Re: [yocto] os-release change - build failure #bitbake #os-release

On Sun, Jul 31, 2022 at 11:56:24PM -0700, Gangadhar N wrote: > Hi All, > I made below change in recipes-core/os-release/os-release.bbappend. It > results in build failure. Please give me pointers to resolve the issue. > I deleted build/cache and build/sstate-cache. But it didn't resolve the issue.

Re: [yocto] Re : rdepends upon non-existent task do_package_write_deb

Thanks for your valuable reply . I followed the procedure which you have mentioned i.e added *IMAGE_INSTALL:append = " go.opentelemetry.io-proto-otlp"* in local.conf file. After that I am getting this error , can you please suggest me where I need to modify . --

[yocto] nftables_0.7 not working

Hi, I added the following to our image recipe: IMAGE_INSTALL_append = " nftables" When running that image, nftables seems to be included, but we get the following error: ~# nft ../../nftables-0.7/src/netlink.c:59: Unable to initialize Netlink socket: Protocol not supported Furthermore, it's not

[yocto] error building core-image-full-cmdline image on kirkstone for powerpc 64 (meta-freescale, t1024rdb-64b machine)

Hi everyone, I get some errors when I build “core-image-full-cmdline” for t1024rdb-64b machine. I fix the error then I get another one, so I wonder if anybody has seen these errors or if meta-freescale (kirkstone) has been tested/used by someone? This is what I do: 1. clone poky kirkstone

Re: [yocto] nftables_0.7 not working

Hi Maik, On 8/1/22 14:41, Maik Vermeulen wrote: Hi, I added the following to our image recipe: IMAGE_INSTALL_append = " nftables" When running that image, nftables seems to be included, but we get the following error: ~# nft ../../nftables-0.7/src/netlink.c:59: Unable to initialize Netlink soc

Re: [yocto] nftables_0.7 not working

Hi Quentin, Thank you for your response! I added kernel-modules to the IMAGE_INSTALL_append, but it seems that the modules are still not being loaded. Is that the correct way? Also I see that CONFIG_NF_TABLES is not set (with ~# zcat /proc/config.gz | grep CONFIG_NF_ | grep TABLE) Is that expect

Re: [yocto] nftables_0.7 not working

Hi Maik, On 8/1/22 17:34, Maik Vermeulen wrote: Hi Quentin, Thank you for your response! I added kernel-modules to the IMAGE_INSTALL_append, but it seems that the modules are still not being loaded. Is that the correct way? Also I see that CONFIG_NF_TABLES is not set (with ~# zcat /proc/confi

[yocto] [meta-security][PATCH 1/2] krill: only builds on x86/x86-64 and arm64

Signed-off-by: Armin Kuster --- recipes-security/krill/krill_0.9.6.bb | 3 ++- 1 file changed, 2 insertions(+), 1 deletion(-) diff --git a/recipes-security/krill/krill_0.9.6.bb b/recipes-security/krill/krill_0.9.6.bb index c8b5b0c..fd86c4b 100644 --- a/recipes-security/krill/krill_0.9.6.bb +++

[yocto] [meta-security][PATCH 2/2] packagegroup-core-security: remove krill for some archs

Signed-off-by: Armin Kuster --- recipes-core/packagegroup/packagegroup-core-security.bb | 5 - 1 file changed, 4 insertions(+), 1 deletion(-) diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb index 821ebf6..a12a4c2

[yocto] Confused as to why runtime variables (RDEPENDS, RPROVIDES, etc) require package name overrides

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 putting the package name as a conditional after the variable pointless, since bitbake only parses t

Re: [yocto] Confused as to why runtime variables (RDEPENDS, RPROVIDES, etc) require package name overrides

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. On Mon, Aug 1, 2022 at 10:45 AM wrote: > Essentially I don't understand why variables like RDEPENDS require a

[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: https://wiki.yoctoproject.org/wiki/Bug_Triage#Newc

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

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 release candidates for YP 4.1 needs to be released. Who Count michael.opdenac...@boo

[yocto] Enhancements/Bugs closed WW31!

All, The below were the owners of enhancements or bugs closed during the last week! Who Count ross.bur...@arm.com 1 mhalst...@linuxfoundation.org 1 Grand Total 2 Thanks, Stephen K. Jolley Yocto Project Program Manager *Cell:(208) 244-4460 * Email:

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

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 intermittent failure randy.macl...@windri