This is not enough information. To be able to help, I need to see the complete recipe, the command you are issuing, and the complete error message that happens. You can simply publish your work in pub

I think it goes like this. In your recipe you need to install files into the root directory of the partition itself and not its mount point, e.g. strip the mnt/custom prefix. Then you need to create a

Yocto first builds its own toolchain, then uses the toolchain to build the actual software stack for the target. So the host environment can be any Linux distribution. If you can say what the other OS

Please check: https://docs.yoctoproject.org/ref-manual/classes.html#buildstats-bbclass Alex

You need to build the code outside of yocto using the toolchain provided by ubuntu. If built with yocto, your options are to run the tests under qemu usermode, or in full qemu system emulation. Alex

I think you need to inspect the ${WORKDIR} of elfutils-native in detail, particularly the build and install logs in temp/. Does elfutils ./configure get the right options, and does it end up enabling

python-compiler is an obsolete module from python 2.x era and isn't available with 3.x. You can probably remove it from the image altogether: https://python.readthedocs.io/en/v2.7.2/library/compiler.h

Note that the list of supported host distros is set only for the poky reference distro with a weak assignment, and not for oe-core or yocto as a whole. If you do your own tests, and they don't show is

On the other hand, I'm yet to hear an actual case of a broken build due to non-ECC. It's not impossible, but it seems exceedingly rare. You're far more likely to spend 100x as much time on logical err

Note that per its README, meta-virtualization has a dedicated mailing list and an irc channel, so perhaps you could ask there? https://git.yoctoproject.org/meta-virtualization/tree/README says Mailing

There are sample recipes in that layer, e.g. in recipes-demo/images. I suggest you clone it and study that and available image classes. Alex

That layer is not maintained and you should not be using it. If you want to use containers, meta-virtualization is the supported way. Alex

The schedule for upcoming releases is recorded here: https://wiki.yoctoproject.org/wiki/Releases There is no development plan as such (in the sense of a promise to implement new features and timelines

Please do notice there's a new public article by RP: https://www.linux.com/audience/maintainer-confidential-opportunities-and-challenges-of-the-ubiquitous-but-under-resourced-yocto-project/ "Maintaine

This is different to the previous error. Yocto itself does not prevent the recipe from building, but something inside the component is producing an error during configuration. One of the screenshots m

The screenshot indicates the problem originates in libimxvpuapi2 recipe. So you should get more information by running 'bitbake libimxvpuapi2'. Alex

What happens if you bitbake libimx… thingy directly? Alex

meta-raspberrypi kernel comes from https://github.com/raspberrypi/linux and they stopped providing -rt options some time ago. Your options are to apply the -rt patchset to regular rpi kernel and enabl

#raspberrypi

One more thought: would shipping gcc-runtime also trigger the 'provide the source code for everything that has been linked with it' then as required by all gpl versions? The exception frees you from t

#gplv3 #yocto #llvm

Changing gcc to clang should be done for technical reasons, I would rather not give this advice to address what seems like an incomplete understanding of the licensing situation. Alex

#gplv3 #yocto #llvm