refdb-devel — List for RefDB developers

[Refdb-devel] [ refdb-Feature Requests-1706652 ] Please improve bibliography sorting

[SourceForge.net <no...@so...>]

Feature Requests item #1706652, was opened at 2007-04-24 22:21
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1706652&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdb clients
Group: Next Release (example)
Status: Open
Priority: 5
Private: No
Submitted By: Jeremy Malcolm (qirtaiba)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Please improve bibliography sorting

Initial Comment:
As discussed on the mailing list, please improve sorting of the bibliography so that a-z and A-Z are contiguous, and preferably so that if there is no primary author, it will sort on the secondary author instead.

Thanks!

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1706652&group_id=26091

[Refdb-devel] [ refdb-Feature Requests-1603774 ] Database name configuration

[SourceForge.net <no...@so...>]

Feature Requests item #1603774, was opened at 2006-11-27 16:18
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1603774&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
>Status: Closed
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Database name configuration

Initial Comment:
Actually, it is possible to adjust the database name via passing the name to the configure script:

./configure --with-main-db=<name>

That's quite a improvement, but it'll be nice to be fully independant of the building process, especially while a user will get the refdb package in a pre-built form (be it a rpm, deb, binary, ...).

Could the database name be configurable please ?

I could imagine a situation where you have two different databases or only one. In this situation, one could easily use both variable names:

styles-db-name=<db1> (default refdb)
references-db-name=<db2> (default ?)

When you have only one db available, then db1==db2

Thanks for the job :-)

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2007-02-25 12:51

Message:
Logged In: YES 
user_id=85809
Originator: NO

This feature has been implemented in revision 253.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1603774&group_id=26091

[Refdb-devel] [ refdb-Bugs-1643127 ] Web Client: Doesn't separate multiple query results

[SourceForge.net <no...@so...>]

Bugs item #1643127, was opened at 2007-01-24 04:20
Message generated for change (Settings changed) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1643127&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
>Category: web interface
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
>Assigned to: Daniel O'Donnell (dpod)
Summary: Web Client: Doesn't separate multiple query results

Initial Comment:
If you do a query that returns multiple results I only see one checkbox and only one ID tag.  The first piece of information for subsequent results is the Citation key.

0.9.8-1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1643127&group_id=26091

[Refdb-devel] [ refdb-Bugs-1643127 ] Web Client: Doesn't separate multiple query results

[SourceForge.net <no...@so...>]

Bugs item #1643127, was opened at 2007-01-23 19:20
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1643127&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: clients
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Web Client: Doesn't separate multiple query results

Initial Comment:
If you do a query that returns multiple results I only see one checkbox and only one ID tag.  The first piece of information for subsequent results is the Citation key.

0.9.8-1

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1643127&group_id=26091

Re: [Refdb-devel] Storage locations again

