its infact booting into a single user mode, what is your qemu launch command ? are you using runqemu helper that yocto has ?

This is the problem link. So either the sdk has provided them faulty install or they have replaced some stuff knowiingly or unknowingly or they have environment issues where their make system is findi

<rudolf.streif@...> wrote: I see a potential problem here, the soname is libGLESv2.so.2 but the dependency its complaining about is libGLESv2.so()(64bit), ( you see the missing version number ?

<rudolf.streif@...> wrote: interesting, are you adding RDEPENDS on libgles2-mesa ?

<rudolf.streif@...> wrote: some libraries do not set SONAME in them, which can trip the shlibs code. Can you check if libgles in question has SONAME encoded in its ELF header readelf -d <lib> |

look into mega manual something like this would help https://docs.yoctoproject.org/dev-manual/common-tasks.html?highlight=writing+recipe#patching-code

If it’s in-tree kernel module then you create a patch with your changes and apply it via recipe like any other recipe is going to do in metadata However you need to share specific details on errors so

#dunfell

fetcher will try to get versions of recipes during parse phase and if your recipes are using AUTOREV they will try to poke at git server for latest commit SHA are you using AUTOREV by chance ?

it is part of systemd recipe if your distro is based on systemd. In that case, you can write a bbappend where you define do_install:append() and delete it from staging area before it gets packaged

lists.yoctoproject.org <jebr=google.com@...> wrote: We dont need setting PR manually anymore. So remove it. This should be FILES:${PN} as per new syntax.

Can you try something like this INCOMPATIBLE_LICENSE:pn-foo = "GPL-3.0* LGPL-3.0*"

#bitbake #dunfell

it seems to be emitting errors due to build system configuration, and I guess you are running in a VM, so can you check if you have enough RAM assigned to VM preferably ( 16G or more ) > > >

#dunfell

Also add INSANE_SKIP:libspeechd += "dev-so"

Yes

Packageconfigs are about what you would like to build it’s still another step what you would like to bundle in your image which is what IMAGE_INSTALL does. At times this is already done because whatev

<kuzemkoyocto@...> wrote: I wonder why do you have do_stage task, it should not be defined in recipes anymore as the bbclasses should be left to handle staging sysroot creating most of times. Yo

you don't add native packages to image, native packages are for supporting cross builds of target packages to avoid build host specific issues etc. If you want opentelemetry in your image you want to

<GWilson@...> wrote: if you need it in a recipe then perhaps that maybe a good approach.

<gwilson@...> wrote: you can do it in image recipe inherit extrausers IMAGE_FEATURES:remove = "debug-tweaks" EXTRA_USERS_PARAMS += "\ useradd scribbledeedoo; \ usermod -p '$(openssl passwd -6

right, I missed that in this v3 the SRCREV is bumped too which should address the issue.