[OE-core][kirkstone][PATCH] qemu: Fix CVE-2023-42467

[Poonam Jadhav]

1. scsi-disk: allow MODE SELECT block descriptor to set the block size
Link: 
https://github.com/qemu/qemu/commit/356c4c441ec01910314c5867c680bef80d1dd373

The MODE SELECT command can contain an optional block descriptor that can be 
used
to set the device block size. If the block descriptor is present then update the
block size on the SCSI device accordingly.

This allows CDROMs to be used with A/UX which requires a CDROM drive which is
capable of switching from a 2048 byte sector size to a 512 byte sector size.

2. scsi-disk: ensure block size is non-zero and changes limited to bits 8-15
Link: 
https://github.com/qemu/qemu/commit/55794c904df723109b228da28b5db778e0df3110

The existing code assumes that the block size can be generated from p[1] << 8
in multiple places which ignores the top and bottom 8 bits. If the block size
is allowed to be set to an arbitrary value then this causes a mismatch
between the value written by the guest in the block descriptor and the value
subsequently read back using READ CAPACITY causing the guest to generate
requests that can crash QEMU.

For now restrict block size changes to bits 8-15 and also ignore requests to
set the block size to 0 which causes the SCSI emulation to crash in at least
one place with a divide by zero error.

3. Disallow block sizes smaller than 512 [CVE-2023-42467]
Link: 
https://gitlab.com/qemu-project/qemu/-/commit/7cfcc79b0ab800959716738aff9419f53fc68c9c

We are doing things like

nb_sectors /= (s->qdev.blocksize / BDRV_SECTOR_SIZE);

in the code here (e.g. in scsi_disk_emulate_mode_sense()), so if
the blocksize is smaller than BDRV_SECTOR_SIZE (=512), this crashes
with a division by 0 exception. Thus disallow block sizes of 256
bytes to avoid this situation.

Signed-off-by: Poonam Jadhav 
---
 meta/recipes-devtools/qemu/qemu.inc   |  3 +
 .../qemu/qemu/CVE-2023-42467.patch| 46 +
 ...lock-desriptor-to-set-the-block-size.patch | 54 +++
 ...ero-and-changes-limited-to-bits-8-15.patch | 67 +++
 4 files changed, 170 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2023-42467.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/scsi-disk-allow-MODE-SELECT-block-desriptor-to-set-the-block-size.patch
 create mode 100644 
meta/recipes-devtools/qemu/qemu/scsi-disk-ensure-block-size-is-non-zero-and-changes-limited-to-bits-8-15.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index c5fb9b1eab..f97dcf289e 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -103,6 +103,9 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://CVE-2021-3638.patch \
   file://CVE-2023-1544.patch \
   file://CVE-2023-5088.patch \
+   
file://scsi-disk-allow-MODE-SELECT-block-desriptor-to-set-the-block-size.patch \
+   
file://scsi-disk-ensure-block-size-is-non-zero-and-changes-limited-to-bits-8-15.patch
 \
+   file://CVE-2023-42467.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2023-42467.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2023-42467.patch
new file mode 100644
index 00..d53683faa7
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2023-42467.patch
@@ -0,0 +1,46 @@
+From 7cfcc79b0ab800959716738aff9419f53fc68c9c Mon Sep 17 00:00:00 2001
+From: Thomas Huth 
+Date: Mon, 25 Sep 2023 11:18:54 +0200
+Subject: [PATCH] hw/scsi/scsi-disk: Disallow block sizes smaller than 512
+ [CVE-2023-42467]
+
+We are doing things like
+
+nb_sectors /= (s->qdev.blocksize / BDRV_SECTOR_SIZE);
+
+in the code here (e.g. in scsi_disk_emulate_mode_sense()), so if
+the blocksize is smaller than BDRV_SECTOR_SIZE (=512), this crashes
+with a division by 0 exception. Thus disallow block sizes of 256
+bytes to avoid this situation.
+
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1813
+CVE: 2023-42467
+Signed-off-by: Thomas Huth 
+Message-ID: <20230925091854.49198-1-th...@redhat.com>
+Signed-off-by: Paolo Bonzini 
+
+CVE: CVE-2023-42467
+Upstream-Status: Backport 
[https://gitlab.com/qemu-project/qemu/-/commit/7cfcc79b0ab800959716738aff9419f53fc68c9c]
+Signed-off-by: Poonam Jadhav 
+---
+ hw/scsi/scsi-disk.c | 5 +++--
+ 1 file changed, 3 insertions(+), 2 deletions(-)
+
+diff --git a/hw/scsi/scsi-disk.c b/hw/scsi/scsi-disk.c
+index e0d79c7966c..477ee2bcd47 100644
+--- a/hw/scsi/scsi-disk.c
 b/hw/scsi/scsi-disk.c
+@@ -1628,9 +1628,10 @@ static void scsi_disk_emulate_mode_select(SCSIDiskReq 
*r, uint8_t *inbuf)
+  * Since the existing code only checks/updates bits 8-15 of the block
+  * size, restrict ourselves to the same requirement for now to ensure
+  * that a block size set by a block descriptor and then read back by
+- * a subsequent SCSI command will be the same
++ * a subsequent SCSI command will be the same. Also 

Re: [OE-core] [PATCH V5] systemd: fix a dead link under /var/log

[Khem Raj]

On Wed, Feb 28, 2024 at 10:43 PM Changqing Li
 wrote:
>
>
> On 2/29/24 14:04, Khem Raj wrote:
> > CAUTION: This email comes from a non Wind River email account!
> > Do not click links or open attachments unless you recognize the sender and 
> > know the content is safe.
> >
> > On Wed, Feb 28, 2024 at 9:56 PM Changqing Li
> >  wrote:
> >>
> >> On 2/28/24 17:45, Alexander Kanavin wrote:
> >>
> >> CAUTION: This email comes from a non Wind River email account!
> >> Do not click links or open attachments unless you recognize the sender and 
> >> know the content is safe.
> >>
> >> On Wed, 28 Feb 2024 at 04:19, Changqing Li  
> >> wrote:
> >>
> >> 1.
> >>
> >> Currently,  There is one line in /usr/lib/tmpfile.d/legacy.conf(this is in 
> >> package systemd),
> >>
> >> "L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs"
> >>
> >> This line will create an link to "${datadir}/doc/systemd/README.logs" 
> >> during boot,
> >>
> >> and ${datadir}/doc/systemd/README.logs is in package systemd-doc. So there 
> >> will be dead link when systemd-doc is not installed.
> >>
> >> So that's why I create another legacy-doc.conf packaged into systemd-doc
> >>
> >> Then legacy.conf and README.logs should be placed into the same
> >> package. I would suggest that README.logs just goes into main systemd
> >> package. (the other option is placing legacy.conf into systemd-doc,
> >> but that file is not doc-specific, and should stay in systemd package,
> >> especially if more entries are added to it).
> >>
> >> The solution is also good. But package "${docdir}/systemd/README.logs" in 
> >> package systemd may make things more complicated.
> >>
> >> since in bitabke .conf, ${PN}-doc is before ${PN} in PACKAGES, and  
> >> FILES:${PN}-doc = "${docdir}  ...". we need to adjust the sequence,
> >>
> >> and may have influences to current list of files and directories that are 
> >> placed in a package.
> >>
> >> So maybe this patch is more simple and reasonable, and will not have other 
> >> impact.
> >>
> >> 2.
> >>
> >> The symlink in legacy.conf use relative path.  but for oe, when 
> >> VOLATILE_LOG_DIR is true, /var/log is a link to /var/volatile/log, so
> >>
> >> /var/log/README need link to ../../../usr/share/doc/systemd/README.logs,
> >>
> >> while VOLATILE_LOG_DIR is false, /var/log is a dir, so /var/log/README
> >>
> >> need link to ../../usr/share/doc/systemd/README.logs.
> >>
> >> After change it to absolute path, checking of VOLATILE_LOG_DIR is not 
> >> needed.
> >>
> >> That's ok, but can you make fixing the path to an absolute one a
> >> separate, second commit then?
> >>
> >> if  use solution in this patch,  it is better they are in one commit.  I 
> >> can update description more detail.
> >>
> > You could also explore using -Dcreate-log-dirs=false via EXTRA_OEMESON
>
> Thanks. I had do some research about turn off CREATE_LOG_DIR,
>
> if turn off CREATE_LOG_DIR, " /var/log/journal/" will not be created.
> By default,  VOLATILE__LOG_DIR = "yes",  this change will have no
> influence, since we will remove content under /var/log.
>
> if VOLATILE_LOG_DIR set to "no", the current default behavior will be
> changed,  log will saved from persistent  to memory.   our default
> Storage set to auto,  if " /var/log/journal/" not exist, the log will
>
> save  in memory /run/log/journal.  Refer [1].  So I did not try to turn
> off it in case current default behavior is changed.
>

The option -Dcreate-log-dirs will control if systemd build emits
relevant info into generated legacy.conf
or not thats all. Whatever logic you have in OE is high level which
might be covering it across the distro. so
what I am suggesting is to use the meson option to control it when
building systemd, the knob logic
to apply it will depend on OE's logic for log persistence.

> Refer:
>
> [1] https://www.freedesktop.org/software/systemd/man/journald.conf.html
>
> //Changqing
>
> >
> >> Thanks
> >>
> >> Changqing
> >>
> >> Thanks,
> >> Alex
> >>
> >>
> >> 
> >>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196454): 
https://lists.openembedded.org/g/openembedded-core/message/196454
Mute This Topic: https://lists.openembedded.org/mt/104598170/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 V5] systemd: fix a dead link under /var/log

