Re: [OE-core][master][PATCH v2] librsvg: Fix do_package_qa error for librsvg

2024-03-07 Thread Alexander Kanavin
meta-rust is generally seen as obsolete, is there a particular reason
you need to use it with oe-core master, instead of the standard rust
recipes?

Even then, this looks like it needs to be fixed in meta-rust, rather
than individual recipes. The error does not occur with official rust
toolchain, so meta-rust should just copy what that does.

Alex

On Fri, 8 Mar 2024 at 06:03, nikhil  wrote:
>
> When using meta-rust layer for rust below
> do_package_qa error in librsvg is observed
>
> Fix the below error:
> ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert 
> in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File 
> /usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass 
> LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors 
> were found, failing task.
>
> Signed-off-by: Nikhil R 
> ---
>  meta/recipes-gnome/librsvg/librsvg_2.56.3.bb | 2 ++
>  1 file changed, 2 insertions(+)
>
> diff --git a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb 
> b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> index 9824b8898d..e6eece6858 100644
> --- a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> +++ b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
> @@ -77,3 +77,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
>  RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
>
>  PIXBUF_PACKAGES = "librsvg-gtk"
> +
> +TARGET_CC_ARCH += "${LDFLAGS}"
> --
> 2.25.1
>
>
> 
>

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



[OE-core][master][PATCH v2] librsvg: Fix do_package_qa error for librsvg

2024-03-07 Thread nikhil
When using meta-rust layer for rust below
do_package_qa error in librsvg is observed

Fix the below error:
ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert 
in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File 
/usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass 
LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors 
were found, failing task.

Signed-off-by: Nikhil R 
---
 meta/recipes-gnome/librsvg/librsvg_2.56.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
index 9824b8898d..e6eece6858 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
@@ -77,3 +77,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
 RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
 
 PIXBUF_PACKAGES = "librsvg-gtk"
+
+TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.25.1


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



[OE-core][kirkstone][PATCH v2] librsvg: Fix do_package_qa error for librsvg

2024-03-07 Thread nikhil
When using meta-rust layer for rust below
do_package_qa error in librsvg is observed

Fix the below error:
ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert 
in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File 
/usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass 
LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors 
were found, failing task.

Signed-off-by: Nikhil R 
---
 meta/recipes-gnome/librsvg/librsvg_2.52.10.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
index b79e95a04f..21f502444b 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
@@ -73,3 +73,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
 RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
 
 PIXBUF_PACKAGES = "librsvg-gtk"
+
+TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.25.1


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



[OE-core][kirkstone][PATCH] librsvg: Fix do_package_qa error for librsvg

2024-03-07 Thread nikhil
When using meta-rust layer for rust below
do_package_qa error in librsvg is observed

Fix the below error:
ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert 
in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File 
/usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass 
LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors 
were found, failing task.

Upstream-Status: Pending

gitlint-ignore: B1, CCL1

Signed-off-by: Nikhil R 
---
 meta/recipes-gnome/librsvg/librsvg_2.52.10.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
index b79e95a04f..21f502444b 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.52.10.bb
@@ -73,3 +73,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
 RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
 
 PIXBUF_PACKAGES = "librsvg-gtk"
+
+TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.25.1


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



[OE-core][master][PATCH] librsvg: Fix do_package_qa error for librsvg

2024-03-07 Thread nikhil
When using meta-rust layer for rust below
do_package_qa error in librsvg is observed

Fix the below error:
ERROR: librsvg-2.52.10-r0 do_package_qa: QA Issue: File /usr/bin/rsvg-convert 
in package rsvg doesn't have GNU_HASH (didn't pass LDFLAGS?) File 
/usr/bin/rsvg-convert in package rsvg doesn't have GNU_HASH (didn't pass 
LDFLAGS?) [ldflags] ERROR: librsvg-2.52.10-r0 do_package_qa: Fatal QA errors 
were found, failing task.

Upstream-Status: Pending

gitlint-ignore: B1, CCL1

Signed-off-by: Nikhil R 
---
 meta/recipes-gnome/librsvg/librsvg_2.56.3.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb 
b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
index 9824b8898d..e6eece6858 100644
--- a/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
+++ b/meta/recipes-gnome/librsvg/librsvg_2.56.3.bb
@@ -77,3 +77,5 @@ FILES:librsvg-gtk = "${libdir}/gdk-pixbuf-2.0/*/*/*.so \
 RRECOMMENDS:librsvg-gtk = "gdk-pixbuf-bin"
 
 PIXBUF_PACKAGES = "librsvg-gtk"
+
+TARGET_CC_ARCH += "${LDFLAGS}"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196843): 
https://lists.openembedded.org/g/openembedded-core/message/196843
Mute This Topic: https://lists.openembedded.org/mt/104803672/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 v3] lttng-tools: skip kernel tests if no kernel modules present

2024-03-07 Thread Xiangyu Chen
From: Xiangyu Chen 

The current tests will run both userspace and kernel testing. Some of use cases
only use lttng for one kind of tracing (e.g. userspace). If the lttng
modules(.ko files) is not present during the test,it would end up with lots of
failing.

Add a check in ptest script, if current system doesn't contain lttng kernel
modules, passing LTTNG_TOOLS_DISABLE_KERNEL_TESTS=1 to make to skip all lttng
kernel related testing.

Signed-off-by: Xiangyu Chen 
---
changes:
v1->v2: the patch has been merged to lttng-tools master
v2->v3: fix patchtest, edit shortlog less than 90 characters
---
 ...skip_kernel_test-to-check-root-user-.patch | 1246 +
 .../lttng/lttng-tools/run-ptest   |   25 +
 .../lttng/lttng-tools_2.13.11.bb  |1 +
 3 files changed, 1272 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
