Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues

[Peter Humphrey]

On Thursday 22 October 2015 17:11:42 Dale wrote:
> Alan McKinnon wrote:
> > On 22/10/2015 23:51, Dale wrote:
> >> Neil Bothwick wrote:
> >>> On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:
> >>>> Of course, there is better ways of finding this info but I never can
> >>>> remember the command and it takes me a bit to figure out what options
> >>>> do what so I finally said "screw it" and work without it unless I just
> >>>> must have it.  If I only need one, I use the date command.  It
> >>>> works.  ;-)
> >>>
> >>> genlop -l --date yesterday
> >>>
> >>> Not too hard to remember :)
> >>
> >> It is when you only use it once every year or two.  Generally, it is
> >> rare that I have to even go look at the emerge log file.  This is likely
> >> the first time I have looked in there in a good long while. Maybe over a
> >> year.  Sometimes, I wonder if I even need the thing.
> >
> > Of course you need it - genlop won't work without it
>
> That's the point.  I rarely use it.  The only genlop command I may use
> every once in a while is genlop -c.  I use that to see how long
> something has been compiling or if it is a major upgrade, what is
> actually being compiled at the time.  Generally, the estimated time
> remaining is worthless.  Most of the time, it isn't even in the ballpark.

Genlop is just a simple tool. I know of two cases it doesn't cope with well: 
first, simultaneous emerges of the same package in the main system and in a 
chroot; second, emerge -k.

I sometimes do a batch of emerge -B followed with emerge -k. The time taken 
from emerge.log is tiny in that case, but genlop still includes it in its 
calculation of average emerge time.

Any time I want to emerge -e world I do it that way. Also any KDE upgrade gets 
the same treatment: first compile the packages, then shut down KDE and install 
them. That way I don't get problems in trying to restart KDE when half its 
code has changed.

-- 
Rgds
Peter