Re: [yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

Most likely expired Let's Encrypt certificate (which salsa.debian.org where ca-certificates are hoster is using) on your builder (host OS), see e.g. for ubuntu: https://bugs.launchpad.net/ubuntu/+source/openssl/+bug/1928989 So to fix this update ca-certificates on your host distribution and then

[yocto] Dunfell - ERROR: ca-certificates-20211016-r0 do_fetch: Fetcher failure

Hi, After syncup of Yocto dunfell, I get the following error: dwatkins@carmd-ed-n11377-docker-dwatkins_apollo17:64bit build $ bitbake ca-certificates -c fetch Loading cache: 100%

Re: [yocto] Bitbake build fails because of a python function

It's hard to say if we can't replicate the issue. Check /srv/yocto/build/tmp/work/corei7-64-poky-linux/perl/5.30.1-r0/temp/log.do_package_write_rpm, it might have useful debugging info. Alex On Wed, 3 Nov 2021 at 21:45, Maksym Iliev via lists.yoctoproject.org wrote: > Hello guys. I am brand

[yocto] Bitbake build fails because of a python function

Hello guys. I am brand new to yocto and bitbake and I am looking for any help/advice/hints I can get. I have inherited someone else's code for building yocto project images, but the bitbake fails with the following error: ERROR: perl-5.30.1-r0 do_package_write_rpm: Error executing a python

Re: [yocto] how to handle third party licenses

On Wed, Nov 3, 2021 at 10:57 AM Monsees, Steven C (US) via lists.yoctoproject.org wrote: > > > Looking for the proper Yocto way to handle third party software ported to > Yocto and built into kernel… > > > > I’m not having issues when I recognize the license as a generic license. > But the

Re: [yocto] how to handle third party licenses

Hi Steven, Monsees, Steven C (US) via lists.yoctoproject.org escreveu no dia quarta, 3/11/2021 à(s) 17:57: > > > Looking for the proper Yocto way to handle third party software ported to > Yocto and built into kernel… > > > > I’m not having issues when I recognize the license as a generic

[yocto] how to handle third party licenses

Looking for the proper Yocto way to handle third party software ported to Yocto and built into kernel... I'm not having issues when I recognize the license as a generic license. But the license provided to us by the vendor is not part of the generic licenses list that you (Yocto) recognize.

[yocto] [meta-security][PATCH] recipes: Update SRC_URI branch and protocols

This patch updates SRC_URIs using git to include branch=master if no branch is set and also to use protocol=https for github urls as generated by the conversion script in OE-Core. Signed-off-by: Armin Kuster --- .../recipes-openscap/oe-scap/oe-scap_1.0.bb | 2 +-

Re: [yocto] preempt-rt

Thanks… From: yocto@lists.yoctoproject.org On Behalf Of codusnocturnus via lists.yoctoproject.org Sent: Wednesday, November 3, 2021 9:25 AM To: yocto@lists.yoctoproject.org Subject: Re: [yocto] preempt-rt External Email Alert This email has been sent from an account outside of the BAE

Re: [yocto] preempt-rt

‐‐‐ Original Message ‐‐‐ On Wednesday, November 3rd, 2021 at 6:24 AM, codusnocturnus via lists.yoctoproject.org wrote: > ‐‐‐ Original Message ‐‐‐ > On Wednesday, November 3rd, 2021 at 5:43 AM, Monsees, Steven C (US) via > lists.yoctoproject.org > wrote: > >> I have a

Re: [yocto] preempt-rt

‐‐‐ Original Message ‐‐‐ On Wednesday, November 3rd, 2021 at 5:43 AM, Monsees, Steven C (US) via lists.yoctoproject.org wrote: > I have a platform based off a aarm64 Xilinx based kernel, which is not a > compliant mainline kernel… so, I will need to go the preemp-rt patch route. > >

Re: [yocto] preempt-rt

Cannot… Generic preempt-rt patch bbappend should be enough… From: Leon Woestenberg Sent: Wednesday, November 3, 2021 8:59 AM To: Monsees, Steven C (US) Cc: yocto@lists.yoctoproject.org Subject: Re: [yocto] preempt-rt External Email Alert This email has been sent from an account outside of

Re: [yocto] [meta-selinux][dunfell][PATCH 0/3] Fix dunfell build

On Wed, Oct 27, 2021 at 10:04 AM Jason Andryuk via lists.yoctoproject.org wrote: > > meta-selinux fails to build libselinux and e2fsprogs. These patches > fix that and then removes the unused e2fsprogs overrides. > > Jason Andryuk (3): > e2fsprogs: Remove misc_create_inode.c-label_rootfs.patch

Re: [yocto] preempt-rt

Hello Steve, On Wed, 3 Nov 2021 at 13:44, Monsees, Steven C (US) via lists.yoctoproject.org wrote: > > > I have a platform based off a aarm64 Xilinx based kernel, which is not a > compliant mainline kernel… so, I will need to go the preemp-rt patch route. > Depends, no mainline kernel? Vendor

[yocto] preempt-rt

I have a platform based off a aarm64 Xilinx based kernel, which is not a compliant mainline kernel... so, I will need to go the preemp-rt patch route. Can you supply an example Yocto recipe that applies the patch, doesn't even have to be arm based... just looking for baseline I might use to

[linux-yocto][linux-yocto v5.10/standard/sdkv5.10/xlnx-soc][PATCH] arm64: zynqmp: add a new partition to protect parameters of u-boot

From: Quanyang Wang In the commit 996ca36db0e5 ("arm64: zynqmp: adjust qspi flash partition"), I adjust the partition "qspi-rootfs" to cover the address 0x1e0. But this address is used to store the parameters for u-boot v2019.2 by default. Erase this partition will corrupt parameters data.