Debian's MIPS64EL CPU Port Is At Risk Due To Declining Hardware Access

[phoronix]

Phoronix: Debian's MIPS64EL CPU Port Is At Risk Due To Declining Hardware Access

Debian's MIPS64EL that is a 64-bit little endian port using the N64 ABI is at risk due to declining access for building the Debian 64-bit MIPS packages. MIPS64EL is now being treated as an "out of sync" architecture due to lacking sufficient build daemon resources for timely building new packages and if the situation doesn't improve, it may not be suitable as a release architecture for Debian 13 "Trixie"...

https://www.phoronix.com/news/Debian-MIPS64EL-Risk

[OneTimeShot]

Can’t they build this in qemu? It doesn’t really make sense to support architectures that do not have a good emulator.

[CommunityMember]

Can’t they build this in qemu? It doesn’t really make sense to support architectures that do not have a good emulator.

I believe the Debian system administration team requires their official buildd machines to be physical systems (along with other common datacenter requirements, so, essentially, "server class" hardware).

The requirement for physical machines with datacenter support is one of the holdups for getting RISC-V to be a fully supported architecture for some distros, as "server class" RISC-V systems are still mostly unobtainium.

[OneTimeShot]

Ah… so the problem is not really that they can’t afford another VM in AWS. They are just being bureaucratic.

[kpedersen]

Ah… so the problem is not really that they can’t afford another VM in AWS. They are just being bureaucratic.

There is a technical aspect to it too. For example OpenBSD's stance has been to prefer physical machines:

Virtual machines are rarely functional hardware tests, because there is always a software layer between the host and guests. Only when that layer is the hardware's own microcode could you consider the hardware directly involved. If there is a host OS or a hypervisor, then the guest is divorced from the hardware. We could argue how large a separation that is, but there is still a separation from the hardware.

[iustinp]

Ah… so the problem is not really that they can’t afford another VM in AWS. They are just being bureaucratic.

Sigh. Feel free to step up and maintain it yourself then. It's soo easy to comment from the sidelines, no?

(A Debian maintainer, who has had to deal with obscure arch support once or twice)

[rene]

There is a technical aspect to it too. For example OpenBSD's stance has been to prefer physical machines:

Qemu is also pretty slow. Nothing like building your OS with 1/20th the performance and usually not SMP, ... so 1/20/32 of native epyc thread ripping performance, ...

[NovenTheHero]

Where does one even get the hardware to do this? I don't even know what such a system would look like.

[rene]

cool, guess one day everyone will just use T2 Linux ;-) https://t.ly/giNHP

[transwarp]

Ah… so the problem is not really that they can’t afford another VM in AWS. They are just being bureaucratic.

QEMU isn't perfect. With rare architectures like this, you risk writing to QEMU's bugs. Remember when the VersatilePB support in Linux was broken, and only worked with the QEMU version that everyone was developing against and testing on?