AB-INT issues - where we could use help

[Richard Purdie <richard.purdie@linuxfoundation.org>]

Hi,

There are at least a couple of intermittent issues where we would
welcome some help and we now probably have enough information to allow
debugging/progress.

Firstly, we suspect there is a reproducibility issue arm to x86. This
is summarised with this reproducibility diff:

https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20260726-9wb1l3t4/packages/diff-html/

(from
https://valkyrie.yocto.io/pub/repro-fail/oe-reproducible-20260726-9wb1l3t4/packages/diff-html/)

I suspect what happened here is that the qemux86-64 files were built
first on an arm host rather than an x86 host. In general the x86 hosts
probably beat the arm hosts to it, hence why this is rare.

To test/reproduce this, I'd suggest picking a target machine (say
qemux86-64) and then building diffutils on both an x86-64 based host
and on an aarch64 host. Comparing the ptest package will probably
result in a diff similar to the above, e.g.:

build_triplet·=·aarch64-unknown-linux-gnu

vs.

build_triplet·=·x86_64-pc-linux-gnu

in usr/lib/diffutils/ptest/tests/Makefile amongst other things. I
suspect picking MACHINE=qemuarm64 would have the same result.

If that reproduces the issue, it would then be a case of iterating
through the differnces and finding a way to reconcile the output so it
is the same, independent of build host architecture.



The second issue where we could potentially take help is with 

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

This is the infamous matchbox segfault, now strong suspected to be the
xserver restarting during boot. There are several things which could
help here:

* finding out whether it always restarts the xserver?
* is there a way to crash the xserver like that (race with psplash for
the console?)
* working out if we can reproduce the matchbox crash using some delays
placed in some of the code to widen the race window?

Given what we suspect is happening, we can likely improve the code to
exit cleanly when the suspected memory allocation failure occurs rather
than crashing too.

Cheers,

Richard