[OE-core] [PATCH 1/3] sbom30.py: reduce redundant spdxid-hash symlinks to save inode on host

2024-11-09 Thread hongxu via lists.openembedded.org
In order to support all in-scope SPDX data within a single JSON-LD file for SPDX 3.0.1, Yocto's SBOM: - In native/target/nativesdk recipe, created spdxid-hash symlink for each element to point to the JSON-LD file that contains element details; - In image recipe, use spdxid-hash symlink to colle

[OE-core] [PATCH 2/3] sbom30.py: use file-license-relationship as spdxid_name of hasDeclaredLicense relationship

2024-11-09 Thread hongxu via lists.openembedded.org
In order to distinguish the spdxId of hasDeclaredLicense relationship with other relationship, use file-license-relationship as spdxid_name, and filter it out for spdxid-hash symlink creation While SPDX_INCLUDE_SOURCES = "1", N hasDeclaredLicense's Relationship for N source files in one recipe wil

[OE-core] [PATCH 3/3] oeqa/selftest: Add SPDX 3.0 include source cases for core_image_minimal build

2024-11-09 Thread hongxu via lists.openembedded.org
$ oe-selftest -r spdx.SPDX30Check.test_core_image_minimal_include_source 2024-11-09 09:17:54,600 - oe-selftest - INFO - Adding layer libraries: 2024-11-09 09:17:54,601 - oe-selftest - INFO - path-to/poky/meta/lib 2024-11-09 09:17:54,601 - oe-selftest - INFO - path-to/poky/meta-yocto-bsp/lib 2024-

[OE-core][scarthgap][PATCH] gstreamer1.0: set status for CVE-2024-0444

2024-11-09 Thread Peter Marko via lists.openembedded.org
From: Peter Marko This is patched in gstreamer1.0-plugins-bad in 1.22 branch since 1.22.9 via [1]. cpe product is set to gstreamer, they share source git repository. [1] https://gitlab.freedesktop.org/gstreamer/gstreamer/-/commit/394d5066f8a7b728df02fe9084e955b2f7d7f6fe Signed-off-by: Peter Ma

[OE-core][kirkstone][PATCH] gstreamer1.0: ignore CVE-2024-0444

2024-11-09 Thread Peter Marko via lists.openembedded.org
From: Peter Marko This CVE is patched in gstreamer1.0-plugins-bad. cpe product is set to gstreamer, they share source git repository. Signed-off-by: Peter Marko --- meta/recipes-multimedia/gstreamer/gstreamer1.0_1.20.7.bb | 3 +++ 1 file changed, 3 insertions(+) diff --git a/meta/recipes-mult

[OE-core] [meta-oe][PATCH] curl: upgrade 8.10.1 -> 8.11.0

2024-11-09 Thread Peter Marko via lists.openembedded.org
From: Peter Marko Solves CVE-2024-9681 * refresh patch * add patch for buildpaths issue * add new options for ipfs and websockets, keep them configure as they were previously configures * drop notexists.pl from ptest install as it was removed and code was integrated into the test framework i

Re: [OE-core] Question: Need advise with providing native Bluetooth sockets for Python

2024-11-09 Thread Guðni Már Gilbert via lists . openembedded . org
Adding this to bluez5 bbappend: PACKAGECONFIG:class-native = "" BBCLASSEXTEND = "native" And to python3 bbappend: DEPENDS:append:class-target = " ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 'bluez5-native', '', d)}" Seems to do the trick. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all

Re: [OE-core] [PATCH RESEND v3] reproducibility: continue testing in case of build failure

2024-11-09 Thread Yoann Congal via lists.openembedded.org
Le 04/11/2024 à 12:25, Yoann Congal a écrit : > Hi, > > > Le 29/10/2024 à 11:09, Yoann Congal a écrit : >> From: Yoann Congal >> >> The current reproducibility test stops all build tasks when a single >> task fails (default BitBake behavior). This means that a single build >> failure prevents th

Re: [OE-core] Question: Need advise with providing native Bluetooth sockets for Python

2024-11-09 Thread Guðni Már Gilbert via lists . openembedded . org
Hmm I found this in BlueZ README, it suggests creating a separate package. If no one is against that idea I will try to create it and submit a patch. --enable-library Enable installation of Bluetooth library By default the Bluetooth library is no longer installed. The user interfaces or command l

[OE-core] Question: Need advise with providing native Bluetooth sockets for Python

2024-11-09 Thread Guðni Már Gilbert via lists . openembedded . org
Hi everyone, I am upgrading a project from Scarthgap to Styhead and am facing a problem again which I somewhat solved before though not properly. And now I want to fix it for good and hopefully have the solution upstream too. The problem: I have a Python application which needs bluetooth.h head

[OE-core][kirkstone][PATCH] curl: patch CVE-2024-9681

2024-11-09 Thread Peter Marko via lists.openembedded.org
From: Peter Marko Picked commit [1] per solution described in [2]. [1] https://github.com/curl/curl/commit/a94973805df96269bf [2] https://curl.se/docs/CVE-2024-9681.html Signed-off-by: Peter Marko --- .../curl/curl/CVE-2024-9681.patch | 85 +++ meta/recipes-support

[OE-core][scarthgap][PATCH] curl: patch CVE-2024-9681

2024-11-09 Thread Peter Marko via lists.openembedded.org
From: Peter Marko Picked commit [1] per solution described in [2]. [1] https://github.com/curl/curl/commit/a94973805df96269bf [2] https://curl.se/docs/CVE-2024-9681.html Signed-off-by: Peter Marko --- .../curl/curl/CVE-2024-9681.patch | 85 +++ meta/recipes-support

[OE-core] [PATCH] lttng-ust: backport patch to fix cmake-multiple-shared-libraries build error

2024-11-09 Thread Bin Lan via lists.openembedded.org
There are the following error when building doc/examples/cmake-multiple-shared-libraries: ld: warning: liblttng-ust-common.so.1, needed by lttng-ust/2.13.8/build/src/lib/lttng-ust/.libs/liblttng-ust.so, not found (try using -rpath or -rpath-link) ld: warning: liblttng-ust-tracepoint.so.1, needed