Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
Should portage hide build output from the user by default?
View unanswered posts
View posts from last 24 hours

Goto page Previous  1, 2, 3 ... , 9, 10, 11  Next  
Reply to topic    Gentoo Forums Forum Index Gentoo Chat
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%
 28%  [ 132 ]
emerge should show build output by default (unless --quiet-build=y)
51%
 51%  [ 236 ]
The -v option should control whether build output is shown or not by default
17%
 17%  [ 80 ]
Other (please comment)
1%
 1%  [ 9 ]
Total Votes : 457

Author Message
firephoto
Veteran
Veteran


Joined: 29 Oct 2003
Posts: 1560
Location: +48° 5' 23.40", -119° 48' 30.00"

PostPosted: Tue Nov 22, 2011 9:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
karmaking
n00b
n00b


Joined: 11 Feb 2004
Posts: 74
Location: Berlin, Germany

PostPosted: Tue Nov 22, 2011 9:42 pm    Post subject: Reply with quote

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
View user's profile Send private message
Nerdanel
Apprentice
Apprentice


Joined: 27 Apr 2003
Posts: 161
Location: Finland

PostPosted: Tue Nov 22, 2011 11:21 pm    Post subject: Reply with quote

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
View user's profile Send private message
lasuit
n00b
n00b


Joined: 01 Mar 2011
Posts: 12
Location: London, England

PostPosted: Tue Nov 22, 2011 11:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
Suicidal
l33t
l33t


Joined: 30 Jul 2003
Posts: 940
Location: /dev/null

PostPosted: Wed Nov 23, 2011 1:58 am    Post subject: Reply with quote

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}

_________________
Who controls the past now, controls the future
Who controls the present now, controls the past.
Back to top
View user's profile Send private message
gringo
Advocate
Advocate


Joined: 27 Apr 2003
Posts: 3734

PostPosted: Wed Nov 23, 2011 10:46 am    Post subject: Reply with quote

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
View user's profile Send private message
aidanjt
Veteran
Veteran


Joined: 20 Feb 2005
Posts: 1102
Location: Rep. of Ireland

PostPosted: Wed Nov 23, 2011 11:45 am    Post subject: Reply with quote

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
View user's profile Send private message
Nerdanel
Apprentice
Apprentice


Joined: 27 Apr 2003
Posts: 161
Location: Finland

PostPosted: Wed Nov 23, 2011 7:48 pm    Post subject: Reply with quote

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
View user's profile Send private message
zmedico
Developer
Developer


Joined: 02 Jan 2004
Posts: 284
Location: California USA

PostPosted: Wed Nov 23, 2011 8:12 pm    Post subject: Reply with quote

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
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4270

PostPosted: Wed Nov 23, 2011 9:00 pm    Post subject: Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7774
Location: Somewhere over Atlanta, Georgia

PostPosted: Wed Nov 23, 2011 9:15 pm    Post subject: Reply with quote

/me waves hand in front of the screen while intoning, "These aren't the emerge options you're looking for." :D

- John
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
zmedico
Developer
Developer


Joined: 02 Jan 2004
Posts: 284
Location: California USA

PostPosted: Wed Nov 23, 2011 9:37 pm    Post subject: Reply with quote

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
View user's profile Send private message
disi
Veteran
Veteran


Joined: 28 Nov 2003
Posts: 1354
Location: Out There ...

PostPosted: Wed Nov 23, 2011 10:18 pm    Post subject: Reply with quote

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
View user's profile Send private message
krinn
Advocate
Advocate


Joined: 02 May 2003
Posts: 4270

PostPosted: Wed Nov 23, 2011 11:30 pm    Post subject: Reply with quote

disi wrote:

//edit: ah, I get you now :)

You're not jabba yet :)
Back to top
View user's profile Send private message
FizzyWidget
Veteran
Veteran


Joined: 21 Nov 2008
Posts: 1113
Location: 127.0.0.1

PostPosted: Sun Nov 27, 2011 3:30 pm    Post subject: Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7774
Location: Somewhere over Atlanta, Georgia

PostPosted: Sun Nov 27, 2011 3:55 pm    Post subject: Reply with quote

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
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
FizzyWidget
Veteran
Veteran


Joined: 21 Nov 2008
Posts: 1113
Location: 127.0.0.1

PostPosted: Sun Nov 27, 2011 4:16 pm    Post subject: Reply with quote

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
View user's profile Send private message
John R. Graham
Administrator
Administrator


Joined: 08 Mar 2005
Posts: 7774
Location: Somewhere over Atlanta, Georgia

PostPosted: Sun Nov 27, 2011 4:20 pm    Post subject: Reply with quote

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
_________________
This space intentionally left blank.
Back to top
View user's profile Send private message
vinky
Apprentice
Apprentice


Joined: 24 Feb 2005
Posts: 214
Location: Sweden

PostPosted: Wed Nov 30, 2011 10:53 am    Post subject: Reply with quote

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
View user's profile Send private message
f4c3m3l70r
n00b
n00b


Joined: 19 Jul 2011
Posts: 40

PostPosted: Wed Nov 30, 2011 3:20 pm    Post subject: Reply with quote

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 | TridentX 16GB 2400MHz | SSD 840 Pro | Essence STX | GTX680
Back to top
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4120

PostPosted: Wed Nov 30, 2011 6:02 pm    Post subject: Reply with quote

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
View user's profile Send private message
zmedico
Developer
Developer


Joined: 02 Jan 2004
Posts: 284
Location: California USA

PostPosted: Wed Nov 30, 2011 6:13 pm    Post subject: Reply with quote

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
View user's profile Send private message
mv
Advocate
Advocate


Joined: 20 Apr 2005
Posts: 4120

PostPosted: Wed Nov 30, 2011 8:26 pm    Post subject: Reply with quote

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
View user's profile Send private message
rogerx
n00b
n00b


Joined: 06 Apr 2004
Posts: 70

PostPosted: Fri Dec 02, 2011 7:01 am    Post subject: Use debug/info levels instead of quiet options Reply with quote

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
View user's profile Send private message
zmedico
Developer
Developer


Joined: 02 Jan 2004
Posts: 284
Location: California USA

PostPosted: Fri Dec 02, 2011 7:17 am    Post subject: Re: Use debug/info levels instead of quiet options Reply with quote

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
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Gentoo Chat All times are GMT
Goto page Previous  1, 2, 3 ... , 9, 10, 11  Next
Page 10 of 11

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum