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

<martin.leduc=luminator.com@...> wrote: Can you provide a little more detail about how it crashes? Also, I'm not quite clear what you mean by "works like a charm with Warrior";

Hi team, Well, I throw in the towel. But it's looks like so simple .... for me 🤣🤣. I've a function to replace the version file in /etc/version. This function is integrated into my

I have generated two yocto builds at different times while taking the same SDK and target. So is there any way to verify yocto builds so I could differentiate between them for their timestamp, date

Is there a way to set the GOVERSION for a single recipe only? At the moment I set the Golang version to 1.18 using the recipes from master (on a local dunfell branch) and set the go version in the

The commit 38e6288c7dad579518b0de2b6664f23be58889b6 has added oe-core to BBLAYERS by default, and then there will be mutliple BBFILE_COLLECTIONS and caused update.py failed to update layers (most of

All, YP M+ or high bugs which moved to a new milestone in WW31 are listed below: Priority Bug ID Short Description Changer Owner Was Became Medium+ 14800 AB-INT PTEST: libgcrypt ptest

All, The below were the owners of enhancements or bugs closed during the last week! Who Count ross.burton@... 1 mhalstead@... 1 Grand Total 2 Thanks, Stephen K. Jolley Yocto Project

All, Below is the list as of top 37 bug owners as of the end of WW31 of who have open medium or higher bugs and enhancements against YP 4.1. There are 62 possible work days left until the final

All, The triage team is starting to try and collect up and classify bugs which a newcomer to the project would be able to work on in a way which means people can find them. They're being listed on

It doesn't have anything to do with parsing. A single bitbake recipe will write multiple binary packages by splitting up its files, so each binary package it writes has its own metadata.--

Essentially I don't understand why variables like RDEPENDS require a package name conditional override such as "RDEPENDS_${PN}" while other variables, including DEPENDS, do not require this. Isn't