Re: [gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

Re: [gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[james]

On 12/14/2016 12:59 PM, Doug Freed wrote:
> On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman <rich0@gentoo.org> wrote:
>> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>>>
>>> I do, but only usually if its the last package of an emerge because
>>> otherwise its lost many many thousands of lines upwards. Thank goodness
>>> for portage's savelog feature. - Actually that reminds me .. someone
>>> mentioned a useful tweak to that, with an appropriate FEATURES switch,
>>> it would categorise the output of the logging system .. must look that
>>> one up again, or poke the wiki team .......




Well pardon me, if I'm miss interpreting here, as there is only this 
fragmented thread in my inbox:: no prior postings. But perhaps folks 
should look at "app-portage/elogv"

Already in place, easy to use, and should be updated with EAPI (5/6) 
based parsing features?

hth,
James


>>>
>>
>> IMO, emailing elogs to root should probably be the default.  By all
>> means let people turn it off, but I bet a lot of people don't realize
>> it is an option.
>
> Having just looked at portage's mail code, you can't use the mail
> subsystem if you have no mailserver or sendmail binary.  Instead,
> it'll just throw an error, so you couldn't have any default Portage
> configuration to mail them somewhere.  The current default
> configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
> warn, and error levels for every package that outputs any of these
> classes.  If PORT_LOGDIR is unset, the target is
> /var/log/portage/elog/summary.log.
>
>>
>> This goes in all my make.conf files:
>> PORTAGE_ELOG_CLASSES="warn error log"
>> PORTAGE_ELOG_SYSTEM="save mail"
>> PORTAGE_ELOG_MAILURI="a@a.com smtp.server.address"
>> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
>>
>> Yes, some packages are a bit spammy and this should be fixed, but in
>> general it has prevented more headaches than it has caused.
>
> This can't really be fixed in a good way, and I'd really rather it
> wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
> pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
> defined in pkg_pretend or pkg_setup), and in many cases, using
> REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
> the readme.gentoo eclass wouldn't be an awful way to go if it really
> bothers you, but you could also use mail_summary instead of mail to
> reduce the mail spam to 1 email per emerge run.
>
> -Doug
>
>

[gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[Doug Freed]

On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman <rich0@gentoo.org> wrote:
> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt <m.j.everitt@iee.org> wrote:
>>
>> I do, but only usually if its the last package of an emerge because
>> otherwise its lost many many thousands of lines upwards. Thank goodness
>> for portage's savelog feature. - Actually that reminds me .. someone
>> mentioned a useful tweak to that, with an appropriate FEATURES switch,
>> it would categorise the output of the logging system .. must look that
>> one up again, or poke the wiki team .......
>>
>
> IMO, emailing elogs to root should probably be the default.  By all
> means let people turn it off, but I bet a lot of people don't realize
> it is an option.

Having just looked at portage's mail code, you can't use the mail
subsystem if you have no mailserver or sendmail binary.  Instead,
it'll just throw an error, so you couldn't have any default Portage
configuration to mail them somewhere.  The current default
configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
warn, and error levels for every package that outputs any of these
classes.  If PORT_LOGDIR is unset, the target is
/var/log/portage/elog/summary.log.

>
> This goes in all my make.conf files:
> PORTAGE_ELOG_CLASSES="warn error log"
> PORTAGE_ELOG_SYSTEM="save mail"
> PORTAGE_ELOG_MAILURI="a@a.com smtp.server.address"
> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST} with notice"
>
> Yes, some packages are a bit spammy and this should be fixed, but in
> general it has prevented more headaches than it has caused.

This can't really be fixed in a good way, and I'd really rather it
wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
defined in pkg_pretend or pkg_setup), and in many cases, using
REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
the readme.gentoo eclass wouldn't be an awful way to go if it really
bothers you, but you could also use mail_summary instead of mail to
reduce the mail spam to 1 email per emerge run.

-Doug

Re: [gentoo-dev] Handling ebuild logging output in Portage (Was: gpg: signing failed: Inappropriate ioctl for device)

[M. J. Everitt]

[-- Attachment #1.1: Type: text/plain, Size: 3286 bytes --]

At the risk of starting a flame war, two minor netiquette tips... ;)

1) Top or mid-posting is not recommended .. makes following the thread
harder [note my deliberate misuse here!]
2) PLEASE PLEASE sort out your clock .. I have emails from you (yeah I
know Thunderbird is ****) from the future year 2026 which don't really
belong at the top of my mail folder.....

Tyvm,ia,

Michael.
PS. Yes, I was aware of the elogv package, I think its mentioned in
whatever docs for PORTAGE_ELOG_*. If it needs updating for EAPI6 we'll
have to hunt down a maintainer....

On 11/12/16 15:49, james wrote:
> On 12/14/2016 12:59 PM, Doug Freed wrote:
>> On Wed, Dec 14, 2016 at 10:45 AM, Rich Freeman <rich0@gentoo.org> wrote:
>>> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt
>>> <m.j.everitt@iee.org> wrote:
>>>>
>>>> I do, but only usually if its the last package of an emerge because
>>>> otherwise its lost many many thousands of lines upwards. Thank
>>>> goodness
>>>> for portage's savelog feature. - Actually that reminds me .. someone
>>>> mentioned a useful tweak to that, with an appropriate FEATURES switch,
>>>> it would categorise the output of the logging system .. must look that
>>>> one up again, or poke the wiki team .......
>
>
>
>
> Well pardon me, if I'm miss interpreting here, as there is only this
> fragmented thread in my inbox:: no prior postings. But perhaps folks
> should look at "app-portage/elogv"
>
> Already in place, easy to use, and should be updated with EAPI (5/6)
> based parsing features?
>
> hth,
> James
>
>
>>>>
>>>
>>> IMO, emailing elogs to root should probably be the default.  By all
>>> means let people turn it off, but I bet a lot of people don't realize
>>> it is an option.
>>
>> Having just looked at portage's mail code, you can't use the mail
>> subsystem if you have no mailserver or sendmail binary.  Instead,
>> it'll just throw an error, so you couldn't have any default Portage
>> configuration to mail them somewhere.  The current default
>> configuration appends to ${PORT_LOGDIR}/elog/summary.log with qa, log,
>> warn, and error levels for every package that outputs any of these
>> classes.  If PORT_LOGDIR is unset, the target is
>> /var/log/portage/elog/summary.log.
>>
>>>
>>> This goes in all my make.conf files:
>>> PORTAGE_ELOG_CLASSES="warn error log"
>>> PORTAGE_ELOG_SYSTEM="save mail"
>>> PORTAGE_ELOG_MAILURI="a@a.com smtp.server.address"
>>> PORTAGE_ELOG_MAILSUBJECT="package \${PACKAGE} merged on \${HOST}
>>> with notice"
>>>
>>> Yes, some packages are a bit spammy and this should be fixed, but in
>>> general it has prevented more headaches than it has caused.
>>
>> This can't really be fixed in a good way, and I'd really rather it
>> wasn't anyway.  A [ -z "$REPLACING_VERSIONS" ] test is only valid in
>> pkg_* phases (and by PMS, REPLACING_VERSIONS doesn't have to be
>> defined in pkg_pretend or pkg_setup), and in many cases, using
>> REPLACING_VERSIONS in any way can be difficult to do correctly.  Using
>> the readme.gentoo eclass wouldn't be an awful way to go if it really
>> bothers you, but you could also use mail_summary instead of mail to
>> reduce the mail spam to 1 email per emerge run.
>>
>> -Doug
>>
>>
>
>



[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 836 bytes --]