refdb-devel — List for RefDB developers

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

[<ste...@jo...>]

David Nebauer a =E9crit :
> Hi Stephane,
>=20
>> Following your work, i'm not sure if packaging perl modules into an=20
>> obscure refdb-lib is a good option ...
>>
>> For instance in Mandriva, i've packaged refdb separately from those pe=
rl=20
>> modules since the perl modules themselves may be updated (and this can=
=20
>> be unrelated to refdb itself).
>=20
> I've packaged into refdb-lib only those perl libraries written by Marku=
s=20
> as adjuncts to refdb.  As such they are of no use to anyone outside the=
=20
> refdb project.  I do not quite understand your objection to packaging=20
> them as refdb-lib.
>=20
>> For example i've made perl-Term-Clui (lastly updated to 1.36), i suppo=
se=20
>> this separation is also correct for debian (as someone may need=20
>> perl-Term-Clui for another project): this will provide more feedback a=
nd=20
>> let you away from getting a refdb-lib trailing.
>=20
> Term::Clui has not yet been made an official Debian package (don't know=
=20
> why -- I love using it) so I packaged it as 'libperl-term-clui'.  It ha=
s=20
> been part of the 'release' and 'svn' repositories since 2005-09-10.  As=
=20
> soon as someone supplies an official debian package of it I'll remove m=
ine.
>=20
> Thanks for your feedback.
>=20
> Regards,
> David.

Ok, i've read too fast, i'll try to be clearer.
I think it would be consistent to name your package=20
libperl-refDB-perlmod instead of refdb-lib, to be in agreement with=20
debian policy (to tell the thrut, i don't know what is the correct=20
policy for perl modules in debian).

This is not very important, just a remark, though :-)

St=E9phane


--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

[<ste...@jo...>]

Markus Hoenicka a =E9crit :
> Hi,
>=20
> as far as I can see David has packaged only the RefDB::??? Perl modules=
,
> assuming that other modules like Term::Clui are available from other so=
urces.
> This basically satisfies your concerns about "usurping" non-RefDB code.

It was not a concern of "usurping" (since its GPL and i presume he had=20
mentionned the source). It is rather a concern of naming policy.
For instance for the rpm part, i made a perl-RefDB-perlmod sub-package,=20
like this it is coherent with the other disribution packets.

This was more the debian's consistency than an argument against some=20
misrespect ;-)

> However, I can't see that refdb-lib depends on Term::Clui (most likely =
because
> the latter does not seem to be available as a .deb). This would not pre=
vent the
> installation of the package, but it would cause the makestyle script to=
 fail.
>=20
> regards,
> Markus

Cheers,

St=E9phane
--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

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

Hi Markus,

> However, I can't see that refdb-lib depends on Term::Clui (most likely because
> the latter does not seem to be available as a .deb). This would not prevent the
> installation of the package, but it would cause the makestyle script to fail.

As I mentioned in another post, Term::Clui has been available as a deb 
(libperl-term-clui) in the refdb repositories for almost a year.  
Currently 'refdb-clients' declares a dependency on libperl-term-clui and 
refdb-clients thus forcing the installation of both packages.  I 
suppose, strictly speaking, since:
    refdb-ms (part of refdb-clients) requires
        RefDB::Makestyle (part of refdb-lib) which, in turn, requires
            Term::Clui (packaged as libperl-term-clui),
then the corresponding dependencies should be:
    refdb-clients depends on
        refdb-lib depends on
            libperl-term-clui.
I'll fix that dependency chain in the next svn refdb update.

Regards,
David.

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

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

Hi Stephane,

> Following your work, i'm not sure if packaging perl modules into an 
> obscure refdb-lib is a good option ...
>
> For instance in Mandriva, i've packaged refdb separately from those perl 
> modules since the perl modules themselves may be updated (and this can 
> be unrelated to refdb itself).

I've packaged into refdb-lib only those perl libraries written by Markus 
as adjuncts to refdb.  As such they are of no use to anyone outside the 
refdb project.  I do not quite understand your objection to packaging 
them as refdb-lib.

> For example i've made perl-Term-Clui (lastly updated to 1.36), i suppose 
> this separation is also correct for debian (as someone may need 
> perl-Term-Clui for another project): this will provide more feedback and 
> let you away from getting a refdb-lib trailing.

Term::Clui has not yet been made an official Debian package (don't know 
why -- I love using it) so I packaged it as 'libperl-term-clui'.  It has 
been part of the 'release' and 'svn' repositories since 2005-09-10.  As 
soon as someone supplies an official debian package of it I'll remove mine.

Thanks for your feedback.

Regards,
David.

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

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

Hi,

as far as I can see David has packaged only the RefDB::??? Perl modules,
assuming that other modules like Term::Clui are available from other sour=
ces.
This basically satisfies your concerns about "usurping" non-RefDB code.

However, I can't see that refdb-lib depends on Term::Clui (most likely be=
cause
the latter does not seem to be available as a .deb). This would not preve=
nt the
installation of the package, but it would cause the makestyle script to f=
ail.

regards,
Markus

St=E9phane T=E9letch=E9a <ste...@jo...> was heard to say:

> Following your work, i'm not sure if packaging perl modules into an
> obscure refdb-lib is a good option ...
>
> For instance in Mandriva, i've packaged refdb separately from those per=
l
> modules since the perl modules themselves may be updated (and this can
> be unrelated to refdb itself).
>
> For example i've made perl-Term-Clui (lastly updated to 1.36), i suppos=
e
> this separation is also correct for debian (as someone may need
> perl-Term-Clui for another project): this will provide more feedback an=
d
> let you away from getting a refdb-lib trailing.
>


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

Re: [Refdb-devel] RefDB-perlmod packaged as refdb-lib

[<ste...@jo...>]

David Nebauer a =E9crit :
> Hi Markus,
>=20
> I've packaged the RefDB-perlmod as refdb-lib.  I believe this now means=
=20
> refdb can be completely installed on a virgin machine using:
>      apt-get install refdb-clients refdb-server [refdb-doc]
> (provided, of course, the appropriate line is added to=20
> /etc/apt/sources.list).
>=20
> The packaging system is automated.  It actually draws from the svn=20
> repository and builds from those files rather than the archive you make=
=20
> available.  I don't track changes to perlmod/trunk/RefDB -- if you make=
=20
> changes to any of those perl libraries just let me know and I'll=20
> generate a new refdb-lib package.
>=20
> Regards,
> David.
>=20

Following your work, i'm not sure if packaging perl modules into an=20
obscure refdb-lib is a good option ...

For instance in Mandriva, i've packaged refdb separately from those perl=20
modules since the perl modules themselves may be updated (and this can=20
be unrelated to refdb itself).

For example i've made perl-Term-Clui (lastly updated to 1.36), i suppose=20
this separation is also correct for debian (as someone may need=20
perl-Term-Clui for another project): this will provide more feedback and=20
let you away from getting a refdb-lib trailing.

This post is just for comments, feel free to use it or not ;-)

Cheers,
St=E9phane

--=20
St=E9phane T=E9letch=E9a, PhD.                  http://www.steletch.org
Unit=E9 Math=E9matique Informatique et G=E9nome http://migale.jouy.inra.f=
r/mig
INRA, Domaine de Vilvert                  T=E9l : (33) 134 652 891
78352 Jouy-en-Josas cedex, France         Fax : (33) 134 652 901

Re: [Refdb-devel] Table support in current DocBook XSL stylesheets [was: Latin-1 character 160 (nbsp) in manpages]

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

Michael(tm) Smith wrote:
> The current version, 1.70.1, fully supports real table output
> using tbl(1) markup. See the attached example (refdbib.1).

The table output in the example looks stunningly good.

Regards,
David.

[Refdb-devel] Table support in current DocBook XSL stylesheets [was: Latin-1 character 160 (nbsp) in manpages]

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

Markus Hoenicka <mar...@mh...>, 2006-08-18 22:20 +0200:

> For the time being I've changed the driver file which RefDB uses to
> process the man pages.

