[PATCH 01/10] virglrenderer: explicitly depend on libgbm

[PATCH 01/10] virglrenderer: explicitly depend on libgbm

[Alexander Kanavin]

virtual/gl may not necessarily be mesa, and virgl needs
specifically the gbm part of mesa.

There's also hope nvidia will support gbm somehow, someday.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
index 3991895823..65bd1af942 100644
--- a/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
+++ b/meta/recipes-graphics/virglrenderer/virglrenderer_0.9.1.bb
@@ -8,7 +8,7 @@ HOMEPAGE = "https://virgil3d.github.io/"
 LICENSE = "MIT"
 LIC_FILES_CHKSUM = "file://COPYING;md5=c81c08eeefd9418fca8f88309a76db10"
 
-DEPENDS = "libdrm virtual/libgl libepoxy"
+DEPENDS = "libdrm virtual/libgl virtual/libgbm libepoxy"
 SRCREV = "363915595e05fb252e70d6514be2f0c0b5ca312b"
 SRC_URI = "git://anongit.freedesktop.org/virglrenderer;branch=branch-0.9.1 \
            file://0001-meson.build-use-python3-directly-for-python.patch \
-- 
2.31.1

[PATCH 02/10] elfutils: update 0.183 -> 0.185

[Alexander Kanavin]

0001-add-support-for-ipkg-to-debuginfod.cxx.patch merged upstream.

0001-debuginfod-debuginfod-client.c-correct-string-format.patch rebased.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 .../{elfutils_0.183.bb => elfutils_0.185.bb}  |  3 +-
 ...d-support-for-ipkg-to-debuginfod.cxx.patch | 33 ----------
 ...infod-client.c-correct-string-format.patch | 61 ++++++++-----------
 .../elfutils/files/0002-musl-libs.patch       |  4 +-
 .../elfutils/files/0003-musl-utils.patch      |  8 +--
 .../files/0004-Fix-error-on-musl.patch        |  4 +-
 .../0015-config-eu.am-do-not-use-Werror.patch | 16 ++---
 7 files changed, 42 insertions(+), 87 deletions(-)
 rename meta/recipes-devtools/elfutils/{elfutils_0.183.bb => elfutils_0.185.bb} (97%)
 delete mode 100644 meta/recipes-devtools/elfutils/files/0001-add-support-for-ipkg-to-debuginfod.cxx.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.183.bb b/meta/recipes-devtools/elfutils/elfutils_0.185.bb
similarity index 97%
rename from meta/recipes-devtools/elfutils/elfutils_0.183.bb
rename to meta/recipes-devtools/elfutils/elfutils_0.185.bb
index 7aebaf1b6d..b1ffbc18bf 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.183.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.185.bb
@@ -21,7 +21,6 @@ SRC_URI = "https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
            file://run-ptest \
            file://ptest.patch \
            file://0001-tests-Makefile.am-compile-test_nlist-with-standard-C.patch \
-           file://0001-add-support-for-ipkg-to-debuginfod.cxx.patch \
            file://0001-debuginfod-debuginfod-client.c-correct-string-format.patch \
            "
 SRC_URI_append_libc-musl = " \
@@ -30,7 +29,7 @@ SRC_URI_append_libc-musl = " \
            file://0004-Fix-error-on-musl.patch \
            file://0015-config-eu.am-do-not-use-Werror.patch \
            "
-SRC_URI[sha256sum] = "c3637c208d309d58714a51e61e63f1958808fead882e9b607506a29e5474f2c5"
+SRC_URI[sha256sum] = "dc8d3e74ab209465e7f568e1b3bb9a5a142f8656e2b57d10049a73da2ae6b5a6"
 
 inherit autotools gettext ptest pkgconfig
 
