Re: [gentoo-user] Re: Pseudo first impressions

[lee]

Kai Krakow  writes:

> Am Sat, 29 Apr 2017 14:39:13 +
> schrieb Alan Mackenzie :
>
>> 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.
>
> This is a problem with most terminal emulators having a much too dark
> "dark blue".

Gentoo is being designed by and for ppl using CRTs?


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

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sun, 30 Apr 2017 00:56:40 -0500
schrieb R0b0t1 :

> On Sun, Apr 30, 2017 at 12:14 AM, Kai Krakow 
> wrote:
> > Am Sat, 29 Apr 2017 14:39:13 +
> > schrieb Alan Mackenzie :
> >  
> >> 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.  
> >
> > This is a problem with most terminal emulators having a much too
> > dark "dark blue". On an old DOS CRT, this dark blue was still
> > bright enough to be read easily on black background. Especially, I
> > found PuTTY in Windows having a dark blue barely readable.
> >
> > E.g., in KDE Konsole I usually switch to a different terminal color
> > scheme which usually gets around this. But then, contrast on bright
> > colors is usually very bad, as can be seen in MC at some points. But
> > the new "breeze" color scheme from current Plasma versions is quite
> > nice and an overall good fit.
> >  
> 
> I have occasionally had this problem (and the reverse - green and
> yellow are unreadable on light backgrounds), but the default colors in
> URxvt are fairly reasonable.

Much depends on a reasonable color palette in the terminal emulator.
There are only few that get it right.

> Not to derail this thread but what is the process for getting changes
> into the handbook? I have some suggestions as well, but still only
> have a vague idea of how it is maintained. There's a lot that could be
> added in relation to maintaining modern systems, and many of the
> changes to portage could be added. (E.g. there's people who will come
> into the IRC and have a conglomeration of settings that, based on the
> quirks and naming conventions, you can tell were taken from 3-4 places
> each being published years apart. There probably needs to be some
> basic information all in one place.)

There's the Gentoo wiki. I don't know if you need special privileges or
if it's open to everyone to put in improvements. And then, there's
always the BGO (bugs.gentoo.org) where you can suggest even handbook
improvements by selecting the proper bug component.

> And in reply to the Perl problem, though my response probably isn't
> needed: I can verify that using a high backtrack number solved this,
> and that the dependency chain was the longest I have seen save one
> other time.

Usually, using "reinstall-atoms" works much better for me (and it's
faster in most cases because when emerge dumps all those stuff and I
see it's easily resolvable by reinstall-atoms, I do that, instead of
using a high backtrack value, waiting for ages again, only to see that
it may not solve my problem).


-- 
Regards,
Kai

Replies to list-only preferred.

Re: [gentoo-user] Re: Pseudo first impressions

[R0b0t1]

On Sun, Apr 30, 2017 at 12:14 AM, Kai Krakow  wrote:
> Am Sat, 29 Apr 2017 14:39:13 +
> schrieb Alan Mackenzie :
>
>> 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.
>
> This is a problem with most terminal emulators having a much too dark
> "dark blue". On an old DOS CRT, this dark blue was still bright enough
> to be read easily on black background. Especially, I found PuTTY in
> Windows having a dark blue barely readable.
>
> E.g., in KDE Konsole I usually switch to a different terminal color
> scheme which usually gets around this. But then, contrast on bright
> colors is usually very bad, as can be seen in MC at some points. But
> the new "breeze" color scheme from current Plasma versions is quite
> nice and an overall good fit.
>

I have occasionally had this problem (and the reverse - green and
yellow are unreadable on light backgrounds), but the default colors in
URxvt are fairly reasonable.

Not to derail this thread but what is the process for getting changes
into the handbook? I have some suggestions as well, but still only
have a vague idea of how it is maintained. There's a lot that could be
added in relation to maintaining modern systems, and many of the
changes to portage could be added. (E.g. there's people who will come
into the IRC and have a conglomeration of settings that, based on the
quirks and naming conventions, you can tell were taken from 3-4 places
each being published years apart. There probably needs to be some
basic information all in one place.)


And in reply to the Perl problem, though my response probably isn't
needed: I can verify that using a high backtrack number solved this,
and that the dependency chain was the longest I have seen save one
other time.

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sat, 29 Apr 2017 20:53:50 -0700
schrieb Ian Zimmerman :

> On 2017-04-30 02:23, lee wrote:
> 
> > > 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.  
> 
> emerge --select =sys-kernel/gentoo-sources-${VERSION}
> 
> or add a line for the exact version to the world file manually

If you give a slot instead of a version, it will record that slot in
the world file, which is usually more appropriate:

# emerge --select sys-kernel/gentoo-sources:${VERSION}

No need to add that manually then.

Kernel versions are slotted per minor version, so it is essentially the
same for your example.

-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Pseudo first impressions

[Kai Krakow]

Am Sat, 29 Apr 2017 14:39:13 +
schrieb Alan Mackenzie :

> 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.

This is a problem with most terminal emulators having a much too dark
"dark blue". On an old DOS CRT, this dark blue was still bright enough
to be read easily on black background. Especially, I found PuTTY in
Windows having a dark blue barely readable.

E.g., in KDE Konsole I usually switch to a different terminal color
scheme which usually gets around this. But then, contrast on bright
colors is usually very bad, as can be seen in MC at some points. But
the new "breeze" color scheme from current Plasma versions is quite
nice and an overall good fit.

> 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???

This wouldn't happen if this would actually be a new system with vendor
stage tarball. I guess you're upgrading an existing system from new
hardware.

> 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".

This, and similar conflicts, can be easily resolved by forcing rebuilds
of the packages marked in blue in the conflict tree. I particular, here
it works by running:

# emerge -DNua world --reinstall-atoms "$(qlist -ICS dev-perl/
virtual/perl-)"

I found "reinstall-atoms" to become very handy lately. Emerge seems to
be pretty bad at determining rebuilds of dependents in world upgrades,
even when using big backtrack values. Also, bigger backtrack values
increase deptree calculation by a huge factor, especially when emerge
isn't able to figure it out anyways.

You may want to remove all perl virtuals first, which is essentially
what perl-cleaner also does in a first step:

# emerge -Ca $(qlist -IC virtual/perl-)


-- 
Regards,
Kai

Replies to list-only preferred.

[gentoo-user] Re: Pseudo first impressions

[Ian Zimmerman]

On 2017-04-30 02:23, lee wrote:

> > 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.

emerge --select =sys-kernel/gentoo-sources-${VERSION}

or add a line for the exact version to the world file manually

-- 
Please *no* private Cc: on mailing lists and newsgroups
Personal signed mail: please _encrypt_ and sign
Don't clear-text sign:
http://primate.net/~itz/blog/the-problem-with-gpg-signatures.html