as root, `qlop -r` for me literally never says anything. There are other bugs, but they all talk about how long it takes, or focuses on parallel building. But for me, I can't get `qlop -r` to ever show any output as root. I can only get the heurstic mode giving output. qlop -vr qlop: insufficient privileges for full /proc access, running merges are based on heuristics 2020-10-01T12:55:07 >>> net-p2p/qbittorrent-9999... (1 of 2) ETA: 16s (average run) 2020-10-01T11:08:25 >>> gnome-extra/libgda-5.2.9... +1:41:43 2020-10-01T09:04:13 >>> dev-lang/mono-6.10.0.104... +1:23:25 2020-10-01T08:55:52 >>> games-util/grfcodec-6.0.6... +4:04:33 2020-09-30T12:09:07 >>> x11-libs/gtk+-2.24.32-r1... +23:56:33 2020-09-30T11:25:34 >>> dev-libs/fribidi-1.0.9... +25:36:31 2020-09-30T11:19:27 >>> x11-libs/libXt-1.2.0... +25:40:07 2020-09-29T23:17:51 >>> dev-python/pygobject-3.36.1-r1... +37:37:08 2020-09-29T09:10:48 >>> sys-apps/linux-misc-apps-5.8... +51:50:07 2020-09-29T08:45:13 >>> dev-db/pgadmin4-4.26... +52:08:39 2020-09-28T13:31:50 >>> x11-misc/qt5ct-1.1... +71:29:30 2020-09-28T13:29:28 >>> www-client/palemoon-28.13.0-r1... +57:36:12 2020-09-28T13:01:27 >>> media-video/smplayer-20.6.0... +71:41:28 2020-09-27T21:16:33 >>> dev-lang/rust-1.46.0... +75:42:57 2020-09-26T20:05:20 >>> media-libs/rubberband-1.9.0... +111:57:11 2020-09-26T19:55:28 >>> x11-misc/primus-0.2-r2... +112:06:58 2020-09-23T08:14:03 >>> sys-devel/gcc-10.2.0-r1... +181:30:33 2020-09-22T06:39:26 >>> dev-perl/Math-Random-ISAAC-XS-1.4.0-r1... +221:24:15 2020-09-22T04:30:30 >>> dev-perl/Data-Password-passwdqc-0.90.0... +223:33:18 2020-09-21T15:43:43 >>> sys-fs/duperemove-0.11.1... (1 of 1) ETA: unknown sudo qlop -vr <no output> None of the targets sans qbittorrent listed in the "non-root" output are still running :/ sudo genlop -c however works: * net-p2p/qbittorrent-9999 current merge time: 10 minutes and 57 seconds. ETA: any time now. For completeness: qlop -vH qbittorrent-9999 2015-08-27T23:25:45 >>> net-p2p/qbittorrent-9999: 8 minutes, 22 seconds 2015-08-29T09:33:08 >>> net-p2p/qbittorrent-9999: 6 minutes, 39 seconds 2015-09-03T05:45:37 >>> net-p2p/qbittorrent-9999: 6 minutes, 55 seconds 2015-09-08T22:42:48 >>> net-p2p/qbittorrent-9999: 5 minutes, 8 seconds 2015-09-26T04:13:03 >>> net-p2p/qbittorrent-9999: 5 minutes, 38 seconds 2015-10-02T02:30:13 >>> net-p2p/qbittorrent-9999: 2 minutes, 1 second 2015-10-04T07:11:58 >>> net-p2p/qbittorrent-9999: 1 minute, 45 seconds 2015-10-04T15:43:51 >>> net-p2p/qbittorrent-9999: 2 minutes, 33 seconds 2016-01-23T11:32:27 >>> net-p2p/qbittorrent-9999: 9 minutes, 45 seconds 2016-01-30T21:30:47 >>> net-p2p/qbittorrent-9999: 8 minutes, 20 seconds 2016-03-06T09:21:01 >>> net-p2p/qbittorrent-9999: 5 minutes, 48 seconds 2016-04-09T10:06:31 >>> net-p2p/qbittorrent-9999: 8 minutes, 10 seconds 2016-05-08T01:33:29 >>> net-p2p/qbittorrent-9999: 19 minutes, 25 seconds 2016-05-29T11:42:05 >>> net-p2p/qbittorrent-9999: 13 minutes, 54 seconds 2016-06-29T09:56:14 >>> net-p2p/qbittorrent-9999: 6 minutes, 38 seconds 2016-10-13T12:06:13 >>> net-p2p/qbittorrent-9999: 9 minutes, 32 seconds 2017-01-27T22:07:33 >>> net-p2p/qbittorrent-9999: 10 minutes, 6 seconds 2017-03-23T00:04:30 >>> net-p2p/qbittorrent-9999: 15 minutes, 37 seconds 2017-09-10T03:38:59 >>> net-p2p/qbittorrent-9999: 8 minutes, 50 seconds 2017-11-03T18:55:55 >>> net-p2p/qbittorrent-9999: 10 minutes, 33 seconds 2017-12-16T01:45:26 >>> net-p2p/qbittorrent-9999: 6 minutes, 41 seconds 2018-06-15T05:33:05 <<< net-p2p/qbittorrent-9999: 22 seconds 2018-07-27T13:00:40 >>> net-p2p/qbittorrent-9999: 15 minutes, 8 seconds 2018-09-16T05:48:02 >>> net-p2p/qbittorrent-9999: 12 minutes, 42 seconds 2019-06-29T00:31:10 >>> net-p2p/qbittorrent-9999: 16 minutes, 1 second 2019-07-05T02:38:38 >>> net-p2p/qbittorrent-9999: 15 minutes, 31 seconds 2020-01-30T20:34:42 >>> net-p2p/qbittorrent-9999: 14 minutes, 28 seconds 2020-02-02T08:30:24 >>> net-p2p/qbittorrent-9999: 13 minutes, 19 seconds 2020-05-13T12:57:37 >>> net-p2p/qbittorrent-9999: 46 minutes, 26 seconds
If I had to guess, its getting thwarted in approach by portage pid namespacing. But I'm not acquainted well enough with how that works wrt/ its /proc hacking. htop sees it all just fine.
do you have emerge_logpath set by chance?
(In reply to Fabian Groffen from comment #2) > do you have emerge_logpath set by chance? Uh, Not even sure what that pertains to, or where it would be set. The closest I have is: # /etc/portage.make.conf PORT_LOGDIR="/var/log/portage" And no amount of fiddling with the only ENV var I can find in qlop with `strings` ( EMERGE_LOG_DIR ) helps, as emerge.log is in the regular place. stat /var/log/emerge.log File: /var/log/emerge.log Size: 102806601 Blocks: 200848 IO Block: 4096 regular file Device: 806h/2054d Inode: 5242893 Links: 1 Access: (0660/-rw-rw----) Uid: ( 250/ portage) Gid: ( 250/ portage) Access: 2020-10-02 15:05:06.796616746 +1300 Modify: 2020-10-02 15:07:53.165001386 +1300 Change: 2020-10-02 15:07:53.165001386 +1300 Birth: 2012-06-26 02:23:53.515018091 +1200 Renaming it PORTAGE_LOGDIR to not be the deprecated variable doesn't appear to do anything *shrug* Running qlop under strace looking for log directory access: strace -e trace=file qlop -r |& grep log readlink("/proc/1998/fd/2", "/var/log/auth.log", 4095) = 17 readlink("/proc/1998/fd/5", "/var/log/auth.log", 4095) = 17 readlink("/proc/1998/fd/7", "/var/log/secure", 4095) = 15 readlink("/proc/1998/fd/8", "/var/log/daemon.log", 4095) = 19 readlink("/proc/1998/fd/9", "/var/log/syslog", 4095) = 15 readlink("/proc/1998/fd/10", "/var/log/daemon.log", 4095) = 19 readlink("/proc/1998/fd/11", "/var/log/cron.log", 4095) = 17 readlink("/proc/1998/fd/12", "/var/log/cron", 4095) = 13 readlink("/proc/1998/fd/13", "/var/log/messages", 4095) = 17 readlink("/proc/1998/fd/14", "/var/log/messages", 4095) = 17 readlink("/proc/1998/fd/15", "/var/log/user.log", 4095) = 17 readlink("/proc/1998/fd/16", "/var/log/user.log", 4095) = 17 readlink("/proc/1998/fd/17", "/var/log/kern.log", 4095) = 17 readlink("/proc/1998/fd/18", "/var/log/kern.log", 4095) = 17 readlink("/proc/1998/fd/20", "/var/log/debug.log", 4095) = 18 readlink("/proc/1998/fd/21", "/var/log/debug", 4095) = 14 readlink("/proc/3782/fd/4", "/var/log/ntp.log", 4095) = 16 readlink("/proc/3917/fd/2", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3917/fd/8", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3919/fd/2", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3919/fd/14", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3920/fd/2", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3920/fd/8", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3921/fd/2", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3921/fd/14", "/var/log/samba/log.smbd", 4095) = 23 readlink("/proc/3926/fd/2", "/var/log/samba/log.nmbd", 4095) = 23 readlink("/proc/3926/fd/8", "/var/log/samba/log.nmbd", 4095) = 23 readlink("/proc/6979/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/6979/fd/5", "/var/log/Xorg.0.log", 4095) = 19 readlink("/proc/7296/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/7348/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/7349/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/9124/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/9876/fd/8", "/home/kent/.claws-mail/claws.log", 4095) = 32 readlink("/proc/12838/fd/3", "/var/log/slim.log", 4095) = 17 readlink("/proc/15506/fd/3", "/home/kent/.gnupg/scdaemon-log", 4095) = 30 readlink("/proc/19665/fd/13", "/var/log/portage/build/dev-util/"..., 4095) = 67 Hmmm. strace -s 1024 -v -e trace=file qlop -r |& grep -C10 "/proc/19665" readlink("/proc/19095/fd/6", "socket:[16561933]", 4095) = 17 readlink("/proc/19095/fd/7", "anon_inode:[eventfd]", 4095) = 20 readlink("/proc/19095/fd/8", "socket:[16563833]", 4095) = 17 readlink("/proc/19095/fd/9", "anon_inode:[eventfd]", 4095) = 20 readlink("/proc/19095/fd/10", "pipe:[16563838]", 4095) = 15 readlink("/proc/19095/fd/11", "/memfd:pulseaudio (deleted)", 4095) = 27 readlink("/proc/19095/fd/12", "socket:[16563841]", 4095) = 17 readlink("/proc/19095/fd/13", "anon_inode:[eventfd]", 4095) = 20 readlink("/proc/19095/fd/14", "anon_inode:[eventfd]", 4095) = 20 openat(AT_FDCWD, "/proc/19437/fd", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 openat(AT_FDCWD, "/proc/19665/fd", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 readlink("/proc/19665/fd/0", "/dev/pts/10", 4095) = 11 readlink("/proc/19665/fd/1", "/dev/pts/10", 4095) = 11 readlink("/proc/19665/fd/2", "/dev/pts/10", 4095) = 11 readlink("/proc/19665/fd/3", "anon_inode:[eventpoll]", 4095) = 22 readlink("/proc/19665/fd/4", "socket:[34304518]", 4095) = 17 readlink("/proc/19665/fd/5", "socket:[34304519]", 4095) = 17 readlink("/proc/19665/fd/6", "/var/tmp/portage/dev-util/cmake-3.18.3/.ipc_in", 4095) = 46 readlink("/proc/19665/fd/7", "/var/tmp/portage/dev-util/.cmake-3.18.3.portage_lockfile", 4095) = 56 readlink("/proc/19665/fd/9", "/dev/ptmx", 4095) = 9 readlink("/proc/19665/fd/10", "/dev/pts/10", 4095) = 11 readlink("/proc/19665/fd/11", "pipe:[34429344]", 4095) = 15 readlink("/proc/19665/fd/12", "pipe:[34429344]", 4095) = 15 readlink("/proc/19665/fd/13", "/var/log/portage/build/dev-util/cmake-3.18.3:20201002-021233.log.gz", 4095) = 67 openat(AT_FDCWD, "/proc/20044/fd", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 readlink("/proc/20044/fd/0", "/home/kent/.awesome-errors", 4095) = 26 readlink("/proc/20044/fd/1", "/home/kent/.awesome-errors", 4095) = 26 readlink("/proc/20044/fd/2", "/home/kent/.awesome-errors", 4095) = 26 readlink("/proc/20044/fd/3", "anon_inode:[eventpoll]", 4095) = 22 readlink("/proc/20044/fd/4", "pipe:[16467395]", 4095) = 15 readlink("/proc/20044/fd/5", "pipe:[16467395]", 4095) = 15 readlink("/proc/20044/fd/6", "socket:[16467396]", 4095) = 17 readlink("/proc/20044/fd/7", "/dev/ptmx", 4095) = 9 openat(AT_FDCWD, "/proc/20046/fd", O_RDONLY|O_NONBLOCK|O_CLOEXEC|O_DIRECTORY) = 3 Perhaps its not expecting the ".gz" suffix? Or is it something about it being "/build/" in the path? I can't read the C code :/
PORTAGE_LOGDIR causes portage to use buildlogs such as: /var/log/portage/build/dev-util/cmake-3.18.3:20201002-021233.log.gz This should've been resolved by the fix for bug #711896. The compression suffix certainly is the culprit. I tried addressing this now.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=83325e68514d4d55554bff9439b61c03f12d4d8b commit 83325e68514d4d55554bff9439b61c03f12d4d8b Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-10-04 11:29:43 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-10-04 11:29:43 +0000 qlop: deal with optionally compressed buildlogs in probe_proc Bug: https://bugs.gentoo.org/745798 Signed-off-by: Fabian Groffen <grobian@gentoo.org> qlop.c | 14 ++++++++++++++ 1 file changed, 14 insertions(+)
qlop -r 2020-10-05T06:13:48 >>> app-portage/portage-utils... (1 of 1) ETA: 2′34″ :)
Side question, what causes: 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown Its not like I don't have a history of gcc merges: qlop -Hv sys-devel/gcc | grep 'gcc-10' 2020-05-12T22:32:29 >>> sys-devel/gcc-10.1.0: 14 hours, 15 minutes, 19 seconds 2020-09-24T16:06:07 >>> sys-devel/gcc-10.2.0-r1: 4 hours, 25 minutes, 40 seconds qlop -Hv sys-devel/gcc | grep 'gcc-9' 2019-06-19T20:09:45 >>> sys-devel/gcc-9.1.0-r1: 13 hours, 50 minutes, 1 second 2019-06-20T13:08:25 >>> sys-devel/gcc-9.1.0-r1: 13 hours, 18 minutes, 19 seconds 2019-07-29T11:55:28 >>> sys-devel/gcc-9.1.0-r1: 14 hours, 19 minutes, 36 seconds 2019-08-10T22:42:14 >>> sys-devel/gcc-9.1.0-r1: 6 hours, 18 minutes, 51 seconds 2019-08-18T01:29:17 >>> sys-devel/gcc-9.2.0: 9 hours, 47 minutes, 43 seconds 2019-09-24T17:47:37 >>> sys-devel/gcc-9.2.0-r1: 9 hours, 9 minutes, 7 seconds 2019-11-19T17:18:54 >>> sys-devel/gcc-9.2.0-r2: 9 hours, 31 minutes, 12 seconds 2019-11-25T08:08:42 >>> sys-devel/gcc-9.2.0-r2: 9 hours, 11 minutes, 12 seconds 2020-01-24T19:27:07 >>> sys-devel/gcc-9.2.0-r3: 9 hours, 28 minutes, 38 seconds 2020-03-30T21:31:32 >>> sys-devel/gcc-9.3.0: 10 hours, 15 minutes, 50 seconds 2020-04-19T01:51:02 >>> sys-devel/gcc-9.2.0-r4: 14 hours, 14 minutes, 39 seconds It might be something about the variance being too high? Maybe some statistical output instead of "idunno" could help? eg: 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown (between 4 and 14 hours remaining) And when its > min 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown (up to 14 hours remaining) genlop currently says: * sys-devel/gcc-10.2.0-r2 current merge time: 16 minutes and 25 seconds. ETA: 3 hours, 6 minutes and 1 second.
(In reply to Kent Fredric (IRC: kent\n) from comment #7) > Side question, what causes: > > 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown drop the -v for a bit, does it work then? > Its not like I don't have a history of gcc merges: > > qlop -Hv sys-devel/gcc | grep 'gcc-10' > 2020-05-12T22:32:29 >>> sys-devel/gcc-10.1.0: 14 hours, 15 minutes, 19 > seconds > 2020-09-24T16:06:07 >>> sys-devel/gcc-10.2.0-r1: 4 hours, 25 minutes, 40 > seconds side question, isn't qlop -Hv gcc-10 working properly? Or ">=gcc-10"? > qlop -Hv sys-devel/gcc | grep 'gcc-9' > 2019-06-19T20:09:45 >>> sys-devel/gcc-9.1.0-r1: 13 hours, 50 minutes, 1 > second > 2019-06-20T13:08:25 >>> sys-devel/gcc-9.1.0-r1: 13 hours, 18 minutes, 19 > seconds > 2019-07-29T11:55:28 >>> sys-devel/gcc-9.1.0-r1: 14 hours, 19 minutes, 36 > seconds > 2019-08-10T22:42:14 >>> sys-devel/gcc-9.1.0-r1: 6 hours, 18 minutes, 51 > seconds > 2019-08-18T01:29:17 >>> sys-devel/gcc-9.2.0: 9 hours, 47 minutes, 43 seconds > 2019-09-24T17:47:37 >>> sys-devel/gcc-9.2.0-r1: 9 hours, 9 minutes, 7 seconds > 2019-11-19T17:18:54 >>> sys-devel/gcc-9.2.0-r2: 9 hours, 31 minutes, 12 > seconds > 2019-11-25T08:08:42 >>> sys-devel/gcc-9.2.0-r2: 9 hours, 11 minutes, 12 > seconds > 2020-01-24T19:27:07 >>> sys-devel/gcc-9.2.0-r3: 9 hours, 28 minutes, 38 > seconds > 2020-03-30T21:31:32 >>> sys-devel/gcc-9.3.0: 10 hours, 15 minutes, 50 seconds > 2020-04-19T01:51:02 >>> sys-devel/gcc-9.2.0-r4: 14 hours, 14 minutes, 39 > seconds > > > It might be something about the variance being too high? there is no such thing, it's a dumb average + max, nothing more. > Maybe some statistical output instead of "idunno" could help? In this case, it probably is looking for comparable gcc-10.2.0-r2 merges, which don't exist. In retrospect I think that's stupid behaviour, and it should be keeled. > > eg: > > > 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown > (between 4 and 14 hours remaining) > > And when its > min > > 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: unknown (up > to 14 hours remaining) > > genlop currently says: > > * sys-devel/gcc-10.2.0-r2 > > current merge time: 16 minutes and 25 seconds. > ETA: 3 hours, 6 minutes and 1 second.
think I found the culprit % ./qlop -rvt proc: dev-libs/expat 2020-10-04T20:40:33 >>> dev-libs/expat-2.2.10: 27s... (1 of 1) ETA: 1′23″ (average run)
(In reply to Fabian Groffen from comment #8) > drop the -v for a bit, does it work then? No difference, added -v in the hope it would improve things, but doesn't > side question, isn't qlop -Hv gcc-10 working properly? Or ">=gcc-10"? qlop -Hv gcc-10 <no output> qlop -Hv ">=gcc-10" 2020-05-12T22:32:29 >>> sys-devel/gcc-10.1.0: 14 hours, 15 minutes, 19 seconds 2020-09-24T16:06:07 >>> sys-devel/gcc-10.2.0-r1: 4 hours, 25 minutes, 40 seconds
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage-utils.git/commit/?id=e2cb3938176e97b6e41d1873838db35a017cf7d9 commit e2cb3938176e97b6e41d1873838db35a017cf7d9 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-10-04 18:43:17 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-10-04 18:43:17 +0000 qlop: fix fix for #731122, also make it work without packages specified Bug: https://bugs.gentoo.org/745798 Bug: https://bugs.gentoo.org/731122 Signed-off-by: Fabian Groffen <grobian@gentoo.org> qlop.c | 13 +++++++------ 1 file changed, 7 insertions(+), 6 deletions(-)
For completeness. qlop -a sys-devel/gcc sys-devel/gcc: 3:44:48 average for 99 merges sys-devel/gcc: 2′09″ average for 22 unmerges !?!?! qlop -va sys-devel/gcc sys-devel/gcc-10.2.0-r1: 4:25:40 average for 1 merge sys-devel/gcc-10.1.0: 14:15:19 average for 1 merge sys-devel/gcc-9.3.0: 10:15:50 average for 1 merge sys-devel/gcc-9.2.0-r4: 14:14:39 average for 1 merge sys-devel/gcc-9.2.0-r3: 9:28:38 average for 1 merge sys-devel/gcc-9.2.0-r2: 9:21:12 average for 2 merges sys-devel/gcc-9.2.0-r1: 9:09:07 average for 1 merge sys-devel/gcc-9.2.0: 9:47:43 average for 1 merge sys-devel/gcc-9.1.0-r1: 11:56:41 average for 4 merges sys-devel/gcc-8.3.0-r3: 3:23:24 average for 2 merges sys-devel/gcc-8.3.0-r2: 3:06:13 average for 1 merge sys-devel/gcc-8.3.0-r1: 3:46:10 average for 3 merges sys-devel/gcc-8.2.0-r6: 4:55:54 average for 1 merge sys-devel/gcc-8.2.0-r4: 4:57:33 average for 1 merge sys-devel/gcc-8.2.0-r3: 4:30:03 average for 1 merge sys-devel/gcc-8.2.0-r2: 4:53:18 average for 2 merges sys-devel/gcc-7.3.0-r4: 5:19:33 average for 1 merge sys-devel/gcc-7.3.0-r3: 3:13:39 average for 1 merge sys-devel/gcc-7.3.0-r1: 5:18:15 average for 2 merges sys-devel/gcc-7.3.0: 2:52:33 average for 2 merges sys-devel/gcc-7.2.0-r1: 3:42:46 average for 1 merge sys-devel/gcc-7.2.0: 2:46:49 average for 1 merge sys-devel/gcc-6.4.0-r5: 2:43:30 average for 2 merges sys-devel/gcc-6.4.0-r4: 2:29:12 average for 1 merge sys-devel/gcc-6.4.0-r3: 3:00:50 average for 1 merge sys-devel/gcc-6.4.0-r1: 2:56:33 average for 2 merges sys-devel/gcc-6.4.0: 2:36:43 average for 3 merges sys-devel/gcc-6.3.0: 3:19:43 average for 2 merges sys-devel/gcc-5.4.0-r3: 3:40:17 average for 1 merge sys-devel/gcc-5.4.0-r2: 5:30:48 average for 1 merge sys-devel/gcc-5.4.0: 2:22:01 average for 1 merge sys-devel/gcc-5.3.0: 4:45:08 average for 3 merges sys-devel/gcc-5.2.0: 3:30:48 average for 4 merges sys-devel/gcc-4.9.4: 1:31:44 average for 2 merges sys-devel/gcc-4.9.3: 2:18:25 average for 4 merges sys-devel/gcc-4.9.2: 2:00:26 average for 5 merges sys-devel/gcc-4.8.3: 2:05:38 average for 3 merges sys-devel/gcc-4.8.2: 2:36:37 average for 2 merges sys-devel/gcc-4.7.4: 2:08:45 average for 6 merges sys-devel/gcc-4.7.3-r1: 1:57:41 average for 3 merges sys-devel/gcc-4.7.2-r1: 1:29:56 average for 2 merges sys-devel/gcc-4.7.2: 1:48:48 average for 5 merges sys-devel/gcc-4.7.1: 55′05″ average for 2 merges sys-devel/gcc-4.6.4: 2:03:38 average for 1 merge sys-devel/gcc-4.6.3: 1:44:29 average for 9 merges sys-devel/gcc-4.1.2: 26′48″ average for 1 merge sys-devel/gcc-3.4.6-r2: 12′03″ average for 1 merge sys-devel/gcc-9.3.0: 20s average for 1 unmerge sys-devel/gcc-9.2.0-r3: 1′11″ average for 1 unmerge sys-devel/gcc-9.1.0-r1: 1′28″ average for 1 unmerge sys-devel/gcc-8.3.0-r1: 34s average for 1 unmerge sys-devel/gcc-8.2.0-r6: 8′58″ average for 1 unmerge sys-devel/gcc-7.3.0-r4: 3′16″ average for 1 unmerge sys-devel/gcc-7.2.0-r1: 3′10″ average for 1 unmerge sys-devel/gcc-6.4.0-r5: 1′02″ average for 1 unmerge sys-devel/gcc-6.4.0: 2′53″ average for 1 unmerge sys-devel/gcc-6.3.0: 13s average for 1 unmerge sys-devel/gcc-5.4.0-r3: 3′04″ average for 1 unmerge sys-devel/gcc-5.3.0: 16s average for 1 unmerge sys-devel/gcc-5.2.0: 4′39″ average for 1 unmerge sys-devel/gcc-4.9.4: 1′26″ average for 2 unmerges sys-devel/gcc-4.9.3: 30s average for 1 unmerge sys-devel/gcc-4.8.3: 3′02″ average for 1 unmerge sys-devel/gcc-4.7.4: 4′04″ average for 1 unmerge sys-devel/gcc-4.6.4: 2′31″ average for 1 unmerge sys-devel/gcc-4.5.3-r2: 17s average for 1 unmerge sys-devel/gcc-4.1.2: 11s average for 1 unmerge sys-devel/gcc-3.4.6-r2: 2′58″ average for 1 unmerge
(In reply to Kent Fredric (IRC: kent\n) from comment #12) > For completeness. > > qlop -a sys-devel/gcc > sys-devel/gcc: 3:44:48 average for 99 merges > sys-devel/gcc: 2′09″ average for 22 unmerges > > !?!?! Is your confusement above or below this marker? > > qlop -va sys-devel/gcc > sys-devel/gcc-10.2.0-r1: 4:25:40 average for 1 merge > sys-devel/gcc-10.1.0: 14:15:19 average for 1 merge > sys-devel/gcc-9.3.0: 10:15:50 average for 1 merge > sys-devel/gcc-9.2.0-r4: 14:14:39 average for 1 merge ...
(In reply to Larry the Git Cow from comment #11) > The bug has been referenced in the following commit(s): > > https://gitweb.gentoo.org/proj/portage-utils.git/commit/ > ?id=e2cb3938176e97b6e41d1873838db35a017cf7d9 > > commit e2cb3938176e97b6e41d1873838db35a017cf7d9 > Author: Fabian Groffen <grobian@gentoo.org> > AuthorDate: 2020-10-04 18:43:17 +0000 > Commit: Fabian Groffen <grobian@gentoo.org> > CommitDate: 2020-10-04 18:43:17 +0000 > > qlop: fix fix for #731122, also make it work without packages specified > > Bug: https://bugs.gentoo.org/745798 > Bug: https://bugs.gentoo.org/731122 > Signed-off-by: Fabian Groffen <grobian@gentoo.org> > > qlop.c | 13 +++++++------ > 1 file changed, 7 insertions(+), 6 deletions(-) That helps a lot :) 2020-10-05T06:21:00 >>> sys-devel/gcc-10.2.0-r2... (4 of 5) ETA: 2:02:33 (average run)
(In reply to Fabian Groffen from comment #13) > Is your confusement above or below this marker? Above, but upon reflection, I just didn't see the "unmerges" and spat the dummy not understanding why there were 2 different reports for one package. User Error.
(In reply to Kent Fredric (IRC: kent\n) from comment #15) > (In reply to Fabian Groffen from comment #13) > > Is your confusement above or below this marker? > > Above, but upon reflection, I just didn't see the "unmerges" and spat the > dummy not understanding why there were 2 different reports for one package. > User Error. Though the more I use qlop, the more I can't help thinking it needs a seperate "cluster-by" argument. Trying to unify both "package selection" and "clustering criteria" is surely an exercise in futility as they're somewhat orthogonal concerns. --cluster-by=package (all versions of the package are used equally) --cluster-by=version-revision (each distinct ebuild is a basis) --cluster-by=version (-r level ignored, but otherwise the same as above) --cluster-by=version-major (only the first element of the version is a unique constraint ) --cluster-by=version-minor (first 2 version components are a unique constraint )
perhaps also a cluster-by=slot
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=1278e75ff758df9e3a7f11d57d36dc378461fe2e commit 1278e75ff758df9e3a7f11d57d36dc378461fe2e Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2020-10-04 20:14:05 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2020-10-04 20:14:05 +0000 app-portage/portage-utils-0.90: version bump for qlop fixes Closes: https://bugs.gentoo.org/745798 Closes: https://bugs.gentoo.org/731122 Closes: https://bugs.gentoo.org/713536 Closes: https://bugs.gentoo.org/705748 Closes: https://bugs.gentoo.org/701968 Package-Manager: Portage-3.0.4, Repoman-3.0.1 Signed-off-by: Fabian Groffen <grobian@gentoo.org> app-portage/portage-utils/Manifest | 2 +- ...portage-utils-0.88.ebuild => portage-utils-0.90.ebuild} | 14 -------------- 2 files changed, 1 insertion(+), 15 deletions(-)
(In reply to Fabian Groffen from comment #17) > perhaps also a cluster-by=slot Yeah, would have suggested that, but ... qlop -r -F "%{CAT}/%{PN}:%{SLOT}" 2020-10-05T15:09:23 >>> app-emulation/qemu:<unset>... (4 of 4) ETA: 31′03″ 2020-10-05T14:40:04 >>> media-gfx/inkscape:<unset>... (7 of 7) ETA: 2:47:01 Looks like the slot isn't available. Also, weird shenangians are afoot, not sure why these ETA's are going *up* sudo qlop -r 2020-10-05T14:53:45 >>> dev-libs/glib... (3 of 4) ETA: 9′43″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 21′29″ sudo qlop -r 2020-10-05T14:53:45 >>> dev-libs/glib... (3 of 4) ETA: 9′11″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 20′57″ sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 23′52″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 15′40″ sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 23′38″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 15′26″ sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 4′10″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 3:15:28 #<------ JUMP sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 48′29″ #<----- JUMP 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 3:04:27 sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 48′09″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 3:04:07 sudo qlop -r 2020-10-05T15:09:23 >>> app-emulation/qemu... (4 of 4) ETA: 32′20″ 2020-10-05T14:40:04 >>> media-gfx/inkscape... (7 of 7) ETA: 2:48:18 > there is no such thing, it's a dumb average + max, nothing more. ^ this statement doesn't quite explain what's happening :)
(In reply to Kent Fredric (IRC: kent\n) from comment #19) > ^ this statement doesn't quite explain what's happening :) Ah, doh, Now I see, -v explains. It went from "average", and due to exceeding average, it changed to "longest run". That's fine. Just surprising :)
