FWIW, you could make the parsing order not matter (at least in thud, from a quick look, master as well). LAYERSERIES_COMPAT is resolved after all layer.conf have been parsed[1]. I do not know if it's

Hi Damienm Conceptually, no. An image recipe is a recipe. Global data is global and local data is local. A recipe (image or package) set local data only. Correct way is different distro or machine. Ob

On Wed, May 13, 2020 at 09:53:12AM -0400, Robert P. J. Day wrote: [...] > > it gets weirder ... the project i'm working with is based on morty > so that variable *would* still be relevant, but even ad

That'll teach me to check in master instead of my release of Yocto :) Quentin

Hi Robert, I'm not sure, but there might be a need to add it to SRC_DISTRIBUTE_LICENSES in openembedded-core/meta/conf/licenses.conf. Quentin

Hi Robert, You can add a license to your layer by doing the following in conf/layer.conf: LICENSE_PATH += "${LAYERDIR}/licenses" and in there you put the Unlicense file named exactly the same with the

Hi Mohamed, Why? What's the exact use case? Maybe you could play with PREMIRROS? (I've never explicitly used that variable though): https://www.yoctoproject.org/docs/latest/mega-manual/mega-manual.htm

Hi Prashanth, It depends exactly which package you're talking about. The superset of all licenses of all packages created by the gnutls recipe is GPLv3+ & LGPLv2.1+. This is also the default if the li

Salut Bastien, The `file` command on Linux (could be run on the host and not the target) will give you important info such as the architecture for which it was built. In that case, we would have detec

#yocto

Hi Marek, This seems wrong. **RDEPENDS** (dependency at runtime, on the target) on a **native** (for the host only) package does not make sense to me. I think we need more context (what are you trying

Hi Stefan, Your recipe can now be used in DEPENDS of other recipes with both "my-recipe" and "my-recipe-package". N.B.: please do not use underscore in recipe names, it can have weird consequences (be

#yocto

Hi Stefan, I think you meant PACKAGES and not PROVIDES here. If that is the case, then yes, congrats, you found the root cause :) Otherwise, I think there might be something worth debugging and maybe

#yocto

Hi Emily, You can create a patch for it. You can use devtool modify <your-recipe> and create the patch from there, you have access to the sources with that. devtool build <your-recipe> to check it bui

Hi Emily, I should have read more carefully, sorry. So... After googling a little bit I stumbled upon: https://askubuntu.com/a/486184 "The -mt suffix had been removed. The installed Boost libraries ar

Hi Emily, Ok so two things. Yes, I'd say you need python in PACKAGECONFIG for boost. However, it seems it's already part of the default value of PACKAGECONFIG, c.f. http://cgit.openembedded.org/openem

Hi JH, It was recently changed to libubootenv IIRC. Are you sure it was taken from u-boot git repo? In zeus you have both available if you have meta-swupdate layer but u-boot-fw-utils is still present

Hi Kent, inherit module should usually be enough in the recipe AFAICT. There might be some fixes to do in Makefiles but nothing crazy. c.f. https://www.yoctoproject.org/docs/current/mega-manual/mega-m

Hi Dmitri, I've had this before with a vendor layer. The culprit was the distro having some weird USERADDEXTENSION messing up with everything. How we found out what it was was by uncommenting: https:/

Hi JH, None. Or all of them, depends on how one sees it. You just create a directory in do_install of a recipe. You then make sure this directory is part of a package by checking it's in one of the re

Hi Philip, *Very* quick and vague answer as it's not something I'm doing right now. I can only give hints to where to look next. Have you had a look at INHERIT += "rm_work"? Should get rid of most of

#yocto