new style of merge screen.
what will happen if a merge fails?
where to look for error messages?

today's update of 7 files did the same way.
no scrolling messages while merge of any of them_________________reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

This depends on your video driver, your terminal emulator en a few other things. However you can achieve the same thing just minimizing your window or going to another workspace.

However, even if I feel a bit disoriented right now, I am glad that this was implemented, overall taking into account that this new default can easily be reversed if you really want to get the old behaviour._________________Gentoo Handbook | My website

Seems like a punishment to those build systems that have clean output and progress indication like cmake. After reading the discussion that triggered this, it went from those ebuilds that can't display necessary errors needing changes to ... well I guess it just went to killing the build output completely.

What exactly was the issue that was corrected with this change to the defaults?_________________#gentoo-kde on freenode

In my opinion, an upstream build system should not run quietly, unless it also has the ability to go back and give you a full explanation when things break. I dislike getting a build log where you have a compilation error, the name of the file, and nothing else. You do not know what compiler options the build system used and may not even know which features it decided to turn on/off. I much prefer the idea that the upstream build system be noisy and that Portage hide the output until needed, then go back and display the log when an error occurs.

In my opinion, an upstream build system should not run quietly [...] You do not know what compiler options the build system used and may not even know which features it decided to turn on/off

You are mixing two things here: One is to display useful information which might help debugging (like the compiler/linker flags, utilities and features which are used - this should be output at the end of the configure phase, but can for autotools pakckages usually found in much more detail in the configure.log), and the other is useless output during compilation like repeating all compiler/linker flags for every command and even showing "if"-statements and other completely useless crap.

The point is that making the latter output more verbose does not give the desired information either but just makes looking at logs (and even more communicating and storing them) much more cumbersome and resource intensive. So the right[TM] way to go (at least with autotools based packages) would be to encourage --enable-silent-rules and to post the configure.log in case the upstream configure output is not very verbose in what is going on.

Unfortunately, gentoo takes currently the opposite road: It seems that --disable-silent-rules will be default in gentoo, soon.

I have encountered enough build systems that have "special" flags for particular subdirectories that I consider the entire build log potentially useful. I recognize that some build systems are repetitive enough that your statement is correct, but some of them are not. I would much rather receive the full and noisy build log, then reprocess it with sed/grep to discard uninteresting sections. The storage cost is unfortunate, but necessary.

I have encountered enough build systems that have "special" flags for particular subdirectories that I consider the entire build log potentially useful.

In the best case, this will show the compiler/linker flags. Concerning the important information that you ask for - which packages are (auto)detected, which features are activated, and in case of complex packages like texlive, which environment variables are possibly set (for the non-compiling part) - all this information will still only be available in the config.log (or might be visible during configure output). In particular, from the information which you are missing you gain at most one relatively unimportant - the compiler/linker flags - and these are in almost all cases already shown in the corresponding (subdirectory) configure output, since autotools does explicitly not support setting them locally per file/subdirectory but only per (sub)project.

Again, you assume that upstream uses a build system that provides some sort of sanity. There are packages that either skip autotools/cmake entirely or abuse them so badly that they should have skipped them. I never said that the config.log should not be included in a problem report. I only said that the build.log should be verbose and should be available. I do not care whether the build system is verbose on the console that runs it. I care only that the build system be sufficiently verbose in its logging that I can either identify why it broke or that I can provide a concise set of questions to the reporter.

I'm in two minds about this change, really. On the one hand I like to see precisely what's happening, but on the other hand it does make the output very compact and easy to assimilate when one is doing an emerge world:

* GNU info directory index is up-to-date.
* After world updates, it is important to remove obsolete packages with
* emerge --depclean. Refer to `man emerge` for more information.
meshedgedx fitzcarraldo #

I'll have to defer my final decision on whether or not to assign EMERGE_DEFAULT_OPTS="--quiet-build=n" in /etc/make.conf until I see what the output looks like when there is a problem with an emerge world._________________Clevo W230SS: amd64, OpenRC, nvidia-drivers & xf86-video-intel.
Compal NBLB2: ~amd64, OpenRC, xf86-video-ati, dual booting with Win 7 Pro 64-bit.
KDE on both laptops.Fitzcarraldo's blog

Unfortunately, this is not the case for the net traffic if you use screen or tmux: Displaying the current load average regularly in the title bar needs (slightly) more net resources then the previous way of updating the bar only once per emerge phase. That is the main reason why I will not be using it on remote systems.

very unwisely i decided to merge libreoffice which runs for last 7 hours.
the previous packages merged times not shown as the post shown above
what changes you have made?

edit
after reading your post again i find it is in your wish list
well i too hope these features can be added and ETA of the running merge_________________reach out a little bit more to catch it (DON'T BELIEVE the advocate part under my user name)

well i too hope these features can be added and ETA of the running merge

padoor, do you know about genlop (app-portage/genlop)? It can provide running status and remaining time estimates.

- John

I know it, but I don't know why, almost always I tried it, genlop told me, there is no running emerge. But it was not true.

It being a separate command also reduces it's usefulness and like you said the fact that it has to be ran when the emerge is going and it just doesn't wait for something to output is a pita too... and actually as I just check it out now I see it just runs, checks the running emerge and outputs some time then it's done. Not an ongoing progress without some other foo obviously._________________#gentoo-kde on freenode