bug#48024: glib-2.62.6 build fails i686

[Efraim Flashner]

On Mon, May 03, 2021 at 11:01:22PM -0400, Mark H Weaver wrote:
> Hi,  [added Efraim Flashner to the CC list]
> 
> Bone Baboon <bone.baboon@disroot.org> writes:
> 
> > Thank you for your helpful response.
> >
> > Would a patch like this that addresses test timeouts be good to have in
> > the Guix repository?  It would help other Guix users who also run into
> > test timeouts when building glib.
> 
> Good question!  The problem is that applying this patch would entail
> rebuilding every package that depends on 'glib' for i686-linux, which is
> likely on the order of thousands of packages.  By policy, we don't make
> changes that require so many rebuilds on our 'master' branch.  Instead,
> such changes must be made on 'core-updates', or possibly 'staging',
> which are merged into 'master' a few times a year.
> 
> The plan seems to have been to remove the conditional on our
> 'core-updates' branch, so that the 'increase-test-timeout' phase would
> be included on *all* architectures.  See the comment above the code:
> 
>   
> <https://git.sv.gnu.org/cgit/guix.git/tree/gnu/packages/glib.scm?id=b9fb13b28437a254683273094f189396a6e1421d#n231>
> 
> However, I see now that the 'increase-test-timeout' phase was recently
> completely _removed_ by Efraim on our 'core-updates' branch a couple of
> weeks ago, in the following commit:
> 
>   
> <https://git.sv.gnu.org/cgit/guix.git/commit/?h=core-updates&id=a24562af52d2f318c9e17be73393ddb4bd9e347c>
> 
> Efraim: What was the rationale for removing that phase?
> 
> I think it would be good to keep that phase, for the benefit of users
> building 'glib' on slower machines.  I think the intent was to remove
> the conditional, but to keep the body that's within the conditional.
> 
> What do you think?
> 
>       Regards,
>         Mark
> 

As part of my powerpc efforts I built glib on my way to building ...
something. This is on an iBook G4 with the original 4200 RPM drive from
~15 years ago, so old hardware.

In glib-2.68 test_timeout and test_timeout_slow are set to 60 and 180
respectively. I initially merged the increase-test-timeout changes to
apply to all architectures, and then changed the time to 240 before
changing it to 1800 during my testing. I've attached the build log from
that round.

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 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.

-- 
Efraim Flashner   <efraim@flashner.co.il>   אפרים פלשנר
GPG key = A28B F40C 3E55 1372 662D  14F7 41AA E7DC CA3D 8351
Confidentiality cannot be guaranteed on emails sent or received unencrypted

l8yf5a7jj5mz6s67fffhylyk7w1jbg-glib-2.68.0.drv.gz
Description: application/gunzip

signature.asc
Description: PGP signature