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
<br>
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.
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]?
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 '[ ]'.
On Tue, 2021-09-28 at 18:26 +0200, Ulrich Mueller wrote:On Tue, 28 Sep 2021, Michał Górny 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.
or maybe even without eyes entirely '[ ]'.
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
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
On 29 Sep 2021, at 22:52, A Schenck <lane_andrew@hotmail.com> 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.
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
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
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)?
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.
On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
Hi,Patches welcome. It shouldn't be hard, my commit shows which files need
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.
to be edited to alter the prefixes and how to pass them into ebd.
On 9/29/21 11:44 PM, Michał Górny wrote:
On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:
Hi,Patches welcome. It shouldn't be hard, my commit shows which files need
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.
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
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
Il giorno mer 29 set 2021 alle ore 23:52 A Schenck
<lane_andrew@hotmail.com <mailto:lane_andrew@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
Â
>
> The PR doing this is: https://github.com/gentoo/portage/pull/759
<https://github.com/gentoo/portage/pull/759>
>
> Example screenshot:
>
https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png
<https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png>
>
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?
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.
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.
On Fri, Oct 1, 2021 at 11:30 AM A Schenck <lane_andrew@hotmail.com> wrote:
On 9/29/21 11:44 PM, Michał Górny wrote:I'm not sure what you mean; you can download the PR...
On Thu, 2021-09-30 at 08:40 +0200, Fabian Groffen wrote:Would it be possible to get this patch in an format that it can be
Hi,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 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.
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.
https://github.com/gentoo/portage/pull/759
-A
-A
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.
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.
* current, it wasn't aligned now that I look at it againtext
[QA] new based on current PRtext
[QA] aligned 1 character further, maybe skipping changing >>> is fine?text
QA* similar to before, but aligned using only 3 charstext
[Q] kinda more obscure but it can worktext
QA* probably closest to how it was before alignment-wise, but meh at 4 >text
(other characters could be considered as well)not convinced about this one, but throwing it here anywaymessage
Guess there's a lot of other options that could be considered as well.
--- files
* current, it wasn't aligned now that I look at it againtext
(relying only on color to convey type feels clearly wrong to me)
--- files
[QA] new based on current PRtext
[QA] aligned 1 character further, maybe skipping changing >>> is fine?text
(then again that it's further is what threw me off at first)
QA* similar to before, but aligned using only 3 charstext
[Q] kinda more obscure but it can worktext
Q* Notice:text
QA Notice:text
QA* probably closest to how it was before alignment-wise, but meh at 4 >text
(other characters could be considered as well)not convinced about this one, but throwing it here anywaymessage
Maybe a poll of some kind may help, personally undecided on what I
like better beside agreeing that a change is needed.
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
* current, it wasn't aligned now that I look at it againtext
(relying only on color to convey type feels clearly wrong to me)
--- files
[QA] new based on current PRtext
[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 charstext
[Q] kinda more obscure but it can worktext
Guess should also add these:
Q* Notice:text
E* Some error happened
(closest to before by making use of the former leading space, thus
no alignment changes)
QA Notice:text
EE Some error happened
(at least clearer than Q* Notice, but unsure about no separator.. guess
it could work?)
QA* probably closest to how it was before alignment-wise, but meh at 4 >text
(other characters could be considered as well)not convinced about this one, but throwing it here anywaymessage
Maybe a poll of some kind may help, personally undecided on what I
like better beside agreeing that a change is needed.
--
ionen
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
* current, it wasn't aligned now that I look at it againtext
(relying only on color to convey type feels clearly wrong to me)
--- files
[QA] new based on current PRtext
[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 charstext
[Q] kinda more obscure but it can worktext
Guess should also add these:
Q* Notice:text
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
QA Notice:text
EE Some error happened
(at least clearer than Q* Notice, but unsure about no separator.. guess
it could work?)
QA* probably closest to how it was before alignment-wise, but meh at 4 >text
(other characters could be considered as well)not convinced about this one, but throwing it here anywaymessage
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
FWIW, I like this one. Perhaps even with lowercase
make[4]: leaving directory src
q* soname lacks version
e* failed to die
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.
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.
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?
On Sat, Oct 2, 2021 at 1:25 PM A Schenck <lane_andrew@hotmail.com> wrote:Thanks. The patch is a bit messier than hoped but it's a starting point.
Further discussion belongs on a different list, but the link provided byThe patches were also posted for review on the gentoo-portage-dev mailing list.
mgorny and repeated by you does not allow collaborating in compliance
with the Gentoo Social Contract.
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.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 296 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 33:06:15 |
| Calls: | 6,648 |
| Calls today: | 3 |
| Files: | 12,193 |
| Messages: | 5,328,703 |
![https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png"](https://user-images.githubusercontent.com/110765/135119090-16e9599d-1b0f-41b8-a965-a55577183ffd.png"){kind=link}
