Hi Hector,

On Thu, 2024-08-01 at 07:55 +0200, Hector Oron wrote:

Upstream projects, ARM companies which I was able to check with, do
not care that much about maintaining old code for ARMv5t chipsets,
therefore supporting it is more and more costly resource wise (not
only in Debian).

Timely to the writing of this email, Arnd Bergmann posted the
following timeline to deprecate ARM (armel) architecture, you can read
at:
- https://lwn.net/ml/all/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/

Should Debian drop armel from the upcoming Debian release?

While I understand the reasoning behind it, also having read Arnd's mail, I don't
understand why these decisions rarely consider the environment and sustainability
when talking about removing support for a given hardware.

ARM5vT/armel devices are still widely used for various embedded and low-energy applications where compute power doesn't matter but just reliability and energy consumption.

Dropping support for these devices will mean that a lot of hardware will eventually
be thrown away which otherwise could still have been fulfilled their purpose without
any problems.

It's certainly not easy to determine the actual usage statistics, but as long as there
is a considerable user base, I think dropping support for hardware because it's old
doesn't sound right to me.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Thu, Aug 1, 2024, at 07:55, Hector Oron wrote:

[ {debian-kernel,debian-boot,debian-release}@d.o are in Bcc so they
can track follow up emails at debian-arm ML if interested. ]

Dear fellow developers,

Debian Installer no longer produces daily builds for this platform:
- https://d-i.debian.org/daily-images/armel/

Debian Linux kernel packages are only building support for Raspberry
Pi Zero, Zero W and 1:
- https://salsa.debian.org/kernel-team/linux/-/blob/master/debian/config/armel/defines.toml
while many other platforms have been dropped.

Upstream projects, ARM companies which I was able to check with, do
not care that much about maintaining old code for ARMv5t chipsets,
therefore supporting it is more and more costly resource wise (not
only in Debian).

Timely to the writing of this email, Arnd Bergmann posted the
following timeline to deprecate ARM (armel) architecture, you can read
at:
- https://lwn.net/ml/all/2831c5a6-cfbf-4fe0-b51c-0396e5b0aeb7@app.fastmail.com/

To clarify the scope of my proposal, as that may be easy to
misunderstand: There is no current plan to drop kernel support
for any of the hundreds of ARMv5 machines that use devicetree,
or remove features that armel depends on.

The only ARMv5/v6 machines that are up for debate at this
point are the Nokia N800/N810 tablet because of its unusual
CPU (ARM1136r0), and a the few PXA2xx and Orion5x machine
that were never converted to DT. If there are actual users,
we'll try to keep them and change them to DT.

The timing I suggested for dropping the non-DT orion5x
machines in 6.13 is intended to still allow the debianonbuffalo
project to support all NAS boxes with a kernel using the
Trixie kernel source package with a custom config. Most
of the ARMv5 machines they support do use DT and will
keep working in future releases.

Should Debian drop armel from the upcoming Debian release?

This is of course a valid question to ask regardless.

It's clear that armel is used much less than armhf, but
I think it's also still more widely used than any of the
inofficial ports, so the question is when it hits that
threshold of not being worth maintainer time.

Most of the current users are probably fine with armel
being moved from a release architecture to ports, but from
a user perspective I also think it would be nice to do
that after Trixie is out, so that there is at least one
official release with time64 library support.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On 2024-08-01 10:31, Arnd Bergmann wrote:

Most of the current users are probably fine with armel
being moved from a release architecture to ports, but from
a user perspective I also think it would be nice to do
that after Trixie is out, so that there is at least one
official release with time64 library support.

Good point!

Also, for armel to stay alive longer, we might like to remove some huge applications from its small shoulders. (I believe, e.g. libreoffice is
still available for armel and I wonder, how useful that is.)

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hello Adrian,

On Thu, 1 Aug 2024 at 09:39, John Paul Adrian Glaubitz <glaubitz@physik.fu-berlin.de> wrote:

Should Debian drop armel from the upcoming Debian release?

While I understand the reasoning behind it, also having read Arnd's mail, I don't
understand why these decisions rarely consider the environment and sustainability
when talking about removing support for a given hardware.

ARM5vT/armel devices are still widely used for various embedded and low-energy
applications where compute power doesn't matter but just reliability and energy
consumption.

Dropping support for these devices will mean that a lot of hardware will eventually
be thrown away which otherwise could still have been fulfilled their purpose without
any problems.

It's certainly not easy to determine the actual usage statistics, but as long as there
is a considerable user base, I think dropping support for hardware because it's old
doesn't sound right to me.

The main reasoning for dropping the port are the problems listed at:
- https://release.debian.org/testing/arch_qualify.html

On the other hand, I find your arguments and Arnd's one about keeping
an official release with time64 library support very useful to keep
port alive one more release.

Note that dropping from stable does not mean we fully drop the port,
it can be kept as non-release architecture, then it would not block
security updates like the ones we had with linux kernel build
failures.

