yocto@lists.yoctoproject.org

Recipe fails at do_rm_work due to failed attempt to delete a named pipe (FIFO)

David Antliff

Hi,

I'm working with a PetaLinux 2021.2 project, which defines a recipe called "petalinux-initramfs-image".

# Simple petalinux initramfs image.
DESCRIPTION = "Small image capable of booting a device. The kernel includes \

the Minimal RAM-based Initial Root Filesystem (initramfs), which finds the \

first 'init' program more efficiently."

INITRAMFS_SCRIPTS ?= "initramfs-framework-base \

initramfs-module-e2fs \

initramfs-module-udhcpc \

initramfs-module-searche2fs \

"

INITRAMFS_SCRIPTS_append_k26 = " initramfs-module-exec"

INITRAMFS_PACKAGES ?= "${VIRTUAL-RUNTIME_base-utils} \

base-passwd \

e2fsprogs \

${ROOTFS_BOOTSTRAP_INSTALL} \

${MACHINE_ESSENTIAL_EXTRA_RDEPENDS} \

"

BAD_RECOMMENDATIONS += "initramfs-module-rootfs"

PACKAGE_INSTALL ?= "packagegroup-core-boot ${INITRAMFS_PACKAGES} ${INITRAMFS_SCRIPTS}"

# Do not pollute the initrd image with rootfs features

IMAGE_FEATURES = ""

export IMAGE_BASENAME = "petalinux-initramfs-image"

IMAGE_LINGUAS = ""

LICENSE = "MIT"

IMAGE_FSTYPES = "${INITRAMFS_FSTYPES}"

inherit core-image

IMAGE_ROOTFS_SIZE = "8192"

IMAGE_ROOTFS_EXTRA_SPACE = "0"

rm_work_rootfs[noexec] = "1"

rm_work_rootfs[cleandirs] = ""

RM_WORK_EXCLUDE_ITEMS = "rootfs"

For reasons I don't understand, this recipe fails to build at the do_rm_work task. Looking at the bitbake -v log, I can see that this recipe is somehow causing the temp directory in the build directory to be deleted:

+ rm -rf recipe-sysroot-native

+ for dir in *

+ '[' rootfs = pseudo ']'

+ echo rootfs

+ grep -q -w rootfs

+ for dir in *

+ '[' temp = pseudo ']'

+ echo rootfs

+ grep -q -w temp

+ rm -rf temp

+ ret=0

+ trap '' 0

+ exit 0

ERROR: petalinux-initramfs-image-1.0-r0 do_rm_work: [Errno 2] No such file or directory: '/[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.59670'

I think whatever is calling do_rm_work (in rm_work.bbclass) is creating a named pipe (FIFO) file in the build/...petalinux-initramfs-image/1.0-r0/temp directory, for whatever purpose, and then when this recipe (for whatever reason) causes the deletion of the temp directory and exits, this outer entity then expects to be able to clean up the FIFO file it created, fails to do so, and raises the fatal error.

I'm assuming that this is a problem with the recipe itself, but I (with my limited knowledge and experience in this area) cannot see anything obvious in there that would lead to the inadvertent deletion of the temp directory.

Note that if I add RM_WORK_EXCLUDE += "petalinux-initramfs-image" then the build does not fail and I see this instead:

NOTE: Executing Tasks
+ do_rm_work

+ for p in petalinux-initramfs-image

NOTE: petalinux-initramfs-image-1.0-r0 do_rm_work: rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE

+ '[' petalinux-initramfs-image = petalinux-initramfs-image ']'

+ bbnote 'rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'

+ '[' -p /[removed]/build/tmp/work/zynqmp_generic-xilinx-linux/petalinux-initramfs-image/1.0-r0/temp/fifo.60213 ']'

+ printf '%b\0' 'bbnote rm_work: Skipping petalinux-initramfs-image since it is in RM_WORK_EXCLUDE'

+ exit 0

+ bb_bash_exit_handler 'exit 0'

+ ret=0

+ set +x

There the named pipe file is mentioned, but I'm not sure why a test for its existence is here, interleaved with output from rm_work.bbclass. I don't see that in rm_work.bbclass anywhere - or is it a part of bbnote?

Any idea what's going on with this recipe?

-- David.

M+ & H bugs with Milestone Movements WW2"All,

Stephen Jolley

#57500

All,

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

Priority	Bug ID	Short Description	Changer	Owner	Was	Became
High	14065	Automated ptest regression testing	randy.macleod@...	ross.burton@...	4.1 M2	4.1 M3
Medium+	14775	AB-INT: SDK preparation failure: SState: cannot test file://[...] TimeoutError('timed out')	richard.purdie@...	unassigned@...	4.1 M2	4.1 M3

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Enhancements/Bugs closed WW28!

Stephen Jolley

#57499

All,

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

Who	Count
alejandro@...	2
yogesh.tyagi@...	1
ptsneves@...	1
randy.macleod@...	1
ross.burton@...	1
Grand Total	6

Thanks,

Stephen K. Jolley

Yocto Project Program Manager

( Cell: (208) 244-4460

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

Current high bug count owners for Yocto Project 4.1

Stephen Jolley

#57498

All,

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

Who	Count
michael.opdenacker@...	36
ross.burton@...	27
david.reyna@...	23
bruce.ashfield@...	21
randy.macleod@...	16
richard.purdie@...	10
saul.wold@...	10
JPEWhacker@...	9
sakib.sajal@...	9
Aryaman.Gupta@...	6
tim.orling@...	6
mhalstead@...	5
jon.mason@...	4
akuster808@...	3
tvgamblin@...	2
pavel@...	2
pgowda.cve@...	2
Qi.Chen@...	2
hongxu.jia@...	2
sundeep.kokkonda@...	2
mostthingsweb@...	1
aehs29@...	1
behanw@...	1
martin.beeger@...	1
Ahmed.Hossam@...	1
nicolas.dechesne@...	1
raj.khem@...	1
Martin.Jansa@...	1
thomas.perrot@...	1
shachar@...	1
ola.x.nilsson@...	1
alexandre.belloni@...	1
luca.ceresoli@...	1
alejandro@...	1
open.source@...	1
Grand Total	212

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

#57497

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 410 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, “4.1”, “4.2”, "4.99" and "Future", the more pressing/urgent issues being in "4.1" and then “4.2”.

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

missing cgroups when trying to re-mount rootfs from initramfs busybox image

Embedded 1

#57496

I have busybox with an initramfs. When I try to re-mount the rootfs I
see this. This is with Yocto. Do I need to include systemd in my
initramfs image?

sh-5.0# exec switch_root /root /sbin/init
switch_root: failed to mount moving /run to /root/run: Invalid argument
switch_root: forcing unmount of /run
[  339.929584] systemd[1]: System time before build time, advancing clock.
[  339.974784] systemd[1]: Module 'autofs4' is built in
[  339.980811] systemd[1]: Failed to mount tmpfs at /sys/fs/cgroup: No such file
 or directory
[  339.989411] systemd[1]: Failed to mount cgroup at /sys/fs/cgroup/systemd: No
such file or directory
[!!!!!!] Failed to mount API filesystems.
[  340.024657] systemd[1]: Freezing execution.

Re: Installing gfortran into native sysroot for libgfortran

Philip Balister

#57495

In my notes:

cat /dev/null > conf/locked-signs.inc

Philip

Show quoted text

On 7/11/22 12:49, Gregory Anders wrote:
On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:
  
On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

     On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
      >On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
      >> Problem solved: the issue was actually that I was using a network
      >> sstate cache,
      >> and the cached output of gcc-cross did not contain gfortran.
      >> Disabling the
      >> sstate cache for gcc-cross causes gfortran to be included in the
      >> sysroot and
      >> now all is working as expected.
      >
      >You shouldn't have to disable the sstate cache but glad you got it
      >working. Which release series is that with?

     I am using Xilinx's Petalinux tool, which uses honister under the
     hood. Xilinx maintains an sstate cache for Petalinux, which is quite
     convenient for cutting down build times, but apparently setting the
     FORTRAN variable does not invalidate the sstate cache entry for the
     gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reasonIt is. It was great fun to find the path to disable it when I also had
this issue :)

Philip(Apologies for the double post to the list.)
Philip, would you mind sharing what you did to disable it?
Thanks,
Greg

Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>

#57494

On Friday, July 08, 2022 11:40 AM MDT, Philip Balister <philip@...> wrote:

On 7/8/22 09:12, Khem Raj wrote:


On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...
<mailto:greg@...>> wrote:

    On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
     >On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
     >> Problem solved: the issue was actually that I was using a network
     >> sstate cache,
     >> and the cached output of gcc-cross did not contain gfortran.
     >> Disabling the
     >> sstate cache for gcc-cross causes gfortran to be included in the
     >> sysroot and
     >> now all is working as expected.
     >
     >You shouldn't have to disable the sstate cache but glad you got it
     >working. Which release series is that with?

    I am using Xilinx's Petalinux tool, which uses honister under the
    hood. Xilinx maintains an sstate cache for Petalinux, which is quite
    convenient for cutting down build times, but apparently setting the
    FORTRAN variable does not invalidate the sstate cache entry for the
    gcc-cross recipe (which it should, as it affects the build outputs).


Perhaps it’s using locked sstate which might be the reasonIt is. It was great fun to find the path to disable it when I also had
this issue :)

Philip(Apologies for the double post to the list.)

Philip, would you mind sharing what you did to disable it?

Thanks,

Greg

How to get license text

William Huang

#57493

Hi,
I was wondering if it is possible to get the license information for all of the deployed packages in the image? I know there's a license.manifest file in deploy/licenses, but I'm looking for a file that includes that manifest as well as the paragraph associated with the license. Closest I found was in the /usr/share/common-license folder which has the LICENSE or COPYING file for each package, but I am looking if there's a single file that contains this information instead.

Thanks

Re: Installing gfortran into native sysroot for libgfortran

Gregory Anders <greg@...>

#57492

On Friday, July 08, 2022 08:12 AM MDT, Khem Raj <raj.khem@...> wrote:

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
Problem solved: the issue was actually that I was using a network
sstate cache,
and the cached output of gcc-cross did not contain gfortran.
Disabling the
sstate cache for gcc-cross causes gfortran to be included in the
sysroot and
now all is working as expected.You shouldn't have to disable the sstate cache but glad you got it
working. Which release series is that with?I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).
Perhaps it’s using locked sstate which might be the reasonI didn't know the sstate could be locked -- how would one unlock it? Could you
point me toward some relevant docs?

After some cursory searching the only thing I've found is the 'locked-sigs.inc'
file. And indeed, Petalinux does ship with a locked-sigs.inc file which
includes a signature for gcc-cross-arm. But adding gcc-cross-arm to
SIGGEN_UNLOCKED_RECIPES doesn't seem to have any effect.

ALTERNATIVE and RDEPENDS

Konrad Weihmann <kweihmann@...>

#57491

Hi all,

is there a way to set the package metadata in a way that it would require one of the packages providing a tool via the ALTERNATIVE_ mechanism?

E.g. sed for instance could be provided by busybox (if enabled in config) or by the standalone sed recipe - within my recipe I would just want to make sure that any of the providing packages is available/used when assembling the image.

This basically affects all of the tools that are provided by coreutils and busybox too

I would be happy about any pointer...

Regards
Konrad

Re: source-less python

Aurum Nitrogen

#57490

Hi,

So after a little bit of research, I've implemented this feature in poky.

The way buildroot works, is that it doesn't create any .pyc files during the build process of single packages but has a post rootfs hook that (If that's what the user has configured) compiles the .py files into .pyc files and removes the .py files.

The compilation to .pyc files is done using a small script that uses python's py_compile module.

I have attached the diff to poky for implementation of this feature and the pycompile.py script.

I would love to get your input on this.

Another thing I noticed while doing this research was that the python recipe has a variable called INCLUDE_PYCS that decides if to include the .pyc files in the package. This is nice but why not implement this in the rest of the python package recipes? It can be added to setuptools3.bbclass or something like that. What do you think?

Thanks a lot,

John

‫בתאריך יום ה׳, 23 ביוני 2022 ב-19:10 מאת ‪Ross Burton‬‏ <‪Ross.Burton@...‬‏>:‬

Show quoted text

On 23 Jun 2022, at 23:40, Aurum Nitrogen via lists.yoctoproject.org <aurumnitrogen=gmail.com@...> wrote:
>
> Hi,
> I was wondering if there has been talk about support for source-less python on an image. Installing py and pyc files doubles the size of python on the rootfs. I can imagine this being implemented as an image feature.
> I know that in buildroot it is supported.
> Was this discussed and decided against? Is this an open issue?

There’s an open issue: https://bugzilla.yoctoproject.org/show_bug.cgi?id=6434

The easiest implementation would be a rootfs-time postprocessing step where you compile every .py file, and then delete the .py. Is this what buildroot does?

This does break feeds, but the alternative (of changing how packaging is done) would be a lot more invasive.

Ross
IMPORTANT NOTICE: The contents of this email and any attachments are confidential and may also be privileged. If you are not the intended recipient, please notify the sender immediately and do not disclose the contents to any other person, use it for any purpose, or store or copy the information in any medium. Thank you.

pycompile.py

diff.patch

Re: meta-riscv layer *seems* to have broken opensbi_%.bbappend file

Khem Raj

#57489

On Sun, Jul 10, 2022 at 7:56 AM Robert P. J. Day <rpjday@...> wrote:

the SRC_URI line:

SRC_URI:append:nezha = " \ ...

seems odd since the machine name is actually "nezha-allwinner-d1", not
just "nezha". i checked and the two listed patches there don't appear
to be applied, for what i assume is just that reason.

This is a bug and this should be fixed to use full machine name for override since we do not have nezha SoC override

or is this somehow related to the "nezha.yml" file in the meta-riscv
layer?

No it’s unrelated

rday

meta-riscv layer *seems* to have broken opensbi_%.bbappend file

Robert P. J. Day

#57488

the SRC_URI line:

  SRC_URI:append:nezha = " \ ...

seems odd since the machine name is actually "nezha-allwinner-d1", not
just "nezha". i checked and the two listed patches there don't appear
to be applied, for what i assume is just that reason.

  or is this somehow related to the "nezha.yml" file in the meta-riscv
layer?

rday

Re: Installing gfortran into native sysroot for libgfortran

Philip Balister

#57487

On 7/8/22 09:12, Khem Raj wrote:
On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@... <mailto:greg@...>> wrote:
On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
     >On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
     >> Problem solved: the issue was actually that I was using a network
     >> sstate cache,
     >> and the cached output of gcc-cross did not contain gfortran.
     >> Disabling the
     >> sstate cache for gcc-cross causes gfortran to be included in the
     >> sysroot and
     >> now all is working as expected.
     >
     >You shouldn't have to disable the sstate cache but glad you got it
     >working. Which release series is that with?
I am using Xilinx's Petalinux tool, which uses honister under the
    hood. Xilinx maintains an sstate cache for Petalinux, which is quite
    convenient for cutting down build times, but apparently setting the
    FORTRAN variable does not invalidate the sstate cache entry for the
    gcc-cross recipe (which it should, as it affects the build outputs).
Perhaps it’s using locked sstate which might be the reasonIt is. It was great fun to find the path to disable it when I also had this issue :)

Philip

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

Jon Mason

#57486

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

Signed-off-by: Jon Mason <jon.mason@...>
---
 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 0/3] Gitlab CI for meta-zephyr

Jon Mason

#57485

This series is adding Gitlab CI to meta-zephyr.  I've been running a
version of this on my personal gitlab for some time (see
https://gitlab.com/jonmason00/meta-zephyr/-/pipelines).

This will allow Arm (and anyone else) that wants to run CI as part of
their process for submitting patches to meta-zephyr to verify they work
prior to submission.

In addition to the CI, I've added some patches necessary to get
meta-zephyr working for me.

Thanks,
Jon

Jon Mason (3):
  qemu-nios2: use glibc
  CI: add Gitlab CI support
  CI: Add Richard Purdie's workaround to get meta-zephyr working again

 .gitlab-ci.yml                               | 101 +++++++++++++++++++
 ci/96b-avenger96.yml                         |   6 ++
 ci/96b-nitrogen.yml                          |   6 ++
 ci/arduino-nano-33-ble.yml                   |   6 ++
 ci/base.yml                                  |  37 +++++++
 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 ++++++++
 meta-zephyr-bsp/conf/machine/qemu-nios2.conf |   2 +
 meta-zephyr-core/conf/distro/zephyr.conf     |   2 +-
 20 files changed, 345 insertions(+), 1 deletion(-)
 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

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

Jon Mason

#57484

Mostly stolen from meta-arm

Signed-off-by: Jon Mason <jon.mason@...>
---
 .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..3467c74
--- /dev/null
+++ b/ci/base.yml
@@ -0,0 +1,36 @@
+header:
+  version: 11
+  includes:
+    - meta-openembedded.yml
+
+distro: zephyr
+
+defaults:
+  repos:
+    refspec: master
+
+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 3/3] CI: Add Richard Purdie's workaround to get meta-zephyr working again

Jon Mason

#57483

Issue being tracked at
https://bugzilla.yoctoproject.org/show_bug.cgi?id=14803

Signed-off-by: Jon Mason <jon.mason@...>
---
 ci/base.yml | 1 +
 1 file changed, 1 insertion(+)

diff --git a/ci/base.yml b/ci/base.yml
index 3467c74..5e1683e 100644
--- a/ci/base.yml
+++ b/ci/base.yml
@@ -29,6 +29,7 @@ local_conf_header:
     BB_SERVER_TIMEOUT = "60"
     CONF_VERSION = "2"
     INHERIT += "rm_work"
+    EXTRA_OECONF:append:pn-gcc-runtime = " ac_cv_func_fcntl=no  ac_cv_func_getexecname=no"
 
 machine: unset
 
-- 
2.17.1

Re: Installing gfortran into native sysroot for libgfortran

Khem Raj

#57482

On Fri, Jul 8, 2022 at 2:25 AM Gregory Anders <greg@...> wrote:

On Thu, 07 Jul 2022 16:26 +0100, Richard Purdie wrote:
>On Thu, 2022-07-07 at 06:39 -0700, Gregory Anders wrote:
>> Problem solved: the issue was actually that I was using a network
>> sstate cache,
>> and the cached output of gcc-cross did not contain gfortran.
>> Disabling the
>> sstate cache for gcc-cross causes gfortran to be included in the
>> sysroot and
>> now all is working as expected.
>
>You shouldn't have to disable the sstate cache but glad you got it
>working. Which release series is that with?

I am using Xilinx's Petalinux tool, which uses honister under the
hood. Xilinx maintains an sstate cache for Petalinux, which is quite
convenient for cutting down build times, but apparently setting the
FORTRAN variable does not invalidate the sstate cache entry for the
gcc-cross recipe (which it should, as it affects the build outputs).

Perhaps it’s using locked sstate which might be the reason