Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 174434 - [TRACKER] x11-libs/libxcb breakage
Summary: [TRACKER] x11-libs/libxcb breakage
Status: RESOLVED FIXED
Alias: None
Product: Gentoo Linux
Classification: Unclassified
Component: Eclasses (show other bugs)
Hardware: All Linux
: High normal (vote)
Assignee: Gentoo X packagers
URL:
Whiteboard:
Keywords: Tracker
Depends on: sun_xcb 156367 158476 162028 169574 174345 174426 174707 176590 176839 178484 180328 186603 196717 206573 239977 240482
Blocks:
  Show dependency tree
 
Reported: 2007-04-13 11:49 UTC by Jakub Moc (RETIRED)
Modified: 2009-09-13 08:11 UTC (History)
10 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Jakub Moc (RETIRED) gentoo-dev 2007-04-13 11:49:58 UTC
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
Comment 1 Samuli Suominen gentoo-dev 2007-04-13 12:28:27 UTC
Umm, no? Been using it since it became available and had no issues at all..
- bug 169574 , Comment #17
- 174426 is worksforme
Comment 2 Jakub Moc (RETIRED) gentoo-dev 2007-04-13 13:24:33 UTC
(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.
Comment 3 Arthur Hagen 2007-04-13 15:45:43 UTC
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.
Comment 4 Arthur Hagen 2007-04-13 16:05:45 UTC
(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.
Comment 5 Santiago M. Mola (RETIRED) gentoo-dev 2007-04-13 20:54:26 UTC
python: xcb_xlib.c:50: xcb_xlib_lock: Assertion `!c->xlib.lock' failed.

It broke various apps here.
Comment 6 James Cloos 2007-04-14 17:20:13 UTC
(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.
Comment 7 Joshua Baergen (RETIRED) gentoo-dev 2007-04-14 17:32:30 UTC
(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?
Comment 8 Donnie Berkholz (RETIRED) gentoo-dev 2007-04-17 19:27:06 UTC
I just filed bug #174959 to stable some X libraries with XCB fixes. Hopefully that will resolve some of these issues.
Comment 9 Petteri Räty (RETIRED) gentoo-dev 2007-04-17 20:05:52 UTC
(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.
Comment 10 Joshua Baergen (RETIRED) gentoo-dev 2007-04-17 20:23:20 UTC
(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
Comment 11 Petteri Räty (RETIRED) gentoo-dev 2007-04-17 20:44:15 UTC
(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.
Comment 12 James Cloos 2007-04-19 20:48:41 UTC
(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.)
Comment 13 Joshua Baergen (RETIRED) gentoo-dev 2007-04-20 23:08:09 UTC
(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.
Comment 14 Simon Cooper 2007-05-06 14:17:03 UTC
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?
Comment 15 Joshua Baergen (RETIRED) gentoo-dev 2007-05-07 22:52:45 UTC
(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.
Comment 16 Jakub Moc (RETIRED) gentoo-dev 2007-06-02 17:59:37 UTC
Uhm seriously, the loads of broken stuff isn't enough to use.mask this, or?
Comment 17 Peter Fern 2007-06-05 16:53:43 UTC
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.
Comment 18 Josh Triplett 2007-06-10 06:15:33 UTC
I submitted a workaround to the Java bugreport recently; perhaps Gentoo could incorporate that workaround?
Comment 19 Petteri Räty (RETIRED) gentoo-dev 2007-06-23 10:30:06 UTC
How about we modify the xcb use flag description to tell that it can potentially break some applications?
Comment 20 Jakub Moc (RETIRED) gentoo-dev 2007-06-23 10:48:14 UTC
(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. :(
Comment 21 Rémi Cardona gentoo-dev 2009-09-13 08:11:56 UTC
All bugs are closed and libxcb is now enabled by default on ~arch libX11.

Closing