Hi Luka, I guess it does not hurt to be on the safe side by having them before and after the git checkout then? Since the current issue went unnoticed for months... https://lore.kernel.org/yocto-docs/

Hi Luca, Nope, not sure this is correct. I misread git clean manpage, we should have a git reset --hard and git clean -ffdx. Now the question is when those are necessary because with this patch we do

Hi all, Forgot to say this was not tested. Let's run this on the autobuilder and see if it helps? Is there a way to try without merging? Cheers, Quentin

Hi Khem, Considering that we have a branch for kirkstone already, maybe we can just switch to supporting langdale only? Cheers, Quentin

Hi Mahendra Sondagar, Considering you're using SRC_URI unconditionally, I suggest you use: . ├── swupdate │ ├── 09-swupdate-args │ ├── defconfig │ ├── sw-description │ └── swupdate.cfg └── swupdate_%.

#dunfell

Hi Kuzemko Aleksandr, Maybe this has a broken autotools script, can you try to inherit autotools-brokensep instead of autotools? c.f. https://docs.yoctoproject.org/ref-manual/classes.html#autotools-bb

Hi John, meta layer is part of openembedded-core, so please re-send to the correct mailing list following the docs here https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded Are thos

Hi Mahendra, Spurious slash at the end of the line, it tries to install ${WORKDIR}/test.sh and ${D}${bindir} to / (root directory of your build machine). Just remove it. Cheers, Quentin

#dunfell

Hi Paulo, For OpenEmbedded-core patches: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded#Backporting_fixes_to_stable_releases For meta-openembedded, I do not know how Khem deal

Hi Aleksandar, If the packages that are in both images are compiled identically, with the same options, etc... then two images. Recipes are the least invasive in terms of Yocto builds so if you can av

Hi Rudolf, Bitbake versions its shared libraries. So a binary built by Bitbake will link against libGLESv2.so.1.3 (or whatever the version of the lib actually is). This also means that the only shared

Hi Maik, This is not possible because recipe data is local to the recipe, you cannot impact a recipe from another one. The only way to have 2+ recipes doing some things in sync is by having a variable

Hi Maik, No, you would indeed need to enable those in your kernel config. Cheers, Quentin

Hi Maik, It seems you built many netfilter features/drivers as modules and not built-in in the kernel. When that is the case, you need to add the modules to your image because Yocto does not do it for

Hi, DEPENDS += "libdotconf" in speech-dispatcher recipe. This adds a dependency on libdotconf target recipe so that it makes it to the sysroot of the speech-dispatcher recipe at build time. I had a qu

Hi Marek, Anonymous functions are run during parsing before anything is built. Therefore, I don't think it'll be possible to use a python module from a recipe in an anonymous function. In order to use

Hi, This seems like a good use for overlayfs-etc IMAGE_FEATURES? c.f. https://docs.yoctoproject.org/ref-manual/features.html#image-features See https://docs.yoctoproject.org/ref-manual/classes.html#ov

#zeus #yocto

Hi Senthamilarasi.M, It is not possible to modify a recipe from another recipe. Meaning you cannot decide which config file to use for the kernel from the image recipe. You have however two options: -

Hi Rashmi, You only need to add ;protocol=https to your SRC_URI which starts with git://. git:// in SRC_URI is NOT the protocol used to download the sources, it is the way Bitbake knows which fetcher

Hi Richard, Michael, Some warnings are actually valid. Such is the case for the one that warranted https://git.yoctoproject.org/yocto-docs/commit/?id=9a797dedf6708da3e7ce789c5c8735e5d891cde4. The issu