Peter Humphrey wrote: > 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. >
What I have noticed about the time estimation is this. When emerge is working on several packages compiled in parallel, that slows each package down. Instead of using all four cores to work on one package, those four cores may be working on half a dozen packages. That alone makes the time estimator wrong, sometimes by a lot. If I set portage to compile only one package at a time, then it would be more accurate. Thing is, it also makes it take longer. I sometimes use -k but not to often. It can be handy tho. The times I have used it is when I update Firefox/seamonkey and some plugin doesn't work. I just go back to a earlier version until it gets fixed/updated. Usually tho, Firefox/Seamonkey catches it and just disables the thing instead of not coming up at all. I do upgrades to KDE and just let it update while I am doing something else, usually sleeping. When it gets done, I log out and back in and the new stuff loads up. So far, I've never had any trouble with it. The stuff it is using is usually already loaded anyway. Luck maybe. Either way, I just don't use genlop much. I rarely use the q* commands either. I use qlop -s on occasion to see when my last sync was but even that is not to often. I generally do mine on Sundays, Tuesdays and either Thursday or Friday. Sometimes if a check of the packages Gentoo page shows little changes, I may skip a update or two. Dale :-) :-)
