he panel encountered a problem while loading "OAFIID:GNOME_ClockApplet". # ldd /usr/lib64/gnome-panel/libclock-applet.so | grep "not found" libproxy.so.0 not found Reproducible: Always ＃ cd /usr/lib64; ln -s libproxy.so.1.0.0 libproxy.so.0 solved the problem
(In reply to comment #0) > ＃ cd /usr/lib64; ln -s libproxy.so.1.0.0 libproxy.so.0 > solved the problem No. Don't do that. Remove the symlink and # emerge gentoolkit # revdep-rebuild
Missing preserved-libs stuff. Reopening.
(In reply to comment #2) > Missing preserved-libs stuff. Reopening. > Uh, you mean old-style preserved-libs stuff? Try to avoid overusing it... Things break just at runtime then, when half of the libs are still linked against .so.0 and second half .so.1 and these symbols collide at runtime. People really don't read the postinst messages, we've seen that already :)
(In reply to comment #1) > (In reply to comment #0) > > ＃ cd /usr/lib64; ln -s libproxy.so.1.0.0 libproxy.so.0 > > solved the problem > > No. Don't do that. Remove the symlink and > > # emerge gentoolkit > # revdep-rebuild > thank you very much, this sovled the problem
0.4.2 is out seems to install and work fine; http://code.google.com/p/libproxy/updates/list
Not really a bug, they just bumped the soname
sorry but we do handle this in gnome ebuilds. Sure the preserved-libs stuff is not optimal but at least we can point user to the relevant point of failure.
I agree with Gilles here, please think in people that try to maintain their systems properly (-> reviewing elog messages) ;-)
+ 31 May 2010; Gilles Dartiguelongue <eva@gentoo.org> libproxy-0.4.2.ebuild: + Preserve old lib, bug #320511. Install perl binding in vendor directory, + bug #321807. Improve python binding handling, bug #315319. +