That driver file should no longer be needed except for backward
compatibility with older versions of the DocBook XSL stylesheets.
The current version, 1.70.1, fully supports real table output
using tbl(1) markup. See the attached example (refdbib.1).

I've also attached a patch to the driver file. The patch causes
the driver to check the value of the DocBook XSL stylesheets
$VERSION param. If the middle part is 70 or greater, it uses the
table-processing code in the stylesheets as-is; otherwise, it
falls back to outputting the table rows in paragraphs.

  --Mike

[Refdb-devel] RefDB-perlmod packaged as refdb-lib

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

Hi Markus,

I've packaged the RefDB-perlmod as refdb-lib.  I believe this now means 
refdb can be completely installed on a virgin machine using:
     apt-get install refdb-clients refdb-server [refdb-doc]
(provided, of course, the appropriate line is added to 
/etc/apt/sources.list).

The packaging system is automated.  It actually draws from the svn 
repository and builds from those files rather than the archive you make 
available.  I don't track changes to perlmod/trunk/RefDB -- if you make 
changes to any of those perl libraries just let me know and I'll 
generate a new refdb-lib package.

Regards,
David.

[Refdb-devel] Changes to homepage

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

Hi Markus,

I've made some changes to homepage's 'install.html' page to reflect the 
new svn packages.

Incidentally, on my machine Firefox does not honour the css 'code' 
settings, displaying them in the same font as normal text.  I know of no 
local settings on my system that might cause this to happen.

Regards,
David.

[Refdb-devel] Latin-1 character 160 (nbsp) in manpages

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

Hi David,

David Nebauer writes:
 > ----------------------------------------------------------------------------
 > /usr/share/man/man1/refdbc.1:143: warning: can't find numbered character 160
 > /usr/share/man/man1/refdbc.1:143: warning: can't find numbered character 160
 > ----------------------------------------------------------------------------

I can't reproduce this problem over here. I've tried this on FreeBSD,
Cygwin, and Debian (testing) without getting warnings like this. I
wonder whether this is a localization issue.

In any case, the DocBook stylesheets indeed put the non-breaking space
where you see it, and they do so on purpose. Just have a look at the
manpages/charmap.groff.xsl file which contains the mapping of the
groff construct "\ " to the character #160.

For the time being I've changed the driver file which RefDB uses to
process the man pages.

 > You can see groff strips out the offending characters. Incidentally, the 
 > layout would look better if the table caption had its own line.
 > 

While I was at it, I also put the caption on a separate line. The only
downside is that the tables are not numbered. I don't think this is
going to cause problems as the tables are always rendered where they
belong.

 > I know I'm being picky here but an error is an error...
 > 

Actually it is a good sign if we have the time to ponder problems like
these. This means that the rest of the program is more or less working
ok.

regards,
Markus

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

[Refdb-devel] Latin-1 character 160 (nbsp) in manpages

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

Hi Markus,

The following manpages cause groff errors when they are being processed 
for display: refdbib, bib2ris, db2ris, en2ris, marc2ris, med2ris, 
refdbxml, refdba, refdbc and refdbd.

The error for refdbc is representative:
----------------------------------------------------------------------------
/usr/share/man/man1/refdbc.1:143: warning: can't find numbered character 160
/usr/share/man/man1/refdbc.1:143: warning: can't find numbered character 160
----------------------------------------------------------------------------

There are two Latin-1 characters 160 (non-breaking space) in line 143 of 
refdbc.1.

Line 143 is: 'Table 1. refdbcrc'.

The non-breaking spaces can be made visible by changing them to hashes:
-------------------------------------------------------------------------
<< first line proves there are no hash ('#') characters in manpage source >>
$ cat refdbc.1 | grep '#'
<< now transform non-breaking space to hash
david@hezmana:temp$ cat refdbc.1 | tr '\240' '#' | grep '#'
Table#1.#refdbcrc
$
-------------------------------------------------------------------------

The hashes show the location of the two non-breaking spaces.

In every case where this error occurs it is due to a table caption line 
similar to the one for refdbc.1.

These characters are not present in the xml source and are obviously 
introduced during the transformation of xml to groff.

