Date   

[ANNOUNCEMENT] Yocto Project 3.1.9 (dunfell-23.0.9) is Released

Vineela
 

Hello,

 

We are pleased to announce the Yocto Project 3.1.9 (dunfell-23.0.9) Release is now available for download.

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

 

A gpg signed version of these release notes is available at:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/RELEASENOTES

 

Full Test Report:

 

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/testreport.txt

 

Thank you for everyone's contributions to this release.

 

Vineela Tummalapalli

Yocto Project Build and Release

vineela.tummalapalli@...

 

- --------------------------

yocto-3.1.9 Release Notes

- --------------------------

 

- --------------------------

Repositories/Downloads

- --------------------------

 

Repository Name: poky

Repository Location: https://git.yoctoproject.org/git/poky

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 43060f59ba60a0257864f1f7b25b51fac3f2d2cf

Release Artefact: poky-dunfell-23.0.9

sha: d2a7acbaca384408594b72f25883f10b454215af97e31914e8a11035a0334424

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/poky-dunfell-23.0.9.tar.bz2

 

Repository Name: openembedded-core

Repository Location: https://git.openembedded.org/openembedded-core

Branch: dunfell

Tag: 2020-04.9-dunfell

Git Revision: ac8181d9b9ad8360f7dba03aba8b00f008c6ebb4

Release Artefact: oecore-dunfell-23.0.9

sha: d4fc5e5333bc6b2dee464d1845554920e3d504ab16a47e6d335d5c8a185e0dcd

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/oecore-dunfell-23.0.9.tar.bz2

 

Repository Name: meta-mingw

Repository Location: https://git.yoctoproject.org/git/meta-mingw

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 524de686205b5d6736661d4532f5f98fee8589b7

Release Artefact: meta-mingw-dunfell-23.0.9

sha: e5f8e6777003d329fe7ff9e69c9e9f46edf5a272198a194cbc79b866c7b9dab6

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-mingw-dunfell-23.0.9.tar.bz2

 

Repository Name: meta-gplv2

Repository Location: https://git.yoctoproject.org/git/meta-gplv2

Branch: dunfell

Tag: yocto-3.1.9

Git Revision: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac

Release Artefact: meta-gplv2-dunfell-23.0.9

sha: 39bffee0bc5a93e224073036e6a544d83c40f5bccc4c8faeb3995cef323969e1

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/meta-gplv2-dunfell-23.0.9.tar.bz2

 

Repository Name: bitbake

Repository Location: https://git.openembedded.org/bitbake

Branch: 1.46

Tag: 2020-04.9-dunfell

Git Revision: 0e0af15b84e07e6763300dcd092b980086b9b9c4

Release Artefact: bitbake-dunfell-23.0.9

sha: 9a3da4317d9e43ef9b0e66ed0d8070d373fc41fa34648e2a6b04c591d12b97d0

Download Locations:

http://downloads.yoctoproject.org/releases/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

http://mirrors.kernel.org/yocto/yocto/yocto-3.1.9/bitbake-dunfell-23.0.9.tar.bz2

 

Repository Name: yocto-docs

Repository Location: https://git.yoctoproject.org/git/yocto-docs

Branch: dunfell

Tag: yocto-3.1.9

Git Revision:0fadb292429b4147408798ed4c806ba6d9dd81b8

 

- -------------

Contributors

- -------------

akash hadke

Andrea Adami

Bruce Ashfield

Changqing Li

Daniel McGregor

Guillaume Champagne

Jain Sangeeta

Kai Kang

Klaus Heinrich Kiwi

Lee Chee Yang

Michael Halstead

Ming Liu

Ovidiu Panait

Richard Purdie

Ross Burton

Sana Kazi

Stephen Jolley

Steve Sakoman

Tony Tascioglu

Vineela Tummalapalli

Volker Vogelhuber

Yi Zhao

 

- ---------------

Known Issues

- ---------------

N/A

 

 

- ---------------

Security Fixes

- ---------------

Revert "python3: fix CVE-2021-23336"

python3: fix CVE-2021-23336

gstreamer-plugins-good: fix CVE-2021-3497 CVE-2021-3498

gnutls: fix CVE-2021-20231 CVE-2021-20232

libxml: fix CVE-2021-3517 CVE-2021-3537

grub: Exclude CVE-2019-14865 from cve-check

cve-extra-exclusions.inc: add exclusion list for intractable CVE's

expat: set CVE_PRODUCT

openssh: Add fixes for CVEs reported for openssh

tiff: Add fix for CVE-2020-35521 and CVE-2020-35522

cups: whitelist CVE-2021-25317

 

 

- ---------------

Fixes

- ---------------

bitbake: cooker: Avoid parser deadlocks

bitbake: cooker: Ensure parser is cleaned up

bitbake: cooker: Explictly shut down the sync thread

bitbake: cooker: Ensure parse_quit thread is closed down

kernel.bbclass: fix do_sizecheck() comparison

