linux/poky.git/bitbake/bin, branch uninative-1.4

bitbake: toaster: don't kill all runserver processes

2016-09-07T23:33:47+00:00

Toaster script kills runserver process 2 ways: - sending signal to pid from .toastermain.pid. - sending signal to pids found by grepping ps output: ps fux | grep "python.*manage.py runserver" Second approach is redundant and harmfull as it kills all django development server running on the machine. [YOCTO #7973] (Bitbake rev: 0f47b17fe88dc660648d94b2d8d8286d87ae6295) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: remove handling of .toasterui.pid

2016-09-07T23:33:47+00:00

This file is not created anywhere, but handled in toaster script code. (Bitbake rev: 16f3cd3535c9eec71ea7594c1e3a83db00dba7ca) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: toaster: don't kill toaster on start

2016-09-07T23:33:47+00:00

There is no point of trying to kill django development server when toaster starts because 'manage.py checksocket' command is already used in the script code to check if development server port is occupied. Even if Toaster is listening on another port, killing previous instance looks quite implicit and doesn't solve anything as there are other processes that might be still running. (Bitbake rev: 0dab45e9815e8939219900264e86f569c714b7c6) Signed-off-by: Ed Bartosh Signed-off-by: Michael Wood Signed-off-by: Richard Purdie

bitbake: bitbake-diffsigs/bitbake-layers: Ensure tinfoil is shut down correctly

2016-09-02T17:09:48+00:00

We should always shut down tinfoil when we're finished with it, either by explicitly calling the shutdown() method or by using it as a context manager ("with ..."). (Bitbake rev: 131e6dc4bbd197774d35d2b266bfb0816f6e6b1e) Signed-off-by: Paul Eggleton Signed-off-by: Richard Purdie

bitbake: bitbake-selftest: enable bitbake logging to stdout

2016-08-20T15:08:59+00:00

Now you get the bb logger output for failed tests. This helps debugging problems. Also, all stdout/stderr data for successful tests is silenced which makes for less cluttered console output. (Bitbake rev: ea19972a16f7639f944823d1d8a7728105460136) Signed-off-by: Markus Lehtonen Signed-off-by: Richard Purdie

bitbake: bitbake-selftest: introduce BB_TMPDIR_NOCLEAN

2016-08-20T15:08:59+00:00

Set this env variable to 'yes' to preserve temporary directories used by the fetcher tests. Useful for debugging tests. (Bitbake rev: 04132b261df9def3a0cff14c93c29b26ff906e8b) Signed-off-by: Markus Lehtonen Signed-off-by: Richard Purdie

bitbake: bitbake-selftest: add help text for env variable(s)

2016-08-20T15:08:58+00:00

(Bitbake rev: 94c63a5b1e731e64eb8efbc09f2ab6a0ce11df05) Signed-off-by: Markus Lehtonen Signed-off-by: Richard Purdie

bitbake: bitbake-selftest: utilize unittest.main better

2016-08-20T15:08:58+00:00

This simplifies the script, and, gives new features. It is now possible to run single test functions, for example. This is nice when writing new test cases. (Bitbake rev: 8c513580b9406b031674f799117eae7410f8e01c) Signed-off-by: Markus Lehtonen Signed-off-by: Richard Purdie

bitbake: bitbake: Update version to 1.31.1

2016-08-18T09:06:27+00:00

(Bitbake rev: 3ff1c66e6f336e5de7dcbc983a97fcd19ddc6b81) Signed-off-by: Richard Purdie

bitbake: bitbake: Initial multi-config support

2016-08-18T09:06:27+00:00

This patch adds the notion of supporting multiple configurations within a single build. To enable it, set a line in local.conf like: BBMULTICONFIG = "configA configB configC" This would tell bitbake that before it parses the base configuration, it should load conf/configA.conf and so on for each different configuration. These would contain lines like: MACHINE = "A" or other variables which can be set which can be built in the same build directory (or change TMPDIR not to conflict). One downside I've already discovered is that if we want to inherit this file right at the start of parsing, the only place you can put the configurations is in "cwd", since BBPATH isn't constructed until the layers are parsed and therefore using it as a preconf file isn't possible unless its located there. Execution of these targets takes the form "bitbake multiconfig:configA:core-image-minimal core-image-sato" so similar to our virtclass approach for native/nativesdk/multilib using BBCLASSEXTEND. Implementation wise, the implication is that instead of tasks being uniquely referenced with "recipename/fn:task" it now needs to be "configuration:recipename:task". We already started using "virtual" filenames for recipes when we implemented BBCLASSEXTEND and this patch adds a new prefix to these, "multiconfig::" and hence avoid changes to a large part of the codebase thanks to this. databuilder has an internal array of data stores and uses the right one depending on the supplied virtual filename. That trick allows us to use the existing parsing code including the multithreading mostly unchanged as well as most of the cache code. For recipecache, we end up with a dict of these accessed by multiconfig (mc). taskdata and runqueue can only cope with one recipecache so for taskdata, we pass in each recipecache and have it compute the result and end up with an array of taskdatas. We can only have one runqueue so there extensive changes there. This initial implementation has some drawbacks: a) There are no inter-multi-configuration dependencies as yet b) There are no sstate optimisations. This means if the build uses the same object twice in say two different TMPDIRs, it will either load from an existing sstate cache at the start or build it twice. We can then in due course look at ways in which it would only build it once and then reuse it. This will likely need significant changes to the way sstate currently works to make that possible. (Bitbake rev: 5287991691578825c847bac2368e9b51c0ede3f0) Signed-off-by: Richard Purdie