Date   

Re: resolvconf breakage in kirkstone

Alexander Kanavin
 

A patch to address this would be appreciated.

Alex


On Wed, 3 Aug 2022 at 03:36, Craig McQueen <craig.mcqueen@...> wrote:
I've recently been upgrading from dunfell to kirkstone. I see a regression in the resolvconf package, so DNS lookups aren't functional.

I see in /var/log/messages:

Aug  2 19:39:31 tv999996 daemon.warn ifplugd(wan)[1729]: client: /sbin/resolvconf: line 173: /lib/resolvconf/normalize-resolvconf: No such file or directory

It looks as though the file is present in the Yocto build directory under
build/tmp/work/all-poky-linux/resolvconf/1.91-r0/git/bin/normalize-resolvconf
but the bb recipe is not installing that file to
/lib/resolvconf/normalize-resolvconf

--
Craig McQueen



 
 

 

Craig McQueen
Embedded Systems Engineer

t
e
w
:
:
:
+61 3 9780 4378
craig.mcqueen@...
innerrange.com
 Inner Range • 1 Millennium Court • Knoxfield • Victoria • 3180 • Australia 

 

 





Re: RDEPENDS of something provided by ALTERNATIVE

Richard Purdie
 

On Wed, 2022-08-03 at 09:25 +0200, Martin Jansa wrote:
You can use VIRTUAL-RUNTIME_sed variable instead of 'sed'
_everywhere_ and then change the preferred runtime provider in your
DISTRO config.

Similar case for "stat" from busybox in webOS OSE:
https://github.com/webosose/meta-webosose/search?q=VIRTUAL-RUNTIME_stat

and much worse case (because too many places add runtime dependency
on bash) to replace bash:
https://github.com/webosose/meta-webosose/search?q=VIRTUAL-RUNTIME_bash
see
https://bugzilla.yoctoproject.org/show_bug.cgi?id=9217#c5
This is where we should perhaps think about the filter variable option
Joshua and I have talked about periodically as that could handle this
in a much neater and generic way, at the unfortunate cost of
complexity.

The multilib code already tries to do this kind of remapping.

Cheers,

Richard


Re: RDEPENDS of something provided by ALTERNATIVE

Martin Jansa
 

You can use VIRTUAL-RUNTIME_sed variable instead of 'sed' _everywhere_ and then change the preferred runtime provider in your DISTRO config.

Similar case for "stat" from busybox in webOS OSE:

and much worse case (because too many places add runtime dependency on bash) to replace bash:
see

Regards,

On Wed, Aug 3, 2022 at 7:03 AM Craig McQueen <craig.mcqueen@...> wrote:
I have a recipe which contains a script that uses /bin/sed.

When I build it, I get an error:

ERROR: myrecipe-1.2.3-r0 do_package_qa: QA Issue: /lib/myrecipe/mycommand contained in package myrecipe requires /bin/sed, but no providers found in RDEPENDS:myrecipe? [file-rdeps]

My final image contains the BusyBox implementation of sed, so it will be fine at runtime.

If I add to my recipe RDEPENDS:${PN} += "sed", then when the image is built then it uses /bin/sed from the "sed" package, rather than being happy to use the BusyBox sed.

So, what is the correct way to specify a RDEPENDS to say that it depends on _any_ implementation of /bin/sed from any ALTERNATIVE provider?

--
Craig McQueen



 
 

 

Craig McQueen
Embedded Systems Engineer

t
e
w
:
:
:
+61 3 9780 4378
craig.mcqueen@...
innerrange.com
 Inner Range • 1 Millennium Court • Knoxfield • Victoria • 3180 • Australia 

 

 





RDEPENDS of something provided by ALTERNATIVE

Craig McQueen
 

I have a recipe which contains a script that uses /bin/sed.

When I build it, I get an error:

ERROR: myrecipe-1.2.3-r0 do_package_qa: QA Issue: /lib/myrecipe/mycommand contained in package myrecipe requires /bin/sed, but no providers found in RDEPENDS:myrecipe? [file-rdeps]

My final image contains the BusyBox implementation of sed, so it will be fine at runtime.

If I add to my recipe RDEPENDS:${PN} += "sed", then when the image is built then it uses /bin/sed from the "sed" package, rather than being happy to use the BusyBox sed.

So, what is the correct way to specify a RDEPENDS to say that it depends on _any_ implementation of /bin/sed from any ALTERNATIVE provider?

--
Craig McQueen



 
 

 

Craig McQueen
Embedded Systems Engineer

t
e
w
:
:
:
+61 3 9780 4378
craig.mcqueen@...
innerrange.com
 Inner Range • 1 Millennium Court • Knoxfield • Victoria • 3180 • Australia 

 

 


Re: [meta-zephyr][PATCH kirkstone 0/7] Series to add Gitlab CI to kirkstone

Naveen Saini
 

My local daily builds also run on master. I triggered a kirkstone build today, it builds successfully for me. Is it failing for specific machine ?

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Jon Mason
Sent: Tuesday, August 2, 2022 11:51 PM
To: yocto@...
Subject: [yocto] [meta-zephyr][PATCH kirkstone 0/7] Series to add Gitlab CI
to kirkstone

Kirkstone was broken for meta-zephyr for weeks, but no one noticed
because Gitlab CI is only running on master. Backport the relevant patches
from master so this can be more easily detected, and I'll run a nightly
kirkstone to my personal Gitlab CI setup (which can be monitored at
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines).

NOTE: I was conflicted between squashing the uniquely CI patches into a
single one to hide some of the bug fixesin he originals, versus pulling them
back to match what was in master. I did the latter, but the former might be
more acceptable.

CI run for this series can be seen at https://gitlab.com/jonmason00/meta-
zephyr/-/pipelines/602974431

Thanks,
Jon

--

Jon Mason (5):
qemu-nios2: use glibc
CI: add Gitlab CI support
CI: use path to avoid warning
CI: move stm32mp157c-dk2 to be alphabetical
CI: add more targets

Peter Hoyes (2):
zephyrtest: Enable use of TESTIMAGE_AUTO
CI: Use TESTIMAGE_AUTO

.gitlab-ci.yml | 90 ++++++++++++++++++++
ci/96b-avenger96.yml | 6 ++
ci/96b-nitrogen.yml | 20 +++++
ci/arduino-nano-33-ble.yml | 21 +++++
ci/base.yml | 38 +++++++++
ci/check-machine-coverage | 26 ++++++
ci/check-warnings | 19 +++++
ci/intel-x86-64.yml | 6 ++
ci/jobs-to-kas | 19 +++++
ci/logging.yml | 13 +++
ci/meta-openembedded.yml | 11 +++
ci/nrf52840dk-nrf52840.yml | 20 +++++
ci/qemu-cortex-m3.yml | 12 +++
ci/qemu-nios2.yml | 10 +++
ci/qemu-x86.yml | 10 +++
ci/stm32mp157c-dk2.yml | 13 +++
ci/testimage.yml | 9 ++
ci/update-repos | 40 +++++++++
meta-zephyr-bsp/conf/machine/qemu-nios2.conf | 2 + meta-zephyr-
core/classes/zephyrtest.bbclass | 2 +-
meta-zephyr-core/conf/distro/zephyr.conf | 2 +-
21 files changed, 387 insertions(+), 2 deletions(-) create mode 100644
.gitlab-ci.yml create mode 100644 ci/96b-avenger96.yml create mode 100644
ci/96b-nitrogen.yml create mode 100644 ci/arduino-nano-33-ble.yml create
mode 100644 ci/base.yml create mode 100755 ci/check-machine-coverage
create mode 100755 ci/check-warnings create mode 100644 ci/intel-x86-
64.yml create mode 100755 ci/jobs-to-kas create mode 100644
ci/logging.yml create mode 100644 ci/meta-openembedded.yml create
mode 100644 ci/nrf52840dk-nrf52840.yml create mode 100644 ci/qemu-
cortex-m3.yml create mode 100644 ci/qemu-nios2.yml create mode 100644
ci/qemu-x86.yml create mode 100644 ci/stm32mp157c-dk2.yml create
mode 100644 ci/testimage.yml create mode 100755 ci/update-repos

--
2.17.1


resolvconf breakage in kirkstone

Craig McQueen
 

I've recently been upgrading from dunfell to kirkstone. I see a regression in the resolvconf package, so DNS lookups aren't functional.

I see in /var/log/messages:

Aug  2 19:39:31 tv999996 daemon.warn ifplugd(wan)[1729]: client: /sbin/resolvconf: line 173: /lib/resolvconf/normalize-resolvconf: No such file or directory

It looks as though the file is present in the Yocto build directory under
build/tmp/work/all-poky-linux/resolvconf/1.91-r0/git/bin/normalize-resolvconf
but the bb recipe is not installing that file to
/lib/resolvconf/normalize-resolvconf

--
Craig McQueen



 
 

 

Craig McQueen
Embedded Systems Engineer

t
e
w
:
:
:
+61 3 9780 4378
craig.mcqueen@...
innerrange.com
 Inner Range • 1 Millennium Court • Knoxfield • Victoria • 3180 • Australia 

 

 


[ANNOUNCEMENT] Yocto Project 3.1.18 (dunfell-23.0.18) is Released

Lee Chee Yang
 

Hello

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

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/poky-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/poky-dunfell-23.0.18.tar.bz2

 

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

 

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

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/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.18 Release Notes

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

 

 

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

Repositories/Downloads

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

 

Repository Name: poky

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: d695bd0d3dc66f2111a25c6922f617be2d991071

Release Artefact: poky-dunfell-23.0.18

sha: c83e55427d7f0f05f87d8da9c5ce97e3b3a1eb5c1c8cf3920bcade97ca9ab7e0

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/poky-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/poky-dunfell-23.0.18.tar.bz2

 

Repository Name: openembedded-core

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: 3f40d5f095ceb099b604750db96058df00fcd49e

Release Artefact: oecore-dunfell-23.0.18

sha: f0e09a67a6da10b8abfa743541f20fd53bd7374531499912f22e101c19ada0eb

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/oecore-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/oecore-dunfell-23.0.18.tar.bz2

 

Repository Name: meta-mingw

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.18

sha: d5c020953dd61fe93d2dfec469c269553bf39b64173eaa410d2aca362f915933

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/meta-mingw-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/meta-mingw-dunfell-23.0.18.tar.bz2

 

Repository Name: meta-gplv2

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.18

sha: f89e80e64b646ca84a73b1a8377f808c99c747f7ba682a269bfb502de5775194

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/meta-gplv2-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/meta-gplv2-dunfell-23.0.18.tar.bz2

 

Repository Name: bitbake

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: 7fc4cffebf5dcc1d050416c0b7f7d58c765c1d69

Release Artefact: bitbake-dunfell-23.0.18

sha: 0cc901eedbb2fec1208383e8fee3a5fc9935a67171926517eef1c69f7da6eb02

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.18/bitbake-dunfell-23.0.18.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.18/bitbake-dunfell-23.0.18.tar.bz2

 

Repository Name: yocto-docs

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

Branch: dunfell

Tag: yocto-3.1.18

Git Revision: 882810d294762a6340909b59736acc660c4eaf5c

 

 

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

Known Issues

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

N/A

 

 

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

Security Fixes

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

grub2: CVE-2021-3981 Incorrect permission in grub.cfg allow unprivileged user to read the file content

unzip: Port debian fixes for CVE-2022-0529 and CVE-2022-0530

unzip: Fix CVE-2021-4217

golang: Fix CVE-2021-31525 net/http: panic in ReadRequest and ReadResponse when reading a very large header

golang: Fix CVE-2022-24675 encoding/pem: fix stack overflow in Decode

golang: Fix CVE-2021-44717 syscall: don't close fd 0 on ForkExec error

python-pip: Fix CVE-2021-3572 Incorrect handling of unicode separators in git references

openssh: Whitelist CVE-2021-36368

cups: Fix CVE-2022-26691

curl: Fix CVE-2022-27774, CVE-2022-27781, CVE-2022-27782, CVE-2022-32206, CVE-2022-32207, and CVE-2022-32208

libxslt: Mark CVE-2022-29824 as not applying

libxslt: Fix CVE-2021-30560

pcre2: Fix CVE-2022-1587 Out-of-bounds read

e2fsprogs: Fix CVE-2022-1304 out-of-bounds read/write via crafted filesystem

 

 

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

Fixes

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

IMAGE_LOCALES_ARCHIVE: add option to prevent locale archive creation

alsa-plugins: fix libavtp vs. avtp packageconfig

archiver: don't use machine variables in shared recipes

archiver: use bb.note instead of echo

bitbake: bin/bitbake-getvar: Add a new command to query a variable value (with history)

bitbake: fetch/git: Fix usehead for non-default names

bitbake: fetch/wget: Move files into place atomically

bitbake: knotty: display active tasks when printing keepAlive() message

bitbake: knotty: reduce keep-alive timeout from 5000s (83 minutes) to 10 minutes

bitbake: tinfoil/data_smart: Allow variable history emit() to function remotely

build-appliance-image: Update to dunfell head revision

classes/cve-check: Move get_patches_cves to library

curl: Fix CVE_CHECK_WHITELIST typo

cve-check: add coverage statistics on recipes with/without CVEs

cve-check: add support for Ignored CVEs

cve-check: hook cleanup to the BuildCompleted event, not CookerExit

cve-check: move update_symlinks to a library

cve-check: write empty fragment files in the text mode

cve-extra-exclusions.inc: Use CVE_CHECK_WHITELIST

cve-extra-exclusions: Clean up and ignore three CVEs (2xqemu and nasm)

cve-update-db-native: make it possible to disable database updates

documentation: update for 3.1.18 release

dpkg: update to 1.19.8

dropbear: break dependency on base package for -dev package

e2fsprogs: add alternatives handling of lsattr as well

efivar: change branch name to main

gcc-source: Fix incorrect task dependencies from ${B}

initramfs-framework: move storage mounts to actual rootfs

insane.bbclass: host-user-contaminated: Correct per package home path

kernel-yocto.bbclass: Reset to exiting on non-zero return code at end of task

license.bbclass: Bound beginline and endline in copy_license_files()

linux-firmware: add support for building snapshots

linux-firmware: upgrade 20220509 -> 20220610

linux-yocto-rt/5.4: fixup -rt build breakage

linux-yocto/5.4: update to v5.4.205

local.conf.sample: Update sstate url to new 'all' path

lttng-modules: Backport Linux 5.18+, 5.15.44+, 5.10.119+ fixes

manuals: switch to the sstate mirror shared between all versions

oe-selftest-image: Ensure the image has sftp as well as dropbear

oeqa/runtime/scp: Disable scp test for dropbear

oeqa/selftest/cve_check: add tests for Ignored and partial reports

oescripts: change compare logic in OEListPackageconfigTests

openssh: break dependency on base package for -dev package

openssl: update fix for ptest certificate expiration

