Date   

Re: Recipe Grep'ing

Robert Joslyn
 

On Wed, 2021-05-05 at 17:50 -0700, Khem Raj wrote:


On 5/5/21 5:41 PM, Chuck Wolber wrote:
I was pondering putting some work in to a fairly large patch set
aimed
at making recipes easier to grep through, and wanted to get some
feedback before I put time and effort into it.

"what" and the "why" when grep'ing through recipes to search for
things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
              item2 \
             "

After discussing this with Richard Purdie on IRC, I also understand
that
the latter pattern benefits some forms of build output. In addition,
for
SRC_URI, the "why" is normally fairly obvious from context clues.

So, is there any interest in accepting a patch set of that nature for
Yocto and OE repositories? If so, what variables and situations
should
be considered "off limits" to a change like that?
nice to have a linter, which can do such checks and perhaps we can
enable this in autobuilders so we can keep such cleansups maintained
There is the oe-stylize.py script that attempts to format recipes
according to the style guide:
https://git.openembedded.org/meta-openembedded/tree/contrib/oe-stylize.py

Last time I played with it, I was a bit disappointed with some of the
changes it makes, some of which are different than what devtool does.
When I need to introduce new developers to bitbake, I'd love to be able
to hand them oe-stylize or something similar and just tell them to run
it before committing to make sure everything is formatted consistently.

I've had updating oe-stylize.py on my TODO list for a while, but more
important things always come up.

Robert


[meta-security][PATCH 2/2] tpm2-pkcs11: Update to 1.6.0

Armin Kuster
 

Includes gcc11 fix.
Added p11-kit
Minor cleanup

Signed-off-by: Armin Kuster <akuster808@...>
---
.../recipes-tpm2/tpm2-pkcs11/files/677.patch | 295 ++++++++++++++++++
...2-pkcs11_1.5.0.bb => tpm2-pkcs11_1.6.0.bb} | 27 +-
2 files changed, 314 insertions(+), 8 deletions(-)
create mode 100644 meta-tpm/recipes-tpm2/tpm2-pkcs11/files/677.patch
rename meta-tpm/recipes-tpm2/tpm2-pkcs11/{tpm2-pkcs11_1.5.0.bb => tpm2-pkcs11_1.6.0.bb} (76%)

diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/677.patch b/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/677.patch
new file mode 100644
index 0000000..5c91a5e
--- /dev/null
+++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/files/677.patch
@@ -0,0 +1,295 @@
+From 2b74d3df9b3b6932052ace627b21ff1352aa2932 Mon Sep 17 00:00:00 2001
+From: William Roberts <william.c.roberts@...>
+Date: Wed, 5 May 2021 13:32:05 -0500
+Subject: [PATCH 1/4] test: fix build for gcc11
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes 0 size regions by ignoring them. The test code intentionally does
+bad things.
+
+test/unit/test_twist.c: In function ‘test_twistbin_aappend_twist_null’:
+test/unit/test_twist.c:327:18: error: ‘twistbin_aappend’ accessing 16 bytes in a region of size 0 [-Werror=stringop-overflow=]
+ 327 | actual = twistbin_aappend(expected, (binarybuffer *) 0xDEADBEEF, 0);
+ | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+
+Signed-off-by: William Roberts <william.c.roberts@...>
+
+Upstream-Status: Pending
+Fix out for merge to offical repo
+
+Signed-off-by: Armin Kuster <akuster808@...>
+
+---
+ test/unit/test_twist.c | 12 ++++++++++++
+ 1 file changed, 12 insertions(+)
+
+diff --git a/test/unit/test_twist.c b/test/unit/test_twist.c
+index ec66f69f..58d4530a 100644
+--- a/test/unit/test_twist.c
++++ b/test/unit/test_twist.c
+@@ -244,15 +244,23 @@ void test_twistbin_create(void **state) {
+ void test_twistbin_new_overflow_1(void **state) {
+ (void) state;
+
++#pragma GCC diagnostic push
++#pragma GCC diagnostic ignored "-Wpragmas"
++#pragma GCC diagnostic ignored "-Wstringop-overflow"
+ twist actual = twistbin_new((void *) 0xDEADBEEF, ~0);
+ assert_null(actual);
++#pragma GCC diagnostic pop
+ }
+
+ void test_twistbin_new_overflow_2(void **state) {
+ (void) state;
+
++#pragma GCC diagnostic push
++#pragma GCC diagnostic ignored "-Wpragmas"
++#pragma GCC diagnostic ignored "-Wstringop-overflow"
+ twist actual = twistbin_new((void *) 0xDEADBEEF, ~0 - sizeof(void *));
+ assert_null(actual);
++#pragma GCC diagnostic pop
+ }
+
+ void test_twistbin_new_overflow_3(void **state) {
+@@ -318,8 +326,12 @@ void test_twistbin_aappend_twist_null(void **state) {
+ twist actual = twistbin_aappend(expected, NULL, 42);
+ assert_ptr_equal((void * )actual, (void * )expected);
+
++#pragma GCC diagnostic push
++#pragma GCC diagnostic ignored "-Wpragmas"
++#pragma GCC diagnostic ignored "-Wstringop-overflow"
+ actual = twistbin_aappend(expected, (binarybuffer *) 0xDEADBEEF, 0);
+ assert_ptr_equal((void * )actual, (void * )expected);
++#pragma GCC diagnostic pop
+
+ twist_free(actual);
+ }
+
+From 5bea05613e638375b73e29e5d56a9dabcfd2269d Mon Sep 17 00:00:00 2001
+From: William Roberts <william.c.roberts@...>
+Date: Wed, 5 May 2021 11:52:23 -0500
+Subject: [PATCH 2/4] utils: fix stringop-overread in str_padded_copy
+
+cc1: all warnings being treated as errors
+| make: *** [Makefile:1953: src/lib/slot.lo] Error 1
+| make: *** Waiting for unfinished jobs....
+| In file included from src/lib/mutex.h:10,
+| from src/lib/session_ctx.h:6,
+| from src/lib/digest.h:13,
+| from src/lib/tpm.c:28:
+| In function 'str_padded_copy',
+| inlined from 'tpm_get_token_info' at src/lib/tpm.c:742:5:
+| src/lib/utils.h:42:5: error: 'strnlen' specified bound 32 exceeds source size 5 [-Werror=stringop-overread]
+| 42 | memcpy(dst, src, strnlen((char *)(src), dst_len));
+| | ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
+| src/lib/utils.h: In function 'tpm_get_token_info':
+| src/lib/tpm.c:739:19: note: source object declared here
+| 739 | unsigned char manufacturerID[sizeof(UINT32)+1] = {0}; // 4 bytes + '\0' as temp storage
+| | ^~~~~~~~~~~~~~
+| cc1: all warnings being treated as errors
+| make: *** [Makefile:1953: src/lib/tpm.lo] Error 1
+| WARNING: exit code 1 from a shell command.
+
+Fixes #676
+
+Signed-off-by: William Roberts <william.c.roberts@...>
+---
+ src/lib/general.c | 8 ++++----
+ src/lib/general.h | 2 +-
+ src/lib/slot.c | 4 ++--
+ src/lib/token.c | 4 ++--
+ src/lib/tpm.c | 7 +++----
+ src/lib/utils.h | 6 ++++--
+ 6 files changed, 16 insertions(+), 15 deletions(-)
+
+diff --git a/src/lib/general.c b/src/lib/general.c
+index 9b7327c1..eaddaf82 100644
+--- a/src/lib/general.c
++++ b/src/lib/general.c
+@@ -19,8 +19,8 @@
+ #define VERSION "UNKNOWN"
+ #endif
+
+-#define LIBRARY_DESCRIPTION (CK_UTF8CHAR_PTR)"TPM2.0 Cryptoki"
+-#define LIBRARY_MANUFACTURER (CK_UTF8CHAR_PTR)"tpm2-software.github.io"
++static const CK_UTF8CHAR LIBRARY_DESCRIPTION[] = "TPM2.0 Cryptoki";
++static const CK_UTF8CHAR LIBRARY_MANUFACTURER[] = "tpm2-software.github.io";
+
+ #define CRYPTOKI_VERSION { \
+ .major = CRYPTOKI_VERSION_MAJOR, \
+@@ -78,8 +78,8 @@ CK_RV general_get_info(CK_INFO *info) {
+
+ static CK_INFO *_info = NULL;
+ if (!_info) {
+- str_padded_copy(_info_.manufacturerID, LIBRARY_MANUFACTURER, sizeof(_info_.manufacturerID));
+- str_padded_copy(_info_.libraryDescription, LIBRARY_DESCRIPTION, sizeof(_info_.libraryDescription));
++ str_padded_copy(_info_.manufacturerID, LIBRARY_MANUFACTURER);
++ str_padded_copy(_info_.libraryDescription, LIBRARY_DESCRIPTION);
+
+ parse_lib_version(&_info_.libraryVersion.major,
+ &_info_.libraryVersion.minor);
+diff --git a/src/lib/general.h b/src/lib/general.h
+index 14a18e46..356c142d 100644
+--- a/src/lib/general.h
++++ b/src/lib/general.h
+@@ -10,7 +10,7 @@
+ #define TPM2_TOKEN_LABEL "TPM2 PKCS#11 Token"
+ #define TPM2_TOKEN_MANUFACTURER "Intel"
+ #define TPM2_TOKEN_MODEL "TPM2 PKCS#11"
+-#define TPM2_TOKEN_SERIAL_NUMBER "0000000000000000"
++static const CK_UTF8CHAR TPM2_TOKEN_SERIAL_NUMBER[] = "0000000000000000";
+ #define TPM2_TOKEN_HW_VERSION { 0, 0 }
+ #define TPM2_TOKEN_FW_VERSION { 0, 0 }
+
+diff --git a/src/lib/slot.c b/src/lib/slot.c
+index 548d22b5..6db5bb93 100644
+--- a/src/lib/slot.c
++++ b/src/lib/slot.c
+@@ -119,8 +119,8 @@ CK_RV slot_get_info (CK_SLOT_ID slot_id, CK_SLOT_INFO *info) {
+ return CKR_GENERAL_ERROR;
+ }
+
+- str_padded_copy(info->manufacturerID, token_info.manufacturerID, sizeof(info->manufacturerID));
+- str_padded_copy(info->slotDescription, token_info.label, sizeof(info->slotDescription));
++ str_padded_copy(info->manufacturerID, token_info.manufacturerID);
++ str_padded_copy(info->slotDescription, token_info.label);
+
+ info->hardwareVersion = token_info.hardwareVersion;
+ info->firmwareVersion = token_info.firmwareVersion;
+diff --git a/src/lib/token.c b/src/lib/token.c
+index 6d7ebd27..c7211296 100644
+--- a/src/lib/token.c
++++ b/src/lib/token.c
+@@ -317,8 +317,8 @@ CK_RV token_get_info (token *t, CK_TOKEN_INFO *info) {
+ }
+
+ // Identification
+- str_padded_copy(info->label, t->label, sizeof(info->label));
+- str_padded_copy(info->serialNumber, (unsigned char*) TPM2_TOKEN_SERIAL_NUMBER, sizeof(info->serialNumber));
++ str_padded_copy(info->label, t->label);
++ str_padded_copy(info->serialNumber, TPM2_TOKEN_SERIAL_NUMBER);
+
+
+ // Memory: TODO not sure what memory values should go here, the platform?
+diff --git a/src/lib/tpm.c b/src/lib/tpm.c
+index 1639df48..7f9f052a 100644
+--- a/src/lib/tpm.c
++++ b/src/lib/tpm.c
+@@ -740,15 +740,14 @@ CK_RV tpm_get_token_info (tpm_ctx *ctx, CK_TOKEN_INFO *info) {
+ unsigned char manufacturerID[sizeof(UINT32)+1] = {0}; // 4 bytes + '\0' as temp storage
+ UINT32 manufacturer = ntohl(tpmProperties[TPM2_PT_MANUFACTURER - TPM2_PT_FIXED].value);
+ memcpy(manufacturerID, (unsigned char*) &manufacturer, sizeof(uint32_t));
+- str_padded_copy(info->manufacturerID, manufacturerID, sizeof(info->manufacturerID));
++ str_padded_copy(info->manufacturerID, manufacturerID);
+
+ // Map human readable Manufacturer String, if available,
+ // otherwise 4 byte ID was already padded and will be used.
+ for (unsigned int i=0; i < ARRAY_LEN(TPM2_MANUFACTURER_MAP); i++){
+ if (!strncasecmp((char *)info->manufacturerID, TPM2_MANUFACTURER_MAP[i][0], 4)) {
+ str_padded_copy(info->manufacturerID,
+- (unsigned char *)TPM2_MANUFACTURER_MAP[i][1],
+- sizeof(info->manufacturerID));
++ (unsigned char *)TPM2_MANUFACTURER_MAP[i][1]);
+ }
+ }
+
+@@ -758,7 +757,7 @@ CK_RV tpm_get_token_info (tpm_ctx *ctx, CK_TOKEN_INFO *info) {
+ vendor[1] = ntohl(tpmProperties[TPM2_PT_VENDOR_STRING_2 - TPM2_PT_FIXED].value);
+ vendor[2] = ntohl(tpmProperties[TPM2_PT_VENDOR_STRING_3 - TPM2_PT_FIXED].value);
+ vendor[3] = ntohl(tpmProperties[TPM2_PT_VENDOR_STRING_4 - TPM2_PT_FIXED].value);
+- str_padded_copy(info->model, (unsigned char*) &vendor, sizeof(info->model));
++ str_padded_copy(info->model, (unsigned char*) &vendor);
+
+ return CKR_OK;
+ }
+diff --git a/src/lib/utils.h b/src/lib/utils.h
+index 81c61fae..cf357464 100644
+--- a/src/lib/utils.h
++++ b/src/lib/utils.h
+@@ -39,9 +39,11 @@
+
+ int str_to_ul(const char *val, size_t *res);
+
+-static inline void str_padded_copy(CK_UTF8CHAR_PTR dst, const CK_UTF8CHAR_PTR src, size_t dst_len) {
++#define str_padded_copy(dst, src) _str_padded_copy(dst, sizeof(dst), src, strnlen((const char *)src, sizeof(src)))
++static inline void _str_padded_copy(CK_UTF8CHAR_PTR dst, size_t dst_len, const CK_UTF8CHAR *src, size_t src_len) {
+ memset(dst, ' ', dst_len);
+- memcpy(dst, src, strnlen((char *)(src), dst_len));
++ memcpy(dst, src, src_len);
++ LOGE("BILL(%zu): %.*s\n", dst_len, dst_len, dst);
+ }
+
+ twist utils_hash_pass(const twist pin, const twist salt);
+
+From afeae8a3846e06152fafb180077fbad4381a124d Mon Sep 17 00:00:00 2001
+From: William Roberts <william.c.roberts@...>
+Date: Wed, 5 May 2021 14:09:27 -0500
+Subject: [PATCH 3/4] general: drop unused macros
+
+Signed-off-by: William Roberts <william.c.roberts@...>
+---
+ src/lib/general.h | 10 ----------
+ 1 file changed, 10 deletions(-)
+
+diff --git a/src/lib/general.h b/src/lib/general.h
+index 356c142d..b3089554 100644
+--- a/src/lib/general.h
++++ b/src/lib/general.h
+@@ -7,17 +7,7 @@
+
+ #include "pkcs11.h"
+
+-#define TPM2_TOKEN_LABEL "TPM2 PKCS#11 Token"
+-#define TPM2_TOKEN_MANUFACTURER "Intel"
+-#define TPM2_TOKEN_MODEL "TPM2 PKCS#11"
+ static const CK_UTF8CHAR TPM2_TOKEN_SERIAL_NUMBER[] = "0000000000000000";
+-#define TPM2_TOKEN_HW_VERSION { 0, 0 }
+-#define TPM2_TOKEN_FW_VERSION { 0, 0 }
+-
+-#define TPM2_SLOT_DESCRIPTION "Intel TPM2.0 Cryptoki"
+-#define TPM2_SLOT_MANUFACTURER TPM2_TOKEN_MANUFACTURER
+-#define TPM2_SLOT_HW_VERSION TPM2_TOKEN_HW_VERSION
+-#define TPM2_SLOT_FW_VERSION TPM2_TOKEN_FW_VERSION
+
+ CK_RV general_init(void *init_args);
+ CK_RV general_get_func_list(CK_FUNCTION_LIST **function_list);
+
+From 8b43a99c5ff604d890bdc23fd2fa5f98aa087d83 Mon Sep 17 00:00:00 2001
+From: William Roberts <william.c.roberts@...>
+Date: Wed, 5 May 2021 14:11:04 -0500
+Subject: [PATCH 4/4] token: move TPM2_TOKEN_SERIAL_NUMBER local to use
+
+Signed-off-by: William Roberts <william.c.roberts@...>
+---
+ src/lib/general.h | 2 --
+ src/lib/token.c | 2 ++
+ 2 files changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/lib/general.h b/src/lib/general.h
+index b3089554..9afd61ec 100644
+--- a/src/lib/general.h
++++ b/src/lib/general.h
+@@ -7,8 +7,6 @@
+
+ #include "pkcs11.h"
+
+-static const CK_UTF8CHAR TPM2_TOKEN_SERIAL_NUMBER[] = "0000000000000000";
+-
+ CK_RV general_init(void *init_args);
+ CK_RV general_get_func_list(CK_FUNCTION_LIST **function_list);
+ CK_RV general_get_info(CK_INFO *info);
+diff --git a/src/lib/token.c b/src/lib/token.c
+index c7211296..63a9a71b 100644
+--- a/src/lib/token.c
++++ b/src/lib/token.c
+@@ -20,6 +20,8 @@
+ #include "token.h"
+ #include "utils.h"
+
++static const CK_UTF8CHAR TPM2_TOKEN_SERIAL_NUMBER[] = "0000000000000000";
++
+ void pobject_config_free(pobject_config *c) {
+
+ if (c->is_transient) {
diff --git a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.5.0.bb b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.6.0.bb
similarity index 76%
rename from meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.5.0.bb
rename to meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.6.0.bb
index d53d4fa..63ec18d 100644
--- a/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.5.0.bb
+++ b/meta-tpm/recipes-tpm2/tpm2-pkcs11/tpm2-pkcs11_1.6.0.bb
@@ -4,13 +4,15 @@ SECTION = "security/tpm"
LICENSE = "BSD-2-Clause"
LIC_FILES_CHKSUM = "file://LICENSE;md5=0fc19f620a102768d6dbd1e7166e78ab"

-DEPENDS = "autoconf-archive pkgconfig dstat sqlite3 openssl libtss2-dev tpm2-tools libyaml python3-setuptools-native"
+DEPENDS = "autoconf-archive pkgconfig dstat sqlite3 openssl libtss2-dev tpm2-tools libyaml p11-kit python3-setuptools-native"

-SRC_URI = "git://github.com/tpm2-software/tpm2-pkcs11.git;branch=1.X \
+SRC_URI = "git://github.com/tpm2-software/tpm2-pkcs11.git;branch=master \
file://bootstrap_fixup.patch \
- file://0001-remove-local-binary-checkes.patch"
+ file://0001-remove-local-binary-checkes.patch \
+ file://677.patch \
+ "

-SRCREV = "5d583351028eebd470f50ec35db5dcf00533df31"
+SRCREV = "c2d53cc1af6b9df13c832715442853b21048c273"

S = "${WORKDIR}/git"

@@ -26,6 +28,10 @@ do_compile_append() {
}

do_install_append() {
+ install -d ${D}${libdir}/pkcs11
+ install -d ${D}${datadir}/p11-kit
+ rm -f ${D}${libdir}/pkcs11/libtpm2_pkcs11.so
+
cd ${S}/tools
export PYTHONPATH="${D}${PYTHON_SITEPACKAGES_DIR}"
${PYTHON_PN} setup.py install --root="${D}" --prefix="${prefix}" --install-lib="${PYTHON_SITEPACKAGES_DIR}" --optimize=1 --skip-build
@@ -33,12 +39,17 @@ do_install_append() {
sed -i -e "s:${PYTHON}:${USRBINPATH}/env ${PYTHON_PN}:g" "${D}${bindir}"/tpm2_ptool
}

-RDEPNDS_${PN} = "tpm2-tools"
-
PACKAGES =+ "${PN}-tools"
-RDEPENDS_${PN}-tools += "${PYTHON_PN}-setuptools ${PYTHON_PN}-pyyaml ${PYTHON_PN}-cryptography ${PYTHON_PN}-pyasn1-modules"

FILES_${PN}-tools = "\
${bindir}/tpm2_ptool \
${libdir}/${PYTHON_DIR}/* \
-"
+ "
+
+FILES_${PN} += "\
+ ${libdir}/pkcs11/* \
+ ${datadir}/p11-kit/* \
+ "
+
+RDEPNDS_${PN} = "tpm2-tools"
+RDEPENDS_${PN}-tools += "${PYTHON_PN}-setuptools ${PYTHON_PN}-pyyaml ${PYTHON_PN}-cryptography ${PYTHON_PN}-pyasn1-modules"
--
2.25.1


[meta-security][PATCH 1/2] tripwire: Blacklist pkg, upstream seems abandond

Armin Kuster
 

Last update was 2018. Does not build with gcc11.
There are other actively maintained IDS options.

Signed-off-by: Armin Kuster <akuster808@...>
---
recipes-core/packagegroup/packagegroup-core-security.bb | 2 --
recipes-ids/tripwire/tripwire_2.4.3.7.bb | 2 ++
2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/recipes-core/packagegroup/packagegroup-core-security.bb b/recipes-core/packagegroup/packagegroup-core-security.bb
index a6142a8..6d2dd7c 100644
--- a/recipes-core/packagegroup/packagegroup-core-security.bb
+++ b/recipes-core/packagegroup/packagegroup-core-security.bb
@@ -68,7 +68,6 @@ RDEPENDS_packagegroup-security-hardening = " \

SUMMARY_packagegroup-security-ids = "Security Intrusion Detection systems"
RDEPENDS_packagegroup-security-ids = " \
- tripwire \
samhain-standalone \
${@bb.utils.contains_any("TUNE_FEATURES", "ppc7400 riscv32 riscv64", "", " suricata",d)} \
"
@@ -89,7 +88,6 @@ RDEPENDS_packagegroup-meta-security-ptest-packages = "\
libseccomp-ptest \
python3-scapy-ptest \
suricata-ptest \
- tripwire-ptest \
python3-fail2ban-ptest \
${@bb.utils.contains("DISTRO_FEATURES", "smack", "smack-ptest", "",d)} \
"
diff --git a/recipes-ids/tripwire/tripwire_2.4.3.7.bb b/recipes-ids/tripwire/tripwire_2.4.3.7.bb
index 4f50bff..36e5d00 100644
--- a/recipes-ids/tripwire/tripwire_2.4.3.7.bb
+++ b/recipes-ids/tripwire/tripwire_2.4.3.7.bb
@@ -73,3 +73,5 @@ FILES_${PN}-ptest += "${PTEST_PATH}/tests "

RDEPENDS_${PN} += " perl nano msmtp cronie"
RDEPENDS_${PN}-ptest = " perl lib-perl perl-modules "
+
+PNBLACKLIST[tripwire] ?= "Upsteram project appears to be abondoned, fails to build with gcc11"
--
2.25.1


Re: Improving NPM recipe build speed

Alessandro Tagliapietra
 

Anyone?


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Richard Purdie
 

On Fri, 2021-05-07 at 10:10 +0300, Thomas Hill via lists.yoctoproject.org wrote:
On Thu, 6 May 2021, 13:44 Martin Jansa <Martin.Jansa@...> wrote:
On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin!
On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
 I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?
No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.
Ok. Thanks. I can confirm that the change of the bitbake users UID to 1111
did not solve the issue.
I will open a new thread because I don't see why this fails. I use oe_runmake
in my do_install function and got the impression that oe_runmake should take 
care of this via fakeroot.
When you install files during do_install, you need to be clear about who
you want to own the end result.

If you do something like "touch ${D}/x", the it will be owned by the default
user which in a fakeroot context under pseudo is root.

If however you cp a file to ${D}/x, it would depend what you told cp
to do about ownership. If the original file was owned by user 1001, it
may try and preserve that.

We don't know what your code is doing in do_install but its almost certainly
not setting the file ownership correctly.

Cheers,

Richard


[meta-zephyr][PATCH 1/1] zephyr-qemuboot.bbclass: Fix runqemu dependency on qemu native sysroot

Andrei Gherzan
 

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

The runqemu script depends on having the native sysroot populated for
the qemu recipes. Add the required dependency to the mix.

Signed-off-by: Andrei Gherzan <andrei.gherzan@...>
---
classes/zephyr-qemuboot.bbclass | 19 +++++++++++++++++++
1 file changed, 19 insertions(+)

diff --git a/classes/zephyr-qemuboot.bbclass b/classes/zephyr-qemuboot.bbclass
index 5ac1c86..f508b45 100644
--- a/classes/zephyr-qemuboot.bbclass
+++ b/classes/zephyr-qemuboot.bbclass
@@ -35,3 +35,22 @@ python do_bootconf_write() {
}

addtask do_bootconf_write before do_build after do_deploy
+
+# The runqemu script requires the native sysroot populated for the qemu
+# recipes. Usually, this is pulled in by a do_image dependency (see
+# baremetal-helloworld_git, for example), but in this case, there is no such
+# task, so we hook in the dependency to do_bootconf_write. This also ensures
+# that builds from sstate will also have this requirement satisfied.
+python () {
+ # do_addto_recipe_sysroot doesnt exist for all recipes, but we need it to have
+ # /usr/bin on recipe-sysroot (qemu) populated
+ def extraimage_getdepends(task):
+ deps = ""
+ for dep in (d.getVar('EXTRA_IMAGEDEPENDS') or "").split():
+ # Make sure we only add it for qemu
+ if 'qemu' in dep:
+ deps += " %s:%s" % (dep, task)
+ return deps
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_addto_recipe_sysroot'))
+ d.appendVarFlag('do_bootconf_write', 'depends', extraimage_getdepends('do_populate_sysroot'))
+}
--
2.31.1


Path ./package/usr/lib/libcryptopp.so.8 is owned by uid 1111, gid 1111, which doesn't match any user/group on target. This may be due to host contamination.

Thomas Hill
 

Hi!

I try to create a libcryptopp package for my yocto build with the appended bb-recipe.
That worked without problems on my old build server with Yocto 3.0.

Now I have moved to a new build server and upgrade to Yocto 3.3. Now I have the problem that the do_package function failed.

,---[ bitbake core-image-minimal ]---
| WARNING: libcryptopp-8.2.0+gitAUTOINC+9dcc26c582-r8 do_package: KeyError in ./package/usr/lib/libcryptopp.so.8
| ERROR: libcryptopp-8.2.0+gitAUTOINC+9dcc26c582-r8 do_package: Error executing a python function in exec_python_func() autogenerated:
| [...]
| Exception: Exception: KeyError: 'getpwuid(): uid not found: 1001'
| Path ./package/usr/lib/libcryptopp.so.8 is owned by uid 1001, gid 1001, which doesn't match any user/group on target. This may be due to host contamination.
| [...]
| ERROR: Task (/home/thomas/yocto/meta-X2/recipes-X2/libcryptopp/libcryptopp_8.2.0.bb:do_package) failed with exit code '1'
`------------------

I checked the list and found similar problems but not a real solution for me.

libcryptopp's Makefile uses "cp" for installation. I understand this is bad so I patched the Makefile to use "install" instead. That is the recommended usage I could read in the yocto manual. But this does not help either.

As I understand will the do_install and oe_runmake using the bitbake user's UID for installation in a temp dir. Afterwards the do_package uses fakeroot to create the package with root:root file ownership in the package. Right?
In this case I don't understand where the problem is.

I do not run bitbake as root - why should I? So I don't see a possibility to change the files in the temp dir with "chmod" or "install -o 0".

My current bitbake user has UID 1001. On the old server I think it was 1000. Can this be a problem? I tried a new user with UID 1111 but got the same error. Unfortunatelly I can't test with user 1000. It is occupied.

I am out of ideas. Can someone please poke me in the right direction?

Thanks a lot!
Tom


Re: [qa-build-notification] QA notification for completed autobuilder build (yocto-3.2.4.rc1)

Sangeeta Jain
 

Hi all,

Intel and WR YP QA is planning for QA execution for YP build yocto-3.2.4.rc1. We are planning to execute following tests for this cycle:

OEQA-manual tests for following module:
1. OE-Core
2. BSP-hw

Runtime auto test for following platforms:
1. MinnowTurbot 32-bit
2. Coffee Lake
3. NUC 7
4. NUC 6
5. Edgerouter
6. Beaglebone

ETA for completion is next Wednesday, 12 May

Thanks,
Sangeeta

-----Original Message-----
From: qa-build-notification@... <qa-build-
notification@...> On Behalf Of Pokybuild User
Sent: Friday, 7 May, 2021 12:06 AM
To: yocto@...
Cc: qa-build-notification@...
Subject: [qa-build-notification] QA notification for completed autobuilder build
(yocto-3.2.4.rc1)


A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and is
available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1


Build hash information:

bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8
meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc
meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2
poky: 60c8482769f38a4db6f38d525405c887794511a9



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...







Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Thomas Hill
 

On Thu, 6 May 2021, 13:44 Martin Jansa <Martin.Jansa@...> wrote:
On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin!
On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?
No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.
Ok. Thanks. I can confirm that the change of the bitbake users UID to 1111 did not solve the issue.
I will open a new thread because I don't see why this fails. I use oe_runmake in my do_install function and got the impression that oe_runmake should take care of this via fakeroot.

Tom


QA notification for completed autobuilder build (yocto-3.2.4.rc1)

Pokybuild User <pokybuild@...>
 

A build flagged for QA (yocto-3.2.4.rc1) was completed on the autobuilder and is available at:


https://autobuilder.yocto.io/pub/releases/yocto-3.2.4.rc1


Build hash information:

bitbake: e05d79a6ed92c9ce17b90fd5fb6186898a7b3bf8
meta-arm: 39bc4076b2d9a662111beaa0621ee9c1e37f56ea
meta-gplv2: 6e8e969590a22a729db1ff342de57f2fd5d02d43
meta-intel: c325d3e2eab9952dc175a38f31b78fecdcdd0fcc
meta-kernel: 4b288396eff43fe9b1a233aed1ce9b48329a2eb6
meta-mingw: 352d8b0aa3c7bbd5060a4cc2ebe7c0e964de4879
oecore: d47b7cdc3508343349f3bb3eacb2dc3227dd94d2
poky: 60c8482769f38a4db6f38d525405c887794511a9



This is an automated message from the Yocto Project Autobuilder
Git: git://git.yoctoproject.org/yocto-autobuilder2
Email: richard.purdie@...


Re: #yocto cmake configurations #yocto

Monsees, Steven C (US)
 

 

Thanks… I forgot that… linked.

 

I appreciate the help.

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Wednesday, May 5, 2021 5:06 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

usually one uses llvm-config to get the libs and order is important too especially with static libs. Can you dump all .a files from clang and see if its defined in some other .a which is either missing or present after the faulting .a in linker cmd

 

On Wed, May 5, 2021 at 12:53 PM Monsees, Steven C (US) <steven.monsees@...> wrote:

 

I made some modification in the cmake modules to adjust for the linker issue below, but now I appear to have uncovered an issue with the static libraries which meta-clang generated under the SDK… (see below)…

 

The link command is attached as “tmp.txt”.

 

There are a lot of these being generated, this is but a subset…

Note:

(1) “workspace_3” is a reference to my build area where I built the STD SDK, why would this be here the SDK should be independent of this are, no ?

                (2) the code with the undefined reference does appear to be missing the proper header file reference

 

 

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `CodeGenModule':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:114: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:116: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:118: undefined reference to `clang::ASTContext::toCharUnitsFromBits(long) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::IFuncAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::checkAliases()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:304: undefined reference to `clang::Decl::getDefiningAttr() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::SectionAttr* clang::Decl::getAttr<clang::SectionAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:539: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `bool clang::Decl::hasAttr<clang::CUDAGlobalAttr>() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/AST/DeclBase.h:543: undefined reference to `clang::Decl::getAttrs() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::Release()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:520: undefined reference to `clang::ASTContext::getTypeSizeInChars(clang::QualType) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::emitMultiVersionFunctions()':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2788: undefined reference to `clang::ASTContext::forEachMultiversionedFunctionVersion(clang::FunctionDecl const*, llvm::function_ref<void (clang::FunctionDecl*)>) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:2819: undefined reference to `clang::FunctionDecl::isTargetMultiVersion() const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::CodeGen::CodeGenModule::getFunctionLinkage(clang::GlobalDecl)':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/lib/CodeGen/CodeGenModule.cpp:1188: undefined reference to `clang::ASTContext::GetGVALinkageForFunction(clang::FunctionDecl const*) const'

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libclangCodeGen.a(CodeGenModule.cpp.o): in function `clang::Module::getTopLevelModuleName() const':

/disk0/scratch/smonsees/yocto/workspace_3/builds2/sbcb-default/tmp/work-shared/llvm-project-source-9.0.1-r0/git/clang/include/clang/Basic/Module.h:468: undefined reference to `clang::Module::getTopLevelModule() const'

 

 

From: Monsees, Steven C (US) <steven.monsees@...>
Sent: Wednesday, May 5, 2021 7:25 AM
To: Monsees, Steven C (US) <steven.monsees@...>; Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: RE: [yocto] #yocto cmake configurations

 

 

All the libraries are under the SDK here:

 

-L/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib

 

I need the DRM libraries to be picked up correctly, libclang.so may not be required since I have all the static variations available, (added to while testing linker) I have yet to make it through entire build due to linker issue…

 

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Wednesday, May 5, 2021 6:44 AM
To: Khem Raj <raj.khem@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

Khem:

 

I only have the following libraries present for these:

 

libclang.so  

libclang.so.9

libdrm_intel.so

libdrm_intel.so.1

libdrm_intel.so.1.0.0

libdrm.so

libdrm.so.2

libdrm.so.2.4.0   

 

I do generate the static (*.a) files for both LLVM & Clang and they appear to all be present (No libclang.a was generated).

 

Steve

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 7:46 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

the cmd seems to pass --sysroot correctly so can you search in SDK sysroot if you have libclang.a libdrm_intel.a and libdrm.a ?

 

On Tue, May 4, 2021 at 3:20 PM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

Yes, LLVM & Clang…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 5:17 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

I see its using -rdynamic -static

so next question is that do you have .a files in your sdk ?

 

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

 

Attached…

 

From: Khem Raj <raj.khem@...>
Sent: Tuesday, May 4, 2021 2:36 PM
To: Monsees, Steven C (US) <steven.monsees@...>
Cc: yocto@...
Subject: Re: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

can you post full linker cmd which is failing ?

 

On Tue, May 4, 2021 at 11:24 AM Monsees, Steven C (US) via lists.yoctoproject.org <steven.monsees=baesystems.com@...> wrote:

 

My standard zeus SDK appears to have an issue linking in my applications dynamic libs…

 

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm_intel

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -ldrm

/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/x86_64-pokysdk-linux/usr/libexec/x86_64-poky-linux/gcc/x86_64-poky-linux/9.2.0/real-ld: cannot find -lclang

collect2: error: ld returned 1 exit status

The libraries are under: /disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/

 

My CMake build app does not appear to have an issue finding the files:

 

DRM_INTEL_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm_intel.so

DRM_LIBRARIES:STRING=/disk0/scratch/smonsees/sbcbSTD_SDK/limws/3.0.4/sysroots/corei7-64-poky-linux/usr/lib/libdrm.so

 

It appears to be an issue specifically with the ld…

 

LDFLAGS= " --sysroot=$ENV{OECORE_TARGET_SYSROOT} -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib -L$ENV{OECORE_TARGET_SYSROOT}/usr/lib/x86_64-poky-linux/9.2.0 -lpthread -pthread -O2 -pipe -Wl,-O1 -Wl,-O1 -Wl,--hash-style=gnu -Wl,--as-needed"

 

It does not appear to be making use of –L’s…

 

Is there something I might look at/configure (i.e. add paths to search paths) ?

Is there a simple test to validate tool ?

 

Thanks,

Steve

 

From: yocto@... <yocto@...> On Behalf Of Monsees, Steven C (US) via lists.yoctoproject.org
Sent: Sunday, May 2, 2021 1:28 PM
To: yocto@...
Subject: [yocto] #yocto cmake configurations

 

External Email Alert

This email has been sent from an account outside of the BAE Systems network.

Please treat the email with caution, especially if you are requested to click on a link, decrypt/open an attachment, or enable macros.  For further information on how to spot phishing, access “Cybersecurity OneSpace Page” and report phishing by clicking the button “Report Phishing” on the Outlook toolbar.

 

 

I am using zeus, standard SDK, cmake…

 

Can I pre-configure the SDK to setup cmake package search paths ?, say for find_package, etc. (i.e. detecting external libraries/programs)…

 

The majority of my env is configuring properly, but I am finding cmake is setup for a standard linux env with regards to these types of searches, and

I wanted the cmake built in to look at my SDK paths (first by default) when doing such things as detecting python interpreter, libraries, etc.

 

I am working on third party package unaware of my SDK setup.

 

Thanks,

Steve

 

 

 


Next Yocto Project LTS - April 2022

Richard Purdie
 

I'm pleased to be able to announce that the project is planning to have
the April 2022 release next year be our next LTS release.

This fits in with our original announced plan of 2 year cycles and 
recognises that the LTS has been well received by members and our 
community. It also aligns well with LTS releases of other projects
meaning we have "co-travellers".

The current dunfell LTS would be due to end at that time. There has
been discussion about extending it beyond the currently planned 
timeframe but no agreement/decision has been made on the extra finance 
that would require at this time. There is also some concern about the 
potential pressure on layer maintainers in wider ecosystem which we
plan to investigate further.

By confirming this now, we're hoping to give people a chance to align
strategies and plan for feature development to land into the LTS. There
is a clear need for any new/experimental changes to be planned/developed
now in order to ensure they're ready and stabilised for the LTS.

Cheers,

Richard


[PATCH] config.json: Remove -j option for reproducibility as live output is useful

Richard Purdie
 

The -j option has the side effect that the output is cached. For a long running
single threaded target, the live output is more useful so switch to it.

Signed-off-by: Richard Purdie <richard.purdie@...>
---
config.json | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/config.json b/config.json
index 3e12d3f..6533dab 100644
--- a/config.json
+++ b/config.json
@@ -191,7 +191,7 @@
"SDKMACHINE" : "x86_64",
"step1" : {
"shortname" : "Reproducible Selftest",
- "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible -j 1"],
+ "EXTRACMDS" : ["${SCRIPTSDIR}/checkvnc; OEQA_DEBUGGING_SAVED_OUTPUT=${BASE_SHAREDDIR}/pub/repro-fail/ DISPLAY=:1 oe-selftest -r reproducible"],
"ADDLAYER" : ["${BUILDDIR}/../meta-selftest"]

}
--
2.30.2


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Martin Jansa
 

On Thu, May 6, 2021 at 10:57 AM Thomas Hill via lists.yoctoproject.org <tom.hill=inbox.lv@...> wrote:
Hi Martin!

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
 
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

No, you should chown the files to be owned by the expected user which exists in the image (probably root like in my commit). Changing the UID of the user on host is very bad work around (as it will fail for the next person building the same image with host user 1001.


Re: Hardknott - pseudo excluded from intercept_scripts

Richard Purdie
 

On Wed, 2021-05-05 at 00:56 -0700, Chuck Wolber wrote:
The following code is an effective workaround. It must be added after the core-image is inherited.

python () {
     pseudo_ignore_paths = d.getVar('PSEUDO_IGNORE_PATHS')
     result = ','.join([x for x in pseudo_ignore_paths.split(',') if "intercept_scripts" not in x])
     d.setVar('PSEUDO_IGNORE_PATHS', result)
}

..Ch:W..

On Tue, May 4, 2021 at 8:53 PM Chuck Wolber via lists.yoctoproject.org <
chuckwolber=gmail.com@...> wrote:

I was attempting an image build with Yocto Hardknott, and I ran into a chown problem during do_rootfs(). I
traced it down to ${WORKDIR}/intercept_scripts showing up in the PSEUDO_IGNORE_PATHS environment variable.

This commit made the change:
https://git.openembedded.org/openembedded-core/commit/meta/classes/image.bbclass?id=9463be2292b942a1072eea88881b9644e55aadb9

I continued down the rabbit hole until I got here:
https://git.openembedded.org/openembedded-core/tree/meta/lib/oe/package_manager/__init__.py#n173

Line 192 specifically is the smoking gun. The files are being copied from poky/scripts/postinst-intercepts
into the ${WORKDIR}/intercept_scripts directory and immediately failing when the copyFile utility attempts
to do a chown.

Is there any logical explanation for this? Is this a bug or am I doing something wrong? Is there a
workaround?
This should be fixed in master, the issue was triggered by a checkout 
owned by root/root:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=eff192abe2ee43ebf981bafbb7fca8602ebdcf0c

Steve/Anuj: We'll likely want to backport that one.

Cheers,

Richard


Re: KeyError: 'getpwuid(): uid not found: 1000' in do_package phase

Thomas Hill
 

Hi Martin!

On Mon, Nov 16, 2020 at 02:28 PM, Martin Jansa wrote:
https://github.com/webOS-ports/meta-webos-ports/commit/9fd17a67cdbed92df13a14b002a189b4c6c2d442
 
is an example where it triggers this error, but doesn't trigger the more common host-user-contaminated QA error (unless you happened to use UID 1001 on host for the user running bitbake).
I have here a similar problem with one of my own packages. It happens that my bitbake user uses UID 1001. Do you have more information why this is a problem? Should it be enough to change the UID to 1002 to get everything running?

Thanks!
Tom


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Adding BB_ORIGENV to do_compile[vardepsexclude] solved the issue. Thanks for your help!


Re: SSH_AUTH_SOCK unavailable when pulling modules #golang

Sven
 

Hi Richard,

Unfortunately, that doesn't make the error messages go away. I agree that it's not great that go-mod fetches during do_compile but that's the way it currently is.

For completeness sake, here is the complete minimal example that _does_ compile. However, error messages à la

ERROR: When reparsing [...]/golang-test/golang-test.bb:do_compile, the basehash value changed from be5e3ca0e52fd3e3a0315fb32a2845f097bb6925940a8141b6f4d99fa2423e20 to fc952756231a898ae7d3fd611607066b349042f5313b8363d11eef18ed317ed2. The metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake golang-test -cdo_compile -Snone
ERROR: Then:
ERROR: $ bitbake golang-test -cdo_compile -Sprintdiff

are spewed out. Here's the recipe:

LICENSE = "CLOSED"
GO_IMPORT = "bitbucket.org/sven_schwermer/golang-a"
SRC_URI = "git://git@${GO_IMPORT};protocol=ssh;branch=master"
SRCREV = "f7d820d09a5b2332737a8105b3efd9c1e8e51d32"
inherit go-mod
do_compile() {
export SSH_AUTH_SOCK="${@d.getVar('BB_ORIGENV', False).getVar('SSH_AUTH_SOCK', False)}"
go_do_compile
}

bitbucket.org/sven_schwermer/golang-a pulls in a secondary dependency (bitbucket.org/sven_schwermer/golang-b) which is not publicly available. This is golang-a's go.mod:

module bitbucket.org/sven_schwermer/golang-a
go 1.16
require bitbucket.org/sven_schwermer/golang-b v0.0.0-20210505180831-90ba3cd6391e

I have tested this also on latest poky@master (5a0679cb75) with identical results.


Re: Recipe Grep'ing

Khem Raj
 

On Wed, May 5, 2021 at 7:13 PM Bruce Ashfield <bruce.ashfield@...> wrote:

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.
right, that's what if we want to do this then it has to be persisted
with otherwise it will end up being one time exercise with all these
losses you described.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II



Re: Recipe Grep'ing

Bruce Ashfield
 

On Wed, May 5, 2021 at 8:42 PM Chuck Wolber <chuckwolber@...> wrote:

I was pondering putting some work in to a fairly large patch set aimed at making recipes easier to grep through, and wanted to get some feedback before I put time and effort into it.

I have often found that the following pattern cleanly describes the "what" and the "why" when grep'ing through recipes to search for things:

FOO += "item1"
FOO += "item2"

Whereas this pattern gives us the "what", but not the "why":

FOO = "item1 \
item2 \
"

After discussing this with Richard Purdie on IRC, I also understand that the latter pattern benefits some forms of build output. In addition, for SRC_URI, the "why" is normally fairly obvious from context clues.
The other issue with large formatting patches, is that they make a
history "wall". So when we are debugging and trying to figure why a
change was made, you always have to jump over the wall (or dig under
it) to get the real information.

As such, I'm not a fan of changes like this, unless they are coupled
to some sort of functional change. So I'd be hesitant to take them
into recipes that I end up holding the bag when things break.

Cheers,

Bruce


So, is there any interest in accepting a patch set of that nature for Yocto and OE repositories? If so, what variables and situations should be considered "off limits" to a change like that?

..Ch:W..


--
"Perfection must be reached by degrees; she requires the slow hand of time." - Voltaire



--
- Thou shalt not follow the NULL pointer, for chaos and madness await
thee at its end
- "Use the force Harry" - Gandalf, Star Trek II

4001 - 4020 of 57387