new file mode 100644
index 00..2671a1908e
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
@@ -0,0 +1,1246 @@
+From cf558f802b259a33605fe0ede4d74ae2ff6be699 Mon Sep 17 00:00:00 2001
+From: Xiangyu Chen 
+Date: Mon, 12 Feb 2024 09:23:54 -0500
+Subject: [PATCH] tests: add check_skip_kernel_test to check root user and
+ lttng kernel modules
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The current tests will run both userspace and kernel testing. Some of
+use cases only use lttng for one kind of tracing on an embedded
+device (e.g. userspace), so in this scenario, the kernel modules might
+not install to target rootfs, the test cases would be fail and exit.
+
+Add LTTNG_TOOLS_DISABLE_KERNEL_TESTS to skip the lttng kernel features
+test, this flag can be set via "make":
+
+  make check LTTNG_TOOLS_DISABLE_KERNEL_TESTS=1
+
+When this flag was set, all kernel related testcases would be marked as
+SKIP in result.
+
+Since the the LTTNG_TOOLS_DISABLE_KERNEL_TESTS was checked in function
+check_skip_kernel_test, lots of testcases also need to check root
+permission, so merging the root permission checking into
+check_skip_kernel_test.
+
+Upstream-Status: Backport from
+[https://git.lttng.org/?p=lttng-tools.git;a=commit;h=3a1744008331a0604479d3d7461f77056fad3a64]
+
+Change-Id: I49a1f642a9869c21a69e0186c296fd917bd7b525
+Signed-off-by: Xiangyu Chen 
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Jérémie Galarneau 
+---
+ tests/destructive/metadata-regeneration   |  8 +
+ tests/perf/test_perf_raw.in   |  8 +
+ tests/regression/kernel/test_all_events   |  8 +
+ tests/regression/kernel/test_callstack|  8 +
+ tests/regression/kernel/test_channel  |  8 +
+ tests/regression/kernel/test_clock_override   |  8 +
+ tests/regression/kernel/test_event_basic  |  8 +
+ tests/regression/kernel/test_kernel_function  |  8 +
+ tests/regression/kernel/test_lttng_logger |  8 +
+ tests/regression/kernel/test_ns_contexts  |  8 +
+ .../regression/kernel/test_ns_contexts_change |  9 +
+ .../kernel/test_rotation_destroy_flush|  8 +
+ .../regression/kernel/test_select_poll_epoll  |  8 +
+ tests/regression/kernel/test_syscall  |  8 +
+ tests/regression/kernel/test_userspace_probe  |  8 +
+ tests/regression/tools/clear/test_kernel  |  8 +
+ .../tools/filtering/test_invalid_filter   |  8 +
+ .../tools/filtering/test_unsupported_op   |  8 +
+ .../tools/filtering/test_valid_filter |  8 +
+ tests/regression/tools/health/test_health.sh  | 10 ++
+ tests/regression/tools/health/test_thread_ok  |  9 +
+ tests/regression/tools/live/test_kernel   | 10 +++---
+ tests/regression/tools/live/test_lttng_kernel |  8 +
+ tests/regression/tools/metadata/test_kernel   |  8 +
+ .../test_notification_kernel_buffer_usage | 36 +--
+ .../test_notification_kernel_capture  | 23 ++--
+ .../test_notification_kernel_error| 23 ++--
+ .../test_notification_kernel_instrumentation  | 23 ++--
+ .../test_notification_kernel_syscall  | 19 +-
+ .../test_notification_kernel_userspace_probe  | 20 +--
+ .../notification/test_notification_multi_app  | 14 +++-
+ ...test_notification_notifier_discarded_count |  9 +++--
+ .../tools/regen-metadata/test_kernel  |  8 +
+ .../tools/regen-statedump/test_kernel |  8 +
+ tests/regression/tools/rotation/test_kernel   |  8 +
+ tests/regression/tools/snapshots/test_kernel  |  8 +
+ .../tools/snapshots/test_kernel_streaming |  8 +
+ 

Patchtest results for [OE-core][PATCH v2] lttng-tools: lttng-tools: skip lttng kernel related test if lttng kernel modules not present

2024-03-07 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/v2-lttng-tools-lttng-tools-skip-lttng-kernel-related-test-if-lttng-kernel-modules-not-present.patch

FAIL: test shortlog length: Edit shortlog so that it is 90 characters or less 
(currently 103 characters) (test_mbox.TestMbox.test_shortlog_length)

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 CVE tag format (test_patch.TestPatch.test_cve_tag_format)
PASS: test Signed-off-by presence 
(test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test Signed-off-by presence 
(test_patch.TestPatch.test_signed_off_by_presence)
PASS: test Upstream-Status presence 
(test_patch.TestPatch.test_upstream_status_presence_format)
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 src uri left files 
(test_metadata.TestMetadata.test_src_uri_left_files)

SKIP: pretest pylint: No python related patches, skipping test 
(test_python_pylint.PyLint.pretest_pylint)
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 (#196841): 
https://lists.openembedded.org/g/openembedded-core/message/196841
Mute This Topic: https://lists.openembedded.org/mt/104802629/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 v2] lttng-tools: lttng-tools: skip lttng kernel related test if lttng kernel modules not present

2024-03-07 Thread Xiangyu Chen
From: Xiangyu Chen 

The current tests will run both userspace and kernel testing. Some of use cases
only use lttng for one kind of tracing (e.g. userspace). If the lttng
modules(.ko files) is not present during the test,it would end up with lots of
failing.

Add a check in ptest script, if current system doesn't contain lttng kernel
modules, passing LTTNG_TOOLS_DISABLE_KERNEL_TESTS=1 to make to skip all lttng
kernel related testing.

Signed-off-by: Xiangyu Chen 
---
changes:
v1->v2: the patch has been merged to lttng-tools master

---
 ...skip_kernel_test-to-check-root-user-.patch | 1246 +
 .../lttng/lttng-tools/run-ptest   |   25 +
 .../lttng/lttng-tools_2.13.11.bb  |1 +
 3 files changed, 1272 insertions(+)
 create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch

diff --git 
a/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
new file mode 100644
index 00..2671a1908e
--- /dev/null
+++ 
b/meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch
@@ -0,0 +1,1246 @@
+From cf558f802b259a33605fe0ede4d74ae2ff6be699 Mon Sep 17 00:00:00 2001
+From: Xiangyu Chen 
+Date: Mon, 12 Feb 2024 09:23:54 -0500
+Subject: [PATCH] tests: add check_skip_kernel_test to check root user and
+ lttng kernel modules
+MIME-Version: 1.0
+Content-Type: text/plain; charset=UTF-8
+Content-Transfer-Encoding: 8bit
+
+The current tests will run both userspace and kernel testing. Some of
+use cases only use lttng for one kind of tracing on an embedded
+device (e.g. userspace), so in this scenario, the kernel modules might
+not install to target rootfs, the test cases would be fail and exit.
+
+Add LTTNG_TOOLS_DISABLE_KERNEL_TESTS to skip the lttng kernel features
+test, this flag can be set via "make":
+
+  make check LTTNG_TOOLS_DISABLE_KERNEL_TESTS=1
+
+When this flag was set, all kernel related testcases would be marked as
+SKIP in result.
+
+Since the the LTTNG_TOOLS_DISABLE_KERNEL_TESTS was checked in function
+check_skip_kernel_test, lots of testcases also need to check root
+permission, so merging the root permission checking into
+check_skip_kernel_test.
+
+Upstream-Status: Backport from
+[https://git.lttng.org/?p=lttng-tools.git;a=commit;h=3a1744008331a0604479d3d7461f77056fad3a64]
+
+Change-Id: I49a1f642a9869c21a69e0186c296fd917bd7b525
+Signed-off-by: Xiangyu Chen 
+Signed-off-by: Michael Jeanson 
+Signed-off-by: Jérémie Galarneau 
+---
+ tests/destructive/metadata-regeneration   |  8 +
+ tests/perf/test_perf_raw.in   |  8 +
+ tests/regression/kernel/test_all_events   |  8 +
+ tests/regression/kernel/test_callstack|  8 +
+ tests/regression/kernel/test_channel  |  8 +
+ tests/regression/kernel/test_clock_override   |  8 +
+ tests/regression/kernel/test_event_basic  |  8 +
+ tests/regression/kernel/test_kernel_function  |  8 +
+ tests/regression/kernel/test_lttng_logger |  8 +
+ tests/regression/kernel/test_ns_contexts  |  8 +
+ .../regression/kernel/test_ns_contexts_change |  9 +
+ .../kernel/test_rotation_destroy_flush|  8 +
+ .../regression/kernel/test_select_poll_epoll  |  8 +
+ tests/regression/kernel/test_syscall  |  8 +
+ tests/regression/kernel/test_userspace_probe  |  8 +
+ tests/regression/tools/clear/test_kernel  |  8 +
+ .../tools/filtering/test_invalid_filter   |  8 +
+ .../tools/filtering/test_unsupported_op   |  8 +
+ .../tools/filtering/test_valid_filter |  8 +
+ tests/regression/tools/health/test_health.sh  | 10 ++
+ tests/regression/tools/health/test_thread_ok  |  9 +
+ tests/regression/tools/live/test_kernel   | 10 +++---
+ tests/regression/tools/live/test_lttng_kernel |  8 +
+ tests/regression/tools/metadata/test_kernel   |  8 +
+ .../test_notification_kernel_buffer_usage | 36 +--
+ .../test_notification_kernel_capture  | 23 ++--
+ .../test_notification_kernel_error| 23 ++--
+ .../test_notification_kernel_instrumentation  | 23 ++--
+ .../test_notification_kernel_syscall  | 19 +-
+ .../test_notification_kernel_userspace_probe  | 20 +--
+ .../notification/test_notification_multi_app  | 14 +++-
+ ...test_notification_notifier_discarded_count |  9 +++--
+ .../tools/regen-metadata/test_kernel  |  8 +
+ .../tools/regen-statedump/test_kernel |  8 +
+ tests/regression/tools/rotation/test_kernel   |  8 +
+ tests/regression/tools/snapshots/test_kernel  |  8 +
+ .../tools/snapshots/test_kernel_streaming |  8 +
+ .../streaming/test_high_throughput_limits |  8 +
+ 

Re: [OE-core][PATCH] lttng-tools: skip lttng kernel related test if lttng kernel modules not present

2024-03-07 Thread Xiangyu Chen


On 2/10/24 00:44, Richard Purdie 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 Wed, 2024-01-31 at 11:40 +0800, Xiangyu Chen wrote:

From: Xiangyu Chen 

The current tests will run both userspace and kernel testing. Some of use cases 
only
use lttng for one kind of tracing (e.g. userspace). If the lttng modules(.ko 
files)
is not present during the test,it would end up with lots of failing.

Add a check in ptest script, if current system doesn't contain lttng kernel 
modules,
passing LTTNG_TOOLS_DISABLE_KERNEL_TESTS=1 to make to skip all lttng kernel 
related testing.

Signed-off-by: Xiangyu Chen 
---
  ...skip_kernel_test-to-check-root-user-.patch | 1307 +
  .../lttng/lttng-tools/run-ptest   |   25 +
  .../lttng/lttng-tools_2.13.11.bb  |1 +
  3 files changed, 1333 insertions(+)
  create mode 100644 
meta/recipes-kernel/lttng/lttng-tools/0001-tests-add-check_skip_kernel_test-to-check-root-user-.patch

This is a complex patch and I don't really want to carry this until
something merges upstream or ideally makes it into a released version.


Hi Richard,


Thanks for your suggestion,

lttng upstream has merged this patch, I'll send a v2 patch to oe-core 
later after a simple testing in my local setup.



Br,

Xiangyu



We simply don't have the maintainer capacity to carry large patches
like this unfortunately and the number of people who need it isn't
clear.

Cheers,

Richard

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



Re: [OE-core] [PATCH] glibc: Fix conflict error when enbale multilib on aarch64.

2024-03-07 Thread leimaohui via lists.openembedded.org
Ping 



> -Original Message-
> From: openembedded-core@lists.openembedded.org
>  On Behalf Of Khem Raj
> Sent: Monday, February 26, 2024 2:19 PM
> To: Lei, Maohui 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] glibc: Fix conflict error when enbale multilib 
> on
> aarch64.
> 
> lgtm.
> 
> On Sun, Feb 25, 2024 at 9:32 PM leimaohui via lists.openembedded.org
>  wrote:
> >
> > From: Lei Maohui 
> >
> > Error: Transaction test error:
> >   file /usr/include/finclude/math-vector-fortran.h from install of
> > lib32-libc6-dev-2.39+git0+312e159626-r0.armv7ahf_neon conflicts with
> > file from package libc6-dev-2.39+git0+312e159626-r0.aarch64
> >
> > The difference of math-vector-fortran.h between 32bit and 64bit is as
> > the following:
> >
> > ---
> tmp/work/aarch64-linux/glibc/2.39+git/image/usr/include/finclude/math-vecto
> r-fortran.h2024-02-26 03:41:59.56000 +
> > +++ tmp/work/armv7ahf-neon-xmllib32-linux-gnueabi/lib32-glibc/2.39+git
> > +++ /image/usr/include/finclude/math-vector-fortran.h 2024-02-26
> > +++ 02:22:28.59200 +
> > @@ -15,33 +15,5 @@
> >  !   You should have received a copy of the GNU Lesser General Public
> >  !   License along with the GNU C Library; if not, see
> >  !   .
> > -!GCC$ builtin (acos) attributes simd (notinbranch) -!GCC$ builtin
> > (acosf) attributes simd (notinbranch) -!GCC$ builtin (asin) attributes
> > simd (notinbranch) -!GCC$ builtin (asinf) attributes simd
> > (notinbranch) -!GCC$ builtin (atan) attributes simd (notinbranch)
> > -!GCC$ builtin (atanf) attributes simd (notinbranch) -!GCC$ builtin
> > (atan2) attributes simd (notinbranch) -!GCC$ builtin (atan2f)
> > attributes simd (notinbranch) -!GCC$ builtin (cos) attributes simd
> > (notinbranch) -!GCC$ builtin (cosf) attributes simd (notinbranch)
> > -!GCC$ builtin (exp) attributes simd (notinbranch) -!GCC$ builtin
> > (expf) attributes simd (notinbranch) -!GCC$ builtin (exp10) attributes
> > simd (notinbranch) -!GCC$ builtin (exp10f) attributes simd
> > (notinbranch) -!GCC$ builtin (exp2) attributes simd (notinbranch)
> > -!GCC$ builtin (exp2f) attributes simd (notinbranch) -!GCC$ builtin
> > (expm1) attributes simd (notinbranch) -!GCC$ builtin (expm1f)
> > attributes simd (notinbranch) -!GCC$ builtin (log) attributes simd
> > (notinbranch) -!GCC$ builtin (logf) attributes simd (notinbranch)
> > -!GCC$ builtin (log10) attributes simd (notinbranch) -!GCC$ builtin
> > (log10f) attributes simd (notinbranch) -!GCC$ builtin (log1p)
> > attributes simd (notinbranch) -!GCC$ builtin (log1pf) attributes simd
> > (notinbranch) -!GCC$ builtin (log2) attributes simd (notinbranch)
> > -!GCC$ builtin (log2f) attributes simd (notinbranch) -!GCC$ builtin
> > (sin) attributes simd (notinbranch) -!GCC$ builtin (sinf) attributes
> > simd (notinbranch) -!GCC$ builtin (tan) attributes simd (notinbranch)
> > -!GCC$ builtin (tanf) attributes simd (notinbranch)
> > +
> > +! No SIMD math functions are available for this platform.
> >
> > Signed-off-by: Lei Maohui 
> > ---
> >  meta/recipes-core/glibc/glibc-package.inc | 1 +
> >  1 file changed, 1 insertion(+)
> >
> > diff --git a/meta/recipes-core/glibc/glibc-package.inc
> > b/meta/recipes-core/glibc/glibc-package.inc
> > index 1ef987be0a..19eb7afa81 100644
> > --- a/meta/recipes-core/glibc/glibc-package.inc
> > +++ b/meta/recipes-core/glibc/glibc-package.inc
> > @@ -167,6 +167,7 @@ do_install_armmultilib () {
> > oe_multilib_header fpu_control.h gnu/lib-names.h gnu/stubs.h
> > ieee754.h
> >
> > oe_multilib_header sys/elf.h sys/procfs.h sys/ptrace.h
> > sys/ucontext.h sys/user.h
> > +   oe_multilib_header finclude/math-vector-fortran.h
> >  }
> >
> >
> > --
> > 2.34.1
> >
> >
> >
> >

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



[oe-core][kirkstone][PATCH 1/1] expat: fix CVE-2023-52426

2024-03-07 Thread Meenali Gupta via lists.openembedded.org
From: Meenali Gupta 

A flaw was found in Expat (libexpat). If XML_DTD is undefined at compile time, 
a recursive XML Entity
Expansion condition can be triggered. This issue may lead to a condition where 
data is expanded exponentially,
which will quickly consume system resources and cause a denial of service.

Signed-off-by: Meenali Gupta 
---
 .../expat/expat/CVE-2023-52426.patch  | 429 ++
 meta/recipes-core/expat/expat_2.5.0.bb|   1 +
 2 files changed, 430 insertions(+)
 create mode 100644 meta/recipes-core/expat/expat/CVE-2023-52426.patch

diff --git a/meta/recipes-core/expat/expat/CVE-2023-52426.patch 
b/meta/recipes-core/expat/expat/CVE-2023-52426.patch
new file mode 100644
index 00..b78a8ee0dc
--- /dev/null
+++ b/meta/recipes-core/expat/expat/CVE-2023-52426.patch
@@ -0,0 +1,429 @@
+From 0f075ec8ecb5e43f8fdca5182f8cca4703da0404 Mon Sep 17 00:00:00 2001
+From: Sebastian Pipping 
+Date: Thu, 26 Oct 2023 00:43:22 +0200
+Subject: [PATCH] lib|xmlwf|cmake: Extend scope of billion laughs attack
+ protection
+
+.. from "defined(XML_DTD)" to "defined(XML_DTD) || XML_GE==1".
+
+CVE: CVE-2023-52426
+Upstream-Status: Backport 
[https://github.com/libexpat/libexpat/commit/0f075ec8ecb5e43f8fdca5182f8cca4703da0404]
+
+Signed-off-by: Meenali Gupta 
+---
+ CMakeLists.txt |  8 -
+ lib/expat.h|  8 +++--
+ lib/internal.h |  2 +-
+ lib/libexpat.def.cmake |  4 +--
+ lib/xmlparse.c | 71 ++
+ xmlwf/xmlwf.c  | 18 ++-
+ 6 files changed, 62 insertions(+), 49 deletions(-)
+
+diff --git a/CMakeLists.txt b/CMakeLists.txt
+index 2b4c13c..183c5c2 100644
+--- a/CMakeLists.txt
 b/CMakeLists.txt
+@@ -381,7 +381,13 @@ if(EXPAT_SHARED_LIBS)
+ endif()
+ endmacro()
+
+-_expat_def_file_toggle(EXPAT_DTD _EXPAT_COMMENT_DTD)
++  if(EXPAT_DTD OR EXPAT_GE)
++set(_EXPAT_DTD_OR_GE TRUE)
++else()
++set(_EXPAT_DTD_OR_GE FALSE)
++endif()
++
++_expat_def_file_toggle(_EXPAT_DTD_OR_GE _EXPAT_COMMENT_DTD_OR_GE)
+ _expat_def_file_toggle(EXPAT_ATTR_INFO _EXPAT_COMMENT_ATTR_INFO)
+
+ configure_file("${CMAKE_CURRENT_SOURCE_DIR}/lib/libexpat.def.cmake" 
"${CMAKE_CURRENT_BINARY_DIR}/lib/libexpat.def")
+diff --git a/lib/expat.h b/lib/expat.h
+index 1c83563..33c94af 100644
+--- a/lib/expat.h
 b/lib/expat.h
+@@ -1038,13 +1038,15 @@ typedef struct {
+ XMLPARSEAPI(const XML_Feature *)
+ XML_GetFeatureList(void);
+
+-#ifdef XML_DTD
+-/* Added in Expat 2.4.0. */
++#if defined(XML_DTD) || XML_GE == 1
++/* Added in Expat 2.4.0 for XML_DTD defined and
++ * added in Expat 2.6.0 for XML_GE == 1. */
+ XMLPARSEAPI(XML_Bool)
+ XML_SetBillionLaughsAttackProtectionMaximumAmplification(
+ XML_Parser parser, float maximumAmplificationFactor);
+
+-/* Added in Expat 2.4.0. */
++/* Added in Expat 2.4.0 for XML_DTD defined and
++ * added in Expat 2.6.0 for XML_GE == 1. */
+ XMLPARSEAPI(XML_Bool)
+ XML_SetBillionLaughsAttackProtectionActivationThreshold(
+ XML_Parser parser, unsigned long long activationThresholdBytes);
+diff --git a/lib/internal.h b/lib/internal.h
+index e09f533..1851925 100644
+--- a/lib/internal.h
 b/lib/internal.h
+@@ -154,7 +154,7 @@ extern "C" {
+ void _INTERNAL_trim_to_complete_utf8_characters(const char *from,
+ const char **fromLimRef);
+
+-#if defined(XML_DTD)
++#if defined(XML_DTD) || XML_GE == 1
+ unsigned long long testingAccountingGetCountBytesDirect(XML_Parser parser);
+ unsigned long long testingAccountingGetCountBytesIndirect(XML_Parser parser);
+ const char *unsignedCharToPrintable(unsigned char c);
+diff --git a/lib/libexpat.def.cmake b/lib/libexpat.def.cmake
+index cf434a2..61a4f00 100644
+--- a/lib/libexpat.def.cmake
 b/lib/libexpat.def.cmake
+@@ -75,5 +75,5 @@ EXPORTS
+   XML_SetHashSalt @67
+ ; internal @68 removed with version 2.3.1
+ ; added with version 2.4.0
+-@_EXPAT_COMMENT_DTD@ XML_SetBillionLaughsAttackProtectionActivationThreshold 
@69
+-@_EXPAT_COMMENT_DTD@ XML_SetBillionLaughsAttackProtectionMaximumAmplification 
@70
++@_EXPAT_COMMENT_DTD_OR_GE@ 
XML_SetBillionLaughsAttackProtectionActivationThreshold @69
++@_EXPAT_COMMENT_DTD_OR_GE@ 
XML_SetBillionLaughsAttackProtectionMaximumAmplification @70
+diff --git a/lib/xmlparse.c b/lib/xmlparse.c
+index b6c2eca..e23441e 100644
+--- a/lib/xmlparse.c
 b/lib/xmlparse.c
+@@ -408,7 +408,7 @@ enum XML_Account {
+   XML_ACCOUNT_NONE  /* i.e. do not account, was accounted already 
*/
+ };
+
+-#ifdef XML_DTD
++#if defined(XML_DTD) || XML_GE == 1
+ typedef unsigned long long XmlBigCount;
+ typedef struct accounting {
+   XmlBigCount countBytesDirect;
+@@ -424,7 +424,7 @@ typedef struct entity_stats {
+   unsigned int maximumDepthSeen;
+   int debugLevel;
+ } ENTITY_STATS;
+-#endif /* XML_DTD */
++#endif /* defined(XML_DTD) || XML_GE == 1 */
+
+ typedef enum XML_Error PTRCALL 

[OE-core][kirkstone 9/9] Revert "linux-yocto/5.15: update to v5.15.141"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit 5832eebee3c150a30bd489699ca693240d11beda.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index f7286759a9..6ac3118f81 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "423b5d5cb3f45a272285fa4157d1964086fabc2e"
-SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
+SRCREV_machine ?= "0ac91942af8fec31671ffe62e9518aaf15f110b3"
+SRCREV_meta ?= "f484a7f175b4f3c4f7d2b553cde232bd41f757d8"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.141"
+LINUX_VERSION ?= "5.15.124"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 7461087299..9c06ddf200 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.141"
+LINUX_VERSION ?= "5.15.124"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "ddf2eeeb31d1edaa5a80e9aabc8b2674ae95f865"
-SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
+SRCREV_machine ?= "cdb289c798fe1fc9f259a08c32e2dd9516ccb7a4"
+SRCREV_meta ?= "f484a7f175b4f3c4f7d2b553cde232bd41f757d8"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index c7b07dee62..439479022b 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,24 +14,24 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "0bd882ff2a47566033965928ab468491f7e1ffd6"
-SRCREV_machine:qemuarm64 ?= "d353330a9ba30300be32f1d732723ae3678da684"
-SRCREV_machine:qemumips ?= "7f8fbffda634dc22a70f69ff2b762a1f3ff9c842"
-SRCREV_machine:qemuppc ?= "fb2191ca96824c7451fbca4eef129660d25711af"
-SRCREV_machine:qemuriscv64 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
-SRCREV_machine:qemuriscv32 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
-SRCREV_machine:qemux86 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
-SRCREV_machine:qemux86-64 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
-SRCREV_machine:qemumips64 ?= "35895af6b529915f9c09a720592554feaca9a2c7"
-SRCREV_machine ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
-SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
+SRCREV_machine:qemuarm ?= "676a22c65ec0f8bb5dc7e13d130f6e3764959d75"
+SRCREV_machine:qemuarm64 ?= "f0e7afd5948f71be062cd9194b56cd03de94b7cb"
+SRCREV_machine:qemumips ?= "0f1ceb9008f182cd7f21420bbec6f21a67da8397"
+SRCREV_machine:qemuppc ?= "4ec9fc13283ce01627ef8c32617a1eb71e127c62"
+SRCREV_machine:qemuriscv64 ?= "1c09be01f4b87f60ea64136459167d73502a118f"
+SRCREV_machine:qemuriscv32 ?= "1c09be01f4b87f60ea64136459167d73502a118f"
+SRCREV_machine:qemux86 ?= "1c09be01f4b87f60ea64136459167d73502a118f"
+SRCREV_machine:qemux86-64 ?= "1c09be01f4b87f60ea64136459167d73502a118f"
+SRCREV_machine:qemumips64 ?= "fad09cc6acf2175aa6b5979ef48cd5f05afc3da0"
+SRCREV_machine ?= "1c09be01f4b87f60ea64136459167d73502a118f"
+SRCREV_meta ?= "f484a7f175b4f3c4f7d2b553cde232bd41f757d8"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds. Select your version using the
 # normal PREFERRED_VERSION settings.
 BBCLASSEXTEND = "devupstream:target"
-SRCREV_machine:class-devupstream ?= "9b91d36ba301db86bbf9e783169f7f6abf2585d8"
+SRCREV_machine:class-devupstream ?= "38d4ca22a5288c4bae7e6d62a1728b0718d51866"
 PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v5.15/base"
 
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA


[OE-core][kirkstone 8/9] Revert "linux-yocto/5.15: update to v5.15.142"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit 4deed206f92fc207d18cdb4c8bc35ce1bf0fb0f6.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 37fb729e0d..f7286759a9 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "205938506aafa86698f2753a59d2c9f13d080fbb"
-SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
+SRCREV_machine ?= "423b5d5cb3f45a272285fa4157d1964086fabc2e"
+SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.142"
+LINUX_VERSION ?= "5.15.141"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index f502030c9d..7461087299 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.142"
+LINUX_VERSION ?= "5.15.141"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "53b8058476d634a0103dff993e24d15b1fd087c7"
-SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
+SRCREV_machine ?= "ddf2eeeb31d1edaa5a80e9aabc8b2674ae95f865"
+SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 1021065bf7..c7b07dee62 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,24 +14,24 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "325679bc1a595ca81783f7652e13ce7f2be58620"
-SRCREV_machine:qemuarm64 ?= "338f086bcd841a5b0239ddb66c34ca23ff5af2f5"
-SRCREV_machine:qemumips ?= "af26192f4dd0fc7396faedd4653034ae02d5ed6d"
-SRCREV_machine:qemuppc ?= "be567407d4d9009407c4e7a511e7227fcb36b0b7"
-SRCREV_machine:qemuriscv64 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
-SRCREV_machine:qemuriscv32 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
-SRCREV_machine:qemux86 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
-SRCREV_machine:qemux86-64 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
-SRCREV_machine:qemumips64 ?= "3a2ff5c2f2e6e0c0653da1192081681e2a50b592"
-SRCREV_machine ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
-SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
+SRCREV_machine:qemuarm ?= "0bd882ff2a47566033965928ab468491f7e1ffd6"
+SRCREV_machine:qemuarm64 ?= "d353330a9ba30300be32f1d732723ae3678da684"
+SRCREV_machine:qemumips ?= "7f8fbffda634dc22a70f69ff2b762a1f3ff9c842"
+SRCREV_machine:qemuppc ?= "fb2191ca96824c7451fbca4eef129660d25711af"
+SRCREV_machine:qemuriscv64 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
+SRCREV_machine:qemuriscv32 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
+SRCREV_machine:qemux86 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
+SRCREV_machine:qemux86-64 ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
+SRCREV_machine:qemumips64 ?= "35895af6b529915f9c09a720592554feaca9a2c7"
+SRCREV_machine ?= "54a3472506956ed41289ae423ca9b7ad4cbb3ab5"
+SRCREV_meta ?= "92bd0a656f0f9db955fb53c52be71cce9296bdb2"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds. Select your version using the
 # normal PREFERRED_VERSION settings.
 BBCLASSEXTEND = "devupstream:target"
-SRCREV_machine:class-devupstream ?= "8a1d809b05454b2e08fb3d801787917975fdb037"
+SRCREV_machine:class-devupstream ?= "9b91d36ba301db86bbf9e783169f7f6abf2585d8"
 PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v5.15/base"
 
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA


[OE-core][kirkstone 7/9] Revert "linux-yocto/5.15: update to v5.15.145"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit 03794866c1333113c909ef88dc232bcc47a7c459.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 4f02e5acfa..37fb729e0d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "cf2f74df4ffdee7034979616bc37c5717b0d6070"
-SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
+SRCREV_machine ?= "205938506aafa86698f2753a59d2c9f13d080fbb"
+SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.145"
+LINUX_VERSION ?= "5.15.142"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 037c33f434..f502030c9d 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.145"
+LINUX_VERSION ?= "5.15.142"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "3b30ca7fb1716cd0f7bbf16c1253d8a4bbdeb421"
-SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
+SRCREV_machine ?= "53b8058476d634a0103dff993e24d15b1fd087c7"
+SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 0cb559b162..1021065bf7 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,24 +14,24 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "5b261b61614c090b787fdadb865c5db3ee0171f4"
-SRCREV_machine:qemuarm64 ?= "fdaf870c63fc887b40138cca652ae961c9556a95"
-SRCREV_machine:qemumips ?= "8a07b5a788879035d1eea4df0780a40d131cf5d9"
-SRCREV_machine:qemuppc ?= "fffda6901d92bf63f7876cb6d912492030995588"
-SRCREV_machine:qemuriscv64 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
-SRCREV_machine:qemuriscv32 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
-SRCREV_machine:qemux86 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
-SRCREV_machine:qemux86-64 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
-SRCREV_machine:qemumips64 ?= "510f5a0a3daaf9f970b610a427f77c52289a2777"
-SRCREV_machine ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
-SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
+SRCREV_machine:qemuarm ?= "325679bc1a595ca81783f7652e13ce7f2be58620"
+SRCREV_machine:qemuarm64 ?= "338f086bcd841a5b0239ddb66c34ca23ff5af2f5"
+SRCREV_machine:qemumips ?= "af26192f4dd0fc7396faedd4653034ae02d5ed6d"
+SRCREV_machine:qemuppc ?= "be567407d4d9009407c4e7a511e7227fcb36b0b7"
+SRCREV_machine:qemuriscv64 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
+SRCREV_machine:qemuriscv32 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
+SRCREV_machine:qemux86 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
+SRCREV_machine:qemux86-64 ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
+SRCREV_machine:qemumips64 ?= "3a2ff5c2f2e6e0c0653da1192081681e2a50b592"
+SRCREV_machine ?= "97015a8737f3f284f9a9c4967bf12c8b26efcdcc"
+SRCREV_meta ?= "9a1e0301f56cda16a9fabd03745dba445f068349"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds. Select your version using the
 # normal PREFERRED_VERSION settings.
 BBCLASSEXTEND = "devupstream:target"
-SRCREV_machine:class-devupstream ?= "d93fa2c78854d25ed4b67ac87f1c3c264d8b27fb"
+SRCREV_machine:class-devupstream ?= "8a1d809b05454b2e08fb3d801787917975fdb037"
 PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v5.15/base"
 
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA


[OE-core][kirkstone 4/9] Revert "linux-yocto/5.15: update to v5.15.147"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit f4f1964a7a2922f3253484852b76602af5f31a89.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 24 +--
 3 files changed, 18 insertions(+), 18 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index e64f21b2f0..1e61698222 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "7168cfa2ce6492db31163393808806b6f48af5e8"
-SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
+SRCREV_machine ?= "daa620f017a02ae381f1e54be7ceb8a2f3e3caee"
+SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.147"
+LINUX_VERSION ?= "5.15.146"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 38bea23264..c7c4e09bd9 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.147"
+LINUX_VERSION ?= "5.15.146"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "641e2136a155ce3179c84b9365a5998c1354fdd0"
-SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
+SRCREV_machine ?= "aade2fc343af128889d6c6f1071ec1a8e9a548a8"
+SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 1acd7b62cd..ef8c18b1b2 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,17 +14,17 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "82f8a25a3894c10d1cf26914b8e51726351ba11e"
-SRCREV_machine:qemuarm64 ?= "cf955e443d881e296b83940143fd30ea83fcf222"
-SRCREV_machine:qemumips ?= "1c3babd3b42768e24c797edfc3f67906aca6d072"
-SRCREV_machine:qemuppc ?= "b08998787bece69376578b049cab073d8b80e872"
-SRCREV_machine:qemuriscv64 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
-SRCREV_machine:qemuriscv32 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
-SRCREV_machine:qemux86 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
-SRCREV_machine:qemux86-64 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
-SRCREV_machine:qemumips64 ?= "4ff2c0496c0160a96185a080ec9678c63b68bd47"
-SRCREV_machine ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
-SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
+SRCREV_machine:qemuarm ?= "f59d00a628c3ddb39052284a4a7bd54f9ee12999"
+SRCREV_machine:qemuarm64 ?= "8b10556d4fd67dec1a16252ef0d3058dfe31dff5"
+SRCREV_machine:qemumips ?= "b0c8aefa7811fd3b7cebb25c1565f73523c7b2ac"
+SRCREV_machine:qemuppc ?= "0ebd785a8436934e3f3e6dea6506de7f7ed9947e"
+SRCREV_machine:qemuriscv64 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
+SRCREV_machine:qemuriscv32 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
+SRCREV_machine:qemux86 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
+SRCREV_machine:qemux86-64 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
+SRCREV_machine:qemumips64 ?= "187d249255a797c470b0680f28e18a17a05c3bb4"
+SRCREV_machine ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
+SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
-LINUX_VERSION ?= "5.15.147"
+LINUX_VERSION ?= "5.15.146"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
 DEPENDS += "openssl-native util-linux-native"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages 

[OE-core][kirkstone 6/9] Revert "linux-yocto/5.15: update to v5.15.146"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit ee4695138e36155c8e0b173f7952372693c0589a.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 1e61698222..4f02e5acfa 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "daa620f017a02ae381f1e54be7ceb8a2f3e3caee"
-SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
+SRCREV_machine ?= "cf2f74df4ffdee7034979616bc37c5717b0d6070"
+SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.146"
+LINUX_VERSION ?= "5.15.145"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index c7c4e09bd9..037c33f434 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.146"
+LINUX_VERSION ?= "5.15.145"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "aade2fc343af128889d6c6f1071ec1a8e9a548a8"
-SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
+SRCREV_machine ?= "3b30ca7fb1716cd0f7bbf16c1253d8a4bbdeb421"
+SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index ef8c18b1b2..0cb559b162 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,24 +14,24 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "f59d00a628c3ddb39052284a4a7bd54f9ee12999"
-SRCREV_machine:qemuarm64 ?= "8b10556d4fd67dec1a16252ef0d3058dfe31dff5"
-SRCREV_machine:qemumips ?= "b0c8aefa7811fd3b7cebb25c1565f73523c7b2ac"
-SRCREV_machine:qemuppc ?= "0ebd785a8436934e3f3e6dea6506de7f7ed9947e"
-SRCREV_machine:qemuriscv64 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
-SRCREV_machine:qemuriscv32 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
-SRCREV_machine:qemux86 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
-SRCREV_machine:qemux86-64 ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
-SRCREV_machine:qemumips64 ?= "187d249255a797c470b0680f28e18a17a05c3bb4"
-SRCREV_machine ?= "ea4d6bb2c229f41b49dc8a8a9cdcd6d7e55dc46f"
-SRCREV_meta ?= "be429ba6790683eae6d1c34d527af29890988c25"
+SRCREV_machine:qemuarm ?= "5b261b61614c090b787fdadb865c5db3ee0171f4"
+SRCREV_machine:qemuarm64 ?= "fdaf870c63fc887b40138cca652ae961c9556a95"
+SRCREV_machine:qemumips ?= "8a07b5a788879035d1eea4df0780a40d131cf5d9"
+SRCREV_machine:qemuppc ?= "fffda6901d92bf63f7876cb6d912492030995588"
+SRCREV_machine:qemuriscv64 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
+SRCREV_machine:qemuriscv32 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
+SRCREV_machine:qemux86 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
+SRCREV_machine:qemux86-64 ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
+SRCREV_machine:qemumips64 ?= "510f5a0a3daaf9f970b610a427f77c52289a2777"
+SRCREV_machine ?= "dd7a3940edb28ce99789430818b521c38dec4c6f"
+SRCREV_meta ?= "d3ba5beca1136447584b7af10546fff974c36cc1"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds. Select your version using the
 # normal PREFERRED_VERSION settings.
 BBCLASSEXTEND = "devupstream:target"
-SRCREV_machine:class-devupstream ?= "26c690eff0a56293e0b6911a38e406c211b35547"
+SRCREV_machine:class-devupstream ?= "d93fa2c78854d25ed4b67ac87f1c3c264d8b27fb"
 PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v5.15/base"
 
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA


[OE-core][kirkstone 5/9] Revert "linux-yocto/5.15: update CVE exclusions"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit 22b1db5362e18ee6c2a90049facc72c3554542dd.
---
 .../linux/cve-exclusion_5.15.inc  | 259 +++---
 1 file changed, 36 insertions(+), 223 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc 
b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
index 84d0becb8d..7822040782 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2024-01-11 21:16:55.956074 for version 5.15.146
+# Generated at 2023-09-23 10:40:51.641475 for version 5.15.124
 
 python check_kernel_cve_status_version() {
-this_version = "5.15.146"
+this_version = "5.15.124"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
@@ -4839,8 +4839,7 @@ CVE_CHECK_IGNORE += "CVE-2020-27194"
 # fixed-version: Fixed after version 5.6rc4
 CVE_CHECK_IGNORE += "CVE-2020-2732"
 
-# fixed-version: Fixed after version 5.6rc5
-CVE_CHECK_IGNORE += "CVE-2020-27418"
+# CVE-2020-27418 has no known resolution
 
 # fixed-version: Fixed after version 5.10rc1
 CVE_CHECK_IGNORE += "CVE-2020-27673"
@@ -4982,9 +4981,6 @@ CVE_CHECK_IGNORE += "CVE-2020-36691"
 # fixed-version: Fixed after version 5.10
 CVE_CHECK_IGNORE += "CVE-2020-36694"
 
-# fixed-version: Fixed after version 5.9rc1
-CVE_CHECK_IGNORE += "CVE-2020-36766"
-
 # fixed-version: Fixed after version 5.12rc1
 CVE_CHECK_IGNORE += "CVE-2020-3702"
 
@@ -6454,8 +6450,7 @@ CVE_CHECK_IGNORE += "CVE-2022-40768"
 # cpe-stable-backport: Backported in 5.15.66
 CVE_CHECK_IGNORE += "CVE-2022-4095"
 
-# cpe-stable-backport: Backported in 5.15.125
-CVE_CHECK_IGNORE += "CVE-2022-40982"
+# CVE-2022-40982 needs backporting (fixed from 5.15.125)
 
 # cpe-stable-backport: Backported in 5.15.87
 CVE_CHECK_IGNORE += "CVE-2022-41218"
@@ -6541,7 +6536,7 @@ CVE_CHECK_IGNORE += "CVE-2022-43945"
 
 # CVE-2022-44033 needs backporting (fixed from 6.4rc1)
 
-# CVE-2022-44034 needs backporting (fixed from 6.4rc1)
+# CVE-2022-44034 has no known resolution
 
 # CVE-2022-4543 has no known resolution
 
@@ -6596,8 +6591,7 @@ CVE_CHECK_IGNORE += "CVE-2022-47938"
 # cpe-stable-backport: Backported in 5.15.61
 CVE_CHECK_IGNORE += "CVE-2022-47939"
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE += "CVE-2022-47940"
+# CVE-2022-47940 needs backporting (fixed from 5.19rc1)
 
 # cpe-stable-backport: Backported in 5.15.61
 CVE_CHECK_IGNORE += "CVE-2022-47941"
@@ -6714,11 +6708,9 @@ CVE_CHECK_IGNORE += "CVE-2023-1118"
 # cpe-stable-backport: Backported in 5.15.113
 CVE_CHECK_IGNORE += "CVE-2023-1192"
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE += "CVE-2023-1193"
+# CVE-2023-1193 has no known resolution
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE += "CVE-2023-1194"
+# CVE-2023-1194 has no known resolution
 
 # fixed-version: only affects 5.16rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-1195"
@@ -6805,11 +6797,9 @@ CVE_CHECK_IGNORE += "CVE-2023-2008"
 # cpe-stable-backport: Backported in 5.15.61
 CVE_CHECK_IGNORE += "CVE-2023-2019"
 
-# cpe-stable-backport: Backported in 5.15.125
-CVE_CHECK_IGNORE += "CVE-2023-20569"
+# CVE-2023-20569 needs backporting (fixed from 5.15.125)
 
-# cpe-stable-backport: Backported in 5.15.126
-CVE_CHECK_IGNORE += "CVE-2023-20588"
+# CVE-2023-20588 needs backporting (fixed from 5.15.126)
 
 # cpe-stable-backport: Backported in 5.15.122
 CVE_CHECK_IGNORE += "CVE-2023-20593"
@@ -6932,8 +6922,7 @@ CVE_CHECK_IGNORE += "CVE-2023-25012"
 # cpe-stable-backport: Backported in 5.15.61
 CVE_CHECK_IGNORE += "CVE-2023-2513"
 
-# cpe-stable-backport: Backported in 5.15.144
-CVE_CHECK_IGNORE += "CVE-2023-25775"
+# CVE-2023-25775 needs backporting (fixed from 6.6rc1)
 
 # fixed-version: only affects 6.3rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-2598"
@@ -7014,8 +7003,7 @@ CVE_CHECK_IGNORE += "CVE-2023-3106"
 
 # CVE-2023-31084 needs backporting (fixed from 6.4rc3)
 
-# cpe-stable-backport: Backported in 5.15.135
-CVE_CHECK_IGNORE += "CVE-2023-31085"
+# CVE-2023-31085 has no known resolution
 
 # cpe-stable-backport: Backported in 5.15.63
 CVE_CHECK_IGNORE += "CVE-2023-3111"
@@ -7047,26 +7035,20 @@ CVE_CHECK_IGNORE += "CVE-2023-3220"
 # cpe-stable-backport: Backported in 5.15.111
 CVE_CHECK_IGNORE += "CVE-2023-32233"
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE += "CVE-2023-32247"
+# CVE-2023-32247 needs backporting (fixed from 6.4rc1)
 
 # cpe-stable-backport: Backported in 5.15.111
 CVE_CHECK_IGNORE += "CVE-2023-32248"
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE += "CVE-2023-32250"
+# CVE-2023-32250 needs backporting (fixed from 6.4rc1)
 
-# cpe-stable-backport: Backported in 5.15.145
-CVE_CHECK_IGNORE 

[OE-core][kirkstone 3/9] Revert "linux-yocto/5.15: update CVE exclusions"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit c7c86d97f6a0e1d09eaca999ecec13656655f299.
---
 .../linux/cve-exclusion_5.15.inc  | 44 +++
 1 file changed, 7 insertions(+), 37 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc 
b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
index 0d54b414d9..84d0becb8d 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2024-01-18 18:47:24.084935 for version 5.15.147
+# Generated at 2024-01-11 21:16:55.956074 for version 5.15.146
 
 python check_kernel_cve_status_version() {
-this_version = "5.15.147"
+this_version = "5.15.146"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
@@ -6626,9 +6626,6 @@ CVE_CHECK_IGNORE += "CVE-2022-48425"
 # cpe-stable-backport: Backported in 5.15.121
 CVE_CHECK_IGNORE += "CVE-2022-48502"
 
-# cpe-stable-backport: Backported in 5.15.42
-CVE_CHECK_IGNORE += "CVE-2022-48619"
-
 # fixed-version: Fixed after version 5.0rc1
 CVE_CHECK_IGNORE += "CVE-2023-0030"
 
@@ -6750,8 +6747,6 @@ CVE_CHECK_IGNORE += "CVE-2023-1382"
 # fixed-version: Fixed after version 5.11rc4
 CVE_CHECK_IGNORE += "CVE-2023-1390"
 
-# CVE-2023-1476 has no known resolution
-
 # cpe-stable-backport: Backported in 5.15.95
 CVE_CHECK_IGNORE += "CVE-2023-1513"
 
@@ -6926,8 +6921,7 @@ CVE_CHECK_IGNORE += "CVE-2023-23559"
 # fixed-version: Fixed after version 5.12rc1
 CVE_CHECK_IGNORE += "CVE-2023-23586"
 
-# fixed-version: only affects 5.18rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2023-2430"
+# CVE-2023-2430 needs backporting (fixed from 6.2rc5)
 
 # cpe-stable-backport: Backported in 5.15.105
 CVE_CHECK_IGNORE += "CVE-2023-2483"
@@ -7357,8 +7351,7 @@ CVE_CHECK_IGNORE += "CVE-2023-45871"
 # fixed-version: only affects 6.5rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-45898"
 
-# fixed-version: only affects 6.4rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2023-4610"
+# CVE-2023-4610 needs backporting (fixed from 6.4)
 
 # fixed-version: only affects 6.4rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-4611"
@@ -7393,8 +7386,7 @@ CVE_CHECK_IGNORE += "CVE-2023-5090"
 # cpe-stable-backport: Backported in 5.15.135
 CVE_CHECK_IGNORE += "CVE-2023-5158"
 
-# cpe-stable-backport: Backported in 5.15.146
-CVE_CHECK_IGNORE += "CVE-2023-51779"
+# CVE-2023-51779 needs backporting (fixed from 6.7rc7)
 
 # cpe-stable-backport: Backported in 5.15.137
 CVE_CHECK_IGNORE += "CVE-2023-5178"
@@ -7425,8 +7417,6 @@ CVE_CHECK_IGNORE += "CVE-2023-5972"
 
 # CVE-2023-6039 needs backporting (fixed from 6.5rc5)
 
-# CVE-2023-6040 needs backporting (fixed from 5.18rc1)
-
 # fixed-version: only affects 6.6rc3 onwards
 CVE_CHECK_IGNORE += "CVE-2023-6111"
 
@@ -7438,13 +7428,8 @@ CVE_CHECK_IGNORE += "CVE-2023-6176"
 
 # CVE-2023-6238 has no known resolution
 
-# CVE-2023-6270 has no known resolution
-
 # CVE-2023-6356 has no known resolution
 
-# fixed-version: only affects 6.1rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2023-6531"
-
 # CVE-2023-6535 has no known resolution
 
 # CVE-2023-6536 has no known resolution
@@ -7454,16 +7439,14 @@ CVE_CHECK_IGNORE += "CVE-2023-6546"
 
 # CVE-2023-6560 needs backporting (fixed from 6.7rc4)
 
-# cpe-stable-backport: Backported in 5.15.146
-CVE_CHECK_IGNORE += "CVE-2023-6606"
+# CVE-2023-6606 needs backporting (fixed from 6.7rc7)
 
 # CVE-2023-6610 needs backporting (fixed from 6.7rc7)
 
 # cpe-stable-backport: Backported in 5.15.143
 CVE_CHECK_IGNORE += "CVE-2023-6622"
 
-# fixed-version: only affects 6.7rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2023-6679"
+# CVE-2023-6679 needs backporting (fixed from 6.7rc6)
 
 # cpe-stable-backport: Backported in 5.15.143
 CVE_CHECK_IGNORE += "CVE-2023-6817"
@@ -7476,16 +7459,3 @@ CVE_CHECK_IGNORE += "CVE-2023-6932"
 
 # CVE-2023-7042 has no known resolution
 
-# cpe-stable-backport: Backported in 5.15.100
-CVE_CHECK_IGNORE += "CVE-2023-7192"
-
-# fixed-version: only affects 6.5rc6 onwards
-CVE_CHECK_IGNORE += "CVE-2024-0193"
-
-# CVE-2024-0340 needs backporting (fixed from 6.4rc6)
-
-# fixed-version: only affects 6.2rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2024-0443"
-
-# Skipping dd=CVE-2023-1476, no affected_versions
-
-- 
2.34.1


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



[OE-core][kirkstone 2/9] Revert "linux-yocto/5.15: update to v5.15.148"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit f1326d008a2a37b3860f25eb082efabdeba7cc32.
---
 .../linux/linux-yocto-rt_5.15.bb  |  6 ++---
 .../linux/linux-yocto-tiny_5.15.bb|  6 ++---
 meta/recipes-kernel/linux/linux-yocto_5.15.bb | 26 +--
 3 files changed, 19 insertions(+), 19 deletions(-)

diff --git a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
index 4578a1d819..e64f21b2f0 100644
--- a/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-rt_5.15.bb
@@ -11,13 +11,13 @@ python () {
 raise bb.parse.SkipRecipe("Set PREFERRED_PROVIDER_virtual/kernel to 
linux-yocto-rt to enable it")
 }
 
-SRCREV_machine ?= "198d85bb67700ac968a286cf7f89f008bb6eff39"
-SRCREV_meta ?= "c07c75a1e9438e70a80615cac0f48eb91d8f34ea"
+SRCREV_machine ?= "7168cfa2ce6492db31163393808806b6f48af5e8"
+SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
 
 SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;branch=${KBRANCH};name=machine \

git://git.yoctoproject.org/yocto-kernel-cache;type=kmeta;name=meta;branch=yocto-5.15;destsuffix=${KMETA}"
 
-LINUX_VERSION ?= "5.15.148"
+LINUX_VERSION ?= "5.15.147"
 
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
index 267ebb11c4..38bea23264 100644
--- a/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto-tiny_5.15.bb
@@ -5,7 +5,7 @@ KCONFIG_MODE = "--allnoconfig"
 
 require recipes-kernel/linux/linux-yocto.inc
 
-LINUX_VERSION ?= "5.15.148"
+LINUX_VERSION ?= "5.15.147"
 LIC_FILES_CHKSUM = "file://COPYING;md5=6bc538ed5bd9a7fc9398086aedcd7e46"
 
 DEPENDS += "${@bb.utils.contains('ARCH', 'x86', 'elfutils-native', '', d)}"
@@ -14,8 +14,8 @@ DEPENDS += "openssl-native util-linux-native"
 KMETA = "kernel-meta"
 KCONF_BSP_AUDIT_LEVEL = "2"
 
-SRCREV_machine ?= "0780801e81912c4bbd53b4fc01dad6df556739b6"
-SRCREV_meta ?= "c07c75a1e9438e70a80615cac0f48eb91d8f34ea"
+SRCREV_machine ?= "641e2136a155ce3179c84b9365a5998c1354fdd0"
+SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
 
 PV = "${LINUX_VERSION}+git${SRCPV}"
 
diff --git a/meta/recipes-kernel/linux/linux-yocto_5.15.bb 
b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
index 9a7c96b453..1acd7b62cd 100644
--- a/meta/recipes-kernel/linux/linux-yocto_5.15.bb
+++ b/meta/recipes-kernel/linux/linux-yocto_5.15.bb
@@ -14,24 +14,24 @@ KBRANCH:qemux86  ?= "v5.15/standard/base"
 KBRANCH:qemux86-64 ?= "v5.15/standard/base"
 KBRANCH:qemumips64 ?= "v5.15/standard/mti-malta64"
 
-SRCREV_machine:qemuarm ?= "c0150afdb5ca785c04acec22c7f42f42b044ca43"
-SRCREV_machine:qemuarm64 ?= "201f4f28b183815dbabda398e9ee90a2e628ad94"
-SRCREV_machine:qemumips ?= "1d82f42872b46d7f129bbe631931a09590d9d6bf"
-SRCREV_machine:qemuppc ?= "e985732d9de961b364b9bbf03ef3eba41adf8e37"
-SRCREV_machine:qemuriscv64 ?= "9bc0938c9f31f2f63b8e9d7b8f43671927858068"
-SRCREV_machine:qemuriscv32 ?= "9bc0938c9f31f2f63b8e9d7b8f43671927858068"
-SRCREV_machine:qemux86 ?= "9bc0938c9f31f2f63b8e9d7b8f43671927858068"
-SRCREV_machine:qemux86-64 ?= "9bc0938c9f31f2f63b8e9d7b8f43671927858068"
-SRCREV_machine:qemumips64 ?= "c87c9b74f382aba2886320ca29dd32544e53f15b"
-SRCREV_machine ?= "9bc0938c9f31f2f63b8e9d7b8f43671927858068"
-SRCREV_meta ?= "c07c75a1e9438e70a80615cac0f48eb91d8f34ea"
+SRCREV_machine:qemuarm ?= "82f8a25a3894c10d1cf26914b8e51726351ba11e"
+SRCREV_machine:qemuarm64 ?= "cf955e443d881e296b83940143fd30ea83fcf222"
+SRCREV_machine:qemumips ?= "1c3babd3b42768e24c797edfc3f67906aca6d072"
+SRCREV_machine:qemuppc ?= "b08998787bece69376578b049cab073d8b80e872"
+SRCREV_machine:qemuriscv64 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
+SRCREV_machine:qemuriscv32 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
+SRCREV_machine:qemux86 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
+SRCREV_machine:qemux86-64 ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
+SRCREV_machine:qemumips64 ?= "4ff2c0496c0160a96185a080ec9678c63b68bd47"
+SRCREV_machine ?= "5822f13dba3b1f460536d873aea707f4b25840cf"
+SRCREV_meta ?= "487de687c6a4553f11d67b83d01f16f79449ee49"
 
 # set your preferred provider of linux-yocto to 'linux-yocto-upstream', and 
you'll
 # get the /base branch, which is pure upstream -stable, and the same
 # meta SRCREV as the linux-yocto-standard builds. Select your version using the
 # normal PREFERRED_VERSION settings.
 BBCLASSEXTEND = "devupstream:target"
-SRCREV_machine:class-devupstream ?= "6139f2a02fe0ac7a08389b4eb786e0c659039ddd"
+SRCREV_machine:class-devupstream ?= "26c690eff0a56293e0b6911a38e406c211b35547"
 PN:class-devupstream = "linux-yocto-upstream"
 KBRANCH:class-devupstream = "v5.15/base"
 
@@ -39,7 +39,7 @@ SRC_URI = 
"git://git.yoctoproject.org/linux-yocto.git;name=machine;branch=${KBRA


[OE-core][kirkstone 1/9] Revert "linux-yocto/5.15: update CVE exclusions"

2024-03-07 Thread Steve Sakoman
This series is causing issues with adding and resizing partitions.

This reverts commit b71eeab71911ab49a8e8b8d78560fdbd66f883e7.
---
 .../linux/cve-exclusion_5.15.inc  | 91 ++-
 1 file changed, 6 insertions(+), 85 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc 
b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
index d33f2b3c7f..0d54b414d9 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2024-02-06 21:02:11.546853 for version 5.15.148
+# Generated at 2024-01-18 18:47:24.084935 for version 5.15.147
 
 python check_kernel_cve_status_version() {
-this_version = "5.15.148"
+this_version = "5.15.147"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
@@ -5299,12 +5299,6 @@ CVE_CHECK_IGNORE += "CVE-2021-3348"
 # fixed-version: Fixed after version 5.13rc7
 CVE_CHECK_IGNORE += "CVE-2021-33624"
 
-# fixed-version: Fixed after version 5.4rc1
-CVE_CHECK_IGNORE += "CVE-2021-33630"
-
-# cpe-stable-backport: Backported in 5.15.87
-CVE_CHECK_IGNORE += "CVE-2021-33631"
-
 # cpe-stable-backport: Backported in 5.15.54
 CVE_CHECK_IGNORE += "CVE-2021-33655"
 
@@ -6401,8 +6395,7 @@ CVE_CHECK_IGNORE += "CVE-2022-3635"
 # fixed-version: only affects 5.19 onwards
 CVE_CHECK_IGNORE += "CVE-2022-3640"
 
-# cpe-stable-backport: Backported in 5.15.129
-CVE_CHECK_IGNORE += "CVE-2022-36402"
+# CVE-2022-36402 has no known resolution
 
 # CVE-2022-3642 has no known resolution
 
@@ -7375,15 +7368,9 @@ CVE_CHECK_IGNORE += "CVE-2023-4611"
 # cpe-stable-backport: Backported in 5.15.132
 CVE_CHECK_IGNORE += "CVE-2023-4623"
 
-# cpe-stable-backport: Backported in 5.15.137
-CVE_CHECK_IGNORE += "CVE-2023-46343"
-
 # cpe-stable-backport: Backported in 5.15.137
 CVE_CHECK_IGNORE += "CVE-2023-46813"
 
-# cpe-stable-backport: Backported in 5.15.148
-CVE_CHECK_IGNORE += "CVE-2023-46838"
-
 # cpe-stable-backport: Backported in 5.15.140
 CVE_CHECK_IGNORE += "CVE-2023-46862"
 
@@ -7398,17 +7385,11 @@ CVE_CHECK_IGNORE += "CVE-2023-4881"
 # cpe-stable-backport: Backported in 5.15.132
 CVE_CHECK_IGNORE += "CVE-2023-4921"
 
-# CVE-2023-50431 needs backporting (fixed from 6.8rc1)
+# CVE-2023-50431 has no known resolution
 
 # fixed-version: only affects 6.0rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-5090"
 
-# cpe-stable-backport: Backported in 5.15.128
-CVE_CHECK_IGNORE += "CVE-2023-51042"
-
-# cpe-stable-backport: Backported in 5.15.121
-CVE_CHECK_IGNORE += "CVE-2023-51043"
-
 # cpe-stable-backport: Backported in 5.15.135
 CVE_CHECK_IGNORE += "CVE-2023-5158"
 
@@ -7430,9 +7411,6 @@ CVE_CHECK_IGNORE += "CVE-2023-51782"
 # cpe-stable-backport: Backported in 5.15.134
 CVE_CHECK_IGNORE += "CVE-2023-5197"
 
-# cpe-stable-backport: Backported in 5.15.147
-CVE_CHECK_IGNORE += "CVE-2023-52340"
-
 # fixed-version: only affects 6.1rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2023-5345"
 
@@ -7447,8 +7425,7 @@ CVE_CHECK_IGNORE += "CVE-2023-5972"
 
 # CVE-2023-6039 needs backporting (fixed from 6.5rc5)
 
-# cpe-stable-backport: Backported in 5.15.147
-CVE_CHECK_IGNORE += "CVE-2023-6040"
+# CVE-2023-6040 needs backporting (fixed from 5.18rc1)
 
 # fixed-version: only affects 6.6rc3 onwards
 CVE_CHECK_IGNORE += "CVE-2023-6111"
@@ -7459,9 +7436,6 @@ CVE_CHECK_IGNORE += "CVE-2023-6121"
 # cpe-stable-backport: Backported in 5.15.132
 CVE_CHECK_IGNORE += "CVE-2023-6176"
 
-# fixed-version: only affects 6.6rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2023-6200"
-
 # CVE-2023-6238 has no known resolution
 
 # CVE-2023-6270 has no known resolution
@@ -7494,9 +7468,6 @@ CVE_CHECK_IGNORE += "CVE-2023-6679"
 # cpe-stable-backport: Backported in 5.15.143
 CVE_CHECK_IGNORE += "CVE-2023-6817"
 
-# cpe-stable-backport: Backported in 5.15.148
-CVE_CHECK_IGNORE += "CVE-2023-6915"
-
 # cpe-stable-backport: Backported in 5.15.143
 CVE_CHECK_IGNORE += "CVE-2023-6931"
 
@@ -7516,55 +7487,5 @@ CVE_CHECK_IGNORE += "CVE-2024-0193"
 # fixed-version: only affects 6.2rc1 onwards
 CVE_CHECK_IGNORE += "CVE-2024-0443"
 
-# cpe-stable-backport: Backported in 5.15.64
-CVE_CHECK_IGNORE += "CVE-2024-0562"
-
-# CVE-2024-0564 has no known resolution
-
-# CVE-2024-0565 needs backporting (fixed from 6.7rc6)
-
-# fixed-version: only affects 6.4rc1 onwards
-CVE_CHECK_IGNORE += "CVE-2024-0582"
-
-# cpe-stable-backport: Backported in 5.15.142
-CVE_CHECK_IGNORE += "CVE-2024-0584"
-
-# cpe-stable-backport: Backported in 5.15.140
-CVE_CHECK_IGNORE += "CVE-2024-0607"
-
-# cpe-stable-backport: Backported in 5.15.121
-CVE_CHECK_IGNORE += "CVE-2024-0639"
-
-# cpe-stable-backport: Backported in 5.15.135
-CVE_CHECK_IGNORE += "CVE-2024-0641"
-
-# cpe-stable-backport: Backported in 5.15.147
-CVE_CHECK_IGNORE += "CVE-2024-0646"
-
-# cpe-stable-backport: 

[OE-core][kirkstone 0/9] Patch review

2024-03-07 Thread Steve Sakoman
Unfortunately this series of linux-yocto version bumps has caused a
number of issues with adding and resizing partitions.  The problem was
introduced in 5.15.132 and has not been fixed in any of the subsequent
version bumps.

Bruce and have decided to revert this series until we have an acceptable fix.

Please have any comments back by end of day Monday, March 11.

The following changes since commit e5aae8a371717215a7d78459788ad67dfaefe37e:

  golang: Fix CVE-2023-45289 & CVE-2023-45290 (2024-03-07 04:18:33 -1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/kirkstone-nut
  
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

Steve Sakoman (9):
  Revert "linux-yocto/5.15: update CVE exclusions"
  Revert "linux-yocto/5.15: update to v5.15.148"
  Revert "linux-yocto/5.15: update CVE exclusions"
  Revert "linux-yocto/5.15: update to v5.15.147"
  Revert "linux-yocto/5.15: update CVE exclusions"
  Revert "linux-yocto/5.15: update to v5.15.146"
  Revert "linux-yocto/5.15: update to v5.15.145"
  Revert "linux-yocto/5.15: update to v5.15.142"
  Revert "linux-yocto/5.15: update to v5.15.141"

 .../linux/cve-exclusion_5.15.inc  | 372 ++
 .../linux/linux-yocto-rt_5.15.bb  |   6 +-
 .../linux/linux-yocto-tiny_5.15.bb|   6 +-
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |  26 +-
 4 files changed, 57 insertions(+), 353 deletions(-)

-- 
2.34.1


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



Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Bruce Ashfield
Adding Kevin,

I'm not going to be able to debug this more for a week or so.

The alternate ways to fix it would be to try that ubuntu patch (fixed
for our tree), and / or see what else needs
to be cherry picked to -stable to fix util-linux. It is likely just a
return code difference to userspace when
resizing is being done.

Kevin: I'm not sure if Wind River is seeing this, but you might want to look
into those ptests and see if they pass on your end.

Bruce

On Thu, Mar 7, 2024 at 6:05 PM Steve Sakoman  wrote:
>
> Hi Bruce,
>
> This patch seems to fix the parted ptest problems, but now util-linux
> ptest is failing :-(
>
> Also seems to be partition resize related:
>
> AssertionError: Failed ptests:
> {'util-linux': ['fdisk:_gpt-resize']}
>
> Steve
>
> On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield  
> wrote:
> >
> > From: Bruce Ashfield 
> >
> > Signed-off-by: Bruce Ashfield 
> > ---
> >  ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
> >  ...-support-partitions-without-scanning.patch | 87 +++
> >  meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
> >  3 files changed, 134 insertions(+)
> >  create mode 100644 
> > meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> >  create mode 100644 
> > meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> >
> > diff --git 
> > a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> >  
> > b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> > new file mode 100644
> > index 00..cde4f317e9
> > --- /dev/null
> > +++ 
> > b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> > @@ -0,0 +1,43 @@
> > +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
> > +From: Ming Lei 
> > +Date: Tue, 23 Aug 2022 18:38:19 +0800
> > +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is 
> > set
> > +
> > +Commit b9684a71fca7 ("block, loop: support partitions without scanning")
> > +adds GD_SUPPRESS_PART_SCAN for replacing part function of
> > +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
> > +loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
> > +And it causes regression on libblockdev (as called from udisks) which
> > +operates with the LO_FLAGS_PARTSCAN.
> > +
> > +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
> > +set.
> > +
> > +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
> > +
> > +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
> > +Signed-off-by: Ming Lei 
> > +Reviewed-by: Christoph Hellwig 
> > +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
> > +Signed-off-by: Jens Axboe 
> > +---
> > + block/partitions/core.c | 3 +++
> > + 1 file changed, 3 insertions(+)
> > +
> > +diff --git a/block/partitions/core.c b/block/partitions/core.c
> > +index fc1d70384825..b8112f52d388 100644
> > +--- a/block/partitions/core.c
> >  b/block/partitions/core.c
> > +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
> > +   if (disk->flags & GENHD_FL_NO_PART)
> > +   return 0;
> > +
> > ++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
> > ++  return 0;
> > ++
> > +   state = check_partition(disk);
> > +   if (!state)
> > +   return 0;
> > +--
> > +2.39.2
> > +
> > diff --git 
> > a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> >  
> > b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> > new file mode 100644
> > index 00..9522c2d2cc
> > --- /dev/null
> > +++ 
> > b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> > @@ -0,0 +1,87 @@
> > +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
> > +From: Christoph Hellwig 
> > +Date: Fri, 27 May 2022 07:58:06 +0200
> > +Subject: [PATCH] block, loop: support partitions without scanning
> > +
> > +Historically we did distinguish between a flag that surpressed partition
> > +scanning, and a combinations of the minors variable and another flag if
> > +any partitions were supported.  This was generally confusing and doesn't
> > +make much sense, but some corner case uses of the loop driver actually
> > +do want to support manually added partitions on a device that does not
> > +actively scan for partitions.  To make things worsee the loop driver
> > +also wants to dynamically toggle the scanning for partitions on a live
> > +gendisk, which makes the disk->flags updates non-atomic.
> > +
> > +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
> > +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
> > +in the loop driver.
> > +
> > +Upstream-Status: 

Re: [OE-core] [PATCH 1/3] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Steve Sakoman
Hi Bruce,

This patch seems to fix the parted ptest problems, but now util-linux
ptest is failing :-(

Also seems to be partition resize related:

AssertionError: Failed ptests:
{'util-linux': ['fdisk:_gpt-resize']}

Steve

On Thu, Mar 7, 2024 at 9:34 AM Bruce Ashfield  wrote:
>
> From: Bruce Ashfield 
>
> Signed-off-by: Bruce Ashfield 
> ---
>  ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
>  ...-support-partitions-without-scanning.patch | 87 +++
>  meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
>  3 files changed, 134 insertions(+)
>  create mode 100644 
> meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
>  create mode 100644 
> meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
>
> diff --git 
> a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
>  
> b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> new file mode 100644
> index 00..cde4f317e9
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
> @@ -0,0 +1,43 @@
> +From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
> +From: Ming Lei 
> +Date: Tue, 23 Aug 2022 18:38:19 +0800
> +Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set
> +
> +Commit b9684a71fca7 ("block, loop: support partitions without scanning")
> +adds GD_SUPPRESS_PART_SCAN for replacing part function of
> +GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
> +loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
> +And it causes regression on libblockdev (as called from udisks) which
> +operates with the LO_FLAGS_PARTSCAN.
> +
> +Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
> +set.
> +
> +Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
> +
> +Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
> +Signed-off-by: Ming Lei 
> +Reviewed-by: Christoph Hellwig 
> +Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
> +Signed-off-by: Jens Axboe 
> +---
> + block/partitions/core.c | 3 +++
> + 1 file changed, 3 insertions(+)
> +
> +diff --git a/block/partitions/core.c b/block/partitions/core.c
> +index fc1d70384825..b8112f52d388 100644
> +--- a/block/partitions/core.c
>  b/block/partitions/core.c
> +@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
> +   if (disk->flags & GENHD_FL_NO_PART)
> +   return 0;
> +
> ++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
> ++  return 0;
> ++
> +   state = check_partition(disk);
> +   if (!state)
> +   return 0;
> +--
> +2.39.2
> +
> diff --git 
> a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
>  
> b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> new file mode 100644
> index 00..9522c2d2cc
> --- /dev/null
> +++ 
> b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
> @@ -0,0 +1,87 @@
> +From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
> +From: Christoph Hellwig 
> +Date: Fri, 27 May 2022 07:58:06 +0200
> +Subject: [PATCH] block, loop: support partitions without scanning
> +
> +Historically we did distinguish between a flag that surpressed partition
> +scanning, and a combinations of the minors variable and another flag if
> +any partitions were supported.  This was generally confusing and doesn't
> +make much sense, but some corner case uses of the loop driver actually
> +do want to support manually added partitions on a device that does not
> +actively scan for partitions.  To make things worsee the loop driver
> +also wants to dynamically toggle the scanning for partitions on a live
> +gendisk, which makes the disk->flags updates non-atomic.
> +
> +Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
> +just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
> +in the loop driver.
> +
> +Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1]
> +
> +Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
> +Reported-by: Ming Lei 
> +Signed-off-by: Christoph Hellwig 
> +Reviewed-by: Ming Lei 
> +Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
> +Signed-off-by: Jens Axboe 
> +Signed-off-by: Bruce Ashfield 
> +---
> + drivers/block/loop.c   | 8 
> + include/linux/blkdev.h | 1 +
> + 2 files changed, 5 insertions(+), 4 deletions(-)
> +
> +diff --git a/drivers/block/loop.c b/drivers/block/loop.c
> +index 4769caab9ff9..a76302450c46 100644
> +--- a/drivers/block/loop.c
>  b/drivers/block/loop.c
> +@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, 
> fmode_t mode,
> +  

[OE-core] [PATCH] layer.conf: Prepare for release, drop nanbield LAYERSERIES

2024-03-07 Thread Richard Purdie
As we're close to release, drop compatibility to nanbield, people
have had time to switch now.

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

diff --git a/meta/conf/layer.conf b/meta/conf/layer.conf
index 2418ee7d53b..62f86f361ad 100644
--- a/meta/conf/layer.conf
+++ b/meta/conf/layer.conf
@@ -7,7 +7,7 @@ BBFILE_COLLECTIONS += "core"
 BBFILE_PATTERN_core = "^${LAYERDIR}/"
 BBFILE_PRIORITY_core = "5"
 
-LAYERSERIES_CORENAMES = "nanbield scarthgap"
+LAYERSERIES_CORENAMES = "scarthgap"
 
 # This should only be incremented on significant changes that will
 # cause compatibility issues with other layers
-- 
2.40.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196824): 
https://lists.openembedded.org/g/openembedded-core/message/196824
Mute This Topic: https://lists.openembedded.org/mt/104798280/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] openssh: enable sshd.service by default

2024-03-07 Thread Emil Kronborg via lists.openembedded.org
Socket activation is prone to DoS (denial of service) because too many
connections will permanently deactivate sshd.socket [1]. Also, since
socket units do not allow setting Restart, accepting new connections can
fail due to, for example, OOM (out of memory) [2]. Therefore, it seems
more sensible to use sshd.service by default and let sshd.socket be an
optional choice.

[1] https://bugs.archlinux.org/task/62248
[2] https://github.com/systemd/systemd/issues/11553

Signed-off-by: Emil Kronborg 
---
 meta/recipes-connectivity/openssh/openssh_9.6p1.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-connectivity/openssh/openssh_9.6p1.bb 
b/meta/recipes-connectivity/openssh/openssh_9.6p1.bb
index 1fd36a266fde..a21570ed9382 100644
--- a/meta/recipes-connectivity/openssh/openssh_9.6p1.bb
+++ b/meta/recipes-connectivity/openssh/openssh_9.6p1.bb
@@ -57,7 +57,7 @@ DEPENDS += "${@bb.utils.contains('DISTRO_FEATURES', 
'systemd', 'systemd', '', d)
 
 # systemd-sshd-socket-mode means installing sshd.socket
 # and systemd-sshd-service-mode corresponding to sshd.service
-PACKAGECONFIG ??= "systemd-sshd-socket-mode"
+PACKAGECONFIG ??= "systemd-sshd-service-mode"
 PACKAGECONFIG[kerberos] = "--with-kerberos5,--without-kerberos5,krb5"
 PACKAGECONFIG[ldns] = "--with-ldns,--without-ldns,ldns"
 PACKAGECONFIG[libedit] = "--with-libedit,--without-libedit,libedit"
-- 
2.44.0



-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196823): 
https://lists.openembedded.org/g/openembedded-core/message/196823
Mute This Topic: https://lists.openembedded.org/mt/104795507/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] linux-yocto/5.15: update to v5.15.150

2024-03-07 Thread Bruce Ashfield
From: Bruce Ashfield 

Updating linux-yocto/5.15 to the latest korg -stable release that comprises
the following commits:

80efc6265290 Linux 5.15.150
da6cabc1981e r8169: use new PM macros
b7f3fac6d301 netfilter: nf_tables: can't schedule in nft_chain_validate
a4efc62cd1ed ext4: avoid bb_free and bb_fragments inconsistency in 
mb_free_blocks()
c1317822e2de ext4: regenerate buddy after block freeing failed if under fc 
replay
d82ec7529c5f netfilter: nf_tables: fix scheduling-while-atomic splat
97eaa2955db4 arp: Prevent overflow in arp_req_get().
d7b6fa97ec89 fs/aio: Restrict kiocb_set_cancel_fn() to I/O submitted via 
libaio
df31d05f0678 cifs: fix mid leak during reconnection after timeout threshold
aade859419ce i2c: imx: when being a target, mark the last read as processed
cb21407f0b39 i2c: imx: Add timer for handling the stop condition
33f649f1b1ce drm/amd/display: Fix memory leak in dm_sw_fini()
9a03126588e5 drm/syncobj: call drm_syncobj_fence_add_wait when 
WAIT_AVAILABLE flag is set
13b57b5cd591 netfilter: nft_flow_offload: release dst in case direct xmit 
path is used
4c167af9f6b5 netfilter: nft_flow_offload: reset dst in route object after 
setting up flow
7c71b831220e netfilter: flowtable: simplify route logic
664264a5c55b netfilter: nf_tables: set dormant flag on hook register failure
4338032aa90b tls: stop recv() if initial process_rx_list gave us non-DATA
ea845237a39d tls: rx: drop pointless else after goto
8b32e43a80a1 tls: rx: jump to a more appropriate label
39603a6d4e71 s390: use the correct count for __iowrite64_copy()
8cae520f21ad octeontx2-af: Consider the action set by PF
6dae096960bc drm/nouveau/instmem: fix uninitialized_var.cocci warning
4d3b2bd995ed net: dev: Convert sa_data to flexible array in struct sockaddr
d65ec3e48f70 packet: move from strlcpy with unused retval to strscpy
91b020aaa1e5 ipv6: sr: fix possible use-after-free and null-ptr-deref
e56662160fc2 afs: Increase buffer size in afs_update_volume_status()
5268bb02107b bpf: Fix racing between bpf_timer_cancel_and_free and 
bpf_timer_cancel
6800ad7417f3 ata: ahci_ceva: fix error handling for Xilinx GT PHY support
7fcc31a3a705 ata: libahci_platform: Introduce reset assertion/deassertion 
methods
ddac2e0e656e ata: libahci_platform: Convert to using devm bulk clocks API
302b92b37304 ipv6: properly combine dev_base_seq and ipv6.dev_addr_genid
a75b49547831 ipv4: properly combine dev_base_seq and ipv4.dev_addr_genid
2a7b878a7dad net: stmmac: Fix incorrect dereference in interrupt handlers
a41d9142d2dd nouveau: fix function cast warnings
1087c284fd11 scsi: jazz_esp: Only build if SCSI core is builtin
4e395fb89e7e bpf, scripts: Correct GPL license name
cd6070d9f5e7 RDMA/srpt: fix function pointer cast warnings
656bd1702fea arm64: dts: rockchip: set num-cs property for spi on px30
135e5465fefa RDMA/qedr: Fix qedr_create_user_qp error flow
989af2f29342 RDMA/srpt: Support specifying the srpt_service_guid parameter
b6e660e07622 RDMA/irdma: Add AE for too many RNRS
056ed95befd1 RDMA/irdma: Set the CQ read threshold for GEN 1
a95d4cf82775 RDMA/irdma: Validate max_send_wr and max_recv_wr
635d79aa477f RDMA/irdma: Fix KASAN issue with tasklet
aeb5ac1c9d10 RDMA/bnxt_re: Return error for SRQ resize
52de5805c147 IB/hfi1: Fix a memleak in init_credit_return
48c63a174489 cifs: add a warning when the in-flight count goes negative
6538b6d13ce3 xhci: track port suspend state correctly in unsuccessful 
resume cases
8839d5728baa xhci: decouple usb2 port resume and get_port_status request 
handling
8af9de2a5ba1 xhci: clear usb2 resume related variables in one place.
a99c8f1abef9 xhci: rename resume_done to resume_timestamp
63f0e79cf382 xhci: move port specific items such as state completions to 
port structure
ea6c19c7365d xhci: cleanup xhci_hub_control port references
95973afc870c ACPI: resource: Skip IRQ override on ASUS ExpertBook B1502CBA
4f080b6487bd ACPI: resource: Skip IRQ override on Asus Expertbook B2402CBA
c2a9376d507e ACPI: resource: Add Asus ExpertBook B2502 to Asus quirks
1b64ff947a5a ACPI: resource: Skip IRQ override on Asus Vivobook S5602ZA
f3607954f2e6 ACPI: resource: Add ASUS model S5402ZA to quirks
27e99d785721 ACPI: video: Add backlight=native DMI quirk for Apple iMac12,1 
and iMac12,2
cb1003c07e74 ARM: dts: BCM53573: Describe on-SoC BCM53125 rev 4 switch
28e5e3e59b3b arm64: dts: rockchip: add SPDIF node for ROCK Pi 4
99c8b2e99783 arm64: dts: rockchip: add ES8316 codec for ROCK Pi 4
371036bf7666 arm64: dts: rockchip: fix regulator name on rk3399-rock-4
92dcd7d6c606 exfat: support dynamic allocate bh for exfat_entry_set_cache
b4dc693b29ef wifi: iwlwifi: mvm: avoid baid size integer overflow
fa92c463eba7 igb: Fix igb_down hung on surprise removal
16f653776caf wifi: 

[OE-core] [PATCH 3/3] linux-yocto/5.15: update CVE exclusions

2024-03-07 Thread Bruce Ashfield
From: Bruce Ashfield 

Data pulled from: https://github.com/nluedtke/linux_kernel_cves

1/1 [
Author: Nicholas Luedtke
Email: nicholas.lued...@uwalumni.com
Subject: Update 25Feb24
Date: Sun, 25 Feb 2024 07:03:08 -0500

]

Signed-off-by: Bruce Ashfield 
---
 meta/recipes-kernel/linux/cve-exclusion_5.15.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc 
b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
index 2e30efe6be..7cabb1e244 100644
--- a/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
+++ b/meta/recipes-kernel/linux/cve-exclusion_5.15.inc
@@ -1,9 +1,9 @@
 
 # Auto-generated CVE metadata, DO NOT EDIT BY HAND.
-# Generated at 2024-02-26 23:36:34.200936 for version 5.15.149
+# Generated at 2024-03-07 14:18:47.385549 for version 5.15.150
 
 python check_kernel_cve_status_version() {
-this_version = "5.15.149"
+this_version = "5.15.150"
 kernel_version = d.getVar("LINUX_VERSION")
 if kernel_version != this_version:
 bb.warn("Kernel CVE status needs updating: generated for %s but kernel 
is %s" % (this_version, kernel_version))
-- 
2.39.2


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196822): 
https://lists.openembedded.org/g/openembedded-core/message/196822
Mute This Topic: https://lists.openembedded.org/mt/104794846/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] linux-yocto: for-test-only: fix parted ptest

2024-03-07 Thread Bruce Ashfield
From: Bruce Ashfield 

Signed-off-by: Bruce Ashfield 
---
 ...partitions-if-GD_SUPPRESS_PART_SCAN-.patch | 43 +
 ...-support-partitions-without-scanning.patch | 87 +++
 meta/recipes-kernel/linux/linux-yocto_5.15.bb |  4 +
 3 files changed, 134 insertions(+)
 create mode 100644 
meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
 create mode 100644 
meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch

diff --git 
a/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
 
b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
new file mode 100644
index 00..cde4f317e9
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-block-don-t-add-partitions-if-GD_SUPPRESS_PART_SCAN-.patch
@@ -0,0 +1,43 @@
+From 748008e1da926a814cc0a054c81ca614408b1b0c Mon Sep 17 00:00:00 2001
+From: Ming Lei 
+Date: Tue, 23 Aug 2022 18:38:19 +0800
+Subject: [PATCH] block: don't add partitions if GD_SUPPRESS_PART_SCAN is set
+
+Commit b9684a71fca7 ("block, loop: support partitions without scanning")
+adds GD_SUPPRESS_PART_SCAN for replacing part function of
+GENHD_FL_NO_PART. But looks blk_add_partitions() is missed, since
+loop doesn't want to add partitions if GENHD_FL_NO_PART was set.
+And it causes regression on libblockdev (as called from udisks) which
+operates with the LO_FLAGS_PARTSCAN.
+
+Fixes the issue by not adding partitions if GD_SUPPRESS_PART_SCAN is
+set.
+
+Upstream-Status: Backport [748008e1da926a814cc0a054c81ca614408b1b0c]
+
+Fixes: b9684a71fca7 ("block, loop: support partitions without scanning")
+Signed-off-by: Ming Lei 
+Reviewed-by: Christoph Hellwig 
+Link: https://lore.kernel.org/r/20220823103819.395776-1-ming@redhat.com
+Signed-off-by: Jens Axboe 
+---
+ block/partitions/core.c | 3 +++
+ 1 file changed, 3 insertions(+)
+
+diff --git a/block/partitions/core.c b/block/partitions/core.c
+index fc1d70384825..b8112f52d388 100644
+--- a/block/partitions/core.c
 b/block/partitions/core.c
+@@ -596,6 +596,9 @@ static int blk_add_partitions(struct gendisk *disk)
+   if (disk->flags & GENHD_FL_NO_PART)
+   return 0;
+ 
++  if (test_bit(GD_SUPPRESS_PART_SCAN, >state))
++  return 0;
++
+   state = check_partition(disk);
+   if (!state)
+   return 0;
+-- 
+2.39.2
+
diff --git 
a/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
new file mode 100644
index 00..9522c2d2cc
--- /dev/null
+++ 
b/meta/recipes-kernel/linux/files/0001-block-loop-support-partitions-without-scanning.patch
@@ -0,0 +1,87 @@
+From ea6bf87558eb534ded532cfa622b575c1f39e3d6 Mon Sep 17 00:00:00 2001
+From: Christoph Hellwig 
+Date: Fri, 27 May 2022 07:58:06 +0200
+Subject: [PATCH] block, loop: support partitions without scanning
+
+Historically we did distinguish between a flag that surpressed partition
+scanning, and a combinations of the minors variable and another flag if
+any partitions were supported.  This was generally confusing and doesn't
+make much sense, but some corner case uses of the loop driver actually
+do want to support manually added partitions on a device that does not
+actively scan for partitions.  To make things worsee the loop driver
+also wants to dynamically toggle the scanning for partitions on a live
+gendisk, which makes the disk->flags updates non-atomic.
+
+Introduce a new GD_SUPPRESS_PART_SCAN bit in disk->state that disables
+just scanning for partitions, and toggle that instead of GENHD_FL_NO_PART
+in the loop driver.
+
+Upstream-Status: Backport [b9684a71fca793213378dd410cd11675d973eaa1]
+
+Fixes: 1ebe2e5f9d68 ("block: remove GENHD_FL_EXT_DEVT")
+Reported-by: Ming Lei 
+Signed-off-by: Christoph Hellwig 
+Reviewed-by: Ming Lei 
+Link: https://lore.kernel.org/r/20220527055806.1972352-1-...@lst.de
+Signed-off-by: Jens Axboe 
+Signed-off-by: Bruce Ashfield 
+---
+ drivers/block/loop.c   | 8 
+ include/linux/blkdev.h | 1 +
+ 2 files changed, 5 insertions(+), 4 deletions(-)
+
+diff --git a/drivers/block/loop.c b/drivers/block/loop.c
+index 4769caab9ff9..a76302450c46 100644
+--- a/drivers/block/loop.c
 b/drivers/block/loop.c
+@@ -1332,7 +1332,7 @@ static int loop_configure(struct loop_device *lo, 
fmode_t mode,
+   lo->lo_flags |= LO_FLAGS_PARTSCAN;
+   partscan = lo->lo_flags & LO_FLAGS_PARTSCAN;
+   if (partscan)
+-  lo->lo_disk->flags &= ~GENHD_FL_NO_PART;
++  clear_bit(GD_SUPPRESS_PART_SCAN, >lo_disk->state);
+ 
+   /* enable and uncork uevent now that we are done */
+   dev_set_uevent_suppress(disk_to_dev(lo->lo_disk), 0);
+@@ -1481,7 +1481,7 @@ static int __loop_clr_fd(struct loop_device *lo, bool 
release)
+   mutex_lock(>lo_mutex);
+   lo->lo_flags = 0;
+ 

Re: [OE-core] [PATCH 22/47] libxml2: upgrade 2.11.5 -> 2.12.5

2024-03-07 Thread Khem Raj
libosinfo fails due to this upgrade

https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3691/steps/14/logs/stdio

On Wed, Mar 6, 2024 at 7:42 AM Alexander Kanavin  wrote:
>
> License-Update: hash.c is rewritten and no longer carries a special copyright 
> notice, but dict.c still does
> (Copyright file updated to reflect that)
>
> Signed-off-by: Alexander Kanavin 
> ---
>  meta/recipes-core/libxml/libxml2/install-tests.patch | 9 -
>  .../libxml/{libxml2_2.11.5.bb => libxml2_2.12.5.bb}  | 9 +
>  2 files changed, 9 insertions(+), 9 deletions(-)
>  rename meta/recipes-core/libxml/{libxml2_2.11.5.bb => libxml2_2.12.5.bb} 
> (92%)
>
> diff --git a/meta/recipes-core/libxml/libxml2/install-tests.patch 
> b/meta/recipes-core/libxml/libxml2/install-tests.patch
> index 14ccce5873b..478eeea81b1 100644
> --- a/meta/recipes-core/libxml/libxml2/install-tests.patch
> +++ b/meta/recipes-core/libxml/libxml2/install-tests.patch
> @@ -1,4 +1,4 @@
> -From 3fc716357ce1372d9418dc86f24315b34d9808de Mon Sep 17 00:00:00 2001
> +From 0779511838a8cbd1e0f431c22f28f286a2a37b1b Mon Sep 17 00:00:00 2001
>  From: Ross Burton 
>  Date: Mon, 5 Dec 2022 17:02:32 +
>  Subject: [PATCH] add yocto-specific install-ptest target
> @@ -7,17 +7,16 @@ Add a target to install the test suite.
>
>  Upstream-Status: Inappropriate
>  Signed-off-by: Ross Burton 
> -
>  ---
>   Makefile.am | 10 ++
>   1 file changed, 10 insertions(+)
>
>  diff --git a/Makefile.am b/Makefile.am
> -index 5bc4018..57d27af 100644
> +index 0a49d37..1097c63 100644
>  --- a/Makefile.am
>  +++ b/Makefile.am
> -@@ -26,6 +26,16 @@ check_PROGRAMS = \
> -   testlimits \
> +@@ -27,6 +27,16 @@ check_PROGRAMS = \
> +   testparser \
> testrecurse
>
>  +ptestdir=$(libexecdir)
> diff --git a/meta/recipes-core/libxml/libxml2_2.11.5.bb 
> b/meta/recipes-core/libxml/libxml2_2.12.5.bb
> similarity index 92%
> rename from meta/recipes-core/libxml/libxml2_2.11.5.bb
> rename to meta/recipes-core/libxml/libxml2_2.12.5.bb
> index 44336c25e1c..47c1a72e77e 100644
> --- a/meta/recipes-core/libxml/libxml2_2.11.5.bb
> +++ b/meta/recipes-core/libxml/libxml2_2.12.5.bb
> @@ -4,10 +4,11 @@ HOMEPAGE = "https://gitlab.gnome.org/GNOME/libxml2;
>  BUGTRACKER = "http://bugzilla.gnome.org/buglist.cgi?product=libxml2;
>  SECTION = "libs"
>  LICENSE = "MIT"
> -LIC_FILES_CHKSUM = "file://Copyright;md5=2044417e2e5006b65a8b9067b683fcf1 \
> -
> file://hash.c;beginline=6;endline=15;md5=e77f77b12cb69e203d8b4090a0eee879 \
> +LIC_FILES_CHKSUM = "file://Copyright;md5=fec7ecfe714722b2bb0aaff7d200c701 \
> +
> file://dict.c;beginline=6;endline=15;md5=2b4b7b827d2d8b080372433c4c9c85b6 \
>  
> file://list.c;beginline=4;endline=13;md5=b9c25b021ccaf287e50060602d20f3a7 \
> -
> file://trio.c;beginline=5;endline=14;md5=cd4f61e27f88c1d43df112966b1cd28f"
> +
> file://trio.c;beginline=5;endline=14;md5=cd4f61e27f88c1d43df112966b1cd28f \
> +"
>
>  DEPENDS = "zlib virtual/libiconv"
>
> @@ -19,7 +20,7 @@ SRC_URI += 
> "http://www.w3.org/XML/Test/xmlts20130923.tar;subdir=${BP};name=testt
> file://install-tests.patch \
> "
>
> -SRC_URI[archive.sha256sum] = 
> "3727b078c360ec69fa869de14bd6f75d7ee8d36987b071e6928d4720a28df3a6"
> +SRC_URI[archive.sha256sum] = 
> "a972796696afd38073e0f59c283c3a2f5a560b5268b4babc391b286166526b21"
>  SRC_URI[testtar.sha256sum] = 
> "c6b2d42ee50b8b236e711a97d68e6c4b5c8d83e69a2be4722379f08702ea7273"
>
>  # Disputed as a security issue, but fixed in d39f780
> --
> 2.39.2
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196819): 
https://lists.openembedded.org/g/openembedded-core/message/196819
Mute This Topic: https://lists.openembedded.org/mt/104767962/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] systemd: Check for directory before chmod'ing it

2024-03-07 Thread Khem Raj
da9db878a15 systemd: fix dead link /var/log/README
add -Dcreate-log-dirs=false which means journal dir
will not be generated regardless of VOLATILE_LOG_DIR value
if a distro decided to set VOLATILE_LOG_DIR=no this
code path will be executes and the directory being operated
upon wont exist ending in do_install errors

chown: cannot access 
'/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/systemd/255.4/image/var/log/journal':
 No such file or directory

Signed-off-by: Khem Raj 
Cc: Changqing Li 
---
 meta/recipes-core/systemd/systemd_255.4.bb | 2 +-
 1 file changed, 1 insertion(+), 1 deletion(-)

diff --git a/meta/recipes-core/systemd/systemd_255.4.bb 
b/meta/recipes-core/systemd/systemd_255.4.bb
index d59ca30c12f..bcef3e6b7ac 100644
--- a/meta/recipes-core/systemd/systemd_255.4.bb
+++ b/meta/recipes-core/systemd/systemd_255.4.bb
@@ -306,7 +306,7 @@ do_install() {
# /var/log is typically a symbolic link to inside /var/volatile,
# which is expected to be empty.
rm -rf ${D}${localstatedir}/log
-   else
+   elif [ -e ${D}${localstatedir}/log/journal ]; then
chown root:systemd-journal ${D}${localstatedir}/log/journal
 
# journal-remote creates this at start
-- 
2.44.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196818): 
https://lists.openembedded.org/g/openembedded-core/message/196818
Mute This Topic: https://lists.openembedded.org/mt/104794378/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 v3] bmaptool: Add bmap-tools runtime alias for compatibility

2024-03-07 Thread Tom Hochstein
The rename of bmap-tools to bmaptool creates an incompatibility that
will break package feeds. Restore package feed compatibility by adding
a bmap-tools runtime alias.

Acked-by: Otavio Salvador 
Signed-off-by: Tom Hochstein 
---
 meta/recipes-support/bmaptool/bmaptool_git.bb | 4 
 1 file changed, 4 insertions(+)

diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb 
b/meta/recipes-support/bmaptool/bmaptool_git.bb
index 87328af8c6..f706477323 100644
--- a/meta/recipes-support/bmaptool/bmaptool_git.bb
+++ b/meta/recipes-support/bmaptool/bmaptool_git.bb
@@ -28,4 +28,8 @@ RDEPENDS:${PN} = "python3-core python3-compression 
python3-misc python3-mmap pyt
 
 inherit setuptools3
 
+# For compatibility with layers before scarthgap
+RREPLACES:${PN} = "bmap-tools"
+RCONFLICTS:${PN} = "bmap-tools"
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.25.1


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



Patchtest results for [OE-core][kirkstone 3/4] selftest: skip virgl gtk/sdl test on ubuntu 18.04

2024-03-07 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/kirkstone-3-4-selftest-skip-virgl-gtk-sdl-test-on-ubuntu-18.04.patch

FAIL: test commit message presence: Please include a commit message on your 
patch explaining the change (test_mbox.TestMbox.test_commit_message_presence)

PASS: pretest pylint (test_python_pylint.PyLint.pretest_pylint)
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 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 pylint (test_python_pylint.PyLint.test_pylint)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)

SKIP: pretest src uri left files: No modified recipes, skipping pretest 
(test_metadata.TestMetadata.pretest_src_uri_left_files)
SKIP: test CVE check ignore: No modified recipes or older target branch, 
skipping test (test_metadata.TestMetadata.test_cve_check_ignore)
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 modified not mentioned: No modified recipes, 
skipping test 
(test_metadata.TestMetadata.test_lic_files_chksum_modified_not_mentioned)
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 series merge on head: Merge test is disabled for now 
(test_mbox.TestMbox.test_series_merge_on_head)
SKIP: test src uri left files: No modified recipes, skipping pretest 
(test_metadata.TestMetadata.test_src_uri_left_files)
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 (#196816): 
https://lists.openembedded.org/g/openembedded-core/message/196816
Mute This Topic: https://lists.openembedded.org/mt/104793919/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub 
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-



[OE-core][kirkstone 4/4] golang: Fix CVE-2023-45289 & CVE-2023-45290

2024-03-07 Thread Steve Sakoman
From: Hitendra Prajapati 

Backport fixes for:
CVE-2023-45289 - Upstream-Status: Backport from 
https://github.com/golang/go/commit/3a855208e3efed2e9d7c20ad023f1fa78afcc0be
CVE-2023-45290 - Upstream-Status: Backport from 
https://github.com/golang/go/commit/041a47712e765e94f86d841c3110c840e76d8f82

Signed-off-by: Hitendra Prajapati 
Signed-off-by: Steve Sakoman 
---
 meta/recipes-devtools/go/go-1.17.13.inc   |   2 +
 .../go/go-1.21/CVE-2023-45289.patch   | 121 
 .../go/go-1.21/CVE-2023-45290.patch   | 270 ++
 3 files changed, 393 insertions(+)
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-45290.patch

diff --git a/meta/recipes-devtools/go/go-1.17.13.inc 
b/meta/recipes-devtools/go/go-1.17.13.inc
index c02da60f68..e635445579 100644
--- a/meta/recipes-devtools/go/go-1.17.13.inc
+++ b/meta/recipes-devtools/go/go-1.17.13.inc
@@ -51,6 +51,8 @@ SRC_URI += "\
 file://CVE-2023-39326.patch \
 file://CVE-2023-45285.patch \
 file://CVE-2023-45287.patch \
+file://CVE-2023-45289.patch \
+file://CVE-2023-45290.patch \
 "
 SRC_URI[main.sha256sum] = 
"a1a48b23afb206f95e7bbaa9b898d965f90826f6f1d1fc0c1d784ada0cd300fd"
 
diff --git a/meta/recipes-devtools/go/go-1.21/CVE-2023-45289.patch 
b/meta/recipes-devtools/go/go-1.21/CVE-2023-45289.patch
new file mode 100644
index 00..f8ac64472f
--- /dev/null
+++ b/meta/recipes-devtools/go/go-1.21/CVE-2023-45289.patch
@@ -0,0 +1,121 @@
+From 3a855208e3efed2e9d7c20ad023f1fa78afcc0be Mon Sep 17 00:00:00 2001
+From: Damien Neil 
+Date: Thu, 11 Jan 2024 11:31:57 -0800
+Subject: [PATCH] [release-branch.go1.22] net/http, net/http/cookiejar: avoid
+ subdomain matches on IPv6 zones
+
+When deciding whether to forward cookies or sensitive headers
+across a redirect, do not attempt to interpret an IPv6 address
+as a domain name.
+
+Avoids a case where a maliciously-crafted redirect to an
+IPv6 address with a scoped addressing zone could be
+misinterpreted as a within-domain redirect. For example,
+we could interpret "::1%.www.example.com" as a subdomain
+of "www.example.com".
+
+Thanks to Juho Nurminen of Mattermost for reporting this issue.
+
+Fixes CVE-2023-45289
+Fixes #65859
+For #65065
+
+Change-Id: I8f463f59f0e700c8a18733d2b264a8bcb3a19599
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2131938
+Reviewed-by: Tatiana Bradley 
+Reviewed-by: Roland Shoemaker 
+Reviewed-on: 
https://team-review.git.corp.google.com/c/golang/go-private/+/2174344
+Reviewed-by: Carlos Amedee 
+Reviewed-on: https://go-review.googlesource.com/c/go/+/569236
+Reviewed-by: Carlos Amedee 
+LUCI-TryBot-Result: Go LUCI 

+Auto-Submit: Michael Knyszek 
+
+Upstream-Status: Backport 
[https://github.com/golang/go/commit/3a855208e3efed2e9d7c20ad023f1fa78afcc0be]
+CVE: CVE-2023-45289
+Signed-off-by: Hitendra Prajapati 
+---
+ src/net/http/client.go |  6 ++
+ src/net/http/client_test.go|  1 +
+ src/net/http/cookiejar/jar.go  |  7 +++
+ src/net/http/cookiejar/jar_test.go | 10 ++
+ 4 files changed, 24 insertions(+)
+
+diff --git a/src/net/http/client.go b/src/net/http/client.go
+index 22db96b..b2dd445 100644
+--- a/src/net/http/client.go
 b/src/net/http/client.go
+@@ -1015,6 +1015,12 @@ func isDomainOrSubdomain(sub, parent string) bool {
+   if sub == parent {
+   return true
+   }
++  // If sub contains a :, it's probably an IPv6 address (and is 
definitely not a hostname).
++  // Don't check the suffix in this case, to avoid matching the contents 
of a IPv6 zone.
++  // For example, "::1%.www.example.com" is not a subdomain of 
"www.example.com".
++  if strings.ContainsAny(sub, ":%") {
++  return false
++  }
+   // If sub is "foo.example.com" and parent is "example.com",
+   // that means sub must end in "."+parent.
+   // Do it without allocating.
+diff --git a/src/net/http/client_test.go b/src/net/http/client_test.go
+index 9788c7a..7a0aa53 100644
+--- a/src/net/http/client_test.go
 b/src/net/http/client_test.go
+@@ -1729,6 +1729,7 @@ func TestShouldCopyHeaderOnRedirect(t *testing.T) {
+   {"cookie2", "http://foo.com/;, "http://bar.com/;, false},
+   {"authorization", "http://foo.com/;, "http://bar.com/;, false},
+   {"www-authenticate", "http://foo.com/;, "http://bar.com/;, 
false},
++  {"authorization", "http://foo.com/;, 
"http://[::1%25.foo.com]/;, false},
+ 
+   // But subdomains should work:
+   {"www-authenticate", "http://foo.com/;, "http://foo.com/;, 
true},
+diff --git a/src/net/http/cookiejar/jar.go b/src/net/http/cookiejar/jar.go
+index e6583da..f2cf9c2 100644
+--- a/src/net/http/cookiejar/jar.go
 b/src/net/http/cookiejar/jar.go
+@@ -362,6 +362,13 @@ func jarKey(host string, psl PublicSuffixList) string {
+ 
+ // isIP reports whether host is 

[OE-core][kirkstone 3/4] selftest: skip virgl gtk/sdl test on ubuntu 18.04

2024-03-07 Thread Steve Sakoman
Signed-off-by: Steve Sakoman 
---
 meta/lib/oeqa/selftest/cases/runtime_test.py | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/lib/oeqa/selftest/cases/runtime_test.py 
b/meta/lib/oeqa/selftest/cases/runtime_test.py
index d06d480c2b..7dcdfd0ab2 100644
--- a/meta/lib/oeqa/selftest/cases/runtime_test.py
+++ b/meta/lib/oeqa/selftest/cases/runtime_test.py
@@ -221,6 +221,8 @@ class TestImage(OESelftestTestCase):
 self.skipTest('virgl isn\'t working with Centos 7')
 if distro and distro == 'opensuseleap-15.0':
 self.skipTest('virgl isn\'t working with Opensuse 15.0')
+if distro and distro == 'ubuntu-18.04':
+self.skipTest('virgl isn\'t working with Ubuntu 18.04')
 
 qemu_packageconfig = get_bb_var('PACKAGECONFIG', 'qemu-system-native')
 qemu_distrofeatures = get_bb_var('DISTRO_FEATURES', 
'qemu-system-native')
-- 
2.34.1


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



[OE-core][kirkstone 1/4] u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

2024-03-07 Thread Steve Sakoman
From: Fabio Estevam 

Commit cc6c3e31526d ("u-boot: Move definitions to common locations") moved
UBOOT_INITIAL_ENV to uboot-config.bbclass, but it should be kept at u-boot.inc
because it encodes ${PN} in it, which should be set by the U-Boot recipe.

Currently, whatever inherits uboot-config bbclass will fill-in its own PN,
which would change the content of UBOOT_INITIAL_ENV per-package.

Cc: Klaus Heinrich Kiwi 
Cc: Marek Vasut 
Fixes: cc6c3e31526d ("u-boot: Move definitions to common locations")
Signed-off-by: Fabio Estevam 

Backported from master: 0b0c4b37d318b86f100512476ffd861e0ce1f47e
Signed-off-by: Fabio Estevam 
Signed-off-by: Steve Sakoman 
---
 meta/classes/uboot-config.bbclass  | 4 
 meta/recipes-bsp/u-boot/u-boot.inc | 4 
 2 files changed, 4 insertions(+), 4 deletions(-)

diff --git a/meta/classes/uboot-config.bbclass 
b/meta/classes/uboot-config.bbclass
index b9ad35821a..fe85521877 100644
--- a/meta/classes/uboot-config.bbclass
+++ b/meta/classes/uboot-config.bbclass
@@ -59,10 +59,6 @@ UBOOT_ENV_BINARY ?= "${UBOOT_ENV}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_IMAGE ?= "${UBOOT_ENV}-${MACHINE}-${PV}-${PR}.${UBOOT_ENV_SUFFIX}"
 UBOOT_ENV_SYMLINK ?= "${UBOOT_ENV}-${MACHINE}.${UBOOT_ENV_SUFFIX}"
 
-# Default name of u-boot initial env, but enable individual recipes to change
-# this value.
-UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
-
 # U-Boot EXTLINUX variables. U-Boot searches for /boot/extlinux/extlinux.conf
 # to find EXTLINUX conf file.
 UBOOT_EXTLINUX_INSTALL_DIR ?= "/boot/extlinux"
diff --git a/meta/recipes-bsp/u-boot/u-boot.inc 
b/meta/recipes-bsp/u-boot/u-boot.inc
index b2f33e3826..54ea2e9e50 100644
--- a/meta/recipes-bsp/u-boot/u-boot.inc
+++ b/meta/recipes-bsp/u-boot/u-boot.inc
@@ -24,6 +24,10 @@ PACKAGECONFIG[openssl] = ",,openssl-native"
 # file already exists it will not be overwritten.
 UBOOT_LOCALVERSION ?= ""
 
+# Default name of u-boot initial env, but enable individual recipes to change
+# this value.
+UBOOT_INITIAL_ENV ?= "${PN}-initial-env"
+
 require u-boot-configure.inc
 
 do_compile () {
-- 
2.34.1


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



[OE-core][kirkstone 2/4] useradd-example: do not use unsupported clear text password

2024-03-07 Thread Steve Sakoman
From: Chen Qi 

The clear text password support has been dropped. So let's just
use a normal ecrypted one. The password remains to be 'user3'.

Signed-off-by: Chen Qi 
Signed-off-by: Richard Purdie 
(cherry picked from commit cd8232f9c58980d95180ad320b7b0bb0fcfd9ff5)
Signed-off-by: Fabio Berton 
Signed-off-by: Steve Sakoman 
---
 meta-skeleton/recipes-skeleton/useradd/useradd-example.bb | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb 
b/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
index 3f4c42d714..cff624e2f9 100644
--- a/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
+++ b/meta-skeleton/recipes-skeleton/useradd/useradd-example.bb
@@ -33,8 +33,8 @@ USERADD_PACKAGES = "${PN} ${PN}-user3"
 USERADD_PARAM:${PN} = "-u 1200 -d /home/user1 -r -s /bin/bash user1; -u 1201 
-d /home/user2 -r -s /bin/bash user2"
 
 # user3 will be managed in the useradd-example-user3 pacakge:
-# As an example, we use the -P option to set clear text password for user3
-USERADD_PARAM:${PN}-user3 = "-u 1202 -d /home/user3 -r -s /bin/bash -P 'user3' 
user3"
+# As an example, we use the -p option to set password ('user3') for user3
+USERADD_PARAM:${PN}-user3 = "-u 1202 -d /home/user3 -r -s /bin/bash -p 
'\$6\$XAWr.8nc\$bUE4pYYaVb8n6BbnBitU0zeJMtfhTpFpiOBLL9zRl4e4YQo88UU4r/1kjRzmTimCy.BvDh4xoFwVqcO.pihLa1'
 user3"
 
 # GROUPADD_PARAM works the same way, which you set to the options
 # you'd normally pass to the groupadd command. This will create
-- 
2.34.1


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



[OE-core][kirkstone 0/4] Patch review

2024-03-07 Thread Steve Sakoman
Please review this set of changes for kirkstone and have comments back by
end of day Monday, March 11

Passed a-full on autobuilder:

https://autobuilder.yoctoproject.org/typhoon/#/builders/83/builds/6658

The following changes since commit d63af11e92094487d6e358f27283e5385937e7a8:

  kernel.bbclass: Set pkg-config variables for building modules (2024-03-03 
11:56:20 -1000)

are available in the Git repository at:

  https://git.openembedded.org/openembedded-core-contrib stable/kirkstone-nut
  
https://git.openembedded.org/openembedded-core-contrib/log/?h=stable/kirkstone-nut

Chen Qi (1):
  useradd-example: do not use unsupported clear text password

Fabio Estevam (1):
  u-boot: Move UBOOT_INITIAL_ENV back to u-boot.inc

Hitendra Prajapati (1):
  golang: Fix CVE-2023-45289 & CVE-2023-45290

Steve Sakoman (1):
  selftest: skip virgl gtk/sdl test on ubuntu 18.04

 .../useradd/useradd-example.bb|   4 +-
 meta/classes/uboot-config.bbclass |   4 -
 meta/lib/oeqa/selftest/cases/runtime_test.py  |   2 +
 meta/recipes-bsp/u-boot/u-boot.inc|   4 +
 meta/recipes-devtools/go/go-1.17.13.inc   |   2 +
 .../go/go-1.21/CVE-2023-45289.patch   | 121 
 .../go/go-1.21/CVE-2023-45290.patch   | 270 ++
 7 files changed, 401 insertions(+), 6 deletions(-)
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-45289.patch
 create mode 100644 meta/recipes-devtools/go/go-1.21/CVE-2023-45290.patch

-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196811): 
https://lists.openembedded.org/g/openembedded-core/message/196811
Mute This Topic: https://lists.openembedded.org/mt/104793682/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 4/4] linux-firmware: remove pointless -license packages

2024-03-07 Thread Ross Burton
I retract this final patch of the series: there’s a few licenses which specify 
that the text needs to be distributed alongside the firmware and not just in 
“documentation or similar”.

The rest of the patches are good, however.

Ross

> On 7 Mar 2024, at 12:05, Ross Burton via lists.openembedded.org 
>  wrote:
> 
> From: Ross Burton 
> 
> The linux-firmware recipe goes to a lot of effort to attempt to package
> the license texts into separate packages, and add dependencies so that
> installing a piece of firmware will also ship the relevant license text.
> 
> However, licence.bbclass can already do this, because the requirement to
> ship license texts alongside binaries isn't specific to the firmware.
> 
> This class will collate the licenses (extended by NON_GENERIC_LICENSE
> assignments) and optionally put the license texts into a -lic package.
> These packages can be automatically installed into any image by adding
> lic-pkgs to IMAGE_FEATURES.
> 
> Signed-off-by: Ross Burton 
> ---
> .../linux-firmware/linux-firmware_20231211.bb | 412 ++
> 1 file changed, 41 insertions(+), 371 deletions(-)
> 
> diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
> b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> index b6b98628f3f..bb949bc5040 100644
> --- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> +++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
> @@ -258,33 +258,30 @@ do_compile() {
> 
> do_install() {
> oe_runmake 'DESTDIR=${D}' 
> 'FIRMWAREDIR=${nonarch_base_libdir}/firmware' ${PACKAGECONFIG_CONFARGS}
> -cp LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
> }
> 
> 
> -PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
> - ${PN}-cw1200-license ${PN}-cw1200 \
> - ${PN}-ralink-license ${PN}-ralink \
> - ${PN}-mt76x-license ${PN}-mt7601u ${PN}-mt7650 ${PN}-mt76x2 \
> - ${PN}-radeon-license ${PN}-radeon \
> - ${PN}-amdgpu-license ${PN}-amdgpu \
> - ${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
> - ${PN}-mediatek-license ${PN}-mediatek \
> - ${PN}-microchip-license ${PN}-microchip \
> - ${PN}-moxa-license ${PN}-moxa \
> +PACKAGES =+ "${PN}-amphion-vpu \
> + ${PN}-cw1200 \
> + ${PN}-ralink \
> + ${PN}-mt7601u ${PN}-mt7650 ${PN}-mt76x2 \
> + ${PN}-radeon \
> + ${PN}-amdgpu \
> + ${PN}-pcie8897 ${PN}-pcie8997 \
> + ${PN}-mediatek \
> + ${PN}-microchip \
> + ${PN}-moxa \
>  ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 
> \
>  ${PN}-sd8887 ${PN}-sd8897 ${PN}-sd8997 ${PN}-usb8997 \
> - ${PN}-ti-connectivity-license ${PN}-wlcommon ${PN}-wl12xx 
> ${PN}-wl18xx \
> - ${PN}-ti-keystone-license ${PN}-ti-keystone \
> - ${PN}-vt6656-license ${PN}-vt6656 \
> + ${PN}-wlcommon ${PN}-wl12xx ${PN}-wl18xx \
> + ${PN}-ti-keystone \
> + ${PN}-vt6656 \
>  ${PN}-rs9113 ${PN}-rs9116 \
> - ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce 
> ${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
> + ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce ${PN}-rtl8192su 
> ${PN}-rtl8723 ${PN}-rtl8821 \
>  ${PN}-rtl8761 \
>  ${PN}-rtl8168 \
>  ${PN}-rtl8822 \
>  ${PN}-rtl-nic \
> - ${PN}-cypress-license \
> - ${PN}-broadcom-license \
>  ${PN}-bcm-0bb4-0306 \
>  ${PN}-bcm43143 \
>  ${PN}-bcm43236b \
> @@ -318,15 +315,13 @@ PACKAGES =+ "${PN}-amphion-vpu-license 
> ${PN}-amphion-vpu \
>  ${PN}-bcm4373 \
>  ${PN}-bcm43xx \
>  ${PN}-bcm43xx-hdr \
> - ${PN}-cirrus-license ${PN}-cirrus \
> - ${PN}-cnm-license ${PN}-cnm \
> - ${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k 
> ${PN}-ath9k ${PN}-ath3k \
> + ${PN}-cirrus \
> + ${PN}-cnm \
> + ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k ${PN}-ath9k ${PN}-ath3k \
>  ${PN}-carl9170 \
> - ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
> ${PN}-ath11k ${PN}-qca \
> - \
> - ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q 
> ${PN}-imx-sdma-imx7d \
> - \
> - ${PN}-iwlwifi-license ${PN}-iwlwifi \
> + ${PN}-ar3k ${PN}-ath10k ${PN}-ath11k ${PN}-qca \
> + ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
> + ${PN}-iwlwifi \
>  ${PN}-iwlwifi-135-6 \
>  ${PN}-iwlwifi-3160-7 ${PN}-iwlwifi-3160-8 ${PN}-iwlwifi-3160-9 \
>  ${PN}-iwlwifi-3160-10 ${PN}-iwlwifi-3160-12 
> ${PN}-iwlwifi-3160-13 \
> @@ -339,23 +334,21 @@ PACKAGES =+ "${PN}-amphion-vpu-license 
> 

Re: [OE-core] [PATCH V6] systemd: fix dead link /var/log/README

2024-03-07 Thread Khem Raj
This is causing errors in do_install

| chown: cannot access
'/mnt/b/yoe/master/build/tmp/work/riscv64-yoe-linux/systemd/255.4/image/var/log/journal':
No such file or directory

On Wed, Mar 6, 2024 at 10:56 PM Changqing Li
 wrote:
>
> From: Changqing Li 
>
> There are 2 issues here:
> First, in package systemd, there is a file /usr/lib/tmpfile.d/legacy.conf,
> which will create a symlink to /usr/share/doc/systemd/README.logs during
> boot time. But for oe, /usr/share/doc/systemd/README.logs is packaged in
> systemd-doc, which will make /var/log/README is dead link.
>
> Second, the symlink /var/log/README in legacy.conf use relative path:
> "L /var/log/README - - - - ../../usr/share/doc/systemd/README.logs"
> But for oe, when VOLATILE_LOG_DIR is true, /var/log is a link to
> /var/volatile/log, so /var/log/README need link to
> ../../../usr/share/doc/systemd/README.logs, while VOLATILE_LOG_DIR is
> false, /var/log is a dir, so /var/log/README need link to
> ../../usr/share/doc/systemd/README.logs. So current symlink in
> legacy.conf will also make it a dead link when VOLATILE_LOG_DIR is true.
>
> Turn off CREATE_LOG_DIRS to avoid these issues.
>
> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-core/systemd/systemd_255.1.bb | 1 +
>  1 file changed, 1 insertion(+)
>
> diff --git a/meta/recipes-core/systemd/systemd_255.1.bb 
> b/meta/recipes-core/systemd/systemd_255.1.bb
> index a907d60e84..9fd7eccb38 100644
> --- a/meta/recipes-core/systemd/systemd_255.1.bb
> +++ b/meta/recipes-core/systemd/systemd_255.1.bb
> @@ -247,6 +247,7 @@ EXTRA_OEMESON += "-Dnobody-user=nobody \
>-Dsystem-uid-max=999 \
>-Dsystem-alloc-gid-min=101 \
>-Dsystem-gid-max=999 \
> +  -Dcreate-log-dirs=false \
>"
>
>  # Hardcode target binary paths to avoid using paths from sysroot or worse
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196809): 
https://lists.openembedded.org/g/openembedded-core/message/196809
Mute This Topic: https://lists.openembedded.org/mt/104782978/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] glib-2.0: backport a switch from distutils to packaging in codegen

2024-03-07 Thread Martin Jansa
On Thu, Mar 7, 2024 at 4:48 PM Peter Kjellerstedt
 wrote:
>
> We have a lot of recipes that use gdbus-codegen and are now facing this
> problem. To solve it, I have added a gdbus-codegen.bbclass that does:
>
> DEPENDS:append = " glib-2.0-native python3-packaging-native"
>
> inherit python3native
>
> This adds the dependencies needed to use gdbus-codegen, and is similar
> in spirit to pkgconfig.bbclass, which adds the dependencies needed to use
> pkg-config.
>
> I can send a patch to add it to either meta or meta-oe if it sounds
> like this is something that would be useful to others.

I was wondering about the same while changing this, there is already
CODEGEN_PYTHON_RDEPENDS = "python3 python3-packaging python3-xml"
CODEGEN_PYTHON_RDEPENDS:mingw32 = ""

RDEPENDS:${PN}-codegen += "${CODEGEN_PYTHON_RDEPENDS}"

but that won't apply the python3native inherit, unless moving this to
some gdbus-codegen.bbclass as you suggested.

I've already fixed all recipes in meta-oe and our internal layers so I
don't need this anymore, but agree it would be useful.

Regards,

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196808): 
https://lists.openembedded.org/g/openembedded-core/message/196808
Mute This Topic: https://lists.openembedded.org/mt/104560766/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] glib-2.0: backport a switch from distutils to packaging in codegen

2024-03-07 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 7 mars 2024 17:11
> To: Peter Kjellerstedt 
> Cc: Khem Raj ; Martin Jansa ;
> openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] glib-2.0: backport a switch from distutils
> to packaging in codegen
> 
> On Thu, 7 Mar 2024 at 16:49, Peter Kjellerstedt
>  wrote:
> 
> > We have a lot of recipes that use gdbus-codegen and are now facing this
> > problem. To solve it, I have added a gdbus-codegen.bbclass that does:
> >
> > DEPENDS:append = " glib-2.0-native python3-packaging-native"
> >
> > inherit python3native
> >
> > This adds the dependencies needed to use gdbus-codegen, and is similar
> > in spirit to pkgconfig.bbclass, which adds the dependencies needed to use
> > pkg-config.
> >
> > I can send a patch to add it to either meta or meta-oe if it sounds
> > like this is something that would be useful to others.
> 
> I wonder if instead of a class, this can be solved by tweaking
> RDEPENDS of glib recipe (perhaps with a class-native override), so
> that python3-packaging is pulled in through that, and no special
> dependencies are needed, other than glib-2.0-native.
> 
> Alex

The problem is the need to inherit python3native. Without it, the host 
packages are used...

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196807): 
https://lists.openembedded.org/g/openembedded-core/message/196807
Mute This Topic: https://lists.openembedded.org/mt/104560766/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] bmaptool: Add bmap-tools runtime alias for compatibility

2024-03-07 Thread Alexander Kanavin
Is it? Why? There’s plenty of recipes in core  that don’t do it. Package
managers resolvers are able to figure out that one package needs to be
replaced with another.

Alex

On Thu 7. Mar 2024 at 17.17, Otavio Salvador <
otavio.salva...@ossystems.com.br> wrote:

>
>
> Em qui., 7 de mar. de 2024 às 13:14, Alexander Kanavin <
> alex.kana...@gmail.com> escreveu:
>
>> On Thu, 7 Mar 2024 at 14:43, Tom Hochstein  wrote:
>> > +# For compatibility with layers before scarthgap
>> > +RPROVIDES:${PN} = "bmap-tools"
>> > +RREPLACES:${PN} = "bmap-tools"
>> > +RCONFLICTS:${PN} = "bmap-tools"
>>
>> Only RREPLACES/RCONFLICTS please. Do not add the obsolete RPROVIDES.
>>
>
> For package feed upgrade it is required.
>
> --
> Otavio Salvador O.S. Systems
> http://www.ossystems.com.brhttp://code.ossystems.com.br
> Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750
>
> 
>
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196806): 
https://lists.openembedded.org/g/openembedded-core/message/196806
Mute This Topic: https://lists.openembedded.org/mt/104787184/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] bmaptool: Add bmap-tools runtime alias for compatibility

2024-03-07 Thread Otavio Salvador
Em qui., 7 de mar. de 2024 às 13:14, Alexander Kanavin <
alex.kana...@gmail.com> escreveu:

> On Thu, 7 Mar 2024 at 14:43, Tom Hochstein  wrote:
> > +# For compatibility with layers before scarthgap
> > +RPROVIDES:${PN} = "bmap-tools"
> > +RREPLACES:${PN} = "bmap-tools"
> > +RCONFLICTS:${PN} = "bmap-tools"
>
> Only RREPLACES/RCONFLICTS please. Do not add the obsolete RPROVIDES.
>

For package feed upgrade it is required.

-- 
Otavio Salvador O.S. Systems
http://www.ossystems.com.brhttp://code.ossystems.com.br
Mobile: +55 (53) 9 9981-7854  Mobile: +1 (347) 903-9750

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196805): 
https://lists.openembedded.org/g/openembedded-core/message/196805
Mute This Topic: https://lists.openembedded.org/mt/104787184/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] bmaptool: Add bmap-tools runtime alias for compatibility

2024-03-07 Thread Alexander Kanavin
On Thu, 7 Mar 2024 at 14:43, Tom Hochstein  wrote:
> +# For compatibility with layers before scarthgap
> +RPROVIDES:${PN} = "bmap-tools"
> +RREPLACES:${PN} = "bmap-tools"
> +RCONFLICTS:${PN} = "bmap-tools"

Only RREPLACES/RCONFLICTS please. Do not add the obsolete RPROVIDES.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196804): 
https://lists.openembedded.org/g/openembedded-core/message/196804
Mute This Topic: https://lists.openembedded.org/mt/104787184/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] glib-2.0: backport a switch from distutils to packaging in codegen

2024-03-07 Thread Alexander Kanavin
On Thu, 7 Mar 2024 at 16:49, Peter Kjellerstedt
 wrote:

> We have a lot of recipes that use gdbus-codegen and are now facing this
> problem. To solve it, I have added a gdbus-codegen.bbclass that does:
>
> DEPENDS:append = " glib-2.0-native python3-packaging-native"
>
> inherit python3native
>
> This adds the dependencies needed to use gdbus-codegen, and is similar
> in spirit to pkgconfig.bbclass, which adds the dependencies needed to use
> pkg-config.
>
> I can send a patch to add it to either meta or meta-oe if it sounds
> like this is something that would be useful to others.

I wonder if instead of a class, this can be solved by tweaking
RDEPENDS of glib recipe (perhaps with a class-native override), so
that python3-packaging is pulled in through that, and no special
dependencies are needed, other than glib-2.0-native.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196803): 
https://lists.openembedded.org/g/openembedded-core/message/196803
Mute This Topic: https://lists.openembedded.org/mt/104560766/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 7/9] oeqa/runtime/login: Exclude qemuriscv64

2024-03-07 Thread Khem Raj
On Wed, Mar 6, 2024 at 2:34 PM Richard Purdie
 wrote:
>
> On Wed, 2024-03-06 at 10:52 -0800, Khem Raj wrote:
> > On Wed, Mar 6, 2024 at 8:23 AM Richard Purdie
> >  wrote:
> > >
> > > From: Eilís 'pidge' Ní Fhlannagáin 
> > >
> > > Excluding riscv64 due to mouse rather than a touchscreen which adds a
> > > moving cursor, so the diff ends up > 0. Need to fix the image to use the
> > > touchscreen rather than mouse input.
> >
> > Is it an option we are using to start the qemu which is causing this issue?
> > I would like to understand more
>
> I suspect it will be. Somewhere on the other platforms we use a usb
> touch input device (absolute coords) but I think for riscv64 it is
> using a mouse (relative coords).
>
> We just need to compare the usb devices and work out what is missing...
>

We use -device usb-tablet -device usb-kbd for qemuarm64 and for qemuriscv64
-device virtio-tablet-pci -device virtio-keyboard-pci is used. I think
that might be
the difference. I will test a change to use usb-tablet and usb-kbd, I
have a local
patch for kernel-cache and then these options work for qemuriscv64 as well
sadly the events are received by qemu but clicks do not work for qemuriscv32
somehow, I will make the changes for qemuriscv64 atleast and leave rv32 as it
is.

> Cheers,
>
> Richard
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196802): 
https://lists.openembedded.org/g/openembedded-core/message/196802
Mute This Topic: https://lists.openembedded.org/mt/104768948/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] glib-2.0: backport a switch from distutils to packaging in codegen

2024-03-07 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Khem Raj
> Sent: den 28 februari 2024 19:30
> To: Martin Jansa 
> Cc: openembedded-core@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH] glib-2.0: backport a switch from distutils
> to packaging in codegen
> 
> some more failures in meta-openembedded layers ( meta-xfce)
> 
> https://errors.yoctoproject.org/Errors/Details/754995/
> https://errors.yoctoproject.org/Errors/Details/754996/
> 
> On Tue, Feb 27, 2024 at 3:39 AM Martin Jansa 
> wrote:
> >
> > Yes, it was reproducible on my host gentoo after removing distutils
> > with dev-python/setuptools (and for updated glib-2.0-native after
> > removing dev-python/packaging)
> >
> > Fixes sent:
> > https://patchwork.yoctoproject.org/project/oe/patch/20240227113711.834767-1-martin.ja...@gmail.com/
> > https://patchwork.yoctoproject.org/project/oe/patch/20240227113711.834767-2-martin.ja...@gmail.com/
> >
> > Cheers,
> >
> > On Tue, Feb 27, 2024 at 12:58 AM Martin Jansa via
> > lists.openembedded.org 
> > wrote:
> > >
> > > Thanks Khem, will try to reproduce tomorrow. Maybe these don't use
> > > CODEGEN_PYTHON_RDEPENDS.
> > >
> > > With this patch backported to kirkstone I've seen glib-2.0-native
> > > failing with the same issue as python3native there doesn't include
> > > python3-packaging.
> > >
> > > Maybe these recipes aren't using python3native and were depending on
> > > packaging from host, will debug tomorrow.
> > >
> > > On Tue, Feb 27, 2024 at 12:16 AM Khem Raj  wrote:
> > > >
> > > > I am seeing some build failures which seems to be related to this
> > > > patch
> > > >
> > > > https://autobuilder.yoctoproject.org/typhoon/#/builders/88/builds/3657/steps/15/logs/stdio
> > > >
> > > >  |   File 
> > > > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/gattlib/0.2+git/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py",
> > > >  line 22, in 
> > > > | import packaging.version
> > > > | ModuleNotFoundError: No module named 'packaging'
> > > >
> > > >
> > > >
> > > >   |   File 
> > > > "/home/pokybuild/yocto-worker/meta-oe/build/build/tmp/work/core2-64-poky-linux/networkmanager-fortisslvpn/1.4.0/recipe-sysroot-native/usr/share/glib-2.0/codegen/utils.py",
> > > >  line 22, in 
> > > > | import packaging.version
> > > > | ModuleNotFoundError: No module named 'packaging'
> > > > | make: *** [Makefile:2081: src/nm-fortisslvpn-pppd-service-dbus.h] 
> > > > Error 1

We have a lot of recipes that use gdbus-codegen and are now facing this 
problem. To solve it, I have added a gdbus-codegen.bbclass that does:

DEPENDS:append = " glib-2.0-native python3-packaging-native"

inherit python3native

This adds the dependencies needed to use gdbus-codegen, and is similar 
in spirit to pkgconfig.bbclass, which adds the dependencies needed to use 
pkg-config.

I can send a patch to add it to either meta or meta-oe if it sounds 
like this is something that would be useful to others.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196801): 
https://lists.openembedded.org/g/openembedded-core/message/196801
Mute This Topic: https://lists.openembedded.org/mt/104560766/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 4/4] linux-yocto/5.15: update to v5.15.141

2024-03-07 Thread Bruce Ashfield
On Thu, Mar 7, 2024 at 9:51 AM Steve Sakoman  wrote:
>
> On Thu, Mar 7, 2024 at 4:34 AM Steve Sakoman via
> lists.openembedded.org 
> wrote:
> >
> >
> >
> > On Thu, Mar 7, 2024, 4:29 AM Bruce Ashfield  
> > wrote:
> >>
> >> On Thu, Mar 7, 2024 at 9:00 AM Steve Sakoman  wrote:
> >> >
> >> > On Thu, Mar 7, 2024 at 3:46 AM Steve Sakoman via
> >> > lists.openembedded.org 
> >> > wrote:
> >> > >
> >> > > On Wed, Mar 6, 2024 at 7:42 AM Bruce Ashfield 
> >> > >  wrote:
> >> > > >
> >> > > > On Wed, Mar 6, 2024 at 12:38 PM Steve Sakoman  
> >> > > > wrote:
> >> > > > >
> >> > > > >
> >> > > > >
> >> > > > > On Wed, Mar 6, 2024 at 6:04 AM Steve Sakoman via 
> >> > > > > lists.openembedded.org  
> >> > > > > wrote:
> >> > > > > >
> >> > > > > > On Wed, Mar 6, 2024 at 5:59 AM Bruce Ashfield 
> >> > > > > >  wrote:
> >> > > > > > >
> >> > > > > > > On Wed, Mar 6, 2024 at 10:43 AM Steve Sakoman 
> >> > > > > > >  wrote:
> >> > > > > > > >
> >> > > > > > > > On Thu, Dec 7, 2023 at 8:08 AM Steve Sakoman 
> >> > > > > > > >  wrote:
> >> > > > > > > > >
> >> > > > > > > > > Hi Bruce,
> >> > > > > > > > >
> >> > > > > > > > > The 5.10 version bumps look fine in testing, but sadly 
> >> > > > > > > > > this 5.15
> >> > > > > > > > > version bump breaks qemux86-64-ptest:
> >> > > > > > > > >
> >> > > > > > > > > AssertionError: Failed ptests:
> >> > > > > > > > > {'parted': ['t1104-remove-and-add-partition.sh',
> >> > > > > > > > > 't8000-loop.sh',
> >> > > > > > > > > 't8001-loop-blkpg.sh']}
> >> > > > > > > > >
> >> > > > > > > > > Failure is reproducible 100% of the time, so there is that 
> >> > > > > > > > > ...
> >> > > > > > > >
> >> > > > > > > > After  wading through the hundreds of changes in this 
> >> > > > > > > > version bump
> >> > > > > > > > from 5.15.124 to 5.15.141 I found this in the 5.13.132 
> >> > > > > > > > portion that
> >> > > > > > > > looks suspicious:
> >> > > > > > > >
> >> > > > > > > > 072cd213c64f block: don't add or resize partition on the 
> >> > > > > > > > disk with
> >> > > > > > > > GENHD_FL_NO_PART
> >> > > > > > > > c6ce1c5dd327 block: rename GENHD_FL_NO_PART_SCAN to 
> >> > > > > > > > GENHD_FL_NO_PART
> >> > > > > > > >
> >> > > > > > >
> >> > > > > > > It could very well be that, I haven't been able to get to any 
> >> > > > > > > local
> >> > > > > > > testing on this
> >> > > > > > > yet.
> >> > > > > > >
> >> > > > > > > I will go look at parted for commits that indicate they are 
> >> > > > > > > fixing a
> >> > > > > > > kernel interface
> >> > > > > > > that sounds similar .. since we don't want to revert an 
> >> > > > > > > offending commit, the
> >> > > > > > > way to fix this is via selective update of parted.
> >> > > > > >
> >> > > > > > I'm doing a test kirkstone build that bumps parted to the same 
> >> > > > > > version
> >> > > > > > as in master.
> >> > > > > >
> >> > > > > > This will at least let us know whether it has been fixed in 
> >> > > > > > upstream parted.
> >> > > > >
> >> > > > > The test completed and I get the same failure with the most recent 
> >> > > > > parted version.
> >> > > > >
> >> > > > > So apparently not fixed in parted.
> >> > > >
> >> > > > Which means that the newer kernels have some sort of additional fix 
> >> > > > or a revert.
> >> > > >
> >> > > > I'll have a look for that as well.
> >> > >
> >> > > From looking at how Ubuntu deals with this
> >> > > (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056143):
> >> > >
> >> > > -- Impact --
> >> > > In 22.04/Jammy with the GA 5.15 kernel there was an upstream change
> >> > > preventing partition table operations when GENHD_FL_NO_PART is set.
> >> > >  1a721de8489f "block: don't add or resize partition on the disk with
> >> > > GENHD_FL_NO_PART"
> >> > > Beside of changing return codes and breaking some user-space that way
> >> > > this also causes loop block devices to no longer be able to have
> >> > > partitions manually created. This is because the loop block driver
> >> > > uses GENHD_FL_NO_PART to prevent active partition scans.
> >> > >
> >> > > -- Fix --
> >> > > This was changed in 5.19 (and thus Mantic is not affected) by
> >> > > introducing a separate flag to prevent those scans:
> >> > >  b9684a71fca7 "block, loop: support partitions without scanning"
> >> > > The fix depends on a larger rewrite so it cannot be simply picked. The
> >> > > biggest change from the original is moving the check for the new flag
> >> > > into a helper function in genhd.h which checks whether a disk should
> >> > > be scanned for partitions. That function was dropped with the upstream
> >> > > rewrite and checking moved into the loop driver directly. But it felt
> >> > > like adjusting the helper was the better approach.
> >> > >
> >> > > Note: The upstream patch has a follow-up change submitted:
> >> > >   748008e1da92 "block: don't add partitions if GD_SUPPRESS_PART_SCAN 
> >> > > is set"
> >> > > We do _NOT_ need that in Jammy/5.15 because 

Re: [OE-core][nanbield] cherry-pick request

2024-03-07 Thread Steve Sakoman
On Sat, Mar 2, 2024 at 1:23 PM Munehisa Kamata  wrote:
>
> Hi Steve,
>
> Could you please cherry-pick the commit cd2072e5d953 ("kernel.bbclass: Set
> pkg-config variables for building modules") from the master for nanbield to
> avoid the unexpected rebuild at do_compile_kernelmodules()?

OK, will do so.

Steve

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196799): 
https://lists.openembedded.org/g/openembedded-core/message/196799
Mute This Topic: https://lists.openembedded.org/mt/104694809/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] ghostscript: ignore CVE-2020-36773

2024-03-07 Thread Steve Sakoman
On Sun, Mar 3, 2024 at 3:50 PM Vijay Anusuri  wrote:
>
> Hi Steve,
>
> I've sent mail to cpe_diction...@nist.gov to update the information.
>
> Now it was updated in https://nvd.nist.gov/vuln/detail/CVE-2020-36773

Thanks!

Steve

> On Thu, Feb 8, 2024 at 8:40 PM Steve Sakoman  wrote:
>>
>> On Wed, Feb 7, 2024 at 8:42 PM Vijay Anusuri via
>> lists.openembedded.org 
>> wrote:
>> >
>> > From: Vijay Anusuri 
>> >
>> > Artifex Ghostscript before 9.53.0 has an out-of-bounds write and 
>> > use-after-free in devices/vector/gdevtxtw.c (for txtwrite) because a 
>> > single character code in a PDF document can map to more than one Unicode 
>> > code point (e.g., for a ligature).
>> >
>> > Reference: https://ubuntu.com/security/CVE-2020-36773
>> >
>> > Signed-off-by: Vijay Anusuri 
>> > ---
>> >  meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb | 4 
>> >  1 file changed, 4 insertions(+)
>> >
>> > diff --git a/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb 
>> > b/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
>> > index e0d1e4618f..cc06d092c1 100644
>> > --- a/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
>> > +++ b/meta/recipes-extended/ghostscript/ghostscript_9.55.0.bb
>> > @@ -26,6 +26,10 @@ CVE_CHECK_IGNORE += "CVE-2013-6629"
>> >  # Issue in the GhostPCL. GhostPCL not part of this GhostScript recipe.
>> >  CVE_CHECK_IGNORE += "CVE-2023-38560"
>> >
>> > +# This CVE affects Ghostscript before 9.53.0
>> > +# https://ubuntu.com/security/CVE-2020-36773
>> > +CVE_CHECK_IGNORE += "CVE-2020-36773"
>>
>> When there is an error in the upstream database it is preferred that
>> you send an email to cpe_diction...@nist.gov requesting an update
>> (giving links that justify the change to make it easy for them to
>> research)
>>
>> They are usually quite responsive, and this is much preferred to
>> carrying an IGNORE in our metadata.
>>
>> Thanks!
>>
>> Steve
>>
>> > +
>> >  def gs_verdir(v):
>> >  return "".join(v.split("."))
>> >
>> > --
>> > 2.25.1
>> >
>> >
>> > 
>> >

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196798): 
https://lists.openembedded.org/g/openembedded-core/message/196798
Mute This Topic: https://lists.openembedded.org/mt/104234914/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 4/4] linux-yocto/5.15: update to v5.15.141

2024-03-07 Thread Steve Sakoman
On Thu, Mar 7, 2024 at 4:34 AM Steve Sakoman via
lists.openembedded.org 
wrote:
>
>
>
> On Thu, Mar 7, 2024, 4:29 AM Bruce Ashfield  wrote:
>>
>> On Thu, Mar 7, 2024 at 9:00 AM Steve Sakoman  wrote:
>> >
>> > On Thu, Mar 7, 2024 at 3:46 AM Steve Sakoman via
>> > lists.openembedded.org 
>> > wrote:
>> > >
>> > > On Wed, Mar 6, 2024 at 7:42 AM Bruce Ashfield  
>> > > wrote:
>> > > >
>> > > > On Wed, Mar 6, 2024 at 12:38 PM Steve Sakoman  
>> > > > wrote:
>> > > > >
>> > > > >
>> > > > >
>> > > > > On Wed, Mar 6, 2024 at 6:04 AM Steve Sakoman via 
>> > > > > lists.openembedded.org  
>> > > > > wrote:
>> > > > > >
>> > > > > > On Wed, Mar 6, 2024 at 5:59 AM Bruce Ashfield 
>> > > > > >  wrote:
>> > > > > > >
>> > > > > > > On Wed, Mar 6, 2024 at 10:43 AM Steve Sakoman 
>> > > > > > >  wrote:
>> > > > > > > >
>> > > > > > > > On Thu, Dec 7, 2023 at 8:08 AM Steve Sakoman 
>> > > > > > > >  wrote:
>> > > > > > > > >
>> > > > > > > > > Hi Bruce,
>> > > > > > > > >
>> > > > > > > > > The 5.10 version bumps look fine in testing, but sadly this 
>> > > > > > > > > 5.15
>> > > > > > > > > version bump breaks qemux86-64-ptest:
>> > > > > > > > >
>> > > > > > > > > AssertionError: Failed ptests:
>> > > > > > > > > {'parted': ['t1104-remove-and-add-partition.sh',
>> > > > > > > > > 't8000-loop.sh',
>> > > > > > > > > 't8001-loop-blkpg.sh']}
>> > > > > > > > >
>> > > > > > > > > Failure is reproducible 100% of the time, so there is that 
>> > > > > > > > > ...
>> > > > > > > >
>> > > > > > > > After  wading through the hundreds of changes in this version 
>> > > > > > > > bump
>> > > > > > > > from 5.15.124 to 5.15.141 I found this in the 5.13.132 portion 
>> > > > > > > > that
>> > > > > > > > looks suspicious:
>> > > > > > > >
>> > > > > > > > 072cd213c64f block: don't add or resize partition on the disk 
>> > > > > > > > with
>> > > > > > > > GENHD_FL_NO_PART
>> > > > > > > > c6ce1c5dd327 block: rename GENHD_FL_NO_PART_SCAN to 
>> > > > > > > > GENHD_FL_NO_PART
>> > > > > > > >
>> > > > > > >
>> > > > > > > It could very well be that, I haven't been able to get to any 
>> > > > > > > local
>> > > > > > > testing on this
>> > > > > > > yet.
>> > > > > > >
>> > > > > > > I will go look at parted for commits that indicate they are 
>> > > > > > > fixing a
>> > > > > > > kernel interface
>> > > > > > > that sounds similar .. since we don't want to revert an 
>> > > > > > > offending commit, the
>> > > > > > > way to fix this is via selective update of parted.
>> > > > > >
>> > > > > > I'm doing a test kirkstone build that bumps parted to the same 
>> > > > > > version
>> > > > > > as in master.
>> > > > > >
>> > > > > > This will at least let us know whether it has been fixed in 
>> > > > > > upstream parted.
>> > > > >
>> > > > > The test completed and I get the same failure with the most recent 
>> > > > > parted version.
>> > > > >
>> > > > > So apparently not fixed in parted.
>> > > >
>> > > > Which means that the newer kernels have some sort of additional fix or 
>> > > > a revert.
>> > > >
>> > > > I'll have a look for that as well.
>> > >
>> > > From looking at how Ubuntu deals with this
>> > > (https://bugs.launchpad.net/ubuntu/+source/linux/+bug/2056143):
>> > >
>> > > -- Impact --
>> > > In 22.04/Jammy with the GA 5.15 kernel there was an upstream change
>> > > preventing partition table operations when GENHD_FL_NO_PART is set.
>> > >  1a721de8489f "block: don't add or resize partition on the disk with
>> > > GENHD_FL_NO_PART"
>> > > Beside of changing return codes and breaking some user-space that way
>> > > this also causes loop block devices to no longer be able to have
>> > > partitions manually created. This is because the loop block driver
>> > > uses GENHD_FL_NO_PART to prevent active partition scans.
>> > >
>> > > -- Fix --
>> > > This was changed in 5.19 (and thus Mantic is not affected) by
>> > > introducing a separate flag to prevent those scans:
>> > >  b9684a71fca7 "block, loop: support partitions without scanning"
>> > > The fix depends on a larger rewrite so it cannot be simply picked. The
>> > > biggest change from the original is moving the check for the new flag
>> > > into a helper function in genhd.h which checks whether a disk should
>> > > be scanned for partitions. That function was dropped with the upstream
>> > > rewrite and checking moved into the loop driver directly. But it felt
>> > > like adjusting the helper was the better approach.
>> > >
>> > > Note: The upstream patch has a follow-up change submitted:
>> > >   748008e1da92 "block: don't add partitions if GD_SUPPRESS_PART_SCAN is 
>> > > set"
>> > > We do _NOT_ need that in Jammy/5.15 because block/partitions/core.c:
>> > > blk_add_partitions() checks disk_part_scan_enabled() which was where
>> > > we added the check for the backport instead of modifying
>> > > disk_scan_partitions() directly.
>> >
>> > Forgot to add this:
>> >
>> > 

Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit

2024-03-07 Thread Peter Kjellerstedt
> -Original Message-
> From: openembedded-core@lists.openembedded.org  c...@lists.openembedded.org> On Behalf Of Alexander Kanavin
> Sent: den 7 mars 2024 12:42
> To: qi.c...@windriver.com
> Cc: Li, Changqing ; Richard Purdie
> ; openembedded-
> c...@lists.openembedded.org
> Subject: Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit
> 
> On Thu, 7 Mar 2024 at 11:21, Chen Qi via lists.openembedded.org
>  wrote:
> > You can see dnf's solution is: https://github.com/rpm-software-
> management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
> >
> > I don't think dnf community will look into this issue. And I would
> expect it to be a complicated one. Because dnf's own solution looks like
> more of a workaround. At the same time, yocto based systems will sometimes
> have log_lock.pid left in target filesystems. Users typing 'ls /' will
> notice it.
> >
> > We have an OE specific patch: https://git.openembedded.org/openembedded-
> core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
> > I can see that this OE specific patch, 0001-dnf-write-the-log-lock-to-
> root.patch, does solve some issue. Unfortunately, at the same time, it
> introduces this specific issue, a easy-to-notice one.
> >
> > My suggestion is that we merge this fix into 0001-dnf-write-the-log-
> lock-to-root.patch, because they really belong together. I guess we can't
> expect dnf community to devote time into this, as they've already got a
> solution. And I'm not sure if anyone in OE community is familiar with dnf
> enough to solve this issue. So let's make things a little better, avoiding
> users of Yocto systems see this log_lock.pid file when they type 'ls /'.
> >
> > If you have any other suggestion, please let us know.
> 
> We need to find out why it happens, and why it happens only sometimes.
> If lock file does not get properly deleted that is quite possibly
> masking a different issue which needs fixing, and the proposed patch
> just sweeps it all under the carpet in the name of giving users an
> aesthetically pleasing rootfs. So the answer is still no.
> 
> If you are having difficulty debugging the situation where the lock
> file does get left behind, can you provide a way for me to reproduce
> the issue? I just build core-image-minimal, and I'm not seeing it:
> 
> alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ls
> tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/rootfs/
> bin  boot  dev  etc  home  lib  media  mnt  proc  root  run  sbin  srv
>  sys  tmp  usr  var
> 
> If you can't provide that, then you can certainly still do more on
> your side: build core-image-minimal with plain poky, ensure the lock
> file gets deleted, then build your own private things where the file
> does not get deleted, then investigate why the code path that deletes
> the lock file isn't being taken in the latter case. You can see the
> code where the lock log (self.rotate_lock) is used in logging.py:
> 
> def emit(self, record):
> while True:
> try:
> if self.shouldRollover(record):
> with self.rotate_lock:
> # Do rollover while preserving the mode of the new 
> log file
> mode = os.stat(self.baseFilename).st_mode
> self.doRollover()
> os.chmod(self.baseFilename, mode)
> logging.FileHandler.emit(self, record)
> return
> except (dnf.exceptions.ProcessLockError, 
> dnf.exceptions.ThreadLockError):
> time.sleep(0.01)
> except Exception:
> self.handleError(record)
> return
> 
> And the deletion happens in lock.py:
> 
> def __exit__(self, *exc_args):
> if self.count == 1:
> os.unlink(self.target)
> self._unlock_thread()
> 
> 
> 
> Alex

I did try to find a solution to this problem quite a while back, but 
unfortunately never managed to get to the bottom of it. What I did figure out 
was that the problem is related to whether dnf thinks it is running as root 
or not as that results in different paths being used. I.e., it may create the 
file in one place and then try to delete it in another. What I never could 
figure out is how/where dnf switches between root/not root as it seems to 
happen mid-run.

//Peter


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196795): 
https://lists.openembedded.org/g/openembedded-core/message/196795
Mute This Topic: https://lists.openembedded.org/mt/104784184/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 v2] bmaptool: Add bmap-tools runtime alias for compatibility

2024-03-07 Thread Tom Hochstein
The rename of bmap-tools to bmaptool creates an incompatibility that
will break package feeds. Restore compatibility by adding bmap-tools as
a runtime alias.

Acked-by: Otavio Salvador 
Signed-off-by: Tom Hochstein 
---
 meta/recipes-support/bmaptool/bmaptool_git.bb | 5 +
 1 file changed, 5 insertions(+)

diff --git a/meta/recipes-support/bmaptool/bmaptool_git.bb 
b/meta/recipes-support/bmaptool/bmaptool_git.bb
index 87328af8c6..f0f3b85902 100644
--- a/meta/recipes-support/bmaptool/bmaptool_git.bb
+++ b/meta/recipes-support/bmaptool/bmaptool_git.bb
@@ -28,4 +28,9 @@ RDEPENDS:${PN} = "python3-core python3-compression 
python3-misc python3-mmap pyt
 
 inherit setuptools3
 
+# For compatibility with layers before scarthgap
+RPROVIDES:${PN} = "bmap-tools"
+RREPLACES:${PN} = "bmap-tools"
+RCONFLICTS:${PN} = "bmap-tools"
+
 BBCLASSEXTEND = "native nativesdk"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196791): 
https://lists.openembedded.org/g/openembedded-core/message/196791
Mute This Topic: https://lists.openembedded.org/mt/104787184/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 7/9] oeqa/runtime/login: Exclude qemuriscv64

2024-03-07 Thread Richard Purdie
On Wed, 2024-03-06 at 14:34 -0800, Richard Purdie via
lists.openembedded.org wrote:
> On Wed, 2024-03-06 at 10:52 -0800, Khem Raj wrote:
> > On Wed, Mar 6, 2024 at 8:23 AM Richard Purdie
> >  wrote:
> > > 
> > > From: Eilís 'pidge' Ní Fhlannagáin 
> > > 
> > > Excluding riscv64 due to mouse rather than a touchscreen which
> > > adds a
> > > moving cursor, so the diff ends up > 0. Need to fix the image to
> > > use the
> > > touchscreen rather than mouse input.
> > 
> > Is it an option we are using to start the qemu which is causing
> > this issue?
> > I would like to understand more
> 
> I suspect it will be. Somewhere on the other platforms we use a usb
> touch input device (absolute coords) but I think for riscv64 it is
> using a mouse (relative coords).
> 
> We just need to compare the usb devices and work out what is
> missing...

https://bugzilla.yoctoproject.org/show_bug.cgi?id=15427

Cheers,

Richard

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196790): 
https://lists.openembedded.org/g/openembedded-core/message/196790
Mute This Topic: https://lists.openembedded.org/mt/104768948/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] linux-firmware: remove pointless -license packages

2024-03-07 Thread Ross Burton
From: Ross Burton 

The linux-firmware recipe goes to a lot of effort to attempt to package
the license texts into separate packages, and add dependencies so that
installing a piece of firmware will also ship the relevant license text.

However, licence.bbclass can already do this, because the requirement to
ship license texts alongside binaries isn't specific to the firmware.

This class will collate the licenses (extended by NON_GENERIC_LICENSE
assignments) and optionally put the license texts into a -lic package.
These packages can be automatically installed into any image by adding
lic-pkgs to IMAGE_FEATURES.

Signed-off-by: Ross Burton 
---
 .../linux-firmware/linux-firmware_20231211.bb | 412 ++
 1 file changed, 41 insertions(+), 371 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index b6b98628f3f..bb949bc5040 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -258,33 +258,30 @@ do_compile() {
 
 do_install() {
 oe_runmake 'DESTDIR=${D}' 
'FIRMWAREDIR=${nonarch_base_libdir}/firmware' ${PACKAGECONFIG_CONFARGS}
-cp LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
 }
 
 
-PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
- ${PN}-cw1200-license ${PN}-cw1200 \
- ${PN}-ralink-license ${PN}-ralink \
- ${PN}-mt76x-license ${PN}-mt7601u ${PN}-mt7650 ${PN}-mt76x2 \
- ${PN}-radeon-license ${PN}-radeon \
- ${PN}-amdgpu-license ${PN}-amdgpu \
- ${PN}-marvell-license ${PN}-pcie8897 ${PN}-pcie8997 \
- ${PN}-mediatek-license ${PN}-mediatek \
- ${PN}-microchip-license ${PN}-microchip \
- ${PN}-moxa-license ${PN}-moxa \
+PACKAGES =+ "${PN}-amphion-vpu \
+ ${PN}-cw1200 \
+ ${PN}-ralink \
+ ${PN}-mt7601u ${PN}-mt7650 ${PN}-mt76x2 \
+ ${PN}-radeon \
+ ${PN}-amdgpu \
+ ${PN}-pcie8897 ${PN}-pcie8997 \
+ ${PN}-mediatek \
+ ${PN}-microchip \
+ ${PN}-moxa \
  ${PN}-sd8686 ${PN}-sd8688 ${PN}-sd8787 ${PN}-sd8797 ${PN}-sd8801 \
  ${PN}-sd8887 ${PN}-sd8897 ${PN}-sd8997 ${PN}-usb8997 \
- ${PN}-ti-connectivity-license ${PN}-wlcommon ${PN}-wl12xx 
${PN}-wl18xx \
- ${PN}-ti-keystone-license ${PN}-ti-keystone \
- ${PN}-vt6656-license ${PN}-vt6656 \
+ ${PN}-wlcommon ${PN}-wl12xx ${PN}-wl18xx \
+ ${PN}-ti-keystone \
+ ${PN}-vt6656 \
  ${PN}-rs9113 ${PN}-rs9116 \
- ${PN}-rtl-license ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce 
${PN}-rtl8192su ${PN}-rtl8723 ${PN}-rtl8821 \
+ ${PN}-rtl8188 ${PN}-rtl8192cu ${PN}-rtl8192ce ${PN}-rtl8192su 
${PN}-rtl8723 ${PN}-rtl8821 \
  ${PN}-rtl8761 \
  ${PN}-rtl8168 \
  ${PN}-rtl8822 \
  ${PN}-rtl-nic \
- ${PN}-cypress-license \
- ${PN}-broadcom-license \
  ${PN}-bcm-0bb4-0306 \
  ${PN}-bcm43143 \
  ${PN}-bcm43236b \
@@ -318,15 +315,13 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-bcm4373 \
  ${PN}-bcm43xx \
  ${PN}-bcm43xx-hdr \
- ${PN}-cirrus-license ${PN}-cirrus \
- ${PN}-cnm-license ${PN}-cnm \
- ${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k 
${PN}-ath9k ${PN}-ath3k \
+ ${PN}-cirrus \
+ ${PN}-cnm \
+ ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k ${PN}-ath9k ${PN}-ath3k \
  ${PN}-carl9170 \
- ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-qca \
- \
- ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
- \
- ${PN}-iwlwifi-license ${PN}-iwlwifi \
+ ${PN}-ar3k ${PN}-ath10k ${PN}-ath11k ${PN}-qca \
+ ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
+ ${PN}-iwlwifi \
  ${PN}-iwlwifi-135-6 \
  ${PN}-iwlwifi-3160-7 ${PN}-iwlwifi-3160-8 ${PN}-iwlwifi-3160-9 \
  ${PN}-iwlwifi-3160-10 ${PN}-iwlwifi-3160-12 ${PN}-iwlwifi-3160-13 
\
@@ -339,23 +334,21 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-iwlwifi-7265d ${PN}-iwlwifi-8000c ${PN}-iwlwifi-8265 \
  ${PN}-iwlwifi-9000 \
  ${PN}-iwlwifi-misc \
- ${PN}-ibt-license ${PN}-ibt \
+ ${PN}-ibt \
  ${PN}-ibt-11-5 ${PN}-ibt-12-16 ${PN}-ibt-hw-37-7 
${PN}-ibt-hw-37-8 \
  ${PN}-ibt-17 \
  ${PN}-ibt-20 \
  ${PN}-ibt-misc \
- ${PN}-i915-license ${PN}-i915 \
- ${PN}-ice-license ${PN}-ice \
- 

[OE-core] [PATCH 3/4] linux-firmware: remove pointless linux-firmware-gplv2-license package

2024-03-07 Thread Ross Burton
From: Ross Burton 

The GPLv2 text is the standard text, so the -carl9170 package can just
set LICENSE=GPL-2.0-or-later and the custom license handling removed.

Confirmed in the source that the intended license is v2-or-later, not
v2-only as WHENCE says.

Signed-off-by: Ross Burton 
---
 .../linux-firmware/linux-firmware_20231211.bb  | 14 --
 1 file changed, 4 insertions(+), 10 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index 54e0dc7dc91..b6b98628f3f 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -28,7 +28,6 @@ LICENSE = "\
 & Firmware-ene_firmware \
 & Firmware-fw_sst_0f28 \
 & Firmware-go7007 \
-& Firmware-GPLv2 \
 & Firmware-hfi1_firmware \
 & Firmware-i915 \
 & Firmware-ibt_firmware \
@@ -77,6 +76,7 @@ LICENSE = "\
 & Firmware-xc5000 \
 & Firmware-xc5000c \
 & WHENCE \
+& GPL-2.0-or-later \
 "
 
 LIC_FILES_CHKSUM = "file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc 
\
@@ -102,7 +102,6 @@ LIC_FILES_CHKSUM = 
"file://LICENCE.Abilis;md5=b5ee3f410780e56711ad48eadc22b8bc \
 
file://LICENCE.ene_firmware;md5=ed67f0f62f8f798130c296720b7d3921 \
 
file://LICENCE.fw_sst_0f28;md5=6353931c988ad52818ae733ac61cd293 \
 file://LICENCE.go7007;md5=c0bb9f6aaaba55b0529ee9b30aa66beb 
\
-file://GPL-2;md5=b234ee4d69f5fce4486a80fdaf4a4263 \
 
file://LICENSE.hfi1_firmware;md5=5e7b6e586ce7339d12689e49931ad444 \
 file://LICENSE.i915;md5=2b0b2e0d20984affd4490ba2cba02570 \
 
file://LICENCE.ibt_firmware;md5=fdbee1ddfe0fb7ab0b2fcd6b454a366b \
@@ -182,7 +181,6 @@ NO_GENERIC_LICENSE[Firmware-e100] = "LICENCE.e100"
 NO_GENERIC_LICENSE[Firmware-ene_firmware] = "LICENCE.ene_firmware"
 NO_GENERIC_LICENSE[Firmware-fw_sst_0f28] = "LICENCE.fw_sst_0f28"
 NO_GENERIC_LICENSE[Firmware-go7007] = "LICENCE.go7007"
-NO_GENERIC_LICENSE[Firmware-GPLv2] = "GPL-2"
 NO_GENERIC_LICENSE[Firmware-hfi1_firmware] = "LICENSE.hfi1_firmware"
 NO_GENERIC_LICENSE[Firmware-i915] = "LICENSE.i915"
 NO_GENERIC_LICENSE[Firmware-ibt_firmware] = "LICENCE.ibt_firmware"
@@ -260,7 +258,7 @@ do_compile() {
 
 do_install() {
 oe_runmake 'DESTDIR=${D}' 
'FIRMWAREDIR=${nonarch_base_libdir}/firmware' ${PACKAGECONFIG_CONFARGS}
-cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
+cp LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
 }
 
 
@@ -323,7 +321,7 @@ PACKAGES =+ "${PN}-amphion-vpu-license ${PN}-amphion-vpu \
  ${PN}-cirrus-license ${PN}-cirrus \
  ${PN}-cnm-license ${PN}-cnm \
  ${PN}-atheros-license ${PN}-ar5523 ${PN}-ar9170 ${PN}-ath6k 
${PN}-ath9k ${PN}-ath3k \
- ${PN}-gplv2-license ${PN}-carl9170 \
+ ${PN}-carl9170 \
  ${PN}-ar3k-license ${PN}-ar3k ${PN}-ath10k-license ${PN}-ath10k 
${PN}-ath11k ${PN}-qca \
  \
  ${PN}-imx-sdma-license ${PN}-imx-sdma-imx6q ${PN}-imx-sdma-imx7d \
@@ -461,15 +459,11 @@ RDEPENDS:${PN}-ath6k += "${PN}-atheros-license"
 RDEPENDS:${PN}-ath9k += "${PN}-atheros-license"
 
 # For carl9170
-LICENSE:${PN}-carl9170 = "Firmware-GPLv2"
-LICENSE:${PN}-gplv2-license = "Firmware-GPLv2"
 
-FILES:${PN}-gplv2-license = "${nonarch_base_libdir}/firmware/GPL-2"
 FILES:${PN}-carl9170 = " \
   ${nonarch_base_libdir}/firmware/carl9170*.fw \
 "
-
-RDEPENDS:${PN}-carl9170 += "${PN}-gplv2-license"
+LICENSE:${PN}-carl9170 = "GPL-2.0-or-later"
 
 # For QualCommAthos
 LICENSE:${PN}-ar3k = "Firmware-qualcommAthos_ar3k & Firmware-atheros_firmware"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196788): 
https://lists.openembedded.org/g/openembedded-core/message/196788
Mute This Topic: https://lists.openembedded.org/mt/104785590/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] linux-firmware: set LICENSE field for -liquidui and -mellanox

2024-03-07 Thread Ross Burton
From: Ross Burton 

Signed-off-by: Ross Burton 
---
 meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index b3884dd3e5a..54e0dc7dc91 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -1481,8 +1481,10 @@ RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-adreno = 
"${PN}-qcom-sc8280xp-lenovo
 RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-compute = 
"${PN}-qcom-sc8280xp-lenovo-x13s-compat"
 RRECOMMENDS:${PN}-qcom-sc8280xp-lenovo-x13s-sensors = 
"${PN}-qcom-sc8280xp-lenovo-x13s-compat"
 
+LICENSE:${PN}-liquidui = "Firmware-cavium_liquidio"
 FILES:${PN}-liquidio = "${nonarch_base_libdir}/firmware/liquidio"
 
+LICENSE:${PN}-mellanox = "WHENCE"
 FILES:${PN}-mellanox = "${nonarch_base_libdir}/firmware/mellanox"
 
 LICENSE:${PN}-prestera = "Firmware-Marvell"
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196787): 
https://lists.openembedded.org/g/openembedded-core/message/196787
Mute This Topic: https://lists.openembedded.org/mt/104785589/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] linux-firmware: add support for deduplicating the firmware

2024-03-07 Thread Ross Burton
From: Ross Burton 

This can a non-trivial amount of disk space, but requires rdfind from
meta-oe. As duplicate pieces of firmware become links, this reduces the
size of individual packages and adds dependencies:

linux-firmware-adsp-sst: PKGSIZE changed from 6362678 to 560 (-12%)
linux-firmware-amdgpu: PKGSIZE changed from 80234502 to 60819841 (-24%)
linux-firmware-cirrus: PKGSIZE changed from 1290908 to 1068886 (-17%)
linux-firmware-ibt-17: PKGSIZE changed from 2601222 to 1300679 (-50%)
linux-firmware-ibt-17: RDEPENDS: added "linux-firmware-ibt-misc"
linux-firmware-ibt-20: PKGSIZE changed from 2399511 to 1599721 (-33%)
linux-firmware-ibt-20: RDEPENDS: added "linux-firmware-ibt-misc"
linux-firmware-ibt-misc: PKGSIZE changed from 22400466 to 13390020 (-40%)
linux-firmware-ibt-misc: RDEPENDS: added "linux-firmware-ibt-17"
linux-firmware-qcom-qrb4210-audio: RDEPENDS: added 
"linux-firmware-qcom-qcm2290-audio"
linux-firmware-qcom-qrb4210-modem: PKGSIZE changed from 8882947 to 63 (-100%)
linux-firmware-qcom-qrb4210-modem: RDEPENDS: added 
"linux-firmware-qcom-qcm2290-modem"
linux-firmware-qcom-sdm845-audio: RDEPENDS: added 
"linux-firmware-qcom-qcm2290-audio"
linux-firmware-qcom-sdm845-compute: RDEPENDS: added 
"linux-firmware-qcom-qrb4210-compute"
linux-firmware-qcom-sdm845-modem: RDEPENDS: added 
"linux-firmware-qcom-qcm2290-modem"
linux-firmware-qcom-sm8250-audio: RDEPENDS: added 
"linux-firmware-qcom-qcm2290-audio"
linux-firmware-qcom-sm8250-compute: RDEPENDS: added 
"linux-firmware-qcom-qrb4210-compute"
linux-firmware-qcom-sm8250-thundercomm-rb5-sensors: RDEPENDS: added 
"linux-firmware-qcom-sdm845-thundercomm-db845c-sensors"
linux-firmware-radeon: PKGSIZE changed from 7105560 to 3343141 (-53%)
linux-firmware-radeon: RDEPENDS: added "linux-firmware-amdgpu"
linux-firmware-rtl8822: RDEPENDS: added "linux-firmware-rtl8761"
linux-firmware-sd8688: RDEPENDS: added "linux-firmware"
linux-firmware: RDEPENDS: added "linux-firmware-rtl8761"

Signed-off-by: Ross Burton 
---
 .../linux-firmware/linux-firmware_20231211.bb | 8 ++--
 1 file changed, 6 insertions(+), 2 deletions(-)

diff --git a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb 
b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
index 3a3690bdc1b..b3884dd3e5a 100644
--- a/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
+++ b/meta/recipes-kernel/linux-firmware/linux-firmware_20231211.bb
@@ -249,13 +249,17 @@ inherit allarch
 
 CLEANBROKEN = "1"
 
+# Use PACKAGECONFIG_CONFARGS to set the Makefile target
+PACKAGECONFIG ??= ""
+# Enabling dedup will turn duplicate firmware files into links
+PACKAGECONFIG[deduplicate] = "install,install-nodedup,rdfind-native"
+
 do_compile() {
:
 }
 
 do_install() {
-# install-nodedup avoids rdfind dependency
-oe_runmake 'DESTDIR=${D}' 
'FIRMWAREDIR=${nonarch_base_libdir}/firmware' install-nodedup
+oe_runmake 'DESTDIR=${D}' 
'FIRMWAREDIR=${nonarch_base_libdir}/firmware' ${PACKAGECONFIG_CONFARGS}
 cp GPL-2 LICEN[CS]E.* WHENCE ${D}${nonarch_base_libdir}/firmware/
 }
 
-- 
2.34.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196786): 
https://lists.openembedded.org/g/openembedded-core/message/196786
Mute This Topic: https://lists.openembedded.org/mt/104785588/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Alexander Kanavin
On Thu, 7 Mar 2024 at 11:21, Chen Qi via lists.openembedded.org
 wrote:
> You can see dnf's solution is: 
> https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
>
> I don't think dnf community will look into this issue. And I would expect it 
> to be a complicated one. Because dnf's own solution looks like more of a 
> workaround. At the same time, yocto based systems will sometimes have 
> log_lock.pid left in target filesystems. Users typing 'ls /' will notice it.
>
> We have an OE specific patch: 
> https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
> I can see that this OE specific patch, 
> 0001-dnf-write-the-log-lock-to-root.patch, does solve some issue. 
> Unfortunately, at the same time, it introduces this specific issue, a 
> easy-to-notice one.
>
> My suggestion is that we merge this fix into 
> 0001-dnf-write-the-log-lock-to-root.patch, because they really belong 
> together. I guess we can't expect dnf community to devote time into this, as 
> they've already got a solution. And I'm not sure if anyone in OE community is 
> familiar with dnf enough to solve this issue. So let's make things a little 
> better, avoiding users of Yocto systems see this log_lock.pid file when they 
> type 'ls /'.
>
> If you have any other suggestion, please let us know.

We need to find out why it happens, and why it happens only sometimes.
If lock file does not get properly deleted that is quite possibly
masking a different issue which needs fixing, and the proposed patch
just sweeps it all under the carpet in the name of giving users an
aesthetically pleasing rootfs. So the answer is still no.

If you are having difficulty debugging the situation where the lock
file does get left behind, can you provide a way for me to reproduce
the issue? I just build core-image-minimal, and I'm not seeing it:

alex@Zen2:/srv/storage/alex/yocto/build-64-alt$ ls
tmp/work/qemux86_64-poky-linux/core-image-minimal/1.0/rootfs/
bin  boot  dev  etc  home  lib  media  mnt  proc  root  run  sbin  srv
 sys  tmp  usr  var

If you can't provide that, then you can certainly still do more on
your side: build core-image-minimal with plain poky, ensure the lock
file gets deleted, then build your own private things where the file
does not get deleted, then investigate why the code path that deletes
the lock file isn't being taken in the latter case. You can see the
code where the lock log (self.rotate_lock) is used in logging.py:

def emit(self, record):
while True:
try:
if self.shouldRollover(record):
with self.rotate_lock:
# Do rollover while preserving the mode of the
new log file
mode = os.stat(self.baseFilename).st_mode
self.doRollover()
os.chmod(self.baseFilename, mode)
logging.FileHandler.emit(self, record)
return
except (dnf.exceptions.ProcessLockError,
dnf.exceptions.ThreadLockError):
time.sleep(0.01)
except Exception:
self.handleError(record)
return

And the deletion happens in lock.py:

def __exit__(self, *exc_args):
if self.count == 1:
os.unlink(self.target)
self._unlock_thread()



Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196785): 
https://lists.openembedded.org/g/openembedded-core/message/196785
Mute This Topic: https://lists.openembedded.org/mt/104784184/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Chen Qi via lists.openembedded.org
Hi Alex,

You can see dnf's solution is: 
https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf

I don't think dnf community will look into this issue. And I would expect it to 
be a complicated one. Because dnf's own solution looks like more of a 
workaround. At the same time, yocto based systems will sometimes have 
log_lock.pid left in target filesystems. Users typing 'ls /' will notice it.

We have an OE specific patch: 
https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
I can see that this OE specific patch, 
0001-dnf-write-the-log-lock-to-root.patch, does solve some issue. 
Unfortunately, at the same time, it introduces this specific issue, a 
easy-to-notice one. 

My suggestion is that we merge this fix into 
0001-dnf-write-the-log-lock-to-root.patch, because they really belong together. 
I guess we can't expect dnf community to devote time into this, as they've 
already got a solution. And I'm not sure if anyone in OE community is familiar 
with dnf enough to solve this issue. So let's make things a little better, 
avoiding users of Yocto systems see this log_lock.pid file when they type 'ls 
/'.

If you have any other suggestion, please let us know.

Regards,
Qi


-Original Message-
From: openembedded-core@lists.openembedded.org 
 On Behalf Of Alexander Kanavin via 
lists.openembedded.org
Sent: Thursday, March 7, 2024 5:57 PM
To: Li, Changqing ; Richard Purdie 

Cc: openembedded-core@lists.openembedded.org
Subject: Re: [OE-core] [PATCH V2] dnf: remove log_lock.pid before exit

On Thu, 7 Mar 2024 at 10:19, Changqing Li  
wrote:
> ++for arg in args:
> ++if arg.startswith("--installroot="):
> ++root=arg.split("=")[1]
> ++if os.path.exists(os.path.join(root, "log_lock.pid")):
> ++os.unlink(os.path.join(root, "log_lock.pid"))
> ++break

Apologies, but after looking at this more carefully I have to say no once more. 
The obstacle is that the code checks for existence before removing the lock, 
which means the issue of why the lock is left in place to begin with is still 
unresolved. This doesn't always happen, and we need to get to the bottom of 
*why*.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196784): 
https://lists.openembedded.org/g/openembedded-core/message/196784
Mute This Topic: https://lists.openembedded.org/mt/104784184/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.bbclass: set GOPROXY

2024-03-07 Thread Jose Quaresma
The GOPROXY is already correctly defined on the native sys root
and this can be checked using the bitbake devshell:

| $ go env GOPROXY
| https://proxy.golang.org,direct

The go_do_compile task calls the compiler directly so the
GOPROXY env is not seen because it's not defined in the shell.
Defining it explicitly solves this problem and was to avoid
setting it in the recipes itself.

Signed-off-by: Jose Quaresma 
---
 meta/classes-recipe/go.bbclass | 1 +
 1 file changed, 1 insertion(+)

diff --git a/meta/classes-recipe/go.bbclass b/meta/classes-recipe/go.bbclass
index 39bfaa5156..cc3564c36a 100644
--- a/meta/classes-recipe/go.bbclass
+++ b/meta/classes-recipe/go.bbclass
@@ -78,6 +78,7 @@ GO_INSTALL_FILTEROUT ?= "${GO_IMPORT}/vendor/"
 B = "${WORKDIR}/build"
 export GOPATH = "${B}"
 export GOENV = "off"
+export GOPROXY ??= "https://proxy.golang.org,direct;
 export GOTMPDIR ?= "${WORKDIR}/build-tmp"
 GOTMPDIR[vardepvalue] = ""
 
-- 
2.44.0


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196783): 
https://lists.openembedded.org/g/openembedded-core/message/196783
Mute This Topic: https://lists.openembedded.org/mt/104784533/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Alexander Kanavin
On Thu, 7 Mar 2024 at 10:19, Changqing Li
 wrote:
> ++for arg in args:
> ++if arg.startswith("--installroot="):
> ++root=arg.split("=")[1]
> ++if os.path.exists(os.path.join(root, "log_lock.pid")):
> ++os.unlink(os.path.join(root, "log_lock.pid"))
> ++break

Apologies, but after looking at this more carefully I have to say no
once more. The obstacle is that the code checks for existence before
removing the lock, which means the issue of why the lock is left in
place to begin with is still unresolved. This doesn't always happen,
and we need to get to the bottom of *why*.

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196782): 
https://lists.openembedded.org/g/openembedded-core/message/196782
Mute This Topic: https://lists.openembedded.org/mt/104784184/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Alexander Kanavin
On Thu, 7 Mar 2024 at 10:19, Changqing Li
 wrote:
> +Upstream-Status: Inappropriate [oe specific workaround]

You *just* said you will send this upstream as requested. Why is it
suddenly Inappropriate?

Alex

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196781): 
https://lists.openembedded.org/g/openembedded-core/message/196781
Mute This Topic: https://lists.openembedded.org/mt/104784184/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 V2] dnf: remove log_lock.pid before exit

2024-03-07 Thread Changqing Li
From: Changqing Li 

dnf has a bug, refer [1], it causes that log_lock.pid may not removed
after dnf exit. And for native dnf, since we change the lock file path
to /, it will never be removed, and make the rootfs not clean,refer
[2][3].  This patch is a workaround to fix above issue.

[1] https://github.com/rpm-software-management/dnf/issues/1963
[2] 
https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
[3] 
https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf

Signed-off-by: Changqing Li 
---
 ...n.py-remove-log_lock.pid-before-exit.patch | 41 +++
 meta/recipes-devtools/dnf/dnf_4.18.2.bb   |  3 +-
 2 files changed, 43 insertions(+), 1 deletion(-)
 create mode 100644 
meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch

diff --git 
a/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
 
b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
new file mode 100644
index 00..2dd4969d57
--- /dev/null
+++ 
b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
@@ -0,0 +1,41 @@
+From bdf17281385cf33ad59267fe75a9e427e6e2ffc4 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 7 Mar 2024 14:03:07 +0800
+Subject: [PATCH] main.py: remove log_lock.pid before exit
+
+dnf has a bug, refer [1], it causes that log_lock.pid may not removed
+after dnf exit. And for native dnf, since we change the lock file path
+to /, it will never be removed, and make the rootfs not clean,refer
+[2][3].  This patch is a workaround to fix above issue.
+
+[1] https://github.com/rpm-software-management/dnf/issues/1963
+[2] 
https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
+[3] 
https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
+
+Upstream-Status: Inappropriate [oe specific workaround]
+
+Signed-off-by: Changqing Li 
+---
+ dnf/cli/main.py | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/dnf/cli/main.py b/dnf/cli/main.py
+index 2a7f92d54..2f672cff2 100644
+--- a/dnf/cli/main.py
 b/dnf/cli/main.py
+@@ -200,6 +200,12 @@ def user_main(args, exit_code=False):
+ 
+ errcode = main(args)
+ if exit_code:
++for arg in args:
++if arg.startswith("--installroot="):
++root=arg.split("=")[1]
++if os.path.exists(os.path.join(root, "log_lock.pid")):
++os.unlink(os.path.join(root, "log_lock.pid"))
++break
+ sys.exit(errcode)
+ return errcode
+ 
+-- 
+2.25.1
+
diff --git a/meta/recipes-devtools/dnf/dnf_4.18.2.bb 
b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
index dc0c18be5e..7770c9d7e0 100644
--- a/meta/recipes-devtools/dnf/dnf_4.18.2.bb
+++ b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
@@ -17,7 +17,8 @@ SRC_URI = 
"git://github.com/rpm-software-management/dnf.git;branch=master;protoc
file://0001-set-python-path-for-completion_helper.patch \
"
 
-SRC_URI:append:class-native = 
"file://0001-dnf-write-the-log-lock-to-root.patch"
+SRC_URI:append:class-native = 
"file://0001-dnf-write-the-log-lock-to-root.patch \
+   
file://0001-main.py-remove-log_lock.pid-before-exit.patch"
 
 SRCREV = "1c43d0999178d492381ad0b43917ffd9c74016f8"
 UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
-- 
2.25.1


-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196780): 
https://lists.openembedded.org/g/openembedded-core/message/196780
Mute This Topic: https://lists.openembedded.org/mt/104784184/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Changqing Li


On 3/7/24 16:14, 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.

Thanks, the patch is ok, but you need to actually open a dnf pull
request with the patch, and not just the ticket (also 'Submitted'
means that the patch was actually provided to upstream). It's okay if
upstream then rejects the patch. We'll at least try to convince them
:)

Alex


ok, I will send an pull request and send a v2 with the pull request.

Thanks

Changqing



On Thu, 7 Mar 2024 at 07:49, Changqing Li
 wrote:

From: Changqing Li 

dnf has a bug, refer [1], it causes that log_lock.pid may not removed
after dnf exit. And for native dnf, since we change the lock file path
to /, it will never be removed, and make the rootfs not clean,refer
[2][3].  This patch is a workaround to fix above issue.

[1] https://github.com/rpm-software-management/dnf/issues/1963
[2] 
https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
[3] 
https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf

Signed-off-by: Changqing Li 
---
  ...n.py-remove-log_lock.pid-before-exit.patch | 41 +++
  meta/recipes-devtools/dnf/dnf_4.18.2.bb   |  3 +-
  2 files changed, 43 insertions(+), 1 deletion(-)
  create mode 100644 
meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch

diff --git 
a/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
 
b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
new file mode 100644
index 00..ae036cbbd6
--- /dev/null
+++ 
b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
@@ -0,0 +1,41 @@
+From bdf17281385cf33ad59267fe75a9e427e6e2ffc4 Mon Sep 17 00:00:00 2001
+From: Changqing Li 
+Date: Thu, 7 Mar 2024 14:03:07 +0800
+Subject: [PATCH] main.py: remove log_lock.pid before exit
+
+dnf has a bug, refer [1], it causes that log_lock.pid may not removed
+after dnf exit. And for native dnf, since we change the lock file path
+to /, it will never be removed, and make the rootfs not clean,refer
+[2][3].  This patch is a workaround to fix above issue.
+
+[1] https://github.com/rpm-software-management/dnf/issues/1963
+[2] 
https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
+[3] 
https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
+
+Upstream-Status: Submited [ report to 
https://github.com/rpm-software-management/dnf/issues/1963]
+
+Signed-off-by: Changqing Li 
+---
+ dnf/cli/main.py | 6 ++
+ 1 file changed, 6 insertions(+)
+
+diff --git a/dnf/cli/main.py b/dnf/cli/main.py
+index 2a7f92d54..2f672cff2 100644
+--- a/dnf/cli/main.py
 b/dnf/cli/main.py
+@@ -200,6 +200,12 @@ def user_main(args, exit_code=False):
+
+ errcode = main(args)
+ if exit_code:
++for arg in args:
++if arg.startswith("--installroot="):
++root=arg.split("=")[1]
++if os.path.exists(os.path.join(root, "log_lock.pid")):
++os.unlink(os.path.join(root, "log_lock.pid"))
++break
+ sys.exit(errcode)
+ return errcode
+
+--
+2.25.1
+
diff --git a/meta/recipes-devtools/dnf/dnf_4.18.2.bb 
b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
index dc0c18be5e..7770c9d7e0 100644
--- a/meta/recipes-devtools/dnf/dnf_4.18.2.bb
+++ b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
@@ -17,7 +17,8 @@ SRC_URI = 
"git://github.com/rpm-software-management/dnf.git;branch=master;protoc
 file://0001-set-python-path-for-completion_helper.patch \
 "

-SRC_URI:append:class-native = 
"file://0001-dnf-write-the-log-lock-to-root.patch"
+SRC_URI:append:class-native = 
"file://0001-dnf-write-the-log-lock-to-root.patch \
+   
file://0001-main.py-remove-log_lock.pid-before-exit.patch"

  SRCREV = "1c43d0999178d492381ad0b43917ffd9c74016f8"
  UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
--
2.25.1








-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196779): 
https://lists.openembedded.org/g/openembedded-core/message/196779
Mute This Topic: https://lists.openembedded.org/mt/104782944/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] image_types_wic.bbclass: remove .env file in do_clean

2024-03-07 Thread Mauro

On 06/03/24 17:57, Richard Purdie wrote:

On Wed, 2024-03-06 at 08:37 -0800, Mauro wrote:

Before this commit, the .env file created in
tmp/sysroots//imgdata/.env was never cleaned,
but when the do_clean task is invoked on an image, the .env file
contains paths that are not valid anymore.
If another image wants to use the cleaned image fs to build a .wic,
the wic command fails because paths contained in .env are not found.
With this patch, the returned error is more clear:

   "File /.../tmp/sysroots//imgdata/.env doesn't
exist"

Signed-off-by: Mauro Salvini 
---
  meta/classes-recipe/image_types_wic.bbclass | 11 +++
  1 file changed, 11 insertions(+)

diff --git a/meta/classes-recipe/image_types_wic.bbclass
b/meta/classes-recipe/image_types_wic.bbclass
index cf3be909b3..b0b5691225 100644
--- a/meta/classes-recipe/image_types_wic.bbclass
+++ b/meta/classes-recipe/image_types_wic.bbclass
@@ -205,3 +205,14 @@ addtask do_flush_pseudodb after do_rootfs before
do_image do_image_qa
  addtask do_rootfs_wicenv after do_image before do_image_wic
  do_rootfs_wicenv[vardeps] += "${WICVARS}"
  do_rootfs_wicenv[prefuncs] = 'set_image_size'
