Re: [OE-core][PATCH] meta/recipes-bsp: Add recipe for Slim Bootloader

[Yongxin Liu]

> -Original Message-
> From: Konrad Weihmann 
> Sent: Wednesday, December 15, 2021 15:35
> To: Liu, Yongxin ; openembedded-
> c...@lists.openembedded.org; richard.pur...@linuxfoundation.org
> Subject: Re: [OE-core][PATCH] meta/recipes-bsp: Add recipe for Slim
> Bootloader
>  
> On 15.12.21 08:16, Yongxin Liu wrote:
> > Slim Bootloader is an open-source boot firmware running on Intel x86
> > architecture.
> >
> > Currently it supports qemu, apl(Apollo Lake), cfl(Coffee Lake),
> > cml(Comet Lake), tgl(Tiger Lake), and ehl(Elkhart Lake). You can set
> > "SLIMBOOT_TARGET" in .bb file or .bbappend file to specify or add the
> > target firmware you want, for example: SLIMBOOT_TARGET = "qemu apl".
> > The default target is qemu.
> >
> > Generated firmware and security keys are installed in build directory:
> >  image
> >  `-- usr
> >  `-- libexec
> >  `-- slimboot
> >  |-- Outputs
> >  |   |-- qemu
> >  |   |-- apl
> >  |   `-- cfl
> >  `-- keys
> >
> > Boot firmware for qemu can be used by command:
> > "qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash
> SlimBootloader.bin"
> >
> > Other boot firmware for real hardware cannot be programmed directly to
> > flash, please refer to https://slimbootloader.github.io/index.html for
> > more instructions.
> >
> > Signed-off-by: Yongxin Liu 
> > ---
> >   ...d-private-key-check-for-PKCS8-format.patch | 28 
> >   .../build-EDK2-BaseTools-with-bitbake.patch   | 70 +++
> >   ...limbootloader-BaseTools-with-bitbake.patch | 42 +++
> >   meta/recipes-bsp/slimboot/slimboot_git.bb | 57 +++
> >   4 files changed, 197 insertions(+)
> >   create mode 100644 meta/recipes-bsp/slimboot/files/add-private-key-
> check-for-PKCS8-format.patch
> >   create mode 100644 meta/recipes-bsp/slimboot/files/build-EDK2-
> BaseTools-with-bitbake.patch
> >   create mode 100644 meta/recipes-bsp/slimboot/files/build-
> slimbootloader-BaseTools-with-bitbake.patch
> >   create mode 100644 meta/recipes-bsp/slimboot/slimboot_git.bb
> >
> > diff --git
> > a/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-form
> > at.patch
> > b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-form
> > at.patch
> > new file mode 100644
> > index 00..a7e9d96dfb
> > --- /dev/null
> > +++ b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-
> > +++ format.patch
> > @@ -0,0 +1,28 @@
> > +From e31e9b34f5ffccaab3788da781e05a0622cf7d45 Mon Sep 17 00:00:00
> > +2001
> > +From: Yongxin Liu 
> > +Date: Tue, 7 Dec 2021 16:18:43 +
> > +Subject: [PATCH] add private key check for PKCS8 format
> > +
> > +Upstream-Status: Pending
> 
> Pending patches are discouraged, please send them upstream

Will do.


> 
> > +
> > +Signed-off-by: Yongxin Liu 
> > +---
> > + BootloaderCorePkg/Tools/SingleSign.py | 2 +-
> > + 1 file changed, 1 insertion(+), 1 deletion(-)
> > +
> > +diff --git a/BootloaderCorePkg/Tools/SingleSign.py
> > +b/BootloaderCorePkg/Tools/SingleSign.py
> > +index 2a550bf8..5baacbde 100644
> > +--- a/BootloaderCorePkg/Tools/SingleSign.py
> >  b/BootloaderCorePkg/Tools/SingleSign.py
> > +@@ -259,7 +259,7 @@ def single_sign_gen_pub_key (in_key, pub_key_file =
> None):
> > + cmdline = [get_openssl_path(), 'rsa', '-pubout', '-text', '-noout',
> '-in', '%s' % in_key]
> > + # Check if it is public key or private key
> > + text = open(in_key, 'r').read()
> > +-if '-BEGIN RSA PRIVATE KEY-' in text:
> > ++if '-BEGIN RSA PRIVATE KEY-' in text or '-BEGIN PRIVATE KEY-' in
> text:
> > + is_prv_key = True
> > + elif '-BEGIN PUBLIC KEY-' in text:
> > + cmdline.extend (['-pubin'])
> > +--
> > +2.33.0
> > +
> > diff --git
> > a/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.pa
> > tch
> > b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.pa
> > tch
> > new file mode 100644
> > index 00..3b9db74491
> > --- /dev/null
> > +++ b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbak
> > +++ e.patch
> > @@ -0,0 +1,70 @@
> > +From ce5ed81d9dd9c37e494560edb8f0fbae83713416 Mon Sep 17 00:00:00
> > +2001
> > +From: Yongxin Liu 
> > +Date: Wed, 15 Dec 2021 02:19:42 +
> > +Subject: [PATCH] build EDK2/BaseTools with bitbake
> > +
> > +EDK2 basetools are needed by QEMU FSP. Due to CRLF line terminators
> > +in target file, the patch has to be set to binary format.
> > +
> > +Upstream-Status: Inappropriate [oe-core specific]
> 
> Why is this oe-specific, I'm missing a proper explanation in the commit
> message

This patch is used for using bitbake only to use proper include and library
directories in recipe-sysroot-native. It is not needed if building on host 
directly.

> > +
> > +Signed-off-by: Yongxin Liu 
> > +---
> > + .gitattributes   |   1 +
> > + .../Tools/PrepareBuildComponentBin.py  

Re: [OE-core][PATCH] meta/recipes-bsp: Add recipe for Slim Bootloader

[Konrad Weihmann]

On 15.12.21 08:16, Yongxin Liu wrote:

Slim Bootloader is an open-source boot firmware running on Intel x86
architecture.

Currently it supports qemu, apl(Apollo Lake), cfl(Coffee Lake),
cml(Comet Lake), tgl(Tiger Lake), and ehl(Elkhart Lake). You can set
"SLIMBOOT_TARGET" in .bb file or .bbappend file to specify or add the
target firmware you want, for example: SLIMBOOT_TARGET = "qemu apl".
The default target is qemu.

Generated firmware and security keys are installed in build directory:
 image
 `-- usr
 `-- libexec
 `-- slimboot
 |-- Outputs
 |   |-- qemu
 |   |-- apl
 |   `-- cfl
 `-- keys

Boot firmware for qemu can be used by command:
"qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash 
SlimBootloader.bin"

Other boot firmware for real hardware cannot be programmed directly to
flash, please refer to https://slimbootloader.github.io/index.html for
more instructions.

Signed-off-by: Yongxin Liu 
---
  ...d-private-key-check-for-PKCS8-format.patch | 28 
  .../build-EDK2-BaseTools-with-bitbake.patch   | 70 +++
  ...limbootloader-BaseTools-with-bitbake.patch | 42 +++
  meta/recipes-bsp/slimboot/slimboot_git.bb | 57 +++
  4 files changed, 197 insertions(+)
  create mode 100644 
meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
  create mode 100644 
meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
  create mode 100644 
meta/recipes-bsp/slimboot/files/build-slimbootloader-BaseTools-with-bitbake.patch
  create mode 100644 meta/recipes-bsp/slimboot/slimboot_git.bb

diff --git 
a/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch 
b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
new file mode 100644
index 00..a7e9d96dfb
--- /dev/null
+++ 
b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
@@ -0,0 +1,28 @@
+From e31e9b34f5ffccaab3788da781e05a0622cf7d45 Mon Sep 17 00:00:00 2001
+From: Yongxin Liu 
+Date: Tue, 7 Dec 2021 16:18:43 +
+Subject: [PATCH] add private key check for PKCS8 format
+
+Upstream-Status: Pending


Pending patches are discouraged, please send them upstream


+
+Signed-off-by: Yongxin Liu 
+---
+ BootloaderCorePkg/Tools/SingleSign.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/BootloaderCorePkg/Tools/SingleSign.py 
b/BootloaderCorePkg/Tools/SingleSign.py
+index 2a550bf8..5baacbde 100644
+--- a/BootloaderCorePkg/Tools/SingleSign.py
 b/BootloaderCorePkg/Tools/SingleSign.py
+@@ -259,7 +259,7 @@ def single_sign_gen_pub_key (in_key, pub_key_file = None):
+ cmdline = [get_openssl_path(), 'rsa', '-pubout', '-text', '-noout', 
'-in', '%s' % in_key]
+ # Check if it is public key or private key
+ text = open(in_key, 'r').read()
+-if '-BEGIN RSA PRIVATE KEY-' in text:
++if '-BEGIN RSA PRIVATE KEY-' in text or '-BEGIN PRIVATE KEY-' in text:
+ is_prv_key = True
+ elif '-BEGIN PUBLIC KEY-' in text:
+ cmdline.extend (['-pubin'])
+--
+2.33.0
+
diff --git 
a/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch 
b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
new file mode 100644
index 00..3b9db74491
--- /dev/null
+++ b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
@@ -0,0 +1,70 @@
+From ce5ed81d9dd9c37e494560edb8f0fbae83713416 Mon Sep 17 00:00:00 2001
+From: Yongxin Liu 
+Date: Wed, 15 Dec 2021 02:19:42 +
+Subject: [PATCH] build EDK2/BaseTools with bitbake
+
+EDK2 basetools are needed by QEMU FSP. Due to CRLF line terminators
+in target file, the patch has to be set to binary format.
+
+Upstream-Status: Inappropriate [oe-core specific]


Why is this oe-specific, I'm missing a proper explanation in the commit 
message



+
+Signed-off-by: Yongxin Liu 
+---
+ .gitattributes   |   1 +
+ .../Tools/PrepareBuildComponentBin.py|   6 ++
+ .../build-edk2-BaseTools-with-bitbake.patch  | Bin 0 -> 1375 bytes
+ 3 files changed, 7 insertions(+)
+ create mode 100644 
Silicon/QemuSocPkg/FspBin/Patches/build-edk2-BaseTools-with-bitbake.patch
+
+diff --git a/.gitattributes b/.gitattributes
+index e372c4d9..d31d5dbb 100644
+--- a/.gitattributes
 b/.gitattributes
+@@ -17,3 +17,4 @@
+ # since the files that are being patched have a mixture of line
+ # endings. This means it must be treated as binary.
+ Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch 
binary
++Silicon/QemuSocPkg/FspBin/Patches/build-edk2-BaseTools-with-bitbake.patch 
binary
+diff --git a/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py 
b/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py
+index 50f24736..2cd2f5d5 100644
+--- a/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py
 

[OE-core][PATCH] meta/recipes-bsp: Add recipe for Slim Bootloader

[Yongxin Liu]

Slim Bootloader is an open-source boot firmware running on Intel x86
architecture.

Currently it supports qemu, apl(Apollo Lake), cfl(Coffee Lake),
cml(Comet Lake), tgl(Tiger Lake), and ehl(Elkhart Lake). You can set
"SLIMBOOT_TARGET" in .bb file or .bbappend file to specify or add the
target firmware you want, for example: SLIMBOOT_TARGET = "qemu apl".
The default target is qemu.

