Splits out the three variants of the rock-pi-4 (A, B & C) into their own machines. Unfortunately, it is not possible to have a single machine that works for all three, as there isn't any known ways fo

Ya, we can keep the old machine around for the old kernels

Ya, I saw that. We should probably remove the .patch file also.

Upstream OE Core has moved to Kernel 5.10 which fixed this problem, so remove the patch for 5.8 Signed-off-by: Joshua Watt <JPEWhacker@...> --- ...-resolve-supply-after-creating-regul.patch | 53

Splits out the three variants of the rock-pi-4 (A, B & C) into their own machines. Unfortunately, it is not possible to have a single machine that works for all three, as there isn't any known ways fo

When I use `linux-yocto-dev` as the kernel provider, it works just fine (in fact, I can't seem to find the commit that *fixes* the problem there....), so I think 5.10 will be OK? Is there something el

Fixes the serial port output stopping mid way through the boot process by reverting the kernel commit that caused it. Signed-off-by: Joshua Watt <JPEWhacker@...> --- ...-resolve-supply-after-cre

This means the recipe is having host contamination (where the UID of the user doing the build is leaking into the file system).

AFAIK, there is no way to replace a do_install_append from another .bbappend; you'll have to modify the original.

#yocto

Any update on this? FWIW, I think with something this old it's probably best to keep the -fcommon behavior rather than try to patch around it.

Correct. I don't remember exactly, but there was no combination of "-fno-common" and the patch that worked for both native and target cases. The only way I could get it to work for both was without th

The patch from f9761c0 ("gnupg: Make it build with GCC 10 (which uses -fno-common by default)") doesn't work in all cases, such as when building gnupg-native. Instead of trying to patch around it, re-

No. It works in all cases if I remove the patch and use "-fcommon" though. Oddly enough, in my build having the patch caused the target recipe to fail one way, and not having it caused it to fail anot

With this patch applied, I get the following errors when using the latest master branches: | ../mpi/libmpi.a(mpiutil.o): In function `mpi_alloc_limb_space': | mpiutil.c:(.text+0x84): undefined referen

Thanks. I figured that was the case. This is testing on the AB.

Does this enable it for the i686 toolchain also? Does that make sense?

Thanks! Can you add this to core-image-mingw-sdktest to test it doesn't regress? Bonus points for writing a runtime test for it if there isn't one already

Ah, right; you jogged my memory :) Structured logging still co-exists with the debug_domains, so it's not the *only* way the core speicfies logging messages. The main reason for this is that we still

The newer log handling uses Python's structure logging configuration [1], so you should be able to use whatever capabilities it has (including logging different domains/levels to a separate file). In

You can't include IMAGE_BASENAME in SDKPATH because it's not known at the time recipe are built; it's only defined when the final image is created. I'm guessing that's the source of your error. For re