In local.conf, one usually wants to use _append instead of += since local.conf is parsed pretty early, += will override current values set with ?= or ??=. It might also be overridden if = is used in r

Hi Mauro, Missing ca-certificates-native somewhere in the dependency chain. I honestly thought curl-native would bring it, but does not seem so. I personally added ca-certificates-native to the DEPEND

Hi Mauro, You can't. Because recipes cannot impact other recipes. Now there's a catch, which applies to a VERY specific corner case. Let's say recip1 is a final package (recip1 recipe is in no DEPENDS

Hi Mauro, Yocto chant #1: Recipe data is local, conf data is global. In other words, you cannot modify other recipes from one recipe. Since image recipes are recipes, your PREFERRED_VERSION ni your im

Hi David, Not always. E.g. debian packages are renamed if they only have a library in it to be the name of said library. This does not happen for rpm and opkg. Note: this is a vague memory, I don't us

#yocto

Hi Steve, This overwrite the do_install task with "nothing". The ':' character is needed because do_install() {} is not syntaxically correct. However, the do_install_prepend and _append would still ap

#yocto

Hi Steve, http://cgit.openembedded.org/openembedded-core/commit/meta/recipes-connectivity/inetutils?h=zeus&id=9e13dad6ea76dd036098ef62427804e4138bf83b It's disabled by default now. You can probably re

#yocto #kernel

I'd say yes except for task-specific variables (one can do QB_OPT_APPEND_task-install for example). Make sure you expand the variable though (d.getVar('QB_OPT_APPEND', True) IIRC?) so that if QB_OPT_A

Hi Sergey, A "hack" I'm thinking about right now would be to remove those variables by hand in a python anonymous function. You want to expand the variable first, then do some python regex or however

Hi VR, I told you on StackOverflow to checkout the dunfell branch of meta-clang. Do that, and recompile again instead of cherry-picking recipes, classes, patches and whatnot. Once you've something tha

#yocto

Hi Jupiter, This should have nothing to do with a Yocto version, if your recipe is not found, it's just not found and it is usually a tell that you either put your recipe in the wrong tree layout or t

Do you have B set up somewhere in your recipe? Otherwise try ${S}/lib/libopentok.so for the source path. Quentin

#dunfell #yocto

If you go into ${WORKDIR} of your recipe (tmp/work/<arch>/<recipe name>), what is the path to libopentok.*.so? Quentin

#dunfell #yocto

Hi, S = "${WORKDIR}/libopentok_linux_llvm_arm64" This is the root directory of your archive and should be used for `S` Cheers, Quentin

#dunfell #yocto

Hi Jupiter, [...] [...] Not sure this will fly nicely (the kernel headers being older than your kernel). Otherwise ok. And here we have the winner :) You don't have a 5.10 linux-yocto recipe so obviou

Hi, So we can stop half guessing and help you can you give us the output of: bitbake -e virtual/kernel | grep -e "^PREFERRED_PROVIDER_" bitbake -e virtual/kernel | grep -e "^PREFERRED_VERSION_" bitbak

Hi Sateesh, Are you sure all layers are checked out at the same branch? (e.g. `dunfell` branch (or a branch with LAYERSERIESCOMPAT in conf/layer.conf with dunfell in it))? I suspect there was a change

Hi Andrew, MACHINE is automatically added to MACHINEOVERRIDES which in turn is automatically added to OVERRIDES. Doc patches welcome if something would benefit more or clearer explanation :) Quentin

Hi, No target named install. Add one or override do_install task since by default it "calls" the install target. [...] IIRC, gitsm in SRC_URI instead of git should handle that: https://docs.yoctoproje

#yocto #toolchain #linux

Hi Andrew, OVERRIDES is set in configuration files usually (always?). It can be either in a distro if you use DISTROOVERRIDES, in a machine if you use MACHINEOVERRIDES, and you might be able to add ma