Re: [OE-core] [kirkstone][PATCH-v2] Upgrade OpenSSL 3.0.7 -> 3.0.8

2023-02-14 Thread Richard Leitner via lists.openembedded.org
On Thu, Feb 09, 2023 at 08:08:00PM +0530, Siddharth wrote:
> From: Siddharth Doshi 
> 
> OpenSSL 3.0.8 fixes 1 HIGH level security vulnerability and 7 MODERATE level 
> security vulnerability [1].
> 
> Upgrade the recipe to point to 3.0.8.
> 
> CVE-2022-3996 is reported fixed in 3.0.8, so drop the patch for that as
> well.
> 
> [1] https://www.openssl.org/news/vulnerabilities.html
> 
> CVEs Fixed:
> https://www.openssl.org/news/secadv/20230207.txt
> 
> Signed-off-by: Siddharth Doshi 

Hi Siddharth,
thanks for the patch.

Tested-by: Richard Leitner 

> ---
>  .../openssl/openssl/CVE-2022-3996.patch   | 43 ---
>  .../{openssl_3.0.7.bb => openssl_3.0.8.bb}|  3 +-
>  2 files changed, 1 insertion(+), 45 deletions(-)
>  delete mode 100644 
> meta/recipes-connectivity/openssl/openssl/CVE-2022-3996.patch
>  rename meta/recipes-connectivity/openssl/{openssl_3.0.7.bb => 
> openssl_3.0.8.bb} (98%)


regards;rl

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177181): 
https://lists.openembedded.org/g/openembedded-core/message/177181
Mute This Topic: https://lists.openembedded.org/mt/96853907/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [meta-oe][PATCH V2] tar: add ptest support

2023-02-14 Thread Yan Xin Kuan
From: yanxk 

original test suites takes 5 minutes with KVM enabled.

autotest files would contain reference to TMPDIR, now
they are removed.

tar test would provide ptest output like:

PASS: compressor program failure
SKIP: remove-files with compression
PASS: remove-files with compression: grand-child

be aware tar tests contain some large compression and
decompression tests that require large device storage.

those cases would not work fine in default qemu image,
for the default storage is too small. Some errors:

listing sparse files bigger than 2^33 B./testsuite: line 1928: echo: 
write error: No space left on device

they are hard coded in the original test scripts, no
modifications have been made to that yet.

Signed-off-by: yanxk 
---
 .../distro/include/ptest-packagelists.inc |  1 +
 meta/recipes-extended/tar/tar-1.34/run-ptest  | 10 ++
 meta/recipes-extended/tar/tar_1.34.bb | 31 +--
 3 files changed, 40 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-extended/tar/tar-1.34/run-ptest

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 0681b4b7a2..139fbc4a03 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -102,6 +102,7 @@ PTESTS_SLOW = "\
 python3-cryptography-ptest \
 python3-ptest \
 strace-ptest \
+tar-ptest \
 tcl-ptest \
 util-linux-ptest \
 valgrind-ptest \
diff --git a/meta/recipes-extended/tar/tar-1.34/run-ptest 
b/meta/recipes-extended/tar/tar-1.34/run-ptest
new file mode 100644
index 00..9ca27153d9
--- /dev/null
+++ b/meta/recipes-extended/tar/tar-1.34/run-ptest
@@ -0,0 +1,10 @@
+#!/bin/sh
+
+# Define tar test work dir
+WORKDIR=/usr/lib/tar/ptest/tests/
+
+# Run test
+cd ${WORKDIR}
+./atconfig ./atlocal ./testsuite
+
+./testsuite 2>&1 | grep -E '[0-9]{1,3}: ' | sed -e 's/^.//' -e 
'/[ok]$/s/^/PASS: /;/FAILED (.*)/s/^/FAIL: /;/skipped (.*)/s/^/SKIP: 
/;/expected failure/ s/^/PASS: /;/UNEXPECTED PASS/s/^/FAIL: /' -e 's/ok$//g' -e 
's/FAILED.*//g' -e 's/skipped.*//g' -e 's/expected failure.*//g' -e 
's/UNEXPECTED PASS.*//g'
diff --git a/meta/recipes-extended/tar/tar_1.34.bb 
b/meta/recipes-extended/tar/tar_1.34.bb
index 7307cd57a2..ce319f6e7a 100644
--- a/meta/recipes-extended/tar/tar_1.34.bb
+++ b/meta/recipes-extended/tar/tar_1.34.bb
@@ -6,11 +6,13 @@ SECTION = "base"
 LICENSE = "GPL-3.0-only"
 LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 
-SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2"
+SRC_URI = "${GNU_MIRROR}/tar/tar-${PV}.tar.bz2 \
+   file://run-ptest \
+"
 
 SRC_URI[sha256sum] = 
"b44cc67f8a1f6b0250b7c860e952b37e8ed932a90bd9b1862a511079255646ff"
 
-inherit autotools gettext texinfo
+inherit autotools gettext texinfo ptest
 
 PACKAGECONFIG ??= ""
 PACKAGECONFIG:append:class-target = " ${@bb.utils.filter('DISTRO_FEATURES', 
'acl', d)}"
@@ -42,6 +44,31 @@ do_install:append:class-target() {
 fi
 }
 
+# Tar testsuite would generate some small tests that are bash
+# scripts, so set ptest dependency to bash
+
+RDEPENDS:${PN}-ptest += "bash"
+
+do_compile_ptest() {
+oe_runmake -C ${B}/gnu/ check
+oe_runmake -C ${B}/lib/ check
+oe_runmake -C ${B}/rmt/ check
+oe_runmake -C ${B}/src/ check
+oe_runmake -C ${B}/tests/ genfile checkseekhole ckmtime
+}
+
+do_install_ptest() {
+install -d ${D}${PTEST_PATH}/tests/
+sed -i "/abs_/d" ${B}/tests/atconfig
+install --mode=755 ${B}/tests/atconfig ${D}${PTEST_PATH}/tests/
+sed -i "s%${B}/../tar-1.34.build-aux:%%g" ${B}/tests/atlocal
+install --mode=755 ${B}/tests/atlocal ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/genfile ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/checkseekhole ${D}${PTEST_PATH}/tests/
+install --mode=755 ${B}/tests/ckmtime ${D}${PTEST_PATH}/tests/
+install --mode=755 ${S}/tests/testsuite ${D}${PTEST_PATH}/tests/
+}
+
 PACKAGES =+ "${PN}-rmt"
 
 FILES:${PN}-rmt = "${sbindir}/rmt*"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177180): 
https://lists.openembedded.org/g/openembedded-core/message/177180
Mute This Topic: https://lists.openembedded.org/mt/96975703/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] qemu: fix compile error

2023-02-14 Thread Kai Kang

On 2/14/23 22:30, Martin Jansa wrote:

Thanks Kai,

this should fix what I've reported in:
https://lists.openembedded.org/g/openembedded-core/message/176508 



once this is merged, can you please add both oe-core changes (3 qemu 
patches) to dunfell as well, so that similar patch is included in both 
branches? The broken version wasn't merged to dunfell after my report.


You meanCVE-2022-4144.patch and this commit, right? OK, will do.

Regards,
Kai



Regards,

On Tue, Feb 14, 2023 at 3:22 PM Kai Kang  
wrote:


From: Kai Kang 

Backport 2 patches and rebase
0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch to fix
compile error:

../qemu-6.2.0/hw/display/qxl.c: In function 'qxl_phys2virt':
../qemu-6.2.0/hw/display/qxl.c:1477:67: error: 'size' undeclared
(first use in this function); did you mean 'gsize'?
 1477 |         if (!qxl_get_check_slot_offset(qxl, pqxl, &slot,
&offset, size)) {
      |            ^~~~
      |            gsize
../qemu-6.2.0/hw/display/qxl.c:1477:67: note: each undeclared
identifier is reported only once for each function it appears in

Signed-off-by: Kai Kang 
---
 meta/recipes-devtools/qemu/qemu.inc           |   2 +
 ...ave-qxl_log_command-Return-early-if-.patch |  57 +
 ...ass-requested-buffer-size-to-qxl_phy.patch | 217
++
 3 files changed, 276 insertions(+)
 create mode 100644

meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
 create mode 100644

meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc
b/meta/recipes-devtools/qemu/qemu.inc
index b68be447f1..5430718f75 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -93,6 +93,8 @@ SRC_URI =
"https://download.qemu.org/${BPN}-${PV}.tar.xz


\
file://0021-target-ppc-implement-xs-n-maddqp-o-xs-n-msubqp-o.patch \
file://CVE-2022-3165.patch \
file://CVE-2022-4144.patch \
+
file://0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
\
+
file://0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
\
            "
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"

diff --git

a/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch

b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
new file mode 100644
index 00..cd846222c9
--- /dev/null
+++

b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
@@ -0,0 +1,57 @@
+Upstream-Status: Backport
[https://github.com/qemu/qemu/commit/61c34fc

]
+
+Signed-off-by: Kai Kang 
+
+From 61c34fc194b776ecadc39fb26b061331107e5599 Mon Sep 17 00:00:00
2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Mon, 28 Nov 2022 21:27:37 +0100
+Subject: [PATCH] hw/display/qxl: Have qxl_log_command Return
early if no
+ log_cmd handler
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Only 3 command types are logged: no need to call qxl_phys2virt()
+for the other types. Using different cases will help to pass
+different structure sizes to qxl_phys2virt() in a pair of commits.
+
+Reviewed-by: Marc-André Lureau 
+Signed-off-by: Philippe Mathieu-Daudé 
+Signed-off-by: Stefan Hajnoczi 
+Message-Id: <20221128202741.4945-2-phi...@linaro.org>
+---
+ hw/display/qxl-logger.c | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/hw/display/qxl-logger.c b/hw/display/qxl-logger.c
+index 68bfa47568..1bcf803db6 100644
+--- a/hw/display/qxl-logger.c
 b/hw/display/qxl-logger.c
+@@ -247,6 +247,16 @@ int qxl_log_command(PCIQXLDevice *qxl, const
char *ring, QXLCommandExt *ext)
+             qxl_name(qxl_type, ext->cmd.type),
+             compat ? "(compat)" : "");
+
++    switch (ext->cmd.type) {
++    case QXL_CMD_DRAW:
++        break;
++    case QXL_CMD_SURFACE:
++        break;
++    case QXL_CMD_CURSOR:
++        break;
++  

Re: [OE-core] [kirkstone][PATCH 0/1] Update webkitgtk to 2.38.4 for CVEs

2023-02-14 Thread Kai Kang

On 2/15/23 00:22, Steve Sakoman wrote:

Stable branch policy doesn't allow this type of version upgrade.  I
can only take upgrades that are strict bug/security fix only releases.
The reason that why upgrade webkitgtk directly is that there is no 
obvious single patch to fix CVEs.
It just declares that some CVEs have been fixed in x.x.x version. And 
update to 2.38.4 could resolve

15 CVEs at least.


Exceptions to the policy would require TSC approval.


Who is TSCer? Would he/she like to review it, please?

Thanks,
Kai



Best regards,

Steve

On Sun, Feb 12, 2023 at 7:50 PM Kai Kang  wrote:

From: Kai Kang 

Update webkitgtk 2.36.8 to latest version 2.38.4 which solves a lot of CVEs.

The diff output of header files is attached at the end of this file.

Kai Kang (1):
   webkitgtk: 2.36.8 -> 2.38.4

  ...spection.cmake-prefix-variables-obta.patch |  39 +--
  .../0001-Fix-build-without-opengl-or-es.patch | 133 
  ...tings-so-that-gtkdoc-generation-work.patch |  47 ---
  ...trospection-files-do-not-quote-CFLAG.patch |  78 -
  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ++
  ...ebkitgtk_2.36.8.bb => webkitgtk_2.38.4.bb} |  15 +-
  7 files changed, 348 insertions(+), 290 deletions(-)
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-without-opengl-or-es.patch
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/0001-When-building-introspection-files-do-not-quote-CFLAG.patch
  create mode 100644 
meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
  create mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
  rename meta/recipes-sato/webkit/{webkitgtk_2.36.8.bb => webkitgtk_2.38.4.bb} 
(92%)

--
2.17.1

diff -Nur 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h 
2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h
--- 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h  2022-06-30 
17:49:25.0 +0800
+++ 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h  2022-09-20 
16:13:44.0 +0800
@@ -23,7 +23,7 @@
   * THE POSSIBILITY OF SUCH DAMAGE.
   */

-#if !defined(__JSC_H_INSIDE__) && !defined(JSC_COMPILATION)
+#if !defined(__JSC_H_INSIDE__) && !defined(JSC_COMPILATION) && 
!defined(WEBKIT2_COMPILATION)
  #error "Only  can be included directly."
  #endif

@@ -42,7 +42,9 @@
  #define JSC_API __attribute__((visibility("default")))
  #endif

+#ifndef __GI_SCANNER__
  #define JSC_DEPRECATED JSC_API G_DEPRECATED
  #define JSC_DEPRECATED_FOR(f) JSC_API G_DEPRECATED_FOR(f)
+#endif /* !__GI_SCANNER__ */

  #endif /* JSCDefines_h */
diff -Nur 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h 
2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h
--- 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h2022-06-30 
17:49:25.0 +0800
+++ 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h2022-09-20 
16:13:44.0 +0800
@@ -49,6 +49,21 @@
  JSC_VALUE_PROPERTY_WRITABLE = 1 << 2
  } JSCValuePropertyFlags;

+typedef enum {
+JSC_TYPED_ARRAY_NONE = 0,
+JSC_TYPED_ARRAY_INT8,
+JSC_TYPED_ARRAY_INT16,
+JSC_TYPED_ARRAY_INT32,
+JSC_TYPED_ARRAY_INT64,
+JSC_TYPED_ARRAY_UINT8,
+JSC_TYPED_ARRAY_UINT8_CLAMPED,
+JSC_TYPED_ARRAY_UINT16,
+JSC_TYPED_ARRAY_UINT32,
+JSC_TYPED_ARRAY_UINT64,
+JSC_TYPED_ARRAY_FLOAT32,
+JSC_TYPED_ARRAY_FLOAT64,
+} JSCTypedArrayType;
+
  struct _JSCValue {
  GObject parent;

@@ -246,6 +261,55 @@
  jsc_value_function_callv  (JSCValue *value,
 guint n_parameters,
 JSCValue**parameters) 
G_GNUC_WARN_UNUSED_RESULT;
+JSC_API JSCValue *
+jsc_value_new_array_buffer(JSCContext   *context,
+   gpointer  data,
+   gsize size,
+   GDestroyNotify
destroy_notify,
+   gpointer  user_data);
+
+JSC_API gboolean
+jsc_value_is_array_buffer (JSCValue *value);
+
+JSC_API gpointer
+jsc_value_array_buffer_get_data   (JSCValue *value,
+   gsize*size);
+
+JSC_API gsize
+jsc_value_array_buffer_get_size   (JSCValue *value);
+
+JSC_API JSCValue *
+jsc_value_new_typed_array (JSCContext   *context,
+   JSCTypedArrayType type,
+   gsize length);
+
+JSC_API JSCValue *
+jsc_value_new_typed

Re: [OE-core] [PATCH 1/2] site: remove glib site values

2023-02-14 Thread Alexandre Belloni via lists.openembedded.org
Hello Ross,

iI think this is causes failures on the AB while building nativesdk-pkgconfig:

https://autobuilder.yoctoproject.org/typhoon/#/builders/65/builds/6725/steps/12/logs/stdio

| checking for growing stack pointer... configure: error: in 
`/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/build/glib':
| configure: error: cannot run test program while cross compiling
| See `config.log' for more details
| configure: error: ../../git/glib/configure failed for glib
| NOTE: The following config.log files may provide further information.
| NOTE: 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/build/glib/config.log
 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/build/config.log
| ERROR: configure failed
| WARNING: 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368:285
 exit 1 from 'exit 1'
| WARNING: Backtrace (BB generated script):
|   #1: bbfatal_log, 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368,
 line 285
|   #2: oe_runconf, 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368,
 line 261
|   #3: autotools_do_configure, 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368,
 line 231
|   #4: do_configure, 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368,
 line 151
|   #5: main, 
/home/pokybuild/yocto-worker/beaglebone/build/build/tmp/work/i686-nativesdk-pokysdk-linux/nativesdk-pkgconfig/0.29.2+gitAUTOINC+d97db4fae4-r0/temp/run.do_configure.24368,
 line 289
NOTE: recipe nativesdk-pkgconfig-0.29.2+gitAUTOINC+d97db4fae4-r0: task 
do_configure: Failed
ERROR: Task 
(virtual:nativesdk:/home/pokybuild/yocto-worker/beaglebone/build/meta/recipes-devtools/pkgconfig/pkgconfig_git.bb:do_configure)
 failed with exit code '1'

Let me know if you want config.log, I pulled it from the worker.

On 14/02/2023 15:56:02+, Ross Burton wrote:
> GLib 1.x is incredibly obsolete and GLib 2.x is built using Meson
> not autotools, so we can remove the GLib entries from the site files.
> 
> Also fix a few copy/paste typos where glib_ was used incorrectly, for example:
> 
>   ac_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
> 
> The glib_cv_ should be ac_cv_.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/site/arc-common  |  4 
>  meta/site/arm-32  | 15 ---
>  meta/site/arm-64  | 15 ---
>  meta/site/arm-common  | 19 ---
>  meta/site/arm-darwin  |  2 --
>  meta/site/arm-darwin8 |  2 --
>  meta/site/arm-linux   |  2 +-
>  meta/site/armeb-linux |  2 +-
>  meta/site/common-glibc| 13 -
>  meta/site/common-musl |  9 -
>  meta/site/ix86-common | 22 --
>  meta/site/loongarch64-linux   |  4 
>  meta/site/microblaze-linux| 23 ---
>  meta/site/mips-common |  7 ---
>  meta/site/mips-linux  | 18 --
>  meta/site/mips64-linux| 22 --
>  meta/site/mips64el-linux  | 22 --
>  meta/site/mipsel-linux| 18 --
>  meta/site/mipsisa32r6-linux   | 18 --
>  meta/site/mipsisa32r6el-linux | 18 --
>  meta/site/mipsisa64r6-linux   | 22 --
>  meta/site/mipsisa64r6el-linux | 22 --
>  meta/site/nios2-linux | 35 +--
>  meta/site/powerpc-common  |  5 -
>  meta/site/powerpc-linux   |  5 -
>  meta/site/powerpc32-linux | 26 --
>  meta/site/riscv32-linux   |  4 
>  meta/site/riscv64-linux   |  4 
>  meta/site/sh-common   | 33 -
>  meta/site/sparc-linux |  6 --
>  meta/site/x32-linux   |  3 ---
>  meta/site/x86_64-linux| 22 --
>  32 files changed, 3 insertions(+), 439 deletions(-)
> 
> diff --git a/meta/site/arc-common b/meta/site/arc-common
> index d3c721a8bb9..5cdad0b07b0 100644
> --- a/meta/site/arc-common
> +++ b/meta/site/arc-common
> @@ -3,9 +3,5 @@ ac_cv_alignof_guint32=4
>  ac_cv_alignof_guint64=4
>

[OE-core] [PATCH] python3-numpy: upgrade to 1.24.2

2023-02-14 Thread Martin Jansa
* remove patch applied upstream

* FWIW: this version still fails to build with DEBUG_BUILD AND gcc-13 as
  shown in:
  http://errors.yoctoproject.org/Errors/Details/689841/

In file included from 
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/recipe-sysroot-native/usr/lib/x86_64-oe-linux/gcc/x86_64-oe-linux/13.0.1/include/immintrin.h:57,
 from 
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/numpy-1.24.1/numpy/distutils/checks/cpu_avx512_knl.c:14:
In function '_mm512_mask_prefetch_i64scatter_pd',
inlined from 'main' at 
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/numpy-1.24.1/numpy/distutils/checks/cpu_avx512_knl.c:23:5:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/recipe-sysroot-native/usr/lib/x86_64-oe-linux/gcc/x86_64-oe-linux/13.0.1/include/avx512pfintrin.h:180:3:
 error: 'base' may be used uninitialized [-Werror=maybe-uninitialized]
  180 |   __builtin_ia32_scatterpfqpd (__mask, (__v8di) __index, __addr, 
__scale,
  |   
^~~
  181 |__hint);
  |~~~
: In function 'main':
: note: by argument 3 of type 'const void *' to 
'__builtin_ia32_scatterpfqpd' declared here
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/numpy-1.24.1/numpy/distutils/checks/cpu_avx512_knl.c:18:9:
 note: 'base' declared here
   18 | int base[128];
  | ^~~~

In file included from 
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/recipe-sysroot-native/usr/lib/x86_64-oe-linux/gcc/x86_64-oe-linux/13.0.1/include/immintrin.h:53,
 from numpy/core/src/umath/simd.inc.src:25:
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/recipe-sysroot-native/usr/lib/x86_64-oe-linux/gcc/x86_64-oe-linux/13.0.1/include/avx512fintrin.h:
 In function 'AVX512F_square_CFLOAT':
TOPDIR/tmp-glibc/work/core2-64-oe-linux/python3-numpy/1.24.1-r0/recipe-sysroot-native/usr/lib/x86_64-oe-linux/gcc/x86_64-oe-linux/13.0.1/include/avx512fintrin.h:314:1:
 error: inlining failed in call to 'always_inline' '_mm512_setzero_ps': target 
specific option mismatch
  314 | _mm512_setzero_ps (void)
  | ^
numpy/core/src/umath/simd.inc.src:977:20: note: called from here
  977 | @vtype@ zeros = _mm512_setzero_@vsuffix@();
  |^~~
numpy/core/src/umath/simd.inc.src:596:1: error: inlining failed in call to 
'always_inline' 'avx512_get_full_load_mask_ps': target specific option mismatch
  596 | avx512_get_full_load_mask_ps(void)
  | ^~~~

It will be probably resolved in next release from 1.25 as whole simd.inc.src 
was removed in:
https://github.com/numpy/numpy/commit/640e85017aa8eac3e9be68b475acf27d623b16b7
but this PR https://github.com/numpy/numpy/pull/21056 wasn't backported
to maintenance/1.24.x and probably isn't worth backporting now as
neither DEBUG_BUILD is enabled by default nor gcc-13 merged in oe-core,
and the changes don't backport cleanly.

Signed-off-by: Martin Jansa 
---
 ...ing-_Alignof-when-using-C11-or-newer.patch | 77 ---
 ...umpy_1.24.1.bb => python3-numpy_1.24.2.bb} |  3 +-
 2 files changed, 1 insertion(+), 79 deletions(-)
 delete mode 100644 
meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
 rename meta/recipes-devtools/python/{python3-numpy_1.24.1.bb => 
python3-numpy_1.24.2.bb} (93%)

diff --git 
a/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
 
b/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
deleted file mode 100644
index 97391e2c12..00
--- 
a/meta/recipes-devtools/python/python3-numpy/0001-Define-_ALIGN-using-_Alignof-when-using-C11-or-newer.patch
+++ /dev/null
@@ -1,77 +0,0 @@
-From f9ac08a0fea543d68b2dba540093bd079e50be47 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Sun, 15 Jan 2023 15:49:09 -0800
-Subject: [PATCH] Define _ALIGN using _Alignof when using C11 or newer
-
-WG14 N2350 made very clear that it is an UB having type definitions
-within "offsetof" [1]. This patch enhances the implementation of macro
-_ALIGN to use builtin "_Alignof" to avoid undefined behavior on
-when using std=c11 or newer
-
-clang 16+ has started to flag this [2]
-
-Fixes build when using -std >= gnu11 and using clang16+
-
-Older compilers gcc < 4.9 or clang < 8 has buggy _Alignof even though it
-may support C11, exclude those compilers too
-
-[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
-[2] https://reviews.llvm.org/D133574
-
-Upstream-Status: Submitted [https://github.com/numpy/numpy/pull/23016]
-Signed-off-by: Khem Raj 

- numpy/core/src/multiarray/arraytypes.c.src | 13 +++--
- numpy/core/src/multiarray/common.h | 12 +++-
- 2 files ch

Re: [OE-core] [PATCH 2/2] site: remove at-spi2-core values

2023-02-14 Thread Khem Raj
these would need some testing, I wonder if there are other autotooled
recipes which indirectly are using these cached values.

On Tue, Feb 14, 2023 at 7:56 AM Ross Burton  wrote:
>
> at-spi2-core is built with Meson now, so these values are not needed.
>
> Signed-off-by: Ross Burton 
> ---
>  meta/site/arm-32 | 10 --
>  meta/site/arm-64 |  9 -
>  meta/site/ix86-common| 10 --
>  meta/site/mips-common| 10 --
>  meta/site/powerpc-common |  9 -
>  meta/site/x86_64-linux   | 10 --
>  6 files changed, 58 deletions(-)
>  delete mode 100644 meta/site/powerpc-common
>
> diff --git a/meta/site/arm-32 b/meta/site/arm-32
> index c6af852354e..be741617b67 100644
> --- a/meta/site/arm-32
> +++ b/meta/site/arm-32
> @@ -6,13 +6,3 @@ ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
>
>  # jikes
>  ac_cv_sizeof_wchar_t=4
> -
> -# at-spi2-core
> -ac_cv_alignof_char=1
> -ac_cv_alignof_dbind_pointer=4
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=8
> -ac_cv_alignof_double=8
> diff --git a/meta/site/arm-64 b/meta/site/arm-64
> index 79c10dab0e8..f4eae88471e 100644
> --- a/meta/site/arm-64
> +++ b/meta/site/arm-64
> @@ -6,12 +6,3 @@ ac_cv_sizeof_size_t=8
>  ac_cv_sizeof_ssize_t=8
>  ac_cv_alignof_char=1
>  ac_cv_alignof_double=8
> -
> -# at-spi2-core
> -ac_cv_alignof_dbind_pointer=8
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=8
> -
> diff --git a/meta/site/ix86-common b/meta/site/ix86-common
> index b97b2e3f60c..eae5670d937 100644
> --- a/meta/site/ix86-common
> +++ b/meta/site/ix86-common
> @@ -170,13 +170,3 @@ ac_cv_lib_c_signalfd=${ac_cv_lib_c_signalfd=yes}
>  nfsd_cv_broken_setfsuid=${nfsd_cv_broken_setfsuid=0}
>  nfsd_cv_func_statfs=${nfsd_cv_func_statfs=statfs2_bsize}
>  nfsd_cv_bsd_signals=${nfsd_cv_bsd_signals=yes}
> -
> -# at-spi2-core
> -ac_cv_alignof_char=1
> -ac_cv_alignof_dbind_pointer=4
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=4
> -ac_cv_alignof_double=4
> diff --git a/meta/site/mips-common b/meta/site/mips-common
> index ff1b7f4e5e0..55dc50beb18 100644
> --- a/meta/site/mips-common
> +++ b/meta/site/mips-common
> @@ -20,13 +20,3 @@ ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
>
>  # slrn
>  slrn_cv_va_val_copy=${slrn_cv_va_val_copy=yes}
> -
> -# at-spi2-core
> -ac_cv_alignof_char=1
> -ac_cv_alignof_dbind_pointer=4
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=8
> -ac_cv_alignof_double=8
> diff --git a/meta/site/powerpc-common b/meta/site/powerpc-common
> deleted file mode 100644
> index 02217c70f94..000
> --- a/meta/site/powerpc-common
> +++ /dev/null
> @@ -1,9 +0,0 @@
> -# at-spi2-core
> -ac_cv_alignof_char=1
> -ac_cv_alignof_dbind_pointer=4
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=8
> -ac_cv_alignof_double=8
> diff --git a/meta/site/x86_64-linux b/meta/site/x86_64-linux
> index d7b7a530ff5..b9ee141fd5c 100644
> --- a/meta/site/x86_64-linux
> +++ b/meta/site/x86_64-linux
> @@ -83,13 +83,3 @@ ac_cv_func__restgpr_14_x=no
>
>  # cvs
>  cvs_cv_func_printf_ptr=${cvs_cv_func_printf_ptr=yes}
> -
> -# at-spi2-core
> -ac_cv_alignof_char=1
> -ac_cv_alignof_dbind_pointer=8
> -ac_cv_alignof_dbind_struct=1
> -ac_cv_alignof_dbus_bool_t=4
> -ac_cv_alignof_dbus_int16_t=2
> -ac_cv_alignof_dbus_int32_t=4
> -ac_cv_alignof_dbus_int64_t=8
> -ac_cv_alignof_double=8
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177175): 
https://lists.openembedded.org/g/openembedded-core/message/177175
Mute This Topic: https://lists.openembedded.org/mt/96962710/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] Can create-spdx handle multiple components per recipe

2023-02-14 Thread Joseph Reynolds

Team,

Thanks again for continuing to improve Yocto/OE.

I have a question about the capabilities of the create-spdx.bbclass.  I 
understand it will can an sBOM entry for each recipe.


Can create-spdx.bbclass handle multiple components per recipe?  For 
example, my bitbake recipe produces a web application which packages 
many HTML components.  I would like to have the recipe included in the 
SBOM together with the components which are packaged into the web 
application files.  Is there a way to do that?


Specifically, the OpenBMC web application uses various NPM compoents to 
provide it functionality in the end-user's browser.
Recipe: 
https://github.com/openbmc/openbmc/blob/master/meta-phosphor/recipes-phosphor/webui/webui-vue_git.bb 


Project source: https://github.com/openbmc/webui-vue/
NPM packages are specified here: 
https://github.com/openbmc/webui-vue/blob/master/package-lock.json
Package-lock docs: 
https://docs.npmjs.com/cli/v9/configuring-npm/package-lock-json


I want my SBOM to include the webui-vue application together with each 
of the NPM packages it uses.
  How can I do that?


Sincerely,
Joseph Reynolds


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177174): 
https://lists.openembedded.org/g/openembedded-core/message/177174
Mute This Topic: https://lists.openembedded.org/mt/96969479/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 v3 4/4] linux-yocto: include tools for dtb in devshell

2023-02-14 Thread Trevor Woerner
Make more tools available to the user in a kernel devshell so they can test
and validate their device trees.

devshell> make dtbs_check

Signed-off-by: Trevor Woerner 
---
 meta/recipes-kernel/linux/linux-yocto.inc | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-kernel/linux/linux-yocto.inc 
b/meta/recipes-kernel/linux/linux-yocto.inc
index 091003ed8299..86046150d5c7 100644
--- a/meta/recipes-kernel/linux/linux-yocto.inc
+++ b/meta/recipes-kernel/linux/linux-yocto.inc
@@ -63,6 +63,10 @@ KERNEL_FEATURES:append:qemuall=" 
features/kernel-sample/kernel-sample.scc"
 KERNEL_DEBUG_OPTIONS ?= "stack"
 KERNEL_EXTRA_ARGS:append:x86-64 = " 
${@bb.utils.contains('KERNEL_DEBUG_OPTIONS', 'stack', 
'HOST_LIBELF_LIBS="-L${RECIPE_SYSROOT_NATIVE}/usr/lib/pkgconfig/../../../usr/lib/
 -lelf"', '', d)}"
 
+do_devshell[depends] = " \
+   python3-dtschema-native:do_populate_sysroot \
+   python3-yamllint-native:do_populate_sysroot \
+   "
 do_devshell:prepend() {
 # setup native pkg-config variables (kconfig scripts call pkg-config 
directly, cannot generically be overriden to pkg-config-native)
 d.setVar("PKG_CONFIG_DIR", 
"${STAGING_DIR_NATIVE}${libdir_native}/pkgconfig")
-- 
2.36.0.rc2.17.g4027e30c53


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177173): 
https://lists.openembedded.org/g/openembedded-core/message/177173
Mute This Topic: https://lists.openembedded.org/mt/96966813/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 v3 2/4] python3-dtschema: add dependency on dtc-pylibfdt

2023-02-14 Thread Trevor Woerner
dt-schema has a dependency on pylibfdt from dtc.

Signed-off-by: Trevor Woerner 
---
 meta/recipes-devtools/python/python3-dtschema_2023.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/python/python3-dtschema_2023.1.bb 
b/meta/recipes-devtools/python/python3-dtschema_2023.1.bb
index 9767c95d3043..7d69b568514c 100644
--- a/meta/recipes-devtools/python/python3-dtschema_2023.1.bb
+++ b/meta/recipes-devtools/python/python3-dtschema_2023.1.bb
@@ -10,6 +10,6 @@ PYPI_PACKAGE = "dtschema"
 SRC_URI[sha256sum] = 
"8fc8c269e4c57e9d008af7b32cd33b77afd4ea1ac9552bcfa96b41b9e0c52586"
 
 DEPENDS += "python3-setuptools-scm-native"
-RDEPENDS:${PN} += "python3-ruamel-yaml python3-jsonschema python3-rfc3987"
+RDEPENDS:${PN} += "python3-ruamel-yaml python3-jsonschema python3-rfc3987 
dtc-pylibfdt"
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.36.0.rc2.17.g4027e30c53


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177171): 
https://lists.openembedded.org/g/openembedded-core/message/177171
Mute This Topic: https://lists.openembedded.org/mt/96966810/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 v3 3/4] python3-yamllint: add

2023-02-14 Thread Trevor Woerner
Add a recipe for yamllint, which is used in a kernel devshell for dtb
checking.

Signed-off-by: Trevor Woerner 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../python/python3-yamllint_1.29.0.bb | 15 +++
 2 files changed, 16 insertions(+)
 create mode 100644 meta/recipes-devtools/python/python3-yamllint_1.29.0.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index ec7ea90d16a6..02aa6cb1b2cf 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -704,6 +704,7 @@ RECIPE_MAINTAINER:pn-python3-vcversioner = "Bruce Ashfield 
https://github.com/adrienverge/yamllint";
+LICENSE = "GPL-3.0-only"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1ebbd3e34237af26da5dc08a4e440464"
+
+inherit pypi setuptools3
+
+PYPI_PACKAGE = "yamllint"
+
+SRC_URI[sha256sum] = 
"66a755d5fbcbb8831f1a9568676329b5bac82c37995bcc9afd048b6459f9fa48"
+
+DEPENDS += "python3-setuptools-scm-native"
+RDEPENDS:${PN} += "python3-pyyaml"
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.36.0.rc2.17.g4027e30c53


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177172): 
https://lists.openembedded.org/g/openembedded-core/message/177172
Mute This Topic: https://lists.openembedded.org/mt/96966812/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 v3 1/4] dtc: version bump and add python wrapper

2023-02-14 Thread Trevor Woerner
Bump the version of dtc from 1.6.1 to to 1.7.0.

Add support for building the python wrapper around libfdt.

Signed-off-by: Trevor Woerner 
---
 ...tdump-fix-Werror-int-to-pointer-cast.patch | 40 ---
 meta/recipes-kernel/dtc/dtc/0001-meson.patch  | 37 +
 .../dtc/{dtc_1.6.1.bb => dtc_1.7.0.bb}| 18 +
 3 files changed, 48 insertions(+), 47 deletions(-)
 delete mode 100644 
meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
 create mode 100644 meta/recipes-kernel/dtc/dtc/0001-meson.patch
 rename meta/recipes-kernel/dtc/{dtc_1.6.1.bb => dtc_1.7.0.bb} (51%)

diff --git 
a/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch 
b/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
deleted file mode 100644
index 4c3e34b1ffd2..
--- 
a/meta/recipes-kernel/dtc/dtc/0001-fdtdump-fix-Werror-int-to-pointer-cast.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-Fix the build of fdtdump with mingw.
-
-Upstream-Status: Backport
-Signed-off-by: Ross Burton 
-
-From ae0ce1fa7f4d679b5f8df1fc0e797246e43547fe Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
-Date: Wed, 25 Aug 2021 16:13:50 +0400
-Subject: [PATCH] fdtdump: fix -Werror=int-to-pointer-cast
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-With mingw64-gcc, the compiler complains with various warnings:
-error: cast from pointer to integer of different size 
[-Werror=pointer-to-int-cast]
-
-Signed-off-by: Marc-André Lureau 
-Message-Id: <20210825121350.213551-1-marcandre.lur...@redhat.com>
-Acked-by: Rob Herring 
-Signed-off-by: David Gibson 

- fdtdump.c | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/fdtdump.c b/fdtdump.c
-index d9fb374..483f367 100644
 a/fdtdump.c
-+++ b/fdtdump.c
-@@ -21,7 +21,7 @@
- #define MAX_VERSION 17
- 
- #define ALIGN(x, a)   (((x) + ((a) - 1)) & ~((a) - 1))
--#define PALIGN(p, a)  ((void *)(ALIGN((unsigned long)(p), (a
-+#define PALIGN(p, a)  ((void *)(ALIGN((uintptr_t)(p), (a
- #define GET_CELL(p)   (p += 4, *((const fdt32_t *)(p-4)))
- 
- static const char *tagname(uint32_t tag)
--- 
-2.25.1
-
diff --git a/meta/recipes-kernel/dtc/dtc/0001-meson.patch 
b/meta/recipes-kernel/dtc/dtc/0001-meson.patch
new file mode 100644
index ..10c4f8706194
--- /dev/null
+++ b/meta/recipes-kernel/dtc/dtc/0001-meson.patch
@@ -0,0 +1,37 @@
+From faa02d4a60859089017bf92e0e3f49d600c44d73 Mon Sep 17 00:00:00 2001
+From: Trevor Woerner 
+Date: Sun, 12 Feb 2023 14:37:04 -0500
+Subject: [PATCH] allow pylibfdt in cross
+
+Allow pylibfdt to be built even in cross-development scenarios.
+
+Upstream-Status: Inappropriate [embedded specific]
+
+Signed-off-by: Trevor Woerner 
+---
+ meson.build | 8 
+ 1 file changed, 4 insertions(+), 4 deletions(-)
+
+diff --git a/meson.build b/meson.build
+index b23ea1b159b2..34a21a6dc783 100644
+--- a/meson.build
 b/meson.build
+@@ -118,11 +118,11 @@ if get_option('tools')
+   )
+ endif
+ 
+-if not meson.is_cross_build()
+-  if py.found() and swig.found()
+-subdir('pylibfdt')
+-  endif
++if py.found() and swig.found()
++  subdir('pylibfdt')
++endif
+ 
++if not meson.is_cross_build()
+   if get_option('tools')
+ subdir('tests')
+   endif
+-- 
+2.36.0.rc2.17.g4027e30c53
+
diff --git a/meta/recipes-kernel/dtc/dtc_1.6.1.bb 
b/meta/recipes-kernel/dtc/dtc_1.7.0.bb
similarity index 51%
rename from meta/recipes-kernel/dtc/dtc_1.6.1.bb
rename to meta/recipes-kernel/dtc/dtc_1.7.0.bb
index 2a6ac089a338..445bf54f8581 100644
--- a/meta/recipes-kernel/dtc/dtc_1.6.1.bb
+++ b/meta/recipes-kernel/dtc/dtc_1.7.0.bb
@@ -1,15 +1,18 @@
 SUMMARY = "Device Tree Compiler"
 HOMEPAGE = "https://devicetree.org/";
-DESCRIPTION = "The Device Tree Compiler is a tool used to manipulate the 
Open-Firmware-like device tree used by PowerPC kernels."
+DESCRIPTION = "The Device Tree Compiler is a toolchain for working with device 
tree source and binary files."
+DEPENDS = "bison-native python3-setuptools-scm-native swig-native libyaml"
 SECTION = "bootloader"
 LICENSE = "GPL-2.0-only | BSD-2-Clause"
 
 LIC_FILES_CHKSUM = "file://GPL;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
-
file://libfdt/libfdt.h;beginline=4;endline=7;md5=05bb357cfb75cae7d2b01d2ee8d76407"
+file://BSD-2-Clause;md5=5d6306d1b08f8df623178dfd81880927 \
+file://README.license;md5=a1eb22e37f09df5b5511b8a278992d0e"
 
 SRC_URI = "git://git.kernel.org/pub/scm/utils/dtc/dtc.git;branch=master \
-   file://0001-fdtdump-fix-Werror-int-to-pointer-cast.patch"
-SRCREV = "b6910bec11614980a21e46fbccc35934b671bd81"
+   file://0001-meson.patch"
+PV = "1.7.0+git${SRCPV}"
+SRCREV = "039a99414e778332d8f9c04cbd3072e1dcc62798"
 
 UPSTREAM_CHECK_GITTAGREGEX = "v(?P\d+(\.\d+)+)"
 
