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: dev-libs/openssl USE=bindist removal
> On 27 Sep 2021, at 23:50, Robin H. Johnson wrote: > > Deadline for responses: 2021/10/14! > > The Foundation would like to propose that RedHat/Fedora "hobble" patch > presently applied when USE=bindist is true shall be removed from > dev-libs/openssl. > > RedHat's stated reasons for the patch were originally to avoid any patent > concerns, but they have also morphed over time to present some "insecure" > things from being used entirely: > https://access.redhat.com/documentation/en-us/red_hat_enterprise_linux/8/html/security_hardening/using-the-system-wide-cryptographic-policies_security-hardening > "All ECC curves < 224 bits (since RHEL 6)" > "All binary field ECC curves (since RHEL 6)" > > However, the Foundation would also like to be sure that no users feel that > patchset provides something critical to their usage of Gentoo. > > If nobody speaks up as saying that the "hobble" patch is REQUIRED for their > use > cases, the Foundation proposes that usage of the patchset be dropped from the > main tree. > > Any users who might be concerned about patent compliance are encouraged to do > their own due diligence, as OpenSSL was the only Gentoo package that shipped > this type of patch, and even Fedora's upstream did not completely patch out EC > in other packages. > > [snip] Thanks for this. You've ended up addressing the comments & concerns I raised the other day on the (slightly derailed) other thread [0]. There's a PR on this on GitHub too [1] to handle the removal. As I suspect was already clear, I support this move in the absence of new information (which I suspect will not be forthcoming). [0] https://archives.gentoo.org/gentoo-dev/message/99551035af66db79f60c6bd8ef7138a8 [1] https://github.com/gentoo/gentoo/pull/18894 best, sam signature.asc Description: Message signed with OpenPGP
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
