i would think start with defining a minimal image, then define other images based on that one which add more recipes. this has nothing to do with redefining the recipes, it just means defining more th

i asked about this once upon a time, so i thought i'd follow up ... given the fairly stable state of recent linux distros, is there any standard for taking advantage of what *should* be robust native

the (legacy) code base i was handed involves several sizable makefiles that were not designed to take advantage of parallelism -- apparently, they come from an environment (QNX?) where "make" does not

i wasn't blaming yocto ... that was an attempt at wry humour. or possibly irony. rday

refactoring existing (legacy) code base into more bite-sized bitbake recipes to speed up build by taking advantage of 6-core (12-thread) dell laptop ... end result is that i get so much parallelism th

starting to think about a new laptop that will, among other things, do lots of OE/YP builds, and i'll start with this as the basis for a few questions about hard drives: https://www.dell.com/en-ca/sho

you don't want the leading space. rday

#dunfell

as i recall, all of the above can be replaced by a single assignment to the INIT_MANAGER variable. rday

#dunfell

Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/conf/distro/include/maintainers.inc b/conf/distro/include/maintainers.inc index 7b82ef7..e02b903 100644 --- a/conf/distro/inclu

granted, that Q was a bit vague ... based on a suggestion of richard's, i was going to do an "audit" of OE/YP layers to see the effect of doing a particular minor cleanup, but it's not clear the requi

related to something that richard purdie mentioned on the OE list, if one wanted to do a YP-wide "cleanup" of some indeterminate form, what are the layers that would be considered mandatory to cover i

ah, now it makes sense, thanks. rday

superficially makes sense, except that a packagegroup does not really define a "package". perhaps all *recipe* files need a license but, again, it's not clear how a packagegroup license should percola

colleague wants to get into working with SDKs, and as i'm just diving into the intricacies of that myself, i'm not sure how to answser the question: "is there any reason to use the regular SDK as oppo

for the first time, i'm digging around in the docs for how to properly license various types of recipes, so a couple simple questions to start with, at least so i can make a first pass of cleaning up

for a current project (and subsequent projects), i want to define a hardware bringup image; that is, a really basic image chock-full of low-level utilities for debugging initial board bringup. this me

over the years, i've always been uncomfortable with the admittedly small number of examples in various layers i've found that append to FILESEXTRAPATHS rather than prepend, so i'm curious if there is

just noticed this is meta-virt layer, file layer.conf: # The dynamic-layers directory hosts extensions and layer-specific # modifications. # # The .bbappend and .bb files are included if the respectiv

i just noticed that both of the layers meta-secure-core and meta-security: https://github.com/jiazhang0/meta-secure-core https://git.yoctoproject.org/cgit/cgit.cgi/meta-security seem to include a good

i note that the linux-yocto repo has a nxp-s32g2xx branch: https://git.yoctoproject.org/cgit/cgit.cgi/linux-yocto/commit/?h=v5.10/standard/nxp-sdk-5.4/nxp-s32g2xx so wondering about the subsequent BSP