View previous topic :: View next topic |
Show or hide build output by default? |
emerge should hide build output by default (unless --quiet-build=n) |
|
28% |
[ 135 ] |
emerge should show build output by default (unless --quiet-build=y) |
|
51% |
[ 240 ] |
The -v option should control whether build output is shown or not by default |
|
17% |
[ 81 ] |
Other (please comment) |
|
2% |
[ 10 ] |
|
Total Votes : 466 |
|
Author |
Message |
firephoto Veteran
Joined: 29 Oct 2003 Posts: 1612 Location: +48° 5' 23.40", -119° 48' 30.00"
|
Posted: Tue Nov 22, 2011 9:30 pm Post subject: |
|
|
zmedico wrote: |
firephoto wrote: | If I set -j6, but the ebuild or the source code itself strips it away, how do i know this without seeing the output? |
Maybe we could detect this automatically and trigger a QA Notice for display via elog? |
I know at some time I've seen notices about this but it might have just been a notice that if it broke this is why sort of thing.
If it could be a little flag of some sort on the line entry that just showed these sort of changes. I know there's not much this affects but if something big had an update and needed this workaround for a short bit someone might be surprised to see something that should have finished still chugging away... it would just be nice to avoid another terminal login to check something occasionally.
Half jokingly I've thought to myself why not have a ncurses or similar interface that can have some different areas displaying different things. _________________ #gentoo-kde on freenode |
|
Back to top |
|
|
karmaking Tux's lil' helper
Joined: 11 Feb 2004 Posts: 82 Location: Berlin, Germany
|
Posted: Tue Nov 22, 2011 9:42 pm Post subject: |
|
|
AidanJT wrote: | karmaking wrote: | Just as the cool guys can understand the green rainy noise of the "Matrix", you can understand portage's "noise" while it's working. This should not be hidden by default from users of whatever level of experience. |
No you can't, and pretending you understand the noise is just plain nonsense. If spewing gcc noise was beneficial then the kernel devs would enable it instead of only printing what module make is working on, and warnings and errors. You know, something actually relevant. And even that is only of value to kernel programmers, not users who're only interested in using the software rather than actively coding and debugging. |
No, it's not nonsense. It has the sense of letting people know that something is going on and gives them a feeling that it is much that is going on and what is taking so much time. It's been well put by Randy Andy (p.7), krinn (p.8) and others earlier. Technically, it might be obsolete to you and some other power users, but that's not all of the users. We guys know how to enable/disable this feature, so we generally don't care.
Hence I'd like to see this thread elaborating from a mere rant ("I personally hate/love it") to a more future-oriented debate: Is it good for the future of Gentoo, for attracting and keeping new users, to have this feature enabled or not. How many complaints about too much make output have there been from this target group in the past? I guess not so many. It has been said already: The "noise" gives new users something to wonder about and to learn and motivates them to dig more into the matter (and get to know and love Gentoo more than other distros). |
|
Back to top |
|
|
Nerdanel Apprentice
Joined: 27 Apr 2003 Posts: 161 Location: Finland
|
Posted: Tue Nov 22, 2011 11:21 pm Post subject: |
|
|
I think trying to solve messy compile messages in portage by removing all compile messages from view altogether is a misguided downstream approach to an upstream problem (or "problem"). Maybe more projects could be like KDE and use cmake for terse compile messages (only showing the errors and the warning is full) and helpful percentage progress indications, but that's not for Gentoo to decide and in this case I anyway get the impression that even KDE and the Linux kernel aren't good enough for certain devs who want to hide everything.
I also think it's wrong to say that compilers categorically never get stuck in a loop. Sure gcc is stable and has a lot of eyeballs on it, but that's not 100% proof against regressions that only appear when compiling some program that none of the devs use. There is also the possibility of a compiler other than gcc. So when openoffice has been compiling all night and still isn't done the compile messages show that something is progressing. You can't deduce that from the load averages even if you know what they mean, which I rather suspect most newbies won't. Load averages aren't even specific to the program being compiled, so if you have some other program taking up the cpu it can totally hide the compile doing nothing at all.
Quote: | A major factor is that I do not like to make major changes to the default user interface, like this one, since I know that it will tend to upset some of the users (as this thread clearly demonstrates). In the case of --quiet-build, in the long-term, I think it will be worth the short-term ruckus that the change has caused. |
The world is full of interface "improvements" that seemed like good ideas at the time to the people making them but which were in reality bad ideas for the userbase as a whole. (It's probably best to avoid derailing the thread with specific examples.) And no, bad defaults aren't fine and dandy even if you can read the man page and then edit some file somewhere to bring back the sensible behavior. Unfortunately Gentoo seems to be the latest victim of this trend. |
|
Back to top |
|
|
lasuit n00b
Joined: 01 Mar 2011 Posts: 24 Location: London, England
|
Posted: Tue Nov 22, 2011 11:26 pm Post subject: |
|
|
FWIW, I too like to see the compiler output, even if I cannot read it in detail. If a program "hangs", you can scroll back to see what's going on. Now I know some will say, "go to config.status and look it up that way", but my preference, since that's what this thread is all about is to see the output on the screen. Thank you, and good night. |
|
Back to top |
|
|
Suicidal l33t
Joined: 30 Jul 2003 Posts: 959 Location: /dev/null
|
Posted: Wed Nov 23, 2011 1:58 am Post subject: |
|
|
I started using this script when --jobs came out, it just tails the most recent log in ${PORT_LOGDIR}
It suits my need for watching a compile in realtime.
/usr/local/bin/portalog: | #!/bin/bash
LOGFILE=$(ls -lt /var/log/portage/ | grep --color=never log | head -n1 | awk '{print $9}')
tailf /var/log/portage/${LOGFILE}
|
|
|
Back to top |
|
|
gringo Advocate
Joined: 27 Apr 2003 Posts: 3793
|
Posted: Wed Nov 23, 2011 10:46 am Post subject: |
|
|
Quote: | Is it good for the future of Gentoo, for attracting and keeping new users, to have this feature enabled or not |
thats the point i think, those that have been using gentoo for some time probably shouldnt care about the defaults in case they can tune it ... i dont care, there are other defaults in portage i dont like and i just modify them to suit my needs.
But i dont see how a new gentoo user would take ANY advantage of seeing shit scrolling on the screen, shit that he probably will not even be able to read anyways and therefore has for example no idea on what stage of the emerge process portage currently is. With the silent output the user has a clean overview of whats going on.
Yes, maybe it could be a bit more verbose and as someone pointed out it should inform the user about other stuff too but there is no need at all to have the complete build process scrolling on your screen, its just useless for almost everyone and i have yet to see a valid argument saying this is usefull for newcomers.
Having it scrolling so that newcomers know that "something" is happening is just silly IMO. Briefly tell them instead what is happening, show them how to know more in case they are interested and show them how to locate and understand the logs.
cheers guys |
|
Back to top |
|
|
aidanjt Veteran
Joined: 20 Feb 2005 Posts: 1118 Location: Rep. of Ireland
|
Posted: Wed Nov 23, 2011 11:45 am Post subject: |
|
|
karmaking wrote: | No, it's not nonsense. It has the sense of... |
How quantified. _________________
juniper wrote: | you experience political reality dilation when travelling at american political speeds. it's in einstein's formulas. it's not their fault. |
|
|
Back to top |
|
|
Nerdanel Apprentice
Joined: 27 Apr 2003 Posts: 161 Location: Finland
|
Posted: Wed Nov 23, 2011 7:48 pm Post subject: |
|
|
I would like to ask the hiding proponents if they still would like to hide the compile messages if every program in the portage tree used cmake or something similar? |
|
Back to top |
|
|
zmedico Developer
Joined: 02 Jan 2004 Posts: 352 Location: California USA
|
Posted: Wed Nov 23, 2011 8:12 pm Post subject: |
|
|
Nerdanel wrote: | I would like to ask the hiding proponents if they still would like to hide the compile messages if every program in the portage tree used cmake or something similar? |
One of the reasons for enabling --quiet-build by default is for consistency with the --jobs user interface. With --jobs, there can be multiple builds running at the same time, so it could be confusing to mix their build output together on the screen. This issue would apply even if every ebuild used cmake or something similar. _________________ Zac |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Wed Nov 23, 2011 9:00 pm Post subject: |
|
|
zmedico wrote: | One of the reasons for enabling --quiet-build by default is for consistency with the --jobs user interface. |
Give up your jedi mind trick on us zac
Since when --jobs>1 is the new gentoo default ? |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10589 Location: Somewhere over Atlanta, Georgia
|
Posted: Wed Nov 23, 2011 9:15 pm Post subject: |
|
|
/me waves hand in front of the screen while intoning, "These aren't the emerge options you're looking for."
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
zmedico Developer
Joined: 02 Jan 2004 Posts: 352 Location: California USA
|
Posted: Wed Nov 23, 2011 9:37 pm Post subject: |
|
|
krinn wrote: | Since when --jobs>1 is the new gentoo default ? |
It's one of those things that you configure manually, like MAKEOPTS. However, with the average number of cpu cores increasing rapidly, it's natural that more users will tend to use --jobs in order to minimize overall build time. Enabling --quiet-build by default will provide a more consistent experience across the broad spectrum of users, regardless of whether or not they happen to use --jobs. _________________ Zac |
|
Back to top |
|
|
disi Veteran
Joined: 28 Nov 2003 Posts: 1354 Location: Out There ...
|
Posted: Wed Nov 23, 2011 10:18 pm Post subject: |
|
|
zmedico wrote: | krinn wrote: | Since when --jobs>1 is the new gentoo default ? |
It's one of those things that you configure manually, like MAKEOPTS. However, with the average number of cpu cores increasing rapidly, it's natural that more users will tend to use --jobs in order to minimize overall build time. Enabling --quiet-build by default will provide a more consistent experience across the broad spectrum of users, regardless of whether or not they happen to use --jobs. |
Hmm, hmm. If I enable --jobs=3, then the build output is suppressed anyway, even with --quiet-build=n. So this is no argument to suppress single emerge?
//edit: ah, I get you now _________________ Gentoo on Uptime Project - Larry is a cow |
|
Back to top |
|
|
krinn Watchman
Joined: 02 May 2003 Posts: 7470
|
Posted: Wed Nov 23, 2011 11:30 pm Post subject: |
|
|
disi wrote: |
//edit: ah, I get you now |
You're not jabba yet |
|
Back to top |
|
|
FizzyWidget Veteran
Joined: 21 Nov 2008 Posts: 1133 Location: 127.0.0.1
|
Posted: Sun Nov 27, 2011 3:30 pm Post subject: |
|
|
so just to see if i have this right, if i add --jobs to EMERGE_DEFAULT_OPTS, i don't need to have makeopts=j5 set? or is it basically the same thing? _________________ I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10589 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Nov 27, 2011 3:55 pm Post subject: |
|
|
Nope. MAKEOPTS launches multiple simultaneous source code compiles within a particular package build, while --jobs launches multiple simultaneous package builds. If you have a large, multi-core system, you may need both to keep all cores busy. If you have two or less cores, then --jobs will probably slow you down.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
FizzyWidget Veteran
Joined: 21 Nov 2008 Posts: 1133 Location: 127.0.0.1
|
Posted: Sun Nov 27, 2011 4:16 pm Post subject: |
|
|
so a minimum of say four cores and above? _________________ I know 43 ways to kill with a SKITTLE, so taste my rainbow bitch. |
|
Back to top |
|
|
John R. Graham Administrator
Joined: 08 Mar 2005 Posts: 10589 Location: Somewhere over Atlanta, Georgia
|
Posted: Sun Nov 27, 2011 4:20 pm Post subject: |
|
|
That's probably a decent thumb rule. However, the goal is to keep all the cores occupied. If you notice that MAKEOPTS isn't doing it for you, then you can set --jobs above 1.
- John _________________ I can confirm that I have received between 0 and 499 National Security Letters. |
|
Back to top |
|
|
vinky Apprentice
Joined: 24 Feb 2005 Posts: 214 Location: Sweden
|
Posted: Wed Nov 30, 2011 10:53 am Post subject: |
|
|
One good thing with --quiet-build=y by default is that the messages from emerge (about errors , post-merge/post-install messages etc.) will be more distinct since there will be less overall output together with a pointer to the build.log for the failed build(s) => less common problem with users only pasting the last x lines of the output which often doesn't show the actual errors
Maybe add somethings about where the build.log can be found during the merge and also better info about which stage its on (not only building or installing) to make this "feature" better |
|
Back to top |
|
|
f4c3m3l70r n00b
Joined: 19 Jul 2011 Posts: 47
|
Posted: Wed Nov 30, 2011 3:20 pm Post subject: |
|
|
Showing output with high resolution in console slows the compilation down.
The install Iso shouldnt use high res/framebuffer by default. _________________ i7-4820X | ROG RIVE | 16GB 2400MHz CL10 | SSD 850 Pro | Essence STX | GTX970 |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Nov 30, 2011 6:02 pm Post subject: |
|
|
vinky wrote: | better info about which stage its on (not only building or installing) to make this "feature" better |
This would be very nice.
Simultaneously, it would be very nice to have an option to make the output happen only when a stage really changes:
Having a display of the current load is convenient on a local system, but it is rather inconvenient on a remote system with a very limited bandwith. In fact, with the current display of load, if you use tmux or screen, there is more traffice going over the line for updating the windows title than if you put the previous output into a background window: This is currently preventing me to use the new feature on my remote systems... |
|
Back to top |
|
|
zmedico Developer
Joined: 02 Jan 2004 Posts: 352 Location: California USA
|
Posted: Wed Nov 30, 2011 6:13 pm Post subject: |
|
|
mv wrote: | vinky wrote: | better info about which stage its on (not only building or installing) to make this "feature" better |
This would be very nice.
Simultaneously, it would be very nice to have an option to make the output happen only when a stage really changes: |
Bug 391323 is about adding additional information to --quiet-build output (possibly controlled by separate options).
mv wrote: | Having a display of the current load is convenient on a local system, but it is rather inconvenient on a remote system with a very limited bandwith. In fact, with the current display of load, if you use tmux or screen, there is more traffice going over the line for updating the windows title than if you put the previous output into a background window: This is currently preventing me to use the new feature on my remote systems... |
If you use --quiet then it will not update the display for load average changes. If necessary, we can add a separate option to control that. _________________ Zac |
|
Back to top |
|
|
mv Watchman
Joined: 20 Apr 2005 Posts: 6747
|
Posted: Wed Nov 30, 2011 8:26 pm Post subject: |
|
|
zmedico wrote: | If you use --quiet then it will not update the display for load average changes. |
Thanks. This seems reasonable, but I am unsure which additional information I might then be missing: The documentation is rather unclear about --quiet.
Quote: | If necessary, we can add a separate option to control that. |
Since --quiet-build is already added, if would perhaps make sense to allow more finetuning of the other --quiet features as well (since I had never used --quiet, I can only guess where it takes effect, but it certainly would be useful to allow e.g. separation of the effect for downloading and compiling/installing as remarked in the bugreport you mentioned). |
|
Back to top |
|
|
rogerx Tux's lil' helper
Joined: 06 Apr 2004 Posts: 118
|
Posted: Fri Dec 02, 2011 7:01 am Post subject: Use debug/info levels instead of quiet options |
|
|
I'm not going to vote on this one because of this issue:
When specifying "--quiet-build=y", it does not show einfo and ewarn. With "--quiet-build=y", it shows nothing at all! Which doesn't make sense.
Using "--quiet-build=n", you get everything.
What you should really be doing is using debug/verbose/info levels!
ie.
info level 0 = no info except return value (ie. 0 or 1, ...)
info level 1 = Just output einfo & ewarn data, along with return value.
info level 2 = einfo, ewarn, and compile data
info level 3 = compile data and installed files data
(level 2 likely could be omitted, and use level 3)
My bottom suggestion, use something a little better to get us an option with no output and an option to to provide only ewarn and einfo data. The current solution fails miserably and is bad for scripting. _________________ Roger
http://rogerx.freeshell.org/ |
|
Back to top |
|
|
zmedico Developer
Joined: 02 Jan 2004 Posts: 352 Location: California USA
|
Posted: Fri Dec 02, 2011 7:17 am Post subject: Re: Use debug/info levels instead of quiet options |
|
|
rogerx wrote: | When specifying "--quiet-build=y", it does not show einfo and ewarn. With "--quiet-build=y", it shows nothing at all! Which doesn't make sense.
Using "--quiet-build=n", you get everything. |
Actually, the default PORTAGE_ELOG_SYSTEM="save_summary echo" setting causes elog messages to be echoed before emerge exits, regardless of your --quiet-build setting. The default PORTAGE_ELOG_CLASSES="log warn error" setting makes it so that only elog, ewarn, and eerror messages are shown by default. It omits einfo messages since those are typically uninteresting. For example, most people aren't interested in the names of patches that epatch displays via einfo.
rogerx wrote: | What you should really be doing is using debug/verbose/info levels!
ie.
info level 0 = no info except return value (ie. 0 or 1, ...)
info level 1 = Just output einfo & ewarn data, along with return value.
info level 2 = einfo, ewarn, and compile data
info level 3 = compile data and installed files data
(level 2 likely could be omitted, and use level 3)
My bottom suggestion, use something a little better to get us an option with no output and an option to to provide only ewarn and einfo data. |
Bug 391323 is about adding additional information to --quiet-build output (possibly controlled by separate options).
rogerx wrote: | The current solution fails miserably and is bad for scripting. |
I think that people who want to analyze build output, generally, are better served by PORT_LOGDIR (refer to `man make.conf` for more information about that). In case you didn't know, you can change it back to the old default like this:
Code: | echo "EMERGE_DEFAULT_OPTS=\"\${EMERGE_DEFAUT_OPTS} --quiet-build=n\"" >> /etc/make.conf |
_________________ Zac |
|
Back to top |
|
|
|