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

bitbake: runqueue: Ensure setscene tasks that aren't covered get built

2018-09-10T11:13:38+00:00

Running "bitbake gconf-native -c cleansstate; bitbake core-image-sato:do_populate_sdk" results in a build where it fails to find gconf-native and fails to build it, merrily trying to build the SDK without gconf being present. The issue is the missing setscene tasks are effectively ignored as the later code in runqueue thinks that since other sstate tasks are present, these 'cover' the missing one. In reality we need to call BB_SETSCENE_DEPVALID to make that decision. To do that we need a "reduced" setscene dependency graph which we don't have in main task graph context. Since that was already done in setscene, we should just assume anything in the non-covered list needs to be built. (Bitbake rev: 464d0339add15bc8b4344ddd1e4c49706e3c0a02) Signed-off-by: Richard Purdie

bitbake: cooker/runqueue: Turn universe warnings into verbnotes

2018-09-10T11:13:38+00:00

If the user puts universe on the commandline, they don't really want warnings so use the new verbnote level instead. (Bitbake rev: 0c87ade5678e503899e3a6cdda5329f6fc212b63) Signed-off-by: Richard Purdie

bitbake: runqueue: Move decision if a task can be started to one common place

2018-08-15T20:45:58+00:00

(Bitbake rev: 99d9e4389e1f1d78d17a23ee078fe3f4a12cb31d) Signed-off-by: Andreas Müller Signed-off-by: Richard Purdie

bitbake: runqueue: Allow the hash validate function to have an idea of build completion

2018-08-08T09:52:00+00:00

There is an oversight in the current hash validation API in that the function can't know how many setscene tasks already completed. Rather than trying to add additional parameters to the function, causing incompatibilities, store the value in the datastore. This is useful to allow build status reporting to the user for figures on sstate reusage and build completion. (Bitbake rev: ec037d3e49264037b81212f498d98e292ae7c334) Signed-off-by: Richard Purdie

bitbake: bitbake: Add support for multiconfig dependencies

2018-08-01T09:07:22+00:00

This patch adds the capability for tasks from different multiconfigs to depend on one another. These dependencies can be enabled using the following format: task[mcdepends] = "multiconfig:FROM-MC:TO-MC:PN:task-to-depend-on" For the sake of simplicity consider the following example: Assuming we have set up multiconfig builds, one for qemux86 and one for qemuarm, named x86 and arm respectively. Adding the following line to an image recipe (core-image-sato): do_image[mcdepends] = "multiconfig:x86:arm:core-image-minimal:do_rootfs" Would state that core-image-sato:do_image from x86 will depend on core-image-minimal:do_rootfs from arm so it can be executed. This patch makes modifications to: - cooker: To glue both multiconfigs in one place and make sure the dependencies can be provided. - taskdata: To parse and add a new kind of dependency (mcdepends) to the taskdata object. - runqueue: To differentiate tasks from different multiconfigs, add the specified dependencies to the corresponding tasks, and create a working runqueue that contains tasks from both multiconfigs. - siggen: To avoid looking for tasks from different multiconfigs on objects where they dont belong. The taskdata objects are still not aware of the concept of multiconfig, so each object doesnt know which multiconfig its building, hence why the mcdepends are added to all taskdata objects equally (we really dont expect many of these), but the actual dependencies are added only to the required tasks by the runqueue. (Bitbake rev: da8cb8633504bdc815bdcefc538340b9bce5065d) Signed-off-by: Alejandro Enedino Hernandez Samaniego Signed-off-by: Richard Purdie

bitbake: runqueue: Stop on first unsatisfied dependency

2018-07-09T10:26:56+00:00

(Bitbake rev: 9876b5da1c65bf09a790542cb4057f2d93868cf7) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: runqueue: Remove unused variable

2018-07-09T10:26:56+00:00

(Bitbake rev: 91e5540f53aca93e3489255cfd95feaa0afd0498) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: runqueue: Remove trailing whitespace

2018-07-09T10:26:56+00:00

(Bitbake rev: 9b9aecbbb1a3fa67f7d3b1669186c9f4ced3a590) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: runqueue.py: Fix a virtual class extension stamps issue

2018-07-02T20:38:06+00:00

The file_name parameter passed to bb.parse.siggen.invalidate_task should be a virtual file name instead of a real file name, or else you will encounter a following error, for instance, when you run: $ bitbake nativesdk-lzip -c unpack -f the error arise: | ERROR: An uncaught exception occurred in runqueue | if file_name: | > taintfn = d.stamp[file_name] + '.' + task + '.taint' | else: | KeyError: 'virtual:nativesdk:/opt/poky/meta/recipes-extended/lzip/lzip_1.19.bb' when multilib builds are used on OE. (Bitbake rev: da37bdad46e11e7ce93ba7a59d58757b769dc16b) Signed-off-by: Ming Liu Signed-off-by: Richard Purdie

bitbake: runqueue.py: Initial implementation of per task process limits

2018-06-15T16:57:30+00:00

On high core machines, in do_fetch, it is possible to DDoS your own machine. A method to limit any arbitrary task type to a certain number of simultaneous threads is needed. (Similar to how BB_NUMBER_THREADS works in the general case.) The format of this new limitation is: do_fetch[number_threads] = "2" This should be set globally. If it is set in individual recipes it could result in unpredictable behavior. Note: a value for number_threads > BB_NUMBER_THREADS will have no effect. (Bitbake rev: 055865047c63b9c3b213b47a1884924ce0adeda0) Signed-off-by: Mark Hatle Signed-off-by: Richard Purdie