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 <[email protected]> wrote: >>> On Wed, Dec 14, 2016 at 10:27 AM, M. J. Everitt >>> <[email protected]> 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="[email protected] 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 >> >> > >
signature.asc
Description: OpenPGP digital signature
