Hello,
Sorry for taking this long to respond, I've had quite some stuff
to catch up on, after I was ill for 1 1/2 weeks.
On 20.05.24 02:56, Luca Boccassi wrote:
On Sun, 19 May 2024 at 23:30, Thomas Goirand wrote:
On 5/19/24 17:30, r...@neoquasar.org wrote:
I have an N270 system I can use to contribute, if someone is willing to
explain what I need to do to make it useful.
Hi,
If you allow me ... I was expecting someone else to write it before me,
but seeing nobody does, let me try.
... The issue isn't only about how many contributors, or how much effort
they put into it, but how much *everyone* in the project wants to spend
time on i386 support.
For example, *I* don't care at all about 32 bits arch, and would prefer
if these were to be sent to ports.debian.org. I really mean *all* 32
bits arch, including armhf for example.
Indeed, it's annoying each time when:
- I have to pin Arch: in debian/tests/control for example, only because
some packages have dropped 32 bits support (hint: sometimes, because
some of them also maintained by myself as well, like OpenVSwitch, for
example).
- I have to care for failed build (often because of unit tests) in i386
of packages I know wont mater for these arch.
And this is only 2 examples. This is a considerable loss of my (limited)
contributor time.
If 32 bits support was removed from Debian, this would make my (Debian)
life easier, while I have zero use of 32 bits. If I had to setup Linux
on a pi-zero, I probably would choose a more embedded distro than Debian
anyways, and that's what I would recommend to anyone. Anyone running
Debian on a non-amd64 capable laptop, at this time, should stop
procrastinate, and get decent hardware (as mentioned earlier in this
thread, cheap 2nd hands amd64 laptops are *very* cheap).
Because I know others care, I continue to make the effort when possible.
But these others should remember that's annoying me, and should weight
the collective cost, because I might not be the only one... and everyone
slightly involved in maintaining Debian might have, at some point, loss
some time on 32 bits support.
So this is a collective decision we should make: is 32 bits still
relevant enough for spending (wasting?) our collective (limited) time on
it? I'd vote no ... Especially considering i386 can become an unofficial
port for those who care. Even if I will respect our community decision
until the majority agrees, and will continue to do my best with i386
support until then, it has to happen one day. The only question is how
long. Can Trixie be the last release with 32 bits support?
On top of all these (very much agreeable) considerations, full i386
support is not just about "I have some hardware around to boot
images". We need porters who can triage, debug and fix complex
toolchain issues.
For example, we have a report that on some actual 32bit CPU
(unreproducible on anything else), due to the default compiler
optimizations some versions of gcc generate seemingly broken code when
building systemd, which causes memory corruption and an assertion to
be raised when a data structure is corrupted, which happens on
daemon-reload: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645
Nobody has been able to reproduce this on modern CPUs, so nobody has
put any time toward fixing this. The upstream bug report (closed due
to long inactivity) has more details, including decoded backtraces,
but it's not enough, someone needs to look at the generated code and
how it runs on said old 32bit CPUs, because for the same build the
issue doesn't happen in VMs, nor on modern CPUs running 32bit kernels.
These are the kind of issues that require work, that just isn't happening.
So, can any of the people who are saying they want to work on keeping
i386 alive as a fully bootable architecture step up and fix this
issue? If bugs like these don't get proper fixes (no, workarounds like
disabling compiler optimizations are not acceptable), then I don't see
what kind of future as a fully bootable architecture i386 can have. It
should of course continue as a toolchain plus libraries, so that
legacy programs can run on amd64. But if a fix for that bug doesn't
show up, after the installer and the kernel have dropped i386 builds,
I will most likely drop i386 from systemd too (aside from the
libraries ofc).
I've tried reproducing the daemon-reload bug report, unless I missed
something
obvious, daemon-reload works on my T2300, the TM Efficeon, and the pre-SSE2
Pentium 3 (mobile) that I have. I could try running it on an original
Pentium, but
I doubt that debian will run on it at all, even when ignoring the fact
that the thing
also only has 96M of ram, which is to small to load a ramdisk and debian
only targets
i686. So the bug might only apply to a very specific processor, unless
there is a patch
in the debian package.
regards,
Maite Gamper