[Changqing Li]

On 2/29/24 19:56, Peter Kjellerstedt wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.


-Original Message-
From:openembedded-core@lists.openembedded.org  
  On Behalf Of Alexander Kanavin
Sent: den 29 februari 2024 10:01
To: Changqing Li
Cc: Changqing 
Li;openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V5] systemd: fix a dead link under /var/log

On Thu, 29 Feb 2024 at 06:56, Changqing Li  wrote:

The solution is also good. But package "${docdir}/systemd/README.logs"
in package systemd may make things more complicated.

since in bitabke .conf, ${PN}-doc is before ${PN} in PACKAGES, and
FILES:${PN}-doc = "${docdir}  ...". we need to adjust the sequence,

and may have influences to current list of files and directories that
are placed in a package.

So maybe this patch is more simple and reasonable, and will not have
other impact.

That's right. It's possible but not obvious how to override that (I
don't remember that from memory).


That's ok, but can you make fixing the path to an absolute one a
separate, second commit then?

if  use solution in this patch,  it is better they are in one commit.  I
can update description more detail.

Please no. These are two separate issues, let's deal with them as
separate changes.

Alex

Given how much churn this patch has generated for a file that probably
no one will read, how about just not creating it in the first place?
That is what we do with the following patch:

 From 49483effbcb920d097487c58214518f2f3a9d479 Mon Sep 17 00:00:00 2001
From: Yang Lyu
Date: Mon, 20 Jun 2022 09:07:19 +0200
Subject: [PATCH] Do not create README in log directory

---
  tmpfiles.d/legacy.conf.in | 3 ---
  1 file changed, 3 deletions(-)

diff --git a/tmpfiles.d/legacy.conf.in b/tmpfiles.d/legacy.conf.in
index 4f2c0d7c43..62e2ae0986 100644
--- a/tmpfiles.d/legacy.conf.in
+++ b/tmpfiles.d/legacy.conf.in
@@ -12,9 +12,6 @@

  d /run/lock 0755 root root -
  L /var/lock - - - - ../run/lock
-{% if CREATE_LOG_DIRS %}
-L /var/log/README - - - - ../..{{DOC_DIR}}/README.logs
-{% endif %}

  # /run/lock/subsys is used for serializing SysV service execution, and
  # hence without use on SysV-less systems.

//Peter


Hi,

This is also my V1 patch solution.  Please see Richard's comments for V1,

he also recommeded turn off CREATE_LOG_DIRS, but this CREATE_LOG_DIRS is 
not only


used here, it will changed log save location default behavior when 
volatile is disabled.


Thanks

Changqing

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196453): 
https://lists.openembedded.org/g/openembedded-core/message/196453
Mute This Topic: https://lists.openembedded.org/mt/104598170/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] u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

[Fabio Estevam]

From: Fabio Estevam 

Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved
UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc
because it encodes ${PN} in it, which should be set by the U-Boot recipe.

Currently, whatever inherits uboot-config bbclass will fill-in its own PN,
which would change the content of UBOOT_INITIAL_ENV per-package.

Cc: Klaus Heinrich Kiwi 
Cc: Marek Vasut 
Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations")
Signed-off-by: Fabio Estevam 
---
 meta/classes-recipe/uboot-config.bbclass | 4 
 meta/recipes-bsp/u-boot/u-boot.inc   | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes-recipe/uboot-config.bbclass 
b/meta/classes-recipe/uboot-config.bbclass
index 0c579e8861..e55fc38b7c 100644
--- a/meta/classes-recipe/uboot-config.bbclass
+++ b/meta/classes-recipe/uboot-config.bbclass
@@ -65,10 +65,6 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
 
-# Default name of u-boot initial env, but enable individual recipes to change
-# this value.
-UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
-
 # U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
 # to find EXTLINUX conf file.
 UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index 79f84b0672..f5b43f6e36 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -24,6 +24,10 @@ PACKAGECONFIG[openssl] = ",,openssl-native"
 # file already exists it will not be overwritten.
 UBOOT_LOCALVERSION ?= ""
 
+# Default name of u-boot initial env, but enable individual recipes to change
+# this value.
+UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
+
 require u-boot-configure.inc
 
 do_savedefconfig() {
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196452): 
https://lists.openembedded.org/g/openembedded-core/message/196452
Mute This Topic: https://lists.openembedded.org/mt/104655704/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] python3-attrs: disable Hypothesis deadline

[Tim Orling]

The deadline is by default 200ms, but this is intended to be useful to
the developer and not necessarily recommended for heavily loaded CI
systems. Avoid warnings by disabling the deadline completely.

https://github.com/HypothesisWorks/hypothesis/issues/3713
https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.deadline
https://lists.openembedded.org/g/openembedded-core/topic/104640034#196437
https://github.com/python-attrs/attrs/pull/1252

Fixes:
"""
Unreliable test timings! On an initial run, this test took 268.29ms,
which exceeded the deadline of 200.00ms, but on a subsequent run it
took 2.63 ms, which did not. If you expect this sort of variability in
your test timings, consider turning deadlines off for this test by
setting deadline=None.
"""

[YOCTO #15350]

Signed-off-by: Tim Orling 
---
Changes in v2:
* Reference Bugzilla #15350 which is HIGHLY likely to be related
* Change Upstream-Status to submitted, since the comments in conftest.py state
  it is setting up for CI situation. "patience" and deadline=None seem to go
  hand in hand :)

 .../0001-conftest.py-disable-deadline.patch   | 45 +++
 .../python/python3-attrs_23.2.0.bb|  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch

diff --git 
a/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
 
b/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
new file mode 100644
index 000..b1e6d999168
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
@@ -0,0 +1,45 @@
+From 41103f017f6a233ebb477dd1712fe82ea8f1c84c Mon Sep 17 00:00:00 2001
+From: Tim Orling 
+Date: Thu, 29 Feb 2024 08:45:54 -0800
+Subject: [PATCH] conftest.py: disable deadline
+
+The deadline is by default 200ms, but this is intended to be useful to
+the developer and not necessarily recommended for heavily loaded CI
+systems. Avoid warnings by disabling the deadline completely.
+
+https://github.com/HypothesisWorks/hypothesis/issues/3713
+https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.deadline
+https://lists.openembedded.org/g/openembedded-core/topic/104640034#196437
+
+Fixes:
+"""
+Unreliable test timings! On an initial run, this test took 268.29ms,
+which exceeded the deadline of 200.00ms, but on a subsequent run it
+took 2.63 ms, which did not. If you expect this sort of variability in
+your test timings, consider turning deadlines off for this test by
+setting deadline=None.
+"""
+
+Upstream-Status: Submitted [https://github.com/python-attrs/attrs/pull/1252]
+
+Signed-off-by: Tim Orling 
+---
+ conftest.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/conftest.py b/conftest.py
+index 144e5f3..fdead3d 100644
+--- a/conftest.py
 b/conftest.py
+@@ -20,7 +20,7 @@ def _frozen(request):
+ def pytest_configure(config):
+ # HealthCheck.too_slow causes more trouble than good -- especially in CIs.
+ settings.register_profile(
+-"patience", settings(suppress_health_check=[HealthCheck.too_slow])
++"patience", settings(suppress_health_check=[HealthCheck.too_slow], 
deadline=None)
+ )
+ settings.load_profile("patience")
+ 
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/python/python3-attrs_23.2.0.bb 
b/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
index 3945798ba5e..a6380979884 100644
--- a/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
@@ -9,6 +9,7 @@ inherit pypi ptest python_hatchling
 
 SRC_URI += " \
file://0001-test_funcs-skip-test_unknown-for-pytest-8.patch \
+   file://0001-conftest.py-disable-deadline.patch \
file://run-ptest \
 "
 
-- 
2.34.1


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

[OE-core] [PATCH] linux-yocto: Enable gpio-sim with ptests

[Khem Raj]

ptests for packages like libgpiod and python3-gpiod need gpio-sim to run
the tests successfully.

Signed-off-by: Khem Raj 
Cc: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-dev.bb| 2 +-
 meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb | 2 +-
 meta/recipes-kernel/linux/linux-yocto_6.6.bb| 2 +-
 3 files changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 8365e22b32b..6aec34c16c4 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -62,6 +62,6 @@ KERNEL_FEATURES:append:qemux86=" cfg/sound.scc 
cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "", d)}"
 KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "", d)}"
-KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc", "", d)}"
+KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc features/gpio/sim.scc", "", d)}"
 
 KERNEL_VERSION_SANITY_SKIP = "1"
diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
index 6eca6de5da5..65c440d40d8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.6.bb
@@ -45,4 +45,4 @@ KERNEL_FEATURES:append:qemuall=" cfg/virtio.scc 
features/drm-bochs/drm-bochs.scc
 KERNEL_FEATURES:append:qemux86=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "", d)}"
