fails on musl [1] due to missing FNM_EXTMATCH define. There are patches to define it to 0 in oe-core in musl case. Perhaps that can fix it [1] https://errors.yoctoproject.org/Errors/Details/655765/

This is kind of promise than reality at this point. True, although I wonder if there will be a case where we wont be compatible with langdale in master Logically yes.

Isn't it a bit premature to claim langdale compatibility when we don't know what changes langdale will need? I think it makes more sense to add this at the end of cycle, not at the beginning. Regards,

Hello, My apology, I am not sure which group is working on defconfig syntax for version 3.4 Honister branch. I posted the question to Yocto list without response, let me rephrase it again: According

Post release add langdale to match core Signed-off-by: Armin Kuster <akuster808@...> --- meta-filesystems/conf/layer.conf | 2 +- meta-gnome/conf/layer.conf | 2 +-

The install target is checking for install paths on build host assuming thats where it will run too, which breaks cross builds. Add a patch to aide the install from recipe. Signed-off-by: Khem Raj

This adds a recipe for pyfanotify - a python wrapper around linux' fanotify interface. Signed-off-by: Bartosz Golaszewski <brgl@...> --- .../packagegroups/packagegroup-meta-python.bb | 1 +

Adding Ross, Richard and Steve. I'm wondering if it makes sense to consider .diff.gz (or .patch.gz) files as patches for cve-check. They basically come directly from 3rd parties and it is quite

We have such bbclass already: https://github.com/webosose/meta-webosose/blob/master/meta-webos/classes/webos_npm_env.bbclass but I didn't want to enable legacy providers globally, so I was adding it

Maybe you can try to add it into global npm class with some enabling variable. Cheers, Andrej On Tue, 2022-04-26 at 14:59 +0200, Martin Jansa wrote:

This patch is essentially defines MAXPATHLEN which no longer is problem with latest glibc or musl define MAJOR/MINOR for non-glibc case Signed-off-by: Khem Raj <raj.khem@...> Cc: Marta

Hi Marta I think this option looks best or perhaps we should drop applying debian diff entirely since debian seems to have dropped this package I think regardless of what we do with this package it

On Tue, Apr 26, 2022 at 5:12 PM Khem Raj <raj.khem@...> wrote: Thanks. Just a minor nit: Could you change commit message to 'atkmm: Allow build with wayland only' because it builds fine with

Signed-off-by: Khem Raj <raj.khem@...> Cc: Andreas Müller <schnitzeltony@...> --- meta-oe/recipes-graphics/pango/pangomm_2.46.2.bb | 3 ++- 1 file changed, 2 insertions(+), 1

Signed-off-by: Khem Raj <raj.khem@...> Cc: Andreas Müller <schnitzeltony@...> --- meta-oe/recipes-gnome/atk/atkmm-2.36_2.36.1.bb | 2 +- meta-oe/recipes-gnome/atk/atkmm_2.28.2.bb |

OK. I will look into it. Thanks. //Yi

export OPENSSL_MODULES="${STAGING_LIBDIR_NATIVE}/ossl-modules" export NODE_OPTIONS="--openssl-legacy-provider" is what I'm doing in recipes which need it now. > you should have a legacy libraries in

Hi, of course, that i working. But if you're going to use --openssl-legacy-provider, you should have a legacy libraries in library loading path already. Other option is manually set variables in

Hi, does this work correctly for you with nodejs-native? Here it fails to load legacy module: recipe-sysroot-native/usr/bin/node -p 'crypto.createHash("md4")' --openssl-legacy-provider Unable to load

Khem, Any feedback about this? From the history it looks like it was you who changed the recipe to use the .diff.gz file. Thanks in advance, Marta