Generated firmware and security keys are installed in build directory:
image
`-- usr
`-- libexec
`-- slimboot
|-- Outputs
|   |-- qemu
|   |-- apl
|   `-- cfl
`-- keys

Boot firmware for qemu can be used by command:
"qemu-system-x86_64 -machine q35 -nographic -serial mon:stdio -pflash 
SlimBootloader.bin"

Other boot firmware for real hardware cannot be programmed directly to
flash, please refer to https://slimbootloader.github.io/index.html for
more instructions.

Signed-off-by: Yongxin Liu 
---
 ...d-private-key-check-for-PKCS8-format.patch | 28 
 .../build-EDK2-BaseTools-with-bitbake.patch   | 70 +++
 ...limbootloader-BaseTools-with-bitbake.patch | 42 +++
 meta/recipes-bsp/slimboot/slimboot_git.bb | 57 +++
 4 files changed, 197 insertions(+)
 create mode 100644 
meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
 create mode 100644 
meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
 create mode 100644 
meta/recipes-bsp/slimboot/files/build-slimbootloader-BaseTools-with-bitbake.patch
 create mode 100644 meta/recipes-bsp/slimboot/slimboot_git.bb

diff --git 
a/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch 
b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
new file mode 100644
index 00..a7e9d96dfb
--- /dev/null
+++ 
b/meta/recipes-bsp/slimboot/files/add-private-key-check-for-PKCS8-format.patch
@@ -0,0 +1,28 @@
+From e31e9b34f5ffccaab3788da781e05a0622cf7d45 Mon Sep 17 00:00:00 2001
+From: Yongxin Liu 
+Date: Tue, 7 Dec 2021 16:18:43 +
+Subject: [PATCH] add private key check for PKCS8 format
+
+Upstream-Status: Pending
+
+Signed-off-by: Yongxin Liu 
+---
+ BootloaderCorePkg/Tools/SingleSign.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/BootloaderCorePkg/Tools/SingleSign.py 
b/BootloaderCorePkg/Tools/SingleSign.py
+index 2a550bf8..5baacbde 100644
+--- a/BootloaderCorePkg/Tools/SingleSign.py
 b/BootloaderCorePkg/Tools/SingleSign.py
+@@ -259,7 +259,7 @@ def single_sign_gen_pub_key (in_key, pub_key_file = None):
+ cmdline = [get_openssl_path(), 'rsa', '-pubout', '-text', '-noout', 
'-in', '%s' % in_key]
+ # Check if it is public key or private key
+ text = open(in_key, 'r').read()
+-if '-BEGIN RSA PRIVATE KEY-' in text:
++if '-BEGIN RSA PRIVATE KEY-' in text or '-BEGIN PRIVATE KEY-' in text:
+ is_prv_key = True
+ elif '-BEGIN PUBLIC KEY-' in text:
+ cmdline.extend (['-pubin'])
+-- 
+2.33.0
+
diff --git 
a/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch 
b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
new file mode 100644
index 00..3b9db74491
--- /dev/null
+++ b/meta/recipes-bsp/slimboot/files/build-EDK2-BaseTools-with-bitbake.patch
@@ -0,0 +1,70 @@
+From ce5ed81d9dd9c37e494560edb8f0fbae83713416 Mon Sep 17 00:00:00 2001
+From: Yongxin Liu 
+Date: Wed, 15 Dec 2021 02:19:42 +
+Subject: [PATCH] build EDK2/BaseTools with bitbake
+
+EDK2 basetools are needed by QEMU FSP. Due to CRLF line terminators
+in target file, the patch has to be set to binary format.
+
+Upstream-Status: Inappropriate [oe-core specific]
+
+Signed-off-by: Yongxin Liu 
+---
+ .gitattributes   |   1 +
+ .../Tools/PrepareBuildComponentBin.py|   6 ++
+ .../build-edk2-BaseTools-with-bitbake.patch  | Bin 0 -> 1375 bytes
+ 3 files changed, 7 insertions(+)
+ create mode 100644 
Silicon/QemuSocPkg/FspBin/Patches/build-edk2-BaseTools-with-bitbake.patch
+
+diff --git a/.gitattributes b/.gitattributes
+index e372c4d9..d31d5dbb 100644
+--- a/.gitattributes
 b/.gitattributes
+@@ -17,3 +17,4 @@
+ # since the files that are being patched have a mixture of line
+ # endings. This means it must be treated as binary.
+ Silicon/QemuSocPkg/FspBin/Patches/0001-Build-QEMU-FSP-2.0-binaries.patch 
binary
++Silicon/QemuSocPkg/FspBin/Patches/build-edk2-BaseTools-with-bitbake.patch 
binary
+diff --git a/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py 
b/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py
+index 50f24736..2cd2f5d5 100644
+--- a/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py
 b/BootloaderCorePkg/Tools/PrepareBuildComponentBin.py
+@@ -188,6 +188,12 @@ def BuildFspBins (fsp_dir, sbl_dir, fsp_inf, 
silicon_pkg_name, flag):
+ ret = subprocess.call(cmd.split(' '), cwd=fsp_dir)
+ if ret:
+ Fatal 

[OE-core] [hardknott][PATCH 00/20] Pull request

[Anuj Mittal]

Please merge these changes.

Thanks,

Anuj

The following changes since commit d748ebb61d4dd355265f4a78790b4c30c3ec1a61:

  cups: Fix missing installation of cups sysv init scripts (2021-11-29 13:07:24 
+0800)

are available in the Git repository at:

  git://push.openembedded.org/openembedded-core-contrib stable/hardknott-next

Alexander Kanavin (1):
  libpcre/libpcre2: correct SRC_URI

Anuj Mittal (1):
  python3: upgrade 3.9.7 -> 3.9.9

Bruce Ashfield (2):
  linux-yocto/5.10: update to v5.10.82
  linux-yocto-rt/5.10: update to -rt56

Chen Qi (1):
  patchelf: fix PT_PHDR program header corruption

Dhruva Gole (1):
  scripts/checklayer/common.py: Fixed a minor grammatical error

Pavel Zhukov (1):
  patch.py: Initialize git repo before patching

Quentin Schulz (1):
  README.OE-Core.md: update URLs

Richard Purdie (3):
  buildhistory: Fix srcrevs output
  oeqa/parselogs: Fix quoting
  gcc: Add CVE-2021-37322 to the list of CVEs to ignore

Ross Burton (3):
  recipetool: handle GitLab URLs like we do GitHub
  recipetool: extend curl detection when creating recipes
  runqemu: check the qemu PID has been set before kill()ing it

Schmidt, Adriaan (1):
  wic: support rootdev identified by partition label

Stefan Herbrechtsmeier (2):
  recipetool: Set master branch only as fallback
  selftest/devtool: Check branch in git fetch

Steve Sakoman (1):
  cve-extra-exclusions: add db CVEs to exclusion list

Thomas Perrot (1):
  uboot-sign: fix the concatenation when multiple U-BOOT configurations
are specified

Vyacheslav Yurkov (1):
  rootfs-postcommands: update systemd_create_users

 README.OE-Core| 10 ++--
 meta/classes/buildhistory.bbclass | 30 +---
 meta/classes/rootfs-postcommands.bbclass  |  2 +-
 meta/classes/uboot-sign.bbclass   | 16 ++-
 .../distro/include/cve-extra-exclusions.inc   |  9 
 meta/lib/oe/patch.py  | 16 ++-
 meta/lib/oeqa/runtime/cases/parselogs.py  | 14 +++---
 meta/lib/oeqa/selftest/cases/bbtests.py   | 15 ++
 meta/lib/oeqa/selftest/cases/devtool.py   |  5 +-
 meta/recipes-devtools/gcc/gcc-10.2.inc|  3 ++
 .../patchelf/0001-merge-from-PR243.patch  | 47 +++
 .../patchelf/patchelf_0.12.bb |  1 +
 ...-detection-of-mips-architecture-for-.patch | 20 
 .../{python3_3.9.7.bb => python3_3.9.9.bb}|  2 +-
 .../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 +-
 .../recipes-support/libpcre/libpcre2_10.36.bb |  4 +-
 meta/recipes-support/libpcre/libpcre_8.44.bb  |  2 +-
 scripts/lib/checklayer/cases/common.py|  2 +-
 scripts/lib/recipetool/create.py  | 17 ---
 scripts/lib/recipetool/create_buildsys.py |  3 +-
 scripts/lib/wic/plugins/imager/direct.py  |  2 +
 scripts/runqemu   |  3 +-
 24 files changed, 182 insertions(+), 79 deletions(-)
 create mode 100644 
meta/recipes-devtools/patchelf/patchelf/0001-merge-from-PR243.patch
 rename meta/recipes-devtools/python/{python3_3.9.7.bb => python3_3.9.9.bb} 
(99%)

-- 
2.33.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159712): 
https://lists.openembedded.org/g/openembedded-core/message/159712
Mute This Topic: https://lists.openembedded.org/mt/87739530/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] gcc: Fix CVE-2021-42574

[Pgowda]

Hi,

> this is adding a new warning to help mitigate the problem, this is not
> a gcc CVE per se.
> so perhaps backporting to older branches makes sense, this looks ok

The patch "0001-CVE-2021-42574.patch" is a dependency patch required
for these 3 CVE patches.
It adds 2 MACRO definitions that are present in the CVE patches.
We can just implement those macros and drop the complete patch which
is quite large.
Please let me know if we keep the patches as is or just implement the
macros to make patch smaller?

Thanks,
pgowda

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159711): 
https://lists.openembedded.org/g/openembedded-core/message/159711
Mute This Topic: https://lists.openembedded.org/mt/87718531/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] gcc: Update status of musl stddef.h patch

[Khem Raj]

This patch has been accepted upstream

Signed-off-by: Khem Raj 
---
 .../gcc/gcc/0030-sync-gcc-stddef.h-with-musl.patch  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-devtools/gcc/gcc/0030-sync-gcc-stddef.h-with-musl.patch 
b/meta/recipes-devtools/gcc/gcc/0030-sync-gcc-stddef.h-with-musl.patch
index 86f75d0d51d..fd7d604e988 100644
--- a/meta/recipes-devtools/gcc/gcc/0030-sync-gcc-stddef.h-with-musl.patch
+++ b/meta/recipes-devtools/gcc/gcc/0030-sync-gcc-stddef.h-with-musl.patch
@@ -6,7 +6,7 @@ Subject: [PATCH] sync gcc stddef.h with musl
 musl defines ptrdiff_t size_t and wchar_t
 so dont define them here if musl is definining them
 
-Upstream-Status: Pending
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/?p=gcc.git;a=commit;h=85a438fc78dd12249ca854a3e5c577fefeb1a5cd]
 
 Signed-off-by: Khem Raj 
 ---
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159710): 
https://lists.openembedded.org/g/openembedded-core/message/159710
Mute This Topic: https://lists.openembedded.org/mt/87736342/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] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Konrad Weihmann]

On 14.12.21 21:11, Alexander Kanavin wrote:
What I would like to see at least is correctly tagging patches with dead 
upstreams, now that we have the shiny new status for it, and a report 
where they can be seen clearly :)


The point of that patch is to have everything more machine readable, so 
we can have your requested stats and any stats one can think of :-) - 
and to my understanding that was the whole point of defining these 
metadata entries.


I think we should head down this road, even if the initial amount of 
changes might be quite high - but in the end we might have some pretty 
automated, fancy stats, that will really provide some insights.


If we don't, we might end up in defining more and more new ids for 
different things already covered by the current approach.




Alex

On Tue, 14 Dec 2021 at 19:48, Konrad Weihmann > wrote:




On 14.12.21 19:38, Bruce Ashfield wrote:
 > On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann
mailto:kweihm...@outlook.com>> wrote:
 >>
[snip]

 >>
 >>

meta/recipes-support/vte/vte/0001-Makefile.docs-correctly-substitute-gtkdoc-qemu-wrapp.patch:
 >>     6: Upstream-Status: Inappropriate [oe-core specific]
 >>
 >> or are simply ignoring it at all.
 >>
 >> In total that are 352 patches I could indentify in latest master.
 >>
 >> I don't want to open up another can of worms, but either we drop the
 >> reasoning from Inappropriate in the patch guideline completely or we
 >> need to fix that in core (I guess in other layers it is even
worse :) )
 >>
 >> Any thoughts?
 >
 > If we can opt out of the check either in a layer config or a recipe,
 > then the noise can at least be minimized. Since the ecosystem !=
 > oe-core, this level of checking needs to be something that can be
 > opted-out / disabled.
 >
 > Whatever way this goes, I'd suggest that it not merge until the start
 > of the new year .. luckily RP is in full control of when it merges.
 >
 > Because I for one, won't be spending the Chrismtas holidays queuing
 > other people's patches, or fixing status lines in the patches in my
 > layers :)
 >
 > Cheers,
 >
 > Bruce

Actually a very good idea, but I'm not sure how fine grained we want
these package-qa ids to be... @RP any thoughts?

Basically we can solve the issue either
- by keeping the status quo (dropping the reason from the docu)
- or having is according to docu
         - having it as a warning in the first place
         - turning it into an error once we are clean in core and
all layers
hosted on yocto project's infra

But yeah sure that patch doesn't need to go in this year, as I don't
want to ruins everyone's holidays :-)

 >>
 >> On 14.12.21 18:53, Konrad Weihmann wrote:
 >>> if a patch uses Upstream-Status: Inappropriate it should
provide a machine
 >>> readable reasoning in square brackets.
 >>>
 >>> According to latest wiki entry that would be
 >>>
 >>> not author
 >>> native
 >>> licensing
 >>> configuration
 >>> enable feature
 >>> disable feature
 >>> bugfix .*
 >>> embedded specific
 >>> no upstream
 >>> other
 >>>
 >>> a detailed reasoning could be provided as part of the commit
message,
 >>> but format of the metadata line is fixed.
 >>>
 >>> This patch adds a check to insane.bbclass and warns if there is a
 >>> non-compliant reasoning given, or none at all.
 >>>
 >>> In a follow-up this should be turned into an error, as it was done
 >>> with missing Upstream-Status
 >>>
 >>> Signed-off-by: Konrad Weihmann mailto:kweihm...@outlook.com>>
 >>> ---
 >>>    meta/classes/insane.bbclass | 20 
 >>>    1 file changed, 20 insertions(+)
 >>>
 >>> diff --git a/meta/classes/insane.bbclass
b/meta/classes/insane.bbclass
 >>> index 240f3aad62..da26f4662c 100644
 >>> --- a/meta/classes/insane.bbclass
 >>> +++ b/meta/classes/insane.bbclass
 >>> @@ -1191,6 +1191,26 @@ python do_qa_patch() {
 >>>                   bb.error("Malformed Upstream-Status in
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath,
guidelines, match_kinda.group(0)))
 >>>               else:
 >>>                   bb.error("Missing Upstream-Status in
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
 >>> +
 >>> +       inappr_message_re =
r'Inappropriate(\s+\[(?P.*)\])*'
 >>> +       inappr_reasons = [
 >>> +            'not author',
 >>> +            'native',
 >>> +            'licensing',
 >>> +            'configuration',
 >>> +            'enable feature',
 >>> +            'disable feature',
 >>> +            'bugfix .*',
 >>> +            'embedded specific',
 >>> +            'no 

Re: [OE-core] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Alexander Kanavin]

What I would like to see at least is correctly tagging patches with dead
upstreams, now that we have the shiny new status for it, and a report where
they can be seen clearly :)

Alex

On Tue, 14 Dec 2021 at 19:48, Konrad Weihmann  wrote:

>
>
> On 14.12.21 19:38, Bruce Ashfield wrote:
> > On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann 
> wrote:
> >>
> [snip]
>
> >>
> >>
> meta/recipes-support/vte/vte/0001-Makefile.docs-correctly-substitute-gtkdoc-qemu-wrapp.patch:
> >> 6: Upstream-Status: Inappropriate [oe-core specific]
> >>
> >> or are simply ignoring it at all.
> >>
> >> In total that are 352 patches I could indentify in latest master.
> >>
> >> I don't want to open up another can of worms, but either we drop the
> >> reasoning from Inappropriate in the patch guideline completely or we
> >> need to fix that in core (I guess in other layers it is even worse :) )
> >>
> >> Any thoughts?
> >
> > If we can opt out of the check either in a layer config or a recipe,
> > then the noise can at least be minimized. Since the ecosystem !=
> > oe-core, this level of checking needs to be something that can be
> > opted-out / disabled.
> >
> > Whatever way this goes, I'd suggest that it not merge until the start
> > of the new year .. luckily RP is in full control of when it merges.
> >
> > Because I for one, won't be spending the Chrismtas holidays queuing
> > other people's patches, or fixing status lines in the patches in my
> > layers :)
> >
> > Cheers,
> >
> > Bruce
>
> Actually a very good idea, but I'm not sure how fine grained we want
> these package-qa ids to be... @RP any thoughts?
>
> Basically we can solve the issue either
> - by keeping the status quo (dropping the reason from the docu)
> - or having is according to docu
> - having it as a warning in the first place
> - turning it into an error once we are clean in core and all
> layers
> hosted on yocto project's infra
>
> But yeah sure that patch doesn't need to go in this year, as I don't
> want to ruins everyone's holidays :-)
>
> >>
> >> On 14.12.21 18:53, Konrad Weihmann wrote:
> >>> if a patch uses Upstream-Status: Inappropriate it should provide a
> machine
> >>> readable reasoning in square brackets.
> >>>
> >>> According to latest wiki entry that would be
> >>>
> >>> not author
> >>> native
> >>> licensing
> >>> configuration
> >>> enable feature
> >>> disable feature
> >>> bugfix .*
> >>> embedded specific
> >>> no upstream
> >>> other
> >>>
> >>> a detailed reasoning could be provided as part of the commit message,
> >>> but format of the metadata line is fixed.
> >>>
> >>> This patch adds a check to insane.bbclass and warns if there is a
> >>> non-compliant reasoning given, or none at all.
> >>>
> >>> In a follow-up this should be turned into an error, as it was done
> >>> with missing Upstream-Status
> >>>
> >>> Signed-off-by: Konrad Weihmann 
> >>> ---
> >>>meta/classes/insane.bbclass | 20 
> >>>1 file changed, 20 insertions(+)
> >>>
> >>> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> >>> index 240f3aad62..da26f4662c 100644
> >>> --- a/meta/classes/insane.bbclass
> >>> +++ b/meta/classes/insane.bbclass
> >>> @@ -1191,6 +1191,26 @@ python do_qa_patch() {
> >>>   bb.error("Malformed Upstream-Status in
> patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines,
> match_kinda.group(0)))
> >>>   else:
> >>>   bb.error("Missing Upstream-Status in
> patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
> >>> +
> >>> +   inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
> >>> +   inappr_reasons = [
> >>> +'not author',
> >>> +'native',
> >>> +'licensing',
> >>> +'configuration',
> >>> +'enable feature',
> >>> +'disable feature',
> >>> +'bugfix .*',
> >>> +'embedded specific',
> >>> +'no upstream',
> >>> +'other',
> >>> +   ]
> >>> +   for match_inappr in re.finditer(inappr_message_re, content,
> re.IGNORECASE | re.MULTILINE):
> >>> +
> >>> +   if 'reason' not in match_inappr.groupdict():
> >>> +   bb.warning("Missing Upstream-Status: Inappropriate
> reasoning in patch\n%s\nPlease add according to %s ." % (fullpath,
> guidelines))
> >>> +   elif not any(re.match(x,
> match_inappr.groupdict().get('reason', '') or '') for x in inappr_reasons):
> >>> +   bb.warning("Malformed Upstream-Status: Inappropriate
> in patch\n%s\nPlease correct according to %s :\n%s" % (fullpath,
> guidelines, match_inappr.group(0)))
> >>>}
> >>>
> >>>python do_qa_configure() {
> >>>
> >>>
> >>>
> >>>
> >>>
> >>
> >>
> >>
> >
> >
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159708): 
https://lists.openembedded.org/g/openembedded-core/message/159708
Mute This Topic: 

Re: [OE-core] [PATCH][dunfell] lttng-modules: do not search in non-existing folder during install

[Steve Sakoman]

On Tue, Dec 14, 2021 at 9:36 AM Anibal Limon  wrote:
>
> Hi,
>
> Any update on push this to dunfell?

It is in this morning's pull request:

https://lists.openembedded.org/g/openembedded-core/message/159699

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159707): 
https://lists.openembedded.org/g/openembedded-core/message/159707
Mute This Topic: https://lists.openembedded.org/mt/87597519/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][dunfell] lttng-modules: do not search in non-existing folder during install

[Anibal Limon]

Hi,

Any update on push this to dunfell?,

I'm facing the issue,

https://ci.linaro.org/job/lt-qcom-openembedded-meta-qcom-premerge-dunfell/46/MACHINE=dragonboard-410c,TCLIBC=glibc,label=docker-buster-amd64/console

Thanks in advance!,
Anibal

On Wed, 8 Dec 2021 at 14:21, Anibal Limon via lists.openembedded.org
 wrote:

> From: Andrey Zhizhikin 
>
> When CONFIG_TRACEPOINTS is not enabled in kernel config - module
> compilation is skipped, which causes the ${D}/${nonarch_base_libdir} not
> to be created.
>
> This fails later in do_install:append() due to the fact that find
> command in executed for non-existing folder.
>
> Check for folder existence before find command in executed.
>
> Signed-off-by: Andrey Zhizhikin 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit de0aa1700ed4e6f04b0a233eb1f6d2ac598e7ed8)
> Signed-off-by: Aníbal Limón 
> ---
>  meta/recipes-kernel/lttng/lttng-modules_2.11.6.bb | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
>
> diff --git a/meta/recipes-kernel/lttng/lttng-modules_2.11.6.bb
> b/meta/recipes-kernel/lttng/lttng-modules_2.11.6.bb
> index 3fdc8094e9..3145f0298c 100644
> --- a/meta/recipes-kernel/lttng/lttng-modules_2.11.6.bb
> +++ b/meta/recipes-kernel/lttng/lttng-modules_2.11.6.bb
> @@ -39,7 +39,9 @@ EXTRA_OEMAKE += "KERNELDIR='${STAGING_KERNEL_DIR}'"
>
>  do_install_append() {
> # Delete empty directories to avoid QA failures if no modules were
> built
> -   find ${D}/${nonarch_base_libdir} -depth -type d -empty -exec rmdir
> {} \;
> +   if [ -d ${D}/${nonarch_base_libdir} ]; then
> +   find ${D}/${nonarch_base_libdir} -depth -type d -empty
> -exec rmdir {} \;
> +   fi
>  }
>
>  python do_package_prepend() {
> --
> 2.34.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159706): 
https://lists.openembedded.org/g/openembedded-core/message/159706
Mute This Topic: https://lists.openembedded.org/mt/87597519/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] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Konrad Weihmann]

On 14.12.21 19:38, Bruce Ashfield wrote:

On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann  wrote:



[snip]



meta/recipes-support/vte/vte/0001-Makefile.docs-correctly-substitute-gtkdoc-qemu-wrapp.patch:
6: Upstream-Status: Inappropriate [oe-core specific]

or are simply ignoring it at all.

In total that are 352 patches I could indentify in latest master.

I don't want to open up another can of worms, but either we drop the
reasoning from Inappropriate in the patch guideline completely or we
need to fix that in core (I guess in other layers it is even worse :) )

Any thoughts?


If we can opt out of the check either in a layer config or a recipe,
then the noise can at least be minimized. Since the ecosystem !=
oe-core, this level of checking needs to be something that can be
opted-out / disabled.

Whatever way this goes, I'd suggest that it not merge until the start
of the new year .. luckily RP is in full control of when it merges.

Because I for one, won't be spending the Chrismtas holidays queuing
other people's patches, or fixing status lines in the patches in my
layers :)

Cheers,

Bruce


Actually a very good idea, but I'm not sure how fine grained we want 
these package-qa ids to be... @RP any thoughts?


Basically we can solve the issue either
- by keeping the status quo (dropping the reason from the docu)
- or having is according to docu
- having it as a warning in the first place
	- turning it into an error once we are clean in core and all layers 
hosted on yocto project's infra


But yeah sure that patch doesn't need to go in this year, as I don't 
want to ruins everyone's holidays :-)




On 14.12.21 18:53, Konrad Weihmann wrote:

if a patch uses Upstream-Status: Inappropriate it should provide a machine
readable reasoning in square brackets.

According to latest wiki entry that would be

not author
native
licensing
configuration
enable feature
disable feature
bugfix .*
embedded specific
no upstream
other

a detailed reasoning could be provided as part of the commit message,
but format of the metadata line is fixed.

This patch adds a check to insane.bbclass and warns if there is a
non-compliant reasoning given, or none at all.

In a follow-up this should be turned into an error, as it was done
with missing Upstream-Status

Signed-off-by: Konrad Weihmann 
---
   meta/classes/insane.bbclass | 20 
   1 file changed, 20 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..da26f4662c 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1191,6 +1191,26 @@ python do_qa_patch() {
  bb.error("Malformed Upstream-Status in patch\n%s\nPlease correct 
according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
  else:
  bb.error("Missing Upstream-Status in patch\n%s\nPlease add 
according to %s ." % (fullpath, guidelines))
+
+   inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
+   inappr_reasons = [
+'not author',
+'native',
+'licensing',
+'configuration',
+'enable feature',
+'disable feature',
+'bugfix .*',
+'embedded specific',
+'no upstream',
+'other',
+   ]
+   for match_inappr in re.finditer(inappr_message_re, content, 
re.IGNORECASE | re.MULTILINE):
+
+   if 'reason' not in match_inappr.groupdict():
+   bb.warning("Missing Upstream-Status: Inappropriate reasoning in 
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
+   elif not any(re.match(x, match_inappr.groupdict().get('reason', '') 
or '') for x in inappr_reasons):
+   bb.warning("Malformed Upstream-Status: Inappropriate in 
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines, 
match_inappr.group(0)))
   }

   python do_qa_configure() {













-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159705): 
https://lists.openembedded.org/g/openembedded-core/message/159705
Mute This Topic: https://lists.openembedded.org/mt/87726727/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] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Bruce Ashfield]

On Tue, Dec 14, 2021 at 1:05 PM Konrad Weihmann  wrote:
>
> The following patches in core don't follow the recommendation
>
> meta/recipes-bsp/apmd/apmd/legacy.patch:
>9: Upstream-Status: Inappropriate [upstream is dead]
>
> meta/recipes-bsp/efivar/efivar/no-werror.patch:
>3: Upstream-Status: Inappropriate
> [https://github.com/rhboot/efivar/issues/131]
>
> meta/recipes-bsp/grub/files/0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch:
>15: Upstream-Status: Inappropriate [OE specific]
>
> meta/recipes-bsp/grub/files/autogen.sh-exclude-pc.patch:
>12: Upstream-Status: Inappropriate [OE specific]
>
> meta/recipes-bsp/lrzsz/lrzsz-0.12.20/0001-Fix-cross-compilation-using-autoconf-detected-AR.patch:
>9: Upstream-Status: Inappropriate [upstream hasn't been active since
> 1998]
>
> meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch:
>3: Upstream-Status: Inappropriate [upstream hasn't been active since
> 1998]
>
> meta/recipes-bsp/lrzsz/lrzsz-0.12.20/cve-2018-10195.patch:
>6: Upstream-Status: Inappropriate (dead upstream)
>
> meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch:
>4: Upstream-Status: Inappropriate [upstream is dead]
>
> meta/recipes-bsp/opensbi/files/0001-Makefile-Don-t-specify-mabi-or-march.patch:
>10: Upstream-Status: Inappropriate [Fixes a 32-bit OE flow bug]
>
> meta/recipes-connectivity/avahi/files/0001-Fix-opening-etc-resolv.conf-error.patch:
>19: Upstream-Status: Inappropriate [OE Specific]
>
> meta/recipes-connectivity/bind/bind-9.16.23/0001-named-lwresd-V-and-start-log-hide-build-options.patch:
>12: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-connectivity/bind/bind-9.16.23/bind-ensure-searching-for-json-headers-searches-sysr.patch:
>28: Upstream-Status: Inappropriate [OE Specific]
>
> meta/recipes-connectivity/bind/bind-9.16.23/init.d-add-support-for-read-only-rootfs.patch:
>3: Upstream-Status: Inappropriate [oe specific]
>
> meta/recipes-connectivity/bluez5/bluez5/0001-tests-add-a-target-for-building-tests-without-runnin.patch:
>6: Upstream-Status: Inappropriate [oe specific]
>
> meta/recipes-connectivity/connman/connman/no-version-scripts.patch:
>13: Upstream-Status: Inappropriate
>
> meta/recipes-connectivity/kea/files/0001-src-lib-log-logger_unittest_support.cc-do-not-write-.patch:
>9: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-connectivity/openssl/openssl/0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch:
>21: Upstream-Status: Inappropriate [OE specific]
>
> meta/recipes-connectivity/openssl/openssl/0001-Configure-do-not-tweak-mips-cflags.patch:
>10: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-connectivity/ppp/ppp/0001-ppp-fix-build-against-5.15-headers.patch:
>14: Upstream-Status: Inappropriate [OE-specific configuration/headers]
>
> meta/recipes-core/base-passwd/base-passwd/add_shutdown.patch:
>6: Upstream-Status: Inappropriate [Embedded]
>
> meta/recipes-core/base-passwd/base-passwd/disable-docs.patch:
>4: Upstream-Status: Inappropriate [OE-Core specific]
>
> meta/recipes-core/busybox/busybox/recognize_connmand.patch:
>3: Upstream-Status: Inappropriate [OE-Core]
>
> meta/recipes-core/coreutils/coreutils/remove-usr-local-lib-from-m4.patch:
>14: Upstream-Status: Inappropriate [Upstream does care for AIX while
> we may not]
>
> meta/recipes-core/dbus/dbus/python-config.patch:
>6: Upstream-Status: Inappropriate [oe specific]
>
> meta/recipes-core/dbus/dbus/tmpdir.patch:
>8: Upstream-Status: Inappropriate [embedded]
>
> meta/recipes-core/dbus/dbus-glib/test-install-makefile.patch:
>3: Upstream-Status: Inappropriate [test not install is for purpose
> from upstream]
>
> meta/recipes-core/gettext/gettext-0.21/0001-init-env.in-do-not-add-C-CXX-parameters.patch:
>9: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-core/gettext/gettext-0.21/0001-tests-autopoint-3-unset-MAKEFLAGS.patch:
>9: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-core/gettext/gettext-0.21/serial-tests-config.patch:
>8: Upstream-Status: Inappropriate [oe specific]
>
> meta/recipes-core/gettext/gettext-0.21/use-pkgconfig.patch:
>13: Upstream-Status: Inappropriate [upstream still refuse to consider
> pkg-config]
>
> meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch:
>10: Upstream-Status: Inappropriate [upstream wants the paths in .pc
> files]
>
> meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch:
>9: Upstream-Status: Inappropriate [oe-core specific]
>
> meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch:
>10: Upstream-Status: Inappropriate [OE specific]
>
> meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch:
>10: Upstream-Status: Inappropriate
>
> 

Re: [OE-core] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Konrad Weihmann]

The following patches in core don't follow the recommendation

meta/recipes-bsp/apmd/apmd/legacy.patch:
  9: Upstream-Status: Inappropriate [upstream is dead]

meta/recipes-bsp/efivar/efivar/no-werror.patch:
  3: Upstream-Status: Inappropriate 
[https://github.com/rhboot/efivar/issues/131]


meta/recipes-bsp/grub/files/0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch:
  15: Upstream-Status: Inappropriate [OE specific]

meta/recipes-bsp/grub/files/autogen.sh-exclude-pc.patch:
  12: Upstream-Status: Inappropriate [OE specific]

meta/recipes-bsp/lrzsz/lrzsz-0.12.20/0001-Fix-cross-compilation-using-autoconf-detected-AR.patch:
  9: Upstream-Status: Inappropriate [upstream hasn't been active since 
1998]


meta/recipes-bsp/lrzsz/lrzsz-0.12.20/autotools-update.patch:
  3: Upstream-Status: Inappropriate [upstream hasn't been active since 
1998]


meta/recipes-bsp/lrzsz/lrzsz-0.12.20/cve-2018-10195.patch:
  6: Upstream-Status: Inappropriate (dead upstream)

meta/recipes-bsp/lrzsz/lrzsz-0.12.20/include.patch:
  4: Upstream-Status: Inappropriate [upstream is dead]

meta/recipes-bsp/opensbi/files/0001-Makefile-Don-t-specify-mabi-or-march.patch:
  10: Upstream-Status: Inappropriate [Fixes a 32-bit OE flow bug]

meta/recipes-connectivity/avahi/files/0001-Fix-opening-etc-resolv.conf-error.patch:
  19: Upstream-Status: Inappropriate [OE Specific]

meta/recipes-connectivity/bind/bind-9.16.23/0001-named-lwresd-V-and-start-log-hide-build-options.patch:
  12: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-connectivity/bind/bind-9.16.23/bind-ensure-searching-for-json-headers-searches-sysr.patch:
  28: Upstream-Status: Inappropriate [OE Specific]

meta/recipes-connectivity/bind/bind-9.16.23/init.d-add-support-for-read-only-rootfs.patch:
  3: Upstream-Status: Inappropriate [oe specific]

meta/recipes-connectivity/bluez5/bluez5/0001-tests-add-a-target-for-building-tests-without-runnin.patch:
  6: Upstream-Status: Inappropriate [oe specific]

meta/recipes-connectivity/connman/connman/no-version-scripts.patch:
  13: Upstream-Status: Inappropriate

meta/recipes-connectivity/kea/files/0001-src-lib-log-logger_unittest_support.cc-do-not-write-.patch:
  9: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-connectivity/openssl/openssl/0001-buildinfo-strip-sysroot-and-debug-prefix-map-from-co.patch:
  21: Upstream-Status: Inappropriate [OE specific]

meta/recipes-connectivity/openssl/openssl/0001-Configure-do-not-tweak-mips-cflags.patch:
  10: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-connectivity/ppp/ppp/0001-ppp-fix-build-against-5.15-headers.patch:
  14: Upstream-Status: Inappropriate [OE-specific configuration/headers]

meta/recipes-core/base-passwd/base-passwd/add_shutdown.patch:
  6: Upstream-Status: Inappropriate [Embedded]

meta/recipes-core/base-passwd/base-passwd/disable-docs.patch:
  4: Upstream-Status: Inappropriate [OE-Core specific]

meta/recipes-core/busybox/busybox/recognize_connmand.patch:
  3: Upstream-Status: Inappropriate [OE-Core]

meta/recipes-core/coreutils/coreutils/remove-usr-local-lib-from-m4.patch:
  14: Upstream-Status: Inappropriate [Upstream does care for AIX while 
we may not]


meta/recipes-core/dbus/dbus/python-config.patch:
  6: Upstream-Status: Inappropriate [oe specific]

meta/recipes-core/dbus/dbus/tmpdir.patch:
  8: Upstream-Status: Inappropriate [embedded]

meta/recipes-core/dbus/dbus-glib/test-install-makefile.patch:
  3: Upstream-Status: Inappropriate [test not install is for purpose 
from upstream]


meta/recipes-core/gettext/gettext-0.21/0001-init-env.in-do-not-add-C-CXX-parameters.patch:
  9: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-core/gettext/gettext-0.21/0001-tests-autopoint-3-unset-MAKEFLAGS.patch:
  9: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-core/gettext/gettext-0.21/serial-tests-config.patch:
  8: Upstream-Status: Inappropriate [oe specific]

meta/recipes-core/gettext/gettext-0.21/use-pkgconfig.patch:
  13: Upstream-Status: Inappropriate [upstream still refuse to consider 
pkg-config]


meta/recipes-core/glib-2.0/glib-2.0/0001-Do-not-write-bindir-into-pkg-config-files.patch:
  10: Upstream-Status: Inappropriate [upstream wants the paths in .pc 
files]


meta/recipes-core/glib-2.0/glib-2.0/0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch:
  9: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-core/glib-2.0/glib-2.0/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch:
  10: Upstream-Status: Inappropriate [OE specific]

meta/recipes-core/glib-2.0/glib-2.0/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch:
  10: Upstream-Status: Inappropriate

meta/recipes-core/glib-2.0/glib-2.0/0001-Set-host_machine-correctly-when-building-with-mingw3.patch:
  6: Upstream-Status: Inappropriate [oe-core specific]

meta/recipes-core/glib-2.0/glib-2.0/0010-Do-not-hardcode-python-path-into-various-tools.patch:
  6: Upstream-Status: Inappropriate [oe-core specific]

Re: [OE-core] [PATCH] gcc: Fix CVE-2021-42574

[Khem Raj]

On Tue, Dec 14, 2021 at 9:31 AM Randy MacLeod
 wrote:
>
> On 2021-12-14 5:46 a.m., Pgowda wrote:
> > Upstream-Status: Backport 
> > [https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bd5e882cf6e0def3dd1bc106075d59a303fe0d1e]
> > Upstream-Status: Backport 
> > [https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=51c500269bf53749b107807d84271385fad35628]
> > Upstream-Status: Backport 
> > [https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1a7f2c0774129750fdf73e9f1b78f0ce983c9ab3]
> > Upstream-Status: Backport 
> > [https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bef32d4a28595e933f24fef378cf052a30b674a7]
>
> Ugh, that's quite a bit of patch to fix this bi-directional Unicode
> input attack.
> I'm fine with these changes though.
>
>
> I do wonder about how or if we should fix the CVE in older releases.

this is adding a new warning to help mitigate the problem, this is not
a gcc CVE per se.
so perhaps backporting to older branches makes sense, this looks ok
for 11.x here

>
> For example, has or is there an indication that gcc upstream will,
> be backporting these patches to:
>
> $ git branch -a | grep " releases/gcc-[10|11|9]"
>
>releases/gcc-10
>
>releases/gcc-11
>
>releases/gcc-9
>
>
> ?
>
> The current state of supported branches is:
>
> Branch  YP gcc ver  Latest gcc ver  Upgrade needed?
> --  --  --  ---
> master  11.2.0  11.2.0  No
> honister11.2.0  11.2.0  No
> hardknott   10.2.0  10.3.0  Yes
> dunfell 9.3.09.4.0  Yes
>
> https://gcc.gnu.org/releases.html
>
>
> so please check with upstream to see what the plan is for
> the 9-11 release branches and this CVE and report back here.
> Feel free to volunteer backport patches to gcc upstream if needed.
>
> Are people CCed okay with upgrading gcc to the latest release or
> ideally the next dot releases that will include a fix for this CVE
> if it happens in the coming month or so?

I think doing a bug fix dot release upgrade might be ok. Although we
would have to do some good amount of testing. But I am in favor

>
>
> --><-- snip --><--
>
> --
> # Randy MacLeod
> # Wind River Linux
>

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

[OE-core] [meta-oe][RFC PATCH] insane: Inappropriate patch reasoning

[Konrad Weihmann]

if a patch uses Upstream-Status: Inappropriate it should provide a machine
readable reasoning in square brackets.

According to latest wiki entry that would be

not author
native
licensing
configuration
enable feature
disable feature
bugfix .*
embedded specific
no upstream
other

a detailed reasoning could be provided as part of the commit message,
but format of the metadata line is fixed.

This patch adds a check to insane.bbclass and warns if there is a
non-compliant reasoning given, or none at all.

In a follow-up this should be turned into an error, as it was done
with missing Upstream-Status

Signed-off-by: Konrad Weihmann 
---
 meta/classes/insane.bbclass | 20 
 1 file changed, 20 insertions(+)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..da26f4662c 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1191,6 +1191,26 @@ python do_qa_patch() {
bb.error("Malformed Upstream-Status in patch\n%s\nPlease 
correct according to %s :\n%s" % (fullpath, guidelines, match_kinda.group(0)))
else:
bb.error("Missing Upstream-Status in patch\n%s\nPlease add 
according to %s ." % (fullpath, guidelines))
+   
+   inappr_message_re = r'Inappropriate(\s+\[(?P.*)\])*'
+   inappr_reasons = [
+'not author',
+'native',
+'licensing',
+'configuration',
+'enable feature',
+'disable feature',
+'bugfix .*',
+'embedded specific',
+'no upstream',
+'other',
+   ]
+   for match_inappr in re.finditer(inappr_message_re, content, 
re.IGNORECASE | re.MULTILINE):
+
+   if 'reason' not in match_inappr.groupdict():
+   bb.warning("Missing Upstream-Status: Inappropriate reasoning in 
patch\n%s\nPlease add according to %s ." % (fullpath, guidelines))
+   elif not any(re.match(x, match_inappr.groupdict().get('reason', '') 
or '') for x in inappr_reasons):
+   bb.warning("Malformed Upstream-Status: Inappropriate in 
patch\n%s\nPlease correct according to %s :\n%s" % (fullpath, guidelines, 
match_inappr.group(0)))
 }
 
 python do_qa_configure() {
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159701): 
https://lists.openembedded.org/g/openembedded-core/message/159701
Mute This Topic: https://lists.openembedded.org/mt/87726727/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] gcc: Fix CVE-2021-42574

[Randy MacLeod]

On 2021-12-14 5:46 a.m., Pgowda wrote:

Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bd5e882cf6e0def3dd1bc106075d59a303fe0d1e]
Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=51c500269bf53749b107807d84271385fad35628]
Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=1a7f2c0774129750fdf73e9f1b78f0ce983c9ab3]
Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=bef32d4a28595e933f24fef378cf052a30b674a7]


Ugh, that's quite a bit of patch to fix this bi-directional Unicode 
input attack.

I'm fine with these changes though.


I do wonder about how or if we should fix the CVE in older releases.

For example, has or is there an indication that gcc upstream will,
be backporting these patches to:

$ git branch -a | grep " releases/gcc-[10|11|9]"

  releases/gcc-10

  releases/gcc-11

  releases/gcc-9


?

The current state of supported branches is:

Branch  YP gcc ver  Latest gcc ver  Upgrade needed?
--  --  --  ---
master  11.2.0  11.2.0  No
honister11.2.0  11.2.0  No
hardknott   10.2.0  10.3.0  Yes
dunfell 9.3.09.4.0  Yes

https://gcc.gnu.org/releases.html


so please check with upstream to see what the plan is for
the 9-11 release branches and this CVE and report back here.
Feel free to volunteer backport patches to gcc upstream if needed.

Are people CCed okay with upgrading gcc to the latest release or
ideally the next dot releases that will include a fix for this CVE
if it happens in the coming month or so?


--><-- snip --><--

--
# Randy MacLeod
# Wind River Linux


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159700): 
https://lists.openembedded.org/g/openembedded-core/message/159700
Mute This Topic: https://lists.openembedded.org/mt/87718531/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 00/10] Pull request (cover letter only)

[Steve Sakoman]

The following changes since commit f788765e1b9832d0da8ec4ce49aa85864b0e:

  README.OE-Core.md: update URLs (2021-12-06 04:48:48 -1000)

are available in the Git repository at:

  git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
  
http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next

Andrey Zhizhikin (1):
  lttng-modules: do not search in non-existing folder during install

Markus Volk (1):
  wic:direct.py: ignore invalid mountpoints during fstab update

Marta Rybczynska (1):
  libgcrypt: solve CVE-2021-33560 and CVE-2021-40528

Richard Purdie (1):
  gcc: Add CVE-2021-37322 to the list of CVEs to ignore

Ross Burton (1):
  runqemu: check the qemu PID has been set before kill()ing it

Sana Kazi (1):
  busybox: Fix multiple security issues in awk

Stefan Herbrechtsmeier (2):
  recipetool: Set master branch only as fallback
  selftest/devtool: Check branch in git fetch

Steve Sakoman (2):
  cve-extra-exclusions: add db CVEs to exclusion list
  selftest: skip virgl test on centos 8 entirely

 .../distro/include/cve-extra-exclusions.inc   |   9 +-
 meta/lib/oeqa/selftest/cases/devtool.py   |   5 +-
 meta/lib/oeqa/selftest/cases/runtime_test.py  |   2 +
 meta/recipes-core/busybox/busybox_1.31.1.bb   |   1 +
 .../busybox/files/CVE-2021-423xx-awk.patch| 215 ++
 meta/recipes-devtools/gcc/gcc-9.3.inc |   3 +
 .../lttng/lttng-modules_2.11.6.bb |   4 +-
 .../libgcrypt/files/CVE-2021-33560.patch  | 138 +--
 .../libgcrypt/files/CVE-2021-40528.patch  | 109 +
 .../libgcrypt/libgcrypt_1.8.5.bb  |   1 +
 scripts/lib/recipetool/create.py  |  15 +-
 scripts/lib/wic/plugins/imager/direct.py  |   2 +-
 scripts/runqemu   |   3 +-
 13 files changed, 408 insertions(+), 99 deletions(-)
 create mode 100644 meta/recipes-core/busybox/files/CVE-2021-423xx-awk.patch
 create mode 100644 meta/recipes-support/libgcrypt/files/CVE-2021-40528.patch

-- 
2.25.1


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

[OE-core] [meta-oe][PATCH v2 2/2] insane: add Inactive-Upstream to Upstream-Status

[Konrad Weihmann]

as defined by latest addition to the commit message guideline

Signed-off-by: Konrad Weihmann 
---
 meta/classes/insane.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 125c339942..11532ecd08 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1170,7 +1170,7 @@ python do_qa_patch() {
 
content = open(fullpath, encoding='utf-8', errors='ignore').read()
kinda_status_re = re.compile(r"^.*upstream.*status.*$", re.IGNORECASE | 
re.MULTILINE)
-   strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport)( .+)?$", 
re.MULTILINE)
+   strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport|Inactive-Upstream)( 
.+)?$", re.MULTILINE)
match_kinda = kinda_status_re.search(content)
match_strict = strict_status_re.search(content)
guidelines = 
"https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status;
-- 
2.25.1


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

[OE-core] [meta-oe][PATCH v2 1/2] insane: move src-uri-bad checks to unpack stage

[Konrad Weihmann]

previously used package_qa_check_src_uri was triggered during
package_qa stage, which implies having packages.
This isn't the case for native-only recipes or recipe that inherit
nopackages.

Still the checks performed (src-uri-bad) apply to those as well.
Therefore move the check from package_qa stage to unpack stage.

Signed-off-by: Konrad Weihmann 
---
 meta/classes/insane.bbclass | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..125c339942 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -968,17 +968,6 @@ def package_qa_check_host_user(path, name, d, elf, 
messages):
 return False
 return True
 
-QARECIPETEST[src-uri-bad] = "package_qa_check_src_uri"
-def package_qa_check_src_uri(pn, d, messages):
-import re
-
-if "${PN}" in d.getVar("SRC_URI", False):
-oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses PN not BPN" % pn, 
d)
-
-for url in d.getVar("SRC_URI").split():
-if re.search(r"git(hu|la)b\.com/.+/.+/archive/.+", url):
-oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses unstable 
GitHub/GitLab archives, convert recipe to use git protocol" % pn, d)
-
 QARECIPETEST[unhandled-features-check] = 
"package_qa_check_unhandled_features_check"
 def package_qa_check_unhandled_features_check(pn, d, messages):
 if not bb.data.inherits_class('features_check', d):
@@ -1285,11 +1274,28 @@ Rerun configure task after fixing this."""
 oe.qa.exit_if_errors(d)
 }
 
+def unpack_check_src_uri(pn, d):
+import re
+
+skip = (d.getVar('INSANE_SKIP') or "").split()
+if 'src-uri-bad' in skip:
+bb.note("Recipe %s skipping qa checking: src-uri-bad" % d.getVar('PN'))
+return
+
+if "${PN}" in d.getVar("SRC_URI", False):
+oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses PN not BPN" % pn, 
d)
+
+for url in d.getVar("SRC_URI").split():
+if re.search(r"git(hu|la)b\.com/.+/.+/archive/.+", url):
+oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses unstable 
GitHub/GitLab archives, convert recipe to use git protocol" % pn, d)
+
 python do_qa_unpack() {
 src_uri = d.getVar('SRC_URI')
 s_dir = d.getVar('S')
 if src_uri and not os.path.exists(s_dir):
 bb.warn('%s: the directory %s (%s) pointed to by the S variable 
doesn\'t exist - please set S within the recipe to point to where the source 
has been unpacked to' % (d.getVar('PN'), d.getVar('S', False), s_dir))
+
+unpack_check_src_uri(d.getVar('PN'), d)
 }
 
 # The Staging Func, to check all staging
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159697): 
https://lists.openembedded.org/g/openembedded-core/message/159697
Mute This Topic: https://lists.openembedded.org/mt/87724917/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/2] insane: add Inactive-Upstream to Upstream-Status

[Konrad Weihmann]

as defined by latest addition to the commit message guideline

Signed-off-by: Konrad Weihmann 
---
 meta/classes/insane.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 70c2d97df1..cc348173d6 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -1170,7 +1170,7 @@ python do_qa_patch() {
 
content = open(fullpath, encoding='utf-8', errors='ignore').read()
kinda_status_re = re.compile(r"^.*upstream.*status.*$", re.IGNORECASE | 
re.MULTILINE)
-   strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport)( .+)?$", 
re.MULTILINE)
+   strict_status_re = re.compile(r"^Upstream-Status: 
(Pending|Submitted|Denied|Accepted|Inappropriate|Backport|Inactive-Upstream)( 
.+)?$", re.MULTILINE)
match_kinda = kinda_status_re.search(content)
match_strict = strict_status_re.search(content)
guidelines = 
"https://www.openembedded.org/wiki/Commit_Patch_Message_Guidelines#Patch_Header_Recommendations:_Upstream-Status;
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159696): 
https://lists.openembedded.org/g/openembedded-core/message/159696
Mute This Topic: https://lists.openembedded.org/mt/87724799/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/2] insane: move src-uri-bad checks to unpack stage

[Konrad Weihmann]

previously used package_qa_check_src_uri was triggered during
package_qa stage, which implies having packages.
This isn't the case for native-only recipes or recipe that inherit
nopackages.

Still the checks performed (src-uri-bad) apply to those as well.
Therefore move the check from package_qa stage to unpack stage.

Signed-off-by: Konrad Weihmann 
---
 meta/classes/insane.bbclass | 28 +---
 1 file changed, 17 insertions(+), 11 deletions(-)

diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
index 240f3aad62..70c2d97df1 100644
--- a/meta/classes/insane.bbclass
+++ b/meta/classes/insane.bbclass
@@ -968,17 +968,6 @@ def package_qa_check_host_user(path, name, d, elf, 
messages):
 return False
 return True
 
-QARECIPETEST[src-uri-bad] = "package_qa_check_src_uri"
-def package_qa_check_src_uri(pn, d, messages):
-import re
-
-if "${PN}" in d.getVar("SRC_URI", False):
-oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses PN not BPN" % pn, 
d)
-
-for url in d.getVar("SRC_URI").split():
-if re.search(r"git(hu|la)b\.com/.+/.+/archive/.+", url):
-oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses unstable 
GitHub/GitLab archives, convert recipe to use git protocol" % pn, d)
-
 QARECIPETEST[unhandled-features-check] = 
"package_qa_check_unhandled_features_check"
 def package_qa_check_unhandled_features_check(pn, d, messages):
 if not bb.data.inherits_class('features_check', d):
@@ -1285,11 +1274,28 @@ Rerun configure task after fixing this."""
 oe.qa.exit_if_errors(d)
 }
 
+def unpack_check_src_uri(pn, d):
+import re
+
+skip = (d.getVar('INSANE_SKIP') or "").split()
+if 'src-uri-bad' in skip:
+bb.note("Recipe %s skipping qa checking: configure-unsafe" % 
d.getVar('PN'))
+return
+
+if "${PN}" in d.getVar("SRC_URI", False):
+oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses PN not BPN" % pn, 
d)
+
+for url in d.getVar("SRC_URI").split():
+if re.search(r"git(hu|la)b\.com/.+/.+/archive/.+", url):
+oe.qa.handle_error("src-uri-bad", "%s: SRC_URI uses unstable 
GitHub/GitLab archives, convert recipe to use git protocol" % pn, d)
+
 python do_qa_unpack() {
 src_uri = d.getVar('SRC_URI')
 s_dir = d.getVar('S')
 if src_uri and not os.path.exists(s_dir):
 bb.warn('%s: the directory %s (%s) pointed to by the S variable 
doesn\'t exist - please set S within the recipe to point to where the source 
has been unpacked to' % (d.getVar('PN'), d.getVar('S', False), s_dir))
+
+unpack_check_src_uri(d.getVar('PN'), d)
 }
 
 # The Staging Func, to check all staging
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159695): 
https://lists.openembedded.org/g/openembedded-core/message/159695
Mute This Topic: https://lists.openembedded.org/mt/87724797/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] The state of DKMS in the Yocto community

[Alex Stewart]

Converging threads.

Thanks all for the feedback. It sounds like there's no appetite for a 
DKMS recipe, and I agree with the rationale for rejection.


I'll motion to have NI's DKMS recipe migrated to our meta-nilrt layer 
and independently maintained until such a time as we can deprecate it.


Thanks,

--
Alex Stewart
Software Engineer - NI Real-Time OS
NI (National Instruments)

alex.stew...@ni.com


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

[OE-core] Yocto Project Status WW50`21

