bug#54292: Commit e8518c43 breaks guix pull on i686

[Liliana Marie Prikler <liliana.prikler@ist.tugraz.at>]

Hi Diego,

Am Montag, dem 07.03.2022 um 18:12 +0000 schrieb Diego Nicola Barbato:
> Hi Liliana,
> 
> Liliana Marie Prikler <liliana.prikler@ist.tugraz.at> writes:
> 
> > Hi,
> > 
> > Am Montag, dem 07.03.2022 um 12:47 +0000 schrieb Diego Nicola
> > Barbato:
> > > Hi Guix,
> > > 
> > > Commit e8518c43 (gnu: Add stex) breaks guix pull, specifically
> > > the package cache hook, on i686-linux.
> > This series also fails on CI in a rather peculiar manner [1,2,3]. 
> > However, it succeeded on bordeaux, even for i686 [4].
> 
> While these CI issues are certainly interesting and possibly
> deserving of their own bug reports, they have little to do with this
> bug report: I didn't try to build chez-nanopass [1],
> chez-scheme-for-racket-bootstrap-bootfiles [2], or racket [4] itself
> and I didn't experience any offloading errors [3].  This bug report
> is about guix pull failing to build the package cache on i686-linux
> (the package cache is one of the last things guix pull builds, it
> didn't have any trouble building guix-packages-base, guix-packages,
> guix-system, guix-home, guix-cli, etc.).
These are very much related in that they all belong to the same series.
We would not only have to revert that single commit, but all following
commits authored by Philip as well.

> > I don't think this is an issue with the patch, we should start
> > challenging berlin.
> 
> I do think this is an issue with commit e8518c43 because
> 
> --8<---------------cut here---------------start------------->8---
> guix pull --commit=e8518c43 --system=i686-linux -p /tmp/guix
> --8<---------------cut here---------------end--------------->8---
> 
> fails to build the package cache whereas 
> 
> --8<---------------cut here---------------start------------->8---
> guix pull --commit=75f9f944 --system=i686-linux -p /tmp/guix
> --8<---------------cut here---------------end--------------->8---
> 
> succeeds (75f9f944 being the parent commit of e8518c43).  I even ran
> these with --substitute-urls=https://bordeaux.guix.gnu.org in a
> freshly downloaded instance of the 1.3.0 QEMU image [5] to rule out
> corrupted substitutes from berlin with the same result.
For the sake of completeness, I'll be running this with --no-
substitutes and see what happens.  If you want to try the same without
rebuilding the world, I suggest first pulling
b5f654b238dd3dec43b0ee9e08b78981cf8de981 with substitutes -- that is
the last commit before the series. 

> 
Cheers