Date   

Gatesgarth-24.0.4 image-live fails

Ferry Toth
 

Accidentally I refreshed poky and rebuilt. The image-live (do_bootimg) fails when building hddimg with the following:

ERROR: edison-image-1.0-r0 do_bootimg: Error executing a python function in exec_python_func() autogenerated: The stack trace of python calls that resulted in this exception/failure was: File: 'exec_python_func() autogenerated', lineno: 2, function: <module>      0001:  *** 0002:do_bootimg(d)      0003: File: '/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/meta/classes/image-live.bbclass', lineno: 258, function: do_bootimg      0254:    if d.getVar("PCBIOS") == "1":      0255:        bb.build.exec_func('build_syslinux_cfg', d)      0256:    if d.getVar("EFI") == "1":      0257:        bb.build.exec_func('build_efi_cfg', d)  *** 0258:    bb.build.exec_func('build_hddimg', d)      0259:    bb.build.exec_func('build_iso', d)      0260:    bb.build.exec_func('create_symlinks', d)      0261:}      0262:do_bootimg[subimages] = "hddimg iso" File: '/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py', lineno: 256, function: exec_func      0252:    with bb.utils.fileslocked(lockfiles):      0253:        if ispython:      0254:            exec_func_python(func, d, runfile, cwd=adir)      0255:        else:  *** 0256:            exec_func_shell(func, d, runfile, cwd=adir)      0257:      0258:    try:      0259:        curcwd = os.getcwd()      0260:    except: File: '/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/build.py', lineno: 503, function: exec_func_shell      0499:    with open(fifopath, 'r+b', buffering=0) as fifo:      0500:        try:      0501:            bb.debug(2, "Executing shell function %s" % func)      0502:            with open(os.devnull, 'r+') as stdin, logfile:  *** 0503:                bb.process.run(cmd, shell=False, stdin=stdin, log=logfile, extrafiles=[(fifo,readfifo)])      0504:        except bb.process.ExecutionError as exe:      0505:            # Find the backtrace that the shell trap generated      0506:            backtrace_marker_regex = re.compile(r"WARNING: Backtrace \(BB generated script\)")      0507:            stdout_lines = (exe.stdout or "").split("\n") File: '/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/poky/bitbake/lib/bb/process.py', lineno: 184, function: run      0180:        if not stderr is None:      0181:            stderr = stderr.decode("utf-8")      0182:      0183:    if pipe.returncode != 0:  *** 0184:        raise ExecutionError(cmd, pipe.returncode, stdout, stderr)      0185:    return stdout, stderr Exception: bb.process.ExecutionError: Execution of '/home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/temp/run.build_hddimg.256530' failed with exit code 1: mkdosfs: unable to create /home/ferry/tmp/edison-intel/my/edison-morty/out/linux64/build/tmp/work/edison-poky-linux/edison-image/1.0-r0/deploy-edison-image-image-complete/edison-image-edison-20210524113748.hddimg mkfs.fat 4.1 (2017-01-24) WARNING: exit code 1 from a shell command.

The reason is that the directory deploy-edison-image-image-complete doesn't exist at the time mkdosfs want to write. However after completing the remainder of image live the directory does exists. Consequently, running bitbake a second time image-live succeeds.

I've tried various thing including expressly creating the directory before mkdosfs, but nothing worked. It seems I don't understand how it is supposed to work in the first place.

However, I managed to trace back the issue to this commit 91e4a1c1 "image-live.bbclass: optional depends when ROOTFS empty".

Reverting this resolves the issue.

Any idea what could be wrong?


ERROR: ParseError at .../bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4: Could not include required file images/basic-dev-image.bb

Zoran
 

Hello again to YOCTO Folks,

Here is another blunder I ran into while fixing a yocto-setup.sh script:
https://github.com/ZoranStojsavljevic/bbb-yocto/blob/master/yocto-setup.sh

While executing $ . ./yocto-setup.sh dunfell, everything ran smoothly.

I did the same routine with the $ . ./yocto-setup.sh gatesgarth, and
approximately after:
Parsing recipes: 9% |##########

The following message pops up!
Loading cache: 100% |
| ETA: --:--:--
Loaded 0 entries from dependency cache.
ERROR: ParseError at
/home/vuser/projects_yocto/bbb-yocto-gatesgarth/meta-bbb/images/console-image.bb:4:
Could not include required file images/basic-dev-image.bb

Summary: There was 1 WARNING message shown.
Summary: There was 1 ERROR message shown, returning a non-zero exit code.

If you peek into the following github repos:
https://github.com/jumpnow/meta-bbb
https://github.com/jumpnow/meta-jumpnow

You'll see that in later images/basic-dev-image.bb does exist, as
well as in the dunfell branch:
https://github.com/jumpnow/meta-jumpnow/blob/zeus/images/basic-dev-image.bb

As well as in gatesgarth branch:
https://github.com/jumpnow/meta-jumpnow/blob/gatesgarth/images/basic-dev-image.bb

What I see upon the logic, something changes in poky/ setup, while
transitioning from dunfell to gatesgarth.

