Regarding 32-Bit (x86) Support for Debian 13

[siamhie]

Also, Debian has stopped building kernels for 32bit x86 upstream, starting with 6.11 kernels. It's already happening.

Yup. They stopped signing them in 6.6.7-1~exp1 and stopped building them in 6.11-1~exp1.

linux (6.6.7-1~exp1) experimental; urgency=medium

* New upstream stable update:
https://www.kernel.org/pub/linux/kernel ... eLog-6.6.5


[ Bastian Blank ]
* [i386] No longer sign kernels.
* Properly merge Build-Depends, so that we don't carry hundred identical
entries.
* [udeb] Fix nic-shared-modules dependencies.
* Add dependency on image to headers package.




linux (6.11-1~exp1) experimental; urgency=medium

* New upstream release: https://kernelnewbies.org/Linux_6.11


[ Ben Hutchings ]
* [x86] ACPI: Enable ACPI_EC_DEBUGFS as module (Closes: #980555)
* [i386] Stop building kernel packages
* rtla: Switch to out-of-tree build:
- Revert "tools/rtla: Restore option to set VERSION var to VERSION file's
contents"
- Fix installation from out-of-tree build
* rtla: Enable verbose build
* rtla: Build with dpkg's recommended compiler flags (regression in 6.9)
* rtla: Fix missing debug symbols
* rtla: Disable LTO
* rtla: Set LD correctly for cross-build
* objtool: Build with dpkg's recommended compiler flags (regression in
6.5.1-1¬exp1):
- Revert "tools build: Clean CFLAGS and LDFLAGS for fixdep"
- Update "fixdep: Allow overriding HOSTCC and HOSTLD" to clear the
buildflags when overriding
- d/rules.d/t/objtool: Put buildflags in the correct variables when
recursing
- d/rules: Delete blhc ignore regexp for objtool



https://metadata.ftp-master.debian.org/ ... _changelog

[topcat]

We have some concepts of a plan...

I see what you did there

In 2 weeks!

[topcat]

We have some concepts of a plan...

I see what you did there

In 2 weeks!

[Arnox]

With the issues that Intel is facing and the alleged offer by Qualcomm to Intel we might see the end of x86_64 and x86_32 lineup itself. As it is Intel chips cannot compete with ARM based chips either on efficiency or in power draw.

Intel/x86 is far from out of the game, though ARM is definitely starting to invade their territory for sure. I suspect we'll get at least 5 more years of x86-64 dominance and maybe even longer after that depending on if Intel/AMD can innovate enough to keep up with ARM. In any case, it's not a sure thing.

About the move to remove legacy support from Debian 13 that has been in works for a long time.

Kinda, yeah. But they never gave a firm end-date for it to my knowledge. You'd expect them to give a much more locked-in deadline for this first before they actually did it.

We have some concepts of a plan about using a 32-bit antiX kernel for MX 25, but it's still under discussion, and may not materialize.

Doing some further investigation, I think what Debian is looking to do is continue offering and supporting the 6.10.x kernels with security updates for Debian 13 to fill the x86 hole, but nothing further than that. Don't know if that changes what you guys are planning.

This seems more reasonable, but at the same time... Why? Why not just ship the damn 6.11 kernels with x86 support and announce a firm cut-off date for later on? Now they have an extra kernel version they need to keep track of.

Even if that were not the case nobody said that Kernel source will no longer compile on 32bit systems so as long as there will be 32bit legacy Packaging then if any organization is interested in maintaining a 32bit Distro (although "why?" is becoming a more dominant question) it will fall upon the Distro Maintainers to build their own kernels. Debian not doing it isn't the end of the road at all..

Of course it's not the end of the world, but it also puts unnecessary work and responsibility on the distro maintainers. The MX/AntiX team in particular already has a crapload of stuff to maintain. They don't need the hassle of compiling more kernels because the Debian team suddenly, without any warning, decided they can't be arsed to do it.

[DukeComposed]

In 2 weeks!

"Get ready for a surprise."

[Eadwine Rose]

Guys, no politics, also no hinting toward it, thanks.

[dolphin_oracle]

debian announced this in the debian mailing list a year ago this December and it made the usual news sources. Here's the register's link.

https://www.theregister.com/2023/12/19/ ... op_x86_32/

debian will likely use the next LTS kernel for debian 13. this should drop before the end of the year, that's when they usually appear. could be 6.11, but might be 6.12. either way, I don't forsee a 32 bit kernel nor a 32 bit debian installer iso/app, at least in the x86 category. might still keep a 32bit arm I guess.

as for "firm" cutoff dates....debian rarely uses cutoff dates until they get into freeze cycle, and even then take them with a grain of salt.

antiX doesn't use debian kernels, so it doesn't change much for antiX. We have a decision to make, and we haven't made it yet, and likely won't until after debian feature freeze.

[AK-47]

We will probably not know for sure until closer to the time. I'm not a big fan of trusting some tech journos that sensationalise everything as if the apocalypse is about to occur as a result of a Linux developer farting in Antarctica, don't cite any definitive source (eg. mailing list announcement) and just speculate on what may happen.

I do still have a 32-bit laptop, so not having MX on it may be a drag, but I'll survive. The installer will still have to support 32-bit anyway because antiX supports it, but there isn't much additional overhead for supporting 32-bit in the installer so why not.

[AVLinux]

Also...

Isn't the reason antiX maintains their own 32bit Kernels is because a growing number of older 32bit computers don't work well with newer kernels anyway, I mean the hardware has already been supported for over a decade (maybe two!), aside from the security patches (which are designed to apply to older Kernels as well) what do 6.X+ Kernels really have of any benefit to legacy 32bit computers?

I suppose external peripheral hardware support would be one thing but if the main computer doesn't work well with a latest kernel I suppose that is a moot point..