Hello,

I have created a recipe to call multiple makefile and set a variable
if it's not defined inside them, meaning I set it before "oe_runmake".
It works as expected on a Debian testing, but with a Ubuntu base
chroot it does not.

I have written a simple recipe and the steps I used to configure the
Ubuntu chroot; on Debian I can see "var -bar-" inside log.do_compile,
but on Ubuntu it will only be "var --".
I'm not sure where the bug is located; I'm using Dunfell but I always
thought the host running Yocto was not relevant during the
compilation.
Thanks.

### Ubuntu chroot: download the image [0], extract it and start the
chroot, update it [1], add the en_US.UTF-8 locale [2], install Yocto
dependencies [3], then add an user.

### testvar.bb
SRC_URI = "file://Makefile"
LICENSE = "CLOSED"
S = "${WORKDIR}"

do_compile() {
FOO=bar oe_runmake
}

### Makefile
all:
@echo "var -$(FOO)-"

clean:


[0] http://cdimage.ubuntu.com/ubuntu-base/releases/20.04/release/ubuntu-base-20.04.2-base-amd64.tar.gz
[1] apt update && apt upgrade
[2] apt install locales && dpkg-reconfigure locales - select "159" then "3"
[3] apt install python3 python3-distutils binutils chrpath cpio cpp
diffstat g++ gawk gcc git make patch wget xxd

On Tue, May 18, 2021 at 11:24 AM Zbigniew Bodek
<zbigniew.bodek@...> wrote:

Hello Jon,

Thanks for your comment. I will try to answer.
This change is to include following bug fix: https://github.com/zephyrproject-rtos/zephyr/pull/33251
I can also see we've had multiple RC versions in the past but in principle, I'm not against your suggestion to have master-next, etc. So where should we go from here?

My recommendation would be to pull that patch out and apply it
directly on top of v2.5.0 (assuming that is feasible). Maybe even
asking the upstream zephyr project to port this to v2.5.0 and make it
v2.5.1 would be the optimal solution.

As far as a master-next branch, that would be up to Naveen.

Kind regards
Zbigniew

-----Original Message-----
From: Jon Mason [mailto:jdmason@...]
Sent: 18 May, 2021 17:17
To: Wojciech Zmuda <zmuda.w@...>
Cc: yocto@...; Zbigniew Bodek <zbigniew.bodek@...>
Subject: Re: [yocto] [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

On Tue, May 18, 2021 at 8:30 AM Wojciech Zmuda <zmuda.w@...> wrote:

From: Zbigniew Bodek <zbigniew.bodek@...>

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...>

Do we really want to have Zephyr on a release candidate? IMHO, we should never be doing this, as we should want the kernel in meta-zephyr to be as stable as possible. If this is really desired, perhaps a master-next branch for things like this.

Thanks,
Jon

---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..9fc08ba 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -2,7 +2,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc

inherit cmake
--
2.25.1

On Tue, May 18, 2021 at 8:30 AM Wojciech Zmuda <zmuda.w@...> wrote:

From: Zbigniew Bodek <zbigniew.bodek@...>

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...>

Do we really want to have Zephyr on a release candidate? IMHO, we
should never be doing this, as we should want the kernel in
meta-zephyr to be as stable as possible. If this is really desired,
perhaps a master-next branch for things like this.

Thanks,
Jon

---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..9fc08ba 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -2,7 +2,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc

inherit cmake
--
2.25.1

Read the generated QEMU conf file, instead of using hard coded values.
This allows for machines not conforming to the hard coded values to work
with testimage.

Signed-off-by: Jon Mason <jon.mason@...>
---
conf/machine/qemu-x86.conf | 1 +
lib/oeqa/utils/qemuzephyrrunner.py | 89 +++++++++++++++++++++++++-----
2 files changed, 77 insertions(+), 13 deletions(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index d85c22215520..ce79b5b1f510 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,6 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
+QB_MACHINE = "-machine type=pc-1.3"
QB_OPT_APPEND = "-nographic -no-acpi"
QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"
diff --git a/lib/oeqa/utils/qemuzephyrrunner.py b/lib/oeqa/utils/qemuzephyrrunner.py
index e8a1bd4544cf..a1ed30be1ca8 100644
--- a/lib/oeqa/utils/qemuzephyrrunner.py
+++ b/lib/oeqa/utils/qemuzephyrrunner.py
@@ -14,6 +14,7 @@ import select
import bb
import tempfile
import sys
+import configparser
from oeqa.utils.qemurunner import QemuRunner

class QemuZephyrRunner(QemuRunner):
@@ -42,6 +43,72 @@ class QemuZephyrRunner(QemuRunner):
# 5 minutes timeout...
self.endtime = time.time() + 60*5

+ self.qemuboot = False
+ self.d = {'QB_KERNEL_ROOT': '/dev/vda'}
+
+ def get(self, key):
+ if key in self.d:
+ return self.d.get(key)
+ elif os.getenv(key):
+ return os.getenv(key)
+ else:
+ return ''
+
+ def set(self, key, value):
+ self.d[key] = value
+
+ def read_qemuboot(self):
+ if not self.qemuboot:
+ if self.get('DEPLOY_DIR_IMAGE'):
+ deploy_dir_image = self.get('DEPLOY_DIR_IMAGE')
+ else:
+ bb.warning("Can't find qemuboot conf file, DEPLOY_DIR_IMAGE is NULL!")
+ return
+
+ if self.rootfs and not os.path.exists(self.rootfs):
+ # Lazy rootfs
+ machine = self.get('MACHINE')
+ if not machine:
+ machine = os.path.basename(deploy_dir_image)
+ self.qemuboot = "%s/%s-%s.qemuboot.conf" % (deploy_dir_image,
+ self.rootfs, machine)
+ else:
+ cmd = 'ls -t %s/*.qemuboot.conf' % deploy_dir_image
+ try:
+ qbs = subprocess.check_output(cmd, shell=True).decode('utf-8')
+ except subprocess.CalledProcessError as err:
+ raise RunQemuError(err)
+ if qbs:
+ for qb in qbs.split():
+ # Don't use initramfs when other choices unless fstype is ramfs
+ if '-initramfs-' in os.path.basename(qb) and self.fstype != 'cpio.gz':
+ continue
+ self.qemuboot = qb
+ break
+ if not self.qemuboot:
+ # Use the first one when no choice
+ self.qemuboot = qbs.split()[0]
+ self.qbconfload = True
+
+ if not self.qemuboot:
+ # If we haven't found a .qemuboot.conf at this point it probably
+ # doesn't exist, continue without
+ return
+
+ if not os.path.exists(self.qemuboot):
+ raise RunQemuError("Failed to find %s (wrong image name or BSP does not support running under qemu?)." % self.qemuboot)
+
+ cf = configparser.ConfigParser()
+ cf.read(self.qemuboot)
+ for k, v in cf.items('config_bsp'):
+ k_upper = k.upper()
+ if v.startswith("../"):
+ v = os.path.abspath(os.path.dirname(self.qemuboot) + "/" + v)
+ elif v == ".":
+ v = os.path.dirname(self.qemuboot)
+ self.set(k_upper, v)
+
+
def create_socket(self):
bb.note("waiting at most %s seconds for qemu pid" % self.runqemutime)
tries = self.runqemutime
@@ -66,7 +133,6 @@ class QemuZephyrRunner(QemuRunner):

if not os.path.exists(self.tmpdir):
bb.error("Invalid TMPDIR path %s" % self.tmpdir)
- #logger.error("Invalid TMPDIR path %s" % self.tmpdir)
return False
else:
os.environ["OE_TMPDIR"] = self.tmpdir
@@ -82,21 +148,18 @@ class QemuZephyrRunner(QemuRunner):
bb.error("Invalid kernel path: %s" % self.kernel)
return False

- self.qemuparams = '-nographic -serial unix:%s,server' % (self.socketname)
- qemu_binary = ""
- if 'arm' in self.machine or 'cortex' in self.machine:
- qemu_binary = 'qemu-system-arm'
- qemu_machine_args = '-machine lm3s6965evb'
- elif 'x86' in self.machine:
- qemu_binary = 'qemu-system-i386'
- qemu_machine_args = '-machine type=pc-1.3 -no-acpi -nographic -cpu qemu32,+nx,+pae'
- elif 'nios2' in self.machine:
- qemu_binary = 'qemu-system-nios2'
- qemu_machine_args = '-machine altera_10m50_zephyr'
- else:
+ self.qemuparams = '-serial unix:%s,server' % (self.socketname)
+
+ self.read_qemuboot()
+ qemu_binary = self.get('QB_SYSTEM_NAME')
+ qemu_machine_args = self.get('QB_MACHINE')
+ if qemu_binary == "" or qemu_machine_args == "":
bb.error("Unsupported QEMU: %s" % self.machine)
return False

+ self.qemuparams += " %s " %self.get('QB_OPT_APPEND')
+ self.qemuparams += " %s " %self.get('QB_CPU')
+
self.origchldhandler = signal.getsignal(signal.SIGCHLD)
signal.signal(signal.SIGCHLD, self.handleSIGCHLD)

--
2.20.1

-----Alkuperäinen viesti-----
Lähettäjä: Richard Purdie <richard.purdie@...>
Lähetetty: tiistai 18. toukokuuta 2021 12.19
There is no direct dependency from do_image_complete on the do_create_spdx
tasks.

You can add:

do_rootfs[recrdeptask] += "do_create_spdx"

but this will have the side effect that the build will never use sstate and always
rebuild since that task isn't an sstate task.

Thanks, I'll give that a go!

I did have a quick look and you're going further than I'd been thinking of, at least
initially.

What I'm thinking of in core YP initially is to have do_packagedata generate
SPDX data for the output packaged files in do_package/do_packagedata. I
noticed you go further and process all the input sources and I'm not sure we're
ready to do that yet.

Doing it at do_package/do_packagedata time would still access any of the
sources included from a debug perspective, hence it should correctly find the
shipped manifest/license info without the complexity of having to scan all the
sources

For your level of source scanning, I'd look at the existing do_populate_lic task
which is sstate and generates license info. I think I'd be in favour of totally
replacing that with something generating spdx output...

I'll give do_populate_lic task a look.

I'm actually hoping we could simply what we're doing today however the more I
look at all the information you can put into SPDX, the more I worry that whilst
we can generate tons of data and huge SPDX files, I'm not sure they're actually
useful to anyone to actually use :/.

We're working on this as a part of a workflow that utilizes the SPDX files. Our tool uploads the source code archived by the layer to a Fossology instance, after which it queries Fossology's API for the file level license and copyright data. We then utilize OSS Review Toolkit by converting the SPDX file to ORT's data format and use ORT's Evaluator and Reporter to evaluate license compliance and create notice files and other reports.

This is done to evaluate the image not based on the declared licenses of packages, which may omit some licenses of individual files, but those individual files.

For the SBOM information, we do need to somehow make something as useful
as our normal manifest to people for this to be useful and adopted, at least from
my perspective.

The huge SPDX files created might indeed not be super useful for all use cases. Long term, some kind of configurability regarding e.g. the level of granularity (packages vs. files) could enable the layer to be used for more use cases than the one we're currently working on.

Mikko

From: Zbigniew Bodek <zbigniew.bodek@...>

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..9fc08ba 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -2,7 +2,7 @@ LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

# Default to a stable version
-PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1"
include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc

inherit cmake
--
2.25.1

From: Zbigniew Bodek <zbigniew.bodek@...>

This version can be selected defining
PREFERRED_VERSION_zephyr-kernel ??= "2.6.0-rc1"

Signed-off-by: Zbigniew Bodek <zbigniew.bodek@...>
---
.../zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
new file mode 100644
index 0000000..6ea1593
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc
@@ -0,0 +1,10 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "v2.6.0-rc1"
+SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_nordic = "574493fe29c79140df4827ab5d4a23df79d03681"
+SRCREV_stm32 = "f8ff8d25aa0a9e65948040c7b47ec67f3fa300df"
+SRCREV_open-amp = "6010f0523cbc75f551d9256cf782f173177acdef"
+SRCREV_libmetal = "39d049d4ae68e6f6d595fce7de1dcfc1024fb4eb"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+
+PV = "2.6.0-rc1+git${SRCPV}"
--
2.25.1

From: Wojciech Zmuda <wojciech.zmuda@...>

2.6.0-rc1 has been released 9 days ago and contains a vast number
of improvements. Release notes available here:
https://github.com/zephyrproject-rtos/zephyr/releases/tag/v2.6.0-rc1

I'm sending this patch set on behalf of the original author
Zbigniew Bodek <zbigniew.bodek@...>

Zbigniew Bodek (2):
zephyr-kernel-src-2.6.0-rc1.inc: Add support for zephyr kernel version
2.6.0-rc1
zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

.../zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc | 10 ++++++++++
recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc | 2 +-
2 files changed, 11 insertions(+), 1 deletion(-)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.6.0-rc1.inc

--
2.25.1

From: Wojciech Zmuda <wojciech.zmuda@...>

Add support for Nordic Semiconductor nRF52840 Development
Kit board.

This is a generic MACHINE over nRF52 SoC family config
plus PyOCD flashing ability.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
conf/machine/nrf52840dk_nrf52840.conf | 8 ++++++++
1 file changed, 8 insertions(+)
create mode 100644 conf/machine/nrf52840dk_nrf52840.conf

diff --git a/conf/machine/nrf52840dk_nrf52840.conf b/conf/machine/nrf52840dk_nrf52840.conf
new file mode 100644
index 0000000..0aa50e0
--- /dev/null
+++ b/conf/machine/nrf52840dk_nrf52840.conf
@@ -0,0 +1,8 @@
+#@TYPE: Machine
+#@NAME: nrf52840dk_nrf52840
+
+#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52840 Development Kit.
+
+require conf/machine/include/nrf52.inc
+ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
+ARCH_nrf52840dk_nrf52840 = "arm"
--
2.25.1

From: Wojciech Zmuda <wojciech.zmuda@...>

The file is so generic anyway it can be targeted for
the nRF52 family without any harm.

Signed-off-by: Wojciech Zmuda <wojciech.zmuda@...>
---
conf/machine/96b-nitrogen.conf | 2 +-
conf/machine/include/{nrf52832.inc => nrf52.inc} | 4 ++--
2 files changed, 3 insertions(+), 3 deletions(-)
rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%)

diff --git a/conf/machine/96b-nitrogen.conf b/conf/machine/96b-nitrogen.conf
index 998db4c..48f2041 100644
--- a/conf/machine/96b-nitrogen.conf
+++ b/conf/machine/96b-nitrogen.conf
@@ -3,6 +3,6 @@

#@DESCRIPTION: Machine configuration for 96Boards Nitrogen Board.

-require conf/machine/include/nrf52832.inc
+require conf/machine/include/nrf52.inc
ZEPHYR_INHERIT_CLASSES += "zephyr-flash-pyocd"
ARCH_96b-nitrogen = "arm"
diff --git a/conf/machine/include/nrf52832.inc b/conf/machine/include/nrf52.inc
similarity index 86%
rename from conf/machine/include/nrf52832.inc
rename to conf/machine/include/nrf52.inc
index e938aa6..d22f8bc 100644
--- a/conf/machine/include/nrf52832.inc
+++ b/conf/machine/include/nrf52.inc
@@ -1,7 +1,7 @@
#@TYPE: Machine
-#@NAME: nrf52832
+#@NAME: nrf52xxx

-#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52832 (Cortex-M4) SoC.
+#@DESCRIPTION: Machine configuration for Nordic Semiconductor nRF52xxx (Cortex-M4) SoC.

require conf/machine/include/tune-cortexm4.inc

--
2.25.1

From: Wojciech Zmuda <wojciech.zmuda@...>

This patch set adds support for Nordic Semiconductor nRF5284
Development Kit board. Since there already is nRF52xx family
chip support added (specifically nRF52832 used in 96Boards
Nitrogen), make this support a bit more generic to cover
the whole family, then add a platform-specific configs
for both nRF-based boards on top of it.

The change has been tested with the actual nRF52840 DK
board by building and flashing with `-c flash_usb`
some sample applications.

Wojciech Zmuda (2):
nrf52832.inc: Rename to nrf52.inc
nrf52840dk_nrf52840.conf: Add nRF52840 DK support

conf/machine/96b-nitrogen.conf | 2 +-
conf/machine/include/{nrf52832.inc => nrf52.inc} | 4 ++--
conf/machine/nrf52840dk_nrf52840.conf | 8 ++++++++
3 files changed, 11 insertions(+), 3 deletions(-)
rename conf/machine/include/{nrf52832.inc => nrf52.inc} (86%)
create mode 100644 conf/machine/nrf52840dk_nrf52840.conf

--
2.25.1

On Tue, 2021-05-18 at 07:09 +0000, Mikko Murto wrote:

Lähettäjä: Richard Purdie <richard.purdie@...>
Lähetetty: tiistai 18. toukokuuta 2021 9.57

On Tue, 2021-05-18 at 06:15 +0000, Mikko Murto wrote:

Hi,

I've created a task do_create_spdx that gets some data from packages
after do_package. The task is currently added with `addtask
do_create_spdx after do_package before do_packagedata` The data is
then enriched and combined in do_image_complete by adding the combining

function to IMAGE_POSTPROCESS_COMMAND.

For the most part everything works as expected, but for some packages
do_create_spdx does not complete in time for the combination step in

do_image_complete.

Is there a way for me force do_image_complete to wait for
do_create_spdx to have been completed for all packages?

This seems a little odd since image.bbclass has:

do_rootfs[recrdeptask] += "do_packagedata"

which means do_rootfs should only happen after all do_packagedata have run.
Your task is added before do_packagedata.
do_image and do_image_complete should run after do_rootfs.

I'm wondering if the issue is more to do with reuse of previous build artefacts
where sstate is involved. Does your added task account for sstate?

That is odd indeed. I need to give it another go. As for accounting for sstate, 
no, at least not intentionally.

I don't have much to go on but guessing, if you run some test and then rerun that
test, the second build would come from sstate. If a build comes from sstate, it will 
skip tasks that precede the sstate artefact.

More specifically, if sstate exists for do_packagedata, it would skip any tasks 
preceeding that task including your do_create_spdx task.

There is no direct dependency from do_image_complete on the do_create_spdx tasks.

You can add:

do_rootfs[recrdeptask] += "do_create_spdx"

but this will have the side effect that the build will never use sstate and always
rebuild since that task isn't an sstate task.

I've been giving some thought to SDPX and SBOM during our build process so I
am curious what you're doing, is the work public anywhere?

Public at https://github.com/doubleopen-project/meta-doubleopen. The usual 
disclaimers about PoC-level spaghetti apply; all questions and comments 
very much appreciated! 😊

I did have a quick look and you're going further than I'd been thinking of, at 
least initially.

What I'm thinking of in core YP initially is to have do_packagedata generate SPDX 
data for the output packaged files in do_package/do_packagedata. I noticed you go
further and process all the input sources and I'm not sure we're ready to do that
yet.

Doing it at do_package/do_packagedata time would still access any of the sources
included from a debug perspective, hence it should correctly find the shipped 
manifest/license info without the complexity of having to scan all the sources

For your level of source scanning, I'd look at the existing do_populate_lic task
which is sstate and generates license info. I think I'd be in favour of totally 
replacing that with something generating spdx output...

I'm actually hoping we could simply what we're doing today however the more I look
at all the information you can put into SPDX, the more I worry that whilst we can
generate tons of data and huge SPDX files, I'm not sure they're actually useful
to anyone to actually use :/.

For the SBOM information, we do need to somehow make something as useful as our
normal manifest to people for this to be useful and adopted, at least from my 
perspective.

Cheers,

Richard

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.3.1.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 is next Thursday, May 20.


Thanks,
Sangeeta

Lähettäjä: Richard Purdie <richard.purdie@...>
Lähetetty: tiistai 18. toukokuuta 2021 9.57

On Tue, 2021-05-18 at 06:15 +0000, Mikko Murto wrote:

Hi,

I've created a task do_create_spdx that gets some data from packages
after do_package. The task is currently added with `addtask
do_create_spdx after do_package before do_packagedata` The data is
then enriched and combined in do_image_complete by adding the combining

function to IMAGE_POSTPROCESS_COMMAND.

For the most part everything works as expected, but for some packages
do_create_spdx does not complete in time for the combination step in

do_image_complete.

Is there a way for me force do_image_complete to wait for
do_create_spdx to have been completed for all packages?

This seems a little odd since image.bbclass has:

do_rootfs[recrdeptask] += "do_packagedata"

which means do_rootfs should only happen after all do_packagedata have run.
Your task is added before do_packagedata.
do_image and do_image_complete should run after do_rootfs.

I'm wondering if the issue is more to do with reuse of previous build artefacts
where sstate is involved. Does your added task account for sstate?

That is odd indeed. I need to give it another go. As for accounting for sstate, no, at least not intentionally.

I've been giving some thought to SDPX and SBOM during our build process so I
am curious what you're doing, is the work public anywhere?

Public at https://github.com/doubleopen-project/meta-doubleopen. The usual disclaimers about PoC-level spaghetti apply; all questions and comments very much appreciated! 😊

Mikko

On Tue, 2021-05-18 at 06:15 +0000, Mikko Murto wrote:

Hi,

I've created a task do_create_spdx that gets some data from packages after 
do_package. The task is currently added with `addtask do_create_spdx after 
do_package before do_packagedata` The data is then enriched and combined in 
do_image_complete by adding the combining function to IMAGE_POSTPROCESS_COMMAND. 
For the most part everything works as expected, but for some packages 
do_create_spdx does not complete in time for the combination step in do_image_complete. 
Is there a way for me force do_image_complete to wait for do_create_spdx to have been 
completed for all packages?

This seems a little odd since image.bbclass has:

do_rootfs[recrdeptask] += "do_packagedata"

which means do_rootfs should only happen after all do_packagedata have run.
Your task is added before do_packagedata.
do_image and do_image_complete should run after do_rootfs.

I'm wondering if the issue is more to do with reuse of previous build artefacts where
sstate is involved. Does your added task account for sstate?

I've been giving some thought to SDPX and SBOM during our build process
so I am curious what you're doing, is the work public anywhere?

Cheers,

Richard

Hi,

I've created a task do_create_spdx that gets some data from packages after do_package. The task is currently added with `addtask do_create_spdx after do_package before do_packagedata` The data is then enriched and combined in do_image_complete by adding the combining function to IMAGE_POSTPROCESS_COMMAND. For the most part everything works as expected, but for some packages do_create_spdx does not complete in time for the combination step in do_image_complete. Is there a way for me force do_image_complete to wait for do_create_spdx to have been completed for all packages?

Best regards,
Mikko Murto

On Mon, May 17, 2021 at 10:57 PM sateesh m <sateesh0457@...> wrote:

Hi ,

I am trying to run vlc-3.0.11 media player on my riscv target board. I am facing problem this package

[cli] lua interface error: Error loading script /usr/lib/vlc/lua/intf/cli.luac: ../../vlc-3.0.11.1/share/lua/modules/common.lua:3: attempt to call a nil value (global 'module')

lua package also I installed version is 5.3.6 .

usually it means lua version mismatch. You might be hitting same issue
as reported here

https://trac.videolan.org/vlc/ticket/25036

there is a patch attached to that ticket. Please try to apply that and
see if it helps.

https://trac.videolan.org/vlc/attachment/ticket/25036/0001-lua-Make-scripts-compatible-to-lua-5.4.patch

How can I fix this issue. Is I need to apply patch for this?if patch is present please give me guidance. Can anybody knows this problem help me.

Thanking you in advance.
--
Regards,
Sateesh

Hi ,

   I am trying to run vlc-3.0.11 media player on my riscv target board.  I am facing problem this package 

 [cli] lua interface error: Error loading script /usr/lib/vlc/lua/intf/cli.luac: ../../vlc-3.0.11.1/share/lua/modules/common.lua:3: attempt to call a nil value (global 'module')

lua package also I installed version is 5.3.6 .

How can I fix this issue. Is I need to apply patch for this?if patch is present please give me guidance. Can anybody knows this problem help me.

Thanking you in advance.
--
Regards,
Sateesh

Hi ,

   I am trying to run vlc-3.0.11 media player on my riscv target board.  I am facing problem this package 

 [cli] lua interface error: Error loading script /usr/lib/vlc/lua/intf/cli.luac: ../../vlc-3.0.11.1/share/lua/modules/common.lua:3: attempt to call a nil value (global 'module')

lua package also I installed version is 5.3.6 .

How can I fix this issue. Is I need to apply patch for this?if patch is present please give me guidance. Can anybody knows this problem help me.

Thanking you in advance.
--
Regards,
Sateesh