Hi! Per-package message logging. I suggest app-portage. This ebuild depend on python. maxtoo.
Created attachment 57378 [details] enotice-0.2.2.ebuild
Created attachment 57379 [details] enotice-0.2.2 script (to put in "/files" dir)
Created attachment 57380 [details] profile.bashrc (to put in "/files" dir)
Works fine here. Finally I don
Works fine here. Finally I don´t have to set this up manually on every Gentoo box. Thanks!
*** This bug has been marked as a duplicate of 11356 ***
wrong bug number
*** This bug has been marked as a duplicate of 11359 ***
Hmm, yet another bug is marked as a dupe of a bug that has been around for 2,5 years (a.k.a. for ages) but I
Hmm, yet another bug is marked as a dupe of a bug that has been around for 2,5 years (a.k.a. for ages) but I´d rather have this ebuild in portage tree than wait for maybe another year until portage-2.1 (?) becomes reality. This could have been a separate ebuild or a part of gentoolkit for a long time and would have prevented people from moaning about missed einfo/ewarns causing the things to break... Just my $0.02 :p
Well, I'm not going to support ANY package that abuses profile.bashrc.
Abuses?! Huh, any other non-abusive ideas then? Sorry, but this has taken too long, seriously...
"Abuses?! Huh, any other non-abusive ideas then? Sorry, but this has taken too long, seriously... " Kindly play nice. Use it in your overlay, portage cvs head already has functionality that's not a hack (sorry eldad, the bashrc trickery is a hack, nifty solution, but not something deployable). If you want to go ahead with it, tack it into your bashrc. The bashrc hack won't wind up in a profile....
Any issue with integrating the bashrc part into ebuild.sh? It would remove the dependency on /sbin/functions.sh if nothing else...
Please note that I've done some substantial development work on enotice in coordination with Eldad Zack. We're up to version 0.2.9. It's available at http://www.fmp.com/enotice. Further enhancements are planned since I'm getting some good feedback from people who are using the utility, and I was just sent a link to a newer ebuild script which I haven't had time to check out yet. The tar file at fmp.com includes a man page, a change log and a shell installer (lacking as yet a proper ebuild) Integrating the functionality of our profile.bashrc into ebuild.sh would, of course, eliminate objections to putting code into the former. I'm not able to find any consistent protocol or usage description for profile.bashrc (it's not listed in the portage man page) so I don't know what the issues are there. This would require a commitment from the portage devs to support the changes in ebuild.sh going forward.
Created attachment 65088 [details] Enotice-0.2.9 tarball enotice-0.2.9 adds alpha|timestamp sorting option, paging for notices and notice index, notice range display or deletion, severity selection criteria, man page and much more.
well, *if* we're going to change ebuild.sh then I'd rather backport the elog changes in head, as the changes on the python side shouldn't differ between head and stable. Jason, would be your decision if changes to ebuild.sh are acceptable (new feature in stable that will likely see a few changes once it's out).
That works as it's fairly isolated. *** This bug has been marked as a duplicate of 11359 ***
As 2.1 alpha is out, you might wanna look at porting the enotice reader to use the elog logfiles (comments in make.conf.example should explain how to use it)
It looks like the proposed portage system is going to address the issue of ebuild logging, but from looking at the 2.1 make.conf, the logging may or may not be compatible with the enotice reader. enotice expects each line in a logfile to have a prefix - "info:", "warn:" or "error:" and display options can be set according to how much or how little information is wanted. How will this work in logfiles generated by portage 2.1? Will there be any distinctions between lines in the generated logfiles so the enotice can make such a selection? I could probably go digging in the gentoo CVS system and find this information eventually, but if someone who knows it could summarize it for me, I could move forward.
Created attachment 68851 [details] sample logfile from portage-2.1 Well, you could just merge portage-2.1 after unamsking, but I'm also attaching a sample logfile generated by it. It doesn't prefix every line, instead it's using sections where each section is started with a line LEVEL:phase and ended with one or more blank newlines. It would also be possible to make a module that saves it in a enotice compatible way though.
Created attachment 68852 [details] sample logfile from portage-2.1 Well, you could just merge portage-2.1 after unamsking, but I'm also attaching a sample logfile generated by it. It doesn't prefix every line, instead it's using sections where each section is started with a line LEVEL:phase and ended with one or more blank newlines. It would also be possible to make a module that saves it in a enotice compatible way though.
Comment on attachment 68851 [details] sample logfile from portage-2.1 stupid bugzilla adding this twice ...
*** Bug 145062 has been marked as a duplicate of this bug. ***
Time permitting, I'll have a go at updating enotice to support elog log files.
Possible alternate solution: write a elog module that generates logfiles in enotice format (see mod_save.py and/or mod_syslog.py for examples). Might be the easier solution.
