Date   

Re: [PATCH] e2fsprogs: add alternatives handling of lsattr as well

Rasmus Villemoes
 

On 09/06/2022 09.20, Luca Ceresoli wrote:
Hi Rasmus,

On Wed, 8 Jun 2022 15:12:05 +0200
"Rasmus Villemoes via lists.openembedded.org"
<rasmus.villemoes=prevas.dk@...> wrote:
^^^^^^^^^^^

As you can see above, your sender address is getting mangled. This is
not your fault, but it makes applying your patches annoying.

Can you please try to work around that by setting the sendemail.from
parameter in your git config?
Sorry about that, didn't know it.

It's not completely clear if I should put just the email address or the
full "Name <email>" in that configuration item, i.e. whether it's

[sendemail]
from = rasmus.villemoes@...

or

[sendemail]
from = Rasmus Villemoes <rasmus.villemoes@...>

For now I've gone with the latter, please let me know if that's correct.
In any case we'll see if it works the next time I submit a patch.

Rasmus


Re: [PATCH] mesa: upgrade 22.0.3 -> 22.1.1

Alexander Kanavin
 

I have looked into this and submitted a patch upstream for this:
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/16942

Let's defer the update until upstream addresses this one way or another.

Alex

On Tue, 7 Jun 2022 at 12:41, Luca Ceresoli via lists.openembedded.org
<luca.ceresoli=bootlin.com@...> wrote:

Hi wangmy,

On Mon, 6 Jun 2022 20:27:12 +0800
"wangmy" <wangmy@...> wrote:

Signed-off-by: Wang Mingyu <wangmy@...>
There are lots of failures when testing with this patch applied:

(EE) AIGLX error: Calling driver entry point failed

Here are some logs:

https://autobuilder.yoctoproject.org/typhoon/#/builders/73/builds/5275/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/5318/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/5291/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/5338/steps/19/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/109/builds/4202/steps/13/logs/stdio

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com



[PATCH] selftest/multiconfig: Test that multiconfigs in separate layers works

Richard Purdie
 

We should test that mutliconfigs from a layer work, not just build/conf.
This adds such a test.

[YOCTO #13566]

Signed-off-by: Richard Purdie <richard.purdie@...>
---
meta-selftest/conf/multiconfig/muslmc.conf | 2 ++
meta/lib/oeqa/selftest/cases/multiconfig.py | 13 +++++++++++++
2 files changed, 15 insertions(+)
create mode 100644 meta-selftest/conf/multiconfig/muslmc.conf

diff --git a/meta-selftest/conf/multiconfig/muslmc.conf b/meta-selftest/conf/multiconfig/muslmc.conf
new file mode 100644
index 00000000000..043cd1ccc3b
--- /dev/null
+++ b/meta-selftest/conf/multiconfig/muslmc.conf
@@ -0,0 +1,2 @@
+TCLIBC = "musl"
+TMPDIR = "${TOPDIR}/tmp-mc-musl"
diff --git a/meta/lib/oeqa/selftest/cases/multiconfig.py b/meta/lib/oeqa/selftest/cases/multiconfig.py
index baae9b456f5..83cbd1345da 100644
--- a/meta/lib/oeqa/selftest/cases/multiconfig.py
+++ b/meta/lib/oeqa/selftest/cases/multiconfig.py
@@ -70,3 +70,16 @@ TMPDIR = "${TOPDIR}/tmp-mc-tiny"

result = bitbake('mc:test:multiconfig-test-parse -c showvar')
self.assertIn('MCTESTVAR=test2', result.output.splitlines())
+
+ def test_multiconfig_inlayer(self):
+ """
+ Test that a multiconfig from meta-selftest works.
+ """
+
+ config = """
+BBMULTICONFIG = "muslmc"
+"""
+ self.write_config(config)
+
+ # Build a core-image-minimal, only dry run needed to check config is present
+ bitbake('mc:muslmc:bash -n')
--
2.34.1


[meta-java] icedtea7-native build fails on kirkstone and in master

Bartosz Golaszewski
 

Hi!

I'm trying to build java support with the following configuration:

Build Configuration:
BB_VERSION = "2.0.0"
BUILD_SYS = "x86_64-linux"
NATIVELSBSTRING = "universal"
TARGET_SYS = "x86_64-poky-linux"
MACHINE = "qemux86-64"
DISTRO = "poky"
DISTRO_VERSION = "4.0.1"
TUNE_FEATURES = "m64 core2"
TARGET_FPU = ""
meta
meta-poky = "kirkstone:45d7615dfef8093a2467d52ca1130e62db6a1187"
meta-oe = "kirkstone:fcc7d7eae82be4c180f2e8fa3db90a8ab3be07b7"
meta-java = "kirkstone:1a8059f6b257ebe6fcae6416e499784d976afd24"

---

PREFERRED_PROVIDER_virtual/java-initial-native = "cacao-initial-native"
PREFERRED_PROVIDER_virtual/java-native = "jamvm-native"
PREFERRED_PROVIDER_virtual/javac-native = "ecj-bootstrap-native"

---

The build fails for icedtea7-native but it's hard to tell why exactly
from the logs. Here is the full output: https://pastebin.com/3dRt6J0Y

It seems to be failing here:

| Checking for mapfile use in:
/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so
| Library loads for:
/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so
| make[5]: Leaving directory
'/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make/java/management'
| make[5]: *** [../../common/Library.gmk:225:
/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk.build-boot/lib/amd64/libmanagement.so]
Error 1
| make[4]: Leaving directory
'/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make/java'
| make[4]: *** [Makefile:63: all] Error 1
| make[3]: Leaving directory
'/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot/jdk/make'
| make[3]: *** [Makefile:247: all] Error 1
| make[2]: Leaving directory
'/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot'
| make[2]: *** [make/jdk-rules.gmk:79: jdk-build] Error 2
| make[1]: Leaving directory
'/home/brgl/workspace/target-build-yocto/build/tmp/work/x86_64-linux/icedtea7-native/2.1.3-r1.0/icedtea-2.1.3/build/openjdk-boot'
| make[1]: *** [Makefile:244: build_product_image] Error 2
| make: *** [Makefile:2252: stamps/icedtea-boot.stamp] Error 2

But not sure why.

Thanks in advance for any help.
Bart


[PATCH v2] dbus: Soecify runstatedir configure option

Pavel Zhukov
 

Without specifing runstatedir tmpfiles.d is configured to use /var/run
for dbus and this causes deprecation warnings in system logs.

Signed-off-by: Pavel Zhukov <pavel.zhukov@...>
---
meta/recipes-core/dbus/dbus_1.14.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/dbus/dbus_1.14.0.bb b/meta/recipes-core/dbus/dbus_1.14.0.bb
index 7598c45f8e..0046b9fda2 100644
--- a/meta/recipes-core/dbus/dbus_1.14.0.bb
+++ b/meta/recipes-core/dbus/dbus_1.14.0.bb
@@ -24,6 +24,7 @@ EXTRA_OECONF = "--disable-xml-docs \
--enable-tests \
--enable-checks \
--enable-asserts \
+ --runstatedir=/run \
"
EXTRA_OECONF:append:class-target = " SYSTEMCTL=${base_bindir}/systemctl"

@@ -131,7 +132,7 @@ do_install() {
sed 's:@bindir@:${bindir}:' < ${WORKDIR}/dbus-1.init >${WORKDIR}/dbus-1.init.sh
install -m 0755 ${WORKDIR}/dbus-1.init.sh ${D}${sysconfdir}/init.d/dbus-1
install -d ${D}${sysconfdir}/default/volatiles
- echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \
+ echo "d messagebus messagebus 0755 /run/dbus none" \
> ${D}${sysconfdir}/default/volatiles/99_dbus
fi

--
2.35.1


[PATCH] dbus: Soecify runstatedir configure option

Pavel Zhukov
 

From: Pavel Zhukov <pavel.zhukov@...>

Without specifing runstatedir tmpfiles.d is configured to use /var/run
for dbus and this causes deprecation warnings in system logs.

Signed-off-by: Pavel Zhukov <pavel.zhukov@...>
---
meta/recipes-core/dbus/dbus_1.14.0.bb | 3 ++-
1 file changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-core/dbus/dbus_1.14.0.bb b/meta/recipes-core/dbus/dbus_1.14.0.bb
index 7598c45f8e..0046b9fda2 100644
--- a/meta/recipes-core/dbus/dbus_1.14.0.bb
+++ b/meta/recipes-core/dbus/dbus_1.14.0.bb
@@ -24,6 +24,7 @@ EXTRA_OECONF = "--disable-xml-docs \
--enable-tests \
--enable-checks \
--enable-asserts \
+ --runstatedir=/run \
"
EXTRA_OECONF:append:class-target = " SYSTEMCTL=${base_bindir}/systemctl"

@@ -131,7 +132,7 @@ do_install() {
sed 's:@bindir@:${bindir}:' < ${WORKDIR}/dbus-1.init >${WORKDIR}/dbus-1.init.sh
install -m 0755 ${WORKDIR}/dbus-1.init.sh ${D}${sysconfdir}/init.d/dbus-1
install -d ${D}${sysconfdir}/default/volatiles
- echo "d messagebus messagebus 0755 ${localstatedir}/run/dbus none" \
+ echo "d messagebus messagebus 0755 /run/dbus none" \
> ${D}${sysconfdir}/default/volatiles/99_dbus
fi

--
2.35.1


[PATCH] uboot-sign: Fix potential index error issues

Richard Purdie
 

Someone reported that if some other shell function has left i or j set,
the concat_dtb_helper function could fail. Add a small tweak to avoid this.

[YOCTO #14815]

Signed-off-by: Richard Purdie <richard.purdie@...>
---
meta/classes/uboot-sign.bbclass | 2 ++
1 file changed, 2 insertions(+)

diff --git a/meta/classes/uboot-sign.bbclass b/meta/classes/uboot-sign.bbclass
index 4ca8118eb27..31ffe1f4720 100644
--- a/meta/classes/uboot-sign.bbclass
+++ b/meta/classes/uboot-sign.bbclass
@@ -134,6 +134,8 @@ concat_dtb_helper() {

if [ -n "${UBOOT_CONFIG}" ]
then
+ i=0
+ j=0
for config in ${UBOOT_MACHINE}; do
i=$(expr $i + 1);
for type in ${UBOOT_CONFIG}; do
--
2.34.1


[PATCH] ltp: use bfd even when gold is used with ld-is-gold

Martin Jansa
 

* version 20220527 added KVM test infrastructure which currently fails to build with gold due to
SORT_NONE in linker script which isn't supported by gold:
https://sourceware.org/bugzilla/show_bug.cgi?id=18097
https://github.com/linux-test-project/ltp/commit/3fce2064b54843218d085aae326c8f7ecf3a8c41#diff-39268f0855c634ca48c8993fcd2c95b12a65b79e8d9fa5ccd6b0f5a8785c0dd6R36

Signed-off-by: Martin Jansa <Martin.Jansa@...>
---
meta/recipes-extended/ltp/ltp_20220527.bb | 6 ++++++
1 file changed, 6 insertions(+)

diff --git a/meta/recipes-extended/ltp/ltp_20220527.bb b/meta/recipes-extended/ltp/ltp_20220527.bb
index b136c83860..b3ef8f5910 100644
--- a/meta/recipes-extended/ltp/ltp_20220527.bb
+++ b/meta/recipes-extended/ltp/ltp_20220527.bb
@@ -33,6 +33,12 @@ S = "${WORKDIR}/git"

inherit autotools-brokensep pkgconfig

+# Version 20220527 added KVM test infrastructure which currently fails to build with gold due to
+# SORT_NONE in linker script which isn't supported by gold:
+# https://sourceware.org/bugzilla/show_bug.cgi?id=18097
+# https://github.com/linux-test-project/ltp/commit/3fce2064b54843218d085aae326c8f7ecf3a8c41#diff-39268f0855c634ca48c8993fcd2c95b12a65b79e8d9fa5ccd6b0f5a8785c0dd6R36
+LDFLAGS:append = "${@bb.utils.contains('DISTRO_FEATURES', 'ld-is-gold', ' -fuse-ld=bfd', '', d)}"
+
TARGET_CC_ARCH += "${LDFLAGS}"

export prefix = "/opt/${PN}"
--
2.35.1


Re: [PATCH 17/21] ltp: upgrade 20220121 -> 20220527

Martin Jansa
 

This seems to be causing:
when ld-is-gold is used.

Added in upstream commit:
  commit 3fce2064b54843218d085aae326c8f7ecf3a8c41
  Author: Martin Doucha <mdoucha@...>
  Date:   Thu Apr 21 14:33:50 2022 +0200

    KVM test infrastructure


On Mon, Jun 6, 2022 at 2:02 PM Alexander Kanavin <alex.kanavin@...> wrote:
Disable stack protection as newly added kvm tests won't build with it.

Signed-off-by: Alexander Kanavin <alex@...>
---
 meta/conf/distro/include/security_flags.inc   |  1 +
 ...sh-sort-filelist-for-reproducibility.patch | 28 -------------------
 .../ltp/{ltp_20220121.bb => ltp_20220527.bb}  |  3 +-
 3 files changed, 2 insertions(+), 30 deletions(-)
 delete mode 100644 meta/recipes-extended/ltp/ltp/0001-metadata-parse.sh-sort-filelist-for-reproducibility.patch
 rename meta/recipes-extended/ltp/{ltp_20220121.bb => ltp_20220527.bb} (97%)

diff --git a/meta/conf/distro/include/security_flags.inc b/meta/conf/distro/include/security_flags.inc
index 8374cb8544..2972f05b4e 100644
--- a/meta/conf/distro/include/security_flags.inc
+++ b/meta/conf/distro/include/security_flags.inc
@@ -61,6 +61,7 @@ TARGET_LDFLAGS:append:class-cross-canadian = " ${SECURITY_LDFLAGS}"
 SECURITY_STACK_PROTECTOR:pn-gcc-runtime = ""
 SECURITY_STACK_PROTECTOR:pn-glibc = ""
 SECURITY_STACK_PROTECTOR:pn-glibc-testsuite = ""
+SECURITY_STACK_PROTECTOR:pn-ltp = ""
 # All xorg module drivers need to be linked this way as well and are
 # handled in recipes-graphics/xorg-driver/xorg-driver-common.inc
 SECURITY_LDFLAGS:pn-xserver-xorg = "${SECURITY_X_LDFLAGS}"
diff --git a/meta/recipes-extended/ltp/ltp/0001-metadata-parse.sh-sort-filelist-for-reproducibility.patch b/meta/recipes-extended/ltp/ltp/0001-metadata-parse.sh-sort-filelist-for-reproducibility.patch
deleted file mode 100644
index e8d9f212a9..0000000000
--- a/meta/recipes-extended/ltp/ltp/0001-metadata-parse.sh-sort-filelist-for-reproducibility.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 4aad23f208cc7725cd61bbe5aaadb9994c794cd0 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin <alex@...>
-Date: Wed, 26 Jan 2022 20:58:46 +0100
-Subject: [PATCH] metadata/parse.sh: sort filelist for reproducibility
-
-find does not guarantee the order of the files.
-
-Upstream-Status: Submitted [https://github.com/linux-test-project/ltp/pull/907]
-Signed-off-by: Alexander Kanavin <alex@...>
----
- metadata/parse.sh | 2 +-
-
-diff --git a/metadata/parse.sh b/metadata/parse.sh
-index b43d024c68..1811665bfe 100755
---- a/metadata/parse.sh
-+++ b/metadata/parse.sh
-@@ -29,7 +29,7 @@ echo ' "tests": {'
-
- first=1
-
--for test in `find testcases/ -name '*.c'`; do
-+for test in `find testcases/ -name '*.c'|sort`; do
-       a=$($top_builddir/metadata/metaparse -Iinclude -Itestcases/kernel/syscalls/utils/ "$test")
-       if [ -n "$a" ]; then
-               if [ -z "$first" ]; then
---
-2.20.1
-
diff --git a/meta/recipes-extended/ltp/ltp_20220121.bb b/meta/recipes-extended/ltp/ltp_20220527.bb
similarity index 97%
rename from meta/recipes-extended/ltp/ltp_20220121.bb
rename to meta/recipes-extended/ltp/ltp_20220527.bb
index 8a13dcf9d0..b136c83860 100644
--- a/meta/recipes-extended/ltp/ltp_20220121.bb
+++ b/meta/recipes-extended/ltp/ltp_20220527.bb
@@ -22,11 +22,10 @@ CFLAGS:append:x86-64 = " -fomit-frame-pointer"

 CFLAGS:append:powerpc64 = " -D__SANE_USERSPACE_TYPES__"
 CFLAGS:append:mipsarchn64 = " -D__SANE_USERSPACE_TYPES__"
-SRCREV = "b0561ad8d9ee9fe1244b5385e941eb65a21e91a1"
+SRCREV = "6f88e0f6f1d6eb12c48c902f50f47ecbd3b0f18a"

 SRC_URI = "git://github.com/linux-test-project/ltp.git;branch=master;protocol=https \
            file://0001-Remove-OOM-tests-from-runtest-mm.patch \
-           file://0001-metadata-parse.sh-sort-filelist-for-reproducibility.patch \
            file://disable_hanging_tests.patch \
            "

--
2.30.2





Re: [master][kirkstone][PATCH] efivar: add musl libc compatibility

Davide Gardenal
 

Greetings,

I’m here to flag that this patch has not yet landed to kirkstone-nut, is there any reason why?

Davide

Il giorno 24 mag 2022, alle ore 10:04, Davide Gardenal <davidegarde2000@...> ha scritto:

Backport patch to get efivar working with musl.

Upstream issue:
https://github.com/rhboot/efivar/issues/202

After commit meta-oe/1582f81805ee3114bc1a44bd5cf52d21f96702ca
fwupd gives an error when trying to build with musl because
efivar is not compatible. This fixes the issue.

Signed-off-by: Davide Gardenal <davide.gardenal@...>
---
.../efisecdb-fix-build-with-musl-libc.patch | 184 ++++++++++++++++++
meta/recipes-bsp/efivar/efivar_38.bb | 3 +-
2 files changed, 185 insertions(+), 2 deletions(-)
create mode 100644 meta/recipes-bsp/efivar/efivar/efisecdb-fix-build-with-musl-libc.patch

diff --git a/meta/recipes-bsp/efivar/efivar/efisecdb-fix-build-with-musl-libc.patch b/meta/recipes-bsp/efivar/efivar/efisecdb-fix-build-with-musl-libc.patch
new file mode 100644
index 0000000000..ec5b285a06
--- /dev/null
+++ b/meta/recipes-bsp/efivar/efivar/efisecdb-fix-build-with-musl-libc.patch
@@ -0,0 +1,184 @@
+From cece3ffd5be2f8641eb694513f2b73e5eb97ffd3 Mon Sep 17 00:00:00 2001
+From: Natanael Copa <ncopa@...>
+Date: Fri, 28 Jan 2022 12:13:30 +0100
+Subject: [PATCH] efisecdb: fix build with musl libc
+
+Refactor code to use POSIX atexit(3) instead of the GNU specific
+on_exit(3).
+
+Resolves: #197
+Resolves: #202
+Signed-off-by: Natanael Copa <ncopa@...>
+
+Upstream-Status: Backport
+https://github.com/rhboot/efivar/commit/cece3ffd5be2f8641eb694513f2b73e5eb97ffd3
+
+Signed-off-by: Davide Gardenal <davide.gardenal@...>
+---
+ src/compiler.h | 2 --
+ src/efisecdb.c | 68 +++++++++++++++++++-------------------------------
+ 2 files changed, 26 insertions(+), 44 deletions(-)
+
+diff --git a/src/compiler.h b/src/compiler.h
+index e2f18f0b..d95fb014 100644
+--- a/src/compiler.h
++++ b/src/compiler.h
+@@ -7,8 +7,6 @@
+ #ifndef COMPILER_H_
+ #define COMPILER_H_
+
+-#include <sys/cdefs.h>
+-
+ /* GCC version checking borrowed from glibc. */
+ #if defined(__GNUC__) && defined(__GNUC_MINOR__)
+ # define GNUC_PREREQ(maj,min) \
+diff --git a/src/efisecdb.c b/src/efisecdb.c
+index f8823737..6bd5ad90 100644
+--- a/src/efisecdb.c
++++ b/src/efisecdb.c
+@@ -25,6 +25,10 @@
+ extern char *optarg;
+ extern int optind, opterr, optopt;
+
++static efi_secdb_t *secdb = NULL;
++static list_t infiles;
++static list_t actions;
++
+ struct hash_param {
+ char *name;
+ efi_secdb_type_t algorithm;
+@@ -187,12 +191,11 @@ add_action(list_t *list, action_type_t action_type, const efi_guid_t *owner,
+ }
+
+ static void
+-free_actions(int status UNUSED, void *actionsp)
++free_actions(void)
+ {
+- list_t *actions = (list_t *)actionsp;
+ list_t *pos, *tmp;
+
+- for_each_action_safe(pos, tmp, actions) {
++ for_each_action_safe(pos, tmp, &actions) {
+ action_t *action = list_entry(pos, action_t, list);
+
+ list_del(&action->list);
+@@ -202,12 +205,11 @@ free_actions(int status UNUSED, void *actionsp)
+ }
+
+ static void
+-free_infiles(int status UNUSED, void *infilesp)
++free_infiles(void)
+ {
+- list_t *infiles = (list_t *)infilesp;
+ list_t *pos, *tmp;
+
+- for_each_ptr_safe(pos, tmp, infiles) {
++ for_each_ptr_safe(pos, tmp, &infiles) {
+ ptrlist_t *entry = list_entry(pos, ptrlist_t, list);
+
+ list_del(&entry->list);
+@@ -216,27 +218,12 @@ free_infiles(int status UNUSED, void *infilesp)
+ }
+
+ static void
+-maybe_free_secdb(int status UNUSED, void *voidp)
++maybe_free_secdb(void)
+ {
+- efi_secdb_t **secdbp = (efi_secdb_t **)voidp;
+-
+- if (secdbp == NULL || *secdbp == NULL)
++ if (secdb == NULL)
+ return;
+
+- efi_secdb_free(*secdbp);
+-}
+-
+-static void
+-maybe_do_unlink(int status, void *filep)
+-{
+- char **file = (char **)filep;
+-
+- if (status == 0)
+- return;
+- if (file == NULL || *file == NULL)
+- return;
+-
+- unlink(*file);
++ efi_secdb_free(secdb);
+ }
+
+ static void
+@@ -323,15 +310,6 @@ parse_input_files(list_t *infiles, char **outfile, efi_secdb_t **secdb,
+ return status;
+ }
+
+-/*
+- * These need to be static globals so that they're not on main's stack when
+- * on_exit() fires.
+- */
+-static efi_secdb_t *secdb = NULL;
+-static list_t infiles;
+-static list_t actions;
+-static char *outfile = NULL;
+-
+ int
+ main(int argc, char *argv[])
+ {
+@@ -351,6 +329,7 @@ main(int argc, char *argv[])
+ bool do_sort_data = false;
+ bool sort_descending = false;
+ int status = 0;
++ char *outfile = NULL;
+
+ const char sopts[] = ":aAc:dfg:h:i:Lo:rs:t:v?";
+ const struct option lopts[] = {
+@@ -376,10 +355,9 @@ main(int argc, char *argv[])
+ INIT_LIST_HEAD(&infiles);
+ INIT_LIST_HEAD(&actions);
+
+- on_exit(free_actions, &actions);
+- on_exit(free_infiles, &infiles);
+- on_exit(maybe_free_secdb, &secdb);
+- on_exit(maybe_do_unlink, &outfile);
++ atexit(free_actions);
++ atexit(free_infiles);
++ atexit(maybe_free_secdb);
+
+ /*
+ * parse the command line.
+@@ -587,24 +565,30 @@ main(int argc, char *argv[])
+ outfd = open(outfile, flags, 0600);
+ if (outfd < 0) {
+ char *tmpoutfile = outfile;
+- if (errno == EEXIST)
+- outfile = NULL;
++ if (errno != EEXIST)
++ unlink(outfile);
+ err(1, "could not open \"%s\"", tmpoutfile);
+ }
+
+ rc = ftruncate(outfd, 0);
+- if (rc < 0)
++ if (rc < 0) {
++ unlink(outfile);
+ err(1, "could not truncate output file \"%s\"", outfile);
++ }
+
+ void *output;
+ size_t size = 0;
+ rc = efi_secdb_realize(secdb, &output, &size);
+- if (rc < 0)
++ if (rc < 0) {
++ unlink(outfile);
+ secdb_err(1, "could not realize signature list");
++ }
+
+ rc = write(outfd, output, size);
+- if (rc < 0)
++ if (rc < 0) {
++ unlink(outfile);
+ err(1, "could not write signature list");
++ }
+
+ close(outfd);
+ xfree(output);
diff --git a/meta/recipes-bsp/efivar/efivar_38.bb b/meta/recipes-bsp/efivar/efivar_38.bb
index 68c4b4b914..53fe20a95b 100644
--- a/meta/recipes-bsp/efivar/efivar_38.bb
+++ b/meta/recipes-bsp/efivar/efivar_38.bb
@@ -10,6 +10,7 @@ COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
SRC_URI = "git://github.com/rhinstaller/efivar.git;branch=main;protocol=https \
file://0001-docs-do-not-build-efisecdb-manpage.patch \
file://0001-src-Makefile-build-util.c-separately-for-makeguids.patch \
+ file://efisecdb-fix-build-with-musl-libc.patch \
"
SRCREV = "1753149d4176ebfb2b135ac0aaf79340bf0e7a93"

@@ -36,5 +37,3 @@ BBCLASSEXTEND = "native"
RRECOMMENDS:${PN}:class-target = "kernel-module-efivarfs"

CLEANBROKEN = "1"
-# https://github.com/rhboot/efivar/issues/202
-COMPATIBLE_HOST:libc-musl = 'null'
--
2.32.0


Re: [PATCH] e2fsprogs: add alternatives handling of lsattr as well

Luca Ceresoli
 

Hi Rasmus,

On Wed, 8 Jun 2022 15:12:05 +0200
"Rasmus Villemoes via lists.openembedded.org"
<rasmus.villemoes=prevas.dk@...> wrote:
^^^^^^^^^^^

As you can see above, your sender address is getting mangled. This is
not your fault, but it makes applying your patches annoying.

Can you please try to work around that by setting the sendemail.from
parameter in your git config?

You can read the details in this discussion:
https://lists.openembedded.org/g/openembedded-core/message/166515?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Crootfs.py%3A+find+.ko.zst+kernel+modules%2C20%2C2%2C0%2C91453338

Thanks you very much!

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH v3] python3-cryptography: remove --benchmark-disable option

Luca Ceresoli
 

Hi,

On Wed, 8 Jun 2022 17:31:20 +0800
"Yu, Mingli" <mingli.yu@...> wrote:

From: Mingli Yu <mingli.yu@...>

The new version introduced below change, so remove the option
to avoid python3-pytest-benchmark rdepends to fix the gap.
496703c8 Refs #7079 -- added basic scaffholding for benchmarks (#7087)

Fixes:
# ./run-ptest
Free memory: 31.283 GB
ERROR: usage: pytest [options] [file_or_dir] [file_or_dir] [...]
pytest: error: unrecognized arguments: --benchmark-disable
inifile: /usr/lib/python3-cryptography/ptest/pyproject.toml
rootdir: /usr/lib/python3-cryptography/ptest

Remove the case test_x509.py to avoid below failure:
file /usr/lib64/python3-cryptography/ptest/tests/bench/test_x509.py, line 9
def test_aki_public_bytes(benchmark):
> fixture 'benchmark' not found
> available fixtures: backend, cache, capfd, capfdbinary, caplog, capsys, capsysbinary, disable_rsa_checks, doctesty
> use 'pytest --fixtures [testpath]' for help on them.

Signed-off-by: Mingli Yu <mingli.yu@...>
I currently see all patches at v1, and a patch has one v2 and two v3s.
This is confusing and chances are whatever I take for testing will be
wrong.

Could you please send the entire series as v4, updated at the
current state of the art and with all the changes discussed in previous
replies?

Thanks!
--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


[kirkstone 00/13] Pull request (cover letter only)

Steve Sakoman
 

The following changes since commit e63013cc38b82659658365da53b14952711d6701:

gcc: Upgrade to 11.3 release (2022-06-02 06:48:32 -1000)

are available in the Git repository at:

git://git.openembedded.org/openembedded-core-contrib stable/kirkstone-next
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-next

Alexander Kanavin (3):
bash: submit patch upstream
valgrind: submit arm patches upstream
zip/unzip: mark all submittable patches as Inactive-Upstream

Jiaqing Zhao (4):
systemd: Drop 0001-test-parse-argument-Include-signal.h.patch
systemd: Remove __compare_fn_t type in musl-specific patch
systemd: Drop 0002-don-t-use-glibc-specific-qsort_r.patch
systemd: Correct path returned in sd_path_lookup()

Khem Raj (4):
systemd: Drop redundant musl patches
systemd: Document future actions needed for set of musl patches
systemd: Drop
0016-Hide-__start_BUS_ERROR_MAP-and-__stop_BUS_ERROR_MAP.patch
systemd: Update patch status

Martin Jansa (1):
makedevs: Don't use COPYING.patch just to add license file into ${S}

Richard Purdie (1):
lzo: Add further info to a patch and mark as Inactive-Upstream

...sysctl.d-binfmt.d-modules-load.d-to-.patch | 73 ++++
...se-ROOTPREFIX-without-suffixed-slash.patch | 42 ---
...test-parse-argument-Include-signal.h.patch | 27 --
.../0002-Add-sys-stat.h-for-S_IFDIR.patch | 2 +-
...002-don-t-use-glibc-specific-qsort_r.patch | 163 ---------
...-missing_type.h-add-comparison_fn_t.patch} | 41 +--
...missing.h-check-for-missing-strndupa.patch | 14 +-
...008-add-missing-FTW_-macros-for-musl.patch | 3 +
..._register_atfork-for-non-glibc-build.patch | 3 +
...S_ERROR_MAP-and-__stop_BUS_ERROR_MAP.patch | 33 --
...ype.h-add-__compar_d_fn_t-definition.patch | 28 --
.../systemd/0019-Handle-missing-LOCK_EX.patch | 24 --
...ible-pointer-type-struct-sockaddr_un.patch | 38 --
.../0021-test-json.c-define-M_PIl.patch | 4 +
meta/recipes-core/systemd/systemd_250.5.bb | 10 +-
.../makedevs/makedevs/COPYING.patch | 346 ------------------
.../makedevs/makedevs/makedevs.c | 4 +
.../makedevs/makedevs_1.0.1.bb | 5 +-
...etting-mcpu-to-cortex-a8-on-arm-arch.patch | 2 +-
...n-for-targets-which-don-t-support-it.patch | 2 +-
...te-march-mcpu-mfpu-for-ARM-test-apps.patch | 2 +-
.../bash/bash/makerace2.patch | 2 +-
...ass-LDFLAGS-to-tests-doing-link-step.patch | 2 +-
.../unzip/unzip/CVE-2021-4217.patch | 2 +-
.../unzip/unzip/avoid-strip.patch | 2 +-
.../unzip/unzip/define-ldflags.patch | 2 +-
.../unzip/unzip/fix-security-format.patch | 2 +-
.../unzip/unzip/symlink.patch | 2 +-
...LAGS-and-LDFLAGS-when-doing-link-tes.patch | 2 +-
.../zip/zip-3.0/10-remove-build-date.patch | 2 +-
.../zip/zip-3.0/fix-security-format.patch | 2 +-
.../zipnote-crashes-with-segfault.patch | 2 +-
...Use-memcpy-instead-of-reinventing-it.patch | 10 +-
33 files changed, 136 insertions(+), 762 deletions(-)
create mode 100644 meta/recipes-core/systemd/systemd/0001-Move-sysusers.d-sysctl.d-binfmt.d-modules-load.d-to-.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0001-systemd.pc.in-use-ROOTPREFIX-without-suffixed-slash.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0001-test-parse-argument-Include-signal.h.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0002-don-t-use-glibc-specific-qsort_r.patch
rename meta/recipes-core/systemd/systemd/{0003-missing_type.h-add-__compare_fn_t-and-comparison_fn_.patch => 0003-missing_type.h-add-comparison_fn_t.patch} (63%)
delete mode 100644 meta/recipes-core/systemd/systemd/0016-Hide-__start_BUS_ERROR_MAP-and-__stop_BUS_ERROR_MAP.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0017-missing_type.h-add-__compar_d_fn_t-definition.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0019-Handle-missing-LOCK_EX.patch
delete mode 100644 meta/recipes-core/systemd/systemd/0020-Fix-incompatible-pointer-type-struct-sockaddr_un.patch
delete mode 100644 meta/recipes-devtools/makedevs/makedevs/COPYING.patch

--
2.25.1


Re: [PATCH] e2fsprogs: add alternatives handling of lsattr as well

Paulo Neves
 

Looks good to me.


Re: How to use devicetree.bbclass?

Chris Laplante
 

We’re using honister. We have a recipe that generates a device tree using devicetree.bbclass. It doesn’t do anything special:
 
    SRC_URI = file://system-top.dts
    DT_INCLUDE:append = " ${THISDIR}/files"
    COMPATIBLE_MACHINE:zynq = "zynq"
    inherit devicetree
 
 
It’s unclear to me how this is actually supposed to work, however. There are no examples of using the class in poky or meta-openembedded that I can find.

What I’m leaning towards now is creating a bbappend for the kernel recipe that just installs the generated device tree into arch/arm/boot/dts. But if anyone has a better way I’d be glad to hear it.
 
I’ve done a little more experimenting and I think I understand now. Please someone correct me if I’m wrong.
 
If you want an in-tree (kernel source tree, that is) device tree, you set KERNEL_DEVICETREE. AFAICT the device tree doesn’t actually get baked into the kernel. Rather, it is exported alongside the kernel to be picked up by a fitImage, for example.
 
If you want an out-of-tree device tree, you can write a recipe that inherits devicetree.bbclass (if you want to use the device tree compiler), or I suppose you could write a recipe that just deploys a pre-built .dtb in a similar way to how devicetree.bbclass does. Either way, you *don’t* set KERNEL_DEVICETREE. Then the fitimage process will pick up the .dtb.
 
In my case, I’m creating a fitimage without an initramfs. It’s just the kernel and dtb. This is done by adding this to my MACHINE conf:
 
KERNEL_CLASSES += "kernel-fitimage"
KERNEL_IMAGETYPES += "fitImage"
 
You also need to tell the kernel-fitimage.bbclass where to get the dtb from, which is done somewhat indirectly by setting a preferred provider:
 
PREFERRED_PROVIDER_virtual/dtb = "my-device-tree"
 
 
 
Thanks,
Chris
 


Re: How to use devicetree.bbclass?

Chris Laplante
 

We’re using honister. We have a recipe that generates a device tree using devicetree.bbclass. It doesn’t do anything special:

 

    SRC_URI = file://system-top.dts

    DT_INCLUDE:append = " ${THISDIR}/files"

    COMPATIBLE_MACHINE:zynq = "zynq"

    inherit devicetree

 

 

It’s unclear to me how this is actually supposed to work, however. There are no examples of using the class in poky or meta-openembedded that I can find.


What I’m leaning towards now is creating a bbappend for the kernel recipe that just installs the generated device tree into arch/arm/boot/dts. But if anyone has a better way I’d be glad to hear it.

 

Thanks,

Chris


How to use devicetree.bbclass?

Chris Laplante
 

Hello,

 

We’re using honister. We have a recipe that generates a device tree using devicetree.bbclass. It doesn’t do anything special:

 

    SRC_URI = file://system-top.dts

    DT_INCLUDE:append = " ${THISDIR}/files"

    COMPATIBLE_MACHINE:zynq = "zynq"

    inherit devicetree

 

 

It’s unclear to me how this is actually supposed to work, however. There are no examples of using the class in poky or meta-openembedded that I can find.

 

In my MACHINE conf, I tried to set:

 

    KERNEL_DEVICETREE = "system-top.dtb"

 

but then Yocto thinks you’re talking about a system-top.dtb that lives in the kernel source arch/arm/boot/dtb.

 

I see in kernel-fitimage.bbclass there is something to do with EXTERNAL_KERNEL_DEVICETREE, but as far as I can tell that has to do with packaging the dtb as part of the fitimage. Which maybe is what I want? But then how do I tell Yocto not to bundle the dtb with the kernel?

 

It is a shame that there is no documentation in the kernel dev manual about how to deal with device trees. I’d offer to write it, but then of course first I’d need to understand what I’m doing :(

 

 

Thanks,

Chris


Re: [PATCH v2 4/5] oeqa/selftest: Add test for shebang overflow

Luca Ceresoli
 

Hi Paulo,

On Wed, 8 Jun 2022 14:53:05 +0200
"Luca Ceresoli via lists.openembedded.org"
<luca.ceresoli=bootlin.com@...> wrote:

Hi Paulo,

On Tue, 7 Jun 2022 17:11:22 +0200
"Paulo Neves" <ptsneves@...> wrote:

Make sure we do not stage any executable with a bigger shebang
than 128. Fixes [1]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11053

Signed-off-by: Paulo Neves <ptsneves@...>
This check seems to be working very well!! It triggered a huge amount
of build failures on the autobuilders due to libcheck having a shebang
too long in the checkmk script, e.g.:

#! /home/pokybuild/yocto-worker/genericx86-64-alt/build/build/tmp/work/x86_64-linux/libcheck-native/0.15.2-r0/recipe-sysroot-native/usr/bin/gawk -f

Here are a few logs:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5367/steps/14/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5367/steps/11/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5689/steps/11/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5340/steps/12/logs/errors

It would be great if you could add another patch to your series to fix
libcheck, and also to do 'bitbake world' to test as many packages as
possible before discovering from the autobuilders.
Here are more failures:

https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5689/steps/12/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5689/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5340/steps/12/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/5340/steps/12/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5340/steps/13/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5340/steps/13/logs/stdio

This time the error is:

stdio: ERROR: core-image-sato-1.0-r0 do_testsdk: The toolchain <...> is not built. Build it before running the tests: 'bitbake <image> -c populate_sdk' .

I'm not sure exactly how your code triggers such error, but it appeared
when testing on the autobuilders with this patch series and disappeared
when I removed only these 5 patches, thus it seems related.

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: [PATCH v2 4/5] oeqa/selftest: Add test for shebang overflow

Luca Ceresoli
 

On Wed, 8 Jun 2022 16:45:20 +0200
"Paulo Neves" <ptsneves@...> wrote:

On 6/8/22 14:53, Luca Ceresoli wrote:
Hi Paulo,

On Tue, 7 Jun 2022 17:11:22 +0200
"Paulo Neves" <ptsneves@...> wrote:

Make sure we do not stage any executable with a bigger shebang
than 128. Fixes [1]

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=11053

Signed-off-by: Paulo Neves <ptsneves@...>
This check seems to be working very well!! It triggered a huge amount
of build failures on the autobuilders due to libcheck having a shebang
too long in the checkmk script, e.g.:

#! /home/pokybuild/yocto-worker/genericx86-64-alt/build/build/tmp/work/x86_64-linux/libcheck-native/0.15.2-r0/recipe-sysroot-native/usr/bin/gawk -f

Here are a few logs:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5367/steps/14/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/5367/steps/11/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/20/builds/5689/steps/11/logs/errors
https://autobuilder.yoctoproject.org/typhoon/#/builders/37/builds/5340/steps/12/logs/errors
I am not seeing an immediate way to fix this optimally. The go-to
solution to this class of issues is to just make
the #!/usr/bin/env <interpreter>. The issue is that there is an extra
-f, which with /usr/bin/env, will not work. The awk manual also implies
this is not optional for standalone scripts. I think we can create a
wrapper, or maybe we already have such a wrapper?

It would be great if you could add another patch to your series to fix
libcheck, and also to do 'bitbake world' to test as many packages as
possible before discovering from the autobuilders.
It takes quite a while on my computer and often i get out of disk space.
I tried asking the linaro guys for a tuxsuite token but no answer yet.
If you have some way of getting resources to make builds let me know.
Did you enable rm_work?

--
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: Rust recipe fails to build project on kirkstone but works on dunfell

Randy MacLeod
 

On 2022-06-08 10:35, Bartosz Golaszewski wrote:
On Wed, Jun 8, 2022 at 3:21 AM Randy MacLeod
<randy.macleod@...> wrote:
[snip]

Naveen or I will take a look at some point and at least let you know if
we can reproduce the error.
Can you try using the master branch to use rust_1.60 ?
I doubt it will help but it might be easy to check.
Actually, the reason seems to be with outdated packages. I updated my
recipe to a newer version and hit a bunch of different issues but they
seem to be in cargo and not in oe-core (for reference:
https://github.com/rust-lang/cargo/pull/10730).

Then, I'll conclude that this is now in your court and there's nothing
you need from rust/bitbake in  oe-core.

Let me know if that's wrong.

../Randy


Bart

--
# Randy MacLeod
# Wind River Linux