Is there a reason to do this? If so, what would be required to keep the i386 version, seeing as it still is important and used?
Is there a reason to do this? If so, what would be required to keep
the i386 version, seeing as it still is important and used?
That depends. What would be required of such a person? I also have
several i386-class machines that run Debian (though only one that can
run Debian 12).
--J
Sent from my mobile device. ------------------------------------------------------------------------ *From:* Johannes Schauer Marin Rodrigues <josch@debian.org>
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support
Quoting Victor Gamper (2024-05-17 21:58:58)
Is there a reason to do this? If so, what would be required to keepthe i386
version, seeing as it still is important and used?
anything can be done if there are enough contributors who care.
For i386 there is a severe lack of person-power. Do you want to start contributing your free-time for several years to come to d-i and other
areas
which are needed to keep i386 more alive for longer?
Thanks!
cheers, josch
On Sat, 2024-05-18 at 10:28 +0000, Andrew M.A. Cater wrote:
On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote:[...]
Hello everyone,The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware >> at this point.
Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?
If so, I'd like to ask to reconsider this seeing as there is still a
plethora of i386 machines and i386 is as of now still the
second most used architecture according to popcon with 8437
reports there, if I understand correctly.
I personally use the i386 version on multiple machines,
including a ThinkPad T60 (on which I'm writing this on) and a
Transmeta Efficeon, which I'm using as a router and access point.
The T60 will do amd64.
According to thinkwiki, the T60 had CPU options of Core Solo/Duo (32-
bit) and Core 2 Duo (64-bit) CPUs, so this may or may not be correct.
Ben.
I believe I could swap out the processor on my T60,
however, I'd both need to have that processor and
make sure that it is actually possible. It still would
not really make sense on a platform that only supports
3G of physical RAM.
Anyways, if the only reason why i386 cd images are not
supported anymore is the lack of contributors,
I'd be willing to contribute in that area, if it's possible.
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?
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.Â
From: Victor Gamper <victor@wenzeslaus.de>
Sent: Sunday, May 19, 2024 08:03
To: debian-devel@lists.debian.org
Subject: Re: About i386 support
I believe I could swap out the processor on my T60,
however, I'd both need to have that processor and
make sure that it is actually possible. It still would
not really make sense on a platform that only supports
3G of physical RAM.
Anyways, if the only reason why i386 cd images are not
supported anymore is the lack of contributors,
I'd be willing to contribute in that area, if it's possible.
There is no "end of support for 32 bits" yet so no.which is good news. The end of support for 32 bits will not
affect the lives of almost anyone who has machines purchased after
2011 and who bought them after that
Does this also mean he support for armhf will be dropped ?
Hello everyone,
Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?
If so, I'd like to ask to reconsider this seeing as there is still a
plethora of i386 machines and i386 is as of now still the
second most used architecture according to popcon with 8437
reports there, if I understand correctly.
I personally use the i386 version on multiple machines,
including a ThinkPad T60 (on which I'm writing this on) and a
Transmeta Efficeon, which I'm using as a router and access point.
I personally don't understand why you'd want to deprecate i386,
especially if you compare it to other official architectures
(s390, ppc64el and armel have way less reports on popcon. I don't
want to suggest to deprecate any of these architectures, but just
compare the amount of users there). For many tasks an i386
machine still offers more than enough capabilities and deprecating
i386 now would brick many otherwise completely functional machines.
Just not shipping an i386 iso would still be deprecating an architecture,
as many people don't have the knowledge and/or patience to set up
debian over debootstrap which would again practically brick i386 machines
for many users. Also, deprecating i386 would probably make it
difficult or downright impossible for downstream distributions to
themself keep the i386 version maintained,
as they'd have to invest much more effort to keep i386.
Is there a reason to do this? If so, what would be required to keep
the i386 version, seeing as it still is important and used?
regards,
Maite Gamper (zeldakatze)
No, please don't, this confuses people.which is good news. The end of support for 32 bits will not
affect the lives of almost anyone who has machines purchased after
2011 and who bought them after that
When you refer to 32 bits you are referring to i386 (see the subject),Does this also mean he support for armhf will be dropped ?There is no "end of support for 32 bits" yet so no.
*From:* Johannes Schauer Marin Rodrigues <josch@debian.org>
*Sent:* Friday, May 17, 2024 15:48
*To:* Victor Gamper; debian-devel@lists.debian.org
*Subject:* Re: About i386 support
Quoting Victor Gamper (2024-05-17 21:58:58)
Is there a reason to do this? If so, what would be required to keepthe i386
version, seeing as it still is important and used?
anything can be done if there are enough contributors who care.
For i386 there is a severe lack of person-power. Do you want to start
contributing your free-time for several years to come to d-i and other
areas
which are needed to keep i386 more alive for longer?
On 18.05.24 03:15, rhys@neoquasar.org wrote:
That depends. What would be required of such a person? I also have
several i386-class machines that run Debian (though only one that can
run Debian 12).
Whilst I can't for sure say how much free time I'll have, I'd like
to try and contribute. How would you get started with that?
Quoting Victor Gamper (2024-05-17 21:58:58)
For i386 there is a severe lack of person-power. Do you want to start contributing your free-time for several years to come to d-i and
other areas
which are needed to keep i386 more alive for longer?
On 18.05.24 03:15, rhys@neoquasar.org wrote:
That depends. What would be required of such a person? I also have
several i386-class machines that run Debian (though only one that can
run Debian 12).
On 18.05.24 15:16, Maite Gamper wrote:
Whilst I can't for sure say how much free time I'll have, I'd like
to try and contribute. How would you get started with that?
There's somewhere a page that is showing how much of the archive is built by architecture. A search engine should help you finding that page. Pick the package that is furthest down the stack of package dependencies that is not building on i386.
Find out why. Fix the bug. Check if there's a bug report
about the problem. Send a patch. If the maintainer doesn't have time then become a Debian Maintainer [or] Developer yourself, consult with the package's maintainers and upload fixed packages.
Pretty much every major Linux distribution is dropping _any_ 32 bit: Debian is trying to support 32 bit on armhf, for example, which is more than
Ubuntu and Fedora.
On Sun, 19 May 2024 at 23:30, Thomas Goirand <zigo@debian.org> wrote:
On 5/19/24 17:30, rhys@neoquasar.org wrote:On top of all these (very much agreeable) considerations, full i386
I have an N270 system I can use to contribute, if someone is willing toHi,
explain what I need to do to make it useful.
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?
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.
A bug that can't be reproduced, effectively doesn't exist.ÂWow.
Then it's not a problem in the first place. If you can't reproduce a bug with a reasonable effort, then it is unconfirmed and you can stop worrying about it. A bug that can't be reproduced, effectively doesn't exist.
That's not a reason to stop supporting an entire architecture. That's a troubleshooting decision that you would make on any architecture.
Then it's not a problem in the first place. If you can't reproduce a
bug with a reasonable effort, then it is unconfirmed and you can stop worrying about it. A bug that can't be reproduced, effectively doesn't
exist.
That's not a reason to stop supporting an entire architecture. That's
a troubleshooting decision that you would make on any architecture.
Sent from my mobile device.
------------------------------------------------------------------------ *From:* Luca Boccassi <bluca@debian.org>
*Sent:* Friday, June 14, 2024 04:39
*To:* debian-devel@lists.debian.org
*Subject:* Re: Re: About i386 support
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.
There are no relevant patches in the Debian package. This is exactly
the problem with supporting old and obsolete architectures, that are
very difficult to find in the wild: things break in weird and incomprehensible ways, and nobody is able to fix them. This is one of
the main jobs of porters: if you can't triage and fix this issue, then
it's likely you won't be able to triage and fix other architecture-
specific issues either, as this is very very likely a hidden compiler toolchain issue. The effort required to have a release architecture officially supported in Debian goes way beyond "I have an old machine
under the desk and can build some trivial packages", I am afraid.
--
Kind regards,
Luca Boccassi
Then it's not a problem in the first place. If you can't reproduce a bug
with a reasonable effort, then it is unconfirmed and you can stop
worrying about it.
On Jun 14, 2024, at 11:46, Russ Allbery <rra@debian.org> wrote:
rhys@neoquasar.org writes:
Then it's not a problem in the first place. If you can't reproduce a bug
with a reasonable effort, then it is unconfirmed and you can stop
worrying about it.
I think you're confusing two different types of reproduction.
Architecture porting bugs are often hardware-specific. The bug may be
100% reproducible on that instance of the architecture, an instance that
you do not own and do not have access to. So the package is reliably
broken for a user trying to use that architecture, and yet the porter has limited ability to triage or debug it because they don't have access to
that architecture.
This is one of the reasons why projects (not just Debian) drop support for architectures. Once the *maintainers* no longer have easy access to instances of that architecture, it's very hard to support, even if users
keep trying to use that architecture and run into problems that are reproducible for them.
That's the first hurdle. The second hurdle you then run into is that frequently the cause of these problems is deep inside the compiler, the kernel, or some other complex piece of upstream code. There are a very limited number of people who have the ability to track down and fix
problems like that, since they can require a lot of toolchain expertise.
It's not a simple thing to commit to doing.
Debian relies fairly heavily on a whole ecosystem of upstream developers
to do a lot of the difficult work for supporting architectures, including
the kernel, GCC, binutils, etc. If that ecosystem stops supporting architectures, it will be very difficult for Debian to keep support, and doing so usually requires the people interested in keeping those architectures working to also become upstream kernel, GCC, etc.
developers.
My response remains the same. If it only affects a small slice of
systems that already represent a small slice of systems, it becomes
untenably difficult to chase that one bug that affects that one
case.
But that does not translate into an excuse to drop all of the many
working legacy systems.
This argument gets used both ways by people who just want to abandon
"old stuff," regardless of the circumstances.
As someone who uses things until they fail, I find myself unmoved by
these excuses.
There is always a corner case that doesn't work. But my 32-bit
machines have been able to run Linux for as long as Linux has
existed. Even under the bookworm "Intel 686-only" rules, it still
works, so I still use it. It's built, it runs, it serves a purpose,
and it costs very little.
Dropping support for something that works based on some other much
less common thing that doesn't work sounds to me like an excuse, not
a logically valid reason.
| Sysop: | Keyop |
|---|---|
| Location: | Huddersfield, West Yorkshire, UK |
| Users: | 486 |
| Nodes: | 16 (2 / 14) |
| Uptime: | 147:18:37 |
| Calls: | 9,659 |
| Calls today: | 1 |
| Files: | 13,708 |
| Messages: | 6,168,025 |