[OE-core] [kirkstone][PATCH 5/5] classes: npm: Add support for the new format of the shrinkwrap file

2023-05-26 Thread belouargamohamed
From: BELOUARGA Mohamed 1 - Adapt do_configure to the new format of the shrinkwrap 2 - Remove useless function _npmsw_dependency_dict because the dictionnary is already given by npmsw:foreach_dependencies 3 - Rename arguments of callback functions Signed-off-by: BELOUARGA Mohamed --- met

[OE-core] [kirkstone][PATCH 4/5] recipetool: create: npm: Add support to handle peer dependencies

2023-05-26 Thread belouargamohamed
From: BELOUARGA Mohamed NPM changed its manner to handle peer dependencies over its versions: - Before NPM 3: NPM installs automatically peer dependencies - Between NPM 3 and 7: NPM shows a warning about peer dependencies - After NPM 3: NPM reworked its manner how to handle peer dependencies

[OE-core] [kirkstone][PATCH 3/5] recipetool: create: npm: Add support for the new format of the shrinkwrap file

2023-05-26 Thread belouargamohamed
From: BELOUARGA Mohamed The shrinkwrap file changed its format, but npm does not version this file. So we can use it properly. The actual changes make the script check if the npm package has dependencies in the actual shrinkwrap format. Signed-off-by: BELOUARGA Mohamed --- scripts/lib/recipe

[OE-core] [kirkstone][PATCH 2/5] classes: npm: Handle peer dependencies for npm packages

2023-05-26 Thread belouargamohamed
From: BELOUARGA Mohamed NPM changed its manner to handle peer dependencies over its versions: - Before NPM 3: NPM installs automatically peer dependencies - Between NPM 3 and 7: NPM shows a warning about peer dependencies - After NPM 3: NPM reworked its manner how to handle peer dependencies

[OE-core] [kirkstone][PATCH 1/5] recipetool: create: npm: Remove duplicate function to not have future conflicts

2023-05-26 Thread belouargamohamed
From: BELOUARGA Mohamed Npm packages do not have yocto friendly names. fore instance we can have names like "@example/npmPackage" npm fetcher has a function that convert these names to yocto friendly names. But in recipe tool we have an other function (duplicate). Signed-off-by: BELOUARGA Moha

[OE-core] [PATCH] selftest: wic.py respect IMAGE_LINK_NAME

