Re: [gentoo-portage-dev] [PATCH] Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`

["Michał Górny" <mgorny@gentoo.org>]

[-- Attachment #1: Type: text/plain, Size: 1432 bytes --]

On Sun, 2023-11-26 at 18:33 +0100, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Nov 2023, Michał Górny wrote:
> 
> > 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.
> 
> I'd argue that test suites that fail because of NO_COLOR are broken.
> IIUC, these failures will show up for users who set NO_COLOR=1 in their
> make.conf or in the environment?

Sure, they are broken.  However, as I said I'd rather fix them in my
spare time than have to fix them to unblock a security stablereq because
implicit Portage logic blocks all AT work on a minor issue that's non-
trivial to fix.

> 
> > 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`.
> 
> Will this still guarantee that NO_COLOR=1 from the environment is always
> passed on to the build system?
> 
> Otherwise, it would break ebuild-mode in some configurations.
> 

Yes, I've tested it and it worked.  Both for passing from external env
and via make.conf.

-- 
Best regards,
Michał Górny


[-- Attachment #2: This is a digitally signed message part --]
[-- Type: application/pgp-signature, Size: 512 bytes --]