Hi, On Wed, May 27, 2026 at 6:12 AM Fabian Grünbichler <[email protected]> wrote: > > (CCing debian-rust@) > > On Tue, May 26, 2026, at 9:30 PM, Paul Gevers wrote: > > Hi riscv64 porters, > > > > [..] > > > > PS: I personally have the impression that rust is a particular problem > > on riscv64. While I recognize most things are slower on riscv64 > > hardware, it seems that rust is extra slow. The ci.d.n team is > > considering to reject_list all rust packages on riscv64. > > That has also been our experience in the Rust team - we started cutting down > the worst offenders by skipping most tests on riscv64 (and I've considered > doing that automatically for all packaged crates managed with debcargo..). But > besides the bad performance, riscv64 has also been the architecture with the > longest run of plain stability issues for Rust - i.e., random/flaky segfaults, > aborts and similar problems affecting a wide range of crates/test suites. I > don't have systematic data (and the few times I asked it was mostly described > as hardware/kernel combination causing them), but it is probably not too hard > to extract from debci logs. >
I would like to add some context regarding the current state of ci.d.n on riscv64 in Debian, especially in relation to Rust packages' instability reports and timeout/resource concerns. First, it is important to note that riscv64gc is currently only a Tier-2 target in Rust upstream. In practice, this means there is still no comprehensive upstream CI[0] coverage for riscv64 if it compares to x86_64 and aarch64. While working on our internal Rust CI infra, we have found several Rust upstream test failures and architecture specific issues due to missing the riscv64 CI. For example: - https://github.com/rust-lang/gccjit.rs/pull/64 - https://github.com/rust-lang/rust/issues/150050 - https://github.com/rust-lang/miri/issues/4989 - https://github.com/rust-lang/rust/issues/155830 Given that these issues exist in `rust-lang/*` itself, it is very likely that a broader ecosystem of crates will be affected due to the lack of GitHub riscv64 runners support, may contain latent riscv64 specfic bugs, races, symbol checks, or timeout-sensitive cases that have simply not been exposed before. Second, performance on current riscv64 hardware is still a major factor. This is especially evident when building Rust packages and running its test suites. To reduce debci pressure on riscv64, we introduced newer and faster riscv64 machines than buildd machines. and we greatly appreciate the continued work from elbrus and others who help to maintain these infrastructures. This might cause some problems, I'll explain later. Personally, I would prefer not to skip rust-* test on ci.d.n also unless we are currently out of control. If additional riscv64 hardware resources on ci.d.o can reduce pending-related annoying and improve overall stability, then it may be better to first keep the tests enabled and continue observing the failures. Some of these failures may reflect genuine riscv64-specific issues in Rust or in the wider crate ecosystem, rather than being purely infrastructure noise. In that sense, debci currently provides very useful exposure for issues that might remain unnoticed upstream due to the limited riscv64 CI in Rust itself or a wider range of other packages. Certainly, one practical issue needs to be considered here also: If some failures ultimately proved to stem primarily from hardware limitations, insufficient platform maturity, or non reproduced random instability, then it may cost the package maintainer some valuable time wasted on this. This is a point that certainly requires careful balancing. If this happened, please send it to [email protected] then we will have a look. Next, we are planning to deploy more high-performance riscv64 hardware with better upstream support(may take one or two months), which should help improve overall stability and reduce some of the current performance-related issues in Rust package testing on riscv64. BR, Bo [0]: https://github.com/rust-lang/infra-team/issues/201
