Hi Mauro, No. Recipe data is local to the recipe. Cheers, Quentin

Hi Damien, IMAGE_NAME variable is the one specifying the name which should be used for the final image. c.f. https://docs.yoctoproject.org/ref-manual/variables.html#term-IMAGE_NAME By default, its val

Hi Nicolas, What about using `git tag -l 3.2*` so that we don't need to maintain the list of tags? Or, maybe `git tag --contains <3.1.5 commit hash introducing sphinx doc> --contains <3.2 commit hash

Hi Randall, You cannot, you need to either not instal init-ifupdown and busybox-udhdpc or modify them to not install this file in your image. Cheers, Quentin

Hi Mauro, oe-pkgdata-util lookup-recipe qtwebkit could help. Or if you know which file you don't want in your fs and want to know which package is installing it: oe-pkgdata-util find-path '*qtwebkit*'

Hi Robert, For that particular example, I'm not entirely sure what the actual value for VAR would be. Also not sure what: VAR = "snafu" VAR_append = " more" VAR_qemux86 = "qemu" would mean for VAR. I

Hi Robert, https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-kernel/linux/linux-yocto_5.10.bb#n12 for example. This is an example of a "valid" use case (not that there are invalid ones

Hi Leon, Define what you mean by "where += would not work", I'm not sure to have enough context to answer this question. gdb/gdbserver above would be replaced with ${PN} in many/most recipes. I am not

Hi Robert, Yes, in 99% of the cases, you want VAR_append_foo and not VAR_foo_append. VAR_foo_append makes sense when you want to append to VAR_foo which is a way to override completely VAR for builds

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