Bug 160075 – portage elog system: add logging of "QA Notice: ..."

• Status: RESOLVED FIXED
• Product: Portage Development

[Description Steve Dibb (RETIRED) 2007-01-04 12:40:06 UTC]

Currently, there's no way to track QA notices that portage is throwing out (save grepping the output).

It would be extremely helpful if the ELOG system could handle these.

Thanks :)

[Comment 1 Marius Mauch (RETIRED) 2007-01-04 16:24:04 UTC]

Guess that could work, just need to think of an appropriate syslog level for mapping in mod_syslog (options: notice/warning/error (already used by current functions, so not really optimal), critical (too serious IMO) or debug (too easy IMO)).
Any suggestions?

[Comment 2 Simon Stelling (RETIRED) 2007-01-05 15:18:40 UTC]

(In reply to comment #1)
> Any suggestions?

How about:

no strict in FEATURES: notice
strict in FEATURES: warn
stricter in FEATURES: error

Just an idea...

[Comment 3 Jan Kaliszewski 2007-01-08 22:54:54 UTC]

(In reply to comment #0)
> Currently, there's no way to track QA notices that portage is throwing out

Not entirely "no way" -- try using enotice:
http://www.fmp.com/enotice/

All the best.

[Comment 4 Marius Mauch (RETIRED) 2007-01-09 00:22:16 UTC]

(In reply to comment #3)
> (In reply to comment #0)
> > Currently, there's no way to track QA notices that portage is throwing out
> 
> Not entirely "no way" -- try using enotice:
> http://www.fmp.com/enotice/
> 
> All the best.

enotice is an obsolete hack, completely incompatible with elog and I've recently seen reports about it causing sandbox violations. So not really an alternative.(In reply to comment #2)
> (In reply to comment #1)
> > Any suggestions?
> 
> How about:
> 
> no strict in FEATURES: notice
> strict in FEATURES: warn
> stricter in FEATURES: error
> 
> Just an idea...

Hmm, I'd rather keep it static. And that doesn't solve the "already used" problem (for mod_syslog users QA messages would look exactly like normal elog/ewarn/eerror messages).
Well, I guess mapping it to WARN is ok, mod_syslog isn't widely used anyway AFAIK.

[Comment 5 SpanKY 2007-01-09 01:22:33 UTC]

this really needs to be opt-in ... for the average user, they shouldnt see QA Notices in their logs

[Comment 6 Marius Mauch (RETIRED) 2007-01-09 01:46:33 UTC]

New eqawarn function added.

[Comment 7 Zac Medico 2007-01-09 02:35:20 UTC]

(In reply to comment #5)
> this really needs to be opt-in ... for the average user, they shouldnt see QA
> Notices in their logs

No problem.  Calls to eqawarn won't be logged unless the user adds QA to PORTAGE_ELOG_SYSTEM in /etc/make.conf.

Now we just have to go through the code and convert each qa echo call to an eqawarn() call.

[Comment 8 Jan Kaliszewski 2007-01-09 02:50:22 UTC]

(In reply to comment #4)
> enotice is an obsolete hack, completely incompatible with elog and I've
> recently seen reports about it causing sandbox violations.

And enotice 0.2.9.1?

[Comment 9 Marius Mauch (RETIRED) 2007-01-09 08:18:46 UTC]

(In reply to comment #8)
> (In reply to comment #4)
> > enotice is an obsolete hack, completely incompatible with elog and I've
> > recently seen reports about it causing sandbox violations.
> 
> And enotice 0.2.9.1?

I don't track it, but unless it completely changed the way it works it's still incompatible with elog (as both hijack the same functions) which for me is enough reason to not recommend it to people for anything.
But lets stop this now, this bug isn't about enotice.

[Comment 10 Zac Medico 2007-01-10 04:24:06 UTC]

In svn r5507 I've sent all 'QA Notice' messages to eqawarn.  Also, I've modified eqawarn to use vecho and send output to stderr.

[Comment 11 Zac Medico 2007-01-11 04:15:31 UTC]

This has been released in 2.1.2_rc4-r8.