A build flagged for QA (yocto-3.1.11.rc2) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.11.rc2 Build hash information: bitbake:

yes if you use uninative ( which is default in poky) then it should be able to share across multiple build hosts. if you preserve PR server data then you should be good. sstate can be regenerated.

Thanks for the replies, Richard. Can SSTATE_DIR be shared across build hosts with different OS's (Ubuntu 18.04, ubuntu 20.04, etc, RHEL)? Our build hosts are somewhat ephemeral. Occasionally we

Below is an accidental DM between Richard and myself. I am posting it here for others. > When setting up a shared sstate cache via NFS, do all the build hosts have > read/write access to the sstate

I also took the opportunity to correct a weird API that returns a result (or not), depending on some internal condition. Signed-off-by: Alexander Kanavin <alex@...> --- tests/utils.c | 35

The rock64 has an ARM Mali 450 MP2 GPU, therefore enable mesa's lima for accelerated, open-source graphics. Signed-off-by: Trevor Woerner <twoerner@...> ---

It looks like we'll need to do an rc2 build to pick up a patch for meta-yocto. Thanks to Denys for noticing the issue! For details

A build flagged for QA (yocto-3.1.11.rc1) was completed on the autobuilder and is available at: https://autobuilder.yocto.io/pub/releases/yocto-3.1.11.rc1 Build hash information: bitbake:

there is core-image-x11 which will be bareminimal and core-image-weston if you want to use wayland/weston based desktop. if you like XFCE for desktop then close meta-openembedded and add meta-oe and

merged thanks

Hello all, This is the full report for yocto-3.3.3.rc2: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults ======= Summary ======== No high

Dear Team, I need to build Rpi3 image with yocto which includes Desktop, so how can build the image with desktop feature, so that I can use it for browsing purpose after installing one of the

I see, are you talking about ${MLPREFIX} variable? The target itself compiles fine, all are 32-bit binaries in userspace. I have this issue only for SDK.

you should check the dependencies and ensure they are multilib safe sometimes dependencies could be hardcodes and cross the multilib boundaries accidentally >

The packages that SDK is trying to build are userspace packages and they haven't been ported for 64-bit. There are quite a few of them and short of fixing 64-bit compile issues for all of them, I am

I think since kernel is 64bit it might be building some tools and packages to support kernel builds. Is there a specific need to not build 64bit userspace completely ? > >

Bumping this question... Is there a way for me to disable building of 64-bit packages when building SDK with a multilib config? I have no use for 64-bit userspace package artifacts.

I have a python package hosted in an internal git repo that is currently configured to use Poetry and as such does not have a setup.py file. Yocto appears to expect a setup.py file (via inherit

"BSD" is ambiguous, use the precise licenses BSD-2-Clause Signed-off-by: Armin Kuster <akuster808@...> --- recipes-security/isic/isic_0.07.bb | 2 +- 1 file changed, 1 insertion(+), 1

"BSD" is ambiguous, use the precise licenses BSD-3-Clause Signed-off-by: Armin Kuster <akuster808@...> --- recipes-scanners/checksec/checksec_2.4.0.bb | 2 +- 1 file changed, 1 insertion(+), 1