Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

[Alexander Kanavin]

Actually, I think this was some kind of missed PR opportunity. Regular
distros, such as RHEL, Debian and everyone else, are constantly trotting
out their support windows as the reason to hand them the job of making
products, so we could counter that better perhaps.

Alex

On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker <
michael.opdenac...@bootlin.com> wrote:

>
> On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
> > I received the answer to this question in IRC on 10/29/2021.
> >
> > 16:06
> >  > 
> > I saw a wiki edit that said dunfell's LTS period is now through April
> > 2024, but I've seen no announcements. Any truth to this rumor?
> > 16:20
> >  > 
> > jatedev: it was announced on one of the technical calls a few weeks
> > back, so yes AFAIK
> > 16:25
> >  
> > jatedev: definitely true. I wish we could sort out the project
> > advocacy side of things :(
> >
> > Let this email serve as a little advocacy.
>
>
> I believe this would also help if the website (releases page) and/or
> official documentation carried such information.
> Thanks for raising this concern!
> Cheers
> Michael.
>
> --
> Michael Opdenacker, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160561): 
https://lists.openembedded.org/g/openembedded-core/message/160561
Mute This Topic: https://lists.openembedded.org/mt/88415300/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/1] wic: support 512 byte size granularity

[Richard Purdie]

On Fri, 2022-01-14 at 00:25 +0200, Igor Opaniuk wrote:
> Since 938595d1dc("wic: Add 512 Byte alignment to --offset") wic
> parser supports "s"/"S" suffixes, that can be used to align partition
> on 512 byte boundary. Nevertheless, the minimum value of size is still
> 1Kb.
> 
> Introduce support for "s"/"S" suffixes for --size/--fixes-size.
> This is required for some SoCs (like i.MX8M/MM, where SIT image is
> stored on 0x8200, and actual boot image is at 0x8400).
> 
> Signed-off-by: Igor Opaniuk 
> ---
>  meta/lib/oeqa/selftest/cases/wic.py  | 11 +++
>  scripts/lib/wic/ksparser.py  | 19 +++
>  scripts/lib/wic/plugins/imager/direct.py |  6 +++---
>  3 files changed, 21 insertions(+), 15 deletions(-)

Should there be some tests added to "oe-selftest -r wic" for this?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160560): 
https://lists.openembedded.org/g/openembedded-core/message/160560
Mute This Topic: https://lists.openembedded.org/mt/88408509/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 0/4] Move crate fetcher to OE_IMPORTS

[Matt Madison]

On Tue, Dec 21, 2021 at 10:15 AM Matt Madison via
lists.openembedded.org 
wrote:
>
> On Tue, Dec 21, 2021 at 6:07 AM Paul Barker  wrote:
> >
> > On 20/12/2021 22:34, Richard Purdie wrote:
> > > On Mon, 2021-12-20 at 17:01 +, Paul Barker wrote:
> > >> On 17/12/2021 15:36, Matt Madison wrote:
> > >>> This patch series switches to using the OE_IMPORTS mechanism
> > >>> for installing the crate fetcher. This simplifies the addition
> > >>> and clears up issues with interactions between SRCPV and
> > >>> the shared-state fetching logic.
> > >>>
> > >>> Matt Madison (4):
> > >>> lib/crate.py: install crate fetcher on import
> > >>> base.bbclass: add crate to OE_IMPORTS
> > >>> cargo_common.bbclass: remove inherit of crate-fetch
> > >>> classes: remove crate-fetch.bbclass
> > >>>
> > >>>meta/classes/base.bbclass |  2 +-
> > >>>meta/classes/cargo_common.bbclass |  2 --
> > >>>meta/classes/crate-fetch.bbclass  | 28 
> > >>>meta/lib/crate.py |  2 ++
> > >>>4 files changed, 3 insertions(+), 31 deletions(-)
> > >>>delete mode 100644 meta/classes/crate-fetch.bbclass
> > >>>
> > >>
> > >> Would a better solution here be to move the crate fetcher into
> > >> lib/bb/fetch2/ in bitbake?
> > >
> > > I've been wondering about this too.
> > >
> > > Does anyone remember how the fetcher lines up against the general fetcher
> > > requirements we have and is there a list of anything that remained to be 
> > > done
> > > before it could be added to bitbake?
> >
> > If I remember correctly, it just needed some test cases writing. The
> > crate fetcher is a subclass of the wget fetcher with changes to how
> > urldata is set up and how unpack is handled, so it should integrate well
> > into bitbake.
>
> One thing I see that's a bit worrisome is that it disables
> recommends_checksum for the downloaded files,
> and populates metadata for use (I assume) by cargo with the calculated
> SHA256 on the download.

Any other thoughts on this?  I've modified my distro to work around
the problem that led me to propose these patches, but something needs
to be fixed here. crate-fetch.bbclass should not be setting SRCPV.

Thanks,
-Matt

>
> -Matt
>
> >
> > Thanks,
> >
> > --
> > Paul Barker
> > Principal Software Engineer
> > SanCloud Ltd
> >
> > e: paul.bar...@sancloud.com
> > w: https://sancloud.co.uk/
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160562): 
https://lists.openembedded.org/g/openembedded-core/message/160562
Mute This Topic: https://lists.openembedded.org/mt/87791267/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] create-spdx: add support for SDKs

[Saul Wold]

Overall I think this is going in the right direction, I need to review 
it a little deeper and check the actual output.


I am not sure that you tested this against master as you use the old _ 
override syntax vs using a :.


See note below.

Sau!


On 1/12/22 11:40, Andres Beltran wrote:

Signed-off-by: Andres Beltran 
---
  meta/classes/create-spdx.bbclass | 95 +---
  meta/lib/oe/sbom.py  |  6 +-
  2 files changed, 68 insertions(+), 33 deletions(-)

diff --git a/meta/classes/create-spdx.bbclass b/meta/classes/create-spdx.bbclass
index e44a204a8fc..d0f987315ee 100644
--- a/meta/classes/create-spdx.bbclass
+++ b/meta/classes/create-spdx.bbclass
@@ -556,7 +556,7 @@ python do_create_spdx() {
  oe.sbom.write_doc(d, package_doc, "packages")
  }
  # NOTE: depending on do_unpack is a hack that is necessary to get it's 
dependencies for archive the source
-addtask do_create_spdx after do_package do_packagedata do_unpack before 
do_build do_rm_work
+addtask do_create_spdx after do_package do_packagedata do_unpack before 
do_populate_sdk do_build do_rm_work
  
  SSTATETASKS += "do_create_spdx"

  do_create_spdx[sstate-inputdirs] = "${SPDXDEPLOY}"
@@ -788,28 +788,77 @@ def spdx_get_src(d):
  do_rootfs[recrdeptask] += "do_create_spdx do_create_runtime_spdx"
  
  ROOTFS_POSTUNINSTALL_COMMAND =+ "image_combine_spdx ; "

+
+do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"
+POPULATE_SDK_POST_HOST_COMMAND_append_task-populate-sdk = " sdk_host_combine_spdx; 
"
+POPULATE_SDK_POST_TARGET_COMMAND_append_task-populate-sdk = " 
sdk_target_combine_spdx; > +

You using the older _append syntax vs newer :append syntax in master



  python image_combine_spdx() {
+import os
+import oe.sbom
+from pathlib import Path
+from oe.rootfs import image_list_installed_packages
+
+image_name = d.getVar("IMAGE_NAME")
+image_link_name = d.getVar("IMAGE_LINK_NAME")
+imgdeploydir = Path(d.getVar("IMGDEPLOYDIR"))
+img_spdxid = oe.sbom.get_image_spdxid(image_name)
+packages = image_list_installed_packages(d)
+
+combine_spdx(d, image_name, imgdeploydir, img_spdxid, packages)
+
+if image_link_name:
+image_spdx_path = imgdeploydir / (image_name + ".spdx.json")
+image_spdx_link = imgdeploydir / (image_link_name + ".spdx.json")
+image_spdx_link.symlink_to(os.path.relpath(image_spdx_path, 
image_spdx_link.parent))
+
+def make_image_link(target_path, suffix):
+if image_link_name:
+link = imgdeploydir / (image_link_name + suffix)
+link.symlink_to(os.path.relpath(target_path, link.parent))
+
+spdx_tar_path = imgdeploydir / (image_name + ".spdx.tar.zst")
+make_image_link(spdx_tar_path, ".spdx.tar.zst")
+spdx_index_path = imgdeploydir / (image_name + ".spdx.index.json")
+make_image_link(spdx_index_path, ".spdx.index.json")
+}
+
+python sdk_host_combine_spdx() {
+sdk_combine_spdx(d, "host")
+}
+
+python sdk_target_combine_spdx() {
+sdk_combine_spdx(d, "target")
+}
+
+def sdk_combine_spdx(d, sdk_type):
+import oe.sbom
+from pathlib import Path
+from oe.sdk import sdk_list_installed_packages
+
+sdk_name = d.getVar("SDK_NAME") + "-" + sdk_type
+sdk_deploydir = Path(d.getVar("SDKDEPLOYDIR"))
+sdk_spdxid = oe.sbom.get_sdk_spdxid(sdk_name)
+sdk_packages = sdk_list_installed_packages(d, sdk_type == "target")
+combine_spdx(d, sdk_name, sdk_deploydir, sdk_spdxid, sdk_packages)
+
+def combine_spdx(d, rootfs_name, rootfs_deploydir, rootfs_spdxid, packages):
  import os
  import oe.spdx
  import oe.sbom
  import io
  import json
-from oe.rootfs import image_list_installed_packages
  from datetime import timezone, datetime
  from pathlib import Path
  import tarfile
  import bb.compress.zstd
  
  creation_time = datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")

-image_name = d.getVar("IMAGE_NAME")
-image_link_name = d.getVar("IMAGE_LINK_NAME")
-
  deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
-imgdeploydir = Path(d.getVar("IMGDEPLOYDIR"))
  source_date_epoch = d.getVar("SOURCE_DATE_EPOCH")
  
  doc = oe.spdx.SPDXDocument()

-doc.name = image_name
+doc.name = rootfs_name
  doc.documentNamespace = get_doc_namespace(d, doc)
  doc.creationInfo.created = creation_time
  doc.creationInfo.comment = "This document was created by analyzing the source 
of the Yocto recipe during the build."
@@ -821,14 +870,12 @@ python image_combine_spdx() {
  image = oe.spdx.SPDXPackage()
  image.name = d.getVar("PN")
  image.versionInfo = d.getVar("PV")
-image.SPDXID = oe.sbom.get_image_spdxid(image_name)
+image.SPDXID = rootfs_spdxid
  
  doc.packages.append(image)
  
  spdx_package = oe.spdx.SPDXPackage()
  
-packages = image_list_installed_packages(d)

-
  for name in sorted(packages.keys()):
  pkg_spdx_path = 

[OE-core] [PATCH 0/6] kernel: consolidated pull request

[Bruce Ashfield]

From: Bruce Ashfield 

Richard,

Here's the latest round of configuration, CVE, warning and -stable
fixes against the active kernels.

I've also included the lttng-modules fix again, since it supports the
5.16 work that is underway.

Bruce

The following changes since commit f9f3e1bd3e1144f237598c6e20874bc621de6190:

  go: fix building without SECURITY_LDFLAGS (2022-01-14 09:25:31 +)

are available in the Git repository at:

  git://git.yoctoproject.org/poky-contrib zedd/kernel
  http://git.yoctoproject.org/cgit.cgi/poky-contrib/log/?h=zedd/kernel

Bruce Ashfield (6):
  lttng-modules: update to 2.13.1
  linux-yocto/5.15: fix arm defconfig warnings
  linux-yocto/5.10: amdgpu: updates for CVE-2021-42327
  linux-yocto/5.15: update to v5.15.14
  linux-yocto/5.10: update to v5.10.91
  linux-yocto-rt/5.15: update to -rt22

 .../linux/linux-yocto-rt_5.10.bb  |   6 +-
 .../linux/linux-yocto-rt_5.15.bb  |   6 +-
 .../linux/linux-yocto-tiny_5.10.bb|   8 +-
 .../linux/linux-yocto-tiny_5.15.bb|   8 +-
 meta/recipes-kernel/linux/linux-yocto_5.10.bb |  24 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |  26 +-
 ...Remove-deprecated-CPU-hotplug-functi.patch | 394 -
 ...ile-Enable-Wimplicit-fallthrough-for.patch | 829 --
 ...ules_2.13.0.bb => lttng-modules_2.13.1.bb} |   4 +-
 9 files changed, 40 insertions(+), 1265 deletions(-)
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-cpu-hotplug-Remove-deprecated-CPU-hotplug-functi.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-Revert-Makefile-Enable-Wimplicit-fallthrough-for.patch
 rename meta/recipes-kernel/lttng/{lttng-modules_2.13.0.bb => 
lttng-modules_2.13.1.bb} (86%)

-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160584): 
https://lists.openembedded.org/g/openembedded-core/message/160584
Mute This Topic: https://lists.openembedded.org/mt/88427394/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 3/6] linux-yocto/5.10: amdgpu: updates for CVE-2021-42327

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.10:

fd84b99a8ccb drm/amd/display: Don't allow partial copy_from_user
024f4ff63d55 drm/amdgpu: Fix even more out of bound writes from debugfs

Signed-off-by: Paul Gortmaker 
Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.10.bb  |  4 ++--
 .../linux/linux-yocto-tiny_5.10.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 22 +--
 3 files changed, 16 insertions(+), 16 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 52ba3b9f61..75beee3a04 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,8 +11,8 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "e137d5d92c05530840f2e191ec471f8f0ea2d62e"
-SRCREV_meta ?= "65d66ac9789372923b42be0683a87955e52705a5"
+SRCREV_machine ?= "fbed4064df813f01c1a862548f28b2050ee9b09e"
+SRCREV_meta ?= "ad119826536616f28e4309e825b61e16357f4c7e"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}"
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index d0166f6c4f..c8787085fe 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -15,9 +15,9 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "c0774ebd6bc1c7541deb4f9a649a1a6bfa42853f"
-SRCREV_machine ?= "ab201bf6e3f9d187c7c26a0ec6537fadb41de918"
-SRCREV_meta ?= "65d66ac9789372923b42be0683a87955e52705a5"
+SRCREV_machine:qemuarm ?= "ca2928bf9b108b45a8ecfe6c76ae9d66b9527f0c"
+SRCREV_machine ?= "5d7922b2755129e1066944a25675a4f9bdbbe706"
+SRCREV_meta ?= "ad119826536616f28e4309e825b61e16357f4c7e"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index 43274a318f..9bc6511ec2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -13,17 +13,17 @@ KBRANCH:qemux86  ?= "v5.10/standard/base"
 KBRANCH:qemux86-64 ?= "v5.10/standard/base"
 KBRANCH:qemumips64 ?= "v5.10/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "d9597fe71e155c5a96452d23694188d6d4091673"
-SRCREV_machine:qemuarm64 ?= "210fcd9ee603afb731beaa5833e7e3f1d1918786"
-SRCREV_machine:qemumips ?= "8688d3707cea38bd7ed115a12005079c2215f77d"
-SRCREV_machine:qemuppc ?= "933b47667b7549bb36a809cca90bc372a7182620"
-SRCREV_machine:qemuriscv64 ?= "2a2f4a19d9d77ad40b9d079be860f736846f5d55"
-SRCREV_machine:qemuriscv32 ?= "2a2f4a19d9d77ad40b9d079be860f736846f5d55"
-SRCREV_machine:qemux86 ?= "2a2f4a19d9d77ad40b9d079be860f736846f5d55"
-SRCREV_machine:qemux86-64 ?= "2a2f4a19d9d77ad40b9d079be860f736846f5d55"
-SRCREV_machine:qemumips64 ?= "25fcfe4f5c4be9bbb67498f09b2dd088f8bb6dfd"
-SRCREV_machine ?= "2a2f4a19d9d77ad40b9d079be860f736846f5d55"
-SRCREV_meta ?= "65d66ac9789372923b42be0683a87955e52705a5"
+SRCREV_machine:qemuarm ?= "dbf49e7b0801b1b92994f7bc3c6bba943340e273"
+SRCREV_machine:qemuarm64 ?= "0b092f0c4e3471ef22aef0343477519b0ba8b533"
+SRCREV_machine:qemumips ?= "1806335706c3549985836385bb400c1d80819d73"
+SRCREV_machine:qemuppc ?= "270ee670f95ad200c7c32bf8a8ffbf6ed43d7964"
+SRCREV_machine:qemuriscv64 ?= "fd84b99a8ccbfae11300c3a72183616bc0560870"
+SRCREV_machine:qemuriscv32 ?= "fd84b99a8ccbfae11300c3a72183616bc0560870"
+SRCREV_machine:qemux86 ?= "fd84b99a8ccbfae11300c3a72183616bc0560870"
+SRCREV_machine:qemux86-64 ?= "fd84b99a8ccbfae11300c3a72183616bc0560870"
+SRCREV_machine:qemumips64 ?= "ea456bce3f1ed65b1ab00a0cf8cf551b5967aec3"
+SRCREV_machine ?= "fd84b99a8ccbfae11300c3a72183616bc0560870"
+SRCREV_meta ?= "ad119826536616f28e4309e825b61e16357f4c7e"
 
 # remap qemuarm to qemuarma15 for the 5.8 kernel
 # KMACHINE:qemuarm ?= "qemuarma15"
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160587): 
https://lists.openembedded.org/g/openembedded-core/message/160587
Mute This Topic: https://lists.openembedded.org/mt/88427399/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 2/6] linux-yocto/5.15: fix arm defconfig warnings

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto/5.15:

