On Sat, 12 Jul 2025 at 15:27:32 +0100, Simon McVittie wrote:
As with trixie, unfortunately the libsoup test suite is known to be flaky in several ways, so it might require some retries to herd it through the official Debian infrastructure. See #1109142 for more details.
The mipsel build is failing, but not because of the flaky test infrastructure I was expecting: it seems that one of the build-time unit tests wants to allocate 1G of RAM in two 512M blocks (this particular unit test is specifically exercising what happens when doing http2 with an inadvisably large buffer size), and the mipsel buildds mipsel-osuosl-{03,04,05} apparently don't have that available for 32-bit processes. Do we need a respin of this update with that test skipped on mipsel?
This is probably not (or at least not entirely) a 32-bit-address-space problem, because the armel, armhf and i386 builds were OK; similarly these buildds do physically have enough RAM, because the mips64el build on mipsel-osuosl-03 was successful. It is not a new test in 3.2.3, and 3.2.2 built successfully on mipsel back in 2023, so I assume either libsoup or some dependency must be using just slightly more memory now than it did in 2023, pushing the total memory required beyond what's available.
It is probably possible to replace the failing g_new() call with g_try_new(), and just skip the test if the allocation fails; but my ability to test that change will be very limited, unless I happen to be able to either reproduce the problem on eberlin, or find an x86 qemu VM size that has enough RAM to build the package but not enough RAM to run that one test.
smcv