openssl: update the epoch time for ct_test ptest

openssl: upgrade to 1.1.1q

packagegroup-core-ssh-dropbear: Add openssh-sftp-server recommendation

poky.conf: bump version for 3.1.18 release

qemu: add PACKAGECONFIG for capstone

ref-manual: Add XZ_THREADS and XZ_MEMLIMIT

ref-manual: variables: remove sphinx directive from literal block

rootfs.py: close kernel_abi_ver_file

systemd: systemd-systemctl: Support instance conf files during enable

vim: upgrade to 9.0.0021

wic: fix WicError message

wireless-regdb: upgrade 2022.04.08 -> 2022.06.06


Re: nftables_0.7 not working

Randy MacLeod
 

On 2022-08-01 11:45, Quentin Schulz wrote:
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/config.gz |
grep CONFIG_NF_ | grep TABLE)
Is that expected?
No, you would indeed need to enable those in your kernel config.
0.7 - that's pre-dunfell!

For master or kirkstone, see:
https://lists.yoctoproject.org/g/linux-yocto/message/11523?p=%2C%2C%2C20%2C0%2C0%2C0%3A%3Acreated%2C0%2Cmacleod%2C20%2C1%2C0%2C92659340

and the follow-up that I'll send soon to get the pass-rate to 100%.

You won't be able to use the WR Linux features directly but take a look at the image.inc
and template.conf files in:

https://github.com/WindRiver-Labs/wrlinux/tree/WRLINUX_10_21_BASE/templates/feature/nftables

for the syntax to use the kernel scc files for nftables. It may not be there if you're using an older kernel.

../Randy


Cheers,
Quentin

--
# Randy MacLeod
# Wind River Linux


Videos from Yocto talks at Embedded Linux Conference NA

Michael Opdenacker
 

Greetings

5 videos from Yocto Project talks at the Embedded Linux Conference North America are now available on YouTube:

BoF: The Yocto Project and OpenEmbedded Organization - Philip Balister, OpenSDR: https://youtu.be/Upvyb6VlICk

Configuring and Building a Heterogenous System Using the Yocto Project - Mark Hatle, AMD: https://youtu.be/SSFAp4LS6hs

Lessons Learned: Migrating a Production Platform to Yocto - Mitch Gaines, Farmblox: https://youtu.be/2mXxhlNM0_Q

Software Bill of Materials and Supply Chain with the Yocto Project - Joshua Watt, Garmin: https://youtu.be/6zms_qGmVqg

Yocto Project Autobuilders and the SWAT Team - Alexandre Belloni, Bootlin: https://youtu.be/SLHV9HbxKcM

For quick sharing, these videos are available on a special playlist: https://www.youtube.com/playlist?list=PL9E8231JvrhKff6RuVXJ8qlluqS4xG_9c

Please spread the news through social media. Feel free to reuse my own posts:
https://fosstodon.org/@MichaelOpdenacker/108754686397298056
https://www.linkedin.com/posts/michaelopdenacker_bof-the-yocto-project-and-openembedded-organization-activity-6960297794007904258-7eaB
https://twitter.com/mopdenacker/status/1554533737643159552

Cheers
Michael.

--
Michael Opdenacker, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com


Re: BBClass function and symbolic link (symlink) ... I throw in the towel #kirkstone #python #bitbake

Martin Leduc <martin.leduc@...>
 

Hi Joshua,

It's 100% my fault, I'm mixed 2 variables:

ROOTFS_POSTPROCESS_COMMAND
IMAGE_POSTPROCESS_COMMAND

My "ln " command have to be placed into IMAGE_POSTPROCESS_COMMAND, not ROOTFS_POSTPROCESS_COMMAND.

Thank you to have answer

-----Message d'origine-----
De : yocto@... <yocto@...> De la part de Martin Leduc via lists.yoctoproject.org
Envoyé : 2 août 2022 11:22
À : Joshua Watt <jpewhacker@...>
Cc : yocto@...
Objet : Re: [yocto] BBClass function and symbolic link (symlink) ... I throw in the towel #python #bitbake #kirkstone

Probably, I don't really know but when I comment the "ln -s" line, using a #, the compilation works. Only the "ln -s" lines

-----Message d'origine-----
De : Joshua Watt <jpewhacker@...> Envoyé : 2 août 2022 11:10 À : Martin Leduc <martin.leduc@...> Cc : yocto@... Objet : [EXTERNAL] Re: [yocto] BBClass function and symbolic link (symlink) ... I throw in the towel #python #bitbake #kirkstone

CAUTION: This email originated from outside of Luminator Technology Group. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Tue, Aug 2, 2022 at 10:02 AM Martin Leduc <martin.leduc@...> wrote:

Hi Joshua,

I've founded a second function, in the same class, using ln -s

set_log_folder () {
bbplain "Set var log folder BEGIN"
rm -Rf ${IMAGE_ROOTFS}/var/log
ln -s /mnt/general_data/log/ ${IMAGE_ROOTFS}/var/log
bbplain "Set var log folder END"
}

The logs show "Set var log folder BEGIN" and "Set var log folder END" and no issues ....
Your set version function looks like it's running from the logs, so don't think your function is directly causing a problem. My guess is something else later is crashing or something else unrelated?


What the hell I'm doing wrong....


Martin Leduc
T : (418) 856-6896
martin.leduc@...


-----Message d'origine-----
De : yocto@... <yocto@...> De la
part de Martin Leduc via lists.yoctoproject.org Envoyé : 2 août 2022
10:20 À : Joshua Watt <jpewhacker@...> Cc :
yocto@... Objet : Re: [yocto] BBClass function and
symbolic link (symlink) ... I throw in the towel #python #bitbake
#kirkstone

Hi Joshua,

Thank you for your quick reply.

Please see the crash log in the attachment.

"Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something still isn't working in Warrior that you need, or just in Kirkstone?"
This bbclass is imported from a previous build make using the Yocto Warrior version and the build report no failure using "ln -s" directly, well it compile.

BR,

-----Message d'origine-----
De : Joshua Watt <jpewhacker@...> Envoyé : 2 août 2022 09:57 À :
Martin Leduc <martin.leduc@...> Cc :
yocto@... Objet : [EXTERNAL] Re: [yocto] BBClass
function and symbolic link (symlink) ... I throw in the towel #python
#bitbake #kirkstone

CAUTION: This email originated from outside of Luminator Technology Group. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Tue, Aug 2, 2022 at 8:44 AM Martin Leduc via lists.yoctoproject.org <martin.leduc=luminator.com@...> wrote:

Hi team,

Well, I throw in the towel. But it's looks like so simple .... for me 🤣🤣.

I've a function to replace the version file in /etc/version. This function is integrated into my mybase-image.bbclass, defined in my layer and I add, in my core-image-minimal.bbappend recipe inherit mybase-image.bbclass.

In my bbclass, I call my function using

ROOTFS_POSTPROCESS_COMMAND += " \
set_version_file ; \
"

My function is written like this
set_version_file() {
bbplain "set_version_file BEGIN"
mkdir -p ${IMAGE_ROOTFS}/etc/tmp/
echo ${PV} > ${IMAGE_ROOTFS}/etc/tmp/version
chmod 644 ${IMAGE_ROOTFS}/etc/tmp/version
rm ${IMAGE_ROOTFS}/etc/version
ln -sf /etc/tmp/version "${IMAGE_ROOTFS}/etc/version"
}
Note: /etc/tmp is just for the purpose of this test

I mean, I don't try to do anything outstanding but the ln -sf line makes my compilation crash BUT.... it works like a charm with Warrior but Kirkstone rejects "ln -sf" command.
Can you provide a little more detail about how it crashes? Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something still isn't working in Warrior that you need, or just in Kirkstone?


I'm definitely not the only one who adds symlinks to the recipes

I've also tried:

lnr
inherit relative_symlinks (don't have any impact but I've given it a
try), from the poky folder I've tried grep -r "ln" ./* | grep
bbclass (to validate the syntax) Read many posts on this topic


I'm unable to find where is my issue.

Any ideas are welcome, even if it works like a charm on Warrior but not in Kirkstone.

BR,
Martin


Re: [OE-core] Yocto Project Status 02 August 2022 (WW31)

Steve Sakoman
 

On Tue, Aug 2, 2022 at 6:30 AM Marta Rybczynska <rybczynska@...> wrote:

On Tue, Aug 2, 2022 at 4:49 PM Neal Caidin <ncaidin@...> wrote:

Current Dev Position: YP 4.1 M3

Next Deadline: 22nd August 2022 YP 4.1 M3 Build


Next Team Meetings:

Bug Triage meeting Thursday August 4th 7:30 am PDT (https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)

Weekly Project Engineering Sync Tuesday August 2nd at 8 am PDT (https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09)

Twitch - See https://www.twitch.tv/theyoctojester


Key Status/Updates:

YP 4.1 M2 was released

YP 3.1.18 passed QA and is due to be released

The debug file mapping issues have moved slightly further forward thanks to some help from Ross but are stalling due to insufficient developer time available to resolve the issues.

Some rust toolchain improvements did merge, including an automated rust toolchain test. The bulk of the rework is stalled on a handful of remaining issues, particularly a couple of reproducibility problems but also a mips n32 toolchain issue.

We have one open CVE on master against qemu, help to backport that fix would be very welcome to keep the numbers down. CVEs in kirkstone (LTS) significantly reduced.
Do you mean CVE-2022-35414?
Yes! We have a patch under review for kirkstone:
https://lists.openembedded.org/g/openembedded-core/message/168636

I think Richard is hoping someone will see if that also will work on
master and if so send a patch.

Steve


[meta-zephyr][PATCH kirkstone 7/7] CI: add more targets

Jon Mason
 

The autotest change allows for the list of targets to be built to be
larger. Add more targets to increase the build coverage of CI.
Unfortunately, there are some platforms that do not build everything.
So, clip those down to those that work for all. Also, there are a few
targets unique to certain platforms. So, expand those to have coverage.

Signed-off-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
ci/96b-nitrogen.yml | 14 ++++++++++++++
ci/arduino-nano-33-ble.yml | 15 +++++++++++++++
ci/base.yml | 2 ++
ci/nrf52840dk-nrf52840.yml | 14 ++++++++++++++
ci/stm32mp157c-dk2.yml | 7 +++++++
5 files changed, 52 insertions(+)

diff --git a/ci/96b-nitrogen.yml b/ci/96b-nitrogen.yml
index d033d02..9b685fe 100644
--- a/ci/96b-nitrogen.yml
+++ b/ci/96b-nitrogen.yml
@@ -4,3 +4,17 @@ header:
- ci/base.yml

machine: 96b-nitrogen
+
+target:
+ - zephyr-blinky
+ - zephyr-coap-client
+ - zephyr-coap-server
+ - zephyr-echo-client
+ - zephyr-hci-uart
+ - zephyr-helloworld
+ - zephyr-http-client
+ - zephyr-kernel-test-all
+ - zephyr-mqtt-publisher
+ - zephyr-peripheral-esp
+ - zephyr-peripheral-hr
+ - zephyr-philosophers
diff --git a/ci/arduino-nano-33-ble.yml b/ci/arduino-nano-33-ble.yml
index eb878b9..1035118 100644
--- a/ci/arduino-nano-33-ble.yml
+++ b/ci/arduino-nano-33-ble.yml
@@ -4,3 +4,18 @@ header:
- ci/base.yml

machine: arduino-nano-33-ble
+
+target:
+ - zephyr-blinky
+ - zephyr-coap-client
+ - zephyr-coap-server
+ - zephyr-echo-client
+ - zephyr-helloworld
+ - zephyr-http-client
+ - zephyr-kernel-test-all
+ - zephyr-mqtt-publisher
+ - zephyr-openthread-echo-client
+ - zephyr-openthread-rcp
+ - zephyr-peripheral-esp
+ - zephyr-peripheral-hr
+ - zephyr-philosophers
diff --git a/ci/base.yml b/ci/base.yml
index 678b45d..bab03d3 100644
--- a/ci/base.yml
+++ b/ci/base.yml
@@ -33,4 +33,6 @@ local_conf_header:
machine: unset

target:
+ - zephyr-helloworld
- zephyr-kernel-test-all
+ - zephyr-philosophers
diff --git a/ci/nrf52840dk-nrf52840.yml b/ci/nrf52840dk-nrf52840.yml
index 53ab8af..a0c1587 100644
--- a/ci/nrf52840dk-nrf52840.yml
+++ b/ci/nrf52840dk-nrf52840.yml
@@ -4,3 +4,17 @@ header:
- ci/base.yml

machine: nrf52840dk-nrf52840
+
+target:
+ - zephyr-blinky
+ - zephyr-coap-client
+ - zephyr-coap-server
+ - zephyr-echo-client
+ - zephyr-helloworld
+ - zephyr-http-client
+ - zephyr-kernel-test-all
+ - zephyr-lvgl
+ - zephyr-mqtt-publisher
+ - zephyr-peripheral-esp
+ - zephyr-peripheral-hr
+ - zephyr-philosophers
diff --git a/ci/stm32mp157c-dk2.yml b/ci/stm32mp157c-dk2.yml
index 8929b00..3dc04a5 100644
--- a/ci/stm32mp157c-dk2.yml
+++ b/ci/stm32mp157c-dk2.yml
@@ -4,3 +4,10 @@ header:
- ci/base.yml

machine: stm32mp157c-dk2
+
+target:
+ - zephyr-blinky
+ - zephyr-helloworld
+ - zephyr-kernel-test-all
+ - zephyr-philosophers
+ - zephyr-openamp-rsc-table
--
2.17.1


[meta-zephyr][PATCH kirkstone 6/7] CI: move stm32mp157c-dk2 to be alphabetical

Jon Mason
 

Trivial change to move stm32mp157c-dk2 to its alphabetical location.
This is relevant because it aligns the file to match the order on the
gilab pipeline entry.

Signed-off-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.gitlab-ci.yml | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 014123f..8d22654 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -77,9 +77,6 @@ intel-x86-64:
nrf52840dk-nrf52840:
extends: .build

-stm32mp157c-dk2:
- extends: .build
-
qemu-cortex-m3/testimage:
extends: .build

@@ -88,3 +85,6 @@ qemu-nios2:

qemu-x86/testimage:
extends: .build
+
+stm32mp157c-dk2:
+ extends: .build
--
2.17.1


[meta-zephyr][PATCH kirkstone 5/7] CI: use path to avoid warning

Jon Mason
 

Warnings are being seen in gitlab of
WARNING - Falling back to file-relative addressing of local include "base.yml"
WARNING - Update your layer to repo-relative addressing to avoid this warning
WARNING - Falling back to file-relative addressing of local include "meta-openembedded.yml"
WARNING - Update your layer to repo-relative addressing to avoid this warning

Make the relevant changes to resolve this issue

Signed-off-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
ci/96b-avenger96.yml | 2 +-
ci/96b-nitrogen.yml | 2 +-
ci/arduino-nano-33-ble.yml | 2 +-
ci/base.yml | 2 +-
ci/intel-x86-64.yml | 2 +-
ci/nrf52840dk-nrf52840.yml | 2 +-
ci/qemu-nios2.yml | 2 +-
ci/qemu-x86.yml | 2 +-
ci/stm32mp157c-dk2.yml | 2 +-
9 files changed, 9 insertions(+), 9 deletions(-)

diff --git a/ci/96b-avenger96.yml b/ci/96b-avenger96.yml
index 6d632f1..bcdccf3 100644
--- a/ci/96b-avenger96.yml
+++ b/ci/96b-avenger96.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: 96b-avenger96
diff --git a/ci/96b-nitrogen.yml b/ci/96b-nitrogen.yml
index ecd96fb..d033d02 100644
--- a/ci/96b-nitrogen.yml
+++ b/ci/96b-nitrogen.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: 96b-nitrogen
diff --git a/ci/arduino-nano-33-ble.yml b/ci/arduino-nano-33-ble.yml
index ca332da..eb878b9 100644
--- a/ci/arduino-nano-33-ble.yml
+++ b/ci/arduino-nano-33-ble.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: arduino-nano-33-ble
diff --git a/ci/base.yml b/ci/base.yml
index fb1699c..678b45d 100644
--- a/ci/base.yml
+++ b/ci/base.yml
@@ -1,7 +1,7 @@
header:
version: 11
includes:
- - meta-openembedded.yml
+ - ci/meta-openembedded.yml

distro: zephyr

diff --git a/ci/intel-x86-64.yml b/ci/intel-x86-64.yml
index 525a38f..23e711c 100644
--- a/ci/intel-x86-64.yml
+++ b/ci/intel-x86-64.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: intel-x86-64
diff --git a/ci/nrf52840dk-nrf52840.yml b/ci/nrf52840dk-nrf52840.yml
index cbbf434..53ab8af 100644
--- a/ci/nrf52840dk-nrf52840.yml
+++ b/ci/nrf52840dk-nrf52840.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: nrf52840dk-nrf52840
diff --git a/ci/qemu-nios2.yml b/ci/qemu-nios2.yml
index c382582..b818371 100644
--- a/ci/qemu-nios2.yml
+++ b/ci/qemu-nios2.yml
@@ -1,7 +1,7 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

local_conf_header:
nonbuilding_tests: |
diff --git a/ci/qemu-x86.yml b/ci/qemu-x86.yml
index ba80dd3..df744a1 100644
--- a/ci/qemu-x86.yml
+++ b/ci/qemu-x86.yml
@@ -1,7 +1,7 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

local_conf_header:
failing_tests: |
diff --git a/ci/stm32mp157c-dk2.yml b/ci/stm32mp157c-dk2.yml
index c833794..8929b00 100644
--- a/ci/stm32mp157c-dk2.yml
+++ b/ci/stm32mp157c-dk2.yml
@@ -1,6 +1,6 @@
header:
version: 9
includes:
- - base.yml
+ - ci/base.yml

machine: stm32mp157c-dk2
--
2.17.1


[meta-zephyr][PATCH kirkstone 3/7] zephyrtest: Enable use of TESTIMAGE_AUTO

Jon Mason
 

From: Peter Hoyes <Peter.Hoyes@...>

When TESTIMAGE_AUTO is enabled, the do_testimage task is inserted after
do_image_complete and before do_build so that the test suites
automatically run as part of the image build.

However, do_testdata_write is currently constrained to run only before
do_build, so it likely won't execute prior to do_testimage. Change the
"before" constraint to do_testimage do that the testdata is always
generated prior to running the testimage task.

Signed-off-by: Peter Hoyes <Peter.Hoyes@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
meta-zephyr-core/classes/zephyrtest.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta-zephyr-core/classes/zephyrtest.bbclass b/meta-zephyr-core/classes/zephyrtest.bbclass
index 248fd15..aa48e6c 100644
--- a/meta-zephyr-core/classes/zephyrtest.bbclass
+++ b/meta-zephyr-core/classes/zephyrtest.bbclass
@@ -50,4 +50,4 @@ python testdata_clean() {
os.remove(fname)
}

-addtask do_testdata_write before do_build after do_deploy
+addtask do_testdata_write before do_testimage after do_deploy
--
2.17.1


[meta-zephyr][PATCH kirkstone 1/7] qemu-nios2: use glibc

Jon Mason
 

newlib fails to compile for nios2 architecture. Work around this by
using glibc instead.

Signed-off-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
meta-zephyr-bsp/conf/machine/qemu-nios2.conf | 2 ++
meta-zephyr-core/conf/distro/zephyr.conf | 2 +-
2 files changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta-zephyr-bsp/conf/machine/qemu-nios2.conf b/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
index de20320..c41f505 100644
--- a/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
+++ b/meta-zephyr-bsp/conf/machine/qemu-nios2.conf
@@ -14,3 +14,5 @@ QB_OPT_APPEND = "-nographic"
QB_CPU = "-cpu nios2"

ARCH:qemu-nios2 = "nios2"
+
+TCLIBC = "glibc"
diff --git a/meta-zephyr-core/conf/distro/zephyr.conf b/meta-zephyr-core/conf/distro/zephyr.conf
index 6ecd421..bdf1821 100644
--- a/meta-zephyr-core/conf/distro/zephyr.conf
+++ b/meta-zephyr-core/conf/distro/zephyr.conf
@@ -4,7 +4,7 @@ DISTRO_VERSION = "1.0"

TARGET_VENDOR = "-yocto"

-TCLIBC = "newlib"
+TCLIBC ?= "newlib"

TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"
--
2.17.1


[meta-zephyr][PATCH kirkstone 4/7] CI: Use TESTIMAGE_AUTO

Jon Mason
 

From: Peter Hoyes <Peter.Hoyes@...>

Now that TESTIMAGE_AUTO is available for Zephyr builds, enable it in
ci/testimage.yml and remove the redundant build_and_test base
configuration.

Remove testimage from Nios2 build as it is currently failing.

Signed-off-by: Peter Hoyes <Peter.Hoyes@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.gitlab-ci.yml | 17 +++--------------
ci/testimage.yml | 1 +
2 files changed, 4 insertions(+), 14 deletions(-)

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
index 68abd32..014123f 100644
--- a/.gitlab-ci.yml
+++ b/.gitlab-ci.yml
@@ -35,17 +35,6 @@ stages:
paths:
- $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*

-# Workaround for Zephyr not currectly handling TESTIMAGE_AUTO
-.build_and_test:
- extends: .setup
- script:
- - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
- - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
- - kas build $KASFILES
- - kas build $KASFILES -c testimage
- - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
-
-
#
# Prep stage, update repositories once
#
@@ -92,10 +81,10 @@ stm32mp157c-dk2:
extends: .build

qemu-cortex-m3/testimage:
- extends: .build_and_test
+ extends: .build

-qemu-nios2/testimage:
+qemu-nios2:
extends: .build

qemu-x86/testimage:
- extends: .build_and_test
+ extends: .build
diff --git a/ci/testimage.yml b/ci/testimage.yml
index 7ef051b..83e17a7 100644
--- a/ci/testimage.yml
+++ b/ci/testimage.yml
@@ -6,3 +6,4 @@ local_conf_header:
IMAGE_CLASSES += "testimage"
TEST_TARGET = "QemuTargetZephyr"
TEST_SUITES = "zephyr"
+ TESTIMAGE_AUTO = "1"
--
2.17.1


[meta-zephyr][PATCH kirkstone 2/7] CI: add Gitlab CI support

Jon Mason
 

Mostly stolen from meta-arm

NOTE: this differs from upstream in that the kirkstone branch is being
used instead of the master branch in ci/base.yml

Signed-off-by: Jon Mason <jon.mason@...>
Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
.gitlab-ci.yml | 101 +++++++++++++++++++++++++++++++++++++
ci/96b-avenger96.yml | 6 +++
ci/96b-nitrogen.yml | 6 +++
ci/arduino-nano-33-ble.yml | 6 +++
ci/base.yml | 36 +++++++++++++
ci/check-machine-coverage | 26 ++++++++++
ci/check-warnings | 19 +++++++
ci/intel-x86-64.yml | 6 +++
ci/jobs-to-kas | 19 +++++++
ci/logging.yml | 13 +++++
ci/meta-openembedded.yml | 11 ++++
ci/nrf52840dk-nrf52840.yml | 6 +++
ci/qemu-cortex-m3.yml | 12 +++++
ci/qemu-nios2.yml | 10 ++++
ci/qemu-x86.yml | 10 ++++
ci/stm32mp157c-dk2.yml | 6 +++
ci/testimage.yml | 8 +++
ci/update-repos | 40 +++++++++++++++
18 files changed, 341 insertions(+)
create mode 100644 .gitlab-ci.yml
create mode 100644 ci/96b-avenger96.yml
create mode 100644 ci/96b-nitrogen.yml
create mode 100644 ci/arduino-nano-33-ble.yml
create mode 100644 ci/base.yml
create mode 100755 ci/check-machine-coverage
create mode 100755 ci/check-warnings
create mode 100644 ci/intel-x86-64.yml
create mode 100755 ci/jobs-to-kas
create mode 100644 ci/logging.yml
create mode 100644 ci/meta-openembedded.yml
create mode 100644 ci/nrf52840dk-nrf52840.yml
create mode 100644 ci/qemu-cortex-m3.yml
create mode 100644 ci/qemu-nios2.yml
create mode 100644 ci/qemu-x86.yml
create mode 100644 ci/stm32mp157c-dk2.yml
create mode 100644 ci/testimage.yml
create mode 100755 ci/update-repos

diff --git a/.gitlab-ci.yml b/.gitlab-ci.yml
new file mode 100644
index 0000000..68abd32
--- /dev/null
+++ b/.gitlab-ci.yml
@@ -0,0 +1,101 @@
+image: ghcr.io/siemens/kas/kas:latest-release
+
+stages:
+ - prep
+ - build
+
+# Common job fragment to get a worker ready
+.setup:
+ stage: build
+ interruptible: true
+ variables:
+ KAS_WORK_DIR: $CI_PROJECT_DIR/work
+ KAS_REPO_REF_DIR: $CI_BUILDS_DIR/persist/repos
+ SSTATE_DIR: $CI_BUILDS_DIR/persist/sstate
+ DL_DIR: $CI_BUILDS_DIR/persist/downloads
+ BB_LOGCONFIG: $CI_PROJECT_DIR/ci/logging.yml
+ before_script:
+ - echo KAS_WORK_DIR = $KAS_WORK_DIR
+ - echo SSTATE_DIR = $SSTATE_DIR
+ - echo DL_DIR = $DL_DIR
+ - rm -rf $KAS_WORK_DIR
+ - mkdir --verbose --parents $KAS_WORK_DIR $KAS_REPO_REF_DIR $SSTATE_DIR $DL_DIR
+
+# Generalised fragment to do a Kas build
+.build:
+ extends: .setup
+ script:
+ - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
+ - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
+ - kas build $KASFILES
+ - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
+ artifacts:
+ name: "logs"
+ when: on_failure
+ paths:
+ - $CI_PROJECT_DIR/work/build/tmp/work*/**/temp/log.do_*.*
+
+# Workaround for Zephyr not currectly handling TESTIMAGE_AUTO
+.build_and_test:
+ extends: .setup
+ script:
+ - KASFILES=$(./ci/jobs-to-kas "$CI_JOB_NAME")
+ - kas shell --update --force-checkout $KASFILES -c 'cat conf/*.conf'
+ - kas build $KASFILES
+ - kas build $KASFILES -c testimage
+ - ./ci/check-warnings $KAS_WORK_DIR/build/warnings.log
+
+
+#
+# Prep stage, update repositories once
+#
+update-repos:
+ extends: .setup
+ stage: prep
+ script:
+ - flock --verbose --timeout 60 $KAS_REPO_REF_DIR ./ci/update-repos
+
+
+#
+# Bootstrap stage, machine coverage
+#
+
+# What percentage of machines in the layer do we build
+machine-coverage:
+ stage: prep
+ interruptible: true
+ script:
+ - ./ci/check-machine-coverage
+ coverage: '/Coverage: \d+/'
+
+
+#
+# Build stage, the actual build jobs
+#
+
+96b-avenger96:
+ extends: .build
+
+96b-nitrogen:
+ extends: .build
+
+arduino-nano-33-ble:
+ extends: .build
+
+intel-x86-64:
+ extends: .build
+
+nrf52840dk-nrf52840:
+ extends: .build
+
+stm32mp157c-dk2:
+ extends: .build
+
+qemu-cortex-m3/testimage:
+ extends: .build_and_test
+
+qemu-nios2/testimage:
+ extends: .build
+
+qemu-x86/testimage:
+ extends: .build_and_test
diff --git a/ci/96b-avenger96.yml b/ci/96b-avenger96.yml
new file mode 100644
index 0000000..6d632f1
--- /dev/null
+++ b/ci/96b-avenger96.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: 96b-avenger96
diff --git a/ci/96b-nitrogen.yml b/ci/96b-nitrogen.yml
new file mode 100644
index 0000000..ecd96fb
--- /dev/null
+++ b/ci/96b-nitrogen.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: 96b-nitrogen
diff --git a/ci/arduino-nano-33-ble.yml b/ci/arduino-nano-33-ble.yml
new file mode 100644
index 0000000..ca332da
--- /dev/null
+++ b/ci/arduino-nano-33-ble.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: arduino-nano-33-ble
diff --git a/ci/base.yml b/ci/base.yml
new file mode 100644
index 0000000..fb1699c
--- /dev/null
+++ b/ci/base.yml
@@ -0,0 +1,36 @@
+header:
+ version: 11
+ includes:
+ - meta-openembedded.yml
+
+distro: zephyr
+
+defaults:
+ repos:
+ refspec: kirkstone
+
+repos:
+ meta-zephyr:
+ layers:
+ meta-zephyr-core:
+ meta-zephyr-bsp:
+
+ poky:
+ url: https://git.yoctoproject.org/git/poky
+ layers:
+ meta:
+ meta-poky:
+
+env:
+ BB_LOGCONFIG: ""
+
+local_conf_header:
+ base: |
+ BB_SERVER_TIMEOUT = "60"
+ CONF_VERSION = "2"
+ INHERIT += "rm_work"
+
+machine: unset
+
+target:
+ - zephyr-kernel-test-all
diff --git a/ci/check-machine-coverage b/ci/check-machine-coverage
new file mode 100755
index 0000000..19f9571
--- /dev/null
+++ b/ci/check-machine-coverage
@@ -0,0 +1,26 @@
+#! /usr/bin/env python3
+
+from pathlib import Path
+import sys
+
+metazephyr = Path.cwd()
+
+if metazephyr.name != "meta-zephyr":
+ print("Not running inside meta-zephyr")
+ sys.exit(1)
+
+# All machine configurations
+machines = metazephyr.glob("meta-zephyr-bsp/conf/machine/*.conf")
+machines = set(p.stem for p in machines)
+
+# All kas files
+kas = metazephyr.glob("ci/*.yml")
+kas = set(p.stem for p in kas)
+
+missing = machines - kas
+print(f"The following machines are missing: {', '.join(sorted(missing))}.")
+
+covered = len(machines) - len(missing)
+total = len(machines)
+percent = int(covered / total * 100)
+print(f"Coverage: {percent}%")
diff --git a/ci/check-warnings b/ci/check-warnings
new file mode 100755
index 0000000..9d08010
--- /dev/null
+++ b/ci/check-warnings
@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Expects the path to a log file as $1, and if this file has any content
+# then display the contents and exit with an error code.
+
+set -e -u
+
+LOGFILE=$1
+
+LINES=$(grep --invert-match "relocations in \.text" $LOGFILE | wc -l)
+if test "$LINES" -ne 0; then
+ echo ==============================
+ echo The build had warnings/errors:
+ echo ==============================
+ cat $LOGFILE
+ exit 1
+fi
+
+exit 0
diff --git a/ci/intel-x86-64.yml b/ci/intel-x86-64.yml
new file mode 100644
index 0000000..525a38f
--- /dev/null
+++ b/ci/intel-x86-64.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: intel-x86-64
diff --git a/ci/jobs-to-kas b/ci/jobs-to-kas
new file mode 100755
index 0000000..7057970
--- /dev/null
+++ b/ci/jobs-to-kas
@@ -0,0 +1,19 @@
+#! /bin/bash
+
+# Read a GitLab CI job name on $1 and transform it to a
+# list of Kas yaml files
+
+set -e -u
+
+# Read Job namne from $1 and split on /
+IFS=/ read -r -a PARTS<<<$1
+
+# Prefix each part with ci/
+PARTS=("${PARTS[@]/#/ci/}")
+
+# Suffix each part with .yml
+PARTS=("${PARTS[@]/%/.yml}")
+
+# Print colon-separated
+IFS=":"
+echo "${PARTS[*]}"
diff --git a/ci/logging.yml b/ci/logging.yml
new file mode 100644
index 0000000..3af1029
--- /dev/null
+++ b/ci/logging.yml
@@ -0,0 +1,13 @@
+# Python logging configuration to write all warnings to a separate file
+version: 1
+
+handlers:
+ warnings:
+ class: logging.FileHandler
+ level: WARNING
+ filename: warnings.log
+ formatter: BitBake.logfileFormatter
+
+loggers:
+ BitBake:
+ handlers: [warnings]
diff --git a/ci/meta-openembedded.yml b/ci/meta-openembedded.yml
new file mode 100644
index 0000000..bed338d
--- /dev/null
+++ b/ci/meta-openembedded.yml
@@ -0,0 +1,11 @@
+header:
+ version: 11
+
+repos:
+ meta-openembedded:
+ url: https://git.openembedded.org/meta-openembedded
+ layers:
+ meta-filesystems:
+ meta-networking:
+ meta-oe:
+ meta-python:
diff --git a/ci/nrf52840dk-nrf52840.yml b/ci/nrf52840dk-nrf52840.yml
new file mode 100644
index 0000000..cbbf434
--- /dev/null
+++ b/ci/nrf52840dk-nrf52840.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: nrf52840dk-nrf52840
diff --git a/ci/qemu-cortex-m3.yml b/ci/qemu-cortex-m3.yml
new file mode 100644
index 0000000..b01480c
--- /dev/null
+++ b/ci/qemu-cortex-m3.yml
@@ -0,0 +1,12 @@
+header:
+ version: 11
+ includes:
+ - ci/base.yml
+
+local_conf_header:
+ nonbuilding_tests: |
+ ZEPHYRTESTS:remove = "common context pending poll sleep"
+ qemu_opts: |
+ QB_OPT_APPEND = "-icount shift=3,align=off,sleep=on -rtc clock=vm"
+
+machine: qemu-cortex-m3
diff --git a/ci/qemu-nios2.yml b/ci/qemu-nios2.yml
new file mode 100644
index 0000000..c382582
--- /dev/null
+++ b/ci/qemu-nios2.yml
@@ -0,0 +1,10 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+local_conf_header:
+ nonbuilding_tests: |
+ ZEPHYRTESTS:remove = "interrupt"
+
+machine: qemu-nios2
diff --git a/ci/qemu-x86.yml b/ci/qemu-x86.yml
new file mode 100644
index 0000000..ba80dd3
--- /dev/null
+++ b/ci/qemu-x86.yml
@@ -0,0 +1,10 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+local_conf_header:
+ failing_tests: |
+ ZEPHYRTESTS:remove = "pending"
+
+machine: qemu-x86
diff --git a/ci/stm32mp157c-dk2.yml b/ci/stm32mp157c-dk2.yml
new file mode 100644
index 0000000..c833794
--- /dev/null
+++ b/ci/stm32mp157c-dk2.yml
@@ -0,0 +1,6 @@
+header:
+ version: 9
+ includes:
+ - base.yml
+
+machine: stm32mp157c-dk2
diff --git a/ci/testimage.yml b/ci/testimage.yml
new file mode 100644
index 0000000..7ef051b
--- /dev/null
+++ b/ci/testimage.yml
@@ -0,0 +1,8 @@
+header:
+ version: 11
+
+local_conf_header:
+ testimage: |
+ IMAGE_CLASSES += "testimage"
+ TEST_TARGET = "QemuTargetZephyr"
+ TEST_SUITES = "zephyr"
diff --git a/ci/update-repos b/ci/update-repos
new file mode 100755
index 0000000..fa638aa
--- /dev/null
+++ b/ci/update-repos
@@ -0,0 +1,40 @@
+#! /usr/bin/env python3
+
+# Update clones of the repositories we need in KAS_REPO_REF_DIR to speed up fetches
+
+import sys
+import os
+import subprocess
+import pathlib
+
+def repo_shortname(url):
+ # Taken from Kas (Repo.__getattr__) to ensure the logic is right
+ from urllib.parse import urlparse
+ url = urlparse(url)
+ return ('{url.netloc}{url.path}'
+ .format(url=url)
+ .replace('@', '.')
+ .replace(':', '.')
+ .replace('/', '.')
+ .replace('*', '.'))
+
+repositories = (
+ "https://git.yoctoproject.org/git/poky",
+ "https://git.openembedded.org/meta-openembedded",
+)
+
+if __name__ == "__main__":
+ if "KAS_REPO_REF_DIR" not in os.environ:
+ print("KAS_REPO_REF_DIR needs to be set")
+ sys.exit(1)
+
+ base_repodir = pathlib.Path(os.environ["KAS_REPO_REF_DIR"])
+
+ for repo in repositories:
+ repodir = base_repodir / repo_shortname(repo)
+ if repodir.exists():
+ print("Updating %s..." % repo)
+ subprocess.run(["git", "-C", repodir, "fetch"], check=True)
+ else:
+ print("Cloning %s..." % repo)
+ subprocess.run(["git", "clone", "--bare", repo, repodir], check=True)
--
2.17.1


[meta-zephyr][PATCH kirkstone 0/7] Series to add Gitlab CI to kirkstone

Jon Mason
 

Kirkstone was broken for meta-zephyr for weeks, but no one noticed because Gitlab CI is only running on master. Backport the relevant patches from master so this can be more easily detected, and I'll run a nightly kirkstone to my personal Gitlab CI setup (which can be monitored at https://gitlab.com/jonmason00/meta-zephyr/-/pipelines).

NOTE: I was conflicted between squashing the uniquely CI patches into a single one to hide some of the bug fixesin he originals, versus pulling them back to match what was in master. I did the latter, but the former might be more acceptable.

CI run for this series can be seen at https://gitlab.com/jonmason00/meta-zephyr/-/pipelines/602974431

Thanks,
Jon

--

Jon Mason (5):
qemu-nios2: use glibc
CI: add Gitlab CI support
CI: use path to avoid warning
CI: move stm32mp157c-dk2 to be alphabetical
CI: add more targets

Peter Hoyes (2):
zephyrtest: Enable use of TESTIMAGE_AUTO
CI: Use TESTIMAGE_AUTO

.gitlab-ci.yml | 90 ++++++++++++++++++++
ci/96b-avenger96.yml | 6 ++
ci/96b-nitrogen.yml | 20 +++++
ci/arduino-nano-33-ble.yml | 21 +++++
ci/base.yml | 38 +++++++++
ci/check-machine-coverage | 26 ++++++
ci/check-warnings | 19 +++++
ci/intel-x86-64.yml | 6 ++
ci/jobs-to-kas | 19 +++++
ci/logging.yml | 13 +++
ci/meta-openembedded.yml | 11 +++
ci/nrf52840dk-nrf52840.yml | 20 +++++
ci/qemu-cortex-m3.yml | 12 +++
ci/qemu-nios2.yml | 10 +++
ci/qemu-x86.yml | 10 +++
ci/stm32mp157c-dk2.yml | 13 +++
ci/testimage.yml | 9 ++
ci/update-repos | 40 +++++++++
meta-zephyr-bsp/conf/machine/qemu-nios2.conf | 2 +
meta-zephyr-core/classes/zephyrtest.bbclass | 2 +-
meta-zephyr-core/conf/distro/zephyr.conf | 2 +-
21 files changed, 387 insertions(+), 2 deletions(-)
create mode 100644 .gitlab-ci.yml
create mode 100644 ci/96b-avenger96.yml
create mode 100644 ci/96b-nitrogen.yml
create mode 100644 ci/arduino-nano-33-ble.yml
create mode 100644 ci/base.yml
create mode 100755 ci/check-machine-coverage
create mode 100755 ci/check-warnings
create mode 100644 ci/intel-x86-64.yml
create mode 100755 ci/jobs-to-kas
create mode 100644 ci/logging.yml
create mode 100644 ci/meta-openembedded.yml
create mode 100644 ci/nrf52840dk-nrf52840.yml
create mode 100644 ci/qemu-cortex-m3.yml
create mode 100644 ci/qemu-nios2.yml
create mode 100644 ci/qemu-x86.yml
create mode 100644 ci/stm32mp157c-dk2.yml
create mode 100644 ci/testimage.yml
create mode 100755 ci/update-repos

--
2.17.1


Re: BBClass function and symbolic link (symlink) ... I throw in the towel #kirkstone #python #bitbake

Martin Leduc <martin.leduc@...>
 

Hi Joshua,

Everything is around the /etc/version file. I know that this file is generated automatically and this is hardcoded in Yocto. I've to check how to found a workaround on this.

Sorry for this.

Have a great day

-----Message d'origine-----
De : Joshua Watt <jpewhacker@...>
Envoyé : 2 août 2022 11:10
À : Martin Leduc <martin.leduc@...>
Cc : yocto@...
Objet : [EXTERNAL] Re: [yocto] BBClass function and symbolic link (symlink) ... I throw in the towel #python #bitbake #kirkstone

CAUTION: This email originated from outside of Luminator Technology Group. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Tue, Aug 2, 2022 at 10:02 AM Martin Leduc <martin.leduc@...> wrote:

Hi Joshua,

I've founded a second function, in the same class, using ln -s

set_log_folder () {
bbplain "Set var log folder BEGIN"
rm -Rf ${IMAGE_ROOTFS}/var/log
ln -s /mnt/general_data/log/ ${IMAGE_ROOTFS}/var/log
bbplain "Set var log folder END"
}

The logs show "Set var log folder BEGIN" and "Set var log folder END" and no issues ....
Your set version function looks like it's running from the logs, so don't think your function is directly causing a problem. My guess is something else later is crashing or something else unrelated?


What the hell I'm doing wrong....


Martin Leduc
T : (418) 856-6896
martin.leduc@...


-----Message d'origine-----
De : yocto@... <yocto@...> De la
part de Martin Leduc via lists.yoctoproject.org Envoyé : 2 août 2022
10:20 À : Joshua Watt <jpewhacker@...> Cc :
yocto@... Objet : Re: [yocto] BBClass function and
symbolic link (symlink) ... I throw in the towel #python #bitbake
#kirkstone

Hi Joshua,

Thank you for your quick reply.

Please see the crash log in the attachment.

"Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something still isn't working in Warrior that you need, or just in Kirkstone?"
This bbclass is imported from a previous build make using the Yocto Warrior version and the build report no failure using "ln -s" directly, well it compile.

BR,

-----Message d'origine-----
De : Joshua Watt <jpewhacker@...> Envoyé : 2 août 2022 09:57 À :
Martin Leduc <martin.leduc@...> Cc :
yocto@... Objet : [EXTERNAL] Re: [yocto] BBClass
function and symbolic link (symlink) ... I throw in the towel #python
#bitbake #kirkstone

CAUTION: This email originated from outside of Luminator Technology Group. Do not click links or open attachments unless you recognize the sender and know the content is safe.

On Tue, Aug 2, 2022 at 8:44 AM Martin Leduc via lists.yoctoproject.org <martin.leduc=luminator.com@...> wrote:

Hi team,

Well, I throw in the towel. But it's looks like so simple .... for me 🤣🤣.

I've a function to replace the version file in /etc/version. This function is integrated into my mybase-image.bbclass, defined in my layer and I add, in my core-image-minimal.bbappend recipe inherit mybase-image.bbclass.

In my bbclass, I call my function using

ROOTFS_POSTPROCESS_COMMAND += " \
set_version_file ; \
"

My function is written like this
set_version_file() {
bbplain "set_version_file BEGIN"
mkdir -p ${IMAGE_ROOTFS}/etc/tmp/
echo ${PV} > ${IMAGE_ROOTFS}/etc/tmp/version
chmod 644 ${IMAGE_ROOTFS}/etc/tmp/version
rm ${IMAGE_ROOTFS}/etc/version
ln -sf /etc/tmp/version "${IMAGE_ROOTFS}/etc/version"
}
Note: /etc/tmp is just for the purpose of this test

I mean, I don't try to do anything outstanding but the ln -sf line makes my compilation crash BUT.... it works like a charm with Warrior but Kirkstone rejects "ln -sf" command.
Can you provide a little more detail about how it crashes? Also, I'm not quite clear what you mean by "works like a charm with Warrior"; it sounds like something still isn't working in Warrior that you need, or just in Kirkstone?


I'm definitely not the only one who adds symlinks to the recipes

I've also tried:

lnr
inherit relative_symlinks (don't have any impact but I've given it a
try), from the poky folder I've tried grep -r "ln" ./* | grep
bbclass (to validate the syntax) Read many posts on this topic


I'm unable to find where is my issue.

Any ideas are welcome, even if it works like a charm on Warrior but not in Kirkstone.

BR,
Martin