(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. In any case I am happy to test things on the toolchain side, or adjust he default list of arch restrictions in debcargo to always only run the all features case on riscv64, if that seems like a better hammer than disabling rust-* on debci outright. That being said, most crate tests there seem to just be good at flagging this riscv64 specific flakiness and bad performance, and not actual riscv64 specific issues in the packaging or sources, in my experience. If you do end up disabling rust-*, please take care to keep rustc itself tested if possible! Fabian
