Bug 428168 - xmlto (xsltproc) fails with "I/O error : Attempt to load network"
xmlto (xsltproc) fails with "I/O error : Attempt to load network"
Status: CLOSED DEFERRED
Product: Fedora
Classification: Fedora
Component: docbook-style-xsl (Show other bugs)
8
All Linux
low Severity high
: ---
: ---
Assigned To: Ondrej Vasik
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-01-09 14:00 EST by James Ralston
Modified: 2008-01-10 11:09 EST (History)
0 users

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-01-10 11:09:36 EST
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
test DocBook man page (659 bytes, text/plain)
2008-01-09 14:00 EST, James Ralston
no flags Details

  None (edit)
Description James Ralston 2008-01-09 14:00:26 EST
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
Comment 1 James Ralston 2008-01-09 14:00:26 EST
Created attachment 291186 [details]
test DocBook man page
Comment 2 Ondrej Vasik 2008-01-09 16:14:21 EST
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.
Comment 3 James Ralston 2008-01-09 20:17:53 EST
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...
Comment 4 Ondrej Vasik 2008-01-10 02:57:36 EST
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). 
Comment 5 Ondrej Vasik 2008-01-10 11:09:36 EST
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.

Note You need to log in before you can comment on or make changes to this bug.