Howdy! Am 01.07.2020 um 14:05 schrieb ingemar0720@...: Please see https://www.yoctoproject.org/docs/3.1/ref-manual/ref-manual.html#var-PACKAGECONFIG Section "configuration file" Greetz

Howdy! Am 01.07.2020 um 13:04 schrieb ingemar0720@...: Exactly. If activated, then the rrdtool recipe already procides the rrdtool-perl package. The correct place to do this is your DISTRO conf

Howdy! Looks very much like you'll need to set up PACKAGECONFIG of rrdtool, then it should provide rrdtool-perl. See also: http://cgit.openembedded.org/meta-openembedded/tree/meta-oe/recipes-extended/

Howdy! Am 24.06.2020 um 07:48 schrieb Nicolas Dechesne: Yet that actually only holds true if both images share DISTRO, MACHINE and local.conf. Generally I would rather advise to look into multiconfig

Howdy! Am 10.06.2020 um 19:48 schrieb Mauro Ziliani: Maybe some script / part of the recipe is dependent on the execution time or evaluation order? The error basically tells you that your build is not

Howdy! Am 27.05.2020 um 12:06 schrieb Siddhartha V: This sounds like you actually want an ubuntu. Why not just use it, then? Beating a yocto build into shape will always just leave you wanting and com

#apt #linux #yocto

Howdy! Exactly. Nope. Whats the reason of using Yocto anyways if you are then jumping through all kinds of hoops to just make it behave like a Debian? If you want a Debian, you should probably be usin

#apt #yocto

Long story short: It does not work like this. Just because the tool has the same name and the packages have the same suffix, they are basically not related. You cannot use a debian package repository

#apt #yocto

Howdy! My vote is totally on this too! Greetz.

Howdy! No, there is not. As always: "Recipe data is local, conf data is global." (see: https://twitter.com/YoctoThe/status/1217166071519744000) So, you either have to factor out things into an include

Howdy! Image-inside-image is about the classis usecase for multiconfig builds. Either that, or make things DISTRO_FEATURE dependent, etc. Within multiconfig builds you can essentially create two compl

Howdy! Whats the rationale behind it? I can see apt being useful on the target under rare/obscure cirumstances, but in the SDK, what do you want to archieve? Greetz PS: Hiding behind "FooBar" doesn't

#apt #yocto #sdk #toolchain

Howdy! No problem at all - be it either through seperate builds, or multiconfig. Greetz

Howdy! Have fun, and feel free to return with arising questions :) Anything that works for you is a decent usecase. In terms of Yocto/OE, the line between decent and non-decent is less a technical tha

Howdy! Write a recipe and submit :) I don't think there was ever a "conscious decision" to not support a specific package for non-technical reasons. And this one doesn't also look like it has any note

Howdy! Sure, just drop a recipe for 1.37 into your custom layer. By default, the highet one gets chosen. Greetz

Hello Kent! Sorry to hear that your presumably first contact with Yocto respectively OpenEmbedded technology is being so painful. Please find some thought and comments inline. We have, by now. "close"

Howdy. If a Makefile does such _stupid_ things, then better patch it. An example of patching something like this is https://git.yoctoproject.org/cgit/cgit.cgi/poky/tree/meta/recipes-core/util-linux/ut

Howdy! Sorry, but there is no such thing. Yocto respectively OpenEmbedded technology can build a custom distribution that suits a lot of cases, but not being a drop-in replacement for general distribu

Howdy! If your recipe needs sum at build time, then it shall have DEPENDS = "coreutils-native" If it needs sum at runtime, then it shall have RDEPENDS_${PN} = "coreutils" No need to download any recip