Should portage hide build output from the user by default?

[firephoto]

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.

[karmaking]

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).

[Nerdanel]

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.

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.

[lasuit]

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.

[Suicidal]

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.

Code: Select all

#!/bin/bash

        LOGFILE=$(ls -lt /var/log/portage/ | grep --color=never log | head -n1 | awk '{print $9}')

        tailf /var/log/portage/${LOGFILE}

[gringo]

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

[aidanjt]

No, it's not nonsense. It has the sense of...

How quantified.

[Nerdanel]

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?

[zmedico]

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.

[krinn]

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 ?

[John R. Graham]

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

- John

[zmedico]

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.

[disi]

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

[krinn]

//edit: ah, I get you now

You're not jabba yet

[FizzyWidget]

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?

[John R. Graham]

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

[FizzyWidget]

so a minimum of say four cores and above?

[John R. Graham]

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

[vinky]

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

[f4c3m3l70r]

Showing output with high resolution in console slows the compilation down.
The install Iso shouldnt use high res/framebuffer by default.

[mv]

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...

[zmedico]

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]Bug 391323[/bug] is about adding additional information to --quiet-build output (possibly controlled by separate options).

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.

[mv]

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.

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 [bug=391323]bugreport[/bug] you mentioned).

[rogerx]

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.

[zmedico]

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.

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]Bug 391323[/bug] is about adding additional information to --quiet-build output (possibly controlled by separate options).

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: Select all

echo "EMERGE_DEFAULT_OPTS="\${EMERGE_DEFAUT_OPTS} --quiet-build=n"" >> /etc/make.conf