Date   

Re: [meta-rockchip][PATCH 2/3] IMAGE_FSTYPES: remove ext4

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:40 AM, Trevor Woerner wrote:
The ext4 IMAGE_FSTYPES does not need to be mentioned explicitly. It will be
automatically generated in cases where it is needed.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/rockchip-defaults.inc | 1 -
1 file changed, 1 deletion(-)

diff --git a/conf/machine/include/rockchip-defaults.inc b/conf/machine/include/rockchip-defaults.inc
index b41c523..0666119 100644
Applied to meta-rockchip master.


Re: [meta-rockchip][PATCH 1/3] conf/machine/include/nanopi-m4.inc: add full include path

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:39 AM, Trevor Woerner wrote:
Specify the full include path to the rk3399.inc file.

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/include/nanopi-m4.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/conf/machine/include/nanopi-m4.inc b/conf/machine/include/nanopi-m4.inc
index 7ca91db..b5251a1 100644
Applied to meta-rockchip master.


Re: Python2 in Gatesgarth

Marek Belisko
 

Hi Aashik,

On Wed, Jun 30, 2021 at 4:25 PM Aashik Aswin <thisisaash9698@...> wrote:

Hello Developers,

We are migrating our platforms from Zeus to Gatesgarth, We could see that the native Python2 bb file and core modules have been removed.

As much of our platform code is in Python2, I was wondering if there is some way we can re-enable python2 support in our yocto environment to compile/run python2 scripts ?
You can use meta-python2 [0] layer

Thanks in Advance,

Thanks & Regards
Aashik


[0] - https://git.openembedded.org/meta-python2

marek


Python2 in Gatesgarth

Aashik Aswin
 

Hello Developers,

We are migrating our platforms from Zeus to Gatesgarth, We could see that the native Python2 bb file and core modules have been removed.

 As much of our platform code is in Python2, I was wondering if there is some way we can re-enable python2 support in our yocto environment to compile/run python2 scripts ?

Thanks in Advance,

Thanks & Regards
Aashik


#yocto #zeus #yocto #zeus

Monsees, Steven C (US)
 

 

I am running with zeus 3.0.4 and appear to have an issue with the mount command supporting NFS… ?

 

Can someone explain the following and how I can get “mount” to support NFS ?

 

Trying to mount the UDM from the AIO

mount.nfs: Operation not permitted

Failed to mount the UDM from the AIO!

Trying tNFS: bad mount option value specified: minorversion=1

 

Thanks,

Steve


Question regarding custom device tree update

Sohil Shah <sohils@...>
 

Hello,

I am kinda a noob at this so please bear with me.

I am using the sama5d27-wlsom1-ek board for my demo and I am trying to make changes to the device tree.

So far I have compiled core-image-minimal and find my dtb files are generated in
/tmp/work/sama5d27_wlsom1_ek_sd-poky-linux-gnueabi/linux-at91/5.4+gitAUTOINC+3dba8c9991-r0/build/arch/arm/boot/dts
folder.

Also I find many different dts files in
build/tmp/work-shared/sama5d27-wlsom1-ek-sd/kernel-source/arch/arm/boot/dts

But where does my machine get device tree files if they are generated inside the build folder and if so where do I place my custom files so that they get called during bitbake.

I want to build the image using my custom dts file where I enable certain peripherals and disable the ones not required. (A test to update dtb's in future).

I tried different methods found here

But, I seem to run into some errors when I try to build the image.

Please help and let me know if I missed any required information from my side.

Thank you and Regards,
Sohil


[poky][PATCH] devtool: deploy-target: Fix preserving attributes when using --strip

Florian Amstutz
 

Commit a2db4fa127a3347fc6df31f895fb0b552669119e added ${WORKDIR}/deploy-* to
PSEUDO_IGNORE_PATHS. This breaks the --strip mode since ${D} is copied to
deploy-target-stripped. Use the directory devtool-deploy-target-stripped
instead.

[YOCTO #14451]

Signed-off-by: Florian Amstutz <florian.amstutz@...>
---
 scripts/lib/devtool/deploy.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 
diff --git a/scripts/lib/devtool/deploy.py b/scripts/lib/devtool/deploy.py
index e5af2c95ae..833322571f 100644
--- a/scripts/lib/devtool/deploy.py
+++ b/scripts/lib/devtool/deploy.py
@@ -168,7 +168,7 @@ def deploy(args, config, basepath, workspace):
         if args.strip and not args.dry_run:
             # Fakeroot copy to new destination
             srcdir = recipe_outdir
-            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 'deploy-target-stripped')
+            recipe_outdir = os.path.join(rd.getVar('WORKDIR'), 'devtool-deploy-target-stripped')
             if os.path.isdir(recipe_outdir):
                 bb.utils.remove(recipe_outdir, True)
             exec_fakeroot(rd, "cp -af %s %s" % (os.path.join(srcdir, '.'), recipe_outdir), shell=True)
-- 
2.17.1
 


Re: Launching script at the very end of the image process

Richard Purdie
 

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


Re: Launching script at the very end of the image process

Cardaillac, Yann
 

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


Re: Launching script at the very end of the image process

Richard Purdie
 

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


man package issue

sateesh m
 

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.

ERROR: core-image-sato-1.0-r0 do_rootfs: Postinstall scriptlets of ['man-pages'] have failed. If the intention is to defer them to first boot,
then please place them into pkg_postinst_ontarget_${PN} ().
Deferring to first boot via 'exit 1' is no longer supported.
 

--
Thanks & Regards,
Sateesh


[meta-mingw] [PATCH] libidn2: package all files

Samuli Piippo
 

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


Launching script at the very end of the image process

Cardaillac, Yann
 

Hi yall,

 

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.

 

I’ve made a recipe (.inc) that I’m able to access directly doing so:

 

bitbake ycn-image -c release_ycn

 

To give a bit more context here’s how I’ve made it :

 

File ycn-image.bb:

 

SUMMARY = "Ycn image"

 

require recipes-core/images/core-image-base.bb

inherit package-list

 

require ycn-release.inc

 

File ycn-release.inc:

 

do_release_ycn() {

}

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.

 

If you happen to have any leads on the subject please don’t hesitate to share!

 

Best regards,

 

Yann


[meta-gplv2] [PATCH] coreutils_6.9.bb: Fix build with glibc 2.34

Khem Raj
 

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


Re: Problem with YOCTO Dunfell and host Fedora 33

Zoran
 

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
_______




[meta-openssl102-fips][PATCH] openssh: refresh patches for 8.6p1

Yi Zhao
 

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

Trevor Woerner
 

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


Yocto Project Status WW26`21

Stephen Jolley
 

Current Dev Position: YP 3.4 M2

Next Deadline: 12th July 2021 YP 3.4 M2 build

 

Next Team Meetings:

 

Key Status/Updates:

  • YP 3.1.9 has been through QA and is awaiting release approval, no blocking issues were identified.
  • YP 3.4 M1 was released.
  • Significantly for the project, we have now identified a kernel hang caused from RCU stalls which has been plaguing our autobuilder testing for months. The issue is still open in upstream mainline kernels but there is a patch queued in the rcu tree for it. Since applying this patch to linux-yocto, our builds have been noticeably greener and more stable. We have closed out many of the related AB-INT bugs and will be creating new ones for any remaining issues as they occur since it is hard to tell some other bugs apart from the RCU issue.
  • The prserv rewrite to use asyncio is stuck on autobuilder hangs when testing at larger scale. We’d welcome help from anyone with more details asyncio knowledge/experience as it is looking like the new code isn’t entirely stable in python 3.5/3.6 and may have “at exit” issues, as well as perhaps issues mixing async io code on the client side with multiprocessing during parsing.
  • There does still seem to be an arm specific LTP hang reading /proc/kmsg now tracked by bug 14460.
  • The multiconfig changes in bitbake continue to cause problems, we still need simpler test cases to reproduce issues rather than huge builds. The existing patches seem to fix some workloads and break others. Richard is trying to fix but trying to fix autobuilder issues and other problems and these are slow builds to debug.
  • Intermittent autobuilder issues continue to occur, about 50% of the open issues are now ptest failures and the rest are various other races or timeouts. You can see the list of failures we’re continuing to see by searching for the “AB-INT” tag in bugzilla: https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

 

YP 3.4 Milestone Dates:

  • YP 3.4 M1 is released
  • YP 3.4 M2 build date 2021/07/12
  • YP 3.4 M2 Release date 2021/07/23
  • YP 3.4 M3 build date 2021/08/23 (Feature Freeze)
  • YP 3.4 M3 Release date 2021/09/03
  • YP 3.4 M4 build date 2021/10/04
  • YP 3.4 M4 Release date 2021/10/29

 

Planned upcoming dot releases:

  • YP 3.1.9 is under review
  • YP 3.3.2 build date 2021/07/19
  • YP 3.3.2 release date 2021/07/30
  • YP 3.1.10 build date 2021/07/26
  • YP 3.1.10 release date 2021/08/06
  • YP 3.1.11 build date 2021/09/13
  • YP 3.1.11 release date 2021/9/24

 

Tracking Metrics:

 

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

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

(    Cell:                (208) 244-4460

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

 


pyqtwebengine recipe problem

Bel Hadj Salem Talel <bhstalel@...>
 

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


Re: Would COMPATIBLE_IMAGE make sense?

Bruce Ashfield
 

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

3801 - 3820 of 57789