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
