Kernel 6.9.9 (amd64) results in huge initrd / initramfs size

[Celejar]

Hello,

I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
running out of space on /boot:

*****
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
*****

It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!

*****
~$ ls -l /boot/initrd.img*
-rw-r--r-- 1 root root 27491557 Jul 8 13:45 /boot/initrd.img-6.9.8-amd64
-rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64
*****

Diffing the two initrd files suggests that the problem stems from the
fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP)
firmware in the initrd:

https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html

Arch dealt with this 6 months ago - they claim that the problem
actually began in kernel 6.7:

https://bbs.archlinux.org/viewtopic.php?id=291900
https://gitlab.archlinux.org/archlinux/mkinitcpio/mkinitcpio/-/issues/238

I'm not sure why I'm hitting this now - did Debian just change
something? Is anyone else hitting this? Is this documented somewhere?
Is there a straightforward fix / workaround?

[Dan Ritter]

Post by Celejar
Hello,
I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to

...

Post by Celejar
I'm not sure why I'm hitting this now - did Debian just change
something? Is anyone else hitting this? Is this documented somewhere?
Is there a straightforward fix / workaround?

Of course something changed: it's Sid.

It will probably be straightened out before it hits stable.

Do you need this firmware? If so, do you need it at boot time?
There are kernel build options. Building it as a module and
making sure that initrd doesn't include it is pretty normal for
a number of kernel modules.

-dsr-

[Celejar]

Post by Dan Ritter

Post by Celejar
Hello,
I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to

...

Post by Celejar
I'm not sure why I'm hitting this now - did Debian just change
something? Is anyone else hitting this? Is this documented somewhere?
Is there a straightforward fix / workaround?

Of course something changed: it's Sid.

The question is whether this is a change Debian made to the kernel
packaging, an upstream change,, or something I inadvertently changed on
my system. If either of the former two, Debian really needs to document
something like this.

Post by Dan Ritter
It will probably be straightened out before it hits stable.

Great. As I noted, Arch seems to have gotten a handle on this six
months ago. In the meantime, Debian really should document breaking
changes like this. Is a bug report in order?

Post by Dan Ritter
Do you need this firmware? If so, do you need it at boot time?
There are kernel build options. Building it as a module and
making sure that initrd doesn't include it is pretty normal for
a number of kernel modules.

I suppose that I can do this if I have to, but I'd rather not mess
around with stuff I don't really understand without an official guide
to the process.

[Andy Smith]

Hi,

I'd rather not mess around with stuff I don't really understand
without an official guide to the process.

I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

Asking if a specific thing is a known issue that is being worked
on? Sure. Expecting it to be documented before any user hits it? Not
so much.

Thanks,
Andy

[Andrew M.A. Cater]

Post by Andy Smith
Hi,

I'd rather not mess around with stuff I don't really understand
without an official guide to the process.

I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

If you run Sid, you are *expected* to be able to solve all your own
problems. There are no guarantees other than if it breaks, you get
to keep both pieces :)

I recognise your name: you are an experienced user, but if you're not
ready for speed of change / likelihood of serious breakage, please *don't*
run Sid.

The pace of change is high - apart from the freeze period prior to a major
release, the likelihood of random breakage is very high. If there is a major
transition (versions of GNOME, Qt versions for KDE, usrmerge for example)
you could run into breakages that will last a few weeks.

This is not the place for debugging Sid, I'm afraid, there are too few
of us here that would run Sid normally.

All the very best, as ever,

Andy

Post by Andy Smith
Asking if a specific thing is a known issue that is being worked
on? Sure. Expecting it to be documented before any user hits it? Not
so much.
Thanks,
Andy
--
https://bitfolk.com/ -- No-nonsense VPS hosting

[Celejar]

Post by Andrew M.A. Cater

Post by Andy Smith
Hi,

I'd rather not mess around with stuff I don't really understand
without an official guide to the process.

I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

...

Post by Andrew M.A. Cater
This is not the place for debugging Sid, I'm afraid, there are too few

It's not? Where, then, is the place for debugging Sid?

Post by Andrew M.A. Cater
of us here that would run Sid normally.

Really? I had the impression that lots of list subscribers / readers
run Sid. Are there statistics on this?

[Greg Wooledge]

Post by Celejar
Really? I had the impression that lots of list subscribers / readers
run Sid. Are there statistics on this?

Nah, sid users are just louder, on average. Stable users don't have
as much to talk about, because our stuff just works. ;-)

[Joe]

On Thu, 18 Jul 2024 14:10:21 -0400

Post by Greg Wooledge

Post by Celejar
Really? I had the impression that lots of list subscribers / readers
run Sid. Are there statistics on this?

Nah, sid users are just louder, on average. Stable users don't have
as much to talk about, because our stuff just works. ;-)

... thanks to many sid users helping with bug reports, and, indeed just
using stuff to demonstrate that it isn't going to break instantly.

And unless you're an experienced C/C++ programmer, then the correct way
to deal with many/most sid breakages *is* to just wait, to stick with a
previous version of something. Sometimes a bit of individual upgrading
of things in a particular order can get things to install that the apt
tools haven't managed in bulk. Certainly having more than one computer
can help.

I've used sid on my main workstation (not my server) since about the
time of etch, and submitted a few bug reports over the years. And yes,
I have a couple of spare computers which serve as backups if something
vitally important breaks badly, but this is fairly rare. I did lose
gEDA pcb for a while, but made do with an older version on my
netbook. And I've never been a professional programmer, the most I've
ever sold is a few bits of PIC assembler and, a very long time ago, a
few bits of Delphi, so I'm not going to charge in and start hacking
Linux code. Waiting is.

[The Wanderer]

Post by Celejar

Post by Andrew M.A. Cater
This is not the place for debugging Sid, I'm afraid, there are too few

It's not? Where, then, is the place for debugging Sid?

I'm no longer anything *close* to an expert in this area (having not run
sid myself in well over a decade), but my understanding is: debugging
sid is done in the BTS, collaboratively among Debian developers and that
subset of non-DD users who run sid, and preferably involves those users
investigating causes and filing bug reports with the results of those
investigations.

By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.

-- And, by doing that, you are volunteering to help protect those who do
*not* run sid from having to encounter those issues. It's an admirable
thing to do, really, if you have the time and energy and so forth to
spare for it.

(I just doubt whether a lot of those who currently run sid understand
that that is what they are volunteering for, given the pattern of "what
to update against" recommendations that I remember seeing, which was
rather at odds with what I expected and what I myself would have
recommended.)

[Celejar]

Post by The Wanderer

Post by Celejar

Post by Andrew M.A. Cater
This is not the place for debugging Sid, I'm afraid, there are too few

It's not? Where, then, is the place for debugging Sid?

I'm no longer anything *close* to an expert in this area (having not run
sid myself in well over a decade), but my understanding is: debugging
sid is done in the BTS, collaboratively among Debian developers and that
subset of non-DD users who run sid, and preferably involves those users
investigating causes and filing bug reports with the results of those
investigations.
By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.
-- And, by doing that, you are volunteering to help protect those who do
*not* run sid from having to encounter those issues. It's an admirable
thing to do, really, if you have the time and energy and so forth to
spare for it.

Done:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561

[songbird]

The Wanderer wrote:
...

Post by The Wanderer
By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.

there is no such contract. just like Debian Developers and
other volunteers are not forced to do work they would not wish
to do. however, Debian Developers and others do have a social
agreement and other rules they do pledge to abide by.

a simple user? anyone using any version, there's no contract
we agree to for such use.

Post by The Wanderer
-- And, by doing that, you are volunteering to help protect those who do
*not* run sid from having to encounter those issues. It's an admirable
thing to do, really, if you have the time and energy and so forth to
spare for it.
(I just doubt whether a lot of those who currently run sid understand
that that is what they are volunteering for, given the pattern of "what
to update against" recommendations that I remember seeing, which was
rather at odds with what I expected and what I myself would have
recommended.)

i usually run testing and parts of unstable, but also stable.

i contribute where i can when i can, but i'm certainly not
bound by any formal agreement or contract (nor could i real-
istically honor one were it somehow attempted to be imposed).

i understand your intent and that is how i feel myself but i
would not state it so strongly. i consider it all on my best
efforts and under the time contraints i have. sometimes i can
be interrupted at any moment caring for a parent so that is
a first priority no matter what.


songbird

[didier gaumet]

Post by songbird
...

Post by The Wanderer
By taking on yourself the risk and burden of running sid, you are
volunteering to be one of those who helps notice issues before they
reach testing, and report those issues so that the machinery of the
archive can stop the package versions which those issues from migrating
to testing. Ideally, you are also volunteering to be one of those who
helps the package maintainers track down and fix the issues.

there is no such contract. just like Debian Developers and
other volunteers are not forced to do work they would not wish
to do. however, Debian Developers and others do have a social
agreement and other rules they do pledge to abide by.

You are perfectly right: there is no contract and one i free to use
which Debian distro one wants to...

Post by songbird
a simple user? anyone using any version, there's no contract
we agree to for such use.

[...]
... but to me that seems ignoring what appears (to me, again) the main
goal of Debian: to provide a *stable* *user* (i.e.: to be used) distro.
A mean to this goal is to provide *testers* a way to test preparation of
the next stable release with, first, an *unstable* distro, and then a
*testing* distro.

The names of Debian distros are a down-to-earth declaration of intent:
- Stable is meant to be usable and stable
- Testing is meant to be tested
- Unstable is not meant to be stable
- Sid is the guy in the movie who *breaks* his toys

So if one chooses to *use* anything other than Stable, basically, one is
not considered a user but a tester:
https://www.debian.org/doc/manuals/debian-faq/choosing.en.html

To me a common misconception is to compare Debian
Unstable(+Experimental) to, say, the main distro of Archlinux or
Opensuse Tumbleweed, because they are rolling release distros.
For example, Archlinux has Stable repositories, and also have Testing
and Staging repositories.
The warning in Archlinux is as clear (to me) as in Debian: Stable is
meant to be used, Testing and Staging are meant to be tested, "users" of
these repositories are de facto, from Arch POV, considered testers.
https://wiki.archlinux.org/title/Official_repositories#

All that does *not* prevent nor forbid someone to *use* anything else
than the Stable channel of Debian or Arch, obviously :-)

[didier gaumet]

Le 19/07/2024 à 09:25, didier gaumet a écrit :
[...]

Post by didier gaumet
You are perfectly right: there is no contract and one i free to use
which Debian distro one wants to...

[...]

typo error, sorry:

You are perfectly right: there is no contract and one is free to use
which Debian distro one wants to...

[t***@tuxteam.de]

[...]

You are perfectly right: there is no contract and one i free to use which
Debian distro one wants to...

Actually, there /is/ a contract:

https://www.debian.org/social_contract

It's just another kind of contract than the usual "I pay you,
so you do what I say". In my eyes a kinder, deeper, more humane
kind of contract.

One of the things I love Debian for.

Cheers

[didier gaumet]

Post by t***@tuxteam.de
[...]

You are perfectly right: there is no contract and one i free to use which
Debian distro one wants to...

https://www.debian.org/social_contract
It's just another kind of contract than the usual "I pay you,
so you do what I say". In my eyes a kinder, deeper, more humane
kind of contract.
One of the things I love Debian for.
Cheers

My bad, I do know the existence of the Debian social contract but have
not worded accurately enough what I wanted to say. I should have written
something like:

"You are perfectly right: there is no such Debian contract that forbids
one to use whatever (Testing, Unstable, Experimental...) Debian distro
one wants to..."

Thank you Tomas :-)

[t***@tuxteam.de]

On Fri, Jul 19, 2024 at 10:07:14AM +0200, didier gaumet wrote:

[...]

Post by t***@tuxteam.de
One of the things I love Debian for.
Cheers

My bad, I do know the existence of the Debian social contract but have not
worded accurately enough what I wanted to say. I should have written

No bad. I perfectly understood what you meant. My notice was rather aimed
to some visitor from a distant galaxy (or to some confused future self :)

Cheers

[Celejar]

Post by Andy Smith
Hi,

I'd rather not mess around with stuff I don't really understand
without an official guide to the process.

I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

That's fair. I think I meant more that I was just going to stick with
6.9.8 until this gets sorted out, rather than muck around and deviate
from the default kernel / initrd build settings without official
documentation of the process.

Post by Andy Smith
Asking if a specific thing is a known issue that is being worked
on? Sure. Expecting it to be documented before any user hits it? Not
so much.

I understand, and largely agree.

Post by Andy Smith
Thanks,
Andy

[Michael Kjörling]

Post by Celejar

Post by Andy Smith
I don't mean this to be snarky, but that desire seems incompatible
with running Debian sid. I honestly think it's an unreasonable
expectation to want official guides for every transitory broken
state in a development tree.

That's fair. I think I meant more that I was just going to stick with
6.9.8 until this gets sorted out, rather than muck around and deviate
from the default kernel / initrd build settings without official
documentation of the process.

The process for doing that is setting up an apt pin either to force
the kernel packages to a particular, known good version, or to block
installation of a particular, problematic version of the kernel
packages.

I agree with what others have already said. If you're running Sid,
problems are par for the course, and you're expected to be able to
either help fix those issues (by filing and collaborating about bug
reports against the affected packages, and maybe contributing patches
to fix issues that you run across), solve those problems on your own
system (and ideally submit patches), or wait them out until the
package maintainers fix them (either based on bug reports filed by
others, or by noticing the issue themselves). Sometimes more than one
of those. Yes, maybe it'll work out great with the particular set of
packages you have installed; all the more power to you in that case.
Over time that becomes ever more unlikely, though, because at one
point or another any package is going to be involved in some sort of
major transition (the switch to a 64-bit time_t, a major libc upgrade,
a default init system change, or whatever else might happen as time
goes on).

[The Wanderer]

Post by Celejar
Hello,
I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
*****
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
*****
It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!
*****
~$ ls -l /boot/initrd.img*
-rw-r--r-- 1 root root 27491557 Jul 8 13:45 /boot/initrd.img-6.9.8-amd64
-rw-r--r-- 1 root root 205739589 Jul 16 14:29 /boot/initrd.img-6.9.9-amd64
*****
Diffing the two initrd files suggests that the problem stems from the
fact that 6.9.9 is including the NVIDIA GPU System Processor (GSP)
https://download.nvidia.com/XFree86/Linux-x86_64/510.39.01/README/gsp.html
Arch dealt with this 6 months ago - they claim that the problem
https://bbs.archlinux.org/viewtopic.php?id=291900

From relatively deep in this thread, the issue appears to be that the
GSP firmware references the same files multiple times via directory
symlinks, and mkinitcpio was not detecting that, but rather was creating
an actual new directory and populating it with additional copies of the
files for each such symlink.

The (a?) proposed solution appears to have been to update mkinitcpio so
that it *does* detect this: "if the parent directory of the current file
to be added is a symlink, create that symlink instead of adding the
file", or logic to that effect. I haven't followed far enough to see
whether that was actually done, but it seems(?) to have gotten far
enough for a patch doing it to have been proposed.

I imagine that the solution for the Debian side may wind up being
analogous, albeit probably for mkinitramfs (or some tool it relies on),
since I don't see a mkinitcpio in at least the parts of the archive I
can quickly search against.

[Ash Joubert]

Post by Celejar
I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!

I had the same problem. The cause is not the kernel upgrade but the
refactoring of non-free firmware packages. firmware-misc-nonfree now
recommends firmware-nvidia-graphics, causing it to be installed:

$ apt-cache show firmware-misc-nonfree
[...]
Recommends: firmware-nvidia-graphics, firmware-intel-graphics,
firmware-intel-misc, firmware-mediatek


I am not using an nvidia gpu so the fix for me was:

apt-get purge firmware-nvidia-graphics


There was NEWS when I dist-upgraded:

$ zcat /usr/share/doc/firmware-misc-nonfree/NEWS.Debian.gz
firmware-nonfree (20230625-3~exp1) experimental; urgency=medium

Several firmware files were moved from firmware-misc-nonfree into
their own package:
- firmware-nvidia-graphics: This package now holds the firmware files for
Nvidia GPU hardware.
- firmware-intel-graphics: This package now holds the firmware files
for Intel Graphics Media Driver chips (mostly i915) as found in
'modern' Intel CPUs with integrated graphics in the Broadwell and
the various 'Lake' CPU series.
- firmware-intel-misc: This package now holds the firmware files for
Intel
devices and chips which do not belong in one of the other Intel
firmware
packages. These devices/chips include for example Omni-Path devices,
Ethernet/Network chips/devices and QuickAssist Technology crypto
accelerators.
- firmware-mediatek: This package now holds the firmware files for
devices and chips made by MediaTek and Ralink, which is part of
MediaTek.

-- Diederik de Haas <***@cknow.org> Thu, 18 Jan 2024 14:00:00
+0100


Kind regards,

[Celejar]

