refdb-devel — List for RefDB developers

[Refdb-devel] CVS build failure - refdbd

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

Hi Markus,

I've still got that pesky build failure for refdb cvs.  It's occurring 
despite using libdbi 0.8.0 -- specifically, the debs I emailed you a 
little while ago.

I'm sending you the complete build log off list.

Regards,
David.

Re: [Refdb-devel] Makestyle (and other) changes

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

Hi David,

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

> Hi Markus,
>
> I've updated makestyle to match v.1.4 of citestylex.
>
> All my addons are now packaged as proper autotool-generated tarballs and
> Debian packages.
>

Thanks for this burst of activity.

> I've added tarballs and debs for MARC::Record and MARC::Charset to
> provide all perl dependencies for refdb in those formats.  The refdb deb
> suggests, rather then demands, them as the user may have installed them
> from perl sources.
>
> Some of the new packages are:
>
>     'refdb-makestyle' & 'libperl-refdb-makestyle':
>         provides makestyle
>
>     'vim-docbk-xml-refdb':
>         vim plugin for docbook xml and refdb
>
>     'refdb-cache' and 'libperl-refdb-cache':
>         provides a caching server for refdb (used by vim-docbk plugin)
>
>     'libperl-term-clui' and 'libperl-term-clui-fileselect':
>         provides perl module 'Term::Clui'
>
> The debs live under 'debian/' and the source tarballs live under 'source/'.
>

I'm probably asking the wrong persion, but would it be feasible to package the
Emacs refdb-mode once it is finished?

> In the next couple of days I'll amend the addons page and make an
> announcement to the list.
>
> I'm still not supplying a new cvs deb for refdb until the dependencies
> on libdbi are satisfied in debian testing.
>

libdbi is a stumbling block on Debian, unfortunately. The package maintainer
used to be the main libdbi author, but he jumped ship with the other maintainer
and basically left the project to me. I'm afraid the Debian packages won't be
updated unless we can convince someone else to grab maintainership. I'll try to
track down the kind souls who fixed the 0.7.1/2 packages in the wake of the
Sarge release, they might be able to help out.

regards,
Markus

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

[Refdb-devel] Makestyle (and other) changes

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

Hi Markus,

I've updated makestyle to match v.1.4 of citestylex.

All my addons are now packaged as proper autotool-generated tarballs and 
Debian packages.

I've added tarballs and debs for MARC::Record and MARC::Charset to 
provide all perl dependencies for refdb in those formats.  The refdb deb 
suggests, rather then demands, them as the user may have installed them 
from perl sources.

Some of the new packages are:

    'refdb-makestyle' & 'libperl-refdb-makestyle':
        provides makestyle

    'vim-docbk-xml-refdb':
        vim plugin for docbook xml and refdb

    'refdb-cache' and 'libperl-refdb-cache':
        provides a caching server for refdb (used by vim-docbk plugin)

    'libperl-term-clui' and 'libperl-term-clui-fileselect':
        provides perl module 'Term::Clui'

The debs live under 'debian/' and the source tarballs live under 'source/'.

In the next couple of days I'll amend the addons page and make an 
announcement to the list.

I'm still not supplying a new cvs deb for refdb until the dependencies 
on libdbi are satisfied in debian testing.

Regards,
David.

Re: [Refdb-devel] citestylex dtd: LINK element

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

Hi David,

yes this is correct. I've implemented support for multiple UR and L1-L4 entries
in response to a feature request. While I was at it I noticed that, like many
features in the RIS "spec", the link stuff was slapped together quite
carelessly. The UR and L1-L4 fields share exactly the same semantics and
processing expectations, therefore it seemed logical to me to use the same risx
element for all of them. I didn't announce this change yet as I'm not completely
done with testing, but I think I'll be able to make the missing checkins tonight
which will make the multiple URL support fully operational (rebuilding of your
databases required, as usual).

BTW I've also added a <ulink> element to the xnote.dtd which serves the same
purpose in extended notes.

regards,
Markus

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

> Hi Markus,
>
> I need to check on what's happening with the LINK element in
> citestylex.  I gather from the recent change to citestylex that LINK
> ROLE='0' maps to the ris tag URL.  Is this so?  If a bibliographic style
> includes
>
>     <LINK ROLE='0'>
>        <PRECEEDING>, </PRECEEDING>
>        <FOLLOWING></FOLLOWING>
>     </LINK>
>
> will this be replaced during processing with the contents of the ris URL
> field?
>


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

[Refdb-devel] citestylex dtd: LINK element

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

Hi Markus,

I need to check on what's happening with the LINK element in 
citestylex.  I gather from the recent change to citestylex that LINK 
ROLE='0' maps to the ris tag URL.  Is this so?  If a bibliographic style 
includes

    <LINK ROLE='0'>
       <PRECEEDING>, </PRECEEDING>
       <FOLLOWING></FOLLOWING>
    </LINK>

will this be replaced during processing with the contents of the ris URL 
field?

Regards,
David.

[Refdb-devel] Updated Vim support -- bad etiquette

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

Oops.  I had meant to send those last two messages to Markus' personal 
email address rather than the devel list.  They're rather large and I 
apologise to anyone who gets them.

Regards,
David.

[Refdb-devel] Updated Vim support

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

Hi Markus,

The current 'vimhelper.tar.gz' file available from the addons page 
provides support only for RIS editing in Vim.  It has a clunky 
installation mechanism that is, frankly, embarrassing.  I want to 
withdraw it.

I want, instead, to provide two new packages:


1. vim-ris

This provides support for RIS editing in Vim.  It is, effectively, the 
old vimhelper package.


2. vim-docbook-xml-refdb

This provides support for DocBook XML editing in Vim.  It includes RefDB 
support.


Both packages are available in two forms:
1. Autotools-generated tar.gz distributions (installed with ./configure 
&& make && make install), and
2. Debian packages (i386/Sarge).

I'll send you the relevant files for each in separate emails.

Regards,
David.

Re: [Refdb-devel] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

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

> There is one further problem: the 'dos2unix' script supplied with refdb
> is going to conflict with an executable of the same name supplied by the
> 'sysutils' package (actually, '/usr/bin/dos2unix' is a symlink to
> '/usr/bin/fromdos').  It was never a problem until now since refdb
> installed to '/usr/local/bin' while the sysutils version lives in
> '/usr/bin'.  Of course, since debian policy requires the debian version
> of refdb to install its scripts/binary files to '/usr/bin', the two
> files now clash.
>
> There are a number of possible solutions:
> 1. I can always remove the 'dos2unix' and 'dos2unix.in' files and
> manually strip out any related plumbing in the relevant make files,
> 2. The build system could check the OS and not install the file if it
> detects a debian OS, or
> 3. Rename the script.
>

The cleanest way is to rename the script. I guess there are quite a few
implementations of this kind of tool out there, all with the same name. Putting
a 'refdb_' in front of the filename should be all it takes to avoid conflicts.

regards,
Markus


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

Re: [Refdb-devel] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

Markus Hoenicka wrote:

>David Nebauer writes:
> > From what I have observed 
> > of other packages, however, the daemon script is usually copied to the 
> > /etc/init.d directory by the standard install process.  I presume this 
> > involves a simple one-line copy command inserted into one of the make 
> > files.  If you can show me where this command would go I would make the 
> > alteration to my debian build system which would result in the 
> > subsequent deb package copying the daemon to /etc/init.d.
> > 
>
>Ok, I think now I've got it. You need to maintain your own source
>branch with the modifications required to install it on Debian. The
>required changes should indeed be fairly easy. The most convenient
>mechanism is the "install-data-local" hook which allows you to install
>a file wherever you like.
>
Actually, this turned out to be far easier than I thought.  There is a 
script supplied as part of the debhelper package that automates the 
whole daemon init file install and link configuration.  Very nice.

> > I was thinking of something simpler and just for the Debian install: I'd 
> > wget the html manual files from the refdb website and add a copy command 
> > to the build process that would install them as part of the debian 
> > package install.
> > 
>
>Well, if that is kosher, I'll take my time with moving the manual to
>XML.
>
>The Makefile modification depends on whether the HTML files are
>already available or whether you want the Makefile to retrieve the
>files. Assuming the files are available locally (the paths are wild
>guesses as I'm away from my Debian test box):
>
>docfiles = $(wildcard *.html)
>[...]
>install-data-local:
>	$(mkinstalldirs) /usr/doc/refdb
>	@for f in $(docfiles); do \
>		$(INSTALL_DATA) $$f /usr/doc/refdb/$$f; \
>	done
>  
>
Once again, this is all handled by a single helper script.  Another 
script integrates the doc files with debian's integrated 
help/documentation system (doc-base/dwww).  If only the documentation 
was clearer I'd find this stuff out a lot faster...

There is one further problem: the 'dos2unix' script supplied with refdb 
is going to conflict with an executable of the same name supplied by the 
'sysutils' package (actually, '/usr/bin/dos2unix' is a symlink to 
'/usr/bin/fromdos').  It was never a problem until now since refdb 
installed to '/usr/local/bin' while the sysutils version lives in 
'/usr/bin'.  Of course, since debian policy requires the debian version 
of refdb to install its scripts/binary files to '/usr/bin', the two 
files now clash.

There are a number of possible solutions:
1. I can always remove the 'dos2unix' and 'dos2unix.in' files and 
manually strip out any related plumbing in the relevant make files,
2. The build system could check the OS and not install the file if it 
detects a debian OS, or
3. Rename the script.

Of course, there may be other alternatives I haven't thought of.

What do you think?

Regards,
David.

[Refdb-devel] Stayton links in manual

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

Hi David,

thanks for the pointer. I'll check the links asap.

regards,
Markus

David Nebauer writes:
 > Hi Markus,
 > 
 > Bob Stayton's "Docbook XSL: The Complete Guide" is now in it's third 
 > edition.  This is the edition on display at 
 > <http://www.sagehill.net/docbookxsl>.  I see you have the occasional 
 > link to that online book in the refdb manual.  It may be worth checking 
 > that none of them are broken.
 > 
 > Regards,
 > David.
 > 
 > 
 > -------------------------------------------------------
 > SF email is sponsored by - The IT Product Guide
 > Read honest & candid reviews on hundreds of IT Products from real users.
 > Discover which products truly live up to the hype. Start reading now.
 > http://ads.osdn.com/?ad_id=6595&alloc_id=14396&op=click
 > _______________________________________________
 > 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] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

David Nebauer writes:
 > Ah, I see how my choice of words misled you.  I did not want you to make 
 > an upstream change to the install process.  The change I want to make is 
 > only for the Debian install.  The packaging process involves building 
 > the application from source and so I would make the changes only to the 
 > local source tree I am creating the package from.  There are also pre- 
 > and post-install scripts.  The process of adding the links to the /etc 
 > tree is handled by the post-install script.  From what I have observed 
 > of other packages, however, the daemon script is usually copied to the 
 > /etc/init.d directory by the standard install process.  I presume this 
 > involves a simple one-line copy command inserted into one of the make 
 > files.  If you can show me where this command would go I would make the 
 > alteration to my debian build system which would result in the 
 > subsequent deb package copying the daemon to /etc/init.d.
 > 

Ok, I think now I've got it. You need to maintain your own source
branch with the modifications required to install it on Debian. The
required changes should indeed be fairly easy. The most convenient
mechanism is the "install-data-local" hook which allows you to install
a file wherever you like. The following modification of 
scripts/Makefile.am should do what you need to copy refdb to
/etc/init.d (untested, so please beware):

install-data-local:
	$(mkinstalldirs) $(DESTDIR)$(pkgdatadir)/sql
	@for f in $(sqlscripts); do \
		$(INSTALL_DATA) $$f $(DESTDIR)$(pkgdatadir)/sql/$$f; \
	done
	$(INSTALL_DATA) refdb /etc/init.d

Make sure that the leading whitespace of the command is a single
tab. Make is picky about this.

 > This would certainly accomplish the desired result.  Again, however, I 
 > was thinking of something simpler and just for the Debian install: I'd 
 > wget the html manual files from the refdb website and add a copy command 
 > to the build process that would install them as part of the debian 
 > package install.
 > 

Well, if that is kosher, I'll take my time with moving the manual to
XML.

