feat(ci): build loongarch64 binaries in CI

[SkyBird233]

Summary

This PR adds support for building loongarch64 binaries in CI. As uv itself runs perfectly well on loongarch64 and with the latter's userbase steadily growing, it would be a good idea to ship prebuilt binaries to help them out.

Please note that as Ubuntu is not yet available for loongarch64, I have elected to use a Debian Trixie container maintained by community members. In addition, as Debian's pip does not allow installing modules system-wide, the workflow for loongarch64 installs additional modules in a virtual environment.

Test Plan

Tests are included in CI and the loongarch64 artifacts built in this workflow has been smoke tested.

[zanieb]

As with astral-sh/python-build-standalone#653 I think we're blocked on clearing this with our lawyers first.

[MingcongBai]

As with astral-sh/python-build-standalone#653 I think we're blocked on clearing this with our lawyers first.

Interesting... Just out of curiosity, what legal challenges/processes are we facing with this?

[shauneccles]

Sanctions is my guess - https://www.tomshardware.com/news/us-govt-blacklists-loongson-and-inspur

[MingcongBai]

Sanctions is my guess - https://www.tomshardware.com/news/us-govt-blacklists-loongson-and-inspur

Same guess as mine but was wondering if they could just say it outright.

[zanieb]

Yeah, the sanctions.

[xen0n]

My two cents... (Disclaimer: IANAL and I'm Chinese, unaffiliated with Loongson though, so take my words with a grain of salt. I'm just trying to bring some constructive points forward because I am a LoongArch user and community contributor myself.)

Technically the sanctions only affect the company entity, and LoongArch is just an abstract ISA, even though right now all readily available LoongArch CPU models are from Loongson. And the contributor is not a Loongson employee AFAIK. So maybe having anything to do with this PR doesn't imply any relationship with or endorsement of Loongson?

On the other hand, like it or not politics is not going anywhere, and not producing LoongArch binaries wouldn't stop the community from doing so downstream, so maybe the net effect is just making community packagers' and LoongArch daily-drivers' lives harder. Is it possible to both keep being "compliant" and somehow not regress downstream UX when they want to just install uv, like allowing people to specify download mirrors or anything equivalent?

[andypost]

Would be great to add this kind of testing as starting with 0.8.13 building uv fails for Alpinelinux on rustix
see the full log https://gitlab.alpinelinux.org/alpine/aports/-/jobs/1985668

[andypost]

0.8.14 fails too

error[E0659]: `STATX_TYPE` is ambiguous
   --> /home/buildozer/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustix-1.0.8/src/fs/statx.rs:73:25
    |
73  |         const TYPE = c::STATX_TYPE;
    |                         ^^^^^^^^^^ ambiguous name
    |
    = note: ambiguous because of multiple glob imports of a name in the same module
note: `STATX_TYPE` could refer to the constant imported here
   --> /home/buildozer/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustix-1.0.8/src/backend/libc/c.rs:7:16
    |
7   | pub(crate) use libc::*;
    |                ^^^^^^^
    = help: consider adding an explicit import of `STATX_TYPE` to disambiguate
note: `STATX_TYPE` could also refer to the constant imported here
   --> /home/buildozer/.cargo/registry/src/index.crates.io-1949cf8c6b5b557f/rustix-1.0.8/src/backend/libc/c.rs:512:16
    |
512 | pub(crate) use statx_flags::*;
    |                ^^^^^^^^^^^^^^
    = help: consider adding an explicit import of `STATX_TYPE` to disambiguate

[SkyBird233]

FYI @andypost, here's the tracking issue for the rustix problem: bytecodealliance/rustix#1496. It appears to be unrelated to uv.

[andypost]

@SkyBird233 thank you, following

[MingcongBai]

My two cents... (Disclaimer: IANAL and I'm Chinese, unaffiliated with Loongson though, so take my words with a grain of salt. I'm just trying to bring some constructive points forward because I am a LoongArch user and community contributor myself.)

Technically the sanctions only affect the company entity, and LoongArch is just an abstract ISA, even though right now all readily available LoongArch CPU models are from Loongson. And the contributor is not a Loongson employee AFAIK. So maybe having anything to do with this PR doesn't imply any relationship with or endorsement of Loongson?

On the other hand, like it or not politics is not going anywhere, and not producing LoongArch binaries wouldn't stop the community from doing so downstream, so maybe the net effect is just making community packagers' and LoongArch daily-drivers' lives harder. Is it possible to both keep being "compliant" and somehow not regress downstream UX when they want to just install uv, like allowing people to specify download mirrors or anything equivalent?

Hi @zanieb, were you able to hear back from your lawyers?

[zanieb]

I can't comment on that until we have a policy, sorry. We're working on it.

[MingcongBai]

I can't comment on that until we have a policy, sorry. We're working on it.

Good to know, thanks.