You might be better off trying to use a container to build, but with a host that old, even that might be hard. There are several container solutions for the project, including: * crops - https://githu

I agree. I assume the change is simple enough to make that we can bring them back easily if we think it might be helpful is some scenario? Also, just to clarify, those workers will still contribute to

<trevor.gamblin@...> wrote: Merged as 52d5f76f54eac384f9480dffe96df089d9ee8f33 in OE-core

<michael.opdenacker@...> wrote: This usually happens when there is a sstate archive (.tar.zst), but no corresponding siginfo file (.tar.zst.siginfo). The sstate code assumes the siginfo file i

Michael, I noticed that the https://www.yoctoproject.org/reproducible-build-results/ website went down (it always shows "Error fetching test results"). I did a little debugging and I think that the CO

<abeltran@...> wrote: Looks like the loop is: nativesdk-clang-glue.bb:do_create_spdx -> clang_git.bb:do_create_spdx -> clang-crosssdk_git.bb:do_create_spdx -> nativesdk-clang-glue.bb:d

This is good, thanks. Is the libnsl2 also tied to some feature? Perhaps you can explain why it needs to be removed from MinGW

Yes, that's a good idea. Sinan, please make that change in meta-oe, then change this patch to remove it from PACKAGECONFIG

RIght, the "mingw32" override shouldn't affect what you do with the *target* unless your target is MinGW; I'm not sure if anyone is actually doing that, most SDKs target Linux for ARM, Linux for AArch

Are you building with "mingw32" as the target (not as the SDK), and it works there? I wonder why it only fails for the SDK build and not the target build? If that is truly the case, then yes I suppose

I had to clean these up a little bit and pushed them to master-next. Please verify that they still work for you and if not used them as a starting point and send a V4 patchset.

These 3 recipes are in meta-oe, not OE-core which means that the bbappends are going to cause a dangling appends error/warning. Please add a dynamic BBFILES pattern[1] so that these are conditionally

Apologies, this should use the :mingw32 override, since it's not *specific* to the SDK, but MinGW in general. Anyway, I fixed this up for you since I wasn't clear; this is in master-next and I'll get

All of the bbappends in meta-mingw should be using the :mingw32 override (or sdkmingw32 if it specific to just the SDK). If you found an example in the current code where that is not the case, it need

Hmm, I'm not sure why I missed this. However, why is the MinGW build producing the .a files and not all the builds? It seems like this could go in the oe-core version of the recipe (w/o the override)

AFAIK, passing arguments from a python function to a shell function is not allowed

#bitbake #yocto

It would appear that some or all of this patch is unnecessary. OE-core 166bb89f6d97495b6522786182b4f9623acd7ff4 implements part of this patch, which makes me think it's working there without any chang

I haven't, but it's on my radar to look at as it seems like it could be pretty useful. If you look into it, please share your findings!

Disables debuginfod when using MingGW. This feature brings in unbuildable dependencies and can't be used. Signed-off-by: Joshua Watt <JPEWhacker@...> --- conf/machine-sdk/include/mingw32-common.

It might be easier to manually enable the service with a symbolic link instead of using systemd.bbclass with something like: do_install() { install -Dm 755 ${D}${systemd_unitdir}/system/multi-user.tar