Re: [OE-core] [qa-build-notification] QA notification for completed autobuilder build (yocto-3.1.28.rc2)
Hi all, Intel and WR YP QA is planning for QA execution for YP build yocto-3.1.28.rc2. We are planning to execute following tests for this cycle: OEQA-manual tests for following module: 1. OE-Core 2. BSP-hw Runtime auto test for following platforms: 1. MinnowBoard Turbot - 32bit 2. Kaby Lake (7th Generation Intel(r) Core(tm) Processors) 3. Tiger Lake (11th Generation Intel(r) Core(tm) Processors) 4. Alder Lake-S (12th Generation Intel(r) Core(tm) Processors) 5. Raptor Lake-P (13th Generation Intel(r) Core(tm) Processors) 6. Edgerouter 7. Beaglebone ETA for completion Friday, 22 Sept 2023. Best regards, Jing Hui > -Original Message- > From: qa-build-notificat...@lists.yoctoproject.org notificat...@lists.yoctoproject.org> On Behalf Of Pokybuild User > Sent: Sunday, September 17, 2023 3:03 PM > To: yo...@lists.yoctoproject.org > Cc: qa-build-notificat...@lists.yoctoproject.org > Subject: [qa-build-notification] QA notification for completed autobuilder > build (yocto-3.1.28.rc2) > > > A build flagged for QA (yocto-3.1.28.rc2) was completed on the autobuilder > and is available at: > > > https://autobuilder.yocto.io/pub/releases/yocto-3.1.28.rc2 > > > Build hash information: > > bitbake: b60c7085ec370473bea9b3b4b65826a17638837f > meta-agl: e0f6590189cb0a510bff0d4233667c552d964591 > meta-arm: b1fe8443a7a72c65fa0fc3371f607c6671b3a882 > meta-aws: 77e5438c27292ad5f8c7d3b100cb09b8dbf1c7f4 > meta-gplv2: 60b251c25ba87e946a0ca4cdc8d17b1cb09292ac > meta-intel: e482213f37828216c7a7df68ff353652cc865ec1 > meta-mingw: 524de686205b5d6736661d4532f5f98fee8589b7 > meta-openembedded: e42d1e758f9f08b98c0e8c6f0532316951bb276f > meta-virtualization: 0dbb8593fa38ac2a04fcac04ff3e35611e849824 > oecore: 8b91c463fb3546836789e1890b3c68acf69c162a > poky: 926eb08fe325e2ea13098f99d920840b9354ceb9 > > > > This is an automated message from the Yocto Project Autobuilder > Git: git://git.yoctoproject.org/yocto-autobuilder2 > Email: richard.pur...@linuxfoundation.org > > > > > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187849): https://lists.openembedded.org/g/openembedded-core/message/187849 Mute This Topic: https://lists.openembedded.org/mt/101450664/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore][PATCH 1/2] multilib.conf: explicitly make MULTILIB_VARIANTS vardeps on MULTILIBS
From: Chen Qi
This patch is to ensure recipes get rebuilt correctly and avoid
incorrect sstate cache reuse when toggling multilib.
The following steps show one example of such incorrect sstate cache reuse.
1. enable multilib && bitbake -c populate_sdk
2. disable multilib && bitbake -c populate_sdk
The error message is as below:
Error:
Problem: conflicting requests
- nothing provides binutils-cross-canadian-i686 needed by
packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
- nothing provides gcc-cross-canadian-i686 needed by
packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
- nothing provides gdb-cross-canadian-i686 needed by
packagegroup-cross-canadian-intel-x86-64-1.0-r0.x86_64_nativesdk
(try to add '--skip-broken' to skip uninstallable packages)
We get this error because packagegroup-cross-canadian recipe is
not rebuilt when it should be.
Current codes have tracked the dependency to MULTILIB_VARIANTS, as
shown in the following chain:
RDEPENDS:packagegroup-cross-canadian-intel-x86-64 ->
all_multilib_tune_values -> MULTILIB_VARIANTS.
However, MULTILIB_VARIANTS cannot automatically depend on MULTILIBS.
See some results from 'bitbake-dumpsigs' below:
List of dependencies for variable MULTILIB_VARIANTS is ['extend_variants']
Variable MULTILIB_VARIANTS value is
${@extend_variants(d,'MULTILIBS','multilib')}
It's obvious that the value of MULTILIB_VARIANTS depend on the
value of MULTILIBS, so let's set this dependency manually.
(From OE-Core rev: 9f47d8eb51816d16078a23c0cef4d697555f913f)
Signed-off-by: Chen Qi
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
meta/conf/multilib.conf | 1 +
1 file changed, 1 insertion(+)
diff --git a/meta/conf/multilib.conf b/meta/conf/multilib.conf
index 7f3b9463ef..ef3605a73d 100644
--- a/meta/conf/multilib.conf
+++ b/meta/conf/multilib.conf
@@ -2,6 +2,7 @@
baselib = "${@d.getVar('BASE_LIB:tune-' + (d.getVar('DEFAULTTUNE') or
'INVALID')) or d.getVar('BASELIB')}"
MULTILIB_VARIANTS = "${@extend_variants(d,'MULTILIBS','multilib')}"
+MULTILIB_VARIANTS[vardeps] += "MULTILIBS"
MULTILIB_SAVE_VARNAME = "DEFAULTTUNE TARGET_ARCH TARGET_SYS TARGET_VENDOR"
MULTILIBS ??= "multilib:lib32"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187848):
https://lists.openembedded.org/g/openembedded-core/message/187848
Mute This Topic: https://lists.openembedded.org/mt/101447919/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
[OE-core][mickledore][PATCH 2/2] gcc-crosssdk: ignore MULTILIB_VARIANTS in signature computation
From: Chen Qi
The gcc_multilib_setup function is a function that is run at the
do_configure step, so it's counted into the signature computation.
The MULTILIB_VARIANTS this function uses is also extracted to be
taken into consideration. After the change of setting MULTILIB_VARIANTS
explictly vardeps on MULTILIBS, the change of MULTILIBS changes the
signature, thus causing rebuilding. However, in case of gcc-crosssdk,
the setting of multilib should have no effect on it, as it's used
to build nativesdk packages, not the target packages. So ignore
MULTILIB_VARIANTS in signature computation. This fixes oe-selftest
case sstatetests.SStateHashSameSigs2.test_sstate_nativesdk_samesigs_multilib.
(From OE-Core rev: 537c71162a711dec32a63a657c4b101269a3e267)
Signed-off-by: Chen Qi
Signed-off-by: Alexandre Belloni
Signed-off-by: Richard Purdie
---
meta/recipes-devtools/gcc/gcc-crosssdk.inc | 2 ++
1 file changed, 2 insertions(+)
diff --git a/meta/recipes-devtools/gcc/gcc-crosssdk.inc
b/meta/recipes-devtools/gcc/gcc-crosssdk.inc
index bd2e71d63f..74c4537f4f 100644
--- a/meta/recipes-devtools/gcc/gcc-crosssdk.inc
+++ b/meta/recipes-devtools/gcc/gcc-crosssdk.inc
@@ -10,3 +10,5 @@ GCCMULTILIB = "--disable-multilib"
DEPENDS = "virtual/${TARGET_PREFIX}binutils-crosssdk gettext-native
${NATIVEDEPS}"
PROVIDES = "virtual/${TARGET_PREFIX}gcc-crosssdk
virtual/${TARGET_PREFIX}g++-crosssdk"
+
+gcc_multilib_setup[vardepsexclude] = "MULTILIB_VARIANTS"
--
2.34.1
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187847):
https://lists.openembedded.org/g/openembedded-core/message/187847
Mute This Topic: https://lists.openembedded.org/mt/101447917/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 V3] tar: add ptest support
Hi，Alex Thank you very much! I will try it. Best Regards. Qiu Tingting -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187846): https://lists.openembedded.org/g/openembedded-core/message/187846 Mute This Topic: https://lists.openembedded.org/mt/101372466/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] pulseaudio: dont include consolekit for systemd
Consolekit is not needed for systemd and getting it installed by default
can be disturbing.
Signed-off-by: Markus Volk
---
meta/recipes-multimedia/pulseaudio/pulseaudio.inc | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
index 08a608bab1..2245a73392 100644
--- a/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
+++ b/meta/recipes-multimedia/pulseaudio/pulseaudio.inc
@@ -257,7 +257,7 @@ RDEPENDS:pulseaudio-server +=
"${@bb.utils.contains('DISTRO_FEATURES', 'pulseaud
# pulseaudio-module-console-kit is built whenever dbus is enabled by
PACKAGECONFIG
# but consolekit depends on libx11 and is available only for DISTRO with x11
in DISTRO_FEATURES
-RDEPENDS:pulseaudio-module-console-kit =+
"${@bb.utils.contains('DISTRO_FEATURES', 'x11', 'consolekit', '', d)}"
+RDEPENDS:pulseaudio-module-console-kit =+
"${@bb.utils.contains('DISTRO_FEATURES', 'sysvinit x11', 'consolekit', '', d)}"
RDEPENDS:pulseaudio-misc += "pulseaudio-module-cli-protocol-unix"
FILES:${PN}-module-alsa-card += "${datadir}/pulseaudio/alsa-mixer"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187845):
https://lists.openembedded.org/g/openembedded-core/message/187845
Mute This Topic: https://lists.openembedded.org/mt/101443878/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [AUH] alsa-lib: upgrading to 1.2.10 FAILED
On Mon, 18 Sept 2023 at 20:46, Michael Opdenacker wrote: > Ah, right, I should have paid attention to the file name. > I could reproduce it too. > > Thanks a lot Alex :) > Michael. I think this backport should help: https://github.com/alsa-project/alsa-lib/commit/10bd599970acc71c92f85eb08943eb8d3d702a9c Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187844): https://lists.openembedded.org/g/openembedded-core/message/187844 Mute This Topic: https://lists.openembedded.org/mt/101386188/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [AUH] alsa-lib: upgrading to 1.2.10 FAILED
On 18.09.23 at 19:16, Alexander Kanavin wrote: On Mon, 18 Sept 2023 at 18:28, Michael Opdenacker via lists.openembedded.org wrote: this email is a notification from the Auto Upgrade Helper that the automatic attempt to upgrade the recipe *alsa-lib* to *1.2.10* has Failed(do_compile). Detailed error information: do_compile failed Ouch, as far as I am concerned, the AUH patch didn't cause any failure on Poky "master". After applying a fix to the alsa-utils 2.10 recipe, I could also build this recipe depending on alsa-lib 1.2.10 and check that "speaker-test" starts. Any advice for cases when you can't reproduce the AUH failures? The failure is with musl, and I easily reproduced it there. The main report itself isn't saying it, but attached log file name should indicate the failing configuration. Ah, right, I should have paid attention to the file name. I could reproduce it too. Thanks a lot Alex :) Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187843): https://lists.openembedded.org/g/openembedded-core/message/187843 Mute This Topic: https://lists.openembedded.org/mt/101386188/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
On 18 Sep 2023, at 18:50, Martin Jansa wrote: > > On Mon, Sep 18, 2023 at 7:21 PM Steve Sakoman wrote: > On Mon, Sep 18, 2023 at 7:10 AM Martin Jansa wrote: > > > > I've intentionally sent it only for mickledore as the gcc version in > > kirkstone and dunfell isn't affected by this (at least my reproducer isn't). > > So, just to clarify, is it OK to take the CVE-2023-4039.patch for > kirkstone and dunfell? > > I think so. Agreed. The relevant code changed a fair bit and there’s no evidence right now that it was broken in older releases. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187842): https://lists.openembedded.org/g/openembedded-core/message/187842 Mute This Topic: https://lists.openembedded.org/mt/101387993/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
On Mon, Sep 18, 2023 at 7:21 PM Steve Sakoman wrote: > On Mon, Sep 18, 2023 at 7:10 AM Martin Jansa > wrote: > > > > I've intentionally sent it only for mickledore as the gcc version in > kirkstone and dunfell isn't affected by this (at least my reproducer isn't). > > So, just to clarify, is it OK to take the CVE-2023-4039.patch for > kirkstone and dunfell? > I think so. -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187841): https://lists.openembedded.org/g/openembedded-core/message/187841 Mute This Topic: https://lists.openembedded.org/mt/101387993/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
On Mon, Sep 18, 2023 at 7:10 AM Martin Jansa wrote: > > I've intentionally sent it only for mickledore as the gcc version in > kirkstone and dunfell isn't affected by this (at least my reproducer isn't). So, just to clarify, is it OK to take the CVE-2023-4039.patch for kirkstone and dunfell? Steve > > On Mon, Sep 18, 2023 at 6:42 PM Steve Sakoman wrote: >> >> On Mon, Sep 18, 2023 at 6:08 AM Ross Burton wrote: >> > >> > On 18 Sep 2023, at 16:48, Steve Sakoman wrote: >> > > >> > > The CVE-2023-4039.patch was also submitted for kirkstone and dunfell. >> > > Should I attempt to cherry-pick this fix for those branches too? >> > >> > The bug says that the patch only applies cleaning to GCC 12/13, I’m >> > seeking clarification as to whether that means it’s not relevant for older >> > branches or whether a proper backport will be needed. >> >> I did a quick experiment with kirkstone and there were two issues with >> cherry-picking: >> >> 1. The test suite hunk failed since the test file doesn't exist in gcc 11 >> 2. The first hunk fails to apply since the file name being modified in >> gcc 11 is a .c, apparently it was changed to .cc in later releases. >> You took this into account in the CVE patch file >> >> Removing the testsuite hunk and hacking the filename allowed the first >> hunk to apply (but with fuzz errors). >> >> So I'd say we definitely need a proper backport if the issue is >> relevant for older branches. >> >> I'll pull CVE-2023-4039.patch from kirkstone and dunfell until we have >> clarification. >> >> Thanks! >> >> Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187840): https://lists.openembedded.org/g/openembedded-core/message/187840 Mute This Topic: https://lists.openembedded.org/mt/101387993/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [AUH] alsa-lib: upgrading to 1.2.10 FAILED
On Mon, 18 Sept 2023 at 18:28, Michael Opdenacker via lists.openembedded.org wrote: > > this email is a notification from the Auto Upgrade Helper > > that the automatic attempt to upgrade the recipe *alsa-lib* to *1.2.10* has > > Failed(do_compile). > > > > Detailed error information: > > > > do_compile failed > > > Ouch, as far as I am concerned, the AUH patch didn't cause any failure > on Poky "master". > After applying a fix to the alsa-utils 2.10 recipe, I could also build > this recipe depending on alsa-lib 1.2.10 and check that "speaker-test" > starts. > > Any advice for cases when you can't reproduce the AUH failures? The failure is with musl, and I easily reproduced it there. The main report itself isn't saying it, but attached log file name should indicate the failing configuration. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187839): https://lists.openembedded.org/g/openembedded-core/message/187839 Mute This Topic: https://lists.openembedded.org/mt/101386188/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
I've intentionally sent it only for mickledore as the gcc version in kirkstone and dunfell isn't affected by this (at least my reproducer isn't). On Mon, Sep 18, 2023 at 6:42 PM Steve Sakoman wrote: > On Mon, Sep 18, 2023 at 6:08 AM Ross Burton wrote: > > > > On 18 Sep 2023, at 16:48, Steve Sakoman wrote: > > > > > > The CVE-2023-4039.patch was also submitted for kirkstone and dunfell. > > > Should I attempt to cherry-pick this fix for those branches too? > > > > The bug says that the patch only applies cleaning to GCC 12/13, I’m > seeking clarification as to whether that means it’s not relevant for older > branches or whether a proper backport will be needed. > > I did a quick experiment with kirkstone and there were two issues with > cherry-picking: > > 1. The test suite hunk failed since the test file doesn't exist in gcc 11 > 2. The first hunk fails to apply since the file name being modified in > gcc 11 is a .c, apparently it was changed to .cc in later releases. > You took this into account in the CVE patch file > > Removing the testsuite hunk and hacking the filename allowed the first > hunk to apply (but with fuzz errors). > > So I'd say we definitely need a proper backport if the issue is > relevant for older branches. > > I'll pull CVE-2023-4039.patch from kirkstone and dunfell until we have > clarification. > > Thanks! > > Steve > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187838): https://lists.openembedded.org/g/openembedded-core/message/187838 Mute This Topic: https://lists.openembedded.org/mt/101387993/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
On Mon, Sep 18, 2023 at 6:08 AM Ross Burton wrote: > > On 18 Sep 2023, at 16:48, Steve Sakoman wrote: > > > > The CVE-2023-4039.patch was also submitted for kirkstone and dunfell. > > Should I attempt to cherry-pick this fix for those branches too? > > The bug says that the patch only applies cleaning to GCC 12/13, I’m seeking > clarification as to whether that means it’s not relevant for older branches > or whether a proper backport will be needed. I did a quick experiment with kirkstone and there were two issues with cherry-picking: 1. The test suite hunk failed since the test file doesn't exist in gcc 11 2. The first hunk fails to apply since the file name being modified in gcc 11 is a .c, apparently it was changed to .cc in later releases. You took this into account in the CVE patch file Removing the testsuite hunk and hacking the filename allowed the first hunk to apply (but with fuzz errors). So I'd say we definitely need a proper backport if the issue is relevant for older branches. I'll pull CVE-2023-4039.patch from kirkstone and dunfell until we have clarification. Thanks! Steve -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187837): https://lists.openembedded.org/g/openembedded-core/message/187837 Mute This Topic: https://lists.openembedded.org/mt/101387993/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
Re: [OE-core] [AUH] alsa-lib: upgrading to 1.2.10 FAILED
Greetings, On 15.09.23 at 20:59, Auto Upgrade Helper wrote: Hello, this email is a notification from the Auto Upgrade Helper that the automatic attempt to upgrade the recipe *alsa-lib* to *1.2.10* has Failed(do_compile). Detailed error information: do_compile failed Ouch, as far as I am concerned, the AUH patch didn't cause any failure on Poky "master". After applying a fix to the alsa-utils 2.10 recipe, I could also build this recipe depending on alsa-lib 1.2.10 and check that "speaker-test" starts. Any advice for cases when you can't reproduce the AUH failures? Thanks in advance Michael. -- Michael Opdenacker, Bootlin Embedded Linux and Kernel engineering https://bootlin.com -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187836): https://lists.openembedded.org/g/openembedded-core/message/187836 Mute This Topic: https://lists.openembedded.org/mt/101386188/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
On 18 Sep 2023, at 16:48, Steve Sakoman wrote: > > The CVE-2023-4039.patch was also submitted for kirkstone and dunfell. > Should I attempt to cherry-pick this fix for those branches too? The bug says that the patch only applies cleaning to GCC 12/13, I’m seeking clarification as to whether that means it’s not relevant for older branches or whether a proper backport will be needed. Ross -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187835): https://lists.openembedded.org/g/openembedded-core/message/187835 Mute This Topic: https://lists.openembedded.org/mt/101387993/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] [mickledore][PATCH] gcc: backport a fix for ICE caused by CVE-2023-4039.patch
The CVE-2023-4039.patch was also submitted for kirkstone and dunfell.
Should I attempt to cherry-pick this fix for those branches too?
Steve
On Fri, Sep 15, 2023 at 10:42 AM Martin Jansa wrote:
>
> * see:
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111418
> https://gcc.gnu.org/bugzilla/show_bug.cgi?id=111411
>
> Signed-off-by: Martin Jansa
> ---
> meta/recipes-devtools/gcc/gcc-12.3.inc| 1 +
> ...ch64-Fix-loose-ldpstp-check-PR111411.patch | 117 ++
> 2 files changed, 118 insertions(+)
> create mode 100644
> meta/recipes-devtools/gcc/gcc/0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch
>
> diff --git a/meta/recipes-devtools/gcc/gcc-12.3.inc
> b/meta/recipes-devtools/gcc/gcc-12.3.inc
> index 5896f26e1a..5655b6f46d 100644
> --- a/meta/recipes-devtools/gcc/gcc-12.3.inc
> +++ b/meta/recipes-devtools/gcc/gcc-12.3.inc
> @@ -64,6 +64,7 @@ SRC_URI = "${BASEURI} \
> file://prefix-map-realpath.patch \
> file://hardcoded-paths.patch \
> file://CVE-2023-4039.patch \
> + file://0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch \
> "
> SRC_URI[sha256sum] =
> "949a5d4f99e786421a93b532b22ffab5578de7321369975b91aec97adfda8c3b"
>
> diff --git
> a/meta/recipes-devtools/gcc/gcc/0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch
>
> b/meta/recipes-devtools/gcc/gcc/0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch
> new file mode 100644
> index 00..a408a98698
> --- /dev/null
> +++
> b/meta/recipes-devtools/gcc/gcc/0026-aarch64-Fix-loose-ldpstp-check-PR111411.patch
> @@ -0,0 +1,117 @@
> +From adb60dc78e0da4877747f32347cee339364775be Mon Sep 17 00:00:00 2001
> +From: Richard Sandiford
> +Date: Fri, 15 Sep 2023 09:19:14 +0100
> +Subject: [PATCH] aarch64: Fix loose ldpstp check [PR111411]
> +
> +aarch64_operands_ok_for_ldpstp contained the code:
> +
> + /* One of the memory accesses must be a mempair operand.
> + If it is not the first one, they need to be swapped by the
> + peephole. */
> + if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1))
> + && !aarch64_mem_pair_operand (mem_2, GET_MODE (mem_2)))
> +return false;
> +
> +But the requirement isn't just that one of the accesses must be a
> +valid mempair operand. It's that the lower access must be, since
> +that's the access that will be used for the instruction operand.
> +
> +gcc/
> + PR target/111411
> + * config/aarch64/aarch64.cc (aarch64_operands_ok_for_ldpstp): Require
> + the lower memory access to a mem-pair operand.
> +
> +gcc/testsuite/
> + PR target/111411
> + * gcc.dg/rtl/aarch64/pr111411.c: New test.
> +
> +Upstream-Status: Backport
> [https://gcc.gnu.org/git/gitweb.cgi?p=gcc.git;h=2d38f45bcca62ca0c7afef4b579f82c5c2a01610]
> +Signed-off-by: Martin Jansa
> +---
> + gcc/config/aarch64/aarch64.cc | 8 ++-
> + gcc/testsuite/gcc.dg/rtl/aarch64/pr111411.c | 57 +
> + 2 files changed, 60 insertions(+), 5 deletions(-)
> + create mode 100644 gcc/testsuite/gcc.dg/rtl/aarch64/pr111411.c
> +
> +diff --git a/gcc/config/aarch64/aarch64.cc b/gcc/config/aarch64/aarch64.cc
> +index 6118a3354ac..9b1f791ca8b 100644
> +--- a/gcc/config/aarch64/aarch64.cc
> b/gcc/config/aarch64/aarch64.cc
> +@@ -26154,11 +26154,9 @@ aarch64_operands_ok_for_ldpstp (rtx *operands, bool
> load,
> + gcc_assert (known_eq (GET_MODE_SIZE (GET_MODE (mem_1)),
> + GET_MODE_SIZE (GET_MODE (mem_2;
> +
> +- /* One of the memory accesses must be a mempair operand.
> +- If it is not the first one, they need to be swapped by the
> +- peephole. */
> +- if (!aarch64_mem_pair_operand (mem_1, GET_MODE (mem_1))
> +- && !aarch64_mem_pair_operand (mem_2, GET_MODE (mem_2)))
> ++ /* The lower memory access must be a mem-pair operand. */
> ++ rtx lower_mem = reversed ? mem_2 : mem_1;
> ++ if (!aarch64_mem_pair_operand (lower_mem, GET_MODE (lower_mem)))
> + return false;
> +
> + if (REG_P (reg_1) && FP_REGNUM_P (REGNO (reg_1)))
> +diff --git a/gcc/testsuite/gcc.dg/rtl/aarch64/pr111411.c
> b/gcc/testsuite/gcc.dg/rtl/aarch64/pr111411.c
> +new file mode 100644
> +index 000..ad07e9c6c89
> +--- /dev/null
> b/gcc/testsuite/gcc.dg/rtl/aarch64/pr111411.c
> +@@ -0,0 +1,57 @@
> ++/* { dg-do compile { target aarch64*-*-* } } */
> ++/* { dg-require-effective-target lp64 } */
> ++/* { dg-options "-O -fdisable-rtl-postreload -fpeephole2
> -fno-schedule-fusion" } */
> ++
> ++extern int data[];
> ++
> ++void __RTL (startwith ("ira")) foo (void *ptr)
> ++{
> ++ (function "foo"
> ++(param "ptr"
> ++ (DECL_RTL (reg/v:DI <0> [ ptr ]))
> ++ (DECL_RTL_INCOMING (reg/v:DI x0 [ ptr ]))
> ++) ;; param "ptr"
> ++(insn-chain
> ++ (block 2
> ++ (edge-from entry (flags "FALLTHRU"))
> ++ (cnote 3 [bb 2] NOTE_INSN_BASIC_BLOCK)
> ++ (insn 4 (set (reg:DI <0>) (reg:DI x0)))
> ++ (insn 5 (set (reg:DI <1>)
> ++ (plus:DI (reg:DI <0>)
[oe-core][PATCHv2] libxmlb: import recipe from meta-oe
appstream has a dependency on it
- add a patch to fix a reproducibility and runtime issue with ptest
ptest completes without error
- add the recipe to ptest-packagelists.inc
Signed-off-by: Markus Volk
---
.../distro/include/ptest-packagelists.inc | 1 +
...xb-selftest.c-hardcode-G_TEST_SRCDIR.patch | 35 +++
meta/recipes-gnome/libxmlb/libxmlb/run-ptest | 3 ++
meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb | 25 +
4 files changed, 64 insertions(+)
create mode 100644
meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
create mode 100644 meta/recipes-gnome/libxmlb/libxmlb/run-ptest
create mode 100644 meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
diff --git a/meta/conf/distro/include/ptest-packagelists.inc
b/meta/conf/distro/include/ptest-packagelists.inc
index e023891b7b..d5f41a995e 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -47,6 +47,7 @@ PTESTS_FAST = "\
libxml-sax-base-perl \
libxml-simple-perl \
libxml2 \
+libxmlb \
logrotate \
lua \
lzo \
diff --git
a/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
b/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
new file mode 100644
index 00..da8ce68df9
--- /dev/null
+++
b/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
@@ -0,0 +1,35 @@
+From dc208bafc57c1ccaa0ca260f99c8b4c976271ebc Mon Sep 17 00:00:00 2001
+From: Markus Volk
+Date: Sat, 16 Sep 2023 14:02:57 +0200
+Subject: [PATCH] xb-self-test.c: hardcode G_TEST_SRCDIR
+
+This avoids:
+ libxmlb-0.3.14-r0 do_package_qa: QA Issue: File
+ /usr/libexec/installed-tests/libxmlb/xb-self-test in package libxmlb-ptest
+ contains reference to TMPDIR [buildpaths]
+
+and also fixes the runtime for the ptest.
+
+Upstream-Status: Inappropriate [oe-specific]
+
+Signed-off-by: Markus Volk
+---
+ src/xb-self-test.c | 2 +-
+ 1 file changed, 1 insertion(+), 1 deletion(-)
+
+diff --git a/src/xb-self-test.c b/src/xb-self-test.c
+index 47d9728..8b3dd0e 100644
+--- a/src/xb-self-test.c
b/src/xb-self-test.c
+@@ -2870,7 +2870,7 @@ xb_speed_func(void)
+ int
+ main(int argc, char **argv)
+ {
+- g_setenv("G_TEST_SRCDIR", SRCDIR, FALSE);
++ g_setenv("G_TEST_SRCDIR", "/usr/libexec/installed-tests/libxmlb",
FALSE);
+
+ g_test_init(&argc, &argv, NULL);
+
+--
+2.41.0
+
diff --git a/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
b/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
new file mode 100644
index 00..6d0bb95d3a
--- /dev/null
+++ b/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
@@ -0,0 +1,3 @@
+#! /bin/sh
+
+gnome-desktop-testing-runner libxmlb
diff --git a/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
b/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
new file mode 100644
index 00..1d3b0de29a
--- /dev/null
+++ b/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
@@ -0,0 +1,25 @@
+SUMMARY = "A library to help create and query binary XML blobs"
+HOMEPAGE = "https://github.com/hughsie/libxmlb";
+LICENSE = "LGPL-2.1-only"
+LIC_FILES_CHKSUM = "file://LICENSE;md5=1803fa9c2c3ce8cb06b4861d75310742"
+
+SRC_URI = " \
+ git://github.com/hughsie/libxmlb.git;branch=main;protocol=https \
+ file://0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch \
+ file://run-ptest \
+"
+SRCREV = "aa577b276adc66564f5777f9a522ca3bf0bfa65e"
+S = "${WORKDIR}/git"
+
+DEPENDS = "glib-2.0 xz zstd"
+
+inherit gobject-introspection gtk-doc meson ptest-gnome lib_package pkgconfig
+
+PACKAGECONFIG ??= "${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '', d)}"
+PACKAGECONFIG[tests] = "-Dtests=true,-Dtests=false"
+
+GTKDOC_MESON_OPTION = "gtkdoc"
+
+FILES:${PN} += "${datadir}"
+
+BBCLASSEXTEND = "native"
--
2.41.0
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187833):
https://lists.openembedded.org/g/openembedded-core/message/187833
Mute This Topic: https://lists.openembedded.org/mt/101432374/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/4] libxmlb: import recipe from meta-oe
On Mon, Sep 18 2023 at 02:44:00 PM +02:00:00, Alexander Kanavin wrote: The criteria is written in the file where ptests are separated into fast and slow. Well documented. You just have to open your eyes ;) Thanks. I'll send an update -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187832): https://lists.openembedded.org/g/openembedded-core/message/187832 Mute This Topic: https://lists.openembedded.org/mt/101419208/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/4] libxmlb: import recipe from meta-oe
The criteria is written in the file where ptests are separated into fast and slow. Alex On Mon, 18 Sept 2023 at 14:39, Markus Volk wrote: > > On Mon, Sep 18 2023 at 01:40:25 PM +02:00:00, Markus Volk > wrote: > > I did that already to check if the test is working at all. It took a few > minutes. Didn't focus on that but I guess its been about 1-2 Minutes. > That is a fast one, I guess? > > > Tested this again with core-image-sato and runqemu script > Without compiling at the same time, it's also much quicker. > total=1; passed=1; skipped=0; failed=0 > DURATION: 14 > > But I don't have a clue as to when a ptest is considered slow -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187831): https://lists.openembedded.org/g/openembedded-core/message/187831 Mute This Topic: https://lists.openembedded.org/mt/101419208/21656 Group Owner: openembedded-core+ow...@lists.openembedded.org Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub [arch...@mail-archive.com] -=-=-=-=-=-=-=-=-=-=-=-
[OE-core] [PATCH] oeqa/selftest/wic: Improve assertTrue calls
assertTrue is a problematic call use in test cases since when it fails,
you just get an unhelpful "False is not True" message.
Replace some uses with assertIn/assertNotIn which will give more helpful results
and for the rest, add msg entries which given more helpful debugging.
For example, this patch would help debugging of #15176.
Signed-off-by: Richard Purdie
---
meta/lib/oeqa/selftest/cases/wic.py | 36 ++---
1 file changed, 18 insertions(+), 18 deletions(-)
diff --git a/meta/lib/oeqa/selftest/cases/wic.py
b/meta/lib/oeqa/selftest/cases/wic.py
index aa61349ed12..b4866bcb323 100644
--- a/meta/lib/oeqa/selftest/cases/wic.py
+++ b/meta/lib/oeqa/selftest/cases/wic.py
@@ -729,7 +729,7 @@ part /etc --source rootfs --fstype=ext4
--change-directory=etc
wicout = glob(os.path.join(self.resultdir, "wictestdisk-*.direct"))
self.assertEqual(1, len(wicout))
size = os.path.getsize(wicout[0])
-self.assertTrue(size > extraspace)
+self.assertTrue(size > extraspace, msg="Extra space not present (%s vs
%s)" % (size, extraspace))
def test_no_table(self):
"""Test --no-table wks option."""
@@ -773,7 +773,7 @@ class Wic2(WicTestCase):
basename = bb_vars['IMAGE_BASENAME']
self.assertEqual(basename, image)
path = os.path.join(imgdatadir, basename) + '.env'
-self.assertTrue(os.path.isfile(path))
+self.assertTrue(os.path.isfile(path), msg="File %s wasn't generated as
expected" % path)
wicvars = set(bb_vars['WICVARS'].split())
# filter out optional variables
@@ -786,7 +786,7 @@ class Wic2(WicTestCase):
# test if variables used by wic present in the .env file
for var in wicvars:
self.assertTrue(var in content, "%s is not in .env file" % var)
-self.assertTrue(content[var])
+self.assertTrue(content[var], "%s doesn't have a value (%s)" %
(var, content[var]))
def test_image_vars_dir_short(self):
"""Test image vars directory selection -v option"""
@@ -833,8 +833,8 @@ class Wic2(WicTestCase):
# pointing to existing files
for suffix in ('wic', 'manifest'):
path = prefix + suffix
-self.assertTrue(os.path.islink(path))
-self.assertTrue(os.path.isfile(os.path.realpath(path)))
+self.assertTrue(os.path.islink(path), msg="Link %s wasn't
generated as expected" % path)
+self.assertTrue(os.path.isfile(os.path.realpath(path)), msg="File
linked to by %s wasn't generated as expected" % path)
# TODO this should work on aarch64
@skipIfNotArch(['i586', 'i686', 'x86_64'])
@@ -1104,7 +1104,7 @@ class Wic2(WicTestCase):
self.remove_config(config)
bb_vars = get_bb_vars(['DEPLOY_DIR_IMAGE', 'IMAGE_LINK_NAME'], image)
image_path = os.path.join(bb_vars['DEPLOY_DIR_IMAGE'], '%s.wic' %
bb_vars['IMAGE_LINK_NAME'])
-self.assertTrue(os.path.exists(image_path))
+self.assertTrue(os.path.exists(image_path), msg="Image file %s wasn't
generated as expected" % image_path)
sysroot = get_bb_var('RECIPE_SYSROOT_NATIVE', 'wic-tools')
@@ -1345,11 +1345,11 @@ class Wic2(WicTestCase):
orig_sizes = [int(line.split()[3]) for line in
orig.output.split('\n')[1:]]
exp_sizes = [int(line.split()[3]) for line in
exp.output.split('\n')[1:]]
self.assertEqual(orig_sizes[0], exp_sizes[0]) # first partition is
not resized
-self.assertTrue(orig_sizes[1] < exp_sizes[1])
+self.assertTrue(orig_sizes[1] < exp_sizes[1], msg="Parition size
wasn't enlarged (%s vs %s)" % (orig_sizes[1], exp_sizes[1]))
# Check if all free space is partitioned
result = runCmd("%s/usr/sbin/sfdisk -F %s" % (sysroot,
new_image_path))
-self.assertTrue("0 B, 0 bytes, 0 sectors" in result.output)
+self.assertIn("0 B, 0 bytes, 0 sectors", result.output)
os.rename(image_path, image_path + '.bak')
os.rename(new_image_path, image_path)
@@ -1433,7 +1433,7 @@ class ModifyTests(WicTestCase):
# check if file is there
result = runCmd("wic ls %s:1/ -n %s" % (images[0], sysroot))
self.assertEqual(7, len(result.output.split('\n')))
-self.assertTrue(os.path.basename(testfile.name) in result.output)
+self.assertIn(os.path.basename(testfile.name), result.output)
# prepare directory
testdir = os.path.join(self.resultdir, 'wic-test-cp-dir')
@@ -1447,13 +1447,13 @@ class ModifyTests(WicTestCase):
# check if directory is there
result = runCmd("wic ls %s:1/ -n %s" % (images[0], sysroot))
self.assertEqual(8, len(result.output.split('\n')))
-self.assertTrue(os.path.basename(testdir) in result.output)
+self.assertIn(os.path.basename(testdir), result.output)
Re: [oe-core][PATCH 1/4] libxmlb: import recipe from meta-oe
On Mon, Sep 18 2023 at 01:40:25 PM +02:00:00, Markus Volk wrote: I did that already to check if the test is working at all. It took a few minutes. Didn't focus on that but I guess its been about 1-2 Minutes. That is a fast one, I guess? Tested this again with core-image-sato and runqemu script Without compiling at the same time, it's also much quicker. total=1; passed=1; skipped=0; failed=0 DURATION: 14 But I don't have a clue as to when a ptest is considered slow -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187829): https://lists.openembedded.org/g/openembedded-core/message/187829 Mute This Topic: https://lists.openembedded.org/mt/101419208/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] gdb: fix RDEPENDS for PACKAGECONFIG[tui]
TUI mode needs terminfo at runtime, which is required to be
explicitly stated in the respective PACKAGECONFIG variable.
Without this change /etc/terminfo/ might be missing, which
leads to a runtime error when trying to use tui, e.g.:
(gdb) tui enable
Cannot enable the TUI: error opening terminal [TERM=xterm-256color]
Signed-off-by: Stefan Tauner
---
meta/recipes-devtools/gdb/gdb-common.inc | 3 +--
1 file changed, 1 insertion(+), 2 deletions(-)
I ran into this when running a very minimal Kirkstone image. I presume
this is still an issue but someone should definitely look into it since
I am quite new to bitbake/Yocto and have no means to test it with a
current version.
diff --git a/meta/recipes-devtools/gdb/gdb-common.inc
b/meta/recipes-devtools/gdb/gdb-common.inc
index 925b0c2f80..0f392357fe 100644
--- a/meta/recipes-devtools/gdb/gdb-common.inc
+++ b/meta/recipes-devtools/gdb/gdb-common.inc
@@ -35,8 +35,7 @@ PACKAGECONFIG ??= "readline
${@bb.utils.filter('DISTRO_FEATURES', 'debuginfod',
PACKAGECONFIG[readline] =
"--with-system-readline,--without-system-readline,readline"
PACKAGECONFIG[python] =
"--with-python=${WORKDIR}/python,--without-python,python3,python3
python3-codecs"
PACKAGECONFIG[babeltrace] = "--with-babeltrace,--without-babeltrace,babeltrace"
-# ncurses is already a hard DEPENDS, but would be added here if it weren't
-PACKAGECONFIG[tui] = "--enable-tui,--disable-tui"
+PACKAGECONFIG[tui] = "--enable-tui,--disable-tui,,ncurses-terminfo-base"
PACKAGECONFIG[xz] = "--with-lzma
--with-liblzma-prefix=${STAGING_DIR_HOST},--without-lzma,xz"
PACKAGECONFIG[debuginfod] = "--with-debuginfod, --without-debuginfod, elfutils"
--
Kind regards, Stefan Tauner
FN 181686 k. HG Wien, UID-Nr. ATU 47056901, zertifiziert nach ISO 9001:2015
(Nr. AT-04036/0), ISO/TS 22163:2017 (IR-9/0) und ISO 27001:2013 (Nr.
I-00619/0)
Der Inhalt dieser E-Mail ist vertraulich und ausschließlich für den
bezeichneten Adressaten bestimmt. Wenn Sie nicht der vorgesehene Adressat
dieser E-Mail oder dessen Vertreter sein sollten, so beachten Sie bitte, dass
jede Form der Kenntnisnahme, Veröffentlichung, Vervielfältigung oder Weitergabe
des Inhaltes dieser E-Mail unzulässig ist. Wir bitten Sie, sich in diesem Fall
mit dem Absender der E-Mail in Verbindung zu setzen und die E-Mail zu
vernichten. Für Übermittlungsfehler oder sonstige Irrtümer bei der Übermittlung
besteht keine Haftung.
This e-mail is intended solely for the person to whom it is addressed and may
contain confidential or legally privileged information. Access to this e-mail
by anyone else is unauthorized. If an addressing or transmission error has
misdirected this e-mail, please notify the author by replying to this e-mail
and destroy this e-mail and any attachments. E-mail may be susceptible to data
corruption, interception, unauthorized amendment, viruses and delays or the
consequences thereof. If you are not the intended recipient, be advised that
you have received this e-mail in error and that any use, dissemination,
forwarding, printing or copying of this e-mail is strictly prohibited.
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187828):
https://lists.openembedded.org/g/openembedded-core/message/187828
Mute This Topic: https://lists.openembedded.org/mt/101431727/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] curl: Update from 8.2.1 to 8.3.0
On Sun, 2023-09-17 at 18:57 -0700, Robert Joslyn via
lists.openembedded.org wrote:
> NSS support was removed, so adjust PACKAGECONFIG options.
>
> The --enable-crypto-auth option was removed and split into separate
> options for basic-auth, bearer-auth, digest-auth, kerberos-auth,
> negotiate-auth, and aws. Enable basic, bearer, digest, and negotiate by
> default as these are probably the most common.
>
> Disable test 1279 since this requires libcurl and hangs the tests.
>
> Signed-off-by: Robert Joslyn
> ---
> meta/recipes-support/curl/curl/disable-tests | 1 +
> .../curl/{curl_8.2.1.bb => curl_8.3.0.bb} | 14 +-
> 2 files changed, 10 insertions(+), 5 deletions(-)
> rename meta/recipes-support/curl/{curl_8.2.1.bb => curl_8.3.0.bb} (88%)
>
> diff --git a/meta/recipes-support/curl/curl/disable-tests
> b/meta/recipes-support/curl/curl/disable-tests
> index b687b2bb76..fdac795662 100644
> --- a/meta/recipes-support/curl/curl/disable-tests
> +++ b/meta/recipes-support/curl/curl/disable-tests
> @@ -21,6 +21,7 @@
> # This test is scanning the source tree
> 1222
> # These CRL tests need --libcurl option to be enabled
> +1279
> 1400
> 1401
> 1402
Thanks for the patch. Unfortunately there were warnings generated on
the autobuilder test run for this:
https://autobuilder.yoctoproject.org/typhoon/#/builders/82/builds/5452
https://autobuilder.yoctoproject.org/typhoon/#/builders/81/builds/5631
I'd also wondered if you'd mind setting your from address correctly for
patches please? For more info see:
https://docs.yoctoproject.org/contributor-guide/submit-changes.html#fixing-your-from-identity
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187827):
https://lists.openembedded.org/g/openembedded-core/message/187827
Mute This Topic: https://lists.openembedded.org/mt/101426058/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/4] libxmlb: import recipe from meta-oe
On Mon, Sep 18 2023 at 01:33:56 PM +02:00:00, Alexander Kanavin wrote: You need to first check (with kvm) how long the tests are taking (and that they pass, obviously), then add to one of the lists in ptest-packagelists.inc. I did that already to check if the test is working at all. It took a few minutes. Didn't focus on that but I guess its been about 1-2 Minutes. That is a fast one, I guess? -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187826): https://lists.openembedded.org/g/openembedded-core/message/187826 Mute This Topic: https://lists.openembedded.org/mt/101419208/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/4] libxmlb: import recipe from meta-oe
You need to first check (with kvm) how long the tests are taking (and that they pass, obviously), then add to one of the lists in ptest-packagelists.inc. Alex On Mon, 18 Sept 2023 at 13:29, Markus Volk wrote: > > On Mon, Sep 18 2023 at 12:24:40 PM +01:00:00, Richard Purdie > wrote: > > (and I suspect warnings from other targets will follow) > > > yes, I noticed that too. However, I couldn't decide where it had to be > entered and whether at all. That's why I left this question open > > > -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187825): https://lists.openembedded.org/g/openembedded-core/message/187825 Mute This Topic: https://lists.openembedded.org/mt/101419208/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/4] libxmlb: import recipe from meta-oe
On Mon, Sep 18 2023 at 12:24:40 PM +01:00:00, Richard Purdie wrote: (and I suspect warnings from other targets will follow) yes, I noticed that too. However, I couldn't decide where it had to be entered and whether at all. That's why I left this question open -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187824): https://lists.openembedded.org/g/openembedded-core/message/187824 Mute This Topic: https://lists.openembedded.org/mt/101419208/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/4] libxmlb: import recipe from meta-oe
On Sun, 2023-09-17 at 20:28 +0200, Markus Volk wrote:
> appstream has a dependency on it
>
> - add a patch to fix a reproducibility and runtime issue with ptest
> ptest completes without error
>
> Signed-off-by: Markus Volk
> ---
> ...xb-selftest.c-hardcode-G_TEST_SRCDIR.patch | 35 +++
> meta/recipes-gnome/libxmlb/libxmlb/run-ptest | 3 ++
> meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb | 25 +
> 3 files changed, 63 insertions(+)
> create mode 100644
> meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
> create mode 100644 meta/recipes-gnome/libxmlb/libxmlb/run-ptest
> create mode 100644 meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
>
> diff --git
> a/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
>
> b/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
> new file mode 100644
> index 00..da8ce68df9
> --- /dev/null
> +++
> b/meta/recipes-gnome/libxmlb/libxmlb/0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch
> @@ -0,0 +1,35 @@
> +From dc208bafc57c1ccaa0ca260f99c8b4c976271ebc Mon Sep 17 00:00:00 2001
> +From: Markus Volk
> +Date: Sat, 16 Sep 2023 14:02:57 +0200
> +Subject: [PATCH] xb-self-test.c: hardcode G_TEST_SRCDIR
> +
> +This avoids:
> + libxmlb-0.3.14-r0 do_package_qa: QA Issue: File
> + /usr/libexec/installed-tests/libxmlb/xb-self-test in package libxmlb-ptest
> + contains reference to TMPDIR [buildpaths]
> +
> +and also fixes the runtime for the ptest.
> +
> +Upstream-Status: Inappropriate [oe-specific]
> +
> +Signed-off-by: Markus Volk
> +---
> + src/xb-self-test.c | 2 +-
> + 1 file changed, 1 insertion(+), 1 deletion(-)
> +
> +diff --git a/src/xb-self-test.c b/src/xb-self-test.c
> +index 47d9728..8b3dd0e 100644
> +--- a/src/xb-self-test.c
> b/src/xb-self-test.c
> +@@ -2870,7 +2870,7 @@ xb_speed_func(void)
> + int
> + main(int argc, char **argv)
> + {
> +-g_setenv("G_TEST_SRCDIR", SRCDIR, FALSE);
> ++g_setenv("G_TEST_SRCDIR", "/usr/libexec/installed-tests/libxmlb",
> FALSE);
> +
> + g_test_init(&argc, &argv, NULL);
> +
> +--
> +2.41.0
> +
> diff --git a/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
> b/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
> new file mode 100644
> index 00..6d0bb95d3a
> --- /dev/null
> +++ b/meta/recipes-gnome/libxmlb/libxmlb/run-ptest
> @@ -0,0 +1,3 @@
> +#! /bin/sh
> +
> +gnome-desktop-testing-runner libxmlb
> diff --git a/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
> b/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
> new file mode 100644
> index 00..1d3b0de29a
> --- /dev/null
> +++ b/meta/recipes-gnome/libxmlb/libxmlb_0.3.14.bb
> @@ -0,0 +1,25 @@
> +SUMMARY = "A library to help create and query binary XML blobs"
> +HOMEPAGE = "https://github.com/hughsie/libxmlb";
> +LICENSE = "LGPL-2.1-only"
> +LIC_FILES_CHKSUM = "file://LICENSE;md5=1803fa9c2c3ce8cb06b4861d75310742"
> +
> +SRC_URI = " \
> + git://github.com/hughsie/libxmlb.git;branch=main;protocol=https \
> + file://0001-xb-selftest.c-hardcode-G_TEST_SRCDIR.patch \
> + file://run-ptest \
> +"
> +SRCREV = "aa577b276adc66564f5777f9a522ca3bf0bfa65e"
> +S = "${WORKDIR}/git"
> +
> +DEPENDS = "glib-2.0 xz zstd"
> +
> +inherit gobject-introspection gtk-doc meson ptest-gnome lib_package pkgconfig
> +
> +PACKAGECONFIG ??= "${@bb.utils.contains('PTEST_ENABLED', '1', 'tests', '',
> d)}"
> +PACKAGECONFIG[tests] = "-Dtests=true,-Dtests=false"
> +
> +GTKDOC_MESON_OPTION = "gtkdoc"
> +
> +FILES:${PN} += "${datadir}"
> +
> +BBCLASSEXTEND = "native"
https://autobuilder.yoctoproject.org/typhoon/#/builders/45/builds/7823/steps/11/logs/warnings
(and I suspect warnings from other targets will follow)
Cheers,
Richard
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187823):
https://lists.openembedded.org/g/openembedded-core/message/187823
Mute This Topic: https://lists.openembedded.org/mt/101419208/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 V3] tar: add ptest support
On Mon, 18 Sept 2023 at 10:28, qi...@fujitsu.com wrote: > Thanks for your reply. > There are two ways to add markers. Which one is better? > 1. add one marker for the hole test of tar (as your suggestion) > 2. add markers(PASS, FAIL, SKIP) for every case > sample: > PASS: 1: tar version > FAIL: 5: TAR_OPTIONS with string arguments > SKIP: 11: --pax-option compatibility I looked into why the test suite doesn't print those markers to begin with (GNU items usually do when they use libcheck). It seems that tests/testsuite is pre-generated with a different thing called 'autotest' that doesn't print them. You need to regenerate the file with autotest from from the native sysroot (provided by yocto), which is patched to print the markers: https://git.yoctoproject.org/poky/tree/meta/recipes-devtools/autoconf/autoconf/autotest-automake-result-format.patch and then use --am-fmt option with testsuite so they get printed. > When try to run 'bitbake -c testimage core-image-ptest-tar' command , my > compiling env can not find the testimage task. (ERROR: Task do_testimage does > not exist for target core-image-ptest-tar) > Maybe my compiling env has problems, so could you show me the correct steps > for running the command? local.conf should contain IMAGE_CLASSES += "testimage" You might already have it there, just commented out. Alex -=-=-=-=-=-=-=-=-=-=-=- Links: You receive all messages sent to this group. View/Reply Online (#187822): https://lists.openembedded.org/g/openembedded-core/message/187822 Mute This Topic: https://lists.openembedded.org/mt/101372466/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 V3] tar: add ptest support
Hi， Alex
Thanks for your reply.
There are two ways to add markers. Which one is better?
1. add one marker for the hole test of tar (as your suggestion)
2. add markers(PASS, FAIL, SKIP) for every case
sample:
PASS: 1: tar version
FAIL: 5: TAR_OPTIONS with string arguments
SKIP: 11: --pax-option compatibility
When try to run 'bitbake -c testimage core-image-ptest-tar' command , my
compiling env can not find the testimage task. ( ERROR: Task do_testimage does
not exist for target core-image-ptest-tar)
Maybe my compiling env has problems, so c ould you show me the correct steps
for running the command ?
my steps :
1. download bitbake and install
cd ${WORK_DIR}
git clone https://git.openembedded.org/bitbake bitbake export
BITBAKEDIR=${WORK_DIR}/bitbake/
2. download openembedded-core and apply this patch
git clone https://git.openembedded.org/openembedded-core oe-core
cd oe-core
patch -p1 < ${THIS_PATCH}
3. compile image
source ./oe-init-build-env
echo 'DISTRO_FEATURES:append = " ptest"' >> conf/local.conf
bitbake core-image-ptest-tar
4. run command
bitbake -c testimage core-image-ptest-tar
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187821):
https://lists.openembedded.org/g/openembedded-core/message/187821
Mute This Topic: https://lists.openembedded.org/mt/101372466/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] lttng-tools: Upgrade 2.13.10 -> 2.13.11
Signed-off-by: Richard Purdie
---
.../lttng/{lttng-tools_2.13.10.bb => lttng-tools_2.13.11.bb}| 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
rename meta/recipes-kernel/lttng/{lttng-tools_2.13.10.bb =>
lttng-tools_2.13.11.bb} (99%)
diff --git a/meta/recipes-kernel/lttng/lttng-tools_2.13.10.bb
b/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
similarity index 99%
rename from meta/recipes-kernel/lttng/lttng-tools_2.13.10.bb
rename to meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
index 20e6375a9bb..44415fbf2df 100644
--- a/meta/recipes-kernel/lttng/lttng-tools_2.13.10.bb
+++ b/meta/recipes-kernel/lttng/lttng-tools_2.13.11.bb
@@ -39,7 +39,7 @@ SRC_URI =
"https://lttng.org/files/lttng-tools/lttng-tools-${PV}.tar.bz2 \
file://0001-compat-Define-off64_t-as-off_t-on-linux.patch \
"
-SRC_URI[sha256sum] =
"e5d1095ec1322565f38f149346f71967496c281eacc51ec5c77994b850e7d335"
+SRC_URI[sha256sum] =
"ac5baeef9fa690936b1ca01ecd1742da762c2c08511ff1b4e923938d94d0f979"
inherit autotools ptest pkgconfig useradd python3-dir manpages systemd
--
2.39.2
-=-=-=-=-=-=-=-=-=-=-=-
Links: You receive all messages sent to this group.
View/Reply Online (#187820):
https://lists.openembedded.org/g/openembedded-core/message/187820
Mute This Topic: https://lists.openembedded.org/mt/101429354/21656
Group Owner: openembedded-core+ow...@lists.openembedded.org
Unsubscribe: https://lists.openembedded.org/g/openembedded-core/unsub
[arch...@mail-archive.com]
-=-=-=-=-=-=-=-=-=-=-=-
