[PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

For better or worse, more and more rust components are appearing that do
not include their dependencies in tarballs (or git trees), and rely on cargo
to fetch them. On the other hand, bitbake does not use cargo (and quite possible
won't ever be able to), and relies on having each item explicitly listed in SRC_URI
with a crate:// prefix. This however creates a problem of both making such lists in
the first place and updating them when a recipe is updated to a newer version.

So this class can be used to perform such updates by implementing a task that does it;
the next commit shows the outcome for python3-bcrypt (which has been tested to work
and produce a successful build).

Note: the python script relies on tomllib library, which appears in Python 3.11 and
does not exist in earlier versions - I've tested this by first updating python to 3.11-rc2
in oe-core.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../cargo-update-recipe-crates.bbclass        | 41 +++++++++++++++++++
 1 file changed, 41 insertions(+)
 create mode 100644 meta/classes-recipe/cargo-update-recipe-crates.bbclass

diff --git a/meta/classes-recipe/cargo-update-recipe-crates.bbclass b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
new file mode 100644
index 0000000000..f90938c734
--- /dev/null
+++ b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
@@ -0,0 +1,41 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: MIT
+#
+
+##
+## Purpose:
+## This class is used to update the list of crates in SRC_URI
+## by reading Cargo.lock in the source tree.
+##
+## See meta/recipes-devtools/python/python3-bcrypt_*.bb for an example
+##
+## To perform the update: bitbake -c update_crates recipe-name
+
+addtask do_update_crates after do_patch
+do_update_crates[depends] = "python3-native:do_populate_sysroot"
+
+do_update_crates() {
+    nativepython3 - <<EOF
+
+def get_crates(f):
+    import tomllib
+    c_list = 'SRC_URI += " \\ \n'
+    crates = tomllib.load(open(f, 'rb'))
+    for c in crates['package']:
+        if 'source' in c and 'crates.io' in c['source']:
+            c_list += "        crate://crates.io/{}/{} \\ \n".format(c['name'], c['version'])
+    c_list += '"\n'
+    return c_list
+
+import os
+crates = "# Autogenerated with 'bitbake -c update_crates ${PN}'\n\n"
+for root, dirs, files in os.walk('${S}'):
+    for file in files:
+        if file == 'Cargo.lock':
+            crates += get_crates(os.path.join(root, file))
+open(os.path.join('${THISDIR}', '${PN}'+"-crates.inc"), 'w').write(crates)
+
+EOF
+}
-- 
2.30.2

[PATCH 02/13] python3-bcrypt: convert to use cargo-update-recipe-crates class.

[Alexander Kanavin]

The component has been reimplemented in rust, and comes
with a large list of dependencies in Cargo.toml/Cargo.lock.

Rather than list them by hand, use a file generated with
cargo-update-recipe-crates class.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../python/python3-bcrypt-crates.inc          | 53 ++++++++++++++++++
 .../python/python3-bcrypt_4.0.0.bb            | 55 ++-----------------
 2 files changed, 57 insertions(+), 51 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python3-bcrypt-crates.inc

diff --git a/meta/recipes-devtools/python/python3-bcrypt-crates.inc b/meta/recipes-devtools/python/python3-bcrypt-crates.inc
new file mode 100644
index 0000000000..78c5d5aa22
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-bcrypt-crates.inc
@@ -0,0 +1,53 @@
+# Autogenerated with 'bitbake -c update_crates python3-bcrypt'
+
+SRC_URI += " \ 
+        crate://crates.io/autocfg/1.1.0 \ 
+        crate://crates.io/base64/0.13.0 \ 
+        crate://crates.io/bcrypt/0.13.0 \ 
+        crate://crates.io/bcrypt-pbkdf/0.8.1 \ 
+        crate://crates.io/bitflags/1.3.2 \ 
+        crate://crates.io/block-buffer/0.10.2 \ 
+        crate://crates.io/blowfish/0.9.1 \ 
+        crate://crates.io/byteorder/1.4.3 \ 
+        crate://crates.io/cfg-if/1.0.0 \ 
+        crate://crates.io/cipher/0.4.3 \ 
+        crate://crates.io/cpufeatures/0.2.4 \ 
+        crate://crates.io/crypto-common/0.1.6 \ 
+        crate://crates.io/digest/0.10.3 \ 
+        crate://crates.io/generic-array/0.14.6 \ 
+        crate://crates.io/getrandom/0.2.7 \ 
+        crate://crates.io/indoc/0.3.6 \ 
+        crate://crates.io/indoc-impl/0.3.6 \ 
+        crate://crates.io/inout/0.1.3 \ 
+        crate://crates.io/instant/0.1.12 \ 
+        crate://crates.io/libc/0.2.132 \ 
+        crate://crates.io/lock_api/0.4.7 \ 
+        crate://crates.io/once_cell/1.13.1 \ 
+        crate://crates.io/parking_lot/0.11.2 \ 
+        crate://crates.io/parking_lot_core/0.8.5 \ 
+        crate://crates.io/paste/0.1.18 \ 
+        crate://crates.io/paste-impl/0.1.18 \ 
+        crate://crates.io/pbkdf2/0.10.1 \ 
+        crate://crates.io/proc-macro-hack/0.5.19 \ 
+        crate://crates.io/proc-macro2/1.0.43 \ 
+        crate://crates.io/pyo3/0.15.2 \ 
+        crate://crates.io/pyo3-build-config/0.15.2 \ 
+        crate://crates.io/pyo3-macros/0.15.2 \ 
+        crate://crates.io/pyo3-macros-backend/0.15.2 \ 
+        crate://crates.io/quote/1.0.21 \ 
+        crate://crates.io/redox_syscall/0.2.16 \ 
+        crate://crates.io/scopeguard/1.1.0 \ 
+        crate://crates.io/sha2/0.10.2 \ 
+        crate://crates.io/smallvec/1.9.0 \ 
+        crate://crates.io/subtle/2.4.1 \ 
+        crate://crates.io/syn/1.0.99 \ 
+        crate://crates.io/typenum/1.15.0 \ 
+        crate://crates.io/unicode-ident/1.0.3 \ 
+        crate://crates.io/unindent/0.1.10 \ 
+        crate://crates.io/version_check/0.9.4 \ 
+        crate://crates.io/wasi/0.11.0+wasi-snapshot-preview1 \ 
+        crate://crates.io/winapi/0.3.9 \ 
+        crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \ 
+        crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \ 
+        crate://crates.io/zeroize/1.5.7 \ 
+"
diff --git a/meta/recipes-devtools/python/python3-bcrypt_4.0.0.bb b/meta/recipes-devtools/python/python3-bcrypt_4.0.0.bb
index ac795ca8ab..857b38df2c 100644
--- a/meta/recipes-devtools/python/python3-bcrypt_4.0.0.bb
+++ b/meta/recipes-devtools/python/python3-bcrypt_4.0.0.bb
@@ -7,61 +7,14 @@ DEPENDS += "${PYTHON_PN}-cffi-native"
 
 SRC_URI[sha256sum] = "c59c170fc9225faad04dde1ba61d85b413946e8ce2e5f5f5ff30dfd67283f319"
 
-inherit pypi python_setuptools3_rust ptest
+inherit pypi python_setuptools3_rust ptest cargo-update-recipe-crates
 
 SRC_URI += " \
-    crate://crates.io/autocfg/1.1.0 \
-    crate://crates.io/base64/0.13.0 \
-    crate://crates.io/bcrypt-pbkdf/0.8.1 \
-    crate://crates.io/bcrypt/0.13.0 \
-    crate://crates.io/bitflags/1.3.2 \
-    crate://crates.io/block-buffer/0.10.2 \
-    crate://crates.io/blowfish/0.9.1 \
-    crate://crates.io/byteorder/1.4.3 \
-    crate://crates.io/cfg-if/1.0.0 \
-    crate://crates.io/cipher/0.4.3 \
-    crate://crates.io/cpufeatures/0.2.4 \
-    crate://crates.io/crypto-common/0.1.6 \
-    crate://crates.io/digest/0.10.3 \
-    crate://crates.io/generic-array/0.14.6 \
-    crate://crates.io/getrandom/0.2.7 \
-    crate://crates.io/indoc-impl/0.3.6 \
-    crate://crates.io/indoc/0.3.6 \
-    crate://crates.io/inout/0.1.3 \
-    crate://crates.io/instant/0.1.12 \
-    crate://crates.io/libc/0.2.132 \
-    crate://crates.io/lock_api/0.4.7 \
-    crate://crates.io/once_cell/1.13.1 \
-    crate://crates.io/parking_lot/0.11.2 \
-    crate://crates.io/parking_lot_core/0.8.5 \
-    crate://crates.io/paste-impl/0.1.18 \
-    crate://crates.io/paste/0.1.18 \
-    crate://crates.io/pbkdf2/0.10.1 \
-    crate://crates.io/proc-macro-hack/0.5.19 \
-    crate://crates.io/proc-macro2/1.0.43 \
-    crate://crates.io/pyo3-build-config/0.15.2 \
-    crate://crates.io/pyo3-macros-backend/0.15.2 \
-    crate://crates.io/pyo3-macros/0.15.2 \
-    crate://crates.io/pyo3/0.15.2 \
-    crate://crates.io/quote/1.0.21 \
-    crate://crates.io/redox_syscall/0.2.16 \
-    crate://crates.io/scopeguard/1.1.0 \
-    crate://crates.io/sha2/0.10.2 \
-    crate://crates.io/smallvec/1.9.0 \
-    crate://crates.io/subtle/2.4.1 \
-    crate://crates.io/syn/1.0.99 \
-    crate://crates.io/typenum/1.15.0 \
-    crate://crates.io/unicode-ident/1.0.3 \
-    crate://crates.io/unindent/0.1.10 \
-    crate://crates.io/version_check/0.9.4 \
-    crate://crates.io/wasi/0.11.0+wasi-snapshot-preview1 \
-    crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
-    crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
-    crate://crates.io/winapi/0.3.9 \
-    crate://crates.io/zeroize/1.5.7 \
-    file://run-ptest \
+	file://run-ptest \
 "
 
+require ${BPN}-crates.inc
+
 RDEPENDS:${PN}-ptest += " \
 	${PYTHON_PN}-pytest \
 "
-- 
2.30.2

[PATCH 03/13] python3-cryptography: convert to cargo-update-recipe-crates class

[Alexander Kanavin]

This allows semi-automated updates to the list of crates, which
is far too awkward to maintain by hand, particularly on version updates.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../python/python3-cryptography-crates.inc    | 58 +++++++++++++++++++
 .../python/python3-cryptography_38.0.1.bb     | 58 +------------------
 2 files changed, 61 insertions(+), 55 deletions(-)
 create mode 100644 meta/recipes-devtools/python/python3-cryptography-crates.inc

diff --git a/meta/recipes-devtools/python/python3-cryptography-crates.inc b/meta/recipes-devtools/python/python3-cryptography-crates.inc
new file mode 100644
index 0000000000..9339a15091
--- /dev/null
+++ b/meta/recipes-devtools/python/python3-cryptography-crates.inc
@@ -0,0 +1,58 @@
+# Autogenerated with 'bitbake -c update_crates python3-cryptography'
+
+SRC_URI += " \ 
+        crate://crates.io/Inflector/0.11.4 \ 
+        crate://crates.io/aliasable/0.1.3 \ 
+        crate://crates.io/android_system_properties/0.1.5 \ 
+        crate://crates.io/asn1/0.12.2 \ 
+        crate://crates.io/asn1_derive/0.12.2 \ 
+        crate://crates.io/autocfg/1.1.0 \ 
+        crate://crates.io/base64/0.13.0 \ 
+        crate://crates.io/bitflags/1.3.2 \ 
+        crate://crates.io/bumpalo/3.10.0 \ 
+        crate://crates.io/cfg-if/1.0.0 \ 
+        crate://crates.io/chrono/0.4.22 \ 
+        crate://crates.io/core-foundation-sys/0.8.3 \ 
+        crate://crates.io/iana-time-zone/0.1.47 \ 
+        crate://crates.io/indoc/0.3.6 \ 
+        crate://crates.io/indoc-impl/0.3.6 \ 
+        crate://crates.io/instant/0.1.12 \ 
+        crate://crates.io/js-sys/0.3.59 \ 
+        crate://crates.io/libc/0.2.132 \ 
+        crate://crates.io/lock_api/0.4.8 \ 
+        crate://crates.io/log/0.4.17 \ 
+        crate://crates.io/num-integer/0.1.45 \ 
+        crate://crates.io/num-traits/0.2.15 \ 
+        crate://crates.io/once_cell/1.14.0 \ 
+        crate://crates.io/ouroboros/0.15.4 \ 
+        crate://crates.io/ouroboros_macro/0.15.4 \ 
+        crate://crates.io/parking_lot/0.11.2 \ 
+        crate://crates.io/parking_lot_core/0.8.5 \ 
+        crate://crates.io/paste/0.1.18 \ 
+        crate://crates.io/paste-impl/0.1.18 \ 
+        crate://crates.io/pem/1.1.0 \ 
+        crate://crates.io/proc-macro-error/1.0.4 \ 
+        crate://crates.io/proc-macro-error-attr/1.0.4 \ 
+        crate://crates.io/proc-macro-hack/0.5.19 \ 
+        crate://crates.io/proc-macro2/1.0.43 \ 
+        crate://crates.io/pyo3/0.15.2 \ 
+        crate://crates.io/pyo3-build-config/0.15.2 \ 
+        crate://crates.io/pyo3-macros/0.15.2 \ 
+        crate://crates.io/pyo3-macros-backend/0.15.2 \ 
+        crate://crates.io/quote/1.0.21 \ 
+        crate://crates.io/redox_syscall/0.2.16 \ 
+        crate://crates.io/scopeguard/1.1.0 \ 
+        crate://crates.io/smallvec/1.9.0 \ 
+        crate://crates.io/syn/1.0.99 \ 
+        crate://crates.io/unicode-ident/1.0.3 \ 
+        crate://crates.io/unindent/0.1.10 \ 
+        crate://crates.io/version_check/0.9.4 \ 
+        crate://crates.io/wasm-bindgen/0.2.82 \ 
+        crate://crates.io/wasm-bindgen-backend/0.2.82 \ 
+        crate://crates.io/wasm-bindgen-macro/0.2.82 \ 
+        crate://crates.io/wasm-bindgen-macro-support/0.2.82 \ 
+        crate://crates.io/wasm-bindgen-shared/0.2.82 \ 
+        crate://crates.io/winapi/0.3.9 \ 
+        crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \ 
+        crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \ 
+"
diff --git a/meta/recipes-devtools/python/python3-cryptography_38.0.1.bb b/meta/recipes-devtools/python/python3-cryptography_38.0.1.bb
index 905293a43e..68679b745a 100644
--- a/meta/recipes-devtools/python/python3-cryptography_38.0.1.bb
+++ b/meta/recipes-devtools/python/python3-cryptography_38.0.1.bb
@@ -16,63 +16,11 @@ SRC_URI += "\
     file://0001-pyproject.toml-remove-benchmark-disable-option.patch \
     file://check-memfree.py \
     file://run-ptest \
-    crate://crates.io/Inflector/0.11.4 \
-    crate://crates.io/aliasable/0.1.3 \
-    crate://crates.io/android_system_properties/0.1.5 \
-    crate://crates.io/asn1/0.12.2 \
-    crate://crates.io/asn1_derive/0.12.2 \
-    crate://crates.io/autocfg/1.1.0 \
-    crate://crates.io/base64/0.13.0 \
-    crate://crates.io/bitflags/1.3.2 \
-    crate://crates.io/bumpalo/3.10.0 \
-    crate://crates.io/cfg-if/1.0.0 \
-    crate://crates.io/chrono/0.4.22 \
-    crate://crates.io/core-foundation-sys/0.8.3 \
-    crate://crates.io/iana-time-zone/0.1.47 \
-    crate://crates.io/indoc-impl/0.3.6 \
-    crate://crates.io/indoc/0.3.6 \
-    crate://crates.io/instant/0.1.12 \
-    crate://crates.io/js-sys/0.3.59 \
-    crate://crates.io/libc/0.2.132 \
-    crate://crates.io/lock_api/0.4.8 \
-    crate://crates.io/log/0.4.17 \
-    crate://crates.io/num-integer/0.1.45 \
-    crate://crates.io/num-traits/0.2.15 \
-    crate://crates.io/once_cell/1.14.0 \
-    crate://crates.io/ouroboros/0.15.4 \
-    crate://crates.io/ouroboros_macro/0.15.4 \
-    crate://crates.io/parking_lot/0.11.2 \
-    crate://crates.io/parking_lot_core/0.8.5 \
-    crate://crates.io/paste-impl/0.1.18 \
-    crate://crates.io/paste/0.1.18 \
-    crate://crates.io/pem/1.1.0 \
-    crate://crates.io/proc-macro-error-attr/1.0.4 \
-    crate://crates.io/proc-macro-error/1.0.4 \
-    crate://crates.io/proc-macro-hack/0.5.19 \
-    crate://crates.io/proc-macro2/1.0.43 \
-    crate://crates.io/pyo3-build-config/0.15.2 \
-    crate://crates.io/pyo3-macros-backend/0.15.2 \
-    crate://crates.io/pyo3-macros/0.15.2 \
-    crate://crates.io/pyo3/0.15.2 \
-    crate://crates.io/quote/1.0.21 \
-    crate://crates.io/redox_syscall/0.2.16 \
-    crate://crates.io/scopeguard/1.1.0 \
-    crate://crates.io/smallvec/1.9.0 \
-    crate://crates.io/syn/1.0.99 \
-    crate://crates.io/unicode-ident/1.0.3 \
-    crate://crates.io/unindent/0.1.10 \
-    crate://crates.io/version_check/0.9.4 \
-    crate://crates.io/wasm-bindgen/0.2.82 \
-    crate://crates.io/wasm-bindgen-backend/0.2.82 \
-    crate://crates.io/wasm-bindgen-macro-support/0.2.82 \
-    crate://crates.io/wasm-bindgen-macro/0.2.82 \
-    crate://crates.io/wasm-bindgen-shared/0.2.82 \
-    crate://crates.io/winapi/0.3.9 \
-    crate://crates.io/winapi-i686-pc-windows-gnu/0.4.0 \
-    crate://crates.io/winapi-x86_64-pc-windows-gnu/0.4.0 \
 "
 
-inherit pypi python_setuptools3_rust
+require ${BPN}-crates.inc
+
+inherit pypi python_setuptools3_rust cargo-update-recipe-crates
 
 DEPENDS += " \
     ${PYTHON_PN}-cffi-native \
-- 
2.30.2

[PATCH 04/13] groff: submit patches upstream

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../groff/files/0001-Make-manpages-mulitlib-identical.patch     | 2 +-
 .../groff/files/0001-replace-perl-w-with-use-warnings.patch     | 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch
index 9105da6457..c3cfc7cea8 100644
--- a/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch
+++ b/meta/recipes-extended/groff/files/0001-Make-manpages-mulitlib-identical.patch
@@ -3,7 +3,7 @@ From: Jeremy Puhlman <jpuhlman@mvista.com>
 Date: Sat, 7 Mar 2020 00:59:13 +0000
 Subject: [PATCH] Make manpages mulitlib identical
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [by email to g.branden.robinson@gmail.com]
 Signed-off-by: Jeremy Puhlman <jpuhlman@mvista.com>
 ---
  Makefile.am | 2 +-
diff --git a/meta/recipes-extended/groff/files/0001-replace-perl-w-with-use-warnings.patch b/meta/recipes-extended/groff/files/0001-replace-perl-w-with-use-warnings.patch
index eda6a40f51..b028fa20aa 100644
--- a/meta/recipes-extended/groff/files/0001-replace-perl-w-with-use-warnings.patch
+++ b/meta/recipes-extended/groff/files/0001-replace-perl-w-with-use-warnings.patch
@@ -15,7 +15,7 @@ doesn't work:
 
 So replace "perl -w" with "use warnings" to make it work.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [by email to g.branden.robinson@gmail.com]
 
 Signed-off-by: Robert Yang <liezhi.yang@windriver.com>
 
-- 
2.30.2

[PATCH 05/13] tcl: correct patch status

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
index 44b2ce0a30..5a10c93a31 100644
--- a/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
+++ b/meta/recipes-devtools/tcltk/tcl/fix_non_native_build_issue.patch
@@ -1,4 +1,4 @@
-Upstream-Status: Pending
+Upstream-Status: Inappropriate [upstream does not support installed tests]
 
 Index: unix/Makefile.in
 ===================================================================
-- 
2.30.2

[PATCH 06/13] tcl: correct upstream version check

[Alexander Kanavin]

Sourceforge does not report the latest version reliably.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-devtools/tcltk/tcl_8.6.11.bb | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/recipes-devtools/tcltk/tcl_8.6.11.bb b/meta/recipes-devtools/tcltk/tcl_8.6.11.bb
index 9f6b003ffb..f8b2a69b9f 100644
--- a/meta/recipes-devtools/tcltk/tcl_8.6.11.bb
+++ b/meta/recipes-devtools/tcltk/tcl_8.6.11.bb
@@ -33,6 +33,7 @@ SRC_URI:class-native = "${BASE_SRC_URI}"
 # https://core.tcl-lang.org/tcl/info/7079e4f91601e9c7
 CVE_CHECK_IGNORE += "CVE-2021-35331"
 
+UPSTREAM_CHECK_URI = "https://www.tcl.tk/software/tcltk/download.html"
 UPSTREAM_CHECK_REGEX = "tcl(?P<pver>\d+(\.\d+)+)-src"
 
 S = "${WORKDIR}/${BPN}${PV}"
-- 
2.30.2

[PATCH 07/13] lttng-tools: submit determinism.patch upstream

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-kernel/lttng/lttng-tools/determinism.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/lttng/lttng-tools/determinism.patch b/meta/recipes-kernel/lttng/lttng-tools/determinism.patch
index b2ab880bd6..0a897a8e13 100644
--- a/meta/recipes-kernel/lttng/lttng-tools/determinism.patch
+++ b/meta/recipes-kernel/lttng/lttng-tools/determinism.patch
@@ -13,7 +13,7 @@ to me whether the tests need that or not.
 
 Fixes reproducibility issues for lttng-tools.
 
-Upstream-Status: Pending [needs discussion with upstream about the correct solution]
+Upstream-Status: Submitted [https://bugs.lttng.org/issues/1361 - needs discussion with upstream about the correct solution]
 RP 2021/3/1
 
 Index: lttng-tools-2.12.2/tests/regression/ust/ust-dl/Makefile.am
-- 
2.30.2

[PATCH 08/13] cmake: drop qt4 patches

[Alexander Kanavin]

Qt4 has been dead for a very long time now.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-devtools/cmake/cmake.inc         |  2 -
 ...t-OpenEmbedded-Qt4-tool-binary-names.patch | 56 -------------
 ...-if-system-Qt-installation-is-broken.patch | 79 -------------------
 3 files changed, 137 deletions(-)
 delete mode 100644 meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
 delete mode 100644 meta/recipes-devtools/cmake/cmake/0004-Fail-silently-if-system-Qt-installation-is-broken.patch

diff --git a/meta/recipes-devtools/cmake/cmake.inc b/meta/recipes-devtools/cmake/cmake.inc
index 1ede8eee61..7561e851c6 100644
--- a/meta/recipes-devtools/cmake/cmake.inc
+++ b/meta/recipes-devtools/cmake/cmake.inc
@@ -17,8 +17,6 @@ LIC_FILES_CHKSUM = "file://Copyright.txt;md5=45025187a129339459b6f1a24f7fac6e \
 CMAKE_MAJOR_VERSION = "${@'.'.join(d.getVar('PV').split('.')[0:2])}"
 
 SRC_URI = "https://cmake.org/files/v${CMAKE_MAJOR_VERSION}/cmake-${PV}.tar.gz \
-           file://0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch \
-           file://0004-Fail-silently-if-system-Qt-installation-is-broken.patch \
 "
 
 SRC_URI[sha256sum] = "0d9020f06f3ddf17fb537dc228e1a56c927ee506b486f55fe2dc19f69bf0c8db"
diff --git a/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch b/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
deleted file mode 100644
index 575a5cb7fb..0000000000
--- a/meta/recipes-devtools/cmake/cmake/0003-cmake-support-OpenEmbedded-Qt4-tool-binary-names.patch
+++ /dev/null
@@ -1,56 +0,0 @@
-From 2d02ac91d5a5d72eaddba4894eaa6db3ed8fee62 Mon Sep 17 00:00:00 2001
-From: Otavio Salvador <otavio@ossystems.com.br>
-Date: Thu, 12 May 2011 15:36:03 +0000
-Subject: [PATCH] cmake: support OpenEmbedded Qt4 tool binary names
-
-The FindQt4 module looks for Qt4 binaries to be able to gather the
-paths used for compilation and also to be using during other processes
-(translation update, translation binary generating and like) however
-OpenEmbedded has renamed those to allow old QMake to be used in
-parallel with the current one. This patch adds support for the
-OpenEmbedded specific binary names.
-
-Upstream-Status: Inappropriate [embedded specific]
-
-Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
-
-The patch was slightly adapted in order to match cmake 3.2.2:
-Instead of find_program, _find_qt4_program is now used.
-
-Signed-off-by: Moritz Blume <moritz.blume@bmw-carit.de>
-Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
-
----
- Modules/FindQt4.cmake | 10 +++++-----
- 1 file changed, 5 insertions(+), 5 deletions(-)
-
-diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
-index 3993968..b2a8585 100644
---- a/Modules/FindQt4.cmake
-+++ b/Modules/FindQt4.cmake
-@@ -518,7 +518,7 @@ endfunction()
- 
- set(QT4_INSTALLED_VERSION_TOO_OLD FALSE)
- 
--set(_QT4_QMAKE_NAMES qmake qmake4 qmake-qt4 qmake-mac)
-+set(_QT4_QMAKE_NAMES qmake qmake2 qmake4 qmake-qt4 qmake-mac)
- _qt4_find_qmake("${_QT4_QMAKE_NAMES}" QT_QMAKE_EXECUTABLE QTVERSION)
- 
- if (QT_QMAKE_EXECUTABLE AND
-@@ -1136,12 +1136,12 @@ if (QT_QMAKE_EXECUTABLE AND
-   _find_qt4_program(QT_MOC_EXECUTABLE Qt4::moc moc-qt4 moc4 moc)
-   _find_qt4_program(QT_UIC_EXECUTABLE Qt4::uic uic-qt4 uic4 uic)
-   _find_qt4_program(QT_UIC3_EXECUTABLE Qt4::uic3 uic3)
--  _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc)
--  _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml)
--  _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp)
-+  _find_qt4_program(QT_RCC_EXECUTABLE Qt4::rcc rcc4 rcc)
-+  _find_qt4_program(QT_DBUSCPP2XML_EXECUTABLE Qt4::qdbuscpp2xml qdbuscpp2xml4 qdbuscpp2xml)
-+  _find_qt4_program(QT_DBUSXML2CPP_EXECUTABLE Qt4::qdbusxml2cpp qdbusxml2cpp4 qdbusxml2cpp)
-   _find_qt4_program(QT_LUPDATE_EXECUTABLE Qt4::lupdate lupdate-qt4 lupdate4 lupdate)
-   _find_qt4_program(QT_LRELEASE_EXECUTABLE Qt4::lrelease lrelease-qt4 lrelease4 lrelease)
--  _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator)
-+  _find_qt4_program(QT_QCOLLECTIONGENERATOR_EXECUTABLE Qt4::qcollectiongenerator qcollectiongenerator-qt4 qcollectiongenerator qcollectiongenerator4)
-   _find_qt4_program(QT_DESIGNER_EXECUTABLE Qt4::designer designer-qt4 designer4 designer)
-   _find_qt4_program(QT_LINGUIST_EXECUTABLE Qt4::linguist linguist-qt4 linguist4 linguist)
- 
diff --git a/meta/recipes-devtools/cmake/cmake/0004-Fail-silently-if-system-Qt-installation-is-broken.patch b/meta/recipes-devtools/cmake/cmake/0004-Fail-silently-if-system-Qt-installation-is-broken.patch
deleted file mode 100644
index 1b196db81a..0000000000
--- a/meta/recipes-devtools/cmake/cmake/0004-Fail-silently-if-system-Qt-installation-is-broken.patch
+++ /dev/null
@@ -1,79 +0,0 @@
-From 60864efbe52cc12018efaafbc4e4c3c8b4af2b65 Mon Sep 17 00:00:00 2001
-From: Otavio Salvador <otavio@ossystems.com.br>
-Date: Thu, 5 Jul 2018 10:26:48 -0300
-Subject: [PATCH] Fail silently if system Qt installation is broken
-
-Fixes a regression in behaviour from 2.8.10 to 2.8.11 resulting in the
-following error if the system Qt installation is broken:
-
-CMake Error at Modules/FindQt4.cmake:1028 (set_property):
-  set_property could not find TARGET Qt4::QtCore.  Perhaps it has not yet
-  been created.
-Call Stack (most recent call first):
-  Tests/RunCMake/CMakeLists.txt:79 (find_package)
-
-Upstream-Status: Pending
-
-Signed-off-by: Paul Eggleton <paul.eggleton@linux.intel.com>
-
-The patch was slightly adapted in order to match cmake 3.2.2:
-Another set_property was introduced which had to be included
-within the if(QT_QTCORE_FOUND) statement.
-
-Signed-off-by: Moritz Blume <moritz.blume@bmw-carit.de>
-Signed-off-by: Otavio Salvador <otavio@ossystems.com.br>
-
----
- Modules/FindQt4.cmake | 39 ++++++++++++++++++++-------------------
- 1 file changed, 20 insertions(+), 19 deletions(-)
-
-diff --git a/Modules/FindQt4.cmake b/Modules/FindQt4.cmake
-index b2a8585..77c89aa 100644
---- a/Modules/FindQt4.cmake
-+++ b/Modules/FindQt4.cmake
-@@ -988,25 +988,26 @@ if (QT_QMAKE_EXECUTABLE AND
-     endif()
-   endmacro()
- 
--
--  # Set QT_xyz_LIBRARY variable and add
--  # library include path to QT_INCLUDES
--  _QT4_ADJUST_LIB_VARS(QtCore)
--  set_property(TARGET Qt4::QtCore APPEND PROPERTY
--    INTERFACE_INCLUDE_DIRECTORIES
--      "${QT_MKSPECS_DIR}/default"
--      ${QT_INCLUDE_DIR}
--  )
--  set_property(TARGET Qt4::QtCore APPEND PROPERTY
--    INTERFACE_COMPILE_DEFINITIONS
--      $<$<NOT:$<CONFIG:Debug>>:QT_NO_DEBUG>
--  )
--  set_property(TARGET Qt4::QtCore PROPERTY
--    INTERFACE_QT_MAJOR_VERSION 4
--  )
--  set_property(TARGET Qt4::QtCore APPEND PROPERTY
--    COMPATIBLE_INTERFACE_STRING QT_MAJOR_VERSION
--  )
-+  if(QT_QTCORE_FOUND)
-+    # Set QT_xyz_LIBRARY variable and add
-+    # library include path to QT_INCLUDES
-+    _QT4_ADJUST_LIB_VARS(QtCore)
-+    set_property(TARGET Qt4::QtCore APPEND PROPERTY
-+      INTERFACE_INCLUDE_DIRECTORIES
-+        "${QT_MKSPECS_DIR}/default"
-+        ${QT_INCLUDE_DIR}
-+    )
-+    set_property(TARGET Qt4::QtCore APPEND PROPERTY
-+      INTERFACE_COMPILE_DEFINITIONS
-+        $<$<NOT:$<CONFIG:Debug>>:QT_NO_DEBUG>
-+    )
-+    set_property(TARGET Qt4::QtCore PROPERTY
-+      INTERFACE_QT_MAJOR_VERSION 4
-+    )
-+    set_property(TARGET Qt4::QtCore APPEND PROPERTY
-+      COMPATIBLE_INTERFACE_STRING QT_MAJOR_VERSION
-+    )
-+  endif()
- 
-   foreach(QT_MODULE ${QT_MODULES})
-     _QT4_ADJUST_LIB_VARS(${QT_MODULE})
-- 
2.30.2

[PATCH 09/13] kea: submit patch upstream

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch b/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
index 78f475a495..451b409c88 100644
--- a/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
+++ b/meta/recipes-connectivity/kea/files/fix-multilib-conflict.patch
@@ -12,7 +12,7 @@ Subject: [PATCH] There are conflict of config files between kea and lib32-kea:
 Because they are all commented out, replace the expanded libdir path with
 '$libdir' in the config files to avoid conflict.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://gitlab.isc.org/isc-projects/kea/-/issues/2602]
 Signed-off-by: Kai Kang <kai.kang@windriver.com>
 
 ---
-- 
2.30.2

[PATCH 10/13] argp-standalone: replace with a maintained fork

[Alexander Kanavin]

Remove two patches as issues fixed upstream,
submit the third one.

License-Update: argp.h is an import from glibc and
has been refreshed to the latest version. It's still
lgpl 2.1.

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 ...dalone_1.3.bb => argp-standalone_1.4.1.bb} | 12 ++-
 .../files/0001-throw-in-funcdef.patch         | 84 -------------------
 .../argp-standalone/files/0002-isprint.patch  | 51 -----------
 .../files/out_of_tree_build.patch             |  2 +-
 4 files changed, 6 insertions(+), 143 deletions(-)
 rename meta/recipes-support/argp-standalone/{argp-standalone_1.3.bb => argp-standalone_1.4.1.bb} (59%)
 delete mode 100644 meta/recipes-support/argp-standalone/files/0001-throw-in-funcdef.patch
 delete mode 100644 meta/recipes-support/argp-standalone/files/0002-isprint.patch

diff --git a/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb b/meta/recipes-support/argp-standalone/argp-standalone_1.4.1.bb
similarity index 59%
rename from meta/recipes-support/argp-standalone/argp-standalone_1.3.bb
rename to meta/recipes-support/argp-standalone/argp-standalone_1.4.1.bb
index 8d8122612a..00b6036502 100644
--- a/meta/recipes-support/argp-standalone/argp-standalone_1.3.bb
+++ b/meta/recipes-support/argp-standalone/argp-standalone_1.4.1.bb
@@ -3,18 +3,16 @@
 
 SUMMARY = "Glibc hierarchical argument parsing standalone library"
 DESCRIPTION = "Standalone version of arguments parsing functions from GLIBC"
-HOMEPAGE = "http://www.lysator.liu.se/~nisse/misc/"
+HOMEPAGE = "https://github.com/ericonr/argp-standalone"
 LICENSE = "LGPL-2.1-only"
-LIC_FILES_CHKSUM = "file://argp.h;beginline=1;endline=20;md5=008b7e53dea6f9e1d9fdef0d9cf3184a"
+LIC_FILES_CHKSUM = "file://argp.h;beginline=1;endline=20;md5=464f2cfb1c35a5123f9e309d7afd79f8"
 SECTION = "libs"
 
-SRC_URI = "http://www.lysator.liu.se/~nisse/misc/argp-standalone-${PV}.tar.gz \
-           file://0001-throw-in-funcdef.patch \
-           file://0002-isprint.patch \
+SRC_URI = "git://github.com/ericonr/argp-standalone;branch=master;protocol=https \
            file://out_of_tree_build.patch \
           "
-SRC_URI[md5sum] = "720704bac078d067111b32444e24ba69"
-SRC_URI[sha256sum] = "dec79694da1319acd2238ce95df57f3680fea2482096e483323fddf3d818d8be"
+SRCREV = "e5fe9ad9e83e6765cf8fa787f903d4c6792338b5"
+S = "${WORKDIR}/git"
 
 inherit autotools
 
diff --git a/meta/recipes-support/argp-standalone/files/0001-throw-in-funcdef.patch b/meta/recipes-support/argp-standalone/files/0001-throw-in-funcdef.patch
deleted file mode 100644
index a6e2759c5d..0000000000
--- a/meta/recipes-support/argp-standalone/files/0001-throw-in-funcdef.patch
+++ /dev/null
@@ -1,84 +0,0 @@
-# --- T2-COPYRIGHT-NOTE-BEGIN ---
-# This copyright note is auto-generated by ./scripts/Create-CopyPatch.
-# 
-# T2 SDE: package/.../rng-tools/throw-in-funcdef.patch.argp-standalone
-# Copyright (C) 2006 The T2 SDE Project
-# 
-# More information can be found in the files COPYING and README.
-# 
-# This patch file is dual-licensed. It is available under the license the
-# patched project is licensed under, as long as it is an OpenSource license
-# as defined at http://www.opensource.org/ (e.g. BSD, X11) or under the terms
-# of the GNU General Public License as published by the Free Software
-# Foundation; either version 2 of the License, or (at your option) any later
-# version.
-# --- T2-COPYRIGHT-NOTE-END ---
-
-
-No __THROW in function implementation.
-	--jsaw
-
-Taken from buildroot
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-
---- argp-standalone-1.4-test2/argp.h.orig	2006-01-06 02:29:59.000000000 +0100
-+++ argp-standalone-1.4-test2/argp.h	2006-01-06 02:41:10.000000000 +0100
-@@ -560,17 +560,17 @@
- # endif
- 
- # ifndef ARGP_EI
--#  define ARGP_EI extern __inline__
-+#  define ARGP_EI extern inline
- # endif
- 
- ARGP_EI void
--__argp_usage (__const struct argp_state *__state) __THROW
-+__argp_usage (__const struct argp_state *__state)
- {
-   __argp_state_help (__state, stderr, ARGP_HELP_STD_USAGE);
- }
- 
- ARGP_EI int
--__option_is_short (__const struct argp_option *__opt) __THROW
-+__option_is_short (__const struct argp_option *__opt)
- {
-   if (__opt->flags & OPTION_DOC)
-     return 0;
-@@ -582,7 +582,7 @@
- }
- 
- ARGP_EI int
--__option_is_end (__const struct argp_option *__opt) __THROW
-+__option_is_end (__const struct argp_option *__opt)
- {
-   return !__opt->key && !__opt->name && !__opt->doc && !__opt->group;
- }
---- argp-standalone-1.4-test2/argp-parse.c.orig	2006-01-06 02:47:48.000000000 +0100
-+++ argp-standalone-1.4-test2/argp-parse.c	2006-01-06 02:48:16.000000000 +0100
-@@ -1290,13 +1290,13 @@
- /* Defined here, in case a user is not inlining the definitions in
-  * argp.h */
- void
--__argp_usage (__const struct argp_state *__state) __THROW
-+__argp_usage (__const struct argp_state *__state)
- {
-   __argp_state_help (__state, stderr, ARGP_HELP_STD_USAGE);
- }
- 
- int
--__option_is_short (__const struct argp_option *__opt) __THROW
-+__option_is_short (__const struct argp_option *__opt) 
- {
-   if (__opt->flags & OPTION_DOC)
-     return 0;
-@@ -1310,7 +1310,7 @@
- }
- 
- int
--__option_is_end (__const struct argp_option *__opt) __THROW
-+__option_is_end (__const struct argp_option *__opt) 
- {
-   return !__opt->key && !__opt->name && !__opt->doc && !__opt->group;
- }
diff --git a/meta/recipes-support/argp-standalone/files/0002-isprint.patch b/meta/recipes-support/argp-standalone/files/0002-isprint.patch
deleted file mode 100644
index 1c07eea3c1..0000000000
--- a/meta/recipes-support/argp-standalone/files/0002-isprint.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-Subject: restrict value range passed to isprint function
-
-According to C standards isprint argument shall be representable as an
-unsigned char or be equal to EOF, otherwise the behaviour is undefined.
-
-Passing arbitrary ints leads to segfault in nm program from elfutils.
-
-Restrict isprint argument range to values representable by unsigned char.
-
-Signed-off-by: Max Filippov <jcmvbkbc@gmail.com>
-
-Taken from buildroot
-
-Upstream-Status: Pending
-Signed-off-by: Khem Raj <raj.khem@gmail.com>
-
----
-Index: b/argp.h
-===================================================================
---- a/argp.h
-+++ b/argp.h
-@@ -23,6 +23,7 @@
- 
- #include <stdio.h>
- #include <ctype.h>
-+#include <limits.h>
- 
- #define __need_error_t
- #include <errno.h>
-@@ -577,7 +578,7 @@
-   else
-     {
-       int __key = __opt->key;
--      return __key > 0 && isprint (__key);
-+      return __key > 0 && __key <= UCHAR_MAX && isprint (__key);
-     }
- }
- 
-Index: b/argp-parse.c
-===================================================================
---- a/argp-parse.c
-+++ b/argp-parse.c
-@@ -1292,7 +1292,7 @@
-       int __key = __opt->key;
-       /* FIXME: whether or not a particular key implies a short option
-        * ought not to be locale dependent. */
--      return __key > 0 && isprint (__key);
-+      return __key > 0 && __key <= UCHAR_MAX && isprint (__key);
-     }
- }
- 
diff --git a/meta/recipes-support/argp-standalone/files/out_of_tree_build.patch b/meta/recipes-support/argp-standalone/files/out_of_tree_build.patch
index b7777cbd91..c863104430 100644
--- a/meta/recipes-support/argp-standalone/files/out_of_tree_build.patch
+++ b/meta/recipes-support/argp-standalone/files/out_of_tree_build.patch
@@ -2,7 +2,7 @@ Fix the testsuite to built out of tree
 in OE S != B
 
 Signed-off-by: Khem Raj <raj.khem@gmail.com>
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/ericonr/argp-standalone/pull/9]
 Index: argp-standalone-1.3/testsuite/Makefile.am
 ===================================================================
 --- argp-standalone-1.3.orig/testsuite/Makefile.am
-- 
2.30.2

[PATCH 11/13] ovmf: correct patches status

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../ovmf/0001-ovmf-update-path-to-native-BaseTools.patch   | 2 +-
 ...seTools-makefile-adjust-to-build-in-under-bitbake.patch | 7 ++++++-
 2 files changed, 7 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-core/ovmf/ovmf/0001-ovmf-update-path-to-native-BaseTools.patch b/meta/recipes-core/ovmf/ovmf/0001-ovmf-update-path-to-native-BaseTools.patch
index 89d9ffab5e..0c3df4fc44 100644
--- a/meta/recipes-core/ovmf/ovmf/0001-ovmf-update-path-to-native-BaseTools.patch
+++ b/meta/recipes-core/ovmf/ovmf/0001-ovmf-update-path-to-native-BaseTools.patch
@@ -10,7 +10,7 @@ tools. The BBAKE_EDK_TOOLS_PATH string is used as a pattern to be replaced
 with the appropriate location before building.
 
 Signed-off-by: Ricardo Neri <ricardo.neri-calderon@linux.intel.com>
-Upstream-Status: Pending
+Upstream-Status: Inappropriate [oe-core cross compile specific]
 ---
  OvmfPkg/build.sh | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-core/ovmf/ovmf/0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch b/meta/recipes-core/ovmf/ovmf/0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch
index f6141c8af5..2293d7e938 100644
--- a/meta/recipes-core/ovmf/ovmf/0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch
+++ b/meta/recipes-core/ovmf/ovmf/0002-BaseTools-makefile-adjust-to-build-in-under-bitbake.patch
@@ -6,8 +6,13 @@ Subject: [PATCH 2/6] BaseTools: makefile: adjust to build in under bitbake
 Prepend the build flags with those of bitbake. This is to build
 using the bitbake native sysroot include and library directories.
 
+Note from Alex: this is not appropriate for upstream submission as
+the recipe already does lots of similar in-place fixups elsewhere, so
+this patch shold be converted to follow that pattern. We're not going
+to fight against how upstream wants to configure the build.
+
 Signed-off-by: Ricardo Neri <ricardo.neri@linux.intel.com>
-Upstream-Status: Pending
+Upstream-Status: Inappropriate [needs to be converted to in-recipe fixups]
 ---
  BaseTools/Source/C/Makefiles/header.makefile | 17 +++++++++--------
  1 file changed, 9 insertions(+), 8 deletions(-)
-- 
2.30.2

[PATCH 12/13] go: submit patch upstream

[Alexander Kanavin]

Note: it will not be reviewed until RP signs the google CLA
(link in the PR).

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 meta/recipes-devtools/go/go/filter-build-paths.patch | 4 +++-
 1 file changed, 3 insertions(+), 1 deletion(-)

diff --git a/meta/recipes-devtools/go/go/filter-build-paths.patch b/meta/recipes-devtools/go/go/filter-build-paths.patch
index a1aa37c2a4..a036f177e0 100644
--- a/meta/recipes-devtools/go/go/filter-build-paths.patch
+++ b/meta/recipes-devtools/go/go/filter-build-paths.patch
@@ -8,7 +8,9 @@ embedded in the go binary so that builds are reproducible regardless of build
 location. This codepath is hit for statically linked go binaries such as those
 on mips/ppc.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/golang/go/pull/56410]
+Note: RP needs to sign Google CLA for the PR to proceed.
+
 Signed-off-by: Richard Purdie <richard.purdie@linuxfoundation.org>
 
 ---
-- 
2.30.2

[PATCH 13/13] libffi: submit patch upstream

[Alexander Kanavin]

Signed-off-by: Alexander Kanavin <alex@linutronix.de>
---
 .../libffi/0001-arm-sysv-reverted-clang-VFP-mitigation.patch    | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-support/libffi/libffi/0001-arm-sysv-reverted-clang-VFP-mitigation.patch b/meta/recipes-support/libffi/libffi/0001-arm-sysv-reverted-clang-VFP-mitigation.patch
index 5e529d1ce7..4233799501 100644
--- a/meta/recipes-support/libffi/libffi/0001-arm-sysv-reverted-clang-VFP-mitigation.patch
+++ b/meta/recipes-support/libffi/libffi/0001-arm-sysv-reverted-clang-VFP-mitigation.patch
@@ -11,7 +11,7 @@ https://github.com/libffi/libffi/issues/607. Now that
 clang supports the LDC and SDC instructions, this mitigation
 has been reverted.
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [https://github.com/libffi/libffi/pull/747]
 Signed-off-by: Brett Warren <brett.warren@arm.com>
 ---
  src/arm/sysv.S | 33 ---------------------------------
-- 
2.30.2

Re: [OE-core] [PATCH 12/13] go: submit patch upstream

[Richard Purdie]

On Mon, 2022-10-31 at 12:47 +0100, Alexander Kanavin wrote:
> Note: it will not be reviewed until RP signs the google CLA
> (link in the PR).
> 
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>  meta/recipes-devtools/go/go/filter-build-paths.patch | 4 +++-
>  1 file changed, 3 insertions(+), 1 deletion(-)
> 
> diff --git a/meta/recipes-devtools/go/go/filter-build-paths.patch b/meta/recipes-devtools/go/go/filter-build-paths.patch
> index a1aa37c2a4..a036f177e0 100644
> --- a/meta/recipes-devtools/go/go/filter-build-paths.patch
> +++ b/meta/recipes-devtools/go/go/filter-build-paths.patch
> @@ -8,7 +8,9 @@ embedded in the go binary so that builds are reproducible regardless of build
>  location. This codepath is hit for statically linked go binaries such as those
>  on mips/ppc.
>  
> -Upstream-Status: Pending
> +Upstream-Status: Submitted [https://github.com/golang/go/pull/56410]
> +Note: RP needs to sign Google CLA for the PR to proceed.
> +

I did sort that, I'm not sure I quite wanted to get into a larger
discussion on how to do it properly and to rewrite the patch and run
more tests though...

Cheers,

Richard

Re: [OE-core] [PATCH 12/13] go: submit patch upstream

[Alexander Kanavin]

On Mon, 31 Oct 2022 at 22:55, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:

> I did sort that, I'm not sure I quite wanted to get into a larger
> discussion on how to do it properly and to rewrite the patch and run
> more tests though...

I wasn't inspired by those review comments either, perhaps we can
convince upstream to take the existing patch as a 'bug report' and
leave the actual fix to them.

Alex

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Randy MacLeod]

On 2022-10-31 07:47, Alexander Kanavin wrote:
> For better or worse, more and more rust components are appearing that do
> not include their dependencies in tarballs (or git trees), and rely on cargo
> to fetch them. On the other hand, bitbake does not use cargo (and quite possible
> won't ever be able to), and relies on having each item explicitly listed in SRC_URI
> with a crate:// prefix. This however creates a problem of both making such lists in
> the first place and updating them when a recipe is updated to a newer version.
>
> So this class can be used to perform such updates by implementing a task that does it;
> the next commit shows the outcome for python3-bcrypt (which has been tested to work
> and produce a successful build).
>
> Note: the python script relies on tomllib library, which appears in Python 3.11 and
> does not exist in earlier versions - I've tested this by first updating python to 3.11-rc2
> in oe-core.


Thanks Alex, that's a nice approach.

I'm reply to the thread since Jin had some trouble getting started
with this class. This pushed me to finally try it and I have some minor
comments and suggestions.

First, it works for me for adding ripgrep (1) and for Jin for something 
he was
working on. It wasn't a perfect experience for me since at first, I
had omitted:

S = "${WORKDIR}/git"

and
$ bitbake -c update_crates  ripgrep

would fail silently with nothing useful in the log.do_update_crates file.

I'll likely send a patch to make it more verbose on error.


It also wasn't clear how to get started but in hindsight, you need 
'obviously'
need a recipe that has SRC_URI and SRCREV and S and maybe a bit more to 
get started.


Michael,

Do you think we should a document this workflow in addition to the cargo 
bitbake approach?

../Randy


1) https://github.com/BurntSushi/ripgrep

Recipe will go to meta-oe.

>
> Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> ---
>   .../cargo-update-recipe-crates.bbclass        | 41 +++++++++++++++++++
>   1 file changed, 41 insertions(+)
>   create mode 100644 meta/classes-recipe/cargo-update-recipe-crates.bbclass
>
> diff --git a/meta/classes-recipe/cargo-update-recipe-crates.bbclass b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
> new file mode 100644
> index 0000000000..f90938c734
> --- /dev/null
> +++ b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
> @@ -0,0 +1,41 @@
> +#
> +# Copyright OpenEmbedded Contributors
> +#
> +# SPDX-License-Identifier: MIT
> +#
> +
> +##
> +## Purpose:
> +## This class is used to update the list of crates in SRC_URI
> +## by reading Cargo.lock in the source tree.
> +##
> +## See meta/recipes-devtools/python/python3-bcrypt_*.bb for an example
> +##
> +## To perform the update: bitbake -c update_crates recipe-name
> +
> +addtask do_update_crates after do_patch
> +do_update_crates[depends] = "python3-native:do_populate_sysroot"
> +
> +do_update_crates() {
> +    nativepython3 - <<EOF
> +
> +def get_crates(f):
> +    import tomllib
> +    c_list = 'SRC_URI += " \\ \n'
> +    crates = tomllib.load(open(f, 'rb'))
> +    for c in crates['package']:
> +        if 'source' in c and 'crates.io' in c['source']:
> +            c_list += "        crate://crates.io/{}/{} \\ \n".format(c['name'], c['version'])
> +    c_list += '"\n'
> +    return c_list
> +
> +import os
> +crates = "# Autogenerated with 'bitbake -c update_crates ${PN}'\n\n"
> +for root, dirs, files in os.walk('${S}'):
> +    for file in files:
> +        if file == 'Cargo.lock':
> +            crates += get_crates(os.path.join(root, file))
> +open(os.path.join('${THISDIR}', '${PN}'+"-crates.inc"), 'w').write(crates)
> +
> +EOF
> +}
>
> -=-=-=-=-=-=-=-=-=-=-=-
> Links: You receive all messages sent to this group.
> View/Reply Online (#172303): https://lists.openembedded.org/g/openembedded-core/message/172303
> Mute This Topic: https://lists.openembedded.org/mt/94683148/3616765
> Group Owner: openembedded-core+owner@lists.openembedded.org
> Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> -=-=-=-=-=-=-=-=-=-=-=-
>

-- 
# Randy MacLeod
# Wind River Linux

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Sergey 'Jin' Bostandzhyan]

Hi everyone,

I promised Randy to post my experience with Yocto and Rust, which was a
first time attempt for me. Note, that when starting I had no knowledge about 
Rust whatsoever, so this is "clean start" observation.

On Tue, Dec 06, 2022 at 06:04:18PM -0500, Randy MacLeod wrote:
> On 2022-10-31 07:47, Alexander Kanavin wrote:
> >For better or worse, more and more rust components are appearing that do
> >not include their dependencies in tarballs (or git trees), and rely on cargo
> >to fetch them. On the other hand, bitbake does not use cargo (and quite possible
> >won't ever be able to), and relies on having each item explicitly listed in SRC_URI
> >with a crate:// prefix. This however creates a problem of both making such lists in
> >the first place and updating them when a recipe is updated to a newer version.
> >
> >So this class can be used to perform such updates by implementing a task that does it;
> >the next commit shows the outcome for python3-bcrypt (which has been tested to work
> >and produce a successful build).
> >
> >Note: the python script relies on tomllib library, which appears in Python 3.11 and
> >does not exist in earlier versions - I've tested this by first updating python to 3.11-rc2
> >in oe-core.
> 
> 
> Thanks Alex, that's a nice approach.
> 
> I'm reply to the thread since Jin had some trouble getting started
> with this class. This pushed me to finally try it and I have some minor
> comments and suggestions.

my first issue was to actually find out how to approach this, it seems
most google hits point to meta-rust which has been around for a longer period
and I was lucky to get some hints in #oe on IRC, where Randy pointed me to 
cargo-update-recipe-crates.bbclass which is already in Poky.

The comment in the header about running bitbake -c update_crates recipe-name
allowed me to generate the .inc file, but it was not immediately clear to me
what I should do next.

The pointer to python3-bcrypt_*.bb was a bit confusing in the sense, that
from the rust perspective it only inherits cargo-update-recipe-crates,
but trying to build my package after having genrated the SRC_URI entries did
not produce any build output, I ended up with an empty -dev and an empty -dbg 
ipk.

By looking at the available classes I figured that I should probably also
inherit cargo, which indeed started to compile the application I needed to
package.

Next, I ran into some build issues for packages which I guess the application
was depending upon. I got an error:

error: failed to run custom build command for `libudev-sys v0.1.4`

which luckily had enough google hits to understand that it expects
a DEPENDS = "eudev"

It however still failed after that and it took me some time to realize
that I should also inherit pkgconfig, which finally did the trick.

I copied the working recipe back to Kirkstone and was happy to see, that it
builds there as well.

So overall, given that I had zero Rust knowledge, it wasn't a bad
experience, Yocto took care of most things for me.

> First, it works for me for adding ripgrep (1) and for Jin for
> something he was
> working on. It wasn't a perfect experience for me since at first, I
> had omitted:
> 
> S = "${WORKDIR}/git"
> 
> and
> $ bitbake -c update_crates  ripgrep
> 
> would fail silently with nothing useful in the log.do_update_crates file.
> 
> I'll likely send a patch to make it more verbose on error.
> 
> 
> It also wasn't clear how to get started but in hindsight, you need
> 'obviously'
> need a recipe that has SRC_URI and SRCREV and S and maybe a bit more
> to get started.
> 
> 
> Michael,
> 
> Do you think we should a document this workflow in addition to the
> cargo bitbake approach?

I think this should be documented more prominently, as missing information
on how to get going was the biggest obstacle, at least for me. The benefit of
this workflow is, that no additional layer is needed and that everything seems
to more or less work out of the box within the usual checkout.

The downside is a two step approach and I wonder if it would be possible to
append the SRC_URI crate entries on the fly, but in a way that still works
with sstate so that regeneration happens only when something has changed.

Anyway, it seems to be a good start, thanks to everyone who made this possible!

Kind regards,
Jin

 
 
> 1) https://github.com/BurntSushi/ripgrep
> 
> Recipe will go to meta-oe.
> 
> >
> >Signed-off-by: Alexander Kanavin <alex@linutronix.de>
> >---
> >  .../cargo-update-recipe-crates.bbclass        | 41 +++++++++++++++++++
> >  1 file changed, 41 insertions(+)
> >  create mode 100644 meta/classes-recipe/cargo-update-recipe-crates.bbclass
> >
> >diff --git a/meta/classes-recipe/cargo-update-recipe-crates.bbclass b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
> >new file mode 100644
> >index 0000000000..f90938c734
> >--- /dev/null
> >+++ b/meta/classes-recipe/cargo-update-recipe-crates.bbclass
> >@@ -0,0 +1,41 @@
> >+#
> >+# Copyright OpenEmbedded Contributors
> >+#
> >+# SPDX-License-Identifier: MIT
> >+#
> >+
> >+##
> >+## Purpose:
> >+## This class is used to update the list of crates in SRC_URI
> >+## by reading Cargo.lock in the source tree.
> >+##
> >+## See meta/recipes-devtools/python/python3-bcrypt_*.bb for an example
> >+##
> >+## To perform the update: bitbake -c update_crates recipe-name
> >+
> >+addtask do_update_crates after do_patch
> >+do_update_crates[depends] = "python3-native:do_populate_sysroot"
> >+
> >+do_update_crates() {
> >+    nativepython3 - <<EOF
> >+
> >+def get_crates(f):
> >+    import tomllib
> >+    c_list = 'SRC_URI += " \\ \n'
> >+    crates = tomllib.load(open(f, 'rb'))
> >+    for c in crates['package']:
> >+        if 'source' in c and 'crates.io' in c['source']:
> >+            c_list += "        crate://crates.io/{}/{} \\ \n".format(c['name'], c['version'])
> >+    c_list += '"\n'
> >+    return c_list
> >+
> >+import os
> >+crates = "# Autogenerated with 'bitbake -c update_crates ${PN}'\n\n"
> >+for root, dirs, files in os.walk('${S}'):
> >+    for file in files:
> >+        if file == 'Cargo.lock':
> >+            crates += get_crates(os.path.join(root, file))
> >+open(os.path.join('${THISDIR}', '${PN}'+"-crates.inc"), 'w').write(crates)
> >+
> >+EOF
> >+}
> >
> >-=-=-=-=-=-=-=-=-=-=-=-
> >Links: You receive all messages sent to this group.
> >View/Reply Online (#172303): https://lists.openembedded.org/g/openembedded-core/message/172303
> >Mute This Topic: https://lists.openembedded.org/mt/94683148/3616765
> >Group Owner: openembedded-core+owner@lists.openembedded.org
> >Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [randy.macleod@windriver.com]
> >-=-=-=-=-=-=-=-=-=-=-=-
> >
> 
> -- 
> # Randy MacLeod
> # Wind River Linux

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

On Wed, 7 Dec 2022 at 01:21, Sergey Bostandzhyan <jin@mediatomb.cc> wrote:
> I think this should be documented more prominently, as missing information
> on how to get going was the biggest obstacle, at least for me. The benefit of
> this workflow is, that no additional layer is needed and that everything seems
> to more or less work out of the box within the usual checkout.

Thanks for the report, I totally agree that the rust recipe workflow
should be documented somewhere in the official manuals, I'm just not
sure where. Perhaps the 'common tasks' in
https://docs.yoctoproject.org/dev-manual/index.html ?

Can you write and propose a patch to the documentation repository?

> The downside is a two step approach and I wonder if it would be possible to
> append the SRC_URI crate entries on the fly, but in a way that still works
> with sstate so that regeneration happens only when something has changed.

You can't modify anything in the layers during bitbake tasks, only if
the task is completely standalone and isolated. You also can't modify
SRC_URI internally after fetching as SRC_URI needs to be fully formed
before the fetch task runs. What we can do is provide better hints in
case cargo fails because the list of crates mismatches the lockdown
file in the source, and needs to be updated (or created). Can this be
reliably detected?

Alex

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Stefan Herbrechtsmeier]

Hi Alex,

Am 07.12.2022 um 09:53 schrieb Alexander Kanavin via lists.openembedded.org:
> On Wed, 7 Dec 2022 at 01:21, Sergey Bostandzhyan <jin@mediatomb.cc> wrote:
>> I think this should be documented more prominently, as missing information
>> on how to get going was the biggest obstacle, at least for me. The benefit of
>> this workflow is, that no additional layer is needed and that everything seems
>> to more or less work out of the box within the usual checkout.
> Thanks for the report, I totally agree that the rust recipe workflow
> should be documented somewhere in the official manuals, I'm just not
> sure where. Perhaps the 'common tasks' in
> https://docs.yoctoproject.org/dev-manual/index.html ?
>
> Can you write and propose a patch to the documentation repository?

Is the recipetool obsolete or why we have yust an other tool to create a 
recipe in oe-core?

Regards
   Stefan

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

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

On Wed 7. Dec 2022 at 16.28, Stefan Herbrechtsmeier <
stefan.herbrechtsmeier-oss@weidmueller.com> wrote:

> Hi Alex,
>
> Am 07.12.2022 um 09:53 schrieb Alexander Kanavin via
> lists.openembedded.org:
> > On Wed, 7 Dec 2022 at 01:21, Sergey Bostandzhyan <jin@mediatomb.cc>
> wrote:
> >> I think this should be documented more prominently, as missing
> information
> >> on how to get going was the biggest obstacle, at least for me. The
> benefit of
> >> this workflow is, that no additional layer is needed and that
> everything seems
> >> to more or less work out of the box within the usual checkout.
> > Thanks for the report, I totally agree that the rust recipe workflow
> > should be documented somewhere in the official manuals, I'm just not
> > sure where. Perhaps the 'common tasks' in
> > https://docs.yoctoproject.org/dev-manual/index.html ?
> >
> > Can you write and propose a patch to the documentation repository?
>
> Is the recipetool obsolete or why we have yust an other tool to create a
> recipe in oe-core?


Which another tool are you referring to? Cargo bitbake is a 3rd party
project, one that I am not recommending to anyone in any way. And having a
class to update or create a list of crates does not preclude its use in
recipetool. Patches welcome.

A bit of politeness would be welcome too, Stefan, seriously. Watch your
tone.

Alex

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

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Stefan Herbrechtsmeier]

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

Hi Alex,

Am 07.12.2022 um 17:21 schrieb Alexander Kanavin:
> On Wed 7. Dec 2022 at 16.28, Stefan Herbrechtsmeier 
> <stefan.herbrechtsmeier-oss@weidmueller.com> wrote:
>
>     Hi Alex,
>
>     Am 07.12.2022 um 09:53 schrieb Alexander Kanavin via
>     lists.openembedded.org <http://lists.openembedded.org>:
>     > On Wed, 7 Dec 2022 at 01:21, Sergey Bostandzhyan
>     <jin@mediatomb.cc> wrote:
>     >> I think this should be documented more prominently, as missing
>     information
>     >> on how to get going was the biggest obstacle, at least for me.
>     The benefit of
>     >> this workflow is, that no additional layer is needed and that
>     everything seems
>     >> to more or less work out of the box within the usual checkout.
>     > Thanks for the report, I totally agree that the rust recipe workflow
>     > should be documented somewhere in the official manuals, I'm just not
>     > sure where. Perhaps the 'common tasks' in
>     > https://docs.yoctoproject.org/dev-manual/index.html ?
>     >
>     > Can you write and propose a patch to the documentation repository?
>
>     Is the recipetool obsolete or why we have yust an other tool to
>     create a
>     recipe in oe-core?
>
>
> Which another tool are you referring to? Cargo bitbake is a 3rd party 
> project, one that I am not recommending to anyone in any way. And 
> having a class to update or create a list of crates does not preclude 
> its use in recipetool. Patches welcome.
>
> A bit of politeness would be welcome too, Stefan, seriously. Watch 
> your tone.

Sorry for the harsh tone but you ignore existing tools and add just 
another tool to oe-core without mention any reason or document it. Do 
you really expect that somebody will patch existing tools if main 
developers ignore existing tools and provide new tool for their use 
case? Why should somebody improve an existing tool, extend the 
documentation, add tests or even upstream its work if these same 
requirements don’t exist for the main developers. It looks like the 
requirements for foreign and main contributors are different and this 
doesn't encourage people to participant. Maybe this is only my personal 
feeling and I apologize my harsh tone, but the acceptance of patches 
should be comprehensible, and expectations should be the same for 
everyone. Should others answer to your comments that their solution 
doesn’t preclude your suggestion and that they welcome patches? For sure 
it takes more time to add rust support to recipetool but I think a 
second tool without a clear reason in oe-core hurts more in long term 
because its now unclear if new features (like checksums or licenses 
support) should be added to this tool or if this tool is only a 
temporary solution and should be replaced by recipetool in long term. 
Furthermore, this class is marked as a class for a recipe but shouldn’t 
be inherit by a recipe and manipulates a file inside the meta data.

Regards
   Stefan

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

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Richard Purdie]

On Fri, 2022-12-09 at 11:39 +0100, Stefan Herbrechtsmeier wrote:
> Sorry for the harsh tone but you ignore existing tools and add just
> another tool to oe-core without mention any reason or document it. Do
> you really expect that somebody will patch existing tools if main
> developers ignore existing tools and provide new tool for their use
> case?

