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

bitbake: Force parser shutdown after catching an exception

2021-03-24T22:48:12+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: 5d02c98489d3a5836676b9c3fb3bd0157449db2b) Signed-off-by: Jan Brzezanski Signed-off-by: Richard Purdie (cherry picked from commit 915330e1dbae1ee8fd9a0358decf2c294f771961) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

bitbake: runqueue: Add setscene task overlap sanity check

2021-03-24T14:36:17+00:00

We've seen hard to debug issues where a task ends up in both the covered and notcovered list. Add a sanity check to ensure if this happens in future, we see it in the logs. (Bitbake rev: 947c2ad65e4c59d01c603f767f11f9aa86b69264) Signed-off-by: Richard Purdie (cherry picked from commit 6e001410854792f9bb66a0409a2ac176171b0507) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: runqueue: Fix task execution corruption issue

2021-03-24T14:36:17+00:00

We've seen occasional issues where linux-yocto:do_compile_kernelmodules would run without do_shared_workdir running before it. do_shared_workdir is an setscene task but never has an sstate object generated so it will always rerun. This should not happen since compile_kernemodules should only execute if a setscene that depends on it didn't run and that should trigger do_shared_workdir not to be marked as covered. The issue is that build-appliance-image:do_package is one of the tasks which covers linux-yocto:do_compile_kernelmodules but it is also a noexec task and has a dependecy on pseudo-native:do_populate_sysroot. In the problem case, pseudo-native:do_populate_sysroot is unavailable but marked as covered since it is noexec. The "harddeps" code then also marks it as notcovered. No task should ever be both covered and notcovered and this is where the problems come from. The solution is for the harddeps code only to to fail tasks if they've not already been handled in some way. The code is assuming code couldn't have handled revdeps at this point but we now have clear evidence they can. (Bitbake rev: 0a61f86a8da5356ce0d894ef2ffb96ac6a219db5) Signed-off-by: Richard Purdie (cherry picked from commit f66556bbb38449789ceea2fd105e9f68df7fb660) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: init.py: Fix bitbake debug log handling

2021-03-09T00:04:01+00:00

For a while I've been puzzled as to why debug logging from runqueue wouldn't appear on the console with -DD. The logic in the bbdebug handling is inverted so fix it and now we see the expected messages from runqueue with -D and -DD. This should then let us debug other issues using those log messages. (Bitbake rev: 7a6517243dbfecfd78f82f6709fbeaab2fb03e2c) Signed-off-by: Richard Purdie

bitbake: lib/bb/fetch2/init.py: drop _PYTHON_SYSCONFIGDATA_NAME unsetting

2021-02-11T17:49:22+00:00

With introduction of python3targetconfig class in core this is no longer needed. (Bitbake rev: 0a3bf681530bd63fc0036ca81ef868ab53fde56c) Signed-off-by: Alexander Kanavin Signed-off-by: Richard Purdie (cherry picked from commit 47b64cfacd7c498ef9ed5486d117f2d69a39f225) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

bitbake: fetch/git: download LFS content too during do_fetch

2021-02-02T15:51:56+00:00

Insert an explicit pass to fetch all blobs needed by Git LFS, during the fetch() function. This avoids the default behavior of Git LFS to wait until 'git checkout' to begin downloading the blobs pointed to by LFS records. Network access is not allowed at that point in the recipe's lifecycle. [YOCTO #14191] (Bitbake rev: c73f8f2f4a6491c6bea54839630af6994c27ad24) Signed-off-by: Matt Hoosier Signed-off-by: Richard Purdie (cherry picked from commit 0efac66043662e7a2027192f50e92e982db2ba1c) Signed-off-by: Anuj Mittal Signed-off-by: Richard Purdie

bitbake: data_smart: Ensure hash reflects vardepvalue flags correctly

2021-01-26T15:45:09+00:00

The get_hash() function is used to decide if the base configuration has changed and hence whether a reparse is required. The vardepvalue flag's value was not expanded but it is often used in contexts like: METADATA_REVISION = "${@base_detect_revision(d)}" METADATA_REVISION[vardepvalue] = "${METADATA_REVISION}" which in it's unexpanded form means reparsing doesn't happen when it should as the data appears unchanged. Update get_hash to expand the values of vardepvalue so reparsing works as expected. This avoids basehash mismatch errors such as the one recently caused by using METADATA_REVISION in poky.conf's DISTRO_VERSION variable. The issue there could be exposed by a recipe using DISTRO_VERSION with the sequence: bitbake os-release bitbake os-release -C install which was caused because METADATA_REVISION changed but the metadata didn't reparse. (Bitbake rev: cb7277e7bb3a440968fdb918d56fe8fa17bca2e6) Signed-off-by: Richard Purdie

bitbake: Add missing documentation Makefile

2020-11-24T09:10:58+00:00

Signed-off-by: Richard Purdie

bitbake: main: Handle cooker daemon startup error

2020-10-26T22:12:42+00:00

On startup, bitbake spawns a cooker daemon and waits for it's acknowledgement signal. If the acknowledgement doesn't happen in time,the bitbake object will fail to initialize and exit. The error that occurs in this case isn't handled by the existing try - catch block because SystemExit inherits from a different base Exception class. This commit adds SystemExit to the list of expected bitbake server startup errors. [YOCTO #13993] (Bitbake rev: fec2b85689bba1d26ad6f376bc11cc29bb27cbe5) Signed-off-by: Stacy Gaikovaia Signed-off-by: Richard Purdie

bitbake: tests/fetch: Update upstream master->main branchname transition

2020-10-26T22:06:37+00:00

(Bitbake rev: 8b9471e02528320f6ef8d35840b5618883e85447) Signed-off-by: Richard Purdie