<div dir="ltr">> <span style="font-size:12.8px">You could do "grep -v version-going-backwards qa.log" I guess?</span><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">In theory yes, in practice the same jenkins jobs are building different DISTROs or different Yocto releases with different QA flags enabled, so I would end up with using bitbke -e to find</span></div><div><span style="font-size:12.8px">WARN_QA and ERROR_QA for given build and then filter only those from qa.log.</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">I can still do it outside OE, I just didn't realize that there are reasons for not wanting the levels in the log file (and I still don't know why it's a good thing not to have them).</span></div><div><span style="font-size:12.8px"><br></span></div><div><span style="font-size:12.8px">Regards,</span></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Aug 21, 2017 at 11:23 PM, Richard Purdie <span dir="ltr"><<a href="mailto:richard.purdie@linuxfoundation.org" target="_blank">richard.purdie@linuxfoundation.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><span class="">On Mon, 2017-08-21 at 23:13 +0200, Martin Jansa wrote:<br>
> > all messages are put into the log but at differing log levels.<br>
><br>
> But there aren't the "log levels" in the file (as NOTE, WARN, ERROR)<br>
> now, it writes only P, error message and type of QA check (not the<br>
> selected severity of it, like bb.error, bb.warn, bb.note used in the<br>
> function for normal output).<br>
><br>
> See the function above package_qa_handle_error:<br>
><br>
> def package_qa_write_error(type, error, d):<br>
> logfile = d.getVar('QA_LOGFILE')<br>
> if logfile:<br>
> p = d.getVar('P')<br>
> with open(logfile, "a+") as f:<br>
> f.write("%s: %s [%s]\n" % (p, error, type))<br>
><br>
<br>
</span>Sorry, I misread your earlier message and assumed it was logging the<br>
level already. I've spent too long staring at bitbake server bugs :/.<br>
<br>
I'm still torn on this, I can see why qa.log makes sense to contain all<br>
the qa issues found and then the WARN/ERROR levels filter the console<br>
output (and ultimately the bitbake exit code). I can also see why in<br>
general we'd not want "levels" in the logfile, its more of a console<br>
issue.<br>
<br>
You could do "grep -v version-going-backwards qa.log" I guess?<br>
<br>
Cheers,<br>
<br>
Richard<br>
<br>
<br>
</blockquote></div><br></div>