genlop treats emerge times identically even when a package is installed from a binary package. This makes "genlop -c" output ETAs that are way off. To illustrate: $ genlop -t mozilla-firefox --date 5 days ago * www-client/mozilla-firefox Thu Jan 26 12:55:49 2006 >>> www-client/mozilla-firefox-1.5.0.1_rc1 merge time: 45 minutes and 46 seconds. Mon Jan 30 10:23:03 2006 >>> www-client/mozilla-firefox-1.5.0.1_rc1 merge time: 31 seconds. Mon Jan 30 12:27:08 2006 >>> www-client/mozilla-firefox-1.5.0.1_rc1 merge time: 44 minutes and 40 seconds. And the estimate would be... what 1/3 of (45 min + 31 sec + 44 min)? As to the version... $ equery l genlop [ Searching for package 'genlop' in all categories among: ] * installed packages [I--] [ ] app-portage/genlop-0.30.5 (0) $ genlop -v genlop 0.30.4 by Giorgio Mandolfo and Antonio Dolcetta please send praise to Giorgio <giorgio@pollycoke.org> and bugs/flames to Antonio <adolcetta@infracom.it> Copyright 2004 Giorgio Mandolfo. Distribuited under the GPL v2. See COPYING for details
After some advice on IRC: (12:38:46 PM) chutz: it [genlop] should ignore binary emerges in emerge.log (12:39:08 PM) antarus: how about just marking them as a binary merge (12:39:15 PM) chutz: the problem is with genlop -c (12:39:28 PM) chutz: it seems to take the average of all emerges (12:39:30 PM) chutz: even the binary ones And a RFE: (12:40:35 PM) chutz: in fact, "genlop -p" could recognize the "binary" and output proper times!
genlop just analyzes /var/log/emerge.log so unless portage itself already says whether it's emerging a binary package or a regular one ...
(In reply to comment #2) > genlop just analyzes /var/log/emerge.log > > so unless portage itself already says whether it's emerging a binary package or > a regular one ... I really hope these don't get wrapped: $ grep -i binary /var/log/emerge.log | tail 1137641682: === (2 of 42) Merging Binary (dev-perl/Net-IP-1.24::/usr/portage-dell/packages/All/Net-IP-1.24.tbz2) 1137642097: === (1 of 41) Merging Binary (dev-perl/Net-IP-1.24::/usr/portage-dell/packages/All/Net-IP-1.24.tbz2) 1138067506: === (6 of 39) Merging Binary (gnome-base/orbit-2.12.4::/usr/portage-dell/packages/All/orbit-2.12.4.tbz2) 1138094019: === (1 of 2) Merging Binary (x11-misc/gccmakedep-1.0.1::/usr/portage-dell/packages/All/gccmakedep-1.0.1.tbz2) 1138094265: === (1 of 2) Merging Binary (virtual/x11-6.8::/usr/portage-dell/packages/All/x11-6.8.tbz2) 1138095259: === (1 of 1) Merging Binary (net-misc/vnc-4.0-r1::/usr/portage-dell/packages/All/vnc-4.0-r1.tbz2) 1138271336: === (1 of 1) Merging Binary (media-gfx/inkscape-0.43::/usr/portage-dell/packages/All/inkscape-0.43.tbz2) 1138584124: === (1 of 1) Merging Binary (www-client/mozilla-firefox-1.5.0.1_rc1::/usr/portage-dell/packages/All/mozilla-firefox-1.5.0.1_rc1.tbz2) 1138584152: === (1 of 1) Merging Binary (www-client/mozilla-firefox-1.5.0.1_rc1::/usr/portage-dell/packages/All/mozilla-firefox-1.5.0.1_rc1.tbz2) 1138592519: === (1 of 1) Merging Binary (x11-themes/gtk-engines-2.6.7::/usr/portage-dell/packages/All/gtk-engines-2.6.7.tbz2)
yes, but i'm pretty sure that output is also logged if you do `FEATURES=buildpkg emerge foo`
(In reply to comment #4) > yes, but i'm pretty sure that output is also logged if you do > `FEATURES=buildpkg emerge foo` Have you tried it? I've been using "emerge -b" for quite a while now... $ ls packages/All | wc -l 924 And still there are only 199 entries in emerge.log chutz@ols-dell ~ $ awk -F: '/Merging Binary/ { print ++n, strftime("%c",$1) }' /var/log/emerge.log | head -n 1 1 Thu 19 Feb 2004 03:26:03 PM JST chutz@ols-dell ~ $ ^head^tail awk -F: '/Merging Binary/ { print ++n, strftime("%c",$1) }' /var/log/emerge.log | tail -n 1 199 Mon 30 Jan 2006 12:41:59 PM JST
FEATURES=buildpkg doesn't have an impact apparently: phish blubb # tail /var/log/emerge.log 1141422114: === (1 of 1) Cleaning (app-vim/gentoo-syntax-20051221::/usr/portage/app-vim/gentoo-syntax/gentoo-syntax-20051221.ebuild) 1141422115: === (1 of 1) Compiling/Packaging (app-vim/gentoo-syntax-20051221::/usr/portage/app-vim/gentoo-syntax/gentoo-syntax-20051221.ebuild) 1141422118: === (1 of 1) Merging (app-vim/gentoo-syntax-20051221::/usr/portage/app-vim/gentoo-syntax/gentoo-syntax-20051221.ebuild) 1141422139: === (1 of 1) Updating world file (app-vim/gentoo-syntax-20051221) 1141422139: === (1 of 1) Post-Build Cleaning (app-vim/gentoo-syntax-20051221::/usr/portage/app-vim/gentoo-syntax/gentoo-syntax-20051221.ebuild) 1141422139: >>> AUTOCLEAN: app-vim/gentoo-syntax 1141422144: === Unmerging... (app-vim/gentoo-syntax-20050618) 1141422148: >>> unmerge success: app-vim/gentoo-syntax-20050618 1141422148: ::: completed emerge (1 of 1) app-vim/gentoo-syntax-20051221 to / 1141422148: *** Finished. Cleaning up...
Perhaps genlop should simply cast out outliers. If there are multiple instances that are several minutest long, I would say to just ignore the install that only lasted 31 seconds. That is how I was taught to calculate the average anyway.
(In reply to comment #5) > (In reply to comment #4) > > yes, but i'm pretty sure that output is also logged if you do > > `FEATURES=buildpkg emerge foo` > > Have you tried it? I've been using "emerge -b" for quite a while now... > > $ ls packages/All | wc -l > 924 > > And still there are only 199 entries in emerge.log > > chutz@ols-dell ~ $ awk -F: '/Merging Binary/ { print ++n, strftime("%c",$1) }' > /var/log/emerge.log | head -n 1 > 1 Thu 19 Feb 2004 03:26:03 PM JST > chutz@ols-dell ~ $ ^head^tail > awk -F: '/Merging Binary/ { print ++n, strftime("%c",$1) }' > /var/log/emerge.log | tail -n 1 > 199 Mon 30 Jan 2006 12:41:59 PM JST > Actually -b and FEATURES="buildpkg" don't merge binaries, they simply create binaries to be merged later. "Merging Binary" in emerge.log comes from emerge [-k|--usepkg] or emerge [-K|--usepkgonly] These merges are the ones genlop should ignore
Mike, your choice.
