linux/poky.git/bitbake, branch yocto-4.0.16

bitbake: asyncrpc: Add context manager API

2024-01-10T15:14:16+00:00

Adds context manager API for the asyncrcp client class which allow writing code that will automatically close the connection like so: with hashserv.create_client(address) as client: ... Rework the bitbake-hashclient tool and PR server to use this new API to fix warnings about unclosed event loops when exiting (Bitbake rev: ee090484cc25d760b8c20f18add17b5eff485b40) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie (cherry picked from commit d01d684a0f6398270fe35ed59b7d28f3fd9b7e41) Signed-off-by: Steve Sakoman

bitbake: lib/bb: Add workaround for libgcc issues with python 3.8 and 3.9

2024-01-04T15:00:12+00:00

With python 3.8 and 3.9, we see intermittent errors of: libgcc_s.so.1 must be installed for pthread_cancel to work Aborted (core dumped) which seem related to: https://stackoverflow.com/questions/64797838/libgcc-s-so-1-must-be-installed-for-pthread-cancel-to-work https://bugs.ams1.psf.io/issue42888 These tend to occur on debian 11 and ubuntu 20.04. Workaround this by ensuring libgcc is preloaded in all cases. (Bitbake rev: 2c6183594279e2e9d03f11155ad969448869c863) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: data: Add missing dependency handling of remove operator

2024-01-04T15:00:12+00:00

A recipe variable handles its dependencies even on the "contains" variables within the "inline Python expressions" like bb.utils.filter(). And it also handles those in the append operator correctly, but the problem is that it does not so in the remove operator. Fix it by adding the missing dependencies every time the remove operator has been handled. Also add a test case to check if the override operators handle dependencies correctly. (Bitbake rev: 23639edfbbb3fced7606dce211db8a31c5766585) Signed-off-by: Insu Park Signed-off-by: Richard Purdie Cherry-picked from master: b90520eedb1dbc7f6a3928d089fe74fafb864eb5 - Conflicts in data.py are resolved as the master branch moved handle_contains() and handle_remove() out of the try block. - The test code in codeparser.py are modified as the master branch added three more arguments to the build_dependencies(). Signed-off-by: Insu Park Signed-off-by: Steve Sakoman

bitbake: toastergui: verify that an existing layer path is given

2023-12-21T16:14:00+00:00

Verify that an existing layer path was given when adding a new layer. Manually using the shell for globbing is unnecessary, use the glob function instead for cleaner code. (Bitbake rev: de1cf0e31f3836a449cbd17490a2f6b6a86b17f9) Signed-off-by: Marta Rybczynska Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: show number of currently running bitbake threads when pressure changes

2023-12-11T16:13:49+00:00

* it might be a bit confusing as it shows number of threads before making the decision to start more tasks and also it can show only a few tasks running, but not because of pressure when there just aren't many tasks left or wait for their dependencies to be finished first * example output: NOTE: Pressure status changed to CPU: True, IO: None, Mem: None (CPU: 297589.5/200000.0, IO: 5522.2/None, Mem: 779.2/None) - using 7/8 bitbake threads NOTE: Pressure status changed to CPU: False, IO: None, Mem: None (CPU: 196381.2/200000.0, IO: 2667.9/None, Mem: 556.2/None) - using 2/8 bitbake threads (Bitbake rev: 42a1c9fe698a03feb34c5bba223c6e6e0350925b) Signed-off-by: Martin Jansa Signed-off-by: Steve Sakoman

bitbake: runqueue: show more pressure data

2023-12-11T16:13:49+00:00

* with latest bitbake I'm seeing very low number of bitbake tasks executed in parallel, probably due to pressure regulation show the values this is based on in the note * also simplify a bit by counting the pressure and exceeds signs only once (Bitbake rev: 1050145c3004861ebede4777fd4fbd89d0470716) Signed-off-by: Martin Jansa Signed-off-by: Steve Sakoman

bitbake: runqueue.py: fix PSI check logic

2023-12-11T16:13:49+00:00

The current calculation is not correct because if tdiff is less than 1.0, it's not taken into consideration when calculating the current pressure. Also, make it clear that the 1.0s is the psi accumulation cycle, which might be changed in the future. We have this cycle because it could largely avoid the 0 result issue, that is, if the interval between checks are too small, the result might be 0. With this accumulation logic, which has been there but let's make it clear, this 0 result problem could be mitigated. (Bitbake rev: 76889ff0a8938a3d77603d2af176aa9e264df839) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: Add pressure change logging

2023-12-11T16:13:49+00:00

It is currently hard to tell when bitbake is throttling task execution due to system pressure changes. Add notes to the console output to make this clearer, only generating output when the values change. (Bitbake rev: b5f77e8159ad321f31999af8304f082a2c56b537) Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: runqueue: fix PSI check calculation

2023-12-11T16:13:49+00:00

The current PSI check calculation does not take into consideration the possibility of the time interval between last check and current check being much larger than 1s. In fact, the current behavior does not match what the manual says about BB_PRESSURE_MAX_XXX, even if the value is set to upper limit, 1000000, we still get many blocks on new task launch. The difference between 'total' should be divided by the time interval if it's larger than 1s. (Bitbake rev: 2b2997ab6bdda730e4b638f416311a73e0c42156) Signed-off-by: Chen Qi Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman

bitbake: Fix disk space monitoring on cephfs

2023-11-09T14:41:17+00:00

Error occured while running bitbake on cephfs: WARNING: The free inode of path is running low (-0.001K left) ERROR: Immediately halt since the disk space monitor action is "HALT"! (Bitbake rev: a7f6c3e67bd9170e93b2b94676e84018faf0df91) Signed-off-by: Samantha Jalabert Signed-off-by: Richard Purdie Signed-off-by: Steve Sakoman