bug#48024: glib-2.62.6 build fails i686

[Bone Baboon]

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.

Mark H Weaver writes:
> I also build everything locally, and have sometimes run into problems
> like this on my slower machines.  Overly aggressive test timeouts,
> chosen for powerful developer machines, are annoying.

What are the benefits of aggressive test timeouts chosen for powerful
developer machines?

> The following patch, applied to your copy of Guix, should work around
> the problem:
>
> --8<---------------cut here---------------start------------->8---
> diff --git a/gnu/packages/glib.scm b/gnu/packages/glib.scm
> index c04bd334e9..b8f509306d 100644
> --- a/gnu/packages/glib.scm
> +++ b/gnu/packages/glib.scm
> @@ -230,7 +230,8 @@ shared NFS home directories.")
>                #t)))
>          ;; TODO: Remove the conditional in the next core-updates cycle.
>          ;; Needed to build glib on slower ARM nodes.
> -        ,@(if (string-prefix? "arm" (%current-system))
> +        ,@(if (or (string-prefix? "arm" (%current-system))
> +                  (string-prefix? "i686" (%current-system)))
>                `((add-after 'unpack 'increase-test-timeout
>                    (lambda _
>                      (substitute* "meson.build"
> --8<---------------cut here---------------end--------------->8---
>
> To use this patch, you'll need to apply it to a Git checkout of Guix,
> build it, and then use "/PATH-TO-GIT-CHECKOUT/pre-inst-env guix ..."
> whenever building anything with Guix that depends on glib.

Preparation steps taken:
1) cloned the Guix repository
2) ran `./bootstrap`
3) ran `./configure --localstatedir=/var/`
4) checked out a branch
5) applied the patch

Then in the branch of the Guix repository with the patch applied I ran
the following commands which failed with test timeouts.

`./pre-inst-env guix build --no-substitutes glib`
`./pre-inst-env guix build --no-substitutes --cores=2 glib`
`./pre-inst-env guix build --no-substitutes --cores=3 glib`

> Alternatively, you *might* be able to build 'glib' successfully by not
> doing anything else with your machine while it's building 'glib'.  I
> notice that in your original bug report, only the "1bit-mutex" test
> timed out, but in your later build attempt, a total of 5 tests timed
> out.  These differing results suggest that you might have been running
> other programs at the same time.

I tried this by having only ssh running so I could connect.  Then on a
virtual terminal I ran `guix build --no-substitutes --cores=2 glib`.
This failed with test timeouts.

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

This is how I think a substitute server workflow could be modified to
use this approach.  I would appreciate corrections or suggestions.

On the substitute server

Remove the official Guix substitute server from /etc/guix/acl.

Instead of: `guix pull --no-substitutes`
It would be: `git pull <official-guix-repo>` and merge the updated Guix
              repository with the local patched repository.

Instead of: `guix build --no-substitues <package>`
It would be: `/<path-to-patched-repo>/pre-inst-env guix build <package>`

Instead of: `guix publish <options>`
It would be: `/<path-to-patched-repo>/pre-inst-env guix publish
              <options>`

Instead of: `sudo guix system --no-substitutes reconfigure
             <configuration>`
It would be: `sudo /<path-to-patched-repo>/pre-inst-env guix system
              reconfigure <configuration>`

Substitute server clients would have a channel for the patched
repository and no channel for the official Guix repository.

The commands stay the same on the clients of the substitute server.

`guix pull --substitute-urls=<substitute-server-ip>:<port>`

`sudo guix system --subsitute-urls=<substitute-server-ip>:<port>
reconfigure <configuration>`