Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-4.0.12.rc2)

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-4.0.12.rc2. 
We are planning to execute following tests for this cycle:
 
OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw
 
Runtime auto test for following platforms:
1. MinnowBoard Turbot - 32bit
2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors)
3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors)
4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors)
5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors)
6. Edgerouter
7. Beaglebone

 
ETA for completion next Wednesday, 16 Aug 2023.
 
Best regards,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Wednesday, August 9, 2023 7:35 AM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-4.0.12.rc2)
> 
> 
> A build flagged for QA (yocto-4.0.12.rc2) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-4.0.12.rc2
> 
> 
> Build hash information:
> 
> bitbake: 41b6684489d0261753344956042be2cc4adb0159
> meta-agl: 45b1b63c35c52b8283e1893dfa099607baa0cdcc
> meta-arm: c39bb4ce3b60b73d35c5fb06af012432e70d6b38
> meta-aws: 723a8a04965af482fe65e8e56eabea858858bd88
> meta-gplv2: d2f8b5cdb285b72a4ed93450f6703ca27aa42e8a
> meta-intel: 1aacdb4ed1e639cc6e19c541b058264eb17eb093
> meta-mingw: a90614a6498c3345704e9611f2842eb933dc51c1
> meta-openembedded: 4da92ed9be41734f6ced46b981958e2e868cbff2
> meta-virtualization: af02908efda1580e77b3fdeed25b124a2b8d9482
> oecore: e1a604db8d2cf8782038b4016cc2e2052467333b
> poky: d6b8790370500b99ca11f0d8a05c39b661ab2ba6
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 
> 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185686): 
https://lists.openembedded.org/g/openembedded-core/message/185686
Mute This Topic: https://lists.openembedded.org/mt/100638041/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 0/7] linux-yocto: consolidated kernel pull request

[Bruce Ashfield]

On Tue, Aug 8, 2023 at 4:49 PM Alexandre Belloni
 wrote:
>
> On 08/08/2023 13:09:50-0400, Bruce Ashfield wrote:
> > On Tue, Aug 8, 2023 at 8:49 AM Bruce Ashfield via
> > lists.openembedded.org
> >  wrote:
> > >
> > > On Tue, Aug 8, 2023 at 6:43 AM Alexandre Belloni
> > >  wrote:
> > > >
> > > > Hello Bruce,
> > > >
> > > > While I didn't test this series yet, as discussed, I've tried to switch
> > > > to 6.4 by default. I got this warning:
> > >
> > > -tiny was clean here, but let me re-test and see if I've missed
> > > sending something in my 6.4 SRCREV bumps.
> > >
> >
> > Which Machine is this ? (I always have a hard time figuring that out
> > .. sad, I know).
> >
>
> This was qemuarm.
>

Ack'd.

I tested that config before sending the new recipes, but I've started
a new build with my latest and qemuarm.

I'll follow up on Wednesday when I know more.

Bruce

> > I have this series of commits:
> >
> > commit fa08cd6bd6f9415c91da0dd72f4338bff3c68c68
> > Author: Bruce Ashfield 
> > Date:   Mon Jul 10 11:21:58 2023 -0400
> >
> > tiny: enable HID in tiny BSPs
> >
> > HID is no longer selected, so to avoid -tiny warnings we need to
> > explicitly enable it in more -tiny BSPs.
> >
> > Signed-off-by: Bruce Ashfield 
> >
> > :100644 100644 0fa5dae7ec9 51d597039c3 M
> > bsp/arm-versatile-926ejs/arm-versatile-926ejs-tiny.scc
> > :100644 100644 e4928b43416 5fdb341638a M
> > bsp/qemuarm64/qemuarm64-tiny.scc
> >
> > commit 4655de57a68a86e651fcea2eb2c7e88f3de3bbfb
> > Author: Bruce Ashfield 
> > Date:   Fri Jul 7 14:00:08 2023 -0400
> >
> > common-pc-64/tiny: enable HID by default
> >
> > Signed-off-by: Bruce Ashfield 
> >
> > :100644 100644 7fcac7fd54a 0d083b0d2a5 M
> > bsp/common-pc-64/common-pc-64-tiny.scc
> >
> > commit 252c55e236cb46860bae0fd1b1e0641e6e8dd512
> > Author: Bruce Ashfield 
> > Date:   Fri Jul 7 10:39:41 2023 -0400
> >
> > common-pc/tiny: enable HID by default
> >
> > Signed-off-by: Bruce Ashfield 
> >
> > :100644 100644 687414ae671 9fe725ac450 M
> > bsp/common-pc/common-pc-tiny.scc
> >
> > commit 849f920aa1b7c76c0be6c1054c5efb758ca07600
> > Author: Bruce Ashfield 
> > Date:   Fri Jul 7 10:36:39 2023 -0400
> >
> > cfg: add CONFIG_HID base fragment
> >
> > When testing the -tiny kernel against v6.4, configuration warnings
> > were noticed as CONFIG_HID is disabled by our baseline allnoconfig.
> >
> > We have BSPs that require HID support for drivers, and they will
> > warn when building a -tiny variant.
> >
> > Introducing a HID base fragment so they can share the enabling of
> > these options as required.
> >
> > Signed-off-by: Bruce Ashfield 
> >
> > :00 100644 000 cfd84dbda45 Afeatures/hid/hid.cfg
> > :00 100644 000 28d242df7ad Afeatures/hid/hid.scc
> >
> > But if this is showing up on the AB, I must have missed an instance.
> >
> > My test build was just clean.
> >
> > Bruce
> >
> >
> > > Bruce
> > >
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7876/steps/13/logs/stdio
> > > >
> > > > WARNING: linux-yocto-tiny-6.4.3+gitAUTOINC+dab56f52aa_dee78ad196-r0 
> > > > do_kernel_configcheck: [kernel config]: specified values did not make 
> > > > it into the kernel's final configuration:
> > > > [NOTE]: 'CONFIG_USB_HID' last val (y) and .config val (n) do not 
> > > > match
> > > > [INFO]: CONFIG_USB_HID : n
> > > > [INFO]: raw config text:
> > > > config USB_HID
> > > > tristate "USB HID transport layer"
> > > > default y
> > > > select HID
> > > > depends on USB && INPUT && USB && HID_SUPPORT
> > > > help
> > > >   Say Y here if you want to connect USB keyboards,
> > > >   mice, joysticks, graphic tablets, or any other HID 
> > > > based devices
> > > >   to your computer via USB, as well as Uninterruptible 
> > > > Power Supply
> > > >   (UPS) and monitor control devices.
> > > >
> > > >   You can't use this driver and the HIDBP (Boot 
> > > > Protocol) keyboard
> > > >   and mouse drivers at the same time. More information 
> > > > is available:
> > > >   .
> > > >
> > > >   If unsure, say Y.
> > > >
> > > >   To compile this driver as a module, choose M here: the
> > > >   module will be called usbhid.
> > > > Config 'USB_HID' has the following Direct dependencies 
> > > > (USB_HID=n):
> > > > USB(=y) && INPUT(=y) && HID_SUPPORT(=n)
> > > > Parent dependencies are:
> > > >  INPUT [y] USB [y] HID_SUPPORT [n]
> > > > [INFO]: config 'CONFIG_USB_HID' was set, but it wasn't assignable, 
> > > > check (parent) dependencies
> > > >
> > > >
> > > > master has 86adbe4db668 ("linux-yocto-tiny/6.4: fix configuration
> > > > warnings (HID)") so I guess 

[OE-core] [PATCH 2/2] linux-yocto/6.4: fix qemuarm boot failure

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/6.4:

72bad8cd7540 drm/fb-helper: move zeroing code to drm_fb_helper_fill_var

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_6.4.bb   |  2 +-
 .../linux/linux-yocto-tiny_6.4.bb |  2 +-
 meta/recipes-kernel/linux/linux-yocto_6.4.bb  | 22 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
index c624b2dac8..8cc39faf9c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
@@ -14,7 +14,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "0bcc161e5d456bcbcfa6852e5e7750636a00ce46"
+SRCREV_machine ?= "121d700ad4b877fab9238a92356ad32506ef70d5"
 SRCREV_meta ?= "8dc4f68eb852784a5bc82d30768ac3276c890754"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
 \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
index 409a95e633..834d07be48 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
@@ -17,7 +17,7 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
+SRCREV_machine ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
 SRCREV_meta ?= "8dc4f68eb852784a5bc82d30768ac3276c890754"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.4.bb
index 527b09087c..4deb7bc537 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.4.bb
@@ -17,17 +17,17 @@ KBRANCH:qemux86-64 ?= "v6.4/standard/base"
 KBRANCH:qemuloongarch64  ?= "v6.4/standard/base"
 KBRANCH:qemumips64 ?= "v6.4/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "4d6b5d3235770e00b35d53c0dd33827624e0dba3"
-SRCREV_machine:qemuarm64 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemuloongarch64 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemumips ?= "1504fdd2f568bf0f39042b69e282a9e6042594a1"
-SRCREV_machine:qemuppc ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemuriscv64 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemuriscv32 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemux86 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemux86-64 ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
-SRCREV_machine:qemumips64 ?= "a55946081548eb8b23d5e1da3aa7f469addef1c8"
-SRCREV_machine ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
+SRCREV_machine:qemuarm ?= "16af0b21320a78b21d5d9ded1188e398352d262a"
+SRCREV_machine:qemuarm64 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemuloongarch64 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemumips ?= "de46701cb3ac494b27ae70f1475efb855e9d817a"
+SRCREV_machine:qemuppc ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemuriscv64 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemuriscv32 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemux86 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemux86-64 ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
+SRCREV_machine:qemumips64 ?= "47d7881e76d678cc9dc034f0acdd1bc416fa05bb"
+SRCREV_machine ?= "72bad8cd7540f07ab54e08b83ad106dec0df123c"
 SRCREV_meta ?= "8dc4f68eb852784a5bc82d30768ac3276c890754"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185684): 
https://lists.openembedded.org/g/openembedded-core/message/185684
Mute This Topic: https://lists.openembedded.org/mt/100636967/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] linux-yocto/6.4: update to v6.4.9

[Bruce Ashfield]

From: Bruce Ashfield 

Updating  to the latest korg -stable release that comprises
the following commits:

38ca69782268 Linux 6.4.9
2692b1574ad9 x86: fix backwards merge of GDS/SRSO bit
cf482893f721 xen/netback: Fix buffer overrun triggered by unusual packet
9b73a2a43f4d x86/srso: Tie SBPB bit setting to microcode patch detection
4974bd4b1385 x86/srso: Add a forgotten NOENDBR annotation
b155f54a92b0 x86/srso: Fix return thunks in generated code
b31eb84b6756 x86/srso: Add IBPB on VMEXIT
948e43310c20 x86/srso: Add IBPB
bf46b6249f26 x86/srso: Add SRSO_NO support
dc399c66209b x86/srso: Add IBPB_BRTYPE support
acdc883eb61e x86/srso: Add a Speculative RAS Overflow mitigation
d351cc7c14a6 x86/bugs: Increase the x86 bugs vector size to two u32s
7be4a6b1128c Documentation/x86: Fix backwards on/off logic about YMM support
2f94fb4a4231 x86/xen: Fix secondary processors' FPU initialization
6a592d977a0d x86/mem_encrypt: Unbreak the AMD_MEM_ENCRYPT=n build
6f29afbba8fc KVM: Add GDS_NO support to KVM
4da542e6b2bb x86/speculation: Add Kconfig option for GDS
c73393948612 x86/speculation: Add force option to GDS mitigation
ff0642207e24 x86/speculation: Add Gather Data Sampling mitigation
71c140aa6327 x86/fpu: Move FPU initialization into arch_cpu_finalize_init()
7e56c238ff4a x86/fpu: Mark init functions __init
6c69f14c3e67 x86/fpu: Remove cpuinfo argument from init functions
121887418638 x86/init: Initialize signal frame size late
03e244a37a41 init, x86: Move mem_encrypt_init() into 
arch_cpu_finalize_init()
5dc85ed21b9c init: Invoke arch_cpu_finalize_init() earlier
f9a4f2ba337c init: Remove check_bugs() leftovers
50455d685b65 um/cpu: Switch to arch_cpu_finalize_init()
4b61f3683da0 sparc/cpu: Switch to arch_cpu_finalize_init()
65b2da915cf9 sh/cpu: Switch to arch_cpu_finalize_init()
09afafc754b3 mips/cpu: Switch to arch_cpu_finalize_init()
626fefa0ba15 m68k/cpu: Switch to arch_cpu_finalize_init()
3868a6a35c95 loongarch/cpu: Switch to arch_cpu_finalize_init()
2156182d8f66 ia64/cpu: Switch to arch_cpu_finalize_init()
81da5576db4e ARM: cpu: Switch to arch_cpu_finalize_init()
f2aef93c0bc7 x86/cpu: Switch to arch_cpu_finalize_init()
e5b3acb81bd2 init: Provide arch_cpu_finalize_init()

Signed-off-by: Bruce Ashfield 
---

Richard,

These two patches should be applied to the end of my latest
consolidated pull request to pickup the latest 6.4-stable
and Jon's qemuarm boot fix.

Bruce

 .../linux/linux-yocto-rt_6.4.bb   |  6 ++--
 .../linux/linux-yocto-tiny_6.4.bb |  6 ++--
 meta/recipes-kernel/linux/linux-yocto_6.4.bb  | 28 +--
 3 files changed, 20 insertions(+), 20 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
index 53961cb9b3..c624b2dac8 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.4.bb
@@ -14,13 +14,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "dea7f1321a72454808398aba37090cb8543d68c2"
-SRCREV_meta ?= "50e8722be4cd4fe25f03d5a26ea88fb199c8b41a"
+SRCREV_machine ?= "0bcc161e5d456bcbcfa6852e5e7750636a00ce46"
+SRCREV_meta ?= "8dc4f68eb852784a5bc82d30768ac3276c890754"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine;protocol=https
 \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.4;destsuffix=${KMETA};protocol=https"
 
-LINUX_VERSION ?= "6.4.8"
+LINUX_VERSION ?= "6.4.9"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
index 950df14f26..409a95e633 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.4.bb
@@ -8,7 +8,7 @@ require recipes-kernel/linux/linux-yocto.inc
 # CVE exclusions
 include recipes-kernel/linux/cve-exclusion_6.4.inc
 
-LINUX_VERSION ?= "6.4.8"
+LINUX_VERSION ?= "6.4.9"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -17,8 +17,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "5545fd447acbc5d280c783e1e1c73a3e2ef7f54a"
-SRCREV_meta ?= "50e8722be4cd4fe25f03d5a26ea88fb199c8b41a"
+SRCREV_machine ?= "80174b01645669e6d83c7c1532fa2661438ba49d"
+SRCREV_meta ?= "8dc4f68eb852784a5bc82d30768ac3276c890754"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.4.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.4.bb
index 5badb65731..527b09087c 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.4.bb
+++ 

[OE-core] [PATCH] pm-utils: Do not require GNU grep at runtime

[Khem Raj]

This was added to fix bug reported here [1]

back then busybox grep applet did not implement -x option
and it would fail as reported in the bug, in due course
busybox now has implemented -x option [2] and the expression

using grep -x in /usr/lib/pm-utils/functions:219 works fine

[1] https://bugzilla.yoctoproject.org/show_bug.cgi?id=1887
[2] 
https://git.busybox.net/busybox/commit/?id=cd09e81520b7917adebcffd7c361671f913325eb

Signed-off-by: Khem Raj 
---
 meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb 
b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
index dcc09f279ef..2c3ade99347 100644
--- a/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
+++ b/meta/recipes-bsp/pm-utils/pm-utils_1.4.1.bb
@@ -17,7 +17,7 @@ inherit pkgconfig autotools manpages
 
 PACKAGECONFIG[manpages] = "--enable-doc, --disable-doc, libxslt-native 
xmlto-native"
 
-RDEPENDS:${PN} = "grep bash"
+RDEPENDS:${PN} = "bash"
 
 EXTRA_OECONF = "--libdir=${nonarch_libdir}"
 
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185682): 
https://lists.openembedded.org/g/openembedded-core/message/185682
Mute This Topic: https://lists.openembedded.org/mt/100634624/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: Fix mediatek mt7601u firmware path

[Marek Vasut]

The following linux-firmware commit moved the mt7601u firmware blob
into a mediatek/ subdirectory, update the path accordingly.
8451c2b1 ("mt76xx: Move the old Mediatek WiFi firmware to mediatek")

Fixes: 64603f602d ("linux-firmware: upgrade 20230404 -> 20230515")
Signed-off-by: Marek Vasut 
---
Cc: Alexander Kanavin 
Cc: Alexandre Belloni 
Cc: Richard Purdie 
Cc: Trevor Gamblin 
Cc: Steve Sakoman 
---
NOTE: It would be good to apply to kirkstone and dunfell too
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
index 3c88bdeb7e..6765226b9d 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20230625.bb
@@ -419,7 +419,7 @@ LICENSE:${PN}-mt7601u-license = 
"Firmware-ralink_a_mediatek_company_firmware"
 
 FILES:${PN}-mt7601u-license = 
"${nonarch_base_libdir}/firmware/LICENCE.ralink_a_mediatek_company_firmware"
 FILES:${PN}-mt7601u = " \
-  ${nonarch_base_libdir}/firmware/mt7601u.bin \
+  ${nonarch_base_libdir}/firmware/mediatek/mt7601u.bin \
 "
 
 RDEPENDS:${PN}-mt7601u += "${PN}-mt7601u-license"
-- 
2.40.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185681): 
https://lists.openembedded.org/g/openembedded-core/message/185681
Mute This Topic: https://lists.openembedded.org/mt/100634395/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] systemd-boot: enable verbose compilation

[Khem Raj]

On Tue, Aug 8, 2023 at 4:00 PM Jose Quaresma 
wrote:

>
>
> Khem Raj  escreveu no dia terça, 8/08/2023 à(s) 18:05:
>
>> On Tue, Aug 8, 2023 at 9:08 AM Jose Quaresma 
>> wrote:
>> >
>> > Signed-off-by: Jose Quaresma 
>> > ---
>> >  meta/recipes-core/systemd/systemd-boot_254.bb | 2 +-
>> >  1 file changed, 1 insertion(+), 1 deletion(-)
>> >
>> > diff --git a/meta/recipes-core/systemd/systemd-boot_254.bb
>> b/meta/recipes-core/systemd/systemd-boot_254.bb
>> > index 5d69cf83ab..b91bbfe485 100644
>> > --- a/meta/recipes-core/systemd/systemd-boot_254.bb
>> > +++ b/meta/recipes-core/systemd/systemd-boot_254.bb
>> > @@ -53,7 +53,7 @@ COMPATIBLE_HOST =
>> "(aarch64.*|arm.*|x86_64.*|i.86.*)-linux"
>> >  COMPATIBLE_HOST:x86-x32 = "null"
>> >
>> >  do_compile() {
>> > -   ninja systemd-boot
>> > +   ninja -v systemd-boot
>>
>> I think this is only useful during debugging. So perhaps a comment to
>> enable it is better than enabling it always.
>>
>
> The meson bbclass also compile with verbose so in my opinion it is better
> to do the same
> and make it consistent with the main systemd recipe
>
> meson_do_compile() {
> meson compile -v ${PARALLEL_MAKE}
> }
>

Ideally we only want the verbosity when something goes wrong and meson
ninja etc are good at that with their defaults perhaps that -v should be
turned off by default as well

>
>
> Jose
>
>
>> >  }
>> >
>> >  do_install() {
>> > --
>> > 2.34.1
>> >
>> >
>> > 
>> >
>>
>
>
> --
> Best regards,
>
> José Quaresma
>

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

[Jose Quaresma]

Ping!

Jose Quaresma via lists.openembedded.org  escreveu no dia segunda, 7/08/2023 à(s)
15:26:

> Last version of systemd dpends now on pyelftools to build the efi support
> but the required tool is the native ones and not the target.
> The systemd-boot has the corrected dependencie so fix this in the main
> recipe.
>
> | Program python3 (jinja2) found: YES
> (/build/tmp-lmp/work/corei7-64-lmp-linux/systemd/1_254-r0/recipe-sysroot-native/usr/bin/python3-native/python3)
> modules: jinja2
> | Checking if "32bit build possible" : links: NO
> | Program python3 (elftools) found: NO
> |
> | ../git/meson.build:2147:8: ERROR: Problem encountered: EFI bootloader
> support requires pyelftools.
> |
> | A full log can be found at
> /build/tmp-lmp/work/corei7-64-lmp-linux/systemd/1_254-r0/build/meson-logs/meson-log.txt
>
> Signed-off-by: Jose Quaresma 
> ---
>  meta/recipes-core/systemd/systemd_254.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd_254.bb
> b/meta/recipes-core/systemd/systemd_254.bb
> index ea1a4f02f0..cd2a021da2 100644
> --- a/meta/recipes-core/systemd/systemd_254.bb
> +++ b/meta/recipes-core/systemd/systemd_254.bb
> @@ -142,7 +142,7 @@ PACKAGECONFIG[default-compression-lz4] = "-Dlz4=true
> -Ddefault-compression=lz4,,
>  PACKAGECONFIG[default-compression-xz] = "-Dxz=true
> -Ddefault-compression=xz,,xz"
>  PACKAGECONFIG[default-compression-zstd] = "-Dzstd=true
> -Ddefault-compression=zstd,,zstd"
>  PACKAGECONFIG[dbus] = "-Ddbus=true,-Ddbus=false,dbus"
> -PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=true,-Defi=false
> -Dbootloader=false,python3-pyelftools"
> +PACKAGECONFIG[efi] = "-Defi=true -Dbootloader=true,-Defi=false
> -Dbootloader=false,python3-pyelftools-native"
>  PACKAGECONFIG[elfutils] = "-Delfutils=true,-Delfutils=false,elfutils"
>  PACKAGECONFIG[firstboot] = "-Dfirstboot=true,-Dfirstboot=false"
>  PACKAGECONFIG[repart] = "-Drepart=true,-Drepart=false"
> --
> 2.34.1
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185679): 
https://lists.openembedded.org/g/openembedded-core/message/185679
Mute This Topic: https://lists.openembedded.org/mt/100600508/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] systemd-boot: enable verbose compilation

[Jose Quaresma]

Khem Raj  escreveu no dia terça, 8/08/2023 à(s) 18:05:

> On Tue, Aug 8, 2023 at 9:08 AM Jose Quaresma 
> wrote:
> >
> > Signed-off-by: Jose Quaresma 
> > ---
> >  meta/recipes-core/systemd/systemd-boot_254.bb | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/systemd/systemd-boot_254.bb
> b/meta/recipes-core/systemd/systemd-boot_254.bb
> > index 5d69cf83ab..b91bbfe485 100644
> > --- a/meta/recipes-core/systemd/systemd-boot_254.bb
> > +++ b/meta/recipes-core/systemd/systemd-boot_254.bb
> > @@ -53,7 +53,7 @@ COMPATIBLE_HOST =
> "(aarch64.*|arm.*|x86_64.*|i.86.*)-linux"
> >  COMPATIBLE_HOST:x86-x32 = "null"
> >
> >  do_compile() {
> > -   ninja systemd-boot
> > +   ninja -v systemd-boot
>
> I think this is only useful during debugging. So perhaps a comment to
> enable it is better than enabling it always.
>

The meson bbclass also compile with verbose so in my opinion it is better
to do the same
and make it consistent with the main systemd recipe

meson_do_compile() {
meson compile -v ${PARALLEL_MAKE}
}

Jose


> >  }
> >
> >  do_install() {
> > --
> > 2.34.1
> >
> >
> > 
> >
>


-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185678): 
https://lists.openembedded.org/g/openembedded-core/message/185678
Mute This Topic: https://lists.openembedded.org/mt/100625045/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 0/7] linux-yocto: consolidated kernel pull request

[Alexandre Belloni via lists.openembedded.org]

On 08/08/2023 13:09:50-0400, Bruce Ashfield wrote:
> On Tue, Aug 8, 2023 at 8:49 AM Bruce Ashfield via
> lists.openembedded.org
>  wrote:
> >
> > On Tue, Aug 8, 2023 at 6:43 AM Alexandre Belloni
> >  wrote:
> > >
> > > Hello Bruce,
> > >
> > > While I didn't test this series yet, as discussed, I've tried to switch
> > > to 6.4 by default. I got this warning:
> >
> > -tiny was clean here, but let me re-test and see if I've missed
> > sending something in my 6.4 SRCREV bumps.
> >
> 
> Which Machine is this ? (I always have a hard time figuring that out
> .. sad, I know).
> 

This was qemuarm.

> I have this series of commits:
> 
> commit fa08cd6bd6f9415c91da0dd72f4338bff3c68c68
> Author: Bruce Ashfield 
> Date:   Mon Jul 10 11:21:58 2023 -0400
> 
> tiny: enable HID in tiny BSPs
> 
> HID is no longer selected, so to avoid -tiny warnings we need to
> explicitly enable it in more -tiny BSPs.
> 
> Signed-off-by: Bruce Ashfield 
> 
> :100644 100644 0fa5dae7ec9 51d597039c3 M
> bsp/arm-versatile-926ejs/arm-versatile-926ejs-tiny.scc
> :100644 100644 e4928b43416 5fdb341638a M
> bsp/qemuarm64/qemuarm64-tiny.scc
> 
> commit 4655de57a68a86e651fcea2eb2c7e88f3de3bbfb
> Author: Bruce Ashfield 
> Date:   Fri Jul 7 14:00:08 2023 -0400
> 
> common-pc-64/tiny: enable HID by default
> 
> Signed-off-by: Bruce Ashfield 
> 
> :100644 100644 7fcac7fd54a 0d083b0d2a5 M
> bsp/common-pc-64/common-pc-64-tiny.scc
> 
> commit 252c55e236cb46860bae0fd1b1e0641e6e8dd512
> Author: Bruce Ashfield 
> Date:   Fri Jul 7 10:39:41 2023 -0400
> 
> common-pc/tiny: enable HID by default
> 
> Signed-off-by: Bruce Ashfield 
> 
> :100644 100644 687414ae671 9fe725ac450 M
> bsp/common-pc/common-pc-tiny.scc
> 
> commit 849f920aa1b7c76c0be6c1054c5efb758ca07600
> Author: Bruce Ashfield 
> Date:   Fri Jul 7 10:36:39 2023 -0400
> 
> cfg: add CONFIG_HID base fragment
> 
> When testing the -tiny kernel against v6.4, configuration warnings
> were noticed as CONFIG_HID is disabled by our baseline allnoconfig.
> 
> We have BSPs that require HID support for drivers, and they will
> warn when building a -tiny variant.
> 
> Introducing a HID base fragment so they can share the enabling of
> these options as required.
> 
> Signed-off-by: Bruce Ashfield 
> 
> :00 100644 000 cfd84dbda45 Afeatures/hid/hid.cfg
> :00 100644 000 28d242df7ad Afeatures/hid/hid.scc
> 
> But if this is showing up on the AB, I must have missed an instance.
> 
> My test build was just clean.
> 
> Bruce
> 
> 
> > Bruce
> >
> > >
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7876/steps/13/logs/stdio
> > >
> > > WARNING: linux-yocto-tiny-6.4.3+gitAUTOINC+dab56f52aa_dee78ad196-r0 
> > > do_kernel_configcheck: [kernel config]: specified values did not make it 
> > > into the kernel's final configuration:
> > > [NOTE]: 'CONFIG_USB_HID' last val (y) and .config val (n) do not match
> > > [INFO]: CONFIG_USB_HID : n
> > > [INFO]: raw config text:
> > > config USB_HID
> > > tristate "USB HID transport layer"
> > > default y
> > > select HID
> > > depends on USB && INPUT && USB && HID_SUPPORT
> > > help
> > >   Say Y here if you want to connect USB keyboards,
> > >   mice, joysticks, graphic tablets, or any other HID 
> > > based devices
> > >   to your computer via USB, as well as Uninterruptible 
> > > Power Supply
> > >   (UPS) and monitor control devices.
> > >
> > >   You can't use this driver and the HIDBP (Boot Protocol) 
> > > keyboard
> > >   and mouse drivers at the same time. More information is 
> > > available:
> > >   .
> > >
> > >   If unsure, say Y.
> > >
> > >   To compile this driver as a module, choose M here: the
> > >   module will be called usbhid.
> > > Config 'USB_HID' has the following Direct dependencies 
> > > (USB_HID=n):
> > > USB(=y) && INPUT(=y) && HID_SUPPORT(=n)
> > > Parent dependencies are:
> > >  INPUT [y] USB [y] HID_SUPPORT [n]
> > > [INFO]: config 'CONFIG_USB_HID' was set, but it wasn't assignable, 
> > > check (parent) dependencies
> > >
> > >
> > > master has 86adbe4db668 ("linux-yocto-tiny/6.4: fix configuration
> > > warnings (HID)") so I guess there is something missing.
> > >
> > >
> > > On 07/08/2023 23:35:46-0400, Bruce Ashfield wrote:
> > > > From: Bruce Ashfield 
> > > >
> > > > Richard,
> > > >
> > > > Here's my queued set of -stable updates (as well as a -dev kernel bump).
> > > >
> > > > I've got another round of updates under test, and will send them when
> > > > ready.
> > > >
> > > > 6.4 marches along, it'll be up to date when those last issues keeping
> > > > it from being the default are resolved.
> > > >
> 

Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated kernel pull request

[Bruce Ashfield]

On Tue, Aug 8, 2023 at 8:49 AM Bruce Ashfield via
lists.openembedded.org
 wrote:
>
> On Tue, Aug 8, 2023 at 6:43 AM Alexandre Belloni
>  wrote:
> >
> > Hello Bruce,
> >
> > While I didn't test this series yet, as discussed, I've tried to switch
> > to 6.4 by default. I got this warning:
>
> -tiny was clean here, but let me re-test and see if I've missed
> sending something in my 6.4 SRCREV bumps.
>

Which Machine is this ? (I always have a hard time figuring that out
.. sad, I know).

I have this series of commits:

commit fa08cd6bd6f9415c91da0dd72f4338bff3c68c68
Author: Bruce Ashfield 
Date:   Mon Jul 10 11:21:58 2023 -0400

tiny: enable HID in tiny BSPs

HID is no longer selected, so to avoid -tiny warnings we need to
explicitly enable it in more -tiny BSPs.

Signed-off-by: Bruce Ashfield 

:100644 100644 0fa5dae7ec9 51d597039c3 M
bsp/arm-versatile-926ejs/arm-versatile-926ejs-tiny.scc
:100644 100644 e4928b43416 5fdb341638a Mbsp/qemuarm64/qemuarm64-tiny.scc

commit 4655de57a68a86e651fcea2eb2c7e88f3de3bbfb
Author: Bruce Ashfield 
Date:   Fri Jul 7 14:00:08 2023 -0400

common-pc-64/tiny: enable HID by default

Signed-off-by: Bruce Ashfield 

:100644 100644 7fcac7fd54a 0d083b0d2a5 M
bsp/common-pc-64/common-pc-64-tiny.scc

commit 252c55e236cb46860bae0fd1b1e0641e6e8dd512
Author: Bruce Ashfield 
Date:   Fri Jul 7 10:39:41 2023 -0400

common-pc/tiny: enable HID by default

Signed-off-by: Bruce Ashfield 

:100644 100644 687414ae671 9fe725ac450 Mbsp/common-pc/common-pc-tiny.scc

commit 849f920aa1b7c76c0be6c1054c5efb758ca07600
Author: Bruce Ashfield 
Date:   Fri Jul 7 10:36:39 2023 -0400

cfg: add CONFIG_HID base fragment

When testing the -tiny kernel against v6.4, configuration warnings
were noticed as CONFIG_HID is disabled by our baseline allnoconfig.

We have BSPs that require HID support for drivers, and they will
warn when building a -tiny variant.

Introducing a HID base fragment so they can share the enabling of
these options as required.

Signed-off-by: Bruce Ashfield 

:00 100644 000 cfd84dbda45 Afeatures/hid/hid.cfg
:00 100644 000 28d242df7ad Afeatures/hid/hid.scc

But if this is showing up on the AB, I must have missed an instance.

My test build was just clean.

Bruce


> Bruce
>
> >
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7876/steps/13/logs/stdio
> >
> > WARNING: linux-yocto-tiny-6.4.3+gitAUTOINC+dab56f52aa_dee78ad196-r0 
> > do_kernel_configcheck: [kernel config]: specified values did not make it 
> > into the kernel's final configuration:
> > [NOTE]: 'CONFIG_USB_HID' last val (y) and .config val (n) do not match
> > [INFO]: CONFIG_USB_HID : n
> > [INFO]: raw config text:
> > config USB_HID
> > tristate "USB HID transport layer"
> > default y
> > select HID
> > depends on USB && INPUT && USB && HID_SUPPORT
> > help
> >   Say Y here if you want to connect USB keyboards,
> >   mice, joysticks, graphic tablets, or any other HID based 
> > devices
> >   to your computer via USB, as well as Uninterruptible 
> > Power Supply
> >   (UPS) and monitor control devices.
> >
> >   You can't use this driver and the HIDBP (Boot Protocol) 
> > keyboard
> >   and mouse drivers at the same time. More information is 
> > available:
> >   .
> >
> >   If unsure, say Y.
> >
> >   To compile this driver as a module, choose M here: the
> >   module will be called usbhid.
> > Config 'USB_HID' has the following Direct dependencies (USB_HID=n):
> > USB(=y) && INPUT(=y) && HID_SUPPORT(=n)
> > Parent dependencies are:
> >  INPUT [y] USB [y] HID_SUPPORT [n]
> > [INFO]: config 'CONFIG_USB_HID' was set, but it wasn't assignable, 
> > check (parent) dependencies
> >
> >
> > master has 86adbe4db668 ("linux-yocto-tiny/6.4: fix configuration
> > warnings (HID)") so I guess there is something missing.
> >
> >
> > On 07/08/2023 23:35:46-0400, Bruce Ashfield wrote:
> > > From: Bruce Ashfield 
> > >
> > > Richard,
> > >
> > > Here's my queued set of -stable updates (as well as a -dev kernel bump).
> > >
> > > I've got another round of updates under test, and will send them when
> > > ready.
> > >
> > > 6.4 marches along, it'll be up to date when those last issues keeping
> > > it from being the default are resolved.
> > >
> > > Bruce
> > >
> > > The following changes since commit 
> > > 058a44165ce375f405063e73a9fcd1b2757ef8da:
> > >
> > >   bitbake: fetch2: Check if path is 'None' before calculating checksums 
> > > (2023-08-04 11:48:26 +0100)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://git.yoctoproject.org/poky-contrib zedd/kernel
> > >   

Re: [OE-core][PATCH 1/2] systemd-boot: enable verbose compilation

[Khem Raj]

On Tue, Aug 8, 2023 at 9:08 AM Jose Quaresma  wrote:
>
> Signed-off-by: Jose Quaresma 
> ---
>  meta/recipes-core/systemd/systemd-boot_254.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>
> diff --git a/meta/recipes-core/systemd/systemd-boot_254.bb 
> b/meta/recipes-core/systemd/systemd-boot_254.bb
> index 5d69cf83ab..b91bbfe485 100644
> --- a/meta/recipes-core/systemd/systemd-boot_254.bb
> +++ b/meta/recipes-core/systemd/systemd-boot_254.bb
> @@ -53,7 +53,7 @@ COMPATIBLE_HOST = "(aarch64.*|arm.*|x86_64.*|i.86.*)-linux"
>  COMPATIBLE_HOST:x86-x32 = "null"
>
>  do_compile() {
> -   ninja systemd-boot
> +   ninja -v systemd-boot

I think this is only useful during debugging. So perhaps a comment to
enable it is better than enabling it always.

>  }
>
>  do_install() {
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185675): 
https://lists.openembedded.org/g/openembedded-core/message/185675
Mute This Topic: https://lists.openembedded.org/mt/100625045/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] systemd issue with network commandline config and 6.4 kernel

[Richard Purdie]

On Tue, 2023-08-08 at 12:13 -0400, Bruce Ashfield wrote:
> On Tue, Aug 8, 2023 at 11:35 AM Chen Qi via lists.openembedded.org
>  wrote:
> > 
> > I found some clue, but not the root cause yet.
> > The eth0 is renamed to enp0s2 by 80-net-setup-link.rules udev rule in 
> > systemd. And the connman.conf only blacklists eth0.
> > 
> > The related log is:
> > Aug 08 15:18:16 qemux86-64 kernel[213]: [1.727332] virtio_net virtio0 
> > enp0s2: renamed from eth0 (while UP)
> > 
> > The systemd udev configuration file is:
> > root@qemux86-64:~# cat /lib/udev/rules.d/80-net-setup-link.rules
> > # do not edit this file, it will be overwritten on update
> > SUBSYSTEM!="net", GOTO="net_setup_link_end"
> > IMPORT{builtin}="path_id"
> > ACTION=="remove", GOTO="net_setup_link_end"
> > IMPORT{builtin}="net_setup_link"
> > NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
> > LABEL="net_setup_link_end"
> > 
> > And the connman configuration file is:
> > root@qemux86-64:~# cat /etc/connman/main.conf
> > [General]
> > NetworkInterfaceBlacklist = eth0
> > 
> > In contrary, with 6.1 kernel, the renaming failed with the following 
> > message:
> > Aug 08 15:29:58 qemux86-64 (udev-worker)[206]: enp0s2: Network interface 
> > 'eth0' is already up, cannot rename to 'enp0s2'.
> > 
> > Maybe some changes in new kernel allows renaming network interface while 
> > it's up?
> 
> This brings back a memory of something I ran into on a build server
> when upgrading to a "newer" 6.2 kernel,
> 
> I had to disable interface renaming in order to get a consistent
> network configuration, and did that via "net.ifnames=0" on the kernel
> command line.

Thanks, Qi and Bruce, this all starts to make more sense now.

I've sent a patch adding "net.ifnames=0" to the two places we need it
to fix runqemu usage which fixed the issue in my local testing.

Cheers,

Richard



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

[OE-core] [PATCH] qemuboot/runqemu: Fix 6.2 and later kernel network device naming

[Richard Purdie]

With kernel 6.2 and later network devices are renamed by systemd. This does not
match with the current network device naming assumed in our configuration.

We may or may not change that naming but for now, pass the right kernel 
commandline
so things work as expected with newer kernels and removing a blocker on 
upgrading
to the 6.4 kernel by default.

Signed-off-by: Richard Purdie 
---
 meta/classes-recipe/qemuboot.bbclass | 2 +-
 scripts/runqemu  | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/classes-recipe/qemuboot.bbclass 
b/meta/classes-recipe/qemuboot.bbclass
index 444871438da..12d0a509f13 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -102,7 +102,7 @@ QB_RNG ?= "-object rng-random,filename=/dev/urandom,id=rng0 
-device virtio-rng-p
 QB_OPT_APPEND ?= ""
 QB_NETWORK_DEVICE ?= "-device virtio-net-pci,netdev=net0,mac=@MAC@"
 QB_CMDLINE_IP_SLIRP ?= "ip=dhcp"
-QB_CMDLINE_IP_TAP ?= 
"ip=192.168.7.@CLIENT@::192.168.7.@GATEWAY@:255.255.255.0::eth0:off:8.8.8.8"
+QB_CMDLINE_IP_TAP ?= 
"ip=192.168.7.@CLIENT@::192.168.7.@GATEWAY@:255.255.255.0::eth0:off:8.8.8.8 
net.ifnames=0"
 QB_ROOTFS_EXTRA_OPT ?= ""
 QB_GRAPHICS ?= ""
 QB_NFSROOTFS_EXTRA_OPT ?= ""
diff --git a/scripts/runqemu b/scripts/runqemu
index 5e6793d44e5..0e105a918b1 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -203,7 +203,7 @@ class BaseConfig(object):
 self.fsinfo = {}
 self.network_device = "-device e1000,netdev=net0,mac=@MAC@"
 self.cmdline_ip_slirp = "ip=dhcp"
-self.cmdline_ip_tap = 
"ip=192.168.7.@CLIENT@::192.168.7.@GATEWAY@:255.255.255.0::eth0:off:8.8.8.8"
+self.cmdline_ip_tap = 
"ip=192.168.7.@CLIENT@::192.168.7.@GATEWAY@:255.255.255.0::eth0:off:8.8.8.8 
net.ifnames=0"
 # Use different mac section for tap and slirp to avoid
 # conflicts, e.g., when one is running with tap, the other is
 # running with slirp.
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185673): 
https://lists.openembedded.org/g/openembedded-core/message/185673
Mute This Topic: https://lists.openembedded.org/mt/100626228/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] gnu-efi: Fix build on musl

[Alexander Kanavin]

I think this doesn’t have to be musl specific, werror by default is a bad
idea in general and conditional patches are a pain to maintain. Also it
should be proposed upstream.

Alex

On Tue 8. Aug 2023 at 18.50, Khem Raj  wrote:

> Build with musl emits extra warnings about pointer incompatibility due
> to different type of wchar_t than glibc which turns to be error in the
> end, disable -Werror for musl.
>
> Signed-off-by: Khem Raj 
> ---
>  .../recipes-bsp/gnu-efi/gnu-efi/no-werror.patch | 17 +
>  meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb  |  1 +
>  2 files changed, 18 insertions(+)
>  create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
>
> diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
> b/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
> new file mode 100644
> index 000..2d7ad740723
> --- /dev/null
> +++ b/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
> @@ -0,0 +1,17 @@
> +Do not treat warnings as errors on musl
> +
> +There are additional warnings found with musl which may not be treated as
> errors
> +
> +Signed-off-by: Khem Raj 
> +Upstream-Status: Inappropriate [musl specific]
> +--- a/Make.defaults
>  b/Make.defaults
> +@@ -187,7 +187,7 @@ CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wex
> +-funsigned-char -fshort-wchar -fno-strict-aliasing \
> +-ffreestanding -fno-stack-protector
> + else
> +-CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wextra -Wno-pointer-sign -Werror \
> ++CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wextra -Wno-pointer-sign \
> +-funsigned-char -fshort-wchar -fno-strict-aliasing \
> +  -ffreestanding -fno-stack-protector -fno-stack-check \
> +-fno-stack-check \
> diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
> b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
> index d37d638e097..819d376f9d9 100644
> --- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
> +++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
> @@ -18,6 +18,7 @@ SRC_URI =
> "${SOURCEFORGE_MIRROR}/${BPN}/files/${BP}.tar.bz2 \
> file://0001-riscv64-adjust-type-definitions.patch \
> file://0001-riscv64-ignore-unknown-relocs.patch \
> "
> +SRC_URI:append:libc-musl = " file://no-werror.patch"
>
>  SRC_URI[sha256sum] =
> "7807e903349343a7a142ebb934703a2872235e89688cf586c032b0a1087bcaf4"
>
> --
> 2.41.0
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185672): 
https://lists.openembedded.org/g/openembedded-core/message/185672
Mute This Topic: https://lists.openembedded.org/mt/100626020/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] gnu-efi: Fix build on musl

[Khem Raj]

Build with musl emits extra warnings about pointer incompatibility due
to different type of wchar_t than glibc which turns to be error in the
end, disable -Werror for musl.

Signed-off-by: Khem Raj 
---
 .../recipes-bsp/gnu-efi/gnu-efi/no-werror.patch | 17 +
 meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb  |  1 +
 2 files changed, 18 insertions(+)
 create mode 100644 meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch

diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch 
b/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
new file mode 100644
index 000..2d7ad740723
--- /dev/null
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi/no-werror.patch
@@ -0,0 +1,17 @@
+Do not treat warnings as errors on musl
+
+There are additional warnings found with musl which may not be treated as 
errors
+
+Signed-off-by: Khem Raj 
+Upstream-Status: Inappropriate [musl specific]
+--- a/Make.defaults
 b/Make.defaults
+@@ -187,7 +187,7 @@ CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wex
+-funsigned-char -fshort-wchar -fno-strict-aliasing \
+-ffreestanding -fno-stack-protector
+ else
+-CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wextra -Wno-pointer-sign -Werror \
++CFLAGS  += $(ARCH3264) -g -O2 -Wall -Wextra -Wno-pointer-sign \
+-funsigned-char -fshort-wchar -fno-strict-aliasing \
+  -ffreestanding -fno-stack-protector -fno-stack-check \
+-fno-stack-check \
diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb 
b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
index d37d638e097..819d376f9d9 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
+++ b/meta/recipes-bsp/gnu-efi/gnu-efi_3.0.17.bb
@@ -18,6 +18,7 @@ SRC_URI = "${SOURCEFORGE_MIRROR}/${BPN}/files/${BP}.tar.bz2 \
file://0001-riscv64-adjust-type-definitions.patch \
file://0001-riscv64-ignore-unknown-relocs.patch \
"
+SRC_URI:append:libc-musl = " file://no-werror.patch"
 
 SRC_URI[sha256sum] = 
"7807e903349343a7a142ebb934703a2872235e89688cf586c032b0a1087bcaf4"
 
-- 
2.41.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185671): 
https://lists.openembedded.org/g/openembedded-core/message/185671
Mute This Topic: https://lists.openembedded.org/mt/100626020/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 2/2] systemd: fix efi stubs

[Alexandre Belloni via lists.openembedded.org]

On 08/08/2023 16:08:28+, Jose Quaresma wrote:
> Before the patch:
> 
> | $ objdump -h deploy/images/intel-corei7-64/linuxx64.efi.stub
> | objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub (.reloc): section 
> flag STYP_GROUP (0x4) ignored
> | objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub (.reloc): section 
> flag STYP_GROUP (0x4) ignored
> | objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub: file format not 
> recognized
> 
> After the patch:
> 
> | $objdump -h deploy/images/intel-corei7-64/linuxx64.efi.stub
> |
> | deploy/images/intel-corei7-64/linuxx64.efi.stub: file format pei-x86-64
> |
> | Sections:
> | Idx Name  Size  VMA   LMA   File off  
> Algn
> |   0 .text f99f  00014df91000  00014df91000  0400  
> 2**4
> |   CONTENTS, ALLOC, LOAD, READONLY, CODE
> |   1 .rodata   2c40  00014dfa1000  00014dfa1000  fe00  
> 2**2
> |   CONTENTS, ALLOC, LOAD, READONLY, DATA
> |   2 .data 02d8  00014dfa4000  00014dfa4000  00012c00  
> 2**4
> |   CONTENTS, ALLOC, LOAD, DATA
> |   3 .sdmagic  0032  00014dfa5000  00014dfa5000  00013000  
> 2**2
> |   CONTENTS, ALLOC, LOAD, READONLY, DATA
> |   4 .reloc0080  00014dfa6000  00014dfa6000  00013200  
> 2**2
> |   CONTENTS, ALLOC, LOAD, READONLY, DATA
> 
> Signed-off-by: Jose Quaresma 
> ---
>  meta/recipes-core/systemd/systemd.inc |  1 +
>  ...-elf2efi-Fix-header-size-calculation.patch | 70 +++
>  2 files changed, 71 insertions(+)
>  create mode 100644 
> meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
> 
> diff --git a/meta/recipes-core/systemd/systemd.inc 
> b/meta/recipes-core/systemd/systemd.inc
> index b00a49884b..e5686fbe44 100644
> --- a/meta/recipes-core/systemd/systemd.inc
> +++ b/meta/recipes-core/systemd/systemd.inc
> @@ -17,6 +17,7 @@ LIC_FILES_CHKSUM = 
> "file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
>  SRCREV = "994c7978608a0bd9b317f4f74ff266dd50a3e74e"
>  SRCBRANCH = "v254-stable"
>  SRC_URI = 
> "git://github.com/systemd/systemd-stable.git;protocol=https;branch=${SRCBRANCH}
>  \
> +   file://0001-elf2efi-Fix-header-size-calculation.patch \

Yes, this is exactly what Ross pointed to me and I had locally, I've put
this through the autobuilders now.

