Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 05/13/2017 06:05 PM, lee wrote:
> It worked --- now some time when I do upgrade the kernel, I somehow need
> to remove these sources from the world list, I guess ...
> 

That's easy: `emerge --deselect sys-kernel/gentoo-sources:4.4.52` undoes
my previous suggestion.

Dan

Re: [gentoo-user] Pseudo first impressions

[Neil Bothwick]

On Sun, 14 May 2017 02:05:58 +0100, lee wrote:

> > It will only remove things that it deems not needed. Usually these are
> > packages that have just been upgraded.  
> 
> Yes, the sources wouldn't be needed if I had upgraded the kernel.  Still
> one might expect it to figure out which kernel is in use and to not try
> to delete it --- that would make some sense.

This is Gentoo, you have to make most of the decisions yourself. You
don't necessarily need the sources for the running kernel.

> > For kernel sources, tell portage to not remove it:
> >
> > `emerge --noreplace sys-kernel/gentoo-sources:4.4.52`
> >
> > as an example.
> >
> > If you do that, --depclean will not remove the sources for 4.4.52 (as
> > an example.)  
> 
> Thanks, I couldn't find an option like this.

It's in the emerge man page.

Alternatively, you can create a set that ensures no kernel sources are
ever depcleaned. Add this to /etc/portage/sets.conf

[kernels]
class = portage.sets.dbapi.OwnerSet
world-candidate = False
files = /usr/src

and add the kernels set to world with this

emerge -n @kernels

Now any kernel sources you install will not be removed until you
specifically instruct portage to do so.

> It worked --- now some time when I do upgrade the kernel, I somehow need
> to remove these sources from the world list, I guess ...

They will be removed when you manually unmerge the kernel

emerge -Ca \=sys-kernel/gentoo-sources:4.4.52


-- 
Neil Bothwick

The sergeant walked into the shower and caught me giving myself a
dishonorable discharge. Without missing a beat, I said, "It's my dick
and I can wash it as fast as I want!"


pgpEFg5WIq8_f.pgp
Description: OpenPGP digital signature

Re: [gentoo-user] Pseudo first impressions

[lee]

Daniel Frey  writes:

> On 04/29/2017 06:23 PM, lee wrote:
>> Daniel Frey  writes:
>>> Do a --depclean and that will resolve itself.
>> 
>> Last time I tried that, it wanted to remove the source of the kernel I'm
>> using, along with other things.  It would have made sense if I had
>> upgraded the kernel, too, but I didn't have the time to do that yet.
>> 
>> 
>
> It will only remove things that it deems not needed. Usually these are
> packages that have just been upgraded.

Yes, the sources wouldn't be needed if I had upgraded the kernel.  Still
one might expect it to figure out which kernel is in use and to not try
to delete it --- that would make some sense.

> For kernel sources, tell portage to not remove it:
>
> `emerge --noreplace sys-kernel/gentoo-sources:4.4.52`
>
> as an example.
>
> If you do that, --depclean will not remove the sources for 4.4.52 (as an
> example.)

Thanks, I couldn't find an option like this.

It worked --- now some time when I do upgrade the kernel, I somehow need
to remove these sources from the world list, I guess ...


-- 
"Didn't work" is an error.

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 06:23 PM, lee wrote:
> Daniel Frey  writes:
>> Do a --depclean and that will resolve itself.
> 
> Last time I tried that, it wanted to remove the source of the kernel I'm
> using, along with other things.  It would have made sense if I had
> upgraded the kernel, too, but I didn't have the time to do that yet.
> 
> 

It will only remove things that it deems not needed. Usually these are
packages that have just been upgraded.

For kernel sources, tell portage to not remove it:

`emerge --noreplace sys-kernel/gentoo-sources:4.4.52`

as an example.

If you do that, --depclean will not remove the sources for 4.4.52 (as an
example.)

Dan

Re: [gentoo-user] Pseudo first impressions

[lee]

Daniel Frey  writes:

> On 04/29/2017 01:38 PM, lee wrote:
>> !!! existing preserved libs:
> package: sys-libs/binutils-libs-2.27
>>  *  - /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
>> 
>> 
>> 
>> It's not possible to emerge net-dns/bind (I'm guessing that might be
>> because of binutils having some issue) and mysql-workbench.  The old
>> version of bind is still working, but what if it wasn't already
>> installed?  Also, I had to patch dev-perl/GD to get that to work.  What
>> will fail next?
>> 
>> So yes, it's not only about updates but about installing something in
>> general: It may work or not, and it may break other things or not, or it
>> may require you to do something because something has been pulled into
>> something by something, or you need to remove something, or something
>> doesn't work because of something ...
>> 
>> 
>
> Do a --depclean and that will resolve itself.

