Hi,

On Tue, 12 Nov 2024 21:59:42 +0900
Maxim Cournoyer <maxim.cournoyer@gmail.com> wrote:
> Great.  That said, I wouldn't be against stopping building i686
> packages on our build farm.  Nobody has shown much interested in
> fixing the broken ones or hunting down test failures... it seems
> better to focus our energy elsewhere and clear the view in my opinion
> (such as old bugs on our bug tracker that lingers on)
> 
> So I'd be of the opinion to:
> 
> 1) Stop building i686 packages
> 2) Otherwise preserve the architecture in Guix source so that someone
> can at least build from source and hack on it if they wish, e.g. to
> test cross-building packages.
In GNU Boot we chose to use i686-linux as the system we build packages
for as this way we support both i686 and x86_64 (some of the computers
we support are still i686).

Though for now we fixed the revision to Guix 1.4.0 so it means that we
don't find regressions affecting newer revisions.

I also personally also depend on i686 computers (ThinkPad X60) that I
don't use every day but that are important for me: they hold the
signature key of my gpg key and they are way easier to secure than
x86_64 machines against evil maid attacks (the machines were audited,
and don't allow DMA from external ports unlike all the x86_64 machines
supported by GNU Boot). But here too they are not updated regularly.

So does it means that we ultimately need to run our own builder for
i686 or are there other options (like setting up our own CI, going back
to i686 to test builds (I was running i686 to be able to find and fix
what didn't work before), etc), using latest Guix revisions to test more
often, etc?

All the use cases above only require very basic software to work: we
don't need full blown desktop systems (that would probably require to
bootstrap rust and I didn't really manage to find a way that would work
in Guix).

Denis.