I also have created an issue in bbb-yocto repo:
https://github.com/ZoranStojsavljevic/bbb-yocto/issues/3

I would appreciate any ideas or hints... Maybe some changes required
in local.conf ?

You can all try it yourselves, and see the same!

Thank you,
Zoran
_______


using grpc fails with linker error: file in wrong format

Juergen Landwehr
 

Hi all,

I am developing a C++ library that is using gRPC.

To be able to use protoc for generating the stubs I added the following dependencies:

DEPENDS += "\
grpc-native \
protobuf-native \
...
"

and to link my library with cross-compiled libraries:

RDEPENDS += "\
   grpc \
   protobuf \
   ...
   "

However, linking the library fails with the following error:

ld: /data/jenkins/workspace/e0_mbient_yocto_mbient_manifests_master_downstream/build/tmp/work/cortexa72-mbient-linux/tokenmaster-client/git-r0/recipe-sysroot-native/usr/lib/libgrpc++.so.1.24.3: error adding symbols: file in wrong format

I guess the problem is, that native grpc++ library is used from the "recipe-sysroot-native" directory and thus not the cross-compiled version.

What am I doing wrong? How can I tell Yocto to use the cross-compiled versions?

Thanks,

Jürgen


[meta-security][PATCH] libgssglue: update SRC_URI

Yi Zhao
 

Update SRC_URI to use Debian mirror because the original site is
unaccessible.

Fixes do_fetch error:
ERROR: libgssglue-0.4-r0 do_fetch: Fetcher failure for URL:
'http://www.citi.umich.edu/projects/nfsv4/linux/libgssglue/libgssglue-0.4.tar.gz'.
Unable to fetch URL from any source.

Signed-off-by: Yi Zhao <yi.zhao@windriver.com>
---
recipes-security/libgssglue/libgssglue_0.4.bb | 6 +++---
1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/recipes-security/libgssglue/libgssglue_0.4.bb b/recipes-security/libgssglue/libgssglue_0.4.bb
index f7859a7..88c58ed 100644
--- a/recipes-security/libgssglue/libgssglue_0.4.bb
+++ b/recipes-security/libgssglue/libgssglue_0.4.bb
@@ -21,7 +21,7 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=56871e72a5c475289c0d5e4ba3f2ee3a \
file://src/oid_ops.c;beginline=378;endline=398;md5=e02c165cb8383e950214baca2fbd664b \
"

-SRC_URI = "http://www.citi.umich.edu/projects/nfsv4/linux/${BPN}/${BP}.tar.gz \
+SRC_URI = "${DEBIAN_MIRROR}/main/libg/${BPN}/${BPN}_${PV}.orig.tar.bz2 \
file://libgssglue-canon-name.patch \
file://libgssglue-gss-inq-cred.patch \
file://libgssglue-mglueP.patch \
@@ -29,8 +29,8 @@ SRC_URI = "http://www.citi.umich.edu/projects/nfsv4/linux/${BPN}/${BP}.tar.gz \
file://libgssglue-fix-CVE-2011-2709.patch \
"

-SRC_URI[md5sum] = "088797f3180702fa54e786496b32e750"
-SRC_URI[sha256sum] = "3f791a75502ba723e5e85e41e5e0c711bb89e2716b7c0ec6e74bd1df6739043a"
+SRC_URI[md5sum] = "5ce81940965fa68c7635c42dcafcddfe"
+SRC_URI[sha256sum] = "bb47b2de78409f461811d0db8595c66e6631a9879c3621a35e4434b104ee52f5"

# gssglue can use krb5, spkm3... as gssapi library, configurable
RRECOMMENDS_${PN} += "krb5"
--
2.25.1


Re: [meta-dpdk][PATCH] dpdk: fix build with GCC 11

Naveen Saini
 

Please send this patch to meta-intel mailing list.

-----Original Message-----
From: yocto@lists.yoctoproject.org <yocto@lists.yoctoproject.org> On
Behalf Of Yu, Mingli
Sent: Thursday, May 20, 2021 3:38 PM
To: yocto@yoctoproject.org
Subject: [yocto] [meta-dpdk][PATCH] dpdk: fix build with GCC 11

From: Mingli Yu <mingli.yu@windriver.com>

Fixes:
| In function 'memset',
| inlined from 'test_table_stub' at test_table_tables.c:151:4:
| /buildarea/tmp/work/intel_x86_64-wrs-linux/dpdk/19.11.5-r0/recipe-
sysroot/usr/include/bits/string_fortified.h:59:10: error: '__builtin_memset'
offset [0, 31] is out of the bounds [0, 0] [-Werror=array-bounds]

Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
---
...001-test-table-fix-build-with-GCC-11.patch | 56 +++++++++++++++++++
recipes-extended/dpdk/dpdk_19.11.5.bb | 3 +-
2 files changed, 58 insertions(+), 1 deletion(-) create mode 100644 recipes-
extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-11.patch

