Package: release-notes Followup-For: Bug #1033065 X-Debbugs-Cc: p...@debian.org, ballo...@debian.org
Dear Maintainer and Éric-Martin (with Bill on carbon copy), Please find linked below a previous release note from Debian 9.0 (stretch) that we could use to provide relevant user guidance: https://www.debian.org/releases/stretch/i386/release-notes/ch-information.html#i386-is-now-almost-i686 (I discovered this while reading a 2019 mailing list discussion[1]) On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote: > Broadly speaking, detecting non-baseline instruction usage isn't > possible without false positives, because the program could use runtime > instruction selection based on the current CPU to avoid currently > unavailable instructions, while the binary would still contain those > instructions for use on other CPUs. > > https://wiki.debian.org/InstructionSelection > > Of course you could do the scanning and then use autopkgtests or manual > tests to find out if the found programs work on the relevant CPUs. Thank you, that makes sense. I've run some ad-hoc script analysis[2] on a recent mirror of the bookworm i386 archive, and it appears that ~20% or so of packages are potentially affected in that (so, in all likelihood, Debian is currently uninstallable and/or unusable on Geode LX). In theory I would like to run a comparative analysis against the snapshot archives from previous points in time, but am not sure whether I'll get around to doing that. On Mon, 20 Mar 2023 13:31:37 +0800, pabs wrote: > Perhaps lintian could add classification tags for the relevant CPU > instructions and then the i386 port could have extra autopkgtest nodes > that only process the packages detected by lintian. That's not a bad idea. Are there any reasons that that might _not_ be a good idea before filing a wishlist bug? (performance, implications of scanning binary packages, ...) [1] - https://lists.debian.org/debian-user/2019/04/msg01091.html [2] - https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1005863#48