-KERNEL_FEATURES:append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc", "", d)}"
+KERNEL_FEATURES:append = "${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc features/gpio/sim.scc", "", d)}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
index ee585e588b3..86da40e0215 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
@@ -65,7 +65,7 @@ KERNEL_FEATURES:append:qemux86=" cfg/sound.scc 
cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append:qemux86-64=" cfg/sound.scc cfg/paravirt_kvm.scc"
 KERNEL_FEATURES:append = " ${@bb.utils.contains("TUNE_FEATURES", "mx32", " 
cfg/x32.scc", "", d)}"
 KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/scsi/scsi-debug.scc", "", d)}"
-KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc", "", d)}"
+KERNEL_FEATURES:append = " ${@bb.utils.contains("DISTRO_FEATURES", "ptest", " 
features/gpio/mockup.scc features/gpio/sim.scc", "", d)}"
 KERNEL_FEATURES:append:powerpc =" arch/powerpc/powerpc-debug.scc"
 KERNEL_FEATURES:append:powerpc64 =" arch/powerpc/powerpc-debug.scc"
 KERNEL_FEATURES:append:powerpc64le =" arch/powerpc/powerpc-debug.scc"
-- 
2.44.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196450): 
https://lists.openembedded.org/g/openembedded-core/message/196450
Mute This Topic: https://lists.openembedded.org/mt/104653789/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] [RFC OE-core][PATCH v2 1/7] go: rework patch to avoid identation

[Richard Purdie]

On Thu, 2024-02-29 at 21:42 +, Jose Quaresma wrote:
> 
> 
> A quinta, 29/02/2024, 09:35, Jose Quaresma via lists.openembedded.org
>  escreveu:
> > 
> > 
> > Richard Purdie  escreveu
> > (quinta, 29/02/2024 à(s) 08:18):
> > > On Wed, 2024-02-28 at 21:16 -0800, Khem Raj wrote:
> > > > Fails to compile bunch of  recipes using go e.g. influxdb,
> > > > crucible,
> > > > syzkaller in meta-oe see
> > > > 
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3667/steps/15/logs/stdio
> > > 
> > > Also fails for oe-selftest:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/6415/steps/14/logs/stdio
> > > 
> > > and on arm hosts:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/7999/steps/13/logs/stdio
> > > 
> > 
> > 
> > 
> > Thanks for testing, I will take a look on all of this today.
> 
> I have no progress today and unfortunately I won't have time to work
> on this in the next few days :( if anyone wants to continue with this
> effort, feel free to do so.
> 
> my apologies.

FWIW https://github.com/golang/go/issues/65887 looked relevant to the
first issue.

We are really late in the schedule to pull in things like this so I'm
not sure we'll get this in at this point :/.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196449): 
https://lists.openembedded.org/g/openembedded-core/message/196449
Mute This Topic: https://lists.openembedded.org/mt/104628621/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] [RFC OE-core][PATCH v2 1/7] go: rework patch to avoid identation

[Jose Quaresma]

A quinta, 29/02/2024, 09:35, Jose Quaresma via lists.openembedded.org
 escreveu:

>
>
> Richard Purdie  escreveu (quinta,
> 29/02/2024 à(s) 08:18):
>
>> On Wed, 2024-02-28 at 21:16 -0800, Khem Raj wrote:
>> > Fails to compile bunch of  recipes using go e.g. influxdb, crucible,
>> > syzkaller in meta-oe see
>> >
>> >
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3667/steps/15/logs/stdio
>>
>> Also fails for oe-selftest:
>>
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/6415/steps/14/logs/stdio
>>
>> and on arm hosts:
>>
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/7999/steps/13/logs/stdio
>
>
>
> Thanks for testing, I will take a look on all of this today.
>

I have no progress today and unfortunately I won't have time to work on
this in the next few days :( if anyone wants to continue with this effort,
feel free to do so.

my apologies.

Jose


> Jose
>
>
>>
>>
>> Cheers,
>>
>> Richard
>>
>
>
> --
> Best regards,
>
> José Quaresma
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196448): 
https://lists.openembedded.org/g/openembedded-core/message/196448
Mute This Topic: https://lists.openembedded.org/mt/104628621/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] core-image-full-cmdline: add package-management

[Richard Purdie]

On Thu, 2024-02-29 at 16:03 +0100, michael.opdenac...@bootlin.com
wrote:
> From: Michael Opdenacker 
> 
> Add "package-management" image feature to the core-image-full-cmdline
> image,
> to support package upgrade testing.
> 
> Signed-off-by: Michael Opdenacker 
> Suggested-by: Richard Purdie 
> ---
>  meta/recipes-extended/images/core-image-full-cmdline.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/images/core-image-full-cmdline.bb
> b/meta/recipes-extended/images/core-image-full-cmdline.bb
> index 4e1cf58d55..b034cd0aeb 100644
> --- a/meta/recipes-extended/images/core-image-full-cmdline.bb
> +++ b/meta/recipes-extended/images/core-image-full-cmdline.bb
> @@ -1,7 +1,7 @@
>  SUMMARY = "A console-only image with more full-featured Linux system
> \
>  functionality installed."
>  
> -IMAGE_FEATURES += "splash ssh-server-openssh"
> +IMAGE_FEATURES += "splash ssh-server-openssh package-management"
>  
>  IMAGE_INSTALL = "\
>  packagegroup-core-boot \

This does break one of the oe-selftests around gplv3 exclusion handling
unfortunately:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/6471/steps/15/logs/stdio

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196447): 
https://lists.openembedded.org/g/openembedded-core/message/196447
Mute This Topic: https://lists.openembedded.org/mt/104644618/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] core-image-full-cmdline: add package-management

[Richard Purdie]

On Thu, 2024-02-29 at 13:29 -0600, Mark Hatle wrote:
> There are plenty of systems where we don't want package-management
> enabled by default.  This will just make core-image-full-cmdline less
> useful there.
> 
> In the past, it's always been up to the user to enable full package-
> management in their configuration, default has been to not have it
> present.  Has this changed?

Of our images, many of them already enable package-management including
core-image-sato (and derivatives like sdk), core-image-x11, core-image-
weston and build-appliance. In that sense, core-image-full-cmdline was
an outlier.

Whilst it does add some dependencies and metadata it doesn't add that
much overall. This big win for this is that it then lets us test image
upgrades with the artefact built as part of the release artefacts.

That testing does make sense with full-cmdline so bringing it slightly
more into line with the other images seemed like the best/easiest
improvement for a big QA win.

Anyone not needing it can easily remove that feature as they would with
the others.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196446): 
https://lists.openembedded.org/g/openembedded-core/message/196446
Mute This Topic: https://lists.openembedded.org/mt/104644618/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] core-image-full-cmdline: add package-management

[Mark Hatle]

There are plenty of systems where we don't want package-management enabled by 
default.  This will just make core-image-full-cmdline less useful there.


In the past, it's always been up to the user to enable full package-management 
in their configuration, default has been to not have it present.  Has this changed?


On 2/29/24 9:03 AM, Michael Opdenacker via lists.openembedded.org wrote:

From: Michael Opdenacker 

Add "package-management" image feature to the core-image-full-cmdline image,
to support package upgrade testing.

Signed-off-by: Michael Opdenacker 
Suggested-by: Richard Purdie 
---
  meta/recipes-extended/images/core-image-full-cmdline.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/images/core-image-full-cmdline.bb 
b/meta/recipes-extended/images/core-image-full-cmdline.bb
index 4e1cf58d55..b034cd0aeb 100644
--- a/meta/recipes-extended/images/core-image-full-cmdline.bb
+++ b/meta/recipes-extended/images/core-image-full-cmdline.bb
@@ -1,7 +1,7 @@
  SUMMARY = "A console-only image with more full-featured Linux system \
  functionality installed."
  
-IMAGE_FEATURES += "splash ssh-server-openssh"

+IMAGE_FEATURES += "splash ssh-server-openssh package-management"
  
  IMAGE_INSTALL = "\

  packagegroup-core-boot \






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

[OE-core] [PATCH] python3-attrs: disable Hypothesis deadline

[Tim Orling]

The deadline is by default 200ms, but this is intended to be useful to
the developer and not necessarily recommended for CI systems. Avoid,
AB warnings by disabling the deadline completely.

https://github.com/HypothesisWorks/hypothesis/issues/3713
https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.deadline
https://lists.openembedded.org/g/openembedded-core/topic/104640034#196437

Fixes:
"""
Unreliable test timings! On an initial run, this test took 268.29ms,
which exceeded the deadline of 200.00ms, but on a subsequent run it
took 2.63 ms, which did not. If you expect this sort of variability in
your test timings, consider turning deadlines off for this test by
setting deadline=None.
"""

Signed-off-by: Tim Orling 
---
All tests pass on qemux86-64 for core-image-ptest-python3-attrs

 .../0001-conftest.py-disable-deadline.patch   | 45 +++
 .../python/python3-attrs_23.2.0.bb|  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch

diff --git 
a/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
 
b/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
new file mode 100644
index 000..efd78fca608
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3-attrs/0001-conftest.py-disable-deadline.patch
@@ -0,0 +1,45 @@
+From 41103f017f6a233ebb477dd1712fe82ea8f1c84c Mon Sep 17 00:00:00 2001
+From: Tim Orling 
+Date: Thu, 29 Feb 2024 08:45:54 -0800
+Subject: [PATCH] conftest.py: disable deadline
+
+The deadline is by default 200ms, but this is intended to be useful to
+the developer and not necessarily recommended for CI systems. Avoid,
+AB warnings by disabling the deadline completely.
+
+https://github.com/HypothesisWorks/hypothesis/issues/3713
+https://hypothesis.readthedocs.io/en/latest/settings.html#hypothesis.settings.deadline
+https://lists.openembedded.org/g/openembedded-core/topic/104640034#196437
+
+Fixes:
+"""
+Unreliable test timings! On an initial run, this test took 268.29ms,
+which exceeded the deadline of 200.00ms, but on a subsequent run it
+took 2.63 ms, which did not. If you expect this sort of variability in
+your test timings, consider turning deadlines off for this test by
+setting deadline=None.
+"""
+
+Upstream-Status: Inappropriate [CI specific]
+
+Signed-off-by: Tim Orling 
+---
+ conftest.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/conftest.py b/conftest.py
+index 144e5f3..fdead3d 100644
+--- a/conftest.py
 b/conftest.py
+@@ -20,7 +20,7 @@ def _frozen(request):
+ def pytest_configure(config):
+ # HealthCheck.too_slow causes more trouble than good -- especially in CIs.
+ settings.register_profile(
+-"patience", settings(suppress_health_check=[HealthCheck.too_slow])
++"patience", settings(suppress_health_check=[HealthCheck.too_slow], 
deadline=None)
+ )
+ settings.load_profile("patience")
+ 
+-- 
+2.34.1
+
diff --git a/meta/recipes-devtools/python/python3-attrs_23.2.0.bb 
b/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
index 3945798ba5e..a6380979884 100644
--- a/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
+++ b/meta/recipes-devtools/python/python3-attrs_23.2.0.bb
@@ -9,6 +9,7 @@ inherit pypi ptest python_hatchling
 
 SRC_URI += " \
file://0001-test_funcs-skip-test_unknown-for-pytest-8.patch \
+   file://0001-conftest.py-disable-deadline.patch \
file://run-ptest \
 "
 
-- 
2.34.1


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

Re: [OE-core] [PATCH 3/3] rust: reproducibility issue fix with v1.75

[Shinde, Yash via lists.openembedded.org]

*Reproducibility:*
Below targets are tested-
- x86_64
- x86
- arm
- arm64

Remaining targets yet to be tested.

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

Re: [OE-core] [PATCH 1/3] rust: Upgrade 1.74.1 -> 1.75.0

[Shinde, Yash via lists.openembedded.org]

*Builds tested:*
- bitbake rust
- bitbake cargo
- bitbake nativesdk-rust

*oe-selftest:*
Below targets are tested-
- x86_64
- x86

Remaining targets yet to be tested.

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

[OE-core] [PATCH 3/3] rust: reproducibility issue fix with v1.75

[Shinde, Yash via lists.openembedded.org]

From: Yash Shinde 

With 1.75 rust release, the '.rustc' section of shared object libs are embedded 
with absolute path names which is casuing reproducibiluty issues.
This change will fix the path name format back to '/rust/$hash' as in earlier 
versions.

Below are the links for detailed bug description & discusssion with upstream 
rust.
https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656

Signed-off-by: Sundeep KOKKONDA 
Signed-off-by: Yash Shinde 
---
 .../files/repro-issue-fix-with-v175.patch | 23 +++
 meta/recipes-devtools/rust/rust-source.inc|  1 +
 2 files changed, 24 insertions(+)
 create mode 100644 
meta/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch

diff --git a/meta/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch 
b/meta/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
new file mode 100644
index 00..6840bafff8
--- /dev/null
+++ b/meta/recipes-devtools/rust/files/repro-issue-fix-with-v175.patch
@@ -0,0 +1,23 @@
+rust: reproducibility issue fix with v1.75
+
+With 1.75 rust release, the '.rustc' section of shared object libs are 
embedded with absolute path names which is casuing reproducibiluty issues.
+This change will fix the path name format back to '/rust/$hash' as in earlier 
versions.
+
+Below are the links for detailed bug description & discusssion with upstream 
rust.
+https://github.com/rust-lang/rust/issues/120825#issuecomment-1964307219
+https://github.com/rust-lang/rust/issues/120825#issuecomment-1964652656
+
+Upstream-Status: Inappropriate [patches need rework]
+Signed-off-by: Sundeep KOKKONDA 
+---
+--- a/compiler/rustc_session/src/session.rs2023-12-21 08:55:28.0 
-0800
 b/compiler/rustc_session/src/session.rs2024-02-26 07:29:15.527577022 
-0800
+@@ -1269,7 +1269,7 @@
+ | CrateType::Rlib
+ | CrateType::Staticlib
+ | CrateType::Cdylib => continue,
+-CrateType::ProcMacro => return false,
++CrateType::ProcMacro => return true,
+ }
+ }
+ 
diff --git a/meta/recipes-devtools/rust/rust-source.inc 
b/meta/recipes-devtools/rust/rust-source.inc
index 8ae8add495..6bef99039d 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -12,6 +12,7 @@ SRC_URI += 
"https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
 file://rustc-bootstrap.patch;patchdir=${RUSTSRC} \
 file://target-build-value.patch;patchdir=${RUSTSRC} \
 
file://0001-Handle-vendored-sources-when-remapping-paths.patch;patchdir=${RUSTSRC}
 \
+file://repro-issue-fix-with-v175.patch;patchdir=${RUSTSRC} \
 "
 SRC_URI[rust.sha256sum] = 
"4526f786d673e4859ff2afa0bab2ba13c918b796519a25c1acce06dba9542340"
 
-- 
2.43.0


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

[OE-core] [PATCH 2/3] rust: Revert PGO to it's default

[Shinde, Yash via lists.openembedded.org]

From: Yash Shinde 

The rust profiler PGO (Profile-guided Optimization) options was disabled as a 
part rustdoc reproducibility fix.
https://git.yoctoproject.org/poky/commit/meta/recipes-devtools/rust?id=321aebfa281bd28e368c684ece57867f6bd0cbe7

But, other applications (such as to build chromium with poky) requires PGO 
enabled (https://github.com/OSSystems/meta-browser/issues/786).

For reproducibility issue fix only "rust-demangler" change is sufficient in 
commit#321aebfa281. The PGO is reverted to it's default.

Signed-off-by: Yash Shinde 
---
 meta/recipes-devtools/rust/rust_1.75.0.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb 
b/meta/recipes-devtools/rust/rust_1.75.0.bb
index ee1ce9e050..76e1fe2d84 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -146,10 +146,6 @@ python do_configure() {
 rustc = d.expand("${WORKDIR}/rust-snapshot/bin/rustc")
 config.set("build", "rustc", e(rustc))
 
-# Support for the profiler runtime to generate e.g. coverage report,
-# PGO etc.
-config.set("build", "profiler", e(False))
-
 cargo = d.expand("${WORKDIR}/rust-snapshot/bin/cargo")
 config.set("build", "cargo", e(cargo))
 
-- 
2.43.0


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

[OE-core] [PATCH] linux-firmware: split out more firmware pieces

[Ross Burton]

From: Ross Burton 

Split _most_ of the rtl_nic drivers to a subpackage. Notably this does
not include rtl8168 as this is already split into a separate package.
These drivers are fairly common so this lets people install the essential
firmware easier.

Also split out some large firmware collections into subpackages:
- Mellanox (82M)
- Marvell Prestera (72M)
- QLogic 4 (21M)

Signed-off-by: Ross Burton 
---
 .../linux-firmware/linux-firmware_20231211.bb  | 18 ++
 1 file changed, 18 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index 9347cde298d..3a3690bdc1b 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -280,6 +280,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-rtl8761 \
  ${PN}-rtl8168 \
  ${PN}-rtl8822 \
+ ${PN}-rtl-nic \
  ${PN}-cypress-license \
  ${PN}-broadcom-license \
  ${PN}-bcm-0bb4-0306 \
@@ -348,6 +349,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-bnx2 \
  ${PN}-bnx2x \
  ${PN}-liquidio \
+ ${PN}-mellanox \
  ${PN}-nvidia-license \
  ${PN}-nvidia-tegra-k1 ${PN}-nvidia-tegra \
  ${PN}-nvidia-gpu \
@@ -366,7 +368,9 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-olpc-license ${PN}-olpc \
  ${PN}-phanfw-license ${PN}-phanfw \
  ${PN}-powervr-license ${PN}-powervr \
+ ${PN}-prestera \
  ${PN}-qat ${PN}-qat-license \
+ ${PN}-qed \
  ${PN}-qcom-license ${PN}-qcom-yamato-license \
  ${PN}-qcom-venus-1.8 ${PN}-qcom-venus-4.2 ${PN}-qcom-venus-5.2 
${PN}-qcom-venus-5.4 ${PN}-qcom-venus-6.0 \
  ${PN}-qcom-vpu-1.0 ${PN}-qcom-vpu-2.0 \
@@ -817,6 +821,7 @@ LICENSE:${PN}-rtl8761 = "Firmware-rtlwifi_firmware"
 LICENSE:${PN}-rtl8821 = "Firmware-rtlwifi_firmware"
 LICENSE:${PN}-rtl8822 = "Firmware-rtlwifi_firmware"
 LICENSE:${PN}-rtl-license = "Firmware-rtlwifi_firmware"
+LICENSE:${PN}-rtl-nic = "WHENCE"
 LICENSE:${PN}-rtl8168 = "WHENCE"
 
 FILES:${PN}-rtl-license = " \
@@ -852,6 +857,9 @@ FILES:${PN}-rtl8822 = " \
   ${nonarch_base_libdir}/firmware/rtw88/rtw8822*.bin \
   ${nonarch_base_libdir}/firmware/rtlwifi/rtl8822*.bin \
 "
+FILES:${PN}-rtl-nic = " \
+  ${nonarch_base_libdir}/firmware/rtl_nic/*.fw \
+"
 
 RDEPENDS:${PN}-rtl8188 += "${PN}-rtl-license"
 RDEPENDS:${PN}-rtl8192ce += "${PN}-rtl-license"
@@ -862,6 +870,7 @@ RDEPENDS:${PN}-rtl8821 += "${PN}-rtl-license"
 RDEPENDS:${PN}-rtl8761 += "${PN}-rtl-license"
 RDEPENDS:${PN}-rtl8822 += "${PN}-rtl-license"
 RDEPENDS:${PN}-rtl8168 += "${PN}-whence-license"
+RDEPENDS:${PN}-rtl-nic += "${PN}-whence-license"
 
 # For TI wl1251
 LICENSE:${PN}-wl1251 = "Firmware-wl1251"
@@ -1325,6 +1334,9 @@ FILES:${PN}-qat-license   = 
"${nonarch_base_libdir}/firmware/LICENCE.qat_firmwar
 FILES:${PN}-qat   = "${nonarch_base_libdir}/firmware/qat*.bin"
 RDEPENDS:${PN}-qat= "${PN}-qat-license"
 
+LICENSE:${PN}-qed = "WHENCE"
+FILES:${PN}-qed   = "${nonarch_base_libdir}/firmware/qed/*"
+
 # For QCOM VPU/GPU and SDM845
 LICENSE:${PN}-qcom-license = "Firmware-qcom"
 LICENSE:${PN}-qcom-yamato-license = "Firmware-qcom-yamato"
@@ -1467,6 +1479,12 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = 
"${PN}-qcom-sc8280xp-lenov
 
 FILES:${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
 
+FILES:${PN}-mellanox = "${nonarch_base_libdir}/firmware/mellanox"
+
+LICENSE:${PN}-prestera = "Firmware-Marvell"
+FILES:${PN}-prestera = "${nonarch_base_libdir}/firmware/mrvl/prestera"
+RDEPENDS:${PN}-prestera = "${PN}-marvell-license"
+
 # For Rockchip
 LICENSE:${PN}-rockchip-dptx = "Firmware-rockchip"
 FILES:${PN}-rockchip-license = 
"${nonarch_base_libdir}/firmware/LICENCE.rockchip"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196438): 
https://lists.openembedded.org/g/openembedded-core/message/196438
Mute This Topic: https://lists.openembedded.org/mt/104646418/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] python3-attrs - turn deadline off?

[Tim Orling]

On Thu, Feb 29, 2024 at 12:25 AM Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> I noticed this failures:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/6139
>
> which leads to:
>
>
> http://autobuilder.yocto.io/pub/non-release/20240228-36/testresults/qemuarm64-ptest/python3-attrs.log
>
> which says:
>
> """
> Unreliable test timings! On an initial run, this test took 268.29ms,
> which exceeded the deadline of 200.00ms, but on a subsequent run it
> took 2.63 ms, which did not. If you expect this sort of variability in
> your test timings, consider turning deadlines off for this test by
> setting deadline=None.
> """
>
> This warning is coming from python3-hypothesis, and is totally no obvious
from the test case itself
https://github.com/python-attrs/attrs/blob/23.2.0/tests/test_make.py#L1318C1-L1337C24

@given(integers(), booleans())
def test_converter_factory_property(self, val, init):
"""
Property tests for attributes with converter, and a factory default.
"""
C = make_class(
"C",
{
"y": attr.ib(),
"x": attr.ib(
init=init,
default=Factory(lambda: val),
converter=lambda v: v + 1,
),
},
)
c = C(2)

assert c.x == val + 1
assert c.y == 2

Related:
https://github.com/HypothesisWorks/hypothesis/issues/3713

Is there a setting we should be considering?
>
> Cheers,
>
> Richard
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196437): 
https://lists.openembedded.org/g/openembedded-core/message/196437
Mute This Topic: https://lists.openembedded.org/mt/104640034/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] core-image-full-cmdline: add package-management

[Michael Opdenacker via lists.openembedded.org]

From: Michael Opdenacker 

Add "package-management" image feature to the core-image-full-cmdline image,
to support package upgrade testing.

Signed-off-by: Michael Opdenacker 
Suggested-by: Richard Purdie 
---
 meta/recipes-extended/images/core-image-full-cmdline.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/images/core-image-full-cmdline.bb 
b/meta/recipes-extended/images/core-image-full-cmdline.bb
index 4e1cf58d55..b034cd0aeb 100644
--- a/meta/recipes-extended/images/core-image-full-cmdline.bb
+++ b/meta/recipes-extended/images/core-image-full-cmdline.bb
@@ -1,7 +1,7 @@
 SUMMARY = "A console-only image with more full-featured Linux system \
 functionality installed."
 
-IMAGE_FEATURES += "splash ssh-server-openssh"
+IMAGE_FEATURES += "splash ssh-server-openssh package-management"
 
 IMAGE_INSTALL = "\
 packagegroup-core-boot \
-- 
2.34.1


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

Re: [OE-core] [PATCH] linux-yocto: update yocto-kernel-cache to fix CONFIG_DEBUG_CREDENTIALS warnings

[Bruce Ashfield]

On Thu, Feb 29, 2024 at 5:49 AM Ross Burton  wrote:
>
> From: Ross Burton 
>
> Incorporate the fix for upstream removing CONFIG_DEBUG_CREDENTIALS in
> the stable branch.

Please don't merge this, it makes handling my local patch queue more difficult
to handle.

I have more kernel changes staged and this will come out with that series.

Bruce

>
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-kernel/linux/linux-yocto_6.6.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/linux/linux-yocto_6.6.bb 
> b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
> index 2d218692e28..beb26281215 100644
> --- a/meta/recipes-kernel/linux/linux-yocto_6.6.bb
> +++ b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
> @@ -29,7 +29,7 @@ SRCREV_machine:qemux86 ?= 
> "e064a7d658a30b027b999183e21cd37305caff2a"
>  SRCREV_machine:qemux86-64 ?= "e064a7d658a30b027b999183e21cd37305caff2a"
>  SRCREV_machine:qemumips64 ?= "52456b6cb3393c1848da3ccdae37727c31896f1c"
>  SRCREV_machine ?= "e064a7d658a30b027b999183e21cd37305caff2a"
> -SRCREV_meta ?= "c97276cdc9d89cceef61184e296e5c837a265ed1"
> +SRCREV_meta ?= "229dc6171461800d7b4ab16f9c8b35a47a48897f"
>
>  # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
> you'll
>  # get the /base branch, which is pure upstream -stable, and the same
> --
> 2.34.1
>
>
> 
>


-- 
- 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 (#196435): 
https://lists.openembedded.org/g/openembedded-core/message/196435
Mute This Topic: https://lists.openembedded.org/mt/104640975/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] login.py: Proof of concept for screenshot testcases

[Eilís 'pidge' Ní Fhlannagáin]

This takes the work rburton did on image screenshot testing and
expands it.

Right now this works with most of the qemu based machines except for

- qemuppc64
- qemuarmv5
- qemuriscv32
- qemuloongarch64

See "Known Issues" further down.

This test takes a screendump of a qemu image, blanks out the clock
and compares it to an image we have on record. If the diff is exact,
the test passes. If not, it stores the image in build/failed-images and
fails out.

In order to enable this test, you will need meta-openembedded/meta-oe in
your bblayers.conf for imagemagick and the following in local.conf:

IMAGE_CLASSES += "testimage"
TEST_SUITES = "login"
TESTIMAGEDEPENDS:append:qemuall = " imagemagick-native:do_populate_sysroot "

Known Issues


The main issue is that I've yet to find a gating factor that would allow
me to tell when the qemu instance is fully up and rendered. I've tried a
few tactics here, (dbus-wait, qmp) but for now a disgusting
time.sleep(30) is there.

You can replicate this by running qemumips. The screen load takes forever,
but you even see it on qemux86 where the Home and Workspace Switch icons
will sometimes take a while to fully load.

Eventually I'm going to have to take multiple screenshots and compare
them, but then you get into the issue where the question is, is the diff
greater than 0 because it hasn't fully loaded or something is actually
incorrect.

There are the issues I know about:

   - runqemu qemuppc64 comes up blank.
   - qemuarmv5 comes up with multiple heads but sending "head" to screendump.
 seems to create a png with a bad header.
   - qemuriscv32 and qemuloongarch64 don't work with testimage apparently?
   - qemumips64 is missing mouse icon.
   - qemumips takes forever to render and is missing mouse icon.
   - qemuarm and qemuppc return incorrect width
   - All images have home and screen flipper icons not always rendered fully at 
first.
 The sleep seems to help this out some, depending on machine load.

Signed-off-by: Eilís 'pidge' Ní Fhlannagáin 
Co-authored-by: Ross Burton 
Co-authored-by: Eilís 'pidge' Ní Fhlannagáin 
---
 meta/lib/oeqa/runtime/cases/login.py | 107 +++
 1 file changed, 107 insertions(+)
 create mode 100644 meta/lib/oeqa/runtime/cases/login.py

diff --git a/meta/lib/oeqa/runtime/cases/login.py 
b/meta/lib/oeqa/runtime/cases/login.py
new file mode 100644
index 000..aea3bfc778e
--- /dev/null
+++ b/meta/lib/oeqa/runtime/cases/login.py
@@ -0,0 +1,107 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+import subprocess
+from oeqa.runtime.case import OERuntimeTestCase
+import tempfile
+from oeqa.runtime.decorator.package import OEHasPackage
+
+### Status of qemu images.
+#   - runqemu qemuppc64 comes up blank. (skip)
+#   - qemuarmv5 comes up with multiple heads but sending "head" to screendump.
+# seems to create a png with a bad header? (skip for now, but come back to 
fix)
+#   - qemuriscv32 and qemuloongarch64 doesn't work with testimage apparently? 
(skip)
+#   - qemumips64 is missing mouse icon.
+#   - qemumips takes forever to render and is missing mouse icon.
+#   - qemuarm and qemuppc are odd as they don't resize so we need to just set 
width.
+#   - All images have home and screen flipper icons not always rendered fully 
at first.
+# the sleep seems to help this out some, depending on machine load.
+###
+
+class LoginTest(OERuntimeTestCase):
+def test_screenshot(self):
+if self.td.get('MACHINE') in ("qemuppc64", "qemuarmv5", "qemuriscv32", 
"qemuloongarch64"):
+self.skipTest("{0} is not currently 
supported.".format(self.td.get('MACHINE')))
+
+# Set DEBUG_CREATE_IMAGES to 1 in order to populate the image-test 
images directory.
+DEBUG_CREATE_IMAGES="0"
+# Store failed images so we can debug them.
+failed_image_dir=self.td.get('TOPDIR') + "/failed-images/"
+
+###
+# This is a really horrible way of doing this but I've not found the
+# right event to determine "The system is loaded and screen is 
rendered"
+#
+# Using dbus-wait for matchbox is the wrong answer because while it
+# ensures the system is up, it doesn't mean the screen is rendered.
+#
+# Checking the qmp socket doesn't work afaik either.
+#
+# One way to do this is to do compares of known good screendumps until
+# we either get expected or close to expected or we time out. Part of 
the
+# issue here with that is that there is a very fine difference in the
+# diff between a screendump where the icons haven't loaded yet and
+# one where they won't load. I'll look at that next, but, for now, 
this.
+#
+# Which is ugly and I hate it but it 'works' for various definitions of
+# 'works'.
+###
+
+import time
+
+# qemumips takes forever to render. We could probably get away with 20

[OE-core] [PATCH 2/4] qemurunner.py: Fix error on calls to run_monitor

[Eilís 'pidge' Ní Fhlannagáin]

A change in QEMUMonitorProtocol.cmd() requires that we either pass in
kwargs instead of an argument dict or move to cmd_raw()

cmd() was renamed to cmd_raw() (and command() was renamed to cmd())
See:
https://github.com/qemu/qemu/commit/37274707f6f3868fae7e0055d9a703006fc142d0
https://github.com/qemu/qemu/commit/684750ab4f8a3ad69512b71532408be3ac2547d4

My concern with this patch is that I haven't seen this come up with
utils/dump.py which also uses QemuMonitor's run_monitor. If it is
occuring, this should fix issues there as well

Signed-off-by: Eilís 'pidge' Ní Fhlannagáin 
---
 meta/lib/oeqa/utils/qemurunner.py | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 277cd328484..cda43aad8c5 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -650,9 +650,9 @@ class QemuRunner:
 if hasattr(self, 'qmp') and self.qmp:
 self.qmp.settimeout(timeout)
 if args is not None:
-return self.qmp.cmd(command, args)
+return self.qmp.cmd_raw(command, args)
 else:
-return self.qmp.cmd(command)
+return self.qmp.cmd_raw(command)
 
 def run_serial(self, command, raw=False, timeout=60):
 # Returns (status, output) where status is 1 on success and 0 on error
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196432): 
https://lists.openembedded.org/g/openembedded-core/message/196432
Mute This Topic: https://lists.openembedded.org/mt/104641611/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] sstatetests.py: Add testing for correct sstate permissions

[Eilís 'pidge' Ní Fhlannagáin]

This patch adds to run_test_sstate_creation so that it also tests
that sstate directories don't accidentally pickup umask permissions
from the user upon creation.

Signed-off-by: Eilís 'pidge' Ní Fhlannagáin 
---
 meta/lib/oeqa/selftest/cases/sstatetests.py | 28 -
 1 file changed, 27 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/sstatetests.py 
b/meta/lib/oeqa/selftest/cases/sstatetests.py
index 56dfcdb0f39..c5581d52628 100644
--- a/meta/lib/oeqa/selftest/cases/sstatetests.py
+++ b/meta/lib/oeqa/selftest/cases/sstatetests.py
@@ -79,7 +79,7 @@ class SStateBase(OESelftestTestCase):
 result.append(f)
 return result
 
-# Test sstate files creation and their location
+# Test sstate files creation and their location and directory perms
 def run_test_sstate_creation(self, targets, distro_specific=True, 
distro_nonspecific=True, temp_sstate_location=True, should_pass=True):
 self.config_sstate(temp_sstate_location, [self.sstate_path])
 
@@ -88,6 +88,19 @@ class SStateBase(OESelftestTestCase):
 else:
 bitbake(['-ccleansstate'] + targets)
 
+# We need to test that the env umask have does not effect sstate 
directory creation
+# So, first, we'll get the current umask and set it to something we 
know incorrect
+# See: sstate_task_postfunc for correct umask of os.umask(0o002)
+import os
+def current_umask():
+current_umask = os.umask(0)
+os.umask(current_umask)
+return current_umask 
+
+orig_umask = current_umask()
+# Set it to a umask we know will be 'wrong'
+os.umask(0o022)
+
 bitbake(targets)
 file_tracker = []
 results = self.search_sstate('|'.join(map(str, targets)), 
distro_specific, distro_nonspecific)
@@ -104,6 +117,19 @@ class SStateBase(OESelftestTestCase):
 else:
 self.assertTrue(not file_tracker , msg="Found sstate files in the 
wrong place for: %s (found %s)" % (', '.join(map(str, targets)), 
str(file_tracker)))
 
+# Now we'll walk the tree to check the mode and see if things are 
incorrect.
+badperms = []
+for root, dirs, files in os.walk(self.sstate_path):
+for directory in dirs:
+if str(oct(os.stat(os.path.join(root, directory)).st_mode & 
0o777)) != "0o775":
+badperms.append(os.path.join(root, directory))
+
+# Return to original umask
+os.umask(orig_umask)
+
+if should_pass:
+self.assertTrue(badperms , msg="Found sstate directories with the 
wrong permissions: %s (found %s)" % (', '.join(map(str, targets)), 
str(badperms)))
+
 # Test the sstate files deletion part of the do_cleansstate task
 def run_test_cleansstate_task(self, targets, distro_specific=True, 
distro_nonspecific=True, temp_sstate_location=True):
 self.config_sstate(temp_sstate_location, [self.sstate_path])
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196431): 
https://lists.openembedded.org/g/openembedded-core/message/196431
Mute This Topic: https://lists.openembedded.org/mt/104641610/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/4] image-tests and sstate permissions testing

[Eilís 'pidge' Ní Fhlannagáin]

This patch series implements image-testing proof of concept and 
sstate permissions testing for self test. It fixes an issue in qemurunner due to
changes in QEMUMonitorProtocol.cmd() and adds test png images to compare against
for the image-testing.

Eilís 'pidge' Ní Fhlannagáin (4):
  sstatetests.py: Add testing for correct sstate permissions
  qemurunner.py: Fix error on calls to run_monitor
  image-tests: Add initial image test png files
  login.py: Proof of concept for screenshot testcases

 .../image-tests/core-image-sato-qemuarm.png   | Bin 0 -> 52405 bytes
 .../image-tests/core-image-sato-qemuarm64.png | Bin 0 -> 47505 bytes
 .../image-tests/core-image-sato-qemumips.png  | Bin 0 -> 46634 bytes
 .../core-image-sato-qemumips64.png| Bin 0 -> 46053 bytes
 .../image-tests/core-image-sato-qemuppc.png   | Bin 0 -> 52232 bytes
 .../core-image-sato-qemuriscv64.png   | Bin 0 -> 38806 bytes
 .../image-tests/core-image-sato-qemux86.png   | Bin 0 -> 46548 bytes
 meta/lib/oeqa/runtime/cases/login.py  | 107 ++
 meta/lib/oeqa/selftest/cases/sstatetests.py   |  28 -
 meta/lib/oeqa/utils/qemurunner.py |   4 +-
 10 files changed, 136 insertions(+), 3 deletions(-)
 create mode 100644 meta/files/image-tests/core-image-sato-qemuarm.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemuarm64.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemumips.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemumips64.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemuppc.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemuriscv64.png
 create mode 100644 meta/files/image-tests/core-image-sato-qemux86.png
 create mode 100644 meta/lib/oeqa/runtime/cases/login.py

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196430): 
https://lists.openembedded.org/g/openembedded-core/message/196430
Mute This Topic: https://lists.openembedded.org/mt/104641606/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 V5] systemd: fix a dead link under /var/log

