GNU bug report logs - #48024
glib-2.62.6 build fails i686

Previous Next

Package: guix;

Reported by: Bone Baboon <bone.baboon <at> disroot.org>

Date: Mon, 26 Apr 2021 03:38:02 UTC

Severity: normal

Done: Maxim Cournoyer <maxim.cournoyer <at> gmail.com>

Bug is archived. No further changes may be made.

Full log


View this message in rfc822 format

From: Mark H Weaver <mhw <at> netris.org>
To: Efraim Flashner <efraim <at> flashner.co.il>
Cc: 48024 <at> debbugs.gnu.org, raingloom <raingloom <at> riseup.net>, Bone Baboon <bone.baboon <at> disroot.org>
Subject: bug#48024: glib-2.62.6 build fails i686
Date: Tue, 04 May 2021 16:01:54 -0400
Hi Efraim,

Efraim Flashner <efraim <at> 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>.




This bug report was last modified 3 years and 121 days ago.

Previous Next


GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.