[OE-core][PATCH v1] libpng: ptest: disable for riscv64 due to timeout

[OE-core][PATCH v1] libpng: ptest: disable for riscv64 due to timeout

[Pratik Farkase]

The libpng ptest suite consistently times out on qemuriscv64 due to
the emulated target being too slow to complete all tests within the
ptest-runner timeout. All individual tests pass but the full suite
does not finish in time.

[YOCTO #16215] : https://bugzilla.yoctoproject.org/show_bug.cgi?id=16215

Signed-off-by: Pratik Farkase <pratik.farkase@est.tech>
---
 meta/conf/distro/include/ptest-packagelists.inc | 4 ++--
 1 file changed, 2 insertions(+), 2 deletions(-)

diff --git a/meta/conf/distro/include/ptest-packagelists.inc b/meta/conf/distro/include/ptest-packagelists.inc
index 453fb87c17..ffeb322bf2 100644
--- a/meta/conf/distro/include/ptest-packagelists.inc
+++ b/meta/conf/distro/include/ptest-packagelists.inc
@@ -160,8 +160,8 @@ PTESTS_PROBLEMS:append:riscv32 = " lttng-tools strace"
 PTESTS_SLOW:append:libc-musl = " libc-test"
 
 # These tests don't yet pass for riscv64
-PTESTS_SLOW:remove:riscv64 = "tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0"
-PTESTS_PROBLEMS:append:riscv64 = " tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0"
+PTESTS_SLOW:remove:riscv64 = "tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0 libpng"
+PTESTS_PROBLEMS:append:riscv64 = " tcl tcl8 python3-cffi strace lttng-tools python3-numpy perl glib-2.0 libpng"
 
 # These tests don't yet pass for musl qemuarm64
 PTESTS_SLOW:remove:libc-musl:qemuarm64 = "strace perl gnutls glib-2.0"
-- 
2.34.1

Re: [OE-core][PATCH v1] libpng: ptest: disable for riscv64 due to timeout

[Richard Purdie]

On Mon, 2026-08-03 at 11:33 +0200, Pratik Farkase via lists.openembedded.org wrote:
> The libpng ptest suite consistently times out on qemuriscv64 due to
> the emulated target being too slow to complete all tests within the
> ptest-runner timeout. All individual tests pass but the full suite
> does not finish in time.
> 
> [YOCTO #16215] : https://bugzilla.yoctoproject.org/show_bug.cgi?id=16215
> 
> Signed-off-by: Pratik Farkase <pratik.farkase@est.tech>
> ---
>  meta/conf/distro/include/ptest-packagelists.inc | 4 ++--
>  1 file changed, 2 insertions(+), 2 deletions(-)

When you say "does not finish in time", where is the timeout occurring
exactly?

Do the libpng tests emit output as they go, so each test should reset
the timeout in ptest?

Or are the individual tests really so slow that they don't emit any
output within ptest's timeout?

We did have an issue a while back there the output wasn't being flushed
periodically and once we did that, we stopped hitting the timeouts,
hence the questions.

I'd just like to understand where the issue is before we disable it
entirely. A comment about why it was disabled might also be helpful if
we do ever come to revisit this.

Cheers,

Richard

Re: [OE-core][PATCH v1] libpng: ptest: disable for riscv64 due to timeout

[Ross Burton]

On 3 Aug 2026, at 11:18, Richard Purdie via lists.openembedded.org <richard.purdie=linuxfoundation.org@lists.openembedded.org> wrote:
> 
> On Mon, 2026-08-03 at 11:33 +0200, Pratik Farkase via lists.openembedded.org wrote:
>> The libpng ptest suite consistently times out on qemuriscv64 due to
>> the emulated target being too slow to complete all tests within the
>> ptest-runner timeout. All individual tests pass but the full suite
>> does not finish in time.
>> 
>> [YOCTO #16215] : https://bugzilla.yoctoproject.org/show_bug.cgi?id=16215
>> 
>> Signed-off-by: Pratik Farkase <pratik.farkase@est.tech>
>> ---
>>  meta/conf/distro/include/ptest-packagelists.inc | 4 ++--
>>  1 file changed, 2 insertions(+), 2 deletions(-)
> 
> When you say "does not finish in time", where is the timeout occurring
> exactly?
> 
> Do the libpng tests emit output as they go, so each test should reset
> the timeout in ptest?

[ ccing Trevor as we’re talking about this on the bug triage call ]

I just ran the tests locally on my arm machine.  The ptest ran in just over a minute, so a test timeout on a riscv machine would be unexpected.

I suggest seeing if you can replicate this interactively, and where the delay is.  Is a test hanging, or is a specific test taking forever due to riscv/qemu behaviour, or something else?

What might be useful are the .log files in /usr/lib/libpng/ptest/src/tests which will contain the full output of the tests.

Ross