@@ -17,14 +20,15 @@ S = "${WORKDIR}/git"
 
 inherit meson pkgconfig
 
-EXTRA_OEMESON = "-Dpython=disabled -Dvalgrind=disa

Re: [OE-core] [PATCH] libcgroup: clean up musl DEPENDS

2023-02-14 Thread Khem Raj
On Tue, Feb 14, 2023 at 8:42 AM Ross Burton  wrote:
>
> libcgroup uses fts_* functions, but these are not implemented in musl so
> we depend on the fts recipe and force a link to libfts.
>
> However since 3.0.0 libcgroup will automatically look for fts_open in
> both libc and libfts[1], so this can be simplified to just a conditional
> DEPENDS.
>
> [1] 
> https://github.com/libcgroup/libcgroup/commit/27ba904355575153308bdc0fa48344ef1be55ca1
>

cool. LGTM

> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/libcgroup/libcgroup_3.0.0.bb | 4 +---
>  1 file changed, 1 insertion(+), 3 deletions(-)
>
> diff --git a/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb 
> b/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
> index 9937a17fb51..457b965481d 100644
> --- a/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
> +++ b/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
> @@ -10,6 +10,7 @@ LIC_FILES_CHKSUM = 
> "file://COPYING;md5=4d794c5d710e5b3547a6cc6a6609a641"
>  inherit autotools pkgconfig github-releases
>
>  DEPENDS = "bison-native flex-native"
> +DEPENDS:append:libc-musl = " fts"
>
>  SRC_URI = "${GITHUB_BASE_URI}/download/v3.0/${BP}.tar.gz \
> file://0001-api-Use-GNU-strerror_r-when-available.patch \
> @@ -18,9 +19,6 @@ UPSTREAM_CHECK_URI = 
> "https://github.com/libcgroup/libcgroup/tags";
>
>  SRC_URI[sha256sum] = 
> "8d284d896fca1c981b55850e92acd3ad9648a69227c028dda7ae3402af878edd"
>
> -DEPENDS:append:libc-musl = " fts "
> -EXTRA_OEMAKE:append:libc-musl = " LIBS=-lfts"
> -
>  PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}"
>  PACKAGECONFIG[pam] = "--enable-pam-module-dir=${base_libdir}/security 
> --enable-pam=yes,--enable-pam=no,libpam"
>
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177169): 
https://lists.openembedded.org/g/openembedded-core/message/177169
Mute This Topic: https://lists.openembedded.org/mt/96963828/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 0/1] Add support for custom annotations in SPDX

2023-02-14 Thread Saul Wold
V2 fixes commit message and adds additional check for empty
custom_var.

Additional testing with SPDX_CUSTOM_ANNOTATION_VARS:pn-${PN} and
SPDX_CUSTOM_ANNOTATION_VARS:append:pn-${PN} confirmed to work
as expected.

We will leave the variable flag handling for a future extension
of this code as needed.

Saul Wold (1):
  create-spdx-2.2: Add support for custom Annotations

 meta/classes/create-spdx-2.2.bbclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177168): 
https://lists.openembedded.org/g/openembedded-core/message/177168
Mute This Topic: https://lists.openembedded.org/mt/96964901/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 1/1] create-spdx-2.2: Add support for custom Annotations

2023-02-14 Thread Saul Wold
This change adds a new variable to track which recipe variables
are added as SPDX Annotations.

Usage: add SPDX_CUSTOM_ANNOTATION_VARS = 

The recipe spdx json will contain an annotation stanza that looks
something like this:

 "annotations": [
{
  "annotationDate": "2023-02-13T19:44:20Z",
  "annotationType": "OTHER",
  "annotator": "Tool: oe-spdx-creator - 1.0",
  "comment": "CUSTOM_VARIABLE=some value or string"
},

Signed-off-by: Saul Wold 
---
 meta/classes/create-spdx-2.2.bbclass | 8 +++-
 1 file changed, 7 insertions(+), 1 deletion(-)

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index f0513af083b..bdc2e2c91e7 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -30,6 +30,8 @@ SPDX_PRETTY ??= "0"
 
 SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"
 
+SPDX_CUSTOM_ANNOTATION_VARS ??= ""
+
 SPDX_ORG ??= "OpenEmbedded ()"
 SPDX_SUPPLIER ??= "Organization: ${SPDX_ORG}"
 SPDX_SUPPLIER[doc] = "The SPDX PackageSupplier field for SPDX packages created 
from \
@@ -402,7 +404,6 @@ def collect_dep_sources(d, dep_recipes):
 
 return sources
 
-
 python do_create_spdx() {
 from datetime import datetime, timezone
 import oe.sbom
@@ -479,6 +480,11 @@ python do_create_spdx() {
 if description:
 recipe.description = description
 
+if d.getVar("SPDX_CUSTOM_ANNOTATION_VARS"):
+for var in d.getVar("SPDX_CUSTOM_ANNOTATION_VARS").split():
+if d.getVar(var):
+recipe.annotations.append(create_annotation(d, var + "=" + 
d.getVar(var)))
+
 # Some CVEs may be patched during the build process without incrementing 
the version number,
 # so querying for CVEs based on the CPE id can lead to false positives. To 
account for this,
 # save the CVEs fixed by patches to source information field in the SPDX.
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177167): 
https://lists.openembedded.org/g/openembedded-core/message/177167
Mute This Topic: https://lists.openembedded.org/mt/96964900/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] create-spdx-2.2: Add support for custom Annotations

2023-02-14 Thread Joshua Watt


On 2/14/23 10:52, Saul Wold (local) wrote:



On 2/13/23 12:03, Joshua Watt wrote:
On Mon, Feb 13, 2023 at 1:54 PM Saul Wold  
wrote:


This change adds a new variable to track which recipe variables
are added as SPDX Annotations.

Usage: add SPDX_CUSTOME_ANNOTATION_VARS = 


nit: CUSTOM


v2 will come shortly (I will try to address the flags)


Sorry, I wasn't trying to say we needed to do that today; that was for 
posterity. I'm fine with omitting the flags and adding them in later if 
necessary; I don't have crystal ball to tell whats needed today, so it 
might be best to wait until we know.




The recipe spdx json will contain an annotation stanza that looks
something like this:

  "annotations": [
 {
   "annotationDate": "2023-02-13T19:44:20Z",
   "annotationType": "OTHER",
   "annotator": "Tool: oe-spdx-creator - 1.0",
   "comment": "CUSTOM_VARIABLE=some value or string"
 },

Signed-off-by: Saul Wold 
---
  meta/classes/create-spdx-2.2.bbclass | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass

index f0513af083b..e1bbf646ff9 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -30,6 +30,8 @@ SPDX_PRETTY ??= "0"

  SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"

+SPDX_CUSTOM_ANNOTATION_VARS ??= ""
+
  SPDX_ORG ??= "OpenEmbedded ()"
  SPDX_SUPPLIER ??= "Organization: ${SPDX_ORG}"
  SPDX_SUPPLIER[doc] = "The SPDX PackageSupplier field for SPDX 
packages created from \

@@ -402,7 +404,6 @@ def collect_dep_sources(d, dep_recipes):

  return sources

-
  python do_create_spdx() {
  from datetime import datetime, timezone
  import oe.sbom
@@ -479,6 +480,10 @@ python do_create_spdx() {
  if description:
  recipe.description = description

+    if d.getVar("SPDX_CUSTOM_ANNOTATION_VARS"):
+    for var in d.getVar('SPDX_CUSTOM_ANNOTATION_VARS').split():
+    recipe.annotations.append(create_annotation(d, var + 
"=" + d.getVar(var)))

+


Seems reasonable. If we need more configuration options, I think we
can add it later with flags, e.g.

  MY_VAR = "foo"
  MY_VAR[spdx-annotator] = "Me!"
  SPDX_CUSTOM_ANNOTATION_VARS = "MY_VAR"

What did you think the output should be here? ie what does the comment 
line contain?

Today the annotation would contain:

"comment": "MY_VAR=foo"

What should the comment line contain if a flag or multiple flags 
exists? Or the CUSTOM_ANNOTATION code only looks for one flag 
[spdx-annotator]?


"comment": "Me!=foo"

Thoughts?

Aslo, in the future if users want package annotations, we can 
probably do:


  SPDX_CUSTOM_ANNOTATION_VARS:${PN}


Do you really mean SPDX_CUSTOM_ANNOTATIONS_VARS:pn-${PN}

I tested this and it appears to work, along with the :append:pn-${PN} 
style.


Sau!


  # Some CVEs may be patched during the build process without 
incrementing the version number,
  # so querying for CVEs based on the CPE id can lead to false 
positives. To account for this,
  # save the CVEs fixed by patches to source information field 
in the SPDX.

--
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177166): 
https://lists.openembedded.org/g/openembedded-core/message/177166
Mute This Topic: https://lists.openembedded.org/mt/96944341/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 4/4] oeqa/selftest/resulttool: add test for metadata filtering on regression

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
From: Alexis Lothoré 

Introduce new tests for the metadata-based filtering added for oeselftest
results

Signed-off-by: Alexis Lothoré 
---
 .../oeqa/selftest/cases/resulttooltests.py| 121 ++
 1 file changed, 121 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/resulttooltests.py 
b/meta/lib/oeqa/selftest/cases/resulttooltests.py
index efdfd98af3..e93796e145 100644
--- a/meta/lib/oeqa/selftest/cases/resulttooltests.py
+++ b/meta/lib/oeqa/selftest/cases/resulttooltests.py
@@ -98,3 +98,124 @@ class ResultToolTests(OESelftestTestCase):
 resultutils.append_resultsdata(results, 
ResultToolTests.target_results_data, configmap=resultutils.flatten_map)
 self.assertEqual(len(results[''].keys()), 5, msg="Flattened results 
not correct %s" % str(results))
 
+def test_results_without_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86"}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertTrue(regression.can_be_compared(base_configuration, 
target_configuration),
+msg="incorrect metadata filtering, tests without 
metadata should be compared")
+
+def test_target_result_with_missing_metadata_can_not_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86",
+  "OESELFTEST_METADATA": {"run_all_tests": True,
+  "run_tests": None,
+  "skips": None,
+  "machine": None,
+  "select_tags": 
["toolchain-user", "toolchain-system"],
+  "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertFalse(regression.can_be_compared(base_configuration, 
target_configuration),
+ msg="incorrect metadata filtering, tests should not 
be compared")
+
+def test_results_with_matching_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86",
+  "OESELFTEST_METADATA": {"run_all_tests": True,
+  "run_tests": None,
+  "skips": None,
+  "machine": None,
+  "select_tags": 
["toolchain-user", "toolchain-system"],
+  "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86",
+"OESELFTEST_METADATA": {"run_all_tests": True,
+"run_tests": None,
+"skips": None,
+"machine": None,
+"select_tags": 
["toolchain-user", "toolchain-system"],
+"exclude_tags": None}}
+self.assertTrue(regression.can_be_compared(base_configuration, 
target_configuration),
+   

[OE-core] [PATCH v2 3/4] scripts/resulttool/regression: add metadata filtering for oeselftest

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
From: Alexis Lothoré 

When generating regression reports, many false positive can be observed since
some tests results are compared while the corresponding tests sets are not the
same, as it can be seen for example for oeselftest tests (oeselftest is run
multiple time but with different parameters, resulting in different tests sets)

Add a filtering mechanism in resulttool regression module to enable a better
matching between tests. The METADATA_MATCH_TABLE defines that when the TEST_TYPE
is "oeselftest", then resulttool should filter pairs based on
OESELFTEST_METADATA appended to test configuration. If metadata is absent from
"base" test results, tests are marked "comparable" to preserve compatibility
with test results which still do not have those new metadata.

Signed-off-by: Alexis Lothoré 
---
 scripts/lib/resulttool/regression.py | 34 
 1 file changed, 34 insertions(+)

diff --git a/scripts/lib/resulttool/regression.py 
b/scripts/lib/resulttool/regression.py
index 9f952951b3..64d137 100644
--- a/scripts/lib/resulttool/regression.py
+++ b/scripts/lib/resulttool/regression.py
@@ -12,6 +12,36 @@ import json
 from oeqa.utils.git import GitRepo
 import oeqa.utils.gitarchive as gitarchive
 
+METADATA_MATCH_TABLE={
+"oeselftest": "OESELFTEST_METADATA"
+}
+
+
+def metadata_matches(base_configuration, target_configuration):
+"""
+For passed base and target, check test type. If test type matches one of
+properties described in METADATA_MATCH_TABLE, compare metadata if it is
+present in base. Return true if metadata matches, or if base lacks some
+data (either TEST_TYPE or the corresponding metadata)
+"""
+test_type=base_configuration.get('TEST_TYPE')
+metadata_key=METADATA_MATCH_TABLE.get(test_type)
+if metadata_key not in base_configuration:
+return True
+
+if target_configuration.get(metadata_key) != 
base_configuration[metadata_key]:
+return False
+
+return True
+
+def can_be_compared(base_configuration, target_configuration):
+"""
+Some tests are not relevant to be compared, for example some oeselftest
+run with different tests sets or parameters. Return true if tests can be
+compared
+"""
+return metadata_matches(base_configuration, target_configuration)
+
 def compare_result(logger, base_name, target_name, base_result, target_result):
 base_result = base_result.get('result')
 target_result = target_result.get('result')
@@ -62,6 +92,8 @@ def regression_common(args, logger, base_results, 
target_results):
 # removing any pairs which match
 for c in base.copy():
 for b in target.copy():
+if not 
can_be_compared(base_results[a][c]['configuration'], 
target_results[a][b]['configuration']):
+continue
 res, resstr = compare_result(logger, c, b, 
base_results[a][c], target_results[a][b])
 if not res:
 matches.append(resstr)
@@ -71,6 +103,8 @@ def regression_common(args, logger, base_results, 
target_results):
 # Should only now see regressions, we may not be able to match 
multiple pairs directly
 for c in base:
 for b in target:
+if not 
can_be_compared(base_results[a][c]['configuration'], 
target_results[a][b]['configuration']):
+continue
 res, resstr = compare_result(logger, c, b, 
base_results[a][c], target_results[a][b])
 if res:
 regressions.append(resstr)
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177164): 
https://lists.openembedded.org/g/openembedded-core/message/177164
Mute This Topic: https://lists.openembedded.org/mt/96964073/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 2/4] oeqa/selftest/resulttooltests: fix minor typo

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
From: Alexis Lothoré 

Signed-off-by: Alexis Lothoré 
---
 meta/lib/oeqa/selftest/cases/resulttooltests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/resulttooltests.py 
b/meta/lib/oeqa/selftest/cases/resulttooltests.py
index c2e76f1a44..efdfd98af3 100644
--- a/meta/lib/oeqa/selftest/cases/resulttooltests.py
+++ b/meta/lib/oeqa/selftest/cases/resulttooltests.py
@@ -71,7 +71,7 @@ class ResultToolTests(OESelftestTestCase):
 self.assertTrue('target_result1' in 
results['runtime/mydistro/qemux86/image'], msg="Pair not correct:%s" % results)
 self.assertTrue('target_result3' in 
results['runtime/mydistro/qemux86-64/image'], msg="Pair not correct:%s" % 
results)
 
-def test_regrresion_can_get_regression_result(self):
+def test_regression_can_get_regression_result(self):
 base_result_data = {'result': {'test1': {'status': 'PASSED'},
'test2': {'status': 'PASSED'},
'test3': {'status': 'FAILED'},
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177162): 
https://lists.openembedded.org/g/openembedded-core/message/177162
Mute This Topic: https://lists.openembedded.org/mt/96964071/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 0/4] scripts/resulttool/regression: add metadata filtering

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
From: Alexis Lothoré 

This v2 does not contain any change in patches content, it only sets the From:
field correctly. Sorry for the noise.

This patch serie is a proposal linked to discussion initiated here:
https://lists.yoctoproject.org/g/automated-testing/topic/96652823#1219

After integration of some improvements on regression reporting, it has been
observed that the regression report of version 4.2_M2 is way too big. When
checking it, it appears that a big part of the report is composed of "missing
tests" (regression detected because test status changed from "PASS" to "None").
It is mostly due to oeselftest results, since oeselftest is run multiple time
for a single build, but not with the same parameters (so not the same tests
"sets"), so those test sets are not comparable.

The proposed serie introduce OSELFTEST_METADATA appended to tests results when
the TEST_TYPE is "oeselftest". An oeselftest result with those metadata looks
like this:
[...]
"configuration": {
"HOST_DISTRO": "fedora-36",
"HOST_NAME": "fedora36-ty-3",
"LAYERS": {
[...]
},
"MACHINE": "qemux86",
"STARTTIME": "20230126235248",
"TESTSERIES": "qemux86",
"TEST_TYPE": "oeselftest",
"OESELFTEST_METADATA": {
"run_all_tests": true,
"run_tests": null,
"skips": null,
"machine": null,
"select_tags": ["toolchain-user", "toolchain-system"],
"exclude_tags": null
} 
}
[...]

Additionally, the serie now makes resulttool look at a METADATA_MATCH_TABLE,
which tells that when compared test results have a specific TEST_TYPE, it should
look for some specific metadata to know if tests can be compared or not. It will
then remove all the false positive in regression reports due to tests present in
base results but not found in target results because of skipped tests/excluded
tags

* this serie prioritize retro-compatibility: if the base test is older (ie: it
does not have the needed metadata), it will consider tests as "comparable"
* additionally to tests added in oeqa test cases, some "best effort" manual
testing has been done, with the following cases:
  - run a basic test (e.g: `oeselftest -r tinfoils`), collect test result, break
test, collect result, ensure tests are compared. Change oeselftest
parameters, ensure tests are not compared
  - collect base and target tests results from 4.2_M2 regression report,
manually add new metadata to some tests, replay regression report, ensure
that regressions are kept or discarded depending on the metadata

Alexis Lothoré (4):
  scripts/oe-selftest: append metadata to tests results
  oeqa/selftest/resulttooltests: fix minor typo
  scripts/resulttool/regression: add metadata filtering for oeselftest
  oeqa/selftest/resulttool: add test for metadata filtering on
regression

 .../oeqa/selftest/cases/resulttooltests.py| 123 +-
 meta/lib/oeqa/selftest/context.py |  15 ++-
 scripts/lib/resulttool/regression.py  |  34 +
 3 files changed, 170 insertions(+), 2 deletions(-)

-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177161): 
https://lists.openembedded.org/g/openembedded-core/message/177161
Mute This Topic: https://lists.openembedded.org/mt/96964070/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH v2 1/4] scripts/oe-selftest: append metadata to tests results

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
From: Alexis Lothoré 

Many stored results TEST_TYPE are set to "oeselftest", however all those
tests are not run with the same sets of parameters, so those tests results may
not be comparable.

Attach relevant parameters as tests metadata to allow identifying tests
configuration so we can compare tests only when they are run with the same
parameters.

Signed-off-by: Alexis Lothoré 
---
 meta/lib/oeqa/selftest/context.py | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index c7dd03ce37..8cc46283ed 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -22,6 +22,17 @@ from oeqa.core.exception import OEQAPreRun, OEQATestNotFound
 
 from oeqa.utils.commands import runCmd, get_bb_vars, get_test_layer
 
+OESELFTEST_METADATA=["run_all_tests", "run_tests", "skips", "machine", 
"select_tags", "exclude_tags"]
+
+def get_oeselftest_metadata(args):
+result = {}
+raw_args = vars(args)
+for metadata in OESELFTEST_METADATA:
+if metadata in raw_args:
+result[metadata] = raw_args[metadata]
+
+return result
+
 class NonConcurrentTestSuite(unittest.TestSuite):
 def __init__(self, suite, processes, setupfunc, removefunc):
 super().__init__([suite])
@@ -334,12 +345,14 @@ class 
OESelftestTestContextExecutor(OETestContextExecutor):
 import platform
 from oeqa.utils.metadata import metadata_from_bb
 metadata = metadata_from_bb()
+oeselftest_metadata = get_oeselftest_metadata(args)
 configuration = {'TEST_TYPE': 'oeselftest',
 'STARTTIME': args.test_start_time,
 'MACHINE': self.tc.td["MACHINE"],
 'HOST_DISTRO': oe.lsb.distro_identifier().replace(' ', 
'-'),
 'HOST_NAME': metadata['hostname'],
-'LAYERS': metadata['layers']}
+'LAYERS': metadata['layers'],
+'OESELFTEST_METADATA':oeselftest_metadata}
 return configuration
 
 def get_result_id(self, configuration):
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177163): 
https://lists.openembedded.org/g/openembedded-core/message/177163
Mute This Topic: https://lists.openembedded.org/mt/96964072/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] create-spdx-2.2: Add support for custom Annotations

2023-02-14 Thread Saul Wold



On 2/13/23 12:03, Joshua Watt wrote:

On Mon, Feb 13, 2023 at 1:54 PM Saul Wold  wrote:


This change adds a new variable to track which recipe variables
are added as SPDX Annotations.

Usage: add SPDX_CUSTOME_ANNOTATION_VARS = 


nit: CUSTOM


v2 will come shortly (I will try to address the flags)


The recipe spdx json will contain an annotation stanza that looks
something like this:

  "annotations": [
 {
   "annotationDate": "2023-02-13T19:44:20Z",
   "annotationType": "OTHER",
   "annotator": "Tool: oe-spdx-creator - 1.0",
   "comment": "CUSTOM_VARIABLE=some value or string"
 },

Signed-off-by: Saul Wold 
---
  meta/classes/create-spdx-2.2.bbclass | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index f0513af083b..e1bbf646ff9 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -30,6 +30,8 @@ SPDX_PRETTY ??= "0"

  SPDX_LICENSES ??= "${COREBASE}/meta/files/spdx-licenses.json"

+SPDX_CUSTOM_ANNOTATION_VARS ??= ""
+
  SPDX_ORG ??= "OpenEmbedded ()"
  SPDX_SUPPLIER ??= "Organization: ${SPDX_ORG}"
  SPDX_SUPPLIER[doc] = "The SPDX PackageSupplier field for SPDX packages 
created from \
@@ -402,7 +404,6 @@ def collect_dep_sources(d, dep_recipes):

  return sources

-
  python do_create_spdx() {
  from datetime import datetime, timezone
  import oe.sbom
@@ -479,6 +480,10 @@ python do_create_spdx() {
  if description:
  recipe.description = description

+if d.getVar("SPDX_CUSTOM_ANNOTATION_VARS"):
+for var in d.getVar('SPDX_CUSTOM_ANNOTATION_VARS').split():
+recipe.annotations.append(create_annotation(d, var + "=" + 
d.getVar(var)))
+


Seems reasonable. If we need more configuration options, I think we
can add it later with flags, e.g.

  MY_VAR = "foo"
  MY_VAR[spdx-annotator] = "Me!"
  SPDX_CUSTOM_ANNOTATION_VARS = "MY_VAR"

What did you think the output should be here? ie what does the comment 
line contain?

Today the annotation would contain:

"comment": "MY_VAR=foo"

What should the comment line contain if a flag or multiple flags exists? 
Or the CUSTOM_ANNOTATION code only looks for one flag [spdx-annotator]?


"comment": "Me!=foo"

Thoughts?


Aslo, in the future if users want package annotations, we can probably do:

  SPDX_CUSTOM_ANNOTATION_VARS:${PN}


Do you really mean SPDX_CUSTOM_ANNOTATIONS_VARS:pn-${PN}

I tested this and it appears to work, along with the :append:pn-${PN} style.

Sau!



  # Some CVEs may be patched during the build process without incrementing 
the version number,
  # so querying for CVEs based on the CPE id can lead to false positives. 
To account for this,
  # save the CVEs fixed by patches to source information field in the SPDX.
--
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177160): 
https://lists.openembedded.org/g/openembedded-core/message/177160
Mute This Topic: https://lists.openembedded.org/mt/96944341/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 2/2] cml1: remove redundand addtask

2023-02-14 Thread Ross Burton
The configure task is added by base.bbclass, no need to do it again.

Signed-off-by: Ross Burton 
---
 meta/classes-recipe/cml1.bbclass | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/classes-recipe/cml1.bbclass b/meta/classes-recipe/cml1.bbclass
index b79091383de..a09a042c3f1 100644
--- a/meta/classes-recipe/cml1.bbclass
+++ b/meta/classes-recipe/cml1.bbclass
@@ -21,7 +21,6 @@ cml1_do_configure() {
 }
 
 EXPORT_FUNCTIONS do_configure
-addtask configure after do_unpack do_patch before do_compile
 
 inherit terminal
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177159): 
https://lists.openembedded.org/g/openembedded-core/message/177159
Mute This Topic: https://lists.openembedded.org/mt/96963918/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 1/2] lib/buildstats: handle tasks that never finished

2023-02-14 Thread Ross Burton
If a task is aborted the buildstats file isn't complete, so calculate
when the build finished and use that as a end time.

Signed-off-by: Ross Burton 
---
 scripts/lib/buildstats.py | 33 +++--
 1 file changed, 27 insertions(+), 6 deletions(-)

diff --git a/scripts/lib/buildstats.py b/scripts/lib/buildstats.py
index 3b76286ba57..fa94c655399 100644
--- a/scripts/lib/buildstats.py
+++ b/scripts/lib/buildstats.py
@@ -79,8 +79,8 @@ class BSTask(dict):
 return self['rusage']['ru_oublock']
 
 @classmethod
-def from_file(cls, buildstat_file):
-"""Read buildstat text file"""
+def from_file(cls, buildstat_file, fallback_end=0):
+"""Read buildstat text file. fallback_end is an optional end time for 
tasks that are not recorded as finishing."""
 bs_task = cls()
 log.debug("Reading task buildstats from %s", buildstat_file)
 end_time = None
@@ -108,7 +108,10 @@ class BSTask(dict):
 bs_task[ru_type][ru_key] = val
 elif key == 'Status':
 bs_task['status'] = val
-if end_time is not None and start_time is not None:
+# If the task didn't finish, fill in the fallback end time if specified
+if start_time and not end_time and fallback_end:
+end_time = fallback_end
+if start_time and end_time:
 bs_task['elapsed_time'] = end_time - start_time
 else:
 raise BSError("{} looks like a invalid buildstats 
file".format(buildstat_file))
@@ -226,15 +229,33 @@ class BuildStats(dict):
 epoch = match.group('epoch')
 return name, epoch, version, revision
 
+@staticmethod
+def parse_top_build_stats(path):
+"""
+Parse the top-level build_stats file for build-wide start and duration.
+"""
+with open(path) as fobj:
+for line in fobj.readlines():
+key, val = line.split(':', 1)
+val = val.strip()
+if key == 'Build Started':
+start = float(val)
+elif key == "Elapsed time":
+elapsed = float(val.split()[0])
+return start, elapsed
+
 @classmethod
 def from_dir(cls, path):
 """Load buildstats from a buildstats directory"""
-if not os.path.isfile(os.path.join(path, 'build_stats')):
+top_stats = os.path.join(path, 'build_stats')
+if not os.path.isfile(top_stats):
 raise BSError("{} does not look like a buildstats 
directory".format(path))
 
 log.debug("Reading buildstats directory %s", path)
-
 buildstats = cls()
+build_started, build_elapsed = 
buildstats.parse_top_build_stats(top_stats)
+build_end = build_started + build_elapsed
+
 subdirs = os.listdir(path)
 for dirname in subdirs:
 recipe_dir = os.path.join(path, dirname)
@@ -244,7 +265,7 @@ class BuildStats(dict):
 bsrecipe = BSRecipe(name, epoch, version, revision)
 for task in os.listdir(recipe_dir):
 bsrecipe.tasks[task] = BSTask.from_file(
-os.path.join(recipe_dir, task))
+os.path.join(recipe_dir, task), build_end)
 if name in buildstats:
 raise BSError("Cannot handle multiple versions of the same "
   "package ({})".format(name))
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177158): 
https://lists.openembedded.org/g/openembedded-core/message/177158
Mute This Topic: https://lists.openembedded.org/mt/96963917/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] libcgroup: clean up musl DEPENDS

2023-02-14 Thread Ross Burton
libcgroup uses fts_* functions, but these are not implemented in musl so
we depend on the fts recipe and force a link to libfts.

However since 3.0.0 libcgroup will automatically look for fts_open in
both libc and libfts[1], so this can be simplified to just a conditional
DEPENDS.

[1] 
https://github.com/libcgroup/libcgroup/commit/27ba904355575153308bdc0fa48344ef1be55ca1

Signed-off-by: Ross Burton 
---
 meta/recipes-core/libcgroup/libcgroup_3.0.0.bb | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb 
b/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
index 9937a17fb51..457b965481d 100644
--- a/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
+++ b/meta/recipes-core/libcgroup/libcgroup_3.0.0.bb
@@ -10,6 +10,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4d794c5d710e5b3547a6cc6a6609a641"
 inherit autotools pkgconfig github-releases
 
 DEPENDS = "bison-native flex-native"
+DEPENDS:append:libc-musl = " fts"
 
 SRC_URI = "${GITHUB_BASE_URI}/download/v3.0/${BP}.tar.gz \
file://0001-api-Use-GNU-strerror_r-when-available.patch \
@@ -18,9 +19,6 @@ UPSTREAM_CHECK_URI = 
"https://github.com/libcgroup/libcgroup/tags";
 
 SRC_URI[sha256sum] = 
"8d284d896fca1c981b55850e92acd3ad9648a69227c028dda7ae3402af878edd"
 
-DEPENDS:append:libc-musl = " fts "
-EXTRA_OEMAKE:append:libc-musl = " LIBS=-lfts"
-
 PACKAGECONFIG = "${@bb.utils.filter('DISTRO_FEATURES', 'pam', d)}"
 PACKAGECONFIG[pam] = "--enable-pam-module-dir=${base_libdir}/security 
--enable-pam=yes,--enable-pam=no,libpam"
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177157): 
https://lists.openembedded.org/g/openembedded-core/message/177157
Mute This Topic: https://lists.openembedded.org/mt/96963828/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] busybox: Fix excluding .debug from depmod

2023-02-14 Thread Alexandre Belloni via lists.openembedded.org
Hello,

Saul sent this on Friday:
https://lore.kernel.org/openembedded-core/20230210153255.2716448-1-saul.w...@windriver.com/

On 14/02/2023 16:17:34+0300, Anton Kikin wrote:
> The previously added patch for excluding .debug from depmod has an
> invalid expression in the condition. The strstr function returns
> NULL if substring is NOT found [1]. Therefore, the existing patch,
> on the opposite, handles only modules that have a .debug substring
> in the path. This commit fixes the condition in the patch to the
> correct one.
> 
> [1]: https://man7.org/linux/man-pages/man3/strstr.3.html
> 
> Signed-off-by: Anton Kikin 
> ---
>  .../busybox/0001-depmod-Ignore-.debug-directories.patch| 7 ---
>  1 file changed, 4 insertions(+), 3 deletions(-)
> 
> diff --git 
> a/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
>  
> b/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
> index 354f83a4a5..3398a354c5 100644
> --- 
> a/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
> +++ 
> b/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
> @@ -1,6 +1,6 @@
>  From 5f6ed003f10ee0bd4a508d5f59129a29f0920dfc Mon Sep 17 00:00:00 2001
> -From: Saul Wold 
> -Date: Thu, 31 Mar 2022 11:21:45 -0700
> +From: Anton Kikin 
> +Date: Tue, 14 Feb 2023 15:46:42 +0300
>  Subject: [PATCH] depmod: Ignore .debug directories
>  
>  The .debug/.ko files do not have the correct symbol information
> @@ -9,6 +9,7 @@ since it's split away from the actual .ko file. Just 
> ignore it.
>  Upstream-Status: Pending
>  
>  Signed-off-by: Saul Wold 
> +Signed-off-by: Anton Kikin 
>  ---
>   modutils/depmod.c | 3 +++
>   1 file changed, 3 insertions(+)
> @@ -21,7 +22,7 @@ index bb42bbe..aa5a2de 100644
>   /* Arbitrary. Was sb->st_size, but that breaks .gz etc */
>   size_t len = (64*1024*1024 - 4096);
>   
> -+if (strstr(fname, ".debug") == NULL)
> ++if (strstr(fname, ".debug"))
>  +return TRUE;
>  +
>   if (strrstr(fname, ".ko") == NULL)
> -- 
> 2.34.1.windows.1
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177156): 
https://lists.openembedded.org/g/openembedded-core/message/177156
Mute This Topic: https://lists.openembedded.org/mt/96959409/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] elfutils: Backport fix for DW_TAG_unspecified_type handling

2023-02-14 Thread Khem Raj
Re-enable funcretval tests

Signed-off-by: Khem Raj 
---
 .../elfutils/elfutils_0.188.bb|  3 +-
 .../handle_DW_TAG_unspecified_type.patch  | 88 +++
 2 files changed, 89 insertions(+), 2 deletions(-)
 create mode 100644 
meta/recipes-devtools/elfutils/files/handle_DW_TAG_unspecified_type.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.188.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.188.bb
index 182229becf..74271b2411 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.188.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.188.bb
@@ -23,6 +23,7 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \

file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \

file://0001-PR29926-debuginfod-Fix-usage-of-deprecated-CURLINFO_.patch \

file://0002-debuginfod-client-Use-CURLOPT_PROTOCOLS_STR-for-libc.patch \
+   file://handle_DW_TAG_unspecified_type.patch \
"
 SRC_URI:append:libc-musl = " \
file://0003-musl-utils.patch \
@@ -98,8 +99,6 @@ do_install_ptest() {
cp -r ${B}/debuginfod   ${D}${PTEST_PATH}
sed -i '/^Makefile:/c Makefile:'
${D}${PTEST_PATH}/tests/Makefile
find ${D}${PTEST_PATH} -type f -name *.[hoc] | xargs -i rm {}
-   # TODO: remove below filter after 
https://sourceware.org/bugzilla/show_bug.cgi?id=30047 is fixed
-   sed -i -e '/funcretval/d' 
${D}${PTEST_PATH}/tests/run-native-test.sh
fi
 }
 
diff --git 
a/meta/recipes-devtools/elfutils/files/handle_DW_TAG_unspecified_type.patch 
b/meta/recipes-devtools/elfutils/files/handle_DW_TAG_unspecified_type.patch
new file mode 100644
index 00..8cab01c29a
--- /dev/null
+++ b/meta/recipes-devtools/elfutils/files/handle_DW_TAG_unspecified_type.patch
@@ -0,0 +1,88 @@
+From: Mark Wielaard 
+Date: Thu, 26 Jan 2023 17:19:15 + (+0100)
+Subject: backends: Handle DW_TAG_unspecified_type in dwarf_peeled_die_type
+X-Git-Url: 
https://sourceware.org/git/?p=elfutils.git;a=commitdiff_plain;h=f2c522567ad63ac293535fba9704895e685ab5bc;hp=3fa98a6f29b0f370e32549ead7eb897c839af980
+
+backends: Handle DW_TAG_unspecified_type in dwarf_peeled_die_type
+
+binutils 2.40 introduces DW_TAG_unspecified_type for assembly
+functions with an unknown return type. This breaks the
+run-funcretval.sh testcase because dwfl_module_return_value_location
+returns an error for such functions because it cannot determine the
+return value location. Fix that by treating DW_TAG_unspecified_type
+as if the DIE doesn't have a DW_AT_type.
+
+Also update the testcase to explicitly checking for
+DW_TAG_unspecified_type and printing "returns unspecified type".
+
+https://sourceware.org/bugzilla/show_bug.cgi?id=30047
+
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=elfutils.git;a=commitdiff;h=f2c522567ad63ac293535fba9704895e685ab5bc;hp=3fa98a6f29b0f370e32549ead7eb897c839af980]
+Signed-off-by: Mark Wielaard 
+---
+
+--- a/backends/libebl_CPU.h
 b/backends/libebl_CPU.h