[Dan O'D. <dan...@ul...>]

On Mon, 2007-22-01 at 14:19 +0100, Markus Hoenicka wrote:
> Daniel O'Donnell <dan...@ul...> was heard to say:
> 
> > I can see both: a call number and information about reading room, home
> > or office, etc. Also what about a chapter from a collection: the book
> > has a call number (so I can get it again to see the other chapters), and
> > the chapter I photocopied has a physical location. If we can have
> > multiple AVs, I suppose it is not a great problem. Hard to disentangle,
> > though if we decide to have a CN field later.
> >
> 
> I see. Multiple AVs or a new CN field (or do you need more than one?) are of
> course doable in the database. We just have to figure out ways to export these
> data to RIS. We could concatenate the values with a separator, as the AV field
> is of unlimited size as per the spec. risx could be amended to allow several AV
> fields (in fact, it already supports one AV per user).
> 
> > Lying awake thinking about this (!), I began to wonder is M was not
> > better than U: strictly speaking we are talking about agreeing on a
> > miscellaneous field, not adding a user-defined one.
> >
> 
> The thing is, there is no M field which is unused in all reference types. You'll
> always face conflicts with particular reference types no matter which M field
> you pick. The M fields are a leftover of the record-based schema that the
> original incarnations of Reference Manager apparently used, as I've discussed
> here:
> 
> http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=515

Damn. I hadn't realised. What about using a high U for right now then?
Or a separate CN which is converted to RIS AV? I'd say put them all on
AV (i.e. locations like "Shelf in office" and "PR 1119 .A2 v304" except
that I can see reasons for wanting to be able to distinguish between
them: in printing out library cards of spine stickers (both of which I
use) for example: I would want to be able to suppress non-call number
AVs if both existed.

I suppose we could do some kind of ordering thing as they do with date:
AV  - Call Number/Physical Location

-dan
> 
> regards,
> Markus
> 
-- 
Daniel Paul O'Donnell, PhD
Chair, Text Encoding Initiative <http://www.tei-c.org/>
Director, Digital Medievalist Project <http://www.digitalmedievalist.org/>
Associate Professor and Chair of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox: +1 403 329 2378
Fax: +1 403 382-7191
Homepage: http://people.uleth.ca/~daniel.odonnell/

Re: [Refdb-devel] Storage locations again

[Markus H. <mar...@mh...>]

Daniel O'Donnell <dan...@ul...> was heard to say:

> I can see both: a call number and information about reading room, home
> or office, etc. Also what about a chapter from a collection: the book
> has a call number (so I can get it again to see the other chapters), and
> the chapter I photocopied has a physical location. If we can have
> multiple AVs, I suppose it is not a great problem. Hard to disentangle,
> though if we decide to have a CN field later.
>

I see. Multiple AVs or a new CN field (or do you need more than one?) are of
course doable in the database. We just have to figure out ways to export these
data to RIS. We could concatenate the values with a separator, as the AV field
is of unlimited size as per the spec. risx could be amended to allow several AV
fields (in fact, it already supports one AV per user).

> Lying awake thinking about this (!), I began to wonder is M was not
> better than U: strictly speaking we are talking about agreeing on a
> miscellaneous field, not adding a user-defined one.
>

The thing is, there is no M field which is unused in all reference types. You'll
always face conflicts with particular reference types no matter which M field
you pick. The M fields are a leftover of the record-based schema that the
original incarnations of Reference Manager apparently used, as I've discussed
here:

http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=515

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] Storage locations again

[Daniel O'D. <dan...@ul...>]

On Mon, 2007-01-22 at 11:28 +0100, Markus Hoenicka wrote:
> Daniel O'Donnell <dan...@ul...> was heard to say:
> 
> > Looking of the Reference Manager Spec, I'd say it looks like the L
> > series is what we want, though I'm not sure we need their level of
> > granularity (i.e. distinguishing between specifically PDF files vs.
> > specifically full text bu not PDF vs. images). That would leave AV
> > solely for physical location, though as you say refdb itself would need
> > for reasons of backward compatability to look for PATH on the AV field.
> >
> 
> I agree. The PATH: kludge was actually introduced before the L1-L4 fields were
> available in RIS, so it is about time to abandon it. The PHP form should allow
> to enter either a full path (file:///path/to/pdf.pdf) or a relative path
> (path/to/pdf.pdf), as the latter would allow to use the pdfroot setting with
> all its advantages (move your PDF repository without breaking your database,
> access your repository from a remote computer via NFS and so on).
> 
> > It's crucial for me--my library is organised by call numbers--and
> > probably a number of humanists. I've always recorded call number data
> > (sometimes multiple CNs) for books I use a lot, even before I began
> > LoCing my home library. What if I took the last U--U5--on the assumption
> > that would be least likely to conflict with any existing data?
> >
> 
> Come to think of it, wouldn't the AV field be a natural match for call numbers
> once we've moved the links to PDFs out of the way? Or do you need to store a
> call number *and* a physical location?

I can see both: a call number and information about reading room, home
or office, etc. Also what about a chapter from a collection: the book
has a call number (so I can get it again to see the other chapters), and
the chapter I photocopied has a physical location. If we can have
multiple AVs, I suppose it is not a great problem. Hard to disentangle,
though if we decide to have a CN field later.

Lying awake thinking about this (!), I began to wonder is M was not
better than U: strictly speaking we are talking about agreeing on a
miscellaneous field, not adding a user-defined one.


> 
> regards,
> Markus
> 
-- 
Daniel Paul O'Donnell, PhD
Department Chair and Associate Professor of English
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Chair, Text Encoding Initiative http://www.tei-c.org/

Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Vox +1 403 329-2377
Fax +1 403 382-7191
Email: dan...@ul...
WWW: http://people.uleth.ca/~daniel.odonnell/

Re: [Refdb-devel] Storage locations again

[Markus H. <mar...@mh...>]

Daniel O'Donnell <dan...@ul...> was heard to say:

> Looking of the Reference Manager Spec, I'd say it looks like the L
> series is what we want, though I'm not sure we need their level of
> granularity (i.e. distinguishing between specifically PDF files vs.
> specifically full text bu not PDF vs. images). That would leave AV
> solely for physical location, though as you say refdb itself would need
> for reasons of backward compatability to look for PATH on the AV field.
>

I agree. The PATH: kludge was actually introduced before the L1-L4 fields were
available in RIS, so it is about time to abandon it. The PHP form should allow
to enter either a full path (file:///path/to/pdf.pdf) or a relative path
(path/to/pdf.pdf), as the latter would allow to use the pdfroot setting with
all its advantages (move your PDF repository without breaking your database,
access your repository from a remote computer via NFS and so on).

> It's crucial for me--my library is organised by call numbers--and
> probably a number of humanists. I've always recorded call number data
> (sometimes multiple CNs) for books I use a lot, even before I began
> LoCing my home library. What if I took the last U--U5--on the assumption
> that would be least likely to conflict with any existing data?
>

Come to think of it, wouldn't the AV field be a natural match for call numbers
once we've moved the links to PDFs out of the way? Or do you need to store a
call number *and* a physical location?

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

Re: [Refdb-devel] Storage locations again

[Daniel O'D. <dan...@ul...>]

On Sat, 2007-01-20 at 23:23 +0100, Markus Hoenicka wrote:
> [ I've cc'ed and reply-to'ed the refdb devel list. A few others might
> be interested too ]
> 
> Daniel O'Donnell writes:
>  > Hi Markus,
>  > 
>  > I'm thinking about how to handle the AV field, and especially what to do
>  > about digital and physical locations for the same copy. Related to this
>  > is call numbers.
>  > 
>  > Currently, in your implementation of RIS an object can't have both a
>  > physical and a virtual AV, right? Do you think I should require users to
>  > specify which they mean? I.e. check a box to say "computer file" vs.
>  > "physical copy"? Or we could move one of the fields off to a U or M.
>  > 
> 
> As usual, the RIS spec is not very clear about this, but I wonder
> whether we should use the L1/L2 fields for storing paths to electronic
> copies. Each dataset can have an unlimited number of L1 and L2 entries
> so this would not collide with an URL to the original location of a
> PDF. The only difference would be a local path, something like
> file:///path/to/file.pdf, instead of an URL. We'd have to figure out
> something to keep the pdfroot mechanism alive though. refdbc, or a web
> frontend would then have to check both the AV and the L1/L2 fields for
> matching entries if the RP field claims the item is in file.

Looking of the Reference Manager Spec, I'd say it looks like the L
series is what we want, though I'm not sure we need their level of
granularity (i.e. distinguishing between specifically PDF files vs.
specifically full text bu not PDF vs. images). That would leave AV
solely for physical location, though as you say refdb itself would need
for reasons of backward compatability to look for PATH on the AV field.

> 
>  > Same thing with Call numbers, which are covered anywhere in RIS.
>  > Refworks actually uses ER  - to store them!?! We discussed this earlier
>  > and for my personal use I was just going to choose one of the U or M
>  > fields, but a PHP form is going to enforce the choice on whoever uses
>  > it. Any suggestions for where that ought to go?
>  > 
> 
> If at all, we should settle on one of the U fields. Frankly, I don't
> have a better suggestion right now if we want to be able to export all
> data to RIS. We'll have to decide whether this is indeed an important
> goal, or if we should move ahead and officially support more data than
> RIS can store.

It's crucial for me--my library is organised by call numbers--and
probably a number of humanists. I've always recorded call number data
(sometimes multiple CNs) for books I use a lot, even before I began
LoCing my home library. What if I took the last U--U5--on the assumption
that would be least likely to conflict with any existing data?

> 
>  > Given your own work on a better storage and transport language, I think
>  > we should be looking for solutions to these that are easily undone so
>  > data entered into RIS using this form can be converted easily to
>  > whatever comes next. I wouldn't mind being on the same page with you on
>  > this.
>  > 
> 
> I have no idea what your data entry code looks like right now. I
> assume you have some internal representation of the data that you
> receive as input, and you map that representation to either RIS or
> risx. I guess that only that mapping is going to change if RefDB moves
> to a richer storage model.

Basically the PHP entry form is using fields corresponding to the refdb
use of RIS: so the value a user places on article title is assigned to
T1 if the type is an article. The output of the form is an RIS dataset
that is fed directly to refdb of addition to the database. The only
internal datamodelling at the moment involves elements for which fields
can repeat (e.g. like authors); in the PHP form you enter them all in
one line separated by colons.

It seems to me best to do as little internal modelling in the PHP as
possible: the goal is to make a web-based front end for refdb.

> 
> regards,
> Markus
> 
-- 
Daniel Paul O'Donnell, PhD
Director, Digital Medievalist Project http://www.digitalmedievalist.org/
Associate Professor and Chair, Department of English
University of Lethbridge
Lethbridge AB T1K 3M4
Canada
Vox: +1 403 329-2378
Fax: +1 403 382-7191

[Refdb-devel] Storage locations again

[Markus H. <mar...@mh...>]

[ I've cc'ed and reply-to'ed the refdb devel list. A few others might
be interested too ]

Daniel O'Donnell writes:
 > Hi Markus,
 > 
 > I'm thinking about how to handle the AV field, and especially what to do
 > about digital and physical locations for the same copy. Related to this
 > is call numbers.
 > 
 > Currently, in your implementation of RIS an object can't have both a
 > physical and a virtual AV, right? Do you think I should require users to
 > specify which they mean? I.e. check a box to say "computer file" vs.
 > "physical copy"? Or we could move one of the fields off to a U or M.
 > 

As usual, the RIS spec is not very clear about this, but I wonder
whether we should use the L1/L2 fields for storing paths to electronic
copies. Each dataset can have an unlimited number of L1 and L2 entries
so this would not collide with an URL to the original location of a
PDF. The only difference would be a local path, something like
file:///path/to/file.pdf, instead of an URL. We'd have to figure out
something to keep the pdfroot mechanism alive though. refdbc, or a web
frontend would then have to check both the AV and the L1/L2 fields for
matching entries if the RP field claims the item is in file.

 > Same thing with Call numbers, which are covered anywhere in RIS.
 > Refworks actually uses ER  - to store them!?! We discussed this earlier
 > and for my personal use I was just going to choose one of the U or M
 > fields, but a PHP form is going to enforce the choice on whoever uses
 > it. Any suggestions for where that ought to go?
 > 

If at all, we should settle on one of the U fields. Frankly, I don't
have a better suggestion right now if we want to be able to export all
data to RIS. We'll have to decide whether this is indeed an important
goal, or if we should move ahead and officially support more data than
RIS can store.

 > Given your own work on a better storage and transport language, I think
 > we should be looking for solutions to these that are easily undone so
 > data entered into RIS using this form can be converted easily to
 > whatever comes next. I wouldn't mind being on the same page with you on
 > this.
 > 

I have no idea what your data entry code looks like right now. I
assume you have some internal representation of the data that you
receive as input, and you map that representation to either RIS or
risx. I guess that only that mapping is going to change if RefDB moves
to a richer storage model.

regards,
Markus

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] [ refdb-Bugs-1603652 ] Not able to run refdb with one remote MySQL database ...

[SourceForge.net <no...@so...>]

Bugs item #1603652, was opened at 2006-11-27 03:00
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not able to run refdb with one remote MySQL database ...

Initial Comment:
Here is my current setup:

Database cm127107 on remotehost, initiated with:
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/refdb.2.dump.mysql41
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/empty.2.dump.mysql41

(as stated on http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=974)

Refdb from svn, rev238 on localhost, (compiled with:
configure --with-main-db=cm127107 --disable-docs)
refdba on localhost

I've started refdb like this:

refdbd -V -s -e 0 -l 7 -i remotehost

and refdba with:

refdba -d cm127107 -u cm127107

I've also set up (and verified) on the database side, the commands had been correctly set up (via phpmysql).

On the refdba side, i can see the setup is correct via 'set':

#####
set
serverip 127.0.0.1
port 9734
verbose f
pager stdout
username cm127107
timeout 180
logfile /var/log/refdba.log
logdest 2
loglevel 6
refdblib
#####

On the server side (refdbd):

#####
dbi_driver_dir went to:

dbi is up using default driver dir
Available libdbi database drivers:
mysql
Requested libdbi driver found
Database directory:
/usr/local/var/lib/refdb/db
application server started
share extended notes by default
use /tmp/refdbd_fifo16182 as fifo
server waiting n_max_fd=4
adding client 127.0.0.1 on fd 5
server waiting n_max_fd=5
try to read from client
serving client on fd 5 with protocol version 4
021-00-31-26
send pseudo-random string to client
parent removing client on fd 5
server waiting n_max_fd=4
#####


When i want to do a 'viewstat', i get:

refdba:
#####
viewstat
main database is too old or corrupt
#####

refdbd:
#####
viewstat  -u cm127107 -w 111068122108064067116122
dbi is up
195.8.66.15
cm127107
<password>


3306
mysql
/usr/local/var/lib/refdb/db

cm127107
connected to database server using database:
cm127107
main database is too old or corrupt
child finished client on fd 5
child exited with code 1
server waiting n_max_fd=4
#####

Anything i've missed ?

I can provide access (privately) to the mysql database in order to do further checks if needed)

Aside of this, is it logical to see the password IN CLEAR into the refdbd log console ? (i've replaced it here for <password> but it was in lcear ...).

Cheers,


----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-12-07 05:42

Message:
Logged In: NO 

I forgot to tell it, but the setup now works ;-)

Cheers,

Stéphane

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-27 06:45

Message:
Logged In: YES 
user_id=85809
Originator: NO

A quick glance at the MySQL tables revealed the following problem:
database dumps created with current versions of MySQL contain a "DROP
TABLE IF EXISTS" clause in front of each "CREATE TABLE" statement.
Therefore PostgreSQL and SQLite add another row to the existing t_meta
table when creating the reference database tables, whereas MySQL first
drops the existing table and then fills in the row. As a result, the MySQL
database lacks a row in t_meta. The fix is to run the following command in
mysql after using the two dump files refdb.2.dump.mysql41 and
empty.2.dump.mysql41 (in this particular order!):

mysql> INSERT INTO t_meta VALUES ('refdb', 'refdb',
'0.9.8-pre8',2,UTC_TIMESTAMP, UTC_TIMESTAMP);

I've updated the instructions at:

http://mhoenicka.de/system-cgi/blog/index.php?itemid=974

Let me know if your setup works now.

BTW it is indeed intentional that the passwords appear in plain text in
the logs. They appear only when you use log level 7, and I assume you know
what you do if you switch to that log level. A common connection problem is
a mistyped password, after all.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

[Refdb-devel] [ refdb-Bugs-1603652 ] Not able to run refdb with one remote MySQL database ...

[SourceForge.net <no...@so...>]

Bugs item #1603652, was opened at 2006-11-27 12:00
Message generated for change (Settings changed) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not able to run refdb with one remote MySQL database ...

Initial Comment:
Here is my current setup:

Database cm127107 on remotehost, initiated with:
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/refdb.2.dump.mysql41
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/empty.2.dump.mysql41

(as stated on http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=974)

Refdb from svn, rev238 on localhost, (compiled with:
configure --with-main-db=cm127107 --disable-docs)
refdba on localhost

I've started refdb like this:

refdbd -V -s -e 0 -l 7 -i remotehost

and refdba with:

refdba -d cm127107 -u cm127107

I've also set up (and verified) on the database side, the commands had been correctly set up (via phpmysql).

On the refdba side, i can see the setup is correct via 'set':

#####
set
serverip 127.0.0.1
port 9734
verbose f
pager stdout
username cm127107
timeout 180
logfile /var/log/refdba.log
logdest 2
loglevel 6
refdblib
#####

On the server side (refdbd):

#####
dbi_driver_dir went to:

dbi is up using default driver dir
Available libdbi database drivers:
mysql
Requested libdbi driver found
Database directory:
/usr/local/var/lib/refdb/db
application server started
share extended notes by default
use /tmp/refdbd_fifo16182 as fifo
server waiting n_max_fd=4
adding client 127.0.0.1 on fd 5
server waiting n_max_fd=5
try to read from client
serving client on fd 5 with protocol version 4
021-00-31-26
send pseudo-random string to client
parent removing client on fd 5
server waiting n_max_fd=4
#####


When i want to do a 'viewstat', i get:

refdba:
#####
viewstat
main database is too old or corrupt
#####

refdbd:
#####
viewstat  -u cm127107 -w 111068122108064067116122
dbi is up
195.8.66.15
cm127107
<password>


3306
mysql
/usr/local/var/lib/refdb/db

cm127107
connected to database server using database:
cm127107
main database is too old or corrupt
child finished client on fd 5
child exited with code 1
server waiting n_max_fd=4
#####

Anything i've missed ?

I can provide access (privately) to the mysql database in order to do further checks if needed)

Aside of this, is it logical to see the password IN CLEAR into the refdbd log console ? (i've replaced it here for <password> but it was in lcear ...).

Cheers,


----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-27 15:45

Message:
Logged In: YES 
user_id=85809
Originator: NO

A quick glance at the MySQL tables revealed the following problem:
database dumps created with current versions of MySQL contain a "DROP
TABLE IF EXISTS" clause in front of each "CREATE TABLE" statement.
Therefore PostgreSQL and SQLite add another row to the existing t_meta
table when creating the reference database tables, whereas MySQL first
drops the existing table and then fills in the row. As a result, the MySQL
database lacks a row in t_meta. The fix is to run the following command in
mysql after using the two dump files refdb.2.dump.mysql41 and
empty.2.dump.mysql41 (in this particular order!):

mysql> INSERT INTO t_meta VALUES ('refdb', 'refdb',
'0.9.8-pre8',2,UTC_TIMESTAMP, UTC_TIMESTAMP);

I've updated the instructions at:

http://mhoenicka.de/system-cgi/blog/index.php?itemid=974

Let me know if your setup works now.

BTW it is indeed intentional that the passwords appear in plain text in
the logs. They appear only when you use log level 7, and I assume you know
what you do if you switch to that log level. A common connection problem is
a mistyped password, after all.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

Re: [Refdb-devel] Minor formatting fix

[Markus H. <mar...@mh...>]

Hi David,

thanks for turning your attention to small details as well. I've added the
missing space in revision 254.

regards,
Markus

David Nebauer <dav...@sw...> was heard to say:

> Hi Markus,
>
> To be consistent in viewstat output a space should be added after the
> colon when reporting the svn revision.
>

-- 
Markus Hoenicka
mar...@ca...
(Spam-protected email: replace the quadrupeds with "mhoenicka")
http://www.mhoenicka.de

[Refdb-devel] Minor formatting fix

[David N. <dav...@sw...>]

Hi Markus,

To be consistent in viewstat output a space should be added after the 
colon when reporting the svn revision.

Sample viewstat output:
-------------------------------------------------------------------------------
refdba: viewstat
You are served by: refdb 0.9.8-pre9
SVN revision:253
Client IP: 127.0.0.1
Connected via sqlite driver (dbd_sqlite v0.8.1)
to: 2.8.17
db version: 2
serverip: localhost
timeout: 180
dbs_port:
logfile: /var/log/refdbd.log
logdest: FILE
loglevel: INFO
remoteadmin: off
pidfile: /var/run/refdbd.pid
999:1
-------------------------------------------------------------------------------

Regards,
David.

[Refdb-devel] [ refdb-Feature Requests-1603774 ] Database name configuration

[SourceForge.net <no...@so...>]

Feature Requests item #1603774, was opened at 2006-11-27 16:18
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1603774&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Database name configuration

Initial Comment:
Actually, it is possible to adjust the database name via passing the name to the configure script:

./configure --with-main-db=<name>

That's quite a improvement, but it'll be nice to be fully independant of the building process, especially while a user will get the refdb package in a pre-built form (be it a rpm, deb, binary, ...).

Could the database name be configurable please ?

I could imagine a situation where you have two different databases or only one. In this situation, one could easily use both variable names:

styles-db-name=<db1> (default refdb)
references-db-name=<db2> (default ?)

When you have only one db available, then db1==db2

Thanks for the job :-)

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1603774&group_id=26091

[Refdb-devel] [ refdb-Bugs-1603652 ] Not able to run refdb with one remote MySQL database ...

[SourceForge.net <no...@so...>]

Bugs item #1603652, was opened at 2006-11-27 12:00
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not able to run refdb with one remote MySQL database ...

Initial Comment:
Here is my current setup:

Database cm127107 on remotehost, initiated with:
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/refdb.2.dump.mysql41
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/empty.2.dump.mysql41

(as stated on http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=974)

Refdb from svn, rev238 on localhost, (compiled with:
configure --with-main-db=cm127107 --disable-docs)
refdba on localhost

I've started refdb like this:

refdbd -V -s -e 0 -l 7 -i remotehost

and refdba with:

refdba -d cm127107 -u cm127107

I've also set up (and verified) on the database side, the commands had been correctly set up (via phpmysql).

On the refdba side, i can see the setup is correct via 'set':

#####
set
serverip 127.0.0.1
port 9734
verbose f
pager stdout
username cm127107
timeout 180
logfile /var/log/refdba.log
logdest 2
loglevel 6
refdblib
#####

On the server side (refdbd):

#####
dbi_driver_dir went to:

dbi is up using default driver dir
Available libdbi database drivers:
mysql
Requested libdbi driver found
Database directory:
/usr/local/var/lib/refdb/db
application server started
share extended notes by default
use /tmp/refdbd_fifo16182 as fifo
server waiting n_max_fd=4
adding client 127.0.0.1 on fd 5
server waiting n_max_fd=5
try to read from client
serving client on fd 5 with protocol version 4
021-00-31-26
send pseudo-random string to client
parent removing client on fd 5
server waiting n_max_fd=4
#####


When i want to do a 'viewstat', i get:

refdba:
#####
viewstat
main database is too old or corrupt
#####

refdbd:
#####
viewstat  -u cm127107 -w 111068122108064067116122
dbi is up
195.8.66.15
cm127107
<password>


3306
mysql
/usr/local/var/lib/refdb/db

cm127107
connected to database server using database:
cm127107
main database is too old or corrupt
child finished client on fd 5
child exited with code 1
server waiting n_max_fd=4
#####

Anything i've missed ?

I can provide access (privately) to the mysql database in order to do further checks if needed)

Aside of this, is it logical to see the password IN CLEAR into the refdbd log console ? (i've replaced it here for <password> but it was in lcear ...).

Cheers,


----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-27 15:45

Message:
Logged In: YES 
user_id=85809
Originator: NO

A quick glance at the MySQL tables revealed the following problem:
database dumps created with current versions of MySQL contain a "DROP
TABLE IF EXISTS" clause in front of each "CREATE TABLE" statement.
Therefore PostgreSQL and SQLite add another row to the existing t_meta
table when creating the reference database tables, whereas MySQL first
drops the existing table and then fills in the row. As a result, the MySQL
database lacks a row in t_meta. The fix is to run the following command in
mysql after using the two dump files refdb.2.dump.mysql41 and
empty.2.dump.mysql41 (in this particular order!):

mysql> INSERT INTO t_meta VALUES ('refdb', 'refdb',
'0.9.8-pre8',2,UTC_TIMESTAMP, UTC_TIMESTAMP);

I've updated the instructions at:

http://mhoenicka.de/system-cgi/blog/index.php?itemid=974

Let me know if your setup works now.

BTW it is indeed intentional that the passwords appear in plain text in
the logs. They appear only when you use log level 7, and I assume you know
what you do if you switch to that log level. A common connection problem is
a mistyped password, after all.


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

[Refdb-devel] [ refdb-Bugs-1603652 ] Not able to run refdb with one remote MySQL database ...

[SourceForge.net <no...@so...>]

Bugs item #1603652, was opened at 2006-11-27 12:00
Message generated for change (Tracker Item Submitted) made by Item Submitter
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: steletch (steletch)
Assigned to: Nobody/Anonymous (nobody)
Summary: Not able to run refdb with one remote MySQL database ...

Initial Comment:
Here is my current setup:

Database cm127107 on remotehost, initiated with:
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/refdb.2.dump.mysql41
mysql -h remotehost -u cm127107 -p cm127107 < /usr/local/share/refdb/sql/empty.2.dump.mysql41

(as stated on http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=974)

Refdb from svn, rev238 on localhost, (compiled with:
configure --with-main-db=cm127107 --disable-docs)
refdba on localhost

I've started refdb like this:

refdbd -V -s -e 0 -l 7 -i remotehost

and refdba with:

refdba -d cm127107 -u cm127107

I've also set up (and verified) on the database side, the commands had been correctly set up (via phpmysql).

On the refdba side, i can see the setup is correct via 'set':

#####
set
serverip 127.0.0.1
port 9734
verbose f
pager stdout
username cm127107
timeout 180
logfile /var/log/refdba.log
logdest 2
loglevel 6
refdblib
#####

On the server side (refdbd):

#####
dbi_driver_dir went to:

dbi is up using default driver dir
Available libdbi database drivers:
mysql
Requested libdbi driver found
Database directory:
/usr/local/var/lib/refdb/db
application server started
share extended notes by default
use /tmp/refdbd_fifo16182 as fifo
server waiting n_max_fd=4
adding client 127.0.0.1 on fd 5
server waiting n_max_fd=5
try to read from client
serving client on fd 5 with protocol version 4
021-00-31-26
send pseudo-random string to client
parent removing client on fd 5
server waiting n_max_fd=4
#####


When i want to do a 'viewstat', i get:

refdba:
#####
viewstat
main database is too old or corrupt
#####

refdbd:
#####
viewstat  -u cm127107 -w 111068122108064067116122
dbi is up
195.8.66.15
cm127107
<password>


3306
mysql
/usr/local/var/lib/refdb/db

cm127107
connected to database server using database:
cm127107
main database is too old or corrupt
child finished client on fd 5
child exited with code 1
server waiting n_max_fd=4
#####

Anything i've missed ?

I can provide access (privately) to the mysql database in order to do further checks if needed)

Aside of this, is it logical to see the password IN CLEAR into the refdbd log console ? (i've replaced it here for <password> but it was in lcear ...).

Cheers,


----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1603652&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 14:19
Message generated for change (Comment added) made by dreusser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
>Status: Closed
Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

>Comment By: Dominik (dreusser)
Date: 2006-11-24 13:35

Message:
Logged In: YES 
user_id=1572139
Originator: YES

works with revision 241.
Thanks

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-22 22:17

Message:
Logged In: YES 
user_id=85809
Originator: NO

Turns out the problem was an insufficiently sized buffer in dbfncs.c. The
problem does not depend on particular input data, but it occurs only if
you use MySQL as the database engine. I've fixed this bug in subversion
revision 241. A one-line patch is also attached to this bug report.

Please let me know whether revision 241 runs ok on Debian with MySQL.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-22 14:57

Message:
Logged In: YES 
user_id=85809
Originator: NO

It is correct that the current svn version still claims to be pre8. I
usually bump up the version numbers only just before a new (pre)release. I
think I should add the svn revision number to the viewstat output as well.
As for the bug itself, please provide your database (as a ris or risx
dump) and the ris file that you want to check. As valgrind does not detect
any incorrect access to allocated memory with my data, I'll have to try
with your data in order to reproduce the problem.

----------------------------------------------------------------------

Comment By: Dominik (dreusser)
Date: 2006-11-22 14:47

Message:
Logged In: YES 
user_id=1572139
Originator: YES

When reporting the bug, I've been using the refdb 0.9.8-pre8 (as shown in
refdb-bug.txt). I upgraded today to svn revision 238 (dpkg -i
refdb-server_0.0-svn-20061121_i386.deb
refdb-0.0-svn_20061121.orig.tar.gz). Is it possible, that refdba:viewstat
still reports 0.9.8-pre8 after upgrading? If so, then the error persists
with the latest svn.
With respect to the debian system: I'm also using an up-to-date
debian/testing box except for 9 packages which are held back (apache2
apache2-mpm-prefork apache2-utils gnupg libapache-mod-php4
libapache2-mod-perl2 libapache2-mod-php4 php4-common php4-mysql).

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-20 22:54

Message:
Logged In: YES 
user_id=85809
Originator: NO

I've checked my setup on FreeBSD using valgrind to detect allocated memory
problems. There were no errors reported, except a number of memory leaks
related to the checkref command. I've plugged these leaks, although they
most likely cannot not cause the problem that you reported. In any case
you may want to check out svn revision 238 and try again. If this does not
fix the problem, please send me your test data (both the datasets in your
database and in the file that you want to check) off-list. It could just
so happen that my data miss a bordercase that triggers the problem.

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-20 18:42

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 14:19
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
>Resolution: Fixed
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-22 22:17

Message:
Logged In: YES 
user_id=85809
Originator: NO

Turns out the problem was an insufficiently sized buffer in dbfncs.c. The
problem does not depend on particular input data, but it occurs only if
you use MySQL as the database engine. I've fixed this bug in subversion
revision 241. A one-line patch is also attached to this bug report.

Please let me know whether revision 241 runs ok on Debian with MySQL.

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-22 14:57

Message:
Logged In: YES 
user_id=85809
Originator: NO

It is correct that the current svn version still claims to be pre8. I
usually bump up the version numbers only just before a new (pre)release. I
think I should add the svn revision number to the viewstat output as well.
As for the bug itself, please provide your database (as a ris or risx
dump) and the ris file that you want to check. As valgrind does not detect
any incorrect access to allocated memory with my data, I'll have to try
with your data in order to reproduce the problem.

----------------------------------------------------------------------

Comment By: Dominik (dreusser)
Date: 2006-11-22 14:47

Message:
Logged In: YES 
user_id=1572139
Originator: YES

When reporting the bug, I've been using the refdb 0.9.8-pre8 (as shown in
refdb-bug.txt). I upgraded today to svn revision 238 (dpkg -i
refdb-server_0.0-svn-20061121_i386.deb
refdb-0.0-svn_20061121.orig.tar.gz). Is it possible, that refdba:viewstat
still reports 0.9.8-pre8 after upgrading? If so, then the error persists
with the latest svn.
With respect to the debian system: I'm also using an up-to-date
debian/testing box except for 9 packages which are held back (apache2
apache2-mpm-prefork apache2-utils gnupg libapache-mod-php4
libapache2-mod-perl2 libapache2-mod-php4 php4-common php4-mysql).

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-20 22:54

Message:
Logged In: YES 
user_id=85809
Originator: NO

I've checked my setup on FreeBSD using valgrind to detect allocated memory
problems. There were no errors reported, except a number of memory leaks
related to the checkref command. I've plugged these leaks, although they
most likely cannot not cause the problem that you reported. In any case
you may want to check out svn revision 238 and try again. If this does not
fix the problem, please send me your test data (both the datasets in your
database and in the file that you want to check) off-list. It could just
so happen that my data miss a bordercase that triggers the problem.

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-20 18:42

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 14:19
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-22 14:57

Message:
Logged In: YES 
user_id=85809
Originator: NO

It is correct that the current svn version still claims to be pre8. I
usually bump up the version numbers only just before a new (pre)release. I
think I should add the svn revision number to the viewstat output as well.
As for the bug itself, please provide your database (as a ris or risx
dump) and the ris file that you want to check. As valgrind does not detect
any incorrect access to allocated memory with my data, I'll have to try
with your data in order to reproduce the problem.

----------------------------------------------------------------------

Comment By: Dominik (dreusser)
Date: 2006-11-22 14:47

Message:
Logged In: YES 
user_id=1572139
Originator: YES

When reporting the bug, I've been using the refdb 0.9.8-pre8 (as shown in
refdb-bug.txt). I upgraded today to svn revision 238 (dpkg -i
refdb-server_0.0-svn-20061121_i386.deb
refdb-0.0-svn_20061121.orig.tar.gz). Is it possible, that refdba:viewstat
still reports 0.9.8-pre8 after upgrading? If so, then the error persists
with the latest svn.
With respect to the debian system: I'm also using an up-to-date
debian/testing box except for 9 packages which are held back (apache2
apache2-mpm-prefork apache2-utils gnupg libapache-mod-php4
libapache2-mod-perl2 libapache2-mod-php4 php4-common php4-mysql).

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-20 22:54