On my xterm the relevant region of transformed groff input is displayed as:
-------------------------------------------------------------------------
...
refdbc evaluates the refdbcrc configuration file at startup to 
initialize it-
self. Table1.refdbcrc

| Variable | Default | Comment |
...
-------------------------------------------------------------------------

You can see groff strips out the offending characters. Incidentally, the 
layout would look better if the table caption had its own line.

I know I'm being picky here but an error is an error...

Regards,
David.

Re: [Refdb-devel] Docs in split packages

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

Markus Hoenicka wrote:
> Please give revision 126 a try. I've now checked in the relevant
> changes that address the server-only build problems.

Thanks, Marcus.  Revision 126 worked the charm.  All listed problems 
resolved.

Regards,
David.

Re: [Refdb-devel] Docs in split packages

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

David Nebauer writes:
 > All problems are still present building server+manpages from revision 
 > 125.

Please give revision 126 a try. I've now checked in the relevant
changes that address the server-only build problems.

regards,
Markus

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

Re: [Refdb-devel] Docs in split packages

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

Hi Markus,

> Is there any chance you could move to batik-rasterizer?

On debian batik is supplied as a library ('libbatik-java') with no 
binaries.  That's why the refdb configure check would always fail and 
switch to 'convert'.  Since it is a library there is no main executable 
class supplied.

After a moderate amount of googling (whatever did we do before it 
existed?) I've created my own 'batik-rasterizer' script which satisfies 
'configure' and successfully converts all the SVG files.

To try and help those who come after me, here is the 'batik-rasterizer' 
script for debian:

---------------------------------------------------------------------------------
#!/bin/sh

# Script: batik-rasterizer
# Date created: 2006-08-17
# Date last modified: 2006-08-17

# Function: Convert SVG images to PNG
#           Wrapper for Debian 'libbatik-java' package

# Credits:
#   David Nebauer
#     author
#   Petter Reinholdtsen
#     for the basic script posted as part of debian bug report 152180
#     accessible at 
<http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=152180>
#   Michael F. Lamb
#     for the tip on script security in his posting at
#     <http://blog.gmane.org/gmane.text.xml.batik.devel/day=20060403>


# VARIABLES

[ "${DESTDIR}" ] || DESTDIR=""
[ "${JAVA}" ]    || JAVA="java"                    # Java executable
XERCES="${DESTDIR}/usr/share/java/xercesImpl.jar"  # Xerces
BATIK="${DESTDIR}/usr/share/java/batik-all.jar"    # Batik
CLASSPATH="${XERCES}:${BATIK}"                     # Java classpath


# MAIN

${JAVA} \
    -cp ${CLASSPATH} \
    org.apache.batik.apps.rasterizer.Main \
    -scriptSecurityOff \
    $@
---------------------------------------------------------------------------------

Regards,
David.

Re: [Refdb-devel] latex bibliographies with multiple databases

[Damien J. D. <D.J...@cs...>]

> 
>>Incidentally, how do docbook users deal with this capitalisation 
>>issue? i.e. capitalisation of acronyms and proper nouns versus of 
>>subtitles and improper nouns. Anyone?
> 
> 
> The bibliography style options for TITLE are
>     case: ASIS ICAPS LOWER UPPER
>     style: BOLD BOLDITALIC BOLDITULINE BOLDULINE ITALIC ITULINE NONE SUB 
> SUPER ULINE
> 
> As you can see from the case options your only choice for preserving 
> mixed case is to use ASIS, which of course means "as is".  In that 
> situation it is up to the person inputting the reference in the first 
> place to get the case right.
> 
> Does that answer your question?

Yes, thank you. Since Docbook users get by without this extra markup I 
think we latex users should be able to get by without it too. I have no 
complaints. Though it seems logically possible, I doubt I will ever 
actually find an instance where anything more complicated than the above 
options is required.
Peace
Damien

Re: [Refdb-devel] Docs in split packages

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

Hi Markus,

Markus Hoenicka wrote:
> The "bizarre file content" is actually sort of a symlink emulation within the
> man page system.

Oops.  Thanks for the manpage tutorial.

Regards,
David.

Re: [Refdb-devel] Docs in split packages

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

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

> refdb.sh.1:
> ------------------------------------------------------------
> .so man8/refdb.8
> ------------------------------------------------------------
>
> Clearly the symlinks have morphed into bizarre file content.  There is
> no man8 directory.

The "bizarre file content" is actually sort of a symlink emulation within the
man page system. If a man page is to be available through more than one name,
you create one real man page (in this case man8/refdb.8) and put stub files
everywhere else. The ".so" command simply means to source the mentioned file.
This is equivalent to a symlink on the filesystem level.

regards,
Markus

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

Re: [Refdb-devel] Docs in split packages

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

Hi David,

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

> All problems are still present building server+manpages from revision
> 125.  To check whether it was a debian problem or a native build problem
> I built server+manpages from source and installed them to a dummy
> location.  Here's what happened in the native build (item numbers match
> those used above):
>

I'm awfully sorry. I had sent the messages yesterday before checking in the
relevant files. Sure enough there was an intermittent svn problem, so I could
not check in the files yesterday. I'll do it as soon as I get home from work.
Please try again in a couple of hours.

regards,
Markus

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

Re: [Refdb-devel] Docs in split packages

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

Hi Markus,

Markus Hoenicka wrote:
>  > 1.  Missing manpage symlink targets.
>  > 
>  > The following symlinks occur in man1:
>  >     refdb-init-pgsql.1 -> ../man8/refdb-init.8
>  >     refdb.sh.1 -> ../man8/refdb.8
>  > but there is no man8 directory at all.
>  > 
>  > 2.  Missing refdb-init manpage altogether.
>  > 
>  > There is no refdb-init manpage symlink in man1 and/or no equivalent in 
>  > man8 (since man8 is missing entirely.
>  > 
>
> These problems were due to an incorrect usage of an autoconf/automake
> trick. I've fixed that.
>
>  > 3.  Missing interpreter
>  > 
>  > The script refdbctl has no interpreter in its first line.  I note it is 
>  > the only one of the server-built scripts whose '.in' file uses the 
>  > '<myshell>' placeholder.
>  > 
>
> The interpreter check ran only if the clients were to be built. I've
> moved the check outside of the conditional, and the shell appears
> again.

All problems are still present building server+manpages from revision 
125.  To check whether it was a debian problem or a native build problem 
I built server+manpages from source and installed them to a dummy 
location.  Here's what happened in the native build (item numbers match 
those used above):

1.  Manpage symlinks

refdb-init-pgsql.1 and refdb.sh.1 are both present in man1 as regular 
files, not symlinks.  The problem is their content:

refdb-init-pgsql.1:
------------------------------------------------------------
.so man8/refdb-init.8
------------------------------------------------------------

refdb.sh.1:
------------------------------------------------------------
.so man8/refdb.8
------------------------------------------------------------

Clearly the symlinks have morphed into bizarre file content.  There is 
no man8 directory.


2.  refdb-init manpage

Still missing.


3.  Missing interpreter

Still missing.


Do these problems occur when building server+manpages on your boxen?

Regards,
David.

Re: [Refdb-devel] Docs in split packages

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

Hi David,

David Nebauer <dav...@sw...>:

> It's strange since convert works on all other SVG images.  Here's the
> version information:
>

I'm afraid this is a ImageMagick bug. I've checked the SVG file in question with
the online validator at http://jiggles.w3.org/svgvalidator/. All I see are error
messages about namespaces in attribute names, but no structural or other errors.
These error messages about namespaces also occur in all other RefDB SVG files.
All of them seem to work ok with your version of convert.

I've also installed the newest Inkscape version (0.44) on my Windoze box, opened
the file (created with 0.43-2), and saved it using a different name. The diff
does not show any substantial differences except version numbers and path
names. It does not look like an Inkscape bug either.

I don't know where to go from here. I don't want to break building the svn
packages on your system. Is there any chance you could move to a different
version of ImageMagick, or even to batik-rasterizer? Otherwise you could try
and remove one object after another from the image and check the results with
convert in order to see what breaks the conversion.

regards,
Markus

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

