Another question regarding recipe/coding style (based on actual examples I run across in existing code bases). In one vendor's layer, in file "lighttpd_1.4.%.bbappend", I read: RDEPENDS_${PN} += " \ l

currently updating lots of YP class notes, and writing a short section on "coding style", and ran across the following oddity(?) related to PACKAGECONFIG (all on master branches). i noticed in oe-core

Quoting Laurent Gauthier <laurent.gauthier@...>: I was just about to weigh in on this as I was just educated by Richard Purdie as to the (im)proper use of SSTATE_DUPWHITELIST. If two packages

Quoting "Robert P. J. Day" <rpjday@...>: Oh, wait, I think I misunderstood this variable entirely -- it's not a per-recipe variable, is it? Its value represents the combination over all rec

Never had cause to dig into SSTATE_DUPWHITELIST until now, so a couple questions. (Side Note: This variable is not listed in the YP Reference Manual variable glossary -- should it be?) Ran across this

Quoting Oliver Westermann <oliver.westermann@...>: Could it have something to do with layer priorities? Use the "bitbake-layers" utility to display where recipes are being pulled from. rday

currently have a perfectly functioning zeus-based layer with a small number of out-of-tree kernel modules which build just fine with: $ bitbake kernel-module-fubar against the stock linux-yocto (5.2)

migrating from zeus to dunfell and, suddenly, some "ndisc"-related recipes no longer build with: ERROR: Nothing PROVIDES 'coreutils-native'. the offending recipe is from meta-networking/recipes-suppor

i've seen two different wiki pages suggest each of the above ... it would be nice to be consistent. rday

based on recipe from an existing (zeus-based) project, colleague asks about a bbappend file, and whether it's appropriate that it be submitted upstream as a patch -- this example involves "pciutils" r

Colleague hands me build error wherein a Python2 recipe (grpc-python) fails to compile with: ... pkg_resources.DistributionNotFound: \ The 'wheel' distribution was not found and is required by the app

what is the simplest way to disable any use of sstate for a new build? i see bitbake has a "--no-setscene" option that would appear to do that: Do not run any setscene tasks. sstate will be ignored an

i've run across this on occasion -- using http://layers.openembedded.org/ to find a given recipe sometimes produces answers that don't actually point to the recipe (this seems to be a good entry for a

Quoting Richard Purdie <richard.purdie@...>: that actually clears things up. i'll let others higher up the food chain decide if the meta-toolchain target should be documented, or if it

Quoting Ross Burton <ross@...>: i'd assumed as much, but is there a reason that the meta-toolchain target is not mentioned at all in the SDK manual? Would that not be the right place to ment

colleague asked what should have been an easy question, but as i've never spent a lot of time digging into the intricacies of generating SDKs (i guess i will now), i didn't have an immediate answer. c

followup to yesterday's cry for help, i've built a core-image-minimal for x86_64 using "zeus" layers and, at this point, i'm simply going to start trying to bitbake and IMAGE_INSTALL_append various ru

background: trying to get ruby and a number of ruby gems migrated from "morty" to "zeus", and nothing but grief trying to compile/install ruby gems. plan A: start with standard YP layers all checked o

apparently, i and a couple other people are responsible for whipping up a bunch of python3 recipes that currently do not exist; we're going to standardize on what seems to be the most popular format -

aside from whether there is a good way to do this, this seems to be a really bad idea since recipes that inherit what they *think* is the systemd class file will be getting something different; that's