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 |
:-) :-) |