[OE-core] [dunfell][PATCH] QEMU: CVE-2022-4144 QXL: qxl_phys2virt unsafe address translation can lead to out-of-bounds read

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://gitlab.com/qemu-project/qemu/-/commit/6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622

Signed-off-by: Hitendra Prajapati 
---
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 .../qemu/qemu/CVE-2022-4144.patch | 103 ++
 2 files changed, 104 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index fff2c87780..898fa1a8d8 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -115,6 +115,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
   file://CVE-2021-3638.patch \
   file://CVE-2021-20196.patch \
   file://CVE-2021-3507.patch \
+  file://CVE-2022-4144.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
new file mode 100644
index 00..3f0d5fbd5c
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
@@ -0,0 +1,103 @@
+From 6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Mon, 28 Nov 2022 21:27:40 +0100
+Subject: [PATCH] hw/display/qxl: Avoid buffer overrun in qxl_phys2virt
+ (CVE-2022-4144)
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Have qxl_get_check_slot_offset() return false if the requested
+buffer size does not fit within the slot memory region.
+
+Similarly qxl_phys2virt() now returns NULL in such case, and
+qxl_dirty_one_surface() aborts.
+
+This avoids buffer overrun in the host pointer returned by
+memory_region_get_ram_ptr().
+
+Fixes: CVE-2022-4144 (out-of-bounds read)
+Reported-by: Wenxu Yin (@awxylitol)
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1336
+
+Signed-off-by: Philippe Mathieu-Daudé 
+Signed-off-by: Stefan Hajnoczi 
+Message-Id: <20221128202741.4945-5-phi...@linaro.org>
+
+Upstream-Status: Backport 
[https://gitlab.com/qemu-project/qemu/-/commit/6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622]
+CVE: CVE-2022-4144
+Comments: Deleted patch hunk in qxl.h,as it contains change
+in comments which is not present in current version of qemu.
+
+Signed-off-by: Hitendra Prajapati 
+---
+ hw/display/qxl.c | 27 +++
+ 1 file changed, 23 insertions(+), 4 deletions(-)
+
+diff --git a/hw/display/qxl.c b/hw/display/qxl.c
+index cd7eb39d..6bc8385b 100644
+--- a/hw/display/qxl.c
 b/hw/display/qxl.c
+@@ -1440,11 +1440,13 @@ static void qxl_reset_surfaces(PCIQXLDevice *d)
+ 
+ /* can be also called from spice server thread context */
+ static bool qxl_get_check_slot_offset(PCIQXLDevice *qxl, QXLPHYSICAL pqxl,
+-  uint32_t *s, uint64_t *o)
++  uint32_t *s, uint64_t *o,
++  size_t size_requested)
+ {
+ uint64_t phys   = le64_to_cpu(pqxl);
+ uint32_t slot   = (phys >> (64 -  8)) & 0xff;
+ uint64_t offset = phys & 0x;
++uint64_t size_available;
+ 
+ if (slot >= NUM_MEMSLOTS) {
+ qxl_set_guest_bug(qxl, "slot too large %d >= %d", slot,
+@@ -1468,6 +1470,23 @@ static bool qxl_get_check_slot_offset(PCIQXLDevice 
*qxl, QXLPHYSICAL pqxl,
+   slot, offset, qxl->guest_slots[slot].size);
+ return false;
+ }
++size_available = memory_region_size(qxl->guest_slots[slot].mr);
++if (qxl->guest_slots[slot].offset + offset >= size_available) {
++qxl_set_guest_bug(qxl,
++  "slot %d offset %"PRIu64" > region size 
%"PRIu64"\n",
++  slot, qxl->guest_slots[slot].offset + offset,
++  size_available);
++return false;
++}
++size_available -= qxl->guest_slots[slot].offset + offset;
++if (size_requested > size_available) {
++qxl_set_guest_bug(qxl,
++  "slot %d offset %"PRIu64" size %zu: "
++  "overrun by %"PRIu64" bytes\n",
++  slot, offset, size_requested,
++  size_requested - size_available);
++return false;
++}
+ 
+ *s = slot;
+ *o = offset;
+@@ -1486,7 +1505,7 @@ void *qxl_phys2virt(PCIQXLDevice *qxl, QXLPHYSICAL pqxl, 
int group_id)
+ offset = le64_to_cpu(pqxl) & 0x;
+ return (void *)(intptr_t)offset;
+ case MEMSLOT_GROUP_GUEST:
+-if (!qxl_get_check_slot_offset(qxl, pqxl, , )) {
++if (!qxl_get_check_slot_offset(qxl, pqxl, , , size)) {
+ return NULL;
+ }
+ ptr = memory_region_get_ram_ptr(qxl->guest_slots[slot].mr);
+@@ -1944,9 +1963,9 @@ static void qxl_dirty_one_surface(PCIQXLDevice *qxl, 
QXLPHYSICAL pqxl,
+ uint32_t slot;
+ bool rc;
+ 
+-

[OE-core][PATCH 2/2] rpm: do not export MAGIC in SDK

[Chen Qi]

This MAGIC variable is used by libmagic (file), and should
be exported by the file recipe.

As the rpm recipe has 'file' in its DEPENDS, its sub-packages
which links to libmagic will be automatically added the 'file'
runtime dependency. More specifically, it's the rpm-build package.
So in case components in nativesdk-rpm-build package uses libmagic,
the nativesdk-file package will be installed and the MAGIC var
will be exported.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
index 8eb0ab207e..61e395a9d0 100644
--- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
@@ -123,7 +123,6 @@ do_install:append:class-nativesdk() {
cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/rpm.sh
export RPM_CONFIGDIR="$OECORE_NATIVE_SYSROOT${libdir}/rpm"
export RPM_ETCCONFIGDIR="$OECORE_NATIVE_SYSROOT${sysconfdir}"
-   export MAGIC="$OECORE_NATIVE_SYSROOT${datadir}/misc/magic.mgc"
export RPM_NO_CHROOT_FOR_SCRIPTS=1
EOF
 }
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176028): 
https://lists.openembedded.org/g/openembedded-core/message/176028
Mute This Topic: https://lists.openembedded.org/mt/96324206/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] file: export MAGIC in SDK

[Chen Qi]

Previously, a wrapper is used for file, which adds '--magic-file'
option to it. But other components might use libmagic and in such
case, if there's no MAGIC environent variable set correctly, things
do not work. For example, rpmbuild makes use of libmagic and it
requries MAGIC to be set correctly.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/file/file_5.44.bb | 7 +--
 1 file changed, 5 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/file/file_5.44.bb 
b/meta/recipes-devtools/file/file_5.44.bb
index b3d821518a..d4b49341b7 100644
--- a/meta/recipes-devtools/file/file_5.44.bb
+++ b/meta/recipes-devtools/file/file_5.44.bb
@@ -32,6 +32,7 @@ EXTRA_OEMAKE:append:class-target = " -e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/fi
 EXTRA_OEMAKE:append:class-nativesdk = " -e 
FILE_COMPILE=${STAGING_BINDIR_NATIVE}/file-native/file"
 
 FILES:${PN} += "${datadir}/misc/*.mgc"
+FILES:${PN}:append:class-nativesdk = " 
${SDKPATHNATIVE}/environment-setup.d/file.sh"
 
 do_compile:append:class-native() {
oe_runmake check
@@ -43,8 +44,10 @@ do_install:append:class-native() {
 }
 
 do_install:append:class-nativesdk() {
-   create_cmdline_wrapper ${D}/${bindir}/file \
-   --magic-file ${datadir}/misc/magic.mgc
+   mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
+   cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/file.sh
+   export MAGIC="$OECORE_NATIVE_SYSROOT${datadir}/misc/magic.mgc"
+   EOF
 }
 
 BBCLASSEXTEND = "native nativesdk"
-- 
2.17.1


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

Re: [OE-Core][PATCH 3/3] qemuppc64: set the qemuppc64 nfs r/wsize mount options to 524288

[Khem Raj]

On Mon, Jan 16, 2023 at 6:05 PM Xiangyu Chen
 wrote:
>
> From: Xiangyu Chen 
>
> On master oe, build a qemuppc64 with systemd as default init, when we
> use nfs bootup, the kernel might panic due to missing symbol in dynamic
> libraries as below:
>
>   hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB 
> Tablet] on usb-:00:01.0-3/input0
>   /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by 
> /usr/lib64/libkmod.so.2)
>   Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00
>   CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1
>   Call Trace:
>   [c7443ba0] [c09538d0] dump_stack_lvl+0x74/0xa8 (unreliable)
>   [c7443be0] [c0103524] panic+0x170/0x3cc
>   [c7443c80] [c010cf64] do_exit+0xb44/0xb50
>   [c7443d50] [c010d040] do_group_exit+0x60/0xd0
>   [c7443d90] [c010d0d4] sys_exit_group+0x24/0x30
>   [c7443db0] [c002cfd4] system_call_exception+0x194/0x2f0
>   [c7443e10] [c000c2cc] system_call_common+0xec/0x250
>   --- interrupt: c00 at 0x7fff9ed9e840
>   NIP:  7fff9ed9e840 LR: 7fff9ed7da20 CTR: 
>   REGS: c7443e80 TRAP: 0c00   Not tainted (5.15.78-yocto-standard)
>   MSR:  8280f033   CR: 24022442  
> XER: 
>
> One or more of the libraries systemd depends on failed to load due to
> unresolved symbols/functions.  This was intermittent - with a failure
> rate estimated between 5% and 30%.
>
> After checking the code, this issue happens on gcc 12, kirkstone is using
> gcc 11 works well, with both using the exact same v5.15.84 kernel commit.
>
> There is a kernel fix from upstream [1], they changed the rsize / wsize
> to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's
> default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have
> its own linux-yocto kernel branch, so apply this change might cause
> regression with other platforms which share branch with qemuppc64.
>
> So, we added an extra option for nfs rootfs, and set the qemuppc64 default
> r/w size to 524288 to line up with the kernel fix[1].
>
> Yocto did a similar thing in the distant past[2] - prior to boot-arg
> adjustments existing - by allowing a Kconfig to set the defaults on
> nfsboot, in order to work around hardware limitations.
>
> Reference:
> [1] 
> https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf
> [2] 
> https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base=a96cfd98add95
>
> Signed-off-by: Xiangyu Chen 
> ---
>  meta/conf/machine/qemuppc64.conf | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/conf/machine/qemuppc64.conf 
> b/meta/conf/machine/qemuppc64.conf
> index 304f06a30d..7709339313 100644
> --- a/meta/conf/machine/qemuppc64.conf
> +++ b/meta/conf/machine/qemuppc64.conf
> @@ -15,6 +15,7 @@ QB_MACHINE = "-machine pseries"
>  QB_CPU = "-cpu POWER9"
>  QB_SMP = "-smp 2"
>
> +QB_NFSROOTFS_EXTRA_OPT = "wsize=524288,rsize=524288"

lgtm

>  QB_KERNEL_CMDLINE_APPEND = "console=hvc0 nohugevmalloc"
>  #QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
>  QB_OPT_APPEND = "-usb -device usb-tablet"
> --
> 2.34.1
>
>
> 
>

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

[OE-core] Current high bug count owners for Yocto Project 4.2

[Stephen Jolley]

All,

Below is the list as of top 34 bug owners as of the end of WW02 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 71
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


michael.opdenac...@bootlin.com

34


ross.bur...@arm.com

32


randy.macl...@windriver.com

26


bruce.ashfi...@gmail.com

25


richard.pur...@linuxfoundation.org

25


david.re...@windriver.com

23


jpewhac...@gmail.com

10


sakib.sa...@windriver.com

8


saul.w...@windriver.com

5


tim.orl...@konsulko.com

5


pi...@toganlabs.com

4


pa...@zhukoff.net

4


thomas.per...@bootlin.com

2


rybczyn...@gmail.com

2


bluelightn...@bluelightning.org

2


s...@bigsur.com

2


zheng@windriver.com

2


jon.ma...@arm.com

2


naveen.go...@windriver.com

2


alexis.loth...@bootlin.com

2


sundeep.kokko...@gmail.com

2


anton.anto...@arm.com

1


yoann.con...@smile.fr

1


yashinde...@gmail.com

1


tvgamb...@gmail.com

1


sundeep.kokko...@windriver.com

1


martin.ja...@gmail.com

1


aeh...@gmail.com

1


thr...@amazon.de

1


mathew.pro...@gmail.com

1


mhalst...@linuxfoundation.org

1


alex.kana...@gmail.com

1


hongxu@windriver.com

1


alexandre.bell...@bootlin.com

1


Grand Total

232

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176025): 
https://lists.openembedded.org/g/openembedded-core/message/176025
Mute This Topic: https://lists.openembedded.org/mt/96323570/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 Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 417
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now,  "4.2", "4.3", "4.99" and "Future", the more pressing/urgent
issues being in "4.2" and then "4.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


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

[OE-Core][PATCH 0/3] set qemuppc64 default nfs rootfs mount r/w size to 524288

[Xiangyu Chen]

From: Xiangyu Chen 

On master oe, build a qemuppc64 with systemd as default init, when we
use nfs bootup, the kernel might panic due to missing symbol in dynamic
libraries as below:

  hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB 
Tablet] on usb-:00:01.0-3/input0
  /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by 
/usr/lib64/libkmod.so.2)
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00
  CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1
  Call Trace:
  [c7443ba0] [c09538d0] dump_stack_lvl+0x74/0xa8 (unreliable)
  [c7443be0] [c0103524] panic+0x170/0x3cc
  [c7443c80] [c010cf64] do_exit+0xb44/0xb50
  [c7443d50] [c010d040] do_group_exit+0x60/0xd0
  [c7443d90] [c010d0d4] sys_exit_group+0x24/0x30
  [c7443db0] [c002cfd4] system_call_exception+0x194/0x2f0
  [c7443e10] [c000c2cc] system_call_common+0xec/0x250
  --- interrupt: c00 at 0x7fff9ed9e840
  NIP:  7fff9ed9e840 LR: 7fff9ed7da20 CTR: 
  REGS: c7443e80 TRAP: 0c00   Not tainted (5.15.78-yocto-standard)
  MSR:  8280f033   CR: 24022442  
XER: 

One or more of the libraries systemd depends on failed to load due to
unresolved symbols/functions.  This was intermittent - with a failure
rate estimated between 5% and 30%.

After checking the code, this issue happens on gcc 12, kirkstone is using
gcc 11 works well, with both using the exact same v5.15.84 kernel commit.

There is a kernel fix from upstream [1], they changed the rsize / wsize
to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's
default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have
its own linux-yocto kernel branch, so apply this change might cause
regression with other platforms which share branch with qemuppc64.

So, we added an extra option for nfs rootfs, and set the qemuppc64 default
r/w size to 524288 to line up with the kernel fix[1].

Yocto did a similar thing in the distant past[2] - prior to boot-arg
adjustments existing - by allowing a Kconfig to set the defaults on
nfsboot, in order to work around hardware limitations.

There are 3 patches for this fix:
the patch 1 added QB_NFSROOTFS_EXTRA_OPT in qemuboot.bbclass,it contains 
a default QB_NFSROOTFS_EXTRA_OPT value and some notes in comment.
the patch 2 contains processing this value in runqemu script
the patch 3 set the r/wsize value in qemuppc64 machine configuration
file.

Reference:
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf
[2] 
https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base=a96cfd98add95

Xiangyu Chen (3):
  qemuboot.bbclass: add QB_NFSROOTFS_EXTRA_OPT for nfs rootfs extra
option
  runqemu: add process of option QB_NFSROOTFS_EXTRA_OPT
  qemuppc64: set the qemuppc64 nfs r/wsize mount options to 524288

 meta/classes-recipe/qemuboot.bbclass | 3 +++
 meta/conf/machine/qemuppc64.conf | 1 +
 scripts/runqemu  | 6 +-
 3 files changed, 9 insertions(+), 1 deletion(-)

-- 
2.34.1


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

[OE-Core][PATCH 3/3] qemuppc64: set the qemuppc64 nfs r/wsize mount options to 524288

[Xiangyu Chen]

From: Xiangyu Chen 