[Peter Kjellerstedt]

> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Alexander Kanavin
> Sent: den 29 februari 2024 10:01
> To: Changqing Li 
> Cc: Changqing Li ; 
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V5] systemd: fix a dead link under /var/log
> 
> On Thu, 29 Feb 2024 at 06:56, Changqing Li  wrote:
> > The solution is also good. But package "${docdir}/systemd/README.logs"
> > in package systemd may make things more complicated.
> >
> > since in bitabke .conf, ${PN}-doc is before ${PN} in PACKAGES, and
> > FILES:${PN}-doc = "${docdir}  ...". we need to adjust the sequence,
> >
> > and may have influences to current list of files and directories that
> > are placed in a package.
> >
> > So maybe this patch is more simple and reasonable, and will not have
> > other impact.
> 
> That's right. It's possible but not obvious how to override that (I
> don't remember that from memory).
> 
> > That's ok, but can you make fixing the path to an absolute one a
> > separate, second commit then?
> >
> > if  use solution in this patch,  it is better they are in one commit.  I
> > can update description more detail.
> 
> Please no. These are two separate issues, let's deal with them as
> separate changes.
> 
> Alex

Given how much churn this patch has generated for a file that probably 
no one will read, how about just not creating it in the first place? 
That is what we do with the following patch:

From 49483effbcb920d097487c58214518f2f3a9d479 Mon Sep 17 00:00:00 2001
From: Yang Lyu 
Date: Mon, 20 Jun 2022 09:07:19 +0200
Subject: [PATCH] Do not create README in log directory

---
 tmpfiles.d/legacy.conf.in | 3 ---
 1 file changed, 3 deletions(-)

diff --git a/tmpfiles.d/legacy.conf.in b/tmpfiles.d/legacy.conf.in
index 4f2c0d7c43..62e2ae0986 100644
--- a/tmpfiles.d/legacy.conf.in
+++ b/tmpfiles.d/legacy.conf.in
@@ -12,9 +12,6 @@

 d /run/lock 0755 root root -
 L /var/lock - - - - ../run/lock
-{% if CREATE_LOG_DIRS %}
-L /var/log/README - - - - ../..{{DOC_DIR}}/README.logs
-{% endif %}

 # /run/lock/subsys is used for serializing SysV service execution, and
 # hence without use on SysV-less systems.

//Peter


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

[OE-core] [PATCH] linux-yocto: update yocto-kernel-cache to fix CONFIG_DEBUG_CREDENTIALS warnings

[Ross Burton]

From: Ross Burton 

Incorporate the fix for upstream removing CONFIG_DEBUG_CREDENTIALS in
the stable branch.

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux/linux-yocto_6.6.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto_6.6.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
index 2d218692e28..beb26281215 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.6.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.6.bb
@@ -29,7 +29,7 @@ SRCREV_machine:qemux86 ?= 
"e064a7d658a30b027b999183e21cd37305caff2a"
 SRCREV_machine:qemux86-64 ?= "e064a7d658a30b027b999183e21cd37305caff2a"
 SRCREV_machine:qemumips64 ?= "52456b6cb3393c1848da3ccdae37727c31896f1c"
 SRCREV_machine ?= "e064a7d658a30b027b999183e21cd37305caff2a"
-SRCREV_meta ?= "c97276cdc9d89cceef61184e296e5c837a265ed1"
+SRCREV_meta ?= "229dc6171461800d7b4ab16f9c8b35a47a48897f"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.34.1


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

Re: [OE-core][PATCH 1/2] bash: add locale alias for ja_JP shiftjis in run-ptest

[Xiangyu Chen]

On 2/29/24 18:09, Alexander Kanavin wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Thu, 29 Feb 2024 at 11:00, Xiangyu Chen
 wrote:


And also i met a problem, most of cases are comparing test log with
pre-test log from maintainer as the test result that line
number/space/path/new line is produced causes diff failed,

but in fact they are not a real test failure, the result still need to
verify by manual, seems cannot do the automation test, any suggestion on
that?

All of this seems to indicate that the bash test suite is not meant
for independent execution, and is only intended for bash maintainers.
Perhaps you should clarify this with them first, and then also point
out specific problems you are facing. Basically, engage with bash
upstream, and see if they're interested in helping you to improve
tests to the point where we can re-enable them. If there's no such
interest, we shouldn't have to continuously add fixes and workarounds.

Whether the whole effort is worth your time is a question I leave for
you to answer :)


Aha, thanks for your information :)

Yes, from the result, it seems only intended for bash maintainers and 
not fit for other automation yet.


I think firstly i need to check the history of bash maillist to see 
whether others sent this topic and the result of discussion on that.



Thanks :D


Br,

Xiangyu




Alex

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

Re: [OE-core][PATCH 1/2] bash: add locale alias for ja_JP shiftjis in run-ptest

[Alexander Kanavin]

On Thu, 29 Feb 2024 at 11:00, Xiangyu Chen
 wrote:

> And also i met a problem, most of cases are comparing test log with
> pre-test log from maintainer as the test result that line
> number/space/path/new line is produced causes diff failed,
>
> but in fact they are not a real test failure, the result still need to
> verify by manual, seems cannot do the automation test, any suggestion on
> that?

All of this seems to indicate that the bash test suite is not meant
for independent execution, and is only intended for bash maintainers.
Perhaps you should clarify this with them first, and then also point
out specific problems you are facing. Basically, engage with bash
upstream, and see if they're interested in helping you to improve
tests to the point where we can re-enable them. If there's no such
interest, we shouldn't have to continuously add fixes and workarounds.

Whether the whole effort is worth your time is a question I leave for
you to answer :)

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196426): 
https://lists.openembedded.org/g/openembedded-core/message/196426
Mute This Topic: https://lists.openembedded.org/mt/104599698/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] waf: Improve version parsing to avoid failing on warnings

[Yoann Congal]

waf uses an inline tar file extracted by the tarfile module. The tarfile
module may print a warning when used with default 'filter' argument[0].

When called to get the version, the first time after unpack, the output
may look like:
  # output from lower modules (e.g: warnings from tarfile, ...)
  waf X.Y.Z ...

This patch makes the version parsing more precise by looking at the
first line matching "waf ".

[0]: https://docs.python.org/3.12/library/tarfile.html#extraction-filters

Signed-off-by: Yoann Congal 
---
 meta/classes-recipe/waf.bbclass | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/waf.bbclass b/meta/classes-recipe/waf.bbclass
index 70bf3be8fd..01707c8e2c 100644
--- a/meta/classes-recipe/waf.bbclass
+++ b/meta/classes-recipe/waf.bbclass
@@ -54,11 +54,21 @@ python waf_preconfigure() {
 wafbin = os.path.join(subsrcdir, 'waf')
 try:
 result = subprocess.check_output([python, wafbin, '--version'], 
cwd=subsrcdir, stderr=subprocess.STDOUT)
-version = result.decode('utf-8').split()[1]
-if not bb.utils.is_semver(version):
+# Output looks like:
+#  # output from lower modules (e.g. warnings, ...)
+#  waf X.Y.Z ...
+# So, look for the line starting with "waf "
+version = None
+for line in result.decode('utf-8').split("\n"):
+if line.startswith("waf "):
+version = line.split()[1]
+break
+
+if not version or not bb.utils.is_semver(version):
 bb.warn("Unable to parse \"waf --version\" output. Assuming waf 
version without bindir/libdir support.")
 bb.warn("waf·--version·output = \n%s" % result.decode('utf-8'))
 elif bb.utils.vercmp_string_op(version, "1.8.7", ">="):
+bb.note("waf version is high enough to add --bindir and --libdir")
 d.setVar("WAF_EXTRA_CONF", "--bindir=${bindir} --libdir=${libdir}")
 except subprocess.CalledProcessError as e:
 bb.warn("Unable to execute waf --version, exit code %d. Assuming waf 
version without bindir/libdir support." % e.returncode)
-- 
2.39.2


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

Re: [OE-core][PATCH 1/2] bash: add locale alias for ja_JP shiftjis in run-ptest

[Xiangyu Chen]

On 2/28/24 17:38, Alexander Kanavin wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Wed, 28 Feb 2024 at 03:45, Xiangyu Chen
 wrote:

Since SHIFTJIS is not a ISO2022/posix compliant and not in the list of
glibc locale data support, it was generated by manual with localedef and
don't have a unified name.


The following name has been already found on different linux:

ja_JP.SJIS ja_JP.SHIFT_JIS ja_JP.shiftjis japanese.sjis

Hello Chen,

I need to note that we specifically exclude bash from ptests, and this
is the reason:
https://git.yoctoproject.org/poky/commit/?id=2758f6d0337ec84c9143546bc65a80559e8d7808

Hi Alex,


As a result, bash ptest would keep regressing in various ways, simply
because it's not executed, and I would suggest that you either first
fix these failures, so we can restore bash in
meta/conf/distro/include/ptests-packagelists.inc, or drop bash from
your own testing. Is there a particular reason you need to run those
tests?


Thanks for your information, recently I am trying to fix the bash ptest 
failures.


Currently, in my local setup with master oe, the test failure is 5(total 
83).  The failed cases are run-intl run-type run-array run-execscript 
run-read.


After checking the failure log,  the following is a simple of failure 
cases analysis:


1) run-array: egrep output warning messages cause the final log is 
different from pre-log. A patch has been sent to bash bug-report list to use


grep -v -e instead of egrep[1].

2) run-type: there is a patch need to rebase, fix has been merged to 
oe-core master[2]


3) run-execscript: it reports the failure but not really failed, it just 
differing only in line numbers is produced.


