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--