Summary: | x11-libs/libX11-1.1.1-r1 makes www-client/opera segfault | ||
---|---|---|---|
Product: | Gentoo Linux | Reporter: | Milan Vít <milanvit> |
Component: | New packages | Assignee: | Jeroen Roovers (RETIRED) <jer> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | anton.bugs, axxo, daemon, jakub |
Priority: | High | Keywords: | REGRESSION |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
URL: | https://bugs.freedesktop.org/show_bug.cgi?id=10536 | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: | opera-9.20_rc633.ebuild |
Description
Milan Vít
2007-04-05 20:34:08 UTC
Confirmed. BTW, looks like there's exactly same borkage w/ 1.0.3-r2 (same patch). Please get this filed upstream at bugs.freedesktop.org, xorg product ASAP so we can get a fixed patch. Once you do, post the URL here. Thanks! BTW: http://my.opera.com/desktopteam/blog/show.dml/890647 (I haven't tried this weekly build yet) It's not opera. Revert to x11-libs/libX11-1.1.1. The xorg-libX11-1.1.1-xinitimage.diff patch that was added in 1.1.1-r1 is causing the problem. See bug 172752. How to find info: - Check genlop history back to where the broken package used to work. - Do "ldd" on the broken binary, if possible. - See if any of the reported libraries are in recently upgraded packages. - Revert those packages until the one that fixes the problem is found. - diff the ebuild that did the upgrade. - Inspect any new patches being applied. - Go to http://sources.gentoo.org/viewcvs.py/gentoo-x86/ and find the change. - Look at the CVS checkin comments for bug references - Read and add to the bug. FWIW: This bug is being worked by the opera developers. forum: http://my.opera.com/community/forums/topic.dml?id=183923 hotfix: http://my.opera.com/desktopteam/blog/2007/04/06/hotfix Upstream Xorg folks don't want this either, re-assigning to Opera maintainer. Created attachment 115605 [details]
opera-9.20_rc633.ebuild
FIX
Sorcerer / # emerge -pv opera
These are the packages that would be merged, in order:
Calculating dependencies... done!
[ebuild R ] www-client/opera-9.20_rc633 USE="-debug gnome qt-static spell" 0 kB [1]
(In reply to comment #9) > Created an attachment (id=115605) [edit] > opera-9.20_rc633.ebuild Please do provide a unified diff instead of a complete ebuild next time. Putting Opera's "daily weeklies" into the tree would take away the fun from maintaining www-client/opera, so I won't. It seems Opera's plans to take build 617 to beta status and to an official release failed, so I can't put that into the tree now, although it worked fine for me and I did intend to commit an ebuild right until the next weekly was published unexpectedly. ;) However, as referenced in comment #7, [1] suggests you work around the problem as follows: "If you do not want to install a weekly release but continue running version 9.1, you can change the "DefaultDepth" option to 16 in your /etc/X11/xorg.conf file, as this will also work around the problem." [1] http://my.opera.com/desktopteam/blog/2007/04/06/hotfix I suggest you to release opera-9.10-r1.ebuild which would block building opera if this version of lib is installed. (In reply to comment #11) > I suggest you to release opera-9.10-r1.ebuild which would block building opera > if this version of lib is installed. Er, so user would do `emerge --update [--deep] world`, emerge would then find a www-client/opera-9.10-r1 to upgrade to, and the ebuild would then merely `die "Downgrade your libX11, ktxbye"`? I can't think how that (or making DEPEND version-aware) would help users at this time. There are two ways to fix the issue now: downgrade libX11 or apply the workaround I quoted in comment #10. Upstream thinks it is fixed now. Enjoy Opera 9.20 now or wait for a month for it to go stable! (In reply to comment #12) > "Downgrade your libX11, ktxbye"`? I can't think how that (or making DEPEND > version-aware) would help users at this time. Agree, it was bad idea. Anyway, x11-libs/libX11-1.1.1-r1 went stable today because of security bug and stable (6.10) opera will stop working after upgrading. Since many people relay on a browser today and expect stable version to be working, is any way to stabilize version 6.20 early? As a mitigation it might be a good idea to create a sticky thread on the forum with details to avoid dups of this bug. What is a usual procedure in such case? (In reply to comment #14) > Since many people relay on a browser today and expect stable version to be > working, is any way to stabilize version 6.20 early? Bug #168484 says x86 keyworded 9.20 stable just now. |