Yes! We have a patch under review for kirkstone: https://lists.openembedded.org/g/openembedded-core/message/168636 I think Richard is hoping someone will see if that also will work on master and if

The autotest change allows for the list of targets to be built to be larger. Add more targets to increase the build coverage of CI. Unfortunately, there are some platforms that do not build

Trivial change to move stm32mp157c-dk2 to its alphabetical location. This is relevant because it aligns the file to match the order on the gilab pipeline entry. Signed-off-by: Jon Mason

Warnings are being seen in gitlab of WARNING - Falling back to file-relative addressing of local include "base.yml" WARNING - Update your layer to repo-relative addressing to avoid this warning

From: Peter Hoyes <Peter.Hoyes@...> When TESTIMAGE_AUTO is enabled, the do_testimage task is inserted after do_image_complete and before do_build so that the test suites automatically run as part

newlib fails to compile for nios2 architecture. Work around this by using glibc instead. Signed-off-by: Jon Mason <jon.mason@...> Signed-off-by: Naveen Saini <naveen.kumar.saini@...> ---

From: Peter Hoyes <Peter.Hoyes@...> Now that TESTIMAGE_AUTO is available for Zephyr builds, enable it in ci/testimage.yml and remove the redundant build_and_test base configuration. Remove

Mostly stolen from meta-arm NOTE: this differs from upstream in that the kirkstone branch is being used instead of the master branch in ci/base.yml Signed-off-by: Jon Mason

Kirkstone was broken for meta-zephyr for weeks, but no one noticed because Gitlab CI is only running on master. Backport the relevant patches from master so this can be more easily detected, and I'll

Hi Joshua, Everything is around the /etc/version file. I know that this file is generated automatically and this is hardcoded in Yocto. I've to check how to found a workaround on this. Sorry for

Do you mean CVE-2022-35414? Regards, Marta

If you took go recipes from master, then try building mender from master as well, by setting up a master build. If that works fine, then you need to figure out how to backport mender as a whole, or

Probably, I don't really know but when I comment the "ln -s" line, using a #, the compilation works. Only the "ln -s" lines

I wanted to do a simple test with dunfell, my system meets all the minimum requirements based on documentation, and I am running under centos7… I downloaded poky-dunfell-23.0.17, built both

Your set version function looks like it's running from the logs, so don't think your function is directly causing a problem. My guess is something else later is crashing or something else unrelated?

Hi Joshua, I've founded a second function, in the same class, using ln -s set_log_folder () { bbplain "Set var log folder BEGIN" rm -Rf ${IMAGE_ROOTFS}/var/log ln -s

Current Dev Position: YP 4.1 M3 Next Deadline: 22nd August 2022 YP 4.1 M3 Build Next Team Meetings: Bug Triage meeting Thursday August 4th 7:30 am PDT

Thanks, that seems like a good hint. Regarding the fixing: As I said it seems as this is a bug in golang itself. Correct me if I'm wrong but here is the output from building

Hi Joshua, Thank you for your quick reply. Please see the crash log in the attachment. "Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something

There's no way to build two versions of the same component, if the versions share the recipe name. You have to fix the application, or try to rename one set of the go recipes so it is separate from