On Mon, Feb 16, 2026, at 9:33 AM, Emilio Pozuelo Monfort wrote: > On 06/02/2026 17:30, Fabian Grünbichler wrote: >> On Thu, Jan 29, 2026, at 9:32 AM, Emilio Pozuelo Monfort wrote: >>> Package: rustc >>> Version: 1.91.1+dfsg1-1 >>> Severity: normal >>> >>> Hi, >>> >>> rustc includes a script, debian/make_orig-stage0_tarball.sh, to create a >>> stage0.orig.tar.xz that can be used to bootstrap rustc. I don't think that's >>> used much, since new updates in Debian sid will use X-1 from sid to build. >>> However, when uploading a (much newer) version to (old)stable, we don't have >>> X-1, so we need to create and use a -stage0 tarball. >> >> It is mainly used for rebootstrapping when ports/archs get out of sync. But I >> guess that might also have fallen out of favor with cross builds mostly >> working >> nowadays. >> >>> The issue I find is that upstream doesn't support some of our release >>> architectures, so when doing these backports, we lack a way to bootstrap the >>> new version on those architectures. See for example [1]. >> >> Yes. >> >>> One possibility would be to create the -stage0 tarballs using Debian >>> sid packages >>> for X-1. I haven't looked in detail, but perhaps we would need >>> statically linked >>> binaries, which could be done in an extra build and placed in a >>> rust-static .deb. >>> Then make_orig-stage0_tarball could look for those .debs from >>> snapshot.debian.org. >>> >>> Thoughts? >> >> I think for builds using those stage0 tarballs targeting stable we have three >> options: >> - build a static variant on every unstable upload >> - provide a script that cross-builds the missing stage0 targets (either >> using upstream build, or using an arch that has an upstream stage0 as >> starting point by doing a cross package build?) >> - use backports packages as stage0 input >> >> I think I'd favor the latter, since I already do the work for those ;) >> >> In recent history I think libgit2 was the only library pulled in that I had >> to backport as well (that was for Bookworm and for unofficial backports). >> It maybe would have been possible to avoid that by patching more >> aggressively. >> >> Of course, that would *only* help for Trixie, not Bookworm or older. If you >> need to support those, only the static or cross build variants would work at >> at the moment. > > Right, I was going to say that. We are backporting rustc to older releases as > well since we need it for firefox or clamav security updates. Those static > builds sound better, as then getting the stage0 tarball is probably just a > matter of running a script that downloads and packs some stuff. OTOH, that > wouldn't work for e.g. mips* or armel, which are no longer present in sid > (not > even in ports). The same situation could happen in the future, where we have > an > architecture in (old)stable which no longer exists in sid, and so for which > we > don't have the required build. Which brings us back to the cross-build option.
so I guess the most "robust" solution would be to do a combined approach: - the existing stage0 download where available - a script to drive cross-builds using whichever stage0 (upstream or packaging based or both?) - a script converting (backports/cross-built) packages to stage0 tarballs - allowing the stage0-tarball to contain either version N or N-1 the existing stage0 covers targets where upstream has tier2+host tools support the cross build script would allow filling gaps where upstream lacks support the package-to-stage0 conversion allows not relying on upstream at all allowing both N and N-1 just like for the regular build increases the chances of having *some* stage0 available technically it's possible to reduce the bootstrap chain with extra patches, but I am not sure we want to go down that route..
