i use portage 2.1 logging system with email notification to catch most of the messages during merge i set portage log level to info for lots of ebuilds now i get 2 emails with different/separate contents i think portage should only send one mail out for one ebuild, collecting all log/status information in one, so if there's something special to do with/for the ebuild i still get the info something like sending one mail at the beginning of an ebuild (if there are infos) and one at the end is not really useful for most ebuilds since it mostly takes only little more for the ebuild to finish than to me to get and read the mail. i use portage 2.1.1_rc1-r1
Can you attach some of those mails? The mail module is supposed to send one mail per package, if it actually sends two it's a bug, but I need to see the pattern before I can investigate this.
Created attachment 95498 [details] content of some mails actually i've seen most of those mails sent twice are from ebuilds with changed use flags/language settings, when updating it seems to send two mails for one ebuild merged and one unmerged (last 2 mails) ...though the info from unmerging is not really interesting anymore since the ebuild is gone !?!
(In reply to comment #2) > when updating it seems to send two mails for one ebuild merged and one unmerged The package being merged is separate from the package being unmerged. The alternative is to combine two separate packages into one email. > ...though the info from unmerging is not really interesting anymore since the > ebuild is gone !?! It may be that the ebuild/eclass maintainer simply needs to switch from einfo to elog for messages that aren't really interesting.
(In reply to comment #3) > (In reply to comment #2) > > when updating it seems to send two mails for one ebuild merged and one unmerged > > The package being merged is separate from the package being unmerged. The > alternative is to combine two separate packages into one email. Hmm, tricky idea. There is no sane general solution (e.g. combining messages in log_process()) due to dependecy on $T, so this would have to be implemented in the delivery modules by (conditional?) caching and comparing the cpv. Don't really like the idea of yet another cache. Also could cause loss of information if a cached (and therefore delayed) message is followed by a failed merge, even if that's very unlikely. > > ...though the info from unmerging is not really interesting anymore since the > > ebuild is gone !?! > > It may be that the ebuild/eclass maintainer simply needs to switch from einfo > to elog for messages that aren't really interesting. Other way around: elog for important messages, einfo for routine stuff.
This should be mostly fixed in trunk.
This is supposed to be fixed in portage-2.2_pre5 or earlier.
