linux/poky.git/bitbake/lib/bb/tinfoil.py, branch uninative-2.1

bitbake: tinfoil: ensure get_recipe_info() returns Null if recipe not found

2017-11-21T13:06:45+00:00

If a matching recipe is not found then return Null instead of raising KeyError because we were blindly using None as a key for pkg_fn. (Bitbake rev: 431e89e322850a2497157c3c0843da9df6bc9a3e) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: Ensure we clean up loggers

2017-11-09T12:24:40+00:00

This is primarily paranoid but ensure we remove any loggers we setup either directly or indirectly so the initial state is restored after we exit. (Bitbake rev: af7d63b1f76fd3f7fa92ed15ae61ca47d9e13472) Signed-off-by: Richard Purdie

bitbake: tinfoil: ensure variable history tracking works when parsing a recipe

2017-08-31T22:30:04+00:00

If you set tracking=True when creating the tinfoil object, that ensures history is collected for the main datastore, but at the end of parsing the configuration, history tracking gets turned off to save time with the result that we don't collect history for any recipes we parse. Enable tracking when we parse a recipe (and disable it afterwards if we enabled it) in order to fix this. This fixes functionality in OE's devtool that relies upon variable history (such as devtool upgrade updating PV when it's set within a recipe). (Bitbake rev: cc8b4c81bb589fb70774a0151f87a8d277f40f06) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: ensure log lines get printed when tasks fail

2017-08-31T22:30:03+00:00

If a task fails during build_targets(), we need to print out the log lines as knotty does or the user will be missing information about the failure. (This should get some deeper refactoring, but now isn't the time for that.) (Bitbake rev: 24879df071d4803db3d39ae1d5cad852daa92f28) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: fix log message doubling when config_only=False

2017-08-31T22:30:03+00:00

With config_only=False we launch the UI and it sets up a logger, whereas when config_only=True we don't, with the result that with True we are seeing log messages from both our logger and the one set up by the UI. Suppress our loggers with config_only=True to avoid this. Fixes [YOCTO #11275] (again). (Bitbake rev: b5e3b28b7c982dd8a3991d727f25710dbf58bb80) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: Revert "tinfoil: fix duplication of log messages"

2017-08-09T08:24:56+00:00

In combination with the recent server reworking, this change actually prevents messages sent from tasks from being logged properly. This will of course give us the duplicated messages back, and I really hate to do that effectively a second time, but that's better than seeing no error at all in the case of a failure - we'll have to find the proper way of avoiding the duplication that doesn't result in some messages going missing. This reverts commit 8a5bae76f91f2411187c638a42fa3c762052cf11. (Bitbake rev: 645c8dd15762516ae5ab64a1df47fadb95d072d1) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: add more doc comments

2017-07-21T07:41:12+00:00

We want this API to be easier to use, so add missing function documentation to help with that. (Bitbake rev: 3e0e002d6497caa987f327cd83ad4db82cca6810) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: add simple API for getting cached recipe information

2017-07-21T07:41:12+00:00

A common task for tinfoil-using scripts is to iterate over all recipes. This isn't too difficult with the current API, but the pkg_* variables are a little awkward and are really designed for bitbake's internal usage - and it gets a bit more difficult when you want to access some of the other information such as packages and rprovides. To resolve this, create a new recipe info class and add an all_recipes() function to generate this for all recipes. Also add a get_recipe_info() function to get the information for a specific recipe (by PN). (It might perhaps be suggested that we already have a structure similar to this in the cache, however the one we add here is designed for external use and allows the internal structures to change if needed without affecting the API). (Bitbake rev: 308994028e59735ca726c5d2c1f0f85baccfe89d) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: enable access to additional cached items

2017-07-21T07:41:12+00:00

Add access to fn_provides, packages, packages_dynamic and rproviders on the recipecache object. This requires an additional corresponding command plumbing to be added. (Bitbake rev: 3df9b7c615174a6557581f3cd157842a28f6bb26) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: tinfoil: add functionality for running full builds

2017-07-21T07:41:12+00:00

Up to this point, if you wanted to run build tasks in the normal way they get run from a python script, there was no other way than to shell out to bitbake. Worse than that, you couldn't have tinfoil active during that because only one bitbake instance could be running at once. As long as we're prepared to handle the events produced, we can create a wrapper around calling the buildTargets command. Borrow code from knotty to do this in such a way that we get the expected running task display (courtesy of TermFilter) and Ctrl+C handling. (Bitbake rev: 43761eee756be52a1021be53a40dc591a6c35fa7) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie