Date   

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
 

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


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

Teoh, Jay Shen
 

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,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Teoh, Jay Shen
Sent: Thursday, 10 February, 2022 12:05 PM
To: qa-build-notification@...;
<yocto@...> <yocto@...>; OE-core
<openembedded-core@...>
Subject: Re: [qa-build-notification] QA notification for completed autobuilder
build (yocto-3.1.14.rc1)

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-
3.1.14.rc1. 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 next Tuesday, Feb 15.

Thanks,
Jay

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Richard Purdie
Sent: Tuesday, 1 February, 2022 5:47 AM
To: <yocto@...> <yocto@...>
Cc: qa-build-notification
<qa-build-notification@...>
Subject: [qa-build-notification] QA notification for completed
autobuilder build (yocto-3.1.14.rc1)

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


https://autobuilder.yocto.io/pub/releases/yocto-3.1.14.rc1


Build hash information:

bitbake: be6ecc160ac4a8d9715257b9b955363cecc081ea
meta-agl: 7a644d636237459c54128a71d083cb6f9e1b8e60
meta-arm: ce535dfb96de4d2529f091d7d85a7172c626001c
meta-aws: 9979cfa676105cb68cfadfdaeabf044d7c919319
meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac
meta-intel: 87984115eb6ed1a4c17204629dcb100f6b76fe82
meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7
meta-openembedded: ab9fca485e13f6f2f9761e1d2810f87c2e4f060a
oecore: f3be01483b01c88f8c4ba24ca73ccf1bcc33665c
poky: bba323389749ec3e306509f8fb12649f031be152



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










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

Teoh, Jay Shen
 

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@...







M+ & H bugs with Milestone Movements WW07

Stephen Jolley
 

All,

YP M+ or high bugs which moved to a new milestone in WW07 are listed below:

Priority

Bug ID

Short Description

Changer

Owner

Was

Became

Medium+

10693

Add a testcase for multilib eSDK on the autobuilder

randy.macleod@...

Qi.Chen@...

3.5 M2

3.5 M3

 

13052

Allow oe-core generated OCI containers to be executed/tested on the build host

randy.macleod@...

bruce.ashfield@...

3.5 M2

3.5 M3

 

13053

oe-core OCI container compatibility / deployment and conversion

randy.macleod@...

bruce.ashfield@...

3.5 M2

3.5 M3

 

13251

Symlinks overridden when building multitple kernels

randy.macleod@...

bruce.ashfield@...

3.5 M2

3.5 M3

 

13722

Debugging With the GNU Project Debugger enhancements

randy.macleod@...

john.kaldas.enpj@...

3.5 M2

3.5 M3

 

13835

KCONF_BSP_AUDIT_LEVEL is not properly documented

randy.macleod@...

bruce.ashfield@...

3.5 M2

3.5 M3

 

14065

Automated ptest regression testing

randy.macleod@...

chee.yang.lee@...

3.5 M2

3.5 M4

 

14118

systemd services not enabled when using package feed

randy.macleod@...

unassigned@...

3.5 M2

3.5 M4

 

14121

Implement sphinx switchers.js for bitbake

randy.macleod@...

nicolas.dechesne@...

3.5 M2

3.5 M4

 

14571

Add support for arm in poky-tiny

randy.macleod@...

jon.mason@...

3.5 M3

3.5 M4

 

 

 

 

3.5 M2

3.5 M3

 

 

 

 

3.5 M4

3.5 M3

 

14572

mozjs doesn't build for armv5

randy.macleod@...

jon.mason@...

3.5 M2

3.5 M3

 

14570

debuginfod gdb: *** stack smashing detected ***: terminated

randy.macleod@...

pgowda.cve@...

3.5 M2

3.5 M4

 

14626

lttng user space tracing example does not build with eSDK. but with classic SDK

randy.macleod@...

saul.wold@...

3.5 M2

3.5 M3

 

14640

Relocation error when setting up SDK with rust tools

randy.macleod@...

pgowda.cve@...

3.5 M2

3.5 M3

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Enhancements/Bugs closed WW07!

Stephen Jolley
 

All,

The below were the owners of enhancements or bugs closed during the last week!

Who

Count

randy.macleod@...

8

richard.purdie@...

3

pavel@...

1

Grand Total

12

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Current high bug count owners for Yocto Project 3.5

Stephen Jolley
 

All,

Below is the list as of top 46 bug owners as of the end of WW07 of who have open medium or higher bugs and enhancements against YP 3.5.   There are 52 possible work days left until the final release candidates for YP 3.5 needs to be released.

Who

Count

michael.opdenacker@...

35

ross@...

34

randy.macleod@...

24

david.reyna@...

22

bruce.ashfield@...

17

sakib.sajal@...

13

tim.orling@...

13

trevor.gamblin@...

12

mhalstead@...

10

richard.purdie@...

9

bluelightning@...

6

saul.wold@...

6

kai.kang@...

6

JPEWhacker@...

4

hongxu.jia@...

4

chee.yang.lee@...

4

jon.mason@...

3

Qi.Chen@...

3

pokylinux@...

3

mshah@...

2

pgowda.cve@...

2

alexandre.belloni@...

2

alejandro@...

2

thomas.perrot@...

1

mark.hatle@...

1

martin.beeger@...

1

liezhi.yang@...

1

kexin.hao@...

1

yi.zhao@...

1

mostthingsweb@...

1

Martin.Jansa@...

1

pavel@...

1

raj.khem@...

1

andrei@...

1

aehs29@...

1

yf3yu@...

1

matthewzmd@...

1

jay.shen.teoh@...

1

mingli.yu@...

1

TicoTimo@...

1

nicolas.dechesne@...

1

jaskij@...

1

shachar@...

1

john.kaldas.enpj@...

1

open.source@...

1

akuster808@...

1

Grand Total

259

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


Yocto Project Newcomer & Unassigned Bugs - Help Needed

Stephen Jolley
 

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#Newcomer_Bugs  Also please review: https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and how to create a bugzilla account at: https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work on who doesn't have deep experience with the project.  If anyone can help, please take ownership of the bug and send patches!  If anyone needs help/advice there are people on irc who can likely do so, or some of the more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs reported into the Bugzilla. The number of people attending that meeting has fallen, as have the number of people available to help fix bugs. One of the things we hear users report is they don't know how to help. We (the triage team) are therefore going to start reporting out the currently 401 unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out with these.  Bugs are split into two types, "true bugs" where things don't work as they should and "enhancements" which are features we'd want to add to the system.  There are also roughly four different "priority" classes right now,  “3.5, “3.6”, "3.99" and "Future", the more pressing/urgent issues being in "3.4" and then “3.5”.

 

Please review this link and if a bug is something you would be able to help with either take ownership of the bug, or send me (sjolley.yp.pm@...) an e-mail with the bug number you would like and I will assign it to you (please make sure you have a Bugzilla account).  The list is at: https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 

1181 - 1200 of 57347