[Stephen Jolley]

Current Dev Position: YP 3.5 M1

Next Deadline: 6th Dec. 2021 YP 3.5 M1 build

 

Next Team Meetings:

*   Bug Triage meeting Thursday Dec. 16th at 7:30am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Monthly Project Meeting Tuesday Jan. 4th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Weekly Engineering Sync Tuesday Dec. 14th at 8am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 3.5 M1 is in QA
*   YP 3.1.13 is due to build this week
*   We have maintenance to the autobuilder planned to fit SSDs to speed
up IO and update the host distros to more modern equivalents. If parts
arrive as planned, this is scheduled for next week (20th-24th) and the
autobuilder will be unavailable during the work. There may be bring up
issues with the new distros.
*   There were significant improvements in patch metrics this week with
large drops in both patches in the pending state and overlap number of
patches. Thanks to everyone who contributed to that!
*   As part of patch cleanup, some changes were made which could impact
other layers or our spectrum of support. The libtool prefix patches were
dropped as the need was largely obsolete by recipe specific sysroots,
hosttools and other developments and this may mean patches in other layers
can be dropped too. Some non-upstream invasive mips and sh4 patches were
dropped as they were either obsolete or there were less invasive ways to
handle them. 
*   CVE metrics improved this week with drops in open CVEs for both
dunfull and master.
*   Intermittent issues continue to rise and help is very much welcome
on these issues. You can see the list of failures we're continuing to see by
searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT

 

