bug#48024: glib-2.62.6 build fails i686

[Mark H Weaver <mhw@netris.org>]

Hi Efraim,

Efraim Flashner <efraim@flashner.co.il> writes:
> In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
> respectively.

Right.  Unfortunately, these timeouts are too short for many slower
machines, such as 32-bit ARM systems.  Bone Baboon has also recently
reported being unable to build 'glib' on a 32-bit i686 system due to
these timeouts, even when making extreme efforts to reduce load from
other processes.

> As I understand it, the tests which are are tagged '+slow' get the
> test_timeout_slow property, with the test taking the longest on that
> machine was glib:glib+slow / gvariant, at 65 seconds. By comparison, on
> my Ryzen 3900XT machine it took 2.58 seconds. I figured even at double
> that time it still fell within the 180 seconds given by default in the
> test suite so it was likely safe to remove the substitution entirely.

I think that this recently-reported bug (<https://bugs.gnu.org/48024>)
demonstrates that we can't safely remove the substitution.

> I don't have other suitably slow hardware to test on, but I am building
> it on my aarch64 board too, so I should be able to say in a day or two
> if it works there.

I don't see how a build test on your aarch64 board is relevant here.
As the comment above the 'increase-test-timeout' phase indicated, the
timeouts were increased for the sake of slower 32-bit ARM boards.

I think that we should re-introduce the 'increase-test-timeout' phase
for all systems on the 'core-updates' branch.  Is there a disadvantage,
besides having to wait a couple more minutes if a test fails to
terminate?

What do you think?

      Regards,
        Mark

-- 
Disinformation flourishes because many people care deeply about injustice
but very few check the facts.  Ask me about <https://stallmansupport.org>.