[OE-core][PATCH v5] patch.py: Initialize git repo before patching

From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches with error message: Command Error: 'git rev-parse --show-toplevel' exited with 0 Output: fatal: not a git repository (or any of the parent directories): .git Fix this by

[OE-core] [hardknott][PATCH] glibc: Backport fix for CVE-2021-43396

Backport the fix for CVE-2021-43396. It is disputed that this is a security issue. (From OE-Core rev: e8de9b01c6b305b2498c5f942397a49ae2af0cde) Signed-off-by: pgowda --- .../glibc/glibc/0031-CVE-2021-43396.patch | 188 ++ meta/recipes-core/glibc/glibc_2.33.bb | 1

Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision

On Wed, Dec 01, 2021 at 04:27:44PM -0500, Bruce Ashfield wrote: > [Please note: This e-mail is from an EXTERNAL e-mail address] > > On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie > wrote: > > > > On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote: > > > By default the -dev kernel uses the

[OE-core] [PATCH] glibc: Drop patch to support/workaround prelinked apps on armv5

The usecase explained in bug #1443 works fine now a days on qemuarmv5, tested by using lltng-ust and explicitly linking in liburcu-bp.so as well, since its no more a direct dependency of liblttng-ust.so.1 Given that usecase works, unbolt this fix now. Signed-off-by: Khem Raj Cc: Mark Hatle ---

[OE-core] [PATCH] boost: Fix build on arches with no atomics

1.77 is broken on architectures which dont have lockfree atomics e.g. armv5 [1], backport relevant fixes from upstream to unbreak the build [1] https://github.com/boostorg/math/issues/673 Signed-off-by: Khem Raj --- ...th_no_atomic_int-on-the-command-line.patch | 53 ++

[OE-core] [PATCH] packagegroup-core-tools-testapps: clear GOTOOLS for riscv32

From: Kai Kang go-helloworld is not compatible with riscv32 and causes error: | ERROR: Nothing RPROVIDES 'go-helloworld' (but meta/recipes-core/packagegroups/packagegroup-core-tools-testapps.bb RDEPENDS on or otherwise requires it) | go-helloworld was skipped: Unsupported CPU

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

Actually the recipe pkgconfig_git.bb points to the freedesktop pkg-config repo, which is used by default. On Wed, Dec 1, 2021 at 3:27 PM Joel Winarske via lists.openembedded.org wrote: > Forgot the reply all, not intentional :) > > Looks like the build is using the pkgconfig flavor: >

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

Forgot the reply all, not intentional :) Looks like the build is using the pkgconfig flavor: meta/recipes-devtools/pkgconfig/pkgconfig_git.bb Perhaps I just need a PREFERRED_PROVIDER_pkgconfig ?= "pkg-config" and pkg-config recipe, then perhaps it will just work. On Wed, Dec 1, 2021 at 2:39 PM

Re: [OE-core] [RFC PATCH v2 1/2] bitbake.conf: Pad rpath and remove build ID in native binaries

On Tue, 2021-11-30 at 23:37 +0100, Jacob Kroon wrote: > Try to make sure that the RUNTIME dynamic entry size is the same for all > binaries produced with the native compiler. This is necessary in order to > produce identical binaries when using differently sized buildpaths. I've > tried using only

Re: [OE-core][PATCH v4] patch.py: Initialize git repo before patching

On Wed, 2021-12-01 at 17:12 +0100, Pavel Zhukov wrote: > From: Pavel Zhukov > > If PATCHTOOL="git" has been specified but workdir is not git repo > bitbake fails to apply the patches with error message: > Command Error: 'git rev-parse --show-toplevel' exited with 0 Output: > fatal: not a git

[OE-core][dunfell 00/40] Pull request (cover letter only)

The following changes since commit 44b1970c40e9d73f6e63fb10cdc55837a26f5921: build-appliance-image: Update to dunfell head revision (2021-11-15 15:00:44 +) are available in the Git repository at: git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

Please keep the conversation on the list. Those are two different, independently developed projects: https://gitlab.freedesktop.org/pkg-config/pkg-config https://github.com/pkgconf/pkgconf and they are not fully compatible as you have just shown. I'm not sure how pkgconf is able to decide that

Re: [OE-core] [PATCH v2 2/2] vim: set PACKAGECONFIG idiomatically

On Tue, 2021-11-30 at 13:45 -0800, Andre McCurdy wrote: > On Tue, Nov 30, 2021 at 1:20 PM Ross Burton wrote: > > > > On Tue, 30 Nov 2021 at 19:32, Andre McCurdy wrote: > > > This isn't equivalent - it will cause a change in behaviour for anyone > > > using PACKAGECONFIG += "foo" from a

Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

On Wed, 2021-12-01 at 16:33 -0500, Bruce Ashfield wrote: > On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma > wrote: > > > > This is a backport request for dunfell, while picking up only the > > skeletal support for allowing mandatory dtschema handling for > > device trees built through the

Re: [OE-core] [dunfell][PATCH 00/14] Backport mandatory dtschema handling for device trees built through the kernel.

On Wed, Dec 1, 2021 at 3:34 PM Bhupesh Sharma wrote: > > This is a backport request for dunfell, while picking up only the > skeletal support for allowing mandatory dtschema handling for > device trees built through the kernel, introduced from kernel > version 5.16 onwards. The problem with

Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision

On Wed, Dec 1, 2021 at 6:28 AM Richard Purdie wrote: > > On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote: > > By default the -dev kernel uses the "AUTOREV" to pull in the branch > > head as the revision. Some of our BSPs are based on the -dev kernel and > > we choose to nail down the kernel to

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

I'd like to see specifics though to understand the use case better. What kind of target you're on, how much space will be saved by only building the driver you need and which driver is that? If the drivers are in separate .so objects, you can simply delete the ones you don't need from

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

On Wednesday 01 December 2021 at 14:18:19 -0500, Justin Bronder wrote: > On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote: > > I'm building for a specific chip and therefore don't wish to waste time and > > electricity building and disk space on the target installing unwanted

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

On 01/12/21 16:43 +, Mike Crowe via lists.openembedded.org wrote: > I'm building for a specific chip and therefore don't wish to waste time and > electricity building and disk space on the target installing unwanted mesa > drivers. However, mesa.inc contains: > > GALLIUMDRIVERS = "swrast" >

Re: [OE-core] [PATCH] ptest-packagelists: Add missing python3-webcolors entry

On Wed, 2021-12-01 at 11:58 -0500, Bruce Ashfield wrote: > On Wed, Dec 1, 2021 at 11:28 AM Quentin Schulz > wrote: > > > > Resolves: > > > > WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports > > ptests but is not included in oe-core's ptest-packagelists.inc > >

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

Hi Alex, Thanks for responding. Just to make sure I understand, you think that I should add something like: PACKAGECONFIG[i915] = "" PACKAGECONFIG[iris] = "" PACKAGECONFIG[crocus] = "" GALLIUMDRIVERS:append = "${@bb.utils.contains('PACKAGECONFIG', 'i915', ',i915', '', d)}"

Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

On 01.12.21 18:20, Quentin Schulz wrote: Hi Konrad, On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad Weihmann wrote: I'm kind of following the argumentation in the commit message, still I see differences between the Unicode-DFS-2016 template file and the text downloadable from

Re: [OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

I think you do need to modify oe-core unfortunately, like is done for other drivers: PACKAGECONFIG[etnaviv] = "" GALLIUMDRIVERS:append ="${@bb.utils.contains('PACKAGECONFIG', 'etnaviv', ',etnaviv', '', d)}" Alex On Wed, 1 Dec 2021 at 17:44, Mike Crowe via lists.openembedded.org wrote: > I'm

Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

Hi Konrad, On Wed, Dec 01, 2021 at 06:04:36PM +0100, Konrad Weihmann wrote: > I'm kind of following the argumentation in the commit message, still I see > differences between the Unicode-DFS-2016 template file and the text > downloadable from >

Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

I'm kind of following the argumentation in the commit message, still I see differences between the Unicode-DFS-2016 template file and the text downloadable from https://www.unicode.org/license.txt. Not much, but enough to make me think, if we wouldn't instead need a Unicode-DFS-2021 file and

Re: [OE-core] [PATCH] ptest-packagelists: Add missing python3-webcolors entry

On Wed, Dec 1, 2021 at 11:28 AM Quentin Schulz wrote: > > Resolves: > > WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports ptests > but is not included in oe-core's ptest-packagelists.inc [missing-ptest] > I haven't seen the warning for this either, and I didn't even know

Re: [OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

On Wed, Dec 1, 2021 at 11:13 AM Quentin Schulz wrote: > > In addition to not being an SPDX license, Unicode license also isn't > available in any of the LICENSE_PATH available in openembedded, meaning > the following warning is printed: > > python3-idna: No generic license file exists for:

[OE-core] Correct way to set DRIDRIVERS and GALLIUMDRIVERS from mesa bbappend

I'm building for a specific chip and therefore don't wish to waste time and electricity building and disk space on the target installing unwanted mesa drivers. However, mesa.inc contains: GALLIUMDRIVERS = "swrast" GALLIUMDRIVERS:x86-x32 = "" GALLIUMDRIVERS:append:x86:class-target =

[OE-core] [PATCH] ptest-packagelists: Add missing python3-webcolors entry

Resolves: WARNING: python3-webcolors-1.11.1-r0 do_package_qa: QA Issue: supports ptests but is not included in oe-core's ptest-packagelists.inc [missing-ptest] Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- Note: Not tested meta/conf/distro/include/ptest-packagelists.inc | 1 + 1

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

Nevermind, I do now :) Alex On Wed, 1 Dec 2021 at 17:26, Alexander Kanavin wrote: > Not seeing that in v4 :) > > Alex > > On Wed, 1 Dec 2021 at 17:14, Pavel Zhukov wrote: > >> Thanks. Done in v4. >> >> -- >> Pavel >> >> >> >> 01.12.2021, 17:08, "Alexander Kanavin" : >> >> Thanks :) You can

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

Not seeing that in v4 :) Alex On Wed, 1 Dec 2021 at 17:14, Pavel Zhukov wrote: > Thanks. Done in v4. > > -- > Pavel > > > > 01.12.2021, 17:08, "Alexander Kanavin" : > > Thanks :) You can add the failure into the commit message. > > Alex > > On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov wrote: > >

[OE-core] [PATCH] README.OE-Core.md: update URLs

Update URLs to what they actually redirect to. Cc: Quentin Schulz Signed-off-by: Quentin Schulz --- README.OE-Core.md | 10 +- 1 file changed, 5 insertions(+), 5 deletions(-) diff --git a/README.OE-Core.md b/README.OE-Core.md index 521916cd4f..2f2127fb03 100644 --- a/README.OE-Core.md

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

Thanks. Done in v4. -- Pavel   01.12.2021, 17:08, "Alexander Kanavin" :Thanks :) You can add the failure into the commit message. Alex On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov wrote:without change in patch.py:ERROR: man-db-2.9.0-r1 do_patch: Applying patch

[OE-core][PATCH v4] patch.py: Initialize git repo before patching

From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches with error message: Command Error: 'git rev-parse --show-toplevel' exited with 0 Output: fatal: not a git repository (or any of the parent directories): .git Fix this by

[OE-core] [PATCH] python: python3-idna: fix non-existent Unicode license

In addition to not being an SPDX license, Unicode license also isn't available in any of the LICENSE_PATH available in openembedded, meaning the following warning is printed: python3-idna: No generic license file exists for: Unicode in any provider [license-exists] Unfortunately the license is

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

Thanks :) You can add the failure into the commit message. Alex On Wed, 1 Dec 2021 at 17:00, Pavel Zhukov wrote: > without change in patch.py: > ERROR: man-db-2.9.0-r1 do_patch: Applying patch > 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target > directory >

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

without change in patch.py:ERROR: man-db-2.9.0-r1 do_patch: Applying patch 'man_db.conf-avoid-multilib-install-file-conflict.patch' on target directory '/mnt/builds/oniroproject/builds/build-oniro-linux-st/tmp/work/core2-64-oniro-linux-musl/man-db/2.9.0-r1/man-db-2.9.0'Command Error: 'git

Re: [OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

Does the test fail without the change in lib/oepatch.py? Can you show how? Alex On Wed, 1 Dec 2021 at 15:17, Pavel Zhukov wrote: > From: Pavel Zhukov > > If PATCHTOOL="git" has been specified but workdir is not git repo > bitbake fails to apply the patches. Fix this by initializing the repo >

[OE-core][PATCH v3] patch.py: Initialize git repo before patching

From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches. Fix this by initializing the repo before patching. This allows binary git patches to be applied. Signed-off-by: Pavel Zhukov --- meta/lib/oe/patch.py|

[OE-core] [PATCH 1/2] recipetool: handle GitLab URLs like we do GitHub

GitHub URLs are automatically transformed to git: fetches, so handle GitLab URLs too. Signed-off-by: Ross Burton --- scripts/lib/recipetool/create.py | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/lib/recipetool/create.py b/scripts/lib/recipetool/create.py index

[OE-core] [PATCH 2/2] recipetool: extend curl detection when creating recipes

If a configure.ac uses LIBCURL_CHECK_CONFIG it wants curl. Signed-off-by: Ross Burton --- scripts/lib/recipetool/create_buildsys.py | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/scripts/lib/recipetool/create_buildsys.py b/scripts/lib/recipetool/create_buildsys.py index

Re: [OE-core] patch files in a directory aren't applied

Hi Max, I think you are interpreting it not entirely correctly. You are reading do_patch() description and the task would pick up all patches it finds. But SRC_URI is another thing and it is looked at during parsing time. Vyacheslav On 01.12.2021 15:26, Max Krummenacher wrote: Hello I

[OE-core] patch files in a directory aren't applied

Hello I tried to add patches by specifing a directory in SRC_URI and have bitbake appling all patch files in it without explicitely adding the individual file names in SRC_URI. According to the do_patch description [1] that should work, however for my example recipe it does not. The files in the

Re: [OE-core] [PATCH] patch.py: Initialize git repo before patching

Hi Konrad,Test (very simple one) has been added (see v2). I'm not familiar with testsuite so please excuse me if I put it into wrong place. Also I'm not sure if it's ok to keep test more general (catch all errors like I did) or I have to check for specific error message. -- Pavel   01.12.2021,

[OE-core] [meta-oe][PATCH v2] patch.py: Initialize git repo before patching

From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches. Fix this by initializing the repo before patching. This allows binary git patches to be applied. Signed-off-by: Pavel Zhukov --- meta/lib/oe/patch.py|

Re: [OE-core] [PATCH] patch.py: Initialize git repo before patching

Could you please add a test case for that to the testing suite, as I'm having issues to understand under what circumstances we are getting into such kind of situation On 01.12.21 14:19, Pavel Zhukov wrote: From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo

[OE-core] [PATCH] patch.py: Initialize git repo before patching

From: Pavel Zhukov If PATCHTOOL="git" has been specified but workdir is not git repo bitbake fails to apply the patches. Fix this by initializing the repo before patching. This allows binary git patches to be applied. Signed-off-by: Pavel Zhukov --- meta/lib/oe/patch.py | 17 +

Re: [OE-core] Yocto Project Status WW48`21

On Tue, 30 Nov 2021 at 21:40, Stephen Jolley wrote: > We continue to see a reduction in the number of patches in “Pending” > state. Many thanks to everyone who has taken the time to review patch > status and handle accordingly, particularly where they were accepted > upstream. This will

Re: [OE-core] [PATCH] linux-yocto-dev: Make -dev kernel work for a fixed revision

On Wed, 2021-12-01 at 12:39 +0800, Kevin Hao wrote: > By default the -dev kernel uses the "AUTOREV" to pull in the branch > head as the revision. Some of our BSPs are based on the -dev kernel and > we choose to nail down the kernel to a specific revision when releasing > our product by using some

[OE-core] [PATCH] openssl: fix EVP_PKEY_CTX_get_rsa_pss_saltlen() not returning a value

Backport a patch from upstream. Specifically, this fixes signature validation in trusted-firmware-a with OpenSSL 3. Signed-off-by: Ross Burton --- ...-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch | 108 ++ .../openssl/openssl_3.0.0.bb | 1 + 2 files changed, 109

Re: [OE-core] [PATCH] [master] [dunfell] [hardknott] Revert "db: update CVE_PRODUCT"

HI Steve, When do you plan to add these db CVEs in the 'meta/conf/distro/include/cve-extra-exclusions.inc' file? Thanks, Best Regards, Ranjitsinh Rathod Technical Leader | | KPIT Technologies Ltd. Cellphone: +91-84606 92403 __

[OE-core] [dunfell][PATCH 2/2] busybox: Fix for CVE-2021-42376

From: Pavel Zhukov A NULL pointer dereference in Busybox's hush applet leads to denial of service when processing a crafted shell command, due to missing validation after a \x03 delimiter character. This may be used for DoS under very rare conditions of filtered command input. Reference:

[OE-core] [dunfell][PATCH 1/2] busybox: Fix for CVE-2021-42374

From: Pavel Zhukov An out-of-bounds heap read in unlzma leads to information leak and denial of service when crafted LZMA-compressed input is decompressed. This can be triggered by any applet/format that internally supports LZMA compression. Reference:

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

You can use `${pcfiledir}/../..` within a pkg-config file to reference the install path. Unfortunately the last time I tried it when cross-compiling, the PKG_CONFIG_SYSROOT_DIR was ended up in the path as a duplicate. -Eero On Wed, 2021-12-01 at 09:36 +0100, Alexander Kanavin via

Re: [OE-core] [RFC] meson needs a pkg-config wrapper script

No, it's not that. Even if you pass PKG_CONFIG_SYSROOT_DIR to pkg-config directly, it will apply that only to --cflags and similar, but not to generic --variable. Try this: alex@alex-lx-laptop:~$ PKG_CONFIG_SYSROOT_DIR=/ pkg-config libdrm --cflags -I//usr/include/libdrm