Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 2021-09-28, Ulrich Mueller wrote: > > On Tue, 28 Sep 2021, Michał Górny wrote: > > On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote: > >> Markers: (--) probed, (**) from config file, (==) default > >> setting, > >> (++) from command line, (!!) notice, (II) informational, > >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > >> > >> So, maybe change einfo from [--] to [II]? > > > Nah, the whole point is to avoid letters since it's not very > > important. > > Alternatively to '[--]' I could make it look down '[..]' or maybe even > > without eyes entirely '[ ]'. > > Yeah, anything but [--]. The version with the dots is nice. I think any change from only-color would be an improvement; mgorny's first version looks nice. I can see why symmetry with Xorg EE, WW, etc. has an appeal but also the downsides of a) since things don't actually line up 1:1 it could be misleading to try; b) it's also somewhat language-biased. Something a lot of tools have started doing is [?] prefixes to their output; I don't know if there's even a semi-formal spec on it, but what seems to me to map well would be: [!] fatal error (die / eerror?) [*] important but nonfatal (ewarn?) [+] info, maybe memorable, but not harmful (elog?) [.] status/verbose message (einfo?) Could double that if preserving a 4-char-wide tag is preferred. That doesn't cover all needed, like eqawarn, but there are more to choose from. It's unfortunate that many of these are regex metacharacters, making slightly more (human) overhead when grepping, but we already have that with the [] delimeters. > > or maybe even without eyes entirely '[ ]'. For no reason I can articulate, the empty one bugs me. I would get over it though ;) Thanks, -- Hank Leininger 9606 3BF9 B593 4CBC E31A A384 6200 F6E3 781E 3DD7 signature.asc Description: Digital signature
[gentoo-dev] Package up for grabs: >=app-emulation/docker-compose-2.0.0 (1.x.x was Python, 2.0.0 is Go)
Hi! docker-compose upstream has apparently re-written docker-compose in Golang from scratch. While I'm happy to keep maintaining the current python-based =2.0.0 in Gentoo. Thanks in advance! Best Sebastian
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
> On Tue, 28 Sep 2021, Michał Górny wrote: > On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote: >> Markers: (--) probed, (**) from config file, (==) default setting, >> (++) from command line, (!!) notice, (II) informational, >> (WW) warning, (EE) error, (NI) not implemented, (??) unknown. >> >> So, maybe change einfo from [--] to [II]? > Nah, the whole point is to avoid letters since it's not very important. > Alternatively to '[--]' I could make it look down '[..]' or maybe even > without eyes entirely '[ ]'. Yeah, anything but [--]. The version with the dots is nice. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote: > > > > > > On Tue, 28 Sep 2021, Michał Górny wrote: > > > The proposed new format distinguished message types both using > > colors > > and strings. This is roughly inspired by Xorg logs. > > Using the same markers as Xorg (especially [--]) but with different > meaning may be confusing though. Xorg has these: > > Markers: (--) probed, (**) from config file, (==) default setting, > (++) from command line, (!!) notice, (II) informational, > (WW) warning, (EE) error, (NI) not implemented, (??) unknown. > > So, maybe change einfo from [--] to [II]? Nah, the whole point is to avoid letters since it's not very important. Alternatively to '[--]' I could make it look down '[..]' or maybe even without eyes entirely '[ ]'. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
> On Tue, 28 Sep 2021, Michał Górny wrote: > The proposed new format distinguished message types both using colors > and strings. This is roughly inspired by Xorg logs. Using the same markers as Xorg (especially [--]) but with different meaning may be confusing though. Xorg has these: Markers: (--) probed, (**) from config file, (==) default setting, (++) from command line, (!!) notice, (II) informational, (WW) warning, (EE) error, (NI) not implemented, (??) unknown. So, maybe change einfo from [--] to [II]? signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
I love it - this is similar to the xorg log output, and i think it makes the portage output much cleaner and easier to read. El mar., 28 de septiembre de 2021 11:36 a. m., Michał Górny < mgo...@gentoo.org> escribió: > Hi, everyone. > > I know I'm going to regret asking this... but I've prepared a change to > the Portage output format and I think it asks for a wider discussion > than internally in Portage team. > > The primary problem with the current output format is that different > kinds of messages differ only in color. This makes them > indistinguishable without colors and hard to grep. ago's been asking > for a better way to grep for QA warnings and this is pretty much what > motivated me to do this. > > The proposed new format distinguished message types both using colors > and strings. This is roughly inspired by Xorg logs. For example, > instead of: > > * some message > * other message > * hell if i know what this is > > You get: > > [WW] some message > [EE] other message > [QA] hell if i know what this is > > I've also added more colors to explicitly distinguish einfo from elog, > and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' > used by Portage with four-character versions to keep messages aligned. > The 'zings' used for merging files remain three-character, so now it's > easily possible to distinguish messages from installed file list. > > The PR doing this is: https://github.com/gentoo/portage/pull/759 > > Example screenshot: > > https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png > > -- > Best regards, > Michał Górny > > > >
[gentoo-dev] [RFC] Portage einfo, elog... output format change
Hi, everyone. I know I'm going to regret asking this... but I've prepared a change to the Portage output format and I think it asks for a wider discussion than internally in Portage team. The primary problem with the current output format is that different kinds of messages differ only in color. This makes them indistinguishable without colors and hard to grep. ago's been asking for a better way to grep for QA warnings and this is pretty much what motivated me to do this. The proposed new format distinguished message types both using colors and strings. This is roughly inspired by Xorg logs. For example, instead of: * some message * other message * hell if i know what this is You get: [WW] some message [EE] other message [QA] hell if i know what this is I've also added more colors to explicitly distinguish einfo from elog, and ewarn from eqawarn. Then, I've replaced most of '>>>' and '!!!' used by Portage with four-character versions to keep messages aligned. The 'zings' used for merging files remain three-character, so now it's easily possible to distinguish messages from installed file list. The PR doing this is: https://github.com/gentoo/portage/pull/759 Example screenshot: https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png -- Best regards, Michał Górny
Re: [gentoo-dev] Guidance on adding kernel config checks to ebuilds
On Mon, 2021-09-27 at 15:44 -0400, Mike Gilbert wrote: > On Mon, Sep 27, 2021 at 3:11 PM Peter Stuge wrote: > > > > Mike Gilbert wrote: > > > It's a waste of time and effort to pepper random ebuilds with checks > > > for options that everyone should have enabled in the first place. > > > > It's not for you to say what everyone should have enabled in their kernel. > > Do you not agree that there are some options that should always be > enabled, or at least that we can assume are enabled? > There is a distro/Kconfig in gentoo-sources with, config GENTOO_LINUX bool "Gentoo Linux support" ... that could be extended to include a set of assumed features; otherwise a sub-setting (default enabled) could be added.
