Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.devel > #112149

Re: About i386 support

Show all headers | View raw

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 <zigo@debian.org> wrote:
>> On 5/19/24 17:30, rhys@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

Back to linux.debian.devel | Previous | Next — Previous in thread | Next in thread | Find similar

Thread

Re: About i386 support Luca Boccassi <bluca@debian.org> - 2024-05-20 03:00 +0200
  Re: About i386 support Leandro Cunha <leandrocunha016@gmail.com> - 2024-05-20 03:50 +0200
  Re: About i386 support Victor Gamper <victor@wenzeslaus.de> - 2024-06-14 11:10 +0200
    Re: Re: About i386 support Luca Boccassi <bluca@debian.org> - 2024-06-14 11:40 +0200
      Re: Re: About i386 support Andrey Rakhmatullin <wrar@debian.org> - 2024-06-14 13:10 +0200
      Re: Re: About i386 support Luca Boccassi <bluca@debian.org> - 2024-06-14 13:30 +0200

csiph-web