Re: [oe-core][PATCHv4] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

v4 adds Khems fix for riscv64

Am 28.03.23 um 07:57 schrieb Markus Volk:

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
   ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
   there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
   while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
   recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
   6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
   variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update
- add fixes that have been sent by kai.k...@eng.windriver.com
- add fix for riscv64 that has been sent by raj.k...@gmail.com

Signed-off-by: Markus Volk 
---
  meta/conf/distro/include/maintainers.inc  |   1 +
  ...spection.cmake-prefix-variables-obta.patch |   0
  ...ibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch |  34 
  ...44e17d258106617b0e6d783d073b188a2548.patch |  32 +++-
  .../webkit/files/disable_wasm_riscv64.patch   |  24 +++
  .../reproducibility.patch |   0
  .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 173 ++
  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ---
  ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  78 
  ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
  10 files changed, 296 insertions(+), 78 deletions(-)
  rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
  create mode 100644 
meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
  rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0d3344e17d258106617b0e6d783d073b188a2548.patch (87%)
  create mode 100644 meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch
  rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
  create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
  rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(71%)
  rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
  RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
  RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git 
a/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
new file mode 100644
index 00..dc56bbb92c
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/11913]
+
+Signed-off-by: Kai Kang 
+
+From de30f1a1caf81902d254e046e382f9cf9cd62c58 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Fri, 24 Mar 2023 17:58:29 +0800
+Subject: [PATCH] FindLibGcrypt.cmake: check PC_GCRYPT_FOUND
+
+After `pkg_check_modules(PC_GCRYPT QUIET libgcrypt)` in
+FindLibGcrypt.cmake, PC_GCRYPT_FOUND will be set but PC_GCRYPT is kept
+empty. So check PC_GCRYPT_FOUND instead.
+
+Signed-off-by: Kai Kang 
+---
+ Source/cmake/FindLibGcrypt.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Source/cmake/FindLibGcrypt.cmake 
b/Source/cmake/FindLibGcrypt.cmake
+index 8bee72963902..2

[oe-core][PATCHv4] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
  ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
  there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
  while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
  recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
  6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
  variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update
- add fixes that have been sent by kai.k...@eng.windriver.com
- add fix for riscv64 that has been sent by raj.k...@gmail.com

Signed-off-by: Markus Volk 
---
 meta/conf/distro/include/maintainers.inc  |   1 +
 ...spection.cmake-prefix-variables-obta.patch |   0
 ...ibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch |  34 
 ...44e17d258106617b0e6d783d073b188a2548.patch |  32 +++-
 .../webkit/files/disable_wasm_riscv64.patch   |  24 +++
 .../reproducibility.patch |   0
 .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 173 ++
 ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ---
 ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  78 
 ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
 10 files changed, 296 insertions(+), 78 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
 create mode 100644 
meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0d3344e17d258106617b0e6d783d073b188a2548.patch (87%)
 create mode 100644 meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch
 rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
 create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
 delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
 rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(71%)
 rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
 RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
 RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git 
a/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
new file mode 100644
index 00..dc56bbb92c
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/11913]
+
+Signed-off-by: Kai Kang 
+
+From de30f1a1caf81902d254e046e382f9cf9cd62c58 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Fri, 24 Mar 2023 17:58:29 +0800
+Subject: [PATCH] FindLibGcrypt.cmake: check PC_GCRYPT_FOUND
+
+After `pkg_check_modules(PC_GCRYPT QUIET libgcrypt)` in
+FindLibGcrypt.cmake, PC_GCRYPT_FOUND will be set but PC_GCRYPT is kept
+empty. So check PC_GCRYPT_FOUND instead.
+
+Signed-off-by: Kai Kang 
+---
+ Source/cmake/FindLibGcrypt.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Source/cmake/FindLibGcrypt.cmake 
b/Source/cmake/FindLibGcrypt.cmake
+index 8bee72963902..2e84cfc4e9b1 100644
+--- a/Source/cmake/FindLibGcrypt.cmake
 b/Source/cmake/FindLibGcrypt.cmake
+@@ -49,

[OE-core] [dunfell][PATCH] curl: CVE-2023-23916 HTTP multi-header compression denial of service

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://github.com/curl/curl/commit/119fb187192a9ea13dc90d9d20c215fc82799ab9

Signed-off-by: Hitendra Prajapati 
---
 .../curl/curl/CVE-2023-23916.patch| 231 ++
 meta/recipes-support/curl/curl_7.69.1.bb  |   1 +
 2 files changed, 232 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-23916.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2023-23916.patch 
b/meta/recipes-support/curl/curl/CVE-2023-23916.patch
new file mode 100644
index 00..054615963e
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-23916.patch
@@ -0,0 +1,231 @@
+From 119fb187192a9ea13dc90d9d20c215fc82799ab9 Mon Sep 17 00:00:00 2001
+From: Patrick Monnerat 
+Date: Mon, 13 Feb 2023 08:33:09 +0100
+Subject: [PATCH] content_encoding: do not reset stage counter for each header
+
+Test 418 verifies
+
+Closes #10492
+
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/119fb187192a9ea13dc90d9d20c215fc82799ab9]
+CVE: CVE-2023-23916
+Signed-off-by: Hitendra Prajapati 
+---
+ lib/content_encoding.c  |   7 +-
+ lib/urldata.h   |   1 +
+ tests/data/Makefile.inc |   2 +-
+ tests/data/test418  | 152 
+ 4 files changed, 157 insertions(+), 5 deletions(-)
+ create mode 100644 tests/data/test418
+
+diff --git a/lib/content_encoding.c b/lib/content_encoding.c
+index 91e621f..7e098a5 100644
+--- a/lib/content_encoding.c
 b/lib/content_encoding.c