Last time I tried that, it wanted to remove the source of the kernel I'm
using, along with other things.  It would have made sense if I had
upgraded the kernel, too, but I didn't have the time to do that yet.


-- 
"Didn't work" is an error.

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 10:28 AM, J. Roeleveld wrote:
> 
> I found on several systems that using "--backtrack=100" actually resolved the 
> latest blockers with perl.
> 

I find doing `emerge --oneshot --nodeps perl` then `perl-cleaner --all`
was faster. Portage would chug for over five minutes on some of my
machines trying to resolve the dependencies. By the time it figured out
what it wanted to do, the manual way I used was almost finished.

(Do note the CPU is slow on the machines I use but compiling is done
with distcc so that was done relatively quickly.)

Dan

Re: [gentoo-user] Pseudo first impressions

[Daniel Frey]

On 04/29/2017 01:38 PM, lee wrote:
> !!! existing preserved libs:
 package: sys-libs/binutils-libs-2.27
>  *  - /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
> 
> 
> 
> It's not possible to emerge net-dns/bind (I'm guessing that might be
> because of binutils having some issue) and mysql-workbench.  The old
> version of bind is still working, but what if it wasn't already
> installed?  Also, I had to patch dev-perl/GD to get that to work.  What
> will fail next?
> 
> So yes, it's not only about updates but about installing something in
> general: It may work or not, and it may break other things or not, or it
> may require you to do something because something has been pulled into
> something by something, or you need to remove something, or something
> doesn't work because of something ...
> 
> 

Do a --depclean and that will resolve itself.

Dan

Re: [gentoo-user] Pseudo first impressions

[lee]

Alan Mackenzie  writes:

> For a start, I could barely read parts of it, which were displayed in
> dark blue text on a black background.

Yes, that always annoys me, too.  You need to copy it from the terminal
and paste it into emacs, and then it's still not exactly readable or
even understandable.

> Setting up /etc/portage/color.map is not the first thing a new user
> should have to do to be able to read messages from emerge.  This is,
> however, something I knew had to be done, and I did it.

I didn't know that there's such a thing.  That should be mentioned in
the docs.

> The error message was "Multiple package instances within a single
> package slot have been pulled into the dependency graph, resulting in a
> slot conflict:".  Uhh???

Yeah, I never saw that graph.

> Is this gobbledegook really what a new user should be seeing, having not
> yet installed any packages, bar a very few, beyond what is requisite to
> bringing a new machine up?

The common answer to this is that the devs don't have time and/or can't
be bothered to improve this, and it's too complicated anyway.

> The actual conflict packages are:
> dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>   and
> dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
> , "pulled in" by internal system packages I've got no direct interest
> in, plus, shockingly, "and 2 more with the same problem" and "and 5 more
> with the same problem".

It's usually hundreds, not only 2 or 5.

> I'm glad I've got the experience with Gentoo to know it's worth
> ploughing on through these messes.

How's all the pain worth it?  It's not even all about the pain, it's
about keeping things working and up to date.  Even just that may be
impossible with Gentoo, even if you have the time.

> Other than that, it seems like a pretty ghastly mistake by Gentoo's
> quality control.  I know none of you get paid for it, and you all do it
> for love.  I admit I probably wouldn't have done the job much better
> myself.  But for Gentoo's sake, something needs to get better.

Being able to update at all would be a good start.


BTW, what's with this:


emerge -a feh
[...]
!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.27
 *  - /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

emerge @preserved-rebuild
[...]
>>> Emerging (1 of 1) sys-devel/binutils-2.25.1-r1::gentoo
[...]
>>> Installing (1 of 1) sys-devel/binutils-2.25.1-r1::gentoo
>>> Jobs: 1 of 1 complete   Load avg: 3.41, 1.36, 0.60
[...]
!!! existing preserved libs:
>>> package: sys-libs/binutils-libs-2.27
 *  - /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



