Date   

[meta-security][PATCH] Correct "securiyt" typo in maintainers.inc

Robert P. J. Day
 

Signed-off-by: Robert P. J. Day <rpjday@...>

---

diff --git a/conf/distro/include/maintainers.inc b/conf/distro/include/maintainers.inc
index 7b82ef7..e02b903 100644
--- a/conf/distro/include/maintainers.inc
+++ b/conf/distro/include/maintainers.inc
@@ -1,4 +1,4 @@
-# meta-securiyt Maintainers File
+# meta-security Maintainers File
#
# This file contains a list of recipe maintainers.
#

--

========================================================================
Robert P. J. Day Ottawa, Ontario, CANADA
http://crashcourse.ca

LinkedIn: http://ca.linkedin.com/in/rpjday
========================================================================


[meta-security][v2][PATCH] sssd: update to 2.5.0

Armin Kuster
 

Add new depends
Drop obsolete patches

Signed-off-by: Armin Kuster <akuster808@...>

----
v2]
Fix issue with nsupdate check
don't use host bind
---
...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/drop_ntpdate_chk.patch | 28 +++++++
.../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} | 29 +++----
8 files changed, 89 insertions(+), 183 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
create mode 100644 recipes-security/sssd/files/drop_ntpdate_chk.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} (85%)

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/drop_ntpdate_chk.patch b/recipes-security/sssd/files/drop_ntpdate_chk.patch
new file mode 100644
index 0000000..338af5d
--- /dev/null
+++ b/recipes-security/sssd/files/drop_ntpdate_chk.patch
@@ -0,0 +1,28 @@
+nsupdate path is needed for various exec call
+but don't run natvie tests on it.
+
+
+Upstream-Status: Inappropriate [OE specific]
+Signed-off-by: Armin Kuster <akuster808@...>
+
+Index: sssd-2.5.0/src/external/nsupdate.m4
+===================================================================
+--- sssd-2.5.0.orig/src/external/nsupdate.m4
++++ sssd-2.5.0/src/external/nsupdate.m4
+@@ -3,16 +3,4 @@ AC_MSG_CHECKING(for executable nsupdate)
+ if test -x "$NSUPDATE"; then
+ AC_DEFINE_UNQUOTED([NSUPDATE_PATH], ["$NSUPDATE"], [The path to nsupdate])
+ AC_MSG_RESULT(yes)
+-
+- AC_MSG_CHECKING(for nsupdate 'realm' support')
+- if AC_RUN_LOG([echo realm |$NSUPDATE >&2]); then
+- AC_MSG_RESULT([yes])
+- else
+- AC_MSG_RESULT([no])
+- AC_MSG_ERROR([nsupdate does not support 'realm'])
+- fi
+-
+-else
+- AC_MSG_RESULT([no])
+- AC_MSG_ERROR([nsupdate is not available])
+ fi
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 85%
rename from recipes-security/sssd/sssd_1.16.5.bb
rename to recipes-security/sssd/sssd_2.5.0.bb
index 9784ec7..4c92519 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,14 @@ 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 \
+ file://drop_ntpdate_chk.patch \
"
-
-SRC_URI[sha256sum] = "2e1a7bf036b583f686d35164f2d79bdf4857b98f51fe8b0d17aa0fa756e4d0c0"
+SRC_URI[sha256sum] = "afa62d7d8d23fca3aba093abe4ec0d14e7d9346c5b28ceb7c2c624bed98caa06"

inherit autotools pkgconfig gettext python3-dir features_check systemd

@@ -34,7 +32,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_prog_HAVE_PYTHON3=${PYTHON_DIR} \
"

PACKAGECONFIG ?="nss nscd autofs sudo infopipe"
@@ -42,13 +40,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"
@@ -75,6 +73,9 @@ do_configure_prepend() {
sed -i -e "s#\$sss_extra_libdir##" ${S}/src/external/libresolv.m4
}

+do_compile_prepend () {
+ echo '#define NSUPDATE_PATH "${bindir}"' >> ${B}/config.h
+}
do_install () {
oe_runmake install DESTDIR="${D}"
rmdir --ignore-fail-on-non-empty "${D}/${bindir}"
@@ -119,10 +120,10 @@ 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
INSANE_SKIP_${PN} = "dev-so"

-RDEPENDS_${PN} = "bind dbus libldb libpam"
+RDEPENDS_${PN} = "bind bind-utils dbus libldb libpam"
--
2.24.3


/proc/vmcore not created with CONFIG_PROC_VMCORE=y

Ori Pessach
 

Hello,

I'm trying to enable kdump on an intel x86_64 system, and while kexec boots the crash kernel (I use the same kernel image for the system and crash kernel) makedumpfile fails, apparently because it can't find /proc/vmcore.

My understanding is that vmcore should be found (and empty) in the system kernel, and populated in the crash kernel, but it's not found in either as far as I can tell.

/proc/config.gz shows that CONFIG_PROC_VMCORE Is set to 'y' so I'm not sure what's going on. Any ideas on how to solve this?

Thanks,

Ori Pessach


freescale imx-boot, fails to generate is imx-boot container for signed uboot ( wrong u-boot.bin used by imx-boot compile?)

richard allen
 

In Hardknott, trying to enabled signed uboot containers for signed fitimage

The interaction between the uboot-sign.bbclass and the imx-boot.bb is not working

 

MACHINE=imx8qxq-mek

UBOOT_SIGN_ENABLE= “1”

FIT_SIGN_INDIVIDUAL=”1”

 

(no SPL_SIGN_ENABLE)

 

I see the updated u-boot.bin in the uboot ${B}{config} sub-directory but other copies are still the original u-boot.bin

  • The updated u-boot.bin = u-boot-nodtb.bin + u-boot-pubkey.dtb ,

When imx-boot creates the flash.bin, it is using original u-boot.bin , not the updated one.

 

Have confirmed if I put the updated u-boot.bin where imx-boot will use when creating the flash.bin , then the resulting uboot will only boot signed fitImages .

 

Any known work-arounds ? or this a known bug?

Thanks

Richard Allen

 

 

 

 

 

 

 


[meta-zephyr][hardknott][PATCH] zephyr-kernel-src: switch from master branch to main

Naveen Saini
 

* branch was renamed in upstream repo

It fixes do_fetch failure

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
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 8c987bb..5ee40d4 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -13,7 +13,7 @@ inherit cmake
FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI = "\
- git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=master;name=default \
+ git://github.com/zephyrproject-rtos/zephyr.git;protocol=https;branch=main;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 \
--
2.17.1


Re: Problem with YOCTO Dunfell and host Fedora 33

Zoran
 

Hello Joel,

Thank you for the tips. Really helpful, appreciated very much.

I spent some time this morning investigating this issue, and to find
the culprit.

Here are my findings, which resulted in a cannelloni.bb recipe change
(according to what you wrote).

The fix submitted is in recipe:
https://github.com/ZoranStojsavljevic/meta-socketcan/blob/master/recipes-can/cannelloni/cannelloni.bb

The last cannelloni version which works is:
https://github.com/mguentner/cannelloni/commit/0bd7e27db35bdef361226882ae04205504f7b2f4

The culprit introducing the cmake errors is this one:
https://github.com/mguentner/cannelloni/commit/d01dd1dc745914d129b1f4da2074e282253246af

And, the issue recorded with Maximilian Guentner's cannelloni repo:
https://github.com/mguentner/cannelloni/issues/35

Thank you again,
Zoran
_______

On Thu, May 20, 2021 at 4:48 PM Joel Winarske <joel.winarske@...> wrote:

Hi Zoran,

Your cannelloni recipe is set to autorev, meaning it's not locked to a commit. So when something changes upstream you have to manage it.

Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling. Perhaps try to cross compile (not a host build) Canelloni by itself without Yocto involved. Once that's sorted, then reintroduce yocto.


Joel


On Thu, May 20, 2021, 6:58 AM Zoran <zoran.stojsavljevic@...> wrote:

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______



[meta-zephyr][PATCH] qemu-x86: set new -machine value for QEMU

Naveen Saini
 

-machine type=pc-1.3 is deprecated with QEMU 5.1.0

Error:
machine runqemu - ERROR - Failed
to run qemu: qemu-system-i386: unsupported machine type

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/qemu-x86.conf | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/qemu-x86.conf b/conf/machine/qemu-x86.conf
index ce79b5b..85b3f0d 100644
--- a/conf/machine/qemu-x86.conf
+++ b/conf/machine/qemu-x86.conf
@@ -9,7 +9,7 @@ ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"

# For runqemu
QB_SYSTEM_NAME = "qemu-system-i386"
-QB_MACHINE = "-machine type=pc-1.3"
+QB_MACHINE = "-machine type=pc-q35-2.10"
QB_OPT_APPEND = "-nographic -no-acpi"
QB_CPU_x86 = "-cpu qemu32,+nx,+pae"
QB_CPU_KVM_x86 = "-cpu kvm32"
--
2.17.1


[meta-security][PATCH] tpm2-tss: fix usrmerge udev install path

Ricardo Salveti
 

Update ${base_prefix}/lib to ${nonarch_base_libdir} to fix a package QA
issue when usrmerge is enabled in DISTRO_FEATURES.

QA Issue: tpm2-tss package is not obeying usrmerge distro feature. /lib
should be relocated to /usr. [usrmerge]

Signed-off-by: Ricardo Salveti <ricardo@...>
---
meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
index b2486e5..cc4f191 100644
--- a/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-tss/tpm2-tss_3.0.3.bb
@@ -17,7 +17,7 @@ PACKAGECONFIG ??= ""
PACKAGECONFIG[oxygen] = ",--disable-doxygen-doc, "
PACKAGECONFIG[fapi] = "--enable-fapi,--disable-fapi,json-c "

-EXTRA_OECONF += "--enable-static --with-udevrulesdir=${base_prefix}/lib/udev/rules.d/"
+EXTRA_OECONF += "--enable-static --with-udevrulesdir=${nonarch_base_libdir}/udev/rules.d/"
EXTRA_OECONF_remove = " --disable-static"


@@ -73,6 +73,6 @@ FILES_libtss2-dev = " \
${libdir}/libtss2*so"
FILES_libtss2-staticdev = "${libdir}/libtss*a"

-FILES_${PN} = "${libdir}/udev ${base_prefix}/lib/udev"
+FILES_${PN} = "${libdir}/udev ${nonarch_base_libdir}/udev"

RDEPENDS_libtss2 = "libgcrypt"
--
2.31.1


Re: Statically linked libraries and license manifest

Khem Raj
 

On Thu, May 20, 2021 at 9:18 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

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

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?
I see, this is a workaround that will work in this case but may not
work in case where the PN is not empty
but static linking it happening. So I think in cases of static linking
the parent recipe has to reflect that chage

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




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:
On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

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

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

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




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

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

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----



Re: Statically linked libraries and license manifest

Jasper Orschulko
 

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

OK, maybe I did not make the issue clear enough:

I have a package A which statically links package B at compile time
(using DEPENDS).
As a result the package A is "tainted" with source code from package B.
However, as package B is only in the DEPENDS, not in the RDEPENDS, it
is not included in the license.manifest. As a result, the output image
violates the license terms of package B.

Now my idea comes into play:
Add package B to the RDEPENDS (even though the ${PN} package is empty
after the packages-split), which should result in package B's inclusion
in the license.manifest. Or am I approaching this completely wrong?

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




On Thu, 2021-05-20 at 09:04 -0700, Khem Raj wrote:
On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

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

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is
to
use dynamic linked libraries whenever possible? I have done some
more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to
include
these into the license manifest is to also add them to RDEPENDS and
set
ALLOW_EMPTY_${PN} = "1". This should not change the output image,
but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

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




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries
in
the
license manifest, but so far I am at a loss. To my
understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code
from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as
the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides
on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

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

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----
-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmi5gACgkQYgqew07V
MNURUQf+J7XVwVWvY8fFiOqXyiUFQXzeKpru3v9QNx6RRfXSxUXvs1taKPHEdKOG
vhBvnEIagC6Hzg0+QRBamk8c7KdgQXlS7FGNzMAbybE0Is/ocY1dpiQABSKTP8Za
4/EFNBZ64fzPMfFq3gX3mzko4vf7Ub6R3hmXkZTZnJVUTU9fMCNnxt94mXDvwSB4
bK54TRs2Zpg9s77XxL/nxvaEpkdYC2GBMxIgjahVLVhbxgmn03Sozt2zawbawGRK
NpvagP06+6o0gSgwKBJ3bU2H3i9nQGLOETTGvMjnsbqOANusNZ6QR2WTtJrFirZN
j10vjBt7b+0/GOqU0ONGnVDQYSx74A==
=foGh
-----END PGP SIGNATURE-----


Re: Statically linked libraries and license manifest

Khem Raj
 

On Thu, May 20, 2021 at 9:00 AM Jasper Orschulko
<Jasper.Orschulko@...> wrote:

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

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?
I am not sure why you will include empty packages in your manifest

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




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

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

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----


Re: Statically linked libraries and license manifest

Jasper Orschulko
 

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

Hi Khem,

thanks for your reply. As far as I understand, the "proper" way is to
use dynamic linked libraries whenever possible? I have done some more
thinking on the matter, and at least in our case the packages in
question are empty (the base package that is, everything else is in
${PN}-src ${PN}-devstatic etc), so I believe the easiest way to include
these into the license manifest is to also add them to RDEPENDS and set
ALLOW_EMPTY_${PN} = "1". This should not change the output image, but
include the packages in the build, thus adding them to the license
manifest. What do you think?

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




On Mon, 2021-05-17 at 15:56 -0700, Khem Raj wrote:


On 5/17/21 10:44 AM, Jasper Orschulko wrote:
Hi,

my question more or less reiterates the following:
https://www.yoctoproject.org/pipermail/yocto/2018-July/041854.html

I am trying to find a way to list statically linked libraries in
the
license manifest, but so far I am at a loss. To my understanding
Yocto
does not understand packages included using DEPENDS and not
RDEPENDS as
part of the resulting image, however technically source code from
the
dependee can (and will) end up on the image as part of the
dependent
package. This is a serious issue from a legal point of view, as the
developer ultimately might end up with an incomplete list of
licenses,
when relying on the Yocto license manifest.

Please, do correct me if I'm wrong :)
partly yes. there is a provision to disable static linking using
DISABLE_STATIC, so atleast some of packages can be cleared of.
depends
are effective during build time and its the linking which decides on
that but you can perhaps easily write a probe and extract this
information from linker cmdline perhaps by dumping linker map and
post
processing it.

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

iQEzBAEBCAAdFiEE4WyPMIC5Ap4+Ooo1Ygqew07VMNUFAmCmh3EACgkQYgqew07V
MNWiXAf9GPbvZjlzAW+ref/+RKP/9GbtSBpajVUkn+x4DYdO0DmSq6JwOGeLblW8
qu2wjw9cLwgDAL4YRLESrgA3XAbflFgf0IZBuEMbT6WONW7fgHeQ7+jPrEQ7dkgx
POrePcququDSDi2idjjrdTuqHxLl0Il09g8vJz9oktZhIKwCesqWQE8VjSLcjBaj
u+7nHLY77fV/a1o/Ka7PkH2AjbWsmn/iHC1hLN91yNVG6EyzAneHQYKDo7Y5kRVn
YWNSgmmab7uiigrN2KqFOblazkBaA5/rIKD1PpeOjqOTtF7+UfWkL5DZZArdh/KG
+E3VauRz6agqxbb0VUWZZjE6if07Qg==
=UCmd
-----END PGP SIGNATURE-----


[yocto-autobuilder-helper][dunfell] config.json: Set XZ limits to more reasonable values on autobuilder

Steve Sakoman
 

From: Richard Purdie <richard.purdie@...>

The autobuilders have 128GB memory, we don't want them using 50% which is
the default, 5% should be enough. Also limit the number of threads down
from 48 to something reasonable. This may be partly causing some of our
performance issues?

Signed-off-by: Richard Purdie <richard.purdie@...>
(cherry picked from commit 19b4e74b3960174238acc79fd112f55706bc7385)
Signed-off-by: Steve Sakoman <steve@...>
---
config.json | 2 ++
1 file changed, 2 insertions(+)

diff --git a/config.json b/config.json
index e77a8fe..b62035b 100644
--- a/config.json
+++ b/config.json
@@ -44,6 +44,8 @@
"BB_GENERATE_MIRROR_TARBALLS = '1'",
"BB_NUMBER_THREADS = '16'",
"PARALLEL_MAKE = '-j 16'",
+ "XZ_MEMLIMIT = '5%'",
+ "XZ_THREADS = '8'",
"BB_TASK_NICE_LEVEL = '5'",
"BB_TASK_NICE_LEVEL_task-testimage = '0'",
"BB_TASK_IONICE_LEVEL = '2.7'",
--
2.25.1


Re: Problem with YOCTO Dunfell and host Fedora 33

Joel Winarske
 

Hi Zoran,

Your cannelloni recipe is set to autorev, meaning it's not locked to a commit.  So when something changes upstream you have to manage it.

Chances are Canelloni introduced a CMake change which is overwriting (opposed to appending) one or more variables required for cross compiling.  Perhaps try to cross compile (not a host build) Canelloni by itself without Yocto involved.  Once that's sorted, then reintroduce yocto.


Joel


On Thu, May 20, 2021, 6:58 AM Zoran <zoran.stojsavljevic@...> wrote:
Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______




Problem with YOCTO Dunfell and host Fedora 33

Zoran
 

Hello Yocto developers,

I have few problems running the following self proprietary script from
one of my public git repos:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

I recall that last time I used the script (I used then Fedora 31), the
./yocto setup dunfell worked seamlessly, did setup the environment,
and upon bitbake -k core-image-minimal completed the tasks without any
problem.

Now, I am using Fedora 33 (in the meantime I did two Fedora version upgrades).

The problem is that while compiling the cannelloni package, the
following errors were issued (please, look into the attached file
cmake_problem.txt).

This cmake problem was introduced after switching from Fedora 31 to Fedora 33 ?!

Any clue/idea why this is happening??? What is the cause of the problem?

Thank you,
Zoran
_______


[meta-zephyr][PATCH v2 4/4] acrn.conf: drop acrn machine configuration

Naveen Saini
 

zephyr can be build for 'acrn' with following configuration:

MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/acrn.conf | 9 ---------
1 file changed, 9 deletions(-)
delete mode 100644 conf/machine/acrn.conf

diff --git a/conf/machine/acrn.conf b/conf/machine/acrn.conf
deleted file mode 100644
index c044933..0000000
--- a/conf/machine/acrn.conf
+++ /dev/null
@@ -1,9 +0,0 @@
-#@TYPE: Machine
-#@NAME: acrn
-#@DESCRIPTION: Machine for Zephyr BOARD acrn
-
-require conf/machine/include/qemu.inc
-require conf/machine/include/tune-corei7-common.inc
-ZEPHYR_INHERIT_CLASSES += "zephyr-qemuboot"
-
-ARCH_acrn = "x86"
--
2.17.1


[meta-zephyr][PATCH v2 3/4] intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "minnowboard"

By default it set to MinnowBoard Max 'minnowboard'

Currently 32-bit supported boards:
* up_squared_32
* minnowboard

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-core2-common.inc | 6 ++++++
conf/machine/intel-x86-32.conf | 12 ++++++++++++
2 files changed, 18 insertions(+)
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf

diff --git a/conf/machine/include/tune-core2-common.inc b/conf/machine/include/tune-core2-common.inc
new file mode 100644
index 0000000..012f078
--- /dev/null
+++ b/conf/machine/include/tune-core2-common.inc
@@ -0,0 +1,6 @@
+DEFAULTTUNE ?= "core2-32"
+require conf/machine/include/tune-core2.inc
+require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDES
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-32.conf b/conf/machine/intel-x86-32.conf
new file mode 100644
index 0000000..06f6da5
--- /dev/null
+++ b/conf/machine/intel-x86-32.conf
@@ -0,0 +1,12 @@
+#@TYPE: Machine
+#@NAME: intel-x86-32
+#@DESCRIPTION: common MACHINE for 32-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'minnowboard' board.
+
+require conf/machine/include/tune-core2-common.inc
+
+ARCH_intel-x86-32 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "minnowboard"
+# ZEPHYR_BOARD ?= "up_squared_32"
+ZEPHYR_BOARD ?= "minnowboard"
--
2.17.1


[meta-zephyr][PATCH v2 2/4] intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS

Naveen Saini
 

User need to specify board value to ZEPHYR_BOARD in local.conf
ZEPHYR_BOARD = "ehl_crb"

By default it set to Elkhart Lake CRB 'ehl_crb'

Currently 64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb
* acrn
* acrn_ehl_crb

Ref:
https://docs.zephyrproject.org/latest/boards/x86/index.html

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
conf/machine/include/tune-corei7-common.inc | 3 +++
conf/machine/intel-x86-64.conf | 14 ++++++++++++++
2 files changed, 17 insertions(+)
create mode 100644 conf/machine/intel-x86-64.conf

diff --git a/conf/machine/include/tune-corei7-common.inc b/conf/machine/include/tune-corei7-common.inc
index 7ad9516..509d190 100644
--- a/conf/machine/include/tune-corei7-common.inc
+++ b/conf/machine/include/tune-corei7-common.inc
@@ -1,3 +1,6 @@
DEFAULTTUNE ?= "corei7-64"
require conf/machine/include/tune-corei7.inc
require conf/machine/include/x86-base.inc
+
+# Add x86 to MACHINEOVERRIDE
+MACHINEOVERRIDES =. "x86:"
diff --git a/conf/machine/intel-x86-64.conf b/conf/machine/intel-x86-64.conf
new file mode 100644
index 0000000..2935cff
--- /dev/null
+++ b/conf/machine/intel-x86-64.conf
@@ -0,0 +1,14 @@
+#@TYPE: Machine
+#@NAME: intel-x86-64
+#@DESCRIPTION: common MACHINE for 64-bit x86 boards. User must set ${ZEPHYR_BOARD}. By default is set to 'ech_crb' board.
+
+require conf/machine/include/tune-corei7-common.inc
+
+ARCH_intel-x86-64 = "x86"
+
+# Supported Boards:
+# ZEPHYR_BOARD ?= "acrn"
+# ZEPHYR_BOARD ?= "acrn_ehl_crb"
+# ZEPHYR_BOARD ?= "up_squared"
+# ZEPHYR_BOARD ?= "ehl_crb_sbl"
+ZEPHYR_BOARD ?= "ehl_crb"
--
2.17.1


[meta-zephyr][PATCH v2 1/4] zephyr-kernel-src: fix efi generation failure for x86 boards

Naveen Saini
 

With zephyr v2.5.0, EFI binary support has been added for x86 board (64-bit mode).

To achieve this, an python tool[1] has been added to convert zephyr ELF file
into an EFI appliable. But currently this does not work with Yocto
cross-compilation env.
This patch fix this issue and allow to build zephyr.efi

Ref:
[1]https://github.com/zephyrproject-rtos/zephyr/commit/928d31125f0b4eb28fe1cf3f3ad02b0ae071d7fd

Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
---
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
3 files changed, 87 insertions(+), 4 deletions(-)
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

diff --git a/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
new file mode 100644
index 0000000..fd6fc6b
--- /dev/null
+++ b/recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch
@@ -0,0 +1,80 @@
+From cfde3b1018c3151b6cc1fbe3e9e163d0aaf16954 Mon Sep 17 00:00:00 2001
+From: Naveen Saini <naveen.kumar.saini@...>
+Date: Tue, 11 May 2021 13:46:39 +0800
+Subject: [PATCH] x86: fix efi binary generation issue in cross compilation env
+
+Set root directory for headers.
+
+Upstream-Status: Inappropriate [Cross-compilation specific]
+
+Signed-off-by: Naveen Saini <naveen.kumar.saini@...>
+---
+ arch/x86/zefi/zefi.py | 6 +++++-
+ boards/x86/ehl_crb/CMakeLists.txt | 1 +
+ boards/x86/qemu_x86/CMakeLists.txt | 1 +
+ boards/x86/up_squared/CMakeLists.txt | 1 +
+ 4 files changed, 8 insertions(+), 1 deletion(-)
+
+diff --git a/arch/x86/zefi/zefi.py b/arch/x86/zefi/zefi.py
+index d3514391a8..b9eccbfa10 100755
+--- a/arch/x86/zefi/zefi.py
++++ b/arch/x86/zefi/zefi.py
+@@ -106,7 +106,10 @@ def build_elf(elf_file):
+ # + We need pic to enforce that the linker adds no relocations
+ # + UEFI can take interrupts on our stack, so no red zone
+ # + UEFI API assumes 16-bit wchar_t
+- cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.",
++
++ # Pass --sysroot path for cross compilation
++ sysrootarg = "--sysroot=" + args.sysroot
++ cmd = [args.compiler, "-shared", "-Wall", "-Werror", "-I.", sysrootarg,
+ "-fno-stack-protector", "-fpic", "-mno-red-zone", "-fshort-wchar",
+ "-Wl,-nostdlib", "-T", ldscript, "-o", "zefi.elf", cfile]
+ verbose(" ".join(cmd))
+@@ -145,6 +148,7 @@ def parse_args():
+ parser.add_argument("-o", "--objcopy", required=True, help="objcopy to be used")
+ parser.add_argument("-f", "--elf-file", required=True, help="Input file")
+ parser.add_argument("-v", "--verbose", action="store_true", help="Verbose output")
++ parser.add_argument("-s", "--sysroot", required=True, help="Cross compilation --sysroot=path")
+
+ return parser.parse_args()
+
+diff --git a/boards/x86/ehl_crb/CMakeLists.txt b/boards/x86/ehl_crb/CMakeLists.txt
+index 0d572eff30..6a228107dc 100644
+--- a/boards/x86/ehl_crb/CMakeLists.txt
++++ b/boards/x86/ehl_crb/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/qemu_x86/CMakeLists.txt b/boards/x86/qemu_x86/CMakeLists.txt
+index 1131a5c7ce..489f17192b 100644
+--- a/boards/x86/qemu_x86/CMakeLists.txt
++++ b/boards/x86/qemu_x86/CMakeLists.txt
+@@ -4,6 +4,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+diff --git a/boards/x86/up_squared/CMakeLists.txt b/boards/x86/up_squared/CMakeLists.txt
+index 0eaa9753fc..2e8ce7cfbc 100644
+--- a/boards/x86/up_squared/CMakeLists.txt
++++ b/boards/x86/up_squared/CMakeLists.txt
+@@ -5,6 +5,7 @@ set_property(GLOBAL APPEND PROPERTY extra_post_build_commands
+ -c ${CMAKE_C_COMPILER}
+ -o ${CMAKE_OBJCOPY}
+ -f ${PROJECT_BINARY_DIR}/${CONFIG_KERNEL_BIN_NAME}.elf
++ -s ${SYSROOT_DIR}
+ $<$<BOOL:${CMAKE_VERBOSE_MAKEFILE}>:--verbose>
+ WORKING_DIRECTORY ${PROJECT_BINARY_DIR}
+ )
+--
+2.17.1
+
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
index 6350d86..5d66f0f 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src-2.5.0.inc
@@ -8,3 +8,6 @@ SRCREV_libmetal = "9d4ee2c3cfd5f49861939447990f3b7d7bf9bf94"
SRCREV_tinycrypt = "3e9a49d2672ec01435ffbf0d788db6d95ef28de0"

PV = "2.5.0+git${SRCPV}"
+
+SRC_URI_append = " file://0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch \
+ "
diff --git a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
index 5ee40d4..b3b9565 100644
--- a/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
+++ b/recipes-kernel/zephyr-kernel/zephyr-kernel-src.inc
@@ -1,10 +1,6 @@
LICENSE = "Apache-2.0"
LIC_FILES_CHKSUM = "file://LICENSE;md5=fa818a259cbed7ce8bc2a22d35a464fc"

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

# This file might be included from other places (like other layers) and not
@@ -23,3 +19,7 @@ SRC_URI = "\
file://0001-cmake-add-yocto-toolchain.patch \
"
S = "${WORKDIR}/git"
+
+# Default to a stable version
+PREFERRED_VERSION_zephyr-kernel ??= "2.5.0"
+include zephyr-kernel-src-${PREFERRED_VERSION_zephyr-kernel}.inc
--
2.17.1


[meta-zephyr][PATCH v2 0/4] Fix efi generation and add x86 MACHINE confs (cover letter)

Naveen Saini
 

(1) zephyr-kernel-src: fix efi generation failure for x86 boards

With zephyr v2.5.0, EFI binary generation support has been added for x86 board (64-bit mode).
To achieve this, an python tool[1] has been added to convert zephyr EFL file
into an EFI appliable. But unfortunately at current this does not work with Yocto cross-compilation env.
This patch fix this issue and allow to build zephyr.efi for ehl_crb and up_squared boards.


(2)
Instead of creating machine configuration for each
supported boards, I would like to have common machine configurations for
supported boards. One for 64-bit (intel-x86-64.conf) and one for 32-bit
(intel-x86-32.conf).

User need to specify board value to ZEPHYR_BOARD in local.conf based on
targeted board i.e
ZEPHYR_BOARD = "ehl_crb"

64-bit supported boards:
* up_squared
* ehl_crb_sbl
* ehl_crb (default)
* acrn
* acrn_ehl_crb

32-bit supported boards:
* up_squared_32
* minnowboard (default)

(3) Dropped acrn MACHINE configuration, which can be build with
MACHINE = "intel-x86-64"
ZEPHYR_BOARD = "acrn"

---
v2:
Fixed build for Zephyr 2.4.0
Dropped ACRN configuration

Naveen Saini (4):
zephyr-kernel-src: fix efi generation failure for x86 boards
intel-x86-64.conf: add common MACHINE for x86 (64-bit) BOARDS
intel-x86-32.conf: add common MACHINE for x86 (32-bit) BOARDS
acrn.conf: drop acrn machine configuration

conf/machine/acrn.conf | 9 ---
conf/machine/include/tune-core2-common.inc | 6 ++
conf/machine/include/tune-corei7-common.inc | 3 +
conf/machine/intel-x86-32.conf | 12 +++
conf/machine/intel-x86-64.conf | 14 ++++
...ry-generation-issue-in-cross-compila.patch | 80 +++++++++++++++++++
.../zephyr-kernel/zephyr-kernel-src-2.5.0.inc | 3 +
.../zephyr-kernel/zephyr-kernel-src.inc | 8 +-
8 files changed, 122 insertions(+), 13 deletions(-)
delete mode 100644 conf/machine/acrn.conf
create mode 100644 conf/machine/include/tune-core2-common.inc
create mode 100644 conf/machine/intel-x86-32.conf
create mode 100644 conf/machine/intel-x86-64.conf
create mode 100644 recipes-kernel/zephyr-kernel/files/0001-x86-fix-efi-binary-generation-issue-in-cross-compila.patch

--
2.17.1

4181 - 4200 of 57764