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

bitbake: main/runqueue: Rework runall task and add runonly option

2018-02-14T15:26:03+00:00

The runall commandline option was confusing people. There are in fact two different behaviours people may want. a) For a given target (or set of targets) look through the task graph and run task X only if its present and would have been built. b) For a given target (or set of targets) look through the task graph and run task X if any recipe in the taskgraph has such a target even if it wasn't in the original task graph. I've decided to interpret the existing "runall" option as b), even if right now if behaves like a). For a), which is a valid use case, this patch adds a "runonly" option. With both behaviours present, I'm hoping we can then kill off the "fetchall", "checkuriall" and other tasks from OE metadata and replace them with this option. This would significantly speed up task graph processing. (Deleting the checkuriall and fetchall tasks takes "bitbake core-image-sato -g" from 22s to 8s). (Bitbake rev: 546a662c877b2d3af35e3996950582ed2df41fe4) Signed-off-by: Richard Purdie

bitbake: main: Give a user readable error if we can't locate topdir

2017-10-31T09:09:21+00:00

Currently if you run bitbake in an invalid directory, the user experience is poor: birbake/lib/bb/main.py", line 427, in setup_bitbake topdir, lock = lockBitbake() File "./bitbake/lib/bb/main.py", line 494, in lockBitbake lockfile = topdir + "/bitbake.lock" TypeError: unsupported operand type(s) for +: 'NoneType' and 'str' This ensures we exit straight away with a better error message. [YOCTO #12163] (Bitbake rev: 562f9ee674a8b392437096422b9cceab9c3cba2e) Signed-off-by: Richard Purdie

bitbake: cookerdata/taskdata/runqueue: Drop remaining tryaltconfigs code and commandline option

2017-09-01T23:52:10+00:00

I can't actually see how this was working, nothing connected the commandline option to the data in TaskData(). Drop the remaining pieces of this option, it was a relic from a decade ago and we want deterministic builds, not random tries until something might work. (Bitbake rev: 767c7ba8fc76ec667ac1567de1c971c3575f2ecd) Signed-off-by: Richard Purdie

bitbake: main: Attempt to gain bitbake.lock rather than just waiting

2017-08-24T12:48:40+00:00

Rather than just waiting for 5s, try and get the lockfile. If we gain the lock, we know we're ready to retry and can skip any remaining timeout. (Bitbake rev: 8a60106c6f7d586c793b965c5e9460b6016fab15) Signed-off-by: Richard Purdie

bitbake: process: Clean up connection retry logic

2017-08-24T12:48:40+00:00

Its possible for a connection to connect to the server as its shutting down but before its removed the socket file. This patch: a) Removes the socket file earlier to avoid connections. b) Handles EOFError in initial connections gracefully. These occur if the socket is closed during the server shutdown. c) Ensure duplicate events aren't shown on the console. This makes debugging these issues very very confusing. With these changes the backtrace that was concerning users is hidden and the server works as expected with a reconnect when it catches it in a bad state. (Bitbake rev: f45196cf84669723382730944dddc7eaf50826f2) Signed-off-by: Richard Purdie

bitbake: main: Handle BB_SERVER_TIMEOUT = -1 for no server timeout

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

Make BB_SERVER_TIMEOUT = -1 mean no unload forever. (Bitbake rev: 923d5567be6fd9969ca74c166f36817ec09305e3) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie

bitbake: main: Remove unneeded float()

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

There is already a type=float, so the float() is not needed, which also makes the error clearer: $ export BB_SERVER_TIMEOUT=10000AA With float(): $ bitbake quilt-native [snip] ValueError: could not convert string to float: '10000AA' Without float(): $ bitbake quilt-native [snip] optparse.OptionValueError: option --idle-timeout: invalid floating-point value: '10000AA' The second one tells clearly where is wrong. (Bitbake rev: 7a4ea1e6a10f20d80009a78f4f0aebf8f90095fd) Signed-off-by: Robert Yang 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: main: Always return 0 for bitbake --kill-server

2017-07-30T07:43:36+00:00

If the server isn't running return 0 as to do otherwise complicates scripts which do cleanup of bitbake servers which would potentially be memory resident. (Bitbake rev: 0f85c54385f325f3ebbf911b35bbac11b8863b6b) Signed-off-by: Richard Purdie

bitbake: bb/main.py: fix logic for --observe-only

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

Fixed: $ bitbake --observe-only FATAL: '--observe-only' can only be used by UI clients connecting to a server. And even: $bitbake --observe-only -B localhost:-1 FATAL: '--observe-only' can only be used by UI clients connecting to a server. This was beucase the brackets were in a wrong position. (Bitbake rev: 4ffc91a2b3eb13e98078e6b1913f056a0c1797bc) Signed-off-by: Robert Yang Signed-off-by: Richard Purdie