bug#48024: glib-2.62.6 build fails i686

[Bone Baboon]

Mark H Weaver writes:
> Did you also run "make"?

I have now.

> Hmm.  Can you please grep the build log for "TIMEOUT" and
> "increase-test-timeout", and show me the matching lines?

"increase-test-timeout":
```
starting phase `increase-test-timeout'
phase `increase-test-timeout' succeeded after 0.1 seconds
```

"TIMEOUT":
```
 53/259 glib:glib / rec-mutex                   TIMEOUT 120.03 s
 83/259 glib:glib / 1bit-mutex                  TIMEOUT 120.02 s 
 84/259 glib:glib+slow / 1bit-emufutex          TIMEOUT 180.05 s
```

Attached is the build log.

>>> (Incidentally, I *always* use Guix this way, using my own private branch
>>> of Guix, never using "guix pull", and never using substitutes.)
>>
>> This is interesting to me.
>
> I outlined how I use Guix in the following message:
>
>   https://lists.gnu.org/archive/html/guix-devel/2021-03/msg00625.html
>
> However, note that there are some significant caveats and "rough edges"
> to this approach.  I can't recommend it in good conscience, unless you
> truly need the extreme flexibility that it provides.
>
> To avoid the rough edges, I'd suggest using "guix pull --url" as
> outlined in the last two paragraphs of the message above.  For most
> purposes, I suspect you'd be much happier with that approach.

Thank you for sharing this.  Also thank you for the warning about 'significant 
caveats and "rough edges"'.

As a new user of Guix I think I will initially try to use the official
Guix repository.

However the message from Tobias Geerinckx-Rice in
https://issues.guix.gnu.org/48213 gives me the idea that your flexible
approach could be very useful if I find myself in a situation where I
have an issue that will not be addressed by an upstream project and
that has too much of a maintenance burden for Guix maintainers to take
on.

1kqwp7fsdphlkg75x0bhyw5m49y41d-glib-2.62.6.drv.bz2
Description: Binary data