was playing with shadow and PAM stuff, and noticed this in shadow.inc: # Additional Policy files for PAM PAM_SRC_URI = "file://pam.d/chfn \ file://pam.d/chpasswd \ file://pam.d/chsh \ file://pam.d/log

first, i realize PPC is still supported, despite the official dropping of reference target MPC8315-RDB. also aware of meta-riscv layer: https://github.com/riscv despite not having a reference board. i

for a gem that is as popular as that is, i was surprised to not find a recipe for it. any recipe that is compatible as far back as morty would be fine, thanks. rday

i know, that's what i mentioned above. i suspected as much, i just wanted to point out that those two snippets are not *exactly* equivalent so someone should make sure that INIT_MANAGER usage is preci

just noticed that, given that since YP 3.0 one could select systemd as the init manager via the single variable INIT_MANAGER, which pulled in init-manager-systemd.inc: # Use systemd for system initial

looking at old YP project, wherein the ruby.bbclass class file for working with ruby gems was in a now-removed meta-oe/meta-ruby classes directory. AFAICT, these days, if you want to build ruby gems,

not sure if this really solves the underlying issue, but you can always turn those errors into warnings with: BB_DANGLINGAPPENDS_WARNONLY = "1" in your local.conf, although i'm still skeptical as to w

i recall seeing (twitter?) that there are some yocto-related online presentations associated with linaro connect, on march 24 and 25. is there somewhere a full list of these things? here's a complete

messing with docs some more, and just noticed that while all else under poky uses the variable OEROOT, the toaster executable uses OE_ROOT. works fine, of course, given that toaster is self-contained,

Quoting Mikko Rapeli <mikko.rapeli@...>: Have you verified with "bitbake -e" that the configure task was really appended to WRT the build? That's the first thing I would check. rday

i was just handed an issue that pops up under wind river linux 9 (effectively, "morty", YP 2.2), so i was hoping someone here might have some thoughts. there are a small number of ruby recipes that ar

in addition, you can always override that build-wide setting with RM_WORK_EXCLUDE if you want to keep generated work from a small set of recipes for debugging. rday

#yocto

ah, i was unaware of that list, my apologies. rday

ah, this is useful to know, and probably belongs in a YP manual somewhere; perhaps in a section called, "cool things that no one ever mentions." :-) rday

for wholly-unrelated reasons, i fell across devicetree.bbclass and was inspired to check what inherited it, and noticed that nothing in oe-core or meta-openembedded inherited it ... i had to dig aroun

whoops, my fault, i was probably on zeus branch for sake of a build, rather than looking at master. i'll look more carefully next time. rday

exactly, that's where i was going ... extending that explanation with a reference to the "rev" and "tag" options. rday

yes, yes, more obsessive-compulsive nitpickery, but YP dev tasks manual, section 3.3.5, reads: "Another way of specifying source is from an SCM. For Git repositories, you must specify SRCREV and you s

Signed-off-by: Robert P. J. Day <rpjday@...> --- diff --git a/documentation/dev-manual/dev-manual-common-tasks.xml b/documentation/dev-manual/dev-manual-common-tasks.xml index 1e6addde4..d2

just noticed in dev tasks manual in same paragraph i was whining about earlier, section 3.1.6, Note: "Also, the layer priority does not currently affect the precedence order of .conf or .bbclass files