Summary: | sys-apps/portage: emerge is aggressively forcing NO_COLOR on packages against user's wishes | ||
---|---|---|---|
Product: | Portage Development | Reporter: | Michał Górny <mgorny> |
Component: | Core - Ebuild Support | Assignee: | Portage team <dev-portage> |
Status: | RESOLVED FIXED | ||
Severity: | normal | CC: | sam, ulm |
Priority: | Normal | Keywords: | InVCS, PullRequest |
Version: | unspecified | ||
Hardware: | All | ||
OS: | Linux | ||
See Also: |
https://bugs.gentoo.org/show_bug.cgi?id=898224 https://github.com/gentoo/portage/pull/1189 https://github.com/gentoo/portage/pull/1188 |
||
Whiteboard: | |||
Package list: | Runtime testing required: | --- | |
Bug Depends on: | 916977 | ||
Bug Blocks: |
Description
Michał Górny
2023-11-25 12:27:39 UTC
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(+) |