+
+#
+# Clean also .env file created in
tmp/sysroots//imgdata/.env
+# when a clean is invoked
+#
+do_clean:append() {
+    stdir = d.getVar('STAGING_DIR')
+    outdir = os.path.join(stdir, d.getVar('MACHINE'), 'imgdata')
+    basename = d.getVar('IMAGE_BASENAME')
+    bb.utils.remove(os.path.join(outdir, basename) + '.env')
+}


This doesn't look right unfortunately.

Things should not be being placed into the sysroots (STAGING_DIR) that
aren't under the control of sstate. If things are, we need to fix that
at the source of the problem.

Cheers,

Richard



Hi Richard,

thank you.

If I understood correctly, your suggestion is to create the .env file in 
WORKDIR instead of in the STAGING_DIR, and use 
tmp/deploy/images//.env (now copied from STAGING_DIR, 
after copied from WORKDIR) when creating the wic file. If this is the 
right way, I can try to produce a patch.


Thanks. regards

--
Mauro




-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196778): 
https://lists.openembedded.org/g/openembedded-core/message/196778
Mute This Topic: https://lists.openembedded.org/mt/104769309/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 V7] rxvt-unicode: Fix installing of terminfo

2024-03-07 Thread Alexander Kanavin
Thanks, this is fine.

Alex

On Thu, 7 Mar 2024 at 07:50, Changqing Li
 wrote:
>
> From: Changqing Li 
>
> For cross compile, TIC will be native tic in recipe-sysroot-native, and
> the terminfo path will be native path, the rxvt-unicode terminfo will be
> wrongly installed to native path.
>
> install terminfo to correct path in do_install
>
> Signed-off-by: Changqing Li 
> ---
>  meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc | 7 +--
>  1 file changed, 5 insertions(+), 2 deletions(-)
>
> diff --git a/meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc 
> b/meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc
> index e7d520ebef..016614b19c 100644
> --- a/meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc
> +++ b/meta/recipes-sato/rxvt-unicode/rxvt-unicode.inc
> @@ -6,7 +6,7 @@ terminal emulator rxvt, modified to store text in Unicode \
>  output. It also supports mixing multiple fonts at the \
>  same time, including Xft fonts."
>  HOMEPAGE = "https://rxvt.org/;
> -DEPENDS = "virtual/libx11 libxt libxft gdk-pixbuf libxmu libptytty"
> +DEPENDS = "virtual/libx11 libxt libxft gdk-pixbuf libxmu libptytty 
> ncurses-native"
>
>  SRC_URI = 
> "http://dist.schmorp.de/rxvt-unicode/Attic/rxvt-unicode-${PV}.tar.bz2 \
>file://xwc.patch \
> @@ -53,6 +53,9 @@ do_install:append () {
>
> install -m 0644 ${WORKDIR}/rxvt.png ${D}/${datadir}/pixmaps
> install -m 0644 ${WORKDIR}/rxvt.desktop ${D}/${datadir}/applications
> +
> +   ${STAGING_BINDIR_NATIVE}/tic -x ${S}/doc/etc/rxvt-unicode.terminfo -o 
> ${D}${datadir}/terminfo || \
> +   ${STAGING_BINDIR_NATIVE}/tic ${S}/doc/etc/rxvt-unicode.terminfo -o 
> ${D}${datadir}/terminfo
>  }
>
> -FILES:${PN} += "${datadir}/applications/rxvt.desktop 
> ${datadir}/pixmaps/rxvt.png"
> +FILES:${PN} += "${datadir}/applications/rxvt.desktop 
> ${datadir}/pixmaps/rxvt.png ${datadir}/terminfo"
> --
> 2.25.1
>
>
> 
>

