Re: [OE-core] [PATCH 1/2] musl: Update to latest tip of trunk
Hello,
ofonod on qemux86-64 doesn't like this series:
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/8776/steps/13/logs/stdio
On 15/02/2024 09:02:00-0800, Khem Raj wrote:
> Do not use https protocol for fetching
>
> Musl author confirms that https protocol is not well supported yet on
> musl git host, currently we experience this problem intermittently on
> some build hosts where the fetching fails.
>
> fatal: protocol error: bad line length character: erro
> WARNING: Failed to fetch URL
> git://git.etalabs.net/git/musl;branch=master;protocol=https
>
> Brings these changes
>
> * cf91e9b3 fix erroneous feature test macro check for ppoll
> * 39838619 syslog: use C locale for timestamp generation
> * 8b704868 stdc-predef.h: prevent redefining __STDC_UTF_{16,32}__ macros
> * 407aea62 riscv: add TLSDESC support
> * 2e1bb87a install.sh: avoid creating symlinks with restricted permissions
> * 0e330722 sqrtl: fix invalid use of a non-constant-expression as static
> initializer
> * bd3138b7 riscv: correct symbol version of __vdso_flush_icache
> * 15aa7abd elf.h: add NT_RISCV_CSR and NT_RISCV_VECTOR constants
> * 25c41236 elf.h: update RISC-V relocation types
> * 81cced6e add preadv2 and pwritev2 syscall wrappers, flag value macros
> * f247462b expose ppoll in default feature profile
> * 07af0181 move ppoll from src/linux to src/select reflecting future
> standardization
> * 11fb3832 remove INT_MAX limit on the n argument to snprintf/swprintf
> * f47a5d40 strftime: don't attempt to parse field width without seeing a digit
> * f314e133 mntent: fields are delimited only by tabs or spaces, not general
> whitespace
> * ee1d39bc mntent: unescape octal sequences
> * e17b9d74 ldso: fix TLSDESC addend processing on archs with backwards
> descriptors
> * 039d3c34 ldso: convert TLSDESC_BACKWARDS from "#ifdef" to "if" logic
> * 7b6a6516 byte-based printf family: emit a nul byte for %lc with argument
> zero
> * 8c086e76 remove arbitrary limit from dns result parsing
> * 2265a4c9 pass AT_NO_AUTOMOUNT when emulating fstatat via statx
> * 2d84486a __year_to_secs: fix dangling pointer
> * c5459df1 timer_create: volatile static -> static volatile
> * 7bb11f75 ensure valid setxid return value in an unexpected error case
> * 7f3a2925 synccall: add separate exit_sem to fix thread release logic bug
> * 5baf2d92 ldso: use __ehdr_start if available to locate its own ELF headers
> * 725e17ed remove non-prototype declaration of basename from string.h
> * 6be76895 elf.h: add typedefs for Elf64_Relr and Elf32_Relr
>
> Signed-off-by: Khem Raj
>
> Signed-off-by: Khem Raj
> ---
> ...ic-linker-a-relative-symlink-to-libc.patch | 12 +++---
> ...ir-and-libdir-as-default-pathes-to-l.patch | 10 ++---
> ...pedefs-for-Elf64_Relr-and-Elf32_Relr.patch | 37 ---
> meta/recipes-core/musl/musl_git.bb| 5 +--
> 4 files changed, 13 insertions(+), 51 deletions(-)
> delete mode 100644
> meta/recipes-core/musl/musl/0003-elf.h-add-typedefs-for-Elf64_Relr-and-Elf32_Relr.patch
>
> diff --git
> a/meta/recipes-core/musl/musl/0001-Make-dynamic-linker-a-relative-symlink-to-libc.patch
>
> b/meta/recipes-core/musl/musl/0001-Make-dynamic-linker-a-relative-symlink-to-libc.patch
> index 8b097f32768..06ab27f0eb4 100644
> ---
> a/meta/recipes-core/musl/musl/0001-Make-dynamic-linker-a-relative-symlink-to-libc.patch
> +++
> b/meta/recipes-core/musl/musl/0001-Make-dynamic-linker-a-relative-symlink-to-libc.patch
> @@ -1,4 +1,4 @@
> -From f95b6fd0475a95c00e886219271cb5c93838e3c3 Mon Sep 17 00:00:00 2001
> +From 665ecc610c261d5e98710aa0c6ccf6e4991eaf58 Mon Sep 17 00:00:00 2001
> From: Amarnath Valluri
> Date: Wed, 18 Jan 2017 16:14:37 +0200
> Subject: [PATCH 1/2] Make dynamic linker a relative symlink to libc
> @@ -35,7 +35,7 @@ index e8cc4436..466d9afd 100644
> install-libs: $(ALL_LIBS:lib/%=$(DESTDIR)$(libdir)/%) $(if
> $(SHARED_LIBS),$(DESTDIR)$(LDSO_PATHNAME),)
>
> diff --git a/tools/install.sh b/tools/install.sh
> -index d913b60b..b6a7f797 100755
> +index 855a8ca2..a2e6a5eb 100755
> --- a/tools/install.sh
> +++ b/tools/install.sh
> @@ -6,18 +6,20 @@
> @@ -61,15 +61,15 @@ index d913b60b..b6a7f797 100755
> m) mode=$OPTARG ;;
> ?) usage ;;
> esac
> -@@ -48,7 +50,7 @@ trap 'rm -f "$tmp"' EXIT INT QUIT TERM HUP
> - umask 077
> +@@ -49,7 +51,7 @@ umask 077
>
> if test "$symlink" ; then
> + umask 000
> -ln -s "$1" "$tmp"
> +ln $symlinkflags "$1" "$tmp"
> + umask 077
> else
> cat < "$1" > "$tmp"
> - chmod "$mode" "$tmp"
> --
> -2.37.2
> +2.43.0
>
> diff --git
> a/meta/recipes-core/musl/musl/0002-ldso-Use-syslibdir-and-libdir-as-default-pathes-to-l.patch
>
> b/meta/recipes-core/musl/musl/0002-ldso-Use-syslibdir-and-libdir-as-default-pathes-to-l.patch
> index 59bfae5a27c..04630b32ee9 100644
> ---
> a/meta/recipes-core/musl/musl/0002-ldso-Use-syslibdir-and-libdir-as-default-pathes-to-l.patch
> +++
>
[OE-core] [PATCH 1/2] wic: bootimg-partition allow to set var to get boot files
This is a generic functionality that takes a set of files and create a
boot parition based on IMAGE_BOOT_FILES var, allow to sepcify the
variable name so a BSP plugin can extend this and re-use the
functionality.
Signed-off-by: Anibal Limon
---
scripts/lib/wic/plugins/source/bootimg-partition.py | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py
b/scripts/lib/wic/plugins/source/bootimg-partition.py
index 58f6da72c3..1071d1af3f 100644
--- a/scripts/lib/wic/plugins/source/bootimg-partition.py
+++ b/scripts/lib/wic/plugins/source/bootimg-partition.py
@@ -32,6 +32,7 @@ class BootimgPartitionPlugin(SourcePlugin):
"""
name = 'bootimg-partition'
+image_boot_files_var_name = 'IMAGE_BOOT_FILES'
@classmethod
def do_configure_partition(cls, part, source_params, cr, cr_workdir,
@@ -56,12 +57,12 @@ class BootimgPartitionPlugin(SourcePlugin):
else:
var = ""
-boot_files = get_bitbake_var("IMAGE_BOOT_FILES" + var)
+boot_files = get_bitbake_var(cls.image_boot_files_var_name + var)
if boot_files is not None:
break
if boot_files is None:
-raise WicError('No boot files defined, IMAGE_BOOT_FILES unset for
entry #%d' % part.lineno)
+raise WicError('No boot files defined, %s unset for entry #%d' %
(cls.image_boot_files_var_name, part.lineno))
logger.debug('Boot files: %s', boot_files)
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197470):
https://lists.openembedded.org/g/openembedded-core/message/197470
Mute This Topic: https://lists.openembedded.org/mt/105108997/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH 2/2] wic: plugins source bootimage/isoimage rename to allow be imported
Python not support importing modules with - so change to _.
Signed-off-by: Anibal Limon
---
.../source/{bootimg-biosplusefi.py => bootimg_biosplusefi.py} | 0
scripts/lib/wic/plugins/source/{bootimg-efi.py => bootimg_efi.py} | 0
.../plugins/source/{bootimg-partition.py => bootimg_partition.py} | 0
.../wic/plugins/source/{bootimg-pcbios.py => bootimg_pcbios.py} | 0
.../source/{isoimage-isohybrid.py => isoimage_isohybrid.py} | 0
5 files changed, 0 insertions(+), 0 deletions(-)
rename scripts/lib/wic/plugins/source/{bootimg-biosplusefi.py =>
bootimg_biosplusefi.py} (100%)
rename scripts/lib/wic/plugins/source/{bootimg-efi.py => bootimg_efi.py} (100%)
rename scripts/lib/wic/plugins/source/{bootimg-partition.py =>
bootimg_partition.py} (100%)
rename scripts/lib/wic/plugins/source/{bootimg-pcbios.py => bootimg_pcbios.py}
(100%)
rename scripts/lib/wic/plugins/source/{isoimage-isohybrid.py =>
isoimage_isohybrid.py} (100%)
diff --git a/scripts/lib/wic/plugins/source/bootimg-biosplusefi.py
b/scripts/lib/wic/plugins/source/bootimg_biosplusefi.py
similarity index 100%
rename from scripts/lib/wic/plugins/source/bootimg-biosplusefi.py
rename to scripts/lib/wic/plugins/source/bootimg_biosplusefi.py
diff --git a/scripts/lib/wic/plugins/source/bootimg-efi.py
b/scripts/lib/wic/plugins/source/bootimg_efi.py
similarity index 100%
rename from scripts/lib/wic/plugins/source/bootimg-efi.py
rename to scripts/lib/wic/plugins/source/bootimg_efi.py
diff --git a/scripts/lib/wic/plugins/source/bootimg-partition.py
b/scripts/lib/wic/plugins/source/bootimg_partition.py
similarity index 100%
rename from scripts/lib/wic/plugins/source/bootimg-partition.py
rename to scripts/lib/wic/plugins/source/bootimg_partition.py
diff --git a/scripts/lib/wic/plugins/source/bootimg-pcbios.py
b/scripts/lib/wic/plugins/source/bootimg_pcbios.py
similarity index 100%
rename from scripts/lib/wic/plugins/source/bootimg-pcbios.py
rename to scripts/lib/wic/plugins/source/bootimg_pcbios.py
diff --git a/scripts/lib/wic/plugins/source/isoimage-isohybrid.py
b/scripts/lib/wic/plugins/source/isoimage_isohybrid.py
similarity index 100%
rename from scripts/lib/wic/plugins/source/isoimage-isohybrid.py
rename to scripts/lib/wic/plugins/source/isoimage_isohybrid.py
--
2.43.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197471):
https://lists.openembedded.org/g/openembedded-core/message/197471
Mute This Topic: https://lists.openembedded.org/mt/105108998/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Patchtest results for [PATCH] sbc: add PACKAGECONFIG tester to make libsndfile1 optional
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/sbc-add-PACKAGECONFIG-tester-to-make-libsndfile1-optional.patch FAIL: test mbox format: Series has malformed diff lines. Create the series again using git-format-patch and ensure it applies using git am (test_mbox.TestMbox.test_mbox_format) PASS: test Signed-off-by presence (test_mbox.TestMbox.test_signed_off_by_presence) PASS: test author valid (test_mbox.TestMbox.test_author_valid) PASS: test commit message presence (test_mbox.TestMbox.test_commit_message_presence) PASS: test max line length (test_metadata.TestMetadata.test_max_line_length) PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade) PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format) PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length) PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list) SKIP: pretest pylint: Python-unidiff parse error (test_python_pylint.PyLint.pretest_pylint) SKIP: pretest src uri left files: Patch cannot be merged (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: Parse error Hunk diff line expected: file://src/sbcenc.c; beginline=1;endline=24;md5=08e 7a70b127f4100ff2cd7d629147d8d \ SKIP: test Signed-off-by presence: Parse error Hunk diff line expected: file://src/sbcenc.c; beginline=1;endline=24;md5=08e 7a70b127f4100ff2cd7d629147d8d \ SKIP: test Upstream-Status presence: Parse error Hunk diff line expected: file://src/sbcenc.c; beginline=1;endline=24;md5=08e 7a70b127f4100ff2cd7d629147d8d \ 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 pylint: Python-unidiff parse error (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 src uri left files: Patch cannot be merged (test_metadata.TestMetadata.test_src_uri_left_files) SKIP: test summary presence: No added recipes, skipping test (test_metadata.TestMetadata.test_summary_presence) --- 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 (#197469): https://lists.openembedded.org/g/openembedded-core/message/197469 Mute This Topic: https://lists.openembedded.org/mt/105108268/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] Patchtest results for [PATCH RESEND] wpa-supplicant: add support for building without DBus
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/RESEND-wpa-supplicant-add-support-for-building-without-DBus.patch
FAIL: test mbox format: Series has malformed diff lines. Create the series
again using git-format-patch and ensure it applies using git am
(test_mbox.TestMbox.test_mbox_format)
PASS: test Signed-off-by presence
(test_mbox.TestMbox.test_signed_off_by_presence)
PASS: test author valid (test_mbox.TestMbox.test_author_valid)
PASS: test commit message presence
(test_mbox.TestMbox.test_commit_message_presence)
PASS: test max line length (test_metadata.TestMetadata.test_max_line_length)
PASS: test non-AUH upgrade (test_mbox.TestMbox.test_non_auh_upgrade)
PASS: test shortlog format (test_mbox.TestMbox.test_shortlog_format)
PASS: test shortlog length (test_mbox.TestMbox.test_shortlog_length)
PASS: test target mailing list (test_mbox.TestMbox.test_target_mailing_list)
SKIP: pretest pylint: Python-unidiff parse error
(test_python_pylint.PyLint.pretest_pylint)
SKIP: pretest src uri left files: Patch cannot be merged
(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: Parse error Unexpected hunk found: @@ -25,9 +25,10
@@ S = "${WORKDIR}/wpa_supplicant-${P V}"
SKIP: test Signed-off-by presence: Parse error Unexpected hunk found: @@ -25,9
+25,10 @@ S = "${WORKDIR}/wpa_supplicant-${P V}"
SKIP: test Upstream-Status presence: Parse error Unexpected hunk found: @@
-25,9 +25,10 @@ S = "${WORKDIR}/wpa_supplicant-${P V}"
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 pylint: Python-unidiff parse error
(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 src uri left files: Patch cannot be merged
(test_metadata.TestMetadata.test_src_uri_left_files)
SKIP: test summary presence: No added recipes, skipping test
(test_metadata.TestMetadata.test_summary_presence)
---
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 (#197468):
https://lists.openembedded.org/g/openembedded-core/message/197468
Mute This Topic: https://lists.openembedded.org/mt/105108267/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 RESEND] wpa-supplicant: add support for building without DBus
Useful on highly resource constrained embedded systems where DBus is an extra
dependency. Tested to build with and without ` dbus ` in PACKAGECONFIG.
DBus interface is left enabled by default to preserve old behavior.
Signed-off-by: Alibek Omarov < a1ba.oma...@gmail.com >
---
.../wpa-supplicant/ wpa-suppli cant_2.10.bb ( http://wpa-supplicant_2.10.bb ) |
21 +--
1 file changed, 15 insertions(+), 6 deletions(-)
diff --git a/meta/recipes-connectivity/wp
a-supplicant/ wpa-supplicant_2. 10.bb ( http://wpa-supplicant_2.10.bb )
b/meta/recipes-connectivity/wp a-supplicant/ wpa-supplicant_2. 10.bb (
http://wpa-supplicant_2.10.bb )
index 46604045da..dec904b12d 100644
--- a/meta/recipes-connectivity/wp a-supplicant/ wpa-supplicant_2. 10.bb (
http://wpa-supplicant_2.10.bb )
+++ b/meta/recipes-connectivity/wp a-supplicant/ wpa-supplicant_2. 10.bb (
http://wpa-supplicant_2.10.bb )
@@ -8,7 +8,7 @@ LIC_FILES_CHKSUM =
"file://COPYING;md5=5ebcb90236 d1ad640558c3d3cd3035df \
file://README;beginline=1;endl ine=56;md5=e3d2f6c2948991e37c1 ca4960de84747
\
file://wpa_supplicant/wpa_supp licant.c;beginline=1;endline=
12;md5=76306a95306fee9a976b0ac 1be70f705"
-DEPENDS = " dbus libnl"
+DEPENDS = "libnl"
SRC_URI = " http://w1.fi/releases/wpa_sup plicant-${PV}.tar.gz (
http://w1.fi/releases/wpa_supplicant-$%7BPV%7D.tar.gz ) \
file://wpa-supplicant.sh \
@@ -25,9 +25,10 @@ S = "${WORKDIR}/wpa_supplicant-${P V}"
inherit pkgconfig systemd
-PACKAGECONFIG ?= "openssl"
+PACKAGECONFIG ?= "openssl dbus "
PACKAGECONFIG[gnutls] = ",,gnutls libgcrypt"
PACKAGECONFIG[openssl] = ",,openssl"
+PACKAGECONFIG[ dbus ] = ",, dbus "
CVE_PRODUCT = "wpa_supplicant"
@@ -46,6 +47,12 @@ do_configure () {
-e 's/\(^CONFIG_SAE=\)/#\1/' wpa_supplicant/.config
fi
+ if [ "${@bb.utils.contains('PACKAGE CONFIG',' dbus ','true','false',
d)}"
= "false" ]; then
+ sed -i -e 's/\(^CONFIG_CTRL_IFACE_DBUS_N EW=\)/#\1/' \
+ -e 's/\(^CONFIG_CTRL_IFACE_DBUS_I NTRO=\)/#\1/'
wpa_supplicant/.config
+ fi
+
+
# For rebuild
rm -f wpa_supplicant/*.d wpa_supplicant/ dbus /*.d
}
@@ -72,10 +79,12 @@ do_install () {
install -m 755 ${WORKDIR}/wpa-supplicant.sh
${D}${sysconfdir}/network/if-p re-up.d/wpa-supplicant
ln -sf ../if-pre-up.d/wpa-supplicant
${D}${sysconfdir}/network/if-p ost-down.d/wpa-supplicant
- install -d ${D}/${sysconfdir}/ dbus -1/syst em.d
- install -m 644
${S}/wpa_supplicant/ dbus / dbus - wpa_supplicant.conf
${D}/${sysconfdir}/ dbus -1/syst em.d
- install -d ${D}/${datadir}/ dbus -1/system- services
- install -m 644 ${S}/wpa_supplicant/ dbus /*.ser vice
${D}/${datadir}/ dbus -1/system- services
+ if ${@bb.utils.contains('PACKAGEC ONFIG',' dbus ','true','false', d)};
then
+ install -d ${D}/${sysconfdir}/ dbus -1/syst em.d
+ install -m 644
${S}/wpa_supplicant/ dbus / dbus - wpa_supplicant.conf
${D}/${sysconfdir}/ dbus -1/syst em.d
+ install -d ${D}/${datadir}/ dbus -1/system- services
+ install -m 644 ${S}/wpa_supplicant/ dbus /*.ser vice
${D}/${datadir}/ dbus -1/system- services
+ fi
if ${@bb.utils.contains('DISTRO_F EATURES','systemd','true','fal se',d)};
then
install -d ${D}/${systemd_system_unitdir}
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197467):
https://lists.openembedded.org/g/openembedded-core/message/197467
Mute This Topic: https://lists.openembedded.org/mt/105108062/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] sbc: add PACKAGECONFIG tester to make libsndfile1 optional
Noticed that enabling sbc brought libsndfile1->{flac,libogg,vorb
is,etc} chain
dependency. As it wasn't really used by anything critical, made this dependency
optional.
Fixes: fc6375426f94 ("sbc: SBC audio codec")
Signed-off-by: Alibek Omarov < a1ba.oma...@gmail.com >
---
meta/recipes-multimedia/sbc/ s bc_2.0.bb ( http://sbc_2.0.bb ) | 5 +++--
1 file changed, 3 insertions(+), 2 deletions(-)
diff --git a/meta/recipes-multimedia/sbc/ sbc_2.0.bb ( http://sbc_2.0.bb )
b/meta/recipes-multimedia/sbc/ sbc_2.0.bb ( http://sbc_2.0.bb )
index d25be9e80c..2b1e2d0441 100644
--- a/meta/recipes-multimedia/sbc/ sbc_2.0.bb ( http://sbc_2.0.bb )
+++ b/meta/recipes-multimedia/sbc/ sbc_2.0.bb ( http://sbc_2.0.bb )
@@ -10,13 +10,14 @@ LIC_FILES_CHKSUM = "file://COPYING;md5=12f884d2ae
1ff87c09e5b7ccc2c4ca7e \
file://src/sbcenc.c; beginline=1;endline=24;md5=08e
7a70b127f4100ff2cd7d629147d8d \
file://sbc/sbc.h;beginline=1; endline=26;md5=0f57d0df22b0d40 746bdd29805a4361b"
-DEPENDS = "libsndfile1"
-
SRC_URI = "${KERNELORG_MIRROR}/linux/blu etooth/${BP}.tar.xz"
SRC_URI[sha256sum] = "8f12368e1dbbf55e14536520473cf
b338c84b392939cc9b64298360fd4a 07992"
inherit autotools pkgconfig
+PACKAGECONFIG ??= "tester"
+PACKAGECONFIG[tester] = ",--disable-tester,libsndfile1 "
+
PACKAGES =+ "${PN}-examples"
FILES:${PN}-examples += "${bindir}/*"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197466):
https://lists.openembedded.org/g/openembedded-core/message/197466
Mute This Topic: https://lists.openembedded.org/mt/105108044/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] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, Mar 23, 2024 at 10:34 AM Robert P. J. Day wrote: > > On Sat, 23 Mar 2024, Alexander Kanavin wrote: > > > Packaging format of the host distribution and packaging format used > > by yocto have no relation even if there is package management on > > real targets. Why is there an assumption that matching them is going > > to help something? > > > > If anything, making them match might prompt misguided attempts to > > install Ubuntu packages in yocto systems and frustration at not > > being able to make it work. > > all of this being accurate, the one advantage i can see is that, if > developers are familiar with deb package management on their ubuntu > dev systems, then they would be familiar with having package > management on their target systems (provided, as you say, they > understand that they should work only with YP-generated packages). > while ipk/deb/rpm are well supported in OE, rpm is defaults for poky reference distribution and ipk is default for nodistro if you were to use just oe-core, on yocto autobuilders, defaults poky configurations are tested extensively, so you might find a bit of better help if something goes wrong with rpm and its reproducible on AB or indirectly you may build upon the testing that's happening on AB if you used rpm, having said that YP AB is also starting to test ipk backend and we did figure out a nasty lock/race condition in opkg, which has always been there so such issues would be less although not down to zero for you if you used more tested profiles. downside is as Alex mentioned, construing yocto rpms/debs to be valid for other hosts using same packaging backends, that's going to be a constant battle to keep your team to be taught as new folks come on board etc. If your workflows do involve package managers, then opkg is definitely lightweight and easier setup for dev work. > rday > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197465): https://lists.openembedded.org/g/openembedded-core/message/197465 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] glibc: Repace aarch configure patch fix with a backport
despite it being an issue in gcc and still being open
glibc has fixed this problem upstream regardless, therefore
apply the backport instead.
Signed-off-by: Khem Raj
---
...e-Pass-mcpu-along-with-march-to-dete.patch | 67 +++
1 file changed, 38 insertions(+), 29 deletions(-)
diff --git
a/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch
b/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch
index 816471a8287..f6523c54989 100644
---
a/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch
+++
b/meta/recipes-core/glibc/glibc/0023-aarch64-configure-Pass-mcpu-along-with-march-to-dete.patch
@@ -1,53 +1,62 @@
-From f761f5ca2d453e11d34fc7d552dab4a0e189dae9 Mon Sep 17 00:00:00 2001
-From: Khem Raj
-Date: Fri, 4 Aug 2023 09:34:50 -0700
-Subject: [PATCH] aarch64/configure: Pass -mcpu along with -march to detect sve
- support
+From 73c26018ed0ecd9c807bb363cc2c2ab4aca66a82 Mon Sep 17 00:00:00 2001
+From: Szabolcs Nagy
+Date: Wed, 13 Mar 2024 14:34:14 +
+Subject: [PATCH] aarch64: fix check for SVE support in assembler
-SVE support logic in configure is rightly passing -march=+sve to
-compiler to override whatever user might have passed via environment,
-however GCC does not do as intended when -mcpu is part of environment
-compiler flags, then it overrides the -march computed from -mcpu and
-igonores other -march values so this test fails for lot of aarch64
-machines which pass -mcpu that does not support sve. This is seemingly a
-bug in GCC [1], until that is fixed we preempt -mcpu along with -march
-in the configure test itself. It does not change functionality and yet
-lets us through the GCC inconsistency.
+Due to GCC bug 110901 -mcpu can override -march setting when compiling
+asm code and thus a compiler targetting a specific cpu can fail the
+configure check even when binutils gas supports SVE.
-[1] https://gcc.gnu.org/bugzilla/show_bug.cgi?id=110901
-
-Upstream-Status: Inappropriate [Workaround for a GCC issue]
-Signed-off-by: Khem Raj
+The workaround is that explicit .arch directive overrides both -mcpu
+and -march, and since that's what the actual SVE memcpy uses the
+configure check should use that too even if the GCC issue is fixed
+independently.
+Upstream-Status: Backport
[https://sourceware.org/git/?p=glibc.git;a=commit;h=73c26018ed0ecd9c807bb363cc2c2ab4aca66a82]
Signed-off-by: Khem Raj
+Reviewed-by: Florian Weimer
---
- sysdeps/aarch64/configure| 2 +-
- sysdeps/aarch64/configure.ac | 2 +-
- 2 files changed, 2 insertions(+), 2 deletions(-)
+ sysdeps/aarch64/configure| 5 +++--
+ sysdeps/aarch64/configure.ac | 5 +++--
+ 2 files changed, 6 insertions(+), 4 deletions(-)
+ mode change 100644 => 100755 sysdeps/aarch64/configure
diff --git a/sysdeps/aarch64/configure b/sysdeps/aarch64/configure
-index 5e91fab023..39dddc66d4 100644
+old mode 100644
+new mode 100755
+index ca57edce47..9606137e8d
--- a/sysdeps/aarch64/configure
+++ b/sysdeps/aarch64/configure
-@@ -327,7 +327,7 @@ else $as_nop
+@@ -325,9 +325,10 @@ then :
+ printf %s "(cached) " >&6
+ else $as_nop
cat > conftest.s <<\EOF
- ptrue p0.b
+-ptrue p0.b
++ .arch armv8.2-a+sve
++ ptrue p0.b
EOF
-if { ac_try='${CC-cc} -c -march=armv8.2-a+sve conftest.s 1>&5'
-+if { ac_try='${CC-cc} -c -mcpu=generic+sve -march=armv8.2-a+sve conftest.s
1>&5'
++if { ac_try='${CC-cc} -c conftest.s 1>&5'
{ { eval echo "\"\$as_me\":${as_lineno-$LINENO}: \"$ac_try\""; } >&5
(eval $ac_try) 2>&5
ac_status=$?
diff --git a/sysdeps/aarch64/configure.ac b/sysdeps/aarch64/configure.ac
-index 8a708f2ef4..b6a146d2be 100644
+index 27874eceb4..56d12d661d 100644
--- a/sysdeps/aarch64/configure.ac
+++ b/sysdeps/aarch64/configure.ac
-@@ -92,7 +92,7 @@ AC_CACHE_CHECK([for SVE support in assembler],
[libc_cv_aarch64_sve_asm], [dnl
+@@ -90,9 +90,10 @@ LIBC_CONFIG_VAR([aarch64-variant-pcs],
[$libc_cv_aarch64_variant_pcs])
+ # Check if asm support armv8.2-a+sve
+ AC_CACHE_CHECK([for SVE support in assembler], [libc_cv_aarch64_sve_asm], [dnl
cat > conftest.s <<\EOF
- ptrue p0.b
+-ptrue p0.b
++ .arch armv8.2-a+sve
++ ptrue p0.b
EOF
-if AC_TRY_COMMAND(${CC-cc} -c -march=armv8.2-a+sve conftest.s
1>_MESSAGE_LOG_FD); then
-+if AC_TRY_COMMAND(${CC-cc} -c -mcpu=generic+sve -march=armv8.2-a+sve
conftest.s 1>_MESSAGE_LOG_FD); then
++if AC_TRY_COMMAND(${CC-cc} -c conftest.s 1>_MESSAGE_LOG_FD); then
libc_cv_aarch64_sve_asm=yes
else
libc_cv_aarch64_sve_asm=no
+--
+2.44.0
+
--
2.44.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#197464):
https://lists.openembedded.org/g/openembedded-core/message/197464
Mute This Topic: https://lists.openembedded.org/mt/105107290/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe:
Re: [OE-core] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, 23 Mar 2024, Alexander Kanavin wrote: > On Sat, 23 Mar 2024 at 18:34, Robert P. J. Day wrote: > > all of this being accurate, the one advantage i can see is that, if > > developers are familiar with deb package management on their ubuntu > > dev systems, then they would be familiar with having package > > management on their target systems (provided, as you say, they > > understand that they should work only with YP-generated packages). > > Nah, I don't see that familiarity helping anything. Reading output of > opkg and finding out that you need to issue 'opkg install' takes 10 > seconds. That's such a minor hurdle compared to learning yocto in > general (especially when to do when bitbake ends with an error) that > I'd say any time saved there is statistical noise. ok, that's reasonable. thanks. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197463): https://lists.openembedded.org/g/openembedded-core/message/197463 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, 23 Mar 2024 at 18:34, Robert P. J. Day wrote: > all of this being accurate, the one advantage i can see is that, if > developers are familiar with deb package management on their ubuntu > dev systems, then they would be familiar with having package > management on their target systems (provided, as you say, they > understand that they should work only with YP-generated packages). Nah, I don't see that familiarity helping anything. Reading output of opkg and finding out that you need to issue 'opkg install' takes 10 seconds. That's such a minor hurdle compared to learning yocto in general (especially when to do when bitbake ends with an error) that I'd say any time saved there is statistical noise. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197462): https://lists.openembedded.org/g/openembedded-core/message/197462 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] is there any reason to use .ipk packaging if devs are using ubuntu?
On Sat, 23 Mar 2024, Alexander Kanavin wrote: > Packaging format of the host distribution and packaging format used > by yocto have no relation even if there is package management on > real targets. Why is there an assumption that matching them is going > to help something? > > If anything, making them match might prompt misguided attempts to > install Ubuntu packages in yocto systems and frustration at not > being able to make it work. all of this being accurate, the one advantage i can see is that, if developers are familiar with deb package management on their ubuntu dev systems, then they would be familiar with having package management on their target systems (provided, as you say, they understand that they should work only with YP-generated packages). rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197461): https://lists.openembedded.org/g/openembedded-core/message/197461 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] is there any reason to use .ipk packaging if devs are using ubuntu?
Packaging format of the host distribution and packaging format used by yocto have no relation even if there is package management on real targets. Why is there an assumption that matching them is going to help something? If anything, making them match might prompt misguided attempts to install Ubuntu packages in yocto systems and frustration at not being able to make it work. Alex On Sat 23. Mar 2024 at 18.04, Robert P. J. Day wrote: > > yet another sophomoric question but i have inherited (and am > babysitting) a fairly extensive OE/YP build system that, for the most > part, works but i noticed early on that it selects ipk for the package > format. > > now, given that there is no package management installed in the > images, i guess it really makes no difference what the package format > is, but it just seems unnatural to use ipk given that the > corp-approved linux development system is ubuntu. > > is there any compelling argument for this? i suspect i could change > the packaging format and the developers would not even notice. > > rday > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197460): https://lists.openembedded.org/g/openembedded-core/message/197460 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] [master] riscv: libcamera stack smashing detected
Glad it worked! On Sat, Mar 23, 2024 at 8:14 AM Joel Winarske wrote: > > The patch is good! > > visionfive2:~$ cam -l > [0:04:03.111334926] [405] WARN IPAManager ipa_manager.cpp:154 No IPA found > in '/usr/lib/libcamera' > [0:04:03.111423176] [405] INFO Camera camera_manager.cpp:284 libcamera > v0.2.0+dirty (2024-03-23T15:11:32+00:00) > Available cameras: > visionfive2:~$ > > On Fri, Mar 22, 2024 at 11:57 PM Khem Raj wrote: >> >> Joel, please test the patch I posted to oe ml which should hopefully >> fix the problem you are seeing on rv64 Let me know if it is working or >> not working for your use case. >> >> https://lore.kernel.org/openembedded-devel/20240323065503.4149463-1-raj.k...@gmail.com/T/#u >> >> On Thu, Mar 21, 2024 at 3:15 PM Khem Raj wrote: >> > >> > yes I am aware of it. >> > >> > On Thu, Mar 21, 2024 at 3:08 PM Alexandre Belloni >> > wrote: >> > > >> > > Hello, >> > > >> > > This report should have gone to the openembedded-devel mailing list as >> > > libcamera is in meta-oe. But I guess Khem will have a look anyway. >> > > >> > > >> > > On 20/03/2024 09:10:05-0700, Joel Winarske wrote: >> > > > In master there is a problem running the libcamera "cam" app on a >> > > > RISC-V >> > > > device: >> > > > >> > > > *** stack smashing detected ***: terminated >> > > > >> > > > If I remove the patches in the libcamera recipe, it builds and runs on >> > > > target without issue. >> > > > >> > > > libcamera bug has the details: >> > > > https://bugs.libcamera.org/show_bug.cgi?id=214 >> > > > >> > > > Joel >> > > >> > > > >> > > > >> > > > >> > > >> > > >> > > -- >> > > Alexandre Belloni, co-owner and COO, Bootlin >> > > Embedded Linux and Kernel engineering >> > > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197459): https://lists.openembedded.org/g/openembedded-core/message/197459 Mute This Topic: https://lists.openembedded.org/mt/105047726/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] is there any reason to use .ipk packaging if devs are using ubuntu?
yet another sophomoric question but i have inherited (and am babysitting) a fairly extensive OE/YP build system that, for the most part, works but i noticed early on that it selects ipk for the package format. now, given that there is no package management installed in the images, i guess it really makes no difference what the package format is, but it just seems unnatural to use ipk given that the corp-approved linux development system is ubuntu. is there any compelling argument for this? i suspect i could change the packaging format and the developers would not even notice. rday -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197458): https://lists.openembedded.org/g/openembedded-core/message/197458 Mute This Topic: https://lists.openembedded.org/mt/105106419/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] python3-pytest: add CVE_PRODUCT
On Thu, Mar 21, 2024 at 17:10 +, Ross Burton wrote: > I can only find two CVEs with the CPE pytest:py and either of them are > actually related to the pytest package: > > https://nvd.nist.gov/vuln/detail/CVE-2020-29651 > https://nvd.nist.gov/vuln/detail/CVE-2022-42969 > > These issues relate to https://github.com/pytest-dev/py which is not pytest. You are right. This patch should not be pulled. -- Emil Kronborg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197457): https://lists.openembedded.org/g/openembedded-core/message/197457 Mute This Topic: https://lists.openembedded.org/mt/105047705/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] python3-pytest: add CVE_PRODUCT
On Thu, Mar 21, 2024 at 12:13 +, Richard Purdie wrote: > I worry this is a misfiled CPE rather than general statement that > they'd always use this for pytest CVEs. We might want to talk to them > about tweaking it to be consistent? I'm certainly unsure about taking > this patch as it might mask future issues? I made a mistake. This CPE belongs to the py project by pytest [1]. The vendor name being http://pytest.org tricked me. Searching for pytest in the NIST NVD database yields a single CPE: pytest:py, so I think it is fine to keep it as is, even though a CPE might appear as pytest:pytest instead of python:pytest. [1]: https://github.com/pytest-dev/py -- Emil Kronborg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197456): https://lists.openembedded.org/g/openembedded-core/message/197456 Mute This Topic: https://lists.openembedded.org/mt/105047705/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] pypi.bbclass: remove vendor from CVE_PRODUCT
On Thu, Mar 21, 2024 at 17:16 +, Ross Burton wrote: > Have you got comparison reports for a world run before and after this change > so we can see what the difference is? No. After setting CVE_PRODUCT for around 5 python-* recipes, I noticed a pattern, which led me to pypi.bbclass. Here, I saw that the product is hardcoded to 'python', and thought it would be easier (and more correct) to fix it in a single place instead of multiple recipes. -- Emil Kronborg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197455): https://lists.openembedded.org/g/openembedded-core/message/197455 Mute This Topic: https://lists.openembedded.org/mt/105047700/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] file: add CVE_PRODUCT
On Thu, Mar 21, 2024 at 17:15 +, Ross Burton wrote: > There’s also file:file, for example > https://nvd.nist.gov/vuln/detail/CVE-2007-2799. Hm, clicking on "Show Matching CPE(s)" gives no matches, which a search also confirms. Searching for file_project:file yield results with identical versioning to the file project [1], and the vendor website also matches. My guess is that NIST changed the CPE name at some point, but I am unsure if or how I can confirm that. [1]: https://nvd.nist.gov/products/cpe/search/results?namingFormat=2.3=cpe%3A2.3%3Aa%3Afile_project%3Afile -- Emil Kronborg -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197454): https://lists.openembedded.org/g/openembedded-core/message/197454 Mute This Topic: https://lists.openembedded.org/mt/105047692/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] [master] riscv: libcamera stack smashing detected
The patch is good! visionfive2:~$ cam -l [0:04:03.111334926] [405] WARN IPAManager ipa_manager.cpp:154 No IPA found in '/usr/lib/libcamera' [0:04:03.111423176] [405] INFO Camera camera_manager.cpp:284 libcamera v0.2.0+dirty (2024-03-23T15:11:32+00:00) Available cameras: visionfive2:~$ On Fri, Mar 22, 2024 at 11:57 PM Khem Raj wrote: > Joel, please test the patch I posted to oe ml which should hopefully > fix the problem you are seeing on rv64 Let me know if it is working or > not working for your use case. > > > https://lore.kernel.org/openembedded-devel/20240323065503.4149463-1-raj.k...@gmail.com/T/#u > > On Thu, Mar 21, 2024 at 3:15 PM Khem Raj wrote: > > > > yes I am aware of it. > > > > On Thu, Mar 21, 2024 at 3:08 PM Alexandre Belloni > > wrote: > > > > > > Hello, > > > > > > This report should have gone to the openembedded-devel mailing list as > > > libcamera is in meta-oe. But I guess Khem will have a look anyway. > > > > > > > > > On 20/03/2024 09:10:05-0700, Joel Winarske wrote: > > > > In master there is a problem running the libcamera "cam" app on a > RISC-V > > > > device: > > > > > > > > *** stack smashing detected ***: terminated > > > > > > > > If I remove the patches in the libcamera recipe, it builds and runs > on > > > > target without issue. > > > > > > > > libcamera bug has the details: > > > > https://bugs.libcamera.org/show_bug.cgi?id=214 > > > > > > > > Joel > > > > > > > > > > > > > > > > > > > > > > > > -- > > > Alexandre Belloni, co-owner and COO, Bootlin > > > Embedded Linux and Kernel engineering > > > https://bootlin.com > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197453): https://lists.openembedded.org/g/openembedded-core/message/197453 Mute This Topic: https://lists.openembedded.org/mt/105047726/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [PATCH v4 0/3] pkg-database and systemd-sysext image
Hello, The series causes failures on the autobuilders: https://autobuilder.yoctoproject.org/typhoon/#/builders/79/builds/6548/steps/14/logs/stdio 2024-03-21 21:05:49,848 - oe-selftest - INFO - 6: 20/46 500/587 (137.73s) (0 failed) (imagefeatures.ImageFeatures.test_image_gen_pkgdbfs) 2024-03-21 21:05:49,848 - oe-selftest - INFO - testtools.testresult.real._StringException: Traceback (most recent call last): File "/home/pokybuild/yocto-worker/oe-selftest-centos/build/meta/lib/oeqa/selftest/cases/imagefeatures.py", line 327, in test_image_gen_pkgdbfs self.assertTrue(os.path.exists(os.path.join(img_vars['DEPLOY_DIR_IMAGE'], 'var/lib/opkg/status')), 'opkg\'s status file was not present in: %s' % tar_file) File "/usr/lib64/python3.9/unittest/case.py", line 688, in assertTrue raise self.failureException(msg) AssertionError: False is not true : opkg's status file was not present in: /home/pokybuild/yocto-worker/oe-selftest-centos/build/build-st-3332915/tmp/deploy/images/qemux86-64/core-image-minimal-qemux86-64.rootfs-pkgdb.tar.gz On 04/03/2024 07:15:50+0100, Johannes Schneider via lists.openembedded.org wrote: > systemd-sysext allows to overlay another image (or multiple) ontop of > a "base-image" = the current rootfs, via the use of overlayfs; to add > tools and features meant for development purposes. > > To quote the documentation on systemd-sysext: > " ...addition in order to make debugging/development easier). System > extension images should not be misunderstood as a generic software > packaging framework, ..." > > To build a lean image, that only holds packages that are not already > part of the base-image, a snapshot of the package-database is taken > after the installation of the base-rootfs is done, and picked up again > when collecting the rootfs of such a extension image. > > with all this in place an example usage could look like this: > some-core-image.bb > inherit core-image > IMAGE_GEN_PKGDBFS = "1" > > extending-image.bb > inherit image-sysext > IMAGE_FSTYPES = "squashfs" > IMAGE_BASE_PKGDB = "some-core-image" > # the above pointing at a package-db similar to: > # > build/deploy/images/$MACHINE/some-core-image-$MACHINE-20240210172305-pkgdb.rootfs.tar.gz > > then on the device, running some-core-image, with the extension image placed > at FN: > $> ln -s "$FN" /run/extensions/$(basename $FN).raw > $> systemd-sysext list > $> SYSTEMD_LOG_LEVEL=debug systemd-sysext merge > > As long as the VERSION_ID of the extension image matches the os-release > in the base image, the above commands return sucessfully; > for details on the compativility check see the docs for systemd-sysext. > > = > > changes with v2: > rebase from 'kirkstone' onto 'master' > > changes with v3; > incorporate review suggestions for simplification > add task dependency handling > add oe-selftest for the pkgdb handling > add variable documentation and > some more comments, and examples in the commit-msg > > changes with v4; > rebase onto 'master' => no functional changes > fixed patchtest findings > > > -- Alexandre Belloni, co-owner and COO, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197452): https://lists.openembedded.org/g/openembedded-core/message/197452 Mute This Topic: https://lists.openembedded.org/mt/104717642/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] [master] riscv: libcamera stack smashing detected
Joel, please test the patch I posted to oe ml which should hopefully fix the problem you are seeing on rv64 Let me know if it is working or not working for your use case. https://lore.kernel.org/openembedded-devel/20240323065503.4149463-1-raj.k...@gmail.com/T/#u On Thu, Mar 21, 2024 at 3:15 PM Khem Raj wrote: > > yes I am aware of it. > > On Thu, Mar 21, 2024 at 3:08 PM Alexandre Belloni > wrote: > > > > Hello, > > > > This report should have gone to the openembedded-devel mailing list as > > libcamera is in meta-oe. But I guess Khem will have a look anyway. > > > > > > On 20/03/2024 09:10:05-0700, Joel Winarske wrote: > > > In master there is a problem running the libcamera "cam" app on a RISC-V > > > device: > > > > > > *** stack smashing detected ***: terminated > > > > > > If I remove the patches in the libcamera recipe, it builds and runs on > > > target without issue. > > > > > > libcamera bug has the details: > > > https://bugs.libcamera.org/show_bug.cgi?id=214 > > > > > > Joel > > > > > > > > > > > > > > > > > -- > > Alexandre Belloni, co-owner and COO, Bootlin > > Embedded Linux and Kernel engineering > > https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#197451): https://lists.openembedded.org/g/openembedded-core/message/197451 Mute This Topic: https://lists.openembedded.org/mt/105047726/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