diff --git a/meta/recipes-devtools/elfutils/files/0001-add-support-for-ipkg-to-debuginfod.cxx.patch b/meta/recipes-devtools/elfutils/files/0001-add-support-for-ipkg-to-debuginfod.cxx.patch
deleted file mode 100644
index 5f82afef0c..0000000000
--- a/meta/recipes-devtools/elfutils/files/0001-add-support-for-ipkg-to-debuginfod.cxx.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From 571416bf5b5ef319df6d9c79e46680920487e4a7 Mon Sep 17 00:00:00 2001
-From: dorindabassey <dorindabassey@gmail.com>
-Date: Sat, 19 Dec 2020 01:11:46 +0100
-Subject: [PATCH] add support for ipkg to debuginfod.cxx
-
-added support for ipkg to the debuginfod scanner. 0.182 only supports RPM and scan .debs, with this patch, debuginfod scanner would be able to scan .ipk
-
-Upstream-status: Submitted [https://sourceware.org/pipermail/elfutils-devel/2020q4/003357.html]
-
-Signed-off-by: dorindabassey <dorindabassey@gmail.com>
-
----
- debuginfod/debuginfod.cxx | 2 ++
- 1 file changed, 2 insertions(+)
-
-diff --git a/debuginfod/debuginfod.cxx b/debuginfod/debuginfod.cxx
-index b34eacc..a8915f2 100644
---- a/debuginfod/debuginfod.cxx
-+++ b/debuginfod/debuginfod.cxx
-@@ -484,11 +484,13 @@ parse_opt (int key, char *arg,
-         {
-           scan_archives[".deb"]="dpkg-deb --fsys-tarfile";
-           scan_archives[".ddeb"]="dpkg-deb --fsys-tarfile";
-+          scan_archives[".ipk"]="dpkg-deb --fsys-tarfile";
-         }
-       else
-         {
-           scan_archives[".deb"]="(bsdtar -O -x -f - data.tar.xz)<";
-           scan_archives[".ddeb"]="(bsdtar -O -x -f - data.tar.xz)<";
-+          scan_archives[".ipk"]="(bsdtar -O -x -f - data.tar.xz)<";
-         }
-       // .udeb too?
-       break;
diff --git a/meta/recipes-devtools/elfutils/files/0001-debuginfod-debuginfod-client.c-correct-string-format.patch b/meta/recipes-devtools/elfutils/files/0001-debuginfod-debuginfod-client.c-correct-string-format.patch
index 5bd6ba961c..5b225c532d 100644
--- a/meta/recipes-devtools/elfutils/files/0001-debuginfod-debuginfod-client.c-correct-string-format.patch
+++ b/meta/recipes-devtools/elfutils/files/0001-debuginfod-debuginfod-client.c-correct-string-format.patch
@@ -1,4 +1,4 @@
-From 14dfe84943b8f9e6f504536d8735ef6356210b40 Mon Sep 17 00:00:00 2001
+From c3055ce9eb32d0d24abc5cea5e1d231c499312a7 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Mon, 19 Apr 2021 23:29:10 +0200
 Subject: [PATCH] debuginfod/debuginfod-client.c: correct string format on
@@ -16,15 +16,34 @@ Upstream-Status: Pending
 
 Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
+
 ---
- debuginfod/debuginfod-client.c | 10 +++++-----
- 1 file changed, 5 insertions(+), 5 deletions(-)
+ debuginfod/debuginfod-client.c | 8 ++++----
+ 1 file changed, 4 insertions(+), 4 deletions(-)
 
 diff --git a/debuginfod/debuginfod-client.c b/debuginfod/debuginfod-client.c
-index de26af5..39e28f2 100644
+index ee7eda2..083ec2c 100644
 --- a/debuginfod/debuginfod-client.c
 +++ b/debuginfod/debuginfod-client.c
-@@ -229,7 +229,7 @@ debuginfod_init_cache (char *cache_path, char *interval_path, char *maxage_path)
+@@ -226,7 +226,7 @@ debuginfod_config_cache(char *config_path,
+       if (fd < 0)
+         return -errno;
+ 
+-      if (dprintf(fd, "%ld", cache_config_default_s) < 0)
++      if (dprintf(fd, "%jd", (intmax_t)cache_config_default_s) < 0)
+         return -errno;
+     }
+ 
+@@ -234,7 +234,7 @@ debuginfod_config_cache(char *config_path,
+   FILE *config_file = fopen(config_path, "r");
+   if (config_file)
+     {
+-      if (fscanf(config_file, "%ld", &cache_config) != 1)
++      if (fscanf(config_file, "%jd", (intmax_t*)(&cache_config)) != 1)
+         cache_config = cache_config_default_s;
+       fclose(config_file);
+     }
+@@ -267,7 +267,7 @@ debuginfod_init_cache (char *cache_path, char *interval_path, char *maxage_path)
    if (fd < 0)
      return -errno;
  
@@ -33,7 +52,7 @@ index de26af5..39e28f2 100644
      return -errno;
  
    /* init max age config file.  */
-@@ -237,7 +237,7 @@ debuginfod_init_cache (char *cache_path, char *interval_path, char *maxage_path)
+@@ -275,7 +275,7 @@ debuginfod_init_cache (char *cache_path, char *interval_path, char *maxage_path)
        && (fd = open(maxage_path, O_CREAT | O_RDWR, DEFFILEMODE)) < 0)
      return -errno;
  
@@ -42,33 +61,3 @@ index de26af5..39e28f2 100644
      return -errno;
  
    return 0;
-@@ -263,7 +263,7 @@ debuginfod_clean_cache(debuginfod_client *c,
-       if (interval_file == NULL)
-         return -errno;
- 
--      int rc = fprintf(interval_file, "%ld", cache_clean_default_interval_s);
-+      int rc = fprintf(interval_file, "%jd", (intmax_t)cache_clean_default_interval_s);
-       fclose(interval_file);
- 
-       if (rc < 0)
-@@ -275,7 +275,7 @@ debuginfod_clean_cache(debuginfod_client *c,
-   interval_file = fopen(interval_path, "r");
-   if (interval_file)
-     {
--      if (fscanf(interval_file, "%ld", &clean_interval) != 1)
-+      if (fscanf(interval_file, "%jd", (intmax_t*)(&clean_interval)) != 1)
-         clean_interval = cache_clean_default_interval_s;
-       fclose(interval_file);
-     }
-@@ -291,7 +291,7 @@ debuginfod_clean_cache(debuginfod_client *c,
-   max_unused_file = fopen(max_unused_path, "r");
-   if (max_unused_file)
-     {
--      if (fscanf(max_unused_file, "%ld", &max_unused_age) != 1)
-+      if (fscanf(max_unused_file, "%jd", (intmax_t*)(&max_unused_age)) != 1)
-         max_unused_age = cache_default_max_unused_age_s;
-       fclose(max_unused_file);
-     }
--- 
-2.31.1
-
diff --git a/meta/recipes-devtools/elfutils/files/0002-musl-libs.patch b/meta/recipes-devtools/elfutils/files/0002-musl-libs.patch
index b373940d37..c7360da7a7 100644
--- a/meta/recipes-devtools/elfutils/files/0002-musl-libs.patch
+++ b/meta/recipes-devtools/elfutils/files/0002-musl-libs.patch
@@ -1,4 +1,4 @@
-From 18c527991deee93170a887b6da622560d5606913 Mon Sep 17 00:00:00 2001
+From 0f4667f0bb4b000d74ade07e90bd690b7217a19d Mon Sep 17 00:00:00 2001
 From: Hongxu Jia <hongxu.jia@windriver.com>
 Date: Fri, 23 Aug 2019 10:18:47 +0800
 Subject: [PATCH] musl-libs
@@ -82,7 +82,7 @@ index ecb4d01..edc85e3 100644
  #include <stdint.h>
  
 diff --git a/libdwfl/linux-kernel-modules.c b/libdwfl/linux-kernel-modules.c
-index 6edb27f..f331e3c 100644
+index c0f8dfa..aa78033 100644
 --- a/libdwfl/linux-kernel-modules.c
 +++ b/libdwfl/linux-kernel-modules.c
 @@ -50,6 +50,7 @@
diff --git a/meta/recipes-devtools/elfutils/files/0003-musl-utils.patch b/meta/recipes-devtools/elfutils/files/0003-musl-utils.patch
index 65593be32f..2e379cdba6 100644
--- a/meta/recipes-devtools/elfutils/files/0003-musl-utils.patch
+++ b/meta/recipes-devtools/elfutils/files/0003-musl-utils.patch
@@ -1,4 +1,4 @@
-From 2dab1a02a3cfd80629f3e0f380805a5e58dd0ac3 Mon Sep 17 00:00:00 2001
+From 2f94d488bf3daaa6a8548ee77120fc2506a9bbe3 Mon Sep 17 00:00:00 2001
 From: Hongxu Jia <hongxu.jia@windriver.com>
 Date: Fri, 23 Aug 2019 10:19:48 +0800
 Subject: [PATCH] musl-utils
@@ -39,7 +39,7 @@ index e117166..8326f6c 100644
  /* State of -D/-U flags.  */
  extern bool arlib_deterministic_output;
 diff --git a/src/elfcompress.c b/src/elfcompress.c
-index 1b5b1e3..21c9024 100644
+index 2c6d91b..608646e 100644
 --- a/src/elfcompress.c
 +++ b/src/elfcompress.c
 @@ -37,6 +37,13 @@
@@ -57,7 +57,7 @@ index 1b5b1e3..21c9024 100644
  ARGP_PROGRAM_VERSION_HOOK_DEF = print_version;
  
 diff --git a/src/strip.c b/src/strip.c
-index 7a5d4e4..81a0d57 100644
+index 70fc8c0..d035d9e 100644
 --- a/src/strip.c
 +++ b/src/strip.c
 @@ -46,6 +46,13 @@
@@ -75,7 +75,7 @@ index 7a5d4e4..81a0d57 100644
  
  /* Name and version of program.  */
 diff --git a/src/unstrip.c b/src/unstrip.c
-index 8580329..d547487 100644
+index e488e81..0e44456 100644
 --- a/src/unstrip.c
 +++ b/src/unstrip.c
 @@ -52,6 +52,15 @@
diff --git a/meta/recipes-devtools/elfutils/files/0004-Fix-error-on-musl.patch b/meta/recipes-devtools/elfutils/files/0004-Fix-error-on-musl.patch
index 8e1e97041f..2fa60c333c 100644
--- a/meta/recipes-devtools/elfutils/files/0004-Fix-error-on-musl.patch
+++ b/meta/recipes-devtools/elfutils/files/0004-Fix-error-on-musl.patch
@@ -1,4 +1,4 @@
-From ce3b1403bd88261b5461a9dcb7d6d6be9185703e Mon Sep 17 00:00:00 2001
+From 72819106d0e5666d172d39c24c19e4e7a3b8be0e Mon Sep 17 00:00:00 2001
 From: Richard Purdie <richard.purdie@linuxfoundation.org>
 Date: Wed, 1 May 2019 22:15:03 +0100
 Subject: [PATCH] Fix error on musl:
@@ -19,7 +19,7 @@ Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
  1 file changed, 5 insertions(+)
 
 diff --git a/tests/elfstrmerge.c b/tests/elfstrmerge.c
-index abbdf3f..bd90f4d 100644
+index 197c6a5..3683672 100644
 --- a/tests/elfstrmerge.c
 +++ b/tests/elfstrmerge.c
 @@ -33,6 +33,11 @@
diff --git a/meta/recipes-devtools/elfutils/files/0015-config-eu.am-do-not-use-Werror.patch b/meta/recipes-devtools/elfutils/files/0015-config-eu.am-do-not-use-Werror.patch
index 205362626d..5cd6fffc27 100644
--- a/meta/recipes-devtools/elfutils/files/0015-config-eu.am-do-not-use-Werror.patch
+++ b/meta/recipes-devtools/elfutils/files/0015-config-eu.am-do-not-use-Werror.patch
@@ -1,4 +1,4 @@
-From dfe11e043cd8ea0b0f0252bcff9f5a6b98c0ecd3 Mon Sep 17 00:00:00 2001
+From cfced441d4a6f2eca51d29c52240275bd6f54e49 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Mon, 22 Jun 2020 21:35:16 +0000
 Subject: [PATCH] config/eu.am: do not use -Werror
@@ -16,22 +16,22 @@ Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
  1 file changed, 2 deletions(-)
 
 diff --git a/config/eu.am b/config/eu.am
-index 6c3c444..3bc0dc9 100644
+index 2c3e457..8fb0411 100644
 --- a/config/eu.am
 +++ b/config/eu.am
-@@ -73,7 +73,6 @@ AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
- 	    -Wold-style-definition -Wstrict-prototypes -Wtrampolines \
+@@ -89,7 +89,6 @@ AM_CFLAGS = -std=gnu99 -Wall -Wshadow -Wformat=2 \
+ 	    -Wold-style-definition -Wstrict-prototypes $(TRAMPOLINES_WARNING) \
  	    $(LOGICAL_OP_WARNING) $(DUPLICATED_COND_WARNING) \
  	    $(NULL_DEREFERENCE_WARNING) $(IMPLICIT_FALLTHROUGH_WARNING) \
 -	    $(if $($(*F)_no_Werror),,-Werror) \
  	    $(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
  	    $(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
- 	    $(if $($(*F)_no_Wpacked_not_aligned),-Wno-packed-not-aligned,) \
-@@ -83,7 +82,6 @@ AM_CXXFLAGS = -std=c++11 -Wall -Wshadow \
- 	   -Wtrampolines \
+ 	    $(if $($(*F)_no_Wpacked_not_aligned),$(NO_PACKED_NOT_ALIGNED_WARNING),) \
+@@ -99,7 +98,6 @@ AM_CXXFLAGS = -std=c++11 -Wall -Wshadow \
+ 	   $(TRAMPOLINES_WARNING) \
  	   $(LOGICAL_OP_WARNING) $(DUPLICATED_COND_WARNING) \
  	   $(NULL_DEREFERENCE_WARNING) $(IMPLICIT_FALLTHROUGH_WARNING) \
 -	   $(if $($(*F)_no_Werror),,-Werror) \
  	   $(if $($(*F)_no_Wunused),,-Wunused -Wextra) \
  	   $(if $($(*F)_no_Wstack_usage),,$(STACK_USAGE_WARNING)) \
- 	   $(if $($(*F)_no_Wpacked_not_aligned),-Wno-packed-not-aligned,) \
+ 	   $(if $($(*F)_no_Wpacked_not_aligned),$(NO_PACKED_NOT_ALIGNED_WARNING),) \
-- 
2.31.1

[PATCH 03/10] libcap: update 2.49 -> 2.50

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 ...-tests-do-not-statically-link-a-test.patch | 20 +++++++++----------
 .../libcap/{libcap_2.49.bb => libcap_2.50.bb} |  2 +-
 2 files changed, 10 insertions(+), 12 deletions(-)
 rename meta/recipes-support/libcap/{libcap_2.49.bb => libcap_2.50.bb} (95%)

diff --git a/meta/recipes-support/libcap/files/0001-tests-do-not-statically-link-a-test.patch b/meta/recipes-support/libcap/files/0001-tests-do-not-statically-link-a-test.patch
index d2653afb75..414e45a6f4 100644
--- a/meta/recipes-support/libcap/files/0001-tests-do-not-statically-link-a-test.patch
+++ b/meta/recipes-support/libcap/files/0001-tests-do-not-statically-link-a-test.patch
@@ -1,4 +1,4 @@
-From 6aa15fe548e5b1d6ca3b373779beb7521ea95ba9 Mon Sep 17 00:00:00 2001
+From 897900f3f9084c5542097851323bba3f2691df20 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin <alex.kanavin@gmail.com>
 Date: Wed, 15 Jan 2020 17:16:28 +0100
 Subject: [PATCH] tests: do not statically link a test
@@ -7,26 +7,27 @@ This fails on e.g. centos 7
 
 Upstream-Status: Inappropriate [oe-core specific]
 Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+
 ---
  progs/Makefile | 2 +-
  tests/Makefile | 4 ++--
  2 files changed, 3 insertions(+), 3 deletions(-)
 
 diff --git a/progs/Makefile b/progs/Makefile
-index 1d7fc7a..37db8f7 100644
+index 289186e..071a285 100644
 --- a/progs/Makefile
 +++ b/progs/Makefile
-@@ -42,7 +42,7 @@ endif
- test: $(PROGS)
+@@ -49,7 +49,7 @@ capsh: capsh.c capshdoc.h.cf $(DEPS)
+ 	$(CC) $(IPATH) $(CAPSH_SHELL) $(CFLAGS) -o $@ $< $(LIBCAPLIB) $(LDFLAGS)
  
- tcapsh-static: capsh.c $(DEPS)
+ tcapsh-static: capsh.c capshdoc.h.cf $(DEPS)
 -	$(CC) $(IPATH) $(CAPSH_SHELL) $(CFLAGS) -o $@ $< $(LIBCAPLIB) $(LDFLAGS) --static
 +	$(CC) $(IPATH) $(CAPSH_SHELL) $(CFLAGS) -o $@ $< $(LIBCAPLIB) $(LDFLAGS)
  
  sudotest: test tcapsh-static
  	sudo $(LDPATH) ./quicktest.sh
 diff --git a/tests/Makefile b/tests/Makefile
-index 01f7589..094ec57 100644
+index 4a5f2f9..4266d86 100644
 --- a/tests/Makefile
 +++ b/tests/Makefile
 @@ -22,7 +22,7 @@ ifeq ($(PTHREADS),yes)
@@ -38,7 +39,7 @@ index 01f7589..094ec57 100644
  DEPS=../libcap/libcap.a
  ifeq ($(PTHREADS),yes)
  DEPS +=  ../libcap/libpsx.a
-@@ -106,7 +106,7 @@ noexploit: exploit.o $(DEPS)
+@@ -113,7 +113,7 @@ noexploit: exploit.o $(DEPS)
  
  # This one runs in a chroot with no shared library files.
  noop: noop.c
@@ -46,7 +47,4 @@ index 01f7589..094ec57 100644
 +	$(CC) $(CFLAGS) $< -o $@
  
  clean:
- 	rm -f psx_test libcap_psx_test libcap_launch_test *~
--- 
-2.17.1
-
+ 	rm -f psx_test libcap_psx_test libcap_launch_test uns_test *~
diff --git a/meta/recipes-support/libcap/libcap_2.49.bb b/meta/recipes-support/libcap/libcap_2.50.bb
similarity index 95%
rename from meta/recipes-support/libcap/libcap_2.49.bb
rename to meta/recipes-support/libcap/libcap_2.50.bb
index eb9fc5b4b3..15137f0ac0 100644
--- a/meta/recipes-support/libcap/libcap_2.49.bb
+++ b/meta/recipes-support/libcap/libcap_2.50.bb
@@ -14,7 +14,7 @@ SRC_URI = "${KERNELORG_MIRROR}/linux/libs/security/linux-privs/${BPN}2/${BPN}-${
            file://0002-tests-do-not-run-target-executables.patch \
            file://0001-tests-do-not-statically-link-a-test.patch \
            "
-SRC_URI[sha256sum] = "e98bc4d93645082ec787730b0fd1a712b38882465c505777de17c338831ee181"
+SRC_URI[sha256sum] = "47a57b8bd238b84c93c921a9b4ff82337551dbcb0cca071316aadf3e23b19261"
 
 UPSTREAM_CHECK_URI = "https://www.kernel.org/pub/linux/libs/security/linux-privs/${BPN}2/"
 
-- 
2.31.1

[PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 .../cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb}    | 0
 meta/recipes-devtools/cmake/cmake.inc                           | 2 +-
 .../recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} | 0
 3 files changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb} (100%)
 rename meta/recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} (100%)

diff --git a/meta/recipes-devtools/cmake/cmake-native_3.20.2.bb b/meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake-native_3.20.2.bb
rename to meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
index be43760628..0987c01c87 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -21,7 +21,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
            file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
 "
 
-SRC_URI[sha256sum] = "aecf6ecb975179eb3bb6a4a50cae192d41e92b9372b02300f9e8f1d5f559544e"
+SRC_URI[sha256sum] = "4d008ac3461e271fcfac26a05936f77fc7ab64402156fb371d41284851a651b8"
 
 UPSTREAM_CHECK_REGEX = "cmake-(?P<pver>\d+(\.\d+)+)\.tar"
 
diff --git a/meta/recipes-devtools/cmake/cmake_3.20.2.bb b/meta/recipes-devtools/cmake/cmake_3.20.3.bb
similarity index 100%
rename from meta/recipes-devtools/cmake/cmake_3.20.2.bb
rename to meta/recipes-devtools/cmake/cmake_3.20.3.bb
-- 
2.31.1

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Fri, 2021-06-04 at 11:14 +0200, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> ---
>  .../cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb}    | 0
>  meta/recipes-devtools/cmake/cmake.inc                           | 2 +-
>  .../recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} | 0
>  3 files changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-devtools/cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb} (100%)
>  rename meta/recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} (100%)
> 
> diff --git a/meta/recipes-devtools/cmake/cmake-native_3.20.2.bb b/meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> similarity index 100%
> rename from meta/recipes-devtools/cmake/cmake-native_3.20.2.bb
> rename to meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
> index be43760628..0987c01c87 100644
> --- a/meta/recipes-devtools/cmake/cmake.inc
> +++ b/meta/recipes-devtools/cmake/cmake.inc
> @@ -21,7 +21,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
>             file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
>  "
>  
> 
> 
> 
> -SRC_URI[sha256sum] = "aecf6ecb975179eb3bb6a4a50cae192d41e92b9372b02300f9e8f1d5f559544e"
> +SRC_URI[sha256sum] = "4d008ac3461e271fcfac26a05936f77fc7ab64402156fb371d41284851a651b8"
>  
> 
> 
> 
>  UPSTREAM_CHECK_REGEX = "cmake-(?P<pver>\d+(\.\d+)+)\.tar"
>  
> 
> 
> 
> diff --git a/meta/recipes-devtools/cmake/cmake_3.20.2.bb b/meta/recipes-devtools/cmake/cmake_3.20.3.bb
> similarity index 100%
> rename from meta/recipes-devtools/cmake/cmake_3.20.2.bb
> rename to meta/recipes-devtools/cmake/cmake_3.20.3.bb

Seems there is some intermittent issue that the cmake upgrade brings in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/3509/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3513/steps/12/logs/stdio

yet the latter passed in:

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3514

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Sat, 2021-06-05 at 15:35 +0100, Richard Purdie via lists.openembedded.org wrote:
> On Fri, 2021-06-04 at 11:14 +0200, Alexander Kanavin wrote:
> > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > ---
> >  .../cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb}    | 0
> >  meta/recipes-devtools/cmake/cmake.inc                           | 2 +-
> >  .../recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} | 0
> >  3 files changed, 1 insertion(+), 1 deletion(-)
> >  rename meta/recipes-devtools/cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb} (100%)
> >  rename meta/recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} (100%)
> > 
> > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.20.2.bb b/meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/cmake/cmake-native_3.20.2.bb
> > rename to meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> > diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
> > index be43760628..0987c01c87 100644
> > --- a/meta/recipes-devtools/cmake/cmake.inc
> > +++ b/meta/recipes-devtools/cmake/cmake.inc
> > @@ -21,7 +21,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
> >             file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
> >  "
> >  
> > 
> > 
> > 
> > -SRC_URI[sha256sum] = "aecf6ecb975179eb3bb6a4a50cae192d41e92b9372b02300f9e8f1d5f559544e"
> > +SRC_URI[sha256sum] = "4d008ac3461e271fcfac26a05936f77fc7ab64402156fb371d41284851a651b8"
> >  
> > 
> > 
> > 
> >  UPSTREAM_CHECK_REGEX = "cmake-(?P<pver>\d+(\.\d+)+)\.tar"
> >  
> > 
> > 
> > 
> > diff --git a/meta/recipes-devtools/cmake/cmake_3.20.2.bb b/meta/recipes-devtools/cmake/cmake_3.20.3.bb
> > similarity index 100%
> > rename from meta/recipes-devtools/cmake/cmake_3.20.2.bb
> > rename to meta/recipes-devtools/cmake/cmake_3.20.3.bb
> 
> Seems there is some intermittent issue that the cmake upgrade brings in:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/3509/steps/13/logs/stdio
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3513/steps/12/logs/stdio
> 
> yet the latter passed in:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3514

Re-ran it on centos8 and it failed:

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3515

so this looks to be centos8 specific.

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Khem Raj]

On 6/5/21 8:13 AM, Richard Purdie wrote:
> On Sat, 2021-06-05 at 15:35 +0100, Richard Purdie via lists.openembedded.org wrote:
>> On Fri, 2021-06-04 at 11:14 +0200, Alexander Kanavin wrote:
>>> Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
>>> ---
>>>   .../cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb}    | 0
>>>   meta/recipes-devtools/cmake/cmake.inc                           | 2 +-
>>>   .../recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} | 0
>>>   3 files changed, 1 insertion(+), 1 deletion(-)
>>>   rename meta/recipes-devtools/cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb} (100%)
>>>   rename meta/recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} (100%)
>>>
>>> diff --git a/meta/recipes-devtools/cmake/cmake-native_3.20.2.bb b/meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
>>> similarity index 100%
>>> rename from meta/recipes-devtools/cmake/cmake-native_3.20.2.bb
>>> rename to meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
>>> diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
>>> index be43760628..0987c01c87 100644
>>> --- a/meta/recipes-devtools/cmake/cmake.inc
>>> +++ b/meta/recipes-devtools/cmake/cmake.inc
>>> @@ -21,7 +21,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
>>>              file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
>>>   "
>>>   
>>>
>>>
>>>
>>> -SRC_URI[sha256sum] = "aecf6ecb975179eb3bb6a4a50cae192d41e92b9372b02300f9e8f1d5f559544e"
>>> +SRC_URI[sha256sum] = "4d008ac3461e271fcfac26a05936f77fc7ab64402156fb371d41284851a651b8"
>>>   
>>>
>>>
>>>
>>>   UPSTREAM_CHECK_REGEX = "cmake-(?P<pver>\d+(\.\d+)+)\.tar"
>>>   
>>>
>>>
>>>
>>> diff --git a/meta/recipes-devtools/cmake/cmake_3.20.2.bb b/meta/recipes-devtools/cmake/cmake_3.20.3.bb
>>> similarity index 100%
>>> rename from meta/recipes-devtools/cmake/cmake_3.20.2.bb
>>> rename to meta/recipes-devtools/cmake/cmake_3.20.3.bb
>>
>> Seems there is some intermittent issue that the cmake upgrade brings in:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/3509/steps/13/logs/stdio
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3513/steps/12/logs/stdio
>>
>> yet the latter passed in:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3514
> 
> Re-ran it on centos8 and it failed:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3515
> 
> so this looks to be centos8 specific.
> 

CMake Error at cmake_install.cmake:46 (file):
   file INSTALL cannot set modification time on
 
"/home/pokybuild/yocto-worker/genericx86/build/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/assimppcyyuhv8/install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake":
   Invalid argument.
make: *** [Makefile:74: install] Error 1
No python package in the SDK

I wonder if its some parallel install race. Can we try disabling 
parallelism during install for the assimp build during test and see if 
that helps.

> Cheers,
> 
> Richard
> 
> 
> 
> 
> 

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Sat, 2021-06-05 at 08:32 -0700, Khem Raj wrote:
> 
> On 6/5/21 8:13 AM, Richard Purdie wrote:
> > On Sat, 2021-06-05 at 15:35 +0100, Richard Purdie via lists.openembedded.org wrote:
> > > On Fri, 2021-06-04 at 11:14 +0200, Alexander Kanavin wrote:
> > > > Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
> > > > ---
> > > >   .../cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb}    | 0
> > > >   meta/recipes-devtools/cmake/cmake.inc                           | 2 +-
> > > >   .../recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} | 0
> > > >   3 files changed, 1 insertion(+), 1 deletion(-)
> > > >   rename meta/recipes-devtools/cmake/{cmake-native_3.20.2.bb => cmake-native_3.20.3.bb} (100%)
> > > >   rename meta/recipes-devtools/cmake/{cmake_3.20.2.bb => cmake_3.20.3.bb} (100%)
> > > > 
> > > > diff --git a/meta/recipes-devtools/cmake/cmake-native_3.20.2.bb b/meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/cmake/cmake-native_3.20.2.bb
> > > > rename to meta/recipes-devtools/cmake/cmake-native_3.20.3.bb
> > > > diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
> > > > index be43760628..0987c01c87 100644
> > > > --- a/meta/recipes-devtools/cmake/cmake.inc
> > > > +++ b/meta/recipes-devtools/cmake/cmake.inc
> > > > @@ -21,7 +21,7 @@ SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
> > > >              file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
> > > >   "
> > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > -SRC_URI[sha256sum] = "aecf6ecb975179eb3bb6a4a50cae192d41e92b9372b02300f9e8f1d5f559544e"
> > > > +SRC_URI[sha256sum] = "4d008ac3461e271fcfac26a05936f77fc7ab64402156fb371d41284851a651b8"
> > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > >   UPSTREAM_CHECK_REGEX = "cmake-(?P<pver>\d+(\.\d+)+)\.tar"
> > > >   
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > 
> > > > diff --git a/meta/recipes-devtools/cmake/cmake_3.20.2.bb b/meta/recipes-devtools/cmake/cmake_3.20.3.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/cmake/cmake_3.20.2.bb
> > > > rename to meta/recipes-devtools/cmake/cmake_3.20.3.bb
> > > 
> > > Seems there is some intermittent issue that the cmake upgrade brings in:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/60/builds/3509/steps/13/logs/stdio
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3513/steps/12/logs/stdio
> > > 
> > > yet the latter passed in:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3514
> > 
> > Re-ran it on centos8 and it failed:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3515
> > 
> > so this looks to be centos8 specific.
> > 
> 
> CMake Error at cmake_install.cmake:46 (file):
>    file INSTALL cannot set modification time on
>  
> 
> 
> 
> 
> 
> 
> 
> "/home/pokybuild/yocto-worker/genericx86/build/build/tmp/work/genericx86-poky-linux/core-image-sato/1.0-r0/testimage-sdk/assimppcyyuhv8/install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake":
>    Invalid argument.
> make: *** [Makefile:74: install] Error 1
> No python package in the SDK
> 
> I wonder if its some parallel install race. Can we try disabling 
> parallelism during install for the assimp build during test and see if 
> that helps.

I've just realised this is also happening with master in a-quick:

https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1441

all centos8 failures.

Michael: Did something change on those machines during maint on Friday
that could be triggering ths?

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 554 bytes --]

On Sat, 5 Jun 2021 at 18:09, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

>
> I've just realised this is also happening with master in a-quick:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1441
>
> all centos8 failures.
>
> Michael: Did something change on those machines during maint on Friday
> that could be triggering ths?
>

I manually ran sato testsdk on the centos8 worker just now, and it passed
without errors.

Was there maybe a period where system time on the host was wrong?

Alex

[-- Attachment #2: Type: text/html, Size: 1052 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Sat, 2021-06-05 at 21:27 +0200, Alexander Kanavin wrote:
> On Sat, 5 Jun 2021 at 18:09, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > 
> > I've just realised this is also happening with master in a-quick:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/85/builds/1441
> > 
> > all centos8 failures.
> > 
> > Michael: Did something change on those machines during maint on Friday
> > that could be triggering ths?
> > 
> 
> 
> I manually ran sato testsdk on the centos8 worker just now, and it passed without errors.
> 
> Was there maybe a period where system time on the host was wrong?

I tried again with the autobuilder, still fails:

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516

so whatever it is, it is still "live".

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2038 bytes --]

On Sun, 6 Jun 2021 at 01:10, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> I tried again with the autobuilder, still fails:
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
>
> so whatever it is, it is still "live".
>

I did some digging. The issue happens when:
- host is centos8
- SDKMACHINE is i686 (e.g. cmake is 32 bit)

Then there's a failing syscall attempting to set file times:
utimensat_time64(AT_FDCWD,
"../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579,
tv_nsec=17840053692309438464}], 0) = -1 EINVAL (Invalid argument)

On latest Fedora, there's no issue:
utimensat_time64(AT_FDCWD,
"../install2/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1623002886, tv_nsec=6369724778172907520}, {tv_sec=1623002886,
tv_nsec=17839174083007217664}], 0) = 0

utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should be
returning ENOSYS in that case probably?

i686 SDK is using its own libc, and from what I can tell that libc is
trying to be Y2038 compatible, e.g. calling the 64 bit version first, and
if that returns ENOSYS, it falls through to the 32 bit version. But because
centos kernel returns EINVAL, the 32 bit version is never attempted:
https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/utimensat.c;h=909a29762b504091a4e32487d8bc4cc68d34c508;hb=HEAD

I also tried this in Ubuntu 18.04 (kernel 4.15), the fall-through works
correctly:
syscall_0x19c(0xffffff9c, 0x579e4260, 0xffe46590, 0, 0xf7aace3c,
0xffe46768) = -1 (errno 38)
utimensat(AT_FDCWD,
"../install2/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1623008744, tv_nsec=0} /* 2021-06-06T19:45:44+0000 */,
{tv_sec=1623008629, tv_nsec=0} /* 2021-06-06T19:43:49+0000 */], 0) = 0

The bottom line, this looks like a botched kernel update in Centos8 -
possibly a backport of time64 calls that doesn't work with non-centos libc?

Alex

[-- Attachment #2: Type: text/html, Size: 2864 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Khem Raj]

On Sun, Jun 6, 2021 at 12:51 PM Alexander Kanavin
<alex.kanavin@gmail.com> wrote:
>
> On Sun, 6 Jun 2021 at 01:10, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
>>
>> I tried again with the autobuilder, still fails:
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
>>
>> so whatever it is, it is still "live".
>
>
> I did some digging. The issue happens when:
> - host is centos8
> - SDKMACHINE is i686 (e.g. cmake is 32 bit)
>
> Then there's a failing syscall attempting to set file times:
> utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1 EINVAL (Invalid argument)
>
> On latest Fedora, there's no issue:
> utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=1623002886, tv_nsec=6369724778172907520}, {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
>
> utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should be returning ENOSYS in that case probably?
>
> i686 SDK is using its own libc, and from what I can tell that libc is trying to be Y2038 compatible, e.g. calling the 64 bit version first, and if that returns ENOSYS, it falls through to the 32 bit version. But because centos kernel returns EINVAL, the 32 bit version is never attempted:
> https://sourceware.org/git/?p=glibc.git;a=blob;f=sysdeps/unix/sysv/linux/utimensat.c;h=909a29762b504091a4e32487d8bc4cc68d34c508;hb=HEAD
>
> I also tried this in Ubuntu 18.04 (kernel 4.15), the fall-through works correctly:
> syscall_0x19c(0xffffff9c, 0x579e4260, 0xffe46590, 0, 0xf7aace3c, 0xffe46768) = -1 (errno 38)
> utimensat(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=1623008744, tv_nsec=0} /* 2021-06-06T19:45:44+0000 */, {tv_sec=1623008629, tv_nsec=0} /* 2021-06-06T19:43:49+0000 */], 0) = 0
>
> The bottom line, this looks like a botched kernel update in Centos8 - possibly a backport of time64 calls that doesn't work with non-centos libc?
>

Good sleuthing.  Can you find out if libseccomp is in play ? if so
what version of libseccomp is being used by cmake if it is libseccomp
< 2.4.2 then time64 syscall support won't be there unless
its backported to the older version.

> Alex

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 508 bytes --]

On Sun, 6 Jun 2021 at 23:51, Khem Raj <raj.khem@gmail.com> wrote:

>
> Good sleuthing.  Can you find out if libseccomp is in play ? if so
> what version of libseccomp is being used by cmake if it is libseccomp
> < 2.4.2 then time64 syscall support won't be there unless
> its backported to the older version.
>

From what i could tell cmake does not use libseccomp, but centos8 could
have some kind of syscall filtering in place. It would be good to try with
a few older centos8 kernels.

Alex

[-- Attachment #2: Type: text/html, Size: 846 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Khem Raj]

On Sun, Jun 6, 2021 at 3:06 PM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>
> On Sun, 6 Jun 2021 at 23:51, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>> Good sleuthing.  Can you find out if libseccomp is in play ? if so
>> what version of libseccomp is being used by cmake if it is libseccomp
>> < 2.4.2 then time64 syscall support won't be there unless
>> its backported to the older version.
>
>
> From what i could tell cmake does not use libseccomp, but centos8 could have some kind of syscall filtering in place. It would be good to try with a few older centos8 kernels.
>

here is a small testcase to excercise utimensat_time64
https://raw.githubusercontent.com/xantares/test-seccomp-time64/master/test-time64.c

gcc -m32 test-time64.c

it will be good to check how the resulting binary behaves with centos
provided libc and sdk provided one.
> Alex

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 731 bytes --]

On Mon, 7 Jun 2021 at 00:19, Khem Raj <raj.khem@gmail.com> wrote:

> here is a small testcase to excercise utimensat_time64
>
> https://raw.githubusercontent.com/xantares/test-seccomp-time64/master/test-time64.c
>
> gcc -m32 test-time64.c
>
> it will be good to check how the resulting binary behaves with centos
> provided libc and sdk provided one.
>

Yes, testing the issue without involving the sdk would be good, but I can't
build it in the host environment, and don't have rights to install missing
32 bit support packages (not sure what that would be):

/usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or
directory
 # include <gnu/stubs-32.h>
           ^~~~~~~~~~~~~~~~

Alex

[-- Attachment #2: Type: text/html, Size: 1237 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Khem Raj]

[-- Attachment #1: Type: text/plain, Size: 920 bytes --]

On Mon, Jun 7, 2021 at 3:20 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Mon, 7 Jun 2021 at 00:19, Khem Raj <raj.khem@gmail.com> wrote:
>
>> here is a small testcase to excercise utimensat_time64
>>
>> https://raw.githubusercontent.com/xantares/test-seccomp-time64/master/test-time64.c
>>
>> gcc -m32 test-time64.c
>>
>> it will be good to check how the resulting binary behaves with centos
>> provided libc and sdk provided one.
>>
>
> Yes, testing the issue without involving the sdk would be good, but I
> can't build it in the host environment, and don't have rights to install
> missing 32 bit support packages (not sure what that would be):
>
> /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file
> or directory
>  # include <gnu/stubs-32.h>
>

Yeah it needs 32bit development libc and compiler installed


>            ^~~~~~~~~~~~~~~~
>
> Alex
>

[-- Attachment #2: Type: text/html, Size: 1929 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 1298 bytes --]

On Mon, Jun 7, 2021 at 8:10 AM Khem Raj <raj.khem@gmail.com> wrote:

>
>
> On Mon, Jun 7, 2021 at 3:20 AM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> On Mon, 7 Jun 2021 at 00:19, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> here is a small testcase to excercise utimensat_time64
>>>
>>> https://raw.githubusercontent.com/xantares/test-seccomp-time64/master/test-time64.c
>>>
>>> gcc -m32 test-time64.c
>>>
>>> it will be good to check how the resulting binary behaves with centos
>>> provided libc and sdk provided one.
>>>
>>
>> Yes, testing the issue without involving the sdk would be good, but I
>> can't build it in the host environment, and don't have rights to install
>> missing 32 bit support packages (not sure what that would be):
>>
>> /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file
>> or directory
>>  # include <gnu/stubs-32.h>
>>
>
> Yeah it needs 32bit development libc and compiler installed
>


I added the needed packages to the CentOS workers. The compiled binary
prints "rc=0" on the three CentOS workers.

Is reverting to an older kernel in order yet?


>
>
>>            ^~~~~~~~~~~~~~~~
>>
>> Alex
>>
>

-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 2983 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Khem Raj]

On Mon, Jun 7, 2021 at 9:41 AM Michael Halstead
<mhalstead@linuxfoundation.org> wrote:
>
>
>
> On Mon, Jun 7, 2021 at 8:10 AM Khem Raj <raj.khem@gmail.com> wrote:
>>
>>
>>
>> On Mon, Jun 7, 2021 at 3:20 AM Alexander Kanavin <alex.kanavin@gmail.com> wrote:
>>>
>>> On Mon, 7 Jun 2021 at 00:19, Khem Raj <raj.khem@gmail.com> wrote:
>>>>
>>>> here is a small testcase to excercise utimensat_time64
>>>> https://raw.githubusercontent.com/xantares/test-seccomp-time64/master/test-time64.c
>>>>
>>>> gcc -m32 test-time64.c
>>>>
>>>> it will be good to check how the resulting binary behaves with centos
>>>> provided libc and sdk provided one.
>>>
>>>
>>> Yes, testing the issue without involving the sdk would be good, but I can't build it in the host environment, and don't have rights to install missing 32 bit support packages (not sure what that would be):
>>>
>>> /usr/include/gnu/stubs.h:7:11: fatal error: gnu/stubs-32.h: No such file or directory
>>>  # include <gnu/stubs-32.h>
>>
>>
>> Yeah it needs 32bit development libc and compiler installed
>
>
>
> I added the needed packages to the CentOS workers. The compiled binary prints "rc=0" on the three CentOS workers.

can we now try linking and running it against SDK built nativesdk-glibc ?

>
> Is reverting to an older kernel in order yet?
>
>>
>>
>>>
>>>            ^~~~~~~~~~~~~~~~
>>>
>>> Alex
>
>
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1007 bytes --]

On Mon, 7 Jun 2021 at 19:18, Khem Raj <raj.khem@gmail.com> wrote:

> > I added the needed packages to the CentOS workers. The compiled binary
> prints "rc=0" on the three CentOS workers.
>
> can we now try linking and running it against SDK built nativesdk-glibc ?
>

Using the host libc won't show the issue, as it is old (2.28), isn't using
utimensat_time64 and goes straight to utimensat.

With nativesdk-glibc, it still succeeds:
utimensat_time64(3, NULL, [{tv_sec=1, tv_nsec=2} /*
1970-01-01T00:00:01.000000002+0000 */, {tv_sec=3, tv_nsec=4} /*
1970-01-01T00:00:03.000000004+0000 */], 0) = 0

So we'd need to look into why the kernel accepts this, but rejects the call
from cmake. Any easy way to trace this? Just to repeat the failing one:

utimensat_time64(AT_FDCWD,
"../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579,
tv_nsec=17840053692309438464}], 0) = -1 EINVAL (Invalid argument)

Alex

[-- Attachment #2: Type: text/html, Size: 1431 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 1470 bytes --]

I've rebooted centos8-ty-1 using the previous 4.18.0-240.15.1.el8_3.x86_64
kernel and kept it in the pool. I've paused centos8-ty-2 so it won't
interfere with builds and left it at the current 4.18.0-305.3.1.el8.x86_64
kernel for testing.

On Mon, Jun 7, 2021 at 11:04 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Mon, 7 Jun 2021 at 19:18, Khem Raj <raj.khem@gmail.com> wrote:
>
>> > I added the needed packages to the CentOS workers. The compiled binary
>> prints "rc=0" on the three CentOS workers.
>>
>> can we now try linking and running it against SDK built nativesdk-glibc ?
>>
>
> Using the host libc won't show the issue, as it is old (2.28), isn't using
> utimensat_time64 and goes straight to utimensat.
>
> With nativesdk-glibc, it still succeeds:
> utimensat_time64(3, NULL, [{tv_sec=1, tv_nsec=2} /*
> 1970-01-01T00:00:01.000000002+0000 */, {tv_sec=3, tv_nsec=4} /*
> 1970-01-01T00:00:03.000000004+0000 */], 0) = 0
>
> So we'd need to look into why the kernel accepts this, but rejects the
> call from cmake. Any easy way to trace this? Just to repeat the failing one:
>
> utimensat_time64(AT_FDCWD,
> "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
> [{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579,
> tv_nsec=17840053692309438464}], 0) = -1 EINVAL (Invalid argument)
>
> Alex
>


-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 2271 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 2208 bytes --]

I can confirm that the previous kernel behaves correctly:
utimensat_time64(AT_FDCWD,
"../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1623176017, tv_nsec=6290007298941124608}, {tv_sec=1622966579,
tv_nsec=17838646317425885184}], 0) = -1 ENOSYS (Function not implemented)
utimensat(AT_FDCWD,
"../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
[{tv_sec=1623176017, tv_nsec=0} /* 2021-06-08T18:13:37+0000 */,
{tv_sec=1622966579, tv_nsec=0} /* 2021-06-06T08:02:59+0000 */], 0) = 0

Does look like a botched backport of time64 syscalls to me.

Alex

On Tue, 8 Jun 2021 at 17:40, Michael Halstead <mhalstead@linuxfoundation.org>
wrote:

> I've rebooted centos8-ty-1 using the previous 4.18.0-240.15.1.el8_3.x86_64
> kernel and kept it in the pool. I've paused centos8-ty-2 so it won't
> interfere with builds and left it at the current 4.18.0-305.3.1.el8.x86_64
> kernel for testing.
>
> On Mon, Jun 7, 2021 at 11:04 AM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> On Mon, 7 Jun 2021 at 19:18, Khem Raj <raj.khem@gmail.com> wrote:
>>
>>> > I added the needed packages to the CentOS workers. The compiled binary
>>> prints "rc=0" on the three CentOS workers.
>>>
>>> can we now try linking and running it against SDK built nativesdk-glibc ?
>>>
>>
>> Using the host libc won't show the issue, as it is old (2.28), isn't
>> using utimensat_time64 and goes straight to utimensat.
>>
>> With nativesdk-glibc, it still succeeds:
>> utimensat_time64(3, NULL, [{tv_sec=1, tv_nsec=2} /*
>> 1970-01-01T00:00:01.000000002+0000 */, {tv_sec=3, tv_nsec=4} /*
>> 1970-01-01T00:00:03.000000004+0000 */], 0) = 0
>>
>> So we'd need to look into why the kernel accepts this, but rejects the
>> call from cmake. Any easy way to trace this? Just to repeat the failing one:
>>
>> utimensat_time64(AT_FDCWD,
>> "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
>> [{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579,
>> tv_nsec=17840053692309438464}], 0) = -1 EINVAL (Invalid argument)
>>
>> Alex
>>
>
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>

[-- Attachment #2: Type: text/html, Size: 3317 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Tue, 2021-06-08 at 20:15 +0200, Alexander Kanavin wrote:
> I can confirm that the previous kernel behaves correctly:
> utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
> [{tv_sec=1623176017, tv_nsec=6290007298941124608}, {tv_sec=1622966579, tv_nsec=17838646317425885184}], 0) = -1
> ENOSYS (Function not implemented)
> utimensat(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake", [{tv_sec=1623176017,
> tv_nsec=0} /* 2021-06-08T18:13:37+0000 */, {tv_sec=1622966579, tv_nsec=0} /* 2021-06-06T08:02:59+0000 */], 0)
> = 0
> 
> Does look like a botched backport of time64 syscalls to me.
> 
> Alex
> 
> On Tue, 8 Jun 2021 at 17:40, Michael Halstead <mhalstead@linuxfoundation.org> wrote:
> > I've rebooted centos8-ty-1 using the previous 4.18.0-240.15.1.el8_3.x86_64 kernel and kept it in the pool.
> > I've paused centos8-ty-2 so it won't interfere with builds and left it at the current 4.18.0-
> > 305.3.1.el8.x86_64 kernel for testing. 

Thanks Michael and Alex. We can therefore pretty safely say that something was 
broken between the 240 and 305 of the centos8 kernel for the 32 bit syscall
utimensat syscalls.

I did poke around https://github.com/kernelim/linux/tree/centos8 which does
have a kernel diff but it is huge and you have to clone the repo to get it.

git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat -C 40

shows they did add the syscalls in that kernel.

So this does look to be a RedHat issue. Not sure if we want to report it
to them? Can we run the autobuilders on the older kernel for now until
they hopefully fix it?

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1048 bytes --]

On Wed, 9 Jun 2021 at 13:37, Richard Purdie <
richard.purdie@linuxfoundation.org> wrote:

> Thanks Michael and Alex. We can therefore pretty safely say that something
> was
> broken between the 240 and 305 of the centos8 kernel for the 32 bit syscall
> utimensat syscalls.
>
> I did poke around https://github.com/kernelim/linux/tree/centos8 which
> does
> have a kernel diff but it is huge and you have to clone the repo to get it.
>
> git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat -C
> 40
>
> shows they did add the syscalls in that kernel.
>
> So this does look to be a RedHat issue. Not sure if we want to report it
> to them? Can we run the autobuilders on the older kernel for now until
> they hopefully fix it?
>

Centos 8 will be discontinued in just over 6 months  (
https://www.centos.org/centos-linux/)
so I think at least one of the centos 8 workers should be updated to centos
stream 8
(https://www.centos.org/centos-stream/ - includes instructions) and take it
from there.

Alex

[-- Attachment #2: Type: text/html, Size: 1623 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 1581 bytes --]

I've switched centos8-ty-2.yocto.io over to Stream and it's now running
kernel 4.18.0-310.el8.x86_64. I'm not sure how to test if the problem
still exists but I don't see a related entry in the changelog so I expect
it does.

Alex, can you check or send me a bit more info about how to check myself?

On Wed, Jun 9, 2021 at 7:07 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> On Wed, 9 Jun 2021 at 13:37, Richard Purdie <
> richard.purdie@linuxfoundation.org> wrote:
>
>> Thanks Michael and Alex. We can therefore pretty safely say that
>> something was
>> broken between the 240 and 305 of the centos8 kernel for the 32 bit
>> syscall
>> utimensat syscalls.
>>
>> I did poke around https://github.com/kernelim/linux/tree/centos8 which
>> does
>> have a kernel diff but it is huge and you have to clone the repo to get
>> it.
>>
>> git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat -C
>> 40
>>
>> shows they did add the syscalls in that kernel.
>>
>> So this does look to be a RedHat issue. Not sure if we want to report it
>> to them? Can we run the autobuilders on the older kernel for now until
>> they hopefully fix it?
>>
>
> Centos 8 will be discontinued in just over 6 months  (
> https://www.centos.org/centos-linux/)
> so I think at least one of the centos 8 workers should be updated to
> centos stream 8
> (https://www.centos.org/centos-stream/ - includes instructions) and take
> it from there.
>
> Alex
>


-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 2633 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 1963 bytes --]

I think the easiest is to run the genericx86 job on the worker. If the
problem exists, you'll see a failure like this one:

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3523/steps/12/logs/stdio

Alex

On Fri, 11 Jun 2021 at 23:56, Michael Halstead <
mhalstead@linuxfoundation.org> wrote:

> I've switched centos8-ty-2.yocto.io over to Stream and it's now running
> kernel 4.18.0-310.el8.x86_64. I'm not sure how to test if the problem
> still exists but I don't see a related entry in the changelog so I expect
> it does.
>
> Alex, can you check or send me a bit more info about how to check myself?
>
> On Wed, Jun 9, 2021 at 7:07 AM Alexander Kanavin <alex.kanavin@gmail.com>
> wrote:
>
>> On Wed, 9 Jun 2021 at 13:37, Richard Purdie <
>> richard.purdie@linuxfoundation.org> wrote:
>>
>>> Thanks Michael and Alex. We can therefore pretty safely say that
>>> something was
>>> broken between the 240 and 305 of the centos8 kernel for the 32 bit
>>> syscall
>>> utimensat syscalls.
>>>
>>> I did poke around https://github.com/kernelim/linux/tree/centos8 which
>>> does
>>> have a kernel diff but it is huge and you have to clone the repo to get
>>> it.
>>>
>>> git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat
>>> -C 40
>>>
>>> shows they did add the syscalls in that kernel.
>>>
>>> So this does look to be a RedHat issue. Not sure if we want to report it
>>> to them? Can we run the autobuilders on the older kernel for now until
>>> they hopefully fix it?
>>>
>>
>> Centos 8 will be discontinued in just over 6 months  (
>> https://www.centos.org/centos-linux/)
>> so I think at least one of the centos 8 workers should be updated to
>> centos stream 8
>> (https://www.centos.org/centos-stream/ - includes instructions) and take
>> it from there.
>>
>> Alex
>>
>
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>

[-- Attachment #2: Type: text/html, Size: 3538 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 2421 bytes --]

Thanks Alex,
The issue persists with the newest CentOS8 Stream kernel. Time to file a
bug with RedHat I suppose.

https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3535/steps/12/logs/stdio

On Fri, Jun 11, 2021 at 3:18 PM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> I think the easiest is to run the genericx86 job on the worker. If the
> problem exists, you'll see a failure like this one:
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3523/steps/12/logs/stdio
>
> Alex
>
> On Fri, 11 Jun 2021 at 23:56, Michael Halstead <
> mhalstead@linuxfoundation.org> wrote:
>
>> I've switched centos8-ty-2.yocto.io over to Stream and it's now running
>> kernel 4.18.0-310.el8.x86_64. I'm not sure how to test if the problem
>> still exists but I don't see a related entry in the changelog so I expect
>> it does.
>>
>> Alex, can you check or send me a bit more info about how to check myself?
>>
>> On Wed, Jun 9, 2021 at 7:07 AM Alexander Kanavin <alex.kanavin@gmail.com>
>> wrote:
>>
>>> On Wed, 9 Jun 2021 at 13:37, Richard Purdie <
>>> richard.purdie@linuxfoundation.org> wrote:
>>>
>>>> Thanks Michael and Alex. We can therefore pretty safely say that
>>>> something was
>>>> broken between the 240 and 305 of the centos8 kernel for the 32 bit
>>>> syscall
>>>> utimensat syscalls.
>>>>
>>>> I did poke around https://github.com/kernelim/linux/tree/centos8 which
>>>> does
>>>> have a kernel diff but it is huge and you have to clone the repo to get
>>>> it.
>>>>
>>>> git show a3342908613ba72a84f652ca7a56c3e2113bda12 | grep sys_utimensat
>>>> -C 40
>>>>
>>>> shows they did add the syscalls in that kernel.
>>>>
>>>> So this does look to be a RedHat issue. Not sure if we want to report it
>>>> to them? Can we run the autobuilders on the older kernel for now until
>>>> they hopefully fix it?
>>>>
>>>
>>> Centos 8 will be discontinued in just over 6 months  (
>>> https://www.centos.org/centos-linux/)
>>> so I think at least one of the centos 8 workers should be updated to
>>> centos stream 8
>>> (https://www.centos.org/centos-stream/ - includes instructions) and
>>> take it from there.
>>>
>>> Alex
>>>
>>
>>
>> --
>> Michael Halstead
>> Linux Foundation / Yocto Project
>> Systems Operations Engineer
>>
>

-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 4489 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Richard Purdie]

On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
> On Sun, 6 Jun 2021 at 01:10, Richard Purdie <richard.purdie@linuxfoundation.org> wrote:
> > I tried again with the autobuilder, still fails:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
> > 
> > so whatever it is, it is still "live".
> > 
> 
> 
> I did some digging. The issue happens when:
> - host is centos8
> - SDKMACHINE is i686 (e.g. cmake is 32 bit)
> 
> Then there's a failing syscall attempting to set file times:
> utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
> [{tv_sec=1622966723, tv_nsec=6319439026193432576}, {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
> EINVAL (Invalid argument)
> 
> On latest Fedora, there's no issue:
> utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-4.1/assimp-config.cmake",
> [{tv_sec=1623002886, tv_nsec=6369724778172907520}, {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
> 
> utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should be returning ENOSYS in that case
> probably?

I hacked up a quick test bit of code (which makes assumptions 
about 32 bit):

#include <unistd.h>
#include <sys/syscall.h>
#include <sys/types.h>
#include <sys/stat.h>
#include <fcntl.h>
#include <stdio.h>

struct timespec64 {
    long long 		tv_sec;			/* seconds */
    long long		tv_nsec;		/* nanoseconds */
};

int main() {
  int fd = open("foo", O_RDWR | O_CREAT, 0644);
  write(fd, "foo", 3);
  struct timespec64 times[2] = {};
  times[0].tv_sec = 1622966723;
  times[0].tv_nsec = 631943;
  times[1].tv_sec = 1622966579;
  times[1].tv_nsec = 178400;
  int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
  printf("rc=%d\n", rc);
  close(fd);
  return rc;
}

built with "gcc -m32 test-syscall.c -o test" and run with "strace ./test".
This works on all the systems I tried it in. As does:


  times[0].tv_sec = 1;
  times[0].tv_nsec = 2;
  times[1].tv_sec = 3;
  times[1].tv_nsec = 4;

however if you set (and ignore the compiler warning):

  times[0].tv_sec = 1622966723;
  times[0].tv_nsec = 6319439026193432576;
  times[1].tv_sec = 1622966579;
  times[1].tv_nsec = 17840053692309438464;

then you see EINVAL on the centos system but not on my ubuntu one. It will
do that until you reduce the values of tv_nsec right now. So it seems most 
systems accept large tv_nsec values but the Centos one does not.

I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should be 
a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit long.

Michael: Hopefully that gives you something to raise with them?

Cheers,

Richard

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Mittal, Anuj]

Did we find out the reason why this was happening? I have started
getting this error on Centos-8 while building hardknott.

https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045

Thanks,

Anuj

On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
> On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
> > On Sun, 6 Jun 2021 at 01:10, Richard Purdie
> > <richard.purdie@linuxfoundation.org> wrote:
> > > I tried again with the autobuilder, still fails:
> > > 
> > > https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
> > > 
> > > so whatever it is, it is still "live".
> > > 
> > 
> > 
> > I did some digging. The issue happens when:
> > - host is centos8
> > - SDKMACHINE is i686 (e.g. cmake is 32 bit)
> > 
> > Then there's a failing syscall attempting to set file times:
> > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
> > 4.1/assimp-config.cmake",
> > [{tv_sec=1622966723, tv_nsec=6319439026193432576},
> > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
> > EINVAL (Invalid argument)
> > 
> > On latest Fedora, there's no issue:
> > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
> > 4.1/assimp-config.cmake",
> > [{tv_sec=1623002886, tv_nsec=6369724778172907520},
> > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
> > 
> > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
> > be returning ENOSYS in that case
> > probably?
> 
> I hacked up a quick test bit of code (which makes assumptions 
> about 32 bit):
> 
> #include <unistd.h>
> #include <sys/syscall.h>
> #include <sys/types.h>
> #include <sys/stat.h>
> #include <fcntl.h>
> #include <stdio.h>
> 
> struct timespec64 {
>     long long           tv_sec;                 /* seconds */
>     long long           tv_nsec;                /* nanoseconds */
> };
> 
> int main() {
>   int fd = open("foo", O_RDWR | O_CREAT, 0644);
>   write(fd, "foo", 3);
>   struct timespec64 times[2] = {};
>   times[0].tv_sec = 1622966723;
>   times[0].tv_nsec = 631943;
>   times[1].tv_sec = 1622966579;
>   times[1].tv_nsec = 178400;
>   int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
>   printf("rc=%d\n", rc);
>   close(fd);
>   return rc;
> }
> 
> built with "gcc -m32 test-syscall.c -o test" and run with "strace
> ./test".
> This works on all the systems I tried it in. As does:
> 
> 
>   times[0].tv_sec = 1;
>   times[0].tv_nsec = 2;
>   times[1].tv_sec = 3;
>   times[1].tv_nsec = 4;
> 
> however if you set (and ignore the compiler warning):
> 
>   times[0].tv_sec = 1622966723;
>   times[0].tv_nsec = 6319439026193432576;
>   times[1].tv_sec = 1622966579;
>   times[1].tv_nsec = 17840053692309438464;
> 
> then you see EINVAL on the centos system but not on my ubuntu one. It
> will
> do that until you reduce the values of tv_nsec right now. So it seems
> most 
> systems accept large tv_nsec values but the Centos one does not.
> 
> I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
> be 
> a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
> long.
> 
> Michael: Hopefully that gives you something to raise with them?
> 
> Cheers,
> 
> Richard
> 
> 
> 
> 
> 
> 
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#153046):
> https://lists.openembedded.org/g/openembedded-core/message/153046
> Mute This Topic: https://lists.openembedded.org/mt/83304703/3616702
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe:
> https://lists.openembedded.org/g/openembedded-core/unsub [anuj.mittal@intel.com
> ]
> -=-=-=-=-=-=-=-=-=-=-=-
> 

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 4333 bytes --]

This error was fixed upstream
https://bugzilla.redhat.com/show_bug.cgi?id=1975562 kernel 4.18.0-325.x
which has landed in CentOS8 Stream on centos8-ty-2 but not plain CentOS8
where the newest kernel is still at 4.18.0-305.x.

I'll reboot into the older 4.18.0-240.15 kernel again on centos8-ty-1 as a
fix for now.

On Tue, Sep 28, 2021 at 6:12 PM Anuj Mittal <anuj.mittal@intel.com> wrote:

> Did we find out the reason why this was happening? I have started
> getting this error on Centos-8 while building hardknott.
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045
>
> Thanks,
>
> Anuj
>
> On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
> > On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
> > > On Sun, 6 Jun 2021 at 01:10, Richard Purdie
> > > <richard.purdie@linuxfoundation.org> wrote:
> > > > I tried again with the autobuilder, still fails:
> > > >
> > > >
> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
> > > >
> > > > so whatever it is, it is still "live".
> > > >
> > >
> > >
> > > I did some digging. The issue happens when:
> > > - host is centos8
> > > - SDKMACHINE is i686 (e.g. cmake is 32 bit)
> > >
> > > Then there's a failing syscall attempting to set file times:
> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
> > > 4.1/assimp-config.cmake",
> > > [{tv_sec=1622966723, tv_nsec=6319439026193432576},
> > > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
> > > EINVAL (Invalid argument)
> > >
> > > On latest Fedora, there's no issue:
> > > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
> > > 4.1/assimp-config.cmake",
> > > [{tv_sec=1623002886, tv_nsec=6369724778172907520},
> > > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
> > >
> > > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
> > > be returning ENOSYS in that case
> > > probably?
> >
> > I hacked up a quick test bit of code (which makes assumptions
> > about 32 bit):
> >
> > #include <unistd.h>
> > #include <sys/syscall.h>
> > #include <sys/types.h>
> > #include <sys/stat.h>
> > #include <fcntl.h>
> > #include <stdio.h>
> >
> > struct timespec64 {
> >     long long           tv_sec;                 /* seconds */
> >     long long           tv_nsec;                /* nanoseconds */
> > };
> >
> > int main() {
> >   int fd = open("foo", O_RDWR | O_CREAT, 0644);
> >   write(fd, "foo", 3);
> >   struct timespec64 times[2] = {};
> >   times[0].tv_sec = 1622966723;
> >   times[0].tv_nsec = 631943;
> >   times[1].tv_sec = 1622966579;
> >   times[1].tv_nsec = 178400;
> >   int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
> >   printf("rc=%d\n", rc);
> >   close(fd);
> >   return rc;
> > }
> >
> > built with "gcc -m32 test-syscall.c -o test" and run with "strace
> > ./test".
> > This works on all the systems I tried it in. As does:
> >
> >
> >   times[0].tv_sec = 1;
> >   times[0].tv_nsec = 2;
> >   times[1].tv_sec = 3;
> >   times[1].tv_nsec = 4;
> >
> > however if you set (and ignore the compiler warning):
> >
> >   times[0].tv_sec = 1622966723;
> >   times[0].tv_nsec = 6319439026193432576;
> >   times[1].tv_sec = 1622966579;
> >   times[1].tv_nsec = 17840053692309438464;
> >
> > then you see EINVAL on the centos system but not on my ubuntu one. It
> > will
> > do that until you reduce the values of tv_nsec right now. So it seems
> > most
> > systems accept large tv_nsec values but the Centos one does not.
> >
> > I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
> > be
> > a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
> > long.
> >
> > Michael: Hopefully that gives you something to raise with them?
> >
> > Cheers,
> >
> > Richard
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#156435):
> https://lists.openembedded.org/g/openembedded-core/message/156435
> Mute This Topic: https://lists.openembedded.org/mt/83304703/1003190
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
> mhalstead@linuxfoundation.org]
> -=-=-=-=-=-=-=-=-=-=-=-
>
>

-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 6635 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Alexander Kanavin]

[-- Attachment #1: Type: text/plain, Size: 4717 bytes --]

Since the original centos 8 is going away (support-wise) in less than 3
months, should we just convert all workers to stream and move on?

Alex

On Mon, 4 Oct 2021 at 18:27, Michael Halstead <mhalstead@linuxfoundation.org>
wrote:

> This error was fixed upstream
> https://bugzilla.redhat.com/show_bug.cgi?id=1975562 kernel 4.18.0-325.x
> which has landed in CentOS8 Stream on centos8-ty-2 but not plain CentOS8
> where the newest kernel is still at 4.18.0-305.x.
>
> I'll reboot into the older 4.18.0-240.15 kernel again on centos8-ty-1 as a
> fix for now.
>
> On Tue, Sep 28, 2021 at 6:12 PM Anuj Mittal <anuj.mittal@intel.com> wrote:
>
>> Did we find out the reason why this was happening? I have started
>> getting this error on Centos-8 while building hardknott.
>>
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045
>>
>> Thanks,
>>
>> Anuj
>>
>> On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
>> > On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
>> > > On Sun, 6 Jun 2021 at 01:10, Richard Purdie
>> > > <richard.purdie@linuxfoundation.org> wrote:
>> > > > I tried again with the autobuilder, still fails:
>> > > >
>> > > >
>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
>> > > >
>> > > > so whatever it is, it is still "live".
>> > > >
>> > >
>> > >
>> > > I did some digging. The issue happens when:
>> > > - host is centos8
>> > > - SDKMACHINE is i686 (e.g. cmake is 32 bit)
>> > >
>> > > Then there's a failing syscall attempting to set file times:
>> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
>> > > 4.1/assimp-config.cmake",
>> > > [{tv_sec=1622966723, tv_nsec=6319439026193432576},
>> > > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
>> > > EINVAL (Invalid argument)
>> > >
>> > > On latest Fedora, there's no issue:
>> > > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
>> > > 4.1/assimp-config.cmake",
>> > > [{tv_sec=1623002886, tv_nsec=6369724778172907520},
>> > > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
>> > >
>> > > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
>> > > be returning ENOSYS in that case
>> > > probably?
>> >
>> > I hacked up a quick test bit of code (which makes assumptions
>> > about 32 bit):
>> >
>> > #include <unistd.h>
>> > #include <sys/syscall.h>
>> > #include <sys/types.h>
>> > #include <sys/stat.h>
>> > #include <fcntl.h>
>> > #include <stdio.h>
>> >
>> > struct timespec64 {
>> >     long long           tv_sec;                 /* seconds */
>> >     long long           tv_nsec;                /* nanoseconds */
>> > };
>> >
>> > int main() {
>> >   int fd = open("foo", O_RDWR | O_CREAT, 0644);
>> >   write(fd, "foo", 3);
>> >   struct timespec64 times[2] = {};
>> >   times[0].tv_sec = 1622966723;
>> >   times[0].tv_nsec = 631943;
>> >   times[1].tv_sec = 1622966579;
>> >   times[1].tv_nsec = 178400;
>> >   int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
>> >   printf("rc=%d\n", rc);
>> >   close(fd);
>> >   return rc;
>> > }
>> >
>> > built with "gcc -m32 test-syscall.c -o test" and run with "strace
>> > ./test".
>> > This works on all the systems I tried it in. As does:
>> >
>> >
>> >   times[0].tv_sec = 1;
>> >   times[0].tv_nsec = 2;
>> >   times[1].tv_sec = 3;
>> >   times[1].tv_nsec = 4;
>> >
>> > however if you set (and ignore the compiler warning):
>> >
>> >   times[0].tv_sec = 1622966723;
>> >   times[0].tv_nsec = 6319439026193432576;
>> >   times[1].tv_sec = 1622966579;
>> >   times[1].tv_nsec = 17840053692309438464;
>> >
>> > then you see EINVAL on the centos system but not on my ubuntu one. It
>> > will
>> > do that until you reduce the values of tv_nsec right now. So it seems
>> > most
>> > systems accept large tv_nsec values but the Centos one does not.
>> >
>> > I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
>> > be
>> > a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
>> > long.
>> >
>> > Michael: Hopefully that gives you something to raise with them?
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>> >
>>
>>
>> -=-=-=-=-=-=-=-=-=-=-=-
>> Links: You receive all messages sent to this group.
>> View/Reply Online (#156435):
>> https://lists.openembedded.org/g/openembedded-core/message/156435
>> Mute This Topic: https://lists.openembedded.org/mt/83304703/1003190
>> Group Owner: openembedded-core+owner@lists.openembedded.org
>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
>> mhalstead@linuxfoundation.org]
>> -=-=-=-=-=-=-=-=-=-=-=-
>>
>>
>
> --
> Michael Halstead
> Linux Foundation / Yocto Project
> Systems Operations Engineer
>

[-- Attachment #2: Type: text/html, Size: 7202 bytes --]

Re: [OE-core] [PATCH 04/10] cmake: update 3.20.2 -> 3.20.3

[Michael Halstead]

[-- Attachment #1: Type: text/plain, Size: 5216 bytes --]

I'll go ahead and switch to CentOS8-Stream once the current a-full is
complete. If there is a need to follow RHEL8 exactly we can add a Rocky
Linux worker in the future.


On Mon, Oct 4, 2021 at 11:28 AM Alexander Kanavin <alex.kanavin@gmail.com>
wrote:

> Since the original centos 8 is going away (support-wise) in less than 3
> months, should we just convert all workers to stream and move on?
>
> Alex
>
> On Mon, 4 Oct 2021 at 18:27, Michael Halstead <
> mhalstead@linuxfoundation.org> wrote:
>
>> This error was fixed upstream
>> https://bugzilla.redhat.com/show_bug.cgi?id=1975562 kernel 4.18.0-325.x
>> which has landed in CentOS8 Stream on centos8-ty-2 but not plain CentOS8
>> where the newest kernel is still at 4.18.0-305.x.
>>
>> I'll reboot into the older 4.18.0-240.15 kernel again on centos8-ty-1 as
>> a fix for now.
>>
>> On Tue, Sep 28, 2021 at 6:12 PM Anuj Mittal <anuj.mittal@intel.com>
>> wrote:
>>
>>> Did we find out the reason why this was happening? I have started
>>> getting this error on Centos-8 while building hardknott.
>>>
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4045
>>>
>>> Thanks,
>>>
>>> Anuj
>>>
>>> On Wed, 2021-06-16 at 23:45 +0100, Richard Purdie wrote:
>>> > On Sun, 2021-06-06 at 21:51 +0200, Alexander Kanavin wrote:
>>> > > On Sun, 6 Jun 2021 at 01:10, Richard Purdie
>>> > > <richard.purdie@linuxfoundation.org> wrote:
>>> > > > I tried again with the autobuilder, still fails:
>>> > > >
>>> > > >
>>> https://autobuilder.yoctoproject.org/typhoon/#/builders/48/builds/3516
>>> > > >
>>> > > > so whatever it is, it is still "live".
>>> > > >
>>> > >
>>> > >
>>> > > I did some digging. The issue happens when:
>>> > > - host is centos8
>>> > > - SDKMACHINE is i686 (e.g. cmake is 32 bit)
>>> > >
>>> > > Then there's a failing syscall attempting to set file times:
>>> > > utimensat_time64(AT_FDCWD, "../install/usr/local/lib/cmake/assimp-
>>> > > 4.1/assimp-config.cmake",
>>> > > [{tv_sec=1622966723, tv_nsec=6319439026193432576},
>>> > > {tv_sec=1622966579, tv_nsec=17840053692309438464}], 0) = -1
>>> > > EINVAL (Invalid argument)
>>> > >
>>> > > On latest Fedora, there's no issue:
>>> > > utimensat_time64(AT_FDCWD, "../install2/usr/local/lib/cmake/assimp-
>>> > > 4.1/assimp-config.cmake",
>>> > > [{tv_sec=1623002886, tv_nsec=6369724778172907520},
>>> > > {tv_sec=1623002886, tv_nsec=17839174083007217664}], 0) = 0
>>> > >
>>> > > utimensat_time64 only appeared with 5.1 kernels, however, 4.18 should
>>> > > be returning ENOSYS in that case
>>> > > probably?
>>> >
>>> > I hacked up a quick test bit of code (which makes assumptions
>>> > about 32 bit):
>>> >
>>> > #include <unistd.h>
>>> > #include <sys/syscall.h>
>>> > #include <sys/types.h>
>>> > #include <sys/stat.h>
>>> > #include <fcntl.h>
>>> > #include <stdio.h>
>>> >
>>> > struct timespec64 {
>>> >     long long           tv_sec;                 /* seconds */
>>> >     long long           tv_nsec;                /* nanoseconds */
>>> > };
>>> >
>>> > int main() {
>>> >   int fd = open("foo", O_RDWR | O_CREAT, 0644);
>>> >   write(fd, "foo", 3);
>>> >   struct timespec64 times[2] = {};
>>> >   times[0].tv_sec = 1622966723;
>>> >   times[0].tv_nsec = 631943;
>>> >   times[1].tv_sec = 1622966579;
>>> >   times[1].tv_nsec = 178400;
>>> >   int rc = syscall(SYS_utimensat_time64, fd, NULL, &times[0], 0);
>>> >   printf("rc=%d\n", rc);
>>> >   close(fd);
>>> >   return rc;
>>> > }
>>> >
>>> > built with "gcc -m32 test-syscall.c -o test" and run with "strace
>>> > ./test".
>>> > This works on all the systems I tried it in. As does:
>>> >
>>> >
>>> >   times[0].tv_sec = 1;
>>> >   times[0].tv_nsec = 2;
>>> >   times[1].tv_sec = 3;
>>> >   times[1].tv_nsec = 4;
>>> >
>>> > however if you set (and ignore the compiler warning):
>>> >
>>> >   times[0].tv_sec = 1622966723;
>>> >   times[0].tv_nsec = 6319439026193432576;
>>> >   times[1].tv_sec = 1622966579;
>>> >   times[1].tv_nsec = 17840053692309438464;
>>> >
>>> > then you see EINVAL on the centos system but not on my ubuntu one. It
>>> > will
>>> > do that until you reduce the values of tv_nsec right now. So it seems
>>> > most
>>> > systems accept large tv_nsec values but the Centos one does not.
>>> >
>>> > I think tv_nsec may be being clamped to LONG_MAX of 4 bytes but should
>>> > be
>>> > a LONG_LONG_MAX of 8 bytes on a 32 bit since the field is a 64 bit
>>> > long.
>>> >
>>> > Michael: Hopefully that gives you something to raise with them?
>>> >
>>> > Cheers,
>>> >
>>> > Richard
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>> >
>>>
>>>
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>> Links: You receive all messages sent to this group.
>>> View/Reply Online (#156435):
>>> https://lists.openembedded.org/g/openembedded-core/message/156435
>>> Mute This Topic: https://lists.openembedded.org/mt/83304703/1003190
>>> Group Owner: openembedded-core+owner@lists.openembedded.org
>>> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [
>>> mhalstead@linuxfoundation.org]
>>> -=-=-=-=-=-=-=-=-=-=-=-
>>>
>>>
>>
>> --
>> Michael Halstead
>> Linux Foundation / Yocto Project
>> Systems Operations Engineer
>>
>

-- 
Michael Halstead
Linux Foundation / Yocto Project
Systems Operations Engineer

[-- Attachment #2: Type: text/html, Size: 7990 bytes --]

[PATCH 05/10] perl: split perl-cross into its own recipe

[Alexander Kanavin]

As perl and perl-cross need to be updated (and patches rebased)
in lockstep, devtool upgrade (and therefore AUH) can't cope with it.
Manually updating is still possible, but painful.

Split determinism.patch into perl and perl-cross parts, move the
rest of the perl-cross patches.

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/conf/distro/include/maintainers.inc      |  1 +
 ...h-do-not-hardcode-prefix-lib-as-libr.patch |  0
 ...h-do-not-quote-the-argument-to-comma.patch |  0
 ...oss-add-LDFLAGS-when-linking-libperl.patch |  0
 .../perl-cross/files/README.md                | 29 ++++++++++++
 .../perl-cross/files/determinism.patch        | 46 +++++++++++++++++++
 .../perl-cross/perlcross_1.3.5.bb             | 38 +++++++++++++++
 .../perl/files/determinism.patch              | 23 ----------
 meta/recipes-devtools/perl/perl_5.32.1.bb     | 17 ++-----
 9 files changed, 118 insertions(+), 36 deletions(-)
 rename meta/recipes-devtools/{perl => perl-cross}/files/0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch (100%)
 rename meta/recipes-devtools/{perl => perl-cross}/files/0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch (100%)
 rename meta/recipes-devtools/{perl => perl-cross}/files/0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch (100%)
 create mode 100644 meta/recipes-devtools/perl-cross/files/README.md
 create mode 100644 meta/recipes-devtools/perl-cross/files/determinism.patch
 create mode 100644 meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb

diff --git a/meta/conf/distro/include/maintainers.inc b/meta/conf/distro/include/maintainers.inc
index ee118209db..89dec1f86a 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -558,6 +558,7 @@ RECIPE_MAINTAINER_pn-pciutils = "Chen Qi <Qi.Chen@windriver.com>"
 RECIPE_MAINTAINER_pn-pcmanfm = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-perf = "Bruce Ashfield <bruce.ashfield@gmail.com>"
 RECIPE_MAINTAINER_pn-perl = "Alexander Kanavin <alex.kanavin@gmail.com>"
+RECIPE_MAINTAINER_pn-perlcross = "Alexander Kanavin <alex.kanavin@gmail.com>"
 RECIPE_MAINTAINER_pn-piglit = "Ross Burton <ross.burton@arm.com>"
 RECIPE_MAINTAINER_pn-pigz = "Hongxu Jia <hongxu.jia@windriver.com>"
 RECIPE_MAINTAINER_pn-pinentry = "Armin Kuster <akuster808@gmail.com>"
diff --git a/meta/recipes-devtools/perl/files/0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch b/meta/recipes-devtools/perl-cross/files/0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch
similarity index 100%
rename from meta/recipes-devtools/perl/files/0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch
rename to meta/recipes-devtools/perl-cross/files/0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch
diff --git a/meta/recipes-devtools/perl/files/0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch b/meta/recipes-devtools/perl-cross/files/0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch
similarity index 100%
rename from meta/recipes-devtools/perl/files/0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch
rename to meta/recipes-devtools/perl-cross/files/0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch
diff --git a/meta/recipes-devtools/perl/files/0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch b/meta/recipes-devtools/perl-cross/files/0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch
similarity index 100%
rename from meta/recipes-devtools/perl/files/0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch
rename to meta/recipes-devtools/perl-cross/files/0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch
diff --git a/meta/recipes-devtools/perl-cross/files/README.md b/meta/recipes-devtools/perl-cross/files/README.md
new file mode 100644
index 0000000000..93217245c8
--- /dev/null
+++ b/meta/recipes-devtools/perl-cross/files/README.md
@@ -0,0 +1,29 @@
+**perl-cross** provides configure script, top-level Makefile
+and some auxiliary files for [perl](http://www.perl.org),  
+with the primary emphasis on cross-compiling the source.  
+
+    # Get perl and perl-cross sources
+    curl -L -O http://www.cpan.org/src/5.0/perl-5.24.1.tar.gz
+    curl -L -O https://github.com/arsv/perl-cross/releases/download/1.1.3/perl-cross-1.1.3.tar.gz
+
+    # Unpack perl-cross over perl, overwriting Makefile
+    tar -zxf perl-5.24.1.tar.gz
+    cd perl-5.24.1
+    tar --strip-components=1 -zxf ../perl-cross-1.1.3.tar.gz
+
+    # Proceed as usual with most autoconfed packages
+    ./configure --target=arm-linux-gnueabi --prefix=/usr -Duseshrplib
+    make -j4
+    make DESTDIR=/path/to/staging/dir install
+
+Unlike mainline Perl, this configure never runs any target executables,  
+relying solely on compile/link tests and pre-defined hints.  
+On the flip side, it is only meant to run on resonably sane modern unix systems.  
+
+Check [project pages](http://arsv.github.io/perl-cross/) for more info.  
+In particular, [configure usage](http://arsv.github.io/perl-cross/usage.html)
+lists available configure options.
+
+Perl-cross is a free software licensed under the same terms
+as the original perl source.  
+See LICENSE, Copying and Artistic files.
diff --git a/meta/recipes-devtools/perl-cross/files/determinism.patch b/meta/recipes-devtools/perl-cross/files/determinism.patch
new file mode 100644
index 0000000000..e9bf752bcb
--- /dev/null
+++ b/meta/recipes-devtools/perl-cross/files/determinism.patch
@@ -0,0 +1,46 @@
+Fixes to make the perl build reproducible:
+
+a) Remove the \n from configure_attr.sh since it gets quoted differently depending on
+   whether the shell is bash or dash which can cause the test result to be incorrect.
+   Reported upstream: https://github.com/arsv/perl-cross/issues/87
+
+b) Sort the order of the module lists from configure_mods.sh since otherwise
+   the result isn't the same leading to makefile differences.
+   Reported upstream: https://github.com/arsv/perl-cross/issues/88
+
+c) Sort the Encode::Byte byte_t.fnm file output (and the makefile depends whilst 
+   there for good measure)
+   This needs to go to upstream perl (not done)
+
+d) Use bash for perl-cross configure since otherwise trnl gets set to "\n" with bash
+   and "" with dash
+   Reported upstream: https://github.com/arsv/perl-cross/issues/87
+
+RP 2020/2/7
+
+Upstream-Status: Pending [75% submitted]
+Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
+
+Index: perl-5.30.1/cnf/configure_mods.sh
+===================================================================
+--- perl-5.30.1.orig/cnf/configure_mods.sh
++++ perl-5.30.1/cnf/configure_mods.sh
+@@ -82,7 +82,7 @@ extonlyif() {
+ }
+ 
+ definetrimspaces() {
+-	v=`echo "$2" | sed -r -e 's/\s+/ /g' -e 's/^\s+//' -e 's/\s+$//'`
++	v=`echo "$2" | sed -r -e 's/\s+/ /g' -e 's/^\s+//' -e 's/\s+$//' | xargs -n1 | LANG=C sort | xargs`
+ 	define $1 "$v"
+ }
+ 
+Index: perl-5.30.1/cnf/configure
+===================================================================
+--- perl-5.30.1.orig/cnf/configure
++++ perl-5.30.1/cnf/configure
+@@ -1,4 +1,4 @@
+-#!/bin/sh
++#!/bin/bash
+ 
+ base=${0%/*}; test -z "$base" && base=.
+ 
diff --git a/meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb b/meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb
new file mode 100644
index 0000000000..0d81d4d0f1
--- /dev/null
+++ b/meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb
@@ -0,0 +1,38 @@
+SUMMARY = "Perl-cross build system"
+HOMEPAGE = "https://github.com/arsv/perl-cross"
+DESCRIPTION = "perl-cross provides configure script, top-level Makefile and some auxiliary files for perl, \
+with the primary emphasis on cross-compiling the source."
+SECTION = "devel"
+LICENSE = "Artistic-1.0 | GPL-1.0+"
+# README.md is taken from https://github.com/arsv/perl-cross/blob/master/README.md
+# but is not provided inside the release tarballs
+LIC_FILES_CHKSUM = "file://${WORKDIR}/README.md;md5=252fcce2026b765fee1ad74d2fb07a3b"
+
+inherit allarch
+
+SRC_URI = "https://github.com/arsv/perl-cross/releases/download/${PV}/perl-cross-${PV}.tar.gz;name=perl-cross \
+           file://README.md \
+           file://0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch \
+           file://0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch \
+           file://0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch \
+           file://determinism.patch \
+"
+UPSTREAM_CHECK_URI = "https://github.com/arsv/perl-cross/releases/"
+
+SRC_URI[perl-cross.sha256sum] = "91c66f6b2b99fccfd4fee14660b677380b0c98f9456359e91449798c2ad2ef25"
+
+S = "${WORKDIR}/perl-cross-${PV}"
+
+do_configure () {
+}
+
+do_compile () {
+}
+
+do_install_class-native() {
+    mkdir -p ${D}/${datadir}/perl-cross/
+    cp -rf ${S}/* ${D}/${datadir}/perl-cross/
+}
+
+BBCLASSEXTEND = "native"
+
diff --git a/meta/recipes-devtools/perl/files/determinism.patch b/meta/recipes-devtools/perl/files/determinism.patch
index ccdd52a0d0..aa85ccef10 100644
--- a/meta/recipes-devtools/perl/files/determinism.patch
+++ b/meta/recipes-devtools/perl/files/determinism.patch
@@ -21,19 +21,6 @@ RP 2020/2/7
 Upstream-Status: Pending [75% submitted]
 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org
 
-Index: perl-5.30.1/cnf/configure_mods.sh
-===================================================================
---- perl-5.30.1.orig/cnf/configure_mods.sh
-+++ perl-5.30.1/cnf/configure_mods.sh
-@@ -82,7 +82,7 @@ extonlyif() {
- }
- 
- definetrimspaces() {
--	v=`echo "$2" | sed -r -e 's/\s+/ /g' -e 's/^\s+//' -e 's/\s+$//'`
-+	v=`echo "$2" | sed -r -e 's/\s+/ /g' -e 's/^\s+//' -e 's/\s+$//' | xargs -n1 | LANG=C sort | xargs`
- 	define $1 "$v"
- }
- 
 Index: perl-5.30.1/cpan/Encode/Byte/Makefile.PL
 ===================================================================
 --- perl-5.30.1.orig/cpan/Encode/Byte/Makefile.PL
@@ -56,13 +43,3 @@ Index: perl-5.30.1/cpan/Encode/Byte/Makefile.PL
      {
          print FILELIST $self->catfile($dir,$file) . "\n";
      }
-Index: perl-5.30.1/cnf/configure
-===================================================================
---- perl-5.30.1.orig/cnf/configure
-+++ perl-5.30.1/cnf/configure
-@@ -1,4 +1,4 @@
--#!/bin/sh
-+#!/bin/bash
- 
- base=${0%/*}; test -z "$base" && base=.
- 
diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb b/meta/recipes-devtools/perl/perl_5.32.1.bb
index b28040c7fb..01db924a73 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.32.1.bb
@@ -9,18 +9,14 @@ LIC_FILES_CHKSUM = "file://Copying;md5=5b122a36d0f6dc55279a0ebc69f3c60b \
 
 
 SRC_URI = "https://www.cpan.org/src/5.0/perl-${PV}.tar.gz;name=perl \
-           https://github.com/arsv/perl-cross/releases/download/1.3.5/perl-cross-1.3.5.tar.gz;name=perl-cross \
            file://perl-rdepends.txt \
-           file://0001-configure_tool.sh-do-not-quote-the-argument-to-comma.patch \
            file://0001-ExtUtils-MakeMaker-add-LDFLAGS-when-linking-binary-m.patch \
            file://0001-Somehow-this-module-breaks-through-the-perl-wrapper-.patch \
            file://errno_ver.diff \
            file://native-perlinc.patch \
-           file://0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch \
            file://perl-dynloader.patch \
-           file://0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch \
            file://0002-Constant-Fix-up-shebang.patch \
-           file://determinism.patch  \
+           file://determinism.patch \
            "
 SRC_URI_append_class-native = " \
            file://perl-configpm-switch.patch \
@@ -30,13 +26,12 @@ SRC_URI_append_class-target = " \
 "
 
 SRC_URI[perl.sha256sum] = "03b693901cd8ae807231b1787798cf1f2e0b8a56218d07b7da44f784a7caeb2c"
-SRC_URI[perl-cross.sha256sum] = "91c66f6b2b99fccfd4fee14660b677380b0c98f9456359e91449798c2ad2ef25"
 
 S = "${WORKDIR}/perl-${PV}"
 
 inherit upstream-version-is-even update-alternatives
 
-DEPENDS += "zlib virtual/crypt"
+DEPENDS += "perlcross-native zlib virtual/crypt"
 
 PERL_LIB_VER = "${@'.'.join(d.getVar('PV').split('.')[0:2])}.0"
 
@@ -47,12 +42,8 @@ PACKAGECONFIG[gdbm] = ",-Ui_gdbm,gdbm"
 # Don't generate comments in enc2xs output files. They are not reproducible
 export ENC2XS_NO_COMMENTS = "1"
 
-do_unpack_append() {
-    bb.build.exec_func('do_copy_perlcross', d)
-}
-
-do_copy_perlcross() {
-    cp -rfp ${WORKDIR}/perl-cross*/* ${S}
+do_configure_prepend() {
+    cp -rfp ${STAGING_DATADIR_NATIVE}/perl-cross/* ${S}
 }
 
 do_configure_class-target() {
-- 
2.31.1

Re: [OE-core] [PATCH 05/10] perl: split perl-cross into its own recipe

[Jacob Kroon]

On 6/4/21 11:14 AM, Alexander Kanavin wrote:
> As perl and perl-cross need to be updated (and patches rebased)
> in lockstep, devtool upgrade (and therefore AUH) can't cope with it.
> Manually updating is still possible, but painful.
> 
> Split determinism.patch into perl and perl-cross parts, move the
> rest of the perl-cross patches.
> 

Not sure if this is intentional, but when I build master now I get a new 
dependency pulled in that is built called "perlcross-native". Given the 
sound of that name, is that intentional ?

Regards,
Jacob

Re: [OE-core] [PATCH 05/10] perl: split perl-cross into its own recipe

[Richard Purdie]

On Mon, 2021-06-07 at 07:29 +0200, Jacob Kroon wrote:
> On 6/4/21 11:14 AM, Alexander Kanavin wrote:
> > As perl and perl-cross need to be updated (and patches rebased)
> > in lockstep, devtool upgrade (and therefore AUH) can't cope with it.
> > Manually updating is still possible, but painful.
> > 
> > Split determinism.patch into perl and perl-cross parts, move the
> > rest of the perl-cross patches.
> > 
> 
> Not sure if this is intentional, but when I build master now I get a new 
> dependency pulled in that is built called "perlcross-native". Given the 
> sound of that name, is that intentional ?

The component is called "perl cross" and this is the native version of it.

It is rather unfortunate naming but technically accurate :/.

Cheers,

Richard

[PATCH 06/10] perl-cross: 1.3.5 -> 1.3.6

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 ...nc_sel.sh-disable-thread_safe_nl_lan.patch | 27 +++++++++++++++++++
 ...{perlcross_1.3.5.bb => perlcross_1.3.6.bb} |  5 ++--
 2 files changed, 30 insertions(+), 2 deletions(-)
 create mode 100644 meta/recipes-devtools/perl-cross/files/0001-cnf-configure_func_sel.sh-disable-thread_safe_nl_lan.patch
 rename meta/recipes-devtools/perl-cross/{perlcross_1.3.5.bb => perlcross_1.3.6.bb} (86%)

diff --git a/meta/recipes-devtools/perl-cross/files/0001-cnf-configure_func_sel.sh-disable-thread_safe_nl_lan.patch b/meta/recipes-devtools/perl-cross/files/0001-cnf-configure_func_sel.sh-disable-thread_safe_nl_lan.patch
new file mode 100644
index 0000000000..744e4e09c3
--- /dev/null
+++ b/meta/recipes-devtools/perl-cross/files/0001-cnf-configure_func_sel.sh-disable-thread_safe_nl_lan.patch
@@ -0,0 +1,27 @@
+From d22f2bb5afcd278b68999f5ce0362328fc8c7723 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin <alex.kanavin@gmail.com>
+Date: Thu, 3 Jun 2021 18:50:56 +0200
+Subject: [PATCH] cnf/configure_func_sel.sh: disable thread_safe_nl_langinfo_l
+
+Upstream-Status: Submitted [https://github.com/arsv/perl-cross/pull/115]
+Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
+---
+ cnf/configure_func_sel.sh | 8 ++++++--
+ 1 file changed, 6 insertions(+), 2 deletions(-)
+
+diff --git a/cnf/configure_func_sel.sh b/cnf/configure_func_sel.sh
+index f48294f..90d350d 100644
+--- a/cnf/configure_func_sel.sh
++++ b/cnf/configure_func_sel.sh
+@@ -97,5 +97,9 @@ else
+ 	result "irrelevant"
+ fi
+ 
+-# Assume nl_langinfo_l is threadsafe if available
+-define d_thread_safe_nl_langinfo_l "$d_nl_langinfo_l"
++# thread_safe_nl_langinfo_l is not enabled by default
++# by upstream, and causes t/Langinfo.t to fail when it is
++# (starting from 5.34.0). This means the configuration is
++# either not well tested, or not at all tested, so we should
++# pick a safer option.
++define d_thread_safe_nl_langinfo_l "undef"
diff --git a/meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb b/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
similarity index 86%
rename from meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb
rename to meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
index 0d81d4d0f1..b77bbd1fd4 100644
--- a/meta/recipes-devtools/perl-cross/perlcross_1.3.5.bb
+++ b/meta/recipes-devtools/perl-cross/perlcross_1.3.6.bb
@@ -16,10 +16,11 @@ SRC_URI = "https://github.com/arsv/perl-cross/releases/download/${PV}/perl-cross
            file://0001-perl-cross-add-LDFLAGS-when-linking-libperl.patch \
            file://0001-configure_path.sh-do-not-hardcode-prefix-lib-as-libr.patch \
            file://determinism.patch \
-"
+           file://0001-cnf-configure_func_sel.sh-disable-thread_safe_nl_lan.patch \
+           "
 UPSTREAM_CHECK_URI = "https://github.com/arsv/perl-cross/releases/"
 
-SRC_URI[perl-cross.sha256sum] = "91c66f6b2b99fccfd4fee14660b677380b0c98f9456359e91449798c2ad2ef25"
+SRC_URI[perl-cross.sha256sum] = "4010f41870d64e3957b4b8ce70ebba10a7c4a3e86c5551acb4099c3fcbb37ce5"
 
 S = "${WORKDIR}/perl-cross-${PV}"
 
-- 
2.31.1

[PATCH 07/10] perl: update 5.32.1 -> 5.34.0

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-devtools/perl/{perl_5.32.1.bb => perl_5.34.0.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/perl/{perl_5.32.1.bb => perl_5.34.0.bb} (99%)

diff --git a/meta/recipes-devtools/perl/perl_5.32.1.bb b/meta/recipes-devtools/perl/perl_5.34.0.bb
similarity index 99%
rename from meta/recipes-devtools/perl/perl_5.32.1.bb
rename to meta/recipes-devtools/perl/perl_5.34.0.bb
index 01db924a73..7935a58723 100644
--- a/meta/recipes-devtools/perl/perl_5.32.1.bb
+++ b/meta/recipes-devtools/perl/perl_5.34.0.bb
@@ -25,7 +25,7 @@ SRC_URI_append_class-target = " \
            file://encodefix.patch \
 "
 
-SRC_URI[perl.sha256sum] = "03b693901cd8ae807231b1787798cf1f2e0b8a56218d07b7da44f784a7caeb2c"
+SRC_URI[perl.sha256sum] = "551efc818b968b05216024fb0b727ef2ad4c100f8cb6b43fab615fa78ae5be9a"
 
 S = "${WORKDIR}/perl-${PV}"
 
-- 
2.31.1

[PATCH 08/10] libgcrypt: upgrade 1.9.2 -> 1.9.3

[Alexander Kanavin]

License-Update: added terms for cipher/cipher-gcm-ppc.c, still under GPL

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 .../libgcrypt/{libgcrypt_1.9.2.bb => libgcrypt_1.9.3.bb}      | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-support/libgcrypt/{libgcrypt_1.9.2.bb => libgcrypt_1.9.3.bb} (93%)

diff --git a/meta/recipes-support/libgcrypt/libgcrypt_1.9.2.bb b/meta/recipes-support/libgcrypt/libgcrypt_1.9.3.bb
similarity index 93%
rename from meta/recipes-support/libgcrypt/libgcrypt_1.9.2.bb
rename to meta/recipes-support/libgcrypt/libgcrypt_1.9.3.bb
index 34735ea5d7..fd3d8e09f2 100644
--- a/meta/recipes-support/libgcrypt/libgcrypt_1.9.2.bb
+++ b/meta/recipes-support/libgcrypt/libgcrypt_1.9.3.bb
@@ -14,7 +14,7 @@ LICENSE_dumpsexp-dev = "GPLv3+"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f \
                     file://COPYING.LIB;md5=bbb461211a33b134d42ed5ee802b37ff \
-                    file://LICENSES;md5=2dae15d91a37cfde72fe9eae75f8ea14 \
+                    file://LICENSES;md5=42fa35a25e138166cc40588387f9159d \
                     "
 
 DEPENDS = "libgpg-error"
@@ -27,7 +27,7 @@ SRC_URI = "${GNUPG_MIRROR}/libgcrypt/libgcrypt-${PV}.tar.bz2 \
            file://0004-tests-Makefile.am-fix-undefined-reference-to-pthread.patch \
            file://0001-Makefile.am-add-a-missing-space.patch \
            "
-SRC_URI[sha256sum] = "b2c10d091513b271e47177274607b1ffba3d95b188bbfa8797f948aec9053c5a"
+SRC_URI[sha256sum] = "97ebe4f94e2f7e35b752194ce15a0f3c66324e0ff6af26659bbfb5ff2ec328fd"
 
 # Below whitelisted CVEs are disputed and not affecting crypto libraries for any distro.
 CVE_CHECK_WHITELIST += "CVE-2018-12433 CVE-2018-12438"
-- 
2.31.1

[PATCH 09/10] xf86-input-libinput: update 0.30.0 -> 1.0.1

[Alexander Kanavin]

License-Update: formatting

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 .../xorg-driver/xf86-input-libinput_0.30.0.bb         | 11 -----------
 .../xorg-driver/xf86-input-libinput_1.0.1.bb          | 10 ++++++++++
 2 files changed, 10 insertions(+), 11 deletions(-)
 delete mode 100644 meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
 create mode 100644 meta/recipes-graphics/xorg-driver/xf86-input-libinput_1.0.1.bb

diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
deleted file mode 100644
index d02988caa4..0000000000
--- a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_0.30.0.bb
+++ /dev/null
@@ -1,11 +0,0 @@
-require xorg-driver-input.inc
-
-SUMMARY = "Generic input driver for the X.Org server based on libinput"
-LIC_FILES_CHKSUM = "file://COPYING;md5=5e6b20ea2ef94a998145f0ea3f788ee0"
-
-DEPENDS += "libinput"
-
-SRC_URI[md5sum] = "11dcfa2cc39f790731a9545fcdeea717"
-SRC_URI[sha256sum] = "f9c7f9fd41ae14061e0e9c3bd45fa170e5e21027a2bc5810034e1e748db996c0"
-
-FILES_${PN} += "${datadir}/X11/xorg.conf.d"
diff --git a/meta/recipes-graphics/xorg-driver/xf86-input-libinput_1.0.1.bb b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_1.0.1.bb
new file mode 100644
index 0000000000..8da47eaa43
--- /dev/null
+++ b/meta/recipes-graphics/xorg-driver/xf86-input-libinput_1.0.1.bb
@@ -0,0 +1,10 @@
+require xorg-driver-input.inc
+
+SUMMARY = "Generic input driver for the X.Org server based on libinput"
+LIC_FILES_CHKSUM = "file://COPYING;md5=a22925127bd3c827c384cedd23ed2309"
+
+DEPENDS += "libinput"
+
+SRC_URI[sha256sum] = "fddec49c115591918475155bf16aaf23017d7f814cee7823a0c11f867aca245b"
+
+FILES_${PN} += "${datadir}/X11/xorg.conf.d"
-- 
2.31.1

[PATCH 10/10] erofs-utils: correct upstream version check

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex.kanavin@gmail.com>
---
 meta/recipes-devtools/erofs-utils/erofs-utils_1.2.1.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-devtools/erofs-utils/erofs-utils_1.2.1.bb b/meta/recipes-devtools/erofs-utils/erofs-utils_1.2.1.bb
index 6435fea68c..5ab4bf2816 100644
--- a/meta/recipes-devtools/erofs-utils/erofs-utils_1.2.1.bb
+++ b/meta/recipes-devtools/erofs-utils/erofs-utils_1.2.1.bb
@@ -7,6 +7,8 @@ HOMEPAGE = "https://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.gi
 SRCREV = "d1f4953edfcf4f51c71ba91586e21fc6ce9f6db9"
 SRC_URI = "git://git.kernel.org/pub/scm/linux/kernel/git/xiang/erofs-utils.git"
 
+UPSTREAM_CHECK_GITTAGREGEX = "v(?P<pver>(\d+(\.\d+)+))"
+
 S = "${WORKDIR}/git"
 
 DEPENDS = "util-linux-libuuid"
-- 
2.31.1