Basically, if either of the following is true: 1) `--color n` is passed 2) TERM=dumb 3) output is not to a tty 4) AbstractEbuildProcess is used with background=True (I guess that means --quiet-build) emerge implicitly sets NO_COLOR=true in the build environment. I can't see any obvious way to stop Portage from doing that. As more packages start respecting that, they stop outputting colors. Besides this being against the user wishes (just because Portage is running without colors, it doesn't mean I don't want colors in build logs), this is also causing significant pain for arch testers, causing lots of test failures in random packages that assume they're being tested in "vanilla" env.
Is it possible to strip colours from the terminal output but leave them in the logs? Or maybe that's too expensive to be worth it?
(In reply to James Le Cuirot from comment #1) > Is it possible to strip colours from the terminal output but leave them in > the logs? Or maybe that's too expensive to be worth it? Yes, you can use ansifilter(1) for that. Portage man already suggests using it as a filter.
One might've thought that `--color` already controlled `NO_COLOR` for everything running under emerge based on the manpage: --color < y | n > Enable or disable color output. This option will override NO_COLOR and NOCOLOR (see make.conf(5)) and may also be used to force color output when stdout is not a tty (by default, color is disabled unless stdout is a tty). Thus, it makes sense to me if we make this configurable based on `--color`.
I'd rather let users set FORCE_COLOR and NO_COLOR as they wish, and therefore make it possible to control color output of emerge (i.e. the one going straight to the console) independently of color output of commands inside (i.e. these going to the logs). Unless I'm mistaken, you can't e.g. do `NO_COLOR=1 emerge --color y ...` to get colorful emerge output with color-free logs. What's even worse, you can't reenable colors in logs when using `emerge --jobs`.
In https://github.com/gentoo/portage/pull/1189 I decoupled NO_COLOR from isatty and TERM. For now, I've left it so that NO_COLOR=true in make.conf disables color in the portage UI for now, since decoupling there seems like a more drastic change.
I didn't see https://github.com/gentoo/portage/pull/1188 before I created 1189, but anyway 1188 seems pretty reasonable.
The bug has been referenced in the following commit(s): https://gitweb.gentoo.org/proj/portage.git/commit/?id=3011e502b399d2d02e292480252525e16dc1cfb4 commit 3011e502b399d2d02e292480252525e16dc1cfb4 Author: Michał Górny <mgorny@gentoo.org> AuthorDate: 2023-11-26 15:17:47 +0000 Commit: Michał Górny <mgorny@gentoo.org> CommitDate: 2023-11-30 04:43:53 +0000 Stop implicitly manipulating `NO_COLOR`/`NOCOLOR` Stop implicitly forcing `NO_COLOR` and `NOCOLOR` in ebuild environment. This is undesired for several reasons: 1. It makes it impossible to control color for emerge output independently of command output, e.g. when one goes to a pty while the other goes to logs. 2. It makes it impossible to get color output in logs when running `emerge --jobs ...`. 3. Forcing `NO_COLOR=1` turns out to cause random test failures, and while fixing them is commendable, it is a pain for arch testing and it is currently blocking stabilization requests. With the new approach, the color output in programs is consistent between using ``--jobs`` or ``--quiet-build``, and not. Therefore, both cases generate uniform logs. In order to obtain logs free of color codes, one can either filter them via `ansifilter(1)` (as the manpages already recommend) or explicitly set `NO_COLOR`. Furthermore, one can combine color-free build output (for clean logs) with colorful emerge output by using: NO_COLOR=true emerge --color y ... Bug: https://bugs.gentoo.org/918515 Signed-off-by: Michał Górny <mgorny@gentoo.org> Closes: https://github.com/gentoo/portage/pull/1188 Signed-off-by: Michał Górny <mgorny@gentoo.org> NEWS | 5 +++++ bin/ebuild | 4 ---- lib/_emerge/AbstractEbuildProcess.py | 6 ------ lib/_emerge/actions.py | 5 ----- lib/portage/tests/resolver/ResolverPlayground.py | 3 --- 5 files changed, 5 insertions(+), 18 deletions(-)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=baec60737ddc370dcf77ce1c797ff187357c4b14 commit baec60737ddc370dcf77ce1c797ff187357c4b14 Author: Sam James <sam@gentoo.org> AuthorDate: 2023-12-01 02:54:12 +0000 Commit: Sam James <sam@gentoo.org> CommitDate: 2023-12-01 02:54:29 +0000 sys-apps/portage: add 3.0.56 Closes: https://bugs.gentoo.org/760893 Closes: https://bugs.gentoo.org/917033 Closes: https://bugs.gentoo.org/917259 Closes: https://bugs.gentoo.org/917315 Closes: https://bugs.gentoo.org/918515 Closes: https://bugs.gentoo.org/918682 Closes: https://bugs.gentoo.org/918683 Closes: https://bugs.gentoo.org/916977 Signed-off-by: Sam James <sam@gentoo.org> sys-apps/portage/Manifest | 1 + sys-apps/portage/portage-3.0.56.ebuild | 238 +++++++++++++++++++++++++++++++++ 2 files changed, 239 insertions(+)
