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

Your company's application should be built within its _own_ bitbake recipe and then pulled into your image with an RDEPENDS entry in your image build recipe. If you do it that way, you can find the pa

On Sat, Nov 21, 2020 at 7:48 AM Robert P. J. Day <rpjday@...> wrote: %< SNIP %< pedantically speaking, since you're using "+=", you don't need those leading spaces. Indeed you are correct.

On Sat, Nov 21, 2020 at 12:21 AM Chuck Wolber <chuckwolber@...> wrote: %< SNIP %< And finally, I have adjusted to using the following pattern, and found that it has improved maintainability a gr

Both will work, although you do run the risk of accidentally globbing files that you do not mean to include, but perhaps you know your recipes well enough that that is not a factor. Personally, I find

I have bumbled into a few recipes like that as well. It caused some concern because bitbake is supposed to avoid contamination like that. You can use the ERROR_QA variable to do compile-host-path and