bug#48024: glib-2.62.6 build fails i686

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

Hi,

Bone Baboon <bone.baboon@disroot.org> writes:

> Mark H Weaver writes:
>> 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

Did you also run "make"?

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

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

>> Alternatively, you *might* be able to build 'glib' successfully by not
>> doing anything else with your machine while it's building 'glib'.  [...]
>
> 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.

Oh well, thanks for trying.

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

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

I'll postpone commenting on most of these, in case you decide to use the
"guix pull --url" method.  A few comments though:

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

I've never used channels, and I'm not sure off-hand how to make them
work with my unusual approach.

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

This wouldn't work.  It's not enough to merely ask 'guix' to use your
substitute server.  If you did this, your clients would use the official
Guix package descriptions from our 'master' branch, but would look for
builds of those official packages on your substitute server.

To make this work, you would _also_ need to pass "--url <YOUR_GIT_REPO>"
each time you run 'guix pull' on your client machines.

Alternatively, if you chose to use my unusual approach, you'd need to
have built git checkouts of your custom branch of Guix on each of your
client machines, and run Guix from those git checkouts.

      Regards,
        Mark

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