On Wed, 2021-06-30 at 10:41 +0000, Cardaillac, Yann wrote:

Hi Richard,

Many thanks for the fast answer.

I’m switching from buildroot to yocto and trying to figure out how to
do the equivalent of a POST_BUILD_SCRIPT.

Indeed I want to format the images built in a specific format for latter use and CI needs.

In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults are quite simple (tar), some are quite complex (wic has its own bbclass).

I said image, but it was probably not the best word, I just want to make a tarball 
of the generated image + adding some file in it.

Here's the complete file with the job :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://nallino-custom-params.txt"
SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"

do_release_ycn() {

    rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
    mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
    cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
    cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
    cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
    cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
    cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
    tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release

}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules

You're used to poking around things in buildroot, OE doesn't quite like you
doing that so much :)

You shouldn't really be poking around DEPLOY_DIR without letting the build
system know what you're doing. Intermediate files like the intermediate directory
you're using to create the tarball above should really be in WORKDIR.
That is itself won't break, it just not good practise. Ideally you'd write
a separate recipe to do this final piece with a do_deploy task, using the
deploy bbclass which would them take care of removing obsolete versions
when you rebuild and so on.

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success
since it wasn’t running at the proper moment.

When is "the right moment"? :)

The right moment, is at the very end of bitbake, indeed I want the job 
to be the overall last job!

You're not really helping us help you find a solution since you've not described
what you'd expect to be happening that isn't happening. How is what you have
failing?

I'm going to take a leap and guess that some of the files you expect there
aren't? Maybe the dtbo files from some other do_deploy tasks? If that is true
you're missing dependencies for your task. You can do things like:

do_release_ycn[depends] += "virtual/kernel:do_deploy"

I'd caution against "last" as it is a fine concept until two things want to 
be "last". It is usually better to describe the dependencies properly.

Cheers,

Richard

Hi Richard,

Many thanks for the fast answer.

I’m switching from buildroot to yocto and trying to figure out how to
do the equivalent of a POST_BUILD_SCRIPT.

Indeed I want to format the images built in a specific format for latter use and CI needs.

In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults are quite simple (tar), some are quite complex (wic has its own bbclass).

I said image, but it was probably not the best word, I just want to make a tarball of the generated image + adding some file in it.

Here's the complete file with the job :

FILESEXTRAPATHS_prepend := "${THISDIR}/files:"

SRC_URI += "file://nallino-custom-params.txt"
SRC_URI += "file://configuration_instruction_to_do_on_GUF.txt"

do_release_ycn() {

rm -rf ${DEPLOY_DIR_IMAGE}/ycn_release
mkdir -p ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${DEPLOY_DIR_IMAGE}/fng-install.sh ${DEPLOY_DIR_IMAGE}/ycn_release
cp ${DEPLOY_DIR_IMAGE}/ycn-image-imx6ullguf.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release/guf-image-imx6ullguf.tar.gz
cp ${DEPLOY_DIR_IMAGE}/*.dtbo ${DEPLOY_DIR_IMAGE}/ycn_release/overlays
cp ${WORKDIR}/nallino-custom-params.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
cp ${WORKDIR}/configuration_instruction_to_do_on_GUF.txt ${DEPLOY_DIR_IMAGE}/ycn_release/
tar -czf ${DEPLOY_DIR_IMAGE}/ycn_release.tar.gz ${DEPLOY_DIR_IMAGE}/ycn_release

}
addtask release_ycn after do_image_complete after do_deploy_kernelmodules

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success
since it wasn’t running at the proper moment.

When is "the right moment"? :)

The right moment, is at the very end of bitbake, indeed I want the job to be the overall last job!

Thanks again,

Yann

On Wed, 2021-06-30 at 09:33 +0000, Cardaillac, Yann wrote:

I’m switching from buildroot to yocto and trying to figure out how to do the equivalent of a
POST_BUILD_SCRIPT.
 
Indeed I want to format the images built in a specific format for latter use and CI needs.

In OE, the equivalent for that is probably the image types code.
See http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/classes/image_types.bbclass

You can define your own custom image types to extend the system. Some of our defaults
are quite simple (tar), some are quite complex (wic has its own bbclass).

I’ve also tried to use IMAGE_POSTPROCESS_COMMAND without much success since it 
wasn’t running at the proper moment.

When is "the right moment"? :)

Cheers,

Richard

Hi Guys,

             I am building core-image-sato image. i am facing issue rootfs creation. can anybody know give suggition how we can solve this issue.


--
Thanks & Regards,
Sateesh

Include .def files to the -dev package to fix QA Issue: nativesdk-libidn2:
Files/directories were installed but not shipped in any package.

Signed-off-by: Samuli Piippo <samuli.piippo@...>
---
recipes-extended/libidn/libidn2_%.bbappend | 1 +
1 file changed, 1 insertion(+)
create mode 100644 recipes-extended/libidn/libidn2_%.bbappend

diff --git a/recipes-extended/libidn/libidn2_%.bbappend b/recipes-extended/libidn/libidn2_%.bbappend
new file mode 100644
index 0000000..275886d
--- /dev/null
+++ b/recipes-extended/libidn/libidn2_%.bbappend
@@ -0,0 +1 @@
+FILES_${PN}-dev_append_mingw32 = " ${libdir}/*.def"
--
2.25.1

Signed-off-by: Khem Raj <raj.khem@...>
---
...-includes-for-glibc-2.34-portability.patch | 39 +++++++++++++++++++
recipes-core/coreutils/coreutils_6.9.bb | 1 +
2 files changed, 40 insertions(+)
create mode 100644 recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch

diff --git a/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
new file mode 100644
index 0000000..0d9b5e2
--- /dev/null
+++ b/recipes-core/coreutils/coreutils-6.9/0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch
@@ -0,0 +1,39 @@
+From e241a55767c4eaac7d14c412d880037cb6d2ee33 Mon Sep 17 00:00:00 2001
+From: Khem Raj <raj.khem@...>
+Date: Tue, 29 Jun 2021 22:43:16 -0700
+Subject: [PATCH] sort.c: Reorder includes for glibc 2.34 portability
+
+With glibc 2.34 config.h will include stdlib.h and that would disable
+sys/wait.h to include needed definitions from bits/waitflags.h since
+_STDLIB_H would have been defined already and sys/wait.h would think
+these paths are included already, this is fixed with newer gnulib and
+configure so this is to get this old version to compile with latest
+glibc headers
+
+Upstream-Status: Inappropriate [OE-Specific]
+Signed-off-by: Khem Raj <raj.khem@...>
+---
+ src/sort.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/sort.c b/src/sort.c
+index 58ca66a..48b22c8 100644
+--- a/src/sort.c
++++ b/src/sort.c
+@@ -21,11 +21,11 @@
+
+ Ørn E. Hansen added NLS support in 1997. */
+
++#include <sys/types.h>
++#include <sys/wait.h>
+ #include <config.h>
+
+ #include <getopt.h>
+-#include <sys/types.h>
+-#include <sys/wait.h>
+ #include <signal.h>
+ #include "system.h"
+ #include "argmatch.h"
+--
+2.32.0
+
diff --git a/recipes-core/coreutils/coreutils_6.9.bb b/recipes-core/coreutils/coreutils_6.9.bb
index 42b4f3c..69e5489 100644
--- a/recipes-core/coreutils/coreutils_6.9.bb
+++ b/recipes-core/coreutils/coreutils_6.9.bb
@@ -27,6 +27,7 @@ SRC_URI = "${GNU_MIRROR}/coreutils/${BP}.tar.bz2 \
file://no-man.patch \
file://build-don-t-need-charset.alias-when-building-for-mus.patch \
file://no-su.patch \
+ file://0001-sort.c-Reorder-includes-for-glibc-2.34-portability.patch \
"

SRC_URI[md5sum] = "c9607d8495f16e98906e7ed2d9751a06"
--
2.32.0

Hello to everyone,

Mguentner fixed the cmake issue:
https://github.com/mguentner/cannelloni/issues/35

With this patch:
https://github.com/mguentner/cannelloni/commit/125a7c72e4bcbbf580aeb6ee03e25ed0540be217

So I also reinstated the old cannelloni recipe with:
https://github.com/ZoranStojsavljevic/meta-socketcan/commit/b79e35425b72ba1caf90404a953235a43202e16f

Zee
_______

On Fri, May 21, 2021 at 7:55 AM Zoran via lists.yoctoproject.org
<zoran.stojsavljevic=gmail.com@...> wrote:

Hello Joel,

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

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

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

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

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

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

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

Thank you again,
Zoran
_______

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

Hi Zoran,

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

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


Joel


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

Hello Yocto developers,

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

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

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

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

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

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

Thank you,
Zoran
_______

Refresh patches:
0001-openssh-8.6p1-fips.patch
0001-conditional-enable-fips-mode.patch

Signed-off-by: Yi Zhao <yi.zhao@...>
---
.../0001-conditional-enable-fips-mode.patch | 38 +++++++------
...ps.patch => 0001-openssh-8.6p1-fips.patch} | 55 ++++++++++---------
recipes-connectivity/openssh/openssh_fips.inc | 2 +-
3 files changed, 50 insertions(+), 45 deletions(-)
rename recipes-connectivity/openssh/openssh/{0001-openssh-8.4p1-fips.patch => 0001-openssh-8.6p1-fips.patch} (92%)

diff --git a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
index 9fd19c0..9bec7d7 100644
--- a/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
+++ b/recipes-connectivity/openssh/openssh/0001-conditional-enable-fips-mode.patch
@@ -1,4 +1,4 @@
-From 48888de317391522186c6ae24a8d6d7d7add2673 Mon Sep 17 00:00:00 2001
+From 1696484c2a06e2ec095d748d2155eb8206dd850b Mon Sep 17 00:00:00 2001
From: Hongxu Jia <hongxu.jia@...>
Date: Sat, 21 Dec 2019 13:03:23 +0800
Subject: [PATCH] conditional enable fips mode
@@ -14,11 +14,12 @@ The ssh_malloc_init function is removed in openssh 8.1p1, we need to
insert ssh_enable_fips_mode function to main function for all
applications.

+Rebase to 8.6p1
Signed-off-by: Yi Zhao <yi.zhao@...>
---
sftp-server-main.c | 1 +
sftp-server.c | 1 +
- sftp.c | 1 +
+ sftp.c | 2 ++
ssh-add.c | 1 +
ssh-agent.c | 1 +
ssh-keygen.c | 1 +
@@ -29,7 +30,7 @@ Signed-off-by: Yi Zhao <yi.zhao@...>
sshd.c | 1 +
xmalloc.c | 20 ++++++++++++++++++++
xmalloc.h | 1 +
- 13 files changed, 32 insertions(+)
+ 13 files changed, 33 insertions(+)

diff --git a/sftp-server-main.c b/sftp-server-main.c
index 06566d3..a10566d 100644
@@ -44,10 +45,10 @@ index 06566d3..a10566d 100644
sanitise_stdfd();

diff --git a/sftp-server.c b/sftp-server.c
-index 7300900..42da9d7 100644
+index 838f048..8a8d87b 100644
--- a/sftp-server.c
+++ b/sftp-server.c
-@@ -1616,6 +1616,7 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
+@@ -1656,6 +1656,7 @@ sftp_server_main(int argc, char **argv, struct passwd *user_pw)
extern char *optarg;
extern char *__progname;

@@ -56,19 +57,20 @@ index 7300900..42da9d7 100644
log_init(__progname, log_level, log_facility, log_stderr);

diff --git a/sftp.c b/sftp.c
-index fb3c08d..85b9b67 100644
+index 3f46c55..e9c8f1d 100644
--- a/sftp.c
+++ b/sftp.c
-@@ -2345,6 +2345,7 @@ main(int argc, char **argv)
- size_t num_requests = DEFAULT_NUM_REQUESTS;
+@@ -2342,6 +2342,8 @@ main(int argc, char **argv)
+ size_t num_requests = 0;
long long limit_kbps = 0;

+ ssh_enable_fips_mode();
++
/* Ensure that fds 0, 1 and 2 are open or directed to /dev/null */
sanitise_stdfd();
msetlocale();
diff --git a/ssh-add.c b/ssh-add.c
-index 7edb9f9..c75f85b 100644
+index 92192fc..4ed14cd 100644
--- a/ssh-add.c
+++ b/ssh-add.c
@@ -667,6 +667,7 @@ main(int argc, char **argv)
@@ -80,7 +82,7 @@ index 7edb9f9..c75f85b 100644
sanitise_stdfd();

diff --git a/ssh-agent.c b/ssh-agent.c
-index 58fe6dd..9018a7c 100644
+index 48a47d4..8a0d7a2 100644
--- a/ssh-agent.c
+++ b/ssh-agent.c
@@ -1388,6 +1388,7 @@ main(int ac, char **av)
@@ -92,7 +94,7 @@ index 58fe6dd..9018a7c 100644
sanitise_stdfd();

diff --git a/ssh-keygen.c b/ssh-keygen.c
-index 6451584..246caa1 100644
+index fc73943..cdb45a9 100644
--- a/ssh-keygen.c
+++ b/ssh-keygen.c
@@ -3153,6 +3153,7 @@ main(int argc, char **argv)
@@ -140,7 +142,7 @@ index a9a6fe3..3c76f70 100644
seed_rng();
TAILQ_INIT(&pkcs11_keylist);
diff --git a/ssh.c b/ssh.c
-index 729d87a..ab78b53 100644
+index a6e7642..8f91534 100644
--- a/ssh.c
+++ b/ssh.c
@@ -650,6 +650,7 @@ main(int ac, char **av)
@@ -152,10 +154,10 @@ index 729d87a..ab78b53 100644
sanitise_stdfd();

diff --git a/sshd.c b/sshd.c
-index fee4703..07faf7b 100644
+index b2ab001..8112d2c 100644
--- a/sshd.c
+++ b/sshd.c
-@@ -1534,6 +1534,7 @@ main(int ac, char **av)
+@@ -1535,6 +1535,7 @@ main(int ac, char **av)
Authctxt *authctxt;
struct connection_info *connection_info = NULL;

@@ -199,13 +201,13 @@ index b48d33b..456a063 100644
+ }
+}
diff --git a/xmalloc.h b/xmalloc.h
-index abaf7ad..b3b1c8c 100644
+index a6b8d23..18fe756 100644
--- a/xmalloc.h
+++ b/xmalloc.h
-@@ -26,3 +26,4 @@ int xasprintf(char **, const char *, ...)
- __attribute__((__nonnull__ (2)));
+@@ -25,3 +25,4 @@ int xasprintf(char **, const char *, ...)
+ __attribute__((__format__ (printf, 2, 3))) __attribute__((__nonnull__ (2)));
int xvasprintf(char **, const char *, va_list)
- __attribute__((__nonnull__ (2)));
+ __attribute__((__nonnull__ (2)));
+void ssh_enable_fips_mode(void);
--
2.17.1
diff --git a/recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch b/recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
similarity index 92%
rename from recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch
rename to recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
index 10687ff..ff1b5dc 100644
--- a/recipes-connectivity/openssh/openssh/0001-openssh-8.4p1-fips.patch
+++ b/recipes-connectivity/openssh/openssh/0001-openssh-8.6p1-fips.patch
@@ -1,7 +1,7 @@
-From 0452f9dc4acf90b8d7ac6ddf6ebbe455d202ce54 Mon Sep 17 00:00:00 2001
+From 064c5cafa532166058a5cc694c4398ed2aaae8d1 Mon Sep 17 00:00:00 2001
From: Hongxu Jia <hongxu.jia@...>
Date: Sat, 21 Dec 2019 11:45:38 +0800
-Subject: [PATCH] openssh 8.4p1 fips
+Subject: [PATCH] openssh 8.6p1 fips

Port openssh-7.7p1-fips.patch from Fedora
https://src.fedoraproject.org/rpms/openssh.git
@@ -19,6 +19,9 @@ Port openssh-7.7p1-fips.patch from Fedora
https://src.fedoraproject.org/rpms/openssh.git
(commit: fbd5f1bee2e2cdc7b1b47f4604b8347d8c3ed63f)

+Signed-off-by: Yi Zhao <yi.zhao@...>
+
+Rebase to 8.6p1
Signed-off-by: Yi Zhao <yi.zhao@...>
---
Makefile.in | 14 +++++++-------
@@ -38,10 +41,10 @@ Signed-off-by: Yi Zhao <yi.zhao@...>
14 files changed, 171 insertions(+), 20 deletions(-)

diff --git a/Makefile.in b/Makefile.in
-index e3cd296..bf53fb0 100644
+index b749206..ee58570 100644
--- a/Makefile.in
+++ b/Makefile.in
-@@ -204,25 +204,25 @@ libssh.a: $(LIBSSH_OBJS)
+@@ -205,25 +205,25 @@ libssh.a: $(LIBSSH_OBJS)
$(RANLIB) $@

ssh$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHOBJS)
@@ -73,7 +76,7 @@ index e3cd296..bf53fb0 100644

ssh-pkcs11-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(P11HELPER_OBJS)
$(LD) -o $@ $(P11HELPER_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS)
-@@ -231,7 +231,7 @@ ssh-sk-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(SKHELPER_OBJS)
+@@ -232,7 +232,7 @@ ssh-sk-helper$(EXEEXT): $(LIBCOMPAT) libssh.a $(SKHELPER_OBJS)
$(LD) -o $@ $(SKHELPER_OBJS) $(LDFLAGS) -lssh -lopenbsd-compat -lssh -lopenbsd-compat $(LIBS) $(LIBFIDO2)

ssh-keyscan$(EXEEXT): $(LIBCOMPAT) libssh.a $(SSHKEYSCAN_OBJS)
@@ -97,10 +100,10 @@ index 32771f2..74fac3b 100644
return (&aes_ctr);
}
diff --git a/dh.c b/dh.c
-index b5bb35e..676f893 100644
+index ce2eb47..c038961 100644
--- a/dh.c
+++ b/dh.c
-@@ -152,6 +152,12 @@ choose_dh(int min, int wantbits, int max)
+@@ -164,6 +164,12 @@ choose_dh(int min, int wantbits, int max)
int best, bestcount, which, linenum;
struct dhgroup dhg;

@@ -110,10 +113,10 @@ index b5bb35e..676f893 100644
+ return (dh_new_group_fallback(max));
+ }
+
- if ((f = fopen(_PATH_DH_MODULI, "r")) == NULL) {
+ if ((f = fopen(get_moduli_filename(), "r")) == NULL) {
logit("WARNING: could not open %s (%s), using fixed modulus",
- _PATH_DH_MODULI, strerror(errno));
-@@ -489,4 +495,38 @@ dh_estimate(int bits)
+ get_moduli_filename(), strerror(errno));
+@@ -502,4 +508,38 @@ dh_estimate(int bits)
return 8192;
}

@@ -153,7 +156,7 @@ index b5bb35e..676f893 100644
+
#endif /* WITH_OPENSSL */
diff --git a/dh.h b/dh.h
-index 5d6df62..54c7aa2 100644
+index c6326a3..e51e292 100644
--- a/dh.h
+++ b/dh.h
@@ -45,6 +45,7 @@ DH *dh_new_group_fallback(int);
@@ -163,9 +166,9 @@ index 5d6df62..54c7aa2 100644
+int dh_is_known_group(const DH *);

u_int dh_estimate(int);
-
+ void dh_set_moduli_file(const char *);
diff --git a/kex.c b/kex.c
-index 30425ab..1250f42 100644
+index 709a0ec..c4ac65f 100644
--- a/kex.c
+++ b/kex.c
@@ -165,7 +165,10 @@ kex_names_valid(const char *names)
@@ -257,7 +260,7 @@ index f03b7df..57b8779 100644
#define SSH_ALLOWED_CA_SIGALGS \
"ssh-ed25519," \
diff --git a/readconf.c b/readconf.c
-index 724974b..870a654 100644
+index 0f27652..6311bd1 100644
--- a/readconf.c
+++ b/readconf.c
@@ -2475,11 +2475,16 @@ fill_default_options(Options * options)
@@ -283,10 +286,10 @@ index 724974b..870a654 100644
do { \
if ((r = kex_assemble_names(&options->what, \
diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
-index d8dc712..c6e62e4 100644
+index 798b24b..bbc2380 100644
--- a/sandbox-seccomp-filter.c
+++ b/sandbox-seccomp-filter.c
-@@ -157,6 +157,9 @@ static const struct sock_filter preauth_insns[] = {
+@@ -160,6 +160,9 @@ static const struct sock_filter preauth_insns[] = {
#ifdef __NR_open
SC_DENY(__NR_open, EACCES),
#endif
@@ -297,7 +300,7 @@ index d8dc712..c6e62e4 100644
SC_DENY(__NR_openat, EACCES),
#endif
diff --git a/servconf.c b/servconf.c
-index 9695583..98f6303 100644
+index 4d1910f..4502fef 100644
--- a/servconf.c
+++ b/servconf.c
@@ -218,11 +218,16 @@ assemble_algorithms(ServerOptions *o)
@@ -323,7 +326,7 @@ index 9695583..98f6303 100644
do { \
if ((r = kex_assemble_names(&o->what, defaults, all)) != 0) \
diff --git a/ssh-keygen.c b/ssh-keygen.c
-index cfb5f11..6451584 100644
+index 027c6db..fc73943 100644
--- a/ssh-keygen.c
+++ b/ssh-keygen.c
@@ -205,6 +205,12 @@ type_bits_valid(int type, const char *name, u_int32_t *bitsp)
@@ -359,7 +362,7 @@ index cfb5f11..6451584 100644
error("Could not save your private key in %s: %s",
prv_tmp, strerror(errno));
diff --git a/ssh.c b/ssh.c
-index 53330da..729d87a 100644
+index 35b6b51..a6e7642 100644
--- a/ssh.c
+++ b/ssh.c
@@ -77,6 +77,8 @@
@@ -400,7 +403,7 @@ index 53330da..729d87a 100644
if (options.sk_provider != NULL && *options.sk_provider == '$' &&
strlen(options.sk_provider) > 1) {
diff --git a/sshd.c b/sshd.c
-index eff4778..fee4703 100644
+index 8918eb2..b2ab001 100644
--- a/sshd.c
+++ b/sshd.c
@@ -66,6 +66,7 @@
@@ -420,7 +423,7 @@ index eff4778..fee4703 100644
#include "openbsd-compat/openssl-compat.h"
#endif

-@@ -1536,6 +1539,18 @@ main(int ac, char **av)
+@@ -1537,6 +1540,18 @@ main(int ac, char **av)
#endif
__progname = ssh_get_progname(av[0]);

@@ -439,7 +442,7 @@ index eff4778..fee4703 100644
/* Save argv. Duplicate so setproctitle emulation doesn't clobber it */
saved_argc = ac;
rexec_argc = ac;
-@@ -2017,6 +2032,10 @@ main(int ac, char **av)
+@@ -2023,6 +2038,10 @@ main(int ac, char **av)
/* Reinitialize the log (because of the fork above). */
log_init(__progname, options.log_level, options.log_facility, log_stderr);

@@ -447,11 +450,11 @@ index eff4778..fee4703 100644
+ logit("FIPS mode initialized");
+ }
+
- /* Chdir to the root directory so that the current disk can be
- unmounted if desired. */
- if (chdir("/") == -1)
+ /*
+ * Chdir to the root directory so that the current disk can be
+ * unmounted if desired.
diff --git a/sshkey.c b/sshkey.c
-index b25c59a..8fcfe22 100644
+index e92709d..5bd4fa9 100644
--- a/sshkey.c
+++ b/sshkey.c
@@ -34,6 +34,7 @@
diff --git a/recipes-connectivity/openssh/openssh_fips.inc b/recipes-connectivity/openssh/openssh_fips.inc
index 194a6f4..efba8db 100644
--- a/recipes-connectivity/openssh/openssh_fips.inc
+++ b/recipes-connectivity/openssh/openssh_fips.inc
@@ -6,7 +6,7 @@ DEPENDS += " \
RRECOMMENDS_${PN}-sshd_remove = "rng-tools"

SRC_URI += " \
- file://0001-openssh-8.4p1-fips.patch \
+ file://0001-openssh-8.6p1-fips.patch \
file://0001-conditional-enable-fips-mode.patch \
file://openssh-6.6p1-ctr-cavstest.patch \
file://openssh-6.7p1-kdf-cavs.patch \
--
2.25.1

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

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

== attendees ==
Trevor Woerner, Stephen Jolley, Steve Sakoman, Joshua Watt, Jon Mason, Tony
Tascioglu, Richard Purdie, Scott Murray, Armin Kuster, Paul Barker, Tim
Orling, Alejandro H, Bruce Ashfield, Randy MacLeod, Denys Dmytriyenko

== notes ==
- 3.1.9 (dunfell) through QA awaiting release approval, no blockers
- 3.4 m1 (honister) released
- identified an RCU stall hang that’s been causing some of our AB-INT issues. closed a couple of AB-INT bugs as a result, but found some more
- prserv rewrite using asyncio is stuck on AB hangs when tested on larger scale
- ARM-specific ltp hang issue (bug 14460, https://bugzilla.yoctoproject.org/show_bug.cgi?id=14460)
- multiconfig needs simpler test cases
- about 50% of AB issues are ptest-related

== general ==
RP: the RCU fix is awesome, significantly fixed AB-INT issues


PaulB: (summary) prserv code updated to asycio, it works for me on my home
machine, but then we see failures when that code is run on the AB. bitbake
hangs, probably in the shutdown path. i have been able to reproduce it
at home. works with python3.6 but seems to fail with python3.8 (from
buildtools). we’re using asyncio and multiprocessing in various modules
and it’s unclear how well they play together. there might be issues wrt
to which system gets initiated first and when forking occurs
JPEW: buildtools tarball only?
PaulB: i need to check the matrix of what’s running native vs what’s from
the buildtools
JPEW: you’re mixing asyncio and multiprocessing?
PaulB: yes
JPEW: doesn’t that do a fork/exec itself? just to be clear: you’re
init’ing asyncio first, then forking?
PaulB: yes, that’s what other parts of the code are doing too. maybe we
should fork first, then call start_tcp_server(), then start the asyncio?
JPEW: server or client?
PaulB: server, but that’s in bitbake. there’s no clear docs on how these
things would work together
JPEW: the AB uses hash equiv server but it’s running on its own, so i’m
not sure what code paths are used
PaulB: yes, RP and i discussed that and we know that code path is not being
used
JPEW: so what happens? what are you seeing?
PaulB: it gets so far through the test suite then the bitbake server stops.
we see the keepalive messages but no other output. RP got stuff installed
and did some dumps. it looks to be prserver-export functionality related.
bitbake is finished and is run successfully, but stalled in tring to
shutdown bitbake 
RP: for example in one case we saw 57 zombie threads, the 58th is stuck in
a client side asyncio call to prserv. we tried killing the prserv, so
we’re not sure if it’s hung. then we found it waiting on the socket
(which was already closed)
PaulB: and if we sent sigint to the process, it’s not waiting
RP: we had backtrace issues which we’ve fixed. but there’s this hang. some
tests failed early with python3.8, but then an oeselftest failed. one of
the parsers was stuck in this prserv call
PaulB: we should take a look through prserv.bbclass to see what’s also done.
we could look at the args used and check for parse completed events
RP: hashserv vs prserv: hashserv is called in its own context but prserv is
called from within the parser threads
PaulB: yes, back to the issue of the init-vs-fork timing
JPEW: i would expect that’s an issue. have them init in each thread. are
they threads or processes?
RP: can’t remember. i think processes, but not sure
JPEW: that seems something to try. i would guess setting up asyncio then
forking wouldn’t work over that boundary. so have each parser thread
setup their asyncio separately
PaulB: we can run builds quite happily. the build works, but then when i try
the prserv-export that’s where it falls over
RP: in the parse thread
PaulB: it’s also queried in do_package, and that seems fine
JPEW: i think asyncio in python is an abstraction around some OS primitive,
but it’s configurable so it’s possible the one being put in the
buildtools tarballs (from wherever it’s being built) isn’t properly
setup for the actual machine on which it’s run. if we could dump the
config then we’lll probably see that it’s not using the proper backend
PaulB: i think there’s just a linux one and a windows one
JPEW: okay, maybe it’s something else
RP: i think the async init is key
PaulB: i think asyncio has a good reputation of working. on stackoverflow
there are other instances/questions of people mixing asyncio with threads
and none of them have definitive answers. so there must be caveats that
the docs don’t address. most users of asyncio are basing their entire
software on it, whereas we’re just using it in one piece and mixing it
with everything else. we have some good leads here, i’ll do a writeup
and send my latest patches (there’s a new read-only patch)
RP: JPEW if you could look at the patches, specifically the shutdown paths
that would be great. has anyone else expressed interest?
ScottM: I’ll be taking a look, as part of AGL. it’s on my short list


PaulB: there’s a patch series that Khem has forwarded, python linter fixes,
i think we need more discussion on it. ideally we should be testing this
with every commit, otherwise we end up with these massive linter patches
that mess up the repo history
JPEW: i’m a big fan of automatic linters/formatters, but it has to be
automated
TimO: me too. not sure how it’ll work for a large group like this
PaulB: having these flag days is really bad for breaking “git blame” etc
RP: bad implications for LTS. some changes i like, some i’m less keen on
PaulB: if there’s some agreement, then we could add a linter config file to
the project so we’re all using the same thing
RP: we are running the pylint stuff on the AB, i’m blanking on where the
config file is
Bruce: i usually do that
RP: we do some of this stuff in oe-core (pylint script) but was only
configured to show errors, but nobody is even looking at those now
Bruce: i looked at the github link, this is a “throw oever the wall”
patch. there isn’t going to be any updates (“i only do github pull
requests, could you please forward this to the list”)
TrevorW: do we have a checkpatch.sh script?
RP: we had something, but nobody is considering/using it
TrevorW: if the patch doesn’t pass, it doesn’t get applied. so it should
be up to the submitter to fix
PaulB: the check tools we have aren’t easy to run locally
RP: it should be. if we had something would someone maintain it?
TrevorW: i tried a long time ago to create such a tool but there are
significant differences between (for example) the formatting between YP
and OE so how can a tool be created?
RP: yes there are some conflicts, but there is also a lot of agreement, so
let’s focus on the agreed-upon things first. i think the only issue is
tabs vs spaces
TrevorW: i think there was also an ordering issue
RP: yes, but ordering is not irrelevant. changing the order can change the
behaviour, so we can’t enforce ordering
Armin: there is an ordering styleguide
TimO: some linters are too aggressive


RP: JPEW: how did the SBOM plugfest go?
JPEW: it went well. gave us an idea of how compatible we are. i don’t think
we’re too far off. i think there’s another one coming up. i think
they’re going to be a plugfest every 3 months or so until momentum goes
down. i’ll go to the next one. i have some patches, we are compatible
but there are some things we can change. it was interesting to see the
issues of the community at large. but we’re lucky because we have all
the data (whereas other projects don’t, necessarily) i believe one of
our outstanding issues is that license strings need a sync, but that’s
for another time. i think our mappings might be bad.
RP: i’d be interested in a list of the ones that aren’t valid
JPEW: i can track that down


RP: i liked the compression patch series, it failed in testing but i think a
small tweak will fix it


TrevorW: tomorrow is the OEHH
https://www.openembedded.org/wiki/Happy_Hours


Bruce: we’re starting to shape up for -m2. 5.13 kernels added. 5.4 dropped
from master but will send rev updates for dunfell for 5.4
RP: so just as we got 5.10 working, we’ll drop it
Bruce: we’ve been testing with -dev a lot (ARM64 needs awk). i think we’ll
add 5.13, then let all 3 sit there for a while, then drop 5.10. 5.13 has
been tested a lot more than most


TrevorW: has there been a resolution wrt to the new operator discussion?
RP: no. i think there are more invasive things that need to be done with some
existing operators.
TrevorW: so the new operator is a go? it’s going in?
RP: not sure yet, more experiments needed
ScottM: at the end of the day we’re talking about 1 person’s issue with 1
BSP. is this a generic issue to warrant such a move?
RP: i think many people have hit it, but worked around it. so i think there is
an architectural problem that needs a wider discussion
ScottM: i think there’s more value in the changes to += and _append than
adding a new operator
RP: i think we need both. that’s why i’ve deferred. i need to do more
experiments
ScottM: could we do a flag day, or a carry-over for say 1 year. do we have a
process for that
RP: we don’t have a process, the TSC would have to come up with a plan for
it. it would be specific for this case

Hi All,

I want to make a recipe for python3-pyqt5 and python3-pyqtwebengine, 
the problem is that the source doe does not contain setup.py , it contains project.py and configure.py.

Is there a solution for this so that it works with setuptools and pypi ?

Thanks,
Talel

On Tue, Jun 29, 2021 at 2:41 AM Josef Holzmayr
<jester@...> wrote:

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:

I was thinking about my issue described here [1], and discovered the
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
use to stop recipes from being built for machines (/hosts) with which
the recipes are not compatible". And so I wondered if it would make
sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers
(say `first-project-image` and `second-project-image`), and in each of
those layers I create `.bbappends` to configure some packages. Typically
`hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because
`second-project-image` is part of my bblayers.conf, then the
hostapd_%.bbappend from `second-project-image` is used and may have an
impact on `first-project-image`, which I don't want. I really want this
bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that
`first-project-image` and `second-project-image` are two different
projects, and build them from two different BUILDDIRs. The thing I don't
like here is that all the packages are therefore downloaded and built
twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
of `first-project-image`, I would set "COMPATIBLE_IMAGE =
'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
'second-project-image'". So that I could still share a BUILDDIR between
different projects.

Yocto chant #1 applies: "Recipe data is local, configuration data is
global." Means: the recipe does not see at all which image it is being
built for. So it also can't react to it - you can't check a variable
against something you do not even see.

How bad of an idea is that?

It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images,
because that actually what they mean to do: you change the ABI/API of
the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
derivatives, so its all there already. It just cannot be triggered from
the image, because, well.. see first pragraph of the answer.

I was also going to suggest distros.

And also, if the concern really is about builds reusing downloads,
etc, then by all means configure those different distro builds to
share download and sstate directories.

Bruce

Greetz

Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers
<https://stackoverflow.com/questions/68167244/image-specific-layers>

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

On Tue, Jun 29, 2021 at 8:41 AM Josef Holzmayr
<jester@...> wrote:

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:

I was thinking about my issue described here [1], and discovered the
variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can
use to stop recipes from being built for machines (/hosts) with which
the recipes are not compatible". And so I wondered if it would make
sense to add COMPATIBLE_IMAGE, for a similar purpose.

Let me explain my issue: I define different images in different layers
(say `first-project-image` and `second-project-image`), and in each of
those layers I create `.bbappends` to configure some packages. Typically
`hostapd` is used by both images, but with a different config file.

The thing is that when I run `bitbake first-project-image`, because
`second-project-image` is part of my bblayers.conf, then the
hostapd_%.bbappend from `second-project-image` is used and may have an
impact on `first-project-image`, which I don't want. I really want this
bbappend to only affect the image `second-project-image`.

One way I can see to deal with that is to realize that
`first-project-image` and `second-project-image` are two different
projects, and build them from two different BUILDDIRs. The thing I don't
like here is that all the packages are therefore downloaded and built
twice, which seems like a loss of time and space.

That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend
of `first-project-image`, I would set "COMPATIBLE_IMAGE =
'first-project-image'", and similarly for "COMPATIBLE_IMAGE =
'second-project-image'". So that I could still share a BUILDDIR between
different projects.

Yocto chant #1 applies: "Recipe data is local, configuration data is
global." Means: the recipe does not see at all which image it is being
built for. So it also can't react to it - you can't check a variable
against something you do not even see.

How bad of an idea is that?

It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images,
because that actually what they mean to do: you change the ABI/API of
the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO
derivatives, so its all there already. It just cannot be triggered from
the image, because, well.. see first pragraph of the answer.

I agree with everything Josef said, but just wanted to add that if
it's just different
configurations needed for different images it might be easier to just
put the configs
into separate packages and install the right package in the respective image.

So configuration for first-project-image goes into <somepackage>-foo, and the
config for second-project-image goes into <somepackage>-bar. Then the image
would add the correct configuration package.

This only works for the simple cases, and if you really need to change the way
a package is built the DISTRO way is better.

Erik

Greetz

Thanks in advance,
Jonas

[1]: https://stackoverflow.com/questions/68167244/image-specific-layers
<https://stackoverflow.com/questions/68167244/image-specific-layers>

Hello,

i have tried to build yocto image. And it compiled successfully without any error but when am trying to BOOT them it didnt prompt any error message
what should i do to BOOT my yocto build image on zc702 board

What is your output from the ZC702 (USB) serial console?


I had similar issue on ZCU102 and debugged my issue:

"the U-Boot not showing anything I have debugged to be an issue where
DEVICE_TREE does not propagate from the BitBake recipe into the U-Boot
build (both for upstream and Xilinx). I have reported this on
meta-xilinx but will make it a separate bug report."

I can imagine the same problem would occur on ZC702 (single-core Zynq).

I have posted a few messages with meta-xilinx in the subject on how I
had to bring Yocto to the ZCU102.

Regards,

Leon.


--
Leon Woestenberg
leon@...
M: +31 6 472 30 372

Sidebranch Embedded Systems
Eindhoven, The Netherlands
http://www.sidebranch.com



On Tue, Jun 29, 2021 at 8:02 AM shoaib akhtar
<m.shoaibakhtar98@...> wrote:

i have tried to build yocto image. And it compiled successfully without any error but when am trying to BOOT them it didnt prompt any error message my BBlayer.conf is shown below

# POKY_BBLAYERS_CONF_VERSION is increased each time build/conf/bblayers.conf
# changes incompatibly
POKY_BBLAYERS_CONF_VERSION = "2"

BBPATH = "${TOPDIR}"
BBFILES ?= ""

BBLAYERS ?= " \
/media/vmnrtc/Drive/poky/meta \
/media/vmnrtc/Drive/poky/meta-poky \
/media/vmnrtc/Drive/poky/meta-yocto-bsp \
/media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-bsp \
/media/vmnrtc/Drive/poky/meta-openembedded/meta-oe \
/media/vmnrtc/Drive/poky/meta-openembedded/meta-python \
/media/vmnrtc/Drive/poky/meta-xilinx/meta-xilinx-standalone \
/media/vmnrtc/Drive/poky/meta-xilinx-tools \
/media/vmnrtc/Drive/poky/build/meta-networking \
"

MY files in image directories


boot.bin
boot.bin-zc702-zynq7
boot.bin-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
boot.scr
core-image-minimal-zc702-zynq7-20210629031233.qemuboot.conf
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio
core-image-minimal-zc702-zynq7-20210629031233.rootfs.cpio.gz.u-boot
core-image-minimal-zc702-zynq7-20210629031233.rootfs.manifest
core-image-minimal-zc702-zynq7-20210629031233.rootfs.tar.gz
core-image-minimal-zc702-zynq7-20210629031233.testdata.json
core-image-minimal-zc702-zynq7.cpio
core-image-minimal-zc702-zynq7.cpio.gz.u-boot
core-image-minimal-zc702-zynq7.manifest
core-image-minimal-zc702-zynq7.qemuboot.conf
core-image-minimal-zc702-zynq7.tar.gz
core-image-minimal-zc702-zynq7.testdata.json
modules--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.tgz
modules-zc702-zynq7.tgz
pxeboot
pxelinux.cfg
u-boot.elf
u-boot.img
u-boot-xlnx-AUTOINC+bb4660c33a.elf
u-boot-xlnx-initial-env
u-boot-xlnx-initial-env-zc702-zynq7
u-boot-xlnx-initial-env-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0
u-boot-zc702-zynq7.elf
u-boot-zc702-zynq7.img
u-boot-zc702-zynq7-v2020.01-xilinx-v2020.2+gitAUTOINC+bb4660c33a-r0.img
u-boot-zynq-scr--1.0-r0.scr
uEnv.txt
uImage
uImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
uImage-zc702-zynq7.bin
zImage
zImage--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.bin
zImage-zc702-zynq7.bin
zynq-zc702--5.4+git0+62ea514294-r0-zc702-zynq7-20210622034511.dtb
zynq-zc702.dtb
zynq-zc702-zc702-zynq7.dtb



what should i do to BOOT my yocto build image on zc702 board

Howdy!

Am 29.06.2021 um 01:28 schrieb Jonas Vautherin:

I was thinking about my issue described here [1], and discovered the variables called COMPATIBLE_MACHINE and COMPATIBLE_HOST, which "you can use to stop recipes from being built for machines (/hosts) with which the recipes are not compatible". And so I wondered if it would make sense to add COMPATIBLE_IMAGE, for a similar purpose.
Let me explain my issue: I define different images in different layers (say `first-project-image` and `second-project-image`), and in each of those layers I create `.bbappends` to configure some packages. Typically `hostapd` is used by both images, but with a different config file.
The thing is that when I run `bitbake first-project-image`, because `second-project-image` is part of my bblayers.conf, then the hostapd_%.bbappend from `second-project-image` is used and may have an impact on `first-project-image`, which I don't want. I really want this bbappend to only affect the image `second-project-image`.
One way I can see to deal with that is to realize that `first-project-image` and `second-project-image` are two different projects, and build them from two different BUILDDIRs. The thing I don't like here is that all the packages are therefore downloaded and built twice, which seems like a loss of time and space.
That's where I thought about COMPATIBLE_IMAGE. In the hostapd_%.bbappend of `first-project-image`, I would set "COMPATIBLE_IMAGE = 'first-project-image'", and similarly for "COMPATIBLE_IMAGE = 'second-project-image'". So that I could still share a BUILDDIR between different projects.

Yocto chant #1 applies: "Recipe data is local, configuration data is global." Means: the recipe does not see at all which image it is being built for. So it also can't react to it - you can't check a variable against something you do not even see.

How bad of an idea is that?

It just doesn't work. If that counts as "bad" is left for you to decide :)

What you actually might use is using different DISTROs for the images, because that actually what they mean to do: you change the ABI/API of the image. And you can also define a base DISTRO and COMPATIBLE_DISTRO derivatives, so its all there already. It just cannot be triggered from the image, because, well.. see first pragraph of the answer.

Greetz

Thanks in advance,
Jonas
[1]: https://stackoverflow.com/questions/68167244/image-specific-layers <https://stackoverflow.com/questions/68167244/image-specific-layers>