Date   

[ANNOUNCEMENT] Yocto Project 3.4.2 (honister) is Released

Lee Chee Yang
 

Hi

We are pleased to announce the Yocto Project 3.4.2 Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/poky-e0ab08bb6a32916b457d221021e7f402ffa36b1a.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/poky-e0ab08bb6a32916b457d221021e7f402ffa36b1a.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Chee Yang Lee
chee.yang.lee@...

Yocto Project Build and Release


- --------------------------

yocto-3.4.2 Release Notes

- --------------------------

 

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: honister

Tag: yocto-3.4.2

Git Revision: e0ab08bb6a32916b457d221021e7f402ffa36b1a

Release Artefact: poky-e0ab08bb6a32916b457d221021e7f402ffa36b1a

sha: 8580dc5067ee426fe347a0d0f7a74c29ba539120bbe8438332339a9c8bce00fd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/poky-e0ab08bb6a32916b457d221021e7f402ffa36b1a.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/poky-e0ab08bb6a32916b457d221021e7f402ffa36b1a.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: honister

Tag: yocto-3.4.2

Git Revision: 418a9c4c31615a9e3e011fc2b21fb7154bc6c93a

Release Artefact: oecore-418a9c4c31615a9e3e011fc2b21fb7154bc6c93a

sha: f2ca94a5a7ec669d4c208d1729930dfc1b917846dbb2393d01d6d5856fcbc6de

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/oecore-418a9c4c31615a9e3e011fc2b21fb7154bc6c93a.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/oecore-418a9c4c31615a9e3e011fc2b21fb7154bc6c93a.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: honister

Tag: yocto-3.4.2

Git Revision: f5d761cbd5c957e4405c5d40b0c236d263c916a8

Release Artefact: meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8

sha: d4305d638ef80948584526c8ca386a8cf77933dffb8a3b8da98d26a5c40fcc11

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/meta-mingw-f5d761cbd5c957e4405c5d40b0c236d263c916a8.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: honister

Tag: yocto-3.4.2

Git Revision: f04e4369bf9dd3385165281b9fa2ed1043b0e400

Release Artefact: meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400

sha: ef8e2b1ec1fb43dbee4ff6990ac736315c7bc2d8c8e79249e1d337558657d3fe

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/meta-gplv2-f04e4369bf9dd3385165281b9fa2ed1043b0e400.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: honister

Tag: yocto-3.4.2

Git Revision: c039182c79e2ccc54fff5d7f4f266340014ca6e0

Release Artefact: bitbake-c039182c79e2ccc54fff5d7f4f266340014ca6e0

sha: bd80297f8d8aa40cbcc8a3d4e23a5223454b305350adf34cd29b5fb65c1b4c52

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.4.2/bitbake-c039182c79e2ccc54fff5d7f4f266340014ca6e0.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.4.2/bitbake-c039182c79e2ccc54fff5d7f4f266340014ca6e0.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: honister

Tag: yocto-3.4.2

Git Revision: 3061d3d62054a5c3b9e16bfce4bcd186fa7a23d2

 

 

- ---------------

Contributors

- ---------------

Alexander Kanavin

Alexandre Belloni

Anton Mikanovich

Anuj Mittal

Bruce Ashfield

Carlos Rafael Giani

Chaitanya Vadrevu

Changqing Li

Dhruva Gole

Florian Amstutz

Joshua Watt

Kai Kang

Khairul Rohaizzat Jamaluddin

Khem Raj

Konrad Weihmann

Kory Maincent

Li Wang

Marek Vasut

Markus Volk

Martin Jansa

Max Krummenacher

Michael Opdenacker

Mingli Yu

Oleksiy Obitotskyy

Pavel Zhukov

Peter Kjellerstedt

Pgowda

Quentin Schulz

Richard Purdie

Robert Yang

Ross Burton

Rudolf J Streif

Sakib Sajal

Samuli Piippo

Schmidt, Adriaan

Stefan Herbrechtsmeier

Steve Sakoman

Sundeep KOKKONDA

Teoh Jay Shen

Thomas Perrot

Tim Orling

Vyacheslav Yurkov

Yongxin Liu

pgowda

wangmy

 

- ---------------

Known Issues

- ---------------

N/A

 

- ---------------

Security Fixes

- ---------------

tiff: backport fix for CVE-2022-22844

glibc : Fix CVE-2021-3999

glibc : Fix CVE-2021-3998

glibc : Fix CVE-2022-23219

glibc : Fix CVE-2022-23218

lighttpd: backport a fix for CVE-2022-22707

speex: fix CVE-2020-23903

linux-yocto/5.10: amdgpu: updates for CVE-2021-42327

libsndfile1: fix CVE-2021-4156

xserver-xorg: whitelist two CVEs

grub2: fix CVE-2021-3981

xserver-xorg: update CVE_PRODUCT

binutils: CVE-2021-42574

gcc: Fix CVE-2021-42574

gcc: Fix CVE-2021-35465

cve-extra-exclusions: add db CVEs to exclusion list

gcc: Add CVE-2021-37322 to the list of CVEs to ignore

bind: fix CVE-2021-25219

openssh: fix CVE-2021-41617

ncurses: fix CVE-2021-39537

vim: fix CVE-2021-3968 and CVE-2021-3973

vim: fix CVE-2021-3927 and CVE-2021-3928

gmp: fix CVE-2021-43618

 

 

- ---------------

Fixes

- ---------------

build-appliance-image: Update to honister head revision

poky.conf: bump version for 3.4.2 release

libxml2: Backport python3-lxml workaround patch

core-image-sato-sdk: allocate more memory when in qemu