diff --git a/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-
11.patch b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-
GCC-11.patch
new file mode 100644
index 0000000..4f76290
--- /dev/null
+++ b/recipes-extended/dpdk/dpdk/0001-test-table-fix-build-with-GCC-
11.p
+++ atch
@@ -0,0 +1,56 @@
+From 33c12ac5ba5f09727c6de807e71403dd260a7bbc Mon Sep 17 00:00:00
2001
+From: Ferruh Yigit <ferruh.yigit@intel.com>
+Date: Mon, 17 May 2021 16:57:39 +0100
+Subject: [PATCH] test/table: fix build with GCC 11
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Build error:
+../app/test/test_table_tables.c: In function ‘test_table_stub’:
+../app/test/test_table_tables.c:31:9:
+ warning: ‘memset’ offset [0, 31] is out of the bounds [0, 0]
+ [-Warray-bounds]
+ memset((uint8_t *)mbuf + sizeof(struct rte_mbuf) + 32, 0, 32); \
+
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
~~~
+../app/test/test_table_tables.c:151:25:
+ note: in expansion of macro ‘PREPARE_PACKET’
+ 151 | PREPARE_PACKET(mbufs[i], 0xadadadad);
+ | ^~~~~~~~~~~~~~
+
+'key' points to mbuf header + 32 bytes, and memset clears next 32 bytes
+of 'key', so overall there needs to be 64 bytes after mbuf header.
+Adding a mbuf size check before memset.
+
+The original code has an assumption that mbuf data buffer follows mbuf
+header, this patch accepts same assumption.
+
+Bugzilla ID: 677
+Fixes: 5205954791cb ("app/test: packet framework unit tests")
+Cc: stable@dpdk.org
+
+Upstream-Status: Backport
+[https://github.com/DPDK/dpdk/commit/33c12ac5ba5f09727c6de807e7140
3dd26
+0a7bbc]
+
+Signed-off-by: Ferruh Yigit <ferruh.yigit@intel.com>
+Signed-off-by: Mingli Yu <mingli.yu@windriver.com>
+---
+ app/test/test_table_tables.c | 3 ++-
+ 1 file changed, 2 insertions(+), 1 deletion(-)
+
+diff --git a/app/test/test_table_tables.c
+b/app/test/test_table_tables.c index 1aa269f95..4ff6ab16a 100644
+--- a/app/test/test_table_tables.c
++++ b/app/test/test_table_tables.c
+@@ -28,7 +28,8 @@ table_test table_tests[] = {
+ APP_METADATA_OFFSET(0)); \
+ key = RTE_MBUF_METADATA_UINT8_PTR(mbuf,
\
+ APP_METADATA_OFFSET(32)); \
+- memset(key, 0, 32); \
++ if (mbuf->priv_size + mbuf->buf_len >= 64) \
++ memset(key, 0, 32); \
+ k32 = (uint32_t *) key; \
+ k32[0] = (value); \
+ *signature = pipeline_test_hash(key, NULL, 0, 0);
\
+--
+2.17.1
+
diff --git a/recipes-extended/dpdk/dpdk_19.11.5.bb b/recipes-
extended/dpdk/dpdk_19.11.5.bb
index 8410c8a..2ae9b43 100644
--- a/recipes-extended/dpdk/dpdk_19.11.5.bb
+++ b/recipes-extended/dpdk/dpdk_19.11.5.bb
@@ -4,7 +4,8 @@ SRC_URI += " \
file://dpdk-16.04-add-RTE_KERNELDIR_OUT-to-split-kernel-bu.patch \
file://dpdk-16.07-add-sysroot-option-within-app-makefile.patch \
file://0001-Starting-from-Linux-5.9-get_user_pages_remote-API-
do.patch \
- file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch"
+ file://usertools-devbind-fix-binding-for-built-in-kernel-dr.patch \
+ file://0001-test-table-fix-build-with-GCC-11.patch"


STABLE = "-stable"
--
2.29.2


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

Robert P. J. Day
 

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

---

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

----
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@gmail.com>
-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@gmail.com>
----
- 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@redhat.com>
-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@redhat.com>
-
-Upstream-Status: Backport [https://github.com/SSSD/sssd.git]
-Signed-off-by: Hongxu.jia@windriver.com
-Signed-off-by: Qi.Chen@windriver.com
----
- 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@gmail.com>
-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@gmail.com>
-
-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@gmail.com>
+
+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@windriver.com>
----
- 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@gmail.com>
+
+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@gmail.com>
+
+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@intel.com>
---
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@gmail.com> 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@gmail.com> 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@intel.com>
---
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@foundries.io>
---
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@iris-sensing.com> 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-sensing.com

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

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@iris-sensing.com> 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-sensing.com

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

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-sensing.com

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

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@iris-sensing.com> 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-sensing.com

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

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@iris-sensing.com> 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-sensing.com

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

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-sensing.com

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

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

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@linuxfoundation.org>
(cherry picked from commit 19b4e74b3960174238acc79fd112f55706bc7385)
Signed-off-by: Steve Sakoman <steve@sakoman.com>
---
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
_______

1481 - 1500 of 55069