Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Mon, Oct 4, 2021 at 2:48 AM Michał Górny wrote: > > On Tue, 2021-09-28 at 17:36 +0200, Michał Górny wrote: > > 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. > > As I suspected, I truly regret sending this mail. I'm dangerously close > to burning out, so I'm going to retract these patches. When you decide > what you want and make patches for it, feel free to send them to > Portage. Keep in mind that while distributing patches and soliciting comments is a good practice, I don't believe any of our policies REQUIRE that you: 1. Reply to anybody who comments. 2. Address any comments. 3. Wait until anybody (let alone everybody) agrees before proceeding. I think that we sometimes let the requirement to communicate somehow stifle the desire to get things done. While I don't recommend it, you can technically satisfy any communications requirements by posting your patch and literally never checking your email before committing it. Obviously if you mess something up in doing so you'll look dumb, but it isn't intended to be a bureaucratic requirement. I suggest just skimming the comments to see if there is anything that seems like a good idea, then implementing those ideas (which you'll probably want to do anyway), and ignore the rest without comment. If somebody has a problem with what you're doing, the onus is on them to go find somebody to complain to in order to stop you. If you're the maintainer then you don't need permission to commit. In my experience the Council is fairly resistant to requests to meddle for things that aren't super-critical, so I'd be shocked if they didn't just ack and dismiss any request to bikeshed exactly what prefix your elog output uses. Open to contrary opinions, but IMO I think maintainers perceive that the distro is more consensus-driven than it actually is. You don't have to "win" the email battle. -- Rich
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 10/2/21 10:51 AM, Mike Gilbert wrote: > On Sat, Oct 2, 2021 at 1:25 PM A Schenck wrote: >> Further discussion belongs on a different list, but the link provided by >> mgorny and repeated by you does not allow collaborating in compliance >> with the Gentoo Social Contract. > The patches were also posted for review on the gentoo-portage-dev mailing > list. Thanks. The patch is a bit messier than hoped but it's a starting point. OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 05-10-2021 09:35:32 +0200, Michał Górny wrote: > On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote: > > > > Final question, am I understanding correctly that normal lines are not > > > > prefixed with something? Would it be, for consistency, alignment, and > > > > certainty of selecting rows something to use a prefix for those lines > > > > too (assuming they aren't at this point)? > > > > > > I don't know, we've never done that. I suppose it would be possible but > > > it is even more controversial and unlike the proposed changes, it would > > > actually require mangling the process output. > > > > If I remember correctly, Portage already does. In which case, doing > > this (even if it were adding leading spaces) would not be that much > > work? > > > > I'm afraid this is not that simple. You need to account for all escape > sequences that can affect editing already output data including clean > handling of line wrapping. In the end, we'd have to have a complete > detachtty-class terminal emulator inside Portage. Fair enough, thanks for looking into it. Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Thu, 2021-09-30 at 09:18 +0200, Fabian Groffen wrote: > > > Final question, am I understanding correctly that normal lines are not > > > prefixed with something? Would it be, for consistency, alignment, and > > > certainty of selecting rows something to use a prefix for those lines > > > too (assuming they aren't at this point)? > > > > I don't know, we've never done that. I suppose it would be possible but > > it is even more controversial and unlike the proposed changes, it would > > actually require mangling the process output. > > If I remember correctly, Portage already does. In which case, doing > this (even if it were adding leading spaces) would not be that much > work? > I'm afraid this is not that simple. You need to account for all escape sequences that can affect editing already output data including clean handling of line wrapping. In the end, we'd have to have a complete detachtty-class terminal emulator inside Portage. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Tue, 2021-09-28 at 17:36 +0200, Michał Górny wrote: > 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. As I suspected, I truly regret sending this mail. I'm dangerously close to burning out, so I'm going to retract these patches. When you decide what you want and make patches for it, feel free to send them to Portage. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
03.10.2021 07:58, Fabian Groffen пишет: > > FWIW, I like this one. Perhaps even with lowercase > > make[4]: leaving directory src > q* soname lacks version > e* failed to die > For me this reads as some kind of censorship to remove profanities from the output; and my mind is trying to reconstruct what profanity it was... -- Best regards, Alexey "DarthGandalf" Sokolov
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sun, Oct 03, 2021 at 08:58:00AM +0200, Fabian Groffen wrote: > On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote: > > On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote: > > > Guess there's a lot of other options that could be considered as well. > > > > > > --- files > > > >>> text > > > * current, it wasn't aligned now that I look at it again > > > (relying only on color to convey type feels clearly wrong to me) > > > > > > --- files > > > text > > > [QA] new based on current PR > > > > > > >>> text > > > [QA] aligned 1 character further, maybe skipping changing >>> is fine? > > > (then again that it's further is what threw me off at first) > > > > > > >>> text > > > QA* similar to before, but aligned using only 3 chars > > > > > > >>> text > > > [Q] kinda more obscure but it can work > > > > > > > Guess should also add these: > > >>> text > > Q* Notice: > > E* Some error happened > > (closest to before by making use of the former leading space, thus > > no alignment changes) > > FWIW, I like this one. Perhaps even with lowercase > > make[4]: leaving directory src > q* soname lacks version > e* failed to die Also I guess it provides some degree of compatibility with external scripts/tools that adopted the ` * ` format to copy portage. i.e. could actually keep ` * ` for einfo, no need for `.* ` here. Lowercase might be a good idea too, albeit I'm still undecided on what I like best in general. > > Fabian > > > > > >>> text > > QA Notice: > > EE Some error happened > > (at least clearer than Q* Notice, but unsure about no separator.. guess > > it could work?) > > > > > text > > > QA* probably closest to how it was before alignment-wise, but meh at 4 > > > > > > > >>> message > > > QA> not convinced about this one, but throwing it here anyway > > > (other characters could be considered as well) > > > > > > Maybe a poll of some kind may help, personally undecided on what I > > > like better beside agreeing that a change is needed. > > > > > > -- > > ionen > > > > -- > Fabian Groffen > Gentoo on a different level -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 02-10-2021 23:03:56 -0400, Ionen Wolkens wrote: > On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote: > > Guess there's a lot of other options that could be considered as well. > > > > --- files > > >>> text > > * current, it wasn't aligned now that I look at it again > > (relying only on color to convey type feels clearly wrong to me) > > > > --- files > > text > > [QA] new based on current PR > > > > >>> text > > [QA] aligned 1 character further, maybe skipping changing >>> is fine? > > (then again that it's further is what threw me off at first) > > > > >>> text > > QA* similar to before, but aligned using only 3 chars > > > > >>> text > > [Q] kinda more obscure but it can work > > > > Guess should also add these: > >>> text > Q* Notice: > E* Some error happened > (closest to before by making use of the former leading space, thus > no alignment changes) FWIW, I like this one. Perhaps even with lowercase make[4]: leaving directory src q* soname lacks version e* failed to die Fabian > > >>> text > QA Notice: > EE Some error happened > (at least clearer than Q* Notice, but unsure about no separator.. guess > it could work?) > > > text > > QA* probably closest to how it was before alignment-wise, but meh at 4 > > > > > >>> message > > QA> not convinced about this one, but throwing it here anyway > > (other characters could be considered as well) > > > > Maybe a poll of some kind may help, personally undecided on what I > > like better beside agreeing that a change is needed. > > > -- > ionen -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 10:53:37PM -0400, Ionen Wolkens wrote: > Guess there's a lot of other options that could be considered as well. > > --- files > >>> text > * current, it wasn't aligned now that I look at it again > (relying only on color to convey type feels clearly wrong to me) > > --- files > text > [QA] new based on current PR > > >>> text > [QA] aligned 1 character further, maybe skipping changing >>> is fine? > (then again that it's further is what threw me off at first) > > >>> text > QA* similar to before, but aligned using only 3 chars > > >>> text > [Q] kinda more obscure but it can work > Guess should also add these: >>> text Q* Notice: E* Some error happened (closest to before by making use of the former leading space, thus no alignment changes) >>> text QA Notice: EE Some error happened (at least clearer than Q* Notice, but unsure about no separator.. guess it could work?) > text > QA* probably closest to how it was before alignment-wise, but meh at 4 > > > >>> message > QA> not convinced about this one, but throwing it here anyway > (other characters could be considered as well) > > Maybe a poll of some kind may help, personally undecided on what I > like better beside agreeing that a change is needed. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 06:04:36PM -0400, Ionen Wolkens wrote: > On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote: > > > On Wed, 29 Sep 2021, A Schenck wrote: > > > > > On 9/28/21 8:36 AM, Michał Górny wrote: > > >> [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. > > > > > Didn't expect to be the only dissenting opinion on something like this > > > but. . . Some applications parse portage output looking for these > > > 'zings'. At very least app-portage/kuroo does it this way; there must be > > > others, right? This is obviously not the ideal way to get information > > > out of portage, but it's been stable for the 15 years Kuroo has existed. > > > 10-ish years ago dol-sen started some work on building and API for > > > portage, but then got sucked into core portage development to the point > > > of abandoning their GTK+ portage GUI porthole, which was the original > > > impetus for an API, and as far as we know, the API never made it to the > > > point it could replace parsing the output. > > > > If only the length of the >>> and !!! strings is a problem, then why not > > leave them alone and go for single-letter tags instead? Like this: > > > >[.] einfo > >[I] elog > >[W] ewarn > >[E] eerror > >[Q] eqawarn > > > > The only problematic one is [Q] instead of [QA] which is no longer > > self-explanatory. Then again, only devs and experienced users should see > > eqawarn messages. > > fwiw eqawarn is currently displayed for everyone in a similar manner > as einfo, just not post-emerge/elog without adding to ELOG classes. > > If users aren't hiding build logs entirely, they may notice those > done at the end (often shown after size report) -- and possibly > think it's a problem. > > Not to say whether [Q] vs [QA] would help with this much so I have > no strong opinion here. Guess there's a lot of other options that could be considered as well. --- files >>> text * current, it wasn't aligned now that I look at it again (relying only on color to convey type feels clearly wrong to me) --- files text [QA] new based on current PR >>> text [QA] aligned 1 character further, maybe skipping changing >>> is fine? (then again that it's further is what threw me off at first) >>> text QA* similar to before, but aligned using only 3 chars >>> text [Q] kinda more obscure but it can work text QA* probably closest to how it was before alignment-wise, but meh at 4 > >>> message QA> not convinced about this one, but throwing it here anyway (other characters could be considered as well) Maybe a poll of some kind may help, personally undecided on what I like better beside agreeing that a change is needed. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 02, 2021 at 09:22:49AM +0200, Ulrich Mueller wrote: > > On Wed, 29 Sep 2021, A Schenck wrote: > > > On 9/28/21 8:36 AM, Michał Górny wrote: > >> [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. > > > Didn't expect to be the only dissenting opinion on something like this > > but. . . Some applications parse portage output looking for these > > 'zings'. At very least app-portage/kuroo does it this way; there must be > > others, right? This is obviously not the ideal way to get information > > out of portage, but it's been stable for the 15 years Kuroo has existed. > > 10-ish years ago dol-sen started some work on building and API for > > portage, but then got sucked into core portage development to the point > > of abandoning their GTK+ portage GUI porthole, which was the original > > impetus for an API, and as far as we know, the API never made it to the > > point it could replace parsing the output. > > If only the length of the >>> and !!! strings is a problem, then why not > leave them alone and go for single-letter tags instead? Like this: > >[.] einfo >[I] elog >[W] ewarn >[E] eerror >[Q] eqawarn > > The only problematic one is [Q] instead of [QA] which is no longer > self-explanatory. Then again, only devs and experienced users should see > eqawarn messages. fwiw eqawarn is currently displayed for everyone in a similar manner as einfo, just not post-emerge/elog without adding to ELOG classes. If users aren't hiding build logs entirely, they may notice those done at the end (often shown after size report) -- and possibly think it's a problem. Not to say whether [Q] vs [QA] would help with this much so I have no strong opinion here. -- ionen signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Sat, Oct 2, 2021 at 1:25 PM A Schenck wrote: > Further discussion belongs on a different list, but the link provided by > mgorny and repeated by you does not allow collaborating in compliance > with the Gentoo Social Contract. The patches were also posted for review on the gentoo-portage-dev mailing list.
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 10/1/21 11:32 AM, Alec Warner wrote: > On Fri, Oct 1, 2021 at 11:30 AM A Schenck wrote: >> On 9/29/21 11:44 PM, Michał Górny wrote: >>> On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: Hi, Would it be possible to have some switch (e.g. --style=legacy) that controls this new vs. the old behaviour? Would perhaps allow applications that parse the output to work via setting this in the global opts. >>> Patches welcome. It shouldn't be hard, my commit shows which files need >>> to be edited to alter the prefixes and how to pass them into ebd. >> Would it be possible to get this patch in an format that it can be >> interacted with with open tools? Per the other branch of this thread, >> we'd be happy to make this an opt-in so as to not break existing people. > I'm not sure what you mean; you can download the PR... > > https://github.com/gentoo/portage/pull/759 > > -A This isn't really the place to rehash the whole discussion of free speech vs. free beer: http://www.gnu.org/philosophy/free-sw-en.html . Suffice to say the Gentoo Social Contract (https://www.gentoo.org/get-started/philosophy/social-contract.html#gentoo-is-and-will-remain-free-software) states: "Gentoo will never depend upon a piece of software or metadata unless it conforms to the GNU General Public License, the GNU Lesser General Public License, the Creative Commons - Attribution/Share Alike or some other license approved by the Open Source Initiative"; which GitHub does not conform to: https://www.gnu.org/software/repo-criteria-evaluation.html#GitHub . Further reading (linked from gnu.org) at https://sanctum.geek.nz/why-not-github.html , and of course we all know that Microsoft acquired GitHub, and of course Microsoft has a history of suing Free / Libre / Open Source Software creators and users. Further discussion belongs on a different list, but the link provided by mgorny and repeated by you does not allow collaborating in compliance with the Gentoo Social Contract. -A >> -A >> >> OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
> On Wed, 29 Sep 2021, A Schenck wrote: > On 9/28/21 8:36 AM, Michał Górny wrote: >> [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. > Didn't expect to be the only dissenting opinion on something like this > but. . . Some applications parse portage output looking for these > 'zings'. At very least app-portage/kuroo does it this way; there must be > others, right? This is obviously not the ideal way to get information > out of portage, but it's been stable for the 15 years Kuroo has existed. > 10-ish years ago dol-sen started some work on building and API for > portage, but then got sucked into core portage development to the point > of abandoning their GTK+ portage GUI porthole, which was the original > impetus for an API, and as far as we know, the API never made it to the > point it could replace parsing the output. If only the length of the >>> and !!! strings is a problem, then why not leave them alone and go for single-letter tags instead? Like this: [.] einfo [I] elog [W] ewarn [E] eerror [Q] eqawarn The only problematic one is [Q] instead of [QA] which is no longer self-explanatory. Then again, only devs and experienced users should see eqawarn messages. Ulrich signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Fri, 2021-10-01 at 18:00 -0400, Joshua Kinard wrote: > On 9/30/2021 02:40, Fabian Groffen wrote: > > Hi, > > > > Would it be possible to have some switch (e.g. --style=legacy) that > > controls this new vs. the old behaviour? Would perhaps allow > > applications that parse the output to work via setting this in the > > global opts. > > Perhaps this would be better as a FEATURE flag? E.g., 'legacy-output' or > something similar? > No. FEATURES is just a horrible historical mistake. Proper configuration uses separate keys for separate options. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 9/29/21 3:58 PM, Francesco Riosa wrote: > Il giorno mer 29 set 2021 alle ore 23:52 A Schenck > mailto:lane_and...@hotmail.com>> ha scritto: > > On 9/28/21 8:36 AM, Michał Górny wrote: > > 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. > > Didn't expect to be the only dissenting opinion on something like this > but. . . Some applications parse portage output looking for these > 'zings'. At very least app-portage/kuroo does it this way; there > must be > others, right? This is obviously not the ideal way to get information > out of portage, but it's been stable for the 15 years Kuroo has > existed. > 10-ish years ago dol-sen started some work on building and API for > portage, but then got sucked into core portage development to the > point > of abandoning their GTK+ portage GUI porthole, which was the original > impetus for an API, and as far as we know, the API never made it > to the > point it could replace parsing the output. > > It wouldn't be worth blocking progress for one application that > not many > people use, but assuming there are others that will also break > with this > change. Are we sure there's no way to support ago's (very > valuable) work > without breaking other things? > > -A > > > Kuroo is already a quite complex application that parse portage > output. A quick grep seems to show that changes needed are quite > manageable. > Also the parsing should be more accurate with proposed changes. > Rather it should be easy for the application to know in advance which > format the output will be. > There is also the opportunity to have a flag that enable (or disable) > the augmented output, but IMHO this should be done only if the added > complexity is NIL > > $ grep -c -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1 | grep > -v :0$ > kuroo-1.2.1/TODO:1 > kuroo-1.2.1/src/history/history.cpp:3 > kuroo-1.2.1/src/config/configdialog.h:2 > kuroo-1.2.1/src/queue/queuelistview.cpp:1 > kuroo-1.2.1/src/core/scanupdatesjob.cpp:1 > kuroo-1.2.1/src/core/global.h:2 > kuroo-1.2.1/src/core/packageinspector.cpp:4 > kuroo-1.2.1/src/core/packageversion.h:2 > kuroo-1.2.1/src/core/etcupdate.h:1 > kuroo-1.2.1/src/core/portagedb.cpp:2 > kuroo-1.2.1/src/core/scanhistoryjob.cpp:3 > kuroo-1.2.1/src/core/global.cpp:1 > kuroo-1.2.1/src/core/dependatom.h:2 > kuroo-1.2.1/src/core/emerge.cpp:8 > Alas and alack, just searching for regular expressions isn't enough, there are places that use QString::startsWith and contains and mid, with literal QStrings. Tthere might be "spooky action at a distance" in some fifteen year old code that used some esoteric method to parse output because it was hip like -funroll-loops, and that could takes years to track down and fix despite best efforts to fix all the obvious QReg(|ular)Ex(|pression)s. If the idea is to clean up old code that admins haven't looked at in years because it "just worked"™, that's valid too; treecleaner project is laudable for that. But if breaking things isn't the goal, then we should consider if there are options to keep things working. Regarding "added complexity": it would probably mean parsing one additional optional command line argument or make.conf / environment variable, then initialize format strings in elog/messages.py or output.py or something. It would be a lot easier to figure out how if the patch was available on free infrastructure rather than just looking randomly at portage code. > > > > > > > > The PR doing this is: https://github.com/gentoo/portage/pull/759 >
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 9/30/2021 02:40, Fabian Groffen wrote: > Hi, > > Would it be possible to have some switch (e.g. --style=legacy) that > controls this new vs. the old behaviour? Would perhaps allow > applications that parse the output to work via setting this in the > global opts. Perhaps this would be better as a FEATURE flag? E.g., 'legacy-output' or something similar? > In addition, much like the colour map, how do you see this change in > light of eclasses, init-scripts, etc. that also use the same scheme as > Portage at the moment? Would you expect to change those too at some > point? > > Final question, am I understanding correctly that normal lines are not > prefixed with something? Would it be, for consistency, alignment, and > certainty of selecting rows something to use a prefix for those lines > too (assuming they aren't at this point)? > > Thanks, > Fabian -- Joshua Kinard Gentoo/MIPS ku...@gentoo.org rsa6144/5C63F4E3F5C6C943 2015-04-27 177C 1972 1FB8 F254 BAD0 3E72 5C63 F4E3 F5C6 C943 "The past tempts us, the present confuses us, the future frightens us. And our lives slip away, moment by moment, lost in that vast, terrible in-between." --Emperor Turhan, Centauri Republic
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Fri, Oct 1, 2021 at 11:30 AM A Schenck wrote: > > On 9/29/21 11:44 PM, Michał Górny wrote: > > On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: > >> Hi, > >> > >> Would it be possible to have some switch (e.g. --style=legacy) that > >> controls this new vs. the old behaviour? Would perhaps allow > >> applications that parse the output to work via setting this in the > >> global opts. > > Patches welcome. It shouldn't be hard, my commit shows which files need > > to be edited to alter the prefixes and how to pass them into ebd. > > Would it be possible to get this patch in an format that it can be > interacted with with open tools? Per the other branch of this thread, > we'd be happy to make this an opt-in so as to not break existing people. I'm not sure what you mean; you can download the PR... https://github.com/gentoo/portage/pull/759 -A > > -A > >
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 9/29/21 11:44 PM, Michał Górny wrote: > On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: >> Hi, >> >> Would it be possible to have some switch (e.g. --style=legacy) that >> controls this new vs. the old behaviour? Would perhaps allow >> applications that parse the output to work via setting this in the >> global opts. > Patches welcome. It shouldn't be hard, my commit shows which files need > to be edited to alter the prefixes and how to pass them into ebd. Would it be possible to get this patch in an format that it can be interacted with with open tools? Per the other branch of this thread, we'd be happy to make this an opt-in so as to not break existing people. -A OpenPGP_signature Description: OpenPGP digital signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 30-09-2021 08:44:33 +0200, Michał Górny wrote: > On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: > > Hi, > > > > Would it be possible to have some switch (e.g. --style=legacy) that > > controls this new vs. the old behaviour? Would perhaps allow > > applications that parse the output to work via setting this in the > > global opts. > > Patches welcome. It shouldn't be hard, my commit shows which files need > to be edited to alter the prefixes and how to pass them into ebd. I see. > > In addition, much like the colour map, how do you see this change in > > light of eclasses, init-scripts, etc. that also use the same scheme as > > Portage at the moment? Would you expect to change those too at some > > point? > > Eclasses are supposed to use standard einfo, elog... functions, so they > should just work™. If someone's reinventing the wheel, it's not my > problem. > > Init scripts aren't supposed to be used inside the PM, so that's out of > scope. I was just referring to the overall "feel" of Gentoo, which your work changes. It is ok that you don't plan on doing anything there. > > Final question, am I understanding correctly that normal lines are not > > prefixed with something? Would it be, for consistency, alignment, and > > certainty of selecting rows something to use a prefix for those lines > > too (assuming they aren't at this point)? > > I don't know, we've never done that. I suppose it would be possible but > it is even more controversial and unlike the proposed changes, it would > actually require mangling the process output. If I remember correctly, Portage already does. In which case, doing this (even if it were adding leading spaces) would not be that much work? Thanks, Fabian -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote: > Hi, > > Would it be possible to have some switch (e.g. --style=legacy) that > controls this new vs. the old behaviour? Would perhaps allow > applications that parse the output to work via setting this in the > global opts. Patches welcome. It shouldn't be hard, my commit shows which files need to be edited to alter the prefixes and how to pass them into ebd. > > In addition, much like the colour map, how do you see this change in > light of eclasses, init-scripts, etc. that also use the same scheme as > Portage at the moment? Would you expect to change those too at some > point? Eclasses are supposed to use standard einfo, elog... functions, so they should just work™. If someone's reinventing the wheel, it's not my problem. Init scripts aren't supposed to be used inside the PM, so that's out of scope. > Final question, am I understanding correctly that normal lines are not > prefixed with something? Would it be, for consistency, alignment, and > certainty of selecting rows something to use a prefix for those lines > too (assuming they aren't at this point)? I don't know, we've never done that. I suppose it would be possible but it is even more controversial and unlike the proposed changes, it would actually require mangling the process output. -- Best regards, Michał Górny
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
Hi, Would it be possible to have some switch (e.g. --style=legacy) that controls this new vs. the old behaviour? Would perhaps allow applications that parse the output to work via setting this in the global opts. In addition, much like the colour map, how do you see this change in light of eclasses, init-scripts, etc. that also use the same scheme as Portage at the moment? Would you expect to change those too at some point? Final question, am I understanding correctly that normal lines are not prefixed with something? Would it be, for consistency, alignment, and certainty of selecting rows something to use a prefix for those lines too (assuming they aren't at this point)? Thanks, Fabian On 28-09-2021 17:36:25 +0200, Michał Górny wrote: > 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 > > > -- Fabian Groffen Gentoo on a different level signature.asc Description: PGP signature
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
> On 29 Sep 2021, at 22:52, A Schenck wrote: > > [snip] > Didn't expect to be the only dissenting opinion on something like this > but. . . Some applications parse portage output looking for these > 'zings'. At very least app-portage/kuroo does it this way; there must be > others, right? This is obviously not the ideal way to get information > out of portage, but it's been stable for the 15 years Kuroo has existed. > 10-ish years ago dol-sen started some work on building and API for > portage, but then got sucked into core portage development to the point > of abandoning their GTK+ portage GUI porthole, which was the original > impetus for an API, and as far as we know, the API never made it to the > point it could replace parsing the output. > Valid point, and I wish that we could get more useful information out of Portage with easy APIs. > It wouldn't be worth blocking progress for one application that not many > people use, but assuming there are others that will also break with this > change. Are we sure there's no way to support ago's (very valuable) work > without breaking other things? Note that this isn't just for ago's purposes. One, it makes it easier to generally grep or parse portage output, but also (very importantly), it makes Portage's output more _accessible_. Right now, Portage is *way* too reliant on colour, which isn't very helpful for colourblind or eyesight impaired users/developers. > -A > >> >> 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, sam signature.asc Description: Message signed with OpenPGP
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
Il giorno mer 29 set 2021 alle ore 23:52 A Schenck ha scritto: > On 9/28/21 8:36 AM, Michał Górny wrote: > > 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. > > Didn't expect to be the only dissenting opinion on something like this > but. . . Some applications parse portage output looking for these > 'zings'. At very least app-portage/kuroo does it this way; there must be > others, right? This is obviously not the ideal way to get information > out of portage, but it's been stable for the 15 years Kuroo has existed. > 10-ish years ago dol-sen started some work on building and API for > portage, but then got sucked into core portage development to the point > of abandoning their GTK+ portage GUI porthole, which was the original > impetus for an API, and as far as we know, the API never made it to the > point it could replace parsing the output. > > It wouldn't be worth blocking progress for one application that not many > people use, but assuming there are others that will also break with this > change. Are we sure there's no way to support ago's (very valuable) work > without breaking other things? > > -A > Kuroo is already a quite complex application that parse portage output. A quick grep seems to show that changes needed are quite manageable. Also the parsing should be more accurate with proposed changes. Rather it should be easy for the application to know in advance which format the output will be. There is also the opportunity to have a flag that enable (or disable) the augmented output, but IMHO this should be done only if the added complexity is NIL $ grep -c -Ers 'QRegExp |QregularExpression ' -i kuroo-1.2.1 | grep -v :0$ kuroo-1.2.1/TODO:1 kuroo-1.2.1/src/history/history.cpp:3 kuroo-1.2.1/src/config/configdialog.h:2 kuroo-1.2.1/src/queue/queuelistview.cpp:1 kuroo-1.2.1/src/core/scanupdatesjob.cpp:1 kuroo-1.2.1/src/core/global.h:2 kuroo-1.2.1/src/core/packageinspector.cpp:4 kuroo-1.2.1/src/core/packageversion.h:2 kuroo-1.2.1/src/core/etcupdate.h:1 kuroo-1.2.1/src/core/portagedb.cpp:2 kuroo-1.2.1/src/core/scanhistoryjob.cpp:3 kuroo-1.2.1/src/core/global.cpp:1 kuroo-1.2.1/src/core/dependatom.h:2 kuroo-1.2.1/src/core/emerge.cpp:8 > > > > > 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 > > > >
Re: [gentoo-dev] [RFC] Portage einfo, elog... output format change
On 9/28/21 8:36 AM, Michał Górny wrote: > 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. Didn't expect to be the only dissenting opinion on something like this but. . . Some applications parse portage output looking for these 'zings'. At very least app-portage/kuroo does it this way; there must be others, right? This is obviously not the ideal way to get information out of portage, but it's been stable for the 15 years Kuroo has existed. 10-ish years ago dol-sen started some work on building and API for portage, but then got sucked into core portage development to the point of abandoning their GTK+ portage GUI porthole, which was the original impetus for an API, and as far as we know, the API never made it to the point it could replace parsing the output. It wouldn't be worth blocking progress for one application that not many people use, but assuming there are others that will also break with this change. Are we sure there's no way to support ago's (very valuable) work without breaking other things? -A > > 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 > OpenPGP_signature Description: OpenPGP digital signature
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
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