Message:
Logged In: YES 
user_id=85809
Originator: NO

I've checked my setup on FreeBSD using valgrind to detect allocated memory
problems. There were no errors reported, except a number of memory leaks
related to the checkref command. I've plugged these leaks, although they
most likely cannot not cause the problem that you reported. In any case
you may want to check out svn revision 238 and try again. If this does not
fix the problem, please send me your test data (both the datasets in your
database and in the file that you want to check) off-list. It could just
so happen that my data miss a bordercase that triggers the problem.

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-20 18:42

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 14:19
Message generated for change (Comment added) made by dreusser
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

>Comment By: Dominik (dreusser)
Date: 2006-11-22 14:47

Message:
Logged In: YES 
user_id=1572139
Originator: YES

When reporting the bug, I've been using the refdb 0.9.8-pre8 (as shown in
refdb-bug.txt). I upgraded today to svn revision 238 (dpkg -i
refdb-server_0.0-svn-20061121_i386.deb
refdb-0.0-svn_20061121.orig.tar.gz). Is it possible, that refdba:viewstat
still reports 0.9.8-pre8 after upgrading? If so, then the error persists
with the latest svn.
With respect to the debian system: I'm also using an up-to-date
debian/testing box except for 9 packages which are held back (apache2
apache2-mpm-prefork apache2-utils gnupg libapache-mod-php4
libapache2-mod-perl2 libapache2-mod-php4 php4-common php4-mysql).

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-20 22:54