vim: upgrade to patch 4269

vim: update to include latest CVE fixes

expat: upgrade to 2.4.4

libusb1: correct SRC_URI

yocto-check-layer: add debug output for the layers that were found

linux-firmware: Add CLM blob to linux-firmware-bcm4373 package

linux-yocto/5.10: update to v5.10.93

icu: fix make_icudata dependencies

sstate: Improve failure to obtain archive message/handling

insane.bbclass: Correct package_qa_check_empty_dirs()

sstate: A third fix for for touching files inside pseudo

kernel: introduce python3-dtschema-wrapper

vim: upgrade to 8.2 patch 3752

bootchart2: Add missing python3-math dependency

socat: update SRC_URI

pigz: fix one failure of command "unpigz -l"

linux-yocto/5.14: update genericx86* machines to v5.14.21

linux-yocto/5.10: update genericx86* machines to v5.10.87

go: upgrade 1.16.10 -> 1.16.13

linux-yocto/5.10/cfg: add kcov feature fragment

linux-yocto/5.14: fix arm 32bit -rt warnings

oeqa/sstate: Fix allarch samesigs test

rootfs-postcommands.bbclass: Make two comments use the new variable syntax

cve-check: add lockfile to task

lib/oe/reproducible: correctly set .git location when recursively looking for git repos

epiphany: Update 40.3 -> 40.6

scripts/buildhistory-diff: drop use of distutils

scripts: Update to use exec_module() instead of load_module()

vulkan-loader: inherit pkgconfig

webkitgtk: Add reproducibility fix

openssl: Add reproducibility fix

rpm: remove tmp folder created during install

package_manager: ipk: Fix host manifest generation

bitbake: utils: Update to use exec_module() instead of load_module()

linux-yocto: add libmpc-native to DEPENDS

ref-manual: fix patch documentation

bitbake: tests/fetch: Drop gnu urls from wget connectivity test

bitbake: fetch: npm: Use temporary file for empty user config

bitbake: fetch: npm: Quote destdir in run chmod command

bitbake: process: Do not mix stderr with stdout

xserver-xorg: upgrade 1.20.13 -> 1.20.14

python3-pyelftools: Depend on debugger, pprint

linux-firmware: upgrade 20211027 -> 20211216

oeqa/selftest/bbtests: Use YP sources mirror instead of GNU

systemd: Fix systemd-journal-gateway user/groups

license.bbclass: implement ast.NodeVisitor.visit_Constant

oe/license: implement ast.NodeVisitor.visit_Constant

packagedata.py: silence a DeprecationWarning

uboot-sign: fix the concatenation when multiple U-BOOT configurations are specified

runqemu: check the qemu PID has been set before kill()ing it

selftest/devtool: Check branch in git fetch

recipetool: Set master branch only as fallback

kern-tools: bug fixes and kgit-gconfig

linux-yocto-rt/5.10: update to -rt56

linux-yocto/5.14: update to v5.14.21

python3: upgrade 3.9.7 -> 3.9.9

bitbake: lib/pyinotify.py: Remove deprecated module asyncore

updates for recent releases

libdrm: upgrade 2.4.108 -> 2.4.109

patch.py: Initialize git repo before patching

boost: Fix build on arches with no atomics

boost: allow searching for python310

recipetool: extend curl detection when creating recipes

recipetool: handle GitLab URLs like we do GitHub

README.OE-Core.md: update URLs

libtool: change the default AR_FLAGS from "cru" to "cr"

libtool: Update patchset to match those submitted upstream

scripts/checklayer/common.py: Fixed a minor grammatical error

oeqa/parselogs: Fix quoting

oeqa/utils/dump: Fix typo

systemd: update 249.6 -> 249.7

glibc: Fix i586/c3 support

wic: support rootdev identified by partition label

buildhistory: Fix srcrevs output

classes/crate-fetch: Ensure crate fetcher is available

rootfs-postcommands: update systemd_create_users

classes/meson: Add optional rust definitions

rust-cross: Replace TARGET_ARCH with TUNE_PKGARCH

maintainers.inc: fix up rust-cross entry

rust-cross: Fix directory not deleted for race glibc vs. musl

wic: use shutil.which

bitbake: data_smart.py: Skip old override syntax checking for anonymous functions

documentation: conf.py: fix version of bitbake objects.inv

updates for release 3.3.4

 


[meta-security][PATCH] layer.conf: Update to use kirkstone

Armin Kuster
 

Update the layers to use the kirkstone namespace. No compatibility is made
for honister due to the variable renaming.

Signed-off-by: Armin Kuster <akuster808@...>
---
conf/layer.conf | 2 +-
meta-hardening/conf/layer.conf | 2 +-
meta-integrity/conf/layer.conf | 2 +-
meta-parsec/conf/layer.conf | 2 +-
meta-security-compliance/conf/layer.conf | 2 +-
meta-security-isafw/conf/layer.conf | 2 +-
meta-tpm/conf/layer.conf | 2 +-
7 files changed, 7 insertions(+), 7 deletions(-)

diff --git a/conf/layer.conf b/conf/layer.conf
index ad9da56..1f83593 100644
--- a/conf/layer.conf
+++ b/conf/layer.conf
@@ -9,7 +9,7 @@ BBFILE_COLLECTIONS += "security"
BBFILE_PATTERN_security = "^${LAYERDIR}/"
BBFILE_PRIORITY_security = "8"

-LAYERSERIES_COMPAT_security = "honister"
+LAYERSERIES_COMPAT_security = "kirkstone"

LAYERDEPENDS_security = "core openembedded-layer perl-layer networking-layer meta-python"

diff --git a/meta-hardening/conf/layer.conf b/meta-hardening/conf/layer.conf
index 1cd6f4f..bc33d97 100644
--- a/meta-hardening/conf/layer.conf
+++ b/meta-hardening/conf/layer.conf
@@ -8,6 +8,6 @@ BBFILE_COLLECTIONS += "harden-layer"
BBFILE_PATTERN_harden-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_harden-layer = "10"

-LAYERSERIES_COMPAT_harden-layer = "honister"
+LAYERSERIES_COMPAT_harden-layer = "kirkstone"

LAYERDEPENDS_harden-layer = "core openembedded-layer"
diff --git a/meta-integrity/conf/layer.conf b/meta-integrity/conf/layer.conf
index e9446e6..3d58be4 100644
--- a/meta-integrity/conf/layer.conf
+++ b/meta-integrity/conf/layer.conf
@@ -20,7 +20,7 @@ INTEGRITY_BASE := '${LAYERDIR}'
# interactive shell is enough.
OE_TERMINAL_EXPORTS += "INTEGRITY_BASE"

-LAYERSERIES_COMPAT_integrity = "honister"
+LAYERSERIES_COMPAT_integrity = "kirkstone"
# ima-evm-utils depends on keyutils from meta-oe
LAYERDEPENDS_integrity = "core openembedded-layer"

diff --git a/meta-parsec/conf/layer.conf b/meta-parsec/conf/layer.conf
index 2eeb71b..19900bb 100644
--- a/meta-parsec/conf/layer.conf
+++ b/meta-parsec/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "parsec-layer"
BBFILE_PATTERN_parsec-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_parsec-layer = "5"

-LAYERSERIES_COMPAT_parsec-layer = "honister"
+LAYERSERIES_COMPAT_parsec-layer = "kirkstone"

LAYERDEPENDS_parsec-layer = "core clang-layer tpm-layer"
BBLAYERS_LAYERINDEX_NAME_parsec-layer = "meta-parsec"
diff --git a/meta-security-compliance/conf/layer.conf b/meta-security-compliance/conf/layer.conf
index ec4fd47..7c07625 100644
--- a/meta-security-compliance/conf/layer.conf
+++ b/meta-security-compliance/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "scanners-layer"
BBFILE_PATTERN_scanners-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_scanners-layer = "10"

-LAYERSERIES_COMPAT_scanners-layer = "honister"
+LAYERSERIES_COMPAT_scanners-layer = "kirkstone"

LAYERDEPENDS_scanners-layer = "core openembedded-layer meta-python"

diff --git a/meta-security-isafw/conf/layer.conf b/meta-security-isafw/conf/layer.conf
index 86b0d4b..e8cdc1b 100644
--- a/meta-security-isafw/conf/layer.conf
+++ b/meta-security-isafw/conf/layer.conf
@@ -14,4 +14,4 @@ LAYERVERSION_security-isafw = "1"

LAYERDEPENDS_security-isafw = "core"

-LAYERSERIES_COMPAT_security-isafw = "honister"
+LAYERSERIES_COMPAT_security-isafw = "kirkstone"
diff --git a/meta-tpm/conf/layer.conf b/meta-tpm/conf/layer.conf
index b00dd3c..52e3ee0 100644
--- a/meta-tpm/conf/layer.conf
+++ b/meta-tpm/conf/layer.conf
@@ -8,7 +8,7 @@ BBFILE_COLLECTIONS += "tpm-layer"
BBFILE_PATTERN_tpm-layer = "^${LAYERDIR}/"
BBFILE_PRIORITY_tpm-layer = "10"

-LAYERSERIES_COMPAT_tpm-layer = "honister"
+LAYERSERIES_COMPAT_tpm-layer = "kirkstone"

LAYERDEPENDS_tpm-layer = " \
core \
--
2.25.1


Question: Derivative SDK using extensible SDK will produce an eSDK?

Miranda Miguel A
 

Hi everyone,  my team is working on generating a derivative SDK just as it is showed in documentation(https://www.yoctoproject.org/docs/2.1/sdk-manual/sdk-manual.html#sdk-creating-a-derivative-sdk-with-...)  but it is a little bit confusing when it use the SDK word to refer to eSDK instead. From build-sdk command commit https://git.yoctoproject.org/poky/commit/scripts/lib/devtool/build_sdk.py?id=25d9c4e02a90b1fd8c6a203... we can see that build-sdk is intended to produce an extensible SDK(eSDK) instead of a SDK. so my question is, buid-sdk should produce both eSDK and SDK or just eSDK?

Thanks!


[PATCH] meta-poky: Update BB_DISKMON_DIRS use

Scott Murray
 

Update the example BB_DISKMON_DIRS definitions in the sample
local.conf files for the rename of the "ABORT" action to "HALT".

Signed-off-by: Scott Murray <scott.murray@...>
---
meta-poky/conf/local.conf.sample | 10 +++++-----
meta-poky/conf/local.conf.sample.extended | 2 +-
2 files changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta-poky/conf/local.conf.sample b/meta-poky/conf/local.conf.sample
index dc78919..55e90e0 100644
--- a/meta-poky/conf/local.conf.sample
+++ b/meta-poky/conf/local.conf.sample
@@ -184,7 +184,7 @@ PATCHRESOLVE = "noop"
#
# Monitor the disk space during the build. If there is less that 1GB of space or less
# than 100K inodes in any key build location (TMPDIR, DL_DIR, SSTATE_DIR), gracefully
-# shutdown the build. If there is less than 100MB or 1K inodes, perform a hard abort
+# shutdown the build. If there is less than 100MB or 1K inodes, perform a hard halt
# of the build. The reason for this is that running completely out of space can corrupt
# files and damages the build in ways which may not be easily recoverable.
# It's necessary to monitor /tmp, if there is no space left the build will fail
@@ -194,10 +194,10 @@ BB_DISKMON_DIRS ??= "\
STOPTASKS,${DL_DIR},1G,100K \
STOPTASKS,${SSTATE_DIR},1G,100K \
STOPTASKS,/tmp,100M,100K \
- ABORT,${TMPDIR},100M,1K \
- ABORT,${DL_DIR},100M,1K \
- ABORT,${SSTATE_DIR},100M,1K \
- ABORT,/tmp,10M,1K"
+ HALT,${TMPDIR},100M,1K \
+ HALT,${DL_DIR},100M,1K \
+ HALT,${SSTATE_DIR},100M,1K \
+ HALT,/tmp,10M,1K"

#
# Shared-state files from other locations
diff --git a/meta-poky/conf/local.conf.sample.extended b/meta-poky/conf/local.conf.sample.extended
index 8a38454..1e3699e 100644
--- a/meta-poky/conf/local.conf.sample.extended
+++ b/meta-poky/conf/local.conf.sample.extended
@@ -195,7 +195,7 @@ DISTRO_FEATURES:remove = "x11"
# "action,directory,minimum_space,minimum_free_inode"
#
# The "action" must be set and should be one of:
-# ABORT: Immediately abort
+# HALT: Immediately halt
# STOPTASKS: The new tasks can't be executed any more, will stop the build
# when the running tasks have been done.
# WARN: show warnings (see BB_DISKMON_WARNINTERVAL for more information)
--
2.35.1


Minutes: Yocto Project Weekly Triage Meeting 2/17/2022

Trevor Gamblin
 

Wiki: https://wiki.yoctoproject.org/wiki/Bug_Triage

Attendees: Alejandro, Alexandre, Bruce, Daiane, Jan-Simon, Joshua, Michael, Pavel, Randy, Richard, Saul, Stephen, Steve, Tim, Trevor

ARs:

N/A


Notes:

- ~43% of AB workers have been switched to SSDs. Failure rate appears lower, but still TBD

Medium+ 3.5 Unassigned Enhancements/Bugs: 78 (Last week 79)

Medium+ 3.99 Unassigned Enhancements/Bugs: 39 (Last week 39)

AB Bugs: 73 (Last week 73)


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

Teoh, Jay Shen
 

Hi All,

This is the full report for yocto-3.4.2.rc2:
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,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Teoh, Jay Shen
Sent: Tuesday, 15 February, 2022 11:21 AM
To: qa-build-notification@...;
<yocto@...> <yocto@...>; OE-core
<openembedded-core@...>
Subject: Re: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.4.2.rc2)

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.4.2.rc2.
We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion this Friday, Feb 18.

Thanks,
Jay
-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Tuesday, 15 February, 2022 2:39 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification
<qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed
autobuilder build (yocto-3.4.2.rc2)

A build flagged for QA (yocto-3.4.2.rc2) was completed on the
autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.4.2.rc2


Build hash information:

bitbake: c039182c79e2ccc54fff5d7f4f266340014ca6e0
meta-agl: 1a8abc70c4f2339200b612d96d81c4eec3ac0519
meta-arm: 51b728a52bde7c613d5855afeac0fa6a31771bd2
meta-aws: c92344938ab4d37de8bd8b799186dbbe3019a069
meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
meta-intel: 5a30dcefa54040dd05099549a56156a83263554c
meta-mingw: f5d761cbd5c957e4405c5d40b0c236d263c916a8
meta-openembedded: c05ae80ba680887ac924c21536091be7a1173427
oecore: 418a9c4c31615a9e3e011fc2b21fb7154bc6c93a
poky: e0ab08bb6a32916b457d221021e7f402ffa36b1a



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...










Yocto Project 3.1.14 (dunfell-23.0.14) is Released

Lee Chee Yang
 

Hi

We are pleased to announce the Yocto Project 3.1.14 (dunfell-23.0.14) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Chee Yang Lee chee.yang.lee@...

Yocto Project Build and Release

 

- --------------------------

yocto-3.1.14 Release Notes

- --------------------------

 

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: bba323389749ec3e306509f8fb12649f031be152

Release Artefact: poky-dunfell-23.0.14

sha: 3401d1b660f2284e6e974c4dd1a8a3d5b1d311f87d261c324a84f812a9ad9d9c

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/poky-dunfell-23.0.14.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: f3be01483b01c88f8c4ba24ca73ccf1bcc33665c

Release Artefact: oecore-dunfell-23.0.14

sha: 9584897dfdab65bd1d70254f25cc91fb6d04e92e4b77b088ed81603da6a57909

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/oecore-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/oecore-dunfell-23.0.14.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.14

sha: dcd6e4a799b8f2727279eb640f077ca945a33ad61a2a9f076a72061874847e6d

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/meta-mingw-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/meta-mingw-dunfell-23.0.14.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.14

sha: a102bad796e7bbd36881068e18aabf49ce66b41a252ae06101ff3d64d4ce6ec8

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/meta-gplv2-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/meta-gplv2-dunfell-23.0.14.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: be6ecc160ac4a8d9715257b9b955363cecc081ea

Release Artefact: bitbake-dunfell-23.0.14

sha: 3f6a3bb828be8196e19b6a46461373cdced08792ac01488f25cdb31a0740e7f3

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.14/bitbake-dunfell-23.0.14.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.14/bitbake-dunfell-23.0.14.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.14

