Re: [OE-core] [PATCH] linux-yocto/5.10: update qemuriscv32 v5.10.23

[Khem Raj]

On 3/22/21 11:44 AM, Bruce Ashfield wrote:

From: Bruce Ashfield 

The kernel SRCREV updates were missing riscv32, so stayed back on
5.10.21, which causes build issues as PV is out of sync with the
actual kernel version.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index 9c122832f4..83e70d01d1 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -18,7 +18,7 @@ SRCREV_machine_qemuarm64 ?= 
"04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
  SRCREV_machine_qemumips ?= "68527a50a2f5b0992ba85255325d76a9f187c237"
  SRCREV_machine_qemuppc ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
  SRCREV_machine_qemuriscv64 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
-SRCREV_machine_qemuriscv32 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_qemuriscv32 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
  SRCREV_machine_qemux86 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
  SRCREV_machine_qemux86-64 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
  SRCREV_machine_qemumips64 ?= "c19b50af1e3680ff6050a0cce8dcd888accafd9b"



I wonder if we really need to lock the machines using tip of
v5.10/standard/base e.g. x86/x86_64/ppc64/rv64/rv32






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149808): 
https://lists.openembedded.org/g/openembedded-core/message/149808
Mute This Topic: https://lists.openembedded.org/mt/81532821/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] go-helloworld: disable module-aware mode

[Changqing Li]

On 3/23/21 1:17 AM, Konrad Weihmann wrote:

[Please note: This e-mail is from an EXTERNAL e-mail address]

On 22.03.21 04:23, Changqing Li wrote:

From: Changqing Li 

 From go 1.16, module-aware mode is enabled by default, regardless of
whether a go.mod file is present in the current working directory or a
parent directory.

Above change makes go-helloworld build fail when doing offline build or
proxy.golang.org is not accessible.


I'm not a go expert, but I understood the changelog [1] differently and
IMO export GO111MODULE="auto" would restore the same behavior as before
the update to go 1.16.


when GO111MODULE="auto" , actually to use "off" mode (GPPATH mode) or

"on" mode(module-aware mode) is decided by existing of "go.mod".

after revert SRCREV, there is no go.mod.  so it works in off mode 
actually. so, set it directly to off here.


set to "auto" also works.


And if not it would make the whole go-mod.bbclass somehow obsolete,
right - so it should be removed, or at least a sanity check should be
added, that the class is not safe to be used with BB_NO_NETWORK

[1] https://blog.golang.org/go116-module-changes



This fix is kind of workaround, as from go1.17, GOPATH mode will be
dropped, and GO111MODULE is ignored.

Signed-off-by: Changqing Li 
---
  meta/recipes-extended/go-examples/go-helloworld_0.1.bb | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/go-examples/go-helloworld_0.1.bb 
b/meta/recipes-extended/go-examples/go-helloworld_0.1.bb

index d3f7525dc9..c51f163e9b 100644
--- a/meta/recipes-extended/go-examples/go-helloworld_0.1.bb
+++ b/meta/recipes-extended/go-examples/go-helloworld_0.1.bb
@@ -6,14 +6,15 @@ LICENSE = "MIT"
  LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"


  SRC_URI = "git://${GO_IMPORT}"
-SRCREV = "bcf50bfd7dcd8020c90965747d857ae42802e0c5"
+SRCREV = "46695d81d1fae905a270fb7db8a4d11a334562fe"
  UPSTREAM_CHECK_COMMITS = "1"

  GO_IMPORT = "github.com/golang/example"
  GO_INSTALL = "${GO_IMPORT}/hello"
  GO_WORKDIR = "${GO_INSTALL}"
+export GO111MODULE="off"

-inherit go-mod
+inherit go

  # This is just to make clear where this example is
  do_install_append() {










-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149807): 
https://lists.openembedded.org/g/openembedded-core/message/149807
Mute This Topic: https://lists.openembedded.org/mt/81516655/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] openssh: correct LICENSE

[wangmy]

From: Wang Mingyu 

update LICENSE to show that BSD-2-Clause, BSD-3-Clause and BSD-4-Clause are all 
present.

Signed-off-by: Wang Mingyu 
---
 meta/recipes-connectivity/openssh/openssh_8.5p1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssh/openssh_8.5p1.bb 
b/meta/recipes-connectivity/openssh/openssh_8.5p1.bb
index 61d9b95b9e..6a49cf71cc 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.5p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.5p1.bb
@@ -5,7 +5,7 @@ Ssh (Secure Shell) is a program for logging into a remote 
machine \
 and for executing commands on a remote machine."
 HOMEPAGE = "http://www.openssh.com/;
 SECTION = "console/network"
-LICENSE = "BSD & ISC & MIT"
+LICENSE = "BSD-2-Clause & BSD-3-Clause & BSD-4-Clause & BSD & ISC & MIT"
 LIC_FILES_CHKSUM = "file://LICENCE;md5=d9d2753bdef9f19466dc7bc959114b11"
 
 DEPENDS = "zlib openssl virtual/crypt"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149806): 
https://lists.openembedded.org/g/openembedded-core/message/149806
Mute This Topic: https://lists.openembedded.org/mt/81541821/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] openssh: upgrade 8.4p1 -> 8.5p1

[wangmy]

From: Wang Mingyu 

0f90440ca70abab947acbd77795e9f130967956c.patch
removed since it is included in 8.5p1

License Updated :
2-clause BSD license and 4-clause BSD license added

Signed-off-by: Wang Mingyu 
---
 ...440ca70abab947acbd77795e9f130967956c.patch | 28 ---
 .../{openssh_8.4p1.bb => openssh_8.5p1.bb}|  5 ++--
 2 files changed, 2 insertions(+), 31 deletions(-)
 delete mode 100644 
meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
 rename meta/recipes-connectivity/openssh/{openssh_8.4p1.bb => 
openssh_8.5p1.bb} (97%)

diff --git 
a/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
 
b/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
deleted file mode 100644
index b88bc18f12..00
--- 
a/meta/recipes-connectivity/openssh/openssh/0f90440ca70abab947acbd77795e9f130967956c.patch
+++ /dev/null
@@ -1,28 +0,0 @@
-From 0f90440ca70abab947acbd77795e9f130967956c Mon Sep 17 00:00:00 2001
-From: Darren Tucker 
-Date: Fri, 20 Nov 2020 13:37:54 +1100
-Subject: [PATCH] Add new pselect6_time64 syscall on ARM.
-
-This is apparently needed on armhfp/armv7hl.  bz#3232, patch from
-jjelen at redhat.com.

- sandbox-seccomp-filter.c | 3 +++
- 1 file changed, 3 insertions(+)
-
-Upstream-Status: Backport
-[fixes issues on 32bit IA and probably other 32 bit platforms too with glibc 
2.33]
-
-diff --git a/sandbox-seccomp-filter.c b/sandbox-seccomp-filter.c
-index e0768c063..5065ae7ef 100644
 a/sandbox-seccomp-filter.c
-+++ b/sandbox-seccomp-filter.c
-@@ -267,6 +267,9 @@ static const struct sock_filter preauth_insns[] = {
- #ifdef __NR_pselect6
-   SC_ALLOW(__NR_pselect6),
- #endif
-+#ifdef __NR_pselect6_time64
-+  SC_ALLOW(__NR_pselect6_time64),
-+#endif
- #ifdef __NR_read
-   SC_ALLOW(__NR_read),
- #endif
diff --git a/meta/recipes-connectivity/openssh/openssh_8.4p1.bb 
b/meta/recipes-connectivity/openssh/openssh_8.5p1.bb
similarity index 97%
rename from meta/recipes-connectivity/openssh/openssh_8.4p1.bb
rename to meta/recipes-connectivity/openssh/openssh_8.5p1.bb
index 128e2e318a..61d9b95b9e 100644
--- a/meta/recipes-connectivity/openssh/openssh_8.4p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_8.5p1.bb
@@ -6,7 +6,7 @@ and for executing commands on a remote machine."
 HOMEPAGE = "http://www.openssh.com/;
 SECTION = "console/network"
 LICENSE = "BSD & ISC & MIT"
-LIC_FILES_CHKSUM = "file://LICENCE;md5=18d9e5a8b3dd1790d73502f50426d4d3"
+LIC_FILES_CHKSUM = "file://LICENCE;md5=d9d2753bdef9f19466dc7bc959114b11"
 
 DEPENDS = "zlib openssl virtual/crypt"
 DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 'pam', 'libpam', '', d)}"
@@ -24,9 +24,8 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://fix-potential-signed-overflow-in-pointer-arithmatic.patch \
file://sshd_check_keys \
file://add-test-support-for-busybox.patch \
-   file://0f90440ca70abab947acbd77795e9f130967956c.patch \
"
-SRC_URI[sha256sum] = 
"5a01d22e407eb1c05ba8a8f7c654d388a13e9f226e4ed33bd38748dafa1d2b24"
+SRC_URI[sha256sum] = 
"f52f3f41d429aa9918e38cf200af225ccdd8e66f052da572870c89737646ec25"
 
 # This CVE is specific to OpenSSH server, as used in Fedora and Red Hat 
Enterprise Linux 7
 # and when running in a Kerberos environment. As such it is not relevant to 
OpenEmbedded
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149805): 
https://lists.openembedded.org/g/openembedded-core/message/149805
Mute This Topic: https://lists.openembedded.org/mt/81541820/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] really strange usage of FILESPATH and FILESEXTRAPATHS

[Andre McCurdy]

On Mon, Mar 22, 2021 at 2:29 PM Robert P. J. Day  wrote:
>
>   here's the next head-scratching oddity i just ran across in the
> current layer (and there's more weirdness on its way).
>
>   perusing a recipe only to see:
>
>   FILESPATH =+ "${COMMON_STUFF_DIR}:"
>   SRC_URI += "file://file1 file://file2 file://file 3 ... etc ..."
>
> ok ... apparently, there are a number of recipes that want access to
> some small set of common files, so the solution(?) was to put those
> common files in some (out-of-layer) directory, and prepend to
> FILESPATH in each of those recipe files so that SRC_URI could find
> them.
>
>   i am not going to ask if this is some wickedly clever trick, since
> it can't be. it just can't.

It's unconventional, but I guess it will work OK (i.e. it won't have
any surprising or negative side effects).

It's better than (for example) one recipe fetching source from the
build directory of another recipe - which obviously breaks if you
don't somehow guarantee the order in which recipes are (re)built. I've
seen projects which did things like that and then needed to disable
sstate for CI and release builds as a workaround...

>   even stranger, one of the common files was a configuration script
> that contributed the line:
>
>   . config.sh
>
> to the top of a number of common tasks like do_configure, do_compile,
> do_install and so on.

It's not clear how a common file in SRC_URI could affect any tasks?

>   a similar tactic was to find this line in a class file:
>
>   FILESEXTRAPATHS_prepend := "${COMMON_STUFF_DIR}:"
>
> my head hurts.
>
>   first, if i needed to do something in common at the beginning of
> some basic tasks, i'd invent a bbclass file that "_prepend"ed to those
> tasks, and just inherit it when necessary.
>
>   as for a number of recipes needing access to common files for any
> reason, well, thoughts? my first thought is to encapsulate those files
> in a separate recipe, then make that recipe a build dependency so that
> those files would be available from the sysroot, but i'm sure there
> are better ideas.

Build dependencies are heavily geared towards libraries and header
files rather than common source files. See SYSROOT_DIRS and
SYSROOT_DIRS_BLACKLIST in staging.bbclass, which limit which
directories get staged in sysroot. You would need to navigate your way
around that (e.g. ensuring that the common source files get staged in
sysroot without being included in the final image, etc). Certainly
doable, but I guess too far up the OE learning cliff for most typical
users.

Adding the common source files to SRC_URI for each recipe which needs
them (whether as individual files from a local directory, as in your
example, or as a single tar file or git repo from a remote server) is
probably the better approach.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149804): 
https://lists.openembedded.org/g/openembedded-core/message/149804
Mute This Topic: https://lists.openembedded.org/mt/81536884/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] [gatesgarth][PATCH 01/30] initrdscripts: init-install-efi.sh install extra files for ESP

[Steve Sakoman]

On Sun, Mar 21, 2021 at 10:57 PM Lee Chee Yang  wrote:
>
> Hi,
>
> Can this backport to Dunfell too?

Yes, I'll take care of it.

Steve

>
> >-Original Message-
> >From: openembedded-core@lists.openembedded.org  >c...@lists.openembedded.org> On Behalf Of Anuj Mittal
> >Sent: Tuesday, 23 February, 2021 12:00 AM
> >To: openembedded-core@lists.openembedded.org
> >Subject: [OE-core] [gatesgarth][PATCH 01/30] initrdscripts: 
> >init-install-efi.sh
> >install extra files for ESP
> >
> >From: Chee Yang Lee 
> >
> >Currently the install script copy only few hard coded item while setting up 
> >target
> >ESP, kernel artifacts, all .efi in EFI/BOOT, grub & boot cfg and loader.conf.
> >While ESP can be much complex, eg: contain multiple initrd.
> >
> >Add a ESP folder to carry any other files to setup onto ESP.
> >
> >Signed-off-by: Chee Yang Lee 
> >Signed-off-by: Richard Purdie 
> >(cherry picked from commit 6eaca9cf20c42501fba27dea3a6446bad948e859)
> >Signed-off-by: Anuj Mittal 
> >---
> > meta/recipes-core/initrdscripts/files/init-install-efi.sh | 5 +
> > 1 file changed, 5 insertions(+)
> >
> >diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
> >b/meta/recipes-
> >core/initrdscripts/files/init-install-efi.sh
> >index b6855b5aac..f667518b89 100644
> >--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> >+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
> >@@ -279,6 +279,11 @@ fi
> >
> > umount /tgt_root
> >
> >+# copy any extra files needed for ESP
> >+if [ -d /run/media/$1/esp ]; then
> >+cp -r /run/media/$1/esp/* /boot
> >+fi
> >+
> > # Copy kernel artifacts. To add more artifacts just add to types  # For now 
> > just
> >support kernel types already being used by something in OE-core  for types in
> >bzImage zImage vmlinux vmlinuz fitImage; do
> >--
> >2.29.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149803): 
https://lists.openembedded.org/g/openembedded-core/message/149803
Mute This Topic: https://lists.openembedded.org/mt/80827809/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] site/elfutils/libunistring: Drop patching for iconv and set in site file

[Richard Purdie]

The standard macros from gettext for iconv include problematic tests which
we've been patching out adhoc. Stop doing this and set results in the site
files instead which is simpler, more maintainable and peforms better too
as an added bonus.

Signed-off-by: Richard Purdie 
---
 .../elfutils/elfutils_0.183.bb|  1 -
 ...4-Disable-the-test-to-convert-euc-jp.patch | 42 --
 ...m4-remove-the-test-to-convert-euc-jp.patch | 56 ---
 .../libunistring/libunistring_0.9.10.bb   |  1 -
 meta/site/common-linux|  3 +
 5 files changed, 3 insertions(+), 100 deletions(-)
 delete mode 100644 
meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
 delete mode 100644 
meta/recipes-support/libunistring/libunistring/iconv-m4-remove-the-test-to-convert-euc-jp.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.183.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.183.bb
index 16ed7c9ddbf..c0833686de9 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.183.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.183.bb
@@ -14,7 +14,6 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://0001-dso-link-change.patch \
file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
file://0003-fixheadercheck.patch \
-   file://0004-Disable-the-test-to-convert-euc-jp.patch \
file://0006-Fix-build-on-aarch64-musl.patch \
file://0001-libasm-may-link-with-libbz2-if-found.patch \

file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
diff --git 
a/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
 
b/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
deleted file mode 100644
index f407bdd0be5..000
--- 
a/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From cd36f34c722dd0babd7beb13c968aa0780c9f726 Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Tue, 15 Aug 2017 17:24:06 +0800
-Subject: [PATCH] Disable the test to convert euc-jp
-
-Remove the test "Test against HP-UX 11.11 bug:
-No converter from EUC-JP to UTF-8 is provided"
-since we don't support HP-UX and if the euc-jp is not
-installed on the host, the dependence will be built without
-iconv support and will cause guild-native building fail.
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Roy Li 
-
-Rebase to 0.170
-Signed-off-by: Hongxu Jia 
-

- m4/iconv.m4 | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/m4/iconv.m4 b/m4/iconv.m4
-index aa159c5..d16312b 100644
 a/m4/iconv.m4
-+++ b/m4/iconv.m4
-@@ -165,6 +165,7 @@ AC_DEFUN([AM_ICONV_LINK],
-   }
-   }
- #endif
-+#if 0
-   /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
-  provided.  */
-   if (/* Try standardized names.  */
-@@ -176,6 +177,7 @@ AC_DEFUN([AM_ICONV_LINK],
-   /* Try HP-UX names.  */
-   && iconv_open ("utf8", "eucJP") == (iconv_t)(-1))
- result |= 16;
-+#endif
-   return result;
- ]])],
-   [am_cv_func_iconv_works=yes], ,
diff --git 
a/meta/recipes-support/libunistring/libunistring/iconv-m4-remove-the-test-to-convert-euc-jp.patch
 
