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
[gentoo-dev] Re: RFC: intel-sdp-r1.eclass
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. -- Duncan - List replies preferred. No HTML msgs. "Every nonfree program has a lord, a master -- and if you use the program, he is your master." Richard Stallman
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
[gentoo-dev] Re: RFC: intel-sdp-r1.eclass
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.
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 next 12 lines without missing anything. The next block
isn't worded the greatest, but that's beside the point. And now
I get an important message at the end that I previously never
noticed because tl;dr.
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.
--
pgpywRVygQn7V.pgp
Description: OpenPGP digital signature
[gentoo-dev] Re: RFC: intel-sdp-r1.eclass
Justin Lecher (jlec) wrote:
>>> [[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="${_INTEL_PV4}-"
>>> [[ -n ${_INTEL_PV1} ]] && _INTEL_PV+="${_INTEL_PV1}"
>>> [[ -n ${_INTEL_PV2} ]] && _INTEL_PV+=".${_INTEL_PV2}"
>>> [[ -n ${_INTEL_PV3} ]] && _INTEL_PV+=".${_INTEL_PV3}"
>>> [[ -n ${_INTEL_PV4} ]] && _INTEL_PV+="-${_INTEL_PV4}"
>>
>> Now, this is crazy ;-). I don't see immediately how to improve that,
>> but I suggest you thought about that.
>
> [...] So there is no sanity other then reshuffling.
You could put the logic into the string:
_INTEL_PV+="${_INTEL_PV4}${_INTEL_PV4:+-}${_INTEL_PV1}"
_INTEL_PV+="${_INTEL_PV2:+.}${_INTEL_PV2}"
_INTEL_PV+="${_INTEL_PV3:+.}${_INTEL_PV3}"
_INTEL_PV+="${_INTEL_PV4:+-}${_INTEL_PV4}"
