BUG: xmlto fails to build git-core manpages

[namely_void@…]

Gives to following error with "port install git-core +doc" with the latest 1.2.1 git-core:

asciidoc -b docbook -d manpage -f asciidoc.conf git-add.txt xmlto man git-add.xml I/O error : Attempt to load network entity  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity " http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" cannot parse  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl Variable $SGML_CATALOG_FILES not set I/O error : Attempt to load network entity  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl warning: failed to load external entity " http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" cannot parse  http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl asciidoc -b docbook -d manpage -f asciidoc.conf git-am.txt ...

So maybe there's some builtin directory var that needs patching.

[olegb@…]

assigning to maintainer

[blb@…]

Sorry about the delay, this bug seems to have slipped through the cracks...

Is that XSL file not easily retrievable from your system, it loads okay here?

[namely_void@…]

I can retrieve the " http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl" using curl or wget just fine...but the error, when trying to build git-core, remains the same. I also tried building git (make all doc) on gentoo/linux (same box) and there it went ok. I suppose xmlto should use its own (or some dependency's) version of docbook.xsl instead of trying to retrieve it from the net. Maybe gentoo's ebuild for xmlto would provide some insight...

[blb@…]

I think the issue here is that we need to have a catalog file for the docbook stuff. I've put that in my /etc/xml directory and xmlto successfully builds the docs for git-core.

The question is which port should be doing this? Should it be one of the more basic ports, libxml2 or libxslt, or the docbook ports themselves, docbook-xml or docbook-xsl. I've Cc'd the maintainer for these to see if he has any input.

Michael, any thoughts on whether one of these ports should be providing a catalog file (at the very least, to provide some rewrite rules to point docbook stuff to the items installed in ${prefix})? One big issue is that xmlcatalog (from libxml2) and xsltproc (from libxslt) both expect the catalog file in /etc/xml, so patches would need to be made to point them to ${prefix}/etc/xml instead.

[namely_void@…]

Gentoo seems to have the stuff in docbook-xsl-stylesheets ebuild, which probably corresponds to docbook-xsl of darwinports.

[blb@…]

And debian appears to do it in xml-core which is a dependency of things like docbook-xml; maybe there is no true standard method.

fink appears to update the catalog when needed (which debian may be doing as well). This is probably the most robust method to use. Install a barebones version with libxml2, and update it as necessary with things like docbook-xml/xsl etc via a post-activate rule. However, last I checked, post-deactivate doesn't function, so I'm not sure how we'd handle package removal.

[namely_void@…]

...I did a more in-depth review of the gentoo case: it turns out the stylesheet packages depend on the "build-docbook-catalog" package, which essentially is the script at:  http://sources.gentoo.org/viewcvs.py/gentoo-src/build-docbook-catalog/ The script is run (without args) when stylesheet packages are installed and removed (postinst/postrm). Maybe this could be (is already?) adapted/ported to darwinports. I suppose the functionality is more-or-less the same as in debian, but the implementation is probably structurally not so "nice."

[stephen@…]

This is *still* horribly broken as of 2006-08-15. There is a catalog.xml.in in dports/xmlto/files, but it never gets frobbed and installed, at least not so far as `find ${prefix} -name catalog.xml' can tell on my system.

Given how badly the whole system is screwed at the moment (see bugs 10422, 10424, 10425), it might be preferable to unpublish asciidoc and xmlto from the ports system. They're easy to install from upstream (considering the probable audience is git users), and that will at least hint to clueful people who can handle XML catalogs that problems like the version skew between asciidoc and the docbook port might crop up. Unless you're pretty sure you can do better than 6 month (and counting) response time.... (Or of course if there are other ports beside git-core that depend on asciidoc and/or xmlto.)

(In reply to comment #2)

Sorry about the delay, this bug seems to have slipped through the cracks... Is that XSL file not easily retrievable from your system, it loads okay here?

IIRC the xmlto script assumes that you have local copies, and deliberately turns off resolution of non-file URLs.

(In reply to comment #4)

I think the issue here is that we need to have a catalog file for the docbook stuff. I've put that in my /etc/xml directory and xmlto successfully builds the docs for git-core.

According to Norman Walsh, you just plain need catalogs.

The question is which port should be doing this? Should it be one of the more basic ports, libxml2 or libxslt, or the docbook ports themselves, docbook-xml or docbook-xsl.

Each port should keep a catalog of its resources and add a delegation for Public, System, or URI identifiers it provides to a system catalog. libxml2 should supply an explicitly empty default catalog. (No redirections, either, since you don't know at the time of installling libxml2 what resources will later be installed.)

[blb@…]

No longer maintaining this port.

[boeyms@…]

Attached is a patch to fix this bug, as well as a minor syntax improvement on the depends_build line. Its simplicity is due to the fact that most of the hard work has been done in the new docbook-xml-4.2 port (r25676), which incorporates automatic addition to a local XML catalog, and in the update to the xmlto port (r25745) that takes advantage of this. If no reply is received from the maintainer within a week, I will commit this patch to the repository regardless.

[bryan@…]

Sorry for the delay, I had problems with my port system. Recompiling gcc takes a while on PowerPC. I've updated the patch in ticket #11962 to include this patch. Somebody with commit privileges is welcome to apply the patch. Thanks for the help!

[boeyms@…]

Applied in r25898. Thanks for testing the patch!

[anonymous]

Milestone Port Bugs deleted