linux/poky.git/bitbake/lib/bb/cooker.py, branch dunfell-23.0.23

bitbake: cooker/command: Add a dummy event for tinfoil testing

2022-01-07T23:43:50+00:00

We need a command genetating an event to test through the tinfoil API. The current test has IO load issues so add a dummy version which won't have the IO constraints. (Bitbake rev: c5969eedd035648e3258bade386cc67ce3bb0e03) Signed-off-by: Richard Purdie (cherry picked from commit a144178584394ea0700ffc2f2bfac94e8690effc) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Ensure reparsing is handled correctly

2021-12-05T12:36:55+00:00

>From tinfoil, if you edit bblayers.conf and break it, then call parseConfiguration (e.g. by adding a bad layer with bitbake-layers), the system doens't show any parse error yet it should. Add in a call to the updateCache function so that things really are reparsed when requested. Partially fixes [YOCTO #14054] (Bitbake rev: a6ad6eaf4cddbe45077d1e6cb667f71602b8a49d) Signed-off-by: Richard Purdie (cherry picked from commit e655f9361b9c3b77906b8e06b5cc76bc5180640e) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: build/msg: Cleanup verbose option handling

2021-10-02T08:55:51+00:00

The levels of indirection to set these verbose logging options is rather crazy. This attempts to turn things into two specific options with much more specific meanings. For now its all still controlled by the commandline verbose option and should funciton as previously, with the addition that the BB_VERBOSE_LOGS option can now be task specific. (Bitbake rev: b4117231bf070703b9375af4411bcd160e07fdae) Signed-off-by: Richard Purdie (cherry picked from commit 423c046f2173aaff3072dc3d0882d01b8a0b0212) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Avoid parser deadlocks

2021-06-19T16:06:18+00:00

If you make parsing fail (e.g. add something like: X := "${@d.getVar('MCMACHINES').split()[1]}" to meson.bbclass, then run "while true; do bitbake -g bash; done" it will eventually hang. It appears the cancel_join_thread() call the parsing failure triggers, breaks the results_queue badly enough that it sits in read() indefintely (called from self.result_queue.get(timeout=0.25)). The timeout only applies to lock aquisition, not the read call. I've tried various other approaches such as using cancel_join_thread() in other places but the only way things don't lock up is to avoid cancel_join_thread() entirely for results_queue. I do have a concern that this may adversely affect Ctrl+C handling but equally, its broken now already and this appears to improve things. [YOCTO #14034] (Bitbake rev: 0e0af15b84e07e6763300dcd092b980086b9b9c4) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Ensure parser is cleaned up

2021-06-19T16:06:18+00:00

During cooker shutdown, its possible the parser isn't cleaned up. Fix this (which may partially explain why threads were left hanging around at exit). (Bitbake rev: fe1b57f4d39c287526353387e164c863eb9df421) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Explictly shut down the sync thread

2021-06-19T16:06:18+00:00

Hongxu Jia reported a problem where the bb_cache files were not always being written out correctly. This was due to the sync thread being terminated prematurely. Whilst the preceeding changes mean the exit handler for this thread is now correctly called since we switch to using sys.exit() instead of os._exit(), this write can happen after we drop the bitbake lock, leading to potential races. Avoid that headache by adding in explicit thread join() calls before we drop the lock (which atexit or Finalize can't do). (Bitbake rev: 6d2dd16b87ce62086f956912e9a7335b2adfcc94) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Ensure parse_quit thread is closed down

2021-06-19T16:06:18+00:00

Each run through the parser would leak a thread from the queue created to shut the parser down. Close this down correctly and clean up the code flow slightly whilst in the area, making sure this thread does shut down correctly (we don't care if it loses data). (Bitbake rev: 1dcc4e29dee3fd0dd4d6dc2fc9ccdc5888fcfcf3) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: Force parser shutdown after catching an exception

2021-04-06T21:45:36+00:00

Commit bebef58b21bdff7a3ee1fa2449b7df19144f26fd introduced forcing parser shutdown as default in case of build abort. In this case bitbake sometimes hangs after facing error during parsing, waiting for child processes to finish. Killing it then will spawn zombie processes. Thus we force the shutdown after catching an exception. (Bitbake rev: 017a39ed05d065bf28fd38f91bcde8a098300551) Signed-off-by: Jan Brzezanski Signed-off-by: Richard Purdie (cherry picked from commit 915330e1dbae1ee8fd9a0358decf2c294f771961) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: cooker: Handle multiconfig name mappings correctly

2020-07-23T15:51:07+00:00

"bitbake mc:arm:bash mc:arm:busybox" works but "bitbake multiconfig:arm:bash multiconfig:arm:busybox" does not. The reason is the list is modified whilst iterating. Don't do that. [YOCTO #13607] (Bitbake rev: cc11dfa4eb3616547a8a3909f89da0cc4f35dc57) Signed-off-by: Richard Purdie

bitbake: cooker: Respect multiconfig parameter

2020-03-07T16:07:00+00:00

The cooker had a multiconfig parameter for the findProviders() and findBestProviders() API, but it was being ignored. (Bitbake rev: ea0b68ac2b77676ed1c63f0ee1ae5d300f2b4696) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie