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

bitbake: gitsm: Fix regression in gitsm submodule path parsing

2022-12-09T13:02:50+00:00

Commit 0361ecf7eb82c386a9842cf1f3cb706c0a112e77 introduced regression in submodules path parsing. As the result gitsm fetcher fails on each submodule which name begins from the name of the parent repo which is totally valid usecase [Yocto #14045] [1] Fix the code to error out only if submodule's name is equal to parent name but not if it's part of it. [1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=14045#c4 (Bitbake rev: 7e268c107bb0240d583d2c34e24a71e373382509) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie (cherry picked from commit 3ad27272c18f2bb9edd441f840167a3dabd5407b) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: runqueue: Fix race issues around hash equivalence and sstate reuse

2022-11-24T15:25:19+00:00

We identified a use case where a native recipe (autoconf-native) was rebuilt with no change in output yet the sstate for do_package tasks wasn't being used. The issue is that do_package tasks have a hard dependency on pseudo-native:do_populate_sysroot. That task was one of the many tasks being rehashed when autoconf-native's hash was changed. If update_tasks processed a recipe before it had processed pseudo-native, that recipe would be marked as not possible from sstate and would run the full tasks. The fix is to split the processing into two passes, first to handle the existing covered/notcovered updates, then in the second pass, check whether there are "harddep" issues. This defers the do_package tasks until after pseudo-native is installed from sstate as expected and everything works well again. (Bitbake rev: 72a3afd99e8b785cb2a2f687e71a58e08cdd9c74) Signed-off-by: Richard Purdie (cherry picked from commit e479d1e418a7d34f0a4663b4a0e22bb11503c8ab) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: tests/fetch: Allow handling of a file:// url within a submodule

2022-10-27T15:39:20+00:00

CVE-2022-39253 in git meant file:// urls within submodules were disabled. Add a parameter to the commands in the tests to allow this to continue to work. (Bitbake rev: c90d57497b9bcd237c3ae810ee8edb5b0d2d575a) Signed-off-by: Richard Purdie

bitbake: asyncrpc/client: Fix unix domain socket chdir race issues

2022-10-11T20:57:28+00:00

The connect_unix() call had a bug where if a relative path to a socket was passed (which the non-async client always does), and the current working directory was changed after the initial call, it would fail to reconnect if it became disconnected, since the socket couldn't be found relative to the new current working directory. To work around this, change the socket connection for UNIX domain sockets to be synchronous and change current working before connecting. This isn't ideal since the connection could block the entire event loop, but in practice this shouldn't happen since the socket are local files anyway. Help debugging and resolving from Joshua Watt. (Bitbake rev: 6603c3e39f1cf746669ec6c9f0be8c6e6ece426e) Signed-off-by: Richard Purdie (cherry picked from commit 5964bb67bb20df7f411ee0650cf189504a05cf25) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: gitsm: Error out if submodule refers to parent repo

2022-10-11T20:57:28+00:00

If submodule refers to specific revision of the parent repository it causes deadlock in bitbake locking mechanism (lock is acquired to fetch the parent and cannot be released before all submodules are fetched). raise FetchError in such situation to prevent deadlocking. [Yocto 14045] (Bitbake rev: 987712c4c8fefd86a1f5116c11ee86e296e852ee) Signed-off-by: Pavel Zhukov Signed-off-by: Richard Purdie (cherry picked from commit 0361ecf7eb82c386a9842cf1f3cb706c0a112e77) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: Fix npm to use https rather than http

2022-10-11T20:57:28+00:00

Hit this error while building nlf-native recently: { "error": { "summary": "URI malformed", "detail": "" } } Some poking about led me to discover that: 1) The npm.py tool replaces npm:// with http://, not https:// 2) Some versions of the npm tool don't handle 301 redirects properly, choosing to display the above error instead when using the default nodejs registry It would be good to go fix npm to handle the redirect properly, but it seems like it would also be good to assume secure http when contacting a registry, hence, this patch (Bitbake rev: bb5c43220f5f1c3d82334c65aff1ce13008db8d9) Signed-off-by: Neil Horman Signed-off-by: Richard Purdie (cherry picked from commit 2cd76e8aabe4e803c760e60f06cfe1f470714ec7) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: bitbake: Add copyright headers where missing

2022-10-11T20:57:28+00:00

Where copyright headers were not present, add them to make things clear. (Bitbake rev: e591325b2bd901c381003deb96a7b32a7148e93e) Signed-off-by: Richard Purdie (cherry picked from commit 1aa338a216350a2751fff52f866039343e9ac013) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: siggen: Fix insufficent entropy in sigtask file names

2022-10-11T20:57:28+00:00

Signature generation uses mkstemp() to get a file descriptor to a unique file and then write the signature into it. However, the unique file name generation in glibc is based on the system timestamp, which means that with highly parallel builds it is more likely than one might expect expected that a conflict will occur between two different builder nodes. When operating over NFS (such as a shared sstate cache), this can cause race conditions and rare failures (particularly with NFS servers that may not correctly implement O_EXCL). The signature generation code is particularly susceptible to races since a single "sigtask." prefix used for all signatures from all tasks, which makes collision even more likely. To work around this, add an internal implementation of mkstemp() that adds additional truly random entropy to the file name to eliminate conflicts. (Bitbake rev: 63bb5591e833de0e7b552963ad9bc4b39e56fda9) Signed-off-by: Joshua Watt Signed-off-by: Luca Ceresoli (cherry picked from commit 97955f3c1c738aa4b4478a6ec10a08094ffc689d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: runqueue: Drop deadlock breaking force fail

2022-10-11T20:57:28+00:00

I'm 99% certain this failing of a scenequeue task corrupts runqueue and causes all kinds of breakage. I'd rather runqueue deadlocked than corrupted and did weird things so drop this code. We've seen builds where the deadlock triggers and it then tries to run tasks where the SQ task already ran with very confusing failures. It is likely it is this code causing it. (Bitbake rev: f386298fc056ef130c2eb6dabf25eafbd55f55ca) Signed-off-by: Richard Purdie (cherry picked from commit 8efced47fcb47851a370fd6786df6fb377f99963) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie

bitbake: runqueue: Improve deadlock warning messages

2022-10-11T20:57:28+00:00

Tweak the deadlock breaking messages to be explict about which task is blocked on which other task. The messages currently imply it is "freeing" the blocking task which is confusing. (Bitbake rev: d1b84e3cfe9fb8d282d4b700a9fe31891e00d837) Signed-off-by: Richard Purdie (cherry picked from commit cf7f60b83adaded180f6717cb4681edc1d65b66d) Signed-off-by: Steve Sakoman Signed-off-by: Richard Purdie