[OE-core] [kirkstone][PATCH] curl: CVE-2023-27534 SFTP path resolving discrepancy

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://github.com/curl/curl/commit/4e2b52b5f7a3bf50a0f1494155717b02cc1df6d6

Signed-off-by: Hitendra Prajapati 
---
 .../curl/curl/CVE-2023-27534.patch| 122 ++
 meta/recipes-support/curl/curl_7.82.0.bb  |   1 +
 2 files changed, 123 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-27534.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2023-27534.patch 
b/meta/recipes-support/curl/curl/CVE-2023-27534.patch
new file mode 100644
index 00..9109faaf88
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-27534.patch
@@ -0,0 +1,122 @@
+From 4e2b52b5f7a3bf50a0f1494155717b02cc1df6d6 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Thu, 9 Mar 2023 16:22:11 +0100
+Subject: [PATCH] curl_path: create the new path with dynbuf
+
+CVE: CVE-2023-27534
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/4e2b52b5f7a3bf50a0f1494155717b02cc1df6d6]
+
+Signed-off-by: Hitendra Prajapati 
+---
+ lib/curl_path.c | 71 -
+ 1 file changed, 35 insertions(+), 36 deletions(-)
+
+diff --git a/lib/curl_path.c b/lib/curl_path.c
+index a1669d1..b9c470f 100644
+--- a/lib/curl_path.c
 b/lib/curl_path.c
+@@ -30,66 +30,65 @@
+ #include "escape.h"
+ #include "memdebug.h"
+ 
++#define MAX_SSHPATH_LEN 10 /* arbitrary */
++
+ /* figure out the path to work with in this particular request */
+ CURLcode Curl_getworkingpath(struct Curl_easy *data,
+  char *homedir,  /* when SFTP is used */
+  char **path) /* returns the  allocated
+  real path to work with */
+ {
+-  char *real_path = NULL;
+   char *working_path;
+   size_t working_path_len;
++  struct dynbuf npath;
+   CURLcode result =
+ Curl_urldecode(data->state.up.path, 0, _path,
+_path_len, REJECT_ZERO);
+   if(result)
+ return result;
+ 
++  /* new path to switch to in case we need to */
++  Curl_dyn_init(, MAX_SSHPATH_LEN);
++
+   /* Check for /~/, indicating relative to the user's home directory */
+-  if(data->conn->handler->protocol & CURLPROTO_SCP) {
+-real_path = malloc(working_path_len + 1);
+-if(!real_path) {
++  if((data->conn->handler->protocol & CURLPROTO_SCP) &&
++ (working_path_len > 3) && (!memcmp(working_path, "/~/", 3))) {
++/* It is referenced to the home directory, so strip the leading '/~/' */
++if(Curl_dyn_addn(, _path[3], working_path_len - 3)) {
+   free(working_path);
+   return CURLE_OUT_OF_MEMORY;
+ }
+-if((working_path_len > 3) && (!memcmp(working_path, "/~/", 3)))
+-  /* It is referenced to the home directory, so strip the leading '/~/' */
+-  memcpy(real_path, working_path + 3, working_path_len - 2);
+-else
+-  memcpy(real_path, working_path, 1 + working_path_len);
+   }
+-  else if(data->conn->handler->protocol & CURLPROTO_SFTP) {
+-if((working_path_len > 1) && (working_path[1] == '~')) {
+-  size_t homelen = strlen(homedir);
+-  real_path = malloc(homelen + working_path_len + 1);
+-  if(!real_path) {
+-free(working_path);
+-return CURLE_OUT_OF_MEMORY;
+-  }
+-  /* It is referenced to the home directory, so strip the
+- leading '/' */
+-  memcpy(real_path, homedir, homelen);
+-  real_path[homelen] = '/';
+-  real_path[homelen + 1] = '\0';
+-  if(working_path_len > 3) {
+-memcpy(real_path + homelen + 1, working_path + 3,
+-   1 + working_path_len -3);
+-  }
++  else if((data->conn->handler->protocol & CURLPROTO_SFTP) &&
++  (working_path_len > 2) && !memcmp(working_path, "/~/", 3)) {
++size_t len;
++const char *p;
++int copyfrom = 3;
++if(Curl_dyn_add(, homedir)) {
++  free(working_path);
++  return CURLE_OUT_OF_MEMORY;
+ }
+-else {
+-  real_path = malloc(working_path_len + 1);
+-  if(!real_path) {
+-free(working_path);
+-return CURLE_OUT_OF_MEMORY;
+-  }
+-  memcpy(real_path, working_path, 1 + working_path_len);
++/* Copy a separating '/' if homedir does not end with one */
++len = Curl_dyn_len();
++p = Curl_dyn_ptr();
++if(len && (p[len-1] != '/'))
++  copyfrom = 2;
++
++if(Curl_dyn_addn(,
++ _path[copyfrom], working_path_len - copyfrom)) {
++  free(working_path);
++  return CURLE_OUT_OF_MEMORY;
+ }
+   }
+ 
+-  free(working_path);
++  if(Curl_dyn_len()) {
++free(working_path);
+ 
+-  /* store the pointer for the caller to receive */
+-  *path = real_path;
++/* store the pointer for the caller to receive */
++*path = Curl_dyn_ptr();
++  }
++  else
++*path = working_path;
+ 
+   return CURLE_OK;
+ }
+-- 
+2.25.1
+
diff --git a/meta/recipes-support/curl/curl_7.82.0.bb 
b/meta/recipes-support/curl/curl_7.82.0.bb
index cd6264b715..8c2d99a449 100644
--- 

[OE-core] [PATCH] kernel-devsrc: depend on python3-core instead of python3

[bkylerussell]

Avoids pulling in potential GPLv3 packages through python3-misc catch-all.

python3-core is the intended minimal RDEPENDS for packages requiring python3
support.  Other python3 module dependencies should be listed explicitly.

Signed-off-by: Kyle Russell 
---
 meta/recipes-kernel/linux/kernel-devsrc.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-kernel/linux/kernel-devsrc.bb 
b/meta/recipes-kernel/linux/kernel-devsrc.bb
index b4ea5f756a..6764598d48 100644
--- a/meta/recipes-kernel/linux/kernel-devsrc.bb
+++ b/meta/recipes-kernel/linux/kernel-devsrc.bb
@@ -377,7 +377,7 @@ do_install[lockfiles] = "${TMPDIR}/kernel-scripts.lock"
 FILES:${PN} = "${KERNEL_BUILD_ROOT} ${KERNEL_SRC_PATH}"
 FILES:${PN}-dbg += "${KERNEL_BUILD_ROOT}*/build/scripts/*/.debug/*"
 
-RDEPENDS:${PN} = "bc python3 flex bison ${TCLIBC}-utils"
+RDEPENDS:${PN} = "bc python3-core flex bison ${TCLIBC}-utils"
 # 4.15+ needs these next two RDEPENDS
 RDEPENDS:${PN} += "openssl-dev util-linux"
 # and x86 needs a bit more for 4.15+
-- 
2.34.1


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

[Frederic Martinsons]

Le mar. 11 avr. 2023, 18:41, Richard Purdie <
richard.pur...@linuxfoundation.org> a écrit :

> On Tue, 2023-04-11 at 17:27 +0200, Frédéric Martinsons wrote:
> > Hello with the patch below:
> >
> > --- a/meta/lib/oeqa/selftest/cases/reproducible.py
> > +++ b/meta/lib/oeqa/selftest/cases/reproducible.py
> > @@ -134,9 +134,9 @@ class ReproducibleTests(OESelftestTestCase):
> >  max_report_size = 250 * 1024 * 1024
> >
> >  # targets are the things we want to test the reproducibility of
> > -targets = ['core-image-minimal', 'core-image-sato', 'core-image-
> > full-cmdline', 'core-image-weston', 'world']
> > +targets = ['zvariant']
> >  # sstate targets are things to pull from sstate to potentially
> > cut build/debugging time
> > -sstate_targets = []
> > +sstate_targets = ['rust-native', 'cargo-native']
> >  save_results = False
> >  if 'OEQA_DEBUGGING_SAVED_OUTPUT' in os.environ:
> >  save_results = os.environ['OEQA_DEBUGGING_SAVED_OUTPUT']
> >
> > I managed to reduce the time to test to 30mn (which is reasonable).
> > Today, I made 5 run of this
> > reproducibility test and if library is indeed different between build
> > A and build B every time, this
> > is the same exact difference, that is to day that the 5 libraries in
> > build A are identical and so are
> > the 5 libraries in build B.
> >
> > I admit I'm surprised , I would have waited for some random diff.
> > I'll continue my investigation but if this rang a bell to someone
> > here, feel free to tell (this does
> > seem strange to me).
>
> It likely means it is the path the build is made in that is being
> encoded into the build somehow. The same binary is resulting for a
> given build path?
>
> Cheers,
>
> Richard
>

I issued "strings" and "hexdump -C" on the  libraries and didn't see any
build path (the remap-path-prefix in rust-common.bbclass do it's job and I
only saw /usr/src/debug with the rust source file of zvariant).

But maybe the build path is leaking anyway in some kind of binary format?

>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179936): 
https://lists.openembedded.org/g/openembedded-core/message/179936
Mute This Topic: https://lists.openembedded.org/mt/98126404/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] rust: Upgrade 1.68.1 -> 1.68.2

[Alexandre Belloni via lists.openembedded.org]

I confirm it didn't cause any particular issue to the autobuilders.

On 11/04/2023 08:18:23+0100, Alex Kiernan wrote:
> Cool, was just picking up the pieces to check it, but I'll leave it now!
> 
> On Tue, 11 Apr 2023, 08:07 Khem Raj,  wrote:
> 
> > alright my builds for cargo on qemuriscv32/musl went ok so I guess its ok.
> >
> > On Mon, Apr 10, 2023 at 11:11 AM Khem Raj  wrote:
> > >
> > > Thanks, I'll also check it out. I think the checksums for the musl
> > > patch would need updating I think as the versions of these crates
> > > might have changed.
> > >
> > > On Mon, Apr 10, 2023 at 10:30 AM Alexandre Belloni
> > >  wrote:
> > > >
> > > > My current a-full has this patch.
> > > >
> > > > On 10/04/2023 10:21:16-0700, Khem Raj wrote:
> > > > > If possible, Can you test this on top of contrib/abelloni/master-next
> > > > > for musl target ?
> > > > >
> > > > > On Mon, Apr 10, 2023 at 2:42 AM Alex Kiernan 
> > wrote:
> > > > > >
> > > > > > Changes:
> > > > > >
> > > > > > * Update the GitHub RSA host key bundled within Cargo. The key was
> > > > > >   rotated by GitHub on 2023-03-24 after the old one leaked.
> > > > > > * Mark the old GitHub RSA host key as revoked. This will prevent
> > Cargo
> > > > > >   from accepting the leaked key even when trusted by the system.
> > > > > > * Add support for @revoked and a better error message for
> > > > > >   @cert-authority in Cargo’s SSH host key verification
> > > > > >
> > > > > > Signed-off-by: Alex Kiernan 
> > > > > > ---
> > > > > >
> > > > > >  meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb}
> > | 0
> > > > > >  .../rust/{libstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb}
> >  | 0
> > > > > >  ...t-cross-canadian_1.68.1.bb => rust-cross-canadian_1.68.2.bb}
> > | 0
> > > > > >  .../rust/{rust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb}
> >  | 0
> > > > > >  meta/recipes-devtools/rust/rust-source.inc  |
> > 2 +-
> > > > > >  meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb}
> >  | 0
> > > > > >  6 files changed, 1 insertion(+), 1 deletion(-)
> > > > > >  rename meta/recipes-devtools/rust/{cargo_1.68.1.bb =>
> > cargo_1.68.2.bb} (100%)
> > > > > >  rename meta/recipes-devtools/rust/{libstd-rs_1.68.1.bb =>
> > libstd-rs_1.68.2.bb} (100%)
> > > > > >  rename meta/recipes-devtools/rust/{rust-cross-canadian_1.68.1.bb
> > => rust-cross-canadian_1.68.2.bb} (100%)
> > > > > >  rename meta/recipes-devtools/rust/{rust-llvm_1.68.1.bb =>
> > rust-llvm_1.68.2.bb} (100%)
> > > > > >  rename meta/recipes-devtools/rust/{rust_1.68.1.bb =>
> > rust_1.68.2.bb} (100%)
> > > > > >
> > > > > > diff --git a/meta/recipes-devtools/rust/cargo_1.68.1.bb
> > b/meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > > > similarity index 100%
> > > > > > rename from meta/recipes-devtools/rust/cargo_1.68.1.bb
> > > > > > rename to meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
> > b/meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > > > similarity index 100%
> > > > > > rename from meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
> > > > > > rename to meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > > > diff --git a/meta/recipes-devtools/rust/
> > rust-cross-canadian_1.68.1.bb b/meta/recipes-devtools/rust/
> > rust-cross-canadian_1.68.2.bb
> > > > > > similarity index 100%
> > > > > > rename from meta/recipes-devtools/rust/
> > rust-cross-canadian_1.68.1.bb
> > > > > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
> > > > > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
> > b/meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > > > similarity index 100%
> > > > > > rename from meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
> > > > > > rename to meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> > b/meta/recipes-devtools/rust/rust-source.inc
> > > > > > index c8f5a5a9c4c4..6d3a4b131e26 100644
> > > > > > --- a/meta/recipes-devtools/rust/rust-source.inc
> > > > > > +++ b/meta/recipes-devtools/rust/rust-source.inc
> > > > > > @@ -7,7 +7,7 @@ SRC_URI += "
> > https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > > > > >
> > file://0001-Do-not-use-LFS64-on-linux-with-musl.patch;patchdir=${RUSTSRC} \
> > > > > >  file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> > > > > >  "
> > > > > > -SRC_URI[rust.sha256sum] =
> > "5b8ea94085b65e75c1fa6310e2f90bd706fa80bfcb3544fe26f4037b911d9fb2"
> > > > > > +SRC_URI[rust.sha256sum] =
> > "ce1a115f6aafa912b4622906a92b626354973afa9288e2c7750df4dcf3390fc0"
> > > > > >
> > > > > >  RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> > > > > >
> > > > > > diff --git a/meta/recipes-devtools/rust/rust_1.68.1.bb
> > b/meta/recipes-devtools/rust/rust_1.68.2.bb
> > > > > > similarity index 100%
> > > > > > rename from meta/recipes-devtools/rust/rust_1.68.1.bb
> > > > > > rename to meta/recipes-devtools/rust/rust_1.68.2.bb
> > 

Re: [OE-core] Reproducible build

[Richard Purdie]

On Tue, 2023-04-11 at 17:27 +0200, Frédéric Martinsons wrote:
> Hello with the patch below:
> 
> --- a/meta/lib/oeqa/selftest/cases/reproducible.py
> +++ b/meta/lib/oeqa/selftest/cases/reproducible.py
> @@ -134,9 +134,9 @@ class ReproducibleTests(OESelftestTestCase):
>      max_report_size = 250 * 1024 * 1024
>  
>      # targets are the things we want to test the reproducibility of
> -    targets = ['core-image-minimal', 'core-image-sato', 'core-image-
> full-cmdline', 'core-image-weston', 'world']
> +    targets = ['zvariant']
>      # sstate targets are things to pull from sstate to potentially
> cut build/debugging time
> -    sstate_targets = []
> +    sstate_targets = ['rust-native', 'cargo-native']
>      save_results = False
>      if 'OEQA_DEBUGGING_SAVED_OUTPUT' in os.environ:
>          save_results = os.environ['OEQA_DEBUGGING_SAVED_OUTPUT']
> 
> I managed to reduce the time to test to 30mn (which is reasonable).
> Today, I made 5 run of this
> reproducibility test and if library is indeed different between build
> A and build B every time, this
> is the same exact difference, that is to day that the 5 libraries in
> build A are identical and so are
> the 5 libraries in build B.
> 
> I admit I'm surprised , I would have waited for some random diff.
> I'll continue my investigation but if this rang a bell to someone
> here, feel free to tell (this does
> seem strange to me).

It likely means it is the path the build is made in that is being
encoded into the build somehow. The same binary is resulting for a
given build path?

Cheers,

Richard

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

Re: [OE-core] [PATCH 1/7] ffmpeg: update 5.1.2 -> 6.0

[Khem Raj]

On Tue, Apr 11, 2023 at 8:15 AM Alexander Kanavin
 wrote:
>
> This has been resolved by your 0.34.1 -> 0.35.1 update.
>
cool

> Alex
>
> On Sat, 1 Apr 2023 at 20:57, Khem Raj  wrote:
> >
> > I think mpv is failing to this upgrade, this issue talks about it
> > https://github.com/mpv-player/mpv/issues/9803
> > https://errors.yoctoproject.org/Errors/Details/699341/
> > This is a arm64/musl build.
> >
> > On Thu, Mar 30, 2023 at 10:26 PM Alexander Kanavin
> >  wrote:
> > >
> > > Add a patch to gstreamer1.0-libav to address an API compatibility fail.
> > >
> > > Signed-off-by: Alexander Kanavin 
> > > ---
> > >  ...c-stop-accessing-out-of-bounds-frame.patch |  89 ---
> > >  ...c-stop-accessing-out-of-bounds-frame.patch | 108 --
> > >  .../ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch |  34 --
> > >  .../ffmpeg/{ffmpeg_5.1.2.bb => ffmpeg_6.0.bb} |   8 +-
> > >  .../gstreamer1.0-libav/ffmpeg-6.0.patch   |  49 
> > >  .../gstreamer/gstreamer1.0-libav_1.22.0.bb|   4 +-
> > >  6 files changed, 54 insertions(+), 238 deletions(-)
> > >  delete mode 100644 
> > > meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > >  delete mode 100644 
> > > meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
> > >  delete mode 100644 
> > > meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
> > >  rename meta/recipes-multimedia/ffmpeg/{ffmpeg_5.1.2.bb => ffmpeg_6.0.bb} 
> > > (95%)
> > >  create mode 100644 
> > > meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/ffmpeg-6.0.patch
> > >
> > > diff --git 
> > > a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > >  
> > > b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > > deleted file mode 100644
> > > index 2775a81cc86..000
> > > --- 
> > > a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > > +++ /dev/null
> > > @@ -1,89 +0,0 @@
> > > -From 92f9b28ed84a77138105475beba16c146bdaf984 Mon Sep 17 00:00:00 2001
> > > -From: Paul B Mahol 
> > > -Date: Sat, 12 Nov 2022 16:12:00 +0100
> > > -Subject: [PATCH] avcodec/rpzaenc: stop accessing out of bounds frame
> > > -
> > > -Upstream-Status: Backport 
> > > [https://github.com/FFmpeg/FFmpeg/commit/92f9b28ed84a77138105475beba16c146bdaf984]
> > > -
> > > -Signed-off-by: 
> > > -
> > > 
> > > - libavcodec/rpzaenc.c | 22 +++---
> > > - 1 file changed, 15 insertions(+), 7 deletions(-)
> > > -
> > > -diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
> > > -index d710eb4f82..4ced9523e2 100644
> > >  a/libavcodec/rpzaenc.c
> > > -+++ b/libavcodec/rpzaenc.c
> > > -@@ -205,7 +205,7 @@ static void get_max_component_diff(const BlockInfo 
> > > *bi, const uint16_t *block_pt
> > > -
> > > - // loop thru and compare pixels
> > > - for (y = 0; y < bi->block_height; y++) {
> > > --for (x = 0; x < bi->block_width; x++){
> > > -+for (x = 0; x < bi->block_width; x++) {
> > > - // TODO:  optimize
> > > - min_r = FFMIN(R(block_ptr[x]), min_r);
> > > - min_g = FFMIN(G(block_ptr[x]), min_g);
> > > -@@ -278,7 +278,7 @@ static int leastsquares(const uint16_t *block_ptr, 
> > > const BlockInfo *bi,
> > > - return -1;
> > > -
> > > - for (i = 0; i < bi->block_height; i++) {
> > > --for (j = 0; j < bi->block_width; j++){
> > > -+for (j = 0; j < bi->block_width; j++) {
> > > - x = GET_CHAN(block_ptr[j], xchannel);
> > > - y = GET_CHAN(block_ptr[j], ychannel);
> > > - sumx += x;
> > > -@@ -325,7 +325,7 @@ static int calc_lsq_max_fit_error(const uint16_t 
> > > *block_ptr, const BlockInfo *bi
> > > - int max_err = 0;
> > > -
> > > - for (i = 0; i < bi->block_height; i++) {
> > > --for (j = 0; j < bi->block_width; j++){
> > > -+for (j = 0; j < bi->block_width; j++) {
> > > - int x_inc, lin_y, lin_x;
> > > - x = GET_CHAN(block_ptr[j], xchannel);
> > > - y = GET_CHAN(block_ptr[j], ychannel);
> > > -@@ -420,7 +420,9 @@ static void update_block_in_prev_frame(const 
> > > uint16_t *src_pixels,
> > > -uint16_t *dest_pixels,
> > > -const BlockInfo *bi, int 
> > > block_counter)
> > > - {
> > > --for (int y = 0; y < 4; y++) {
> > > -+const int y_size = FFMIN(4, bi->image_height - bi->row * 4);
> > > -+
> > > -+for (int y = 0; y < y_size; y++) {
> > > - memcpy(dest_pixels, src_pixels, 8);
> > > - dest_pixels += bi->rowstride;
> > > - src_pixels += bi->rowstride;
> > > -@@ -730,14 +732,15 @@ post_skip :
> > > -
> > > - if (err > s->sixteen_color_thresh) { // DO SIXTEEN COLOR 
> > > BLOCK
> > > - uint16_t 

Re: [OE-core] Reproducible build

[Frederic Martinsons]

Hello with the patch below:

--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -134,9 +134,9 @@ class ReproducibleTests(OESelftestTestCase):
 max_report_size = 250 * 1024 * 1024

 # targets are the things we want to test the reproducibility of
-targets = ['core-image-minimal', 'core-image-sato',
'core-image-full-cmdline', 'core-image-weston', 'world']
+targets = ['zvariant']
 # sstate targets are things to pull from sstate to potentially cut
build/debugging time
-sstate_targets = []
+sstate_targets = ['rust-native', 'cargo-native']
 save_results = False
 if 'OEQA_DEBUGGING_SAVED_OUTPUT' in os.environ:
 save_results = os.environ['OEQA_DEBUGGING_SAVED_OUTPUT']

I managed to reduce the time to test to 30mn (which is reasonable). Today,
I made 5 run of this
reproducibility test and if library is indeed different between build A and
build B every time, this
is the same exact difference, that is to day that the 5 libraries in build
A are identical and so are
the 5 libraries in build B.

I admit I'm surprised , I would have waited for some random diff.
I'll continue my investigation but if this rang a bell to someone here,
feel free to tell (this does
seem strange to me).



On Mon, 10 Apr 2023 at 18:38, Frederic Martinsons via lists.openembedded.org
 wrote:

>
>
> On Mon, 10 Apr 2023 at 17:32, Jose Quaresma 
> wrote:
>
>> Hi Frederic,
>>
>> Frederic Martinsons  escreveu no dia
>> domingo, 9/04/2023 à(s) 16:05:
>>
>>>
>>>
>>> Le dim. 9 avr. 2023, 10:43, Richard Purdie <
>>> richard.pur...@linuxfoundation.org> a écrit :
>>>
 On Sat, 2023-04-08 at 09:56 +0200, Frederic Martinsons wrote:
 > Forget my previous question,
 >
 > I simply
 > edit https://git.openembedded.org/openembedded-core/tree/meta/lib/oeq
 > a/selftest/cases/reproducible.py#n137
 > to replace by zavariant, and with OEQA_DEBUGGING_SAVED_OUTPUT set , I
 > managed to see the html diff
 >
 > Nevertheless, It took one hour, but it seems that it cannot be
 > avoided since there are two builds and one
 > without any shared state.

 Unfortunately that is the nature of the test, one side has to be built
 from scratch. Tweaking the test as you'd done to target a specific
 component is what I'd have done too to speed things up for a specific
 recipe.

 To get a further speedup, you could probably keep the sstate for each
 of the two builds separate but retain both, then in theory on the
 pieces you change would rebuild. Again, it would mean tweaking the test
 but for debugging, I think that is fine. Rust can be a pain if you just
 rebuild those as it still takes a while. Thanks for taking a look!

 Cheers,

 Richard


>>> Thank you for the tip, I'll try that, everything that help to speed up
>>> is good to take of course.
>>>
>>
>> To speedup the build you can take the rust-native from the state cache
>> [1] and this will improve a bit bit the time needed:
>>
>> sstate_target = [ "rust-native" ]
>>
>> [1] 
>> https://git.openembedded.org/openembedded-core/tree/meta/lib/oeqa/selftest/cases/reproducible.py#n139
>>
>>
>> Jose
>>
>>
>>>
>>>
>>>
>>>
>>
>> --
>> Best regards,
>>
>> José Quaresma
>>
>
>
> Hey, thank you José for the advice, I'll apply that for sure.
>
> By the way, like I commented in
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090 , I'm currently
> try to reproduce (ahah) the reproducibility issue of zvariant with the use
> of reprotest (https://salsa.debian.org/reproducible-builds/reprotest)
> and outside yocto environment. For the moment, I was not able to pinpoint
> the issue (I must have
> put aside the faketime usage since it caused me segfault of rustc).
>
> I plan to dig further in reproducible.py class and how the package is
> built under yocto to try to find out
> what is going on.
>
>
>
>
>
> 
>
>

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

[Frederic Martinsons]

Yes  I already did that and manage to get the test last 30mn (see the other
mail thread)

Le mar. 11 avr. 2023, 16:52, Alexander Kanavin  a
écrit :

> If you read the code for the test, you'll see a 'bitbake world' in it
> somewhere :) Tweak that to build only the item you need.
>
> Alternatively, you can set up two separate build directories, and
> avoid selftest altogether for investigating and fixing the issue.
>
> Alex
>
> On Fri, 7 Apr 2023 at 17:21, Frederic Martinsons
>  wrote:
> >
> > Hello,
> >
> > I plan to work on
> https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090  in the coming
> days.
> > To show how things are tested I ran "oe-selftest -r
> reproducible.ReproducibleTests.test_reproducible_builds" but even on a
> strong machine, it took several hours (I waited for 6h and it is not
> finished yet).
> >
> > Does anyone know if it is possible to test reproducibility on a single
> package (here, zvariant) ?
> > Should I tweak the python test class or is there a simple way ?
> >
> > Thanks
> >
> > 
> >
>

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

Re: [OE-core] [PATCH 1/7] ffmpeg: update 5.1.2 -> 6.0

[Alexander Kanavin]

This has been resolved by your 0.34.1 -> 0.35.1 update.

Alex

On Sat, 1 Apr 2023 at 20:57, Khem Raj  wrote:
>
> I think mpv is failing to this upgrade, this issue talks about it
> https://github.com/mpv-player/mpv/issues/9803
> https://errors.yoctoproject.org/Errors/Details/699341/
> This is a arm64/musl build.
>
> On Thu, Mar 30, 2023 at 10:26 PM Alexander Kanavin
>  wrote:
> >
> > Add a patch to gstreamer1.0-libav to address an API compatibility fail.
> >
> > Signed-off-by: Alexander Kanavin 
> > ---
> >  ...c-stop-accessing-out-of-bounds-frame.patch |  89 ---
> >  ...c-stop-accessing-out-of-bounds-frame.patch | 108 --
> >  .../ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch |  34 --
> >  .../ffmpeg/{ffmpeg_5.1.2.bb => ffmpeg_6.0.bb} |   8 +-
> >  .../gstreamer1.0-libav/ffmpeg-6.0.patch   |  49 
> >  .../gstreamer/gstreamer1.0-libav_1.22.0.bb|   4 +-
> >  6 files changed, 54 insertions(+), 238 deletions(-)
> >  delete mode 100644 
> > meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> >  delete mode 100644 
> > meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-smcenc-stop-accessing-out-of-bounds-frame.patch
> >  delete mode 100644 
> > meta/recipes-multimedia/ffmpeg/ffmpeg/ffmpeg-fix-vulkan.patch
> >  rename meta/recipes-multimedia/ffmpeg/{ffmpeg_5.1.2.bb => ffmpeg_6.0.bb} 
> > (95%)
> >  create mode 100644 
> > meta/recipes-multimedia/gstreamer/gstreamer1.0-libav/ffmpeg-6.0.patch
> >
> > diff --git 
> > a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> >  
> > b/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > deleted file mode 100644
> > index 2775a81cc86..000
> > --- 
> > a/meta/recipes-multimedia/ffmpeg/ffmpeg/0001-avcodec-rpzaenc-stop-accessing-out-of-bounds-frame.patch
> > +++ /dev/null
> > @@ -1,89 +0,0 @@
> > -From 92f9b28ed84a77138105475beba16c146bdaf984 Mon Sep 17 00:00:00 2001
> > -From: Paul B Mahol 
> > -Date: Sat, 12 Nov 2022 16:12:00 +0100
> > -Subject: [PATCH] avcodec/rpzaenc: stop accessing out of bounds frame
> > -
> > -Upstream-Status: Backport 
> > [https://github.com/FFmpeg/FFmpeg/commit/92f9b28ed84a77138105475beba16c146bdaf984]
> > -
> > -Signed-off-by: 
> > -
> > 
> > - libavcodec/rpzaenc.c | 22 +++---
> > - 1 file changed, 15 insertions(+), 7 deletions(-)
> > -
> > -diff --git a/libavcodec/rpzaenc.c b/libavcodec/rpzaenc.c
> > -index d710eb4f82..4ced9523e2 100644
> >  a/libavcodec/rpzaenc.c
> > -+++ b/libavcodec/rpzaenc.c
> > -@@ -205,7 +205,7 @@ static void get_max_component_diff(const BlockInfo 
> > *bi, const uint16_t *block_pt
> > -
> > - // loop thru and compare pixels
> > - for (y = 0; y < bi->block_height; y++) {
> > --for (x = 0; x < bi->block_width; x++){
> > -+for (x = 0; x < bi->block_width; x++) {
> > - // TODO:  optimize
> > - min_r = FFMIN(R(block_ptr[x]), min_r);
> > - min_g = FFMIN(G(block_ptr[x]), min_g);
> > -@@ -278,7 +278,7 @@ static int leastsquares(const uint16_t *block_ptr, 
> > const BlockInfo *bi,
> > - return -1;
> > -
> > - for (i = 0; i < bi->block_height; i++) {
> > --for (j = 0; j < bi->block_width; j++){
> > -+for (j = 0; j < bi->block_width; j++) {
> > - x = GET_CHAN(block_ptr[j], xchannel);
> > - y = GET_CHAN(block_ptr[j], ychannel);
> > - sumx += x;
> > -@@ -325,7 +325,7 @@ static int calc_lsq_max_fit_error(const uint16_t 
> > *block_ptr, const BlockInfo *bi
> > - int max_err = 0;
> > -
> > - for (i = 0; i < bi->block_height; i++) {
> > --for (j = 0; j < bi->block_width; j++){
> > -+for (j = 0; j < bi->block_width; j++) {
> > - int x_inc, lin_y, lin_x;
> > - x = GET_CHAN(block_ptr[j], xchannel);
> > - y = GET_CHAN(block_ptr[j], ychannel);
> > -@@ -420,7 +420,9 @@ static void update_block_in_prev_frame(const uint16_t 
> > *src_pixels,
> > -uint16_t *dest_pixels,
> > -const BlockInfo *bi, int 
> > block_counter)
> > - {
> > --for (int y = 0; y < 4; y++) {
> > -+const int y_size = FFMIN(4, bi->image_height - bi->row * 4);
> > -+
> > -+for (int y = 0; y < y_size; y++) {
> > - memcpy(dest_pixels, src_pixels, 8);
> > - dest_pixels += bi->rowstride;
> > - src_pixels += bi->rowstride;
> > -@@ -730,14 +732,15 @@ post_skip :
> > -
> > - if (err > s->sixteen_color_thresh) { // DO SIXTEEN COLOR BLOCK
> > - uint16_t *row_ptr;
> > --int rgb555;
> > -+int y_size, rgb555;
> > -
> > - block_offset = get_block_info(, block_counter);
> > -
> > - row_ptr = _pixels[block_offset];
> > -+y_size = FFMIN(4, bi.image_height - bi.row * 4);
> 

[OE-core] [PATCH v4 1/2] oeqa/utils/qemurunner: change the serial runner

[Louis Rannou]

[YOCTO #15021]

Create a new runner run_serial_socket which usage matches the traditional ssh
runner. Its return status is 0 when the command succeeded or 0 when it
failed. If an error is encountered, it raises an Exception.

The previous serial runner is maintained and marked as deprecated.

Signed-off-by: Louis Rannou 
---
 meta/lib/oeqa/targetcontrol.py|  3 ++
 meta/lib/oeqa/utils/qemurunner.py | 57 +++
 2 files changed, 60 insertions(+)

diff --git a/meta/lib/oeqa/targetcontrol.py b/meta/lib/oeqa/targetcontrol.py
index d686fe07ec..3707883da7 100644
--- a/meta/lib/oeqa/targetcontrol.py
+++ b/meta/lib/oeqa/targetcontrol.py
@@ -206,6 +206,9 @@ class QemuTarget(BaseTarget):
 def run_serial(self, command, timeout=60):
 return self.runner.run_serial(command, timeout=timeout)
 
+def run_serial_socket(self, command, timeout=60):
+return self.runner.run_serial_socket(command, timeout=timeout)
+
 
 class SimpleRemoteTarget(BaseTarget):
 
diff --git a/meta/lib/oeqa/utils/qemurunner.py 
b/meta/lib/oeqa/utils/qemurunner.py
index 6734cee48d..7e1c7a7eac 100644
--- a/meta/lib/oeqa/utils/qemurunner.py
+++ b/meta/lib/oeqa/utils/qemurunner.py
@@ -637,6 +637,7 @@ class QemuRunner:
 return self.qmp.cmd(command)
 
 def run_serial(self, command, raw=False, timeout=60):
+# Deprecated
 # Returns (status, output) where status is 1 on success and 0 on error
 
 # We assume target system have echo to get command status
@@ -688,6 +689,62 @@ class QemuRunner:
 status = 1
 return (status, str(data))
 
+def run_serial_socket(self, command, raw=False, timeout=60):
+# Returns (status, output) where status is 0 on success and a negative 
value on error.
+
+# We assume target system have echo to get command status
+if not raw:
+command = "%s; echo $?\n" % command
+
+data = ''
+status = 0
+self.server_socket.sendall(command.encode('utf-8'))
+start = time.time()
+end = start + timeout
+while True:
+now = time.time()
+if now >= end:
+data += "<<< run_serial_socket(): command timed out after %d 
seconds without output >>>\r\n\r\n" % timeout
+break
+try:
+sread, _, _ = select.select([self.server_socket],[],[], end - 
now)
+except InterruptedError:
+continue
+if sread:
+# try to avoid reading single character at a time
+time.sleep(0.1)
+answer = self.server_socket.recv(1024)
+if answer:
+data += answer.decode('utf-8')
+# Search the prompt to stop
+if re.search(self.boot_patterns['search_cmd_finished'], 
data):
+break
+else:
+if self.canexit:
+return (1, "")
+raise Exception("No data on serial console socket, 
connection closed?")
+
+if not data:
+raise Exception('serial run failed: no data')
+
+if raw:
+status = 0
+else:
+# Remove first line (command line) and last line (prompt)
+data = data[data.find('$?\r\n')+4:data.rfind('\r\n')]
+index = data.rfind('\r\n')
+if index == -1:
+data = ""
+raise Exception('serial run failed: no result')
+else:
+status_cmd = data[index+2:]
+data = data[:index]
+try:
+status = int(status_cmd)
+except ValueError as e:
+raise Exception('Could not convert to integer: 
{}'.format(str(e)))
+return (status, str(data))
+
 
 def _dump_host(self):
 self.host_dumper.create_dir("qemu")
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179928): 
https://lists.openembedded.org/g/openembedded-core/message/179928
Mute This Topic: https://lists.openembedded.org/mt/98199478/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 v4 2/2] oeqa/selftest: change deprecated usage of run_serial

[Louis Rannou]

Prefer the new function run_serial_socket. Change calls where the modification
is easy.

Signed-off-by: Louis Rannou 
---
 meta/lib/oeqa/selftest/cases/debuginfod.py | 3 ++-
 meta/lib/oeqa/selftest/cases/gdbserver.py  | 7 ---
 meta/lib/oeqa/selftest/cases/locales.py| 8 
 meta/lib/oeqa/selftest/cases/package.py| 7 ---
 meta/lib/oeqa/selftest/cases/runqemu.py| 2 +-
 5 files changed, 15 insertions(+), 12 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/debuginfod.py 
b/meta/lib/oeqa/selftest/cases/debuginfod.py
index 37f51760fb..2571ce6989 100644
--- a/meta/lib/oeqa/selftest/cases/debuginfod.py
+++ b/meta/lib/oeqa/selftest/cases/debuginfod.py
@@ -99,7 +99,8 @@ CORE_IMAGE_EXTRA_INSTALL += "elfutils"
 % (qemu.server_ip, port)
 )
 self.logger.info(f"Starting client {cmd}")
-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
+self.assertEqual(0, status)
 # This should be more comprehensive
 self.assertIn("/.cache/debuginfod_client/", output)
 finally:
diff --git a/meta/lib/oeqa/selftest/cases/gdbserver.py 
b/meta/lib/oeqa/selftest/cases/gdbserver.py
index 9da97ae780..4f8c7d620f 100644
--- a/meta/lib/oeqa/selftest/cases/gdbserver.py
+++ b/meta/lib/oeqa/selftest/cases/gdbserver.py
@@ -43,7 +43,8 @@ CORE_IMAGE_EXTRA_INSTALL = "gdbserver"
 shutil.unpack_archive(filename, debugfs)
 
 with runqemu("core-image-minimal", runqemuparams="nographic") as 
qemu:
-status, output = qemu.run_serial("kmod --help")
+status, output = qemu.run_serial_socket("kmod --help")
+self.assertEqual(status, 0)
 self.assertIn("modprobe", output)
 
 with concurrent.futures.ThreadPoolExecutor(max_workers=1) as 
executor:
@@ -61,7 +62,7 @@ CORE_IMAGE_EXTRA_INSTALL = "gdbserver"
 self.fail("Timed out connecting to gdb")
 future = executor.submit(run_gdb)
 
-status, output = qemu.run_serial("gdbserver --once : 
kmod --help")
-self.assertEqual(status, 1)
+status, output = qemu.run_serial_socket("gdbserver --once 
: kmod --help")
+self.assertEqual(status, 0)
 # The future either returns None, or raises an exception
 future.result()
diff --git a/meta/lib/oeqa/selftest/cases/locales.py 
b/meta/lib/oeqa/selftest/cases/locales.py
index 4ca8ffb7aa..98026d2c80 100644
--- a/meta/lib/oeqa/selftest/cases/locales.py
+++ b/meta/lib/oeqa/selftest/cases/locales.py
@@ -27,15 +27,15 @@ class LocalesTest(OESelftestTestCase):
 
 with runqemu("core-image-minimal", ssh=False, 
runqemuparams='nographic') as qemu:
 cmd = "locale -a"
-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
 # output must includes fr_FR or fr_FR.UTF-8
-self.assertEqual(status, 1, msg='locale test command failed: 
output: %s' % output)
+self.assertEqual(status, 0, msg='locale test command failed: 
output: %s' % output)
 self.assertIn("fr_FR", output, msg='locale -a test failed: output: 
%s' % output)
 
 cmd = "localedef --list-archive -v"
-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
 # output must includes fr_FR.utf8
-self.assertEqual(status, 1, msg='localedef test command failed: 
output: %s' % output)
+self.assertEqual(status, 0, msg='localedef test command failed: 
output: %s' % output)
 self.assertIn("fr_FR.utf8", output, msg='localedef test failed: 
output: %s' % output)
 
 def test_locales_on(self):
diff --git a/meta/lib/oeqa/selftest/cases/package.py 
b/meta/lib/oeqa/selftest/cases/package.py
index 1aa6c03f8a..78e8a4c26b 100644
--- a/meta/lib/oeqa/selftest/cases/package.py
+++ b/meta/lib/oeqa/selftest/cases/package.py
@@ -135,7 +135,8 @@ class PackageTests(OESelftestTestCase):
 Check that gdb ``binary`` to read symbols from separated debug file
 """
 self.logger.info("gdbtest %s" % binary)
-status, output = qemu.run_serial('/usr/bin/gdb.sh %s' % binary, 
timeout=60)
+status, output = qemu.run_serial_socket('/usr/bin/gdb.sh %s' % 
binary, timeout=60)
+self.assertEqual(0, status)
 for l in output.split('\n'):
 # Check debugging symbols exists
 if '(no debugging symbols found)' in l:
@@ -166,8 +167,8 @@ class PackageTests(OESelftestTestCase):
 
 def check_ownership(qemu, expected_gid, expected_uid, path):
 self.logger.info("Check ownership of %s", path)
-status, output = qemu.run_serial('stat -c "%U %G" ' + path)
- 

[OE-core] [PATCH v4 0/2] oeqa: Change the serial runner

[Louis Rannou]

The actual serial runner has a different usage compare to the ssh runner. The
return status is different and failure are not raised as exceptions.

Initially, I wanted to create a new run_serial_socket and modify the old
run_serial to use the former. And there was a second patch that changed every
call to run_serial to run_serial_socket. But that is not easy as each test can
have a different manner to handle the exception.

Therefore, the second patch only change dummy calls to the serial runner.

Louis Rannou (2):
  oeqa/utils/qemurunner: change the serial runner
  oeqa/selftest: change deprecated usage of run_serial

 meta/lib/oeqa/selftest/cases/debuginfod.py |  3 +-
 meta/lib/oeqa/selftest/cases/gdbserver.py  |  7 +--
 meta/lib/oeqa/selftest/cases/locales.py|  8 +--
 meta/lib/oeqa/selftest/cases/package.py|  7 +--
 meta/lib/oeqa/selftest/cases/runqemu.py|  2 +-
 meta/lib/oeqa/targetcontrol.py |  3 ++
 meta/lib/oeqa/utils/qemurunner.py  | 57 ++
 7 files changed, 75 insertions(+), 12 deletions(-)

-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179927): 
https://lists.openembedded.org/g/openembedded-core/message/179927
Mute This Topic: https://lists.openembedded.org/mt/98199473/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 Status 11 April 2023 (WW15)

[Stephen Jolley]

Current Dev Position: YP 4.2 M4

Next Deadline: 28th April 2023 YP 4.2 Release

 

Next Team Meetings:

*   Bug Triage meeting Thursday April 13th 7:30 am PDT (

https://zoom.us/j/454367603?pwd=ZGxoa2ZXL3FkM3Y0bFd5aVpHVVZ6dz09)
*   Weekly Project Engineering Sync Tuesday April 11th at 8 am PDT (

https://zoom.us/j/990892712?pwd=cHU1MjhoM2x6ck81bkcrYjRrcmJsUT09
 )
*   Twitch -  See  
https://www.twitch.tv/theyoctojester

 

Key Status/Updates:

*   YP 4.2 rc2 is now in QA
*   YP 4.0.9 is being built
*   Due to some concerns about crate urls, 4.2 rc1 was abandoned and rc2
built.
*   linux-yocto is no longer excluded from CVE reporting on master,
thanks to all who have helped triage the CVE list for the kernel.

 

https://autobuilder.yocto.io/pub/non-release/patchmetrics/cve-status-master.
txt

*   We're happy to announce that Steve Sakoman is going to be supporting
the mickledore stable series.
*   The langdale release series will now wind down after one final point
release
*   Patches should soon start flowing into master for 4.3
*   The project is looking at a funding opportunity where projects with
a specific development focus may be able to be funded. Ideas coming to mind
might include bringing back patchtest or toaster's automated testing. If
anyone has ideas that we'd be able to find people to work on (contract
based?) within a reasonable timeframe, we'd be interested to hear the things
people feel would make the biggest difference to the project.
*   We have a growing number of bugs in bugzilla, any help with them is
appreciated.

 

Ways to contribute:

*   As people are likely aware, the project has a number of components
which are either unmaintained, or have people with little to no time trying
to keep them alive. These components include: patchtest, layerindex,
devtool, toaster, wic, oeqa, autobuilder, CROPs containers, pseudo and more.
Many have open bugs. Help is welcome in trying to better look after these
components!
*   There are bugs identified as possible for newcomers to the project:

https://wiki.yoctoproject.org/wiki/Newcomers
*   There are bugs that are currently unassigned for YP 4.2. See:

https://wiki.yoctoproject.org/wiki/Bug_Triage#Medium.2B_4.2_Unassigned_Enhan
cements.2FBugs
*   We'd welcome new maintainers for recipes in OE-Core. Please see the
list at:

http://git.yoctoproject.org/cgit.cgi/poky/tree/meta/conf/distro/include/main
tainers.inc and discuss with the existing maintainer, or ask on the OE-Core
mailing list. We will likely move a chunk of these to "Unassigned" soon to
help facilitate this.
*   Help is very much welcome in trying to resolve our autobuilder
intermittent issues. You can see the list of failures we're continuing to
see by searching for the "AB-INT" tag in bugzilla:

https://bugzilla.yoctoproject.org/buglist.cgi?quicksearch=AB-INT.
*   Help us resolve CVE issues:
 CVE metrics 

 

YP 4.2 Milestone Dates:

*   YP 4.2 M4 built and in QA
*   YP 4.2 M4 Release date 2023/04/28

 

YP 4.3 Milestone Dates:

*   YP 4.2 M4 build date 2023/04/03
*   YP 4.2 M4 Release date 2023/04/28
*   YP 4.3 M1 build date  2023/06/05
*   YP 4.3 M1 Release date 2023/06/16
*   YP 4.3 M2 build date  2023/07/17
*   YP 4.3 M2 Release date 2023/07/28
*   YP 4.3 M3 build date  2023/08/28
*   YP 4.3 M3 Release date 2023/09/08
*   YP 4.3 M4 build date  2023/10/02
*   YP 4.3 M4 Release date 2023/10/27

 

Upcoming dot releases:

*   YP 4.0.9 building
*   YP 4.0.9 Release date 2023/04/21
*   YP 4.1.4 build date 2023/05/01
*   YP 4.1.4 Release date 2023/05/13
*   YP 3.1.25 build date 2023/05/08
*   YP 3.1.25 Release date 2023/05/19
*   YP 4.0.10 build date 2023/05/15
*   YP 4.0.10 Release date 2023/05/26
*   YP 4.2.1 build date 2023/05/22
*   YP 4.2.1 Release date 2023/06/02
*   YP 3.1.26 build date 2023/06/19
*   YP 3.1.26 Release date 2023/06/30
*   YP 4.0.11 build date 2023/06/26
*   YP 4.0.11 Release date 2023/07/07
*   YP 4.2.2 build date 2023/07/10
*   YP 4.2.2 Release date 2023/07/21 
*   YP 3.1.27 build date 2023/07/31
*   YP 3.1.27 Release date 2023/08/11
*   YP 4.0.12 build date 2023/08/07
*   YP 4.0.12 Release date 2023/08/18
*   YP 4.2.3 build date 

Re: [OE-core] Reproducible build

[Alexander Kanavin]

If you read the code for the test, you'll see a 'bitbake world' in it
somewhere :) Tweak that to build only the item you need.

Alternatively, you can set up two separate build directories, and
avoid selftest altogether for investigating and fixing the issue.

Alex

On Fri, 7 Apr 2023 at 17:21, Frederic Martinsons
 wrote:
>
> Hello,
>
> I plan to work on https://bugzilla.yoctoproject.org/show_bug.cgi?id=15090  in 
> the coming days.
> To show how things are tested I ran "oe-selftest -r 
> reproducible.ReproducibleTests.test_reproducible_builds" but even on a strong 
> machine, it took several hours (I waited for 6h and it is not finished yet).
>
> Does anyone know if it is possible to test reproducibility on a single 
> package (here, zvariant) ?
> Should I tweak the python test class or is there a simple way ?
>
> Thanks
>
> 
>

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

[OE-core][master][PATCH] tiff: Add fix for CVE-2022-4645

[Pawan Badganchi]

From: Pawan Badganchi 

Below patch fixes the CVE-2022-4645 as well.

0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch

Link: https://nvd.nist.gov/vuln/detail/CVE-2022-4645

Signed-off-by: Pawan Badganchi 
---
 ...-of-TIFFTAG_INKNAMES-and-related-TIF.patch | 267 ++
 1 file changed, 267 insertions(+)
 create mode 100644 
meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch

diff --git 
a/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
 
b/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
new file mode 100644
index 00..17b37be041
--- /dev/null
+++ 
b/meta/recipes-multimedia/libtiff/files/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
@@ -0,0 +1,267 @@
+From f00484b9519df933723deb38fff943dc291a793d Mon Sep 17 00:00:00 2001
+From: Su_Laus 
+Date: Tue, 30 Aug 2022 16:56:48 +0200
+Subject: [PATCH] Revised handling of TIFFTAG_INKNAMES and related
+ TIFFTAG_NUMBEROFINKS value
+
+In order to solve the buffer overflow issues related to TIFFTAG_INKNAMES and 
related TIFFTAG_NUMBEROFINKS value, a revised handling of those tags within 
LibTiff is proposed:
+
+Behaviour for writing:
+`NumberOfInks`  MUST fit to the number of inks in the `InkNames` string.
+`NumberOfInks` is automatically set when `InkNames` is set.
+If `NumberOfInks` is different to the number of inks within `InkNames` 
string, that will be corrected and a warning is issued.
+If `NumberOfInks` is not equal to samplesperpixel only a warning will be 
issued.
+
+Behaviour for reading:
+When reading `InkNames` from a TIFF file, the `NumberOfInks` will be set 
automatically to the number of inks in `InkNames` string.
+If `NumberOfInks` is different to the number of inks within `InkNames` 
string, that will be corrected and a warning is issued.
+If  `NumberOfInks` is not equal to samplesperpixel only a warning will be 
issued.
+
+This allows the safe use of the NumberOfInks value to read out the InkNames 
without buffer overflow
+
+This MR will close the following issues:  #149, #150, #152, #168 (to be 
checked), #250, #269, #398 and #456.
+
+It also fixes the old bug at 
http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of 
`NumberOfInks = SPP` was introduced, which is in my opinion not necessary and 
does not solve the general issue.
+
+CVE: CVE-2022-3599 CVE-2022-4645
+Upstream-Status: Backport 
[https://gitlab.com/libtiff/libtiff/-/commit/e813112545942107551433d61afd16ac094ff246.patch]
+Signed-off-by: Ross Burton 
+Signed-off-by: Pawan Badganchi 
+---
+ libtiff/tif_dir.c  | 119 -
+ libtiff/tif_dir.h  |   2 +
+ libtiff/tif_dirinfo.c  |   2 +-
+ libtiff/tif_dirwrite.c |   5 ++
+ libtiff/tif_print.c|   4 ++
+ 5 files changed, 82 insertions(+), 50 deletions(-)
+
+diff --git a/libtiff/tif_dir.c b/libtiff/tif_dir.c
+index 793e8a79..816f7756 100644
+--- a/libtiff/tif_dir.c
 b/libtiff/tif_dir.c
+@@ -136,32 +136,30 @@ setExtraSamples(TIFF* tif, va_list ap, uint32_t* v)
+ }
+ 
+ /*
+- * Confirm we have "samplesperpixel" ink names separated by \0.  Returns 
++ * Count ink names separated by \0.  Returns
+  * zero if the ink names are not as expected.
+  */
+-static uint32_t
+-checkInkNamesString(TIFF* tif, uint32_t slen, const char* s)
++static uint16_t
++countInkNamesString(TIFF *tif, uint32_t slen, const char *s)
+ {
+-  TIFFDirectory* td = >tif_dir;
+-  uint16_t i = td->td_samplesperpixel;
++  uint16_t i = 0;
++  const char *ep = s + slen;
++  const char *cp = s;
+ 
+   if (slen > 0) {
+-  const char* ep = s+slen;
+-  const char* cp = s;
+-  for (; i > 0; i--) {
++  do {
+   for (; cp < ep && *cp != '\0'; cp++) {}
+   if (cp >= ep)
+   goto bad;
+   cp++;   /* skip \0 */
+-  }
+-  return ((uint32_t)(cp - s));
++  i++;
++  } while (cp < ep);
++  return (i);
+   }
+ bad:
+   TIFFErrorExt(tif->tif_clientdata, "TIFFSetField",
+-  "%s: Invalid InkNames value; expecting %"PRIu16" names, found 
%"PRIu16,
+-  tif->tif_name,
+-  td->td_samplesperpixel,
+-  (uint16_t)(td->td_samplesperpixel-i));
++  "%s: Invalid InkNames value; no NUL at given buffer end 
location %"PRIu32", after %"PRIu16" ink",
++  tif->tif_name, slen, i);
+   return (0);
+ }
+ 
+@@ -478,13 +476,61 @@ _TIFFVSetField(TIFF* tif, uint32_t tag, va_list ap)
+   _TIFFsetFloatArray(>td_refblackwhite, va_arg(ap, float*), 
6);
+   break;
+   case TIFFTAG_INKNAMES:
+-  v = (uint16_t) va_arg(ap, uint16_vap);
+-  s = va_arg(ap, char*);

[OE-core][kirkstone][PATCH] tiff: Add fix for CVE-2022-4645

[Pawan Badganchi]

From: Pawan Badganchi 

Below patch fixes the CVE-2022-4645 as well.

0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch

Link: https://nvd.nist.gov/vuln/detail/CVE-2022-4645

Signed-off-by: Pawan Badganchi 
---
 ...evised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git 
a/meta/recipes-multimedia/libtiff/tiff/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
 
b/meta/recipes-multimedia/libtiff/tiff/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
index 37859c9192..17b37be041 100644
--- 
a/meta/recipes-multimedia/libtiff/tiff/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
+++ 
b/meta/recipes-multimedia/libtiff/tiff/0001-Revised-handling-of-TIFFTAG_INKNAMES-and-related-TIF.patch
@@ -23,9 +23,10 @@ This MR will close the following issues:  #149, #150, #152, 
#168 (to be checked)
 
 It also fixes the old bug at 
http://bugzilla.maptools.org/show_bug.cgi?id=2599, for which the limitation of 
`NumberOfInks = SPP` was introduced, which is in my opinion not necessary and 
does not solve the general issue.
 
-CVE: CVE-2022-3599
-Upstream-Status: Backport
+CVE: CVE-2022-3599 CVE-2022-4645
+Upstream-Status: Backport 
[https://gitlab.com/libtiff/libtiff/-/commit/e813112545942107551433d61afd16ac094ff246.patch]
 Signed-off-by: Ross Burton 
+Signed-off-by: Pawan Badganchi 
 ---
  libtiff/tif_dir.c  | 119 -
  libtiff/tif_dir.h  |   2 +
-- 
2.38.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179923): 
https://lists.openembedded.org/g/openembedded-core/message/179923
Mute This Topic: https://lists.openembedded.org/mt/98198689/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] squashfs-tools: upgrade 4.5.1 -> 4.6.0

[Luca Ceresoli via lists.openembedded.org]

Hello Wang,

On Tue, 11 Apr 2023 09:01:28 +0800
"wangmy"  wrote:

> From: Wang Mingyu 
> 
> Changelog:
> https://github.com/plougher/squashfs-tools/blob/master/CHANGES
> 
> 0001-install-manpages.sh-do-not-write-original-timestamps.patch
> removed since it's included in 4.6.0
> 
> Signed-off-by: Wang Mingyu 

Reproducible testing fails with this patch, even though I'm not sure
exactly why in detail:

Log:
https://autobuilder.yoctoproject.org/typhoon/#/builders/117/builds/2692/steps/12/logs/stdio

Diffoscope output:
http://autobuilder.yocto.io/pub/repro-fail/oe-reproducible-20230411-n16xgjqy/packages/diff-html/

-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

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

Re: [OE-core] [PATCH v2 4/9] oeqa/utils/qemurunner: support ignoring vt100 escape sequences

[Alexander Kanavin]

Right, but this information should be recorded in commit message, or
the file itself.

Alex

On Mon, 3 Apr 2023 at 15:02, Enrico Jörns  wrote:
>
> Hi Alex,
>
> Am Freitag, dem 31.03.2023 um 16:05 +0200 schrieb Alexander Kanavin:
> > On Fri, 31 Mar 2023 at 12:40, Enrico Jorns  wrote:
> > > +re_vt100 = re.compile(r'(\x1b\[|\x9b)[^@-_a-z]*[@-_a-z]|\x1b[@-_a-z]')
> >
> > This piece of 'magic' needs to be explained :) What does it define?
>
> this is actually 'stolen' from labgrid's implementation for barebox[1] or 
> shell[2] drivers which
> have exactly the same needs: They need to remove the ansii (color) control 
> codes from the strings in
> order to match the text only.
>
> The unprocessed barebox console prompt would look like:
>
>   ESC[1;32mbarebox@ESC[1;36mARM QEMU virt64:/ESC[0m
>
> where we cannot match for something like "barebox@ARM QEMU virt64:/".
> The same applies to colored linux terminal output of course.
>
> The "\x1b\[" from the regex catches the standard start of ansii escape 
> sequence while the rest
> catches the actual command code executed.
>
>
> Regards, Enrico
>
> [1] 
> https://github.com/labgrid-project/labgrid/blob/e05f530c22513cd775b4f84e28f6c8c920b95102/labgrid/driver/bareboxdriver.py#L44
> [2] 
> https://github.com/labgrid-project/labgrid/blob/5d3d5714976b37df0f9a9b769c581fe1f83ccbdc/labgrid/driver/shelldriver.py#L61
>
> > Alex
> >
>
> --
> Pengutronix e.K.   | Enrico Jörns|
> Embedded Linux Consulting & Support| https://www.pengutronix.de/ |
> Steuerwalder Str. 21   | Phone: +49-5121-206917-180  |
> 31137 Hildesheim, Germany  | Fax:   +49-5121-206917-9|
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179921): 
https://lists.openembedded.org/g/openembedded-core/message/179921
Mute This Topic: https://lists.openembedded.org/mt/97970648/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 3/9] barebox: set default BAREBOX_CONFIG for qemu machines

[Alexander Kanavin]

On Mon, 3 Apr 2023 at 13:42, Enrico Jörns  wrote:
> > > +# set defaults for oe-core MACHINEs to allow building barebox
> > > +BAREBOX_CONFIG:qemuarm = "vexpress_defconfig"
> > > +BAREBOX_CONFIG:qemuarm64 = "qemu_virt64_defconfig"
> > > +BAREBOX_CONFIG:qemux86-64 = "efi_defconfig"
> >
> > As all three are different perhaps there could be commentary in the
> > recipe explaining why that and how they differ? Note that there's also
> > a qemuall override if there's a single configuration that works for
> > all qemu targets.
>
> as these three are different archs/machines, I do not find it surprising that 
> they require different
> configs. I assumed that this was self-explaining.

Not at all. What is this 'vexpress' thingy? What does 'express' mean?
Why does it apply to arm, but not arm64? Why arm64 is using
'qemu_virt64', but not any other targets, if that config does not seem
arm-specific? Why is x86 using 'efi' but not the arm targets?

The choices you made here should be explained.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179920): 
https://lists.openembedded.org/g/openembedded-core/message/179920
Mute This Topic: https://lists.openembedded.org/mt/97970650/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/3] oeqa: print stderr in the AssertionError as well

[Martin Jansa]

Hello Luca,

I'm sorry, I've updated the runcmd.RunCmdTests.test_result_assertion test
case to pass with this change just to realize that:
"stderr": subprocess.STDOUT
in self.defaultopts does work and even the stderr output is ending in
stdout, so this change isn't very useful (as I don't see any runcmd users
passing different options than defaultopts).

Please drop 3/3 other 2 changes are independent on it.

I have one more change in this area which is the real fix for esdk tests
with uninative disabled, but that has some weird side-effect which is
triggering:

NOTE: Running task 3807 of 3809
(/OE/build/poky/meta/recipes-core/images/core-image-minimal.bb:
do_populate_lic_deploy)
ERROR: When reparsing
/OE/build/poky/meta/recipes-core/images/core-image-minimal.bb:do_populate_sdk_ext,
the basehash value changed from
8249821d6529e111a2f7f1101632fe140639df54a700e2c604a99ea150541a6d to
86086c51c409799a0d4d2a4fcac9e7e245cb36d86f236dcf7093e428a7c37ac9. The
metadata is not deterministic and this needs to be fixed.
ERROR: The following commands may help:
ERROR: $ bitbake core-image-minimal -cdo_populate_sdk_ext -Snone
ERROR: Then:
ERROR: $ bitbake core-image-minimal -cdo_populate_sdk_ext -Sprintdiff

which I haven't resolved yet, so it might be a while before I send this 4th
change.

Regards,

On Tue, Apr 11, 2023 at 2:28 PM Luca Ceresoli 
wrote:

> Hello Martin,
>
> On Tue, 11 Apr 2023 11:03:48 +0200
> "Martin Jansa"  wrote:
>
> > Signed-off-by: Martin Jansa 
> > ---
> >  meta/lib/oeqa/utils/commands.py | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/lib/oeqa/utils/commands.py
> b/meta/lib/oeqa/utils/commands.py
> > index c1f533802e..7b2f6ec124 100644
> > --- a/meta/lib/oeqa/utils/commands.py
> > +++ b/meta/lib/oeqa/utils/commands.py
> > @@ -209,7 +209,7 @@ def runCmd(command, ignore_status=False,
> timeout=None, assert_error=True, sync=T
> >  exc_output = "\n... (last %d lines of output)\n" %
> limit_exc_output + \
> >   '\n'.join(split[-limit_exc_output:])
> >  if assert_error:
> > -raise AssertionError("Command '%s' returned non-zero exit
> status %d:\n%s" % (command, result.status, exc_output))
> > +raise AssertionError("Command '%s' returned non-zero exit
> status %d:\nstderr: %s\nstdout:\n%s" % (command, result.status,
> result.error, exc_output))
>
> Testing with this series produces errors on the selftest builds:
>
> -8<-
>
> AssertionError: Command 'echo foobar >&2; false' returned non-zero exit
> status 1:
> stderr:
> stdout:
> foobar
>
> During handling of the above exception, another exception occurred:
>
> Traceback (most recent call last):
>   File
> "/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/runcmd.py",
> line 61, in test_result_assertion
> self.assertRaisesRegexp(AssertionError, "Command 'echo .* false'
> returned non-zero exit status 1:\nfoobar",
>   File "/usr/lib/python3.9/unittest/case.py", line 1329, in deprecated_func
> return original_func(*args, **kwargs)
>   File "/usr/lib/python3.9/unittest/case.py", line 1276, in
> assertRaisesRegex
> return context.handle('assertRaisesRegex', args, kwargs)
>   File "/usr/lib/python3.9/unittest/case.py", line 201, in handle
> callable_obj(*args, **kwargs)
>   File "/usr/lib/python3.9/unittest/case.py", line 239, in __exit__
> self._raiseFailure('"{}" does not match "{}"'.format(
>   File "/usr/lib/python3.9/unittest/case.py", line 163, in _raiseFailure
> raise self.test_case.failureException(msg)
> AssertionError: "Command 'echo .* false' returned non-zero exit status 1:
> foobar" does not match "Command 'echo foobar >&2; false' returned non-zero
> exit status 1:
> stderr:
> stdout:
> foobar"
>
> -8<-
>
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5002/steps/14/logs/stdio
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5044/steps/14/logs/stdio
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5053/steps/14/logs/stdio
>
> https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5083/steps/15/logs/stdio
>
>
> --
> Luca Ceresoli, Bootlin
> Embedded Linux and Kernel engineering
> https://bootlin.com
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179919): 
https://lists.openembedded.org/g/openembedded-core/message/179919
Mute This Topic: https://lists.openembedded.org/mt/98193877/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/3] oeqa: print stderr in the AssertionError as well

[Luca Ceresoli via lists.openembedded.org]

Hello Martin,

On Tue, 11 Apr 2023 11:03:48 +0200
"Martin Jansa"  wrote:

> Signed-off-by: Martin Jansa 
> ---
>  meta/lib/oeqa/utils/commands.py | 2 +-
>  1 file changed, 1 insertion(+), 1 deletion(-)
> 
> diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
> index c1f533802e..7b2f6ec124 100644
> --- a/meta/lib/oeqa/utils/commands.py
> +++ b/meta/lib/oeqa/utils/commands.py
> @@ -209,7 +209,7 @@ def runCmd(command, ignore_status=False, timeout=None, 
> assert_error=True, sync=T
>  exc_output = "\n... (last %d lines of output)\n" % 
> limit_exc_output + \
>   '\n'.join(split[-limit_exc_output:])
>  if assert_error:
> -raise AssertionError("Command '%s' returned non-zero exit status 
> %d:\n%s" % (command, result.status, exc_output))
> +raise AssertionError("Command '%s' returned non-zero exit status 
> %d:\nstderr: %s\nstdout:\n%s" % (command, result.status, result.error, 
> exc_output))

Testing with this series produces errors on the selftest builds:

-8<-

AssertionError: Command 'echo foobar >&2; false' returned non-zero exit status 
1:
stderr: 
stdout:
foobar

During handling of the above exception, another exception occurred:

Traceback (most recent call last):
  File 
"/home/pokybuild/yocto-worker/oe-selftest-debian/build/meta/lib/oeqa/selftest/cases/runcmd.py",
 line 61, in test_result_assertion
self.assertRaisesRegexp(AssertionError, "Command 'echo .* false' returned 
non-zero exit status 1:\nfoobar",
  File "/usr/lib/python3.9/unittest/case.py", line 1329, in deprecated_func
return original_func(*args, **kwargs)
  File "/usr/lib/python3.9/unittest/case.py", line 1276, in assertRaisesRegex
return context.handle('assertRaisesRegex', args, kwargs)
  File "/usr/lib/python3.9/unittest/case.py", line 201, in handle
callable_obj(*args, **kwargs)
  File "/usr/lib/python3.9/unittest/case.py", line 239, in __exit__
self._raiseFailure('"{}" does not match "{}"'.format(
  File "/usr/lib/python3.9/unittest/case.py", line 163, in _raiseFailure
raise self.test_case.failureException(msg)
AssertionError: "Command 'echo .* false' returned non-zero exit status 1:
foobar" does not match "Command 'echo foobar >&2; false' returned non-zero exit 
status 1:
stderr: 
stdout:
foobar"

-8<-

https://autobuilder.yoctoproject.org/typhoon/#/builders/80/builds/5002/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/86/builds/5044/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/5053/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#/builders/87/builds/5083/steps/15/logs/stdio


-- 
Luca Ceresoli, Bootlin
Embedded Linux and Kernel engineering
https://bootlin.com

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179918): 
https://lists.openembedded.org/g/openembedded-core/message/179918
Mute This Topic: https://lists.openembedded.org/mt/98193877/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] kernel-fitimage: Fix the default dtb config check

[Arslan Ahmad]

From: Arslan Ahmad 

The current check for default dtb image checks if the file exists and is
not empty but appends a slash to the path due to which the file is never
found. It also doesn't replace slash in filename with _ as done when
populating the DTB variable. A better way to check the existence of the
device tree would be from the list of DTBs since this is used during
compilation.

Signed-off-by: Arslan Ahmad 
---
 meta/classes-recipe/kernel-fitimage.bbclass | 36 +++--
 1 file changed, 26 insertions(+), 10 deletions(-)

diff --git a/meta/classes-recipe/kernel-fitimage.bbclass 
b/meta/classes-recipe/kernel-fitimage.bbclass
index b77747404f..6684478c33 100644
--- a/meta/classes-recipe/kernel-fitimage.bbclass
+++ b/meta/classes-recipe/kernel-fitimage.bbclass
@@ -388,6 +388,7 @@ symlink_points_below() {
 # $5 ... u-boot script ID
 # $6 ... config ID
 # $7 ... default flag
+# $8 ... default DTB image name
 fitimage_emit_section_config() {
 
conf_csum="${FIT_HASH_ALG}"
@@ -404,6 +405,7 @@ fitimage_emit_section_config() {
bootscr_id="$5"
config_id="$6"
default_flag="$7"
+   default_dtb_image="$8"
 
# Test if we have any DTBs at all
sep=""
@@ -415,7 +417,6 @@ fitimage_emit_section_config() {
bootscr_line=""
setup_line=""
default_line=""
-   default_dtb_image="${FIT_CONF_DEFAULT_DTB}"
 
dtb_image_sect=$(symlink_points_below $dtb_image 
"${EXTERNAL_KERNEL_DEVICETREE}")
if [ -z "$dtb_image_sect" ]; then
@@ -469,11 +470,7 @@ fitimage_emit_section_config() {
# Select default node as user specified dtb when
# multiple dtb exists.
if [ -n "$default_dtb_image" ]; then
-   if [ -s 
"${EXTERNAL_KERNEL_DEVICETREE}/$default_dtb_image" ]; then
-   default_line="default = 
\"${FIT_CONF_PREFIX}$default_dtb_image\";"
-   else
-   bbwarn "Couldn't find a valid user 
specified dtb in ${EXTERNAL_KERNEL_DEVICETREE}/$default_dtb_image"
-   fi
+   default_line="default = 
\"${FIT_CONF_PREFIX}$default_dtb_image\";"
else
default_line="default = 
\"${FIT_CONF_PREFIX}$dtb_image\";"
fi
@@ -555,7 +552,8 @@ fitimage_assemble() {
ramdiskcount=$3
setupcount=""
bootscr_id=""
-   rm -f $1 ${KERNEL_OUTPUT_DIR}/$2
+   default_dtb_image=""
+   rm -f $1 arch/${ARCH}/boot/$2
 
if [ -n "${UBOOT_SIGN_IMG_KEYNAME}" -a "${UBOOT_SIGN_KEYNAME}" = 
"${UBOOT_SIGN_IMG_KEYNAME}" ]; then
bbfatal "Keys used to sign images and configuration nodes must 
be different."
@@ -593,6 +591,13 @@ fitimage_assemble() {
DTB_PATH="${KERNEL_OUTPUT_DIR}/$DTB"
fi
 
+   # Set the default dtb image if it exists in the 
devicetree.
+   if [ ${FIT_CONF_DEFAULT_DTB} = $DTB ];then
+   default_dtb_image=$(echo "$DTB" | tr '/' '_')
+   fi
+
+   DTB=$(echo "$DTB" | tr '/' '_')
+
# Skip DTB if we've picked it up previously
echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
 
@@ -606,6 +611,13 @@ fitimage_assemble() {
dtbcount=1
for DTB in $(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtb' 
-printf '%P\n' | sort) \
$(find "${EXTERNAL_KERNEL_DEVICETREE}" -name '*.dtbo' -printf 
'%P\n' | sort); do
+   # Set the default dtb image if it exists in the 
devicetree.
+   if [ ${FIT_CONF_DEFAULT_DTB} = $DTB ];then
+   default_dtb_image=$(echo "$DTB" | tr '/' '_')
+   fi
+
+   DTB=$(echo "$DTB" | tr '/' '_')
+
# Skip DTB/DTBO if we've picked it up previously
echo "$DTBS" | tr ' ' '\n' | grep -xq "$DTB" && continue
 
@@ -619,6 +631,10 @@ fitimage_assemble() {
done
fi
 
+   if [ -n "${FIT_CONF_DEFAULT_DTB}" ] && [ -z $default_dtb_image ]; then 
+   bbwarn "${FIT_CONF_DEFAULT_DTB} is not available in the list of 
device trees."
+   fi
+
#
# Step 3: Prepare a u-boot script section
#
@@ -691,15 +707,15 @@ fitimage_assemble() {
for DTB in ${DTBS}; do
dtb_ext=${DTB##*.}
if [ "$dtb_ext" = "dtbo" ]; then
-   fitimage_emit_section_config $1 "" "$DTB" "" 
"$bootscr_id" "" "`expr $i = $dtbcount`"
+   fitimage_emit_section_config $1 "" "$DTB" "" 
"$bootscr_id" "" "`expr $i = $dtbcount`" "$default_dtb_image"

[OE-core] [kirkstone][PATCH] curl: CVE-2023-27533 TELNET option IAC injection

[Hitendra Prajapati]

Upstream-Status: Backport from 
https://github.com/curl/curl/commit/0c28ba2faae2d7da780a66d2446045a560192cdc && 
https://github.com/curl/curl/commit/538b1e79a6e7b0bb829ab4cecc828d32105d0684

Signed-off-by: Hitendra Prajapati 
---
 .../curl/curl/CVE-2023-27533.patch| 208 ++
 meta/recipes-support/curl/curl_7.82.0.bb  |   1 +
 2 files changed, 209 insertions(+)
 create mode 100644 meta/recipes-support/curl/curl/CVE-2023-27533.patch

diff --git a/meta/recipes-support/curl/curl/CVE-2023-27533.patch 
b/meta/recipes-support/curl/curl/CVE-2023-27533.patch
new file mode 100644
index 00..b69b20c85a
--- /dev/null
+++ b/meta/recipes-support/curl/curl/CVE-2023-27533.patch
@@ -0,0 +1,208 @@
+From 538b1e79a6e7b0bb829ab4cecc828d32105d0684 Mon Sep 17 00:00:00 2001
+From: Daniel Stenberg 
+Date: Mon, 6 Mar 2023 12:07:33 +0100
+Subject: [PATCH] telnet: parse telnet options without sscanf & only accept 
option arguments in ascii
+
+To avoid embedded telnet negotiation commands etc.
+
+Reported-by: Harry Sintonen
+Closes #10728
+
+CVE: CVE-2023-27533
+Upstream-Status: Backport 
[https://github.com/curl/curl/commit/0c28ba2faae2d7da780a66d2446045a560192cdc 
&& https://github.com/curl/curl/commit/538b1e79a6e7b0bb829ab4cecc828d32105d0684]
+
+Signed-off-by: Hitendra Prajapati 
+---
+ lib/telnet.c | 149 +++
+ 1 file changed, 91 insertions(+), 58 deletions(-)
+
+diff --git a/lib/telnet.c b/lib/telnet.c
+index e709973..3ecd680 100644
+--- a/lib/telnet.c
 b/lib/telnet.c
+@@ -768,22 +768,32 @@ static void printsub(struct Curl_easy *data,
+   }
+ }
+ 
++static bool str_is_nonascii(const char *str)
++{
++  size_t len = strlen(str);
++  while(len--) {
++if(*str & 0x80)
++  return TRUE;
++str++;
++  }
++  return FALSE;
++}
++
+ static CURLcode check_telnet_options(struct Curl_easy *data)
+ {
+   struct curl_slist *head;
+   struct curl_slist *beg;
+-  char option_keyword[128] = "";
+-  char option_arg[256] = "";
+   struct TELNET *tn = data->req.p.telnet;
+-  struct connectdata *conn = data->conn;
+   CURLcode result = CURLE_OK;
+-  int binary_option;
+ 
+   /* Add the user name as an environment variable if it
+  was given on the command line */
+   if(data->state.aptr.user) {
+-msnprintf(option_arg, sizeof(option_arg), "USER,%s", conn->user);
+-beg = curl_slist_append(tn->telnet_vars, option_arg);
++char buffer[256];
++if(str_is_nonascii(data->conn->user))
++  return CURLE_BAD_FUNCTION_ARGUMENT;
++msnprintf(buffer, sizeof(buffer), "USER,%s", data->conn->user);
++beg = curl_slist_append(tn->telnet_vars, buffer);
+ if(!beg) {
+   curl_slist_free_all(tn->telnet_vars);
+   tn->telnet_vars = NULL;
+@@ -793,68 +803,91 @@ static CURLcode check_telnet_options(struct Curl_easy 
*data)
+ tn->us_preferred[CURL_TELOPT_NEW_ENVIRON] = CURL_YES;
+   }
+ 
+-  for(head = data->set.telnet_options; head; head = head->next) {
+-if(sscanf(head->data, "%127[^= ]%*[ =]%255s",
+-  option_keyword, option_arg) == 2) {
+-
+-  /* Terminal type */
+-  if(strcasecompare(option_keyword, "TTYPE")) {
+-strncpy(tn->subopt_ttype, option_arg, 31);
+-tn->subopt_ttype[31] = 0; /* String termination */
+-tn->us_preferred[CURL_TELOPT_TTYPE] = CURL_YES;
++  for(head = data->set.telnet_options; head && !result; head = head->next) {
++size_t olen;
++char *option = head->data;
++char *arg;
++char *sep = strchr(option, '=');
++if(sep) {
++  olen = sep - option;
++  arg = ++sep;
++  if(str_is_nonascii(arg))
+ continue;
+-  }
++  switch(olen) {
++  case 5:
++/* Terminal type */
++if(strncasecompare(option, "TTYPE", 5)) {
++  strncpy(tn->subopt_ttype, arg, 31);
++  tn->subopt_ttype[31] = 0; /* String termination */
++  tn->us_preferred[CURL_TELOPT_TTYPE] = CURL_YES;
++}
++else
++  result = CURLE_UNKNOWN_OPTION;
++break;
+ 
+-  /* Display variable */
+-  if(strcasecompare(option_keyword, "XDISPLOC")) {
+-strncpy(tn->subopt_xdisploc, option_arg, 127);
+-tn->subopt_xdisploc[127] = 0; /* String termination */
+-tn->us_preferred[CURL_TELOPT_XDISPLOC] = CURL_YES;
+-continue;
+-  }
++  case 8:
++/* Display variable */
++if(strncasecompare(option, "XDISPLOC", 8)) {
++  strncpy(tn->subopt_xdisploc, arg, 127);
++  tn->subopt_xdisploc[127] = 0; /* String termination */
++  tn->us_preferred[CURL_TELOPT_XDISPLOC] = CURL_YES;
++}
++else
++  result = CURLE_UNKNOWN_OPTION;
++break;
+ 
+-  /* Environment variable */
+-  if(strcasecompare(option_keyword, "NEW_ENV")) {
+-beg = curl_slist_append(tn->telnet_vars, option_arg);
+-if(!beg) {
+-  result = CURLE_OUT_OF_MEMORY;
+-  break;
++  case 7:
++/* Environment 

[OE-core] [PATCH v4] migration-guides: update 4.2 migration and release notes

[Michael Opdenacker via lists.openembedded.org]

From: Michael Opdenacker 

Signed-off-by: Michael Opdenacker 
CC: Frederic Martinsons 
CC: Marta Rybczynska 
CC: Paul Eggleton 
CC: Alex Kiernan 
CC: Alexis Lothoré `
+for example.
+
+The ``cargo-update-recipe-crates`` utility
+:yocto_git:`has been extended 
`
+to include such checksums. So, in case you need to add the list of checksums
+to a recipe just inheriting the :ref:`ref-classes-cargo` class so far, you can
+follow these steps:
+
+#.  Make the recipe inherit :ref:`ref-classes-cargo-update-recipe-crates`
+#.  Remove all ``crate://`` lines from the recipe
+#.  Create an empty ``${BPN}-crates.inc`` file and make your recipe require it
+#.  Execute ``bitbake -c update_crates your_recipe``
+#.  Copy and paste the output of BitBake about the missing checksums into the
+``${BPN}-crates.inc`` file.
+
 .. _migration-4.2-qa-checks:
 
 QA check changes
 
 
+.. _migration-4.2-supported-distributions:
+
+Supported distributions
+~~~
+
+This release supports running BitBake on new GNU/Linux distributions:
+
+-  Fedora 36 and 37
+-  AlmaLinux 8.7 and 9.1
+-  OpenSuse 15.4
+
+On the other hand, some earlier distributions are no longer supported:
+
+-  Debian 10.x
+-  Fedora 34 and 35
+-  AlmaLinux 8.5
+
+See :ref:`all supported distributions `.
+
 .. _migration-4.2-misc-changes:
 
 Miscellaneous changes
@@ -30,6 +97,7 @@ Miscellaneous changes
 
 -  The ``OEBasic`` signature handler (see :term:`BB_SIGNATURE_HANDLER`) has 
been
removed.
+  
 
 .. _migration-4.2-removed-variables:
 
@@ -38,7 +106,7 @@ Removed variables
 
 The following variables have been removed:
 
--  ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by 
:term:``SERIAL_CONSOLES``.
+-  ``SERIAL_CONSOLE``, deprecated since version 2.6, replaced by 
:term:`SERIAL_CONSOLES`.
 
 .. _migration-4.2-removed-recipes:
 
@@ -47,3 +115,17 @@ Removed recipes
 
 The following recipes have been removed in this release:
 
+-  ``python3-picobuild``: after switching to ``python3-build``
+-  ``python3-strict-rfc3339``: unmaintained and not needed by anything in
+   :oe_git:`openembedded-core `
+   or :oe_git:`meta-openembedded `.
+
+.. _migration-4.2-removed-classes:
+
+Removed classes
+~~~
+
+The following classes have been removed in this release:
+
+-  ``rust-bin``: no longer used in Poky
+
diff --git a/documentation/migration-guides/release-notes-4.2.rst 
b/documentation/migration-guides/release-notes-4.2.rst
index edafe378b0..b6e278ee5d 100644
--- a/documentation/migration-guides/release-notes-4.2.rst
+++ b/documentation/migration-guides/release-notes-4.2.rst
@@ -6,23 +6,90 @@ Release notes for 4.2 (mickledore)
 New Features / Enhancements in 4.2
 ~~
 
-- Python 3.8 is the minimum Python version required on the build host.
-  For host distributions that do not provide it, this is included as part of 
the
-  :term:`buildtools` tarball.
+-  Python 3.8 is the minimum Python version required on the build host.
+   For host distributions that do not provide it, this is included as part of 
the
+   :term:`buildtools` tarball.
 
-- This release now supports a new ``addpylib`` directive to enable
-  Python libraries within layers.
+-  BitBake in this release now supports a new ``addpylib`` directive to enable
+   Python libraries within layers.
 
-  This directive should be added to your layer configuration,
-  as in the below example from ``meta/conf/layer.conf``::
+   This directive should be added to your layer configuration
+   as in the below example from ``meta/conf/layer.conf``::
 
- addpylib ${LAYERDIR}/lib oe
+  addpylib ${LAYERDIR}/lib oe
+
+-  BitBake has seen multiple internal changes that may impact
+   memory and disk usage as well as parsing time, in particular:
+
+   -  BitBake's Cooker server is now multithreaded.
+
+   -  BitBake's cache has been extended to include more hash
+  debugging data, but has also been optimized to :yocto_git:`compress
+  cache data 
`.
+
+   -  BitBake's Cooker server :yocto_git:`can now be pinged
+  https://git.yoctoproject.org/poky/commit/?h=mickledore=26f255da09>`
+  from the UI.
 
 -  Architecture-specific enhancements:
 
+   -  This release adds initial support for the
+  :wikipedia:`LoongArch `
+  (``loongarch64``) architecture, though there is no testing for it yet.
+
 -  Kernel-related enhancements:
 
 -  QEMU/runqemu enhancements:
 
 -  Image-related enhancements:
 
+-  New variables:
+
+   - :term:`VOLATILE_TMP_DIR` allows to specify
+ whether ``/tmp`` should be on persistent storage
+ or in RAM.
+
+-  Rust improvements:
+
+   -  This release adds Cargo support on the target, and includes
+  automated QA tests for this functionality.
+
+   -  It also supports checksums for Rust crates and makes
+  them mandatory for each crate in a recipe.
+
+-  Testing:
+
+   -  The ptest 

ODP: [OE-core] [PATCH] tar: extend numeric-owner to ACL entries

[Piotr Łobacz]

Hi Fabien,
That was my intention to leave you as an author as you have found and fixed 
this issue 

Btw. this patch saved my time for applying stupid solutions...
Additionaly I have also created a bug report on that in ubuntu 
https://bugs.launchpad.net/ubuntu/+source/tar/+bug/2015539

BR
Piotr

Od: Fabian Grünbichler 
Wysłane: wtorek, 11 kwietnia 2023 09:44
Do: Alexandre Belloni ; Piotr Łobacz 

DW: openembedded-core@lists.openembedded.org 

Temat: Re: [OE-core] [PATCH] tar: extend numeric-owner to ACL entries

On April 9, 2023 1:53 am, Alexandre Belloni wrote:
> Hello,
>
> On 07/04/2023 14:58:46+0200, Piotr Łobacz wrote:
>> ACL entries store references to numeric uids/gids. on platforms that
>> have libacl, use `acl_to_any_text` to generate ACL strings that preserve
>> those numeric identifiers if `numeric-owner` is set (instead of doing a
>> conversion to user/group name, like the acl_to_text function does).
>>
>> [..]
>>
>> +
>> +actual output (getfacl) - note the missing user entry:
>> + # file: file
>> + # owner: 0
>> + # group: 0
>> + user::rw-
>> + group::r--
>> + other::r--
>> +
>
> This patch is missing the Upstream-Status tag here
>
>> +Signed-off-by: Fabian Grünbichler 

(Original patch author, thanks for the CC!)

FWIW, I got no response from upstream or the Debian tar maintainers[0].

But nice to see that other distros are interested as well :) maybe we
could try to ping the upstream report or sending the patch to some
relevant devel list?

The bug was not important enough for us to justify carrying our own,
custom tar packages, so we'd ideally still want to see this upstreamed.

0: 
https://eur04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fbugs.debian.org%2Fcgi-bin%2Fbugreport.cgi%3Fbug%3D1004430=05%7C01%7Cp.lobacz%40welotec.com%7Cd5846947d807488e650108db3a60b11e%7C25111a7f1d5a4c51a4ca7f8e44011b39%7C0%7C0%7C638167959195524735%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C=xYvcBDzx40TfoeX6dE2HQuj3tpP1u2SyX19WNqRWd5Q%3D=0


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

[OE-core] [PATCH 1/3] populate_sdk_ext.bbclass: set METADATA_REVISION with an DISTRO override

[Martin Jansa]

* otherwise it ends '' inside esdk, because of parsing order:
  # $METADATA_REVISION [3 operations]
  #   set /OE/build/test-D/conf/local.conf:43
  # "f2da54ef432eac89b0f18eaad68e602b6990b5de"
  #   immediate /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:9
  # "${@oe.buildcfg.detect_revision(d)}"
  #   set /OE/build/test-D/layers/poky/meta/classes/metadata_scm.bbclass:10
  # [vardepvalue] "${METADATA_REVISION}"
  # pre-expansion value:
  #   ""
  METADATA_REVISION=""

* This causes base-files.do_install and following tasks to have different
  signatures between esdk and the build directory where this esdk was created:

  bitbake-diffsigs 
{test-D,poky/build-uninative-disabled}/tmp/stamps/qemux86_64-poky-linux/base-files/*do_install*sigdata*
  NOTE: Starting bitbake server...
  basehash changed from 
5b6981cf58bfd57d416b0e31611b73a26baae635dd1ac31c08d46f95064c3ffc to 
dbdce042da4d7813d632b6d1cc87a16f728ad20e55fecbc392830e6acf72babd
  Variable METADATA_REVISION value changed from '' to 
'f2da54ef432eac89b0f18eaad68e602b6990b5de'

  and an warning from "python3 /OE/build/test-D/ext-sdk-prepare.py" when eSDK 
is being prepared for use:
  WARNING: The base-files:do_install sig is computed to be 
83b9c9a6ef1145baac5a1e0d08814b9156af239c58fc42df95c25a9cd8a7f201,
but the sig is locked to 
3dc22233059075978e5503691e98e79e7cc60db94259dfcd886bca2291c0add7 in 
SIGGEN_LOCKEDSIGS_t-qemux86-64

Signed-off-by: Martin Jansa 
---
 meta/classes-recipe/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass 
b/meta/classes-recipe/populate_sdk_ext.bbclass
index f619fc9011..7f55c83ee2 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -376,7 +376,7 @@ python copy_buildsystem () {
 f.write('BUILDCFG_HEADER = ""\n\n')
 
 # Write METADATA_REVISION
-f.write('METADATA_REVISION = "%s"\n\n' % 
d.getVar('METADATA_REVISION'))
+f.write('METADATA_REVISION:%s = "%s"\n\n' % (d.getVar('DISTRO'), 
d.getVar('METADATA_REVISION')))
 
 f.write('# Provide a flag to indicate we are in the EXT_SDK 
Context\n')
 f.write('WITHIN_EXT_SDK = "1"\n\n')
-- 
2.40.0


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

[OE-core] [PATCH 2/3] populate_sdk_ext.bbclass: redirect stderr to stdout so that both end in LOGFILE

[Martin Jansa]

* this in the end doesn't help much, I was debugging warning (about 
base-files.do_install
  signature being different than expected) from:

  python3 $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'

  this shows the warning on console, but it doesn't end in $LOGFILE, because it
  writes only contents of cooker log into the $LOGFILE with:

with open(logfile, 'a') as logf:
logf.write('Preparing SDK for %s...\n' % ', '.join(sdk_targets))

ret = run_command_interruptible('BB_SETSCENE_ENFORCE=1 bitbake --quiet 
%s' % ' '.join(sdk_targets))
if not ret:
ret = run_command_interruptible('bitbake --quiet build-sysroots')
lastlog = get_last_consolelog()
if lastlog:
with open(lastlog, 'r') as f:
for line in f:
logf.write(line)
if ret:
print('ERROR: SDK preparation failed: error log written to %s' % 
logfile)
return ret

  maybe we could remove whole support for $LOGFILE parameter and just redirect
  the output like other commands on this line

Signed-off-by: Martin Jansa 
---
 meta/classes-recipe/populate_sdk_ext.bbclass | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/classes-recipe/populate_sdk_ext.bbclass 
b/meta/classes-recipe/populate_sdk_ext.bbclass
index 7f55c83ee2..8146036fa9 100644
--- a/meta/classes-recipe/populate_sdk_ext.bbclass
+++ b/meta/classes-recipe/populate_sdk_ext.bbclass
@@ -739,7 +739,7 @@ sdk_ext_postinst() {
# current working directory when first ran, nor will it set $1 
when
# sourcing a script. That is why this has to look so ugly.
LOGFILE="$target_sdk_dir/preparing_build_system.log"
-   sh -c ". buildtools/environment-setup* > $LOGFILE && cd 
$target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . 
$target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE && 
python3 $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" 
|| { echo "printf 'ERROR: this SDK was not fully installed and needs 
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
+   sh -c ". buildtools/environment-setup* > $LOGFILE 2>&1 && cd 
$target_sdk_dir/`dirname ${oe_init_build_env_path}` && set $target_sdk_dir && . 
$target_sdk_dir/${oe_init_build_env_path} $target_sdk_dir >> $LOGFILE 2>&1 && 
python3 $target_sdk_dir/ext-sdk-prepare.py $LOGFILE '${SDK_INSTALL_TARGETS}'" 
|| { echo "printf 'ERROR: this SDK was not fully installed and needs 
reinstalling\n'" >> $env_setup_script ; exit 1 ; }
fi
if [ -e $target_sdk_dir/ext-sdk-prepare.py ]; then
rm $target_sdk_dir/ext-sdk-prepare.py
-- 
2.40.0


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

[OE-core] [PATCH 3/3] oeqa: print stderr in the AssertionError as well

[Martin Jansa]

Signed-off-by: Martin Jansa 
---
 meta/lib/oeqa/utils/commands.py | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/utils/commands.py b/meta/lib/oeqa/utils/commands.py
index c1f533802e..7b2f6ec124 100644
--- a/meta/lib/oeqa/utils/commands.py
+++ b/meta/lib/oeqa/utils/commands.py
@@ -209,7 +209,7 @@ def runCmd(command, ignore_status=False, timeout=None, 
assert_error=True, sync=T
 exc_output = "\n... (last %d lines of output)\n" % 
limit_exc_output + \
  '\n'.join(split[-limit_exc_output:])
 if assert_error:
-raise AssertionError("Command '%s' returned non-zero exit status 
%d:\n%s" % (command, result.status, exc_output))
+raise AssertionError("Command '%s' returned non-zero exit status 
%d:\nstderr: %s\nstdout:\n%s" % (command, result.status, result.error, 
exc_output))
 else:
 raise CommandError(result.status, command, exc_output)
 
-- 
2.40.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#179913): 
https://lists.openembedded.org/g/openembedded-core/message/179913
Mute This Topic: https://lists.openembedded.org/mt/98193877/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] rust: Upgrade 1.68.1 -> 1.68.2

[Alex Kiernan]

Cool, was just picking up the pieces to check it, but I'll leave it now!

On Tue, 11 Apr 2023, 08:07 Khem Raj,  wrote:

> alright my builds for cargo on qemuriscv32/musl went ok so I guess its ok.
>
> On Mon, Apr 10, 2023 at 11:11 AM Khem Raj  wrote:
> >
> > Thanks, I'll also check it out. I think the checksums for the musl
> > patch would need updating I think as the versions of these crates
> > might have changed.
> >
> > On Mon, Apr 10, 2023 at 10:30 AM Alexandre Belloni
> >  wrote:
> > >
> > > My current a-full has this patch.
> > >
> > > On 10/04/2023 10:21:16-0700, Khem Raj wrote:
> > > > If possible, Can you test this on top of contrib/abelloni/master-next
> > > > for musl target ?
> > > >
> > > > On Mon, Apr 10, 2023 at 2:42 AM Alex Kiernan 
> wrote:
> > > > >
> > > > > Changes:
> > > > >
> > > > > * Update the GitHub RSA host key bundled within Cargo. The key was
> > > > >   rotated by GitHub on 2023-03-24 after the old one leaked.
> > > > > * Mark the old GitHub RSA host key as revoked. This will prevent
> Cargo
> > > > >   from accepting the leaked key even when trusted by the system.
> > > > > * Add support for @revoked and a better error message for
> > > > >   @cert-authority in Cargo’s SSH host key verification
> > > > >
> > > > > Signed-off-by: Alex Kiernan 
> > > > > ---
> > > > >
> > > > >  meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb}
> | 0
> > > > >  .../rust/{libstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb}
>  | 0
> > > > >  ...t-cross-canadian_1.68.1.bb => rust-cross-canadian_1.68.2.bb}
> | 0
> > > > >  .../rust/{rust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb}
>  | 0
> > > > >  meta/recipes-devtools/rust/rust-source.inc  |
> 2 +-
> > > > >  meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb}
>  | 0
> > > > >  6 files changed, 1 insertion(+), 1 deletion(-)
> > > > >  rename meta/recipes-devtools/rust/{cargo_1.68.1.bb =>
> cargo_1.68.2.bb} (100%)
> > > > >  rename meta/recipes-devtools/rust/{libstd-rs_1.68.1.bb =>
> libstd-rs_1.68.2.bb} (100%)
> > > > >  rename meta/recipes-devtools/rust/{rust-cross-canadian_1.68.1.bb
> => rust-cross-canadian_1.68.2.bb} (100%)
> > > > >  rename meta/recipes-devtools/rust/{rust-llvm_1.68.1.bb =>
> rust-llvm_1.68.2.bb} (100%)
> > > > >  rename meta/recipes-devtools/rust/{rust_1.68.1.bb =>
> rust_1.68.2.bb} (100%)
> > > > >
> > > > > diff --git a/meta/recipes-devtools/rust/cargo_1.68.1.bb
> b/meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > > similarity index 100%
> > > > > rename from meta/recipes-devtools/rust/cargo_1.68.1.bb
> > > > > rename to meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
> b/meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > > similarity index 100%
> > > > > rename from meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
> > > > > rename to meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > > diff --git a/meta/recipes-devtools/rust/
> rust-cross-canadian_1.68.1.bb b/meta/recipes-devtools/rust/
> rust-cross-canadian_1.68.2.bb
> > > > > similarity index 100%
> > > > > rename from meta/recipes-devtools/rust/
> rust-cross-canadian_1.68.1.bb
> > > > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
> > > > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
> b/meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > > similarity index 100%
> > > > > rename from meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
> > > > > rename to meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > > diff --git a/meta/recipes-devtools/rust/rust-source.inc
> b/meta/recipes-devtools/rust/rust-source.inc
> > > > > index c8f5a5a9c4c4..6d3a4b131e26 100644
> > > > > --- a/meta/recipes-devtools/rust/rust-source.inc
> > > > > +++ b/meta/recipes-devtools/rust/rust-source.inc
> > > > > @@ -7,7 +7,7 @@ SRC_URI += "
> https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > > > >
> file://0001-Do-not-use-LFS64-on-linux-with-musl.patch;patchdir=${RUSTSRC} \
> > > > >  file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> > > > >  "
> > > > > -SRC_URI[rust.sha256sum] =
> "5b8ea94085b65e75c1fa6310e2f90bd706fa80bfcb3544fe26f4037b911d9fb2"
> > > > > +SRC_URI[rust.sha256sum] =
> "ce1a115f6aafa912b4622906a92b626354973afa9288e2c7750df4dcf3390fc0"
> > > > >
> > > > >  RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> > > > >
> > > > > diff --git a/meta/recipes-devtools/rust/rust_1.68.1.bb
> b/meta/recipes-devtools/rust/rust_1.68.2.bb
> > > > > similarity index 100%
> > > > > rename from meta/recipes-devtools/rust/rust_1.68.1.bb
> > > > > rename to meta/recipes-devtools/rust/rust_1.68.2.bb
> > > > > --
> > > > > 2.39.0
> > > > >
> > > > >
> > > > >
> > > > >
> > >
> > > >
> > > > 
> > > >
> > >
> > >
> > > --
> > > 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 

Re: [OE-core] [PATCH v3 2/2] oeqa/selftest: change deprecated usage of run_serial

[Louis Rannou]

On 09/04/2023 11:39, Alexandre Belloni wrote:

Hello,

This breaks the overlayfs tests:

https://autobuilder.yoctoproject.org/typhoon/#builders/87/builds/5075/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#builders/86/builds/5036/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#builders/80/builds/4994/steps/14/logs/stdio
https://autobuilder.yoctoproject.org/typhoon/#builders/79/builds/5045/steps/15/logs/stdio


Hello,

Indeed, the overlayfs test was not supposed to remain in the commit

Louis


On 07/04/2023 16:26:22+0200, Louis Rannou wrote:

Prefer the new function run_serial_socket. Change calls where the modification
is easy.

Signed-off-by: Louis Rannou 
---
  meta/lib/oeqa/selftest/cases/debuginfod.py |  3 +-
  meta/lib/oeqa/selftest/cases/gdbserver.py  |  7 ++--
  meta/lib/oeqa/selftest/cases/locales.py|  8 ++---
  meta/lib/oeqa/selftest/cases/overlayfs.py  | 42 ++
  meta/lib/oeqa/selftest/cases/package.py|  7 ++--
  meta/lib/oeqa/selftest/cases/runqemu.py|  2 +-
  6 files changed, 43 insertions(+), 26 deletions(-)

diff --git a/meta/lib/oeqa/selftest/cases/debuginfod.py 
b/meta/lib/oeqa/selftest/cases/debuginfod.py
index 37f51760fb..2571ce6989 100644
--- a/meta/lib/oeqa/selftest/cases/debuginfod.py
+++ b/meta/lib/oeqa/selftest/cases/debuginfod.py
@@ -99,7 +99,8 @@ CORE_IMAGE_EXTRA_INSTALL += "elfutils"
  % (qemu.server_ip, port)
  )
  self.logger.info(f"Starting client {cmd}")
-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
+self.assertEqual(0, status)
  # This should be more comprehensive
  self.assertIn("/.cache/debuginfod_client/", output)
  finally:
diff --git a/meta/lib/oeqa/selftest/cases/gdbserver.py 
b/meta/lib/oeqa/selftest/cases/gdbserver.py
index 9da97ae780..4f8c7d620f 100644
--- a/meta/lib/oeqa/selftest/cases/gdbserver.py
+++ b/meta/lib/oeqa/selftest/cases/gdbserver.py
@@ -43,7 +43,8 @@ CORE_IMAGE_EXTRA_INSTALL = "gdbserver"
  shutil.unpack_archive(filename, debugfs)
  
  with runqemu("core-image-minimal", runqemuparams="nographic") as qemu:

-status, output = qemu.run_serial("kmod --help")
+status, output = qemu.run_serial_socket("kmod --help")
+self.assertEqual(status, 0)
  self.assertIn("modprobe", output)
  
  with concurrent.futures.ThreadPoolExecutor(max_workers=1) as executor:

@@ -61,7 +62,7 @@ CORE_IMAGE_EXTRA_INSTALL = "gdbserver"
  self.fail("Timed out connecting to gdb")
  future = executor.submit(run_gdb)
  
-status, output = qemu.run_serial("gdbserver --once : kmod --help")

-self.assertEqual(status, 1)
+status, output = qemu.run_serial_socket("gdbserver --once : 
kmod --help")
+self.assertEqual(status, 0)
  # The future either returns None, or raises an exception
  future.result()
diff --git a/meta/lib/oeqa/selftest/cases/locales.py 
b/meta/lib/oeqa/selftest/cases/locales.py
index 4ca8ffb7aa..98026d2c80 100644
--- a/meta/lib/oeqa/selftest/cases/locales.py
+++ b/meta/lib/oeqa/selftest/cases/locales.py
@@ -27,15 +27,15 @@ class LocalesTest(OESelftestTestCase):
  
  with runqemu("core-image-minimal", ssh=False, runqemuparams='nographic') as qemu:

  cmd = "locale -a"
-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
  # output must includes fr_FR or fr_FR.UTF-8
-self.assertEqual(status, 1, msg='locale test command failed: 
output: %s' % output)
+self.assertEqual(status, 0, msg='locale test command failed: 
output: %s' % output)
  self.assertIn("fr_FR", output, msg='locale -a test failed: 
output: %s' % output)
  
  cmd = "localedef --list-archive -v"

-status, output = qemu.run_serial(cmd)
+status, output = qemu.run_serial_socket(cmd)
  # output must includes fr_FR.utf8
-self.assertEqual(status, 1, msg='localedef test command failed: 
output: %s' % output)
+self.assertEqual(status, 0, msg='localedef test command failed: 
output: %s' % output)
  self.assertIn("fr_FR.utf8", output, msg='localedef test failed: 
output: %s' % output)
  
  def test_locales_on(self):

diff --git a/meta/lib/oeqa/selftest/cases/overlayfs.py 
b/meta/lib/oeqa/selftest/cases/overlayfs.py
index b4f0663828..753821490b 100644
--- a/meta/lib/oeqa/selftest/cases/overlayfs.py
+++ b/meta/lib/oeqa/selftest/cases/overlayfs.py
@@ -183,20 +183,24 @@ EOT
  
  with runqemu('core-image-minimal') as qemu:

  # Check that application service started
-status, 

Re: [OE-Core][PATCH] rust: Upgrade 1.68.1 -> 1.68.2

[Khem Raj]

alright my builds for cargo on qemuriscv32/musl went ok so I guess its ok.

On Mon, Apr 10, 2023 at 11:11 AM Khem Raj  wrote:
>
> Thanks, I'll also check it out. I think the checksums for the musl
> patch would need updating I think as the versions of these crates
> might have changed.
>
> On Mon, Apr 10, 2023 at 10:30 AM Alexandre Belloni
>  wrote:
> >
> > My current a-full has this patch.
> >
> > On 10/04/2023 10:21:16-0700, Khem Raj wrote:
> > > If possible, Can you test this on top of contrib/abelloni/master-next
> > > for musl target ?
> > >
> > > On Mon, Apr 10, 2023 at 2:42 AM Alex Kiernan  
> > > wrote:
> > > >
> > > > Changes:
> > > >
> > > > * Update the GitHub RSA host key bundled within Cargo. The key was
> > > >   rotated by GitHub on 2023-03-24 after the old one leaked.
> > > > * Mark the old GitHub RSA host key as revoked. This will prevent Cargo
> > > >   from accepting the leaked key even when trusted by the system.
> > > > * Add support for @revoked and a better error message for
> > > >   @cert-authority in Cargo’s SSH host key verification
> > > >
> > > > Signed-off-by: Alex Kiernan 
> > > > ---
> > > >
> > > >  meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb} | 0
> > > >  .../rust/{libstd-rs_1.68.1.bb => libstd-rs_1.68.2.bb}   | 0
> > > >  ...t-cross-canadian_1.68.1.bb => rust-cross-canadian_1.68.2.bb} | 0
> > > >  .../rust/{rust-llvm_1.68.1.bb => rust-llvm_1.68.2.bb}   | 0
> > > >  meta/recipes-devtools/rust/rust-source.inc  | 2 +-
> > > >  meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb}   | 0
> > > >  6 files changed, 1 insertion(+), 1 deletion(-)
> > > >  rename meta/recipes-devtools/rust/{cargo_1.68.1.bb => cargo_1.68.2.bb} 
> > > > (100%)
> > > >  rename meta/recipes-devtools/rust/{libstd-rs_1.68.1.bb => 
> > > > libstd-rs_1.68.2.bb} (100%)
> > > >  rename meta/recipes-devtools/rust/{rust-cross-canadian_1.68.1.bb => 
> > > > rust-cross-canadian_1.68.2.bb} (100%)
> > > >  rename meta/recipes-devtools/rust/{rust-llvm_1.68.1.bb => 
> > > > rust-llvm_1.68.2.bb} (100%)
> > > >  rename meta/recipes-devtools/rust/{rust_1.68.1.bb => rust_1.68.2.bb} 
> > > > (100%)
> > > >
> > > > diff --git a/meta/recipes-devtools/rust/cargo_1.68.1.bb 
> > > > b/meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/rust/cargo_1.68.1.bb
> > > > rename to meta/recipes-devtools/rust/cargo_1.68.2.bb
> > > > diff --git a/meta/recipes-devtools/rust/libstd-rs_1.68.1.bb 
> > > > b/meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/rust/libstd-rs_1.68.1.bb
> > > > rename to meta/recipes-devtools/rust/libstd-rs_1.68.2.bb
> > > > diff --git a/meta/recipes-devtools/rust/rust-cross-canadian_1.68.1.bb 
> > > > b/meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/rust/rust-cross-canadian_1.68.1.bb
> > > > rename to meta/recipes-devtools/rust/rust-cross-canadian_1.68.2.bb
> > > > diff --git a/meta/recipes-devtools/rust/rust-llvm_1.68.1.bb 
> > > > b/meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/rust/rust-llvm_1.68.1.bb
> > > > rename to meta/recipes-devtools/rust/rust-llvm_1.68.2.bb
> > > > diff --git a/meta/recipes-devtools/rust/rust-source.inc 
> > > > b/meta/recipes-devtools/rust/rust-source.inc
> > > > index c8f5a5a9c4c4..6d3a4b131e26 100644
> > > > --- a/meta/recipes-devtools/rust/rust-source.inc
> > > > +++ b/meta/recipes-devtools/rust/rust-source.inc
> > > > @@ -7,7 +7,7 @@ SRC_URI += 
> > > > "https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
> > > >  
> > > > file://0001-Do-not-use-LFS64-on-linux-with-musl.patch;patchdir=${RUSTSRC}
> > > >  \
> > > >  file://zlib-off64_t.patch;patchdir=${RUSTSRC} \
> > > >  "
> > > > -SRC_URI[rust.sha256sum] = 
> > > > "5b8ea94085b65e75c1fa6310e2f90bd706fa80bfcb3544fe26f4037b911d9fb2"
> > > > +SRC_URI[rust.sha256sum] = 
> > > > "ce1a115f6aafa912b4622906a92b626354973afa9288e2c7750df4dcf3390fc0"
> > > >
> > > >  RUSTSRC = "${WORKDIR}/rustc-${RUST_VERSION}-src"
> > > >
> > > > diff --git a/meta/recipes-devtools/rust/rust_1.68.1.bb 
> > > > b/meta/recipes-devtools/rust/rust_1.68.2.bb
> > > > similarity index 100%
> > > > rename from meta/recipes-devtools/rust/rust_1.68.1.bb
> > > > rename to meta/recipes-devtools/rust/rust_1.68.2.bb
> > > > --
> > > > 2.39.0
> > > >
> > > >
> > > >
> > > >
> >
> > >
> > > 
> > >
> >
> >
> > --
> > 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 (#179908): 
https://lists.openembedded.org/g/openembedded-core/message/179908
Mute This Topic: https://lists.openembedded.org/mt/98172309/21656
Group Owner: