Bug 454952

This may be related to bug #453513.

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.

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"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<catalog xmlns="urn:oasis:names:tc:entity:xmlns:xml:catalog">
  <delegatePublic publicIdStartString="-//OASIS//ENTITIES DocBook XML"
catalog="file:///usr/share/sgml/docbook/xmlcatalog"/>
  <delegatePublic publicIdStartString="-//OASIS//DTD DocBook XML"
catalog="file:///usr/share/sgml/docbook/xmlcatalog"/>
....
</catalog>

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"
"http://www.oasis-open.org/committees/entity/release/1.0/catalog.dtd">
<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?

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
/usr/share/sgml/docbook/xmlcatalog.  

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. 

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 ***

(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?

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.

docbook-dtds-1.0-37.fc9 has been submitted as an update for Fedora 9

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.

Downloaded the koji build manually. This seems to fix the empty missing entries
in /usr/share/sgml/docbook/xmlcatalog problem! Thanks!

Re-opening bug as bodhi should close this bug automatically once pushed to stable.

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.