+@@ -1,5 +1,6 @@
+ /* Common interface for libebl modules.
+Copyright (C) 2000, 2001, 2002, 2003, 2005, 2013, 2014 Red Hat, Inc.
++   Copyright (C) 2023 Mark J. Wielaard 
+This file is part of elfutils.
+ 
+This file is free software; you can redistribute it and/or modify
+@@ -53,7 +54,9 @@ extern bool (*generic_debugscn_p) (const
+  dwarf_tag (_die); })
+ 
+ /* Get a type die corresponding to DIE.  Peel CV qualifiers off
+-   it.  */
++   it.  Returns zero if the DIE doesn't have a type, or the type
++   is DW_TAG_unspecified_type.  Returns -1 on error.  Otherwise
++   returns the result tag DW_AT value.  */
+ static inline int
+ dwarf_peeled_die_type (Dwarf_Die *die, Dwarf_Die *result)
+ {
+@@ -69,7 +72,14 @@ dwarf_peeled_die_type (Dwarf_Die *die, D
+   if (dwarf_peel_type (result, result) != 0)
+ return -1;
+ 
+-  return DWARF_TAG_OR_RETURN (result);
++  if (result == NULL)
++return -1;
++
++  int tag = dwarf_tag (result);
++  if (tag == DW_TAG_unspecified_type)
++return 0; /* Treat an unspecified type as if there was no type.  */
++
++  return tag;
+ }
+ 
+ #endif/* libebl_CPU.h */
+--- a/tests/funcretval.c
 b/tests/funcretval.c
+@@ -1,5 +1,6 @@
+ /* Test program for dwfl_module_return_value_location.
+Copyright (C) 2005 Red Hat, Inc.
++   Copyright (C) 2023 Mark J. Wielaard 
+This file is part of elfutils.
+ 
+This file is free software; you can redistribute it and/or modify
+@@ -67,7 +68,18 @@ handle_function (Dwarf_Die *funcdie, voi
+ error (EXIT_FAILURE, 0, "dwfl_module_return_value_location: %s",
+  dwfl_errmsg (-1));
+   else if (nlocops == 0)
+-puts ("returns no value");
++{
++  // Check if this is the special unspecified type
++  // https://sourceware.org/bugzilla/show_bug.cgi?id=30047
++  Dwarf_Die die_mem, *typedie = &die_mem;
++  Dwarf_Attribute attr_mem, *attr;

Re: [OE-core] [kirkstone][PATCH 0/1] Update webkitgtk to 2.38.4 for CVEs

2023-02-14 Thread Steve Sakoman
Stable branch policy doesn't allow this type of version upgrade.  I
can only take upgrades that are strict bug/security fix only releases.

Exceptions to the policy would require TSC approval.

Best regards,

Steve

On Sun, Feb 12, 2023 at 7:50 PM Kai Kang  wrote:
>
> From: Kai Kang 
>
> Update webkitgtk 2.36.8 to latest version 2.38.4 which solves a lot of CVEs.
>
> The diff output of header files is attached at the end of this file.
>
> Kai Kang (1):
>   webkitgtk: 2.36.8 -> 2.38.4
>
>  ...spection.cmake-prefix-variables-obta.patch |  39 +--
>  .../0001-Fix-build-without-opengl-or-es.patch | 133 
>  ...tings-so-that-gtkdoc-generation-work.patch |  47 ---
>  ...trospection-files-do-not-quote-CFLAG.patch |  78 -
>  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 ++
>  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ++
>  ...ebkitgtk_2.36.8.bb => webkitgtk_2.38.4.bb} |  15 +-
>  7 files changed, 348 insertions(+), 290 deletions(-)
>  delete mode 100644 
> meta/recipes-sato/webkit/webkitgtk/0001-Fix-build-without-opengl-or-es.patch
>  delete mode 100644 
> meta/recipes-sato/webkit/webkitgtk/0001-Tweak-gtkdoc-settings-so-that-gtkdoc-generation-work.patch
>  delete mode 100644 
> meta/recipes-sato/webkit/webkitgtk/0001-When-building-introspection-files-do-not-quote-CFLAG.patch
>  create mode 100644 
> meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
>  create mode 100644 
> meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
>  rename meta/recipes-sato/webkit/{webkitgtk_2.36.8.bb => webkitgtk_2.38.4.bb} 
> (92%)
>
> --
> 2.17.1
>
> diff -Nur 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h 
> 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h
> --- 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h  2022-06-30 
> 17:49:25.0 +0800
> +++ 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCDefines.h  2022-09-20 
> 16:13:44.0 +0800
> @@ -23,7 +23,7 @@
>   * THE POSSIBILITY OF SUCH DAMAGE.
>   */
>
> -#if !defined(__JSC_H_INSIDE__) && !defined(JSC_COMPILATION)
> +#if !defined(__JSC_H_INSIDE__) && !defined(JSC_COMPILATION) && 
> !defined(WEBKIT2_COMPILATION)
>  #error "Only  can be included directly."
>  #endif
>
> @@ -42,7 +42,9 @@
>  #define JSC_API __attribute__((visibility("default")))
>  #endif
>
> +#ifndef __GI_SCANNER__
>  #define JSC_DEPRECATED JSC_API G_DEPRECATED
>  #define JSC_DEPRECATED_FOR(f) JSC_API G_DEPRECATED_FOR(f)
> +#endif /* !__GI_SCANNER__ */
>
>  #endif /* JSCDefines_h */
> diff -Nur 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h 
> 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h
> --- 2.36.8-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h2022-06-30 
> 17:49:25.0 +0800
> +++ 2.38.4-r0/image/usr/include/webkitgtk-4.0/jsc/JSCValue.h2022-09-20 
> 16:13:44.0 +0800
> @@ -49,6 +49,21 @@
>  JSC_VALUE_PROPERTY_WRITABLE = 1 << 2
>  } JSCValuePropertyFlags;
>
> +typedef enum {
> +JSC_TYPED_ARRAY_NONE = 0,
> +JSC_TYPED_ARRAY_INT8,
> +JSC_TYPED_ARRAY_INT16,
> +JSC_TYPED_ARRAY_INT32,
> +JSC_TYPED_ARRAY_INT64,
> +JSC_TYPED_ARRAY_UINT8,
> +JSC_TYPED_ARRAY_UINT8_CLAMPED,
> +JSC_TYPED_ARRAY_UINT16,
> +JSC_TYPED_ARRAY_UINT32,
> +JSC_TYPED_ARRAY_UINT64,
> +JSC_TYPED_ARRAY_FLOAT32,
> +JSC_TYPED_ARRAY_FLOAT64,
> +} JSCTypedArrayType;
> +
>  struct _JSCValue {
>  GObject parent;
>
> @@ -246,6 +261,55 @@
>  jsc_value_function_callv  (JSCValue *value,
> guint 
> n_parameters,
> JSCValue**parameters) 
> G_GNUC_WARN_UNUSED_RESULT;
> +JSC_API JSCValue *
> +jsc_value_new_array_buffer(JSCContext   *context,
> +   gpointer  data,
> +   gsize size,
> +   GDestroyNotify
> destroy_notify,
> +   gpointer  user_data);
> +
> +JSC_API gboolean
> +jsc_value_is_array_buffer (JSCValue *value);
> +
> +JSC_API gpointer
> +jsc_value_array_buffer_get_data   (JSCValue *value,
> +   gsize*size);
> +
> +JSC_API gsize
> +jsc_value_array_buffer_get_size   (JSCValue *value);
> +
> +JSC_API JSCValue *
> +jsc_value_new_typed_array (JSCContext   *context,
> +   JSCTypedArrayType type,
> +   gsize length);
> +
> +JSC_API JSCValue *
> +jsc_value_new_typed_array_with_buffer (JSCValue 
> *array_buffer,
> +   JSCTypedArrayType type,
> + 

[OE-core] [PATCH 2/2] site: remove at-spi2-core values

2023-02-14 Thread Ross Burton
at-spi2-core is built with Meson now, so these values are not needed.

Signed-off-by: Ross Burton 
---
 meta/site/arm-32 | 10 --
 meta/site/arm-64 |  9 -
 meta/site/ix86-common| 10 --
 meta/site/mips-common| 10 --
 meta/site/powerpc-common |  9 -
 meta/site/x86_64-linux   | 10 --
 6 files changed, 58 deletions(-)
 delete mode 100644 meta/site/powerpc-common

diff --git a/meta/site/arm-32 b/meta/site/arm-32
index c6af852354e..be741617b67 100644
--- a/meta/site/arm-32
+++ b/meta/site/arm-32
@@ -6,13 +6,3 @@ ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
 
 # jikes
 ac_cv_sizeof_wchar_t=4
-
-# at-spi2-core
-ac_cv_alignof_char=1
-ac_cv_alignof_dbind_pointer=4
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=8
-ac_cv_alignof_double=8
diff --git a/meta/site/arm-64 b/meta/site/arm-64
index 79c10dab0e8..f4eae88471e 100644
--- a/meta/site/arm-64
+++ b/meta/site/arm-64
@@ -6,12 +6,3 @@ ac_cv_sizeof_size_t=8
 ac_cv_sizeof_ssize_t=8
 ac_cv_alignof_char=1
 ac_cv_alignof_double=8
-
-# at-spi2-core
-ac_cv_alignof_dbind_pointer=8
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=8
-
diff --git a/meta/site/ix86-common b/meta/site/ix86-common
index b97b2e3f60c..eae5670d937 100644
--- a/meta/site/ix86-common
+++ b/meta/site/ix86-common
@@ -170,13 +170,3 @@ ac_cv_lib_c_signalfd=${ac_cv_lib_c_signalfd=yes}
 nfsd_cv_broken_setfsuid=${nfsd_cv_broken_setfsuid=0}
 nfsd_cv_func_statfs=${nfsd_cv_func_statfs=statfs2_bsize}
 nfsd_cv_bsd_signals=${nfsd_cv_bsd_signals=yes}
-
-# at-spi2-core
-ac_cv_alignof_char=1
-ac_cv_alignof_dbind_pointer=4
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=4
-ac_cv_alignof_double=4
diff --git a/meta/site/mips-common b/meta/site/mips-common
index ff1b7f4e5e0..55dc50beb18 100644
--- a/meta/site/mips-common
+++ b/meta/site/mips-common
@@ -20,13 +20,3 @@ ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
 
 # slrn
 slrn_cv_va_val_copy=${slrn_cv_va_val_copy=yes}
-
-# at-spi2-core
-ac_cv_alignof_char=1
-ac_cv_alignof_dbind_pointer=4
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=8
-ac_cv_alignof_double=8
diff --git a/meta/site/powerpc-common b/meta/site/powerpc-common
deleted file mode 100644
index 02217c70f94..000
--- a/meta/site/powerpc-common
+++ /dev/null
@@ -1,9 +0,0 @@
-# at-spi2-core
-ac_cv_alignof_char=1
-ac_cv_alignof_dbind_pointer=4
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=8
-ac_cv_alignof_double=8
diff --git a/meta/site/x86_64-linux b/meta/site/x86_64-linux
index d7b7a530ff5..b9ee141fd5c 100644
--- a/meta/site/x86_64-linux
+++ b/meta/site/x86_64-linux
@@ -83,13 +83,3 @@ ac_cv_func__restgpr_14_x=no
 
 # cvs
 cvs_cv_func_printf_ptr=${cvs_cv_func_printf_ptr=yes}
-
-# at-spi2-core
-ac_cv_alignof_char=1
-ac_cv_alignof_dbind_pointer=8
-ac_cv_alignof_dbind_struct=1
-ac_cv_alignof_dbus_bool_t=4
-ac_cv_alignof_dbus_int16_t=2
-ac_cv_alignof_dbus_int32_t=4
-ac_cv_alignof_dbus_int64_t=8
-ac_cv_alignof_double=8
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177153): 
https://lists.openembedded.org/g/openembedded-core/message/177153
Mute This Topic: https://lists.openembedded.org/mt/96962710/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 1/2] site: remove glib site values

2023-02-14 Thread Ross Burton
GLib 1.x is incredibly obsolete and GLib 2.x is built using Meson
not autotools, so we can remove the GLib entries from the site files.

Also fix a few copy/paste typos where glib_ was used incorrectly, for example:

  ac_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}

The glib_cv_ should be ac_cv_.

Signed-off-by: Ross Burton 
---
 meta/site/arc-common  |  4 
 meta/site/arm-32  | 15 ---
 meta/site/arm-64  | 15 ---
 meta/site/arm-common  | 19 ---
 meta/site/arm-darwin  |  2 --
 meta/site/arm-darwin8 |  2 --
 meta/site/arm-linux   |  2 +-
 meta/site/armeb-linux |  2 +-
 meta/site/common-glibc| 13 -
 meta/site/common-musl |  9 -
 meta/site/ix86-common | 22 --
 meta/site/loongarch64-linux   |  4 
 meta/site/microblaze-linux| 23 ---
 meta/site/mips-common |  7 ---
 meta/site/mips-linux  | 18 --
 meta/site/mips64-linux| 22 --
 meta/site/mips64el-linux  | 22 --
 meta/site/mipsel-linux| 18 --
 meta/site/mipsisa32r6-linux   | 18 --
 meta/site/mipsisa32r6el-linux | 18 --
 meta/site/mipsisa64r6-linux   | 22 --
 meta/site/mipsisa64r6el-linux | 22 --
 meta/site/nios2-linux | 35 +--
 meta/site/powerpc-common  |  5 -
 meta/site/powerpc-linux   |  5 -
 meta/site/powerpc32-linux | 26 --
 meta/site/riscv32-linux   |  4 
 meta/site/riscv64-linux   |  4 
 meta/site/sh-common   | 33 -
 meta/site/sparc-linux |  6 --
 meta/site/x32-linux   |  3 ---
 meta/site/x86_64-linux| 22 --
 32 files changed, 3 insertions(+), 439 deletions(-)

diff --git a/meta/site/arc-common b/meta/site/arc-common
index d3c721a8bb9..5cdad0b07b0 100644
--- a/meta/site/arc-common
+++ b/meta/site/arc-common
@@ -3,9 +3,5 @@ ac_cv_alignof_guint32=4
 ac_cv_alignof_guint64=4
 ac_cv_alignof_unsigned_long=4
 
-# glib-2.0
-glib_cv_stack_grows=${glib_cv_stack_grows=no}
-glib_cv_uscore=${glib_cv_uscore=no}
-
 # startup-notification
 lf_cv_sane_realloc=${lf_cv_sane_realloc=yes}
diff --git a/meta/site/arm-32 b/meta/site/arm-32
index 60ada2e974d..c6af852354e 100644
--- a/meta/site/arm-32
+++ b/meta/site/arm-32
@@ -4,21 +4,6 @@
 ac_cv_sizeof_size_t=${ac_cv_sizeof_size_t=4}
 ac_cv_sizeof_ssize_t=${ac_cv_sizeof_ssize_t=4}
 
-# glib
-glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
-glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-
-# glib-2.0
-glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-glib_cv_sizeof_intmax_t=${glib_cv_sizeof_intmax_t=8}
-glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
-glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
-glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
-ac_cv_alignof_guint32=4
-ac_cv_alignof_guint64=8
-ac_cv_alignof_unsigned_long=4
-
 # jikes
 ac_cv_sizeof_wchar_t=4
 
diff --git a/meta/site/arm-64 b/meta/site/arm-64
index 40763fb0592..79c10dab0e8 100644
--- a/meta/site/arm-64
+++ b/meta/site/arm-64
@@ -7,21 +7,6 @@ ac_cv_sizeof_ssize_t=8
 ac_cv_alignof_char=1
 ac_cv_alignof_double=8
 
-# glib
-#glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-#glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
-#glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-
-# glib-2.0
-#glib_cv_sizeof_gmutex=${glib_cv_sizeof_gmutex=24}
-#glib_cv_sizeof_intmax_t=${glib_cv_sizeof_intmax_t=8}
-#glib_cv_sizeof_ptrdiff_t=${glib_cv_sizeof_ptrdiff_t=4}
-#glib_cv_sizeof_size_t=${glib_cv_sizeof_size_t=4}
-#glib_cv_sizeof_system_thread=${glib_cv_sizeof_system_thread=4}
-ac_cv_alignof_guint32=4
-ac_cv_alignof_guint64=8
-ac_cv_alignof_unsigned_long=8
-
 # at-spi2-core
 ac_cv_alignof_dbind_pointer=8
 ac_cv_alignof_dbind_struct=1
diff --git a/meta/site/arm-common b/meta/site/arm-common
index 4c25c82be95..18c6d422008 100644
--- a/meta/site/arm-common
+++ b/meta/site/arm-common
@@ -41,25 +41,6 @@ ac_cv_func_fnmatch_works=${ac_cv_func_fnmatch_works=yes}
 # gettext
 am_cv_func_working_getline=${am_cv_func_working_getline=yes}
 
-# glib
-glib_cv_stack_grows=${glib_cv_stack_grows=no}
-glib_cv_uscore=${glib_cv_uscore=no}
-glib_cv_use_pid_surrogate=${glib_cv_use_pid_surrogate=yes}
-glib_cv_has__inline=${glib_cv_has__inline=yes}
-glib_cv_has__inline__=${glib_cv_has__inline__=yes}
-glib_cv_hasinline=${glib_cv_hasinline=yes}
-glib_cv_sane_realloc=${glib_cv_sane_realloc=yes}
-glib_cv_uscore=${glib_cv_uscore=no}
-glib_cv_va_val_copy=${glib_cv_va_val_copy=yes}
-glib_cv_rtldglobal_broken=${glib_cv_rtldglobal_broken=no}
-glib_cv_sys_pthread_mutex_trylock_posix=${glib_cv_sys_pthread_mutex_trylock_posix=yes}
-glib_cv_s

[OE-core] Yocto Project Status 14 February 2023 (WW07)

2023-02-14 Thread Stephen Jolley
Current Dev Position: YP 4.2 M3

Next Deadline: 20th February 2023 YP 4.2 M3 Build

 

Next Team Meetings:

*   Bug Triage meeting Thursday February 16th 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday February 14th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.1.23 was built and is in QA. There was an intermittent failure
during the release build but this was a known issue recurring.
*   Next week is when M3 is due to build and this marks feature freeze
for YP 4.2.
*   We saw a number of version upgrades this week (thanks Alex Kanavin).
*   There were also improvements to our runtime testing reliability
(thanks Mikko Rapeli).
*   Of the issues discussed in

https://lists.openembedded.org/g/openembedded-core/message/176476, the
bitbake command timeout and PR serv async io issues still need to be
addressed.
*   CVE levels in master are reducing but help in resolving the
remaining issues would be appreciated.
*   We have a growing number of bugs in bugzilla, any help with them is
appreciated.

 

Ways to contribute:

*   As people are likely aware, the project has a number of components
which are either unmaintained, or have people with little to no time trying
to keep them alive. These components include: patchtest, layerindex,
devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more.
Many have open bugs. Help is welcome in trying to better look after these
components!
*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 4.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.2_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.2 Milestone Dates:

*   YP 4.2 M3 build date 2023/02/20
*   YP 4.2 M3 Release date 2023/03/03
*   YP 4.2 M4 build date 2023/04/03
*   YP 4.2 M4 Release date 2023/04/28

 

Upcoming dot releases:

*   YP 3.1.23 is built and in QA
*   YP 3.1.23 Release date 2023/02/24
*   YP 4.0.8 build date 2023/02/27
*   YP 4.0.8 Release date 2023/03/10
*   YP 4.1.3 build date 2023/03/06
*   YP 4.1.3 Release date 2023/03/17
*   YP 3.1.24 build date 2023/03/20
*   YP 3.1.24 Release date 2023/03/31
*   YP 4.0.9 build date 2023/04/10
*   YP 4.0.9 Release date 2023/04/21
*   YP 4.1.4 build date 2023/05/01
*   YP 4.1.4 Release date 2023/05/13
*   YP 3.1.25 build date 2023/05/08
*   YP 3.1.25 Release date 2023/05/19
*   YP 4.0.10 build date 2023/05/15
*   YP 4.0.10 Release date 2023/05/26

 

Tracking Metrics:

*   WDD 2407 (last week 2437) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1187 (last week 1200)
*   Patches in the Pending State: 277 (23%) [last week 280 (23%)]

*
https://autobuilder.yocto.io/pub/non-release/patchmetrics/

 

The Yocto Project's technical governance is through its Technical Steering
Committee, more information is available at:

 
https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let us know!]

Re: [OE-core] [kirkstone][PATCH] qemu: fix compile error

2023-02-14 Thread Martin Jansa
Thanks Kai,

this should fix what I've reported in:
https://lists.openembedded.org/g/openembedded-core/message/176508

once this is merged, can you please add both oe-core changes (3 qemu
patches) to dunfell as well, so that similar patch is included in both
branches? The broken version wasn't merged to dunfell after my report.

Regards,

On Tue, Feb 14, 2023 at 3:22 PM Kai Kang  wrote:

> From: Kai Kang 
>
> Backport 2 patches and rebase
> 0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch to fix
> compile error:
>
> ../qemu-6.2.0/hw/display/qxl.c: In function 'qxl_phys2virt':
> ../qemu-6.2.0/hw/display/qxl.c:1477:67: error: 'size' undeclared (first
> use in this function); did you mean 'gsize'?
>  1477 | if (!qxl_get_check_slot_offset(qxl, pqxl, &slot, &offset,
> size)) {
>   |
>  ^~~~
>   |
>  gsize
> ../qemu-6.2.0/hw/display/qxl.c:1477:67: note: each undeclared identifier
> is reported only once for each function it appears in
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-devtools/qemu/qemu.inc   |   2 +
>  ...ave-qxl_log_command-Return-early-if-.patch |  57 +
>  ...ass-requested-buffer-size-to-qxl_phy.patch | 217 ++
>  3 files changed, 276 insertions(+)
>  create mode 100644
> meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
>  create mode 100644
> meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc
> b/meta/recipes-devtools/qemu/qemu.inc
> index b68be447f1..5430718f75 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -93,6 +93,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz
> \
>
> file://0021-target-ppc-implement-xs-n-maddqp-o-xs-n-msubqp-o.patch \
> file://CVE-2022-3165.patch \
> file://CVE-2022-4144.patch \
> +
>  file://0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch \
> +
>  file://0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch \
> "
>  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>
> diff --git
> a/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
> b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
> new file mode 100644
> index 00..cd846222c9
> --- /dev/null
> +++
> b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
> @@ -0,0 +1,57 @@
> +Upstream-Status: Backport [https://github.com/qemu/qemu/commit/61c34fc]
> +
> +Signed-off-by: Kai Kang 
> +
> +From 61c34fc194b776ecadc39fb26b061331107e5599 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
> +Date: Mon, 28 Nov 2022 21:27:37 +0100
> +Subject: [PATCH] hw/display/qxl: Have qxl_log_command Return early if no
> + log_cmd handler
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Only 3 command types are logged: no need to call qxl_phys2virt()
> +for the other types. Using different cases will help to pass
> +different structure sizes to qxl_phys2virt() in a pair of commits.
> +
> +Reviewed-by: Marc-André Lureau 
> +Signed-off-by: Philippe Mathieu-Daudé 
> +Signed-off-by: Stefan Hajnoczi 
> +Message-Id: <20221128202741.4945-2-phi...@linaro.org>
> +---
> + hw/display/qxl-logger.c | 11 +++
> + 1 file changed, 11 insertions(+)
> +
> +diff --git a/hw/display/qxl-logger.c b/hw/display/qxl-logger.c
> +index 68bfa47568..1bcf803db6 100644
> +--- a/hw/display/qxl-logger.c
>  b/hw/display/qxl-logger.c
> +@@ -247,6 +247,16 @@ int qxl_log_command(PCIQXLDevice *qxl, const char
> *ring, QXLCommandExt *ext)
> + qxl_name(qxl_type, ext->cmd.type),
> + compat ? "(compat)" : "");
> +
> ++switch (ext->cmd.type) {
> ++case QXL_CMD_DRAW:
> ++break;
> ++case QXL_CMD_SURFACE:
> ++break;
> ++case QXL_CMD_CURSOR:
> ++break;
> ++default:
> ++goto out;
> ++}
> + data = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id);
> + if (!data) {
> + return 1;
> +@@ -269,6 +279,7 @@ int qxl_log_command(PCIQXLDevice *qxl, const char
> *ring, QXLCommandExt *ext)
> + qxl_log_cmd_cursor(qxl, data, ext->group_id);
> + break;
> + }
> ++out:
> + fprintf(stderr, "\n");
> + return 0;
> + }
> +--
> +2.34.1
> +
> diff --git
> a/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
> b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
> new file mode 100644
> index 00..ac51cf567a
> --- /dev/null
> +++
> b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
> @@ -0,0 +1,217 @@
> +Upstream-Status: Backport [https://github.com/qemu/qemu/commit/8efec0e]
> +
> +Backpor

[OE-core] [kirkstone][PATCH] qemu: fix compile error

2023-02-14 Thread Kai Kang
From: Kai Kang 

Backport 2 patches and rebase
0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch to fix
compile error:

../qemu-6.2.0/hw/display/qxl.c: In function 'qxl_phys2virt':
../qemu-6.2.0/hw/display/qxl.c:1477:67: error: 'size' undeclared (first use in 
this function); did you mean 'gsize'?
 1477 | if (!qxl_get_check_slot_offset(qxl, pqxl, &slot, &offset, 
size)) {
  |   ^~~~
  |   gsize
../qemu-6.2.0/hw/display/qxl.c:1477:67: note: each undeclared identifier is 
reported only once for each function it appears in

Signed-off-by: Kai Kang 
---
 meta/recipes-devtools/qemu/qemu.inc   |   2 +
 ...ave-qxl_log_command-Return-early-if-.patch |  57 +
 ...ass-requested-buffer-size-to-qxl_phy.patch | 217 ++
 3 files changed, 276 insertions(+)
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index b68be447f1..5430718f75 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -93,6 +93,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://0021-target-ppc-implement-xs-n-maddqp-o-xs-n-msubqp-o.patch \
file://CVE-2022-3165.patch \
file://CVE-2022-4144.patch \
+   
file://0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch \
+   
file://0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
new file mode 100644
index 00..cd846222c9
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Have-qxl_log_command-Return-early-if-.patch
@@ -0,0 +1,57 @@
+Upstream-Status: Backport [https://github.com/qemu/qemu/commit/61c34fc]
+
+Signed-off-by: Kai Kang 
+
+From 61c34fc194b776ecadc39fb26b061331107e5599 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Mon, 28 Nov 2022 21:27:37 +0100
+Subject: [PATCH] hw/display/qxl: Have qxl_log_command Return early if no
+ log_cmd handler
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Only 3 command types are logged: no need to call qxl_phys2virt()
+for the other types. Using different cases will help to pass
+different structure sizes to qxl_phys2virt() in a pair of commits.
+
+Reviewed-by: Marc-André Lureau 
+Signed-off-by: Philippe Mathieu-Daudé 
+Signed-off-by: Stefan Hajnoczi 
+Message-Id: <20221128202741.4945-2-phi...@linaro.org>
+---
+ hw/display/qxl-logger.c | 11 +++
+ 1 file changed, 11 insertions(+)
+
+diff --git a/hw/display/qxl-logger.c b/hw/display/qxl-logger.c
+index 68bfa47568..1bcf803db6 100644
+--- a/hw/display/qxl-logger.c
 b/hw/display/qxl-logger.c
+@@ -247,6 +247,16 @@ int qxl_log_command(PCIQXLDevice *qxl, const char *ring, 
QXLCommandExt *ext)
+ qxl_name(qxl_type, ext->cmd.type),
+ compat ? "(compat)" : "");
+ 
++switch (ext->cmd.type) {
++case QXL_CMD_DRAW:
++break;
++case QXL_CMD_SURFACE:
++break;
++case QXL_CMD_CURSOR:
++break;
++default:
++goto out;
++}
+ data = qxl_phys2virt(qxl, ext->cmd.data, ext->group_id);
+ if (!data) {
+ return 1;
+@@ -269,6 +279,7 @@ int qxl_log_command(PCIQXLDevice *qxl, const char *ring, 
QXLCommandExt *ext)
+ qxl_log_cmd_cursor(qxl, data, ext->group_id);
+ break;
+ }
++out:
+ fprintf(stderr, "\n");
+ return 0;
+ }
+-- 
+2.34.1
+
diff --git 
a/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
 
b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
new file mode 100644
index 00..ac51cf567a
--- /dev/null
+++ 
b/meta/recipes-devtools/qemu/qemu/0001-hw-display-qxl-Pass-requested-buffer-size-to-qxl_phy.patch
@@ -0,0 +1,217 @@
+Upstream-Status: Backport [https://github.com/qemu/qemu/commit/8efec0e]
+
+Backport and rebase patch to fix compile error which imported by 
CVE-2022-4144.patch:
+
+../qemu-6.2.0/hw/display/qxl.c: In function 'qxl_phys2virt':
+../qemu-6.2.0/hw/display/qxl.c:1477:67: error: 'size' undeclared (first use in 
this function); did you mean 'gsize'?
+   1477 | if (!qxl_get_check_slot_offset(qxl, pqxl, &slot, 
&offset, size)) {
+   |   
^~~~
+  

Re: [OE-core] [PATCH] kernel-yocto: fix kernel-meta data detection

2023-02-14 Thread Bruce Ashfield
Indeed.

Clearly not something anyone is using very often. Good catch on that typo!

Bruce

On Tue, Feb 14, 2023 at 5:26 AM Ulrich Ölmann  wrote:
>
> Fixes: 7ef7af5c03ba ("kernel-yocto: restore kernel-meta data detection for 
> SRC_URI elements")
> Signed-off-by: Ulrich Ölmann 
> ---
>  meta/classes-recipe/kernel-yocto.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/classes-recipe/kernel-yocto.bbclass 
> b/meta/classes-recipe/kernel-yocto.bbclass
> index 1a6695ba7e35..7de99cff5642 100644
> --- a/meta/classes-recipe/kernel-yocto.bbclass
> +++ b/meta/classes-recipe/kernel-yocto.bbclass
> @@ -212,7 +212,7 @@ do_kernel_metadata() {
> # SRC_URI. If they were supplied, we convert them into include 
> directives
> # for the update part of the process
> for f in ${feat_dirs}; do
> -   if [ -d "${WORKDIR}/$f/meta" ]; then
> +   if [ -d "${WORKDIR}/$f/kernel-meta" ]; then
> includes="$includes -I${WORKDIR}/$f/kernel-meta"
> elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
> includes="$includes -I${WORKDIR}/../oe-local-files/$f"
> --
> 2.30.2
>


-- 
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177148): 
https://lists.openembedded.org/g/openembedded-core/message/177148
Mute This Topic: https://lists.openembedded.org/mt/96956989/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support

2023-02-14 Thread Richard Purdie
On Tue, 2023-02-14 at 10:46 +0100, Enrico Jörns wrote:
> Hi Richard,
> 
> Am Freitag, dem 03.02.2023 um 14:17 + schrieb Richard Purdie:
> > On Fri, 2023-02-03 at 14:50 +0100, Marco Felsch wrote:
> > > This adds the support for the barebox bootloader to oe-core. The recipe
> > > is based on the recipe found in meta-ptx [1] with a few minor adaptions.
> > > 
> > > This basic support includes the bootloader and the target tools to
> > > interact with the bootloader. The host tools support is not part of
> > > this commit. This will be added later on as separate recipe.
> > > 
> > > [1] 
> > > https://github.com/pengutronix/meta-ptx/tree/master/recipes-bsp/barebox
> > > 
> > > Signed-off-by: Marco Felsch 
> > > ---
> > >  meta/conf/documentation.conf  |   7 +
> > >  meta/recipes-bsp/barebox/barebox.inc  | 123 ++
> > >  meta/recipes-bsp/barebox/barebox_2023.01.0.bb |   5 +
> > >  ...IMAGE_COMPRESSION-per-default-to-lz4.patch |  40 ++
> > >  4 files changed, 175 insertions(+)
> > >  create mode 100644 meta/recipes-bsp/barebox/barebox.inc
> > >  create mode 100644 meta/recipes-bsp/barebox/barebox_2023.01.0.bb
> > >  create mode 100644 
> > > meta/recipes-bsp/barebox/files/0001-pbl-set-IMAGE_COMPRESSION-per-default-
> > > to-lz4.patch
> > 
> > In order to add something to OE-Core, we need to see it being used by a
> > reasonable portion of the ecosystem. Is there enough usage of barebox
> > on common boards that justifies this?
> 
> I understand that not each and every package can and should be added to 
> OE-core, so let me provide
> my view on why adding barebox could be reasonable.
> 
> First of all, since it is a bootloader and oe-core's purpose is to provide 
> basic common recipes
> required to bring up a device, I found it to be a proper location for the 
> recipe.
> It does not add any further dependencies in the oe-core ecosystem so 
> additional maintenance should
> be limited in scope.
> 
> With over 300 individual contributors and regular monthly releases [1] I 
> would call the barebox
> bootloader a common, stable and mature project that is around since ~2009 and 
> provides support for a
> wide range of architectures, SoCs and platforms [2] including freely 
> available common boards like
> RPI, beaglebone, i.MX eval kits and UEFI in general.
> 
> Ever since, barebox has also been used by different hardware vendors (e.g. 
> [4]) and was chosen by
> Kalray [5] as their bootloader. Of course, as you know, it is always 
> difficult to have a reliable
> overview of the user base of an open source project as barebox.
> 
> So far there are already a number of barebox oe recipes around [3] that I 
> find worth to consolidate
> with adding one reference recipe to oe-core.
> 
> The question if these are sufficient arguments for adding barebox to oe-core 
> probably needs to be
> answered by the broader community, but I found it to be a good added value to 
> have a bootloader in
> oe-core that adapts many of the well-known schemes of Linux and focuses on 
> being developer-friendly
> and framework-driven.
> (Let me just drop [6] for those interested in a bit details on what I summed 
> up very roughly here.)

Fair enough, I'm open to the idea. It would be interesting/useful to
see if anyone else in the community is in favour of this or not. I'm
sure you appreciate why we need to ask the question and why we can't
just add everything! :)

The community usage does appear to be primarily phytec/ptx.

> > I noticed there is no maintainers entry being added so this will throw
> > QA errors on the autobuilder.
> 
> I would take responsibility for the recipe, backed by other barebox 
> developers here.

Ok, that helps. What about testing? I'm a bit worried that in adding
this, we'd be adding something which doesn't really get tested by the
autobuilder and is hence in an unknown state to us...

> > Also, I'm not sure adding doc varflags for individual recipe variables
> > to documentation.conf makes sense. We should probably have them in the
> > recipe or just put entries into the manual?
> 
> To be honest, this was inspired by the UBOOT_ variables that are placed in 
> documentation.conf thus
> we assumed this could be a proper place. We can simply move them into the 
> recipe to limit intrusion
> into the rest of the oe ecosystem.

There are multiple u-boot pieces so there is a slightly different case
there but even then, I think we should likely be rethinking global
variables like that which are so specific. Sadly global content isn't
something which comes for free in bitbake. I'm not keen to add to the
problem if we don't need to.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177147): 
https://lists.openembedded.org/g/openembedded-core/message/177147
Mute This Topic: https://lists.openembedded.org/mt/96956667/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lis

[OE-core] [PATCH 3/4] scripts/resulttool/regression: add metadata filtering for oeselftest

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
When generating regression reports, many false positive can be observed since
some tests results are compared while the corresponding tests sets are not the
same, as it can be seen for example for oeselftest tests (oeselftest is run
multiple time but with different parameters, resulting in different tests sets)

Add a filtering mechanism in resulttool regression module to enable a better
matching between tests. The METADATA_MATCH_TABLE defines that when the TEST_TYPE
is "oeselftest", then resulttool should filter pairs based on
OESELFTEST_METADATA appended to test configuration. If metadata is absent from
"base" test results, tests are marked "comparable" to preserve compatibility
with test results which still do not have those new metadata.

Signed-off-by: Alexis Lothoré 
---
 scripts/lib/resulttool/regression.py | 34 
 1 file changed, 34 insertions(+)

diff --git a/scripts/lib/resulttool/regression.py 
b/scripts/lib/resulttool/regression.py
index 9f952951b3..64d137 100644
--- a/scripts/lib/resulttool/regression.py
+++ b/scripts/lib/resulttool/regression.py
@@ -12,6 +12,36 @@ import json
 from oeqa.utils.git import GitRepo
 import oeqa.utils.gitarchive as gitarchive
 
+METADATA_MATCH_TABLE={
+"oeselftest": "OESELFTEST_METADATA"
+}
+
+
+def metadata_matches(base_configuration, target_configuration):
+"""
+For passed base and target, check test type. If test type matches one of
+properties described in METADATA_MATCH_TABLE, compare metadata if it is
+present in base. Return true if metadata matches, or if base lacks some
+data (either TEST_TYPE or the corresponding metadata)
+"""
+test_type=base_configuration.get('TEST_TYPE')
+metadata_key=METADATA_MATCH_TABLE.get(test_type)
+if metadata_key not in base_configuration:
+return True
+
+if target_configuration.get(metadata_key) != 
base_configuration[metadata_key]:
+return False
+
+return True
+
+def can_be_compared(base_configuration, target_configuration):
+"""
+Some tests are not relevant to be compared, for example some oeselftest
+run with different tests sets or parameters. Return true if tests can be
+compared
+"""
+return metadata_matches(base_configuration, target_configuration)
+
 def compare_result(logger, base_name, target_name, base_result, target_result):
 base_result = base_result.get('result')
 target_result = target_result.get('result')
@@ -62,6 +92,8 @@ def regression_common(args, logger, base_results, 
target_results):
 # removing any pairs which match
 for c in base.copy():
 for b in target.copy():
+if not 
can_be_compared(base_results[a][c]['configuration'], 
target_results[a][b]['configuration']):
+continue
 res, resstr = compare_result(logger, c, b, 
base_results[a][c], target_results[a][b])
 if not res:
 matches.append(resstr)
@@ -71,6 +103,8 @@ def regression_common(args, logger, base_results, 
target_results):
 # Should only now see regressions, we may not be able to match 
multiple pairs directly
 for c in base:
 for b in target:
+if not 
can_be_compared(base_results[a][c]['configuration'], 
target_results[a][b]['configuration']):
+continue
 res, resstr = compare_result(logger, c, b, 
base_results[a][c], target_results[a][b])
 if res:
 regressions.append(resstr)
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177145): 
https://lists.openembedded.org/g/openembedded-core/message/177145
Mute This Topic: https://lists.openembedded.org/mt/96960029/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] oeqa/selftest/resulttool: add test for metadata filtering on regression

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
Introduce new tests for the metadata-based filtering added for oeselftest
results

Signed-off-by: Alexis Lothoré 
---
 .../oeqa/selftest/cases/resulttooltests.py| 121 ++
 1 file changed, 121 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/resulttooltests.py 
b/meta/lib/oeqa/selftest/cases/resulttooltests.py
index efdfd98af3..e93796e145 100644
--- a/meta/lib/oeqa/selftest/cases/resulttooltests.py
+++ b/meta/lib/oeqa/selftest/cases/resulttooltests.py
@@ -98,3 +98,124 @@ class ResultToolTests(OESelftestTestCase):
 resultutils.append_resultsdata(results, 
ResultToolTests.target_results_data, configmap=resultutils.flatten_map)
 self.assertEqual(len(results[''].keys()), 5, msg="Flattened results 
not correct %s" % str(results))
 
+def test_results_without_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86"}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertTrue(regression.can_be_compared(base_configuration, 
target_configuration),
+msg="incorrect metadata filtering, tests without 
metadata should be compared")
+
+def test_target_result_with_missing_metadata_can_not_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86",
+  "OESELFTEST_METADATA": {"run_all_tests": True,
+  "run_tests": None,
+  "skips": None,
+  "machine": None,
+  "select_tags": 
["toolchain-user", "toolchain-system"],
+  "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86"}
+self.assertFalse(regression.can_be_compared(base_configuration, 
target_configuration),
+ msg="incorrect metadata filtering, tests should not 
be compared")
+
+def test_results_with_matching_metadata_can_be_compared(self):
+base_configuration = {"TEST_TYPE": "oeselftest",
+  "TESTSERIES": "series1",
+  "IMAGE_BASENAME": "image",
+  "IMAGE_PKGTYPE": "ipk",
+  "DISTRO": "mydistro",
+  "MACHINE": "qemux86",
+  "OESELFTEST_METADATA": {"run_all_tests": True,
+  "run_tests": None,
+  "skips": None,
+  "machine": None,
+  "select_tags": 
["toolchain-user", "toolchain-system"],
+  "exclude_tags": None}}
+target_configuration = {"TEST_TYPE": "oeselftest",
+"TESTSERIES": "series1",
+"IMAGE_BASENAME": "image",
+"IMAGE_PKGTYPE": "ipk",
+"DISTRO": "mydistro",
+"MACHINE": "qemux86",
+"OESELFTEST_METADATA": {"run_all_tests": True,
+"run_tests": None,
+"skips": None,
+"machine": None,
+"select_tags": 
["toolchain-user", "toolchain-system"],
+"exclude_tags": None}}
+self.assertTrue(regression.can_be_compared(base_configuration, 
target_configuration),
+ms

[OE-core] [PATCH 0/4] scripts/resulttool/regression: add metadata filtering

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
This patch serie is a proposal linked to discussion initiated here:
https://lists.yoctoproject.org/g/automated-testing/topic/96652823#1219

After integration of some improvements on regression reporting, it has been
observed that the regression report of version 4.2_M2 is way too big. When
checking it, it appears that a big part of the report is composed of "missing
tests" (regression detected because test status changed from "PASS" to "None").
It is mostly due to oeselftest results, since oeselftest is run multiple time
for a single build, but not with the same parameters (so not the same tests
"sets"), so those test sets are not comparable.

The proposed serie introduce OSELFTEST_METADATA appended to tests results when
the TEST_TYPE is "oeselftest". An oeselftest result with those metadata looks
like this:
[...]
"configuration": {
"HOST_DISTRO": "fedora-36",
"HOST_NAME": "fedora36-ty-3",
"LAYERS": {
[...]
},
"MACHINE": "qemux86",
"STARTTIME": "20230126235248",
"TESTSERIES": "qemux86",
"TEST_TYPE": "oeselftest",
"OESELFTEST_METADATA": {
"run_all_tests": true,
"run_tests": null,
"skips": null,
"machine": null,
"select_tags": ["toolchain-user", "toolchain-system"],
"exclude_tags": null
} 
}
[...]

Additionally, the serie now makes resulttool look at a METADATA_MATCH_TABLE,
which tells that when compared test results have a specific TEST_TYPE, it should
look for some specific metadata to know if tests can be compared or not. It will
then remove all the false positive in regression reports due to tests present in
base results but not found in target results because of skipped tests/excluded
tags

* this serie prioritize retro-compatibility: if the base test is older (ie: it
does not have the needed metadata), it will consider tests as "comparable"
* additionally to tests added in oeqa test cases, some "best effort" manual
testing has been done, with the following cases:
  - run a basic test (e.g: `oeselftest -r tinfoils`), collect test result, break
test, collect result, ensure tests are compared. Change oeselftest
parameters, ensure tests are not compared
  - collect base and target tests results from 4.2_M2 regression report,
manually add new metadata to some tests, replay regression report, ensure
that regressions are kept or discarded depending on the metadata

Alexis Lothoré (4):
  scripts/oe-selftest: append metadata to tests results
  oeqa/selftest/resulttooltests: fix minor typo
  scripts/resulttool/regression: add metadata filtering for oeselftest
  oeqa/selftest/resulttool: add test for metadata filtering on
regression

 .../oeqa/selftest/cases/resulttooltests.py| 123 +-
 meta/lib/oeqa/selftest/context.py |  15 ++-
 scripts/lib/resulttool/regression.py  |  34 +
 3 files changed, 170 insertions(+), 2 deletions(-)

-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177144): 
https://lists.openembedded.org/g/openembedded-core/message/177144
Mute This Topic: https://lists.openembedded.org/mt/96960028/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] scripts/oe-selftest: append metadata to tests results

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
Many stored results TEST_TYPE are set to "oeselftest", however all those
tests are not run with the same sets of parameters, so those tests results may
not be comparable.

Attach relevant parameters as tests metadata to allow identifying tests
configuration so we can compare tests only when they are run with the same
parameters.

Signed-off-by: Alexis Lothoré 
---
 meta/lib/oeqa/selftest/context.py | 15 ++-
 1 file changed, 14 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index c7dd03ce37..8cc46283ed 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -22,6 +22,17 @@ from oeqa.core.exception import OEQAPreRun, OEQATestNotFound
 
 from oeqa.utils.commands import runCmd, get_bb_vars, get_test_layer
 
+OESELFTEST_METADATA=["run_all_tests", "run_tests", "skips", "machine", 
"select_tags", "exclude_tags"]
+
+def get_oeselftest_metadata(args):
+result = {}
+raw_args = vars(args)
+for metadata in OESELFTEST_METADATA:
+if metadata in raw_args:
+result[metadata] = raw_args[metadata]
+
+return result
+
 class NonConcurrentTestSuite(unittest.TestSuite):
 def __init__(self, suite, processes, setupfunc, removefunc):
 super().__init__([suite])
@@ -334,12 +345,14 @@ class 
OESelftestTestContextExecutor(OETestContextExecutor):
 import platform
 from oeqa.utils.metadata import metadata_from_bb
 metadata = metadata_from_bb()
+oeselftest_metadata = get_oeselftest_metadata(args)
 configuration = {'TEST_TYPE': 'oeselftest',
 'STARTTIME': args.test_start_time,
 'MACHINE': self.tc.td["MACHINE"],
 'HOST_DISTRO': oe.lsb.distro_identifier().replace(' ', 
'-'),
 'HOST_NAME': metadata['hostname'],
-'LAYERS': metadata['layers']}
+'LAYERS': metadata['layers'],
+'OESELFTEST_METADATA':oeselftest_metadata}
 return configuration
 
 def get_result_id(self, configuration):
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177142): 
https://lists.openembedded.org/g/openembedded-core/message/177142
Mute This Topic: https://lists.openembedded.org/mt/96960026/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/4] oeqa/selftest/resulttooltests: fix minor typo

2023-02-14 Thread Alexis Lothoré via lists . openembedded . org
Signed-off-by: Alexis Lothoré 
---
 meta/lib/oeqa/selftest/cases/resulttooltests.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/resulttooltests.py 
b/meta/lib/oeqa/selftest/cases/resulttooltests.py
index c2e76f1a44..efdfd98af3 100644
--- a/meta/lib/oeqa/selftest/cases/resulttooltests.py
+++ b/meta/lib/oeqa/selftest/cases/resulttooltests.py
@@ -71,7 +71,7 @@ class ResultToolTests(OESelftestTestCase):
 self.assertTrue('target_result1' in 
results['runtime/mydistro/qemux86/image'], msg="Pair not correct:%s" % results)
 self.assertTrue('target_result3' in 
results['runtime/mydistro/qemux86-64/image'], msg="Pair not correct:%s" % 
results)
 
-def test_regrresion_can_get_regression_result(self):
+def test_regression_can_get_regression_result(self):
 base_result_data = {'result': {'test1': {'status': 'PASSED'},
'test2': {'status': 'PASSED'},
'test3': {'status': 'FAILED'},
-- 
2.39.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177143): 
https://lists.openembedded.org/g/openembedded-core/message/177143
Mute This Topic: https://lists.openembedded.org/mt/96960027/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] busybox: Fix excluding .debug from depmod

2023-02-14 Thread Anton Kikin
The previously added patch for excluding .debug from depmod has an
invalid expression in the condition. The strstr function returns
NULL if substring is NOT found [1]. Therefore, the existing patch,
on the opposite, handles only modules that have a .debug substring
in the path. This commit fixes the condition in the patch to the
correct one.

[1]: https://man7.org/linux/man-pages/man3/strstr.3.html

Signed-off-by: Anton Kikin 
---
 .../busybox/0001-depmod-Ignore-.debug-directories.patch| 7 ---
 1 file changed, 4 insertions(+), 3 deletions(-)

diff --git 
a/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch 
b/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
index 354f83a4a5..3398a354c5 100644
--- 
a/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
+++ 
b/meta/recipes-core/busybox/busybox/0001-depmod-Ignore-.debug-directories.patch
@@ -1,6 +1,6 @@
 From 5f6ed003f10ee0bd4a508d5f59129a29f0920dfc Mon Sep 17 00:00:00 2001
-From: Saul Wold 
-Date: Thu, 31 Mar 2022 11:21:45 -0700
+From: Anton Kikin 
+Date: Tue, 14 Feb 2023 15:46:42 +0300
 Subject: [PATCH] depmod: Ignore .debug directories
 
 The .debug/.ko files do not have the correct symbol information
@@ -9,6 +9,7 @@ since it's split away from the actual .ko file. Just 
ignore it.
 Upstream-Status: Pending
 
 Signed-off-by: Saul Wold 
+Signed-off-by: Anton Kikin 
 ---
  modutils/depmod.c | 3 +++
  1 file changed, 3 insertions(+)
@@ -21,7 +22,7 @@ index bb42bbe..aa5a2de 100644
/* Arbitrary. Was sb->st_size, but that breaks .gz etc */
size_t len = (64*1024*1024 - 4096);
  
-+  if (strstr(fname, ".debug") == NULL)
++  if (strstr(fname, ".debug"))
 +  return TRUE;
 +
if (strrstr(fname, ".ko") == NULL)
-- 
2.34.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177141): 
https://lists.openembedded.org/g/openembedded-core/message/177141
Mute This Topic: https://lists.openembedded.org/mt/96959409/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/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Robert Yang



On 2/14/23 18:38, Alexander Kanavin wrote:

On Tue, 14 Feb 2023 at 10:12, Robert Yang  wrote:

This is used for online package feeds (When PACKAGE_FEED_URIS is set), the
default PACKAGE_FEED_ARCHS is None, so "dnf install/upgrade" or "apt-get update"
doesn't work by default, we must set PACKAGE_FEED_ARCHS to make it work, but
it's hard to maintain PACKAGE_FEED_ARCHS manually since we can't add more/less
archs:

1) When add less archs in PACKAGE_FEED_ARCHS, "dnf update" can't find the missed
packages.

