This patch will give an approximate completion percentage of the package currently being emerged. The text will show up in the header of the xterm. Reproducible: Always Steps to Reproduce: 1. 2. 3.
Just some clarification: the patch I posted in that thread will add the following feature to emerge: If "dyntitle" is in FEATURES, and TITLE_COMMAND is set, then TITLE_COMMAND, with "$PKG" replaced with the package being merged, will be executed periodically (default every 2.5 seconds; override with TITLE_FREQ variable) during compilation, and the Xterm title (if applicable) will be set to the output of that command. This should allow for a crude progress meter to be implemented, when used in conjunction with the progress script in the same thread. There are possible security implications here in that the title command executed isn't sandboxed, and runs in the context of the emerge process. It will also impact performance slightly, though I'm not sure it's noticeable. The bigger issue in that regard is that emerge goes multithreaded with this enabled. I didn't originally intend this to get into the official Portage, but if someone wants to pick it up, then fine by me. ;)
*** Bug 88341 has been marked as a duplicate of this bug. ***
Putting a hold on feature requests for portage as they are drowning out the bugs. Most of these features should be available in the next major version of portage. But for the time being, they are just drowning out the major bugs and delaying the next version's progress. Any bugs that contain patches and any bugs for etc-update or dispatch-conf can be reopened. Sorry, I'm just not good enough with bugzilla. ;)
If you look at Severity on this bug it's an enhancement. If you do a search on bugzilla http://bugs.gentoo.org/ for portage it lists all the bugs related to portage. At the top of the page are the column headings. One of them is severity. Clicking on it will sort the bugs by severity. Deleting bugs because they are drowning out the important ones is not a good idea. Enhancments are worthwhile to keep around, and should only be deleted if they are either done, or invalid.
RESOLVED:LATER is not deleting. It means it will be looked at later. Your noise just delays it more.
Jstubbs: Ah, I see, so the bugs with the most "noise" should really be pushed back further and further, I mean, if 50 people saw fit to comment on it they probably do that because they are bored, and not because they might really be interested in seeing the damn bug solved or anything. Also: Mr. Burner gets a great big kudos for pointing out the functionality that makes your "Resolving spree" unneccessary and counterproductive. Toodles.
The problem is that you are only looking at the RESOLVED part of RESOLVED LATER. The amount of noise that happens drowns out the real bugs whether you see it or not. If you'd like to fix all the portage bugs, you're welcome to manage them in your own way.
Reopening for consideration.
Closing as apparently nobody else is interested in adding this and I also don't see much use in it.