-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#196777): 
https://lists.openembedded.org/g/openembedded-core/message/196777
Mute This Topic: https://lists.openembedded.org/mt/104782953/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] dnf: remove log_lock.pid before exit

2024-03-07 Thread Alexander Kanavin
Thanks, the patch is ok, but you need to actually open a dnf pull
request with the patch, and not just the ticket (also 'Submitted'
means that the patch was actually provided to upstream). It's okay if
upstream then rejects the patch. We'll at least try to convince them
:)

Alex

On Thu, 7 Mar 2024 at 07:49, Changqing Li
 wrote:
>
> From: Changqing Li 
>
> dnf has a bug, refer [1], it causes that log_lock.pid may not removed
> after dnf exit. And for native dnf, since we change the lock file path
> to /, it will never be removed, and make the rootfs not clean,refer
> [2][3].  This patch is a workaround to fix above issue.
>
> [1] https://github.com/rpm-software-management/dnf/issues/1963
> [2] 
> https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
> [3] 
> https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
>
> Signed-off-by: Changqing Li 
> ---
>  ...n.py-remove-log_lock.pid-before-exit.patch | 41 +++
>  meta/recipes-devtools/dnf/dnf_4.18.2.bb   |  3 +-
>  2 files changed, 43 insertions(+), 1 deletion(-)
>  create mode 100644 
> meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
>
> diff --git 
> a/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
>  
> b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
> new file mode 100644
> index 00..ae036cbbd6
> --- /dev/null
> +++ 
> b/meta/recipes-devtools/dnf/dnf/0001-main.py-remove-log_lock.pid-before-exit.patch
> @@ -0,0 +1,41 @@
> +From bdf17281385cf33ad59267fe75a9e427e6e2ffc4 Mon Sep 17 00:00:00 2001
> +From: Changqing Li 
> +Date: Thu, 7 Mar 2024 14:03:07 +0800
> +Subject: [PATCH] main.py: remove log_lock.pid before exit
> +
> +dnf has a bug, refer [1], it causes that log_lock.pid may not removed
> +after dnf exit. And for native dnf, since we change the lock file path
> +to /, it will never be removed, and make the rootfs not clean,refer
> +[2][3].  This patch is a workaround to fix above issue.
> +
> +[1] https://github.com/rpm-software-management/dnf/issues/1963
> +[2] 
> https://git.openembedded.org/openembedded-core/commit/?id=742a1b71249f4da1c8d8e13e270b0eb6128a3f66
> +[3] 
> https://github.com/rpm-software-management/dnf/blob/master/etc/tmpfiles.d/dnf.conf
> +
> +Upstream-Status: Submited [ report to 
> https://github.com/rpm-software-management/dnf/issues/1963]
> +
> +Signed-off-by: Changqing Li 
> +---
> + dnf/cli/main.py | 6 ++
> + 1 file changed, 6 insertions(+)
> +
> +diff --git a/dnf/cli/main.py b/dnf/cli/main.py
> +index 2a7f92d54..2f672cff2 100644
> +--- a/dnf/cli/main.py
>  b/dnf/cli/main.py
> +@@ -200,6 +200,12 @@ def user_main(args, exit_code=False):
> +
> + errcode = main(args)
> + if exit_code:
> ++for arg in args:
> ++if arg.startswith("--installroot="):
> ++root=arg.split("=")[1]
> ++if os.path.exists(os.path.join(root, "log_lock.pid")):
> ++os.unlink(os.path.join(root, "log_lock.pid"))
> ++break
> + sys.exit(errcode)
> + return errcode
> +
> +--
> +2.25.1
> +
> diff --git a/meta/recipes-devtools/dnf/dnf_4.18.2.bb 
> b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
> index dc0c18be5e..7770c9d7e0 100644
> --- a/meta/recipes-devtools/dnf/dnf_4.18.2.bb
> +++ b/meta/recipes-devtools/dnf/dnf_4.18.2.bb
> @@ -17,7 +17,8 @@ SRC_URI = 
> "git://github.com/rpm-software-management/dnf.git;branch=master;protoc
> file://0001-set-python-path-for-completion_helper.patch \
> "
>
> -SRC_URI:append:class-native = 
> "file://0001-dnf-write-the-log-lock-to-root.patch"
> +SRC_URI:append:class-native = 
> "file://0001-dnf-write-the-log-lock-to-root.patch \
> +   
> file://0001-main.py-remove-log_lock.pid-before-exit.patch"
>
>  SRCREV = "1c43d0999178d492381ad0b43917ffd9c74016f8"
>  UPSTREAM_CHECK_GITTAGREGEX = "(?P\d+(\.\d+)+)"
> --
> 2.25.1
>
>
> 
>

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