> "
>  
>  S = "${WORKDIR}/git"
> diff --git 
> a/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
>  
> b/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
> new file mode 100644
> index 00..0e8924d27d
> --- /dev/null
> +++ 
> b/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
> @@ -0,0 +1,70 @@
> +From d082d6502fa86e08dda858933838dde0406b824f Mon Sep 17 00:00:00 2001
> +From: Jan Janssen 
> +Date: Sun, 30 Jul 2023 20:59:04 +0200
> +Subject: [PATCH] elf2efi: Fix header size calculation
> +
> +The PE header size calculation failed to take the PE magic and coff
> +header size into account, which will lead to header truncation if we are
> +writing only 5 sections.
> +
> +Upstream-Status: Backport 
> [https://github.com/systemd/systemd/commit/ee91e06a5841c30bc7306260528ef407e0ebbab3]
> +
> +Signed-off-by: Jose Quaresma 
> +---
> + tools/elf2efi.py | 12 ++--
> + 1 file changed, 10 insertions(+), 2 deletions(-)
> +
> +diff --git a/tools/elf2efi.py b/tools/elf2efi.py
> +index e233c8e3ab..2e478940f5 100755
> +--- a/tools/elf2efi.py
>  b/tools/elf2efi.py
> +@@ -210,6 +210,7 @@ FILE_ALIGNMENT = 512
> + 
> + # Nobody cares about DOS headers, so put the PE header right after.
> + PE_OFFSET = 64
> ++PE_MAGIC = b"PE\0\0"
> + 
> + 
> + def align_to(x: int, align: int) -> int:
> +@@ -304,7 +305,10 @@ def copy_sections(elf: ELFFile, opt: PeOptionalHeader) 
> -> typing.List[PeSection]
> + 
> + 
> + def apply_elf_relative_relocation(
> +-reloc: ElfRelocation, image_base: int, sections: 
> typing.List[PeSection], addend_size: int
> ++reloc: ElfRelocation,
> ++image_base: int,
> ++sections: typing.List[PeSection],
> ++addend_size: int,
> + ):
> + # fmt: off
> + [target] = [
> +@@ -439,7 +443,7 @@ def write_pe(
> + file.seek(0x3C, io.SEEK_SET)
> + file.write(PE_OFFSET.to_bytes(2, byteorder="little"))
> + file.seek(PE_OFFSET, io.SEEK_SET)
> +-file.write(b"PE\0\0")
> ++file.write(PE_MAGIC)
> + file.write(coff)
> + file.write(opt)
> + 
> +@@ -453,6 +457,8 @@ def write_pe(
> + file.write(pe_s)
> + offset = align_to(offset + len(pe_s.data), FILE_ALIGNMENT)
> + 
> ++assert file.tell() <= opt.SizeOfHeaders
> ++
> + for pe_s in sections:
> + file.seek(pe_s.PointerToRawData, io.SEEK_SET)
> + file.write(pe_s.data)
> +@@ -515,6 +521,8 @@ def elf2efi(args: argparse.Namespace):
> + 
> + 

Re: [OE-core] systemd issue with network commandline config and 6.4 kernel

[Bruce Ashfield]

On Tue, Aug 8, 2023 at 11:35 AM Chen Qi via lists.openembedded.org
 wrote:
>
> I found some clue, but not the root cause yet.
> The eth0 is renamed to enp0s2 by 80-net-setup-link.rules udev rule in 
> systemd. And the connman.conf only blacklists eth0.
>
> The related log is:
> Aug 08 15:18:16 qemux86-64 kernel[213]: [1.727332] virtio_net virtio0 
> enp0s2: renamed from eth0 (while UP)
>
> The systemd udev configuration file is:
> root@qemux86-64:~# cat /lib/udev/rules.d/80-net-setup-link.rules
> # do not edit this file, it will be overwritten on update
> SUBSYSTEM!="net", GOTO="net_setup_link_end"
> IMPORT{builtin}="path_id"
> ACTION=="remove", GOTO="net_setup_link_end"
> IMPORT{builtin}="net_setup_link"
> NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
> LABEL="net_setup_link_end"
>
> And the connman configuration file is:
> root@qemux86-64:~# cat /etc/connman/main.conf
> [General]
> NetworkInterfaceBlacklist = eth0
>
> In contrary, with 6.1 kernel, the renaming failed with the following message:
> Aug 08 15:29:58 qemux86-64 (udev-worker)[206]: enp0s2: Network interface 
> 'eth0' is already up, cannot rename to 'enp0s2'.
>
> Maybe some changes in new kernel allows renaming network interface while it's 
> up?

This brings back a memory of something I ran into on a build server
when upgrading to a "newer" 6.2 kernel,

I had to disable interface renaming in order to get a consistent
network configuration, and did that via "net.ifnames=0" on the kernel
command line.

Bruce

>
> Regards,
> Qi
>
>
> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Richard Purdie
> Sent: Tuesday, August 8, 2023 7:51 PM
> To: openembedded-core 
> Cc: Luca Boccassi ; Alexandre Belloni 
> 
> Subject: [OE-core] systemd issue with network commandline config and 6.4 
> kernel
>
> Hi,
>
> We'd like to switch to the 6.4 kernel and there are two blockers. One of them 
> is that systemd appears to be breaking the network device config with 6.4 
> kernels.
>
> This happens with core-image-sato but not with core-image-minimal.
>
> In the sato image, I can see the kernel gets the ip= commandline parameters 
> and sets up the network (IP-Config: Complete:  info>) in the dmesg logs. When I look at the "ip addr" config, that
> setup is gone though.
>
> The autobuilder manifestation of this is for example:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/7580/steps/23/logs/stdio
>
> i.e. ping fails.
>
> Does anyone know why updating from the 6.1 kernel to the the 6.4 kernel would 
> cause this only for systemd images?
>
> I couldn't spot anything in the journal but I'm not sure I'd know what to 
> look for...
>
> Thanks,
>
> Richard
>
> 
>


--
- 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 (#185669): 
https://lists.openembedded.org/g/openembedded-core/message/185669
Mute This Topic: https://lists.openembedded.org/mt/100620069/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v8] systemd: update to v254

[Jose Quaresma]

With this adictional patch
https://lists.openembedded.org/g/openembedded-core/message/185666
the stub looks good again.

Jose

Alexandre Belloni via lists.openembedded.org  escreveu no dia terça, 8/08/2023 à(s)
01:51:

> On 07/08/2023 17:01:02-0700, Khem Raj wrote:
> > Can you try this patch on top
> >
> >
> https://git.yoctoproject.org/poky-contrib/commit/?h=yoe/mut=0defb14c600170434befe8c94dad4732041a3513
> >
>
> I have those two patches on top of master:
>
> systemd-boot: Ensure EFI_LD is also passed to compiler driver
> systemd: fix efi dependency
>



>
>
> > On Mon, Aug 7, 2023 at 3:48 PM Luca Boccassi 
> wrote:
> > >
> > > On Mon, 7 Aug 2023 at 23:37, Alexandre Belloni
> > >  wrote:
> > > >
> > > > On 07/08/2023 16:40:25+0200, Alexandre Belloni wrote:
> > > > > Hello,
> > > > >
> > > > > I've been looking a bit more at this. there is definitively another
> > > > > issue here which is the first one I found:
> > > > >
> > > > > x86_64-poky-linux-objcopy:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> file format not recognized
> > > > >
> > > > > This is the main issue here.
> > > > >
> > > > > $ file
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> > > > >
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> MS-DOS executable PE32+ executable (EFI application) x86-64 (stripped to
> external PDB), for MS Windows
> > > > > $ objdump -p
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> (.reloc): section flag STYP_GROUP (0x4) ignored
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> (.reloc): section flag STYP_COPY (0x10) ignored
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> (.reloc): section flag STYP_GROUP (0x4) ignored
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> (.reloc): section flag STYP_COPY (0x10) ignored
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> warning: ignoring section flag IMAGE_SCN_MEM_NOT_PAGED in section .reloc
> > > > > objdump:
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> file format not recognized
> > > > >
> > > > > I tested with v253.7 and I properly get:
> > > > >
> > > > > $ file
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> > > > >
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
> PE32+ executable (EFI application) x86-64 (stripped to external PDB), for
> MS Windows
> > > > > $
> ./build-st/tmp/sysroots-components/x86_64/binutils-cross-x86_64/usr/bin/x86_64-poky-linux/x86_64-poky-linux-objdump
> -h
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub
> > > > >
> > > > >
> /home/alexandre/poky/build-st/tmp/deploy/images/qemux86-64/linuxx64.efi.stub:
>file format pei-x86-64
> > > > >
> > > > > Sections:
> > > > > Idx Name  Size  VMA   LMA
>  File off  Algn
> > > > >   0 .text d7f0  4000  4000
> 0400  2**4
> > > > >   CONTENTS, ALLOC, LOAD, READONLY, CODE
> > > > >   1 .reloc000c  00012000  00012000
> dc00  2**2
> > > > >   CONTENTS, ALLOC, LOAD, READONLY, DATA
> > > > >   2 .data 2ab0  00013000  00013000
> de00  2**4
> > > > >   CONTENTS, ALLOC, LOAD, DATA
> > > > >   3 .dynamic  0100  00016000  00016000
> 00010a00  2**2
> > > > >   CONTENTS, ALLOC, LOAD, DATA
> > > > >   4 .rela 0630  00017000  00017000
> 00010c00  2**2
> > > > >   CONTENTS, ALLOC, LOAD, READONLY, DATA
> > > > >   5 .dynsym   0018  00018000  00018000
> 00011400  2**2
> > > > >   CONTENTS, ALLOC, LOAD, READONLY, DATA
> > > > >   6 .sdmagic  002a  0001a460  0001a460
> 00011600  2**2
> > > > >   CONTENTS, ALLOC, LOAD, READONLY, DATA
> > > > >
> > > > > I really believe the recipe is not generating a working efi.stub.
> Can
> > > > > you check?
> > > > >
> > > >
> > > > I've built systemd-boot v254 outside of YP and it generated a proper
> > > > linuxx64.efi.stub. I still don't get why the recipe doesn't generate
> a
> > > > working binary.
> > > >
> > > > The issue seems to be at the linuxx64.elf.stub generation as I took
> the
> > > > one from my YP build, ran it through elf2efi.py on my PC and this
> didn't
> > > > generate a working 

Re: [OE-core] systemd issue with network commandline config and 6.4 kernel

[Peter Bergin]

On 2023-08-08 17:34, Chen Qi via lists.openembedded.org wrote:

Maybe some changes in new kernel allows renaming network interface while it's 
up?


Seems correct!

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit?id=bd039b5ea2a91ea707ee8539df26456bd5be80af

That was added in v6.2

/Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185667): 
https://lists.openembedded.org/g/openembedded-core/message/185667
Mute This Topic: https://lists.openembedded.org/mt/100620069/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] systemd-boot: enable verbose compilation

[Jose Quaresma]

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd-boot_254.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd-boot_254.bb 
b/meta/recipes-core/systemd/systemd-boot_254.bb
index 5d69cf83ab..b91bbfe485 100644
--- a/meta/recipes-core/systemd/systemd-boot_254.bb
+++ b/meta/recipes-core/systemd/systemd-boot_254.bb
@@ -53,7 +53,7 @@ COMPATIBLE_HOST = "(aarch64.*|arm.*|x86_64.*|i.86.*)-linux"
 COMPATIBLE_HOST:x86-x32 = "null"
 
 do_compile() {
-   ninja systemd-boot
+   ninja -v systemd-boot
 }
 
 do_install() {
-- 
2.34.1


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

[OE-core][PATCH 2/2] systemd: fix efi stubs

[Jose Quaresma]

Before the patch:

| $ objdump -h deploy/images/intel-corei7-64/linuxx64.efi.stub
| objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub (.reloc): section 
flag STYP_GROUP (0x4) ignored
| objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub (.reloc): section 
flag STYP_GROUP (0x4) ignored
| objdump: deploy/images/intel-corei7-64/linuxx64.efi.stub: file format not 
recognized

After the patch:

| $objdump -h deploy/images/intel-corei7-64/linuxx64.efi.stub
|
| deploy/images/intel-corei7-64/linuxx64.efi.stub: file format pei-x86-64
|
| Sections:
| Idx Name  Size  VMA   LMA   File off  Algn
|   0 .text f99f  00014df91000  00014df91000  0400  2**4
|   CONTENTS, ALLOC, LOAD, READONLY, CODE
|   1 .rodata   2c40  00014dfa1000  00014dfa1000  fe00  2**2
|   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   2 .data 02d8  00014dfa4000  00014dfa4000  00012c00  2**4
|   CONTENTS, ALLOC, LOAD, DATA
|   3 .sdmagic  0032  00014dfa5000  00014dfa5000  00013000  2**2
|   CONTENTS, ALLOC, LOAD, READONLY, DATA
|   4 .reloc0080  00014dfa6000  00014dfa6000  00013200  2**2
|   CONTENTS, ALLOC, LOAD, READONLY, DATA

Signed-off-by: Jose Quaresma 
---
 meta/recipes-core/systemd/systemd.inc |  1 +
 ...-elf2efi-Fix-header-size-calculation.patch | 70 +++
 2 files changed, 71 insertions(+)
 create mode 100644 
meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch

diff --git a/meta/recipes-core/systemd/systemd.inc 
b/meta/recipes-core/systemd/systemd.inc
index b00a49884b..e5686fbe44 100644
--- a/meta/recipes-core/systemd/systemd.inc
+++ b/meta/recipes-core/systemd/systemd.inc
@@ -17,6 +17,7 @@ LIC_FILES_CHKSUM = 
"file://LICENSE.GPL2;md5=751419260aa954499f7abaabaa882bbe \
 SRCREV = "994c7978608a0bd9b317f4f74ff266dd50a3e74e"
 SRCBRANCH = "v254-stable"
 SRC_URI = 
"git://github.com/systemd/systemd-stable.git;protocol=https;branch=${SRCBRANCH} 
\
+   file://0001-elf2efi-Fix-header-size-calculation.patch \
"
 
 S = "${WORKDIR}/git"
diff --git 
a/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
 
b/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
new file mode 100644
index 00..0e8924d27d
--- /dev/null
+++ 
b/meta/recipes-core/systemd/systemd/0001-elf2efi-Fix-header-size-calculation.patch
@@ -0,0 +1,70 @@
+From d082d6502fa86e08dda858933838dde0406b824f Mon Sep 17 00:00:00 2001
+From: Jan Janssen 
+Date: Sun, 30 Jul 2023 20:59:04 +0200
+Subject: [PATCH] elf2efi: Fix header size calculation
+
+The PE header size calculation failed to take the PE magic and coff
+header size into account, which will lead to header truncation if we are
+writing only 5 sections.
+
+Upstream-Status: Backport 
[https://github.com/systemd/systemd/commit/ee91e06a5841c30bc7306260528ef407e0ebbab3]
+
+Signed-off-by: Jose Quaresma 
+---
+ tools/elf2efi.py | 12 ++--
+ 1 file changed, 10 insertions(+), 2 deletions(-)
+
+diff --git a/tools/elf2efi.py b/tools/elf2efi.py
+index e233c8e3ab..2e478940f5 100755
+--- a/tools/elf2efi.py
 b/tools/elf2efi.py
+@@ -210,6 +210,7 @@ FILE_ALIGNMENT = 512
+ 
+ # Nobody cares about DOS headers, so put the PE header right after.
+ PE_OFFSET = 64
++PE_MAGIC = b"PE\0\0"
+ 
+ 
+ def align_to(x: int, align: int) -> int:
+@@ -304,7 +305,10 @@ def copy_sections(elf: ELFFile, opt: PeOptionalHeader) -> 
typing.List[PeSection]
+ 
+ 
+ def apply_elf_relative_relocation(
+-reloc: ElfRelocation, image_base: int, sections: typing.List[PeSection], 
addend_size: int
++reloc: ElfRelocation,
++image_base: int,
++sections: typing.List[PeSection],
++addend_size: int,
+ ):
+ # fmt: off
+ [target] = [
+@@ -439,7 +443,7 @@ def write_pe(
+ file.seek(0x3C, io.SEEK_SET)
+ file.write(PE_OFFSET.to_bytes(2, byteorder="little"))
+ file.seek(PE_OFFSET, io.SEEK_SET)
+-file.write(b"PE\0\0")
++file.write(PE_MAGIC)
+ file.write(coff)
+ file.write(opt)
+ 
+@@ -453,6 +457,8 @@ def write_pe(
+ file.write(pe_s)
+ offset = align_to(offset + len(pe_s.data), FILE_ALIGNMENT)
+ 
++assert file.tell() <= opt.SizeOfHeaders
++
+ for pe_s in sections:
+ file.seek(pe_s.PointerToRawData, io.SEEK_SET)
+ file.write(pe_s.data)
+@@ -515,6 +521,8 @@ def elf2efi(args: argparse.Namespace):
+ 
+ opt.SizeOfHeaders = align_to(
+ PE_OFFSET
+++ len(PE_MAGIC)
+++ sizeof(PeCoffHeader)
+ + coff.SizeOfOptionalHeader
+ + sizeof(PeSection) * max(coff.NumberOfSections, 
args.minimum_sections),
+ FILE_ALIGNMENT,
+-- 
+2.34.1
+
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185666): 

Re: [OE-core] systemd issue with network commandline config and 6.4 kernel

[Chen Qi via lists.openembedded.org]

I found some clue, but not the root cause yet.
The eth0 is renamed to enp0s2 by 80-net-setup-link.rules udev rule in systemd. 
And the connman.conf only blacklists eth0.

The related log is:
Aug 08 15:18:16 qemux86-64 kernel[213]: [1.727332] virtio_net virtio0 
enp0s2: renamed from eth0 (while UP)

The systemd udev configuration file is:
root@qemux86-64:~# cat /lib/udev/rules.d/80-net-setup-link.rules
# do not edit this file, it will be overwritten on update
SUBSYSTEM!="net", GOTO="net_setup_link_end"
IMPORT{builtin}="path_id"
ACTION=="remove", GOTO="net_setup_link_end"
IMPORT{builtin}="net_setup_link"
NAME=="", ENV{ID_NET_NAME}!="", NAME="$env{ID_NET_NAME}"
LABEL="net_setup_link_end"

And the connman configuration file is:
root@qemux86-64:~# cat /etc/connman/main.conf
[General]
NetworkInterfaceBlacklist = eth0

In contrary, with 6.1 kernel, the renaming failed with the following message:
Aug 08 15:29:58 qemux86-64 (udev-worker)[206]: enp0s2: Network interface 'eth0' 
is already up, cannot rename to 'enp0s2'.

Maybe some changes in new kernel allows renaming network interface while it's 
up?

Regards,
Qi


-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Richard Purdie
Sent: Tuesday, August 8, 2023 7:51 PM
To: openembedded-core 
Cc: Luca Boccassi ; Alexandre Belloni 

Subject: [OE-core] systemd issue with network commandline config and 6.4 kernel

Hi,

We'd like to switch to the 6.4 kernel and there are two blockers. One of them 
is that systemd appears to be breaking the network device config with 6.4 
kernels.

This happens with core-image-sato but not with core-image-minimal.

In the sato image, I can see the kernel gets the ip= commandline parameters and 
sets up the network (IP-Config: Complete: ) in the dmesg logs. When I look at the "ip addr" config, that
setup is gone though.

The autobuilder manifestation of this is for example:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/7580/steps/23/logs/stdio

i.e. ping fails.

Does anyone know why updating from the 6.1 kernel to the the 6.4 kernel would 
cause this only for systemd images?

I couldn't spot anything in the journal but I'm not sure I'd know what to look 
for...

Thanks,

Richard

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

[OE-core] Yocto Project Status 8 August 2023 (WW32)

[Stephen Jolley]

Current Dev Position: YP 4.3 M3

Next Deadline: 28th August 2023 YP 4.3 M3 build date

Next Team Meetings:

   -

   Bug Triage meeting Thursday August 10th 7:30 am PDT (
   https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
   -

   Weekly Project Engineering Sync Tuesday August 8th at 8 am PDT (
   https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)
   
   -

   Twitch -  See https://www.twitch.tv/theyoctojester


Key Status/Updates:

   -

   YP 4.3 M2 was released.
   -

   YP 3.1.27 was rebuilt after a toolchain tests fix and is in QA
   -

   YP 4.0.12 rc1 was built but will need to be rebuilt due to an
   autobuilder failure due to certificate expiration.
   -

   The merged systemd upgrade has destablised the autobuilder. We don’t
   want to revert the upgrade but the regressions are causing multiple test
   failures and this along with other issues in multiple patch series means
   patch merging is effectively stalled.
   -

   There are two issues blocking the 6.4 kernel upgrade, one is qemuarm drm
   boot errors and the second is broken networking for systemd images under
   qemu.
   -

   Support for a  new recipe sanity testing task (do_recipe_qa) was merged
   and there is a hope/plan to move more “processing” operations over to this
   task to improve general parsing time.
   -

   CVE metrics are worrying with significant numbers of open CVEs against
   master, many of them kernel related. The 6.4 upgrade should help but that
   is blocked. Mickledore is also badly affected with a record high count.

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

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.3. See:
   
https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.3_Unassigned_Enhancements.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/maintainers.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
   
   -

   We have a growing number of bugs in bugzilla, any help with them is
   appreciated.


YP 4.3 Milestone Dates:

   -

   YP 4.3 M2 is released
   -

   YP 4.3 M3 build date  2023/08/28
   -

   YP 4.3 M3 Release date 2023/09/08
   -

   YP 4.3 M4 build date  2023/10/02
   -

   YP 4.3 M4 Release date 2023/10/27


Upcoming dot releases:

   -

   YP 3.1.27 is in QA
   -

   YP 4.0.12 is being built
   -

   YP 4.0.12 Release date 2023/08/18
   -

   YP 4.2.3 build date 2023/08/28
   -

   YP 4.2.3 Release date 2023/09/08
   -

   YP 3.1.28 build date 2023/09/18
   -

   YP 3.1.28 Release date 2023/09/29
   -

   YP 4.0.13 build date 2023/09/25
   -

   YP 4.0.13 Release date 2023/10/06
   -

   YP 3.1.29 build date 2023/10/30
   -

   YP 3.1.29 Release date 2023/11/10
   -

   YP 4.0.14 build date 2023/11/06
   -

   YP 4.0.14 Release date 2023/11/17
   -

   YP 4.2.4 build date 2023/11/13
   -

   YP 4.2.4 Release date 2023/11/24
   -

   YP 3.1.30 build date 2023/12/11
   -

   YP 3.1.30 Release date 2023/12/22
   -

   YP 4.0.15 build date 2023/12/18
   -

   YP 4.0.15 Release date 2023/12/29


Tracking Metrics:

   -

   WDD 2495 (last week 2470) (
   https://wiki.yoctoproject.org/charts/combo.html)
   -

   OE-Core/Poky Patch Metrics
   -

  Total patches found: 1186 (last week 1181)
  -

  Patches in the Pending State: 256 (22%) [last week 256 (22%)]
  -

   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!]

Thanks,



*Stephen K. Jolley*

*Yocto Project 

Re: [OE-core] [OE] help with Equivalence Server

[Maksim Chichikalov]

> On Mon, 2023-08-07 at 11:30 -0400, Maksim Chichikalov wrote:
> > > On Mon, Aug 7, 2023 at 8:41 AM Maksim Chichikalov
> > >  wrote:
> > > >
> > > > On Mon, Aug 7, 2023 at 4:01 AM Richard Purdie
> > > >  wrote:
> > > > >
> > > > > On Sun, 2023-08-06 at 13:15 -0600, Joshua Watt wrote:
> > > > > > On Sat, Aug 5, 2023 at 7:54 PM Maksim Chichikalov
> > > > > >  wrote:
> > > > > > > My name is Max; nice to e-meet you. I need your help with
> > > > > > > Equivalence Server :)
> > > > > > > I watched your presentation on Youtube - it 100% helped me
> > > > > > > to
> > > > > > > understand the logic better and debug the issue we are
> > > > > > > facing.
> > > > > > > Thank you for all your input into OE development.
> > > > > > >
> > > > > > > I found in OE repo that you introduced "def
> > > > > > > OEOuthashBasic()", so I
> > > > > > > decided to write to you first before opening the topic on
> > > > > > > an email
> > > > > > > list.
> > > > > > >
> > > > > > > The problem:
> > > > > > >
> > > > > > > Input data are propagated to the output hash generation
> > > > > > > function,
> > > > > > > which generates a different out-hash.
> > > > > > >
> > > > > > > Description:
> > > > > > >
> > > > > > > All "_git.bb" recipes have to append SRCPV to PV. As a
> > > > > > > result, PV
> > > > > > > is different on each commit.
> > > > > > >
> > > > > > > The OEOuthashBasic function includes SSTATE_PKGSPEC to
> > > > > > > generate
> > > > > > > hash, which contains PV (PV contains git hash). As a
> > > > > > > result, there
> > > > > > > is no way to generate the same out-hash even if changes
> > > > > > > introduced
> > > > > > > within a commit were trivial.
> > > > > > >
> > > > > >
> > > > > > Right, this is sort of on purpose, because the hash
> > > > > > equivalence is
> > > > > > basically trying to say that an sstate object can be used in
> > > > > > place of
> > > > > > another one, even when the task hashes aren't the same (but
> > > > > > the
> > > > > > output hashes are). However, the sstate code itself will only
> > > > > > look
> > > > > > for sstate object with a certain name (which include PV);
> > > > > > hash
> > > > > > equivalency does have _some_ control over the file name
> > > > > > sstate looks
> > > > > > for, since it will replace the taskhash portion of the name
> > > > > > with the
> > > > > > unified hash, but it doesn't have complete control.
> > > > > >
> > > > > > >
> > > > > > > In our codebase, our components have API part, which is
> > > > > > > managed by
> > > > > > > an independent recipe per component. The described above
> > > > > > > problem
> > > > > > > caused the recompilation of all components dependent on
> > > > > > > API, even
> > > > > > > in cases when API was not changed. CI for pull requests
> > > > > > > recompiles
> > > > > > > mostly the entire code base, I need to do something with
> > > > > > > it.
> > > > > > > (sorry, quite hard for me to explain it in a nutshell, let
> > > > > > > me know
> > > > > > > if you like to know slightly more details)
> > > > > > >
> > > > > >
> > > > > > Ya, sounds like a typical mono-repo design?
> > > > > >
> > > > > > >
> > > > > > > I see a couple of options for us:
> > > > > > > * Add a custom implementation of out-hash generated
> > > > > > > function and
> > > > > > > overwrite SSTATE_HASHEQUIV_METHOD.
> > > > > > > * Better understand why it's mandatory to append SRCPV to
> > > > > > > PV, and
> > > > > > > maybe it's flexible in our cases to do it.
> > > > > > >
> > > > > >
> > > > > > This might be the best option, at least for your recipes, but
> > > > > > I've
> > > > > > CC'd the list for additional feedback
> > > > > >
> > > > > > > * Propose a patch to fix OEOuthashBasic().
> > > > > > >
> > > > > > > In my humble opinion, the commit's hash shouldn't be
> > > > > > > included in
> > > > > > > out-hash generation, it doesn't make sense. Unless I'm
> > > > > > > missing
> > > > > > > something important - What are your thoughts?
> > > > > > >
> > > > > >
> > > > > > Yes and no. It's not intentional, but a side effect of hash
> > > > > > equivalency trying to make sure that the things it's marking
> > > > > > as
> > > > > > equivalent can actually be found in sstate (basically,
> > > > > > because sstate
> > > > > > include the commit hash, hash equivalency kinda has to
> > > > > > include it).
> > > > >
> > > > > This all sounds a bit unfortunate.
> > > > >
> > > > > sstate only works as long as the filenames are predictable.
> > > > > Some
> > > > > elements of the sstate filenames are essential to operation,
> > > > > e.g. the
> > > > > package architecture since one input would result in multiple
> > > > > files
> > > > > with the same hash in the filename of the output otherwise. The
> > > > > recipe
> > > > > name and version are there mainly for debugging to allow
> > > > > someone to
> > > > > more easily know where an sstate object came from and what it
> > > > > represents. This is summarised by the comment 

Re: [OE-core] [PATCH 0/7] linux-yocto: consolidated kernel pull request

[Bruce Ashfield]

On Tue, Aug 8, 2023 at 6:43 AM Alexandre Belloni
 wrote:
>
> Hello Bruce,
>
> While I didn't test this series yet, as discussed, I've tried to switch
> to 6.4 by default. I got this warning:

-tiny was clean here, but let me re-test and see if I've missed
sending something in my 6.4 SRCREV bumps.

Bruce

>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7876/steps/13/logs/stdio
>
> WARNING: linux-yocto-tiny-6.4.3+gitAUTOINC+dab56f52aa_dee78ad196-r0 
> do_kernel_configcheck: [kernel config]: specified values did not make it into 
> the kernel's final configuration:
> [NOTE]: 'CONFIG_USB_HID' last val (y) and .config val (n) do not match
> [INFO]: CONFIG_USB_HID : n
> [INFO]: raw config text:
> config USB_HID
> tristate "USB HID transport layer"
> default y
> select HID
> depends on USB && INPUT && USB && HID_SUPPORT
> help
>   Say Y here if you want to connect USB keyboards,
>   mice, joysticks, graphic tablets, or any other HID based 
> devices
>   to your computer via USB, as well as Uninterruptible Power 
> Supply
>   (UPS) and monitor control devices.
>
>   You can't use this driver and the HIDBP (Boot Protocol) 
> keyboard
>   and mouse drivers at the same time. More information is 
> available:
>   .
>
>   If unsure, say Y.
>
>   To compile this driver as a module, choose M here: the
>   module will be called usbhid.
> Config 'USB_HID' has the following Direct dependencies (USB_HID=n):
> USB(=y) && INPUT(=y) && HID_SUPPORT(=n)
> Parent dependencies are:
>  INPUT [y] USB [y] HID_SUPPORT [n]
> [INFO]: config 'CONFIG_USB_HID' was set, but it wasn't assignable, check 
> (parent) dependencies
>
>
> master has 86adbe4db668 ("linux-yocto-tiny/6.4: fix configuration
> warnings (HID)") so I guess there is something missing.
>
>
> On 07/08/2023 23:35:46-0400, Bruce Ashfield wrote:
> > From: Bruce Ashfield 
> >
> > Richard,
> >
> > Here's my queued set of -stable updates (as well as a -dev kernel bump).
> >
> > I've got another round of updates under test, and will send them when
> > ready.
> >
> > 6.4 marches along, it'll be up to date when those last issues keeping
> > it from being the default are resolved.
> >
> > Bruce
> >
> > The following changes since commit 058a44165ce375f405063e73a9fcd1b2757ef8da:
> >
> >   bitbake: fetch2: Check if path is 'None' before calculating checksums 
> > (2023-08-04 11:48:26 +0100)
> >
> > are available in the Git repository at:
> >
> >   https://git.yoctoproject.org/poky-contrib zedd/kernel
> >   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
> >
> > Bruce Ashfield (7):
> >   linux-yocto/6.4: fix CONFIG_LEDS_TRIGGER_GPIO kernel audit warning
> >   linux-yocto/6.4: update to v6.4.6
> >   linux-yocto/6.1: update to v6.1.41
> >   linux-yocto/6.4: update to v6.4.7
> >   linux-yocto-dev: bump to v6.5+
> >   linux-yocto/6.4: update to v6.4.8
> >   linux-yocto/6.1: update to v6.1.43
> >
> >  meta/recipes-kernel/linux/linux-yocto-dev.bb  |  4 +--
> >  .../linux/linux-yocto-rt_6.1.bb   |  6 ++--
> >  .../linux/linux-yocto-rt_6.4.bb   |  6 ++--
> >  .../linux/linux-yocto-tiny_6.1.bb |  6 ++--
> >  .../linux/linux-yocto-tiny_6.4.bb |  6 ++--
> >  meta/recipes-kernel/linux/linux-yocto_6.1.bb  | 28 +--
> >  meta/recipes-kernel/linux/linux-yocto_6.4.bb  | 28 +--
> >  7 files changed, 42 insertions(+), 42 deletions(-)
> >
> > --
> > 2.34.1
> >
>
> >
> > 
> >
>
>
> --
> Alexandre Belloni, co-owner and COO, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com



-- 
- 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 (#185661): 
https://lists.openembedded.org/g/openembedded-core/message/185661
Mute This Topic: https://lists.openembedded.org/mt/100615695/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] systemd issue with network commandline config and 6.4 kernel

[Richard Purdie]

Hi,

We'd like to switch to the 6.4 kernel and there are two blockers. One
of them is that systemd appears to be breaking the network device
config with 6.4 kernels.

This happens with core-image-sato but not with core-image-minimal.

In the sato image, I can see the kernel gets the ip= commandline
parameters and sets up the network (IP-Config: Complete: ) in the dmesg logs. When I look at the "ip addr" config, that
setup is gone though.

The autobuilder manifestation of this is for example:

https://autobuilder.yoctoproject.org/typhoon/#/builders/72/builds/7580/steps/23/logs/stdio

i.e. ping fails.

Does anyone know why updating from the 6.1 kernel to the the 6.4 kernel
would cause this only for systemd images?

I couldn't spot anything in the journal but I'm not sure I'd know what
to look for...

Thanks,

Richard

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

Re: [OE-core] [PATCH v4] sstatesig: Fix pn and taskname derivation in find_siginfo

[Yang Xu via lists.openembedded.org]

I got it, thank you :)

Yang

On Tue, 2023-08-08 at 11:39 +0100, Richard Purdie wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  
> On Tue, 2023-08-08 at 10:15 +, Yang Xu (徐扬) wrote:
> > It is a elegant solution for current issue. I will test and update
> my
> > patch to only include testcase part soon.
> > 
> > Thank you
> 
> I did end up tweaking your patch to this:
> 
> 
https://git.yoctoproject.org/poky/commit/?h=master-next=3a79452507846756f6d78cab4dc4adafa0cb2be7
> 
> Cheers,
> 
> Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185659): 
https://lists.openembedded.org/g/openembedded-core/message/185659
Mute This Topic: https://lists.openembedded.org/mt/100113209/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 0/7] linux-yocto: consolidated kernel pull request

[Alexandre Belloni via lists.openembedded.org]

Hello Bruce,

While I didn't test this series yet, as discussed, I've tried to switch
to 6.4 by default. I got this warning:

https://autobuilder.yoctoproject.org/typhoon/#/builders/15/builds/7876/steps/13/logs/stdio

WARNING: linux-yocto-tiny-6.4.3+gitAUTOINC+dab56f52aa_dee78ad196-r0 
do_kernel_configcheck: [kernel config]: specified values did not make it into 
the kernel's final configuration:
[NOTE]: 'CONFIG_USB_HID' last val (y) and .config val (n) do not match
[INFO]: CONFIG_USB_HID : n 
[INFO]: raw config text:
config USB_HID
tristate "USB HID transport layer"
default y
select HID
depends on USB && INPUT && USB && HID_SUPPORT
help
  Say Y here if you want to connect USB keyboards,
  mice, joysticks, graphic tablets, or any other HID based 
devices
  to your computer via USB, as well as Uninterruptible Power 
Supply
  (UPS) and monitor control devices.
  
  You can't use this driver and the HIDBP (Boot Protocol) 
keyboard
  and mouse drivers at the same time. More information is 
available:
  .
  
  If unsure, say Y.
  
  To compile this driver as a module, choose M here: the
  module will be called usbhid.
Config 'USB_HID' has the following Direct dependencies (USB_HID=n):
USB(=y) && INPUT(=y) && HID_SUPPORT(=n)
Parent dependencies are:
 INPUT [y] USB [y] HID_SUPPORT [n]
[INFO]: config 'CONFIG_USB_HID' was set, but it wasn't assignable, check 
(parent) dependencies


master has 86adbe4db668 ("linux-yocto-tiny/6.4: fix configuration
warnings (HID)") so I guess there is something missing.


On 07/08/2023 23:35:46-0400, Bruce Ashfield wrote:
> From: Bruce Ashfield 
> 
> Richard,
> 
> Here's my queued set of -stable updates (as well as a -dev kernel bump).
> 
> I've got another round of updates under test, and will send them when
> ready.
> 
> 6.4 marches along, it'll be up to date when those last issues keeping
> it from being the default are resolved.
> 
> Bruce
> 
> The following changes since commit 058a44165ce375f405063e73a9fcd1b2757ef8da:
> 
>   bitbake: fetch2: Check if path is 'None' before calculating checksums 
> (2023-08-04 11:48:26 +0100)
> 
> are available in the Git repository at:
> 
>   https://git.yoctoproject.org/poky-contrib zedd/kernel
>   http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel
> 
> Bruce Ashfield (7):
>   linux-yocto/6.4: fix CONFIG_LEDS_TRIGGER_GPIO kernel audit warning
>   linux-yocto/6.4: update to v6.4.6
>   linux-yocto/6.1: update to v6.1.41
>   linux-yocto/6.4: update to v6.4.7
>   linux-yocto-dev: bump to v6.5+
>   linux-yocto/6.4: update to v6.4.8
>   linux-yocto/6.1: update to v6.1.43
> 
>  meta/recipes-kernel/linux/linux-yocto-dev.bb  |  4 +--
>  .../linux/linux-yocto-rt_6.1.bb   |  6 ++--
>  .../linux/linux-yocto-rt_6.4.bb   |  6 ++--
>  .../linux/linux-yocto-tiny_6.1.bb |  6 ++--
>  .../linux/linux-yocto-tiny_6.4.bb |  6 ++--
>  meta/recipes-kernel/linux/linux-yocto_6.1.bb  | 28 +--
>  meta/recipes-kernel/linux/linux-yocto_6.4.bb  | 28 +--
>  7 files changed, 42 insertions(+), 42 deletions(-)
> 
> -- 
> 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 (#185658): 
https://lists.openembedded.org/g/openembedded-core/message/185658
Mute This Topic: https://lists.openembedded.org/mt/100615695/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH v4] sstatesig: Fix pn and taskname derivation in find_siginfo

[Richard Purdie]

On Tue, 2023-08-08 at 10:15 +, Yang Xu (徐扬) wrote:
> It is a elegant solution for current issue. I will test and update my
> patch to only include testcase part soon.
> 
> Thank you

I did end up tweaking your patch to this:

https://git.yoctoproject.org/poky/commit/?h=master-next=3a79452507846756f6d78cab4dc4adafa0cb2be7

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185657): 
https://lists.openembedded.org/g/openembedded-core/message/185657
Mute This Topic: https://lists.openembedded.org/mt/100113209/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-bcrypt fails for Power Pc

[Alexander Kanavin]

You are welcome. Now regarding your actual issue: what I would do is
set up an identical build for a different architecture that works to
successful completion (e.g. arm), and start comparing them.
Specifically:
- do the builds have the same things in their respective sysroots? Is
something missing?
- are the command lines the same? Is there something different in the
command invocation that ends in an error?
- the error is complaining about missing symbols. Are they present in
the build that works? Or if they are absent, why is the working build
not producing an error? Is it using some other symbols?

I hope you see the theme here: people will be much more willing to
help, if you position yourself, from the start, as a leading, active
participant in finding a solution.

Alex

On Tue, 8 Aug 2023 at 06:50, Krupal Ka Patel -X (krkapate - E-INFO
CHIPS INC at Cisco)  wrote:
>
> Hi Alex,
>
> I wanted to extend my sincerest apologies if my previous emails came across 
> as overly persistent or demanding.
> I truly value your insight and guidance regarding interactions within the 
> Yocto community and open-source communities.
>
> I sincerely regret any inconvenience my prior communications may have caused.
> Going forward, I am committed to adopting a more thoughtful and respectful 
> approach when seeking help and collaborating within these communities.
>
> Your guidance has been invaluable, and I am eager to apply it to enhance my 
> interactions within the Yocto community.
>
> Thanks,
> Krupal
>

> > > Mute This Topic: https://lists.openembedded.org/mt/100499985/1686489
> > > Group Owner: openembedded-core+ow...@lists.openembedded.org
> > > Unsubscribe: https://lists.openembedded.org/g/openembedded-
> > core/unsub [alex.kana...@gmail.com]
> > > -=-=-=-=-=-=-=-=-=-=-=-
> > >

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

Re: [OE-core] [PATCH v4] sstatesig: Fix pn and taskname derivation in find_siginfo

[Yang Xu via lists.openembedded.org]

It is a elegant solution for current issue. I will test and update my
patch to only include testcase part soon.

Thank you

Yang

On Sat, 2023-08-05 at 11:36 +0100, Richard Purdie wrote:
>
> External email : Please do not click links or open attachments until
> you have verified the sender or the content.
>  
> On Fri, 2023-08-04 at 17:13 +0100, Richard Purdie via
> lists.openembedded.org wrote:
> > On Thu, 2023-07-13 at 02:16 +, Yang Xu via
> lists.openembedded.org
> > wrote:
> > > From: Yang Xu 
> > > 
> > > The `bb.siggen.compare_sigfiles` method transforms the key format
> from
> > > `[mc::][virtual:][native:]:` to
> > > `/ name>:[:virtual][:native][:mc:]`
> > > by `clean_basepaths`. However, `find_siginfo` uses the original
> format
> > > to get the package name (pn) and task name.
> > > 
> > > This commit corrects the method for deriving the pn and task name
> in
> > > `find_siginfo` and adds handling for multilib name.
> > > And add test for compare_sigfiles and find_siginfo working
> together.
> > > 
> > > Signed-off-by: Yang Xu 
> > > ---
> > > 
> > > Notes:
> > > v1: correct handling for pn and taskname for native target in
> find_siginfo
> > > v2: add handling for multilib target in find_siginfo
> > > v3: add testcase for compare_sigfiles and find_siginfo work
> together.
> > > v4: optimize testcase to avoid non-deterministic fail
> > > 
> > >  .../recipes-test/binutils/binutils_%.bbappend |  2 +
> > >  meta/lib/oe/sstatesig.py  | 17 ++--
> > >  meta/lib/oeqa/selftest/cases/sstatetests.py   | 83
> +++
> > >  3 files changed, 97 insertions(+), 5 deletions(-)
> > >  create mode 100644 meta-selftest/recipes-
> test/binutils/binutils_%.bbappend
> > > 
> > > diff --git a/meta-selftest/recipes-
> test/binutils/binutils_%.bbappend b/meta-selftest/recipes-
> test/binutils/binutils_%.bbappend
> > > new file mode 100644
> > > index 00..205720982c
> > > --- /dev/null
> > > +++ b/meta-selftest/recipes-test/binutils/binutils_%.bbappend
> > > @@ -0,0 +1,2 @@
> > > +# This bbappend is used to alter the recipe using the
> test_recipe.inc file created by tests.
> > > +include test_recipe.inc
> > > diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> > > index f943df181e..f041a0c430 100644
> > > --- a/meta/lib/oe/sstatesig.py
> > > +++ b/meta/lib/oe/sstatesig.py
> > > @@ -321,11 +321,18 @@ def find_siginfo(pn, taskname,
> taskhashlist, d):
> > >  if not taskname:
> > >  # We have to derive pn and taskname
> > >  key = pn
> > > -splitit = key.split('.bb:')
> > > -taskname = splitit[1]
> > > -pn = os.path.basename(splitit[0]).split('_')[0]
> > > -if key.startswith('virtual:native:'):
> > > -pn = pn + '-native'
> > > +if key.count(':') >= 2:
> > > +splitit, taskname, affix = key.split(':', 2)
> > > +else:
> > > +splitit, taskname = key.split(':', 1)
> > > +affix = ''
> > > +pn =
> os.path.splitext(os.path.basename(splitit))[0].split('_')[0]
> > > +affixitems = affix.split(':')
> > > +if affixitems[0] == 'virtual':
> > > +if affixitems[1] == 'native':
> > > +pn = pn + '-native'
> > > +if affixitems[1] == 'multilib':
> > > +pn = affixitems[2] + '-' + pn
> > >  
> > >  hashfiles = {}
> > >  filedates = {}
> > 
> > 
> > I've stared at this patch long and hard and I'm coming to the
> > conclusion that whilst what you're doing improves things, there are
> > more corner cases remaining and we're just moving the problem to
> new
> > ones down the road. Having to hardcode in each of the class names
> and
> > special case them is a big warning sign.
> > 
> > I started wondering why we encode pathnames into the siginfo files.
> The
> > reason is that is how bitbake handles them within runqueue. In
> earlier
> > times when this was being built, that was fine but things have been
> > extended many times over since that decision was made.
> > 
> > The issue is that those "internal" representations don't map onto
> other
> > systems, so sstate writes files in a different format. There is no
> easy
> > way to map the original representations to the format used in the
> > sstate file names.
> > 
> > My conclusion is that we should change the siginfo files to have
> the
> > data already in "sstate" format. That does potentially break a few
> > things but is probably worth doing for the simplicity gains in code
> > like this.
> 
> I've sent a couple of patches, one to bitbake and one to OE-Core
> which
> change the format of the data in runtaskdeps to be PN based rather
> than
> recipe filename based which then makes the above change unneeded, we
> no
> longer need to hardcode classes into it.
> 
> With those changes, I did confirm that the testcase added in this
> pattch does pass.
> 
> We need to review those other changes but assuming testing 

Re: [OE-core] [PATCH 2/2] linux-yocto: add script to generate kernel CVE_STATUS entries

[Marta Rybczynska]

On Mon, Aug 7, 2023 at 6:28 PM  wrote:

> From: Ross Burton 
>
> Instead of manually looking up new CVEs and determining what point
> releases the fixes are incorporated into, add a script to generate the
> CVE_STATUS data automatically.
>
> First, note that this is very much an interim solution until the
> cve-check class fetches data from www.linuxkernelcves.com directly.
>
>
This is coming Ross, this is coming...

But I have a question. We do prefer to have a solution that runs completely
on the
build machine, without automatic rebuilds from the YP? I'm asking because
for the
solution I'm working on we're adding a pretty big git repo to each build
(~130MB).

Regards,
Marta

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185654): 
https://lists.openembedded.org/g/openembedded-core/message/185654
Mute This Topic: https://lists.openembedded.org/mt/100603502/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] systemd: set correct paths for kdb binaries

[Ross Burton]

On 8 Aug 2023, at 09:32, Francesco Dolcini  wrote:
> 
> Hello,
> 
> On Fri, Aug 04, 2023 at 04:29:36PM +0100, ross.bur...@arm.com wrote:
>> From: Ross Burton 
>> 
>> The kbd binaries (loadkeys and setfont) are installed to bindir, not
>> base_bindir.
>> 
>> Fixes: 94ccc7acc4a871f5bb7ab8e135e70b5519eff6ad
>> Signed-off-by: Ross Burton 
> 
> Is my understanding correct that this patch is supposed to fix the
> following error:
> 
> ```
>>> systemd-test: systemd-vconsole-setup.service status:
> x systemd-vconsole-setup.service - Virtual Console Setup
> Loaded: loaded (/lib/systemd/system/systemd-vconsole-setup.service; 
> static)
> Active: failed (Result: exit-code) since Mon 2023-08-07 15:34:29 UTC; 
> 8min ago
>   Docs: man:systemd-vconsole-setup.service(8)
> man:vconsole.conf(5)
>Process: 765 ExecStart=/lib/systemd/systemd-vconsole-setup (code=exited, 
> status=1/FAILURE)
>   Main PID: 765 (code=exited, status=1/FAILURE)
> Aug 07 15:34:29 localhost systemd[1]: Starting Virtual Console Setup...
> Aug 07 15:34:29 localhost systemd-vconsole-setup[765]: /bin/loadkeys failed 
> with exit status 1.
> Aug 07 15:34:29 localhost systemd[1]: systemd-vconsole-setup.service: Main 
> process exited, code=exited, status=1/FAILURE
> Aug 07 15:34:29 localhost systemd[1]: systemd-vconsole-setup.service: Failed 
> with result 'exit-code'.
> Aug 07 15:34:29 localhost systemd[1]: Failed to start Virtual Console Setup.
> ```
> 
> just introduced with systemd 254 in oe-core ?

Yes, that’s right.

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

[OE-core][mickledore][PATCH 1/1] python3-pygments: upgrade 2.14.0 -> 2.15.1

[Narpat Mali via lists.openembedded.org]

From: Narpat Mali 

* Upstream has dropped setup.py
* Inherit python_setuptools_build_meta instead of setuptools3
* Add self as maintainer, as this is a dependency for python3-sphinx

Adds some new lexers, updates a few others. A handful of bug fixes.

https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L6
https://github.com/pygments/pygments/blob/2.15.1/CHANGES#L18

Have cherry-picked the upgrade commit from upstream/master:
https://git.openembedded.org/openembedded-core/commit/?id=22e2569ae4843071b2b48d026ca4742351baf6d1

Signed-off-by: Narpat Mali 
---
 meta/conf/distro/include/maintainers.inc  | 2 +-
 ...{python3-pygments_2.14.0.bb => python3-pygments_2.15.1.bb} | 4 ++--
 2 files changed, 3 insertions(+), 3 deletions(-)
 rename meta/recipes-devtools/python/{python3-pygments_2.14.0.bb => 
python3-pygments_2.15.1.bb} (76%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 07498a23a9..c9d790ca32 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -666,7 +666,7 @@ RECIPE_MAINTAINER:pn-python3-pyasn1 = "Tim Orling 
"
 RECIPE_MAINTAINER:pn-python3-pycairo = "Zang Ruochen "
 RECIPE_MAINTAINER:pn-python3-pycparser = "Tim Orling "
 RECIPE_MAINTAINER:pn-python3-pyelftools = "Joshua Watt "
-RECIPE_MAINTAINER:pn-python3-pygments = "Unassigned 
"
+RECIPE_MAINTAINER:pn-python3-pygments = "Tim Orling "
 RECIPE_MAINTAINER:pn-python3-pygobject = "Zang Ruochen 
"
 RECIPE_MAINTAINER:pn-python3-pyopenssl = "Tim Orling "
 RECIPE_MAINTAINER:pn-python3-pyparsing = "Unassigned 
"
diff --git a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb 
b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
similarity index 76%
rename from meta/recipes-devtools/python/python3-pygments_2.14.0.bb
rename to meta/recipes-devtools/python/python3-pygments_2.15.1.bb
index 16769e9263..e0e477100e 100644
--- a/meta/recipes-devtools/python/python3-pygments_2.14.0.bb
+++ b/meta/recipes-devtools/python/python3-pygments_2.15.1.bb
@@ -4,8 +4,8 @@ HOMEPAGE = "http://pygments.org/;
 LICENSE = "BSD-2-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=36a13c90514e2899f1eba7f41c3ee592"
 
-inherit setuptools3
-SRC_URI[sha256sum] = 
"b3ed06a9e8ac9a9aae5a6f5dbe78a8a58655d17b43b93c078f094ddc476ae297"
+inherit python_setuptools_build_meta
+SRC_URI[sha256sum] = 
"8ace4d3c1dd481894b2005f560ead0f9f19ee64fe983366be1a21e171d12775c"
 
 DEPENDS += "\
 ${PYTHON_PN} \
-- 
2.40.0


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

Re: [OE-Core][PATCH v2 1/3] rootfs: Add debugfs package db file copy and cleanup

[Alex Kiernan]

On Mon, Aug 7, 2023 at 9:21 PM Peter Kjellerstedt
 wrote:
>
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org 
> >  On Behalf Of Alex Kiernan
> > Sent: den 20 juli 2023 12:20
> > To: openembedded-core@lists.openembedded.org
> > Cc: Alex Kiernan 
> > Subject: [OE-Core][PATCH v2 1/3] rootfs: Add debugfs package db file copy 
> > and cleanup
> >
> > When copying the package database files for the debugfs, add individual
> > file copy as well as tree copying. After the debug rootfs has been
> > created, cleanup the package files.
> >
> > This then allows us to avoid a problem where (for rpm at least)
> > extraneous files in the debug rootfs would cause failures during
> > oe-selftest because some files existed in both regular and debugfs
> > images.
> >
> > Signed-off-by: Alex Kiernan 
> > ---
> >
> > Changes in v2:
> > - New in v2
> >
> >  meta/lib/oe/rootfs.py | 20 ++--
> >  1 file changed, 14 insertions(+), 6 deletions(-)
> >
> > diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> > index 890ba5f03984..1a48ed10b3f6 100644
> > --- a/meta/lib/oe/rootfs.py
> > +++ b/meta/lib/oe/rootfs.py
> > @@ -106,7 +106,7 @@ class Rootfs(object, metaclass=ABCMeta):
> >  def _cleanup(self):
> >  pass
> >
> > -def _setup_dbg_rootfs(self, dirs):
> > +def _setup_dbg_rootfs(self, package_paths):
> >  gen_debugfs = self.d.getVar('IMAGE_GEN_DEBUGFS') or '0'
> >  if gen_debugfs != '1':
> > return
> > @@ -122,11 +122,12 @@ class Rootfs(object, metaclass=ABCMeta):
> >  bb.utils.mkdirhier(self.image_rootfs)
> >
> >  bb.note("  Copying back package database...")
> > -for dir in dirs:
> > -if not os.path.isdir(self.image_rootfs + '-orig' + dir):
> > -continue
> > -bb.utils.mkdirhier(self.image_rootfs + os.path.dirname(dir))
> > -shutil.copytree(self.image_rootfs + '-orig' + dir, 
> > self.image_rootfs + dir, symlinks=True)
> > +for path in package_paths:
> > +bb.utils.mkdirhier(self.image_rootfs + os.path.dirname(path))
> > +if os.path.isdir(self.image_rootfs + '-orig' + path):
> > +shutil.copytree(self.image_rootfs + '-orig' + path, 
> > self.image_rootfs + path, symlinks=True)
> > +elif os.path.isfile(self.image_rootfs + '-orig' + path):
> > +shutil.copyfile(self.image_rootfs + '-orig' + path, 
> > self.image_rootfs + path)
> >
> >  # Copy files located in /usr/lib/debug or /usr/src/debug
> >  for dir in ["/usr/lib/debug", "/usr/src/debug"]:
> > @@ -162,6 +163,13 @@ class Rootfs(object, metaclass=ABCMeta):
> >  bb.note("  Install extra debug packages...")
> >  self.pm.install(extra_debug_pkgs.split(), True)
> >
> > +bb.note("  Removing package database...")
> > +for path in package_paths:
> > +if os.path.isdir(self.image_rootfs + path):
> > +shutil.rmtree(self.image_rootfs + path)
> > +elif os.path.isfile(self.image_rootfs + path):
> > +os.remove(self.image_rootfs + path)
>
> What's the reason to do it like this rather than calling
> self.pm.remove_packaging_data()?
>

Just looking now, I suspect only that I didn't notice that it existed!
Though looking across the other packaging implementations, it looks
like you'd get different things removed than were passed initially.
Certainly looks like a refactor would be in order.

> I also just noticed that we apparently have a local change that does the
> above, but where we also do:
>
>  # Remove /etc as it may clash with rootfs.  Also saves some space.
>  bb.utils.remove(oe.path.join(self.image_rootfs, 'etc'), True)
>
> I do not know if that would be appropriate to do here as well?
>

The clash was exactly what I was fixing here (gshadow), but prior to
these two changes you got the whole of /etc copied, so a clash was
exactly what you were in danger of running into - anything that
clashes now, I think wants investigating as to why, rather than just
wiping out `/etc` entirely.

-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185651): 
https://lists.openembedded.org/g/openembedded-core/message/185651
Mute This Topic: https://lists.openembedded.org/mt/100252894/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] externalsrc: fix dependency chain issues

[Richard Purdie]

On Mon, 2023-08-07 at 16:15 +0200, Peter Suti wrote:
> On Mon, Aug 7, 2023 at 2:55 PM Richard Purdie
>  wrote:
> > 
> > On Mon, 2023-08-07 at 13:19 +0200, Peter Suti wrote:
> > > On Fri, Aug 4, 2023 at 4:47 PM Richard Purdie
> > >  wrote:
> > > > 
> > > > Do you have a way to reproduce this using recipes in OE-Core?
> > > > 
> > > > For example, I tried adding this to the cairo recipe:
> > > > 
> > > > EXTERNALSRC = "/xxx/cairo-1.16.0"
> > > > inherit externalsrc
> > > > 
> > > > and then building cairo, cleaning cairo, building pango (which depends
> > > > on cairo). I couldn't see any failure.
> > > > 
> > > 
> > > To reproduce you need a transitive dependency on a recipe using
> > > externalsrc and run populate_sysroot.
> > > 
> > >  I can trigger it with the following sequence:
> > > 1) make cairo inherit externalsrc just like you described above.
> > > 2) build a package that depends on pango, for example libfm: bitbake libfm
> > > 3) clean cairo sstate: bitbake -c cleansstate cairo
> > > 4) rerun prepare_recipe_sysroot for libfm: bitbake -c
> > > prepare_recipe_sysroot -f libfm
> > > 
> > > This produces the following error for me:
> > > ERROR: libfm-1.3.2-r0 do_prepare_recipe_sysroot: The sstate manifest
> > > for task 'cairo:populate_sysroot' (multilib variant '') could not be
> > > found.
> > > The pkgarchs considered were: armv8a-crc, armv8a, aarch64, allarch,
> > > x86_64_x86_64-nativesdk.
> > > But none of these manifests exists:
> > > /home/yocto/.build-yocto/tmp/sstate-control/manifest-armv8a-crc-cairo.populate_sysroot
> > > /home/yocto/.build-yocto/tmp/sstate-control/manifest-armv8a-cairo.populate_sysroot
> > > /home/yocto/.build-yocto/tmp/sstate-control/manifest-aarch64-cairo.populate_sysroot
> > > /home/yocto/.build-yocto/tmp/sstate-control/manifest-allarch-cairo.populate_sysroot
> > > /home/yocto/.build-yocto/tmp/sstate-control/manifest-x86_64_x86_64-nativesdk-cairo.populate_sysroot
> > > ERROR: Logfile of failure stored in:
> > > /home/yocto/.build-yocto/tmp/work/armv8a-poky-linux/libfm/1.3.2-r0/temp/log.do_prepare_recipe_sysroot.3102616
> > > ERROR: Task 
> > > (/home/yocto/poky/meta/recipes-support/libfm/libfm_1.3.2.bb:do_prepare_recipe_sysroot)
> > > failed with exit code '1'
> > > 
> > > > > I'd like to thank you for the time you have invested in this issue! I
> > > > > appreciate the help.
> > > > > I understand that my proposed solution might not be ideal, but fixing
> > > > > the underlying issue in runqueue would be a real challenge.
> > > > > If upstream is not interested in this patch, I can also understand 
> > > > > that.
> > > > 
> > > > It isn't that we're not interested, we just need to make sure something
> > > > else doesn't break. A test case to reproduce the issue you're seeing
> > > > would help a lot. Ultimately we should perhaps add something to the
> > > > tests in meta/lib/oeqa/ to cover the issue.
> > > 
> > > I agree that a test would be valuable for this. I'll try to look into
> > > how such a testcase could be constructed.
> > 
> > I tried:
> > 
> > bitbake libfm; bitbake -c cleansstate cairo; bitbake -c 
> > prepare_recipe_sysroot -f libfm
> > 
> > with cairo marked as externalsrc and everything built just fine. Can
> > you confirm which release of the project you're using please? I tested
> > with master.
> > 
> 
> I have just tried with 058a44165ce375f405063e73a9fcd1b2757ef8da and I
> could reproduce it.
> I did not notice before but on the first try the issue is not
> triggered, but running the following two commands it eventually
> breaks:
> 1) bitbake -c cleansstate cairo
> 2) bitbake -c prepare_recipe_sysroot -f libfm
> 
> It did not happen on the first 2 runs for me, but it did happen on the 3rd 
> one.
> 
> Could you check if running this a few times reproduces the issue?
> `bitbake -c cleansstate cairo; bitbake -c prepare_recipe_sysroot -f libfm`
> 
> Because eventually cairo is not built, just skipped entirely.

Thanks, with this tip I was able to reproduce the issue locally.

I've spent some time looking at what was happening and why. I also dug
into the history to find out who added the deltask and when (me back in
2012 it seems when externalsrc was created).

After all of that I'm starting to think your patch or something similar
might be the right thing to do to resolve the issues here.

The main issue is that runqueue has stopped seeing populate_sysroot as
an sstate task as the setscene task is missing. The options come down
to either teaching bitbake a new way of recognising sstate tasks even
when setscene isn't there, or putting the setscene tasks back and
disabling them some other way which your patch does.

Meanwhile we probably should put it through wider testing and see how
that looks.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#185650): 
https://lists.openembedded.org/g/openembedded-core/message/185650
Mute This Topic: