Greg Hogan <[email protected]> writes:
> On Wed, Dec 18, 2024 at 12:43 PM Suhail Singh <[email protected]>
> wrote:
>>
>> Suhail Singh <[email protected]> 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
