Note: This is a beta release of Red Hat Bugzilla 5.0. The data contained within is a snapshot of the live data so any changes you make will not be reflected in the production Bugzilla. Also email is disabled so feel free to test any aspect of the site that you want. File any problems you find or give feedback here.
Bug 454952 - xmlcatalog can't find DTD for -//OASIS//DTD DocBook XML V4.2//EN using /etc/xml/catalog
Summary: xmlcatalog can't find DTD for -//OASIS//DTD DocBook XML V4.2//EN using /etc/x...
Alias: None
Product: Fedora
Classification: Fedora
Component: docbook-dtds
Version: 9
Hardware: All
OS: Linux
Target Milestone: ---
Assignee: Ondrej Vasik
QA Contact: Fedora Extras Quality Assurance
Depends On:
TreeView+ depends on / blocked
Reported: 2008-07-11 00:45 UTC by Alex Lancaster
Modified: 2008-07-15 12:18 UTC (History)
0 users

Fixed In Version: 1.0-37.fc9
Doc Type: Bug Fix
Doc Text:
Clone Of:
Last Closed: 2008-07-15 12:18:01 UTC

Attachments (Terms of Use)

Description Alex Lancaster 2008-07-11 00:45:23 UTC
Description of problem:
DTD can't be found for -//OASIS//DTD DocBook XML V4.2//EN using
/etc/xml/catalog, but can be found if pointing to /etc/sgml/catalog.

Version-Release number of selected component (if applicable):

How reproducible:

Steps to Reproduce:
1. xmlcatalog /etc/xml/catalog "-//OASIS//DTD DocBook XML V4.2//EN"
2. xmlcatalog /etc/sgml/catalog "-//OASIS//DTD DocBook XML V4.2//EN"

Actual results:
$ xmlcatalog /etc/sgml/catalog "-//OASIS//DTD DocBook XML V4.2//EN" 

$ xmlcatalog /etc/xml/catalog "-//OASIS//DTD DocBook XML V4.2//EN" 
No entry for PUBLIC -//OASIS//DTD DocBook XML V4.2//EN

Expected results:
After step 2 using the /etc/xml/catalog file, it should find the DTD in the same
location as for the /etc/sgml/catalog file

Additional info:
This d

Comment 1 Alex Lancaster 2008-07-11 00:51:35 UTC
This may be related to bug #453513.

Comment 2 Alex Lancaster 2008-07-11 00:53:36 UTC
The effect of this lack of DTD resolution is that it attempts to download the
DTDs via the web when running xsltproc or dblatex, which is why I thought it
might be related to bug #453513.

Comment 3 Alex Lancaster 2008-07-11 01:00:11 UTC
Digging deeper, I see that

/etc/xml/catalog contains this:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <delegatePublic publicIdStartString="-//OASIS//ENTITIES DocBook XML"
  <delegatePublic publicIdStartString="-//OASIS//DTD DocBook XML"

so it tells xmlcatalog to look for the DocBook DTDs in
/usr/share/sgml/docbook/xmlcatalog but here are the contents:

<?xml version="1.0"?>
<!DOCTYPE catalog PUBLIC "-//OASIS//DTD Entity Resolution XML Catalog V1.0//EN"
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog"/>

the file doesn't appear to contain any further information to allow xmlcatalog
to resolve the DTD location.  Did this get corrupted somehow?

Comment 4 Alex Lancaster 2008-07-11 01:07:20 UTC
OK, so a reinstallation of docbook-dtds fixed it apparently because it re-ran
the postinstall scriptlet which has all the logic to fill up

But I still don't know what was the underlying cause for this. Ff bug #453513 is
anything to go by, it may be affect more than just me. 

Comment 5 Ondrej Vasik 2008-07-11 08:02:21 UTC
Thanks for report. Yep, it's related and unfortunately no way to fix it without
breaking those catalogs once more time, will comment that in the duplicate
bugzilla preceeding that one report, closing that as duplicate of bug #453513.

*** This bug has been marked as a duplicate of 453513 ***

Comment 6 Alex Lancaster 2008-07-11 08:13:08 UTC
(In reply to comment #5)
> Thanks for report. Yep, it's related and unfortunately no way to fix it without
> breaking those catalogs once more time

Why can't this be fixed? What caused the original breakage?  Will a freshly
installed + recent upgrades box have this problem?

Comment 7 Ondrej Vasik 2008-07-11 08:32:29 UTC
I'm afraid it will. It can't be fixed simply because the rawhide fix only
prevents occurance of that behaviour in future. Design of usage in xml-common
/usr/share/sgml/docbook/xmlcatalog is bad from the beginning, as every time you
change something in that file, it will replace all registered catalogs. I will
try to find out a solution which will not break install+update boxes. This is
quiet unfortune situation as only because of cosmetic issue with rpm -V
xml-common complaints all the Docbook-dtds things got broken. Simpliest solution
might be to untag xml-common-0.6.24.fc9 from dist-f9. Another way could be to
make an update of docbook-dtds, which will require xml-common >= 0.6.24.fc9 -
which will make install+update solution working once more time. I do prefer the
second one with docbook-dtds update.

Comment 8 Fedora Update System 2008-07-11 10:55:37 UTC
docbook-dtds-1.0-37.fc9 has been submitted as an update for Fedora 9

Comment 9 Ondrej Vasik 2008-07-11 17:15:59 UTC
It turned out that the bug described in #453513 was slightly different.
Therefore removing duplicate and marking closed current release. Sorry for
troubles, xml-common catalog issue should be solved by this docbook-dtds update.

Comment 10 Alex Lancaster 2008-07-13 01:27:12 UTC
Downloaded the koji build manually. This seems to fix the empty missing entries
in /usr/share/sgml/docbook/xmlcatalog problem! Thanks!

Comment 11 Alex Lancaster 2008-07-13 01:27:57 UTC
Re-opening bug as bodhi should close this bug automatically once pushed to stable.

Comment 12 Fedora Update System 2008-07-15 12:17:59 UTC
docbook-dtds-1.0-37.fc9 has been pushed to the Fedora 9 stable repository.  If problems still persist, please make note of it in this bug report.

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