Post by Celejar
I'm currently on kernel 6.9.8 (amd64 / Sid). Installing 6.9.9 fails due to
update-initramfs: Generating /boot/initrd.img-6.9.9-amd64
zstd: error 70 : Write error : cannot write block : No space left on device
E: mkinitramfs failure zstd -q -9 -T0 70
update-initramfs: failed for /boot/initrd.img-6.9.9-amd64 with 1.
It turns out that the initrd for 6.9.9 is more than 7x the size of the
one for 6.9.8!
$ apt-cache show firmware-misc-nonfree
[...]
Recommends: firmware-nvidia-graphics, firmware-intel-graphics, firmware-intel-misc, firmware-mediatek
apt-get purge firmware-nvidia-graphics
$ zcat /usr/share/doc/firmware-misc-nonfree/NEWS.Debian.gz
firmware-nonfree (20230625-3~exp1) experimental; urgency=medium
Several firmware files were moved from firmware-misc-nonfree into
- firmware-nvidia-graphics: This package now holds the firmware files for
Nvidia GPU hardware.
- firmware-intel-graphics: This package now holds the firmware files
for Intel Graphics Media Driver chips (mostly i915) as found in
'modern' Intel CPUs with integrated graphics in the Broadwell and
the various 'Lake' CPU series.
- firmware-intel-misc: This package now holds the firmware files for Intel devices and chips which do not belong in one of the other Intel firmware
packages. These devices/chips include for example Omni-Path devices,
Ethernet/Network chips/devices and QuickAssist Technology crypto
accelerators.
- firmware-mediatek: This package now holds the firmware files for
devices and chips made by MediaTek and Ralink, which is part of
MediaTek.

Thanks much! *This* type of answer is why I posted here instead of
going straight to the BTS - none of the messages prior to this one
provided any insight as to why I was hitting the problem now, while
other distros had hit it months ago, or where the problem really lay.
As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.

[Ash Joubert]

Post by Celejar
Thanks much!

[...]

Post by Celejar
As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.

You are welcome! Please close your kernel bug report.

Hard to pin this on the firmware package either as the recommends is
arguably the right behaviour to prevent missing firmware at boot time,
but the recommends has this surprising side-effect for those with a
/boot partition with insufficient free space for such a large firmware
package. It is not dangerous because the old initrd is not removed until
the new one is written successfully, but it is annoying!

Kind regards,

[David Wright]

Post by Ash Joubert

Post by Celejar
Thanks much!

[...]

Post by Celejar
As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.

You are welcome! Please close your kernel bug report.
Hard to pin this on the firmware package either as the recommends is
arguably the right behaviour to prevent missing firmware at boot time,
but the recommends has this surprising side-effect for those with a
/boot partition with insufficient free space for such a large firmware
package. It is not dangerous because the old initrd is not removed
until the new one is written successfully, but it is annoying!

According to Debian policy: "The Recommends field should
list packages that would be found together with this one
in all but unusual installations."
-----------------------------

So if my old Broadcom ethernet card requires firmware-misc-nonfree
(the package for "firmware blobs which are not individually large
enough to warrant a standalone package"), it would be /unusual/ for
the installation not to need some Nvidia firmware as well?

That doesn't seem to make any sense. Suggests might be a better
relationship, but even that seems a stretch to me.

"Suggests […] is used to declare that one package may be more useful
with one or more others. Using this field tells the packaging system
and the user that the listed packages are related to this one and
can perhaps enhance its usefulness, but that installing this one
without them is perfectly reasonable."

Cheers,
David.

[Celejar]

Post by Celejar
Thanks much!
[...]
As per another message in this thread, I've already filed a bug against
linux-image-6.9.9-amd64, but I suppose I should update the report with
this information, indicating that it's not really a problem with that
package.
You are welcome! Please close your kernel bug report.
Hard to pin this on the firmware package either as the recommends is
arguably the right behaviour to prevent missing firmware at boot time,
but the recommends has this surprising side-effect for those with
a /boot partition with insufficient free space for such a large
firmware package. It is not dangerous because the old initrd is not
removed until the new one is written successfully, but it is annoying!

Update: FWIW, Debian Developer Ben Hutchings actually assigned this
issue a "grave" severity, and it was ultimately moved to the
initramfs-tools package. It's now fixed:

https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561

[Ash Joubert]

Post by Celejar
Update: FWIW, Debian Developer Ben Hutchings actually assigned this
issue a "grave" severity, and it was ultimately moved to the
https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1076561

Well done! Thank you for helping to make Debian better. 🙏

Kind regards,