Re: [gentoo-user] Re: @preserved-rebuild gone in a loop
On Monday 16 Dec 2013 04:04:34 eroen wrote: On Sun, 15 Dec 2013 17:37:53 +0100 Benjamin Block b...@zlug.org wrote: Most of the times, when some binary packages on my systems do cause something like this, then I just unemerge the package that keeps recompiling and emerge it again afterwards. This will cause the portage to drop the library-references in question and add new ones. So, this should do the trick: emerge -C app-antivirus/avast4workstation emerge -1 app-antivirus/avast4workstation This will make the message from portage and the old library version go away, yes. It will also cause the program that used the library (/opt/avast4workstation/bin/avastgui in OP's case) crash when you try to run it, due to the old library version not being installed. The correct solution to this is to add the specific (old) version of the library to the dependencies (in the ebuild) of the (binary) package that uses it. This will prevent an upgrade that uninstalls the old library version. Sometimes the maintainer of the library will add a slotted version of it, so that non-binary users of it do not have to use the outdated version. If the binary package is not an ebuild, you can manually add the newer library version to package.mask, or make sure that the slot for the older version is installed if the library is slotted. Better yet (in all cases), get a more recent version of the binary package that is built against the newer version of the library. Complain to the vendor if none is available :-) The preserve-libs feature in portage is intended to let things keep on working short-term for source-distributed packages. In that case, the currently installed program is linked against the old library version, and when the program is rebuilt (with @preserved-rebuild) it will be linked against the newer version. Thank you for a detailed explanation, which makes sense to me. You are right, uninstalling, running @preserved-rebuild and reinstalling this package breaks the avastgui because of the missing libpangox-1.0.so.0 library. Thankfully, the command line function is unaffected. I wouldn't want to keep old libraries around unnecessarily, so I may have to chase the dev for this package and see if he's still interested to look after it. -- Regards, Mick signature.asc Description: This is a digitally signed message part.
[gentoo-user] Re: @preserved-rebuild gone in a loop
On 15/12/13 11:51, Mick wrote: Not sure why, but for some reason running emerge @preserved-rebuild does not seem to fix some preserved libs links: !!! existing preserved libs: package: x11-libs/pango-1.34.1 * - /usr/lib/libpangox-1.0.so.0 * - /usr/lib/libpangox-1.0.so.0.3000.1 This is all caused by some hack I have in my local portage for app- antivirus/avast4workstation-1.3.0-r2. No matter how many times I run @preserved-rebuild the libs in question keep coming up: Yes, that's to be expected. Avast is a binary, it's not built from sources, so there's no link step involved that would link against the new pango libs. I'm not sure if it'll work, by try emerging x11-libs/pangox-compat. If that doesn't help, then your only option is to downgrade your pango version to the version that doesn't exhibit the problem and mask all newer versions.
[gentoo-user] Re: @preserved-rebuild gone in a loop
On Sun, 15 Dec 2013 17:37:53 +0100 Benjamin Block b...@zlug.org wrote: Most of the times, when some binary packages on my systems do cause something like this, then I just unemerge the package that keeps recompiling and emerge it again afterwards. This will cause the portage to drop the library-references in question and add new ones. So, this should do the trick: emerge -C app-antivirus/avast4workstation emerge -1 app-antivirus/avast4workstation This will make the message from portage and the old library version go away, yes. It will also cause the program that used the library (/opt/avast4workstation/bin/avastgui in OP's case) crash when you try to run it, due to the old library version not being installed. The correct solution to this is to add the specific (old) version of the library to the dependencies (in the ebuild) of the (binary) package that uses it. This will prevent an upgrade that uninstalls the old library version. Sometimes the maintainer of the library will add a slotted version of it, so that non-binary users of it do not have to use the outdated version. If the binary package is not an ebuild, you can manually add the newer library version to package.mask, or make sure that the slot for the older version is installed if the library is slotted. Better yet (in all cases), get a more recent version of the binary package that is built against the newer version of the library. Complain to the vendor if none is available :-) The preserve-libs feature in portage is intended to let things keep on working short-term for source-distributed packages. In that case, the currently installed program is linked against the old library version, and when the program is rebuilt (with @preserved-rebuild) it will be linked against the newer version. -- eroen signature.asc Description: PGP signature
[gentoo-user] Re: @preserved-rebuild
Neil Bothwick neil at digimed.co.uk writes: No apparent ill effects. You now have the old, orphaned version of the library on your system and unknown to portage. Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? Yes, qfile will help here qfile -o $(find /lib* /usr/lib*) OK, I used Francesco's little script: for i in $(find /lib* /usr/lib*) ; do qfile -o $i ; done It worked like a charm, except there is a huge list? It overfilled my scroll back, so below is a tiny snippet. I'm weary of removing so many files? rm these files? revdep-rebuild comes back clean. Check with another tool? I already synced and updated, do again? snip /usr/lib64/python2.6/site-packages/_xmlplus/dom/html/HTMLElement.pyo snip /usr/lib64/libblas.a /usr/lib64/libruby.so James
Re: [gentoo-user] Re: @preserved-rebuild
On Mon, 28 Sep 2009 12:53:11 + (UTC), James wrote: for i in $(find /lib* /usr/lib*) ; do qfile -o $i ; done It worked like a charm, except there is a huge list? It overfilled my scroll back, so below is a tiny snippet. I'm weary of removing so many files? rm these files? revdep-rebuild comes back clean. Check with another tool? revdep-rebuild checks for binaries built against non-existent libraries, you are looking for surlpus libraries,so it won't help. You're already using the correct tool, qfile. I already synced and updated, do again? snip /usr/lib64/python2.6/site-packages/_xmlplus/dom/html/HTMLElement.pyo snip /usr/lib64/libblas.a /usr/lib64/libruby.so Ignore the .pyo and.pyc files, they are created by ebuilds after installation, so don't show up in the packages' contents. The .so files certainly look guilty, but move them somewhere rather than deleting, then run revdep-rebuild. -- Neil Bothwick Error reading FAT record: Try the SKINNY one? (Y/N) signature.asc Description: PGP signature
[gentoo-user] Re: @preserved-rebuild
Neil Bothwick neil at digimed.co.uk writes: Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? qfile -o $(find /lib* /usr/lib*) qfile -o $(find /lib* /usr/lib*) bash: /usr/bin/qfile: Argument list too long Now what? I look at the man page for qfile and tried all the -m option, but still get the same error? ideas? James
[gentoo-user] Re: @preserved-rebuild
On Sunday 27 September 2009, James wrote: Neil Bothwick neil at digimed.co.uk writes: Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? qfile -o $(find /lib* /usr/lib*) qfile -o $(find /lib* /usr/lib*) bash: /usr/bin/qfile: Argument list too long Now what? I look at the man page for qfile and tried all the -m option, but still get the same error? ideas? James for i in $(find /lib* /usr/lib*) ; do qfile -o $i ; done Ciao Francesco -- Linux Version 2.6.31-gentoo, Compiled #3 SMP PREEMPT Sat Sep 12 15:07:06 CEST 2009 Two 2.9GHz AMD Athlon 64 Processors, 4GB RAM, 11659 Bogomips Total aemaeth
Re: [gentoo-user] Re: @preserved-rebuild
Am Sun, 27 Sep 2009 18:20:52 +0200 schrieb Francesco Talamona francesco.talam...@know.eu: On Sunday 27 September 2009, James wrote: Neil Bothwick neil at digimed.co.uk writes: Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? qfile -o $(find /lib* /usr/lib*) qfile -o $(find /lib* /usr/lib*) bash: /usr/bin/qfile: Argument list too long Now what? I look at the man page for qfile and tried all the -m option, but still get the same error? ideas? James for i in $(find /lib* /usr/lib*) ; do qfile -o $i ; done Ciao Francesco It would be much faster to use find /lib* /usr/lib* | qfile -o -f - instead (see man qfile). HTH -- Marc Joliet -- Lt. Frank Drebin: It's true what they say: cops and women don't mix. Like eating a spoonful of Drāno; sure, it'll clean you out, but it'll leave you hollow inside. signature.asc Description: PGP signature
Re: [gentoo-user] Re: @preserved-rebuild
On Sat, 26 Sep 2009 01:23:31 + (UTC), James wrote: No apparent ill effects. You now have the old, orphaned version of the library on your system and unknown to portage. Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? Yes, qfile will help here qfile -o $(find /lib* /usr/lib*) -- Neil Bothwick Windows Error #01: No error... ...yet. signature.asc Description: PGP signature
[gentoo-user] Re: @preserved-rebuild
Jonathan Callen (ABCD abcd at gentoo.org writes: Rather than rebuilding kalgebra, unmerge it completely then emerge it again. It might be a problem with the emerge process for that package not using the latest version for some reason, so it is rebuilding against the old libs (which therefore remain preserved). Also, try removing /lib64/libreadline.so (not .so.5 or .so.5.2 !) first, so that kalgebra is forced to link against /usr/lib64/libreadline.so (which ends up pointing at /lib64/libreadline.so.6). My guess is that for some reason the linker is looking in /lib64 before checking /usr/lib64, and finding the wrong file first. OK, I'm in the process of trying all that has been suggested, along with syncing and rebuilding anything that complains. I'll post an update on the process, once I have exhausted all these ideas.. thx James
[gentoo-user] Re: @preserved-rebuild
Robin Atwood robin.atwood at attglobal.net writes: I had exactly the same problem. I solved it by deleting /var/lib/portage/preserved_libs_registry with no ill effects (since revdep- rebuild was clean). I did this as well as the previous suggestions. I also rebuilt xulrunner, in an attempt to emerge openoffice 3.1.0-r1, which is the only package that now needs to rebuild according to @preserved-rebuild Well all else is cleaned up except a complaint about openoffice . NOW I've lost my KDE-4 tool bar across the bottom of the screen ( I believe the first app is kde-launcher, but my kde verbiage could be way off). again. Before when this happened the fix was to reboot into an older kernel and run 'kbuildsycoca4' as a user. This fixed the identical problem a few days ago. This does not work now. see 21sep09 thread: KDE menu missing with new kernel revdep-rebuild is clean. The system is synced up and only openoffice 3.1 gives building complaints. My kde environment is 4.2.4 (via sets) and it seems like I fix one problem and another arises. aarrggg. any ideas? James
[gentoo-user] Re: @preserved-rebuild
Neil Bothwick neil at digimed.co.uk writes: No apparent ill effects. You now have the old, orphaned version of the library on your system and unknown to portage. Portage deletes these after emerge @preserved-rebuild has successfully re-emerged packages depending on it. OK, so now I just have to root it out manually.? I fixed the klauncher (menu) bar problem by just rebuilding 1/2 of the kde-base stuff... James
[gentoo-user] Re: @preserved-rebuild
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Paul Hartman wrote: On Thu, Sep 24, 2009 at 1:25 PM, James wirel...@tampabay.rr.com wrote: Hello, I keep getting this mesaage on one particulary system: existing preserved libs: package: sys-libs/readline-6.0_p3 * - /lib64/libreadline.so * - /lib64/libreadline.so.5 * - /lib64/libreadline.so.5.2 * used by /usr/bin/calgebra (kde-base/kalgebra-4.2.4) So I've rebuilt kalgegra, readline and revdep-rebuild comes up clean. I ran 'emerge @preserved-rebuild' numerous times and still I get this error message. Ideas on cleaning this up? It just happens on one system out of a dozen/plus gentoo boxes I manage.. Rather than rebuilding kalgebra, unmerge it completely then emerge it again. It might be a problem with the emerge process for that package not using the latest version for some reason, so it is rebuilding against the old libs (which therefore remain preserved). Also, try removing /lib64/libreadline.so (not .so.5 or .so.5.2 !) first, so that kalgebra is forced to link against /usr/lib64/libreadline.so (which ends up pointing at /lib64/libreadline.so.6). My guess is that for some reason the linker is looking in /lib64 before checking /usr/lib64, and finding the wrong file first. - -- Jonathan Callen (ABCD) -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.11 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iEYEARECAAYFAkq73xcACgkQOypDUo0oQOqriACfSrdCwExsBbmkSYLXqVQALWxT Yd4An2VAYc0Gy5Slx94QeKKbV+gceqeg =rgNN -END PGP SIGNATURE-
