Re: About i386 support

[Victor Gamper]

Hello,
Sorry for taking this long to respond, I've had quite some stuff
to catch up on, after I was ill for 1 1/2 weeks.

On 20.05.24 02:56, Luca Boccassi wrote:

On Sun, 19 May 2024 at 23:30, Thomas Goirand  wrote:

On 5/19/24 17:30, r...@neoquasar.org wrote:

I have an N270 system I can use to contribute, if someone is willing to
explain what I need to do to make it useful.

Hi,

If you allow me ... I was expecting someone else to write it before me,
but seeing nobody does, let me try.

... The issue isn't only about how many contributors, or how much effort
they put into it, but how much *everyone* in the project wants to spend
time on i386 support.

For example, *I* don't care at all about 32 bits arch, and would prefer
if these were to be sent to ports.debian.org. I really mean *all* 32
bits arch, including armhf for example.

Indeed, it's annoying each time when:
- I have to pin Arch: in debian/tests/control for example, only because
some packages have dropped 32 bits support (hint: sometimes, because
some of them also maintained by myself as well, like OpenVSwitch, for
example).
- I have to care for failed build (often because of unit tests) in i386
of packages I know wont mater for these arch.

And this is only 2 examples. This is a considerable loss of my (limited)
contributor time.

If 32 bits support was removed from Debian, this would make my (Debian)
life easier, while I have zero use of 32 bits. If I had to setup Linux
on a pi-zero, I probably would choose a more embedded distro than Debian
anyways, and that's what I would recommend to anyone. Anyone running
Debian on a non-amd64 capable laptop, at this time, should stop
procrastinate, and get decent hardware (as mentioned earlier in this
thread, cheap 2nd hands amd64 laptops are *very* cheap).

Because I know others care, I continue to make the effort when possible.
But these others should remember that's annoying me, and should weight
the collective cost, because I might not be the only one... and everyone
slightly involved in maintaining Debian might have, at some point, loss
some time on 32 bits support.

So this is a collective decision we should make: is 32 bits still
relevant enough for spending (wasting?) our collective (limited) time on
it? I'd vote no ... Especially considering i386 can become an unofficial
port for those who care. Even if I will respect our community decision
until the majority agrees, and will continue to do my best with i386
support until then, it has to happen one day. The only question is how
long. Can Trixie be the last release with 32 bits support?

On top of all these (very much agreeable) considerations, full i386
support is not just about "I have some hardware around to boot
images". We need porters who can triage, debug and fix complex
toolchain issues.

For example, we have a report that on some actual 32bit CPU
(unreproducible on anything else), due to the default compiler
optimizations some versions of gcc generate seemingly broken code when
building systemd, which causes memory corruption and an assertion to
be raised when a data structure is corrupted, which happens on
daemon-reload: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=944645
Nobody has been able to reproduce this on modern CPUs, so nobody has
put any time toward fixing this. The upstream bug report (closed due
to long inactivity) has more details, including decoded backtraces,
but it's not enough, someone needs to look at the generated code and
how it runs on said old 32bit CPUs, because for the same build the
issue doesn't happen in VMs, nor on modern CPUs running 32bit kernels.

These are the kind of issues that require work, that just isn't happening.

So, can any of the people who are saying they want to work on keeping
i386 alive as a fully bootable architecture step up and fix this
issue? If bugs like these don't get proper fixes (no, workarounds like
disabling compiler optimizations are not acceptable), then I don't see
what kind of future as a fully bootable architecture i386 can have. It
should of course continue as a toolchain plus libraries, so that
legacy programs can run on amd64. But if a fix for that bug doesn't
show up, after the installer and the kernel have dropped i386 builds,
I will most likely drop i386 from systemd too (aside from the
libraries ofc).


I've tried reproducing the daemon-reload bug report, unless I missed 
something

obvious, daemon-reload works on my T2300, the TM Efficeon, and the pre-SSE2
Pentium 3 (mobile) that I have. I could try running it on an original 
Pentium, but
I doubt that debian will run on it at all, even when ignoring the fact 
that the thing
also only has 96M of ram, which is to small to load a ramdisk and debian 
only targets
i686. So the bug might only apply to a very specific processor, unless 
there is a patch

in the debian package.

regards,
Maite Gamper

Re: Re: About i386 support

[Luca Boccassi]

> 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


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

Re: autoconf 2.72 to unstable?

[Sergei Golovan]

Hi Gürkan,

On Fri, Jun 14, 2024 at 12:03 PM Gürkan Myczko  wrote:
>
> Have never done mass bug filings, any easy way, preferably something
> copy pastable,
> non-interactive.

Concerning erlang, I've already prepared an upload which builds with
autoconf 1.72, so you may skip it when reporting bugs.

Cheers!
-- 
Sergei Golovan

Bug#1073195: ITP: hyprwayland-scanner -- Implementation of wayland-scanner for Hyprland

[Alan M Varghese]

Package: wnpp
Severity: wishlist
Owner: Alan M Varghese 
X-Debbugs-Cc: debian-devel@lists.debian.org, a...@digistorm.in

* Package name: hyprwayland-scanner
  Version : 0.3.10
  Upstream Contact: vaxerski  
* URL : https://github.com/hyprwm/hyprwayland-scanner
* License : BSD-3-Clause
  Programming Lang: C++
  Description : Implementation of wayland-scanner for Hyprland

hyprwayland-scanner is "a Hyprland implementation of wayland-scanner, in
and for C++."

This is a dependency for the Hyprland window manager for Wayland[1][2].

[1] https://github.com/hyprwm/Hyprland
[2] https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1040971

Re: DEP17 /usr-move: debootstrap set uploaded

[Andreas Tille]

Am Thu, Jun 06, 2024 at 08:14:18PM +0200 schrieb Étienne Mollier:
> > 100% agreed.  The care and excellence that you've brought to this work has
> > been exceptional.
> 
> Very much seconded, you have my thanks added on the stack!  :)

Seconded as well.  You deserve a $DRINK / some sweets once we meet next
time (no matter whether I might wear my DPL hat at hat time any more).
;-)

Kind regards
   Andreas.

-- 
https://fam-tille.de

Re: Re: About i386 support

[rhys]

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

Re: Re: About i386 support

[Andrey Rakhmatullin]

On Fri, Jun 14, 2024 at 05:53:42AM -0500, r...@neoquasar.org wrote:
> A bug that can't be reproduced, effectively doesn't exist. 
Wow.

-- 
WBR, wRAR


signature.asc
Description: PGP signature

Re: About i386 support

[Maite Gamper]

Hello,

On 14.06.24 12:53, r...@neoquasar.org wrote:
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 
*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


Looking at the upstream bug report, the issue seemed to also affect
the  Intel J1900, which is a amd64 machine, so the bug is architecture-
independent. I'll look if I can get either of those processors, though I'd
doubt that.

However I do get the point that toolchain issues are a major problem and
can be a blocker for supporting an architecture, having encountered some
bugs when porting globulation2 to Haiku.
I'll look at the debian build tracker to have a look at broken packages.
Currently though I still don't really understand how the tracker works,
I'll first try to get a grasp about that.

Kind regards,
Maite Gamper

Re: Re: About i386 support

[Luca Boccassi]

On Fri, 14 Jun 2024 at 11:54,  wrote:
>
> 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.

Of course it is a reason to drop an architecture. Not the mere
existence of an individual bug of course, but the fact that there is
nobody who is able or willing to successfully triage and debug and fix
such toolchain issues. As per RT's requirements, a release
architecture requires multiple porters as one of the basic
requirements to be considered, and the fact that nobody can fix issues
like these means there are effectively 0 porters. Once again,
maintaining a release architecture does not just mean having a machine
under your desk and building trivial packages, it means maintaining a
functioning toolchain, which involves triaging and fixing complex
bugs.

Re: Suggestions about i386 support

[Maite Gamper]

Hello,

On 09.06.24 16:21, Ansgar 🙀 wrote:

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.


There can be other reasons aswell, for example, it's quite hard
to get a T61 with 4:3 screens and later models only have widescreens,
which I find cumbersome to use.


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.


Newer hardware is still often sought after and as such often quite
costly, whilst you can sometimes snatch a machine from e-waste,
you have to still be lucky.

About electricity: I know that, and that is part of the reason why I
would never use a Pentium 4 as a server nowerdays. However,
with laptops, which often run in standby or are at idle and have
good power-saving features, the advantage, at least with my T60
lies in 4-10W, which can be mostly attributed to the CCFL, if the
powertop output is correct. (If I were to switch out the CCFL for
an LED, I might be able to get single digit discharge-rates.)

Also the repairability of newer laptops is often times garbage,
something I find invaluable on a transportable device, not to mention
that you can replace such machines quite cheaply, in the worst case.


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.


CPU mitigations exist in the PAE kernel that is at least supported on an
Intel Pentium PRO (and on Pentium M's with forcepae, to my knowledge).
Instead of removing i386 entirely, I'd suggest to bump the requirements to
include PAE, if that would otherwise be an argument to stop supporting i386.
If someone would really like to run debian on a non-PAE-system, they'd still
be able with a custom kernel.


2. Address builds reaching address limit. There were ideas to use
foreign-arch (amd64) compilers to do so.
Wouldn't that be important for all 32-bit archs? I'll have a look at 
trying to setup

a crosscompile environment.

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

My mail server has some problems which is the reason why I use my old mail
address. My new address is m...@zeldakatze.de , however, currently postfix
sends mail on the wrong ip address breaking rDNS lookups, which I'll 
have to fix.

Ansgar



regards,
Maite Gamper (zeldakatze)

Re: File descriptor hard limit is now bumped to the kernel max

[Mourad De Clerck]

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.


Hi,

It seems some proprietary software (the JetBrains IDEs) has some 
problems with this change.


See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522

While I wait for them to fix this on their end, what's the best way to 
revert this to the original behaviour on my machine?


I would think:

echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf

… would do the trick, but "ulimit -Hn" reports 524288.

Something to do with DefaultLimitNOFILE=1024:524288 maybe? But 
overriding that didn't work.


Thanks,

--
Mourad De Clerck

Re: File descriptor hard limit is now bumped to the kernel max

[Luca Boccassi]

On Fri, 14 Jun 2024 at 13:21, Mourad De Clerck  wrote:
>
> > PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
> > bumped early at boot from 1048576 to the max value that the kernel
> > allows, which on amd64 is currently 1073741816.
>
> Hi,
>
> It seems some proprietary software (the JetBrains IDEs) has some
> problems with this change.
>
> See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522
>
> While I wait for them to fix this on their end, what's the best way to
> revert this to the original behaviour on my machine?
>
> I would think:
>
> echo "fs.nr_open = 1048576" > /etc/sysctl.d/99-max-fds.conf
>
> … would do the trick, but "ulimit -Hn" reports 524288.
>
> Something to do with DefaultLimitNOFILE=1024:524288 maybe? But
> overriding that didn't work.

For user instances the link you shared has a workaround, it has to do
with PAM limits, that should work.
Please keep the pressure on the upstream project to fix that bug as
well. Thanks.

Re: File descriptor hard limit is now bumped to the kernel max

[Michael Biebl]

Am 14.06.24 um 14:13 schrieb Mourad De Clerck:

PSA: as of systemd/256~rc3-3 the open file descriptors hard limit is
bumped early at boot from 1048576 to the max value that the kernel
allows, which on amd64 is currently 1073741816.


Hi,

It seems some proprietary software (the JetBrains IDEs) has some 
problems with this change.


See for instance: https://youtrack.jetbrains.com/issue/IJPL-156522


See https://github.com/JetBrains/pty4j/pull/149

Feel free to upvote the MR.



OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: autoconf 2.72 to unstable?

[Andreas Metzler]

On 2024-06-14 Gürkan Myczko  wrote:
[...]
> Have never done mass bug filings, any easy way, preferably something copy
> pastable,
> non-interactive.

Hej,

How about mass-bug(1) in devscripts?

cu Andreas

Re: About i386 support

[Russ Allbery]

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

-- 
Russ Allbery (r...@debian.org)  

Re: About i386 support

[rhys]

> On Jun 14, 2024, at 11:46, Russ Allbery  wrote:
> 
> r...@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.

--J

Re: About i386 support

[Gunnar Wolf]

rhys dijo [Fri, Jun 14, 2024 at 01:09:18PM -0500]:
> 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.

I'm very happy that Debian has provided you with a tool for your aging
hardware for 30 years already. However, the Debian project (a group of
around a thousand individuals, each of them working independently in
their own time, and according to their own motivations) has decided to
drop support for that architecture.

I am sorry this becomes a pain point for you. As a project, we try to
always put our users first. But there is a tension --- the amount of
energy (person-hours) needed to keep i386 alive is higher than what we
are willing to put up with (and there are many documented documents
leading to that, mostly the most prominent of which is the
architecture qualification rules).

Maybe you didn't read Russ' excellent explanation as an answer to your
previous message. Supporting an architecture (that, yes, still has
many millions of computers that can use it, and that was the original
development target both of Linux and of Debian) is not as easy as
setting up some computers to compile and accept some bugs as corner
cases. There are, and there will be, each time more technically-hard
bugs to overcome.

And there's just not the needed interest to keep it alive.

In case you, and a group of devoted people, are willing to put up with
the effort to keep i386 a viable architecture, please step up and do
it (either as a port or as an official architecture). It is too late
for you to become a DD and join the developer for architecture
qualification for the Trixie cycle (but having a full-hosted i386
install as a port would not be impossible!), but you might still
achieve it for our next release.

In the meantime, please don't abuse volunteer time. Every minute
somebody spends time answering to rants blindly saying that "this old
stuff is not so broken" is a minute we don't spend making Debian
better for more use cases.

- Gunnar.


signature.asc
Description: PGP signature

Re: About i386 support

[Paul Gevers]

Hi

On 14-06-2024 8:09 p.m., rhys wrote:

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.


And you can keep trying that until it doesn't work for you anymore, 
we're not saying we'll hold you from trying. What support means here is 
that if you come and say: here's a bug, we'll say: you're on your own to 
fix it.


Paul


OpenPGP_signature.asc
Description: OpenPGP digital signature

Re: Suggestions about i386 support

[Ben Hutchings]

On Fri, 2024-06-14 at 14:07 +0200, Maite Gamper wrote:
> Hello,
> 
> On 09.06.24 16:21, Ansgar 🙀 wrote:
[...]
> > 
> > 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.
> 
> CPU mitigations exist in the PAE kernel that is at least supported on an
> Intel Pentium PRO (and on Pentium M's with forcepae, to my knowledge).
[...]

You're thinking about the NX or XD bit, which was introduced with AMD64
but is also supported by some later 32-bit-only CPUs.

But I believe Ansgar was referring to mitigation of speculative
execution vulnerabilities.  Mitigations in the Linux kernel usually
require assembly-language code that is written for 64-bit mode and
would require extra work (that does not happen) to cover 32-bit builds.
as well.  While "Meltdown" was eventually mitigated in 32-bit builds
that change was never backported in stable updates, so Debian 8 and 9
on i386 remained vulnerable.

However, these vulnerabilities aren't only a problem for i386.  Many
speculative execution mitigations depend at least partly on updated
microcode which can only be provided by the manufacturer.  CPU support
lifetimes can be quite short; for example compare the Launch Date and
End of Servicing Updates Date on
.
(I can't find similar published information from AMD but there's a
vague general statement at the bottom of
.)

I also don't think these vulnerabilities are likely to be a practical
concern for people using 32-bit-only CPUs.  But we definitely should
discourage users from using i386 kernel packages on 64-bit-capable
hardware, if we don't drop them entirely.  I keep meaning to implement
a boot-time warning about that...

Ben.

-- 
Ben Hutchings
Never put off till tomorrow what you can avoid all together.



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

Bug#1073240: xcur2png -- program to convert X cursors into PNG images

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-devel@lists.debian.org
Control: block 1073140 by -1

* Package name: xcur2png
  Version : 0.7.1
  Upstream Contact: https://github.com/eworm-de/xcur2png/issues
* URL : https://github.com/eworm-de/xcur2png
* License : GPL-3+
  Programming Lang: C
  Description : program to convert X cursors into PNG images

 xcur2png is a program which lets you convert an X cursor and convert it into a
 PNG image, and generate a configuration file reusable by other programs like
 xcursorgen.

Required for nwg-look.
Will need sponsor to upload to NEW.

--
Kind regards,
Maytham Alsudany


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

Bug#1073246: ITP: azote -- wallpaper manager for wlroots-based compositors and some other WMs

[Maytham Alsudany]

Package: wnpp
Severity: wishlist
Owner: Maytham Alsudany 
X-Debbugs-CC: debian-devel@lists.debian.org, debian-pyt...@lists.debian.org

* Package name: azote
  Version : 1.12.9
  Upstream Contact: https://github.com/nwg-piotr/azote/issues
* URL : https://github.com/nwg-piotr/azote
* License : GPL-3+
  Programming Lang: Python
  Description : wallpaper manager for wlroots-based compositors and some 
other WMs

 Azote is a GTK+3 - based picture browser and background setter, as the
 frontend to the swaybg (sway/Wayland) and feh (X windows) commands. The user
 interface is being developed with multi-headed setups in mind. Azote also
 includes several colour management tools.
 .
 The program, written primarily for sway, should work on all wlroots-based
 Wayland compositors, as well as on some X11 window managers. GNOME is not
 supported.
 .
 This application is a part of the nwg-shell project.

Will be maintained in DPT.
Will need sponsor to upload to NEW.

--
Kind regards,
Maytham Alsudany



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

Re: Suggestions about i386 support

[Marc Haber]

On Fri, 14 Jun 2024 21:04:23 +0200, Ben Hutchings
 wrote:
>But we definitely should
>discourage users from using i386 kernel packages on 64-bit-capable
>hardware, if we don't drop them entirely.  I keep meaning to implement
>a boot-time warning about that...

We could build that into the update-grub kernel snippet, with the
advantage that it would be easier to get rid of the warning locally.

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