Ways to contribute:

*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 3.5. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_3.5_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.

 

YP 3.5 Milestone Dates:

*   YP 3.5 M1 in QA
*   YP 3.5 M1 Release date 2021/12/17
*   YP 3.5 M2 build date 2022/01/10
*   YP 3.5 M2 Release date 2022/1/21
*   YP 3.5 M3 build date 2022/2/21
*   YP 3.5 M3 Release date 2022/03/04
*   YP 3.5 M4 build date 2022/04/04
*   YP 3.5 M4 Release date 2022/04/29

 

Upcoming dot releases:

*   YP 3.4.1  is released
*   YP 3.1.13 build date 2021/12/13
*   YP 3.1.13 Release date 2021/12/22
*   YP 3.1.14 build date 2022/01/24
*   YP 3.1.14 Release date 2022/02/04
*   YP 3.4.2 build date 2022/02/07
*   YP 3.4.2 Release date 2022/02/18
*   YP 3.3.5 build date 2022/02/14
*   YP 3.3.5 Release date 2022/02/25
*   YP 3.1.15 build date 2022/03/14
*   YP 3.1.15 Release date 2022/03/25
*   YP 3.4.3 build date 2022/03/21
*   YP 3.4.3 Release date 2022/04/01
*   YP 3.3.6 build date 2022/03/28
*   YP 3.3.6 Release date 2022/04/08
*   YP 3.1.16 build date 2022/04/25
*   YP 3.1.16 Release date 2022/05/06

 