Git Revision: 9c5533b45bfd6a3d383e973a2c40e0f418afcbe9

 

 

- ---------------

Known Issues

- ---------------

N/A

 

 

- ---------------

Security Fixes

- ---------------

speex: fix CVE-2020-23903

expat: fix CVE-2021-46143

expat: fix CVE-2021-45960

expat fix CVE-2022-22822 through CVE-2022-22827

xserver-xorg: whitelist two CVEs

xserver-xorg: update CVE_PRODUCT

grub: fix CVE-2020-14372 and CVE-2020-27779

dropbear: Fix CVE-2020-36254

inetutils: fix CVE-2021-40491

vim: fix CVE-2021-4069

openssh: Whitelist CVE-2016-20012

openssh: Fix CVE-2021-41617

bluez: fix CVE-2021-0129

 

 

- ---------------

Fixes

- ---------------

build-appliance-image: Update to dunfell head revision

poky.conf: Bump version for 3.1.14 release

bitbake: hashserv: specify loop for asyncio in python < 3.6

Revert "weston: Use systemd notify,"

lttng-tools: Add missing DEPENDS on bison-native

kernel: introduce python3-dtschema-wrapper

linux-yocto/5.4: update to v5.4.172

glibc: Add fix for data races in pthread_create and TLS access

parselogs: add a couple systemd false positives

expat: Update HOMEPAGE to current url

wic: use shutil.which

wic: misc: Do not find for executables in ASSUME_PROVIDED

cve-check: add lockfile to task

cve-update-db-native: use fetch task

oeqa/selftest/cases/tinfoil.py: increase timeout 60->120s test_wait_event

valgrind: skip flakey ptest (gdbserver_tests/hginfo)

bitbake: tests/fetch: Drop gnu urls from wget connectivity test

bitbake: utils: Update to use exec_module() instead of load_module()

linux-yocto/5.4: update genericx86* machines to v5.4.158

asciidoc: properly detect and compare Python versions >= 3.10

lib/oe/reproducible: correctly set .git location when recursively looking for git repos

scripts: Update to use exec_module() instead of load_module()

selftest: skip virgl test on fedora 35

scripts/buildhistory-diff: drop use of distutils

weston: Backport patches to always activate the top-level surface

oeqa/selftest/tinfoil: Update to use test command

oeqa/selftest/bbtests: Use YP sources mirror instead of GNU

openssl: Add reproducibility fix

libpcre2: update SRC_URI

linux-firmware: upgrade 20211027 -> 20211216

bitbake: cooker/command: Add a dummy event for tinfoil testing

ref-manual: fix patch documentation

documentation: further updates for 3.1.13

releases: update to include 3.1.13

selftest: skip virgl test on fedora 34 entirely

gstreamer1.0: fix failing ptest

bootchart2: remove wait_boot logic


[meta-security][PATCH] tpm2-pkcs11: fix RDEPENDS variable

Patrick Williams
 

The RDEPENDS variable was misspelled and as a result was never fixed up
with the `_${PN}` to `:${PN}` transition. Fix both aspects.

Signed-off-by: Patrick Williams <patrick@...>
---
meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb
index d70dbfa..177c3c3 100644
--- a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.7.0.bb
@@ -52,5 +52,5 @@ FILES:${PN} += "\
${datadir}/p11-kit/* \
"

-RDEPNDS_${PN} = "tpm2-tools"
+RDEPENDS:${PN} = "tpm2-tools"
RDEPENDS:${PN}-tools += "${PYTHON_PN}-setuptools ${PYTHON_PN}-pyyaml ${PYTHON_PN}-cryptography ${PYTHON_PN}-pyasn1-modules"
--
2.34.1


Re: freecell-solver fetch issue

Andreas Müller
 

Hi,

Isn't that [1]? I answered and got no response. Why cross-post?

[1] https://github.com/schnitzeltony/meta-qt5-extra/issues/88

Cheers

Andreas

On Fri, Feb 11, 2022 at 1:50 PM sateesh m <sateesh0457@...> wrote:

Hi Team,

I am trying to install the Freecell-solver package. I am facing a problem fetcher issue. Can anybody know how to fix this issue? please guide me.

WARNING: /home/integration-team/kde2/meta-qt5-extra/recipes-kde/packagegroups/kde-games.bb:do_build is tainted from a forced run | ETA: 0:00:00
Initialising tasks: 100% |####################################################################################################################################| Time: 0:00:01
Sstate summary: Wanted 12 Found 0 Missed 12 Current 1387 (0% match, 99% complete)
NOTE: Executing Tasks
WARNING: freecell-solver-5.24.0-r0 do_fetch: Failed to fetch URL http://fc-solve.shlomifish.org/downloads/fc-solve/freecell-solver-5.24.0.tar.xz, attempting MIRRORS if available
ERROR: freecell-solver-5.24.0-r0 do_fetch: Fetcher failure: Fetch command export PSEUDO_DISABLED=1; export DBUS_SESSION_BUS_ADDRESS="unix:path=/run/user/1001/bus"; export PATH="/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/usr/bin/perl-native:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/usr/bin/python3-native:/home/integration-team/kde2/openembedded-core/scripts:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/usr/bin/riscv64-oe-linux:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot/usr/bin/crossscripts:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/usr/sbin:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/usr/bin:/home/integration-team/kde2/exaleap-build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/sbin:/home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/recipe-sysroot-native/bin:/home/integration-team/kde2/bitbake/bin:/home/integration-team/kde2/build/tmp-glibc/hosttools"; export HOME="/home/integration-team"; /usr/bin/env wget -t 2 -T 30 --passive-ftp --no-check-certificate -P /home/integration-team/kde2/build/downloads 'http://fc-solve.shlomifish.org/downloads/fc-solve/freecell-solver-5.24.0.tar.xz' --progress=dot -v failed with exit code 8, no output
ERROR: freecell-solver-5.24.0-r0 do_fetch: Fetcher failure for URL: 'http://fc-solve.shlomifish.org/downloads/fc-solve/freecell-solver-5.24.0.tar.xz'. Unable to fetch URL from any source.
ERROR: Logfile of failure stored in: /home/integration-team/kde2/build/tmp-glibc/work/riscv64-oe-linux/freecell-solver/5.24.0-r0/temp/log.do_fetch.22394
ERROR: Task (/home/integration-team/kde2/meta-qt5-extra/recipes-support/shlomif/freecell-solver.bb:do_fetch) failed with exit code '1'
NOTE: Tasks Summary: Attempted 4421 tasks of which 4420 didn't need to be rerun and 1 failed.

