[OE-core] Patchtest results for [PATCH 3/3] gnu-efi: upgrade 3.0.17 -> 3.0.18

2024-05-16 Thread Patchtest
Thank you for your submission. Patchtest identified one
or more issues with the patch. Please see the log below for
more information:

---
Testing patch 
/home/patchtest/share/mboxes/3-3-gnu-efi-upgrade-3.0.17---3.0.18.patch

FAIL: test src uri left files: Patches not removed from tree. Remove them and 
amend the submitted mbox (test_metadata.TestMetadata.test_src_uri_left_files)

PASS: pretest src uri left files 
(test_metadata.TestMetadata.pretest_src_uri_left_files)
PASS: test CVE check ignore (test_metadata.TestMetadata.test_cve_check_ignore)
PASS: test Signed-off-by presence 
(test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence 
(test_mbox.TestMbox.test_commit_message_presence)
PASS: test lic files chksum modified not mentioned 
(test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test mbox format (test_mbox.TestMbox.test_mbox_format)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)

SKIP: pretest pylint: No python related patches, skipping test 
(test_python_pylint.PyLint.pretest_pylint)
SKIP: test CVE tag format: No new CVE patches introduced 
(test_patch.TestPatch.test_cve_tag_format)
SKIP: test Signed-off-by presence: No new CVE patches introduced 
(test_patch.TestPatch.test_signed_off_by_presence)
SKIP: test Upstream-Status presence: No new CVE patches introduced 
(test_patch.TestPatch.test_upstream_status_presence_format)
SKIP: test bugzilla entry format: No bug ID found 
(test_mbox.TestMbox.test_bugzilla_entry_format)
SKIP: test lic files chksum presence: No added recipes, skipping test 
(test_metadata.TestMetadata.test_lic_files_chksum_presence)
SKIP: test license presence: No added recipes, skipping test 
(test_metadata.TestMetadata.test_license_presence)
SKIP: test pylint: No python related patches, skipping test 
(test_python_pylint.PyLint.test_pylint)
SKIP: test series merge on head: Merge test is disabled for now 
(test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test summary presence: No added recipes, skipping test 
(test_metadata.TestMetadata.test_summary_presence)
SKIP: test target mailing list: Series merged, no reason to check other mailing 
lists (test_mbox.TestMbox.test_target_mailing_list)

---

Please address the issues identified and
submit a new revision of the patch, or alternatively, reply to this
email with an explanation of why the patch should be accepted. If you
believe these results are due to an error in patchtest, please submit a
bug at https://bugzilla.yoctoproject.org/ (use the 'Patchtest' category
under 'Yocto Project Subprojects'). For more information on specific
failures, see: https://wiki.yoctoproject.org/wiki/Patchtest. Thank
you!

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199503): 
https://lists.openembedded.org/g/openembedded-core/message/199503
Mute This Topic: https://lists.openembedded.org/mt/106146796/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] libsdl2: upgrade 2.30.2 -> 2.30.3

2024-05-16 Thread Yi Zhao
Changelog:
https://github.com/libsdl-org/SDL/releases/tag/release-2.30.3

This is a stable bugfix release, with the following changes:
 - Fixed Win+V handling (pasting from clipboard history) on Windows
 - Fixed Caps Lock and Backspace key mapping for the Colemak keyboard layout on 
Windows
 - Fixed mouse warp on XWayland
 - Reduced startup time when scanning for game controllers on Linux
 - Fixed building with C89 compilers
 - Fixed building with the GDK SDK on Windows

Signed-off-by: Yi Zhao 
---
 .../libsdl2/{libsdl2_2.30.2.bb => libsdl2_2.30.3.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/libsdl2/{libsdl2_2.30.2.bb => libsdl2_2.30.3.bb} 
(97%)

diff --git a/meta/recipes-graphics/libsdl2/libsdl2_2.30.2.bb 
b/meta/recipes-graphics/libsdl2/libsdl2_2.30.3.bb
similarity index 97%
rename from meta/recipes-graphics/libsdl2/libsdl2_2.30.2.bb
rename to meta/recipes-graphics/libsdl2/libsdl2_2.30.3.bb
index f9dacb288c..68cc2790e5 100644
--- a/meta/recipes-graphics/libsdl2/libsdl2_2.30.2.bb
+++ b/meta/recipes-graphics/libsdl2/libsdl2_2.30.3.bb
@@ -25,7 +25,7 @@ SRC_URI = "http://www.libsdl.org/release/SDL2-${PV}.tar.gz;
 
 S = "${WORKDIR}/SDL2-${PV}"
 
-SRC_URI[sha256sum] = 
"891d66ac8cae51361d3229e3336ebec1c407a8a2a063b61df14f5fdf3ab5ac31"
+SRC_URI[sha256sum] = 
"820440072f8f5b50188c1dae104f2ad25984de268785be40c41a099a510f0aec"
 
 inherit cmake lib_package binconfig-disabled pkgconfig upstream-version-is-even
 
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199501): 
https://lists.openembedded.org/g/openembedded-core/message/199501
Mute This Topic: https://lists.openembedded.org/mt/106146618/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] gnu-efi: upgrade 3.0.17 -> 3.0.18

2024-05-16 Thread Yi Zhao
* Drop backport patches.
* Refresh patches.

Signed-off-by: Yi Zhao 
---
 ...-parallel-make-failure-for-archives.patch} | 12 ---
 ...0001-riscv64-adjust-type-definitions.patch | 34 ---
 .../0001-riscv64-ignore-unknown-relocs.patch  | 32 -
 ...002-Do-not-treat-warnings-as-errors.patch} | 21 +---
 .../gnu-efi-3.0.9-fix-clang-build.patch   | 24 -
 .../{gnu-efi_3.0.17.bb => gnu-efi_3.0.18.bb}  |  9 ++---
 6 files changed, 27 insertions(+), 105 deletions(-)
 rename meta/recipes-bsp/gnu-efi/gnu-efi/{parallel-make-archives.patch => 
0001-Fix-parallel-make-failure-for-archives.patch} (85%)
 delete mode 100644 
meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-adjust-type-definitions.patch
 delete mode 100644 
meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-ignore-unknown-relocs.patch
 rename meta/recipes-bsp/gnu-efi/gnu-efi/{no-werror.patch => 
0002-Do-not-treat-warnings-as-errors.patch} (57%)
 delete mode 100644 
meta/recipes-bsp/gnu-efi/gnu-efi/gnu-efi-3.0.9-fix-clang-build.patch
 rename meta/recipes-bsp/gnu-efi/{gnu-efi_3.0.17.bb => gnu-efi_3.0.18.bb} (88%)

diff --git a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch 
b/meta/recipes-bsp/gnu-efi/gnu-efi/0001-Fix-parallel-make-failure-for-archives.patch
similarity index 85%
rename from meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
rename to 
meta/recipes-bsp/gnu-efi/gnu-efi/0001-Fix-parallel-make-failure-for-archives.patch
index 63d9b6fc31..3c11baca0c 100644
--- a/meta/recipes-bsp/gnu-efi/gnu-efi/parallel-make-archives.patch
+++ 
b/meta/recipes-bsp/gnu-efi/gnu-efi/0001-Fix-parallel-make-failure-for-archives.patch
@@ -1,4 +1,4 @@
-From f56ddb00a656af2e84f839738fad19909ac65047 Mon Sep 17 00:00:00 2001
+From 70e30774debb9ab5d53a29c183f86fc569661b7c Mon Sep 17 00:00:00 2001
 From: Saul Wold 
 Date: Sun, 9 Mar 2014 15:22:15 +0200
 Subject: [PATCH] Fix parallel make failure for archives
@@ -19,16 +19,15 @@ Signed-off-by: Darren Hart 
 Signed-off-by: California Sullivan 
 [Rebased for 3.0.8]
 Signed-off-by: Yi Zhao 
-
 ---
  lib/Makefile | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
 diff --git a/lib/Makefile b/lib/Makefile
-index 1fc6a47..54b0ca7 100644
+index ec1f9e3..79a794d 100644
 --- a/lib/Makefile
 +++ b/lib/Makefile
-@@ -77,7 +77,7 @@ libsubdirs:
+@@ -75,7 +75,7 @@ libsubdirs:
  $(OBJS): libsubdirs
  
  libefi.a: $(OBJS)
@@ -36,4 +35,7 @@ index 1fc6a47..54b0ca7 100644
 +  $(AR) $(ARFLAGS) $@ $(OBJS)
  
  clean:
-   rm -f libefi.a *~ $(OBJS) */*.o
+   @rm -vf libefi.a *~ $(OBJS) */*.o
+-- 
+2.25.1
+
diff --git 
a/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-adjust-type-definitions.patch 
b/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-adjust-type-definitions.patch
deleted file mode 100644
index 3475606264..00
--- 
a/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-adjust-type-definitions.patch
+++ /dev/null
@@ -1,34 +0,0 @@
-From 1de509497826faa0ad84b82f5e2c3d21ee613459 Mon Sep 17 00:00:00 2001
-From: Moody Liu 
-Date: Sat, 13 May 2023 17:39:16 +0100
-Subject: [PATCH] riscv64: adjust type definitions
-
-CHAR8 needs to be defined while BOOLEAN should be removed
-here to prevent typedef conflicts
-
-Upstream-Status: Backport 
[https://sourceforge.net/p/gnu-efi/code/ci/1de509497826faa0ad84b82f5e2c3d21ee613459/]
-Signed-off-by: Moody Liu 

- inc/riscv64/efibind.h | 4 +---
- 1 file changed, 1 insertion(+), 3 deletions(-)
-
-diff --git a/inc/riscv64/efibind.h b/inc/riscv64/efibind.h
-index 4fdf81d..d8b4f39 100644
 a/inc/riscv64/efibind.h
-+++ b/inc/riscv64/efibind.h
-@@ -32,11 +32,9 @@ typedef uint16_tUINT16;
- typedef int16_t INT16;
- typedef uint8_t UINT8;
- typedef int8_t  INT8;
-+typedef charCHAR8;
- typedef wchar_t CHAR16;
- #define WCHAR   CHAR16
--#ifndef BOOLEAN
--typedef uint8_t BOOLEAN;
--#endif
- #undef VOID
- typedef voidVOID;
- typedef int64_t INTN;
--- 
-2.41.0
-
diff --git 
a/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-ignore-unknown-relocs.patch 
b/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-ignore-unknown-relocs.patch
deleted file mode 100644
index 5b3c152c5e..00
--- a/meta/recipes-bsp/gnu-efi/gnu-efi/0001-riscv64-ignore-unknown-relocs.patch
+++ /dev/null
@@ -1,32 +0,0 @@
-From 708f66acfec9a86f237726d45095cbd380fd83ca Mon Sep 17 00:00:00 2001
-From: Callum Farmer 
-Date: Wed, 21 Jun 2023 11:32:28 +0100
-Subject: [PATCH] riscv64: ignore unknown relocs
-
-Sometimes ld emits relocs such as R_RISCV_64 for unwind symbols
-these don't need to be handled yet so just can be skipped otherwise
-the binary will never load
-
-Upstream-Status: Backport 
[https://sourceforge.net/p/gnu-efi/code/ci/708f66acfec9a86f237726d45095cbd380fd83ca/]
-Signed-off-by: Callum Farmer 

- gnuefi/reloc_riscv64.c | 3 +--
- 1 file changed, 1 insertion(+), 2 deletions(-)
-
-diff --git 

[OE-core] [PATCH 1/3] dropbear: upgrade 2024.84 -> 2024.85

2024-05-16 Thread Yi Zhao
Changelog:
https://matt.ucc.asn.au/dropbear/CHANGES

This release fixes build regressions in 2024.84:
 - Fix build failure when SHA1 is disabled
 - Fix build failure when DROPBEAR_CLI_PUBKEY_AUTH disabled
 - Update debian/ directory with changed paths

Signed-off-by: Yi Zhao 
---
 .../0001-urandom-xauth-changes-to-options.h.patch   |  8 
 .../dropbear/0005-dropbear-enable-pam.patch | 13 +
 .../dropbear/0006-dropbear-configuration-file.patch | 11 ---
 .../dropbear/dropbear-disable-weak-ciphers.patch|  9 +++--
 .../{dropbear_2024.84.bb => dropbear_2024.85.bb}|  2 +-
 5 files changed, 17 insertions(+), 26 deletions(-)
 rename meta/recipes-core/dropbear/{dropbear_2024.84.bb => dropbear_2024.85.bb} 
(98%)

diff --git 
a/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
 
b/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
index c74f09e484..9c1dd3f606 100644
--- 
a/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
+++ 
b/meta/recipes-core/dropbear/dropbear/0001-urandom-xauth-changes-to-options.h.patch
@@ -1,4 +1,7 @@
-Subject: [PATCH 1/6] urandom-xauth-changes-to-options.h
+From cdc6a4a57a86d8116a92a5d905993e65cf723556 Mon Sep 17 00:00:00 2001
+From: Richard Purdie 
+Date: Wed, 31 Aug 2005 10:45:47 +
+Subject: [PATCH] urandom-xauth-changes-to-options.h
 
 Upstream-Status: Inappropriate [configuration]
 ---
@@ -18,6 +21,3 @@ index 6e970bb..ccc8b47 100644
  
  
  /* If you want to enable running an sftp server (such as the one included with
--- 
-2.34.1
-
diff --git a/meta/recipes-core/dropbear/dropbear/0005-dropbear-enable-pam.patch 
b/meta/recipes-core/dropbear/dropbear/0005-dropbear-enable-pam.patch
index fe667ddc25..6743f506e9 100644
--- a/meta/recipes-core/dropbear/dropbear/0005-dropbear-enable-pam.patch
+++ b/meta/recipes-core/dropbear/dropbear/0005-dropbear-enable-pam.patch
@@ -1,7 +1,7 @@
-From b8cece92ba19aa77ac013ea161bfe4c7147747c9 Mon Sep 17 00:00:00 2001
+From 253ca01f0fc50dbaeb2ff8bcece0c34256eba94f Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen 
 Date: Wed, 2 Dec 2015 11:36:02 +0200
-Subject: Enable pam
+Subject: [PATCH] Enable pam
 
 We need modify file default_options.h besides enabling pam in
 configure if we want dropbear to support pam.
@@ -15,10 +15,10 @@ Signed-off-by: Jussi Kukkonen 
  1 file changed, 2 insertions(+), 2 deletions(-)
 
 diff --git a/src/default_options.h b/src/default_options.h
-index 0e3d027..349338c 100644
+index ccc8b47..12768d1 100644
 --- a/src/default_options.h
 +++ b/src/default_options.h
-@@ -210,7 +210,7 @@ group1 in Dropbear server too */
+@@ -228,7 +228,7 @@ group1 in Dropbear server too */
  
  /* Authentication Types - at least one required.
 RFC Draft requires pubkey auth, and recommends password */
@@ -27,7 +27,7 @@ index 0e3d027..349338c 100644
  
  /* Note: PAM auth is quite simple and only works for PAM modules which just do
   * a simple "Login: " "Password: " (you can edit the strings in 
svr-authpam.c).
-@@ -218,7 +218,7 @@ group1 in Dropbear server too */
+@@ -236,7 +236,7 @@ group1 in Dropbear server too */
   * but there's an interface via a PAM module. It won't work for more complex
   * PAM challenge/response.
   * You can't enable both PASSWORD and PAM. */
@@ -36,6 +36,3 @@ index 0e3d027..349338c 100644
  
  /* ~/.ssh/authorized_keys authentication.
   * You must define DROPBEAR_SVR_PUBKEY_AUTH in order to use plugins. */
--- 
-2.25.1
-
diff --git 
a/meta/recipes-core/dropbear/dropbear/0006-dropbear-configuration-file.patch 
b/meta/recipes-core/dropbear/dropbear/0006-dropbear-configuration-file.patch
index f54f634a4e..44861088cc 100644
--- a/meta/recipes-core/dropbear/dropbear/0006-dropbear-configuration-file.patch
+++ b/meta/recipes-core/dropbear/dropbear/0006-dropbear-configuration-file.patch
@@ -1,4 +1,4 @@
-From e3a5db1b6d3f6382a15b2266458c26c645a10f18 Mon Sep 17 00:00:00 2001
+From 16b147f97f0938cddb55ec1c90bc919c13f26fc0 Mon Sep 17 00:00:00 2001
 From: Mingli Yu 
 Date: Thu, 6 Sep 2018 15:54:00 +0800
 Subject: [PATCH] dropbear configuration file
@@ -15,11 +15,11 @@ Signed-off-by: Mingli Yu 
  src/svr-authpam.c | 2 +-
  1 file changed, 1 insertion(+), 1 deletion(-)
 
-diff --git a/srec/svr-authpam.c b/src/svr-authpam.c
-index d201bc9..165ec5c 100644
+diff --git a/src/svr-authpam.c b/src/svr-authpam.c
+index ec14632..026102f 100644
 --- a/src/svr-authpam.c
 +++ b/src/svr-authpam.c
-@@ -223,7 +223,7 @@ void svr_auth_pam(int valid_user) {
+@@ -224,7 +224,7 @@ void svr_auth_pam(int valid_user) {
}
  
/* Init pam */
@@ -28,6 +28,3 @@ index d201bc9..165ec5c 100644
dropbear_log(LOG_WARNING, "pam_start() failed, rc=%d, %s", 
rc, pam_strerror(pamHandlep, rc));
goto cleanup;
--- 
-2.7.4
-
diff --git 
a/meta/recipes-core/dropbear/dropbear/dropbear-disable-weak-ciphers.patch 

[OE-core] A question about nodejs & node-gyp

2024-05-16 Thread imikec
Is there a recipe or explanation on how to integrate prebuilt nodejs and 
node-gyp for an embedded platform?

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

2024-05-16 Thread Martin Jansa
On Thu, May 16, 2024 at 10:05 PM Khem Raj  wrote:
>
> On Wed, May 15, 2024 at 10:29 PM Martin Jansa via
> lists.openembedded.org 
> wrote:
> >
> > Hi Peter,
> >
> > what about BSD-4-Clause-UC, BSD-3-Clause, ISC licenses included in glibc.
> >
> > I've suggested to add them long time ago in:
> > https://lists.openembedded.org/g/openembedded-core/topic/91285771#msg166005
> > which resulted in:
> > https://sourceware.org/bugzilla/show_bug.cgi?id=28007
> > https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html
> > but the discussion upstream stopped shortly after and the oe-core
> > change was never merged because of that. Maybe it's time to re-check
> > and ping upstream again after 2 years.
>
> Perhaps yes.
>
> On a tangent here, but I also think we should use
> https://github.com/nexB/scancode-toolkit
> to extract the license information from source code itself to update
> the LICENSE field
> in the recipes.

Yeah, we've added it 10+ years ago, because Blackduck or something was
complaining about missing license identifiers in:
https://github.com/openwebos/meta-webos/commit/8eb313e4303defbe495cf7f91974799046975fca
then I've dropped this 2 years ago in:
https://github.com/webosose/meta-webosose/commit/95d7c2798d6f0a7a227db9631775eff7a2928596
after failed attempt to upstream this to oe-core and upstream glibc reaction.

The LICENSE information in the recipe isn't complete and as Peter
wanted to fix "or later" part I though he might be interested in other
licenses as well.

There weren't many changes in:
https://sourceware.org/git/?p=glibc.git;a=history;f=LICENSES;h=530893b1dc9ea00755603c68fb36bd4fc38a7be8;hb=HEAD
but the last commit looks interesting.

Cheers,

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

2024-05-16 Thread Khem Raj
On Wed, May 15, 2024 at 10:29 PM Martin Jansa via
lists.openembedded.org 
wrote:
>
> Hi Peter,
>
> what about BSD-4-Clause-UC, BSD-3-Clause, ISC licenses included in glibc.
>
> I've suggested to add them long time ago in:
> https://lists.openembedded.org/g/openembedded-core/topic/91285771#msg166005
> which resulted in:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28007
> https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html
> but the discussion upstream stopped shortly after and the oe-core
> change was never merged because of that. Maybe it's time to re-check
> and ping upstream again after 2 years.

Perhaps yes.

On a tangent here, but I also think we should use
https://github.com/nexB/scancode-toolkit
to extract the license information from source code itself to update
the LICENSE field
in the recipes.

>
> Cheers,
>
> On Mon, May 6, 2024 at 9:46 AM Peter Marko via lists.openembedded.org
>  wrote:
> >
> > From: Peter Marko 
> >
> > The license per [1] is LGPL-2.1-or-later and
> > [2] converted last LGPL-2.1-only references.
> >
> > License-Update: corrected from LGPL-2.1-only to LGPL-2.1-or-later based on 
> > [1] and [2]
> >
> > [1] https://www.gnu.org/software/libc/
> > [2] 
> > https://sourceware.org/git/?p=glibc.git;a=commitdiff;h=273a835fe7c685cc54266bb8b502787bad5e9bae
> >
> > Signed-off-by: Peter Marko 
> > ---
> >  meta/recipes-core/glibc/glibc-common.inc | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/meta/recipes-core/glibc/glibc-common.inc 
> > b/meta/recipes-core/glibc/glibc-common.inc
> > index b9516e77f0..91a3f5bcd5 100644
> > --- a/meta/recipes-core/glibc/glibc-common.inc
> > +++ b/meta/recipes-core/glibc/glibc-common.inc
> > @@ -2,7 +2,7 @@ SUMMARY = "GLIBC (GNU C Library)"
> >  DESCRIPTION = "The GNU C Library is used as the system C library in most 
> > systems with the Linux kernel."
> >  HOMEPAGE = "http://www.gnu.org/software/libc/libc.html;
> >  SECTION = "libs"
> > -LICENSE = "GPL-2.0-only & LGPL-2.1-only"
> > +LICENSE = "GPL-2.0-only & LGPL-2.1-or-later"
> >
> >  LIC_FILES_CHKSUM ?= "file://LICENSES;md5=f77e878d320e99e94ae9a4aea7f491d1 \
> >file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
> > --
> > 2.30.2
> >
> >
> >
> >
>
> 
>

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

2024-05-16 Thread Peter Marko via lists.openembedded.org
Hi Martin,

license handling is a very complicated topic, especially for historical 
projects like glibc with ton of files with diverse origin.
License scanning programs will find 15+ different licenses here and some of 
them may not be even available in yocto license list.
I submitted this particular commit because I was responsible for an update with 
commit which was asking for it.

The discussion you linked about adding SPDX identifiers is something which 
would really help.
It would enable license discovery without need of big data software and allow 
to accurately set the LICENSE field also by SW developers.

Peter

-Original Message-
From: Martin Jansa  
Sent: Thursday, May 16, 2024 7:30
To: Marko, Peter (ADV D EU SK BFS1) 
Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core][PATCH v2] glibc: correct license

> Hi Peter,
>
> what about BSD-4-Clause-UC, BSD-3-Clause, ISC licenses included in glibc.
>
> I've suggested to add them long time ago in:
> https://lists.openembedded.org/g/openembedded-core/topic/91285771#msg166005
> which resulted in:
> https://sourceware.org/bugzilla/show_bug.cgi?id=28007
> https://sourceware.org/pipermail/libc-alpha/2022-May/139167.html
> but the discussion upstream stopped shortly after and the oe-core change was 
> never merged because of that. Maybe it's time to re-check and ping upstream 
> again after 2 years.
>
> Cheers,
>
> On Mon, May 6, 2024 at 9:46 AM Peter Marko via lists.openembedded.org 
>  wrote:
> ...

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199496): 
https://lists.openembedded.org/g/openembedded-core/message/199496
Mute This Topic: https://lists.openembedded.org/mt/105935723/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 10/13] iptables: remove unneeded 0002-iptables-xshared.h-add-missing-sys.types.h-include.patch

2024-05-16 Thread Khem Raj
On Thu, May 16, 2024 at 4:27 AM Alexander Kanavin via
lists.openembedded.org 
wrote:
>
> From: Alexander Kanavin 
>
> Somewhere on the way it ceased to be necessary.

Thats due it being applied upstream [1] so mentioning that is perhaps
going to qualify this a bit more.

[1] 
https://git.netfilter.org/iptables/commit/iptables/xshared.h?id=f319389525b066b7dc6d389c88f16a0df3b8f189

>
> Signed-off-by: Alexander Kanavin 
> ---
>  ...ed.h-add-missing-sys.types.h-include.patch | 31 ---
>  .../iptables/iptables_1.8.10.bb   |  1 -
>  2 files changed, 32 deletions(-)
>  delete mode 100644 
> meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
>
> diff --git 
> a/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
>  
> b/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
> deleted file mode 100644
> index a190c7e8ae2..000
> --- 
> a/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
> +++ /dev/null
> @@ -1,31 +0,0 @@
> -From 465e3ef77f1763d225adc76220e43ee9bd73b178 Mon Sep 17 00:00:00 2001
> -From: Alexander Kanavin 
> -Date: Tue, 17 May 2022 10:56:59 +0200
> -Subject: [PATCH] iptables/xshared.h: add missing sys.types.h include
> -
> -This resolves the build error under musl:
> -
> -| ../../../../../../../workspace/sources/iptables/iptables/xshared.h:83:56: 
> error: unknown type name 'u_int16_t'; did you mean 'uint16_t'?
> -|83 | set_option(unsigned int *options, unsigned int option, u_int16_t 
> *invflg,
> -|   |^
> -|   |uint16_t
> -
> -Upstream-Status: Submitted [via email to p...@nwl.cc]
> -Signed-off-by: Alexander Kanavin 
> -
> 
> - iptables/xshared.h | 1 +
> - 1 file changed, 1 insertion(+)
> -
> -diff --git a/iptables/xshared.h b/iptables/xshared.h
> -index a200e0d..f543dbf 100644
>  a/iptables/xshared.h
> -+++ b/iptables/xshared.h
> -@@ -6,6 +6,7 @@
> - #include 
> - #include 
> - #include 
> -+#include 
> - #include 
> - #include 
> - #include 
> diff --git a/meta/recipes-extended/iptables/iptables_1.8.10.bb 
> b/meta/recipes-extended/iptables/iptables_1.8.10.bb
> index 5a878977425..cbd727b75df 100644
> --- a/meta/recipes-extended/iptables/iptables_1.8.10.bb
> +++ b/meta/recipes-extended/iptables/iptables_1.8.10.bb
> @@ -14,7 +14,6 @@ SRC_URI = 
> "http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.xz \
> file://ip6tables.service \
> file://ip6tables.rules \
> 
> file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \
> -   
> file://0002-iptables-xshared.h-add-missing-sys.types.h-include.patch \
> 
> file://0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch \
> "
>  SRC_URI[sha256sum] = 
> "5cc255c189356e317d070755ce9371eb63a1b783c34498fb8c30264f3cc59c9c"
> --
> 2.39.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199495): 
https://lists.openembedded.org/g/openembedded-core/message/199495
Mute This Topic: https://lists.openembedded.org/mt/106132526/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] iso/live/hddimg images, cdrecord, burnia, the future

2024-05-16 Thread Alexander Kanavin
On Thu, 16 May 2024 at 17:57, Ross Burton via lists.openembedded.org
 wrote:
> > I'm fine with moving out iso but hddimg has proven to be used by more
> > that you'd think. It also has fairly complex code in core which if
> > we're keeping it, I'd like a way to test it…
>
> Unfortunately an hddimg is an ISO on a FAT, so they’re tangled together.  
> hddimg are _horrible_...

We can also do it with a two step deprecation process. I'm going to
write a proposal for formalising that, as there are quite a few more
things I want out of core, but the key to getting there is knowing who
the users are and how they're using those things. The only way to find
out is to give them deprecation warnings.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199494): 
https://lists.openembedded.org/g/openembedded-core/message/199494
Mute This Topic: https://lists.openembedded.org/mt/106134701/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] iso/live/hddimg images, cdrecord, burnia, the future

2024-05-16 Thread Ross Burton
On 16 May 2024, at 16:53, Richard Purdie  
wrote:
> I'm fine with moving out iso but hddimg has proven to be used by more
> that you'd think. It also has fairly complex code in core which if
> we're keeping it, I'd like a way to test it…

Unfortunately an hddimg is an ISO on a FAT, so they’re tangled together.  
hddimg are _horrible_...

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199493): 
https://lists.openembedded.org/g/openembedded-core/message/199493
Mute This Topic: https://lists.openembedded.org/mt/106134701/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] iso/live/hddimg images, cdrecord, burnia, the future

2024-05-16 Thread Richard Purdie
On Thu, 2024-05-16 at 13:47 +, Ross Burton via lists.openembedded.org wrote:
> oe-core has an ‘iso’ image type that creates ISO9660 images for
> booting from a CD/DVD.  At the moment this is implemented using
> cdrtools (aka cdrecord) but this has “legal complications” meaning a
> number of mainstream distributions don’t use cdrtools [1], and the
> project is - generously speaking - only somewhat maintained as part
> of an uber-repository at
> https://codeberg.org/schilytools/schilytools.  None of this is ideal.
> 
> Back when cdrtools moved to the CDDL and the distros decided this was
> not acceptable, Debian created a fork called cdrkit based on the last
> GPL release.  This has no licensing issues but is now abandoned,
> notably the Debian packaging of cdrkit has a number of patches which
> are not upstreamed.
> 
> Against this background, the libburnia project has been quietly busy
> since ~2007.  This is a fresh implementation with wrappers that
> behave like cdrtools, is GPLv2 licensed, and still actively
> maintained[2].
> 
> I’m proposing that we switch the ISO image type to using libburnia
> instead of cdrtools.  I’ve verified that this is just a
> s/mkisofs/xorrisofs/ in image-live.bbclass and the resulting ISO is
> almost identical and boots successfully (in a qemu).
> 
> I’m _also_ proposing that we admit that ISO images and Yocto have
> very limited overlap, and instead of moving the libburnia recipes
> from meta-filesystems (libburn, libisofs, libisoburn) we just
> document that ISO generation requires meta-filesystems to be added. 
> The big catch here is that live images are actually ISOs, but for
> this I believe that very few people actually use the live/hddimg
> images and this won’t be missed from core.  My entirely unresearched
> guess is that some people use hddimg but they don’t need to: a
> traditional partitioned disk image can be written to a
> disk/stick/card and works just as well to boot, and the initramfs-
> based installer should work in that environment too.
> 
> Thoughts?

I'm fine with moving out iso but hddimg has proven to be used by more
that you'd think. It also has fairly complex code in core which if
we're keeping it, I'd like a way to test it...

Cheers,

Richard

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



Re: [OE-core][kirkstone][PATCH 1/1] bluez5: Fix CVE-2023-50230, CVE-2023-50229 and CVE-2023-27349

2024-05-16 Thread Steve Sakoman
This overlaps with the following commit in kirkstone:

https://git.yoctoproject.org/poky/commit/?h=kirkstone=688f3725d2bc14f1343d2d3fb9b13c58c1140089

Please submit a V2 which omits the already fixed CVEs

Thanks!

Steve

On Tue, May 14, 2024 at 10:54 PM Soumya via lists.openembedded.org
 wrote:
>
> From: Soumya Sambu 
>
> CVE-2023-50230:
> BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code
> Execution Vulnerability. This vulnerability allows network-adjacent
> attackers to execute arbitrary code on affected installations of BlueZ.
> User interaction is required to exploit this vulnerability in that the
> target must connect to a malicious Bluetooth device. The specific flaw
> exists within the handling of the Phone Book Access profile. The issue
> results from the lack of proper validation of the length of user-supplied
> data prior to copying it to a fixed-length heap-based buffer. An attacker
> can leverage this vulnerability to execute code in the context of root.
> Was ZDI-CAN-20938.
>
> CVE-2023-50229:
> BlueZ Phone Book Access Profile Heap-based Buffer Overflow Remote Code
> Execution Vulnerability. This vulnerability allows network-adjacent
> attackers to execute arbitrary code on affected installations of BlueZ.
> User interaction is required to exploit this vulnerability in that the
> target must connect to a malicious Bluetooth device. The specific flaw
> exists within the handling of the Phone Book Access profile. The issue
> results from the lack of proper validation of the length of user-supplied
> data prior to copying it to a fixed-length heap-based buffer. An attacker
> can leverage this vulnerability to execute code in the context of root.
> Was ZDI-CAN-20936.
>
> CVE-2023-27349:
> BlueZ Audio Profile AVRCP Improper Validation of Array Index Remote Code
> Execution Vulnerability. This vulnerability allows network-adjacent
> attackers to execute arbitrary code via Bluetooth on affected installations
> of BlueZ. User interaction is required to exploit this vulnerability in
> that the target must connect to a malicious device. The specific flaw
> exists within the handling of the AVRCP protocol. The issue results from
> the lack of proper validation of user-supplied data, which can result in a
> write past the end of an allocated buffer. An attacker can leverage this
> vulnerability to execute code in the context of root. Was ZDI-CAN-19908.
>
> References:
> https://nvd.nist.gov/vuln/detail/CVE-2023-50230
> https://nvd.nist.gov/vuln/detail/CVE-2023-50229
> https://nvd.nist.gov/vuln/detail/CVE-2023-27349
>
> Signed-off-by: Soumya Sambu 
> ---
>  meta/recipes-connectivity/bluez5/bluez5.inc   |  4 +-
>  .../bluez5/bluez5/CVE-2023-27349.patch| 52 ++
>  .../CVE-2023-50230-CVE-2023-50229.patch   | 71 +++
>  3 files changed, 126 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-connectivity/bluez5/bluez5/CVE-2023-27349.patch
>  create mode 100644 
> meta/recipes-connectivity/bluez5/bluez5/CVE-2023-50230-CVE-2023-50229.patch
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5.inc 
> b/meta/recipes-connectivity/bluez5/bluez5.inc
> index 7786b65670..a752975b3a 100644
> --- a/meta/recipes-connectivity/bluez5/bluez5.inc
> +++ b/meta/recipes-connectivity/bluez5/bluez5.inc
> @@ -54,7 +54,9 @@ SRC_URI = 
> "${KERNELORG_MIRROR}/linux/bluetooth/bluez-${PV}.tar.xz \
> ${@bb.utils.contains('DISTRO_FEATURES', 'systemd', '', 
> 'file://0001-Allow-using-obexd-without-systemd-in-the-user-sessio.patch', d)} 
> \
> 
> file://0001-tests-add-a-target-for-building-tests-without-runnin.patch \
> file://0001-test-gatt-Fix-hung-issue.patch \
> -  file://CVE-2023-45866.patch \
> +   file://CVE-2023-45866.patch \
> +   file://CVE-2023-50230-CVE-2023-50229.patch \
> +   file://CVE-2023-27349.patch \
> "
>  S = "${WORKDIR}/bluez-${PV}"
>
> diff --git a/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-27349.patch 
> b/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-27349.patch
> new file mode 100644
> index 00..26edb3a5cb
> --- /dev/null
> +++ b/meta/recipes-connectivity/bluez5/bluez5/CVE-2023-27349.patch
> @@ -0,0 +1,52 @@
> +From f54299a850676d92c3dafd83e9174fcfe420ccc9 Mon Sep 17 00:00:00 2001
> +From: Luiz Augusto von Dentz 
> +Date: Wed, 22 Mar 2023 11:34:24 -0700
> +Subject: [PATCH] avrcp: Fix crash while handling unsupported events
> +
> +The following crash can be observed if the remote peer send and
> +unsupported event:
> +
> +ERROR: AddressSanitizer: heap-use-after-free on address 0x60b000148f11
> + at pc 0x559644552088 bp 0x7ffe28b3c7b0 sp 0x7ffe28b3c7a0
> + WRITE of size 1 at 0x60b000148f11 thread T0
> + #0 0x559644552087 in avrcp_handle_event profiles/audio/avrcp.c:3907
> + #1 0x559644536c22 in control_response profiles/audio/avctp.c:939
> + #2 0x5596445379ab in session_cb profiles/audio/avctp.c:1108
> + #3 0x7fbcb3e51c43 in 

Re: [OE-core] [yocto-security] CVE status for scathgap on 2024-05-16 and ask for help

2024-05-16 Thread Jose Quaresma
Marta Rybczynska via lists.yoctoproject.org  escreveu (quinta, 16/05/2024 à(s) 14:20):

> Hello all,
> The prototype CVE check via the MITRE database is giving the following for
> scathgap today (adding maintainers of affected packages in copy):
>
> CVE-2024-32002.json: affected: git 2.44.0
> CVE-2024-32004.json: affected: git 2.44.0
> CVE-2024-32020.json: affected: git 2.44.0
> CVE-2024-32021.json: affected: git 2.44.0
> CVE-2024-3205.json: affected: libyaml 0.2.5
> CVE-2024-32465.json: affected: git 2.44.0
> CVE-2024-33599.json: affected glibc 2.39
> CVE-2024-33600.json: affected: glibc 2.39
> CVE-2024-33601.json: affected: glibc 2.39
> CVE-2024-33602.json: affected: glibc 2.39
>
> I would also like to ask for volunteers to help with looking up the
> following CVEs and submitting fixes to
> https://github.com/mrybczyn/cvelistV5-overrides/tree/overrides if they
> are malformed:
> go: CVE-2024-24788, CVE=2024-24787
>

All the golang was fixed in today bump to 1.22.3
https://patchwork.yoctoproject.org/project/oe-core/patch/20240516102322.301064-1-jose.quare...@foundries.io/

Anyway the CVE-2024-24787 only affects the Apple people on Darwin.

Jose

aiohttp: CVE-2024-30251
> x server: CVE-2024-31053, CVE-2024-31082
> bluez: CVE-2023-27349, CVE-2023-50229, CVE-2023-50230
> gstreamer: CVE-2023-50186, CVE-2023-6
> less: CVE-2024-32407
> ncurses: CVE-2023-45988
> ofono: CVE-2023-4234, CVE-2023-4233
>
> If you have any question on how to do that, ask me.
>
> Kind regards,
> Marta
>
> 
>
>

-- 
Best regards,

José Quaresma

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



[OE-core] iso/live/hddimg images, cdrecord, burnia, the future

2024-05-16 Thread Ross Burton
Hi,

oe-core has an ‘iso’ image type that creates ISO9660 images for booting from a 
CD/DVD.  At the moment this is implemented using cdrtools (aka cdrecord) but 
this has “legal complications” meaning a number of mainstream distributions 
don’t use cdrtools [1], and the project is - generously speaking - only 
somewhat maintained as part of an uber-repository at 
https://codeberg.org/schilytools/schilytools.  None of this is ideal.

Back when cdrtools moved to the CDDL and the distros decided this was not 
acceptable, Debian created a fork called cdrkit based on the last GPL release.  
This has no licensing issues but is now abandoned, notably the Debian packaging 
of cdrkit has a number of patches which are not upstreamed.

Against this background, the libburnia project has been quietly busy since 
~2007.  This is a fresh implementation with wrappers that behave like cdrtools, 
is GPLv2 licensed, and still actively maintained[2].

I’m proposing that we switch the ISO image type to using libburnia instead of 
cdrtools.  I’ve verified that this is just a s/mkisofs/xorrisofs/ in 
image-live.bbclass and the resulting ISO is almost identical and boots 
successfully (in a qemu).

I’m _also_ proposing that we admit that ISO images and Yocto have very limited 
overlap, and instead of moving the libburnia recipes from meta-filesystems 
(libburn, libisofs, libisoburn) we just document that ISO generation requires 
meta-filesystems to be added.  The big catch here is that live images are 
actually ISOs, but for this I believe that very few people actually use the 
live/hddimg images and this won’t be missed from core.  My entirely 
unresearched guess is that some people use hddimg but they don’t need to: a 
traditional partitioned disk image can be written to a disk/stick/card and 
works just as well to boot, and the initramfs-based installer should work in 
that environment too.

Thoughts?
Ross

[1] https://en.wikipedia.org/wiki/Cdrtools#License_compatibility_controversy
[2] https://dev.lovelyhq.com/libburnia/libisoburn/commits/branch/master
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199489): 
https://lists.openembedded.org/g/openembedded-core/message/199489
Mute This Topic: https://lists.openembedded.org/mt/106134701/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] [yocto-security] CVE status for scathgap on 2024-05-16 and ask for help

2024-05-16 Thread Marta Rybczynska
Thank you Marko for the feedback! For CVE-2024-34397 the reason is simple:

"affected": [
{
"vendor": "n/a",
"product": "n/a",
"versions": [
{
"version": "n/a",
"status": "affected"
}
]
}
],

I'm fixing this... Strange that this one was assigned by MITRE itself...

Regards,
Marta

On Thu, May 16, 2024 at 3:26 PM Marko, Peter 
wrote:

> Hello Marta,
>
>
>
> Glibc fixes are already staged in scarthgap-nut.
>
> Interesting would be to check why the prototype does not list glib-2.0
> CVE-2024-34397 which is staged there, too.
>
>
>
> Peter
>
>
>
> *From:* yocto-secur...@lists.yoctoproject.org <
> yocto-secur...@lists.yoctoproject.org> *On Behalf Of *Marta Rybczynska
> via lists.yoctoproject.org
> *Sent:* Thursday, May 16, 2024 15:21
> *To:* yocto-secur...@lists.yoctoproject.org; OE-core <
> openembedded-core@lists.openembedded.org>
> *Cc:* Richard Purdie ; Steve Sakoman <
> st...@sakoman.com>; liezhi.y...@windriver.com; wan...@fujitsu.com; Khem
> Raj 
> *Subject:* [yocto-security] CVE status for scathgap on 2024-05-16 and ask
> for help
>
>
>
> > Hello all,
>
> > The prototype CVE check via the MITRE database is giving the following
> for scathgap today (adding maintainers of affected packages in copy):
>
> >
>
> > CVE-2024-32002.json: affected: git 2.44.0
> > CVE-2024-32004.json: affected: git 2.44.0
> > CVE-2024-32020.json: affected: git 2.44.0
> > CVE-2024-32021.json: affected: git 2.44.0
> > CVE-2024-3205.json: affected: libyaml 0.2.5
> > CVE-2024-32465.json: affected: git 2.44.0
> > CVE-2024-33599.json: affected glibc 2.39
> > CVE-2024-33600.json: affected: glibc 2.39
> > CVE-2024-33601.json: affected: glibc 2.39
> > CVE-2024-33602.json: affected: glibc 2.39
>
> >
>
> > I would also like to ask for volunteers to help with looking up the
> following CVEs and submitting fixes to
> https://github.com/mrybczyn/cvelistV5-overrides/tree/overrides if they
> are malformed:
>
> > go: CVE-2024-24788, CVE=2024-24787
>
> > aiohttp: CVE-2024-30251
>
> > x server: CVE-2024-31053, CVE-2024-31082
>
> > bluez: CVE-2023-27349, CVE-2023-50229, CVE-2023-50230
>
> > gstreamer: CVE-2023-50186, CVE-2023-6
>
> > less: CVE-2024-32407
>
> > ncurses: CVE-2023-45988
>
> > ofono: CVE-2023-4234, CVE-2023-4233
>
> >
>
> > If you have any question on how to do that, ask me.
>
> >
>
> > Kind regards,
>
> > Marta
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199488): 
https://lists.openembedded.org/g/openembedded-core/message/199488
Mute This Topic: https://lists.openembedded.org/mt/106134282/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] [yocto-security] CVE status for scathgap on 2024-05-16 and ask for help

2024-05-16 Thread Peter Marko via lists.openembedded.org
Hello Marta,

Glibc fixes are already staged in scarthgap-nut.
Interesting would be to check why the prototype does not list glib-2.0 
CVE-2024-34397 which is staged there, too.

Peter

From: yocto-secur...@lists.yoctoproject.org 
 On Behalf Of Marta Rybczynska via 
lists.yoctoproject.org
Sent: Thursday, May 16, 2024 15:21
To: yocto-secur...@lists.yoctoproject.org; OE-core 

Cc: Richard Purdie ; Steve Sakoman 
; liezhi.y...@windriver.com; wan...@fujitsu.com; Khem Raj 

Subject: [yocto-security] CVE status for scathgap on 2024-05-16 and ask for help

> Hello all,
> The prototype CVE check via the MITRE database is giving the following for 
> scathgap today (adding maintainers of affected packages in copy):
>
> CVE-2024-32002.json: affected: git 2.44.0
> CVE-2024-32004.json: affected: git 2.44.0
> CVE-2024-32020.json: affected: git 2.44.0
> CVE-2024-32021.json: affected: git 2.44.0
> CVE-2024-3205.json: affected: libyaml 0.2.5
> CVE-2024-32465.json: affected: git 2.44.0
> CVE-2024-33599.json: affected glibc 2.39
> CVE-2024-33600.json: affected: glibc 2.39
> CVE-2024-33601.json: affected: glibc 2.39
> CVE-2024-33602.json: affected: glibc 2.39
>
> I would also like to ask for volunteers to help with looking up the following 
> CVEs and submitting fixes to 
> https://github.com/mrybczyn/cvelistV5-overrides/tree/overrides if they are 
> malformed:
> go: CVE-2024-24788, CVE=2024-24787
> aiohttp: CVE-2024-30251
> x server: CVE-2024-31053, CVE-2024-31082
> bluez: CVE-2023-27349, CVE-2023-50229, CVE-2023-50230
> gstreamer: CVE-2023-50186, CVE-2023-6
> less: CVE-2024-32407
> ncurses: CVE-2023-45988
> ofono: CVE-2023-4234, CVE-2023-4233
>
> If you have any question on how to do that, ask me.
>
> Kind regards,
> Marta

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



[OE-core] CVE status for scathgap on 2024-05-16 and ask for help

2024-05-16 Thread Marta Rybczynska
Hello all,
The prototype CVE check via the MITRE database is giving the following for
scathgap today (adding maintainers of affected packages in copy):

CVE-2024-32002.json: affected: git 2.44.0
CVE-2024-32004.json: affected: git 2.44.0
CVE-2024-32020.json: affected: git 2.44.0
CVE-2024-32021.json: affected: git 2.44.0
CVE-2024-3205.json: affected: libyaml 0.2.5
CVE-2024-32465.json: affected: git 2.44.0
CVE-2024-33599.json: affected glibc 2.39
CVE-2024-33600.json: affected: glibc 2.39
CVE-2024-33601.json: affected: glibc 2.39
CVE-2024-33602.json: affected: glibc 2.39

I would also like to ask for volunteers to help with looking up the
following CVEs and submitting fixes to
https://github.com/mrybczyn/cvelistV5-overrides/tree/overrides if they are
malformed:
go: CVE-2024-24788, CVE=2024-24787
aiohttp: CVE-2024-30251
x server: CVE-2024-31053, CVE-2024-31082
bluez: CVE-2023-27349, CVE-2023-50229, CVE-2023-50230
gstreamer: CVE-2023-50186, CVE-2023-6
less: CVE-2024-32407
ncurses: CVE-2023-45988
ofono: CVE-2023-4234, CVE-2023-4233

If you have any question on how to do that, ask me.

Kind regards,
Marta

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



Re: [OE-core] [PATCH v4] ipk/rootfs: run sanity test of multilib in parallel

2024-05-16 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org 
>  On Behalf Of Seungkyun Kim
> Sent: den 16 maj 2024 02:12
> To: openembedded-core@lists.openembedded.org
> Cc: seungkyun.kim 
> Subject: [OE-core] [PATCH v4] ipk/rootfs: run sanity test of multilib in 
> parallel
> 
> From: "seungkyun.kim" 
> 
> For multilib type packages, there is an additional temporary
> installation before the actual installation. It makes almost doubles
> the do_rootfs time if having many multilib type packages.
> To avoid this overhead, run sanity test in parallel.
> Installing package groups through opkg takes much more time than
> copying directory.
> 
> - Changes in V2:
> Fix FileNotFoundError exception when copying rootfs
> - Changes in V3:
> Removed unnecessary test call
> - Changes in V4:
> Fix invalid argument when create Process
> Keep the temporary rootfs directory after sanity check

The above list of changes related to the review process should be moved to 
after the --- line below as they should not be part of the actual commit 
message.

> 
> Signed-off-by: seungkyun.kim 
> ---
>  meta/lib/oe/package_manager/ipk/rootfs.py | 34 +--
>  1 file changed, 32 insertions(+), 2 deletions(-)
> 
> diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
> b/meta/lib/oe/package_manager/ipk/rootfs.py
> index ba93eb62ea..a3842a6264 100644
> --- a/meta/lib/oe/package_manager/ipk/rootfs.py
> +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
> @@ -6,7 +6,9 @@
> 
>  import re
>  import filecmp
> +import multiprocessing
>  import shutil
> +import stat
>  from oe.rootfs import Rootfs
>  from oe.manifest import Manifest
>  from oe.utils import execute_pre_post_process
> @@ -197,11 +199,34 @@ class PkgRootfs(DpkgOpkgRootfs):
>  files[key] = item
> 
>  def _multilib_test_install(self, pkgs):
> +def _copy_rootfs(src, dst):
> +if os.path.islink(src):
> +linkto = os.readlink(src)
> +if os.path.isabs(linkto):
> +linkto = 
> os.path.normpath(os.path.join(os.path.dirname(dst),
> +  os.path.relpath(linkto, src)))
> +os.symlink(linkto, dst)
> +elif os.path.isfile(src):
> +shutil.copy2(src, dst)
> +elif stat.S_ISFIFO(os.stat(src).st_mode):
> +os.mkfifo(dst)
> +else:
> +bb.warn("Skip unsupported file type: %s" % src)
> +
>  ml_temp = self.d.getVar("MULTILIB_TEMP_ROOTFS")
> +rootfs_temp = os.path.join(ml_temp, "rootfs")
>  bb.utils.mkdirhier(ml_temp)
> +bb.utils.remove(rootfs_temp, True)
> 
> -dirs = [self.image_rootfs]
> +if os.path.exists(self.image_rootfs):
> +shutil.copytree(self.image_rootfs, rootfs_temp, 
> copy_function=_copy_rootfs)
> +else:
> +bb.utils.mkdirhier(rootfs_temp)
> +dirs = [rootfs_temp]
> +return 
> multiprocessing.Process(target=self._multilib_test_pkg_install,
> +   args=(pkgs, ml_temp, dirs,))
> 
> +def _multilib_test_pkg_install(self, pkgs, ml_temp, dirs):
>  for variant in self.d.getVar("MULTILIB_VARIANTS").split():
>  ml_target_rootfs = os.path.join(ml_temp, variant)
> 
> @@ -300,15 +325,20 @@ class PkgRootfs(DpkgOpkgRootfs):
> 
>  for pkg_type in self.install_order:
>  if pkg_type in pkgs_to_install:
> +sanity_test = None
>  # For multilib, we perform a sanity test before final install
>  # If sanity test fails, it will automatically do a bb.fatal()
>  # and the installation will stop
>  if pkg_type == Manifest.PKG_TYPE_MULTILIB:
> -self._multilib_test_install(pkgs_to_install[pkg_type])
> +sanity_test= 
> self._multilib_test_install(pkgs_to_install[pkg_type])

Add a space before the equal sign.

> +sanity_test.start()
> 
>  self.pm.install(pkgs_to_install[pkg_type],
>  [False, True][pkg_type == 
> Manifest.PKG_TYPE_ATTEMPT_ONLY])
> 
> +if sanity_test is not None:
> +sanity_test.join()
> +
>  if self.progress_reporter:
>  self.progress_reporter.next_stage()
> 
> --
> 2.34.1

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199485): 
https://lists.openembedded.org/g/openembedded-core/message/199485
Mute This Topic: https://lists.openembedded.org/mt/106125799/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] What does "do_menuconfig is disabled" really mean?

2024-05-16 Thread Mike Looijmans

On 16-05-2024 13:41, Mike Looijmans via lists.openembedded.org wrote:


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail
On 16-05-2024 13:34, Ross Burton wrote:
On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:


Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.


The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.


So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).


I started out trying to get linux-yocto to build for my board, so copied 
the "skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a 
defconfig).


But when I then run "bitbake -c menuconfig virtual/kernel" I always get 
this message:


ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.


I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, 
so it's not the system).


I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
 if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
 bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)


So if you’re seeing that message then _something_ is assigning that variable 
to false. Use bitbake-getvar to identify what that is.




Interesting, that points to "uboot-config.bbclass:147" which sets it to false. 
I'm not building u-boot here, I'm building the kernel?



$ bitbake-getvar -r linux-fslc KCONFIG_CONFIG_ENABLE_MENUCONFIG
#
# $KCONFIG_CONFIG_ENABLE_MENUCONFIG [3 operations]
#   set /.../oe-core/meta/classes-recipe/cml1.bbclass:35
# [_defaultval] "true"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
# pre-expansion value:
#   "false"
KCONFIG_CONFIG_ENABLE_MENUCONFIG="false"




This is because of using "fitImage":

meta/classes-recipe/kernel-fitimage.bbclass:inherit kernel-uboot 
kernel-artifact-names uboot-config



I can specify this in the kernel recipe to make this error go away:
UBOOT_CONFIG = "tfa"

But then the menuconfig command just exits silently and does nothing whatsoever.













-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199484): 
https://lists.openembedded.org/g/openembedded-core/message/199484
Mute This Topic: https://lists.openembedded.org/mt/106132236/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] What does "do_menuconfig is disabled" really mean?

2024-05-16 Thread Mike Looijmans


Met vriendelijke groet / kind regards,

Mike Looijmans
System Expert


TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl

Please consider the environment before printing this e-mail
On 16-05-2024 13:34, Ross Burton wrote:

On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:


Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.

The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.

So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).

I started out trying to get linux-yocto to build for my board, so copied the 
"skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a defconfig).

But when I then run "bitbake -c menuconfig virtual/kernel" I always get this 
message:

ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.

I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, so 
it's not the system).

I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
 if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
 bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)

So if you’re seeing that message then _something_ is assigning that variable to 
false. Use bitbake-getvar to identify what that is.



Interesting, that points to "uboot-config.bbclass:147" which sets it to false. 
I'm not building u-boot here, I'm building the kernel?



$ bitbake-getvar -r linux-fslc KCONFIG_CONFIG_ENABLE_MENUCONFIG
#
# $KCONFIG_CONFIG_ENABLE_MENUCONFIG [3 operations]
#   set /.../oe-core/meta/classes-recipe/cml1.bbclass:35
# [_defaultval] "true"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
#   set uboot-config.bbclass:147 
[__anon_148__..._oe_core_meta_classes_recipe_uboot_config_bbclass]

# "false"
# pre-expansion value:
#   "false"
KCONFIG_CONFIG_ENABLE_MENUCONFIG="false"




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199483): 
https://lists.openembedded.org/g/openembedded-core/message/199483
Mute This Topic: https://lists.openembedded.org/mt/106132236/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] What does "do_menuconfig is disabled" really mean?

2024-05-16 Thread Ross Burton
On 16 May 2024, at 12:03, Mike Looijmans via lists.openembedded.org 
 wrote:
> 
> Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
> machine.
> 
> The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
> produces a 5.10 kernel.
> 
> So for my custom board based on the ls1028 I want to create a recipe that 
> builds a mainline kernel (I don't need GPU or fancy things that require 
> firmware or special drivers, so mainline should be fine).
> 
> I started out trying to get linux-yocto to build for my board, so copied the 
> "skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a defconfig).
> 
> But when I then run "bitbake -c menuconfig virtual/kernel" I always get this 
> message:
> 
> ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
> please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.
> 
> I tried starting with a copy of recipes like linux-fscl, same error. Always.
> 
> (note: I've run "menuconfig" a million times by now, for dozens of boards, so 
> it's not the system).
> 
> I tried adding
> KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
> to my recipe, but that also had no effect.
> 
> The log file also contains no information whatsoever.
> 
> What's the real issue?

cml1.bbclass has this:

KCONFIG_CONFIG_ENABLE_MENUCONFIG ??= “true"
…
if not bb.utils.to_boolean(d.getVar("KCONFIG_CONFIG_ENABLE_MENUCONFIG")):
bb.fatal("do_menuconfig is disabled, please check 
KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.”)

So if you’re seeing that message then _something_ is assigning that variable to 
false. Use bitbake-getvar to identify what that is.

Ross
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199482): 
https://lists.openembedded.org/g/openembedded-core/message/199482
Mute This Topic: https://lists.openembedded.org/mt/106132236/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] Debugging rust oe-selftest failures

2024-05-16 Thread Alexander Kanavin
On Thu, 16 May 2024 at 13:00, Alexander Kanavin via
lists.openembedded.org 
wrote:
> I'll send the ab patches that break the test suite later today; the
> request is to take them, and unbreak the test suite.
>
> Then you can rebase your upgrade work on top of that. And address the
> usability points I made.

The patchset is now sent. Please fix the testsuite, and send that as
soon as possible.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199481): 
https://lists.openembedded.org/g/openembedded-core/message/199481
Mute This Topic: https://lists.openembedded.org/mt/105307188/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 13/13] elfutils: remove unneeded 0006-Fix-build-on-aarch64-musl.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Verified on qemuarm64/musl (as the patch says).

Signed-off-by: Alexander Kanavin 
---
 .../elfutils/elfutils_0.191.bb|  1 -
 .../0006-Fix-build-on-aarch64-musl.patch  | 58 ---
 2 files changed, 59 deletions(-)
 delete mode 100644 
meta/recipes-devtools/elfutils/files/0006-Fix-build-on-aarch64-musl.patch

diff --git a/meta/recipes-devtools/elfutils/elfutils_0.191.bb 
b/meta/recipes-devtools/elfutils/elfutils_0.191.bb
index c4d872430be..76bd2b3a99c 100644
--- a/meta/recipes-devtools/elfutils/elfutils_0.191.bb
+++ b/meta/recipes-devtools/elfutils/elfutils_0.191.bb
@@ -15,7 +15,6 @@ SRC_URI = 
"https://sourceware.org/elfutils/ftp/${PV}/${BP}.tar.bz2 \
file://0001-dso-link-change.patch \
file://0002-Fix-elf_cvt_gunhash-if-dest-and-src-are-same.patch \
file://0003-fixheadercheck.patch \
-   file://0006-Fix-build-on-aarch64-musl.patch \
file://0001-libasm-may-link-with-libbz2-if-found.patch \

file://0001-libelf-elf_end.c-check-data_list.data.d.d_buf-before.patch \
file://0001-skip-the-test-when-gcc-not-deployed.patch \
diff --git 
a/meta/recipes-devtools/elfutils/files/0006-Fix-build-on-aarch64-musl.patch 
b/meta/recipes-devtools/elfutils/files/0006-Fix-build-on-aarch64-musl.patch
deleted file mode 100644
index 149e0e6a7b9..000
--- a/meta/recipes-devtools/elfutils/files/0006-Fix-build-on-aarch64-musl.patch
+++ /dev/null
@@ -1,58 +0,0 @@
-From 4409f128c81a9d76b9360b002a1d76043c77b53e Mon Sep 17 00:00:00 2001
-From: Hongxu Jia 
-Date: Tue, 15 Aug 2017 17:27:30 +0800
-Subject: [PATCH] Fix build on aarch64/musl
-
-Errors
-
-invalid operands to binary & (have 'long double' and 'unsigned int')
-
-error: redefinition
- of 'struct iovec'
- struct iovec { void *iov_base; size_t iov_len; };
-^
-Upstream-Status: Pending
-Signed-off-by: Khem Raj 
-
-Rebase to 0.170
-Signed-off-by: Hongxu Jia 

- backends/aarch64_initreg.c | 4 ++--
- backends/arm_initreg.c | 2 +-
- 2 files changed, 3 insertions(+), 3 deletions(-)
-
-diff --git a/backends/aarch64_initreg.c b/backends/aarch64_initreg.c
-index daf6f37..6445276 100644
 a/backends/aarch64_initreg.c
-+++ b/backends/aarch64_initreg.c
-@@ -33,7 +33,7 @@
- #include "system.h"
- #include 
- #if defined(__aarch64__) && defined(__linux__)
--# include 
-+# include 
- # include 
- # include 
- /* Deal with old glibc defining user_pt_regs instead of user_regs_struct.  */
-@@ -82,7 +82,7 @@ aarch64_set_initial_registers_tid (pid_t tid __attribute__ 
((unused)),
- 
-   Dwarf_Word dwarf_fregs[32];
-   for (int r = 0; r < 32; r++)
--dwarf_fregs[r] = fregs.vregs[r] & 0x;
-+dwarf_fregs[r] = (unsigned int)fregs.vregs[r] & 0x;
- 
-   if (! setfunc (64, 32, dwarf_fregs, arg))
- return false;
-diff --git a/backends/arm_initreg.c b/backends/arm_initreg.c
-index efcabaf..062bb9e 100644
 a/backends/arm_initreg.c
-+++ b/backends/arm_initreg.c
-@@ -38,7 +38,7 @@
- #endif
- 
- #ifdef __aarch64__
--# include 
-+# include 
- # include 
- # include 
- /* Deal with old glibc defining user_pt_regs instead of user_regs_struct.  */
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199480): 
https://lists.openembedded.org/g/openembedded-core/message/199480
Mute This Topic: https://lists.openembedded.org/mt/106132529/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 11/13] iptables: correctly enable libnetfilter_conntrack support

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

This is done via configure option, and makes
0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch
unnecessary, as both libnetfilter_conntrack and libnfnetlink
are enabled in lockstep.

Signed-off-by: Alexander Kanavin 
---
 ...y-check-conntrack-when-libnfnetlink-.patch | 49 ---
 .../iptables/iptables_1.8.10.bb   |  3 +-
 2 files changed, 1 insertion(+), 51 deletions(-)
 delete mode 100644 
meta/recipes-extended/iptables/iptables/0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch

diff --git 
a/meta/recipes-extended/iptables/iptables/0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch
 
b/meta/recipes-extended/iptables/iptables/0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch
deleted file mode 100644
index 5a022ebc8c3..000
--- 
a/meta/recipes-extended/iptables/iptables/0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch
+++ /dev/null
@@ -1,49 +0,0 @@
-From 6832501bbb90a3dab977a4625d0391804c0e795c Mon Sep 17 00:00:00 2001
-From: "Maxin B. John" 
-Date: Tue, 21 Feb 2017 11:49:07 +0200
-Subject: [PATCH] configure.ac:
- only-check-conntrack-when-libnfnetlink-enabled.patch
-
-Package libnetfilter-conntrack depends on package libnfnetlink. iptables
-checks package libnetfilter-conntrack whatever its package config
-libnfnetlink is enabled or not. When libnfnetlink is disabled but
-package libnetfilter-conntrack exists, it fails randomly with:
-
-In file included from
-.../iptables/1.4.21-r0/iptables-1.4.21/extensions/libxt_connlabel.c:8:0:
-
-.../tmp/sysroots/qemumips/usr/include/libnetfilter_conntrack/libnetfilter_conntrack.h:14:42:
-fatal error: libnfnetlink/linux_nfnetlink.h: No such file or directory
-
-compilation terminated.
-GNUmakefile:96: recipe for target 'libxt_connlabel.oo' failed
-Only check libnetfilter-conntrack when libnfnetlink is enabled to fix it.
-
-Upstream-Status: Pending
-
-Signed-off-by: Kai Kang 
-Signed-off-by: Maxin B. John 
-

- configure.ac | 6 --
- 1 file changed, 4 insertions(+), 2 deletions(-)
-
-diff --git a/configure.ac b/configure.ac
-index d607772..25a8e75 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -159,10 +159,12 @@ if test "$nftables" != 1; then
- fi
- 
- if test "x$enable_connlabel" = "xyes"; then
--  PKG_CHECK_MODULES([libnetfilter_conntrack],
-+nfconntrack=0
-+AS_IF([test "x$enable_libnfnetlink" = "xyes"], [
-+PKG_CHECK_MODULES([libnetfilter_conntrack],
-   [libnetfilter_conntrack >= 1.0.6],
-   [nfconntrack=1], [nfconntrack=0])
--
-+])
-   if test "$nfconntrack" -ne 1; then
-   blacklist_modules="$blacklist_modules connlabel";
-   echo "WARNING: libnetfilter_conntrack not found, connlabel 
match will not be built";
diff --git a/meta/recipes-extended/iptables/iptables_1.8.10.bb 
b/meta/recipes-extended/iptables/iptables_1.8.10.bb
index cbd727b75df..a9c88582cda 100644
--- a/meta/recipes-extended/iptables/iptables_1.8.10.bb
+++ b/meta/recipes-extended/iptables/iptables_1.8.10.bb
@@ -14,7 +14,6 @@ SRC_URI = 
"http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.xz \
file://ip6tables.service \
file://ip6tables.rules \

file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \
-   
file://0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch \
"
 SRC_URI[sha256sum] = 
"5cc255c189356e317d070755ce9371eb63a1b783c34498fb8c30264f3cc59c9c"
 
@@ -33,7 +32,7 @@ PACKAGECONFIG ?= "${@bb.utils.filter('DISTRO_FEATURES', 
'ipv6', d)}"
 PACKAGECONFIG[ipv6] = "--enable-ipv6,--disable-ipv6,"
 
 # libnfnetlink recipe is in meta-networking layer
-PACKAGECONFIG[libnfnetlink] = 
"--enable-libnfnetlink,--disable-libnfnetlink,libnfnetlink 
libnetfilter-conntrack"
+PACKAGECONFIG[libnfnetlink] = "--enable-libnfnetlink 
--enable-connlabel,--disable-libnfnetlink --disable-connlabel,libnfnetlink 
libnetfilter-conntrack"
 
 # libnftnl recipe is in meta-networking layer(previously known as libnftables)
 PACKAGECONFIG[libnftnl] = "--enable-nftables,--disable-nftables,libnftnl"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199478): 
https://lists.openembedded.org/g/openembedded-core/message/199478
Mute This Topic: https://lists.openembedded.org/mt/106132527/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 04/13] vorbis: mark patch as Inactive-Upstream

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 .../libvorbis/libvorbis/0001-configure-Check-for-clang.patch| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
 
b/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
index b06029b98b7..d4fac605b66 100644
--- 
a/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
+++ 
b/meta/recipes-multimedia/libvorbis/libvorbis/0001-configure-Check-for-clang.patch
@@ -5,9 +5,9 @@ Subject: [PATCH] configure: Check for clang
 
 Disable gcc specific options if using clang
 
+Upstream-Status: Inactive-Upstream 
[https://gitlab.xiph.org/xiph/vorbis,https://github.com/xiph/vorbis]
 Signed-off-by: Khem Raj 
 ---
-Upstream-Status: Pending
 
  configure.ac | 19 +--
  1 file changed, 17 insertions(+), 2 deletions(-)
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199471): 
https://lists.openembedded.org/g/openembedded-core/message/199471
Mute This Topic: https://lists.openembedded.org/mt/106132518/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 12/13] x264: update to latest revision on official git

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

The mirror was out of date; meanwhile x264 remains in active development.

Drop unsuitable x32 patch and declare x264 incompatible with the target
(by every sign it's an extinct target; if not so please work with upstream
to develop a solution there).

Replace don-t-default-to-cortex-a9-with-neon.patch with a configure
option passing in target compiler options so that configure can make
correct decisions and we don't have to patch it.

Signed-off-by: Alexander Kanavin 
---
 .../x264/Fix-X32-build-by-disabling-asm.patch | 51 ---
 ...don-t-default-to-cortex-a9-with-neon.patch | 33 
 meta/recipes-multimedia/x264/x264_git.bb  |  9 ++--
 3 files changed, 5 insertions(+), 88 deletions(-)
 delete mode 100644 
meta/recipes-multimedia/x264/x264/Fix-X32-build-by-disabling-asm.patch
 delete mode 100644 
meta/recipes-multimedia/x264/x264/don-t-default-to-cortex-a9-with-neon.patch

diff --git 
a/meta/recipes-multimedia/x264/x264/Fix-X32-build-by-disabling-asm.patch 
b/meta/recipes-multimedia/x264/x264/Fix-X32-build-by-disabling-asm.patch
deleted file mode 100644
index cb771fb0bf8..000
--- a/meta/recipes-multimedia/x264/x264/Fix-X32-build-by-disabling-asm.patch
+++ /dev/null
@@ -1,51 +0,0 @@
-From 7bc25f4d1aaa5186d2eff3e2326c7245fcd7e7f3 Mon Sep 17 00:00:00 2001
-From: Christopher Larson 
-Date: Tue, 13 Dec 2016 14:22:32 -0700
-Subject: [PATCH] Fix X32 build by disabling asm
-
-This applies gentoo's x32 patch, adjusted slightly, which disables asm support
-for x32 as well as correcting -m.
-
-Debian has a different patch which does the same, and there's a superior yet
-out of date patch series on the x264 list which keeps asm support enabled, but
-doesn't successfully build at this time, and my assembly is very rusty.
-
-Upstream-Status: Pending
-Signed-off-by: Christopher Larson 
-

- configure | 14 --
- 1 file changed, 12 insertions(+), 2 deletions(-)
-
-diff --git a/configure b/configure
-index 51b128d..6ea9469 100755
 a/configure
-+++ b/configure
-@@ -754,7 +754,13 @@ case $host_cpu in
- AS_EXT=".asm"
- ASFLAGS="$ASFLAGS -DARCH_X86_64=1 -I\$(SRCPATH)/common/x86/"
- stack_alignment=16
--[ $compiler = GNU ] && CFLAGS="-m64 $CFLAGS" && LDFLAGS="-m64 
$LDFLAGS"
-+if [ $compiler = GNU ]; then
-+if cpp_check "" "" "__ILP32__" ; then
-+CFLAGS="-mx32 $CFLAGS" && LDFLAGS="-mx32 $LDFLAGS"
-+else
-+CFLAGS="-m64 $CFLAGS" && LDFLAGS="-m64 $LDFLAGS"
-+fi
-+fi
- if [ "$SYS" = MACOSX ]; then
- ASFLAGS="$ASFLAGS -f macho64 -DPREFIX"
- if cc_check '' "-arch x86_64"; then
-@@ -773,7 +779,11 @@ case $host_cpu in
- RCFLAGS="--target=pe-x86-64 $RCFLAGS"
- fi
- else
--ASFLAGS="$ASFLAGS -f elf64"
-+if cpp_check "" "" "__ILP32__" ; then
-+asm=no
-+else
-+ASFLAGS="$ASFLAGS -f elf64"
-+fi
- fi
- ;;
- powerpc*)
diff --git 
a/meta/recipes-multimedia/x264/x264/don-t-default-to-cortex-a9-with-neon.patch 
b/meta/recipes-multimedia/x264/x264/don-t-default-to-cortex-a9-with-neon.patch
deleted file mode 100644
index 065e3b35b7c..000
--- 
a/meta/recipes-multimedia/x264/x264/don-t-default-to-cortex-a9-with-neon.patch
+++ /dev/null
@@ -1,33 +0,0 @@
-From a72bf499a0674fc75eedf15008b424e28f67e4bd Mon Sep 17 00:00:00 2001
-From: Andrei Gherzan 
-Date: Fri, 2 Feb 2018 15:10:08 +0200
-Subject: [PATCH] dont default to cortex-a9 with neon
-
--march flag is not in CFLAGS so this will always default to
- -mcpu=cortex-a8 -mfpu=neon.
-
-Upstream-Status: Pending
-
-Signed-off-by: Andrei Gherzan 
-Signed-off-by: Maxin B. John 

- configure | 3 ---
- 1 file changed, 3 deletions(-)
-
-diff --git a/configure b/configure
-index 0e3ef23..955b993 100755
 a/configure
-+++ b/configure
-@@ -911,9 +911,6 @@ if [ $asm = auto -a \( $ARCH = X86 -o $ARCH = X86_64 \) ] 
; then
- fi
- 
- if [ $asm = auto -a $ARCH = ARM ] ; then
--# set flags so neon is built by default
--[ $compiler == CL ] || echo $CFLAGS | grep -Eq '(-mcpu|-march|-mfpu)' || 
CFLAGS="$CFLAGS -mcpu=cortex-a8 -mfpu=neon"
--
- cc_check '' '' '__asm__("add r0, r1, r2");' && define HAVE_ARM_INLINE_ASM
- if [ $compiler = CL ] && cpp_check '' '' 'defined(_M_ARM) && _M_ARM >= 7' 
; then
- define HAVE_ARMV6
--- 
-2.4.0
-
diff --git a/meta/recipes-multimedia/x264/x264_git.bb 
b/meta/recipes-multimedia/x264/x264_git.bb
index e7d9e75e8de..fae88d24d13 100644
--- a/meta/recipes-multimedia/x264/x264_git.bb
+++ b/meta/recipes-multimedia/x264/x264_git.bb
@@ -8,13 +8,11 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=94d55d512a9ba36caa9b7df079bae19f"
 
 DEPENDS = "nasm-native"
 
-SRC_URI = "git://github.com/mirror/x264;branch=stable;protocol=https \
-   file://don-t-default-to-cortex-a9-with-neon.patch \
-   

[OE-core] [PATCH 03/13] kexec-tools: submit 0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch upstream

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 .../0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-kernel/kexec/kexec-tools/0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch
 
b/meta/recipes-kernel/kexec/kexec-tools/0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch
index e874a8b4f16..489b1092850 100644
--- 
a/meta/recipes-kernel/kexec/kexec-tools/0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch
+++ 
b/meta/recipes-kernel/kexec/kexec-tools/0003-kexec-ARM-Fix-add_buffer_phys_virt-align-issue.patch
@@ -8,7 +8,7 @@ is used by MMU, the "SECTION_SIZE" is defined with
 (1 << 21), but 'add_buffer_phys_virt()' hardcode this
 to (1 << 20).
 
-Upstream-Status: Pending
+Upstream-Status: Submitted [via email to 
ho...@kernel.org,http://lists.infradead.org/pipermail/kexec/2024-April/029903.html]
 
 Suggested-By:fredrik.markst...@gmail.com
 Signed-off-by: Haiqing Bai 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199470): 
https://lists.openembedded.org/g/openembedded-core/message/199470
Mute This Topic: https://lists.openembedded.org/mt/106132517/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 10/13] iptables: remove unneeded 0002-iptables-xshared.h-add-missing-sys.types.h-include.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Somewhere on the way it ceased to be necessary.

Signed-off-by: Alexander Kanavin 
---
 ...ed.h-add-missing-sys.types.h-include.patch | 31 ---
 .../iptables/iptables_1.8.10.bb   |  1 -
 2 files changed, 32 deletions(-)
 delete mode 100644 
meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch

diff --git 
a/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
 
b/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
deleted file mode 100644
index a190c7e8ae2..000
--- 
a/meta/recipes-extended/iptables/iptables/0002-iptables-xshared.h-add-missing-sys.types.h-include.patch
+++ /dev/null
@@ -1,31 +0,0 @@
-From 465e3ef77f1763d225adc76220e43ee9bd73b178 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Tue, 17 May 2022 10:56:59 +0200
-Subject: [PATCH] iptables/xshared.h: add missing sys.types.h include
-
-This resolves the build error under musl:
-
-| ../../../../../../../workspace/sources/iptables/iptables/xshared.h:83:56: 
error: unknown type name 'u_int16_t'; did you mean 'uint16_t'?
-|83 | set_option(unsigned int *options, unsigned int option, u_int16_t 
*invflg,
-|   |^
-|   |uint16_t
-
-Upstream-Status: Submitted [via email to p...@nwl.cc]
-Signed-off-by: Alexander Kanavin 
-

- iptables/xshared.h | 1 +
- 1 file changed, 1 insertion(+)
-
-diff --git a/iptables/xshared.h b/iptables/xshared.h
-index a200e0d..f543dbf 100644
 a/iptables/xshared.h
-+++ b/iptables/xshared.h
-@@ -6,6 +6,7 @@
- #include 
- #include 
- #include 
-+#include 
- #include 
- #include 
- #include 
diff --git a/meta/recipes-extended/iptables/iptables_1.8.10.bb 
b/meta/recipes-extended/iptables/iptables_1.8.10.bb
index 5a878977425..cbd727b75df 100644
--- a/meta/recipes-extended/iptables/iptables_1.8.10.bb
+++ b/meta/recipes-extended/iptables/iptables_1.8.10.bb
@@ -14,7 +14,6 @@ SRC_URI = 
"http://netfilter.org/projects/iptables/files/iptables-${PV}.tar.xz \
file://ip6tables.service \
file://ip6tables.rules \

file://0001-configure-Add-option-to-enable-disable-libnfnetlink.patch \
-   
file://0002-iptables-xshared.h-add-missing-sys.types.h-include.patch \

file://0004-configure.ac-only-check-conntrack-when-libnfnetlink-.patch \
"
 SRC_URI[sha256sum] = 
"5cc255c189356e317d070755ce9371eb63a1b783c34498fb8c30264f3cc59c9c"
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199477): 
https://lists.openembedded.org/g/openembedded-core/message/199477
Mute This Topic: https://lists.openembedded.org/mt/106132526/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 09/13] iptables: submit 0001-configure-Add-option-to-enable-disable-libnfnetlink.patch upstream

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 ...ption-to-enable-disable-libnfnetlink.patch | 44 +++
 1 file changed, 26 insertions(+), 18 deletions(-)

diff --git 
a/meta/recipes-extended/iptables/iptables/0001-configure-Add-option-to-enable-disable-libnfnetlink.patch
 
b/meta/recipes-extended/iptables/iptables/0001-configure-Add-option-to-enable-disable-libnfnetlink.patch
index 8824bf2af7e..0fe22615119 100644
--- 
a/meta/recipes-extended/iptables/iptables/0001-configure-Add-option-to-enable-disable-libnfnetlink.patch
+++ 
b/meta/recipes-extended/iptables/iptables/0001-configure-Add-option-to-enable-disable-libnfnetlink.patch
@@ -1,22 +1,24 @@
-From 0096c854d5015918ed154dccb3ad472fd06c1010 Mon Sep 17 00:00:00 2001
+From 653db8b938166db7833135f615b90c38a3f27a30 Mon Sep 17 00:00:00 2001
 From: "Maxin B. John" 
-Date: Tue, 21 Feb 2017 11:16:31 +0200
+Date: Thu, 25 Apr 2024 10:51:02 +0200
 Subject: [PATCH] configure: Add option to enable/disable libnfnetlink
 
-This changes the configure behaviour from autodetecting
-for libnfnetlink to having an option to disable it explicitly
-
-Upstream-Status: Pending
+Default behavior (autodetecting) does not change, but specifying
+either option would explicitly disable or enable libnfnetlink support,
+and if the library is not found in the latter case, ./configure will error
+out.
 
+Upstream-Status: Backport 
[https://git.netfilter.org/iptables/commit/?id=653db8b938166db7833135f615b90c38a3f27a30]
 Signed-off-by: Khem Raj 
 Signed-off-by: Maxin B. John 
-
+Signed-off-by: Alexander Kanavin 
+Signed-off-by: Phil Sutter 
 ---
- configure.ac | 10 +++---
- 1 file changed, 7 insertions(+), 3 deletions(-)
+ configure.ac | 13 +++--
+ 1 file changed, 11 insertions(+), 2 deletions(-)
 
 diff --git a/configure.ac b/configure.ac
-index d99fa3b..d607772 100644
+index d99fa3b9..2293702b 100644
 --- a/configure.ac
 +++ b/configure.ac
 @@ -63,6 +63,9 @@ AC_ARG_WITH([pkgconfigdir], 
AS_HELP_STRING([--with-pkgconfigdir=PATH],
@@ -25,21 +27,27 @@ index d99fa3b..d607772 100644
[enable_nftables="$enableval"], [enable_nftables="yes"])
 +AC_ARG_ENABLE([libnfnetlink],
 +AS_HELP_STRING([--disable-libnfnetlink], [Do not use netfilter netlink 
library]),
-+[enable_libnfnetlink="$enableval"], [enable_libnfnetlink="yes"])
++[enable_libnfnetlink="$enableval"], [enable_libnfnetlink="auto"])
  AC_ARG_ENABLE([connlabel],
AS_HELP_STRING([--disable-connlabel],
[Do not build libnetfilter_conntrack]),
-@@ -113,9 +116,10 @@ AM_CONDITIONAL([ENABLE_SYNCONF], [test 
"$enable_nfsynproxy" = "yes"])
+@@ -113,8 +116,14 @@ AM_CONDITIONAL([ENABLE_SYNCONF], [test 
"$enable_nfsynproxy" = "yes"])
  AM_CONDITIONAL([ENABLE_NFTABLES], [test "$enable_nftables" = "yes"])
  AM_CONDITIONAL([ENABLE_CONNLABEL], [test "$enable_connlabel" = "yes"])
  
 -PKG_CHECK_MODULES([libnfnetlink], [libnfnetlink >= 1.0],
 -  [nfnetlink=1], [nfnetlink=0])
--AM_CONDITIONAL([HAVE_LIBNFNETLINK], [test "$nfnetlink" = 1])
-+AS_IF([test "x$enable_libnfnetlink" = "xyes"], [
-+PKG_CHECK_MODULES([libnfnetlink], [libnfnetlink >= 1.0])
-+])
-+AM_CONDITIONAL([HAVE_LIBNFNETLINK], [test "x$enable_libnfnetlink" = "xyes"])
++# If specified explicitly on the command line, error out when library was not 
found
++# Otherwise, disable and continue
++AS_IF([test "x$enable_libnfnetlink" = "xyes"],
++  [PKG_CHECK_MODULES([libnfnetlink], [libnfnetlink >= 1.0],
++ [nfnetlink=1])],
++  [test "x$enable_libnfnetlink" = "xauto"],
++  [PKG_CHECK_MODULES([libnfnetlink], [libnfnetlink >= 1.0],
++ [nfnetlink=1], [nfnetlink=0])])
+ AM_CONDITIONAL([HAVE_LIBNFNETLINK], [test "$nfnetlink" = 1])
  
  if test "x$enable_bpfc" = "xyes" || test "x$enable_nfsynproxy" = "xyes"; then
-   PKG_CHECK_MODULES([libpcap], [libpcap], [], [
+-- 
+2.39.2
+
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199476): 
https://lists.openembedded.org/g/openembedded-core/message/199476
Mute This Topic: https://lists.openembedded.org/mt/106132524/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 06/13] grub: remove unneeded 0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Verified on qemux86 and qemux86-64 with grub and grub-efi.

Signed-off-by: Alexander Kanavin 
---
 ...ath-sse-as-well-when-SSE-is-disabled.patch | 44 ---
 meta/recipes-bsp/grub/grub2.inc   |  1 -
 2 files changed, 45 deletions(-)
 delete mode 100644 
meta/recipes-bsp/grub/files/0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch

diff --git 
a/meta/recipes-bsp/grub/files/0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch
 
b/meta/recipes-bsp/grub/files/0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch
deleted file mode 100644
index 05a4697a734..000
--- 
a/meta/recipes-bsp/grub/files/0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch
+++ /dev/null
@@ -1,44 +0,0 @@
-From 006799e9c4babe8a8340a24501b253e759614a2d Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Wed, 13 Jan 2016 19:17:31 +
-Subject: [PATCH] Disable -mfpmath=sse as well when SSE is disabled
-
-Fixes
-
-configure:20574: i586-poky-linux-gcc  -m32-march=core2 -msse3
--mtune=generic -mfpmath=sse
---sysroot=/usr/local/dev/yocto/grubtest2/build/tmp/sysroots/emenlow -o
-conftest -O2 -pipe -g -feliminate-unused-debug-types -Wall -W -Wshadow
--Wpointer-arith -Wmissing-prototypes -Wundef -Wstrict-prototypes -g
--falign-jumps=1 -falign-loops=1 -falign-functions=1 -mno-mmx -mno-sse
--mno-sse2 -mno-3dnow -fno-dwarf2-cfi-asm -m32 -fno-stack-protector
--mno-stack-arg-probe -Werror -nostdlib -Wl,--defsym,___main=0x8100
--Wall -W -I$(top_srcdir)/include -I$(top_builddir)/include
--DGRUB_MACHINE_PCBIOS=1 -DGRUB_MACHINE=I386_PC -Wl,-O1
--Wl,--hash-style=gnu -Wl,--as-needed conftest.c  >&5
-conftest.c:1:0: error: SSE instruction set disabled, using 387
-arithmetics [-Werror]
-cc1: all warnings being treated as errors
-
-Signed-off-by: Nitin A Kamble 
-Signed-off-by: Khem Raj 
-
-Upstream-Status: Pending
-

- configure.ac | 2 +-
- 1 file changed, 1 insertion(+), 1 deletion(-)
-
-diff --git a/configure.ac b/configure.ac
-index cd667a2..8263876 100644
 a/configure.ac
-+++ b/configure.ac
-@@ -846,7 +846,7 @@ fi
- if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ) && test 
"x$platform" != xemu; then
-   # Some toolchains enable these features by default, but they need
-   # registers that aren't set up properly in GRUB.
--  TARGET_CFLAGS="$TARGET_CFLAGS -mno-mmx -mno-sse -mno-sse2 -mno-sse3 
-mno-3dnow"
-+  TARGET_CFLAGS="$TARGET_CFLAGS -mno-mmx -mno-sse -mno-sse2 -mno-sse3 
-mno-3dnow -mfpmath=387"
- fi
- 
- if ( test "x$target_cpu" = xi386 || test "x$target_cpu" = xx86_64 ); then
diff --git a/meta/recipes-bsp/grub/grub2.inc b/meta/recipes-bsp/grub/grub2.inc
index bb9aacb478a..e2a2a842773 100644
--- a/meta/recipes-bsp/grub/grub2.inc
+++ b/meta/recipes-bsp/grub/grub2.inc
@@ -14,7 +14,6 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=d32239bcb673463ab874e80d47fae504"
 CVE_PRODUCT = "grub2"
 
 SRC_URI = "${GNU_MIRROR}/grub/grub-${PV}.tar.gz \
-   file://0001-Disable-mfpmath-sse-as-well-when-SSE-is-disabled.patch \
file://autogen.sh-exclude-pc.patch \
file://grub-module-explicitly-keeps-symbole-.module_license.patch \
file://0001-grub.d-10_linux.in-add-oe-s-kernel-name.patch \
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199473): 
https://lists.openembedded.org/g/openembedded-core/message/199473
Mute This Topic: https://lists.openembedded.org/mt/106132520/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 08/13] perl: submit the rest of determinism.patch upstream

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/perl/files/determinism.patch | 6 +++---
 1 file changed, 3 insertions(+), 3 deletions(-)

diff --git a/meta/recipes-devtools/perl/files/determinism.patch 
b/meta/recipes-devtools/perl/files/determinism.patch
index aa85ccef100..f2b5524 100644
--- a/meta/recipes-devtools/perl/files/determinism.patch
+++ b/meta/recipes-devtools/perl/files/determinism.patch
@@ -8,9 +8,9 @@ b) Sort the order of the module lists from configure_mods.sh 
since otherwise
the result isn't the same leading to makefile differences.
Reported upstream: https://github.com/arsv/perl-cross/issues/88
 
-c) Sort the Encode::Byte byte_t.fnm file output (and the makefile depends 
whilst 
+c) Sort the Encode::Byte byte_t.fnm file output (and the makefile depends 
whilst
there for good measure)
-   This needs to go to upstream perl (not done)
+   Submitted to upstream perl: https://github.com/dankogai/p5-encode/pull/179
 
 d) Use bash for perl-cross configure since otherwise trnl gets set to "\n" 
with bash
and "" with dash
@@ -18,7 +18,7 @@ d) Use bash for perl-cross configure since otherwise trnl 
gets set to "\n" with
 
 RP 2020/2/7
 
-Upstream-Status: Pending [75% submitted]
+Upstream-Status: Submitted [see links above]
 Signed-off-by: Richard Purdie 
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199475): 
https://lists.openembedded.org/g/openembedded-core/message/199475
Mute This Topic: https://lists.openembedded.org/mt/106132522/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 07/13] gdb: remove unneeded 0006-resolve-restrict-keyword-conflict.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Somewhere on the way the issue solved itself.

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/gdb/gdb.inc |  1 -
 ...06-resolve-restrict-keyword-conflict.patch | 45 ---
 2 files changed, 46 deletions(-)
 delete mode 100644 
meta/recipes-devtools/gdb/gdb/0006-resolve-restrict-keyword-conflict.patch

diff --git a/meta/recipes-devtools/gdb/gdb.inc 
b/meta/recipes-devtools/gdb/gdb.inc
index 81ac441462a..c2fbcb2ac6b 100644
--- a/meta/recipes-devtools/gdb/gdb.inc
+++ b/meta/recipes-devtools/gdb/gdb.inc
@@ -10,7 +10,6 @@ SRC_URI = "${GNU_MIRROR}/gdb/gdb-${PV}.tar.xz \

file://0003-Dont-disable-libreadline.a-when-using-disable-static.patch \
file://0004-use-asm-sgidefs.h.patch \
file://0005-Change-order-of-CFLAGS.patch \
-   file://0006-resolve-restrict-keyword-conflict.patch \
file://0007-Fix-invalid-sigprocmask-call.patch \

file://0008-Define-alignof-using-_Alignof-when-using-C11-or-newe.patch \
"
diff --git 
a/meta/recipes-devtools/gdb/gdb/0006-resolve-restrict-keyword-conflict.patch 
b/meta/recipes-devtools/gdb/gdb/0006-resolve-restrict-keyword-conflict.patch
deleted file mode 100644
index 45388c5ac5a..000
--- a/meta/recipes-devtools/gdb/gdb/0006-resolve-restrict-keyword-conflict.patch
+++ /dev/null
@@ -1,45 +0,0 @@
-From 477f1b2049c7f940b8e8fda4ac396cfe322b269f Mon Sep 17 00:00:00 2001
-From: Khem Raj 
-Date: Tue, 10 May 2016 08:47:05 -0700
-Subject: [PATCH] resolve restrict keyword conflict
-
-GCC detects that we call 'restrict' as param name in function
-signatures and complains since both params are called 'restrict'
-therefore we use __restrict to denote the C99 keywork
-
-Upstream-Status: Pending
-
-Signed-off-by: Khem Raj 

- gnulib/import/sys_time.in.h | 8 
- 1 file changed, 4 insertions(+), 4 deletions(-)
-
-diff --git a/gnulib/import/sys_time.in.h b/gnulib/import/sys_time.in.h
-index 87db1a88745..e6b98c7e467 100644
 a/gnulib/import/sys_time.in.h
-+++ b/gnulib/import/sys_time.in.h
-@@ -93,20 +93,20 @@ struct timeval
- #   define gettimeofday rpl_gettimeofday
- #  endif
- _GL_FUNCDECL_RPL (gettimeofday, int,
--  (struct timeval *restrict, void *restrict)
-+  (struct timeval *__restrict, void *__restrict)
-   _GL_ARG_NONNULL ((1)));
- _GL_CXXALIAS_RPL (gettimeofday, int,
--  (struct timeval *restrict, void *restrict));
-+  (struct timeval *__restrict, void *__restrict));
- # else
- #  if !@HAVE_GETTIMEOFDAY@
- _GL_FUNCDECL_SYS (gettimeofday, int,
--  (struct timeval *restrict, void *restrict)
-+  (struct timeval *__restrict, void *__restrict)
-   _GL_ARG_NONNULL ((1)));
- #  endif
- /* Need to cast, because on glibc systems, by default, the second argument is
-   struct timezone *.  */
- _GL_CXXALIAS_SYS_CAST (gettimeofday, int,
--   (struct timeval *restrict, void *restrict));
-+   (struct timeval *__restrict, void *__restrict));
- # endif
- _GL_CXXALIASWARN (gettimeofday);
- # if defined __cplusplus && defined GNULIB_NAMESPACE
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199474): 
https://lists.openembedded.org/g/openembedded-core/message/199474
Mute This Topic: https://lists.openembedded.org/mt/106132521/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 05/13] grub: mark grub-module-explicitly-keeps-symbole-.module_license.patch as a workaround

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Signed-off-by: Alexander Kanavin 
---
 .../grub-module-explicitly-keeps-symbole-.module_license.patch  | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git 
a/meta/recipes-bsp/grub/files/grub-module-explicitly-keeps-symbole-.module_license.patch
 
b/meta/recipes-bsp/grub/files/grub-module-explicitly-keeps-symbole-.module_license.patch
index d9012d1dd63..7c8770ce8bd 100644
--- 
a/meta/recipes-bsp/grub/files/grub-module-explicitly-keeps-symbole-.module_license.patch
+++ 
b/meta/recipes-bsp/grub/files/grub-module-explicitly-keeps-symbole-.module_license.patch
@@ -37,7 +37,7 @@ SYMBOL TABLE:
  ld  .modname    .modname
 --
 
-Upstream-Status: Pending
+Upstream-Status: Inappropriate [workaround that needs investigation into 
@TARGET_STRIP@ behaviour in oe-core vs toolchain used by upstream]
 
 Signed-off-by: Hongxu Jia 
 
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199472): 
https://lists.openembedded.org/g/openembedded-core/message/199472
Mute This Topic: https://lists.openembedded.org/mt/106132519/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 01/13] mesa: remove obsolete 0001-meson.build-check-for-all-linux-host_os-combinations.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

The patch was submitted upstream
https://gitlab.freedesktop.org/mesa/mesa/-/merge_requests/28895
but further investigation revealed that the problem had been solved properly
in meson.class:
https://git.yoctoproject.org/poky/commit/?id=6bf674374d568b2419a4c6eef00d893028878881

