I think the possibility to only have the choices of "info, warn, error, log" are a bit wrong. Why? I have all these mailed to me mostly becouse the possibility to catch messages like: *** INFO: postinst ~/.wine/config is now deprecated. For configuration either use winecfg or regedit HKCU\Software\Wine *** the BAD part with having INFO in your choices is that you got A LOT of messages without any purpose like a mail only containing *** INFO: postrm Updating scrollkeeper database ... Updating desktop mime database ... Updating shared mime info database ... Updating icons cache ... *** (this from the postemerge cleanup-unmerge from lifrea) The ponit is: there is a lot of messages (like the one above from wine) that is nice to have, but a lot (like the postrm from liferea) that is not needed for me. I think it would be nice to maybe make it possible to choose also from what part of the process you want the INFO (and thus also have the possibility to not have all the messages only containing info about a successfully patch).
This is (hopefully) a transitory issue: the LOG level didn't exist before elog was introduced, so most ebuilds still use INFO while they should use LOG. I already have a list of ebuilds to check for potential conversion that I plan to work on next year. A seconf filter is of course another option, but I'd rather avoid the additional (configuration, not code) complexity introduced by it.
Oh, I see. I could understand then why you do not want an additional filter then. Maybe do a tracker-bug for ebuilds not yet migrated? Either list them here or do seperate bugs blocking that one bug?
Too many packages for that yet (current list includes ~1900 packages, but that includes a number of false positives). You can see the current list at dev.gentoo.org/~genone/reports/einfo
How goes the work on this? Is there someone working on it? Can I attach patches for ebuilds I find or should I just point them out here? Like sys-kernel/gentoo-sources is pretty obvious...
I had been processing the list, but stopped somewhere in net-*, partially because I got distracted with other things (like portage-2.2 ;) and partially because it's a really boring job. And unfortunately patches don't really help here as it doesn't make much of a difference if I apply a patch or change the stuff myself, it's all the other stuff that's the real drain (looking up package names, cvs update, changelog update, commit, ...), even though I already have it mostly scripted already. It's ok for one, two or even a dozen packages, but after dealing with several hundred packages this way I burned out on that front.
So with other word it may be better to make bugs for each package I found, and bug their devs?
(In reply to comment #3) > Too many packages for that yet (current list includes ~1900 packages, but > that includes a number of false positives). You can see the current list at > dev.gentoo.org/~genone/reports/einfo What we need is a way for maintainers to remove false positives from a list like this. (In reply to comment #5) [...] Maybe the qa team can help here?
(In reply to comment #7) > (In reply to comment #3) > > Too many packages for that yet (current list includes ~1900 packages, but > > that includes a number of false positives). You can see the current list at > > dev.gentoo.org/~genone/reports/einfo > > What we need is a way for maintainers to remove false positives from a list > like this. Well, my script[1] (called by another wrapper script setting $WHITELIST) for generating those lists has whitelist functionality already. [1] http://sources.gentoo.org/viewcvs.py/portage/private/genone/scripts/einfo-check.sh
I think it would be wise to fix eclasses first since one eclass could fix the behavior of many ebuilds. Bug #199464 was me trying to do something about kernel-2.eclass, but since there is no feedback on my question I came to a stall.
This has gone no where.
