[OE-core][mickledore][PATCH 1/1] libx11: upgrade to 1.8.7
From: Ross Burton
This incorporates fixes for the following CVEs:
- CVE-2023-43785
- CVE-2023-43786
- CVE-2023-43787
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
(cherry picked from commit a1534bb34b680bfc5cb2f35b5fd5a0c2afed6368)
Signed-off-by: Yogita Urade
---
.../xorg-lib/{libx11_1.8.6.bb => libx11_1.8.7.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/xorg-lib/{libx11_1.8.6.bb => libx11_1.8.7.bb}
(92%)
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
similarity index 92%
rename from meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb
rename to meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
index 1cfa56b21e..5f14e62446 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.8.6.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.8.7.bb
@@ -24,7 +24,7 @@ XORG_PN = "libX11"
SRC_URI += "file://disable_tests.patch"
-SRC_URI[sha256sum] =
"59535b7cc6989ba806a022f7e8533b28c4397b9d86e9d07b6df0c0703fa25cc9"
+SRC_URI[sha256sum] =
"05f267468e3c851ae2b5c830bcf74251a90f63f04dd7c709ca94dc155b7e99ee"
inherit gettext
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189495):
https://lists.openembedded.org/g/openembedded-core/message/189495
Mute This Topic: https://lists.openembedded.org/mt/102075524/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore][PATCH 1/1] libxpm: upgrade to 3.5.17
From: Ross Burton
This release fixes the following CVEs:
- CVE-2023-43788
- CVE-2023-43789
Signed-off-by: Ross Burton
Signed-off-by: Richard Purdie
(cherry picked from commit 46dd8ce41756dbc2aa0f9001416f208cced1c8d5)
Signed-off-by: Yogita Urade
---
.../xorg-lib/{libxpm_3.5.16.bb => libxpm_3.5.17.bb} | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-graphics/xorg-lib/{libxpm_3.5.16.bb => libxpm_3.5.17.bb}
(88%)
diff --git a/meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb
b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
similarity index 88%
rename from meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb
rename to meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
index c3d01f1bb3..8e15ecc0d4 100644
--- a/meta/recipes-graphics/xorg-lib/libxpm_3.5.16.bb
+++ b/meta/recipes-graphics/xorg-lib/libxpm_3.5.17.bb
@@ -22,6 +22,6 @@ PACKAGES =+ "sxpm cxpm"
FILES:cxpm = "${bindir}/cxpm"
FILES:sxpm = "${bindir}/sxpm"
-SRC_URI[sha256sum] =
"e6bc5da7a69dbd9bcc67e87c93d4904fe2f5177a0711c56e71fa2f6eff649f51"
+SRC_URI[sha256sum] =
"64b31f81019e7d388c822b0b28af8d51c4622b83f1f0cb6fa3fc95e271226e43"
BBCLASSEXTEND = "native"
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189494):
https://lists.openembedded.org/g/openembedded-core/message/189494
Mute This Topic: https://lists.openembedded.org/mt/102075523/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH 1/1] libx11: fix CVE-2023-43787
From: Yogita Urade
A vulnerability was found in libX11 due to an integer overflow
within the XCreateImage() function. This flaw allows a local
user to trigger an integer overflow and execute arbitrary code
with elevated privileges.
Reference:
https://security-tracker.debian.org/tracker/CVE-2023-43787
https://www.openwall.com/lists/oss-security/2023/10/03/1
Signed-off-by: Yogita Urade
---
.../xorg-lib/libx11/CVE-2023-43787.patch | 64 +++
.../xorg-lib/libx11_1.7.3.1.bb| 1 +
2 files changed, 65 insertions(+)
create mode 100644 meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43787.patch
diff --git a/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43787.patch
b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43787.patch
new file mode 100644
index 00..48cb56831b
--- /dev/null
+++ b/meta/recipes-graphics/xorg-lib/libx11/CVE-2023-43787.patch
@@ -0,0 +1,64 @@
+From 7916869d16bdd115ac5be30a67c3749907aea6a0 Mon Sep 17 00:00:00 2001
+From: Yair Mizrahi
+Date: Tue, 17 Oct 2023 08:26:32 +
+Subject: [PATCH] CVE-2023-43787: Integer overflow in XCreateImage() leading to
+ a heap overflow
+
+When the format is `Pixmap` it calculates the size of the image data as:
+ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
+There is no validation on the `width` of the image, and so this
+calculation exceeds the capacity of a 4-byte integer, causing an overflow.
+
+Signed-off-by: Alan Coopersmith
+
+CVE: CVE-2023-43787
+
+Upstream-Status: Backport
[https://gitlab.freedesktop.org/xorg/lib/libx11/-/commit/7916869d16bdd115ac5be30a67c3749907aea6a0]
+
+Signed-off-by: Yogita Urade
+---
+ src/ImUtil.c | 20 +++-
+ 1 file changed, 15 insertions(+), 5 deletions(-)
+
+diff --git a/src/ImUtil.c b/src/ImUtil.c
+index 36f08a0..fbfad33 100644
+--- a/src/ImUtil.c
b/src/ImUtil.c
+@@ -30,6 +30,7 @@ in this Software without prior written authorization from
The Open Group.
+ #include
+ #include
+ #include
++#include
+ #include "ImUtil.h"
+
+ static int _XDestroyImage(XImage *);
+@@ -361,13 +362,22 @@ XImage *XCreateImage (
+ /*
+* compute per line accelerator.
+*/
+- {
+- if (format == ZPixmap)
++ if (format == ZPixmap) {
++ if ((INT_MAX / bits_per_pixel) < width) {
++ Xfree(image);
++ return NULL;
++ }
++
+ min_bytes_per_line =
+- ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
+- else
++ ROUNDUP((bits_per_pixel * width), image->bitmap_pad);
++ } else {
++ if ((INT_MAX - offset) < width) {
++ Xfree(image);
++ return NULL;
++ }
++
+ min_bytes_per_line =
+- ROUNDUP((width + offset), image->bitmap_pad);
++ ROUNDUP((width + offset), image->bitmap_pad);
+ }
+ if (image_bytes_per_line == 0) {
+ image->bytes_per_line = min_bytes_per_line;
+--
+2.35.5
diff --git a/meta/recipes-graphics/xorg-lib/libx11_1.7.3.1.bb
b/meta/recipes-graphics/xorg-lib/libx11_1.7.3.1.bb
index 19687d546b..e77b148d76 100644
--- a/meta/recipes-graphics/xorg-lib/libx11_1.7.3.1.bb
+++ b/meta/recipes-graphics/xorg-lib/libx11_1.7.3.1.bb
@@ -18,6 +18,7 @@ SRC_URI += "file://disable_tests.patch \
file://CVE-2022-3554.patch \
file://CVE-2022-3555.patch \
file://CVE-2023-3138.patch \
+file://CVE-2023-43787.patch \
"
SRC_URI[sha256sum] =
"2ffd417266fb875028fdc0ef349694f63dbcd76d0b0cfacfb52e6151f4b60989"
--
2.35.5
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189493):
https://lists.openembedded.org/g/openembedded-core/message/189493
Mute This Topic: https://lists.openembedded.org/mt/102075512/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[oe-core][kirkstone][PATCH 1/1] linux-firmware: upgrade 20230625 -> 20230804
License-Update: additional firmwares
upgrade include fix for CVE-2023-20569 CVE-2022-40982 CVE-2023-20593
Changelog:
https://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git/
References:
https://nvd.nist.gov/vuln/detail/CVE-2023-20569
https://nvd.nist.gov/vuln/detail/CVE-2022-40982
https://nvd.nist.gov/vuln/detail/CVE-2023-20593
Signed-off-by: Meenali Gupta
---
...{linux-firmware_20230625.bb => linux-firmware_20230804.bb} | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
rename meta/recipes-kernel/linux-firmware/{linux-firmware_20230625.bb =>
linux-firmware_20230804.bb} (99%)
diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
similarity index 99%
rename from meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
rename to meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
index 6765226b9d..4defab434d 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230804.bb
@@ -134,7 +134,7 @@ LIC_FILES_CHKSUM =
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
"
# WHENCE checksum is defined separately to ease overriding it if
# class-devupstream is selected.
-WHENCE_CHKSUM = "57bf874056926f12aec2405d3fc390d9"
+WHENCE_CHKSUM = "41f9a48bf27971b126a36f9344594dcd"
# These are not common licenses, set NO_GENERIC_LICENSE for them
# so that the license files will be copied from fetched source
@@ -212,7 +212,7 @@ SRC_URI:class-devupstream =
"git://git.kernel.org/pub/scm/linux/kernel/git/firmw
# Pin this to the 20220509 release, override this in local.conf
SRCREV:class-devupstream ?= "b19cbdca78ab2adfd210c91be15a22568e8b8cae"
-SRC_URI[sha256sum] =
"87597111c0d4b71b31e53cb85a92c386921b84c825a402db8c82e0e86015500d"
+SRC_URI[sha256sum] =
"88d46c543847ee3b03404d4941d91c92974690ee1f6fdcbee9cef3e5f97db688"
inherit allarch
--
2.40.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189492):
https://lists.openembedded.org/g/openembedded-core/message/189492
Mute This Topic: https://lists.openembedded.org/mt/102075429/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.
Hi Khem, We have checked by raising the memory and no regression failures were found. Here is the test summary; Regression testing is done and below are the test results. Before glibc update Summary of test results: PASS:4727 FAIL:240 XPASS:4 XFAIL:16 UNSUPPORTED:220 After glibc update Summary of test results: PASS:4733 FAIL:235 XPASS:4 XFAIL:16 UNSUPPORTED:221 These are the newly added test cases PASS: io/tst-fcntl-lock-lfs UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname And these are tests that were failing earlier and passed after raising the memory PASS: nptl/tst-thread-affinity-pthread PASS: nptl/tst-thread-affinity-pthread2 PASS: nptl/tst-thread-affinity-sched -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189489): https://lists.openembedded.org/g/openembedded-core/message/189489 Mute This Topic: https://lists.openembedded.org/mt/101774187/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.
Hi Khem , We tried increasing the memory and no regression failures were found. Here is the test results: Regression testing is done and below are the test results. Before glibc update Summary of test results: PASS:4727 FAIL:240 XPASS:4 XFAIL:16 UNSUPPORTED:220 After glibc update Summary of test results: PASS:4733 FAIL:235 XPASS:4 XFAIL:16 UNSUPPORTED:221 These are the newly added test cases PASS: io/tst-fcntl-lock-lfs UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname These are the tests which are failing before and now it is passing PASS: nptl/tst-thread-affinity-pthread PASS: nptl/tst-thread-affinity-pthread2 PASS: nptl/tst-thread-affinity-sched -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189490): https://lists.openembedded.org/g/openembedded-core/message/189490 Mute This Topic: https://lists.openembedded.org/mt/101774187/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.
Hi Khem, We tried increasing the memory and no regression failures were found. Here is the test results: Regression testing is done and below are the test results. Before glibc update Summary of test results: PASS:4727 FAIL:240 XPASS:4 XFAIL:16 UNSUPPORTED:220 After glibc update Summary of test results: PASS:4733 FAIL:235 XPASS:4 XFAIL:16 UNSUPPORTED:221 These are the newly added test cases PASS: io/tst-fcntl-lock-lfs UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname These are the tests which were failing before and passed after increasing the memory: PASS: nptl/tst-thread-affinity-pthread PASS: nptl/tst-thread-affinity-pthread2 PASS: nptl/tst-thread-affinity-sched -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189491): https://lists.openembedded.org/g/openembedded-core/message/189491 Mute This Topic: https://lists.openembedded.org/mt/101774187/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.
On Thu, Oct 19, 2023 at 5:16 AM Sanjana.Venkatesh via lists.openembedded.org wrote: > Hi Khem, > > We tried increasing the memory and no regression failures were found. > > Thanks for following up Steve We can cherry pick this for mickledore I think now Here is the test results: > > Regression testing is done and below are the test results. > Before glibc update > Summary of test results: > PASS:4727 > FAIL:240 > XPASS:4 > XFAIL:16 > UNSUPPORTED:220 > > After glibc update > Summary of test results: > PASS:4733 > FAIL:235 > XPASS:4 > XFAIL:16 > UNSUPPORTED:221 > > These are the newly added test cases > PASS: io/tst-fcntl-lock-lfs > UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname > > These are the tests which were failing before and passed after increasing > the memory: > PASS: nptl/tst-thread-affinity-pthread > PASS: nptl/tst-thread-affinity-pthread2 > PASS: nptl/tst-thread-affinity-sched > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189488): https://lists.openembedded.org/g/openembedded-core/message/189488 Mute This Topic: https://lists.openembedded.org/mt/101774187/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH RESEND] runqemu: Add squashfs filesystem types
When using a squashfs filesystem type, runqemu requires specifying the
full path to the image because it doesn't list squashfs types in its
fstypes variable. Add them to provide the same support as other
filesystem types.
Signed-off-by: Logan Gunthorpe
---
scripts/runqemu | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 6fca7439a1d2..18aeb7f5f0cf 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -198,7 +198,9 @@ class BaseConfig(object):
self.snapshot = False
self.wictypes = ('wic', 'wic.vmdk', 'wic.qcow2', 'wic.vdi', "wic.vhd",
"wic.vhdx")
self.fstypes = ('ext2', 'ext3', 'ext4', 'jffs2', 'nfs', 'btrfs',
-'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz')
+'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz',
+'squashfs', 'squashfs-xz', 'squashfs-lzo',
+'squashfs-lz4', 'squashfs-zst')
self.vmtypes = ('hddimg', 'iso')
self.fsinfo = {}
self.network_device = "-device e1000,netdev=net0,mac=@MAC@"
base-commit: f65f100bc5379c3153ee00b2aa62ea5c9a66ec79
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189487):
https://lists.openembedded.org/g/openembedded-core/message/189487
Mute This Topic: https://lists.openembedded.org/mt/102069212/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/2 v2] patchtest: skip merge test if not targeting master
Avoid testing mergeability of a patch when not targeting master, so that
patches tested via other means (e.g. maintainer branches and AB runs)
don't get unnecessarily reviewed an extra time.
Signed-off-by: Trevor Gamblin
---
v2 corrects the logic in the new if statement (modified during a test)
and states which branch was detected as a patch target when printing the
message. It also adds a detailed commit message so that it'll pass the
patchtest check.
meta/lib/patchtest/tests/test_mbox_merge.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/patchtest/tests/test_mbox_merge.py
b/meta/lib/patchtest/tests/test_mbox_merge.py
index bc55c588b40..f69d57c71b1 100644
--- a/meta/lib/patchtest/tests/test_mbox_merge.py
+++ b/meta/lib/patchtest/tests/test_mbox_merge.py
@@ -18,6 +18,8 @@ def headlog():
class Merge(base.Base):
def test_series_merge_on_head(self):
+if PatchTestInput.repo.branch != "master":
+self.skip("Skipping merge test since patch is not intended for
master branch. Target detected is %s" % PatchTestInput.repo.branch)
if not PatchTestInput.repo.ismerged:
commithash, author, date, shortlog = headlog()
self.fail('Series does not apply on top of target branch. Rebase
your series and ensure the target is correct',
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189486):
https://lists.openembedded.org/g/openembedded-core/message/189486
Mute This Topic: https://lists.openembedded.org/mt/102069183/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] runqemu: Add squashfs filesystem types
On 2023-10-19 14:57, Alexandre Belloni wrote: > Hello, > > On 19/10/2023 12:10:51-0600, Logan Gunthorpe via lists.openembedded.org wrote: >> From: Logan Gunthorpe >> >> When using a squashfs filesystem type, runqemu requires specifying the >> full path to the image because it doesn't list squashfs types in its >> fstypes variable. Add them to provide the same support as other >> filesystem types. >> >> Signed-off-by: Logan Gunthorpe > > One of the SoB must match your From: My apologies. I messed that up and didn't notice until after it was sent. I'll resend. Thanks, Logan -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189485): https://lists.openembedded.org/g/openembedded-core/message/189485 Mute This Topic: https://lists.openembedded.org/mt/102065945/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] runqemu: Add squashfs filesystem types
Hello,
On 19/10/2023 12:10:51-0600, Logan Gunthorpe via lists.openembedded.org wrote:
> From: Logan Gunthorpe
>
> When using a squashfs filesystem type, runqemu requires specifying the
> full path to the image because it doesn't list squashfs types in its
> fstypes variable. Add them to provide the same support as other
> filesystem types.
>
> Signed-off-by: Logan Gunthorpe
One of the SoB must match your From:
> ---
> scripts/runqemu | 4 +++-
> 1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/runqemu b/scripts/runqemu
> index 6fca7439a1d2..18aeb7f5f0cf 100755
> --- a/scripts/runqemu
> +++ b/scripts/runqemu
> @@ -198,7 +198,9 @@ class BaseConfig(object):
> self.snapshot = False
> self.wictypes = ('wic', 'wic.vmdk', 'wic.qcow2', 'wic.vdi',
> "wic.vhd", "wic.vhdx")
> self.fstypes = ('ext2', 'ext3', 'ext4', 'jffs2', 'nfs', 'btrfs',
> -'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz')
> +'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz',
> +'squashfs', 'squashfs-xz', 'squashfs-lzo',
> +'squashfs-lz4', 'squashfs-zst')
> self.vmtypes = ('hddimg', 'iso')
> self.fsinfo = {}
> self.network_device = "-device e1000,netdev=net0,mac=@MAC@"
>
> base-commit: f65f100bc5379c3153ee00b2aa62ea5c9a66ec79
> --
> 2.30.2
>
>
>
>
--
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189484):
https://lists.openembedded.org/g/openembedded-core/message/189484
Mute This Topic: https://lists.openembedded.org/mt/102065945/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 2/2] patchtest: test regardless of mergeability
Signed-off-by: Trevor Gamblin
---
meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py | 5 -
meta/lib/patchtest/tests/test_metadata_license.py | 5 -
meta/lib/patchtest/tests/test_metadata_summary.py | 5 -
meta/lib/patchtest/tests/test_python_pylint.py | 2 --
4 files changed, 17 deletions(-)
diff --git a/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
b/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
index b2c32507ffe..cb3e7c9d341 100644
--- a/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
+++ b/meta/lib/patchtest/tests/test_metadata_lic_files_chksum.py
@@ -15,11 +15,6 @@ class LicFilesChkSum(base.Metadata):
lictag = 'License-Update'
lictag_re = pyparsing.Regex("^%s:" % lictag)
-def setUp(self):
-# these tests just make sense on patches that can be merged
-if not PatchTestInput.repo.canbemerged:
-self.skip('Patch cannot be merged')
-
def test_lic_files_chksum_presence(self):
if not self.added:
self.skip('No added recipes, skipping test')
diff --git a/meta/lib/patchtest/tests/test_metadata_license.py
b/meta/lib/patchtest/tests/test_metadata_license.py
index a5bc03b83fe..1a7f09b7470 100644
--- a/meta/lib/patchtest/tests/test_metadata_license.py
+++ b/meta/lib/patchtest/tests/test_metadata_license.py
@@ -12,11 +12,6 @@ class License(base.Metadata):
metadata = 'LICENSE'
invalid_license = 'PATCHTESTINVALID'
-def setUp(self):
-# these tests just make sense on patches that can be merged
-if not PatchTestInput.repo.canbemerged:
-self.skip('Patch cannot be merged')
-
def test_license_presence(self):
if not self.added:
self.skip('No added recipes, skipping test')
diff --git a/meta/lib/patchtest/tests/test_metadata_summary.py
b/meta/lib/patchtest/tests/test_metadata_summary.py
index 1502863df02..170e79eb4b7 100644
--- a/meta/lib/patchtest/tests/test_metadata_summary.py
+++ b/meta/lib/patchtest/tests/test_metadata_summary.py
@@ -10,11 +10,6 @@ from data import PatchTestInput
class Summary(base.Metadata):
metadata = 'SUMMARY'
-def setUp(self):
-# these tests just make sense on patches that can be merged
-if not PatchTestInput.repo.canbemerged:
-self.skip('Patch cannot be merged')
-
def test_summary_presence(self):
if not self.added:
self.skip('No added recipes, skipping test')
diff --git a/meta/lib/patchtest/tests/test_python_pylint.py
b/meta/lib/patchtest/tests/test_python_pylint.py
index 9cfc491a134..304b2d5ee9a 100644
--- a/meta/lib/patchtest/tests/test_python_pylint.py
+++ b/meta/lib/patchtest/tests/test_python_pylint.py
@@ -26,8 +26,6 @@ class PyLint(base.Base):
def setUp(self):
if self.unidiff_parse_error:
self.skip('Python-unidiff parse error')
-if not PatchTestInput.repo.canbemerged:
-self.skip('Patch cannot be merged, no reason to execute the test
method')
if not PyLint.pythonpatches:
self.skip('No python related patches, skipping test')
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189483):
https://lists.openembedded.org/g/openembedded-core/message/189483
Mute This Topic: https://lists.openembedded.org/mt/102068909/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/2] patchtest: skip merge test if not targeting master
Signed-off-by: Trevor Gamblin
---
meta/lib/patchtest/tests/test_mbox_merge.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/patchtest/tests/test_mbox_merge.py
b/meta/lib/patchtest/tests/test_mbox_merge.py
index bc55c588b40..013b9e0144d 100644
--- a/meta/lib/patchtest/tests/test_mbox_merge.py
+++ b/meta/lib/patchtest/tests/test_mbox_merge.py
@@ -18,6 +18,8 @@ def headlog():
class Merge(base.Base):
def test_series_merge_on_head(self):
+if PatchTestInput.repo.branch == "master":
+self.skip("Skipping merge test since patch is not intended for
master branch")
if not PatchTestInput.repo.ismerged:
commithash, author, date, shortlog = headlog()
self.fail('Series does not apply on top of target branch. Rebase
your series and ensure the target is correct',
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189482):
https://lists.openembedded.org/g/openembedded-core/message/189482
Mute This Topic: https://lists.openembedded.org/mt/102068908/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
On 19/10/2023 20:20:33+0200, Julien Stephan wrote:
> Le jeu. 19 oct. 2023 à 15:49, Alexandre Belloni
> a écrit :
> >
> > Hello,
> >
> > On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > > add support for PEP517 [1]
> > >
> > > if a pyproject.toml file is found, use it to create the recipe,
> > > otherwise fallback to the old setup.py method.
> > >
> > > [YOCTO #14737]
> > >
> > > [1]: https://peps.python.org/pep-0517/
> > >
> > > Signed-off-by: Julien Stephan
> > > ---
> > > .../lib/recipetool/create_buildsys_python.py | 234 +-
> > > 1 file changed, 233 insertions(+), 1 deletion(-)
> > >
> > > diff --git a/scripts/lib/recipetool/create_buildsys_python.py
> > > b/scripts/lib/recipetool/create_buildsys_python.py
> > > index 69f6f5ca511..0b601d50a4b 100644
> > > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > > @@ -18,6 +18,7 @@ import os
> > > import re
> > > import sys
> > > import subprocess
> > > +import toml
> >
> > This fails on the autobuilders because we don't have the toml module
> > installed so I guess you need to add a dependency.
> >
>
> Hello,
>
> Sure I 'll do it. Just to confirm, I should add it here:
> https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host
> ?
I guess the preferred way would be to depend on python3-toml-native
instead of requiring installation on the host.
>
> Cheers
> Julien
>
> > > from recipetool.create import RecipeHandler
> > >
> > > logger = logging.getLogger('recipetool')
> > > @@ -656,6 +657,235 @@ class
> > > PythonSetupPyRecipeHandler(PythonRecipeHandler):
> > >
> > > handled.append('buildsystem')
> > >
> > > +class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
> > > +"""Base class to support PEP517 and PEP518
> > > +
> > > +PEP517 https://peps.python.org/pep-0517/#source-trees
> > > +PEP518 https://peps.python.org/pep-0518/#build-system-table
> > > +"""
> > > +
> > > +# PEP621:
> > > https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
> > > +# add only the ones that map to a BB var
> > > +# potentially missing: optional-dependencies
> > > +bbvar_map = {
> > > +"name": "PN",
> > > +"version": "PV",
> > > +"Homepage": "HOMEPAGE",
> > > +"description": "SUMMARY",
> > > +"license": "LICENSE",
> > > +"dependencies": "RDEPENDS:${PN}",
> > > +"requires": "DEPENDS",
> > > +}
> > > +
> > > +replacements = [
> > > +("license", r" +$", ""),
> > > +("license", r"^ +", ""),
> > > +("license", r" ", "-"),
> > > +("license", r"^GNU-", ""),
> > > +("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
> > > +("license", r"^UNKNOWN$", ""),
> > > +# Remove currently unhandled version numbers from these variables
> > > +("requires", r"\[[^\]]+\]$", ""),
> > > +("requires", r"^([^><= ]+).*", r"\1"),
> > > +("dependencies", r"\[[^\]]+\]$", ""),
> > > +("dependencies", r"^([^><= ]+).*", r"\1"),
> > > +]
> > > +
> > > +build_backend_map = {
> > > +"setuptools.build_meta": "python_setuptools_build_meta",
> > > +"poetry.core.masonry.api": "python_poetry_core",
> > > +"flit_core.buildapi": "python_flit_core",
> > > +}
> > > +
> > > +excluded_native_pkgdeps = [
> > > +# already provided by python_setuptools_build_meta.bbclass
> > > +"python3-setuptools-native",
> > > +"python3-wheel-native",
> > > +# already provided by python_poetry_core.bbclass
> > > +"python3-poetry-core-native",
> > > +# already provided by python_flit_core.bbclass
> > > +"python3-flit-core-native",
> > > +]
> > > +
> > > +# add here a list of known and often used packages and the
> > > corresponding bitbake package
> > > +known_deps_map = {
> > > +"setuptools": "python3-setuptools",
> > > +"wheel": "python3-wheel",
> > > +"poetry-core": "python3-poetry-core",
> > > +"flit_core": "python3-flit-core",
> > > +"setuptools-scm": "python3-setuptools-scm",
> > > +}
> > > +
> > > +def __init__(self):
> > > +pass
> > > +
> > > +def process(self, srctree, classes, lines_before, lines_after,
> > > handled, extravalues):
> > > +info = {}
> > > +
> > > +if 'buildsystem' in handled:
> > > +return False
> > > +
> > > +# Check for non-zero size setup.py files
> > > +setupfiles = RecipeHandler.checkfiles(srctree,
> > > ["pyproject.toml"])
> > > +for fn in setupfiles:
> > > +if os.path.getsize(fn):
> > > +break
> > > +else:
> > > +return False
> > > +
> > > +setupscript = os.path.join(srctree, "pyproject.toml")
> > > +
> > > +try:
> > > +config =
[OE-core][kirkstone][PATCH] zlib: patch CVE-2023-45853
From: Peter Marko
Backport commit merged to develop branch from PR linked in NVD report:
* https://nvd.nist.gov/vuln/detail/CVE-2023-45853
* https://github.com/madler/zlib/pull/843
Signed-off-by: Peter Marko
---
.../zlib/zlib/CVE-2023-45853.patch| 42 +++
meta/recipes-core/zlib/zlib_1.2.11.bb | 1 +
2 files changed, 43 insertions(+)
create mode 100644 meta/recipes-core/zlib/zlib/CVE-2023-45853.patch
diff --git a/meta/recipes-core/zlib/zlib/CVE-2023-45853.patch
b/meta/recipes-core/zlib/zlib/CVE-2023-45853.patch
new file mode 100644
index 00..ba3709249b
--- /dev/null
+++ b/meta/recipes-core/zlib/zlib/CVE-2023-45853.patch
@@ -0,0 +1,42 @@
+From 73331a6a0481067628f065ffe87bb1d8f787d10c Mon Sep 17 00:00:00 2001
+From: Hans Wennborg
+Date: Fri, 18 Aug 2023 11:05:33 +0200
+Subject: [PATCH] Reject overflows of zip header fields in minizip.
+
+This checks the lengths of the file name, extra field, and comment
+that would be put in the zip headers, and rejects them if they are
+too long. They are each limited to 65535 bytes in length by the zip
+format. This also avoids possible buffer overflows if the provided
+fields are too long.
+
+CVE: CVE-2023-45853
+Upstream-Status: Backport
[https://github.com/madler/zlib/commit/73331a6a0481067628f065ffe87bb1d8f787d10c]
+
+Signed-off-by: Peter Marko
+
+---
+ contrib/minizip/zip.c | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/contrib/minizip/zip.c b/contrib/minizip/zip.c
+index 3d3d4cadd..0446109b2 100644
+--- a/contrib/minizip/zip.c
b/contrib/minizip/zip.c
+@@ -1043,6 +1043,17 @@ extern int ZEXPORT zipOpenNewFileInZip4_64(zipFile
file, const char* filename, c
+ return ZIP_PARAMERROR;
+ #endif
+
++// The filename and comment length must fit in 16 bits.
++if ((filename!=NULL) && (strlen(filename)>0x))
++return ZIP_PARAMERROR;
++if ((comment!=NULL) && (strlen(comment)>0x))
++return ZIP_PARAMERROR;
++// The extra field length must fit in 16 bits. If the member also requires
++// a Zip64 extra block, that will also need to fit within that 16-bit
++// length, but that will be checked for later.
++if ((size_extrafield_local>0x) || (size_extrafield_global>0x))
++return ZIP_PARAMERROR;
++
+ zi = (zip64_internal*)file;
+
+ if (zi->in_opened_file_inzip == 1)
diff --git a/meta/recipes-core/zlib/zlib_1.2.11.bb
b/meta/recipes-core/zlib/zlib_1.2.11.bb
index f768b41988..d75474dcb6 100644
--- a/meta/recipes-core/zlib/zlib_1.2.11.bb
+++ b/meta/recipes-core/zlib/zlib_1.2.11.bb
@@ -12,6 +12,7 @@ SRC_URI =
"${SOURCEFORGE_MIRROR}/libpng/${BPN}/${PV}/${BPN}-${PV}.tar.xz \
file://CVE-2018-25032.patch \
file://run-ptest \
file://CVE-2022-37434.patch \
+ file://CVE-2023-45853.patch \
"
UPSTREAM_CHECK_URI = "http://zlib.net/;
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189480):
https://lists.openembedded.org/g/openembedded-core/message/189480
Mute This Topic: https://lists.openembedded.org/mt/102066305/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
Le jeu. 19 oct. 2023 à 15:49, Alexandre Belloni
a écrit :
>
> Hello,
>
> On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > add support for PEP517 [1]
> >
> > if a pyproject.toml file is found, use it to create the recipe,
> > otherwise fallback to the old setup.py method.
> >
> > [YOCTO #14737]
> >
> > [1]: https://peps.python.org/pep-0517/
> >
> > Signed-off-by: Julien Stephan
> > ---
> > .../lib/recipetool/create_buildsys_python.py | 234 +-
> > 1 file changed, 233 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/recipetool/create_buildsys_python.py
> > b/scripts/lib/recipetool/create_buildsys_python.py
> > index 69f6f5ca511..0b601d50a4b 100644
> > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > @@ -18,6 +18,7 @@ import os
> > import re
> > import sys
> > import subprocess
> > +import toml
>
> This fails on the autobuilders because we don't have the toml module
> installed so I guess you need to add a dependency.
>
Hello,
Sure I 'll do it. Just to confirm, I should add it here:
https://docs.yoctoproject.org/ref-manual/system-requirements.html#required-packages-for-the-build-host
?
Cheers
Julien
> > from recipetool.create import RecipeHandler
> >
> > logger = logging.getLogger('recipetool')
> > @@ -656,6 +657,235 @@ class PythonSetupPyRecipeHandler(PythonRecipeHandler):
> >
> > handled.append('buildsystem')
> >
> > +class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
> > +"""Base class to support PEP517 and PEP518
> > +
> > +PEP517 https://peps.python.org/pep-0517/#source-trees
> > +PEP518 https://peps.python.org/pep-0518/#build-system-table
> > +"""
> > +
> > +# PEP621:
> > https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
> > +# add only the ones that map to a BB var
> > +# potentially missing: optional-dependencies
> > +bbvar_map = {
> > +"name": "PN",
> > +"version": "PV",
> > +"Homepage": "HOMEPAGE",
> > +"description": "SUMMARY",
> > +"license": "LICENSE",
> > +"dependencies": "RDEPENDS:${PN}",
> > +"requires": "DEPENDS",
> > +}
> > +
> > +replacements = [
> > +("license", r" +$", ""),
> > +("license", r"^ +", ""),
> > +("license", r" ", "-"),
> > +("license", r"^GNU-", ""),
> > +("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
> > +("license", r"^UNKNOWN$", ""),
> > +# Remove currently unhandled version numbers from these variables
> > +("requires", r"\[[^\]]+\]$", ""),
> > +("requires", r"^([^><= ]+).*", r"\1"),
> > +("dependencies", r"\[[^\]]+\]$", ""),
> > +("dependencies", r"^([^><= ]+).*", r"\1"),
> > +]
> > +
> > +build_backend_map = {
> > +"setuptools.build_meta": "python_setuptools_build_meta",
> > +"poetry.core.masonry.api": "python_poetry_core",
> > +"flit_core.buildapi": "python_flit_core",
> > +}
> > +
> > +excluded_native_pkgdeps = [
> > +# already provided by python_setuptools_build_meta.bbclass
> > +"python3-setuptools-native",
> > +"python3-wheel-native",
> > +# already provided by python_poetry_core.bbclass
> > +"python3-poetry-core-native",
> > +# already provided by python_flit_core.bbclass
> > +"python3-flit-core-native",
> > +]
> > +
> > +# add here a list of known and often used packages and the
> > corresponding bitbake package
> > +known_deps_map = {
> > +"setuptools": "python3-setuptools",
> > +"wheel": "python3-wheel",
> > +"poetry-core": "python3-poetry-core",
> > +"flit_core": "python3-flit-core",
> > +"setuptools-scm": "python3-setuptools-scm",
> > +}
> > +
> > +def __init__(self):
> > +pass
> > +
> > +def process(self, srctree, classes, lines_before, lines_after,
> > handled, extravalues):
> > +info = {}
> > +
> > +if 'buildsystem' in handled:
> > +return False
> > +
> > +# Check for non-zero size setup.py files
> > +setupfiles = RecipeHandler.checkfiles(srctree, ["pyproject.toml"])
> > +for fn in setupfiles:
> > +if os.path.getsize(fn):
> > +break
> > +else:
> > +return False
> > +
> > +setupscript = os.path.join(srctree, "pyproject.toml")
> > +
> > +try:
> > +config = self.parse_pyproject_toml(setupscript)
> > +build_backend = config["build-system"]["build-backend"]
> > +if build_backend in self.build_backend_map:
> > +classes.append(self.build_backend_map[build_backend])
> > +else:
> > +logger.error(
> > +"Unsupported build-backend: %s, cannot use
> > pyproject.toml. Will try to use legacy setup.py"
> > +%
[OE-core] [PATCH] runqemu: Add squashfs filesystem types
From: Logan Gunthorpe
When using a squashfs filesystem type, runqemu requires specifying the
full path to the image because it doesn't list squashfs types in its
fstypes variable. Add them to provide the same support as other
filesystem types.
Signed-off-by: Logan Gunthorpe
---
scripts/runqemu | 4 +++-
1 file changed, 3 insertions(+), 1 deletion(-)
diff --git a/scripts/runqemu b/scripts/runqemu
index 6fca7439a1d2..18aeb7f5f0cf 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -198,7 +198,9 @@ class BaseConfig(object):
self.snapshot = False
self.wictypes = ('wic', 'wic.vmdk', 'wic.qcow2', 'wic.vdi', "wic.vhd",
"wic.vhdx")
self.fstypes = ('ext2', 'ext3', 'ext4', 'jffs2', 'nfs', 'btrfs',
-'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz')
+'cpio.gz', 'cpio', 'ramfs', 'tar.bz2', 'tar.gz',
+'squashfs', 'squashfs-xz', 'squashfs-lzo',
+'squashfs-lz4', 'squashfs-zst')
self.vmtypes = ('hddimg', 'iso')
self.fsinfo = {}
self.network_device = "-device e1000,netdev=net0,mac=@MAC@"
base-commit: f65f100bc5379c3153ee00b2aa62ea5c9a66ec79
--
2.30.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189478):
https://lists.openembedded.org/g/openembedded-core/message/189478
Mute This Topic: https://lists.openembedded.org/mt/102065945/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] shared-mime-info: Fix missing sentinel warning
Clang finds it, gcc does not.
Signed-off-by: Khem Raj
---
v2: Some more warnings fixed with clang
.../0001-Fix-literal-as-per-c-11.patch| 279 ++
...001-Fix-string-literal-concatenation.patch | 39 +++
.../shared-mime-info/shared-mime-info_git.bb | 5 +-
3 files changed, 322 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
create mode 100644
meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-string-literal-concatenation.patch
diff --git
a/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
new file mode 100644
index 000..25f409c206e
--- /dev/null
+++
b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
@@ -0,0 +1,279 @@
+From 157c16b09f54741aefbc4be6a3507455f0378389 Mon Sep 17 00:00:00 2001
+From: Biswapriyo Nath
+Date: Sun, 8 Oct 2023 13:26:43 +
+Subject: [PATCH] Fix missing sentinel warning with clang
+
+This fixes the compiler warnings similar as following.
+
+../src/update-mime-database.cpp:393:50: warning: missing sentinel in function
call [-Wsentinel]
+ 393 | g_strconcat(namespaceURI, " ", localName,
NULL),
+ | ^
+ |
, nullptr
+
+Upstream-Status: Backport
[https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/157c16b09f54741aefbc4be6a3507455f0378389]
+Signed-off-by: Khem Raj
+---
+ src/update-mime-database.cpp | 58 ++--
+ 1 file changed, 29 insertions(+), 29 deletions(-)
+
+--- a/src/update-mime-database.cpp
b/src/update-mime-database.cpp
+@@ -390,7 +390,7 @@ static void add_namespace(Type *type, co
+ }
+
+ g_hash_table_insert(namespace_hash,
+- g_strconcat(namespaceURI, " ", localName, NULL),
++ g_strconcat(namespaceURI, " ", localName, nullptr),
+ type);
+ }
+
+@@ -1023,7 +1023,7 @@ static void write_out_type(gpointer key,
+ char *lower;
+
+ lower = g_ascii_strdown(type->media, -1);
+- media = g_strconcat(mime_dir, "/", lower, NULL);
++ media = g_strconcat(mime_dir, "/", lower, nullptr);
+ g_free(lower);
+ #ifdef _WIN32
+ fs::create_directory(media);
+@@ -1032,7 +1032,7 @@ static void write_out_type(gpointer key,
+ #endif
+
+ lower = g_ascii_strdown(type->subtype, -1);
+- filename = g_strconcat(media, "/", lower, ".xml.new", NULL);
++ filename = g_strconcat(media, "/", lower, ".xml.new", nullptr);
+ g_free(lower);
+ g_free(media);
+ media = NULL;
+@@ -1622,7 +1622,7 @@ static Magic *magic_new(xmlNode *node, T
+ magic_free(magic);
+ magic = NULL;
+ (*error)->message = g_strconcat(
+- _("Error in element: "), old, NULL);
++ _("Error in element: "), old, nullptr);
+ g_free(old);
+ } else if (magic->matches == NULL) {
+ magic_free(magic);
+@@ -1843,7 +1843,7 @@ static TreeMagic *tree_magic_new(xmlNode
+ tree_magic_free(magic);
+ magic = NULL;
+ (*error)->message = g_strconcat(
+- _("Error in element: "), old, NULL);
++ _("Error in element: "), old,
nullptr);
+ g_free(old);
+ }
+ }
+@@ -1960,7 +1960,7 @@ static void delete_old_types(const gchar
+
+ for (i = 0; i < G_N_ELEMENTS(media_types); i++)
+ {
+- const fs::path media_dir = g_strconcat(mime_dir, "/",
media_types[i], NULL);
++ const fs::path media_dir = g_strconcat(mime_dir, "/",
media_types[i], nullptr);
+
+ if (!fs::is_directory(fs::status(media_dir)))
+ continue;
+@@ -1973,13 +1973,13 @@ static void delete_old_types(const gchar
+ continue;
+
+ char *type_name = g_strconcat(media_types[i], "/",
+-
dir_entry.path().filename().string().c_str(), NULL);
++
dir_entry.path().filename().string().c_str(), nullptr);
+ type_name[strlen(type_name) - 4] = '\0';
+ if (!g_hash_table_lookup(types, type_name))
+ {
+ char *path;
+ path = g_strconcat(mime_dir, "/",
+- type_name, ".xml", NULL);
++
[OE-core] [PATCH] shared-mime-info: Fix missing sentinel warning
Clang finds it, gcc does not.
Signed-off-by: Khem Raj
---
.../0001-Fix-literal-as-per-c-11.patch| 284 ++
.../shared-mime-info/shared-mime-info_git.bb | 3 +-
2 files changed, 286 insertions(+), 1 deletion(-)
create mode 100644
meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
diff --git
a/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
new file mode 100644
index 000..63af84e3a87
--- /dev/null
+++
b/meta/recipes-support/shared-mime-info/shared-mime-info/0001-Fix-literal-as-per-c-11.patch
@@ -0,0 +1,284 @@
+From 157c16b09f54741aefbc4be6a3507455f0378389 Mon Sep 17 00:00:00 2001
+From: Biswapriyo Nath
+Date: Sun, 8 Oct 2023 13:26:43 +
+Subject: [PATCH] Fix missing sentinel warning with clang
+
+This fixes the compiler warnings similar as following.
+
+../src/update-mime-database.cpp:393:50: warning: missing sentinel in function
call [-Wsentinel]
+ 393 | g_strconcat(namespaceURI, " ", localName,
NULL),
+ | ^
+ |
, nullptr
+
+Upstream-Status: Backport
[https://gitlab.freedesktop.org/xdg/shared-mime-info/-/commit/157c16b09f54741aefbc4be6a3507455f0378389]
+Signed-off-by: Khem Raj
+---
+ src/update-mime-database.cpp | 58 ++--
+ 1 file changed, 29 insertions(+), 29 deletions(-)
+
+diff --git a/src/update-mime-database.cpp b/src/update-mime-database.cpp
+index 29d82a9..7838a0e 100644
+--- a/src/update-mime-database.cpp
b/src/update-mime-database.cpp
+@@ -390,7 +390,7 @@ static void add_namespace(Type *type, const char
*namespaceURI,
+ }
+
+ g_hash_table_insert(namespace_hash,
+- g_strconcat(namespaceURI, " ", localName, NULL),
++ g_strconcat(namespaceURI, " ", localName, nullptr),
+ type);
+ }
+
+@@ -1023,7 +1023,7 @@ static void write_out_type(gpointer key, gpointer value,
gpointer data)
+ char *lower;
+
+ lower = g_ascii_strdown(type->media, -1);
+- media = g_strconcat(mime_dir, "/", lower, NULL);
++ media = g_strconcat(mime_dir, "/", lower, nullptr);
+ g_free(lower);
+ #ifdef _WIN32
+ fs::create_directory(media);
+@@ -1032,7 +1032,7 @@ static void write_out_type(gpointer key, gpointer value,
gpointer data)
+ #endif
+
+ lower = g_ascii_strdown(type->subtype, -1);
+- filename = g_strconcat(media, "/", lower, ".xml.new", NULL);
++ filename = g_strconcat(media, "/", lower, ".xml.new", nullptr);
+ g_free(lower);
+ g_free(media);
+ media = NULL;
+@@ -1622,7 +1622,7 @@ static Magic *magic_new(xmlNode *node, Type *type,
GError **error)
+ magic_free(magic);
+ magic = NULL;
+ (*error)->message = g_strconcat(
+- _("Error in element: "), old, NULL);
++ _("Error in element: "), old, nullptr);
+ g_free(old);
+ } else if (magic->matches == NULL) {
+ magic_free(magic);
+@@ -1843,7 +1843,7 @@ static TreeMagic *tree_magic_new(xmlNode *node, Type
*type, GError **error)
+ tree_magic_free(magic);
+ magic = NULL;
+ (*error)->message = g_strconcat(
+- _("Error in element: "), old, NULL);
++ _("Error in element: "), old,
nullptr);
+ g_free(old);
+ }
+ }
+@@ -1960,7 +1960,7 @@ static void delete_old_types(const gchar *mime_dir)
+
+ for (i = 0; i < G_N_ELEMENTS(media_types); i++)
+ {
+- const fs::path media_dir = g_strconcat(mime_dir, "/",
media_types[i], NULL);
++ const fs::path media_dir = g_strconcat(mime_dir, "/",
media_types[i], nullptr);
+
+ if (!fs::is_directory(fs::status(media_dir)))
+ continue;
+@@ -1973,13 +1973,13 @@ static void delete_old_types(const gchar *mime_dir)
+ continue;
+
+ char *type_name = g_strconcat(media_types[i], "/",
+-
dir_entry.path().filename().string().c_str(), NULL);
++
dir_entry.path().filename().string().c_str(), nullptr);
+ type_name[strlen(type_name) - 4] = '\0';
+ if (!g_hash_table_lookup(types, type_name))
+ {
+ char *path;
+ path = g_strconcat(mime_dir, "/",
+- type_name, ".xml",
Re: [OE-core] [PATCH 1/3] kernel-yocto, devtool-source.bbclass: fix 'devtool modify' for kernels
Hi Alexandre,
> The series causes:
>
> 2023-10-17 23:07:15,509 - oe-selftest - INFO -
> devtool.DevtoolUpgradeTests.test_devtool_modify_kernel_overrides
> (subunit.RemotedTestCase)
> 2023-10-17 23:07:15,675 - oe-selftest - INFO - ... FAIL
> Stderr:
> 2023-10-17 22:28:35,773 - oe-selftest - INFO - Adding: "include selftest.inc"
> in
> /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-
> 2667546/conf/local.conf
> 2023-10-17 22:28:35,773 - oe-selftest - INFO - Adding: "include bblayers.inc"
> in
> bblayers.conf
> 2023-10-17 23:07:15,680 - oe-selftest - INFO - 7: 10/32 116/544 (1008.52s) (0
> failed) (devtool.DevtoolUpgradeTests.test_devtool_modify_kernel_overrides)
> 2023-10-17 23:07:15,681 - oe-selftest - INFO -
> testtools.testresult.real._StringException: Traceback (most recent call last):
> File "/home/pokybuild/yocto-worker/oe-selftest-
> centos/build/meta/lib/oeqa/selftest/cases/devtool.py", line 2236, in
> test_devtool_modify_kernel_overrides
> self.assertSetEqual(set(tags), {"devtool-base", "devtool-patched"})
> File "/usr/lib64/python3.9/unittest/case.py", line 1097, in assertSetEqual
> self.fail(self._formatMessage(msg, standardMsg))
> File "/usr/lib64/python3.9/unittest/case.py", line 676, in fail
> raise self.failureException(msg)
> AssertionError: Items in the second set but not the first:
> 'devtool-base'
>
> https://nam12.safelinks.protection.outlook.com/?url=https%3A%2F%2Fautobu
> ilder.yoctoproject.org%2Ftyphoon%2F%23%2Fbuilders%2F79%2Fbuilds%2F592
> 7%2Fsteps%2F14%2Flogs%2Fstdio=05%7C01%7Cchris.laplante%40agilen
> t.com%7Ce69a6029f8c8428f140208dbd009d811%7Ca9c0bc098b46420693512b
> a12fb4a5c0%7C0%7C0%7C638332512937141361%7CUnknown%7CTWFpbGZsb
> 3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%
> 3D%7C3000%7C%7C%7C=ptHcRf3P8%2Fg6G%2BgA2ZXR6SSVuKJcZGOR
> UwUzbYoJ70E%3D=0
I'm unable to reproduce this failure locally. Is there any way to grab the temp
directories or otherwise access the filesystem on the Autobuilder to see what's
going on? I suspect the answer is 'no', but just thought I'd ask.
Thanks,
Chris
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189475):
https://lists.openembedded.org/g/openembedded-core/message/189475
Mute This Topic: https://lists.openembedded.org/mt/101926734/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] bb-matrix-plot.sh: Show underscores correctly in labels
Underscores previously caused the next character in the label to be printed using subscript due to the enhanced string support in gnuplot. Signed-off-by: Peter Kjellerstedt --- scripts/contrib/bb-perf/bb-matrix-plot.sh | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/scripts/contrib/bb-perf/bb-matrix-plot.sh b/scripts/contrib/bb-perf/bb-matrix-plot.sh index e7bd129e9e..6672189c95 100755 --- a/scripts/contrib/bb-perf/bb-matrix-plot.sh +++ b/scripts/contrib/bb-perf/bb-matrix-plot.sh @@ -16,8 +16,8 @@ # Setup the defaults DATFILE="bb-matrix.dat" -XLABEL="BB_NUMBER_THREADS" -YLABEL="PARALLEL_MAKE" +XLABEL="BB_NUMBER_THREADS" +YLABEL="PARALLEL_MAKE" FIELD=3 DEF_TITLE="Elapsed Time (seconds)" PM3D_FRAGMENT="unset surface; set pm3d at s hidden3d 100" -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189474): https://lists.openembedded.org/g/openembedded-core/message/189474 Mute This Topic: https://lists.openembedded.org/mt/102063102/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3.rc1)
On Thu, 2023-10-19 at 14:06 +, Jing Hui Tham wrote: > Hi all, > > Intel and WR YP QA is planning for QA execution for YP build yocto-4.3.rc1. > We are planning to execute following tests for this cycle: > > OEQA-manual tests for following module: > 1. OE-Core > 2. BSP-hw > > Runtime auto test for following platforms: > 1. MinnowBoard Turbot - 32bit > 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) > 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) > 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) > 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) > 6. Beaglebone > > > ETA for completion next Tuesday, October 24. We've realised there is a nasty bug in rc1 related to patchtest deleting local changes. Given the build failure in the rc1 build and other security issues we're thinking we should make an rc2 build and abandon rc1. Sorry for the churn. The new build should be ready soon with any luck. Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189473): https://lists.openembedded.org/g/openembedded-core/message/189473 Mute This Topic: https://lists.openembedded.org/mt/102060626/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] linux-yocto/6.5: config: remove VIDEO_STK1160_COMMON
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/.:
4531e74daf0 media/media-usb-tv.cfg: remove VIDEO_STK1160_COMMON
Signed-off-by: Bruce Ashfield
---
Apply this before the recently sent serial core fixup patch.
Bruce
meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_6.5.bb | 2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
index ff61a33db6..985490e5e5 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
@@ -15,7 +15,7 @@ python () {
}
SRCREV_machine ?= "541ff832e9f2a168145f96ff41857a6cf1c74289"
-SRCREV_meta ?= "7686d2c442df26daa77f91098f7fac8fdf5b35d7"
+SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
\
git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.5;destsuffix=${KMETA};protocol=https"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
index 6ed9972549..e2214851ab 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
@@ -18,7 +18,7 @@ KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
SRCREV_machine ?= "8ad515e79001700d5e3d36e6ffe37ebdae2b5cd4"
-SRCREV_meta ?= "7686d2c442df26daa77f91098f7fac8fdf5b35d7"
+SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
PV = "${LINUX_VERSION}+git"
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto_6.5.bb
index f63b93ce49..bd99b54bce 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.5.bb
@@ -29,7 +29,7 @@ SRCREV_machine:qemux86 ?=
"79a314e29b53062b4dfd316569d5480ee0d19249"
SRCREV_machine:qemux86-64 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
SRCREV_machine:qemumips64 ?= "59ac3aaf836bd355d0f9f734e7bcca3dde44573a"
SRCREV_machine ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_meta ?= "7686d2c442df26daa77f91098f7fac8fdf5b35d7"
+SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
# set your preferred provider of linux-yocto to 'linux-yocto-upstream', and
you'll
# get the /base branch, which is pure upstream -stable, and the same
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189472):
https://lists.openembedded.org/g/openembedded-core/message/189472
Mute This Topic: https://lists.openembedded.org/mt/102062619/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] linux-yocto/6.5: serial: core: integrate upstream fixes
On Thu, 2023-10-19 at 11:08 -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield
>
> Integrating the following commit(s) to linux-yocto/6.5:
>
> 14f83e409308 serial: core: test for -EINPROGRESS during tx power
> management validation
> 1b5b735f311f serial: core: Fix checks for tx runtime PM state
> dee98a75d75c Revert "serial-core: disable power managment for serial tx"
Thanks, these changes look good.
>
> Signed-off-by: Bruce Ashfield
> ---
> .../linux/linux-yocto-rt_6.5.bb | 2 +-
> .../linux/linux-yocto-tiny_6.5.bb | 2 +-
> meta/recipes-kernel/linux/linux-yocto_6.5.bb | 22 +--
> 3 files changed, 13 insertions(+), 13 deletions(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
> b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
> index 985490e5e5..598280c5b6 100644
> --- a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
> @@ -14,7 +14,7 @@ python () {
> raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
> linux-yocto-rt to enable it")
> }
>
> -SRCREV_machine ?= "541ff832e9f2a168145f96ff41857a6cf1c74289"
> +SRCREV_machine ?= "2aa14dbb8520e59358778a80b32d7ccf6dd6c2ac"
> SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
>
The patch doesn't want to apply unfortunately, locally (and on master)
I have:
SRCREV_machine ?= "541ff832e9f2a168145f96ff41857a6cf1c74289"
SRCREV_meta ?= "7686d2c442df26daa77f91098f7fac8fdf5b35d7"
for the rt recipe for example so the meta revisions are different. Did
I miss a patch?
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189471):
https://lists.openembedded.org/g/openembedded-core/message/189471
Mute This Topic: https://lists.openembedded.org/mt/102061865/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v3] rust: Upgrade 1.70.0 -> 1.71.0
Hi Alex, We may look into rust oe-selftest issues during coming week. FYI... We did rust upgrade to 1.73.0 and we could still see the "-Z nightly build flag" failure issue (which was initially observed with rust 1.72.0 upgrade). We will send the patch by tomorrow and you can consider that for your analysis. Thanks, Sundeep K. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189470): https://lists.openembedded.org/g/openembedded-core/message/189470 Mute This Topic: https://lists.openembedded.org/mt/100936266/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Detecting unimplemented ptests with heuristics
Hi Yoann On 19.10.23 at 10:00, Yoann Congal wrote: Hi everyone, We recently implemented a way to detect recipes for upstream code that contain unit tests but does not implement ptests. Those recipes make good candidates for increasing the ptests coverage. This is implemented as a QA check. The check is disabled by default since it generates a lot of warning at build. In order to activate it (in local.conf for exemple) : WARN_QA += "unimplemented-ptest" The warnings looks like: WARNING: time-1.9-r0 do_patch: QA Issue: time: autotools-based tests detected [unimplemented-ptest] I've generated the list for the unimplemented ptests for oe-core and for meta-openembedded: 329 unimplemented-ptests_oe-core.log: https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_oe-core-log 1080 unimplemented-ptests_meta-openembedded.log: https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_meta-openembedded-log Thanks, indeed, I "own" recipes that were flagged :) Maybe, you could find a way to notify the maintainers of such recipes, as in the AUH upgrade status reports (https://lists.openembedded.org/g/openembedded-core/message/188589 for example). Cheers Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189469): https://lists.openembedded.org/g/openembedded-core/message/189469 Mute This Topic: https://lists.openembedded.org/mt/102056219/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] linux-yocto/6.5: serial: core: integrate upstream fixes
From: Bruce Ashfield
Integrating the following commit(s) to linux-yocto/6.5:
14f83e409308 serial: core: test for -EINPROGRESS during tx power management
validation
1b5b735f311f serial: core: Fix checks for tx runtime PM state
dee98a75d75c Revert "serial-core: disable power managment for serial tx"
Signed-off-by: Bruce Ashfield
---
.../linux/linux-yocto-rt_6.5.bb | 2 +-
.../linux/linux-yocto-tiny_6.5.bb | 2 +-
meta/recipes-kernel/linux/linux-yocto_6.5.bb | 22 +--
3 files changed, 13 insertions(+), 13 deletions(-)
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
index 985490e5e5..598280c5b6 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.5.bb
@@ -14,7 +14,7 @@ python () {
raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to
linux-yocto-rt to enable it")
}
-SRCREV_machine ?= "541ff832e9f2a168145f96ff41857a6cf1c74289"
+SRCREV_machine ?= "2aa14dbb8520e59358778a80b32d7ccf6dd6c2ac"
SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
SRC_URI =
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
\
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
index e2214851ab..b047ab340b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.5.bb
@@ -17,7 +17,7 @@ DEPENDS += "openssl-native util-linux-native"
KMETA = "kernel-meta"
KCONF_BSP_AUDIT_LEVEL = "2"
-SRCREV_machine ?= "8ad515e79001700d5e3d36e6ffe37ebdae2b5cd4"
+SRCREV_machine ?= "dfe7f47645429e162819c3d5690d8f5052f5b5a3"
SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
PV = "${LINUX_VERSION}+git"
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.5.bb
b/meta/recipes-kernel/linux/linux-yocto_6.5.bb
index bd99b54bce..516605c587 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.5.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.5.bb
@@ -18,17 +18,17 @@ KBRANCH:qemux86-64 ?= "v6.5/standard/base"
KBRANCH:qemuloongarch64 ?= "v6.5/standard/base"
KBRANCH:qemumips64 ?= "v6.5/standard/mti-malta64"
-SRCREV_machine:qemuarm ?= "e3bd53c181eb362535991bb0e0c15bf7b8b8e86f"
-SRCREV_machine:qemuarm64 ?= "cd01efb6992e0af5dfef251420291d5984898a9c"
-SRCREV_machine:qemuloongarch64 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_machine:qemumips ?= "76f1c7370493dd6068f6733eb7d6ff9da6e7fae8"
-SRCREV_machine:qemuppc ?= "a3ac3f52f2352476f0fb1b0b4fe7b1c2339f9b18"
-SRCREV_machine:qemuriscv64 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_machine:qemuriscv32 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_machine:qemux86 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_machine:qemux86-64 ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
-SRCREV_machine:qemumips64 ?= "59ac3aaf836bd355d0f9f734e7bcca3dde44573a"
-SRCREV_machine ?= "79a314e29b53062b4dfd316569d5480ee0d19249"
+SRCREV_machine:qemuarm ?= "04942abac8568705f1fae34066db171b6e2669bd"
+SRCREV_machine:qemuarm64 ?= "ea4b620f18f882b3d882a53ffa33d8125ab27c83"
+SRCREV_machine:qemuloongarch64 ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
+SRCREV_machine:qemumips ?= "3348b580e3c47da56ce97a8297a574c2e37bc410"
+SRCREV_machine:qemuppc ?= "2fd47e07960edcd21455548ac6a25b19babe5c10"
+SRCREV_machine:qemuriscv64 ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
+SRCREV_machine:qemuriscv32 ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
+SRCREV_machine:qemux86 ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
+SRCREV_machine:qemux86-64 ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
+SRCREV_machine:qemumips64 ?= "6706327d870a0f246df8ed20c6a7f51ef46db1d6"
+SRCREV_machine ?= "14f83e40930806c3f5c61988e69a3ca1820a1b8f"
SRCREV_meta ?= "9af846da534077c91e3c42242fceba7aef8dd784"
# set your preferred provider of linux-yocto to 'linux-yocto-upstream', and
you'll
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189468):
https://lists.openembedded.org/g/openembedded-core/message/189468
Mute This Topic: https://lists.openembedded.org/mt/102061865/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] kea: drop unused directory
the usage of /var/kea was dropped in the 1.6 release (see https://gitlab.isc.org/isc-projects/kea/-/issues/538 ). Creating the directory fails on systems with read-only rootfs. Signed-off-by: Thomas Wolber Signed-off-by: Vyacheslav Yurkov --- meta/recipes-connectivity/kea/files/kea-dhcp-ddns.service | 1 - 1 file changed, 1 deletion(-) diff --git a/meta/recipes-connectivity/kea/files/kea-dhcp-ddns.service b/meta/recipes-connectivity/kea/files/kea-dhcp-ddns.service index 91aa2eb14f..f6059d73cb 100644 --- a/meta/recipes-connectivity/kea/files/kea-dhcp-ddns.service +++ b/meta/recipes-connectivity/kea/files/kea-dhcp-ddns.service @@ -6,7 +6,6 @@ After=time-sync.target [Service] ExecStartPre=@BASE_BINDIR@/mkdir -p @LOCALSTATEDIR@/run/kea/ -ExecStartPre=@BASE_BINDIR@/mkdir -p @LOCALSTATEDIR@/kea ExecStart=@SBINDIR@/kea-dhcp-ddns -c @SYSCONFDIR@/kea/kea-dhcp-ddns.conf [Install] -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189467): https://lists.openembedded.org/g/openembedded-core/message/189467 Mute This Topic: https://lists.openembedded.org/mt/102061566/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Using devtool without an absolute path to the workspace in bblayers.conf
On Thursday 19 October 2023 at 14:51:56 +0200, Alexander Kanavin wrote: > On Thu, 19 Oct 2023 at 14:33, Mike Crowe via lists.openembedded.org > wrote: > > We do need to modify bblayers.conf from time to time to add and remove > > layers. > > > > Using templates might be possible, but it would appear that this would > > force developers to manually incorporate changes (or just wipe their > > bblayers.conf file) when the template changes. Just keeping bblayers.conf > > under version control doesn't suffer from that problem. > > Generally content of build/conf/, or anything else in build/ is not > designed for being under version control. You may be able to get away > with it by coincidence, but it's neither documented nor tested, and so > any issues are your own. > > I don't have a quick solution to ensure that templates and > configurations coming from them are strictly in sync, but welcome to > suggestions. People modify local.conf and bblayers.conf all the time > as well for local experiments, you're simply not supposed to lock them > down. There's no problem with modifying them for local experiments, even if they are under version control, but it's clear when those experiments need to be committed that those files need to be committed too. However, it's clear that I'm pushing against the tide. I'll stick with the early-return hack in devtool for the short term to see if we come across any other reasons to make changes or any other breakage. Once everything is working I'll investigate our options for not keeping bblayers.conf under version control. Thanks for you help. Mike. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189466): https://lists.openembedded.org/g/openembedded-core/message/189466 Mute This Topic: https://lists.openembedded.org/mt/102039990/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/2] patchtest: sort when reading patches from a directory
On 2023-10-19 09:40, Ross Burton wrote: From: Ross Burton When reading patches from a directory it's important to sort the output of os.listdir(), as that returns the files in an effectively random order. We can't test the patches apply if they're applied in the wrong order, and typically patch filenames are prefixed with a counter to ensure the order is correct. Thanks for the patch. I like this as a general improvement and preparation for future fixes, but this might not have the results you're expecting (right now) - patchtest currently has a known limitation where it only tests patches one-at-a-time, so if you have multiple patches depending on previous entries in the series, they will not apply them in the sequence and you may get erroneous failures for the merge-on-head test. That's on the roadmap for upcoming improvements. Signed-off-by: Ross Burton --- scripts/patchtest | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/patchtest b/scripts/patchtest index 642486b8c7f..c47b05b7d47 100755 --- a/scripts/patchtest +++ b/scripts/patchtest @@ -172,7 +172,7 @@ def main(): patch_list = None if os.path.isdir(patch_path): -patch_list = [os.path.join(patch_path, filename) for filename in os.listdir(patch_path)] +patch_list = [os.path.join(patch_path, filename) for filename in sorted(os.listdir(patch_path))] else: patch_list = [patch_path] -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189465): https://lists.openembedded.org/g/openembedded-core/message/189465 Mute This Topic: https://lists.openembedded.org/mt/102060105/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
On Thu, Oct 19, 2023 at 6:49 AM Alexandre Belloni via lists.openembedded.org
wrote:
> Hello,
>
> On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> > add support for PEP517 [1]
> >
> > if a pyproject.toml file is found, use it to create the recipe,
> > otherwise fallback to the old setup.py method.
> >
> > [YOCTO #14737]
> >
> > [1]: https://peps.python.org/pep-0517/
> >
> > Signed-off-by: Julien Stephan
> > ---
> > .../lib/recipetool/create_buildsys_python.py | 234 +-
> > 1 file changed, 233 insertions(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/recipetool/create_buildsys_python.py
> b/scripts/lib/recipetool/create_buildsys_python.py
> > index 69f6f5ca511..0b601d50a4b 100644
> > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > @@ -18,6 +18,7 @@ import os
> > import re
> > import sys
> > import subprocess
> > +import toml
>
> This fails on the autobuilders because we don't have the toml module
> installed so I guess you need to add a dependency.
>
>
Starting in Python 3.11, we have tomllib
https://docs.python.org/3/library/tomllib.html
However, we currently pin the minimum Python version at 3.8:
https://git.yoctoproject.org/poky/tree/bitbake/lib/bb/__init__.py#n15
> from recipetool.create import RecipeHandler
> >
> > logger = logging.getLogger('recipetool')
> > @@ -656,6 +657,235 @@ class
> PythonSetupPyRecipeHandler(PythonRecipeHandler):
> >
> > handled.append('buildsystem')
> >
> > +class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
> > +"""Base class to support PEP517 and PEP518
> > +
> > +PEP517 https://peps.python.org/pep-0517/#source-trees
> > +PEP518 https://peps.python.org/pep-0518/#build-system-table
> > +"""
> > +
> > +# PEP621:
> https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
> > +# add only the ones that map to a BB var
> > +# potentially missing: optional-dependencies
> > +bbvar_map = {
> > +"name": "PN",
> > +"version": "PV",
> > +"Homepage": "HOMEPAGE",
> > +"description": "SUMMARY",
> > +"license": "LICENSE",
> > +"dependencies": "RDEPENDS:${PN}",
> > +"requires": "DEPENDS",
> > +}
> > +
> > +replacements = [
> > +("license", r" +$", ""),
> > +("license", r"^ +", ""),
> > +("license", r" ", "-"),
> > +("license", r"^GNU-", ""),
> > +("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
> > +("license", r"^UNKNOWN$", ""),
> > +# Remove currently unhandled version numbers from these
> variables
> > +("requires", r"\[[^\]]+\]$", ""),
> > +("requires", r"^([^><= ]+).*", r"\1"),
> > +("dependencies", r"\[[^\]]+\]$", ""),
> > +("dependencies", r"^([^><= ]+).*", r"\1"),
> > +]
> > +
> > +build_backend_map = {
> > +"setuptools.build_meta": "python_setuptools_build_meta",
> > +"poetry.core.masonry.api": "python_poetry_core",
> > +"flit_core.buildapi": "python_flit_core",
> > +}
> > +
> > +excluded_native_pkgdeps = [
> > +# already provided by python_setuptools_build_meta.bbclass
> > +"python3-setuptools-native",
> > +"python3-wheel-native",
> > +# already provided by python_poetry_core.bbclass
> > +"python3-poetry-core-native",
> > +# already provided by python_flit_core.bbclass
> > +"python3-flit-core-native",
> > +]
> > +
> > +# add here a list of known and often used packages and the
> corresponding bitbake package
> > +known_deps_map = {
> > +"setuptools": "python3-setuptools",
> > +"wheel": "python3-wheel",
> > +"poetry-core": "python3-poetry-core",
> > +"flit_core": "python3-flit-core",
> > +"setuptools-scm": "python3-setuptools-scm",
> > +}
> > +
> > +def __init__(self):
> > +pass
> > +
> > +def process(self, srctree, classes, lines_before, lines_after,
> handled, extravalues):
> > +info = {}
> > +
> > +if 'buildsystem' in handled:
> > +return False
> > +
> > +# Check for non-zero size setup.py files
> > +setupfiles = RecipeHandler.checkfiles(srctree,
> ["pyproject.toml"])
> > +for fn in setupfiles:
> > +if os.path.getsize(fn):
> > +break
> > +else:
> > +return False
> > +
> > +setupscript = os.path.join(srctree, "pyproject.toml")
> > +
> > +try:
> > +config = self.parse_pyproject_toml(setupscript)
> > +build_backend = config["build-system"]["build-backend"]
> > +if build_backend in self.build_backend_map:
> > +classes.append(self.build_backend_map[build_backend])
> > +else:
> > +logger.error(
> > +"Unsupported build-backend: %s, cannot use
> pyproject.toml. Will try to use
Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.3.rc1)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-4.3.rc1. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowBoard Turbot - 32bit 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) 6. Beaglebone ETA for completion next Tuesday, October 24. Best regards, Jing Hui > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Wednesday, October 18, 2023 2:16 PM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [qa-build-notification] QA notification for completed autobuilder > build (yocto-4.3.rc1) > > > A build flagged for QA (yocto-4.3.rc1) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-4.3.rc1 > > > Build URL: > https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6062 > > Build hash information: > > bitbake: 5419a8473d6d4cd1d01537de68ad8d72cf5be0b2 > meta-agl: 4063b4f9a712e32337c1d9678b2f2481dde2a346 > meta-arm: 3ed13d25a065f29bd46ee725c708d12ebc3f175a > meta-aws: a30a2b66f1447dc5abdbca6c5de743e39c08b99b > meta-intel: 1bca60610c597571769edc4a057a04bfdbd2f994 > meta-mingw: 65ef95a74f6ae815f63f636ed53e140a26a014ce > meta-openembedded: 35bcd8c6ddfb6bc8729d0006dab887afcc772ec9 > meta-virtualization: 827092c2ec925ea3a024dcda9ccfd738e351e6ba > oecore: 4f84537670020a8d902248479efa9f062089c0d3 > poky: f65f100bc5379c3153ee00b2aa62ea5c9a66ec79 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189463): https://lists.openembedded.org/g/openembedded-core/message/189463 Mute This Topic: https://lists.openembedded.org/mt/102060626/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
Hello,
On 19/10/2023 09:36:53+0200, Julien Stephan wrote:
> add support for PEP517 [1]
>
> if a pyproject.toml file is found, use it to create the recipe,
> otherwise fallback to the old setup.py method.
>
> [YOCTO #14737]
>
> [1]: https://peps.python.org/pep-0517/
>
> Signed-off-by: Julien Stephan
> ---
> .../lib/recipetool/create_buildsys_python.py | 234 +-
> 1 file changed, 233 insertions(+), 1 deletion(-)
>
> diff --git a/scripts/lib/recipetool/create_buildsys_python.py
> b/scripts/lib/recipetool/create_buildsys_python.py
> index 69f6f5ca511..0b601d50a4b 100644
> --- a/scripts/lib/recipetool/create_buildsys_python.py
> +++ b/scripts/lib/recipetool/create_buildsys_python.py
> @@ -18,6 +18,7 @@ import os
> import re
> import sys
> import subprocess
> +import toml
This fails on the autobuilders because we don't have the toml module installed
so I guess you need to add a dependency.
> from recipetool.create import RecipeHandler
>
> logger = logging.getLogger('recipetool')
> @@ -656,6 +657,235 @@ class PythonSetupPyRecipeHandler(PythonRecipeHandler):
>
> handled.append('buildsystem')
>
> +class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
> +"""Base class to support PEP517 and PEP518
> +
> +PEP517 https://peps.python.org/pep-0517/#source-trees
> +PEP518 https://peps.python.org/pep-0518/#build-system-table
> +"""
> +
> +# PEP621:
> https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
> +# add only the ones that map to a BB var
> +# potentially missing: optional-dependencies
> +bbvar_map = {
> +"name": "PN",
> +"version": "PV",
> +"Homepage": "HOMEPAGE",
> +"description": "SUMMARY",
> +"license": "LICENSE",
> +"dependencies": "RDEPENDS:${PN}",
> +"requires": "DEPENDS",
> +}
> +
> +replacements = [
> +("license", r" +$", ""),
> +("license", r"^ +", ""),
> +("license", r" ", "-"),
> +("license", r"^GNU-", ""),
> +("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
> +("license", r"^UNKNOWN$", ""),
> +# Remove currently unhandled version numbers from these variables
> +("requires", r"\[[^\]]+\]$", ""),
> +("requires", r"^([^><= ]+).*", r"\1"),
> +("dependencies", r"\[[^\]]+\]$", ""),
> +("dependencies", r"^([^><= ]+).*", r"\1"),
> +]
> +
> +build_backend_map = {
> +"setuptools.build_meta": "python_setuptools_build_meta",
> +"poetry.core.masonry.api": "python_poetry_core",
> +"flit_core.buildapi": "python_flit_core",
> +}
> +
> +excluded_native_pkgdeps = [
> +# already provided by python_setuptools_build_meta.bbclass
> +"python3-setuptools-native",
> +"python3-wheel-native",
> +# already provided by python_poetry_core.bbclass
> +"python3-poetry-core-native",
> +# already provided by python_flit_core.bbclass
> +"python3-flit-core-native",
> +]
> +
> +# add here a list of known and often used packages and the corresponding
> bitbake package
> +known_deps_map = {
> +"setuptools": "python3-setuptools",
> +"wheel": "python3-wheel",
> +"poetry-core": "python3-poetry-core",
> +"flit_core": "python3-flit-core",
> +"setuptools-scm": "python3-setuptools-scm",
> +}
> +
> +def __init__(self):
> +pass
> +
> +def process(self, srctree, classes, lines_before, lines_after, handled,
> extravalues):
> +info = {}
> +
> +if 'buildsystem' in handled:
> +return False
> +
> +# Check for non-zero size setup.py files
> +setupfiles = RecipeHandler.checkfiles(srctree, ["pyproject.toml"])
> +for fn in setupfiles:
> +if os.path.getsize(fn):
> +break
> +else:
> +return False
> +
> +setupscript = os.path.join(srctree, "pyproject.toml")
> +
> +try:
> +config = self.parse_pyproject_toml(setupscript)
> +build_backend = config["build-system"]["build-backend"]
> +if build_backend in self.build_backend_map:
> +classes.append(self.build_backend_map[build_backend])
> +else:
> +logger.error(
> +"Unsupported build-backend: %s, cannot use
> pyproject.toml. Will try to use legacy setup.py"
> +% build_backend
> +)
> +return False
> +
> +licfile = ""
> +if "project" in config:
> +for field, values in config["project"].items():
> +if field == "license":
> +value = values.get("text", "")
> +if not value:
> +licfile = values.get("file", "")
> +elif isinstance(values, dict):
> +for k,
[OE-core][PATCH] patchtest: check for untracked changes
[YOCTO #15243]
Avoid overwriting local changes when running patchtest by checking for
anything unstaged or uncommitted in the target repo, and logging an
error if something is found. This will provide the user helpful feedback
if (for example) they forgot to commit a change for their patch under
test, and will leave the target repository in a reasonable state (rather
than a temporary branch created by patchtest).
Signed-off-by: Trevor Gamblin
---
scripts/patchtest | 6 ++
1 file changed, 6 insertions(+)
diff --git a/scripts/patchtest b/scripts/patchtest
index 642486b8c7f..be40e4b2a47 100755
--- a/scripts/patchtest
+++ b/scripts/patchtest
@@ -171,6 +171,12 @@ def main():
log_path = None
patch_list = None
+git_status = os.popen("(cd %s && git status)" %
PatchTestInput.repodir).read()
+status_matches = ["Changes not staged for commit", "Changes to be
committed"]
+if any([match in git_status for match in status_matches]):
+logger.error("patchtest: there are uncommitted changes in the target
repo that would be overwritten. Please commit or restore them before running
patchtest")
+return 1
+
if os.path.isdir(patch_path):
patch_list = [os.path.join(patch_path, filename) for filename in
os.listdir(patch_path)]
else:
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189461):
https://lists.openembedded.org/g/openembedded-core/message/189461
Mute This Topic: https://lists.openembedded.org/mt/102060207/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] patchtest: remove unused imports
From: Ross Burton
Signed-off-by: Ross Burton
---
meta/lib/patchtest/data.py | 1 -
meta/lib/patchtest/repo.py | 1 -
meta/lib/patchtest/tests/test_mbox_cve.py | 1 -
meta/lib/patchtest/tests/test_mbox_mailinglist.py | 1 -
meta/lib/patchtest/tests/test_metadata_src_uri.py | 1 -
meta/lib/patchtest/tests/test_patch_cve.py | 1 -
meta/lib/patchtest/tests/test_patch_upstream_status.py | 1 -
meta/lib/patchtest/utils.py| 1 -
scripts/patchtest | 1 -
scripts/patchtest-get-branch | 1 -
10 files changed, 10 deletions(-)
diff --git a/meta/lib/patchtest/data.py b/meta/lib/patchtest/data.py
index 25a9a57dfb1..356259921da 100644
--- a/meta/lib/patchtest/data.py
+++ b/meta/lib/patchtest/data.py
@@ -16,7 +16,6 @@
import os
import argparse
import collections
-import tempfile
import logging
logger=logging.getLogger('patchtest')
diff --git a/meta/lib/patchtest/repo.py b/meta/lib/patchtest/repo.py
index 8a11af5fd66..d3788f466d3 100644
--- a/meta/lib/patchtest/repo.py
+++ b/meta/lib/patchtest/repo.py
@@ -11,7 +11,6 @@
import os
import utils
import logging
-import json
from patch import PatchTestPatch
logger = logging.getLogger('patchtest')
diff --git a/meta/lib/patchtest/tests/test_mbox_cve.py
b/meta/lib/patchtest/tests/test_mbox_cve.py
index 31faeb5ef5a..29ab12cbb53 100644
--- a/meta/lib/patchtest/tests/test_mbox_cve.py
+++ b/meta/lib/patchtest/tests/test_mbox_cve.py
@@ -6,7 +6,6 @@
#
import base
-import os
import parse_cve_tags
import pyparsing
diff --git a/meta/lib/patchtest/tests/test_mbox_mailinglist.py
b/meta/lib/patchtest/tests/test_mbox_mailinglist.py
index 0ffb6056c08..feff4360894 100644
--- a/meta/lib/patchtest/tests/test_mbox_mailinglist.py
+++ b/meta/lib/patchtest/tests/test_mbox_mailinglist.py
@@ -4,7 +4,6 @@
#
# SPDX-License-Identifier: GPL-2.0-only
-import subprocess
import collections
import base
import pyparsing
diff --git a/meta/lib/patchtest/tests/test_metadata_src_uri.py
b/meta/lib/patchtest/tests/test_metadata_src_uri.py
index 01d8a451037..87a24ea937e 100644
--- a/meta/lib/patchtest/tests/test_metadata_src_uri.py
+++ b/meta/lib/patchtest/tests/test_metadata_src_uri.py
@@ -4,7 +4,6 @@
#
# SPDX-License-Identifier: GPL-2.0-only
-import subprocess
import base
import os
import pyparsing
diff --git a/meta/lib/patchtest/tests/test_patch_cve.py
b/meta/lib/patchtest/tests/test_patch_cve.py
index c0c7e742ee1..c77848de458 100644
--- a/meta/lib/patchtest/tests/test_patch_cve.py
+++ b/meta/lib/patchtest/tests/test_patch_cve.py
@@ -6,7 +6,6 @@
#
import base
-import os
import pyparsing
class CVE(base.Base):
diff --git a/meta/lib/patchtest/tests/test_patch_upstream_status.py
b/meta/lib/patchtest/tests/test_patch_upstream_status.py
index 957817ba8d9..a5b278304e6 100644
--- a/meta/lib/patchtest/tests/test_patch_upstream_status.py
+++ b/meta/lib/patchtest/tests/test_patch_upstream_status.py
@@ -7,7 +7,6 @@
import base
import parse_upstream_status
import pyparsing
-import os
class PatchUpstreamStatus(base.Base):
diff --git a/meta/lib/patchtest/utils.py b/meta/lib/patchtest/utils.py
index 8dcac30941e..a4a523b4e25 100644
--- a/meta/lib/patchtest/utils.py
+++ b/meta/lib/patchtest/utils.py
@@ -11,7 +11,6 @@
import os
import subprocess
import logging
-import sys
import re
import mailbox
diff --git a/scripts/patchtest b/scripts/patchtest
index c47b05b7d47..00c73610fcd 100755
--- a/scripts/patchtest
+++ b/scripts/patchtest
@@ -12,7 +12,6 @@
import sys
import os
import unittest
-import fileinput
import logging
import traceback
import json
diff --git a/scripts/patchtest-get-branch b/scripts/patchtest-get-branch
index 962f572b20c..b5fb2b0f04d 100755
--- a/scripts/patchtest-get-branch
+++ b/scripts/patchtest-get-branch
@@ -15,7 +15,6 @@ import mailbox
import argparse
import re
import git
-import sys
re_prefix = re.compile("(\[.*\])", re.DOTALL)
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189460):
https://lists.openembedded.org/g/openembedded-core/message/189460
Mute This Topic: https://lists.openembedded.org/mt/102060106/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 1/2] patchtest: sort when reading patches from a directory
From: Ross Burton When reading patches from a directory it's important to sort the output of os.listdir(), as that returns the files in an effectively random order. We can't test the patches apply if they're applied in the wrong order, and typically patch filenames are prefixed with a counter to ensure the order is correct. Signed-off-by: Ross Burton --- scripts/patchtest | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/patchtest b/scripts/patchtest index 642486b8c7f..c47b05b7d47 100755 --- a/scripts/patchtest +++ b/scripts/patchtest @@ -172,7 +172,7 @@ def main(): patch_list = None if os.path.isdir(patch_path): -patch_list = [os.path.join(patch_path, filename) for filename in os.listdir(patch_path)] +patch_list = [os.path.join(patch_path, filename) for filename in sorted(os.listdir(patch_path))] else: patch_list = [patch_path] -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189459): https://lists.openembedded.org/g/openembedded-core/message/189459 Mute This Topic: https://lists.openembedded.org/mt/102060105/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore][PATCH] weston: default to launcher-seatd
Lets use the launcher-seatd as default, launcher-logind is "sometimes"
failing to provide input events. Further more is the launcher-logind
depricated in newer versions of weston.
Signed-off-by: Sean Nyekjaer
---
meta/recipes-graphics/wayland/weston_11.0.1.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston_11.0.1.bb
b/meta/recipes-graphics/wayland/weston_11.0.1.bb
index 0838791a6b..09753e7c51 100644
--- a/meta/recipes-graphics/wayland/weston_11.0.1.bb
+++ b/meta/recipes-graphics/wayland/weston_11.0.1.bb
@@ -37,7 +37,7 @@ PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES',
'wayland', 'kms wayla
${@bb.utils.contains('DISTRO_FEATURES', 'x11 wayland',
'xwayland', '', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'systemd x11', d)} \
${@bb.utils.contains_any('DISTRO_FEATURES', 'wayland x11',
'', 'headless', d)} \
- ${@oe.utils.conditional('VIRTUAL-RUNTIME_init_manager',
'sysvinit', 'launcher-libseat', '', d)} \
+ launcher-libseat \
image-jpeg \
screenshare \
shell-desktop \
@@ -71,7 +71,7 @@ PACKAGECONFIG[lcms] =
"-Dcolor-management-lcms=true,-Dcolor-management-lcms=fals
# Weston with webp support
PACKAGECONFIG[webp] = "-Dimage-webp=true,-Dimage-webp=false,libwebp"
# Weston with systemd-login support
-PACKAGECONFIG[systemd] = "-Dsystemd=true
-Dlauncher-logind=true,-Dsystemd=false -Dlauncher-logind=false,systemd dbus"
+PACKAGECONFIG[systemd] = "-Dsystemd=true,-Dsystemd=false,systemd dbus"
# Weston with Xwayland support (requires X11 and Wayland)
PACKAGECONFIG[xwayland] = "-Dxwayland=true,-Dxwayland=false,libxcb libxcursor
xwayland"
# colord CMS support
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189458):
https://lists.openembedded.org/g/openembedded-core/message/189458
Mute This Topic: https://lists.openembedded.org/mt/102059907/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Using devtool without an absolute path to the workspace in bblayers.conf
On Thu, 19 Oct 2023 at 14:33, Mike Crowe via lists.openembedded.org wrote: > We do need to modify bblayers.conf from time to time to add and remove > layers. > > Using templates might be possible, but it would appear that this would > force developers to manually incorporate changes (or just wipe their > bblayers.conf file) when the template changes. Just keeping bblayers.conf > under version control doesn't suffer from that problem. Generally content of build/conf/, or anything else in build/ is not designed for being under version control. You may be able to get away with it by coincidence, but it's neither documented nor tested, and so any issues are your own. I don't have a quick solution to ensure that templates and configurations coming from them are strictly in sync, but welcome to suggestions. People modify local.conf and bblayers.conf all the time as well for local experiments, you're simply not supposed to lock them down. Alex Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189457): https://lists.openembedded.org/g/openembedded-core/message/189457 Mute This Topic: https://lists.openembedded.org/mt/102039990/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
On Thu, 2023-10-19 at 14:32 +0200, Rasmus Villemoes via
lists.openembedded.org wrote:
> From: Rasmus Villemoes
>
> Building perf without security_flags.inc being included in one's
> distro results in the buildpaths warning
>
> WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
> package perf contains reference to TMPDIR
>
> because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
> that from CFLAGS, but the perf recipe explicitly unsets that.
>
> Now ${SELECTED_OPTIMIZATION} of course contains more than just
> ${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
> adds its own optimization flags (-O6 for odd reasons), so for those
> including the -O2 or -Og doesn't change anything. But looking at the
> .o.cmd files show that there are some TUs which currently get built
> without any -O flag. So for those adding the distro's
> SELECTED_OPTIMIZATION seem to be the right thing to do.
>
> Signed-off-by: Rasmus Villemoes
> ---
> meta/conf/distro/include/security_flags.inc | 1 -
> meta/recipes-kernel/perf/perf.bb| 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
The fact this works suggests perf is ignoring TARGET_CFLAGS. Is there
anything in the perf build system where we should be passing in cflags
we really want used?
It feels like the fix is still a little fragile and we should find out
how to get it to use our flags. The security_flags hack really needs to
not be needed.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189456):
https://lists.openembedded.org/g/openembedded-core/message/189456
Mute This Topic: https://lists.openembedded.org/mt/102058904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
Hi,
Could something like this work?
--- a/meta/lib/oe/cve_check.py
+++ b/meta/lib/oe/cve_check.py
@@ -140,15 +140,14 @@ def get_patched_cves(d):
return patched_cves
-def get_cpe_ids(cve_product, version):
+def get_cpe_ids(cve_product, cve_version):
"""
Get list of CPE identifiers for the given product and version
"""
-version = version.split("+git")[0]
-
cpe_ids = []
for product in cve_product.split():
+version = (d.getVar("CVE_VERSION_%s" % product) or
cve_version).split("+git")[0]
# CVE_PRODUCT in recipes may include vendor information for CPE
identifiers. If not,
# use wildcard for vendor.
if ":" in product:
Cheers,
-Mikko
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189455):
https://lists.openembedded.org/g/openembedded-core/message/189455
Mute This Topic: https://lists.openembedded.org/mt/101991269/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: Kernel 6.5 ttyS1 hang with qemu (was Re: [OE-core] Summary of the remaining 6.5 kernel serial issue (and 6.5 summary)
On Wed, 2023-10-18 at 08:28 +0300, Tony Lindgren wrote:
> * Richard Purdie [231017 22:15]:
> > On Tue, 2023-10-17 at 09:56 +0300, Tony Lindgren wrote:
> > > * Richard Purdie [231016 08:10]:
> > > > The port sometimes doesn't come up properly at boot.
> > > >
> > > > To be clear, the "\n\n" from the qemu side into the port doesn't seem
> > > > to help. The "echo helloB > /dev/ttyS1" inside the image does seem to
> > > > wake it up.
> > >
> > > So if I understand correctly, this issue still happens with kernel patched
> > > with commit 81a61051e0ce ("serial: core: Fix checks for tx runtime PM
> > > state"), and the issue now only happens sometimes.
> >
> > The issue has always been intermittent and it appeared to happen less
> > frequently with 81a61051e0ce added but it was hard to know if I was
> > imagining that.
>
> Oh OK.
>
> > > I wonder if the following additional change might help?
> >
> > I've added it into testing and have not reproduced the failure with it
> > applied yet, locally or on our autobuilder. We need to sort some
> > release pieces which have been delayed by these issues and we're going
> > with a workaround for that. Once that is built I can get back to
> > testing this change more extensively, see if we can still provoke the
> > issue or not. It may take a day or two of testing before we know with
> > any certainty if the issue is resolved or not.
>
> Thanks for the update, let's wait a few days and see then.
Our release build failed with our workaround, probably as this piece is
missing.
I've not seen the failure occur in any build with it applied so far. As
such I think we'll move over to this patch as it seems to be better.
Whether it is fixed or not I'm still not 100% sure but it is looking
more likely. Thanks for the patch/fix!
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189454):
https://lists.openembedded.org/g/openembedded-core/message/189454
Mute This Topic: https://lists.openembedded.org/mt/101849211/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
On Thu, Oct 19, 2023 at 8:32 AM Rasmus Villemoes
wrote:
>
> From: Rasmus Villemoes
>
> Building perf without security_flags.inc being included in one's
> distro results in the buildpaths warning
>
> WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
> package perf contains reference to TMPDIR
>
> because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
> that from CFLAGS, but the perf recipe explicitly unsets that.
>
> Now ${SELECTED_OPTIMIZATION} of course contains more than just
> ${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
> adds its own optimization flags (-O6 for odd reasons), so for those
> including the -O2 or -Og doesn't change anything. But looking at the
> .o.cmd files show that there are some TUs which currently get built
> without any -O flag. So for those adding the distro's
> SELECTED_OPTIMIZATION seem to be the right thing to do.
The change is fine with me.
>
> Signed-off-by: Rasmus Villemoes
> ---
> meta/conf/distro/include/security_flags.inc | 1 -
> meta/recipes-kernel/perf/perf.bb| 1 +
> 2 files changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/conf/distro/include/security_flags.inc
> b/meta/conf/distro/include/security_flags.inc
> index 2972f05b4e..d97a6edb0f 100644
> --- a/meta/conf/distro/include/security_flags.inc
> +++ b/meta/conf/distro/include/security_flags.inc
> @@ -69,4 +69,3 @@ SECURITY_LDFLAGS:pn-xserver-xorg = "${SECURITY_X_LDFLAGS}"
> TARGET_CC_ARCH:append:pn-binutils = " ${SELECTED_OPTIMIZATION}"
> TARGET_CC_ARCH:append:pn-gcc = " ${SELECTED_OPTIMIZATION}"
> TARGET_CC_ARCH:append:pn-gdb = " ${SELECTED_OPTIMIZATION}"
> -TARGET_CC_ARCH:append:pn-perf = " ${SELECTED_OPTIMIZATION}"
> diff --git a/meta/recipes-kernel/perf/perf.bb
> b/meta/recipes-kernel/perf/perf.bb
> index 675acfaf26..a6110dedc9 100644
> --- a/meta/recipes-kernel/perf/perf.bb
> +++ b/meta/recipes-kernel/perf/perf.bb
> @@ -72,6 +72,7 @@ SPDX_S = "${S}/tools/perf"
> # symbols and this is preferred than requiring patches to every old
> # supported kernel.
> LDFLAGS="-ldl -lutil"
> +TARGET_CC_ARCH += "${SELECTED_OPTIMIZATION}"
I'd even go so far as to add a comment above the relocated line with a
hint / reminder that this adds the debug prefix map.
Bruce
>
> EXTRA_OEMAKE = '\
> V=1 \
> --
> 2.40.1.1.g1c60b9335d
>
--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189453):
https://lists.openembedded.org/g/openembedded-core/message/189453
Mute This Topic: https://lists.openembedded.org/mt/102058904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] Using devtool without an absolute path to the workspace in bblayers.conf
On Wednesday 18 October 2023 at 17:47:50 +0200, Julien Stephan wrote: > Le mer. 18 oct. 2023 à 16:29, Mike Crowe via lists.openembedded.org > a écrit : > > > > I'm trying to work out how we can make use of devtool to make our lives > > easier during development. In general it seems to work very well, but the > > way that it modifies bblayers.conf to add an absolute path to the workspace > > directory to BBLAYERS is incompatible with that file being held in a Git > > repository and shared by multiple users in multiple trees. There's a high > > risk that the file will accidentally be committed containing a path that's > > only meaningful for a single user in a single source tree. All of our other > > paths in bblayers.conf are relative to a variable that contains the path to > > the top of the source tree. > > Hi Mike, > > I think it is a bad idea to version files under the build directory. Hi Julien, We don't version all files under the build directory, just ones that control the configuration that we want to share. We've been using OE that way for about twelve years now and this is the first time we've run into a problem. That might at least partly be because we haven't taken advantage of newer features like devtool though! We mostly avoided devtool by putting the sources that we modify heavily in submodules and used externalsrc.bbclass (with some local progressively-less-hacky modifications that I should try to upstream sometime.) > Maybe you have a specific use case that you can address in a different way? > You need to share bblayers.conf, I can see 2 options here: > - either you want your co-workers to fetch it only once, when setting > up their source tree > - or you need to frequently modify bblayer.conf because you are adding > or removing layers and want your coworkers to be up-to date > > In the first case, TEMPLATECONF is the way to go! More information > here; > https://docs.yoctoproject.org/ref-manual/variables.html#term-TEMPLATECONF We do need to modify bblayers.conf from time to time to add and remove layers. Using templates might be possible, but it would appear that this would force developers to manually incorporate changes (or just wipe their bblayers.conf file) when the template changes. Just keeping bblayers.conf under version control doesn't suffer from that problem. > In the second scenario, if this is something you *really* need, maybe > you can switch to some other tools such as 'kas' > (https://kas.readthedocs.io/en/latest/) that should be useful here. I have looked at kas in the past (and listened to podcasts about it), but it seemed to solve a different set of problems. I will look at it again. Thanks for the suggestions. Mike -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189452): https://lists.openembedded.org/g/openembedded-core/message/189452 Mute This Topic: https://lists.openembedded.org/mt/102039990/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] perf: lift TARGET_CC_ARCH modification out of security_flags.inc
From: Rasmus Villemoes
Building perf without security_flags.inc being included in one's
distro results in the buildpaths warning
WARNING: perf-1.0-r9 do_package_qa: QA Issue: File /usr/bin/trace in
package perf contains reference to TMPDIR
because the ${DEBUG_PREFIX_MAP} does not get used. Most recipes get
that from CFLAGS, but the perf recipe explicitly unsets that.
Now ${SELECTED_OPTIMIZATION} of course contains more than just
${DEBUG_FLAGS}/${DEBUG_PREFIX_MAP}. For most TUs, perf's build system
adds its own optimization flags (-O6 for odd reasons), so for those
including the -O2 or -Og doesn't change anything. But looking at the
.o.cmd files show that there are some TUs which currently get built
without any -O flag. So for those adding the distro's
SELECTED_OPTIMIZATION seem to be the right thing to do.
Signed-off-by: Rasmus Villemoes
---
meta/conf/distro/include/security_flags.inc | 1 -
meta/recipes-kernel/perf/perf.bb| 1 +
2 files changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/conf/distro/include/security_flags.inc
b/meta/conf/distro/include/security_flags.inc
index 2972f05b4e..d97a6edb0f 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -69,4 +69,3 @@ SECURITY_LDFLAGS:pn-xserver-xorg = "${SECURITY_X_LDFLAGS}"
TARGET_CC_ARCH:append:pn-binutils = " ${SELECTED_OPTIMIZATION}"
TARGET_CC_ARCH:append:pn-gcc = " ${SELECTED_OPTIMIZATION}"
TARGET_CC_ARCH:append:pn-gdb = " ${SELECTED_OPTIMIZATION}"
-TARGET_CC_ARCH:append:pn-perf = " ${SELECTED_OPTIMIZATION}"
diff --git a/meta/recipes-kernel/perf/perf.bb b/meta/recipes-kernel/perf/perf.bb
index 675acfaf26..a6110dedc9 100644
--- a/meta/recipes-kernel/perf/perf.bb
+++ b/meta/recipes-kernel/perf/perf.bb
@@ -72,6 +72,7 @@ SPDX_S = "${S}/tools/perf"
# symbols and this is preferred than requiring patches to every old
# supported kernel.
LDFLAGS="-ldl -lutil"
+TARGET_CC_ARCH += "${SELECTED_OPTIMIZATION}"
EXTRA_OEMAKE = '\
V=1 \
--
2.40.1.1.g1c60b9335d
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189451):
https://lists.openembedded.org/g/openembedded-core/message/189451
Mute This Topic: https://lists.openembedded.org/mt/102058904/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
Hi, On Thu, Oct 19, 2023 at 12:54:44PM +0100, Jose Quaresma wrote: > Hi > > This change will need some adaptations in the create-spdx.bbclass to handle > this new variable with _PN Good point. How does SPDX tooling handle embedded SW components in recipe sources? I presume it does not because recipe and license don't handle it either. Should there be a more generic PN_subpn, PV_subpn, LICENSE_subpn and matching CVE_PRODUCT and CVE_VERSION? I don't have use cases for these currently. I would like to fix the CVE reporting issues with embedded SW components though. mbedtls being one good example. Or would it be better to convert mbedtls users to use the meta-oe side recipe for it? Additionally I don't currently read the SDPX output. I don't have use cases for it. I do check recipes and their metadata like LICENSE though. Feels like the SDPX data is used as reporting/export data format which is fed to some other tools which are not open source. Can of worms... Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189450): https://lists.openembedded.org/g/openembedded-core/message/189450 Mute This Topic: https://lists.openembedded.org/mt/101991269/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [mickledore] glibc: stable 2.37 branch updates.
Hi Khem, We tried increasing the memory and no regression failures were found. Here is the test results: Regression testing is done and below are the test results. Before glibc update Summary of test results: PASS:4727 FAIL:240 XPASS:4 XFAIL:16 UNSUPPORTED:220 After glibc update Summary of test results: PASS:4733 FAIL:235 XPASS:4 XFAIL:16 UNSUPPORTED:221 These are the newly added test cases PASS: io/tst-fcntl-lock-lfs UNSUPPORTED: nss/mtrace-tst-nss-gai-hv2-canonname These are the tests which were failing before and passed after increasing the memory: PASS: nptl/tst-thread-affinity-pthread PASS: nptl/tst-thread-affinity-pthread2 PASS: nptl/tst-thread-affinity-sched -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189449): https://lists.openembedded.org/g/openembedded-core/message/189449 Mute This Topic: https://lists.openembedded.org/mt/101774187/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
Hi This change will need some adaptations in the create-spdx.bbclass to handle this new variable with _PN Jose Mikko Rapeli escreveu no dia quinta, 19/10/2023 à(s) 10:13: > Hi, > > On Thu, Oct 19, 2023 at 10:19:53AM +0200, Marta Rybczynska wrote: > > On Mon, Oct 16, 2023 at 9:01 AM Mikko Rapeli > wrote: > > > > > > Many recipes embed other SW components. The name and version of the > > > embedded SW component differs from the main recipe. To detect CVEs in > the > > > embedded SW component, it needs to be added to CVE_PRODUCT list using > > > name of the SW product in CVE database or with "vendor:product" syntax. > > > Then the version of the embedded SW component can be set using > > > CVE_VERSION_product variable. > > > > > > For example in meta-arm, trusted-firmware-a embeds mbed_tls SW > component. > > > Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database > > > uses product name "mbed_tls": > > > > > > CVE_PRODUCT += "mbed_tls" > > > > > > and set the version of mbed_tls: > > > > > > CVE_VERSION_mbed_tls = "2.28.4" > > > > > > (Real patches for both are a bit more complex due to conditional build > > > enabling mbed_tls support and due to mbed_tls version being set in an > > > .inc file.) > > > > > > > I like the support for embedded software. In this approach, I'm wondering > > how it would work for packages like curl that have multiple CPEs. Would > we > > need to duplicate the list of CPEs? > > The current approach of listing multiple CPEs in CVE_PRODUCT still works. > It's just possible to include a different version for an entry in > CVE_PRODUCT > via CVE_VERSION_swcomponent variable. It will fall back to PV. > > > There are layers/recipes where we have a very long list of embedded > components, > > meta-zephyr is probably the best example. > > Yes, I think this embedding of SW components is very common. I think some > of the > LICENSE data does reflect this but not in all cases. > > Cheers, > > -Mikko > > > > -- Best regards, José Quaresma -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189448): https://lists.openembedded.org/g/openembedded-core/message/189448 Mute This Topic: https://lists.openembedded.org/mt/101991269/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2] selftest/buildoptions: tag the download mirror test with 'yocto-mirrors'
This will allow bundling all yocto mirror tests together, both for
the purposes of running only them specifically,
and excluding them from 'general' oe-selftest runs.
There is an upcoming test for sstate cache served over content
delivery network which will use the same tag, so it can be run
together with this.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/buildoptions.py | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py
b/meta/lib/oeqa/selftest/cases/buildoptions.py
index 104448442ad..31dafaa9c50 100644
--- a/meta/lib/oeqa/selftest/cases/buildoptions.py
+++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
@@ -14,6 +14,7 @@ from oeqa.selftest.cases.buildhistory import BuildhistoryBase
from oeqa.core.decorator.data import skipIfMachine
from oeqa.utils.commands import bitbake, get_bb_var, get_bb_vars
import oeqa.utils.ftools as ftools
+from oeqa.core.decorator import OETestTag
class ImageOptionsTests(OESelftestTestCase):
@@ -204,6 +205,7 @@ class ToolchainOptions(OESelftestTestCase):
self.write_config(features)
bitbake('fortran-helloworld')
+@OETestTag("yocto-mirrors")
class SourceMirroring(OESelftestTestCase):
# Can we download everything from the Yocto Sources Mirror over http only
def test_yocto_source_mirror(self):
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189447):
https://lists.openembedded.org/g/openembedded-core/message/189447
Mute This Topic: https://lists.openembedded.org/mt/102058007/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 2/2] systemd: add option to use stub-resolv.conf
From: Eero Aaltonen
Add option to use the stub-resolv.conf file, which is the systemd
upstream's recommended default mode
https://www.freedesktop.org/software/systemd/man/systemd-resolved.service.html#/etc/resolv.conf
This enables the resolution of Multicast DNS and Link-Local Multicast
Name Resolution names for programs that do not use Name Service Switch.
Signed-off-by: Eero Aaltonen
---
meta/recipes-core/systemd/systemd_254.bb | 7 +--
1 file changed, 5 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-core/systemd/systemd_254.bb
b/meta/recipes-core/systemd/systemd_254.bb
index e0ee2da412..83cd854b87 100644
--- a/meta/recipes-core/systemd/systemd_254.bb
+++ b/meta/recipes-core/systemd/systemd_254.bb
@@ -228,6 +228,8 @@ PACKAGECONFIG[xz] = "-Dxz=true,-Dxz=false,xz"
PACKAGECONFIG[zlib] = "-Dzlib=true,-Dzlib=false,zlib"
PACKAGECONFIG[zstd] = "-Dzstd=true,-Dzstd=false,zstd"
+RESOLV_CONF ??= ""
+
# Helper variables to clarify locations. This mirrors the logic in systemd's
# build system.
rootprefix ?= "${root_prefix}"
@@ -339,8 +341,9 @@ do_install() {
echo 'f /run/systemd/resolve/resolv.conf 0644 root root'
>>${D}${exec_prefix}/lib/tmpfiles.d/systemd.conf
ln -s ../run/systemd/resolve/resolv.conf
${D}${sysconfdir}/resolv-conf.systemd
else
- sed -i -e "s%^L! /etc/resolv.conf.*$%L! /etc/resolv.conf - - -
- ../run/systemd/resolve/resolv.conf%g"
${D}${exec_prefix}/lib/tmpfiles.d/etc.conf
- ln -s ../run/systemd/resolve/resolv.conf
${D}${sysconfdir}/resolv-conf.systemd
+ resolv_conf="${@bb.utils.contains('RESOLV_CONF', 'stub-resolv',
'run/systemd/resolve/stub-resolv.conf', 'run/systemd/resolve/resolv.conf', d)}"
+ sed -i -e "s%^L! /etc/resolv.conf.*$%L! /etc/resolv.conf - - -
- ../${resolv_conf}%g" ${D}${exec_prefix}/lib/tmpfiles.d/etc.conf
+ ln -s ../${resolv_conf} ${D}${sysconfdir}/resolv-conf.systemd
fi
if ${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'false', 'true', d)};
then
rm ${D}${exec_prefix}/lib/tmpfiles.d/x11.conf
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189446):
https://lists.openembedded.org/g/openembedded-core/message/189446
Mute This Topic: https://lists.openembedded.org/mt/102057806/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 1/2] base-files, systemd: add nss-resolve plugin
From: Eero Aaltonen
Add nss-resolve plugin to the glibc Name Service Switch (NSS) with
systemd-resolved DISTRO_FEATURE so that systemd-resolved is used in DNS
name resolution.
This enables the resolution of Multicast DNS and Link-Local Multicast
Name Resolution names, depending on the selected options.
Signed-off-by: Eero Aaltonen
---
.../0001-add-nss-resolve-to-nsswitch.patch| 31 +++
.../base-files/base-files_3.0.14.bb | 2 ++
meta/recipes-core/systemd/systemd_254.bb | 3 ++
3 files changed, 36 insertions(+)
create mode 100644
meta/recipes-core/base-files/base-files/0001-add-nss-resolve-to-nsswitch.patch
diff --git
a/meta/recipes-core/base-files/base-files/0001-add-nss-resolve-to-nsswitch.patch
b/meta/recipes-core/base-files/base-files/0001-add-nss-resolve-to-nsswitch.patch
new file mode 100644
index 00..a6e39e0956
--- /dev/null
+++
b/meta/recipes-core/base-files/base-files/0001-add-nss-resolve-to-nsswitch.patch
@@ -0,0 +1,31 @@
+From 830abe652428d9d31780c3ace121635ad7b64274 Mon Sep 17 00:00:00 2001
+From: Eero Aaltonen
+Date: Wed Sep 27 15:50:48 2023 +0300
+Subject: [PATCH] Add nss-resolve to the Name Service Switch (NSS)
+
+Add `nss-resolve` so that `systemd-resolved` is used for name
+resolution with glibc `gethostbyname` calls.
+
+Upstream-Status: Inappropriate [no upstream, configuration].
+
+Signed-off-by: Eero Aaltonen
+---
+ nsswitch.conf | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/nsswitch.conf b/nsswitch.conf
+index 06f03d2..34b165c 100644
+--- a/nsswitch.conf
b/nsswitch.conf
+@@ -8,7 +8,7 @@ passwd: compat
+ group: compat
+ shadow: compat
+
+-hosts: files dns
++hosts: resolve [!UNAVAIL=return] files dns
+ networks: files
+
+ protocols: db files
+--
+2.25.1
+
diff --git a/meta/recipes-core/base-files/base-files_3.0.14.bb
b/meta/recipes-core/base-files/base-files_3.0.14.bb
index 6ba3971e32..6890fe114d 100644
--- a/meta/recipes-core/base-files/base-files_3.0.14.bb
+++ b/meta/recipes-core/base-files/base-files_3.0.14.bb
@@ -23,6 +23,8 @@ SRC_URI = "file://rotation \
file://share/dot.profile \
file://licenses/GPL-2 \
"
+SRC_URI:append:libc-glibc = "${@bb.utils.contains('DISTRO_FEATURES', 'systemd
systemd-resolved', ' file://0001-add-nss-resolve-to-nsswitch.patch', '', d)}"
+
S = "${WORKDIR}"
INHIBIT_DEFAULT_DEPS = "1"
diff --git a/meta/recipes-core/systemd/systemd_254.bb
b/meta/recipes-core/systemd/systemd_254.bb
index 8d5cf13095..e0ee2da412 100644
--- a/meta/recipes-core/systemd/systemd_254.bb
+++ b/meta/recipes-core/systemd/systemd_254.bb
@@ -789,6 +789,9 @@ python __anonymous() {
if not bb.utils.contains('DISTRO_FEATURES', 'sysvinit', True, False, d):
d.setVar("INHIBIT_UPDATERCD_BBCLASS", "1")
+if bb.utils.contains('DISTRO_FEATURES', 'systemd-resolved', True, False,
d) and not bb.utils.contains('PACKAGECONFIG', 'nss-resolve resolved', True,
False, d):
+bb.error("DISTRO_FEATURES[systemd-resolved] requires
PACKAGECONFIG[nss-resolve, resolved]")
+
if bb.utils.contains('PACKAGECONFIG', 'repart', True, False, d) and not
bb.utils.contains('PACKAGECONFIG', 'openssl', True, False, d):
bb.error("PACKAGECONFIG[repart] requires PACKAGECONFIG[openssl]")
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189445):
https://lists.openembedded.org/g/openembedded-core/message/189445
Mute This Topic: https://lists.openembedded.org/mt/102057805/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][PATCH 0/2] DNS resolution using systemd-resolved
From: Eero Aaltonen Enable DNS resolution features from systemd-resolved, such as Multicast DNS for distros using systemd. The first commit enables systemd-resolved via glibc nsswitch.conf, which is one of the interfaces recommended by systemd upstream. The second commit enables mDNS resolution for executables that do not use nsswitch, notably including busybox. Eero Aaltonen (2): base-files, systemd: add nss-resolve plugin systemd: add option to use stub-resolv.conf .../0001-add-nss-resolve-to-nsswitch.patch| 31 +++ .../base-files/base-files_3.0.14.bb | 2 ++ meta/recipes-core/systemd/systemd_254.bb | 10 -- 3 files changed, 41 insertions(+), 2 deletions(-) create mode 100644 meta/recipes-core/base-files/base-files/0001-add-nss-resolve-to-nsswitch.patch -- 2.25.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189444): https://lists.openembedded.org/g/openembedded-core/message/189444 Mute This Topic: https://lists.openembedded.org/mt/102057804/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] Add SECURITY.md
On Wed, 2023-10-18 at 07:03 +0200, Marta Rybczynska wrote: > On Tue, Oct 17, 2023 at 11:50 PM Richard Purdie > wrote: > > > > On Tue, 2023-10-17 at 17:25 +0200, Marta Rybczynska wrote: > > > Add a SECURITY.md filr with hints for security researchers and other > > > parties who might report potential security vulnerabilities. > > > > > > Signed-off-by: Marta Rybczynska > > > --- > > > SECURITY.md | 17 + > > > 1 file changed, 17 insertions(+) > > > create mode 100644 SECURITY.md > > > > > > diff --git a/SECURITY.md b/SECURITY.md > > > new file mode 100644 > > > index 00..900da76e59 > > > --- /dev/null > > > +++ b/SECURITY.md > > > @@ -0,0 +1,17 @@ > > > +How to Report a Vulnerability? > > > +== > > > + > > > +Please send a message to security AT yoctoproject DOT org, including as > > > many details > > > +as possible: the layer or software module affected, the recipe and its > > > version, > > > +and any example code, if available. > > > > Rather than send everyone to the security address, can we suggest > > bugzilla as the first port of call for anything public knowledge and > > less urgent and to only to use the security address for non-public or > > urgent issues? > > > > We do have the ability to mark bugs as security and private and then > > triage unlocks them too. > > > > Absolutely. I will be sending a v2 to OE-core only. When we agree on this one, > I will send it also to other layers. As they might come in different > combinations, > a SECURITY.md for each layer (like README) gives us best visibility. I'm happy with the OE-Core v2 so plan to merge that to the nanbield and master branches even if we've built rc1. I'm assuming Steve will add to the LTS branches too? Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189443): https://lists.openembedded.org/g/openembedded-core/message/189443 Mute This Topic: https://lists.openembedded.org/mt/102019988/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][kirkstone][PATCH] gawk: backport Debian patch to fix CVE-2023-4156
From: Vijay Anusuri
Upstream-Status: Backport
[https://git.launchpad.net/ubuntu/+source/gawk/tree/debian/patches?h=ubuntu/jammy-security
&
https://git.savannah.gnu.org/gitweb/?p=gawk.git;a=commitdiff;h=e709eb829448ce040087a3fc5481db6bfcaae212]
Signed-off-by: Vijay Anusuri
---
.../gawk/gawk/CVE-2023-4156.patch | 28 +++
meta/recipes-extended/gawk/gawk_5.1.1.bb | 1 +
2 files changed, 29 insertions(+)
create mode 100644 meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
diff --git a/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
b/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
new file mode 100644
index 00..bc157d6afb
--- /dev/null
+++ b/meta/recipes-extended/gawk/gawk/CVE-2023-4156.patch
@@ -0,0 +1,28 @@
+From e709eb829448ce040087a3fc5481db6bfcaae212 Mon Sep 17 00:00:00 2001
+From: "Arnold D. Robbins"
+Date: Wed, 3 Aug 2022 13:00:54 +0300
+Subject: [PATCH] Smal bug fix in builtin.c.
+
+Upstream-Status: Backport [import from ubuntu
https://git.launchpad.net/ubuntu/+source/gawk/tree/debian/patches/CVE-2023-4156.patch?h=ubuntu/jammy-security
+Upstream commit
https://git.savannah.gnu.org/gitweb/?p=gawk.git;a=commitdiff;h=e709eb829448ce040087a3fc5481db6bfcaae212]
+CVE: CVE-2023-4156
+Signed-off-by: Vijay Anusuri
+---
+ ChangeLog | 6 ++
+ builtin.c | 5 -
+ 2 files changed, 10 insertions(+), 1 deletion(-)
+
+--- gawk-5.1.0.orig/builtin.c
gawk-5.1.0/builtin.c
+@@ -957,7 +957,10 @@ check_pos:
+ s1++;
+ n0--;
+ }
+- if (val >= num_args) {
++ // val could be less than zero if someone
provides a field width
++ // so large that it causes integer overflow.
Mainly fuzzers do this,
++ // but let's try to be good anyway.
++ if (val < 0 || val >= num_args) {
+ toofew = true;
+ break;
+ }
diff --git a/meta/recipes-extended/gawk/gawk_5.1.1.bb
b/meta/recipes-extended/gawk/gawk_5.1.1.bb
index fe339805d0..0b0d0897bc 100644
--- a/meta/recipes-extended/gawk/gawk_5.1.1.bb
+++ b/meta/recipes-extended/gawk/gawk_5.1.1.bb
@@ -18,6 +18,7 @@ PACKAGECONFIG[mpfr] = "--with-mpfr,--without-mpfr, mpfr"
SRC_URI = "${GNU_MIRROR}/gawk/gawk-${PV}.tar.gz \
file://remove-sensitive-tests.patch \
file://run-ptest \
+ file://CVE-2023-4156.patch \
"
SRC_URI[sha256sum] =
"6168d8d1dc8f74bd17d9dc22fa9634c49070f232343b744901da15fb4f06bffd"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189442):
https://lists.openembedded.org/g/openembedded-core/message/189442
Mute This Topic: https://lists.openembedded.org/mt/102057055/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 0/2] Add a display limit for regression report generation
It has been observed that useful information in regression report can be drowned in huge regression lists which are often false-positives (for example, a whole set of tests has been temporarily disabled). This series brings a default limit to how many changes are displayed per base/target comparison. This default can still be overriden on commandline, for example to have a better look at the whole regression list when trying to debug an issue (i.e. by disabling the limit) First commit implement the limit, its default value and the corresponding commandline option in resulttool. Second commit allow yocto_testresults_query.py to drive this value. As a result, one can for example do the following: - yocto_testresults_query 4.3_M1 4.3_M2 -> will display at most 50 regressions per test - yocto_testresults_query -l 10 4.3_M1 4.3_M2 -> override the display limit and reduce it to 10 regressions per pair. - yocto_testresults_query -l 0 4.3_M1 4.3_M2 -> disable the display limit, print all regressions An example of regression report with display limit can be found here: https://pastebin.com/6QbfGstR Alexis Lothoré (2): scripts/resulttool: limit the number of changes displayed per test scripts/yocto_testresults_query: add option to change display limit scripts/lib/resulttool/regression.py | 23 +++ scripts/yocto_testresults_query.py | 13 ++--- 2 files changed, 29 insertions(+), 7 deletions(-) -- 2.42.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189440): https://lists.openembedded.org/g/openembedded-core/message/189440 Mute This Topic: https://lists.openembedded.org/mt/102057050/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 2/2] scripts/yocto_testresults_query: add option to change display limit
From: Alexis Lothoré
Add a "-l"/"--limit" option to allow changing the display limit in
resulttool.
- If no value is passed, resulttool uses its default value.
- If 0 is passed, the display limit is removed and every regression will be
displayed
- If a custom value is passed, this value overrides the vlaue configured in
resulttool
Signed-off-by: Alexis Lothoré
---
scripts/yocto_testresults_query.py | 13 ++---
1 file changed, 10 insertions(+), 3 deletions(-)
diff --git a/scripts/yocto_testresults_query.py
b/scripts/yocto_testresults_query.py
index a5073736aab5..521ead8473ad 100755
--- a/scripts/yocto_testresults_query.py
+++ b/scripts/yocto_testresults_query.py
@@ -56,9 +56,12 @@ def fetch_testresults(workdir, sha1):
subprocess.check_call(["git", "fetch", "--depth", "1", "origin",
f"{rev}:{rev}"], cwd=workdir)
return branch
-def compute_regression_report(workdir, basebranch, baserevision, targetbranch,
targetrevision):
+def compute_regression_report(workdir, basebranch, baserevision, targetbranch,
targetrevision, args):
logger.info(f"Running resulttool regression between SHA1 {baserevision}
and {targetrevision}")
-report = subprocess.check_output([resulttool, "regression-git",
"--branch", basebranch, "--commit", baserevision, "--branch2", targetbranch,
"--commit2", targetrevision, workdir]).decode("utf-8")
+command = [resulttool, "regression-git", "--branch", basebranch,
"--commit", baserevision, "--branch2", targetbranch, "--commit2",
targetrevision, workdir]
+if args.limit:
+command.extend(["-l", args.limit])
+report = subprocess.check_output(command).decode("utf-8")
return report
def print_report_with_header(report, baseversion, baserevision, targetversion,
targetrevision):
@@ -85,7 +88,7 @@ def regression(args):
sys.exit(1)
basebranch = fetch_testresults(workdir, baserevision)
targetbranch = fetch_testresults(workdir, targetrevision)
-report = compute_regression_report(workdir, basebranch, baserevision,
targetbranch, targetrevision)
+report = compute_regression_report(workdir, basebranch, baserevision,
targetbranch, targetrevision, args)
print_report_with_header(report, args.base, baserevision, args.target,
targetrevision)
finally:
if not args.testresultsdir:
@@ -109,6 +112,10 @@ def main():
'-t',
'--testresultsdir',
help=f"An existing test results directory. {sys.argv[0]} will
automatically clone it and use default branch if not provided")
+parser_regression_report.add_argument(
+'-l',
+'--limit',
+help=f"Maximum number of changes to display per test. Can be set to 0
to print all changes")
parser_regression_report.set_defaults(func=regression)
args = parser.parse_args()
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189441):
https://lists.openembedded.org/g/openembedded-core/message/189441
Mute This Topic: https://lists.openembedded.org/mt/102057051/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-Core][PATCH 1/2] scripts/resulttool: limit the number of changes displayed per test
From: Alexis Lothoré
Most of the changes list generated in regression reports fall in one
of the two following categories:
- there is only a few (<10) changes listed and the info is
valuable/relevant
- the list is huge (> 100 ? 1000 ?) and basically tells us that the whole
tests category suffers the same status (test missing, test failing, test
skipped, etc)
Prevent those huge, worthless lists by limiting the output for each test
result pair:
- current default limit is arbitrarily set to 50
- limit can still be overriden with a new "-l"/"--limit" flag, either with
custom value, or with 0 to print the whole lists of changes
Signed-off-by: Alexis Lothoré
---
scripts/lib/resulttool/regression.py | 23 +++
1 file changed, 19 insertions(+), 4 deletions(-)
diff --git a/scripts/lib/resulttool/regression.py
b/scripts/lib/resulttool/regression.py
index 3d64b8f4af7c..5c5ed6e6a670 100644
--- a/scripts/lib/resulttool/regression.py
+++ b/scripts/lib/resulttool/regression.py
@@ -78,6 +78,8 @@ STATUS_STRINGS = {
"None": "No matching test result"
}
+REGRESSIONS_DISPLAY_LIMIT=50
+
def test_has_at_least_one_matching_tag(test, tag_list):
return "oetags" in test and any(oetag in tag_list for oetag in
test["oetags"])
@@ -181,11 +183,12 @@ def get_status_str(raw_status):
raw_status_lower = raw_status.lower() if raw_status else "None"
return STATUS_STRINGS.get(raw_status_lower, raw_status)
-def compare_result(logger, base_name, target_name, base_result, target_result):
+def compare_result(logger, base_name, target_name, base_result, target_result,
display_limit):
base_result = base_result.get('result')
target_result = target_result.get('result')
result = {}
new_tests = 0
+regressions_count = 0
if base_result and target_result:
for k in base_result:
@@ -212,7 +215,14 @@ def compare_result(logger, base_name, target_name,
base_result, target_result):
resultstring = "Regression: %s\n %s\n" % (base_name,
target_name)
for k in sorted(result):
if not result[k]['target'] or not
result[k]['target'].startswith("PASS"):
-resultstring += '%s: %s -> %s\n' % (k,
get_status_str(result[k]['base']), get_status_str(result[k]['target']))
+# Count regressions only if we have to limit the number of
+# displayed regressions
+if display_limit > 0:
+regressions_count = regressions_count + 1
+if regressions_count <= display_limit:
+resultstring += '%s: %s -> %s\n' % (k,
get_status_str(result[k]['base']), get_status_str(result[k]['target']))
+if regressions_count > display_limit:
+resultstring += f'[...]\n(In total,
{regressions_count} regressions/status changes detected)\n'
if new_pass_count > 0:
resultstring += f'Additionally, {new_pass_count}
previously failing test(s) is/are now passing\n'
else:
@@ -263,6 +273,10 @@ def regression_common(args, logger, base_results,
target_results):
if args.target_result_id:
target_results = resultutils.filter_resultsdata(target_results,
args.target_result_id)
+display_limit=REGRESSIONS_DISPLAY_LIMIT
+if args.limit:
+display_limit=int(args.limit)
+
fixup_ptest_names(base_results, logger)
fixup_ptest_names(target_results, logger)
@@ -280,7 +294,7 @@ def regression_common(args, logger, base_results,
target_results):
for b in target.copy():
if not can_be_compared(logger, base_results[a][c],
target_results[a][b]):
continue
-res, resstr = compare_result(logger, c, b,
base_results[a][c], target_results[a][b])
+res, resstr = compare_result(logger, c, b,
base_results[a][c], target_results[a][b], display_limit)
if not res:
matches.append(resstr)
base.remove(c)
@@ -291,7 +305,7 @@ def regression_common(args, logger, base_results,
target_results):
for b in target:
if not can_be_compared(logger, base_results[a][c],
target_results[a][b]):
continue
-res, resstr = compare_result(logger, c, b,
base_results[a][c], target_results[a][b])
+res, resstr = compare_result(logger, c, b,
base_results[a][c], target_results[a][b], display_limit)
if res:
regressions.append(resstr)
else:
@@ -403,4 +417,5 @@ def register_commands(subparsers):
parser_build.add_argument('--commit-number', help="Revision number to
search for, redundant if --commit is specified")
parser_build.add_argument('--commit2', help="Revision to compare with")
[OE-core] [PATCH] selftest/buildoptions: tag the download mirror test with 'yocto-mirrors'
This will allow bundling all yocto mirror tests together, both for
the purposes of running only them specifically,
and excluding them from 'general' oe-selftest runs.
There is an upcoming test for sstate cache served over content
delivery network which will use the same tag, so it can be run
together with this.
Signed-off-by: Alexander Kanavin
---
meta/lib/oeqa/selftest/cases/buildoptions.py | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/lib/oeqa/selftest/cases/buildoptions.py
b/meta/lib/oeqa/selftest/cases/buildoptions.py
index 104448442ad..50c4a331869 100644
--- a/meta/lib/oeqa/selftest/cases/buildoptions.py
+++ b/meta/lib/oeqa/selftest/cases/buildoptions.py
@@ -204,6 +204,7 @@ class ToolchainOptions(OESelftestTestCase):
self.write_config(features)
bitbake('fortran-helloworld')
+@OETestTag("yocto-mirrors")
class SourceMirroring(OESelftestTestCase):
# Can we download everything from the Yocto Sources Mirror over http only
def test_yocto_source_mirror(self):
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189438):
https://lists.openembedded.org/g/openembedded-core/message/189438
Mute This Topic: https://lists.openembedded.org/mt/102056958/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
Hi, On Thu, Oct 19, 2023 at 10:19:53AM +0200, Marta Rybczynska wrote: > On Mon, Oct 16, 2023 at 9:01 AM Mikko Rapeli wrote: > > > > Many recipes embed other SW components. The name and version of the > > embedded SW component differs from the main recipe. To detect CVEs in the > > embedded SW component, it needs to be added to CVE_PRODUCT list using > > name of the SW product in CVE database or with "vendor:product" syntax. > > Then the version of the embedded SW component can be set using > > CVE_VERSION_product variable. > > > > For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component. > > Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database > > uses product name "mbed_tls": > > > > CVE_PRODUCT += "mbed_tls" > > > > and set the version of mbed_tls: > > > > CVE_VERSION_mbed_tls = "2.28.4" > > > > (Real patches for both are a bit more complex due to conditional build > > enabling mbed_tls support and due to mbed_tls version being set in an > > .inc file.) > > > > I like the support for embedded software. In this approach, I'm wondering > how it would work for packages like curl that have multiple CPEs. Would we > need to duplicate the list of CPEs? The current approach of listing multiple CPEs in CVE_PRODUCT still works. It's just possible to include a different version for an entry in CVE_PRODUCT via CVE_VERSION_swcomponent variable. It will fall back to PV. > There are layers/recipes where we have a very long list of embedded > components, > meta-zephyr is probably the best example. Yes, I think this embedding of SW components is very common. I think some of the LICENSE data does reflect this but not in all cases. Cheers, -Mikko -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189437): https://lists.openembedded.org/g/openembedded-core/message/189437 Mute This Topic: https://lists.openembedded.org/mt/101991269/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] qemuboot.bbclass: fix typos in documentation
comand -> command docuemntation -> documentation Signed-off-by: Marcus Folkesson --- meta/classes-recipe/qemuboot.bbclass | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/classes-recipe/qemuboot.bbclass b/meta/classes-recipe/qemuboot.bbclass index 5c4bbd6737..ff32aac902 100644 --- a/meta/classes-recipe/qemuboot.bbclass +++ b/meta/classes-recipe/qemuboot.bbclass @@ -62,8 +62,8 @@ # QB_SLIRP_OPT: network option for SLIRP mode, e.g., -netdev user,id=net0" # # QB_CMDLINE_IP_SLIRP: If QB_NETWORK_DEVICE adds more than one network interface to qemu, usually the -# ip= kernel comand line argument needs to be changed accordingly. Details are documented -# in the kernel docuemntation https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt +# ip= kernel command line argument needs to be changed accordingly. Details are documented +# in the kernel documentation https://www.kernel.org/doc/Documentation/filesystems/nfs/nfsroot.txt # Example to configure only the first interface: "ip=eth0:dhcp" # QB_CMDLINE_IP_TAP: This parameter is similar to the QB_CMDLINE_IP_SLIRP parameter. Since the tap interface requires #static IP configuration @CLIENT@ and @GATEWAY@ place holders are replaced by the IP and the gateway -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189436): https://lists.openembedded.org/g/openembedded-core/message/189436 Mute This Topic: https://lists.openembedded.org/mt/102056643/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/3] lib/oe/sstatesig.py: dump locked.sigs.inc only when explicitly asked via -S lockedsigs
On Tue, 2023-10-17 at 15:30 +0200, Alexander Kanavin wrote: > This was writing out locked-sigs.inc into cwd with every > 'bitbake -S' invocation. When the intent is only to to get task > stamps (-S none), or print the difference between them (-S printdiff), > the file is unnecessary clutter. > > A couple of selftests were however relying on this, so they're > adjusted to explicitly request the file. I think there are a couple of other places needing adjustment: https://autobuilder.yoctoproject.org/typhoon/#/builders/69/builds/7962 https://autobuilder.yoctoproject.org/typhoon/#/builders/39/builds/8022 Cheers, Richard -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189435): https://lists.openembedded.org/g/openembedded-core/message/189435 Mute This Topic: https://lists.openembedded.org/mt/102017473/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH] cve-check.bbclass: support embedded SW components with different version number
On Mon, Oct 16, 2023 at 9:01 AM Mikko Rapeli wrote: > > Many recipes embed other SW components. The name and version of the > embedded SW component differs from the main recipe. To detect CVEs in the > embedded SW component, it needs to be added to CVE_PRODUCT list using > name of the SW product in CVE database or with "vendor:product" syntax. > Then the version of the embedded SW component can be set using > CVE_VERSION_product variable. > > For example in meta-arm, trusted-firmware-a embeds mbed_tls SW component. > Thus trusted-firmware-a can add CVE_PRODUCT for it since CVE database > uses product name "mbed_tls": > > CVE_PRODUCT += "mbed_tls" > > and set the version of mbed_tls: > > CVE_VERSION_mbed_tls = "2.28.4" > > (Real patches for both are a bit more complex due to conditional build > enabling mbed_tls support and due to mbed_tls version being set in an > .inc file.) > I like the support for embedded software. In this approach, I'm wondering how it would work for packages like curl that have multiple CPEs. Would we need to duplicate the list of CPEs? There are layers/recipes where we have a very long list of embedded components, meta-zephyr is probably the best example. Cheers, Marta -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189434): https://lists.openembedded.org/g/openembedded-core/message/189434 Mute This Topic: https://lists.openembedded.org/mt/101991269/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Detecting unimplemented ptests with heuristics
Hi everyone, We recently implemented a way to detect recipes for upstream code that contain unit tests but does not implement ptests. Those recipes make good candidates for increasing the ptests coverage. This is implemented as a QA check. The check is disabled by default since it generates a lot of warning at build. In order to activate it (in local.conf for exemple) : WARN_QA += "unimplemented-ptest" The warnings looks like: WARNING: time-1.9-r0 do_patch: QA Issue: time: autotools-based tests detected [unimplemented-ptest] I've generated the list for the unimplemented ptests for oe-core and for meta-openembedded: 329 unimplemented-ptests_oe-core.log: https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_oe-core-log 1080 unimplemented-ptests_meta-openembedded.log: https://gist.github.com/ycongal-smile/dd51b0e450a8f0083e9d5cc10eeeb060#file-unimplemented-ptests_meta-openembedded-log Those were generated with : bitbake --runall patch world ... without the meta-openembedded layers for oe-core. For meta-openembedded, I have excluded OE-core recipes from world with: EXCLUDE_FROM_WORLD:layer-core = '1' EXCLUDE_FROM_WORLD:layer-yoctobsp = '1' EXCLUDE_FROM_WORLD:layer-yocto = '1' For the curious, the code is here: https://git.yoctoproject.org/poky/tree/meta/classes-global/insane.bbclass?id=07546cc63f5e2a1a74bd7f5cac6ad1c9948264d4#n1351 And the doc was sent here: https://lists.yoctoproject.org/g/docs/message/4335 Regards, -- Yoann Congal Smile ECS - Tech Expert -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189433): https://lists.openembedded.org/g/openembedded-core/message/189433 Mute This Topic: https://lists.openembedded.org/mt/102056219/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH 1/4] scripts:recipetool:create_buildsys_python: fix license note
Le mer. 18 oct. 2023 à 21:58, Alexandre Belloni
a écrit :
>
> Hello,
>
> On 18/10/2023 14:01:11+0200, Julien Stephan wrote:
> > License field of setup is not always standardized, so we usually use the
> > classifier to determine the correct license format to use in the recipe.
> >
> > A warning note is added above the LICENSE field of the create recipe
> > in case a license is provided in setup. But when the plugin is called,
> > "LICENSE =" is not yet present so we can never display this note.
> > Replace the "LICENSE =" condition with "##LICENSE_PLACEHOLDER##"
> > to actually be able to display the note message
> >
> > Signed-off-by: Julien Stephan
> > ---
> > scripts/lib/recipetool/create_buildsys_python.py | 2 +-
> > 1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/scripts/lib/recipetool/create_buildsys_python.py
> > b/scripts/lib/recipetool/create_buildsys_python.py
> > index 92468b22546..d2c7e251bf7 100644
> > --- a/scripts/lib/recipetool/create_buildsys_python.py
> > +++ b/scripts/lib/recipetool/create_buildsys_python.py
> > @@ -254,7 +254,7 @@ class PythonRecipeHandler(RecipeHandler):
> >
> > if license_str:
> > for i, line in enumerate(lines_before):
> > -if line.startswith('LICENSE = '):
> > +if ine.startswith('##LICENSE_PLACEHOLDER##'):
>
> I doubt this parses at all, ine is not declared ;)
Hello,
:O I completely messed up my rebase, good catch! Fixed in v2.
Thank you alexandre
Cheers
Julien
>
> > lines_before.insert(i, '# NOTE: License in
> > setup.py/PKGINFO is: %s' % license_str)
> > break
> >
> > --
> > 2.41.0
> >
>
> >
> >
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189432):
https://lists.openembedded.org/g/openembedded-core/message/189432
Mute This Topic: https://lists.openembedded.org/mt/102037342/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 4/4] scripts:recipetool:create_buildsys_python: add PEP517 support
add support for PEP517 [1]
if a pyproject.toml file is found, use it to create the recipe,
otherwise fallback to the old setup.py method.
[YOCTO #14737]
[1]: https://peps.python.org/pep-0517/
Signed-off-by: Julien Stephan
---
.../lib/recipetool/create_buildsys_python.py | 234 +-
1 file changed, 233 insertions(+), 1 deletion(-)
diff --git a/scripts/lib/recipetool/create_buildsys_python.py
b/scripts/lib/recipetool/create_buildsys_python.py
index 69f6f5ca511..0b601d50a4b 100644
--- a/scripts/lib/recipetool/create_buildsys_python.py
+++ b/scripts/lib/recipetool/create_buildsys_python.py
@@ -18,6 +18,7 @@ import os
import re
import sys
import subprocess
+import toml
from recipetool.create import RecipeHandler
logger = logging.getLogger('recipetool')
@@ -656,6 +657,235 @@ class PythonSetupPyRecipeHandler(PythonRecipeHandler):
handled.append('buildsystem')
+class PythonPyprojectTomlRecipeHandler(PythonRecipeHandler):
+"""Base class to support PEP517 and PEP518
+
+PEP517 https://peps.python.org/pep-0517/#source-trees
+PEP518 https://peps.python.org/pep-0518/#build-system-table
+"""
+
+# PEP621:
https://packaging.python.org/en/latest/specifications/declaring-project-metadata/
+# add only the ones that map to a BB var
+# potentially missing: optional-dependencies
+bbvar_map = {
+"name": "PN",
+"version": "PV",
+"Homepage": "HOMEPAGE",
+"description": "SUMMARY",
+"license": "LICENSE",
+"dependencies": "RDEPENDS:${PN}",
+"requires": "DEPENDS",
+}
+
+replacements = [
+("license", r" +$", ""),
+("license", r"^ +", ""),
+("license", r" ", "-"),
+("license", r"^GNU-", ""),
+("license", r"-[Ll]icen[cs]e(,?-[Vv]ersion)?", ""),
+("license", r"^UNKNOWN$", ""),
+# Remove currently unhandled version numbers from these variables
+("requires", r"\[[^\]]+\]$", ""),
+("requires", r"^([^><= ]+).*", r"\1"),
+("dependencies", r"\[[^\]]+\]$", ""),
+("dependencies", r"^([^><= ]+).*", r"\1"),
+]
+
+build_backend_map = {
+"setuptools.build_meta": "python_setuptools_build_meta",
+"poetry.core.masonry.api": "python_poetry_core",
+"flit_core.buildapi": "python_flit_core",
+}
+
+excluded_native_pkgdeps = [
+# already provided by python_setuptools_build_meta.bbclass
+"python3-setuptools-native",
+"python3-wheel-native",
+# already provided by python_poetry_core.bbclass
+"python3-poetry-core-native",
+# already provided by python_flit_core.bbclass
+"python3-flit-core-native",
+]
+
+# add here a list of known and often used packages and the corresponding
bitbake package
+known_deps_map = {
+"setuptools": "python3-setuptools",
+"wheel": "python3-wheel",
+"poetry-core": "python3-poetry-core",
+"flit_core": "python3-flit-core",
+"setuptools-scm": "python3-setuptools-scm",
+}
+
+def __init__(self):
+pass
+
+def process(self, srctree, classes, lines_before, lines_after, handled,
extravalues):
+info = {}
+
+if 'buildsystem' in handled:
+return False
+
+# Check for non-zero size setup.py files
+setupfiles = RecipeHandler.checkfiles(srctree, ["pyproject.toml"])
+for fn in setupfiles:
+if os.path.getsize(fn):
+break
+else:
+return False
+
+setupscript = os.path.join(srctree, "pyproject.toml")
+
+try:
+config = self.parse_pyproject_toml(setupscript)
+build_backend = config["build-system"]["build-backend"]
+if build_backend in self.build_backend_map:
+classes.append(self.build_backend_map[build_backend])
+else:
+logger.error(
+"Unsupported build-backend: %s, cannot use pyproject.toml.
Will try to use legacy setup.py"
+% build_backend
+)
+return False
+
+licfile = ""
+if "project" in config:
+for field, values in config["project"].items():
+if field == "license":
+value = values.get("text", "")
+if not value:
+licfile = values.get("file", "")
+elif isinstance(values, dict):
+for k, v in values.items():
+info[k] = v
+continue
+else:
+value = values
+
+info[field] = value
+
+# Grab the license value before applying replacements
+license_str = info.get("license", "").strip()
+
+if license_str:
+for i, line in enumerate(lines_before):
+if
[OE-core] [PATCH v2 3/4] scripts:recipetool:create_buildsys_python: refactor code for futur PEP517 addition
In order to prepare the support for pyproject.toml (PEP517 [1]) enabled
projects, refactor the code and move setup.py specific code into a
specific class in order to allow sharing the PythonRecipeHandler class
No functionnal changes expected
[1]: https://peps.python.org/pep-0517/#source-tree
Signed-off-by: Julien Stephan
---
.../lib/recipetool/create_buildsys_python.py | 748 +-
1 file changed, 385 insertions(+), 363 deletions(-)
diff --git a/scripts/lib/recipetool/create_buildsys_python.py
b/scripts/lib/recipetool/create_buildsys_python.py
index 502e1dfbc3d..69f6f5ca511 100644
--- a/scripts/lib/recipetool/create_buildsys_python.py
+++ b/scripts/lib/recipetool/create_buildsys_python.py
@@ -37,63 +37,8 @@ class PythonRecipeHandler(RecipeHandler):
assume_provided = ['builtins', 'os.path']
# Assumes that the host python3 builtin_module_names is sane for target too
assume_provided = assume_provided + list(sys.builtin_module_names)
+excluded_fields = []
-bbvar_map = {
-'Name': 'PN',
-'Version': 'PV',
-'Home-page': 'HOMEPAGE',
-'Summary': 'SUMMARY',
-'Description': 'DESCRIPTION',
-'License': 'LICENSE',
-'Requires': 'RDEPENDS:${PN}',
-'Provides': 'RPROVIDES:${PN}',
-'Obsoletes': 'RREPLACES:${PN}',
-}
-# PN/PV are already set by recipetool core & desc can be extremely long
-excluded_fields = [
-'Description',
-]
-setup_parse_map = {
-'Url': 'Home-page',
-'Classifiers': 'Classifier',
-'Description': 'Summary',
-}
-setuparg_map = {
-'Home-page': 'url',
-'Classifier': 'classifiers',
-'Summary': 'description',
-'Description': 'long-description',
-}
-# Values which are lists, used by the setup.py argument based metadata
-# extraction method, to determine how to process the setup.py output.
-setuparg_list_fields = [
-'Classifier',
-'Requires',
-'Provides',
-'Obsoletes',
-'Platform',
-'Supported-Platform',
-]
-setuparg_multi_line_values = ['Description']
-replacements = [
-('License', r' +$', ''),
-('License', r'^ +', ''),
-('License', r' ', '-'),
-('License', r'^GNU-', ''),
-('License', r'-[Ll]icen[cs]e(,?-[Vv]ersion)?', ''),
-('License', r'^UNKNOWN$', ''),
-
-# Remove currently unhandled version numbers from these variables
-('Requires', r' *\([^)]*\)', ''),
-('Provides', r' *\([^)]*\)', ''),
-('Obsoletes', r' *\([^)]*\)', ''),
-('Install-requires', r'^([^><= ]+).*', r'\1'),
-('Extras-require', r'^([^><= ]+).*', r'\1'),
-('Tests-require', r'^([^><= ]+).*', r'\1'),
-
-# Remove unhandled dependency on particular features (e.g. foo[PDF])
-('Install-requires', r'\[[^\]]+\]$', ''),
-]
classifier_license_map = {
'License :: OSI Approved :: Academic Free License (AFL)': 'AFL',
@@ -166,122 +111,34 @@ class PythonRecipeHandler(RecipeHandler):
def __init__(self):
pass
-def process(self, srctree, classes, lines_before, lines_after, handled,
extravalues):
-if 'buildsystem' in handled:
-return False
-
-# Check for non-zero size setup.py files
-setupfiles = RecipeHandler.checkfiles(srctree, ['setup.py'])
-for fn in setupfiles:
-if os.path.getsize(fn):
-break
-else:
-return False
-
-# setup.py is always parsed to get at certain required information,
such as
-# distutils vs setuptools
-#
-# If egg info is available, we use it for both its PKG-INFO metadata
-# and for its requires.txt for install_requires.
-# If PKG-INFO is available but no egg info is, we use that for
metadata in preference to
-# the parsed setup.py, but use the install_requires info from the
-# parsed setup.py.
-
-setupscript = os.path.join(srctree, 'setup.py')
-try:
-setup_info, uses_setuptools, setup_non_literals, extensions =
self.parse_setup_py(setupscript)
-except Exception:
-logger.exception("Failed to parse setup.py")
-setup_info, uses_setuptools, setup_non_literals, extensions = {},
True, [], []
-
-egginfo = glob.glob(os.path.join(srctree, '*.egg-info'))
-if egginfo:
-info = self.get_pkginfo(os.path.join(egginfo[0], 'PKG-INFO'))
-requires_txt = os.path.join(egginfo[0], 'requires.txt')
-if os.path.exists(requires_txt):
-with codecs.open(requires_txt) as f:
-inst_req = []
-extras_req = collections.defaultdict(list)
-current_feature = None
-for line in f.readlines():
-line = line.rstrip()
-if not line:
-
[OE-core] [PATCH v2 2/4] scripts:recipetool:create_buildsys_python: prefix created recipes with python3-
By convention, all python recipes start with "python3-" so update
create_buildsys_python to do this
This rule doesn't apply for packages already starting with "python"
Signed-off-by: Julien Stephan
---
scripts/lib/recipetool/create_buildsys_python.py | 5 +
1 file changed, 5 insertions(+)
diff --git a/scripts/lib/recipetool/create_buildsys_python.py
b/scripts/lib/recipetool/create_buildsys_python.py
index 321d0ba257d..502e1dfbc3d 100644
--- a/scripts/lib/recipetool/create_buildsys_python.py
+++ b/scripts/lib/recipetool/create_buildsys_python.py
@@ -297,6 +297,11 @@ class PythonRecipeHandler(RecipeHandler):
value = ' '.join(str(v) for v in values if v)
bbvar = self.bbvar_map[field]
+if bbvar == "PN":
+# by convention python recipes start with "python3-"
+if not value.startswith('python'):
+value = 'python3-' + value
+
if bbvar not in extravalues and value:
extravalues[bbvar] = value
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189428):
https://lists.openembedded.org/g/openembedded-core/message/189428
Mute This Topic: https://lists.openembedded.org/mt/102055996/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH v2 1/4] scripts:recipetool:create_buildsys_python: fix license note
License field of setup is not always standardized, so we usually use the
classifier to determine the correct license format to use in the recipe.
A warning note is added above the LICENSE field of the create recipe
in case a license is provided in setup. But when the plugin is called,
"LICENSE =" is not yet present so we can never display this note.
Replace the "LICENSE =" condition with "##LICENSE_PLACEHOLDER##"
to actually be able to display the note message
Signed-off-by: Julien Stephan
---
scripts/lib/recipetool/create_buildsys_python.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/scripts/lib/recipetool/create_buildsys_python.py
b/scripts/lib/recipetool/create_buildsys_python.py
index 92468b22546..321d0ba257d 100644
--- a/scripts/lib/recipetool/create_buildsys_python.py
+++ b/scripts/lib/recipetool/create_buildsys_python.py
@@ -254,7 +254,7 @@ class PythonRecipeHandler(RecipeHandler):
if license_str:
for i, line in enumerate(lines_before):
-if line.startswith('LICENSE = '):
+if line.startswith('##LICENSE_PLACEHOLDER##'):
lines_before.insert(i, '# NOTE: License in
setup.py/PKGINFO is: %s' % license_str)
break
--
2.42.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#189429):
https://lists.openembedded.org/g/openembedded-core/message/189429
Mute This Topic: https://lists.openembedded.org/mt/102055997/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [mickledore][kirkstone][PATCH] qemu: ignore RHEL specific CVE-2023-2680
From: Lee Chee Yang Signed-off-by: Lee Chee Yang --- meta/recipes-devtools/qemu/qemu.inc | 4 1 file changed, 4 insertions(+) diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-devtools/qemu/qemu.inc index 5526eacb960..83bd5d7e67d 100644 --- a/meta/recipes-devtools/qemu/qemu.inc +++ b/meta/recipes-devtools/qemu/qemu.inc @@ -125,6 +125,10 @@ CVE_CHECK_IGNORE += "CVE-2018-18438" # this bug related to windows specific. CVE_CHECK_IGNORE += "CVE-2023-0664" +# As per https://bugzilla.redhat.com/show_bug.cgi?id=2203387 +# RHEL specific issue +CVE_CHECK_IGNORE += "CVE-2023-2680" + COMPATIBLE_HOST:mipsarchn32 = "null" COMPATIBLE_HOST:mipsarchn64 = "null" COMPATIBLE_HOST:riscv32 = "null" -- 2.37.3 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#189427): https://lists.openembedded.org/g/openembedded-core/message/189427 Mute This Topic: https://lists.openembedded.org/mt/102055231/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
