Emerge progress bar

lanius · Retired Dev Joined: 08 Dec 2002 Posts: 160

why do you have to rebuild bash? can't you just replace the binary, as the script mentioned in http://forums.gentoo.org/viewtopic.php?t=42074 does?

bushwakko · Guru Joined: 25 Mar 2003 Posts: 495

any new version of emerge-progress coming any time soon?

tdb

I love the idea and hope it matures, but for the time being, I have to take it off. I tried emerging xfree (fresh install) on my server with emerge-progress and for some reason it didn't install the X binaries. I unmerged it, and X compiled fine. So, I guess this would be a bug report then.

The Jaff · n00b Joined: 14 Mar 2003 Posts: 26 Location: Sweden

I guess that the important thing is to get the progress thingy designed/implemented so that emerging ebuilds is guaranteed to work exactly as good/bad as without the progress-bar. If at the end the meter say 431% or whatever doesnt matter, as long as the ebuild is emerged as it should. When this is milestone is achieved, work on the accuracy.

:roll:

My two cents.
_________________
There are 11 kinds of people - those who know binary, and those who can't count.

helmers · Guru Joined: 16 Sep 2002 Posts: 548 Location: Oslo, Norway

This is very interesting!

There are many times when emerging new systems, I wonder how long there is left of a big emerge, such as KDE or Mozilla, and a progress bar would make it easier to decide when to abort and when to let it finish.

Most of the time the output of the compile is pretty useless to me, if I could look at a progress bar instead it would really make my day. :wink:

_________________
C is for Cookies!

panserg · Apprentice Joined: 16 Apr 2003 Posts: 188

I don't know what people are talking here about. But as for today, in it's 2.0.47-r10, the portage has broken and doesn't log into /var/log/emerge (it leaves empty files). I think before any talking about progress bars and other whistles and candies, the major functionality must be fixed. And until then - please mask portage-2.0.47-r10 as unstable, so people will return back to 2.0.47-r9 which logging worked properly.

helmers · Guru Joined: 16 Sep 2002 Posts: 548 Location: Oslo, Norway

You should file a bug about this, as most of the dev's don't read the forums.

http://bugs.gentoo.org
_________________
C is for Cookies!

axxackall · Posted: Fri May 02, 2003 8:07 pm Post subject:

It seems as fixed

, but in unstable version 2.0.48-pre3 so we have to live for awhile with empty logs

P.S. I wonder if they include logging into unit tests or even do they have unit tests at all...

mrik · n00b Joined: 28 May 2003 Posts: 27 Location: Bruxelles

Oooops I've got a problem ..
Sometimes it's going up to 60000% And I'm not able tu Unmerge this stuff

Please help

Got the problem while emerging xscreensaver !

RedBeard0531 · Guru Joined: 21 Sep 2002 Posts: 415 Location: maryland

Could someone set it up so that it also sets the xterm title bar. That would be cool.
_________________
OH MY GOD! Kenny just killed Kenny!
That Basterd!

Korean Ian · Tux's lil' helper Joined: 12 May 2003 Posts: 95

This looks really awesome but I think i will stay away until I can get my mozilla builds.

Keep up the excelent work.

KI

kopfarzt · Posted: Sat Jul 19, 2003 8:35 pm Post subject:

Here is a naive little script (not to be compared to the elaborated progress meter discussed here), that I use for estimating progress of an ebuild. It works by counting the number of "source" and "object" files and gives a very rough idea of what's going on. It does not change any files and should also work for non-make-based builds (like Java's ant). It will happily count to 110% or more and revise it's output every time you call it, but perhaps anybody finds it useful :-)

There is only one parameter which is a source directory. If you call it without parameters it will use the newest directory in /var/tmp/portage. Possible source and object extensions can and should be added to srcext/objext.

I use to call it with

Fitzsimmons · Posted: Sat Jul 19, 2003 9:46 pm Post subject:

It certainly sounds great, but I would feel more comforable if it piped the output to a file or something like that. Recompiling without the bar can be exremely time consuming (what happens if it crashes in the last portion of OO??) I'm certainly not up for another 8hrs of compiling just to find out what the error was. Anyway, I don't think this should be incorporated into portage without the following first:

Output log
Very high chance of accuracy (i.e. almost always %100, this would probably mean very extensive testing)
Garuntee that it won't break any packages

Don't get me wrong, I still think its pretty darn amazing and I commend you on your work; I just don't think its ready for portage (which wasn't your idea anyway, so that's something of a moot point). I think it should however become something of a reccomended tool, along the lines of ufed and mirrorselect.

Great Work!

Aonoa · Guru Joined: 23 May 2002 Posts: 538 Location: Oslo, Norway

A progress bar for emerge is a neat idea.