On master oe, build a qemuppc64 with systemd as default init, when we
use nfs bootup, the kernel might panic due to missing symbol in dynamic
libraries as below:

  hid-generic 0003:0627:0001.0003: input: USB HID v0.01 Mouse [QEMU QEMU USB 
Tablet] on usb-:00:01.0-3/input0
  /sbin/init: /lib64/libm.so.6: version `XZ_5.0' not found (required by 
/usr/lib64/libkmod.so.2)
  Kernel panic - not syncing: Attempted to kill init! exitcode=0x7f00
  CPU: 0 PID: 1 Comm: init Not tainted 5.15.78-yocto-standard #1
  Call Trace:
  [c7443ba0] [c09538d0] dump_stack_lvl+0x74/0xa8 (unreliable)
  [c7443be0] [c0103524] panic+0x170/0x3cc
  [c7443c80] [c010cf64] do_exit+0xb44/0xb50
  [c7443d50] [c010d040] do_group_exit+0x60/0xd0
  [c7443d90] [c010d0d4] sys_exit_group+0x24/0x30
  [c7443db0] [c002cfd4] system_call_exception+0x194/0x2f0
  [c7443e10] [c000c2cc] system_call_common+0xec/0x250
  --- interrupt: c00 at 0x7fff9ed9e840
  NIP:  7fff9ed9e840 LR: 7fff9ed7da20 CTR: 
  REGS: c7443e80 TRAP: 0c00   Not tainted (5.15.78-yocto-standard)
  MSR:  8280f033   CR: 24022442  
XER: 

One or more of the libraries systemd depends on failed to load due to
unresolved symbols/functions.  This was intermittent - with a failure
rate estimated between 5% and 30%.

After checking the code, this issue happens on gcc 12, kirkstone is using
gcc 11 works well, with both using the exact same v5.15.84 kernel commit.

There is a kernel fix from upstream [1], they changed the rsize / wsize
to a multiple of PAGE_SIZE, when we applied this patch, the qemuppc64's
default r/wsize went from 4096 to 524288.But the qemuppc64 doesn't have
its own linux-yocto kernel branch, so apply this change might cause
regression with other platforms which share branch with qemuppc64.

So, we added an extra option for nfs rootfs, and set the qemuppc64 default
r/w size to 524288 to line up with the kernel fix[1].

Yocto did a similar thing in the distant past[2] - prior to boot-arg
adjustments existing - by allowing a Kconfig to set the defaults on
nfsboot, in order to work around hardware limitations.

Reference:
[1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=940261a195080cf
[2] 
https://git.yoctoproject.org/linux-yocto-4.1/commit/?h=standard/base=a96cfd98add95

Signed-off-by: Xiangyu Chen 
---
 meta/conf/machine/qemuppc64.conf | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/machine/qemuppc64.conf b/meta/conf/machine/qemuppc64.conf
index 304f06a30d..7709339313 100644
--- a/meta/conf/machine/qemuppc64.conf
+++ b/meta/conf/machine/qemuppc64.conf
@@ -15,6 +15,7 @@ QB_MACHINE = "-machine pseries"
 QB_CPU = "-cpu POWER9"
 QB_SMP = "-smp 2"
 
+QB_NFSROOTFS_EXTRA_OPT = "wsize=524288,rsize=524288"
 QB_KERNEL_CMDLINE_APPEND = "console=hvc0 nohugevmalloc"
 #QB_OPT_APPEND += "-device qemu-xhci -device usb-tablet -device usb-kbd"
 QB_OPT_APPEND = "-usb -device usb-tablet"
-- 
2.34.1


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

[OE-Core][PATCH 1/3] qemuboot.bbclass: add QB_NFSROOTFS_EXTRA_OPT for nfs rootfs extra option

[Xiangyu Chen]

From: Xiangyu Chen 

This extra options to be appended to the nfs rootfs options in kernel boot arg.

Signed-off-by: Xiangyu Chen 
---
 meta/classes-recipe/qemuboot.bbclass | 3 +++
 1 file changed, 3 insertions(+)

diff --git a/meta/classes-recipe/qemuboot.bbclass 
b/meta/classes-recipe/qemuboot.bbclass
index 5a0e50ccfc..444871438d 100644
--- a/meta/classes-recipe/qemuboot.bbclass
+++ b/meta/classes-recipe/qemuboot.bbclass
@@ -86,6 +86,8 @@
 #  without the need to specify a dedicated qemu 
configuration
 #
 # QB_GRAPHICS: QEMU video card type (e.g. "-vga std")
+# QB_NFSROOTFS_EXTRA_OPT: extra options to be appended to the nfs rootfs 
options in kernel boot arg, e.g.,
+# "wsize=4096,rsize=4096"
 #
 # Usage:
 # IMAGE_CLASSES += "qemuboot"
@@ -103,6 +105,7 @@ 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_ROOTFS_EXTRA_OPT ?= ""
 QB_GRAPHICS ?= ""
+QB_NFSROOTFS_EXTRA_OPT ?= ""
 
 # This should be kept align with ROOT_VM
 QB_DRIVE_TYPE ?= "/dev/sd"
-- 
2.34.1


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

[OE-Core][PATCH 2/3] runqemu: add process of option QB_NFSROOTFS_EXTRA_OPT

[Xiangyu Chen]

From: Xiangyu Chen 

This extra options to be appended to the nfs rootfs options in kernel
boot arg.

Example config with qemuppc64 in machine config:

add r/w size in the nfs rootfs extra option:
QB_NFSROOTFS_EXTRA_OPT = "wsize=524288,rsize=524288"

re-build and runqemu with nfs again, we can observe the kernel command
line added our defined value in QB_NFSROOTFS_EXTRA_OPT:

Kernel command line: root=/dev/nfs 
nfsroot=10.0.2.2:/home/xchen5/testing/build/tmp-glibc/deploy/images/qemuppc64/testnfs,nfsvers=3,port=3049,tcp,mountport=3048,wsize=524288,rsize=524288
 rw  mem=256M ip=dhcp console=hvc0 console=hvc0 nohugevmalloc

Signed-off-by: Xiangyu Chen 
---
 scripts/runqemu | 6 +-
 1 file changed, 5 insertions(+), 1 deletion(-)

diff --git a/scripts/runqemu b/scripts/runqemu
index ccc557f308..5907390573 100755
--- a/scripts/runqemu
+++ b/scripts/runqemu
@@ -1022,7 +1022,11 @@ class BaseConfig(object):
 # Use '%s' since they are integers
 os.putenv(k, '%s' % v)
 
-self.unfs_opts="nfsvers=3,port=%s,tcp,mountport=%s" % (nfsd_port, 
mountd_port)
+qb_nfsrootfs_extra_opt = self.get("QB_NFSROOTFS_EXTRA_OPT")
+if qb_nfsrootfs_extra_opt and not 
qb_nfsrootfs_extra_opt.startswith(","):
+qb_nfsrootfs_extra_opt = "," + qb_nfsrootfs_extra_opt
+
+self.unfs_opts="nfsvers=3,port=%s,tcp,mountport=%s%s" % (nfsd_port, 
mountd_port, qb_nfsrootfs_extra_opt)
 
 # Extract .tar.bz2 or .tar.bz if no nfs dir
 if not (self.rootfs and os.path.isdir(self.rootfs)):
-- 
2.34.1


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

[OE-core] [PATCH v2] scripts/oe-setup-layers: Make efficiently idempotent

[Chuck Wolber]

The effect of subsequent setup-layers executions is now either a NOOP
or the minimal set of changes required to ensure layers precisely match
the JSON configuration.

This change allows setup-layers to be incorporated into a team's
configuration management strategy. In particular, the configuration
JSON manages a "pinning policy" that documents the oversight of sources
of change (a requirement for embedded development in highly regulated
industries).

One model for this strategy would work as follows. Team level policy is
developed to regularly review upstream commits that occur between the
current upstream HEAD and the previously pinned revision. The JSON
configuration is periodically updated after a review, test, and approval
process. In the rare instance that an upstream change is considered
problematic, the bbappend mechanism can be used to make relevant
changes in the team's project repository. This approach also requires
that team developers regularly run the project repository copy of
setup-layers. This is most easily accomplished by including setup-layers
in a wrapper script that all team developers use to interact with the
bitbake tool suite (e.g. "bb bitbake foo-image"). Project level policy
and oversight is effectively "contained" within this wrapper script,
thereby reducing a significant source of human error.

Left unstated, but acknowledged here, are a number of nuances required
to successfully implement the above strategy.  The details are out of
scope for this explanation. What should be clear is that a larger
configuration management strategy can now benefit from the utility
provided by setup-layers.

Note: Neither the above configuration management strategy example nor
the change itself is intended to alter the original intent to use
"bitbake-layers create-layers-setup destdir" to keep pace with upstream
activity for those who wish to use it that way.

Signed-off-by: Chuck Wolber 
---
 scripts/oe-setup-layers | 55 +
 1 file changed, 46 insertions(+), 9 deletions(-)

diff --git a/scripts/oe-setup-layers b/scripts/oe-setup-layers
index 6ecaffe..d0bc9f1 100755
--- a/scripts/oe-setup-layers
+++ b/scripts/oe-setup-layers
@@ -10,12 +10,42 @@
 # bitbake-layers create-layers-setup destdir
 #
 # It is recommended that you do not modify this file directly, but rather 
re-run the above command to get the freshest upstream copy.
+#
+# This script is idempotent. Subsequent runs only change what is necessary to
+# ensure your layers match your configuration.
 
 import argparse
 import json
 import os
 import subprocess
 
+def _is_layer_git_repo(layerdir):
+git_dir = os.path.join(layerdir, ".git")
+if not os.access(git_dir, os.R_OK):
+return False
+try:
+return subprocess.check_output("git -C %s rev-parse 
--is-inside-git-dir" % git_dir, shell=True, stderr=subprocess.DEVNULL)
+except subprocess.CalledProcessError:
+return False
+
+def _is_layer_at_rev(layerdir, rev):
+try:
+curr_rev = subprocess.check_output("git -C %s rev-parse HEAD" % 
layerdir, shell=True, stderr=subprocess.DEVNULL)
+if curr_rev.strip().decode("utf-8") == rev:
+return True
+except subprocess.CalledProcessError:
+pass
+return False
+
+def _is_layer_at_remote_uri(layerdir, remote, uri):
+try:
+curr_uri = subprocess.check_output("git -C %s remote get-url %s" % 
(layerdir, remote), shell=True, stderr=subprocess.DEVNULL)
+if curr_uri.strip().decode("utf-8") == uri:
+return True
+except subprocess.CalledProcessError:
+pass
+return False
+
 def _do_checkout(args, json):
 layers = json['sources']
 for l_name in layers:
@@ -36,23 +66,30 @@ def _do_checkout(args, json):
 remotes = l_remote['remotes']
 
 print('\nSetting up source {}, revision {}, branch {}'.format(l_name, 
desc, branch))
-cmd = 'git init -q {}'.format(layerdir)
-print("Running '{}'".format(cmd))
-subprocess.check_output(cmd, shell=True)
+if not _is_layer_git_repo(layerdir):
+cmd = 'git init -q {}'.format(layerdir)
+print("Running '{}'".format(cmd))
+subprocess.check_output(cmd, shell=True)
 
 for remote in remotes:
-cmd = "git remote remove {} > /dev/null 2>&1; git remote add {} 
{}".format(remote, remote, remotes[remote]['uri'])
+if not _is_layer_at_remote_uri(layerdir, remote, 
remotes[remote]['uri']):
+cmd = "git remote remove {} > /dev/null 2>&1; git remote add 
{} {}".format(remote, remote, remotes[remote]['uri'])
+print("Running '{}' in {}".format(cmd, layerdir))
+subprocess.check_output(cmd, shell=True, cwd=layerdir)
+
+cmd = "git fetch -q {} || true".format(remote)
+print("Running '{}' in {}".format(cmd, layerdir))
+subprocess.check_output(cmd, shell=True, cwd=layerdir)
+

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

[Jing Hui Tham]

Hi all,
 
Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.22.rc1. 
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. MinnowTurbot 32-bit
2. NUC 7
3. ADL
4. TGL NUC 11
5. Edgerouter
6. Beaglebone
 
ETA for completion this Thursday, 19/1/2023.
 
Best regards,
Jing Hui


> -Original Message-
> From: qa-build-notificat...@lists.yoctoproject.org  notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User
> Sent: Saturday, 14 January, 2023 10:11 AM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [qa-build-notification] QA notification for completed autobuilder
> build (yocto-3.1.22.rc1)
> 
> 
> A build flagged for QA (yocto-3.1.22.rc1) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-3.1.22.rc1
> 
> 
> Build hash information:
> 
> bitbake: e3db9c2e9eded3c5cb6040714a6054b44f6b3880
> meta-agl: ae982d798a979ee5690bee00ca90a2855bab4802
> meta-arm: d13be36099aff7ea2975a1a197564e2e801707a3
> meta-aws: c013258cecbf99528291e55005e1db360d7eb40b
> meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
> meta-intel: 6c202291925bb179d2d08b5bde80192f9b032b88
> meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
> meta-openembedded: 7952135f650b4a754e2255f5aa03973a32344123
> meta-virtualization: beea119eb529b4a11f266004aee8b548427aea39
> oecore: db81e3c7e7f1d4d9eba52ac35ac97627d0240b63
> poky: 6b8a307b7843af23d189d7ffcecf32c05afac850
> 
> 
> 
> 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 (#176018): 
https://lists.openembedded.org/g/openembedded-core/message/176018
Mute This Topic: https://lists.openembedded.org/mt/96322176/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] Make oe-setup-layers efficiently idempotent

[Chuck Wolber]

On 1/16/23, 9:00 AM, "Richard Purdie" mailto:richard.pur...@linuxfoundation.org>> wrote:

%< SNIP %< 

> Making the script rerun successfully seems sensible so the change
> itself is reasonable. I was a little confused by some of the comments
> in the commit message as oe-setup-layers doesn't apply patches as far
> as I know. Is that something you're thinking of adding?

I am indeed. But I realize that it probably confused things too much with that
comment, so I removed it. The patch application feature I have in mind needs
a lot more work, and probably some discussion. We use it internally, but for
broader use it cannot make certain assumptions.


> One small cosmetic issue is that the area of code the patch changes
> should be as a prefix in the shortlog, e.g. "scripts/oe-setup-layers:"
> in this case. It means people can understand the rough scope of the
> patch from a glance.

Sorry about that. Fixed in v2.


> Whilst not essential, I do like Alex's suggestion about improving the
> tests too, not sure if that is possible.

Agreed. I took a look and I do not see much that I would be able to change. My
changes do not alter any existing behavior, nor do they resolve any bugs. They
simply limit the scope of change in subsequent runs to only what is needed.


> I also noticed the patch is against master-next, which usually would be
> fine except I did drop a patch there which means this one no longer
> applies. If you could rebase it for the v2 with the shortlog fix that
> would be much appreciated.

Fixed in v2. Should arrive shortly.

Thank you,

..Ch:W..


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176017): 
https://lists.openembedded.org/g/openembedded-core/message/176017
Mute This Topic: https://lists.openembedded.org/mt/96278464/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] rust: Merge all rustc-source patches into rust-source.inc

[Randy MacLeod]

On 2023-01-16 07:17, Kokkonda, Sundeep via lists.openembedded.org wrote:
Adding 'IMAGE_INSTALL:append = " packagegroup-core-buildessential" ' 


Please make the target build of rust (cargo?) depend on just the parts need
packagegroup-core-buildessential, i.e. you don't need autoconf, make, 
pkgconfig

and likely more from the packagegroup shown below.

I'd assume that it's rust that need the linker rather than cargo, right?

../Randy

cat `fd packagegroup-core-buildessential`
#
# Copyright (C) 2007 OpenedHand Ltd.
# Copyright (C) 2012 Red Hat, Inc.
#

SUMMARY = "Essential build dependencies"

# libstdc++ gets debian renamed
PACKAGE_ARCH = "${TUNE_PKGARCH}"

inherit packagegroup

RDEPENDS:packagegroup-core-buildessential = "\
autoconf \
automake \
binutils \
binutils-symlinks \
cpp \
cpp-symlinks \
gcc \
gcc-symlinks \
g++ \
g++-symlinks \
gettext \
make \
libstdc++ \
libstdc++-dev \
libtool \
pkgconfig \
"



fixed this linker issue.






--
# Randy MacLeod
# Wind River Linux


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

Re: [OE-core] [PATCH] uninative-tarball: Add libgcc

[Richard Purdie]

On Mon, 2023-01-16 at 19:21 +, Jose Quaresma wrote:
> Hi Richard,
> 
> I am seeing some build errors like this at the end of the build whre bibake 
> segment fault.
> My problem is this happens on a build that doesn't use uninative,
> does bitbake require uninative to build on master?

No, it doesn't.

My worry was that uninative didn't contain libgcc which meant that
builds could fail like this if it wasn't present. The reason for the
change is threading in bitbake itself and the thread.join() calls which
seem to trigger pthread_cancel() calls under some circumstances. Having
libgcc present in uninative seemed like a good idea so I've ensured
that. I wasn't entirely convinced it would solve it, I half expected to
see a new/different error replacing it.

Is libgcc present on your build system? It would seem strange for it
not to be but that is what the error message suggests.

I've also seem mention of issues with this in some versions of python
but I've not seen any errors on the autobuilder since I ensured it was
present in uninative.

> This is my build log where bitbake crash at the end:
> 
> INFO: Build completion summary:
> INFO:   do_populate_sysroot: 100.0% sstate reuse(387 setscene, 0 scratch)
> INFO:   do_deploy_source_date_epoch: 100.0% sstate reuse(5 setscene, 0 
> scratch)
> INFO:   do_deploy_archives: 100.0% sstate reuse(400 setscene, 0 scratch)
> INFO:   do_create_spdx: 100.0% sstate reuse(364 setscene, 0 scratch)
> INFO:   do_create_runtime_spdx: 100.0% sstate reuse(342 setscene, 0 scratch)
> INFO:   do_package_qa: 100.0% sstate reuse(243 setscene, 0 scratch)
> INFO:   do_package: 100.0% sstate reuse(26 setscene, 0 scratch)
> INFO:   do_packagedata: 100.0% sstate reuse(243 setscene, 0 scratch)
> INFO:   do_package_write_ipk: 100.0% sstate reuse(243 setscene, 0 scratch)
> INFO:   do_populate_lic: 100.0% sstate reuse(395 setscene, 0 scratch)
> INFO: Writing buildhistory
> INFO: Writing buildhistory took: 10 seconds
> libgcc_s.so.1 must be installed for pthread_cancel to work
> /lmp/bb-build.sh: line 24: 91770 Aborted                 (core dumped) 
> bitbake -D ...

This is the build system's python saying it can't find libgcc_s.so.1 so
I'd start by checking it is there. I'm assuming you're not using
buildtools?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176015): 
https://lists.openembedded.org/g/openembedded-core/message/176015
Mute This Topic: https://lists.openembedded.org/mt/96152280/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/6] glib-2.0: Switch to using C11 std

[Khem Raj]

upstream glib-2,0 has not accepted these patches so lets hold on to
them for now.

On Sun, Jan 15, 2023 at 10:51 AM Khem Raj  wrote:
>
> Signed-off-by: Khem Raj 
> ---
>  ...0001-Switch-from-C99-to-C11-standard.patch | 40 +
>  ...efine-check_alignof-for-std-c11-and-.patch | 44 +++
>  meta/recipes-core/glib-2.0/glib-2.0_2.74.4.bb |  2 +
>  3 files changed, 86 insertions(+)
>  create mode 100644 
> meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-C99-to-C11-standard.patch
>  create mode 100644 
> meta/recipes-core/glib-2.0/glib-2.0/0001-tests-macros.c-Define-check_alignof-for-std-c11-and-.patch
>
> diff --git 
> a/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-C99-to-C11-standard.patch
>  
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-C99-to-C11-standard.patch
> new file mode 100644
> index 00..4ddf49a9df
> --- /dev/null
> +++ 
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-Switch-from-C99-to-C11-standard.patch
> @@ -0,0 +1,40 @@
> +From 59f4bdaedccb14802810e2f28646cc039a92f3d3 Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 14 Jan 2023 12:15:29 -0800
> +Subject: [PATCH] Switch from C99 to C11 standard
> +
> +We need to start using _Alignof consistently as the fallback
> +implementation which uses types within offsetof is UB as per WG14 N2350
> +[1], moreover newer compilers like clang 16+ have started to error on
> +such use.
> +
> +Fixes errors like below with clang 16+
> +
> +| ../glib-2.74.4/glib/ghash.c:299:18: error: 'struct (unnamed at 
> ../glib-2.74.4/glib/ghash.c:299:1)' cannot be defined in '__builtin_offsetof'
> +| G_STATIC_ASSERT (G_ALIGNOF (GHashTableIter) >= G_ALIGNOF (RealIter));
> +
> +[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
> +[2] https://reviews.llvm.org/D133574
> +
> +Upstream-Status: Submitted 
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3202]
> +Signed-off-by: Khem Raj 
> +---
> + meson.build | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/meson.build b/meson.build
> +index 8d3500ad7..87662fa47 100644
> +--- a/meson.build
>  b/meson.build
> +@@ -5,7 +5,7 @@ project('glib', 'c',
> +   default_options : [
> + 'buildtype=debugoptimized',
> + 'warning_level=3',
> +-'c_std=gnu99'
> ++'c_std=gnu11'
> +   ]
> + )
> +
> +--
> +2.39.0
> +
> diff --git 
> a/meta/recipes-core/glib-2.0/glib-2.0/0001-tests-macros.c-Define-check_alignof-for-std-c11-and-.patch
>  
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-tests-macros.c-Define-check_alignof-for-std-c11-and-.patch
> new file mode 100644
> index 00..c6f2ee1948
> --- /dev/null
> +++ 
> b/meta/recipes-core/glib-2.0/glib-2.0/0001-tests-macros.c-Define-check_alignof-for-std-c11-and-.patch
> @@ -0,0 +1,44 @@
> +From 3a86bfadd67983267e5d89b1a7e3a637041e599b Mon Sep 17 00:00:00 2001
> +From: Khem Raj 
> +Date: Sat, 14 Jan 2023 10:54:28 -0800
> +Subject: [PATCH] tests/macros.c: Define check_alignof for std=c11 and newer
> +
> +WG14 N2350 made very clear that it is an UB having type definitions
> +within "offsetof" [1]. This patch changes the implementation of macro
> +check_alignof to builtin "_Alignof" to avoid undefined behavior.
> +
> +clang 16+ has started to diagnose this [2]
> +
> +Fixes build when using -std >= gnu11 and using clang16+
> +
> +[1] https://www.open-std.org/jtc1/sc22/wg14/www/docs/n2350.htm
> +[2] https://reviews.llvm.org/D133574
> +
> +Upstream-Status: Submitted 
> [https://gitlab.gnome.org/GNOME/glib/-/merge_requests/3201]
> +Signed-off-by: Khem Raj 
> +---
> + glib/tests/macros.c | 6 +-
> + 1 file changed, 5 insertions(+), 1 deletion(-)
> +
> +diff --git a/glib/tests/macros.c b/glib/tests/macros.c
> +index efe632b..17b1646 100644
> +--- a/glib/tests/macros.c
>  b/glib/tests/macros.c
> +@@ -42,9 +42,13 @@ test_assert_static (void)
> + static void
> + test_alignof_fallback (void)
> + {
> ++#if defined(__STDC_VERSION__) && __STDC_VERSION__ >= 201112L && 
> !defined(__cplusplus)
> ++#define check_alignof(type) \
> ++  g_assert_cmpint (G_ALIGNOF (type), ==, _Alignof (type))
> ++#else
> + #define check_alignof(type) \
> +   g_assert_cmpint (G_ALIGNOF (type), ==, G_STRUCT_OFFSET (struct { char a; 
> type b; }, b))
> +-
> ++#endif
> +   check_alignof (char);
> +   check_alignof (int);
> +   check_alignof (float);
> +--
> +2.39.0
> +
> diff --git a/meta/recipes-core/glib-2.0/glib-2.0_2.74.4.bb 
> b/meta/recipes-core/glib-2.0/glib-2.0_2.74.4.bb
> index e5279e946c..de3f55e865 100644
> --- a/meta/recipes-core/glib-2.0/glib-2.0_2.74.4.bb
> +++ b/meta/recipes-core/glib-2.0/glib-2.0_2.74.4.bb
> @@ -19,6 +19,8 @@ SRC_URI = 
> "${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \
> file://cpp-null.patch \
> file://cpp-null2.patch \
> file://fix-errno.patch \
> +   
> file://0001-tests-macros.c-Define-check_alignof-for-std-c11-and-.patch \
> +   file://0001-Switch-from-C99-to-C11-standard.patch \
> "
>  

Re: [OE-core] [PATCH] uninative-tarball: Add libgcc

[Jose Quaresma]

Hi Richard,

I am seeing some build errors like this at the end of the build whre bibake
segment fault.
My problem is this happens on a build that doesn't use uninative,
does bitbake require uninative to build on master?

This is my build log where bitbake crash at the end:

INFO: Build completion summary:
INFO:   do_populate_sysroot: 100.0% sstate reuse(387 setscene, 0 scratch)
INFO:   do_deploy_source_date_epoch: 100.0% sstate reuse(5 setscene, 0
scratch)
INFO:   do_deploy_archives: 100.0% sstate reuse(400 setscene, 0 scratch)
INFO:   do_create_spdx: 100.0% sstate reuse(364 setscene, 0 scratch)
INFO:   do_create_runtime_spdx: 100.0% sstate reuse(342 setscene, 0 scratch)
INFO:   do_package_qa: 100.0% sstate reuse(243 setscene, 0 scratch)
INFO:   do_package: 100.0% sstate reuse(26 setscene, 0 scratch)
INFO:   do_packagedata: 100.0% sstate reuse(243 setscene, 0 scratch)
INFO:   do_package_write_ipk: 100.0% sstate reuse(243 setscene, 0 scratch)
INFO:   do_populate_lic: 100.0% sstate reuse(395 setscene, 0 scratch)
INFO: Writing buildhistory
INFO: Writing buildhistory took: 10 seconds
libgcc_s.so.1 must be installed for pthread_cancel to work
/lmp/bb-build.sh: line 24: 91770 Aborted (core dumped)
bitbake -D ...

Jose


Richard Purdie  escreveu no dia
segunda, 9/01/2023 à(s) 13:49:

> We ship libpthread with uninative. when uninative is active we're seeing
> failures like:
>
>libgcc_s.so.1 must be installed for pthread_cancel to work
>Aborted
>
> which is since we don't have a libgcc that matches libpthread. Add libgcc
> to avoid these errors.
>
> Signed-off-by: Richard Purdie 
> ---
>  meta/recipes-core/meta/uninative-tarball.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/meta/uninative-tarball.bb
> b/meta/recipes-core/meta/uninative-tarball.bb
> index a21d08b591c..4aecf39b890 100644
> --- a/meta/recipes-core/meta/uninative-tarball.bb
> +++ b/meta/recipes-core/meta/uninative-tarball.bb
> @@ -20,6 +20,7 @@ TOOLCHAIN_HOST_TASK = "\
>  nativesdk-libxcrypt-compat \
>  nativesdk-libnss-nis \
>  nativesdk-sdk-provides-dummy \
> +nativesdk-libgcc \
>  "
>
>  INHIBIT_DEFAULT_DEPS = "1"
> --
> 2.37.2
>
>
> 
>
>

-- 
Best regards,

José Quaresma

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

Re: [OE-core] [kirkstone][PATCH 1/1] gcc: Refactor linker patches and fix linker on arm with usrmerge

[Khem Raj]

On Mon, Jan 16, 2023 at 7:32 AM Khem Raj  wrote:
>
>
>
> On Sun, Jan 15, 2023 at 11:56 PM Pavel Zhukov  wrote:
>>
>> Backport fix from master to allow gcc to use proper linker path for
>> musl [Yocto #14977].
>
>
> Lgtm

Of the two, I think this seems to be closer to master and perhaps
easier to maintain in long run. So lets use this one.

>
>>
>>
>> Fixes:
>> | qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or 
>> directory
>>
>> Signed-off-by: Pavel Zhukov 
>> ---
>>  meta/recipes-devtools/gcc/gcc-11.3.inc|   1 -
>>  ...rm-add-armv9-a-architecture-to-march.patch |  89 +++---
>>  ...AMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch | 269 +-
>>  ...s-fix-v4bx-to-linker-to-support-EABI.patch |  10 +-
>>  ...019-nios2-Define-MUSL_DYNAMIC_LINKER.patch |  25 --
>>  5 files changed, 245 insertions(+), 149 deletions(-)
>>  delete mode 100644 
>> meta/recipes-devtools/gcc/gcc/0019-nios2-Define-MUSL_DYNAMIC_LINKER.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc 
>> b/meta/recipes-devtools/gcc/gcc-11.3.inc
>> index 27074a06ae..ab2ece3cce 100644
>> --- a/meta/recipes-devtools/gcc/gcc-11.3.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc
>> @@ -48,7 +48,6 @@ SRC_URI = "\
>> 
>> file://0016-If-CXXFLAGS-contains-something-unsupported-by-the-bu.patch \
>> file://0017-handle-sysroot-support-for-nativesdk-gcc.patch \
>> 
>> file://0018-Search-target-sysroot-gcc-version-specific-dirs-with.patch \
>> -   file://0019-nios2-Define-MUSL_DYNAMIC_LINKER.patch \
>> 
>> file://0020-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch \
>> 
>> file://0021-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \
>> file://0022-sync-gcc-stddef.h-with-musl.patch \
>> diff --git 
>> a/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
>>  
>> b/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
>> index c38d1b9119..864c8b3017 100644
>> --- 
>> a/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
>> +++ 
>> b/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
>> @@ -43,10 +43,10 @@ Signed-off-by: Ruiqiang Hao 
>>   gcc/testsuite/lib/target-supports.exp |  3 ++-
>>   9 files changed, 79 insertions(+), 8 deletions(-)
>>
>> -diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
>> -index bcc9ebe9f..58d83829c 100644
>>  a/gcc/config/arm/arm-cpus.in
>> -+++ b/gcc/config/arm/arm-cpus.in
>> +Index: gcc-11.3.0/gcc/config/arm/arm-cpus.in
>> +===
>> +--- gcc-11.3.0.orig/gcc/config/arm/arm-cpus.in
>>  gcc-11.3.0/gcc/config/arm/arm-cpus.in
>>  @@ -132,6 +132,9 @@ define feature cmse
>>   # Architecture rel 8.1-M.
>>   define feature armv8_1m_main
>> @@ -57,7 +57,7 @@ index bcc9ebe9f..58d83829c 100644
>>   # Floating point and Neon extensions.
>>   # VFPv1 is not supported in GCC.
>>
>> -@@ -293,6 +296,7 @@ define fgroup ARMv8m_base ARMv6m armv8 cmse tdiv
>> +@@ -293,6 +296,7 @@ define fgroup ARMv8m_base ARMv6m armv8 c
>>   define fgroup ARMv8m_main ARMv7m armv8 cmse
>>   define fgroup ARMv8r  ARMv8a
>>   define fgroup ARMv8_1m_main ARMv8m_main armv8_1m_main
>> @@ -87,10 +87,10 @@ index bcc9ebe9f..58d83829c 100644
>>   begin arch iwmmxt
>>tune for iwmmxt
>>tune flags LDSCHED STRONG XSCALE
>> -diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
>> -index 5692d4fb7..ae3dd9414 100644
>>  a/gcc/config/arm/arm-tables.opt
>> -+++ b/gcc/config/arm/arm-tables.opt
>> +Index: gcc-11.3.0/gcc/config/arm/arm-tables.opt
>> +===
>> +--- gcc-11.3.0.orig/gcc/config/arm/arm-tables.opt
>>  gcc-11.3.0/gcc/config/arm/arm-tables.opt
>>  @@ -380,10 +380,13 @@ EnumValue
>>   Enum(arm_arch) String(armv8.1-m.main) Value(30)
>>
>> @@ -107,10 +107,10 @@ index 5692d4fb7..ae3dd9414 100644
>>
>>   Enum
>>   Name(arm_fpu) Type(enum fpu_type)
>> -diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
>> -index 47c13a9e5..088c7725c 100644
>>  a/gcc/config/arm/arm.h
>> -+++ b/gcc/config/arm/arm.h
>> +Index: gcc-11.3.0/gcc/config/arm/arm.h
>> +===
>> +--- gcc-11.3.0.orig/gcc/config/arm/arm.h
>>  gcc-11.3.0/gcc/config/arm/arm.h
>>  @@ -456,7 +456,8 @@ enum base_architecture
>> BASE_ARCH_8A = 8,
>> BASE_ARCH_8M_BASE = 8,
>> @@ -121,10 +121,10 @@ index 47c13a9e5..088c7725c 100644
>>   };
>>
>>   /* The major revision number of the ARM Architecture implemented by the 
>> target.  */
>> -diff --git a/gcc/config/arm/t-aprofile b/gcc/config/arm/t-aprofile
>> -index 8574ac3e2..68e2251c7 100644
>>  a/gcc/config/arm/t-aprofile
>> -+++ b/gcc/config/arm/t-aprofile
>> +Index: gcc-11.3.0/gcc/config/arm/t-aprofile
>> 

Re: [oe-core][PATCH] neard: dont pull in wpa-supplicant unconditionally

[Richard Purdie]

On Mon, 2023-01-16 at 18:20 +0100, Markus Volk wrote:
> Yes, that's right, of course. What would be the preferred way to deal
> with this. The dependency on wpa-supplicant is a bit annoying. Should
> I use a bbappend to remove it, or is the RRECOMMEND on wpa-supplicant
> perhaps removable from the neard recipe?

It might be time to add something to meta/conf/distro/includes/default-
providers.inc along the lines of:

VIRTUAL-RUNTIME_wireless-daemon ?= "wpa-supplicant"

I don't like these but probably need something more central/standard...

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176011): 
https://lists.openembedded.org/g/openembedded-core/message/176011
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] neard: dont pull in wpa-supplicant unconditionally

[Jose Quaresma]

Hi Markus,

Markus Volk  escreveu no dia segunda, 16/01/2023 à(s)
17:20:

> Yes, that's right, of course. What would be the preferred way to deal with
> this. The dependency on wpa-supplicant is a bit annoying. Should I use a
> bbappend to remove it, or is the RRECOMMEND on wpa-supplicant perhaps
> removable from the neard recipe?
>

I think we can set on the recipe the default value of the WIRELESS_DAEMON
like on the patch you pointed out
so that globally changing WIRELESS_DAEMON will take effect everywhere where
it is used.

 WIRELESS_DAEMON ??= "wpa-supplicant"

Jose


> Am Mo, 16. Jan 2023 um 17:03:09 + schrieb Richard Purdie <
> richard.pur...@linuxfoundation.org>:
>
> On Mon, 2023-01-16 at 17:49 +0100, Markus Volk wrote:
>
> > That isn't going to work as there is no default value for >
> WIRELESS_DAEMON ? > We have it set here
> https://git.yoctoproject.org/poky/commit/?id=1eaf64fbe16d2ceb472623c65c961b36aee33608
>
> Sure, but the neard recipe can't see in the packagegroup-base recipe
> scope? Cheers, Richard
>
>
> 
>
>

-- 
Best regards,

José Quaresma

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176010): 
https://lists.openembedded.org/g/openembedded-core/message/176010
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] neard: dont pull in wpa-supplicant unconditionally

[Markus Volk]

Yes, that's right, of course. What would be the preferred way to deal 
with this. The dependency on wpa-supplicant is a bit annoying. Should I 
use a bbappend to remove it, or is the RRECOMMEND on wpa-supplicant 
perhaps removable from the neard recipe?


Am Mo, 16. Jan 2023 um 17:03:09 + schrieb Richard Purdie 
:

On Mon, 2023-01-16 at 17:49 +0100, Markus Volk wrote:


 > That isn't going to work as there is no default value for
 > WIRELESS_DAEMON ?
 >

 We have it set here

 





Sure, but the neard recipe can't see in the packagegroup-base recipe
scope?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176009): 
https://lists.openembedded.org/g/openembedded-core/message/176009
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] neard: dont pull in wpa-supplicant unconditionally

[Richard Purdie]

On Mon, 2023-01-16 at 17:49 +0100, Markus Volk wrote:

> > That isn't going to work as there is no default value for
> > WIRELESS_DAEMON ?
> > 
>
> We have it set here
> 
> https://git.yoctoproject.org/poky/commit/?id=1eaf64fbe16d2ceb472623c65c961b36aee33608
> 

Sure, but the neard recipe can't see in the packagegroup-base recipe
scope?

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176008): 
https://lists.openembedded.org/g/openembedded-core/message/176008
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] Make oe-setup-layers efficiently idempotent

[Richard Purdie]

On Sat, 2023-01-14 at 16:53 -0800, Chuck Wolber wrote:
> The effect of subsequent setup-layers executions is now either a NOOP
> or the minimal set of changes required to ensure layers precisely match
> the JSON configuration.
> 
> This change allows setup-layers to be incorporated into a team's
> configuration management strategy. In particular, the configuration
> JSON manages a "pinning policy" that documents the oversight of sources
> of change (a requirement for embedded development in highly regulated
> industries).
> 
> One model for this strategy would work as follows. Team level policy is
> developed to regularly review upstream commits that occur between the
> current upstream HEAD and the previously pinned revision. The JSON
> configuration is periodically updated after a review, test, and approval
> process. In the rare instance that an upstream change is considered
> problematic, the bbappend mechanism can be used to make relevant
> changes in the team's project repository. This approach also requires
> that team developers regularly run the project repository copy of
> setup-layers. This is most easily accomplished by including setup-layers
> in a wrapper script that all team developers use to interact with the
> bitbake tool suite (e.g. "bb bitbake foo-image"). Project level policy
> and oversight is effectively "contained" within this wrapper script,
> thereby reducing a significant source of human error.
> 
> It is also worth noting that, where project level policy cannot be
> asserted on layers with the bbappend mechanism (e.g. bbclass files), a
> patch set can be checked in to the project repository and automatically
> managed by the wrapper script. Patch management against local layer
> clones would be superficial in nature (not pushed upstream). This
> enables projects to "pull in" functionality and manage bug fixes on an
> as-needed basis.
> 
> Left unstated, but acknowledged here, are a number of nuances required
> to successfully implement this strategy e.g. setup-layers does not work
> so well if your layer clone is dirty from locally applied patches, etc.
> The details are out of scope for this explanation. What should be
> clear is that a larger configuration management strategy can now benefit
> from the utility provided by setup-layers.
> 
> Note: Neither the above configuration management strategy example nor
> the change itself is intended to alter the original intent to use
> "bitbake-layers create-layers-setup destdir" to keep pace with upstream
> activity for those who wish to use it that way.
> 
> Signed-off-by: Chuck Wolber 
> ---
>  scripts/oe-setup-layers | 55 
> +
>  1 file changed, 46 insertions(+), 9 deletions(-)

Thanks for the patch!

Making the script rerun successfully seems sensible so the change
itself is reasonable. I was a little confused by some of the comments
in the commit message as oe-setup-layers doesn't apply patches as far
as I know. Is that something you're thinking of adding?

One small cosmetic issue is that the area of code the patch changes
should be as a prefix in the shortlog, e.g. "scripts/oe-setup-layers:"
in this case. It means people can understand the rough scope of the
patch from a glance.

Whilst not essential, I do like Alex's suggestion about improving the
tests too, not sure if that is possible.

I also noticed the patch is against master-next, which usually would be
fine except I did drop a patch there which means this one no longer
applies. If you could rebase it for the v2 with the shortlog fix that
would be much appreciated.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176007): 
https://lists.openembedded.org/g/openembedded-core/message/176007
Mute This Topic: https://lists.openembedded.org/mt/96278464/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] kernel_dep_check.bbclass: help track kernel depend

[Richard Purdie]

On Wed, 2022-12-28 at 13:47 -0800, John Broadbent via
lists.openembedded.org wrote:
> From: John Edward Broadbent 
> 
> This recipe can be used to identify kernel dependencies, and
> immediately throw build errors if those dependencies are not met.
> 
> Signed-off-by: John Edward Broadbent 
> ---
>  meta/classes-recipe/kernel_dep_check.bbclass | 81 
>  1 file changed, 81 insertions(+)
>  create mode 100644 meta/classes-recipe/kernel_dep_check.bbclass
> 
> diff --git a/meta/classes-recipe/kernel_dep_check.bbclass 
> b/meta/classes-recipe/kernel_dep_check.bbclass
> new file mode 100644
> index 00..25bef1533c
> --- /dev/null
> +++ b/meta/classes-recipe/kernel_dep_check.bbclass
> @@ -0,0 +1,81 @@
> +# This class is meant to help in tracking recipe's dependencies
> +# on certain Linux Kernel's compile time options, by making them
> +# explicit.
> +#
> +# Usage.
> +# 1. Inherit this class.
> +# 2. If the Linux Kernel MUST have certain compile time options
> +#   enabled, add them to KERNEL_OPTIONS_REQUIRED variable.
> +#   Multiple options can be added, separated by whitespace.
> +#   If the kernel built with the image does not have these
> +#   options enabled, the build will fail.
> +# 3. If some options are simply recommended, but not mandatory,
> +#   they can be added to KERNEL_OPTIONS_RECOMMENDED variable.
> +#   If the kernel built with the image does not have these
> +#   options enabled, warning will be produced, but the build
> +#   will succeed.
> +# 4. If some options has alternatives, i.e. if only one of the
> +#   options has to be enabled to pass the check, separate
> +#   the alternatives with '|' with no spaces, like so:
> +#   DECOMPRESS_GZIP|DECOMPRESS_BZIP2
> +
> +
> +KERNEL_OPTIONS_REQUIRED ??= ""
> +KERNEL_OPTIONS_RECOMMENDED ??= ""
> +
> +def report_opt_warn(pn, opt):
> +if len(opt_alt_list) > 1:
> +bb.warn("%s recommends one of the following Linux Kernel"
> +" options to be enabled: %s"
> +% (pn, ",".join(opt_alt_list)))
> +else:
> +bb.warn("%s recommends Linux Kernel option %s to be enabled"
> +% (pn, opt_alt_list[0]))
> +
> +
> +def report_opt_fatal(pn, opt_alt_list):
> +if len(opt_alt_list) > 1:
> +bb.fatal("%s requires one of the following Linux Kernel"
> +" options to be enabled: %s"
> +% (pn, ",".join(opt_alt_list)))
> +else:
> +bb.fatal("%s requires Linux Kernel option %s to be enabled"
> +% (pn, opt_alt_list[0]))
> +
> +
> +def check_kernel_option(pn, opt_expr, opt_map, report_f):
> +alt_list = opt_expr.split("|")
> +alt_list_full = []
> +for opt in alt_list:
> +if not opt.startswith("CONFIG_"):
> +alt_list_full.append("CONFIG_" + opt)
> +else:
> +alt_list_full.append(opt)
> +
> +if not any(opt_map.get(o) == "y" for o in alt_list_full):
> +report_f(pn, alt_list_full)
> +
> +
> +python do_package:qa:append () {
> +kconfig_path = os.path.join(d.getVar("STAGING_KERNEL_BUILDDIR"), 
> ".config")
> +
> +kconfig_map = dict()
> +with open(kconfig_path, "r") as kconfig:
> +for line in kconfig:
> +if not line.startswith("CONFIG"):
> +continue
> +
> +cfg_chunks = line.strip().split("=")
> +kconfig_map[cfg_chunks[0]] = cfg_chunks[1]
> +
> +pn = d.getVar("PN")
> +for opt in d.getVar("KERNEL_OPTIONS_REQUIRED", "").split():
> +check_kernel_option(pn, opt, kconfig_map, report_opt_fatal)
> +
> +for opt in d.getVar("KERNEL_OPTIONS_RECOMMENDED", "").split():
> +check_kernel_option(pn, opt, kconfig_map, report_opt_warn)
> +}
> +
> +# do_shared_workdir moves kernel's .config to STAGING_KERNEL_BUILDDIR,
> +# so it must complete before we can run the qa checks above.
> +do_package:qa[depends] = "virtual/kernel:do_shared_workdir"

Thanks for updating the patch. I am a little curious on the
background/context for this code, not sure if there are any details you
can share?

I did talk with our kernel developers about this and there is a worry
that in doing this, we'd start duplicating functionality that we
already have in the kernel tools and kernel cache work that linux-yocto
supports. Did you look at the support there and is that something you
could use instead?

Worst case this can be used within your own layers, in core we'd
probably want to try and standardise around on set of kernel tooling.

Cheers,

Richard





-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176006): 
https://lists.openembedded.org/g/openembedded-core/message/176006
Mute This Topic: https://lists.openembedded.org/mt/95927985/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] neard: dont pull in wpa-supplicant unconditionally

[Markus Volk]

We have it set here



Am Mo, 16. Jan 2023 um 16:47:16 + schrieb Richard Purdie 
:

On Mon, 2023-01-16 at 17:43 +0100, Markus Volk wrote:
 Signed-off-by: Markus Volk >

 ---
  meta/recipes-connectivity/neard/neard_0.18.bb | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)

 diff --git a/meta/recipes-connectivity/neard/neard_0.18.bb 
b/meta/recipes-connectivity/neard/neard_0.18.bb

 index 23e999acc4..17dbfc4378 100644
 --- a/meta/recipes-connectivity/neard/neard_0.18.bb
 +++ b/meta/recipes-connectivity/neard/neard_0.18.bb
 @@ -42,7 +42,7 @@ RDEPENDS:${PN} = "dbus"
  # Bluez & Wifi are not mandatory except for handover
  RRECOMMENDS:${PN} = "\
   ${@bb.utils.contains 
('DISTRO_FEATURES', 'bluetooth', 
'bluez5', '', d)} \
 - ${@bb.utils.contains 
('DISTRO_FEATURES', 
'wifi','wpa-supplicant', '', d)} \
 + ${@bb.utils.contains 
('DISTRO_FEATURES', 
'wifi','${WIRELESS_DAEMON}', '', d)} \

  "

  INITSCRIPT_NAME = "neard"


That isn't going to work as there is no default value for
WIRELESS_DAEMON ?

Cheers,

Richard







-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176005): 
https://lists.openembedded.org/g/openembedded-core/message/176005
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] neard: dont pull in wpa-supplicant unconditionally

[Richard Purdie]

On Mon, 2023-01-16 at 17:43 +0100, Markus Volk wrote:
> Signed-off-by: Markus Volk 
> ---
>  meta/recipes-connectivity/neard/neard_0.18.bb | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-connectivity/neard/neard_0.18.bb 
> b/meta/recipes-connectivity/neard/neard_0.18.bb
> index 23e999acc4..17dbfc4378 100644
> --- a/meta/recipes-connectivity/neard/neard_0.18.bb
> +++ b/meta/recipes-connectivity/neard/neard_0.18.bb
> @@ -42,7 +42,7 @@ RDEPENDS:${PN} = "dbus"
>  # Bluez & Wifi are not mandatory except for handover
>  RRECOMMENDS:${PN} = "\
>   ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
> 'bluez5', '', d)} \
> - ${@bb.utils.contains('DISTRO_FEATURES', 
> 'wifi','wpa-supplicant', '', d)} \
> + ${@bb.utils.contains('DISTRO_FEATURES', 
> 'wifi','${WIRELESS_DAEMON}', '', d)} \
>  "
>  
>  INITSCRIPT_NAME = "neard"

That isn't going to work as there is no default value for
WIRELESS_DAEMON ?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176004): 
https://lists.openembedded.org/g/openembedded-core/message/176004
Mute This Topic: https://lists.openembedded.org/mt/96310274/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] neard: dont pull in wpa-supplicant unconditionally

[Markus Volk]

Signed-off-by: Markus Volk 
---
 meta/recipes-connectivity/neard/neard_0.18.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/neard/neard_0.18.bb 
b/meta/recipes-connectivity/neard/neard_0.18.bb
index 23e999acc4..17dbfc4378 100644
--- a/meta/recipes-connectivity/neard/neard_0.18.bb
+++ b/meta/recipes-connectivity/neard/neard_0.18.bb
@@ -42,7 +42,7 @@ RDEPENDS:${PN} = "dbus"
 # Bluez & Wifi are not mandatory except for handover
 RRECOMMENDS:${PN} = "\
  ${@bb.utils.contains('DISTRO_FEATURES', 'bluetooth', 
'bluez5', '', d)} \
- ${@bb.utils.contains('DISTRO_FEATURES', 
'wifi','wpa-supplicant', '', d)} \
+ ${@bb.utils.contains('DISTRO_FEATURES', 
'wifi','${WIRELESS_DAEMON}', '', d)} \
 "
 
 INITSCRIPT_NAME = "neard"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176003): 
https://lists.openembedded.org/g/openembedded-core/message/176003
Mute This Topic: https://lists.openembedded.org/mt/96310274/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 6/7] gdk-pixbuf: remove ptest support

[Alexander Kanavin]

On Mon 16. Jan 2023 at 17.10, Ross Burton  wrote:

> On 13 Jan 2023, at 14:56, Alexander Kanavin via lists.openembedded.org
>  wrote:
> >
> > Moving to x86-64-v3 instructions revealed that the recipe was doing an
> entirely
> > incorrect thing: running native gdk-pixbuf-query-loaders executable
> against the target set
> > of loader .so binaries. This worked, but only by coincidence, and no
> longer
> > works on build hosts that do not support v3 instructions.
> >
> > Re-enabling installed tests in a cross compile scenario requires a
> complete
> > re-think (against the need to run gdk-pixbuf executables to produce the
> tests),
> > and is best done upstream, so sadly the cross-testing has to be dropped
> > for now.
>
> So what happened in a proper cross environment where the native tools
> can’t open the target .so?


The tool prints failure to load messages, concludes that no loaders are
available and writes out an empty cache file.

Alex

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

Re: [OE-core] [kirkstone][PATCH] gcc: Fix build with musl and usrmerge on arm

[Steve Sakoman]

On Mon, Jan 16, 2023 at 5:31 AM Khem Raj  wrote:
>
>
>
> On Sun, Jan 15, 2023 at 10:59 PM Pavel Zhukov  wrote:
>>
>> Backport fix from master to allow gcc to use proper linker path for
>> musl [Yocto #14977]
>
>
> Lgtm

Hi Khem,

Which of the two versions of the fix do you prefer that I take?

Thanks!

Steve

>> Fixes:
>> | qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or 
>> directory
>>
>> Signed-off-by: Pavel Zhukov 
>> ---
>>  meta/recipes-devtools/gcc/gcc-11.3.inc |  1 +
>>  .../gcc/0031-fix-musl-arm-with-usrmerge.patch  | 18 ++
>>  2 files changed, 19 insertions(+)
>>  create mode 100644 
>> meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
>>
>> diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc 
>> b/meta/recipes-devtools/gcc/gcc-11.3.inc
>> index 27074a06ae..2adb21ed84 100644
>> --- a/meta/recipes-devtools/gcc/gcc-11.3.inc
>> +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc
>> @@ -60,6 +60,7 @@ SRC_URI = "\
>> 
>> file://0028-debug-101473-apply-debug-prefix-maps-before-checksum.patch \
>> file://0029-Fix-install-path-of-linux64.h.patch \
>> file://0030-rust-recursion-limit.patch \
>> +   file://0031-fix-musl-arm-with-usrmerge.patch \
>> file://0001-CVE-2021-42574.patch \
>> file://0002-CVE-2021-42574.patch \
>> file://0003-CVE-2021-42574.patch \
>> diff --git 
>> a/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch 
>> b/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
>> new file mode 100644
>> index 00..1408b65c64
>> --- /dev/null
>> +++ b/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
>> @@ -0,0 +1,18 @@
>> +Upstream-Status: Inappropriate [bugfix]
>> +
>> +The fix has been picked from OE-core ustream:
>> + 0007-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch
>> +
>> +Index: gcc-11.3.0/gcc/config/arm/linux-eabi.h
>> +===
>> +--- gcc-11.3.0.orig/gcc/config/arm/linux-eabi.h
>>  gcc-11.3.0/gcc/config/arm/linux-eabi.h
>> +@@ -89,7 +89,7 @@
>> + #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
>> + #endif
>> + #define MUSL_DYNAMIC_LINKER \
>> +-  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E 
>> "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
>> ++  SYSTEMLIBS_DIR "ld-musl-arm" MUSL_DYNAMIC_LINKER_E 
>> "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
>> +
>> + /* For armv4 we pass --fix-v4bx to linker to support EABI */
>> + #undef TARGET_FIX_V4BX_SPEC
>> --
>> 2.39.0
>>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176001): 
https://lists.openembedded.org/g/openembedded-core/message/176001
Mute This Topic: https://lists.openembedded.org/mt/96302404/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 6/7] gdk-pixbuf: remove ptest support

[Ross Burton]

On 13 Jan 2023, at 14:56, Alexander Kanavin via lists.openembedded.org 
 wrote:
> 
> Moving to x86-64-v3 instructions revealed that the recipe was doing an 
> entirely
> incorrect thing: running native gdk-pixbuf-query-loaders executable against 
> the target set
> of loader .so binaries. This worked, but only by coincidence, and no longer
> works on build hosts that do not support v3 instructions.
> 
> Re-enabling installed tests in a cross compile scenario requires a complete
> re-think (against the need to run gdk-pixbuf executables to produce the 
> tests),
> and is best done upstream, so sadly the cross-testing has to be dropped
> for now.

So what happened in a proper cross environment where the native tools can’t 
open the target .so?

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#176000): 
https://lists.openembedded.org/g/openembedded-core/message/176000
Mute This Topic: https://lists.openembedded.org/mt/96247134/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] mesa: update submitted patch with backported version

[Martin Jansa]

Kai: can you please test it on ubuntu-18.04?

I've tested it with DEBUG_BUILD in native and target build on a host with
new toolchain (gentoo with gcc-12.2.1) and according to
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439 it works
with old toolchain as well.

On Mon, Jan 16, 2023 at 4:30 PM Martin Jansa via lists.openembedded.org
 wrote:

> * this version was merged to main in:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911
>   and cherry-picked to staging/23.0 as well in:
>
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/54cfb552abc50e8167cdc46d87455a9a414d7c65
>
>   and as a bonus it doesn't break the build with DEBUG_BUILD
>   for newer toolchain, so we can apply it for target build as well, see:
>   https://lists.openembedded.org/g/openembedded-core/message/169002
>   https://lists.openembedded.org/g/openembedded-core/message/170930
>
> Signed-off-by: Martin Jansa 
> ---
>  ...ove-fix-ALWAYS_INLINE-compiler-error.patch | 81 ++-
>  meta/recipes-graphics/mesa/mesa.inc   |  5 +-
>  2 files changed, 26 insertions(+), 60 deletions(-)
>
> diff --git
> a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
> b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
> index 7989843eb4..1cf23492fe 100644
> ---
> a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
> +++
> b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
> @@ -1,67 +1,36 @@
> -From da6e47f1717f34c73de388c56ffaf4861a07fdc5 Mon Sep 17 00:00:00 2001
> -From: t bettler 
> -Date: Sat, 9 Jul 2022 09:28:51 +
> +From 267dd1f4d571ee606141aa66f1665aa152b4e911 Mon Sep 17 00:00:00 2001
> +From: t0b3 
> +Date: Sat, 10 Dec 2022 14:32:53 +0100
>  Subject: [PATCH] nir/nir_opt_move: fix ALWAYS_INLINE compiler error
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
>
> -Backport merge request to fix mesa compile error when debug build
> -enabled.
> -
> -Upstream-Status: Submitted [
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439]
> -
> -Signed-off-by: Kai Kang 
> -
> -MIME-Version: 1.0
> -Content-Type: text/plain; charset=UTF-8
> -Content-Transfer-Encoding: 8bit
> -
> -fix call to ‘always_inline’ ‘src_is_ssa’
> -
> -Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6825
> -Fixes: f1d20ec67c3f186886b97de94f74484650f8fda1 ("nir/nir_opt_move:
> handle non-SSA defs ")
> +Reviewed-by: Iago Toral Quiroga 
> +Reviewed-by: Adam Jackson 
> +Closes: #6825
> +Fixes: f1d20ec6 ("nir/nir_opt_move: handle non-SSA defs ")
> +Part-of:  >
>
> +Upstream-Status: Backport [
> https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911
> ]
>  ---
> - src/compiler/nir/nir_inline_helpers.h | 10 --
> - src/compiler/nir/nir_opt_move.c   |  2 +-
> - 2 files changed, 9 insertions(+), 3 deletions(-)
> + src/compiler/nir/nir_opt_move.c | 4 ++--
> + 1 file changed, 2 insertions(+), 2 deletions(-)
>
> -diff --git a/src/compiler/nir/nir_inline_helpers.h
> b/src/compiler/nir/nir_inline_helpers.h
> -index 125dd8a..ec33f05 100644
>  a/src/compiler/nir/nir_inline_helpers.h
> -+++ b/src/compiler/nir/nir_inline_helpers.h
> -@@ -73,8 +73,8 @@ nir_foreach_dest(nir_instr *instr, nir_foreach_dest_cb
> cb, void *state)
> -return _nir_foreach_dest(instr, cb, state);
> - }
> -
> --static inline bool
> --nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
> -+static ALWAYS_INLINE bool
> -+_nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
> - {
> -switch (instr->type) {
> -case nir_instr_type_alu: {
> -@@ -162,3 +162,9 @@ nir_foreach_src(nir_instr *instr, nir_foreach_src_cb
> cb, void *state)
> -dest_state.cb = cb;
> -return _nir_foreach_dest(instr, _nir_visit_dest_indirect,
> _state);
> - }
> -+
> -+static inline bool
> -+nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
> -+{
> -+   return _nir_foreach_src(instr, cb, state);
> -+}
>  diff --git a/src/compiler/nir/nir_opt_move.c
> b/src/compiler/nir/nir_opt_move.c
> -index 81bcde5..051c3cc 100644
> +index 81bcde5c436..9aeb9f4cf86 100644
>  --- a/src/compiler/nir/nir_opt_move.c
>  +++ b/src/compiler/nir/nir_opt_move.c
> -@@ -60,7 +60,7 @@ src_is_ssa(nir_src *src, void *state)
> - static ALWAYS_INLINE bool
> - instr_reads_register(nir_instr *instr)
> +@@ -51,13 +51,13 @@
> +  * lower register pressure.
> +  */
> +
> +-static ALWAYS_INLINE bool
> ++static inline bool
> + src_is_ssa(nir_src *src, void *state)
>   {
> --   return !nir_foreach_src(instr, src_is_ssa, NULL);
> -+   return !_nir_foreach_src(instr, src_is_ssa, NULL);
> +return src->is_ssa;
>   }
>
> - static bool
> +-static ALWAYS_INLINE bool
> ++static inline bool
> + 

Re: [OE-core] [kirkstone][PATCH 1/1] gcc: Refactor linker patches and fix linker on arm with usrmerge

[Khem Raj]

On Sun, Jan 15, 2023 at 11:56 PM Pavel Zhukov  wrote:

> Backport fix from master to allow gcc to use proper linker path for
> musl [Yocto #14977].


Lgtm


>
> Fixes:
> | qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or
> directory
>
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/recipes-devtools/gcc/gcc-11.3.inc|   1 -
>  ...rm-add-armv9-a-architecture-to-march.patch |  89 +++---
>  ...AMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch | 269 +-
>  ...s-fix-v4bx-to-linker-to-support-EABI.patch |  10 +-
>  ...019-nios2-Define-MUSL_DYNAMIC_LINKER.patch |  25 --
>  5 files changed, 245 insertions(+), 149 deletions(-)
>  delete mode 100644
> meta/recipes-devtools/gcc/gcc/0019-nios2-Define-MUSL_DYNAMIC_LINKER.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc
> b/meta/recipes-devtools/gcc/gcc-11.3.inc
> index 27074a06ae..ab2ece3cce 100644
> --- a/meta/recipes-devtools/gcc/gcc-11.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc
> @@ -48,7 +48,6 @@ SRC_URI = "\
>
> file://0016-If-CXXFLAGS-contains-something-unsupported-by-the-bu.patch \
> file://0017-handle-sysroot-support-for-nativesdk-gcc.patch \
>
> file://0018-Search-target-sysroot-gcc-version-specific-dirs-with.patch \
> -   file://0019-nios2-Define-MUSL_DYNAMIC_LINKER.patch \
>
> file://0020-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch \
>
> file://0021-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \
> file://0022-sync-gcc-stddef.h-with-musl.patch \
> diff --git
> a/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
> b/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
> index c38d1b9119..864c8b3017 100644
> ---
> a/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
> +++
> b/meta/recipes-devtools/gcc/gcc/0004-arm-add-armv9-a-architecture-to-march.patch
> @@ -43,10 +43,10 @@ Signed-off-by: Ruiqiang Hao <
> ruiqiang@windriver.com>
>   gcc/testsuite/lib/target-supports.exp |  3 ++-
>   9 files changed, 79 insertions(+), 8 deletions(-)
>
> -diff --git a/gcc/config/arm/arm-cpus.in b/gcc/config/arm/arm-cpus.in
> -index bcc9ebe9f..58d83829c 100644
>  a/gcc/config/arm/arm-cpus.in
> -+++ b/gcc/config/arm/arm-cpus.in
> +Index: gcc-11.3.0/gcc/config/arm/arm-cpus.in
> +===
> +--- gcc-11.3.0.orig/gcc/config/arm/arm-cpus.in
>  gcc-11.3.0/gcc/config/arm/arm-cpus.in
>  @@ -132,6 +132,9 @@ define feature cmse
>   # Architecture rel 8.1-M.
>   define feature armv8_1m_main
> @@ -57,7 +57,7 @@ index bcc9ebe9f..58d83829c 100644
>   # Floating point and Neon extensions.
>   # VFPv1 is not supported in GCC.
>
> -@@ -293,6 +296,7 @@ define fgroup ARMv8m_base ARMv6m armv8 cmse tdiv
> +@@ -293,6 +296,7 @@ define fgroup ARMv8m_base ARMv6m armv8 c
>   define fgroup ARMv8m_main ARMv7m armv8 cmse
>   define fgroup ARMv8r  ARMv8a
>   define fgroup ARMv8_1m_main ARMv8m_main armv8_1m_main
> @@ -87,10 +87,10 @@ index bcc9ebe9f..58d83829c 100644
>   begin arch iwmmxt
>tune for iwmmxt
>tune flags LDSCHED STRONG XSCALE
> -diff --git a/gcc/config/arm/arm-tables.opt b/gcc/config/arm/arm-tables.opt
> -index 5692d4fb7..ae3dd9414 100644
>  a/gcc/config/arm/arm-tables.opt
> -+++ b/gcc/config/arm/arm-tables.opt
> +Index: gcc-11.3.0/gcc/config/arm/arm-tables.opt
> +===
> +--- gcc-11.3.0.orig/gcc/config/arm/arm-tables.opt
>  gcc-11.3.0/gcc/config/arm/arm-tables.opt
>  @@ -380,10 +380,13 @@ EnumValue
>   Enum(arm_arch) String(armv8.1-m.main) Value(30)
>
> @@ -107,10 +107,10 @@ index 5692d4fb7..ae3dd9414 100644
>
>   Enum
>   Name(arm_fpu) Type(enum fpu_type)
> -diff --git a/gcc/config/arm/arm.h b/gcc/config/arm/arm.h
> -index 47c13a9e5..088c7725c 100644
>  a/gcc/config/arm/arm.h
> -+++ b/gcc/config/arm/arm.h
> +Index: gcc-11.3.0/gcc/config/arm/arm.h
> +===
> +--- gcc-11.3.0.orig/gcc/config/arm/arm.h
>  gcc-11.3.0/gcc/config/arm/arm.h
>  @@ -456,7 +456,8 @@ enum base_architecture
> BASE_ARCH_8A = 8,
> BASE_ARCH_8M_BASE = 8,
> @@ -121,10 +121,10 @@ index 47c13a9e5..088c7725c 100644
>   };
>
>   /* The major revision number of the ARM Architecture implemented by the
> target.  */
> -diff --git a/gcc/config/arm/t-aprofile b/gcc/config/arm/t-aprofile
> -index 8574ac3e2..68e2251c7 100644
>  a/gcc/config/arm/t-aprofile
> -+++ b/gcc/config/arm/t-aprofile
> +Index: gcc-11.3.0/gcc/config/arm/t-aprofile
> +===
> +--- gcc-11.3.0.orig/gcc/config/arm/t-aprofile
>  gcc-11.3.0/gcc/config/arm/t-aprofile
>  @@ -26,8 +26,8 @@
>
>   # Arch and FPU variants to build libraries with
> @@ -136,7 +136,7 @@ index 8574ac3e2..68e2251c7 100644
>
>   # ARMv7-A - build nofp, fp-d16 and SIMD variants
>
> -@@ -46,6 +46,11 @@ 

Re: [OE-core] [kirkstone][PATCH] gcc: Fix build with musl and usrmerge on arm

[Khem Raj]

On Sun, Jan 15, 2023 at 10:59 PM Pavel Zhukov  wrote:

> Backport fix from master to allow gcc to use proper linker path for
> musl [Yocto #14977]


Lgtm

>
>
> Fixes:
> | qemu-arm: Could not open '/lib/ld-musl-armhf.so.1': No such file or
> directory
>
> Signed-off-by: Pavel Zhukov 
> ---
>  meta/recipes-devtools/gcc/gcc-11.3.inc |  1 +
>  .../gcc/0031-fix-musl-arm-with-usrmerge.patch  | 18 ++
>  2 files changed, 19 insertions(+)
>  create mode 100644
> meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-11.3.inc
> b/meta/recipes-devtools/gcc/gcc-11.3.inc
> index 27074a06ae..2adb21ed84 100644
> --- a/meta/recipes-devtools/gcc/gcc-11.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-11.3.inc
> @@ -60,6 +60,7 @@ SRC_URI = "\
>
> file://0028-debug-101473-apply-debug-prefix-maps-before-checksum.patch \
> file://0029-Fix-install-path-of-linux64.h.patch \
> file://0030-rust-recursion-limit.patch \
> +   file://0031-fix-musl-arm-with-usrmerge.patch \
> file://0001-CVE-2021-42574.patch \
> file://0002-CVE-2021-42574.patch \
> file://0003-CVE-2021-42574.patch \
> diff --git
> a/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
> b/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
> new file mode 100644
> index 00..1408b65c64
> --- /dev/null
> +++ b/meta/recipes-devtools/gcc/gcc/0031-fix-musl-arm-with-usrmerge.patch
> @@ -0,0 +1,18 @@
> +Upstream-Status: Inappropriate [bugfix]
> +
> +The fix has been picked from OE-core ustream:
> + 0007-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch
> +
> +Index: gcc-11.3.0/gcc/config/arm/linux-eabi.h
> +===
> +--- gcc-11.3.0.orig/gcc/config/arm/linux-eabi.h
>  gcc-11.3.0/gcc/config/arm/linux-eabi.h
> +@@ -89,7 +89,7 @@
> + #define MUSL_DYNAMIC_LINKER_E "%{mbig-endian:eb}"
> + #endif
> + #define MUSL_DYNAMIC_LINKER \
> +-  "/lib/ld-musl-arm" MUSL_DYNAMIC_LINKER_E
> "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
> ++  SYSTEMLIBS_DIR "ld-musl-arm" MUSL_DYNAMIC_LINKER_E
> "%{mfloat-abi=hard:hf}%{mfdpic:-fdpic}.so.1"
> +
> + /* For armv4 we pass --fix-v4bx to linker to support EABI */
> + #undef TARGET_FIX_V4BX_SPEC
> --
> 2.39.0
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175997): 
https://lists.openembedded.org/g/openembedded-core/message/175997
Mute This Topic: https://lists.openembedded.org/mt/96302404/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] mesa: update submitted patch with backported version

[Martin Jansa]

* this version was merged to main in:
  
https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911
  and cherry-picked to staging/23.0 as well in:
  
https://gitlab.freedesktop.org/mesa/mesa/-/commit/54cfb552abc50e8167cdc46d87455a9a414d7c65

  and as a bonus it doesn't break the build with DEBUG_BUILD
  for newer toolchain, so we can apply it for target build as well, see:
  https://lists.openembedded.org/g/openembedded-core/message/169002
  https://lists.openembedded.org/g/openembedded-core/message/170930

Signed-off-by: Martin Jansa 
---
 ...ove-fix-ALWAYS_INLINE-compiler-error.patch | 81 ++-
 meta/recipes-graphics/mesa/mesa.inc   |  5 +-
 2 files changed, 26 insertions(+), 60 deletions(-)

diff --git 
a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
 
b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
index 7989843eb4..1cf23492fe 100644
--- 
a/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
+++ 
b/meta/recipes-graphics/mesa/files/0001-nir-nir_opt_move-fix-ALWAYS_INLINE-compiler-error.patch
@@ -1,67 +1,36 @@
-From da6e47f1717f34c73de388c56ffaf4861a07fdc5 Mon Sep 17 00:00:00 2001
-From: t bettler 
-Date: Sat, 9 Jul 2022 09:28:51 +
+From 267dd1f4d571ee606141aa66f1665aa152b4e911 Mon Sep 17 00:00:00 2001
+From: t0b3 
+Date: Sat, 10 Dec 2022 14:32:53 +0100
 Subject: [PATCH] nir/nir_opt_move: fix ALWAYS_INLINE compiler error
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
 
-Backport merge request to fix mesa compile error when debug build
-enabled.
-
-Upstream-Status: Submitted 
[https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/17439]
-
-Signed-off-by: Kai Kang 
-
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-fix call to ‘always_inline’ ‘src_is_ssa’
-
-Closes: https://gitlab.freedesktop.org/mesa/mesa/-/issues/6825
-Fixes: f1d20ec67c3f186886b97de94f74484650f8fda1 ("nir/nir_opt_move: handle 
non-SSA defs ")
+Reviewed-by: Iago Toral Quiroga 
+Reviewed-by: Adam Jackson 
+Closes: #6825
+Fixes: f1d20ec6 ("nir/nir_opt_move: handle non-SSA defs ")
+Part-of: 
 
+Upstream-Status: Backport 
[https://gitlab.freedesktop.org/mesa/mesa/-/commit/267dd1f4d571ee606141aa66f1665aa152b4e911]
 ---
- src/compiler/nir/nir_inline_helpers.h | 10 --
- src/compiler/nir/nir_opt_move.c   |  2 +-
- 2 files changed, 9 insertions(+), 3 deletions(-)
+ src/compiler/nir/nir_opt_move.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
 
-diff --git a/src/compiler/nir/nir_inline_helpers.h 
b/src/compiler/nir/nir_inline_helpers.h
-index 125dd8a..ec33f05 100644
 a/src/compiler/nir/nir_inline_helpers.h
-+++ b/src/compiler/nir/nir_inline_helpers.h
-@@ -73,8 +73,8 @@ nir_foreach_dest(nir_instr *instr, nir_foreach_dest_cb cb, 
void *state)
-return _nir_foreach_dest(instr, cb, state);
- }
- 
--static inline bool
--nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
-+static ALWAYS_INLINE bool
-+_nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
- {
-switch (instr->type) {
-case nir_instr_type_alu: {
-@@ -162,3 +162,9 @@ nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, 
void *state)
-dest_state.cb = cb;
-return _nir_foreach_dest(instr, _nir_visit_dest_indirect, _state);
- }
-+
-+static inline bool
-+nir_foreach_src(nir_instr *instr, nir_foreach_src_cb cb, void *state)
-+{
-+   return _nir_foreach_src(instr, cb, state);
-+}
 diff --git a/src/compiler/nir/nir_opt_move.c b/src/compiler/nir/nir_opt_move.c
-index 81bcde5..051c3cc 100644
+index 81bcde5c436..9aeb9f4cf86 100644
 --- a/src/compiler/nir/nir_opt_move.c
 +++ b/src/compiler/nir/nir_opt_move.c
-@@ -60,7 +60,7 @@ src_is_ssa(nir_src *src, void *state)
- static ALWAYS_INLINE bool
- instr_reads_register(nir_instr *instr)
+@@ -51,13 +51,13 @@
+  * lower register pressure.
+  */
+ 
+-static ALWAYS_INLINE bool
++static inline bool
+ src_is_ssa(nir_src *src, void *state)
  {
--   return !nir_foreach_src(instr, src_is_ssa, NULL);
-+   return !_nir_foreach_src(instr, src_is_ssa, NULL);
+return src->is_ssa;
  }
  
- static bool
+-static ALWAYS_INLINE bool
++static inline bool
+ instr_reads_register(nir_instr *instr)
+ {
+return !nir_foreach_src(instr, src_is_ssa, NULL);
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 5fdb67ca2a..866b7fc462 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -18,11 +18,8 @@ SRC_URI = 
"https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \

file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \

Re: [OE-core] [PATCH] rust: Upgrade 1.66.0 -> 1.66.1

[Kokkonda, Sundeep]

Rust community said the security fixes are only for the current stable relases.
https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older-releases/18152/3?u=sundeep-kokkonda
For old release we've to backport the patches ourselves.

So, for the Kirkstone & Langdale we've to back port the CVE fix.

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

[OE-core] [PATCH 4/4] linux-yocto/5.15: update to v5.15.87

[Bruce Ashfield]

From: Bruce Ashfield 

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

d57287729e22 Linux 5.15.87
24186c682288 drm/mgag200: Fix PLL setup for G200_SE_A rev >=4
e326ee018a24 io_uring: Fix unsigned 'res' comparison with zero in 
io_fixup_rw_res()
b2b6eefab43d efi: random: combine bootloader provided RNG seed with RNG 
protocol output
99c0759495a0 mbcache: Avoid nesting of cache->c_list_lock under bit locks
d50d6c193adb net: hns3: fix return value check bug of rx copybreak
d4e6a13eb9a3 btrfs: make thaw time super block check to also verify checksum
70a1dccd0e58 selftests: set the BUILD variable to absolute path
58fef3ebc83c ext4: don't allow journal inode to have encrypt flag
bd5dc96fea4e mptcp: use proper req destructor for IPv6
78bd6ab52c03 mptcp: dedicated request sock for subflow in v6
6e9c1aef3e32 Revert "ACPI: PM: Add support for upcoming AMD uPEP HID 
AMDI007"
e32f867b37da ksmbd: check nt_len to be at least CIFS_ENCPWD_SIZE in 
ksmbd_decode_ntlmssp_auth_blob
4136f1ac1ecd ksmbd: fix infinite loop in ksmbd_conn_handler_loop()
f10defb0be6a hfs/hfsplus: avoid WARN_ON() for sanity check, use proper 
error handling
48d9e2e6de01 hfs/hfsplus: use WARN_ON for sanity check
f5a9bbf962e2 drm/i915/gvt: fix vgpu debugfs clean in remove
ae9a61511736 drm/i915/gvt: fix gvt debugfs destroy
eb3e943a3243 riscv, kprobes: Stricter c.jr/c.jalr decoding
620a229f576a riscv: uaccess: fix type of 0 variable on error in get_user()
8e05a993f8aa thermal: int340x: Add missing attribute for data rate base
c3222fd28225 io_uring: fix CQ waiting timeout handling
b7b9bc93055d block: don't allow splitting of a REQ_NOWAIT bio
e1358c878711 fbdev: matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
682a7d064f35 nfsd: fix handling of readdir in v4root vs. mount upcall 
timeout
cb42aa7b5f72 x86/bugs: Flush IBP in ib_prctl_set()
554a880a1fff x86/kexec: Fix double-free of elf header buffer
264241a61045 btrfs: check superblock to ensure the fs was not modified at 
thaw time
69f4bda5f4e6 nvme: also return I/O command effects from nvme_command_effects
a6a4b057cd47 nvmet: use NVME_CMD_EFFECTS_CSUPP instead of open coding it
f9309dcaa9c0 io_uring: check for valid register opcode earlier
4df413d46960 nvme: fix multipath crash caused by flush request when 
blktrace is enabled
03ce7921285e ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech 
MICA-071 tablet
0dca7375e2b9 udf: Fix extension of the last extent in the file
dc1bc903970b caif: fix memory leak in cfctrl_linkup_request()
bce3680b48d2 drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()
da6a3653b82c perf stat: Fix handling of --for-each-cgroup with 
--bpf-counters to match non BPF mode
11cd4ec6359d usb: rndis_host: Secure rndis_query check against int overflow
6ea5273c71dd octeontx2-pf: Fix lmtst ID used in aura free
4e5f2c74cbbf drivers/net/bonding/bond_3ad: return when there's no aggregator
8414983c2e64 fs/ntfs3: don't hold ni_lock when calling truncate_setsize()
a23e8376e613 drm/imx: ipuv3-plane: Fix overlay plane width
a8f7fd322f56 perf tools: Fix resources leak in perf_data__open_dir()
a1e1521b4639 netfilter: ipset: Rework long task execution when 
adding/deleting entries
6f19a3848367 netfilter: ipset: fix hash:net,port,net hang with /0 subnet
774d259749d7 net: sparx5: Fix reading of the MAC address
04dc4003e5df net: sched: cbq: dont intepret cls results when asked to drop
f02327a4877a net: sched: atm: dont intepret cls results when asked to drop
95da1882ce93 gpio: sifive: Fix refcount leak in sifive_gpio_probe
da9c9883ec96 ceph: switch to vfs_inode_has_locks() to fix file lock bug
54e72ce5f1d7 filelock: new helper: vfs_inode_has_locks
f34b03ce3a86 drm/meson: Reduce the FIFO lines held when AFBC is not used
05a8410b0fce RDMA/mlx5: Fix validation of max_rd_atomic caps for DC
8d89870d6375 RDMA/mlx5: Fix mlx5_ib_get_hw_stats when used for device
4d112f001612 net: phy: xgmiitorgmii: Fix refcount leak in xgmiitorgmii_probe
e5fbeb3d16b4 net: ena: Update NUMA TPH hint register upon NUMA node update
7840b93cfd4c net: ena: Set default value for RX interrupt moderation
d09b7a9d2f34 net: ena: Fix rx_copybreak value update
0e7ad9b006d7 net: ena: Use bitmask to indicate packet redirection
5d4964984b99 net: ena: Account for the number of processed bytes in XDP
f17d9aec07de net: ena: Don't register memory info on XDP exchange
a4aa727ad0b2 net: ena: Fix toeplitz initial hash value
0bec17f1ce31 net: amd-xgbe: add missed tasklet_kill
cb2f74685f76 net/mlx5e: Fix hw mtu initializing at XDP SQ allocation
6c72abb78b01 net/mlx5e: Always clear dest encap in neigh-update-del
b36783bc11d1 net/mlx5e: TC, Refactor mlx5e_tc_add_flow_mod_hdr() to get 
flow attr
f8c10eeba31b net/mlx5e: IPoIB, Don't allow CQE 

[OE-core] [PATCH 2/4] linux-yocto/6.1: qemuriscv32: Enable CONFIG_NONPORTABLE

[Bruce Ashfield]

From: Bruce Ashfield 

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

30825f43170 qemuriscv32: Enable CONFIG_NONPORTABLE

[

   Allow configurations that result in non-portable kernels, this is
   required for rv32 kernels starting 6.0+ see [1]

   [1] 
https://git.kernel.org/pub/scm/linux/kernel/git/torvalds/linux.git/commit/?id=44c1e84a38a0

   Signed-off-by: Khem Raj 
]

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
index 090643476f..fb68c7ba78 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "fd78a53858b7f9195ab53fd98c27736d05bbaf7c"
-SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
+SRCREV_meta ?= "30825f431703621e2b659b8e49effbdb3461f2d9"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
index 6eb8cbad2b..0d8fc236f6 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
@@ -15,7 +15,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
+SRCREV_meta ?= "30825f431703621e2b659b8e49effbdb3461f2d9"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
index 46246b9632..2caedf78ac 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"872afe79c5e568acf5f971952e78caada8424df7"
 SRCREV_machine:qemux86-64 ?= "872afe79c5e568acf5f971952e78caada8424df7"
 SRCREV_machine:qemumips64 ?= "e01e486b21db695c46c12253b92adc7aa0da6d38"
 SRCREV_machine ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
+SRCREV_meta ?= "30825f431703621e2b659b8e49effbdb3461f2d9"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.34.1


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

[OE-core] [PATCH 3/4] linux-yocto/6.1: update to v6.1.5

[Bruce Ashfield]

From: Bruce Ashfield 

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

90ca7a874a90 Linux 6.1.5
177055b94fb5 wifi: ath11k: Send PME message during wakeup from D3cold
15f818d4b682 efi: random: combine bootloader provided RNG seed with RNG 
protocol output
0c84b7de2658 drm/i915/dsi: fix MIPI_BKLT_EN_1 native GPIO index
c7229577d93d drm/i915/dsi: add support for ICL+ native MIPI GPIO sequence
5e7d97dbae25 ksmbd: check nt_len to be at least CIFS_ENCPWD_SIZE in 
ksmbd_decode_ntlmssp_auth_blob
ad678f30ac0d ksmbd: send proper error response in smb2_tree_connect()
4cd431722018 ksmbd: fix infinite loop in ksmbd_conn_handler_loop()
53e9d6851b56 btrfs: handle case when repair happens with dev-replace
d179f9d27f1e drm/amd/display: Uninitialized variables causing 4k60 UCLK to 
stay at DPM1 and not DPM0
4ac1437d64ef drm/amd/display: Add check for DET fetch latency hiding for 
dcn32
bff553de2c37 virtio_blk: Fix signedness bug in virtblk_prep_rq()
569b4f8fb02e virtio-blk: use a helper to handle request queuing errors
44c0e07e3972 drm/i915/gvt: fix vgpu debugfs clean in remove
fe340500baf8 drm/i915/gvt: fix gvt debugfs destroy
306888b1246b drm/amdkfd: Fix kernel warning during topology setup
c7041ec41036 drm/plane-helper: Add the missing declaration of 
drm_atomic_state
c4849f18185f of/fdt: run soc memory setup when early_init_dt_scan_memory 
fails
a33220faead6 riscv, kprobes: Stricter c.jr/c.jalr decoding
36fd385ae2ca riscv: uaccess: fix type of 0 variable on error in get_user()
7f56c4fa299a thermal: int340x: Add missing attribute for data rate base
8b258a31c2e8 vhost_vdpa: fix the crash in unmap a large memory
ed2d0e160ce4 tpm: Allow system suspend to continue when TPM suspend fails
e595dcd987d0 io_uring: fix CQ waiting timeout handling
91d129519985 io_uring: pin context while queueing deferred tw
6d47e0f6a535 block: don't allow splitting of a REQ_NOWAIT bio
39a20c4354be net: dsa: tag_qca: fix wrong MGMT_DATA2 size
ec6022235670 net: dsa: qca8k: fix wrong length value for mgmt eth packet
49d901dce4b9 Revert "net: dsa: qca8k: cache lo and hi for mdio write"
d54f66bc9c37 Revert "drm/amd/display: Enable Freesync Video Mode by default"
7f656fff955c bpf: Fix panic due to wrong pageattr of im->image
a3fb152c2f17 fbdev: matroxfb: G200eW: Increase max memory from 1 MB to 16 MB
421fd5c9e0ae nfsd: fix handling of readdir in v4root vs. mount upcall 
timeout
e8377f0456fb x86/bugs: Flush IBP in ib_prctl_set()
5bd3c7abeb69 x86/kexec: Fix double-free of elf header buffer
2dfc2347776e ASoC: SOF: Intel: pci-tgl: unblock S5 entry if DMA stop has 
failed"
f6631b9b4f91 nvme: also return I/O command effects from nvme_command_effects
27eab31ed71f nvmet: use NVME_CMD_EFFECTS_CSUPP instead of open coding it
84cc257e1888 kunit: alloc_string_stream_fragment error handling bug fix
8b2de5212661 io_uring: check for valid register opcode earlier
9c152189a7e8 ACPI: video: Don't enable fallback path for creating ACPI 
backlight by default
adaf41b56803 drm/amd/display: Report to ACPI video if no panels were found
0ba8892d86ad ACPI: video: Allow GPU drivers to report no panels
183c2aaef40a nvme: fix multipath crash caused by flush request when 
blktrace is enabled
a288e98adc02 io_uring/cancel: re-grab ctx mutex after finishing wait
a02c07b61989 drm/amdkfd: Fix double release compute pasid
9d74d1f52e16 drm/amdkfd: Fix kfd_process_device_init_vm error handling
8ba7c55e112f drm/amdgpu: Fix size validation for non-exclusive domains (v4)
b48f8c9a81be ASoC: SOF: mediatek: initialize panic_info to zero
ee887708e25e ASoC: Intel: bytcr_rt5640: Add quirk for the Advantech 
MICA-071 tablet
30f3e4afe09a 9p/client: fix data race on req->status
f6e548529bb9 ASoC: SOF: Revert: "core: unregister clients and machine 
drivers in .shutdown"
45917be9f0af hfs/hfsplus: avoid WARN_ON() for sanity check, use proper 
error handling
f190519b07c7 usb: dwc3: xilinx: include linux/gpio/consumer.h
2d1dbb030ca8 udf: Fix extension of the last extent in the file
3ad47c8aa564 caif: fix memory leak in cfctrl_linkup_request()
7d242f4a0c83 net/ulp: prevent ULP without clone op from entering the LISTEN 
status
50c81b35df01 qed: allow sleep in qed_mcp_trace_dump()
4e0c2961e53d ublk: honor IO_URING_F_NONBLOCK for handling control command
1022519da69d drm/i915/gvt: fix double free bug in split_2MB_gtt_entry
20a07570c166 drm/i915: unpin on error in intel_vgpu_shadow_mm_pin()
c776df09f469 perf stat: Fix handling of --for-each-cgroup with 
--bpf-counters to match non BPF mode
36caf0281b91 perf stat: Fix handling of unsupported cgroup events when 
using BPF counters
75b9086028ce perf lock contention: Fix core dump related to not finding the 
"__sched_text_end" symbol on s/390
a713602807f3 usb: rndis_host: 

[OE-core] [PATCH 1/4] linux-yocto/6.1: edgerouter: Replace OCTEON_USB with USB_OCTEON_HCD

[Bruce Ashfield]

From: Bruce Ashfield 

The OCTEON_USB has been converted into USB_OCTEON_HCD by mainline
commit 9dbdac024d4d ("staging: octeon-usb: move driver out of staging").
So adjust the BSP cfg according to that change.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
index 3f77474ae5..090643476f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_6.1.bb
@@ -12,7 +12,7 @@ python () {
 }
 
 SRCREV_machine ?= "fd78a53858b7f9195ab53fd98c27736d05bbaf7c"
-SRCREV_meta ?= "c56c1ed8bdb0c470069b74090381bfe07341c95a"
+SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-6.1;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
index 54f0065c73..6eb8cbad2b 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_6.1.bb
@@ -15,7 +15,7 @@ KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
 SRCREV_machine ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_meta ?= "c56c1ed8bdb0c470069b74090381bfe07341c95a"
+SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_6.1.bb 
b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
index f357f43f46..46246b9632 100644
--- a/meta/recipes-kernel/linux/linux-yocto_6.1.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_6.1.bb
@@ -23,7 +23,7 @@ SRCREV_machine:qemux86 ?= 
"872afe79c5e568acf5f971952e78caada8424df7"
 SRCREV_machine:qemux86-64 ?= "872afe79c5e568acf5f971952e78caada8424df7"
 SRCREV_machine:qemumips64 ?= "e01e486b21db695c46c12253b92adc7aa0da6d38"
 SRCREV_machine ?= "872afe79c5e568acf5f971952e78caada8424df7"
-SRCREV_meta ?= "c56c1ed8bdb0c470069b74090381bfe07341c95a"
+SRCREV_meta ?= "cee0a2ae73b7d47f881db93340292d22a0aeec61"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
-- 
2.34.1


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

[OE-core] [PATCH 0/4] kernel-yocto: pull request

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

Two -stable updates, and configuration tweaks that should remove the
warnings from Kevin's h/w reference version bump.

Once these merge, I'll follow up with default kernel version changes
and remove 5.19 from master.

Bruce

The following changes since commit 288cc5b879563f7f996733bc9da3b4316aa5ede0:

  gperf: Make the code C++17 compliant (2023-01-16 10:42:07 +)

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 (4):
  linux-yocto/6.1: edgerouter: Replace OCTEON_USB with USB_OCTEON_HCD
  linux-yocto/6.1: qemuriscv32: Enable CONFIG_NONPORTABLE
  linux-yocto/6.1: update to v6.1.5
  linux-yocto/5.15: update to v5.15.87

 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-rt_6.1.bb   |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 .../linux/linux-yocto-tiny_6.1.bb |  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 meta/recipes-kernel/linux/linux-yocto_6.1.bb  | 26 +--
 6 files changed, 38 insertions(+), 38 deletions(-)

-- 
2.34.1


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

Re: [OE-core][kirkstone 03/11] ffmpeg: fix for CVE-2022-3109

[Martin Jansa]

> Not sure why this didn't show up in my testing!

It's shown only when do_patch task is really executed and it doesn't cause
the do_patch to fail completely. So it's possible that you've built it once
with the warning/error shown and then the next time you were doing the
final test for kirkstone it was just re-using ffmpeg from sstate (without
the need to re-executed do_patch again).

Maybe we should consider this issue to be fatal for do_fetch when
patch-fuzz is in ERROR_QA (I even thought it was working like that at some
time).

Regards,

On Mon, Jan 16, 2023 at 3:32 PM Steve Sakoman  wrote:

> On Mon, Jan 16, 2023 at 2:00 AM Martin Jansa 
> wrote:
> >
> > This patch doesn't apply cleanly on ffmpeg-5.0.1:
>
> Thanks for the review Martin.
>
> Not sure why this didn't show up in my testing!  But since Richard
> hasn't taken the pull request yet I will remove this patch from the
> current pull request and move it to my next set of patches (along with
> your fix).
>
> Thanks!
>
> Steve
>
> >
> > ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:
> >
> > Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> > patching file libavcodec/vp3.c
> > Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).
> >
> >
> > The context lines in the patches can be updated with devtool:
> >
> > devtool modify ffmpeg
> > devtool finish --force-patch-refresh ffmpeg 
> >
> > Don't forget to review changes done by devtool!
> >
> > ERROR: ffmpeg-5.0.1-r0 do_patch: QA Issue: Patch log indicates that
> patches do not apply cleanly. [patch-fuzz]
> >
> > Narpat: Should I send a fix or will you handle that?
> >
> > On Thu, Jan 12, 2023 at 3:33 AM Steve Sakoman  wrote:
> >>
> >> From: Narpat Mali 
> >>
> >> An issue was discovered in the FFmpeg package, where vp3_decode_frame
> in libavcodec/vp3.c lacks check of
> >> the return value of av_malloc() and will cause a null pointer
> dereference, impacting availability.
> >>
> >> CVE: CVE-2022-3109
> >>
> >> Upstream-Status: Backport [
> https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568
> ]
> >>
> >> Signed-off-by: Narpat Mali 
> >> Signed-off-by: Steve Sakoman 
> >> ---
> >>  ...-vp3-Add-missing-check-for-av_malloc.patch | 44 +++
> >>  .../recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |  3 +-
> >>  2 files changed, 46 insertions(+), 1 deletion(-)
> >>  create mode 100644
> meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >>
> >> diff --git
> a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >> new file mode 100644
> >> index 00..94858a6cdd
> >> --- /dev/null
> >> +++
> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >> @@ -0,0 +1,44 @@
> >> +From 656cb0450aeb73b25d7d26980af342b37ac4c568 Mon Sep 17 00:00:00 2001
> >> +From: Jiasheng Jiang 
> >> +Date: Tue, 15 Feb 2022 17:58:08 +0800
> >> +Subject: [PATCH] avcodec/vp3: Add missing check for av_malloc
> >> +
> >> +Since the av_malloc() may fail and return NULL pointer,
> >> +it is needed that the 's->edge_emu_buffer' should be checked
> >> +whether the new allocation is success.
> >> +
> >> +Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
> >> +Reviewed-by: Peter Ross 
> >> +Signed-off-by: Jiasheng Jiang 
> >> +
> >> +CVE: CVE-2022-3109
> >> +
> >> +Upstream-Status: Backport [
> https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568
> ]
> >> +
> >> +Signed-off-by: Narpat Mali 
> >> +---
> >> + libavcodec/vp3.c | 7 ++-
> >> + 1 file changed, 6 insertions(+), 1 deletion(-)
> >> +
> >> +diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> >> +index e9ab54d736..e2418eb6fa 100644
> >> +--- a/libavcodec/vp3.c
> >>  b/libavcodec/vp3.c
> >> +@@ -2679,8 +2679,13 @@ static int vp3_decode_frame(AVCodecContext
> *avctx,
> >> + AV_GET_BUFFER_FLAG_REF)) < 0)
> >> + goto error;
> >> +
> >> +-if (!s->edge_emu_buffer)
> >> ++if (!s->edge_emu_buffer) {
> >> + s->edge_emu_buffer = av_malloc(9 *
> FFABS(s->current_frame.f->linesize[0]));
> >> ++if (!s->edge_emu_buffer) {
> >> ++ret = AVERROR(ENOMEM);
> >> ++goto error;
> >> ++}
> >> ++}
> >> +
> >> + if (s->keyframe) {
> >> + if (!s->theora) {
> >> +--
> >> +2.34.1
> >> +
> >> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> index 95b4bf50ac..c5bebe9c2d 100644
> >> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> @@ -26,7 +26,8 @@ SRC_URI = "
> https://www.ffmpeg.org/releases/${BP}.tar.xz \
> >>
>  file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
> >>
>  

Re: [OE-core][kirkstone 03/11] ffmpeg: fix for CVE-2022-3109

[Steve Sakoman]

On Mon, Jan 16, 2023 at 4:32 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
> On Mon, Jan 16, 2023 at 2:00 AM Martin Jansa  wrote:
> >
> > This patch doesn't apply cleanly on ffmpeg-5.0.1:
>
> Thanks for the review Martin.
>
> Not sure why this didn't show up in my testing!  But since Richard
> hasn't taken the pull request yet I will remove this patch from the
> current pull request and move it to my next set of patches (along with
> your fix).

Sigh, clearly I haven't had enough coffee yet this morning -- Richard
has indeed already taken the pull request!

I'll put your fix patch in the next set of patches for kirkstone and
send a new pull request right after testing.

Steve

> >
> > ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:
> >
> > Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> > patching file libavcodec/vp3.c
> > Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).
> >
> >
> > The context lines in the patches can be updated with devtool:
> >
> > devtool modify ffmpeg
> > devtool finish --force-patch-refresh ffmpeg 
> >
> > Don't forget to review changes done by devtool!
> >
> > ERROR: ffmpeg-5.0.1-r0 do_patch: QA Issue: Patch log indicates that patches 
> > do not apply cleanly. [patch-fuzz]
> >
> > Narpat: Should I send a fix or will you handle that?
> >
> > On Thu, Jan 12, 2023 at 3:33 AM Steve Sakoman  wrote:
> >>
> >> From: Narpat Mali 
> >>
> >> An issue was discovered in the FFmpeg package, where vp3_decode_frame in 
> >> libavcodec/vp3.c lacks check of
> >> the return value of av_malloc() and will cause a null pointer dereference, 
> >> impacting availability.
> >>
> >> CVE: CVE-2022-3109
> >>
> >> Upstream-Status: Backport 
> >> [https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568]
> >>
> >> Signed-off-by: Narpat Mali 
> >> Signed-off-by: Steve Sakoman 
> >> ---
> >>  ...-vp3-Add-missing-check-for-av_malloc.patch | 44 +++
> >>  .../recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |  3 +-
> >>  2 files changed, 46 insertions(+), 1 deletion(-)
> >>  create mode 100644 
> >> meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >>
> >> diff --git 
> >> a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >>  
> >> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >> new file mode 100644
> >> index 00..94858a6cdd
> >> --- /dev/null
> >> +++ 
> >> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> >> @@ -0,0 +1,44 @@
> >> +From 656cb0450aeb73b25d7d26980af342b37ac4c568 Mon Sep 17 00:00:00 2001
> >> +From: Jiasheng Jiang 
> >> +Date: Tue, 15 Feb 2022 17:58:08 +0800
> >> +Subject: [PATCH] avcodec/vp3: Add missing check for av_malloc
> >> +
> >> +Since the av_malloc() may fail and return NULL pointer,
> >> +it is needed that the 's->edge_emu_buffer' should be checked
> >> +whether the new allocation is success.
> >> +
> >> +Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
> >> +Reviewed-by: Peter Ross 
> >> +Signed-off-by: Jiasheng Jiang 
> >> +
> >> +CVE: CVE-2022-3109
> >> +
> >> +Upstream-Status: Backport 
> >> [https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568]
> >> +
> >> +Signed-off-by: Narpat Mali 
> >> +---
> >> + libavcodec/vp3.c | 7 ++-
> >> + 1 file changed, 6 insertions(+), 1 deletion(-)
> >> +
> >> +diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> >> +index e9ab54d736..e2418eb6fa 100644
> >> +--- a/libavcodec/vp3.c
> >>  b/libavcodec/vp3.c
> >> +@@ -2679,8 +2679,13 @@ static int vp3_decode_frame(AVCodecContext *avctx,
> >> + AV_GET_BUFFER_FLAG_REF)) < 0)
> >> + goto error;
> >> +
> >> +-if (!s->edge_emu_buffer)
> >> ++if (!s->edge_emu_buffer) {
> >> + s->edge_emu_buffer = av_malloc(9 * 
> >> FFABS(s->current_frame.f->linesize[0]));
> >> ++if (!s->edge_emu_buffer) {
> >> ++ret = AVERROR(ENOMEM);
> >> ++goto error;
> >> ++}
> >> ++}
> >> +
> >> + if (s->keyframe) {
> >> + if (!s->theora) {
> >> +--
> >> +2.34.1
> >> +
> >> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb 
> >> b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> index 95b4bf50ac..c5bebe9c2d 100644
> >> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> >> @@ -26,7 +26,8 @@ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
> >> 
> >> file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
> >> 
> >> file://0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch \
> >> 
> >> file://0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch \
> >> -   "
> >> +   file://0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch \

Re: [OE-core][kirkstone 03/11] ffmpeg: fix for CVE-2022-3109

[Steve Sakoman]

On Mon, Jan 16, 2023 at 2:00 AM Martin Jansa  wrote:
>
> This patch doesn't apply cleanly on ffmpeg-5.0.1:

Thanks for the review Martin.

Not sure why this didn't show up in my testing!  But since Richard
hasn't taken the pull request yet I will remove this patch from the
current pull request and move it to my next set of patches (along with
your fix).

Thanks!

Steve

>
> ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:
>
> Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> patching file libavcodec/vp3.c
> Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).
>
>
> The context lines in the patches can be updated with devtool:
>
> devtool modify ffmpeg
> devtool finish --force-patch-refresh ffmpeg 
>
> Don't forget to review changes done by devtool!
>
> ERROR: ffmpeg-5.0.1-r0 do_patch: QA Issue: Patch log indicates that patches 
> do not apply cleanly. [patch-fuzz]
>
> Narpat: Should I send a fix or will you handle that?
>
> On Thu, Jan 12, 2023 at 3:33 AM Steve Sakoman  wrote:
>>
>> From: Narpat Mali 
>>
>> An issue was discovered in the FFmpeg package, where vp3_decode_frame in 
>> libavcodec/vp3.c lacks check of
>> the return value of av_malloc() and will cause a null pointer dereference, 
>> impacting availability.
>>
>> CVE: CVE-2022-3109
>>
>> Upstream-Status: Backport 
>> [https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568]
>>
>> Signed-off-by: Narpat Mali 
>> Signed-off-by: Steve Sakoman 
>> ---
>>  ...-vp3-Add-missing-check-for-av_malloc.patch | 44 +++
>>  .../recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |  3 +-
>>  2 files changed, 46 insertions(+), 1 deletion(-)
>>  create mode 100644 
>> meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
>>
>> diff --git 
>> a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
>>  
>> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
>> new file mode 100644
>> index 00..94858a6cdd
>> --- /dev/null
>> +++ 
>> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
>> @@ -0,0 +1,44 @@
>> +From 656cb0450aeb73b25d7d26980af342b37ac4c568 Mon Sep 17 00:00:00 2001
>> +From: Jiasheng Jiang 
>> +Date: Tue, 15 Feb 2022 17:58:08 +0800
>> +Subject: [PATCH] avcodec/vp3: Add missing check for av_malloc
>> +
>> +Since the av_malloc() may fail and return NULL pointer,
>> +it is needed that the 's->edge_emu_buffer' should be checked
>> +whether the new allocation is success.
>> +
>> +Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
>> +Reviewed-by: Peter Ross 
>> +Signed-off-by: Jiasheng Jiang 
>> +
>> +CVE: CVE-2022-3109
>> +
>> +Upstream-Status: Backport 
>> [https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568]
>> +
>> +Signed-off-by: Narpat Mali 
>> +---
>> + libavcodec/vp3.c | 7 ++-
>> + 1 file changed, 6 insertions(+), 1 deletion(-)
>> +
>> +diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
>> +index e9ab54d736..e2418eb6fa 100644
>> +--- a/libavcodec/vp3.c
>>  b/libavcodec/vp3.c
>> +@@ -2679,8 +2679,13 @@ static int vp3_decode_frame(AVCodecContext *avctx,
>> + AV_GET_BUFFER_FLAG_REF)) < 0)
>> + goto error;
>> +
>> +-if (!s->edge_emu_buffer)
>> ++if (!s->edge_emu_buffer) {
>> + s->edge_emu_buffer = av_malloc(9 * 
>> FFABS(s->current_frame.f->linesize[0]));
>> ++if (!s->edge_emu_buffer) {
>> ++ret = AVERROR(ENOMEM);
>> ++goto error;
>> ++}
>> ++}
>> +
>> + if (s->keyframe) {
>> + if (!s->theora) {
>> +--
>> +2.34.1
>> +
>> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb 
>> b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
>> index 95b4bf50ac..c5bebe9c2d 100644
>> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
>> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
>> @@ -26,7 +26,8 @@ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz \
>> 
>> file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
>> 
>> file://0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch \
>> 
>> file://0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch \
>> -   "
>> +   file://0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch \
>> +  "
>>
>>  SRC_URI[sha256sum] = 
>> "ef2efae259ce80a240de48ec85ecb062cecca26e4352ffb3fda562c21a93007b"
>>
>> --
>> 2.25.1
>>
>>
>> 
>>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175987): 
https://lists.openembedded.org/g/openembedded-core/message/175987
Mute This Topic: https://lists.openembedded.org/mt/9621/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] devtool: fix devtool finish when gitmodules file is empty

[Thomas Roos via lists.openembedded.org]

From: Thomas Roos 

When a .gitmodules file is exsisting, but empty then devtool finish fails.
This fix is adding an additional check for this.

[YOCTO #14999]

Signed-off-by: Thomas Roos 
---
 meta/classes/externalsrc.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 0deb5dbf5f..26c5803ee6 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -230,7 +230,7 @@ def srctree_hash_files(d, srcdir=None):
 env['GIT_INDEX_FILE'] = tmp_index.name
 subprocess.check_output(['git', 'add', '-A', '.'], cwd=s_dir, 
env=env)
 git_sha1 = subprocess.check_output(['git', 'write-tree'], 
cwd=s_dir, env=env).decode("utf-8")
-if os.path.exists(os.path.join(s_dir, ".gitmodules")):
+if os.path.exists(os.path.join(s_dir, ".gitmodules")) and 
os.path.getsize(os.path.join(s_dir, ".gitmodules")) > 0:
 submodule_helper = subprocess.check_output(["git", "config", 
"--file", ".gitmodules", "--get-regexp", "path"], cwd=s_dir, 
env=env).decode("utf-8")
 for line in submodule_helper.splitlines():
 module_dir = os.path.join(s_dir, 
line.rsplit(maxsplit=1)[1])
-- 
2.25.1




Amazon Web Services EMEA SARL
38 avenue John F. Kennedy, L-1855 Luxembourg
Sitz der Gesellschaft: L-1855 Luxemburg
eingetragen im Luxemburgischen Handelsregister unter R.C.S. B186284

Amazon Web Services EMEA SARL, Niederlassung Deutschland
Marcel-Breuer-Str. 12, D-80807 Muenchen
Sitz der Zweigniederlassung: Muenchen
eingetragen im Handelsregister des Amtsgerichts Muenchen unter HRB 242240, 
USt-ID DE317013094





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

[OE-core] [PATCH v2] webkitgtk: fix perl-native dependency

[Ovidiu Panait]

From: Ovidiu Panait 

Currently, perl-native is missing from DEPENDS for webkitgtk even though
perlnative bbclass is inherited. This happens because the DEPENDS variable is
reassigned right after perlnative class is inherited:

inherit perlnative (DEPENDS += "perl-native")
...
DEPENDS = " \
..."

Adjust the DEPENDS line to use += in order to fix this.

Signed-off-by: Ovidiu Panait 
---
v2 updates: change DEPENDS line to use +=.

 meta/recipes-sato/webkit/webkitgtk_2.38.3.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-sato/webkit/webkitgtk_2.38.3.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.38.3.bb
index e890079dc5..f076fb0498 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.38.3.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.38.3.bb
@@ -24,7 +24,7 @@ REQUIRED_DISTRO_FEATURES = 
"${@bb.utils.contains('DISTRO_FEATURES', 'wayland', '
 
 CVE_PRODUCT = "webkitgtk webkitgtk\+"
 
-DEPENDS = " \
+DEPENDS += " \
   ruby-native \
   gperf-native \
   cairo \
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175985): 
https://lists.openembedded.org/g/openembedded-core/message/175985
Mute This Topic: https://lists.openembedded.org/mt/96306925/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Alexander Kanavin]

MAGIC=... was added in the first place to the native rpm 4.x wrapper
by me because rpm links with libmagic (which is a part of file
recipe/component), and libmagic would try to find it in file's
recipe-specific sysroot if not overridden from environment.

I'd say the right fix would be to make libmagic (or whatever else
reads the file) find the needed file relative to its own installation
path.

Alex

On Mon, 16 Jan 2023 at 13:56, Martin Jansa  wrote:
>
> The use case I was fixing in:
> https://git.openembedded.org/openembedded-core/commit/?id=f40a2658f5be6739c5dddab7f9f11e1f85a17102
> was just about rpmdeps not being able to find rpmrc due to wrong path in the 
> wrapper.
>
> MAGIC was moved to environment-setup.d/rpm.sh just to set all variables 
> (which used to be set in the wrappers) in the same place and to be able to 
> remove the wrappers completely in the next commit.
>
> It might be cleaner to set MAGIC variable in separate 
> environment-setup.d/file.sh installed by nativesdk-file to make sure that 
> it's set only together when corresponding magic.mgc is installed in SDK (but 
> we'll still need to depend on file where needed). MAGIC variable was added in 
> https://git.openembedded.org/openembedded-core/commit/?id=760103cdaed3e820888d8984ec0b76cfc831d534
>  but commit doesn't say why.
>
> Regards,
>
> On Mon, Jan 16, 2023 at 1:47 PM Chen, Qi  wrote:
>>
>> Richard, I'm going to check how rpm uses 'file' and will come up with a 
>> better solution.
>> Martin, could you please tell me your use case, if convenient? I will ensure 
>> I don't break it.
>>
>> Regards,
>> Qi
>>
>> -Original Message-
>> From: Richard Purdie 
>> Sent: Monday, January 16, 2023 7:14 PM
>> To: Chen, Qi ; 
>> openembedded-core@lists.openembedded.org
>> Subject: Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on 
>> nativesdk-file
>>
>> On Mon, 2023-01-16 at 10:39 +, Richard Purdie via lists.openembedded.org 
>> wrote:
>> > On Mon, 2023-01-16 at 16:48 +0800, Chen Qi wrote:
>> > > For now, running `file' inside SDK errors out.
>> > >   file: could not find any valid magic files!
>> > >
>> > > This is because nativesdk-rpm exports MAGIC. So let's make
>> > > nativesdk-rpm depend on file for better user experiences.
>> > >
>> > > Signed-off-by: Chen Qi 
>> > > ---
>> > >  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
>> > >  1 file changed, 1 insertion(+)
>> > >
>> > > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
>> > > b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
>> > > index 8eb0ab207e..3b7d4d640a 100644
>> > > --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
>> > > +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
>> > > @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
>> > >  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
>> > >
>> > >  RDEPENDS:${PN}-build = "bash perl python3-core"
>> > > +RDEPENDS:nativesdk-rpm += "nativesdk-file"
>> >
>> > Should we be adding file to ${PN}-build instead?  Which rpm command
>> > was this with? Does anywhere else in rpm have/need this dependency?
>>
>> To answer my question, the problem is that as well as the rpm wrappers, the 
>> code also sets MAGIC= from an environment setup file.
>>
>> At the very least, the RDEPENDS needs a class-nativesdk override in there as 
>> otherwise it is floating around unconditionally.
>>
>> I don't really like adding workarounds like this since we won't understand 
>> them at some future date.
>>
>> Other solutions might include:
>>
>> a) patching RPM to use RPM_FILEMAGIC instead of MAGIC so we can set it in a 
>> more granular way
>> b) moving the environment setup piece for MAGIC to nativesdk-file so it is 
>> only used if file is installed in the SDK
>> c) fixing rpm (or file?) to dynamically relocate the paths it is using
>>
>> Can we see if there is a better solution we can switch to please?
>>
>> Cheers,
>>
>> Richard
>>
>>
>>
>>
>>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175984): 
https://lists.openembedded.org/g/openembedded-core/message/175984
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] oe-setup-build: add a tool for discovering config templates and setting up builds

[Richard Purdie]

On Thu, 2022-11-10 at 10:24 +0100, Alexander Kanavin wrote:
> This is the last (I believe) piece of the puzzle in setting up builds from 
> nothing
> without having to write custom scripts or use external tools.
> 
> After layers have been fetched and placed into their respective locations, 
> one would
> surely want to proceed to the actual build, and here's how:
> 
> 1. Without arguments or with 'list-config-templates', the tool simply walks 
> the ../..
> of its location (which is the parent dir of poky/oe-core), and prints what 
> templates it
> has found, as seen below. If the following is not enough information,
> adding '-v' will also print conf-notes.txt for each of the templates:
> 
> $ oe-setup-build
> Available build configuration templates (re-run with -v to see their 
> descriptions):
> 
> /srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c 
> /srv/work/alex/poky/meta-poky/conf/templates/default
> will create a build configuration in /srv/work/alex/build-meta-poky-default
> 
> /srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c 
> /srv/work/alex/meta-alex/conf/templates/configuration-gizmo
> will create a build configuration in 
> /srv/work/alex/build-meta-alex-configuration-gizmo
> 
> /srv/work/alex/poky/scripts/oe-setup-build setup-build-env -c 
> /srv/work/alex/meta-alex/conf/templates/configuration-gadget
> will create a build configuration in 
> /srv/work/alex/build-meta-alex-configuration-gadget
> 
> 2. Then the user picks one command of the above and runs it. This will land 
> them in a shell ready to run bitbake:
> 
> $ oe-setup-build setup-build-env -c 
> /srv/work/alex/meta-alex/conf/templates/configuration-gizmo
> Running: 
> TEMPLATECONF=/srv/work/alex/meta-alex/conf/templates/configuration-gizmo . 
> /srv/work/alex/poky/oe-init-build-env 
> /srv/work/alex/build-meta-alex-configuration-gizmo && /bin/bash
> You had no conf/local.conf file. This configuration file has therefore been
> created for you from 
> /srv/work/alex/meta-alex/conf/templates/configuration-gizmo/local.conf.sample
> You may wish to edit it to, for example, select a different MACHINE (target
> hardware). See conf/local.conf for more information as common configuration
> options are commented.
> 
> You had no conf/bblayers.conf file. This configuration file has therefore been
> created for you from 
> /srv/work/alex/meta-alex/conf/templates/configuration-gizmo/bblayers.conf.sample
> To add additional metadata layers into your configuration please add entries
> to conf/bblayers.conf.
> 
> The Yocto Project has extensive documentation about OE including a reference
> manual which can be found at:
> https://docs.yoctoproject.org
> 
> For more information about OpenEmbedded see the website:
> https://www.openembedded.org/
> 
> This configuration template will set up a build for the purposes of 
> supporting gizmo.
> Please refer to meta-alex/README for additional details and available bitbake 
> targets.
> 
> 3. The full set of command line options is:
> 
> $ oe-setup-build -h
> usage: oe-setup-build [-h] {list-config-templates,setup-build-env} ...
> 
> A script that discovers available build configuration templates and sets up a 
> build environment based on one of them
> 
> positional arguments:
>   {list-config-templates,setup-build-env}
> list-config-templates
> List available configuration templates
> setup-build-env Set up a build environment and open a shell session 
> with it, ready to run builds.
> 
> optional arguments:
>   -h, --helpshow this help message and exit
> 
> $ oe-setup-build list-config-templates -h
> usage: oe-setup-build list-config-templates [-h] [--topdir TOPDIR] [-v]
> 
> optional arguments:
>   -h, --help   show this help message and exit
>   --topdir TOPDIR  Where to look for available build configuration templates 
> (default is /srv/work/alex).
>   -v   Print a description for each available build configuration 
> template.
> 
> $ oe-setup-build setup-build-env -h
> usage: oe-setup-build setup-build-env [-h] -c template_path [-b build_path] 
> [--no-shell]
> 
> optional arguments:
>   -h, --helpshow this help message and exit
>   -c template_path  Use a build configuration template in template_path to 
> set up a build environment (run this script with 'list-config-templates' to 
> see what is available)
>   -b build_path Set up a build directory in build_path (run this script 
> with 'list-config-templates' to see where it would be by default)
>   --no-shellCreate a build directory but do not start a shell session 
> with the build environment from it.
> 
> 4. There's also a selftest that runs a basic check for template discovery and 
> build setup,
> and an added hint in oe-setup-layers about how to proceed (as it is really 
> not user-friendly
> to fetch the layer repos successfully and then exit without a word).
> 
> Signed-off-by: Alexander Kanavin 

I appreciate I've 

Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Martin Jansa]

The use case I was fixing in:
https://git.openembedded.org/openembedded-core/commit/?id=f40a2658f5be6739c5dddab7f9f11e1f85a17102
was just about rpmdeps not being able to find rpmrc due to wrong path in
the wrapper.

MAGIC was moved to environment-setup.d/rpm.sh just to set all variables
(which used to be set in the wrappers) in the same place and to be able to
remove the wrappers completely in the next commit.

It might be cleaner to set MAGIC variable in separate
environment-setup.d/file.sh installed by nativesdk-file to make sure that
it's set only together when corresponding magic.mgc is installed in SDK
(but we'll still need to depend on file where needed). MAGIC variable was
added in
https://git.openembedded.org/openembedded-core/commit/?id=760103cdaed3e820888d8984ec0b76cfc831d534
but commit doesn't say why.

Regards,

On Mon, Jan 16, 2023 at 1:47 PM Chen, Qi  wrote:

> Richard, I'm going to check how rpm uses 'file' and will come up with a
> better solution.
> Martin, could you please tell me your use case, if convenient? I will
> ensure I don't break it.
>
> Regards,
> Qi
>
> -Original Message-
> From: Richard Purdie 
> Sent: Monday, January 16, 2023 7:14 PM
> To: Chen, Qi ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on
> nativesdk-file
>
> On Mon, 2023-01-16 at 10:39 +, Richard Purdie via
> lists.openembedded.org wrote:
> > On Mon, 2023-01-16 at 16:48 +0800, Chen Qi wrote:
> > > For now, running `file' inside SDK errors out.
> > >   file: could not find any valid magic files!
> > >
> > > This is because nativesdk-rpm exports MAGIC. So let's make
> > > nativesdk-rpm depend on file for better user experiences.
> > >
> > > Signed-off-by: Chen Qi 
> > > ---
> > >  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
> > >  1 file changed, 1 insertion(+)
> > >
> > > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > > b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > > index 8eb0ab207e..3b7d4d640a 100644
> > > --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > > +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > > @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
> > >  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
> > >
> > >  RDEPENDS:${PN}-build = "bash perl python3-core"
> > > +RDEPENDS:nativesdk-rpm += "nativesdk-file"
> >
> > Should we be adding file to ${PN}-build instead?  Which rpm command
> > was this with? Does anywhere else in rpm have/need this dependency?
>
> To answer my question, the problem is that as well as the rpm wrappers,
> the code also sets MAGIC= from an environment setup file.
>
> At the very least, the RDEPENDS needs a class-nativesdk override in there
> as otherwise it is floating around unconditionally.
>
> I don't really like adding workarounds like this since we won't understand
> them at some future date.
>
> Other solutions might include:
>
> a) patching RPM to use RPM_FILEMAGIC instead of MAGIC so we can set it in
> a more granular way
> b) moving the environment setup piece for MAGIC to nativesdk-file so it is
> only used if file is installed in the SDK
> c) fixing rpm (or file?) to dynamically relocate the paths it is using
>
> Can we see if there is a better solution we can switch to please?
>
> Cheers,
>
> Richard
>
>
>
>
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175982): 
https://lists.openembedded.org/g/openembedded-core/message/175982
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Chen Qi]

Richard, I'm going to check how rpm uses 'file' and will come up with a better 
solution.
Martin, could you please tell me your use case, if convenient? I will ensure I 
don't break it.

Regards,
Qi

-Original Message-
From: Richard Purdie  
Sent: Monday, January 16, 2023 7:14 PM
To: Chen, Qi ; openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on nativesdk-file

On Mon, 2023-01-16 at 10:39 +, Richard Purdie via lists.openembedded.org 
wrote:
> On Mon, 2023-01-16 at 16:48 +0800, Chen Qi wrote:
> > For now, running `file' inside SDK errors out.
> >   file: could not find any valid magic files!
> > 
> > This is because nativesdk-rpm exports MAGIC. So let's make 
> > nativesdk-rpm depend on file for better user experiences.
> > 
> > Signed-off-by: Chen Qi 
> > ---
> >  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
> > b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > index 8eb0ab207e..3b7d4d640a 100644
> > --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
> >  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
> >  
> >  RDEPENDS:${PN}-build = "bash perl python3-core"
> > +RDEPENDS:nativesdk-rpm += "nativesdk-file"
> 
> Should we be adding file to ${PN}-build instead?  Which rpm command 
> was this with? Does anywhere else in rpm have/need this dependency?

To answer my question, the problem is that as well as the rpm wrappers, the 
code also sets MAGIC= from an environment setup file.

At the very least, the RDEPENDS needs a class-nativesdk override in there as 
otherwise it is floating around unconditionally.

I don't really like adding workarounds like this since we won't understand them 
at some future date.

Other solutions might include:

a) patching RPM to use RPM_FILEMAGIC instead of MAGIC so we can set it in a 
more granular way
b) moving the environment setup piece for MAGIC to nativesdk-file so it is only 
used if file is installed in the SDK
c) fixing rpm (or file?) to dynamically relocate the paths it is using

