Re: [gentoo-dev] Re: RFC: intel-sdp-r1.eclass
Dnia 17 lutego 2016 11:53:32 CET, Duncan <1i5t5.dun...@cox.net> napisał(a): >Michał Górny posted on Wed, 17 Feb 2016 07:47:06 +0100 as excerpted: > >> On Tue, 16 Feb 2016 22:48:08 -0600 Ryan Hill >wrote: >> >>> On Mon, 15 Feb 2016 15:35:12 +0100 Michał Górny >>> wrote: >>> > On Mon, 15 Feb 2016 14:37:41 +0100 "Justin Lecher (jlec)" >>> > wrote: >>> > > On 15/02/16 13:59, Michał Górny wrote: > >>> > > > Don't mix echo with ewarn. >>> > > Why? >>> > Because they won't go through the same output channels. >>> >>> That's kinda the point. You want a blank (unstarred) space to >separate >>> out the "important" messages from the generic spew put out by the >>> package manager/eclasses/build system that you have no control over. >> >> This is not just that. Different output channels mean that: > >> - There is no guarantee of correct output order! The empty lines may >> move randomly over the text. > >Good point! (Of course the others are too, but this one could be >particularly damaging to the intended communication.) > >>> If you have several different messages you want a blank space in >>> between them so you can use e* to create whitespace within the >message >>> to avoid the wall of text syndrome while still making it clear where >it >>> begins and ends. > >>> You're right that using echo means the whitespace doesn't get saved >by >>> the elog system. A while back someone proposed we add espace for >>> exactly this reason but IIRC they were laughed down, which is a >shame. >> >> So... to summarize your point. You shouldn't use the correct function >> that is saved in elog which is primary way of getting info because >you >> find it more convenient to have empty non-'starred' lines that don't >> actually get to elog and make elog a mess? >> >> If you really don't like empty 'starred' lines (and I actually like >them >> since they make separation between packages cleaner), why not submit >a >> patch for Portage and make 'elog' with no arguments output log line >> without a star? That's a trivial solution that doesn't require extra >> functions for the sake of inventing elogspace, ewarnspace, ... > >It is at least possible to use say blank ewarn between elog lines, or >the >reverse, so while there's no totally blank separator, there's at least >a >different color to the star on the starred-blank-line separator. > >Similarly, if there's more than one "topic" to the messages, and >they're >of different severity, the severities can be interspersed to get color >separation. > >I believe I've seen both techniques used to good effect in a few >packages >in the past, but I can't name any off the top of my head. This is mixing channels again. Someone may decide to output warnings separately from elogs. Or not output elogs at all. -- Best regards, Michał Górny (by phone)
Re: [gentoo-dev] Re: RFC: intel-sdp-r1.eclass
On Mi, 2016-02-17 at 10:53 +, Duncan wrote: > Michał Górny posted on Wed, 17 Feb 2016 07:47:06 +0100 as excerpted: > > > On Tue, 16 Feb 2016 22:48:08 -0600 Ryan Hill > > wrote: > > > > > On Mon, 15 Feb 2016 15:35:12 +0100 Michał Górny > > g> > > > wrote: > > > > On Mon, 15 Feb 2016 14:37:41 +0100 "Justin Lecher (jlec)" > > > > wrote: > > > > > On 15/02/16 13:59, Michał Górny wrote: > > > > > > > Don't mix echo with ewarn. > > > > > Why? > > > > Because they won't go through the same output channels. > > > > > > That's kinda the point. You want a blank (unstarred) space to > > > separate > > > out the "important" messages from the generic spew put out by the > > > package manager/eclasses/build system that you have no control > > > over. > > > > This is not just that. Different output channels mean that: > > > - There is no guarantee of correct output order! The empty lines > > may > > move randomly over the text. > > Good point! (Of course the others are too, but this one could be > particularly damaging to the intended communication.) > > > > If you have several different messages you want a blank space in > > > between them so you can use e* to create whitespace within the > > > message > > > to avoid the wall of text syndrome while still making it clear > > > where it > > > begins and ends. > > > > You're right that using echo means the whitespace doesn't get > > > saved by > > > the elog system. A while back someone proposed we add espace for > > > exactly this reason but IIRC they were laughed down, which is a > > > shame. > > > > So... to summarize your point. You shouldn't use the correct > > function > > that is saved in elog which is primary way of getting info because > > you > > find it more convenient to have empty non-'starred' lines that > > don't > > actually get to elog and make elog a mess? > > > > If you really don't like empty 'starred' lines (and I actually like > > them > > since they make separation between packages cleaner), why not > > submit a > > patch for Portage and make 'elog' with no arguments output log line > > without a star? That's a trivial solution that doesn't require > > extra > > functions for the sake of inventing elogspace, ewarnspace, ... > > It is at least possible to use say blank ewarn between elog lines, or > the > reverse, so while there's no totally blank separator, there's at > least a > different color to the star on the starred-blank-line separator. > > Similarly, if there's more than one "topic" to the messages, and > they're > of different severity, the severities can be interspersed to get > color > separation. > > I believe I've seen both techniques used to good effect in a few > packages > in the past, but I can't name any off the top of my head. > For all those who care, I've updated the eclass under: https://github.com/gentoo-science/sci/pull/588
Re: [gentoo-dev] Re: RFC: intel-sdp-r1.eclass
On Tue, 16 Feb 2016 22:48:08 -0600
Ryan Hill wrote:
> On Mon, 15 Feb 2016 15:35:12 +0100
> Michał Górny wrote:
> > On Mon, 15 Feb 2016 14:37:41 +0100
> > "Justin Lecher (jlec)" wrote:
> > > On 15/02/16 13:59, Michał Górny wrote:
> > > > On Mon, 15 Feb 2016 09:16:53 +0100
> > > > "Justin Lecher (jlec)" wrote:
> > > >> _isdp_big-warning() {
> > > >>debug-print-function ${FUNCNAME} "${@}"
> > > >>case ${1} in
> > > >>pre-check )
> > > >>echo ""
> > > > Don't mix echo with ewarn.
> > > Why?
> > Because they won't go through the same output channels.
>
> That's kinda the point. You want a blank (unstarred) space
> to separate out the "important" messages from the generic
> spew put out by the package manager/eclasses/build system
> that you have no control over.
This is not just that. Different output channels mean that:
- some of them can be turned off. In this case, you end up with empty
lines and no message.
- There is no guarantee of correct output order! The empty lines may
move randomly over the text.
- When the function happens to be used in $(), part of the output will
be collected (not that it's 100% valid concern right now because
EAPI 6 doesn't guarantee e* using stderr yet).
> If you have several different messages you want a blank space
> in between them so you can use e* to create whitespace within
> the message to avoid the wall of text syndrome while still
> making it clear where it begins and ends.
>
> Let's take openrc for example (not picking on anyone, it's just
> the last package with a bunch of different post-install messages
> I happened to emerge).
>
> Currently:
>
> * The OpenRC dependency data has already been migrated.
> * Caching service dependencies ... [ ok ]
> * In this version of OpenRC, the loopback interface no longer
> * satisfies the net virtual.
> * If you have services now which do not start because of this,
> * They can be fixed by adding rc_need="!net"
> * to the /etc/conf.d/ file.
> * You should also file a bug against the service asking that
> * need net be dropped from the dependencies.
> * The bug you file should block the following tracker:
> * https://bugs.gentoo.org/show_bug.cgi?id=439092
> *
> * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
> * fixed correctly in earlier versions of OpenRC.
> * The correct fix is implemented in this version, but that
> * means netmount needs to be added to the default runlevel if
> * you are using nfs file systems.
> *
> * You should now update all files in /etc, using etc-update
> * or equivalent before restarting any services or this host.
>
> This is pretty much unreadable to me.
>
> Better:
>
> * The OpenRC dependency data has already been migrated.
> * Caching service dependencies ... [ ok ]
> *
> * In this version of OpenRC, the loopback interface no longer
> * satisfies the net virtual.
> *
> * If you have services now which do not start because of this,
> * They can be fixed by adding rc_need="!net"
> * to the /etc/conf.d/ file.
> *
> * You should also file a bug against the service asking that
> * need net be dropped from the dependencies.
> *
> * The bug you file should block the following tracker:
> * https://bugs.gentoo.org/show_bug.cgi?id=439092
> *
> * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
> * fixed correctly in earlier versions of OpenRC.
> *
> * The correct fix is implemented in this version, but that
> * means netmount needs to be added to the default runlevel if
> * you are using nfs file systems.
> *
> * You should now update all files in /etc, using etc-update
> * or equivalent before restarting any services or this host.
>
> This is better but you still have to read the whole thing to
> make sure you didn't miss anything important.
>
> Even better:
>
> * The OpenRC dependency data has already been migrated.
> * Caching service dependencies ... [ ok ]
>
> * In this version of OpenRC, the loopback interface no longer
> * satisfies the net virtual.
> *
> * If you have services now which do not start because of this,
> * They can be fixed by adding rc_need="!net"
> * to the /etc/conf.d/ file.
> *
> * You should also file a bug against the service asking that
> * need net be dropped from the dependencies.
> * The bug you file should block the following tracker:
> *
> * https://bugs.gentoo.org/show_bug.cgi?id=439092
>
> * Bug https://bugs.gentoo.org/show_bug.cgi?id=427996 was not
> * fixed correctly in earlier versions of OpenRC.
> *
> * The correct fix is implemented in this version, but that
> * means netmount needs to be added to the default runlevel if
> * you are using nfs file systems.
>
> * You should now update all files in /etc, using etc-update
> * or equivalent before restarting any services or this host.
>
> Here I can read the first line of the second block and know I can
> skip the ne