I hope it get's implemented eventually, in due time.

So far I have only had the little info aterm displays in it's titlebar. What ebuild it's working on. Eg. 2/9. This would only work in X as well. Better to have a console solution.

Keep up the good work.

_________________
Te audire no possum.
Musa sapientum fixa est in aure.

"I can't hear you."
"I have a banana in my ear."

KiTaSuMbA · Guru Joined: 28 Jun 2002 Posts: 430 Location: Naples Italy

I haven't tried this (too much stuff breaking on their own to give them an extra help atm) but it's definatelly a cute idea.
Some uninformed opinions and ideas:
- Progress Bar in ETA format: is not a good idea as it could never acheive useful accuracy even with fiddling deep inside the building process. Thus, the theoretical advantages of an ETA versus a simple percentage remain just that: theoretical. Let's not add more complexity to what seems to suffer already of serious bugs.
- Accuracy: the fact that many packages are completely blown off in the percent scale is a telltale that what the script measures as constant individual events turn out to be variable (author already noticed the complexities introduced by different makefile formats)
- Breaking packages: this MUST have to do with the script actually interfering with the build process than simply monitoring it from a mere stdout position.
- idea: another user already suggested counting gcc events in the makefile and then counting them as they appear on output. So what we need is:
- modified econf that after the config, greps for gcc in the Makefiles and drops the count in a $var then quiting normally
- a new eprogress function that reads gcc events as they are spit out by emake and does all the math
- modified emake that forks to the new eprogress and then goes its way except that outputs to not stdout but were eprogress can read and present the stdout.
This way we do not put ourselves in the middle of the make proccess possibly harassing it, so even if eprogress completelly shits its pants the emake _will_ do its job.
Now I don't have neither the time nor a gentoo-to-break system to try my ideas, so bare with me.
_________________
Need to flame people LIVE on IRC? Join #gentoo-otw on freenode!

kopfarzt · Posted: Wed Jul 23, 2003 10:32 am Post subject:

Ben2040 · Guru Joined: 07 May 2003 Posts: 445 Location: UK

Hi

gaz · Tux's lil' helper Joined: 12 Oct 2002 Posts: 126

Im gonna give it a go when I get home

would you be able to incorporate distcc into it?

tecknojunky · Posted: Sun Aug 03, 2003 8:49 am Post subject:

I like very much the idea, but if it completely obliterate the make output (not even in a log file), sorry, not for me.

Also, can someone supply a screenshot. Is this a console or graphic meter? It's not specified in any posts.
_________________
(7 of 9) Installing star-trek/species-8.4.7.2::talax.

Yarrick · Posted: Thu Aug 07, 2003 8:09 am Post subject:

i tried installing iproute with progressbar activated, and strange things happened. the progressbar stopped at 6% and the continued the install, complaining about missing files, but the ebuild seemed to install successfully. i tried once disabling the bar and re-emerging iproute and it could not complete the make due to errors, and it halted the installation. so the progressbar doesn't care if the compilation works or not, does it?

charlieg · Posted: Thu Aug 07, 2003 8:23 am Post subject:

sKewlBoy · Guru Joined: 03 Nov 2002 Posts: 406 Location: Portugal

I have tested this and loved it. Beside one time that gave me 6000%, usal is between 90 and 110. And no package has ever been broken. Only mozilla complains that can't be compile without original GNU Make.

Show progress in {a|x}term window title would be great, but I guess it won't be so easy, since it is set by emerge first...
How do you set xterm title ? Is it a env var ?

Cassius · n00b Joined: 03 Aug 2003 Posts: 6

Very nice script but the biggest problem i have with it (and many else i see) is that you don't see the output. Can't it be possible to show the progress only in the statusbar of your shell?
so instead of:
=== ( 1 of 9 ) Compiling/Merging (usr/portage/sys-apps/appname/app.ebuild)
something like this:
=== (1/9) app.ebuild [50%] [********** ]

Pythonhead · Posted: Sun Aug 10, 2003 11:27 pm Post subject:

Check out this thread for a very nice gui (rtkmerge) that has a progress bar:

http://forums.gentoo.org/viewtopic.php?p=443624#443624

helmers · Guru Joined: 16 Sep 2002 Posts: 548 Location: Oslo, Norway

I guess almost everyone have different desires as to what this "progress bar would display. But for all us non-coders out there, the text that flies by is a problem. If you use VESA-framebuffer, or some nice large terminals, scrolling a lot slows down compile speed.

What I would like is either something nice, so that I wouldn't need several screens to see what have gone wrong. If you could just have ONE line for each application, with the name and status, plus one dynamic line below that; letting you know what is going on. I would really appriciate if I were told how long each compile took too, so I know how long the next verison will take. This is probably even more useful for those with slower CPUs.