I'm not sure that is entirely fair criticism. We have some challenges
with some of the new languages. Rust support was in a separate layer.
We took some of those recipes into core, then ended up making
significant changes to them. We never took the external tool.

The hope in doing that was that we'd find a better way to make things
work. I think what Alex has done is an improvement over that external
tool and it experiments with a different way of handling things. I've
had generally quite positive feedback on the approach itself. Yes,
there are some issues with documentation and some people using it have
struggled with some usability issues. None of those look like they're
unfixable.

>  Why should somebody improve an existing tool, extend the
> documentation, add tests or even upstream its work if these same
> requirements don’t exist for the main developers. It looks like the
> requirements for foreign and main contributors are different and this
> doesn't encourage people to participant.

I don't see us treating developers differently and I am concerned you
think we/I do. Any given solution that is proposed is evaluated on it's
pros and cons. In this case the solution is quite self contained and
allowed the approach to be experimented with whilst solving a real
world issue. If it doesn't work out we can easily drop it. The risk
from taking it is therefore low. Yes, I should probably insist on
documentation. In this case it is relatively simple code which is
relatively easily understood so I've been less worried about that up
front.

If it worked out well, we can integrate it further and document it. If
it doesn't it can be removed. FWIW I have heard people saying they like
the approach and that we should use it for some of the other languages
with challenges like this.

>  Maybe this is only my personal feeling and I apologize my harsh
> tone, but the acceptance of patches should be comprehensible, and
> expectations should be the same for everyone.

I do try to ensure that. My "algorithm" for accepting patches is
probably not easily documented but I think the factors here which are 
the standalone nature of the change and the easy with which we could
drop it if needed. As such it is in my "low risk" category of patches.

I'd note Alex has another patch which has been sitting for months
unmerged as it is in my "high risk" to the project category. I suspect
that one will not actually merge but I need to find the time to explain
why, right now it is more based on a feeling it is the wrong direction.