And for old devices (which I also still have) you can always find
unsupported releases at archive.debian.org, maybe we could have an
unofficial kernel package for those devices.

Regards,
--
Héctor Orón -.. . -... .. .- -. -.. . ...- . .-.. --- .--. . .-.

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

Hi Hector,

On Tue, 2024-08-06 at 13:03 +0200, Hector Oron wrote:

It's certainly not easy to determine the actual usage statistics, but as long as there
is a considerable user base, I think dropping support for hardware because it's old
doesn't sound right to me.

The main reasoning for dropping the port are the problems listed at:
- https://release.debian.org/testing/arch_qualify.html

OK, so the main issue here seems to be the aging hardware of the buildds.

From what I remember from my discussions with Alex Graf (former colleague

at SUSE), there are some ARM64 systems which support 32-bit ARM binaries without limitations.

Has that changed in the mean time?

On the other hand, I find your arguments and Arnd's one about keeping
an official release with time64 library support very useful to keep
port alive one more release.

Yeah, it would be strange if we dropped armel now after we've gone through
all the efforts to switch the port to time64_t ;-).

Note that dropping from stable does not mean we fully drop the port,
it can be kept as non-release architecture, then it would not block
security updates like the ones we had with linux kernel build
failures.

Sure, I'm aware of that. The problem is just that the infrastructure we have
at Debian Ports is quite inferior to what we have for release architectures
(no support for cruft, no Britney, no Ben etc), so moving an architecture
to Ports doesn't just mean you lose support for a stable release but also
quite a lot of stuff that is makes maintaining an architecture in Debian much easier.

I have been a proponent of a Tier system within Debian similar to what NetBSD has:

https://www.netbsd.org/ports/#tiers

But so far there has been little to no feedback to this idea. If we introduced tiers,
we could easily downgrade architectures like armel to a less well supported tier without
all the disadvantages that moving it to Debian Ports has.

And for old devices (which I also still have) you can always find
unsupported releases at archive.debian.org, maybe we could have an
unofficial kernel package for those devices.

Sure, that was never the question.

Adrian

--
.''`. John Paul Adrian Glaubitz
: :' : Debian Developer
`. `' Physicist
`- GPG: 62FF 8A75 84E0 2956 9546 0006 7426 3B37 F5B5 F913

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 6, 2024, at 13:54, John Paul Adrian Glaubitz wrote:

On Tue, 2024-08-06 at 13:03 +0200, Hector Oron wrote:

It's certainly not easy to determine the actual usage statistics, but as long as there
is a considerable user base, I think dropping support for hardware because it's old
doesn't sound right to me.

The main reasoning for dropping the port are the problems listed at:
- https://release.debian.org/testing/arch_qualify.html

OK, so the main issue here seems to be the aging hardware of the buildds.

From what I remember from my discussions with Alex Graf (former colleague

at SUSE), there are some ARM64 systems which support 32-bit ARM binaries without limitations.

Has that changed in the mean time?

I believe the builds are all done on arm64 hardware, and the table
lists the same issue for available hardware on armel, armhf and arm64.

There are a few instructions that armel binaries can use that
are missing on armv8 hardware (cp15 barriers, swp/swpb atomics),
and a few differences in how the kernel treats unaligned memory
access and personality. Emulation for these is a bit tricky to
set up correctly for individual developers, but but the
build servers should generall just work.

Most of issues with armel packages are about libatomic link
time requirements, and about applications that hardcode armv7
or vfp instruction extensions.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)

On Tue, Aug 6, 2024, at 16:27, John Paul Adrian Glaubitz wrote:

On Tue, 2024-08-06 at 16:21 +0200, Arnd Bergmann wrote:

Most of issues with armel packages are about libatomic link
time requirements, and about applications that hardcode armv7
or vfp instruction extensions.

Code that hardwires CPU baselines is considered RC-buggy anyway, so
that shouldn't be an argument. And that notoric libatomic issue is
just something that should be finally fixed in GCC upstream (unless
I am missing something why that can't be done).

Right, in principle none of this is specific to armel, but
I think this one gets noticed more than the others:

- upstream projects are likely to hardwire armv7 assembly for
arm32 than hitting the same problem on other architectures
since most people don't understand the exact cpu specific
requirements, and armv7 is what everyone has.

- for libatomic, I think it's the only remaining official
port that is affected (not sure about mips64el), while a
number of the inofficial ones likely have the same issue
(parisc, sparc, ...).

If none of the official release architectures had
the libatomic issue, it would make life a little easier
for their maintainers, but it makes maintaining the
non-release architectures harder because then fewer
people care.

I don't know if a gcc change can address all of the
libatomic issues, but that would of course be best.

Arnd

--- SoupGate-Win32 v1.05
* Origin: fsxNet Usenet Gateway (21:1/5)