On Thu, 25 Aug 2022 at 13:14:33 -0500, Gunnar Wolf wrote: > Simon McVittie dijo [Thu, Aug 25, 2022 at 11:19:30AM +0100]: > > Is armel a realistic candidate for being a Debian 12 release > > architecture? > > I do not feel armel systems are hard to come by, nor marginal in the > amount of users they have. Yes, running a GNOME desktop on them might > be a Very Bad Idea (if at all possible)... But they are very good > non-interactive purposes.
Your vote for retaining armel as a release architecture is noted (but that decision is not up to me - it's up to the release team, with input from the ARM porters who are responsible for doing the work to keep the port alive). If armel is a candidate for being a release architecture, then I think that leaves two-and-a-half options: 1. task-gnome-desktop is uninstallable on this architecture 1a. or Bastien's suggestion: task-gnome-desktop is installable on this architecture, but the preinst fails on baseline CPUs 2. task-gnome-desktop installs something that is not the full GNOME desktop on this architecture I would personally prefer 1., but last time I tried this (for s390x), it was blocked by the release machinery not allowing any task package to be uninstallable on any release architecture, even if the task doesn't really make sense there. So I am going to work towards 2., unless the release team tells me that 1. can be made to work. On Sat, 27 Aug 2022 at 15:41:44 +0000, Bastien Roucariès wrote: > adding support to armv6-support will help here I spoke to an ARM porter (Peter Green) at the weekend, and based on what he said, it would probably have to be armv7-support: if I'm understanding correctly, ARMv6 includes *some* atomic instructions, but they are not the ones that mozjs wants to invoke from inline assembler and its JIT, and are not really safe to use on ARMv7 CPUs. Are you suggesting that mozjs102 should add a Build-Depends and (Pre-?)Depends on armv7-support [armel], and override the compiler defaults on armel to build with something like -march=armv7? That doesn't seem very honest, or very efficient: we'd be compiling an ARMv7 binary as part of what is in theory our ARMv5 port, knowing that anyone who could successfully run it would be better served by installing libmozjs-102-0:armhf instead. For non-baseline i386 extensions (MMX, SSE, SSE2), isa-support has two justifications for existing: - there is a reasonably common class of CPU that is not supported by our next-higher-baseline port but would benefit from the non-baseline extension (CPUs from the Pentium II/III/IV era, which have SSE2 but are still only 32-bit, and cannot run amd64 binaries); - there are commonly-used proprietary binaries which cannot simply be recompiled for the next-higher-baseline ABI, and require libraries with the older ABI for their dependencies (Linux i386 binary-only games etc., and 32-bit Windows binary-only programs running under Wine) Neither of those justifications seems to me like it really applies to the boundary between armel and armhf, unless there is a widespread class of CPU that has all the mandatory ARMv7 instructions (including the atomic operations that mozjs wants), but lacks VFP hardfloat support. smcv