linux/poky.git/bitbake, branch 5.0_M3

bitbake: utils: remove BB_ENV_PASSTHROUGH from preserved_envvars()

2024-03-05T12:25:08+00:00

preserved_envvars() is used when the BB_ENV_PASSTHROUGH environment variable is not set. Therefore, its code shouldn't return this variable. (Bitbake rev: 0a33b560233b983456178541603ab96fea22238b) Signed-off-by: Michael Opdenacker Reported-by: Robert P. J. Day Tested-by: Michael Opdenacker Signed-off-by: Richard Purdie

bitbake: prserv/serv: Fix a PID file removal race on prserv stop

2024-03-03T16:26:17+00:00

A race condition has happened where the exiting server removed the PID file between the existence check and the removal, resulting in a FileNotFoundError exception. The fix is to ignore the FileNotFoundError exception, the existence check is now redundant so remove it to simplify. Fixes [YOCTO #14341] (Bitbake rev: 40d00bf9308e0bf73a00134a99a012a292daa1c5) Signed-off-by: Yoann Congal Signed-off-by: Richard Purdie

bitbake: fetch/git: Avoid clean upon failure

2024-03-03T16:26:17+00:00

Currently when git fetches fail, it destroys all the existing local clone data. For large repositories this can introduce long build delays when for example, you just typo'd the git revision hash. The git fetcher should be able to recover most directories so when the fetch is for a git repo, avoid removing things unless clean is explicitly called (e.g. a -c cleanall task). (Bitbake rev: 1b3cd039fe19b24bd4be9a0202a98cdcbb0e9443) Signed-off-by: Richard Purdie

bitbake: taskexp_ncurses: fix execution example in introductory comment

2024-02-28T09:21:48+00:00

Drop the ".py" file extension from the "-u" option's argument that has been overlooked while applying the original patch (see [1]) to make the example work. While at it sort the recipes' names consistently with respect to what is found in the self-test examples below. [1] https://lore.kernel.org/bitbake-devel/6f2645a7c4db2ae149d387544d2b94209cfed3f4.camel@linuxfoundation.org/ (Bitbake rev: 1f4d517b7a0389f78d1f791135f8dc9120e9912b) Signed-off-by: Ulrich Ölmann Signed-off-by: Richard Purdie

bitbake: asyncrpc: Add support for server headers

2024-02-27T11:36:38+00:00

Adds support for asyncrpc servers to send connection headers to clients on connection. Since this is a breaking protocol change, clients must opt-in to expect headers from the server, corresponding to a version bump in the client protocol. (Bitbake rev: 1cb2b8be6cc5269553f549285592e47b7d29db03) Signed-off-by: Joshua Watt Signed-off-by: Richard Purdie

bitbake: layerindexlib: fix missing layer branch backtrace

2024-02-27T11:36:38+00:00

When a LayerBranch (a specific layer at a specific release) does not exist in the layerindex database ("Layerindex Metadata"), the dependency would throw a backtrace. Instead fail early and provide an error message. Since layerindexlib will also check the local layers, inform the user that a local checkout might resolve the situation. Recommend that they reach out to the layer maintainers and layer index admins to properly fix it for everyone. While we are here, remove some trailing whitespace. [YOCTO #15365] [YOCTO #13954] (Bitbake rev: 96cbe8f87209a927c157ebcf469f8b9d54fcf92e) Signed-off-by: Tim Orling Signed-off-by: Richard Purdie

bitbake: fetch2: Ensure that git LFS objects are available

2024-02-23T14:34:05+00:00

The current implementation only performs a git lfs fetch alongside of a regular git fetch. This causes issues when the downloaded revision is already part of the fetched repository (e.g. because of moving back in history or the updated revision already being part of the repository at the time of the initial clone). Fix this by explicitly checking whether the required LFS objects are available in the downloade directory before confirming that a downloaded repository is up-to-date. This issue previously went unnoticed as git lfs would silently fetch the missing objects during the `unpack` task. With network isolation turned on, this no longer works, and unpacking fails. (Bitbake rev: cfae1556bf671acec119a6c8bbc4b667a856b9ae) Signed-off-by: Philip Lorenz Signed-off-by: Richard Purdie

bitbake: bitbake: progressbar: accept value over initial maxval

2024-02-23T14:34:05+00:00

There is a very rare case where the maxval is improperly computed initially for cache loading progress, and the value will go over. Explanation from bitbake/lib/bb/cache.py:736 in MulticonfigCache:__init__:progress() # we might have calculated incorrect total size because a file # might've been written out just after we checked its size In that case, progressbar will receive a value over the initial maxval. This results in a ValueError stack trace as well as bitbake returning 1. Traceback (most recent call last): File ".../poky/bitbake/lib/bb/ui/knotty.py", line 736, in main cacheprogress.update(event.current) File ".../poky/bitbake/lib/progressbar/progressbar.py", line 256, in update raise ValueError('Value out of range') ValueError: Value out of range This fix mirrors the behavior of MulticonfigCache and accepts the new value as the new maxval. This is also what the percentage printout is doing in bitbake/lib/progressbar/progressbar.py:191 in ProgressBar:percentage() I encountered this issue randomly while working on a project with VSCode saving files while commands where fired. Note: This file is a fork from python-progressbar. It hasn't been refreshed in 8 years. We did only two commits, 5 years ago with minor modifications. This new change is also not how the upstream project is behaving. (Bitbake rev: 7cea7f7a87da041fc1ad370c5c3d15aabad3a0d4) Signed-off-by: Enguerrand de Ribaucourt Signed-off-by: Richard Purdie

bitbake: runqueue: Add support for BB_LOADFACTOR_MAX

2024-02-23T14:34:05+00:00

Some ditros don't enable /proc/pressure and it tends to be those which we see bitbake timeout issues on, seemingly as load gets too high and the bitbake processes don't get scheduled in for minutes at a time. Add support for stopping running extra tasks if the system load average goes above a certain threshold by setting BB_LOADFACTOR_MAX. The value used is scaled by CPU number, so a value of 1 would be when the load average equals the number of cpu cores of the system, under one only starts tasks when the load average is below the number of cores. This means you can centrally set a value such as 1.5 which will then scale correctly to different sized machines with differing numbers of CPUs. The pressure regulation is probably more accurate and responsive, however our graphs do show singificant load spikes on some workers and this patch is aimed at trying to avoid those. Pressure regulation is used where available in preference to this load factor regulation when both are set. (Bitbake rev: 14a27306f6dceb4999c2804ccae5a09cc3d8dd49) Signed-off-by: Richard Purdie

bitbake: hashserv: Re-enable connection pooling with psycopg 3 driver

2024-02-23T14:34:05+00:00

Re-enable connection pooling in case `postgresql+psygopg` driver is used. Async connection pooling is supported in psycopg 3 [psycopg] driver in SQLAlchemy. Allow the connection pool to grow to arbitrary size. (Bitbake rev: 4fe05513b5314c201725e3f8ad54f58d70c56258) Signed-off-by: Tobias Hagelborn Signed-off-by: Richard Purdie