4) run-intl: due to no shiftjis locale in system, some of unicode tests 
were skipped. That cause actually run 1251 cases mismatch with total 
1378 cases.


5) run-read failure cannot 100% reproduce, when it failed, a character 
was missing in test log, still in debugging..



And also i met a problem, most of cases are comparing test log with 
pre-test log from maintainer as the test result that line 
number/space/path/new line is produced causes diff failed,


but in fact they are not a real test failure, the result still need to 
verify by manual, seems cannot do the automation test, any suggestion on 
that?



Thanks,


Ref:

[1] https://lists.gnu.org/archive/html/bug-bash/2024-02/msg00154.html

[2] 
https://git.openembedded.org/openembedded-core/commit/?id=ecb698ca5b4f76937dd3bee927465b17866d50be




Br,

Xiangyu




Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196424): 
https://lists.openembedded.org/g/openembedded-core/message/196424
Mute This Topic: https://lists.openembedded.org/mt/104599698/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] [RFC OE-core][PATCH v2 1/7] go: rework patch to avoid identation

[Jose Quaresma]

Richard Purdie  escreveu (quinta,
29/02/2024 à(s) 08:18):

> On Wed, 2024-02-28 at 21:16 -0800, Khem Raj wrote:
> > Fails to compile bunch of  recipes using go e.g. influxdb, crucible,
> > syzkaller in meta-oe see
> >
> >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3667/steps/15/logs/stdio
>
> Also fails for oe-selftest:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/6415/steps/14/logs/stdio
>
> and on arm hosts:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/7999/steps/13/logs/stdio



Thanks for testing, I will take a look on all of this today.

Jose


>
>
> Cheers,
>
> Richard
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196423): 
https://lists.openembedded.org/g/openembedded-core/message/196423
Mute This Topic: https://lists.openembedded.org/mt/104628621/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 V5] systemd: fix a dead link under /var/log

[Alexander Kanavin]

On Thu, 29 Feb 2024 at 06:56, Changqing Li  wrote:
> The solution is also good. But package "${docdir}/systemd/README.logs" in 
> package systemd may make things more complicated.
>
> since in bitabke .conf, ${PN}-doc is before ${PN} in PACKAGES, and  
> FILES:${PN}-doc = "${docdir}  ...". we need to adjust the sequence,
>
> and may have influences to current list of files and directories that are 
> placed in a package.
>
> So maybe this patch is more simple and reasonable, and will not have other 
> impact.

That's right. It's possible but not obvious how to override that (I
don't remember that from memory).

> That's ok, but can you make fixing the path to an absolute one a
> separate, second commit then?
>
> if  use solution in this patch,  it is better they are in one commit.  I can 
> update description more detail.

Please no. These are two separate issues, let's deal with them as
separate changes.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196422): 
https://lists.openembedded.org/g/openembedded-core/message/196422
Mute This Topic: https://lists.openembedded.org/mt/104598170/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] [RFC PATCH 0/1] package.bbclass: Expose list of split out debug files

[Alexander Kanavin]

On Thu, 29 Feb 2024 at 09:20, Philip Lorenz  wrote:
> > One possibility is teaching it to mass-import pre-computed entries
> > into its index, so that sweeping file tree scans with archive
> > extractions can be avoided altogether. Or doing incremental index
> > imports directly from do_package.
> Producing this data is exactly what this RFC is about. Using the
> extracted build ID information to optimize the import into debuginfod is
> one of the possible use cases but I'd also suggest to keep the extracted
> data agnostic of any concrete tooling (e.g. pkgdata).

This is fair enough. But you need to think upfront about how producing
this data should be tested with just oe-core/poky and what use cases
it could have. Simple sanity check is ok, but improving debuginfod to
import the pre-computed values is much better. Maybe something else
too?

This also allows you to develop and publish the alternative service on
its own schedule and terms, if the code is not mature or BMW legal is
having a hard time signing off on making it public etc. We don't need
to see it, if there's a use case in core.

Alex

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

[OE-core] python3-attrs - turn deadline off?

[Richard Purdie]

I noticed this failures:

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/6139

which leads to:

http://autobuilder.yocto.io/pub/non-release/20240228-36/testresults/qemuarm64-ptest/python3-attrs.log

which says:

"""
Unreliable test timings! On an initial run, this test took 268.29ms,
which exceeded the deadline of 200.00ms, but on a subsequent run it
took 2.63 ms, which did not. If you expect this sort of variability in
your test timings, consider turning deadlines off for this test by
setting deadline=None.
"""

Is there a setting we should be considering?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196420): 
https://lists.openembedded.org/g/openembedded-core/message/196420
Mute This Topic: https://lists.openembedded.org/mt/104640034/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] [RFC PATCH 0/1] package.bbclass: Expose list of split out debug files

[Philip Lorenz]

Hi Alex,

On 28.02.24 18:40, Alexander Kanavin wrote:

On Wed, 28 Feb 2024 at 16:41, Philip Lorenz  wrote:

I'm assuming this data wouldn't be that large or that expensive to
compute so I'd prefer not to hide it behind extra configuration options
if we can help it. That does depend on the overheads/costs though.


I just executed build ID extraction on the debug packages of our medium
sized kirkstone based distro (see my reply to Alex for more details).
Sequentially extracting build IDs from around 8000 files took around
1:30 minutes on my machine. While I wouldn't call this excessive, I am
also not sure whether this is too much overhead given that I only expect
this data to be used in some deployments.

I have to object to the numbers because they were done with a
sequential shell loop. Debuginfod does it in threads and is able to
complete the scans much faster. So you need to check how quickly it
completes its job when started with oe-debuginfod rather. There might
be an improvement coming from what you are proposing, but it's most
likely not going to be as drastic.


I think there's some misunderstanding that I'd like to sort out first: 
This is in no way about deprecating or not using debuginfod. It however 
is an optimization on how build IDs are extracted which can be used by a 
variety of tools (such as debuginfod). As such a sequential scan should 
give a rough idea on how much time it takes to extract the build IDs 
during do_package (wall clock time is bound to differ). Based on this we 
can see that its not free but also not extremely expensive although I'd 
like to leave the judgement call on whether this something that should 
be enabled on all builds to someone else.



There's also something else I noticed just now: there seems to be an
alternative implementation of debuginfod you want to introduce? Why?
If the original from elfutils isn't working well enough, shouldn't we
make it better?


Let try to give you some sort of insight of how we are planning to use 
it and I hope this clarifies things:


In our case we are dealing with hundreds of bitbake builds whose 
artifacts (including package feeds) are published to some storage 
accessible via a HTTP. We would now like to offer a service that gives 
developers access to the debug files in a seamless way (i.e. we want to 
eliminate the process of manually having to download the debug packages 
matching a particular build). To accomplish this, our setup is based 
around a lightweight "gateway" daemon that translates a debuginfo HTTP 
request into a fetch of the corresponding package from the matching 
repository, extracting the debug symbol file and then serving that to 
the requesting client.


This is quite different to the way debuginfod works (which seems to be 
built around the idea of having the debug symbol files readily available 
via the file system) and I also see advantages in that approach when one 
has a fairly static set of debug symbol files one wants to serve. 
There's also some other non-functional requirements that would make 
deployment of debuginfod in our case quite difficult.


This is no way meant to be a fully fledged debuginfod reimplementation 
but a simple gateway between the debuginfod protocol and a backing 
package repository. I am not sure whether such an extension is in scope 
of the elfutils package.

One possibility is teaching it to mass-import pre-computed entries
into its index, so that sweeping file tree scans with archive
extractions can be avoided altogether. Or doing incremental index
imports directly from do_package.
Producing this data is exactly what this RFC is about. Using the 
extracted build ID information to optimize the import into debuginfod is 
one of the possible use cases but I'd also suggest to keep the extracted 
data agnostic of any concrete tooling (e.g. pkgdata).


Br,

Philip

--
Philip Lorenz
BMW Car IT GmbH, Software-Plattform, -Integration Connected Company, 
Lise-Meitner-Straße 14, 89081 Ulm
-
BMW Car IT GmbH
Management: Chris Brandt and Michael Böttrich
Domicile and Court of Registry: München HRB 134810
-


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196419): 
https://lists.openembedded.org/g/openembedded-core/message/196419
Mute This Topic: https://lists.openembedded.org/mt/104619206/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] [RFC OE-core][PATCH v2 1/7] go: rework patch to avoid identation

[Richard Purdie]

On Wed, 2024-02-28 at 21:16 -0800, Khem Raj wrote:
> Fails to compile bunch of  recipes using go e.g. influxdb, crucible,
> syzkaller in meta-oe see
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3667/steps/15/logs/stdio

Also fails for oe-selftest:

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/6415/steps/14/logs/stdio

and on arm hosts:

https://autobuilder.yoctoproject.org/typhoon/#/builders/97/builds/7999/steps/13/logs/stdio

Cheers,

Richard

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