dear release team, I would appreciate some indication/answer which of the options below we will target for Trixie. I did a rebuild of all immediate rdeps of rustc with the baseline raised there (well, with the two patches lowering it dropped ;)).
out of the 3222 packages rebuilt, there were 82 build failures (either FTFBS in sid, or my rebuild env not having enough disk space). 3 of packages actually failed to build with the bumped baseline, but did build successfully in a recheck build with the stock rustc: rust-tint_1.0.1-2 (fails cause of test patched to workaround x87 floating behaviour, likely fixed by dropping that patch) rust-kuznyechik_0.8.2-1 (actually broken upstream, but looks fixable) fish_4.0.0-3 (a second build with the bumped rustc worked, so this seems like a flaky test breaking the build sometimes) my rebuild did not include testing the same change for LLVM itself, nor running autopkgtest which my guess is where most fallout would be if we were to do this for real. I still think it gives a rough idea of what to expect if we selectively bump the baseline. thanks smvc for the great summary of available options! On Thu, Feb 13, 2025, at 5:32 PM, Simon McVittie wrote: > The options as I see them, *including* the options that I would personally > prefer to rule out, are: > > - Status quo: don't change anything. As Fabian says, Rust code on i386 > will sometimes be miscompiled and might crash. I can live with this, provided we raise the baseline for forky (or drop i386 at least for Rust). it should probably be mentioned in the i386 release notes if we go down this route. > - Raise baseline to i686+SSE2+MMX and make gcc require/assume this given doko's objection above, this is likely not an actual option. > - Raise "official" baseline to i686+SSE2+MMX, leave gcc producing > code that would have worked with the previous baseline by default, > but rustc/LLVM may require/assume i686+SSE2+MMX I am willing to work through fallout during the freeze if we choose this option, and would prefer it to the ignore-for-trixie variant. > - Officially keep current baseline, intentionally violate the baseline in > rustc (and maybe LLVM?) so that rustc produces working code, and > have the release team announce that the resulting baseline violations > are not to be considered RC bugs same > - Do a transition to remove all Rust code from i386 this is probably more work and churn then the two partial-baseline-raising variants above, and probably makes more people unhappy > - Remove i386 completely, re-introduce the equivalent of ia32-libs so we > can still provide 32-bit Wine and Mesa > (I'm mentioning this for completeness but I suspect the release team > would veto this, because nobody liked ia32-libs) > > - Remove i386 completely, no more 32-bit Wine, no more ability to > install Steam, etc. I have no opinion on either of these as a rustc maintainer, but guess these would make even more people unhappy. thanks for your time reading this (and work on getting the Trixie ball rolling!) Fabian
