Re: [gentoo-user] scary (?) situation with binutils

[allan gottlieb]

On Mon, Sep 18 2017, allan gottlieb wrote:

> On Mon, Sep 18 2017, Andreas K. Huettel wrote:
>
>> No need to do anything complicated. Just run 
>>
>> emerge --depclean --ask
>>
>> and have it remove outdated binutils versions (it will keep the current one, 
>> and also then select it for usage automatically). 
>>
>> Then all these problems are gone...
>
> Thank you!
> allan

For others who may have encountered the infinite-emerge-binutils
problem, let me report that (as I am sure andreas knows) the depclean
fixes that problem while purging the masked versions of binutils.

Would that the depclean likely have fixed the infinite-emerge-binutils
problem several months ago when it first appeared.  I don't remember
seeing it proposed.

Once again, thank you!
allan

Re: [gentoo-user] scary (?) situation with binutils

[allan gottlieb]

On Mon, Sep 18 2017, Andreas K. Huettel wrote:

> No need to do anything complicated. Just run 
>
> emerge --depclean --ask
>
> and have it remove outdated binutils versions (it will keep the current one, 
> and also then select it for usage automatically). 
>
> Then all these problems are gone...

Thank you!
allan

Re: [gentoo-user] scary (?) situation with binutils

[Andreas K. Huettel]

Am Samstag, 16. September 2017, 22:31:03 CEST schrieb allan gottlieb:
> I am one of the users experiencing the
>infinite rebuild of binutils
> bug.  Today it took a turn I find worrisome
> 
> To summarize for months now after every emerge I get
> 
> !!! existing preserved libs:
> >>> package: sys-libs/binutils-libs-2.28.1
> 
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
[snip]

No need to do anything complicated. Just run 

emerge --depclean --ask

and have it remove outdated binutils versions (it will keep the current one, 
and also then select it for usage automatically). 

Then all these problems are gone...

-- 
Andreas K. Hüttel
dilfri...@gentoo.org
Gentoo Linux developer (council, perl, libreoffice)

Re: [gentoo-user] scary (?) situation with binutils

[Alan McKinnon]

On 16/09/2017 22:31, allan gottlieb wrote:
> I am one of the users experiencing the
>infinite rebuild of binutils
> bug.  Today it took a turn I find worrisome


Replying here so it's at the top.

Several things are happening, but I suppose the primary one is (and I
sorts need to be direct here):

Stop being scared and stop being confused by the big words. It's
blinding you to what is right there is plain sight right in front of you.

binutils has a history of getting itself and portage confused as to what
it needs and does not need with respect to preserved-rebuild. A few
other packages do this as well over the years. The most direct solution
is to simply unmerge the package, letting portage clean out the slate
and all the cruft, then merge the package back. The junk goes away,
portage sorts itself out, and stops it's whining.

The wrinkle as you point out is that you can't merge binutils without
bintils as you need ld. But never fear! this is Gentoo and you have all
the tools. Just quickpkg it, unmerge the damn thing and untar it back
like all the advise you've read tells you to do. Now you have an ld and
can properly merge binutils, so do so. portage will complain about file
collisions as expected, but because you are doing this in "yes, I DO
know what I am doing" mode, say yes.

That should fix your preserved-rebuild.


Now, for the masking notice. This is a completely different thing and
the only similarlity is that this sequence of letters "b,i,n,u,t,i,l,s"
shows up in both.

binutils is slotted. You have 2.28.1 and the mask applies to 2.25.1-r1
Portage is really saying "Yo dude, so this binutils you have? I've been
told to mask it and not just use it. You need to tell me if you want to
use it anyway, or if I can kill it with fire, or what."

It's a simple problem of deciding what you want to do. 2.25 is ancient,
so if you have it installed for some reason, you should find out why and
deal with that. It's probably safe, but you do need to find why you have
it first. Then proceed as a routine package removal (which is actually
all this is).