Can we see if there is a better solution we can switch to please?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175981): 
https://lists.openembedded.org/g/openembedded-core/message/175981
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rust: Merge all rustc-source patches into rust-source.inc

[Kokkonda, Sundeep]

Adding 'IMAGE_INSTALL:append = " packagegroup-core-buildessential" ' fixed this 
linker issue.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175980): 
https://lists.openembedded.org/g/openembedded-core/message/175980
Mute This Topic: https://lists.openembedded.org/mt/96110740/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][kirkstone] ffmpeg: refresh patches to apply cleanly

[Martin Jansa]

* the last patch added in:
  
https://git.openembedded.org/openembedded-core/commit/?h=kirkstone=874b72fe259cd3a23f4613fccfe2e9cc3f79cd6a
  doesn't apply cleanly.

* fixes:
  ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:

  Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
  patching file libavcodec/vp3.c
  Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).

Signed-off-by: Martin Jansa 
---
 ...c-stop-accessing-out-of-bounds-frame.patch | 19 ---
 ...c-stop-accessing-out-of-bounds-frame.patch |  7 ++-
 ...-vp3-Add-missing-check-for-av_malloc.patch | 12 +---
 3 files changed, 15 insertions(+), 23 deletions(-)

diff --git 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
index 2775a81cc8..23573bb6b3 100644
--- 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
+++ 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
@@ -1,4 +1,4 @@
-From 92f9b28ed84a77138105475beba16c146bdaf984 Mon Sep 17 00:00:00 2001
+From ce25c03fb83395c0a8b5b8121182a486c4408dd4 Mon Sep 17 00:00:00 2001
 From: Paul B Mahol 
 Date: Sat, 12 Nov 2022 16:12:00 +0100
 Subject: [PATCH] avcodec/rpzaenc: stop accessing out of bounds frame
@@ -12,10 +12,10 @@ Signed-off-by: 
  1 file changed, 15 insertions(+), 7 deletions(-)
 
 diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
-index d710eb4f82..4ced9523e2 100644
+index 337b1fa..3e97c87 100644
 --- a/libavcodec/rpzaenc.c
 +++ b/libavcodec/rpzaenc.c
-@@ -205,7 +205,7 @@ static void get_max_component_diff(const BlockInfo *bi, 
const uint16_t *block_pt
+@@ -205,7 +205,7 @@ static void get_max_component_diff(BlockInfo *bi, uint16_t 
*block_ptr,
  
  // loop thru and compare pixels
  for (y = 0; y < bi->block_height; y++) {
@@ -24,7 +24,7 @@ index d710eb4f82..4ced9523e2 100644
  // TODO:  optimize
  min_r = FFMIN(R(block_ptr[x]), min_r);
  min_g = FFMIN(G(block_ptr[x]), min_g);
-@@ -278,7 +278,7 @@ static int leastsquares(const uint16_t *block_ptr, const 
BlockInfo *bi,
+@@ -277,7 +277,7 @@ static int leastsquares(uint16_t *block_ptr, BlockInfo *bi,
  return -1;
  
  for (i = 0; i < bi->block_height; i++) {
@@ -33,7 +33,7 @@ index d710eb4f82..4ced9523e2 100644
  x = GET_CHAN(block_ptr[j], xchannel);
  y = GET_CHAN(block_ptr[j], ychannel);
  sumx += x;
-@@ -325,7 +325,7 @@ static int calc_lsq_max_fit_error(const uint16_t 
*block_ptr, const BlockInfo *bi
+@@ -324,7 +324,7 @@ static int calc_lsq_max_fit_error(uint16_t *block_ptr, 
BlockInfo *bi,
  int max_err = 0;
  
  for (i = 0; i < bi->block_height; i++) {
@@ -42,7 +42,7 @@ index d710eb4f82..4ced9523e2 100644
  int x_inc, lin_y, lin_x;
  x = GET_CHAN(block_ptr[j], xchannel);
  y = GET_CHAN(block_ptr[j], ychannel);
-@@ -420,7 +420,9 @@ static void update_block_in_prev_frame(const uint16_t 
*src_pixels,
+@@ -419,7 +419,9 @@ static void update_block_in_prev_frame(const uint16_t 
*src_pixels,
 uint16_t *dest_pixels,
 const BlockInfo *bi, int block_counter)
  {
@@ -53,7 +53,7 @@ index d710eb4f82..4ced9523e2 100644
  memcpy(dest_pixels, src_pixels, 8);
  dest_pixels += bi->rowstride;
  src_pixels += bi->rowstride;
-@@ -730,14 +732,15 @@ post_skip :
+@@ -729,14 +731,15 @@ post_skip :
  
  if (err > s->sixteen_color_thresh) { // DO SIXTEEN COLOR BLOCK
  uint16_t *row_ptr;
@@ -72,7 +72,7 @@ index d710eb4f82..4ced9523e2 100644
  rgb555 = row_ptr[x] & ~0x8000;
  
  put_bits(>pb, 16, rgb555);
-@@ -745,6 +748,11 @@ post_skip :
+@@ -744,6 +747,11 @@ post_skip :
  row_ptr += bi.rowstride;
  }
  
@@ -84,6 +84,3 @@ index d710eb4f82..4ced9523e2 100644
  block_counter++;
  } else { // FOUR COLOR BLOCK
  block_counter += encode_four_color_block(min_color, max_color,
--- 
-2.34.1
-
diff --git 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
index 923fc6a9c1..6e237fdd52 100644
--- 
a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
+++ 
b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
@@ -1,4 +1,4 @@
-From 13c13109759090b7f7182480d075e13b36ed8edd Mon Sep 17 00:00:00 2001
+From d2f31887df2c42948dba7446c475026fdbc69336 Mon Sep 17 00:00:00 2001
 From: Paul B Mahol 
 Date: Sat, 12 Nov 2022 15:19:21 +0100
 Subject: 

Re: [OE-core][kirkstone 03/11] ffmpeg: fix for CVE-2022-3109

[Martin Jansa]

This patch doesn't apply cleanly on ffmpeg-5.0.1:

ERROR: ffmpeg-5.0.1-r0 do_patch: Fuzz detected:

Applying patch 0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
patching file libavcodec/vp3.c
Hunk #1 succeeded at 2677 with fuzz 1 (offset -2 lines).


The context lines in the patches can be updated with devtool:

devtool modify ffmpeg
devtool finish --force-patch-refresh ffmpeg 

Don't forget to review changes done by devtool!

ERROR: ffmpeg-5.0.1-r0 do_patch: QA Issue: Patch log indicates that patches
do not apply cleanly. [patch-fuzz]

Narpat: Should I send a fix or will you handle that?

On Thu, Jan 12, 2023 at 3:33 AM Steve Sakoman  wrote:

> From: Narpat Mali 
>
> An issue was discovered in the FFmpeg package, where vp3_decode_frame in
> libavcodec/vp3.c lacks check of
> the return value of av_malloc() and will cause a null pointer dereference,
> impacting availability.
>
> CVE: CVE-2022-3109
>
> Upstream-Status: Backport [
> https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568
> ]
>
> Signed-off-by: Narpat Mali 
> Signed-off-by: Steve Sakoman 
> ---
>  ...-vp3-Add-missing-check-for-av_malloc.patch | 44 +++
>  .../recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb |  3 +-
>  2 files changed, 46 insertions(+), 1 deletion(-)
>  create mode 100644
> meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
>
> diff --git
> a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> new file mode 100644
> index 00..94858a6cdd
> --- /dev/null
> +++
> b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch
> @@ -0,0 +1,44 @@
> +From 656cb0450aeb73b25d7d26980af342b37ac4c568 Mon Sep 17 00:00:00 2001
> +From: Jiasheng Jiang 
> +Date: Tue, 15 Feb 2022 17:58:08 +0800
> +Subject: [PATCH] avcodec/vp3: Add missing check for av_malloc
> +
> +Since the av_malloc() may fail and return NULL pointer,
> +it is needed that the 's->edge_emu_buffer' should be checked
> +whether the new allocation is success.
> +
> +Fixes: d14723861b ("VP3: fix decoding of videos with stride > 2048")
> +Reviewed-by: Peter Ross 
> +Signed-off-by: Jiasheng Jiang 
> +
> +CVE: CVE-2022-3109
> +
> +Upstream-Status: Backport [
> https://github.com/FFmpeg/FFmpeg/commit/656cb0450aeb73b25d7d26980af342b37ac4c568
> ]
> +
> +Signed-off-by: Narpat Mali 
> +---
> + libavcodec/vp3.c | 7 ++-
> + 1 file changed, 6 insertions(+), 1 deletion(-)
> +
> +diff --git a/libavcodec/vp3.c b/libavcodec/vp3.c
> +index e9ab54d736..e2418eb6fa 100644
> +--- a/libavcodec/vp3.c
>  b/libavcodec/vp3.c
> +@@ -2679,8 +2679,13 @@ static int vp3_decode_frame(AVCodecContext *avctx,
> + AV_GET_BUFFER_FLAG_REF)) < 0)
> + goto error;
> +
> +-if (!s->edge_emu_buffer)
> ++if (!s->edge_emu_buffer) {
> + s->edge_emu_buffer = av_malloc(9 *
> FFABS(s->current_frame.f->linesize[0]));
> ++if (!s->edge_emu_buffer) {
> ++ret = AVERROR(ENOMEM);
> ++goto error;
> ++}
> ++}
> +
> + if (s->keyframe) {
> + if (!s->theora) {
> +--
> +2.34.1
> +
> diff --git a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> index 95b4bf50ac..c5bebe9c2d 100644
> --- a/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> +++ b/meta/recipes-multimedia/ffmpeg/ffmpeg_5.0.1.bb
> @@ -26,7 +26,8 @@ SRC_URI = "https://www.ffmpeg.org/releases/${BP}.tar.xz
> \
>
> file://0001-libavutil-include-assembly-with-full-path-from-sourc.patch \
>
> file://0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch \
>
> file://0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch \
> -   "
> +   file://0001-avcodec-vp3-Add-missing-check-for-av_malloc.patch \
> +  "
>
>  SRC_URI[sha256sum] =
> "ef2efae259ce80a240de48ec85ecb062cecca26e4352ffb3fda562c21a93007b"
>
> --
> 2.25.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175978): 
https://lists.openembedded.org/g/openembedded-core/message/175978
Mute This Topic: https://lists.openembedded.org/mt/9621/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] cve-check: write the cve manifest to IMGDEPLOYDIR

[jermain . horsman]

From: Jermain Horsman 

When building an image cve_check_write_rootfs_manifest() would sometimes fail
with a FileNotFoundError when writing the manifest.cve due to the parent
directory (DEPLOY_DIR_IMAGE) not (yet) existing.

The image task will provide the manifest in the deploy directory afterwards,
so other recipes depending on the manifest being in DEPLOY_DIR_IMAGE should
continue to function properly.

Signed-off-by: Jermain Horsman 
---
 meta/classes/cve-check.bbclass | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/classes/cve-check.bbclass b/meta/classes/cve-check.bbclass
index 4b4ea7893e..41fdf8363f 100644
--- a/meta/classes/cve-check.bbclass
+++ b/meta/classes/cve-check.bbclass
@@ -48,8 +48,8 @@ CVE_CHECK_LOG_JSON ?= "${T}/cve.json"
 CVE_CHECK_DIR ??= "${DEPLOY_DIR}/cve"
 CVE_CHECK_RECIPE_FILE ?= "${CVE_CHECK_DIR}/${PN}"
 CVE_CHECK_RECIPE_FILE_JSON ?= "${CVE_CHECK_DIR}/${PN}_cve.json"
-CVE_CHECK_MANIFEST ?= 
"${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve"
-CVE_CHECK_MANIFEST_JSON ?= 
"${DEPLOY_DIR_IMAGE}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.json"
+CVE_CHECK_MANIFEST ?= "${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.cve"
+CVE_CHECK_MANIFEST_JSON ?= 
"${IMGDEPLOYDIR}/${IMAGE_NAME}${IMAGE_NAME_SUFFIX}.json"
 CVE_CHECK_COPY_FILES ??= "1"
 CVE_CHECK_CREATE_MANIFEST ??= "1"
 
@@ -202,7 +202,7 @@ python cve_check_write_rootfs_manifest () {
 recipies.add(pkg_data["PN"])
 
 bb.note("Writing rootfs CVE manifest")
-deploy_dir = d.getVar("DEPLOY_DIR_IMAGE")
+deploy_dir = d.getVar("IMGDEPLOYDIR")
 link_name = d.getVar("IMAGE_LINK_NAME")
 
 json_data = {"version":"1", "package": []}
-- 
2.38.1.windows.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175976): 
https://lists.openembedded.org/g/openembedded-core/message/175976
Mute This Topic: https://lists.openembedded.org/mt/96304674/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] rust: Upgrade 1.66.0 -> 1.66.1

[Kokkonda, Sundeep]

Topic created on Rust community 
https://internals.rust-lang.org/t/cargo-cve-2022-46176-fix-for-older-releases/18152

Based on the community feedback we will take a decision for Kirkstone & 
Langdale branches update.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175975): 
https://lists.openembedded.org/g/openembedded-core/message/175975
Mute This Topic: https://lists.openembedded.org/mt/96218038/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Richard Purdie]

On Mon, 2023-01-16 at 10:39 +, Richard Purdie via
lists.openembedded.org wrote:
> On Mon, 2023-01-16 at 16:48 +0800, Chen Qi wrote:
> > For now, running `file' inside SDK errors out.
> >   file: could not find any valid magic files!
> > 
> > This is because nativesdk-rpm exports MAGIC. So let's
> > make nativesdk-rpm depend on file for better user
> > experiences.
> > 
> > Signed-off-by: Chen Qi 
> > ---
> >  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
> > b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > index 8eb0ab207e..3b7d4d640a 100644
> > --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
> >  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
> >  
> >  RDEPENDS:${PN}-build = "bash perl python3-core"
> > +RDEPENDS:nativesdk-rpm += "nativesdk-file"
> 
> Should we be adding file to ${PN}-build instead?  Which rpm command was
> this with? Does anywhere else in rpm have/need this dependency?

To answer my question, the problem is that as well as the rpm wrappers,
the code also sets MAGIC= from an environment setup file.

At the very least, the RDEPENDS needs a class-nativesdk override in
there as otherwise it is floating around unconditionally.

I don't really like adding workarounds like this since we won't
understand them at some future date.

Other solutions might include:

a) patching RPM to use RPM_FILEMAGIC instead of MAGIC so we can set it
in a more granular way
b) moving the environment setup piece for MAGIC to nativesdk-file so it
is only used if file is installed in the SDK
c) fixing rpm (or file?) to dynamically relocate the paths it is using

Can we see if there is a better solution we can switch to please?

Cheers,

Richard






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175974): 
https://lists.openembedded.org/g/openembedded-core/message/175974
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] classes: decode output data to text

[Pawel Zalewski]

That is a good point, looking at the codebase I think that the go-to for
dealing with it is using the call to ".decode('utf8')".

Thanks,
Pawel

On Mon, 16 Jan 2023 at 11:01, Richard Purdie <
richard.pur...@linuxfoundation.org> wrote:

> On Thu, 2022-12-22 at 10:38 +, Pawel Zalewski wrote:
> > The default return value from subprocess.check_output is an encoded byte.
> > The applied fix will decode the value to a string.
> >
> > Signed-off-by: Pawel Zalewski 
> > ---
> >  meta/classes/fs-uuid.bbclass | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-uuid.bbclass
> > index 9b53dfba7a..731ea575bd 100644
> > --- a/meta/classes/fs-uuid.bbclass
> > +++ b/meta/classes/fs-uuid.bbclass
> > @@ -4,7 +4,7 @@
> >  def get_rootfs_uuid(d):
> >  import subprocess
> >  rootfs = d.getVar('ROOTFS')
> > -output = subprocess.check_output(['tune2fs', '-l', rootfs])
> > +output = subprocess.check_output(['tune2fs', '-l', rootfs],
> text=True)
> >  for line in output.split('\n'):
> >  if line.startswith('Filesystem UUID:'):
> >  uuid = line.split()[-1]
>
> You mentioned running into this on kirkstone. One problem is that
> text=True is python 3.7 syntax so whilst this is fine for master,
> kirkstone supports older versions of python.
>
> Cheers,
>
> Richard
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175973): 
https://lists.openembedded.org/g/openembedded-core/message/175973
Mute This Topic: https://lists.openembedded.org/mt/95823853/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] classes: decode output data to text

[Richard Purdie]

On Thu, 2022-12-22 at 10:38 +, Pawel Zalewski wrote:
> The default return value from subprocess.check_output is an encoded byte.
> The applied fix will decode the value to a string.
> 
> Signed-off-by: Pawel Zalewski 
> ---
>  meta/classes/fs-uuid.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/fs-uuid.bbclass b/meta/classes/fs-uuid.bbclass
> index 9b53dfba7a..731ea575bd 100644
> --- a/meta/classes/fs-uuid.bbclass
> +++ b/meta/classes/fs-uuid.bbclass
> @@ -4,7 +4,7 @@
>  def get_rootfs_uuid(d):
>  import subprocess
>  rootfs = d.getVar('ROOTFS')
> -output = subprocess.check_output(['tune2fs', '-l', rootfs])
> +output = subprocess.check_output(['tune2fs', '-l', rootfs], text=True)
>  for line in output.split('\n'):
>  if line.startswith('Filesystem UUID:'):
>  uuid = line.split()[-1]

You mentioned running into this on kirkstone. One problem is that
text=True is python 3.7 syntax so whilst this is fine for master,
kirkstone supports older versions of python. 

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175972): 
https://lists.openembedded.org/g/openembedded-core/message/175972
Mute This Topic: https://lists.openembedded.org/mt/95823853/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] classes: decode output data to text

[Richard Purdie]

On Fri, 2023-01-06 at 14:32 +0100, Alexander Kanavin wrote:
> Now I see what's going on. The fs-uuid class contains two functions:
> get_rootfs_uuid, and replace_rootfs_uuid. The former is not used
> anywhere, but the latter is. Can you introduce get_rootfs_uuid() into
> something in oe-core, perhaps it could enhance existing code somewhere
> (maybe complement replace_rootfs_uuid usage?), or a test could be made
> better?
> 
> Otherwise, it's still not tested, and will regress without notice.

I still didn't quite understand this explanation since 
replace_rootfs_uuid() calls get_rootfs_uuid().

The issue is that UUID_PLACEHOLDER isn't used anywhere in core:

UUID_PLACEHOLDER = '<>'

which means that get_rootfs_uuid() is never called.

There are some hints about how this should be used here:

https://git.yoctoproject.org/poky/commit/meta/?id=6d7bcd4df5722f3ccebbbf73361838cb0a5dc0ee

The fix is therefore probably ok but a test of UUID_PLACEHOLDER is
missing.

Looking at the class code, these two functions should be moved to
lib/oe/ as well, we don't need a bbclass for this.

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175971): 
https://lists.openembedded.org/g/openembedded-core/message/175971
Mute This Topic: https://lists.openembedded.org/mt/95823853/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Richard Purdie]

On Mon, 2023-01-16 at 16:48 +0800, Chen Qi wrote:
> For now, running `file' inside SDK errors out.
>   file: could not find any valid magic files!
> 
> This is because nativesdk-rpm exports MAGIC. So let's
> make nativesdk-rpm depend on file for better user
> experiences.
> 
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
> b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> index 8eb0ab207e..3b7d4d640a 100644
> --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
>  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
>  
>  RDEPENDS:${PN}-build = "bash perl python3-core"
> +RDEPENDS:nativesdk-rpm += "nativesdk-file"

Should we be adding file to ${PN}-build instead?  Which rpm command was
this with? Does anywhere else in rpm have/need this dependency?

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175970): 
https://lists.openembedded.org/g/openembedded-core/message/175970
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Martin Jansa]

Acked-by: Martin Jansa 

On Mon, Jan 16, 2023 at 9:48 AM Chen Qi  wrote:

> For now, running `file' inside SDK errors out.
>   file: could not find any valid magic files!
>
> This is because nativesdk-rpm exports MAGIC. So let's
> make nativesdk-rpm depend on file for better user
> experiences.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> index 8eb0ab207e..3b7d4d640a 100644
> --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
>  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
>
>  RDEPENDS:${PN}-build = "bash perl python3-core"
> +RDEPENDS:nativesdk-rpm += "nativesdk-file"
>
>  PACKAGE_PREPROCESS_FUNCS += "rpm_package_preprocess"
>
> --
> 2.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175969): 
https://lists.openembedded.org/g/openembedded-core/message/175969
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Alexander Kanavin]

Thanks, it's fine then.

Alex

On Mon, 16 Jan 2023 at 10:26, Chen, Qi  wrote:
>
> This is because the MAGIC var is pointing a file that does not exist. And the 
> file is provided by nativesdk-file.
>
> Some of the strace output:
> openat(AT_FDCWD, 
> "/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
>  O_RDONLY) = -1 ENOENT (No such file or directory)
> stat("/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
>  0x7ffcddb11330) = -1 ENOENT (No such file or directory)
> openat(AT_FDCWD, 
> "/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
>  O_RDONLY) = -1 ENOENT (No such file or directory)
> write(2, "file: could not find any valid m"..., 44) = 44
> exit_group(1)   = ?
> +++ exited with 1 +++
>
> Regards,
> Qi
>
> -Original Message-
> From: Alexander Kanavin 
> Sent: Monday, January 16, 2023 5:18 PM
> To: Chen, Qi 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on 
> nativesdk-file
>
> I'm not sure I understand the issue. Why isn't file from the host working 
> properly in the presence of the MAGIC env var?
>
> Alex
>
> On Mon, 16 Jan 2023 at 09:48, Chen Qi  wrote:
> >
> > For now, running `file' inside SDK errors out.
> >   file: could not find any valid magic files!
> >
> > This is because nativesdk-rpm exports MAGIC. So let's make
> > nativesdk-rpm depend on file for better user experiences.
> >
> > Signed-off-by: Chen Qi 
> > ---
> >  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > index 8eb0ab207e..3b7d4d640a 100644
> > --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> > @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
> >  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
> >
> >  RDEPENDS:${PN}-build = "bash perl python3-core"
> > +RDEPENDS:nativesdk-rpm += "nativesdk-file"
> >
> >  PACKAGE_PREPROCESS_FUNCS += "rpm_package_preprocess"
> >
> > --
> > 2.17.1
> >
> >
> > 
> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175968): 
https://lists.openembedded.org/g/openembedded-core/message/175968
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rust: Merge all rustc-source patches into rust-source.inc

[Alex Kiernan]

I guess we need to add a target RDEPENDS on gcc as its using that as
the linker (possibly interesting upstream commentary
https://github.com/rust-lang/rust/issues/71515). I'm just wondering
what happens if you have TOOLCHAIN = "clang"?

On Mon, Jan 16, 2023 at 7:00 AM Kokkonda, Sundeep
 wrote:
>
> Hello Alex,
>
> This patch fixed the https://bugzilla.yoctoproject.org/show_bug.cgi?id=14975 
> ('bitbake core-image-full-cmdline' built without any issues.)
>
> But, I tried a 'hello world' program in booted image (bitbake 
> core-image-minimal by adding 'cargo' to IMAGE_INSTALL:append) and getting 
> below error.
>
> root@qemux86-64:~/# cargo new hello
> root@qemux86-64:~/# cd hello
> root@qemux86-64:~/hello# cargo run
>Compiling hello v0.1.0 (/home/root/hello)
> error: linker `x86_64-poky-linux-gcc` not found
>   |
>   = note: No such file or directory (os error 2)
>
> error: could not compile `hello` due to previous error
>
> 
>


-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175967): 
https://lists.openembedded.org/g/openembedded-core/message/175967
Mute This Topic: https://lists.openembedded.org/mt/96110740/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Chen Qi]

This is because the MAGIC var is pointing a file that does not exist. And the 
file is provided by nativesdk-file.

Some of the strace output:
openat(AT_FDCWD, 
"/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
 O_RDONLY) = -1 ENOENT (No such file or directory)
stat("/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
 0x7ffcddb11330) = -1 ENOENT (No such file or directory)
openat(AT_FDCWD, 
"/buildarea2/chenqi/builds/build-poky-sysvinit/sdkinst/sysroots/x86_64-pokysdk-linux/usr/share/misc/magic.mgc",
 O_RDONLY) = -1 ENOENT (No such file or directory)
write(2, "file: could not find any valid m"..., 44) = 44
exit_group(1)   = ?
+++ exited with 1 +++

Regards,
Qi

-Original Message-
From: Alexander Kanavin  
Sent: Monday, January 16, 2023 5:18 PM
To: Chen, Qi 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] rpm: make nativesdk-rpm rdepend on nativesdk-file

I'm not sure I understand the issue. Why isn't file from the host working 
properly in the presence of the MAGIC env var?

Alex

On Mon, 16 Jan 2023 at 09:48, Chen Qi  wrote:
>
> For now, running `file' inside SDK errors out.
>   file: could not find any valid magic files!
>
> This is because nativesdk-rpm exports MAGIC. So let's make 
> nativesdk-rpm depend on file for better user experiences.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
> b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> index 8eb0ab207e..3b7d4d640a 100644
> --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
>  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
>
>  RDEPENDS:${PN}-build = "bash perl python3-core"
> +RDEPENDS:nativesdk-rpm += "nativesdk-file"
>
>  PACKAGE_PREPROCESS_FUNCS += "rpm_package_preprocess"
>
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175966): 
https://lists.openembedded.org/g/openembedded-core/message/175966
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Alexander Kanavin]

I'm not sure I understand the issue. Why isn't file from the host
working properly in the presence of the MAGIC env var?

Alex

On Mon, 16 Jan 2023 at 09:48, Chen Qi  wrote:
>
> For now, running `file' inside SDK errors out.
>   file: could not find any valid magic files!
>
> This is because nativesdk-rpm exports MAGIC. So let's
> make nativesdk-rpm depend on file for better user
> experiences.
>
> Signed-off-by: Chen Qi 
> ---
>  meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
> b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> index 8eb0ab207e..3b7d4d640a 100644
> --- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> +++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
> @@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
>  FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
>
>  RDEPENDS:${PN}-build = "bash perl python3-core"
> +RDEPENDS:nativesdk-rpm += "nativesdk-file"
>
>  PACKAGE_PREPROCESS_FUNCS += "rpm_package_preprocess"
>
> --
> 2.17.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#175965): 
https://lists.openembedded.org/g/openembedded-core/message/175965
Mute This Topic: https://lists.openembedded.org/mt/96303256/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] nativesdk-rpm: export RPM_ETCCONFIGDIR and MAGIC in environment like RPM_CONFIGDIR

[Chen Qi]

Hi Martin,

This patch is causing a regression: running `file xxx' inside SDK errors out.
e.g.,
sdkinst [3][0] $ file environment-setup-core2-64-poky-linux
file: could not find any valid magic files!
sdkinst [3][0] $ which file
/usr/bin/file

I've sent out a patch to fix the issue: rpm: make nativesdk-rpm rdepend on 
nativesdk-file.
Not sure if there's a better solution. Could you please help review it?

Regards,
Qi


-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Martin Jansa
Sent: Friday, December 30, 2022 12:22 AM
To: openembedded-core@lists.openembedded.org
Cc: Martin Jansa 
Subject: [OE-core] [PATCH 1/2] nativesdk-rpm: export RPM_ETCCONFIGDIR and MAGIC 
in environment like RPM_CONFIGDIR

* the paths in wrapper don't work for rpmdeps which is installed in
  ${libdir}/rpm unlike other wrapped bins from ${bindir} these relative
  paths don't work there

* replace environment.d-rpm.sh with here-doc so that we can use
  OE variables

* in the end it might be better to just get rid of the wrappers at
  this point and depend on environment.d to always set right values

* the wrappers were added in:
  commit 760103cdaed3e820888d8984ec0b76cfc831d534
  Author: Ovidiu Panait 
  Date:   Fri May 25 10:48:29 2018 +0800

nativesdk-rpm: Add wrappers for nativesdk support

When installing the SDK to a non-default path, running "rpm --showrc" from 
the
sdk will produce the following error:
error: Unable to open 
/opt/windriver/wrlinux-small/10.17.41/sysroots/x86_64-wrlinuxsdk-linux/usr/lib/rpm/rpmrc
 for reading: No such file or directory.
Fix this by adding wrappers that dynamically export the RPM_CONFIGDIR,
RPM_ETCCONFIGDIR and MAGIC environment variables, pointing to the proper
sdk locations.

* the rpm.sh in environment.d a bit later:
  commit 5f16fd0bf774314c79572daf4ba7e4a8ae209ba1
  Author: hongxu 
  Date:   Wed Jul 29 01:22:06 2020 -0700

nativesdk-rpm: adjust RPM_CONFIGDIR paths dynamically

While installing/extracting SDK to a non-default dir(not /opt),
run rpm failed:
$ python3 -c "import rpm"
|error: Unable to open /opt/windriver/wrlinux-graphics/20.31/sysroots/
x86_64-wrlinuxsdk-linux/usr/lib/rpm/rpmrc for reading: No such file or
directory.

This patch adds a flexible way to configure RPM_CONFIGDIR in SDK.

Signed-off-by: Martin Jansa 
---
 .../rpm/files/environment.d-rpm.sh |  1 -
 meta/recipes-devtools/rpm/rpm_4.18.0.bb| 14 +-
 2 files changed, 9 insertions(+), 6 deletions(-)  delete mode 100644 
meta/recipes-devtools/rpm/files/environment.d-rpm.sh

diff --git a/meta/recipes-devtools/rpm/files/environment.d-rpm.sh 
b/meta/recipes-devtools/rpm/files/environment.d-rpm.sh
deleted file mode 100644
index 9b669a18d1..00
--- a/meta/recipes-devtools/rpm/files/environment.d-rpm.sh
+++ /dev/null
@@ -1 +0,0 @@
-export RPM_CONFIGDIR="$OECORE_NATIVE_SYSROOT/usr/lib/rpm"
diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
index 5f3986d8a3..152cab490d 100644
--- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
@@ -25,7 +25,6 @@ LICENSE = "GPL-2.0-only"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c4eec0c20c6034b9407a09945b48a43f"
 
 SRC_URI = 
"git://github.com/rpm-software-management/rpm;branch=rpm-4.18.x;protocol=https \
-   file://environment.d-rpm.sh \

file://0001-Do-not-add-an-unsatisfiable-dependency-when-building.patch \
file://0001-Do-not-read-config-files-from-HOME.patch \

file://0001-When-cross-installing-execute-package-scriptlets-wit.patch \ @@ 
-120,16 +119,21 @@ do_install:append:class-native() {
 do_install:append:class-nativesdk() {
 for tool in ${WRAPPER_TOOLS}; do
 test -x ${D}$tool && create_wrapper ${D}$tool \
-RPM_CONFIGDIR='`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('libdir'), d.getVar('bindir'))}/rpm \
+RPM_CONFIGDIR='$'{RPM_CONFIGDIR-'`dirname 
+ $''realpath`'/${@os.path.relpath(d.getVar('libdir'), 
+ d.getVar('bindir'))}/rpm} \
 RPM_ETCCONFIGDIR='$'{RPM_ETCCONFIGDIR-'`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('sysconfdir'), 
d.getVar('bindir'))}/..} \
-MAGIC='`dirname 
$''realpath`'/${@os.path.relpath(d.getVar('datadir'), 
d.getVar('bindir'))}/misc/magic.mgc \
+MAGIC=''{MAGIC-'`dirname 
+ $''realpath`'/${@os.path.relpath(d.getVar('datadir'), 
+ d.getVar('bindir'))}/misc/magic.mgc} \
 RPM_NO_CHROOT_FOR_SCRIPTS=1
 done
 
 rm -rf ${D}/var
 
-mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
-install -m 644 ${WORKDIR}/environment.d-rpm.sh 
${D}${SDKPATHNATIVE}/environment-setup.d/rpm.sh
+   mkdir -p ${D}${SDKPATHNATIVE}/environment-setup.d
+   cat <<- EOF > ${D}${SDKPATHNATIVE}/environment-setup.d/rpm.sh
+ 

[OE-core][PATCH] rpm: make nativesdk-rpm rdepend on nativesdk-file

[Chen Qi]

For now, running `file' inside SDK errors out.
  file: could not find any valid magic files!

This is because nativesdk-rpm exports MAGIC. So let's
make nativesdk-rpm depend on file for better user
experiences.

Signed-off-by: Chen Qi 
---
 meta/recipes-devtools/rpm/rpm_4.18.0.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/rpm/rpm_4.18.0.bb 
b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
index 8eb0ab207e..3b7d4d640a 100644
--- a/meta/recipes-devtools/rpm/rpm_4.18.0.bb
+++ b/meta/recipes-devtools/rpm/rpm_4.18.0.bb
@@ -188,6 +188,7 @@ PROVIDES += "python3-rpm"
 FILES:python3-rpm = "${PYTHON_SITEPACKAGES_DIR}/rpm/*"
 
 RDEPENDS:${PN}-build = "bash perl python3-core"
+RDEPENDS:nativesdk-rpm += "nativesdk-file"
 
 PACKAGE_PREPROCESS_FUNCS += "rpm_package_preprocess"
 
-- 
2.17.1


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