The Makefile modification depends on whether the HTML files are
already available or whether you want the Makefile to retrieve the
files. Assuming the files are available locally (the paths are wild
guesses as I'm away from my Debian test box):

docfiles = $(wildcard *.html)
[...]
install-data-local:
	$(mkinstalldirs) /usr/doc/refdb
	@for f in $(docfiles); do \
		$(INSTALL_DATA) $$f /usr/doc/refdb/$$f; \
	done

 > >- What do libacl1 and libattr1 do?
 > >  
 > >
 > The Debian New Maintainers' Guide gives a couple of commands that 
 > analyse a configure file and extract/construct a list of dependencies:
 > 
 > strace -f -o /tmp/log ./configure
 > for x in `dpkg -S $(grep open /tmp/log|\
 >                       perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
 >                       grep "^/"| sort | uniq|\
 >                       grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
 >                       cut -f1 -d":"| sort | uniq`; \
 >         do \
 >           echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
 >         done
 > 
 > The two packages you queried were included in the output and I accepted 
 > the dependencies "on trust:.  The obvious test is to install refdb on a 
 > debian system lacking these packages and see whether it works.  This is 
 > not practicable as half the system packages depend on these two, either 
 > directly or indirectly.  Since most systems will have these two packages 
 > installed anyway I saw little harm in leaving them in the dependency list.
 > 

Don't take me wrong. I had never heard of these packages, so I was
simply curious what might have caused the dependency. If it is a
Debian peculiarity, it is nothing to worry about for me.

Let me know if you need more specific instructions.

regards,
Markus

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

[Refdb-devel] Stayton links in manual

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

Hi Markus,

Bob Stayton's "Docbook XSL: The Complete Guide" is now in it's third 
edition.  This is the edition on display at 
<http://www.sagehill.net/docbookxsl>.  I see you have the occasional 
link to that online book in the refdb manual.  It may be worth checking 
that none of them are broken.

Regards,
David.

Re: [Refdb-devel] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

Markus Hoenicka wrote:

>David Nebauer writes:
> > Two things I'd like the Debian install process to do that don't happen 
> > in the current standard install are:
> > 
> > 1.  Install the refdb daemon. 
>
>I'm not sure whether installing a daemon should be part of the regular
>installation process of a tarball. Daemon installation is all too
>OS-dependent. On the BSD's you'd have to use /usr/local/etc/rc.d/ and
>rename refdb to refdb.sh, on Windows you have to use a special tool
>called cygrunsrv to install refdbd as a service (refdb is not involved
>at all), and hell knows how this might work on OSX. If you install
>RefDB with the current build process, it is ready to run from the
>command line. Everything else should be handled by the OS-specific
>port or package code. I'm sure the Debian package system provides a
>way to run something like an install script after the
>autotools-controlled installation.
>  
>
Ah, I see how my choice of words misled you.  I did not want you to make 
an upstream change to the install process.  The change I want to make is 
only for the Debian install.  The packaging process involves building 
the application from source and so I would make the changes only to the 
local source tree I am creating the package from.  There are also pre- 
and post-install scripts.  The process of adding the links to the /etc 
tree is handled by the post-install script.  From what I have observed 
of other packages, however, the daemon script is usually copied to the 
/etc/init.d directory by the standard install process.  I presume this 
involves a simple one-line copy command inserted into one of the make 
files.  If you can show me where this command would go I would make the 
alteration to my debian build system which would result in the 
subsequent deb package copying the daemon to /etc/init.d.

> > 2.  Copy a html version of the manual to debian's document system.  What 
> > changes would be required to accomplish this?
> > 
>
>You've found a weak spot that I hoped no one would ever notice. The
>documentation is not integrated into the build process so far. I think
>about moving the documentation over to DocBook XML and use xsltproc to
>transform it. This would not create additional dependencies as we need
>xsltproc and the DocBook stylesheets anyway. In that case, "make
>install" would put the docs into a directory which would be customizable
>with another configure switch.
>  
>
This would certainly accomplish the desired result.  Again, however, I 
was thinking of something simpler and just for the Debian install: I'd 
wget the html manual files from the refdb website and add a copy command 
to the build process that would install them as part of the debian 
package install.

> > Here are some of the components of the Debian install process as I've so 
> > far designed it.  Please feel free to comment on any changes you think 
> > advisable:
> > 
> > Dependencies:
> > docbook-xsl (>= 1.66.1-1), libacl1 (>= 2.2.23-1), libattr1 (>= 
> > 2.4.16-1), libexpat1 (>= 1.95.8-1), libreadline4-dev (>= 4.3-11), 
> > libxml2 (>= 2.6.16-3), libxml2-utils (>=2.6.16-3), libxml-parser-perl 
> > (>= 2.34-4), zlib1g (>= 1), libdbi0-dev (>= 0.7.2-1), sqlite 
> > (>=2.8.16-1), libdbd-sqlite (>=0.7.1-2), sgml-data (>=2.0.2)
> > 
>
>- What do libacl1 and libattr1 do?
>  
>
The Debian New Maintainers' Guide gives a couple of commands that 
analyse a configure file and extract/construct a list of dependencies:

strace -f -o /tmp/log ./configure
for x in `dpkg -S $(grep open /tmp/log|\
                      perl -pe 's!.* open\(\"([^\"]*).*!$1!' |\
                      grep "^/"| sort | uniq|\
                      grep -v "^\(/tmp\|/dev\|/proc\)" ) 2>/dev/null|\
                      cut -f1 -d":"| sort | uniq`; \
        do \
          echo -n "$x (>=" `dpkg -s $x|grep ^Version|cut -f2 -d":"` "), "; \
        done

The two packages you queried were included in the output and I accepted 
the dependencies "on trust:.  The obvious test is to install refdb on a 
debian system lacking these packages and see whether it works.  This is 
not practicable as half the system packages depend on these two, either 
directly or indirectly.  Since most systems will have these two packages 
installed anyway I saw little harm in leaving them in the dependency list.

>- libxml-parser-perl required for?
>  
>
It provides the perl module 'XML::Parser'.  As the import filter perl 
module dependencies are optional I have moved it to the suggested 
package list.

>- I don't see xsltproc and/or libxslt here?
>  
>
Quite simply an error on my part.  Since 'xsltproc' depends on 
'libxslt1.1' only the former is required.

>- isn't libdbi0 required as well to run the drivers?
>  
>
If you look more closely you'll see that libdbi0-dev is listed as a 
dependency.  It depends on libdbi0 and so the latter becomes an indirect 
dependency.

As mentioned above, any pointers on how to adjust the build system to 
copy the daemon and help files would be appreciated.

Regards,
David.

[Refdb-devel] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

David Nebauer writes:
 > Two things I'd like the Debian install process to do that don't happen 
 > in the current standard install are:
 > 
 > 1.  Install the refdb daemon as well as the relevant links to in the 
 > /etc/init.d|rc?.d tree.  The links are easy to create using the 
 > 'update-rc.d' tool.  What I'd like the make system to handle is the 
 > copying of 'refdb' to '/etc/init.d' and ensuring it has the proper 
 > permissions -- what changes would be required to do this?
 > 

I'm not sure whether installing a daemon should be part of the regular
installation process of a tarball. Daemon installation is all too
OS-dependent. On the BSD's you'd have to use /usr/local/etc/rc.d/ and
rename refdb to refdb.sh, on Windows you have to use a special tool
called cygrunsrv to install refdbd as a service (refdb is not involved
at all), and hell knows how this might work on OSX. If you install
RefDB with the current build process, it is ready to run from the
command line. Everything else should be handled by the OS-specific
port or package code. I'm sure the Debian package system provides a
way to run something like an install script after the
autotools-controlled installation.

 > 2.  Copy a html version of the manual to debian's document system.  What 
 > changes would be required to accomplish this?
 > 

You've found a weak spot that I hoped no one would ever notice. The
documentation is not integrated into the build process so far. I think
about moving the documentation over to DocBook XML and use xsltproc to
transform it. This would not create additional dependencies as we need
xsltproc and the DocBook stylesheets anyway. In that case, "make
install" would put the docs into a directory which would be customizable
with another configure switch.

 > Here are some of the components of the Debian install process as I've so 
 > far designed it.  Please feel free to comment on any changes you think 
 > advisable:
 > 
 > Dependencies:
 > docbook-xsl (>= 1.66.1-1), libacl1 (>= 2.2.23-1), libattr1 (>= 
 > 2.4.16-1), libexpat1 (>= 1.95.8-1), libreadline4-dev (>= 4.3-11), 
 > libxml2 (>= 2.6.16-3), libxml2-utils (>=2.6.16-3), libxml-parser-perl 
 > (>= 2.34-4), zlib1g (>= 1), libdbi0-dev (>= 0.7.2-1), sqlite 
 > (>=2.8.16-1), libdbd-sqlite (>=0.7.1-2), sgml-data (>=2.0.2)
 > 

- What do libacl1 and libattr1 do?
- libxml-parser-perl required for?
- I don't see xsltproc and/or libxslt here?
- isn't libdbi0 required as well to run the drivers?

The remainder looks ok to me. Thanks a lot for tackling this.

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

[Refdb-devel] Re: [Refdb-users] ANN: RefDB RPM packages pulled, packagers wanted

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

Markus Hoenicka wrote:

>David Nebauer writes:
> > If there have been no takers for this, I'll have a stab at it.
>

I'm finding this a rather challenging project.  The build process for 
RefDB is complex and difficult to unravel -- at least for someone with 
my rudimentary knowledge of the GNU build process.

Two things I'd like the Debian install process to do that don't happen 
in the current standard install are:

1.  Install the refdb daemon as well as the relevant links to in the 
/etc/init.d|rc?.d tree.  The links are easy to create using the 
'update-rc.d' tool.  What I'd like the make system to handle is the 
copying of 'refdb' to '/etc/init.d' and ensuring it has the proper 
permissions -- what changes would be required to do this?

2.  Copy a html version of the manual to debian's document system.  What 
changes would be required to accomplish this?

Here are some of the components of the Debian install process as I've so 
far designed it.  Please feel free to comment on any changes you think 
advisable:

Dependencies:
docbook-xsl (>= 1.66.1-1), libacl1 (>= 2.2.23-1), libattr1 (>= 
2.4.16-1), libexpat1 (>= 1.95.8-1), libreadline4-dev (>= 4.3-11), 
libxml2 (>= 2.6.16-3), libxml2-utils (>=2.6.16-3), libxml-parser-perl 
(>= 2.34-4), zlib1g (>= 1), libdbi0-dev (>= 0.7.2-1), sqlite 
(>=2.8.16-1), libdbd-sqlite (>=0.7.1-2), sgml-data (>=2.0.2)

Suggested packages:
libtext-iconv-perl (>=1.2-3), libbtparse0 (>=0.34-1), libdbd-mysql 
(>=0.7.1-2), libdbd-pgsql (>=0.7.1-2)

One line description (hard limit 80 chars, recommended size < 60 chars):
reference database and bibliography tool for structured documents

Long description:
 RefDB is a reference database and bibliography tool for SGML,
 XML and LaTeX/BibTeX documents. It allows users to share
 databases over a network.
 .
 RefDB appears to be the only available tool to create HTML,
 PostScript, PDF, DVI, MIF, or RTF output from DocBook or
 TEI sources with fully formatted citations and bibliographies
 according to publisher's specifications. Additional document
 types can be easily added.

Copyright file (format is that recommended by debian manual):
.....................................................................................
This package was debianized by David Nebauer <da...@ne...> on
Sat, 26 Feb 2005 18:26:08 +0930.

It was downloaded from 
<http://refdb.sourceforge.net/pre/refdb-latest.tar.gz>.

Copyright:
This software is copyright (c) 2004 by Markus Hoenicka 
<mho...@us...>.

Upstream Author:
Markus Hoenicka <mho...@us...>.

License:
This software is released under the GNU General Public License.
The full text of this license can be found via internet at 
<http://www.gnu.org/copyleft/gpl.html> and on Debian systems at 
</usr/share/common-licenses/GPL>.
.....................................................................................

Configure command from 'rules' file:
    CFLAGS="$(CFLAGS)" ./configure --host=$(DEB_HOST_GNU_TYPE) 
--build=$(DEB_BUILD_GNU_TYPE) --prefix=/usr 
--mandir=\$${prefix}/share/man --infodir=\$${prefix}/share/info 
--sysconfdir=/etc --sharedstatedir=/var --localstatedir=/var 
--with-classpath-root=/usr/share/java --with-db-server=sqlite 
--with-xml-declaration=/usr/share/xml/declaration/xml.dcl

README.Debian file:
.....................................................................................
refdb for Debian
----------------

RefDB is highly configurable during its build process.  Here are the 
possible configure options (as per the source tree's './configure 
--help' command):

------------------------------------------------------------------------
Defaults for the options are specified in brackets.

Configuration:
  -h, --help              display this help and exit
      --help=short        display options specific to this package
      --help=recursive    display the short help of all the included 
packages
  -V, --version           display version information and exit
  -q, --quiet, --silent   do not print `checking...' messages
      --cache-file=FILE   cache test results in FILE [disabled]
  -C, --config-cache      alias for `--cache-file=config.cache'
  -n, --no-create         do not create output files
      --srcdir=DIR        find the sources in DIR [configure dir or `..']

Installation directories:
  --prefix=PREFIX         install architecture-independent files in PREFIX
                          [/usr/local]
  --exec-prefix=EPREFIX   install architecture-dependent files in EPREFIX
                          [PREFIX]

By default, `make install' will install all the files in
`/usr/local/bin', `/usr/local/lib' etc.  You can specify
an installation prefix other than `/usr/local' using `--prefix',
for instance `--prefix=$HOME'.

For better control, use the options below.

Fine tuning of the installation directories:
  --bindir=DIR           user executables [EPREFIX/bin]
  --sbindir=DIR          system admin executables [EPREFIX/sbin]
  --libexecdir=DIR       program executables [EPREFIX/libexec]
  --datadir=DIR          read-only architecture-independent data 
[PREFIX/share]
  --sysconfdir=DIR       read-only single-machine data [PREFIX/etc]
  --sharedstatedir=DIR   modifiable architecture-independent data 
[PREFIX/com]
  --localstatedir=DIR    modifiable single-machine data [PREFIX/var]
  --libdir=DIR           object code libraries [EPREFIX/lib]
  --includedir=DIR       C header files [PREFIX/include]
  --oldincludedir=DIR    C header files for non-gcc [/usr/include]
  --infodir=DIR          info documentation [PREFIX/info]
  --mandir=DIR           man documentation [PREFIX/man]

Program names:
  --program-prefix=PREFIX            prepend PREFIX to installed program 
names
  --program-suffix=SUFFIX            append SUFFIX to installed program 
names
  --program-transform-name=PROGRAM   run sed PROGRAM on installed 
program names

System types:
  --build=BUILD     configure for building on BUILD [guessed]
  --host=HOST       cross-compile to build programs to run on HOST [BUILD]

Optional Features:
  --disable-FEATURE       do not include FEATURE (same as 
--enable-FEATURE=no)
  --enable-FEATURE[=ARG]  include FEATURE [ARG=yes]
  --disable-dependency-tracking Speeds up one-time builds
  --enable-dependency-tracking  Do not reject slow dependency extractors
  --disable-server          Exclude server.
  --disable-clients          Exclude clients.
  --disable-rpath         do not hardcode runtime library paths

Optional Packages:
  --with-PACKAGE[=ARG]    use PACKAGE [ARG=yes]
  --without-PACKAGE       do not use PACKAGE (same as --with-PACKAGE=no)
  --with-libdbi-lib=DIR         Find libdbi lib in DIR
  --with-expat-lib=DIR          Find expat lib in DIR
  --with-btparse-lib=DIR        Find btparse lib in DIR
  --with-sgml-declaration=PATH  Use this file as SGML declaration
  --with-xml-declaration=PATH   Use this file as XML declaration
  --with-docbook-xsl=PATH       Path to the DocBook XSL stylesheet root
  --with-tei-xsl=PATH           Path to the TEI XSL stylesheet root
  --with-classpath-root=PATH    Path to a Java class repository for XSL 
processors
  --with-refdb-url=URL          Root URL for the web interface HTML files
  --with-var-dir=PATH           Path of a directory for PID files
  --with-log-dir=PATH           Path of a directory for log files
  --with-main-db=name           The name of the RefDB system database
  --with-db-server=DBS          Preconfigure for sqlite (default), 
pgsql, or mysql
  --with-trang-jar=PATH  specify the full path to trang
  --with-gnu-ld           assume the C compiler uses GNU ld default=no
  --with-libiconv-prefix[=DIR]  search for libiconv in DIR/include and 
DIR/lib
  --without-libiconv-prefix     don't search for libiconv in includedir 
and libdir
------------------------------------------------------------------------

This debian package of RefDB was compiled with the following options:
--prefix=/usr
--mandir=/usr/share/man
--infodir=/usr/share/info
--sysconfdir=/etc
--sharedstatedir=/var
--localstatedir=/var
--with-classpath-root=/usr/share/java
--with-db-server=sqlite
--with-xml-declaration=/usr/share/xml/declaration/xml.dcl

Please note the following:
1. The database server selected is SQLite.  This choice can be 
overridden by setting the 'dbserver' variable in your local 
(~/.refdbdrc) or global (/etc/refdb/refdbdrc) refdbd configuration file.
2. RefDB uses 'xmlcatalog' to locate xml files.  According to debian 
policy, "update-xmlcatalog is the de-facto standard tool to be used to 
maintain XML catalog files on a Debian system" and "update-xmlcatalog 
and xmlcatalog(1) are incompatible" (see 'update-xmlcatalog' man page).  
Closer examination of the policy, however, reveals that the main concern 
is adding to and deleting from catalogs using these tools.  On my 
interpretation, using 'xmlcatalog' to query catalogs does not violate 
debian policy.
3. The '--with-docbook-xsl' option is omitted on the assumption that 
RefDB can use catalogs to locate it.  This should be the case with 
standard installs of the 'docbook-xsl' package.

 -- David Nebauer <da...@ne...>, Sat, 26 Feb 2005 18:26:08 +0930
.....................................................................................

Regards,
David.

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

Markus Hoenicka wrote:

>I almost beat myself this time. The acinclude.m4 patch has already been applied
>to HEAD two months ago. I just forgot to update configure.in as well. I've done
>this now, and HEAD configures and builds ok (modulo a few warnings which you
>can ignore) on Cygwin using automake 1.9.2. I'd appreciate if you could verify
>this on Linux too.
>

Works with 1.9 just fine now.

Regards,
David.

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

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

> Markus Hoenicka wrote:
>
> >Ok, then I think I know what I'll have to do. I've fixed these version
> >issues in the stable branch when I upgraded myself. All I have to do
> >is to dig out these patches and apply them to HEAD.
> >
>
> When you do I'll re-test using 1.9.
>

I almost beat myself this time. The acinclude.m4 patch has already been applied
to HEAD two months ago. I just forgot to update configure.in as well. I've done
this now, and HEAD configures and builds ok (modulo a few warnings which you
can ignore) on Cygwin using automake 1.9.2. I'd appreciate if you could verify
this on Linux too.

regards,
Markus

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

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

Markus Hoenicka wrote:

>Ok, then I think I know what I'll have to do. I've fixed these version
>issues in the stable branch when I upgraded myself. All I have to do
>is to dig out these patches and apply them to HEAD.
>

When you do I'll re-test using 1.9.

Regards,
David.

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

David Nebauer writes:
 > That was well-spotted.  I had automatically upgraded to automake1.9 
 > (version 1.9.4-1) when it became available.  Reverting to automake1.8 
 > (version 1.8.5-3) enabled refdb HEAD to build successfully.
 > 

Ok, then I think I know what I'll have to do. I've fixed these version
issues in the stable branch when I upgraded myself. All I have to do
is to dig out these patches and apply them to HEAD.

regards,
Markus

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

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

Markus Hoenicka wrote:

>David Nebauer writes:
> > This error occurred while using the 'refdb-cvs' script, so you can look 
> > in there to see the sequence of commands: './autogen.sh' (line 356) is 
> > executed before the configure step (line 392).
> > 
>
>I see. Actually I got one thing wrong in my previous reply. It is
>automake, not autoconf, which generates the Makefile.in from
>Makefile.am. What happens if you run automake manually? Which version
>is this anyway (automake --version)? Do you have several versions
>installed? If yes, does an older version work?
>
> > >
> > If it's a Linux-specific thing I'll do what I can to help track the 
> > problem down.
> > 
>
>I don't think so. Automake's sole purpose is to be and to make things
>platform-independent. I'd rather think it could be a version
>problem. Newer autotools added a few restrictions which could break
>older code.
>  
>
That was well-spotted.  I had automatically upgraded to automake1.9 
(version 1.9.4-1) when it became available.  Reverting to automake1.8 
(version 1.8.5-3) enabled refdb HEAD to build successfully.

Problem solved!

Thanks,
David.

Re: [Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

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

> config.status: error: cannot find input file: src/Makefile.in
> >

Do you run ./autogen.sh between downloading from CVS and running configure?
autoconf generates Makefile.in from Makefile.am. It is not a distributed file.

> I recommend refdb HEAD should be maintained in a buildable form even if
> you caution against anyone actually using it.  That way refdb-cvs will
> continue to work for new users.
>

I absolutely agree. If running autogen.sh does not fix the problem, I'll have to
see what went wrong. I know that HEAD built correctly on FreeBSD last time I
tried.

regards,
Markus

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

[Refdb-devel] refdb-cvs relies on buildable MAIN branch

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

Hi Markus,

I noticed today the MAIN/HEAD branch of refdb fails to configure:

..................................................................................................
<elision/>
checking for /teixsl-fo/tei.xsl... no
TEI XSL stylesheets ***NOT*** found
checking for Perl version... 5.008004
checking for Perl module RefDB::Prefs... RefDB::Prefs
checking for Perl module XML::Parser... XML::Parser
checking for Perl module MARC::Record... configure: WARNING: Perl module 
MARC::Record is required for some scripts

checking for Perl module MARC::Charset... configure: WARNING: Perl 
module MARC::Charset is required for some scripts

checking for Perl module Text::Iconv... Text::Iconv
configure: creating ./config.status
config.status: error: cannot find input file: src/Makefile.in
..................................................................................................

Before you point out, correctly, that users should use 
Release_0_9_5_stable, let me explain why it matters for the 'refdb-cvs' 
script.  The script initially downloads and builds the HEAD branch.  Its 
final act before exiting is to advise the user to change branches to a 
stable branch.  The reason it works this way is that I could not find a 
"generic" way for the script (actually, the 'cvs' program) to discover 
the available branches of refdb until it had actually installed a cvs 
source tree.  To "future-proof" the script I decided the initial, 
default, install should be the HEAD branch instead of 
Release_0_9_5_stable -- that way the script would not need changing if 
you decided to change development to another branch from 
Release_0_9_5_stable.

Unfortunately, the HEAD install fails at the configure stage.  Users do 
not get a working refdb installation and they don't get to see the 
message advising them to change branches.

I recommend refdb HEAD should be maintained in a buildable form even if 
you caution against anyone actually using it.  That way refdb-cvs will 
continue to work for new users.

Regards,
David.

Re: [Refdb-devel] refdb-backup portability and design

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

Markus Hoenicka writes:
 > [ "${backup_dir:0:1}" != "/" ] && \
 > 
 > Can you work around this?
 > 

ok, while we're at it... For testing purposes I asked bash to run the
script and bumped into another portability issue. This time it's the
mktemp implementations. On the BSDs, mktemp expects either a filename
pattern or a prefix to construct the filename. Calling it without an
argument doesn't work. The following examples are from the FreeBSD
mktemp man page and show the two usages allowed here:

 TMPFILE=`mktemp /tmp/${tempfoo}.XXXXXX`

The 'X'es will be replaced by characters to make the name unique.

 tempfoo=`basename $0`
 TMPFILE=`mktemp -t ${tempfoo}`

The value of ${tempfoo} will be used as a prefix for the unique
filename.

Does Linux support one of these usages?

regards,
Markus

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

Re: [Refdb-devel] refdb-backup portability and design

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

David Nebauer writes:
 > The bash-specific constructs you identified (select, cut long options) 
 > have been removed/fixed.
 > 

I'm afraid you've introduced another bash-ism while removing the
others. The following substitution is not supported by BSD sh (line
139 of refdb-backup):

[ "${backup_dir:0:1}" != "/" ] && \

Can you work around this?

regards,
Markus

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

Re: [Refdb-devel] refdb-backup portability and design

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

Hi Markus,

>There were two portability issues:
>
>- cut does not understand the long options on many platforms. It is
>  better to use something like cut -d ' ' -f 1.
>
>- select is a bash feature. Although you use #!/bin/sh at the top,
>  you'll actually run bash on Linux (try ls -al /bin/sh). The BSDs
>  have a real sh which is different from bash. Therefore I have to
>  ask for bash explicitly in the shebang on FreeBSD.
>
>Another, more general problem is that I see a great potential of this
>script to run backups automatically. I'd like to define a cron job
>that runs this script once a week or so. For this to work we'd need a
>way to pass parameters on the command line instead of an interactive
>interface.
>
>Therefore I'd suggest to use getopt or getopts to read the required
>user input from the command line. getopt is a standalone POSIX
>utility, could be used from sh, and should be available on all
>platforms. On the other hand, getopts is a bash builtin and simpler to
>use.
>
>I can handle the getopts/bash stuff if you agree. Let me know what you
>think.
>
I've checked in new versions of the utilities.  There are some major 
alterations which should alleviate most of your concerns.

There is now no user interactivity -- all input is via command line 
arguments (handled by getopts).  Username and password are now accepted 
as arguments and these are passed through to all refdba and refdbc commands.

The bash-specific constructs you identified (select, cut long options) 
have been removed/fixed.

One of the barriers to automating these utilities was the need for 
refdb-backup to run in a blank directory.  Both utilities now use 
temporary directories (courtesy of 'mktemp').

Previously the archive was created in the run directory -- users can now 
supply the target directory for archive creation via a command line 
argument.

The scripts now check for refdba|c access before running.  The restore 
script no longer generates a log file.

Please give this version a hammering to make sure I covered all possible 
error states.

While I've cleaned up some portability issues I may have introduced others!

Regards,
David.