I think this is something we need to do now.

I think we might need to refactor the code a little bit. After all, not all WARNINGS are related to the packaging process and package_qa_handle_error thus not a suitable name for a generic function to handle all warnings.

I also suggest that we use buildhistory to manage that qa.log file.

//Chen Qi

Now that bbwarn routes the messages to bitbake (instead of just being a wrapper around echo) all the warnings from shell will be in the log.

Marking as NEEDINFO as I believe this is actually resolved now.  Martin, as you filed this, do you have any opinion?

.

> Now that bbwarn routes the messages to bitbake (instead of just being a wrapper around echo) all the warnings from shell will be in the log.

That's definitely an improvement, but doesn't implement the description:

> It would be nice to store all WARNINGS shown while building in some file like qa.log (can be different file).

>  it would be nice to extend this to all new warnings (without greping whole cooker log).

Basically I need to check qa.log for QA issues.

_AND_ grep bitbake log for all other ERROR, WARNING (grep -v QA issues).

This ticket was about storing all warnings/errors in qa.log file or introducing new issues.log file which will contain only ERRORs and WARNINGs.

Is this just a convenience over filtering out NOTE/INFO from the cooker log?  Or is there something else I'm still missing?

Yes convenience, like separate qa.log file is.

Right.  Sounds like a good argument to remove the special handling of qa.log and instead allowing bitbake to write more log files depending on the level.

This three-line patch to bitbake:

        handler = logging.FileHandler("/tmp/badlog")
        handler.setLevel(logging.WARNING)
        bb.logger.addHandler(handler)

Mostly does what you want.  Annoyingly doing this from a class is non-trivial as classes are invoked multiple times at startup so the log has duplicates in.

Is it still an issue? someone working on it?

I believe that we can now configure bitbake's logging from a configuration file so this can likely be done that way, we do something a bit like that on the autobuilder.

We can likely close this once we check such a config is possible. 

There is a separate bug for shsowing warnings for things restored from sstate.

This can be acomplished today with a log config file. Set BB_LOGCONFIG to point to a json file that contains:

{
    "version": 1,
    "formatters": {
        "warnlogFormatter": {
            "()": "bb.msg.BBLogFormatter",
            "format": "%(levelname)s: %(message)s"
        }
    },
    "handlers": {
        "warnlog": {
            "class": "logging.FileHandler",
            "formatter": "warnlogFormatter",
            "level": "WARNING",
            "filename": "warn.log"
        }
    },
    "loggers": {
        "BitBake": {
            "handlers": ["warnlog"]
        }
    },
    "@disable_existing_loggers": false
}

And all WARNINGS and higher will be sent to "warn.log"

Thanks, it might take a while to update various jenkins jobs etc to use this, but I agree that this is reasonable long term solution better than special handling of qa.log.