b/meta/recipes-support/libunistring/libunistring/iconv-m4-remove-the-test-to-convert-euc-jp.patch
deleted file mode 100644
index 9e8ce2270da..000
--- 
a/meta/recipes-support/libunistring/libunistring/iconv-m4-remove-the-test-to-convert-euc-jp.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 30562065ba9e4c238e76100b5f9f0c5add0e635b Mon Sep 17 00:00:00 2001
-From: Jackie Huang 
-Date: Tue, 5 Dec 2017 09:30:36 +0200
-Subject: [PATCH] remove the test to convert euc-jp
-
-Remove the test "Test against HP-UX 11.11 bug:
-No converter from EUC-JP to UTF-8 is provided"
-since we don't support HP-UX and if the euc-jp is not
-installed on the host, libunistring will be built without
-iconv support and will cause guild-native configure fail.
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Jackie Huang 


- gnulib-m4/iconv.m4 | 23 ---
- 1 file changed, 23 deletions(-)
-
-diff --git a/gnulib-m4/iconv.m4 b/gnulib-m4/iconv.m4
-index b33ecd0..73b6aa1 100644
 a/gnulib-m4/iconv.m4
-+++ b/gnulib-m4/iconv.m4
-@@ -165,29 +165,6 @@ AC_DEFUN([AM_ICONV_LINK],
-   }
-   }
- #endif
--  /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
-- provided.  */
--  {
--/* Try standardized names.  */
--iconv_t cd1 = iconv_open ("UTF-8", "EUC-JP");
--/* Try IRIX, OSF/1 names.  */
--iconv_t cd2 = iconv_open ("UTF-8", "eucJP");
--/* Try AIX names.  */
--iconv_t cd3 = iconv_open ("UTF-8", "IBM-eucJP");
--/* Try HP-UX names.  */
--iconv_t cd4 = iconv_open ("utf8", "eucJP");
--if (cd1 == (iconv_t)(-1) && cd2 == (iconv_t)(-1)
--&& cd3 == (iconv_t)(-1) && cd4 == 

[OE-core] really strange usage of FILESPATH and FILESEXTRAPATHS

[Robert P. J. Day]

  here's the next head-scratching oddity i just ran across in the
current layer (and there's more weirdness on its way).

  perusing a recipe only to see:

  FILESPATH =+ "${COMMON_STUFF_DIR}:"
  SRC_URI += "file://file1 file://file2 file://file 3 ... etc ..."

ok ... apparently, there are a number of recipes that want access to
some small set of common files, so the solution(?) was to put those
common files in some (out-of-layer) directory, and prepend to
FILESPATH in each of those recipe files so that SRC_URI could find
them.

  i am not going to ask if this is some wickedly clever trick, since
it can't be. it just can't.

  even stranger, one of the common files was a configuration script
that contributed the line:

  . config.sh

to the top of a number of common tasks like do_configure, do_compile,
do_install and so on.

  a similar tactic was to find this line in a class file:

  FILESEXTRAPATHS_prepend := "${COMMON_STUFF_DIR}:"

my head hurts.

  first, if i needed to do something in common at the beginning of
some basic tasks, i'd invent a bbclass file that "_prepend"ed to those
tasks, and just inherit it when necessary.

  as for a number of recipes needing access to common files for any
reason, well, thoughts? my first thought is to encapsulate those files
in a separate recipe, then make that recipe a build dependency so that
those files would be available from the sysroot, but i'm sure there
are better ideas.

  are there any OE recipes that demonstrate this sort of thing?
because extending FILESPATH to arbitrary out-of-layer directories just
makes me want to strangle kittens.

rday


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149801): 
https://lists.openembedded.org/g/openembedded-core/message/149801
Mute This Topic: https://lists.openembedded.org/mt/81536884/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] curious about weirdness in some FILES_${PN} settings

[Robert P. J. Day]

... snipping some stuff ...

On Mon, 22 Mar 2021, Andre McCurdy wrote:

> On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day  
> wrote:
> >
> >   in one recipe, i see the following snippet:
> >
> >   FILES_${PN} += "/etc"
> >   FILES_${PN} += "/etc/mosquitto"
> >   FILES_${PN} += "/etc/mosquitto/config"
> >   ... etc etc ...

... snip ...

> Yes, and even beyond that, ${sysconfdir} is handled by the default
> packaging rules, so any extra packaging rules related to adding
> files from /etc to the default package are redundant.

  actually, i neglected to mention that, just before all that FILES
assignment, the recipe totally redefined the PACKAGES variable, so
even the standard packaging rules had been thrown out the window and
replaced in their entirety.

  that will be another of my "please don't do stuff like that" list i
am working on.

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149800): 
https://lists.openembedded.org/g/openembedded-core/message/149800
Mute This Topic: https://lists.openembedded.org/mt/81532778/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 Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

The triage team is starting to try and collect up and classify bugs which a
newcomer to the project would be able to work on in a way which means people
can find them. They're being listed on the triage page under the appropriate
heading:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Newcomer_Bugs  Also please
review:
https://www.openembedded.org/wiki/How_to_submit_a_patch_to_OpenEmbedded and
how to create a bugzilla account at:

https://bugzilla.yoctoproject.org/createaccount.cgi

The idea is these bugs should be straight forward for a person to help work
on who doesn't have deep experience with the project.  If anyone can help,
please take ownership of the bug and send patches!  If anyone needs
help/advice there are people on irc who can likely do so, or some of the
more experienced contributors will likely be happy to help too.

 

Also, the triage team meets weekly and does its best to handle the bugs
reported into the Bugzilla. The number of people attending that meeting has
fallen, as have the number of people available to help fix bugs. One of the
things we hear users report is they don't know how to help. We (the triage
team) are therefore going to start reporting out the currently 366
unassigned or newcomer bugs.

 

We're hoping people may be able to spare some time now and again to help out
with these.  Bugs are split into two types, "true bugs" where things don't
work as they should and "enhancements" which are features we'd want to add
to the system.  There are also roughly four different "priority" classes
right now, "3.2", "3.3, "3.99" and "Future", the more pressing/urgent issues
being in "3.2" and then "3.3".

 

Please review this link and if a bug is something you would be able to help
with either take ownership of the bug, or send me (sjolley.yp...@gmail.com
 ) an e-mail with the bug number you would
like and I will assign it to you (please make sure you have a Bugzilla
account).  The list is at:
https://wiki.yoctoproject.org/wiki/Bug_Triage_Archive#Unassigned_or_Newcomer
_Bugs

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

* Email:  sjolley.yp...@gmail.com
 

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149799): 
https://lists.openembedded.org/g/openembedded-core/message/149799
Mute This Topic: https://lists.openembedded.org/mt/81535643/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 weirdness of bbappend'ing to stock OE images

[Robert P. J. Day]

On Mon, 22 Mar 2021, Andre McCurdy wrote:

> On Mon, Mar 22, 2021 at 12:50 PM Robert P. J. Day  
> wrote:
> >
> >   more a style issue than anything else, but one of the other
> > oddities in this layer i've been handed is the bbappending to
> > standard OE images, so that recipes-core/images/ contains recipe
> > files like:
> >
> >   core-image-minimal.bbappend
> >   core-image-minimal-dev.bbappend
> >
> > and so on. that just creeps me out -- my plan is to forcefully
> > advise people to leave the stock images alone, and create clearly
> > internal, proprietary ones, like:
> >
> >   acme-core-image-minimal.bb
>
> A clearly internal proprietary image would remove the reference to
> oe-core from the image name, so "acme-image-minimal.bb" rather than
> "acme-core-image-minimal.bb".

  ah, quite so, that would be better.

> > that inherit or include, then do the adjusting.
> >
> >   or is that approach considered acceptable? (it just makes me cringe,
> > personally.)
>
> I don't know. Adding to the core images doesn't seem like the worst
> thing someone could do. After all, it's normal to add to or modify
> the package groups which go into the core images (either directly or
> indirectly by changing distro features).
>
> Creating your own dedicated images is cleaner and clearer though.

  my view is that i like to leave the stock images as they are for
testing purposes -- if the proprietary image has problems, you always
have a stock image to use as a baseline for testing. so that's being
added to my list of "please don't do stuff like that."

  more weirdness coming shortly ...

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149798): 
https://lists.openembedded.org/g/openembedded-core/message/149798
Mute This Topic: https://lists.openembedded.org/mt/81534425/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 weirdness of bbappend'ing to stock OE images

[Andre McCurdy]

On Mon, Mar 22, 2021 at 12:50 PM Robert P. J. Day  wrote:
>
>
>   more a style issue than anything else, but one of the other oddities
> in this layer i've been handed is the bbappending to standard OE
> images, so that recipes-core/images/ contains recipe files like:
>
>   core-image-minimal.bbappend
>   core-image-minimal-dev.bbappend
>
> and so on. that just creeps me out -- my plan is to forcefully advise
> people to leave the stock images alone, and create clearly internal,
> proprietary ones, like:
>
>   acme-core-image-minimal.bb

A clearly internal proprietary image would remove the reference to
oe-core from the image name, so "acme-image-minimal.bb" rather than
"acme-core-image-minimal.bb".

> that inherit or include, then do the adjusting.
>
>   or is that approach considered acceptable? (it just makes me cringe,
> personally.)

I don't know. Adding to the core images doesn't seem like the worst
thing someone could do. After all, it's normal to add to or modify the
package groups which go into the core images (either directly or
indirectly by changing distro features).

Creating your own dedicated images is cleaner and clearer though.

> rday
>
> 
>

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

[OE-core] the weirdness of bbappend'ing to stock OE images

[Robert P. J. Day]

  more a style issue than anything else, but one of the other oddities
in this layer i've been handed is the bbappending to standard OE
images, so that recipes-core/images/ contains recipe files like:

  core-image-minimal.bbappend
  core-image-minimal-dev.bbappend

and so on. that just creeps me out -- my plan is to forcefully advise
people to leave the stock images alone, and create clearly internal,
proprietary ones, like:

  acme-core-image-minimal.bb

that inherit or include, then do the adjusting.

  or is that approach considered acceptable? (it just makes me cringe,
personally.)

rday

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149796): 
https://lists.openembedded.org/g/openembedded-core/message/149796
Mute This Topic: https://lists.openembedded.org/mt/81534425/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] curious about weirdness in some FILES_${PN} settings

[Andre McCurdy]

On Mon, Mar 22, 2021 at 11:43 AM Robert P. J. Day  wrote:
>   (warning: i've just been handed an existing OE code base, and i'm
> going to ask some questions about some head-scratching things i'm
> finding in it, so be prepared for weird questions.)
>
>   in one recipe, i see the following snippet:
>
>   FILES_${PN} += "/etc"
>   FILES_${PN} += "/etc/mosquitto"
>   FILES_${PN} += "/etc/mosquitto/config"
>   ... etc etc ...
>
> first, i'm taken aback by the hardcoding of "/etc" rather than using,
> you know, "${sysconfdir}", so i'm *assuming* that unless someone was
> doing something spectacularly clever here, that just can't be right.

Nothing clever going on, it's just a bug. In general, using /etc
instead of ${sysconfdir} etc will appear to work fine until you add
BBCLASSEXTEND and try to build -native, at which point things
will start to fail in mysterious ways (since native.bbclass over-rides
the default values of ${sysconfdir} etc).

In this particular case, you might still get away with it since
FILES_${PN} is related to packaging and -native recipes don't do any
packaging but it's still not right.

>   more to the point, the above seems redundant -- once you've added
> "/etc", isn't the rest just superfluous? i'm not sure what the
> original developer was going for here. thoughts?

Yes, and even beyond that, ${sysconfdir} is handled by the default
packaging rules, so any extra packaging rules related to adding files
from /etc to the default package are redundant.

>   finally, if i wanted to add all of some directory, say "dir", it was
> my understanding that all of the following were equivalent (h,
> short of picking up hidden files, i guess):
>
>   dir
>   dir/
>   dir/*
>
> my personal preference would be "dir/", as it gets across the idea
> that "dir" is a directory and i want all of it. thoughts on that as
> well? i'm currently perusing the OE code base to see the general
> consensus on this. is there one?

That's more a question of coding style, which the OE maintainers etc
generally doesn't care about very much (unless you start asking about
unifying oe-core and meta-oe with respect to indenting with tabs or
spaces...).

>   more decidedly strange questions coming shortly ...
>
> rday
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149795): 
https://lists.openembedded.org/g/openembedded-core/message/149795
Mute This Topic: https://lists.openembedded.org/mt/81532778/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] linux-yocto/5.10: update qemuriscv32 v5.10.23

[Bruce Ashfield]

From: Bruce Ashfield 

The kernel SRCREV updates were missing riscv32, so stayed back on
5.10.21, which causes build issues as PV is out of sync with the
actual kernel version.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto_5.10.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
index 9c122832f4..83e70d01d1 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.10.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.10.bb
@@ -18,7 +18,7 @@ SRCREV_machine_qemuarm64 ?= 
"04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
 SRCREV_machine_qemumips ?= "68527a50a2f5b0992ba85255325d76a9f187c237"
 SRCREV_machine_qemuppc ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
 SRCREV_machine_qemuriscv64 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
-SRCREV_machine_qemuriscv32 ?= "8c516ced69f41563404ada0bea315a55bcf1df6f"
+SRCREV_machine_qemuriscv32 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
 SRCREV_machine_qemux86 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
 SRCREV_machine_qemux86-64 ?= "04a11eb4aec4efe3064f27b207e8a41c28bb08cd"
 SRCREV_machine_qemumips64 ?= "c19b50af1e3680ff6050a0cce8dcd888accafd9b"
-- 
2.19.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149794): 
https://lists.openembedded.org/g/openembedded-core/message/149794
Mute This Topic: https://lists.openembedded.org/mt/81532821/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] linux-yocto-dev: bump to v5.12-rc

[Bruce Ashfield]

From: Bruce Ashfield 

The -dev kernel has moved to v5.12, as it will be the latest avialable
in the upcoming release. core-image-kernel-dev sanity has passed for
the supported arches.

So we bump the version to match the active branches.

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

diff --git a/meta/recipes-kernel/linux/linux-yocto-dev.bb 
b/meta/recipes-kernel/linux/linux-yocto-dev.bb
index 2ccc0ee875..8725473d1c 100644
--- a/meta/recipes-kernel/linux/linux-yocto-dev.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-dev.bb
@@ -30,7 +30,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto-dev.git;branch=${KBRANCH};name
 SRCREV_machine ?= 
'${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", 
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", 
d)}'
 SRCREV_meta ?= '${@oe.utils.conditional("PREFERRED_PROVIDER_virtual/kernel", 
"linux-yocto-dev", "${AUTOREV}", "29594404d7fe73cd80eaa4ee8c43dcc53970c60e", 
d)}'
 
-LINUX_VERSION ?= "5.11+"
+LINUX_VERSION ?= "5.12+"
 LINUX_VERSION_EXTENSION ?= "-yoctodev-${LINUX_KERNEL_TYPE}"
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
-- 
2.19.1


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

[OE-core] curious about weirdness in some FILES_${PN} settings

[Robert P. J. Day]

  (warning: i've just been handed an existing OE code base, and i'm
going to ask some questions about some head-scratching things i'm
finding in it, so be prepared for weird questions.)

  in one recipe, i see the following snippet:

  FILES_${PN} += "/etc"
  FILES_${PN} += "/etc/mosquitto"
  FILES_${PN} += "/etc/mosquitto/config"
  ... etc etc ...

first, i'm taken aback by the hardcoding of "/etc" rather than using,
you know, "${sysconfdir}", so i'm *assuming* that unless someone was
doing something spectacularly clever here, that just can't be right.

  more to the point, the above seems redundant -- once you've added
"/etc", isn't the rest just superfluous? i'm not sure what the
original developer was going for here. thoughts?

  finally, if i wanted to add all of some directory, say "dir", it was
my understanding that all of the following were equivalent (h,
short of picking up hidden files, i guess):

  dir
  dir/
  dir/*

my personal preference would be "dir/", as it gets across the idea
that "dir" is a directory and i want all of it. thoughts on that as
well? i'm currently perusing the OE code base to see the general
consensus on this. is there one?

  more decidedly strange questions coming shortly ...

rday


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149792): 
https://lists.openembedded.org/g/openembedded-core/message/149792
Mute This Topic: https://lists.openembedded.org/mt/81532778/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] [poky][dunfell][PATCH] glibc: Add and modify CVEs

[saloni]

Hello Raj,

Yes, checked the discussion and patch on the mailing list in the evening.
https://lists.openembedded.org/g/openembedded-core/topic/dunfell_patch_glibc_pull/81482348?p=,,,20,0,0,0::recentpostdate%2Fsticky,,,20,2,40,81482348

Updating to latest 2.31 version will make the below patches obsolete and will 
be whitelisted, hence below changes can be ignored.

Thanks & Regards,
Saloni Jain

From: Khem Raj 
Sent: Monday, March 22, 2021 9:58 PM
To: Saloni Jain ; 
openembedded-core@lists.openembedded.org 

Cc: Nisha Parrakat 
Subject: Re: [poky][dunfell][PATCH] glibc: Add and modify CVEs

There is another patch on mailing lists to update to latest 2.31 which
should perhaps address these ?

On 3/22/21 3:27 AM, Saloni Jain wrote:
> Below patch is modified:
> 1. CVE-2019-25013
> The previous patch was modified for dunfell
> context and causing conflict for CVE-2021-3326.
> Hence, the original patch is backported.
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsecurity-tracker.debian.org%2Ftracker%2FCVE-2020-27618data=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080304204%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=6CnKJfxFf4NpxDANqbuB4wcc3tiRRNF5D%2FKBm18Dq%2FA%3Dreserved=0
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fgit%2F%3Fp%3Dglibc.git%3Ba%3Dpatch%3Bh%3D9a99c682144bdbd40792ebf822fe9264e0376fb5data=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080314201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=is4p3gAjo7AJjCtWRldupysJakNlQWLhkxaxNcIPvMI%3Dreserved=0
>
> Below patch is added:
> 1. CVE-2021-3326
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugzilla.redhat.com%2Fshow_bug.cgi%3Fid%3D1932589data=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080314201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=QIfO6Z9aDldMkDe4nTGwPJO0bF%2F0ovXj%2FEk3nio62sU%3Dreserved=0
> Link: 
> https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fgit%2F%3Fp%3Dglibc.git%3Ba%3Dpatch%3Bh%3Ddca565886b5e8bd7966e15f0ca42ee5cff686673data=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080314201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=xNOEDHc6hkgt4hYNZ5pHanGB9bLrpoUSqda33FAoldI%3Dreserved=0
>
> Signed-off-by: Saloni Jain 
> ---
>   .../glibc/glibc/CVE-2019-25013.patch  |  52 +--
>   .../glibc/glibc/CVE-2021-3326.patch   | 297 ++
>   meta/recipes-core/glibc/glibc_2.31.bb |   3 +-
>   3 files changed, 328 insertions(+), 24 deletions(-)
>   create mode 100644 meta/recipes-core/glibc/glibc/CVE-2021-3326.patch
>
> diff --git a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch 
> b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
> index 73df1da868..3e446f2818 100644
> --- a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
> +++ b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
> @@ -8,12 +8,14 @@ area and is not allowed.  The from_euc_kr function used to 
> skip two bytes
>   when told to skip over the unknown designation, potentially running over
>   the buffer end.
>
> -Upstream-Status: Backport 
> [https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fgit%2F%3Fp%3Dglibc.git%3Ba%3Dpatch%3Bh%3Dee7a3144c9922808181009b7b3e50e852fb4999bdata=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080314201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=R5euqxZd1HbzdIQR%2FVPoxa7NIHxIVEy1O%2FBQosTcZPo%3Dreserved=0]
>   CVE: CVE-2019-25013
> -Signed-off-by: Scott Murray 
> -[Refreshed for Dundell context; Makefile changes]
> -Signed-off-by: Armin Kuster 
> +Upstream Status: Backport 
> [https://apc01.safelinks.protection.outlook.com/?url=https%3A%2F%2Fsourceware.org%2Fgit%2F%3Fp%3Dglibc.git%3Ba%3Dpatch%3Bh%3Dee7a3144c9922808181009b7b3e50e852fb4999bdata=04%7C01%7CSaloni.Jain%40kpit.com%7C35f4f714238c416aff5c08d8ed4f7e7a%7C3539451eb46e4a26a242ff61502855c7%7C0%7C0%7C637520273080314201%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C1000sdata=R5euqxZd1HbzdIQR%2FVPoxa7NIHxIVEy1O%2FBQosTcZPo%3Dreserved=0]
> +Comment: No change in any hunk
>
> +The previous change was modified for dunfell context, causing conflict
> +for CVE-2021-3326. Hence, the original patch is backported.
> +
> +Signed-off-by: Saloni Jain 
>   ---

Re: [OE-core] [PATCH] go-helloworld: disable module-aware mode

[Konrad Weihmann]

On 22.03.21 04:23, Changqing Li wrote:

From: Changqing Li 

 From go 1.16, module-aware mode is enabled by default, regardless of
whether a go.mod file is present in the current working directory or a
parent directory.

Above change makes go-helloworld build fail when doing offline build or
proxy.golang.org is not accessible.


I'm not a go expert, but I understood the changelog [1] differently and 
IMO export GO111MODULE="auto" would restore the same behavior as before 
the update to go 1.16.
And if not it would make the whole go-mod.bbclass somehow obsolete, 
right - so it should be removed, or at least a sanity check should be 
added, that the class is not safe to be used with BB_NO_NETWORK


[1] https://blog.golang.org/go116-module-changes



This fix is kind of workaround, as from go1.17, GOPATH mode will be
dropped, and GO111MODULE is ignored.

Signed-off-by: Changqing Li 
---
  meta/recipes-extended/go-examples/go-helloworld_0.1.bb | 5 +++--
  1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/go-examples/go-helloworld_0.1.bb 
b/meta/recipes-extended/go-examples/go-helloworld_0.1.bb
index d3f7525dc9..c51f163e9b 100644
--- a/meta/recipes-extended/go-examples/go-helloworld_0.1.bb
+++ b/meta/recipes-extended/go-examples/go-helloworld_0.1.bb
@@ -6,14 +6,15 @@ LICENSE = "MIT"
  LIC_FILES_CHKSUM = 
"file://${COMMON_LICENSE_DIR}/MIT;md5=0835ade698e0bcf8506ecda2f7b4f302"
  
  SRC_URI = "git://${GO_IMPORT}"

-SRCREV = "bcf50bfd7dcd8020c90965747d857ae42802e0c5"
+SRCREV = "46695d81d1fae905a270fb7db8a4d11a334562fe"
  UPSTREAM_CHECK_COMMITS = "1"
  
  GO_IMPORT = "github.com/golang/example"

  GO_INSTALL = "${GO_IMPORT}/hello"
  GO_WORKDIR = "${GO_INSTALL}"
+export GO111MODULE="off"
  
-inherit go-mod

+inherit go
  
  # This is just to make clear where this example is

  do_install_append() {






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149790): 
https://lists.openembedded.org/g/openembedded-core/message/149790
Mute This Topic: https://lists.openembedded.org/mt/81516655/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] [poky][PATCH] package_manager: install versioned postinst scripts

[Anton Kachalov via lists.openembedded.org]

Hi, Mike.

That is how OpenBMC is designed. Most of the targets are read-only rootfs
(squashfs) and overlayfs for RW.
It is not expected to overwrite binaries through overlayfs and there are
plans to scope RW areas (e.g. /etc).

Those files with 64-chars suffix are mostly hidden from regular users: the
files are removed during the first startup. No one will notice them :)

Anyway, alternatively within the openbmc update script it's possible to
force clean the deleted files on overlayfs upperdir. However, it will mean
that all the scripts regardless if they are updated or not, will be
re-executed after rootfs update.

On Mon, 22 Mar 2021 at 17:08, Mike Looijmans 
wrote:

> Two remarks below...
>
>
> Met vriendelijke groet / kind regards,
>
> Mike Looijmans
> System Expert
>
>
> TOPIC Embedded Products B.V.
> Materiaalweg 4, 5681 RJ Best
> The Netherlands
>
> T: +31 (0) 499 33 69 69 <+31%20499%20336%20969>
> E: mike.looijm...@topicproducts.com
> W: www.topic.nl
>
> Please consider the environment before printing this e-mail
> On 22-03-2021 16:45, Anton Kachalov via lists.openembedded.org wrote:
> > From: "Anton D. Kachalov" 
> >
> > When running on read-only rootfs backed with overlayfs, the processed
> scripts
> > are being marked as deleted on upperdir of overlayfs. When it comes to
> > upgrade the main read-only image, it might contain new postinst scripts
> that
> > are different from the already processed. Introduced suffix (sha256 of
> > the content) allows to distinct updated scripts of the same package.
>
> So your usecase is that you have a read-only rootfs with an overlay on
> top, and then just replace the rootfs. And then expect things to still
> work?
>
> That doesn't sound valid to me - normally I'd wipe the overlay clean
> when updating the underlying read-only part. I'd be very interested in
> what you're actually trying to accomplish here?
>
> And further, I don't think appending 64 characters to filenames is going
> to make anyone happy.
>
> In your case, I'd opt for a script that just resets the postinst scripts
> (and maybe more?) in the overlay. Or have 3 overlays. Whenever the
> package manager runs, activate the second layer. The "user" stuff in the
> third layer is normally active. Then when you upgrade the system, wipe
> the second layer, to get rid of obsolete packages. Or something like
> that. Again, tell us what you're really building...
>
>
> >
> > Signed-off-by: Anton D. Kachalov 
> > ---
> >   meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
> >   meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
> >   meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
> >   3 files changed, 23 insertions(+), 3 deletions(-)
> >
> > diff --git a/meta/lib/oe/package_manager/deb/rootfs.py
> b/meta/lib/oe/package_manager/deb/rootfs.py
> > index 8fbaca11d6..704d213626 100644
> > --- a/meta/lib/oe/package_manager/deb/rootfs.py
> > +++ b/meta/lib/oe/package_manager/deb/rootfs.py
> > @@ -4,6 +4,7 @@
> >
> >   import re
> >   import shutil
> > +from hashlib import sha256
> >   from oe.rootfs import Rootfs
> >   from oe.manifest import Manifest
> >   from oe.utils import execute_pre_post_process
> > @@ -115,8 +116,16 @@ class DpkgOpkgRootfs(Rootfs):
> >   bb.utils.mkdirhier(dst_postinst_dir)
> >
> >   if os.path.exists(os.path.join(src_postinst_dir, p +
> ".postinst")):
> > +csum = sha256()
> > +with open(src_postinst_dir, p + ".postinst", "rb") as f:
> > +while True:
> > +data = f.read(65536)
> > +if not data:
> > +break
> > +csum.update(data)
> > +
> >   shutil.copy(os.path.join(src_postinst_dir, p +
> ".postinst"),
> > -os.path.join(dst_postinst_dir, "%03d-%s" %
> (num, p)))
> > +os.path.join(dst_postinst_dir, "%03d-%s.%s"
> % (num, p, csum.hexdigest(
> >
> >   num += 1
> >
> > diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py
> b/meta/lib/oe/package_manager/ipk/rootfs.py
> > index 26dbee6f6a..6ead6ddef3 100644
> > --- a/meta/lib/oe/package_manager/ipk/rootfs.py
> > +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
> > @@ -5,6 +5,7 @@
> >   import re
> >   import filecmp
> >   import shutil
> > +from hashlib import sha256
> >   from oe.rootfs import Rootfs
> >   from oe.manifest import Manifest
> >   from oe.utils import execute_pre_post_process
> > @@ -116,8 +117,16 @@ class DpkgOpkgRootfs(Rootfs):
> >   bb.utils.mkdirhier(dst_postinst_dir)
> >
> >   if os.path.exists(os.path.join(src_postinst_dir, p +
> ".postinst")):
> > +csum = sha256()
> > +with open(src_postinst_dir, p + ".postinst", "rb") as f:
> > +while True:
> > +data = f.read(65536)
> > +if not data:
> > + 

Re: [OE-core] [poky][dunfell][PATCH] glibc: Add and modify CVEs

[Khem Raj]

There is another patch on mailing lists to update to latest 2.31 which 
should perhaps address these ?


On 3/22/21 3:27 AM, Saloni Jain wrote:

Below patch is modified:
1. CVE-2019-25013
The previous patch was modified for dunfell
context and causing conflict for CVE-2021-3326.
Hence, the original patch is backported.
Link: https://security-tracker.debian.org/tracker/CVE-2020-27618
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=9a99c682144bdbd40792ebf822fe9264e0376fb5

Below patch is added:
1. CVE-2021-3326
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1932589
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=dca565886b5e8bd7966e15f0ca42ee5cff686673

Signed-off-by: Saloni Jain 
---
  .../glibc/glibc/CVE-2019-25013.patch  |  52 +--
  .../glibc/glibc/CVE-2021-3326.patch   | 297 ++
  meta/recipes-core/glibc/glibc_2.31.bb |   3 +-
  3 files changed, 328 insertions(+), 24 deletions(-)
  create mode 100644 meta/recipes-core/glibc/glibc/CVE-2021-3326.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch 
b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
index 73df1da868..3e446f2818 100644
--- a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
+++ b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
@@ -8,12 +8,14 @@ area and is not allowed.  The from_euc_kr function used to 
skip two bytes
  when told to skip over the unknown designation, potentially running over
  the buffer end.

-Upstream-Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
  CVE: CVE-2019-25013
-Signed-off-by: Scott Murray 
-[Refreshed for Dundell context; Makefile changes]
-Signed-off-by: Armin Kuster 
+Upstream Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
+Comment: No change in any hunk

+The previous change was modified for dunfell context, causing conflict
+for CVE-2021-3326. Hence, the original patch is backported.
+
+Signed-off-by: Saloni Jain 
  ---
   iconvdata/Makefile  |  3 ++-
   iconvdata/bug-iconv13.c | 53 +
@@ -22,23 +24,25 @@ Signed-off-by: Armin Kuster 
   4 files changed, 59 insertions(+), 9 deletions(-)
   create mode 100644 iconvdata/bug-iconv13.c

-Index: git/iconvdata/Makefile
-===
 git.orig/iconvdata/Makefile
-+++ git/iconvdata/Makefile
-@@ -73,7 +73,7 @@ modules.so := $(addsuffix .so, $(modules
+diff --git a/iconvdata/Makefile b/iconvdata/Makefile
+index 4ec2741cdc..85009f3390 100644
+--- a/iconvdata/Makefile
 b/iconvdata/Makefile
+@@ -73,7 +73,8 @@
   ifeq (yes,$(build-shared))
   tests = bug-iconv1 bug-iconv2 tst-loading tst-e2big tst-iconv4 bug-iconv4 \
 tst-iconv6 bug-iconv5 bug-iconv6 tst-iconv7 bug-iconv8 bug-iconv9 \
  -  bug-iconv10 bug-iconv11 bug-iconv12
-+  bug-iconv10 bug-iconv11 bug-iconv12 bug-iconv13
++  bug-iconv10 bug-iconv11 bug-iconv12 tst-iconv-big5-hkscs-to-2ucs4 \
++   bug-iconv13
   ifeq ($(have-thread-library),yes)
   tests += bug-iconv3
   endif
-Index: git/iconvdata/bug-iconv13.c
-===
+diff --git a/iconvdata/bug-iconv13.c b/iconvdata/bug-iconv13.c
+new file mode 100644
+index 00..87aaff398e
  --- /dev/null
-+++ git/iconvdata/bug-iconv13.c
 b/iconvdata/bug-iconv13.c
  @@ -0,0 +1,53 @@
  +/* bug 24973: Test EUC-KR module
  +   Copyright (C) 2020 Free Software Foundation, Inc.
@@ -93,11 +97,11 @@ Index: git/iconvdata/bug-iconv13.c
  +}
  +
  +#include 
-Index: git/iconvdata/euc-kr.c
-===
 git.orig/iconvdata/euc-kr.c
-+++ git/iconvdata/euc-kr.c
-@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned c
+diff --git a/iconvdata/euc-kr.c b/iconvdata/euc-kr.c
+index b0d56cf3ee..1045bae926 100644
+--- a/iconvdata/euc-kr.c
 b/iconvdata/euc-kr.c
+@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned char *cp)
   \
   if (ch <= 0x9f) \
 ++inptr;   
   \
@@ -110,11 +114,11 @@ Index: git/iconvdata/euc-kr.c
 {  
   \
 /* This is illegal.  */   \
 STANDARD_FROM_LOOP_ERR_HANDLER (1);   \
-Index: git/iconvdata/ksc5601.h
-===
 git.orig/iconvdata/ksc5601.h
-+++ git/iconvdata/ksc5601.h
-@@ -50,15 +50,15 @@ ksc5601_to_ucs4 (const unsigned char **s
+diff --git a/iconvdata/ksc5601.h b/iconvdata/ksc5601.h
+index d3eb3a4ff8..f5cdc72797 100644
+--- a/iconvdata/ksc5601.h
 

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

[Mike Looijmans]

Two remarks below...


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topicproducts.com
W: www.topic.nl

Please consider the environment before printing this e-mail
On 22-03-2021 16:45, Anton Kachalov via lists.openembedded.org wrote:

From: "Anton D. Kachalov" 

When running on read-only rootfs backed with overlayfs, the processed scripts
are being marked as deleted on upperdir of overlayfs. When it comes to
upgrade the main read-only image, it might contain new postinst scripts that
are different from the already processed. Introduced suffix (sha256 of
the content) allows to distinct updated scripts of the same package.


So your usecase is that you have a read-only rootfs with an overlay on 
top, and then just replace the rootfs. And then expect things to still 
work?


That doesn't sound valid to me - normally I'd wipe the overlay clean 
when updating the underlying read-only part. I'd be very interested in 
what you're actually trying to accomplish here?


And further, I don't think appending 64 characters to filenames is going 
to make anyone happy.


In your case, I'd opt for a script that just resets the postinst scripts 
(and maybe more?) in the overlay. Or have 3 overlays. Whenever the 
package manager runs, activate the second layer. The "user" stuff in the 
third layer is normally active. Then when you upgrade the system, wipe 
the second layer, to get rid of obsolete packages. Or something like 
that. Again, tell us what you're really building...





Signed-off-by: Anton D. Kachalov 
---
  meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
  meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
  meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
  3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/package_manager/deb/rootfs.py 
b/meta/lib/oe/package_manager/deb/rootfs.py
index 8fbaca11d6..704d213626 100644
--- a/meta/lib/oe/package_manager/deb/rootfs.py
+++ b/meta/lib/oe/package_manager/deb/rootfs.py
@@ -4,6 +4,7 @@
  
  import re

  import shutil
+from hashlib import sha256
  from oe.rootfs import Rootfs
  from oe.manifest import Manifest
  from oe.utils import execute_pre_post_process
@@ -115,8 +116,16 @@ class DpkgOpkgRootfs(Rootfs):
  bb.utils.mkdirhier(dst_postinst_dir)
  
  if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):

+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
  shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
  
  num += 1
  
diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py b/meta/lib/oe/package_manager/ipk/rootfs.py

index 26dbee6f6a..6ead6ddef3 100644
--- a/meta/lib/oe/package_manager/ipk/rootfs.py
+++ b/meta/lib/oe/package_manager/ipk/rootfs.py
@@ -5,6 +5,7 @@
  import re
  import filecmp
  import shutil
+from hashlib import sha256
  from oe.rootfs import Rootfs
  from oe.manifest import Manifest
  from oe.utils import execute_pre_post_process
@@ -116,8 +117,16 @@ class DpkgOpkgRootfs(Rootfs):
  bb.utils.mkdirhier(dst_postinst_dir)
  
  if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):

+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
  shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
  
  num += 1
  
diff --git a/meta/lib/oe/package_manager/rpm/__init__.py b/meta/lib/oe/package_manager/rpm/__init__.py

index 6df0092281..4746e96ce8 100644
--- a/meta/lib/oe/package_manager/rpm/__init__.py
+++ b/meta/lib/oe/package_manager/rpm/__init__.py
@@ -4,6 +4,7 @@
  
  import shutil

  import subprocess
+from hashlib import sha256
  from oe.package_manager import *
  
  class RpmIndexer(Indexer):

@@ -359,7 +360,8 @@ class RpmPM(PackageManager):
  target_path = oe.path.join(self.target_rootfs, 
self.d.expand('${sysconfdir}/rpm-postinsts/'))
  bb.utils.mkdirhier(target_path)
  num = self._script_num_prefix(target_path)
-

Re: [OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

[Richard Purdie]

On Mon, 2021-03-22 at 16:45 +0100, Anton Kachalov via lists.openembedded.org 
wrote:
> From: "Anton D. Kachalov" 
> 
> When running on read-only rootfs backed with overlayfs, the processed scripts
> are being marked as deleted on upperdir of overlayfs. When it comes to
> upgrade the main read-only image, it might contain new postinst scripts that
> are different from the already processed. Introduced suffix (sha256 of
> the content) allows to distinct updated scripts of the same package.
> 
> Signed-off-by: Anton D. Kachalov 
> ---
>  meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
>  meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
>  meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
>  3 files changed, 23 insertions(+), 3 deletions(-)

Isn't this working around an issue with overlayfs?

I'm a bit worried we're adding complexity to all users of the project
for a very specific use case where the issue is really somewhere else?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149786): 
https://lists.openembedded.org/g/openembedded-core/message/149786
Mute This Topic: https://lists.openembedded.org/mt/81527936/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] valgrind: Fix ptests on ppc64 LE

[Khem Raj]

Backport a patch to avoid lsw/lmw instructions

Signed-off-by: Khem Raj 
---
 ...ated-PowerPC-insns-aren-t-allowed-on.patch | 62 +++
 .../valgrind/valgrind_3.16.1.bb   |  1 +
 2 files changed, 63 insertions(+)
 create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
 
b/meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
new file mode 100644
index 00..7c62144978
--- /dev/null
+++ 
b/meta/recipes-devtools/valgrind/valgrind/0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch
@@ -0,0 +1,62 @@
+From 0748ed5403a75c12ad9137b3fabf9d8397206ed8 Mon Sep 17 00:00:00 2001
+From: Mark Wielaard 
+Date: Tue, 1 Dec 2020 13:57:39 +0100
+Subject: [PATCH] lmw, lswi and related PowerPC insns aren't allowed on ppc64le
+
+lmw, lswi and related PowerPC insns aren't allowed on ppc64le
+
+Newer binutils produce an error when the assembly contains lmw, stmw,
+lswi, lswx, stswi, or stswx instructions in little-endian mode.
+
+Only build and run the lsw and ldst_multiple testcases on ppc64[be].
+
+https://bugs.kde.org/show_bug.cgi?id=427870
+Upstream-Status: Backport 
[https://sourceware.org/git/?p=valgrind.git;a=commit;h=74b74174d572fee4015b8f4e326db3cd949bcdc3]
+Signed-off-by: Khem Raj 
+---
+ none/tests/ppc64/Makefile.am  | 9 ++---
+ none/tests/ppc64/ldst_multiple.vgtest | 1 +
+ 2 files changed, 7 insertions(+), 3 deletions(-)
+
+diff --git a/none/tests/ppc64/Makefile.am b/none/tests/ppc64/Makefile.am
+index 9bc0d0a..9d1e8b7 100644
+--- a/none/tests/ppc64/Makefile.am
 b/none/tests/ppc64/Makefile.am
+@@ -54,16 +54,20 @@ EXTRA_DIST = \
+ 
+ check_PROGRAMS = \
+   allexec \
+-  lsw jm-insns round \
++  jm-insns round \
+   test_isa_2_06_part1 test_isa_2_06_part2 test_isa_2_06_part3 \
+   test_dfp1 test_dfp2 test_dfp3 test_dfp4 test_dfp5 \
+   test_isa_2_07_part1 test_isa_2_07_part2 \
+   test_isa_3_0 \
+   subnormal_test \
+-  test_tm test_touch_tm ldst_multiple data-cache-instructions \
++  test_tm test_touch_tm data-cache-instructions \
+   power6_mf_gpr std_reg_imm \
+   twi_tdi tw_td power6_bcmp
+ 
++# lmw, stmw, lswi, lswx, stswi, stswx compile (and run) only on big endian.
++if VGCONF_PLATFORMS_INCLUDE_PPC64BE_LINUX
++check_PROGRAMS += lsw ldst_multiple
++endif
+ 
+ AM_CFLAGS+= @FLAG_M64@
+ AM_CXXFLAGS  += @FLAG_M64@
+@@ -175,4 +179,3 @@ test_isa_2_07_part2_LDADD = -lm
+ test_tm_LDADD = -lm
+ test_touch_tm_LDADD = -lm
+ test_isa_3_0_LDADD = -lm
+-
+diff --git a/none/tests/ppc64/ldst_multiple.vgtest 
b/none/tests/ppc64/ldst_multiple.vgtest
+index 87e668e..22dd46c 100644
+--- a/none/tests/ppc64/ldst_multiple.vgtest
 b/none/tests/ppc64/ldst_multiple.vgtest
+@@ -1 +1,2 @@
++prereq: ../../../tests/is_ppc64_BE
+ prog: ldst_multiple
+-- 
+2.31.0
+
diff --git a/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb 
b/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
index 9dbd9f74c4..2b1d185575 100644
--- a/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
+++ b/meta/recipes-devtools/valgrind/valgrind_3.16.1.bb
@@ -46,6 +46,7 @@ SRC_URI = 
"https://sourceware.org/pub/valgrind/valgrind-${PV}.tar.bz2 \
file://0001-drd-musl-fix.patch \
file://0001-helgrind-Intercept-libc-functions.patch \

file://0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch \
+   
file://0001-lmw-lswi-and-related-PowerPC-insns-aren-t-allowed-on.patch \
"
 SRC_URI[md5sum] = "d1b153f1ab17cf1f311705e7a83ef589"
 SRC_URI[sha256sum] = 
"c91f3a2f7b02db0f3bc99479861656154d241d2fdb265614ba918cc6720a33ca"
-- 
2.31.0


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

[OE-core] [poky][PATCH] package_manager: install versioned postinst scripts

[Anton Kachalov via lists.openembedded.org]

From: "Anton D. Kachalov" 

When running on read-only rootfs backed with overlayfs, the processed scripts
are being marked as deleted on upperdir of overlayfs. When it comes to
upgrade the main read-only image, it might contain new postinst scripts that
are different from the already processed. Introduced suffix (sha256 of
the content) allows to distinct updated scripts of the same package.

Signed-off-by: Anton D. Kachalov 
---
 meta/lib/oe/package_manager/deb/rootfs.py   | 11 ++-
 meta/lib/oe/package_manager/ipk/rootfs.py   | 11 ++-
 meta/lib/oe/package_manager/rpm/__init__.py |  4 +++-
 3 files changed, 23 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oe/package_manager/deb/rootfs.py 
b/meta/lib/oe/package_manager/deb/rootfs.py
index 8fbaca11d6..704d213626 100644
--- a/meta/lib/oe/package_manager/deb/rootfs.py
+++ b/meta/lib/oe/package_manager/deb/rootfs.py
@@ -4,6 +4,7 @@
 
 import re
 import shutil
+from hashlib import sha256
 from oe.rootfs import Rootfs
 from oe.manifest import Manifest
 from oe.utils import execute_pre_post_process
@@ -115,8 +116,16 @@ class DpkgOpkgRootfs(Rootfs):
 bb.utils.mkdirhier(dst_postinst_dir)
 
 if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):
+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
 shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
 
 num += 1
 
diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
b/meta/lib/oe/package_manager/ipk/rootfs.py
index 26dbee6f6a..6ead6ddef3 100644
--- a/meta/lib/oe/package_manager/ipk/rootfs.py
+++ b/meta/lib/oe/package_manager/ipk/rootfs.py
@@ -5,6 +5,7 @@
 import re
 import filecmp
 import shutil
+from hashlib import sha256
 from oe.rootfs import Rootfs
 from oe.manifest import Manifest
 from oe.utils import execute_pre_post_process
@@ -116,8 +117,16 @@ class DpkgOpkgRootfs(Rootfs):
 bb.utils.mkdirhier(dst_postinst_dir)
 
 if os.path.exists(os.path.join(src_postinst_dir, p + ".postinst")):
+csum = sha256()
+with open(src_postinst_dir, p + ".postinst", "rb") as f:
+while True:
+data = f.read(65536)
+if not data:
+break
+csum.update(data)
+
 shutil.copy(os.path.join(src_postinst_dir, p + ".postinst"),
-os.path.join(dst_postinst_dir, "%03d-%s" % (num, 
p)))
+os.path.join(dst_postinst_dir, "%03d-%s.%s" % 
(num, p, csum.hexdigest(
 
 num += 1
 
diff --git a/meta/lib/oe/package_manager/rpm/__init__.py 
b/meta/lib/oe/package_manager/rpm/__init__.py
index 6df0092281..4746e96ce8 100644
--- a/meta/lib/oe/package_manager/rpm/__init__.py
+++ b/meta/lib/oe/package_manager/rpm/__init__.py
@@ -4,6 +4,7 @@
 
 import shutil
 import subprocess
+from hashlib import sha256
 from oe.package_manager import *
 
 class RpmIndexer(Indexer):
@@ -359,7 +360,8 @@ class RpmPM(PackageManager):
 target_path = oe.path.join(self.target_rootfs, 
self.d.expand('${sysconfdir}/rpm-postinsts/'))
 bb.utils.mkdirhier(target_path)
 num = self._script_num_prefix(target_path)
-saved_script_name = oe.path.join(target_path, "%d-%s" % (num, pkg))
+csum = sha256(output.encode("utf-8")).hexdigest()
+saved_script_name = oe.path.join(target_path, "%d-%s.%s" % (num, pkg, 
csum))
 open(saved_script_name, 'w').write(output)
 os.chmod(saved_script_name, 0o755)
 
-- 
2.31.0.rc2.261.g7f71774620-goog


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149784): 
https://lists.openembedded.org/g/openembedded-core/message/149784
Mute This Topic: https://lists.openembedded.org/mt/81527936/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 v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

[Richard Purdie]

On Mon, 2021-03-22 at 11:29 +0300, Alexander Kanavin wrote:
> Note that this m4 file is copied verbatim from upstream gettext, and will 
> be again overwritten on next gettext upgrade. You should figure out what’s
> wrong specifically in elfutils tree, and work with elfutils upstream to 
> resolve it.

It's more that there is a silly/pointless macro that breaks native builds for
us, the issue is in gettext.

How about we set the cache value globally for this macro and drop the patch?

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149783): 
https://lists.openembedded.org/g/openembedded-core/message/149783
Mute This Topic: https://lists.openembedded.org/mt/81519074/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] [WIP] valgrind: update to 3.17.0.RC2

[Randy MacLeod]

On 2021-03-22 10:30 a.m., Randy MacLeod wrote:




TESTING RESULTS:
qemu x86-64:
FAIL: drd/tests/swapcontext
FAIL: gdbserver_tests/hgtls

=== Test Summary ===
TOTAL: 736
PASSED: 693
FAILED: 2
SKIPPED: 41


Compared to:

=== Test Summary ===
TOTAL: 408
PASSED: 390
FAILED: 0
SKIPPED: 18
DURATION: 738

https://autobuilder.yocto.io/pub/non-release/20210321-1/testresults/qemuarm64-ptest/ 



Oops, that was for arm64, the latest x86-64 ptest results on master are:

=== Test Summary ===
TOTAL: 726
PASSED: 688
FAILED: 0
SKIPPED: 38
DURATION: 959

https://autobuilder.yocto.io/pub/non-release/20210321-1/testresults/qemux86-64-ptest/

Please include them in your long log for context.

--
# Randy MacLeod
# Wind River Linux

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149782): 
https://lists.openembedded.org/g/openembedded-core/message/149782
Mute This Topic: https://lists.openembedded.org/mt/81515521/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] [WIP] valgrind: update to 3.17.0.RC2

[Randy MacLeod]

On 2021-03-21 10:02 p.m., Yi Fan Yu wrote:

3.17.0.rc2 will be very close to the 3.17.0 release


It seems that 3.17 is out now:
   https://www.valgrind.org/downloads/current.html





still need to refresh
drd-musl-fix.patch


This post-release commit, that makes the Makefile.a aware of
the musl.supp suppression filter might help musl ptest resutls:

dde556d51 (HEAD -> master, origin/master, origin/HEAD) Add musl.supp to 
SUPP_FILES


and musl.supp is included in the valgring git repo and likely the
tarball so we can drop it from the recipe is the content is the same.



TESTING RESULTS:
qemu x86-64:
FAIL: drd/tests/swapcontext
FAIL: gdbserver_tests/hgtls

=== Test Summary ===
TOTAL: 736
PASSED: 693
FAILED: 2
SKIPPED: 41


Compared to:

=== Test Summary ===
TOTAL: 408
PASSED: 390
FAILED: 0
SKIPPED: 18
DURATION: 738

https://autobuilder.yocto.io/pub/non-release/20210321-1/testresults/qemuarm64-ptest/



swap-context.vgtest has been disabled
a workaround for gdbserver_tests/hgtls has been implemented

+install ${S}/none/tests/tls.c  ${D}${PTEST_PATH}/gdbserver_tests/tls.c

OTHER CHANGES:

libdir is now libexecdir

Signed-off-by: Yi Fan Yu 
---
  ...Disable-drd-tests-swapcontext.vgtest.patch |  49 +
  ...gtest-hanging-on-newer-glibc-and-or-.patch | 200 --
  .../valgrind/0001-drd-Port-to-Fedora-33.patch |  48 -
  .../valgrind/valgrind/0001-drd-musl-fix.patch |  12 +-
  ...eak_cmsg.stderr.exp-adjust-tmp-paths.patch |   2 +-
  ...ch-drd_pthread_intercepts.c-for-musl.patch |  39 
  .../valgrind/valgrind/fixed-perl-path.patch   |  20 +-
  .../valgrind/valgrind/musl.supp   |  46 
  .../valgrind/valgrind/run-ptest   |   3 +-
  .../valgrind/valgrind/s390x_vec_op_t.patch|  24 ++-
  ...{valgrind_3.16.1.bb => valgrind_3.17.0.bb} |  23 +-
  11 files changed, 185 insertions(+), 281 deletions(-)
  create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-Disable-drd-tests-swapcontext.vgtest.patch
  delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-Fix-nlcontrolc.vgtest-hanging-on-newer-glibc-and-or-.patch
  delete mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-drd-Port-to-Fedora-33.patch
  create mode 100644 
meta/recipes-devtools/valgrind/valgrind/0001-patch-drd_pthread_intercepts.c-for-musl.patch
  create mode 100644 meta/recipes-devtools/valgrind/valgrind/musl.supp
  rename meta/recipes-devtools/valgrind/{valgrind_3.16.1.bb => 
valgrind_3.17.0.bb} (93%)

diff --git 
a/meta/recipes-devtools/valgrind/valgrind/0001-Disable-drd-tests-swapcontext.vgtest.patch
 
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-drd-tests-swapcontext.vgtest.patch
new file mode 100644
index 00..9e78a9cb61
--- /dev/null
+++ 
b/meta/recipes-devtools/valgrind/valgrind/0001-Disable-drd-tests-swapcontext.vgtest.patch
@@ -0,0 +1,49 @@
+From e3b587b1cfa7dde1484c88b2af67c49a1c6166e1 Mon Sep 17 00:00:00 2001
+From: Yi Fan Yu 
+Date: Fri, 19 Mar 2021 16:35:26 -0400
+Subject: [PATCH] Disable drd/tests/swapcontext.vgtest
+
+Test fails on both x86-64 and arm64.
+
+Unbuidable on musl with switchcontext.


typo: Unbuildable


Are you going to work on this for a while or just report it upstream?
What happens if you run it?


+
+Signed-off-by: Yi Fan Yu 
+---
+ drd/tests/Makefile.am | 10 --
+ 1 file changed, 10 deletions(-)
+
+diff --git a/drd/tests/Makefile.am b/drd/tests/Makefile.am
+index 79e076246..5df76150e 100644
+--- a/drd/tests/Makefile.am
 b/drd/tests/Makefile.am
+@@ -267,8 +267,6 @@ EXTRA_DIST =\
+   sem_open_traced.vgtest  \
+   sem_wait.stderr.exp \
+   sem_wait.vgtest \
+-  swapcontext.stderr.exp  \
+-  swapcontext.vgtest  \
+   sigalrm.stderr.exp  \
+   sigalrm.vgtest  \
+   sigaltstack.stderr.exp  \
+@@ -408,7 +406,6 @@ check_PROGRAMS =  \
+   sem_as_mutex\
+   sem_open\
+   sigalrm \
+-  swapcontext \


If swapcontext builds for all our targets/libc combos,
I prefer to build it, install it but then move it aside in the run-ptest
script so that there's less of a barrier for someone to try to fix it.

I guess the downside to that approach is that there's no patch for us
to notice so we should probably track it with a YP bug so do as you 
please I guess. :-)




+   threaded-fork   \
+   trylock \
+   unit_bitmap \
+@@ -588,10 +585,3 @@ std_thread2_LDFLAGS  = -Wl,--no-as-needed
+ endif
+
+ sem_wait_SOURCES= sem_wait.cpp
+-
+-swapcontext_SOURCES = swapcontext.c
+-swapcontext_CFLAGS  = $(AM_CFLAGS) -g
+-if VGCONF_OS_IS_SOLARIS
+-swapcontext_CFLAGS  += -D__EXTENSIONS__
+-endif
+-
+--
+2.29.2
+
diff --git 

Re: [OE-core] [PATCH] rootfs.py: mask run-postinsts systemd service when unneeded

[Alexander Kanavin]

Right, I guess I was missing the context where the patch is applied: "if
delayed_postinst is None" inside uninstall_unneeded(). Perhaps you could
expand the commit message a bit, and say specifically what is the scenario
when this is executed ("not needed" is somewhat vague).

Then no separate test is necessary.

Alex

On Mon, 22 Mar 2021 at 14:41, Awais Belal  wrote:

> Hi Alex,
>
> Why isn’t this seen in the tests? Can you add a test that shows the issue
> please? (Fails without the patch, passes with)
>
> I'm not very well versed with the oe test infrastructure, I'd be happy to
> create a test for this scenario if you can point me to the material that I
> need to go through in order to be able to create a test for this. However,
> if you want me to summarize this tends to fix the issue where the systemd
> run-postinsts.service is run at the target even when not needed (no pending
> postinsts are found during build).
>
> I do need to send a v2 for this as there's a slight issue in the patch.
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149780): 
https://lists.openembedded.org/g/openembedded-core/message/149780
Mute This Topic: https://lists.openembedded.org/mt/81518683/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 07/16] mesa: update 20.3.4 -> 21.0.0

[Alexander Kanavin]

I guess so, yes. I believe AB doesn't run the build?

Alex

On Mon, 22 Mar 2021 at 14:29, Martin Jansa  wrote:

> On Fri, Mar 19, 2021 at 09:43:52AM +0100, Alexander Kanavin wrote:
> > 0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> > merged upstream.
> >
> > osmesa is now a simple boolean option.
> >
> > Swrast has been removed from dri drivers, so as we need at least one
> > driver to enable dri in native/nativesdk, replace it with nouveau
> > (which does not take long to build).
>
> so the mesa-gl needs similar change, right?
>
> meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb:# When NOT using X11, we
> need to make sure we have swrast available.
> meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb:DRIDRIVERS_append =
> "${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', ',swrast', d)}"
>
> Now it's failing with:
> http://errors.yoctoproject.org/Errors/Build/118645/
>
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  ...race-between-generating-a-header-and.patch | 31 ---
> >  ...k-for-all-linux-host_os-combinations.patch | 12 +++
> >  ...02-meson.build-make-TLS-ELF-optional.patch | 14 -
> >  .../{mesa-gl_20.3.4.bb => mesa-gl_21.0.0.bb}  |  0
> >  meta/recipes-graphics/mesa/mesa.inc   | 10 +++---
> >  .../mesa/{mesa_20.3.4.bb => mesa_21.0.0.bb}   |  0
> >  6 files changed, 17 insertions(+), 50 deletions(-)
> >  delete mode 100644
> meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> >  rename meta/recipes-graphics/mesa/{mesa-gl_20.3.4.bb =>
> mesa-gl_21.0.0.bb} (100%)
> >  rename meta/recipes-graphics/mesa/{mesa_20.3.4.bb => mesa_21.0.0.bb}
> (100%)
> >
> > diff --git
> a/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> b/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> > deleted file mode 100644
> > index a61e7b2160..00
> > ---
> a/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> > +++ /dev/null
> > @@ -1,31 +0,0 @@
> > -From f148d4f1b5b13288b254ead07f1d008d997e2342 Mon Sep 17 00:00:00 2001
> > -From: Alexander Kanavin 
> > -Date: Mon, 2 Nov 2020 23:23:53 +0100
> > -Subject: [PATCH] anv: fix a build race between generating a header and
> using
> > - it
> > -
> > -anv_batch_chain.c includes genX_bits.h but doesn't ensure it gets
> > -generated first. This causes build failures, as observed here:
> > -
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1501/steps/8/logs/step2d
> > -
> > -Upstream-Status: Submitted [
> https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7412]
> > -Signed-off-by: Alexander Kanavin 
> > 
> > - src/intel/vulkan/meson.build | 1 +
> > - 1 file changed, 1 insertion(+)
> > -
> > -diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> > -index 36e1689314e..b713d8eade3 100644
> >  a/src/intel/vulkan/meson.build
> > -+++ b/src/intel/vulkan/meson.build
> > -@@ -131,6 +131,7 @@ libanv_files = files(
> > - anv_deps = [
> > -   dep_libdrm,
> > -   dep_valgrind,
> > -+  idep_genxml,
> > -   idep_nir_headers,
> > -   idep_vulkan_util_headers,
> > - ]
> > ---
> > -2.29.0
> > -
> > diff --git
> a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> > index 085254323c..b6f86743e1 100644
> > ---
> a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> > +++
> b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> > @@ -1,4 +1,4 @@
> > -From 0d9ed002eff176b902da266d89829a9b0cb10946 Mon Sep 17 00:00:00 2001
> > +From 38e984073e4c23b6278d1a2ff21e894fda7b93c5 Mon Sep 17 00:00:00 2001
> >  From: Alistair Francis 
> >  Date: Thu, 14 Nov 2019 13:04:49 -0800
> >  Subject: [PATCH] meson.build: check for all linux host_os combinations
> > @@ -20,10 +20,10 @@ Signed-off-by: Alistair Francis <
> alist...@alistair23.me>
> >   1 file changed, 2 insertions(+), 2 deletions(-)
> >
> >  diff --git a/meson.build b/meson.build
> > -index 898d025..09e3759 100644
> > +index 932eb13..efc6171 100644
> >  --- a/meson.build
> >  +++ b/meson.build
> > -@@ -124,7 +124,7 @@ with_any_opengl = with_opengl or with_gles1 or
> with_gles2
> > +@@ -153,7 +153,7 @@ with_any_opengl = with_opengl or with_gles1 or
> with_gles2
> >   # Only build shared_glapi if at least one OpenGL API is enabled
> >   with_shared_glapi = with_shared_glapi and with_any_opengl
> >
> > @@ -32,12 +32,12 @@ index 898d025..09e3759 100644
> >
> >   dri_drivers = get_option('dri-drivers')
> >   if dri_drivers.contains('auto')
> > -@@ -884,7 +884,7 @@ if cc.compiles('__uint128_t foo(void) { return 0;
> }',
> > +@@ -970,7 +970,7 @@ if cc.compiles('__uint128_t foo(void) { return 0;
> }',
> >   endif
> >
> >   # TODO: this 

[OE-core] [poky][dunfell][PATCH] glibc: Add and modify CVEs

[saloni]

Below patch is modified:
1. CVE-2019-25013
The previous patch was modified for dunfell
context and causing conflict for CVE-2021-3326.
Hence, the original patch is backported.
Link: https://security-tracker.debian.org/tracker/CVE-2020-27618
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=9a99c682144bdbd40792ebf822fe9264e0376fb5

Below patch is added:
1. CVE-2021-3326
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1932589
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=dca565886b5e8bd7966e15f0ca42ee5cff686673

Signed-off-by: Saloni Jain 
---
 .../glibc/glibc/CVE-2019-25013.patch  |  52 +--
 .../glibc/glibc/CVE-2021-3326.patch   | 297 ++
 meta/recipes-core/glibc/glibc_2.31.bb |   3 +-
 3 files changed, 328 insertions(+), 24 deletions(-)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2021-3326.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch 
b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
index 73df1da868..3e446f2818 100644
--- a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
+++ b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
@@ -8,12 +8,14 @@ area and is not allowed.  The from_euc_kr function used to 
skip two bytes
 when told to skip over the unknown designation, potentially running over
 the buffer end.

-Upstream-Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
 CVE: CVE-2019-25013
-Signed-off-by: Scott Murray 
-[Refreshed for Dundell context; Makefile changes]
-Signed-off-by: Armin Kuster 
+Upstream Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
+Comment: No change in any hunk

+The previous change was modified for dunfell context, causing conflict
+for CVE-2021-3326. Hence, the original patch is backported.
+
+Signed-off-by: Saloni Jain 
 ---
  iconvdata/Makefile  |  3 ++-
  iconvdata/bug-iconv13.c | 53 +
@@ -22,23 +24,25 @@ Signed-off-by: Armin Kuster 
  4 files changed, 59 insertions(+), 9 deletions(-)
  create mode 100644 iconvdata/bug-iconv13.c

-Index: git/iconvdata/Makefile
-===
 git.orig/iconvdata/Makefile
-+++ git/iconvdata/Makefile
-@@ -73,7 +73,7 @@ modules.so := $(addsuffix .so, $(modules
+diff --git a/iconvdata/Makefile b/iconvdata/Makefile
+index 4ec2741cdc..85009f3390 100644
+--- a/iconvdata/Makefile
 b/iconvdata/Makefile
+@@ -73,7 +73,8 @@
  ifeq (yes,$(build-shared))
  tests = bug-iconv1 bug-iconv2 tst-loading tst-e2big tst-iconv4 bug-iconv4 \
tst-iconv6 bug-iconv5 bug-iconv6 tst-iconv7 bug-iconv8 bug-iconv9 \
 -  bug-iconv10 bug-iconv11 bug-iconv12
-+  bug-iconv10 bug-iconv11 bug-iconv12 bug-iconv13
++  bug-iconv10 bug-iconv11 bug-iconv12 tst-iconv-big5-hkscs-to-2ucs4 \
++   bug-iconv13
  ifeq ($(have-thread-library),yes)
  tests += bug-iconv3
  endif
-Index: git/iconvdata/bug-iconv13.c
-===
+diff --git a/iconvdata/bug-iconv13.c b/iconvdata/bug-iconv13.c
+new file mode 100644
+index 00..87aaff398e
 --- /dev/null
-+++ git/iconvdata/bug-iconv13.c
 b/iconvdata/bug-iconv13.c
 @@ -0,0 +1,53 @@
 +/* bug 24973: Test EUC-KR module
 +   Copyright (C) 2020 Free Software Foundation, Inc.
@@ -93,11 +97,11 @@ Index: git/iconvdata/bug-iconv13.c
 +}
 +
 +#include 
-Index: git/iconvdata/euc-kr.c
-===
 git.orig/iconvdata/euc-kr.c
-+++ git/iconvdata/euc-kr.c
-@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned c
+diff --git a/iconvdata/euc-kr.c b/iconvdata/euc-kr.c
+index b0d56cf3ee..1045bae926 100644
+--- a/iconvdata/euc-kr.c
 b/iconvdata/euc-kr.c
+@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned char *cp)
  \
  if (ch <= 0x9f) \
++inptr;
  \
@@ -110,11 +114,11 @@ Index: git/iconvdata/euc-kr.c
{   
  \
/* This is illegal.  */   \
STANDARD_FROM_LOOP_ERR_HANDLER (1);   \
-Index: git/iconvdata/ksc5601.h
-===
 git.orig/iconvdata/ksc5601.h
-+++ git/iconvdata/ksc5601.h
-@@ -50,15 +50,15 @@ ksc5601_to_ucs4 (const unsigned char **s
+diff --git a/iconvdata/ksc5601.h b/iconvdata/ksc5601.h
+index d3eb3a4ff8..f5cdc72797 100644
+--- a/iconvdata/ksc5601.h
 b/iconvdata/ksc5601.h
+@@ -50,15 +50,15 @@ ksc5601_to_ucs4 (const unsigned char **s, size_t avail, 
unsigned char offset)
unsigned char ch2;
int idx;

@@ -133,3 +137,5 @@ Index: 

[OE-core] [PATCH v2] rootfs.py: mask run-postinsts systemd service when unneeded

[Awais Belal]

The service is unnecessarily run even when it is unneeded.
This was handled correctly for sysV systems however the
service still runs on the systemd systems as it is not
disabled/masked when not needed.

Signed-off-by: Awais Belal 
---
 meta/lib/oe/rootfs.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 249c685dcf..fe35ce5b70 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -257,6 +257,10 @@ class Rootfs(object, metaclass=ABCMeta):
 self._exec_shell_cmd(["update-rc.d", "-f", "-r",
   self.d.getVar('IMAGE_ROOTFS'),
   "run-postinsts", "remove"])
+if 
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_unitdir}/system/run-postinsts.service")):
+self._exec_shell_cmd(["systemctl",
+"--root", 
self.d.getVar('IMAGE_ROOTFS'),
+"mask", "run-postinsts.service"])
 
 image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
 True, False, self.d)
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149777): 
https://lists.openembedded.org/g/openembedded-core/message/149777
Mute This Topic: https://lists.openembedded.org/mt/81522036/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] rootfs.py: mask run-postinsts systemd service when unneeded

[Awais Belal]

Hi Alex,

> 
> Why isn’t this seen in the tests? Can you add a test that shows the issue
> please? (Fails without the patch, passes with)

I'm not very well versed with the oe test infrastructure, I'd be happy to 
create a test for this scenario if you can point me to the material that I need 
to go through in order to be able to create a test for this. However, if you 
want me to summarize this tends to fix the issue where the systemd 
run-postinsts.service is run at the target even when not needed (no pending 
postinsts are found during build).

I do need to send a v2 for this as there's a slight issue in the patch.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149776): 
https://lists.openembedded.org/g/openembedded-core/message/149776
Mute This Topic: https://lists.openembedded.org/mt/81518683/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 07/16] mesa: update 20.3.4 -> 21.0.0

[Martin Jansa]

On Fri, Mar 19, 2021 at 09:43:52AM +0100, Alexander Kanavin wrote:
> 0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> merged upstream.
> 
> osmesa is now a simple boolean option.
> 
> Swrast has been removed from dri drivers, so as we need at least one
> driver to enable dri in native/nativesdk, replace it with nouveau
> (which does not take long to build).

so the mesa-gl needs similar change, right?

meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb:# When NOT using X11, we need to 
make sure we have swrast available.
meta/recipes-graphics/mesa/mesa-gl_21.0.0.bb:DRIDRIVERS_append = 
"${@bb.utils.contains('DISTRO_FEATURES', 'x11', '', ',swrast', d)}"

Now it's failing with:
http://errors.yoctoproject.org/Errors/Build/118645/

> 
> Signed-off-by: Alexander Kanavin 
> ---
>  ...race-between-generating-a-header-and.patch | 31 ---
>  ...k-for-all-linux-host_os-combinations.patch | 12 +++
>  ...02-meson.build-make-TLS-ELF-optional.patch | 14 -
>  .../{mesa-gl_20.3.4.bb => mesa-gl_21.0.0.bb}  |  0
>  meta/recipes-graphics/mesa/mesa.inc   | 10 +++---
>  .../mesa/{mesa_20.3.4.bb => mesa_21.0.0.bb}   |  0
>  6 files changed, 17 insertions(+), 50 deletions(-)
>  delete mode 100644 
> meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
>  rename meta/recipes-graphics/mesa/{mesa-gl_20.3.4.bb => mesa-gl_21.0.0.bb} 
> (100%)
>  rename meta/recipes-graphics/mesa/{mesa_20.3.4.bb => mesa_21.0.0.bb} (100%)
> 
> diff --git 
> a/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
>  
> b/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> deleted file mode 100644
> index a61e7b2160..00
> --- 
> a/meta/recipes-graphics/mesa/files/0001-anv-fix-a-build-race-between-generating-a-header-and.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -From f148d4f1b5b13288b254ead07f1d008d997e2342 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Mon, 2 Nov 2020 23:23:53 +0100
> -Subject: [PATCH] anv: fix a build race between generating a header and using
> - it
> -
> -anv_batch_chain.c includes genX_bits.h but doesn't ensure it gets
> -generated first. This causes build failures, as observed here:
> -https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/1501/steps/8/logs/step2d
> -
> -Upstream-Status: Submitted 
> [https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/7412]
> -Signed-off-by: Alexander Kanavin 
> 
> - src/intel/vulkan/meson.build | 1 +
> - 1 file changed, 1 insertion(+)
> -
> -diff --git a/src/intel/vulkan/meson.build b/src/intel/vulkan/meson.build
> -index 36e1689314e..b713d8eade3 100644
>  a/src/intel/vulkan/meson.build
> -+++ b/src/intel/vulkan/meson.build
> -@@ -131,6 +131,7 @@ libanv_files = files(
> - anv_deps = [
> -   dep_libdrm,
> -   dep_valgrind,
> -+  idep_genxml,
> -   idep_nir_headers,
> -   idep_vulkan_util_headers,
> - ]
> --- 
> -2.29.0
> -
> diff --git 
> a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
>  
> b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> index 085254323c..b6f86743e1 100644
> --- 
> a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> +++ 
> b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
> @@ -1,4 +1,4 @@
> -From 0d9ed002eff176b902da266d89829a9b0cb10946 Mon Sep 17 00:00:00 2001
> +From 38e984073e4c23b6278d1a2ff21e894fda7b93c5 Mon Sep 17 00:00:00 2001
>  From: Alistair Francis 
>  Date: Thu, 14 Nov 2019 13:04:49 -0800
>  Subject: [PATCH] meson.build: check for all linux host_os combinations
> @@ -20,10 +20,10 @@ Signed-off-by: Alistair Francis 
>   1 file changed, 2 insertions(+), 2 deletions(-)
>
>  diff --git a/meson.build b/meson.build
> -index 898d025..09e3759 100644
> +index 932eb13..efc6171 100644
>  --- a/meson.build
>  +++ b/meson.build
> -@@ -124,7 +124,7 @@ with_any_opengl = with_opengl or with_gles1 or with_gles2
> +@@ -153,7 +153,7 @@ with_any_opengl = with_opengl or with_gles1 or with_gles2
>   # Only build shared_glapi if at least one OpenGL API is enabled
>   with_shared_glapi = with_shared_glapi and with_any_opengl
>   
> @@ -32,12 +32,12 @@ index 898d025..09e3759 100644
>   
>   dri_drivers = get_option('dri-drivers')
>   if dri_drivers.contains('auto')
> -@@ -884,7 +884,7 @@ if cc.compiles('__uint128_t foo(void) { return 0; }',
> +@@ -970,7 +970,7 @@ if cc.compiles('__uint128_t foo(void) { return 0; }',
>   endif
>   
>   # TODO: this is very incomplete
> --if ['linux', 'cygwin', 'gnu', 'freebsd', 
> 'gnu/kfreebsd'].contains(host_machine.system())
> -+if ['cygwin', 'gnu', 'gnu/kfreebsd'].contains(host_machine.system()) or 
> host_machine.system().startswith('linux')
> +-if ['linux', 'cygwin', 'gnu', 'freebsd', 'gnu/kfreebsd', 
> 

Re: [OE-core] [PATCH] report-error.bbclass: replace angle brackets with and

[Martin Jansa]

On Sun, Mar 14, 2021 at 06:03:25PM -0700, Khem Raj wrote:
> From: Changqing Li 
> 
> when we have below content in local.conf or auto.conf:
> BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj "
> send-error-report will fail with "HTTP Error 500: OK"
> 
> error-report-web do rudimentary check on all fields that are
> passed to the graphs page to avoid any XSS happening, if contains
> '<', the server will return error(Invalid characters in json).
> fixed by use escape of <> to replace it.
> 
> NOTE: with this change, error-report-web need to add filter 'safe'
> for the string wanted to display to avoid further HTML escaping
> prior to output. Below is how the content displayed on webpage:
> with the filter 'safe':
> BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj "
> without the filter 'safe':
> BUILDHISTORY_COMMIT_AUTHOR ?= "Khem Raj raj.k...@gmail.com"
> 
> Another patch for error-report-web will send to yocto mail list.
> 
> [YOCTO #13252]

Acked-by: Martin Jansa 

> Signed-off-by: Changqing Li 
> Signed-off-by: Khem Raj 
> ---
>  meta/classes/report-error.bbclass | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/classes/report-error.bbclass 
> b/meta/classes/report-error.bbclass
> index 9cb6b0bd31..8dac854944 100644
> --- a/meta/classes/report-error.bbclass
> +++ b/meta/classes/report-error.bbclass
> @@ -38,6 +38,7 @@ def get_conf_data(e, filename):
>  continue
>  else:
>  jsonstring=jsonstring + line
> +jsonstring = jsonstring.replace("<", "").replace(">", "")
>  return jsonstring
>
>  python errorreport_handler () {
> -- 
> 2.30.2
> 

> 
> 
> 



signature.asc
Description: PGP signature

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

[OE-core] [poky][dunfell][PATCH] glibc: Add and modify CVEs

[saloni]

Below patch is modified:
1. CVE-2019-25013
The previous patch was modified for dunfell
context and causing conflict for CVE-2021-3326.
Hence, the original patch is backported.
Link: https://security-tracker.debian.org/tracker/CVE-2020-27618
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=9a99c682144bdbd40792ebf822fe9264e0376fb5

Below patch is added:
1. CVE-2021-3326
Link: https://bugzilla.redhat.com/show_bug.cgi?id=1932589
Link: 
https://sourceware.org/git/?p=glibc.git;a=patch;h=dca565886b5e8bd7966e15f0ca42ee5cff686673

Signed-off-by: Saloni Jain 
---
 .../glibc/glibc/CVE-2019-25013.patch  |  52 +--
 .../glibc/glibc/CVE-2021-3326.patch   | 297 ++
 meta/recipes-core/glibc/glibc_2.31.bb |   3 +-
 3 files changed, 328 insertions(+), 24 deletions(-)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2021-3326.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch 
b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
index 73df1da868..3e446f2818 100644
--- a/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
+++ b/meta/recipes-core/glibc/glibc/CVE-2019-25013.patch
@@ -8,12 +8,14 @@ area and is not allowed.  The from_euc_kr function used to 
skip two bytes
 when told to skip over the unknown designation, potentially running over
 the buffer end.

-Upstream-Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
 CVE: CVE-2019-25013
-Signed-off-by: Scott Murray 
-[Refreshed for Dundell context; Makefile changes]
-Signed-off-by: Armin Kuster 
+Upstream Status: Backport 
[https://sourceware.org/git/?p=glibc.git;a=patch;h=ee7a3144c9922808181009b7b3e50e852fb4999b]
+Comment: No change in any hunk

+The previous change was modified for dunfell context, causing conflict
+for CVE-2021-3326. Hence, the original patch is backported.
+
+Signed-off-by: Saloni Jain 
 ---
  iconvdata/Makefile  |  3 ++-
  iconvdata/bug-iconv13.c | 53 +
@@ -22,23 +24,25 @@ Signed-off-by: Armin Kuster 
  4 files changed, 59 insertions(+), 9 deletions(-)
  create mode 100644 iconvdata/bug-iconv13.c

-Index: git/iconvdata/Makefile
-===
 git.orig/iconvdata/Makefile
-+++ git/iconvdata/Makefile
-@@ -73,7 +73,7 @@ modules.so := $(addsuffix .so, $(modules
+diff --git a/iconvdata/Makefile b/iconvdata/Makefile
+index 4ec2741cdc..85009f3390 100644
+--- a/iconvdata/Makefile
 b/iconvdata/Makefile
+@@ -73,7 +73,8 @@
  ifeq (yes,$(build-shared))
  tests = bug-iconv1 bug-iconv2 tst-loading tst-e2big tst-iconv4 bug-iconv4 \
tst-iconv6 bug-iconv5 bug-iconv6 tst-iconv7 bug-iconv8 bug-iconv9 \
 -  bug-iconv10 bug-iconv11 bug-iconv12
-+  bug-iconv10 bug-iconv11 bug-iconv12 bug-iconv13
++  bug-iconv10 bug-iconv11 bug-iconv12 tst-iconv-big5-hkscs-to-2ucs4 \
++   bug-iconv13
  ifeq ($(have-thread-library),yes)
  tests += bug-iconv3
  endif
-Index: git/iconvdata/bug-iconv13.c
-===
+diff --git a/iconvdata/bug-iconv13.c b/iconvdata/bug-iconv13.c
+new file mode 100644
+index 00..87aaff398e
 --- /dev/null
-+++ git/iconvdata/bug-iconv13.c
 b/iconvdata/bug-iconv13.c
 @@ -0,0 +1,53 @@
 +/* bug 24973: Test EUC-KR module
 +   Copyright (C) 2020 Free Software Foundation, Inc.
@@ -93,11 +97,11 @@ Index: git/iconvdata/bug-iconv13.c
 +}
 +
 +#include 
-Index: git/iconvdata/euc-kr.c
-===
 git.orig/iconvdata/euc-kr.c
-+++ git/iconvdata/euc-kr.c
-@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned c
+diff --git a/iconvdata/euc-kr.c b/iconvdata/euc-kr.c
+index b0d56cf3ee..1045bae926 100644
+--- a/iconvdata/euc-kr.c
 b/iconvdata/euc-kr.c
+@@ -80,11 +80,7 @@ euckr_from_ucs4 (uint32_t ch, unsigned char *cp)
  \
  if (ch <= 0x9f) \
++inptr;
  \
@@ -110,11 +114,11 @@ Index: git/iconvdata/euc-kr.c
{   
  \
/* This is illegal.  */   \
STANDARD_FROM_LOOP_ERR_HANDLER (1);   \
-Index: git/iconvdata/ksc5601.h
-===
 git.orig/iconvdata/ksc5601.h
-+++ git/iconvdata/ksc5601.h
-@@ -50,15 +50,15 @@ ksc5601_to_ucs4 (const unsigned char **s
+diff --git a/iconvdata/ksc5601.h b/iconvdata/ksc5601.h
+index d3eb3a4ff8..f5cdc72797 100644
+--- a/iconvdata/ksc5601.h
 b/iconvdata/ksc5601.h
+@@ -50,15 +50,15 @@ ksc5601_to_ucs4 (const unsigned char **s, size_t avail, 
unsigned char offset)
unsigned char ch2;
int idx;

@@ -133,3 +137,5 @@ Index: 

Re: [OE-core] [gatesgarth][PATCH 01/30] initrdscripts: init-install-efi.sh install extra files for ESP

[Lee Chee Yang]

Hi, 

Can this backport to Dunfell too?

>-Original Message-
>From: openembedded-core@lists.openembedded.org c...@lists.openembedded.org> On Behalf Of Anuj Mittal
>Sent: Tuesday, 23 February, 2021 12:00 AM
>To: openembedded-core@lists.openembedded.org
>Subject: [OE-core] [gatesgarth][PATCH 01/30] initrdscripts: init-install-efi.sh
>install extra files for ESP
>
>From: Chee Yang Lee 
>
>Currently the install script copy only few hard coded item while setting up 
>target
>ESP, kernel artifacts, all .efi in EFI/BOOT, grub & boot cfg and loader.conf.
>While ESP can be much complex, eg: contain multiple initrd.
>
>Add a ESP folder to carry any other files to setup onto ESP.
>
>Signed-off-by: Chee Yang Lee 
>Signed-off-by: Richard Purdie 
>(cherry picked from commit 6eaca9cf20c42501fba27dea3a6446bad948e859)
>Signed-off-by: Anuj Mittal 
>---
> meta/recipes-core/initrdscripts/files/init-install-efi.sh | 5 +
> 1 file changed, 5 insertions(+)
>
>diff --git a/meta/recipes-core/initrdscripts/files/init-install-efi.sh 
>b/meta/recipes-
>core/initrdscripts/files/init-install-efi.sh
>index b6855b5aac..f667518b89 100644
>--- a/meta/recipes-core/initrdscripts/files/init-install-efi.sh
>+++ b/meta/recipes-core/initrdscripts/files/init-install-efi.sh
>@@ -279,6 +279,11 @@ fi
>
> umount /tgt_root
>
>+# copy any extra files needed for ESP
>+if [ -d /run/media/$1/esp ]; then
>+cp -r /run/media/$1/esp/* /boot
>+fi
>+
> # Copy kernel artifacts. To add more artifacts just add to types  # For now 
> just
>support kernel types already being used by something in OE-core  for types in
>bzImage zImage vmlinux vmlinuz fitImage; do
>--
>2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149772): 
https://lists.openembedded.org/g/openembedded-core/message/149772
Mute This Topic: https://lists.openembedded.org/mt/80827809/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 v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

[Yu, Mingli]

On 3/22/21 4:29 PM, Alexander Kanavin wrote:

**[Please note: This e-mail is from an EXTERNAL e-mail address]

Note that this m4 file is copied verbatim from upstream gettext, and 
will be again overwritten on next gettext upgrade. You should figure out 
what’s wrong specifically in elfutils tree, and work with elfutils 
upstream to resolve it.


Hi Alex,

The reason why we care out iconv.m4 is because want to keep the logic in 
https://git.openembedded.org/openembedded-core/commit/?id=3dd269e027fda173ee40d671ea47da22300fd51d 
which oe specific.


I think there is nothing wrong for elfutils switches to use AM_GNU_GETTEXT.

Thanks,



Alex

On Mon 22. Mar 2021 at 10.51, Yu, Mingli > wrote:


From: Mingli Yu mailto:mingli...@windriver.com>>

The below m4 macros files shipped with recipe will be removed if the
recipe use AM_GNU_GETTEXT.
gettext.m4
iconv.m4
lib-ld.m4
lib-link.m4
lib-prefix.m4
nls.m4 po.m4
progtest.m4

After elfutils upgrades to 0.183, it begins to use AM_GNU_GETTEXT as the
commit (dd52d2ab Modernize gettext infrastructure) included, so the
above
m4 macros files such as iconv.m4 is removed and it's bad as we need to
patch against iconv.m4 shipped with elfutils.

BTW, the logic to Disable the unnecessary check in iconv.m4 comes since
2015 as [1], so move the related logic to gettext-minimal which provides
iconv.m4 now to fix the gap.

[1]

https://git.openembedded.org/openembedded-core/commit/?id=3dd269e027fda173ee40d671ea47da22300fd51d

Signed-off-by: Mingli Yu mailto:mingli...@windriver.com>>
---
  meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4 | 2 ++
  1 file changed, 2 insertions(+)

diff --git
a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
index e593b7270a..e04476bb7f 100644
--- a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
+++ b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
@@ -166,6 +166,7 @@ AC_DEFUN([AM_ICONV_LINK],
        }
    }
  #endif
+#if 0
    /* Test against HP-UX 11.11 bug: No converter from EUC-JP to
UTF-8 is
       provided.  */
    {
@@ -189,6 +190,7 @@ AC_DEFUN([AM_ICONV_LINK],
      if (cd4 != (iconv_t)(-1))
        iconv_close (cd4);
    }
+#endif
    return result;
  ]])],
            [am_cv_func_iconv_works=yes], ,
-- 
2.17.1






-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149771): 
https://lists.openembedded.org/g/openembedded-core/message/149771
Mute This Topic: https://lists.openembedded.org/mt/81519074/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] scripts: add oe-time-dd-test.sh

[Sakib Sajal]

oe-time-dd-test records how much time it takes to
write  number of kilobytes to the filesystem.
It also records the number of processes that are in
running (R), uninterruptible sleep (D) and interruptible
sleep (S) state from the output of "top" command.
The purporse of this script is to find which part of
the build system puts stress on the filesystem io and
log all the processes.

Signed-off-by: Sakib Sajal 
---
 scripts/oe-time-dd-test.sh | 23 +++
 1 file changed, 23 insertions(+)
 create mode 100644 scripts/oe-time-dd-test.sh

diff --git a/scripts/oe-time-dd-test.sh b/scripts/oe-time-dd-test.sh
new file mode 100644
index 00..970a86dff0
--- /dev/null
+++ b/scripts/oe-time-dd-test.sh
@@ -0,0 +1,23 @@
+#!/bin/sh
+#
+# oe-time-dd-test records how much time it takes to 
+# write  number of kilobytes to the filesystem.
+# It also records the number of processes that are in
+# running (R), uninterruptible sleep (D) and interruptible
+# sleep (S) state from the output of "top" command.
+# The purporse of this script is to find which part of
+# the build system puts stress on the filesystem io and
+# log all the processes.
+
+usage() {
+echo "Usage: $0 "
+}
+
+if [ $# -ne 1 ]; then
+usage
+exit 1
+fi
+
+uptime
+/usr/bin/time -f "%e" dd if=/dev/zero of=foo bs=1024 count=$1 conv=fsync
+top -b -n 1 | grep -v "0  0  0" | grep -E ' [RSD] ' | cut -c 46-47 | 
sort | uniq -c
-- 
2.29.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149770): 
https://lists.openembedded.org/g/openembedded-core/message/149770
Mute This Topic: https://lists.openembedded.org/mt/81519575/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] rootfs.py: mask run-postinsts systemd service when unneeded

[Alexander Kanavin]

Why isn’t this seen in the tests? Can you add a test that shows the issue
please? (Fails without the patch, passes with)

Alex

On Mon 22. Mar 2021 at 10.07, Awais Belal  wrote:

> The service is unnecessarily run even when it is unneeded.
> This was handled correctly for sysV systems however the
> service still runs on the systemd systems as it is not
> disabled/masked when not needed.
>
> Signed-off-by: Awais Belal 
> ---
>  meta/lib/oe/rootfs.py | 4 
>  1 file changed, 4 insertions(+)
>
> diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
> index 249c685dcf..a29d1f6742 100644
> --- a/meta/lib/oe/rootfs.py
> +++ b/meta/lib/oe/rootfs.py
> @@ -257,6 +257,10 @@ class Rootfs(object, metaclass=ABCMeta):
>  self._exec_shell_cmd(["update-rc.d", "-f", "-r",
>self.d.getVar('IMAGE_ROOTFS'),
>"run-postinsts", "remove"])
> +if
> os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_unitdir}/system/run-postinsts.service")):
> +self._exec_shell_cmd(["systemctl",
> +"--root",
> self.d.getVar('IMAGE_ROOTFS'),
> +"mask", "run-postinsts"])
>
>  image_rorfs = bb.utils.contains("IMAGE_FEATURES",
> "read-only-rootfs",
>  True, False, self.d)
> --
> 2.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149769): 
https://lists.openembedded.org/g/openembedded-core/message/149769
Mute This Topic: https://lists.openembedded.org/mt/81518683/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 v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

[Alexander Kanavin]

Note that this m4 file is copied verbatim from upstream gettext, and will
be again overwritten on next gettext upgrade. You should figure out what’s
wrong specifically in elfutils tree, and work with elfutils upstream to
resolve it.

Alex

On Mon 22. Mar 2021 at 10.51, Yu, Mingli  wrote:

> From: Mingli Yu 
>
> The below m4 macros files shipped with recipe will be removed if the
> recipe use AM_GNU_GETTEXT.
> gettext.m4
> iconv.m4
> lib-ld.m4
> lib-link.m4
> lib-prefix.m4
> nls.m4 po.m4
> progtest.m4
>
> After elfutils upgrades to 0.183, it begins to use AM_GNU_GETTEXT as the
> commit (dd52d2ab Modernize gettext infrastructure) included, so the above
> m4 macros files such as iconv.m4 is removed and it's bad as we need to
> patch against iconv.m4 shipped with elfutils.
>
> BTW, the logic to Disable the unnecessary check in iconv.m4 comes since
> 2015 as [1], so move the related logic to gettext-minimal which provides
> iconv.m4 now to fix the gap.
>
> [1]
> https://git.openembedded.org/openembedded-core/commit/?id=3dd269e027fda173ee40d671ea47da22300fd51d
>
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4 | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git
> a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
> b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
> index e593b7270a..e04476bb7f 100644
> --- a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
> +++ b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
> @@ -166,6 +166,7 @@ AC_DEFUN([AM_ICONV_LINK],
>}
>}
>  #endif
> +#if 0
>/* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
>   provided.  */
>{
> @@ -189,6 +190,7 @@ AC_DEFUN([AM_ICONV_LINK],
>  if (cd4 != (iconv_t)(-1))
>iconv_close (cd4);
>}
> +#endif
>return result;
>  ]])],
>[am_cv_func_iconv_works=yes], ,
> --
> 2.17.1
>
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149768): 
https://lists.openembedded.org/g/openembedded-core/message/149768
Mute This Topic: https://lists.openembedded.org/mt/81519074/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 v3 2/2] elfutils: remove 0004-Disable-the-test-to-convert-euc-jp.patch

[Yu, Mingli]

From: Mingli Yu 

The below m4 macros files shipped with recipe will be removed if the
recipe use AM_GNU_GETTEXT.
gettext.m4
iconv.m4
lib-ld.m4
lib-link.m4
lib-prefix.m4
nls.m4 po.m4
progtest.m4

After elfutils upgrades to 0.183, it begins to use AM_GNU_GETTEXT as the
commit (dd52d2ab Modernize gettext infrastructure) included, so the above
m4 macros files such as iconv.m4 is removed and it's bad as we need to
patch against iconv.m4 shipped with elfutils.

So remove 0004-Disable-the-test-to-convert-euc-jp.patch and move the logic
to gettext-mininal which provides iconv.m4 now to fix the gap and also fix
the below build issue.
  $ bitbake elfutils -cconfigure && bitbake elfutils -cpatch -f

Signed-off-by: Mingli Yu 
---
 .../elfutils/elfutils_0.183.bb|  1 -
 ...4-Disable-the-test-to-convert-euc-jp.patch | 42 ---
 2 files changed, 43 deletions(-)
 delete mode 100644 
meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.183.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.183.bb
index 16ed7c9ddb..c0833686de 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.183.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.183.bb
@@ -14,7 +14,6 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://0001-dso-link-change.patch \
file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
file://0003-fixheadercheck.patch \
-   file://0004-Disable-the-test-to-convert-euc-jp.patch \
file://0006-Fix-build-on-aarch64-musl.patch \
file://0001-libasm-may-link-with-libbz2-if-found.patch \

file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
diff --git 
a/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
 
b/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
deleted file mode 100644
index f407bdd0be..00
--- 
a/meta/recipes-devtools/elfutils/files/0004-Disable-the-test-to-convert-euc-jp.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From cd36f34c722dd0babd7beb13c968aa0780c9f726 Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Tue, 15 Aug 2017 17:24:06 +0800
-Subject: [PATCH] Disable the test to convert euc-jp
-
-Remove the test "Test against HP-UX 11.11 bug:
-No converter from EUC-JP to UTF-8 is provided"
-since we don't support HP-UX and if the euc-jp is not
-installed on the host, the dependence will be built without
-iconv support and will cause guild-native building fail.
-
-Upstream-Status: Inappropriate [OE specific]
-
-Signed-off-by: Roy Li 
-
-Rebase to 0.170
-Signed-off-by: Hongxu Jia 
-

- m4/iconv.m4 | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/m4/iconv.m4 b/m4/iconv.m4
-index aa159c5..d16312b 100644
 a/m4/iconv.m4
-+++ b/m4/iconv.m4
-@@ -165,6 +165,7 @@ AC_DEFUN([AM_ICONV_LINK],
-   }
-   }
- #endif
-+#if 0
-   /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
-  provided.  */
-   if (/* Try standardized names.  */
-@@ -176,6 +177,7 @@ AC_DEFUN([AM_ICONV_LINK],
-   /* Try HP-UX names.  */
-   && iconv_open ("utf8", "eucJP") == (iconv_t)(-1))
- result |= 16;
-+#endif
-   return result;
- ]])],
-   [am_cv_func_iconv_works=yes], ,
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149767): 
https://lists.openembedded.org/g/openembedded-core/message/149767
Mute This Topic: https://lists.openembedded.org/mt/81519077/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 v3 1/2] gettext-minimal: Disable the unnecessary check in iconv.m4

[Yu, Mingli]

From: Mingli Yu 

The below m4 macros files shipped with recipe will be removed if the
recipe use AM_GNU_GETTEXT.
gettext.m4
iconv.m4
lib-ld.m4
lib-link.m4
lib-prefix.m4
nls.m4 po.m4
progtest.m4

After elfutils upgrades to 0.183, it begins to use AM_GNU_GETTEXT as the
commit (dd52d2ab Modernize gettext infrastructure) included, so the above
m4 macros files such as iconv.m4 is removed and it's bad as we need to
patch against iconv.m4 shipped with elfutils.

BTW, the logic to Disable the unnecessary check in iconv.m4 comes since
2015 as [1], so move the related logic to gettext-minimal which provides
iconv.m4 now to fix the gap.

[1] 
https://git.openembedded.org/openembedded-core/commit/?id=3dd269e027fda173ee40d671ea47da22300fd51d

Signed-off-by: Mingli Yu 
---
 meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4 | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4 
b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
index e593b7270a..e04476bb7f 100644
--- a/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
+++ b/meta/recipes-core/gettext/gettext-minimal-0.21/aclocal/iconv.m4
@@ -166,6 +166,7 @@ AC_DEFUN([AM_ICONV_LINK],
   }
   }
 #endif
+#if 0
   /* Test against HP-UX 11.11 bug: No converter from EUC-JP to UTF-8 is
  provided.  */
   {
@@ -189,6 +190,7 @@ AC_DEFUN([AM_ICONV_LINK],
 if (cd4 != (iconv_t)(-1))
   iconv_close (cd4);
   }
+#endif
   return result;
 ]])],
   [am_cv_func_iconv_works=yes], ,
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149766): 
https://lists.openembedded.org/g/openembedded-core/message/149766
Mute This Topic: https://lists.openembedded.org/mt/81519074/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][dunfell][PATCH] rapidjson: Remove unwanted patches

[Harpritkaur Bhandari]

Hi,

Can you please confirm when this patch will get merge in dunfell branch as the 
changes are already merged in master branch.


Thanks & Regards,

Harprit Bhandari


From: Harpritkaur Bhandari 
Sent: 05 March 2021 17:05
To: openembedded-core@lists.openembedded.org 
; raj.k...@gmail.com 

Cc: Nisha Parrakat ; st...@sakoman.com 
; Harpritkaur Bhandari 
Subject: [meta-oe][dunfell][PATCH] rapidjson: Remove unwanted patches

From: Harpritkaur Bhandari 

rapidjson is upgraded to latest SRCREV so
removing the below patches which are not
applicable:
1.0001-CMake-remove-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch
2.remove-march-native-from-CMAKE_CXX_FLAGS.patch

Signed-off-by: Khem Raj 
(cherry picked from commit 5aa127af2d3942c9b1dfcd768a8123513a26c53f)
Signed-off-by: Harpritkaur Bhandari 
---
 ...ve-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch | 36 ---
 .../remove-march-native-from-CMAKE_CXX_FLAGS.patch | 40 --
 2 files changed, 76 deletions(-)
 delete mode 100644 
meta-oe/recipes-devtools/rapidjson/rapidjson/0001-CMake-remove-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch
 delete mode 100644 
meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch

diff --git 
a/meta-oe/recipes-devtools/rapidjson/rapidjson/0001-CMake-remove-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch
 
b/meta-oe/recipes-devtools/rapidjson/rapidjson/0001-CMake-remove-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch
deleted file mode 100644
index 745f5d0..000
--- 
a/meta-oe/recipes-devtools/rapidjson/rapidjson/0001-CMake-remove-hardcoded-CMAKECONFIG_INSTALL_DIR-path.patch
+++ /dev/null
@@ -1,36 +0,0 @@
-From 8d272e53a4d1dc405e08ce2dd50159c58f4451e9 Mon Sep 17 00:00:00 2001
-From: Ruslan Bilovol 
-Date: Thu, 24 Jan 2019 18:11:39 +0200
-Subject: [PATCH] CMake: remove hardcoded CMAKECONFIG_INSTALL_DIR path
-
-Currently this path is hardcoded to lib/cmake.
-Some distributions have different library path (like lib64).
-So reuse LIB_INSTALL_DIR for that to make CMAKECONFIG_INSTALL_DIR
-configurable and usable in such distros.
-
-Upstream-Status: Backport 
[https://github.com/Tencent/rapidjson/commit/8d272e53a4d1dc405e08ce2dd50159c58f4451e9]
-
-Signed-off-by: Ruslan Bilovol 

- CMakeLists.txt | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/CMakeLists.txt b/CMakeLists.txt
-index 7c60407..0275672 100644
 a/CMakeLists.txt
-+++ b/CMakeLists.txt
-@@ -199,9 +199,9 @@ 
CONFIGURE_FILE(${CMAKE_CURRENT_SOURCE_DIR}/${PROJECT_NAME}ConfigVersion.cmake.in
- ${CMAKE_CURRENT_BINARY_DIR}/${PROJECT_NAME}ConfigVersion.cmake @ONLY)
-
- # ... for the install tree
--SET( CMAKECONFIG_INSTALL_DIR lib/cmake/${PROJECT_NAME} )
-+SET( CMAKECONFIG_INSTALL_DIR ${LIB_INSTALL_DIR}/cmake/${PROJECT_NAME} )
- FILE( RELATIVE_PATH REL_INCLUDE_DIR
--"${CMAKE_INSTALL_PREFIX}/${CMAKECONFIG_INSTALL_DIR}"
-+"${CMAKECONFIG_INSTALL_DIR}"
- "${CMAKE_INSTALL_PREFIX}/include" )
-
- SET( ${PROJECT_NAME}_INCLUDE_DIR 
"\${${PROJECT_NAME}_CMAKE_DIR}/${REL_INCLUDE_DIR}" )
---
-1.9.1
-
diff --git 
a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
 
b/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
deleted file mode 100644
index cf3e16e..000
--- 
a/meta-oe/recipes-devtools/rapidjson/rapidjson/remove-march-native-from-CMAKE_CXX_FLAGS.patch
+++ /dev/null
@@ -1,40 +0,0 @@
-From 827155e5e659b2a5065b00d701bc59b57feab2bf Mon Sep 17 00:00:00 2001
-From: Andre McCurdy 
-Date: Mon, 19 Dec 2016 01:37:11 -0800
-Subject: [PATCH] remove -march=native from CMAKE_CXX_FLAGS
-
-Not appropriate when cross compiling.
-
-Upstream-Status: Inappropriate [configuration]
-
-Signed-off-by: Andre McCurdy 

- CMakeLists.txt | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-Index: git/CMakeLists.txt
-===
 git.orig/CMakeLists.txt
-+++ git/CMakeLists.txt
-@@ -51,10 +51,10 @@ endif(CCACHE_FOUND)
-
- if ("${CMAKE_CXX_COMPILER_ID}" STREQUAL "GNU")
- if(${CMAKE_SYSTEM_PROCESSOR} STREQUAL "powerpc" OR 
${CMAKE_SYSTEM_PROCESSOR} STREQUAL "ppc64" OR ${CMAKE_SYSTEM_PROCESSOR} 
STREQUAL "ppc64le")
--  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
-+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
- else()
-   #FIXME: x86 is -march=native, but doesn't mean every arch is this 
option. To keep original project's compatibility, I leave this except POWER.
--  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -march=native")
-+  set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS}")
- endif()
- set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -Wall -Wextra -Werror")
- set(EXTRA_CXX_FLAGS -Weffc++ -Wswitch-default -Wfloat-equal -Wconversion 
-Wsign-conversion)
-@@ -84,7 +84,7 @@ elseif (CMAKE_CXX_COMPILER_ID MATCHES "C
-   set(CMAKE_CXX_FLAGS "${CMAKE_CXX_FLAGS} -mcpu=native")
- else()
-   #FIXME: 

[OE-core] [PATCH] rootfs.py: mask run-postinsts systemd service when unneeded

[Awais Belal]

The service is unnecessarily run even when it is unneeded.
This was handled correctly for sysV systems however the
service still runs on the systemd systems as it is not
disabled/masked when not needed.

Signed-off-by: Awais Belal 
---
 meta/lib/oe/rootfs.py | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/lib/oe/rootfs.py b/meta/lib/oe/rootfs.py
index 249c685dcf..a29d1f6742 100644
--- a/meta/lib/oe/rootfs.py
+++ b/meta/lib/oe/rootfs.py
@@ -257,6 +257,10 @@ class Rootfs(object, metaclass=ABCMeta):
 self._exec_shell_cmd(["update-rc.d", "-f", "-r",
   self.d.getVar('IMAGE_ROOTFS'),
   "run-postinsts", "remove"])
+if 
os.path.exists(self.d.expand("${IMAGE_ROOTFS}${systemd_unitdir}/system/run-postinsts.service")):
+self._exec_shell_cmd(["systemctl",
+"--root", 
self.d.getVar('IMAGE_ROOTFS'),
+"mask", "run-postinsts"])
 
 image_rorfs = bb.utils.contains("IMAGE_FEATURES", "read-only-rootfs",
 True, False, self.d)
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#149764): 
https://lists.openembedded.org/g/openembedded-core/message/149764
Mute This Topic: https://lists.openembedded.org/mt/81518683/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] [poky][zeus][PATCH] curl: Security fixes for CVE-2020-{8169/8177}

[Sana Kazi]

Hi,

Could you please review below patch for curl to be upstreamed


 Thanks & Regards,

 Sana Kazi
 KPIT Technologies Limited


From: Sana Kazi 
Sent: Thursday, January 7, 2021 5:26 PM
To: Openembedded-core@lists.openembedded.org 
; raj.k...@gmail.com 

Cc: Nisha Parrakat ; Aditya Tayade 
; Harpritkaur Bhandari ; 
Sana Kazi 
Subject: [poky][zeus][PATCH] curl: Security fixes for CVE-2020-{8169/8177}

From: Armin Kuster 

Source: https://curl.haxx.se/
MR: 104472, 104458
Type: Security Fix
Disposition: Backport from 
https://github.com/curl/curl/commit/{600a8cded447cd/8236aba58542c5f}
ChangeID: 1300924f7a64b22375b4326daeef0b686481e30c
Description:

- Affected versions: curl 7.20.0 to and including 7.70.0
- Not affected versions: curl < 7.20.0 and curl >= 7.71.0

Fixes both CVE-2020-8169 and CVE-2020-8177

(From OE-Core rev: f42702baee57ab3d1b7ab7833e72c7d56ad4ee94)

Signed-off-by: Armin Kuster 
Signed-off-by: Steve Sakoman 
Signed-off-by: Richard Purdie 
Signed-off-by: Sana Kazi 
---
 .../curl/curl/CVE-2020-8169.patch | 141 ++
 .../curl/curl/CVE-2020-8177.patch |  67 +
 meta/recipes-support/curl/curl_7.66.0.bb  |   2 +
 3 files changed, 210 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2020-8169.patch
 create mode 100644 meta/recipes-support/curl/curl/CVE-2020-8177.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2020-8169.patch 
b/meta/recipes-support/curl/curl/CVE-2020-8169.patch
new file mode 100644
index 00..774567c017
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2020-8169.patch
@@ -0,0 +1,141 @@
+From 600a8cded447cd7118ed50142c576567c0cf5158 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Thu, 14 May 2020 14:37:12 +0200
+Subject: [PATCH] url: make the updated credentials URL-encoded in the URL
+
+Found-by: Gregory Jefferis
+Reported-by: Jeroen Ooms
+Added test 1168 to verify. Bug spotted when doing a redirect.
+Bug: https://github.com/jeroen/curl/issues/224
+Closes #5400
+
+Upstream-Status: Backport
+https://github.com/curl/curl/commit/600a8cded447cd
+
+CVE: CVE-2020-8169
+Signed-off-by: Armin Kuster 
+
+---
+ lib/url.c   |  6 ++--
+ tests/data/Makefile.inc |  1 +
+ tests/data/test1168 | 78 +
+ 3 files changed, 83 insertions(+), 2 deletions(-)
+ create mode 100644 tests/data/test1168
+
+Index: curl-7.69.1/lib/url.c
+===
+--- curl-7.69.1.orig/lib/url.c
 curl-7.69.1/lib/url.c
+@@ -2776,12 +2776,14 @@ static CURLcode override_login(struct Cu
+
+   /* for updated strings, we update them in the URL */
+   if(user_changed) {
+-uc = curl_url_set(data->state.uh, CURLUPART_USER, *userp, 0);
++uc = curl_url_set(data->state.uh, CURLUPART_USER, *userp,
++  CURLU_URLENCODE);
+ if(uc)
+   return Curl_uc_to_curlcode(uc);
+   }
+   if(passwd_changed) {
+-uc = curl_url_set(data->state.uh, CURLUPART_PASSWORD, *passwdp, 0);
++uc = curl_url_set(data->state.uh, CURLUPART_PASSWORD, *passwdp,
++  CURLU_URLENCODE);
+ if(uc)
+   return Curl_uc_to_curlcode(uc);
+   }
+Index: curl-7.69.1/tests/data/Makefile.inc
+===
+--- curl-7.69.1.orig/tests/data/Makefile.inc
 curl-7.69.1/tests/data/Makefile.inc
+@@ -129,7 +129,7 @@
+ test1136 test1137 test1138 test1139 test1140 test1141 test1142 test1143 \
+ test1144 test1145 test1146 test1147 test1148 test1149 test1150 test1151 \
+ test1152 test1153 test1154 test1155 test1156 test1157 test1158 test1159 \
+-test1160 test1161 test1162 test1163 test1164 test1165 \
++test1160 test1161 test1162 test1163 test1164 test1165 test1168 \
+ test1170 test1171 test1172 test1173 test1174 \
+ \
+ test1200 test1201 test1202 test1203 test1204 test1205 test1206 test1207 \
+Index: curl-7.69.1/tests/data/test1168
+===
+--- /dev/null
 curl-7.69.1/tests/data/test1168
+@@ -0,0 +1,78 @@
++
++
++
++HTTP
++HTTP GET
++followlocation
++
++
++# Server-side
++
++
++HTTP/1.1 301 This is a weirdo text message swsclose
++Date: Thu, 09 Nov 2010 14:49:00 GMT
++Server: test-server/fake
++Location: /data/11680002.txt
++Connection: close
++
++This server reply is for testing a simple Location: following
++
++
++
++HTTP/1.1 200 Followed here fine swsclose
++Date: Thu, 09 Nov 2010 14:49:00 GMT
++Server: test-server/fake
++Content-Length: 52
++
++If this is received, the location following worked
++
++
++
++HTTP/1.1 301 This is a weirdo text message swsclose
++Date: Thu, 09 Nov 2010 14:49:00 GMT
++Server: test-server/fake
++Location: /data/11680002.txt
++Connection: close
++
++HTTP/1.1 200 Followed here fine swsclose
++Date: Thu, 09 Nov 2010 14:49:00 GMT
++Server: test-server/fake
++Content-Length: 52
++
++If this is received, the location following worked
++
++
++
++