I'll join a copy/paste of my term for details... xmlto seems to disagree with some docbook file... My xmlto version is 0.0.22 with latex USE flag. Reproducible: Always Deactivating doc-epydoc USE flags is a simple workaround (I did not check which one is the source of the bug), so it's not a blocker, but... well, it's an ugly bug for the package manager.
Created attachment 193124 [details] What portage tells me when I try to install it
This error doesn't occur with app-text/xmlto-0.0.21...
Well, if it's an xmlto bug, it's not a Portage bug, but it's still a bug anyway, and quite ugly. To force a versioned dep on =app-text/xmlto-0.0.21 (I locally simply masked 0.0.22) would be ugly, but would fix the problem.
*** Bug 272267 has been marked as a duplicate of this bug. ***
Created attachment 193345 [details] xmlto-0.0.22 build.log (live)
Created attachment 193346 [details] /etc/xml/catalog (live)
Created attachment 193348 [details] /etc/xml/docbook (live)
Created attachment 193349 [details] xmlto-0.0.22 build.log (stage3)
Created attachment 193350 [details] /etc/xml/catalog (stage3)
I get similar errors when installing other packages including xmlto itself on my live system as well as when creating a stage3 tarball using metro. My uneducated guess is that something is wrong with build-docbook-catalog. At the time xmlto is emerged (and all of it's dependencies have been merged already) when building the stage3 /etc/xml/docbook is completely missing and /etc/xml/catalog doesn't contain all the entries it should as can be seen above. I am also unable to emerge git-9999. Probably every package that uses xmlto is affected.
Created attachment 193352 [details] git-9999 build.log (live)
Reassigning to sgml herd as per comment #10.
Samuli Suominen: According to ChangeLog, you added xmlto-0.0.22.ebuild to the tree. (If you can't fix it, please at least restore xmlto-0.0.21.ebuild.)
I'm not an expert with SGML but after Fedora switched to xmlto, the same error occured with their lcdproc pkg, http://cvs.fedoraproject.org/viewvc/rpms/lcdproc/devel/lcdproc-0.5.2-novalidate.patch?revision=1.1&view=markup
Created attachment 193771 [details, diff] No validation with xmlto 0.0.22 until the docbook is fixed. Temp. solution, until we figure out what is wrong with the validation using new xmlto.. Tested, working.
Might want to look at this, http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=516253 If I read it correct, --noent was added to xmllint options for xmlto so there's something wrong with the docbook, not xmlto I'm free to be corrected
"xmllint --noout -xinclude --postvalid --noent portage.docbook" by hand in doc/ directory to reproduce..
(Sorry, I keep spamming.) bzless /usr/share/doc/xmlto-0.0.22/NEWS.bz2 - xmllint validity check now with noent option(debian #516253) So options: 1) Fix Portage's docs to be valid. (This is the correct option.) 2) Apply the foo.patch attached in this bug. (Documentation will build as before, but there is no validation since the docs are broken.) 3) Revert this one change in xmlto-0.0.22 to way it was in 0.0.21 (This still doesn't make your docs valid.) 4) Add 0.0.21 back in tree and reopen all the ~10 bugs it closed. I'll try to rewrite the failing parts for the docs, but I can't promise anything since I'm really not an SGML expert or such :-)
(In reply to comment #15) > Created an attachment (id=193771) [edit] > No validation with xmlto 0.0.22 until the docbook is fixed. > > Temp. solution, until we figure out what is wrong with the validation using new > xmlto.. > > Tested, working. > Thanks, I've applied this patch to the ebuild and the docbook is fixed in svn for the next release.
*** Bug 274461 has been marked as a duplicate of this bug. ***
(In reply to comment #16) > If I read it correct, --noent was added to xmllint options for xmlto so there's > something wrong with the docbook, not xmlto It seems we are dealing with two bugs here. 1. What you have mentioned. 2. The problems I experienced when building a stage3. Well, I have added the noise about 2. and should probably have opened a new bug for that, sorry. Basically some of the involved packages have missing dependencies. I have opened a new bug for that (277092), so you can disregard all my above comments.
This is fixed in 2.2_rc34.
