Hi. An example which demonstrates the issue: # qlop -r 2020-01-09T13:53:10 >>> media-libs/glfw-3.3.1... +9 days, 4 hours, 55 minutes, 23 seconds $ eix -e glfw [I] media-libs/glfw Installed versions: 3.3.1(14:01:08 2020-Jan-09)(-wayland) Excerpt from /var/log/emerge.log: ... 1578574874: ::: completed emerge (1 of 1) media-libs/glfw-3.3.1 to / ... $ date --date @1578574874 Thu 2020-Jan-09 14:01:14 CET In the above, it can be seen that glfw-3.3.1 has failed to install @13:53, but then succeeded to install @14:01. I would attempt at fixing this issue myself, but I am not sure how to submit a pull request to https://gitweb.gentoo.org/proj/portage-utils.git/ Sincerely Jan
qlop only returned the old failed merge? there wasn't an entry for the currently emerging package? You can file a PR on the github mirror, https://github.com/gentoo/portage-utils
(In reply to Fabian Groffen from comment #1) > qlop only returned the old failed merge? > > there wasn't an entry for the currently emerging package? The package currently being emerged is printed correctly, if an emerge is running. The full output, without any emerge running on the machine, is: $ qlop -r qlop: insufficient privileges for full /proc access, running merges are based on heuristics 2020-01-15T16:29:21 >>> sys-devel/libtool-2.4.6-r6... +3 days, 2 hours, 43 minutes, 39 seconds 2020-01-14T16:47:20 >>> xfce-base/xfce4-settings-4.15.0... +4 days, 2 hours, 26 minutes, 40 seconds 2020-01-14T07:27:39 >>> xfce-base/libxfce4ui-4.15.1... +4 days, 11 hours, 47 minutes, 13 seconds 2020-01-14T07:14:00 >>> x11-misc/devilspie-0.23... +4 days, 12 hours, 1 minute, 21 seconds 2020-01-14T06:59:52 >>> sys-boot/grub-2.04-r1... +4 days, 12 hours, 6 minutes, 55 seconds 2020-01-12T22:10:38 >>> app-portage/portage-utils-0.84... +5 days, 21 hours, 3 minutes, 31 seconds 2020-01-09T13:53:10 >>> media-libs/glfw-3.3.1... +9 days, 5 hours, 21 minutes, 35 seconds
can you run qlop with sudo?
(In reply to Fabian Groffen from comment #3) > can you run qlop with sudo? $ sudo qlop -r <empty output - seemingly correct because no emerge is running> But during "emerge llvm", sudo qlop -r gives empty output too, which is incorrect. $ strace -f qlop -r |& grep /var/log openat(AT_FDCWD, "/var/log/emerge.log", O_RDONLY) = 3 $ sudo strace -f qlop -r |& grep /var/log readlink("/proc/2335/fd/17", "/var/log/messages", 4096) = 17 readlink("/proc/2524/fd/4", "/var/log/sddm.log", 4096) = 17 readlink("/proc/2557/fd/4", "/var/log/Xorg.0.log", 4096) = 19 readlink("/proc/2612/fd/3", "/var/log/apcupsd.events", 4096) = 23 readlink("/proc/3114/fd/5", "/var/log/sddm.log", 4096) = 17 readlink("/proc/3147/fd/9", "/var/log/ConsoleKit/history", 4096) = 27 readlink("/proc/502407/fd/12", "/var/log/portage/sys-devel:llvm-"..., 4096) = 60 The command "sudo -u portage qlop -r" has the same effect as "qlop -r". For completeness: $ cat ~/bin/shared/qlop #!/bin/bash exec /usr/bin/qlop --human --verbose "$@"
oh joy... readlink("/proc/502407/fd/12", "/var/log/portage/sys-devel:llvm-"..., 4096) = is that really using a colon (:) now instead of a slash?
(In reply to Fabian Groffen from comment #5) > oh joy... > > readlink("/proc/502407/fd/12", "/var/log/portage/sys-devel:llvm-"..., 4096) > > is that really using a colon (:) now instead of a slash? Yes, it is a colon. I have PORT_LOGDIR="/var/log/portage" in /etc/portage/make.conf.
Hi, I am having the same issue with qlop-0.89. I am currently running `emerge gcc`, but qlop is showing old emerges. >>> Emerging (1 of 12) sys-devel/gcc-10.2.0-r1::gentoo # sudo -u portage qlop -rt qlop: insufficient privileges for full /proc access, running merges are based on heuristics 2020-08-23T17:37:38 >>> sys-devel/gcc: 19′47″... (1 of 12) ETA: 3:23:31 2020-08-22T11:55:03 >>> dev-lang/php: 30:02:22... +29:45:17 2020-08-18T20:45:22 >>> net-vpn/tor: 117:12:03... +117:08:57 2020-08-17T21:11:20 >>> dev-db/mariadb: 140:46:05... +140:31:13 2020-08-16T01:02:02 >>> sys-libs/ldb: 184:55:23... +184:53:50 At least mariadb matches an aborted or failed emerge: 1597691480: >>> emerge (1 of 1) dev-db/mariadb-10.5.5 to / 1597691480: === (1 of 1) Cleaning (dev-db/mariadb-10.5.5::/var/db/repos/gentoo/dev-db/mariadb/mariadb-10.5.5.ebuild) 1597691481: === (1 of 1) Compiling/Merging (dev-db/mariadb-10.5.5::/var/db/repos/gentoo/dev-db/mariadb/mariadb-10.5.5.ebuild) In make.conf I have: PORT_LOGDIR="/var/log/portage" PORT_LOGDIR_CLEAN="find \"\${PORT_LOGDIR}\" -type f ! -name \"summary.log*\" -mtime +90 -delete" FEATURES="${FEATURES} parallel-fetch candy clean-logs split-log split-elog news" Another weird thing is that since several months I have not been able to run `qlop -rt` as root, but must use `sudo -u portage qlop -rt` even if I am logged in as root. Some qlop commands, like `qlop -t gcc` does work when run as root. Is this another bug (didn't see one reported) or intended behaviour?
qlop warns about not having full access to /proc, which is why running as root improves things. Perhaps I re-add the sandbox heuristic for as long sandbox survives in current Gentoo.
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(-)
