Bugzilla Bug 158933

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.