Message:
Logged In: YES 
user_id=85809
Originator: NO

I've checked my setup on FreeBSD using valgrind to detect allocated memory
problems. There were no errors reported, except a number of memory leaks
related to the checkref command. I've plugged these leaks, although they
most likely cannot not cause the problem that you reported. In any case
you may want to check out svn revision 238 and try again. If this does not
fix the problem, please send me your test data (both the datasets in your
database and in the file that you want to check) off-list. It could just
so happen that my data miss a bordercase that triggers the problem.

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-20 18:42

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599208 ] Error message from autogen.sh for svn revision 237

[SourceForge.net <no...@so...>]

Bugs item #1599208, was opened at 2006-11-19 14:48
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599208&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
>Status: Closed
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Error message from autogen.sh for svn revision 237

Initial Comment:
On my computer (Mandriva Linux 2007.0), i get:

./autogen.sh 
aclocal:configure.in:243: warning: macro `AM_ICONV_LINK' not found in library

This results in the configure step to:
./configure: line 3900: AM_ICONV_LINK: command not found

When i try to build refdb, it fails with the error message:

then mv -f ".deps/refdbdcheckref.Tpo" ".deps/refdbdcheckref.Po"; else rm -f ".deps/refdbdcheckref.Tpo"; exit 1; fi
gcc  -g -O2   -o refdbd  refdbd.o refdbdref.o refdbda.o refdbdbib.o pref.o strfncs.o tokenize.o connect.o risdb.o writeris.o getopt.o readris.o backend.o backend-scrn.o backend-ris.o backend-risx.o backend-db31.o backend-teix.o backend-bibtex.o backend-html.o backend-dbib.o backend-dbiba.o backend-citationlistx.o linklist.o xmlhandler.o enigma.o cgi.o atoll.o dbfncs.o xmlout.o risxhandler.o authorinfo.o risdata.o noteshandler.o refdbdnote.o writenote.o backendn-scrn.o backendn-notex.o backendn-html.o xmlhelper.o mset.o refdbdgetref.o refdbdupdb.o passwd.o refdbdcheckref.o -ldl -ldbi -lz -lexpat @LIBICONV@ 


I've tried to search for circumventing this, but unfortunately without luck :-(

----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-21 00:22

Message:
Logged In: YES 
user_id=85809
Originator: NO

Good. Going to close this bug report.

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-11-20 23:46

Message:
Logged In: NO 

Ok, sorry fot the noise.

The iconv.m4 file is into the gettext-devel file in Mandriva ...

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-19 21:58

Message:
Logged In: YES 
user_id=85809
Originator: NO

Please make sure that libiconv is installed on your system
(http://www.gnu.org/software/libiconv/, usually also available as a
package). You should then have /usr/[local/]share/aclocal/iconv.m4 on your
system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599208&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599208 ] Error message from autogen.sh for svn revision 237

[SourceForge.net <no...@so...>]

Bugs item #1599208, was opened at 2006-11-19 05:48
Message generated for change (Comment added) made by nobody
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599208&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: None
Group: None
Status: Open
Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Error message from autogen.sh for svn revision 237

Initial Comment:
On my computer (Mandriva Linux 2007.0), i get:

./autogen.sh 
aclocal:configure.in:243: warning: macro `AM_ICONV_LINK' not found in library

This results in the configure step to:
./configure: line 3900: AM_ICONV_LINK: command not found

When i try to build refdb, it fails with the error message:

then mv -f ".deps/refdbdcheckref.Tpo" ".deps/refdbdcheckref.Po"; else rm -f ".deps/refdbdcheckref.Tpo"; exit 1; fi
gcc  -g -O2   -o refdbd  refdbd.o refdbdref.o refdbda.o refdbdbib.o pref.o strfncs.o tokenize.o connect.o risdb.o writeris.o getopt.o readris.o backend.o backend-scrn.o backend-ris.o backend-risx.o backend-db31.o backend-teix.o backend-bibtex.o backend-html.o backend-dbib.o backend-dbiba.o backend-citationlistx.o linklist.o xmlhandler.o enigma.o cgi.o atoll.o dbfncs.o xmlout.o risxhandler.o authorinfo.o risdata.o noteshandler.o refdbdnote.o writenote.o backendn-scrn.o backendn-notex.o backendn-html.o xmlhelper.o mset.o refdbdgetref.o refdbdupdb.o passwd.o refdbdcheckref.o -ldl -ldbi -lz -lexpat @LIBICONV@ 


I've tried to search for circumventing this, but unfortunately without luck :-(

----------------------------------------------------------------------

Comment By: Nobody/Anonymous (nobody)
Date: 2006-11-20 14:46

Message:
Logged In: NO 

Ok, sorry fot the noise.

The iconv.m4 file is into the gettext-devel file in Mandriva ...

----------------------------------------------------------------------

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-19 12:58

Message:
Logged In: YES 
user_id=85809
Originator: NO

Please make sure that libiconv is installed on your system
(http://www.gnu.org/software/libiconv/, usually also available as a
package). You should then have /usr/[local/]share/aclocal/iconv.m4 on your
system.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599208&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 14:19
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
>Resolution: Works For Me
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-20 22:54

Message:
Logged In: YES 
user_id=85809
Originator: NO

I've checked my setup on FreeBSD using valgrind to detect allocated memory
problems. There were no errors reported, except a number of memory leaks
related to the checkref command. I've plugged these leaks, although they
most likely cannot not cause the problem that you reported. In any case
you may want to check out svn revision 238 and try again. If this does not
fix the problem, please send me your test data (both the datasets in your
database and in the file that you want to check) off-list. It could just
so happen that my data miss a bordercase that triggers the problem.

----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-20 18:42

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

[Refdb-devel] [ refdb-Bugs-1599713 ] checkref: *** glibc detected *** double free or corruption

[SourceForge.net <no...@so...>]

Bugs item #1599713, was opened at 2006-11-20 22:49
Message generated for change (Comment added) made by davidnebauer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091

Please note that this message will contain a full copy of the comment thread,
including the initial issue submission, for this request,
not just the latest update.
Category: refdbd
Group: None
Status: Open
Resolution: None
Priority: 5
Private: No
Submitted By: Dominik (dreusser)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: checkref: *** glibc detected *** double free or corruption 

Initial Comment:
On my debian box I get the following error while running checkref (I'm not sure whether this really is a problem in refdbd or some debian-glibc bug):

client:
refdbc: checkref test.ris
could not write to refdbd. Stop

server:
CREATE TEMPORARY TABLE t_temp_xlink (xlink_id BIGINT NOT NULL AUTO_INCREMENT,link_id BIGINT NOT NULL,xref_id BIGINT NOT NULL,xlink_type ENUM("URL","PDF","FULLTEXT","RELATED", "IMAGE"),xlink_source ENUM("REFERENCE","NOTE"),PRIMARY KEY (xlink_id),KEY (link_id),KEY (xref_id))
BEGIN
LOCK TABLES t_temp_refdb WRITE, t_temp_author WRITE, t_temp_keyword WRITE, t_temp_periodical WRITE, t_temp_user WRITE, t_temp_xauthor WRITE, t_temp_xkeyword WRITE, t_temp_xuser WRITE, t_temp_note WRITE, t_temp_xnote WRITE, t_temp_link WRITE, t_temp_xlink WRITE, refdb.t_journal_words WRITE
*** glibc detected *** double free or corruption (!prev): 0x080ff5a0 ***
child exited with code 0
server waiting n_max_fd=4



----------------------------------------------------------------------

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-21 03:12

Message:
Logged In: YES 
user_id=1080150
Originator: NO

Using refdb svn revision 224 on my up-to-date debian/testing box I find
the checkref command works perfectly and does not generate the error you
describe.  Perhaps you could state the version of refdb you used and the
flavour of debian you are running it on.

----------------------------------------------------------------------

You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1599713&group_id=26091