Actually, I found the upstream patch I backported, which you're probably better off using (same diff though). https://lore.kernel.org/patchwork/patch/773330/

I'm not sure if this is your issue, but I had a similar issue ilog2 and the disassembler and fixed it by backporting this patch. No guarantees, but perhaps it will help. --Aaron

I think you need to set SYSTEMD_AUTO_ENABLE = “disable” (actually any value other than “enable”) in your bbappend. (It looks like SYSTEMD_AUTO_ENABLE_${PN} is intended to work too, but I can’t verify

You would need to add libgpiod-dev, presumably, to get the build requirements.

Centos 8 'which' installs an alias by default: alias which='(alias; typeset -f) | /usr/bin/which --tty-only --read-alias --read-functions --show-tilde --show-dot' This comes from the which rpm, in /et

One of my most frequent annoying mistakes is to forget to run package index. It would be nice if I could INHERIT += "auto-package-index" or something like that. Is there a hook that such a class would

I'm trying to create a multi-partition image, and just ran across a difficult to track-down issue that I'm a little curious about. It's the intersection of rm_work, and needing to get to the sysroot o

I guess this should be more like: 3) cd $BUILDDIR/workspace/sources/<recipe> && git add ... && git commit ... because I don't think git works correctly from outside the repository. You actually don't

The “git commit” step is just how you tell devtool about your changes. Each commit will result in a patch file in your layer (conversely, each patch file ends up as a commit in the sources directory a

devshell is good for playing around, but I don't know of any blessed way to just have it somehow modify recipes and create patches magically. I'd be interested to hear if there is something like that.

Everything else you said makes sense to me, but why would I want to append "+git${SRCPV}" to the actual recipe? Surely I only want to append the git suffix stuff if I'm using a "latest" version, and I

Hmm, that is a very good suggestion that I hadn't thought of. I guess the only disadvantage is that PV doesn't get changed so you end up having to keep track of which "recipe_1.0.0.rpm" is the test on

Hi all, What I've done for quite a while when creating recipes for code that is under heavy development is create 2 version of the recipe. 1) recipe_1.0.0.bb (a known-stable recipe) 2) recipe_git.bb (

I’m using thud latest and trying to update the initramfs that is bundled into my kernel. For some reason, my initramfs is updated in the images directory, but I’m still getting some old version of the

As a user, I much prefer having one MESON_BUILD_TYPE variable that I can modify using the pn-operator, even if the acceptable values are a little less pretty. The alternative is a variable that I have

Hi all, My layer has a bunch of "development" recipes that contain something like: PV = "1.1.2+git${SRCPV}" SRCREV = "${AUTOREV}" DEFAULT_PREFERENCE = "-1" In these cases, my recipes have a "known goo

I'm not sure if this is the proper venue, but I'll send it here hoping for any insight. I'm developing a containerized system. Ideally the host will be somewhat minimal, and most of the functionality

Is there a place I should post this that would get more attention?

Looking through the recipes and classes, it seems that adding "tools-sdk" to the IMAGE_FEATURES of an image just adds a relatively arbitrary list of "sdk-ish" packages to the image from packagegroup-c

I think the problem is in the python-numpy_1.14.5.bb recipe. It does: RDEPENDS_${PN}_class-target_append = ... where it seems to need to be: RDEPENDS_${PN}_append_class-target = ... Note the position