linux/poky.git/bitbake, branch yocto-3.2.4Mirror of git.yoctoproject.org/pokyhttps://git.enea.com/cgit/linux/poky.git/atom?h=yocto-3.2.42021-05-04T22:11:04+00:00bitbake: fetch/gitsm: Fix crash when using git LFS and submodules2021-05-04T22:11:04+00:00Niels Avondsniels@codebits.be2021-05-03T14:35:54+00:00urn:sha1:b492191d87b080304a9d4f2efe0f7c377f6f9438
Gitsm fetcher crashes when cloning a repository that contains LFS files.
This happens because the unpack method is called during download, but the
submodules have not been downloaded yet at this point.
This issue was introduced in this
commit: 977b7268bf4fd425cb86d4a57500350c9b829162
[YOCTO #14283]
(Bitbake rev: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8)
Signed-off-by: Niels Avonds <niels@codebits.be>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 26caedc4d2e9b5a0f1d57f9291754a7f6c5e437e)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: runqueue: Fix deferred task issues2021-05-04T22:11:04+00:00Richard Purdierichard.purdie@linuxfoundation.org2021-05-03T14:35:52+00:00urn:sha1:78c99742b8dd9ae663bfcac8e514069cf11e8d44
In a multiconfig situation there are circumstances where firstly, tasks
are deferred when they shouldn't be, then later, tasks can end up as
both covered and not covered.
This patch fixes two related issues. Firstly, the stamp validity checking
is done up front in the build and not reevaulated. When rebuilding the
deferred task list after scenequeue hash change updates, we need therefore
need to check if a task was in notcovered *or* covered when deciding to
defer it. This avoids strange logs like:
NOTE: Running setscene task X of Y (mc:initrfs_guest:/A/alsa-state.bb:do_deploy_source_date_epoch_setscene)
NOTE: Deferring mc:initrfs_guest:/A/alsa-state.bb:do_deploy_source_date_epoch after mc:host:/A/alsa-state.bb:do_deploy_source_date_epoch
where tasks have run but are then deferred.
Since we're recalculating the whole list, we also need to clear it before
iterating to rebuild it. By ensuring covered tasks aren't added to the
deferred queue, the covered + notcovered issue should also be avoided.
in the task deadlock forcing code.
[YOCTO #14342]
(Bitbake rev: 32183076cb54f6d247471429cfd99491e41a1cab)
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 3c8717fb9ee1114dd80fc1ad22ee6c9e312bdac7)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: bitbake-server: ensure server timeout is a float2021-05-04T22:11:04+00:00Ross Burtonross@burtonini.com2021-05-03T14:35:53+00:00urn:sha1:d583c78d87a16ba7e06da69104da896c79c3a332
bitbake-server is spawned by process.py and passes the arguments it is
given to ProcessServer. There's some type confusion here:
bitbake-server is called with a string representation of the timeout,
which may be None. If the timeout is not set, pass 0 instead of None.
Inside bitbake-server a ProcessServer is created which expects the
timeout to be a float not a string, so always float() the value.
[ YOCTO #14350 ]
(Bitbake rev: 95cc877f3bf5ef2513d7af0ae424f78ec7c24f7d)
Signed-off-by: Ross Burton <ross.burton@arm.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit c93ae1f861208f6d39fd15c84fbcd0e2b54331f5)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: cooker: Include all packages a recipe provides in SkippedPackage.rprovides2021-04-27T14:22:40+00:00Peter Kjellerstedtpeter.kjellerstedt@axis.com2021-04-26T07:30:03+00:00urn:sha1:008f22924921fb46cb38c0c2f8a85f79289bf7bb
The provided packages by a skipped recipe are supposed to be listed in
SkippedPackage.rprovides, which is used when generating a meaningful
error message when a build fails because of a skipped package.
Previously this variable only contained the contents of ${RPROVIDES}.
However, most recipes don't define RPROVIDES, they define
RPROVIDES_<pkg> for each package they provide. Additionally, the recipe
provides the packages in PACKAGES without them being included in
${RPROVIDES}.
Before this change, having a runtime dependency on a skipped non-recipe
package would result in a build error stating that the build failed
because the package was skipped, but without providing any reason for
why it was skipped.
(Bitbake rev: 7b7d7b02faedb603d81144a134e80027e4019ab0)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: cache: Make CoreRecipeInfo include rprovides_pkg for skipped recipes2021-04-27T14:22:40+00:00Peter Kjellerstedtpeter.kjellerstedt@axis.com2021-04-26T07:30:02+00:00urn:sha1:580089c76234f04ac046318fe5f9da65aacab9af
This will be needed by SkippedPackage in the cooker.
(Bitbake rev: 1026b2d29340945608111d19ac5c31f0fcf91851)
Signed-off-by: Peter Kjellerstedt <peter.kjellerstedt@axis.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: Force parser shutdown after catching an exception2021-03-24T22:48:12+00:00Jan Brzezanskijan.brzezanski@gmail.com2021-03-24T14:33:07+00:00urn:sha1:867a2067b29d54978a307691aa9081a77e533cc2
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 <jan.brzezanski@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 915330e1dbae1ee8fd9a0358decf2c294f771961)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: runqueue: Add setscene task overlap sanity check2021-03-24T14:36:17+00:00Richard Purdierichard.purdie@linuxfoundation.org2021-03-08T15:54:56+00:00urn:sha1:0ddc879d61bb3e8b38e1181f4e4392b6c2122c2e
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 <richard.purdie@linuxfoundation.org>
(cherry picked from commit 6e001410854792f9bb66a0409a2ac176171b0507)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: runqueue: Fix task execution corruption issue2021-03-24T14:36:17+00:00Richard Purdierichard.purdie@linuxfoundation.org2021-03-08T15:44:58+00:00urn:sha1:b1cfaaa574a1bfec1de0d85a5b5df58ad9511a54
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 <richard.purdie@linuxfoundation.org>
(cherry picked from commit f66556bbb38449789ceea2fd105e9f68df7fb660)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
bitbake: __init__.py: Fix bitbake debug log handling2021-03-09T00:04:01+00:00Richard Purdierichard.purdie@linuxfoundation.org2021-03-02T22:24:33+00:00urn:sha1:b87671882300ee8f0b613d8c37b274a0f2aae6dc
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 <richard.purdie@linuxfoundation.org>
bitbake: lib/bb/fetch2/__init__.py: drop _PYTHON_SYSCONFIGDATA_NAME unsetting2021-02-11T17:49:22+00:00Alexander Kanavinalex.kanavin@gmail.com2021-02-09T15:56:54+00:00urn:sha1:41244407a0b7000b902c3c91810a8b27ea45b085
With introduction of python3targetconfig class in core this is no longer
needed.
(Bitbake rev: 0a3bf681530bd63fc0036ca81ef868ab53fde56c)
Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
(cherry picked from commit 47b64cfacd7c498ef9ed5486d117f2d69a39f225)
Signed-off-by: Anuj Mittal <anuj.mittal@intel.com>
Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>