Re: [PATCH] Stop implicitly manipulating `NO_COLOR`/`NOCOLOR`

Michał Górny <[email protected]> Sun, 26 Nov 2023 19:58:10 +0100
Newsgroups gmane.linux.gentoo.portage.devel
Organization Gentoo
Message-ID <[email protected]>
--=-tefEIiye0gVv0MUwUElz
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sun, 2023-11-26 at 18:33 +0100, Ulrich Mueller wrote:
> > > > > > On Sun, 26 Nov 2023, Micha=C5=82 G=C3=B3rny wrote:
>=20
> > 3. Forcing `NO_COLOR=3D1` turns out to cause random test failures,
> > =C2=A0=C2=A0=C2=A0and while fixing them is commendable, it is a pain fo=
r arch testing
> > =C2=A0=C2=A0=C2=A0and it is currently blocking stabilization requests.
>=20
> 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=3D1 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.

>=20
> > 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 colo=
r
> > codes, one can either filter them via `ansifilter(1)` (as the manpages
> > already recommend) or explicitly set `NO_COLOR`.
>=20
> Will this still guarantee that NO_COLOR=3D1 from the environment is alway=
s
> passed on to the build system?
>=20
> Otherwise, it would break ebuild-mode in some configurations.
>=20

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

--=20
Best regards,
Micha=C5=82 G=C3=B3rny


--=-tefEIiye0gVv0MUwUElz
Content-Type: application/pgp-signature; name="signature.asc"
Content-Description: This is a digitally signed message part

-----BEGIN PGP SIGNATURE-----

iQFGBAABCgAwFiEEx2qEUJQJjSjMiybFY5ra4jKeJA4FAmVjlUISHG1nb3JueUBn
ZW50b28ub3JnAAoJEGOa2uIyniQOTAIIAKHMaIhfLIbm3ylDO6SSe9DJelXfimBr
ERPfbGw9OE192dRS7fAVmITIPLwptt/0W0PwKCNJMH8tYUtKWdzQxf3WTtreYs2F
cUMH5AoVj6bUesm41nXWv8ifHICosgXcasuJKnQrFjgTRsF32GrxpPYt2lM5bA8J
vilUhjwVAzyDHt4Ln5Eq9aDrEFt/pDHX5mLkJx2Y9g5JChlr8gObQstlELEqQa0X
yY0sj5CyUaPCKpXTcIiPlcH7cTyQjz3iBVfs/KPxlCDrvmGnuX1ftxM60RktCDmc
lsnVTU9VFGR5Pj0sXdgFm/uMwIy4G26x0Y0JY+AzJ5gub87wptHvOkk=
=3nzJ
-----END PGP SIGNATURE-----

--=-tefEIiye0gVv0MUwUElz--