2023-05-26 Thread Martin Jansa
* use IMAGE_LINK_NAME instead of hardcoding core-image-minimal-${MACHINE} assumption [YOCTO #12937] Signed-off-by: Martin Jansa --- meta/lib/oeqa/selftest/cases/wic.py | 9 + 1 file changed, 5 insertions(+), 4 deletions(-) diff --git a/meta/lib/oeqa/selftest/cases/wic.py b/meta/lib/

Re: [OE-core] [PATCH] bitbake.conf: Add -fcanon-prefix-map to DEBUG_PREFIX_MAP

2023-05-26 Thread Jacob Kroon
On 4/28/23 05:20, Khem Raj wrote: This should help canonicalize the relative paths and symlinks during cross compile, -fcanon-prefix-map is newly added in gcc-13+ [1] [1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=108464#c8 Signed-off-by: Khem Raj --- meta/conf/bitbake.conf | 3 ++- 1 file

Re: [OE-core] [PATCH 1/2] image-artifact-names: include ${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and ${IMAGE_LINK_NAME}

2023-05-26 Thread Martin Jansa
On Fri, May 26, 2023 at 8:09 PM Alexandre Belloni < alexandre.bell...@bootlin.com> wrote: > Hello, > > The series causes oe-selftest failures: > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5254/steps/14/logs/stdio > > https://autobuilder.yoctoproject.org/typhoon/#/builder

Re: [OE-core] [PATCH] gcc: Upgrade to 13.1.1

2023-05-26 Thread Martin Jansa
I was using the same change with locally built uninative-tarball ( https://git.openembedded.org/openembedded-core-contrib/log/?h=jansa/master-uninative-3.9-gcc-13) since yesterday and can confirm that selftest passes (except test_gpt_partition_name which was expected and test_testimage_virgl_gtk_sd

[OE-core] [PATCH] gcc: Upgrade to 13.1.1

2023-05-26 Thread Khem Raj
Some distros e.g. gentoo have latest on gcc-13 branch and we have a situation where libstdc++ ABI is changed between 13.1 and 13.2 so official 13.1 release based uninative will no longer work on these distros, therefore switch to a snapshot that includes [1] which fixes it [1] https://gcc.gnu.org/

[OE-core][kirkstone][PATCH 1/4] kernel-devicetree: allow specification of dtb directory

2023-05-26 Thread Randolph Sapp via lists.openembedded.org
From: Randolph Sapp Fedora/Redhat and Arch are somewhat standardized on their dtb directory structure. Let's add some flags to configure yocto to mimic that behavior. Add the following variables to the kernel class: - KERNEL_DTBDEST (controls the destination directory for dtbs) -

[OE-core][kirkstone][PATCH 4/4] kernel-devicetree: recursively search for dtbs

2023-05-26 Thread Randolph Sapp via lists.openembedded.org
From: Randolph Sapp Upstream's dtb directory structure has no real standard. They just tend to idle around the 2/3 directory depth. Recursively search for the dtb/dtbo files instead of assuming anything. Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb directory, 2023-05-02) Sig

[OE-core][kirkstone][PATCH 3/4] package: enable recursion on file globs

2023-05-26 Thread Randolph Sapp via lists.openembedded.org
From: Randolph Sapp Enable recursion of file globs. This just allows the use of '**' in file globs to match 0 or more subdirectories, it should not make all current globs recursive [1]. [1] https://docs.python.org/3.6/library/glob.html#glob.glob Signed-off-by: Randolph Sapp Signed-off-by: Alex

[OE-core][kirkstone][PATCH 2/4] kernel-devicetree: make shell scripts posix compliant

2023-05-26 Thread Randolph Sapp via lists.openembedded.org
From: Martin Jansa Use the notation suggested by Martin Jansa to avoid a bashism. Also switch KERNEL_DTBVENDORED to the more common 0/1 notation instead of true/false. Fixes: 04ab57d200 (kernel-devicetree: allow specification of dtb directory, 2023-05-02) Signed-off-by: Martin Jansa Signed-off

[OE-core][kirkstone][PATCH 0/4] kernel-devicetree: allow specification of dtb directory

2023-05-26 Thread Randolph Sapp via lists.openembedded.org
From: Randolph Sapp Backporting all of the "kernel-devicetree: allow specification of dtb directory" series and subsequent fixes to kirkstone. This still has the same backwards compatibility originally advertised. It won't do anything to the dtb structure unless you tell it to. Let me know if yo

Re: [OE-core] gcc 13 merged, meta-arm, meta-intel and meta-virt issues

2023-05-26 Thread Jon Mason
On Fri, May 26, 2023 at 05:28:21PM +0100, Richard Purdie wrote: > I just wanted to let people know I merged gcc 13 since I think we'd got > as far as we were going to without the patches landing. I dropped the > 5.15 kernel and found ways to fix lttng-tools and glib-2.0 ptest > issues. > > This le

Re: [OE-core] cmake-native build failure on fedora38

2023-05-26 Thread Martin Jansa
I've recently upgraded by gentoo host to gcc-13.1.1_p20230520 and the just merged gcc-13.1.0 in oe-core isn't new enough for uninative again. This new snapshot started to use ABI from GCC-13.2.0 (as https://gcc.gnu.org/onlinedocs/libstdc++/manual/abi.html says: GCC 13.2.0: GLIBCXX_3.4.32, CXXABI_1

Re: [OE-core] [PATCH 1/2] image-artifact-names: include ${IMAGE_NAME_SUFFIX} directly in both ${IMAGE_NAME} and ${IMAGE_LINK_NAME}

2023-05-26 Thread Alexandre Belloni via lists.openembedded.org
Hello, The series causes oe-selftest failures: https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5254/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/127/builds/1468/steps/14/logs/stdio https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5

Re: [OE-core] gcc 13 merged, meta-arm, meta-intel and meta-virt issues

2023-05-26 Thread Martin Jansa
On Fri, May 26, 2023 at 6:28 PM Richard Purdie < richard.pur...@linuxfoundation.org> wrote: > I just wanted to let people know I merged gcc 13 since I think we'd got > as far as we were going to without the patches landing. I dropped the > 5.15 kernel and found ways to fix lttng-tools and glib-2.0

[OE-core] gcc 13 merged, meta-arm, meta-intel and meta-virt issues

2023-05-26 Thread Richard Purdie
I just wanted to let people know I merged gcc 13 since I think we'd got as far as we were going to without the patches landing. I dropped the 5.15 kernel and found ways to fix lttng-tools and glib-2.0 ptest issues. This leaves a few failures on the autobuilder in other layers: meta-arm 5.15 kerne

Re: [OE-core][PATCH] busybox: 1.36.0 -> 1.36.1

2023-05-26 Thread Khem Raj
clang also results in same error ERROR: QA Issue: busybox: ELF binary /usr/bin/busybox.nosuid has relocations in .text [textrel] see https://errors.yoctoproject.org/Errors/Details/705055/ On Thu, May 25, 2023 at 9:13 AM Alexandre Belloni via lists.openembedded.org wrote: > > Hello, > > On the a

Re: [OE-core] [PATCH] qemu: Restrict the built qemu targets

2023-05-26 Thread Alexander Kanavin
I can't agree with this. The whole point of qemu is that it can emulate any target on any other target. If you would like to trim it down, can this be configured via PACKAGECONFIG, and off by default? Alex On Fri, 26 May 2023 at 16:27, Yu, Mingli wrote: > > From: Mingli Yu > > Now the QEMU_TARG

[OE-core] [PATCH] qemu: Restrict the built qemu targets

2023-05-26 Thread Yu, Mingli
From: Mingli Yu Now the QEMU_TARGETS used to set the supported built qemu targets both for "bitbake qemu-native" and "bitbake qemu". After the qemu package installed on the target, it will take up 464M which includes not only the one matches the arch of the target but aslo all available built qe

[OE-core] [PATCH] rpm2cpio.sh: update to the last 4.x version

2023-05-26 Thread Alberto Planas via lists.openembedded.org
From: Alberto Planas openSUSE RPMs are compressing the RPM payload using zstd, that correspond to the magic ID 0x28, 0xb5, 0x2f. This patch update the script to the last version from the rpm project, and add support to this compression format, and extract the cpio payload using the "unzstd" bina

Re: [OE-core] [PATCH 1/1] rpm2cpio.sh: update to the last 4.x version

2023-05-26 Thread Michael Opdenacker via lists.openembedded.org
Hi Alberto, On 26.05.23 at 14:39, Alberto Planas via lists.openembedded.org wrote: openSUSE RPMs are compressing the RPM payload using zstd, that correspond to the magic ID 0x28, 0xb5, 0x2f. This patch update the script to the last version from the rpm project, and add support to this compressi

[OE-core] [PATCH 1/1] rpm2cpio.sh: update to the last 4.x version

2023-05-26 Thread Alberto Planas via lists.openembedded.org
openSUSE RPMs are compressing the RPM payload using zstd, that correspond to the magic ID 0x28, 0xb5, 0x2f. This patch update the script to the last version from the rpm project, and add support to this compression format, and extract the cpio payload using the "unzstd" binary. Signed-off-by: Alb

Re: [OE-core] [PATCH] fix hard-coded .so file extension

2023-05-26 Thread Etienne Cordonnier via lists.openembedded.org
Good point. I had a look at the git history of libxcrypt and at the git history of poky, and I didn't find anything producing a file "libcrypt-*.so". Maybe this was just a copy-paste mistake? Removing FILES:${PN} altogether indeed does not change the files contained in libxcrypt and libxcrypt-dev.

[OE-core] [PATCH] libxcrypt: fix hard-coded ".so" extension

2023-05-26 Thread Etienne Cordonnier via lists.openembedded.org
From: Etienne Cordonnier 2 issues: - the .so extension is hard-coded, and therefore the libxcryt package compiled with meta-darwin is empty, because the dylib files are not contained in FILES_${PN} - nothing actually produces a file libcrypt-*.so (the symlink file is libcrypt.so, without dash

[OE-core] [PATCH 1/1] rpm2cpio.sh: update to the last 4.x version

2023-05-26 Thread Alberto Planas via lists.openembedded.org
openSUSE RPMs are compressing the RPM payload using zstd, that correspond to the magic ID 0x28, 0xb5, 0x2f. This patch update the script to the last version from the rpm project, and add support to this compression format, and extract the cpio payload using the "unzstd" binary. Signed-off-by: Alb

Re: [OE-core] [PATCH v2] perf: Make built-in libtraceevent plugins cohabit with external libtraceevent

2023-05-26 Thread Max Krummenacher
On Friday, May 26, 2023, Khem Raj wrote: > This will package the plugins built by perf into kernel specific dir > under libdir, so it does not conflict with plugins from newly added > libtraceevent recipe > > Fixes > do_sdk_depends: The file /usr/lib/traceevent/plugins/plugin_cfg80211.so is instal

[OE-core][kirkstone][PATCH] curl: Correction for CVE-2023-27536

2023-05-26 Thread Sourav Kumar Pramanik
From: Omkar Patil Correction of backport link inside the patch with correct commit link as below Link: https://github.com/curl/curl/commit/cb49e67303dbafbab1cebf4086e3ec15b7d56ee5 Variable type change from long to unsigned char as per the original patch Signed-off-by: Sourav Kumar Pramanik --

Re: [OE-core] [PATCH 2/2] classes: Add new packagefeed class.

2023-05-26 Thread Alexander Kanavin
By the way, image recipes already do something like point 2 (copy only the needed packages out of global deploy into recipe's $WORKDIR, and then run an indexer only on that prior to composing the rootfs from those private feeds), so you could as well reuse that code. See create_packages_dir() in li

Re: [OE-core] [PATCH 2/2] classes: Add new packagefeed class.

2023-05-26 Thread Alexander Kanavin
On Thu, 25 May 2023 at 23:54, Charlie Johnston wrote: > I can see a couple of potential options: > > 1. Come up with a way to ensure that the do_package_index task is only run > once per bitbake invocation after all other packaging tasks. As far as I can > tell, there's not a way to enforce this