Could this be considered a bug in the package_rpm.bbclass? It seems to me that if you skip files-rdeps, we might not want to be adding anything into splitpreinst. Otherwise it seems silly to tell insa

Alex is very much correct, you should not see corruption. But I think more detail is in order. If your distro repository is a "garden variety" set of image recipes and recipe overrides that pull upstr

I cannot speak for Honister, but I can speak to the higher level abstraction that is causing you issues. The solution is to copy the (right version of the) missing header file into the proper location

Just replace the word "commit" in the URL with the word patch, like so: https://git.kernel.org/pub/scm/linux/kernel/git/legion/kbd.git/patch/?id=50eae66fc21ef8e01c69a9d3c1ff3fcb0b2644a0 ..Ch:W..

On Mon, Jan 24, 2022 at 8:18 AM Jon Mason <jdmason@...> wrote: %< SNIP %< Branch Names The “master” branches on the relevant OpenEmbedded and Yocto Project git trees will be changed to an alterna

I tested the patch you posted on IRC against bitbake 1.50.0. It seems to work quite well, but I think I found two minor bugs in it. I pasted an updated patch below. In a nutshell... If you have a SRC_

Is there a recommended strategy to get do_fetch to invalidate on directory path changes in paths pointed to by file:// URLs in SRC_URI? Example: SRC_URI += "file://src;subdir=${S}" A file at src/foo/b

What problem are you attempting to solve by running a script from /etc/profile.d? ..Ch:W..

Native recipes are meant for the build machine itself to aid your build. If you are packaging something to run on a destination machine, you should be producing non-native recipe images. ..Ch:W..

#toolchain #sdk #bitbake #native

Yes. This is a version of the question - "how do I build an image that *ONLY* includes the packages I explicitly specify". This involves bypassing a lot of guards and bitbake tooling, but it can be do

#yocto

We have many recipes appended to IMAGE_INSTALL in our image recipes and it works just fine. From your description, it sounds like you could go either way. I personally prefer to keep my image recipes

#yocto

You left a few details out about how the configuration files are managed. Ideally you could just make bitbake recipes for the config files themselves. This way you can create an image recipe for each

#yocto

Very strong agreement here. My 2c is that Yocto/OE should be going in that direction even further. One of the significant benefits of the OE build method is eliminating, to the greatest extent possibl

All, Please accept my apologies in advance for the detailed submission. I think it is warranted in this case. There is something... "odd" about the GCC 10 compiler that is delivered with Hardknott. I

I got a fetcher failure on go-systemd today, which puzzled me. That recipe has not changed in ages, and the SRCPV hash is clearly visible in the repository. After looking at it closer, it seems that g

<robert.joslyn@...> wrote: Given what I have seen so far, I am wondering if that is the right place to start. To summarize: There appears to be general agreement that the idea is a good o

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it. I have often foun

The following code is an effective workaround. It must be added after the core-image is inherited. python () { pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS') result = ','.join([x for x in pseud

I was attempting an image build with Yocto Hardknott, and I ran into a chown problem during do_rootfs(). I traced it down to ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS environm

Did you try doing a cleansstate on opencv and attempting the build again? ..Ch:W..

#rocko