It's not possible to emerge net-dns/bind (I'm guessing that might be
because of binutils having some issue) and mysql-workbench.  The old
version of bind is still working, but what if it wasn't already
installed?  Also, I had to patch dev-perl/GD to get that to work.  What
will fail next?

So yes, it's not only about updates but about installing something in
general: It may work or not, and it may break other things or not, or it
may require you to do something because something has been pulled into
something by something, or you need to remove something, or something
doesn't work because of something ...


-- 
"Didn't work" is an error.

Re: [gentoo-user] Pseudo first impressions

[J. Roeleveld]

On April 29, 2017 4:39:13 PM GMT+02:00, Alan Mackenzie  wrote:
>Hello, Gentoo.
>
>Now able to boot into my new hardware, one of the first things I did
>was
>
># emerge --sync
>
>.  Fine.  The next thing I tried was
>
># emerge -auND @world
>
>, which is probably recommended in the handbook.  This was anything but
>fine.
>
>I'm glad I'm not a real Gentoo newby, because I would have been
>completely flumoxed by what came up on my screen.
>
>For a start, I could barely read parts of it, which were displayed in
>dark blue text on a black background.  Setting up
>/etc/portage/color.map
>is not the first thing a new user should have to do to be able to read
>messages from emerge.  This is, however, something I knew had to be
>done, and I did it.
>
>The error message was "Multiple package instances within a single
>package slot have been pulled into the dependency graph, resulting in a
>slot conflict:".  Uhh???
>
>Is this gobbledegook really what a new user should be seeing, having
>not
>yet installed any packages, bar a very few, beyond what is requisite to
>bringing a new machine up?
>
>The actual conflict packages are:
>dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>  and
>dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
>, "pulled in" by internal system packages I've got no direct interest
>in, plus, shockingly, "and 2 more with the same problem" and "and 5
>more
>with the same problem".
>
>I'm glad I've got the experience with Gentoo to know it's worth
>ploughing on through these messes.
>
>Other than that, it seems like a pretty ghastly mistake by Gentoo's
>quality control.  I know none of you get paid for it, and you all do it
>for love.  I admit I probably wouldn't have done the job much better
>myself.  But for Gentoo's sake, something needs to get better.

Alan,

I found on several systems that using "--backtrack=100" actually resolved the 
latest blockers with perl.

--
Joost
-- 
Sent from my Android device with K-9 Mail. Please excuse my brevity.

Re: [gentoo-user] Pseudo first impressions

[Mick]

On Saturday 29 Apr 2017 14:39:13 Alan Mackenzie wrote:
> Hello, Gentoo.
> 
> Now able to boot into my new hardware, one of the first things I did was
> 
> # emerge --sync
> 
> .  Fine.  The next thing I tried was
> 
> # emerge -auND @world
> 
> , which is probably recommended in the handbook.  This was anything but
> fine.
> 
> I'm glad I'm not a real Gentoo newby, because I would have been
> completely flumoxed by what came up on my screen.
> 
> For a start, I could barely read parts of it, which were displayed in
> dark blue text on a black background.  Setting up /etc/portage/color.map
> is not the first thing a new user should have to do to be able to read
> messages from emerge.  This is, however, something I knew had to be
> done, and I did it.
> 
> The error message was "Multiple package instances within a single
> package slot have been pulled into the dependency graph, resulting in a
> slot conflict:".  Uhh???
> 
> Is this gobbledegook really what a new user should be seeing, having not
> yet installed any packages, bar a very few, beyond what is requisite to
> bringing a new machine up?
> 
> The actual conflict packages are:
> dev-lang/perl-5.24.1-r1:0/5.24::gentoo
>   and
> dev-lang/perl-5.22.3-rc4:0/5.22::gentoo
> , "pulled in" by internal system packages I've got no direct interest
> in, plus, shockingly, "and 2 more with the same problem" and "and 5 more
> with the same problem".
> 
> I'm glad I've got the experience with Gentoo to know it's worth
> ploughing on through these messes.
> 
> Other than that, it seems like a pretty ghastly mistake by Gentoo's
> quality control.  I know none of you get paid for it, and you all do it
> for love.  I admit I probably wouldn't have done the job much better
> myself.  But for Gentoo's sake, something needs to get better.

Try running:

perl-cleaner --reallyall

Then try 'emerge -uaNDv world' again.
-- 
Regards,
Mick

signature.asc
Description: This is a digitally signed message part.