> You could do "grep -v version-going-backwards qa.log" I guess?
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 WARN_QA and ERROR_QA for given build and then filter only those from qa.log. 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). Regards, On Mon, Aug 21, 2017 at 11:23 PM, Richard Purdie < [email protected]> wrote: > On Mon, 2017-08-21 at 23:13 +0200, Martin Jansa wrote: > > > all messages are put into the log but at differing log levels. > > > > But there aren't the "log levels" in the file (as NOTE, WARN, ERROR) > > now, it writes only P, error message and type of QA check (not the > > selected severity of it, like bb.error, bb.warn, bb.note used in the > > function for normal output). > > > > See the function above package_qa_handle_error: > > > > def package_qa_write_error(type, error, d): > > logfile = d.getVar('QA_LOGFILE') > > if logfile: > > p = d.getVar('P') > > with open(logfile, "a+") as f: > > f.write("%s: %s [%s]\n" % (p, error, type)) > > > > Sorry, I misread your earlier message and assumed it was logging the > level already. I've spent too long staring at bitbake server bugs :/. > > I'm still torn on this, I can see why qa.log makes sense to contain all > the qa issues found and then the WARN/ERROR levels filter the console > output (and ultimately the bitbake exit code). I can also see why in > general we'd not want "levels" in the logfile, its more of a console > issue. > > You could do "grep -v version-going-backwards qa.log" I guess? > > Cheers, > > Richard > > >
-- _______________________________________________ Openembedded-core mailing list [email protected] http://lists.openembedded.org/mailman/listinfo/openembedded-core
