On Wed, Dec 21, 2022 at 12:39 AM <jovanbosic95@...> wrote: %< SNIP %< 6. After I start my machine and enter firefox in command line this error occurs: no DISPLAY environment variable specified T

Sorry for the slow reply. Yes, keeping it under the recipe is the approach we use. For example... yocto └── meta-abc └── recipes-xyz └── helloworld ├── files │ ├── LICENSE │ └── src │ ├── Makefile │ └

What reasons do they give for that assertion? One size definitely does not suit all. Distro builds that coalesce code from a lot of different internal dev teams are going to have a tough time with the

It sounds like you are trying to build a runtime overlay package that omits all dependencies. If so, this might help. https://lore.kernel.org/all/CAB=6tBRryHURRgqwgwbY_H5Dbr8eUXijTEmVvarbTOTnZDBqZQ@ma

On Sun, Oct 16, 2022 at 12:13 PM <umut@...> wrote: %< SNIP %< I tried various options of tar to extract these files with different UID and GID with no success. How can I solve this issue? I think

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