Folks, this just isn't ready for primetime, it breaks things, creeps into .la files in a weird way and generally causes big trouble for users. Shouldn't be available in stable tree. ebuilds with stable keywords and USE=xcb media-libs/xine-lib-1.1.4-r2 x11-libs/libX11-1.1.1-r1 And unstable ebuilds w/ this flag, for completeness. media-libs/mesa-6.5.1-r4 media-libs/mesa-6.5.2 media-libs/mesa-6.5.2-r1 media-libs/xine-lib-1.1.4-r1 media-libs/xine-lib-1.1.4-r2 media-video/kaffeine-0.8.3-r1 x11-libs/cairo-1.4.0 x11-libs/cairo-1.4.2 x11-libs/libX11-1.0.99.2-r1 x11-libs/libX11-1.1.1
Umm, no? Been using it since it became available and had no issues at all.. - bug 169574 , Comment #17 - 174426 is worksforme
(In reply to comment #1) > Umm, no? Been using it since it became available and had no issues at all.. > - bug 169574 , Comment #17 That's fine but doesn't fix the real problem at all. xcb keeps polluting all sorts of .la stuff that it shouldn't touch (see Bug 158476 e.g.) > - 174426 is worksforme Apparently not for the reporter. Same issue as Bug 174345 or Bug 156367.
I agree with Jakub. Adding "xcb" and doing a --newuse world on two systems here broke gnome-session-2.16.2 on both. Users trying to log in would invariably fail, with the following in .xsession-errors: gnome-session: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. Judging by the other bug reports, there's just too many things breaking with xcb right now for it to be considered stable.
(In reply to comment #3) > > gnome-session: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. Typo. Should have been '[...] xcb_xlib_unlock: Assertion [...]' Doing a search on Google for "xcb_xlib Assertion:" gives quite a few results, for a multitude of apps. Even though the devs in http://lists.debian.org/debian-devel-announce/2006/11/msg00010.html assert that this is a problem with the calling apps, there's just too many calling apps that will trigger that problem right now for xcb to be considered stable.
python: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. It broke various apps here.
(In reply to comment #3) > gnome-session: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed. Adding -DNDEBUG to CFLAGS when compiling xcb avoids the assertions (cf assert(3) for details on the NDEBUG flag). There is a proposal to force it for non-debug compiles of xcb, but until then the ebuild can add the flag unless debug is in USE. I've been using xcb for ages and the assert(3)s are the only issue left. Incidently, I expect at least some of the binary dists will be doing this in their package build scripts, so it would not be a gentoo-only thing.
(In reply to comment #6) > (In reply to comment #3) > Adding -DNDEBUG to CFLAGS when compiling xcb avoids the assertions (cf > assert(3) for details on the NDEBUG flag). There is a proposal to force it for > non-debug compiles of xcb, but until then the ebuild can add the flag unless > debug is in USE. Thanks, James. > I've been using xcb for ages and the assert(3)s are the only issue left. We've been seeing a lot of links to xcb leaking into .la files all over the place. Any idea what's causing this?
I just filed bug #174959 to stable some X libraries with XCB fixes. Hopefully that will resolve some of these issues.
(In reply to comment #8) > I just filed bug #174959 to stable some X libraries with XCB fixes. Hopefully > that will resolve some of these issues. > Running all ~x86 and Java is still borked if I turn on the xcb use flag in libX11.
(In reply to comment #9) > Running all ~x86 and Java is still borked if I turn on the xcb use flag in > libX11. There is a Java bug tracking this: http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373
(In reply to comment #10) > (In reply to comment #9) > > Running all ~x86 and Java is still borked if I turn on the xcb use flag in > > libX11. > > There is a Java bug tracking this: > > http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6532373 > Yes and as such IMHO we should consider if the USE flag is worth it in stable.
(In reply to comment #7) > We've been seeing a lot of links to xcb leaking into .la files all over the > place. Any idea what's causing this? Do you mean those cases where the associated .so links against something that links against an xcb lib? AIUI, libtool will include anything which would show up by running ldd(1) on the .so.... (And yes, upgrading xcb after The Great Renaming™ was a royal pain in the arse. revdep-rebuild fails miserably — mainly because the resulting emerge(1) call does not order the packages being re-merged in dependency order, so you have to manually re-order and/or run the emerge over and over and over until it all works.... Plus, when I did it, revdep-rebuild would fail with too man args errors almost every time I ran it. But that problem ended after a single painful process. Since then xcb at least is non-problematic for me.)
(In reply to comment #12) > (In reply to comment #7) > > We've been seeing a lot of links to xcb leaking into .la files all over the > > place. Any idea what's causing this? > > Do you mean those cases where the associated .so links against something that > links against an xcb lib? AIUI, libtool will include anything which would show > up by running ldd(1) on the .so.... Maybe that's what's causing it. I can't say I looked into it too much.
may I ask what the policy is on mesa-6.5.2-r1 being stabilised on amd64, requiring libX11 compiled with xcb, when there are still these issues around?
(In reply to comment #14) > may I ask what the policy is on mesa-6.5.2-r1 being stabilised on amd64, > requiring libX11 compiled with xcb, when there are still these issues around? > Mesa only requires this when being built with xcb support itself.
Uhm seriously, the loads of broken stuff isn't enough to use.mask this, or?
You're welcome to try the libxcb ebuild from: http://bugs.gentoo.org/show_bug.cgi?id=176839#c1 Somewhat ugly, but best way I could see of solving the problem until clients are updated for the new xcb locking.
I submitted a workaround to the Java bugreport recently; perhaps Gentoo could incorporate that workaround?
How about we modify the xcb use flag description to tell that it can potentially break some applications?
(In reply to comment #19) > How about we modify the xcb use flag description to tell that it can > potentially break some applications? Shrug... As for the original suggested solution, portage would have to support stuff like cat/pkg ~-flag in package.use.mask to unmask the flag on unstable ebuilds only, no matter what their version is. Otherwise it's not maintainable in a reasonable way. :/ Until then, you can either tweak the use flags description as you suggest, or use.mask this globally, or ignore all the breakage. :(
All bugs are closed and libxcb is now enabled by default on ~arch libX11. Closing
