In package rust-src, /usr/src/rustc-1.94.1/Cargo.lock and usr/src/rustc-1.94.1/library/Cargo.lock are locked at crate versions unsatifiable in Debian, e.g. rustc-demangle 0.1.26 and object 0.37.3. Also, /usr/src/rustc-1.94.1/library/std/Cargo.toml requires newer-than-Debian crate including object 0.37.1, and missing-in-Debian crates including dlmalloc and wasi. -----BEGIN PGP SIGNATURE----- iQJABAEBCgAqFiEEn+Ppw2aRpp/1PMaELHwxRsGgASEFAmnh3qsMHGRyQGpvbmVz LmRrAAoJECx8MUbBoAEhEzkP/RgkBQ2/JRyt44fYgC83/3PhvdGfzddGi0jqOVK7 DbdS9je5FBAhW8gobZwQ/PrFvH4r4q4HfFFt7MZeZngVOjF/Ytb7tRVC8xbpSM1F qcspa8xYxJm8mVcGYH1fqzSYkCASanh67+PmRsmrVPCypOGPXkQtd51RZhuRM+0H 8nxdHSkSwVFvQO4abRU6GupBWtKNBB9Qi3CfoikRP2MERe4zZppe00DMAfBiwgh7 Yyz1OOxEkmOO4mcBC93WNxHhfw4mKnBhYQnVyHASHeLxYqNSG0V/E8Qx109jF/Wo sJHq8tnGQMOSs2WfMQl4xEVT80vHNVl8N/XDTXLyo4kD3NVCMtsX/VEZjHIFOmFM vtqWZC+433OV4l1/O6MgtCY2kIj0jyDzwSvuHUIzsh9GBbuw/tjY/4Miw1WlH1Aw eGB9IcGUynMG+WYGDDFZRSWwdAIF67inkh33Nv95FG4ub9gnYNAcq5gPJutPXPp3 XFfEqyoZ90/wqLetgXaOibceYRxUa6SkMPihNcJ2T1Kbrz0c75lOtS+IpOpzFUOM fBRLKxztdkDxvcUrvMko4gBWll3gEykj1qgDs8wKCc6fPw5mTXKWV9NM1UTCtVeu tdADU82qEliwriQrybWWSxeLJcvtOa6HoS68eW2z1TW3Y+S5T3JXTaZu2yq1X7qQ 8GIM =xWTE -----END PGP SIGNATURE-----
Control: severity -1 wishlist Control: tag -1 +moreinfo I am not sure what this severity is supposed to mean, given the lack of justification ;) Downgrading accordingly, but I am willing to reconsider if you provide a reason. crates, so the code shipped in rust-src cannot either. The purpose of rust-src is (at the moment) twofold: - allow navigating into libstd/libcore sources for IDE and editor integration, e.g. via rust-analyzer (as per the package description) - allow using `-Zbuild-std` when using *just the toolchain* (by pretending to be nightly rustc via RUSTC_BOOTSTRAP) Neither of this requires matching rust-src dependency information with packaged crates, the latter in fact would not work at all in that case unless rustc packaging itself is switched over to use packaged crates, which is not really feasible. I hope this clears things up, if not - please clearly describe what you want to do and what doesn't work, maybe we can find a solution. Thanks, Fabian
Quoting Fabian Grünbichler (2026-04-17 18:15:25) Thanks a lot for the elaborate clarification, and sorry that I was way too brief. Yes, it is fine with me to lower severity. What I was thinking but forgot to write was that the severity I set is intended only as a first proposal: I don't really understand the prupose of that package, and you are as maintainer of course free to lower as you see fit. Now, the reason I stumbled upon and reported the issue in the first place was that the binary package libstd-rust-dev-wasm32 had mysteriously gone, and when I tried to use wasm-package without it, it mentioned needing rust-src. After filing the bugreport I realized that the reason for the disappearance was simply a delay in building the arch-all part of the newly released rustc source package. Oxigraph now succesfully builds using wasm-pack again. It sounds like there is no bug here at all. Feel free to close this if that's how you see it. - Jonas
I can see how you ended up thinking that rust-src is broken, that message is indeed confusing in Debian context! It points at the second use case I described - rebuilding libstd for targets not packaged, or with settings not matching the packaged version. The wasm libstd was indeed late this time around (as was the bpf one), because I forgot to upload a matching wasi-libc for the rustc upload. I think I'll leave it open to track maybe finding a way to support -Zbuild-std in packaging context as well (e.g., to unlock some firmware building usecase in the future, that might require a custom libstd). It's a bit of a tough nut to crack though, because there can only be one replacement for crates.io (which we already use for packaged crates), so we'd probably need to ship a copy of the vendored crates as part of rust-src, and adapt all the dependencies to be path dependencies, and so on. Fabian
Control: tag -1 +pending It turned out that this is actually easier than I thought. Starting with the next rustc upload, rust-src will ship a copy of the few vendored crates needed to rebuild std/core/alloc. If you make them available to cargo (i.e. by linking them into the fake registry), a lot of build-std variants already work (some targets will of course require extra setup or dependencies, like special linkers or LLVM bits). Upstream will start doing that as well: https://github.com/rust-lang/rust/pull/156196 and plans to later switch build-std over to automatically pick those up, at which point even linking them into the registry would no longer be required.