[OE-core] [PATCH 3/3] alsa-lib: Disable old API symbols
These symbols are currently generated as undefined in the shared object,
which means we really do not need them.
Signed-off-by: Khem Raj
---
meta/recipes-multimedia/alsa/alsa-lib_1.2.9.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/alsa/alsa-lib_1.2.9.bb
b/meta/recipes-multimedia/alsa/alsa-lib_1.2.9.bb
index a8bf09904d9..d482e27683b 100644
--- a/meta/recipes-multimedia/alsa/alsa-lib_1.2.9.bb
+++ b/meta/recipes-multimedia/alsa/alsa-lib_1.2.9.bb
@@ -16,7 +16,7 @@ inherit autotools pkgconfig
EXTRA_OECONF += " \
${@bb.utils.contains('TARGET_FPU', 'soft', '--with-softfloat', '', d)} \
---disable-python \
+--disable-python --disable-old-symbols \
"
PACKAGES =+ "alsa-server alsa-conf libatopology"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183358):
https://lists.openembedded.org/g/openembedded-core/message/183358
Mute This Topic: https://lists.openembedded.org/mt/99749302/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/3] libxcrypt: Limit to enabling strong hash algos only
This ensures that weak algorithms are not included, which should improve
the defauls to be more secure
Signed-off-by: Khem Raj
---
meta/recipes-core/libxcrypt/libxcrypt.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/libxcrypt/libxcrypt.inc
b/meta/recipes-core/libxcrypt/libxcrypt.inc
index 997e83fb004..db43a34b11d 100644
--- a/meta/recipes-core/libxcrypt/libxcrypt.inc
+++ b/meta/recipes-core/libxcrypt/libxcrypt.inc
@@ -29,7 +29,7 @@ BUILD_CPPFLAGS = "-I${STAGING_INCDIR_NATIVE}"
TARGET_CPPFLAGS = "-I${STAGING_DIR_TARGET}${includedir} -Wno-error"
CPPFLAGS:append:class-nativesdk = " -Wno-error"
-API = "--disable-obsolete-api"
+API = "--disable-obsolete-api --enable-hashes=strong"
EXTRA_OECONF += "${API}"
BBCLASSEXTEND = "native nativesdk"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183356):
https://lists.openembedded.org/g/openembedded-core/message/183356
Mute This Topic: https://lists.openembedded.org/mt/99749300/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/3] mesa: Fix build with upcoming LLVM 17
Signed-off-by: Khem Raj
---
.../0001-gallium-Fix-build-with-llvm-17.patch | 34 +++
meta/recipes-graphics/mesa/mesa.inc | 6
2 files changed, 40 insertions(+)
create mode 100644
meta/recipes-graphics/mesa/files/0001-gallium-Fix-build-with-llvm-17.patch
diff --git
a/meta/recipes-graphics/mesa/files/0001-gallium-Fix-build-with-llvm-17.patch
b/meta/recipes-graphics/mesa/files/0001-gallium-Fix-build-with-llvm-17.patch
new file mode 100644
index 000..3631a918b0c
--- /dev/null
+++ b/meta/recipes-graphics/mesa/files/0001-gallium-Fix-build-with-llvm-17.patch
@@ -0,0 +1,34 @@
+From 865762e0a767a121206d818bdd58301afbf30104 Mon Sep 17 00:00:00 2001
+From: Khem Raj
+Date: Fri, 23 Jun 2023 01:20:38 -0700
+Subject: [PATCH] gallium: Fix build with llvm 17
+
+These headers are not available for C files in llvm 17+
+and they seem to be not needed to compile after all with llvm 17
+so add conditions to exclude them for llvm >= 17
+
+Upstream-Status: Submitted
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/23827]
+Signed-off-by: Khem Raj
+---
+ src/gallium/auxiliary/gallivm/lp_bld_init.c | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
+index 24d0823..3d4573e 100644
+--- a/src/gallium/auxiliary/gallivm/lp_bld_init.c
b/src/gallium/auxiliary/gallivm/lp_bld_init.c
+@@ -42,8 +42,10 @@
+
+ #include
+ #include
++#if LLVM_VERSION_MAJOR < 17
+ #include
+-#if LLVM_VERSION_MAJOR >= 7
++#endif
++#if LLVM_VERSION_MAJOR >= 7 && LLVM_VERSION_MAJOR < 17
+ #include
+ #endif
+ #include
+--
+2.41.0
+
diff --git a/meta/recipes-graphics/mesa/mesa.inc
b/meta/recipes-graphics/mesa/mesa.inc
index ac42a8dd4f3..c988c77115b 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -17,6 +17,7 @@ PE = "2"
SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
+ file://0001-gallium-Fix-build-with-llvm-17.patch \
"
SRC_URI[sha256sum] =
"a2679031ed5b73b29c4f042ac64d96f83b0cfe4858617de32e2efc196c653a40"
@@ -74,6 +75,11 @@ EXTRA_OEMESON = " \
def strip_comma(s):
return s.strip(',')
+# llvm-config should be the one from llvm-native and not from build host ( if
llvm is installed on host )
+do_write_config:append() {
+sed -i -e '/\[binaries\]/a\' -e "llvm-config =
'${STAGING_BINDIR_NATIVE}/llvm-config'" ${WORKDIR}/meson.native
+}
+
PACKAGECONFIG = " \
gallium \
${@bb.utils.filter('DISTRO_FEATURES', 'x11 vulkan wayland', d)} \
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183357):
https://lists.openembedded.org/g/openembedded-core/message/183357
Mute This Topic: https://lists.openembedded.org/mt/99749301/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 0/3] wayland/weston upgrades
I have meanwhile been addressing all these issues in parallel with pidge. There's a patch here: https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/package-version-updates and it doesn't show issues in a-full. If you''re pressed for time, I can simply submit my version when the whole patchset is ready. Alex On Fri, 23 Jun 2023 at 12:53, Luca Ceresoli via lists.openembedded.org wrote: > > Hello Eilís, > > On Fri, 23 Jun 2023 11:21:29 +0100 > Eilís 'pidge' Ní Fhlannagáin wrote: > > > On 23/06/2023 09:46, Luca Ceresoli wrote: > > > Hello Eilís, > > > > > > On Thu, 22 Jun 2023 15:42:14 +0100 > > > Eilís 'pidge' Ní Fhlannagáin wrote: > > > > > >> Nothing really surprising here, except we should note that > > >> launcher-logind is > > >> being depreciated so some thought on how that is dealt with will need to > > >> occur > > > > > > Should we file a bug in bugzilla to avoid forgetting about this? > > > > Yes, I'll assign it to myself. Alex had suggested we just require seatd > > which to me makes the most sense. > > OK, so it I guess you should add it as soon as a future version of > this series is accepted, unless you have managed to handle this > properly by then. > > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183355): https://lists.openembedded.org/g/openembedded-core/message/183355 Mute This Topic: https://lists.openembedded.org/mt/99702158/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] baremetal-helloworld: Fix race condition
There was a race condition during the Makefile execution in
between the assemble and compile targets, only the assemble
target had a dependency on creating the build directory.
If the compile target was executed first, an error was thrown
by bitbake since the build directory did not exist yet:
| Assembler messages:
| Fatal error: can't create build/hello_baremetal_aarch64.o:
No such file or directory
Update the SRCREV to reflect the latest changes serializing
the makefile targets to avoid such race condition from happening.
[YOCTO #15146]
Signed-off-by: Alejandro Enedino Hernandez Samaniego
---
.../baremetal-example/baremetal-helloworld_git.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git
a/meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb
b/meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb
index 4182372057..c5d3e04ed5 100644
--- a/meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb
+++ b/meta/recipes-extended/baremetal-example/baremetal-helloworld_git.bb
@@ -4,7 +4,7 @@ DESCRIPTION = "These are introductory examples to showcase the
use of QEMU to ru
LICENSE = "MIT"
LIC_FILES_CHKSUM = "file://LICENSE;md5=39346640a23c701e4f459e05f56f4449"
-SRCREV = "ea7f59b02467ed1fb36c3b4c6d5cabe702df26ec"
+SRCREV = "fc7c43d138185028b6ac14c83f6492fce26eca95"
PV = "0.1+git${SRCPV}"
SRC_URI =
"git://github.com/ahcbb6/baremetal-helloqemu.git;protocol=https;branch=master"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183354):
https://lists.openembedded.org/g/openembedded-core/message/183354
Mute This Topic: https://lists.openembedded.org/mt/99745564/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][kirkstone][PATCH] libcap: CVE-2023-2603 Integer Overflow in _libcap_strdup()
Due to a space in the URL the backport resolves to the wrong patch (HEAD) which
is included rather than the one actually at
https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?id=422bec25ae4a1ab03fd4d6f728695ed279173b18
From: openembedded-core@lists.openembedded.org
on behalf of vkumbhar via
lists.openembedded.org
Sent: Thursday, June 22, 2023 10:19 PM
To: openembedded-core@lists.openembedded.org
Cc: Vivek Kumbhar
Subject: [OE-core][kirkstone][PATCH] libcap: CVE-2023-2603 Integer Overflow in
_libcap_strdup()
Signed-off-by: Vivek Kumbhar
---
.../libcap/files/CVE-2023-2603.patch | 31 +++
meta/recipes-support/libcap/libcap_2.66.bb| 1 +
2 files changed, 32 insertions(+)
create mode 100644 meta/recipes-support/libcap/files/CVE-2023-2603.patch
diff --git a/meta/recipes-support/libcap/files/CVE-2023-2603.patch
b/meta/recipes-support/libcap/files/CVE-2023-2603.patch
new file mode 100644
index 00..c5ecb70896
--- /dev/null
+++ b/meta/recipes-support/libcap/files/CVE-2023-2603.patch
@@ -0,0 +1,31 @@
+From 8785077d6c69482a2814a2f771aaada2f6ea1894 Mon Sep 17 00:00:00 2001
+From: "Andrew G. Morgan"
+Date: Wed, 24 May 2023 06:55:47 -0700
+Subject: Tidy up the overview example for the "cap" package.
+
+Signed-off-by: Andrew G. Morgan
+
+Upstream-Status: Backport
[https://git.kernel.org/pub/scm/libs/libcap/libcap.git/commit/?%20id=422bec25ae4a1ab03fd4d6f728695ed279173b18]
+CVE: CVE-2023-2603
+Signed-off-by: Vivek Kumbhar
+---
+ cap/cap.go | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/cap/cap.go b/cap/cap.go
+index 784bf65..df32436 100644
+--- a/cap/cap.go
b/cap/cap.go
+@@ -17,7 +17,8 @@
+ //
+ // // Read and display the capabilities of the running process
+ // c := cap.GetProc()
+-// log.Printf("this process has these caps:", c)
++// iab := cap.IABGetProc()
++// log.Printf("this process has these caps: %q [%v]", c, iab)
+ //
+ // // Drop any privilege a process might have (including for root,
+ // // but note root 'owns' a lot of system files so a cap-limited
+--
+2.25.1
+
diff --git a/meta/recipes-support/libcap/libcap_2.66.bb
b/meta/recipes-support/libcap/libcap_2.66.bb
index c50e9d8cc7..844ae58506 100644
--- a/meta/recipes-support/libcap/libcap_2.66.bb
+++ b/meta/recipes-support/libcap/libcap_2.66.bb
@@ -19,6 +19,7 @@ SRC_URI =
"${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${
"
SRC_URI:append:class-nativesdk = " \
file://0001-nativesdk-libcap-Raise-the-size-of-arrays-containing.patch \
+ file://CVE-2023-2603.patch \
"
SRC_URI[sha256sum] =
"15c40ededb3003d70a283fe587a36b7d19c8b3b554e33f86129c059a4bb466b2"
--
2.25.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183353):
https://lists.openembedded.org/g/openembedded-core/message/183353
Mute This Topic: https://lists.openembedded.org/mt/99713227/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] python3-pygobject: disable features_check for class-native
On 23 Jun 2023, at 18:50, Markus Volk via lists.openembedded.org wrote: > > https://git.yoctoproject.org/poky/commit/?id=1ee93dc114df26d94310682e6a632327e8bce062 > mandates gobject-introspection-data DISTRO_FEATURE which is not availabe for > native. > Thus python3-pygobject-native gets unbuildable > > ERROR: Nothing PROVIDES 'python3-pygobject-native' > python3-pygobject-native was skipped: missing required distro feature > 'gobject-introspection-data' (not in DISTRO_FEATURES) pygobject can’t work without g-i so this indicates that you need to fix a DEPENDS, not enable the building of an unusable recipe. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183352): https://lists.openembedded.org/g/openembedded-core/message/183352 Mute This Topic: https://lists.openembedded.org/mt/99723340/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] python3-pygobject: disable features_check for class-native
https://git.yoctoproject.org/poky/commit/?id=1ee93dc114df26d94310682e6a632327e8bce062 mandates gobject-introspection-data DISTRO_FEATURE which is not availabe for native. Thus python3-pygobject-native gets unbuildable ERROR: Nothing PROVIDES 'python3-pygobject-native' python3-pygobject-native was skipped: missing required distro feature 'gobject-introspection-data' (not in DISTRO_FEATURES) Limit the requirement for gobject-introspection-data to class-target Signed-off-by: Markus Volk --- meta/recipes-devtools/python/python3-pygobject_3.44.1.bb | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb b/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb index 6f7d9a09ec..f6fb9688ca 100644 --- a/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb +++ b/meta/recipes-devtools/python/python3-pygobject_3.44.1.bb @@ -10,7 +10,7 @@ GIR_MESON_OPTION = "" inherit gnomebase setuptools3-base gobject-introspection upstream-version-is-even features_check -REQUIRED_DISTRO_FEATURES = "gobject-introspection-data" +REQUIRED_DISTRO_FEATURES:class-target = "gobject-introspection-data" DEPENDS += "python3 glib-2.0" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183351): https://lists.openembedded.org/g/openembedded-core/message/183351 Mute This Topic: https://lists.openembedded.org/mt/99723340/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] tiff: backport a fix for CVE-2023-26965
Fixes a bug where a buffer was used after a potential reallocation.
Signed-off-by: Natasha Bailey
---
.../libtiff/files/CVE-2023-26965.patch| 99 +++
meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 1 +
2 files changed, 100 insertions(+)
create mode 100644 meta/recipes-multimedia/libtiff/files/CVE-2023-26965.patch
diff --git a/meta/recipes-multimedia/libtiff/files/CVE-2023-26965.patch
b/meta/recipes-multimedia/libtiff/files/CVE-2023-26965.patch
new file mode 100644
index 00..5fdc1ed013
--- /dev/null
+++ b/meta/recipes-multimedia/libtiff/files/CVE-2023-26965.patch
@@ -0,0 +1,99 @@
+From ec8ef90c1f573c9eb1f17d6a056aa0015f184acf Mon Sep 17 00:00:00 2001
+From: Su_Laus
+Date: Tue, 14 Feb 2023 20:43:43 +0100
+Subject: [PATCH] tiffcrop: Do not reuse input buffer for subsequent images.
+ Fix issue 527
+
+Reuse of read_buff within loadImage() from previous image is quite unsafe,
because other functions (like rotateImage() etc.) reallocate that buffer with
different size without updating the local prev_readsize value.
+
+Closes #527
+
+CVE: CVE-2023-26965
+Upstream-Status: Backport
[https://gitlab.com/libtiff/libtiff/-/commit/ec8ef90c1f573c9eb1f17d6a056aa0015f184acf]
+Signed-off-by: Natasha Bailey
+---
+ tools/tiffcrop.c | 47 +--
+ 1 file changed, 13 insertions(+), 34 deletions(-)
+
+diff --git a/tools/tiffcrop.c b/tools/tiffcrop.c
+index d7ad5ca8..d3e11ba2 100644
+--- a/tools/tiffcrop.c
b/tools/tiffcrop.c
+@@ -6771,9 +6771,7 @@ static int loadImage(TIFF *in, struct image_data *image,
struct dump_opts *dump,
+ uint32_t tw = 0, tl = 0; /* Tile width and length */
+ tmsize_t tile_rowsize = 0;
+ unsigned char *read_buff = NULL;
+-unsigned char *new_buff = NULL;
+ int readunit = 0;
+-static tmsize_t prev_readsize = 0;
+
+ TIFFGetFieldDefaulted(in, TIFFTAG_BITSPERSAMPLE, );
+ TIFFGetFieldDefaulted(in, TIFFTAG_SAMPLESPERPIXEL, );
+@@ -7097,43 +7095,25 @@ static int loadImage(TIFF *in, struct image_data
*image, struct dump_opts *dump,
+ }
+
+ read_buff = *read_ptr;
+-/* +3 : add a few guard bytes since reverseSamples16bits() can read a bit
*/
+-/* outside buffer */
+-if (!read_buff)
++/* +3 : add a few guard bytes since reverseSamples16bits() can read a bit
++ * outside buffer */
++/* Reuse of read_buff from previous image is quite unsafe, because other
++ * functions (like rotateImage() etc.) reallocate that buffer with
different
++ * size without updating the local prev_readsize value. */
++if (read_buff)
+ {
+-if (buffsize > 0xU - 3)
+-{
+-TIFFError("loadImage", "Unable to allocate/reallocate read
buffer");
+-return (-1);
+-}
+-read_buff =
+-(unsigned char *)limitMalloc(buffsize + NUM_BUFF_OVERSIZE_BYTES);
++_TIFFfree(read_buff);
+ }
+-else
++if (buffsize > 0xU - 3)
+ {
+-if (prev_readsize < buffsize)
+-{
+-if (buffsize > 0xU - 3)
+-{
+-TIFFError("loadImage",
+- "Unable to allocate/reallocate read buffer");
+-return (-1);
+-}
+-new_buff =
+-_TIFFrealloc(read_buff, buffsize + NUM_BUFF_OVERSIZE_BYTES);
+-if (!new_buff)
+-{
+-free(read_buff);
+-read_buff = (unsigned char *)limitMalloc(
+-buffsize + NUM_BUFF_OVERSIZE_BYTES);
+-}
+-else
+-read_buff = new_buff;
+-}
++TIFFError("loadImage", "Required read buffer size too large");
++return (-1);
+ }
++read_buff =
++(unsigned char *)limitMalloc(buffsize + NUM_BUFF_OVERSIZE_BYTES);
+ if (!read_buff)
+ {
+-TIFFError("loadImage", "Unable to allocate/reallocate read buffer");
++TIFFError("loadImage", "Unable to allocate read buffer");
+ return (-1);
+ }
+
+@@ -7141,7 +7121,6 @@ static int loadImage(TIFF *in, struct image_data *image,
struct dump_opts *dump,
+ read_buff[buffsize + 1] = 0;
+ read_buff[buffsize + 2] = 0;
+
+-prev_readsize = buffsize;
+ *read_ptr = read_buff;
+
+ /* N.B. The read functions used copy separate plane data into a buffer as
+--
+2.39.0
+
diff --git a/meta/recipes-multimedia/libtiff/tiff_4.5.0.bb
b/meta/recipes-multimedia/libtiff/tiff_4.5.0.bb
index ca4a3eff91..2bde8fe9d6 100644
--- a/meta/recipes-multimedia/libtiff/tiff_4.5.0.bb
+++ b/meta/recipes-multimedia/libtiff/tiff_4.5.0.bb
@@ -11,6 +11,7 @@ CVE_PRODUCT = "libtiff"
SRC_URI = "http://download.osgeo.org/libtiff/tiff-${PV}.tar.gz \
file://CVE-2022-48281.patch \
file://CVE-2023-2731.patch \
+ file://CVE-2023-26965.patch \
"
SRC_URI[sha256sum] =
"c7a1d9296649233979fa3eacffef3fa024d73d05d589cb622727b5b08c423464"
--
2.39.0
Re: [OE-core] [PATCH v2 0/3] wayland/weston upgrades
On 23/06/2023 09:46, Luca Ceresoli wrote: Hello Eilís, On Thu, 22 Jun 2023 15:42:14 +0100 Eilís 'pidge' Ní Fhlannagáin wrote: Nothing really surprising here, except we should note that launcher-logind is being depreciated so some thought on how that is dealt with will need to occur Should we file a bug in bugzilla to avoid forgetting about this? Yes, I'll assign it to myself. Alex had suggested we just require seatd which to me makes the most sense. -e Luca -- Eilís 'pidge' Ní Fhlannagáin BayLibre - At the Heart of Embedded Linux www.baylibre.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183348): https://lists.openembedded.org/g/openembedded-core/message/183348 Mute This Topic: https://lists.openembedded.org/mt/99702158/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 2/3] weston: Upgrade 11.0.1 -> 12.0.1
On 23/06/2023 11:16, Luca Ceresoli wrote:
Hello Eilís,
On Thu, 22 Jun 2023 15:42:16 +0100
Eilís 'pidge' Ní Fhlannagáin wrote:
Tracking https://gitlab.freedesktop.org/wayland/weston/-/issues/488
we're keeping -Ddeprecated-launcher-logind but plans should be made to
remove this/work around.
We also need to add xcb-util-cursor from meta-openembedded as this is
now required for ptest. When this is pulled we can remove from meta-oe.
Signed-off-by: Eilís 'pidge' Ní Fhlannagáin
---
.../wayland/{weston_11.0.1.bb => weston_12.0.1.bb}| 11 ---
.../xorg-lib/xcb-util-cursor_0.1.4.bb | 10 ++
This is triggering failures on no-x11 builds:
stdio: ERROR: Nothing PROVIDES 'xcb-util' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
DEPENDS on or otherwise requires it)
stdio: ERROR: Nothing PROVIDES 'xcb-util-cursor' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
DEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-init' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-dev' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-init-dev' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-examples' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
Full logs:
https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/7354/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/7354/steps/15/logs/stdio
Patch "weston: Cleanup and fix x11 and xwayland dependencies"
(https://lore.kernel.org/openembedded-core/20230622203913.183451-1-tom.hochst...@nxp.com/T/#u)
was sent a few hours after yours by Tom (in Cc:). Do think it could fix
this error? FYI I'm running a new test build with Tom's patch and
without this series.
No, but it does point to where I think the issue is. Specifically, the
DEPENDS for ptest was incorrect, in that it pulls xcb-util for ptest,
even if we're doing a no-x11 build. I need to see what ptest does for
no-x11 if xcb-util doesn't exist and rework based on that. I'll have a
v3 early next week.
Additionally a new recipe in core needs a maintainer, and as such it is
warning:
WARNING: xcb-util-cursor-0.1.4-r0 do_fetch: QA Issue: Recipe xcb-util-cursor in
/home/pokybuild/yocto-worker/a-full/build/meta/recipes-graphics/xorg-lib/xcb-util-cursor_0.1.4.bb
does not have an assigned maintainer. Please add an entry into
meta/conf/distro/include/maintainers.inc. [missing-metadata]
I'll add that in v3 and take maintainership.
Full log:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5511/steps/13/logs/stdio
Luca
--
Eilís 'pidge' Ní Fhlannagáin
BayLibre - At the Heart of Embedded Linux
www.baylibre.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183349):
https://lists.openembedded.org/g/openembedded-core/message/183349
Mute This Topic: https://lists.openembedded.org/mt/99702160/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] gcc : upgrade to v12.3
gcc stable version upgraded from v12.2 to v12.3
Below is the bug fix list for v12.3
https://gcc.gnu.org/bugzilla/buglist.cgi?bug_status=RESOLVED=FIXED_milestone=12.3
Signed-off-by: Sundeep KOKKONDA
---
meta/recipes-devtools/gcc/{gcc-12.2.inc => gcc-12.3.inc}| 6 +++---
...cc-cross-canadian_12.2.bb => gcc-cross-canadian_12.3.bb} | 0
.../gcc/{gcc-cross_12.2.bb => gcc-cross_12.3.bb}| 0
.../gcc/{gcc-crosssdk_12.2.bb => gcc-crosssdk_12.3.bb} | 0
.../gcc/{gcc-runtime_12.2.bb => gcc-runtime_12.3.bb}| 0
.../gcc/{gcc-sanitizers_12.2.bb => gcc-sanitizers_12.3.bb} | 0
.../gcc/{gcc-source_12.2.bb => gcc-source_12.3.bb} | 0
meta/recipes-devtools/gcc/{gcc_12.2.bb => gcc_12.3.bb} | 0
.../gcc/{libgcc-initial_12.2.bb => libgcc-initial_12.3.bb} | 0
.../recipes-devtools/gcc/{libgcc_12.2.bb => libgcc_12.3.bb} | 0
.../gcc/{libgfortran_12.2.bb => libgfortran_12.3.bb}| 0
11 files changed, 3 insertions(+), 3 deletions(-)
rename meta/recipes-devtools/gcc/{gcc-12.2.inc => gcc-12.3.inc} (97%)
rename meta/recipes-devtools/gcc/{gcc-cross-canadian_12.2.bb =>
gcc-cross-canadian_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-cross_12.2.bb => gcc-cross_12.3.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-crosssdk_12.2.bb =>
gcc-crosssdk_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-runtime_12.2.bb => gcc-runtime_12.3.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc-sanitizers_12.2.bb =>
gcc-sanitizers_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{gcc-source_12.2.bb => gcc-source_12.3.bb}
(100%)
rename meta/recipes-devtools/gcc/{gcc_12.2.bb => gcc_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc-initial_12.2.bb =>
libgcc-initial_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{libgcc_12.2.bb => libgcc_12.3.bb} (100%)
rename meta/recipes-devtools/gcc/{libgfortran_12.2.bb => libgfortran_12.3.bb}
(100%)
diff --git a/meta/recipes-devtools/gcc/gcc-12.2.inc
b/meta/recipes-devtools/gcc/gcc-12.3.inc
similarity index 97%
rename from meta/recipes-devtools/gcc/gcc-12.2.inc
rename to meta/recipes-devtools/gcc/gcc-12.3.inc
index 0dbbecad4a..4ec03f925c 100644
--- a/meta/recipes-devtools/gcc/gcc-12.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-12.3.inc
@@ -2,11 +2,11 @@ require gcc-common.inc
# Third digit in PV should be incremented after a minor release
-PV = "12.2.0"
+PV = "12.3.0"
# BINV should be incremented to a revision after a minor gcc release
-BINV = "12.2.0"
+BINV = "12.3.0"
FILESEXTRAPATHS =. "${FILE_DIRNAME}/gcc:${FILE_DIRNAME}/gcc/backport:"
@@ -64,7 +64,7 @@ SRC_URI = "${BASEURI} \
file://prefix-map-realpath.patch \
file://hardcoded-paths.patch \
"
-SRC_URI[sha256sum] =
"e549cf9cf3594a00e27b6589d4322d70e0720cdd213f39beb4181e06926230ff"
+SRC_URI[sha256sum] =
"949a5d4f99e786421a93b532b22ffab5578de7321369975b91aec97adfda8c3b"
S = "${TMPDIR}/work-shared/gcc-${PV}-${PR}/${SOURCEDIR}"
B = "${WORKDIR}/gcc-${PV}/build.${HOST_SYS}.${TARGET_SYS}"
diff --git a/meta/recipes-devtools/gcc/gcc-cross-canadian_12.2.bb
b/meta/recipes-devtools/gcc/gcc-cross-canadian_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross-canadian_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-cross-canadian_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc-cross_12.2.bb
b/meta/recipes-devtools/gcc/gcc-cross_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-cross_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-cross_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk_12.2.bb
b/meta/recipes-devtools/gcc/gcc-crosssdk_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-crosssdk_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-crosssdk_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc-runtime_12.2.bb
b/meta/recipes-devtools/gcc/gcc-runtime_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-runtime_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-runtime_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
b/meta/recipes-devtools/gcc/gcc-sanitizers_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-sanitizers_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-sanitizers_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc-source_12.2.bb
b/meta/recipes-devtools/gcc/gcc-source_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc-source_12.2.bb
rename to meta/recipes-devtools/gcc/gcc-source_12.3.bb
diff --git a/meta/recipes-devtools/gcc/gcc_12.2.bb
b/meta/recipes-devtools/gcc/gcc_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/gcc_12.2.bb
rename to meta/recipes-devtools/gcc/gcc_12.3.bb
diff --git a/meta/recipes-devtools/gcc/libgcc-initial_12.2.bb
b/meta/recipes-devtools/gcc/libgcc-initial_12.3.bb
similarity index 100%
rename from meta/recipes-devtools/gcc/libgcc-initial_12.2.bb
rename to meta/recipes-devtools/gcc/libgcc-initial_12.3.bb
diff --git
[oe-core][kirkstone][PATCHv2 2/8] weston-init: introduce xwayland PACKAGECONFIG
From: Ming Liu
Some BSPs dont support xwayland in weston, this is easier for them to
control that.
Signed-off-by: Ming Liu
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/wayland/weston-init.bb | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 77dda03cf55..a7adce7fda8 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -14,10 +14,11 @@ SRC_URI = "file://init \
S = "${WORKDIR}"
-PACKAGECONFIG ??= ""
+PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'xwayland',
'', d)}"
PACKAGECONFIG:append:qemuriscv64 = " use-pixman"
PACKAGECONFIG:append:qemuppc64 = " use-pixman"
+PACKAGECONFIG[xwayland] = ",,"
PACKAGECONFIG[no-idle-timeout] = ",,"
PACKAGECONFIG[use-pixman] = ",,"
@@ -50,7 +51,7 @@ do_install() {
sed -i -e "/^\[core\]/a backend=${DEFAULTBACKEND}-backend.so"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
- if [ "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'yes', 'no', d)}"
= "yes" ]; then
+ if [ "${@bb.utils.contains('PACKAGECONFIG', 'xwayland', 'yes', 'no',
d)}" = "yes" ]; then
sed -i -e "/^\[core\]/a xwayland=true"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183344):
https://lists.openembedded.org/g/openembedded-core/message/183344
Mute This Topic: https://lists.openembedded.org/mt/99721740/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][PATCHv2 4/8] weston-init: add weston user to the render group
From: Randolph Sapp
The weston user must be in the render group in order to access render
device nodes for standard user-space graphics.
Signed-off-by: Randolph Sapp
Signed-off-by: Alexandre Belloni
---
meta/recipes-graphics/wayland/weston-init.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index b637fa6a4a5..6d62993d7da 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -93,6 +93,6 @@ FILES:${PN} += "\
CONFFILES:${PN} += "${sysconfdir}/xdg/weston/weston.ini
${sysconfdir}/default/weston"
SYSTEMD_SERVICE:${PN} = "weston.service weston.socket"
-USERADD_PARAM:${PN} = "--home /home/weston --shell /bin/sh --user-group -G
video,input weston"
+USERADD_PARAM:${PN} = "--home /home/weston --shell /bin/sh --user-group -G
video,input,render weston"
GROUPADD_PARAM:${PN} = "-r wayland; -r render"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183343):
https://lists.openembedded.org/g/openembedded-core/message/183343
Mute This Topic: https://lists.openembedded.org/mt/99721739/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][PATCHv2 1/8] weston.init: enabled xwayland
From: ssuesens
set xwayland support in weston.init file to true
Signed-off-by: ssuesens
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/wayland/weston-init.bb | 4
1 file changed, 4 insertions(+)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 497d8602038..77dda03cf55 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -50,6 +50,10 @@ do_install() {
sed -i -e "/^\[core\]/a backend=${DEFAULTBACKEND}-backend.so"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
+ if [ "${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'yes', 'no', d)}"
= "yes" ]; then
+ sed -i -e "/^\[core\]/a xwayland=true"
${D}${sysconfdir}/xdg/weston/weston.ini
+ fi
+
if [ "${@bb.utils.contains('PACKAGECONFIG', 'no-idle-timeout', 'yes',
'no', d)}" = "yes" ]; then
sed -i -e "/^\[core\]/a idle-time=0"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183345):
https://lists.openembedded.org/g/openembedded-core/message/183345
Mute This Topic: https://lists.openembedded.org/mt/99721741/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][PATCHv2 6/8] weston-init: fix the mixed indentation
From: Randolph Sapp
I know my text editor is going to get angry at me if this continues.
Signed-off-by: Randolph Sapp
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/wayland/weston-init.bb | 10 +-
1 file changed, 5 insertions(+), 5 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 4fa302c8333..e538469a58b 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -26,19 +26,19 @@ DEFAULTBACKEND ??= ""
DEFAULTBACKEND:qemuall ?= "drm"
do_install() {
-if [ "${VIRTUAL-RUNTIME_init_manager}" != "systemd" ]; then
+ if [ "${VIRTUAL-RUNTIME_init_manager}" != "systemd" ]; then
install -Dm755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
sed -i 's#ROOTHOME#${ROOT_HOME}#'
${D}/${sysconfdir}/init.d/weston
-fi
+ fi
install -D -p -m0644 ${WORKDIR}/weston.ini
${D}${sysconfdir}/xdg/weston/weston.ini
install -Dm644 ${WORKDIR}/weston.env ${D}${sysconfdir}/default/weston
# Install Weston systemd service and accompanying udev rule
install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
-if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
+ if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
install -D -p -m0644 ${WORKDIR}/weston-autologin
${D}${sysconfdir}/pam.d/weston-autologin
-fi
+ fi
sed -i -e s:/etc:${sysconfdir}:g \
-e s:/usr/bin:${bindir}:g \
-e s:/var:${localstatedir}:g \
@@ -47,7 +47,7 @@ do_install() {
install -Dm755 ${WORKDIR}/weston-start ${D}${bindir}/weston-start
sed -i 's,@DATADIR@,${datadir},g' ${D}${bindir}/weston-start
sed -i 's,@LOCALSTATEDIR@,${localstatedir},g' ${D}${bindir}/weston-start
-if [ -n "${DEFAULTBACKEND}" ]; then
+ if [ -n "${DEFAULTBACKEND}" ]; then
sed -i -e "/^\[core\]/a backend=${DEFAULTBACKEND}-backend.so"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183337):
https://lists.openembedded.org/g/openembedded-core/message/183337
Mute This Topic: https://lists.openembedded.org/mt/99721733/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][PATCHv2 7/8] weston-init: guard against systemd configs
From: Randolph Sapp
Just as sysvinit scripts shouldn't be present in a distro using systemd,
systemd scripts shouldn't be present in a system not using systemd.
Signed-off-by: Randolph Sapp
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/wayland/weston-init.bb | 29
1 file changed, 17 insertions(+), 12 deletions(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index e538469a58b..9d892d58f2f 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -26,27 +26,32 @@ DEFAULTBACKEND ??= ""
DEFAULTBACKEND:qemuall ?= "drm"
do_install() {
+ # Install weston-start script
if [ "${VIRTUAL-RUNTIME_init_manager}" != "systemd" ]; then
+ install -Dm755 ${WORKDIR}/weston-start
${D}${bindir}/weston-start
+ sed -i 's,@DATADIR@,${datadir},g' ${D}${bindir}/weston-start
+ sed -i 's,@LOCALSTATEDIR@,${localstatedir},g'
${D}${bindir}/weston-start
install -Dm755 ${WORKDIR}/init ${D}/${sysconfdir}/init.d/weston
sed -i 's#ROOTHOME#${ROOT_HOME}#'
${D}/${sysconfdir}/init.d/weston
fi
- install -D -p -m0644 ${WORKDIR}/weston.ini
${D}${sysconfdir}/xdg/weston/weston.ini
- install -Dm644 ${WORKDIR}/weston.env ${D}${sysconfdir}/default/weston
# Install Weston systemd service and accompanying udev rule
- install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
- install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
+ if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
+ install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
+ install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
+ sed -i -e s:/etc:${sysconfdir}:g \
+ -e s:/usr/bin:${bindir}:g \
+ -e s:/var:${localstatedir}:g \
+ ${D}${systemd_system_unitdir}/weston.service
+ fi
+
if [ "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}" ]; then
install -D -p -m0644 ${WORKDIR}/weston-autologin
${D}${sysconfdir}/pam.d/weston-autologin
fi
- sed -i -e s:/etc:${sysconfdir}:g \
- -e s:/usr/bin:${bindir}:g \
- -e s:/var:${localstatedir}:g \
- ${D}${systemd_system_unitdir}/weston.service
- # Install weston-start script
- install -Dm755 ${WORKDIR}/weston-start ${D}${bindir}/weston-start
- sed -i 's,@DATADIR@,${datadir},g' ${D}${bindir}/weston-start
- sed -i 's,@LOCALSTATEDIR@,${localstatedir},g' ${D}${bindir}/weston-start
+
+ install -D -p -m0644 ${WORKDIR}/weston.ini
${D}${sysconfdir}/xdg/weston/weston.ini
+ install -Dm644 ${WORKDIR}/weston.env ${D}${sysconfdir}/default/weston
+
if [ -n "${DEFAULTBACKEND}" ]; then
sed -i -e "/^\[core\]/a backend=${DEFAULTBACKEND}-backend.so"
${D}${sysconfdir}/xdg/weston/weston.ini
fi
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183340):
https://lists.openembedded.org/g/openembedded-core/message/183340
Mute This Topic: https://lists.openembedded.org/mt/99721736/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][PATCHv2 8/8] weston-init: add profile to point users to global socket
From: Randolph Sapp
Add profile script to point users capable of interacting with the global
socket to it by default.
Signed-off-by: Randolph Sapp
Signed-off-by: Richard Purdie
---
meta/recipes-graphics/wayland/weston-init.bb | 3 +++
.../wayland/weston-init/weston-socket.sh | 20 +++
2 files changed, 23 insertions(+)
create mode 100755 meta/recipes-graphics/wayland/weston-init/weston-socket.sh
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 9d892d58f2f..1884b5d4401 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -9,6 +9,7 @@ SRC_URI = "file://init \
file://weston.ini \
file://weston.service \
file://weston.socket \
+ file://weston-socket.sh \
file://weston-autologin \
file://weston-start"
@@ -39,6 +40,7 @@ do_install() {
if ${@bb.utils.contains('DISTRO_FEATURES','systemd','true','false',d)};
then
install -D -p -m0644 ${WORKDIR}/weston.service
${D}${systemd_system_unitdir}/weston.service
install -D -p -m0644 ${WORKDIR}/weston.socket
${D}${systemd_system_unitdir}/weston.socket
+ install -D -p -m0644 ${WORKDIR}/weston-socket.sh
${D}${sysconfdir}/profile.d/weston-socket.sh
sed -i -e s:/etc:${sysconfdir}:g \
-e s:/usr/bin:${bindir}:g \
-e s:/var:${localstatedir}:g \
@@ -88,6 +90,7 @@ INITSCRIPT_PARAMS = "start 9 5 2 . stop 20 0 1 6 ."
FILES:${PN} += "\
${sysconfdir}/xdg/weston/weston.ini \
+${sysconfdir}/profile.d/weston-socket.sh \
${systemd_system_unitdir}/weston.service \
${systemd_system_unitdir}/weston.socket \
${sysconfdir}/default/weston \
diff --git a/meta/recipes-graphics/wayland/weston-init/weston-socket.sh
b/meta/recipes-graphics/wayland/weston-init/weston-socket.sh
new file mode 100755
index 000..86389d63a3b
--- /dev/null
+++ b/meta/recipes-graphics/wayland/weston-init/weston-socket.sh
@@ -0,0 +1,20 @@
+#!/bin/sh
+
+# set weston variables for use with global weston socket
+global_socket="/run/wayland-0"
+if [ -e "$global_socket" ]; then
+ weston_group=$(stat -c "%G" "$global_socket")
+ if [ "$(id -u)" = "0" ]; then
+ export WAYLAND_DISPLAY="$global_socket"
+ else
+ case "$(groups "$USER")" in
+ *"$weston_group"*)
+ export WAYLAND_DISPLAY="$global_socket"
+ ;;
+ *)
+ ;;
+ esac
+ fi
+ unset weston_group
+fi
+unset global_socket
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183341):
https://lists.openembedded.org/g/openembedded-core/message/183341
Mute This Topic: https://lists.openembedded.org/mt/99721737/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][PATCHv2 0/8] Backport all weston-init qol updates
From: Randolph Sapp Backport all the weston-init QOL updates. Getting closer to the point where we can actually drop our distro specific weston-init bbappend. May submit a few more QOL patches sooner or later to completely drop it. Resubmitting this because I forgot to CC Steve and myself on this series. Ming Liu (1): weston-init: introduce xwayland PACKAGECONFIG Randolph Sapp (6): weston-init: make sure the render group exists weston-init: add weston user to the render group weston-init: add the weston user to the wayland group weston-init: fix the mixed indentation weston-init: guard against systemd configs weston-init: add profile to point users to global socket ssuesens (1): weston.init: enabled xwayland meta/recipes-graphics/wayland/weston-init.bb | 53 --- .../wayland/weston-init/weston-socket.sh | 20 +++ 2 files changed, 53 insertions(+), 20 deletions(-) create mode 100755 meta/recipes-graphics/wayland/weston-init/weston-socket.sh -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183338): https://lists.openembedded.org/g/openembedded-core/message/183338 Mute This Topic: https://lists.openembedded.org/mt/99721734/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][PATCHv2 5/8] weston-init: add the weston user to the wayland group
From: Randolph Sapp
Add the weston user to the wayland group so all users accessing the
global weston socket in /run all share a group.
Signed-off-by: Randolph Sapp
Signed-off-by: Alexandre Belloni
---
meta/recipes-graphics/wayland/weston-init.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index 6d62993d7da..4fa302c8333 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -93,6 +93,6 @@ FILES:${PN} += "\
CONFFILES:${PN} += "${sysconfdir}/xdg/weston/weston.ini
${sysconfdir}/default/weston"
SYSTEMD_SERVICE:${PN} = "weston.service weston.socket"
-USERADD_PARAM:${PN} = "--home /home/weston --shell /bin/sh --user-group -G
video,input,render weston"
+USERADD_PARAM:${PN} = "--home /home/weston --shell /bin/sh --user-group -G
video,input,render,wayland weston"
GROUPADD_PARAM:${PN} = "-r wayland; -r render"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183339):
https://lists.openembedded.org/g/openembedded-core/message/183339
Mute This Topic: https://lists.openembedded.org/mt/99721735/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][PATCHv2 3/8] weston-init: make sure the render group exists
From: Randolph Sapp
Add the render group explicitly here to make sure it exists for the
useradd command.
Signed-off-by: Randolph Sapp
Signed-off-by: Alexandre Belloni
---
meta/recipes-graphics/wayland/weston-init.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-graphics/wayland/weston-init.bb
b/meta/recipes-graphics/wayland/weston-init.bb
index a7adce7fda8..b637fa6a4a5 100644
--- a/meta/recipes-graphics/wayland/weston-init.bb
+++ b/meta/recipes-graphics/wayland/weston-init.bb
@@ -94,5 +94,5 @@ CONFFILES:${PN} += "${sysconfdir}/xdg/weston/weston.ini
${sysconfdir}/default/we
SYSTEMD_SERVICE:${PN} = "weston.service weston.socket"
USERADD_PARAM:${PN} = "--home /home/weston --shell /bin/sh --user-group -G
video,input weston"
-GROUPADD_PARAM:${PN} = "-r wayland"
+GROUPADD_PARAM:${PN} = "-r wayland; -r render"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183342):
https://lists.openembedded.org/g/openembedded-core/message/183342
Mute This Topic: https://lists.openembedded.org/mt/99721738/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 3/4] cve-update-nvd2-native: handle all configuration nodes, not just first
On Fri, 23 Jun 2023, 08:32 , wrote: > From: Ross Burton > > Some CVEs, such as CVE-2013-6629, list multiple configurations which are > vulnerable. The current JSON parser only considers the first > configuration. > > Instead, consider every configuration. We don't yet handle the AND/OR > logical operators, but this is a step in the right direction. > > Signed-off-by: Ross Burton > --- > meta/recipes-core/meta/cve-update-nvd2-native.bb | 9 + > 1 file changed, 5 insertions(+), 4 deletions(-) > > diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb > b/meta/recipes-core/meta/cve-update-nvd2-native.bb > index 2b585983ac7..0c627ef2623 100644 > --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb > +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb > @@ -323,11 +323,12 @@ def update_db(conn, elt): > [cveId, cveDesc, cvssv2, cvssv3, date, > accessVector]).close() > > try: > -configurations = elt['cve']['configurations'][0]['nodes'] > -for config in configurations: > -parse_node_and_insert(conn, config, cveId) > +for config in elt['cve']['configurations']: > +# This is suboptimal as it doesn't handle AND/OR and negate, > but is better than nothing > +for node in config["nodes"]: > +parse_node_and_insert(conn, node, cveId) > except KeyError: > -bb.debug(2, "Entry without a configuration") > +bb.debug(2, "CVE %s has no configurations" % cveId) > > do_fetch[nostamp] = "1" > Looks good to me, thank you Ross. Regards, Marta > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183336): https://lists.openembedded.org/g/openembedded-core/message/183336 Mute This Topic: https://lists.openembedded.org/mt/99717256/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 3/3] bitbake.conf: add debug symbol for sdk
On Fri, 23 Jun 2023 at 17:42, Christian Eggers wrote: > In my project I have added BBCLASSEXTEND="nativesdk" to many bbappends in > order to have most > libraries I use on my target also for nativesdk (I can compile my embedded > application also > for nativesdk then). As debugging performance using gdbserver is quite poor > on my system, > developing my application with nativesdk is a welcome alternative (that's > why I also have > enabled debug information nativesdk). > > But from some previous comments on the OE list it seems that nativesdk is not > really intended > for this purpose. But what is the alternative? Having two SDKs? The intended way to debug an app is to actually run it in a target environment or in qemu system emulation. Yes this is more tricky to set up, but allowing native or nativesdk builds of the target stack for the sake of debugging is a can of worms I would not want to open. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183335): https://lists.openembedded.org/g/openembedded-core/message/183335 Mute This Topic: https://lists.openembedded.org/mt/99701056/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 3/3] bitbake.conf: add debug symbol for sdk
Hi Max,
I use the following lines in my local.conf file (on kirkstone). Maybe that this
is not
optimal as it may cause silent side effects in case the original values for
BUILDSDK_OPTIMIZATION/_CFLAGS/_CXXFALGS will change same day.
# Build -nativesdk packages with debug info (required for generating -dbg/-src
packages)
# BUILDSDK_OPTIMIZATION is based on BUILD_OPTIMIZATION in bitbake.conf
BUILDSDK_OPTIMIZATION = "${@oe.utils.vartrue('DEBUG_BUILD', '-Og', '-O2', d)}
-g -feliminate-unused-debug-types -pipe"
BUILDSDK_CFLAGS = "${BUILDSDK_CPPFLAGS} ${BUILDSDK_OPTIMIZATION}
${DEBUG_PREFIX_MAP}"
BUILDSDK_CXXFLAGS = "${BUILDSDK_CFLAGS}"
Additionally I have to manually select all available nativesdk-*-dbg/-src
packages in my
nativesdk-packagegroup-sdk-host.bbappend file. Unfortunately these packages are
not added
automatically to my SDK image (SDKIMAGE_FEATURES only applies for target
packages, not for
nativesdk packages). Maybe you'll find a better solution for that.
In my project I have added BBCLASSEXTEND="nativesdk" to many bbappends in order
to have most
libraries I use on my target also for nativesdk (I can compile my embedded
application also
for nativesdk then). As debugging performance using gdbserver is quite poor on
my system,
developing my application with nativesdk is a welcome alternative (that's why
I also have
enabled debug information nativesdk).
But from some previous comments on the OE list it seems that nativesdk is not
really intended
for this purpose. But what is the alternative? Having two SDKs?
regards
Christian
On Friday, 23 June 2023, 16:58:56 CEST, Maxime Roussin-Bélanger wrote:
> On Fri, Jun 23, 2023 at 3:50 AM Alexander Kanavin
> wrote:
> >
> > But then you can set the parameters as you want them in your local
> > configuration. Setting -g globally in the absence of DEBUG_BUILD needs
> > a use case that applies to most users.
> >
> > Alex
>
> If user wants to install nativesdk dgb/src package you need to add that flag,
> so instead of modifying the `BUILDSDK_CPPFLAGS`, it should probably be
> documented.
>
> Do you have any pointers where it could be documented?
>
> Max.
>
> >
> > On Thu, 22 Jun 2023 at 19:11, Maxime Roussin-Bélanger
> > wrote:
> > >
> > > Hi Alex,
> > >
> > > I don't want a complete debug build. I want to keep optimization and
> > > have the debug symbols. I don't think I can achieve that with
> > > DEBUG_BUILD.
> > >
> > > Max
> > >
> > > On Thu, Jun 22, 2023 at 12:30 PM Alexander Kanavin
> > > wrote:
> > > >
> > > > This change is unnecessary, as there is already a mechanism. Just
> > > > slightly further down you can see that BUILDSDK_CFLAGS pulls in
> > > > BUILD_OPTIMIZATION, which sets -g if you enable DEBUG_BUILD in your
> > > > config.
> > > >
> > > > Alex
> > > >
> > > > On Thu, 22 Jun 2023 at 18:20, Maxime Roussin-Bélanger
> > > > wrote:
> > > > >
> > > > > From: Maxime Roussin-Belanger
> > > > >
> > > > > Without adding debug flag nativesdk dbg package is not packaged since
> > > > > there is no debugging information
> > > > >
> > > > > Signed-off-by: Maxime Roussin-Belanger
> > > > >
> > > > > ---
> > > > > v2: New commit
> > > > >
> > > > > meta/conf/bitbake.conf | 2 +-
> > > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > > >
> > > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > > > index 9d9b268858..0635affbc1 100644
> > > > > --- a/meta/conf/bitbake.conf
> > > > > +++ b/meta/conf/bitbake.conf
> > > > > @@ -601,7 +601,7 @@ PATCHRESOLVE = "noop"
> > > > > ##
> > > > >
> > > > > export BUILD_CPPFLAGS = "-isystem${STAGING_INCDIR_NATIVE}"
> > > > > -BUILDSDK_CPPFLAGS = ""
> > > > > +BUILDSDK_CPPFLAGS ?= "-g"
> > > > > export CPPFLAGS = "${TARGET_CPPFLAGS}"
> > > > > TARGET_CPPFLAGS = ""
> > > > >
> > > > > --
> > > > > 2.36.0
> > > > >
> > > > >
> > > > >
> > > > >
>
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183334):
https://lists.openembedded.org/g/openembedded-core/message/183334
Mute This Topic: https://lists.openembedded.org/mt/99701056/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 2/3] insane: ignore nativesdk-${PN}-src host contaminated issue
On Fri, 23 Jun 2023 at 16:56, Maxime Roussin-Bélanger wrote: > When you mention `packages`, do you mean the .rpm, .deb, etc? > > What would be proper desired ownership inside those packages > for a nativesdk -src package? Is it suppose to be root? You can probably check how these packages get created in the first place? There will be explicit ownership set at that point. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#18): https://lists.openembedded.org/g/openembedded-core/message/18 Mute This Topic: https://lists.openembedded.org/mt/99701051/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 3/3] bitbake.conf: add debug symbol for sdk
On Fri, 23 Jun 2023 at 16:59, Maxime Roussin-Bélanger wrote: > If user wants to install nativesdk dgb/src package you need to add that flag, > so instead of modifying the `BUILDSDK_CPPFLAGS`, it should probably be > documented. > > Do you have any pointers where it could be documented? The Yocto SDK manual I suppose? Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183332): https://lists.openembedded.org/g/openembedded-core/message/183332 Mute This Topic: https://lists.openembedded.org/mt/99701056/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 3/3] bitbake.conf: add debug symbol for sdk
On Fri, Jun 23, 2023 at 3:50 AM Alexander Kanavin
wrote:
>
> But then you can set the parameters as you want them in your local
> configuration. Setting -g globally in the absence of DEBUG_BUILD needs
> a use case that applies to most users.
>
> Alex
If user wants to install nativesdk dgb/src package you need to add that flag,
so instead of modifying the `BUILDSDK_CPPFLAGS`, it should probably be
documented.
Do you have any pointers where it could be documented?
Max.
>
> On Thu, 22 Jun 2023 at 19:11, Maxime Roussin-Bélanger
> wrote:
> >
> > Hi Alex,
> >
> > I don't want a complete debug build. I want to keep optimization and
> > have the debug symbols. I don't think I can achieve that with
> > DEBUG_BUILD.
> >
> > Max
> >
> > On Thu, Jun 22, 2023 at 12:30 PM Alexander Kanavin
> > wrote:
> > >
> > > This change is unnecessary, as there is already a mechanism. Just
> > > slightly further down you can see that BUILDSDK_CFLAGS pulls in
> > > BUILD_OPTIMIZATION, which sets -g if you enable DEBUG_BUILD in your
> > > config.
> > >
> > > Alex
> > >
> > > On Thu, 22 Jun 2023 at 18:20, Maxime Roussin-Bélanger
> > > wrote:
> > > >
> > > > From: Maxime Roussin-Belanger
> > > >
> > > > Without adding debug flag nativesdk dbg package is not packaged since
> > > > there is no debugging information
> > > >
> > > > Signed-off-by: Maxime Roussin-Belanger
> > > >
> > > > ---
> > > > v2: New commit
> > > >
> > > > meta/conf/bitbake.conf | 2 +-
> > > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > > >
> > > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > > index 9d9b268858..0635affbc1 100644
> > > > --- a/meta/conf/bitbake.conf
> > > > +++ b/meta/conf/bitbake.conf
> > > > @@ -601,7 +601,7 @@ PATCHRESOLVE = "noop"
> > > > ##
> > > >
> > > > export BUILD_CPPFLAGS = "-isystem${STAGING_INCDIR_NATIVE}"
> > > > -BUILDSDK_CPPFLAGS = ""
> > > > +BUILDSDK_CPPFLAGS ?= "-g"
> > > > export CPPFLAGS = "${TARGET_CPPFLAGS}"
> > > > TARGET_CPPFLAGS = ""
> > > >
> > > > --
> > > > 2.36.0
> > > >
> > > >
> > > >
> > > >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183331):
https://lists.openembedded.org/g/openembedded-core/message/183331
Mute This Topic: https://lists.openembedded.org/mt/99701056/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 2/3] insane: ignore nativesdk-${PN}-src host contaminated issue
On Fri, Jun 23, 2023 at 3:53 AM Alexander Kanavin wrote: > > On Thu, 22 Jun 2023 at 20:04, Maxime Roussin-Bélanger > wrote: > > > I'm not sure I understand this. The check is to ensure build process > > > works as it should, specifically to prevent build host ownership > > > leaking into packages. Yes this information doesn't matter when these > > > packages are installed, but it matters for correctness of the build. > > > > > > Alex > > > > Maybe I don't get how this check is done because everything in the TMPDIR > > is owned by the user running bitbake. > > Installation and packaging tasks run under 'pseudo', an abstraction > that gives the tasks an illusion of running as root and setting file > ownership without restrictions. On build host's disk it's all owned by > bitbake user, but actual packages contain the desired ownership for > the target package installation. When you mention `packages`, do you mean the .rpm, .deb, etc? What would be proper desired ownership inside those packages for a nativesdk -src package? Is it suppose to be root? Max. > > Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183330): https://lists.openembedded.org/g/openembedded-core/message/183330 Mute This Topic: https://lists.openembedded.org/mt/99701051/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/4] cve-update-db-native: remove
From: Ross Burton
The replacement cve-update-nvd2-native is working, so we can remove the
old recipe now.
Signed-off-by: Ross Burton
---
meta/conf/distro/include/maintainers.inc | 1 -
meta/lib/oeqa/selftest/cases/distrodata.py| 2 +-
.../recipes-core/meta/cve-update-db-native.bb | 288 --
3 files changed, 1 insertion(+), 290 deletions(-)
delete mode 100644 meta/recipes-core/meta/cve-update-db-native.bb
diff --git a/meta/conf/distro/include/maintainers.inc
b/meta/conf/distro/include/maintainers.inc
index 9bb5c5205c2..e27295a7cf5 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -127,7 +127,6 @@ RECIPE_MAINTAINER:pn-cryptodev-module = "Robert Yang
RECIPE_MAINTAINER:pn-cryptodev-tests = "Robert Yang
"
RECIPE_MAINTAINER:pn-cups = "Chen Qi "
RECIPE_MAINTAINER:pn-curl = "Robert Joslyn "
-RECIPE_MAINTAINER:pn-cve-update-db-native = "Ross Burton "
RECIPE_MAINTAINER:pn-cve-update-nvd2-native = "Ross Burton
"
RECIPE_MAINTAINER:pn-cwautomacros = "Ross Burton "
RECIPE_MAINTAINER:pn-db = "Unassigned "
diff --git a/meta/lib/oeqa/selftest/cases/distrodata.py
b/meta/lib/oeqa/selftest/cases/distrodata.py
index c83a3a7bd67..111bd3c9beb 100644
--- a/meta/lib/oeqa/selftest/cases/distrodata.py
+++ b/meta/lib/oeqa/selftest/cases/distrodata.py
@@ -92,7 +92,7 @@ The following recipes do not have a DESCRIPTION. Please add
an entry for DESCRIP
def is_maintainer_exception(entry):
exceptions = ["musl", "newlib", "linux-yocto", "linux-dummy",
"mesa-gl", "libgfortran", "libx11-compose-data",
- "cve-update-db-native","cve-update-nvd2-native",]
+ "cve-update-nvd2-native",]
for i in exceptions:
if i in entry:
return True
diff --git a/meta/recipes-core/meta/cve-update-db-native.bb
b/meta/recipes-core/meta/cve-update-db-native.bb
deleted file mode 100644
index 079f062f79b..000
--- a/meta/recipes-core/meta/cve-update-db-native.bb
+++ /dev/null
@@ -1,288 +0,0 @@
-SUMMARY = "Updates the NVD CVE database"
-LICENSE = "MIT"
-
-INHIBIT_DEFAULT_DEPS = "1"
-
-inherit native
-
-deltask do_unpack
-deltask do_patch
-deltask do_configure
-deltask do_compile
-deltask do_install
-deltask do_populate_sysroot
-
-NVDCVE_URL ?= "https://nvd.nist.gov/feeds/json/cve/1.1/nvdcve-1.1-;
-# CVE database update interval, in seconds. By default: once a day (24*60*60).
-# Use 0 to force the update
-# Use a negative value to skip the update
-CVE_DB_UPDATE_INTERVAL ?= "86400"
-
-# Timeout for blocking socket operations, such as the connection attempt.
-CVE_SOCKET_TIMEOUT ?= "60"
-
-CVE_DB_TEMP_FILE ?= "${CVE_CHECK_DB_DIR}/temp_nvdcve_1.1.db"
-
-python () {
-if not bb.data.inherits_class("cve-check", d):
-raise bb.parse.SkipRecipe("Skip recipe when cve-check class is not
loaded.")
-}
-
-python do_fetch() {
-"""
-Update NVD database with json data feed
-"""
-import bb.utils
-import bb.progress
-import shutil
-
-bb.utils.export_proxies(d)
-
-db_file = d.getVar("CVE_CHECK_DB_FILE")
-db_dir = os.path.dirname(db_file)
-db_tmp_file = d.getVar("CVE_DB_TEMP_FILE")
-
-cleanup_db_download(db_file, db_tmp_file)
-
-# The NVD database changes once a day, so no need to update more frequently
-# Allow the user to force-update
-try:
-import time
-update_interval = int(d.getVar("CVE_DB_UPDATE_INTERVAL"))
-if update_interval < 0:
-bb.note("CVE database update skipped")
-return
-if time.time() - os.path.getmtime(db_file) < update_interval:
-bb.debug(2, "Recently updated, skipping")
-return
-
-except OSError:
-pass
-
-bb.utils.mkdirhier(db_dir)
-if os.path.exists(db_file):
-shutil.copy2(db_file, db_tmp_file)
-
-if update_db_file(db_tmp_file, d) == True:
-# Update downloaded correctly, can swap files
-shutil.move(db_tmp_file, db_file)
-else:
-# Update failed, do not modify the database
-bb.note("CVE database update failed")
-os.remove(db_tmp_file)
-}
-
-do_fetch[lockfiles] += "${CVE_CHECK_DB_FILE_LOCK}"
-do_fetch[file-checksums] = ""
-do_fetch[vardeps] = ""
-
-def cleanup_db_download(db_file, db_tmp_file):
-"""
-Cleanup the download space from possible failed downloads
-"""
-
-# Clean up the updates done on the main file
-# Remove it only if a journal file exists - it means a complete re-download
-if os.path.exists("{0}-journal".format(db_file)):
-# If a journal is present the last update might have been interrupted.
In that case,
-# just wipe any leftovers and force the DB to be recreated.
-os.remove("{0}-journal".format(db_file))
-
-if os.path.exists(db_file):
-os.remove(db_file)
-
-# Clean-up the temporary file downloads, we can remove both journal
-# and
[OE-core] [PATCH 2/4] ghostscript: remove CVE_CHECK_IGNORE for CVE-2013-6629
From: Ross Burton
This CVE now has a version range, indicating that this Ghostscript
release isn't vulnerable.
Signed-off-by: Ross Burton
---
meta/recipes-extended/ghostscript/ghostscript_10.01.1.bb | 3 ---
1 file changed, 3 deletions(-)
diff --git a/meta/recipes-extended/ghostscript/ghostscript_10.01.1.bb
b/meta/recipes-extended/ghostscript/ghostscript_10.01.1.bb
index f03ebf44789..0d41242bc2c 100644
--- a/meta/recipes-extended/ghostscript/ghostscript_10.01.1.bb
+++ b/meta/recipes-extended/ghostscript/ghostscript_10.01.1.bb
@@ -18,9 +18,6 @@ DEPENDS = "tiff jpeg fontconfig cups libpng freetype zlib"
UPSTREAM_CHECK_URI =
"https://github.com/ArtifexSoftware/ghostpdl-downloads/releases;
UPSTREAM_CHECK_REGEX = "(?P\d+(\.\d+)+)\.tar"
-# We use a system libjpeg-turbo which has this fix
-CVE_CHECK_IGNORE += "CVE-2013-6629"
-
def gs_verdir(v):
return "".join(v.split("."))
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183326):
https://lists.openembedded.org/g/openembedded-core/message/183326
Mute This Topic: https://lists.openembedded.org/mt/99717253/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 4/4] cve-update-nvd2-native: use exact times, don't truncate
From: Ross Burton When requesting updates in a specific range, use the actual current time and database mtime instead of truncating to midnight, and explicitly set the timezone to UTC so that NIST don't treat the timestamps as _their_ local time when they're _our_ local time. Signed-off-by: Ross Burton --- meta/recipes-core/meta/cve-update-nvd2-native.bb | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb index 0c627ef2623..61f4d47f961 100644 --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb @@ -172,8 +172,8 @@ def update_db_file(db_tmp_file, d, database_time): # The maximum range for time is 120 days # Force a complete update if our range is longer if (database_time != 0): -database_date = datetime.datetime.combine(datetime.date.fromtimestamp(database_time), datetime.time()) -today_date = datetime.datetime.combine(datetime.date.today(), datetime.time()) +database_date = datetime.datetime.fromtimestamp(database_time, tz=datetime.timezone.utc) +today_date = datetime.datetime.now(tz=datetime.timezone.utc) delta = today_date - database_date if delta.days < 120: bb.debug(2, "CVE database: performing partial update") -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183329): https://lists.openembedded.org/g/openembedded-core/message/183329 Mute This Topic: https://lists.openembedded.org/mt/99717257/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 3/4] cve-update-nvd2-native: handle all configuration nodes, not just first
From: Ross Burton Some CVEs, such as CVE-2013-6629, list multiple configurations which are vulnerable. The current JSON parser only considers the first configuration. Instead, consider every configuration. We don't yet handle the AND/OR logical operators, but this is a step in the right direction. Signed-off-by: Ross Burton --- meta/recipes-core/meta/cve-update-nvd2-native.bb | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/meta/recipes-core/meta/cve-update-nvd2-native.bb b/meta/recipes-core/meta/cve-update-nvd2-native.bb index 2b585983ac7..0c627ef2623 100644 --- a/meta/recipes-core/meta/cve-update-nvd2-native.bb +++ b/meta/recipes-core/meta/cve-update-nvd2-native.bb @@ -323,11 +323,12 @@ def update_db(conn, elt): [cveId, cveDesc, cvssv2, cvssv3, date, accessVector]).close() try: -configurations = elt['cve']['configurations'][0]['nodes'] -for config in configurations: -parse_node_and_insert(conn, config, cveId) +for config in elt['cve']['configurations']: +# This is suboptimal as it doesn't handle AND/OR and negate, but is better than nothing +for node in config["nodes"]: +parse_node_and_insert(conn, node, cveId) except KeyError: -bb.debug(2, "Entry without a configuration") +bb.debug(2, "CVE %s has no configurations" % cveId) do_fetch[nostamp] = "1" -- 2.34.1 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183328): https://lists.openembedded.org/g/openembedded-core/message/183328 Mute This Topic: https://lists.openembedded.org/mt/99717256/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 v8 1/3] cve-check: add option to add additional patched CVEs
On Fri, 2023-06-23 at 10:02 +, Ross Burton wrote:
> On 22 Jun 2023, at 13:00, Andrej Valek via lists.openembedded.org
> wrote:
> > - Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
> > The CVE_STATUS should contain an information about status wich
> > is decoded in 3 items:
> > - generic status: "Ignored", "Patched" or "Unpatched"
> > - more detailed status enum
> > - description: free text describing reason for status
>
> I think this needs to be clearer about what the intended use of the keywords
> are.
>
> Is the canonical data the CVE_STATUS[CVE-1234-5678] attribute, and the mapping
> from the status there via CVE_CHECK_STATUSMAP simply for backwards
> compatibility with the existing file format? Is this deprecating the status
> fields in those files or is it just a high-level summary? Either way, that
> should be made clear.
>
Yes, it's for backport compatibility, and extending the existing "Ignored",
"Patched" statuses with reasons.
> > +# Possible options for CVE statuses
> > +
> > +# used by this class internally when fix is detected (NVD DB version check
> > or CVE patch file)
> > +CVE_CHECK_STATUSMAP[patched] = "Patched"
> > +# use when this class does not detect backported patch (e.g. vendor kernel
> > repo with cherry-picked CVE patch)
> > +CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
> > +# use when NVD DB does not mention patched versions of stable/LTS branches
> > which have upstream CVE backports
> > +CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
> > +# use when NVD DB does not mention correct version or does not mention any
> > verion at all
> > +CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
>
> It bothers me that some of these status flags are working around the fact that
> the CPE is incorrect, when that CPE data can be fixed. Instead of setting
> fixed-version, we can just mail NIST and fix the CPE.
>
Yes, but while you're sending it, the current status has to be covered. And you
don't know, if the CPE will be fixed or not.
> > +# used internally by this class if CVE vulnerability is detected which is
> > not marked as fixed or ignored
> > +CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
> > +# use when CVE is confirmed by upstream but fix is still not available
> > +CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
> > +
> > +# used for migration from old concept, do not use for new vulnerabilities
> > +CVE_CHECK_STATUSMAP[ignored] = "Ignored"
> > +# use when NVD DB wrongly indicates vulnerability which is actually for a
> > different component
> > +CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
> > +# use when upstream does not accept the report as a vulnerability (e.g.
> > works as designed)
> > +CVE_CHECK_STATUSMAP[disputed] = "Ignored"
> > +# use when vulnerability depends on build or runtime configuration which is
> > not used
> > +CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
> > +# use when vulnerability affects other platform (e.g. Windows or Debian)
> > +CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
>
> > +# use when upstream acknowledged the vulnerability but does not plan to fix
> > it
> > +CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
>
> Is this any different to ‘disputed’?
>
Of course. In the "upstream-wontfix" status, we know, that it won't be fixed.
But for "disputed" you don't know, if it's a bug or not.
> Do we expect to add a lot more statuses to this table, or for users to add
> their own values? It feels like maybe this should be a dict in
> lib/oe/cve_check.py instead of exposed in the data store.
>
Exactly, know I moved it separated file, where users could extend their own
statuses. The current version is just a "basement" of supported one.
> > + # Process CVE_STATUS_GROUPS to set multiple statuses and optional
> > detail or description at once
> > + for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
> > + cve_group = d.getVar(cve_status_group)
> > + if cve_group is not None:
> > + for cve in cve_group.split():
> > + d.setVarFlag("CVE_STATUS", cve,
> > d.getVarFlag(cve_status_group, "status"))
> > + else:
> > + bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
> > cve_status_group)
> > +}
>
> CVE_STATUS_GROUPS isn’t documented in the class or the commit message.
>
Added a description directly into class.
>
Regards,
Andrej
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183325):
https://lists.openembedded.org/g/openembedded-core/message/183325
Mute This Topic: https://lists.openembedded.org/mt/99695984/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 v9 2/3] oeqa/selftest/cve_check: rework test to new cve status handling
From: Andrej Valek
- After introducing the CVE_STATUS and CVE_CHECK_STATUSMAP flag
variables, CVEs could contain a more information for assigned statuses.
- Add an example conversion in logrotate recipe.
Signed-off-by: Andrej Valek
---
meta/lib/oeqa/selftest/cases/cve_check.py | 26 +++
.../logrotate/logrotate_3.21.0.bb | 5 ++--
2 files changed, 24 insertions(+), 7 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/cve_check.py
b/meta/lib/oeqa/selftest/cases/cve_check.py
index 9534c9775c..60cecd1328 100644
--- a/meta/lib/oeqa/selftest/cases/cve_check.py
+++ b/meta/lib/oeqa/selftest/cases/cve_check.py
@@ -207,18 +207,34 @@ CVE_CHECK_REPORT_PATCHED = "1"
self.assertEqual(len(report["package"]), 1)
package = report["package"][0]
self.assertEqual(package["name"], "logrotate")
-found_cves = { issue["id"]: issue["status"] for issue in
package["issue"]}
+found_cves = {}
+for issue in package["issue"]:
+found_cves[issue["id"]] = {
+"status" : issue["status"],
+"detail" : issue["detail"] if "detail" in issue else "",
+"description" : issue["description"] if "description" in
issue else ""
+}
# m4 CVE should not be in logrotate
self.assertNotIn("CVE-2008-1687", found_cves)
# logrotate has both Patched and Ignored CVEs
self.assertIn("CVE-2011-1098", found_cves)
-self.assertEqual(found_cves["CVE-2011-1098"], "Patched")
+self.assertEqual(found_cves["CVE-2011-1098"]["status"], "Patched")
+self.assertEqual(len(found_cves["CVE-2011-1098"]["detail"]), 0)
+self.assertEqual(len(found_cves["CVE-2011-1098"]["description"]),
0)
+detail = "not-applicable-platform"
+description = "CVE is debian, gentoo or SUSE specific on the way
logrotate was installed/used"
self.assertIn("CVE-2011-1548", found_cves)
-self.assertEqual(found_cves["CVE-2011-1548"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1548"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1548"]["description"],
description)
self.assertIn("CVE-2011-1549", found_cves)
-self.assertEqual(found_cves["CVE-2011-1549"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1549"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1549"]["description"],
description)
self.assertIn("CVE-2011-1550", found_cves)
-self.assertEqual(found_cves["CVE-2011-1550"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["status"], "Ignored")
+self.assertEqual(found_cves["CVE-2011-1550"]["detail"], detail)
+self.assertEqual(found_cves["CVE-2011-1550"]["description"],
description)
self.assertExists(summary_json)
check_m4_json(summary_json)
diff --git a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
index 87c0d9ae60..b83f39b129 100644
--- a/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
+++ b/meta/recipes-extended/logrotate/logrotate_3.21.0.bb
@@ -16,8 +16,9 @@ SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BP}.tar.xz \
SRC_URI[sha256sum] =
"8fa12015e3b8415c121fc9c0ca53aa872f7b0702f543afda7e32b6c4900f6516"
-# These CVEs are debian, gentoo or SUSE specific on the way logrotate was
installed/used
-CVE_CHECK_IGNORE += "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_GROUPS = "CVE_STATUS_RECIPE"
+CVE_STATUS_RECIPE = "CVE-2011-1548 CVE-2011-1549 CVE-2011-1550"
+CVE_STATUS_RECIPE[status] = "not-applicable-platform: CVE is debian, gentoo or
SUSE specific on the way logrotate was installed/used"
PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 'acl selinux', d)}"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183323):
https://lists.openembedded.org/g/openembedded-core/message/183323
Mute This Topic: https://lists.openembedded.org/mt/99716040/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 v9 0/3] CVE-check handling
After discussion in all parallel threads we proposed following variant which covers both expressed requirements to have very small number of different cve statuses and also very large number of them at the same time. This is a compromise version which maybe is not ideal but deals with conflicting responses we got. Changes compared to version 8: - moved CVE_CHECK_STATUSMAP into separated cve-check-map.conf file - this will allow to use it without inheriting the cve-check class, like for SPDX Documentation will be updated in separated repository. meta/classes/cve-check.bbclass| 81 +++- meta/conf/bitbake.conf| 1 + meta/conf/cve-check-map.conf | 28 ++ .../distro/include/cve-extra-exclusions.inc | 371 +- meta/lib/oe/cve_check.py | 25 ++ meta/lib/oeqa/selftest/cases/cve_check.py | 26 +- meta/recipes-bsp/grub/grub2.inc | 6 +- meta/recipes-connectivity/avahi/avahi_0.8.bb | 3 +- .../recipes-connectivity/bind/bind_9.18.15.bb | 2 +- .../bluez5/bluez5_5.66.bb | 4 +- .../openssh/openssh_9.3p1.bb | 9 +- .../openssl/openssl_3.1.1.bb | 3 +- meta/recipes-core/coreutils/coreutils_9.3.bb | 4 +- meta/recipes-core/glibc/glibc_2.37.bb | 17 +- meta/recipes-core/libxml/libxml2_2.10.4.bb| 4 - meta/recipes-core/systemd/systemd_253.3.bb| 3 - meta/recipes-devtools/cmake/cmake.inc | 4 +- meta/recipes-devtools/flex/flex_2.6.4.bb | 6 +- meta/recipes-devtools/gcc/gcc-13.1.inc| 3 +- meta/recipes-devtools/git/git_2.39.3.bb | 7 - meta/recipes-devtools/jquery/jquery_3.6.3.bb | 5 +- meta/recipes-devtools/ninja/ninja_1.11.1.bb | 3 +- .../recipes-devtools/python/python3_3.11.3.bb | 13 +- meta/recipes-devtools/qemu/qemu.inc | 13 +- meta/recipes-devtools/rsync/rsync_3.2.7.bb| 3 - meta/recipes-devtools/tcltk/tcl_8.6.13.bb | 4 - meta/recipes-extended/cpio/cpio_2.14.bb | 3 +- meta/recipes-extended/cups/cups.inc | 17 +- .../ghostscript/ghostscript_10.01.1.bb| 3 +- .../iputils/iputils_20221126.bb | 5 +- .../libtirpc/libtirpc_1.3.3.bb| 3 +- .../logrotate/logrotate_3.21.0.bb | 5 +- meta/recipes-extended/procps/procps_4.0.3.bb | 4 - meta/recipes-extended/shadow/shadow_4.13.bb | 7 +- meta/recipes-extended/unzip/unzip_6.0.bb | 3 +- .../xinetd/xinetd_2.3.15.4.bb | 2 +- meta/recipes-extended/zip/zip_3.0.bb | 7 +- .../libnotify/libnotify_0.8.2.bb | 2 +- meta/recipes-gnome/librsvg/librsvg_2.56.0.bb | 3 +- meta/recipes-graphics/builder/builder_0.1.bb | 3 +- .../xorg-xserver/xserver-xorg.inc | 19 +- .../linux/cve-exclusion_6.1.inc | 11 +- .../libpng/libpng_1.6.39.bb | 3 +- meta/recipes-multimedia/libtiff/tiff_4.5.0.bb | 10 +- .../libgcrypt/libgcrypt_1.10.2.bb | 4 +- .../recipes-support/libxslt/libxslt_1.1.38.bb | 4 +- meta/recipes-support/lz4/lz4_1.9.4.bb | 3 +- meta/recipes-support/sqlite/sqlite3_3.41.2.bb | 7 - 48 files changed, 403 insertions(+), 373 deletions(-) create mode 100644 meta/conf/cve-check-map.conf -- 2.41.0 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183321): https://lists.openembedded.org/g/openembedded-core/message/183321 Mute This Topic: https://lists.openembedded.org/mt/99716038/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 v9 1/3] cve-check: add option to add additional patched CVEs
From: Andrej Valek
- Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
The CVE_STATUS should contain an information about status wich
is decoded in 3 items:
- generic status: "Ignored", "Patched" or "Unpatched"
- more detailed status enum
- description: free text describing reason for status
Examples of usage:
CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
Signed-off-by: Andrej Valek
Signed-off-by: Peter Marko
---
meta/classes/cve-check.bbclass | 81 --
meta/conf/bitbake.conf | 1 +
meta/conf/cve-check-map.conf | 28
meta/lib/oe/cve_check.py | 25 +++
4 files changed, 122 insertions(+), 13 deletions(-)
create mode 100644 meta/conf/cve-check-map.conf
diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index bd9e7e7445..55e3baf1ed 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -70,12 +70,28 @@ CVE_CHECK_COVERAGE ??= "1"
# Skip CVE Check for packages (PN)
CVE_CHECK_SKIP_RECIPE ?= ""
-# Ingore the check for a given list of CVEs. If a CVE is found,
-# then it is considered patched. The value is a string containing
-# space separated CVE values:
+# Replace NVD DB check status for a given CVE. Each of CVE has to be mentioned
+# separately with optional detail and description for this status.
#
-# CVE_CHECK_IGNORE = 'CVE-2014-2524 CVE-2018-1234'
+# CVE_STATUS[CVE-1234-0001] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS[CVE-1234-0002] = "fixed-version: Fixed externally"
#
+# Settings the same status and reason for multiple CVEs is possible
+# via CVE_STATUS_GROUPS variable.
+#
+# CVE_STATUS_GROUPS = "CVE_STATUS_WIN CVE_STATUS_PATCHED"
+#
+# CVE_STATUS_WIN = "CVE-1234-0001 CVE-1234-0003"
+# CVE_STATUS_WIN[status] = "not-applicable-platform: Issue only applies on
Windows"
+# CVE_STATUS_PATCHED = "CVE-1234-0002 CVE-1234-0004"
+# CVE_STATUS_PATCHED[status] = "fixed-version: Fixed externally"
+#
+# All possible CVE statuses could be found in cve-check-map.conf
+# CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
+# CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
+#
+# CVE_CHECK_IGNORE is deprecated and CVE_STATUS has to be used instead.
+# Keep CVE_CHECK_IGNORE until other layers migrate to new variables
CVE_CHECK_IGNORE ?= ""
# Layers to be excluded
@@ -88,6 +104,24 @@ CVE_CHECK_LAYER_INCLUDELIST ??= ""
# set to "alphabetical" for version using single alphabetical character as
increment release
CVE_VERSION_SUFFIX ??= ""
+python () {
+# Fallback all CVEs from CVE_CHECK_IGNORE to CVE_STATUS
+cve_check_ignore = d.getVar("CVE_CHECK_IGNORE")
+if cve_check_ignore:
+bb.warn("CVE_CHECK_IGNORE is deprecated in favor of CVE_STATUS")
+for cve in (d.getVar("CVE_CHECK_IGNORE") or "").split():
+d.setVarFlag("CVE_STATUS", cve, "ignored")
+
+# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
or description at once
+for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
+cve_group = d.getVar(cve_status_group)
+if cve_group is not None:
+for cve in cve_group.split():
+d.setVarFlag("CVE_STATUS", cve, d.getVarFlag(cve_status_group,
"status"))
+else:
+bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
cve_status_group)
+}
+
def generate_json_report(d, out_path, link_path):
if os.path.exists(d.getVar("CVE_CHECK_SUMMARY_INDEX_PATH")):
import json
@@ -260,7 +294,7 @@ def check_cves(d, patched_cves):
"""
Connect to the NVD database and find unpatched cves.
"""
-from oe.cve_check import Version, convert_cve_version
+from oe.cve_check import Version, convert_cve_version, decode_cve_status
pn = d.getVar("PN")
real_pv = d.getVar("PV")
@@ -282,7 +316,12 @@ def check_cves(d, patched_cves):
bb.note("Recipe has been skipped by cve-check")
return ([], [], [], [])
-cve_ignore = d.getVar("CVE_CHECK_IGNORE").split()
+# Convert CVE_STATUS into ignored CVEs and check validity
+cve_ignore = []
+for cve in (d.getVarFlags("CVE_STATUS") or {}):
+decoded_status, _, _ = decode_cve_status(d, cve)
+if decoded_status == "Ignored":
+cve_ignore.append(cve)
import sqlite3
db_file = d.expand("file:${CVE_CHECK_DB_FILE}?mode=ro")
@@ -413,6 +452,8 @@ def cve_write_data_text(d, patched, unpatched, ignored,
cve_data):
CVE manifest if enabled.
"""
+from oe.cve_check import decode_cve_status
+
cve_file = d.getVar("CVE_CHECK_LOG")
fdir_name = d.getVar("FILE_DIRNAME")
layer = fdir_name.split("/")[-3]
@@ -441,20 +482,27 @@ def cve_write_data_text(d, patched,
Re: [OE-core] [PATCH] kernel.bbclass: hoist up "unset S" bbfatal from kernel-yocto.bbclass to kernel.bbclass
Hi Luca,
On Mon, 2023-06-05 at 16:13 +0200, Luca Ceresoli via lists.openembedded.org
wrote:
> From: Luca Ceresoli
>
> Writing a simple recipe that inherits kernel.bbclass and downloads a kernel
> tarball (e.g. a mainline release from kernel.org) via http or ftp fails
> with either:
>
> ERROR: linux-acme-6.3.3-r0 do_configure: oe_runmake failed
> ...
> | make: *** No rule to make target 'oldnoconfig'. Stop.
>
> or (seen on a different setup, based on kirkstone):
>
> ... do_populate_lic: QA Issue: ... LIC_FILES_CHKSUM points to an invalid
> file: .../work-shared/.../kernel-source/COPYING [license-checksum]
>
> This happens when not setting S in the recipe. In this case, kernel.bbclass
> sets it to ${STAGING_KERNEL_DIR}
> (${TMPDIR}/work-shared/${MACHINE}/kernel-source). This means that in
> do_symlink_kernsrc(), the 'if s != kernsrc' never triggers and thus the
> kernel tree will not me moved into work/shared, which results in an empty
> work-shared/.../kernel-source directory.
>
> When downloading a tarball it is usually not required to set S in recipes,
> so this is not obvious here and the error message does not point to the
> problem or its solution.
>
> There is such a check in kernel-yocto.bbclass though, so move it to
> kernel.bbclass so that also kernel recipes not based on kernel-yocto can
> benefit from it.
>
> The check is moved:
>
> - from the beginning of do_kernel_checkout() in kernel-yocto
> - to the end of do_symlink_kernsrc() in kernel.bbclass
>
> and since do_kernel_checkout is executed 'after do_symlink_kernsrc', the
> code flow does not change in a relevant way when using linux-yocto.
>
> Signed-off-by: Luca Ceresoli
> ---
> meta/classes-recipe/kernel-yocto.bbclass | 8
> meta/classes-recipe/kernel.bbclass | 6 ++
> 2 files changed, 6 insertions(+), 8 deletions(-)
>
> diff --git a/meta/classes-recipe/kernel-yocto.bbclass
> b/meta/classes-recipe/kernel-yocto.bbclass
> index 108b7e675212..ceb451b69969 100644
> --- a/meta/classes-recipe/kernel-yocto.bbclass
> +++ b/meta/classes-recipe/kernel-yocto.bbclass
> @@ -394,16 +394,8 @@ do_kernel_checkout() {
> # case: we have no git repository at all.
> # To support low bandwidth options for building the kernel,
> we'll just
> # convert the tree to a git repo and let the rest of the
> process work unchanged
> -
> - # if ${S} hasn't been set to the proper subdirectory a default
> of "linux" is
> - # used, but we can't initialize that empty directory. So check
> it and throw a
> - # clear error
>
> cd ${S}
> - if [ ! -f "Makefile" ]; then
> - bberror "S is not set to the linux source directory.
> Check "
> - bbfatal "the recipe and set S to the proper extracted
> subdirectory"
> - fi
> rm -f .gitignore
> git init
> check_git_config
> diff --git a/meta/classes-recipe/kernel.bbclass
> b/meta/classes-recipe/kernel.bbclass
> index 9c8036f4df01..5ed4a2e03c72 100644
> --- a/meta/classes-recipe/kernel.bbclass
> +++ b/meta/classes-recipe/kernel.bbclass
> @@ -195,6 +195,12 @@ python do_symlink_kernsrc () {
> import shutil
> shutil.move(s, kernsrc)
> os.symlink(kernsrc, s)
> +
> +# When not using git, we cannot figure out automatically the extracted
> +# directory. So check it and throw a clear error.
> +if not os.path.isdir(os.path.join(d.getVar("WORKDIR"), "git")) and \
> + not os.path.exists(os.path.join(s, "Makefile")):
> +bb.fatal("S is not set to the linux source directory. Check the
> recipe and set S to the proper extracted subdirectory.")
> }
> # do_patch is normally ordered before do_configure, but
> # externalsrc.bbclass deletes do_patch, breaking the dependency of
Sorry this has taken a bit of time to get to.
We can't check for "git" as the workdir directory in this test as it
can be overridden in the fetcher. We'll need to find some other better
approach. Can't we just use ${S}/Makefile ?
Please also copy Bruce on these changes going forward.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183320):
https://lists.openembedded.org/g/openembedded-core/message/183320
Mute This Topic: https://lists.openembedded.org/mt/99341197/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 0/3] wayland/weston upgrades
Hello Eilís, On Fri, 23 Jun 2023 11:21:29 +0100 Eilís 'pidge' Ní Fhlannagáin wrote: > On 23/06/2023 09:46, Luca Ceresoli wrote: > > Hello Eilís, > > > > On Thu, 22 Jun 2023 15:42:14 +0100 > > Eilís 'pidge' Ní Fhlannagáin wrote: > > > >> Nothing really surprising here, except we should note that launcher-logind > >> is > >> being depreciated so some thought on how that is dealt with will need to > >> occur > > > > Should we file a bug in bugzilla to avoid forgetting about this? > > Yes, I'll assign it to myself. Alex had suggested we just require seatd > which to me makes the most sense. OK, so it I guess you should add it as soon as a future version of this series is accepted, unless you have managed to handle this properly by then. Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183319): https://lists.openembedded.org/g/openembedded-core/message/183319 Mute This Topic: https://lists.openembedded.org/mt/99702158/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] uninative: call patchelf-uninative only when needed
On Fri, 2023-06-23 at 11:33 +0200, Martin Jansa wrote:
> mke2fs.real, mkfs.ext2.real, mkfs.ext3.real, mkfs.ext4.real are indentical
> binary with multiple hardlinks and we end calling patchelf-uninative 4
> times even when the interpreter is already set correctly from the build
>
> To avoid corrupted binaries created by patchelf-0.18.0 when set-interpreter
> is called multiple times (on some systems like ubuntu-18.04 this leads to
> segfaults elsewhere just ldd complains that the executable is no longer
> dynamically linked, but doesn't fail when executed).
>
> The issue was reported upstream with mkfs.ext4.real as possible reproducer:
> https://github.com/NixOS/patchelf/issues/492#issuecomment-1602862272
> alternatively we can revert
> https://github.com/NixOS/patchelf/commit/65cdee904431d16668f95d816a495bc35a05a192
> and create new uninative release with update patchelf-uninative, but
> better to wait a bit for upstream to have a look and possibly backport
> proper fix later, until then this change fixes the mkfs.ext4 issues I was
> seeing in kirkstone, mickledore, nanbield since uninative-3.9 upgrade, as
> reported in:
> https://lists.openembedded.org/g/openembedded-core/message/182862
>
> Signed-off-by: Martin Jansa
> ---
> meta/classes-global/uninative.bbclass | 11 ---
> 1 file changed, 8 insertions(+), 3 deletions(-)
>
> diff --git a/meta/classes-global/uninative.bbclass
> b/meta/classes-global/uninative.bbclass
> index 366f7ac793..b54acdd542 100644
> --- a/meta/classes-global/uninative.bbclass
> +++ b/meta/classes-global/uninative.bbclass
> @@ -175,7 +175,12 @@ python uninative_changeinterp () {
> if not elf.isDynamic():
> continue
>
> -os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
> -subprocess.check_output(("patchelf-uninative",
> "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f),
> stderr=subprocess.STDOUT)
> -os.chmod(f, s[stat.ST_MODE])
> +current = subprocess.check_output(("patchelf-uninative",
> "--print-interpreter", f),
> stderr=subprocess.STDOUT).decode('utf-8').split('\n')[0]
> +if current != d.getVar("UNINATIVE_LOADER"):
> +bb.debug(2, "Changing interpreter from %s to %s with %s" %
> (current, d.getVar("UNINATIVE_LOADER"), ("patchelf-uninative",
> "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f)))
> +os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
> +subprocess.check_output(("patchelf-uninative",
> "--set-interpreter", d.getVar("UNINATIVE_LOADER"), f),
> stderr=subprocess.STDOUT)
> +os.chmod(f, s[stat.ST_MODE])
> +else:
> +bb.debug(2, "Interpreter was already set to %s in %s" %
> (d.getVar("UNINATIVE_LOADER"), f))
> }
I know why you've done it this way but ideally we should make patchelf
handle this internally? It would be nice to avoid fork calls if we can
in the long run.
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183318):
https://lists.openembedded.org/g/openembedded-core/message/183318
Mute This Topic: https://lists.openembedded.org/mt/99715032/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 2/3] weston: Upgrade 11.0.1 -> 12.0.1
Hello Eilís,
On Thu, 22 Jun 2023 15:42:16 +0100
Eilís 'pidge' Ní Fhlannagáin wrote:
> Tracking https://gitlab.freedesktop.org/wayland/weston/-/issues/488
> we're keeping -Ddeprecated-launcher-logind but plans should be made to
> remove this/work around.
>
> We also need to add xcb-util-cursor from meta-openembedded as this is
> now required for ptest. When this is pulled we can remove from meta-oe.
>
> Signed-off-by: Eilís 'pidge' Ní Fhlannagáin
> ---
> .../wayland/{weston_11.0.1.bb => weston_12.0.1.bb}| 11 ---
> .../xorg-lib/xcb-util-cursor_0.1.4.bb | 10 ++
This is triggering failures on no-x11 builds:
stdio: ERROR: Nothing PROVIDES 'xcb-util' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
DEPENDS on or otherwise requires it)
stdio: ERROR: Nothing PROVIDES 'xcb-util-cursor' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
DEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-init' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb,
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-dev' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston_12.0.1.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-init-dev' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/wayland/weston-init.bb
RDEPENDS on or otherwise requires it)
stdio: ERROR: Nothing RPROVIDES 'weston-examples' (but
/home/pokybuild/yocto-worker/no-x11/build/meta/recipes-graphics/packagegroups/packagegroup-core-weston.bb
RDEPENDS on or otherwise requires it)
Full logs:
https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/7354/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/7354/steps/15/logs/stdio
Patch "weston: Cleanup and fix x11 and xwayland dependencies"
(https://lore.kernel.org/openembedded-core/20230622203913.183451-1-tom.hochst...@nxp.com/T/#u)
was sent a few hours after yours by Tom (in Cc:). Do think it could fix
this error? FYI I'm running a new test build with Tom's patch and
without this series.
Additionally a new recipe in core needs a maintainer, and as such it is
warning:
WARNING: xcb-util-cursor-0.1.4-r0 do_fetch: QA Issue: Recipe xcb-util-cursor in
/home/pokybuild/yocto-worker/a-full/build/meta/recipes-graphics/xorg-lib/xcb-util-cursor_0.1.4.bb
does not have an assigned maintainer. Please add an entry into
meta/conf/distro/include/maintainers.inc. [missing-metadata]
Full log:
https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/5511/steps/13/logs/stdio
Luca
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183317):
https://lists.openembedded.org/g/openembedded-core/message/183317
Mute This Topic: https://lists.openembedded.org/mt/99702160/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 v8 1/3] cve-check: add option to add additional patched CVEs
On 22 Jun 2023, at 13:00, Andrej Valek via lists.openembedded.org
wrote:
> - Replace CVE_CHECK_IGNORE with CVE_STATUS to be more flexible.
> The CVE_STATUS should contain an information about status wich
> is decoded in 3 items:
> - generic status: "Ignored", "Patched" or "Unpatched"
> - more detailed status enum
> - description: free text describing reason for status
I think this needs to be clearer about what the intended use of the keywords
are.
Is the canonical data the CVE_STATUS[CVE-1234-5678] attribute, and the mapping
from the status there via CVE_CHECK_STATUSMAP simply for backwards
compatibility with the existing file format? Is this deprecating the status
fields in those files or is it just a high-level summary? Either way, that
should be made clear.
> +# Possible options for CVE statuses
> +
> +# used by this class internally when fix is detected (NVD DB version check
> or CVE patch file)
> +CVE_CHECK_STATUSMAP[patched] = "Patched"
> +# use when this class does not detect backported patch (e.g. vendor kernel
> repo with cherry-picked CVE patch)
> +CVE_CHECK_STATUSMAP[backported-patch] = "Patched"
> +# use when NVD DB does not mention patched versions of stable/LTS branches
> which have upstream CVE backports
> +CVE_CHECK_STATUSMAP[cpe-stable-backport] = "Patched"
> +# use when NVD DB does not mention correct version or does not mention any
> verion at all
> +CVE_CHECK_STATUSMAP[fixed-version] = "Patched"
It bothers me that some of these status flags are working around the fact that
the CPE is incorrect, when that CPE data can be fixed. Instead of setting
fixed-version, we can just mail NIST and fix the CPE.
> +# used internally by this class if CVE vulnerability is detected which is
> not marked as fixed or ignored
> +CVE_CHECK_STATUSMAP[unpatched] = "Unpatched"
> +# use when CVE is confirmed by upstream but fix is still not available
> +CVE_CHECK_STATUSMAP[vulnerable-investigating] = "Unpatched"
> +
> +# used for migration from old concept, do not use for new vulnerabilities
> +CVE_CHECK_STATUSMAP[ignored] = "Ignored"
> +# use when NVD DB wrongly indicates vulnerability which is actually for a
> different component
> +CVE_CHECK_STATUSMAP[cpe-incorrect] = "Ignored"
> +# use when upstream does not accept the report as a vulnerability (e.g.
> works as designed)
> +CVE_CHECK_STATUSMAP[disputed] = "Ignored"
> +# use when vulnerability depends on build or runtime configuration which is
> not used
> +CVE_CHECK_STATUSMAP[not-applicable-config] = "Ignored"
> +# use when vulnerability affects other platform (e.g. Windows or Debian)
> +CVE_CHECK_STATUSMAP[not-applicable-platform] = "Ignored"
> +# use when upstream acknowledged the vulnerability but does not plan to fix
> it
> +CVE_CHECK_STATUSMAP[upstream-wontfix] = "Ignored"
Is this any different to ‘disputed’?
Do we expect to add a lot more statuses to this table, or for users to add
their own values? It feels like maybe this should be a dict in
lib/oe/cve_check.py instead of exposed in the data store.
> +# Process CVE_STATUS_GROUPS to set multiple statuses and optional detail
> or description at once
> +for cve_status_group in (d.getVar("CVE_STATUS_GROUPS") or "").split():
> +cve_group = d.getVar(cve_status_group)
> +if cve_group is not None:
> +for cve in cve_group.split():
> +d.setVarFlag("CVE_STATUS", cve,
> d.getVarFlag(cve_status_group, "status"))
> +else:
> +bb.warn("CVE_STATUS_GROUPS contains undefined variable %s" %
> cve_status_group)
> +}
CVE_STATUS_GROUPS isn’t documented in the class or the commit message.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183316):
https://lists.openembedded.org/g/openembedded-core/message/183316
Mute This Topic: https://lists.openembedded.org/mt/99695984/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 4/9] runqemu-ifup: remove only our taps
On 22 June 2023 19:01, openembedded-core@lists.openembedded.org wrote: > If there are other tap interfaces than the interfaces created by the > runqemu-* scripts, these interfaces are not ignored. This is now fixed > by filtering the interfaces for a specific prefix in the interface name. > > Signed-off-by: Adrian Freihofer > --- > scripts/runqemu-ifup | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup > index fe4492e78b7..c65ceaf1c83 100755 > --- a/scripts/runqemu-ifup > +++ b/scripts/runqemu-ifup > @@ -45,7 +45,7 @@ if [ -z "$OE_TAP_NAME" ]; then > fi > > if taps=$(ip tuntap list 2>/dev/null); then > - tap_no_last=$(echo "$taps" |cut -f 1 -d ":" |sed "s/$OE_TAP_NAME//g" > | sort -rn | head -n 1) > + tap_no_last=$(echo "$taps" |cut -f 1 -d ":" |grep -E > "^$OE_TAP_NAME.*" |sed "s/$OE_TAP_NAME//g" | sort -rn | head -n 1) You can combine the cut+grep+sed to `sed "/^$OE_TAP_NAME/!d; s///; s/:.*//"` Regards, Jörg Sommer Software Developer / Programmierer -- Navimatix GmbH Tatzendpromenade 2 07745 Jena T: 03641 - 327 99 0 F: 03641 - 526 306 M: joerg.som...@navimatix.de www.navimatix.de Geschäftsführer: Steffen Späthe, Jan Rommeley Registergericht: Amtsgericht Jena, HRB 501480 -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183315): https://lists.openembedded.org/g/openembedded-core/message/183315 Mute This Topic: https://lists.openembedded.org/mt/99702217/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] uninative: call patchelf-uninative only when needed
mke2fs.real, mkfs.ext2.real, mkfs.ext3.real, mkfs.ext4.real are indentical
binary with multiple hardlinks and we end calling patchelf-uninative 4
times even when the interpreter is already set correctly from the build
To avoid corrupted binaries created by patchelf-0.18.0 when set-interpreter
is called multiple times (on some systems like ubuntu-18.04 this leads to
segfaults elsewhere just ldd complains that the executable is no longer
dynamically linked, but doesn't fail when executed).
The issue was reported upstream with mkfs.ext4.real as possible reproducer:
https://github.com/NixOS/patchelf/issues/492#issuecomment-1602862272
alternatively we can revert
https://github.com/NixOS/patchelf/commit/65cdee904431d16668f95d816a495bc35a05a192
and create new uninative release with update patchelf-uninative, but
better to wait a bit for upstream to have a look and possibly backport
proper fix later, until then this change fixes the mkfs.ext4 issues I was
seeing in kirkstone, mickledore, nanbield since uninative-3.9 upgrade, as
reported in:
https://lists.openembedded.org/g/openembedded-core/message/182862
Signed-off-by: Martin Jansa
---
meta/classes-global/uninative.bbclass | 11 ---
1 file changed, 8 insertions(+), 3 deletions(-)
diff --git a/meta/classes-global/uninative.bbclass
b/meta/classes-global/uninative.bbclass
index 366f7ac793..b54acdd542 100644
--- a/meta/classes-global/uninative.bbclass
+++ b/meta/classes-global/uninative.bbclass
@@ -175,7 +175,12 @@ python uninative_changeinterp () {
if not elf.isDynamic():
continue
-os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
-subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
-os.chmod(f, s[stat.ST_MODE])
+current = subprocess.check_output(("patchelf-uninative",
"--print-interpreter", f),
stderr=subprocess.STDOUT).decode('utf-8').split('\n')[0]
+if current != d.getVar("UNINATIVE_LOADER"):
+bb.debug(2, "Changing interpreter from %s to %s with %s" %
(current, d.getVar("UNINATIVE_LOADER"), ("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f)))
+os.chmod(f, s[stat.ST_MODE] | stat.S_IWUSR)
+subprocess.check_output(("patchelf-uninative",
"--set-interpreter", d.getVar("UNINATIVE_LOADER"), f), stderr=subprocess.STDOUT)
+os.chmod(f, s[stat.ST_MODE])
+else:
+bb.debug(2, "Interpreter was already set to %s in %s" %
(d.getVar("UNINATIVE_LOADER"), f))
}
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183314):
https://lists.openembedded.org/g/openembedded-core/message/183314
Mute This Topic: https://lists.openembedded.org/mt/99715032/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] rootfs-postcommands: Set vardeps for write_image_test_data
Hello Peter, On Thu, 22 Jun 2023 17:34:13 +0100 "Peter Hoyes" wrote: > From: Peter Hoyes > > The testdata.json file generated as part of the rootfs postprocess > commands currently contains almost all Bitbake variables and is used by > OEQA test cases to inspect the build environment. However only a small > number of variables are actually used and the testdata.json is not > automatically updated when the variables are updated. > > Introduce the TESTIMAGE_EXPORT_VARS variable to explicitly define the > variables to be collected for testdata.json and populate with all > variables used by runtime tests in OE-core. Use this variable to set the > vardeps of write_image_test_data. > > Modify export2json to take an explicit list of keys to export, instead > of exporting everything in the datastore. > > Add a demonstrative OE selftest to rootfspostcommandstests. > > Signed-off-by: Peter Hoyes This patch is triggering some failures on the autobuilders: Exception: TypeError: export2json() missing 1 required positional argument: 'json_file' Some logs: https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/7744/steps/11/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/7744/steps/16/logs/stdio Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183313): https://lists.openembedded.org/g/openembedded-core/message/183313 Mute This Topic: https://lists.openembedded.org/mt/99701497/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/9] runqemu-ifup: remove uid parameter
On 22 June 2023 19:01, openembedded-core@lists.openembedded.org wrote:
> ip tuntap does not need the uid, it was an unused variable/parameter.
> Backward compatibility should be fine.
>
> Signed-off-by: Adrian Freihofer
> ---
> scripts/runqemu-ifup | 13 -
> 1 file changed, 8 insertions(+), 5 deletions(-)
>
> diff --git a/scripts/runqemu-ifup b/scripts/runqemu-ifup
> index 5dc765dee82..26714518020 100755
> --- a/scripts/runqemu-ifup
> +++ b/scripts/runqemu-ifup
> @@ -21,7 +21,7 @@
> #
>
> usage() {
> - echo "sudo $(basename $0) "
> + echo "sudo $(basename $0) "
> }
>
> if [ $EUID -ne 0 ]; then
> @@ -29,17 +29,20 @@ if [ $EUID -ne 0 ]; then
> exit 1
> fi
>
> -if [ $# -ne 2 ]; then
> +if [ $# -eq 2 ]; then
> + echo "Warning: uid parameter is ignored. It is no longer needed."
Would it be better to send this message to stderr (use `>&2`)?
Regards
Jörg Sommer
Software Developer / Programmierer
--
Navimatix GmbH
Tatzendpromenade 2
07745 Jena
T: 03641 - 327 99 0
F: 03641 - 526 306
M: joerg.som...@navimatix.de
www.navimatix.de
Geschäftsführer: Steffen Späthe, Jan Rommeley
Registergericht: Amtsgericht Jena, HRB 501480
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183312):
https://lists.openembedded.org/g/openembedded-core/message/183312
Mute This Topic: https://lists.openembedded.org/mt/99702214/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 V4 1/3] kernel-module-split: make autoload and probeconf distribution specific
Hi Luca, Luca Ceresoli escreveu no dia quinta, 22/06/2023 à(s) 17:36: > Hi Jose, > > On Thu, 22 Jun 2023 08:44:51 + > "Jose Quaresma" wrote: > > > Also take the oportunity to only add configuration files to FILES > > and CONFFILES when they exist and are used. > > > > The modules-load.d [1] - Configure kernel modules to load at boot > > should install their configuration files in /usr/lib/modules-load.d. > > > > The modprobe.d [2] - Configuration directory for modprobe > > should install their configuration files in /lib/modprobe.d > > > > [1] https://www.freedesktop.org/software/systemd/man/modules-load.d.html > > [2] https://www.man7.org/linux/man-pages//man5/modprobe.d.5.html > > > > [YOCTO #12212] https://bugzilla.yoctoproject.org/show_bug.cgi?id=12212 > > > > CC: Ola x Nilsson > > CC: Peter Kjellerstedt > > Signed-off-by: Jose Quaresma > > This has now turned to: > > ERROR: linux-yocto-6.1.33+gitAUTOINC+db25e51e20_947f660bde-r0 do_package: > QA Issue: linux-yocto: Files/directories were installed but not shipped in > any package: > /usr/lib > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5410/steps/14/logs/stdio > > https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5383/steps/15/logs/stdio I have another patch where we only create the directories when needed (if we have mod config files) and with that we do not need to remove them at the end. However this one changes the logic a bit, so I'd like to send this one separately but I can see that it won't work so I'll have to insert it on V5. Once again thanks for testing. Jose > > Luca > > -- > Luca Ceresoli, Bootlin > Embedded Linux and Kernel engineering > https://bootlin.com > -- Best regards, José Quaresma -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183311): https://lists.openembedded.org/g/openembedded-core/message/183311 Mute This Topic: https://lists.openembedded.org/mt/99694059/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 0/3] wayland/weston upgrades
Hello Eilís, On Thu, 22 Jun 2023 15:42:14 +0100 Eilís 'pidge' Ní Fhlannagáin wrote: > Nothing really surprising here, except we should note that launcher-logind is > being depreciated so some thought on how that is dealt with will need to occur Should we file a bug in bugzilla to avoid forgetting about this? Luca -- Luca Ceresoli, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183310): https://lists.openembedded.org/g/openembedded-core/message/183310 Mute This Topic: https://lists.openembedded.org/mt/99702158/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 2/3] insane: ignore nativesdk-${PN}-src host contaminated issue
On Thu, 22 Jun 2023 at 20:04, Maxime Roussin-Bélanger wrote: > > I'm not sure I understand this. The check is to ensure build process > > works as it should, specifically to prevent build host ownership > > leaking into packages. Yes this information doesn't matter when these > > packages are installed, but it matters for correctness of the build. > > > > Alex > > Maybe I don't get how this check is done because everything in the TMPDIR > is owned by the user running bitbake. Installation and packaging tasks run under 'pseudo', an abstraction that gives the tasks an illusion of running as root and setting file ownership without restrictions. On build host's disk it's all owned by bitbake user, but actual packages contain the desired ownership for the target package installation. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#183309): https://lists.openembedded.org/g/openembedded-core/message/183309 Mute This Topic: https://lists.openembedded.org/mt/99701051/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 3/3] bitbake.conf: add debug symbol for sdk
But then you can set the parameters as you want them in your local
configuration. Setting -g globally in the absence of DEBUG_BUILD needs
a use case that applies to most users.
Alex
On Thu, 22 Jun 2023 at 19:11, Maxime Roussin-Bélanger
wrote:
>
> Hi Alex,
>
> I don't want a complete debug build. I want to keep optimization and
> have the debug symbols. I don't think I can achieve that with
> DEBUG_BUILD.
>
> Max
>
> On Thu, Jun 22, 2023 at 12:30 PM Alexander Kanavin
> wrote:
> >
> > This change is unnecessary, as there is already a mechanism. Just
> > slightly further down you can see that BUILDSDK_CFLAGS pulls in
> > BUILD_OPTIMIZATION, which sets -g if you enable DEBUG_BUILD in your
> > config.
> >
> > Alex
> >
> > On Thu, 22 Jun 2023 at 18:20, Maxime Roussin-Bélanger
> > wrote:
> > >
> > > From: Maxime Roussin-Belanger
> > >
> > > Without adding debug flag nativesdk dbg package is not packaged since
> > > there is no debugging information
> > >
> > > Signed-off-by: Maxime Roussin-Belanger
> > > ---
> > > v2: New commit
> > >
> > > meta/conf/bitbake.conf | 2 +-
> > > 1 file changed, 1 insertion(+), 1 deletion(-)
> > >
> > > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > > index 9d9b268858..0635affbc1 100644
> > > --- a/meta/conf/bitbake.conf
> > > +++ b/meta/conf/bitbake.conf
> > > @@ -601,7 +601,7 @@ PATCHRESOLVE = "noop"
> > > ##
> > >
> > > export BUILD_CPPFLAGS = "-isystem${STAGING_INCDIR_NATIVE}"
> > > -BUILDSDK_CPPFLAGS = ""
> > > +BUILDSDK_CPPFLAGS ?= "-g"
> > > export CPPFLAGS = "${TARGET_CPPFLAGS}"
> > > TARGET_CPPFLAGS = ""
> > >
> > > --
> > > 2.36.0
> > >
> > >
> > >
> > >
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#183308):
https://lists.openembedded.org/g/openembedded-core/message/183308
Mute This Topic: https://lists.openembedded.org/mt/99701056/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
