Summary: | app-portage/portage-utils: qlop: -t does not show correctly when emerge never completed | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Andreas Fink <finkandreas> |
Component: | Third-Party Tools | Assignee: | Fabian Groffen <grobian> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | armin76, bircoph, broken.zhou, dpblnt, dschridde+gentoobugs, jim, marat, nikoli, roman.zilka, rossi.f, skrattaren |
Priority: | High | ||
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Attachments: |
bugfix patch
Patch for qlop-0.5 |
Description
Andreas Fink
2011-01-08 09:33:03 UTC
Created attachment 259274 [details]
bugfix patch
ugly'n'dirty patch, but it works ;)
I have the same problem with missed or miscalculated emerge entries. Patch from Andreas helps, thanks. Fixed with patch for me too, hooray! Thanks for patch, Andreas, I hope it'd hit the tree soon. Seems to be fixed in app-portage/portage-utils-0.5 portage-utils-0.5 does *NOT* fix the problem completely. The problem with 0.5 is that a corrupted emerge process forces that the next time the same version is going to be installed. However this is an assumption which in my case is not true (I have a chromium emerge started with version 8.0.552.215 which never completed. The next merge was with version 8.0.552.224, so qlop got confused and showed way to few results). I will attach a new patch which fixes this issue and can be applied to qlop-0.5. Created attachment 266609 [details, diff]
Patch for qlop-0.5
still not fixed in app-portage/portage-utils-0.62 (In reply to Balint Dobai-Pataky from comment #7) no one said otherwise. the bug is still open. Sorry, didn't mean to be offensive, at all. I just thought to supply info about the new version, for users who use the patched 0.56 version like me. for portage-utils, the bug flow is controlled enough that bugs get closed when the code is fixed, so things rarely go stale. at this point, qlop isn't getting too much love as i don't really use it much anymore, and the portage log system is so noisy it's hard to reasonably parse. to do this reliably, would have to maintain state vs timestamps. *** Bug 470168 has been marked as a duplicate of this bug. *** I don't see how treating aborted merges as successful ones is going to be helpful. I just added a fix for miscalculation in case of aborted merges, but that doesn't show merge attempts either. Judging from your patch, you use atoms to compare category/package, while the original code compares category/package-version, which is more specific. The real catch is in t[0] = t[1]. This bit is in the fix I added. The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=34b636503cc7dcabe32b9b377c2eb77cb5fd5575 commit 34b636503cc7dcabe32b9b377c2eb77cb5fd5575 Author: Fabian Groffen <grobian@gentoo.org> AuthorDate: 2018-04-05 19:02:10 +0000 Commit: Fabian Groffen <grobian@gentoo.org> CommitDate: 2018-04-05 19:02:34 +0000 app-portage/portage-utils: version bump to 0.70 This release fixes multiple bugs lingering around for a while. Closes: https://bugs.gentoo.org/651546 Closes: https://bugs.gentoo.org/646310 Closes: https://bugs.gentoo.org/645554 Closes: https://bugs.gentoo.org/643820 Closes: https://bugs.gentoo.org/638032 Closes: https://bugs.gentoo.org/608960 Closes: https://bugs.gentoo.org/607498 Closes: https://bugs.gentoo.org/558306 Closes: https://bugs.gentoo.org/526596 Closes: https://bugs.gentoo.org/470168 Closes: https://bugs.gentoo.org/351100 Closes: https://bugs.gentoo.org/335453 Package-Manager: Portage-2.3.24, Repoman-2.3.6 app-portage/portage-utils/Manifest | 2 +- .../portage-utils/portage-utils-0.62.ebuild | 2 +- .../portage-utils/portage-utils-0.63.ebuild | 43 ---------------------- ...ls-0.64-r1.ebuild => portage-utils-0.70.ebuild} | 16 +------- 4 files changed, 4 insertions(+), 59 deletions(-) |