I have a very simple test man page (written in DocBook). Attempting to process this man page with xmlto produces: $ xmlto man test.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" compilation error: file /tmp/qralston-gb3077/xmlto-xsl.Wd6965 line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl Up until now, I've been able to process these man pages with xmlto with no problems whatsoever. If I crack xmlto apart and run the xsltproc command directly (adding --verbose), I get: $ xsltproc --verbose --nonet --xinclude -o test.proc xmlto-xsl test.xml creating dictionary for stylesheet reusing dictionary from xmlto-xsl for stylesheet xsltParseStylesheetProcess : found stylesheet xsltPrecomputeStylesheet: removing ignorable blank node Reusing dictionary for document 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" compilation error: file xmlto-xsl line 4 element import xsl:import : unable to load http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl Reusing dictionary for document xsltParseStylesheetProcess : found stylesheet xsltPrecomputeStylesheet: removing ignorable blank node Registering global param chunker.output.encoding Defining global param chunker.output.encoding parsed 0 templates parsed 0 templates freeing dictionary from stylesheet If I strace the xsltproc process, I see: stat("http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl", 0x7fff331e6150) = -1 ENOENT (No such file or directory) write(2, "I/O ", 4I/O ) = 4 write(2, "error : ", 8error : ) = 8 write(2, "Attempt to load network entity h"..., 103Attempt to load network entity http://docbook.sourceforge.net/release/xsl/current/manpages/docbook.xsl ) = 103 Note the totally bogus attempt to stat() what is clearly a URI. If I leave off the --nonet option, xsltproc works, but takes a long time (~60 seconds) and initiates many network connections. I doubt this is actually a bug with xmlto, but I'm unsure whether it's a bug with the catalogs (from xml-common), the xsltproc command itself (from libxslt), or something else. But regardless, something is pretty majorly borked up here. This is a major shopstopper, as not having a working xmlto is preventing me from building any packages from my Subversion repositories. (I write all my man pages in DocBook.) Versions: $ rpm -q libxslt xml-common xmlto libxslt-1.1.22-1.fc8 xml-common-0.6.3-21.fc8 xmlto-0.0.18-17 I also attempted running xmlto on a F7 box; it fails with the same error. Versions: $ rpm -q libxslt xml-common xmlto libxslt-1.1.21-1.fc7 xml-common-0.6.3-20.fc7 xmlto-0.0.18-13.1
Created attachment 291186 [details] test DocBook man page
Sorry, it is not problem of xmlto ... this is problem of docbook-style-xsl - which is already fixed, but still may cause troubles. Sorry for that. Problem was caused by removing release number from docbook-style-xsl(see #389231 for more details). I was not aware enough and drop of release caused that registration of catalogs from docbook-style-xsl was removed in %postun by uninstallation of previous package. This should be fixed now, but previous version still unregistered correct current one. Easiest solution is to force update of docbook-style-xsl with to register catalog one more time(even if the package is already current one, it will help). Let me know if it solved your troubles - but I'm almost sure it will... changing component to docbook-style-xsl.
Confirmed; running "yum erase docbook-style-xsl" and then using "yum install" to reinstall docbook-style-xsl (and the dependent packages that were also removed) fixes the problem. Alas, I'm not sure if there's any way to automatically fix this without manual intervention, as it's the %postun of the old package that's the problem...
Actually, I see one possible way - to make update of docbook-style-xsl with nothing/almost nothing changed - this will cause that this will be fixed without manual intervention - just by update. But this may cause the same problem when someone will miss that "doubled update" and will catch only one... At least the way "Install Fedora 7/8 from CD, do the updates" should be fixed soon - push of fixed package to stable was requested ~1 week ago. Once more time sorry for troubles, I didn't expected that behaviour and it doesn't appear in my standard check of package (because error occur after postun of bad package - after all quicktests were completed).
Don't know what is the exact state for close I have to fill - it is something between CURRENT_RELEASE (docbook-style-xsl-1.73.2-3.fc7(fc8)) and DEFFERED - as the problem will trully be fixed by docbook-style-1.74.0 release(should be end of Jan, according to docbook mailing lists) - so closing as DEFERRED. Anyway - closing this bugzilla, temporary workaround is to remove/install docbook-style-xsl package and updates for new Fedora installations will be ok after 1.73.2-3.fc7(fc8) in stable.