Re: [OE-core][kirkstone][PATCH] rpm: Backport fix CVE-2021-35939

2024-04-25 Thread Anuj Mittal
On Tue, 2024-04-23 at 21:58 +0530, Vivek Kumbhar via lists.openembedded.org wrote: > Upstream-Status: Backport > https://github.com/rpm-software-management/rpm/commit/96ec957e281220f8e137a2d5eb23b83a6377d556 >   >

Re: [OE-core][kirkstone][PATCH] rpm: Backport fix CVE-2021-35939

2024-04-25 Thread Vivek Kumbhar via lists.openembedded.org
Okay, Will correct and send V2. Thanks, Vivek On Fri, Apr 26, 2024 at 1:29 AM Steve Sakoman wrote: > This patch caused multiple build failures both locally and on the > autobuilder. > > Here is a link to the autobuilder run: > >

Re: [OE-core] [RFC][PATCH] oeqa/runtime/cases: new image_upgrade test

2024-04-25 Thread Richard Purdie
Hi Michael, At least at a first read and without running it, this does look like a reasonable direction. I suspect that anyone else looking at this would have a lot of questions about why we'd do it this way but given the various constraints, it does make sense to me. What we do need to think

Re: [OE-core][kirkstone][PATCH] rpm: Backport fix CVE-2021-35939

2024-04-25 Thread Steve Sakoman
This patch caused multiple build failures both locally and on the autobuilder. Here is a link to the autobuilder run: https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6845 Sample error log: https://errors.yoctoproject.org/Errors/Details/763370/ Steve On Tue, Apr 23, 2024 at

Re: [OE-core] btrfs-tools-native build python error

2024-04-25 Thread Lean Sheng Tan
Hi Ross, Here is the background of this: Initially we found this issue, when we are trying to build the Arm FVP for openbmc, as you can see from the discussion here: https://gerrit.openbmc.org/c/openbmc/openbmc/+/70070/comment/4a963c24_75b11840/ So thanks to the kind help from Patrick Williams

Re: [OE-core] btrfs-tools-native build python error

2024-04-25 Thread Lean Sheng Tan
Hi Ross, Thank you for your quick response! That makes sense now. Regarding your statement: "That dependency in btrfs-tools might be actually not required, or you might want to make the recipe depend on python3-native." May I know if something has to be fixed from the meta-openembedded or generic

Re: [OE-core] btrfs-tools-native build python error

2024-04-25 Thread Ross Burton
On 25 Apr 2024, at 13:29, Sheng Lean Tan via lists.openembedded.org wrote: > > Hi, > Good day to openembedded community! > > This is my first post - hope this is the right place to ask for help > regarding a build issue, as refer from here: >

[OE-core] [RFC][PATCH] oeqa/runtime/cases: new image_upgrade test

2024-04-25 Thread Michael Opdenacker via lists.openembedded.org
From: Michael Opdenacker New oe-selftest and associated "testimage" test to check that generated package feeds can be used to update the latest image built by the Yocto Project autobuilder. Currently, only the "core-image-full-cmdline" image with IPK packages and the "poky-altcfg" distro is

Re: [OE-core] [PATCH 1/2] gcc: Oe-selftest failure analysis - fix for host key verfication & kex exchange identification failures

2024-04-25 Thread Richard Purdie
I did compare a build with this patch in it with the 5.0 rc4 test report: http://autobuilder.yocto.io/pub/non-release/20240424-25/testresults/testresult-report.txt vs http://autobuilder.yocto.io/pub/releases/yocto-5.0.rc4/testreport.txt which shows: gcc | 149932

[OE-core] btrfs-tools-native build python error

2024-04-25 Thread Sheng Lean Tan
Hi, Good day to openembedded community! This is my first post - hope this is the right place to ask for help regarding a build issue, as refer from here: https://gerrit.openbmc.org/c/openbmc/openbmc/+/71017/comment/195b742f_6cf8da09/ Currently, we saw this issue when building this on openBMC

Re: [OE-core] [PATCH 1/2] gcc: Oe-selftest failure analysis - fix for host key verfication & kex exchange identification failures

2024-04-25 Thread Richard Purdie
Hi Harish, On Thu, 2024-04-18 at 03:50 -0700, Sadineni, Harish via lists.openembedded.org wrote: > From: Harish Sadineni > > while runnig oe-selftest for gcc, testcases that need to be run on > qemu are not running due to below failures. > - Executing on ssh: mkdir -p /tmp/runtest.3549641  

Re: [OE-core] [PATCH v2 3/5] ninja: build modified version with GNU Make jobserver support

2024-04-25 Thread Alexandre Belloni via lists.openembedded.org
Hello, This patch doesn't apply on master anymore because ninja has been updated. On 04/04/2024 13:16:11+0200, Martin Hundeb?ll wrote: > Ninja doesn't (yet) support the GNU Make jobserver out of the box, but > there is a pull request adding that support[1]. Since that pull request > (and its

Re: [OE-core] Pseudo Abort due to path mismatch #pseudo #kirkstone

2024-04-25 Thread lukas . palme
Hi thanks you for the tips. I had to tell the fetcher to unpack into ${S} too: > > SRC_URI = "file://Makefile;subdir=${S} \ > file://mymodule_core.c;subdir=${S} \ > file://mymodule.h;subdir=${S} \ > file://mymodule_public.h;subdir=${S} \ > file://mymodule_remote_public.h;subdir=${S} \ > " > >

[OE-core] [kirkstone][poky][PATCH] rootfs-postcommands.bbclass: Only set DROPBEAR_RSAKEY_DIR once

2024-04-25 Thread Michael Glembotzki
If DROPBEAR_RSAKEY_DIR has already been set before, e.g. by overwriting the file dropbear.default, the line will still be appended a second time. DROPBEAR_RSAKEY_DIR="/path/to/dropbear" DROPBEAR_EXTRA_ARGS="-B" DROPBEAR_RSAKEY_DIR=/var/lib/dropbear (Backport of rev:

Re: [OE-core] [PATCH 1/1] [mesa] Update do_install as needed per upstream changes

2024-04-25 Thread Alexandre Belloni via lists.openembedded.org
This causes the following failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/4702/steps/13/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/106/builds/7874/steps/11/logs/stdio On 22/04/2024 09:39:21-0500, Joseph Mills wrote: > Signed-off-by: Joseph

Re: [OE-core][PATCH v3] libbsd: Fix conflict error when enable multilib.

2024-04-25 Thread Alexander Kanavin
On Thu, 25 Apr 2024 at 07:52, leimaohui via lists.openembedded.org wrote: > - After oe_multilib_header on cdefs.h, the path of cdefs-64.h and cdefs-32.h > in cdefs.h need to be corrected. Please reference to > https://man.archlinux.org/man/libbsd.7 for details. I looked at this in a local