Re: On the quest for a new release model

[Thiago Jung Bauermann <bauermann@kolabnow.com>]

Greg Hogan <code@greghogan.com> writes:

> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh <suhailsingh247@gmail.com> wrote:
>>
>> Suhail Singh <suhailsingh247@gmail.com> writes:
>>
>> > The issue, as I see it, is the time commitment required from the
>> > release-team.
>>
>> Correction, the issues (IMO) are (in no particular order):
>> 1. the timespan (several weeks)
>> 2. uncertainty around total effort
>> 3. amount of manual effort involved
>>
>> It's unclear which of the three above is the rate-limiting-step.
>
> There is also access to hardware. From doc/release.org:
>
> "Steps #2 and #3 require you to have offloading set up so you can
> build for all the supported architectures.  For instance, if you’re
> running this on an x86_64 machine, you should have ~armhf-linux~,
> ~aarch64-linux~ and ~powerpc64le-linux~ machines in your
> =/etc/guix/machines.scm=. Transparent emulation via QEMU has shown
> limits (such as causing test suite failures); real hardware is a
> must."

In my experience, QEMU system emulation works better than user-mode
emulation so an alternative that I believe would work (though it would
be slow) would be to set up QEMU VMs for armhf, aarch64 and powerpc64le
(virt-manager is a convenient GUI to set these things up) and use them
for offloading.

> Can the armhf release artifacts be built on aarch64? That fails for
> some packages but might work for releases.

Not all aarch64 processors can run armhf code, but many can. This can be
seen in the "CPU op-mode(s)" field of lscpu. E.g.:

$ lscpu
Architecture:                       aarch64
CPU op-mode(s):                     32-bit, 64-bit
Byte Order:                         Little Endian
CPU(s):                             32
On-line CPU(s) list:                0-31
     ⋮
--
Thiago