Date   

[meta-zephy][PATCH 08/14] zephyr-kernel.inc: Remove include file

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

This file has little advantage and can be easily replaced by just
directly including the src include file.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-image.inc | 2 +-
recipes-kernel/zephyr-kernel/zephyr-kernel.inc | 4 ----
2 files changed, 1 insertion(+), 5 deletions(-)
delete mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-image.inc b/recipes-kernel/zephyr-kernel/zephyr-image.inc
index e8b8871..c77692d 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-image.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-image.inc
@@ -1,4 +1,4 @@
-require zephyr-kernel.inc
+require zephyr-kernel-src.inc
require zephyr-kernel-common.inc

inherit testimage
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
deleted file mode 100644
index 903973d..0000000
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel.inc
+++ /dev/null
@@ -1,4 +0,0 @@
-
-inherit zephyr-kernel-src
-
-S = "${WORKDIR}/git"
--
2.30.1


[meta-zephy][PATCH 07/14] zephyr-kernel-common.inc: Reformat EXTRA_OECMAKE

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

This will improve diffs readability in the future.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 11 ++++++++++-
1 file changed, 10 insertions(+), 1 deletion(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index abc55ba..330fe59 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -13,7 +13,16 @@ ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"

-EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto -DEXTRA_CPPFLAGS=${CPPFLAGS}"
+EXTRA_OECMAKE = "\
+ -DZEPHYR_BASE=${S} \
+ -DZEPHYR_GCC_VARIANT=yocto \
+ -DBOARD=${BOARD} \
+ -DARCH=${ARCH} \
+ -DCROSS_COMPILE=${CROSS_COMPILE} \
+ -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} \
+ -DZEPHYR_TOOLCHAIN_VARIANT=yocto \
+ -DEXTRA_CPPFLAGS=${CPPFLAGS} \
+ "

ZEPHYR_MODULES = ""
ZEPHYR_MODULES_append_arm = "\;${S}/modules/cmsis"
--
2.30.1


[meta-zephy][PATCH 06/14] zephyr-kernel-common.inc: Fix configuration CPPFLAGS warning

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

Configure warns when CPPFLAGS is provided as environment variable and
expects its value to be passed to cmake. This patch does that to
surpress the warning.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc | 9 ++++++---
1 file changed, 6 insertions(+), 3 deletions(-)

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
index 5313030..abc55ba 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-common.inc
@@ -13,8 +13,7 @@ ZEPHYR_SYSROOT="${STAGING_DIR_TARGET}"

ZEPHYR_MAKE_OUTPUT = "zephyr.elf"

-
-EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto"
+EXTRA_OECMAKE = " -DZEPHYR_BASE=${S} -DZEPHYR_GCC_VARIANT=yocto -DBOARD=${BOARD} -DARCH=${ARCH} -DCROSS_COMPILE=${CROSS_COMPILE} -DZEPHYR_SYSROOT=${ZEPHYR_SYSROOT} -DZEPHYR_TOOLCHAIN_VARIANT=yocto -DEXTRA_CPPFLAGS=${CPPFLAGS}"

ZEPHYR_MODULES = ""
ZEPHYR_MODULES_append_arm = "\;${S}/modules/cmsis"
@@ -26,7 +25,6 @@ EXTRA_OECMAKE_append = " -DZEPHYR_MODULES=${ZEPHYR_MODULES}"

export ZEPHYR_BASE="${S}"

-
DEPENDS += "gperf-native python3-pyelftools-native python3-pyyaml-native python3-pykwalify-native"
CROSS_COMPILE = "${STAGING_BINDIR_TOOLCHAIN}/${TARGET_PREFIX}"

@@ -51,3 +49,8 @@ OE_TERMINAL_EXPORTS += "ZEPHYR_SYSROOT"
OE_TERMINAL_EXPORTS += "ZEPHYR_GCC_VARIANT"

IMAGE_FSTYPES = "elf bin"
+
+do_configure_prepend() {
+ # Zephyr expects CPPFLAGS as cmake argument as and ignores env variables.
+ unset CPPFLAGS
+}
--
2.30.1


[meta-zephy][PATCH 05/14] zephyr-kernel-src-2.5.0-rc3.inc: Add support for zephyr kernel version 2.5.0-rc3

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

This version can be selected defining
PREFERRED_VERSION_zephyr-kernel ??= "2.5.0-rc3"

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
.../zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc | 10 ++++++++++
1 file changed, 10 insertions(+)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc

diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc
new file mode 100644
index 0000000..4ee9883
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0-rc3.inc
@@ -0,0 +1,10 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "v2.5.0-rc3"
+SRCREV_cmsis = "c3bd2094f92d574377f7af2aec147ae181aa5f8e"
+SRCREV_nordic = "f3434da6446380fcdd426dbe2866af21d0d549b6"
+SRCREV_stm32 = "cc8731dba4fd9c57d7fe8ea6149828b89c2bd635"
+SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
+SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+
+PV = "2.5.0-rc3+git${SRCPV}"
--
2.30.1


[meta-zephy][PATCH 04/14] zephyr-kernel-src: Restructure recipe

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

* Restructure recipe to use include files as opposed to a bbclass. The
latter is unnatural when defining versions, sources etc.
* Make the zephyr-kernel-src follow the version as defined by
PREFERRED_VERSION_zephyr-kernel.
* Make the setup of the zephyr-kernel-src.inc extensible for multiple
versions.

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-kernel-src.bbclass | 37 -------------------
.../zephyr-kernel/zephyr-kernel-src-2.4.0.inc | 10 +++++
...kernel-src_2.4.bb => zephyr-kernel-src.bb} | 9 +----
.../zephyr-kernel/zephyr-kernel-src.inc | 20 ++++++++++
4 files changed, 32 insertions(+), 44 deletions(-)
delete mode 100644 classes/zephyr-kernel-src.bbclass
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
rename recipes-kernel/zephyr-kernel/{zephyr-kernel-src_2.4.bb => zephyr-kernel-src.bb} (80%)
create mode 100644 recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc

diff --git a/classes/zephyr-kernel-src.bbclass b/classes/zephyr-kernel-src.bbclass
deleted file mode 100644
index c6c8d61..0000000
--- a/classes/zephyr-kernel-src.bbclass
+++ /dev/null
@@ -1,37 +0,0 @@
-#Set relevant variables based on Zephyr kernel version
-
-PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
-
-SRCREV_FORMAT = "default_cmsis"
-SRCREV_default = "7a3b253ced7333f5c0269387a7f3ed1dee69739d"
-SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"
-SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
-SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
-SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
-SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
-SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
-
-SRC_URI = "git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=v2.4-branch;name=default \
- git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
- git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
- git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
- git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
- git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
- git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
- file://0001-cmake-add-yocto-toolchain.patch \
- "
-
-PV = "2.4.0+git${SRCPV}"
-
-LICENSE = "Apache-2.0"
-LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
-
-ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"
-
-python () {
- src_pn = d.getVar('PREFERRED_VERSION_zephyr-kernel', True)
- if src_pn == '2.4.0':
- return
- else:
- bb.error("Unsupported Zephyr kernel version requested")
-}
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
new file mode 100644
index 0000000..d1ef80e
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.4.0.inc
@@ -0,0 +1,10 @@
+SRCREV_FORMAT = "default_cmsis"
+SRCREV_default = "7a3b253ced7333f5c0269387a7f3ed1dee69739d"
+SRCREV_cmsis = "542b2296e6d515b265e25c6b7208e8fea3014f90"
+SRCREV_nordic = "d8a6ea9695ddf792bb18bb6035c13b1daac5d79c"
+SRCREV_stm32 = "f0e11398128ac9abdff713da5d3035e6c96e9b86"
+SRCREV_open-amp = "de1b85a13032a2de1d8b6695ae5f800b613e739d"
+SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
+SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"
+
+PV = "2.4.0+git${SRCPV}"
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
similarity index 80%
rename from recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb
rename to recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
index 8e8b5b8..210cfa7 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src_2.4.bb
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.bb
@@ -1,16 +1,12 @@
+include zephyr-kernel-src.inc

-inherit zephyr-kernel-src
-inherit cmake
-
-S = "${WORKDIR}/git"
+ZEPHYR_TEST_SRCDIR = "tests/legacy/kernel/"

IMAGE_NO_MANIFEST = "1"
INHIBIT_DEFAULT_DEPS = "1"

do_configure[noexec] = "1"
do_compile[noexec] = "1"
-
-
do_install () {
kerneldir=${D}/usr/src/zephyr
install -d $kerneldir
@@ -21,4 +17,3 @@ PACKAGES = "${PN}"
FILES_${PN} = "/usr/src/zephyr"

SYSROOT_DIRS += "/usr/src/zephyr"
-
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
new file mode 100644
index 0000000..2dcde74
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -0,0 +1,20 @@
+LICENSE = "Apache-2.0"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.4.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
+
+inherit cmake
+
+SRC_URI = "\
+ git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=master;name=default \
+ git://github.com/zephyrproject-rtos/cmsis.git;protocol=https;destsuffix=git/modules/cmsis;name=cmsis \
+ git://github.com/zephyrproject-rtos/hal_nordic.git;protocol=https;destsuffix=git/modules/hal/nordic;name=nordic \
+ git://github.com/zephyrproject-rtos/hal_stm32.git;protocol=https;destsuffix=git/modules/hal/stm32;name=stm32 \
+ git://github.com/zephyrproject-rtos/open-amp.git;protocol=https;destsuffix=git/modules/lib/open-amp;name=open-amp \
+ git://github.com/zephyrproject-rtos/libmetal.git;protocol=https;destsuffix=git/modules/hal/libmetal;name=libmetal \
+ git://github.com/zephyrproject-rtos/tinycrypt.git;protocol=https;destsuffix=git/modules/crypto/tinycrypt;name=tinycrypt \
+ file://0001-cmake-add-yocto-toolchain.patch \
+ "
+S = "${WORKDIR}/git"
--
2.30.1


[meta-zephy][PATCH 03/14] Cleanup superflous new lines

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyrtest.bbclass | 2 --
conf/distro/zephyr.conf | 1 -
conf/machine/include/tune-arc.inc | 1 -
conf/machine/include/tune-iamcu.inc | 1 -
conf/machine/include/tune-nios2.inc | 1 -
5 files changed, 6 deletions(-)

diff --git a/classes/zephyrtest.bbclass b/classes/zephyrtest.bbclass
index 3acc4c3..248fd15 100644
--- a/classes/zephyrtest.bbclass
+++ b/classes/zephyrtest.bbclass
@@ -51,5 +51,3 @@ python testdata_clean() {
}

addtask do_testdata_write before do_build after do_deploy
-
-
diff --git a/conf/distro/zephyr.conf b/conf/distro/zephyr.conf
index a98da32..6ecd421 100644
--- a/conf/distro/zephyr.conf
+++ b/conf/distro/zephyr.conf
@@ -1,4 +1,3 @@
-
DISTRO = "zephyr"
DISTRO_NAME = "Zephyr"
DISTRO_VERSION = "1.0"
diff --git a/conf/machine/include/tune-arc.inc b/conf/machine/include/tune-arc.inc
index 4bb6f4f..ff841e7 100644
--- a/conf/machine/include/tune-arc.inc
+++ b/conf/machine/include/tune-arc.inc
@@ -18,4 +18,3 @@ AVAILTUNES += "no-sdata"
TUNEVALID[nodata] = "ARC no-delete-null-pointer-checks"
TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'no-delete-null-pointer-checks', ' -fno-delete-null-pointer-checks', '', d)}"
AVAILTUNES += "no-delete-null-pointer-checks"
-
diff --git a/conf/machine/include/tune-iamcu.inc b/conf/machine/include/tune-iamcu.inc
index 6935375..20a93a6 100644
--- a/conf/machine/include/tune-iamcu.inc
+++ b/conf/machine/include/tune-iamcu.inc
@@ -9,4 +9,3 @@ TUNE_ARCH = "i586"
TUNEVALID[iamcu] = "Intel MCU"

PACKAGE_EXTRA_ARCHS_tune-iamcu = "iamcu"
-
diff --git a/conf/machine/include/tune-nios2.inc b/conf/machine/include/tune-nios2.inc
index c74326d..e8662eb 100644
--- a/conf/machine/include/tune-nios2.inc
+++ b/conf/machine/include/tune-nios2.inc
@@ -1,4 +1,3 @@
-
# Nios2 Architecture Definition

DEFAULTTUNE ?= "nios2"
--
2.30.1


[meta-zephy][PATCH 02/14] zephyr-flash-pyocd.bbclass: Add missing do_flash_usb dependency on do_deploy

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-flash-pyocd.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-flash-pyocd.bbclass b/classes/zephyr-flash-pyocd.bbclass
index 04500af..eca30c9 100644
--- a/classes/zephyr-flash-pyocd.bbclass
+++ b/classes/zephyr-flash-pyocd.bbclass
@@ -10,7 +10,7 @@ python do_flash_usb() {
session.board.target.reset()
}

-addtask do_flash_usb
+addtask do_flash_usb after do_deploy

do_flash_usb[nostamp] = "1"
do_flash_usb[vardepsexclude] = "BB_ORIGENV"
--
2.30.1


[meta-zephy][PATCH 01/14] zephyr-flash-dfu.bbclass: Add missing do_flash_usb dependency on do_deploy

Andrei Gherzan
 

From: Andrei Gherzan <andrei.gherzan@huawei.com>

Signed-off-by: Andrei Gherzan <andrei.gherzan@huawei.com>
---
classes/zephyr-flash-dfu.bbclass | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/classes/zephyr-flash-dfu.bbclass b/classes/zephyr-flash-dfu.bbclass
index 32f589a..b4f3d49 100644
--- a/classes/zephyr-flash-dfu.bbclass
+++ b/classes/zephyr-flash-dfu.bbclass
@@ -59,7 +59,7 @@ python do_flash_usb() {
bb.utils.unlockfile(lock)
}

-addtask do_flash_usb
+addtask do_flash_usb after do_deploy

do_flash_usb[nostamp] = "1"
do_flash_usb[vardepsexclude] = "BB_ORIGENV"
--
2.30.1


Re: [meta-security-compliance][PATCH] scap-security-guide: Fix openembedded platform tests and build

Jate Sujjavanich
 

Ping

On Sun, Jan 10, 2021 at 11:21 AM Jate Sujjavanich <jatedev@...> wrote:
Add patches to fix openembedded nodistro tests and openembedded build within
ssg metadata.

Signed-Off-By: Jate Sujjavanich <jatedev@...>
---
 ...c-file-check-tests-in-installed-OS-d.patch | 46 +++++++++++++++++++
 ...g-openembedded-from-ssg-constants.py.patch | 34 ++++++++++++++
 .../scap-security-guide_git.bb                |  2 +
 3 files changed, 82 insertions(+)
 create mode 100644 meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
 create mode 100644 meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch

diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
new file mode 100644
index 0000000..60664a3
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch
@@ -0,0 +1,46 @@
+From 2beb4bc83a157b21edb1a3fef295cd4cced467df Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@...>
+Date: Thu, 7 Jan 2021 18:10:01 -0500
+Subject: [PATCH 1/3] Fix platform spec, file check, tests in installed OS
+ detect for openembedded
+
+Change platform to multi in openembedded installed check matching others
+and allowing compile of xml into oval
+---
+ shared/checks/oval/installed_OS_is_openembedded.xml | 11 ++++++-----
+ 1 file changed, 6 insertions(+), 5 deletions(-)
+
+diff --git a/shared/checks/oval/installed_OS_is_openembedded.xml b/shared/checks/oval/installed_OS_is_openembedded.xml
+index 763d17bcb..01df16b43 100644
+--- a/shared/checks/oval/installed_OS_is_openembedded.xml
++++ b/shared/checks/oval/installed_OS_is_openembedded.xml
+@@ -1,11 +1,9 @@
+-</def-group>
+-
+ <def-group>
+   <definition class="inventory" id="installed_OS_is_openembedded" version="2">
+     <metadata>
+       <title>OpenEmbedded</title>
+       <affected family="unix">
+-        <platform>OPENEMBEDDED</platform>
++        <platform>multi_platform_all</platform>
+       </affected>
+       <reference ref_id="cpe:/o:openembedded:openembedded:0"
+       source="CPE" />
+@@ -20,8 +18,11 @@
+     </criteria>
+   </definition>
+
+-  <ind:textfilecontent54_object id="test_openembedded" version="1" comment="Check OPenEmbedded version">
+-    <ind:filepath>/etc/os-release/ind:filepath>
++  <ind:textfilecontent54_test check="all" check_existence="at_least_one_exists" comment="Check OpenEmbedded version" id="test_openembedded" version="1">
++    <ind:object object_ref="obj_openembedded" />
++  </ind:textfilecontent54_test>
++  <ind:textfilecontent54_object id="obj_openembedded" version="1" comment="Check OpenEmbedded version">
++    <ind:filepath>/etc/os-release</ind:filepath>
+     <ind:pattern operation="pattern match">^VERSION_ID=\"nodistro\.[0-9].$</ind:pattern>
+     <ind:instance datatype="int">1</ind:instance>
+   </ind:textfilecontent54_object>
+--
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch
new file mode 100644
index 0000000..1e712f6
--- /dev/null
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/files/0002-Fix-missing-openembedded-from-ssg-constants.py.patch
@@ -0,0 +1,34 @@
+From 037a12301968a56f0c7e492ea4a05d2eecbd4cc6 Mon Sep 17 00:00:00 2001
+From: Jate Sujjavanich <jatedev@...>
+Date: Fri, 8 Jan 2021 20:18:00 -0500
+Subject: [PATCH 2/3] Fix missing openembedded from ssg/constants.py
+
+---
+ ssg/constants.py | 4 +++-
+ 1 file changed, 3 insertions(+), 1 deletion(-)
+
+diff --git a/ssg/constants.py b/ssg/constants.py
+index fab7cda5d..2ca289f84 100644
+--- a/ssg/constants.py
++++ b/ssg/constants.py
+@@ -234,7 +234,8 @@ PRODUCT_TO_CPE_MAPPING = {
+ }
+
+ MULTI_PLATFORM_LIST = ["rhel", "fedora", "rhosp", "rhv", "debian", "ubuntu",
+-                       "wrlinux", "opensuse", "sle", "ol", "ocp", "example"]
++                       "wrlinux", "opensuse", "sle", "ol", "ocp", "example",
++                       "openembedded"]
+
+ MULTI_PLATFORM_MAPPING = {
+     "multi_platform_debian": ["debian8"],
+@@ -249,6 +250,7 @@ MULTI_PLATFORM_MAPPING = {
+     "multi_platform_sle": ["sle11", "sle12"],
+     "multi_platform_ubuntu": ["ubuntu1404", "ubuntu1604", "ubuntu1804"],
+     "multi_platform_wrlinux": ["wrlinux"],
++    "multi_platform_openembedded": ["openembedded"],
+ }
+
+ RHEL_CENTOS_CPE_MAPPING = {
+--
+2.24.3 (Apple Git-128)
+
diff --git a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
index 6e7180f..0617c56 100644
--- a/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
+++ b/meta-security-compliance/recipes-openscap/scap-security-guide/scap-security-guide_git.bb
@@ -7,6 +7,8 @@ SRC_URI = "git://github.com/akuster/scap-security-guide.git;branch=oe-0.1.44; \
            file://0001-fix-deprecated-instance-of-element.getchildren.patch \
            file://0002-fix-deprecated-getiterator-function.patch \
            file://0003-fix-remaining-getchildren-and-getiterator-functions.patch \
+           file://0001-Fix-platform-spec-file-check-tests-in-installed-OS-d.patch \
+           file://0002-Fix-missing-openembedded-from-ssg-constants.py.patch \
           "
 PV = "0.1.44+git${SRCPV}"

--
2.25.1


Re: Yocto Technical Team Minutes, Engineering Sync, for Feb 9 2021

Ross Burton
 

On Thu, 11 Feb 2021 at 21:14, Trevor Woerner <twoerner@gmail.com> wrote:
RP: there’s been a lot of churn in the versions (glibc, kernel, etc). if
anyone sees anything please raise a flag
Ross: yes, I’ve seen some issues, not always 100% reproducible
RP: x86 host?
Ross: not always
TimO: ubuntu host?
Ross: 20.04
RP: glibc-2.33 does have some interesting things, so i’m not surprised there
are issues
Randy: what are you seeing?
Ross: issues building the kernel (“dangerous relocations”)
RP: for dunfell we did a glibc-2.32 update but we’ll hold off on glibc-2.33
(thanks Michael!)
Ross: turning off uninative makes it go away
TimO: is that a Xen kernel?
Ross: no, just defconfig
I solved this issue: when running inside a container that uses seccomp
to filter the syscalls available, with glibc 2.33 inside (uninative,
for example), applications might end up calling faccessat2() (glibc
does this itself) which as a relatively new syscall is rejected by the
syscall filter. The rejection is EPERM but glibc only handles ENOSYS
so weird things happen.

I sent a workaround to oe-core, systemd 247 and Docker 20.10 are
fixed, but glibc appear to consider this a bug in other software and
not something it should handle.

Ross


Regarding Mender integration

U RAVI KUMAR <uppadaravi2511@...>
 

Hello folks,

I have some issues while integrating the mender on the yocto project.I have included meta-mener-core,meta-mender-raspberrypi layers.And iam getting the following error:

ERROR: u-boot-1_2020.07-r0 do_patch: Command Error: 'quilt --quiltrc /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/recipe-sysroot-native/etc/quiltrc push' exited with 0  Output:
Applying patch 0001-configs-rpi-enable-mender-requirements.patch
patching file configs/rpi_0_w_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_0_w_defconfig
patching file configs/rpi_2_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_2_defconfig
patching file configs/rpi_3_32b_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_32b_defconfig
patching file configs/rpi_3_b_plus_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_b_plus_defconfig
patching file configs/rpi_3_defconfig
Hunk #1 FAILED at 20.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_3_defconfig
patching file configs/rpi_4_32b_defconfig
Hunk #1 FAILED at 16.
Hunk #2 succeeded at 45 (offset 12 lines).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_4_32b_defconfig
patching file configs/rpi_4_defconfig
Hunk #1 FAILED at 16.
Hunk #2 succeeded at 45 (offset 12 lines).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_4_defconfig
patching file configs/rpi_arm64_defconfig
Hunk #1 FAILED at 17.
Hunk #2 succeeded at 43 (offset 1 line).
1 out of 2 hunks FAILED -- rejects in file configs/rpi_arm64_defconfig
patching file configs/rpi_defconfig
Hunk #1 FAILED at 19.
1 out of 2 hunks FAILED -- rejects in file configs/rpi_defconfig
patching file env/Kconfig
Hunk #1 succeeded at 55 (offset 6 lines).
patching file include/configs/rpi.h
Hunk #1 succeeded at 97 (offset 17 lines).
Patch 0001-configs-rpi-enable-mender-requirements.patch does not apply (enforce with -f)
ERROR: Logfile of failure stored in: /home/ravi_uppada/work/vm/sato/poky/build/tmp/work/raspberrypi4_64-poky-linux/u-boot/1_2020.07-r0/temp/log.do_patch.5091
ERROR: Task (/home/ravi_uppada/work/vm/sato/poky/meta/recipes-bsp/u-boot/u-boot_2020.07.bb:do_patch) failed with exit code '1'



Have added in the path : /DIRECTORY_BUILD/sato/poky/layers/meta-mender/meta-mender-core/recipes-bsp/u-boot
 Have added the lines in this file : u-boot_%.bbappend.

Please help me out this.I have been trying this from very long.Please address this issue.

Thanks,
RAVI_UPPADA


Re: Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

Robert Berger
 

Hi,

My comments are in-line.


On 12/02/2021 14:30, Ross Burton wrote:
The first question is why. It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto. I'm struggling to see what this
would achieve.
... a legal battle maybe?

Bring in the lawyers!

I would also ask:

"What is your use case?"
"Did you ask Canonical?"
"Does Canonical allow you to do this?"

From [1]:

"Copyright licensing[1] and trademarks[3] are two different areas of law, and we consider them separately in Ubuntu. The following policy applies only to copyright licences. We evaluate trademarks on a case-by-case basis."

From [4]:

"
You can download, install and receive updates to Ubuntu for free.

You can modify Ubuntu for personal or internal commercial use.

You can redistribute Ubuntu, but only where there has been no modification to it.

You can use our copyright, patent and design materials in accordance with this IPRights Policy.

You can be confident and can trust in the consistency of the Ubuntu experience.

You can rely on the standard expected of Ubuntu.

Ubuntu is an aggregate work; this policy does not modify or reduce rights granted under licences which apply to specific works in Ubuntu.
"

"
Any redistribution of modified versions of Ubuntu must be approved, certified or provided by Canonical if you are going to associate it with the Trademarks. Otherwise you must remove and replace the Trademarks and will need to recompile the source code to create your own binaries. This does not affect your rights under any open source licence applicable to any of the components of Ubuntu. If you need us to approve, certify or provide modified versions for redistribution you will require a licence agreement from Canonical, for which you may be required to pay. For further information, please contact us (as set out below).
"

"
We do not recommend using modified versions of Ubuntu which are not modified in accordance with this IPRights Policy. Modified versions may be corrupted and users of such modified systems or images may find them to be inconsistent with the updates published by Canonical to its users. If they use the Trademarks, they are in contravention of this IPRights Policy. Canonical cannot guarantee the performance of such modified versions. Canonical’s updates will be consistent with every version of Ubuntu approved, certified or provided by Canonical.
"

"
You can use the Trademarks, in accordance with Canonical’s brand guidelines, with Canonical’s permission in writing. If you require a Trademark licence, please contact us (as set out below).
"

"
You can use the Trademarks in discussion, commentary, criticism or parody, provided that you do not imply endorsement by Canonical.
"

[1] https://ubuntu.com/licensing

[2] https://forum.snapcraft.io/t/commercial-usage-of-snaps-and-dealing-with-licensing/6211

[3] https://ubuntu.com/legal/trademarks

[4] https://ubuntu.com/legal/intellectual-property-policy

Regards,

Robert


Re: Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

Ross Burton
 

The first question is why. It sounds like you want Ubuntu but the
bootloader and kernel built by Yocto. I'm struggling to see what this
would achieve.

On Fri, 12 Feb 2021 at 11:49, <poornesh.g@phytecembedded.in> wrote:

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance




Integrating Ubuntu 20.04 root file system in yocto for i.MX8M #linux #yocto #kernel

poornesh.g@...
 

Greetings !

I am trying to integrate the ubuntu 20.04 Root file system with the yocto build . Ultimately my final image should consists of :

Bootloader and Kernel : From default yocto build system.

Rootfile system : Should be taken the ubuntu 20.04 RFS.

I am adding the ubuntu 20.04 rfs as a recipe in yocto, but I am failing to integrate this ubuntu RFS over the default yocto root file system.

Requesting your solutions and steps .

Thanks in advance


Re: How to get packages version from an image recipe #yocto #linux

Nicolas Jeker
 

Hi Zakaria

On Thu, 2021-02-11 at 03:47 -0800, zakaria.zidouh@smile.fr wrote:
Hello,
 
I want to get the version of the packages generated by a recipe from
the image recipe (or by a python script that runs outside of the
package generating recipe). (like the output of the bitbake -s
command)
 
Do you have any ideas please? 
Probably the image manifest is what you are looking for?

From
https://www.yoctoproject.org/docs/current/mega-manual/mega-manual.html#image-generation-dev-environment
:

The manifest file (.manifest) resides in the same directory as the root
filesystem image. This file lists out, line-by-line, the installed
packages.

The file contents look like this:

...
dropbear armv7at2hf-neon 2019.78-r0
dtc armv7at2hf-neon 1.6.0-r0
e2fsprogs armv7at2hf-neon 1.45.4-r0
...

Thank you


Re: Dunfell, nodejs and typescript - short experience report

Simon Vogl
 

Hi,


Am 12.02.21 um 11:12 schrieb Josef Holzmayr:
Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@...>:
I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
 lib/bb/fetch2/npm.py | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
                 cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
                 return runfetchcmd(cmd, d, workdir=workdir)

+            cfg = open(cfgfile, "a")
             if self.configs:
                 for key, value in self.configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    #_run("npm config set %s %s" % (key, shlex.quote(value)))

             if configs:
                 for key, value in configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+            cfg.close()

             if args:
                 for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.
I know, that's why I'm asking in the first place. But performance here is really really improvable.

      
Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

     # Configure the main package
     with tempfile.TemporaryDirectory() as tmpdir:
+        # install all (native) build dependencies, overrides npm cache:
+        ret = os.system("npm i")
+        # run build step:
+        env.run("npm run build", args=[], workdir=d.getVar("S"))
+
         tarball = npm_pack(env, d.getVar("S"), tmpdir)
         npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Agreed, and I have a patched configure in my own subclass without changing the official codebase -- I just wanted to point where the modification needs to take place.

I actually tried the approach that you propose by playing around with configure_append / compile_prepend tasks, but these build steps are called after the package has already been packed --> the compiled data is not being  installed, I'd have to re-pack things.

Agreed, a typescript-native package would be nice, on the other hand this is where the npm-version-chaos comes in again: Many packages use different tsc versions,...

Simon


Greetz



-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon@...
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |
Office address: Industriezeile 35, 4020 Linz (2nd floor)


Re: Dunfell, nodejs and typescript - short experience report

Josef Holzmayr
 

Howdy!

Thanks for sharing, a few comments inline.

Am Fr., 12. Feb. 2021 um 11:03 Uhr schrieb Simon Vogl <simon@voxel.at>:

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@voxel.at>
---
lib/bb/fetch2/npm.py | 9 +++++++--
1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
return runfetchcmd(cmd, d, workdir=workdir)

+ cfg = open(cfgfile, "a")
if self.configs:
for key, value in self.configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ #_run("npm config set %s %s" % (key, shlex.quote(value)))

if configs:
for key, value in configs:
- _run("npm config set %s %s" % (key, shlex.quote(value)))
+ cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+ # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+ cfg.close()

if args:
for key, value in args:
--
2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...
The main side effect is that you're effectively patching poky, which
is bad for maintenance.

Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging:

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {

# Configure the main package
with tempfile.TemporaryDirectory() as tmpdir:
+ # install all (native) build dependencies, overrides npm cache:
+ ret = os.system("npm i")
+ # run build step:
+ env.run("npm run build", args=[], workdir=d.getVar("S"))
+
tarball = npm_pack(env, d.getVar("S"), tmpdir)
npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?
Again, patching poky is a bad idea. Creating custom bbclasses is much
neater: you could create a base include, and pull that together with
npm.bbclass into two final bbclasses of yours, like npm-js-voxel and
npm-ts-voxel. The former would not have the compilation step. And,
putting the typescript/webpack invocation into configure is also not
exactly how things are meant to work. I know that the dependency
tracking of npm is not easily compatible with bitbake, but the aim
should be to
1) have a recipe that provides typescript-native
2) DEPEND on typescript-native in the recipe which you need to compile
3) add a do_compile stage that does the work.

Greetz


Dunfell, nodejs and typescript - short experience report

Simon Vogl
 

I have some remarks and questions about the npm/nodejs support in dunfell that I wanted to share. We are creating nodejs-based IoT edge solutions and upgrading our build environments to Dunfell one by one. In the course of this, we are switching to the new npm-implementation and found a few small issues.

Firstly, the do_configure() task takes quite some time to complete. After a quick analysis, I saw that most of the time is being spent in creating the npmrc files while packing the dependent packages. I wrote a small workaround to directly create the file instead of calling 'npm config', which results in a 3x-4x speedup:

Signed-off-by: Simon Vogl <simon@...>
---
 lib/bb/fetch2/npm.py | 9 +++++++--
 1 file changed, 7 insertions(+), 2 deletions(-)

diff --git a/lib/bb/fetch2/npm.py b/lib/bb/fetch2/npm.py
index 4789850..2720d87 100644
--- a/lib/bb/fetch2/npm.py
+++ b/lib/bb/fetch2/npm.py
@@ -97,13 +97,18 @@ class NpmEnvironment(object):
                 cmd = "NPM_CONFIG_GLOBALCONFIG=%s " % cfgfile + cmd
                 return runfetchcmd(cmd, d, workdir=workdir)
 
+            cfg = open(cfgfile, "a")
             if self.configs:
                 for key, value in self.configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    #_run("npm config set %s %s" % (key, shlex.quote(value)))
 
             if configs:
                 for key, value in configs:
-                    _run("npm config set %s %s" % (key, shlex.quote(value)))
+                    cfg.write("%s=%s\n" % (key, shlex.quote(value)))
+                    # _run("npm config set %s %s" % (key, shlex.quote(value)))
+
+            cfg.close()
 
             if args:
                 for key, value in args:
-- 2.7.4

Are there any side effects that I did not stumble over yet? And I'd LOVE to have these calls running in a thread-pool for better performance...


Secondly, our projects are based on typescript, so a native compile step is necessary to create a compiled version for packing. We experimented with a separate release branch to check in compiled versions, but this is not easy to handle. I played around with npm.bbclass and found a way to extend configure (!) with a call to our build script before packaging: 

diff --git a/meta/classes/npm.bbclass b/meta/classes/npm.bbclass
index 068032a1e5..31535098cf 100644
--- a/meta/classes/npm.bbclass
+++ b/meta/classes/npm.bbclass
@@ -170,6 +170,11 @@ python npm_do_configure() {
 
     # Configure the main package
     with tempfile.TemporaryDirectory() as tmpdir:
+        # install all (native) build dependencies, overrides npm cache:
+        ret = os.system("npm i")
+        # run build step:
+        env.run("npm run build", args=[], workdir=d.getVar("S"))
+
         tarball = npm_pack(env, d.getVar("S"), tmpdir)
         npm_unpack(tarball, d.getVar("NPM_PACKAGE"), d)

As we have plain JS packages as well, I put the modified configure() in a subclass and this works for us, but it does not look like a clean solution to me. How do you other IoT'ers address this situation?

Simon


-- 
VoXel Interaction Design  |  www.voxel.at
DI Dr.techn. Simon Vogl   |  simon@...
Tomaschekweg 46           |  +43 650 2323 555
A-4040 Linz - Austria     |  
Office address: Industriezeile 35, 4020 Linz (2nd floor)


[error-report-web][PATCH] parser: make contains_tag ignore non-str fields

Yi Fan Yu
 

if `MACHINE` is set to False (in a selftest build),
contains_tags should skip that field instead of
searching for the character '<'.

[YOCTO #14208]

Signed-off-by: Yi Fan Yu <yifan.yu@windriver.com>
---
Post/parser.py | 4 ++++
1 file changed, 4 insertions(+)

diff --git a/Post/parser.py b/Post/parser.py
index ed65d4f..f54482a 100644
--- a/Post/parser.py
+++ b/Post/parser.py
@@ -21,10 +21,14 @@ class Parser:

# returns true if the values contain '<' char
# Ignore the failures field (which is an array anyway)
+ # Ignore any non-str fields too [YOCTO #14208]
def contains_tags (self, data):
for key,val in data.items():
if key == 'failures':
continue
+
+ if not isinstance(val, str):
+ continue

if '<' in val:
return True
--
2.25.1


Yocto Technical Team Minutes, Engineering Sync, for Feb 9 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for June 9 2020
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== disclaimer ==
Best efforts are made to ensure the below is accurate and valid. However,
errors sometimes happen. If any errors or omissions are found, please feel
free to reply to this email with any corrections.

== attendees ==
Trevor Woerner, Stephen Jolly, Ross Burton, Saul Wold, Joshua Watt, Richard
Purdie, Alejandro H, Will, Jan-Simon Möller, John Kaldas, Jon Mason, Bruce
Ashfield, Michael Halstead, Scott Murray, Steve Sakoman, Tim Orling, Trevor
Gamblin, Peter Kjellerstedt, Randy MacLeod

== notes ==
- uninative 2.3.2 with upstream fixes (might be issues with 2.3.3, please
have a look)
- swatbot has found some interesting things

== general ==
Randy: rebasing meta-rust into oe-core. it’s working, sdk needs work and
libsvg needs work
RP: have you seen the patches on the mailing list? (Jan-Simon, PaulB)
Randy: yes, haven’t looked at them yet
RP: do you know how they relate?
Randy: not yet, i’ll reply to the thread. is it needed for the next release?
RP: i’m not going to hold up the release for it, but it’d be nice


RP: there’s been a lot of churn in the versions (glibc, kernel, etc). if
anyone sees anything please raise a flag
Ross: yes, I’ve seen some issues, not always 100% reproducible
RP: x86 host?
Ross: not always
TimO: ubuntu host?
Ross: 20.04
RP: glibc-2.33 does have some interesting things, so i’m not surprised there
are issues
Randy: what are you seeing?
Ross: issues building the kernel (“dangerous relocations”)
RP: for dunfell we did a glibc-2.32 update but we’ll hold off on glibc-2.33
(thanks Michael!)
Ross: turning off uninative makes it go away
TimO: is that a Xen kernel?
Ross: no, just defconfig


TimO: (for Bruce) interested in kubernetes or k3s
Bruce: i upgraded pretty much everything in meta-virt over the weekend, k3s is
broken but everything else is good


TimO: how was FOSDEM?
Bruce: best platform so far, better than ELC/E
TimO: their own, or same as Plumbers?
ScottM: their own, something with matrix and jitsi
Bruce: not a lot of OE stuff, specifically, but mentioned in a bunch
(embedded, license, distros, virtualization)

JPEW: was going to give a talk at ELC, (virtual, labgrid, etc)
TrevorG + TimO: we should talk
TrevorG: we’ve got interesting things working, so we were going to give a
talk (kube-virt tekton stuff)
ScottM: for AGL there’s a project to do drm stuff on the host (wayland) from
within a virt machine (virgl)


Randy: is x11 really dead?
Ross: yes, no upstream maintainer
JPEW: i’ve been looking for a good Weston compositor that would be a good
replacement for Sato. even if it just listed out the .desktop files that
could be clicked
Ross: there are some
JPEW: but they’re not great on a 5” screen. there is the IVI shell, but
any apps have to use the IVI shell extensions
ScottM: AGL just migrated away from it. i’ll have to look it up, but there
is a compositor that uses libweston
Ross: i looked at matchbox to see if the sato bits could be converted to
weston. it should be possible, the hooks are there, but i haven’t gone
any further
TimO: the problems with the compositors that i looked at needed QT
JPEW: sway is a good tiling compositor, but we need something that would be
good for an embedded demo
ScottM: maynard is the one from colabora, it was dead, but i think it’s
going to be picked up again. another one would be to use wlroots or
libweston to piece something together
TimO: libweston would be a good one
ScottM: the AGL one targets libweston, libweston had updates to support this
use-case
TimO: also need to consider testability, worked with dogtail but it was
“hacky”
Ross: gtk4 has a re-written accessibility module


RP: there is a layer that RedHat has been working on called meta-rpm,
they’ve been making noises about automotive stuff. it’s completely
beta software so far, native only, they’re repackaging their binaries to
look like yocto packages
TimO: it looks like something similar to what Siemens is doing (isar)
RP: they’re looking at re-writing pseudo
ScottM: is that public?
J-S: it’s on a gitlab: https://gitlab.com/fedora-iot/meta-rpm
JPEW: the idea is “you can run Fedora and put stuff from your own layers on
top”
J-S: it works for a test build they’re doing, it’s actually CentOS8
ScottM: it would be interesting for commercial folks if it was RHEL
JPEW: the idea is “i have this recipe from OE that i want to run on CentOS”
RP: my fear is RedHat is pretty large
Alejandro: my fear is that all distros might take up this path
RP: from a public perception point of view we need to make sure people realize
this isn’t how Yocto is supposed to be done
Randy: the repo started in Nov 2020, the 90% developer on the project seems
like someone we’re linked to (LinkedIn)
RP: both Ross and I have reached out the project
Alejandro: our DNF is quite old, is that good or bad?
RP: don’t think it matters, they’re using DNF in native mode to run
the post-installs which runs into problems with pseudo (we don’t use
chroot). it has a lot of constraints (like isar)
Randy: we’re on the DNF from Dec 2020, and the latest was just released 12
days ago, so we’re not that far behind
TimO: AlexK did quite a lot of work on updates recently, and DNF was not one
of the easy ones


JPEW: (for Michael) any updates on the reproducibility page?
MH: i haven’t had a look at it yet
JPEW: I was hoping it would be hosted on the YP page, is that what you were
thinking?
MH: i thought we were pulling from your site (the JSON) and we’d pull from
there
JPEW: i was putting it up so you could see the HTML, but i wanted it to be
hosted on the YP page, it doesn’t work on mine due to x-site-scripting
checks in browser, so it needs to all be hosted on the same site. if
x-site-scripting is turned off in browser it works, but we can’t expect
that


TimO: i was trying to share the 3.3 release schedule with an intern but we
don’t have one
SJ: probably my fault
RP: as part of the automation there were questions about what we needed and
what was not being used


TrevorW: ELC has been cancelled, should we do something? especially the
training (devday)
RP: need to bring it up with the people who would normally organize it

1541 - 1560 of 53826