Summary: 1 task failed:
/home/integration-team/kde2/meta-qt5-extra/recipes-support/shlomif/freecell-solver.bb:do_fetch
Summary: There were 2 WARNING messages shown.
Summary: There were 2 ERROR messages shown, returning a non-zero exit code.


--
Regards,
Sateesh


Re: same build for multiple machine configurations

Khem Raj
 

On Wed, Feb 16, 2022 at 1:36 AM Alexandru Ionita
<alexandru.ionita@...> wrote:


Hello all,

I'm not sure if this is even possible at all. I'm using the meta-raspberry layer to build raspberry images. Whilst I'm able to build images by strictly selecting a raspberry pi machine configuration (MACHINE=raspberrypi3), I would like to know if it's possible to build an image that is compatible with multiple raspberry pi machine configurations. For instance an image that would work for both raspberrypi3 and raspberrypi4.
I think you can share maximum by using same tunes perhaps for pi3 and
pi4 machines but we do not generate single images which will work
across multiple SOCs.

Thanks.
Alex



Interesting discussion on github relating to branch (re)naming

K1AY <challinan@...>
 

https://github.com/fsnotify/fsnotify/issues/426

I discovered the issue while building something on Warrior.  Yeah, I know it's been fixed a couple weeks ago in Yocto, but it brings up a bigger point of discussion. 

Thought some of you might want to know if you haven't come across the issue yet.

Cheers!

Chris


Re: Yocto Zeus -docker/PREEMPT_RT

Leon Woestenberg
 

Hello Steven,

Last entry, from July 2021, in this blog says not supported;
Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums
No, that remark is completely wrong and is mixing up things.
"RTLinux" has nothing to do with the mainstream Linux kernel (except
that RTLinux can run the Linux kernel underneath)
Forget about those remarks.


Mainstream Linux is now almost fully-featured with the PREEMPT_RT work
merged, and the Linux kernel can be configured as an RTOS capable
kernel.
There is more to hard real-time than just the kernel, but that is the
kernel part.

I would see *no reason* why Docker should not run on Linux, even when
preemptive realtime is enabled.
In contrast when searching for the PREEMPT_RT / Docker combination I
see successful results.

What is probably the cause for Docker not working, is that the kernel
configuration for the PREEMPT_RT a.k.a. "-rt" kernel in Yocto does not
enable all name space support and other capabilities that Docker
depends on.

I would start comparing .config files at this point, together with the
debug/log output of Docker.
Especially first learn which CONFIG_ options Docker depends on.

Regards,

--
Leon Woestenberg
leon@...
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Wed, Feb 16, 2022 at 1:15 PM Monsees, Steven C (US) via
lists.yoctoproject.org
<steven.monsees=baesystems.com@...> wrote:



I have 2 platforms one with a standard kernel the other using PREEMPT_RT kernel… both work as expected.



All things being equal, when I add docker container support to both platforms, the standard kernel works just fine, but on the

PREEMPT_RT kernel docker does not appear to initialize/work correctly…



I have also tested using both ARM & Intel based HW, and appear tosee the same behavior on both.



Checking online it appears there is chatter about whether docker will run correctly under a PREEMPT_RT kernel.

Example:


Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?

>
I am currently running zeus based platforms, docker is at version 19.03.2-ce.



Is there a patch to correct for the compatibility issues being seen ?, or

Is there a yocto version I might move to which supports both correctly ?



Any input on this would be greatly appreciated.



Thanks,

Steve








Yocto Zeus -docker/PREEMPT_RT

Monsees, Steven C (US)
 

 

I have 2 platforms one with a standard kernel the other using PREEMPT_RT kernel… both work as expected.

 

All things being equal, when I add docker container support to both platforms, the standard kernel works just fine, but on the  

PREEMPT_RT kernel docker does not appear to initialize/work correctly…

 

I have also tested using both ARM & Intel based HW, and appear tosee the same behavior on both.

 

Checking online it appears there is chatter about whether docker will run correctly under a PREEMPT_RT kernel.

Example:

 

Last entry, from July 2021, in this blog says not supported;

Docker for RTOS? - General Discussions / Feature Requests - Docker Community Forums

 

Under Yocto, will docker & PREEMPT_RT kernels function correctly, is this combination supported ?

 

I am currently running zeus based platforms, docker is at version 19.03.2-ce.

 

Is there a patch to correct for the compatibility issues being seen ?, or

Is there a yocto version I might move to which supports both correctly ?

 

Any input on this would be greatly appreciated.

 

Thanks,

Steve

 

 


same build for multiple machine configurations

Alexandru Ionita
 


Hello all,

I'm not sure if this is even possible at all. I'm using the meta-raspberry layer to build raspberry images. Whilst I'm able to build images by strictly selecting a raspberry pi machine configuration (MACHINE=raspberrypi3), I would like to know if it's possible to build an image that is compatible with multiple raspberry pi machine configurations. For instance an image that would work for both raspberrypi3 and raspberrypi4.

Thanks.
Alex


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

Richard Purdie
 

On Tue, 2022-02-15 at 12:46 +0000, Teoh, Jay Shen wrote:
Hi All,

This is the full report for yocto-3.1.14.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 for testing! The TSC did discuss this today and agreed it should be good
to release.

Cheers,

Richard


Yocto Project Status WW07`22

Stephen Jolley
 

Current Dev Position: YP 3.5 M3

Next Deadline: 21th Feb. 2022 YP 3.5 M3 build

 

Next Team Meetings:

 

Key Status/Updates:

  • Next week is feature freeze for 3.5, our next LTS release
  • YP 3.1.14 passed QA and is due to be released
  • YP 3.2.4 rc2 is in QA (rc1 had sstate networking issues)
  • We’re extremely worried about the inclusive language changes since these are not anywhere near ready and the freeze deadline is in days. This is an important topic but sadly we’re simply starved of people with the right time and skills to spend on it. There is an email on the openembedded-architecture list about this.
  • The autobuilder infrastructure is planned to be offline 26-28th February for a data center move. Public services like the website, wiki and git servers will remain live but the git backend (push.yoctoproject.org) will be offline, as will the downloads and sstate services and the autobuilder/NAS.
  • We’ve upgraded to the new glibc version and have patches in testing for the new binutils release assuming some minor issues there are resolved.
  • There are changes proposed to the bitbake git fetcher handling of tags. We resolve these against the upstream repositories and the caching of the values was showing issues such as network accesses in the unpack task. We advice against using tags due to the potential for them to change, any layers using them may seen error messages depending on whether their usage is problematic.
  • Intermittent issues continue to be at record high levels and help is very much welcome in trying to resolve them. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

In particular, we’re struggling to understand the intermittent network issue with external hosts we’re seeing very occasionally.

 

Ways to contribute:

 

YP 3.5 Milestone Dates:

  • YP 3.5 M3 build date 2022/02/21
  • YP 3.5 M3 Release date 2022/03/04
  • YP 3.5 M4 build date 2022/04/04
  • YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

  • YP 3.1.14 is out of QA
  • YP 3.4.2 is in QA
  • YP 3.4.2 Release date 2022/02/18
  • YP 3.3.5 build date 2022/02/14
  • YP 3.3.5 Release date 2022/02/25
  • YP 3.1.15 build date 2022/03/14
  • YP 3.1.15 Release date 2022/03/25
  • YP 3.4.3 build date 2022/03/21
  • YP 3.4.3 Release date 2022/04/01
  • YP 3.3.6 build date 2022/03/28
  • YP 3.3.6 Release date 2022/04/08
  • YP 3.1.16 build date 2022/04/25
  • YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

* Email:              sjolley.yp.pm@...

 


gpsd bbappend adding new file causing QA errors even with FILES_${PN}:append set

mattwood2000@...
 

Hi,

I've seen many questions about this with proposed answers but I cannot
seem to get this to work for my bbappend to gpsd.

I'm simply trying to add an additional systemd service file I created
for the gpspipe client.

What is strange is that I'm already appending the
${systemd_system_unitdir} in this bbappend to replace gpsd.socket with
no error.

I'm confused why adding one additional file to a directory that is
already being appended could cause the QA error:
ERROR: gpsd-3.23.1-r0 do_package: QA Issue: gpsd: Files/directories
were installed but not shipped in any package:
/lib/systemd/system/gpspipe.service

The recipe is below - I've commented out the three lines that cause
the error. Anyone have any ideas why this is happening?

Thanks, Matt.

gpsd_%.bbappend:

FILESEXTRAPATHS:prepend := "${THISDIR}/files:"

SRC_URI += "\
file://gpsd.default \
file://gpsd.socket \
file://gpspipe.service \
"

inherit systemd
SYSTEMD_PACKAGES = "${PN}"
SYSTEMD_AUTO_ENABLE = "enable"
SYSTEMD_SERVICE_${PN}:append = " gpsd.service gpsd.socket gpspipe.service "

do_install:append () {
install -d ${D}${sysconfdir}/default/
install -d ${D}${sysconfdir}/systemd/system/multi-user.target.wants/
install -d ${D}${sysconfdir}/systemd/system/sockets.target.wants/

install -D -m 600 ${WORKDIR}/gpsd.default ${D}${sysconfdir}/default/
install -D -m 600 ${WORKDIR}/gpsd.socket ${D}${systemd_system_unitdir}
# install -D -m 600 ${WORKDIR}/gpspipe.service ${D}${systemd_system_unitdir}

ln -s ${systemd_unitdir}/system/gpsd.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpsd.service
ln -s ${systemd_unitdir}/system/gpsd.socket
${D}${sysconfdir}/systemd/system/sockets.target.wants/gpsd.socket
# ln -s ${systemd_unitdir}/system/gpspipe.service
${D}${sysconfdir}/systemd/system/multi-user.target.wants/gpspipe.service
}

FILES_${PN}:append = " \
${sysconfdir}/systemd/system/multi-user.target.wants \
${sysconfdir}/systemd/system/sockets.target.wants \
${sysconfdir}/default/gpsd.default \
${systemd_system_unitdir}/gpsd.socket \
# ${systemd_system_unitdir}/gpspipe.service \
"


Best laptop for compiling Yocto

Greg Wilson-Lindberg <gwilson@...>
 

Hello All,

I have a System 76 Serval laptop that I have been using when building Yocto. It seems to be dying and they are on back order now, so not available for replacement. I was wondering what recommendations others would have for a good laptop to use for building Yocto?

 

Regards,

Greg


Re: [linux-yocto] Controlling features enable/disable across recipe and meta layers ?

Alexander Kanavin
 

You need to define several distributions (e.g. several
conf/distro/something.conf files), then you can set DISTRO_FEATURES
accordingly in each of them, and then on the recipe level
PACKAGECONFIGs can be enabled subject to DISTRO_FEATURES. Note that
each of those .conf files can include the same .inc, where the common
parts go, and only differ in things that need to be different.

Yocto does not provide a way to have different 'products' or 'builds'
inside the same distro: you choose a distro, then you choose a target
MACHINE (e.g. the hardware), then you choose the image to build.

Also, distro definitions do not belong in a BSP layer, they need to go
to a separate distro layer. You can ask your colleagues at QC how this
was cleaned up for a certain big german automotive customer and look
at the resulting layer code.

Alex

On Tue, 15 Feb 2022 at 16:05, Pintu Agarwal <pintu.ping@...> wrote:

Hi,

I have many questions about Yocto features.
My main question is: In Yocto what is the best mechanism to define a
feature flag such that it can be accessed across many layers and
recipes ?

We are using Yocto thud and/or dunfell at this moment for 2 different products.

From the Yocto document also it is not very clear which one to use.
Also, we are confused when one to use when, like we have:
DISTRO Feature flag,
PACKAGECONFIG variable,
IMAGE Feature,
Global Macro (setVar, getVar), etc.

Example:
Currently, we have many different releases and many different products use it.
So, we have many distro features, many of them are common and many of
them we defined newly for our product.
But for our product we have only one component (say: auto-prod).
So, when this component is enabled the same release should be built
for our product including our feature set.
And when this component is disabled, all our features should be
disabled like mainline release.

So, we wanted to define only one DISTRO feature (auto-prod) and list
all our features under this distro.
Also we wanted to control all these from a single place, so that
enabling/disabling all the features in one shot would be easy and
portable.
We tried doing it using PACKAGECONFIG but it seems this option can be
used only at a recipe level and not visible across all layers.

We wanted to do something like this in: auto.conf
DISTRO_FEATURES = "auto-prod"
if defined (distro-features == auto-prod) ; then
PACKAGECONFIG_append-pn-<recipe1> = "f1 f2 ..."
PACKAGECONFIG_append-pn-<recipe2> = "f2 f3 ..."
PACKAGECONFIG_append-pn-<recipe3> = "f1 f3 f4..."
fi

So, if we comment DISTRO_FEATURES all the features listed above should
be automatically disabled.

Note, our feature flags are used across multiple recipes and layers.
Bootloader layer, Kernel, meta layer, recipe layer, python source, C
source, scripts, etc.
Like: edk2, meta-qti-bsp, meta-security, meta-qti-auto, auto-prod-folder, etc.

Is there a well defined way in Yocto to achieve such a modular design approach ?

If there are any such references please share.

Our reference distro is here:
https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/conf/distro/auto.conf?h=yocto.lnx.3.0.c28

Thanks,
Pintu



Re: Controlling features enable/disable across recipe and meta layers ?

Pintu Agarwal
 

Hi,

I have many questions about Yocto features.
My main question is: In Yocto what is the best mechanism to define a
feature flag such that it can be accessed across many layers and
recipes ?

We are using Yocto thud and/or dunfell at this moment for 2 different products.

From the Yocto document also it is not very clear which one to use.
Also, we are confused when one to use when, like we have:
DISTRO Feature flag,
PACKAGECONFIG variable,
IMAGE Feature,
Global Macro (setVar, getVar), etc.

Example:
Currently, we have many different releases and many different products use it.
So, we have many distro features, many of them are common and many of
them we defined newly for our product.
But for our product we have only one component (say: auto-prod).
So, when this component is enabled the same release should be built
for our product including our feature set.
And when this component is disabled, all our features should be
disabled like mainline release.

So, we wanted to define only one DISTRO feature (auto-prod) and list
all our features under this distro.
Also we wanted to control all these from a single place, so that
enabling/disabling all the features in one shot would be easy and
portable.
We tried doing it using PACKAGECONFIG but it seems this option can be
used only at a recipe level and not visible across all layers.

We wanted to do something like this in: auto.conf
DISTRO_FEATURES = "auto-prod"
if defined (distro-features == auto-prod) ; then
PACKAGECONFIG_append-pn-<recipe1> = "f1 f2 ..."
PACKAGECONFIG_append-pn-<recipe2> = "f2 f3 ..."
PACKAGECONFIG_append-pn-<recipe3> = "f1 f3 f4..."
fi

So, if we comment DISTRO_FEATURES all the features listed above should
be automatically disabled.

Note, our feature flags are used across multiple recipes and layers.
Bootloader layer, Kernel, meta layer, recipe layer, python source, C
source, scripts, etc.
Like: edk2, meta-qti-bsp, meta-security, meta-qti-auto, auto-prod-folder, etc.

Is there a well defined way in Yocto to achieve such a modular design approach ?

If there are any such references please share.

Our reference distro is here:
https://source.codeaurora.org/quic/le/meta-qti-bsp/tree/conf/distro/auto.conf?h=yocto.lnx.3.0.c28

Thanks,
Pintu

1641 - 1660 of 57813