Unfortunately I can't post the error message here because it's on the computer that is kind of broken, but the problem is that libxcb can't emerge because xsltproc in the libxslt package segfaults during the compile process. It seems people from other distributions have been experiencing this bug as well. Googling for "xsltproc libxcb" returns quite a few hits about this problem. It looks like this patch on Makefile.in resolve the problem. usesource.patch: new --- /dev/null +++ usesource.patch @@ -0,0 +32 @@ +http://lists.freedesktop.org/archives/xorg/2006-November/019675.html + +--- libxcb-1.0/src/Makefile.in.usesource 2006-12-06 15:22:10.000000000 -0500 ++++ libxcb-1.0/src/Makefile.in 2006-12-06 15:23:45.000000000 -0500 +@@ -860,19 +860,17 @@ + + $(EXTHEADERS) $(EXTSOURCES): c-client.xsl + ++# this hack works because we know that all the files have been ++# pregenerated, but make might try to rebuild them with buggy ++# xsltproc because system files in /usr/share/xcb (say) are ++# newer + .xml.h: +- @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) +- $(XSLTPROC) --stringparam mode header \ +- --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ +- --stringparam extension-path $(XCBPROTO_XCBINCLUDEDIR)/ \ +- -o $@ $(srcdir)/c-client.xsl $< ++ test -f $@ ++ touch $@ + + .xml.c: +- @n=`dirname $*`; test -d $$n || (echo mkdir $$n; mkdir $$n) +- $(XSLTPROC) --stringparam mode source \ +- --stringparam base-path $(XCBPROTO_XCBINCLUDEDIR)/ \ +- --stringparam extension-path $(XCBPROTO_XCBINCLUDEDIR)/ \ +- -o $@ $(srcdir)/c-client.xsl $< ++ test -f $@ ++ touch $@ + + $(EXTENSION_XML): + $(LN_S) -f $(XCBPROTO_XCBINCLUDEDIR)/$@ $@
*** Bug 158974 has been marked as a duplicate of this bug. ***
*** Bug 159332 has been marked as a duplicate of this bug. ***
Well, since it's apparently libxslt's fault, I'd rather solve it by using the working version. 1.1.17 seems to work fine for me. Can you confirm this? CCed Gnome since they're the current maintainers of libxslt.
libxslt 1.1.19 supposedly has a fairly annoying bug (probably this one) that will soon result in a .20.
This seems to affect a bunch of packages, I'd suggest to mask 1.1.19 and wait for an upstream bump.
It is nasty, and I remember this discussed at least one month or two ago on xcb's mailing list, I agree with Hanno, it should be p.masked or fixed.
My bad. A while ago I was asked by an upstream developer not to add libxslt-1.1.18 nor 1.1.19 to the tree because of serious bugs in them, and once I found out 1.1.19 had been added, I decided to wait for 1.1.20, which unfortunately took longer than expected. In retrospective, I made the wrong choice and probably should have hard-masked 1.1.19 early. Now 1.1.20 is in the tree, which should not produce the segfault mentioned in this bug. Please test and let me know if any b0rkness is still present :). Thanks
Seems fine to me. I'll let at least one more person test before I mark this fixed.
Works for me!
(In reply to comment #9) > Works for me! > Thanks, marking fixed.