2) When add more archs in PACKAGE_FEED_ARCHS, "dnf upgrade" will report
"can't find package feed" errors.

We must set the accurate package feed archs to make it work correctly, but
different builds may have different values since recipes can set PACKAGE_ARCH.
Set it automatically (when not set manually) can make it work smoothly.


Tests for online package feeds exist in
meta/lib/oeqa/selftest/cases/runtime_test.py and they work without
setting PACKAGE_FEED_ARCHS, so something isn't quite right on your
side, or the tests aren't covering your local setup (and maybe need to
be extended for it).


Thanks, I will look into it on why it works.

// Robert



As I said, you need to tweak existing code that handles empty
PACKAGE_FEED_ARCHS, not add a whole another overlay function that
clobbers that.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177140): 
https://lists.openembedded.org/g/openembedded-core/message/177140
Mute This Topic: https://lists.openembedded.org/mt/96955951/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/1] libseccomp: fix for the ptest result format

2023-02-14 Thread Narpat Mali
The output of libseccomp ptest should follow a unified format as
per this https://wiki.yoctoproject.org/wiki/Ptest

Replaced the test results SUCCESS, FAILURE & SKIPPPED with PASS,
FAIL & SKIP and printing the ptest result with the below format
result: testname

Signed-off-by: Narpat Mali 
---
 meta/recipes-support/libseccomp/files/run-ptest | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/recipes-support/libseccomp/files/run-ptest 
b/meta/recipes-support/libseccomp/files/run-ptest
index 54b4a63cd2..63c79f09c4 100644
--- a/meta/recipes-support/libseccomp/files/run-ptest
+++ b/meta/recipes-support/libseccomp/files/run-ptest
@@ -1,4 +1,7 @@
 #!/bin/sh
 
 cd tests
+sed -i 's/SUCCESS/PASS/g; s/FAILURE/FAIL/g; s/SKIPPED/SKIP/g' regression
+sed -i 's/"Test %s result:   %s\\n" "$1" "$2"/"%s: %s\\n" "$2" "$1"/g' 
regression
+sed -i 's/"Test %s result:   %s %s\\n" "$1" "$2" "$3"/"%s: %s %s\\n" "$2" "$1" 
"$3"/g' regression
 ./regression -a
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177139): 
https://lists.openembedded.org/g/openembedded-core/message/177139
Mute This Topic: https://lists.openembedded.org/mt/96957247/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/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Alexander Kanavin
On Tue, 14 Feb 2023 at 10:12, Robert Yang  wrote:
> This is used for online package feeds (When PACKAGE_FEED_URIS is set), the
> default PACKAGE_FEED_ARCHS is None, so "dnf install/upgrade" or "apt-get 
> update"
> doesn't work by default, we must set PACKAGE_FEED_ARCHS to make it work, but
> it's hard to maintain PACKAGE_FEED_ARCHS manually since we can't add more/less
> archs:
>
> 1) When add less archs in PACKAGE_FEED_ARCHS, "dnf update" can't find the 
> missed
> packages.
>
> 2) When add more archs in PACKAGE_FEED_ARCHS, "dnf upgrade" will report
> "can't find package feed" errors.
>
> We must set the accurate package feed archs to make it work correctly, but
> different builds may have different values since recipes can set PACKAGE_ARCH.
> Set it automatically (when not set manually) can make it work smoothly.

Tests for online package feeds exist in
meta/lib/oeqa/selftest/cases/runtime_test.py and they work without
setting PACKAGE_FEED_ARCHS, so something isn't quite right on your
side, or the tests aren't covering your local setup (and maybe need to
be extended for it).

As I said, you need to tweak existing code that handles empty
PACKAGE_FEED_ARCHS, not add a whole another overlay function that
clobbers that.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177138): 
https://lists.openembedded.org/g/openembedded-core/message/177138
Mute This Topic: https://lists.openembedded.org/mt/96955951/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] kernel-yocto: fix kernel-meta data detection

2023-02-14 Thread Ulrich Ölmann
Fixes: 7ef7af5c03ba ("kernel-yocto: restore kernel-meta data detection for 
SRC_URI elements")
Signed-off-by: Ulrich Ölmann 
---
 meta/classes-recipe/kernel-yocto.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/kernel-yocto.bbclass 
b/meta/classes-recipe/kernel-yocto.bbclass
index 1a6695ba7e35..7de99cff5642 100644
--- a/meta/classes-recipe/kernel-yocto.bbclass
+++ b/meta/classes-recipe/kernel-yocto.bbclass
@@ -212,7 +212,7 @@ do_kernel_metadata() {
# SRC_URI. If they were supplied, we convert them into include 
directives
# for the update part of the process
for f in ${feat_dirs}; do
-   if [ -d "${WORKDIR}/$f/meta" ]; then
+   if [ -d "${WORKDIR}/$f/kernel-meta" ]; then
includes="$includes -I${WORKDIR}/$f/kernel-meta"
elif [ -d "${WORKDIR}/../oe-local-files/$f" ]; then
includes="$includes -I${WORKDIR}/../oe-local-files/$f"
-- 
2.30.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177137): 
https://lists.openembedded.org/g/openembedded-core/message/177137
Mute This Topic: https://lists.openembedded.org/mt/96956989/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



Re: [yocto] [OE-core] [PATCH 1/2] barebox: add initial support

2023-02-14 Thread Enrico Jörns
Hi Richard,

Am Freitag, dem 03.02.2023 um 14:17 + schrieb Richard Purdie:
> On Fri, 2023-02-03 at 14:50 +0100, Marco Felsch wrote:
> > This adds the support for the barebox bootloader to oe-core. The recipe
> > is based on the recipe found in meta-ptx [1] with a few minor adaptions.
> > 
> > This basic support includes the bootloader and the target tools to
> > interact with the bootloader. The host tools support is not part of
> > this commit. This will be added later on as separate recipe.
> > 
> > [1] https://github.com/pengutronix/meta-ptx/tree/master/recipes-bsp/barebox
> > 
> > Signed-off-by: Marco Felsch 
> > ---
> >  meta/conf/documentation.conf  |   7 +
> >  meta/recipes-bsp/barebox/barebox.inc  | 123 ++
> >  meta/recipes-bsp/barebox/barebox_2023.01.0.bb |   5 +
> >  ...IMAGE_COMPRESSION-per-default-to-lz4.patch |  40 ++
> >  4 files changed, 175 insertions(+)
> >  create mode 100644 meta/recipes-bsp/barebox/barebox.inc
> >  create mode 100644 meta/recipes-bsp/barebox/barebox_2023.01.0.bb
> >  create mode 100644 
> > meta/recipes-bsp/barebox/files/0001-pbl-set-IMAGE_COMPRESSION-per-default-
> > to-lz4.patch
> 
> In order to add something to OE-Core, we need to see it being used by a
> reasonable portion of the ecosystem. Is there enough usage of barebox
> on common boards that justifies this?

I understand that not each and every package can and should be added to 
OE-core, so let me provide
my view on why adding barebox could be reasonable.

First of all, since it is a bootloader and oe-core's purpose is to provide 
basic common recipes
required to bring up a device, I found it to be a proper location for the 
recipe.
It does not add any further dependencies in the oe-core ecosystem so additional 
maintenance should
be limited in scope.

With over 300 individual contributors and regular monthly releases [1] I would 
call the barebox
bootloader a common, stable and mature project that is around since ~2009 and 
provides support for a
wide range of architectures, SoCs and platforms [2] including freely available 
common boards like
RPI, beaglebone, i.MX eval kits and UEFI in general.

Ever since, barebox has also been used by different hardware vendors (e.g. [4]) 
and was chosen by
Kalray [5] as their bootloader. Of course, as you know, it is always difficult 
to have a reliable
overview of the user base of an open source project as barebox.

So far there are already a number of barebox oe recipes around [3] that I find 
worth to consolidate
with adding one reference recipe to oe-core.


The question if these are sufficient arguments for adding barebox to oe-core 
probably needs to be
answered by the broader community, but I found it to be a good added value to 
have a bootloader in
oe-core that adapts many of the well-known schemes of Linux and focuses on 
being developer-friendly
and framework-driven.
(Let me just drop [6] for those interested in a bit details on what I summed up 
very roughly here.)

> I noticed there is no maintainers entry being added so this will throw
> QA errors on the autobuilder.

I would take responsibility for the recipe, backed by other barebox developers 
here.

> Also, I'm not sure adding doc varflags for individual recipe variables
> to documentation.conf makes sense. We should probably have them in the
> recipe or just put entries into the manual?

To be honest, this was inspired by the UBOOT_ variables that are placed in 
documentation.conf thus
we assumed this could be a proper place. We can simply move them into the 
recipe to limit intrusion
into the rest of the oe ecosystem.


Many thanks for your initial thoughts! Best regards,

Enrico

> Cheers,
> 
> Richard


[1] https://barebox.org/download/
[2] https://barebox.org/doc/latest/boards.html
[3] http://layers.openembedded.org/layerindex/branch/master/recipes/?q=barebox
[4] https://www.phytec.eu/en/cdocuments/?doc=YQ4RCg
[5] https://en.wikipedia.org/wiki/Kalray
[6] https://www.youtube.com/watch?v=fru1n54s2W4&ab_channel=TheLinuxFoundation

-- 
Pengutronix e.K.   | Enrico Jörns|
Embedded Linux Consulting & Support| https://www.pengutronix.de/ |
Steuerwalder Str. 21   | Phone: +49-5121-206917-180  |
31137 Hildesheim, Germany  | Fax:   +49-5121-206917-9|


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177136): 
https://lists.openembedded.org/g/openembedded-core/message/177136
Mute This Topic: https://lists.openembedded.org/mt/96956667/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/1] base.bbclass: Fix dangling NATIVELSBSTRING

2023-02-14 Thread Robert Yang

Hi RP,

On 2/14/23 16:44, Richard Purdie wrote:

On Tue, 2023-02-14 at 00:28 -0800, Robert Yang wrote:

Fixed:
$ rm -fr tmp; bitbake quilt-native -n
Build Configuration:
[snip]
NATIVELSBSTRING  = "ubuntu-18.04"
[snip]

And when run bitbake again:
$ bitbake quilt-native -n
Build Configuration:
NATIVELSBSTRING  = "universal"

It has been changed from ubuntu-18.04 to universal on the same host and build
directory, this is because it is overridded by NATIVELSBSTRING. This patch
makes it print the correct value.

Signed-off-by: Robert Yang 
---
  meta/classes-global/base.bbclass | 7 ++-
  1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index 64e805c947..cf42d9d4d2 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -226,7 +226,12 @@ BUILDCFG_FUNCS[type] = "list"
  def buildcfg_vars(d):
  statusvars = oe.data.typed_value('BUILDCFG_VARS', d)
  for var in statusvars:
-value = d.getVar(var)
+# NATIVELSBSTRING var may have been overridden with "universal", so
+# get actual host distribution id and version
+if var == 'NATIVELSBSTRING':
+value = lsb_distro_identifier(d)
+else:
+value = d.getVar(var)
  if value is not None:
  yield '%-20s = "%s"' % (var, value)


The uninative code runs "late" and this is an known issue, there is an
open bug for it if I remember correctly.

I don't really want to put hacks into the BUILDCFG display code to work
around it since it is just going to make it less clear what is going on
and is also likely to break if we evern change the way NATIVELSBSTRING
is set. If you really don't like this, we should fix it properly some
other way rather than work around it.


I'd like to drop the patch since it doesn't affect the build.

// Robert



Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177135): 
https://lists.openembedded.org/g/openembedded-core/message/177135
Mute This Topic: https://lists.openembedded.org/mt/96955945/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/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Richard Purdie
On Tue, 2023-02-14 at 00:28 -0800, Robert Yang wrote:
> The PACKAGE_FEED_ARCHS is highly related to ALL_MULTILIB_PACKAGE_ARCHS, set it
> automatically is better than manually, for example, we may forget to upgrade
> PACKAGE_FEED_ARCHS when ALL_MULTILIB_PACKAGE_ARCHS is changed if set it
> manually.
> 
> The workflow is:
> Use PACKAGE_FEED_ARCHS if it is defined, if not, check DEPLOY_DIR_XXX/, 
> add
>  to PACKAGE_FEED_ARCHS if it exists.

This says what the code does, which I can see from the patch. What this
doesn't say is *why*. 

What issue is this change needed for? When would we currently need to
set these things manually?

The multilib variables are not really meant to be used in generic code
and the multilib classes are meant to to be getting in the way like
this. Does this mean multilib is not setting up something correctly?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177131): 
https://lists.openembedded.org/g/openembedded-core/message/177131
Mute This Topic: https://lists.openembedded.org/mt/96955951/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/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Alexander Kanavin
On Tue, 14 Feb 2023 at 09:28, Robert Yang  wrote:
>  self.pm.insert_feeds_uris(self.d.getVar('PACKAGE_FEED_URIS') or 
> "",
>  self.d.getVar('PACKAGE_FEED_BASE_PATHS') or "",
> -self.d.getVar('PACKAGE_FEED_ARCHS'))
> +self._get_feed_archs())

I have to say no to this. All three package manager-specific
implementations of this function already handle the case of
PACKAGE_FEED_ARCHS not being set. Are they doing the right thing? If
they do, then this should not be necessary. If they do not, then the
code in those implementations should be fixed,but not overriden like
the patch does.

Also, rootfs.py should not be mentioning any specific packaging
format, that's what those classes are for.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177130): 
https://lists.openembedded.org/g/openembedded-core/message/177130
Mute This Topic: https://lists.openembedded.org/mt/96955951/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/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Robert Yang

Hi RP and Alexander,

On 2/14/23 16:47, Richard Purdie wrote:

On Tue, 2023-02-14 at 00:28 -0800, Robert Yang wrote:

The PACKAGE_FEED_ARCHS is highly related to ALL_MULTILIB_PACKAGE_ARCHS, set it
automatically is better than manually, for example, we may forget to upgrade
PACKAGE_FEED_ARCHS when ALL_MULTILIB_PACKAGE_ARCHS is changed if set it
manually.

The workflow is:
Use PACKAGE_FEED_ARCHS if it is defined, if not, check DEPLOY_DIR_XXX/, 
add
 to PACKAGE_FEED_ARCHS if it exists.


This says what the code does, which I can see from the patch. What this
doesn't say is *why*.

What issue is this change needed for? When would we currently need to
set these things manually?


This is used for online package feeds (When PACKAGE_FEED_URIS is set), the
default PACKAGE_FEED_ARCHS is None, so "dnf install/upgrade" or "apt-get update"
doesn't work by default, we must set PACKAGE_FEED_ARCHS to make it work, but
it's hard to maintain PACKAGE_FEED_ARCHS manually since we can't add more/less 
archs:


1) When add less archs in PACKAGE_FEED_ARCHS, "dnf update" can't find the missed 
packages.


2) When add more archs in PACKAGE_FEED_ARCHS, "dnf upgrade" will report
"can't find package feed" errors.

We must set the accurate package feed archs to make it work correctly, but
different builds may have different values since recipes can set PACKAGE_ARCH.
Set it automatically (when not set manually) can make it work smoothly.



The multilib variables are not really meant to be used in generic code
and the multilib classes are meant to to be getting in the way like
this. Does this mean multilib is not setting up something correctly?


No, multilib works correctly, I just use it find archs in DEPLOY_DIR.

// Robert



Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177134): 
https://lists.openembedded.org/g/openembedded-core/message/177134
Mute This Topic: https://lists.openembedded.org/mt/96955951/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/1] base.bbclass: Fix dangling NATIVELSBSTRING

2023-02-14 Thread Richard Purdie
On Tue, 2023-02-14 at 00:28 -0800, Robert Yang wrote:
> Fixed:
> $ rm -fr tmp; bitbake quilt-native -n
> Build Configuration:
> [snip]
> NATIVELSBSTRING  = "ubuntu-18.04"
> [snip]
> 
> And when run bitbake again:
> $ bitbake quilt-native -n
> Build Configuration:
> NATIVELSBSTRING  = "universal"
> 
> It has been changed from ubuntu-18.04 to universal on the same host and build
> directory, this is because it is overridded by NATIVELSBSTRING. This patch
> makes it print the correct value.
> 
> Signed-off-by: Robert Yang 
> ---
>  meta/classes-global/base.bbclass | 7 ++-
>  1 file changed, 6 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes-global/base.bbclass 
> b/meta/classes-global/base.bbclass
> index 64e805c947..cf42d9d4d2 100644
> --- a/meta/classes-global/base.bbclass
> +++ b/meta/classes-global/base.bbclass
> @@ -226,7 +226,12 @@ BUILDCFG_FUNCS[type] = "list"
>  def buildcfg_vars(d):
>  statusvars = oe.data.typed_value('BUILDCFG_VARS', d)
>  for var in statusvars:
> -value = d.getVar(var)
> +# NATIVELSBSTRING var may have been overridden with "universal", so
> +# get actual host distribution id and version
> +if var == 'NATIVELSBSTRING':
> +value = lsb_distro_identifier(d)
> +else:
> +value = d.getVar(var)
>  if value is not None:
>  yield '%-20s = "%s"' % (var, value)

The uninative code runs "late" and this is an known issue, there is an
open bug for it if I remember correctly. 

I don't really want to put hacks into the BUILDCFG display code to work
around it since it is just going to make it less clear what is going on
and is also likely to break if we evern change the way NATIVELSBSTRING
is set. If you really don't like this, we should fix it properly some
other way rather than work around it.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177129): 
https://lists.openembedded.org/g/openembedded-core/message/177129
Mute This Topic: https://lists.openembedded.org/mt/96955945/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][master][kirkstone][PATCH] dhcpcd: fix dhcpcd start failure on qemuppc64

2023-02-14 Thread Alexandre Belloni via lists.openembedded.org
On 14/02/2023 16:32:54+0800, Xiangyu Chen wrote:
> 
> On 2/10/23 10:18, Xiangyu Chen wrote:
> > From: Xiangyu Chen 
> > 
> > Backport patch to fix dhcpcd start failed on qemuppc64.
> 
> Friendly ping, thanks.


You sent this patch 4 days ago, over the weekend, maybe you should have
more patience. Also, you tagged that both master and kirkstone which
will not pass the usual filters as I will drop anything that is for the
stable branches.
> 
> 
> > 
> > Signed-off-by: Xiangyu Chen 
> > ---
> >   .../dhcpcd/dhcpcd_9.4.1.bb|  1 +
> >   ...x-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch | 34 +++
> >   2 files changed, 35 insertions(+)
> >   create mode 100644 
> > meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
> > 
> > diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb 
> > b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
> > index 5cf77fa0f6..39e689d2f6 100644
> > --- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
> > +++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
> > @@ -16,6 +16,7 @@ SRC_URI = 
> > "https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \
> >  
> > file://0001-20-resolv.conf-improve-the-sitation-of-working-with-.patch \
> >  
> > file://0001-privsep-Allow-getrandom-sysctl-for-newer-glibc.patch \
> >  file://0002-privsep-Allow-newfstatat-syscall-as-well.patch \
> > +   
> > file://0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch \
> >  file://dhcpcd.service \
> >  file://dhcpcd@.service \
> >  "
> > diff --git 
> > a/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
> >  
> > b/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
> > new file mode 100644
> > index 00..1c514f9b8c
> > --- /dev/null
> > +++ 
> > b/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
> > @@ -0,0 +1,34 @@
> > +From 7a2d9767585ed2c407d4985bd2d81552034fb90a Mon Sep 17 00:00:00 2001
> > +From: CHEN Xiangyu 
> > +Date: Thu, 9 Feb 2023 18:41:52 +0800
> > +Subject: [PATCH] privsep-linux: fix SECCOMP_AUDIT_ARCH missing ppc64le 
> > (#181)
> > +
> > +when dhcpcd running on ppc64le platform, it would be killed by SIGSYS.
> > +
> > +Upstream-Status: Backport [7a2d9767585ed2c407d4985bd2d81552034fb90a]
> > +
> > +Signed-off-by: Xiangyu Chen 
> > +---
> > + src/privsep-linux.c | 6 +-
> > + 1 file changed, 5 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/src/privsep-linux.c b/src/privsep-linux.c
> > +index 7372d26b..6a301950 100644
> > +--- a/src/privsep-linux.c
> >  b/src/privsep-linux.c
> > +@@ -232,7 +232,11 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int 
> > protocol, struct msghdr *msg)
> > + #elif defined(__or1k__)
> > + #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_OPENRISC
> > + #elif defined(__powerpc64__)
> > +-#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64
> > ++#  if (BYTE_ORDER == LITTLE_ENDIAN)
> > ++#define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64LE
> > ++#  else
> > ++#define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64
> > ++#  endif
> > + #elif defined(__powerpc__)
> > + #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC
> > + #elif defined(__riscv)
> > +--
> > +2.34.1
> > +
> > 
> > 
> > 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177133): 
https://lists.openembedded.org/g/openembedded-core/message/177133
Mute This Topic: https://lists.openembedded.org/mt/96868623/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] meta/lib/oeqa/selftest/cases/wic: Add tests for configuring kernel image install into boot partition.

2023-02-14 Thread Alexandre Belloni via lists.openembedded.org
Hello,

This fails on the autobuilders:

2023-02-14 02:00:37,111 - oe-selftest - INFO - 6: 47/60 496/512 (18.80s) (0 
failed) (wic.Wic.test_kernel_install)
2023-02-14 02:00:37,111 - oe-selftest - INFO - 
testtools.testresult.real._StringException: Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/selftest/cases/wic.py",
 line 203, in test_kernel_install
runCmd(cmd)
  File 
"/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/meta/lib/oeqa/utils/commands.py",
 line 214, in runCmd
raise AssertionError("Command '%s' returned non-zero exit status %d:\n%s" % 
(command, result.status, exc_output))
AssertionError: Command 'wic cp 
/home/pokybuild/yocto-worker/oe-selftest-ubuntu/build/build-st-3404782/wic-tmp/tmp4b6cj2n7-202302140200-sda.direct:1
 /tmp/tmpru5302n7' returned non-zero exit status 1:
ERROR: Can't find executable 'mcopy'

I guess you are missing a dependency.

On 10/02/2023 11:23:37+0100, Kareem Zarka wrote:
> - test_skip_kernel_install: This test verifies that the kernel is not
> installed in the boot partition when the 'install-kernel-into-boot-dir'
> parameter is set to false.
> 
> - test_kernel_install: This test verifies that the kernel is installed
> in the boot partition when the 'install-kernel-into-boot-dir' parameter
> is set to true .
> 
> Both tests use a WKS (Kickstart) file to specify the desired
> configuration, build a disk image using WIC, and extract the disk image
> to a temporary directory to verify the results.
> 
> Signed-off-by: Kareem Zarka 
> ---
>  meta/lib/oeqa/selftest/cases/wic.py | 66 +
>  1 file changed, 66 insertions(+)
> 
> diff --git a/meta/lib/oeqa/selftest/cases/wic.py 
> b/meta/lib/oeqa/selftest/cases/wic.py
> index ca1abb970a..b46dccc144 100644
> --- a/meta/lib/oeqa/selftest/cases/wic.py
> +++ b/meta/lib/oeqa/selftest/cases/wic.py
> @@ -16,6 +16,7 @@ import hashlib
>  from glob import glob
>  from shutil import rmtree, copy
>  from tempfile import NamedTemporaryFile
> +from tempfile import TemporaryDirectory
>  
>  from oeqa.selftest.case import OESelftestTestCase
>  from oeqa.core.decorator import OETestTag
> @@ -146,6 +147,71 @@ class CLITests(OESelftestTestCase):
>  self.assertEqual(1, runCmd('wic', ignore_status=True).status)
>  
>  class Wic(WicTestCase):
> +def test_skip_kernel_install(self):
> +"""Test the functionality of not installing the kernel in the boot 
> directory using the wic plugin"""
> +# create a temporary file for the WKS content
> +with NamedTemporaryFile("w", suffix=".wks") as wks:
> +wks.write(
> +'part --source bootimg-efi '
> +
> '--sourceparams="loader=grub-efi,install-kernel-into-boot-dir=false" '
> +'--label boot --active\n'
> +)
> +wks.flush()
> +# create a temporary directory to extract the disk image to
> +with TemporaryDirectory() as tmpdir:
> +img = 'core-image-minimal'
> +# build the image using the WKS file
> +cmd = "wic create %s -e %s -o %s" % (
> +wks.name, img, self.resultdir)
> +runCmd(cmd)
> +wksname = os.path.splitext(os.path.basename(wks.name))[0]
> +out = glob(os.path.join(
> +self.resultdir, "%s-*.direct" % wksname))
> +self.assertEqual(1, len(out))
> +# extract the content of the disk image to the temporary 
> directory
> +cmd = "wic cp %s:1 %s" % (out[0], tmpdir)
> +runCmd(cmd)
> +# check if the kernel is installed or not
> +kimgtype = get_bb_var('KERNEL_IMAGETYPE', img)
> +for file in os.listdir(tmpdir):
> +if file == kimgtype:
> +raise AssertionError(
> +"The kernel image '{}' was found in the 
> partition".format(kimgtype)
> +)
> +
> +def test_kernel_install(self):
> +"""Test the installation of the kernel to the boot directory in the 
> wic plugin"""
> +# create a temporary file for the WKS content
> +with NamedTemporaryFile("w", suffix=".wks") as wks:
> +wks.write(
> +'part --source bootimg-efi '
> +
> '--sourceparams="loader=grub-efi,install-kernel-into-boot-dir=true" '
> +'--label boot --active\n'
> +)
> +wks.flush()
> +# create a temporary directory to extract the disk image to
> +with TemporaryDirectory() as tmpdir:
> +img = 'core-image-minimal'
> +# build the image using the WKS file
> +cmd = "wic create %s -e %s -o %s" % (wks.name, img, 
> self.resultdir)
> +runCmd(cmd)
> +wksname = os.path.splitext(os.path.basename(

[OE-core] [PATCH 1/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Robert Yang
The PACKAGE_FEED_ARCHS is highly related to ALL_MULTILIB_PACKAGE_ARCHS, set it
automatically is better than manually, for example, we may forget to upgrade
PACKAGE_FEED_ARCHS when ALL_MULTILIB_PACKAGE_ARCHS is changed if set it
manually.

The workflow is:
Use PACKAGE_FEED_ARCHS if it is defined, if not, check DEPLOY_DIR_XXX/, 
add
 to PACKAGE_FEED_ARCHS if it exists.

Signed-off-by: Robert Yang 
---
 meta/lib/oe/rootfs.py | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 890ba5f039..f26b66ba7a 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -89,12 +89,36 @@ class Rootfs(object, metaclass=ABCMeta):
 def _log_check_error(self):
 self._log_check_common('error', self.log_check_regex)
 
+def _get_feed_archs(self):
+feed_archs = self.d.getVar('PACKAGE_FEED_ARCHS') or ''
+if not feed_archs:
+bb.note("  Figuring PACKAGE_FEED_ARCHS from 
ALL_MULTILIB_PACKAGE_ARCHS")
+manager = self.d.getVar('ROOTFS_PKGMANAGE')
+deploy_dir = ''
+if 'rpm' in manager:
+deploy_dir = self.d.getVar('DEPLOY_DIR_RPM')
+elif 'opkg' in manager:
+deploy_dir = self.d.getVar('DEPLOY_DIR_IPK')
+elif 'dpkg' in manager:
+deploy_dir = self.d.getVar('DEPLOY_DIR_DEB')
+else:
+bb.warn('Failed to figure out deploy_dir')
+return ''
+
+for arch in self.d.getVar('ALL_MULTILIB_PACKAGE_ARCHS').split():
+if 'rpm' in manager:
+arch = arch.replace("-", "_")
+arch_path = os.path.join(deploy_dir, arch)
+if os.path.exists(arch_path):
+feed_archs += " %s" % arch
+return feed_archs.strip()
+
 def _insert_feed_uris(self):
 if bb.utils.contains("IMAGE_FEATURES", "package-management",
  True, False, self.d):
 self.pm.insert_feeds_uris(self.d.getVar('PACKAGE_FEED_URIS') or "",
 self.d.getVar('PACKAGE_FEED_BASE_PATHS') or "",
-self.d.getVar('PACKAGE_FEED_ARCHS'))
+self._get_feed_archs())
 
 
 """
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177127): 
https://lists.openembedded.org/g/openembedded-core/message/177127
Mute This Topic: https://lists.openembedded.org/mt/96955951/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 0/1] rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

2023-02-14 Thread Robert Yang
The following changes since commit 0049f6757f6f956fb4cc77b3df6a672c20b53cf4:

  oeqa qemurunner.py: try to avoid reading one character at a time (2023-02-10 
09:25:41 +)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib rbt/feed
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/feed

Robert Yang (1):
  rootfs.py: Set PACKAGE_FEED_ARCHS when it is not defined

 meta/lib/oe/rootfs.py | 26 +-
 1 file changed, 25 insertions(+), 1 deletion(-)

-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177126): 
https://lists.openembedded.org/g/openembedded-core/message/177126
Mute This Topic: https://lists.openembedded.org/mt/96955950/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/1] base.bbclass: Fix dangling NATIVELSBSTRING

2023-02-14 Thread Robert Yang
Fixed:
$ rm -fr tmp; bitbake quilt-native -n
Build Configuration:
[snip]
NATIVELSBSTRING  = "ubuntu-18.04"
[snip]

And when run bitbake again:
$ bitbake quilt-native -n
Build Configuration:
NATIVELSBSTRING  = "universal"

It has been changed from ubuntu-18.04 to universal on the same host and build
directory, this is because it is overridded by NATIVELSBSTRING. This patch
makes it print the correct value.

Signed-off-by: Robert Yang 
---
 meta/classes-global/base.bbclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

diff --git a/meta/classes-global/base.bbclass b/meta/classes-global/base.bbclass
index 64e805c947..cf42d9d4d2 100644
--- a/meta/classes-global/base.bbclass
+++ b/meta/classes-global/base.bbclass
@@ -226,7 +226,12 @@ BUILDCFG_FUNCS[type] = "list"
 def buildcfg_vars(d):
 statusvars = oe.data.typed_value('BUILDCFG_VARS', d)
 for var in statusvars:
-value = d.getVar(var)
+# NATIVELSBSTRING var may have been overridden with "universal", so
+# get actual host distribution id and version
+if var == 'NATIVELSBSTRING':
+value = lsb_distro_identifier(d)
+else:
+value = d.getVar(var)
 if value is not None:
 yield '%-20s = "%s"' % (var, value)
 
-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177125): 
https://lists.openembedded.org/g/openembedded-core/message/177125
Mute This Topic: https://lists.openembedded.org/mt/96955945/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core] [PATCH 0/1] base.bbclass: Fix dangling NATIVELSBSTRING

2023-02-14 Thread Robert Yang
The following changes since commit 0049f6757f6f956fb4cc77b3df6a672c20b53cf4:

  oeqa qemurunner.py: try to avoid reading one character at a time (2023-02-10 
09:25:41 +)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib rbt/lsb
  http://cgit.openembedded.org/openembedded-core-contrib/log/?h=rbt/lsb

Robert Yang (1):
  base.bbclass: Fix dangling NATIVELSBSTRING

 meta/classes-global/base.bbclass | 7 ++-
 1 file changed, 6 insertions(+), 1 deletion(-)

-- 
2.39.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177124): 
https://lists.openembedded.org/g/openembedded-core/message/177124
Mute This Topic: https://lists.openembedded.org/mt/96955944/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][master][kirkstone][PATCH] dhcpcd: fix dhcpcd start failure on qemuppc64

2023-02-14 Thread Xiangyu Chen


On 2/10/23 10:18, Xiangyu Chen wrote:

From: Xiangyu Chen 

Backport patch to fix dhcpcd start failed on qemuppc64.


Friendly ping, thanks.




Signed-off-by: Xiangyu Chen 
---
  .../dhcpcd/dhcpcd_9.4.1.bb|  1 +
  ...x-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch | 34 +++
  2 files changed, 35 insertions(+)
  create mode 100644 
meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch

diff --git a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb 
b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
index 5cf77fa0f6..39e689d2f6 100644
--- a/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
+++ b/meta/recipes-connectivity/dhcpcd/dhcpcd_9.4.1.bb
@@ -16,6 +16,7 @@ SRC_URI = 
"https://roy.marples.name/downloads/${BPN}/${BPN}-${PV}.tar.xz \
 
file://0001-20-resolv.conf-improve-the-sitation-of-working-with-.patch \
 file://0001-privsep-Allow-getrandom-sysctl-for-newer-glibc.patch \
 file://0002-privsep-Allow-newfstatat-syscall-as-well.patch \
+   
file://0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch \
 file://dhcpcd.service \
 file://dhcpcd@.service \
 "
diff --git 
a/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
 
b/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
new file mode 100644
index 00..1c514f9b8c
--- /dev/null
+++ 
b/meta/recipes-connectivity/dhcpcd/files/0001-privsep-linux-fix-SECCOMP_AUDIT_ARCH-missing-ppc64le.patch
@@ -0,0 +1,34 @@
+From 7a2d9767585ed2c407d4985bd2d81552034fb90a Mon Sep 17 00:00:00 2001
+From: CHEN Xiangyu 
+Date: Thu, 9 Feb 2023 18:41:52 +0800
+Subject: [PATCH] privsep-linux: fix SECCOMP_AUDIT_ARCH missing ppc64le (#181)
+
+when dhcpcd running on ppc64le platform, it would be killed by SIGSYS.
+
+Upstream-Status: Backport [7a2d9767585ed2c407d4985bd2d81552034fb90a]
+
+Signed-off-by: Xiangyu Chen 
+---
+ src/privsep-linux.c | 6 +-
+ 1 file changed, 5 insertions(+), 1 deletion(-)
+
+diff --git a/src/privsep-linux.c b/src/privsep-linux.c
+index 7372d26b..6a301950 100644
+--- a/src/privsep-linux.c
 b/src/privsep-linux.c
+@@ -232,7 +232,11 @@ ps_root_sendnetlink(struct dhcpcd_ctx *ctx, int protocol, 
struct msghdr *msg)
+ #elif defined(__or1k__)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_OPENRISC
+ #elif defined(__powerpc64__)
+-#  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64
++#  if (BYTE_ORDER == LITTLE_ENDIAN)
++#define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64LE
++#  else
++#define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC64
++#  endif
+ #elif defined(__powerpc__)
+ #  define SECCOMP_AUDIT_ARCH AUDIT_ARCH_PPC
+ #elif defined(__riscv)
+--
+2.34.1
+




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#177128): 
https://lists.openembedded.org/g/openembedded-core/message/177128
Mute This Topic: https://lists.openembedded.org/mt/96868623/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-