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 <ri...@gentoo.org> wrote:
>>> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt
>>> <m.j.ever...@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: signature.asc
Description: OpenPGP digital signature

Reply via email to