>  Should others answer to your comments that their solution doesn’t
> preclude your suggestion and that they welcome patches? For sure it
> takes more time to add rust support to recipetool but I think a
> second tool without a clear reason in oe-core hurts more in long term
> because its now unclear if new features (like checksums or licenses
> support) should be added to this tool or if this tool is only a
> temporary solution and should be replaced by recipetool in long term.
> Furthermore, this class is marked as a class for a recipe but
> shouldn’t be inherit by a recipe and manipulates a file inside the
> meta data.

We do have precedence for classes that help updates like this. Both
python and perl have code that adds tasks that function a bit like
this, in those cases for the core recipe.

Personally, I would ultimately like to see these operations handled by
recipetool and I suspect natural evolution of the code may head that
way. Both devtool and recipetool have used classes as a way to help
them perform operations so in that sense, this is actually a logical
development path for those tools.

Cheers,

Richard

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

On Fri, 9 Dec 2022 at 11:39, Stefan Herbrechtsmeier
<stefan.herbrechtsmeier-oss@weidmueller.com> wrote:
> Sorry for the harsh tone but you ignore existing tools and add just another tool to oe-core without mention any reason or document it.

The reason to add the class was to be able to update existing
rust-based recipes without having to manually update long lists of
crates in those recipes, which is a rather urgent issue, more urgent
than having rust support in recipetool. The class does not replace
recipetool, in fact it can, and should be used by devtool/recipetool
once someone finds time and motivation to sit down and add (currently
missing) rust support to it (class functionality can be executed from
those tools via tinfoil.build_targets()). I do not have that time, and
I am not getting paid for doing that either. Oh, and we do not have a
maintainer for those tools. Would you like to volunteer for that?

Documentation is handled in a separate repository, and is typically
decoupled from actual code. I'll get to it, but you should know that
some things are actually higher priority. Such as keeping core
updated, so that you can have a secure stack in the products you sell,
and doing paid customer work, so that I can pay my bills. I'd
appreciate if you reflect on the fact that none of my upstream work is
recognized, or supported by your company, even though without it you
would not have a product to sell - which in turn pays your bills.

Alex

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

On Fri, 9 Dec 2022 at 13:01, Richard Purdie
<richard.purdie@linuxfoundation.org> wrote:
> I'd note Alex has another patch which has been sitting for months
> unmerged as it is in my "high risk" to the project category. I suspect
> that one will not actually merge but I need to find the time to explain
> why, right now it is more based on a feeling it is the wrong direction.

I'd be happy to be 'course corrected' on oe-setup-build, I personally
feel it does more 'guessing' than I'm comfortable with but I can't
figure out a better way to handle things. The problems it's aiming to
address are real, so it shouldn't be formally rejected without a plan.

Alex

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Richard Purdie]

On Fri, 2022-12-09 at 15:43 +0100, Alexander Kanavin wrote:
> On Fri, 9 Dec 2022 at 13:01, Richard Purdie
> <richard.purdie@linuxfoundation.org> wrote:
> > I'd note Alex has another patch which has been sitting for months
> > unmerged as it is in my "high risk" to the project category. I suspect
> > that one will not actually merge but I need to find the time to explain
> > why, right now it is more based on a feeling it is the wrong direction.
> 
> I'd be happy to be 'course corrected' on oe-setup-build, I personally
> feel it does more 'guessing' than I'm comfortable with but I can't
> figure out a better way to handle things. The problems it's aiming to
> address are real, so it shouldn't be formally rejected without a plan.

Right, I do need to explain why I'm reluctant about it and what the
concerns are. Sadly doing that isn't straightforward, particularly if
the bar is set to the height of "show how a better approach would work"
since I then have to think through a new design before I can reply. The
challenge with that patch is that it uses a very predominant namespace
and can't easily change once we take that direction so that makes
merging much harder.

My point here was that patches from everyone are treated fairly, some
merge quickly, some don't, it really does depend.

There are also patches from some guy called Richard on the bitbake
mailing list which Richard is refusing to merge due to performance
concerns :)

Cheers,

Richard

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Stefan Herbrechtsmeier]

Hi Richard,

Am 09.12.2022 um 13:01 schrieb Richard Purdie:
> On Fri, 2022-12-09 at 11:39 +0100, Stefan Herbrechtsmeier wrote:
>> Sorry for the harsh tone but you ignore existing tools and add just
>> another tool to oe-core without mention any reason or document it. Do
>> you really expect that somebody will patch existing tools if main
>> developers ignore existing tools and provide new tool for their use
>> case?
> I'm not sure that is entirely fair criticism. We have some challenges
> with some of the new languages. Rust support was in a separate layer.
> We took some of those recipes into core, then ended up making
> significant changes to them. We never took the external tool.
>
> The hope in doing that was that we'd find a better way to make things
> work. I think what Alex has done is an improvement over that external
> tool and it experiments with a different way of handling things. I've
> had generally quite positive feedback on the approach itself. Yes,
> there are some issues with documentation and some people using it have
> struggled with some usability issues. None of those look like they're
> unfixable.
>
>>   Why should somebody improve an existing tool, extend the
>> documentation, add tests or even upstream its work if these same
>> requirements don’t exist for the main developers. It looks like the
>> requirements for foreign and main contributors are different and this
>> doesn't encourage people to participant.
> I don't see us treating developers differently and I am concerned you
> think we/I do. Any given solution that is proposed is evaluated on it's
> pros and cons. In this case the solution is quite self contained and
> allowed the approach to be experimented with whilst solving a real
> world issue. If it doesn't work out we can easily drop it. The risk
> from taking it is therefore low. Yes, I should probably insist on
> documentation. In this case it is relatively simple code which is
> relatively easily understood so I've been less worried about that up
> front.
>
> If it worked out well, we can integrate it further and document it. If
> it doesn't it can be removed. FWIW I have heard people saying they like
> the approach and that we should use it for some of the other languages
> with challenges like this.
>
>>   Maybe this is only my personal feeling and I apologize my harsh
>> tone, but the acceptance of patches should be comprehensible, and
>> expectations should be the same for everyone.
> I do try to ensure that. My "algorithm" for accepting patches is
> probably not easily documented but I think the factors here which are
> the standalone nature of the change and the easy with which we could
> drop it if needed. As such it is in my "low risk" category of patches.
>
> I'd note Alex has another patch which has been sitting for months
> unmerged as it is in my "high risk" to the project category. I suspect
> that one will not actually merge but I need to find the time to explain
> why, right now it is more based on a feeling it is the wrong direction.
>
>>   Should others answer to your comments that their solution doesn’t
>> preclude your suggestion and that they welcome patches? For sure it
>> takes more time to add rust support to recipetool but I think a
>> second tool without a clear reason in oe-core hurts more in long term
>> because its now unclear if new features (like checksums or licenses
>> support) should be added to this tool or if this tool is only a
>> temporary solution and should be replaced by recipetool in long term.
>> Furthermore, this class is marked as a class for a recipe but
>> shouldn’t be inherit by a recipe and manipulates a file inside the
>> meta data.
> We do have precedence for classes that help updates like this. Both
> python and perl have code that adds tasks that function a bit like
> this, in those cases for the core recipe.
>
> Personally, I would ultimately like to see these operations handled by
> recipetool and I suspect natural evolution of the code may head that
> way. Both devtool and recipetool have used classes as a way to help
> them perform operations so in that sense, this is actually a logical
> development path for those tools.

Thanks for you feedback and the clarification. This helps me a lot.

Stefan

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Stefan Herbrechtsmeier]

Hi Alex,

Am 09.12.2022 um 13:09 schrieb Alexander Kanavin:
> On Fri, 9 Dec 2022 at 11:39, Stefan Herbrechtsmeier
> <stefan.herbrechtsmeier-oss@weidmueller.com> wrote:
>> Sorry for the harsh tone but you ignore existing tools and add just another tool to oe-core without mention any reason or document it.
> The reason to add the class was to be able to update existing
> rust-based recipes without having to manually update long lists of
> crates in those recipes, which is a rather urgent issue, more urgent
> than having rust support in recipetool. The class does not replace
> recipetool, in fact it can, and should be used by devtool/recipetool
> once someone finds time and motivation to sit down and add (currently
> missing) rust support to it (class functionality can be executed from
> those tools via tinfoil.build_targets()). I do not have that time, and
> I am not getting paid for doing that either. Oh, and we do not have a
> maintainer for those tools. Would you like to volunteer for that?

Yes, I'm happy to maintain recipetool. We need to go on with our npm und 
go support anyway.

Regards
   Stefan

Re: [OE-core] [PATCH 01/13] cargo-update-recipe-crates.bbclass: add a class to generate SRC_URI crate lists from Cargo.lock

[Alexander Kanavin]

On Mon, 12 Dec 2022 at 15:18, Stefan Herbrechtsmeier
<stefan.herbrechtsmeier-oss@weidmueller.com> wrote:
> >> Sorry for the harsh tone but you ignore existing tools and add just another tool to oe-core without mention any reason or document it.
> > The reason to add the class was to be able to update existing
> > rust-based recipes without having to manually update long lists of
> > crates in those recipes, which is a rather urgent issue, more urgent
> > than having rust support in recipetool. The class does not replace
> > recipetool, in fact it can, and should be used by devtool/recipetool
> > once someone finds time and motivation to sit down and add (currently
> > missing) rust support to it (class functionality can be executed from
> > those tools via tinfoil.build_targets()). I do not have that time, and
> > I am not getting paid for doing that either. Oh, and we do not have a
> > maintainer for those tools. Would you like to volunteer for that?
>
> Yes, I'm happy to maintain recipetool. We need to go on with our npm und
> go support anyway.

Thank you, that would be very much appreciated.

We're all stretched thin, and need to continuously advocate the
importance of OSS maintenance as a job, as it's still not seen as
such. The problem is endemic across the software industry.

Alex