Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues

At least seems that GCC 10.2 is not the cause of the problem for my cannelloni recipe issue: https://github.com/mguentner/cannelloni/issues/35 The same error repeats itself with GCC 11.2 (in hardknott). The issue is most probably optimizing GCC switches and Include paths in further cannelloni

Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues

On Thu, 2021-06-24 at 21:48 -0700, Chuck Wolber wrote: > All, > > Please accept my apologies in advance for the detailed submission. I think  > it is warranted in this case. > > There is something... "odd" about the GCC 10 compiler that is delivered with  > Hardknott. I am still chasing it down,

Re: [yocto] [OE-core] Hardknott (GCC10) Compiler Issues

> The target system should be independent of buildtools version and the target > system should also be binary reproducible so if that were changing through > changing buildtools tarball, that would be worrying in itself. Even better, the rootfs built by YOCTO could be used, but anyone can build

[yocto] [meta-rockchip][PATCH 3/3] wic/wks cleanup

By exporting a couple more variables the wks file for every rockchip device can be built from one template instead of having separate wks files for each board and platform. The following BSP variables were checked before and after this change to make sure they remained valid/sensible: - WKS_FILE

[yocto] [meta-rockchip][PATCH 1/3] conf/machine/include/nanopi-m4.inc: add full include path

Specify the full include path to the rk3399.inc file. Signed-off-by: Trevor Woerner --- conf/machine/include/nanopi-m4.inc | 2 +- 1 file changed, 1 insertion(+), 1 deletion(-) diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc index 7ca91db..b5251a1 100644

[yocto] [meta-rockchip][PATCH 2/3] IMAGE_FSTYPES: remove ext4

The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be automatically generated in cases where it is needed. Signed-off-by: Trevor Woerner --- conf/machine/include/rockchip-defaults.inc | 1 - 1 file changed, 1 deletion(-) diff --git

Re: [yocto] [meta-rockchip][PATCH] conf/machine/include/rockchip-wic.inc: create

On Fri 2021-06-25 @ 09:54:46 AM, Trevor Woerner via lists.yoctoproject.org wrote: > Create a conf/machine/include/rockchip-wic.inc file to contain all the common > wic/wks things for easy inclusion by any MACHINEs that use wic for their image > creation. > > NOTE: the wic image type of rock-pi-e

[yocto] Current high bug count owners for Yocto Project 3.4

All, Below is the list as of top 50 bug owners as of the end of WW26 of who have open medium or higher bugs and enhancements against YP 3.4. There are 86 possible work days left until the final release candidates for YP 3.4 needs to be released. Who Count richard.pur...@linuxfoundation.org

[yocto] M+ & H bugs with Milestone Movements WW26

All, YP M+ or high bugs which moved to a new milestone in WW26 are listed below: Priority Bug ID Short Description Changer Owner Was Became Medium+ 6428 Improve the ability to isolate changes that have caused a rebuild

[yocto] Enhancements/Bugs closed WW26!

All, The below were the owners of enhancements or bugs closed during the last week! Who Count richard.pur...@linuxfoundation.org 3 bruce.ashfi...@gmail.com 1 Grand Total 4 Thanks, Stephen K. Jolley Yocto Project Program Manager *Cell:(208) 244-4460 * Email:

Re: [yocto] Would COMPATIBLE_IMAGE make sense?

Hello, instead of creating a new variable (don't sure of its possible usefulness), you can use BBMASK or review dependencies between your layer PS: I did a similar answer on your stackoverflow question. On Tue, 29 Jun 2021 at 01:29, Jonas Vautherin wrote: > I was thinking about my issue

[yocto] Yocto Project Newcomer & Unassigned Bugs - Help Needed

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 the triage page under the appropriate heading:

Re: [yocto] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.9.rc1)

Hello all, This is the full report for yocto-3.1.9.rc1: https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults === Summary No high milestone defects. No new issue found. Thanks, Sangeeta > -Original Message- > From:

[yocto] Would COMPATIBLE_IMAGE make sense?

I was thinking about my issue described here [1], and discovered the variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use to stop recipes from being built for machines (/hosts) with which the recipes are not compatible". And so I wondered if it would make sense to add

[linux-yocto] [PATCH] bcm-2xxx-rpi: update kernel config for raspberrypi 4B platform

From: Meng Li Signed-off-by: Meng Li --- bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg | 3 +++ 1 file changed, 3 insertions(+) diff --git a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg b/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg index 44e984fc..13ea41c5 100644 --- a/bsp/bcm-2xxx-rpi/bcm-2xxx-rpi.cfg +++

[linux-yocto] [yocto-kernel-cache]: bcm-2xxx-rpi: update kernel config for raspberrypi 4B platform

From: Limeng Hi Bruce, Could you please help to merge this patch into yocto-kernel-cache, branch is only master? diffstat info ad below: bcm-2xxx-rpi.cfg |3 +++ 1 file changed, 3 insertions(+) thanks, Limeng -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group.

[linux-yocto][v5.10/standard/base][PATCH 1/1] iwlwifi: select MAC80211_LEDS conditionally

MAC80211_LEDS depends on LEDS_CLASS=y or LEDS_CLASS=MAC80211, add condition to enable it in iwlwifi/Kconfig to avoid below compile warning when LEDS_CLASS was set to m: WARNING: unmet direct dependencies detected for MAC80211_LEDS Depends on [n]: NET [=y] && WIRELESS [=y] && MAC80211 [=y] &&

[linux-yocto] [yocto-kernel-cache][yocto-5.4][PATCH] NFS: fix general protection fault in nfs_mount

While fuzzing the kernel with syzkaller, the following issue was triggered: Call Trace: strlen usr/src/kernel/include/linux/string.h:306 [inline] nfs_mount+0x316/0x740 usr/src/kernel/fs/nfs/mount_clnt.c:174 ? __kernel_text_address+0x12/0x40 usr/src/kernel/kernel/extable.c:95 ?

[linux-yocto][linux-yocto v5.10][PATCH] eventfd: Enlarge recursion limit to allow vhost to work

From: Zqiang 1/1 [ Author: He Zhe Email: zhe...@windriver.com Subject: eventfd: Enlarge recursion limit to allow vhost to work Date: Fri, 5 Jun 2020 16:32:18 +0800 commit 85f0a97f3aac6bb2c9549af607843644dd2ef5c7 upstream [linux-yocto] Upstream link: