Re: Suggestions about i386 support

[Simon McVittie]

On Mon, 10 Jun 2024 at 20:17:27 +0500, Andrey Rakhmatullin wrote:
> On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> > several important upstreams no longer consider i386 to be useful (and
> > especially i386-without-SSE2), so so the burden of supporting 32-bit
> > CPUs in modern software will fall on the downstream developers who have
> > chosen that their aim is to support 32-bit CPUs.
> 
> I assume such software already has this status on Debian i386 (and so is
> either not built there or supported only by the maintainer, or maybe built
> with a raised baseline) so there should be no regression here

Some concrete examples:

* Packages built with -fcf-protection (Intel CET) require CPU support
  for "long NOP" opcodes which are, or used to be, non-baseline.
  This is a security hardening measure, so if we disable it in order
  to respect the documented baseline, the result is that our binaries
  are less secure than they could be (fewer mitigations for exploits)
  on CPUs where those opcodes actually *are* supported. (That's what
  started this thread: sudo enables this hardening.)

* nodeJS, Qt5WebEngine and others have a known baseline violation by using
  and requiring SSE2 internally, which they document by depending on
  sse2-support. I thought Chromium did this too, but maybe it either
  doesn't do that any more, or still has the baseline violation but
  doesn't document it.

* Packages built with rustc (notably Firefox and librsvg) had a known
  baseline violation in the past (they would crash with an illegal
  instruction on i586) which was made officially not-a-bug by raising the
  baseline to i686.

* In packages with test suites that compare the results of floating-point
  calculations at a high precision (such as librsvg), the fact that we
  target the legacy i387 FPU (which has 80-bit excess precision) rather
  than SSE2 (which has 64-bit IEEE precision) has caused a lot of extra
  work for maintainers in the past, due to tests getting a result on i386
  that differs from the result on every other platform we support.

* Some third-party software like Steam does not follow our baselines,
  and unconditionally requires newer CPU features. (Not a concern for
  Steam on i386 any more, because Steam now requires a 64-bit CPU, so
  bookworm's steam-installer is intentionally not installable on purely
  32-bit systems - but Steam will not actually work on a baseline *64-bit*
  CPU any more.)

smcv

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Mon, Jun 10, 2024 at 04:02:54PM +0100, Simon McVittie wrote:
> On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> > The point here is that the Debian project is not intending to support
> > new hardware on the i386 architecture. The architecture is being kept
> > around primarily to support running old i386 binaries.
> 
> ... and the most appropriate answers to some technical questions are not
> going to be the same for "i386 to run legacy 32-bit binaries on 64-bit
> CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support
> both equally.

Yeah, it should be made clear that if some people want to bring back
proper support for i386 hardware, they will need to make a new port.
Which is of course more complicated than fixing an existing one (but at
least bootstrapping it should be easier than bootstrapping some non-x86
port).

> If people want a distribution to run on 32-bit x86 CPUs badly enough,
> one possible route would be to start a new port (perhaps called ia32,
> i386t64 or something similar) for that use-case; it would have a baseline
> that is as low as its maintainers want it to be (i586?), and a 64-bit
> time_t for post-2038 future-proofing.
> 
> As far as I'm aware, nobody is yet putting effort into doing this. Also,
> several important upstreams no longer consider i386 to be useful (and
> especially i386-without-SSE2), so so the burden of supporting 32-bit
> CPUs in modern software will fall on the downstream developers who have
> chosen that their aim is to support 32-bit CPUs.

I assume such software already has this status on Debian i386 (and so is
either not built there or supported only by the maintainer, or maybe built
with a raised baseline) so there should be no regression here, though
additional packages will get the same status in the future.
Similarly, we already don't build a noticeable number of packages on armel
(and some of them also on armhf) when we build them on arm64.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[Simon McVittie]

On Mon, 10 Jun 2024 at 12:43:27 +, Stefano Rivera wrote:
> The point here is that the Debian project is not intending to support
> new hardware on the i386 architecture. The architecture is being kept
> around primarily to support running old i386 binaries.

... and the most appropriate answers to some technical questions are not
going to be the same for "i386 to run legacy 32-bit binaries on 64-bit
CPUs" and "i386 to run on 32-bit CPUs", so we cannot simply support
both equally.

> We didn't bring 64bit time_t to the architecture, because of this goal.

This is a good example of a decision that goes differently for those two
purposes. If we want to run legacy i386 binaries, 64-bit time_t would
be counterproductive, because it will break some of those binaries *now*
(not just in 2038).

Raising the baseline (to i686 or beyond) is another decision that would
go differently for those two purposes. For legacy i386 binaries on an
x86_64 CPU, the baseline could raise as far as i686 + SSE + SSE2 without
losing any 64-bit CPU support, because SSE and SSE2 are part of the
x86_64 baseline; but for genuinely 32-bit CPUs, as discussed in this
thread and elsewhere, even i686 is sometimes too high.

> There isn't a team working on a modern 32 bit x86 port. We're just
> trying to keep the old one going for as long as we can. You're welcome
> to try to form such a team, of course :)

The "i386" name is widely hard-coded in third-party software (e.g. Steam)
as being the appropriate architecture to use to run legacy 32-bit
binaries on a 64-bit CPU, so if we were to fork i386 into two separate
ports (one for legacy binaries on 64-bit CPUs, and one for 32-bit CPUs),
the route that would avoid breaking backwards-compatibility would be for
the i386 name to stay with the port that is intended for legacy binaries,
introducing a new name for the port that is intended for 32-bit CPUs.

(This is because by definition legacy binaries are legacy, and are not
going to change to accommodate new decisions, whereas a new port can
produce new binaries with code changes if enough effort is put into
doing so.)

If people want a distribution to run on 32-bit x86 CPUs badly enough,
one possible route would be to start a new port (perhaps called ia32,
i386t64 or something similar) for that use-case; it would have a baseline
that is as low as its maintainers want it to be (i586?), and a 64-bit
time_t for post-2038 future-proofing.

As far as I'm aware, nobody is yet putting effort into doing this. Also,
several important upstreams no longer consider i386 to be useful (and
especially i386-without-SSE2), so so the burden of supporting 32-bit
CPUs in modern software will fall on the downstream developers who have
chosen that their aim is to support 32-bit CPUs.

And, for several larger packages it is becoming a serious problem
to compile and link the software natively on any 32-bit architecture,
because the working set for the compiler or linker is larger than 4 GiB,
but a 32-bit architecture can't possibly address more than 4 GiB of
virtual memory at a time.

Those are problems that any would-be port maintainer for a "modern"
32-bit x86 port would have to deal with somehow, and telling the wider
Debian project "this is important to me, therefore it should be important
to you" is unlikely to result in those problems going away.

Alternatively...

> The cost of supporting a port of Debian is far more than the cost of the
> machines needed to build it. Never mind the cost of 1 user's machine.

As a point of comparison, a used 64-bit laptop of a well-respected
design from 12-13 years ago (Lenovo X220) seems to be readily available
for around £60 on eBay UK, and that price is enough to pay a software
consultant in the UK for somewhere around 1 hour. Of course, volunteer
effort is not directly interchangeable with consultant effort and not
every country is the UK, but the time-cost of maintaining a 32-bit port
of Debian is going to be lots of hours.

I suspect that many of the used 64-bit laptops of that age on eBay
go unsold and will instead be discarded, entering the e-waste stream,
in which case buying one as a replacement for a 32-bit machine is not
a net increase in e-waste.

(No endorsement of eBay intended, other sources of refurbished computers
are available.)

smcv

Re: Suggestions about i386 support

[Stefano Rivera]

Hi The (2024.06.10_12:22:14_+)
> How to get access to the right parts of the waste stream to be able to
> pull out some working 64-bit hardware is another question, and one where
> I don't have an answer that wouldn't involve spending money (which would
> presumably make the proposed alternative insufficiently comparable,
> since presumably you wouldn't have to spend money to keep the existing
> 32-bit machine in service). If Andrey does, I'd be interested to learn
> it.

The point here is that the Debian project is not intending to support
new hardware on the i386 architecture. The architecture is being kept
around primarily to support running old i386 binaries.

We didn't bring 64bit time_t to the architecture, because of this goal.

There isn't a team working on a modern 32 bit x86 port. We're just
trying to keep the old one going for as long as we can. You're welcome
to try to form such a team, of course :)

The cost of supporting a port of Debian is far more than the cost of the
machines needed to build it. Never mind the cost of 1 user's machine.

Stefano

-- 
Stefano Rivera
  http://tumbleweed.org.za/

Re: Suggestions about i386 support

[The Wanderer]

On 2024-06-10 at 08:09, rhys wrote:

> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin 
> wrote:
> 
>> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org
>> wrote:

>>> Reuse is better than recycle for complex things like electronics.
>>> 
>> You were suggested to resuse an old amd64 machine.
> 
> Again, that assumes that I have such a thing.  I don't.  Unless you
> want to provide one?
> 
> Also, that still doesn't explain how that means the existing 32-bit
> machine stays out of the waste stream.  In your solution, it doesn't.
> In my solution, it does.

I think the suggestion was to take an old amd64 machine out of the waste
stream, and put the existing 32-bit machine into the waste stream, so
that the total amount in the waste stream remains the same but you no
longer need software support for the 32-bit machine.

How to get access to the right parts of the waste stream to be able to
pull out some working 64-bit hardware is another question, and one where
I don't have an answer that wouldn't involve spending money (which would
presumably make the proposed alternative insufficiently comparable,
since presumably you wouldn't have to spend money to keep the existing
32-bit machine in service). If Andrey does, I'd be interested to learn
it.

-- 
   The Wanderer

The reasonable man adapts himself to the world; the unreasonable one
persists in trying to adapt the world to himself. Therefore all
progress depends on the unreasonable man. -- George Bernard Shaw



signature.asc
Description: OpenPGP digital signature

Re: Suggestions about i386 support

[rhys]

> On Jun 10, 2024, at 01:44, Andrey Rakhmatullin  wrote:
> 
> On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
 It's not just a matter of "buy something better." That's easy. 
>> 
>>> Indeed, that is easier and cheaper.
>> 
>> Of course, continuing to use a system I already have is cheaper still.
>> 
>>> What's not easy is that a) that adds another machine to the waste 
>>> stream, instead of continuing to get use from it, and b) someone has 
>>> to take the time to set up the new machine, test things, migrate 
>>> services, etc. to functionally replace the old one. That takes time 
>>> and effort, too, multiplied by the number of such systems out there. 
>> 
>>> (a) is false as newer hardware can already be taken from electronic waste, 
>>> so it does not add new waste.
>> 
>> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair 
>> amount of material still goes to waste, and there are all kinds of costs 
>> associated with those processes. 
>> 
>> Reuse is better than recycle for complex things like electronics. 
> You were suggested to resuse an old amd64 machine.

Again, that assumes that I have such a thing.  I don't.  Unless you want to 
provide one?

Also, that still doesn't explain how that means the existing 32-bit machine 
stays out of the waste stream.  In your solution, it doesn't.  In my solution, 
it does.

--J

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, Jun 09, 2024 at 08:39:27PM -0500, r...@neoquasar.org wrote:
> >> It's not just a matter of "buy something better." That's easy.  
> 
> >Indeed, that is easier and cheaper.
> 
> Of course, continuing to use a system I already have is cheaper still.
> 
> > What's not easy is that a) that adds another machine to the waste 
> > stream, instead of continuing to get use from it, and b) someone has 
> > to take the time to set up the new machine, test things, migrate 
> > services, etc. to functionally replace the old one. That takes time 
> > and effort, too, multiplied by the number of such systems out there.  
> 
> > (a) is false as newer hardware can already be taken from electronic waste, 
> > so it does not add new waste.
> 
> That is a gross overstatement. Electronics are NOT 100% recyclable. A fair 
> amount of material still goes to waste, and there are all kinds of costs 
> associated with those processes. 
> 
> Reuse is better than recycle for complex things like electronics. 
You were suggested to resuse an old amd64 machine.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Suggestions about i386 support

[rhys]

>> It's not just a matter of "buy something better." That's easy.  

>Indeed, that is easier and cheaper.

Of course, continuing to use a system I already have is cheaper still.

> What's not easy is that a) that adds another machine to the waste 
> stream, instead of continuing to get use from it, and b) someone has 
> to take the time to set up the new machine, test things, migrate 
> services, etc. to functionally replace the old one. That takes time 
> and effort, too, multiplied by the number of such systems out there.  

> (a) is false as newer hardware can already be taken from electronic waste, so 
> it does not add new waste.

That is a gross overstatement. Electronics are NOT 100% recyclable. A fair 
amount of material still goes to waste, and there are all kinds of costs 
associated with those processes. 

Reuse is better than recycle for complex things like electronics. 

>(Also electricity isn't free everywhere.)

Of course. 

> Maintaining support for ancient hardware costs too. And is more expensive per 
> device as the number of systems is lower.

This will always be true if more than one architecture is supported. One will 
be more expensive (in labor) than the other. 

> [support assistance suggestions]

I will keep this (and a couple others) that have listed specific suggestions 
and work on them as I have time. The idea of fundraising is an interesting one. 

> Which leads to the problem: most people who want this, seem to want to 
> continue to use old hardware (T60, N270). However, continuing to support i386 
> has likely costs much higher than the replacement cost of 
said hardware... Which is probably why nobody really seems sufficiently 
motivated to actually invest resources. (Or do you?)

Except that the "replacement cost" is not tied in any way to the "development 
cost" in a practical sense. There is no way to move resources from anywhere 
that I can use for "replacement cost." I'm on my own. 

That's true for development, too, of course. But you make it sound like there 
is money somewhere for replacement and there isn't. 

Also, HARDWARE replacement is the simplest and cheapest part. That doesn't 
address any of the time or expense in setting up and implementing a new system. 
That is far more expensive and time consuming than just buying a new 
motherboard. It's disingenuous to ignore this. 

> (Sadly you previously refused incoming mail as I got a bounce.) 

As you can imagine, I don't personally approve or deny each incoming email. 
It's possible my mail server denied your message based on anti-spam criteria. I 
do get incoming mail in general and I get mail sent to this list. If you want 
to troubleshoot this further, I can send you another account (off list) that we 
might use as a side channel. 

Re: Suggestions about i386 support

[Ansgar ]

Hi,

On Sun, 2024-06-09 at 08:58 -0500, r...@neoquasar.org wrote:
> What it is is functional, and paid for. And likely, already installed
> and in use somewhere (like all of my 32-bit systems). 
> 
> It's not just a matter of "buy something better." That's easy. 

Indeed, that is easier and cheaper.

> What's not easy is that a) that adds another machine to the waste
> stream, instead of continuing to get use from it, and b) someone has
> to take the time to set up the new machine, test things, migrate
> services, etc. to functionally replace the old one. That takes time
> and effort, too, multiplied by the number of such systems out there. 

(a) is false as newer hardware can already be taken from electronic
waste, so it does not add new waste. (Also electricity isn't free
everywhere.)

Maintaining support for ancient hardware costs too. And is more
expensive per device as the number of systems is lower.

> I've asked before and I'll ask again - and perhaps it's time for
> someone to contact me off list to discuss details - how can I help
> with support for i386? I have just enough software training to be
> dangerous and may be able to help carry some of the actual load here,
> instead of just asking for more free support. 

As I said before
(https://lists.debian.org/debian-devel/2024/05/msg00302.html):

If you look at https://release.debian.org/testing/arch_qualify.html
there is at least several things that can be done:

1. Add CPU security mitigations to Linux kernel.
2. Address builds reaching address limit. There were ideas to use
foreign-arch (amd64) compilers to do so.
3. Look at other arch-specific issues (porter); this can also include
baseline violations and other issues for real i386 hardware.

It is also possible to work on finding funding and asking someone else
to do this. I've no idea how much that would cost, but let's say a few
10k USD.

Which leads to the problem: most people who want this, seem to want to
continue to use old hardware (T60, N270). However, continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)

(Sadly you previously refused incoming mail as I got a bounce.)

Ansgar

Re: Suggestions about i386 support

[rhys]

Characterizing it as "ancient" intentionally misses the point. 

What it is is functional, and paid for. And likely, already installed and in 
use somewhere (like all of my 32-bit systems). 

It's not just a matter of "buy something better." That's easy. 

What's not easy is that a) that adds another machine to the waste stream, 
instead of continuing to get use from it, and b) someone has to take the time 
to set up the new machine, test things, migrate services, etc. to functionally 
replace the old one. That takes time and effort, too, multiplied by the number 
of such systems out there. 


People are saying "you can't trust the popcorn data," but that kind of sounds 
to me like people looking to support the answer they've already chosen and 
discounting evidence to the contrary. 

I understand that continuing to support things isn't free. I've offered to 
contribute, but my offers have all been met with descriptions of how hard 
someone else is working, rather than any description of how I might help. 

Lastly, there was a description of a problem that "needed to be fixed," but 
also "can't be reproduced." Well, if it can't be reproduced, then by 
definition, it can't be fixed. That's basic troubleshooting. If it can't be 
reproduced and doesn't seem to affect most systems, then it's barely more than 
a rumor and deserves no attention until it's substantiated further. 

So it doesn't make sense to throw that on the pile of "look how hard it is to 
support old hardware." Yes, there are challenges. Lots of them. But that's not 
one of them. 

I've asked before and I'll ask again - and perhaps it's time for someone to 
contact me off list to discuss details - how can I help with support for i386? 
I have just enough software training to be dangerous and may be able to help 
carry some of the actual load here, instead of just asking for more free 
support. 

Sent from my mobile device.

From: Marc Haber 
Sent: Monday, May 20, 2024 02:35
To: debian-devel@lists.debian.org
Subject: Re: Suggestions about i386 support

On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings 
 wrote: 
>The plan is to keep i386 as a partial architecture that can be used as 
>a "foreign architecture" on systems where amd64 is the main 
>architecture. 

Many people using ancient hardware such as a T60 thinkpad say that's 
not enough for them. I can partly understand both sides though. 

Greetings 
Marc 
-- 
 
Marc Haber |   " Questions are the | Mailadresse im Header 
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402 

Re: About i386 support

[Steve Langasek]

On Sat, May 18, 2024 at 10:28:21AM +, Andrew M.A. Cater wrote:
> 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.

I don't know what you're basing it on, but it's simply not true.  We've just
released Ubuntu 24.04 LTS with full support for (2038-proof) armhf
userspace.

We don't have any armhf images released with 24.04 LTS because we've dropped
32-bit support for *Raspberry Pi*, but that's a separate matter.  We expect
support for other armhf devices for both Ubuntu and Ubuntu Core to come soon
in 24.04.

-- 
Steve Langasek   Give me a lever long enough and a Free OS
Debian Developer   to set it on, and I can move the world.
Ubuntu Developer   https://www.debian.org/
slanga...@ubuntu.com vor...@debian.org


signature.asc
Description: PGP signature

Re: About i386 support

[Samuel Thibault]

Hello,

Tomas Pospisek, le mar. 21 mai 2024 17:22:47 +0200, a ecrit:
> > > 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, r...@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.

It's probably not that easy to find.

The page I know about that would suit best would be the Build-Attempted
and Failed sections of:

https://buildd.debian.org/status/architecture.php?a=i386=sid

> 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.

Yup

Samuel

Re: About i386 support

[Tomas Pospisek]

Hi Maite, hi Rhys,


don't top-post. That breaks the flow of the arguments being argued about.


*From:* Johannes Schauer Marin Rodrigues 
*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 keep 
the 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, r...@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 oder 
Developer yourself consult with the package's maintainers and upload 
fixed packages.

*t

Re: About i386 support

[Leandro Cunha]

Andrey,

On Tue, May 21, 2024 at 3:31 AM Andrey Rakhmatullin  wrote:
>
> On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > > 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 ?
> > > There is no "end of support for 32 bits" yet so no.
> > When you refer to 32 bits you are referring to i386 (see the subject),
> No, please don't, this confuses people.
>
> --
> WBR, wRAR

I agree that it can be confusing, but I mentioned that we are
specifically talking about this architecture (i386) that is in the
subject of the email and to avoid confusion.

--
Cheers,
Leandro Cunha
-BEGIN PGP PUBLIC KEY BLOCK-

mQINBF/gQ8gBEADHVKgoWsUWNGVvR6sMhBPUdBUEH+QALpr1QYXhetBfRwaY0HWN
pKgejHdxKO8H+kIhRMoh89CCKg3hAJ9LmOOTXkX7U5/Cya/zRMKk5zBD3rKIaugh
0XYT15Nz1jwL7TIDG25yPSloDtVgVXTep0ZzKsNYJjb4OAqa88cvUEJEhhqrldlR
gpNbkixEh5ituO8pMShEBWqLs3yt4Hr1VFWnTIm4dl/JLBHpexzubDOw/mKCTpNd
A1JGHTvce1wtJ2fMzCVzhEjd5pyjLZV/o8hVw2/ON/yXvpJuz0lV/hiW0M+cDcas
sKftErtsZpRy3wwXdkBcJt6soYuqfCHwgMfL2iC6mPviE8xWAHMOmhdC3wDskZpb
RcLfH5IMYajJAGRO/GCMcKKbq7WkEOeloivtg64xBlYuJf9aOcHKP/8R3EObiNp7
ubQAJtV3pEGD4mx1mhutFxDHB+CfnxE3dWvxZSV9y1n4UOzkDJ3kDx5Ee0MbRvJD
w6aXKc6dhYREgh7hLDcMFz+3LcBiZDLxI3g+SHe3Bl61vdsnPno+0HhCzvB+fL4S
eoy7Myfiunz9BrB2HPN+wNCT0YgV+Kv8QoDGzBwos5H1vUJSY4t59w6xoXAYUsAm
hjAM8s+rUtG40mcUWePd8kZtgE9IV1eQ+Qt8/SNpSdRnUunmIGl3JjHvEwARAQAB
tClMZWFuZHJvIEN1bmhhIDxsZWFuZHJvY3VuaGEwMTZAZ21haWwuY29tPokCTgQT
AQoAOBYhBLT5oBCvKN3HzFEPK8LZ4zKUW9A8BQJf4EPIAhsDBQsJCAcCBhUKCQgL
AgQWAgMBAh4BAheAAAoJEMLZ4zKUW9A8FjAQAKWYqiLpLUD+DLB+NSy3DI3rf9z3
k0vE7TLaEjdEM5CQWN+j4vBqMnAckdcARvSWPndTjp8K+mtFF4PyfhNbS64z/a7L
F3DdhmX73n7LKFG8Ow9NZwcrkmPwH5WcP7mXTh6R+6/+OSL/K85NB8MLlxQTJOni
julVax9JEZjwBaP2HLCu53Zq9gZcvJlXoAoTHyTxKdp8Mh8V+Qit26E78o9c6SQD
Dq9eyMRG8hYCRfreDjKceRkYHjECySlk+VoI1ssVs07Dqvxg6qSyP4RnW+1+W74C
s0yIyuC/eRJpMAf1PBQEOOrVcTfRfpN+go955t21yIAvT58vqotTM5eaqXYIQn/y
sC4lThZai/ZBZHxl5Mbv42WkkYdjisLQOCALIMBpj5nq4oh2C+kvMupcuBKfERgV
dguU51MzfQktKb6d5y777zYnDaFMQDD2IfiD/C7ln5A9LP/L54ixlA3uRmWx/yAx
/m+Zusws98j4Eq/jw5T54XW655m6lMCTE9WXLJkgxrRcEonHSllbgRSsToEmWq0Z
doxcnpagHdcGQzW+cu2VOGi1da73ZFmrn+ptJgc8cW2suO06IeArOi0TzIg7e65j
Xp2DbJCpFrfzEuBb1u71WvB8V2MkAfJZx/uZJPCA936B4HT8YGPEMzlQRIHI2Y9C
+DloyzlBLTS1EMKuuQINBF/gQ8gBEAC47o9u1Wm9jZ6RC+lfxEDEvVS7MmI5VzSy
q04rFttWwbKix13pc65aDlk47LxWrb84N3Gnf1E/OTsLTXqC7u5JZ7YJkC6CsPbo
D1sQkfCiJCFCTgf7dydEVt8ujS/Uu1kz86ufdRwaMRcvBZAORGdB58LEsLB65WN4
hLRYF7xvcxu6t7FGrIYereaxUAWLA2B/ZnCEdOY94w7s0uaPjHdf4lfHebuZ7T08
iG5ACDvKBjgaFArGfdNYWchXJgbOEg14bGj40/8LuBKQMZASiFSqLPZxoporK9FY
xBw+D080dUWWD5g868TZ3pkM3DXO9bdq22IBKqKOep8CnuKgoDpUvA8dTEY/UDCn
sdOlBUK/Y9zTGVmD/90cO/xkvkV78suqiBnwBSddPzVS0EuiWwrLGu8gaY4EyM/X
7khlbTcMgh4njzUCAE6Tq+TbXSxn86wuOybVY5Y+I99LNdsocI5SIn2nDh2IOi00
4dE/iwO2MatWIOLFBC7pw8Xv4UHZY+WIf3Y/6XjExpllhUkeB6BwZpTr1SXk+cug
q5Dj5i4aGn2LrvQJ57terqUWYyDUBFgXTc4SPOzT5og8CavBgHfrQoFwSnRZ2oyX
xtZhEDI5Pk2j1qTbOhXZ29po4rPNWHMq2HQgM0I+BqQndsoVdkPOFzS2wKkdXjCz
bNYcyanusQARAQABiQI2BBgBCgAgFiEEtPmgEK8o3cfMUQ8rwtnjMpRb0DwFAl/g
Q8gCGwwACgkQwtnjMpRb0Dzh6g//ZjXaWSzKmG5ZS6XJa/ZOokkE2hFOFusWX8Qa
hEwLAnTFEy02dLfV54rKwmu2jHPDKLhE+iYtusvytueZAzVRyQahv0RE4BH8Emqw
gQdBwyJ/L+QhUp/lMdJ6Hh/2ZSZmzU29U24vnY+U+haoB1fLnA3lXgOP59kMLGud
lERR2Vluuc7TcpzvcaRWgrQRU2vSrrBBEp6y07iVKbRM/9yhE/aHJahLbhKh2Dk9
WJvHPnhYJY5yU+Y5vTl3BiW5+EuzMBdPUawOWKhqCq9dswn0GL1g/vlt/bdU/6DO
jECQ6fssTAtDjRClXySsS3X0mh8y8qlGvMPB4anfvOy4+4nUV6IESdJftKn2SMGd
CA3MaQ+S7frWn5v7GIWSC9vumCsiu1JTOugLmbVmu5m5nFsyllavm/k9LtOtswuF
fHM/SlXLFuGBWU6XceqaM2dpP8i5jGz0vIGMhqoFNgXWGO1NhwR1rmeU1CMpnM5e
Wue4h/+mJiuEzuZcmzOcwq3HGMUXO0jZDgLEmlnenO9czhrLuGZaMXGdwnIk0G3O
+SqH36v7blnDh96RXpgaa+ifTHd0qKeoVXVwSq/9jNtHSQrI+NJcTpMhu73xtxhX
UFPr/31+IFLWepC5GDwdu/gQm5E6ntGyxE2p2v76pcjz7SGdXjPFZjqekBveEJuW
fNdY6Ns=
=rdCA
-END PGP PUBLIC KEY BLOCK-

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 07:16:54PM -0300, Leandro Cunha wrote:
> > > > 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 ?
> > There is no "end of support for 32 bits" yet so no.
> When you refer to 32 bits you are referring to i386 (see the subject),
No, please don't, this confuses people.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[Leandro Cunha]

On Mon, May 20, 2024 at 6:11 PM Andrey Rakhmatullin  wrote:
>
> On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > > 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 ?
> There is no "end of support for 32 bits" yet so no.
>
>
> --
> WBR, wRAR

When you refer to 32 bits you are referring to i386 (see the subject),
they are different architectures.

[1] https://en.wikipedia.org/wiki/I386

-- 
Cheers,
Leandro Cunha

Re: About i386 support

[Andrey Rakhmatullin]

On Mon, May 20, 2024 at 10:57:58PM +0200, William Bonnet wrote:
> > 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 ?
There is no "end of support for 32 bits" yet so no.


-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[William Bonnet]

Hi all


On 20/05/2024 22:27, Leandro Cunha wrote:


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 ?

Cheers
William


OpenPGP_0x8436246AE2D3D15F.asc
Description: OpenPGP public key


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: About i386 support

[Leandro Cunha]

Hello,

On Mon, May 20, 2024 at 5:15 PM Paul Gevers  wrote:
>
> Hi,
>
> On 20-05-2024 4:50 p.m., Ben Hutchings wrote:
> > There is a tension here between the interests of (a) users that want to
> > run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
> > keep using 32-bit CPUs.  If i386 is meant for group (a) then the
> > baseline should be raised to include the features that 64-bit CPUs
> > provide, but if it's also for group (b) then this mustn't happen.
>
> The Release Team expects the Debian i386 official port to go to (a).
>
> Paul, wearing his Release Team hat.

LOL, I hope so too...
However, the future stable version will feature RISC-V (at least it's
expected), 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, which I know was the year I
bought a machine starting to use Debian 1 year later. Another
interesting development that is underway and is inherent to the topic
would be the time_t transition (the 2038 problem).

-- 
Cheers,
Leandro Cunha

Re: About i386 support

[Paul Gevers]

Hi,

On 20-05-2024 4:50 p.m., Ben Hutchings wrote:

There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs.  If i386 is meant for group (a) then the
baseline should be raised to include the features that 64-bit CPUs
provide, but if it's also for group (b) then this mustn't happen.


The Release Team expects the Debian i386 official port to go to (a).

Paul, wearing his Release Team hat.


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: About i386 support

[defrag mentation]

On Mon, 20 May 2024 00:30:13 +0200, Thomas Goirand  wrote:
> 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.

I agree with you.

No one really needs armel(armv5te) now. Linux kernel has just dropped Marvell's 
armv5te device support. RPI0/1 users want armv6hf instead of armel(armv5te). 
armhf in Debian is armv7hf, and does not support RPI0/1. It supports RPI2.

For armhf, Fedora has dropped it in 37 due to lack of community interest, and 
worse and worse upstream support. armhf is 3GB user process address space, 1GB 
shared kernel address space, and users will find armhf is a bad platform for 
any heavier jobs, such as compiling or emulating things or running heavy server 
or computing programs. Chrome and Chromium-based apps and some other things do 
not support armhf now as well.

armel, armv6hf and armv7hf can be done by embedded distros like Armbian. Debian 
can just move them into Debian ports, not release them as official arches.

For i386, I only use wine32, and do not have any pure 32-bit x86 devices. Pure 
32-bit x86 devices are aging and less energy-saving, and 64-bit first-handed or 
second-handed devices are cheap enough to buy one rather than wasting time to 
maintain i386 support. Old native i386 Linux apps can be supported by an old 
Debian release chroot or container, not by a new release (native boot or 
multiarch or chroot or container or whatever).

I would like to suggest Debian to drop all i386 things excluding wine32, and 
recompile wine32 to 64-bit time_t. And if WineHQ announced 'new wow64' becomes 
default, Debian could drop i386 completely, only leaving multilib and cross 
compiling things in amd64 is enough.

Re: About i386 support

[Ben Hutchings]

On Mon, 2024-05-20 at 13:39 +0200, Ansgar  wrote:
> Hi,
> 
> On Sun, 2024-05-19 at 10:30 -0500, 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. 
> > 
> > From: Victor Gamper 
> > 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.
> 
> If you look at https://release.debian.org/testing/arch_qualify.html
> there is at least several things that can be done:
> 
> 1. Add CPU security mitigations to Linux kernel.

With few exceptions, the CPU security issues that have been discovered
in tha past few years are not thought to affect 32-bit-only CPUs. 
(Meltdown did affect some of them but was eventually mitigated on
i386.)  I have raised the possibility of making i386 kernel builds warn
very loudly or refuse to boot on 64-bit-capable hardware, but didn't
try implementing it yet.

[...]
> 3. Look at other arch-specific issues (porter); this can also include
> baseline violations and other issues for real i386 hardware.
[...]

There is a tension here between the interests of (a) users that want to
run proprietary i386 binaries on 64-bit CPUs, and (b) those who want to
keep using 32-bit CPUs.  If i386 is meant for group (a) then the
baseline should be raised to include the features that 64-bit CPUs
provide, but if it's also for group (b) then this mustn't happen.

This also showed up in the 64-bit time_t transition, where the
transition would be desirable for group (b) but would make i386 useless
for group (a).  There was some talk then about creating a new port like
"i386t64" for use by group (b), while i386 would serve group (a) only.
Did anything come of this?

Ben.

-- 
Ben Hutchings
I say we take off; nuke the site from orbit.
It's the only way to be sure.



signature.asc
Description: This is a digitally signed message part

Re: About i386 support

[Ansgar ]

Hi,

On Sun, 2024-05-19 at 10:30 -0500, 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. 
> 
> From: Victor Gamper 
> 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.

If you look at https://release.debian.org/testing/arch_qualify.html
there is at least several things that can be done:

1. Add CPU security mitigations to Linux kernel.
2. Address builds reaching address limit. There were ideas to use
foreign-arch (amd64) compilers to do so.
3. Look at other arch-specific issues (porter); this can also include
baseline violations and other issues for real i386 hardware.

It is also possible to work on finding funding and asking someone else
to do this. I've no idea how much that would cost, but let's say a few
10k USD.

Which leads to the problem: most people who want this, seem to want to
continue to use old hardware (T60, N270). However, continuing to
support i386 has likely costs much higher than the replacement cost of
said hardware... Which is probably why nobody really seems sufficiently
motivated to actually invest resources. (Or do you?)

Ansgar

Re: Suggestions about i386 support

[Marc Haber]

On Sun, 19 May 2024 20:19:12 +0200, Ben Hutchings
 wrote:
>The plan is to keep i386 as a partial architecture that can be used as
>a "foreign architecture" on systems where amd64 is the main
>architecture.

Many people using ancient hardware such as a T60 thinkpad say that's
not enough for them. I can partly understand both sides though.

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: About i386 support

[Leandro Cunha]

Hi,

Looking at projects like Arch, Manjaro, Ubuntu, Fedora and other operating
system projects developed to use Linux as the kernel, we realize that none
of them provide ISO for 32 bits. A brief search led me to Debian as the
only one I've seen so far (
https://www.debian.org/releases/bookworm/debian-installer) and that's a few
years old. I don't see a future in 32 bits at the moment and I may be bold
in saying that I see a future in ARM 64 technologies for laptops and even
being able to exist in desktops as well. There are already some Lenovo
laptops and even MacBooks with this technology (arm 64). Processors like
the Qualcomm Snapdragon 8cx Gen 3 and Apple M3 have also attracted
attention.

Leandro Cunha

Re: About i386 support

[Luca Boccassi]

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).

Re: About i386 support

[Thomas Goirand]

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?


Cheers,

Thomas Goirand (zigo)

Re: Suggestions about i386 support

[Ben Hutchings]

On Sun, 2024-05-19 at 07:26 +, defrag mentation wrote:
> I think some of the i386 support policies needs to be reconsidered.
> 
> Here are some suggestions:
> 
> 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t.
> 
> Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as 
> it is multiarch-only now, so at least I think moving it to amd64 is needed.

I think you are confusing the removal of i386 installation media, with
the removal of i386 as a whole.

The plan is to keep i386 as a partial architecture that can be used as
a "foreign architecture" on systems where amd64 is the main
architecture.

[...]
> 2. For device support:
> 
> There are no pure 32-bit x86 non-embedded devices since 2010 (as Atom N450 
> deprecated the pure 32-bit Atom N270) widely manufactured.
> 
> i386 UEFI support is mandatory for Bay Trail and some Cherry Trail devices 
> widely manufactured in 2012-2015, as they are 32-bit Windows 8/8.1 
> preinstalled and do not support legacy BIOS boot mode.
> 
> It's good to keep i386 UEFI support (signed is better) for Bay Trail and some 
> Cherry Trail devices in Debian amd64. Bookworm has added it (moved it from 
> multi-arch iso to amd64 isos), but trixie seems to be dropping it. If Debian 
> thinks 2015 is ancient enough in 2025, this suggestions can be ommited.
[...]

You should ask about that on the debian-cd or debian-boot list.

Ben.

-- 
Ben Hutchings
For every complex problem
there is a solution that is simple, neat, and wrong.



signature.asc
Description: This is a digitally signed message part

Re: About i386 support

[Alexandre Detiste]

Hi,

I have 900 :-) (Moxa V2416). For these type of industrial/embedded use,
popcon is irrelevant. The debian-installer mostly too, the basis image was
Wheezy based with unknown third party tweaks and with only dist upgrade
from that souped up image.

The remaining other legacy project can dist upgrade from bookworm.

But well things do start falling appart anyway. This random nginx memory
corruption bug is annoying.

Greetings

Le dim. 19 mai 2024, 17:31,  a écrit :

> 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 
> *Sent:* Sunday, May 19, 2024 08:03
> *To:* debian-devel@lists.debian.org
> *Subject:* Re: About i386 support
>

Re: About i386 support

[rhys]

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. 

Sent from my mobile device.

From: Victor Gamper 
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. 

regards, 
Maite Gamper (zeldakatze) 

On 18.05.24 13:24, Ben Hutchings wrote: 
> On Sat, 2024-05-18 at 10:28 +, Andrew M.A. Cater wrote: 
>> On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote: 
>>> 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. 
>>> 
>> The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware 
>> at this 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. 
> 

Re: About i386 support

[Marc Haber]

On Sun, 19 May 2024 15:03:18 +0200, Victor Gamper
 wrote:
>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.

If you don't personally care about that T60, because it's the notebook
your mom gave you for your 16th birthday or so, you would probably be
better served with buying another old T-Thinkpad that can run amd64
AND suport amounts of memory that haven't totally fallen out of time.

Ten year old 64bit Notebooks such as the T420 or T430 (three years
younger than your T60) sell for below 100 Euros. Is that a problem?

Greetings
Marc
-- 

Marc Haber |   " Questions are the | Mailadresse im Header
Rhein-Neckar, DE   | Beginning of Wisdom " | 
Nordisch by Nature | Lt. Worf, TNG "Rightful Heir" | Fon: *49 6224 1600402

Re: About i386 support

[Victor Gamper]

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.

regards,
Maite Gamper (zeldakatze)

On 18.05.24 13:24, Ben Hutchings wrote:

On Sat, 2024-05-18 at 10:28 +, Andrew M.A. Cater wrote:

On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote:

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.


The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware
at this 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.

Re: Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, May 19, 2024 at 09:09:10AM +, defrag mentation wrote:
> > What will this solve?
> 
> > I don't think this is "needed"? Unless you think all i386 packages will be
> 
> removed from Debian, which is not the plan?
> 
> Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 
> DVDs/BDs set will be surprised that it do not contain wine32.
This isn't specific to wine.

> > Debian wine is not the only thing we want i386 libraries for.
> 
> What are they?
Non-Debian Wine (e.g. Proton), legacy native apps, probably other non-Wine
wrappers.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: Re: Suggestions about i386 support

[defrag mentation]

> What will this solve?

> I don't think this is "needed"? Unless you think all i386 packages will be

removed from Debian, which is not the plan?

Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 
DVDs/BDs set will be surprised that it do not contain wine32.

Case 2: Wine will work through Y2038 if its Unix-layer is 64-bit time_t by 
Debian, and its Win32-layer is 64-bit time_t by Wine maintainers. And it will 
be convenient to separate it from i386 repo since it will stick to 32-bit 
time_t. Visual C++ 2005 compiled things are 64-bit time_t already, so a lot of 
32-bit Win32 apps already have no Y2038 problem.

Case 3: If forky or later versions will drop i386 totally, trixie may be good 
to firstly separate wine32 from i386 repo.



> Debian wine is not the only thing we want i386 libraries for.

What are they?



> And nobody proposed it.
If nobody proposed it, this can be ignored.

Sorry for the confusion.

Re: Re: Suggestions about i386 support

[defrag mentation]

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote:

> What will this solve?

> I don't think this is "needed"? Unless you think all i386 packages will be

removed from Debian, which is not the plan?

Case 1: Debian removed i386 DVDs/BDs, and someone jigdo backed the full amd64 
DVDs/BDs set will be surprised that it do not contain wine32.

Case 2: Wine will work through Y2038 if its Unix-layer is 64-bit time_t by 
Debian, and its Win32-layer is 64-bit time_t by Wine maintainers. And it will 
be convenient to separate it from i386 repo since it will stick to 32-bit 
time_t. Visual C++ 2005 compiled things are 64-bit time_t already, so a lot of 
32-bit Win32 apps already have no Y2038 problem.

Case 3: If forky or later versions will drop i386 totally, trixie may be good 
to firstly separate wine32 from i386 repo.



> Debian wine is not the only thing we want i386 libraries for.

What are they?



> And nobody proposed it.
If nobody proposed it, this can be ignored.

Re: Suggestions about i386 support

[Andrey Rakhmatullin]

On Sun, May 19, 2024 at 07:26:28AM +, defrag mentation wrote:
> I think some of the i386 support policies needs to be reconsidered.
> 
> Here are some suggestions:
> 
> 1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t.
What will this solve?

> Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as 
> it is multiarch-only now, so at least I think moving it to amd64 is needed.
I don't think this is "needed"? Unless you think all i386 packages will be
removed from Debian, which is not the plan?

> 3. For future i386 support:
> 
> If there are not enough human resources, i386 can be dropped completely as 
> Wine-32 is moved to amd64 
Debian wine is not the only thing we want i386 libraries for.

> If someone wants to continue maintaining pure 32-bit device bootable i386, I 
> think recompiling it to be Y2038-safe is still meaningless 
And nobody proposed it.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Suggestions about i386 support

[defrag mentation]

I think some of the i386 support policies needs to be reconsidered.

Here are some suggestions:

1. ​Move Wine-32 to amd64, and Wine-32 may be compiled to 64-bit time_t.

Wine-32 is now in currently dropped i386 DVDs/BDs, not in amd64 DVDs/BDs as it 
is multiarch-only now, so at least I think moving it to amd64 is needed.

Wine-32 may be compiled to 64-bit time_t, not affecting its Win32 binary 
compatibility. For its Win32-layer, 64-bit time_t can be enabled with 
-D__MINGW_USE_VC2005_COMPAT or by linking to UCRT, but it's up to Wine 
maintainers. For its Unix-layer, 64-bit time_t can be enabled with 
-D_TIME_BITS=64 -D_FILE_OFFSET_BITS=64, and since Wine is to run Win32 
executables, this do not affect its Win32 binary compatibility. This can be 
done by Debian. For compatibility with the multiarch support to i386, I think 
renaming the dependencies' package name and soname may be needed.

There is an experimental 32-bit Unix library-free 'WoW64 thunking' or 'new 
WoW64' mode introduced in Wine 8.0 enabled by './configure 
--enable-arches=x86_64,i686', and becomes almost stable in Wine 9.0. But there 
are some restrictions in it, such as OpenGL performance problem and Win16 
support, so it's not sure whether Wine 10.0 will announce this mode becomes 
default. If Wine 10.0 announces 'WoW64 thunking' or 'new WoW64' mode becomes 
default, Wine-32 can be dropped directly.

As Freexian's ELTS is selective support, and almost no one using Debian as 
server needs Wine, Freexian probably will not support i386 any more, and thus I 
think Debian releasing important 32-bit time_t i386 stuffs like Wine-32 is 
acceptable until 2032. But Ubuntu may have a different opinion as they will 
support total Ubuntu for 12 years. Moving Wine-32 from i386 to amd64 and 
recompiling it to 64-bit time_t  (or dropping it because 'new WoW64' mode 
becomes default) may be needed for Ubuntu to keep it from Y2038 problem.

2. For device support:

There are no pure 32-bit x86 non-embedded devices since 2010 (as Atom N450 
deprecated the pure 32-bit Atom N270) widely manufactured.

i386 UEFI support is mandatory for Bay Trail and some Cherry Trail devices 
widely manufactured in 2012-2015, as they are 32-bit Windows 8/8.1 preinstalled 
and do not support legacy BIOS boot mode.

It's good to keep i386 UEFI support (signed is better) for Bay Trail and some 
Cherry Trail devices in Debian amd64. Bookworm has added it (moved it from 
multi-arch iso to amd64 isos), but trixie seems to be dropping it. If Debian 
thinks 2015 is ancient enough in 2025, this suggestions can be ommited.

3. For future i386 support:

If there are not enough human resources, i386 can be dropped completely as 
Wine-32 is moved to amd64 (or is dropped because 'new WoW64' mode becomes 
default), pure 32-bit device boot support is dropped, and it's all about 
support for ancient Linux apps/games which can be done by old Debian releases.

If someone wants to continue maintaining pure 32-bit device bootable i386, I 
think recompiling it to be Y2038-safe is still meaningless as the devices will 
be very aging and probably broken in 2038, and probably no one need a 
non-binary-compatible i386 build. Just keep it 32-bit time_t is enough as I 
think.

Re: About i386 support

[Maite Gamper]

Hello,
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?

regards,
Maite Gamper (zeldakatze)

On 18.05.24 03:15, r...@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).


--J

Sent from my mobile device.

*From:* Johannes Schauer Marin Rodrigues 
*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 keep 
the 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

Re: About i386 support

[Ben Hutchings]

On Sat, 2024-05-18 at 10:28 +, Andrew M.A. Cater wrote:
> On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote:
> > 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.
> > 
> 
> The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware
> at this 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.

-- 
Ben Hutchings
Horngren's Observation:
  Among economists, the real world is often a special case.



signature.asc
Description: This is a digitally signed message part

Re: About i386 support

[Paul Gevers]

Hi Andrew,

Release team member hat on
On 18-05-2024 12:28 p.m., Andrew M.A. Cater wrote:

In reality, i386 should probably have been dropped early (or at the last
minute) for bookworm; some libraries will be kept for compatibility
but it's not realistic to maintain i386 for the whole of the trixie lifecycle.


Please elaborate. We aren't planning to drop i386. If you have more 
information than I have, we'd like to learn.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: About i386 support

[Andrew M.A. Cater]

On Fri, May 17, 2024 at 09:58:58PM +0200, Victor Gamper wrote:
> 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.
> 

The Transmeta _won't_ do x86_64/amd64 - but is obscure (and rare) hardware
at this point.

The T60 will do amd64.

At this point, any i386-only hardware is well over ten years old.
There's no real UEFI support - so legacy MBR.

Amything else can do amd64. The law of diminishing returns, the lack
of real i386 hardware to test on - at this point, i386 32 bit is effectively
dead. Several large packages can't be built natively on i386 - things like
firefox and libreoffice really need to be built on amd64 hardware for i386.

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.

In reality, i386 should probably have been dropped early (or at the last
minute) for bookworm; some libraries will be kept for compatibility
but it's not realistic to maintain i386 for the whole of the trixie lifecycle.



> 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.
> 

See above. Popcon isn't really an absolute measure: not everyone enables
popcon so there may be very many machines running in server farms or
whatever. Very few people have an s390 around: ppc64el similarly and
armel is valid for less and less hardware (modulo the Raspberry Pi Zero)

_Some_ embedded hardware was sold more recently but it wouldn't
necessarily run Debian.

> 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.
> 

If downstream versions _REALLY_ need genuine i386, they also need to 
ask Debian and step up to maintain. Any Ubuntu derivatives - so
second order Debian versions - are already out of support on the 
latest Ubuntu.

> 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)
>

It would need several maintainers to step up and maintain hardware
and track upstream libraries, compatibility and a recompile farm.

Sorry to be the bearer of bad news but I think that's it in a nutshell.

Andy
(amaca...@debian.org) 

Re: About i386 support

[Paul Gevers]

Hi

On 17-05-2024 9:58 p.m., Victor Gamper wrote:

Is it correct that debian 13 is planned to be released without
an i386 iso and i386 is planned to be deprecated?


Our current position is described here: 
https://lists.debian.org/debian-devel-announce/2023/12/msg3.html


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: About i386 support

[rhys]

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 
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 keep the 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

Re: About i386 support

[Thomas Hochstein]

Victor Gamper wrote:

> 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?

Re: About i386 support

[Johannes Schauer Marin Rodrigues]

Quoting Victor Gamper (2024-05-17 21:58:58)
> 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?

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

signature.asc
Description: signature

About i386 support

[Victor Gamper]

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)