Hi Vishal, It looks like there is some problem with `u-boot-fw-utils` compilation. Are you using U-Boot in your system? Which target do you try to build? As you can

Signed-off-by: Naveen Saini <naveen.kumar.saini@...> --- README.txt | 4 ++-- 1 file changed, 2 insertions(+), 2 deletions(-) diff --git a/README.txt b/README.txt index 5a0ccc7..9889b01

at one point, I had ppc64le working as SDKMACHINE target as well.

Not quite true, aarch64 is supported and tested as an SDKMACHINE value. Right, this sounds like MACHINE is wanted for raspberrypi. Cheers, Richard

(re-adding list as I messed up) Am Mo., 1. Nov. 2021 um 21:45 Uhr schrieb jchludzinski <jchludzinski@...>: MACHINE = "raspberrypi3" (for example, pick your specific one

All, YP M+ or high bugs which moved to a new milestone in WW44 are listed below: Priority Bug ID Short Description Changer Owner Was Became Medium+ 12917 Warnings from nightly-multilib

All, The below were the owners of enhancements or bugs closed during the last week! Who Count randy.macleod@... 1 mickael.laventure+yocto@... 1 steve@... 1 Grand Total 3 Thanks,

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

All, Just a reminder we will hold the monthly Yocto Project Technical Meeting at 8am PST tomorrow. (11/2) Yocto Project Technical Team Meeting: We encourage people attending the meeting to

As per https://docs.yoctoproject.org/ref-manual/variables.html#term-SDKMACHINE the value isn't a target MACHINE, but a name that is present

NEWBIE question! I tried building and I get: "Specified SDKMACHINE value is not valid" pi@raspberrypi ~/p/build> bitbake core-image-minimal /usr/lib/python3/dist-packages/html5lib/_trie/_base.py:3:

The rysnc of 20,000 files (650MB) onto the nas is slow taking ~3 minutes at idle and worse at load. This is due to the number of files which is a pain point for NFS. This piece of the build is also a

By not syncing all the history is is possible to save some time/space in the checkout process since we never use this data. This reduces data from 650MB to 400MB or with the tarball, 416MB to

Signed-off-by: Richard Purdie <richard.purdie@...> --- scripts/prepare-shared-repos | 1 + 1 file changed, 1 insertion(+) diff --git a/scripts/prepare-shared-repos

Signed-off-by: Richard Purdie <richard.purdie@...> --- scripts/prepare-shared-repos | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/scripts/prepare-shared-repos

The way the canStartBuild code was written, it inserted a delay between each build starting of 2 minutes unconditionally. We only want to do this if the worker had run out of space so tweak the code

This didn't work (and wasn't merged) although I still think it is probably the correct thing to do with that code. I did some digging and the issue is that when we trigger builds, it triggers them

Unfortunately this quarantine piece is causing problems. It means that even if there is free space on the builder and always was, a maximum of one build every 2 minutes can be started. I'll probably

drop patch now included. Signed-off-by: Armin Kuster <akuster808@...> --- .../recipes-tpm2/tpm2-pkcs11/files/677.patch | 295 ------------------ ...2-pkcs11_1.6.0.bb => tpm2-pkcs11_1.7.0.bb}

Hello, Copying the docs@ mailing list. All things considered, the documentation for some other parameters explains where they can typically be set. This should definitely help people just quickly