Gentoo Archives: gentoo-user

From: Dale <rdalek1967@×××××.com>
To: gentoo-user@l.g.o
Subject: Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues
Date: Fri, 23 Oct 2015 09:43:10
Message-Id: 562A0120.6050509@gmail.com
In Reply to: Re: [gentoo-user] glibc upgrade and firefox/seamonkey issues by Peter Humphrey
1 Peter Humphrey wrote:
2 > On Thursday 22 October 2015 17:11:42 Dale wrote:
3 >> Alan McKinnon wrote:
4 >>> On 22/10/2015 23:51, Dale wrote:
5 >>>> Neil Bothwick wrote:
6 >>>>> On Thu, 22 Oct 2015 14:07:06 -0500, Dale wrote:
7 >>>>>> Of course, there is better ways of finding this info but I never can
8 >>>>>> remember the command and it takes me a bit to figure out what options
9 >>>>>> do what so I finally said "screw it" and work without it unless I just
10 >>>>>> must have it. If I only need one, I use the date command. It
11 >>>>>> works. ;-)
12 >>>>> genlop -l --date yesterday
13 >>>>>
14 >>>>> Not too hard to remember :)
15 >>>> It is when you only use it once every year or two. Generally, it is
16 >>>> rare that I have to even go look at the emerge log file. This is likely
17 >>>> the first time I have looked in there in a good long while. Maybe over a
18 >>>> year. Sometimes, I wonder if I even need the thing.
19 >>> Of course you need it - genlop won't work without it
20 >> That's the point. I rarely use it. The only genlop command I may use
21 >> every once in a while is genlop -c. I use that to see how long
22 >> something has been compiling or if it is a major upgrade, what is
23 >> actually being compiled at the time. Generally, the estimated time
24 >> remaining is worthless. Most of the time, it isn't even in the ballpark.
25 > Genlop is just a simple tool. I know of two cases it doesn't cope with well:
26 > first, simultaneous emerges of the same package in the main system and in a
27 > chroot; second, emerge -k.
28 >
29 > I sometimes do a batch of emerge -B followed with emerge -k. The time taken
30 > from emerge.log is tiny in that case, but genlop still includes it in its
31 > calculation of average emerge time.
32 >
33 > Any time I want to emerge -e world I do it that way. Also any KDE upgrade gets
34 > the same treatment: first compile the packages, then shut down KDE and install
35 > them. That way I don't get problems in trying to restart KDE when half its
36 > code has changed.
37 >
38
39
40 What I have noticed about the time estimation is this. When emerge is
41 working on several packages compiled in parallel, that slows each
42 package down. Instead of using all four cores to work on one package,
43 those four cores may be working on half a dozen packages. That alone
44 makes the time estimator wrong, sometimes by a lot. If I set portage to
45 compile only one package at a time, then it would be more accurate.
46 Thing is, it also makes it take longer.
47
48 I sometimes use -k but not to often. It can be handy tho. The times I
49 have used it is when I update Firefox/seamonkey and some plugin doesn't
50 work. I just go back to a earlier version until it gets fixed/updated.
51 Usually tho, Firefox/Seamonkey catches it and just disables the thing
52 instead of not coming up at all.
53
54 I do upgrades to KDE and just let it update while I am doing something
55 else, usually sleeping. When it gets done, I log out and back in and
56 the new stuff loads up. So far, I've never had any trouble with it.
57 The stuff it is using is usually already loaded anyway. Luck maybe.
58
59 Either way, I just don't use genlop much. I rarely use the q* commands
60 either. I use qlop -s on occasion to see when my last sync was but even
61 that is not to often. I generally do mine on Sundays, Tuesdays and
62 either Thursday or Friday. Sometimes if a check of the packages Gentoo
63 page shows little changes, I may skip a update or two.
64
65 Dale
66
67 :-) :-)