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
signature.asc
Description: This is a digitally signed message part
