public inbox for openembedded-core@lists.openembedded.org
 help / color / mirror / Atom feed
From: Richard Purdie <richard.purdie@linuxfoundation.org>
To: peter.marko@siemens.com,
	"yoann.congal@smile.fr" <yoann.congal@smile.fr>,
	 "Hemanth.KumarMD@windriver.com"	 <Hemanth.KumarMD@windriver.com>,
	"openembedded-core@lists.openembedded.org"
	<openembedded-core@lists.openembedded.org>
Subject: Re: [OE-core] [scarthgap][PATCH] glibc: stable 2.39 branch updates
Date: Fri, 06 Feb 2026 10:19:41 +0000	[thread overview]
Message-ID: <b885c311ab2d6e31289f5bc857340e96ffc530bc.camel@linuxfoundation.org> (raw)
In-Reply-To: <AS1PR10MB5697B71BC0C1DDAF032FEC46FD66A@AS1PR10MB5697.EURPRD10.PROD.OUTLOOK.COM>

On Fri, 2026-02-06 at 07:42 +0000, Peter Marko via lists.openembedded.org wrote:
> > On Fri Feb 6, 2026 at 6:24 AM CET, Hemanth.KumarMD via
> > lists.openembedded.org wrote:
> > > Hello Peter,
> > 
> > (Yoann here)
> > 
> > > We sometimes see regressions in glibc test runs depending on the local
> > > environment. In such cases, it can help to re-trigger the tests to
> > > check whether the failures are consistently reproducible. It may also
> > > be useful to cross-check the results with autobuilder runs, which
> > > generally provide a more stable baseline before concluding on
> > > regressions.
> 
> I am planning to run the testsuites again during weekend.
> I also find it weird that every update shows different "before" results than previous one showin in "after" result.
> Not sure if it's flakiness or local conditions like CPU overload at time of running tests.
> 

For context, many of the 'toolchain' testsuites have some flaky tests
in them and we don't always see consistent output.

For example, the 5.0.14 regression report mentions:

https://downloads.yoctoproject.org/releases/yocto/yocto-5.0.14/testresults/testresult-regressions-report.txt

Regression:  oeselftest_almalinux-8.10_qemuarm_20251014024649
             oeselftest_almalinux-9.7_qemuarm_20251118011611
    Total: 3 new regression(s):
    1 regression(s) for ptestresult.gcc-libstdc++-v3-user
        ptestresult.gcc-libstdc++-v3-user.30_threads/async/async.cc execution test: PASS -> FAIL
    2 regression(s) for ptestresult.glibc-user
        ptestresult.glibc-user.misc/tst-linux-mremap1: UNSUPPORTED -> FAIL
        ptestresult.glibc-user.misc/tst-pidfd: UNSUPPORTED -> FAIL

or:

    5 regression(s) for ptestresult.glibc
        ptestresult.glibc.elf/ifuncmain8: PASS -> No matching test result
        ptestresult.glibc.elf/tst-tls20: PASS -> FAIL
        ptestresult.glibc.iconvdata/mtrace-tst-loading: PASS -> FAIL
        ptestresult.glibc.iconvdata/tst-loading: PASS -> FAIL
        ptestresult.glibc.nptl/tst-thread-affinity-pthread: PASS -> FAIL

over time we've been trying to investigate and resolve these kinds of
issues but we're obviously not there yet.


I can say we've made big improvements, you can see it in the numbers,
e.g. comparing:

https://downloads.yoctoproject.org/releases/yocto/yocto-4.0/testreport.txt - 142,413 failures
https://downloads.yoctoproject.org/releases/yocto/milestones/yocto-5.3_M3/testreport.txt 1,636 failures

which shows a definite improvement! The number of flaky test results
has also decreased but is obviously not as easy to measure.

We have a policy with ptests and rust of no failures. We're trying to
get there with gcc/binutils/glibc/ltp.

The test results are stored in the testresults.json files and
resulttool knows how to generate reports and compare files for
regression reports.

The plus side of the autobuilder results is that we have a long
baseline for comparison and a relatively stbale testing environment
which should be consistent.

Cheers,

Richard






  reply	other threads:[~2026-02-06 10:19 UTC|newest]

Thread overview: 24+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-01-25 16:16 [OE-core][scarthgap][PATCH] glibc: stable 2.39 branch updates Peter Marko
2026-02-05 17:08 ` Yoann Congal
2026-02-08 15:18   ` Marko, Peter
2026-02-06  5:24 ` [scarthgap][PATCH] " Hemanth.KumarMD
2026-02-06  6:47   ` [OE-core] " Yoann Congal
2026-02-06  7:42     ` Marko, Peter
2026-02-06 10:19       ` Richard Purdie [this message]
2026-02-06  8:19     ` Hemanth Kumar M D
2026-02-06  9:43       ` Yoann Congal
  -- strict thread matches above, loose matches on Subject: below --
2025-10-07  6:31 Deepesh.Varatharajan
2025-10-07 21:30 ` [OE-core] " Khem Raj
2025-10-13  5:43   ` Deepesh Varatharajan
2025-10-13  6:11     ` Khem Raj
2025-07-21 12:23 Deepesh.Varatharajan
2025-07-22  1:38 ` [OE-core] " Khem Raj
2025-06-17 21:11 [OE-core][scarthgap][PATCH] " Peter Marko
2025-05-01  3:03 [scarthgap][PATCH] " Deepesh.Varatharajan
2025-05-01  5:54 ` [OE-core] " Khem Raj
2025-05-02  3:15   ` Deepesh Varatharajan
2025-05-02  3:25     ` Khem Raj
2025-05-02 10:34       ` Randy MacLeod
2025-05-05  4:06         ` Deepesh Varatharajan
2025-02-02 15:52 [OE-core][scarthgap][PATCH] " Peter Marko
2024-09-29 16:18 [scarthgap][PATCH] " Deepesh.Varatharajan
2024-09-29 16:59 ` [OE-core] " Khem Raj
2024-05-17 16:22 sundeep.kokkonda
2024-05-17 16:33 ` Sundeep KOKKONDA
2024-05-17 16:48   ` [OE-core] " Khem Raj
2024-05-17 16:53 ` Marko, Peter
2024-05-17 21:09   ` Steve Sakoman

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=b885c311ab2d6e31289f5bc857340e96ffc530bc.camel@linuxfoundation.org \
    --to=richard.purdie@linuxfoundation.org \
    --cc=Hemanth.KumarMD@windriver.com \
    --cc=openembedded-core@lists.openembedded.org \
    --cc=peter.marko@siemens.com \
    --cc=yoann.congal@smile.fr \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox