On Mon, Nov 29, 2021 at 07:54:15PM +0200, Adrian Bunk wrote: > On Mon, Nov 29, 2021 at 05:32:30PM +0100, Julien Cristau wrote: > > > > 2 things: > > - I think we should pick 1.53 if possible, since that's what mozilla use > > for their esr91 binaries > > I was suggesting 1.51 since the smaller the difference to the currently > used version, the lower the risk of new bad surprises when updating > rustc. > > Roberto is doing this primarily for LTS, and for stretch LTS next years > Firefox that will require yet another rustc update will no longer be an > issue. > > The Debian packages of rustc 1.53 in experimental and unstable were > built with LLVM 12, we won't see before it enters stable-pu whether > building rustc 1.53 with LLVM 11 breaks on some architecture (unlikely > but not impossible, especially with the error thresholds). > I concur with Adrian's assessment here.
> > - I don't think we need to rename the packages unless there's evidence > > of breakage that can't be easily fixed by either simple patches or > > removing the affected packages. Renamed packages are acceptable but > > that seems like extra work and overhead that may not be necessary. > > We have already learned the hard way that such evidence might appears > after it is too late. > > In bullseye there are > 800 non-Firefox packages build depending on rustc. > > In buster there are "only" around 450 packages build depending on rustc. > One of them is librsvg, which failed to build with last years new rustc > for Firefox. > > The librsvg updated for rustc 1.41 updated for last years Firefox ESR > did build on amd64 but not on ppc64el. > > And BTW, this rustc/firefox misery also blocks the CVE-2019-20446 fix in > librsvg from entering buster. > > Assuming ppc64el will continue to not be part of LTS also for buster, > the easiest solution will be to re-upload the fixed librsvg to > buster-security immediately after LTS starts for buster. > > For rustc 1.41 in buster this is exactly the evidence you are asking for. > And it could not have reasonably be discovered before uploading rustc. > > The lesson learned is that the normal rustc package can no longer be > updated in stable series now that Firefox is no longer the sole user. > I concur with this as well. If there are no objections, I will proceed with uploading within the next 24 hours. I'd like to ensure that the new FF/TB make it into the next point release if at all possible and that work is currently blocked by the need for the updated rustc. Regards, -Roberto -- Roberto C. Sánchez
