On Sun, Jan 04, 2026 at 06:59:12AM +0100, Marc Haber wrote:
Of course, people now demand that fix in Trixie as well (see #1004894). I expected this to happen. People are never satisfied with what they get. What does the ctte think about that?
My 2c here is that that bug self-resolved to a sensible place. I agree with zeha's read on-thread.
Just to put it out there -- If someone can find a system which is: 1. An amd64 processor that meets our ISA baseline 2. Running a clean trixie amd64 install (not a i386 franken-install) 3. Which produces an invalid opcode error when running sudo:i386I'd be interested in learning more about that CPU and what may be going on with the host. I do not believe this happens on systems that meet our baseline for trixie. I would be interested in being proven wrong.
That being said:I suspect our calculus (this compiler flag change as discussed is a security noop in the way we talked about) still applies to trixie. This flag change seems to be to be "fine" to backport to trixie, technically.
*HOWEVER*, I'd be interested in use-cases for why people would install sudo:i386 within trixie amd64 or later at all, and rational on why we even ship it for a port that's no longer bootable.
My personal instinct as a package maintainer would be to RM sudo [i386],although, perhaps I don't understand something important. I'd be interested in learning what that misunderstanding is.
paultag -- ⢀⣴⠾⠻⢶⣦⠀ Paul Tagliamonte <paultag> ⣾⠁⢠⠒⠀⣿⡁ https://people.debian.org/~paultag | https://pault.ag/ ⢿⡄⠘⠷⠚⠋ Debian, the universal operating system. ⠈⠳⣄⠀⠀ 4096R / FEF2 EB20 16E6 A856 B98C E820 2DCD 6B5D E858 ADF3
signature.asc
Description: PGP signature
