[Pkg-rust-maintainers] Bug#1126584: Bug#1126584: Bug#1126584: rustc: build stage0 orig tarball from Debian builds

[Fabian Grünbichler]

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..