02bf23d26bc4 arm64: defconfig: cleanup config options
05914e2c87e5 arm: defconfig: drop unused POWER_AVS option

Signed-off-by: Ross Burton 
Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.15.bb  |  2 +-
 .../linux/linux-yocto-tiny_5.15.bb|  4 ++--
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 20 +--
 3 files changed, 13 insertions(+), 13 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index f114e0ad4e..0a905d0bff 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "4cf3777087098d1900d7b10f9fa902374e147243"
+SRCREV_machine ?= "04a95b0307715d513560636c2bef4238dde56c86"
 SRCREV_meta ?= "9855687d0262b744ef201fc6e019c659033b83b2"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 1c41406f52..bee98d87cf 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -15,8 +15,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine:qemuarm ?= "d6eeaf39f3beb483733ff2970c901a94093d0b7d"
-SRCREV_machine ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
+SRCREV_machine:qemuarm ?= "149aa4e4f2f3c704e11fd379be32746ab2d3433f"
+SRCREV_machine ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
 SRCREV_meta ?= "9855687d0262b744ef201fc6e019c659033b83b2"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index b6f2fc3b4f..2e093357cb 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -13,16 +13,16 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "aa48e73490dacca52a99928456050476765b56a7"
-SRCREV_machine:qemuarm64 ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemumips ?= "b15f476dfd5edc44300279429b7de25ec899c2a6"
-SRCREV_machine:qemuppc ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemuriscv64 ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemuriscv32 ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemux86 ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemux86-64 ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
-SRCREV_machine:qemumips64 ?= "e146f932b0ae0c3f764745df1c80aafa0136f276"
-SRCREV_machine ?= "b5879e67153e83a5884bbfa32346dc33d96921e7"
+SRCREV_machine:qemuarm ?= "49cda4a3872929491dbcc3793afbd01709555315"
+SRCREV_machine:qemuarm64 ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemumips ?= "049f989b96848df48c445c2b83c634cc5d692032"
+SRCREV_machine:qemuppc ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemuriscv64 ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemuriscv32 ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemux86 ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemux86-64 ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
+SRCREV_machine:qemumips64 ?= "27a47d7d5d6e7bbe8267f32f8089e395e0eaa863"
+SRCREV_machine ?= "02bf23d26bc4c2e6859aa3810df8d6b955488a06"
 SRCREV_meta ?= "9855687d0262b744ef201fc6e019c659033b83b2"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160586): 
https://lists.openembedded.org/g/openembedded-core/message/160586
Mute This Topic: https://lists.openembedded.org/mt/88427398/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH 1/6] lttng-modules: update to 2.13.1

[Bruce Ashfield]

From: Bruce Ashfield 

Bumping lttng-modules to 2.13.1, which fixes the build against 5.16+
kernels.

We drop two previously backported patches.

The following commits are part of this update:

  8c0aec7e Version 2.13.1
  533556cd fix: mm: move kvmalloc-related functions to slab.h (v5.16)
  2f0087ab fix: block: don't call blk_status_to_errno in blk_update_request 
(v5.16)
  9b092ff2 fix: KVM: MMU: change tracepoints arguments to kvm_page_fault (v5.16)
  036297af fix: KVM: x86: Get exit_reason as part of kvm_x86_ops.get_exit_info 
(v5.16)
  a029f2a3 fix: isystem: delete global -isystem compile option (v5.16)
  d82de6f3 fix: block: move block-related definitions out of fs.h (v5.16)
  4fabf854 Fix: syscall tracing: missing trigger actions
  38b35aff Warn on event registration/unregistration failure
  e26f740b fix: implicit-int error in EXPORT_SYMBOL_GPL
  c570be0d fix: Revert "Makefile: Enable -Wimplicit-fallthrough for Clang" 
(v5.15)
  8be4c8a3 fix: cpu/hotplug: Remove deprecated CPU-hotplug functions. (v5.15)

Signed-off-by: Bruce Ashfield 
---
 ...Remove-deprecated-CPU-hotplug-functi.patch | 394 -
 ...ile-Enable-Wimplicit-fallthrough-for.patch | 829 --
 ...ules_2.13.0.bb => lttng-modules_2.13.1.bb} |   4 +-
 3 files changed, 1 insertion(+), 1226 deletions(-)
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0001-fix-cpu-hotplug-Remove-deprecated-CPU-hotplug-functi.patch
 delete mode 100644 
meta/recipes-kernel/lttng/lttng-modules/0002-fix-Revert-Makefile-Enable-Wimplicit-fallthrough-for.patch
 rename meta/recipes-kernel/lttng/{lttng-modules_2.13.0.bb => 
lttng-modules_2.13.1.bb} (86%)

diff --git 
a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-cpu-hotplug-Remove-deprecated-CPU-hotplug-functi.patch
 
b/meta/recipes-kernel/lttng/lttng-modules/0001-fix-cpu-hotplug-Remove-deprecated-CPU-hotplug-functi.patch
deleted file mode 100644
index 08ad2ddaa8..00
--- 
a/meta/recipes-kernel/lttng/lttng-modules/0001-fix-cpu-hotplug-Remove-deprecated-CPU-hotplug-functi.patch
+++ /dev/null
@@ -1,394 +0,0 @@
-From 8be4c8a38ee1e297578e094a6e4c143ec5259aba Mon Sep 17 00:00:00 2001
-From: Michael Jeanson 
-Date: Mon, 13 Sep 2021 12:00:38 -0400
-Subject: [PATCH 1/2] fix: cpu/hotplug: Remove deprecated CPU-hotplug
- functions. (v5.15)
-
-The CPU-hotplug functions get|put_online_cpus() were deprecated in v4.13
-and removed in v5.15.
-
-See upstream commits :
-
-commit 8c854303ce0e38e5bbedd725ff39da7e235865d8
-Author: Sebastian Andrzej Siewior 
-Date:   Tue Aug 3 16:16:21 2021 +0200
-
-cpu/hotplug: Remove deprecated CPU-hotplug functions.
-
-No users in tree use the deprecated CPU-hotplug functions anymore.
-
-Remove them.
-
-Introduced in v4.13 :
-
-  commit 8f553c498e1772cccb39a114da4a498d22992758
-  Author: Thomas Gleixner 
-  Date:   Wed May 24 10:15:12 2017 +0200
-
-cpu/hotplug: Provide cpus_read|write_[un]lock()
-
-The counting 'rwsem' hackery of get|put_online_cpus() is going to be
-replaced by percpu rwsem.
-
-Rename the functions to make it clear that it's locking and not some
-refcount style interface. These new functions will be used for the
-preparatory patches which make the code ready for the percpu rwsem
-conversion.
-
-Rename all instances in the cpu hotplug code while at it.
-
-Upstream-Status: Backport 
[https://git.lttng.org/?p=lttng-modules.git;a=commit;h=ffcc873470121ef1ebb110df3d9038a38d9cb7cb]
-
-Change-Id: I5a37cf5afc075a402b7347989fac637dfa60a1ed
-Signed-off-by: Michael Jeanson 
-Signed-off-by: Mathieu Desnoyers 

- include/wrapper/cpu.h | 44 +++
- src/lib/ringbuffer/ring_buffer_backend.c  |  8 ++---
- src/lib/ringbuffer/ring_buffer_frontend.c | 17 -
- src/lib/ringbuffer/ring_buffer_iterator.c | 15 
- src/lttng-context-perf-counters.c | 11 +++---
- src/lttng-statedump-impl.c|  6 ++--
- 6 files changed, 74 insertions(+), 27 deletions(-)
- create mode 100644 include/wrapper/cpu.h
-
-diff --git a/include/wrapper/cpu.h b/include/wrapper/cpu.h
-new file mode 100644
-index ..cbee1962
 /dev/null
-+++ b/include/wrapper/cpu.h
-@@ -0,0 +1,44 @@
-+/* SPDX-License-Identifier: (GPL-2.0-only or LGPL-2.1-only)
-+ *
-+ * wrapper/cpu.h
-+ *
-+ * Copyright (C) 2021 Michael Jeanson 
-+ */
-+
-+#ifndef _LTTNG_WRAPPER_CPU_H
-+#define _LTTNG_WRAPPER_CPU_H
-+
-+#include 
-+#include 
-+
-+#if (LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(4,13,0))
-+
-+static inline
-+void lttng_cpus_read_lock(void)
-+{
-+  cpus_read_lock();
-+}
-+
-+static inline
-+void lttng_cpus_read_unlock(void)
-+{
-+  cpus_read_unlock();
-+}
-+
-+#else /* LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(4,13,0) */
-+
-+static inline
-+void lttng_cpus_read_lock(void)
-+{
-+  get_online_cpus();
-+}
-+
-+static inline
-+void lttng_cpus_read_unlock(void)
-+{
-+  put_online_cpus();
-+}
-+
-+#endif /* LTTNG_LINUX_VERSION_CODE >= LTTNG_KERNEL_VERSION(4,13,0) */

[OE-core] [PATCH 4/6] linux-yocto/5.15: update to v5.15.14

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

d114b082bef7 Linux 5.15.14
b8a1293e3850 drm/amd/pm: keep the BACO feature enabled for suspend
19070d812e13 Revert "drm/amdgpu: stop scheduler when calling hw_fini (v2)"
b228924bb619 Input: zinitix - make sure the IRQ is allocated before it gets 
enabled
1917ace18375 ARM: dts: gpio-ranges property is now required
2f66e0976b4a userfaultfd/selftests: fix hugetlb area allocations
ec33da9ae072 ipv6: raw: check passed optlen before reading
04d945934362 drm/amd/display: Added power down for DCN10
9b1df8dab312 drm/amd/display: fix B0 TMDS deepcolor no dislay issue
9964f0840a82 mISDN: change function names to avoid conflicts
f55383e6b92b drm/amdgpu: put SMU into proper state on runpm suspending for 
BOCO capable platform
3c196f05 drm/amdgpu: always reset the asic in suspend (v2)
fbabb82b11b4 drm/amd/pm: skip setting gfx cgpg in the s0ix suspend-resume
80f229009b59 atlantic: Fix buff_ring OOB in aq_ring_rx_clean
cf8f0e76c4ce net: udp: fix alignment problem in udp4_seq_show()
294f3fc9dc27 ip6_vti: initialize __ip6_tnl_parm struct in 
vti6_siocdevprivate
847050d40dc0 scsi: libiscsi: Fix UAF in 
iscsi_conn_get_param()/iscsi_conn_teardown()
6ebb6853108f usb: mtu3: fix interval value for intr and isoc
12a4c1092ae7 drm/amd/pm: Fix xgmi link control on aldebaran
31d95ff41cdf drm/amdgpu: fix dropped backing store handling in 
amdgpu_dma_buf_move_notify
4ed66cdc542f auxdisplay: charlcd: checking for pointer reference before 
dereferencing
8a7520c49994 ipv6: Do cleanup if attribute validation fails in multipath 
route
c1de618c95e9 ipv6: Continue processing multipath route even if gateway 
attribute is invalid
5aec746bf7f2 power: bq25890: Enable continuous conversion for ADC at 
charging
b4391e49ac1d drm/amdgpu: disable runpm if we are the primary adapter
fa3d8456f7cd fbdev: fbmem: add a helper to determine if an aperture is used 
by a fw fb
9ca97a693aa8 phonet: refcount leak in pep_sock_accep
d57da5185def net ticp:fix a kernel-infoleak in __tipc_sendmsg()
75d840c0f5d7 gpio: gpio-aspeed-sgpio: Fix wrong hwirq base in irq handler
7601a265696c rndis_host: support Hytera digital radios
b381e0f98711 reset: renesas: Fix Runtime PM usage
550acd770f9f power: reset: ltc2952: Fix use of floating point literals
be816676f38b power: supply: core: Break capacity loop
b0e72ba9e520 xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like 
fallocate
800f02fa8a51 i2c: mpc: Avoid out of bounds memory access
e24c6a48c6ea Revert "i2c: core: support bus regulator controlling in 
adapter"
43fa0b3639c5 cgroup: Use open-time cgroup namespace for process migration 
perm checks
50273128d640 cgroup: Allocate cgroup_file_ctx for kernfs_open_file->priv
c6ebc3529884 cgroup: Use open-time credentials for process migraton perm 
checks
247b6244d40e KVM: x86: Check for rmaps allocation
a08275570392 EDAC/i10nm: Release mdev/mbase when failing to detect HBM
3400aa7eda64 md/raid1: fix missing bitmap update w/o WriteMostly devices
15fb002977f6 net: ena: Fix error handling when calculating max IO queues 
number
c4c20dc24e09 net: ena: Fix wrong rx request id by resetting device
bf8263c71420 net: ena: Fix undefined state when tx request id is out of 
bounds
6511f8074b70 sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc
9b8bbe489ced batman-adv: mcast: don't send link-local multicast to mcast 
routers
9f00a2a0c139 sctp: hold endpoint before calling cb in 
sctp_transport_lookup_process
3c5c81d1e350 selftests: net: udpgro_fwd.sh: explicitly checking the 
available ping feature
41844e68eb92 lwtunnel: Validate RTA_ENCAP_TYPE attribute length
ca0097c543fc ipv6: Check attribute length for RTA_GATEWAY when deleting 
multipath route
00e8b9f313b2 ipv6: Check attribute length for RTA_GATEWAY in multipath route
bb471784ca85 ipv4: Check attribute length for RTA_FLOW in multipath route
72971eaad6ea ipv4: Check attribute length for RTA_GATEWAY in multipath route
5cb0bd07125f ftrace/samples: Add missing prototypes direct functions
61169d6c77de i40e: Fix incorrect netdev's real number of RX/TX queues
7b177d34a123 i40e: Fix for displaying message regarding NVM version
3f4c2ade4d65 i40e: fix use-after-free in i40e_sync_filters_subtask()
8fbbc33cf018 sfc: The RX page_ring is optional
03fb6db4ad61 mac80211: mesh: embedd mesh_paths and mpp_paths into 
ieee80211_if_mesh
18b224910edc mac80211: initialize variable have_higher_than_11mbit
0ea8bb0811ba RDMA/uverbs: Check for null return of kmalloc_array
6716b40d162f netrom: fix copying in user data in nr_setsockopt
21a18420ae2d Revert "net: usb: r8152: Add MAC passthrough support for more 
Lenovo Docks"
e1e354771812 RDMA/core: Don't infoleak GRH fields
  

[OE-core] [PATCH 5/6] linux-yocto/5.10: update to v5.10.91

[Bruce Ashfield]

From: Bruce Ashfield 

Updating linux-yocto/5.10 to the latest korg -stable release that comprises
the following commits:

df395c763ba0 Linux 5.10.91
674071c9eb26 Input: zinitix - make sure the IRQ is allocated before it gets 
enabled
ef81f7d406c2 ARM: dts: gpio-ranges property is now required
f63fa1a0d4df ipv6: raw: check passed optlen before reading
cf07884e6bec drm/amd/display: Added power down for DCN10
10b9ccd0674d mISDN: change function names to avoid conflicts
dd8a09cfbb99 atlantic: Fix buff_ring OOB in aq_ring_rx_clean
c2f4bb251eb4 net: udp: fix alignment problem in udp4_seq_show()
f82b48d1d86b ip6_vti: initialize __ip6_tnl_parm struct in 
vti6_siocdevprivate
8c87a83ef891 scsi: libiscsi: Fix UAF in 
iscsi_conn_get_param()/iscsi_conn_teardown()
b798b677f94d usb: mtu3: fix interval value for intr and isoc
498d77fc5e38 ipv6: Do cleanup if attribute validation fails in multipath 
route
72b0d14a0a88 ipv6: Continue processing multipath route even if gateway 
attribute is invalid
5a7d650bb181 power: bq25890: Enable continuous conversion for ADC at 
charging
4f260ea5537d phonet: refcount leak in pep_sock_accep
61952934608c rndis_host: support Hytera digital radios
62cbde77d9c1 power: reset: ltc2952: Fix use of floating point literals
998d157e3b2a power: supply: core: Break capacity loop
16d8568378f9 xfs: map unwritten blocks in XFS_IOC_{ALLOC,FREE}SP just like 
fallocate
aa606b82cdfb net: ena: Fix error handling when calculating max IO queues 
number
e7f5480978fd net: ena: Fix undefined state when tx request id is out of 
bounds
2de3d961f8e7 sch_qfq: prevent shift-out-of-bounds in qfq_init_qdisc
4c34d5fd8c96 batman-adv: mcast: don't send link-local multicast to mcast 
routers
f403b5f96e9a lwtunnel: Validate RTA_ENCAP_TYPE attribute length
48d5adb08d60 ipv6: Check attribute length for RTA_GATEWAY when deleting 
multipath route
173bfa2782fa ipv6: Check attribute length for RTA_GATEWAY in multipath route
914420a2a6c5 ipv4: Check attribute length for RTA_FLOW in multipath route
a8fe915be6c2 ipv4: Check attribute length for RTA_GATEWAY in multipath route
786a335fef18 ftrace/samples: Add missing prototypes direct functions
c859c4de0bd7 i40e: Fix incorrect netdev's real number of RX/TX queues
d0ad64438fb5 i40e: Fix for displaying message regarding NVM version
32845aa60203 i40e: fix use-after-free in i40e_sync_filters_subtask()
f7edb6b9438b sfc: The RX page_ring is optional
2b3f34da0d79 mac80211: initialize variable have_higher_than_11mbit
16e5cad6eca1 RDMA/uverbs: Check for null return of kmalloc_array
a7c2cae997db netrom: fix copying in user data in nr_setsockopt
beeb0fdedae8 RDMA/core: Don't infoleak GRH fields
3ca132e6b065 iavf: Fix limit of total number of queues to active queues of 
VF
396e3016905d i40e: Fix to not show opcode msg on unsuccessful VF MAC change
7f13d14e563c ieee802154: atusb: fix uninit value in atusb_set_extended_addr
7db1e245cb71 tracing: Tag trace_percpu_buffer as a percpu pointer
760c6a625506 tracing: Fix check for trace_percpu_buffer validity in 
get_trace_buf()
c1e2da4b3f72 selftests: x86: fix [-Wstringop-overread] warn in 
test_process_vm_readv()
384111e12367 f2fs: quota: fix potential deadlock

Signed-off-by: Bruce Ashfield 
---
 .../linux/linux-yocto-rt_5.10.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.10.bb|  8 +++
 meta/recipes-kernel/linux/linux-yocto_5.10.bb | 24 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
index 75beee3a04..420d67031e 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.10.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "fbed4064df813f01c1a862548f28b2050ee9b09e"
-SRCREV_meta ?= "ad119826536616f28e4309e825b61e16357f4c7e"
+SRCREV_machine ?= "85c14e209f1ab7cee673735c4561e656b4e65217"
+SRCREV_meta ?= "de35f8006d0f932924752ddda94dd24e2da67fbc"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.10;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.10.90"
+LINUX_VERSION ?= "5.10.91"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
index c8787085fe..dabcb97a79 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.10.bb
@@ -6,7 +6,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 

[OE-core] [PATCH 6/6] linux-yocto-rt/5.15: update to -rt22

[Bruce Ashfield]

From: Bruce Ashfield 

Integrating the following commit(s) to linux-yocto-rt/5.15:

799919ec2113 v5.15.5-rt22
4745560a36e7 v5.15.3-rt21
9b4d36e0fbeb v5.15.2-rt20
d156320aca54 net: sched: gred: dynamically allocate tc_gred_qopt_offload
d36603e0d213 v5.15.2-rt19
7ddf3a205fa3 mm/vmalloc: Remove unused `cpu' variable.
3f8e7f777049 v5.15.2-rt18
7b0fd383bb9a printk: fixup -stable merge to -rt

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 8659c606a8..4713e45c2f 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,7 +11,7 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "4903bb17bd48345aa95509e33f0d3aabb782f328"
+SRCREV_machine ?= "799919ec2113ffcec02207ea67abdc629f3bbebe"
 SRCREV_meta ?= "72e4eafb6b3c999aefc56e1c1b9dfa0c94ae2fbb"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160590): 
https://lists.openembedded.org/g/openembedded-core/message/160590
Mute This Topic: https://lists.openembedded.org/mt/88427404/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [PATCH] systemtap: fix vsprintf errors

[Ross Burton]

In some configurations (such as 32-bit arm), using printf() causes
gcc errors.  Backport a patch from upstream to fix this.

Signed-off-by: Ross Burton 
---
 ...ing-tweak-for-sprintf-precision-para.patch | 45 +++
 .../systemtap/systemtap_git.inc   |  1 +
 2 files changed, 46 insertions(+)
 create mode 100644 
meta/recipes-kernel/systemtap/systemtap/0001-PR28778-gcc-warning-tweak-for-sprintf-precision-para.patch

diff --git 
a/meta/recipes-kernel/systemtap/systemtap/0001-PR28778-gcc-warning-tweak-for-sprintf-precision-para.patch
 
b/meta/recipes-kernel/systemtap/systemtap/0001-PR28778-gcc-warning-tweak-for-sprintf-precision-para.patch
new file mode 100644
index 000..0801cb57ece
--- /dev/null
+++ 
b/meta/recipes-kernel/systemtap/systemtap/0001-PR28778-gcc-warning-tweak-for-sprintf-precision-para.patch
@@ -0,0 +1,45 @@
+Upstream-Status: Backport
+Signed-off-by: Ross Burton 
+
+From b0422e9e5a539164af75cddcaeb01bceca56bf12 Mon Sep 17 00:00:00 2001
+From: "Frank Ch. Eigler" 
+Date: Thu, 13 Jan 2022 18:33:15 -0500
+Subject: [PATCH] PR28778: gcc warning tweak for sprintf precision parameter
+
+A precision=-1 sentinel value got interpreted as UINT_MAX in a
+context, leading to diagnostics like:
+
+/usr/share/systemtap/runtime/vsprintf.c:341:23: error: 'strnlen' specified 
bound 4294967295 may exceed maximum object size 2147483647 
[-Werror=stringop-overread]
+
+Adding a clamp_t() around the parameter field to keep it limited to
+STP_BUFFER_SIZE (8K by default), which is apprx. the limit for a
+single printf.
+---
+ runtime/vsprintf.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/runtime/vsprintf.c b/runtime/vsprintf.c
+index cd31a938b..606f685e8 100644
+--- a/runtime/vsprintf.c
 b/runtime/vsprintf.c
+@@ -338,7 +338,7 @@ _stp_vsprint_memory(char * str, char * end, const char * 
ptr,
+   if (format == 's') {
+   if ((unsigned long)ptr < PAGE_SIZE)
+   ptr = "";
+-  len = strnlen(ptr, precision);
++  len = strnlen(ptr, clamp_t(size_t, precision, 0, 
STP_BUFFER_SIZE));
+   }
+   else if (precision > 0)
+   len = precision;
+@@ -410,7 +410,7 @@ _stp_vsprint_memory_size(const char * ptr, int width, int 
precision,
+   if (format == 's') {
+   if ((unsigned long)ptr < PAGE_SIZE)
+   ptr = "";
+-  len = strnlen(ptr, precision);
++  len = strnlen(ptr, clamp_t(size_t, precision, 0, 
STP_BUFFER_SIZE));
+   }
+   else if (precision > 0)
+   len = precision;
+-- 
+2.25.1
+
diff --git a/meta/recipes-kernel/systemtap/systemtap_git.inc 
b/meta/recipes-kernel/systemtap/systemtap_git.inc
index 22b07f15165..36c934c2fa7 100644
--- a/meta/recipes-kernel/systemtap/systemtap_git.inc
+++ b/meta/recipes-kernel/systemtap/systemtap_git.inc
@@ -7,6 +7,7 @@ SRC_URI = "git://sourceware.org/git/systemtap.git;branch=master 
\

file://0001-Do-not-let-configure-write-a-python-location-into-th.patch \
file://0001-Install-python-modules-to-correct-library-dir.patch \

file://0001-staprun-stapbpf-don-t-support-installing-a-non-root.patch \
+   
file://0001-PR28778-gcc-warning-tweak-for-sprintf-precision-para.patch \
"
 
 COMPATIBLE_HOST = '(x86_64|i.86|powerpc|arm|aarch64|microblazeel|mips).*-linux'
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160579): 
https://lists.openembedded.org/g/openembedded-core/message/160579
Mute This Topic: https://lists.openembedded.org/mt/88426954/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

[Ross Burton]

On Fri, 14 Jan 2022 at 12:41, Zoltan Boszormenyi via
lists.yoctoproject.org  wrote:
> It would also help if recipes staying on the same version
> but adding patches for e.g. CVE fixes should increase their
> PR value so their rebuilt versions can be put into a package repo.
>
> Throwing away the buildroot (as suggested any time some obscure
> build error happens) and restarting a complete image build
> resets the autopr value so the repo would contain packages with
> the same r0.0 release string and the package manager doesn't know
> that the package is newer.

If you want persistent PRs between builds after deleting the build
tree, simply archive the PR database.

We're not going back to manually updating the PR on changes.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160572): 
https://lists.openembedded.org/g/openembedded-core/message/160572
Mute This Topic: https://lists.openembedded.org/mt/88415300/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott][PATCH 2/8] qemu: fix CVE-2021-3593

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2021-3593.patch | 40 +++
 2 files changed, 41 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 6c00bf274b..6b544a4344 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -73,6 +73,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3592_1.patch \
file://CVE-2021-3592_2.patch \
file://CVE-2021-3592_3.patch \
+   file://CVE-2021-3593.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
new file mode 100644
index 00..dd14c240a8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
@@ -0,0 +1,40 @@
+From fe99634066e1074aaf55e83b576385877d7e4bcc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 16:32:55 +0400
+Subject: [PATCH 04/12] upd6: check udp6_input buffer size
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: CVE-2021-3593
+Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/45
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [de71c15de66ba9350bf62c45b05f8fbff166517b]
+CVE: CVE-2021-3593
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/udp6.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/slirp/src/udp6.c b/slirp/src/udp6.c
+index 6f9486bbc..8c490e4d1 100644
+--- a/slirp/src/udp6.c
 b/slirp/src/udp6.c
+@@ -28,7 +28,10 @@ void udp6_input(struct mbuf *m)
+ ip = mtod(m, struct ip6 *);
+ m->m_len -= iphlen;
+ m->m_data += iphlen;
+-uh = mtod(m, struct udphdr *);
++uh = mtod_check(m, sizeof(struct udphdr));
++if (uh == NULL) {
++goto bad;
++}
+ m->m_len += iphlen;
+ m->m_data -= iphlen;
+ 
+-- 
+2.31.1
+
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160575): 
https://lists.openembedded.org/g/openembedded-core/message/160575
Mute This Topic: https://lists.openembedded.org/mt/88426914/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott][PATCH 1/8] qemu: fix CVE-2021-3592

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |   3 +
 .../qemu/qemu/CVE-2021-3592_1.patch   |  58 ++
 .../qemu/qemu/CVE-2021-3592_2.patch   | 165 ++
 .../qemu/qemu/CVE-2021-3592_3.patch   |  40 +
 4 files changed, 266 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3592_1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3592_2.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3592_3.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 463339e42b..6c00bf274b 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -70,6 +70,9 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3607.patch \
file://CVE-2021-3608.patch \
file://CVE-2021-3682.patch \
+   file://CVE-2021-3592_1.patch \
+   file://CVE-2021-3592_2.patch \
+   file://CVE-2021-3592_3.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_1.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_1.patch
new file mode 100644
index 00..e374959594
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_1.patch
@@ -0,0 +1,58 @@
+From 0123c625aed2ed0679fa8c084104699d918c1da6 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 15:58:25 +0400
+Subject: [PATCH 01/12] Add mtod_check()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Recent security issues demonstrate the lack of safety care when casting
+a mbuf to a particular structure type. At least, it should check that
+the buffer is large enough. The following patches will make use of this
+function.
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [93e645e72a056ec0b2c16e0299fc5c6b94e4ca17]
+CVE: CVE-2021-3592
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/mbuf.c | 11 +++
+ slirp/src/mbuf.h |  1 +
+ 2 files changed, 12 insertions(+)
+
+diff --git a/slirp/src/mbuf.c b/slirp/src/mbuf.c
+index 54ec721eb..cb2e97108 100644
+--- a/slirp/src/mbuf.c
 b/slirp/src/mbuf.c
+@@ -222,3 +222,14 @@ struct mbuf *dtom(Slirp *slirp, void *dat)
+ 
+ return (struct mbuf *)0;
+ }
++
++void *mtod_check(struct mbuf *m, size_t len)
++{
++if (m->m_len >= len) {
++return m->m_data;
++}
++
++DEBUG_ERROR("mtod failed");
++
++return NULL;
++}
+diff --git a/slirp/src/mbuf.h b/slirp/src/mbuf.h
+index 546e7852c..2015e3232 100644
+--- a/slirp/src/mbuf.h
 b/slirp/src/mbuf.h
+@@ -118,6 +118,7 @@ void m_inc(struct mbuf *, int);
+ void m_adj(struct mbuf *, int);
+ int m_copy(struct mbuf *, struct mbuf *, int, int);
+ struct mbuf *dtom(Slirp *, void *);
++void *mtod_check(struct mbuf *, size_t len);
+ 
+ static inline void ifs_init(struct mbuf *ifm)
+ {
+-- 
+2.31.1
+
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_2.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_2.patch
new file mode 100644
index 00..799a95417e
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3592_2.patch
@@ -0,0 +1,165 @@
+From fc2a4797f55016e78f2cde4806b05368fa5b7a97 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 19:25:28 +0400
+Subject: [PATCH 02/12] bootp: limit vendor-specific area to input packet
+ memory buffer
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+sizeof(bootp_t) currently holds DHCP_OPT_LEN. Remove this optional field
+from the structure, to help with the following patch checking for
+minimal header size. Modify the bootp_reply() function to take the
+buffer boundaries and avoiding potential buffer overflow.
+
+Related to CVE-2021-3592.
+
+https://gitlab.freedesktop.org/slirp/libslirp/-/issues/44
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [f13cad45b25d92760bb0ad67bec0300a4d7d5275]
+CVE: CVE-2021-3592
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/bootp.c | 26 +++---
+ slirp/src/bootp.h |  2 +-
+ slirp/src/mbuf.c  |  5 +
+ slirp/src/mbuf.h  |  1 +
+ 4 files changed, 22 insertions(+), 12 deletions(-)
+
+diff --git a/slirp/src/bootp.c b/slirp/src/bootp.c
+index 46e96810a..e0db8d196 100644
+--- a/slirp/src/bootp.c
 b/slirp/src/bootp.c
+@@ -92,21 +92,22 @@ found:
+ return bc;
+ }
+ 
+-static void dhcp_decode(const struct bootp_t *bp, int *pmsg_type,
++static void dhcp_decode(const struct bootp_t *bp,
++const uint8_t *bp_end,
++int *pmsg_type,
+ struct in_addr *preq_addr)
+ {
+-const uint8_t *p, *p_end;
++const uint8_t *p;
+ int len, tag;
+ 
+ *pmsg_type = 0;
+ preq_addr->s_addr = htonl(0L);
+ 
+ p = bp->bp_vend;
+-p_end = p + 

[OE-core] [hardknott][PATCH 4/8] qemu: fix CVE-2021-3594

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  1 +
 .../qemu/qemu/CVE-2021-3594.patch | 40 +++
 2 files changed, 41 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 811bdff426..4198d3a52c 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -76,6 +76,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3593.patch \
file://CVE-2021-3595_1.patch \
file://CVE-2021-3595_2.patch \
+   file://CVE-2021-3594.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch
new file mode 100644
index 00..c99ba7a7cc
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch
@@ -0,0 +1,40 @@
+From 7a5ffd5475f2cbfe3cf91d9584893f1a4b3b4dff Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 16:40:23 +0400
+Subject: [PATCH 07/12] udp: check upd_input buffer size
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: CVE-2021-3594
+Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/47
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [74572be49247c8c5feae7c6e0b50c4f569ca9824]
+CVE: CVE-2021-3594
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/udp.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/slirp/src/udp.c b/slirp/src/udp.c
+index 0ad44d7c0..18b4acdfa 100644
+--- a/slirp/src/udp.c
 b/slirp/src/udp.c
+@@ -93,7 +93,10 @@ void udp_input(register struct mbuf *m, int iphlen)
+ /*
+  * Get IP and UDP header together in first mbuf.
+  */
+-ip = mtod(m, struct ip *);
++ip = mtod_check(m, iphlen + sizeof(struct udphdr));
++if (ip == NULL) {
++goto bad;
++}
+ uh = (struct udphdr *)((char *)ip + iphlen);
+ 
+ /*
+-- 
+2.31.1
+
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160576): 
https://lists.openembedded.org/g/openembedded-core/message/160576
Mute This Topic: https://lists.openembedded.org/mt/88426915/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott][PATCH 6/8] qemu: fix CVE-2021-3748

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |   1 +
 .../qemu/qemu/CVE-2021-3748.patch | 127 ++
 2 files changed, 128 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 970aa96608..7648ce9a38 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -78,6 +78,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3595_2.patch \
file://CVE-2021-3594.patch \
file://CVE-2021-3713.patch \
+   file://CVE-2021-3748.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
new file mode 100644
index 00..4765f24739
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3748.patch
@@ -0,0 +1,127 @@
+From bacc200f623647632258f7efc0f098ac30dd4225 Mon Sep 17 00:00:00 2001
+From: Jason Wang 
+Date: Thu, 2 Sep 2021 13:44:12 +0800
+Subject: [PATCH 09/12] virtio-net: fix use after unmap/free for sg
+
+When mergeable buffer is enabled, we try to set the num_buffers after
+the virtqueue elem has been unmapped. This will lead several issues,
+E.g a use after free when the descriptor has an address which belongs
+to the non direct access region. In this case we use bounce buffer
+that is allocated during address_space_map() and freed during
+address_space_unmap().
+
+Fixing this by storing the elems temporarily in an array and delay the
+unmap after we set the the num_buffers.
+
+This addresses CVE-2021-3748.
+
+Reported-by: Alexander Bulekov 
+Fixes: fbe78f4f55c6 ("virtio-net support")
+Cc: qemu-sta...@nongnu.org
+Signed-off-by: Jason Wang 
+
+Upstream-Status: Backport [bedd7e93d01961fcb16a97ae45d93acf357e11f6]
+CVE: CVE-2021-3748
+
+Signed-off-by: Sakib Sajal 
+---
+ hw/net/virtio-net.c | 39 ---
+ 1 file changed, 32 insertions(+), 7 deletions(-)
+
+diff --git a/hw/net/virtio-net.c b/hw/net/virtio-net.c
+index 9179013ac..df1d30e2c 100644
+--- a/hw/net/virtio-net.c
 b/hw/net/virtio-net.c
+@@ -1665,10 +1665,13 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+ VirtIONet *n = qemu_get_nic_opaque(nc);
+ VirtIONetQueue *q = virtio_net_get_subqueue(nc);
+ VirtIODevice *vdev = VIRTIO_DEVICE(n);
++VirtQueueElement *elems[VIRTQUEUE_MAX_SIZE];
++size_t lens[VIRTQUEUE_MAX_SIZE];
+ struct iovec mhdr_sg[VIRTQUEUE_MAX_SIZE];
+ struct virtio_net_hdr_mrg_rxbuf mhdr;
+ unsigned mhdr_cnt = 0;
+-size_t offset, i, guest_offset;
++size_t offset, i, guest_offset, j;
++ssize_t err;
+ 
+ if (!virtio_net_can_receive(nc)) {
+ return -1;
+@@ -1699,6 +1702,12 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+ 
+ total = 0;
+ 
++if (i == VIRTQUEUE_MAX_SIZE) {
++virtio_error(vdev, "virtio-net unexpected long buffer chain");
++err = size;
++goto err;
++}
++
+ elem = virtqueue_pop(q->rx_vq, sizeof(VirtQueueElement));
+ if (!elem) {
+ if (i) {
+@@ -1710,7 +1719,8 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+  n->guest_hdr_len, n->host_hdr_len,
+  vdev->guest_features);
+ }
+-return -1;
++err = -1;
++goto err;
+ }
+ 
+ if (elem->in_num < 1) {
+@@ -1718,7 +1728,8 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+  "virtio-net receive queue contains no in buffers");
+ virtqueue_detach_element(q->rx_vq, elem, 0);
+ g_free(elem);
+-return -1;
++err = -1;
++goto err;
+ }
+ 
+ sg = elem->in_sg;
+@@ -1755,12 +1766,13 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+ if (!n->mergeable_rx_bufs && offset < size) {
+ virtqueue_unpop(q->rx_vq, elem, total);
+ g_free(elem);
+-return size;
++err = size;
++goto err;
+ }
+ 
+-/* signal other side */
+-virtqueue_fill(q->rx_vq, elem, total, i++);
+-g_free(elem);
++elems[i] = elem;
++lens[i] = total;
++i++;
+ }
+ 
+ if (mhdr_cnt) {
+@@ -1770,10 +1782,23 @@ static ssize_t virtio_net_receive_rcu(NetClientState 
*nc, const uint8_t *buf,
+  _buffers, sizeof mhdr.num_buffers);
+ }
+ 
++for (j = 0; j < i; j++) {
++/* signal other side */
++virtqueue_fill(q->rx_vq, elems[j], lens[j], j);
++g_free(elems[j]);
++}
++
+ 

[OE-core] [hardknott][PATCH 8/8] qemu: fix CVE-2021-20196

[Sakib Sajal]

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/qemu/qemu.inc   |  2 +
 .../qemu/qemu/CVE-2021-20196_1.patch  | 54 +++
 .../qemu/qemu/CVE-2021-20196_2.patch  | 67 +++
 3 files changed, 123 insertions(+)
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-20196_1.patch
 create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-20196_2.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 4a5379893c..3401fd7194 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -80,6 +80,8 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
file://CVE-2021-3713.patch \
file://CVE-2021-3748.patch \
file://CVE-2021-3930.patch \
+   file://CVE-2021-20196_1.patch \
+   file://CVE-2021-20196_2.patch \
"
 UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_1.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_1.patch
new file mode 100644
index 00..8b1ad0423b
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_1.patch
@@ -0,0 +1,54 @@
+From e907ff3d4cb7fd20d402f45355059e67d0dc93e7 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Wed, 24 Nov 2021 17:15:34 +0100
+Subject: [PATCH 11/12] hw/block/fdc: Extract blk_create_empty_drive()
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+We are going to re-use this code in the next commit,
+so extract it as a new blk_create_empty_drive() function.
+
+Inspired-by: Hanna Reitz 
+Signed-off-by: Philippe Mathieu-Daudé 
+Message-id: 20211124161536.631563-2-phi...@redhat.com
+Signed-off-by: John Snow 
+
+Upstream-Status: Backport [b154791e7b6d4ca5cdcd54443484d97360bd7ad2]
+CVE: CVE-2021-20196
+
+Signed-off-by: Sakib Sajal 
+---
+ hw/block/fdc.c | 9 +++--
+ 1 file changed, 7 insertions(+), 2 deletions(-)
+
+diff --git a/hw/block/fdc.c b/hw/block/fdc.c
+index 4c2c35e22..854b4f172 100644
+--- a/hw/block/fdc.c
 b/hw/block/fdc.c
+@@ -61,6 +61,12 @@
+ } while (0)
+ 
+ 
++/* Anonymous BlockBackend for empty drive */
++static BlockBackend *blk_create_empty_drive(void)
++{
++return blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL);
++}
++
+ //
+ /* qdev floppy bus  */
+ 
+@@ -543,8 +549,7 @@ static void floppy_drive_realize(DeviceState *qdev, Error 
**errp)
+ }
+ 
+ if (!dev->conf.blk) {
+-/* Anonymous BlockBackend for an empty drive */
+-dev->conf.blk = blk_new(qemu_get_aio_context(), 0, BLK_PERM_ALL);
++dev->conf.blk = blk_create_empty_drive();
+ ret = blk_attach_dev(dev->conf.blk, qdev);
+ assert(ret == 0);
+ 
+-- 
+2.31.1
+
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_2.patch 
b/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_2.patch
new file mode 100644
index 00..dd442ccb8f
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-20196_2.patch
@@ -0,0 +1,67 @@
+From 1d48445a951fd5504190a38abeda70ea9372cf77 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
+Date: Wed, 24 Nov 2021 17:15:35 +0100
+Subject: [PATCH 12/12] hw/block/fdc: Kludge missing floppy drive to fix
+ CVE-2021-20196
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Guest might select another drive on the bus by setting the
+DRIVE_SEL bit of the DIGITAL OUTPUT REGISTER (DOR).
+The current controller model doesn't expect a BlockBackend
+to be NULL. A simple way to fix CVE-2021-20196 is to create
+an empty BlockBackend when it is missing. All further
+accesses will be safely handled, and the controller state
+machines keep behaving correctly.
+
+Cc: qemu-sta...@nongnu.org
+Fixes: CVE-2021-20196
+Reported-by: Gaoning Pan (Ant Security Light-Year Lab) 
+Reviewed-by: Darren Kenny 
+Reviewed-by: Hanna Reitz 
+Signed-off-by: Philippe Mathieu-Daudé 
+Message-id: 20211124161536.631563-3-phi...@redhat.com
+BugLink: https://bugs.launchpad.net/qemu/+bug/1912780
+Resolves: https://gitlab.com/qemu-project/qemu/-/issues/338
+Reviewed-by: Darren Kenny 
+Reviewed-by: Hanna Reitz 
+Signed-off-by: Philippe Mathieu-Daudé 
+Signed-off-by: John Snow 
+
+Upstream-Status: Backport [1ab95af033a419e7a64e2d58e67dd96b20af5233]
+CVE: CVE-2021-20196
+
+Signed-off-by: Sakib Sajal 
+---
+ hw/block/fdc.c | 14 +-
+ 1 file changed, 13 insertions(+), 1 deletion(-)
+
+diff --git a/hw/block/fdc.c b/hw/block/fdc.c
+index 854b4f172..a736c4d14 100644
+--- a/hw/block/fdc.c
 b/hw/block/fdc.c
+@@ -1365,7 +1365,19 @@ static FDrive *get_drv(FDCtrl *fdctrl, int unit)
+ 
+ static FDrive *get_cur_drv(FDCtrl *fdctrl)
+ {
+-return get_drv(fdctrl, fdctrl->cur_drv);
++FDrive *cur_drv = get_drv(fdctrl, fdctrl->cur_drv);
++

Re: [OE-core][RFC] classes/native: Propagate dependencies to outhash

[Alexander Kanavin]

While we're here, recipes inheriting qemu class should do this too, but for
the target dependencies.

Alex

On Fri, 14 Jan 2022 at 18:50, Jacob Kroon  wrote:

> On 1/14/22 18:12, Joshua Watt wrote:
> > Native task outputs are directly run on the target (host) system after
>
> "target" or "host" ? the latter i suppose
>
> > being built. Even if the output of a native recipe doesn't change, a
> > change in one of its dependencies may cause a change in the output it
> > generates (e.g. rpm output depends on the output of its dependent zstd
> > library).
> >
> > This can cause poor interactions with hash equivalence, since this
> > recipes output-changing dependency is "hidden" and downstream task only
> > see that this recipe has the same outhash and therefore is equivalent.
> > This can result in different output in different cases.
> >
> > To resolve this, unhide the output-changing dependency by adding it's
> > unihash to this tasks outhash calculation. Unfortunately, don't know
> > specifically know which dependencies are output-changing, so we have to
> > add all of them.
> >
>
> "don't know specifically know which.."
>
> > [YOCTO #14685]
> >
> > Signed-off-by: Joshua Watt 
> > ---
> >  meta/classes/native.bbclass | 31 +++
> >  meta/lib/oe/sstatesig.py| 10 +++---
> >  2 files changed, 38 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> > index 76a599bc15..fc7422c5d7 100644
> > --- a/meta/classes/native.bbclass
> > +++ b/meta/classes/native.bbclass
> > @@ -195,3 +195,34 @@ USE_NLS = "no"
> >
> >  RECIPERDEPTASK = "do_populate_sysroot"
> >  do_populate_sysroot[rdeptask] = "${RECIPERDEPTASK}"
> > +
> > +#
> > +# Native task outputs are directly run on the target (host) system
> after being
>
> see above
>
> > +# built. Even if the output of this recipe doesn't change, a change in
> one of
> > +# its dependencies may cause a change in the output it generates (e.g.
> rpm
> > +# output depends on the output of its dependent zstd library).
> > +#
> > +# This can cause poor interactions with hash equivalence, since this
> recipes
> > +# output-changing dependency is "hidden" and downstream task only see
> that this
> > +# recipe has the same outhash and therefore is equivalent. This can
> result in
> > +# different output in different cases.
> > +#
> > +# To resolve this, unhide the output-changing dependency by adding its
> unihash
> > +# to this tasks outhash calculation. Unfortunately, don't know
> specifically
> > +# know which dependencies are output-changing, so we have to add all of
> them.
> > +#
>
> see above
>
> > +python native_add_do_populate_sysroot_deps () {
> > +current_task = "do_" + d.getVar("BB_CURRENTTASK")
> > +if current_task != "do_populate_sysroot":
> > +return
> > +
> > +taskdepdata = d.getVar("BB_TASKDEPDATA", False)
> > +pn = d.getVar("PN")
> > +deps = {
> > +dep[0]:dep[6] for dep in taskdepdata.values() if
> > +dep[1] == current_task and dep[0] != pn
> > +}
> > +
> > +d.setVar("HASHEQUIV_EXTRA_SIGDATA", "\n".join("%s: %s" % (k,
> deps[k]) for k in sorted(deps.keys(
> > +}
> > +SSTATECREATEFUNCS += "native_add_do_populate_sysroot_deps"
> > diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> > index 038404e377..abcd96231e 100644
> > --- a/meta/lib/oe/sstatesig.py
> > +++ b/meta/lib/oe/sstatesig.py
> > @@ -491,7 +491,8 @@ def OEOuthashBasic(path, sigfile, task, d):
> >  if task == "package":
> >  include_timestamps = True
> >  include_root = False
> > -extra_content = d.getVar('HASHEQUIV_HASH_VERSION')
> > +hash_version = d.getVar('HASHEQUIV_HASH_VERSION')
> > +extra_sigdata = d.getVar("HASHEQUIV_EXTRA_SIGDATA")
> >
> >  filemaps = {}
> >  for m in (d.getVar('SSTATE_HASHEQUIV_FILEMAP') or '').split():
> > @@ -506,8 +507,11 @@ def OEOuthashBasic(path, sigfile, task, d):
> >  basepath = os.path.normpath(path)
> >
> >  update_hash("OEOuthashBasic\n")
> > -if extra_content:
> > -update_hash(extra_content + "\n")
> > +if hash_version:
> > +update_hash(hash_version + "\n")
> > +
> > +if extra_sigdata:
> > +update_hash(extra_sigdata + "\n")
> >
> >  # It is only currently useful to get equivalent hashes for
> things that
> >  # can be restored from sstate. Since the sstate object is named
> using
> >
> >
> >
> >
> >
>
> Sounds to me like something we should do.
>
> Jacob
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160580): 
https://lists.openembedded.org/g/openembedded-core/message/160580
Mute This Topic: https://lists.openembedded.org/mt/88425608/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core][RFC] classes/native: Propagate dependencies to outhash

[Joshua Watt]

Native task outputs are directly run on the target (host) system after
being built. Even if the output of a native recipe doesn't change, a
change in one of its dependencies may cause a change in the output it
generates (e.g. rpm output depends on the output of its dependent zstd
library).

This can cause poor interactions with hash equivalence, since this
recipes output-changing dependency is "hidden" and downstream task only
see that this recipe has the same outhash and therefore is equivalent.
This can result in different output in different cases.

To resolve this, unhide the output-changing dependency by adding it's
unihash to this tasks outhash calculation. Unfortunately, don't know
specifically know which dependencies are output-changing, so we have to
add all of them.

[YOCTO #14685]

Signed-off-by: Joshua Watt 
---
 meta/classes/native.bbclass | 31 +++
 meta/lib/oe/sstatesig.py| 10 +++---
 2 files changed, 38 insertions(+), 3 deletions(-)

diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
index 76a599bc15..fc7422c5d7 100644
--- a/meta/classes/native.bbclass
+++ b/meta/classes/native.bbclass
@@ -195,3 +195,34 @@ USE_NLS = "no"
 
 RECIPERDEPTASK = "do_populate_sysroot"
 do_populate_sysroot[rdeptask] = "${RECIPERDEPTASK}"
+
+#
+# Native task outputs are directly run on the target (host) system after being
+# built. Even if the output of this recipe doesn't change, a change in one of
+# its dependencies may cause a change in the output it generates (e.g. rpm
+# output depends on the output of its dependent zstd library).
+#
+# This can cause poor interactions with hash equivalence, since this recipes
+# output-changing dependency is "hidden" and downstream task only see that this
+# recipe has the same outhash and therefore is equivalent. This can result in
+# different output in different cases.
+#
+# To resolve this, unhide the output-changing dependency by adding its unihash
+# to this tasks outhash calculation. Unfortunately, don't know specifically
+# know which dependencies are output-changing, so we have to add all of them.
+#
+python native_add_do_populate_sysroot_deps () {
+current_task = "do_" + d.getVar("BB_CURRENTTASK")
+if current_task != "do_populate_sysroot":
+return
+
+taskdepdata = d.getVar("BB_TASKDEPDATA", False)
+pn = d.getVar("PN")
+deps = {
+dep[0]:dep[6] for dep in taskdepdata.values() if
+dep[1] == current_task and dep[0] != pn
+}
+
+d.setVar("HASHEQUIV_EXTRA_SIGDATA", "\n".join("%s: %s" % (k, deps[k]) for 
k in sorted(deps.keys(
+}
+SSTATECREATEFUNCS += "native_add_do_populate_sysroot_deps"
diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
index 038404e377..abcd96231e 100644
--- a/meta/lib/oe/sstatesig.py
+++ b/meta/lib/oe/sstatesig.py
@@ -491,7 +491,8 @@ def OEOuthashBasic(path, sigfile, task, d):
 if task == "package":
 include_timestamps = True
 include_root = False
-extra_content = d.getVar('HASHEQUIV_HASH_VERSION')
+hash_version = d.getVar('HASHEQUIV_HASH_VERSION')
+extra_sigdata = d.getVar("HASHEQUIV_EXTRA_SIGDATA")
 
 filemaps = {}
 for m in (d.getVar('SSTATE_HASHEQUIV_FILEMAP') or '').split():
@@ -506,8 +507,11 @@ def OEOuthashBasic(path, sigfile, task, d):
 basepath = os.path.normpath(path)
 
 update_hash("OEOuthashBasic\n")
-if extra_content:
-update_hash(extra_content + "\n")
+if hash_version:
+update_hash(hash_version + "\n")
+
+if extra_sigdata:
+update_hash(extra_sigdata + "\n")
 
 # It is only currently useful to get equivalent hashes for things that
 # can be restored from sstate. Since the sstate object is named using
-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160571): 
https://lists.openembedded.org/g/openembedded-core/message/160571
Mute This Topic: https://lists.openembedded.org/mt/88425608/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH] create-spdx: add support for SDKs

[Joshua Watt]

On Wed, Jan 12, 2022 at 1:40 PM Andres Beltran
 wrote:
>
> Currently, SPDX SBOMs are only created for images. Add support for
> SDKs. Fix json indent when outputting SBOMs for better readability.

Most of us just pipe the output through `jq` to view it (colors are
really helpful). These files are already quite large, do we really
need to add more padding?

>
> Signed-off-by: Andres Beltran 
> ---
>  meta/classes/create-spdx.bbclass | 95 +---
>  meta/lib/oe/sbom.py  |  6 +-
>  2 files changed, 68 insertions(+), 33 deletions(-)
>
> diff --git a/meta/classes/create-spdx.bbclass 
> b/meta/classes/create-spdx.bbclass
> index e44a204a8fc..d0f987315ee 100644
> --- a/meta/classes/create-spdx.bbclass
> +++ b/meta/classes/create-spdx.bbclass
> @@ -556,7 +556,7 @@ python do_create_spdx() {
>  oe.sbom.write_doc(d, package_doc, "packages")
>  }
>  # NOTE: depending on do_unpack is a hack that is necessary to get it's 
> dependencies for archive the source
> -addtask do_create_spdx after do_package do_packagedata do_unpack before 
> do_build do_rm_work
> +addtask do_create_spdx after do_package do_packagedata do_unpack before 
> do_populate_sdk do_build do_rm_work
>
>  SSTATETASKS += "do_create_spdx"
>  do_create_spdx[sstate-inputdirs] = "${SPDXDEPLOY}"
> @@ -788,28 +788,77 @@ def spdx_get_src(d):
>  do_rootfs[recrdeptask] += "do_create_spdx do_create_runtime_spdx"
>
>  ROOTFS_POSTUNINSTALL_COMMAND =+ "image_combine_spdx ; "
> +
> +do_populate_sdk[recrdeptask] += "do_create_spdx do_create_runtime_spdx"
> +POPULATE_SDK_POST_HOST_COMMAND_append_task-populate-sdk = " 
> sdk_host_combine_spdx; "
> +POPULATE_SDK_POST_TARGET_COMMAND_append_task-populate-sdk = " 
> sdk_target_combine_spdx; "
> +
>  python image_combine_spdx() {
> +import os
> +import oe.sbom
> +from pathlib import Path
> +from oe.rootfs import image_list_installed_packages
> +
> +image_name = d.getVar("IMAGE_NAME")
> +image_link_name = d.getVar("IMAGE_LINK_NAME")
> +imgdeploydir = Path(d.getVar("IMGDEPLOYDIR"))
> +img_spdxid = oe.sbom.get_image_spdxid(image_name)
> +packages = image_list_installed_packages(d)
> +
> +combine_spdx(d, image_name, imgdeploydir, img_spdxid, packages)
> +
> +if image_link_name:
> +image_spdx_path = imgdeploydir / (image_name + ".spdx.json")
> +image_spdx_link = imgdeploydir / (image_link_name + ".spdx.json")
> +image_spdx_link.symlink_to(os.path.relpath(image_spdx_path, 
> image_spdx_link.parent))
> +
> +def make_image_link(target_path, suffix):
> +if image_link_name:
> +link = imgdeploydir / (image_link_name + suffix)
> +link.symlink_to(os.path.relpath(target_path, link.parent))
> +
> +spdx_tar_path = imgdeploydir / (image_name + ".spdx.tar.zst")
> +make_image_link(spdx_tar_path, ".spdx.tar.zst")
> +spdx_index_path = imgdeploydir / (image_name + ".spdx.index.json")
> +make_image_link(spdx_index_path, ".spdx.index.json")
> +}
> +
> +python sdk_host_combine_spdx() {
> +sdk_combine_spdx(d, "host")
> +}
> +
> +python sdk_target_combine_spdx() {
> +sdk_combine_spdx(d, "target")
> +}
> +
> +def sdk_combine_spdx(d, sdk_type):
> +import oe.sbom
> +from pathlib import Path
> +from oe.sdk import sdk_list_installed_packages
> +
> +sdk_name = d.getVar("SDK_NAME") + "-" + sdk_type
> +sdk_deploydir = Path(d.getVar("SDKDEPLOYDIR"))
> +sdk_spdxid = oe.sbom.get_sdk_spdxid(sdk_name)
> +sdk_packages = sdk_list_installed_packages(d, sdk_type == "target")
> +combine_spdx(d, sdk_name, sdk_deploydir, sdk_spdxid, sdk_packages)
> +
> +def combine_spdx(d, rootfs_name, rootfs_deploydir, rootfs_spdxid, packages):
>  import os
>  import oe.spdx
>  import oe.sbom
>  import io
>  import json
> -from oe.rootfs import image_list_installed_packages
>  from datetime import timezone, datetime
>  from pathlib import Path
>  import tarfile
>  import bb.compress.zstd
>
>  creation_time = 
> datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
> -image_name = d.getVar("IMAGE_NAME")
> -image_link_name = d.getVar("IMAGE_LINK_NAME")
> -
>  deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
> -imgdeploydir = Path(d.getVar("IMGDEPLOYDIR"))
>  source_date_epoch = d.getVar("SOURCE_DATE_EPOCH")
>
>  doc = oe.spdx.SPDXDocument()
> -doc.name = image_name
> +doc.name = rootfs_name
>  doc.documentNamespace = get_doc_namespace(d, doc)
>  doc.creationInfo.created = creation_time
>  doc.creationInfo.comment = "This document was created by analyzing the 
> source of the Yocto recipe during the build."
> @@ -821,14 +870,12 @@ python image_combine_spdx() {
>  image = oe.spdx.SPDXPackage()
>  image.name = d.getVar("PN")
>  image.versionInfo = d.getVar("PV")
> -image.SPDXID = oe.sbom.get_image_spdxid(image_name)
> +image.SPDXID = rootfs_spdxid
>
>  

[OE-core] [PATCH] oeqa/runtime/stap: rewrite test

[Ross Burton]

There's no need to copy files to the target when stap can take the short
probe directly.

Add more has-package decorators for the kernel source and GCC symlinks.
Remove the test dependencies as it's not a hard dependency.

Change the probe to print a message with some minimal logic, and verify
that the message was correctly constructed in the output.

Signed-off-by: Ross Burton 
---
 meta/lib/oeqa/runtime/cases/stap.py   | 35 +--
 meta/lib/oeqa/runtime/files/hello.stp |  1 -
 2 files changed, 11 insertions(+), 25 deletions(-)
 delete mode 100644 meta/lib/oeqa/runtime/files/hello.stp

diff --git a/meta/lib/oeqa/runtime/cases/stap.py 
b/meta/lib/oeqa/runtime/cases/stap.py
index 5342f6ac342..ac0125edb2b 100644
--- a/meta/lib/oeqa/runtime/cases/stap.py
+++ b/meta/lib/oeqa/runtime/cases/stap.py
@@ -5,33 +5,20 @@
 import os
 
 from oeqa.runtime.case import OERuntimeTestCase
-from oeqa.core.decorator.depends import OETestDepends
 from oeqa.core.decorator.data import skipIfNotFeature
 from oeqa.runtime.decorator.package import OEHasPackage
 
 class StapTest(OERuntimeTestCase):
-
-@classmethod
-def setUp(cls):
-src = os.path.join(cls.tc.runtime_files_dir, 'hello.stp')
-dst = '/tmp/hello.stp'
-cls.tc.target.copyTo(src, dst)
-
-@classmethod
-def tearDown(cls):
-files = '/tmp/hello.stp'
-cls.tc.target.run('rm %s' % files)
-
-@skipIfNotFeature('tools-profile',
-  'Test requires tools-profile to be in IMAGE_FEATURES')
-@OETestDepends(['kernelmodule.KernelModuleTest.test_kernel_module'])
+@skipIfNotFeature('tools-profile', 'Test requires tools-profile to be in 
IMAGE_FEATURES')
 @OEHasPackage(['systemtap'])
+@OEHasPackage(['gcc-symlinks'])
+@OEHasPackage(['kernel-devsrc'])
 def test_stap(self):
-cmds = [
-'cd /usr/src/kernel && make scripts prepare',
-'cd /lib/modules/`uname -r` && (if [ ! -e build ]; then ln -s 
/usr/src/kernel build; fi)',
-'stap --disable-cache -DSTP_NO_VERREL_CHECK /tmp/hello.stp'
-]
-for cmd in cmds:
-status, output = self.target.run(cmd, 900)
-self.assertEqual(status, 0, msg='\n'.join([cmd, output]))
+cmd = 'make -C /usr/src/kernel scripts prepare'
+status, output = self.target.run(cmd, 900)
+self.assertEqual(status, 0, msg='\n'.join([cmd, output]))
+
+cmd = 'stap -v --disable-cache -DSTP_NO_VERREL_CHECK -e \'probe 
oneshot { print("Hello, "); println("world!") }\''
+status, output = self.target.run(cmd, 900)
+self.assertEqual(status, 0, msg='\n'.join([cmd, output]))
+self.assertIn('Hello, world!', output, msg='\n'.join([cmd, output]))
diff --git a/meta/lib/oeqa/runtime/files/hello.stp 
b/meta/lib/oeqa/runtime/files/hello.stp
deleted file mode 100644
index 36771471625..000
--- a/meta/lib/oeqa/runtime/files/hello.stp
+++ /dev/null
@@ -1 +0,0 @@
-probe oneshot { println("hello world") }
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160581): 
https://lists.openembedded.org/g/openembedded-core/message/160581
Mute This Topic: https://lists.openembedded.org/mt/88427039/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][RFC] classes/native: Propagate dependencies to outhash

[Jacob Kroon]

On 1/14/22 18:12, Joshua Watt wrote:
> Native task outputs are directly run on the target (host) system after

"target" or "host" ? the latter i suppose

> being built. Even if the output of a native recipe doesn't change, a
> change in one of its dependencies may cause a change in the output it
> generates (e.g. rpm output depends on the output of its dependent zstd
> library).
> 
> This can cause poor interactions with hash equivalence, since this
> recipes output-changing dependency is "hidden" and downstream task only
> see that this recipe has the same outhash and therefore is equivalent.
> This can result in different output in different cases.
> 
> To resolve this, unhide the output-changing dependency by adding it's
> unihash to this tasks outhash calculation. Unfortunately, don't know
> specifically know which dependencies are output-changing, so we have to
> add all of them.
> 

"don't know specifically know which.."

> [YOCTO #14685]
> 
> Signed-off-by: Joshua Watt 
> ---
>  meta/classes/native.bbclass | 31 +++
>  meta/lib/oe/sstatesig.py| 10 +++---
>  2 files changed, 38 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/classes/native.bbclass b/meta/classes/native.bbclass
> index 76a599bc15..fc7422c5d7 100644
> --- a/meta/classes/native.bbclass
> +++ b/meta/classes/native.bbclass
> @@ -195,3 +195,34 @@ USE_NLS = "no"
>  
>  RECIPERDEPTASK = "do_populate_sysroot"
>  do_populate_sysroot[rdeptask] = "${RECIPERDEPTASK}"
> +
> +#
> +# Native task outputs are directly run on the target (host) system after 
> being

see above

> +# built. Even if the output of this recipe doesn't change, a change in one of
> +# its dependencies may cause a change in the output it generates (e.g. rpm
> +# output depends on the output of its dependent zstd library).
> +#
> +# This can cause poor interactions with hash equivalence, since this recipes
> +# output-changing dependency is "hidden" and downstream task only see that 
> this
> +# recipe has the same outhash and therefore is equivalent. This can result in
> +# different output in different cases.
> +#
> +# To resolve this, unhide the output-changing dependency by adding its 
> unihash
> +# to this tasks outhash calculation. Unfortunately, don't know specifically
> +# know which dependencies are output-changing, so we have to add all of them.
> +#

see above

> +python native_add_do_populate_sysroot_deps () {
> +current_task = "do_" + d.getVar("BB_CURRENTTASK")
> +if current_task != "do_populate_sysroot":
> +return
> +
> +taskdepdata = d.getVar("BB_TASKDEPDATA", False)
> +pn = d.getVar("PN")
> +deps = {
> +dep[0]:dep[6] for dep in taskdepdata.values() if
> +dep[1] == current_task and dep[0] != pn
> +}
> +
> +d.setVar("HASHEQUIV_EXTRA_SIGDATA", "\n".join("%s: %s" % (k, deps[k]) 
> for k in sorted(deps.keys(
> +}
> +SSTATECREATEFUNCS += "native_add_do_populate_sysroot_deps"
> diff --git a/meta/lib/oe/sstatesig.py b/meta/lib/oe/sstatesig.py
> index 038404e377..abcd96231e 100644
> --- a/meta/lib/oe/sstatesig.py
> +++ b/meta/lib/oe/sstatesig.py
> @@ -491,7 +491,8 @@ def OEOuthashBasic(path, sigfile, task, d):
>  if task == "package":
>  include_timestamps = True
>  include_root = False
> -extra_content = d.getVar('HASHEQUIV_HASH_VERSION')
> +hash_version = d.getVar('HASHEQUIV_HASH_VERSION')
> +extra_sigdata = d.getVar("HASHEQUIV_EXTRA_SIGDATA")
>  
>  filemaps = {}
>  for m in (d.getVar('SSTATE_HASHEQUIV_FILEMAP') or '').split():
> @@ -506,8 +507,11 @@ def OEOuthashBasic(path, sigfile, task, d):
>  basepath = os.path.normpath(path)
>  
>  update_hash("OEOuthashBasic\n")
> -if extra_content:
> -update_hash(extra_content + "\n")
> +if hash_version:
> +update_hash(hash_version + "\n")
> +
> +if extra_sigdata:
> +update_hash(extra_sigdata + "\n")
>  
>  # It is only currently useful to get equivalent hashes for things 
> that
>  # can be restored from sstate. Since the sstate object is named using
> 
> 
> 
> 
> 

Sounds to me like something we should do.

Jacob

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160573): 
https://lists.openembedded.org/g/openembedded-core/message/160573
Mute This Topic: https://lists.openembedded.org/mt/88425608/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [hardknott][PATCH 4/8] qemu: fix CVE-2021-3594

[Sakib Sajal]

Please disregard, sorry for the barrage of incomplete patch set.

On 2022-01-14 1:03 p.m., Sakib Sajal wrote:

Signed-off-by: Sakib Sajal 
---
  meta/recipes-devtools/qemu/qemu.inc   |  1 +
  .../qemu/qemu/CVE-2021-3594.patch | 40 +++
  2 files changed, 41 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 811bdff426..4198d3a52c 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -76,6 +76,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
 file://CVE-2021-3593.patch \
 file://CVE-2021-3595_1.patch \
 file://CVE-2021-3595_2.patch \
+   file://CVE-2021-3594.patch \
 "
  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
  
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch b/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch

new file mode 100644
index 00..c99ba7a7cc
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3594.patch
@@ -0,0 +1,40 @@
+From 7a5ffd5475f2cbfe3cf91d9584893f1a4b3b4dff Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 16:40:23 +0400
+Subject: [PATCH 07/12] udp: check upd_input buffer size
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: CVE-2021-3594
+Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/47
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [74572be49247c8c5feae7c6e0b50c4f569ca9824]
+CVE: CVE-2021-3594
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/udp.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/slirp/src/udp.c b/slirp/src/udp.c
+index 0ad44d7c0..18b4acdfa 100644
+--- a/slirp/src/udp.c
 b/slirp/src/udp.c
+@@ -93,7 +93,10 @@ void udp_input(register struct mbuf *m, int iphlen)
+ /*
+  * Get IP and UDP header together in first mbuf.
+  */
+-ip = mtod(m, struct ip *);
++ip = mtod_check(m, iphlen + sizeof(struct udphdr));
++if (ip == NULL) {
++goto bad;
++}
+ uh = (struct udphdr *)((char *)ip + iphlen);
+
+ /*
+--
+2.31.1
+




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160582): 
https://lists.openembedded.org/g/openembedded-core/message/160582
Mute This Topic: https://lists.openembedded.org/mt/88427076/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [hardknott][PATCH 2/8] qemu: fix CVE-2021-3593

[Sakib Sajal]

Please disregard, sorry for the barrage of incomplete patch set.

On 2022-01-14 1:03 p.m., Sakib Sajal wrote:

Signed-off-by: Sakib Sajal 
---
  meta/recipes-devtools/qemu/qemu.inc   |  1 +
  .../qemu/qemu/CVE-2021-3593.patch | 40 +++
  2 files changed, 41 insertions(+)
  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch

diff --git a/meta/recipes-devtools/qemu/qemu.inc 
b/meta/recipes-devtools/qemu/qemu.inc
index 6c00bf274b..6b544a4344 100644
--- a/meta/recipes-devtools/qemu/qemu.inc
+++ b/meta/recipes-devtools/qemu/qemu.inc
@@ -73,6 +73,7 @@ SRC_URI = "https://download.qemu.org/${BPN}-${PV}.tar.xz \
 file://CVE-2021-3592_1.patch \
 file://CVE-2021-3592_2.patch \
 file://CVE-2021-3592_3.patch \
+   file://CVE-2021-3593.patch \
 "
  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
  
diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch

new file mode 100644
index 00..dd14c240a8
--- /dev/null
+++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
@@ -0,0 +1,40 @@
+From fe99634066e1074aaf55e83b576385877d7e4bcc Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?= 
+Date: Fri, 4 Jun 2021 16:32:55 +0400
+Subject: [PATCH 04/12] upd6: check udp6_input buffer size
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Fixes: CVE-2021-3593
+Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/45
+
+Signed-off-by: Marc-André Lureau 
+
+Upstream-Status: Backport [de71c15de66ba9350bf62c45b05f8fbff166517b]
+CVE: CVE-2021-3593
+
+Signed-off-by: Sakib Sajal 
+---
+ slirp/src/udp6.c | 5 -
+ 1 file changed, 4 insertions(+), 1 deletion(-)
+
+diff --git a/slirp/src/udp6.c b/slirp/src/udp6.c
+index 6f9486bbc..8c490e4d1 100644
+--- a/slirp/src/udp6.c
 b/slirp/src/udp6.c
+@@ -28,7 +28,10 @@ void udp6_input(struct mbuf *m)
+ ip = mtod(m, struct ip6 *);
+ m->m_len -= iphlen;
+ m->m_data += iphlen;
+-uh = mtod(m, struct udphdr *);
++uh = mtod_check(m, sizeof(struct udphdr));
++if (uh == NULL) {
++goto bad;
++}
+ m->m_len += iphlen;
+ m->m_data -= iphlen;
+
+--
+2.31.1
+




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160583): 
https://lists.openembedded.org/g/openembedded-core/message/160583
Mute This Topic: https://lists.openembedded.org/mt/88427080/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [hardknott][PATCH 2/8] qemu: fix CVE-2021-3593

[Anuj Mittal]

On Fri, 2022-01-14 at 13:10 -0500, Sakib Sajal wrote:
> Please disregard, sorry for the barrage of incomplete patch set.

Do you also have a branch on contrib that I can pull these patches
from?

Thanks,

Anuj

> On 2022-01-14 1:03 p.m., Sakib Sajal wrote:
>  
> > Signed-off-by: Sakib Sajal 
> > ---
> >  meta/recipes-devtools/qemu/qemu.inc   |  1 +
> >  .../qemu/qemu/CVE-2021-3593.patch | 40
> > +++
> >  2 files changed, 41 insertions(+)
> >  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2021-
> > 3593.patch
> > 
> > diff --git a/meta/recipes-devtools/qemu/qemu.inc b/meta/recipes-
> > devtools/qemu/qemu.inc
> > index 6c00bf274b..6b544a4344 100644
> > --- a/meta/recipes-devtools/qemu/qemu.inc
> > +++ b/meta/recipes-devtools/qemu/qemu.inc
> > @@ -73,6 +73,7 @@ SRC_URI =
> > "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> > file://CVE-2021-3592_1.patch \
> > file://CVE-2021-3592_2.patch \
> > file://CVE-2021-3592_3.patch \
> > +   file://CVE-2021-3593.patch \
> > "
> >  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
> >  
> > diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
> > b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
> > new file mode 100644
> > index 00..dd14c240a8
> > --- /dev/null
> > +++ b/meta/recipes-devtools/qemu/qemu/CVE-2021-3593.patch
> > @@ -0,0 +1,40 @@
> > +From fe99634066e1074aaf55e83b576385877d7e4bcc Mon Sep 17 00:00:00
> > 2001
> > +From: =?UTF-8?q?Marc-Andr=C3=A9=20Lureau?=
> > 
> > +Date: Fri, 4 Jun 2021 16:32:55 +0400
> > +Subject: [PATCH 04/12] upd6: check udp6_input buffer size
> > +MIME-Version: 1.0
> > +Content-Type: text/plain; charset=UTF-8
> > +Content-Transfer-Encoding: 8bit
> > +
> > +Fixes: CVE-2021-3593
> > +Fixes: https://gitlab.freedesktop.org/slirp/libslirp/-/issues/45
> > +
> > +Signed-off-by: Marc-André Lureau 
> > +
> > +Upstream-Status: Backport
> > [de71c15de66ba9350bf62c45b05f8fbff166517b]
> > +CVE: CVE-2021-3593
> > +
> > +Signed-off-by: Sakib Sajal 
> > +---
> > + slirp/src/udp6.c | 5 -
> > + 1 file changed, 4 insertions(+), 1 deletion(-)
> > +
> > +diff --git a/slirp/src/udp6.c b/slirp/src/udp6.c
> > +index 6f9486bbc..8c490e4d1 100644
> > +--- a/slirp/src/udp6.c
> >  b/slirp/src/udp6.c
> > +@@ -28,7 +28,10 @@ void udp6_input(struct mbuf *m)
> > + ip = mtod(m, struct ip6 *);
> > + m->m_len -= iphlen;
> > + m->m_data += iphlen;
> > +-uh = mtod(m, struct udphdr *);
> > ++uh = mtod_check(m, sizeof(struct udphdr));
> > ++if (uh == NULL) {
> > ++goto bad;
> > ++}
> > + m->m_len += iphlen;
> > + m->m_data -= iphlen;
> > + 
> > +-- 
> > +2.31.1
> > +
> >  
> >  
> > 
> > 
> 
> 
> 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160600): 
https://lists.openembedded.org/g/openembedded-core/message/160600
Mute This Topic: https://lists.openembedded.org/mt/88427080/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72

[Kevin Hao]

On Sat, Jan 15, 2022 at 02:53:09AM +, Mittal, Anuj wrote:
> [Please note: This e-mail is from an EXTERNAL e-mail address]
> 
> On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote:
> > From: Jagadeesh Krishnanjanappa 
> >
> > The cryptographic unit is optional for the Cortex-A72, but it was
> > included by default previously.  This breaks building systems that
> > lack this functionality when using tune-cortexa72.inc.
> >
> > To correct this, add a crypto entry in the tune file.  Since CRC is
> > optional for ARMv8.0, do the same thing while we're at it.
> >
> > For platforms that had been happily using tune-cortexa72.inc, a
> > slight
> > degradation of performance will occur using the default.  To correct
> > this, simply add:
> > DEFAULTTUNE = "cortexa72-crc-crypto"
> >
> 
> I am not very familiar with ARM tunes but it sounds like you are
> changing behaviour for people who might already be using these tunes
> with these two patches ... That might not be suitable for stable
> branches.

These two patches fix the application crash bug on the boards which
have a cortexa72 core but don't have a crypto unit. IMHO they are definitely
suitable for the stable branch. Yes, for the boards which do have a crypto
unit, they would have to update their default tune to avoid the slight
the degradation of performance.

Thanks,
Kevin

> 
> Perhaps Ross, Jon or others can comment if this is something that
> should be merged in stable branches.
> 
> Thanks,
> 
> Anuj
> 
> > (From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)
> >
> > Signed-off-by: Jagadeesh Krishnanjanappa 
> > Signed-off-by: Jon Mason  (rewording commit
> > message)
> > Signed-off-by: Richard Purdie 
> > [Kevin: Convert to the old style override syntax]
> > Signed-off-by: Kevin Hao 
> > ---
> >  meta/conf/machine/include/tune-cortexa72.inc | 16 
> >  1 file changed, 12 insertions(+), 4 deletions(-)
> >
> > diff --git a/meta/conf/machine/include/tune-cortexa72.inc
> > b/meta/conf/machine/include/tune-cortexa72.inc
> > index b3f68ab6e3be..7608a20c43f4 100644
> > --- a/meta/conf/machine/include/tune-cortexa72.inc
> > +++ b/meta/conf/machine/include/tune-cortexa72.inc
> > @@ -6,8 +6,16 @@ TUNE_CCARGS .=
> > "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
> >  require conf/machine/include/arm/arch-armv8a.inc
> >
> >  # Little Endian base configs
> > -AVAILTUNES += "cortexa72"
> > +AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
> >  ARMPKGARCH_tune-cortexa72 = "cortexa72"
> > -TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-
> > armv8a-crc-crypto} cortexa72"
> > -PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-
> > armv8a-crc-crypto} cortexa72"
> > -BASE_LIB_tune-cortexa72   = "lib64"
> > +ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
> > +ARMPKGARCH_tune-cortexa72-crc-crypto  = "cortexa72"
> > +TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-
> > armv8a} cortexa72"
> > +TUNE_FEATURES_tune-cortexa72-crc  = "${TUNE_FEATURES_tune-
> > cortexa72} crc"
> > +TUNE_FEATURES_tune-cortexa72-crc-crypto   = "${TUNE_FEATURES_tune-
> > cortexa72} crc crypto"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8} cortexa72"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
> > +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto=
> > "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-
> > crc cortexa72-crc-crypto"
> > +BASE_LIB_tune-cortexa72= "lib64"
> > +BASE_LIB_tune-cortexa72-crc= "lib64"
> > +BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
> 


signature.asc
Description: PGP signature

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160601): 
https://lists.openembedded.org/g/openembedded-core/message/160601
Mute This Topic: https://lists.openembedded.org/mt/88436676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72

[Anuj Mittal]

On Sat, 2022-01-15 at 10:37 +0800, Kevin Hao wrote:
> From: Jagadeesh Krishnanjanappa 
> 
> The cryptographic unit is optional for the Cortex-A72, but it was
> included by default previously.  This breaks building systems that
> lack this functionality when using tune-cortexa72.inc.
> 
> To correct this, add a crypto entry in the tune file.  Since CRC is
> optional for ARMv8.0, do the same thing while we're at it.
> 
> For platforms that had been happily using tune-cortexa72.inc, a
> slight
> degradation of performance will occur using the default.  To correct
> this, simply add:
> DEFAULTTUNE = "cortexa72-crc-crypto"
> 

I am not very familiar with ARM tunes but it sounds like you are
changing behaviour for people who might already be using these tunes
with these two patches ... That might not be suitable for stable
branches.

Perhaps Ross, Jon or others can comment if this is something that
should be merged in stable branches.

Thanks,

Anuj

> (From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)
> 
> Signed-off-by: Jagadeesh Krishnanjanappa 
> Signed-off-by: Jon Mason  (rewording commit
> message)
> Signed-off-by: Richard Purdie 
> [Kevin: Convert to the old style override syntax]
> Signed-off-by: Kevin Hao 
> ---
>  meta/conf/machine/include/tune-cortexa72.inc | 16 
>  1 file changed, 12 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/conf/machine/include/tune-cortexa72.inc
> b/meta/conf/machine/include/tune-cortexa72.inc
> index b3f68ab6e3be..7608a20c43f4 100644
> --- a/meta/conf/machine/include/tune-cortexa72.inc
> +++ b/meta/conf/machine/include/tune-cortexa72.inc
> @@ -6,8 +6,16 @@ TUNE_CCARGS .=
> "${@bb.utils.contains('TUNE_FEATURES', 'cortexa72', ' -mcpu=corte
>  require conf/machine/include/arm/arch-armv8a.inc
>  
>  # Little Endian base configs
> -AVAILTUNES += "cortexa72"
> +AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
>  ARMPKGARCH_tune-cortexa72 = "cortexa72"
> -TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-
> armv8a-crc-crypto} cortexa72"
> -PACKAGE_EXTRA_ARCHS_tune-cortexa72    = "${PACKAGE_EXTRA_ARCHS_tune-
> armv8a-crc-crypto} cortexa72"
> -BASE_LIB_tune-cortexa72   = "lib64"
> +ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
> +ARMPKGARCH_tune-cortexa72-crc-crypto  = "cortexa72"
> +TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-
> armv8a} cortexa72"
> +TUNE_FEATURES_tune-cortexa72-crc  = "${TUNE_FEATURES_tune-
> cortexa72} crc"
> +TUNE_FEATURES_tune-cortexa72-crc-crypto   = "${TUNE_FEATURES_tune-
> cortexa72} crc crypto"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa72    =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8} cortexa72"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc    =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
> +PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto    =
> "${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-
> crc cortexa72-crc-crypto"
> +BASE_LIB_tune-cortexa72    = "lib64"
> +BASE_LIB_tune-cortexa72-crc    = "lib64"
> +BASE_LIB_tune-cortexa72-crc-crypto = "lib64"


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160599): 
https://lists.openembedded.org/g/openembedded-core/message/160599
Mute This Topic: https://lists.openembedded.org/mt/88436676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott 1/2] tune-cortexa72: remove crypto for the default cortex-a72

[Kevin Hao]

From: Jagadeesh Krishnanjanappa 

The cryptographic unit is optional for the Cortex-A72, but it was
included by default previously.  This breaks building systems that
lack this functionality when using tune-cortexa72.inc.

To correct this, add a crypto entry in the tune file.  Since CRC is
optional for ARMv8.0, do the same thing while we're at it.

For platforms that had been happily using tune-cortexa72.inc, a slight
degradation of performance will occur using the default.  To correct
this, simply add:
DEFAULTTUNE = "cortexa72-crc-crypto"

(From OE-Core rev: 2568d537087adb0b592aa250bf628a7b48c3a9d3)

Signed-off-by: Jagadeesh Krishnanjanappa 
Signed-off-by: Jon Mason  (rewording commit message)
Signed-off-by: Richard Purdie 
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao 
---
 meta/conf/machine/include/tune-cortexa72.inc | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa72.inc 
b/meta/conf/machine/include/tune-cortexa72.inc
index b3f68ab6e3be..7608a20c43f4 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -6,8 +6,16 @@ TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 
'cortexa72', ' -mcpu=corte
 require conf/machine/include/arm/arch-armv8a.inc
 
 # Little Endian base configs
-AVAILTUNES += "cortexa72"
+AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
 ARMPKGARCH_tune-cortexa72 = "cortexa72"
-TUNE_FEATURES_tune-cortexa72  = 
"${TUNE_FEATURES_tune-armv8a-crc-crypto} cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72"
-BASE_LIB_tune-cortexa72   = "lib64"
+ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
+ARMPKGARCH_tune-cortexa72-crc-crypto  = "cortexa72"
+TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-armv8a} 
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc  = "${TUNE_FEATURES_tune-cortexa72} crc"
+TUNE_FEATURES_tune-cortexa72-crc-crypto   = "${TUNE_FEATURES_tune-cortexa72} 
crc crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc 
cortexa72-crc-crypto"
+BASE_LIB_tune-cortexa72= "lib64"
+BASE_LIB_tune-cortexa72-crc= "lib64"
+BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160596): 
https://lists.openembedded.org/g/openembedded-core/message/160596
Mute This Topic: https://lists.openembedded.org/mt/88436676/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott 0/2] tune-cortexa72: Drop the crypto extension from the cortexa72 tune

[Kevin Hao]

Hi,

This patch series backport two patches from the master branch to fix the
crash issue on some cortexa72 boards due to the crypto intructions are
used.

Jagadeesh Krishnanjanappa (1):
  tune-cortexa72: remove crypto for the default cortex-a72

Kevin Hao (1):
  tune-cortexa72: Enable the crc extension by default for cortexa72

 meta/conf/machine/include/tune-cortexa72.inc | 16 
 1 file changed, 12 insertions(+), 4 deletions(-)

-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160597): 
https://lists.openembedded.org/g/openembedded-core/message/160597
Mute This Topic: https://lists.openembedded.org/mt/88436677/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott 2/2] tune-cortexa72: Enable the crc extension by default for cortexa72

[Kevin Hao]

The crc extension is optional for the ARMv8.0 but is mandatory for the
cortexa72, so there is no reason not to enable it for the cortexa72
tune. With this change, the cortexa72-crc seems redundant. But we
had better to keep it to be compatible with the BSP which already used
that tune.

(From OE-Core rev: ca50267ab568d2f688844cb7c6cd867ed34168db)

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao 
---
 meta/conf/machine/include/tune-cortexa72.inc | 12 ++--
 1 file changed, 6 insertions(+), 6 deletions(-)

diff --git a/meta/conf/machine/include/tune-cortexa72.inc 
b/meta/conf/machine/include/tune-cortexa72.inc
index 7608a20c43f4..30480efd8328 100644
--- a/meta/conf/machine/include/tune-cortexa72.inc
+++ b/meta/conf/machine/include/tune-cortexa72.inc
@@ -10,12 +10,12 @@ AVAILTUNES += "cortexa72 cortexa72-crc cortexa72-crc-crypto"
 ARMPKGARCH_tune-cortexa72 = "cortexa72"
 ARMPKGARCH_tune-cortexa72-crc = "cortexa72"
 ARMPKGARCH_tune-cortexa72-crc-crypto  = "cortexa72"
-TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-armv8a} 
cortexa72"
-TUNE_FEATURES_tune-cortexa72-crc  = "${TUNE_FEATURES_tune-cortexa72} crc"
-TUNE_FEATURES_tune-cortexa72-crc-crypto   = "${TUNE_FEATURES_tune-cortexa72} 
crc crypto"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72= "${PACKAGE_EXTRA_ARCHS_tune-armv8} 
cortexa72"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72 cortexa72-crc"
-PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc 
cortexa72-crc-crypto"
+TUNE_FEATURES_tune-cortexa72  = "${TUNE_FEATURES_tune-armv8a-crc} 
cortexa72"
+TUNE_FEATURES_tune-cortexa72-crc  = "${TUNE_FEATURES_tune-cortexa72}"
+TUNE_FEATURES_tune-cortexa72-crc-crypto   = "${TUNE_FEATURES_tune-cortexa72} 
crypto"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc} cortexa72"
+PACKAGE_EXTRA_ARCHS_tune-cortexa72-crc-crypto= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a-crc-crypto} cortexa72 cortexa72-crc-crypto"
 BASE_LIB_tune-cortexa72= "lib64"
 BASE_LIB_tune-cortexa72-crc= "lib64"
 BASE_LIB_tune-cortexa72-crc-crypto = "lib64"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160598): 
https://lists.openembedded.org/g/openembedded-core/message/160598
Mute This Topic: https://lists.openembedded.org/mt/88436678/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott][PATCH] curl: Backport CVE fixes

[Robert Joslyn]

Backport fixes for CVE-2021-22922, CVE-2021-22923, CVE-2021-22945,
CVE-2021-22946, and CVE-2021-22947.

 * https://curl.se/docs/CVE-2021-22922.html
 * https://curl.se/docs/CVE-2021-22923.html
 * https://curl.se/docs/CVE-2021-22945.html
 * https://curl.se/docs/CVE-2021-22946.html
 * https://curl.se/docs/CVE-2021-22947.html

22922 and 22923 were fixed by upstream by simply removing metalink
support in newer versions. These are mitigated in older versions by
disabling metalink support, which was already done by the recipe, so
whitelist these CVEs.

22945, 22946, and 22947 are backported with only trivial patch fuzz
modifications.

Signed-off-by: Robert Joslyn 
---
 .../curl/curl/CVE-2021-22945.patch|  35 ++
 .../curl/curl/CVE-2021-22946.patch| 333 
 .../curl/curl/CVE-2021-22947.patch| 357 ++
 meta/recipes-support/curl/curl_7.75.0.bb  |   8 +
 4 files changed, 733 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22945.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22946.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2021-22947.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2021-22945.patch 
b/meta/recipes-support/curl/curl/CVE-2021-22945.patch
new file mode 100644
index 00..44c42632ed
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2021-22945.patch
@@ -0,0 +1,35 @@
+From 43157490a5054bd24256fe12876931e8abc9df49 Mon Sep 17 00:00:00 2001
+From: z2_ on hackerone <>
+Date: Tue, 24 Aug 2021 09:50:33 +0200
+Subject: [PATCH] mqtt: clear the leftovers pointer when sending succeeds
+
+CVE-2021-22945
+
+Bug: https://curl.se/docs/CVE-2021-22945.html
+
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/43157490a5054bd24256fe12876931e8abc9df49]
+
+Signed-off-by: Robert Joslyn 
+
+---
+ lib/mqtt.c | 4 
+ 1 file changed, 4 insertions(+)
+
+diff --git a/lib/mqtt.c b/lib/mqtt.c
+index f077e6c3d..fcd40b41e 100644
+--- a/lib/mqtt.c
 b/lib/mqtt.c
+@@ -128,6 +128,10 @@ static CURLcode mqtt_send(struct Curl_easy *data,
+ mq->sendleftovers = sendleftovers;
+ mq->nsend = nsend;
+   }
++  else {
++mq->sendleftovers = NULL;
++mq->nsend = 0;
++  }
+   return result;
+ }
+ 
+-- 
+2.34.1
+
diff --git a/meta/recipes-support/curl/curl/CVE-2021-22946.patch 
b/meta/recipes-support/curl/curl/CVE-2021-22946.patch
new file mode 100644
index 00..1cb95f0ea7
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2021-22946.patch
@@ -0,0 +1,333 @@
+From 7c6e072216001fb1280d1868adfdcb54e3372ce7 Mon Sep 17 00:00:00 2001
+From: Patrick Monnerat 
+Date: Wed, 8 Sep 2021 11:56:22 +0200
+Subject: [PATCH] ftp,imap,pop3: do not ignore --ssl-reqd
+
+In imap and pop3, check if TLS is required even when capabilities
+request has failed.
+
+In ftp, ignore preauthentication (230 status of server greeting) if TLS
+is required.
+
+Bug: https://curl.se/docs/CVE-2021-22946.html
+
+CVE-2021-22946
+
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/364f174724ef115c63d5e5dc1d3342c8a43b1cca]
+
+Signed-off-by: Robert Joslyn 
+
+---
+ lib/ftp.c   |  9 ---
+ lib/imap.c  | 24 --
+ lib/pop3.c  | 33 +++-
+ tests/data/Makefile.inc |  2 ++
+ tests/data/test984  | 56 +
+ tests/data/test985  | 54 +++
+ tests/data/test986  | 53 ++
+ 7 files changed, 195 insertions(+), 36 deletions(-)
+ create mode 100644 tests/data/test984
+ create mode 100644 tests/data/test985
+ create mode 100644 tests/data/test986
+
+diff --git a/lib/ftp.c b/lib/ftp.c
+index 3818a9e..8b3fe1d 100644
+--- a/lib/ftp.c
 b/lib/ftp.c
+@@ -2665,9 +2665,12 @@ static CURLcode ftp_statemachine(struct Curl_easy *data,
+ /* we have now received a full FTP server response */
+ switch(ftpc->state) {
+ case FTP_WAIT220:
+-  if(ftpcode == 230)
+-/* 230 User logged in - already! */
+-return ftp_state_user_resp(data, ftpcode, ftpc->state);
++  if(ftpcode == 230) {
++/* 230 User logged in - already! Take as 220 if TLS required. */
++if(data->set.use_ssl <= CURLUSESSL_TRY ||
++   conn->bits.ftp_use_control_ssl)
++  return ftp_state_user_resp(data, ftpcode, ftpc->state);
++  }
+   else if(ftpcode != 220) {
+ failf(data, "Got a %03d ftp-server response when 220 was expected",
+   ftpcode);
+diff --git a/lib/imap.c b/lib/imap.c
+index 2d80699..b056208 100644
+--- a/lib/imap.c
 b/lib/imap.c
+@@ -933,22 +933,18 @@ static CURLcode imap_state_capability_resp(struct 
Curl_easy *data,
+   line += wordlen;
+ }
+   }
+-  else if(imapcode == IMAP_RESP_OK) {
+-if(data->set.use_ssl && !conn->ssl[FIRSTSOCKET].use) {
+-  /* We don't have a SSL/TLS connection yet, but SSL is requested */
+-  if(imapc->tls_supported)
+- 

[OE-core] [hardknott 1/2] arch-armv8-5a.inc: Add tune include for armv8.5a

[Kevin Hao]

This adds support for the armv8.5a architecture and the crypto
extension.

(From OE-Core rev: 0cb1a6d9cb4c32526d79dad93c8053b3793053f8)

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao 
---
 .../machine/include/arm/arch-armv8-5a.inc | 19 +++
 1 file changed, 19 insertions(+)
 create mode 100644 meta/conf/machine/include/arm/arch-armv8-5a.inc

diff --git a/meta/conf/machine/include/arm/arch-armv8-5a.inc 
b/meta/conf/machine/include/arm/arch-armv8-5a.inc
new file mode 100644
index ..44c3b5bd2275
--- /dev/null
+++ b/meta/conf/machine/include/arm/arch-armv8-5a.inc
@@ -0,0 +1,19 @@
+DEFAULTTUNE ?= "armv8-5a"
+
+TUNEVALID[armv8-5a] = "Enable instructions for ARMv8.5-a"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a', ' 
-march=armv8.5-a', '', d)}"
+# TUNE crypto will be handled by arch-armv8a.inc below
+MACHINEOVERRIDES =. "${@bb.utils.contains('TUNE_FEATURES', 'armv8-5a', 
'armv8-5a:', '', d)}"
+
+require conf/machine/include/arm/arch-armv8a.inc
+
+# Little Endian base configs
+AVAILTUNES += "armv8-5a armv8-5a-crypto"
+ARMPKGARCH_tune-armv8-5a?= "armv8-5a"
+ARMPKGARCH_tune-armv8-5a-crypto ?= "armv8-5a"
+TUNE_FEATURES_tune-armv8-5a  = "aarch64 armv8-5a"
+TUNE_FEATURES_tune-armv8-5a-crypto   = "${TUNE_FEATURES_tune-armv8-5a} 
crypto"
+PACKAGE_EXTRA_ARCHS_tune-armv8-5a= 
"${PACKAGE_EXTRA_ARCHS_tune-armv8a} armv8-5a"
+PACKAGE_EXTRA_ARCHS_tune-armv8-5a-crypto = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a} armv8-5a-crypto"
+BASE_LIB_tune-armv8-5a   = "lib64"
+BASE_LIB_tune-armv8-5a-crypto= "lib64"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160594): 
https://lists.openembedded.org/g/openembedded-core/message/160594
Mute This Topic: https://lists.openembedded.org/mt/88436042/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott 2/2] armv9a/tune: Add the support for the Neoverse N2 core

[Kevin Hao]

This adds the support for the Neoverse N2 core, even though the
Neoverse N2 core implements the Arm v9.0-A architecture, but the support
of it in GCC is based on the Arm v8.5-A architecture. Please see the
commit 50d9db203bc3 ("aarch64: Add support for Neoverse N2 CPU") in GCC
for more detail.

(From OE-Core rev: 37597397f03b6b0082a702147dc536ff8b2fa7a3)

Signed-off-by: Kevin Hao 
Signed-off-by: Richard Purdie 
[Kevin: Convert to the old style override syntax]
Signed-off-by: Kevin Hao 
---
 .../include/arm/armv9a/tune-neoversen2.inc| 22 +++
 1 file changed, 22 insertions(+)
 create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc

diff --git a/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc 
b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
new file mode 100644
index ..dedabcf46e23
--- /dev/null
+++ b/meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc
@@ -0,0 +1,22 @@
+#
+# Tune Settings for Neoverse-N2
+#
+DEFAULTTUNE ?= "neoversen2"
+
+TUNEVALID[neoversen2] = "Enable Neoverse-N2 specific processor optimizations"
+TUNE_CCARGS .= "${@bb.utils.contains('TUNE_FEATURES', 'neoversen2', ' 
-mcpu=neoverse-n2', '', d)}"
+
+# Even though the Neoverse N2 core implemnts the Arm v9.0-A architecture,
+# but the support of it in GCC is based on the Arm v8.5-A architecture.
+require conf/machine/include/arm/arch-armv8-5a.inc
+
+# Little Endian base configs
+AVAILTUNES += "neoversen2 
neoversen2-crypto"
+ARMPKGARCH_tune-neoversen2  = "neoversen2"
+ARMPKGARCH_tune-neoversen2-crypto   = "neoversen2-crypto"
+TUNE_FEATURES_tune-neoversen2   = 
"${TUNE_FEATURES_tune-armv8-5a} neoversen2"
+TUNE_FEATURES_tune-neoversen2-crypto= 
"${TUNE_FEATURES_tune-neoversen2} crypto"
+PACKAGE_EXTRA_ARCHS_tune-neoversen2 = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a} neoversen2"
+PACKAGE_EXTRA_ARCHS_tune-neoversen2-crypto  = 
"${PACKAGE_EXTRA_ARCHS_tune-armv8-5a-crypto} neoversen2 neoversen2-crypto"
+BASE_LIB_tune-neoversen2= "lib64"
+BASE_LIB_tune-neoversen2-crypto = "lib64"
-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160595): 
https://lists.openembedded.org/g/openembedded-core/message/160595
Mute This Topic: https://lists.openembedded.org/mt/88436043/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [hardknott 0/2] Add tune for Neoverse N2 core

[Kevin Hao]

Hi,

The gcc patches for the Neoverse N2 core have been merged into hardknott
branch, this patch series backport two patches from the master branch to
add the corresponding tune files.

Kevin Hao (2):
  arch-armv8-5a.inc: Add tune include for armv8.5a
  armv9a/tune: Add the support for the Neoverse N2 core

 .../machine/include/arm/arch-armv8-5a.inc | 19 
 .../include/arm/armv9a/tune-neoversen2.inc| 22 +++
 2 files changed, 41 insertions(+)
 create mode 100644 meta/conf/machine/include/arm/arch-armv8-5a.inc
 create mode 100644 meta/conf/machine/include/arm/armv9a/tune-neoversen2.inc

-- 
2.31.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160593): 
https://lists.openembedded.org/g/openembedded-core/message/160593
Mute This Topic: https://lists.openembedded.org/mt/88436041/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [PATCH 1/2] kernel: Rework kernel make flag to variable mappings

[Paul Barker]

On 14/10/2021 21:26, Richard Purdie wrote:

In 2017 we added changes to pass the BUILD_CFLAGS into the kernel
via BUILD_CC. This isn't really correct and the upstream kernel now has
places to pass build cflags, ldflags and more. Update our kernel
make flags to correctly use the kernel's variables. This addresses
concerns raised by kernel developers.

If this breaks some usecase please report it so we can work out how
to fix it properly.


FYI, this change back in Oct broke the build for Linux 5.10.y, 5.4.y, 
4.19.y & 4.4.y kernels where CONFIG_UNWINDER_ORC=y (which is set by the 
in-tree defconfig for x86-64). The build failures sat on my backburner 
for a long time due to other commitments but I finally tracked them down 
to this commit and looked for solutions.


For 5.10.y, 5.4.y & 4.19.y there is an upstream kernel patch which can 
be backported which will address this. See 
https://lore.kernel.org/stable/04598430-7383-b725-2f5f-3f2b16aac...@sancloud.com/ 
and replies for more info. Hopefully these branches will be fixed with 
the next round of stable kernel releases now the backport has been 
requested.


For 4.14.y there is no trivial fix upstream. The backport I did for the 
other branches depends on the KBUILD_HOSTLDFLAGS variable being set in 
the kernel Makefile which was added after 4.14.y. Personally, I'm happy 
to leave 4.14.y broken in this case and workaround the issue in 
meta-linux-mainline by disabling CONFIG_UNWINDER_ORC for this series.


I don't think any changes are needed in oe-core, the info is now here in 
case it affects others though.


Thanks,

--
Paul Barker
Principal Software Engineer
SanCloud Ltd

e: paul.bar...@sancloud.com
w: https://sancloud.co.uk/

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160569): 
https://lists.openembedded.org/g/openembedded-core/message/160569
Mute This Topic: https://lists.openembedded.org/mt/86324180/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [rust] error: the crate panic_abort does not have the panic strategy abort

[Alexander Kanavin]

Perhaps you could look at how this is handled in mozjs recipe in meta-oe, I
vaguely remember it forces panic strategy to something incompatible and I
patched it to match..

Alex

On Fri, 14 Jan 2022 at 15:21, Francesco Pham 
wrote:

> Hi,
> the following error appears when trying to build a simple rust hello
> world that uses panic set to abort mode.
>
> > | DEBUG: Executing shell function do_compile
> > | NOTE: cargo =
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot-native/usr/bin/cargo
> > | NOTE: rustc =
> > | NOTE: cargo build -v --target x86_64-poky-linux --release
> --manifest-path=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/git//Cargo.toml
> > |Compiling rust-hello-world v0.0.1
> (/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/git)
> > | Building [ ] 0/1: rust-hello-world(bin)
> > |  Running `rustc --crate-name rust_hello_world --edition=2018 src/
> main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type
> bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C
> metadata=38cc6f415494c65c -C extra-filename=-38cc6f415494c65c --out-dir
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
> --target x86_64-poky-linux -C
> linker=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/wrapper/target-rust-ccld
> -L
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
> -L
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/release/deps
> -L
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot/usr/lib/rust
> --remap-path-prefix=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0=/usr/src/debug/rust-panic-test/git-r0`
> > | error: the crate `panic_abort` does not have the panic strategy `abort`
> > |
> > | error: aborting due to previous error
> > |
> > | error: could not compile `rust-hello-world`
> > |
> > | Caused by:
> > |   process didn't exit successfully: `rustc --crate-name
> rust_hello_world --edition=2018 src/main.rs --error-format=json
> --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C
> opt-level=3 -C panic=abort -C lto -C metadata=38cc6f415494c65c -C
> extra-filename=-38cc6f415494c65c --out-dir
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
> --target x86_64-poky-linux -C
> linker=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/wrapper/target-rust-ccld
> -L
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
> -L
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/release/deps
> -L
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot/usr/lib/rust
> --remap-path-prefix=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0=/usr/src/debug/rust-panic-test/git-r0`
> (exit status: 1)
> > | WARNING: exit code 101 from a shell command.
>
> A similar error also appears when the panic strategy is set to unwind
> The recipe, generated using cargo bitbake, is as follows:
>
> > inherit cargo
> > SRC_URI += "git://
> g...@github.com/frankplus/rust-hello-world.git;protocol=https;branch=master
> "
> > SRCREV = "68b7f7ee7df6e08a0411ba7157761145c43baf5d"
> > S = "${WORKDIR}/git"
> > SUMMARY = "rust-hello-world"
> > HOMEPAGE = "https://github.com/frankplus/rust-hello-world;
> > LICENSE = "MIT | Apache-2.0"
> > LIC_FILES_CHKSUM =
> "file://COPYRIGHT;md5=e6b2207ac3740d2d01141c49208c2147"
>
> Version: honister @ f286eef, master @ f9f3e1
> Component: meta/recipes-devtools/rust
> Relate-to: https://github.com/meta-rust/meta-rust/issues/343
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160570): 
https://lists.openembedded.org/g/openembedded-core/message/160570
Mute This Topic: https://lists.openembedded.org/mt/88421290/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [dunfell PATCH] kernel: introduce python3-dtschema-wrapper

[Paul Barker]

From: Bruce Ashfield 

The 5.16 kernel introduced mandatory schema checking on any dtb file
built through the kernel.

That funcionality is provided via python3-dt-schema.

The dependencies to enable that functionality is not small, and may
not always be desired (in particular on architectures that do not
support dtbs, or in development cycles). It may also be useful for
allowing a non-conformant dts to be compiled.

This commit introduces a set of wrapper scripts that when added
as a depenency to the kernel, can pass both the validation testing
and validation steps of a dts.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 

Backported from oe-core commit 2566563ad49d.
Signed-off-by: Paul Barker 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../python3-dtschema-wrapper/dt-doc-validate  | 20 +++
 .../dtc/python3-dtschema-wrapper/dt-mk-schema | 20 +++
 .../dtc/python3-dtschema-wrapper/dt-validate  | 20 +++
 .../dtc/python3-dtschema-wrapper_2021.10.bb   | 17 
 5 files changed, 78 insertions(+)
 create mode 100644 
meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-doc-validate
 create mode 100644 
meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
 create mode 100644 meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
 create mode 100644 meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index 895cf894872b..1575fce8c715 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -576,6 +576,7 @@ RECIPE_MAINTAINER_pn-python3 = "Oleksandr Kravchuk 

+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-doc-validate.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
new file mode 100644
index ..24b89d861982
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
@@ -0,0 +1,20 @@
+#!/bin/sh
+# dt-mk-schema wrapper to allow kernel dt-validation to pass
+#
+# Copyright (C) 2021 Bruce Ashfield 
+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-mk-schema.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
new file mode 100644
index ..8a4710a7eda1
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
@@ -0,0 +1,20 @@
+#!/bin/sh
+# dt-validate wrapper to allow kernel dt-validation to pass
+#
+# Copyright (C) 2021 Bruce Ashfield 
+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-validate.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb
new file mode 100644
index ..c869274d09fa
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "Wrapper for tooling for devicetree validation using YAML and 
jsonschema"
+HOMEPAGE = "https://yoctoproject.org;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = "file://dt-doc-validate \
+   file://dt-mk-schema \
+   file://dt-validate"
+
+do_install() {
+install -d ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-doc-validate ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-mk-schema ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-validate ${D}${bindir}/
+}
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160567): 
https://lists.openembedded.org/g/openembedded-core/message/160567
Mute This Topic: https://lists.openembedded.org/mt/88420183/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [rust] error: the crate panic_abort does not have the panic strategy abort

[Francesco Pham]

Hi,
the following error appears when trying to build a simple rust hello
world that uses panic set to abort mode.

> | DEBUG: Executing shell function do_compile
> | NOTE: cargo = 
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot-native/usr/bin/cargo
> | NOTE: rustc =
> | NOTE: cargo build -v --target x86_64-poky-linux --release 
> --manifest-path=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/git//Cargo.toml
> |Compiling rust-hello-world v0.0.1 
> (/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/git)
> | Building [ ] 0/1: rust-hello-world(bin)
> |  Running `rustc --crate-name rust_hello_world --edition=2018 
> src/main.rs --error-format=json --json=diagnostic-rendered-ansi --crate-type 
> bin --emit=dep-info,link -C opt-level=3 -C panic=abort -C lto -C 
> metadata=38cc6f415494c65c -C extra-filename=-38cc6f415494c65c --out-dir 
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
>  --target x86_64-poky-linux -C 
> linker=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/wrapper/target-rust-ccld
>  -L 
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
>  -L 
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/release/deps
>  -L 
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot/usr/lib/rust
>  
> --remap-path-prefix=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0=/usr/src/debug/rust-panic-test/git-r0`
> | error: the crate `panic_abort` does not have the panic strategy `abort`
> |
> | error: aborting due to previous error
> |
> | error: could not compile `rust-hello-world`
> |
> | Caused by:
> |   process didn't exit successfully: `rustc --crate-name rust_hello_world 
> --edition=2018 src/main.rs --error-format=json 
> --json=diagnostic-rendered-ansi --crate-type bin --emit=dep-info,link -C 
> opt-level=3 -C panic=abort -C lto -C metadata=38cc6f415494c65c -C 
> extra-filename=-38cc6f415494c65c --out-dir 
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
>  --target x86_64-poky-linux -C 
> linker=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/wrapper/target-rust-ccld
>  -L 
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/x86_64-poky-linux/release/deps
>  -L 
> dependency=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/build/target/release/deps
>  -L 
> /home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0/recipe-sysroot/usr/lib/rust
>  
> --remap-path-prefix=/home/francesco/Desktop/poky/build/tmp/work/core2-64-poky-linux/rust-panic-test/git-r0=/usr/src/debug/rust-panic-test/git-r0`
>  (exit status: 1)
> | WARNING: exit code 101 from a shell command.

A similar error also appears when the panic strategy is set to unwind
The recipe, generated using cargo bitbake, is as follows:

> inherit cargo
> SRC_URI += 
> "git://g...@github.com/frankplus/rust-hello-world.git;protocol=https;branch=master"
> SRCREV = "68b7f7ee7df6e08a0411ba7157761145c43baf5d"
> S = "${WORKDIR}/git"
> SUMMARY = "rust-hello-world"
> HOMEPAGE = "https://github.com/frankplus/rust-hello-world;
> LICENSE = "MIT | Apache-2.0"
> LIC_FILES_CHKSUM = "file://COPYRIGHT;md5=e6b2207ac3740d2d01141c49208c2147"

Version: honister @ f286eef, master @ f9f3e1
Component: meta/recipes-devtools/rust
Relate-to: https://github.com/meta-rust/meta-rust/issues/343

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160568): 
https://lists.openembedded.org/g/openembedded-core/message/160568
Mute This Topic: https://lists.openembedded.org/mt/88421290/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [yocto] [OE-core] Question of Yocto dunfell LTS period

[Zoltan Boszormenyi via lists.openembedded.org]

Funny you mention PR.

It would also help if recipes staying on the same version
but adding patches for e.g. CVE fixes should increase their
PR value so their rebuilt versions can be put into a package repo.

Throwing away the buildroot (as suggested any time some obscure
build error happens) and restarting a complete image build
resets the autopr value so the repo would contain packages with
the same r0.0 release string and the package manager doesn't know
that the package is newer.

2022. 01. 14. 10:42 keltezéssel, Alexander Kanavin írta:
Actually, I think this was some kind of missed PR opportunity. Regular distros, such as 
RHEL, Debian and everyone else, are constantly trotting out their support windows as the 
reason to hand them the job of making products, so we could counter that better perhaps.


Alex

On Fri, 14 Jan 2022 at 06:28, Michael Opdenacker > wrote:



On 1/14/22 2:36 AM, Jate Sujjavanich wrote:
 > I received the answer to this question in IRC on 10/29/2021.
 >
 > 16:06
 > > 
 > I saw a wiki edit that said dunfell's LTS period is now through April
 > 2024, but I've seen no announcements. Any truth to this rumor?
 > 16:20
 > > 
 > jatedev: it was announced on one of the technical calls a few weeks
 > back, so yes AFAIK
 > 16:25
 > > 
 > jatedev: definitely true. I wish we could sort out the project
 > advocacy side of things :(
 >
 > Let this email serve as a little advocacy.


I believe this would also help if the website (releases page) and/or
official documentation carried such information.
Thanks for raising this concern!
Cheers
Michael.

-- 
Michael Opdenacker, Bootlin

Embedded Linux and Kernel engineering
https://bootlin.com 











-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160563): 
https://lists.openembedded.org/g/openembedded-core/message/160563
Mute This Topic: https://lists.openembedded.org/mt/88415300/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core][PATCH 0/4] Move crate fetcher to OE_IMPORTS

[Richard Purdie]

On Fri, 2022-01-14 at 02:31 -0800, Matt Madison wrote:
> On Tue, Dec 21, 2021 at 10:15 AM Matt Madison via
> lists.openembedded.org 
> wrote:
> > 
> > On Tue, Dec 21, 2021 at 6:07 AM Paul Barker  
> > wrote:
> > > 
> > > On 20/12/2021 22:34, Richard Purdie wrote:
> > > > On Mon, 2021-12-20 at 17:01 +, Paul Barker wrote:
> > > > > On 17/12/2021 15:36, Matt Madison wrote:
> > > > > > This patch series switches to using the OE_IMPORTS mechanism
> > > > > > for installing the crate fetcher. This simplifies the addition
> > > > > > and clears up issues with interactions between SRCPV and
> > > > > > the shared-state fetching logic.
> > > > > > 
> > > > > > Matt Madison (4):
> > > > > > lib/crate.py: install crate fetcher on import
> > > > > > base.bbclass: add crate to OE_IMPORTS
> > > > > > cargo_common.bbclass: remove inherit of crate-fetch
> > > > > > classes: remove crate-fetch.bbclass
> > > > > > 
> > > > > >meta/classes/base.bbclass |  2 +-
> > > > > >meta/classes/cargo_common.bbclass |  2 --
> > > > > >meta/classes/crate-fetch.bbclass  | 28 
> > > > > > 
> > > > > >meta/lib/crate.py |  2 ++
> > > > > >4 files changed, 3 insertions(+), 31 deletions(-)
> > > > > >delete mode 100644 meta/classes/crate-fetch.bbclass
> > > > > > 
> > > > > 
> > > > > Would a better solution here be to move the crate fetcher into
> > > > > lib/bb/fetch2/ in bitbake?
> > > > 
> > > > I've been wondering about this too.
> > > > 
> > > > Does anyone remember how the fetcher lines up against the general 
> > > > fetcher
> > > > requirements we have and is there a list of anything that remained to 
> > > > be done
> > > > before it could be added to bitbake?
> > > 
> > > If I remember correctly, it just needed some test cases writing. The
> > > crate fetcher is a subclass of the wget fetcher with changes to how
> > > urldata is set up and how unpack is handled, so it should integrate well
> > > into bitbake.
> > 
> > One thing I see that's a bit worrisome is that it disables
> > recommends_checksum for the downloaded files,
> > and populates metadata for use (I assume) by cargo with the calculated
> > SHA256 on the download.
> 
> Any other thoughts on this?  I've modified my distro to work around
> the problem that led me to propose these patches, but something needs
> to be fixed here. crate-fetch.bbclass should not be setting SRCPV.

My thoughts are that we should look to getting this merged into bitbake. To do
that we need some tests and then we can probably make it happen.

I am worried about your comments on the checksum and that may be something we
need to fix before it can be merged.

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160565): 
https://lists.openembedded.org/g/openembedded-core/message/160565
Mute This Topic: https://lists.openembedded.org/mt/87791267/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

Re: [OE-core] [yocto] Question of Yocto dunfell LTS period

[Richard Purdie]

On Fri, 2022-01-14 at 07:14 +, Matthias Klein wrote:
> Hello together,
> 
> I would like to add a question to the topic:
> 
> Why was the LTS period for dunfell extended?
> Can we expect the same for kirstone?

The project members agreed to fun an extension to the lifetime of dunfell from 2
years to 4 years. There should have been some announcements about this but we
lack people on the advocacy side of the project with time to make that happen.
That saddens me a lot and I think it is a missed opportunity but there isn't
much I can do about it beyond what I've already tried.

Extending Dunfell is an experiment so we would base a decision on how well the
dunfell extension is working out. Extending an LTS like this requires a
financial commitment from the project. At this point in time the project cannot
commit to extending kirkstone as we can't guarantee the finances. 

Cheers,

Richard




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160564): 
https://lists.openembedded.org/g/openembedded-core/message/160564
Mute This Topic: https://lists.openembedded.org/mt/88419884/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-

[OE-core] [honister PATCH] kernel: introduce python3-dtschema-wrapper

[Paul Barker]

From: Bruce Ashfield 

The 5.16 kernel introduced mandatory schema checking on any dtb file
built through the kernel.

That funcionality is provided via python3-dt-schema.

The dependencies to enable that functionality is not small, and may
not always be desired (in particular on architectures that do not
support dtbs, or in development cycles). It may also be useful for
allowing a non-conformant dts to be compiled.

This commit introduces a set of wrapper scripts that when added
as a depenency to the kernel, can pass both the validation testing
and validation steps of a dts.

Signed-off-by: Bruce Ashfield 
Signed-off-by: Richard Purdie 

Backported from oe-core commit 2566563ad49d.
Signed-off-by: Paul Barker 
---
 meta/conf/distro/include/maintainers.inc  |  1 +
 .../python3-dtschema-wrapper/dt-doc-validate  | 20 +++
 .../dtc/python3-dtschema-wrapper/dt-mk-schema | 20 +++
 .../dtc/python3-dtschema-wrapper/dt-validate  | 20 +++
 .../dtc/python3-dtschema-wrapper_2021.10.bb   | 17 
 5 files changed, 78 insertions(+)
 create mode 100644 
meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-doc-validate
 create mode 100644 
meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
 create mode 100644 meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
 create mode 100644 meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index b3b7711a0c48..2b54d2d12f9b 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -592,6 +592,7 @@ RECIPE_MAINTAINER:pn-python3-cython = "Oleksandr Kravchuk 

+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-doc-validate.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
new file mode 100644
index ..24b89d861982
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-mk-schema
@@ -0,0 +1,20 @@
+#!/bin/sh
+# dt-mk-schema wrapper to allow kernel dt-validation to pass
+#
+# Copyright (C) 2021 Bruce Ashfield 
+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-mk-schema.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
new file mode 100644
index ..8a4710a7eda1
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper/dt-validate
@@ -0,0 +1,20 @@
+#!/bin/sh
+# dt-validate wrapper to allow kernel dt-validation to pass
+#
+# Copyright (C) 2021 Bruce Ashfield 
+# License: MIT (see COPYING.MIT at the root of the repository for terms)
+
+for arg; do
+case "$arg" in
+--version)
+echo "v2021.10"
+;;
+esac
+done
+
+# TBD: left for future consideration
+# exec dt-validate.real "$@"
+
+# we always succeed
+exit 0
+
diff --git a/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb 
b/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb
new file mode 100644
index ..c869274d09fa
--- /dev/null
+++ b/meta/recipes-kernel/dtc/python3-dtschema-wrapper_2021.10.bb
@@ -0,0 +1,17 @@
+DESCRIPTION = "Wrapper for tooling for devicetree validation using YAML and 
jsonschema"
+HOMEPAGE = "https://yoctoproject.org;
+LICENSE = "MIT"
+LIC_FILES_CHKSUM = 
"file://${COREBASE}/meta/COPYING.MIT;md5=3da9cfbcb788c80a0384361b4de20420"
+
+SRC_URI = "file://dt-doc-validate \
+   file://dt-mk-schema \
+   file://dt-validate"
+
+do_install() {
+install -d ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-doc-validate ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-mk-schema ${D}${bindir}/
+install -m 755 ${WORKDIR}/dt-validate ${D}${bindir}/
+}
+
+BBCLASSEXTEND = "native nativesdk"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#160566): 
https://lists.openembedded.org/g/openembedded-core/message/160566
Mute This Topic: https://lists.openembedded.org/mt/88420169/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-