Re: [Refdb-devel] latex bibliographies with multiple databases

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

Hi Damien,

Damien Jade Duff wrote:

> Incidentally, how do docbook users deal with this capitalisation 
> issue? i.e. capitalisation of acronyms and proper nouns versus of 
> subtitles and improper nouns. Anyone?

The bibliography style options for TITLE are
    case: ASIS ICAPS LOWER UPPER
    style: BOLD BOLDITALIC BOLDITULINE BOLDULINE ITALIC ITULINE NONE SUB 
SUPER ULINE

As you can see from the case options your only choice for preserving 
mixed case is to use ASIS, which of course means "as is".  In that 
situation it is up to the person inputting the reference in the first 
place to get the case right.

Does that answer your question?

Regards,
David.

Re: [Refdb-devel] latex bibliographies with multiple databases

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

Hi David,

David Nebauer writes:
 > I'd like to focus on this point again.  I personally allow refdb to=20=

 > generate the citekey for me, mainly because it will automatically ap=
pend=20
 > 'a', 'b', etc. if there is danger of duplication.  Automatically=20
 > stripping non-ascii characters from authors with foreign characters =
will=20
 > lead to some unusual results.  A recent publication from our old=20
 > workhorse 'H=E4=DFler' might produce the citekey 'Hler2006'.
 >=20

I've tried to resolve this problem by running the citekeys through an
iconv conversion (from UTF-8 to ASCII with transliteration switched
on). Only then invalid characters are stripped from the strings. I
hope this will improve the automatically created citation keys.

iconv uses a latex-style transliteration of umlauts and other
non-ASCII characters. E.g. our beloved 'H=E4=DFler' is converted to
'H"assler'. RefDB has to strip the '"' from the latter as it must not
appear in XML attribute values, hence you'll end up with 'Hassler2006'
instead of the abovementioned 'Hler2006'. It is still not the correct
German transliteration, which would call for 'Haessler2006', but I
think we're close enough without having to hand-code a boatload of
special cases.


regards,
Markus

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

Re: [Refdb-devel] Docs in split packages

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

Hi David,

thanks always for your thorough tests.

David Nebauer writes:
 > 1.  Missing manpage symlink targets.
 > 
 > The following symlinks occur in man1:
 >     refdb-init-pgsql.1 -> ../man8/refdb-init.8
 >     refdb.sh.1 -> ../man8/refdb.8
 > but there is no man8 directory at all.
 > 
 > 2.  Missing refdb-init manpage altogether.
 > 
 > There is no refdb-init manpage symlink in man1 and/or no equivalent in 
 > man8 (since man8 is missing entirely.
 > 

These problems were due to an incorrect usage of an autoconf/automake
trick. I've fixed that.

 > 3.  Missing interpreter
 > 
 > The script refdbctl has no interpreter in its first line.  I note it is 
 > the only one of the server-built scripts whose '.in' file uses the 
 > '<myshell>' placeholder.
 > 

The interpreter check ran only if the clients were to be built. I've
moved the check outside of the conditional, and the shell appears
again.


regards,
Markus

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

Re: [Refdb-devel] Docs in split packages

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

Hi David,

David Nebauer writes:
 > Building documentation fails on conversion of refdbmanualfig5.svg:
 > -----------------------------------------------------------------
 > convert ../doc/refdbmanualfig5.svg ../doc/refdbmanualfig5.png
 > convert: unbalanced graphic context push-pop `graphic-context'.
 > make[2]: *** [../doc/refdbmanualfig5.png] Error 1
 > -----------------------------------------------------------------
 > 
 > You will see the build uses 'convert' as batik-rasteriser is 
 > unavailable.  I see you made some changes to that file in the last 48 
 > hours which have presumably caused this error to occur.  Unfortunately, 
 > ViewCVS is currently unable to show the changes made in that revision so 
 > I can't look for myself.
 > 

refdbmanualfig5.svg is a new file which I added a couple of days
ago. I can process it with batik-rasterizer without problems, and even
convert (from ImageMagick 6.2.2, 12/11/05 Q16) works ok. Which version
of convert do you use?

regards,
Markus

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