Hi Stephan, Libraries and binaries are stripped of the debug symbols before adding them to the "normal" package. The version with the debug symbols are usually in the -dbg package of your recipe. You

#devtool

Hi Tomek, Because there is a misunderstanding on how _<override> works :) KERNEL_MODULE_AUTOLOAD_velismate += "A" KERNEL_MODULE_AUTOLOAD += "B" does not mean that you add A in case of velismate machin

Hi, _append in most cases require a leading space, i.e. you want: DISTRO_FEATURES_append = " pam" Let us know if that fixes it. Quentin

#yocto

Hi Damien, It is? https://git.busybox.net/busybox/tree/findutils/find.c#n206 You need to enable it in busybox config (you can use config fragments IIRC). layers.openembedded.org is your friend. For ex

Hi Ayoub, BBPATH[1] is what's used to locate bbclasses. It's defined in your conf/layer.conf. You can either make sure your layer is parsed before the one having the original systemd.bbclass (in BBLAY

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