> 
> To summarize for months now after every emerge I get
> 
> !!! existing preserved libs:
> >>> package: sys-libs/binutils-libs-2.28.1
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> If if then
> emerge @preserved-rebuild
> it rebuilds binutils but I still get the above message.  I have rebuilt
> it at least a dozen times in the past months.
> 
> A solution was posted that involved making a quickpkg (I think),
> unmerging binutils, and then manually untaring (after the unmerge of
> binutils you can't simply remerge since ld is gone).
> 
> This solution frightened me and I am living with always being told to run
>emerge @preserved-rebuild
> and actually doing that fruitless emerge about once a month.
> 
> Today was different, I guess because binutils-lib was involved
> 
> My "twice-weekly"
>emerge --update --changed-use --with-bdeps=y @world
> resulted in
> Calculating dependencies... done!
> [ebuild  NS] sys-kernel/gentoo-sources-4.12.12 [3.10.3-r1, 3.11.0, 
> 3.12.13, 3.18.11, 3.18.12, 4.0.5, 4.0.9, 4.1.12, 4.1.15-r1, 4.4.6, 4.4.21, 
> 4.4.26, 4.4.39, 4.9.6-r1, 4.9.16, 4.9.34, 4.12.5] USE="-build -experimental 
> -symlink" 
> [ebuild U  ] www-plugins/adobe-flash-27.0.0.130-r1 [27.0.0.130]
> [ebuild  rR]  x11-libs/cairo-1.14.8 
> [ebuild  r  U  ]   sys-libs/binutils-libs-2.28.1 [2.28-r1]
> 
> The following packages are causing rebuilds:
> 
>   (sys-libs/binutils-libs-2.28.1:0/2.28.1::gentoo, ebuild scheduled for 
> merge) causes rebuilds for:
> (x11-libs/cairo-1.14.8:0/0::gentoo, ebuild scheduled for merge)
> 
> When the emerge finished I received the usual
> 
> !!! existing preserved libs:
 package: sys-libs/binutils-libs-2.28.1
>  *  - /usr/lib64/libbfd-2.25.1.so
>  *  used by 
> /usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
> (sys-devel/binutils-2.25.1-r1)
> Use emerge @preserved-rebuild to rebuild packages using these libraries
> 
> But when I ran
>   emerge @preserved-rebuild
> out came the following
> 
>   The following mask changes are necessary to proceed:
>(see "package.unmask" in the portage(5) man page for more details)
>   # required by @preserved-rebuild (argument)
>   # /var/portage/profiles/package.mask:
>   # Michał Górny , Andreas K. Hüttel 
> ,
>   # Matthias Maier  (21 May 2017)
>   # These old versions of toolchain packages (binutils, gcc, glibc) are no
>   # longer officially supported and are not suitable for general use. Using
>   # these packages can result in build failures (and possible breakage) for
>   # many packages, and may leave your system vulnerable to known security
>   # exploits.
>   

[gentoo-user] scary (?) situation with binutils

[allan gottlieb]

I am one of the users experiencing the
   infinite rebuild of binutils
bug.  Today it took a turn I find worrisome

To summarize for months now after every emerge I get

!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.28.1
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries

If if then
emerge @preserved-rebuild
it rebuilds binutils but I still get the above message.  I have rebuilt
it at least a dozen times in the past months.

A solution was posted that involved making a quickpkg (I think),
unmerging binutils, and then manually untaring (after the unmerge of
binutils you can't simply remerge since ld is gone).

This solution frightened me and I am living with always being told to run
   emerge @preserved-rebuild
and actually doing that fruitless emerge about once a month.

Today was different, I guess because binutils-lib was involved

My "twice-weekly"
   emerge --update --changed-use --with-bdeps=y @world
resulted in
Calculating dependencies... done!
[ebuild  NS] sys-kernel/gentoo-sources-4.12.12 [3.10.3-r1, 3.11.0, 3.12.13, 
3.18.11, 3.18.12, 4.0.5, 4.0.9, 4.1.12, 4.1.15-r1, 4.4.6, 4.4.21, 4.4.26, 
4.4.39, 4.9.6-r1, 4.9.16, 4.9.34, 4.12.5] USE="-build -experimental -symlink" 
[ebuild U  ] www-plugins/adobe-flash-27.0.0.130-r1 [27.0.0.130]
[ebuild  rR]  x11-libs/cairo-1.14.8 
[ebuild  r  U  ]   sys-libs/binutils-libs-2.28.1 [2.28-r1]

The following packages are causing rebuilds:

  (sys-libs/binutils-libs-2.28.1:0/2.28.1::gentoo, ebuild scheduled for merge) 
causes rebuilds for:
(x11-libs/cairo-1.14.8:0/0::gentoo, ebuild scheduled for merge)

When the emerge finished I received the usual

!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.28.1
 *  - /usr/lib64/libbfd-2.25.1.so
 *  used by 
/usr/lib64/binutils/x86_64-pc-linux-gnu/2.25.1/libopcodes-2.25.1.so 
(sys-devel/binutils-2.25.1-r1)
Use emerge @preserved-rebuild to rebuild packages using these libraries

But when I ran
  emerge @preserved-rebuild
out came the following

  The following mask changes are necessary to proceed:
   (see "package.unmask" in the portage(5) man page for more details)
  # required by @preserved-rebuild (argument)
  # /var/portage/profiles/package.mask:
  # Michał Górny , Andreas K. Hüttel ,
  # Matthias Maier  (21 May 2017)
  # These old versions of toolchain packages (binutils, gcc, glibc) are no
  # longer officially supported and are not suitable for general use. Using
  # these packages can result in build failures (and possible breakage) for
  # many packages, and may leave your system vulnerable to known security
  # exploits.
  # If you still use one of these old toolchain packages, please upgrade (and
  # switch the compiler / the binutils) ASAP. If you need them for a specific
  # (isolated) use case, feel free to unmask them on your system.
  =sys-devel/binutils-2.25.1-r1
  
  NOTE: The --autounmask-keep-masks option will prevent emerge
from creating package.unmask or ** keyword changes.

  Would you like to add these changes to your config files? [Yes/No]

I said no since I don't want to unmask, but am not sure how to proceed

Thanks in advance for any help.

allan