On Sat, Aug 15, 2026 at 03:43:24PM +0200, Stephen Kitt wrote: > Hi Adrian,
Hi Stephen, > On Sat, 15 Aug 2026 15:41:05 +0300, Adrian Bunk <[email protected]> wrote: > > On Sat, Aug 15, 2026 at 02:22:24PM +0200, Stephen Kitt wrote: > > > On Sat, 15 Aug 2026 13:20:20 +0300, Adrian Bunk <[email protected]> wrote: > > > > On Fri, Aug 14, 2026 at 09:23:58PM +0900, Simon Richter wrote: > > > > > The floating point results change, though, so the behaviour is > > > > > different from what the software was tested with, especially the > > > > > rounding behaviour is a lot more aggressive. > > > > >... > > > > > > > > you can compile software relying on the old behaviour with > > > > -mfpmath=387. > > > > > > The typical use-case here though is that you have an existing i386 binary, > > > which you can’t recompile, running with distribution-provided i386 > > > libraries (or a mixture of i386 libraries provided alongside the binary > > > and distribution-provided libraries), and it’s the behaviour of the > > > libraries that may have changed. > > > > this whole line of arguing comes across as asking to continue to do a > > lot of work with a mostly theoretical argument. > > My point is only that if we end up in a situation where i386 software people > care about (which, as you point out elsewhere, isn’t part of the > distribution) is broken, recompiling would most likely not be an option. > > If i386 ends up only being useful for running such software (which is not yet > the case), and that ends up broken, or untestable in any reasonable sense, I > would say that argues for dropping i386 entirely. >... wine32 is another major use case, and that might stay around forever. In practice we will have to revisit the i386 topic when 2038 comes closer, Debian 17 in 2033 is the last release where we can currently include i386. > Regards, > > Stephen cu Adrian
