Yes, the kernel is typically provided by the BSP vendor through the BSP layer, and they define the kernel version in use. The security concerns still apply though: if there is a vulnerability in their

#yocto

The versions of libraries and tools are not independent from Yocto versions, in fact they are directly defined through oe-core metadata that is in a specific Yocto version. For examples, what version

#yocto

I'm not sure if this is distro specific. _PYTHON_SYSCONFIGDATA_NAME is set from python3native.bbclass so that native python can pick up target configuration, and if the target configuration is not the

Qemu is also used to run target binaries during build (when there is a need to generate some data files that can only be produced by running those binaries). If you see a build of qemu-native, it will

The recommended set up is to use r/w NFS between build machines, so they all contribute to the cache directly. And yes, if the inputs to the task are identical, then there should a cache hit. If you a

To me this seems like Wind River's special sauce. The CHANGELOG in meta-intel says this: Added QEMU support. ------------------- We now build several virtio drivers into the kernel by default, and hav

Is it possible to process the output directly, rather than tweak it via sed/awk shell pipelines that are very difficult to read? Alex

This allows automating its setup and execution on all autobuilder worker machines; previously there was a static setup on a dedicated machine, which wasn't great from maintenance perspective. To use:

The three debugging sections in the yocto manual should help? https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.html#platdev-gdb-remotedebug Alex

Reading recipes-devtools/run-postinsts/run-postinsts/run-postinsts and_save_postinsts_common (in rootfs.py) once more, it seems /etc/ipk-postinsts is only used if there is no package manager on the ta

The scripts to be executed are written into /etc/rpm|deb|ipk-postinsts/ and executed by meta/recipes-devtools/run-postinsts/run-postinsts/run-postinsts script (which is started on first boot as a serv

I think you might find auto upgrade helper useful: http://git.yoctoproject.org/cgit/cgit.cgi/auto-upgrade-helper/tree/README It's built on top of 'devtool upgrade' and 'devtool check-upgrade-status',

#yocto

Oh, one more thing, most of those 3rd party BSP layers can be found in the layer index: http://layers.openembedded.org/layerindex/branch/master/layers/ Alex

There is a difference between supported target architectures, and supported target machines; it's easier to talk about the latter. Oe-core layer directly supports QEMU targets (which are *not* suitabl

In some configurations this can be switched on in oe-core, and so needs to be disabled similarly to x11. Signed-off-by: Alexander Kanavin <alex.kanavin@...> --- recipes-graphics/libsdl2/libsdl2_

I think the issue is solved by this: http://git.yoctoproject.org/cgit/cgit.cgi/poky/commit/?h=master-next&id=39970f583dddf04139a039cbe04e62b7236f0481 Alex

I think python2 *recipe* requires openssl 1.1, but python2 itself will work just fine with openssl 1.0. So you only need to adjust the dependency, there are several ways to do that. Alex

#python

Adding Michael (lack of confirmtation email from bugzilla). Alex

I beg to differ! Bbappends are making it difficult to reason about what the recipe with all its appends is doing (because they destroy spatial locality and aren't easily visible), and I would actually

The kernel is still re-built from the same source, so why is this causing issues? Alex