linux/riscv64 platform

[terrapass]

Hi.
Thank you so much for maintaining these images and for the helpful documentation!

This adds linux/riscv64 platform to dev and dev-alpine targets of both Makefiles, as well as couple of additional dependencies to the Dockerfile's for devpi-server specifically.

Several of the devpi-server requirements don't ship pre-built wheels for RISC-V on PyPI, thus needing to be compiled from source during pip install on that platform. At least one of them (nh3, I believe) requires Rust, hence the build-time cargo dependency. Additionally, for the alpine variant of the image specifically, libgcc is added as a runtime dependency, since one of the built binaries attempts to locate libgcc_s.so.1 at server runtime.

I also took the liberty of adding linux/riscv64 to the platforms lists in GitHub Actions for all images. Though note that the aforementioned added compilation time for multiple requirements on RISC-V does significantly increase the total multiplatform image build time for devpi-server.

[JonasAlfredsson]

Thanks for the pull request!

Yeah, the increase in compile time is usually what limits me to include more archs, there is a hard cap of 6 hours (which is surprisingly easy to hit) which we need to keep below.

I just wanted to test this our locally, but seems to get the following error on Alpine, anything you are familiar with before I dig deeper?

#31 128.0             error: could not compile `syn` (lib)
#31 128.0       
#31 128.0             Caused by:
#31 128.0               # I truncated this long command..,..
#31 128.0             warning: build failed, waiting for other jobs to finish...
#31 128.0       
#31 128.0             thread 'rustc' (777) panicked at /rustc-dev/ed61e7d7e242494fb7057f2657300d9e77bb4fcb/compiler/rustc_ty_utils/src/sig_types.rs:69:49:
#31 128.0             called `Option::unwrap()` on a `None` value
#31 128.0             stack backtrace:
#31 128.0                0:       0x40147a8c24 - <std::sys::backtrace::BacktraceLock::print::DisplayBacktrace as core::fmt::Display>::fmt::h0d27387863781a3b
#31 128.0                1:       0x40147d459a - core::fmt::write::h5061b413f9e6386f
#31 128.0                2:       0x401476bea8 - <unknown>
#31 128.0                3:       0x401477c568 - <unknown>
#31 128.0                4:       0x4014783de8 - <unknown>
#31 128.0                5:       0x4014783c62 - std::panicking::default_hook::h82f7280fc114b6db
#31 128.0                6:       0x4012207c94 - <unknown>
#31 128.0                7:       0x40147843ca - std::panicking::panic_with_hook::h8309309ee63abcfc
#31 128.0                8:       0x401478420c - <unknown>
#31 128.0                9:       0x401477c68e - <unknown>
#31 128.0               10:       0x401475f118 - __rustc[33a5e9144a68499]::rust_begin_unwind
#31 128.0               11:       0x40121c50ba - core::panicking::panic_fmt::h1b5eda4800680cc1
#31 128.0               12:       0x40121c5098 - core::panicking::panic::h8078a4341e9642db
#31 128.0               13:       0x40121c46e0 - core::option::unwrap_failed::h0e61b30c3c124d1f
#31 128.0               14:       0x401344e12e - rustc_privacy[19d445675fa8a90e]::check_mod_privacy
#31 128.0               15:       0x40136bc694 - <unknown>
#31 128.0               16:       0x4013727bd8 - rustc_query_system[ea31a59a45a438c3]::query::plumbing::try_execute_query::<rustc_query_impl[998b945314ba2a46]::DynamicConfig<rustc_query_system[ea31a59a45a438c3]::query::caches::DefaultCache<rustc_span[966f4b68cceaf86a]::def_id::LocalModDefId, rustc_middle[a38dffa63ba0b066]::query::erase::Erased<[u8; 0usize]>>, false, false, false>, rustc_query_impl[998b945314ba2a46]::plumbing::QueryCtxt, false>
#31 128.0               17:       0x401383e72e - <unknown>
#31 128.0               18:       0x40123b9666 - <unknown>
#31 128.0               19:       0x40123e040e - rustc_interface[73b30585eaa86810]::passes::analysis
#31 128.0               20:       0x40136c2084 - <unknown>
#31 128.0               21:       0x40136e0a54 - rustc_query_system[ea31a59a45a438c3]::query::plumbing::try_execute_query::<rustc_query_impl[998b945314ba2a46]::DynamicConfig<rustc_query_system[ea31a59a45a438c3]::query::caches::SingleCache<rustc_middle[a38dffa63ba0b066]::query::erase::Erased<[u8; 0usize]>>, false, false, false>, rustc_query_impl[998b945314ba2a46]::plumbing::QueryCtxt, false>
#31 128.0               22:       0x401385ee0a - <unknown>
#31 128.0               23:       0x4012210212 - <unknown>
#31 128.0               24:       0x40121fbb40 - <unknown>
#31 128.0               25:       0x401220b59a - <unknown>
#31 128.0               26:       0x40121fcccc - <unknown>
#31 128.0               27:       0x401220e97a - <unknown>
#31 128.0               28:       0x4014778158 - <unknown>
#31 128.0               29:       0x4001855cf2 - <unknown>
#31 128.0       
#31 128.0             error: the compiler unexpectedly panicked. this is a bug.
#31 128.0       
#31 128.0             note: we would appreciate a bug report: https://github.com/rust-lang/rust/issues/new?labels=C-bug%2C+I-ICE%2C+T-compiler&template=ice.md
#31 128.0       
#31 128.0             note: rustc 1.91.1 (ed61e7d7e 2025-11-07) (Alpine Linux Rust 1.91.1-r0) running on riscv64-alpine-linux-musl
#31 128.0       
#31 128.0             note: compiler flags: --crate-type lib -C opt-level=3 -C embed-bitcode=no -C strip=debuginfo
#31 128.0       
#31 128.0             note: some of the compiler flags provided by cargo are hidden
#31 128.0       
#31 128.0             query stack during panic:
#31 128.0             #0 [check_mod_privacy] checking privacy in module `ugid`
#31 128.0             #1 [analysis] running analysis passes on this crate
#31 128.0             end of query stack
#31 128.0             error: could not compile `rustix` (lib)

[terrapass]

I just wanted to test this our locally, but seems to get the following error on Alpine, anything you are familiar with before I dig deeper?

Can't say that I am: in my local testing both the dev and the dev-alpine targets ran successfully. 🤔
Just in case, I've done docker builder prune and re-run make dev-alpine for the server image just now - still builds fine for me.
Locally I've been running the build commands on Ubuntu 24.04.3 under WSL2.
(Haven't yet tried building them from inside an Alpine container though, in case that's what you meant.)

error: the compiler unexpectedly panicked. this is a bug.
note: we would appreciate a bug report

Interesting message there. I wonder if this could be due to us using different versions of QEMU or the tonistiigi/binfmt image install for the multiplatform build (assuming you're not building on riscv64 hardware directly).
Alternatively, could it be hitting some resource limit, memory or otherwise, in your environment?

---

And thanks for your inline comments, I'll be sure to address them, hopefully some time tonight.
Not sure by how much the CI job time limits should be increased at this point, but I guess we can determine this experimentally.

[JonasAlfredsson]

Just add some random high timeout on the builds, and we can reduce them after the chack run here :)

Tried it out on a little bit older Debian (11 bullseye) system, 8 cores 64 GB RAM.
Docker version 29.2.1, build a5c7197
binfmt/5e2cbca qemu/v10.0.4 go/1.23.12

NAME/NODE        DRIVER/ENDPOINT                   STATUS    BUILDKIT   PLATFORMS
multiarch*       docker-container                                       
 \_ multiarch0    \_ unix:///var/run/docker.sock   running   v0.27.1    linux/amd64, linux/amd64/v2, linux/amd64/v3, linux/386, linux/arm64, linux/riscv64, linux/ppc64, linux/ppc64le, linux/s390x, linux/loong64, linux/arm/v7, linux/arm/v6

It builds well, except for the Alpine riscv one.

[terrapass]

I increased build timeouts to 30 minutes for the client images (not much compiling from sources going on there, so should be plenty), and to 120 and 240 minutes for the Debian and the Alpine server images respectively.

IIRC docker_buildx_debian for the server took about 30 minutes last time, so we should be good there also. Let's see how long the Alpine variant takes (and if it completes successfully on the runner).

---

8 cores 64 GB RAM
binfmt/5e2cbca qemu/v10.0.4 go/1.23.12

Well, that's twice the RAM I have, and those versions are the same as on my local tonistiigi/binfmt image, so there go both of my original guesses.
I also checked the version of rustc being used during the Alpine build, and it came up as rustc 1.91.1 (ed61e7d7e 2025-11-07) (Alpine Linux Rust 1.91.1-r0), same as in your error message.
My Docker and buildkit versions were a bit older, but after updating them to match yours (Docker version 29.2.1, build a5c7197 and buildkit v0.27.1), and clearing caches, the Alpine image still builds fine.

I might be grasping at straws here, but could it be due to us building on top of different versions of the python:3.14.2-alpine base image?
Looks like the tag on Docker Hub was last pushed to only 7 days ago (digest 31da4cb52705), which would be the version that got pulled when I was testing the build locally.
Could it be that the one in your local build environment is older (and potentially missing some newer RISC-V fixes from its own base image)?

FWIW I also just tested the make build-alpine target for the server on a RISC-V machine (namely, Milk-V Jupiter running BianbuOS) and, aside from it taking 3-5 business days to complete, it has likewise managed to build it.

[JonasAlfredsson]

Yeah, did a test build on another system, and it went fine there. Will await the build time result for the GitHub runners, but if they succeed we just merge this and I will have to debug the first computer later :)