refdb-devel — List for RefDB developers

[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 (Tracker Item Submitted) made by Item Submitter
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



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

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: 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: 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 (Tracker Item Submitted) made by Item Submitter
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: None
Priority: 5
Private: No
Submitted By: Nobody/Anonymous (nobody)
Assigned to: Nobody/Anonymous (nobody)
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 :-(

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

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

[Refdb-devel] [ refdb-Feature Requests-1519911 ] MARCXML support

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

Feature Requests item #1519911, was opened at 2006-07-10 14:25
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1519911&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: None
>Status: Closed
Priority: 5
Private: No
Submitted By: Markus Hoenicka (mhoenicka)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: MARCXML support

Initial Comment:
marc2ris currently supports only binary MARC datasets.
Add support for MARCXML. 

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

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

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

MARC-XML has an xml2marc utility which can be used to preprocess MARCXML
data

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

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

[Refdb-devel] [ refdb-Feature Requests-1526113 ] Mandatory database check

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

Feature Requests item #1526113, was opened at 2006-07-20 22:04
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385994&aid=1526113&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: Markus Hoenicka (mhoenicka)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Mandatory database check

Initial Comment:
Currently, if you run a refdb client in batch mode and
attempt to an existing database which is not a RefDB
reference database, you're left cluesless with strange
error messages. refdbd has a builtin check for RefDB
reference databases, but this is currently only invoked
if you use the selectdb command in interactive mode.

1) we could force the check whenever refdbc runs in
batch mode
2) we could run the check by default and add a switch
for experienced users who want to bypass the check to
gain some speed


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

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-18 23:47

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

Current RefDB versions return the message "could not open reference
database" if you try to connect to a nonexistent or a non-RefDB reference
database. This, along with the database engine error message in the refdbd
log should give enough of a clue. 

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

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

[Refdb-devel] [ refdb-Bugs-1597383 ] using dselect (Debian)

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

Bugs item #1597383, was opened at 2006-11-16 01:10
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1597383&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: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://refdb.sourceforge.net/debian/addons testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454484 package 'dbn-querydtd': field name 'This' must be followed by colon

update available list script returned error exit status 2.
(apt-get install is working fine)

For http://refdb.sourceforge.net/debian/release testing main and http://refdb.sourceforge.net/debian/svn testing main, i can use apt-get install and/or dselect.


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

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

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

Great. Going to close this bug report.

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

Comment By: John Beining (jbeining)
Date: 2006-11-18 21:32

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

The problem is fixed.
I have tested the new repository by using 'apt-get install' 'dselect' and
aptitude'.

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

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-17 10:43

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

Thanks for pointing out this problem with the addons repository.  I
suspect the problem is with a malformed Packages.gz file in the repository
tree.  Some package managers (e.g., aptitude) are able to cope with the
errors in the file but others cannot (e.g., dselect).

I've corrected the problem and uploaded a new repository.  Please test it
and let me know if the problem is fixed.

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

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

[Refdb-devel] [ refdb-Bugs-1597383 ] using dselect (Debian)

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

Bugs item #1597383, was opened at 2006-11-16 01:10
Message generated for change (Comment added) made by jbeining
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1597383&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: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://refdb.sourceforge.net/debian/addons testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454484 package 'dbn-querydtd': field name 'This' must be followed by colon

update available list script returned error exit status 2.
(apt-get install is working fine)

For http://refdb.sourceforge.net/debian/release testing main and http://refdb.sourceforge.net/debian/svn testing main, i can use apt-get install and/or dselect.


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

>Comment By: John Beining (jbeining)
Date: 2006-11-18 21:32

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

The problem is fixed.
I have tested the new repository by using 'apt-get install' 'dselect' and
aptitude'.

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

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-17 10:43

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

Thanks for pointing out this problem with the addons repository.  I
suspect the problem is with a malformed Packages.gz file in the repository
tree.  Some package managers (e.g., aptitude) are able to cope with the
errors in the file but others cannot (e.g., dselect).

I've corrected the problem and uploaded a new repository.  Please test it
and let me know if the problem is fixed.

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

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

[Refdb-devel] [ refdb-Bugs-1597383 ] using dselect (Debian)

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

Bugs item #1597383, was opened at 2006-11-16 09:40
Message generated for change (Comment added) made by davidnebauer
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1597383&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: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://refdb.sourceforge.net/debian/addons testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454484 package 'dbn-querydtd': field name 'This' must be followed by colon

update available list script returned error exit status 2.
(apt-get install is working fine)

For http://refdb.sourceforge.net/debian/release testing main and http://refdb.sourceforge.net/debian/svn testing main, i can use apt-get install and/or dselect.


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

Comment By: David Nebauer (davidnebauer)
Date: 2006-11-17 19:13

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

Thanks for pointing out this problem with the addons repository.  I
suspect the problem is with a malformed Packages.gz file in the repository
tree.  Some package managers (e.g., aptitude) are able to cope with the
errors in the file but others cannot (e.g., dselect).

I've corrected the problem and uploaded a new repository.  Please test it
and let me know if the problem is fixed.

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

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

[Refdb-devel] [ refdb-Bugs-1587512 ] citestylex documentation is out of date

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

Bugs item #1587512, was opened at 2006-10-30 22:31
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1587512&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: Markus Hoenicka (mhoenicka)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: citestylex documentation is out of date

Initial Comment:
citestylex has gained a few tricks, e.g. the citation
key citation format. Most of these new features are
undocumented which makes it unnecessarily hard to use
them :-(

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

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-16 21:56

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

uploaded to the web page

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

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

[Refdb-devel] [ refdb-Bugs-1584375 ] External database link not possible

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

Bugs item #1584375, was opened at 2006-10-25 14:06
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1584375&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: steletch (steletch)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: External database link not possible

Initial Comment:
Unless i have not read correctly the manual, i think it
is not possible to have a separate refdb server and a
database server (be it mysql or postgresql).

It would be nice to be able to separate it since having
a separate database server would be nice (i.e. the
external database server can be on the internet and
refdbd on another machine). In fact, most providers
allow database functinalities but do not permit
software installation (refdb).

If i'm wrong, please tell me where i could correct it
please.

Cheers,

Stéphane

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

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-16 10:13

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

Subversion revision 235 now allows to run RefDB with a single database.
See also this blog entry:
http://www.mhoenicka.de/system-cgi/blog/index.php?itemid=974

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

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-02 09:20

Message:
Logged In: YES 
user_id=85809

There is a configure switch to set the main database name
(--with-main-db=name), but this doesn't solve your problem
entirely. As far as I understand you need to run RefDB using
a single database, rather than with a main database and one
or more reference databases. I have to admit that I have not
anticipated any need for doing this. Unfortunately both the
main database and the reference databases contain a table
"t_meta" with identical columns. I'd have to make the main
database meta table name configurable too to avoid the name
clash. Even then some RefDB commands are likely to fail,
e.g. the createdb command, as it will attempt to create a
database that already exists, instead of just adding columns
to it. You'd have to create the reference database tables
from a SQL script (which RefDB provides) instead of using
the createdb command. You'd also have to refrain from using
the main database maintenance mode of refdbd as it would
delete your reference data.

I think I could provide (fragile) support for this feature
in one of the next prereleases for further testing. Adding
robust support may require more thorough changes which I
could add at a later time.

Would you mind submitting a feature request for this? After
all, it's not a bug but rather a limitation of RefDB.

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

Comment By: steletch (steletch)
Date: 2006-10-31 18:18

Message:
Logged In: YES 
user_id=1129476

Hum, that's bad..

I've checked on my ISP and i cannot (at least for now)
change the database name. I've asked him why and if it could
be at least aliased, but no answer yet.

Could it be possible to get a parameter for specifying the
database name (for customizing refdb to the one provided by
my ISP).

I'm ok for a personal hack if tests are needed ...

And for the non existing message, i've no clue, but i've
carefully checked and nothing happens on the server side.

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

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-27 09:24

Message:
Logged In: YES 
user_id=85809

 > Note that on the remote host, the database name is *not*
 > refdb, and the password is *not* refdb.

That pretty much explains why your setup can't work. Each
RefDB installation requires exactly one main database called
refdb to hold the styles and the journal name word list, and
at least one reference database with a different name. The
refdb database is not used by all client commands, but many
require a connection to this database as well. This is
especially true for the viewstat command. The command does
not access any reference data, but it still needs a
connection to the database engine to retrieve version
numbers and such. Therefore viewstat causes refdbd to
connect to the refdb database. If that is missing, you're
screwed.

So please make sure there is a main database called refdb,
created from the appropriate dump file, and make sure the
permissions allow you to connect to that database from your
local computer.

BTW I don't understand why the refdbd -s -e 0 -l 7 log says
nothing. If you run the viewstat command, and get the "could
not open main database" message on the client side, refdbd
must have listed the connection parameters. You should see
that it tries to connect to the refdb database, and you
should also see the error message returned by the database
engine.

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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-10-26 22:05

Message:
Logged In: NO 

Unfortunately, nothing :-(

For what it worths, the remote database name is not refdb
but cm126109

I can connect to it with:
mysql -h <remote host> -u <remote user> -p <remote password>
-d <remote database>, and see all the tables i've already
created (the database itself contains all tables you expect
from a refdb database, *but its name is not refdb*)

Here is what i've done:
1 - start refdbd using --- refdbd -V -s -e 0 -l 7
2 - start refdba using --- refdba -u <remote user> -w
<remote password> -d <remote database> -i <remote host>

In refdba, if i type set, i can see refdb is pointing to
<remote host>, but when i type viewstat, i get:
from refdba --- could not establish server connection
from refdbd --- <nothing> ...

Note that on the remote host, the database name is *not*
refdb, and the password is *not* refdb.

Anything else ?

When i enter in refdba the command *set*, i see the correct
<host>

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

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-26 15:04

Message:
Logged In: YES 
user_id=85809

I would like to know what refdbd -l 7 says at the point
where you run "viewstat". Does that give any clue?

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

Comment By: steletch (steletch)
Date: 2006-10-26 14:54

Message:
Logged In: YES 
user_id=1129476

To be clear...

I can connect to the external database with mysql -u -p,
i've checked via phpmyadmin or the mysql command line that
the database is created and correctly filled in 'as fas as i
can redad from the dump).

I lanched refdb with -l 7
I then launched refdba with -u -p -i as appropriate

The result of the command 'viewstat' is:
"could not open main database"

I'll check again tonight in case i missed any step in this
process.

I'll let you know after the test.


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

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-26 14:38

Message:
Logged In: YES 
user_id=85809

 > refdbd  -i <database server ip> -b <database port> -V -u
<database admin> -w <database admin password> -s -e 0 -l 7
-d <database name>

The -u and -w switches are not required here, they are used
only if you run refdbd to check or update the main database.
If you run refdbd as an application server, the username and
passwords are always provided by the clients.

 > ??? Nothin tells me i have it :-(

Well, refdbd can't. As I said above, refdbd needs a client
connection providing the username and password in order to
even attempt to talk to a database engine. At this point,
i.e. right after startup, refdbd does not know whether or
not it can connect to the database engine.

 > refdba: viewstat
 > could not open main database

You need to use the same username+password in refdba as you
would in the mysql command line client. Can you indeed
connect from your local box to the remote MySQL server with
a command like this:

mysql -u <username> -p refdb

The permissions of the MySQL engine must allow the user in
question to connect to the particular database from your
local box. You may want to review the contents of the db,
host, and user tables of the mysql database in order to
check your permissions.

To make sure your setup is ok you should also look at the -l
7 output of refdbd when you run the viewstat command. You'll
see the connection parameters as they arrive at refdbd.


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

Comment By: Nobody/Anonymous (nobody)
Date: 2006-10-25 23:53

Message:
Logged In: NO 

Well, i tried to follow your recommendations, but i'm pretty
missing something...

I tried to do:

 refdbd  -i <database server ip> -b <database port> -V -u
<database admin> -w <database admin password> -s -e 0 -l 7
-d <database name>

And i get :

dbi_driver_dir went to:

dbi is up using default driver dir
Available libdbi database drivers:
mysql
Requested libdbi driver found
Database directory:
/var/lib/refdb/db
application server started
share extended notes by default
use cm126109 as default database
use /tmp/refdbd_fifo9900 as fifo
server waiting n_max_fd=4

???
Nothin tells me i have it :-(

When i do:
 refdba
Please enter your password: 
refdba: set
serverip 127.0.0.1
port 9734
verbose f
pager stdout
username stephane
timeout 180
logfile /var/log/refdba.log
logdest 2
loglevel 6
refdblib 
 (i tried also by setting a username + password)

refdba: viewstat
could not open main database


So refdbd has not connected correclyt :-(

I've set up the database manually on the remote computer
(using the import mysql function for the appropriate
mysql41+ dump). I can see via phpmyadmin the database 's
structure is there, and from my local computer, i can
connect to the remote computer.

Anything i'm missing ?

Cheers,

Stéphane

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

Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-10-25 14:23

Message:
Logged In: YES 
user_id=85809

I'm sure that this is just a configuration problem as it was
one of the design goals to be able to separate the clients,
the application server, and the database engine physically
if you have any reasons to do so. refdbd (or rather the
libdbi driver it uses) basically acts as the database engine
client. In order to access the database engine on a
different machine, you need to tweak two refdbd settings:

- set the IP address of the box that runs your database
engine. Either set "serverip" in the refdbdrc config file,
or use the -i command line switch. Use the IP address or the
hostname if it can be resolved properly

- set the port where the database engine listens. Set
"dbsport" in refdbcrc, or use the -b command line switch
(*NOT* the more appealing -p switch which defines which port
refdbd listens on for client connections)

This should be all it takes on the RefDB side. Of course you
need to configure your database engine appropriately. E.g.
both MySQL and PostgreSQL listen to local connections only
by default for security reasons. You'll have to flip a
switch to make them serve external connections. Also, both
engines support host-based authentication. That is, you need
to set the database permissions properly to allow
connections from refdbd. It may be slightly confusing that
the host in question is the box where refdbd runs, not where
the client runs (because refdbd acts as the database engine
client, as mentioned before).


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

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

[Refdb-devel] [ refdb-Bugs-1597383 ] using dselect (Debian)

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

Bugs item #1597383, was opened at 2006-11-16 01:10
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=1597383&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: John Beining (jbeining)
Assigned to: Nobody/Anonymous (nobody)
Summary: using dselect (Debian)

Initial Comment:
When i use dselect (Debian) 'update' to access http://refdb.sourceforge.net/debian/addons testing main i get the following message (error): dpkg: parse error, in file '/var/cache/apt/ available' near line 454484 package 'dbn-querydtd': field name 'This' must be followed by colon

update available list script returned error exit status 2.
(apt-get install is working fine)

For http://refdb.sourceforge.net/debian/release testing main and http://refdb.sourceforge.net/debian/svn testing main, i can use apt-get install and/or dselect.


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

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

[Refdb-devel] Oops: inadvertently updated manualxhtml.xsl

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

Don't worry. This was the right fix, after all.

regards,
Markus

David Nebauer writes:
 > Hi Markus,
 > 
 > My apologies.  I inadvertently committed a change to manual-xhtml.xsl in 
 > the refdb repository when I was trying to update my own build system 
 > repository.  This is a problem with having nested svn repositories.  
 > Next on the to-do list: "de-nest" the repositories.
 > 
 > Regards,
 > David.
 > 
 > -------------------------------------------------------------------------
 > Using Tomcat but need to do more? Need to support web services, security?
 > Get stuff done quickly with pre-integrated technology to make your job easier
 > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 > _______________________________________________
 > Refdb-devel mailing list
 > Ref...@li...
 > https://lists.sourceforge.net/lists/listinfo/refdb-devel
 > 

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

[Refdb-devel] Oops: inadvertently updated manualxhtml.xsl

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

Hi Markus,

My apologies.  I inadvertently committed a change to manual-xhtml.xsl in 
the refdb repository when I was trying to update my own build system 
repository.  This is a problem with having nested svn repositories.  
Next on the to-do list: "de-nest" the repositories.

Regards,
David.

Re: [Refdb-devel] Build failure: HTML manual

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

David Nebauer writes:
 > This solves the problem with xsltproc and I am now able to build the 
 > docs.  Thanks for the fix.
 > 
 > Incidentally, the nav links are still present in the output.
 > 

Great. The nav links also work in my xsltproc output. I only got this
problem when transforming the manual with Saxon.

regards,
Markus

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

Re: [Refdb-devel] Build failure: HTML manual

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

Hi Markus,
> The following one-line-fix in
> doc/include/manual-xhtml.xsl fixes the problem with Saxon:
>
> -      <xsl:with-param name="nodes" select="refsynopsisdiv | refsect1 | refsect2 | refsect3"/>
> +      <xsl:with-param name="nodes" select="refsect1 | refsect2 | refsect3"/>


This solves the problem with xsltproc and I am now able to build the 
docs.  Thanks for the fix.

Incidentally, the nav links are still present in the output.

Regards,
David

Re: [Refdb-devel] Build failure: HTML manual

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

Michael(tm) Smith writes:
 > Depending on whether that works or not, I'll then try swapping out
 > xsltproc and/or docbook-xsl versions to see if I can either break
 > it (if it's already working for) or get it working correctly. Then
 > I'll report back about where the problem appears to be.
 > 
 > I suspect it's in xsltproc/libxslt/libxml2, but we'll see.
 > 

Thanks for looking into this. However, I think the problem is caused
by a driver file bug (see my reply to David). xsltproc apparently used
to be too lenient to throw an error. A recent version may have
improved the tool, causing it to recognize the error properly. While
you're at it, please try and see whether the one-line patch I posted
fixes the problem if you manage to reproduce it.

regards,
Markus

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

Re: [Refdb-devel] Build failure: HTML manual

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

Hi David,

David Nebauer writes:
 > On the other hand, using xmllint to resolve xincludes before processing 
 > appears to be simplicity itself:
 >     xmllint --xinclude original.xml > resolved.xml
 > 

darn, I completely forgot about this workaround. Thanks for filling me
in. I managed to build the manual using Saxon, and presto - same error
as you report. The following one-line-fix in
doc/include/manual-xhtml.xsl fixes the problem with Saxon:


--- manual-xhtml.xsl    (revision 221)
+++ manual-xhtml.xsl    (working copy)
@@ -59,7 +59,7 @@
 
     <xsl:call-template name="subtoc">
       <xsl:with-param name="toc-context" select="$toc-context"/>
-      <xsl:with-param name="nodes" select="refsynopsisdiv | refsect1 | refsect2 | refsect3"/>
+      <xsl:with-param name="nodes" select="refsect1 | refsect2 | refsect3"/>
     </xsl:call-template>
     
   </xsl:template>


Could you please try whether this also fixes your build problem?

BTW it's not all milk and honey with Saxon after patching the driver
file. The navigation links generated by the docbook stylesheets are
missing, so you can't really move around, but I don't think that this
is caused by the driver file.

While trying to transform the manual with something else but xsltproc
I was actually using the commands that refdbxml would have
generated. This means that RefDB currently cannot handle documents
using xinclude unless you use xsltpoc. I guess we'll have to fix this
somehow. I'll peruse the links that you send to figure out a fix.

regards,
Markus

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

Re: [Refdb-devel] Build failure: HTML manual

[Michael(tm) S. <sm...@si...>]

Markus Hoenicka <mar...@mh...>, 2006-11-11 03:14 +0100:

> I wanted to transform the manual with a different xslt processor
> ... However, I'm apparently not up to this task:
>=20
> - Saxon by itself does not seem to understand Xincludes

Correct. I think you'd either need to:

  A. Add a pre-processing stemp step that first resolves the
     Xincludes before handing off the document to Saxon for the
     XSLT transformation.

  B. Configure Saxon to use a parser that is capable of resolving
     Xincludes

As far as B, I seem to remember hearing that Xerces can now
resolve Xincludes if you have it installed (perhaps along with
some extra jars from the Apache XML Commons) and have done some
config stuff to enable it.

As far as A, you can use "xmllint --xinclude foo.xml > bar.xml" to
generate a bar.xml from foo.xml with all Xincludes resolved. You
can then run Saxon on bar.xml.

> I spare you my usual rants about the state of XML tools compared to
> SGML tools. Is anyone out there able to transform the manual with
> anything else but xsltproc?

I've not tried yet, but I will attempt to and let you know.

I will also update my refdb working directory and try running the
transformation (in my Debian environment) with the default
makefile and see what happens.

Depending on whether that works or not, I'll then try swapping out
xsltproc and/or docbook-xsl versions to see if I can either break
it (if it's already working for) or get it working correctly. Then
I'll report back about where the problem appears to be.

I suspect it's in xsltproc/libxslt/libxml2, but we'll see.

  --Mike

Re: [Refdb-devel] Build failure: HTML manual

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

Hi Markus,
> I wanted to
> transform the manual with a different xslt processor (if the manual
> would cause a similar problem with a different processor on my system
> as well, I reckon the problem is with the driver file). However, I'm
> apparently not up to this task:
>
> - Saxon by itself does not seem to understand Xincludes
>
> - Saxon-Xerces does not fare any better
>
> - Xalan dies with an error


I found the following link gives a number of strategies for working 
around the incomplete implementation of xincludes in Saxon and Xalan:
    http://www.sagehill.net/docbookxsl/Xinclude.html#JavaXIncludes

The three strategies recommended are:
    - use Xerces
    - use xmllint as a preprocessor to resolve xincludes
    - use XIncluder as a preprocessor to resolve xincludes

When using xerces with Saxon or Xalan the Java command requires 
additional parameters.  Further parameters are needed if catalogs are 
used.  I have to say the Java commands required are god-awfully hideous.

There is a thread in the docbook-apps mailing list that addresses this 
issue.  It includes contributions from Bob Stayton and Dave Pawson.  
Since the thread navigation links on the site appear to be broken, here 
are the thread postings in chronological order:
    http://sources.redhat.com/ml/docbook-apps/2004-q1/msg00308.html
    http://sources.redhat.com/ml/docbook-apps/2004-q1/msg00312.html
    http://sources.redhat.com/ml/docbook-apps/2004-q1/msg00326.html
    http://sources.redhat.com/ml/docbook-apps/2004-q1/msg00328.html
    http://sources.redhat.com/ml/docbook-apps/2004-q1/msg00329.html

On the other hand, using xmllint to resolve xincludes before processing 
appears to be simplicity itself:
    xmllint --xinclude original.xml > resolved.xml

My apologies if you are already aware of this information.  Your email 
didn't specify exactly what strategies or commands you've tried.

Regards,
David.

Re: [Refdb-devel] Build failure: HTML manual

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

Hi David,

I agree with your analysis that the upgrade of the xsltproc/libxslt
packages are most likely the reason for the build failure. In order to
find out whether it is an xsltproc specific problem, I wanted to
transform the manual with a different xslt processor (if the manual
would cause a similar problem with a different processor on my system
as well, I reckon the problem is with the driver file). However, I'm
apparently not up to this task:

- Saxon by itself does not seem to understand Xincludes

- Saxon-Xerces does not fare any better

- Xalan dies with an error:

(Location of error unknown)XSLT Error
(javax.xml.transform.TransformerConfigurationException):
java.io.EOFException: no more input

I spare you my usual rants about the state of XML tools compared to
SGML tools. Is anyone out there able to transform the manual with
anything else but xsltproc?

regards,
Markus

David Nebauer writes:
 > Hi Markus,
 > > did you upgrade xsltproc (or libxslt) or the DocBook XSL stylesheets lately?
 > >
 > > In order to fix this, I'd like to know which of the packages changed on your
 > > system since the last time it worked.
 > 
 > 
 > It's difficult for me to provide this information.  I update my system 
 > from the Debian repository almost nightly and don't keep track of what 
 > changes occur or when.  I presume this information is stored somewhere 
 > in the package management system but, if so, I don't know how to 
 > retrieve it.
 > 
 > Here is the information I've been able to retrieve:
 > 
 > I last built refdb-svn (successfully) on 26 October.
 > 
 > The packages xsltproc and libxslt1.1 are both built from the same 
 > source.  According to both packages' changelog (extract follows) those 
 > packages were updated on 27 October or soon thereafter.
 > ------------------------------------------------------------------------------
 >  libxslt  (1.1.18-1) unstable; urgency=low
 > 
 >    * New upstream release:
 >      + Fixes xsl:variable with node sets. Closes: #381597.
 >      + Honors disable-output-escaping in xhtml 1.0 style element.
 >        Closes: #395210.
 >      + Supports XInclude processing on XSL stylesheets. Closes: #395210.
 >      + Correctly handles xsl:param names with namespaces. Closes: #389023.
 >    * debian/control:
 >      + Bumped Standards-Version to 3.7.2.2. No changes required.
 >      + Build depend on libxml2 >= 2.6.27, and adapt other dependencies
 >        accordingly.
 > 
 >  -- Mike Hommey <gla...@de...>  Fri, 27 Oct 2006 18:30:38 +0200
 > libxslt (1.1.17-5) unstable; urgency=low
 > 
 >    * xsltproc/xsltproc.c: Reverted patch to allow xsltproc to do XInclude
 >      processing. Closes: #389694. Reopens: #383408.
 > 
 >  -- Mike Hommey <gla...@de...>  Wed, 4 Oct 2006 16:57:08 +0200
 > ------------------------------------------------------------------------------
 > 
 > According to package docbook-xsl's changelog (extract follows) that 
 > package has not been updated since 26 October.
 > ------------------------------------------------------------------------------
 >  docbook-xsl  (1.71.0.dfsg.1-1.1) unstable; urgency=low
 > 
 >    * Non-maintainer upload.
 >    * Remove compatibility symlink in
 >      /usr/share/sgml/docbook/stylesheet/xsl/nwalsh and its parent 
 > directories
 >      on removal; closes: #393726.
 > 
 >  -- Loic Minier <lo...@do...>  Tue, 17 Oct 2006 22:26:46 +0200
 > ------------------------------------------------------------------------------
 > 
 > Perhaps changes to xsltproc/libxslt have resulted in the current HTML 
 > manual build problem.
 > 
 > Regards,
 > David.
 > 
 > 
 > -------------------------------------------------------------------------
 > Using Tomcat but need to do more? Need to support web services, security?
 > Get stuff done quickly with pre-integrated technology to make your job easier
 > Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo
 > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=120709&bid=263057&dat=121642
 > _______________________________________________
 > Refdb-devel mailing list
 > Ref...@li...
 > https://lists.sourceforge.net/lists/listinfo/refdb-devel
 > 

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

Re: [Refdb-devel] Build failure: HTML manual

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

Hi Markus,
> did you upgrade xsltproc (or libxslt) or the DocBook XSL stylesheets lately?
>
> In order to fix this, I'd like to know which of the packages changed on your
> system since the last time it worked.


It's difficult for me to provide this information.  I update my system 
from the Debian repository almost nightly and don't keep track of what 
changes occur or when.  I presume this information is stored somewhere 
in the package management system but, if so, I don't know how to 
retrieve it.

Here is the information I've been able to retrieve:

I last built refdb-svn (successfully) on 26 October.

The packages xsltproc and libxslt1.1 are both built from the same 
source.  According to both packages' changelog (extract follows) those 
packages were updated on 27 October or soon thereafter.
------------------------------------------------------------------------------
 libxslt  (1.1.18-1) unstable; urgency=low

   * New upstream release:
     + Fixes xsl:variable with node sets. Closes: #381597.
     + Honors disable-output-escaping in xhtml 1.0 style element.
       Closes: #395210.
     + Supports XInclude processing on XSL stylesheets. Closes: #395210.
     + Correctly handles xsl:param names with namespaces. Closes: #389023.
   * debian/control:
     + Bumped Standards-Version to 3.7.2.2. No changes required.
     + Build depend on libxml2 >= 2.6.27, and adapt other dependencies
       accordingly.

 -- Mike Hommey <gla...@de...>  Fri, 27 Oct 2006 18:30:38 +0200
libxslt (1.1.17-5) unstable; urgency=low

   * xsltproc/xsltproc.c: Reverted patch to allow xsltproc to do XInclude
     processing. Closes: #389694. Reopens: #383408.

 -- Mike Hommey <gla...@de...>  Wed, 4 Oct 2006 16:57:08 +0200
------------------------------------------------------------------------------

According to package docbook-xsl's changelog (extract follows) that 
package has not been updated since 26 October.
------------------------------------------------------------------------------
 docbook-xsl  (1.71.0.dfsg.1-1.1) unstable; urgency=low

   * Non-maintainer upload.
   * Remove compatibility symlink in
     /usr/share/sgml/docbook/stylesheet/xsl/nwalsh and its parent 
directories
     on removal; closes: #393726.

 -- Loic Minier <lo...@do...>  Tue, 17 Oct 2006 22:26:46 +0200
------------------------------------------------------------------------------

Perhaps changes to xsltproc/libxslt have resulted in the current HTML 
manual build problem.

Regards,
David.

Re: [Refdb-devel] Build failure: HTML manual

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

Markus Hoenicka <mar...@mh...> was heard to say:


> - my customization layer for the DocBook stylesheets relied on a
> bug/misfeature
> which was fixed in a new version of xsltproc. I've tweaked the stylesheets
> heavily to make the man pages appear like regular chapters in the table of
> contents. These tweaks may contribute to the problem.
>

please read that as:

may have relied ... may have been fixed

I have no positive proof that this was indeed the case, but it is possible.

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

Re: [Refdb-devel] Build failure: HTML manual

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

Hi David,

did you upgrade xsltproc (or libxslt) or the DocBook XSL stylesheets lately? I
don't think that your problems with the Java tools cause this problem as it is
xsltproc that fails. xsltproc is written in C.

I see a few possible reasons for the failure:

- a new version of xsltproc (or libxslt) may simply be broken

- my customization layer for the DocBook stylesheets relied on a bug/misfeature
which was fixed in a new version of xsltproc. I've tweaked the stylesheets
heavily to make the man pages appear like regular chapters in the table of
contents. These tweaks may contribute to the problem.

- The stylesheets were changed, and my customization layer no longer works

In order to fix this, I'd like to know which of the packages changed on your
system since the last time it worked.

regards,
Markus

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


> I assume this error is due to a change in the toolset rather than a
> change in refdb sources as there appear to have been changes made
> recently to underlying java libraries.  This became evident when I fixed
> another build error due to batik failing to convert svg to png.  The
> batik error was caused by an unsatisfied dependency -- either the
> dependent library (Attributes2.java) had been removed from an existing
> jarfile or the dependency is new.
>
> I'd appreciate some help in debugging this build failure as my
> understanding of xsl is tenuous at best.
>

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

[Refdb-devel] [ refdb-Bugs-1593786 ] Compilation fails on refdb-init-pgsql

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

Bugs item #1593786, was opened at 2006-11-09 23:13
Message generated for change (Comment added) made by mhoenicka
You can respond by visiting: 
https://sourceforge.net/tracker/?func=detail&atid=385991&aid=1593786&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: steletch (steletch)
Assigned to: Markus Hoenicka (mhoenicka)
Summary: Compilation fails on refdb-init-pgsql

Initial Comment:
Sorry to bother you again, but :

sed 's%/var/log%/var/log%' < ./refdb-init.in | \
        sed 's%/var/run%/var/run%' | \
        sed 's%<pkgdatadir>%/usr/share/refdb%' | \
        sed 's%<db_path>%/var/lib/lib/refdb/db%' | \
        sed 's%<main_db>%refdb%g' | \
        sed 's%<myshell>%/bin/bash%' | \
        sed 's%<psarg>%ax%' | \
        sed 's%<prefix>%/usr%' | \
        sed 's%<sysconfdir>%/etc/refdb%g' | \
        sed 's%<piddir>%/var/run%' > refdb-init
make[1]: *** No rule to make target `refdb-init-pgsql',
needed by `all-am'.  Stop.
make[1]: *** Waiting for unfinished jobs....
chmod a+x refdbctl
chmod a+x refdb-init
make[1]: Leaving directory
`/home/steletch/rpm/BUILD/refdb-0.9.8-pre7/scripts'
make: *** [all-recursive] Error 1


Seems we're going to another pre :-)

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

>Comment By: Markus Hoenicka (mhoenicka)
Date: 2006-11-10 12:15

Message:
Logged In: YES 
user_id=85809

I've removed refdb-init-pgsql as it is no longer required,
but it seems I didn't remove all references to it. This
problem is fixed in svn revision 221. An updated prerelease
(pre8) is available as well.

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

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

[Refdb-devel] Build failure: HTML manual

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

Hi Markus,

Revision 218 currently fails to build the HTML manual, reporting the 
following error:
-------------------------------------------------------------------------------------
Creating HTML manual...
rm -rf refdb-manual/*
mkdir -p refdb-manual && cp ../doc/manual.css ../doc/refdbmanualfig1.png 
../doc/refdbmanualfig2.png ../doc/refdbmanualfig3.png 
../doc/refdbmanualfig4.png ../doc/refdbmanualfig5.png refdb-manual/ && 
xsltproc -o refdb-manual/ --nonet --xinclude include/manual-xhtml.xsl 
refdb-manual.xml
runtime error: file 
file:///usr/share/xml/docbook/stylesheet/nwalsh/xhtml/autotoc.xsl line 
190 element apply-templates
The 'select' expression did not evaluate to a node set.
make[2]: *** [refdb-manual/*] Error 10
-------------------------------------------------------------------------------------

The relevant portion of the autotoc.xsl file is:
-------------------------------------------------------------------------------------
  <xsl:variable name="subtoc">
    <xsl:element name="{$toc.list.type}" 
namespace="http://www.w3.org/1999/xhtml">
      <xsl:apply-templates mode="toc" select="$nodes">
        <xsl:with-param name="toc-context" select="$toc-context"/>
      </xsl:apply-templates>
    </xsl:element>
  </xsl:variable>
-------------------------------------------------------------------------------------

The third line is the one generating the error.

I assume this error is due to a change in the toolset rather than a 
change in refdb sources as there appear to have been changes made 
recently to underlying java libraries.  This became evident when I fixed 
another build error due to batik failing to convert svg to png.  The 
batik error was caused by an unsatisfied dependency -- either the 
dependent library (Attributes2.java) had been removed from an existing 
jarfile or the dependency is new.

I'd appreciate some help in debugging this build failure as my 
understanding of xsl is tenuous at best.

Regards,
David.