Signed-off-by: Alexander Kanavin 
---
 ...k-for-all-linux-host_os-combinations.patch | 42 ---
 meta/recipes-graphics/mesa/mesa.inc   |  1 -
 2 files changed, 43 deletions(-)
 delete mode 100644 
meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch

diff --git 
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
 
b/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
deleted file mode 100644
index 7be7d81eeb7..000
--- 
a/meta/recipes-graphics/mesa/files/0001-meson.build-check-for-all-linux-host_os-combinations.patch
+++ /dev/null
@@ -1,42 +0,0 @@
-From e8ec6b1cc5e401ba719095722d8b317d755ae613 Mon Sep 17 00:00:00 2001
-From: Alistair Francis 
-Date: Thu, 14 Nov 2019 13:04:49 -0800
-Subject: [PATCH] meson.build: check for all linux host_os combinations
-
-Make sure that we are also looking for our host_os combinations like
-linux-musl etc. when assuming support for DRM/KMS.
-
-Also delete a duplicate line.
-
-Upstream-Status: Pending
-
-Signed-off-by: Anuj Mittal 
-Signed-off-by: Fabio Berton 
-Signed-off-by: Otavio Salvador 
-Signed-off-by: Alistair Francis 

- meson.build | 4 ++--
- 1 file changed, 2 insertions(+), 2 deletions(-)
-
-diff --git a/meson.build b/meson.build
-index 133fd9a..817861e 100644
 a/meson.build
-+++ b/meson.build
-@@ -128,7 +128,7 @@ with_any_opengl = with_opengl or with_gles1 or with_gles2
- # Only build shared_glapi if at least one OpenGL API is enabled
- with_shared_glapi = with_shared_glapi and with_any_opengl
- 
--system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'gnu/kfreebsd', 
'dragonfly', 'linux', 'sunos', 'android', 
'managarm'].contains(host_machine.system())
-+system_has_kms_drm = ['openbsd', 'netbsd', 'freebsd', 'gnu/kfreebsd', 
'dragonfly', 'linux', 'sunos', 'android', 
'managarm'].contains(host_machine.system()) or 
host_machine.system().startswith('linux')
- 
- gallium_drivers = get_option('gallium-drivers')
- if gallium_drivers.contains('auto')
-@@ -997,7 +997,7 @@ if cc.has_function('fmemopen')
- endif
- 
- # TODO: this is very incomplete
--if ['linux', 'cygwin', 'gnu', 'freebsd', 'gnu/kfreebsd', 'haiku', 'android', 
'managarm'].contains(host_machine.system())
-+if ['linux', 'cygwin', 'gnu', 'freebsd', 'gnu/kfreebsd', 'haiku', 'android', 
'managarm'].contains(host_machine.system()) or 
host_machine.system().startswith('linux')
-   pre_args += '-D_GNU_SOURCE'
- elif host_machine.system() == 'sunos'
-   pre_args += '-D__EXTENSIONS__'
diff --git a/meta/recipes-graphics/mesa/mesa.inc 
b/meta/recipes-graphics/mesa/mesa.inc
index 77e9c80fcb6..a8f3397e04a 100644
--- a/meta/recipes-graphics/mesa/mesa.inc
+++ b/meta/recipes-graphics/mesa/mesa.inc
@@ -15,7 +15,6 @@ LIC_FILES_CHKSUM = 
"file://docs/license.rst;md5=63779ec98d78d823a9dc533a0735ef10
 PE = "2"
 
 SRC_URI = "https://mesa.freedesktop.org/archive/mesa-${PV}.tar.xz \
-   
file://0001-meson.build-check-for-all-linux-host_os-combinations.patch \
file://0001-meson-misdetects-64bit-atomics-on-mips-clang.patch \
file://0001-drisw-fix-build-without-dri3.patch \
file://0002-glxext-don-t-try-zink-if-not-enabled-in-mesa.patch \
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199468): 
https://lists.openembedded.org/g/openembedded-core/message/199468
Mute This Topic: https://lists.openembedded.org/mt/106132515/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 02/13] glib-2.0: remove obsolete 0001-Set-host_machine-correctly-when-building-with-mingw3.patch

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

This as well has been solved via
https://git.yoctoproject.org/poky/commit/?id=f6a35934540e910794b8729ecc278189a39b710f

Signed-off-by: Alexander Kanavin 
---
 ...-correctly-when-building-with-mingw3.patch | 80 ---
 meta/recipes-core/glib-2.0/glib.inc   |  1 -
 2 files changed, 81 deletions(-)
 delete mode 100644 
meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch

diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
 
b/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
deleted file mode 100644
index a2f9dd9672f..000
--- 
a/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
+++ /dev/null
@@ -1,80 +0,0 @@
-From 01810df82fae752428d3756c85edb2eb7bbf3c15 Mon Sep 17 00:00:00 2001
-From: Alexander Kanavin 
-Date: Wed, 13 Feb 2019 15:32:05 +0100
-Subject: [PATCH] Set host_machine correctly when building with mingw32
-
-Upstream-Status: Inappropriate [oe-core specific]
-Signed-off-by: Alexander Kanavin 

- gio/tests/meson.build  | 8 
- glib/tests/meson.build | 2 +-
- meson.build| 3 +++
- 3 files changed, 8 insertions(+), 5 deletions(-)
-
-diff --git a/gio/tests/meson.build b/gio/tests/meson.build
-index 232ecca..563298b 100644
 a/gio/tests/meson.build
-+++ b/gio/tests/meson.build
-@@ -29,7 +29,7 @@ endif
- 
- test_cpp_args = test_c_args
- 
--if host_machine.system() == 'windows'
-+if host_system == 'windows'
-   common_gio_tests_deps += [iphlpapi_dep, winsock2, cc.find_library 
('secur32')]
- endif
- 
-@@ -244,7 +244,7 @@ if have_dbus_daemon
- endif
- 
- #  Test programs buildable on UNIX only
--if host_machine.system() != 'windows'
-+if host_system != 'windows'
-   gio_tests += {
- 'file' : {
-   # FIXME: https://gitlab.gnome.org/GNOME/glib/-/issues/3148
-@@ -593,7 +593,7 @@ if host_machine.system() != 'windows'
- endif # unix
- 
- #  Test programs buildable on Windows only
--if host_machine.system() == 'windows'
-+if host_system == 'windows'
-   gio_tests += {'win32-streams' : {}}
- endif
- 
-@@ -663,7 +663,7 @@ if cc.get_id() != 'msvc' and cc.get_id() != 'clang-cl'
-   }
- endif
- 
--if host_machine.system() != 'windows'
-+if host_system != 'windows'
-   test_extra_programs += {
- 'gdbus-example-unix-fd-client' : {
-   'install' : false,
-diff --git a/glib/tests/meson.build b/glib/tests/meson.build
-index f6efc59..83eb5a5 100644
 a/glib/tests/meson.build
-+++ b/glib/tests/meson.build
-@@ -226,7 +226,7 @@ if glib_conf.has('HAVE_EVENTFD')
-   }
- endif
- 
--if host_machine.system() == 'windows'
-+if host_system == 'windows'
-   if winsock2.found()
- glib_tests += {
-   'gpoll' : {
-diff --git a/meson.build b/meson.build
-index 7534542..2560686 100644
 a/meson.build
-+++ b/meson.build
-@@ -54,6 +54,9 @@ else
- endif
- 
- host_system = host_machine.system()
-+if host_system == 'mingw32'
-+  host_system = 'windows'
-+endif
- 
- if host_system == 'darwin'
-   ios_test_code = '''#include 
diff --git a/meta/recipes-core/glib-2.0/glib.inc 
b/meta/recipes-core/glib-2.0/glib.inc
index 1a97a0d02a6..2de50dd9af3 100644
--- a/meta/recipes-core/glib-2.0/glib.inc
+++ b/meta/recipes-core/glib-2.0/glib.inc
@@ -222,7 +222,6 @@ SRC_URI = 
"${GNOME_MIRROR}/glib/${SHRT_VER}/glib-${PV}.tar.xz \

file://0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch \
file://0001-Install-gio-querymodules-as-libexec_PROGRAM.patch \
file://0010-Do-not-hardcode-python-path-into-various-tools.patch \
-   
file://0001-Set-host_machine-correctly-when-building-with-mingw3.patch \
file://0001-Do-not-write-bindir-into-pkg-config-files.patch \
file://0001-meson-Run-atomics-test-on-clang-as-well.patch \

file://0001-gio-tests-resources.c-comment-out-a-build-host-only-.patch \
-- 
2.39.2


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



[OE-core] [PATCH 4/4] rust: build the default set of tools

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Setting it explicitly replaces rust's default choice which is rustdoc
(needed for example in selftests and otherwise expected to be present
in typical rust installations):

https://github.com/rust-lang/rust/blob/master/config.example.toml#L320

This addresses some of the rust selftest failures but not all. Help
is appreciate to restore the selftest.

Unfortunately, this also breaks rust reproducibility (or rather exposes
that it was never properly fixed, as explained here:
https://lists.openembedded.org/g/openembedded-core/message/199288
)

Signed-off-by: Alexander Kanavin 
---
 meta/lib/oeqa/selftest/cases/reproducible.py | 2 ++
 meta/recipes-devtools/rust/rust_1.75.0.bb| 1 -
 2 files changed, 2 insertions(+), 1 deletion(-)

diff --git a/meta/lib/oeqa/selftest/cases/reproducible.py 
b/meta/lib/oeqa/selftest/cases/reproducible.py
index 80e830136f7..97a9c3da908 100644
--- a/meta/lib/oeqa/selftest/cases/reproducible.py
+++ b/meta/lib/oeqa/selftest/cases/reproducible.py
@@ -16,6 +16,8 @@ import os
 import datetime
 
 exclude_packages = [
+   'rust-rustdoc',
+   'rust-dbg'
]
 
 def is_excluded(package):
diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb 
b/meta/recipes-devtools/rust/rust_1.75.0.bb
index e82a7395e44..b041a5f8e4c 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -149,7 +149,6 @@ python do_configure() {
 config.add_section("build")
 config.set("build", "submodules", e(False))
 config.set("build", "docs", e(False))
-config.set("build", "tools", ["rust-demangler",])
 
 rustc = d.getVar('RUSTC_BOOTSTRAP')
 config.set("build", "rustc", e(rustc))
-- 
2.39.2


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



[OE-core] [PATCH 2/4] rust: add reproducibility patch to eliminate host leakage

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

[YOCTO #15185]

Signed-off-by: Alexander Kanavin 
---
 ...te-host-information-into-compilation.patch | 51 +++
 meta/recipes-devtools/rust/rust-source.inc|  1 +
 2 files changed, 52 insertions(+)
 create mode 100644 
meta/recipes-devtools/rust/files/0001-cargo-do-not-write-host-information-into-compilation.patch

diff --git 
a/meta/recipes-devtools/rust/files/0001-cargo-do-not-write-host-information-into-compilation.patch
 
b/meta/recipes-devtools/rust/files/0001-cargo-do-not-write-host-information-into-compilation.patch
new file mode 100644
index 000..a6ee8676058
--- /dev/null
+++ 
b/meta/recipes-devtools/rust/files/0001-cargo-do-not-write-host-information-into-compilation.patch
@@ -0,0 +1,51 @@
+From 065d7c263091118437465d714d8a29dbb6296921 Mon Sep 17 00:00:00 2001
+From: Alexander Kanavin 
+Date: Mon, 13 May 2024 14:57:54 +0200
+Subject: [PATCH] cargo: do not write host information into compilation unit
+ hashes
+
+This breaks reproducibility in cross-builds where the cross-target
+can be the same, but build hosts are different, as seen with
+"rustc --version -v":
+...
+host: x86_64-unknown-linux-gnu
+
+vs.
+
+host: aarch64-unknown-linux-gnu
+
+This can possibly be improved by only hashing host info if the build
+is a native one (e.g. there's no --target option passed to cargo
+invocation) but I'm not sure how.
+
+Upstream-Status: Inappropriate [reported at 
https://github.com/rust-lang/cargo/issues/13922]
+Signed-off-by: Alexander Kanavin 
+---
+ .../src/cargo/core/compiler/context/compilation_files.rs  | 4 ++--
+ 1 file changed, 2 insertions(+), 2 deletions(-)
+
+diff --git 
a/src/tools/cargo/src/cargo/core/compiler/context/compilation_files.rs 
b/src/tools/cargo/src/cargo/core/compiler/context/compilation_files.rs
+index d83dbf10c..b2ad8d9f3 100644
+--- a/src/tools/cargo/src/cargo/core/compiler/context/compilation_files.rs
 b/src/tools/cargo/src/cargo/core/compiler/context/compilation_files.rs
+@@ -652,7 +652,7 @@ fn hash_rustc_version(bcx: <'_, '_>, hasher: 
 StableHasher) {
+ if vers.pre.is_empty() || bcx.config.cli_unstable().separate_nightlies {
+ // For stable, keep the artifacts separate. This helps if someone is
+ // testing multiple versions, to avoid recompiles.
+-bcx.rustc().verbose_version.hash(hasher);
++//bcx.rustc().verbose_version.hash(hasher);
+ return;
+ }
+ // On "nightly"/"beta"/"dev"/etc, keep each "channel" separate. Don't hash
+@@ -665,7 +665,7 @@ fn hash_rustc_version(bcx: <'_, '_>, hasher: 
 StableHasher) {
+ // Keep "host" since some people switch hosts to implicitly change
+ // targets, (like gnu vs musl or gnu vs msvc). In the future, we may want
+ // to consider hashing `unit.kind.short_name()` instead.
+-bcx.rustc().host.hash(hasher);
++//bcx.rustc().host.hash(hasher);
+ // None of the other lines are important. Currently they are:
+ // binary: rustc  <-- or "rustdoc"
+ // commit-hash: 38114ff16e7856f98b2b4be7ab4cd29b38bed59a
+-- 
+2.39.2
+
diff --git a/meta/recipes-devtools/rust/rust-source.inc 
b/meta/recipes-devtools/rust/rust-source.inc
index c83c8ec3a39..20ef5e82bc4 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -12,6 +12,7 @@ SRC_URI += 
"https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
 file://target-build-value.patch;patchdir=${RUSTSRC} \
 
file://0001-Handle-vendored-sources-when-remapping-paths.patch;patchdir=${RUSTSRC}
 \
 file://repro-issue-fix-with-v175.patch;patchdir=${RUSTSRC} \
+
file://0001-cargo-do-not-write-host-information-into-compilation.patch;patchdir=${RUSTSRC}
 \
 "
 SRC_URI[rust.sha256sum] = 
"4526f786d673e4859ff2afa0bab2ba13c918b796519a25c1acce06dba9542340"
 
-- 
2.39.2


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



[OE-core] [PATCH 1/4] rust: correctly link rust-snapshot into build/stage0

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

This does not seem to be used in regular builds, but is beneficial
in rust selftest, where it allows dropping a custom patch
that is unsuitable for upstream (and was rejected by them).

Also remove an obsolete comment that seems related to the code
but describes something that was resolved long time ago.

I have confirmed that the rust selftest continues to pass with just
this one commit on top of master (as the following changes do break
the selftest).

Signed-off-by: Alexander Kanavin 
---
 .../rust/files/cargo-path.patch   | 37 ---
 meta/recipes-devtools/rust/rust-source.inc|  1 -
 meta/recipes-devtools/rust/rust_1.75.0.bb |  6 +--
 3 files changed, 2 insertions(+), 42 deletions(-)
 delete mode 100644 meta/recipes-devtools/rust/files/cargo-path.patch

diff --git a/meta/recipes-devtools/rust/files/cargo-path.patch 
b/meta/recipes-devtools/rust/files/cargo-path.patch
deleted file mode 100644
index 9a50c402201..000
--- a/meta/recipes-devtools/rust/files/cargo-path.patch
+++ /dev/null
@@ -1,37 +0,0 @@
-Fix the cargo binary path error and ensure that it is fetched
-during rustc bootstrap in rust oe-selftest.
-
-==
-ERROR: test_cargoflags (bootstrap_test.BuildBootstrap)
---
-Traceback (most recent call last):
-  File 
"/home/build-st/tmp/work/cortexa57-poky-linux/rust/1.74.1/rustc-1.74.1-src/src/bootstrap/bootstrap_test.py",
 line 157, in test_cargoflags
-args, _ = self.build_args(env={"CARGOFLAGS": "--timings"})
-  File 
"/home/build-st/tmp/work/cortexa57-poky-linux/rust/1.74.1/rustc-1.74.1-src/src/bootstrap/bootstrap_test.py",
 line 154, in build_args
-return build.build_bootstrap_cmd(env), env
-  File 
"/home/build-st/tmp/work/cortexa57-poky-linux/rust/1.74.1/rustc-1.74.1-src/src/bootstrap/bootstrap.py",
 line 960, in build_bootstrap_cmd
-raise Exception("no cargo executable found at `{}`".format(
-Exception: no cargo executable found at 
`/home/build-st/tmp/work/cortexa57-poky-linux/rust/1.74.1/rustc-1.74.1-src/build/x86_64-unknown-linux-gnu/stage0/bin/cargo`
-
-Upstream-Status: Submitted [https://github.com/rust-lang/rust/pull/120125]
-
-Signed-off-by: Yash Shinde 

-diff --git a/src/bootstrap/bootstrap.py b/src/bootstrap/bootstrap.py
 a/src/bootstrap/bootstrap.py
-+++ b/src/bootstrap/bootstrap.py
-@@ -954,9 +954,11 @@
- if "RUSTFLAGS_BOOTSTRAP" in env:
- env["RUSTFLAGS"] += " " + env["RUSTFLAGS_BOOTSTRAP"]
-
--env["PATH"] = os.path.join(self.bin_root(), "bin") + \
--os.pathsep + env["PATH"]
--if not os.path.isfile(self.cargo()):
-+cargo_bin_path = os.path.join(self.bin_root(), "bin", "cargo")
-+if not os.path.isfile(cargo_bin_path):
-+cargo_bin_path = os.getenv("RUST_TARGET_PATH") + 
"rust-snapshot/bin/cargo"
-+env["PATH"] = os.path.dirname(cargo_bin_path) + os.pathsep + 
env["PATH"]
-+else:
- raise Exception("no cargo executable found at `{}`".format(
- self.cargo()))
- args = [self.cargo(), "build", "--manifest-path",
diff --git a/meta/recipes-devtools/rust/rust-source.inc 
b/meta/recipes-devtools/rust/rust-source.inc
index b14221b6cb8..c83c8ec3a39 100644
--- a/meta/recipes-devtools/rust/rust-source.inc
+++ b/meta/recipes-devtools/rust/rust-source.inc
@@ -7,7 +7,6 @@ SRC_URI += 
"https://static.rust-lang.org/dist/rustc-${RUST_VERSION}-src.tar.xz;n
 file://rv32-missing-syscalls.patch;patchdir=${RUSTSRC} \
 file://rv32-rustix-libc-backend.patch;patchdir=${RUSTSRC} \
 file://rv32-cargo-rustix-0.38.19-fix.patch;patchdir=${RUSTSRC} \
-file://cargo-path.patch;patchdir=${RUSTSRC} \
 file://custom-target-cfg.patch;patchdir=${RUSTSRC} \
 file://rustc-bootstrap.patch;patchdir=${RUSTSRC} \
 file://target-build-value.patch;patchdir=${RUSTSRC} \
diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb 
b/meta/recipes-devtools/rust/rust_1.75.0.bb
index 76e1fe2d84a..8ef838ee90c 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -35,8 +35,6 @@ RUST_ALTERNATE_EXE_PATH_NATIVE = 
"${STAGING_LIBDIR_NATIVE}/llvm-rust/bin/llvm-co
 # own vendoring.
 CARGO_DISABLE_BITBAKE_VENDORING = "1"
 
-# We can't use RUST_BUILD_SYS here because that may be "musl" if
-# TCLIBC="musl". Snapshots are always -unknown-linux-gnu
 setup_cargo_environment () {
 # The first step is to build bootstrap and some early stage tools,
 # these are build for the same target as the snapshot, e.g.
@@ -54,8 +52,8 @@ do_rust_setup_snapshot () {
 
 # Some versions of rust (e.g. 1.18.0) tries to find cargo in 
stage0/bin/cargo
 # and fail without it there.
-mkdir -p ${RUSTSRC}/build/${BUILD_SYS}
-ln -sf ${WORKDIR}/rust-snapshot/ 

[OE-core] [PATCH 3/4] rust: use rust-snapshot binaries only in rust-native

2024-05-16 Thread Alexander Kanavin
From: Alexander Kanavin 

Otherwise, use rust-native and cargo-native binaries as that allows
our native tweaks in them to be used for target/nativesdk rust -
same as for everything else written in rust.

In particular, this allows building target rust with
cargo-native that includes important reproducibility tweaks.

Unfortunately, this also breaks rust selftest, and that
is partially addressed by the following commit.

[YOCTO #15185]

Signed-off-by: Alexander Kanavin 
---
 meta/recipes-devtools/rust/rust_1.75.0.bb | 14 --
 1 file changed, 12 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-devtools/rust/rust_1.75.0.bb 
b/meta/recipes-devtools/rust/rust_1.75.0.bb
index 8ef838ee90c..e82a7395e44 100644
--- a/meta/recipes-devtools/rust/rust_1.75.0.bb
+++ b/meta/recipes-devtools/rust/rust_1.75.0.bb
@@ -11,6 +11,11 @@ DEPENDS += "file-native python3-native"
 DEPENDS:append:class-native = " rust-llvm-native"
 DEPENDS:append:class-nativesdk = " nativesdk-rust-llvm"
 
+# native rust uses cargo/rustc from binary snapshots to bootstrap
+# but everything else should use our native builds
+DEPENDS:append:class-target = " cargo-native rust-native"
+DEPENDS:append:class-nativesdk = " cargo-native rust-native"
+
 DEPENDS += "rust-llvm (=${PV})"
 
 RDEPENDS:${PN}:append:class-target = " gcc g++ binutils"
@@ -68,6 +73,11 @@ addtask do_test_compile after do_configure 
do_rust_gen_targets
 do_rust_setup_snapshot[dirs] += "${WORKDIR}/rust-snapshot"
 do_rust_setup_snapshot[vardepsexclude] += "UNINATIVE_LOADER"
 
+RUSTC_BOOTSTRAP = "${STAGING_BINDIR_NATIVE}/rustc"
+CARGO_BOOTSTRAP = "${STAGING_BINDIR_NATIVE}/cargo"
+RUSTC_BOOTSTRAP:class-native = "${WORKDIR}/rust-snapshot/bin/rustc"
+CARGO_BOOTSTRAP:class-native = "${WORKDIR}/rust-snapshot/bin/cargo"
+
 python do_configure() {
 import json
 import configparser
@@ -141,10 +151,10 @@ python do_configure() {
 config.set("build", "docs", e(False))
 config.set("build", "tools", ["rust-demangler",])
 
-rustc = d.expand("${WORKDIR}/rust-snapshot/bin/rustc")
+rustc = d.getVar('RUSTC_BOOTSTRAP')
 config.set("build", "rustc", e(rustc))
 
-cargo = d.expand("${WORKDIR}/rust-snapshot/bin/cargo")
+cargo = d.getVar('CARGO_BOOTSTRAP')
 config.set("build", "cargo", e(cargo))
 
 config.set("build", "vendor", e(True))
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199465): 
https://lists.openembedded.org/g/openembedded-core/message/199465
Mute This Topic: https://lists.openembedded.org/mt/106132434/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] fribidi: upgrade 1.0.13 -> 1.0.14

2024-05-16 Thread Ross Burton
* Updated Unicode tables to version 15.1

Signed-off-by: Ross Burton 
---
 .../fribidi/{fribidi_1.0.13.bb => fribidi_1.0.14.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-support/fribidi/{fribidi_1.0.13.bb => fribidi_1.0.14.bb} 
(89%)

diff --git a/meta/recipes-support/fribidi/fribidi_1.0.13.bb 
b/meta/recipes-support/fribidi/fribidi_1.0.14.bb
similarity index 89%
rename from meta/recipes-support/fribidi/fribidi_1.0.13.bb
rename to meta/recipes-support/fribidi/fribidi_1.0.14.bb
index 5d0476a3752..51752096de1 100644
--- a/meta/recipes-support/fribidi/fribidi_1.0.13.bb
+++ b/meta/recipes-support/fribidi/fribidi_1.0.14.bb
@@ -11,7 +11,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=a916467b91076e631dd8edb7424769c7"
 
 SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/${BP}.tar.xz \
"
-SRC_URI[sha256sum] = 
"7fa16c80c81bd622f7b198d31356da139cc318a63fc7761217af4130903f54a2"
+SRC_URI[sha256sum] = 
"76ae204a7027652ac3981b9fa5817c083ba23114340284c58e756b259cd2259a"
 
 inherit meson lib_package pkgconfig github-releases
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199463): 
https://lists.openembedded.org/g/openembedded-core/message/199463
Mute This Topic: https://lists.openembedded.org/mt/106132270/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] python3-hatchling: upgrade 1.24.1 -> 1.24.2

2024-05-16 Thread Ross Burton
* Add .venv to the list of directories that cannot be traversed
* Output from the core Application utility now writes to stderr

Signed-off-by: Ross Burton 
---
 ...{python3-hatchling_1.24.1.bb => python3-hatchling_1.24.2.bb} | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-devtools/python/{python3-hatchling_1.24.1.bb => 
python3-hatchling_1.24.2.bb} (85%)

diff --git a/meta/recipes-devtools/python/python3-hatchling_1.24.1.bb 
b/meta/recipes-devtools/python/python3-hatchling_1.24.2.bb
similarity index 85%
rename from meta/recipes-devtools/python/python3-hatchling_1.24.1.bb
rename to meta/recipes-devtools/python/python3-hatchling_1.24.2.bb
index fc8d9532813..0ad545f448b 100644
--- a/meta/recipes-devtools/python/python3-hatchling_1.24.1.bb
+++ b/meta/recipes-devtools/python/python3-hatchling_1.24.2.bb
@@ -8,7 +8,7 @@ inherit pypi python_hatchling
 DEPENDS += "python3-pluggy-native python3-pathspec-native 
python3-packaging-native python3-editables-native 
python3-trove-classifiers-native"
 DEPENDS:remove:class-native = "python3-hatchling-native"
 
-SRC_URI[sha256sum] = 
"51f861891e98c4044eb455163a737e5d2328d7aa74890b182db2d80fee22a497"
+SRC_URI[sha256sum] = 
"41ddc27cdb25db9ef7b68bef075f829c84cb349aa1bff8240797d012510547b0"
 
 do_compile:prepend() {
 export PYTHONPATH=src
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199461): 
https://lists.openembedded.org/g/openembedded-core/message/199461
Mute This Topic: https://lists.openembedded.org/mt/106132268/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] gdk-pixbuf: upgrade 2.42.11 -> 2.42.12

2024-05-16 Thread Ross Burton
- Fix a build failure (Christian Heusel)
- Fix occasional build failures (Benjamin Gilbert)
- ani: Reject files with multiple INA or IART chunks (Benjamin Gilbert)
- ani: Reject files with multiple anih chunks (Benjamin Gilbert, CVE-2022-48622)
- ani: validate chunk size (Benjamin Gilbert)
- Translation updates

Signed-off-by: Ross Burton 
---
 ...n.build-allow-a-subset-of-tests-in-cross-compile.patch | 8 
 .../gdk-pixbuf/gdk-pixbuf/fatal-loader.patch  | 2 +-
 .../{gdk-pixbuf_2.42.11.bb => gdk-pixbuf_2.42.12.bb}  | 2 +-
 3 files changed, 6 insertions(+), 6 deletions(-)
 rename meta/recipes-gnome/gdk-pixbuf/{gdk-pixbuf_2.42.11.bb => 
gdk-pixbuf_2.42.12.bb} (98%)

diff --git 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-meson.build-allow-a-subset-of-tests-in-cross-compile.patch
 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-meson.build-allow-a-subset-of-tests-in-cross-compile.patch
index 3d685db7742..24edda81021 100644
--- 
a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-meson.build-allow-a-subset-of-tests-in-cross-compile.patch
+++ 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/0001-meson.build-allow-a-subset-of-tests-in-cross-compile.patch
@@ -1,4 +1,4 @@
-From 4bfb696fd125f044e3df9f6983c4ad518d9552c7 Mon Sep 17 00:00:00 2001
+From 325a4cde99a00b84116ab7111d27e6973f3c5026 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Thu, 26 Jan 2023 20:29:46 +0100
 Subject: [PATCH] meson.build: allow (a subset of) tests in cross compile
@@ -19,7 +19,7 @@ Signed-off-by: Alexander Kanavin 
  2 files changed, 9 insertions(+), 7 deletions(-)
 
 diff --git a/meson.build b/meson.build
-index 78f3683..e0feaee 100644
+index 3eb3fcc..dc7e790 100644
 --- a/meson.build
 +++ b/meson.build
 @@ -390,10 +390,10 @@ subdir('gdk-pixbuf')
@@ -37,7 +37,7 @@ index 78f3683..e0feaee 100644
  endif
  
 diff --git a/tests/meson.build b/tests/meson.build
-index 78d0ad9..0c9e64e 100644
+index 3781066..911b5fb 100644
 --- a/tests/meson.build
 +++ b/tests/meson.build
 @@ -4,7 +4,7 @@
@@ -49,7 +49,7 @@ index 78d0ad9..0c9e64e 100644
# Resources; we cannot use gnome.compile_resources() here, because we need 
to
# override the environment in order to use the utilities we just built 
instead
# of the system ones
-@@ -172,9 +172,11 @@ endif
+@@ -164,9 +164,11 @@ endif
  test_deps = gdk_pixbuf_deps + [ gdkpixbuf_dep, ]
  test_args = [ '-k' ]
  test_env = environment()
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
index 80c93e2166f..3b4bf628614 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf/fatal-loader.patch
@@ -1,4 +1,4 @@
-From 9b4f5738f8ac30f393b6163dcc84757976683d9b Mon Sep 17 00:00:00 2001
+From f78ab4edaee5f62663a9a4bcfa56e5c524da4474 Mon Sep 17 00:00:00 2001
 From: Ross Burton 
 Date: Tue, 1 Apr 2014 17:23:36 +0100
 Subject: [PATCH] gdk-pixbuf: add an option so that loader errors are fatal
diff --git a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.11.bb 
b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.12.bb
similarity index 98%
rename from meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.11.bb
rename to meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.12.bb
index ef0f23f8f7e..9f825a68efb 100644
--- a/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.11.bb
+++ b/meta/recipes-gnome/gdk-pixbuf/gdk-pixbuf_2.42.12.bb
@@ -22,7 +22,7 @@ SRC_URI = 
"${GNOME_MIRROR}/${BPN}/${MAJ_VER}/${BPN}-${PV}.tar.xz \

file://0001-meson.build-allow-a-subset-of-tests-in-cross-compile.patch \
"
 
-SRC_URI[sha256sum] = 
"49dcb402388708647e8c321d56b6fb30f21e51e515d0c5a942268d23052a2f00"
+SRC_URI[sha256sum] = 
"b9505b3445b9a7e48ced34760c3bcb73e966df3ac94c95a148cb669ab748e3c7"
 
 inherit meson pkgconfig gettext pixbufcache ptest-gnome 
upstream-version-is-even gobject-introspection gi-docgen lib_package
 
-- 
2.34.1


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



[OE-core] What does "do_menuconfig is disabled" really mean?

2024-05-16 Thread Mike Looijmans
Using scartgap branch, trying to create a kernel recipe for a custom LS1028 
machine.


The recipe in meta-freescale for the ls1028ardb is hopelessly outdated and 
produces a 5.10 kernel.


So for my custom board based on the ls1028 I want to create a recipe that 
builds a mainline kernel (I don't need GPU or fancy things that require 
firmware or special drivers, so mainline should be fine).


I started out trying to get linux-yocto to build for my board, so copied the 
"skeleton" recipe, adjusted a bit (add COMPATIBLE_MACHINE and a defconfig).


But when I then run "bitbake -c menuconfig virtual/kernel" I always get this 
message:


ERROR: linux-yocto-*-6.6+git-r0 do_menuconfig: do_menuconfig is disabled, 
please check KCONFIG_CONFIG_ENABLE_MENUCONFIG variable.


I tried starting with a copy of recipes like linux-fscl, same error. Always.

(note: I've run "menuconfig" a million times by now, for dozens of boards, so 
it's not the system).


I tried adding
KCONFIG_CONFIG_ENABLE_MENUCONFIG="true"
to my recipe, but that also had no effect.

The log file also contains no information whatsoever.

What's the real issue?


--
Mike Looijmans
System Expert

TOPIC Embedded Products B.V.
Materiaalweg 4, 5681 RJ Best
The Netherlands

T: +31 (0) 499 33 69 69
E: mike.looijm...@topic.nl
W: www.topic.nl


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199460): 
https://lists.openembedded.org/g/openembedded-core/message/199460
Mute This Topic: https://lists.openembedded.org/mt/106132236/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] Debugging rust oe-selftest failures

2024-05-16 Thread Alexander Kanavin
On Thu, 16 May 2024 at 12:57, Yash Shinde  wrote:
> We have rust 1.76 and 1.77 upgrades along with test suite working
> locally. Currently, we are testing with 1.78 upgrade.
>
> IIUC, Alex has another series of AB fixes which breaks the test suite.
> Should we check the test suite with those patches or sent them to the
> oe-core mailing list?
> Let me know your thoughts on this.

I'll send the ab patches that break the test suite later today; the
request is to take them, and unbreak the test suite.

Then you can rebase your upgrade work on top of that. And address the
usability points I made.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199459): 
https://lists.openembedded.org/g/openembedded-core/message/199459
Mute This Topic: https://lists.openembedded.org/mt/105307188/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] Debugging rust oe-selftest failures

2024-05-16 Thread Yash Shinde via lists.openembedded.org


On 16-05-2024 15:53, Alexander Kanavin wrote:

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

On Thu, 16 May 2024 at 12:15, Richard Purdie  wrote:

There is an extra consideration to this unfortunately which is
scarthgap. For better or worse we have an LTS release with a mostly
working test suite and this arm/x86 issue is present.

Should I take the patches to master, the next instant request will be a
backport to scarthgap.

That gives me pause for thought on what to do here...

I suppose we could give people who understand the test suite time to
unbreak it, before updating rust version. Then both the AB fixes and
test suite fixes could be backported. I'm going to send the ab fxes
today, just writing the upstream report now.

Alex

We have rust 1.76 and 1.77 upgrades along with test suite working 
locally. Currently, we are testing with 1.78 upgrade.


IIUC, Alex has another series of AB fixes which breaks the test suite.
Should we check the test suite with those patches or sent them to the 
oe-core mailing list?

Let me know your thoughts on this.

Regards,
Yash

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



[OE-core] [PATCH 1/4] harfbuzz: upgrade 8.4.0 -> 8.5.0

2024-05-16 Thread Anuj Mittal
Signed-off-by: Anuj Mittal 
---
 .../harfbuzz/{harfbuzz_8.4.0.bb => harfbuzz_8.5.0.bb}   | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-graphics/harfbuzz/{harfbuzz_8.4.0.bb => harfbuzz_8.5.0.bb} 
(95%)

diff --git a/meta/recipes-graphics/harfbuzz/harfbuzz_8.4.0.bb 
b/meta/recipes-graphics/harfbuzz/harfbuzz_8.5.0.bb
similarity index 95%
rename from meta/recipes-graphics/harfbuzz/harfbuzz_8.4.0.bb
rename to meta/recipes-graphics/harfbuzz/harfbuzz_8.5.0.bb
index fc6951d9edb..97efc56c646 100644
--- a/meta/recipes-graphics/harfbuzz/harfbuzz_8.4.0.bb
+++ b/meta/recipes-graphics/harfbuzz/harfbuzz_8.5.0.bb
@@ -9,7 +9,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b98429b8e8e3c2a67cfef01e99e4893d \
 "
 
 SRC_URI = "${GITHUB_BASE_URI}/download/${PV}/${BPN}-${PV}.tar.xz"
-SRC_URI[sha256sum] = 
"af4ea73e25ab748c8c063b78c2f88e48833db9b2ac369e29bd115702e789755e"
+SRC_URI[sha256sum] = 
"77e4f7f98f3d86bf8788b53e6832fb96279956e1c3961988ea3d4b7ca41ddc27"
 
 DEPENDS += "glib-2.0-native"
 
-- 
2.45.0


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



[OE-core] [PATCH 4/4] glib-networking: upgrade 2.78.1 -> 2.80.0

2024-05-16 Thread Anuj Mittal
Signed-off-by: Anuj Mittal 
---
 meta/recipes-core/glib-networking/glib-networking/eagain.patch  | 2 +-
 .../{glib-networking_2.78.1.bb => glib-networking_2.80.0.bb}| 2 +-
 2 files changed, 2 insertions(+), 2 deletions(-)
 rename meta/recipes-core/glib-networking/{glib-networking_2.78.1.bb => 
glib-networking_2.80.0.bb} (95%)

diff --git a/meta/recipes-core/glib-networking/glib-networking/eagain.patch 
b/meta/recipes-core/glib-networking/glib-networking/eagain.patch
index 6c2e3c634b7..88ac15e7d7c 100644
--- a/meta/recipes-core/glib-networking/glib-networking/eagain.patch
+++ b/meta/recipes-core/glib-networking/glib-networking/eagain.patch
@@ -1,4 +1,4 @@
-From 5604707bed4b4a4bc4658c7158a18c1774775775 Mon Sep 17 00:00:00 2001
+From 1bd273b207044a77fba6a6a57a743a1768b2676b Mon Sep 17 00:00:00 2001
 From: Richard Purdie 
 Date: Sat, 6 May 2023 12:18:50 +0100
 Subject: [PATCH] In autobuilder testing we regularly see glib-networking ptest
diff --git a/meta/recipes-core/glib-networking/glib-networking_2.78.1.bb 
b/meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
similarity index 95%
rename from meta/recipes-core/glib-networking/glib-networking_2.78.1.bb
rename to meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
index 5060d9fd7a1..c8a13555486 100644
--- a/meta/recipes-core/glib-networking/glib-networking_2.78.1.bb
+++ b/meta/recipes-core/glib-networking/glib-networking_2.80.0.bb
@@ -14,7 +14,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=4fbd65380cdd255951079008b364516c \
 SECTION = "libs"
 DEPENDS = "glib-2.0-native glib-2.0"
 
-SRC_URI[archive.sha256sum] = 
"e48f2ddbb049832cbb09230529c5e45daca9f0df0eda325f832f7379859bf09f"
+SRC_URI[archive.sha256sum] = 
"d8f4f1aab213179ae3351617b59dab5de6bcc9e785021eee178998ebd4bb3acf"
 
 # Upstream note that for the openssl backend, half the tests where this 
backend don't return
 # the expected error code or don't work as expected so default to gnutls
-- 
2.45.0


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



[OE-core] [PATCH 3/4] glib-2.0: upgrade 2.80.0 -> 2.80.2

2024-05-16 Thread Anuj Mittal
Signed-off-by: Anuj Mittal 
---
 ...Do-not-write-bindir-into-pkg-config-files.patch |  2 +-
 .../0001-Fix-DATADIRNAME-on-uclibc-Linux.patch |  2 +-
 ...stall-gio-querymodules-as-libexec_PROGRAM.patch |  2 +-
 ...warning-about-deprecated-paths-in-schemas.patch |  2 +-
 ...chine-correctly-when-building-with-mingw3.patch | 14 +++---
 ...esources.c-comment-out-a-build-host-only-.patch |  2 +-
 ...y-introspection-correctly-install-.gir-fi.patch |  2 +-
 ...1-meson-Run-atomics-test-on-clang-as-well.patch |  4 ++--
 ...-do-not-enable-pidfd-features-on-native-g.patch |  4 ++--
 ...t-hardcode-python-path-into-various-tools.patch |  2 +-
 .../glib-2.0/files/relocate-modules.patch  |  2 +-
 .../recipes-core/glib-2.0/files/skip-timeout.patch |  2 +-
 ...nitial_2.80.0.bb => glib-2.0-initial_2.80.2.bb} |  0
 .../{glib-2.0_2.80.0.bb => glib-2.0_2.80.2.bb} |  1 +
 meta/recipes-core/glib-2.0/glib.inc|  2 +-
 15 files changed, 22 insertions(+), 21 deletions(-)
 rename meta/recipes-core/glib-2.0/{glib-2.0-initial_2.80.0.bb => 
glib-2.0-initial_2.80.2.bb} (100%)
 rename meta/recipes-core/glib-2.0/{glib-2.0_2.80.0.bb => glib-2.0_2.80.2.bb} 
(94%)

diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
 
b/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
index f6eba04fd4c..10568b7c9fe 100644
--- 
a/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
+++ 
b/meta/recipes-core/glib-2.0/files/0001-Do-not-write-bindir-into-pkg-config-files.patch
@@ -1,4 +1,4 @@
-From 0561dcbf0918631d8106c3f6c2d8e92a5ec4b887 Mon Sep 17 00:00:00 2001
+From 10b08af6c7dcb03f954da29b6c4f9636b8796f30 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Fri, 15 Feb 2019 11:17:27 +0100
 Subject: [PATCH] Do not prefix executables with $bindir in pkg-config files
diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch 
b/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
index 129bc7f8aee..b9c9706fc46 100644
--- 
a/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
+++ 
b/meta/recipes-core/glib-2.0/files/0001-Fix-DATADIRNAME-on-uclibc-Linux.patch
@@ -1,4 +1,4 @@
-From ccb25e8c0bab54eac8ba0e9d7083ce81461ab72a Mon Sep 17 00:00:00 2001
+From 55c49c51d8db5af15132653003d2b65a5215eebf Mon Sep 17 00:00:00 2001
 From: Khem Raj 
 Date: Sat, 15 Mar 2014 22:42:29 -0700
 Subject: [PATCH] Fix DATADIRNAME on uclibc/Linux
diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
 
b/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
index 3e12f8abbeb..bc539fe3e88 100644
--- 
a/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
+++ 
b/meta/recipes-core/glib-2.0/files/0001-Install-gio-querymodules-as-libexec_PROGRAM.patch
@@ -1,4 +1,4 @@
-From caab40411d8520dae77a4b7933ebaffbb00559fe Mon Sep 17 00:00:00 2001
+From 5cf3ec787cb7e60585237327390e2ca89f4c Mon Sep 17 00:00:00 2001
 From: Jussi Kukkonen 
 Date: Tue, 22 Mar 2016 15:14:58 +0200
 Subject: [PATCH] Install gio-querymodules as libexec_PROGRAM
diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
 
b/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
index 9b0b83afa44..5e543339d8c 100644
--- 
a/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
+++ 
b/meta/recipes-core/glib-2.0/files/0001-Remove-the-warning-about-deprecated-paths-in-schemas.patch
@@ -1,4 +1,4 @@
-From 65c036b1ede453e89893076f4ece21c946505096 Mon Sep 17 00:00:00 2001
+From 3db055ce8029372096be534c5cfc385f068bab17 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Fri, 12 Jun 2015 17:08:46 +0300
 Subject: [PATCH] Remove the warning about deprecated paths in schemas
diff --git 
a/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
 
b/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
index a2f9dd9672f..7ac03aa6ac7 100644
--- 
a/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
+++ 
b/meta/recipes-core/glib-2.0/files/0001-Set-host_machine-correctly-when-building-with-mingw3.patch
@@ -1,4 +1,4 @@
-From 01810df82fae752428d3756c85edb2eb7bbf3c15 Mon Sep 17 00:00:00 2001
+From 3f85d7dfb25666aef43dd6d58b4151e523f83693 Mon Sep 17 00:00:00 2001
 From: Alexander Kanavin 
 Date: Wed, 13 Feb 2019 15:32:05 +0100
 Subject: [PATCH] Set host_machine correctly when building with mingw32
@@ -12,7 +12,7 @@ Signed-off-by: Alexander Kanavin 
  3 files changed, 8 insertions(+), 5 deletions(-)
 
 diff --git a/gio/tests/meson.build b/gio/tests/meson.build
-index 232ecca..563298b 100644
+index 3bfb333..60e3d3d 100644
 --- 

[OE-core] [PATCH 2/4] stress-ng: upgrade 0.17.07 -> 0.17.08

2024-05-16 Thread Anuj Mittal
Signed-off-by: Anuj Mittal 
---
 .../stress-ng/{stress-ng_0.17.07.bb => stress-ng_0.17.08.bb}| 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)
 rename meta/recipes-extended/stress-ng/{stress-ng_0.17.07.bb => 
stress-ng_0.17.08.bb} (94%)

diff --git a/meta/recipes-extended/stress-ng/stress-ng_0.17.07.bb 
b/meta/recipes-extended/stress-ng/stress-ng_0.17.08.bb
similarity index 94%
rename from meta/recipes-extended/stress-ng/stress-ng_0.17.07.bb
rename to meta/recipes-extended/stress-ng/stress-ng_0.17.08.bb
index fb88e06a7f5..fffe6a1823b 100644
--- a/meta/recipes-extended/stress-ng/stress-ng_0.17.07.bb
+++ b/meta/recipes-extended/stress-ng/stress-ng_0.17.08.bb
@@ -7,7 +7,7 @@ LIC_FILES_CHKSUM = 
"file://COPYING;md5=b234ee4d69f5fce4486a80fdaf4a4263"
 
 SRC_URI = 
"git://github.com/ColinIanKing/stress-ng.git;protocol=https;branch=master \
"
-SRCREV = "519151f460738cd62b69b84f8096cd218131e0a2"
+SRCREV = "b7c7a5877501679a3b0a67d877e6274a801d1e4e"
 S = "${WORKDIR}/git"
 
 DEPENDS = "coreutils-native libbsd"
-- 
2.45.0


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



Re: [OE-core] [PATCH 05/10] base: Switch UNPACKDIR to a subdir of WORKDIR

2024-05-16 Thread Richard Purdie
On Wed, 2024-05-15 at 17:42 +, Peter Kjellerstedt wrote:
> 
> > diff --git a/meta/classes-global/base.bbclass b/meta/classes-
> > global/base.bbclass
> > index 066f3848f7c..cdce0538273 100644
> > --- a/meta/classes-global/base.bbclass
> > +++ b/meta/classes-global/base.bbclass
> > @@ -153,20 +153,35 @@ python base_do_fetch() {
> >  }
> > 
> >  addtask unpack after do_fetch
> > -do_unpack[dirs] = "${UNPACKDIR}"
> > -
> > -do_unpack[cleandirs] = "${@d.getVar('S') if
> > os.path.normpath(d.getVar('S')) !=
> > os.path.normpath(d.getVar('WORKDIR')) else os.path.join('${S}',
> > 'patches')}"
> > +do_unpack[cleandirs] = "${UNPACKDIR}"
> > 
> >  python base_do_unpack() {
> > +    import shutil
> > +
> >  src_uri = (d.getVar('SRC_URI') or "").split()
> >  if not src_uri:
> >  return
> > 
> > +    sourcedir = d.getVar('S')
> > +    basedir = None
> > +    workdir = d.getVar('WORKDIR')
> > +    unpackdir = d.getVar('UNPACKDIR')
> > +    if sourcedir.startswith(workdir) and not
> > sourcedir.startswith(unpackdir):
> > +    basedir = sourcedir.replace(workdir,
> > '').strip("/").split('/')[0]
> > +    bb.utils.remove(sourcedir, True)
> 
> This remove() seems wrong and should not be needed. There are two 
> cases here:
> 
> 1) either ${S} == ${WORKDIR}, in which case the above will remove 
>    ${WORKDIR}, which is sure to lead to problems, or
> 2) ${S} == ${WORKDIR}/foo[/...], in which case the removal of 
>    workdir + '/' + basedir below will also remove ${S} as 
>    basedir == "foo".
> 
> 

I did look into that remove() further and tried to make the removal
unconditional. The challenge is that if S = UNPACKDIR, it will rmdir
the directory and the code assumes UNPACKDIR to be created from the
cleandirs. We don't want an empty S created though for the S !=
UNPACKDIR case.

Making it conditional on sourcedir != unpackdir which was the original
condition for that code block but that does still cause QA warnings for
linux-yocto. I'm now convinced linux-yocto needs more work so I'm
tempted to disable that QA check there for now, letting us improve
base.bbclass.

Cheers,

Richard, running out of patience with hours long test cycles

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199453): 
https://lists.openembedded.org/g/openembedded-core/message/199453
Mute This Topic: https://lists.openembedded.org/mt/106112374/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] [AUH] python3-pyproject-hooks: upgrading to 1.1.0 FAILED

2024-05-16 Thread Ross Burton
The regression of LICENSE being missing from the sdist is relatively minor (but 
will be fixed in 1.2, there’s a queued MR), but this release has behavioural 
changes which is breaking setuptools/poetry, so I suggest nobody else try to do 
the upgrade until 1.2 is released.

Ross

On 15 May 2024, at 18:32, a...@yoctoproject.org wrote:
> 
> Hello,
> 
> this email is a notification from the Auto Upgrade Helper
> that the automatic attempt to upgrade the recipe *python3-pyproject-hooks* to 
> *1.1.0* has Failed (devtool error).
> 
> Detailed error information:
> 
> The following devtool command failed:  upgrade python3-pyproject-hooks -V 
> 1.1.0
> NOTE: Reconnecting to bitbake server...
> Loading cache...done.
> Loaded 1879 entries from dependency cache.
> Removing 1 recipes from the x86_64 sysroot...done.
> NOTE: Resolving any missing task queue dependencies
> 
> Build Configuration:
> BB_VERSION   = "2.9.1"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "qemux86-64"
> DISTRO   = "poky"
> DISTRO_VERSION   = "5.0+snapshot-b3e1284f77bbeffe62badc80d80f60c14786909d"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta 
> meta-poky
> meta-yocto-bsp   
> workspace= 
> "tmp-auh-upgrades:b3e1284f77bbeffe62badc80d80f60c14786909d"
> 
> Initialising tasks...NOTE: The /proc/pressure files can't be read. Continuing 
> build without monitoring pressure
> Sstate summary: Wanted 10 Local 10 Mirrors 0 Missed 0 Current 20 (100% match, 
> 100% complete)
> done.
> NOTE: Executing Tasks
> NOTE: Tasks Summary: Attempted 103 tasks of which 100 didn't need to be rerun 
> and all succeeded.
> NOTE: Writing buildhistory
> NOTE: Writing buildhistory took: 3 seconds
> Loading cache...done.
> Loaded 1879 entries from dependency cache.
> Parsing recipes...done.
> Parsing of 922 .bb files complete (920 cached, 2 parsed). 1880 targets, 35 
> skipped, 0 masked, 0 errors.
> NOTE: Resolving any missing task queue dependencies
> 
> Build Configuration:
> BB_VERSION   = "2.9.1"
> BUILD_SYS= "x86_64-linux"
> NATIVELSBSTRING  = "universal"
> TARGET_SYS   = "x86_64-poky-linux"
> MACHINE  = "qemux86-64"
> DISTRO   = "poky"
> DISTRO_VERSION   = "5.0+snapshot-b3e1284f77bbeffe62badc80d80f60c14786909d"
> TUNE_FEATURES= "m64 core2"
> TARGET_FPU   = ""
> meta 
> meta-poky
> meta-yocto-bsp   
> workspace= 
> "tmp-auh-upgrades:b3e1284f77bbeffe62badc80d80f60c14786909d"
> 
> Initialising tasks...NOTE: The /proc/pressure files can't be read. Continuing 
> build without monitoring pressure
> Sstate summary: Wanted 1 Local 0 Mirrors 0 Missed 1 Current 0 (0% match, 0% 
> complete)
> done.
> NOTE: Executing Tasks
> NOTE: Tasks Summary: Attempted 3 tasks of which 0 didn't need to be rerun and 
> all succeeded.
> NOTE: Writing buildhistory
> NOTE: Writing buildhistory took: 3 seconds
> DEBUG 5 [Errno 25] Inappropriate ioctl for device
> Adding changed files:   0% |   | ETA:  
> --:--:--
> Adding changed files:   0% |   | ETA:  
> --:--:--
> Adding changed files: 100% || Time: 
> 0:00:00
> 
> INFO: Extracting current version source...
> INFO: Extracting upgraded version source...
> INFO: Fetching 
> https://files.pythonhosted.org/packages/source/p/pyproject_hooks/pyproject_hooks-1.1.0.tar.gz;downloadfilename=pyproject_hooks-1.1.0.tar.gz...
> INFO: Rebasing devtool onto f4075f45a824c1e36c12355627b143dbe10d0c38
> Traceback (most recent call last):
>  File "/home/pokybuild/yocto-worker/auh/build/scripts/devtool", line 350, in 
> 
>ret = main()
>  ^^
>  File "/home/pokybuild/yocto-worker/auh/build/scripts/devtool", line 337, in 
> main
>ret = args.func(args, config, basepath, workspace)
>  
>  File 
> "/home/pokybuild/yocto-worker/auh/build/scripts/lib/devtool/upgrade.py", line 
> 600, in upgrade
>new_licenses = _extract_licenses(srctree_s, (rd.getVar('LIC_FILES_CHKSUM') 
> or ""))
>   
> ^^^
>  File 
> "/home/pokybuild/yocto-worker/auh/build/scripts/lib/devtool/upgrade.py", line 
> 508, in _extract_licenses
>with open(os.path.join(srcpath, path), 'rb') as f:
> ^^^
> FileNotFoundError: [Errno 2] No such file or directory: 
> '/home/pokybuild/yocto-worker/auh/build/build/workspace/sources/python3-pyproject-hooks/LICENSE'
> 
> 
> Please review the attached files for further information and build/update 
> failures.
> Any problem please file a bug at 
> https://bugzilla.yoctoproject.org/enter_bug.cgi?product=Automated%20Update%20Handler
> 
> Regards,
> The Upgrade Helper


Re: [OE-core] Debugging rust oe-selftest failures

2024-05-16 Thread Alexander Kanavin
On Thu, 16 May 2024 at 12:15, Richard Purdie  wrote:
> There is an extra consideration to this unfortunately which is
> scarthgap. For better or worse we have an LTS release with a mostly
> working test suite and this arm/x86 issue is present.
>
> Should I take the patches to master, the next instant request will be a
> backport to scarthgap.
>
> That gives me pause for thought on what to do here...

I suppose we could give people who understand the test suite time to
unbreak it, before updating rust version. Then both the AB fixes and
test suite fixes could be backported. I'm going to send the ab fxes
today, just writing the upstream report now.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199451): 
https://lists.openembedded.org/g/openembedded-core/message/199451
Mute This Topic: https://lists.openembedded.org/mt/105307188/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] go: upgrade 1.22.2 -> 1.22.3

2024-05-16 Thread Jose Quaresma
Upgrade to latest 1.22.x release [1]:

$ git --no-pager log --oneline go1.22.2..go1.22.3
adbfb672ba (tag: go1.22.3) [release-branch.go1.22] go1.22.3
fa0292d252 [release-branch.go1.22] cmd/go: disallow -lto_library in LDFLAGS
947e43e371 [release-branch.go1.22] Revert "cmd/compile: don't combine loads in 
generated equality functions"
9d2e28501c [release-branch.go1.22] cmd/compile: don't combine loads in 
generated equality functions
93d8777d24 [release-branch.go1.22] net: check SkipAdditional error result
3f4af1ff0e [release-branch.go1.22] runtime: use bootstrapRand to initialize 
hashkey
a7ff78d585 [release-branch.go1.22] cmd/compile: bail PGO method lookup on 
interface types
12c1177045 [release-branch.go1.22] cmd/internal/obj/ppc64: fix incorrect int to 
int64 conversion when checking MOVD opcodes
d6c972ad41 [release-branch.go1.22] net/http: update bundled 
golang.org/x/net/http2
a65a2bbd8e [release-branch.go1.22] all: tidy dependency versioning after release

[1] https://github.com/golang/go/compare/go1.22.2...go1.22.3

Signed-off-by: Jose Quaresma 
---
 meta/recipes-devtools/go/{go-1.22.2.inc => go-1.22.3.inc}   | 2 +-
 ...o-binary-native_1.22.2.bb => go-binary-native_1.22.3.bb} | 6 +++---
 ...cross-canadian_1.22.2.bb => go-cross-canadian_1.22.3.bb} | 0
 .../go/{go-cross_1.22.2.bb => go-cross_1.22.3.bb}   | 0
 .../go/{go-crosssdk_1.22.2.bb => go-crosssdk_1.22.3.bb} | 0
 .../go/{go-native_1.22.2.bb => go-native_1.22.3.bb} | 0
 .../go/{go-runtime_1.22.2.bb => go-runtime_1.22.3.bb}   | 0
 meta/recipes-devtools/go/{go_1.22.2.bb => go_1.22.3.bb} | 0
 8 files changed, 4 insertions(+), 4 deletions(-)
 rename meta/recipes-devtools/go/{go-1.22.2.inc => go-1.22.3.inc} (89%)
 rename meta/recipes-devtools/go/{go-binary-native_1.22.2.bb => 
go-binary-native_1.22.3.bb} (78%)
 rename meta/recipes-devtools/go/{go-cross-canadian_1.22.2.bb => 
go-cross-canadian_1.22.3.bb} (100%)
 rename meta/recipes-devtools/go/{go-cross_1.22.2.bb => go-cross_1.22.3.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-crosssdk_1.22.2.bb => 
go-crosssdk_1.22.3.bb} (100%)
 rename meta/recipes-devtools/go/{go-native_1.22.2.bb => go-native_1.22.3.bb} 
(100%)
 rename meta/recipes-devtools/go/{go-runtime_1.22.2.bb => go-runtime_1.22.3.bb} 
(100%)
 rename meta/recipes-devtools/go/{go_1.22.2.bb => go_1.22.3.bb} (100%)

diff --git a/meta/recipes-devtools/go/go-1.22.2.inc 
b/meta/recipes-devtools/go/go-1.22.3.inc
similarity index 89%
rename from meta/recipes-devtools/go/go-1.22.2.inc
rename to meta/recipes-devtools/go/go-1.22.3.inc
index b399207311..34703bc1fa 100644
--- a/meta/recipes-devtools/go/go-1.22.2.inc
+++ b/meta/recipes-devtools/go/go-1.22.3.inc
@@ -15,4 +15,4 @@ SRC_URI += "\
 file://0008-src-cmd-dist-buildgo.go-do-not-hardcode-host-compile.patch \
 file://0009-go-Filter-build-paths-on-staticly-linked-arches.patch \
 "
-SRC_URI[main.sha256sum] = 
"374ea82b289ec738e968267cac59c7d5ff180f9492250254784b2044e90df5a9"
+SRC_URI[main.sha256sum] = 
"80648ef34f903193d72a59c0dff019f5f98ae0c9aa13ade0b0ecbff991a76f68"
diff --git a/meta/recipes-devtools/go/go-binary-native_1.22.2.bb 
b/meta/recipes-devtools/go/go-binary-native_1.22.3.bb
similarity index 78%
rename from meta/recipes-devtools/go/go-binary-native_1.22.2.bb
rename to meta/recipes-devtools/go/go-binary-native_1.22.3.bb
index 0f00509f03..b67d97608d 100644
--- a/meta/recipes-devtools/go/go-binary-native_1.22.2.bb
+++ b/meta/recipes-devtools/go/go-binary-native_1.22.3.bb
@@ -9,9 +9,9 @@ PROVIDES = "go-native"
 
 # Checksums available at https://go.dev/dl/
 SRC_URI = 
"https://dl.google.com/go/go${PV}.${BUILD_GOOS}-${BUILD_GOARCH}.tar.gz;name=go_${BUILD_GOTUPLE};
-SRC_URI[go_linux_amd64.sha256sum] = 
"5901c52b7a78002aeff14a21f93e0f064f74ce1360fce51c6ee68cd471216a17"
-SRC_URI[go_linux_arm64.sha256sum] = 
"36e720b2d564980c162a48c7e97da2e407dfcc4239e1e58d98082dfa2486a0c1"
-SRC_URI[go_linux_ppc64le.sha256sum] = 
"251a8886c5113be6490bdbb955ddee98763b49c9b1bf4c8364c02d3b482dab00"
+SRC_URI[go_linux_amd64.sha256sum] = 
"8920ea521bad8f6b7bc377b4824982e011c19af27df88a815e3586ea895f1b36"
+SRC_URI[go_linux_arm64.sha256sum] = 
"6c33e52a5b26e7aa021b94475587fce80043a727a54ceb0eee2f9fc160646434"
+SRC_URI[go_linux_ppc64le.sha256sum] = 
"04b7b05283de30dd2da20bf3114b2e22cc727938aed3148babaf35cc951051ac"
 
 UPSTREAM_CHECK_URI = "https://golang.org/dl/;
 UPSTREAM_CHECK_REGEX = "go(?P\d+(\.\d+)+)\.linux"
diff --git a/meta/recipes-devtools/go/go-cross-canadian_1.22.2.bb 
b/meta/recipes-devtools/go/go-cross-canadian_1.22.3.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross-canadian_1.22.2.bb
rename to meta/recipes-devtools/go/go-cross-canadian_1.22.3.bb
diff --git a/meta/recipes-devtools/go/go-cross_1.22.2.bb 
b/meta/recipes-devtools/go/go-cross_1.22.3.bb
similarity index 100%
rename from meta/recipes-devtools/go/go-cross_1.22.2.bb
rename to meta/recipes-devtools/go/go-cross_1.22.3.bb
diff --git a/meta/recipes-devtools/go/go-crosssdk_1.22.2.bb 

Re: [OE-core] Debugging rust oe-selftest failures

2024-05-16 Thread Richard Purdie
On Thu, 2024-05-16 at 11:19 +0200, Alexander Kanavin via
lists.openembedded.org wrote:
> As explained elsewhere, rust selftest is going to be disabled to
> resolve sporadic autobuilder failures. This also gives everyone a
> chance to update rust to latest upstream release without having to
> fight with the selftest.

There is an extra consideration to this unfortunately which is
scarthgap. For better or worse we have an LTS release with a mostly
working test suite and this arm/x86 issue is present.

Should I take the patches to master, the next instant request will be a
backport to scarthgap.

That gives me pause for thought on what to do here...

Cheers,

Richard

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



Re: [yocto] QA notification for completed autobuilder build (yocto-5.0.1.rc2)

2024-05-16 Thread Jing Hui Tham
Hi All,
 
QA for yocto-5.0.1.rc2 is completed. This is the full report for this release:  
https://git.yoctoproject.org/cgit/cgit.cgi/yocto-testresults-contrib/tree/?h=intel-yocto-testresults
 
=== Summary 
No high milestone defects.
 
No new issue found. 
 
Thanks,
Jing Hui


> -Original Message-
> From: yo...@lists.yoctoproject.org  On Behalf
> Of Pokybuild User
> Sent: Friday, May 10, 2024 1:45 PM
> To: yo...@lists.yoctoproject.org
> Cc: qa-build-notificat...@lists.yoctoproject.org
> Subject: [yocto] QA notification for completed autobuilder build (yocto-
> 5.0.1.rc2)
> 
> 
> A build flagged for QA (yocto-5.0.1.rc2) was completed on the autobuilder
> and is available at:
> 
> 
> https://autobuilder.yocto.io/pub/releases/yocto-5.0.1.rc2
> 
> 
> Build URL:
> https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6892
> 
> Build hash information:
> 
> bitbake: 8f90d10f9efc9a32e13f6bd031992aece79fe7cc
> meta-agl: 73b088ccfa385f91b8aa56c1d2fbf78d97447dfa
> meta-arm: 6d6fa14744b4e453eedb2c37891259b7dcbf
> meta-aws: 3265343c2f2b22bd0a2a9a688fd20e6540d0d746
> meta-clang: e7dceb1c92caf7f21ef1d7b49c85328c30cffd90
> meta-intel: 52f5037453e797eca8784a410f7a2a55f40aef57
> meta-mingw: acbba477893ef87388effc4679b7f40ee49fc852
> meta-openembedded: 5778e32eae201072c5dc37c9db67dc1848ffb9de
> meta-virtualization: e9bb0a338fdf637f7929e19b21857d4c1d532ce6
> oecore: 294a7dbe44f6b7c8d3a1de8c2cc182af37c4f916
> poky: 4b07a5316ed4b858863dfdb7cab63859d46d1810
> 
> 
> 
> This is an automated message from the Yocto Project Autobuilder
> Git: git://git.yoctoproject.org/yocto-autobuilder2
> Email: richard.pur...@linuxfoundation.org
> 
> 
> 

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



Re: [OE-core] Debugging rust oe-selftest failures

2024-05-16 Thread Alexander Kanavin
As explained elsewhere, rust selftest is going to be disabled to
resolve sporadic autobuilder failures. This also gives everyone a
chance to update rust to latest upstream release without having to
fight with the selftest.

Before selftest is re-enabled, I would ask for the following improvements:

- when it fails, the output is huge, and easily exceeds the terminal
buffer. It's difficult to look through it for possible failures, and
impossible to tell if some failures have scrolled off the buffer. Is
it written to a file somewhere? How do the fails look like? The test
should make both of these points clear. Can we reduce verbosity by
default? No one needs to see a complete list of everything that passed
when just a few items fail.

- the test takes 20 minutes to execute. When debugging it you can't
possibly ask for that much time for developers for every test
execution. There should be a way to re-run just the item that failed
from command line in a preserved build-st directory, and that should
be documented and printed on failure.

Thanks,
Alex

On Tue, 14 May 2024 at 17:52, Randy MacLeod via lists.openembedded.org
 wrote:
>
> On 2024-04-05 7:28 a.m., Alex Kiernan via lists.openembedded.org wrote:
>
> On Thu, Apr 4, 2024 at 10:07 AM Yash Shinde via lists.openembedded.org
>  wrote:
>
> On Wed, Apr 3, 2024 at 05:51 PM, Alex Kiernan wrote:
>
> Hi Sundeep (or anyone else with insight on this!)
>
> How do you go about debugging rust oe-selftest failures? I've bumped
> everything up to 1.77 (https://github.com/akiernan/poky) but
> oe-selftest fails for reasons that aren't immediately obvious to me...
>
> https://gist.github.com/akiernan/6cc6131c1ec3af866098a9318679cf1b
>
> Any clues?
>
> --
> Alex Kiernan
>
>
>
>
> Hi Alex,
>
> I faced the same errors when I was working on to upgrade rust from 1.75 to 
> 1.76. I discussed it with rust upstream here, 
> https://github.com/rust-lang/rust/issues/122075 and the following change 
> solves those failures,
>
> https://github.com/rust-lang/rust/issues/122075#issuecomment-1985153524
>
> PR- 
> https://github.com/rust-lang/rust/pull/122205/commits/5aece7fad06baaa745784d118db862b3e3ccf7f8
>
>
>
>
>
> After this change was backported to poky, the rust build was successful but 
> it was seen that not all the tests are executed.
>
> While discussing upstream, it was known that removing the --doc option from 
> python3 src/bootstrap/bootstrap.py test --exclude list> --doc --no-fail-fast --bless --target x86_64-poky-linux-gnu  cmd in 
> oeqa/selftest/cases/rust.py file execute the other tests also.
>
>
>
>
>
> But, while doing so another set of failures are observed as mentioned in 
> https://github.com/rust-lang/rust/issues/122285
>
> Complete log using --doc option-  
> https://gist.github.com/Yashinde145/7db6bd4a064021bf756b0c0dd6c8777c
>
> Complete log without using --doc option-  
> https://gist.github.com/Yashinde145/036a934f0523307859f7c855b83ecfd6 (this 
> file is truncated in gist due to large size, please see Complete raw file)
>
> I am not very familiar to these failures but  trying to understand them.
>
> Feels like you're way ahead of me. I'll have a bit more of a poke at
> it when I've some time, but it feels like we may be mostly waiting on
> upstream (and a big +1 for getting them engaged!)
>
> FYI,
>
> Sundeep and Yashe have Rust 1.77 (8?) compiling reproducibly.
> They found some problems with the rust test suite and
> are working on fixing or avoiding those errors before submitting a patch.
>
>
> ../Randy
>
>
>
>
>
>
>
> --
> # Randy MacLeod
> # Wind River Linux
>
>
> 
>

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



Re: [OE-core] [PATCH v4] ipk/rootfs: run sanity test of multilib in parallel

2024-05-16 Thread Alexander Kanavin
The code adds significant complexity, and the patch is difficult to
understand. The commit message should explain what the temporary
installation does, and why is needed. What does 'sanity test' do, and
how is it parallelized? Is it a part of that 'temporary installation'?
How is 'Installing package groups through opkg takes much more time
than copying directory.' relevant to all of that?

Also, if it does improve performance, can you please provide some
numbers for that, based on poky?

Alex

On Thu, 16 May 2024 at 02:12, Seungkyun Kim via lists.openembedded.org
 wrote:
>
> From: "seungkyun.kim" 
>
> For multilib type packages, there is an additional temporary
> installation before the actual installation. It makes almost doubles
> the do_rootfs time if having many multilib type packages.
> To avoid this overhead, run sanity test in parallel.
> Installing package groups through opkg takes much more time than
> copying directory.
>
> - Changes in V2:
> Fix FileNotFoundError exception when copying rootfs
> - Changes in V3:
> Removed unnecessary test call
> - Changes in V4:
> Fix invalid argument when create Process
> Keep the temporary rootfs directory after sanity check
>
> Signed-off-by: seungkyun.kim 
> ---
>  meta/lib/oe/package_manager/ipk/rootfs.py | 34 +--
>  1 file changed, 32 insertions(+), 2 deletions(-)
>
> diff --git a/meta/lib/oe/package_manager/ipk/rootfs.py 
> b/meta/lib/oe/package_manager/ipk/rootfs.py
> index ba93eb62ea..a3842a6264 100644
> --- a/meta/lib/oe/package_manager/ipk/rootfs.py
> +++ b/meta/lib/oe/package_manager/ipk/rootfs.py
> @@ -6,7 +6,9 @@
>
>  import re
>  import filecmp
> +import multiprocessing
>  import shutil
> +import stat
>  from oe.rootfs import Rootfs
>  from oe.manifest import Manifest
>  from oe.utils import execute_pre_post_process
> @@ -197,11 +199,34 @@ class PkgRootfs(DpkgOpkgRootfs):
>  files[key] = item
>
>  def _multilib_test_install(self, pkgs):
> +def _copy_rootfs(src, dst):
> +if os.path.islink(src):
> +linkto = os.readlink(src)
> +if os.path.isabs(linkto):
> +linkto = 
> os.path.normpath(os.path.join(os.path.dirname(dst),
> +   
> os.path.relpath(linkto, src)))
> +os.symlink(linkto, dst)
> +elif os.path.isfile(src):
> +shutil.copy2(src, dst)
> +elif stat.S_ISFIFO(os.stat(src).st_mode):
> +os.mkfifo(dst)
> +else:
> +bb.warn("Skip unsupported file type: %s" % src)
> +
>  ml_temp = self.d.getVar("MULTILIB_TEMP_ROOTFS")
> +rootfs_temp = os.path.join(ml_temp, "rootfs")
>  bb.utils.mkdirhier(ml_temp)
> +bb.utils.remove(rootfs_temp, True)
>
> -dirs = [self.image_rootfs]
> +if os.path.exists(self.image_rootfs):
> +shutil.copytree(self.image_rootfs, rootfs_temp, 
> copy_function=_copy_rootfs)
> +else:
> +bb.utils.mkdirhier(rootfs_temp)
> +dirs = [rootfs_temp]
> +return 
> multiprocessing.Process(target=self._multilib_test_pkg_install,
> +   args=(pkgs, ml_temp, dirs,))
>
> +def _multilib_test_pkg_install(self, pkgs, ml_temp, dirs):
>  for variant in self.d.getVar("MULTILIB_VARIANTS").split():
>  ml_target_rootfs = os.path.join(ml_temp, variant)
>
> @@ -300,15 +325,20 @@ class PkgRootfs(DpkgOpkgRootfs):
>
>  for pkg_type in self.install_order:
>  if pkg_type in pkgs_to_install:
> +sanity_test = None
>  # For multilib, we perform a sanity test before final install
>  # If sanity test fails, it will automatically do a bb.fatal()
>  # and the installation will stop
>  if pkg_type == Manifest.PKG_TYPE_MULTILIB:
> -self._multilib_test_install(pkgs_to_install[pkg_type])
> +sanity_test= 
> self._multilib_test_install(pkgs_to_install[pkg_type])
> +sanity_test.start()
>
>  self.pm.install(pkgs_to_install[pkg_type],
>  [False, True][pkg_type == 
> Manifest.PKG_TYPE_ATTEMPT_ONLY])
>
> +if sanity_test is not None:
> +sanity_test.join()
> +
>  if self.progress_reporter:
>  self.progress_reporter.next_stage()
>
> --
> 2.34.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199446): 
https://lists.openembedded.org/g/openembedded-core/message/199446
Mute This Topic: https://lists.openembedded.org/mt/106125799/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] git: set --with-gitconfig=/etc/gitconfig for -native builds

2024-05-16 Thread Rasmus Villemoes via lists.openembedded.org
Polite ping.

On 23/04/2024 11.57, Rasmus Villemoes via lists.openembedded.org wrote:
> From: Rasmus Villemoes 
> 
> Commit 6c2ae2346db0 (kern-tools: depend on git-replacement-native)
> broke our kernel builds. For saving space and time, we have a DL_DIR
> shared between multiple users/buildbots, not all of which run with the
> same uid (and with appropriate sticky bits set so that files
> downloaded by one user become owned by a common group and are readable
> by others). This works fine also for git sources because the docker
> images we use all have a /etc/gitconfig with
> 
>   [safe]
> directory = *
> 
> But with the mentioned commit, the host's git is no longer used for
> do_unpack (nor for do_fetch if re-building and sysroot has already
> been populated by a previous build), causing spurious "fatal: detected
> dubious ownership..." failures.
> 
> Currently, the path where the git-native binary searches for system
> gitconfig is the sysroot from it was built, which obviously doesn't
> contain a /etc/gitconfig. As for the nativesdk variant, respect the
> host's /etc/gitconfig if present.
> 
> Signed-off-by: Rasmus Villemoes 
> ---
>  meta/recipes-devtools/git/git_2.44.0.bb | 1 +
>  1 file changed, 1 insertion(+)
> 
> diff --git a/meta/recipes-devtools/git/git_2.44.0.bb 
> b/meta/recipes-devtools/git/git_2.44.0.bb
> index 90e555eba7..78b00dd19f 100644
> --- a/meta/recipes-devtools/git/git_2.44.0.bb
> +++ b/meta/recipes-devtools/git/git_2.44.0.bb
> @@ -40,6 +40,7 @@ EXTRA_OECONF = 
> "--with-perl=${STAGING_BINDIR_NATIVE}/perl-native/perl \
>   --without-iconv \
>  "
>  EXTRA_OECONF:append:class-nativesdk = " --with-gitconfig=/etc/gitconfig "
> +EXTRA_OECONF:append:class-native = " --with-gitconfig=/etc/gitconfig "
>  
>  # Needs brokensep as this doesn't use automake
>  inherit autotools-brokensep perlnative bash-completion manpages
> 
> 
> 
> 
> 


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



Re: [OE-core] [PATCH 05/10] base: Switch UNPACKDIR to a subdir of WORKDIR

2024-05-16 Thread Richard Purdie
On Thu, 2024-05-16 at 09:18 +0200, Martin Hundebøll wrote:
> On Wed, 2024-05-15 at 12:56 +0100, Richard Purdie wrote:
> > diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> > index b2c500d8739..75c850760f6 100644
> > --- a/meta/conf/bitbake.conf
> > +++ b/meta/conf/bitbake.conf
> > @@ -405,7 +405,7 @@ STAMP =
> > "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${PV}"
> >  STAMPCLEAN = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/*-*"
> >  BASE_WORKDIR ?= "${TMPDIR}/work"
> >  WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${PV}"
> > -UNPACKDIR ??= "${WORKDIR}"
> > +UNPACKDIR ??= "${WORKDIR}/sources-unpack"
> >  T = "${WORKDIR}/temp"
> >  D = "${WORKDIR}/image"
> >  S = "${WORKDIR}/${BP}"
> 
> Why not use
> 
>   UNPACKDIR ??= "${WORKDIR}/sources"
> 
> like it's done in the individual recipes?

I think it is helpful for users to be able to tell the difference
between a recipe where S is a subdirectory of this and when there is no
subdirectory. I therefore left them visually different.

> And shouldn't we do 
> 
>   S = ?? "${UNPACKDIR}/${BP}"
> 
> also?

See my other emails. I'm torn on changing this. I've been hoping we
could avoid extra directory levels, the extra pain of changing S
everywhere and there is also some benefit to keeping extra unpacked
files clearly separate from the other sources. We may end up doing it,
I don't know.

Cheers,

Richard


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199444): 
https://lists.openembedded.org/g/openembedded-core/message/199444
Mute This Topic: https://lists.openembedded.org/mt/106112374/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] package_manager: Share more common DEB / IPK code

2024-05-16 Thread Philip Lorenz
Avoid code duplication by making `extract` a shared method (and
retrieving the package manager specific input via an abstract method).
Additionally, follow Python conventions and prefix class internal
methods with "_" to indicate that they shouldn't be called externally.

Signed-off-by: Philip Lorenz 
---
 meta/lib/oe/package_manager/common_deb_ipk.py | 16 
 meta/lib/oe/package_manager/deb/__init__.py   | 19 ++-
 meta/lib/oe/package_manager/ipk/__init__.py   | 15 +--
 3 files changed, 15 insertions(+), 35 deletions(-)

diff --git a/meta/lib/oe/package_manager/common_deb_ipk.py 
b/meta/lib/oe/package_manager/common_deb_ipk.py
index c91a4b45650..6a1e28ee6f9 100644
--- a/meta/lib/oe/package_manager/common_deb_ipk.py
+++ b/meta/lib/oe/package_manager/common_deb_ipk.py
@@ -20,9 +20,15 @@ class OpkgDpkgPM(PackageManager):
 """
 super(OpkgDpkgPM, self).__init__(d, target_rootfs)
 
-def package_info(self, pkg, cmd):
+def package_info(self, pkg):
 """
 Returns a dictionary with the package info.
+"""
+raise NotImplementedError
+
+def _common_package_info(self, cmd):
+"""
+   "Returns a dictionary with the package info.
 
 This method extracts the common parts for Opkg and Dpkg
 """
@@ -36,14 +42,16 @@ class OpkgDpkgPM(PackageManager):
 
 return opkg_query(proc.stdout)
 
-def extract(self, pkg, pkg_info):
+def extract(self, pkg):
 """
 Returns the path to a tmpdir where resides the contents of a package.
 
 Deleting the tmpdir is responsability of the caller.
-
-This method extracts the common parts for Opkg and Dpkg
 """
+pkg_info = self.package_info(pkg)
+if not pkg_info:
+bb.fatal("Unable to get information for package '%s' while "
+ "trying to extract the package."  % pkg)
 
 ar_cmd = bb.utils.which(os.getenv("PATH"), "ar")
 tar_cmd = bb.utils.which(os.getenv("PATH"), "tar")
diff --git a/meta/lib/oe/package_manager/deb/__init__.py 
b/meta/lib/oe/package_manager/deb/__init__.py
index a96e56b2ada..e09e81e4901 100644
--- a/meta/lib/oe/package_manager/deb/__init__.py
+++ b/meta/lib/oe/package_manager/deb/__init__.py
@@ -7,7 +7,7 @@
 import re
 import subprocess
 from oe.package_manager import *
-from oe.package_manager import OpkgDpkgPM
+from oe.package_manager.common_deb_ipk import OpkgDpkgPM
 
 class DpkgIndexer(Indexer):
 def _create_configs(self):
@@ -431,7 +431,7 @@ class DpkgPM(OpkgDpkgPM):
 Returns a dictionary with the package info.
 """
 cmd = "%s show %s" % (self.apt_cache_cmd, pkg)
-pkg_info = super(DpkgPM, self).package_info(pkg, cmd)
+pkg_info = self._common_package_info(cmd)
 
 pkg_arch = pkg_info[pkg]["pkgarch"]
 pkg_filename = pkg_info[pkg]["filename"]
@@ -439,18 +439,3 @@ class DpkgPM(OpkgDpkgPM):
 os.path.join(self.deploy_dir, pkg_arch, pkg_filename)
 
 return pkg_info
-
-def extract(self, pkg):
-"""
-Returns the path to a tmpdir where resides the contents of a package.
-
-Deleting the tmpdir is responsability of the caller.
-"""
-pkg_info = self.package_info(pkg)
-if not pkg_info:
-bb.fatal("Unable to get information for package '%s' while "
- "trying to extract the package."  % pkg)
-
-tmp_dir = super(DpkgPM, self).extract(pkg, pkg_info)
-
-return tmp_dir
diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py
index 23536294b0b..3d998e52ff1 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -416,7 +416,7 @@ class OpkgPM(OpkgDpkgPM):
 Returns a dictionary with the package info.
 """
 cmd = "%s %s info %s" % (self.opkg_cmd, self.opkg_args, pkg)
-pkg_info = super(OpkgPM, self).package_info(pkg, cmd)
+pkg_info = self._common_package_info(cmd)
 
 pkg_arch = pkg_info[pkg]["arch"]
 pkg_filename = pkg_info[pkg]["filename"]
@@ -424,16 +424,3 @@ class OpkgPM(OpkgDpkgPM):
 os.path.join(self.deploy_dir, pkg_arch, pkg_filename)
 
 return pkg_info
-
-def extract(self, pkg):
-"""
-Returns the path to a tmpdir where resides the contents of a package.
-
-Deleting the tmpdir is responsability of the caller.
-"""
-pkg_info = self.package_info(pkg)
-if not pkg_info:
-bb.fatal("Unable to get information for package '%s' while "
- "trying to extract the package."  % pkg)
-
-return super(OpkgPM, self).extract(pkg, pkg_info)
-- 
2.44.0


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

[OE-core] [PATCH 1/3] ipk: Fix clean up of extracted IPK payload

2024-05-16 Thread Philip Lorenz
It turns out that the IPK payload tarball was actually cleaned up in the
concrete package manager implementation (most likely because at some
point Debian and IPK packages used different compression algorithms).

Globbing removes this ambiguity so move the removal of the payload into
the common extract method.

Signed-off-by: Philip Lorenz 
---
 meta/lib/oe/package_manager/ipk/__init__.py | 6 ++
 1 file changed, 2 insertions(+), 4 deletions(-)

diff --git a/meta/lib/oe/package_manager/ipk/__init__.py 
b/meta/lib/oe/package_manager/ipk/__init__.py
index 0f0038d00d9..47e72cc7a65 100644
--- a/meta/lib/oe/package_manager/ipk/__init__.py
+++ b/meta/lib/oe/package_manager/ipk/__init__.py
@@ -159,6 +159,7 @@ class OpkgDpkgPM(PackageManager):
 bb.note("Extracted %s to %s" % (pkg_path, tmp_dir))
 bb.utils.remove(os.path.join(tmp_dir, "debian-binary"))
 bb.utils.remove(os.path.join(tmp_dir, "control.tar.gz"))
+bb.utils.remove(os.path.join(tmp_dir, data_tar))
 os.chdir(current_dir)
 
 return tmp_dir
@@ -511,7 +512,4 @@ class OpkgPM(OpkgDpkgPM):
 bb.fatal("Unable to get information for package '%s' while "
  "trying to extract the package."  % pkg)
 
-tmp_dir = super(OpkgPM, self).extract(pkg, pkg_info)
-bb.utils.remove(os.path.join(tmp_dir, "data.tar.zst"))
-
-return tmp_dir
+return super(OpkgPM, self).extract(pkg, pkg_info)
-- 
2.44.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#199442): 
https://lists.openembedded.org/g/openembedded-core/message/199442
Mute This Topic: https://lists.openembedded.org/mt/106130330/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] package_manager: Move OpkgDpkgPM into common module

2024-05-16 Thread Philip Lorenz
The OpkgDpkgPM class was introduced to share common functionality
between the Opkg and Debian package manager implementations. However,
for unknown reasons , the refactoring done in
5bc67f55028407de78ac09f97f9a47b165ae8760 duplicated the common class
into the deb and ipk modules. Undo this part of the change by moving the
common base class into a newly created module.

The two variants did not diverge a lot (next to the payload name
generalization, the Debian variant missed
17e2eaed036e1da8e7cb42cb3de51b9523ba54ec) and as such no regressions
should be expected.

Signed-off-by: Philip Lorenz 
---
 meta/lib/oe/package_manager/common_deb_ipk.py | 89 +++
 meta/lib/oe/package_manager/deb/__init__.py   | 68 +-
 meta/lib/oe/package_manager/ipk/__init__.py   | 78 +---
 3 files changed, 91 insertions(+), 144 deletions(-)
 create mode 100644 meta/lib/oe/package_manager/common_deb_ipk.py

diff --git a/meta/lib/oe/package_manager/common_deb_ipk.py 
b/meta/lib/oe/package_manager/common_deb_ipk.py
new file mode 100644
index 000..c91a4b45650
--- /dev/null
+++ b/meta/lib/oe/package_manager/common_deb_ipk.py
@@ -0,0 +1,89 @@
+#
+# Copyright OpenEmbedded Contributors
+#
+# SPDX-License-Identifier: GPL-2.0-only
+#
+
+import glob
+import os
+import subprocess
+import tempfile
+
+import bb
+
+from oe.package_manager import opkg_query, PackageManager
+
+class OpkgDpkgPM(PackageManager):
+def __init__(self, d, target_rootfs):
+"""
+This is an abstract class. Do not instantiate this directly.
+"""
+super(OpkgDpkgPM, self).__init__(d, target_rootfs)
+
+def package_info(self, pkg, cmd):
+"""
+Returns a dictionary with the package info.
+
+This method extracts the common parts for Opkg and Dpkg
+"""
+
+proc = subprocess.run(cmd, capture_output=True, encoding="utf-8", 
shell=True)
+if proc.returncode:
+bb.fatal("Unable to list available packages. Command '%s' "
+ "returned %d:\n%s" % (cmd, proc.returncode, proc.stderr))
+elif proc.stderr:
+bb.note("Command '%s' returned stderr: %s" % (cmd, proc.stderr))
+
+return opkg_query(proc.stdout)
+
+def extract(self, pkg, pkg_info):
+"""
+Returns the path to a tmpdir where resides the contents of a package.
+
+Deleting the tmpdir is responsability of the caller.
+
+This method extracts the common parts for Opkg and Dpkg
+"""
+
+ar_cmd = bb.utils.which(os.getenv("PATH"), "ar")
+tar_cmd = bb.utils.which(os.getenv("PATH"), "tar")
+pkg_path = pkg_info[pkg]["filepath"]
+
+if not os.path.isfile(pkg_path):
+bb.fatal("Unable to extract package for '%s'."
+ "File %s doesn't exists" % (pkg, pkg_path))
+
+tmp_dir = tempfile.mkdtemp()
+current_dir = os.getcwd()
+os.chdir(tmp_dir)
+
+try:
+cmd = [ar_cmd, 'x', pkg_path]
+output = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
+data_tar = glob.glob("data.tar.*")
+if len(data_tar) != 1:
+bb.fatal("Unable to extract %s package. Failed to identify "
+ "data tarball (found tarballs '%s').",
+ pkg_path, data_tar)
+data_tar = data_tar[0]
+cmd = [tar_cmd, 'xf', data_tar]
+output = subprocess.check_output(cmd, stderr=subprocess.STDOUT)
+except subprocess.CalledProcessError as e:
+bb.utils.remove(tmp_dir, recurse=True)
+bb.fatal("Unable to extract %s package. Command '%s' "
+ "returned %d:\n%s" % (pkg_path, ' '.join(cmd), 
e.returncode, e.output.decode("utf-8")))
+except OSError as e:
+bb.utils.remove(tmp_dir, recurse=True)
+bb.fatal("Unable to extract %s package. Command '%s' "
+ "returned %d:\n%s at %s" % (pkg_path, ' '.join(cmd), 
e.errno, e.strerror, e.filename))
+
+bb.note("Extracted %s to %s" % (pkg_path, tmp_dir))
+bb.utils.remove(os.path.join(tmp_dir, "debian-binary"))
+bb.utils.remove(os.path.join(tmp_dir, "control.tar.gz"))
+bb.utils.remove(os.path.join(tmp_dir, data_tar))
+os.chdir(current_dir)
+
+return tmp_dir
+
+def _handle_intercept_failure(self, registered_pkgs):
+self.mark_packages("unpacked", registered_pkgs.split())
diff --git a/meta/lib/oe/package_manager/deb/__init__.py 
b/meta/lib/oe/package_manager/deb/__init__.py
index 0c23c884c12..a96e56b2ada 100644
--- a/meta/lib/oe/package_manager/deb/__init__.py
+++ b/meta/lib/oe/package_manager/deb/__init__.py
@@ -7,6 +7,7 @@
 import re
 import subprocess
 from oe.package_manager import *
+from oe.package_manager import OpkgDpkgPM
 
 class DpkgIndexer(Indexer):
 def _create_configs(self):
@@ -111,72 +112,6 @@ class PMPkgsList(PkgsList):
 
 return 

[OE-core] [PATCH 0/3] package_manager: Clean up shared deb / ipk helpers

2024-05-16 Thread Philip Lorenz
This patch series fixes one issue which I missed in
"lib/package_manager/ipk: Do not hardcode payload compression algorithm"
(2ad05635a6da403b4fadcc126fe7734067c12c73). Default configurations using
zstd are not affected but I'd still like to make sure that things are
cleaned up.

Additionally, this series cleans up some deb / ipk related code by
moving their common base class to a shared location. This originally
used to be the case, but as part of a larger refactoring, the class was
duplicated into the individual packages. If there was some kind of
rationale for doing this (I couldn't think of one and couldn't figure
this out based on the commit history), please let me know.

As part of this clean up, the `extract` method is moved into the common
base class to ensure that future adaptations apply to both
specializations.

Philip Lorenz (3):
  ipk: Fix clean up of extracted IPK payload
  package_manager: Move OpkgDpkgPM into common module
  package_manager: Share more common DEB / IPK code

 meta/lib/oe/package_manager/common_deb_ipk.py | 97 +++
 meta/lib/oe/package_manager/deb/__init__.py   | 85 +---
 meta/lib/oe/package_manager/ipk/__init__.py   | 95 +-
 3 files changed, 101 insertions(+), 176 deletions(-)
 create mode 100644 meta/lib/oe/package_manager/common_deb_ipk.py

-- 
2.44.0


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



Re: [OE-core] [PATCH 05/10] base: Switch UNPACKDIR to a subdir of WORKDIR

2024-05-16 Thread Martin Hundeb?ll
On Wed, 2024-05-15 at 12:56 +0100, Richard Purdie wrote:
> diff --git a/meta/conf/bitbake.conf b/meta/conf/bitbake.conf
> index b2c500d8739..75c850760f6 100644
> --- a/meta/conf/bitbake.conf
> +++ b/meta/conf/bitbake.conf
> @@ -405,7 +405,7 @@ STAMP =
> "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/${PV}"
>  STAMPCLEAN = "${STAMPS_DIR}/${MULTIMACH_TARGET_SYS}/${PN}/*-*"
>  BASE_WORKDIR ?= "${TMPDIR}/work"
>  WORKDIR = "${BASE_WORKDIR}/${MULTIMACH_TARGET_SYS}/${PN}/${PV}"
> -UNPACKDIR ??= "${WORKDIR}"
> +UNPACKDIR ??= "${WORKDIR}/sources-unpack"
>  T = "${WORKDIR}/temp"
>  D = "${WORKDIR}/image"
>  S = "${WORKDIR}/${BP}"

Why not use

  UNPACKDIR ??= "${WORKDIR}/sources"

like it's done in the individual recipes?


And shouldn't we do 

  S = ?? "${UNPACKDIR}/${BP}"

also?

// Martin

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

2024-05-16 Thread Mark Jonas via lists.openembedded.org
From: Ricardo Simoes 

This commit sets the CVE_PRODUCT variable to "libusb" to match the
product name used in the NIST CPE database [1].

[1]: https://nvd.nist.gov/products/cpe/search

Signed-off-by: Ricardo Simoes 
Signed-off-by: Mark Jonas 
---
 meta/recipes-support/libusb/libusb1_1.0.27.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-support/libusb/libusb1_1.0.27.bb 
b/meta/recipes-support/libusb/libusb1_1.0.27.bb
index f2431d75c8..5bf854f95d 100644
--- a/meta/recipes-support/libusb/libusb1_1.0.27.bb
+++ b/meta/recipes-support/libusb/libusb1_1.0.27.bb
@@ -8,6 +8,8 @@ SECTION = "libs"
 LICENSE = "LGPL-2.1-or-later"
 LIC_FILES_CHKSUM = "file://COPYING;md5=fbc093901857fcd118f065f900982c24"
 
+CVE_PRODUCT = "libusb"
+
 BBCLASSEXTEND = "native nativesdk"
 
 SRC_URI = "${GITHUB_BASE_URI}/download/v${PV}/libusb-${PV}.tar.bz2 \
-- 
2.34.1


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