Gentoo Websites Logo
Go to: Gentoo Home Documentation Forums Lists Bugs Planet Store Wiki Get Gentoo!
Bug 391323 - Make --quiet-build less quiet
Summary: Make --quiet-build less quiet
Status: CONFIRMED
Alias: None
Product: Portage Development
Classification: Unclassified
Component: Core - Interface (emerge) (show other bugs)
Hardware: All Linux
: Normal enhancement (vote)
Assignee: Portage team
URL:
Whiteboard:
Keywords:
Depends on:
Blocks: 184128 391317
  Show dependency tree
 
Reported: 2011-11-22 06:23 UTC by Ryan Hill (RETIRED)
Modified: 2023-07-18 21:59 UTC (History)
7 users (show)

See Also:
Package list:
Runtime testing required: ---


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Ryan Hill (RETIRED) gentoo-dev 2011-11-22 06:23:09 UTC
Currently --quiet-build outputs a very minimal amount of information.  I think this makes it an unattractive option for anyone but the most basic Gentoo user.  There are several things we could do to make it more useful to everyone while still hiding the output from the compile and install, which was the point of making it default.

- Display einfo/elog/ewarn/eerror etc. messages.  I believe this is actually a bug.  Shouldn't they always be shown?

- Don't hide the fetch progress.  I had a big distfile downloading off a slow mirror @ 5K/s and couldn't figure out why it was taking so long, or even if it had finished fetching yet.

- Display the phase messages (ie. "Unpacking source" "Preparing source in..." etc.)  I always want to know where in the build process I am.  Among other things I don't want to accidentally do a ^C it's in the middle of merging to the file system.

- Also, do not hide the merge to file system info when -v is used.  This would make it consistent with the behavior when --quiet-build=n is used.

- Display the build log on a ^C, just like with a die/error.  Again, make it consistent.

- QA warnings.  I'm on the fence with this one.  I think they should only be displayed to users of the dev profiles, so I wouldn't lose any sleep if they weren't on by default.

Personally I think --quiet-build should only apply to the src_configure, src_compile, src_test, and src_install phases.  This would still achieve the "goal" of no build output while making it something that people might actually use.
Comment 1 Zac Medico gentoo-dev 2011-11-25 05:23:51 UTC
(In reply to comment #0)
> Currently --quiet-build outputs a very minimal amount of information.  I think
> this makes it an unattractive option for anyone but the most basic Gentoo user.

It seems like you're assuming that "anyone but the most basic user" sits and monitors all of the output. That would require a lot of time and patience, and a lack of better things to do that I think most people don't have.

>  There are several things we could do to make it more useful to everyone while
> still hiding the output from the compile and install, which was the point of
> making it default.

Agreed.

> - Display einfo/elog/ewarn/eerror etc. messages.  I believe this is actually a
> bug.  Shouldn't they always be shown?

The default PORTAGE_ELOG_SYSTEM="save_summary echo" and PORTAGE_ELOG_CLASSES="log warn error" settings cause all of the elog, ewarn, and eerror messages to be echoed before emerge exits. I think it's reasonable to omit einfo, because einfo is mainly used for stuff that's uninteresting to most people, like to display the names of patches applied by epatch.

> - Don't hide the fetch progress.  I had a big distfile downloading off a slow
> mirror @ 5K/s and couldn't figure out why it was taking so long, or even if it
> had finished fetching yet.

I think it would be nice to have a debugger that could be used to check on things like this. That way, a user who's interested in information like fetch progress could use the debugger to attach to running emerge processes and query the information that they want.

> - Display the phase messages (ie. "Unpacking source" "Preparing source in..."
> etc.)  I always want to know where in the build process I am.  Among other
> things I don't want to accidentally do a ^C it's in the middle of merging to
> the file system.

Yes, that would be nice. It currently says when it's beginning an install, but doesn't say when it finishes (though you can tail emerge.log for that info).

> - Also, do not hide the merge to file system info when -v is used.  This would
> make it consistent with the behavior when --quiet-build=n is used.

That would produce a lot of output. I don't think -v is not fine-grained enough to control things that different users may want to enable or disable. I think we need separate flags this.

> - Display the build log on a ^C, just like with a die/error.  Again, make it
> consistent.

That seems reasonable.

> - QA warnings.  I'm on the fence with this one.  I think they should only be
> displayed to users of the dev profiles, so I wouldn't lose any sleep if they
> weren't on by default.

Agreed.

> Personally I think --quiet-build should only apply to the src_configure,
> src_compile, src_test, and src_install phases.  This would still achieve the
> "goal" of no build output while making it something that people might actually
> use.

I think this is another thing that we could add separate flags to control, so that people can tailor the output to suit their preferences.
Comment 2 Ryan Hill (RETIRED) gentoo-dev 2011-11-25 06:29:55 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > Currently --quiet-build outputs a very minimal amount of information.  I think
> > this makes it an unattractive option for anyone but the most basic Gentoo user.
> 
> It seems like you're assuming that "anyone but the most basic user" sits and
> monitors all of the output. That would require a lot of time and patience, and
> a lack of better things to do that I think most people don't have.

Well no, even I don't even sit and monitor all the output.  I just think we went from too much info to none at all, and the current behaviour isn't very appealing to any level of Gentoo user.  I think people in general want to know the progress of the thing they're trying to accomplish, and there have been several user interface studies that have found that when a performing lengthy task, a UI that displays a progress indicator is actually perceived to take less time than one that doesn't.  That's why Windows throws up a fake progress bar that continuously cycles when it has no idea how long something will take.

> > - Display einfo/elog/ewarn/eerror etc. messages.  I believe this is actually a
> > bug.  Shouldn't they always be shown?
> 
> The default PORTAGE_ELOG_SYSTEM="save_summary echo" and
> PORTAGE_ELOG_CLASSES="log warn error" settings cause all of the elog, ewarn,
> and eerror messages to be echoed before emerge exits. I think it's reasonable
> to omit einfo, because einfo is mainly used for stuff that's uninteresting to
> most people, like to display the names of patches applied by epatch.

Agreed about einfo.  But I'm not seeing any e* messages whatsoever except eqawarn:

$ cat quiettest-0.ebuild
# Copyright 1999-2011 Gentoo Foundation
# Distributed under the terms of the GNU General Public License v2
# $Header: $

DESCRIPTION=""
HOMEPAGE=""
SRC_URI=""

LICENSE=""
SLOT="0"
KEYWORDS="~amd64"
IUSE=""

DEPEND=""
RDEPEND="${DEPEND}"

pkg_setup() {
	for x in einfo elog ewarn eerror eqawarn; do
		${x} "${x}"
	done
}

src_compile() {
	for x in einfo elog ewarn eerror eqawarn; do
		${x} "${x}"
	done
}

pkg_preinst() {
	for x in einfo elog ewarn eerror eqawarn; do
		${x} "${x}"
	done
}

$ emerge -1 --quiet-build quiettest
Calculating dependencies... done!
>>> Verifying ebuild manifests
>>> Emerging (1 of 1) app-portage/quiettest-0 from tundra
>>> Installing (1 of 1) app-portage/quiettest-0
>>> Jobs: 1 of 1 complete                           Load avg: 0.18, 0.16, 0.22

 * Messages for package app-portage/quiettest-0:

 * eqawarn
 * eqawarn
 * eqawarn


PORTAGE_ELOG_SYSTEM was set to "echo" but "save_summary echo" makes no difference.

> > mirror @ 5K/s and couldn't figure out why it was taking so long, or even if it
> > had finished fetching yet.
> 
> I think it would be nice to have a debugger that could be used to check on
> things like this. That way, a user who's interested in information like fetch
> progress could use the debugger to attach to running emerge processes and query
> the information that they want.

I think it would be pretty cumbersome to have to use another app to get this kind of basic info.  --quiet-fetch I could see.

> > - Display the phase messages (ie. "Unpacking source" "Preparing source in..."
> > etc.)  I always want to know where in the build process I am.  Among other
> > things I don't want to accidentally do a ^C it's in the middle of merging to
> > the file system.
> 
> Yes, that would be nice. It currently says when it's beginning an install, but
> doesn't say when it finishes (though you can tail emerge.log for that info).

If phase messages were output I think that and the e* messages would cover 90% of my complaints.

> > - Also, do not hide the merge to file system info when -v is used.  This would
> > make it consistent with the behavior when --quiet-build=n is used.
> 
> That would produce a lot of output. I don't think -v is not fine-grained enough
> to control things that different users may want to enable or disable. I think
> we need separate flags this.

Ah I forgot -v also controls the display of USE flags.

> > Personally I think --quiet-build should only apply to the src_configure,
> > src_compile, src_test, and src_install phases.  This would still achieve the
> > "goal" of no build output while making it something that people might actually
> > use.
> 
> I think this is another thing that we could add separate flags to control, so
> that people can tailor the output to suit their preferences.

Sure, but I think this would be a good default.  If people complain it's still too verbose then further steps could be taken.
Comment 3 Zac Medico gentoo-dev 2011-11-25 07:02:21 UTC
(In reply to comment #2)
> But I'm not seeing any e* messages whatsoever except
> eqawarn:

It sounds like your PORTAGE_ELOG_CLASSES setting doesn't contain the default levels. You can use `portageq envvar PORTAGE_ELOG_CLASSES` to check. The developer profile has PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", which should behave like you want.
Comment 4 Ryan Hill (RETIRED) gentoo-dev 2011-11-26 01:45:01 UTC
> It sounds like your PORTAGE_ELOG_CLASSES setting doesn't contain the default
> levels. You can use `portageq envvar PORTAGE_ELOG_CLASSES` to check. The
> developer profile has PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", which
> should behave like you want.

Yep, it's just set to " qa".  I'm using default/linux/amd64/10.0/developer and not overriding it, so I don't know where the rest of it went.
Comment 5 Zac Medico gentoo-dev 2011-11-26 03:01:25 UTC
(In reply to comment #4)
> > It sounds like your PORTAGE_ELOG_CLASSES setting doesn't contain the default
> > levels. You can use `portageq envvar PORTAGE_ELOG_CLASSES` to check. The
> > developer profile has PORTAGE_ELOG_CLASSES="${PORTAGE_ELOG_CLASSES} qa", which
> > should behave like you want.
> 
> Yep, it's just set to " qa".  I'm using default/linux/amd64/10.0/developer and
> not overriding it, so I don't know where the rest of it went.

This is a regression, fixed in git now:

http://git.overlays.gentoo.org/gitweb/?p=proj/portage.git;a=commit;h=917e70d1009727115afbe90e297711d54b7e5374

I'll release portage-2.1.10.38 and 2.2.0_alpha78 with this fix ASAP.
Comment 6 Roger 2011-12-02 07:05:36 UTC
Use something like debug or info levels:

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)


This bug has my vote as well, as I like a quiet build, but output einfo & ewarn data.  This would be more script friendly.
Comment 7 Fredric Johansson 2011-12-02 21:34:53 UTC
(In reply to comment #1)
> (In reply to comment #0)
> > - Don't hide the fetch progress.  I had a big distfile downloading off a slow
> > mirror @ 5K/s and couldn't figure out why it was taking so long, or even if it
> > had finished fetching yet.
> 
> I think it would be nice to have a debugger that could be used to check on
> things like this. That way, a user who's interested in information like fetch
> progress could use the debugger to attach to running emerge processes and query
> the information that they want.
> 

Would it be possible to show the fetch info "side-by-side" somehow together with the merge output? I guess package name, speed and percentage of current or total done would be useful for a user

> > - Display the phase messages (ie. "Unpacking source" "Preparing source in..."
> > etc.)  I always want to know where in the build process I am.  Among other
> > things I don't want to accidentally do a ^C it's in the middle of merging to
> > the file system.
> 
> Yes, that would be nice. It currently says when it's beginning an install, but
> doesn't say when it finishes (though you can tail emerge.log for that info).
> 

ATM it is also hard to see which packages that is actually being emerged when running parallel builds (-jX with X >1). A long-running compile might get hidden far above the info for other later packages.
Comment 8 Zac Medico gentoo-dev 2011-12-05 20:24:41 UTC
(In reply to comment #7)
> Would it be possible to show the fetch info "side-by-side" somehow together
> with the merge output? I guess package name, speed and percentage of current o
> or total done would be useful for a user

FETCHCOMMAND and RESUMECOMMAND aren't very well suited to this, since they constrain us to the output of the program with the user may have configured. We'll have more control over the progress display if we use python libraries to implement the fetch.

> ATM it is also hard to see which packages that is actually being emerged when
> running parallel builds (-jX with X >1). A long-running compile might get
> hidden far above the info for other later packages.

You might try app-portage/genlop or qlop from app-portage/portage-utils. If you're interested in seeing build output for a specific build, a script like showbuild might be useful:

http://code.google.com/p/cj-overlay/source/browse/app-portage/showbuild/files/showbuild-0.5
Comment 9 Ben Kohler gentoo-dev 2012-03-29 15:38:45 UTC
WRT to the fetch issue specifically, why not have --quiet-build=y automatically start writing all fetch info to emerge-fetch.log, as parallel fetches do?  Or does writing that log file go too much against the idea of the --quiet-build=y flag?
Comment 10 Zac Medico gentoo-dev 2012-03-29 15:49:38 UTC
(In reply to comment #9)
> WRT to the fetch issue specifically, why not have --quiet-build=y
> automatically start writing all fetch info to emerge-fetch.log, as parallel
> fetches do?

With --jobs=1 (default), all of the fetch output does go to emerge-fetch.log when FEATURES=parallel-fetch is enabled (default). With --jobs > 1, some of it goes to individual logs since we don't want more than one fetcher writing to emerge-fetch.log simultaneously.
Comment 11 Ben Kohler gentoo-dev 2012-03-29 15:56:42 UTC
Ah I see now.  The case I encountered was a single-package w/ fetch, so no parallel enabled.  With quiet, no parallel, it does indeed go to build.log.  Sorry for the noise/confusion.