valgrind: fix a typo

ruby: 2.7.1 -> 2.7.3

bind: 9.11.22 -> 9.11.32

poky.conf: Bump version for 3.1.9 release

poky.conf: Add openSUSE Leap 15.2 as a supported distro

documentation: prepare for 3.1.9 release

ref-system-requirements.rst: Add openSUSE Leap 15.2 to list of supported distros

variables: Add documentation for KERNEL_DTC_FLAGS

kernel-devicetree: Introduce KERNEL_DTC_FLAGS to pass dtc flags

kernel-fitimage: Don't use unit addresses on FIT

linux-yocto/5.4: update to v5.4.123

linux-yocto/5.4: update to v5.4.120

Revert "busybox: make busybox's syslog.cfg depend on VIRTUAL-RUNTIME_base-utils-syslog"

linux-firmware: upgrade 20210315 -> 20210511

pkgconfig: update SRC_URI

oeqa/runtime/rpm: Drop log message counting test component

image-live.bbclass: order do_bootimg after do_rootfs

package_rpm: pass XZ_THREADS to rpm

unfs3: correct configure option

initramfs-framework:rootfs: fix wrong indentions

kernel-fitimage.bbclass: fix a wrong conditional check

lib/oe/gpg_sign.py: Fix gpg verification

sstate: Ignore sstate signing key

glibc: Add 8GB VM usage cap for usermode test suite

libxml2: Add bash dependency for ptests.

libxml2: Reformat runtest.patch

linux-yocto/5.4: update to v5.4.119

linux-yocto/5.4: update to v5.4.118

linux-yocto/5.4: update to v5.4.117

kernel-yocto: provide debug / summary information for metadata

busybox: make busybox's syslog.cfg depend on VIRTUAL-RUNTIME_base-utils-syslog

cve-extra-exclusions.inc: Clean up merged CPE updates

cve-extra-exclusions: Fix typos


Re: Would COMPATIBLE_IMAGE make sense?

Jonas Vautherin
 

Thanks a lot for the answers, that's really helpful!

Seems like I should have a closer look at the distros.
I'll need some time to test it, I'll update here when that is done!

On Tue, Jun 29, 2021 at 1:52 PM Bruce Ashfield <bruce.ashfield@...> wrote:
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




Re: [meta-rockchip][PATCH 3/3] wic/wks cleanup

Trevor Woerner
 

On Mon 2021-06-28 @ 11:15:41 AM, Trevor Woerner wrote:
By exporting a couple more variables the wks file for every rockchip device
can be built from one template instead of having separate wks files for each
board and platform.

The following BSP variables were checked before and after this change to make
sure they remained valid/sensible:
- WKS_FILE
- UBOOT_SUFFIX
- SPL_BINARY
- IMAGE_FSTYPES

Built-tested for every MACHINE in this BSP.

Run-tested on the following devices to ensure they continue to boot correctly
to a cmdline (core-image-base):
- tinker-board
- rock-pi-e
- rock-pi-4b
- rock64
- nanopi-m4-2gb

Signed-off-by: Trevor Woerner <twoerner@...>
---
conf/machine/firefly-rk3288.conf | 2 --
conf/machine/include/nanopi-m4.inc | 1 -
conf/machine/include/rk3288.inc | 3 +--
conf/machine/include/rk3328.inc | 1 -
conf/machine/include/rk3399.inc | 2 --
conf/machine/include/rock-pi-4.inc | 1 -
conf/machine/include/rockchip-wic.inc | 5 +++++
conf/machine/include/tinker.inc | 2 --
conf/machine/rock-pi-e.conf | 2 --
conf/machine/rock64.conf | 2 --
conf/machine/vyasa-rk3288.conf | 1 -
wic/firefly-rk3288.wks | 7 -------
wic/rk3288-boot.wks | 24 ------------------------
wic/rk3399-boot.wks | 24 ------------------------
wic/rock-pi-4.wks | 7 -------
wic/rock-pi-e.wks | 4 ----
wic/{rk3328-boot.wks => rockchip.wks} | 9 ++++++---
wic/tinker-board.wks | 8 --------
wic/vyasa-rk3288.wks | 8 --------
19 files changed, 12 insertions(+), 101 deletions(-)
delete mode 100644 wic/firefly-rk3288.wks
delete mode 100644 wic/rk3288-boot.wks
delete mode 100644 wic/rk3399-boot.wks
delete mode 100644 wic/rock-pi-4.wks
delete mode 100644 wic/rock-pi-e.wks
rename wic/{rk3328-boot.wks => rockchip.wks} (64%)
delete mode 100644 wic/tinker-board.wks
delete mode 100644 wic/vyasa-rk3288.wks

diff --git a/conf/machine/firefly-rk3288.conf b/conf/machine/firefly-rk3288.conf
index 138e840..3270bb9 100644
Applied to meta-rockchip master.


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

3781 - 3800 of 57772