Build already use a fake root environment using pseudo to intercept the calls so this might not be out of line here. What is the original issue you are running into ?

oe-stylize.py is still the linter of choice but as you have noted it has been lacking on certain areas and wiki should be updated to match what it produces. It does need some TLC and patches are welco

Martin you can use a tool called oe-pkgdata-util to operate on metadata for such things e.g. oe-pkgdata-util find-path "*resize2fs" would give you the names of output packages containing this binary O

there are two recipes building same files which end up in same location on target rootfs. So you should either disable the in-kernel module or not include out of kernel module recipe

before we start on that path, perhaps verify that you can run the kernel that you build with gcc 10.3 externally but manually building it and replacing it on target you can use a prebuilt toolchain fr

Yes, lightly. I found it similar to lld in many cases, only used it on native links for chromium it seems to be better at parallelization.

You can add a kernel config fragment disabling/enabling needed drivers during build and you can either build them into kernel proper or as kernel modules. If you build them as kmods then you have to a

#sdk #yocto #imx8 #kirkstone #kernel

I think this is perhaps in right direction but I would suggest IMX_PLATFORM:mx8mp-nxp-bsp = "imx8mm"

there should be a config.log file generated in the build dir of this component. Can you share that ?

Signed-off-by: Khem Raj <raj.khem@...> --- recipes-extended/libtirpc/libtirpc_%.bbappend | 14 ++++++++++++++ 1 file changed, 14 insertions(+) create mode 100644 recipes-extended/libtirpc/libtirp

Do you have ACCEPT_FSL_EULA = "1" set in config metadata e.g. local.conf or site.conf ?

I was merely replying to question about if llvm could replace it. For licensing related question I refrain because I don’t have expertise in that it’s best to consult some one who knows this stuff and

#gplv3 #yocto #llvm

You can do it to certain extent with meta-clang. Select RUNTIME = "llvm" in local.conf after including it. However, this is not going to be drop-in replacement due to some packages ( e.g. glibc ) stil

#gplv3 #yocto #llvm

Can you try installing libstdc++-dev on your build machine ?

try something like below it will remove the positional requirement. --- a/meta/recipes-core/dropbear/dropbear_2022.83.bb +++ b/meta/recipes-core/dropbear/dropbear_2022.83.bb @@ -27,7 +27,8 @@ SRC_URI[

Does your distro policy inhibit GPL-3.0 ? if so then the error is right. If your distro does not want coreutils then you may have to look through other options to get selinux working. I am not sure if

you need to install C++ runtime or perhaps its there but clang is not able to find it. If you add libcxx-native to dependencies it might fix it.

LOL :). Depends whose CI was noticed first.

oe-core switched to mickedore [1] [1] https://git.openembedded.org/openembedded-core/commit/?id=57239d66b933c4313cf331d35d13ec2d0661c38f Signed-off-by: Khem Raj <raj.khem@...> --- conf/layer.con

Try IMAGE_INSTALL_append = " usbutils-python"