Bug#1109147: bookworm-pu: package libsoup3/3.2.3-0+deb12u1

[Simon McVittie]

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