Bug#1134157: [Pkg-rust-maintainers] Bug#1134157: rustc-src: impossible to satisfy crate dependencies
Control: tag -1 +pending On Sat, 18 Apr 2026 10:08:37 +0200 =?UTF-8?Q?Fabian_Gr=C3=BCnbichler?= wrote: > On Fri, Apr 17, 2026, at 11:05 PM, Jonas Smedegaard wrote: > [..] > > It sounds like there is no bug here at all. Feel free to close this if > > that's how you see it. > > 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. 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.
Bug#1134157: [Pkg-rust-maintainers] Bug#1134157: rustc-src: impossible to satisfy crate dependencies
On Fri, Apr 17, 2026, at 11:05 PM, Jonas Smedegaard wrote: > Quoting Fabian Grünbichler (2026-04-17 18:15:25) >> Control: severity -1 wishlist >> Control: tag -1 +moreinfo >> >> On Fri, Apr 17, 2026, at 9:18 AM, Jonas Smedegaard wrote: >> > Source: rustc >> > Version: 1.94.1+dfsg1-1~exp3 >> > Severity: grave >> >> 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. >> >> > 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. >> >> This is intentional. rustc and libstd/libcore are not built using >> packaged 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 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. 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. > It sounds like there is no bug here at all. Feel free to close this if > that's how you see it. 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
Bug#1134157: [Pkg-rust-maintainers] Bug#1134157: rustc-src: impossible to satisfy crate dependencies
Quoting Fabian Grünbichler (2026-04-17 18:15:25) > Control: severity -1 wishlist > Control: tag -1 +moreinfo > > On Fri, Apr 17, 2026, at 9:18 AM, Jonas Smedegaard wrote: > > Source: rustc > > Version: 1.94.1+dfsg1-1~exp3 > > Severity: grave > > 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. > > > 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. > > This is intentional. rustc and libstd/libcore are not built using > packaged 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 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 -- * Jonas Smedegaard - idealist & Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ * Sponsorship: https://ko-fi.com/drjones [x] quote me freely [ ] ask before reusing [ ] keep private signature.asc Description: signature
Bug#1134157: [Pkg-rust-maintainers] Bug#1134157: rustc-src: impossible to satisfy crate dependencies
Control: severity -1 wishlist Control: tag -1 +moreinfo On Fri, Apr 17, 2026, at 9:18 AM, Jonas Smedegaard wrote: > Source: rustc > Version: 1.94.1+dfsg1-1~exp3 > Severity: grave 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. > 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. This is intentional. rustc and libstd/libcore are not built using packaged 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
