Date   

hostile freenode takeover

Jasper Orschulko
 

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA256

Dear all,

there have been recent reports of a hostile takeover of the freenode
service, as described in
https://gist.github.com/joepie91/df80d8d36cd9d1bde46ba018af497409

The Yocto Project should verify these reports and take the necessary
actions, in order to protect its users.

- --
With best regards

Jasper Orschulko
DevOps Engineer

Tel. +49 30 58 58 14 265
Fax +49 30 58 58 14 999
Jasper.Orschulko@...

• • • • • • • • • • • • • • • • • • • • • • • • • •

iris-GmbH
infrared & intelligent sensors
Ostendstraße 1-14 | 12459 Berlin

https://iris-sensing.com/



-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmClQWsACgkQYgqew07V
MNUqVgf/awf7Sy5zSw1m5hZJTk7qQHQD3mMhLCH6UWnJoi3RtcF+Le8ZGTquEOGs
fQREEASj2ydMn7PI5RdLzVZRW9AoOShJ7SbscsD2FsjAVn1AI77KC8XHed8kp1Bx
6QNsxiOaLGVdGRRteArSmj2CH8An0X/36Aj5eGRcoiWRTES6xuBcttfeQfahvNld
HJWoT5FjDF7pYdsLBxIHrw/rCAZnScyE6+BiRok0tv6dI5FGqoL4vo0PsT/3hX+C
AI/P5ORyl96XDnxFkc/8J08tIJaOuMYjMVc7XosQ3BAVcg2I9bdEIj/ZSideZaGe
DkW7vIolZaxaj5cO6/koVH9V1gVMnA==
=HI7v
-----END PGP SIGNATURE-----


[meta-security][PATCH 3/3] sssd: update to 2.5.0

Armin Kuster
 

Add new depends
Drop obsolete patches

Signed-off-by: Armin Kuster <akuster808@...>
---
...AC_CHECK_FILE-when-building-manpages.patch | 34 --------
...s-Collision-with-external-nss-symbol.patch | 78 -------------------
...defines-which-otherwise-are-availabl.patch | 32 --------
.../sssd/files/fix-ldblibdir.patch | 25 ------
recipes-security/sssd/files/fix_gid.patch | 27 +++++++
recipes-security/sssd/files/no_gen.patch | 19 +++++
.../sssd/{sssd_1.16.5.bb => sssd_2.5.0.bb} | 23 +++---
7 files changed, 56 insertions(+), 182 deletions(-)
delete mode 100644 recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
delete mode 100644 recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
delete mode 100644 recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
delete mode 100644 recipes-security/sssd/files/fix-ldblibdir.patch
create mode 100644 recipes-security/sssd/files/fix_gid.patch
create mode 100644 recipes-security/sssd/files/no_gen.patch
rename recipes-security/sssd/{sssd_1.16.5.bb => sssd_2.5.0.bb} (86%)

diff --git a/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch b/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
deleted file mode 100644
index b64670c..0000000
--- a/recipes-security/sssd/files/0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From d54aa109600bcd02bf72cfe64c01935890a102a1 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Jonatan=20P=C3=A5lsson?= <jonatan.p@...>
-Date: Fri, 21 Aug 2020 14:45:10 +0200
-Subject: [PATCH] build: Don't use AC_CHECK_FILE when building manpages
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-AC_CHECK_FILE does not support cross-compilation, and will only check
-the host rootfs. Replace AC_CHECK_FILE with a 'test -f <FILE>' instead,
-to allow building manpages when cross-compiling.
-
-Upstream-status: Submitted [https://github.com/SSSD/sssd/pull/5289]
-Signed-off-by: Jonatan Pålsson <jonatan.p@...>
----
- src/external/docbook.m4 | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/external/docbook.m4 b/src/external/docbook.m4
-index deb8632fa..acdc89a68 100644
---- a/src/external/docbook.m4
-+++ b/src/external/docbook.m4
-@@ -18,7 +18,7 @@ dnl Checks if the XML catalog given by FILE exists and
- dnl if a particular URI appears in the XML catalog
- AC_DEFUN([CHECK_STYLESHEET],
- [
-- AC_CHECK_FILE($1, [], [AC_MSG_ERROR([could not find XML catalog])])
-+ AS_IF([test -f "$1"], [], [AC_MSG_ERROR([could not find XML catalog])])
-
- AC_MSG_CHECKING([for ifelse([$3],,[$2],[$3]) in XML catalog])
- if AC_RUN_LOG([$XSLTPROC --catalogs --nonet --noout "$2" >&2]); then
---
-2.26.1
-
diff --git a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch b/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
deleted file mode 100644
index c319269..0000000
--- a/recipes-security/sssd/files/0001-nss-Collision-with-external-nss-symbol.patch
+++ /dev/null
@@ -1,78 +0,0 @@
-From 05c315100a70d3372e891e9a0ea981a875b2ec90 Mon Sep 17 00:00:00 2001
-From: =?UTF-8?q?Michal=20=C5=BDidek?= <mzidek@...>
-Date: Thu, 27 Feb 2020 06:50:40 +0100
-Subject: [PATCH] nss: Collision with external nss symbol
-MIME-Version: 1.0
-Content-Type: text/plain; charset=UTF-8
-Content-Transfer-Encoding: 8bit
-
-One of our internal static function names started
-to collide with external nss symbol. Additional
-sss_ suffix was added to avoid the collision.
-
-This is needed to unblock Fedora Rawhide's
-SSSD build.
-
-Reviewed-by: Pavel Březina <pbrezina@...>
-
-Upstream-Status: Backport [https://github.com/SSSD/sssd.git]
-Signed-off-by: Hongxu.jia@...
-Signed-off-by: Qi.Chen@...
----
- src/responder/nss/nss_cmd.c | 18 ++++++++++--------
- 1 file changed, 10 insertions(+), 8 deletions(-)
-
-diff --git a/src/responder/nss/nss_cmd.c b/src/responder/nss/nss_cmd.c
-index 25e663ed5..a4d4cfc0b 100644
---- a/src/responder/nss/nss_cmd.c
-+++ b/src/responder/nss/nss_cmd.c
-@@ -728,11 +728,13 @@ done:
- talloc_free(cmd_ctx);
- }
-
--static void nss_setnetgrent_done(struct tevent_req *subreq);
-+static void sss_nss_setnetgrent_done(struct tevent_req *subreq);
-
--static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
-- enum cache_req_type type,
-- nss_protocol_fill_packet_fn fill_fn)
-+/* This function's name started to collide with external nss symbol,
-+ * so it has additional sss_* prefix unlike other functions here. */
-+static errno_t sss_nss_setnetgrent(struct cli_ctx *cli_ctx,
-+ enum cache_req_type type,
-+ nss_protocol_fill_packet_fn fill_fn)
- {
- struct nss_ctx *nss_ctx;
- struct nss_state_ctx *state_ctx;
-@@ -774,7 +776,7 @@ static errno_t nss_setnetgrent(struct cli_ctx *cli_ctx,
- goto done;
- }
-
-- tevent_req_set_callback(subreq, nss_setnetgrent_done, cmd_ctx);
-+ tevent_req_set_callback(subreq, sss_nss_setnetgrent_done, cmd_ctx);
-
- ret = EOK;
-
-@@ -787,7 +789,7 @@ done:
- return EOK;
- }
-
--static void nss_setnetgrent_done(struct tevent_req *subreq)
-+static void sss_nss_setnetgrent_done(struct tevent_req *subreq)
- {
- struct nss_cmd_ctx *cmd_ctx;
- errno_t ret;
-@@ -1037,8 +1039,8 @@ static errno_t nss_cmd_initgroups_ex(struct cli_ctx *cli_ctx)
-
- static errno_t nss_cmd_setnetgrent(struct cli_ctx *cli_ctx)
- {
-- return nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
-- nss_protocol_fill_setnetgrent);
-+ return sss_nss_setnetgrent(cli_ctx, CACHE_REQ_NETGROUP_BY_NAME,
-+ nss_protocol_fill_setnetgrent);
- }
-
- static errno_t nss_cmd_getnetgrent(struct cli_ctx *cli_ctx)
---
-2.21.0
-
diff --git a/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch b/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
deleted file mode 100644
index 1a22332..0000000
--- a/recipes-security/sssd/files/0002-Provide-missing-defines-which-otherwise-are-availabl.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 37a0999e5a9f54e1c61a02a7fbab6fcd04738b3c Mon Sep 17 00:00:00 2001
-From: Armin Kuster <akuster808@...>
-Date: Thu, 8 Oct 2020 05:54:13 -0700
-Subject: [PATCH] Provide missing defines which otherwise are available on
- glibc system headers
-
-Signed-off-by: Armin Kuster <akuster808@...>
-
-Upsteam-Status: Pending
-
----
- src/util/util.h | 4 ++++
- 1 file changed, 4 insertions(+)
-
-diff --git a/src/util/util.h b/src/util/util.h
-index 8a754dbfd..6e55b4bdc 100644
---- a/src/util/util.h
-+++ b/src/util/util.h
-@@ -76,6 +76,10 @@
- #define MAX(a, b) (((a) > (b)) ? (a) : (b))
- #endif
-
-+#ifndef ALLPERMS
-+# define ALLPERMS (S_ISUID|S_ISGID|S_ISVTX|S_IRWXU|S_IRWXG|S_IRWXO)/* 07777 */
-+#endif
-+
- #define SSSD_MAIN_OPTS SSSD_DEBUG_OPTS
-
- #define SSSD_SERVER_OPTS(uid, gid) \
---
-2.17.1
-
diff --git a/recipes-security/sssd/files/fix-ldblibdir.patch b/recipes-security/sssd/files/fix-ldblibdir.patch
deleted file mode 100644
index e350baf..0000000
--- a/recipes-security/sssd/files/fix-ldblibdir.patch
+++ /dev/null
@@ -1,25 +0,0 @@
-When calculate value of ldblibdir, it checks whether the directory of
-$ldblibdir exists. If not, it assigns ldblibdir with ${libdir}/ldb. It is not
-suitable for cross compile. Fix it that only re-assign ldblibdir when its value
-is empty.
-
-Upstream-Status: Inappropriate [cross compile specific]
-
-Signed-off-by: Kai Kang <kai.kang@...>
----
- src/external/libldb.m4 | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/src/external/libldb.m4 b/src/external/libldb.m4
-index c400add..5e5f06d 100644
---- a/src/external/libldb.m4
-+++ b/src/external/libldb.m4
-@@ -19,7 +19,7 @@ if test x"$with_ldb_lib_dir" != x; then
- ldblibdir=$with_ldb_lib_dir
- else
- ldblibdir="`$PKG_CONFIG --variable=modulesdir ldb`"
-- if ! test -d $ldblibdir; then
-+ if test -z $ldblibdir; then
- ldblibdir="${libdir}/ldb"
- fi
- fi
diff --git a/recipes-security/sssd/files/fix_gid.patch b/recipes-security/sssd/files/fix_gid.patch
new file mode 100644
index 0000000..9b481cc
--- /dev/null
+++ b/recipes-security/sssd/files/fix_gid.patch
@@ -0,0 +1,27 @@
+from ../sssd-2.5.0/src/util/sss_pam_data.c:27:
+| ../sssd-2.5.0/src/util/debug.h:88:44: error: unknown type name 'uid_t'; did you mean 'uint_t'?
+| 88 | int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
+| | ^~~~~
+| | uint_t
+| ../sssd-2.5.0/src/util/debug.h:88:55: error: unknown type name 'gid_t'
+| 88 | int chown_debug_file(const char *filename, uid_t uid, gid_t gid);
+| | ^~~~~
+| make[2]: *** [Makefile:22529: src/util/libsss_iface_la-sss_pam_data.lo] Error 1
+| make[2]: *** Waiting for unfinished jobs....
+
+Upstream-Status: Pending
+Signed-off-by: Armin Kuster <akuster808@...>
+
+Index: sssd-2.5.0/src/util/debug.h
+===================================================================
+--- sssd-2.5.0.orig/src/util/debug.h
++++ sssd-2.5.0/src/util/debug.h
+@@ -24,6 +24,8 @@
+ #include "config.h"
+
+ #include <stdio.h>
++#include <unistd.h>
++#include <sys/types.h>
+ #include <stdbool.h>
+
+ #include "util/util_errors.h"
diff --git a/recipes-security/sssd/files/no_gen.patch b/recipes-security/sssd/files/no_gen.patch
new file mode 100644
index 0000000..5c83777
--- /dev/null
+++ b/recipes-security/sssd/files/no_gen.patch
@@ -0,0 +1,19 @@
+don't run generate-sbus-code
+
+Upstream-Status: Inappropriate [OE Specific]
+
+Signed-off-by: Armin Kuster <akuster808@...>
+
+Index: sssd-2.5.0/Makefile.am
+===================================================================
+--- sssd-2.5.0.orig/Makefile.am
++++ sssd-2.5.0/Makefile.am
+@@ -1033,8 +1033,6 @@ generate-sbus-code:
+
+ .PHONY: generate-sbus-code
+
+-BUILT_SOURCES += generate-sbus-code
+-
+ EXTRA_DIST += \
+ sbus_generate.sh.in \
+ src/sbus/codegen/dbus.xml \
diff --git a/recipes-security/sssd/sssd_1.16.5.bb b/recipes-security/sssd/sssd_2.5.0.bb
similarity index 86%
rename from recipes-security/sssd/sssd_1.16.5.bb
rename to recipes-security/sssd/sssd_2.5.0.bb
index 9784ec7..a49f7c7 100644
--- a/recipes-security/sssd/sssd_1.16.5.bb
+++ b/recipes-security/sssd/sssd_2.5.0.bb
@@ -5,8 +5,8 @@ SECTION = "base"
LICENSE = "GPLv3+"
LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"

-DEPENDS = "openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive"
-DEPENDS_append = " libldb dbus libtalloc libpcre glib-2.0 popt e2fsprogs libtevent"
+DEPENDS = "acl attr openldap cyrus-sasl libtdb ding-libs libpam c-ares krb5 autoconf-archive"
+DEPENDS_append = " libldb dbus libtalloc libpcre glib-2.0 popt e2fsprogs libtevent bind p11-kit"

DEPENDS_append_libc-musl = " musl-nscd"

@@ -15,16 +15,13 @@ DEPENDS_append_libc-musl = " musl-nscd"
DEPENDS += "${@bb.utils.contains('PACKAGECONFIG', 'nss', '', \
bb.utils.contains('PACKAGECONFIG', 'crypto', '', 'nss', d), d)}"

-SRC_URI = "https://releases.pagure.org/SSSD/${BPN}/${BP}.tar.gz \
+SRC_URI = "https://github.com/SSSD/sssd/releases/download/2.5.0/sssd-2.5.0.tar.gz \
file://sssd.conf \
file://volatiles.99_sssd \
- file://fix-ldblibdir.patch \
- file://0001-build-Don-t-use-AC_CHECK_FILE-when-building-manpages.patch \
- file://0001-nss-Collision-with-external-nss-symbol.patch \
- file://0002-Provide-missing-defines-which-otherwise-are-availabl.patch \
+ file://no_gen.patch \
+ file://fix_gid.patch \
"
-
-SRC_URI[sha256sum] = "2e1a7bf036b583f686d35164f2d79bdf4857b98f51fe8b0d17aa0fa756e4d0c0"
+SRC_URI[sha256sum] = "afa62d7d8d23fca3aba093abe4ec0d14e7d9346c5b28ceb7c2c624bed98caa06"

inherit autotools pkgconfig gettext python3-dir features_check systemd

@@ -34,7 +31,7 @@ SSSD_UID ?= "root"
SSSD_GID ?= "root"

CACHED_CONFIGUREVARS = "ac_cv_member_struct_ldap_conncb_lc_arg=no \
- ac_cv_path_NSUPDATE=${bindir} ac_cv_prog_HAVE_PYTHON3=${PYTHON_DIR} \
+ ac_cv_path_NSUPDATE=${bindir}/nsupdate ac_cv_prog_HAVE_PYTHON3=${PYTHON_DIR} \
"

PACKAGECONFIG ?="nss nscd autofs sudo infopipe"
@@ -42,13 +39,13 @@ PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'selinux', 'selinux',
PACKAGECONFIG += "${@bb.utils.contains('DISTRO_FEATURES', 'systemd', 'systemd', '', d)}"

PACKAGECONFIG[autofs] = "--with-autofs, --with-autofs=no"
-PACKAGECONFIG[crypto] = "--with-crypto=libcrypto, , libcrypto"
+PACKAGECONFIG[crypto] = ", , libcrypto"
PACKAGECONFIG[curl] = "--with-kcm, --without-kcm, curl jansson"
PACKAGECONFIG[infopipe] = "--with-infopipe, --with-infopipe=no, "
PACKAGECONFIG[manpages] = "--with-manpages, --with-manpages=no, libxslt-native docbook-xml-dtd4-native docbook-xsl-stylesheets-native"
PACKAGECONFIG[nl] = "--with-libnl, --with-libnl=no, libnl"
PACKAGECONFIG[nscd] = "--with-nscd=${sbindir}, --with-nscd=no "
-PACKAGECONFIG[nss] = "--with-crypto=nss, ,nss,"
+PACKAGECONFIG[nss] = ", ,nss,"
PACKAGECONFIG[python3] = "--with-python3-bindings, --without-python3-bindings"
PACKAGECONFIG[samba] = "--with-samba, --with-samba=no, samba"
PACKAGECONFIG[selinux] = "--with-selinux, --with-selinux=no --with-semanage=no, libselinux"
@@ -119,7 +116,7 @@ SYSTEMD_SERVICE_${PN} = " \
"
SYSTEMD_AUTO_ENABLE = "disable"

-FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss.so"
+FILES_${PN} += "${libdir} ${datadir} ${base_libdir}/security/pam_sss*.so"
FILES_${PN}-dev = " ${includedir}/* ${libdir}/*la ${libdir}/*/*la"

# The package contains symlinks that trip up insane
--
2.24.3


[meta-security][PATCH 2/3] ossec-hids: musl not compatable

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-ids/ossec/ossec-hids_3.6.0.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-ids/ossec/ossec-hids_3.6.0.bb b/recipes-ids/ossec/ossec-hids_3.6.0.bb
index 242bbdb..778278b 100644
--- a/recipes-ids/ossec/ossec-hids_3.6.0.bb
+++ b/recipes-ids/ossec/ossec-hids_3.6.0.bb
@@ -161,3 +161,5 @@ USERADD_PARAM_${PN} = "--system --home-dir /var/ossec -g ossec --shell /bin/fals
GROUPADD_PARAM_${PN} = "--system ossec"

RDEPENDS_${PN} = "openssl bash"
+
+COMPATIBLE_HOST_libc-musl = "null"
--
2.24.3


[meta-security][PATCH 1/3] packagegroup-core-security: exclude ossec-hids from musl

Armin Kuster
 

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 ++
1 file changed, 2 insertions(+)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index d7349b0..cf9620f 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -74,6 +74,8 @@ RDEPENDS_packagegroup-security-ids = " \
aide \
"

+RDEPENDS_packagegroup-security-ids_remove_libc-musl = "ossec-hids"
+
SUMMARY_packagegroup-security-mac = "Security Mandatory Access Control systems"
RDEPENDS_packagegroup-security-mac = " \
${@bb.utils.contains("DISTRO_FEATURES", "tomoyo", "ccs-tools", "",d)} \
--
2.24.3


[yocto-autobuilder2][dunfell] config.py: enable fedora33 workers for dunfell

Steve Sakoman
 

Signed-off-by: Steve Sakoman <steve@...>
---
config.py | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.py b/config.py
index 520de47..2565bd7 100644
--- a/config.py
+++ b/config.py
@@ -150,7 +150,7 @@ all_workers = workers + workers_bringup + workers_buildperf + workers_arm
workers_prev_releases = {
"hardknott" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora31", "fedora32", "fedora33", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu2004", "perf-"),
"gatesgarth" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "opensuse152", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
- "dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora29", "fedora30", "fedora31", "fedora32", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
+ "dunfell" : ("centos7", "centos8", "debian8", "debian9", "debian10", "fedora29", "fedora30", "fedora31", "fedora32", "fedora33", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "ubuntu2004", "perf-"),
"zeus" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
"warrior" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
"thud" : ("centos7", "debian8", "debian9", "debian10", "fedora28", "fedora29", "fedora30", "opensuse150", "opensuse151", "ubuntu1604", "ubuntu1804", "ubuntu1904", "perf-"),
--
2.25.1


Re: PREEMPT_RT patches

codusnocturnus
 

Yocto has supported a PREEMPT_RT kernel as long as I can remember.

There are recipes for linux-yocto-rt for the kernel itself, and a core-image-rt image recipe right in poky.

It's also pretty straightforward to use a different kernel recipe, such as one from a vendor, and apply the PREEMPT_RT patches in a .bbappend, provided the recipe version lines up with the patches.

Thanks,


Sent with ProtonMail Secure Email.

‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐

On Wednesday, May 19, 2021 3:51 AM, Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Recently I heard somewhere that newer versions of the Linux Kernel will include the PREEMPT_RT patches, and configuration settings would be used to set how the Linux would operate in a specific system.

 

Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this option ?

 

Is there documentation on this feature/option ?

 

Thanks,

Steve

 



Re: PREEMPT_RT patches

Leon Woestenberg
 

Hello Steven,

Yocto does support switching kernels and configurations, so yes Yocto does "support" it.

However, providing a well-tested PREEMPT_RT kernel might be more an architectural meta layer topic.

We have been using the Intel provided PREEMPT_RT kernel for x86 with good success in a system with hard real-time requirements.
In the end we chose full task isolation approach, where one task runs in user-space task isolation, reducing latencies even further than what PREEMPT_RT can provide, as we did not need kernel services in our main processing loop (after setup).

Regards,

Leon.


On Wed, May 19, 2021 at 12:53 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

Recently I heard somewhere that newer versions of the Linux Kernel will include the PREEMPT_RT patches, and configuration settings would be used to set how the Linux would operate in a specific system.

 

Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this option ?

 

Is there documentation on this feature/option ?

 

Thanks,

Steve

 





[meta-zephyr][PATCH v2 2/2] nrf52840dk-nrf52840.conf: Add nRF52840 DK support

Wojciech Zmuda
 

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..c5be5db
--- /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


[meta-zephyr][PATCH v2 1/2] nrf52832.inc: Rename to nrf52.inc

Wojciech Zmuda
 

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


[meta-zephyr][PATCH v2 0/2] Add nRF52840 DK support

Wojciech Zmuda
 

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

v1 -> v2:
- MACHINE configurations are named using '-' instead of '_'.
Reame the new configuration accordingly.

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


Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

Wojciech Zmuda
 

Hello everybody, thanks for your comments.

Let's abandon this patch then. Judging by meta-zephyr commit history we guessed that bumping up the rev to -rc is compliant with your policy. In that case we, as meta-zephyr users, will just wait for the upstream to reach stable 2.6.0.

Regards,
Wojciech


On Wed, 19 May 2021 at 08:08, Saini, Naveen Kumar <naveen.kumar.saini@...> wrote:


> -----Original Message-----
> From: yocto@... <yocto@...> On
> Behalf Of Jon Mason
> Sent: Wednesday, May 19, 2021 12:00 AM
> To: Zbigniew Bodek <zbigniew.bodek@...>
> Cc: Wojciech Zmuda <zmuda.w@...>; yocto@...
> 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 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.

[Naveen]  We can wait for stable release. If it is urgent, we can carry patches for bug fixes,  in case upstream does not give dot release !

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


PREEMPT_RT patches

Monsees, Steven C (US)
 

 

Recently I heard somewhere that newer versions of the Linux Kernel will include the PREEMPT_RT patches, and configuration settings would be used to set how the Linux would operate in a specific system.

 

Does Yocto support “PREEMPT_RT”, and what versions of Yocto have this option ?

 

Is there documentation on this feature/option ?

 

Thanks,

Steve

 


Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

Naveen Saini
 

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Jon Mason
Sent: Wednesday, May 19, 2021 12:00 AM
To: Zbigniew Bodek <zbigniew.bodek@...>
Cc: Wojciech Zmuda <zmuda.w@...>; yocto@...
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 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.
[Naveen] We can wait for stable release. If it is urgent, we can carry patches for bug fixes, in case upstream does not give dot release !

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




Re: [meta-zephyr][PATCH 2/2] nrf52840dk_nrf52840.conf: Add nRF52840 DK support

Naveen Saini
 

So far, MACHINE configurations are named using '-' instead of '_' . Could you use change it ?

Regards,
Naveen

-----Original Message-----
From: yocto@... <yocto@...> On
Behalf Of Wojciech Zmuda
Sent: Tuesday, May 18, 2021 7:28 PM
To: yocto@...
Cc: Wojciech Zmuda <wojciech.zmuda@...>
Subject: [yocto] [meta-zephyr][PATCH 2/2] nrf52840dk_nrf52840.conf: Add
nRF52840 DK support

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


Yocto Technical Team Minutes, Engineering Sync, for May 18, 2021

Trevor Woerner
 

Yocto Technical Team Minutes, Engineering Sync, for May 18, 2021
archive: https://docs.google.com/document/d/1ly8nyhO14kDNnFcW2QskANXW3ZT7QwKC5wWVDg9dDH4/edit

== announcements ==
The upcoming Yocto Project Summit is taking place May 25-26 2021
details: https://www.yoctoproject.org/yocto-project-virtual-summit-2021/
registration: https://www.cvent.com/d/yjq4dr/4W?ct=868bfddd-ca91-46bb-aaa5-62d2b61b2501

== 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 Jolley, Peter Kjellerstedt, Steve Sakoman, Joshua
Watt, Scott Murray, Michael Halstead, Ross Burton, Randy MacLeod, Tim
Orling, Jon Mason, Jan-Simon Möller, Alexandre Belloni, Bruce Ashfield,
Richard Purdie, Trevor Gamblin, Tony Tascioglu, Alejandro H

== notes ==
- 3.2.4 was released (gatesgarth), this is the last 3.2.x release before
community support
- 3.3.1 is in QA (hardknott)
- round of AUH updates being added now
- Anuj not available, RP acting as maintainer for hardknott
- huge drop in CVEs against master
- multiconfig issues in bitbake
- smp enabled on qemu arm/x86 and switched to newer MACHINE for x86
- OOM issue tracked to glibc
- bitbake heartbeat events causing bitbake to hang, patch pending
- sstate bug tracked down (thanks JaMa), fix merged
- enabled more resource control

== general ==
RP: the bitbake heartbeat issues seems to be cause by additional logging that
was added


RP: mips/ppc/arm glibc usermode testing seems to cause an OOM issues (it was
found to be using 83GB and up)
Ross: that’s a lot of memory for a glibc test
RP: appears to loop infinitely, even if glibc exits, it leaves things behind
that eat up memory. there are some tests that segfault in malloc(), seeing
12GB of memory being used, we might have to get rid of them until we can
figure it out. this seems unloved, if nobody fixes this we'll pull it out
Ross: glibc tests running inside qemu-user?
Ross: what about downgrading qemu
RP: the tests are things we supply (system mode and user mode) x86 is fast
enough (thanks to kvm) that they can run okay, but off architectures
struggle
Ross: hopefully we’ll just find some tests to disable (if they’re not
important enough)
RP: i’ve identified 4 tests specifically (e.g. pthread timed locked loop)
Ross: be interesting to run on real hardware to see if there’s an actual
leak in qemu or an issue with the test
RP: maybe we can add a resource constraint so qemu dies and doesn’t take the
whole system down with it instead
Ross: we can look at it from an arm point of view
RP: this is an oe-selftest, so not run on arm
RP: rpm and deb compression not covered, and we know rpm (for example) is
using all available threads (because it uses liblzma directly instead of
xz) so our constraints aren’t trickling down to tools like this. we need
to look to see if there are other places and examples of this happening


RP: open letter about challenges (maintainers, resources, contributions to
day-to-day running of an open source project). was written because people
have asked me to. let me know if you know of anyone wanting to follow up.
for example, it would be nice to know who is using the project (and list
it publicly). spread the word.

see: https://lists.openembedded.org/g/openembedded-architecture/topic/open_source_maintainers_an/82722442


ScottM: multiconfig issues on hardknott? any details? about to start some
dunfell stuff
RP: i don’t think some things have been backported to dunfell, a fix was
added to master but it didn’t fix the problem. looked at it last week
but got dragged away by other things.
JPEW: we use multiconfig a lot, i’ll take a look at it
RP: instead of a deferred list that is continuously updated, i want it to
calculate things once (the rehash list), so take a look at what’s in
master-next. it shouldn’t be too hard to pull back into dunfell
JPEW: we use dunfell at work, so it shouldn't be too hard to test. i can test
master-next at home
RP: the master-next patch should apply to dunfell quite easily
RP: i’m worried about multiconfig
RP: we’ve improved the sstate cleanups quite a bit, tmp cleanliness is
quite good (hardknott) but people are writing recipes that don’t care
if data is machine-specific, this causes multiconfig to blow up. people
are writing bad recipes and then complaining when their bad recipes blow
things up
JPEW: how to tell if recipe is bad? can we automate something?
RP: no, not easily
JPEW: the problem happens when all multiconfigs share the same tmp directory?
RP: yes. writing a test would be hard, it would have to go into oe not bitbake
JPEW: curious to know how many people are using multiconfig and using
multiconfig with tmp directories
RP: according to irc, many
Ross: i think there are lots of people using multiconfig too soon, multiconfig
is overkill for them, and then they end up abusing the tmp dirctory
JPEW: because multiconfig uses a common tmp directory by default?
Ross: yes
AlejandroH: i submitted doc fix to recommend people use separate tmp dirs when
using multiconfig
JPEW: i will be talking about it next week in my hands-on class at the YP
Summit
RP: to Ross’s point, too many people are now turning to multiconfig to build
completely separate builds for multiple separate machines. this ignores
how the build works, historically
ScottM: sstate stamps are not machine-specific
RP: exactly. i think we have to figure out how to detect it, but not sure
TrevorW: do we want to steer people away from using multiconfig to build
unrelated images for unrelated machines?
RP: i don’t think we can, i think this is what people have been wanting, so
we need to make sure people are doing it right.
JPEW: on the stamp files, would it be possible (expedient) to run bitbake in
a way that all it does is generate the stamp files for all tasks? then
maybe we could run bitbake to generate all these stamps and then look for
overlaps?
RP: that’s what deferred tasks are. where it sees sstate stamp files that
overlap it will do one first, then look at the other overlapping ones.
ideally doing one first will put stuff into sstate that the others can
then use. so it does do these checks. the problem is that when there are
mistakes in the recipes these tasks don’t actually have anything to do
with each other:
1. hashes are identical or not (deferred tasks)
2. checks for stamp overlaps (don’t run 2 tasks with the same hash)
TimO: that explains why i’m not seeing issues because i always build with
separate tmp dirs. we can use shared download dir and shared sstate dirs,
but it’s only with shared tmp dirs?
RP: yes. but you will be seeing deferred tasks, they just won’t interfere
with each other if you’re using separate tmp dirs
AlejandroH: i test dunfell multiconfig but haven’t seen it (because i too
use separate tmp dirs for each build)
JPEW: in theory we should be able to use the same tmp dir, we just have to do
it right
RP: actually, in my testing i have been using separate tmp dirs, but i’m
still seeing issues. so i don’t think separate tmp dirs is completely
related. qemu cross wrapper script was building it twice and the license
was the same but causes a rehash event for one of the builds, this is
what starts the problems. so the cause is: deferred builds, multiconfig,
reusing hashes


TrevorW: cancel next week’s call due to YP Summit?
RP: (gathers consensus) agreed


RP: software bill of materials, SBOM (in the US) we don’t have one
currently, but we could do something similar following the model of the
license SPDX. this could really put our project in the limelight
Randy: i think Saul has looked into this
TrevorW: i’ll add it to the OEDVM list
JPEW: we have a tool internally that does something like this, if Saul is
working on it then i’d like to be looped in
RP: meta-doubleopen seems to be doing something like this:
https://github.com/doubleopen-project/meta-doubleopen
https://lists.yoctoproject.org/g/yocto/topic/vs_vs_yocto_make/82910309
we don’t need multiple solutions, we need something simple and be able to
say we have it, then build on it
JPEW: do you do that at WR?
RP: the tool i linked does SPDX
PeterK: easy as long as it’s open source, the closed code we bring in gets
harder
TrevorW: isn’t this what we get with buildhistory?
RP: yes, apart from the spdx format
JPEW: since we’re building everything, we have all the data
RP: i’m sure there will be lots of corner cases, but we need to say “we do
this”
JPEW: json format in version 2
RP: and we can translate accordingly (xls, rdf, yaml, json, xml)
RP: let’s use the licensing email list to discuss this


Makefile environment variables do not work on some host

Aymeric Dumaz <aymericdumaz@...>
 

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


Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

Jon Mason
 

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




Re: [meta-zephyr][PATCH 2/2] zephyr-kernel-src.inc: set default preferred version to 2.6.0-rc1

Jon Mason
 

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




[meta-zephyr][PATCH] qemuzephyrrunner.py: use existing qemu conf file

Jon Mason
 

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


Yocto Project Status WW20`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M1

Next Deadline: 7th June 2021 YP 3.4 M1 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.2.4 was released
  • YP 3.3.1 is in QA
  • Patch merging to master is continuing and we now have a round of AUH upgrades to process. We’ve tried to merge some of the easier ones as there was autobuilder testing availability. This allows people to concentrate on the areas where there are issues with the automated upgrade and where we most need the help.
  • Anuj is unavailable for a few weeks so Richard will be acting as maintainer for hardknott until he returns (assistance welcome).
  • An open letter about open source project work was sent to various mailing lists highlighting some of the challenges established project face from a resourcing perspective:

https://lists.openembedded.org/g/openembedded-architecture/topic/open_source_maintainers_an/82722442

  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • We saw a significant drop in open CVEs reported by the tooling against master this week (63 down to 18) and hopefully many more of these have resolutions “in flight”. This will allow us to focus on the real issues and filter out the legacy noise.
  • SMP was enabled for qemu on arm/x86 and we switched x86 to a more modern cpu/platform
  • One source of the OOM issues on the autobuilder appears to be glibc usermode testing going out of control and using up all system memory. We are investigating the best way to mitigate that but it accounts for some of our intermittent issues.
  • When OOM issues occur an issue was identified in bitbake’s heartbeat events causing bitbake to hang. Ironically this was being heavily used by the recent autobuilder load debugging code. There is a patch pending to address this.
  • A rare sstate manifest corruption bug was tracked down thanks to information from Martin Jansa, a fix has been merged.
  • We have enabled more resource control on the autobuilder for xz memory/thread usage as that was contributing to the OOM issues. More investigation is needed into the rpm/deb controls for xz, help there would be appreciated.
  • Intermittent autobuilder issues continue to occur and are now at a record high level. You  can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

We are working to identify the load pattern on the infrastructure that seems to trigger these.

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 build date 2021/06/07
  • YP 3.4 M1 Release date 2021/06/18
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.2.4 is in released
  • YP 3.3.1 is in QA
  • YP 3.3.1 release date 2021/05/28
  • YP 3.1.8 build date 2021/05/24
  • YP 3.1.8 release date 2021/06/04
  • YP 3.1.9 build date 2021/06/21
  • YP 3.1.9 release date 2021/07/02
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

The Yocto Project’s technical governance is through its Technical Steering Committee, more information is available at:

https://wiki.yoctoproject.org/wiki/TSC

 

The Status reports are now stored on the wiki at: https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you’d like to see on this weekly status update, let us know!]

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 

4261 - 4280 of 57813