+@@ -944,7 +944,6 @@ CURLcode Curl_build_unencoding_stack(struct connectdata 
*conn,
+ {
+   struct Curl_easy *data = conn->data;
+   struct SingleRequest *k = &data->req;
+-  int counter = 0;
+ 
+   do {
+ const char *name;
+@@ -979,9 +978,9 @@ CURLcode Curl_build_unencoding_stack(struct connectdata 
*conn,
+   if(!encoding)
+ encoding = &error_encoding;  /* Defer error at stack use. */
+ 
+-  if(++counter >= MAX_ENCODE_STACK) {
+-failf(data, "Reject response due to %u content encodings",
+-  counter);
++  if(k->writer_stack_depth++ >= MAX_ENCODE_STACK) {
++failf(data, "Reject response due to more than %u content encodings",
++  MAX_ENCODE_STACK);
+ return CURLE_BAD_CONTENT_ENCODING;
+   }
+   /* Stack the unencoding stage. */
+diff --git a/lib/urldata.h b/lib/urldata.h
+index ad0ef8f..168f874 100644
+--- a/lib/urldata.h
 b/lib/urldata.h
+@@ -648,6 +648,7 @@ struct SingleRequest {
+ #ifndef CURL_DISABLE_DOH
+   struct dohdata doh; /* DoH specific data for this request */
+ #endif
++  unsigned char writer_stack_depth; /* Unencoding stack depth. */
+   BIT(header);   /* incoming data has HTTP header */
+   BIT(content_range); /* set TRUE if Content-Range: was found */
+   BIT(upload_done);  /* set to TRUE when doing chunked transfer-encoding
+diff --git a/tests/data/Makefile.inc b/tests/data/Makefile.inc
+index 60e8176..40de8bc 100644
+--- a/tests/data/Makefile.inc
 b/tests/data/Makefile.inc
+@@ -63,7 +63,7 @@ test350 test351 test352 test353 test354 test355 test356 
test357 \
+ test393 test394 test395 \
+ \
+ test400 test401 test402 test403 test404 test405 test406 test407 test408 \
+-test409 \
++test409 test418 \
+ \
+ test490 test491 test492 \
+ \
+diff --git a/tests/data/test418 b/tests/data/test418
+new file mode 100644
+index 000..50e974e
+--- /dev/null
 b/tests/data/test418
+@@ -0,0 +1,152 @@
++
++
++
++HTTP
++gzip
++
++
++
++#
++# Server-side
++
++
++HTTP/1.1 200 OK
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Encoding: gzip
++Transfer-Enco

Re: [oe-core][PATCHv3] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

v3 adds fixes that have been sent recently by kai.k...@eng.windriver.com

- reinsert a patch that I had hastily removed
- fix build for gstreamer-transcoder
- fix an issue with finding libgcryt

Am 28.03.23 um 06:37 schrieb Markus Volk:

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
   ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
   there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
   while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
   recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
   6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
   variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update
- add fixes that have been sent by kai.k...@eng.windriver.com

Signed-off-by: Markus Volk 
---
  meta/conf/distro/include/maintainers.inc  |   1 +
  ...spection.cmake-prefix-variables-obta.patch |   0
  ...ibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch |  34 
  ...44e17d258106617b0e6d783d073b188a2548.patch |  32 +++-
  .../reproducibility.patch |   0
  .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 172 ++
  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ---
  ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  71 
  ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
  9 files changed, 267 insertions(+), 75 deletions(-)
  rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
  create mode 100644 
meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
  rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0d3344e17d258106617b0e6d783d073b188a2548.patch (87%)
  rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
  create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
  rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(74%)
  rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
  RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
  RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git 
a/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
new file mode 100644
index 00..dc56bbb92c
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/11913]
+
+Signed-off-by: Kai Kang 
+
+From de30f1a1caf81902d254e046e382f9cf9cd62c58 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Fri, 24 Mar 2023 17:58:29 +0800
+Subject: [PATCH] FindLibGcrypt.cmake: check PC_GCRYPT_FOUND
+
+After `pkg_check_modules(PC_GCRYPT QUIET libgcrypt)` in
+FindLibGcrypt.cmake, PC_GCRYPT_FOUND will be set but PC_GCRYPT is kept
+empty. So check PC_GCRYPT_FOUND instead.
+
+Signed-off-by: Kai Kang 
+---
+ Source/cmake/FindLibGcrypt.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Source/cmake/FindLibGcrypt.cmake 
b/Source/cmake/FindLibGcrypt.cmake
+index 8bee72963902..2e84cfc4e9b1 100644
+--- a/Source/cmak

[oe-core][PATCHv3] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
  ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
  there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
  while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
  recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
  6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
  variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update
- add fixes that have been sent by kai.k...@eng.windriver.com

Signed-off-by: Markus Volk 
---
 meta/conf/distro/include/maintainers.inc  |   1 +
 ...spection.cmake-prefix-variables-obta.patch |   0
 ...ibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch |  34 
 ...44e17d258106617b0e6d783d073b188a2548.patch |  32 +++-
 .../reproducibility.patch |   0
 .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 172 ++
 ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 ---
 ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  71 
 ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
 9 files changed, 267 insertions(+), 75 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
 create mode 100644 
meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0d3344e17d258106617b0e6d783d073b188a2548.patch (87%)
 rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
 create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
 delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
 rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(74%)
 rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
 RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
 RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git 
a/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
new file mode 100644
index 00..dc56bbb92c
--- /dev/null
+++ 
b/meta/recipes-sato/webkit/files/0001-FindLibGcrypt.cmake-check-PC_GCRYPT_FOUND.patch
@@ -0,0 +1,34 @@
+Upstream-Status: Submitted [https://github.com/WebKit/WebKit/pull/11913]
+
+Signed-off-by: Kai Kang 
+
+From de30f1a1caf81902d254e046e382f9cf9cd62c58 Mon Sep 17 00:00:00 2001
+From: Kai Kang 
+Date: Fri, 24 Mar 2023 17:58:29 +0800
+Subject: [PATCH] FindLibGcrypt.cmake: check PC_GCRYPT_FOUND
+
+After `pkg_check_modules(PC_GCRYPT QUIET libgcrypt)` in
+FindLibGcrypt.cmake, PC_GCRYPT_FOUND will be set but PC_GCRYPT is kept
+empty. So check PC_GCRYPT_FOUND instead.
+
+Signed-off-by: Kai Kang 
+---
+ Source/cmake/FindLibGcrypt.cmake | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Source/cmake/FindLibGcrypt.cmake 
b/Source/cmake/FindLibGcrypt.cmake
+index 8bee72963902..2e84cfc4e9b1 100644
+--- a/Source/cmake/FindLibGcrypt.cmake
 b/Source/cmake/FindLibGcrypt.cmake
+@@ -49,7 +49,7 @@ if (PkgConfig_FOUND)
+ set(LibGcrypt_VERSION ${PC_GCRYPT_VERSION})
+ endif ()
+ 
+-if (LIBGCRYPTCONFIG_SCRIPT AND NOT PC_GCRYPT)
++if (LIBGCRYPTCONFIG_SCRIPT AND NOT PC_GCRYPT_FOUND)
+

Re: [oe-core][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

added myself as mainainer for webkitgtk-3 to maintainers.inc

Am 28.03.23 um 05:44 schrieb Markus Volk:

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
   ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
   there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
   while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
   recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
   6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
   variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update

Signed-off-by: Markus Volk 
---
  meta/conf/distro/include/maintainers.inc  |   1 +
  ...spection.cmake-prefix-variables-obta.patch |   0
  .../reproducibility.patch |   0
  .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 168 ++
  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 --
  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 --
  ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  67 ++--
  ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
  8 files changed, 202 insertions(+), 362 deletions(-)
  rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
  rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
  create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
  delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
  rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(77%)
  rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
  RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
  RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
  RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git a/meta/recipes-sato/webkit/webkitgtk/reproducibility.patch 
b/meta/recipes-sato/webkit/files/reproducibility.patch
similarity index 100%
rename from meta/recipes-sato/webkit/webkitgtk/reproducibility.patch
rename to meta/recipes-sato/webkit/files/reproducibility.patch
diff --git a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb 
b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
new file mode 100644
index 00..4401b0e527
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
@@ -0,0 +1,168 @@
+SUMMARY = "WebKit web rendering engine for the GTK+ platform"
+HOMEPAGE = "https://www.webkitgtk.org/";
+BUGTRACKER = "https://bugs.webkit.org/";
+
+LICENSE = "BSD-2-Clause & LGPL-2.0-or-later"
+LIC_FILES_CHKSUM = 
"file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d84286dda758da57bd691 \
+
file://Source/WebCore/LICENSE-APPLE;md5=4646f90082c40bcf298c285f8bab0b12 \
+
file://Source/WebCore/LICENSE-LGPL-2;md5=36357ffde2b64ae177b2494445b79d21 \
+
file://Source/WebCore/LICENSE-LGPL-2.1;md5=a778a33ef338abbaf8b8a7c36b6eec80 \
+"
+
+SRC_URI = "https://www.webkitgtk.org/releases/webkitgtk-${PV}.tar.xz \
+   
file://0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch \
+   file://reproducibility.patch \
+   "
+SRC_URI[sha256sum] = 
"a4607ea1bf89669e89b1cb2c63faaec513f93de09b6ae60cc71d6a8aab7ab393"
+
+S = 

[oe-core][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

- added PACKAGECONFIGs for av1 support, gamepad and sandboxing
- cmake tries to find where bwrap and xdg-dbus-proxy are located on target and 
reads the path from
  ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
adding the needed paths manually.
- ccache seems to be working well now. Enable by default. It significantly 
improves buildtime on rebuilds.
- webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
support for both at once.
  there are still some packages that require the gtk3 variant, nameably surf, 
gnome-online-accounts and wxwidgets
  while ephiphany for example has a hard dependency on webkitgtk built with 
gtk4. This is why we need to provide
  recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
api, if built with gtk4 it'll provide the
  6.0 api. The only conflicting file between those two is the WebKitWebDriver 
binary. This was renamed for the gtk3
  variant so both variants can be installed into the same image.
- update dependencies
- wpebackend-fdo: update

Signed-off-by: Markus Volk 
---
 meta/conf/distro/include/maintainers.inc  |   1 +
 ...spection.cmake-prefix-variables-obta.patch |   0
 .../reproducibility.patch |   0
 .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 168 ++
 ...44e17d258106617b0e6d783d073b188a2548.patch | 296 --
 ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 --
 ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  67 ++--
 ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
 8 files changed, 202 insertions(+), 362 deletions(-)
 rename meta/recipes-sato/webkit/{webkitgtk => 
files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
 rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
(100%)
 create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
 delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
 delete mode 100644 
meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
 rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
(77%)
 rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
wpebackend-fdo_1.14.1.bb} (90%)

diff --git a/meta/conf/distro/include/maintainers.inc 
b/meta/conf/distro/include/maintainers.inc
index c76447a25d..1fec9bc6f4 100644
--- a/meta/conf/distro/include/maintainers.inc
+++ b/meta/conf/distro/include/maintainers.inc
@@ -825,6 +825,7 @@ RECIPE_MAINTAINER:pn-wayland = "Denys Dmytriyenko 
"
 RECIPE_MAINTAINER:pn-wayland-protocols = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wayland-utils = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-webkitgtk = "Alexander Kanavin "
+RECIPE_MAINTAINER:pn-webkitgtk-3 = "Markus Volk "
 RECIPE_MAINTAINER:pn-weston = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-weston-init = "Denys Dmytriyenko "
 RECIPE_MAINTAINER:pn-wget = "Yi Zhao "
diff --git 
a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
 
b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
similarity index 100%
rename from 
meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
rename to 
meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
diff --git a/meta/recipes-sato/webkit/webkitgtk/reproducibility.patch 
b/meta/recipes-sato/webkit/files/reproducibility.patch
similarity index 100%
rename from meta/recipes-sato/webkit/webkitgtk/reproducibility.patch
rename to meta/recipes-sato/webkit/files/reproducibility.patch
diff --git a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb 
b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
new file mode 100644
index 00..4401b0e527
--- /dev/null
+++ b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
@@ -0,0 +1,168 @@
+SUMMARY = "WebKit web rendering engine for the GTK+ platform"
+HOMEPAGE = "https://www.webkitgtk.org/";
+BUGTRACKER = "https://bugs.webkit.org/";
+
+LICENSE = "BSD-2-Clause & LGPL-2.0-or-later"
+LIC_FILES_CHKSUM = 
"file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d84286dda758da57bd691 \
+
file://Source/WebCore/LICENSE-APPLE;md5=4646f90082c40bcf298c285f8bab0b12 \
+
file://Source/WebCore/LICENSE-LGPL-2;md5=36357ffde2b64ae177b2494445b79d21 \
+
file://Source/WebCore/LICENSE-LGPL-2.1;md5=a778a33ef338abbaf8b8a7c36b6eec80 \
+"
+
+SRC_URI = "https://www.webkitgtk.org/releases/webkitgtk-${PV}.tar.xz \
+   
file://0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch \
+   file://reproducibility.patch \
+   "
+SRC_URI[sha256sum] = 
"a4607ea1bf89669e89b1cb2c63faaec513f93de09b6ae60cc71d6a8aab7ab393"
+
+S = "${WORKDIR}/webkitgtk-${PV}"
+
+inherit ccache cmake pkgconfig gobject-introspection perlnative features_check 
upstream-version-is-ev

Re: [OE-core][PATCH] maintainers.inc: add debugedit maintainer

[Chen Qi]

Sorry for the late reply. I noticed that you've helped do that. Thanks 😊

Regards,
Qi

-Original Message-
From: Alexandre Belloni  
Sent: Friday, March 24, 2023 3:10 AM
To: Chen, Qi 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH] maintainers.inc: add debugedit maintainer

Please squash this one with your v2 so this is bisectable.

On 23/03/2023 16:35:04+0800, Chen Qi wrote:
> Signed-off-by: Chen Qi 
> ---
>  meta/conf/distro/include/maintainers.inc | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/conf/distro/include/maintainers.inc 
> b/meta/conf/distro/include/maintainers.inc
> index c76447a25d..682ec2cfdf 100644
> --- a/meta/conf/distro/include/maintainers.inc
> +++ b/meta/conf/distro/include/maintainers.inc
> @@ -135,6 +135,7 @@ RECIPE_MAINTAINER:pn-dbus = "Chen Qi 
> "
>  RECIPE_MAINTAINER:pn-dbus-glib = "Chen Qi "
>  RECIPE_MAINTAINER:pn-dbus-wait = "Chen Qi "
>  RECIPE_MAINTAINER:pn-debianutils = "Yi Zhao "
> +RECIPE_MAINTAINER:pn-debugedit = "Chen Qi "
>  RECIPE_MAINTAINER:pn-dejagnu = "Nathan Rossi "
>  RECIPE_MAINTAINER:pn-depmodwrapper-cross = "Unassigned 
> "
>  RECIPE_MAINTAINER:pn-desktop-file-utils = "Alexander Kanavin 
> "
> -- 
> 2.17.1
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179194): 
https://lists.openembedded.org/g/openembedded-core/message/179194
Mute This Topic: https://lists.openembedded.org/mt/97796827/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][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Markus Volk]

As a

Am 27.03.23 um 21:47 schrieb Alexandre Belloni:

The following recipes do not have a maintainer assigned to them. Please add an 
entry to meta/conf/distro/include/maintainers.inc file.


This would require that I automatically register here as a maintainer, 
since everything else would have to be discussed first?
Or should I simply enter the previous maintainer of webkitgtk. But that 
also feels wrong without prior discussion.




Could you run the oe-selftest when submitting?
As addressed by Alexander Kanavin, this would take several hours. Since 
my technical equipment is limited, my build environment is blocked 
during this time. If this is a prerequisite for commits in oe-core, I 
can understand that, because time is always a factor, but I would rather 
stop sending commits to oe-core, simply because the hurdles would be too 
high for me.

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179193): 
https://lists.openembedded.org/g/openembedded-core/message/179193
Mute This Topic: https://lists.openembedded.org/mt/97865034/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/7] epiphany: update 43.1 -> 44.0

[Markus Volk]

libadwaita is a hard dependency for epiphany so it would be needed to 
import it from meta-gnome or to move  epiphany to meta-gnome


https://gitlab.gnome.org/GNOME/epiphany/-/blob/44.0/meson.build#L78


Am 27.03.23 um 16:38 schrieb Alexandre Belloni:

ERROR: Nothing PROVIDES 'libadwaita' (but 
/home/pokybuild/yocto-worker/reproducible/build/meta/recipes-gnome/epiphany/epiphany_44.0.bb
 DEPENDS on or otherwise requires it). Close matches:
   libedit

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

[OE-core] Current high bug count owners for Yocto Project 4.2

[Stephen Jolley]

All,

 

Below is the list as of top 37 bug owners as of the end of WW12 of who have
open medium or higher bugs and enhancements against YP 4.2.   There are 148
possible work days left until the final release candidates for YP 4.2 needs
to be released.


Who

Count


ross.bur...@arm.com

34


michael.opdenac...@bootlin.com

33


randy.macl...@windriver.com

28


david.re...@windriver.com

25


richard.pur...@linuxfoundation.org

24


bruce.ashfi...@gmail.com

21


jpewhac...@gmail.com

12


pa...@zhukoff.net

9


sakib.sa...@windriver.com

6


tim.orl...@konsulko.com

4


pi...@toganlabs.com

4


sundeep.kokko...@windriver.com

3


yash.shi...@windriver.com

3


sundeep.kokko...@gmail.com

3


alexis.loth...@bootlin.com

2


rybczyn...@gmail.com

2


p.lob...@welotec.com

2


jon.ma...@arm.com

2


yoann.con...@smile.fr

2


wen.yan@intel.com

1


geoffrey.g...@smile.fr

1


alexandre.bell...@bootlin.com

1


hongxu@windriver.com

1


fathi.bou...@linaro.org

1


martin.ja...@gmail.com

1


geissona...@yahoo.com

1


st...@sakoman.com

1


jens.ge...@desy.de

1


yashinde...@gmail.com

1


fawzi.kha...@smile.fr

1


mathew.pro...@gmail.com

1


romuald.jea...@st.com

1


mark.asselst...@windriver.com

1


frank.wo...@smile.fr

1


thomas.per...@bootlin.com

1


tvgamb...@gmail.com

1


louis.ran...@syslinbit.com

1


Grand Total

237

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


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

[OE-core] Yocto Project Newcomer & Unassigned Bugs - Help Needed

[Stephen Jolley]

All,

 

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

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

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

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

 

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

 

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

 

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

 

Thanks,

 

Stephen K. Jolley

Yocto Project Program Manager

*Cell:(208) 244-4460

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

 


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179190): 
https://lists.openembedded.org/g/openembedded-core/message/179190
Mute This Topic: https://lists.openembedded.org/mt/97895863/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] webkitgtk: Disable wasm on rv32/rv64

[Khem Raj]

It does not build

Signed-off-by: Khem Raj 
---
 .../webkit/files/disable_wasm_riscv64.patch   | 24 +++
 .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb |  7 +++---
 meta/recipes-sato/webkit/webkitgtk_2.40.0.bb  |  7 +++---
 3 files changed, 32 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch

diff --git a/meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch 
b/meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch
new file mode 100644
index 00..eac942fddc
--- /dev/null
+++ b/meta/recipes-sato/webkit/files/disable_wasm_riscv64.patch
@@ -0,0 +1,24 @@
+Provide a way to override enabling wasm from CMake
+by setting -DENABLE_WEBASSEMBLY=OFF for RISCV64
+
+Upstream-Status: Submitted [https://bugs.webkit.org/show_bug.cgi?id=254553]
+Signed-off-by: Khem Raj 
+
+--- a/Source/WTF/wtf/PlatformEnable.h
 b/Source/WTF/wtf/PlatformEnable.h
+@@ -613,13 +613,14 @@
+ #endif
+ 
+ #if CPU(RISCV64)
+-#undef ENABLE_WEBASSEMBLY
++#if !defined(ENABLE_WEBASSEMBLY)
+ #define ENABLE_WEBASSEMBLY 1
+ #undef ENABLE_WEBASSEMBLY_B3JIT
+ #define ENABLE_WEBASSEMBLY_B3JIT 0
+ #undef ENABLE_WEBASSEMBLY_BBQJIT
+ #define ENABLE_WEBASSEMBLY_BBQJIT 0
+ #endif
++#endif
+ 
+ #if !defined(ENABLE_C_LOOP)
+ #if ENABLE(JIT) || CPU(X86_64) || CPU(ARM64)
diff --git a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb 
b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
index 4401b0e527..8932bcb562 100644
--- a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
+++ b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d842
 SRC_URI = "https://www.webkitgtk.org/releases/webkitgtk-${PV}.tar.xz \

file://0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch \
file://reproducibility.patch \
+   file://disable_wasm_riscv64.patch \
"
 SRC_URI[sha256sum] = 
"a4607ea1bf89669e89b1cb2c63faaec513f93de09b6ae60cc71d6a8aab7ab393"
 
@@ -113,9 +114,9 @@ EXTRA_OECMAKE:append:armv4 = " -DENABLE_JIT=OFF "
 EXTRA_OECMAKE:append:mipsarch = " -DUSE_LD_GOLD=OFF "
 EXTRA_OECMAKE:append:powerpc = " -DUSE_LD_GOLD=OFF "
 
-# JIT and gold linker does not work on RISCV
-EXTRA_OECMAKE:append:riscv32 = " -DUSE_LD_GOLD=OFF -DENABLE_JIT=OFF"
-EXTRA_OECMAKE:append:riscv64 = " -DUSE_LD_GOLD=OFF -DENABLE_JIT=OFF"
+# JIT and WASM does not work on RISCV
+EXTRA_OECMAKE:append:riscv32 = " -DENABLE_JIT=OFF -DENABLE_WEBASSEMBLY=OFF"
+EXTRA_OECMAKE:append:riscv64 = " -DENABLE_JIT=OFF -DENABLE_WEBASSEMBLY=OFF"
 
 # JIT not supported on MIPS either
 EXTRA_OECMAKE:append:mipsarch = " -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON "
diff --git a/meta/recipes-sato/webkit/webkitgtk_2.40.0.bb 
b/meta/recipes-sato/webkit/webkitgtk_2.40.0.bb
index 84a5981ba0..04f722a913 100644
--- a/meta/recipes-sato/webkit/webkitgtk_2.40.0.bb
+++ b/meta/recipes-sato/webkit/webkitgtk_2.40.0.bb
@@ -12,6 +12,7 @@ LIC_FILES_CHKSUM = 
"file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d842
 SRC_URI = "https://www.webkitgtk.org/releases/${BPN}-${PV}.tar.xz \

file://0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch \
file://reproducibility.patch \
+   file://disable_wasm_riscv64.patch \
"
 SRC_URI[sha256sum] = 
"a4607ea1bf89669e89b1cb2c63faaec513f93de09b6ae60cc71d6a8aab7ab393"
 
@@ -112,9 +113,9 @@ EXTRA_OECMAKE:append:armv4 = " -DENABLE_JIT=OFF "
 EXTRA_OECMAKE:append:mipsarch = " -DUSE_LD_GOLD=OFF "
 EXTRA_OECMAKE:append:powerpc = " -DUSE_LD_GOLD=OFF "
 
-# JIT and gold linker does not work on RISCV
-EXTRA_OECMAKE:append:riscv32 = " -DUSE_LD_GOLD=OFF -DENABLE_JIT=OFF"
-EXTRA_OECMAKE:append:riscv64 = " -DUSE_LD_GOLD=OFF -DENABLE_JIT=OFF"
+# JIT and WASM does not work on RISCV
+EXTRA_OECMAKE:append:riscv32 = " -DENABLE_JIT=OFF -DENABLE_WEBASSEMBLY=OFF"
+EXTRA_OECMAKE:append:riscv64 = " -DENABLE_JIT=OFF -DENABLE_WEBASSEMBLY=OFF"
 
 # JIT not supported on MIPS either
 EXTRA_OECMAKE:append:mipsarch = " -DENABLE_JIT=OFF -DENABLE_C_LOOP=ON "
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179189): 
https://lists.openembedded.org/g/openembedded-core/message/179189
Mute This Topic: https://lists.openembedded.org/mt/97894684/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][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Richard Purdie]

On Mon, 2023-03-27 at 22:08 +0200, Alexander Kanavin wrote:
> I think all of oe-selftest is excessive. It takes many hours.
> oe-selftest -r distrodata is enough.
> 
> What we should do is move the maintainer assignment check into
> package_qa rather.

Assuming we can limit to OE-Core, yes. The other one which trips people
up is the home page check so we should do that at the same time.

Ideally we'd have patchtest back. Failing that, a way to run
patchtest's tests pre-submission would be ideal. The tests were already
in unittest form iirc and would be good to maintain in OE-Core
regardless of patchtest's future anyway.

> And probably split maintainers.inc into respective recipes, come to
> think of it. It'll hopefully draw more attention to how many do not
> have a maintainer.

I think this is probably more obvious all in one file.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179188): 
https://lists.openembedded.org/g/openembedded-core/message/179188
Mute This Topic: https://lists.openembedded.org/mt/97865034/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] [kirkstone][PATCH v2] go: fix CVE-2022-2879 and CVE-2022-41720

[Sakib Sajal]

On 2023-03-22 12:21, Steve Sakoman wrote:

CAUTION: This email comes from a non Wind River email account!
Do not click links or open attachments unless you recognize the sender and know 
the content is safe.

On Tue, Mar 21, 2023 at 9:36 AM Sakib Sajal  wrote:

Backport appropriate patches to fix CVE-2022-2879 and CVE-2022-41720.

Modified the original fix for CVE-2022-2879 to remove a testdata tarball
and any references to it since git binary diffs are not supported in
quilt.

Signed-off-by: Sakib Sajal 
---
  meta/recipes-devtools/go/go-1.17.13.inc   |   2 +
  ...01-archive-tar-limit-size-of-headers.patch | 177 ++
  ...d-escapes-from-os.DirFS-and-http.Dir.patch | 514 ++
  3 files changed, 693 insertions(+)
  create mode 100644 
meta/recipes-devtools/go/go-1.18/0001-archive-tar-limit-size-of-headers.patch
  create mode 100644 
meta/recipes-devtools/go/go-1.18/0002-os-net-http-avoid-escapes-from-os.DirFS-and-http.Dir.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index 99662bd298..a6081bdee7 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -20,6 +20,8 @@ SRC_URI += "\
  file://0001-net-http-httputil-avoid-query-parameter-smuggling.patch \
  file://CVE-2022-41715.patch \
  file://CVE-2022-41717.patch \
+file://0001-archive-tar-limit-size-of-headers.patch \
+file://0002-os-net-http-avoid-escapes-from-os.DirFS-and-http.Dir.patch \

Could you please resubmit with the patch file names changed to reflect
the CVE they are fixing? i.e.

   file://CVE-2022-2879.patch \
   file://CVE-2022-41720.patch \

Thanks!

Steve


Done!

Sakib




  "
  SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"

diff --git 
a/meta/recipes-devtools/go/go-1.18/0001-archive-tar-limit-size-of-headers.patch 
b/meta/recipes-devtools/go/go-1.18/0001-archive-tar-limit-size-of-headers.patch
new file mode 100644
index 00..0315e1a3ee
--- /dev/null
+++ 
b/meta/recipes-devtools/go/go-1.18/0001-archive-tar-limit-size-of-headers.patch
@@ -0,0 +1,177 @@
+From d064ed520a7cc6b480f9565e30751e695d394f4e Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Fri, 2 Sep 2022 20:45:18 -0700
+Subject: [PATCH] archive/tar: limit size of headers
+
+Set a 1MiB limit on special file blocks (PAX headers, GNU long names,
+GNU link names), to avoid reading arbitrarily large amounts of data
+into memory.
+
+Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting
+this issue.
+
+Fixes CVE-2022-2879
+Updates #54853
+Fixes #55925
+
+Change-Id: I85136d6ff1e0af101a112190e027987ab4335680
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/156
+Reviewed-by: Tatiana Bradley 
+Run-TryBot: Roland Shoemaker 
+Reviewed-by: Roland Shoemaker 
+(cherry picked from commit 6ee768cef6b82adf7a90dcf367a1699ef694f3b2)
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1590622
+Reviewed-by: Damien Neil 
+Reviewed-by: Julie Qiu 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/438500
+Reviewed-by: Dmitri Shuralyov 
+Reviewed-by: Carlos Amedee 
+Reviewed-by: Dmitri Shuralyov 
+Run-TryBot: Carlos Amedee 
+TryBot-Result: Gopher Robot 
+
+CVE: CVE-2022-2879
+Upstream-Status: Backport [0a723816cd205576945fa57fbdde7e6532d59d08]
+Signed-off-by: Sakib Sajal 
+---
+ src/archive/tar/format.go  |  4 
+ src/archive/tar/reader.go  | 14 --
+ src/archive/tar/reader_test.go |  8 +++-
+ src/archive/tar/writer.go  |  3 +++
+ src/archive/tar/writer_test.go | 27 +++
+ 5 files changed, 53 insertions(+), 3 deletions(-)
+
+diff --git a/src/archive/tar/format.go b/src/archive/tar/format.go
+index cfe24a5..6642364 100644
+--- a/src/archive/tar/format.go
 b/src/archive/tar/format.go
+@@ -143,6 +143,10 @@ const (
+   blockSize  = 512 // Size of each block in a tar stream
+   nameSize   = 100 // Max length of the name field in USTAR format
+   prefixSize = 155 // Max length of the prefix field in USTAR format
++
++  // Max length of a special file (PAX header, GNU long name or link).
++  // This matches the limit used by libarchive.
++  maxSpecialFileSize = 1 << 20
+ )
+
+ // blockPadding computes the number of bytes needed to pad offset up to the
+diff --git a/src/archive/tar/reader.go b/src/archive/tar/reader.go
+index 1b1d5b4..f645af8 100644
+--- a/src/archive/tar/reader.go
 b/src/archive/tar/reader.go
+@@ -103,7 +103,7 @@ func (tr *Reader) next() (*Header, error) {
+   continue // This is a meta header affecting the next 
header
+   case TypeGNULongName, TypeGNULongLink:
+   format.mayOnlyBe(FormatGNU)
+-  realname, err := io.ReadAll(tr)
++  realname, err := readSpecialFile(tr)
+   if err != nil {
+   return ni

[OE-core] [kirkstone][PATCH v2] go: fix CVE-2022-2879 and CVE-2022-41720

[Sakib Sajal]

Backport appropriate patches to fix CVE-2022-2879 and CVE-2022-41720.

Modified the original fix for CVE-2022-2879 to remove a testdata tarball
and any references to it since git binary diffs are not supported in
quilt.

Signed-off-by: Sakib Sajal 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   2 +
 .../go/go-1.18/CVE-2022-2879.patch| 177 ++
 .../go/go-1.18/CVE-2022-41720.patch   | 514 ++
 3 files changed, 693 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.18/CVE-2022-2879.patch
 create mode 100644 meta/recipes-devtools/go/go-1.18/CVE-2022-41720.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index 99662bd298..856c14de40 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -20,6 +20,8 @@ SRC_URI += "\
 file://0001-net-http-httputil-avoid-query-parameter-smuggling.patch \
 file://CVE-2022-41715.patch \
 file://CVE-2022-41717.patch \
+file://CVE-2022-2879.patch \
+file://CVE-2022-41720.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.18/CVE-2022-2879.patch 
b/meta/recipes-devtools/go/go-1.18/CVE-2022-2879.patch
new file mode 100644
index 00..0315e1a3ee
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.18/CVE-2022-2879.patch
@@ -0,0 +1,177 @@
+From d064ed520a7cc6b480f9565e30751e695d394f4e Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Fri, 2 Sep 2022 20:45:18 -0700
+Subject: [PATCH] archive/tar: limit size of headers
+
+Set a 1MiB limit on special file blocks (PAX headers, GNU long names,
+GNU link names), to avoid reading arbitrarily large amounts of data
+into memory.
+
+Thanks to Adam Korczynski (ADA Logics) and OSS-Fuzz for reporting
+this issue.
+
+Fixes CVE-2022-2879
+Updates #54853
+Fixes #55925
+
+Change-Id: I85136d6ff1e0af101a112190e027987ab4335680
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/156
+Reviewed-by: Tatiana Bradley 
+Run-TryBot: Roland Shoemaker 
+Reviewed-by: Roland Shoemaker 
+(cherry picked from commit 6ee768cef6b82adf7a90dcf367a1699ef694f3b2)
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/1590622
+Reviewed-by: Damien Neil 
+Reviewed-by: Julie Qiu 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/438500
+Reviewed-by: Dmitri Shuralyov 
+Reviewed-by: Carlos Amedee 
+Reviewed-by: Dmitri Shuralyov 
+Run-TryBot: Carlos Amedee 
+TryBot-Result: Gopher Robot 
+
+CVE: CVE-2022-2879
+Upstream-Status: Backport [0a723816cd205576945fa57fbdde7e6532d59d08]
+Signed-off-by: Sakib Sajal 
+---
+ src/archive/tar/format.go  |  4 
+ src/archive/tar/reader.go  | 14 --
+ src/archive/tar/reader_test.go |  8 +++-
+ src/archive/tar/writer.go  |  3 +++
+ src/archive/tar/writer_test.go | 27 +++
+ 5 files changed, 53 insertions(+), 3 deletions(-)
+
+diff --git a/src/archive/tar/format.go b/src/archive/tar/format.go
+index cfe24a5..6642364 100644
+--- a/src/archive/tar/format.go
 b/src/archive/tar/format.go
+@@ -143,6 +143,10 @@ const (
+   blockSize  = 512 // Size of each block in a tar stream
+   nameSize   = 100 // Max length of the name field in USTAR format
+   prefixSize = 155 // Max length of the prefix field in USTAR format
++
++  // Max length of a special file (PAX header, GNU long name or link).
++  // This matches the limit used by libarchive.
++  maxSpecialFileSize = 1 << 20
+ )
+ 
+ // blockPadding computes the number of bytes needed to pad offset up to the
+diff --git a/src/archive/tar/reader.go b/src/archive/tar/reader.go
+index 1b1d5b4..f645af8 100644
+--- a/src/archive/tar/reader.go
 b/src/archive/tar/reader.go
+@@ -103,7 +103,7 @@ func (tr *Reader) next() (*Header, error) {
+   continue // This is a meta header affecting the next 
header
+   case TypeGNULongName, TypeGNULongLink:
+   format.mayOnlyBe(FormatGNU)
+-  realname, err := io.ReadAll(tr)
++  realname, err := readSpecialFile(tr)
+   if err != nil {
+   return nil, err
+   }
+@@ -293,7 +293,7 @@ func mergePAX(hdr *Header, paxHdrs map[string]string) (err 
error) {
+ // parsePAX parses PAX headers.
+ // If an extended header (type 'x') is invalid, ErrHeader is returned
+ func parsePAX(r io.Reader) (map[string]string, error) {
+-  buf, err := io.ReadAll(r)
++  buf, err := readSpecialFile(r)
+   if err != nil {
+   return nil, err
+   }
+@@ -826,6 +826,16 @@ func tryReadFull(r io.Reader, b []byte) (n int, err 
error) {
+   return n, err
+ }
+ 
++// readSpecialFile is like io.ReadAll except it returns
++// ErrFieldTooLong if more than maxSpecialFileSize is read.
++func readSpecialFile(r io.Reader) ([]b

Re: [OE-core] [PATCH 0/5] Extend cargo based recip support

[Alexander Kanavin]

I think I have meanwhile resolved the 1.68 upgrade issues:
https://git.yoctoproject.org/poky-contrib/log/?h=akanavin/package-version-updates

So that leaves the hip and cool rust-in-kernel project ;-)

Alex

On Mon, 27 Mar 2023 at 21:20, Frédéric Martinsons
 wrote:
>
> Thank you alex and alexender ;)
>
> I'll take a look at this as soon as possible and and tell you in a dedicated 
> thread if I'm making progress. But first, I'll work for the devtool test that 
> has been mentioned first.
>
> Have a good evening (or day, depending on your timezone)
>
> Le lun. 27 mars 2023, 21:00, Alexander Kanavin  a 
> écrit :
>>
>> For the kernel modules you could start by replicating an out-of-yocto
>> kernel build as shown here:
>> https://lwn.net/Articles/910762/
>>
>> Alex
>>
>> On Mon, 27 Mar 2023 at 20:52, Alex Kiernan  wrote:
>> >
>> > IIRC the cross upgrade just works, its the target build which explodes:
>> >
>> > https://github.com/akiernan/openembedded-core
>> >
>> > On Mon, Mar 27, 2023 at 7:40 PM Frédéric Martinsons
>> >  wrote:
>> > >
>> > > Ok great, I'm willing to know more about the bootstrap of a rust 
>> > > toolchain, I think I can start by just upgrading my poky master to rust 
>> > > 1.68 and see what it spills out when I compile the hello world
>> > >
>> > > On the other hand, for enabling rust kernel modules in linux-yocto-dev, 
>> > > I don't know where to start (full disclosure : I have no skills about 
>> > > kernel and kernel module developments)
>> > >
>> > > Le lun. 27 mars 2023, 20:30, Alex Kiernan  a 
>> > > écrit :
>> > >>
>> > >> Updating the rust version is pretty much nothing to do with your rust
>> > >> knowledge and way more about digging into how the bootstrap process
>> > >> hangs together... whilst I have an awesome rustacean working for me, I
>> > >> don't think I've ever had to drag him into helping with an upgrade.
>> > >>
>> > >> I wish I could say I'd spent the last few weeks figuring out why the
>> > >> upgrade broke, but I've been buried down the bottom of an ESP-IDF
>> > >> application...
>> > >>
>> > >> Alex
>> > >>
>> > >> On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
>> > >>  wrote:
>> > >> >
>> > >> > I'll look at this but I'm not sure if I can help since I'm a beginner 
>> > >> > (enthusiastic but still)
>> > >> >
>> > >> > Le lun. 27 mars 2023, 19:19, Alexander Kanavin 
>> > >> >  a écrit :
>> > >> >>
>> > >> >> If you'd like to do more here's off the top of my head:
>> > >> >>
>> > >> >> - enable rust kernel modules in linux-yocto-dev
>> > >> >>
>> > >> >> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
>> > >> >> as possible capable of updating the rust toolchain. It's often not
>> > >> >> trivial:
>> > >> >> https://lists.openembedded.org/g/openembedded-core/message/178272
>> > >> >>
>> > >> >> Alex
>> > >> >>
>> > >> >> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
>> > >> >>  wrote:
>> > >> >> >
>> > >> >> > Ah!
>> > >> >> >
>> > >> >> > Alright, I'll try to setup a devtool test which demonstrate the 
>> > >> >> > usage of git subpath with the zvariant.
>> > >> >> > I'll then issue a V4 series which reintroduce the zvariant recipe 
>> > >> >> > in meta-selftest and the unit test on it.
>> > >> >> >
>> > >> >> > I must admit I felt in love for rust since the beginning of the 
>> > >> >> > year and considering that I use yocto on a daily basis, I'll do 
>> > >> >> > everything I can to extend the support of developing rust for 
>> > >> >> > embedded devices.
>> > >> >> >
>> > >> >> > Thank you all for the advices.
>> > >> >> >
>> > >> >> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin 
>> > >> >> >  a écrit :
>> > >> >> >>
>> > >> >> >> So if devtool tests would operate on zvariant recipe, then the 
>> > >> >> >> recipe
>> > >> >> >> can simply go into meta-selftest after all :)
>> > >> >> >>
>> > >> >> >> Alex
>> > >> >> >>
>> > >> >> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
>> > >> >> >>  wrote:
>> > >> >> >> >
>> > >> >> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
>> > >> >> >> > > From: Frederic Martinsons 
>> > >> >> >> > >
>> > >> >> >> > > This series brings the support of local git repository inside
>> > >> >> >> > > a cargo based recipe.
>> > >> >> >> > >
>> > >> >> >> > > It also enable devtool capacity on it and provide a real crate
>> > >> >> >> > > example recipe to show how things are done.
>> > >> >> >> > >
>> > >> >> >> > > The following changes since commit 
>> > >> >> >> > > 4876189dd2ae5a04a296b11b537b9f613159c6bf:
>> > >> >> >> > >
>> > >> >> >> > >   xcb-proto: Fix install conflict when enable multilib. 
>> > >> >> >> > > (2023-03-23 22:38:41 +)
>> > >> >> >> > >
>> > >> >> >> > > are available in the Git repository at:
>> > >> >> >> > >
>> > >> >> >> > >   https://gitlab.com/fmartinsons/openembedded-core 
>> > >> >> >> > > cargo-extend-support-git-and-devtool
>> > >> >> >> > >
>> > >> >> >> > > Alex Kiernan (1):
>> > >> >> >> > >   cargo_common.bbclass: Support local github rep

Re: [OE-core] [PATCH v2 2/2] oeqa/selftest/cases/package.py: adding unittest for package rename conflicts

[Yoann Congal]

Hi Fawzi and list,

While looking at master-next, I found some mistakes in this series.
@maintainers, maybe wait for the v3 before merging into master?

Sorry for this, my internal review was not thorough enough :(

@Fawzi, please see the inline comments :
On 3/23/23 10:56, Fawzi KHABER wrote:
> This Unittest tries to rename a package, using an already used name and
> fails on do_package.
> 
> Reviewed-by: Yoann CONGAL 
> Signed-off-by: Fawzi KHABER 
> ---
>  .../packagenameconflict/packagenameconflict.bb | 10 ++
>  meta/classes-global/package.bbclass|  3 +--
>  meta/lib/oeqa/selftest/cases/package.py|  7 +++
>  3 files changed, 18 insertions(+), 2 deletions(-)
>  create mode 100644 
> meta-selftest/recipes-test/packagenameconflict/packagenameconflict.bb
> 
> diff --git 
> a/meta-selftest/recipes-test/packagenameconflict/packagenameconflict.bb 
> b/meta-selftest/recipes-test/packagenameconflict/packagenameconflict.bb
> new file mode 100644
> index 00..5d19a4dd25
> --- /dev/null
> +++ b/meta-selftest/recipes-test/packagenameconflict/packagenameconflict.bb
> @@ -0,0 +1,10 @@
> +SUMMARY = "Test case that tries to rename a package to an existing one and 
> fails"
> +DESCRIPTION = "This generates a packaging error when a package is renamed to 
> a pre-existing name"
> +LICENSE = "MIT"
> +
> +# Add a new package ${PN}-renametest
> +PACKAGES += "${PN}-renametest"
> +# ... and try to rename the ${PN}-dev to the new ${PN}-renametest (conflict)
> +PKG:${PN}-dev = "${PN}-renametest"
> +
> +EXCLUDE_FROM_WORLD = "1"
> diff --git a/meta/classes-global/package.bbclass 
> b/meta/classes-global/package.bbclass
> index 30dfd63d4f..21461ff314 100644
> --- a/meta/classes-global/package.bbclass
> +++ b/meta/classes-global/package.bbclass
> @@ -498,13 +498,12 @@ python do_package () {
>  
>  # Check for conflict between renamed packages and existing ones
>  # for each package in PACKAGES, check if it will be renamed to an 
> existing one
> -
This line ...
>  for p in packages:
>  localdata = bb.data.createCopy(d)
>  localdata.setVar('OVERRIDES', p)
>  rename = localdata.getVar('PKG')
>  if (rename != None) and rename in packages: 
> -bb.fatal('package %s is renamed %s using PKG:%s, but package 
> name already exists'%(p,rename,p))
> +bb.fatal('package "%s" is renamed to "%s" using PKG:%s, but 
> package name already exists'%(p,rename,p))
... and this line should be squashed with the patch 1/2 instead of the 2/2 of 
your series.

>
>  
> ###
>  # Optimisations
> diff --git a/meta/lib/oeqa/selftest/cases/package.py 
> b/meta/lib/oeqa/selftest/cases/package.py
> index 4f7cd10658..1aa6c03f8a 100644
> --- a/meta/lib/oeqa/selftest/cases/package.py
> +++ b/meta/lib/oeqa/selftest/cases/package.py
> @@ -89,6 +89,13 @@ class VersionOrdering(OESelftestTestCase):
>  self.assertEqual(status - 100, sort, "%s %s (%d) failed" % 
> (ver1, ver2, sort))
>  
>  class PackageTests(OESelftestTestCase):
> +# Verify that a recipe cannot rename a package into an existing one
> +def test_package_name_conflict(self):
> +res = bitbake("packagenameconflict", ignore_status=True)
> +self.assertNotEqual(res.status, 0)
> +err = "package name already exists"
> +self.assertTrue(err in res.output)
> +
>  # Verify that a recipe which sets up hardlink files has those preserved 
> into split packages
>  # Also test file sparseness is preserved
>  def test_preserve_sparse_hardlinks(self):

Regards,
-- 
Yoann Congal
Smile ECS - Tech Expert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179184): 
https://lists.openembedded.org/g/openembedded-core/message/179184
Mute This Topic: https://lists.openembedded.org/mt/97797542/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/2] package.bbclass: check packages name conflict in do_package

[Yoann Congal]

Hi Fawzi,

On 3/23/23 10:56, Fawzi KHABER wrote:
> It is possible to rename packages with the macro PKG:${PN} and result in
> a package name conflict if the target name exists already.
> 
> Add a fatal check to prevent this issue to go unnoticed.
> 
> Fix [Yocto #12060]
> 
> Reviewed-by: Yoann CONGAL 
> Signed-off-by: Fawzi KHABER 
> ---
>  meta/classes-global/package.bbclass | 10 ++
>  1 file changed, 10 insertions(+)
> 
> diff --git a/meta/classes-global/package.bbclass 
> b/meta/classes-global/package.bbclass
> index 7e96601cd9..30dfd63d4f 100644
> --- a/meta/classes-global/package.bbclass
> +++ b/meta/classes-global/package.bbclass
> @@ -496,6 +496,16 @@ python do_package () {
>  
>  bb.build.exec_func("package_convert_pr_autoinc", d)
>  
> +# Check for conflict between renamed packages and existing ones
> +# for each package in PACKAGES, check if it will be renamed to an 
> existing one
> +
> +for p in packages:
> +localdata = bb.data.createCopy(d)
> +localdata.setVar('OVERRIDES', p)
> +rename = localdata.getVar('PKG')
> +if (rename != None) and rename in packages: 
This line adds a bunch of whitespaces at the end of the line.

> +bb.fatal('package %s is renamed %s using PKG:%s, but package 
> name already exists'%(p,rename,p))
> +
>  
> ###
>  # Optimisations
>  
> ###

-- 
Yoann Congal
Smile ECS - Tech Expert

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179183): 
https://lists.openembedded.org/g/openembedded-core/message/179183
Mute This Topic: https://lists.openembedded.org/mt/97797541/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][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Alexander Kanavin]

I think all of oe-selftest is excessive. It takes many hours.
oe-selftest -r distrodata is enough.

What we should do is move the maintainer assignment check into
package_qa rather.

And probably split maintainers.inc into respective recipes, come to
think of it. It'll hopefully draw more attention to how many do not
have a maintainer.

Alex

On Mon, 27 Mar 2023 at 21:47, Alexandre Belloni via
lists.openembedded.org
 wrote:
>
> Hello,
>
> Please adjust maintainers.inc:
>
> The following recipes do not have a maintainer assigned to them. Please add 
> an entry to meta/conf/distro/include/maintainers.inc file.
>
> Could you run the oe-selftest when submitting?
>
> Thanks!
>
> On 26/03/2023 18:45:57+0200, Markus Volk wrote:
> > - added PACKAGECONFIGs for av1 support, gamepad and sandboxing
> > - cmake tries to find where bwrap and xdg-dbus-proxy are located on target 
> > and reads the path from
> >   ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
> > adding the needed paths manually.
> > - ccache seems to be working well now. Enable by default. It significantly 
> > improves buildtime on rebuilds.
> > - webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built 
> > with support for both at once.
> >   there are still some packages that require the gtk3 variant, nameably 
> > surf, gnome-online-accounts and wxwidgets
> >   while ephiphany for example has a hard dependency on webkitgtk built with 
> > gtk4. This is why we need to provide
> >   recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
> > api, if built with gtk4 it'll provide the
> >   6.0 api. The only conflicting file between those two is the 
> > WebKitWebDriver binary. This was renamed for the gtk3
> >   variant so both variants can be installed into the same image.
> > - update dependencies
> > - wpebackend-fdo: update
> >
> > Signed-off-by: Markus Volk 
> > ---
> >  ...spection.cmake-prefix-variables-obta.patch |   0
> >  .../reproducibility.patch |   0
> >  .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 168 ++
> >  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 --
> >  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 --
> >  ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  67 ++--
> >  ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
> >  7 files changed, 201 insertions(+), 362 deletions(-)
> >  rename meta/recipes-sato/webkit/{webkitgtk => 
> > files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch 
> > (100%)
> >  rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
> > (100%)
> >  create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
> >  delete mode 100644 
> > meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
> >  delete mode 100644 
> > meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
> >  rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => 
> > webkitgtk_2.40.0.bb} (77%)
> >  rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
> > wpebackend-fdo_1.14.1.bb} (90%)
> >
> > diff --git 
> > a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> >  
> > b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> > similarity index 100%
> > rename from 
> > meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> > rename to 
> > meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> > diff --git a/meta/recipes-sato/webkit/webkitgtk/reproducibility.patch 
> > b/meta/recipes-sato/webkit/files/reproducibility.patch
> > similarity index 100%
> > rename from meta/recipes-sato/webkit/webkitgtk/reproducibility.patch
> > rename to meta/recipes-sato/webkit/files/reproducibility.patch
> > diff --git a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb 
> > b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
> > new file mode 100644
> > index 00..4401b0e527
> > --- /dev/null
> > +++ b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
> > @@ -0,0 +1,168 @@
> > +SUMMARY = "WebKit web rendering engine for the GTK+ platform"
> > +HOMEPAGE = "https://www.webkitgtk.org/";
> > +BUGTRACKER = "https://bugs.webkit.org/";
> > +
> > +LICENSE = "BSD-2-Clause & LGPL-2.0-or-later"
> > +LIC_FILES_CHKSUM = 
> > "file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d84286dda758da57bd691
> >  \
> > +
> > file://Source/WebCore/LICENSE-APPLE;md5=4646f90082c40bcf298c285f8bab0b12 \
> > +
> > file://Source/WebCore/LICENSE-LGPL-2;md5=36357ffde2b64ae177b2494445b79d21 \
> > +
> > file://Source/WebCore/LICENSE-LGPL-2.1;md5=a778a33ef338abbaf8b8a7c36b6eec80 
> > \
> > +"
> > +
> > +SRC_URI = "https://www.webkitgtk.org/releases/webkitgtk-${PV}.tar.xz \
> > +   
> > file://0001-Fi

[OE-core][dunfell][PATCH v2 5/5] classes/package: Use gzip for extended package data

[Joshua Watt]

The master version of extended package data uses zstd for efficient
compression, but it relies on the zstd tool to be present on the host
system. Since dunfell supports older distros, we don't want to add this
tool as an additional requirement so switch to using gzip instead.

Signed-off-by: Joshua Watt 
---
 meta/classes/package.bbclass | 7 +++
 meta/lib/oe/packagedata.py   | 7 +++
 2 files changed, 6 insertions(+), 8 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 84fdafa8fe..49d30caef7 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1470,7 +1470,7 @@ PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE 
DESCRIPTION SUMMARY RDEPENDS
 python emit_pkgdata() {
 from glob import glob
 import json
-import bb.compress.zstd
+import gzip
 
 def process_postinst_on_target(pkg, mlprefix):
 pkgval = d.getVar('PKG_%s' % pkg)
@@ -1610,9 +1610,8 @@ fi
 
 sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
 
-subdata_extended_file = pkgdatadir + "/extended/%s.json.zstd" % pkg
-num_threads = int(d.getVar("BB_NUMBER_THREADS"))
-with bb.compress.zstd.open(subdata_extended_file, "wt", 
encoding="utf-8", num_threads=num_threads) as f:
+subdata_extended_file = pkgdatadir + "/extended/%s.json.gz" % pkg
+with gzip.open(subdata_extended_file, "wt", encoding="utf-8") as f:
 json.dump(extended_data, f, sort_keys=True, separators=(",", ":"))
 
 # Symlinks needed for rprovides lookup
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index 00f7dc1f3d..feb834c0e3 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -59,12 +59,11 @@ def read_subpkgdata_dict(pkg, d):
 
 def read_subpkgdata_extended(pkg, d):
 import json
-import bb.compress.zstd
+import gzip
 
-fn = d.expand("${PKGDATA_DIR}/extended/%s.json.zstd" % pkg)
+fn = d.expand("${PKGDATA_DIR}/extended/%s.json.gz" % pkg)
 try:
-num_threads = int(d.getVar("BB_NUMBER_THREADS"))
-with bb.compress.zstd.open(fn, "rt", encoding="utf-8", 
num_threads=num_threads) as f:
+with gzip.open(fn, "rt", encoding="utf-8") as f:
 return json.load(f)
 except FileNotFoundError:
 return None
-- 
2.33.0


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

[OE-core][dunfell][PATCH v2 4/5] create-spdx: Use gzip for compression

[Joshua Watt]

The master version of the SPDX classes uses zstd for efficient
compression, but it relies on the zstd tool to be present on the host
system. Since dunfell supports older distros, we don't want to add this
tool as an additional requirement so switch to using gzip instead.

Signed-off-by: Joshua Watt 
---
 meta/classes/create-spdx-2.2.bbclass | 20 +---
 1 file changed, 9 insertions(+), 11 deletions(-)

diff --git a/meta/classes/create-spdx-2.2.bbclass 
b/meta/classes/create-spdx-2.2.bbclass
index 13d13fe1fc..42b693d586 100644
--- a/meta/classes/create-spdx-2.2.bbclass
+++ b/meta/classes/create-spdx-2.2.bbclass
@@ -466,13 +466,11 @@ python do_create_spdx() {
 @contextmanager
 def optional_tarfile(name, guard, mode="w"):
 import tarfile
-import bb.compress.zstd
-
-num_threads = int(d.getVar("BB_NUMBER_THREADS"))
+import gzip
 
 if guard:
 name.parent.mkdir(parents=True, exist_ok=True)
-with bb.compress.zstd.open(name, mode=mode + "b", 
num_threads=num_threads) as f:
+with gzip.open(name, mode=mode + "b") as f:
 with tarfile.open(fileobj=f, mode=mode + "|") as tf:
 yield tf
 else:
@@ -550,7 +548,7 @@ python do_create_spdx() {
 add_download_packages(d, doc, recipe)
 
 if process_sources(d) and include_sources:
-recipe_archive = deploy_dir_spdx / "recipes" / (doc.name + ".tar.zst")
+recipe_archive = deploy_dir_spdx / "recipes" / (doc.name + ".tar.gz")
 with optional_tarfile(recipe_archive, archive_sources) as archive:
 spdx_get_src(d)
 
@@ -618,7 +616,7 @@ python do_create_spdx() {
 package_doc.add_relationship(spdx_package, "GENERATED_FROM", 
"%s:%s" % (recipe_ref.externalDocumentId, recipe.SPDXID))
 package_doc.add_relationship(package_doc, "DESCRIBES", 
spdx_package)
 
-package_archive = deploy_dir_spdx / "packages" / (package_doc.name 
+ ".tar.zst")
+package_archive = deploy_dir_spdx / "packages" / (package_doc.name 
+ ".tar.gz")
 with optional_tarfile(package_archive, archive_packaged) as 
archive:
 package_files = add_package_files(
 d,
@@ -899,8 +897,8 @@ python image_combine_spdx() {
 if link != target_path:
 link.symlink_to(os.path.relpath(target_path, link.parent))
 
-spdx_tar_path = imgdeploydir / (image_name + ".spdx.tar.zst")
-make_image_link(spdx_tar_path, ".spdx.tar.zst")
+spdx_tar_path = imgdeploydir / (image_name + ".spdx.tar.gz")
+make_image_link(spdx_tar_path, ".spdx.tar.gz")
 }
 
 python sdk_host_combine_spdx() {
@@ -931,7 +929,7 @@ def combine_spdx(d, rootfs_name, rootfs_deploydir, 
rootfs_spdxid, packages, spdx
 from datetime import timezone, datetime
 from pathlib import Path
 import tarfile
-import bb.compress.zstd
+import gzip
 
 creation_time = 
datetime.now(tz=timezone.utc).strftime("%Y-%m-%dT%H:%M:%SZ")
 deploy_dir_spdx = Path(d.getVar("DEPLOY_DIR_SPDX"))
@@ -1002,8 +1000,8 @@ def combine_spdx(d, rootfs_name, rootfs_deploydir, 
rootfs_spdxid, packages, spdx
 
 index = {"documents": []}
 
-spdx_tar_path = rootfs_deploydir / (rootfs_name + ".spdx.tar.zst")
-with bb.compress.zstd.open(spdx_tar_path, "w", num_threads=num_threads) as 
f:
+spdx_tar_path = rootfs_deploydir / (rootfs_name + ".spdx.tar.gz")
+with gzip.open(spdx_tar_path, "w") as f:
 with tarfile.open(fileobj=f, mode="w|") as tar:
 def collect_spdx_document(path):
 nonlocal tar
-- 
2.33.0


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

[OE-core][dunfell][PATCH v2 3/5] licenses: Add GPL+ licenses to map

[Joshua Watt]

Adds some missing licenses mappings related to the "+" versions of the
GPL licenses

Signed-off-by: Joshua Watt 
---
 meta/conf/licenses.conf | 7 +++
 1 file changed, 7 insertions(+)

diff --git a/meta/conf/licenses.conf b/meta/conf/licenses.conf
index 0149b1dc44..d14c365977 100644
--- a/meta/conf/licenses.conf
+++ b/meta/conf/licenses.conf
@@ -22,21 +22,28 @@ SPDXLICENSEMAP[GPLv1.0] = "GPL-1.0"
 SPDXLICENSEMAP[GPL-1.0-only] = "GPL-1.0"
 SPDXLICENSEMAP[GPL-2] = "GPL-2.0"
 SPDXLICENSEMAP[GPLv2] = "GPL-2.0"
+SPDXLICENSEMAP[GPLv2+] = "GPL-2.0+"
 SPDXLICENSEMAP[GPLv2.0] = "GPL-2.0"
+SPDXLICENSEMAP[GPLv2.0+] = "GPL-2.0+"
 SPDXLICENSEMAP[GPL-2.0-only] = "GPL-2.0"
 SPDXLICENSEMAP[GPL-3] = "GPL-3.0"
 SPDXLICENSEMAP[GPLv3] = "GPL-3.0"
+SPDXLICENSEMAP[GPLv3+] = "GPL-3.0+"
 SPDXLICENSEMAP[GPLv3.0] = "GPL-3.0"
+SPDXLICENSEMAP[GPLv3.0+] = "GPL-3.0+"
 SPDXLICENSEMAP[GPL-3.0-only] = "GPL-3.0"
 
 #LGPL variations
 SPDXLICENSEMAP[LGPLv2] = "LGPL-2.0"
+SPDXLICENSEMAP[LGPLv2+] = "LGPL-2.0+"
 SPDXLICENSEMAP[LGPLv2.0] = "LGPL-2.0"
 SPDXLICENSEMAP[LGPL-2.0-only] = "LGPL-2.0"
 SPDXLICENSEMAP[LGPL2.1] = "LGPL-2.1"
 SPDXLICENSEMAP[LGPLv2.1] = "LGPL-2.1"
+SPDXLICENSEMAP[LGPLv2.1+] = "LGPL-2.1+"
 SPDXLICENSEMAP[LGPL-2.1-only] = "LGPL-2.1"
 SPDXLICENSEMAP[LGPLv3] = "LGPL-3.0"
+SPDXLICENSEMAP[LGPLv3+] = "LGPL-3.0+"
 SPDXLICENSEMAP[LGPL-3.0-only] = "LGPL-3.0"
 
 #MPL variations
-- 
2.33.0


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

[OE-core][dunfell][PATCH v2 2/5] classes/package: Add extended packaged data

[Joshua Watt]

Adds extended package data which is encoded as JSON which allows it to
encode more structure than the "flat" package data files. The extended
data might be much larger than the standard package data, so it is not
read by default and instead requires
oe.packagedata.read_subpkgdata_extended() to be called

Currently, the file sizes and ELF debug sources are saved off into the
extended package data

(cherry picked from commit db9cf430e54ae68da80fbc3fba80ce88d8df164d)

Signed-off-by: Joshua Watt 
Reviewed-by: Saul Wold 
Signed-off-by: Joshua Watt 
Signed-off-by: Richard Purdie 
---
 meta/classes/package.bbclass | 40 +---
 meta/lib/oe/packagedata.py   | 12 +++
 2 files changed, 49 insertions(+), 3 deletions(-)

diff --git a/meta/classes/package.bbclass b/meta/classes/package.bbclass
index 702427fecc..84fdafa8fe 100644
--- a/meta/classes/package.bbclass
+++ b/meta/classes/package.bbclass
@@ -1140,6 +1140,14 @@ python split_and_strip_files () {
 # Modified the file so clear the cache
 cpath.updatecache(file)
 
+def strip_pkgd_prefix(f):
+nonlocal dvar
+
+if f.startswith(dvar):
+return f[len(dvar):]
+
+return f
+
 #
 # First lets process debug splitting
 #
@@ -1153,6 +1161,8 @@ python split_and_strip_files () {
 for file in staticlibs:
 results.append( (file,source_info(file, d)) )
 
+d.setVar("PKGDEBUGSOURCES", {strip_pkgd_prefix(f): sorted(s) for f, s 
in results})
+
 sources = set()
 for r in results:
 sources.update(r[1])
@@ -1460,6 +1470,7 @@ PKGDATA_VARS = "PN PE PV PR PKGE PKGV PKGR LICENSE 
DESCRIPTION SUMMARY RDEPENDS
 python emit_pkgdata() {
 from glob import glob
 import json
+import bb.compress.zstd
 
 def process_postinst_on_target(pkg, mlprefix):
 pkgval = d.getVar('PKG_%s' % pkg)
@@ -1532,6 +1543,8 @@ fi
 with open(data_file, 'w') as fd:
 fd.write("PACKAGES: %s\n" % packages)
 
+pkgdebugsource = d.getVar("PKGDEBUGSOURCES") or []
+
 pn = d.getVar('PN')
 global_variants = (d.getVar('MULTILIB_GLOBAL_VARIANTS') or "").split()
 variants = (d.getVar('MULTILIB_VARIANTS') or "").split()
@@ -1551,17 +1564,32 @@ fi
 pkgval = pkg
 d.setVar('PKG_%s' % pkg, pkg)
 
+extended_data = {
+"files_info": {}
+}
+
 pkgdestpkg = os.path.join(pkgdest, pkg)
 files = {}
+files_extra = {}
 total_size = 0
 seen = set()
 for f in pkgfiles[pkg]:
-relpth = os.path.relpath(f, pkgdestpkg)
+fpath = os.sep + os.path.relpath(f, pkgdestpkg)
+
 fstat = os.lstat(f)
-files[os.sep + relpth] = fstat.st_size
+files[fpath] = fstat.st_size
+
+extended_data["files_info"].setdefault(fpath, {})
+extended_data["files_info"][fpath]['size'] = fstat.st_size
+
 if fstat.st_ino not in seen:
 seen.add(fstat.st_ino)
 total_size += fstat.st_size
+
+if fpath in pkgdebugsource:
+extended_data["files_info"][fpath]['debugsrc'] = 
pkgdebugsource[fpath]
+del pkgdebugsource[fpath]
+
 d.setVar('FILES_INFO', json.dumps(files, sort_keys=True))
 
 process_postinst_on_target(pkg, d.getVar("MLPREFIX"))
@@ -1582,6 +1610,11 @@ fi
 
 sf.write('%s_%s: %d\n' % ('PKGSIZE', pkg, total_size))
 
+subdata_extended_file = pkgdatadir + "/extended/%s.json.zstd" % pkg
+num_threads = int(d.getVar("BB_NUMBER_THREADS"))
+with bb.compress.zstd.open(subdata_extended_file, "wt", 
encoding="utf-8", num_threads=num_threads) as f:
+json.dump(extended_data, f, sort_keys=True, separators=(",", ":"))
+
 # Symlinks needed for rprovides lookup
 rprov = d.getVar('RPROVIDES_%s' % pkg) or d.getVar('RPROVIDES')
 if rprov:
@@ -1612,7 +1645,8 @@ fi
 write_extra_runtime_pkgs(global_variants, packages, pkgdatadir)
 
 }
-emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse 
${PKGDESTWORK}/runtime-rprovides"
+emit_pkgdata[dirs] = "${PKGDESTWORK}/runtime ${PKGDESTWORK}/runtime-reverse 
${PKGDESTWORK}/runtime-rprovides ${PKGDESTWORK}/extended"
+emit_pkgdata[vardepsexclude] = "BB_NUMBER_THREADS"
 
 ldconfig_postinst_fragment() {
 if [ x"$D" = "x" ]; then
diff --git a/meta/lib/oe/packagedata.py b/meta/lib/oe/packagedata.py
index a82085a792..00f7dc1f3d 100644
--- a/meta/lib/oe/packagedata.py
+++ b/meta/lib/oe/packagedata.py
@@ -57,6 +57,18 @@ def read_subpkgdata_dict(pkg, d):
 ret[newvar] = subd[var]
 return ret
 
+def read_subpkgdata_extended(pkg, d):
+import json
+import bb.compress.zstd
+
+fn = d.expand("${PKGDATA_DIR}/extended/%s.json.zstd" % pkg)
+try:
+num_threads = int(d.getVar("BB_NUMBER_THREADS"))
+with bb.compress.zstd.open(fn, "r

[OE-core][dunfell][PATCH v2 0/5] Backport SPDX Support

[Joshua Watt]

Backports support to creates SPDX during the build from the master
branch, with a few changes to make it compatible with dunfell.
Primarily, the SPDX data is compressed with gzip instead of zstd to
prevent needing the zstd host tools on the older distros supported by
dunfell

v2:
Fixed SPDX symlinks still using .zst instead of .gz extension

Joshua Watt (5):
  classes/create-spdx: Backport
  classes/package: Add extended packaged data
  licenses: Add GPL+ licenses to map
  create-spdx: Use gzip for compression
  classes/package: Use gzip for extended package data

 meta/classes/create-spdx-2.2.bbclass | 1067 +
 meta/classes/create-spdx.bbclass |8 +
 meta/classes/package.bbclass |   39 +-
 meta/conf/licenses.conf  |7 +
 meta/files/spdx-licenses.json| 5937 ++
 meta/lib/oe/packagedata.py   |   11 +
 meta/lib/oe/sbom.py  |   84 +
 meta/lib/oe/spdx.py  |  357 ++
 8 files changed, 7507 insertions(+), 3 deletions(-)
 create mode 100644 meta/classes/create-spdx-2.2.bbclass
 create mode 100644 meta/classes/create-spdx.bbclass
 create mode 100644 meta/files/spdx-licenses.json
 create mode 100644 meta/lib/oe/sbom.py
 create mode 100644 meta/lib/oe/spdx.py

-- 
2.33.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179176): 
https://lists.openembedded.org/g/openembedded-core/message/179176
Mute This Topic: https://lists.openembedded.org/mt/97890957/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][PATCHv2] webkitgtk: update 2.38.5 -> 2.40.0

[Alexandre Belloni via lists.openembedded.org]

Hello,

Please adjust maintainers.inc:

The following recipes do not have a maintainer assigned to them. Please add an 
entry to meta/conf/distro/include/maintainers.inc file.

Could you run the oe-selftest when submitting?

Thanks!

On 26/03/2023 18:45:57+0200, Markus Volk wrote:
> - added PACKAGECONFIGs for av1 support, gamepad and sandboxing
> - cmake tries to find where bwrap and xdg-dbus-proxy are located on target 
> and reads the path from
>   ${STAGING_BINDIR_NATIVE}. This breaks reproducibility and runtime. Fix by 
> adding the needed paths manually.
> - ccache seems to be working well now. Enable by default. It significantly 
> improves buildtime on rebuilds.
> - webkitgtk can be built with both, gtk+3 and gtk4 but it cant be built with 
> support for both at once.
>   there are still some packages that require the gtk3 variant, nameably surf, 
> gnome-online-accounts and wxwidgets
>   while ephiphany for example has a hard dependency on webkitgtk built with 
> gtk4. This is why we need to provide
>   recipes for both variants. If built with gtk+3 webkitgtk provides the 4.0 
> api, if built with gtk4 it'll provide the
>   6.0 api. The only conflicting file between those two is the WebKitWebDriver 
> binary. This was renamed for the gtk3
>   variant so both variants can be installed into the same image.
> - update dependencies
> - wpebackend-fdo: update
> 
> Signed-off-by: Markus Volk 
> ---
>  ...spection.cmake-prefix-variables-obta.patch |   0
>  .../reproducibility.patch |   0
>  .../recipes-sato/webkit/webkitgtk-3_2.40.0.bb | 168 ++
>  ...44e17d258106617b0e6d783d073b188a2548.patch | 296 --
>  ...bb461f040b90453bc4e100dcf967243ecd98.patch |  30 --
>  ...ebkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} |  67 ++--
>  ...fdo_1.14.0.bb => wpebackend-fdo_1.14.1.bb} |   2 +-
>  7 files changed, 201 insertions(+), 362 deletions(-)
>  rename meta/recipes-sato/webkit/{webkitgtk => 
> files}/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch (100%)
>  rename meta/recipes-sato/webkit/{webkitgtk => files}/reproducibility.patch 
> (100%)
>  create mode 100644 meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
>  delete mode 100644 
> meta/recipes-sato/webkit/webkitgtk/0d3344e17d258106617b0e6d783d073b188a2548.patch
>  delete mode 100644 
> meta/recipes-sato/webkit/webkitgtk/d318bb461f040b90453bc4e100dcf967243ecd98.patch
>  rename meta/recipes-sato/webkit/{webkitgtk_2.38.5.bb => webkitgtk_2.40.0.bb} 
> (77%)
>  rename meta/recipes-sato/webkit/{wpebackend-fdo_1.14.0.bb => 
> wpebackend-fdo_1.14.1.bb} (90%)
> 
> diff --git 
> a/meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
>  
> b/meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> similarity index 100%
> rename from 
> meta/recipes-sato/webkit/webkitgtk/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> rename to 
> meta/recipes-sato/webkit/files/0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch
> diff --git a/meta/recipes-sato/webkit/webkitgtk/reproducibility.patch 
> b/meta/recipes-sato/webkit/files/reproducibility.patch
> similarity index 100%
> rename from meta/recipes-sato/webkit/webkitgtk/reproducibility.patch
> rename to meta/recipes-sato/webkit/files/reproducibility.patch
> diff --git a/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb 
> b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
> new file mode 100644
> index 00..4401b0e527
> --- /dev/null
> +++ b/meta/recipes-sato/webkit/webkitgtk-3_2.40.0.bb
> @@ -0,0 +1,168 @@
> +SUMMARY = "WebKit web rendering engine for the GTK+ platform"
> +HOMEPAGE = "https://www.webkitgtk.org/";
> +BUGTRACKER = "https://bugs.webkit.org/";
> +
> +LICENSE = "BSD-2-Clause & LGPL-2.0-or-later"
> +LIC_FILES_CHKSUM = 
> "file://Source/JavaScriptCore/COPYING.LIB;md5=d0c6d6397a5d84286dda758da57bd691
>  \
> +
> file://Source/WebCore/LICENSE-APPLE;md5=4646f90082c40bcf298c285f8bab0b12 \
> +
> file://Source/WebCore/LICENSE-LGPL-2;md5=36357ffde2b64ae177b2494445b79d21 \
> +
> file://Source/WebCore/LICENSE-LGPL-2.1;md5=a778a33ef338abbaf8b8a7c36b6eec80 \
> +"
> +
> +SRC_URI = "https://www.webkitgtk.org/releases/webkitgtk-${PV}.tar.xz \
> +   
> file://0001-FindGObjectIntrospection.cmake-prefix-variables-obta.patch \
> +   file://reproducibility.patch \
> +   "
> +SRC_URI[sha256sum] = 
> "a4607ea1bf89669e89b1cb2c63faaec513f93de09b6ae60cc71d6a8aab7ab393"
> +
> +S = "${WORKDIR}/webkitgtk-${PV}"
> +
> +inherit ccache cmake pkgconfig gobject-introspection perlnative 
> features_check upstream-version-is-even gi-docgen mime-xdg
> +
> +ANY_OF_DISTRO_FEATURES = "${GTK3DISTROFEATURES}"
> +
> +CVE_PRODUCT = "webkitgtk webkitgtk\+"
> +
> +DEPENDS += " \
> +  atk \
> +  cairo \
> +  gperf-native \
> +  gstreamer1.0 \
> +  gstreame

Re: [OE-core] [PATCH 0/5] Extend cargo based recip support

[Frederic Martinsons]

Thank you alex and alexender ;)

I'll take a look at this as soon as possible and and tell you in a
dedicated thread if I'm making progress. But first, I'll work for the
devtool test that has been mentioned first.

Have a good evening (or day, depending on your timezone)

Le lun. 27 mars 2023, 21:00, Alexander Kanavin  a
écrit :

> For the kernel modules you could start by replicating an out-of-yocto
> kernel build as shown here:
> https://lwn.net/Articles/910762/
>
> Alex
>
> On Mon, 27 Mar 2023 at 20:52, Alex Kiernan  wrote:
> >
> > IIRC the cross upgrade just works, its the target build which explodes:
> >
> > https://github.com/akiernan/openembedded-core
> >
> > On Mon, Mar 27, 2023 at 7:40 PM Frédéric Martinsons
> >  wrote:
> > >
> > > Ok great, I'm willing to know more about the bootstrap of a rust
> toolchain, I think I can start by just upgrading my poky master to rust
> 1.68 and see what it spills out when I compile the hello world
> > >
> > > On the other hand, for enabling rust kernel modules in
> linux-yocto-dev, I don't know where to start (full disclosure : I have no
> skills about kernel and kernel module developments)
> > >
> > > Le lun. 27 mars 2023, 20:30, Alex Kiernan  a
> écrit :
> > >>
> > >> Updating the rust version is pretty much nothing to do with your rust
> > >> knowledge and way more about digging into how the bootstrap process
> > >> hangs together... whilst I have an awesome rustacean working for me, I
> > >> don't think I've ever had to drag him into helping with an upgrade.
> > >>
> > >> I wish I could say I'd spent the last few weeks figuring out why the
> > >> upgrade broke, but I've been buried down the bottom of an ESP-IDF
> > >> application...
> > >>
> > >> Alex
> > >>
> > >> On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
> > >>  wrote:
> > >> >
> > >> > I'll look at this but I'm not sure if I can help since I'm a
> beginner (enthusiastic but still)
> > >> >
> > >> > Le lun. 27 mars 2023, 19:19, Alexander Kanavin <
> alex.kana...@gmail.com> a écrit :
> > >> >>
> > >> >> If you'd like to do more here's off the top of my head:
> > >> >>
> > >> >> - enable rust kernel modules in linux-yocto-dev
> > >> >>
> > >> >> - help Alex Kiernan with update 1.67 -> 1.68; we need as many
> people
> > >> >> as possible capable of updating the rust toolchain. It's often not
> > >> >> trivial:
> > >> >> https://lists.openembedded.org/g/openembedded-core/message/178272
> > >> >>
> > >> >> Alex
> > >> >>
> > >> >> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
> > >> >>  wrote:
> > >> >> >
> > >> >> > Ah!
> > >> >> >
> > >> >> > Alright, I'll try to setup a devtool test which demonstrate the
> usage of git subpath with the zvariant.
> > >> >> > I'll then issue a V4 series which reintroduce the zvariant
> recipe in meta-selftest and the unit test on it.
> > >> >> >
> > >> >> > I must admit I felt in love for rust since the beginning of the
> year and considering that I use yocto on a daily basis, I'll do everything
> I can to extend the support of developing rust for embedded devices.
> > >> >> >
> > >> >> > Thank you all for the advices.
> > >> >> >
> > >> >> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin <
> alex.kana...@gmail.com> a écrit :
> > >> >> >>
> > >> >> >> So if devtool tests would operate on zvariant recipe, then the
> recipe
> > >> >> >> can simply go into meta-selftest after all :)
> > >> >> >>
> > >> >> >> Alex
> > >> >> >>
> > >> >> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
> > >> >> >>  wrote:
> > >> >> >> >
> > >> >> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> > >> >> >> > > From: Frederic Martinsons 
> > >> >> >> > >
> > >> >> >> > > This series brings the support of local git repository
> inside
> > >> >> >> > > a cargo based recipe.
> > >> >> >> > >
> > >> >> >> > > It also enable devtool capacity on it and provide a real
> crate
> > >> >> >> > > example recipe to show how things are done.
> > >> >> >> > >
> > >> >> >> > > The following changes since commit
> 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> > >> >> >> > >
> > >> >> >> > >   xcb-proto: Fix install conflict when enable multilib.
> (2023-03-23 22:38:41 +)
> > >> >> >> > >
> > >> >> >> > > are available in the Git repository at:
> > >> >> >> > >
> > >> >> >> > >   https://gitlab.com/fmartinsons/openembedded-core
> cargo-extend-support-git-and-devtool
> > >> >> >> > >
> > >> >> >> > > Alex Kiernan (1):
> > >> >> >> > >   cargo_common.bbclass: Support local github repos
> > >> >> >> > >
> > >> >> >> > > Frederic Martinsons (4):
> > >> >> >> > >   cargo_common.bbclass: add support of user in url for patch
> > >> >> >> > >   rust-example: provide a recipe for zvariant
> > >> >> >> > >   devtool: add support for multiple git url inside a cargo
> based recipe
> > >> >> >> > >   patch: support of git patches when the source uri
> contained subpath
> > >> >> >> > > param
> > >> >> >> >
> > >> >> >> > The various rust/cargo/crate patches look like they're
> heading in a
>

Re: [OE-core] [PATCH 0/5] Extend cargo based recip support

[Alexander Kanavin]

For the kernel modules you could start by replicating an out-of-yocto
kernel build as shown here:
https://lwn.net/Articles/910762/

Alex

On Mon, 27 Mar 2023 at 20:52, Alex Kiernan  wrote:
>
> IIRC the cross upgrade just works, its the target build which explodes:
>
> https://github.com/akiernan/openembedded-core
>
> On Mon, Mar 27, 2023 at 7:40 PM Frédéric Martinsons
>  wrote:
> >
> > Ok great, I'm willing to know more about the bootstrap of a rust toolchain, 
> > I think I can start by just upgrading my poky master to rust 1.68 and see 
> > what it spills out when I compile the hello world
> >
> > On the other hand, for enabling rust kernel modules in linux-yocto-dev, I 
> > don't know where to start (full disclosure : I have no skills about kernel 
> > and kernel module developments)
> >
> > Le lun. 27 mars 2023, 20:30, Alex Kiernan  a écrit :
> >>
> >> Updating the rust version is pretty much nothing to do with your rust
> >> knowledge and way more about digging into how the bootstrap process
> >> hangs together... whilst I have an awesome rustacean working for me, I
> >> don't think I've ever had to drag him into helping with an upgrade.
> >>
> >> I wish I could say I'd spent the last few weeks figuring out why the
> >> upgrade broke, but I've been buried down the bottom of an ESP-IDF
> >> application...
> >>
> >> Alex
> >>
> >> On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
> >>  wrote:
> >> >
> >> > I'll look at this but I'm not sure if I can help since I'm a beginner 
> >> > (enthusiastic but still)
> >> >
> >> > Le lun. 27 mars 2023, 19:19, Alexander Kanavin  
> >> > a écrit :
> >> >>
> >> >> If you'd like to do more here's off the top of my head:
> >> >>
> >> >> - enable rust kernel modules in linux-yocto-dev
> >> >>
> >> >> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
> >> >> as possible capable of updating the rust toolchain. It's often not
> >> >> trivial:
> >> >> https://lists.openembedded.org/g/openembedded-core/message/178272
> >> >>
> >> >> Alex
> >> >>
> >> >> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
> >> >>  wrote:
> >> >> >
> >> >> > Ah!
> >> >> >
> >> >> > Alright, I'll try to setup a devtool test which demonstrate the usage 
> >> >> > of git subpath with the zvariant.
> >> >> > I'll then issue a V4 series which reintroduce the zvariant recipe in 
> >> >> > meta-selftest and the unit test on it.
> >> >> >
> >> >> > I must admit I felt in love for rust since the beginning of the year 
> >> >> > and considering that I use yocto on a daily basis, I'll do everything 
> >> >> > I can to extend the support of developing rust for embedded devices.
> >> >> >
> >> >> > Thank you all for the advices.
> >> >> >
> >> >> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin 
> >> >> >  a écrit :
> >> >> >>
> >> >> >> So if devtool tests would operate on zvariant recipe, then the recipe
> >> >> >> can simply go into meta-selftest after all :)
> >> >> >>
> >> >> >> Alex
> >> >> >>
> >> >> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
> >> >> >>  wrote:
> >> >> >> >
> >> >> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> >> >> >> > > From: Frederic Martinsons 
> >> >> >> > >
> >> >> >> > > This series brings the support of local git repository inside
> >> >> >> > > a cargo based recipe.
> >> >> >> > >
> >> >> >> > > It also enable devtool capacity on it and provide a real crate
> >> >> >> > > example recipe to show how things are done.
> >> >> >> > >
> >> >> >> > > The following changes since commit 
> >> >> >> > > 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> >> >> >> > >
> >> >> >> > >   xcb-proto: Fix install conflict when enable multilib. 
> >> >> >> > > (2023-03-23 22:38:41 +)
> >> >> >> > >
> >> >> >> > > are available in the Git repository at:
> >> >> >> > >
> >> >> >> > >   https://gitlab.com/fmartinsons/openembedded-core 
> >> >> >> > > cargo-extend-support-git-and-devtool
> >> >> >> > >
> >> >> >> > > Alex Kiernan (1):
> >> >> >> > >   cargo_common.bbclass: Support local github repos
> >> >> >> > >
> >> >> >> > > Frederic Martinsons (4):
> >> >> >> > >   cargo_common.bbclass: add support of user in url for patch
> >> >> >> > >   rust-example: provide a recipe for zvariant
> >> >> >> > >   devtool: add support for multiple git url inside a cargo based 
> >> >> >> > > recipe
> >> >> >> > >   patch: support of git patches when the source uri contained 
> >> >> >> > > subpath
> >> >> >> > > param
> >> >> >> >
> >> >> >> > The various rust/cargo/crate patches look like they're heading in a
> >> >> >> > good direction, thanks!
> >> >> >> >
> >> >> >> > The one thing which I think is missing is more support for testing 
> >> >> >> > some
> >> >> >> > of these changes in our automated testing.
> >> >> >> >
> >> >> >> > In particular, devtool does have a decent test suite so we should
> >> >> >> > ensure new devtool additions have tests.
> >> >> >> >
> >> >> >> > You can see the devtools tests in
> >> >> >> > meta/lib/oeqa/selftest/cases/d

Re: [OE-core] [PATCH 0/5] Extend cargo based recip support

[Alex Kiernan]

IIRC the cross upgrade just works, its the target build which explodes:

https://github.com/akiernan/openembedded-core

On Mon, Mar 27, 2023 at 7:40 PM Frédéric Martinsons
 wrote:
>
> Ok great, I'm willing to know more about the bootstrap of a rust toolchain, I 
> think I can start by just upgrading my poky master to rust 1.68 and see what 
> it spills out when I compile the hello world
>
> On the other hand, for enabling rust kernel modules in linux-yocto-dev, I 
> don't know where to start (full disclosure : I have no skills about kernel 
> and kernel module developments)
>
> Le lun. 27 mars 2023, 20:30, Alex Kiernan  a écrit :
>>
>> Updating the rust version is pretty much nothing to do with your rust
>> knowledge and way more about digging into how the bootstrap process
>> hangs together... whilst I have an awesome rustacean working for me, I
>> don't think I've ever had to drag him into helping with an upgrade.
>>
>> I wish I could say I'd spent the last few weeks figuring out why the
>> upgrade broke, but I've been buried down the bottom of an ESP-IDF
>> application...
>>
>> Alex
>>
>> On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
>>  wrote:
>> >
>> > I'll look at this but I'm not sure if I can help since I'm a beginner 
>> > (enthusiastic but still)
>> >
>> > Le lun. 27 mars 2023, 19:19, Alexander Kanavin  a 
>> > écrit :
>> >>
>> >> If you'd like to do more here's off the top of my head:
>> >>
>> >> - enable rust kernel modules in linux-yocto-dev
>> >>
>> >> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
>> >> as possible capable of updating the rust toolchain. It's often not
>> >> trivial:
>> >> https://lists.openembedded.org/g/openembedded-core/message/178272
>> >>
>> >> Alex
>> >>
>> >> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
>> >>  wrote:
>> >> >
>> >> > Ah!
>> >> >
>> >> > Alright, I'll try to setup a devtool test which demonstrate the usage 
>> >> > of git subpath with the zvariant.
>> >> > I'll then issue a V4 series which reintroduce the zvariant recipe in 
>> >> > meta-selftest and the unit test on it.
>> >> >
>> >> > I must admit I felt in love for rust since the beginning of the year 
>> >> > and considering that I use yocto on a daily basis, I'll do everything I 
>> >> > can to extend the support of developing rust for embedded devices.
>> >> >
>> >> > Thank you all for the advices.
>> >> >
>> >> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin  
>> >> > a écrit :
>> >> >>
>> >> >> So if devtool tests would operate on zvariant recipe, then the recipe
>> >> >> can simply go into meta-selftest after all :)
>> >> >>
>> >> >> Alex
>> >> >>
>> >> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
>> >> >>  wrote:
>> >> >> >
>> >> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
>> >> >> > > From: Frederic Martinsons 
>> >> >> > >
>> >> >> > > This series brings the support of local git repository inside
>> >> >> > > a cargo based recipe.
>> >> >> > >
>> >> >> > > It also enable devtool capacity on it and provide a real crate
>> >> >> > > example recipe to show how things are done.
>> >> >> > >
>> >> >> > > The following changes since commit 
>> >> >> > > 4876189dd2ae5a04a296b11b537b9f613159c6bf:
>> >> >> > >
>> >> >> > >   xcb-proto: Fix install conflict when enable multilib. 
>> >> >> > > (2023-03-23 22:38:41 +)
>> >> >> > >
>> >> >> > > are available in the Git repository at:
>> >> >> > >
>> >> >> > >   https://gitlab.com/fmartinsons/openembedded-core 
>> >> >> > > cargo-extend-support-git-and-devtool
>> >> >> > >
>> >> >> > > Alex Kiernan (1):
>> >> >> > >   cargo_common.bbclass: Support local github repos
>> >> >> > >
>> >> >> > > Frederic Martinsons (4):
>> >> >> > >   cargo_common.bbclass: add support of user in url for patch
>> >> >> > >   rust-example: provide a recipe for zvariant
>> >> >> > >   devtool: add support for multiple git url inside a cargo based 
>> >> >> > > recipe
>> >> >> > >   patch: support of git patches when the source uri contained 
>> >> >> > > subpath
>> >> >> > > param
>> >> >> >
>> >> >> > The various rust/cargo/crate patches look like they're heading in a
>> >> >> > good direction, thanks!
>> >> >> >
>> >> >> > The one thing which I think is missing is more support for testing 
>> >> >> > some
>> >> >> > of these changes in our automated testing.
>> >> >> >
>> >> >> > In particular, devtool does have a decent test suite so we should
>> >> >> > ensure new devtool additions have tests.
>> >> >> >
>> >> >> > You can see the devtools tests in
>> >> >> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
>> >> >> > like "oe-selftest -r devtool -j 3" for example.
>> >> >> >
>> >> >> > Cheers,
>> >> >> >
>> >> >> > Richard
>> >> >> >
>> >> >> > 
>> >> >> >
>>
>>
>>
>> --
>> Alex Kiernan



-- 
Alex Kiernan

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

Re: [OE-core] [PATCH 0/5] Extend cargo based recip support

[Frederic Martinsons]

Ok great, I'm willing to know more about the bootstrap of a rust toolchain,
I think I can start by just upgrading my poky master to rust 1.68 and see
what it spills out when I compile the hello world

On the other hand, for enabling rust kernel modules in linux-yocto-dev, I
don't know where to start (full disclosure : I have no skills about kernel
and kernel module developments)

Le lun. 27 mars 2023, 20:30, Alex Kiernan  a écrit :

> Updating the rust version is pretty much nothing to do with your rust
> knowledge and way more about digging into how the bootstrap process
> hangs together... whilst I have an awesome rustacean working for me, I
> don't think I've ever had to drag him into helping with an upgrade.
>
> I wish I could say I'd spent the last few weeks figuring out why the
> upgrade broke, but I've been buried down the bottom of an ESP-IDF
> application...
>
> Alex
>
> On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
>  wrote:
> >
> > I'll look at this but I'm not sure if I can help since I'm a beginner
> (enthusiastic but still)
> >
> > Le lun. 27 mars 2023, 19:19, Alexander Kanavin 
> a écrit :
> >>
> >> If you'd like to do more here's off the top of my head:
> >>
> >> - enable rust kernel modules in linux-yocto-dev
> >>
> >> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
> >> as possible capable of updating the rust toolchain. It's often not
> >> trivial:
> >> https://lists.openembedded.org/g/openembedded-core/message/178272
> >>
> >> Alex
> >>
> >> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
> >>  wrote:
> >> >
> >> > Ah!
> >> >
> >> > Alright, I'll try to setup a devtool test which demonstrate the usage
> of git subpath with the zvariant.
> >> > I'll then issue a V4 series which reintroduce the zvariant recipe in
> meta-selftest and the unit test on it.
> >> >
> >> > I must admit I felt in love for rust since the beginning of the year
> and considering that I use yocto on a daily basis, I'll do everything I can
> to extend the support of developing rust for embedded devices.
> >> >
> >> > Thank you all for the advices.
> >> >
> >> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin <
> alex.kana...@gmail.com> a écrit :
> >> >>
> >> >> So if devtool tests would operate on zvariant recipe, then the recipe
> >> >> can simply go into meta-selftest after all :)
> >> >>
> >> >> Alex
> >> >>
> >> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
> >> >>  wrote:
> >> >> >
> >> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> >> >> > > From: Frederic Martinsons 
> >> >> > >
> >> >> > > This series brings the support of local git repository inside
> >> >> > > a cargo based recipe.
> >> >> > >
> >> >> > > It also enable devtool capacity on it and provide a real crate
> >> >> > > example recipe to show how things are done.
> >> >> > >
> >> >> > > The following changes since commit
> 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> >> >> > >
> >> >> > >   xcb-proto: Fix install conflict when enable multilib.
> (2023-03-23 22:38:41 +)
> >> >> > >
> >> >> > > are available in the Git repository at:
> >> >> > >
> >> >> > >   https://gitlab.com/fmartinsons/openembedded-core
> cargo-extend-support-git-and-devtool
> >> >> > >
> >> >> > > Alex Kiernan (1):
> >> >> > >   cargo_common.bbclass: Support local github repos
> >> >> > >
> >> >> > > Frederic Martinsons (4):
> >> >> > >   cargo_common.bbclass: add support of user in url for patch
> >> >> > >   rust-example: provide a recipe for zvariant
> >> >> > >   devtool: add support for multiple git url inside a cargo based
> recipe
> >> >> > >   patch: support of git patches when the source uri contained
> subpath
> >> >> > > param
> >> >> >
> >> >> > The various rust/cargo/crate patches look like they're heading in a
> >> >> > good direction, thanks!
> >> >> >
> >> >> > The one thing which I think is missing is more support for testing
> some
> >> >> > of these changes in our automated testing.
> >> >> >
> >> >> > In particular, devtool does have a decent test suite so we should
> >> >> > ensure new devtool additions have tests.
> >> >> >
> >> >> > You can see the devtools tests in
> >> >> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
> >> >> > like "oe-selftest -r devtool -j 3" for example.
> >> >> >
> >> >> > Cheers,
> >> >> >
> >> >> > Richard
> >> >> >
> >> >> > 
> >> >> >
>
>
>
> --
> Alex Kiernan
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179171): 
https://lists.openembedded.org/g/openembedded-core/message/179171
Mute This Topic: https://lists.openembedded.org/mt/97840361/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/5] Extend cargo based recip support

[Alex Kiernan]

Updating the rust version is pretty much nothing to do with your rust
knowledge and way more about digging into how the bootstrap process
hangs together... whilst I have an awesome rustacean working for me, I
don't think I've ever had to drag him into helping with an upgrade.

I wish I could say I'd spent the last few weeks figuring out why the
upgrade broke, but I've been buried down the bottom of an ESP-IDF
application...

Alex

On Mon, Mar 27, 2023 at 7:08 PM Frédéric Martinsons
 wrote:
>
> I'll look at this but I'm not sure if I can help since I'm a beginner 
> (enthusiastic but still)
>
> Le lun. 27 mars 2023, 19:19, Alexander Kanavin  a 
> écrit :
>>
>> If you'd like to do more here's off the top of my head:
>>
>> - enable rust kernel modules in linux-yocto-dev
>>
>> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
>> as possible capable of updating the rust toolchain. It's often not
>> trivial:
>> https://lists.openembedded.org/g/openembedded-core/message/178272
>>
>> Alex
>>
>> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
>>  wrote:
>> >
>> > Ah!
>> >
>> > Alright, I'll try to setup a devtool test which demonstrate the usage of 
>> > git subpath with the zvariant.
>> > I'll then issue a V4 series which reintroduce the zvariant recipe in 
>> > meta-selftest and the unit test on it.
>> >
>> > I must admit I felt in love for rust since the beginning of the year and 
>> > considering that I use yocto on a daily basis, I'll do everything I can to 
>> > extend the support of developing rust for embedded devices.
>> >
>> > Thank you all for the advices.
>> >
>> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin  a 
>> > écrit :
>> >>
>> >> So if devtool tests would operate on zvariant recipe, then the recipe
>> >> can simply go into meta-selftest after all :)
>> >>
>> >> Alex
>> >>
>> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
>> >>  wrote:
>> >> >
>> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
>> >> > > From: Frederic Martinsons 
>> >> > >
>> >> > > This series brings the support of local git repository inside
>> >> > > a cargo based recipe.
>> >> > >
>> >> > > It also enable devtool capacity on it and provide a real crate
>> >> > > example recipe to show how things are done.
>> >> > >
>> >> > > The following changes since commit 
>> >> > > 4876189dd2ae5a04a296b11b537b9f613159c6bf:
>> >> > >
>> >> > >   xcb-proto: Fix install conflict when enable multilib. (2023-03-23 
>> >> > > 22:38:41 +)
>> >> > >
>> >> > > are available in the Git repository at:
>> >> > >
>> >> > >   https://gitlab.com/fmartinsons/openembedded-core 
>> >> > > cargo-extend-support-git-and-devtool
>> >> > >
>> >> > > Alex Kiernan (1):
>> >> > >   cargo_common.bbclass: Support local github repos
>> >> > >
>> >> > > Frederic Martinsons (4):
>> >> > >   cargo_common.bbclass: add support of user in url for patch
>> >> > >   rust-example: provide a recipe for zvariant
>> >> > >   devtool: add support for multiple git url inside a cargo based 
>> >> > > recipe
>> >> > >   patch: support of git patches when the source uri contained subpath
>> >> > > param
>> >> >
>> >> > The various rust/cargo/crate patches look like they're heading in a
>> >> > good direction, thanks!
>> >> >
>> >> > The one thing which I think is missing is more support for testing some
>> >> > of these changes in our automated testing.
>> >> >
>> >> > In particular, devtool does have a decent test suite so we should
>> >> > ensure new devtool additions have tests.
>> >> >
>> >> > You can see the devtools tests in
>> >> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
>> >> > like "oe-selftest -r devtool -j 3" for example.
>> >> >
>> >> > Cheers,
>> >> >
>> >> > Richard
>> >> >
>> >> > 
>> >> >



-- 
Alex Kiernan

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179170): 
https://lists.openembedded.org/g/openembedded-core/message/179170
Mute This Topic: https://lists.openembedded.org/mt/97840361/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/5] Extend cargo based recip support

[Frederic Martinsons]

I'll look at this but I'm not sure if I can help since I'm a beginner
(enthusiastic but still)

Le lun. 27 mars 2023, 19:19, Alexander Kanavin  a
écrit :

> If you'd like to do more here's off the top of my head:
>
> - enable rust kernel modules in linux-yocto-dev
>
> - help Alex Kiernan with update 1.67 -> 1.68; we need as many people
> as possible capable of updating the rust toolchain. It's often not
> trivial:
> https://lists.openembedded.org/g/openembedded-core/message/178272
>
> Alex
>
> On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
>  wrote:
> >
> > Ah!
> >
> > Alright, I'll try to setup a devtool test which demonstrate the usage of
> git subpath with the zvariant.
> > I'll then issue a V4 series which reintroduce the zvariant recipe in
> meta-selftest and the unit test on it.
> >
> > I must admit I felt in love for rust since the beginning of the year and
> considering that I use yocto on a daily basis, I'll do everything I can to
> extend the support of developing rust for embedded devices.
> >
> > Thank you all for the advices.
> >
> > Le lun. 27 mars 2023, 16:25, Alexander Kanavin 
> a écrit :
> >>
> >> So if devtool tests would operate on zvariant recipe, then the recipe
> >> can simply go into meta-selftest after all :)
> >>
> >> Alex
> >>
> >> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
> >>  wrote:
> >> >
> >> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> >> > > From: Frederic Martinsons 
> >> > >
> >> > > This series brings the support of local git repository inside
> >> > > a cargo based recipe.
> >> > >
> >> > > It also enable devtool capacity on it and provide a real crate
> >> > > example recipe to show how things are done.
> >> > >
> >> > > The following changes since commit
> 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> >> > >
> >> > >   xcb-proto: Fix install conflict when enable multilib. (2023-03-23
> 22:38:41 +)
> >> > >
> >> > > are available in the Git repository at:
> >> > >
> >> > >   https://gitlab.com/fmartinsons/openembedded-core
> cargo-extend-support-git-and-devtool
> >> > >
> >> > > Alex Kiernan (1):
> >> > >   cargo_common.bbclass: Support local github repos
> >> > >
> >> > > Frederic Martinsons (4):
> >> > >   cargo_common.bbclass: add support of user in url for patch
> >> > >   rust-example: provide a recipe for zvariant
> >> > >   devtool: add support for multiple git url inside a cargo based
> recipe
> >> > >   patch: support of git patches when the source uri contained
> subpath
> >> > > param
> >> >
> >> > The various rust/cargo/crate patches look like they're heading in a
> >> > good direction, thanks!
> >> >
> >> > The one thing which I think is missing is more support for testing
> some
> >> > of these changes in our automated testing.
> >> >
> >> > In particular, devtool does have a decent test suite so we should
> >> > ensure new devtool additions have tests.
> >> >
> >> > You can see the devtools tests in
> >> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
> >> > like "oe-selftest -r devtool -j 3" for example.
> >> >
> >> > Cheers,
> >> >
> >> > Richard
> >> >
> >> > 
> >> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179169): 
https://lists.openembedded.org/g/openembedded-core/message/179169
Mute This Topic: https://lists.openembedded.org/mt/97840361/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/5] Extend cargo based recip support

[Alexander Kanavin]

If you'd like to do more here's off the top of my head:

- enable rust kernel modules in linux-yocto-dev

- help Alex Kiernan with update 1.67 -> 1.68; we need as many people
as possible capable of updating the rust toolchain. It's often not
trivial:
https://lists.openembedded.org/g/openembedded-core/message/178272

Alex

On Mon, 27 Mar 2023 at 17:01, Frédéric Martinsons
 wrote:
>
> Ah!
>
> Alright, I'll try to setup a devtool test which demonstrate the usage of git 
> subpath with the zvariant.
> I'll then issue a V4 series which reintroduce the zvariant recipe in 
> meta-selftest and the unit test on it.
>
> I must admit I felt in love for rust since the beginning of the year and 
> considering that I use yocto on a daily basis, I'll do everything I can to 
> extend the support of developing rust for embedded devices.
>
> Thank you all for the advices.
>
> Le lun. 27 mars 2023, 16:25, Alexander Kanavin  a 
> écrit :
>>
>> So if devtool tests would operate on zvariant recipe, then the recipe
>> can simply go into meta-selftest after all :)
>>
>> Alex
>>
>> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
>>  wrote:
>> >
>> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
>> > > From: Frederic Martinsons 
>> > >
>> > > This series brings the support of local git repository inside
>> > > a cargo based recipe.
>> > >
>> > > It also enable devtool capacity on it and provide a real crate
>> > > example recipe to show how things are done.
>> > >
>> > > The following changes since commit 
>> > > 4876189dd2ae5a04a296b11b537b9f613159c6bf:
>> > >
>> > >   xcb-proto: Fix install conflict when enable multilib. (2023-03-23 
>> > > 22:38:41 +)
>> > >
>> > > are available in the Git repository at:
>> > >
>> > >   https://gitlab.com/fmartinsons/openembedded-core 
>> > > cargo-extend-support-git-and-devtool
>> > >
>> > > Alex Kiernan (1):
>> > >   cargo_common.bbclass: Support local github repos
>> > >
>> > > Frederic Martinsons (4):
>> > >   cargo_common.bbclass: add support of user in url for patch
>> > >   rust-example: provide a recipe for zvariant
>> > >   devtool: add support for multiple git url inside a cargo based recipe
>> > >   patch: support of git patches when the source uri contained subpath
>> > > param
>> >
>> > The various rust/cargo/crate patches look like they're heading in a
>> > good direction, thanks!
>> >
>> > The one thing which I think is missing is more support for testing some
>> > of these changes in our automated testing.
>> >
>> > In particular, devtool does have a decent test suite so we should
>> > ensure new devtool additions have tests.
>> >
>> > You can see the devtools tests in
>> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
>> > like "oe-selftest -r devtool -j 3" for example.
>> >
>> > Cheers,
>> >
>> > Richard
>> >
>> > 
>> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179168): 
https://lists.openembedded.org/g/openembedded-core/message/179168
Mute This Topic: https://lists.openembedded.org/mt/97840361/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] ReproducibleTests: split different from missing

[Jose Quaresma]

When we provide sstate_targets recipes they are reported as missing
which is not quite correct because they are proveided to cut build/debugging 
time.

Signed-off-by: Jose Quaresma 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 10 +++---
 1 file changed, 7 insertions(+), 3 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index f4dd779842..cd7aa8aafa 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -292,9 +292,13 @@ class ReproducibleTests(OESelftestTestCase):
 self.copy_file(d.reference, '/'.join([save_dir, 
'packages-excluded', strip_topdir(d.reference)]))
 self.copy_file(d.test, '/'.join([save_dir, 
'packages-excluded', strip_topdir(d.test)]))
 
-if result.missing or result.different:
-fails.append("The following %s packages are missing or 
different and not in exclusion list: %s" %
-(c, '\n'.join(r.test for r in (result.missing + 
result.different
+if result.different:
+fails.append("The following %s packages are different and 
not in exclusion list:\n%s" %
+(c, '\n'.join(r.test for r in (result.different
+
+if result.missing and len(self.sstate_targets) == 0:
+fails.append("The following %s packages are missing and 
not in exclusion list:\n%s" %
+(c, '\n'.join(r.test for r in (result.missing
 
 # Clean up empty directories
 if self.save_results:
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179167): 
https://lists.openembedded.org/g/openembedded-core/message/179167
Mute This Topic: https://lists.openembedded.org/mt/97885571/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] OESelftestTestContext: convert relative to full path when newbuilddir is provided

[Jose Quaresma]

Relative paths in BBLAYERS only works when the new build dir are on the same
ascending directory node:
 .
 ├── build
 ├── build-st

It works because they share the same ascending relative directory node.

So use the full path when the argument newbuilddir is provided
to make the oe-selftest work everywere regardless of the location chosen.

Signed-off-by: Jose Quaresma 
---
 meta/lib/oeqa/selftest/context.py | 10 ++
 1 file changed, 10 insertions(+)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index adfb1170db..0a7a9da72a 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -102,6 +102,16 @@ class OESelftestTestContext(OETestContext):
 # Tried to used bitbake-layers add/remove but it requires recipe 
parsing and hence is too slow
 subprocess.check_output("sed %s/conf/bblayers.conf -i -e 's#%s#%s#g'" 
% (newbuilddir, selftestdir, newselftestdir), cwd=newbuilddir, shell=True)
 
+# Relative paths in BBLAYERS only works when the new build dir share 
the same ascending node
+if self.newbuilddir:
+bblayers = subprocess.check_output("bitbake-getvar --value 
BBLAYERS | tail -1", cwd=builddir, shell=True, text=True)
+if '..' in bblayers:
+bblayers_abspath = [os.path.abspath(path) for path in 
bblayers.split()]
+with open("%s/conf/bblayers.conf" % newbuilddir, "a") as f:
+newbblayers = "# new bblayers to be used by selftest in 
the new build dir '%s'\n" % newbuilddir
+newbblayers += 'BBLAYERS = "%s"\n' % ' 
'.join(bblayers_abspath)
+f.write(newbblayers)
+
 for e in os.environ:
 if builddir + "/" in os.environ[e]:
 os.environ[e] = os.environ[e].replace(builddir + "/", 
newbuilddir + "/")
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179166): 
https://lists.openembedded.org/g/openembedded-core/message/179166
Mute This Topic: https://lists.openembedded.org/mt/97885548/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] OESelftestTestContext: replace the os.environ after subprocess.check_output

[Jose Quaresma]

No function change but is needed to simplify the next patch.

Signed-off-by: Jose Quaresma 
---
 meta/lib/oeqa/selftest/context.py | 10 +-
 1 file changed, 5 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/context.py 
b/meta/lib/oeqa/selftest/context.py
index ab13131f29..adfb1170db 100644
--- a/meta/lib/oeqa/selftest/context.py
+++ b/meta/lib/oeqa/selftest/context.py
@@ -97,17 +97,17 @@ class OESelftestTestContext(OETestContext):
 oe.path.copytree(builddir + "/cache", newbuilddir + "/cache")
 oe.path.copytree(selftestdir, newselftestdir)
 
+subprocess.check_output("git init; git add *; git commit -a -m 
'initial'", cwd=newselftestdir, shell=True)
+
+# Tried to used bitbake-layers add/remove but it requires recipe 
parsing and hence is too slow
+subprocess.check_output("sed %s/conf/bblayers.conf -i -e 's#%s#%s#g'" 
% (newbuilddir, selftestdir, newselftestdir), cwd=newbuilddir, shell=True)
+
 for e in os.environ:
 if builddir + "/" in os.environ[e]:
 os.environ[e] = os.environ[e].replace(builddir + "/", 
newbuilddir + "/")
 if os.environ[e].endswith(builddir):
 os.environ[e] = os.environ[e].replace(builddir, newbuilddir)
 
-subprocess.check_output("git init; git add *; git commit -a -m 
'initial'", cwd=newselftestdir, shell=True)
-
-# Tried to used bitbake-layers add/remove but it requires recipe 
parsing and hence is too slow
-subprocess.check_output("sed %s/conf/bblayers.conf -i -e 's#%s#%s#g'" 
% (newbuilddir, selftestdir, newselftestdir), cwd=newbuilddir, shell=True)
-
 os.chdir(newbuilddir)
 
 def patch_test(t):
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179165): 
https://lists.openembedded.org/g/openembedded-core/message/179165
Mute This Topic: https://lists.openembedded.org/mt/97885542/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/5] Extend cargo based recip support

[Frederic Martinsons]

Ah!

Alright, I'll try to setup a devtool test which demonstrate the usage of
git subpath with the zvariant.
I'll then issue a V4 series which reintroduce the zvariant recipe in
meta-selftest and the unit test on it.

I must admit I felt in love for rust since the beginning of the year and
considering that I use yocto on a daily basis, I'll do everything I can to
extend the support of developing rust for embedded devices.

Thank you all for the advices.

Le lun. 27 mars 2023, 16:25, Alexander Kanavin  a
écrit :

> So if devtool tests would operate on zvariant recipe, then the recipe
> can simply go into meta-selftest after all :)
>
> Alex
>
> On Mon, 27 Mar 2023 at 16:20, Richard Purdie
>  wrote:
> >
> > On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> > > From: Frederic Martinsons 
> > >
> > > This series brings the support of local git repository inside
> > > a cargo based recipe.
> > >
> > > It also enable devtool capacity on it and provide a real crate
> > > example recipe to show how things are done.
> > >
> > > The following changes since commit
> 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> > >
> > >   xcb-proto: Fix install conflict when enable multilib. (2023-03-23
> 22:38:41 +)
> > >
> > > are available in the Git repository at:
> > >
> > >   https://gitlab.com/fmartinsons/openembedded-core
> cargo-extend-support-git-and-devtool
> > >
> > > Alex Kiernan (1):
> > >   cargo_common.bbclass: Support local github repos
> > >
> > > Frederic Martinsons (4):
> > >   cargo_common.bbclass: add support of user in url for patch
> > >   rust-example: provide a recipe for zvariant
> > >   devtool: add support for multiple git url inside a cargo based recipe
> > >   patch: support of git patches when the source uri contained subpath
> > > param
> >
> > The various rust/cargo/crate patches look like they're heading in a
> > good direction, thanks!
> >
> > The one thing which I think is missing is more support for testing some
> > of these changes in our automated testing.
> >
> > In particular, devtool does have a decent test suite so we should
> > ensure new devtool additions have tests.
> >
> > You can see the devtools tests in
> > meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
> > like "oe-selftest -r devtool -j 3" for example.
> >
> > Cheers,
> >
> > Richard
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179164): 
https://lists.openembedded.org/g/openembedded-core/message/179164
Mute This Topic: https://lists.openembedded.org/mt/97840361/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/7] epiphany: update 43.1 -> 44.0

[Alexandre Belloni via lists.openembedded.org]

This fails on the AB:

https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/2612/steps/13/logs/stdio

ERROR: Nothing PROVIDES 'libadwaita' (but 
/home/pokybuild/yocto-worker/reproducible/build/meta/recipes-gnome/epiphany/epiphany_44.0.bb
 DEPENDS on or otherwise requires it). Close matches:
  libedit

On 25/03/2023 01:48:17+0100, Markus Volk wrote:
> Signed-off-by: Markus Volk 
> ---
>  .../{epiphany_43.1.bb => epiphany_44.0.bb}| 37 +++
>  1 file changed, 22 insertions(+), 15 deletions(-)
>  rename meta/recipes-gnome/epiphany/{epiphany_43.1.bb => epiphany_44.0.bb} 
> (72%)
> 
> diff --git a/meta/recipes-gnome/epiphany/epiphany_43.1.bb 
> b/meta/recipes-gnome/epiphany/epiphany_44.0.bb
> similarity index 72%
> rename from meta/recipes-gnome/epiphany/epiphany_43.1.bb
> rename to meta/recipes-gnome/epiphany/epiphany_44.0.bb
> index ea22723a97..f10b818a06 100644
> --- a/meta/recipes-gnome/epiphany/epiphany_43.1.bb
> +++ b/meta/recipes-gnome/epiphany/epiphany_44.0.bb
> @@ -7,20 +7,27 @@ LICENSE = "GPL-3.0-or-later"
>  LIC_FILES_CHKSUM = "file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
>  
>  DEPENDS = " \
> -  webkitgtk \
> -  gcr3 \
> -  gsettings-desktop-schemas \
> -  nettle \
> -  json-glib \
> -  libarchive \
> -  libdazzle \
> -  libhandy \
> -  libportal \
> -  libsoup \
> -  glib-2.0-native \
> -  coreutils-native \
> -  desktop-file-utils-native \
> -  "
> + appstream-glib-native \
> + coreutils-native \
> + desktop-file-utils-native \
> + gcr \
> + glib-2.0-native \
> + gsettings-desktop-schemas \
> + gstreamer1.0 \
> + iso-codes \
> + json-glib \
> + libadwaita \
> + libarchive \
> + libdazzle \
> + libhandy \
> + libportal \
> + libsecret \
> + libsoup \
> + libxml2 \
> + nettle \
> + sqlite3 \
> + webkitgtk \
> +"
>  
>  GNOMEBASEBUILDCLASS = "meson"
>  inherit gnomebase gsettings features_check gettext mime-xdg gtk-icon-cache
> @@ -31,7 +38,7 @@ SRC_URI = 
> "${GNOME_MIRROR}/${GNOMEBN}/${@oe.utils.trim_version("${PV}", 1)}/${GN
> file://migrator.patch \
> file://distributor.patch \
> "
> -SRC_URI[archive.sha256sum] = 
> "e86ead27cb9982815150664de3bf20faf375f77b8065b02b31180c65b6bbebb4"
> +SRC_URI[archive.sha256sum] = 
> "aabdc9de80c409073676e00e15ba97187715e4b84bc776fe86db86d0f8140bb1"
>  
>  # Developer mode enables debugging
>  PACKAGECONFIG[developer-mode] = 
> "-Ddeveloper_mode=true,-Ddeveloper_mode=false"
> -- 
> 2.34.1
> 

> 
> 
> 


-- 
Alexandre Belloni, co-owner and COO, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179162): 
https://lists.openembedded.org/g/openembedded-core/message/179162
Mute This Topic: https://lists.openembedded.org/mt/97836713/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] oeqa/selftest/imagefeatures: set a test for mutliubi in test_image_fstypes

[Romuald Jeanne via lists.openembedded.org]

From: Romuald Jeanne 

Allow 'multiubi' fstype image.
Set 'MULTIUBI_BUILD' with two entries to allow configuration for two
different '.ubifs'.
Configure 'MKUBIFS_ARGS_*' and 'UBINIZE_ARGS_*' for both configurations.

Signed-off-by: Romuald Jeanne 
---
 meta/lib/oeqa/selftest/cases/imagefeatures.py | 25 +++
 1 file changed, 20 insertions(+), 5 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/imagefeatures.py 
b/meta/lib/oeqa/selftest/cases/imagefeatures.py
index 3dc750594c7..d31b43d9cc1 100644
--- a/meta/lib/oeqa/selftest/cases/imagefeatures.py
+++ b/meta/lib/oeqa/selftest/cases/imagefeatures.py
@@ -199,7 +199,7 @@ class ImageFeatures(OESelftestTestCase):
 image = 'core-image-minimal'
 
 all_image_types = set(get_bb_var("IMAGE_TYPES", image).split())
-skip_image_types = set(('container', 'elf', 'f2fs', 'multiubi', 
'tar.zst', 'wic.zst', 'squashfs-lzo'))
+skip_image_types = set(('container', 'elf', 'f2fs', 'tar.zst', 
'wic.zst', 'squashfs-lzo'))
 img_types = all_image_types - skip_image_types
 
 config = """
@@ -207,16 +207,31 @@ IMAGE_FSTYPES += "%s"
 WKS_FILE = "wictestdisk.wks"
 MKUBIFS_ARGS ?= "-m 2048 -e 129024 -c 2047"
 UBINIZE_ARGS ?= "-m 2048 -p 128KiB -s 512"
+MULTIUBI_BUILD += "mtd_2_128"
+MKUBIFS_ARGS_mtd_2_128 ?= "-m 2048 -e 129024 -c 2047"
+UBINIZE_ARGS_mtd_2_128 ?= "-m 2048 -p 128KiB -s 512"
+MULTIUBI_BUILD += "mtd_4_256"
+MKUBIFS_ARGS_mtd_4_256 ?= "-m 4096 -e 253952 -c 4096"
+UBINIZE_ARGS_mtd_4_256 ?= "-m 4096 -p 256KiB"
 """ % ' '.join(img_types)
 self.write_config(config)
 
 bitbake(image)
-bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_LINK_NAME'], image)
+bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_LINK_NAME', 
'MULTIUBI_BUILD'], image)
 
 for itype in img_types:
-image_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s.%s" % 
(bb_vars['IMAGE_LINK_NAME'], itype))
-# check if result image is in deploy directory
-self.assertTrue(os.path.exists(image_path),
+if itype == 'multiubi':
+# For multiubi build we need to manage MULTIUBI_BUILD entry to 
append
+# specific name to IMAGE_LINK_NAME
+for vname in bb_vars['MULTIUBI_BUILD'].split():
+image_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], 
"%s_%s.ubifs" % (bb_vars['IMAGE_LINK_NAME'], vname))
+# check if result image is in deploy directory
+self.assertTrue(os.path.exists(image_path),
+"%s image %s doesn't exist" % (itype, 
image_path))
+else:
+   image_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], "%s.%s" 
% (bb_vars['IMAGE_LINK_NAME'], itype))
+   # check if result image is in deploy directory
+   self.assertTrue(os.path.exists(image_path),
 "%s image %s doesn't exist" % (itype, image_path))
 
 def test_useradd_static(self):
-- 
2.17.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179163): 
https://lists.openembedded.org/g/openembedded-core/message/179163
Mute This Topic: https://lists.openembedded.org/mt/97883245/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/5] Extend cargo based recip support

[Alexander Kanavin]

So if devtool tests would operate on zvariant recipe, then the recipe
can simply go into meta-selftest after all :)

Alex

On Mon, 27 Mar 2023 at 16:20, Richard Purdie
 wrote:
>
> On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> > From: Frederic Martinsons 
> >
> > This series brings the support of local git repository inside
> > a cargo based recipe.
> >
> > It also enable devtool capacity on it and provide a real crate
> > example recipe to show how things are done.
> >
> > The following changes since commit 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> >
> >   xcb-proto: Fix install conflict when enable multilib. (2023-03-23 
> > 22:38:41 +)
> >
> > are available in the Git repository at:
> >
> >   https://gitlab.com/fmartinsons/openembedded-core 
> > cargo-extend-support-git-and-devtool
> >
> > Alex Kiernan (1):
> >   cargo_common.bbclass: Support local github repos
> >
> > Frederic Martinsons (4):
> >   cargo_common.bbclass: add support of user in url for patch
> >   rust-example: provide a recipe for zvariant
> >   devtool: add support for multiple git url inside a cargo based recipe
> >   patch: support of git patches when the source uri contained subpath
> > param
>
> The various rust/cargo/crate patches look like they're heading in a
> good direction, thanks!
>
> The one thing which I think is missing is more support for testing some
> of these changes in our automated testing.
>
> In particular, devtool does have a decent test suite so we should
> ensure new devtool additions have tests.
>
> You can see the devtools tests in
> meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
> like "oe-selftest -r devtool -j 3" for example.
>
> Cheers,
>
> Richard
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179161): 
https://lists.openembedded.org/g/openembedded-core/message/179161
Mute This Topic: https://lists.openembedded.org/mt/97840361/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/5] Extend cargo based recip support

[Richard Purdie]

On Sat, 2023-03-25 at 10:00 +0100, Frederic Martinsons wrote:
> From: Frederic Martinsons 
> 
> This series brings the support of local git repository inside
> a cargo based recipe.
> 
> It also enable devtool capacity on it and provide a real crate
> example recipe to show how things are done.
> 
> The following changes since commit 4876189dd2ae5a04a296b11b537b9f613159c6bf:
> 
>   xcb-proto: Fix install conflict when enable multilib. (2023-03-23 22:38:41 
> +)
> 
> are available in the Git repository at:
> 
>   https://gitlab.com/fmartinsons/openembedded-core 
> cargo-extend-support-git-and-devtool
> 
> Alex Kiernan (1):
>   cargo_common.bbclass: Support local github repos
> 
> Frederic Martinsons (4):
>   cargo_common.bbclass: add support of user in url for patch
>   rust-example: provide a recipe for zvariant
>   devtool: add support for multiple git url inside a cargo based recipe
>   patch: support of git patches when the source uri contained subpath
> param

The various rust/cargo/crate patches look like they're heading in a
good direction, thanks!

The one thing which I think is missing is more support for testing some
of these changes in our automated testing.

In particular, devtool does have a decent test suite so we should
ensure new devtool additions have tests.

You can see the devtools tests in
meta/lib/oeqa/selftest/cases/devtool.py and run them with a command
like "oe-selftest -r devtool -j 3" for example.

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179160): 
https://lists.openembedded.org/g/openembedded-core/message/179160
Mute This Topic: https://lists.openembedded.org/mt/97840361/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][PATCH v2 1/2] QEMU: CVE-2022-4144 QXL: qxl_phys2virt unsafe address translation can lead to out-of-bounds read

[Steve Sakoman]

We already seem to have a version of this patch in dunfell:

https://git.openembedded.org/openembedded-core/commit/?h=dunfell&id=754cce68614c7985d5848134635a6b318f4505ab

If you have corrections to the above patch, please submit a patch with
those corrections.

Thanks!

Steve


On Sat, Mar 25, 2023 at 4:42 AM Kai Kang  wrote:
>
> From: Hitendra Prajapati 
>
> Upstream-Status: Backport from 
> https://gitlab.com/qemu-project/qemu/-/commit/6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622
>
> Signed-off-by: Hitendra Prajapati 
> Signed-off-by: Steve Sakoman 
>
> Replace the tabs with spaces to correct the indent.
>
> Signed-off-by: Kai Kang 
> ---
>  meta/recipes-devtools/qemu/qemu.inc   |   9 +-
>  .../qemu/qemu/CVE-2022-4144.patch | 103 ++
>  2 files changed, 108 insertions(+), 4 deletions(-)
>  create mode 100644 meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
>
> diff --git a/meta/recipes-devtools/qemu/qemu.inc 
> b/meta/recipes-devtools/qemu/qemu.inc
> index 36d0b9320f..0649727338 100644
> --- a/meta/recipes-devtools/qemu/qemu.inc
> +++ b/meta/recipes-devtools/qemu/qemu.inc
> @@ -112,10 +112,11 @@ SRC_URI = 
> "https://download.qemu.org/${BPN}-${PV}.tar.xz \
> file://CVE-2022-0216-1.patch \
> file://CVE-2022-0216-2.patch \
> file://CVE-2021-3750.patch \
> -  file://CVE-2021-3638.patch \
> -  file://CVE-2021-20196.patch \
> -  file://CVE-2021-3507.patch \
> -  file://CVE-2021-3929.patch \
> +   file://CVE-2021-3638.patch \
> +   file://CVE-2021-20196.patch \
> +   file://CVE-2021-3507.patch \
> +   file://CVE-2021-3929.patch \
> +   file://CVE-2022-4144.patch \
> "
>  UPSTREAM_CHECK_REGEX = "qemu-(?P\d+(\.\d+)+)\.tar"
>
> diff --git a/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch 
> b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
> new file mode 100644
> index 00..3f0d5fbd5c
> --- /dev/null
> +++ b/meta/recipes-devtools/qemu/qemu/CVE-2022-4144.patch
> @@ -0,0 +1,103 @@
> +From 6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622 Mon Sep 17 00:00:00 2001
> +From: =?UTF-8?q?Philippe=20Mathieu-Daud=C3=A9?= 
> +Date: Mon, 28 Nov 2022 21:27:40 +0100
> +Subject: [PATCH] hw/display/qxl: Avoid buffer overrun in qxl_phys2virt
> + (CVE-2022-4144)
> +MIME-Version: 1.0
> +Content-Type: text/plain; charset=UTF-8
> +Content-Transfer-Encoding: 8bit
> +
> +Have qxl_get_check_slot_offset() return false if the requested
> +buffer size does not fit within the slot memory region.
> +
> +Similarly qxl_phys2virt() now returns NULL in such case, and
> +qxl_dirty_one_surface() aborts.
> +
> +This avoids buffer overrun in the host pointer returned by
> +memory_region_get_ram_ptr().
> +
> +Fixes: CVE-2022-4144 (out-of-bounds read)
> +Reported-by: Wenxu Yin (@awxylitol)
> +Resolves: https://gitlab.com/qemu-project/qemu/-/issues/1336
> +
> +Signed-off-by: Philippe Mathieu-Daudé 
> +Signed-off-by: Stefan Hajnoczi 
> +Message-Id: <20221128202741.4945-5-phi...@linaro.org>
> +
> +Upstream-Status: Backport 
> [https://gitlab.com/qemu-project/qemu/-/commit/6dbbf055148c6f1b7d8a3251a65bd6f3d1e1f622]
> +CVE: CVE-2022-4144
> +Comments: Deleted patch hunk in qxl.h,as it contains change
> +in comments which is not present in current version of qemu.
> +
> +Signed-off-by: Hitendra Prajapati 
> +---
> + hw/display/qxl.c | 27 +++
> + 1 file changed, 23 insertions(+), 4 deletions(-)
> +
> +diff --git a/hw/display/qxl.c b/hw/display/qxl.c
> +index cd7eb39d..6bc8385b 100644
> +--- a/hw/display/qxl.c
>  b/hw/display/qxl.c
> +@@ -1440,11 +1440,13 @@ static void qxl_reset_surfaces(PCIQXLDevice *d)
> +
> + /* can be also called from spice server thread context */
> + static bool qxl_get_check_slot_offset(PCIQXLDevice *qxl, QXLPHYSICAL pqxl,
> +-  uint32_t *s, uint64_t *o)
> ++  uint32_t *s, uint64_t *o,
> ++  size_t size_requested)
> + {
> + uint64_t phys   = le64_to_cpu(pqxl);
> + uint32_t slot   = (phys >> (64 -  8)) & 0xff;
> + uint64_t offset = phys & 0x;
> ++uint64_t size_available;
> +
> + if (slot >= NUM_MEMSLOTS) {
> + qxl_set_guest_bug(qxl, "slot too large %d >= %d", slot,
> +@@ -1468,6 +1470,23 @@ static bool qxl_get_check_slot_offset(PCIQXLDevice 
> *qxl, QXLPHYSICAL pqxl,
> +   slot, offset, qxl->guest_slots[slot].size);
> + return false;
> + }
> ++size_available = memory_region_size(qxl->guest_slots[slot].mr);
> ++if (qxl->guest_slots[slot].offset + offset >= size_available) {
> ++qxl_set_guest_bug(qxl,
> ++  "slot %d offset %"PRIu64" > region size 
> %"PRIu64"\n",
> ++  slot, qxl->guest_slots[slot].offset + offset,
> ++  size_available);
> ++return false;
> ++}
> ++size_av

[OE-core] [PATCH] go: fix CVE-2023-2453

[Ross Burton]

Backport a security fix, can be removed once we have 1.20.2 onwards.

Signed-off-by: Ross Burton 
---
 meta/recipes-devtools/go/go-1.20.1.inc|   1 +
 .../go/go/CVE-2023-24532.patch| 208 ++
 2 files changed, 209 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go/CVE-2023-24532.patch

diff --git a/meta/recipes-devtools/go/go-1.20.1.inc 
b/meta/recipes-devtools/go/go-1.20.1.inc
index ffde7ed7324..b1f569212db 100644
--- a/meta/recipes-devtools/go/go-1.20.1.inc
+++ b/meta/recipes-devtools/go/go-1.20.1.inc
@@ -15,5 +15,6 @@ SRC_URI += "\
 file://0008-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \
 file://0009-go-Filter-build-paths-on-staticly-linked-arches.patch \
 file://0010-cmd-compile-re-compile-instantiated-generic-methods-.patch \
+file://CVE-2023-24532.patch \
 "
 SRC_URI[main.sha256sum] = 
"b5c1a3af52c385a6d1c76aed5361cf26459023980d0320de7658bae3915831a2"
diff --git a/meta/recipes-devtools/go/go/CVE-2023-24532.patch 
b/meta/recipes-devtools/go/go/CVE-2023-24532.patch
new file mode 100644
index 000..22f080dbd4b
--- /dev/null
+++ b/meta/recipes-devtools/go/go/CVE-2023-24532.patch
@@ -0,0 +1,208 @@
+From 602eeaab387f24a4b28c5eccbb50fa934f3bc3c4 Mon Sep 17 00:00:00 2001
+From: Filippo Valsorda 
+Date: Mon, 13 Feb 2023 15:16:27 +0100
+Subject: [PATCH] [release-branch.go1.20] crypto/internal/nistec: reduce P-256
+ scalar
+
+Unlike the rest of nistec, the P-256 assembly doesn't use complete
+addition formulas, meaning that p256PointAdd[Affine]Asm won't return the
+correct value if the two inputs are equal.
+
+This was (undocumentedly) ignored in the scalar multiplication loops
+because as long as the input point is not the identity and the scalar is
+lower than the order of the group, the addition inputs can't be the same.
+
+As part of the math/big rewrite, we went however from always reducing
+the scalar to only checking its length, under the incorrect assumption
+that the scalar multiplication loop didn't require reduction.
+
+Added a reduction, and while at it added it in P256OrdInverse, too, to
+enforce a universal reduction invariant on p256OrdElement values.
+
+Note that if the input point is the infinity, the code currently still
+relies on undefined behavior, but that's easily tested to behave
+acceptably, and will be addressed in a future CL.
+
+Updates #58647
+Fixes #58720
+Fixes CVE-2023-24532
+
+(Filed with the "safe APIs like complete addition formulas are good" dept.)
+
+Change-Id: I7b2c75238440e6852be2710fad66ff1fdc4e2b24
+Reviewed-on: https://go-review.googlesource.com/c/go/+/471255
+TryBot-Result: Gopher Robot 
+Reviewed-by: Roland Shoemaker 
+Run-TryBot: Filippo Valsorda 
+Auto-Submit: Filippo Valsorda 
+Reviewed-by: Damien Neil 
+(cherry picked from commit 203e59ad41bd288e1d92b6f617c2f55e70d3c8e3)
+Reviewed-on: https://go-review.googlesource.com/c/go/+/471695
+Reviewed-by: Dmitri Shuralyov 
+Auto-Submit: Dmitri Shuralyov 
+Reviewed-by: Filippo Valsorda 
+Run-TryBot: Roland Shoemaker 
+
+CVE: CVE-2023-24532
+Upstream-Status: Backport [602eeaab387f24a4b28c5eccbb50fa934f3bc3c4]
+Signed-off-by: Ross Burton 
+
+---
+ src/crypto/internal/nistec/nistec_test.go | 81 +++
+ src/crypto/internal/nistec/p256_asm.go| 17 +
+ src/crypto/internal/nistec/p256_ordinv.go |  1 +
+ 3 files changed, 99 insertions(+)
+
+diff --git a/src/crypto/internal/nistec/nistec_test.go 
b/src/crypto/internal/nistec/nistec_test.go
+index 309f68be16a9f..9103608c18a0f 100644
+--- a/src/crypto/internal/nistec/nistec_test.go
 b/src/crypto/internal/nistec/nistec_test.go
+@@ -8,6 +8,7 @@ import (
+   "bytes"
+   "crypto/elliptic"
+   "crypto/internal/nistec"
++  "fmt"
+   "internal/testenv"
+   "math/big"
+   "math/rand"
+@@ -165,6 +166,86 @@ func testEquivalents[P nistPoint[P]](t *testing.T, 
newPoint func() P, c elliptic
+   }
+ }
+ 
++func TestScalarMult(t *testing.T) {
++  t.Run("P224", func(t *testing.T) {
++  testScalarMult(t, nistec.NewP224Point, elliptic.P224())
++  })
++  t.Run("P256", func(t *testing.T) {
++  testScalarMult(t, nistec.NewP256Point, elliptic.P256())
++  })
++  t.Run("P384", func(t *testing.T) {
++  testScalarMult(t, nistec.NewP384Point, elliptic.P384())
++  })
++  t.Run("P521", func(t *testing.T) {
++  testScalarMult(t, nistec.NewP521Point, elliptic.P521())
++  })
++}
++
++func testScalarMult[P nistPoint[P]](t *testing.T, newPoint func() P, c 
elliptic.Curve) {
++  G := newPoint().SetGenerator()
++  checkScalar := func(t *testing.T, scalar []byte) {
++  p1, err := newPoint().ScalarBaseMult(scalar)
++  fatalIfErr(t, err)
++  p2, err := newPoint().ScalarMult(G, scalar)
++  fatalIfErr(t, err)
++  if !bytes.Equal(p1.Bytes(), p2.Bytes()) {
++  t.Error("[k]G != ScalarBaseMult(k)")
++  }
+

[OE-core] [PATCH] libunwind: fix compile failures on 32-bit arm with Clang 16

[Ross Burton]

Signed-off-by: Ross Burton 
---
 ...-Gtrace-remove-unguarded-print-calls.patch | 52 +++
 .../libunwind/libunwind_1.6.2.bb  |  1 +
 2 files changed, 53 insertions(+)
 create mode 100644 
meta/recipes-support/libunwind/libunwind/0001-src-Gtrace-remove-unguarded-print-calls.patch

diff --git 
a/meta/recipes-support/libunwind/libunwind/0001-src-Gtrace-remove-unguarded-print-calls.patch
 
b/meta/recipes-support/libunwind/libunwind/0001-src-Gtrace-remove-unguarded-print-calls.patch
new file mode 100644
index 000..fdadcd3b25a
--- /dev/null
+++ 
b/meta/recipes-support/libunwind/libunwind/0001-src-Gtrace-remove-unguarded-print-calls.patch
@@ -0,0 +1,52 @@
+From 87d24ee47fd0e0461fca32d17564f21d76cbcb92 Mon Sep 17 00:00:00 2001
+From: Ross Burton 
+Date: Fri, 24 Mar 2023 16:18:44 +
+Subject: [PATCH] src/Gtrace: remove unguarded print() calls
+
+There is a use of printf() without #include stdio.h in src/arm/Gtrace.c,
+which results in a compiler error if clang 16 is used:
+
+src/arm/Gtrace.c:529:7: error: call to undeclared library function
+'printf' with type 'int (const char *, ...)'; ISO C99 and later do not
+support implicit function declarations [-Wimplicit-function-declaration]
+
+Replace the printf("XXX") with a Dprintf, so it doesn't pull stdio in
+unless in a debug build, and reword the message to be clearer.
+
+Also there is another printf("XXX") inside a FreeBSD-specific block in
+the UNW_ARM_FRAME_SIGRETURN case, replace this with a #error as the code
+needs to be implemented.
+
+Fixes #482.
+
+Upstream-Status: Submitted [https://github.com/libunwind/libunwind/pull/483]
+Signed-off-by: Ross Burton 
+---
+ src/arm/Gtrace.c | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git a/src/arm/Gtrace.c b/src/arm/Gtrace.c
+index 51fc281d..9e0f25af 100644
+--- a/src/arm/Gtrace.c
 b/src/arm/Gtrace.c
+@@ -514,7 +514,7 @@ tdep_trace (unw_cursor_t *cursor, void **buffer, int *size)
+   if (likely(ret >= 0))
+ ACCESS_MEM_FAST(ret, c->validate, d, cfa + LINUX_SC_LR_OFF, lr);
+ #elif defined(__FreeBSD__)
+-  printf("XXX\n");
++  #error implement UNW_ARM_FRAME_SIGRETURN on FreeBSD
+ #endif
+ 
+   /* Resume stack at signal restoration point. The stack is not
+@@ -526,7 +526,7 @@ tdep_trace (unw_cursor_t *cursor, void **buffer, int *size)
+   break;
+ 
+ case UNW_ARM_FRAME_SYSCALL:
+-  printf("XXX1\n");
++  Dprintf ("%s: implement me\n", __FUNCTION__);
+   break;
+ 
+ default:
+-- 
+2.34.1
+
diff --git a/meta/recipes-support/libunwind/libunwind_1.6.2.bb 
b/meta/recipes-support/libunwind/libunwind_1.6.2.bb
index 716be9a452f..d67862608c1 100644
--- a/meta/recipes-support/libunwind/libunwind_1.6.2.bb
+++ b/meta/recipes-support/libunwind/libunwind_1.6.2.bb
@@ -5,6 +5,7 @@ SRC_URI = 
"http://download.savannah.nongnu.org/releases/libunwind/libunwind-${PV
file://0004-Fix-build-on-mips-musl.patch \

file://0005-ppc32-Consider-ucontext-mismatches-between-glibc-and.patch \
file://0006-Fix-for-X32.patch \
+   file://0001-src-Gtrace-remove-unguarded-print-calls.patch \
"
 SRC_URI:append:libc-musl = " file://musl-header-conflict.patch"
 
-- 
2.34.1


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

Re: [yocto-security] [OE-core] OE-core CVE metrics for master on Sun 26 Mar 2023 02:00:01 AM HST

[Ross Burton]

>> CVE-2023-0330 (CVSS3: 9.8 CRITICAL): qemu:qemu-native:qemu-system-native 
>> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0330 *
> 
> Very niche from what I can tell, but the patch on the list is simple, testing 
> now.

Update: there’s an alternative patch series which is likely merged instead: 
https://lore.kernel.org/qemu-devel/20230324113725.xsnbqvzo6rsza...@mozz.bu.edu/

I suspect none of our machines use this device so this isn’t an urgent fix.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179156): 
https://lists.openembedded.org/g/openembedded-core/message/179156
Mute This Topic: https://lists.openembedded.org/mt/97879841/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] OE-core CVE metrics for master on Sun 26 Mar 2023 02:00:01 AM HST

[Ross Burton]

On 26 Mar 2023, at 13:03, Steve Sakoman via lists.openembedded.org 
 wrote:
> CVE-2005-1796 (CVSS3: N/A): ncurses:ncurses-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2005-1796 *

Still waiting for NIST to update the CPE.

> CVE-2022-3219 (CVSS3: 5.5 MEDIUM): gnupg:gnupg-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-3219 *

Upstream don’t consider this an attack, just slow processing, and have marked 
it as low priority.

> CVE-2022-4055 (CVSS3: 7.4 HIGH): xdg-utils 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-4055 *
> CVE-2022-46456 (CVSS3: 6.1 MEDIUM): nasm:nasm-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2022-46456 *

Both still open upstream.

> CVE-2023-0330 (CVSS3: 9.8 CRITICAL): qemu:qemu-native:qemu-system-native 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-0330 *

Very niche from what I can tell, but the patch on the list is simple, testing 
now.

> CVE-2023-24532 (CVSS3: 5.3 MEDIUM): 
> go:go-binary-native:go-cross-core2-64:go-runtime 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-24532 *

Patch testing now.

> CVE-2023-28531 (CVSS3: 9.8 CRITICAL): openssh 
> https://web.nvd.nist.gov/view/vuln/detail?vulnId=CVE-2023-28531 *

Upgrade patch already on the list.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179155): 
https://lists.openembedded.org/g/openembedded-core/message/179155
Mute This Topic: https://lists.openembedded.org/mt/97860065/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/5] rust-example: provide a recipe for zvariant

[Alex Kiernan]

On Mon, Mar 27, 2023 at 9:52 AM Frédéric Martinsons
 wrote:
>
> True, no rust project will ever DEPENDS on the zvariant recipe and as you said
> will simply list zvariant as a crate.
> My main concern with the example was to address this comment: 
> https://patchwork.yoctoproject.org/project/oe-core/patch/20221030173815.10212-2-alex.kier...@gmail.com/#6450
>
> So , do you think it's still worth providing such an example ? and if yes, 
> can I place it
> in meta-openembedded/meta-oe/recipes-extended/ ?
>

I think it definitely has value for this problem - the examples I had
were either synthetic, or internal.

>
>
> On Mon, 27 Mar 2023 at 10:42, Alex Kiernan  wrote:
>>
>> I think modelling meta-rust on meta-python is wrong - rust doesn't
>> package crates, they get consumed into the main recipe (which I've
>> just realised means I think we have some work on licensing to do).
>>
>> For this example, I think it's just a regular recipe which should sit
>> alongside other recipes in meta-oe; anyone who wants to consume
>> zvariant is going to list it as part of their Cargo.toml, not DEPEND
>> on this recipe.
>>
>> I guess I'm really arguing that meta-rust is purely a legacy thing at
>> this point (one which I continue to need and maintain a fork of!).
>>
>> On Mon, Mar 27, 2023 at 9:30 AM Frédéric Martinsons
>>  wrote:
>> >
>> > There is a stalled merge request for this clean: 
>> > https://github.com/meta-rust/meta-rust/pull/364
>> >
>> > But I think Alex is right, all needed things for rust/cargo projects seem 
>> > to be already in oe-core except
>> > for examples of recipes.
>> >
>> > What about adding meta-rust in meta-openembedded which will contains the 
>> > example, something like
>> >
>> > meta-rust/
>> > ├── conf
>> > │   └── layer.conf
>> > ├── COPYING.MIT
>> > ├── README
>> > └── recipes-extended
>> > ├── zvariant
>> > │   └── 0001-Tweak-zvariant-cargo-config.patch
>> > ├── zvariant_3.12.0.bb
>> > └── zvariant-crates.inc
>> >
>> >
>> > On Mon, 27 Mar 2023 at 10:19, Alex Kiernan  wrote:
>> >>
>> >> If you're on master I don't think there's anything useful in meta-rust
>> >> - its providing toolchains for older branches.
>> >>
>> >> On Mon, Mar 27, 2023 at 7:40 AM Alexander Kanavin
>> >>  wrote:
>> >> >
>> >> > You could meanwhile review meta-rust, and see what is useful and what
>> >> > is obsolete perhaps? I see it still carries toolchain recipes for
>> >> > example, I have no idea why.
>> >> >
>> >> > Alex
>> >> >
>> >> > On Mon, 27 Mar 2023 at 06:09, Frédéric Martinsons
>> >> >  wrote:
>> >> > >
>> >> > > Ok, should I work on this cleaning of meta-rust and merging in 
>> >> > > meta-oe ? or should I wait for other opinions ?
>> >> > >
>> >> > > On Sun, 26 Mar 2023 at 18:55, Alexander Kanavin 
>> >> > >  wrote:
>> >> > >>
>> >> > >> rust-hello-world is installed into test images, and has a runtime 
>> >> > >> test
>> >> > >> to verify that the toolchain produces working binaries:
>> >> > >> meta/lib/oeqa/runtime/cases/rust.py
>> >> > >>
>> >> > >> I thought meta-rust could be cleaned up, and added to meta-oe 
>> >> > >> perhaps?
>> >> > >> Same as meta-perl/meta-python.
>> >> > >> https://github.com/meta-rust/meta-rust
>> >> > >>
>> >> > >> Alex
>> >> > >>
>> >> > >> On Sat, 25 Mar 2023 at 21:43, Frédéric Martinsons
>> >> > >>  wrote:
>> >> > >> >
>> >> > >> > I thought that would be treated the same as 
>> >> > >> > rust-hello-world_git.bb which is in oe-core.
>> >> > >> >
>> >> > >> > Anyway, I don't mind placing it elsewhere, which layer do you 
>> >> > >> > think this recipe would land?
>> >> > >> >
>> >> > >> >
>> >> > >> >
>> >> > >> > Le sam. 25 mars 2023, 19:52, Alexander Kanavin 
>> >> > >> >  a écrit :
>> >> > >> >>
>> >> > >> >> I don't think this should be going in oe-core, as it's not 
>> >> > >> >> actually
>> >> > >> >> used by anything, or in any automated tests. But you can place it 
>> >> > >> >> in a
>> >> > >> >> separate layer.
>> >> > >> >>
>> >> > >> >> Alex
>> >> > >> >>
>> >> > >> >> On Sat, 25 Mar 2023 at 10:01, Frederic Martinsons
>> >> > >> >>  wrote:
>> >> > >> >> >
>> >> > >> >> > From: Frederic Martinsons 
>> >> > >> >> >
>> >> > >> >> > This recipe is for showing an "real world" example of
>> >> > >> >> > a crate that depends on some git repositories.
>> >> > >> >> >
>> >> > >> >> > Usually, this kind of crate is built within a global
>> >> > >> >> > workspace (here it is the zbus project) and so
>> >> > >> >> > doesn't need a Cargo.lock on its own.
>> >> > >> >> >
>> >> > >> >> > For the sake of the demonstration, I had to add
>> >> > >> >> > a patch for probiding a Cargo.lock and modifying
>> >> > >> >> > zvariant_deriver to get it from crates.io instead
>> >> > >> >> > of pulling locally with a relative path
>> >> > >> >> >
>> >> > >> >> > The use case where the crate had some git repository
>> >> > >> >> > in dependency is very common for "private" crate that
>> >> > >> >> > are not aimed to be published on crate.io.
>> >> > >> >> > When the proj

[oe-core][PATCH] python3: Fix failing sysconfig.py test on x86(64 bit) using lib64 as baselib by updating test_sysconfig for posix_user purelib

[Wentao Zhang]

Steps to trigger the failed test:
Edit local.conf to add something as follows:
BASELIB = "lib64"
IMAGE_INSTALL:append = " python3-tests".
bitbake core-image-sato
runqemu qemux86-64 nographic slirp
Reproducer:
$python3 -m test test_sysconfig

sysconfig.py use platlibdir for purelib. Update
test_sysconfig.test_user_similar() for the posix_user
scheme: "purelib" doesn't use sys.platlibdir.

Signed-off-by: Wentao Zhang 
---
 ...est_sysconfig-for-posix_user-purelib.patch | 30 +++
 .../recipes-devtools/python/python3_3.11.2.bb |  1 +
 2 files changed, 31 insertions(+)
 create mode 100644 
meta/recipes-devtools/python/python3/0001-Update-test_sysconfig-for-posix_user-purelib.patch

diff --git 
a/meta/recipes-devtools/python/python3/0001-Update-test_sysconfig-for-posix_user-purelib.patch
 
b/meta/recipes-devtools/python/python3/0001-Update-test_sysconfig-for-posix_user-purelib.patch
new file mode 100644
index 00..3d39839309
--- /dev/null
+++ 
b/meta/recipes-devtools/python/python3/0001-Update-test_sysconfig-for-posix_user-purelib.patch
@@ -0,0 +1,30 @@
+From b9f825b298b555c4770024d1f68ef1df65aad20a Mon Sep 17 00:00:00 2001
+From: Wentao Zhang 
+Date: Mon, 20 Mar 2023 13:39:52 +0800
+Subject: [PATCH] Update test_sysconfig for posix_user purelib
+
+Update test_sysconfig.test_user_similar() for the posix_user scheme:
+"purelib" doesn't use sys.platlibdir.
+
+Upstream-Status: Inappropriate [oe-core specific]
+Signed-off-by: Wentao Zhang 
+---
+ Lib/test/test_sysconfig.py | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/Lib/test/test_sysconfig.py b/Lib/test/test_sysconfig.py
+index d96371d..20aea4b 100644
+--- a/Lib/test/test_sysconfig.py
 b/Lib/test/test_sysconfig.py
+@@ -373,7 +373,7 @@ class TestSysConfig(unittest.TestCase):
+ expected = os.path.normpath(global_path.replace(base, user, 
1))
+ # bpo-44860: platlib of posix_user doesn't use sys.platlibdir,
+ # whereas posix_prefix does.
+-if name == 'platlib':
++if name == 'platlib' or name == 'purelib':
+ # Replace "/lib64/python3.11/site-packages" suffix
+ # with "/lib/python3.11/site-packages".
+ py_version_short = sysconfig.get_python_version()
+-- 
+2.25.1
+
diff --git a/meta/recipes-devtools/python/python3_3.11.2.bb 
b/meta/recipes-devtools/python/python3_3.11.2.bb
index 43c147ca6d..f67012c083 100644
--- a/meta/recipes-devtools/python/python3_3.11.2.bb
+++ b/meta/recipes-devtools/python/python3_3.11.2.bb
@@ -31,6 +31,7 @@ SRC_URI = 
"http://www.python.org/ftp/python/${PV}/Python-${PV}.tar.xz \

file://0001-setup.py-Do-not-detect-multiarch-paths-when-cross-co.patch \
file://deterministic_imports.patch \
file://0001-Avoid-shebang-overflow-on-python-config.py.patch \
+   file://0001-Update-test_sysconfig-for-posix_user-purelib.patch \
"
 
 SRC_URI:append:class-native = " \
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179153): 
https://lists.openembedded.org/g/openembedded-core/message/179153
Mute This Topic: https://lists.openembedded.org/mt/97878203/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] [PATCHV2 3/5] rust-example: provide a recipe for zvariant

[Frederic Martinsons]

There is an ongoing discussion about the place for this recipe. When it
wil' be clear, I'll issue a dedicated patch for this.

In the meantime, I removed this example in the last version of this series
(V3)

Le lun. 27 mars 2023, 11:12, Alexander Kanavin  a
écrit :

> rust-hello-world is actually used in test images to verify that
> toolchains produce working binaries.
>
> For zvariant I guess meta-skeleton would work best, if the recipe
> comes with a README explaining why is it there, and how to handle
> maintenance of similar recipes.
>
> Alex
>
> On Mon, 27 Mar 2023 at 10:58, Peter Bergin  wrote:
> >
> >
> > On 2023-03-26 16:56, Frederic Martinsons wrote:
> > > From: Frederic Martinsons 
> > >
> > > This recipe is for showing a "real world" example of
> > > a crate that depends on some git repositories.
> > >
> > > Usually, this kind of crate is built within a global
> > > workspace (here it is the zbus project) and so
> > > doesn't need a Cargo.lock on its own.
> > >
> > > For the sake of the demonstration, I had to add
> > > a patch for providing a Cargo.lock and modifying
> > > zvariant_derive to get it from crates.io instead
> > > of pulling locally with a relative path.
> > >
> > > The use case where the crate had some git repository
> > > in dependency is very common for "private" crate that
> > > are not aimed to be published on crates.io.
> > > When the project grow bigger, it is common to have
> > > a bin and multiple lib developped in parallel, and these
> > > libs are surely on a git repostitory.
> > >
> > > Hence the need of this support in oe-core.
> > >
> > > Signed-off-by: Frederic Martinsons 
> > > ---
> > >   .../rust-example/zvariant-crates.inc  |  140 ++
> > >   .../0001-Tweak-zvariant-cargo-config.patch| 1249
> +
> > >   .../rust-example/zvariant_3.12.0.bb   |   20 +
> > >   3 files changed, 1409 insertions(+)
> > >   create mode 100644
> meta/recipes-extended/rust-example/zvariant-crates.inc
> > >   create mode 100644
> meta/recipes-extended/rust-example/zvariant/0001-Tweak-zvariant-cargo-config.patch
> > >   create mode 100644 meta/recipes-extended/rust-example/
> zvariant_3.12.0.bb
> >
> > Why not use meta-skeleton for the examples? I know and have seen before
> > that for some reason the rust-example is placed in oe-core/meta, but
> > think rust-example should have its home in meta-skeleton as it is the
> > place for example recipes. Just a suggestion to move this now before
> > filling up more example recipes among the core recipes.
> >
> > /Peter
> >
> >
> >
> > 
> >
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179152): 
https://lists.openembedded.org/g/openembedded-core/message/179152
Mute This Topic: https://lists.openembedded.org/mt/97862976/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] [PATCHV2 3/5] rust-example: provide a recipe for zvariant

[Alexander Kanavin]

rust-hello-world is actually used in test images to verify that
toolchains produce working binaries.

For zvariant I guess meta-skeleton would work best, if the recipe
comes with a README explaining why is it there, and how to handle
maintenance of similar recipes.

Alex

On Mon, 27 Mar 2023 at 10:58, Peter Bergin  wrote:
>
>
> On 2023-03-26 16:56, Frederic Martinsons wrote:
> > From: Frederic Martinsons 
> >
> > This recipe is for showing a "real world" example of
> > a crate that depends on some git repositories.
> >
> > Usually, this kind of crate is built within a global
> > workspace (here it is the zbus project) and so
> > doesn't need a Cargo.lock on its own.
> >
> > For the sake of the demonstration, I had to add
> > a patch for providing a Cargo.lock and modifying
> > zvariant_derive to get it from crates.io instead
> > of pulling locally with a relative path.
> >
> > The use case where the crate had some git repository
> > in dependency is very common for "private" crate that
> > are not aimed to be published on crates.io.
> > When the project grow bigger, it is common to have
> > a bin and multiple lib developped in parallel, and these
> > libs are surely on a git repostitory.
> >
> > Hence the need of this support in oe-core.
> >
> > Signed-off-by: Frederic Martinsons 
> > ---
> >   .../rust-example/zvariant-crates.inc  |  140 ++
> >   .../0001-Tweak-zvariant-cargo-config.patch| 1249 +
> >   .../rust-example/zvariant_3.12.0.bb   |   20 +
> >   3 files changed, 1409 insertions(+)
> >   create mode 100644 meta/recipes-extended/rust-example/zvariant-crates.inc
> >   create mode 100644 
> > meta/recipes-extended/rust-example/zvariant/0001-Tweak-zvariant-cargo-config.patch
> >   create mode 100644 meta/recipes-extended/rust-example/zvariant_3.12.0.bb
>
> Why not use meta-skeleton for the examples? I know and have seen before
> that for some reason the rust-example is placed in oe-core/meta, but
> think rust-example should have its home in meta-skeleton as it is the
> place for example recipes. Just a suggestion to move this now before
> filling up more example recipes among the core recipes.
>
> /Peter
>
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179151): 
https://lists.openembedded.org/g/openembedded-core/message/179151
Mute This Topic: https://lists.openembedded.org/mt/97862976/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] [PATCHV2 3/5] rust-example: provide a recipe for zvariant

[Peter Bergin]

On 2023-03-26 16:56, Frederic Martinsons wrote:

From: Frederic Martinsons 

This recipe is for showing a "real world" example of
a crate that depends on some git repositories.

Usually, this kind of crate is built within a global
workspace (here it is the zbus project) and so
doesn't need a Cargo.lock on its own.

For the sake of the demonstration, I had to add
a patch for providing a Cargo.lock and modifying
zvariant_derive to get it from crates.io instead
of pulling locally with a relative path.

The use case where the crate had some git repository
in dependency is very common for "private" crate that
are not aimed to be published on crates.io.
When the project grow bigger, it is common to have
a bin and multiple lib developped in parallel, and these
libs are surely on a git repostitory.

Hence the need of this support in oe-core.

Signed-off-by: Frederic Martinsons 
---
  .../rust-example/zvariant-crates.inc  |  140 ++
  .../0001-Tweak-zvariant-cargo-config.patch| 1249 +
  .../rust-example/zvariant_3.12.0.bb   |   20 +
  3 files changed, 1409 insertions(+)
  create mode 100644 meta/recipes-extended/rust-example/zvariant-crates.inc
  create mode 100644 
meta/recipes-extended/rust-example/zvariant/0001-Tweak-zvariant-cargo-config.patch
  create mode 100644 meta/recipes-extended/rust-example/zvariant_3.12.0.bb


Why not use meta-skeleton for the examples? I know and have seen before 
that for some reason the rust-example is placed in oe-core/meta, but 
think rust-example should have its home in meta-skeleton as it is the 
place for example recipes. Just a suggestion to move this now before 
filling up more example recipes among the core recipes.


/Peter



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179150): 
https://lists.openembedded.org/g/openembedded-core/message/179150
Mute This Topic: https://lists.openembedded.org/mt/97862976/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/5] rust-example: provide a recipe for zvariant

[Alex Kiernan]

I think modelling meta-rust on meta-python is wrong - rust doesn't
package crates, they get consumed into the main recipe (which I've
just realised means I think we have some work on licensing to do).

For this example, I think it's just a regular recipe which should sit
alongside other recipes in meta-oe; anyone who wants to consume
zvariant is going to list it as part of their Cargo.toml, not DEPEND
on this recipe.

I guess I'm really arguing that meta-rust is purely a legacy thing at
this point (one which I continue to need and maintain a fork of!).

On Mon, Mar 27, 2023 at 9:30 AM Frédéric Martinsons
 wrote:
>
> There is a stalled merge request for this clean: 
> https://github.com/meta-rust/meta-rust/pull/364
>
> But I think Alex is right, all needed things for rust/cargo projects seem to 
> be already in oe-core except
> for examples of recipes.
>
> What about adding meta-rust in meta-openembedded which will contains the 
> example, something like
>
> meta-rust/
> ├── conf
> │   └── layer.conf
> ├── COPYING.MIT
> ├── README
> └── recipes-extended
> ├── zvariant
> │   └── 0001-Tweak-zvariant-cargo-config.patch
> ├── zvariant_3.12.0.bb
> └── zvariant-crates.inc
>
>
> On Mon, 27 Mar 2023 at 10:19, Alex Kiernan  wrote:
>>
>> If you're on master I don't think there's anything useful in meta-rust
>> - its providing toolchains for older branches.
>>
>> On Mon, Mar 27, 2023 at 7:40 AM Alexander Kanavin
>>  wrote:
>> >
>> > You could meanwhile review meta-rust, and see what is useful and what
>> > is obsolete perhaps? I see it still carries toolchain recipes for
>> > example, I have no idea why.
>> >
>> > Alex
>> >
>> > On Mon, 27 Mar 2023 at 06:09, Frédéric Martinsons
>> >  wrote:
>> > >
>> > > Ok, should I work on this cleaning of meta-rust and merging in meta-oe ? 
>> > > or should I wait for other opinions ?
>> > >
>> > > On Sun, 26 Mar 2023 at 18:55, Alexander Kanavin  
>> > > wrote:
>> > >>
>> > >> rust-hello-world is installed into test images, and has a runtime test
>> > >> to verify that the toolchain produces working binaries:
>> > >> meta/lib/oeqa/runtime/cases/rust.py
>> > >>
>> > >> I thought meta-rust could be cleaned up, and added to meta-oe perhaps?
>> > >> Same as meta-perl/meta-python.
>> > >> https://github.com/meta-rust/meta-rust
>> > >>
>> > >> Alex
>> > >>
>> > >> On Sat, 25 Mar 2023 at 21:43, Frédéric Martinsons
>> > >>  wrote:
>> > >> >
>> > >> > I thought that would be treated the same as rust-hello-world_git.bb 
>> > >> > which is in oe-core.
>> > >> >
>> > >> > Anyway, I don't mind placing it elsewhere, which layer do you think 
>> > >> > this recipe would land?
>> > >> >
>> > >> >
>> > >> >
>> > >> > Le sam. 25 mars 2023, 19:52, Alexander Kanavin 
>> > >> >  a écrit :
>> > >> >>
>> > >> >> I don't think this should be going in oe-core, as it's not actually
>> > >> >> used by anything, or in any automated tests. But you can place it in 
>> > >> >> a
>> > >> >> separate layer.
>> > >> >>
>> > >> >> Alex
>> > >> >>
>> > >> >> On Sat, 25 Mar 2023 at 10:01, Frederic Martinsons
>> > >> >>  wrote:
>> > >> >> >
>> > >> >> > From: Frederic Martinsons 
>> > >> >> >
>> > >> >> > This recipe is for showing an "real world" example of
>> > >> >> > a crate that depends on some git repositories.
>> > >> >> >
>> > >> >> > Usually, this kind of crate is built within a global
>> > >> >> > workspace (here it is the zbus project) and so
>> > >> >> > doesn't need a Cargo.lock on its own.
>> > >> >> >
>> > >> >> > For the sake of the demonstration, I had to add
>> > >> >> > a patch for probiding a Cargo.lock and modifying
>> > >> >> > zvariant_deriver to get it from crates.io instead
>> > >> >> > of pulling locally with a relative path
>> > >> >> >
>> > >> >> > The use case where the crate had some git repository
>> > >> >> > in dependency is very common for "private" crate that
>> > >> >> > are not aimed to be published on crate.io.
>> > >> >> > When the project grow bigger, it is common to have
>> > >> >> > a bin and multiple lib developped in parallel, and these
>> > >> >> > libs are surely on a git repostitory.
>> > >> >> >
>> > >> >> > Hence the need of this support in oe-core.
>> > >> >> >
>> > >> >> > Signed-off-by: Frederic Martinsons 
>> > >> >> > ---
>> > >> >> >  .../rust-example/zvariant-crates.inc  |  140 ++
>> > >> >> >  .../0001-Tweak-zvariant-cargo-config.patch| 1249 
>> > >> >> > +
>> > >> >> >  .../rust-example/zvariant_3.12.0.bb   |   20 +
>> > >> >> >  3 files changed, 1409 insertions(+)
>> > >> >> >  create mode 100644 
>> > >> >> > meta/recipes-extended/rust-example/zvariant-crates.inc
>> > >> >> >  create mode 100644 
>> > >> >> > meta/recipes-extended/rust-example/zvariant/0001-Tweak-zvariant-cargo-config.patch
>> > >> >> >  create mode 100644 
>> > >> >> > meta/recipes-extended/rust-example/zvariant_3.12.0.bb
>> > >> >> >
>> > >> >> > diff --git 
>> > >> >> > a/meta/recipes-extended/rust-example/zvariant-crates.inc 
>> > >> >> >

[OE-core][master][PATCH] openssh: upgrade 9.2p1 -> 9.3p1

[Siddharth]

From: Siddharth Doshi 

OpenSSH 9.3p1 fixes 1 HIGH level security vulnerability.

Upgrade the recipe to point to 9.3p1.

CVEs Fixed:
1) CVE-2023-28531
- ssh-add in OpenSSH before 9.3 adds smartcard keys to ssh-agent without the 
intended per-hop destination constraints.

Signed-off-by: Siddharth Doshi 
---
 .../openssh/{openssh_9.2p1.bb => openssh_9.3p1.bb}  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-connectivity/openssh/{openssh_9.2p1.bb => 
openssh_9.3p1.bb} (98%)

diff --git a/meta/recipes-connectivity/openssh/openssh_9.2p1.bb 
b/meta/recipes-connectivity/openssh/openssh_9.3p1.bb
similarity index 98%
rename from meta/recipes-connectivity/openssh/openssh_9.2p1.bb
rename to meta/recipes-connectivity/openssh/openssh_9.3p1.bb
index 4666237d68..d3dedd1a5a 100644
--- a/meta/recipes-connectivity/openssh/openssh_9.2p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_9.3p1.bb
@@ -25,7 +25,7 @@ SRC_URI = 
"http://ftp.openbsd.org/pub/OpenBSD/OpenSSH/portable/openssh-${PV}.tar
file://sshd_check_keys \
file://add-test-support-for-busybox.patch \
"
-SRC_URI[sha256sum] = 
"3f66dbf1655fb45f50e1c56da62ab01218c228807b21338d634ebcdf9d71cf46"
+SRC_URI[sha256sum] = 
"e9baba7701a76a51f3d85a62c383a3c9dcd97fa900b859bc7db114c1868af8a8"
 
 # This CVE is specific to OpenSSH with the pam opie which we don't build/use 
here
 CVE_CHECK_IGNORE += "CVE-2007-2768"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179147): 
https://lists.openembedded.org/g/openembedded-core/message/179147
Mute This Topic: https://lists.openembedded.org/mt/97877563/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/5] rust-example: provide a recipe for zvariant

[Alex Kiernan]

If you're on master I don't think there's anything useful in meta-rust
- its providing toolchains for older branches.

On Mon, Mar 27, 2023 at 7:40 AM Alexander Kanavin
 wrote:
>
> You could meanwhile review meta-rust, and see what is useful and what
> is obsolete perhaps? I see it still carries toolchain recipes for
> example, I have no idea why.
>
> Alex
>
> On Mon, 27 Mar 2023 at 06:09, Frédéric Martinsons
>  wrote:
> >
> > Ok, should I work on this cleaning of meta-rust and merging in meta-oe ? or 
> > should I wait for other opinions ?
> >
> > On Sun, 26 Mar 2023 at 18:55, Alexander Kanavin  
> > wrote:
> >>
> >> rust-hello-world is installed into test images, and has a runtime test
> >> to verify that the toolchain produces working binaries:
> >> meta/lib/oeqa/runtime/cases/rust.py
> >>
> >> I thought meta-rust could be cleaned up, and added to meta-oe perhaps?
> >> Same as meta-perl/meta-python.
> >> https://github.com/meta-rust/meta-rust
> >>
> >> Alex
> >>
> >> On Sat, 25 Mar 2023 at 21:43, Frédéric Martinsons
> >>  wrote:
> >> >
> >> > I thought that would be treated the same as rust-hello-world_git.bb 
> >> > which is in oe-core.
> >> >
> >> > Anyway, I don't mind placing it elsewhere, which layer do you think this 
> >> > recipe would land?
> >> >
> >> >
> >> >
> >> > Le sam. 25 mars 2023, 19:52, Alexander Kanavin  
> >> > a écrit :
> >> >>
> >> >> I don't think this should be going in oe-core, as it's not actually
> >> >> used by anything, or in any automated tests. But you can place it in a
> >> >> separate layer.
> >> >>
> >> >> Alex
> >> >>
> >> >> On Sat, 25 Mar 2023 at 10:01, Frederic Martinsons
> >> >>  wrote:
> >> >> >
> >> >> > From: Frederic Martinsons 
> >> >> >
> >> >> > This recipe is for showing an "real world" example of
> >> >> > a crate that depends on some git repositories.
> >> >> >
> >> >> > Usually, this kind of crate is built within a global
> >> >> > workspace (here it is the zbus project) and so
> >> >> > doesn't need a Cargo.lock on its own.
> >> >> >
> >> >> > For the sake of the demonstration, I had to add
> >> >> > a patch for probiding a Cargo.lock and modifying
> >> >> > zvariant_deriver to get it from crates.io instead
> >> >> > of pulling locally with a relative path
> >> >> >
> >> >> > The use case where the crate had some git repository
> >> >> > in dependency is very common for "private" crate that
> >> >> > are not aimed to be published on crate.io.
> >> >> > When the project grow bigger, it is common to have
> >> >> > a bin and multiple lib developped in parallel, and these
> >> >> > libs are surely on a git repostitory.
> >> >> >
> >> >> > Hence the need of this support in oe-core.
> >> >> >
> >> >> > Signed-off-by: Frederic Martinsons 
> >> >> > ---
> >> >> >  .../rust-example/zvariant-crates.inc  |  140 ++
> >> >> >  .../0001-Tweak-zvariant-cargo-config.patch| 1249 
> >> >> > +
> >> >> >  .../rust-example/zvariant_3.12.0.bb   |   20 +
> >> >> >  3 files changed, 1409 insertions(+)
> >> >> >  create mode 100644 
> >> >> > meta/recipes-extended/rust-example/zvariant-crates.inc
> >> >> >  create mode 100644 
> >> >> > meta/recipes-extended/rust-example/zvariant/0001-Tweak-zvariant-cargo-config.patch
> >> >> >  create mode 100644 
> >> >> > meta/recipes-extended/rust-example/zvariant_3.12.0.bb
> >> >> >
> >> >> > diff --git a/meta/recipes-extended/rust-example/zvariant-crates.inc 
> >> >> > b/meta/recipes-extended/rust-example/zvariant-crates.inc
> >> >> > new file mode 100644
> >> >> > index 00..297a784661
> >> >> > --- /dev/null
> >> >> > +++ b/meta/recipes-extended/rust-example/zvariant-crates.inc
> >> >> > @@ -0,0 +1,140 @@
> >> >> > +SRC_URI += " \
> >> >> > +crate://crates.io/anes/0.1.6 \
> >> >> > +crate://crates.io/anyhow/1.0.70 \
> >> >> > +crate://crates.io/arrayvec/0.7.2 \
> >> >> > +crate://crates.io/atty/0.2.14 \
> >> >> > +crate://crates.io/autocfg/1.1.0 \
> >> >> > +crate://crates.io/bitflags/1.3.2 \
> >> >> > +crate://crates.io/bumpalo/3.12.0 \
> >> >> > +crate://crates.io/byteorder/1.4.3 \
> >> >> > +crate://crates.io/cast/0.3.0 \
> >> >> > +crate://crates.io/cfg-if/1.0.0 \
> >> >> > +crate://crates.io/chrono/0.4.24 \
> >> >> > +crate://crates.io/ciborium-io/0.2.0 \
> >> >> > +crate://crates.io/ciborium-ll/0.2.0 \
> >> >> > +crate://crates.io/ciborium/0.2.0 \
> >> >> > +crate://crates.io/clap/3.2.23 \
> >> >> > +crate://crates.io/clap_lex/0.2.4 \
> >> >> > +crate://crates.io/criterion-plot/0.5.0 \
> >> >> > +crate://crates.io/criterion/0.4.0 \
> >> >> > +crate://crates.io/crossbeam-channel/0.5.7 \
> >> >> > +crate://crates.io/crossbeam-deque/0.8.3 \
> >> >> > +crate://crates.io/crossbeam-epoch/0.9.14 \
> >> >> > +crate://crates.io/crossbeam-utils/0.8.15 \
> >> >> > +crate://crates.io/either/1.8.1 \
> >> >> > +crate://crates.io/enumflags2/0.7.5 \
> >> >> > +crate://crates.io/enumflags2_derive/0.7.4 \
>

[OE-core] [PATCHV3 4/4] patch: support of git patches when the source uri contained subpath parameter

[Frederic Martinsons]

From: Frederic Martinsons 

This is for a specific case where:
  - A recipe use a subpath on a git repo (e.g. 
git://repo.git/projects;subpath=subproject)
  - The recipe contains a patch to apply
  - a devtool modify is used on this recipe

With these conditions, the patch cannot be applied at all.
GitApplyTree class is used for handling patch under devtool, but
when subpath is present in SRC_URI, the resulting git tree
is dirty (every files and directories which was not in subpath are suppressed)
and so "git am" refuse to apply patches.

That would not be an issue since the GitApplyTree have a fallback
to PatchTree in case of error, but during this error management,
there is a "git reset --hard HEAD" call which suppress the subpath
operation and finally prevents the patch to be applied even with PatchTree.

When devtool is not involved, only PatchTree class is used and the
above problem is irrelevant.

To support git patching during devtool, the presence of subpath and
the dirtyness of the repo are checked. If both conditions are
met, we directly call PatchTree like it was already done
in case of error during git apply.

Signed-off-by: Frederic Martinsons 
---
 meta/lib/oe/patch.py | 57 ++--
 1 file changed, 44 insertions(+), 13 deletions(-)

diff --git a/meta/lib/oe/patch.py b/meta/lib/oe/patch.py
index b2dc8d0a90..d047b3b947 100644
--- a/meta/lib/oe/patch.py
+++ b/meta/lib/oe/patch.py
@@ -499,6 +499,36 @@ class GitApplyTree(PatchTree):
 finally:
 shutil.rmtree(tempdir)
 
+def _need_dirty_check(self):
+fetch = bb.fetch2.Fetch([], self.d)
+check_dirtyness = False
+for url in fetch.urls:
+url_data = fetch.ud[url]
+parm = url_data.parm
+# a git url with subpath param will surely be dirty
+# since the git tree from which we clone will be emptied
+# from all files that are not in the subpath
+if url_data.type == 'git' and parm.get('subpath'):
+check_dirtyness = True
+return check_dirtyness
+
+def _commitpatch(self, patch, patchfilevar):
+output = ""
+# Add all files
+shellcmd = ["git", "add", "-f", "-A", "."]
+output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
+# Exclude the patches directory
+shellcmd = ["git", "reset", "HEAD", self.patchdir]
+output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
+# Commit the result
+(tmpfile, shellcmd) = self.prepareCommit(patch['file'], 
self.commituser, self.commitemail)
+try:
+shellcmd.insert(0, patchfilevar)
+output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
+finally:
+os.remove(tmpfile)
+return output
+
 def _applypatch(self, patch, force = False, reverse = False, run = True):
 import shutil
 
@@ -534,6 +564,19 @@ class GitApplyTree(PatchTree):
 shutil.copy2(commithook, applyhook)
 try:
 patchfilevar = 'PATCHFILE="%s"' % os.path.basename(patch['file'])
+if self._need_dirty_check():
+# Check dirtyness of the tree
+try:
+output = runcmd(["git", "--work-tree=%s" % reporoot, 
"status", "--short"])
+except CmdError:
+pass
+else:
+if output:
+# The tree is dirty, not need to try to apply patches 
with git anymore
+# since they fail, fallback directly to patch
+output = PatchTree._applypatch(self, patch, force, 
reverse, run)
+output += self._commitpatch(patch, patchfilevar)
+return output
 try:
 shellcmd = [patchfilevar, "git", "--work-tree=%s" % reporoot]
 self.gitCommandUserOptions(shellcmd, self.commituser, 
self.commitemail)
@@ -560,19 +603,7 @@ class GitApplyTree(PatchTree):
 except CmdError:
 # Fall back to patch
 output = PatchTree._applypatch(self, patch, force, 
reverse, run)
-# Add all files
-shellcmd = ["git", "add", "-f", "-A", "."]
-output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
-# Exclude the patches directory
-shellcmd = ["git", "reset", "HEAD", self.patchdir]
-output += runcmd(["sh", "-c", " ".join(shellcmd)], self.dir)
-# Commit the result
-(tmpfile, shellcmd) = self.prepareCommit(patch['file'], 
self.commituser, self.commitemail)
-try:
-shellcmd.insert(0, patchfilevar)
-output += runcmd(["sh", "-c", " ".join(shellcmd)], 
self.dir)
-finally:
-os.remove(tmpfile)
+output += self._comm

[OE-core] [PATCHV3 3/4] devtool: add support for multiple git url inside a cargo based recipe

[Frederic Martinsons]

From: Frederic Martinsons 

Without that, the possible git urls that are in SRC_URI of a recipe
are removed from SRC_URI during devtool process and so the
cargo_common_do_patch_paths in cargo_common.bbclass cannot
patch these packages to fetch them locally.

I use a generic type name because I foresee this change will
be useful for recipe that used a package manager (cargo but also
npm) see https://bugzilla.yoctoproject.org/show_bug.cgi?id=11015

Signed-off-by: Frederic Martinsons 
---
 meta/classes/externalsrc.bbclass | 4 +---
 1 file changed, 1 insertion(+), 3 deletions(-)

diff --git a/meta/classes/externalsrc.bbclass b/meta/classes/externalsrc.bbclass
index 26c5803ee6..b00fdba8e9 100644
--- a/meta/classes/externalsrc.bbclass
+++ b/meta/classes/externalsrc.bbclass
@@ -68,9 +68,7 @@ python () {
 for url in fetch.urls:
 url_data = fetch.ud[url]
 parm = url_data.parm
-if (url_data.type == 'file' or
-url_data.type == 'npmsw' or url_data.type == 'crate' or
-'type' in parm and parm['type'] == 'kmeta'):
+if url_data.type in ['file', 'npmsw', 'crate'] or parm.get('type') 
in ['kmeta', 'git-dependency']:
 local_srcuri.append(url)
 
 d.setVar('SRC_URI', ' '.join(local_srcuri))
-- 
2.34.1


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

[OE-core] [PATCHV3 2/4] cargo_common.bbclass: add support of user in url for patch

[Frederic Martinsons]

From: Frederic Martinsons 

To handle url like git://git@repo/project

Signed-off-by: Frederic Martinsons 
---
 meta/classes-recipe/cargo_common.bbclass | 5 -
 1 file changed, 4 insertions(+), 1 deletion(-)

diff --git a/meta/classes-recipe/cargo_common.bbclass 
b/meta/classes-recipe/cargo_common.bbclass
index 63b1382908..82ab25b59c 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -134,7 +134,10 @@ python cargo_common_do_patch_paths() {
 name = ud.parm.get('name')
 destsuffix = ud.parm.get('destsuffix')
 if name is not None and destsuffix is not None:
-repo = '%s://%s%s' % (ud.proto, ud.host, ud.path)
+if ud.user:
+repo = '%s://%s@%s%s' % (ud.proto, ud.user, ud.host, 
ud.path)
+else:
+repo = '%s://%s%s' % (ud.proto, ud.host, ud.path)
 path = '%s = { path = "%s" }' % (name, os.path.join(workdir, 
destsuffix))
 patches.setdefault(repo, []).append(path)
 
-- 
2.34.1


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

[OE-core] [PATCHV3 0/4] Extend cargo based recipe support

[Frederic Martinsons]

From: Frederic Martinsons 

This series brings the support of local git repository inside
a cargo based recipe.

It also enables devtool capacity on it.

The following changes since commit 4876189dd2ae5a04a296b11b537b9f613159c6bf:

  xcb-proto: Fix install conflict when enable multilib. (2023-03-23 22:38:41 
+)

are available in the Git repository at:

  https://gitlab.com/fmartinsons/openembedded-core 
cargo-extend-support-git-and-devtool

Alex Kiernan (1):
  cargo_common.bbclass: Support local github repos

Frederic Martinsons (3):
  cargo_common.bbclass: add support of user in url for patch
  devtool: add support for multiple git url inside a cargo based recipe
  patch: support of git patches when the source uri contained subpath
parameter

 meta/classes-recipe/cargo_common.bbclass | 33 ++
 meta/classes/externalsrc.bbclass |  4 +-
 meta/lib/oe/patch.py | 57 ++--
 3 files changed, 78 insertions(+), 16 deletions(-)

-- 
2.34.1


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

[OE-core] [PATCHV3 1/4] cargo_common.bbclass: Support local github repos

[Frederic Martinsons]

From: Alex Kiernan 

Since disable network was added cargo configurations which reference git
repos fail as they attempt to fetch across the network as part of
do_compile, even if EXTRA_OECARGO_PATHS to add them as part of `paths`
is used, as this is documented as only working for packages which exist
in crates.io.

Add parsing of the SRC_URIs for git repos and include `[patch]` sections
to redirect to the checked out source repos which the bitbake fetcher
has already populated.

There are still cases which don't work - if you have multiple copies of
the same repo with different revisions, there's currently no way to
represent that and anything using a repo which has a virtual manifest
will fail to build (see https://github.com/rust-lang/cargo/issues/4934).

Signed-off-by: Alex Kiernan 
---
 meta/classes-recipe/cargo_common.bbclass | 30 
 1 file changed, 30 insertions(+)

diff --git a/meta/classes-recipe/cargo_common.bbclass 
b/meta/classes-recipe/cargo_common.bbclass
index f503a001dd..63b1382908 100644
--- a/meta/classes-recipe/cargo_common.bbclass
+++ b/meta/classes-recipe/cargo_common.bbclass
@@ -116,6 +116,36 @@ cargo_common_do_configure () {
EOF
 }
 
+python cargo_common_do_patch_paths() {
+cargo_config = os.path.join(d.getVar("CARGO_HOME"), "config")
+if not os.path.exists(cargo_config):
+return
+
+src_uri = (d.getVar('SRC_URI') or "").split()
+if len(src_uri) == 0:
+return
+
+patches = dict()
+workdir = d.getVar('WORKDIR')
+fetcher = bb.fetch2.Fetch(src_uri, d)
+for url in fetcher.urls:
+ud = fetcher.ud[url]
+if ud.type == 'git':
+name = ud.parm.get('name')
+destsuffix = ud.parm.get('destsuffix')
+if name is not None and destsuffix is not None:
+repo = '%s://%s%s' % (ud.proto, ud.host, ud.path)
+path = '%s = { path = "%s" }' % (name, os.path.join(workdir, 
destsuffix))
+patches.setdefault(repo, []).append(path)
+
+with open(cargo_config, "a+") as config:
+for k, v in patches.items():
+print('\n[patch."%s"]' % k, file=config)
+for name in v:
+print(name, file=config)
+}
+do_configure[postfuncs] += "cargo_common_do_patch_paths"
+
 oe_cargo_fix_env () {
export CC="${RUST_TARGET_CC}"
export CXX="${RUST_TARGET_CXX}"
-- 
2.34.1


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