After upgrading to media-libs/mesa-8.0.1-r2 a bunch of packages appeared in @preserved-rebuild that require /usr/lib64/libGLU.so.1. Re-merging those packages don't remove them from this list (though they build fine). These packages are: [ebuild R ] x11-misc/xscreensaver-5.15 USE="perl%*" [ebuild R ] media-libs/ftgl-2.1.3_rc5 [ebuild R ] sci-mathematics/octave-3.6.1 [ebuild R ] app-emulation/wine-1.4_rc6 [ebuild R ] x11-libs/gtkglext-1.2.0 [ebuild R ] kde-base/kinfocenter-4.8.0 [ebuild R ] media-libs/smpeg-0.4.4-r9 USE="-static-libs%" [ebuild R ] media-libs/jasper-1.900.1-r4 [ebuild R ] media-libs/libcaca-0.99_beta17 [ebuild R ] kde-base/kdeartwork-kscreensaver-4.8.0 [ebuild R ] media-libs/xine-lib-1.2.1
Same issue. After upgrading to mesa-8.0.1-r2, and performing `emerge @preserved-rebuild` for libGLU, the preserved rebuild warning appears again.
Same problem here on ~amd64... !!! existing preserved libs: >>> package: media-libs/mesa-8.0.1-r2 * - /usr/lib64/libGLU.so.1 * used by /usr/lib64/kde4/kcm_opengl.so (kde-base/kinfocenter-4.8.0) * used by /usr/lib64/libgdkglext-x11-1.0.so.0.0.0 (x11-libs/gtkglext-1.2.0) * used by /usr/lib64/libreoffice/program/OGLTrans.uno.so (app-office/libreoffice-3.5.0.3) * used by /usr/lib64/xine/plugins/2.1/xineplug_vo_out_opengl.so (media-libs/xine-lib-1.2.1)
The libraries have been moved. eselect opengl now manages symlinks to them.
Seems similar to bug 225429. I can't reproduce it. Please post emerge --version.
$ emerge --version Portage 2.2.0_alpha89 (default/linux/amd64/10.0/desktop, gcc-4.5.3, glibc-2.14.1-r2, 3.2.5-pf x86_64)
For a workaround, run this as root: python -c 'import portage; plib_registry = portage.db["/"]["vartree"].dbapi._plib_registry; plib_registry.load(); delete plib_registry._data["media-libs/mesa:0"]; plib_registry.store()'
Funtoo ~amd64 # emerge --version Portage 2.3.2-r2 (default/linux/amd64/2008.0/desktop, gcc-4.6.2, glibc-2.13-r4, 3.2.6-ck x86_64)
I guess I didn't trigger the problem locally because of the following setting created by eselect-opengl: /etc/env.d/03opengl:LDPATH="/usr/lib/opengl/xorg-x11/lib" Do people experiencing this problem have some other setting in there?
Here's my /etc/env.d/03opengl: # Configuration file for eselect # This file has been automatically generated. LDPATH="/usr/lib32/opengl/nvidia/lib:/usr/lib64/opengl/nvidia/lib" OPENGL_PROFILE="nvidia"
This should prevent it from happening: http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=32d19be14e22ada479963ba8627452f5f2d89b94 If the problem has already happened to you, then you should manually removed the mesa library(s) from the the preserved libs registry, using the procedure described in comment #6.
This is fixed in 2.2.0_alpha90. However, users who update media-libs/mesa-8.0.1-r2 without updating portage first will still get a message about the preserved library when the old version of portage exits after the update. After they've updated portage, the @preserved-rebuild set shouldn't pull in libGLU.so.1 consumers though.
(In reply to comment #10) > This should prevent it from happening: > > http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit; > h=32d19be14e22ada479963ba8627452f5f2d89b94 > > If the problem has already happened to you, then you should manually removed > the mesa library(s) from the the preserved libs registry, using the > procedure described in comment #6. Something seems to be wrong with the python snippet: python -c 'import portage; plib_registry = portage.db["/"]["vartree"].dbapi._plib_registry; plib_registry.load(); delete plib_registry._data["media-libs/mesa:0"]; plib_registry.store()' File "<string>", line 1 import portage; plib_registry = portage.db["/"]["vartree"].dbapi._plib_registry; plib_registry.load(); delete plib_registry._data["media-libs/mesa:0"]; plib_registry.store() ^ SyntaxError: invalid syntax
Instead of comment #6, try this (as root): python -c 'import portage; plib_registry = portage.db["/"]["vartree"].dbapi._plib_registry; plib_registry.load(); plib_registry._data.pop("media-libs/mesa:0", None); plib_registry.store()'
Rebuilding mesa with the new portage also does the trick.
(In reply to comment #14) > Rebuilding mesa with the new portage also does the trick. This solution solved the problem for me.