[OE-core] [PATCH] sanity/lib: Replace usage if LooseVersion with bb.utils.vercmp_string_op

2021-11-26 Thread Richard Purdie
distutils is going away and we have functionality in bitbake which can
handle these comparisions so switch to the bb.utils function.

Signed-off-by: Richard Purdie 
---
 meta/classes/sanity.bbclass | 18 ++
 meta/lib/oe/distro_check.py |  2 +-
 meta/lib/oe/terminal.py |  7 +++
 3 files changed, 10 insertions(+), 17 deletions(-)

diff --git a/meta/classes/sanity.bbclass b/meta/classes/sanity.bbclass
index 9fbc9c18e7c..0e20589b22d 100644
--- a/meta/classes/sanity.bbclass
+++ b/meta/classes/sanity.bbclass
@@ -462,13 +462,12 @@ def check_sanity_validmachine(sanity_data):
 # Patch before 2.7 can't handle all the features in git-style diffs.  Some
 # patches may incorrectly apply, and others won't apply at all.
 def check_patch_version(sanity_data):
-from distutils.version import LooseVersion
 import re, subprocess
 
 try:
 result = subprocess.check_output(["patch", "--version"], 
stderr=subprocess.STDOUT).decode('utf-8')
 version = re.search(r"[0-9.]+", result.splitlines()[0]).group()
-if LooseVersion(version) < LooseVersion("2.7"):
+if bb.utils.vercmp_string_op(version, "2.7", "<"):
 return "Your version of patch is older than 2.7 and has bugs which 
will break builds. Please install a newer version of patch.\n"
 else:
 return None
@@ -478,7 +477,6 @@ def check_patch_version(sanity_data):
 # Unpatched versions of make 3.82 are known to be broken.  See GNU Savannah 
Bug 30612.
 # Use a modified reproducer from http://savannah.gnu.org/bugs/?30612 to 
validate.
 def check_make_version(sanity_data):
-from distutils.version import LooseVersion
 import subprocess
 
 try:
@@ -486,7 +484,7 @@ def check_make_version(sanity_data):
 except subprocess.CalledProcessError as e:
 return "Unable to execute make --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[2]
-if LooseVersion(version) == LooseVersion("3.82"):
+if bb.utils.vercmp_string_op(version, "3.82", "=="):
 # Construct a test file
 f = open("makefile_test", "w")
 f.write("makefile_test.a: makefile_test_a.c makefile_test_b.c 
makefile_test.a( makefile_test_a.c makefile_test_b.c)\n")
@@ -539,12 +537,11 @@ def check_wsl(d):
 # built buildtools-extended-tarball)
 #
 def check_gcc_version(sanity_data):
-from distutils.version import LooseVersion
 import subprocess
 
 build_cc, version = oe.utils.get_host_compiler_version(sanity_data)
 if build_cc.strip() == "gcc":
-if LooseVersion(version) < LooseVersion("7.5"):
+if bb.utils.vercmp_string_op(version, "7.5", "<"):
 return "Your version of gcc is older than 7.5 and will break 
builds. Please install a newer version of gcc (you could use the project's 
buildtools-extended-tarball or use scripts/install-buildtools).\n"
 return None
 
@@ -552,14 +549,13 @@ def check_gcc_version(sanity_data):
 # but earlier versions do not; this needs to work properly for sstate
 # Version 1.28 is needed so opkg-build works correctly when reproducibile 
builds are enabled
 def check_tar_version(sanity_data):
-from distutils.version import LooseVersion
 import subprocess
 try:
 result = subprocess.check_output(["tar", "--version"], 
stderr=subprocess.STDOUT).decode('utf-8')
 except subprocess.CalledProcessError as e:
 return "Unable to execute tar --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[3]
-if LooseVersion(version) < LooseVersion("1.28"):
+if bb.utils.vercmp_string_op(version, "1.28", "<"):
 return "Your version of tar is older than 1.28 and does not have the 
support needed to enable reproducible builds. Please install a newer version of 
tar (you could use the project's buildtools-tarball from our last release or 
use scripts/install-buildtools).\n"
 return None
 
@@ -567,14 +563,13 @@ def check_tar_version(sanity_data):
 # The kernel tools assume git >= 1.8.3.1 (verified needed > 1.7.9.5) see #6162 
 # The git fetcher also had workarounds for git < 1.7.9.2 which we've dropped
 def check_git_version(sanity_data):
-from distutils.version import LooseVersion
 import subprocess
 try:
 result = subprocess.check_output(["git", "--version"], 
stderr=subprocess.DEVNULL).decode('utf-8')
 except subprocess.CalledProcessError as e:
 return "Unable to execute git --version, exit code %d\n%s\n" % 
(e.returncode, e.output)
 version = result.split()[2]
-if LooseVersion(version) < LooseVersion("1.8.3.1"):
+if bb.utils.vercmp_string_op(version, 

[OE-core] [PATCH 2/3] oeqa/utils/dump: Fix typo

2021-11-26 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/utils/dump.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/dump.py b/meta/lib/oeqa/utils/dump.py
index bb067f48462..dc8757807e7 100644
--- a/meta/lib/oeqa/utils/dump.py
+++ b/meta/lib/oeqa/utils/dump.py
@@ -134,4 +134,4 @@ class MonitorDumper(BaseDumper):
 output = self.runner.run_monitor(cmd_name)
 self._write_dump(cmd_name, output)
 except Exception as e:
-print("Failed to dump QMP CMD: %s with\nExecption: %s" % 
(cmd_name, e))
+print("Failed to dump QMP CMD: %s with\nException: %s" % 
(cmd_name, e))
-- 
2.32.0


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



[OE-core] [PATCH 3/3] ptest-packagelists: Add missing python3-jsonpointer entry

2021-11-26 Thread Richard Purdie
Resolves:

WARNING: python3-jsonpointer-2.2-r0 do_package_qa: QA Issue: supports ptests 
but is not included in oe-core's ptest-packagelists.inc [missing-ptest]

Signed-off-by: Richard Purdie 
---
 meta/conf/distro/include/ptest-packagelists.inc | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
b/meta/conf/distro/include/ptest-packagelists.inc
index 374c1b8c150..bf9d158a0a4 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -51,6 +51,7 @@ PTESTS_FAST = "\
 python3-atomicwrites-ptest \
 python3-hypothesis-ptest \
 python3-jinja2-ptest \
+python3-jsonpointer-ptest \
 python3-markupsafe-ptest \
 python3-more-itertools-ptest \
 python3-pluggy-ptest \
-- 
2.32.0


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



[OE-core] [PATCH 1/3] oeqa/parselogs: Fix quoting

2021-11-26 Thread Richard Purdie
Fix deprecation warnings about invalid escape sequences.

Signed-off-by: Richard Purdie 
---
 meta/lib/oeqa/runtime/cases/parselogs.py | 14 +++---
 1 file changed, 7 insertions(+), 7 deletions(-)

diff --git a/meta/lib/oeqa/runtime/cases/parselogs.py 
b/meta/lib/oeqa/runtime/cases/parselogs.py
index 50101b78513..b81acdd18a2 100644
--- a/meta/lib/oeqa/runtime/cases/parselogs.py
+++ b/meta/lib/oeqa/runtime/cases/parselogs.py
@@ -303,7 +303,7 @@ class ParseLogsTest(OERuntimeTestCase):
 grepcmd = 'grep '
 grepcmd += '-Ei "'
 for error in errors:
-grepcmd += '\<' + error + '\>' + '|'
+grepcmd += r'\<' + error + r'\>' + '|'
 grepcmd = grepcmd[:-1]
 grepcmd += '" ' + str(log) + " | grep -Eiv \'"
 
@@ -314,13 +314,13 @@ class ParseLogsTest(OERuntimeTestCase):
 errorlist = ignore_errors['default']
 
 for ignore_error in errorlist:
-ignore_error = ignore_error.replace('(', '\(')
-ignore_error = ignore_error.replace(')', '\)')
+ignore_error = ignore_error.replace('(', r'\(')
+ignore_error = ignore_error.replace(')', r'\)')
 ignore_error = ignore_error.replace("'", '.')
-ignore_error = ignore_error.replace('?', '\?')
-ignore_error = ignore_error.replace('[', '\[')
-ignore_error = ignore_error.replace(']', '\]')
-ignore_error = ignore_error.replace('*', '\*')
+ignore_error = ignore_error.replace('?', r'\?')
+ignore_error = ignore_error.replace('[', r'\[')
+ignore_error = ignore_error.replace(']', r'\]')
+ignore_error = ignore_error.replace('*', r'\*')
 ignore_error = ignore_error.replace('0-9', '[0-9]')
 grepcmd += ignore_error + '|'
 grepcmd = grepcmd[:-1]
-- 
2.32.0


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



Re: [OE-core] [PATCH] openssl: fix EVP_PKEY_CTX_get_rsa_pss_saltlen() not returning a value

2021-11-26 Thread Richard Purdie
On Thu, 2021-11-25 at 11:10 +, Ross Burton wrote:
> Backport a patch submitted upstream. Specifically, this fixes signature
> validation in trusted-firmware-a with OpenSSL 3.
> 
> Signed-off-by: Ross Burton 
> ---
>  ...-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch | 89 +++
>  .../openssl/openssl_3.0.0.bb  |  1 +
>  2 files changed, 90 insertions(+)
>  create mode 100644 
> meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
> 
> diff --git 
> a/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
>  
> b/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
> new file mode 100644
> index 00..5c76485b5f
> --- /dev/null
> +++ 
> b/meta/recipes-connectivity/openssl/openssl/0001-Fix-EVP_PKEY_CTX_get_rsa_pss_saltlen-no.patch
> @@ -0,0 +1,89 @@
> +Upstream-Status: Submitted [https://github.com/openssl/openssl/pull/17136]
> +Signed-off-by: Ross Burton 
> +
> +From 425191c295ada8510b0ee87d292ef18b7a45d062 Mon Sep 17 00:00:00 2001
> +From: Tom Cosgrove 
> +Date: Thu, 25 Nov 2021 10:17:15 +
> +Subject: [PATCH] Fix EVP_PKEY_CTX_get_rsa_pss_saltlen() not returning a value
> +
> +When an integer value was specified, it was not being passed back via
> +the orig_p2 weirdness.
> +
> +Regression test included.
> +---
> + crypto/evp/ctrl_params_translate.c | 10 +-
> + test/evp_extra_test.c  | 28 
> + 2 files changed, 33 insertions(+), 5 deletions(-)
> +

I suspect this may be from this patch:

https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2586
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2865

Cheers,

Richard



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



[OE-core] [PATCH] gcc: Drop further unneeded precompiled header patch

2021-11-25 Thread Richard Purdie
According to comments on the bug report from gcc developers, we
no longer need to do this post gcc 10. Lets therefore drop the patch.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-11.2.inc|  1 -
 ...-fault-in-precompiled-header-generat.patch | 57 ---
 2 files changed, 58 deletions(-)
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0031-fix-segmentation-fault-in-precompiled-header-generat.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
b/meta/recipes-devtools/gcc/gcc-11.2.inc
index afb8f2df5c2..4c18396a15f 100644
--- a/meta/recipes-devtools/gcc/gcc-11.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -52,7 +52,6 @@ SRC_URI = "\

file://0028-Add-ssp_nonshared-to-link-commandline-for-musl-targe.patch \
file://0029-Link-libgcc-using-LDFLAGS-not-just-SHLIB_LDFLAGS.patch \
file://0030-sync-gcc-stddef.h-with-musl.patch \
-   
file://0031-fix-segmentation-fault-in-precompiled-header-generat.patch \
file://0033-Re-introduce-spe-commandline-options.patch \

file://0034-libgcc_s-Use-alias-for-__cpu_indicator_init-instead-.patch \

file://0035-gentypes-genmodes-Do-not-use-__LINE__-for-maintainin.patch \
diff --git 
a/meta/recipes-devtools/gcc/gcc/0031-fix-segmentation-fault-in-precompiled-header-generat.patch
 
b/meta/recipes-devtools/gcc/gcc/0031-fix-segmentation-fault-in-precompiled-header-generat.patch
deleted file mode 100644
index 70afa4f9e95..000
--- 
a/meta/recipes-devtools/gcc/gcc/0031-fix-segmentation-fault-in-precompiled-header-generat.patch
+++ /dev/null
@@ -1,57 +0,0 @@
-From 3d59f763b824ac11f8360931092baf0bc1719562 Mon Sep 17 00:00:00 2001
-From: Juro Bystricky 
-Date: Mon, 19 Mar 2018 22:31:20 -0700
-Subject: [PATCH] fix segmentation fault in precompiled header generation
-
-Prevent a segmentation fault which occurs when using incorrect
-structure trying to access name of some named operators, such as
-CPP_NOT, CPP_AND etc. "token->val.node.spelling" cannot be used in
-those cases, as is may not be initialized at all.
-
-[YOCTO #11738]
-
-Upstream-Status: Pending
-
-Signed-off-by: Juro Bystricky 
-Signed-off-by: Khem Raj 

- libcpp/lex.c | 26 +-
- 1 file changed, 21 insertions(+), 5 deletions(-)
-
-diff --git a/libcpp/lex.c b/libcpp/lex.c
-index 06bcc31c87e..24bed9a35fa 100644
 a/libcpp/lex.c
-+++ b/libcpp/lex.c
-@@ -3531,11 +3531,27 @@ cpp_spell_token (cpp_reader *pfile, const cpp_token 
*token,
- spell_ident:
- case SPELL_IDENT:
-   if (forstring)
--  {
--memcpy (buffer, NODE_NAME (token->val.node.spelling),
--NODE_LEN (token->val.node.spelling));
--buffer += NODE_LEN (token->val.node.spelling);
--  }
-+{
-+  if (token->type == CPP_NAME)
-+{
-+  memcpy (buffer, NODE_NAME (token->val.node.spelling),
-+NODE_LEN (token->val.node.spelling));
-+  buffer += NODE_LEN (token->val.node.spelling);
-+  break;
-+}
-+  /* NAMED_OP, cannot use node.spelling */
-+  if (token->flags & NAMED_OP)
-+{
-+  const char *str = cpp_named_operator2name (token->type);
-+  if (str)
-+{
-+  size_t len = strlen(str);
-+  memcpy(buffer, str, len);
-+  buffer += len;
-+}
-+  break;
-+}
-+}
-   else
-   buffer = _cpp_spell_ident_ucns (buffer, token->val.node.node);
-   break;
-- 
2.32.0


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



[OE-core] [PATCH] python3: Add missing HOMEPAGE entries

2021-11-25 Thread Richard Purdie
Add missing HOMEPAGE entries to new python recipes from meta-python.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb   | 1 +
 meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb | 1 +
 meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb  | 1 +
 meta/recipes-devtools/python/python3-webcolors_1.11.1.bb| 1 +
 4 files changed, 4 insertions(+)

diff --git a/meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb 
b/meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb
index 80e2aa5bc26..ae0154080b8 100644
--- a/meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb
+++ b/meta/recipes-devtools/python/python3-rfc3987_1.3.8.bb
@@ -1,4 +1,5 @@
 SUMMARY = "Parsing and validation of URIs (RFC 3986) and IRIs (RFC 3987)"
+HOMEPAGE = "https://pypi.org/project/rfc3987/;
 LICENSE = "GPLv3+"
 LIC_FILES_CHKSUM = 
"file://PKG-INFO;beginline=8;endline=9;md5=2b723edf67b2f3088bc5e339b1ceda2d"
 
diff --git a/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb 
b/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb
index e64f1960046..35c79c40056 100644
--- a/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb
+++ b/meta/recipes-devtools/python/python3-ruamel-yaml_0.17.16.bb
@@ -1,4 +1,5 @@
 SUMMARY = "YAML parser/emitter that supports roundtrip preservation of 
comments, seq/map flow style, and map key order."
+HOMEPAGE = "https://pypi.org/project/ruamel.yaml/;
 AUTHOR = "Anthon van der Neut"
 
 LICENSE = "MIT"
diff --git a/meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb 
b/meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb
index 52ae9ebe9a2..aa2d5b46f05 100644
--- a/meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb
+++ b/meta/recipes-devtools/python/python3-strict-rfc3339_0.7.bb
@@ -1,4 +1,5 @@
 SUMMARY = "Strict, simple, lightweight RFC3339 function.s"
+HOMEPAGE = "https://pypi.org/project/strict-rfc3339/;
 LICENSE = "GPLv3"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=8f0e2cd40e05189ec81232da84bd6e1a"
 
diff --git a/meta/recipes-devtools/python/python3-webcolors_1.11.1.bb 
b/meta/recipes-devtools/python/python3-webcolors_1.11.1.bb
index 2ec036ef357..26dbe517671 100644
--- a/meta/recipes-devtools/python/python3-webcolors_1.11.1.bb
+++ b/meta/recipes-devtools/python/python3-webcolors_1.11.1.bb
@@ -1,4 +1,5 @@
 SUMMARY = "Simple Python module for working with HTML/CSS color definitions."
+HOMEPAGE = "https://pypi.org/project/webcolors/;
 LICENSE = "BSD-3-Clause"
 LIC_FILES_CHKSUM = "file://LICENSE;md5=25b90379a52351261c51272e7923d240"
 
-- 
2.32.0


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



[OE-core] [PATCH 3/3] gcc: Drop mips default ABI patch

2021-11-25 Thread Richard Purdie
gcc-configure-common.inc already sets --with-abi=64 for our mips64
targets so this patch is no longer needed.

[YOCTO #14639]

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-11.2.inc|  1 -
 .../gcc/0010-MIPS64-Default-to-N64-ABI.patch  | 54 ---
 2 files changed, 55 deletions(-)
 delete mode 100644 
meta/recipes-devtools/gcc/gcc/0010-MIPS64-Default-to-N64-ABI.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
b/meta/recipes-devtools/gcc/gcc-11.2.inc
index b4e4300c66b..afb8f2df5c2 100644
--- a/meta/recipes-devtools/gcc/gcc-11.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -36,7 +36,6 @@ SRC_URI = "\
file://0005-optional-libstdc.patch \

file://0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch \
file://0009-cpp-honor-sysroot.patch \
-   file://0010-MIPS64-Default-to-N64-ABI.patch \

file://0011-Define-GLIBC_DYNAMIC_LINKER-and-UCLIBC_DYNAMIC_LINKE.patch \
file://0012-gcc-Fix-argument-list-too-long-error.patch \
file://0014-libtool.patch \
diff --git a/meta/recipes-devtools/gcc/gcc/0010-MIPS64-Default-to-N64-ABI.patch 
b/meta/recipes-devtools/gcc/gcc/0010-MIPS64-Default-to-N64-ABI.patch
deleted file mode 100644
index f385f8c5a20..000
--- a/meta/recipes-devtools/gcc/gcc/0010-MIPS64-Default-to-N64-ABI.patch
+++ /dev/null
@@ -1,54 +0,0 @@
-From a2dc2fa4cc7e5d54544d4a7b6601eef79bc26cad Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 29 Mar 2013 09:23:08 +0400
-Subject: [PATCH] MIPS64: Default to N64 ABI
-
-MIPS64 defaults to n32 ABI, this patch makes it
-so that it defaults to N64 ABI
-
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Inappropriate [OE config specific]

- gcc/config.gcc | 10 +-
- 1 file changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/gcc/config.gcc b/gcc/config.gcc
-index 3ec7582f5dd..a046fa6945c 100644
 a/gcc/config.gcc
-+++ b/gcc/config.gcc
-@@ -2543,29 +2543,29 @@ mips*-*-linux*)# Linux 
MIPS, either endian.
-   default_mips_arch=mips32
-   ;;
-   mips64el-st-linux-gnu)
--  default_mips_abi=n32
-+  default_mips_abi=64
-   tm_file="${tm_file} mips/st.h"
-   tmake_file="${tmake_file} mips/t-st"
-   enable_mips_multilibs="yes"
-   ;;
-   mips64octeon*-*-linux*)
--  default_mips_abi=n32
-+  default_mips_abi=64
-   tm_defines="${tm_defines} 
MIPS_CPU_STRING_DEFAULT=\\\"octeon\\\""
-   target_cpu_default=MASK_SOFT_FLOAT_ABI
-   enable_mips_multilibs="yes"
-   ;;
-   mipsisa64r6*-*-linux*)
--  default_mips_abi=n32
-+  default_mips_abi=64
-   default_mips_arch=mips64r6
-   enable_mips_multilibs="yes"
-   ;;
-   mipsisa64r2*-*-linux*)
--  default_mips_abi=n32
-+  default_mips_abi=64
-   default_mips_arch=mips64r2
-   enable_mips_multilibs="yes"
-   ;;
-   mips64*-*-linux* | mipsisa64*-*-linux*)
--  default_mips_abi=n32
-+  default_mips_abi=64
-   enable_mips_multilibs="yes"
-   ;;
-   esac
-- 
2.32.0


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



[OE-core] [PATCH 1/3] nativesdk: Handle chown/chgrp calls in nativesdk do_install tasks

2021-11-25 Thread Richard Purdie
We disable the useradd code for nativesdk targets since we don't support
postinstalls or multiple users in those cases. This means any usage
of chown/chgrp inside do_install tasks won't work and would have to be
conditional. Rather than require all recipes to do that, add intercepts
of the calls and map those to root/root user/groups. We can't just ignore
them as some calls are used to remove host contamination from the host
user ID so they need to be made, just as root.

Signed-off-by: Richard Purdie 
---
 meta/classes/nativesdk.bbclass|  2 ++
 scripts/nativesdk-intercept/chgrp | 27 +++
 scripts/nativesdk-intercept/chown | 27 +++
 3 files changed, 56 insertions(+)
 create mode 100755 scripts/nativesdk-intercept/chgrp
 create mode 100755 scripts/nativesdk-intercept/chown

diff --git a/meta/classes/nativesdk.bbclass b/meta/classes/nativesdk.bbclass
index 14e210562f1..f8e96075134 100644
--- a/meta/classes/nativesdk.bbclass
+++ b/meta/classes/nativesdk.bbclass
@@ -113,3 +113,5 @@ do_packagedata[stamp-extra-info] = ""
 USE_NLS = "${SDKUSE_NLS}"
 
 OLDEST_KERNEL = "${SDK_OLDEST_KERNEL}"
+
+PATH:prepend = "${COREBASE}/scripts/nativesdk-intercept:"
diff --git a/scripts/nativesdk-intercept/chgrp 
b/scripts/nativesdk-intercept/chgrp
new file mode 100755
index 000..30cc417d3ac
--- /dev/null
+++ b/scripts/nativesdk-intercept/chgrp
@@ -0,0 +1,27 @@
+#!/usr/bin/env python3
+#
+# Wrapper around 'chgrp' that redirects to root in all cases
+
+import os
+import shutil
+import sys
+
+# calculate path to the real 'chgrp'
+path = os.environ['PATH']
+path = path.replace(os.path.dirname(sys.argv[0]), '')
+real_chgrp = shutil.which('chgrp', path=path)
+
+args = list()
+
+found = False
+for i in sys.argv:
+if i.startswith("-"):
+args.append(i)
+continue
+if not found:
+args.append("root")
+found = True
+else:
+args.append(i)
+
+os.execv(real_chgrp, args)
diff --git a/scripts/nativesdk-intercept/chown 
b/scripts/nativesdk-intercept/chown
new file mode 100755
index 000..3914b3e3841
--- /dev/null
+++ b/scripts/nativesdk-intercept/chown
@@ -0,0 +1,27 @@
+#!/usr/bin/env python3
+#
+# Wrapper around 'chown' that redirects to root in all cases
+
+import os
+import shutil
+import sys
+
+# calculate path to the real 'chown'
+path = os.environ['PATH']
+path = path.replace(os.path.dirname(sys.argv[0]), '')
+real_chown = shutil.which('chown', path=path)
+
+args = list()
+
+found = False
+for i in sys.argv:
+if i.startswith("-"):
+args.append(i)
+continue
+if not found:
+args.append("root:root")
+found = True
+else:
+args.append(i)
+
+os.execv(real_chown, args)
-- 
2.32.0


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



[OE-core] [PATCH 2/3] gcc: Drop no longer needed patch

2021-11-25 Thread Richard Purdie
This patch was mentioned upstream a long time ago:

https://gcc.gnu.org/bugzilla/show_bug.cgi?id=47256

Changes from gcc 10 onward mean it is no longer needed as mentioned in the
above bug report. Drop the patch.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc-11.2.inc|  1 -
 .../gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch| 35 ---
 2 files changed, 36 deletions(-)
 delete mode 100644 meta/recipes-devtools/gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch

diff --git a/meta/recipes-devtools/gcc/gcc-11.2.inc 
b/meta/recipes-devtools/gcc/gcc-11.2.inc
index baced2a4007..b4e4300c66b 100644
--- a/meta/recipes-devtools/gcc/gcc-11.2.inc
+++ b/meta/recipes-devtools/gcc/gcc-11.2.inc
@@ -34,7 +34,6 @@ SRC_URI = "\
file://0002-gcc-poison-system-directories.patch \
file://0004-64-bit-multilib-hack.patch \
file://0005-optional-libstdc.patch \
-   file://0006-COLLECT_GCC_OPTIONS.patch \

file://0007-Use-the-defaults.h-in-B-instead-of-S-and-t-oe-in-B.patch \
file://0009-cpp-honor-sysroot.patch \
file://0010-MIPS64-Default-to-N64-ABI.patch \
diff --git a/meta/recipes-devtools/gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch 
b/meta/recipes-devtools/gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch
deleted file mode 100644
index 265ca0e2187..000
--- a/meta/recipes-devtools/gcc/gcc/0006-COLLECT_GCC_OPTIONS.patch
+++ /dev/null
@@ -1,35 +0,0 @@
-From 127716a32a11ca2a6b3aac068054bfc69c4dcfd8 Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Fri, 29 Mar 2013 09:16:28 +0400
-Subject: [PATCH] COLLECT_GCC_OPTIONS
-
-This patch adds --sysroot into COLLECT_GCC_OPTIONS which is used to
-invoke collect2.
-
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Pending

- gcc/gcc.c | 9 +
- 1 file changed, 9 insertions(+)
-
-diff --git a/gcc/gcc.c b/gcc/gcc.c
-index be7630ffd8c..1bc45285384 100644
 a/gcc/gcc.c
-+++ b/gcc/gcc.c
-@@ -5383,6 +5383,15 @@ set_collect_gcc_options (void)
-   sizeof ("COLLECT_GCC_OPTIONS=") - 1);
- 
-   first_time = TRUE;
-+#ifdef HAVE_LD_SYSROOT
-+  if (target_system_root_changed && target_system_root)
-+{
-+  obstack_grow (_obstack, "'--sysroot=", sizeof("'--sysroot=")-1);
-+  obstack_grow (_obstack, 
target_system_root,strlen(target_system_root));
-+  obstack_grow (_obstack, "'", 1);
-+  first_time = FALSE;
-+}
-+#endif
-   for (i = 0; (int) i < n_switches; i++)
- {
-   const char *const *args;
-- 
2.32.0


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



Re: [OE-core] [bitbake-devel] [eo-core][PATCH v6 1/2] repo: Add recipe for 2.17.3

2021-11-24 Thread Richard Purdie
On Wed, 2021-11-24 at 19:35 +0100, Jasper Orschulko via lists.openembedded.org
wrote:
> From: Jasper Orschulko 
> 
> Add a recipe for repo 2.17.3, prerequisite for the repo fetcher.
> 
> Signed-off-by: Jasper Orschulko 
> ---
>  meta/conf/distro/include/maintainers.inc  |  1 +
>  .../0001-Set-REPO_REV-to-v2.17.3.patch| 35 +++
>  .../repo/repo/0001-python3-shebang.patch  | 26 ++
>  meta/recipes-devtools/repo/repo_2.17.3.bb | 28 +++
>  4 files changed, 90 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
>  create mode 100644 meta/recipes-devtools/repo/repo/0001-python3-shebang.patch
>  create mode 100644 meta/recipes-devtools/repo/repo_2.17.3.bb
> 
> 

I thought I'd try testing this. Unfortunately it doesn't build:

https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/1004/steps/13/logs/stdio

Cheers,

Richard



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



Re: [OE-core] [RFC PATCH 05/15] bitbake: fetch2: Support archives with missing search directory mode

2021-11-24 Thread Richard Purdie
On Wed, 2021-11-24 at 18:11 +0100, Stefan Herbrechtsmeier wrote:
> Am 24.11.2021 um 16:17 schrieb Alexander Kanavin:
> > Is it the missing x bit on directories? 
> 
> Yes.
> 
> https://registry.npmjs.org/protoc/-/protoc-1.0.4.tgz
> 
> 
> > If you've encountered this, then 
> > where did it happen,
> 
> cp: cannot stat 
> '.../git/ui/./node_modules/protoc/scripts/postinstall.js': Permission denied
> 
> > and shouldn't the tarball be fixed instead?
> 
> How should we fix a tarball from npmjs.com?
> 
> 
> Is such an influencing change acceptable or should I move the change to 
> the npm class?

We don't want to support that in the general case, that needs to be in the npm
class.

Cheers,

Richard


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



Re: [OE-core] [PATCH] meson: drop redundant patch

2021-11-24 Thread Richard Purdie
On Wed, 2021-11-24 at 10:17 +, Ross Burton wrote:
> On Tue, 23 Nov 2021 at 22:36, Richard Purdie
>  wrote:
> > On Tue, 2021-11-23 at 19:38 +, Ross Burton wrote:
> > > This patch disables the debian-detection to use the correct $libdir by
> > > default on that platform.  However in cross builds this is always
> > > overridden to be $prefix/lib, and all recipes that inherit meson pass
> > > the correct libdir explicitly.
> > > 
> > > Signed-off-by: Ross Burton 
> > > ---
> > >  meta/recipes-devtools/meson/meson.inc |  1 -
> > >  ...01-is_debianlike-always-return-False.patch | 26 ---
> > >  2 files changed, 27 deletions(-)
> > >  delete mode 100644 
> > > meta/recipes-devtools/meson/meson/0001-is_debianlike-always-return-False.patch
> > 
> > We build native things which are meson based. Do we want native tool libdir
> > paths depending on the existence of /etc/debian_version ? It was some reason
> > like that this was added as we found it doing 'fun' changes depending on the
> > host. Not sure I really want to debug that again...
> 
> Sure, and they pass --libdir.  I did a build of Sato and nothing
> moved, so I'm struggling to find the actual problem here.

Did we start setting libdir for native builds after that change merged?

I've spent half the last week chasing phantom issues so I'm just not feeling
keen on doing it with yet another issue but I guess we can queue this and wait
for something to break...

Cheers,

Richard


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



Re: [OE-core] [PATCH] insane.bbclass: do not hardcode oe-core path in upstream-status check

2021-11-24 Thread Richard Purdie
On Wed, 2021-11-24 at 10:25 +0100, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/classes/insane.bbclass | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/classes/insane.bbclass b/meta/classes/insane.bbclass
> index 240f3aad62..8a47da5a09 100644
> --- a/meta/classes/insane.bbclass
> +++ b/meta/classes/insane.bbclass
> @@ -1176,7 +1176,9 @@ python do_qa_patch() {
> (_, _, fullpath, _, _, _) = bb.fetch.decodeurl(url)
>  
> # skip patches not in oe-core
> -   if '/meta/' not in fullpath:
> +   oecore_re = re.compile(d.getVar('BBFILE_PATTERN_core'))
> +   match_oecore = oecore_re.search(fullpath)
> +   if not match_oecore:
> continue
>  

Does this pass the sstate tests? I have a feeling it may encode a path into the
sstate checksums :/

Cheers,

Richard


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



Re: [OE-core] [PATCH] native/cross: Add ar wrapper for determinism

2021-11-23 Thread Richard Purdie
On Tue, 2021-11-23 at 21:22 +0100, Jacob Kroon wrote:
> 
> On 11/23/21 15:12, Richard Purdie wrote:
> > From: Jacob Kroon 
> > 
> > Add a wrapper around ar calls for native/cross recipes. This wrapper adds
> > the -D option so that deterministic archives are built for native/cross
> > output. This improves the changes of hash equivalence matches and hence
> > build artefact reuse.
> > 
> > We don't need this in the target case since we compile binutils-cross
> > with an option making this the default. We need a wrapper since we need
> > to remove the "u" option and replace it with "D" but also allow things like
> > "--version" to continue to work too.
> > 
> > Signed-off-by: Jacob Kroon 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/classes/cross.bbclass  |  2 ++
> >  scripts/cross-intercept/ar  |  1 +
> >  scripts/native-intercept/ar | 29 +
> >  3 files changed, 32 insertions(+)
> >  create mode 12 scripts/cross-intercept/ar
> >  create mode 100755 scripts/native-intercept/ar
> > 
> > diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
> > index 3e6a2f60b9e..9d951076a78 100644
> > --- a/meta/classes/cross.bbclass
> > +++ b/meta/classes/cross.bbclass
> > @@ -93,3 +93,5 @@ python do_addto_recipe_sysroot () {
> >  }
> >  addtask addto_recipe_sysroot after do_populate_sysroot
> >  do_addto_recipe_sysroot[deptask] = "do_populate_sysroot"
> > +
> > +PATH:prepend = "${COREBASE}/scripts/cross-intercept:"
> > diff --git a/scripts/cross-intercept/ar b/scripts/cross-intercept/ar
> > new file mode 12
> > index 000..bc68ffd7a21
> > --- /dev/null
> > +++ b/scripts/cross-intercept/ar
> > @@ -0,0 +1 @@
> > +../native-intercept/ar
> > \ No newline at end of file
> > diff --git a/scripts/native-intercept/ar b/scripts/native-intercept/ar
> > new file mode 100755
> > index 000..642b6eae864
> > --- /dev/null
> > +++ b/scripts/native-intercept/ar
> > @@ -0,0 +1,29 @@
> > +#!/usr/bin/env python3
> > +#
> > +# Wrapper around 'ar' that defaults to deterministic archives
> > +
> > +import os
> > +import shutil
> > +import sys
> > +
> > +# calculate path to the real 'ar'
> > +path = os.environ['PATH']
> > +path = path.replace(os.path.dirname(sys.argv[0]), '')
> > +real_ar = shutil.which('ar', path=path)
> > +
> > +if len(sys.argv) == 1:
> > +os.execl(real_ar, 'ar')
> > +
> > +# modify args to mimic 'ar' configured with 
> > --default-deterministic-archives
> > +argv = sys.argv
> > +if argv[1].startswith('--'):
> > +# No modifier given
> > +None
> > +else:
> > +# remove the optional '-'
> > +if argv[1][0] == '-':
> > +argv[1] = argv[1][1:]
> > +argv[1] = argv[1].replace('u', '')
> > +argv[1] = 'D' + argv[1]
> > +
> > +os.execv(real_ar, argv)
> > 
> 
> What should we do if the user is explicitly passing U, "Do not operate
> in deterministic mode." ? Don't replace any 'u' and don't pass D ?

That would seem to make sense to me...

Cheers,

Richard


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



Re: [OE-core] [PATCHv3] waffle: add explicit dependency to cmake-native

2021-11-23 Thread Richard Purdie
On Tue, 2021-11-23 at 12:00 -0600, Anibal Limon wrote:
> Hi,
> 
> Is this patch good enough? or need another change.

There was feedback about the commit message needing work. Someone else also sent
a similar patch with a commit message with the right explanation in it so that
was merged in preference but the issue should be fixed.

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=50e0aed0684526c74072ceaf8fa52964c9cc0d19

Cheers,

Richard


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



Re: [OE-core] [PATCH] meson: drop redundant patch

2021-11-23 Thread Richard Purdie
On Tue, 2021-11-23 at 19:38 +, Ross Burton wrote:
> This patch disables the debian-detection to use the correct $libdir by
> default on that platform.  However in cross builds this is always
> overridden to be $prefix/lib, and all recipes that inherit meson pass
> the correct libdir explicitly.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-devtools/meson/meson.inc |  1 -
>  ...01-is_debianlike-always-return-False.patch | 26 ---
>  2 files changed, 27 deletions(-)
>  delete mode 100644 
> meta/recipes-devtools/meson/meson/0001-is_debianlike-always-return-False.patch

We build native things which are meson based. Do we want native tool libdir
paths depending on the existence of /etc/debian_version ? It was some reason
like that this was added as we found it doing 'fun' changes depending on the
host. Not sure I really want to debug that again...

Cheers,

Richard




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



Re: [OE-core] [PATCH] glibc: Fix i586/c3 support

2021-11-23 Thread Richard Purdie
On Tue, 2021-11-23 at 09:13 -0800, Khem Raj wrote:
> 
> On 11/23/21 8:55 AM, Richard Purdie wrote:
> > CET can't be enabled on i586 or c3 for x86, adjust the configuration 
> > accordingly
> > to fix those builds.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >   meta/recipes-core/glibc/glibc_2.34.bb | 2 +-
> >   1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-core/glibc/glibc_2.34.bb 
> > b/meta/recipes-core/glibc/glibc_2.34.bb
> > index 72064772789..7efc1ec1ef7 100644
> > --- a/meta/recipes-core/glibc/glibc_2.34.bb
> > +++ b/meta/recipes-core/glibc/glibc_2.34.bb
> > @@ -90,7 +90,7 @@ EXTRA_OECONF = "--enable-kernel=${OLDEST_KERNEL} \
> >   
> >   EXTRA_OECONF += "${@get_libc_fpu_setting(bb, d)}"
> >   
> > -EXTRA_OECONF:append:x86 = " --enable-cet"
> > +EXTRA_OECONF:append:x86 = " ${@bb.utils.contains_any('TUNE_FEATURES', 
> > 'i586 c3', '--disable-cet', '--enable-cet', d)}"
> 
> does this make glibc tune specific now ?

glibc is compiled so it is already tune specific :)

Cheers,

Richard


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



Re: [OE-core] [qa-build-notification] [yocto] QA notification for completed autobuilder build (yocto-3.1.12.rc1)

2021-11-23 Thread Richard Purdie
On Tue, 2021-11-23 at 11:54 +, Teoh, Jay Shen wrote:
> This is the full report for yocto-3.1.12.rc1:  
> https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
> 
> === Summary 
> No high milestone defects. 
> 
> new issue found 
> 
> Bug 14622 - bsps-hw.bsps-hw.Test_Seek_bar_and_volume_control manual test case 
> failure
>
> === Bugs 
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=14622
> 
> Thanks,
> Jay

Thanks Jay.

The TSC discussed 3.1.12 and are happy for rc1 to be released.

Cheers,

Richard


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



[OE-core] [PATCH] glibc: Fix i586/c3 support

2021-11-23 Thread Richard Purdie
CET can't be enabled on i586 or c3 for x86, adjust the configuration accordingly
to fix those builds.

Signed-off-by: Richard Purdie 
---
 meta/recipes-core/glibc/glibc_2.34.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/glibc/glibc_2.34.bb 
b/meta/recipes-core/glibc/glibc_2.34.bb
index 72064772789..7efc1ec1ef7 100644
--- a/meta/recipes-core/glibc/glibc_2.34.bb
+++ b/meta/recipes-core/glibc/glibc_2.34.bb
@@ -90,7 +90,7 @@ EXTRA_OECONF = "--enable-kernel=${OLDEST_KERNEL} \
 
 EXTRA_OECONF += "${@get_libc_fpu_setting(bb, d)}"
 
-EXTRA_OECONF:append:x86 = " --enable-cet"
+EXTRA_OECONF:append:x86 = " ${@bb.utils.contains_any('TUNE_FEATURES', 'i586 
c3', '--disable-cet', '--enable-cet', d)}"
 EXTRA_OECONF:append:x86-64 = " --enable-cet"
 
 PACKAGECONFIG ??= "nscd memory-tagging"
-- 
2.32.0


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



[OE-core] [PATCH] native/cross: Add ar wrapper for determinism

2021-11-23 Thread Richard Purdie
From: Jacob Kroon 

Add a wrapper around ar calls for native/cross recipes. This wrapper adds
the -D option so that deterministic archives are built for native/cross
output. This improves the changes of hash equivalence matches and hence
build artefact reuse.

We don't need this in the target case since we compile binutils-cross
with an option making this the default. We need a wrapper since we need
to remove the "u" option and replace it with "D" but also allow things like
"--version" to continue to work too.

Signed-off-by: Jacob Kroon 
Signed-off-by: Richard Purdie 
---
 meta/classes/cross.bbclass  |  2 ++
 scripts/cross-intercept/ar  |  1 +
 scripts/native-intercept/ar | 29 +
 3 files changed, 32 insertions(+)
 create mode 12 scripts/cross-intercept/ar
 create mode 100755 scripts/native-intercept/ar

diff --git a/meta/classes/cross.bbclass b/meta/classes/cross.bbclass
index 3e6a2f60b9e..9d951076a78 100644
--- a/meta/classes/cross.bbclass
+++ b/meta/classes/cross.bbclass
@@ -93,3 +93,5 @@ python do_addto_recipe_sysroot () {
 }
 addtask addto_recipe_sysroot after do_populate_sysroot
 do_addto_recipe_sysroot[deptask] = "do_populate_sysroot"
+
+PATH:prepend = "${COREBASE}/scripts/cross-intercept:"
diff --git a/scripts/cross-intercept/ar b/scripts/cross-intercept/ar
new file mode 12
index 000..bc68ffd7a21
--- /dev/null
+++ b/scripts/cross-intercept/ar
@@ -0,0 +1 @@
+../native-intercept/ar
\ No newline at end of file
diff --git a/scripts/native-intercept/ar b/scripts/native-intercept/ar
new file mode 100755
index 000..642b6eae864
--- /dev/null
+++ b/scripts/native-intercept/ar
@@ -0,0 +1,29 @@
+#!/usr/bin/env python3
+#
+# Wrapper around 'ar' that defaults to deterministic archives
+
+import os
+import shutil
+import sys
+
+# calculate path to the real 'ar'
+path = os.environ['PATH']
+path = path.replace(os.path.dirname(sys.argv[0]), '')
+real_ar = shutil.which('ar', path=path)
+
+if len(sys.argv) == 1:
+os.execl(real_ar, 'ar')
+
+# modify args to mimic 'ar' configured with --default-deterministic-archives
+argv = sys.argv
+if argv[1].startswith('--'):
+# No modifier given
+None
+else:
+# remove the optional '-'
+if argv[1][0] == '-':
+argv[1] = argv[1][1:]
+argv[1] = argv[1].replace('u', '')
+argv[1] = 'D' + argv[1]
+
+os.execv(real_ar, argv)
-- 
2.32.0


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



[OE-core] [PATCH] bitbake.conf: Pass -D option to ranlib for determisim

2021-11-23 Thread Richard Purdie
Add the -D option to BUILD_RANLIB so that deterministic archives
are built for native/cross output. This improves the changes of hash
equivalence matches and hence build artefact reuse.

We don't need this in the target case since we compile binutils-cross
with an option making this the default.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 71c1e52ad63..fba99e8f0cd 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -542,7 +542,7 @@ export BUILD_LD = "${BUILD_PREFIX}ld ${BUILD_LD_ARCH}"
 export BUILD_CCLD = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
 export BUILD_AR = "${BUILD_PREFIX}ar"
 export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
-export BUILD_RANLIB = "${BUILD_PREFIX}ranlib"
+export BUILD_RANLIB = "${BUILD_PREFIX}ranlib -D"
 export BUILD_STRIP = "${BUILD_PREFIX}strip"
 BUILD_OBJCOPY = "${BUILD_PREFIX}objcopy"
 BUILD_OBJDUMP = "${BUILD_PREFIX}objdump"
-- 
2.32.0


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



[OE-core] [PATCH] bitbake.conf: Pass -D option to ranlib for determisim

2021-11-23 Thread Richard Purdie
Add the -D option to BUILD_RANLIB so that deterministic archives
are built for native/cross output. This improves the changes of hash
equivalence matches and hence build artefact reuse.

We don't need this in the target case since we compile binutils-cross
with an option making this the default.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index 71c1e52ad63..fba99e8f0cd 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -542,7 +542,7 @@ export BUILD_LD = "${BUILD_PREFIX}ld ${BUILD_LD_ARCH}"
 export BUILD_CCLD = "${BUILD_PREFIX}gcc ${BUILD_CC_ARCH}"
 export BUILD_AR = "${BUILD_PREFIX}ar"
 export BUILD_AS = "${BUILD_PREFIX}as ${BUILD_AS_ARCH}"
-export BUILD_RANLIB = "${BUILD_PREFIX}ranlib"
+export BUILD_RANLIB = "${BUILD_PREFIX}ranlib -D"
 export BUILD_STRIP = "${BUILD_PREFIX}strip"
 BUILD_OBJCOPY = "${BUILD_PREFIX}objcopy"
 BUILD_OBJDUMP = "${BUILD_PREFIX}objdump"
-- 
2.32.0


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



[OE-core] [PATCH] buildhistory: Fix do_package race issues

2021-11-23 Thread Richard Purdie
The buildhistory_list_pkg_files function uses data from do_package, not
do_packagedata. Usally the two are restored together but it may see
a half complete directory or other races issues depending on timing.

Rework the function so that it uses the correct task dependencies. This
should avoid races but means the data is only restored to buildhistory
if the do_package or do_package_setscene tasks are restored.

Signed-off-by: Richard Purdie 
---
 meta/classes/buildhistory.bbclass | 12 
 1 file changed, 8 insertions(+), 4 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 64df432f136..daa96f3b63b 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -91,13 +91,19 @@ buildhistory_emit_sysroot() {
 python buildhistory_emit_pkghistory() {
 if d.getVar('BB_CURRENTTASK') in ['populate_sysroot', 
'populate_sysroot_setscene']:
 bb.build.exec_func("buildhistory_emit_sysroot", d)
-
-if not d.getVar('BB_CURRENTTASK') in ['packagedata', 
'packagedata_setscene']:
 return 0
 
 if not "package" in (d.getVar('BUILDHISTORY_FEATURES') or "").split():
 return 0
 
+if d.getVar('BB_CURRENTTASK') in ['package', 'package_setscene']:
+# Create files-in-.txt files containing a list of files 
of each recipe's package
+bb.build.exec_func("buildhistory_list_pkg_files", d)
+return 0
+
+if not d.getVar('BB_CURRENTTASK') in ['packagedata', 
'packagedata_setscene']:
+return 0
+
 import re
 import json
 import shlex
@@ -319,8 +325,6 @@ python buildhistory_emit_pkghistory() {
 
 write_pkghistory(pkginfo, d)
 
-# Create files-in-.txt files containing a list of files of 
each recipe's package
-bb.build.exec_func("buildhistory_list_pkg_files", d)
 oe.qa.exit_if_errors(d)
 }
 
-- 
2.32.0


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



[OE-core] [PATCH 2/2] buildhistory: Fix srcrevs output

2021-11-22 Thread Richard Purdie
The code was assuming that the a recipe with only one srcrev wouldn't "name"
it. This isn't the case as the glibc or bzip2 recipes show, you can have
a single srcrev which is named.

We can pull the data from the fetcher and in fact we already have it, we just
need to handle the "default" case and make that code the default for all srcrev
regardless of length.

[YOCTO #14017]

Signed-off-by: Richard Purdie 
---
 meta/classes/buildhistory.bbclass | 30 +-
 1 file changed, 13 insertions(+), 17 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index e62b45ab7d2..a230a0c2a2e 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -969,23 +969,19 @@ def write_latest_srcrev(d, pkghistdir):
 value = value.replace('"', '').strip()
 old_tag_srcrevs[key] = value
 with open(srcrevfile, 'w') as f:
-orig_srcrev = d.getVar('SRCREV', False) or 'INVALID'
-if orig_srcrev != 'INVALID':
-f.write('# SRCREV = "%s"\n' % orig_srcrev)
-if len(srcrevs) > 1:
-for name, srcrev in sorted(srcrevs.items()):
-orig_srcrev = d.getVar('SRCREV_%s' % name, False)
-if orig_srcrev:
-f.write('# SRCREV_%s = "%s"\n' % (name, orig_srcrev))
-f.write('SRCREV_%s = "%s"\n' % (name, srcrev))
-else:
-f.write('SRCREV = "%s"\n' % next(iter(srcrevs.values(
-if len(tag_srcrevs) > 0:
-for name, srcrev in sorted(tag_srcrevs.items()):
-f.write('# tag_%s = "%s"\n' % (name, srcrev))
-if name in old_tag_srcrevs and old_tag_srcrevs[name] != 
srcrev:
-pkg = d.getVar('PN')
-bb.warn("Revision for tag %s in package %s was changed 
since last build (from %s to %s)" % (name, pkg, old_tag_srcrevs[name], srcrev))
+for name, srcrev in sorted(srcrevs.items()):
+suffix = "_" + name
+if name == "default":
+suffix = ""
+orig_srcrev = d.getVar('SRCREV%s' % suffix, False)
+if orig_srcrev:
+f.write('# SRCREV%s = "%s"\n' % (suffix, orig_srcrev))
+f.write('SRCREV%s = "%s"\n' % (suffix, srcrev))
+for name, srcrev in sorted(tag_srcrevs.items()):
+f.write('# tag_%s = "%s"\n' % (name, srcrev))
+if name in old_tag_srcrevs and old_tag_srcrevs[name] != srcrev:
+pkg = d.getVar('PN')
+bb.warn("Revision for tag %s in package %s was changed 
since last build (from %s to %s)" % (name, pkg, old_tag_srcrevs[name], srcrev))
 
 else:
 if os.path.exists(srcrevfile):
-- 
2.32.0


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



[OE-core] [PATCH 1/2] buildhistory: Drop support for older bitbakes

2021-11-22 Thread Richard Purdie
We've bumped the minimum bitbake version past the point this fallback code
was needed, drop it.

Signed-off-by: Richard Purdie 
---
 meta/classes/buildhistory.bbclass | 12 +---
 1 file changed, 1 insertion(+), 11 deletions(-)

diff --git a/meta/classes/buildhistory.bbclass 
b/meta/classes/buildhistory.bbclass
index 7c44fec2d18..e62b45ab7d2 100644
--- a/meta/classes/buildhistory.bbclass
+++ b/meta/classes/buildhistory.bbclass
@@ -933,22 +933,12 @@ def _get_srcrev_values(d):
 if urldata[u].method.supports_srcrev():
 scms.append(u)
 
-autoinc_templ = 'AUTOINC+'
 dict_srcrevs = {}
 dict_tag_srcrevs = {}
 for scm in scms:
 ud = urldata[scm]
 for name in ud.names:
-try:
-rev = ud.method.sortable_revision(ud, d, name)
-except TypeError:
-# support old bitbake versions
-rev = ud.method.sortable_revision(scm, ud, d, name)
-# Clean this up when we next bump bitbake version
-if type(rev) != str:
-autoinc, rev = rev
-elif rev.startswith(autoinc_templ):
-rev = rev[len(autoinc_templ):]
+autoinc, rev = ud.method.sortable_revision(ud, d, name)
 dict_srcrevs[name] = rev
 if 'tag' in ud.parm:
 tag = ud.parm['tag'];
-- 
2.32.0


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



Re: [OE-core] [PATCH v2 1/7] systemd: skip chown when building for nativesdk

2021-11-22 Thread Richard Purdie
On Fri, 2021-11-19 at 11:34 +, Luca Bocassi wrote:
> From: Luca Boccassi 
> 
> The useradd class is a no-op in the nativesdk case, so chown will fail.
> Skip them.
> 
> Signed-off-by: Luca Boccassi 
> ---
> v2: use "${PN}" = "${BPN}" as suggested by reviewers

I think that was bad advice since this would break multilib variants of the
systemd recipe and I'd much prefer this was conditional on nativesdk.

>  meta/recipes-core/systemd/systemd_249.5.bb | 10 --
>  1 file changed, 8 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/recipes-core/systemd/systemd_249.5.bb 
> b/meta/recipes-core/systemd/systemd_249.5.bb
> index 8bdc0ca028..2df2de0cf3 100644
> --- a/meta/recipes-core/systemd/systemd_249.5.bb
> +++ b/meta/recipes-core/systemd/systemd_249.5.bb
> @@ -275,7 +275,10 @@ do_install() {
>   # which is expected to be empty.
>   rm -rf ${D}${localstatedir}/log
>   else
> - chown root:systemd-journal ${D}${localstatedir}/log/journal
> + # The useradd class is a no-op in the nativesdk case, so chown 
> will fail
> + if [ "${PN}" = "${BPN}" ]; then
> + chown root:systemd-journal 
> ${D}${localstatedir}/log/journal
> + fi
>  
>   # journal-remote creates this at start
>   rm -rf ${D}${localstatedir}/log/journal/remote


I'm guessing this is only failing on systems that don't have a systemd-jounral
group as it built ok for me?

The better way to fix this is probably to replicate what we have for native,
i.e. the entry in the class:

native.bbclass:PATH:prepend = "${COREBASE}/scripts/native-intercept:"

which puts a chown and chgrp into PATH which doesn't do anything. We could do
something similar for nativesdk and it would avoid the need for these if
statements and solve the problem generically.

I am also a bit concerned about some of the other "creeping" dependencies so I
experimented a little with master to see how much it could be cut down. I could
get working builds with the lines below:

"""
PACKAGECONFIG:remove:class-native = "vconsole xkbcommon sysvinit"
PACKAGECONFIG:append:class-native = " serial-getty-generator"
RDEPENDS:${PN}:remove:class-native = "volatile-binds"
RRECOMMENDS:${PN}:remove:class-native = "os-release systemd-conf"
RRECOMMENDS:${PN}-vconsole-setup:class-native = ""

PACKAGECONFIG:remove:class-nativesdk = "vconsole xkbcommon sysvinit"
PACKAGECONFIG:append:class-nativesdk = " serial-getty-generator"
RDEPENDS:${PN}:remove:class-nativesdk = "volatile-binds"
RRECOMMENDS:${PN}:remove:class-nativesdk = "os-release systemd-conf"
RRECOMMENDS:${PN}-vconsole-setup:class-nativesdk = ""

# Nothing picks up /var in the nativesdk case
do_install:append:class-nativesdk () {
   rm -rf ${D}/var
}

BBCLASSEXTEND = "native nativesdk"
"""

which removes the need to change os-release, kbd, systemd-conf and systemd-
getty. To merge, we'd want to restructure this to alter the variable
construction so we can avoid the use of the remove operator but it is an easy
way to test and evaluate the extent of changes needed.

The above also nearly has native builds working as well. To get that to build I
had to patch meson.build:

Index: git/meson.build
===
--- git.orig/meson.buildIndex: git/meson.build
===
--- git.orig/meson.build
+++ git/meson.build
@@ -745,7 +745,7 @@ conf.set('CONTAINER_UID_BASE_MAX', conta
 nobody_user = get_option('nobody-user')
 nobody_group = get_option('nobody-group')
 
-if not meson.is_cross_build()
+if false and not meson.is_cross_build()
 getent_result = run_command('getent', 'passwd', '65534')
 if getent_result.returncode() == 0
 name = getent_result.stdout().split(':')[0]

since we want to use the "cross" codepath there regardless. That lets everything
build but I did then see errors due to absolute path symlinks which would likely
be fixable.

I did this mainly as I wanted to understand how much of systemd is being build
and packaged since many of these packages will not make sense in a SDK or a
native build. I think the final piece of patch which we'd need to be able to
merge something like this is to trim down what is being packaged up to the
pieces which are actually useful in the native or nativesdk cases.

Cheers,

Richard






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



Re: [OE-core] [PATCH v2 4/7] systemd: remove volatile-binds RDEPENDS for nativesdk

2021-11-22 Thread Richard Purdie
On Fri, 2021-11-19 at 11:34 +, Luca Bocassi wrote:
> From: Luca Boccassi 
> 
> Not needed for SDK binaries
> 
> Signed-off-by: Luca Boccassi 
> ---
> v2: remove dependency instead of adding nativesdk to volatile-binds
> 
>  meta/recipes-core/systemd/systemd_249.5.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-core/systemd/systemd_249.5.bb 
> b/meta/recipes-core/systemd/systemd_249.5.bb
> index 9993036aac..2928a85c93 100644
> --- a/meta/recipes-core/systemd/systemd_249.5.bb
> +++ b/meta/recipes-core/systemd/systemd_249.5.bb
> @@ -644,6 +644,7 @@ FILES:${PN}-dev += "${base_libdir}/security/*.la 
> ${datadir}/dbus-1/interfaces/ $
>  RDEPENDS:${PN} += "kmod dbus util-linux-mount util-linux-umount udev (= 
> ${EXTENDPKGV}) systemd-udev-rules util-linux-agetty util-linux-fsck"
>  RDEPENDS:${PN} += "${@bb.utils.contains('PACKAGECONFIG', 
> 'serial-getty-generator', '', 'systemd-serialgetty', d)}"
>  RDEPENDS:${PN} += "volatile-binds"
> +RDEPENDS_${PN}_remove_class-nativesdk = "volatile-binds"
>  
>  RRECOMMENDS:${PN} += "systemd-extra-utils \
>udev-hwdb \

This patch raises a few questions like how this is being tested?

The override syntax changed so the avoid would never have worked with master.

Also, I have a strong preference for not using remove operators in OE-Core, you
can usually rearrange things so that it isn't necessary. The reason for that is
that it is very hard to override these operations. I know we do have some but
minimising them is good.

Cheers,

Richard


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



Re: [OE-core] [PATCH 2/2] core-image-base: Remove psplash from required features

2021-11-21 Thread Richard Purdie
On Sat, 2021-11-20 at 10:05 -0800, Khem Raj wrote:
> base-image boots in degraded mode when using systems without display
> system since there is no fb device detected and pslash service would
> fail to start. Removing this image feature means that core-image-base is
> complete for headless devices
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/images/core-image-base.bb | 2 --
>  1 file changed, 2 deletions(-)
> 
> diff --git a/meta/recipes-core/images/core-image-base.bb 
> b/meta/recipes-core/images/core-image-base.bb
> index 75a08cfc92a..ced8de6c14f 100644
> --- a/meta/recipes-core/images/core-image-base.bb
> +++ b/meta/recipes-core/images/core-image-base.bb
> @@ -1,8 +1,6 @@
>  SUMMARY = "A console-only image that fully supports the target device \
>  hardware."
>  
> -IMAGE_FEATURES += "splash"
> -
>  LICENSE = "MIT"
>  
>  inherit core-image

I think the way this was originally intended to work was to have a
MACHINE_FEATURE which represented the possibility of a display, then the image
could configure itself accordingly. Removing features from images to the lowest
common denominator of any given hardware doesn't seem like the correct thing to
do...

Cheers,

Richard


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



Re: [OE-core] [PATCH 02/36] groff: mark patch as non-upstreamable

2021-11-19 Thread Richard Purdie
On Fri, 2021-11-19 at 13:08 +0100, Alexander Kanavin wrote:
> I checked; the patches are the same, except the upstream one misses one file,
> which is fixed in a different upstream patch. I'd say we can keep things as
> they are.

Can we mark as a backport of those two commits then?

Cheers,

Richard




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



Re: [OE-core] [PATCH 02/36] groff: mark patch as non-upstreamable

2021-11-19 Thread Richard Purdie
On Wed, 2021-11-17 at 16:34 +0100, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-extended/groff/files/0001-Include-config.h.patch | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-extended/groff/files/0001-Include-config.h.patch 
> b/meta/recipes-extended/groff/files/0001-Include-config.h.patch
> index 46065bc513..34fca1eb2f 100644
> --- a/meta/recipes-extended/groff/files/0001-Include-config.h.patch
> +++ b/meta/recipes-extended/groff/files/0001-Include-config.h.patch
> @@ -20,7 +20,7 @@ In file included from 
> TOPDIR/build/tmp/work/aarch64-yoe-linux-musl/groff/1.22.4-
>  We delete eqn.cpp and qen.hpp in do_configure
>  to ensure they're regenerated and deterministic.
>  
> -Upstream-Status: Pending
> +Upstream-Status: Inappropriate [issue fixed upstream with a similar patch]
>  Signed-off-by: Khem Raj 
>  ---
>   src/libs/libgroff/assert.cpp  |   4 +


Should we replace this with the upstream patch? That way we'd have a clean
backport which would help at upgrade time? 

Is the upstream patch exactly functionally equivalent?

Sometimes it can be good to test the upstream version so we know come upgrade
time we're ok and we don't need to ask upstream to make any further tweaks.

Cheers,

Richard


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



[OE-core] [PATCH] gcc: Tweak Upstream-Status formatting

2021-11-19 Thread Richard Purdie
Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/gcc/gcc/0001-CVE-2021-35465.patch | 2 +-
 meta/recipes-devtools/gcc/gcc/0002-CVE-2021-35465.patch | 2 +-
 meta/recipes-devtools/gcc/gcc/0003-CVE-2021-35465.patch | 2 +-
 meta/recipes-devtools/gcc/gcc/0004-CVE-2021-35465.patch | 2 +-
 4 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/recipes-devtools/gcc/gcc/0001-CVE-2021-35465.patch 
b/meta/recipes-devtools/gcc/gcc/0001-CVE-2021-35465.patch
index 6b1d4e3fce4..e4aee10e370 100644
--- a/meta/recipes-devtools/gcc/gcc/0001-CVE-2021-35465.patch
+++ b/meta/recipes-devtools/gcc/gcc/0001-CVE-2021-35465.patch
@@ -20,7 +20,7 @@ gcc:
the command line.
 
 CVE: CVE-2021-35465
-Upstream-Status: 
Backport[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3929bca9ca95de9d35e82ae8828b188029e3eb70]
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=3929bca9ca95de9d35e82ae8828b188029e3eb70]
 Signed-off-by: Pgowda 
 
 ---
diff --git a/meta/recipes-devtools/gcc/gcc/0002-CVE-2021-35465.patch 
b/meta/recipes-devtools/gcc/gcc/0002-CVE-2021-35465.patch
index 98841e6d7c1..e09818fecf7 100644
--- a/meta/recipes-devtools/gcc/gcc/0002-CVE-2021-35465.patch
+++ b/meta/recipes-devtools/gcc/gcc/0002-CVE-2021-35465.patch
@@ -15,7 +15,7 @@ libgcc:
Add vlldm erratum work-around.
 
 CVE: CVE-2021-35465
-Upstream-Status: 
Backport[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=574e7950bd6b34e9e2cacce18c802b45505d1d0a]
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=574e7950bd6b34e9e2cacce18c802b45505d1d0a]
 Signed-off-by: Pgowda 
 
 ---
diff --git a/meta/recipes-devtools/gcc/gcc/0003-CVE-2021-35465.patch 
b/meta/recipes-devtools/gcc/gcc/0003-CVE-2021-35465.patch
index d87be198669..c7a7c76bf87 100644
--- a/meta/recipes-devtools/gcc/gcc/0003-CVE-2021-35465.patch
+++ b/meta/recipes-devtools/gcc/gcc/0003-CVE-2021-35465.patch
@@ -16,7 +16,7 @@ gcc:
use when erratum mitigation is needed.
 
 CVE: CVE-2021-35465
-Upstream-Status: 
Backport[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=30461cf8dba3d3adb15a125e4da48800eb2b9b8f]
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=30461cf8dba3d3adb15a125e4da48800eb2b9b8f]
 Signed-off-by: Pgowda 
 
 ---
diff --git a/meta/recipes-devtools/gcc/gcc/0004-CVE-2021-35465.patch 
b/meta/recipes-devtools/gcc/gcc/0004-CVE-2021-35465.patch
index 12dfe682fa7..9dd6a313c2d 100644
--- a/meta/recipes-devtools/gcc/gcc/0004-CVE-2021-35465.patch
+++ b/meta/recipes-devtools/gcc/gcc/0004-CVE-2021-35465.patch
@@ -17,7 +17,7 @@ gcc/testsuite:
* gcc.target/arm/cmse/mainline/8_1m/softfp/cmse-8a.c: Likewise.
 
 CVE: CVE-2021-35465
-Upstream-Status: 
Backport[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=809330ab8450261e05919b472783bf15e4b000f7]
+Upstream-Status: Backport 
[https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=809330ab8450261e05919b472783bf15e4b000f7]
 Signed-off-by: Pgowda 
 
 ---
-- 
2.32.0


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



Re: [OE-core] [PATCH] buildhistory.bbclass: fix regression from FILES_INFO changes

2021-11-19 Thread Richard Purdie
On Tue, 2021-11-16 at 17:06 -0800, S. Lockwood-Childs wrote:
> Started getting a stack trace during packagedata task for a
> recipe that built fine in hardknott
> 
>  *** 0002:buildhistory_emit_pkghistory(d)
>  0003:
> File: 'meta/classes/buildhistory.bbclass', lineno: 313, function: 
> buildhistory_emit_pkghistory
>  0309:pkginfo.filevars[filevar] = localdata.getVar(filevar) 
> or ""
>  0310:
>  0311:# Gather information about packaged files
>  0312:val = localdata.getVar('FILES_INFO') or ''
>  *** 0313:dictval = json.loads(val)
>  0314:filelist = list(dictval.keys())
>  0315:filelist.sort()
>  0316:pkginfo.filelist = " ".join([shlex.quote(x) for x in 
> filelist])
>  ...
>  Exception: json.decoder.JSONDecodeError: Expecting value: line 1 column 1 
> (char 0)
> 
> which turns out to mean FILES_INFO is undefined for the main package built by
> this recipe (FILES_INFO lookup for other packages such as -dev seemed to work 
> fine).
> 
> Tracked the regression down to this commit:
> package/scripts: Fix FILES_INFO handling
> OE-Core rev: a1190903e0a61a12c9854c96af918ae8d12c6327
> 
> If buildhistory.bbclass uses the same per-package syntax to read
> FILES_INFO as package.bbclass uses now when setting it, then
> this regression goes away.
> 
> Signed-off-by: S. Lockwood-Childs 
> ---
>  meta/classes/buildhistory.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/buildhistory.bbclass 
> b/meta/classes/buildhistory.bbclass
> index 7c44fec2d1..99300ab431 100644
> --- a/meta/classes/buildhistory.bbclass
> +++ b/meta/classes/buildhistory.bbclass
> @@ -309,7 +309,7 @@ python buildhistory_emit_pkghistory() {
>  pkginfo.filevars[filevar] = localdata.getVar(filevar) or ""
>  
>  # Gather information about packaged files
> -val = localdata.getVar('FILES_INFO') or ''
> +val = localdata.getVar('FILES_INFO:%s' % pkg) or ''
>  dictval = json.loads(val)
>  filelist = list(dictval.keys())
>  filelist.sort()

Which revision of the project are you seeing that on? This shouldn't be needed
since a number of lines above there it says:

localdata.setVar('OVERRIDES', d.getVar("OVERRIDES", False) + ":" + pkg)

i.e. pkg is in OVERRIDES and therefore FILES_INFO should be FILES_INFO:pkg if
that is set.

I think this is masking some other issue and isn't the correct fix.

Cheers,

Richard





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



Re: [OE-core] [PATCH 6/8] kbd: add nativesdk

2021-11-17 Thread Richard Purdie
On Wed, 2021-11-17 at 12:31 +, Luca Bocassi wrote:
> From: Luca Boccassi 
> 
> Required to build systemd tools

If systemd needs these to build, wouldn't it be depending on kbd-native?

Or are you saying that systemd-tools needs something in here at runtime?

I don't mind extending the recipe if we really need it but that isn't what the
commit message says so at the very least that needs to be clearer.

Cheers,

Richard


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



Re: [OE-core] [PATCH 5/8] volatile-binds: add nativesdk

2021-11-17 Thread Richard Purdie
On Wed, 2021-11-17 at 12:31 +, Luca Bocassi wrote:
> From: Luca Boccassi 
> 
> Signed-off-by: Luca Boccassi 
> ---
>  meta/recipes-core/volatile-binds/volatile-binds.bb | 2 ++
>  1 file changed, 2 insertions(+)
> 
> diff --git a/meta/recipes-core/volatile-binds/volatile-binds.bb 
> b/meta/recipes-core/volatile-binds/volatile-binds.bb
> index 66e28f4fc9..0f27353031 100644
> --- a/meta/recipes-core/volatile-binds/volatile-binds.bb
> +++ b/meta/recipes-core/volatile-binds/volatile-binds.bb
> @@ -84,3 +84,5 @@ do_install[dirs] = "${WORKDIR}"
>  do_install_append_class-nativesdk () {
>  rm -rf ${D}/var
>  }
> +
> +BBCLASSEXTEND = "nativesdk"

Is there any useful component left in volatile-binds in the SDK case? I don't
think we should be extending this as the recipe makes no sense. Rather nativesdk
variants probably shouldn't be depending upon it?

Cheers,

Richard


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



Re: [OE-core] [PATCH 2/2] glibc: Append files instead of making then part of main SRC_URI

2021-11-17 Thread Richard Purdie
On Wed, 2021-11-17 at 08:56 -0800, Khem Raj wrote:
> This will help later with using devupstream
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/recipes-core/glibc/glibc_2.34.bb | 10 ++
>  1 file changed, 6 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-core/glibc/glibc_2.34.bb 
> b/meta/recipes-core/glibc/glibc_2.34.bb
> index 72064772789..778898f1979 100644
> --- a/meta/recipes-core/glibc/glibc_2.34.bb
> +++ b/meta/recipes-core/glibc/glibc_2.34.bb
> @@ -29,10 +29,6 @@ NATIVESDKFIXES:class-nativesdk = "\
>  "
>  
>  SRC_URI =  "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
> -   file://etc/ld.so.conf \
> -   file://generate-supported.mk \
> -   file://makedbs.sh \
> -   \
> ${NATIVESDKFIXES} \
> file://0009-fsl-e500-e5500-e6500-603e-fsqrt-implementation.patch \
> 
> file://0010-ppc-sqrt-Fix-undefined-reference-to-__sqrt_finite.patch \
> @@ -60,6 +56,12 @@ SRC_URI =  
> "${GLIBC_GIT_URI};branch=${SRCBRANCH};name=glibc \
> 
> file://0001-fix-create-thread-failed-in-unprivileged-process-BZ-.patch \
> file://CVE-2021-43396.patch \
> "
> +# Use append instead of += that way patch is applied with devupstream too
> +SRC_URI:append = "\
> +   file://etc/ld.so.conf \
> +   file://generate-supported.mk \
> +   file://makedbs.sh \
> +"
>  S = "${WORKDIR}/git"
>  B = "${WORKDIR}/build-${TARGET_SYS}"
>  

I'm afraid I really dislike these kinds of patches. We need to do something with
our syntax so we don't have to jump through weird hoops like this. These kind of
changes look really fragile and easy to break. 

Effectively it is an arms race to turn everything into an append, then nothing
can disable it.

Cheers,

Richard


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



Re: [OE-core] [PATCH] Fix Bug-14613

2021-11-15 Thread Richard Purdie
On Mon, 2021-11-15 at 04:58 -0800, Pgowda wrote:
> Source:- https://bugzilla.yoctoproject.org/show_bug.cgi?id=14613
> 
> Adds TUNE_PKGARCH to PN so that it picks correct TUNE_FEATURES.
> 

Also, the short log needs to be in the format matching our commit guidelines so
something like:

rust-cross: Replace TARGET_ARCH with TUNE_PKGARCH

and then the full log needs to describe what issues there were, why the commit
is necessary and how this fixes it. It should be readable without looking at the
bugzilla entry.

The format for a link to the bugzilla entry is:

[YOCTO #14613]

Cheers,

Richard


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



Re: [OE-core] [PATCH] Fix Bug-14613

2021-11-15 Thread Richard Purdie
On Mon, 2021-11-15 at 04:58 -0800, Pgowda wrote:
> Source:- https://bugzilla.yoctoproject.org/show_bug.cgi?id=14613
> 
> Adds TUNE_PKGARCH to PN so that it picks correct TUNE_FEATURES.
> 
> Signed-off-by: Pgowda 
> ---
>  meta/recipes-devtools/rust/rust-cross.inc | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/rust/rust-cross.inc 
> b/meta/recipes-devtools/rust/rust-cross.inc
> index bb625f4240..30c92ed395 100644
> --- a/meta/recipes-devtools/rust/rust-cross.inc
> +++ b/meta/recipes-devtools/rust/rust-cross.inc
> @@ -34,7 +34,7 @@ DEPENDS += "virtual/${TARGET_PREFIX}gcc 
> virtual/${TARGET_PREFIX}compilerlibs vir
>  DEPENDS += "rust-native"
>  
>  PROVIDES = "virtual/${TARGET_PREFIX}rust"
> -PN = "rust-cross-${TARGET_ARCH}-${TCLIBC}"
> +PN = "rust-cross-${TARGET_ARCH}-${TCLIBC}-${TUNE_PKGARCH}"
>  
>  # In the cross compilation case, rustc doesn't seem to get the rpath quite
>  # right. It manages to include '../../lib/${TARGET_PREFIX}', but doesn't

If we do this we can drop the TARGET_ARCH piece since that isn't needed with the
more specific tune present.

Cheers,

Richard


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



[OE-core] [PATCH 1/2] lua: Backport fix for CVE-2021-43396

2021-11-15 Thread Richard Purdie
Backport the fix for CVE-2021-43396 ("C stack overflow with coroutines")
from upstream.

Signed-off-by: Richard Purdie 
---
 ...9057a5146755e737c479850f87fd0e3b6868.patch | 43 +++
 meta/recipes-devtools/lua/lua_5.4.3.bb|  1 +
 2 files changed, 44 insertions(+)
 create mode 100644 
meta/recipes-devtools/lua/lua/74d99057a5146755e737c479850f87fd0e3b6868.patch

diff --git 
a/meta/recipes-devtools/lua/lua/74d99057a5146755e737c479850f87fd0e3b6868.patch 
b/meta/recipes-devtools/lua/lua/74d99057a5146755e737c479850f87fd0e3b6868.patch
new file mode 100644
index 000..dcdc04837d6
--- /dev/null
+++ 
b/meta/recipes-devtools/lua/lua/74d99057a5146755e737c479850f87fd0e3b6868.patch
@@ -0,0 +1,43 @@
+From 74d99057a5146755e737c479850f87fd0e3b6868 Mon Sep 17 00:00:00 2001
+From: Roberto Ierusalimschy 
+Date: Wed, 3 Nov 2021 15:04:18 -0300
+Subject: [PATCH] Bug: C stack overflow with coroutines
+
+'coroutine.resume' did not increment counter of C calls when
+continuing execution after a protected error (that is,
+while running 'precover').
+---
+ ldo.c |  6 --
+ testes/cstack.lua | 14 ++
+ 2 files changed, 18 insertions(+), 2 deletions(-)
+
+Upstream-Status: Backport 
[https://github.com/lua/lua/commit/74d99057a5146755e737c479850f87fd0e3b6868.patch]
+CVE: CVE-2021-43519
+
+diff --git a/src/ldo.c b/src/ldo.c
+index d0edc8b4f..66f890364 100644
+--- a/src/ldo.c
 b/src/ldo.c
+@@ -759,11 +759,10 @@ static void resume (lua_State *L, void *ud) {
+   StkId firstArg = L->top - n;  /* first argument */
+   CallInfo *ci = L->ci;
+   if (L->status == LUA_OK)  /* starting a coroutine? */
+-ccall(L, firstArg - 1, LUA_MULTRET, 1);  /* just call its body */
++ccall(L, firstArg - 1, LUA_MULTRET, 0);  /* just call its body */
+   else {  /* resuming from previous yield */
+ lua_assert(L->status == LUA_YIELD);
+ L->status = LUA_OK;  /* mark that it is running (again) */
+-luaE_incCstack(L);  /* control the C stack */
+ if (isLua(ci)) {  /* yielded inside a hook? */
+   L->top = firstArg;  /* discard arguments */
+   luaV_execute(L, ci);  /* just continue running Lua code */
+@@ -814,6 +813,9 @@ LUA_API int lua_resume (lua_State *L, lua_State *from, int 
nargs,
+   else if (L->status != LUA_YIELD)  /* ended with errors? */
+ return resume_error(L, "cannot resume dead coroutine", nargs);
+   L->nCcalls = (from) ? getCcalls(from) : 0;
++  if (getCcalls(L) >= LUAI_MAXCCALLS)
++return resume_error(L, "C stack overflow", nargs);
++  L->nCcalls++;
+   luai_userstateresume(L, nargs);
+   api_checknelems(L, (L->status == LUA_OK) ? nargs + 1 : nargs);
+   status = luaD_rawrunprotected(L, resume, );
diff --git a/meta/recipes-devtools/lua/lua_5.4.3.bb 
b/meta/recipes-devtools/lua/lua_5.4.3.bb
index 0224744fe7a..a204242bc02 100644
--- a/meta/recipes-devtools/lua/lua_5.4.3.bb
+++ b/meta/recipes-devtools/lua/lua_5.4.3.bb
@@ -7,6 +7,7 @@ HOMEPAGE = "http://www.lua.org/;
 SRC_URI = "http://www.lua.org/ftp/lua-${PV}.tar.gz;name=tarballsrc \
file://lua.pc.in \
${@bb.utils.contains('DISTRO_FEATURES', 'ptest', 
'http://www.lua.org/tests/lua-${PV_testsuites}-tests.tar.gz;name=tarballtest 
file://run-ptest ', '', d)} \
+   file://74d99057a5146755e737c479850f87fd0e3b6868.patch \
"
 
 # if no test suite matches PV release of Lua exactly, download the suite for 
the closest Lua release.
-- 
2.32.0


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



[OE-core] [PATCH 2/2] glibc: Backport fix for CVE-2021-43396

2021-11-15 Thread Richard Purdie
Backport the fix for CVE-2021-43396. It is disputed that this is a security 
issue
however the fix applies easily so we may as well.

Signed-off-by: Richard Purdie 
---
 .../glibc/glibc/CVE-2021-43396.patch  | 184 ++
 meta/recipes-core/glibc/glibc_2.34.bb |   1 +
 2 files changed, 185 insertions(+)
 create mode 100644 meta/recipes-core/glibc/glibc/CVE-2021-43396.patch

diff --git a/meta/recipes-core/glibc/glibc/CVE-2021-43396.patch 
b/meta/recipes-core/glibc/glibc/CVE-2021-43396.patch
new file mode 100644
index 000..ebea5efd347
--- /dev/null
+++ b/meta/recipes-core/glibc/glibc/CVE-2021-43396.patch
@@ -0,0 +1,184 @@
+From ff012870b2c02a62598c04daa1e54632e020fd7d Mon Sep 17 00:00:00 2001
+From: Nikita Popov 
+Date: Tue, 2 Nov 2021 13:21:42 +0500
+Subject: [PATCH] gconv: Do not emit spurious NUL character in ISO-2022-JP-3
+ (bug 28524)
+
+Bugfix 27256 has introduced another issue:
+In conversion from ISO-2022-JP-3 encoding, it is possible
+to force iconv to emit extra NUL character on internal state reset.
+To do this, it is sufficient to feed iconv with escape sequence
+which switches active character set.
+The simplified check 'data->__statep->__count != ASCII_set'
+introduced by the aforementioned bugfix picks that case and
+behaves as if '\0' character has been queued thus emitting it.
+
+To eliminate this issue, these steps are taken:
+* Restore original condition
+'(data->__statep->__count & ~7) != ASCII_set'.
+It is necessary since bits 0-2 may contain
+number of buffered input characters.
+* Check that queued character is not NUL.
+Similar step is taken for main conversion loop.
+
+Bundled test case follows following logic:
+* Try to convert ISO-2022-JP-3 escape sequence
+switching active character set
+* Reset internal state by providing NULL as input buffer
+* Ensure that nothing has been converted.
+
+Signed-off-by: Nikita Popov 
+
+CVE: CVE-2021-43396
+Upstream-Status: Backport [ff012870b2c02a62598c04daa1e54632e020fd7d]
+---
+ iconvdata/Makefile|  5 +++-
+ iconvdata/bug-iconv15.c   | 60 +++
+ iconvdata/iso-2022-jp-3.c | 28 --
+ 3 files changed, 84 insertions(+), 9 deletions(-)
+ create mode 100644 iconvdata/bug-iconv15.c
+
+Index: git/iconvdata/Makefile
+===
+--- git.orig/iconvdata/Makefile
 git/iconvdata/Makefile
+@@ -1,4 +1,5 @@
+ # Copyright (C) 1997-2021 Free Software Foundation, Inc.
++# Copyright (C) The GNU Toolchain Authors.
+ # This file is part of the GNU C Library.
+ 
+ # The GNU C Library is free software; you can redistribute it and/or
+@@ -74,7 +75,7 @@ ifeq (yes,$(build-shared))
+ tests = bug-iconv1 bug-iconv2 tst-loading tst-e2big tst-iconv4 bug-iconv4 \
+   tst-iconv6 bug-iconv5 bug-iconv6 tst-iconv7 bug-iconv8 bug-iconv9 \
+   bug-iconv10 bug-iconv11 bug-iconv12 tst-iconv-big5-hkscs-to-2ucs4 \
+-  bug-iconv13 bug-iconv14
++  bug-iconv13 bug-iconv14 bug-iconv15
+ ifeq ($(have-thread-library),yes)
+ tests += bug-iconv3
+ endif
+@@ -327,6 +328,8 @@ $(objpfx)bug-iconv12.out: $(addprefix $(
+ $(addprefix $(objpfx),$(modules.so))
+ $(objpfx)bug-iconv14.out: $(addprefix $(objpfx), $(gconv-modules)) \
+ $(addprefix $(objpfx),$(modules.so))
++$(objpfx)bug-iconv15.out: $(addprefix $(objpfx), $(gconv-modules)) \
++$(addprefix $(objpfx),$(modules.so))
+ 
+ $(objpfx)iconv-test.out: run-iconv-test.sh \
+$(addprefix $(objpfx), $(gconv-modules)) \
+Index: git/iconvdata/bug-iconv15.c
+===
+--- /dev/null
 git/iconvdata/bug-iconv15.c
+@@ -0,0 +1,60 @@
++/* Bug 28524: Conversion from ISO-2022-JP-3 with iconv
++   may emit spurious NUL character on state reset.
++   Copyright (C) The GNU Toolchain Authors.
++   This file is part of the GNU C Library.
++
++   The GNU C Library is free software; you can redistribute it and/or
++   modify it under the terms of the GNU Lesser General Public
++   License as published by the Free Software Foundation; either
++   version 2.1 of the License, or (at your option) any later version.
++
++   The GNU C Library is distributed in the hope that it will be useful,
++   but WITHOUT ANY WARRANTY; without even the implied warranty of
++   MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the GNU
++   Lesser General Public License for more details.
++
++   You should have received a copy of the GNU Lesser General Public
++   License along with the GNU C Library; if not, see
++   <https://www.gnu.org/licenses/>.  */
++
++#include 
++#include 
++#include 
++
++static int
++do_test (void)
++{
++  char in[] = "\x1b(I";
++  char *inbuf = in;
++  size_t inleft = sizeof (in) - 1;
++  char out[1];
++  char *outbuf = out;
++  size_t outleft = sizeof (out);
++  iconv_t cd;
++
++  cd = ic

[OE-core] [PATCH] gcc: Dropping mips workaround

2021-11-15 Thread Richard Purdie
I've tested without this and the ptest results for mips are the same with
and without it so the issue this was fixing in gcc 9 was likely resolved
by gcc 11.

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/binutils/binutils_2.37.bb | 4 
 1 file changed, 4 deletions(-)

diff --git a/meta/recipes-devtools/binutils/binutils_2.37.bb 
b/meta/recipes-devtools/binutils/binutils_2.37.bb
index 7430bf13425..12a6fb55776 100644
--- a/meta/recipes-devtools/binutils/binutils_2.37.bb
+++ b/meta/recipes-devtools/binutils/binutils_2.37.bb
@@ -27,10 +27,6 @@ EXTRA_OECONF:class-native = "--enable-targets=all \
 
 PACKAGECONFIG ??= "${@bb.utils.filter('DISTRO_FEATURES', 'debuginfod', d)}"
 PACKAGECONFIG[debuginfod] = "--with-debuginfod, --without-debuginfod, elfutils"
-# gcc9.0 end up mis-compiling libbfd.so with O2 which then crashes on target
-# So remove -O2 and use -Os as workaround
-SELECTED_OPTIMIZATION:remove:mipsarch = "-O2"
-SELECTED_OPTIMIZATION:append:mipsarch = " -Os"
 
 do_install:class-native () {
autotools_do_install
-- 
2.32.0


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



Re: [OE-core] [PATCH 05/24] xserver-xorg: convert from autotools to meson

2021-11-15 Thread Richard Purdie
On Mon, 2021-11-15 at 07:15 +0100, Zoltan Boszormenyi via lists.openembedded.org
wrote:
> 2021. 11. 10. 20:39 keltezéssel, Alexander Kanavin írta:
> > 
> >   # Xorg requires a SHA1 implementation, pick one
> >   XORG_CRYPTO ??= "openssl"
> > -PACKAGECONFIG[openssl] = "--with-sha1=libcrypto,,openssl"
> > -PACKAGECONFIG[nettle] = "--with-sha1=libnettle,,nettle"
> > -PACKAGECONFIG[gcrypt] = "--with-sha1=libgcrypt,,libgcrypt"
> > +PACKAGECONFIG[openssl] = "-Dsha1=libcrypto,,openssl"
> > +PACKAGECONFIG[nettle] = "-Dsha1=libnettle,,nettle"
> > +PACKAGECONFIG[gcrypt] = "-Dsha1=libgcrypt,,libgcrypt"
> >   
> >   do_install:append () {
> > # Its assumed base-files creates this for us
> > -   rmdir ${D}${localstatedir}/log/
> 
> The comment is related to the presence of /var/log and
> now it doesn't make sense after removing the above line.
> Please remove the comment, too.
> 
> >   sed -i -e 's,${libdir}/xorg/modules,${prefix}/lib*/xorg/modules,' 
> > ${D}${mandir}/man5/xorg.conf.5
> >   }
> >   

It is gone:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=657f71e1f5cf8a9f385b1748d99cb6d531511626

Cheers,

Richard



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



Re: [OE-core] [hardknott][PATCH] mklibs: remove recipes and class

2021-11-14 Thread Richard Purdie
On Sun, 2021-11-14 at 20:47 +0100, Jacob Kroon wrote:
> On 11/14/21 20:36, Richard Purdie wrote:
> > On Sun, 2021-11-14 at 07:50 +0100, Jacob Kroon wrote:
> > > From: Alexander Kanavin 
> > > 
> > > This is not enabled or tested by default, and has never been
> > > ported to python 3 upstream[1], which means it doesn't work at all
> > > with plain poky. If you need it, please put it in a separate layer
> > > and/or modernize to work with py3.
> > > 
> > > https://salsa.debian.org/installer-team/mklibs/-/blob/master/src/mklibs
> > > 
> > > Signed-off-by: Alexander Kanavin 
> > > Signed-off-by: Jacob Kroon 
> > > Signed-off-by: Richard Purdie 
> > > (cherry picked from commit 908df863b419d1cad7317153101fc827e7e3a354)
> > 
> > What issue is it causing in hardknott? Normally we don't backport invasive
> > changes like that...
> > 
> 
> The problem is that mklibs-native doesn't build with gcc 11, and 
> "image-mklibs" was in USER_CLASSES by default in hardknott.
> 
> I sent a patch to fix mklibs build here:
> 
> https://lists.openembedded.org/g/openembedded-core/message/151982
> 
> but after some discussions we just decided to drop mklibs support 
> entirely with the proposed patch.

ok, that is something we should fix. My worry is that the backport as is will
need everyone to update their local.conf since the class will no longer be there
and it will throw errors if people try and include it. This isn't what people
expect from a point release.

Could we just remove it from local.conf in hardknott? That should solve the
issue but reduce risk to anyone who has hardknott already working fine with an
older gcc.

Cheers,

Richard


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



Re: [OE-core] [hardknott][PATCH] mklibs: remove recipes and class

2021-11-14 Thread Richard Purdie
On Sun, 2021-11-14 at 07:50 +0100, Jacob Kroon wrote:
> From: Alexander Kanavin 
> 
> This is not enabled or tested by default, and has never been
> ported to python 3 upstream[1], which means it doesn't work at all
> with plain poky. If you need it, please put it in a separate layer
> and/or modernize to work with py3.
> 
> https://salsa.debian.org/installer-team/mklibs/-/blob/master/src/mklibs
> 
> Signed-off-by: Alexander Kanavin 
> Signed-off-by: Jacob Kroon 
> Signed-off-by: Richard Purdie 
> (cherry picked from commit 908df863b419d1cad7317153101fc827e7e3a354)

What issue is it causing in hardknott? Normally we don't backport invasive
changes like that...

Cheers,

Richard


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



Re: [OE-core] [PATCH V2] python-numpy: move recipe to python directory

2021-11-13 Thread Richard Purdie
On Sun, 2021-11-14 at 01:02 +0800, Yi Zhao wrote:
> This recipe had been moved out from python directory since 2016[1] in
> order to share patches between python2 and python3. But now there is no
> reason to keep it in its own directory as we only keep python3-nump.
> Move it back to python directory.
> 
> Also add python3-json to RDEPENDS to fix import error:
> $ python3
> > > > import numpy
> Traceback (most recent call last):
>   File "", line 1, in 
>   File "/usr/lib/python3.10/site-packages/numpy/__init__.py", line 138, in 
> 
> from ._version import get_versions
>   File "/usr/lib/python3.10/site-packages/numpy/_version.py", line 7, in 
> 
> import json
> ModuleNotFoundError: No module named 'json'
> > > 

Please make these two separate commits since they're not really related.

Cheers,

Richard



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



Re: [OE-core] [PATCH] python-numpy: move recipe to python directory

2021-11-13 Thread Richard Purdie
On Sat, 2021-11-13 at 21:45 +0800, Yi Zhao wrote:
> This recipe had been moved out from python directory since 2016[1] in
> order to share patches between python2 and python3. But now there is no
> reason to keep it in its own directory as we only keep python3-nump.
> Move it back to python directory.
> 
> [1] 
> https://git.openembedded.org/openembedded-core/commit/?id=9bffe2f9fb4ce6c0b265f27e5b484fbe076c6349
> 
> Signed-off-by: Yi Zhao 
> ---
>  ...01-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch | 0
>  .../python3-numpy}/0001-numpy-core-Define-RISCV-32-support.patch | 0
>  .../{python-numpy/files => python/python3-numpy}/run-ptest   | 0
>  .../{python-numpy => python}/python3-numpy_1.21.4.bb | 1 +
>  4 files changed, 1 insertion(+)
>  rename meta/recipes-devtools/{python-numpy/files => 
> python/python3-numpy}/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
>  (100%)
>  rename meta/recipes-devtools/{python-numpy/files => 
> python/python3-numpy}/0001-numpy-core-Define-RISCV-32-support.patch (100%)
>  rename meta/recipes-devtools/{python-numpy/files => 
> python/python3-numpy}/run-ptest (100%)
>  rename meta/recipes-devtools/{python-numpy => 
> python}/python3-numpy_1.21.4.bb (98%)
> 
> diff --git 
> a/meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
>  
> b/meta/recipes-devtools/python/python3-numpy/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
> similarity index 100%
> rename from 
> meta/recipes-devtools/python-numpy/files/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
> rename to 
> meta/recipes-devtools/python/python3-numpy/0001-Don-t-search-usr-and-so-on-for-libraries-by-default-.patch
> diff --git 
> a/meta/recipes-devtools/python-numpy/files/0001-numpy-core-Define-RISCV-32-support.patch
>  
> b/meta/recipes-devtools/python/python3-numpy/0001-numpy-core-Define-RISCV-32-support.patch
> similarity index 100%
> rename from 
> meta/recipes-devtools/python-numpy/files/0001-numpy-core-Define-RISCV-32-support.patch
> rename to 
> meta/recipes-devtools/python/python3-numpy/0001-numpy-core-Define-RISCV-32-support.patch
> diff --git a/meta/recipes-devtools/python-numpy/files/run-ptest 
> b/meta/recipes-devtools/python/python3-numpy/run-ptest
> similarity index 100%
> rename from meta/recipes-devtools/python-numpy/files/run-ptest
> rename to meta/recipes-devtools/python/python3-numpy/run-ptest
> diff --git a/meta/recipes-devtools/python-numpy/python3-numpy_1.21.4.bb 
> b/meta/recipes-devtools/python/python3-numpy_1.21.4.bb
> similarity index 98%
> rename from meta/recipes-devtools/python-numpy/python3-numpy_1.21.4.bb
> rename to meta/recipes-devtools/python/python3-numpy_1.21.4.bb
> index 8988a5bc39..a3ea4ab5aa 100644
> --- a/meta/recipes-devtools/python-numpy/python3-numpy_1.21.4.bb
> +++ b/meta/recipes-devtools/python/python3-numpy_1.21.4.bb
> @@ -47,6 +47,7 @@ RDEPENDS:${PN} = "${PYTHON_PN}-unittest \
>${PYTHON_PN}-ctypes \
>${PYTHON_PN}-threading \
>${PYTHON_PN}-multiprocessing \
> +  ${PYTHON_PN}-json \
>  "
>  RDEPENDS:${PN}-ptest += "${PYTHON_PN}-pytest \
>   ${PYTHON_PN}-hypothesis \

Looks like there is a dependency being changed too which isn't in the commit
message?

Cheers,

Richard


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



[OE-core] [PATCH] packagegrou-core-x11-base: Drop dbus dependency

2021-11-13 Thread Richard Purdie
dbus isn't an x11 dependency and this suffers from debian renaming. Simply drop
the dependency.

Signed-off-by: Richard Purdie 
---
 .../recipes-graphics/packagegroups/packagegroup-core-x11-base.bb | 1 -
 1 file changed, 1 deletion(-)

diff --git a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb 
b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
index 4e6d9908c74..0185c93354c 100644
--- a/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
+++ b/meta/recipes-graphics/packagegroups/packagegroup-core-x11-base.bb
@@ -9,7 +9,6 @@ REQUIRED_DISTRO_FEATURES = "x11"
 RDEPENDS:${PN} = "\
 packagegroup-core-x11-xserver \
 packagegroup-core-x11-utils \
-dbus \
 matchbox-terminal \
 matchbox-wm \
 mini-x-session \
-- 
2.32.0


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



Re: [OE-core] [PATCH 6/6] ncurses: clean up pkgconfig install location

2021-11-13 Thread Richard Purdie
On Fri, 2021-11-12 at 14:02 +, Ross Burton wrote:
> These is now an option to set the pkg-config install location, instead of
> injecting it into the install to override the detected location (which
> is into the sysroot).
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/recipes-core/ncurses/ncurses.inc | 6 ++
>  1 file changed, 2 insertions(+), 4 deletions(-)
> 
> diff --git a/meta/recipes-core/ncurses/ncurses.inc 
> b/meta/recipes-core/ncurses/ncurses.inc
> index a0ecd8a80b..89642ea782 100644
> --- a/meta/recipes-core/ncurses/ncurses.inc
> +++ b/meta/recipes-core/ncurses/ncurses.inc
> @@ -86,6 +86,7 @@ ncurses_configure() {
>   --with-termlib=${EX_TERMLIB} \
>   --enable-sigwinch \
>   --enable-pc-files \
> + --with-pkg-config-libdir=${libdir}/pkgconfig \
>   --disable-rpath-hack \
>   ${EXCONFIG_ARGS} \
>   --with-manpage-format=normal \
> @@ -156,10 +157,7 @@ do_test() {
>  
>  _install_opts = " install.libs install.man "
>  
> -_install_cfgs = "\
> -  DESTDIR='${D}' \
> -  PKG_CONFIG_LIBDIR='${libdir}/pkgconfig' \
> -"
> +_install_cfgs = "DESTDIR='${D}'"
>  
>  do_install() {
>  # Order of installation is important; widec installs a 'curses.h'

I'm afraid this doesn't work:

https://autobuilder.yoctoproject.org/typhoon/#/builders/62/builds/4347/steps/11/logs/stdio

and many other failures as well. Note the alsa-utils failure looks related too.

Cheers,

Richard


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



[OE-core] [PATCH] mirrors: Add kernel.org sources mirror for downloads.yoctoproject.org

2021-11-12 Thread Richard Purdie
kernel.org now has a mirror of the downloads.yoctoproject.org sources
archive so include this in our mirrors list.

Signed-off-by: Richard Purdie 
---
 meta/classes/mirrors.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index dc95cc1174b..8e7b35d9000 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -62,6 +62,7 @@ npm://.*/?.*http://sources.openembedded.org/ \
 ${CPAN_MIRROR}  http://cpan.metacpan.org/ \
 ${CPAN_MIRROR}  http://search.cpan.org/CPAN/ \
 https?://downloads.yoctoproject.org/releases/uninative/ 
https://mirrors.kernel.org/yocto/uninative/ \
+https?://downloads.yoctoproject.org/mirror/sources/ 
https://mirrors.kernel.org/yocto-sources/ \
 "
 
 # Use MIRRORS to provide git repo fallbacks using the https protocol, for cases
-- 
2.32.0


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



[OE-core] [PATCH 3/4] packagegrou-core-full-cmdline: Drop compatibility mappings

2021-11-12 Thread Richard Purdie
The task-core namespace was dropped years ago and we've had the compatibility
mappings for a long time. We should no longer need them as everyone should long
since have adapted.

Signed-off-by: Richard Purdie 
---
 .../packagegroup-core-full-cmdline.bb | 35 ---
 1 file changed, 35 deletions(-)

diff --git 
a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb 
b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
index c0647b21883..b66617fbf61 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
@@ -18,41 +18,6 @@ PACKAGES = "\
 packagegroup-core-full-cmdline-sys-services \
 "
 
-python __anonymous () {
-# For backwards compatibility after rename
-namemap = {}
-namemap["packagegroup-core-full-cmdline"] = "packagegroup-core-basic"
-namemap["packagegroup-core-full-cmdline-utils"] = 
"packagegroup-core-basic-utils"
-namemap["packagegroup-core-full-cmdline-extended"] = 
"packagegroup-core-basic-extended"
-namemap["packagegroup-core-full-cmdline-dev-utils"] = 
"packagegroup-core-dev-utils"
-namemap["packagegroup-core-full-cmdline-multiuser"] = 
"packagegroup-core-multiuser"
-namemap["packagegroup-core-full-cmdline-initscripts"] = 
"packagegroup-core-initscripts"
-namemap["packagegroup-core-full-cmdline-sys-services"] = 
"packagegroup-core-sys-services"
-
-packages = d.getVar("PACKAGES").split()
-mlprefix = d.getVar("MLPREFIX")
-for pkg in packages:
-pkg2 = pkg[len(mlprefix):]
-if pkg.endswith('-dev'):
-mapped = namemap.get(pkg2[:-4], None)
-if mapped:
-mapped += '-dev'
-elif pkg.endswith('-dbg'):
-mapped = namemap.get(pkg2[:-4], None)
-if mapped:
-mapped += '-dbg'
-else:
-mapped = namemap.get(pkg2, None)
-
-if mapped:
-oldtaskname = mapped.replace("packagegroup-core", "task-core")
-mapstr = " %s%s %s%s" % (mlprefix, mapped, mlprefix, oldtaskname)
-d.appendVar("RPROVIDES:%s" % pkg, mapstr)
-d.appendVar("RREPLACES:%s" % pkg, mapstr)
-d.appendVar("RCONFLICTS:%s" % pkg, mapstr)
-}
-
-
 RDEPENDS:packagegroup-core-full-cmdline = "\
 packagegroup-core-full-cmdline-utils \
 packagegroup-core-full-cmdline-extended \
-- 
2.32.0


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



[OE-core] [PATCH 2/4] packagegroups-core-full-cmdline: Drop libraries packagegroup and gmp

2021-11-12 Thread Richard Purdie
We pull in libraries as/where needed as dependencies so there is no need
to have them as specific packagegroups. This change removes glib-2.0 and gmp.

This also has the advantage of meaning debian renaming now isn't used anywhere
and the packagegroup can remain allarch.

Signed-off-by: Richard Purdie 
---
 .../packagegroups/packagegroup-core-full-cmdline.bb   | 8 
 1 file changed, 8 deletions(-)

diff --git 
a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb 
b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
index 14a7bded953..c0647b21883 100644
--- a/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
+++ b/meta/recipes-extended/packagegroups/packagegroup-core-full-cmdline.bb
@@ -10,7 +10,6 @@ inherit packagegroup
 
 PACKAGES = "\
 packagegroup-core-full-cmdline \
-packagegroup-core-full-cmdline-libs \
 packagegroup-core-full-cmdline-utils \
 packagegroup-core-full-cmdline-extended \
 packagegroup-core-full-cmdline-dev-utils \
@@ -23,7 +22,6 @@ python __anonymous () {
 # For backwards compatibility after rename
 namemap = {}
 namemap["packagegroup-core-full-cmdline"] = "packagegroup-core-basic"
-namemap["packagegroup-core-full-cmdline-libs"] = 
"packagegroup-core-basic-libs"
 namemap["packagegroup-core-full-cmdline-utils"] = 
"packagegroup-core-basic-utils"
 namemap["packagegroup-core-full-cmdline-extended"] = 
"packagegroup-core-basic-extended"
 namemap["packagegroup-core-full-cmdline-dev-utils"] = 
"packagegroup-core-dev-utils"
@@ -56,7 +54,6 @@ python __anonymous () {
 
 
 RDEPENDS:packagegroup-core-full-cmdline = "\
-packagegroup-core-full-cmdline-libs \
 packagegroup-core-full-cmdline-utils \
 packagegroup-core-full-cmdline-extended \
 packagegroup-core-full-cmdline-dev-utils \
@@ -65,10 +62,6 @@ RDEPENDS:packagegroup-core-full-cmdline = "\
 packagegroup-core-full-cmdline-sys-services \
 "
 
-RDEPENDS:packagegroup-core-full-cmdline-libs = "\
-glib-2.0 \
-"
-
 RDEPENDS:packagegroup-core-full-cmdline-utils = "\
 bash \
 acl \
@@ -81,7 +74,6 @@ RDEPENDS:packagegroup-core-full-cmdline-utils = "\
 file \
 findutils \
 gawk \
-gmp \
 grep \
 less \
 makedevs \
-- 
2.32.0


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



[OE-core] [PATCH 1/4] packagegroup-core-buildessential: Mark as TUNE_PKGARCH specific

2021-11-12 Thread Richard Purdie
The libstdc++ dependency is debian renamed so this shouldn't be allarch,
mark accordingly.

Signed-off-by: Richard Purdie 
---
 .../packagegroups/packagegroup-core-buildessential.bb  | 3 +++
 1 file changed, 3 insertions(+)

diff --git 
a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb 
b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb
index 32f4ac35861..2cd67ad05f8 100644
--- a/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb
+++ b/meta/recipes-core/packagegroups/packagegroup-core-buildessential.bb
@@ -5,6 +5,9 @@
 
 SUMMARY = "Essential build dependencies"
 
+# libstdc++ gets debian renamed
+PACKAGE_ARCH = "${TUNE_PKGARCH}"
+
 inherit packagegroup
 
 RDEPENDS:packagegroup-core-buildessential = "\
-- 
2.32.0


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



[OE-core] [PATCH 4/4] package: Add sanity check for allarch packagegroups

2021-11-12 Thread Richard Purdie
We exclude allarch packagegroups from rebuilding when their dependencies change.
The reasoning is that we are just depending on a name so having these rebuild
lots is just pointless and inefficient. We also don't want them duplicated for
multiple machines for efficiency.

In general this works fine, as long as the package names don't change. That
is also rare but there is one corner case which does catch users out - debian
package renaming. When this does break, users question sstate and so on and
lose faith in the system even if this is a known choice we made.

This commit adds an error message if an allarch packagegroup depends on any
package which shows package renaming in action (through the PKG variable
being set).

If you run into this issue you either need to remove the dependency from the
packagegroup or mark the packagegroup as tune specific, i.e. set:

PACKAGE_ARCH = "${TUNE_PKGARCH}"

before the packagegroup inherit.

[YOCTO #7298]

Signed-off-by: Richard Purdie 
---
 meta/classes/package.bbclass | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 92eba988929..84eafbd5293 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -619,6 +619,8 @@ def get_package_mapping (pkg, basepkg, d, depversions=None):
 key = "PKG:%s" % pkg
 
 if key in data:
+if bb.data.inherits_class('allarch', d) and 
bb.data.inherits_class('packagegroup', d) and pkg != data[key]:
+bb.error("An allarch packagegroup shouldn't depend on packages 
which are dynamically renamed (%s to %s)" % (pkg, data[key]))
 # Have to avoid undoing the write_extra_pkgs(global_variants...)
 if bb.data.inherits_class('allarch', d) and not 
d.getVar('MULTILIB_VARIANTS') \
 and data[key] == basepkg:
-- 
2.32.0


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



[OE-core] [PATCH] uninative: Add version to uninative tarball name

2021-11-12 Thread Richard Purdie
uninative works via hashes and doesn't need the version in the tarball name but
it does make things easier to inspect in DL_DIR. There were reasons such as
ease of publication of the build tarballs but we can handle those differently
now and the signature issues from the early code aren't an issue now. From 3.4
onwards we can use a version'd name.

[YOCTO #12970]

Signed-off-by: Richard Purdie 
---
 meta/classes/uninative.bbclass   | 2 +-
 meta/conf/distro/include/yocto-uninative.inc | 3 ++-
 2 files changed, 3 insertions(+), 2 deletions(-)

diff --git a/meta/classes/uninative.bbclass b/meta/classes/uninative.bbclass
index 3c7ccd66f43..4412d7c567c 100644
--- a/meta/classes/uninative.bbclass
+++ b/meta/classes/uninative.bbclass
@@ -2,7 +2,7 @@ UNINATIVE_LOADER ?= 
"${UNINATIVE_STAGING_DIR}-uninative/${BUILD_ARCH}-linux/lib/
 UNINATIVE_STAGING_DIR ?= "${STAGING_DIR}"
 
 UNINATIVE_URL ?= "unset"
-UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc.tar.xz"
+UNINATIVE_TARBALL ?= "${BUILD_ARCH}-nativesdk-libc-${UNINATIVE_VERSION}.tar.xz"
 # Example checksums
 #UNINATIVE_CHECKSUM[aarch64] = "dead"
 #UNINATIVE_CHECKSUM[i686] = "dead"
diff --git a/meta/conf/distro/include/yocto-uninative.inc 
b/meta/conf/distro/include/yocto-uninative.inc
index 3165fc93b89..6833072cd3a 100644
--- a/meta/conf/distro/include/yocto-uninative.inc
+++ b/meta/conf/distro/include/yocto-uninative.inc
@@ -7,8 +7,9 @@
 #
 
 UNINATIVE_MAXGLIBCVERSION = "2.34"
+UNINATIVE_VERSION = "3.4"
 
-UNINATIVE_URL ?= "http://downloads.yoctoproject.org/releases/uninative/3.4/;
+UNINATIVE_URL ?= 
"http://downloads.yoctoproject.org/releases/uninative/${UNINATIVE_VERSION}/;
 UNINATIVE_CHECKSUM[aarch64] ?= 
"3013cdda8f0dc6639ce1c80f33eabce66f06b890bd5b58739a6d7a92a0bb7100"
 UNINATIVE_CHECKSUM[i686] ?= 
"abed500de584aad63ec237546db20cdd0c69d8870a6f8e94ac31721ace64b376"
 UNINATIVE_CHECKSUM[x86_64] ?= 
"126f4f7f6f21084ee140dac3eb4c536b963837826b7c38599db0b512c3377ba2"
-- 
2.32.0


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



Re: [OE-core] [PATCH] util-linux: fix tabfiles-tags case failure

2021-11-12 Thread Richard Purdie
On Fri, 2021-11-12 at 18:03 +0800, Yu, Mingli wrote:
> From: Mingli Yu 
> 
> Pass "--use-system-commands" option when run tabfiles-tags case as
> we don't deploy the command under /usr/lib64/util-linux/ptest folder
> by default.
>  Fixes:
>  # cd /usr/lib64/util-linux/ptest/
>  # ./tests/ts/libmount/tabfiles-tags
>  [snip]
>  ./ts/libmount/../../functions.sh: line 652: 
> /usr/lib64/util-linux/ptest/blkid: No such file or directory
>  FAILED (libmount/tabfiles-tags)'
> 
> Signed-off-by: Mingli Yu 
> ---
>  meta/recipes-core/util-linux/util-linux.inc   |  1 +
>  ...-tags-add-use-system-commands-option.patch | 35 +++
>  2 files changed, 36 insertions(+)
>  create mode 100644 
> meta/recipes-core/util-linux/util-linux/0001-tabfiles-tags-add-use-system-commands-option.patch

I don't really want to carry a patch for this forever. Could we create a symlink
in do_install_ptest that handles this instead?

Also, why isn't isn't failure showing up on the autobuilder test runs?

Cheers,

Richard


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



Re: [OE-core] [PATCH v4] glibc: ptest: Add running glibc time related test suite (Y2038) with ptest

2021-11-12 Thread Richard Purdie
On Fri, 2021-11-12 at 09:41 +0100, Lukasz Majewski wrote:
> Hi Khem,
> 
> > seeing this
> > 
> > https://errors.yoctoproject.org/Errors/Details/616955/
> 
> The error is about autoconf version:
> 
> DEBUG: Executing shell function do_configure
> aclocal.m4:6: error: Exactly version 2.69 of Autoconf is required but
> you have 2.71
> 
> aclocal.m4:6: the top level
> autom4te: error: m4 failed with exit status: 63
> 
> This is strange, as on my setup (qemuarm, qemuarm64, qemux86) the glibc
> and glibc-tests are built without any issues with autoconf version 2.71.
> 
> 
> I've built the glibc-tests without issues with:
> 
> Build Configuration:
> BB_VERSION   = "1.52.0"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "riscv64-poky-linux"
> MACHINE  = "qemuriscv64"
> DISTRO   = "poky"
> DISTRO_VERSION   = "3.4"
> TUNE_FEATURES= "riscv64"
> meta
> meta-poky
> meta-yocto-bsp   =
> "glibc-ptest_v4:164923f0586ac189f01938a32fa102c2df7cc447"
> 
> DISTRO=poky MACHINE=qemuriscv64 bitbake glibc-tests
> 
> 
> Khem, could you help me with setting up environment to reproduce this
> issue?

The autoconf version message isn't a fatal error and if you look at your own
build logs you probably have that too. What looks like it is the issue is:

checking if riscv64-yoe-linux-clang -target riscv64-yoe-linux
-mlittle-endian -mno-relax -Qunused-arguments -fstack-protector-strong  -O2 
-D_FORTIFY_SOURCE=2 -Wformat -Wformat-security -Werror=format-security 
--sysroot=TOPDIR/build/tmp/work/riscv64-yoe-linux/glibc-tests/2.34-r0/recipe-sysroot
 is sufficient to build libc... no

which I think leads to:

configure: error: 
*** These critical programs are missing or too old: compiler

Khem was implying this was a musl build, I can't see that from the logs but if
it is a musl build, it shouldn't be building glibc tests.

For that reason I did add:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?h=master-next=f54774199ef09b655de1b586045995e0f284925a

to master-next since I believe that was the remaining issue blocking the patch
apart from a typo Khem also mentioned which I meant to find and tweak.

I still am concerned about having duplication of tests but I don't see any way
around that since you want to get this patch merged and I don't have any
solution for that.

Cheers,

Richard



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



Re: [OE-core] [PATCH v4] glibc: ptest: Add running glibc time related test suite (Y2038) with ptest

2021-11-11 Thread Richard Purdie
On Thu, 2021-11-11 at 05:51 -0800, Khem Raj wrote:
> On Tue, Nov 9, 2021 at 7:29 AM Lukasz Majewski  wrote:
> > 
> > This patch introduces new recipe - namely 'glibc-tests', which
> > builds and installs time related (to check if Y2038 support works) glibc
> > test suite to OE/Yocto built image.
> > 
> > It reuses code from already available 'glibc-testsuite' recipe,
> > which is run with 'bitbake glibc-testsuite -c check' and uses qemu
> > to execute remotely (via SSH) tests on some emulated machine.
> > 
> > This recipe installs time related glibc tests on some rootfs image.
> > Afterwards, those tests can be executed on the real hardware, to
> > facilitate validation of it with Y2038 problem compliance.
> > 
> > To test time related subset - one needs to call:
> > ptest-runner glibc-tests
> > then change the date after Y2038 threshold for 32 bit systems:
> > date -s "20 JAN 2038 18:00:00"
> > and then run ptest-runner again.
> > 
> > To facilitate debugging, source files are provided by default with
> > the unstripped debugging symbols. Such approach would reduce the
> > already complex recipe (as it inherits base glibc one), so there
> > is no need to also install *-dbg and *-src packages.
> > 
> > Signed-off-by: Lukasz Majewski 
> > 
> > ---
> > Changes for v4:
> > - Add entry for 'glibc-tests' in the maintainers.inc file
> > - Remove nativesdk from BBCLASSEXTEND as this resipe is not supposed
> >   to be the part of SDK
> > 
> > Changes for v3:
> > - Provide missing ${PN}-ptest for PACKAGES, PROVIDES and
> >   RPROVIDES variables
> > 
> > Changes for v2:
> > - Just focus on time related set of tests as those can be run as
> >   standalone
> > - Reuse of already built tests (from glibc-tests.inc) and depoloy
> >   them on the HW target.
> > - Provide single 'run-ptest' script.
> > - Update the recipe to run with newest poky's -master
> > ---
> >  meta/conf/distro/include/maintainers.inc  |   1 +
> >  .../distro/include/ptest-packagelists.inc |   1 +
> >  meta/recipes-core/glibc/glibc-tests_2.34.bb   | 113 ++
> >  meta/recipes-core/glibc/glibc/run-ptest   |  37 ++
> >  4 files changed, 152 insertions(+)
> >  create mode 100644 meta/recipes-core/glibc/glibc-tests_2.34.bb
> >  create mode 100755 meta/recipes-core/glibc/glibc/run-ptest
> > 
> > diff --git a/meta/conf/distro/include/maintainers.inc 
> > b/meta/conf/distro/include/maintainers.inc
> > index baec2bef4d..7104e091fc 100644
> > --- a/meta/conf/distro/include/maintainers.inc
> > +++ b/meta/conf/distro/include/maintainers.inc
> > @@ -209,6 +209,7 @@ RECIPE_MAINTAINER:pn-glibc = "Khem Raj 
> > "
> >  RECIPE_MAINTAINER:pn-glibc-locale = "Khem Raj "
> >  RECIPE_MAINTAINER:pn-glibc-mtrace = "Khem Raj "
> >  RECIPE_MAINTAINER:pn-glibc-scripts = "Khem Raj "
> > +RECIPE_MAINTAINER:pn-glibc-tests = "Lukasz Majewski "
> >  RECIPE_MAINTAINER:pn-glibc-testsuite = "Khem Raj "
> >  RECIPE_MAINTAINER:pn-glide = "Otavio Salvador 
> > "
> >  RECIPE_MAINTAINER:pn-gmp = "Khem Raj "
> > diff --git a/meta/conf/distro/include/ptest-packagelists.inc 
> > b/meta/conf/distro/include/ptest-packagelists.inc
> > index 2e324f8da4..fd52fa72a4 100644
> > --- a/meta/conf/distro/include/ptest-packagelists.inc
> > +++ b/meta/conf/distro/include/ptest-packagelists.inc
> > @@ -61,6 +61,7 @@ PTESTS_FAST = "\
> >  slang-ptest \
> >  wayland-ptest \
> >  zlib-ptest \
> > +glibc-tests-ptest \
> 
> this will break musl. So lets change this to
> 
> PTESTS_FAST:append:libc-glibc = " glibc-tests-ptest"

FWIW I tested a tweak in master-next for that...

Cheers,

Richard


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



[OE-core] [PATCH] wpa-supplicant: Match package override to PACKAGES for pkg_postinst

2021-11-11 Thread Richard Purdie
In PACKAGES, ${PN} is used so it makes sense for the pkg_postinst variable
override to match that else it causes user confusion.

[YOCTO #14616]

Signed-off-by: Richard Purdie 
---
 meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb 
b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb
index 33b1495bb20..25cd8ef82ca 100644
--- a/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb
+++ b/meta/recipes-connectivity/wpa-supplicant/wpa-supplicant_2.9.bb
@@ -108,7 +108,7 @@ do_install () {
install -m 0644 ${WORKDIR}/99_wpa_supplicant ${D}/etc/default/volatiles
 }
 
-pkg_postinst:wpa-supplicant () {
+pkg_postinst:${PN} () {
# If we're offline, we don't need to do this.
if [ "x$D" = "x" ]; then
killall -q -HUP dbus-daemon || true
-- 
2.32.0


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



[OE-core] [PATCH 2/2] scripts/oe-package-browser: Handle no packages being built

2021-11-11 Thread Richard Purdie
Give the user a proper error message if there aren't packages built,
rather than a less friendly traceback.

[YOCTO #14619]

Signed-off-by: Richard Purdie 
---
 scripts/oe-pkgdata-browser | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/scripts/oe-pkgdata-browser b/scripts/oe-pkgdata-browser
index e07005b8070..a3a381923b7 100755
--- a/scripts/oe-pkgdata-browser
+++ b/scripts/oe-pkgdata-browser
@@ -236,6 +236,8 @@ class PkgUi():
 update_deps("RPROVIDES", "Provides: ", self.provides_label, 
clickable=False)
 
 def load_recipes(self):
+if not os.path.exists(pkgdata):
+sys.exit("Error: Please ensure %s exists by generating packages 
before using this tool." % pkgdata)
 for recipe in sorted(os.listdir(pkgdata)):
 if os.path.isfile(os.path.join(pkgdata, recipe)):
 self.recipe_iters[recipe] = self.recipe_store.append([recipe])
-- 
2.32.0


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



[OE-core] [PATCH 1/2] scripts/oe-package-browser: Fix after overrides change

2021-11-11 Thread Richard Purdie
After the overrides change, the format of pkgdata changed and this
usage of configparser no longer works. This change is a bandaid to make
things work but the pkgdata format isn't very similar to ini files
so this may need to be reimplmented in a better way in the long run.

[YOCTO #14619]

Signed-off-by: Richard Purdie 
---
 scripts/oe-pkgdata-browser | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/scripts/oe-pkgdata-browser b/scripts/oe-pkgdata-browser
index 8d223185a43..e07005b8070 100755
--- a/scripts/oe-pkgdata-browser
+++ b/scripts/oe-pkgdata-browser
@@ -49,11 +49,11 @@ def load(filename, suffix=None):
 from configparser import ConfigParser
 from itertools import chain
 
-parser = ConfigParser()
+parser = ConfigParser(delimiters=('='))
 if suffix:
-parser.optionxform = lambda option: option.replace("_" + suffix, "")
+parser.optionxform = lambda option: option.replace(":" + suffix, "")
 with open(filename) as lines:
-lines = chain(("[fake]",), lines)
+lines = chain(("[fake]",), (line.replace(": ", " = ", 1) for line in 
lines))
 parser.read_file(lines)
 
 # TODO extract the data and put it into a real dict so we can transform 
some
-- 
2.32.0


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



Re: [OE-core] [PATCH] xserver-xorg: add missing libtirpc dependency

2021-11-11 Thread Richard Purdie
On Thu, 2021-11-11 at 06:58 -0800, Khem Raj wrote:
> 
> 
> On Thu, Nov 11, 2021 at 2:05 AM Alexander Kanavin 
> wrote:
> > This wasn't a problem in poky, but was exposed with a nodistro build.
> > 
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  meta/recipes-graphics/xorg-xserver/xserver-xorg.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> > 
> > diff --git a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > index 4a7048aced..71c934ef38 100644
> > --- a/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > +++ b/meta/recipes-graphics/xorg-xserver/xserver-xorg.inc
> > @@ -28,7 +28,7 @@ inherit meson pkgconfig
> >  inherit features_check
> >  REQUIRED_DISTRO_FEATURES = "x11"
> > 
> > -LIB_DEPS = "pixman libxfont2 xtrans libxau libxext libxdmcp libdrm
> > libxkbfile
> > libpciaccess libxcvt"
> > +LIB_DEPS = "pixman libxfont2 xtrans libxau libxext libxdmcp libdrm
> > libxkbfile
> > libpciaccess libxcvt libtirpc"
> > 
> 
> 
> Interesting. Do we know what the difference is?
> Perhaps a distro feature gap ? We should try to get poky close to no distro as
> it’s reference distro
> Less work in maintaining nodistro would be beneficial 

The difference is enable/disable of opengl. They are already very close, that is
one of the few major differences and in some ways it is useful to test both.

Cheers,

Richard
> 



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



Re: [OE-core] [pseudo] pseudo_fix_path: do not expand symlinks in /proc

2021-11-11 Thread Richard Purdie
On Thu, 2021-11-11 at 05:11 -0500, Sakib Sajal wrote:
> From: Matt Cowell 
> 
> Some symlinks in /proc, such as those under /proc/[pid]/fd,
> /proc/[pid]/cwd, and /proc/[pid]/exe that are not real and should not
> have readlink called on them.  These look like symlinks, but behave like
> hardlinks.  Readlink does not return actual paths.  Previously
> pseudo_fix_path would expand files such as /dev/stdin to paths such as
> /proc/6680/fd/pipe:[1270830076] which do not exist.
> 
> This issue affects:
> - deleted files
> - deleted directories
> - fifos
> - sockets
> - anon_inodes (epoll, eventfd, inotify, signalfd, timerfd, etc)
> 
> Testing:
> - run_tests: all tests passed (3 tests check the new code path).
>  Checked test output to make sure the new codepath gets executed.
> - perftest: measured time before and after applying the patch
> had insignificant differences (roughly ~1%)
> - world build: completed without warning/errors
> 
> Signed-off-by: Sakib Sajal 
> ---
>  pseudo_util.c | 17 +
>  1 file changed, 17 insertions(+)
> 
> diff --git a/pseudo_util.c b/pseudo_util.c
> index b6980c2..b9de81e 100644
> --- a/pseudo_util.c
> +++ b/pseudo_util.c
> @@ -29,6 +29,11 @@
>  #include "pseudo_ipc.h"
>  #include "pseudo_db.h"
>  
> +/* O_PATH is defined in glibc 2.16 and later only */
> +#ifndef O_PATH
> +#define O_PATH  01000
> +#endif
> +
>  struct pseudo_variables {
>   char *key;
>   size_t key_len;
> @@ -678,6 +683,18 @@ pseudo_append_element(char *newpath, char *root, size_t 
> allocated, char **pcurre
>*/
>   if (!leave_this && is_dir) {
>   int is_link = S_ISLNK(buf->st_mode);
> +
> + /* do not expand symlinks in the proc filesystem, since they 
> may not be real
> +  * check if newpath starts with "/proc/"
> +  * strlen of "/proc/" = 6
> +  */
> + if (is_link && (strncmp("/proc/", newpath, 6) == 0)) {
> + pseudo_debug(PDBGF_PATH | PDBGF_VERBOSE,
> + "pae: '%s' is procfs symlink, not expanding\n",
> + newpath);
> + is_link = 0;
> + }
> +
>   if (link_recursion >= PSEUDO_MAX_LINK_RECURSION && is_link) {
>   pseudo_diag("link recursion too deep, not expanding 
> path '%s'.\n", newpath);
>   is_link = 0;

I merged this into the pseudo repo and put an updated pseudo recipe into a
master-next build. This resulted in issues:

https://autobuilder.yoctoproject.org/typhoon/#/builders/122/builds/485/steps/13/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/116/builds/961
https://autobuilder.yoctoproject.org/typhoon/#/builders/118/builds/922

I've stopped the build since it is clear there is something wrong.

Cheers,

Richard



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



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

2021-11-11 Thread Richard Purdie
On Wed, 2021-11-10 at 08:07 -0500, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> Richard,
> 
> Here's the next round of -stable updates ... more active kernes, means
> more -stable!
> 
> I've also added -rt to 5.17 in this series.

5.17 is out now?! (sorry, couldn't help mention I'd noticed :)

> Finally, there is a non -stable patch for providing virtual/kernel to
> all kernel packages. I've had this patch done locally for ages, but
> my configurations are not as complex for multiple kernels and composite
> images as many .. so this is more of a RFC, to get feedback on cases
> that i've missed, or if the AB will pickup a problem (I've marked it
> with RFC).

It makes sense to me and seemed to work ok on the AB so it merged, thanks.

Cheers,

Richard


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



Re: [OE-core] [honister][PATCH] insane.bbclass: Add a check for directories that are expected to be empty

2021-11-11 Thread Richard Purdie
On Thu, 2021-11-11 at 09:42 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: Mittal, Anuj 
> > Sent: den 11 november 2021 04:06
> > To: Peter Kjellerstedt 
> > Subject: Re: [OE-core] [honister][PATCH] insane.bbclass: Add a check for
> > directories that are expected to be empty
> > 
> > On Wed, 2021-11-10 at 20:53 +, Peter Kjellerstedt wrote:
> > > > -Original Message-
> > > > From: openembedded-core@lists.openembedded.org  > > > c...@lists.openembedded.org> On Behalf Of Anuj Mittal
> > > > Sent: den 9 november 2021 15:36
> > > > To: openembedded-core@lists.openembedded.org; Peter Kjellerstedt
> > > > 
> > > > Subject: Re: [OE-core] [honister][PATCH] insane.bbclass: Add a
> > > > check for
> > > > directories that are expected to be empty
> > > > 
> > > > On Mon, 2021-11-08 at 18:10 +0100, Peter Kjellerstedt wrote:
> > > > > From: Peter Kjellerstedt 
> > > > > 
> > > > > The empty-dirs QA check verifies that all directories specified
> > > > > in
> > > > > QA_EMPTY_DIRS are empty. It is possible to specify why a
> > > > > directory is
> > > > > expected to be empty by defining
> > > > > QA_EMPTY_DIRS_RECOMMENDATION:,
> > > > > which will then be included in the error message if the directory
> > > > > is
> > > > > not empty. If it is not specified for a directory, then "but it
> > > > > is
> > > > > expected to be empty" will be used.
> > > > > 
> > > > > Change-Id: Ic61019528f4b22f26e42e78125a99666ae27c7f5
> > > > > Signed-off-by: Peter Kjellerstedt 
> > > > > ---
> > > > > 
> > > > > Compared to the corresponding patch for master, there are two
> > > > > differences:
> > > > > 
> > > > > * "/var/volatile" is not added to QA_EMPTY_DIRS by default.
> > > > > * "empty-dirs" is added to WARN_QA instead of ERROR_QA.
> > > > > 
> > > > > This should make it safe to add this QA test to Honister without
> > > > > introdusing any new QA errors, while still allowing the QA test to be
> > > > > activated for those who wants to use it.
> > > > 
> > > > Does it have to be enabled by default?
> > > 
> > > Well, it doesn't have to be enabled. However, without /var/volatile in
> > > QA_EMPTY_DIRS, there should be no warnings generated for OE-Core or
> > > OpenEmbedded so it should not hurt to have it in WARN_QA.
> > 
> > Right, but there could be unexpected warnings for other downstream
> > layers in release versions.
> 
> True, but they would still just be warnings.

In the context of backports, this needs to be handled carefully. You're
effectively asking for new feature backport here and people aren't happy when
stable branches suddenly show new warnings.

If the issue was of huge importance, that would be ok but I'm not sure that is
the case here, we've managed with the code as is for a long time.

Cheers,

Richard


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



Re: [OE-core] [PATCH 04/24] xserver-xorg: update 1.20.13 -> 21.1.1

2021-11-11 Thread Richard Purdie
On Thu, 2021-11-11 at 10:26 +, Richard Purdie via lists.openembedded.org
wrote:
> On Wed, 2021-11-10 at 20:39 +0100, Alexander Kanavin wrote:
> > libxcvt is a new dependency (thanks Oleksandr!).
> > 
> > Include ${libdir}/xorg/modules/input/*.so into the main
> > package (if for someone separate packaging matters, please
> > investigate what they do).
> > 
> > Remove options no longer present upstream.
> > 
> > Remove patches available upstream; drop a chunk as well.
> > 
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  .../xorg-xserver/xserver-xorg.inc |  7 +--
> >  ...-duplicate-definitions-of-IOPortBase.patch | 24 ++---
> >  ...probing-a-non-PCI-platform-device-on.patch | 34 -
> >  ...t-xtest-Initialize-array-with-braces.patch | 36 -
> >  .../xorg-xserver/xserver-xorg/pkgconfig.patch | 34 -
> >  .../xserver-xorg/sdksyms-no-build-path.patch  | 50 ---
> >  ...xorg_1.20.13.bb => xserver-xorg_21.1.1.bb} |  6 +--
> >  7 files changed, 7 insertions(+), 184 deletions(-)
> >  delete mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
> >  delete mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
> >  delete mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg/pkgconfig.patch
> >  delete mode 100644 
> > meta/recipes-graphics/xorg-xserver/xserver-xorg/sdksyms-no-build-path.patch
> >  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.13.bb => 
> > xserver-xorg_21.1.1.bb} (77%)
> > 
> 
> I think there is some dependency issue:
> 
> https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/4349
> 
> but I'm wondering why this only showed up on this rebuild and not previously
> too...

Sorry, it did and the buildbot UI let me miss it, it also failed here:

https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/4344

Cheers,

Richard



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



Re: [OE-core] [PATCH 04/24] xserver-xorg: update 1.20.13 -> 21.1.1

2021-11-11 Thread Richard Purdie
On Wed, 2021-11-10 at 20:39 +0100, Alexander Kanavin wrote:
> libxcvt is a new dependency (thanks Oleksandr!).
> 
> Include ${libdir}/xorg/modules/input/*.so into the main
> package (if for someone separate packaging matters, please
> investigate what they do).
> 
> Remove options no longer present upstream.
> 
> Remove patches available upstream; drop a chunk as well.
> 
> Signed-off-by: Alexander Kanavin 
> ---
>  .../xorg-xserver/xserver-xorg.inc |  7 +--
>  ...-duplicate-definitions-of-IOPortBase.patch | 24 ++---
>  ...probing-a-non-PCI-platform-device-on.patch | 34 -
>  ...t-xtest-Initialize-array-with-braces.patch | 36 -
>  .../xorg-xserver/xserver-xorg/pkgconfig.patch | 34 -
>  .../xserver-xorg/sdksyms-no-build-path.patch  | 50 ---
>  ...xorg_1.20.13.bb => xserver-xorg_21.1.1.bb} |  6 +--
>  7 files changed, 7 insertions(+), 184 deletions(-)
>  delete mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-Fix-segfault-on-probing-a-non-PCI-platform-device-on.patch
>  delete mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/0001-test-xtest-Initialize-array-with-braces.patch
>  delete mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/pkgconfig.patch
>  delete mode 100644 
> meta/recipes-graphics/xorg-xserver/xserver-xorg/sdksyms-no-build-path.patch
>  rename meta/recipes-graphics/xorg-xserver/{xserver-xorg_1.20.13.bb => 
> xserver-xorg_21.1.1.bb} (77%)
> 

I think there is some dependency issue:

https://autobuilder.yoctoproject.org/typhoon/#/builders/47/builds/4349

but I'm wondering why this only showed up on this rebuild and not previously
too...

Cheers,

Richard


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



Re: [OE-core] [PATCH] mirrors: Add uninative mirror on kernel.org

2021-11-10 Thread Richard Purdie
On Wed, 2021-11-10 at 20:44 +, Peter Kjellerstedt wrote:
> > -Original Message-
> > From: openembedded-core@lists.openembedded.org  > c...@lists.openembedded.org> On Behalf Of Richard Purdie
> > Sent: den 9 november 2021 14:22
> > To: openembedded-core@lists.openembedded.org
> > Subject: [OE-core] [PATCH] mirrors: Add uninative mirror on kernel.org
> > 
> > At the last nas outage, we realised that we don't have good mirrors of the
> > uninative tarball if our main system can't be accessed. kernel.org mirrors
> > some Yocto Project data so we've ensured uninative is there. Add the
> > appropriate
> > mirror url to make use of that.
> > 
> > Signed-off-by: Richard Purdie 
> > ---
> >  meta/classes/mirrors.bbclass | 1 +
> >  1 file changed, 1 insertion(+)
> > 
> > diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
> > index ba325a658bc..75eb86a7243 100644
> > --- a/meta/classes/mirrors.bbclass
> > +++ b/meta/classes/mirrors.bbclass
> > @@ -62,6 +62,7 @@ ftp://.*/.* http://sources.openembedded.org/ \n \
> >  npm://.*/?.*http://sources.openembedded.org/ \n \
> >  ${CPAN_MIRROR}  http://cpan.metacpan.org/ \n \
> >  ${CPAN_MIRROR}  http://search.cpan.org/CPAN/ \n \
> > +https?$://downloads.yoctoproject.org/releases/uninative/
> > https://mirrors.kernel.org/yocto/uninative/ \n \
> 
> The above looked very odd to me, having that dollar sign in the middle of 
> the regular expression. It wasn't until I was deep into the fetcher's code 
> that I realized that it is not actually one regular expression above, but 
> three, formatted as a URL...

It is all a bit crazy. This format is from the days of the fetcher before my
involvement and before it was the fetcher.

> However, based on the code in bitbake/lib/bb/fetch2/__init__.py:uri_replace(),
> AFAICT, the dollar sign should not be needed above, as it will be added for 
> the URI type regexp automatically. The same goes for the other two URLs in 
> mirrors.bbclass that use that formatting.

Right, I think I remember added the anchoring fix. We haven't cleaned up all the
urls out in the wild and I was being consistent with the other entries in this
case.

> While investigating this, I also tried to look in the bitbake documentation 
> for a description of the format used for the PREMIRRORS and MIRRORS variables,
> but I could not find any. There is only a simple example, without any 
> explanation for the actual format that is being used.

That doesn't surprise me, I still have trouble remembering all the
idiosyncrasies when trying to fix the mirror url code too. It would be good to
document it if anyone fancies trying.

Cheers,

Richard


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



Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3

2021-11-10 Thread Richard Purdie
On Wed, 2021-11-10 at 13:52 +, Jasper Orschulko wrote:
> Hi Richard,
> 
> > When you say "fixed refspec", will that be a definitive sha revision
> > or a tag?
> > We always force resolution of tags as they tend to cause problems and
> > can change even if it is bad form.
> 
> that's a good point. Actually, Martin and I have just been discussing
> this, as we noticed that this point actually got "lost" during our
> implementation. We are currently working on fixing this. Good to know
> how you handle this. I will keep you posted.

Ok, it is good to be clear on that one. I know the fact we hit the network for
tags does concern some but it really is the only way to handle them.

> > This is potentially a big issue. Cloning operations during parsing is
> > pretty
> > horrible. We'd not expect any thing being written out like that
> > during a parse.
> > It would probably work "ok" for one recipe but if you start getting
> > the hundreds
> > of git recipes we have in some layers, it wouldn't scale if we
> > allowed that :(.
> > 
> > Not sure what to recommend here but it is definitely problematic.
> 
> Just to make sure that we are on the same page: This ONLY affects
> recipes which use the repo fetcher. And it ONLY clones the repository
> containing the repo manifest (which tend to be small in size).

Correct, we are on the same page. This is still quite problematic as the recipes
are meant to parse quickly and a repository clone is definitely not expected.

> So unless developers start using hundreds of repo-based recipes, which I
> find a very unlikely scenario, this should not be an issue.

Even ten recipes using this will show a degradation in parsing speed and I do
get a lot of complaints when parsing slows down for any reason. The user doesn't
expect this and it won't be visible what bitbake is doing (sitting at 99% parsed
for a period).

Also, the "tend to be small" implies someone will create a huge one at some
point even if that is a bad idea for whatever reasons, I just know how these
things end up going :(.

> Unfortunately, I don't see any other way to access the repo manifest
> file, as we need to calculate the commit hashes of the git repos
> referenced in the repo manifest file. Otherwise, it is impossible for
> us to determinate the necessity of an update when SRCREV =
> "${AUTOREV}". 

Some further questions:

* Does it only clone a repo in the AUTOREV case?
* Could it only obtain the manifest file somehow without a clone of the repo?

> However, I see one potential improvement here. Currently the cloning of
> the manifest repo is done on a per-recipe basis. E.g. this means if we
> have 10 recipes inheriting a bbclass containing a repo fetcher, we will
> clone 10 identical manifest repos. We'll work on improving this.

At least for wget or git, it is assumed that for a given url, there would be one
tarball/clone and that there is locking in place to share it between them. This
means you'll see do_fetch tasks for binutils, binutils-cross-XXX, nativesdk-
binutils and binutils-native and one will block the others but the fetch will
happen once and be shared between them. I guess with repo it may not be as
simple as that but we should try and share what we can if possible.

Cheers,

Richard



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



Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3

2021-11-10 Thread Richard Purdie
On Tue, 2021-11-09 at 11:26 +, Jasper Orschulko wrote:
> 
> 
> > e) fetcher output is deterministic
> >  (i.e. if you fetch configuration XXX now it will match in future
> > exactly in 
> >  a clean build with a new DL_DIR)
> 
> check. When a fixed refspec is set within the recipe, the fetcher will
> check, if all repositories in the repo manifest are set to a fixed
> refspec as well and otherwise throw an error.

When you say "fixed refspec", will that be a definitive sha revision or a tag?
We always force resolution of tags as they tend to cause problems and can change
even if it is bad form.

> > f) network access is expected to work with the standard linux proxy
> > variables
> >  environment but only in the do_fetch tasks)
> 
> this should work, as we keep the GIT_PROXY_COMMAND environment and run
> repo via runfetchcmd(). Not further tested though.

If you're using runfetchcmd that should work.

> 
> > g) access during parsing has to be minimal, a "git ls-remote" for an
> > AUTOREV 
> >  git recipe might be ok but you can't expect to checkout a git tree
> 
> unfortunately, do to the nature of repo, we need to clone the manifest
> repo, so that we can run "git ls-remote" on the referenced git repos
> and therefore ensure that 

This is potentially a big issue. Cloning operations during parsing is pretty
horrible. We'd not expect any thing being written out like that during a parse.
It would probably work "ok" for one recipe but if you start getting the hundreds
of git recipes we have in some layers, it wouldn't scale if we allowed that :(.

Not sure what to recommend here but it is definitely problematic.

> 
Cheers,

Richard



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



Re: [OE-core] [PATCH] kexec-tools: upgrade 2.0.22 -> 2.0.23

2021-11-09 Thread Richard Purdie
On Tue, 2021-11-09 at 23:03 +0800, wangmy wrote:
> Signed-off-by: Wang Mingyu 
> ---
>  .../kexec/{kexec-tools_2.0.22.bb => kexec-tools_2.0.23.bb}  | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
>  rename meta/recipes-kernel/kexec/{kexec-tools_2.0.22.bb => 
> kexec-tools_2.0.23.bb} (97%)
> 
> diff --git a/meta/recipes-kernel/kexec/kexec-tools_2.0.22.bb 
> b/meta/recipes-kernel/kexec/kexec-tools_2.0.23.bb
> similarity index 97%
> rename from meta/recipes-kernel/kexec/kexec-tools_2.0.22.bb
> rename to meta/recipes-kernel/kexec/kexec-tools_2.0.23.bb
> index 95ff5e6ef8..906e5fcd26 100644
> --- a/meta/recipes-kernel/kexec/kexec-tools_2.0.22.bb
> +++ b/meta/recipes-kernel/kexec/kexec-tools_2.0.23.bb
> @@ -22,7 +22,7 @@ SRC_URI = 
> "${KERNELORG_MIRROR}/linux/utils/kernel/kexec/kexec-tools-${PV}.tar.gz
> 
> file://0001-kexec-arch-ppc-kexec-ppc.c-correct-double-definition.patch \
> "
>  
> -SRC_URI[sha256sum] = 
> "40623d4321be2865ef9ea2cd6ec998d31dcf93d0f74353cbd3aa06d8821e3e41"
> +SRC_URI[sha256sum] = 
> "c7dcc59f5b66004d9d91264324e20e0387ea263dbb449708fbf84a4e5ff7decc"
>  
>  inherit autotools update-rc.d systemd
>  

Fails to build on ppc:

https://autobuilder.yoctoproject.org/typhoon/#/builders/63/builds/4295
https://autobuilder.yoctoproject.org/typhoon/#/builders/107/builds/2335

Cheers,

Richard




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



[OE-core] [PATCH] mirrors: Add uninative mirror on kernel.org

2021-11-09 Thread Richard Purdie
At the last nas outage, we realised that we don't have good mirrors of the
uninative tarball if our main system can't be accessed. kernel.org mirrors
some Yocto Project data so we've ensured uninative is there. Add the appropriate
mirror url to make use of that.

Signed-off-by: Richard Purdie 
---
 meta/classes/mirrors.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes/mirrors.bbclass b/meta/classes/mirrors.bbclass
index ba325a658bc..75eb86a7243 100644
--- a/meta/classes/mirrors.bbclass
+++ b/meta/classes/mirrors.bbclass
@@ -62,6 +62,7 @@ ftp://.*/.* http://sources.openembedded.org/ \n \
 npm://.*/?.*http://sources.openembedded.org/ \n \
 ${CPAN_MIRROR}  http://cpan.metacpan.org/ \n \
 ${CPAN_MIRROR}  http://search.cpan.org/CPAN/ \n \
+https?$://downloads.yoctoproject.org/releases/uninative/ 
https://mirrors.kernel.org/yocto/uninative/ \n \
 "
 
 # Use MIRRORS to provide git repo fallbacks using the https protocol, for cases
-- 
2.32.0


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



Re: [OE-core] [PATCH 1/1] bitbake.conf: Set ZSTD_THREADS to half of cpu number

2021-11-09 Thread Richard Purdie
On Tue, 2021-11-09 at 10:56 +0100, Alexander Kanavin wrote:
> On Tue, 9 Nov 2021 at 10:51, Robert Yang  wrote:
> > > Maybe, but once we start doing tweaks like this, where do they stop? Hey,
> > I'd 
> > 
> > I think that it's not only a performance tweak, but this should be
> > considered
> > as
> > a bug since it would be failed to build on powerful machine, which isn't
> > good
> > for oe-core's user experience.
> > 
> 
> 
> I managed to bring down a powerful machine just yesterday by building webkit
> and llvm together at the same time. They together ate all the RAM, and someone
> in the office had to go and reset the box.
> Do I see it as a bug? Absolutely not: it's in fact my fault for not ensuring
> system resource consumption doesn't overwhelm the machine. This is the same:
> if you do not have RAM to match the cores on your specific rig, add RAM or
> limit the threads.

I can see both sides of this. If we had a pool for all the threads and the
pieces of the system all used the same pool, it would work well as implemented.
Sadly the bitbake threads, the make processes and now the compression threads
are all separate.

We do see the autobuilder break due to load issues too and on that we have
scaled back some of the defaults but not ZSTD as yet that I recall.

As such I think limiting the upper value on number of threads may be a good
compromise, both for compression and maybe for parallel make too.

Cheers,

Richard


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



Re: [OE-core] [PATCH] python3-nose: translate to python3 code before build

2021-11-08 Thread Richard Purdie
On Mon, 2021-11-08 at 14:55 +0800, Yi Zhao wrote:
> Setuptools has removed support for 2to3 during builds since version
> 58[1]. But the nose's setup.py relies on use_2to3 option in setuptools,
> it is failing an import and building without running 2to3 and generating
> valid python3 code. As a workaround, we use command line 2to3 tool to
> translate to Python3 code before build it.
> 
> Fixes:
> $ python3
> > > > import nose
> Traceback (most recent call last):
> File "", line 1, in 
> File "/usr/lib/python3.10/site-packages/nose/_init_.py", line 1, in 
> from nose.core import collector, main, run, run_exit, runmodule
> File "/usr/lib/python3.10/site-packages/nose/core.py", line 153
> print "%s version %s" % (os.path.basename(sys.argv[0]), _version_)
> 
> SyntaxError: Missing parentheses in call to 'print'. Did you mean print(...)?
> > > > 
> 
> [1] https://github.com/pypa/setuptools/issues/2086
> 
> Signed-off-by: Yi Zhao 
> ---
>  meta/recipes-devtools/python/python-nose.inc  |  6 ++
>  .../python3-nose/0001-Remove-use_2to3.patch   | 71 +++
>  2 files changed, 77 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/python/python3-nose/0001-Remove-use_2to3.patch

This failed in testing unfortunately:

https://autobuilder.yoctoproject.org/typhoon/#/builders/40/builds/4323/steps/14/logs/stdio

Cheers,

Richard


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



Re: [OE-core] [PATCH v3] glibc: ptest: Add running glibc time related test suite (Y2038) with ptest

2021-11-08 Thread Richard Purdie
On Mon, 2021-11-08 at 14:42 +0100, Lukasz Majewski wrote:
> Dear Community,
> 
> > This patch introduces new recipe - namely 'glibc-tests', which
> > builds and installs time related (to check if Y2038 support works)
> > glibc test suite to OE/Yocto built image.
> > 
> > It reuses code from already available 'glibc-testsuite' recipe,
> > which is run with 'bitbake glibc-testsuite -c check' and uses qemu
> > to execute remotely (via SSH) tests on some emulated machine.
> > 
> > This recipe installs time related glibc tests on some rootfs image.
> > Afterwards, those tests can be executed on the real hardware, to
> > facilitate validation of it with Y2038 problem compliance.
> > 
> > To test time related subset - one needs to call:
> > ptest-runner glibc-tests
> > then change the date after Y2038 threshold for 32 bit systems:
> > date -s "20 JAN 2038 18:00:00"
> > and then run ptest-runner again.
> > 
> > To facilitate debugging, source files are provided by default with
> > the unstripped debugging symbols. Such approach would reduce the
> > already complex recipe (as it inherits base glibc one), so there
> > is no need to also install *-dbg and *-src packages.
> > 
> 
> Gentle ping on this patch ...

There is a reply from Alexandre on the 29th which says:

"""
There is a remaining issue:

WARNING: Nothing RPROVIDES 'nativesdk-ptest-runner' (but 
virtual:nativesdk:/home/pokybuild/yocto-worker/build-appliance/build/meta/recipes-core/glibc/glibc-tests_2.34.bb
 RDEPENDS on or otherwise requires it)
NOTE: Runtime target 'nativesdk-ptest-runner' is unbuildable, removing...
Missing or unbuildable dependency chain was: ['nativesdk-ptest-runner']
"""

Cheers,

Richard


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



Re: [OE-core] broken dunfell

2021-11-08 Thread Richard Purdie
On Mon, 2021-11-08 at 12:23 +0100, Belisko Marek wrote:
> On Mon, Nov 8, 2021 at 12:08 PM Richard Purdie
>  wrote:
> > 
> > On Mon, 2021-11-08 at 11:53 +0100, Marek Belisko wrote:
> > > Hello, latest commit in meta-openembedded on dunfell branch raise an 
> > > error:
> > > 
> > > meta-openembedded/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb:14:
> > > unparsed line: 'RDEPENDS:${PN} += "${PYTHON_PN}-logging
> > > ${PYTHON_PN}-fcntl "'
> > > 
> > > Seems new syntax is used in this commit, fix is simple:
> > > 
> > > diff --git 
> > > a/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> > > b/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> > > index 1ba2c6f..7ebaa45 100644
> > > --- a/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> > > +++ b/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> > > @@ -8,7 +8,7 @@ SRC_URI[sha256sum] =
> > > "b1ab4e5adfbc28681ce44b3024421c4f567e705cc3963c732bf1cba334
> > > 
> > >  inherit pypi setuptools3
> > > 
> > > -RDEPENDS:${PN} += "\
> > > +RDEPENDS_${PN} += "\
> > >  ${PYTHON_PN}-logging \
> > >  ${PYTHON_PN}-fcntl \
> > >  "
> > > 
> > > Thanks and BR,
> > 
> > 
> > Whilst that probably shouldn't be there, I suspect if you upgrade bitbake 
> > you
> > won't see that issue.
> I want to say on dunfell due fact it's LTS release ;)
> 

Bitbake as well as OE-Core, meta-openembedded and Poky have LTS branches. I
doubt you're using the most recent revisions of bitbake on that LTS branch.

I wasn't suggesting you upgrade to the latest master.

Cheers,

Richard



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



Re: [OE-core] broken dunfell

2021-11-08 Thread Richard Purdie
On Mon, 2021-11-08 at 11:53 +0100, Marek Belisko wrote:
> Hello, latest commit in meta-openembedded on dunfell branch raise an error:
> 
> meta-openembedded/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb:14:
> unparsed line: 'RDEPENDS:${PN} += "${PYTHON_PN}-logging
> ${PYTHON_PN}-fcntl "'
> 
> Seems new syntax is used in this commit, fix is simple:
> 
> diff --git a/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> b/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> index 1ba2c6f..7ebaa45 100644
> --- a/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> +++ b/meta-python/recipes-devtools/python/python3-fasteners_0.16.3.bb
> @@ -8,7 +8,7 @@ SRC_URI[sha256sum] =
> "b1ab4e5adfbc28681ce44b3024421c4f567e705cc3963c732bf1cba334
> 
>  inherit pypi setuptools3
> 
> -RDEPENDS:${PN} += "\
> +RDEPENDS_${PN} += "\
>  ${PYTHON_PN}-logging \
>  ${PYTHON_PN}-fcntl \
>  "
> 
> Thanks and BR,


Whilst that probably shouldn't be there, I suspect if you upgrade bitbake you
won't see that issue.

Cheers,

Richard


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



Re: [OE-core] [V3][PATCH] ruby: workaround ptest hang problem

2021-11-08 Thread Richard Purdie
On Mon, 2021-11-08 at 12:02 +0800, Changqing Li wrote:
> On 11/6/21 5:27 PM, Richard Purdie wrote:
> > [Please note: This e-mail is from an EXTERNAL e-mail address]
> > 
> > On Fri, 2021-11-05 at 10:18 +0800, Changqing Li wrote:
> > > From: Changqing Li 
> > > 
> > > since openssl 3 not compatible problem, ruby have disable openssl
> > > extention. But disable openssl extention make test_smtp.rs hang at
> > > test case "test_start".
> > > 
> > > Net::TestSMTP#test_start:
> > > NameError: uninitialized constant Net::SMTP::OpenSSL
> > > Did you mean? Open3
> > > /usr/lib64/ruby/3.0.0/net/smtp.rb:195:in `default_ssl_context'
> > > /usr/lib64/ruby/3.0.0/net/smtp.rb:552:in `start'
> > > /usr/lib64/ruby/3.0.0/net/smtp.rb:475:in `start'
> > > /usr/lib64/ruby/ptest/test/net/smtp/test_smtp.rb:199:in `test_start'
> > > 
> > > temporarily remove the hang case to make other testcases can be run.
> > > 
> > > Meantime, move ruby-ptest out of the PTESTS_PROBLEMS list.
> > > On 48 core host, run ruby ptest in qemux86-64:
> > > root@qemux86-64:/usr/lib64/ruby/ptest# time ./run-ptest
> > > PASS: test/test_set.rb
> > > PASS: test/stringio/test_stringio.rb
> > > ...
> > > PASS: test/did_you_mean/test_tree_spell_checker.rb
> > > PASS: test/test_mutex_m.rb
> > > 
> > > real  5m42.872s
> > > user  3m50.923s
> > > sys   0m44.136s
> > > 
> > > Signed-off-by: Changqing Li 
> > > ---
> > >   meta/conf/distro/include/ptest-packagelists.inc | 3 +--
> > >   meta/recipes-devtools/ruby/ruby.inc | 4 
> > >   2 files changed, 5 insertions(+), 2 deletions(-)
> > Unfortunately the success rate isn't like that when we tried this on the
> > autobuilder, it failed on both arm64 and x86_64 with multiple failures:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2791
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2507
> 
> Sorry,  I thought this is expected.  Ruby have 800+ test cases, and 
> failed about
> 
> 30+ all the time.  so I think we still need to put ruby ptest in the  
> PTESTS_PROBLEMS list until
> 
> we address all the failed cases.

What we could do is mask out the failing cases. The issue is that we'll see
warnings on the autobuilder for cases that fail so we need to remove any "known
to fail" cases before we can enable by default there.

Cheers,

Richard


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



Re: [OE-core] [PATCH 1/3] wayland: Fix wayland-tools packaging problems

2021-11-07 Thread Richard Purdie
On Sun, 2021-11-07 at 10:00 -0600, Tom Hochstein wrote:
> There are several packaging problems due to the wayland-tools packaging
> implementation. The wayland-tools package currently looks like this:
> 
> wayland-tools
> └── usr
> ├── bin
> │   └── wayland-scanner
> └── share
> └── wayland
> ├── wayland.dtd
> ├── wayland-scanner.mk
> └── wayland.xml
> 
> The files wayland-scanner.pc and wayland-scanner.m4 are incorrectly
> located in the main package. The files wayland.dtd and wayland.xml
> are incorrectly located here but belong in the main package.
> 
> Fix the problems by moving wayland-tools before the other packages,
> adding wayland-tools-dev, and dropping the main package FILES
> variable override as no longer needed.
> 
> After the fix wayland-tools and wayland-tools-dev look like this:
> 
> wayland-tools
> └── usr
> └── bin
> └── wayland-scanner
> wayland-tools-dev
> └── usr
> ├── lib
> │   └── pkgconfig
> │   └── wayland-scanner.pc
> └── share
> ├── aclocal
> │   └── wayland-scanner.m4
> └── wayland
> └── wayland-scanner.mk
> 
> Signed-off-by: Tom Hochstein 
> ---
>  meta/recipes-graphics/wayland/wayland_1.19.0.bb | 10 +++---
>  1 file changed, 7 insertions(+), 3 deletions(-)
> 
> diff --git a/meta/recipes-graphics/wayland/wayland_1.19.0.bb 
> b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
> index d6e468497d..74d6d65e9e 100644
> --- a/meta/recipes-graphics/wayland/wayland_1.19.0.bb
> +++ b/meta/recipes-graphics/wayland/wayland_1.19.0.bb
> @@ -52,10 +52,14 @@ sysroot_stage_all:append:class-target () {
>   cp ${STAGING_DATADIR_NATIVE}/aclocal/wayland-scanner.m4 
> ${SYSROOT_DESTDIR}/${datadir}/aclocal/
>  }
>  
> -PACKAGES += "${PN}-tools"
> +PACKAGES =+ "${PN}-tools ${PN}-tools-dev"
>  
> -FILES:${PN} = "${libdir}/*${SOLIBS}"
> -FILES:${PN}-tools += "${bindir} ${datadir}/wayland"
> +FILES:${PN}-tools = "${bindir}/wayland-scanner"
> +FILES:${PN}-tools-dev = " \
> +${libdir}/pkgconfig/wayland-scanner.pc \
> +${datadir}/aclocal/wayland-scanner.m4 \
> +${datadir}/wayland/wayland-scanner.mk \
> +"
>  
>  BBCLASSEXTEND = "native nativesdk"
> 

Shouldn't these just go into wayland-dev?

Cheers,

Richard



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



Re: [OE-core] [bitbake-devel] [PATCH 2/2] fetch2: Fix race condition in latest_revision

2021-11-07 Thread Richard Purdie
On Fri, 2021-11-05 at 14:30 +0100, Jasper Orschulko via lists.openembedded.org
wrote:
> From: Martin Koppehel 
> 
> Setting latest_revision contained a race condition, where it would be
> set to an empty string, if the hash calculation function would take to
> long.
> 
> Signed-off-by: Jasper Orschulko 
> ---
>  lib/bb/fetch2/__init__.py | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/lib/bb/fetch2/__init__.py b/lib/bb/fetch2/__init__.py
> index 6a38cb09..9dc23d05 100644
> --- a/lib/bb/fetch2/__init__.py
> +++ b/lib/bb/fetch2/__init__.py
> @@ -1602,7 +1602,9 @@ class FetchMethod(object):
>  try:
>  return revs[key]
>  except KeyError:
> -revs[key] = rev = self._latest_revision(ud, d, name)
> +rev = self._latest_revision(ud, d, name)
> +if rev != '':
> +revs[key] = rev
>  return rev
>  
>  def sortable_revision(self, ud, d, name):

I'm afraid I don't understand why this is a race condition? Where is the timeout
that stops one being set?

Cheers,

Richard


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



Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3

2021-11-07 Thread Richard Purdie
On Fri, 2021-11-05 at 14:31 +0100, Jasper Orschulko via lists.openembedded.org
wrote:
> From: Jasper Orschulko 
> 
> Add a recipe for repo, prerequisite for the repo fetcher.
> 
> Signed-off-by: Jasper Orschulko 
> ---
>  .../repo/files/0001-python3-shebang.patch | 21 
>  .../0001-Set-REPO_REV-to-v2.17.3.patch| 33 +++
>  meta/recipes-devtools/repo/repo.inc   | 25 ++
>  meta/recipes-devtools/repo/repo_2.17.3.bb |  7 
>  4 files changed, 86 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/repo/files/0001-python3-shebang.patch
>  create mode 100644 
> meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
>  create mode 100644 meta/recipes-devtools/repo/repo.inc
>  create mode 100644 meta/recipes-devtools/repo/repo_2.17.3.bb

This basically looks ok to me, I've some minor comments below.

The patch is missing adding an entry to:

meta/conf/distro/include/maintainers.inc

which is required for OE-Core recipes and will trip up automated testing if we
don't.

> 
> diff --git a/meta/recipes-devtools/repo/files/0001-python3-shebang.patch 
> b/meta/recipes-devtools/repo/files/0001-python3-shebang.patch
> new file mode 100644
> index 00..09ccf58264
> --- /dev/null
> +++ b/meta/recipes-devtools/repo/files/0001-python3-shebang.patch


I'd put this in a folder called "repo" rather than files.

> @@ -0,0 +1,21 @@
> +From b8e84b202cd302a7c99288d3835dc9c63071f8f2 Mon Sep 17 00:00:00 2001
> +From: Jasper Orschulko 
> +Date: Tue, 14 Sep 2021 16:46:51 +0200
> +Subject: [PATCH] python3 shebang
> +
> +---
> + repo | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> 

Missing Upstream-Status: (you got the second one ok though! :)

> +diff --git a/repo b/repo
> +index b13e34c..205e0e5 100755
> +--- a/repo
>  b/repo
> +@@ -1,4 +1,4 @@
> +-#!/usr/bin/env python
> ++#!/usr/bin/env python3
> + # -*- coding:utf-8 -*-
> + #
> + # Copyright (C) 2008 The Android Open Source Project
> +--
> +2.33.0
> diff --git 
> a/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch 
> b/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
> new file mode 100644
> index 00..294a3af53a
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/repo/repo-2.17.3/0001-Set-REPO_REV-to-v2.17.3.patch
> @@ -0,0 +1,33 @@
> +From bdd2a528da59c28db8ae2986834926de7cebf3ab Mon Sep 17 00:00:00 2001
> +From: Jasper Orschulko 
> +Date: Thu, 4 Nov 2021 16:55:12 +0100
> +Subject: [PATCH] Set REPO_REV to v2.17.3
> +
> +repo is an unusual tool because it downloads all of its own Python modules
> +using GPG-signed git tags, and stores those files as part of the project
> +that it is working with.
> +
> +So in order to have a reproducible repo installation within the project
> +folders, we hardcode the REPO_REV variable to this recipes PV.
> +
> +Upstream-Status: Inappropriate [configuration]
> +Signed-off-by: Jasper Orschulko 
> +---
> + repo | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/repo b/repo
> +index 4cddbf1..cf5f6b1 100755
> +--- a/repo
>  b/repo
> +@@ -142,7 +142,7 @@ if __name__ == '__main__':
> + REPO_URL = os.environ.get('REPO_URL', None)
> + if not REPO_URL:
> +   REPO_URL = 'https://gerrit.googlesource.com/git-repo'
> +-REPO_REV = os.environ.get('REPO_REV')
> ++REPO_REV = 'v2.17.3'
> + if not REPO_REV:
> +   REPO_REV = 'stable'
> + # URL to file bug reports for repo tool issues.
> +--
> +2.33.1
> diff --git a/meta/recipes-devtools/repo/repo.inc 
> b/meta/recipes-devtools/repo/repo.inc
> new file mode 100644
> index 00..60b32e4d74
> --- /dev/null
> +++ b/meta/recipes-devtools/repo/repo.inc
> @@ -0,0 +1,25 @@
> +# SPDX-License-Identifier: MIT
> +# Copyright (C) 2021 iris-GmbH infrared & intelligent sensors
> +
> +SUMMARY = "Tool for managing many Git repositories"
> +DESCRIPTION = "Repo is a tool built on top of Git. Repo helps manage many 
> Git repositories, does the uploads to revision control systems, and automates 
> parts of the development workflow."
> +HOMEPAGE = "https://android.googlesource.com/tools/repo;
> +SECTION = "console/utils"
> +
> +LICENSE = "Apache-2.0"
> +
> +SRC_URI = 
> "git://g...@gerrit.googlesource.com/git-repo.git;protocol=https;branch=main"
> +MIRRORS = "git://g...@gerrit.googlesource.com/git-repo.git 
> git://github.com/GerritCodeReview/git-repo.git \n"

You shouldn't be clearing MIRRORS with "=" as the user may have something set in
there the system needs to work, you probably want += here.

> +
> +SRC_URI += "file://0001-python3-shebang.patch"
> +
> +S = "${WORKDIR}/git"
> +
> +RDEPENDS_${PN} = "python3"

This is old overrides syntax, it is RDEPENDS:${PN} now as others have mentioned.

> +
> +do_install() {
> +install -d ${D}${bindir}
> +install -m 755 ${WORKDIR}/git/repo ${D}${bindir}
> +}
> +
> +BBCLASSEXTEND = "native nativesdk"
> diff --git a/meta/recipes-devtools/repo/repo_2.17.3.bb 
> 

Re: [bitbake-devel] [oe-core][PATCH 1/2] devtools: Initial recipe for repo 2.17.3

2021-11-06 Thread Richard Purdie
On Fri, 2021-11-05 at 14:09 +, Jasper Orschulko wrote:
> Actually, I don't believe this to be an issue for the following
> reasons:
> 
> [...]
>
> 2. When using repo within the yocto build itself (with the repo
> fetcher), the repo binary is only ever called during the do_fetch step,
> which obviously has no issues with any network access.

This is not true. The system may be configured for no network access and is
meant just to be building from MIRRORS/PREMIRRORS (see also BB_NO_NETWORK).

One of the reasons for the fetcher abstraction is to allow us to support
features like that. do_fetch is where network access should happen, if the
system is configured for it.

I guess the question becomes whether the usages of repo when using DL_DIR as a
cache will still touch the network?

Cheers,

Richard





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



Re: [OE-core] [V3][PATCH] ruby: workaround ptest hang problem

2021-11-06 Thread Richard Purdie
On Fri, 2021-11-05 at 10:18 +0800, Changqing Li wrote:
> From: Changqing Li 
> 
> since openssl 3 not compatible problem, ruby have disable openssl
> extention. But disable openssl extention make test_smtp.rs hang at
> test case "test_start".
> 
> Net::TestSMTP#test_start:
> NameError: uninitialized constant Net::SMTP::OpenSSL
> Did you mean? Open3
> /usr/lib64/ruby/3.0.0/net/smtp.rb:195:in `default_ssl_context'
> /usr/lib64/ruby/3.0.0/net/smtp.rb:552:in `start'
> /usr/lib64/ruby/3.0.0/net/smtp.rb:475:in `start'
> /usr/lib64/ruby/ptest/test/net/smtp/test_smtp.rb:199:in `test_start'
> 
> temporarily remove the hang case to make other testcases can be run.
> 
> Meantime, move ruby-ptest out of the PTESTS_PROBLEMS list.
> On 48 core host, run ruby ptest in qemux86-64:
> root@qemux86-64:/usr/lib64/ruby/ptest# time ./run-ptest
> PASS: test/test_set.rb
> PASS: test/stringio/test_stringio.rb
> ...
> PASS: test/did_you_mean/test_tree_spell_checker.rb
> PASS: test/test_mutex_m.rb
> 
> real  5m42.872s
> user  3m50.923s
> sys   0m44.136s
> 
> Signed-off-by: Changqing Li 
> ---
>  meta/conf/distro/include/ptest-packagelists.inc | 3 +--
>  meta/recipes-devtools/ruby/ruby.inc | 4 
>  2 files changed, 5 insertions(+), 2 deletions(-)

Unfortunately the success rate isn't like that when we tried this on the
autobuilder, it failed on both arm64 and x86_64 with multiple failures:

https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2791
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2507


Cheers,

Richard


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



Re: [OE-core] [PATCH 1/2] gdb: Upgrade to 11.1

2021-11-05 Thread Richard Purdie
On Fri, 2021-11-05 at 09:51 -0700, Khem Raj wrote:
> On Fri, Nov 5, 2021 at 4:19 AM Richard Purdie
>  wrote:
> > 
> > On Wed, 2021-11-03 at 18:30 -0700, Khem Raj wrote:
> > > Drop backported patches
> > > Changes are here [1]
> > > 
> > > [1] https://sourceware.org/pipermail/gdb-announce/2021/000129.html
> > > 
> > > Signed-off-by: Khem Raj 
> > > ---
> > >  meta/conf/distro/include/tcmode-default.inc   |   2 +-
> > >  .../gdb/{gdb-10.2.inc => gdb-11.1.inc}|  14 +-
> > >  ...ian_10.2.bb => gdb-cross-canadian_11.1.bb} |   0
> > >  .../{gdb-cross_10.2.bb => gdb-cross_11.1.bb}  |   0
> > >  ...make-man-install-relative-to-DESTDIR.patch |  20 +-
> > >  ...ux-nat-Define-_ABIO32-if-not-defined.patch |   8 +-
> > >  ...e-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch |  10 +-
> > >  ...port-for-Renesas-SH-sh4-architecture.patch |  39 +-
> > >  ...readline.a-when-using-disable-static.patch |  12 +-
> > >  .../gdb/gdb/0006-use-asm-sgidefs.h.patch  |   8 +-
> > >  ...atch => 0007-Change-order-of-CFLAGS.patch} |  12 +-
> > >  ...8-resolve-restrict-keyword-conflict.patch} |   8 +-
> > >  ...> 0009-Fix-invalid-sigprocmask-call.patch} |   8 +-
> > >  ...h => 0010-gdbserver-ctrl-c-handling.patch} |  10 +-
> > >  ...-arc-Add-support-for-signal-handlers.patch | 218 -
> > >  ...-for-signal-frames-for-Linux-targets.patch | 232 --
> > >  ...count-the-REGNUM-in-supply-collect-g.patch | 104 -
> > >  ...-native-support-for-ARC-in-GNU-Linux.patch | 414 --
> > >  .../gdb/{gdb_10.2.bb => gdb_11.1.bb}  |   0
> > >  19 files changed, 74 insertions(+), 1045 deletions(-)
> > >  rename meta/recipes-devtools/gdb/{gdb-10.2.inc => gdb-11.1.inc} (56%)
> > >  rename meta/recipes-devtools/gdb/{gdb-cross-canadian_10.2.bb => 
> > > gdb-cross-canadian_11.1.bb} (100%)
> > >  rename meta/recipes-devtools/gdb/{gdb-cross_10.2.bb => 
> > > gdb-cross_11.1.bb} (100%)
> > >  rename meta/recipes-devtools/gdb/gdb/{0008-Change-order-of-CFLAGS.patch 
> > > => 0007-Change-order-of-CFLAGS.patch} (75%)
> > >  rename 
> > > meta/recipes-devtools/gdb/gdb/{0009-resolve-restrict-keyword-conflict.patch
> > >  => 0008-resolve-restrict-keyword-conflict.patch} (91%)
> > >  rename 
> > > meta/recipes-devtools/gdb/gdb/{0010-Fix-invalid-sigprocmask-call.patch => 
> > > 0009-Fix-invalid-sigprocmask-call.patch} (90%)
> > >  rename 
> > > meta/recipes-devtools/gdb/gdb/{0011-gdbserver-ctrl-c-handling.patch => 
> > > 0010-gdbserver-ctrl-c-handling.patch} (82%)
> > >  delete mode 100644 
> > > meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch
> > >  delete mode 100644 
> > > meta/recipes-devtools/gdb/gdb/0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch
> > >  delete mode 100644 
> > > meta/recipes-devtools/gdb/gdb/0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch
> > >  delete mode 100644 
> > > meta/recipes-devtools/gdb/gdb/0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch
> > >  rename meta/recipes-devtools/gdb/{gdb_10.2.bb => gdb_11.1.bb} (100%)
> > 
> > Breaks on mingw:
> > 
> > https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/4299
> > 
> 
> I see
> 
> > sys-linux.c:140:10: fatal error: linux/ipx.h: No such file or directory
> >   140 | #include 
> >   |  ^
> > compilation terminated.
> > make[1]: *** [: sys-linux.o] Error 1
> > make[1]: Leaving directory
> '/home/pokybuild/yocto-worker/musl-qemux86/build/build/tmp/work/core2-32-poky-linux-musl/ppp/2.4.9-r0/ppp-2.4.9/pppd'
> 
> perhaps wrong link ?

Sorry, https://autobuilder.yoctoproject.org/typhoon/#/builders/89/builds/4293

Cheers,

Richard



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



Re: [OE-core] [PATCH 1/2] gdb: Upgrade to 11.1

2021-11-05 Thread Richard Purdie
On Wed, 2021-11-03 at 18:30 -0700, Khem Raj wrote:
> Drop backported patches
> Changes are here [1]
> 
> [1] https://sourceware.org/pipermail/gdb-announce/2021/000129.html
> 
> Signed-off-by: Khem Raj 
> ---
>  meta/conf/distro/include/tcmode-default.inc   |   2 +-
>  .../gdb/{gdb-10.2.inc => gdb-11.1.inc}|  14 +-
>  ...ian_10.2.bb => gdb-cross-canadian_11.1.bb} |   0
>  .../{gdb-cross_10.2.bb => gdb-cross_11.1.bb}  |   0
>  ...make-man-install-relative-to-DESTDIR.patch |  20 +-
>  ...ux-nat-Define-_ABIO32-if-not-defined.patch |   8 +-
>  ...e-pt_regs-uapi_pt_regs-on-GLIBC-syst.patch |  10 +-
>  ...port-for-Renesas-SH-sh4-architecture.patch |  39 +-
>  ...readline.a-when-using-disable-static.patch |  12 +-
>  .../gdb/gdb/0006-use-asm-sgidefs.h.patch  |   8 +-
>  ...atch => 0007-Change-order-of-CFLAGS.patch} |  12 +-
>  ...8-resolve-restrict-keyword-conflict.patch} |   8 +-
>  ...> 0009-Fix-invalid-sigprocmask-call.patch} |   8 +-
>  ...h => 0010-gdbserver-ctrl-c-handling.patch} |  10 +-
>  ...-arc-Add-support-for-signal-handlers.patch | 218 -
>  ...-for-signal-frames-for-Linux-targets.patch | 232 --
>  ...count-the-REGNUM-in-supply-collect-g.patch | 104 -
>  ...-native-support-for-ARC-in-GNU-Linux.patch | 414 --
>  .../gdb/{gdb_10.2.bb => gdb_11.1.bb}  |   0
>  19 files changed, 74 insertions(+), 1045 deletions(-)
>  rename meta/recipes-devtools/gdb/{gdb-10.2.inc => gdb-11.1.inc} (56%)
>  rename meta/recipes-devtools/gdb/{gdb-cross-canadian_10.2.bb => 
> gdb-cross-canadian_11.1.bb} (100%)
>  rename meta/recipes-devtools/gdb/{gdb-cross_10.2.bb => gdb-cross_11.1.bb} 
> (100%)
>  rename meta/recipes-devtools/gdb/gdb/{0008-Change-order-of-CFLAGS.patch => 
> 0007-Change-order-of-CFLAGS.patch} (75%)
>  rename 
> meta/recipes-devtools/gdb/gdb/{0009-resolve-restrict-keyword-conflict.patch 
> => 0008-resolve-restrict-keyword-conflict.patch} (91%)
>  rename 
> meta/recipes-devtools/gdb/gdb/{0010-Fix-invalid-sigprocmask-call.patch => 
> 0009-Fix-invalid-sigprocmask-call.patch} (90%)
>  rename meta/recipes-devtools/gdb/gdb/{0011-gdbserver-ctrl-c-handling.patch 
> => 0010-gdbserver-ctrl-c-handling.patch} (82%)
>  delete mode 100644 
> meta/recipes-devtools/gdb/gdb/0012-arc-Add-support-for-signal-handlers.patch
>  delete mode 100644 
> meta/recipes-devtools/gdb/gdb/0013-arc-Add-support-for-signal-frames-for-Linux-targets.patch
>  delete mode 100644 
> meta/recipes-devtools/gdb/gdb/0014-arc-Take-into-account-the-REGNUM-in-supply-collect-g.patch
>  delete mode 100644 
> meta/recipes-devtools/gdb/gdb/0015-gdb-Add-native-support-for-ARC-in-GNU-Linux.patch
>  rename meta/recipes-devtools/gdb/{gdb_10.2.bb => gdb_11.1.bb} (100%)

Breaks on mingw:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/4299

Cheers,

Richard


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



Re: [OE-core] [PATCH 3/6] linux-libc-headers: update to v5.15

2021-11-05 Thread Richard Purdie
On Thu, 2021-11-04 at 15:48 -0400, bruce.ashfi...@gmail.com wrote:
> From: Bruce Ashfield 
> 
> No patches needed refreshing or removal, so we just update the
> SRC_URI and pick up the latest uapi / kernel headers.
> 
> Signed-off-by: Bruce Ashfield 
> ---
>  meta/conf/distro/include/tcmode-default.inc   | 2 +-
>  ...{linux-libc-headers_5.14.bb => linux-libc-headers_5.15.bb} | 4 ++--
>  2 files changed, 3 insertions(+), 3 deletions(-)
>  rename meta/recipes-kernel/linux-libc-headers/{linux-libc-headers_5.14.bb => 
> linux-libc-headers_5.15.bb} (81%)
> 
> diff --git a/meta/conf/distro/include/tcmode-default.inc 
> b/meta/conf/distro/include/tcmode-default.inc
> index 58f49800c4..86a6b50433 100644
> --- a/meta/conf/distro/include/tcmode-default.inc
> +++ b/meta/conf/distro/include/tcmode-default.inc
> @@ -21,7 +21,7 @@ SDKGCCVERSION ?= "${GCCVERSION}"
>  BINUVERSION ?= "2.37%"
>  GDBVERSION ?= "10.%"
>  GLIBCVERSION ?= "2.34"
> -LINUXLIBCVERSION ?= "5.14%"
> +LINUXLIBCVERSION ?= "5.15%"
>  QEMUVERSION ?= "6.1%"
>  GOVERSION ?= "1.16%"
>  # This can not use wildcards like 8.0.% since it is also used in mesa to 
> denote
> diff --git 
> a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.14.bb 
> b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.15.bb
> similarity index 81%
> rename from meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.14.bb
> rename to meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.15.bb
> index 282c04d79c..588cc3acd1 100644
> --- a/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.14.bb
> +++ b/meta/recipes-kernel/linux-libc-headers/linux-libc-headers_5.15.bb
> @@ -14,7 +14,7 @@ SRC_URI:append = "\
>  
>  LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
>  
> -SRC_URI[md5sum] = "a082ef5748b813abca0649dab8be5f52"
> -SRC_URI[sha256sum] = 
> "7e068b5e0d26a62b10e5320b25dce57588cbbc6f781c090442138c9c9c3271b2"
> +SRC_URI[md5sum] = "071d49ff4e020d58c04f9f3f76d3b594"
> +SRC_URI[sha256sum] = 
> "57b2cf6991910e3b67a1b3490022e8a0674b6965c74c12da1e99d138d1991ee8"
>  
> 

Looks like there is a musl issue with the ipx.h header in ppp:

https://autobuilder.yoctoproject.org/typhoon/#/builders/64/builds/4299
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/4313

Cheers,

Richard





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



Re: [OE-core] [PATCH] opkg: Fix poor operator combination choice

2021-11-04 Thread Richard Purdie
On Thu, 2021-11-04 at 17:05 -0500, Alex Stewart wrote:
> On 11/4/21 09:35, Mikko Rapeli wrote:
> > On Thu, Nov 04, 2021 at 02:02:57PM +, Richard Purdie wrote:
> > > Combining :append with += rarely makes sense. Improve it to use the 
> > > standard
> > > format (and tweak the implied spacing).
> > Maybe I'm silly but I find :append with += safer to do than manually 
> > remembring
> > to add the space character.
> 
> I tend to agree; hence why I wrote it that way in the original patch. 
> But I'm not going to defend the practice in this case, so ACK from me 
> either way.

There is a patch on the bitbake list which would make this usage a warning. It
certainly isn't obvious to most new users that:

YYY:append += "XXX"

really means

YYY:append = " XXX"

so I tend to prefer the later as being much clearer about what is happening.
Part of what we need to to improve usability is to remove some of these
confusions so standardising on things like this seems to make sense.

> I'm intending to drop this recipe warning after the opkg_0.5.0 release 
> in December. So the recipe-as-written will only exist in the mainline 
> for another few months.

Sounds good.

Cheers,

Richard




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



Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

2021-11-04 Thread Richard Purdie
On Thu, 2021-11-04 at 15:45 -0500, Joshua Watt wrote:
> On 11/4/21 3:43 PM, Richard Purdie wrote:
> > On Thu, 2021-11-04 at 20:00 +, Jose Quaresma wrote:
> > > 
> > > Richard Purdie  escreveu no dia 
> > > quinta,
> > > 28/10/2021 à(s) 21:58:
> > > > On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > > > > On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma 
> > > > > 
> > > > wrote:
> > > > > > Hi all,
> > > > > > 
> > > > > > There are any plans or is it possible to backport the SBOM/SPDX to 
> > > > > > the
> > > > dunfell branch?
> > > > > I'm going to yield to Saul as to whether he thinks this is
> > > > > desirable/possible or not.
> > > > The packagedata changes are pretty invasive unfortunately and likely not
> > > > something you're going to want in dunfell sadly.
> > > > 
> > > 
> > > Thanks for the clarification.
> > > 
> > I have been thinking a bit more about this. I did wonder if we should 
> > consider a
> > mixin layer of some kind for it that could work with dunfell?
> > 
> > We could host it, it is just a question of writing the mixin layer and
> > maintaining it.
> 
> I don't think it's going to be possible with a pure mixin layer, since 
> it relies on the extended package data?

I suspect that could perhaps be patched in through a layer though? You might
choose to drop the compression piece or do it differently for the backport?

Cheers,

Richard


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



Re: [OE-core] [PATCH 0/3] SPDX: Add annotations to relationship

2021-11-04 Thread Richard Purdie
On Thu, 2021-11-04 at 20:00 +, Jose Quaresma wrote:
> 
> 
> Richard Purdie  escreveu no dia quinta,
> 28/10/2021 à(s) 21:58:
> > On Thu, 2021-10-28 at 08:47 -1000, Steve Sakoman wrote:
> > > On Tue, Oct 26, 2021 at 10:41 PM Jose Quaresma 
> > wrote:
> > > > 
> > > > Hi all,
> > > > 
> > > > There are any plans or is it possible to backport the SBOM/SPDX to the
> > dunfell branch?
> > > 
> > > I'm going to yield to Saul as to whether he thinks this is
> > > desirable/possible or not.
> > 
> > The packagedata changes are pretty invasive unfortunately and likely not
> > something you're going to want in dunfell sadly.
> > 
> 
> 
> Thanks for the clarification.
> 

I have been thinking a bit more about this. I did wonder if we should consider a
mixin layer of some kind for it that could work with dunfell?

We could host it, it is just a question of writing the mixin layer and
maintaining it.

Cheers,

Richard


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



[OE-core] [PATCH] opkg: Fix poor operator combination choice

2021-11-04 Thread Richard Purdie
Combining :append with += rarely makes sense. Improve it to use the standard
format (and tweak the implied spacing).

Signed-off-by: Richard Purdie 
---
 meta/recipes-devtools/opkg/opkg_0.4.5.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/opkg/opkg_0.4.5.bb 
b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
index 2760fc58786..8af047a51ff 100644
--- a/meta/recipes-devtools/opkg/opkg_0.4.5.bb
+++ b/meta/recipes-devtools/opkg/opkg_0.4.5.bb
@@ -60,7 +60,7 @@ do_install_ptest () {
sed -i -e '/@PYTHONPATH=. $(PYTHON) $^/a\\t@if [ "$$?" != "0" ];then 
echo "FAIL:"$^;else echo "PASS:"$^;fi' ${D}${PTEST_PATH}/tests/Makefile
 }
 
-WARN_QA:append += "openssl-deprecation"
+WARN_QA:append = " openssl-deprecation"
 QAPKGTEST[openssl-deprecation] = "package_qa_check_openssl_deprecation"
 def package_qa_check_openssl_deprecation (package, d, messages):
 sane = True
-- 
2.32.0


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



[OE-core] [PATCH RFC 1/2] package: Introduce PACKAGE_GLOBAL_RENAMES

2021-11-04 Thread Richard Purdie
Allow renaming of packages on a global basis to work, e.g.:

PACKAGE_GLOBAL_RENAMES[bash] = "busybox"

Note this happens at package creation time and build time dependencies
remain as written.

This does have the potential to replace the horrific VIRTUAL-RUNTIME*
variables, see the follow up patch.

Signed-off-by: Richard Purdie 
---
 meta/classes/image.bbclass |  7 ---
 meta/classes/package.bbclass   | 16 ++--
 meta/classes/populate_sdk_base.bbclass |  9 +
 3 files changed, 19 insertions(+), 13 deletions(-)

diff --git a/meta/classes/image.bbclass b/meta/classes/image.bbclass
index 2fa69a40d10..b3f5421697d 100644
--- a/meta/classes/image.bbclass
+++ b/meta/classes/image.bbclass
@@ -236,9 +236,10 @@ fakeroot python do_rootfs () {
 # otherwise, the multilib renaming could step in and squash any fixups that
 # may have occurred.
 pn = d.getVar('PN')
-runtime_mapping_rename("PACKAGE_INSTALL", pn, d)
-runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", pn, d)
-runtime_mapping_rename("BAD_RECOMMENDATIONS", pn, d)
+remaps = d.getVarFlags("PACKAGE_GLOBAL_RENAMES")
+runtime_mapping_rename("PACKAGE_INSTALL", pn, remaps, d)
+runtime_mapping_rename("PACKAGE_INSTALL_ATTEMPTONLY", pn, remaps, d)
+runtime_mapping_rename("BAD_RECOMMENDATIONS", pn, remaps, d)
 
 # Generate the initial manifest
 create_manifest(d)
diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 92eba988929..aad58ead977 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -612,9 +612,12 @@ def copydebugsources(debugsrcdir, sources, d):
 # Package data handling routines
 #
 
-def get_package_mapping (pkg, basepkg, d, depversions=None):
+def get_package_mapping(pkg, basepkg, remaps, d, depversions=None):
 import oe.packagedata
 
+if pkg in remaps:
+pkg = remaps[pkg]
+
 data = oe.packagedata.read_subpkgdata(pkg, d)
 key = "PKG:%s" % pkg
 
@@ -646,13 +649,13 @@ def get_package_additional_metadata (pkg_type, d):
 metadata_fields = [field.strip() for field in oe.data.typed_value(key, 
d)]
 return "\n".join(metadata_fields).strip()
 
-def runtime_mapping_rename (varname, pkg, d):
+def runtime_mapping_rename(varname, pkg, remaps, d):
 #bb.note("%s before: %s" % (varname, d.getVar(varname)))
 
 new_depends = {}
 deps = bb.utils.explode_dep_versions2(d.getVar(varname) or "")
 for depend, depversions in deps.items():
-new_depend = get_package_mapping(depend, pkg, d, depversions)
+new_depend = get_package_mapping(depend, pkg, remaps, d, depversions)
 if depend != new_depend:
 bb.note("package name mapping done: %s -> %s" % (depend, 
new_depend))
 new_depends[new_depend] = deps[depend]
@@ -2512,6 +2515,7 @@ def mapping_rename_hook(d):
 like debian.bbclass or manual PKG variable name changes
 """
 pkg = d.getVar("PKG")
-runtime_mapping_rename("RDEPENDS", pkg, d)
-runtime_mapping_rename("RRECOMMENDS", pkg, d)
-runtime_mapping_rename("RSUGGESTS", pkg, d)
+remaps = d.getVarFlags("PACKAGE_GLOBAL_RENAMES")
+runtime_mapping_rename("RDEPENDS", pkg, remaps, d)
+runtime_mapping_rename("RRECOMMENDS", pkg, remaps, d)
+runtime_mapping_rename("RSUGGESTS", pkg, remaps, d)
diff --git a/meta/classes/populate_sdk_base.bbclass 
b/meta/classes/populate_sdk_base.bbclass
index fafdd96749c..55c36e1108d 100644
--- a/meta/classes/populate_sdk_base.bbclass
+++ b/meta/classes/populate_sdk_base.bbclass
@@ -152,13 +152,14 @@ def populate_sdk_common(d):
 d.setVar("PACKAGE_INSTALL_ATTEMPTONLY", ' '.join(inst_attempt_pkgs))
 
 pn = d.getVar('PN')
-runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", pn, d)
-runtime_mapping_rename("TOOLCHAIN_TARGET_TASK_ATTEMPTONLY", pn, d)
+remaps = d.getVarFlags("PACKAGE_GLOBAL_RENAMES")
+runtime_mapping_rename("TOOLCHAIN_TARGET_TASK", pn, remaps, d)
+runtime_mapping_rename("TOOLCHAIN_TARGET_TASK_ATTEMPTONLY", pn, remaps, d)
 
 ld = bb.data.createCopy(d)
 ld.setVar("PKGDATA_DIR", 
"${STAGING_DIR}/${SDK_ARCH}-${SDKPKGSUFFIX}${SDK_VENDOR}-${SDK_OS}/pkgdata")
-runtime_mapping_rename("TOOLCHAIN_HOST_TASK", pn, ld)
-runtime_mapping_rename("TOOLCHAIN_HOST_TASK_ATTEMPTONLY", pn, ld)
+runtime_mapping_rename("TOOLCHAIN_HOST_TASK", pn, remaps, ld)
+runtime_mapping_rename("TOOLCHAIN_HOST_TASK_ATTEMPTONLY", pn, remaps, ld)
 d.setVar("TOOLCHAIN_HOST_TASK", ld.getVar("TOOLCHAIN_HOST_TASK"))
 d.setVar("TOOLCHAIN_HOST_TASK_ATTEMPTONLY", 
ld.getVar("TOOLCHAIN_HOST

[OE-core] [PATCH RFC 2/2] conf/recipes: Replace VIRTUAL-RUNTIME with PACKAGE_GLOBAL_RENAMES

2021-11-04 Thread Richard Purdie
I don't think anyone has ever liked VIRTUAL-RUNTIME as a solution. This patch
replaces it with PACKAGE_GLOBAL_RENAME.

There are two types of VIRTUAL-RUNTIME. Direct package replacements like
getopt or keymaps and "namespaces" for things like "device-manager" or
"login-manager". The later are different in that one recipe may provide
several but they need to be configured individually. If they were all
"systemd", we couldn't replace the correct ones.

As such this patch introduces the "virtual-XXX" namespace where the
system is expected to resolve these into final values as per the configuration.

The advantage of this approach is that we no longer need to have specific
VIRTUAL-RUNTIME parameterisation for a user to change a particular dependency,
they can just do things like:

PACKAGE_GLOBAL_RENAME[keymaps] = "mykeymaps"

or simply:

PACKAGE_GLOBAL_RENAME[keymaps] = ""

to remove it. You can see examples of the virtual-* mappings in the init 
manager includes.

This patch uses the PACKAGE_GLOBAL_RENAMES variable and mechanism from the
previous patch to function but to be clear, this only works at package
creation time, not at build time. As such we have to inject the virtual
namespace into RPROVIDES. Filtering all package variables at parse time
isn't really viable at present (the multilib classes show the work involved).

Known issues:
a) The changes apply at final image build time which means that the original
provider would be built and the alternate only swapped in at do_rootfs.
b) The patch throwns build-rdeps QA warnings (probably as a result of a).
c) As a result of b) there are probably missing build dependencies
d) The tests are unconverted.

As such I suspect this patch won't quite work but I want to share it and
see what people think and if a better solution could rise from this as a
result. Adding "filter" support to variables as JPEW and I once discussed
may be a different way of handling this which would also handle some multilib
issues.

Signed-off-by: Richard Purdie 
---
 meta/classes/base.bbclass |  6 +
 meta/classes/image.bbclass|  3 ++-
 meta/classes/multilib_global.bbclass  |  5 +
 meta/classes/package.bbclass  |  4 +++-
 meta/classes/packagegroup.bbclass |  4 ++--
 meta/classes/update-alternatives.bbclass  |  5 +
 .../conf/distro/include/default-providers.inc | 13 +--
 .../include/init-manager-mdev-busybox.inc |  9 
 .../conf/distro/include/init-manager-none.inc |  7 +++---
 .../distro/include/init-manager-systemd.inc   |  9 
 .../distro/include/init-manager-sysvinit.inc  |  7 +++---
 meta/conf/layer.conf  |  2 +-
 meta/lib/oe/rootfs.py |  2 +-
 meta/recipes-core/busybox/busybox.inc |  4 ++--
 meta/recipes-core/busybox/busybox_1.34.1.bb   |  6 ++---
 .../images/core-image-minimal-initramfs.bb|  2 +-
 .../images/core-image-tiny-initramfs.bb   |  4 +---
 .../initrdscripts/initramfs-framework_1.0.bb  |  4 ++--
 .../initramfs-live-install-efi_1.0.bb |  4 ++--
 .../initramfs-live-install_1.0.bb |  4 ++--
 .../initramfs-module-install-efi_1.0.bb   |  4 ++--
 .../initramfs-module-install_1.0.bb   |  4 ++--
 .../packagegroups/packagegroup-base.bb|  9 +++-
 .../packagegroups/packagegroup-core-boot.bb   | 22 ---
 meta/recipes-devtools/dpkg/dpkg.inc   |  2 +-
 meta/recipes-devtools/opkg/opkg_0.4.5.bb  |  2 +-
 meta/recipes-extended/lsb/lsb-release_1.4.bb  |  2 +-
 .../packagegroup-core-base-utils.bb   |  4 +---
 .../packagegroup-core-full-cmdline.bb |  9 
 .../packagegroups/packagegroup-core-weston.bb |  2 +-
 .../packagegroups/packagegroup-core-x11.bb|  9 +---
 meta/recipes-graphics/wayland/weston-init.bb  |  6 ++---
 meta/recipes-graphics/wayland/weston_9.0.0.bb |  2 +-
 .../gstreamer/gstreamer1.0-omx_1.18.5.bb  |  3 +--
 34 files changed, 88 insertions(+), 96 deletions(-)

diff --git a/meta/classes/base.bbclass b/meta/classes/base.bbclass
index a65fcc6c1db..1395df4a02c 100644
--- a/meta/classes/base.bbclass
+++ b/meta/classes/base.bbclass
@@ -334,6 +334,12 @@ python base_eventhandler() {
 profprov = d.getVar("PREFERRED_PROVIDER_" + p)
 if profprov and pn != profprov:
 raise bb.parse.SkipRecipe("PREFERRED_PROVIDER_%s set 
to %s, not %s" % (p, profprov, pn))
+
+
+remaps = d.getVarFlags("PACKAGE_GLOBAL_RENAMES")
+for m in remaps:
+if m.startswith("virtual-"):
+d.setVar("RPROVIDES:" + remaps[m] + ":append", " " + m)
 }
 
 CONFIGURESTAMPFILE = "${WORKDIR}/configure.sstate"
diff --git a/meta/classes/image.bbclass b/meta/class

[OE-core] [PATCH RFC 0/2] Replace VIRTUAL-RUNTIME variables

2021-11-04 Thread Richard Purdie
The VIRTUAL-RUNTIME variables are a hack and not fit for purpose.
These patches replace it with something different. There are some
issues listed in the second patch which probably rule out the 
implmentation as is but I liked it enough to get it this far and
maybe some better solution can rise from the ideas here.

Richard Purdie (2):
  package: Introduce PACKAGE_GLOBAL_RENAMES
  conf/recipes: Replace VIRTUAL-RUNTIME with PACKAGE_GLOBAL_RENAMES

 meta/classes/base.bbclass |  6 +
 meta/classes/image.bbclass| 10 +
 meta/classes/multilib_global.bbclass  |  5 +
 meta/classes/package.bbclass  | 18 ++-
 meta/classes/packagegroup.bbclass |  4 ++--
 meta/classes/populate_sdk_base.bbclass|  9 
 meta/classes/update-alternatives.bbclass  |  5 +
 .../conf/distro/include/default-providers.inc | 13 +--
 .../include/init-manager-mdev-busybox.inc |  9 
 .../conf/distro/include/init-manager-none.inc |  7 +++---
 .../distro/include/init-manager-systemd.inc   |  9 
 .../distro/include/init-manager-sysvinit.inc  |  7 +++---
 meta/conf/layer.conf  |  2 +-
 meta/lib/oe/rootfs.py |  2 +-
 meta/recipes-core/busybox/busybox.inc |  4 ++--
 meta/recipes-core/busybox/busybox_1.34.1.bb   |  6 ++---
 .../images/core-image-minimal-initramfs.bb|  2 +-
 .../images/core-image-tiny-initramfs.bb   |  4 +---
 .../initrdscripts/initramfs-framework_1.0.bb  |  4 ++--
 .../initramfs-live-install-efi_1.0.bb |  4 ++--
 .../initramfs-live-install_1.0.bb |  4 ++--
 .../initramfs-module-install-efi_1.0.bb   |  4 ++--
 .../initramfs-module-install_1.0.bb   |  4 ++--
 .../packagegroups/packagegroup-base.bb|  9 +++-
 .../packagegroups/packagegroup-core-boot.bb   | 22 ---
 meta/recipes-devtools/dpkg/dpkg.inc   |  2 +-
 meta/recipes-devtools/opkg/opkg_0.4.5.bb  |  2 +-
 meta/recipes-extended/lsb/lsb-release_1.4.bb  |  2 +-
 .../packagegroup-core-base-utils.bb   |  4 +---
 .../packagegroup-core-full-cmdline.bb |  9 
 .../packagegroups/packagegroup-core-weston.bb |  2 +-
 .../packagegroups/packagegroup-core-x11.bb|  9 +---
 meta/recipes-graphics/wayland/weston-init.bb  |  6 ++---
 meta/recipes-graphics/wayland/weston_9.0.0.bb |  2 +-
 .../gstreamer/gstreamer1.0-omx_1.18.5.bb  |  3 +--
 35 files changed, 106 insertions(+), 108 deletions(-)

-- 
2.32.0


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



Re: [OE-core][dunfell 00/29] Pull request (cover letter only)

2021-11-03 Thread Richard Purdie
On Tue, 2021-11-02 at 14:11 -1000, Steve Sakoman wrote:
> The following changes since commit a7520c47573cd166d441e504737492b86f5aa42e:
> 
>   selftest/reproducible: adjust exclusion list for dunfell (2021-10-25 
> 13:28:19 -1000)
> 
> are available in the Git repository at:
> 
>   git://git.openembedded.org/openembedded-core-contrib stable/dunfell-next
>   
> http://cgit.openembedded.org/openembedded-core-contrib/log/?h=stable/dunfell-next
> 
> Alexander Kanavin (7):
>   linux-firmware: upgrade 20210511 -> 20210818
>   linux-firmware: upgrade 20210818 -> 20210919
>   wireless-regdb: upgrade 2021.04.21 -> 2021.07.14
>   wireless-regdb: upgrade 2021.07.14 -> 2021.08.28
>   ca-certificates: update 20210119 -> 20211016
>   tzdata: upgrade 2021a -> 2021d
>   tzdata: update 2021d -> 2021e
> 
> Daniel McGregor (1):
>   bitbake.conf: Add gpg-agent as a host tool
> 
> Jose Quaresma (1):
>   sstate: fix touching files inside pseudo
> 
> Minjae Kim (1):
>   vim: fix 2021-3796
> 
> Oleksandr Kravchuk (1):
>   mirrors.bbclass: remove dead infozip mirrors
> 
> Ranjitsinh Rathod (1):
>   curl: Whitelist CVE-2021-22897
> 
> Richard Purdie (5):
>   base: Clean up unneeded len() calls
>   base: Use repr() for printing exceptions
>   reproducible_build: Drop obsolete sstate workaround
>   patch: Use repr() with exceptions instead of str()

The above patch did have at least one fix and further discussion and proposed
patches so I'm not sure about that one. I didn't take it now as it at least
needs my followup fix too.

Cheers,

Richard


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



Re: [OE-core] [PATCH 33/33] perl: backport gdbm 1.2x compatibility fixes

2021-11-03 Thread Richard Purdie
On Tue, 2021-11-02 at 09:43 +0100, Alexander Kanavin wrote:
> Signed-off-by: Alexander Kanavin 
> ---
>  ...e5fdd87aa205011512cd1e6cc655bcf677fd.patch | 31 ++
>  ...2398e766500cb5d83c4d76b642fcf31d997a.patch | 40 +++
>  ...297a58b8f10ab885c19eec48ea076116cc1f.patch | 25 
>  meta/recipes-devtools/perl/perl_5.34.0.bb |  3 ++
>  4 files changed, 99 insertions(+)
>  create mode 100644 
> meta/recipes-devtools/perl/files/5bc1e5fdd87aa205011512cd1e6cc655bcf677fd.patch
>  create mode 100644 
> meta/recipes-devtools/perl/files/aacd2398e766500cb5d83c4d76b642fcf31d997a.patch
>  create mode 100644 
> meta/recipes-devtools/perl/files/ea57297a58b8f10ab885c19eec48ea076116cc1f.patch

I noticed we had a perl gdbm failure on both:
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/2782/steps/12/logs/stdio
and
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/2498

(as well as lttng-tools)

Is that related to this? The commit doesn't say why we need gdbm compatibility
fixes?

Cheers,

Richard


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



Re: [OE-core] [PATCHv4 3/4] apt: Do not install /var/log/apt

2021-11-02 Thread Richard Purdie
On Mon, 2021-11-01 at 01:03 +0100, Peter Kjellerstedt wrote:
> /var/log is normally a link to /var/volatile/log and /var/volatile is a
> tmpfs mount. So anything created in /var/log will not be available when
> the tmpfs is mounted.
> 
> Also some whitespace clean up.
> 
> Signed-off-by: Peter Kjellerstedt 
> ---
>  meta/recipes-devtools/apt/apt_2.2.4.bb | 30 ++
>  1 file changed, 16 insertions(+), 14 deletions(-)
> 
> diff --git a/meta/recipes-devtools/apt/apt_2.2.4.bb 
> b/meta/recipes-devtools/apt/apt_2.2.4.bb
> index 29fc49fb39..3d88371169 100644
> --- a/meta/recipes-devtools/apt/apt_2.2.4.bb
> +++ b/meta/recipes-devtools/apt/apt_2.2.4.bb
> @@ -51,9 +51,8 @@ EXTRA_OECMAKE:append = " -DCURRENT_VENDOR=debian 
> -DWITH_DOC=False \
>  -DWITH_TESTS=False \
>  "
>  
> -do_configure:prepend () {
> -echo "set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH )" >>  
> ${WORKDIR}/toolchain.cmake
> -
> +do_configure:prepend() {
> + echo "set( CMAKE_FIND_ROOT_PATH_MODE_INCLUDE BOTH )" >>  
> ${WORKDIR}/toolchain.cmake
>  }
>  
>  # Unfortunately apt hardcodes this all over the place
> @@ -61,7 +60,7 @@ FILES:${PN} += "${prefix}/lib/dpkg ${prefix}/lib/apt"
>  RDEPENDS:${PN} += "bash perl dpkg"
>  
>  customize_apt_conf_sample() {
> -cat > ${D}${sysconfdir}/apt/apt.conf.sample << EOF
> + cat > ${D}${sysconfdir}/apt/apt.conf.sample << EOF
>  Dir "${STAGING_DIR_NATIVE}/"
>  {
> State "var/lib/apt/"
> @@ -114,22 +113,25 @@ EOF
>  }
>  
>  do_install:append:class-native() {
> -customize_apt_conf_sample
> + customize_apt_conf_sample
>  }
>  
>  do_install:append:class-nativesdk() {
> -customize_apt_conf_sample
> + customize_apt_conf_sample
>  }
>  
> -
>  do_install:append:class-target() {
> -#Write the correct apt-architecture to apt.conf
> -APT_CONF=${D}/etc/apt/apt.conf
> -echo 'APT::Architecture "${DPKG_ARCH}";' > ${APT_CONF}
> + # Write the correct apt-architecture to apt.conf
> + APT_CONF=${D}${sysconfdir}/apt/apt.conf
> + echo 'APT::Architecture "${DPKG_ARCH}";' > ${APT_CONF}
>  }
>  
> -# Avoid non-reproducible -src package
> -do_install:append () {
> -sed -i -e "s,${B},,g" \
> -${B}/apt-pkg/tagfile-keys.cc
> +do_install:append() {
> + # Remove /var/log/apt. /var/log is normally a link to /var/volatile/log
> + # and /var/volatile is a tmpfs mount. So anything created in /var/log
> + # will not be available when the tmpfs is mounted.
> + rm -rf ${D}${localstatedir}/log
> +
> + # Avoid non-reproducible -src package
> + sed -i -e "s,${B},,g" ${B}/apt-pkg/tagfile-keys.cc
>  }

I didn't bisect it down but this looks likely to be from this change:

https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/2796/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/50/builds/4279/steps/11/logs/stdio

https://autobuilder.yoctoproject.org/typhoon/#/builders/76/builds/4260/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/115/builds/919/steps/12/logs/stdio
(and more)

Cheers,

Richard


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



Re: [OE-core] [RFC PATCH 11/14] populate_sdk_base/images: Drop use of 'meta' class and hence do_build dependencies

2021-11-02 Thread Richard Purdie
On Wed, 2021-10-27 at 10:43 +0800, ChenQi wrote:
> 
>  I like this change. However, it causes problem of 'rm_work'.
>  Now some native recipes don't get cleaned up with 'rm_work' enabled.
>  
>  e.g.
>  INHERIT += "rm_work"
>  bitbake core-image-minimal
>  A few native recipes don't get clean up such as alsa-lib-native, createrepo-
> c-native, dnf-native, etc.
>  
>  Do you have any idea how to fix it? Or should we accept the current
> situation?
>  

I think the issue is that populate_sdk is an odd task in that it doesn't run
before do_build (nor should it). rm_work will therefore not get triggered since
the class does:

addtask rm_work_all before do_build

What might work is something like:

do_populate_sdk[recrdeptask] = "do_rm_work"

but that may have some horrible side effects, I'm not sure.

Cheers,

Richard







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



Re: [OE-core] [PATCH] patch.bbclass: don't repr() the exception, use str()

2021-11-02 Thread Richard Purdie
On Tue, 2021-11-02 at 12:26 +, Ross Burton wrote:
> repr() results in formatting characters such as extra quotation marks
> which are pointless.
> 
> Signed-off-by: Ross Burton 
> ---
>  meta/classes/patch.bbclass | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/classes/patch.bbclass b/meta/classes/patch.bbclass
> index 8de7025491..079ee33e3c 100644
> --- a/meta/classes/patch.bbclass
> +++ b/meta/classes/patch.bbclass
> @@ -155,7 +155,7 @@ python patch_do_patch() {
>  resolver.Resolve()
>  except bb.BBHandledException as e:
>  bb.utils.remove(process_tmpdir, True)
> -bb.fatal("Applying patch '%s' on target directory '%s'\n%s" % 
> (parm['patchname'], patchdir, repr(e).replace("\\n", "\n")))
> +bb.fatal("Applying patch '%s' on target directory '%s'\n%s" % 
> (parm['patchname'], patchdir, str(e).replace("\\n", "\n")))
>  
>  bb.utils.remove(process_tmpdir, True)
>  del os.environ['TMPDIR']

Full circle:

http://git.yoctoproject.org/cgit.cgi/poky/commit/?id=ec6edfc27f2cfa990dd0f8b2bbc6f9472a50a839

:(

(the original issue being that str(e) on exceptions can hide a lot of useful
info)

Cheers,

Richard


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



[OE-core] [PATCH 3/3] recipes: Update github.com urls to use https

2021-11-02 Thread Richard Purdie
Github has announced there will be no more git:// fetching from their servers:

https://github.blog/2021-09-01-improving-git-protocol-security-github/#no-more-unauthenticated-git

and they're about to start having brownout periods to encourage people
to update. This runs the conversion script over OE-Core to update our
urls to use https instead of git.

Signed-off-by: Richard Purdie 
---
 meta/recipes-bsp/efivar/efivar_37.bb| 2 +-
 meta/recipes-bsp/opensbi/opensbi_0.9.bb | 2 +-
 meta/recipes-connectivity/connman/connman-gnome_0.7.bb  | 2 +-
 meta/recipes-connectivity/libnss-mdns/libnss-mdns_0.15.1.bb | 2 +-
 meta/recipes-connectivity/libuv/libuv_1.42.0.bb | 2 +-
 meta/recipes-core/fts/fts_1.2.7.bb  | 2 +-
 meta/recipes-core/glibc/cross-localedef-native_2.34.bb  | 2 +-
 meta/recipes-core/libxcrypt/libxcrypt.inc   | 2 +-
 meta/recipes-core/musl/libucontext_git.bb   | 2 +-
 meta/recipes-core/musl/musl-obstack.bb  | 2 +-
 meta/recipes-core/musl/musl-utils.bb| 2 +-
 meta/recipes-core/systemd/systemd.inc   | 2 +-
 meta/recipes-devtools/bootchart2/bootchart2_0.14.9.bb   | 2 +-
 meta/recipes-devtools/createrepo-c/createrepo-c_0.17.7.bb   | 2 +-
 meta/recipes-devtools/distcc/distcc_3.4.bb  | 2 +-
 meta/recipes-devtools/dnf/dnf_4.10.0.bb | 2 +-
 meta/recipes-devtools/file/file_5.41.bb | 2 +-
 meta/recipes-devtools/libcomps/libcomps_0.1.18.bb   | 2 +-
 meta/recipes-devtools/libdnf/libdnf_0.65.0.bb   | 2 +-
 meta/recipes-devtools/librepo/librepo_1.14.2.bb | 2 +-
 meta/recipes-devtools/llvm/llvm_git.bb  | 2 +-
 meta/recipes-devtools/ninja/ninja_1.10.2.bb | 2 +-
 meta/recipes-devtools/rpm/rpm_4.17.0.bb | 2 +-
 meta/recipes-extended/iputils/iputils_20210722.bb   | 2 +-
 meta/recipes-extended/libnsl/libnsl2_git.bb | 2 +-
 meta/recipes-extended/libnss-nis/libnss-nis.bb  | 2 +-
 meta/recipes-extended/libsolv/libsolv_0.7.20.bb | 2 +-
 meta/recipes-extended/lsof/lsof_4.94.0.bb   | 2 +-
 meta/recipes-extended/ltp/ltp_20210927.bb   | 2 +-
 meta/recipes-extended/rpcsvc-proto/rpcsvc-proto.bb  | 2 +-
 meta/recipes-extended/sysklogd/sysklogd_2.2.3.bb| 2 +-
 meta/recipes-extended/zstd/zstd_1.5.0.bb| 2 +-
 meta/recipes-graphics/libva/libva-utils_2.13.0.bb   | 2 +-
 meta/recipes-graphics/spir/spirv-tools_2021.3.bb| 2 +-
 meta/recipes-graphics/vulkan/vulkan-headers_1.2.191.0.bb| 2 +-
 meta/recipes-graphics/vulkan/vulkan-loader_1.2.191.0.bb | 2 +-
 meta/recipes-graphics/vulkan/vulkan-samples_git.bb  | 2 +-
 meta/recipes-graphics/vulkan/vulkan-tools_1.2.191.0.bb  | 2 +-
 .../recipes-graphics/xinput-calibrator/xinput-calibrator_git.bb | 2 +-
 meta/recipes-kernel/cryptodev/cryptodev.inc | 2 +-
 meta/recipes-multimedia/x264/x264_git.bb| 2 +-
 meta/recipes-sato/l3afpad/l3afpad_git.bb| 2 +-
 meta/recipes-support/bmap-tools/bmap-tools_3.6.bb   | 2 +-
 meta/recipes-support/libgit2/libgit2_1.3.0.bb   | 2 +-
 meta/recipes-support/libjitterentropy/libjitterentropy_3.3.0.bb | 2 +-
 meta/recipes-support/libseccomp/libseccomp_2.5.2.bb | 2 +-
 meta/recipes-support/lz4/lz4_1.9.3.bb   | 2 +-
 meta/recipes-support/numactl/numactl_git.bb | 2 +-
 meta/recipes-support/p11-kit/p11-kit_0.24.0.bb  | 2 +-
 meta/recipes-support/rng-tools/rng-tools_6.14.bb| 2 +-
 meta/recipes-support/vim/vim.inc| 2 +-
 meta/recipes-support/xxhash/xxhash_0.8.0.bb | 2 +-
 52 files changed, 52 insertions(+), 52 deletions(-)

diff --git a/meta/recipes-bsp/efivar/efivar_37.bb 
b/meta/recipes-bsp/efivar/efivar_37.bb
index 6340020cef0..fc36913f308 100644
--- a/meta/recipes-bsp/efivar/efivar_37.bb
+++ b/meta/recipes-bsp/efivar/efivar_37.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=6626bb1e20189cfa95f2c508ba286393"
 
 COMPATIBLE_HOST = "(i.86|x86_64|arm|aarch64).*-linux"
 
-SRC_URI = "git://github.com/rhinstaller/efivar.git;branch=master \
+SRC_URI = 
"git://github.com/rhinstaller/efivar.git;branch=master;protocol=https \
file://determinism.patch \
file://no-werror.patch"
 SRCREV = "c1d6b10e1ed4ba2be07f385eae5bceb694478a10"
diff --git a/meta/recipes-bsp/opensbi/opensbi_0.9.bb 
b/meta/recipes-bsp/opensbi/opensbi_0.9.bb
index cb9f346dc05..1956

[OE-core] [PATCH 2/3] scripts/convert-srcuri: Update SRC_URI conversion script to handle github url changes

2021-11-02 Thread Richard Purdie
Github are dropping support for git:// protocol fetching. Update the script
to learn about corner cases found in the previous conversion and
support remapping the github urls as needed too.

Signed-off-by: Richard Purdie 
---
 scripts/contrib/convert-srcuri.py | 16 +++-
 1 file changed, 15 insertions(+), 1 deletion(-)

diff --git a/scripts/contrib/convert-srcuri.py 
b/scripts/contrib/convert-srcuri.py
index 4bf9e3013d3..5b362ea2e84 100755
--- a/scripts/contrib/convert-srcuri.py
+++ b/scripts/contrib/convert-srcuri.py
@@ -19,19 +19,33 @@ if len(sys.argv) < 2:
 sys.exit(1)
 
 def processfile(fn):
+def matchline(line):
+if "MIRROR" in line or ".*" in line or "GNOME_GIT" in line:
+return False
+return True
 print("processing file '%s'" % fn)
 try:
+if "distro_alias.inc" in fn or "linux-yocto-custom.bb" in fn:
+return
 fh, abs_path = tempfile.mkstemp()
 modified = False
 with os.fdopen(fh, 'w') as new_file:
 with open(fn, "r") as old_file:
 for line in old_file:
-if ("git://" in line or "gitsm://" in line) and "branch=" 
not in line and "MIRROR" not in line and ".*" not in line:
+if ("git://" in line or "gitsm://" in line) and "branch=" 
not in line and matchline(line):
 if line.endswith('"\n'):
 line = line.replace('"\n', ';branch=master"\n')
 elif line.endswith(" \\\n"):
 line = line.replace(' \\\n', ';branch=master \\\n')
 modified = True
+if ("git://" in line or "gitsm://" in line) and 
"github.com" in line and "protocol=https" not in line and matchline(line):
+if "protocol=git" in line:
+line = line.replace('protocol=git', 
'protocol=https')
+elif line.endswith('"\n'):
+line = line.replace('"\n', ';protocol=https"\n')
+elif line.endswith(" \\\n"):
+line = line.replace(' \\\n', ';protocol=https 
\\\n')
+modified = True
 new_file.write(line)
 if modified:
 shutil.copymode(fn, abs_path)
-- 
2.32.0


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



[OE-core] [PATCH 1/3] bitbake.conf: Fix corruption of GNOME mirror url

2021-11-02 Thread Richard Purdie
The url changes from the script accidentally corrupted this mirror
url, fix it.

Signed-off-by: Richard Purdie 
---
 meta/conf/bitbake.conf | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
index d9c4b4e5ada..790f2f7a8c4 100644
--- a/meta/conf/bitbake.conf
+++ b/meta/conf/bitbake.conf
@@ -657,7 +657,7 @@ APACHE_MIRROR = "https://archive.apache.org/dist;
 CPAN_MIRROR = "https://search.cpan.org/CPAN;
 DEBIAN_MIRROR = "http://ftp.debian.org/debian/pool;
 GENTOO_MIRROR = "http://distfiles.gentoo.org/distfiles;
-GNOME_GIT = "git://gitlab.gnome.org/GNOME;branch=master"
+GNOME_GIT = "git://gitlab.gnome.org/GNOME"
 GNOME_MIRROR = "https://download.gnome.org/sources/;
 GNU_MIRROR = "https://ftp.gnu.org/gnu;
 GNUPG_MIRROR = "https://www.gnupg.org/ftp/gcrypt;
-- 
2.32.0


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



  1   2   3   4   5   6   7   8   9   10   >