linux/poky.git/bitbake/lib/bb/runqueue.py, branch 1.7_M3

bitbake: siggen/runqueue/bitbake-worker: Improve siggen data transfer interface

2014-09-11T16:31:17+00:00

We need to transfer some of the siggen data from the core/cooker into the worker instances. There was a partial API created for this but its ugly and its not possible to extend it from the siggen class. This patch completes the interface/abstraction for the data and means the class can extend/customise it in any siggen class. (Bitbake rev: cf2d642052979d236185c5b8ca2c5478c06e62ae) Signed-off-by: Richard Purdie

bitbake: bitbake-worker: Extra profiling data dump

2014-08-28T14:12:45+00:00

Currently we get no profiling oversight into either the main bitbake worker process, or the overall parsing before task execution. This adds in extra profiling hooks so we can truly capture all parts of bitbake's execution into the profile data. To do this we modify the 'magic' value passed to bitbake-worker to trigger the profiling, before the configuration data is sent over to the worker. (Bitbake rev: 446e490bf485b712e5cee733dab5805254cdcad0) Signed-off-by: Richard Purdie

bitbake: runqueue: Fix setscene tasks not running

2014-08-28T14:12:45+00:00

Currently, if you have hard dependencies between setscene tasks (like avahi on base-passwd through useradd.bbclass), other dependencies may not be installed even if these exist in sstate. For example, avahi -> expat -> pigz-native (and avahi -> base-passwd) yet if you cleansstate base-passwd: bitbake gzip-native:do_clean avahi:do_clean expat:do_clean pigz-native:do_clean base-passwd:do_cleansstate bitbake avahi | tee you will currently see pigz-native being rebuilt even though it was in sstate. The fix for this is to continue to iterate dependency chains around hard blocked dependencies as per this patch. After this patch is applied, you will see pigz-native installed from sstate. (Bitbake rev: f787957a224e8c2682a19e5c4a4d9c86bdce52ba) Signed-off-by: Richard Purdie

bitbake: runqueue.py: Fix typoes/grammar in comments.

2014-08-19T19:41:26+00:00

(Bitbake rev: 000fa81013205dd9bc907ff7a61f06f57637212d) Signed-off-by: Robert P. J. Day Signed-off-by: Richard Purdie

bitbake: runqueue.py: Correct several misspellings of "notifing".

2014-08-19T19:41:26+00:00

(Bitbake rev: 4e9aef14d747c37444a4fc683f9641906906afe9) Signed-off-by: Robert P. J. Day Signed-off-by: Richard Purdie

bitbake: runqueue: Add sceneQueueComplete event

2014-08-03T11:40:41+00:00

Its useful to have an event emitted when all of the sceneQueue tasks have completed since the metadata can hook this for processing. Therefore add such an event. (Bitbake rev: 38d4f65bf1cbcdd5a2d60dff0e1d2859c34ed62e) Signed-off-by: Richard Purdie

bitbake: command/runqueue: Fix shutdown logic

2014-07-21T18:24:29+00:00

If you hit Ctrl+C at the right point, the system processes the request but merrily continues building. It turns out finish_runqueue() is called but this doesn't stop the later generation and execution of the runqueue. This patch adjusts some of the conditionals to ensure the build really does stop. (Bitbake rev: 39b08c604ba713100e174c136f81f18eca6ef33d) Signed-off-by: Richard Purdie

bitbake: runqueue: Do not write out stamp files in dry_run mode

2014-04-23T10:43:29+00:00

In dry run mode, stamps for noexec tasks are being written out which is incorrect. Avoid this. (Bitbake rev: aa6448a0552ba2947ac262b8b5314a593d1058d3) Signed-off-by: Richard Purdie

bitbake: runqueue: Fix task weighting algorithm

2014-04-23T10:43:29+00:00

When looking at a list of tasks, do_patch and do_unpack were being given equal priority when one clearly depends on another. The reason for this was the default task weights of 0 being to tasks. This is therefore changed to 1 to allow correct weighting of dependencies which means the scheduler has better information available to it about tasks. Weight endpoints differently (10) for clearer debugging of priorities. (Bitbake rev: 12dc1d17fac3e8ec420fcafb06186d32fd847d89) Signed-off-by: Richard Purdie

bitbake: runqueue: Fix handling of zero priority task

2014-04-23T10:43:29+00:00

The zero priority task should be run first but was being confused with the None value the priority field defaulted to. Check for None explicitly to avoid this error. In the real world this doesn't change much but it confused the debug output from the schedulers. (Bitbake rev: 49c9d8c9400f74c804c2f36462639236e0841ff0) Signed-off-by: Richard Purdie