Tracking Metrics:

*   WDD 2633 (last week 2583) (

https://wiki.yoctoproject.org/charts/combo.html)
*   OE-Core/Poky Patch Metrics

*   Total patches found: 1225 (last week 1272)
*   Patches in the Pending State: 349 (28%) [last week 400 (31%)]

 

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

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

 

The Status reports are now stored on the wiki at:

https://wiki.yoctoproject.org/wiki/Weekly_Status

 

[If anyone has suggestions for other information you'd like to see on this
weekly status update, let 

Re: [OE-core] [RFC PATCH v2 3/3] selftest: recipetool: Add test for handle_license_vars function

[Stefan Herbrechtsmeier]

Hi Richard,

Am 14.12.2021 um 14:01 schrieb Richard Purdie:

On Mon, 2021-12-13 at 16:05 +0100, Stefan Herbrechtsmeier wrote:

From: Stefan Herbrechtsmeier 

Signed-off-by: Stefan Herbrechtsmeier 
---

(no changes since v1)

  meta/lib/oeqa/selftest/cases/recipetool.py | 62 ++
  1 file changed, 62 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
b/meta/lib/oeqa/selftest/cases/recipetool.py
index 1c73b2c5e0..5330d73cbf 100644
--- a/meta/lib/oeqa/selftest/cases/recipetool.py
+++ b/meta/lib/oeqa/selftest/cases/recipetool.py
@@ -592,6 +592,68 @@ class RecipetoolTests(RecipetoolBase):
  with open(srcfile, 'w') as fh:
  fh.writelines(plugincontent)
  
+def test_recipetool_handle_license_vars(self):

+from create import handle_license_vars
+from unittest.mock import Mock
+
+commonlicdir = get_bb_var('COMMON_LICENSE_DIR')
+
+d = bb.tinfoil.TinfoilDataStoreConnector
+d.getVar = Mock(return_value=commonlicdir)
+
+srctree = tempfile.mkdtemp(prefix='recipetoolqa')
+self.track_for_cleanup(srctree)
+
+# Multiple licenses
+licenses = ['MIT', 'ISC', 'BSD-3-Clause', 'Apache-2.0']
+for licence in licenses:
+shutil.copy(os.path.join(commonlicdir, licence), 
os.path.join(srctree, 'LICENSE.' + licence))
+# Duplicate license
+shutil.copy(os.path.join(commonlicdir, 'MIT'), os.path.join(srctree, 
'LICENSE'))
+
+extravalues = {
+# Duplicate and missing licenses
+'LICENSE': 'Zlib & BSD-2-Clause & Zlib',
+'LIC_FILES_CHKSUM': [
+'file://README.md;md5=0123456789abcdef0123456789abcd'
+]
+}
+lines_before = []
+handled = []
+licvalues = handle_license_vars(srctree, lines_before, handled, 
extravalues, d)
+expected_lines_before = [
+'# WARNING: the following LICENSE and LIC_FILES_CHKSUM values are 
best guesses - it is',
+'# your responsibility to verify that the values are complete and 
correct.',
+'# NOTE: Original package / source metadata indicates license is: 
BSD-2-Clause & Zlib',
+'#',
+'# NOTE: multiple licenses have been detected; they have been 
separated with &',
+'# in the LICENSE value for now since it is a reasonable 
assumption that all',
+'# of the licenses apply. If instead there is a choice between the 
multiple',
+'# licenses then you should change the value to separate the 
licenses with |',
+'# instead of &. If there is any doubt, check the accompanying 
documentation',
+'# to determine which situation is applicable.',
+'LICENSE = "Apache-2.0 & BSD-2-Clause & BSD-3-Clause & ISC & MIT & 
Zlib"',
+'LIC_FILES_CHKSUM = 
"file://LICENSE;md5=0835ade698e0bcf8506ecda2f7b4f302 \\\n'
+'
file://LICENSE.MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \\\n'
+'
file://LICENSE.ISC;md5=f3b90e78ea0cffb20bf5cca7947a896d \\\n'
+'
file://LICENSE.Apache-2.0;md5=89aea4e17d99a7cacdbeed46a0096b10 \\\n'
+'
file://LICENSE.BSD-3-Clause;md5=550794465ba0ec5312d6919e203a55f9 \\\n'
+'
file://README.md;md5=0123456789abcdef0123456789abcd"',
+''
+]
+self.assertEqual(lines_before, expected_lines_before)
+expected_licvalues = [
+('MIT', 'LICENSE', '0835ade698e0bcf8506ecda2f7b4f302'),
+('MIT', 'LICENSE.MIT', '0835ade698e0bcf8506ecda2f7b4f302'),
+('ISC', 'LICENSE.ISC', 'f3b90e78ea0cffb20bf5cca7947a896d'),
+('Apache-2.0', 'LICENSE.Apache-2.0', 
'89aea4e17d99a7cacdbeed46a0096b10'),
+('BSD-3-Clause', 'LICENSE.BSD-3-Clause', 
'550794465ba0ec5312d6919e203a55f9')
+]
+self.assertEqual(handled, [('license', expected_licvalues)])
+self.assertEqual(extravalues, {})
+self.assertEqual(licvalues, expected_licvalues)
+
+
  def test_recipetool_split_pkg_licenses(self):
  from create import split_pkg_licenses
  licvalues = [




The test failed in testing:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2956/steps/14/logs/stdio


I didn't know that os.walk() is not deterministic.

I will fix it.

Regards
  Stefan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159692): 
https://lists.openembedded.org/g/openembedded-core/message/159692
Mute This Topic: https://lists.openembedded.org/mt/87699203/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] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?

[Robert P. J. Day]

On Tue, 14 Dec 2021, Ross Burton wrote:

> On Tue, 14 Dec 2021 at 11:39, Robert P. J. Day  wrote:
> >   what i'm looking at now does it in a more curious way. there is a
> > catch-all recipe file (call it "catchall.bb") which lists, as its
> > DEPENDS list, *all* of the recipes that make up the image, which means
> > that building catchall.bb builds and populates an image directory with
> > the combination of all those other recipes, after which it defines
> > both pkg_postinst_${PN} *and* do_install_append(), both of which run
> > around and make changes relative to ${D}, given that the image
> > directory for that recipe effectively contains, well, everything that
> > will go into the rootfs.
>
> Either you're explaining badly, or that isn't doing what you expect.
>
> A normal catchall.bb recipe which DEPENDS on all other relevant
> recipes will result in the recipe-sysroot directory containing the
> sysroots for those recipes, but that is all.  the image directory
> won't contain anything apart from what catchall.bb's do_install
> installs.

  yeah, i was typing quickly and screwed up my explanation totally.
i'll try again after imminent meeting. le *sigh*.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159691): 
https://lists.openembedded.org/g/openembedded-core/message/159691
Mute This Topic: https://lists.openembedded.org/mt/87719024/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] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?

[Ross Burton]

On Tue, 14 Dec 2021 at 11:39, Robert P. J. Day  wrote:
>   what i'm looking at now does it in a more curious way. there is a
> catch-all recipe file (call it "catchall.bb") which lists, as its
> DEPENDS list, *all* of the recipes that make up the image, which means
> that building catchall.bb builds and populates an image directory with
> the combination of all those other recipes, after which it defines
> both pkg_postinst_${PN} *and* do_install_append(), both of which run
> around and make changes relative to ${D}, given that the image
> directory for that recipe effectively contains, well, everything that
> will go into the rootfs.

Either you're explaining badly, or that isn't doing what you expect.

A normal catchall.bb recipe which DEPENDS on all other relevant
recipes will result in the recipe-sysroot directory containing the
sysroots for those recipes, but that is all.  the image directory
won't contain anything apart from what catchall.bb's do_install
installs.

Ross

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159690): 
https://lists.openembedded.org/g/openembedded-core/message/159690
Mute This Topic: https://lists.openembedded.org/mt/87719024/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 PATCH v2 3/3] selftest: recipetool: Add test for handle_license_vars function

[Richard Purdie]

On Mon, 2021-12-13 at 16:05 +0100, Stefan Herbrechtsmeier wrote:
> From: Stefan Herbrechtsmeier 
> 
> Signed-off-by: Stefan Herbrechtsmeier 
> ---
> 
> (no changes since v1)
> 
>  meta/lib/oeqa/selftest/cases/recipetool.py | 62 ++
>  1 file changed, 62 insertions(+)
> 
> diff --git a/meta/lib/oeqa/selftest/cases/recipetool.py 
> b/meta/lib/oeqa/selftest/cases/recipetool.py
> index 1c73b2c5e0..5330d73cbf 100644
> --- a/meta/lib/oeqa/selftest/cases/recipetool.py
> +++ b/meta/lib/oeqa/selftest/cases/recipetool.py
> @@ -592,6 +592,68 @@ class RecipetoolTests(RecipetoolBase):
>  with open(srcfile, 'w') as fh:
>  fh.writelines(plugincontent)
>  
> +def test_recipetool_handle_license_vars(self):
> +from create import handle_license_vars
> +from unittest.mock import Mock
> +
> +commonlicdir = get_bb_var('COMMON_LICENSE_DIR')
> +
> +d = bb.tinfoil.TinfoilDataStoreConnector
> +d.getVar = Mock(return_value=commonlicdir)
> +
> +srctree = tempfile.mkdtemp(prefix='recipetoolqa')
> +self.track_for_cleanup(srctree)
> +
> +# Multiple licenses
> +licenses = ['MIT', 'ISC', 'BSD-3-Clause', 'Apache-2.0']
> +for licence in licenses:
> +shutil.copy(os.path.join(commonlicdir, licence), 
> os.path.join(srctree, 'LICENSE.' + licence))
> +# Duplicate license
> +shutil.copy(os.path.join(commonlicdir, 'MIT'), os.path.join(srctree, 
> 'LICENSE'))
> +
> +extravalues = {
> +# Duplicate and missing licenses
> +'LICENSE': 'Zlib & BSD-2-Clause & Zlib',
> +'LIC_FILES_CHKSUM': [
> +'file://README.md;md5=0123456789abcdef0123456789abcd'
> +]
> +}
> +lines_before = []
> +handled = []
> +licvalues = handle_license_vars(srctree, lines_before, handled, 
> extravalues, d)
> +expected_lines_before = [
> +'# WARNING: the following LICENSE and LIC_FILES_CHKSUM values 
> are best guesses - it is',
> +'# your responsibility to verify that the values are complete 
> and correct.',
> +'# NOTE: Original package / source metadata indicates license 
> is: BSD-2-Clause & Zlib',
> +'#',
> +'# NOTE: multiple licenses have been detected; they have been 
> separated with &',
> +'# in the LICENSE value for now since it is a reasonable 
> assumption that all',
> +'# of the licenses apply. If instead there is a choice between 
> the multiple',
> +'# licenses then you should change the value to separate the 
> licenses with |',
> +'# instead of &. If there is any doubt, check the accompanying 
> documentation',
> +'# to determine which situation is applicable.',
> +'LICENSE = "Apache-2.0 & BSD-2-Clause & BSD-3-Clause & ISC & MIT 
> & Zlib"',
> +'LIC_FILES_CHKSUM = 
> "file://LICENSE;md5=0835ade698e0bcf8506ecda2f7b4f302 \\\n'
> +'
> file://LICENSE.MIT;md5=0835ade698e0bcf8506ecda2f7b4f302 \\\n'
> +'
> file://LICENSE.ISC;md5=f3b90e78ea0cffb20bf5cca7947a896d \\\n'
> +'
> file://LICENSE.Apache-2.0;md5=89aea4e17d99a7cacdbeed46a0096b10 \\\n'
> +'
> file://LICENSE.BSD-3-Clause;md5=550794465ba0ec5312d6919e203a55f9 \\\n'
> +'
> file://README.md;md5=0123456789abcdef0123456789abcd"',
> +''
> +]
> +self.assertEqual(lines_before, expected_lines_before)
> +expected_licvalues = [
> +('MIT', 'LICENSE', '0835ade698e0bcf8506ecda2f7b4f302'),
> +('MIT', 'LICENSE.MIT', '0835ade698e0bcf8506ecda2f7b4f302'),
> +('ISC', 'LICENSE.ISC', 'f3b90e78ea0cffb20bf5cca7947a896d'),
> +('Apache-2.0', 'LICENSE.Apache-2.0', 
> '89aea4e17d99a7cacdbeed46a0096b10'),
> +('BSD-3-Clause', 'LICENSE.BSD-3-Clause', 
> '550794465ba0ec5312d6919e203a55f9')
> +]
> +self.assertEqual(handled, [('license', expected_licvalues)])
> +self.assertEqual(extravalues, {})
> +self.assertEqual(licvalues, expected_licvalues)
> +
> +
>  def test_recipetool_split_pkg_licenses(self):
>  from create import split_pkg_licenses
>  licvalues = [
> 
> 

The test failed in testing:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2956/steps/14/logs/stdio

Cheers,

Richard



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159689): 
https://lists.openembedded.org/g/openembedded-core/message/159689
Mute This Topic: https://lists.openembedded.org/mt/87699203/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/2] lttng-tools: Backport ptest fix

[Richard Purdie]

Add a backport and a dependency from upstream to help address one of the 
lttng-tools
ptest relayd hangs we've been seeing on the autobuilder.

Signed-off-by: Richard Purdie 
---
 ...0ba19aec78f36e301494a03f5678fcb6fbb4.patch | 218 ++
 ...46a03fbf31c19b85ec367dc2c3db56e6dbf7.patch | 113 +
 .../lttng/lttng-tools_2.13.1.bb   |   2 +
 3 files changed, 333 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/87250ba19aec78f36e301494a03f5678fcb6fbb4.patch
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/8f0646a03fbf31c19b85ec367dc2c3db56e6dbf7.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/87250ba19aec78f36e301494a03f5678fcb6fbb4.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/87250ba19aec78f36e301494a03f5678fcb6fbb4.patch
new file mode 100644
index 000..f4db4f86fed
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/87250ba19aec78f36e301494a03f5678fcb6fbb4.patch
@@ -0,0 +1,218 @@
+Upstream-Status: Backport
+
+From 87250ba19aec78f36e301494a03f5678fcb6fbb4 Mon Sep 17 00:00:00 2001
+From: =?UTF-8?q?J=C3=A9r=C3=A9mie=20Galarneau?=
+ 
+Date: Mon, 1 Nov 2021 15:43:55 -0400
+Subject: [PATCH] Fix: relayd: live: mishandled initial null trace chunk
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+Observed issue
+==
+
+As reported in #1323 (https://bugs.lttng.org/issues/1323), crashes of
+the relay daemon are observed when running the user space clear tests.
+
+The crash occurs with the following stack trace:
+  #0  0x55fbb861d6ae in urcu_ref_get_unless_zero (ref=0x28) at 
/usr/local/include/urcu/ref.h:85
+  #1  lttng_trace_chunk_get (chunk=0x0) at trace-chunk.c:1836
+  #2  0x55fbb86051e2 in make_viewer_streams 
(relay_session=relay_session@entry=0x7f6ea002d540, viewer_session=, seek_t=seek_t@entry=LTTNG_VIEWER_SEEK_BEGINNING, 
nb_total=nb_total@entry=0x7f6ea9607b00, 
nb_unsent=nb_unsent@entry=0x7f6ea9607aec, 
nb_created=nb_created@entry=0x7f6ea9607ae8, closed=) at 
live.c:405
+  #3  0x55fbb86061d9 in viewer_get_new_streams (conn=0x7f6e94000fc0) at 
live.c:1155
+  #4  process_control (conn=0x7f6e94000fc0, recv_hdr=0x7f6ea9607af0) at 
live.c:2353
+  #5  thread_worker (data=) at live.c:2515
+  #6  0x7f6eae86a609 in start_thread () from 
/lib/x86_64-linux-gnu/libpthread.so.0
+  #7  0x7f6eae78f293 in clone () from /lib/x86_64-linux-gnu/libc.so.6
+
+The race window during which this occurs seems very small as it can take
+hours to reproduce this crash. However, a minimal reproducer could be
+identified, as stated in the bug report.
+
+Essentially, the same crash can be reproduced by attaching a live viewer
+to a session that has seen events being produced, been stopped and been
+cleared.
+
+Cause
+=
+
+The crash occurs as an attempt is made to take a reference to a viewer
+session’s trace chunk as viewer streams are created. The crux of the
+problem is that the code doesn’t expect a viewer session’s trace chunk
+to be NULL.
+
+The viewer session’s current trace chunk is initially set, when a viewer
+attaches to the viewer session, to a copy the corresponding
+relay_session’s current trace chunk.
+
+A live session always attempts to "catch-up" to the newest available
+trace chunk. This means that when a viewer reaches the end of a trace
+chunk, the viewer session may not transition to the "next" one: it jumps
+to the most recent trace chunk available (the one being produced by the
+relay_session). Hence, if the producer performs multiple rotations
+before a viewer completes the consumption of a trace chunk, it will skip
+over those "intermediary" trace chunks.
+
+A viewer session updates its current trace chunk when:
+  1) new viewer streams are created,
+  2) a new index is requested,
+  3) metadata is requested.
+
+Hence, as a general principle, the viewer session will reference the
+most recent trace chunk available _even if its streams do not point to
+it_. It indicates which trace chunk viewer streams should transition to
+when the end of their current trace chunk is reached.
+
+The live code properly handles transitions to a null chunk. This can be
+verified by attaching a viewer to a live session, stopping the session,
+clearing it (thus entering a null trace chunk), and resuming tracing.
+
+The only issue is that the case where the first trace chunk of a viewer
+session is "null" (no active trace chunk) is mishandled in two places:
+  1) in make_viewer_streams(), where the crash is observed,
+  2) in viewer_get_metadata().
+
+Solution
+
+
+In make_viewer_streams(), it is assumed that a viewer session will have
+a non-null trace chunk whenever a rotation is not ongoing. This is
+reflected by the fact that a reference is always acquired on the viewer
+session’s trace chunk.
+
+That code is one of the three places that can cause a viewer session’s
+trace chunk to be updated. We still want to update the viewer session to
+the most recently 

[OE-core] [PATCH 2/2] lttng-tools: Disable problem tests

[Richard Purdie]

There is a pattern of the notification tests hanging. Whilst we need to get to 
the
bottom of that, disable them for now as it is causing high load for triage/SWAT
and masking other failures.

[YOCTO #14263]

Signed-off-by: Richard Purdie 
---
 .../lttng/lttng-tools/disable-tests.patch | 34 +++
 .../lttng/lttng-tools_2.13.1.bb   |  1 +
 2 files changed, 35 insertions(+)
 create mode 100644 meta/recipes-kernel/lttng/lttng-tools/disable-tests.patch

diff --git a/meta/recipes-kernel/lttng/lttng-tools/disable-tests.patch 
b/meta/recipes-kernel/lttng/lttng-tools/disable-tests.patch
new file mode 100644
index 000..3a77ea2e439
--- /dev/null
+++ b/meta/recipes-kernel/lttng/lttng-tools/disable-tests.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Inappropriate [need to root cause the test hangs]
+
+We keep seeing hangs in the tools/notifications tests on x86 and arm for
+a variety of distros. Exclude them for now to work out if this is the
+only place we see them and give SWAT/triage a break from the stream
+of them.
+
+https://bugzilla.yoctoproject.org/show_bug.cgi?id=14263
+
+Signed-off-by: Richard Purdie 
+
+Index: lttng-tools-2.13.1/tests/regression/Makefile.am
+===
+--- lttng-tools-2.13.1.orig/tests/regression/Makefile.am
 lttng-tools-2.13.1/tests/regression/Makefile.am
+@@ -29,18 +29,6 @@ TESTS = tools/base-path/test_ust \
+   tools/crash/test_crash \
+   tools/regen-metadata/test_ust \
+   tools/regen-statedump/test_ust \
+-  tools/notification/test_notification_ust_error \
+-  tools/notification/test_notification_ust_buffer_usage \
+-  tools/notification/test_notification_ust_capture \
+-  tools/notification/test_notification_ust_event_rule_condition_exclusion 
\
+-  tools/notification/test_notification_kernel_error \
+-  tools/notification/test_notification_kernel_buffer_usage \
+-  tools/notification/test_notification_kernel_capture \
+-  tools/notification/test_notification_kernel_instrumentation \
+-  tools/notification/test_notification_kernel_syscall \
+-  tools/notification/test_notification_notifier_discarded_count \
+-  tools/notification/test_notification_kernel_userspace_probe \
+-  tools/notification/test_notification_multi_app \
+   tools/rotation/test_ust \
+   tools/rotation/test_kernel \
+   tools/rotation/test_save_load_mi \
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.13.1.bb 
b/meta/recipes-kernel/lttng/lttng-tools_2.13.1.bb
index 187eff9619e..7ae02d92d2d 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.13.1.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.13.1.bb
@@ -39,6 +39,7 @@ SRC_URI = 
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-src-common-correct-header-location.patch \
file://8f0646a03fbf31c19b85ec367dc2c3db56e6dbf7.patch \
file://87250ba19aec78f36e301494a03f5678fcb6fbb4.patch \
+   file://disable-tests.patch \
"
 
 SRC_URI[sha256sum] = 
"cfe6df7da831fc07fd07ce46b442c2ec1074c167af73f3a1b1d2fba0c453c8b5"
-- 
2.32.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159688): 
https://lists.openembedded.org/g/openembedded-core/message/159688
Mute This Topic: https://lists.openembedded.org/mt/87720054/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] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.5_M1.rc2)

[Teoh, Jay Shen]

Hi everyone,

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

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

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

ETA for completion this Friday, 17th of December.

Thanks,
Jay

>-Original Message-
>From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Richard Purdie
>Sent: Sunday, 12 December, 2021 6:49 PM
>To:  
>Cc: qa-build-notification 
>Subject: [qa-build-notification] QA notification for completed autobuilder 
>build
>(yocto-3.5_M1.rc2)
>
>A build flagged for QA (yocto-3.5_M1.rc2) was completed on the autobuilder and
>is available at:
>
>
>https://autobuilder.yocto.io/pub/releases/yocto-3.5_M1.rc2
>
>
>Build hash information:
>
>bitbake: 1ecc1d9424877df89fcda2f23c306998998a65ff
>meta-agl: 6d1ab9f3bb270a773ec5d2f7c8c856796833b559
>meta-arm: d446f7f80bf61e9cf05843e8ef4bc5473f936118
>meta-aws: 8893e0cd4c0981eeda941eaa9ad2eb9359670502
>meta-gplv2: f04e4369bf9dd3385165281b9fa2ed1043b0e400
>meta-intel: aa8482af7b286f8fe8f7aae648938d4ebf0283c5
>meta-mingw: 992fb40bdbfe9fe60f815aac46e04c58963918b5
>meta-openembedded: ba6a16cdca661b2d5251df243dc19bda0e8db651
>oecore: 1a6c2a7345199d77ad5aeac8ad337ed80a8aa39b
>poky: 65c94ca3196e5ef3344a469fea8e30444f2e967a
>
>
>
>This is an automated message from the Yocto Project Autobuilder
>Git: git://git.yoctoproject.org/yocto-autobuilder2
>Email: richard.pur...@linuxfoundation.org
>
>
>
>
>
>
>


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

[OE-core] ROOTFS_POSTPROCESS_COMMAND versus do_install_append() and using ${D}?

[Robert P. J. Day]

  i've run across a moderately curious example of doing rootfs-wide
tweaking in an odd way.

  my understanding is that, after i've created my basic image rootfs,
i can define that image's ROOTFS_POSTPROCESS_COMMAND variable, and do
all sorts of rootfs-wide adjustments relative to ${IMAGE_ROOTFS},
which could include running chown, chmod, setcap, and so on and so on,
tweaking clearly spread over various installed package contents.

  what i'm looking at now does it in a more curious way. there is a
catch-all recipe file (call it "catchall.bb") which lists, as its
DEPENDS list, *all* of the recipes that make up the image, which means
that building catchall.bb builds and populates an image directory with
the combination of all those other recipes, after which it defines
both pkg_postinst_${PN} *and* do_install_append(), both of which run
around and make changes relative to ${D}, given that the image
directory for that recipe effectively contains, well, everything that
will go into the rootfs.

  at the moment, it works, but in a perfect world, i'd refactor all
that stuff and sprinkle it among the respective recipes that that
content relates to. however, just to get this going, my initial
reaction is to take that tweaking, adjust it to refer, not to ${D},
but to ${IMAGE_ROOTFS}, and move it all into
ROOTFS_POSTPROCESS_COMMAND. theoretically, would that be effectively
equivalent?

  i realize there might be some messing around but, in the big
picture, should it have the same effect?

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159685): 
https://lists.openembedded.org/g/openembedded-core/message/159685
Mute This Topic: https://lists.openembedded.org/mt/87719024/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] cups: fix typo in flags to disable avahi

[S. Lockwood-Childs]

one too many 's': dnsssd -> dnssd

Signed-off-by: S. Lockwood-Childs 
---
 meta/recipes-extended/cups/cups.inc | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-extended/cups/cups.inc 
b/meta/recipes-extended/cups/cups.inc
index 3175a91ce4..05c1e34a77 100644
--- a/meta/recipes-extended/cups/cups.inc
+++ b/meta/recipes-extended/cups/cups.inc
@@ -40,7 +40,7 @@ SYSTEMD_SERVICE:${PN} = "cups.socket cups.path cups.service 
cups-lpd.socket"
 
 PACKAGECONFIG ??= "${@bb.utils.contains('DISTRO_FEATURES', 'zeroconf', 
'avahi', '', d)} \
${@bb.utils.filter('DISTRO_FEATURES', 'pam systemd', d)}"
-PACKAGECONFIG[avahi] = "--with-dnssd=avahi,--with-dnsssd=no,avahi"
+PACKAGECONFIG[avahi] = "--with-dnssd=avahi,--with-dnssd=no,avahi"
 PACKAGECONFIG[acl] = "--enable-acl,--disable-acl,acl"
 PACKAGECONFIG[gnutls] = "--with-tls=gnutls,--with-tls=no,gnutls"
 PACKAGECONFIG[pam] = "--enable-pam --with-pam-module=unix, --disable-pam, 
libpam"
-- 
2.20.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#159683): 
https://lists.openembedded.org/g/openembedded-core/message/159683
Mute This Topic: https://lists.openembedded.org/mt/87718412/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] bluez: fix CVE-2021-0129

[Marta Rybczynska]

From: Marta Rybczynska 

Improper access control in BlueZ may allow an authenticated user to
potentially enable information disclosure via adjacent access.

This issue can be fixed in the kernel, in BlueZ or both. This patch
fixes it on the BlueZ side, so that the configuration no longer
depends on the kernel fix.

https://nvd.nist.gov/vuln/detail/CVE-2021-012

Signed-off-by: Marta Rybczynska 
---
 meta/recipes-connectivity/bluez5/bluez5.inc   |   1 +
 .../bluez5/bluez5/CVE-2021-0129.patch | 109 ++
 2 files changed, 110 insertions(+)
 create mode 100644 meta/recipes-connectivity/bluez5/bluez5/CVE-2021-0129.patch

diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
b/meta/recipes-connectivity/bluez5/bluez5.inc
index 202a14dee0..34796fdd20 100644
--- a/meta/recipes-connectivity/bluez5/bluez5.inc
+++ b/meta/recipes-connectivity/bluez5/bluez5.inc
@@ -52,6 +52,7 @@ SRC_URI = 
"${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} \

file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
file://0001-test-gatt-Fix-hung-issue.patch \
+   file://CVE-2021-0129.patch \
file://CVE-2021-3588.patch \
"
 S = "${WORKDIR}/bluez-${PV}"
diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2021-0129.patch 
b/meta/recipes-connectivity/bluez5/bluez5/CVE-2021-0129.patch
new file mode 100644
index 00..b39730dc10
--- /dev/null
+++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2021-0129.patch
@@ -0,0 +1,109 @@
+From 00da0fb4972cf59e1c075f313da81ea549cb8738 Mon Sep 17 00:00:00 2001
+From: Luiz Augusto von Dentz 
+Date: Tue, 2 Mar 2021 11:38:33 -0800
+Subject: shared/gatt-server: Fix not properly checking for secure flags
+
+When passing the mask to check_permissions all valid permissions for
+the operation must be set including BT_ATT_PERM_SECURE flags.
+
+Upstream-Status: Backport 
[https://git.kernel.org/pub/scm/bluetooth/bluez.git/patch/?id=00da0fb4972cf59e1c075f313da81ea549cb8738]
+Signed-off-by: Marta Rybczynska 
+CVE: CVE-2021-0129
+---
+ src/shared/att-types.h   |  8 
+ src/shared/gatt-server.c | 25 +++--
+ 2 files changed, 15 insertions(+), 18 deletions(-)
+
+diff --git a/src/shared/att-types.h b/src/shared/att-types.h
+index 7108b4e94..3adc05d9e 100644
+--- a/src/shared/att-types.h
 b/src/shared/att-types.h
+@@ -129,6 +129,14 @@ struct bt_att_pdu_error_rsp {
+ #define BT_ATT_PERM_WRITE_SECURE  0x0200
+ #define BT_ATT_PERM_SECURE(BT_ATT_PERM_READ_SECURE | \
+   BT_ATT_PERM_WRITE_SECURE)
++#define BT_ATT_PERM_READ_MASK (BT_ATT_PERM_READ | \
++  BT_ATT_PERM_READ_AUTHEN | \
++  BT_ATT_PERM_READ_ENCRYPT | \
++  BT_ATT_PERM_READ_SECURE)
++#define BT_ATT_PERM_WRITE_MASK(BT_ATT_PERM_WRITE | \
++  BT_ATT_PERM_WRITE_AUTHEN | \
++  BT_ATT_PERM_WRITE_ENCRYPT | \
++  BT_ATT_PERM_WRITE_SECURE)
+ 
+ /* GATT Characteristic Properties Bitfield values */
+ #define BT_GATT_CHRC_PROP_BROADCAST   0x01
+diff --git a/src/shared/gatt-server.c b/src/shared/gatt-server.c
+index b5f7de7dc..970c35f94 100644
+--- a/src/shared/gatt-server.c
 b/src/shared/gatt-server.c
+@@ -444,9 +444,7 @@ static void process_read_by_type(struct async_read_op *op)
+   return;
+   }
+ 
+-  ecode = check_permissions(server, attr, BT_ATT_PERM_READ |
+-  BT_ATT_PERM_READ_AUTHEN |
+-  BT_ATT_PERM_READ_ENCRYPT);
++  ecode = check_permissions(server, attr, BT_ATT_PERM_READ_MASK);
+   if (ecode)
+   goto error;
+ 
+@@ -811,9 +809,7 @@ static void write_cb(struct bt_att_chan *chan, uint8_t 
opcode, const void *pdu,
+   (opcode == BT_ATT_OP_WRITE_REQ) ? "Req" : "Cmd",
+   handle);
+ 
+-  ecode = check_permissions(server, attr, BT_ATT_PERM_WRITE |
+-  BT_ATT_PERM_WRITE_AUTHEN |
+-  BT_ATT_PERM_WRITE_ENCRYPT);
++  ecode = check_permissions(server, attr, BT_ATT_PERM_WRITE_MASK);
+   if (ecode)
+   goto error;
+ 
+@@ -913,9 +909,7 @@ static void handle_read_req(struct bt_att_chan *chan,
+   opcode == BT_ATT_OP_READ_BLOB_REQ ? "Blob " : "",
+   handle);
+ 
+-  ecode = check_permissions(server, attr, BT_ATT_PERM_READ |
+-  BT_ATT_PERM_READ_AUTHEN |
+-