Bug#1086503: The underlying request may be to add 32 bit equivalents of 64 bit caps where the feature is actually accessible from 32 bits

[Ben Hutchings]

On Thu, 2024-10-31 at 12:38 +, Bastien Roucariès wrote:
> Hi;
> 
> In order to be clear the underlying request is to add 32 bit equivalents of 
> 64 bit caps where the feature is actually accessible from 32 bits and make 
> sense
> 
> the second wave of crypto instructions (sha3, sha512) was not added to arm32

Please contact upstream (linux-arm-ker...@lists.infradead.org) directly
to make this request.

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

Bug#1086604: linux-image-6.11.4-amd64: amdgpu is unable to resume from suspend

[Ben Hutchings]

Control: tag -1 moreinfo

On Sat, 2024-11-02 at 11:17 +1030, and...@lists.savchenko.net wrote:
> Package: src:linux
> Version: 6.11.4-1
> Severity: important
> 
> 
> Dear Maintainer,
> 
> After an update to 6.11.4, I am observing the following single line in 
> the TTY after resume from S3:
> 
> ```
> amdgpu :75:00.0: drm *ERROR* dc_dmub_srv_log_diagnostic_data dmcub 
> error - collecting diagnostic data
> ```
> 
> The problem is not present when booting 6.10.X and earlier kernels.

You need to provide the full kernel log and device information (from
lspci).

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

Bug#1085160: linux-sysctl-defaults: apply setting after installation

[Ben Hutchings]

On Thu, 2024-10-24 at 21:09 +1100, Craig Small wrote:
> On Thu, 24 Oct 2024 at 11:25, Ben Hutchings  wrote:
> 
> > 
> > 1. As discussed in the GitLab MR, systemd implements a file trigger on
> >sysctl configuration files.
> 
> I'm not seeing that. There are three triggers in systemd 256.6-1 but not
> for sysctl files.
> Wouldn't it be in
> https://salsa.debian.org/systemd-team/systemd/-/blob/debian/master/debian/systemd.triggers?ref_type=heads

This was a proposed action, not a statement of current behaviour.

> 2. Either:
> >(a) procps implements a similar trigger, but makes it a no-op when
> >systemd is pid 1.
> >(b) linux-sysctl-defaults postinst does:
> >- if systemd is pid 1, nothing;
> >- otherwise, if sysctl is installed, "sysctl --system";
> >- otherwise, nothing.
> > 
> I agree that directly calling the specific file is a bad idea. A user may
> have overrides in other files
> which may not be caught up if you specify a file directly.
> 
> So there are a few things here:
>  * A fix for linux-sysctl-defaults conf files
> * Generically something for any package
> 
> If we're trying to do the first, then having something like your option b
> seems a good idea.
> The conf file and the postinst are the same package, so its simple. It is
> actually what
> #1085160 is about.

Yes.  But the logic is not so straightforward that other packages
installing sysctl files have all done the same thing.  I would like to
start moving toward a consistent behaviour for such packages rather
than just adding another variant.

> Should something, procps or linux-sysctl-defaults, be watching the sysctl.d
> files
> in their various locations and triggering a sysctl if they change? Or
> should the
> individual packages do it?

I would prefer for procps to do it, since:

- systemd and procps are the only 2 packages that are able to parse and
apply these files.  If neither is installed then nothing can be done
with them, so there is little value in adding such a trigger elsewhere.

- linux-sysctl-defaults is currently optional, as it is only
recommended by systemd and procps.

> Should there be some small script that works out which sysctl to use?
> If there is 'whatever-sysctl-is-here' script, where should it live?
> Or would some wiki entry do it better?

This should be unnecessary if we use triggers.

Ben.

-- 
Ben Hutchings
Once a job is fouled up, anything done to improve it makes it worse.



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

Bug#1085160: linux-sysctl-defaults: apply setting after installation

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2024-10-15 at 19:04 +0300, sergio wrote:
> Package: linux-sysctl-defaults
> Version: 4.10.1
> Severity: normal
> 
> Dear Maintainer,
> 
> please call `sysctl -p /usr/lib/sysctl.d/50-default.conf` after installation

Running that command is definitely not a good idea, as it will ignore
any other configuration files which should override the default
settings.

This was discussed at
<https://salsa.debian.org/kernel-team/linux-base/-/merge_requests/12#note_500942>
and there was a deliberate decision then not to do this.

Noah Meyerhans wrote:
> +1  Not doing so is leading to confusing/broken behavior during
> upgrades.  By deferring the application of the sysctl settings until
> reboot, we're effectively leaving the system in a half-upgraded state
> where applications that depend on sysctls set here will misbehave for
> confusing reasons until a reboot happens.
> 
> See https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1085289 and
> https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1084135 for instances
> of issues caused during upgrades.

So it sounds like we do actually need to apply configuration on
installation, just not precisely as requested.

Looking at the postinst scripts of some other packages that install
sysctl configuration, I can see a diversity of approaches to this:

- bubblewrap runs "sysctl --pattern " which seems
  reasonable for a single sysctl but would be a pain to keep in sync
  with the configuration file.

- tracker-miner-fs runs "systemd-sysctl " which does not
  work without systemd and seems to have the same problem I mentioned
  above.

Whatever is decided for linux-sysctl-defaults should ideally be
implemented consistently across the other packages.

Would this work:

1. As discussed in the GitLab MR, systemd implements a file trigger on
   sysctl configuration files.

2. Either:
   (a) procps implements a similar trigger, but makes it a no-op when
   systemd is pid 1.
   (b) linux-sysctl-defaults postinst does:
   - if systemd is pid 1, nothing;
   - otherwise, if sysctl is installed, "sysctl --system";
   - otherwise, nothing.

?

I don't know how well those file triggers would interact with existing
postinst scripts for the other packages.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.



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

Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap

[Ben Hutchings]

On Sat, 2024-10-19 at 15:35 +0200, Bastian Blank wrote:
> Hi
> 
> On Thu, Oct 10, 2024 at 06:03:24PM +0200, Helmut Grohne wrote:
[...]
> 
> > Ben asked me whether linux-libc-dev could simply support all relevant
> > architectures, but there often is a check&egg problem. The linux package
> > can only support architectures that dpkg knows about, but we want to
> > perform test bootstraps way before adding a triplet to dpkg and one of
> > the first things a test bootstrap does is building linux-libc-dev. So I
> > generally expect that linux-libc-dev can never provide support for all
> > architectures of interest and it shouldn't have to. Only once the
> > bootstrap is tested and the parameters are known do we want to file the
> > patches for a new architecture.
> 
> I have to disagree.  With this setup, we can support architectures that
> are neither known by dpkg nor dak.  This was not possible before and
> required patching, aka making a derivative of the package.  You can
> still patch and rebuild it how you want and inject that modified package
> into your workflow.
[...]

Currently gencontrol.py runs dpkg-architecture to find the multiarch
triplet for each Debian architecture.  So it's not possible to add any
architecture that's unknown to dpkg in unstable.

Are you proposing to extend our config schema so we can define those
triplets within src:linux?

Do we really want to be on the critical path for the early stages of
defining a new architecture, including any renaming that might happen
before it's added to dpkg upstream?


Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.



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

Bug#1084908: arch:all linux-libc-dev causes problems to architecture bootstrap

[Ben Hutchings]

On Sat, 2024-10-19 at 18:15 +0200, Helmut Grohne wrote:
> Hi Bastian,
> 
> On Sat, Oct 19, 2024 at 03:35:21PM +0200, Bastian Blank wrote:
[...]
> 
> > But now you can have a port without hand patched linux that is built in
> > a non-standard way and relying on internal and unstable package API,
> > just be talking and getting it added to the package first.
> 
> Fair enough. Please add arc, cksy, mipsr6el, sh3, sparc, and
> musl-linux-any. Thanks in advance.
[...]

We would need to know the multiarch triplet for csky.

Ben.


-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.



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

Bug#1033058: Booting mini.iso : kernel hangs on ppc64el

[Ben Hutchings]

Control: close -1

On Thu, 2024-10-24 at 00:07 +0530, Aditi Mishra wrote:
> Hello John,
> 
> I'm working on this bug. Surperisingly, on p9 this image is working fine 
> with kernel > 6.8. Looking into p8 issue.
> 
> I'll update regarding this ASP.
> 
> Thanks and regards

As this issue seems to be *caused* by the patch which fixed bug
#1033058, it should not be treated as being a reoccurrence of the same
bug.

I have opened bug #1085949 to track the new issue; please continue
discussion there.

Ben.

-- 
Ben Hutchings
No political challenge can be met by shopping. - George Monbiot



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

Bug#1085949: Installer regression on ppc64el under PowerKVM

[Ben Hutchings]

Package: src:linux
Version: 6.11.4-1

Opening a new bug report for the issue that was added to #1033058:

 Forwarded Message 
From: John Paul Adrian Glaubitz 
To: Frédéric Bonnard 
Cc: Cyril Brulebois , debian-kernel 
, 1033...@bugs.debian.org, debian-powerpc 

Subject: Re: Bug#1033058: Booting mini.iso : kernel hangs on ppc64el
Date: 22/10/24 12:37:13
Message-Id: 

Hello,

I have reopened this bug as this problem even shows on ppc64el again
with the latest netinst daily build downloaded from [1]. I have tested
the image on an IBM 8247-42L inside a PowerKVM virtual machine.

Removing the patch again fixes the problem for me. However, at least on
big-endian ppc64, debian-installer does not accept any keyboard input
after the language menu shows up.

So, either the system has crashed at this point or there is something
wrong with the input device.

Adrian

> [1] 
> https://cdimage.debian.org/mirror/cdimage/daily-builds/sid_d-i/current/ppc64el/iso-cd/

 Forwarded Message 
From: John Paul Adrian Glaubitz 
To: Frédéric Bonnard 
Cc: Cyril Brulebois , debian-kernel 
, 1033...@bugs.debian.org, debian-powerpc 

Subject: Re: Bug#1033058: Booting mini.iso : kernel hangs on ppc64el
Date: 23/10/24 15:57:13
Message-Id: 

Hello,

On Tue, 2024-10-22 at 12:37 +0200, John Paul Adrian Glaubitz wrote:
> I have reopened this bug as this problem even shows on ppc64el again
> with the latest netinst daily build downloaded from [1]. I have tested
> the image on an IBM 8247-42L inside a PowerKVM virtual machine.

Here is a short video which demonstrates the hang:

> https://people.debian.org/~glaubitz/debian-bug-1033058.mp4

This was reproduced using the following installation image:

> https://cdimage.debian.org/cdimage/daily-builds/daily/current/ppc64el/iso-cd/debian-testing-ppc64el-netinst.iso

Thanks,
Adrian



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

Bug#993985: wireguard should not depend on wireguard-dkms now that wireguard is in mainline

[Ben Hutchings]

Given that Wireguard has been upstream since Linux 5.5 (more than 4
years ago), I think it really is time to assume that every kernel has
it and to stop depending (or even recommending) wireguard-modules |
wireguard-dkms.

This is continuing to cause surprising behaviour for users with custom
kernel packages that don't have that magic Provides, as seen in bug
#1085239.

Ben.

-- 
Ben Hutchings
The generation of random numbers is too important to be left to chance.
   - Robert Coveyou



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

Bug#1084791: File conflict between firmware-realtek and firmware-realtek-rtl8723cs-bt

[Ben Hutchings]

On Mon, 2024-10-14 at 05:54 +0200, Bastian Germann wrote:
> Hi Ben,
> I am glad the firmware was added to linux-firmware. In fact, I had submitted 
> the same file in 
> https://lore.kernel.org/linux-firmware/20230320164448.3489-1-b...@debian.org/ 
> but that was ignored. I am going to file a RM Bug for my pkg soon.
> 
> Cheers,
> Bastian

OK, so I guess I can go ahead with adding Conflicts+Replaces in
firmware-realtek.  But it's not clear to me from your answer: have the
files that are now in linux-firmware.git and firmware-realtek been
tested and known to work on the Pinebook?

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.



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

Bug#1084791: File conflict between firmware-realtek and firmware-realtek-rtl8723cs-bt

[Ben Hutchings]

Hi Bastian,

The upstream of firmware-nonfree now includes firmware and config files
for RTL8723CS Bluetooth, added in
<https://gitlab.com/kernel-firmware/linux-firmware/-/commit/ed9c1349f8ebae720f3572ad3e74af59bfe345d7>.
As a result of this, firmware-realtek now has a file conflict with
firmware-realtek-rtl8723cs-bt (bug #1084791).

I would like to make firmware-realtek replace firmware-realtek-
rtl8723cs-bt, if you don't mind that and if it really works as a
replacement.  However, they currently contain different versions of
these files.

In firmware-realtek they are:

rtl_bt/rtl8723cs_xx_config.bin: symlink to:
  rtl_bt/rtl8723bs_config.bin:  size64
rtl_bt/rtl8723cs_xx_fw.bin: size 19732

The commit above says they were extracted from a zip file from
realtek.com with version 1.0.245.3 (05/08/2017).  I couldn't find an
exactly matching zip file, and what I did find appears to be a Windows
installer, so I can't confirm that.

In firmware-realtek-rtl8723cs-bt the files are:

rtl_bt/rtl8723cs_xx_config.bin: size63
rtl_bt/rtl8723cs_xx_fw.bin: size 25004

I wanted to find the versions of these files, so I looked at the
upstream WHENCE file in your package.  This claims the files come from
<https://github.com/armbian/firmware>.  Although the config file in
that repository does match, it has yet another version of the firmware:

rtl_bt/rtl8723cs_xx_fw.bin: symlink to:
  rtlbt/rtl8723cs_xx_fw:size 24020

There is, however, a matching version in
<https://github.com/armbian/build> that was added by
<https://github.com/armbian/build/commit/077a7f8590c2799086bd8818115b10fd4d4423d5>.

But at this point the trail runs out: there is no explanation of which
Realtek or other manufacturer release these blobs came from.  (This
just reinforces my distrust of Armbian.)

In any case, it seems that the files in firmware-realtek-rtl8723cs-bt
may be specific to the Pinebook while those in firmware-realtek are
generic.

Are you able to test whether the files in firmware-realtek work
properly on a Pinebook?  If not, I suppose we will need to keep both
packages around with Conflicts, or use alternatives to manage these
filenames.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin



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

Bug#898336: DL380 instability with hpwdt

[Ben Hutchings]

On Wed, 2024-10-09 at 22:44 -0600, Jerry Hoemann wrote:
[...]
> Questions:
> 1) The Debian bug above mentions only Gen 7 and 8 systems.
>Are you seeing this issue on other ProLiant systems?

Not that I can see in our open bugs.

> 2) You mentioned back-porting commit dced0b3e51dd.  Does your
>drivers/watchdog/hpwdt.c source match upstream Linux? Or
>do you cherry pick patches?  (sorry, not knowing Debian,
>I don't know how find/navigate your kernel source.)
[...]

We follow kernel.org stable branches, with a small number of our own
patches on top.  The latest stable release, Debian 12 "boowkorm", is
following the 6.1.y branch, which included a backport of that fix in
6.1.75.  So far as I can see, none of our own patches have ever touched
hpwdt.c.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin



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

Bug#898336: DL380 instability with hpwdt

[Ben Hutchings]

Hi Jerry,

The Debian kernel team received a number of reports over the past few
years of instability of the Proliant DL380 G7 and DL380p G8, seemingly
related to the hpwdt driver (in that this goes away if it is not
loaded).  These reports can be seen at
<https://bugs.debian.org/898336>.

The instability has been seen with kernel versions ranging from 4.16 to
6.1.y, including after the backport of commit dced0b3e51dd
"watchdog/hpwdt: Only claim UNKNOWN NMI if from iLO").

I can see that hpwdt seems to be used for error reporting so it's not
clear to me whether these are problems caused by the driver, or the
driver is only reporting that something bad happened.

Do you have any ideas about what's going wrong here?  Is there
something odd about these models that needs to be handled in hpwdt, or
are they just popular models?

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.



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

Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

On Wed, 2024-08-07 at 00:07 -0400, Bud Heal wrote:
> Ben Hutchings wrote:
> > On Tue, 2024-06-04 at 06:51 -0400, Bud Heal wrote:
> > > I filled up the (micro)SDs, including the current one I have been scanning
> > > into, the one that I set aside as probably defective and the pair I bought
> > > for testing. I will append the bash script.
> > I appreciate that you've scripted this, but you missed step 2: remove
> > and reinsert the card.  Without that, the script may just be reading
> > files out of the cache if your system has enough RAM.
> Do I read this clearly enough - that you have not tried this either? I 
> gave bug reports mentioning three devices - a scanner saving to a 
> microSD, a builtin SD read/writer, and transfer to Windows 10 to 
> confirmation and comparison, innumerable times.

But no-one else has reported similar issues, and I don't have the same
devices, which is why I kept asking you to run tests.

I have now tried reproducing this with my own microSD card and reader,
and didn't see this problem.

> Simply removing and reinserting the microSC card can lead to 
> irrecoverable corruption requiring a reformat. At best it will lead to 
> loss of the last set of scans, prior to inserting the card into the 
> Debian system.
[...]
> > So one or both of:
> > 
> > - A change in the way this newer version of GNOME (or whichever desktop
> > environment you're using) does thumbnail generation
> > - Using USB storage instead of an SD controller
> > 
> > mitigates the problem, but we don't know which.
> Using USB storage does not mitigate the problem. You have a bug 
> corrupting a file system and losing data for an unwary user.

I was not suggesting that this was a practical mitigation.  I am trying
to understand what the exact conditions are for this issue to occur.

> There may 
> be a patch ready to be backported in the latest version, but that is not 
> mine to know. I have given you all that is needed to replicate the 
> problem. Fill a device full enough to let you open a folder while it is 
> generating thumbnails, and test, or not.
> 

But I couldn't replicate the problem.

At this point I think it would be helpful to get disk images of a card
that shows this issue:

1. Erase a card completely, to avoid private data being included in the
images.
2. Use the scanner to format and add some non-sensitive images to the
card.
3. Insert the card into a Linux system with automounting disabled (i.e.
no desktop running).
4. Use dd and gzip to create an image of the card before corruption.
5. Start the desktop and verify that the card does gets corrupted from
the state that was imaged.  If not, go back to step 2.
6. Use dd and gzip to create an image of the card with corruption.

I'm guessing the disk images are going to be rather large, in which
case they should not be attached to this bug report.  I can send you a
link privately to upload them.

Ben.

-- 
Ben Hutchings
Klipstein's 4th Law of Prototyping and Production:
   A fail-safe circuit will destroy others.



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

Bug#1084232: initramfs-tools: fails with "No space left on device" due to 2 temporary initrd copies in /boot

[Ben Hutchings]

On Tue, 2024-10-08 at 03:41 +0200, Vincent Lefevre wrote:
> On 2024-10-07 21:23:40 +0200, Ben Hutchings wrote:
> > Control: tag -1 moreinfo
> > 
> > On Mon, 2024-10-07 at 00:39 +0200, Vincent Lefevre wrote:
> > > Package: initramfs-tools
> > > Version: 0.145
> > > Severity: normal
> > > 
> > > When updating an initrd file, update-initramfs keeps 2 temporary
> > > copies in /boot,
> > 
> > I don't believe this is the case.  A successful run of
> > "update-initramfs -u" will do:
> > 
> > 1. Hard-link initrd.img- to initrd.img-.dpkg-bak
> > 2. Create new initramfs as initrd.img-.new
> > 3. Move initrd.img-.new to initrd.img-
> > 4. Remove initrd.img-.dpkg-bak (unless backup_initramfs is
> >enabled)
> > 
> > There is 1 temporary copy created in step 2, and after step 4 there are
> > 0 temporary copies.
> > 
> > Step 1 does have a fallback to copying if hard-linking fails.  That
> > could happen if your /boot uses VFAT or some other un-Unix-like
> > filesystem, but that's not supported by Debian.  But maybe there's some
> > other reason it can fail?
> 
> Indeed, with 3 installed kernels:
> 
> Filesystem  Size  Used Avail Use% Mounted on
> /dev/nvme0n1p2  456M  295M  137M  69% /boot
> 
> So there isn't enough space for a 4th kernel + a temporary copy
> (90 MB each at maximum compression + 9 MB for the vmlinuz file).

OK.   But 'apt autoremove' should normally remove one of the old
kernels.

And I don't see how this answers my question about the claim of 2
temporary copies.

> 
> > > though its space is typically *very* limited
> > > (456 MB by default). This means that one can keep a limited number
> > > of kernels. With the 456 MB default size and maximum compression
> > > (COMPRESS=lzma and COMPRESSLEVEL=9), only 3 kernels are possible.
> > > 
> > > The temporary copies should be stored on the main file system,
> > > which is not space limited.
> > [...]
> > 
> > The initramfs must be replaced atomically, otherwise we can end up with
> > a previously working image being deleted or replaced with a truncated
> > image.  So there has to be 1 temporary copy.
> 
> The temporary copy could be on the main file system. The goal is
> anyway to keep *at least* an additional working kernel in /boot
> in case the rebuild of the kernel gets broken (which cannot be
> detected until booting on this kernel). So, if anything goes wrong
> (either at install time or when booting on the rebuilt kernel), it
> is possible to boot on the working kernel to fix things.

Unfortunately there is currently nothing with that global view of which
kernel and initramfs images are known good.

Also, if we delete an initramfs before rebuilding it, we should remove
that kernel/initramfs from the boot menu until it's been rebuilt, but
there's currently no mechanism to do that.

I do see a need here for a proper re-think of the way we manage kernel
and initramfs images in /boot, but this is not something that can be
done through a quick fix in initramfs-tools.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#1084232: initramfs-tools: fails with "No space left on device" due to 2 temporary initrd copies in /boot

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 2024-10-07 at 00:39 +0200, Vincent Lefevre wrote:
> Package: initramfs-tools
> Version: 0.145
> Severity: normal
> 
> When updating an initrd file, update-initramfs keeps 2 temporary
> copies in /boot,

I don't believe this is the case.  A successful run of
"update-initramfs -u" will do:

1. Hard-link initrd.img- to initrd.img-.dpkg-bak
2. Create new initramfs as initrd.img-.new
3. Move initrd.img-.new to initrd.img-
4. Remove initrd.img-.dpkg-bak (unless backup_initramfs is
   enabled)

There is 1 temporary copy created in step 2, and after step 4 there are
0 temporary copies.

Step 1 does have a fallback to copying if hard-linking fails.  That
could happen if your /boot uses VFAT or some other un-Unix-like
filesystem, but that's not supported by Debian.  But maybe there's some
other reason it can fail?

> though its space is typically *very* limited
> (456 MB by default). This means that one can keep a limited number
> of kernels. With the 456 MB default size and maximum compression
> (COMPRESS=lzma and COMPRESSLEVEL=9), only 3 kernels are possible.
> 
> The temporary copies should be stored on the main file system,
> which is not space limited.
[...]

The initramfs must be replaced atomically, otherwise we can end up with
a previously working image being deleted or replaced with a truncated
image.  So there has to be 1 temporary copy.

Ben.

-- 
Ben Hutchings
I'm not a reverse psychological virus.
Please don't copy me into your signature.



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

Bug#1082906: linux-image-6.11-amd64: ipu6 camera is not working

[Ben Hutchings]

On Sat, 28 Sep 2024 03:09:54 + gabriel  wrote:
> Package: src:linux
> Version: 6.11-1~exp1
> Severity: normal
> 
> Dear Maintainer,
> 
> 
> ipu6 mipi camera drivers were not part of previous kernels, now they have been
> upstreamed.
> After upgrading kernel to 6.11 the ipu6 kernel modules are loaded, however
> there are 32 video devices /dev/video0 to /dev/video32 and none of them is
> working  (gstreamer, vlc, firefox or cheese)
[...]
> ** Model information
> sys_vendor: Dell Inc.
> product_name: XPS 9320
[...]

With IPU6-based cameras a separate driver is needed for the camera
sensor.  Based on <https://hansdegoede.dreamwidth.org/28841.html> I
think this model needs the ov13b10 sensor driver which we don't yet
enable.  We should enable at least all the sensor drivers listed there.

Ben.

-- 
Ben Hutchings
We get into the habit of living before acquiring the habit of thinking.
 - Albert Camus



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

Bug#1082647: copy_exec: [regression] ignores trailing slash, installs file as directory name

[Ben Hutchings]

On Tue, 2024-09-24 at 17:16 +0200, Thorsten Glaser wrote:
> On Tue, 24 Sep 2024, Ben Hutchings wrote:
> 
> > I suppose I can make this work again for bookworm, but I won't do so
> > for unstable.
> 
> Then, perhaps issue a visible warning so that people can change
> their scripts?

Yes.

> > This was not an intended feature.  When specifiing a diectory as the
> > target you are supposed to ensure that it already exists under
> > ${DESTDIR}.  It seems that this just happened to work when the target
> > name ended in a slash.
> 
> Hmmh, but this is used in so many other places, e.g. dh_install
> does that, and many of the other scripts also don’t place filenames
> after directories, they are just lucky that the directories exist
> then.
> 
> But, wait, copy_exec *DOES* create missing directories, so this
> *does* look like intended behaviour to me…

There used to be a comment explaining this:

# $1 is the source path (e.g. /usr/bin/time)# $2 is the relative destination 
(e.g. /usr or /usr/time)
#
# The destination is interpreted in the same way "cp" would, meaning
# (assuming /bin is a directory):
#
#   "copy_exec /usr/bin/time /bin"-> /bin/time
#   "copy_exec /usr/bin/time /bin/mytime" -> /bin/mytime
# 
# If $2 is left out, the same destination path as for the source arg will
# be used and directories will be created as needed, so:
#
#   "copy_exec /usr/bin/time" -> /usr/bin/time

but that was lost somewhere along the way.

> > The changes in the last point release to avoid duplicating files
> > accessed via directory symlinks broke that because realpath strips the
> > trailing slash.
> 
> Hmh.
> 
> IMHO we have two ways we can go from here (also towards sid).
> 
> One, repair this. If there is a trailing slash, it’s supposed
> to be placed into that directory, then create that if missing.
> That is, make bullseye’s behaviour the intended one.

Now that I've tested, I see that this has worked since at least squeeze
(that's the oldest image I have available).  So I'm now leaning towards
restoring and documenting it.

> Two, say people are expected to create the directories first.
> But in that case, copy_exec also must not create any missing
> directories any more *at all*,

No, it was documented to do that for the case where no target argument
was given, and changing that would likely cause widespread breakage.

> and additionally, if the target
> ends in a slash in the argv (i.e. before realpathisation), it
> still must be interpreted as the name of a directory (or symlink
> to a directory), so that copying to '/usr/libexec/' will either
> work (if pre-created) or fail (if not pre-created).

I agree that we mustn't create the target filename as a regular file if
it originally ended with a slash.

Ben.

> These two
> are needed for consistency and to have a sensitive failure mode
> for users’ scripts, as opposed to create /usr/libexec as file.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.



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

Bug#1082647: copy_exec: [regression] ignores trailing slash, installs file as directory name

[Ben Hutchings]

Control: tag -1 confirmed
Control: affects -1 release.debian.org

On Tue, 2024-09-24 at 02:46 +0200, Thorsten Glaser wrote:
> Package: initramfs-tools-core
> Version: 0.142+deb12u1
> Severity: serious
> Justification: hidden breakage for users, ought to be fixed in stable-pu
> X-Debbugs-Cc: t...@mirbsd.de
> 
> In bullseye, this would work:
> 
> copy_exec /usr/lib/klibc/bin/rnd_shuf /usr/libexec/
> copy_exec /usr/sbin/rdate /usr/libexec/
[...]

This was not an intended feature.  When specifiing a diectory as the
target you are supposed to ensure that it already exists under
${DESTDIR}.  It seems that this just happened to work when the target
name ended in a slash.

The changes in the last point release to avoid duplicating files
accessed via directory symlinks broke that because realpath strips the
trailing slash.

I suppose I can make this work again for bookworm, but I won't do so
for unstable.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.



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

Bug#1082001: linux-image-6.1.0-25-amd64: TOMOYO LSM rejects execveat(AT_EMPTY_PATH) inside chroot

[Ben Hutchings]

Control: tag -1 upstream

On Tue, 2024-09-17 at 01:45 +0200, Alfred Agrell wrote:
> Package: src:linux
> Version: 6.1.106-3
> Severity: normal
> X-Debbugs-Cc: blub...@gmail.com
> 
> Dear Maintainer,
> 
> Please run the following program (as root, so the chroot succeeds):
> 
> 
> #define _GNU_SOURCE
> #include 
> #include 
> #include 
> 
> int main(int argc, char** argv)
> {
> chdir("/lib/");
> if (chroot("/lib/") != 0)
> perror("chroot (needs root)");
> execveat(open("./x86_64-linux-gnu/ld-linux-x86-64.so.2", O_RDONLY), 
> "", NULL, NULL, AT_EMPTY_PATH);
> perror("execveat");
> }
[...]

When you pass an fd other than AT_FDCWD to execveat(), the fd and
filename are translated internally to a filename starting with
"/dev/fd/".  It's noted in the manual page that this affects the way
script interpreters are called.  Another consequence is that when
TOMOYO tries to look up that filename it finds that it does not exist.
I verified that if /dev and /proc are mounted in the chroot your test
program works.

This isn't a high priority for us, but if you report this upstream it
might be fixed.  You'll need to subscribe to the TOMOYO mailing list at
<https://lists.osdn.me/mailman/listinfo/tomoyo-users-en> and then send
your report there.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.



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

Bug#1041484: kernel: hpet_acpi_add: no address or irqs in _CRS

[Ben Hutchings]

On Wed, 2023-07-19 at 15:04 +, Al Ma wrote:

> Package: linux-image-6.1.0-10-amd64
> Version: 6.1.37-1
> In the journal of a laptop Lenovo ThinkPad T14s Gen1, connected to a docking 
> station ThinkPad Thunderbolt 3 Dock Gen 2/Workstation Dock Gen 2 Type 40 AN 
> (which is powered by a 135 W AC Adapter ADL135NCC3A) and to a monitor Philips 
> 275B1 via a HMDI cable, we discovered the following warning (last line is 
> yellow) generated at boot:
[...]

> Jul 19 16:20:34 AnonymizedLenovoThinkPadT14s kernel: hpet_acpi_add: no 
> address or irqs in _CRS
[...]

This was also reported as appearing on Lenovo ThinkPad T14 gen 4
running Linux 6.10.  I searched for the warning on lore.kernel.org and
found that it also appeared on:

- Dell XPS 13 9360/0596KF, Linux 6.9-6.11
- Intel NUC12WSHi7/NUC12WSBi7, Linux 6.11
- Lenovo IdeaPad 82MG, Linux 6.1
- Lenovo ThinkPad T480, Linux 6.10
- System76 Pangolin, Linux 6.11

Is this likely to be a bug in the driver, or in the firmware?  If this
is a common case where the HPET isn't available and has an incomplete
description in the ACPI table, should the warning message be downgraded
to info level?

Ben.


-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

[Dropped leader@ and community@]

On Thu, 2024-09-12 at 00:38 +0200, Ben Hutchings wrote:
> On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> [...]
> > My answers below are mine alone.  I have not discussed this with other
> > team members and do not speak for them.
> > 
> > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > > Hello kernel maintainers,
> > > 
> > > While potential solutions to this bug are being discussed, would you
> > > please consider removing the Provides from linux-libc-dev?
> > 
> > I am open to doing so.
> [...]
> 
> I raised this at today's team meeting and it was agreed to do this; see
> <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1198>.

This change is included in version 6.11-1~exp1 which I am uploading to
experimental.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


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

Bug#1082026: ITP: aider -- CLI tool for pair programming with LLMs.

[Ben Hutchings]

On Tue, 2024-09-17 at 20:37 +0300, Ahmed Siam wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ahmed Siam 
> X-Debbugs-Cc: aahs.co...@gmail.com, o...@debian.org, 
> debian-de...@lists.debian.org, debian-pyt...@lists.debian.org
> 
> * Package name: aider
>   Version : 0.56.0
>   Upstream Contact: Paul Gauthier 
> * URL : https://aider.chat/
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : CLI tool for pair programming with LLMs.
> 
> You can use Aider to edit code in your local git repository by
> running Aider with files you want to edit and asking for changes
> like:
> - Add new features.
> - Describe a bug.
> - Refactor code.
> - Update docs.
> 
> Then Aider will edit your files to complete your request and
> git commit changes with a sensible commit message.
[...]

This is not pair programming.  In pair programming the two programmers
are supposed to discuss what they're doing and learn from each other. 
This is just a way to generate boilerplate with subtle bugs and
possible licensing issues.

See:
- https://arxiv.org/pdf/2401.15232
- https://arxiv.org/pdf/2211.03622

Ben.

-- 
Ben Hutchings
I'm always amazed by the number of people who take up solipsism because
they heard someone else explain it. - E*Borg on alt.fan.pratchett



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

Bug#1081563: Please consider adding the new Xe Graphics driver for Intel GPUs

[Ben Hutchings]

On Sun, 2024-09-15 at 21:27 +0200, Petter L. H. Eide wrote:
> My understanding is that it is possible to manually trigger the binding (by
> adding eg. i915.force_probe=!56a0 xe.force_probe=56a0 as kernel
> parameters). Would the fact that its does not bind to hardware by default
> not mitigate the experimentalness somewhat?
[...]

It mitigates the risk but I'm not sure it will stop people sending us
bug reports about the driver when it turns out not to work for them.

Ben.

-- 
Ben Hutchings
If the facts do not conform to your theory, they must be disposed of.



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

Bug#1081563: Please consider adding the new Xe Graphics driver for Intel GPUs

[Ben Hutchings]

Control: notfound -1 6.10.9
Control: found -1 6.10.9-1

On Thu, 2024-09-12 at 21:35 +0200, Petter L. H. Eide wrote:
> Package: src:linux
> Version: 6.10.9
> Severity: wishlist
> 
> Dear Maintainer,
> 
> Since kernel 6.8, the xe driver for intel GPUs has been available as a kernel 
> module. Please consider including this by enabling CONFIG_DRM_XE. 
> See following references for more information:
[...]

This driver is still experimental and it doesn't bind to any devices by
default.  We probably won't enable it until that changes.

Ben.

-- 
Ben Hutchings
Larkinson's Law: All laws are basically false.



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

Bug#1081751: RM: linux-signed-i386 -- ROM; no longer built from linux

[Ben Hutchings]

Package: ftp.debian.org
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org
User: ftp.debian@packages.debian.org
Usertags: remove

The linux-signed-i386 source package was previously generated from
linux via the signing service.  This is no longer being done, and
linux-signed-i386 hasn't been updated for ¬9 months.  There is no plan
to reverse this; in fact we will soon remove all the i386 kernel
packages.

Please remove linux-signed-i386.

Ben.

Bug#1081546: new "GPU HANG: ecode 12:1:85dffdfb, in Renderer" regression in i915 driver since 6.10 kernel upgrade

[Ben Hutchings]

Control: tag -1 upstream moreinfo

On Thu, 2024-09-12 at 12:07 -0400, Antoine Beaupre wrote:
[...]
> I believe there's a regression in the i915 driver that came with
> 6.10. According to this article:
> 
> https://www.phoronix.com/news/Linux-6.10-Intel-Xe-DRM-Patches
> 
> "Intel Has Many Improvements For The Xe Graphics Driver In Linux
> 6.10"... So I suspect I might have tripped on one of
> those... uh... "improvements".
[...]

The i915 and xe drivers are separate.  The xe driver is still
experimental and we don't enable it.

Please test the latest unstable version (6.10.9-1) to see whether this
has been fixed.

If not, please report the bug upstream, following
<https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html>.
We don't patch the i915 driver or drm core, so it should be OK to do so
even though you are running a distribution kernel.

Let us know the upstream bug URL so we can track it.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman



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

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

On Thu, 2024-09-12 at 12:19 +0200, Helmut Grohne wrote:
> Hi Ben,
> 
> Dropping leader@ and community@ from Cc as this is a technical
> side-track.
> 
> On Thu, Sep 12, 2024 at 12:38:24AM +0200, Ben Hutchings wrote:
> > On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
> > [...]
> > > My answers below are mine alone.  I have not discussed this with other
> > > team members and do not speak for them.
> > > 
> > > On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > > > Hello kernel maintainers,
> > > > 
> > > > While potential solutions to this bug are being discussed, would you
> > > > please consider removing the Provides from linux-libc-dev?
> > > 
> > > I am open to doing so.
> > [...]
> > 
> > I raised this at today's team meeting and it was agreed to do this; see
> > <https://salsa.debian.org/kernel-team/linux/-/merge_requests/1198>.
> 
> Thank you.
> 
> I note that these provides (while causing problems) also solved one
> problem that now reappears. linux-libc-dev is marked `Multi-Arch:
> foreign`, but this technically is a lie. It does not provide
> linux-libc-dev for all architectures - not even for all linux-any
> architectures and never will.
[...]

It is trivial for us to add support for additional architectures once
they are minimally supported in upstream Linux (we may also require
that dpkg recognises their triplet; I'm not sure).  There is no
requirement that we define a kernel configuration for the architecture
at the same time, or ever (see x32).

Can we assume that new Debian Linux ports will be able to satisfy that
or would that be a problem sometimes?


Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


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

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

On Mon, 2024-09-09 at 02:13 +0200, Ben Hutchings wrote:
[...]
> My answers below are mine alone.  I have not discussed this with other
> team members and do not speak for them.
> 
> On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> > Hello kernel maintainers,
> > 
> > While potential solutions to this bug are being discussed, would you
> > please consider removing the Provides from linux-libc-dev?
> 
> I am open to doing so.
[...]

I raised this at today's team meeting and it was agreed to do this; see
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/1198>.

Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


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

Bug#1081356: Configuration changes for linux-6.1 in bullseye-security

[Ben Hutchings]

Package: ftp.debian.org
Severity: important
X-Debbugs-Cc: debian-...@lists.debian.org

As with earlier releases that had LTS, I'm trying to add a backported
kernel version to bullseye-security now that bullseye-backports is
closed.

This will need some configuration changes in dak and the signing
service:

- dak should allow source-only uploads of linux-6.1 and
  linux-signed-6.1-{amd64,arm64,i386} even when they will go into the
  NEW queue.

- The signing service should be configured to process source package
  linux-6.1.  (And it no longer needs to process linux-5.10.)

Ben.

Bug#1080975: upgrade 6.1.106 to 6.10.6 failed

[Ben Hutchings]

On Mon, 2024-09-09 at 08:38 +0200, Harald Dunkel wrote:
> On 2024-09-06 19:10:49, Ben Hutchings wrote:
> > 
> > The kernel doesn't "support" any of these names; that's all done by
> > udev.  I'm reassigning this accordingly.
> > 
> 
> Thank you.
> 
> If I got this correctly the bug is already in udev for stable? I
> was lucky I haven't had any new drivers supporting devlink for
> Bookworm?

Apparently so.

Ben.

-- 
Ben Hutchings
If more than one person is responsible for a bug, no one is at fault.



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

Bug#1081310: Wired ethernet connection disabled.

[Ben Hutchings]

Control: found -1 5.10.218-1

On Tue, 2024-09-10 at 21:22 +0300, Βασίλειος A. Ζοῦκος wrote:
> Attached the file: kern.log.gz
>   Thanks for the prompt responce

- The Ethernet driver in question is sky2, which hasn't changed between
  these versions.
- There are 4 boots logged with the new kernel version, and in 1 case
  the "No irq handler for vector" error appears.
- There are 2 boots logged with the old kernel version, and in both
  cases the "No irq handler for vector" error appears.
- In all boots the Ethernet link is reported as up soon after boot,
  though it's sometimes a bit wobbly (with both old and new version).

So I'm not convinced that there's a regression here.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#1081195: devscripts: test-patches KeyError: 'pae'

[Ben Hutchings]

Control: tag -1 confirmed

On Mon, 09 Sep 2024 10:57:39 +0300 Martin-Éric Racine 
 wrote:
> It appears that test-patches makes incorrect guesses for the target 
> architecture:
> 
> $ debian/bin/test-patches  306803.patch 
[...]
>   File "/home/perkelix/linux-6.10.6/debian/bin/debian_linux/config_v2.py", 
> line 543, in flavours
> debianarch_flavour=debianarch_flavour[flavour.name],
>~~^^
> KeyError: 'pae'
> make: *** [debian/rules:149: debian/control-real] Virhe 1
> 
> 
> By the looks of it, it truncates anything after the last dash of the running 
> kernel,
> which results in it trying to configure for flavor=pae instead of the expected
> flavor=686-pae.

This is annoyingly difficult to get right, as older kernel release
strings with an ABI number that needs to be stripped off while newer
kernel release strings with no ABI number but may have a number at the
start of the flavour.  Having said that, I don't see us ever having an
ABI number as high as 686 so that could be special-cased.

Until this is fixed you can use the -f option to explicitly specify the
flavour to build.

Ben.

-- 
Ben Hutchings
A free society is one where it is safe to be unpopular.
  - Adlai Stevenson



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

Bug#1065416: Bastian's offer in #1065416

[Ben Hutchings]

Hello Stefano, Matthias, Andreas, and other committee members,

I apologise for taking so long to respond to this issue.  I missed the
beginning of it as I did not have much time for Debian in February and
March this year.  I've been aware of it in recent months it but until
today I had not gone back and read through the full conversation.

My answers below are mine alone.  I have not discussed this with other
team members and do not speak for them.

On Wed, 2024-09-04 at 15:30 +0200, Stefano Rivera wrote:
> Hello kernel maintainers,
> 
> While potential solutions to this bug are being discussed, would you
> please consider removing the Provides from linux-libc-dev?

I am open to doing so.

> They can be re-instated again later, in combination with the requested
> symlinks, or the binary package can be transitioned to
> cross-toolchain-base, or some other solution found. I would hope that we
> can figure out the future of this package, without leaving
> cross-building broken.
> 
> Last month, Sean asked you:
> 
> > In [1], Bastian proposes that Matthias  take over the
> > linux-libc-dev binary package, building it from one of the crossbuilding
> > source packages he maintains.  Different people have been reading
> > Bastian's e-mail differently as to whether it was a serious proposal for
> > how to resolve the dispute, or just a rhetorical device Bastian was
> > using to make a point.
> > 
> > In any case, doko is among those who took the offer seriously.
> > 
> > In two messages written today, Bastian appears to say both that he
> > is okay with resolving the dispute that way, and also that he is not.
> > 
> > I am writing seeking some clarity.  What is the team consensus on this?
> > Is this something you are happy to do, would consider doing, or is it
> > off the table?  That would help us see where we are.

Since the Linux UAPI headers originate with Linux upstream, I think it
makes most sense for the linux source package to remain the primary
source for them in Debian.  If I understand correctly, no-one has
claimed that linux-libc-dev is causing problems other than through the
disputed Provides field.

I also don't see any convincing reason why linux-libc-dev and linux-
libc-dev-*-cross cannot continue to be built by different source
packages.  I recognise that there is some duplication that could be
avoided by building them together and having the -cross packages
contain only symlinks, but in my experience of cross-building for
embedded systems an extra few megabytes on the build system is in the
noise.

Kind regards,
Ben.

-- 
Ben Hutchings - Debian developer, member of kernel, installer and LTS
teams


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

Bug#1080975: upgrade 6.1.106 to 6.10.6 failed

[Ben Hutchings]

Control: reassign -1 udev

On Fri, 2024-09-06 at 10:19 +0200, Harald Dunkel wrote:
> Package: linux-image-amd64
> Version: 6.10.6-1
> 
> Upgrading from 6.1.106 to 6.10.6 failed, because some network
> interfaces changed their names, eg.
> 
>   enp49s0f1 --> enp49s0f1np1
[...]

This is a result of:

- The i40e driver adding support for the devlink_port API
- udev adding the port number from the devlink_port API in the
  device name even though there is only port per PCI function

[...]
> I would suggest to support the old-style names ("enp49s0f1")
> in parallel to the new names.

The kernel doesn't "support" any of these names; that's all done by
udev.  I'm reassigning this accordingly.

Ben.

-- 
Ben Hutchings
Time is nature's way of making sure that
everything doesn't happen at once.



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

Bug#1076555: linux-image-6.9.9-amd64: boot crash RIP: 0010:kmem_cache_alloc

[Ben Hutchings]

On Mon, 2024-09-02 at 13:33 +0200, Patrice Duroux wrote:
> Hi Ben,
> 
> Le lun. 2 sept. 2024 à 00:59, Ben Hutchings  a écrit :
[...]
> > - There is a newer kernel version available in unstable now (6.10.6 or
> > maybe 6.10.7 by the time you read this).  Does that fix the issue?
> 
> Since then, I have upgraded and am now using the 6.11.x series from 
> experimental
> without experiencing this issue anymore.

That's good news!  But 6.11 will not reach unstable for a few weeks.

> > - Do these same error messages appear on every boot?
> 
> Often, but not always. I was also not sure if it could be related to #1076561
> that I had seen pass by at the same time.

I don't see any connection with that bug.

> > - If you prevent the dell_wmi_sysman module loading, by adding
> > "blacklist=dell_wmi_sysman" to the kernel command line, do all of the
> > error messages stop appearing?
> 
> Would you like me to reinstall one of those kernel versions so as to
> reproduce this issue
> and try adding the option?

Yes please.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine



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

Bug#1075855: Kernel panic caused by aacraid module prevents normal boot

[Ben Hutchings]

On Wed, 2024-09-04 at 11:18 +0300, Michael Gordon wrote:
> Dear all,
> I couldn't test Ben's patch yet, because the server machine had to be
> online. Now it is possible to pull the server out of rack for several days.
> I'll check if the patch is working and let you know.

Remember that the patch I wrote is only intended to fix the crash (bug
2).  The probe failure of aacraid (bug 1) is still a mystery.

> Since I've never messed with linux kernel compilation before, I'm relying
> on this guide https://passthroughpo.st/patch-kernel-debian . It suggests
> using a *patch -p1* instead of *debian/bin/test-patches* , *quilt *or
> *dquilt*. Or maybe it is easier to add two lines by hand.

The Debian Kernel Handbook
<https://kernel-team.pages.debian.net/kernel-handbook/> is an official
guide maintained by the Debian kernel team (mostly me), and I would
recommend that over the blog you found.

The problem with test-patches that I mentioned earlier has been fixed.

> I've also noticed a Greg's message 
> suggesting to apply this patch to all kernel versions including 5.15. Not
> sure if the result of the patch could be observed on versions 5.15.*
> 
[...]

The crash bug was introduced way back in Linux 2.6.15, which is why my
fix was applied to all supported versions.

Ben.

-- 
Ben Hutchings
Theory and practice are closer in theory than in practice - John Levine



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

Bug#980555: Missing ec_sys module

[Ben Hutchings]

Control: tag -1 patch

I opened an MR for this change at
<https://salsa.debian.org/kernel-team/linux/-/merge_requests/1182>.

Ben.

-- 
Ben Hutchings
The two most common things in the universe are hydrogen and stupidity.



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

Bug#1076555: linux-image-6.9.9-amd64: boot crash RIP: 0010:kmem_cache_alloc

[Ben Hutchings]

Control: tag -1 moreinfo

On Mon, 29 Jul 2024 18:07:37 +0200 Patrice Duroux
 wrote:
> Hi Bastian,
> Sorry I probably did something wrong with gnome-logs. Let's go then
> with journalctl
> and here are attached the complete log files, or at least I hope so!
[...]

OK, so we have:

> WARNING: CPU: 11 PID: 541 at mm/page_alloc.c:4556 __alloc_pages+0x2a3/0x340

This means something tried to allocate a chunk of kernel memory that is
larger than the kernel page allocator supports.

[...]
>  acpi_ds_build_internal_buffer_obj+0xa5/0x170
>  acpi_ds_eval_data_object_operands+0x13a/0x140
>  acpi_ds_exec_end_op+0x440/0x500
>  acpi_ps_parse_loop+0xfb/0x6b0
>  acpi_ps_parse_aml+0x80/0x3d0
>  acpi_ps_execute_method+0x13f/0x270
>  acpi_ns_evaluate+0x128/0x2d0
>  acpi_evaluate_object+0x14d/0x2f0
>  __query_block+0x10a/0x1e0 [wmi]
>  wmi_query_block+0x88/0xd0 [wmi]
>  init_bios_attributes.part.0+0x55/0x2f0 [dell_wmi_sysman]
>  sysman_init+0x158/0xff0 [dell_wmi_sysman]
>  ? __pfx_sysman_init+0x10/0x10 [dell_wmi_sysman]
>  do_one_initcall+0x58/0x320
>  do_init_module+0x60/0x240
>  init_module_from_file+0x89/0xe0
>  idempotent_init_module+0x120/0x2b0
>  __x64_sys_finit_module+0x5e/0xb0

That happened during initialisation of the dell_wmi_sysman module.

[...]
> general protection fault, probably for non-canonical address 
> 0x800771b66d9d7272:  [#1] PREEMPT SMP NOPTI
> CPU: 11 PID: 521 Comm: (udev-worker) Tainted: GW  
> 6.9.10-amd64 #1  Debian 6.9.10-1
> Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.32.0 04/01/2024
> RIP: 0010:kmem_cache_alloc_node+0xed/0x360
[...]
> general protection fault, probably for non-canonical address 
> 0x800771b66d9d7272:  [#2] PREEMPT SMP NOPTI
> CPU: 11 PID: 696 Comm: fsck.ext4 Tainted: G  D W  6.9.10-amd64 #1 
>  Debian 6.9.10-1
> Hardware name: Dell Inc. Precision 7540/0T2FXT, BIOS 1.32.0 04/01/2024
> RIP: 0010:kmem_cache_alloc+0xd7/0x340
[...]

Then later on the kernel heap allocation crashes, suggesting memory
corruption.  Maybe related to the first failure, maybe not.

- There is a newer kernel version available in unstable now (6.10.6 or
maybe 6.10.7 by the time you read this).  Does that fix the issue?

- Do these same error messages appear on every boot?

- If you prevent the dell_wmi_sysman module loading, by adding
"blacklist=dell_wmi_sysman" to the kernel command line, do all of the
error messages stop appearing?

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.



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

Bug#1062421: linux-image-6.5.0-5-686-pae: [iwlegacy] kernel oops

[Ben Hutchings]

Control: tag -1 patch

I attached a patch to the upstream bug report.  I am not able to test
it myself.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1078997: gretap tunnel with checksum enabled: some packets have zero checksum

[Ben Hutchings]

On Mon, 26 Aug 2024 19:11:50 +0300 =?utf-
8?B?0KDQvtC80LDQvSDQnNC10YnQtdGA0Y/QutC+0LI=?=
 wrote:
> Updated kernel to version 6.9.7+bpo and iproute2 package to version
6.9.0-1~bpo12+1 on both servers, the bug is still reproduced:
> 
> user@potok2:~$ sudo tcpdump -e -n -v -xx -i ens5f0
[...]

Please send the output of:

ethtool -k ens5f0 | grep tx-gre-csum-segmentation

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1079536: linux-image-6.9.7+bpo-amd64: debian linux-image-amd64 / 6.9.7+bpo video problems on multiheaded Intel ARC 380

[Ben Hutchings]

Control: tag -1 upstream moreinfo

On Sat, 2024-08-24 at 07:41 -0400, William Yang wrote:
> Package: linux-image-6.9.7+bpo-amd64
> Version: 6.9.7-1~bpo12+1
> Severity: important
> X-Debbugs-Cc: wyang-deb...@wdyllc.com
> 
> Dear Maintainer,
> 
> I am a moderately new Debian user with some UNIX and Linux experience.
> 
> Several months ago, I replaced my video card with a multihead card based on an
> ARC A380 chipset, which I use do drive dual 4KUHD monitors.  In order to get
> this to functionality working, I needed to move to a backported kernel to get
> proper driver support. I used the command:
> 
>   sudo apt-get install -t bookworm-backports --install-recommends linux-image-
> amd64
> 
> I recognize that this set me up to receive future kernel updates as well.  A
> number of kernels, over several months worked correctly when added with "apt-
> get dist-upgrade":
> 
> * linux-image-6.5.0-0.deb12.1-amd64:amd64 (6.5.3-1~bpo12+1)
> * linux-image-6.5.0-0.deb12.4-amd64:amd64 (6.5.10-1~bpo12+1)
> * linux-image-6.6.13+bpo-amd64:amd64 (6.6.13-1~bpo12+1)
> * linux-image-6.7.12+bpo-amd64:amd64 (6.7.12-1~bpo12+1)
> 
> However, the most recent image (linux-image-6.9.7+bpo-amd64:amd64
> (6.9.7-1~bpo12+1)) introduced a problem for my A380 card.
[...]

Can you test whether this is resolved with the latest backports version
(linux-image-6.10.6+bpo-amd64)?

If not, please report the issue upstream, following
<https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html>.
Note that we don't make any changes to the drm subsystem or i915
driver, so it should be OK to do this despite running a distribuion
kernel.  Do let us know the URL of the issue you open, so we can keep
track of it.

(We ask you to do this yourself because the upstream developers will
likely need to ask you more questions.)

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1080264: linux-headers-6.1.0-25-amd64: Package fails to autoinstall due to dkms and wireguard module

[Ben Hutchings]

On Sun, 2024-09-01 at 10:38 +0100, Dario Griffo wrote:
> Package: linux-headers-6.1.0-25-amd64
> Version: 6.1.106-3
> Severity: important
> 
> Dear Maintainer,
> 
> on 2024-08-31 while trying to upgrade to the new released kernel in debian 
> stable
> from 6.1.0-23-amd64 to 6.1.0-25-amd64 an error occured trying to upgrade 
> kernel headers
> 
> command ran:
> 
> apt upgrade -y
> 
> I expected linux-headers to be upgraded without issues, had to reboot
> and run with previous kernel.
> 
> Error during ugprade
> 
> Sign command: /usr/lib/linux-kbuild-6.1/scripts/sign-file
> Signing key: /var/lib/dkms/mok.key
> Public certificate (MOK): /var/lib/dkms/mok.pub
> Error! The
> /var/lib/dkms/wireguard/1.0.20200429/6.1.0-25-amd64/x86_64/dkms.conf for
> module wireguard includes a BUILD_EXCLUSIVE directive which does not
> match this kernel/arch/config.
> This indicates that it should not be built.
[...]

You should remove wireguard-dkms.  The wireguard driver is already
included in linux-image-6.1 packages.

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1079686: nouveau: fifo: fault 01 [WRITE] at 0000000000068000 engine 03 [IFB] client 08 [HUB/HOST_CPU_NB]

[Ben Hutchings]

Control: tag -1 upstream moreinfo

On Mon, 26 Aug 2024 11:25:08 +0200 André Schramm  wrote:
> Package: src:linux
> Version: 6.10.6-1
> Severity: important
> 
> Dear Maintainer,
> 
> after waking up from sleep state S3, nouveau produces the following error:
> 
> [   77.785163] nouveau :01:00.0: fifo: fault 01 [WRITE] at 
> 00068000
> engine 03 [IFB] client 08 [HUB/HOST_CPU_NB] reason 02 [PTE] on channel 2
> [007fa12000 Xorg[1425]]
> [   77.785171] nouveau :01:00.0: fifo:00:0002:[Xorg[1425]] rc 
> scheduled
> [   77.785173] nouveau :01:00.0: fifo:00: rc scheduled
> [   77.785225] nouveau :01:00.0: fifo:00:0002:0002:[Xorg[1425]] 
> errored
> - disabling channel
> [   77.785232] nouveau :01:00.0: Xorg[1425]: channel 2 killed!
> 
> This in turn kills the X server including the whole session.
> 
> During normal boot, nouveau already produces another error:
> 
> [   33.908446] irq 27 handler nvkm_intr+0x0/0x240 [nouveau] enabled interrupts
> [   33.908538] WARNING: CPU: 3 PID: 2320 at kernel/irq/handle.c:161
> __handle_irq_event_percpu+0x193/0x1a0
> 
> Full dmesg log is attached.
> 
> The last known working kernel version was linux-image-6.1.0-11-amd64.
[...]

Please can you open an issue upstream at
<https://gitlab.freedesktop.org/drm/nouveau/-/issues>?  You will need
to create an account there first.  Do let us know the URL of the issue
you open, so we can keep track of it.

(We ask you to do this yourself because the upstream developers will
likely need to ask you more questions.)

Ben.

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1080244: Memory corruption with ancient i386 binaries using stdio

[Ben Hutchings]

Package: libc6
Version: 2.40-2
Severity: minor

I have an executable that I compiled for i386 in (probably) 1998,
which I have been running in a faily cron job until now.  Today it
failed to open a file, and strace showed that the filename was
partially corrupted.

Since the executable predates the use of ASLR, the memory corruption
is reliably reproducible and I was able to catch it with gdb.

The memory watchpoint is hit in __GI__IO_link_in() at:

123 _IO_list_all->file._prevchain = &fp->file._chain;
   0xf7de4a44 <+612>:   lea0x34(%esi),%ebp
   0xf7de4a47 <+615>:   mov%ebp,0x64(%ecx)
=> 0xf7de4a4a <+618>:   jmp0xf7de498a <__GI__IO_link_in+426>
   0xf7de4a4f <+623>:   nop

The backtrace is:

#0  0xf7de4a4a in __GI__IO_link_in (fp=0x804a1a0) at ./libio/genops.c:123
#1  0xf7ed9267 in _IO_old_file_init_internal (fp=0x804a1a0)
at ./libio/oldfileops.c:106
#2  0xf7ed7e5b in _IO_old_fopen (
filename=0x8049c9c  "/home/ben/.base-ԡ\004\b", mode=0x8048b43 "r")
at ./libio/oldiofopen.c:54
#3  0x0804887a in main ()

At this point _IO_list_all points to _IO_stderr_, which for some
reason is *in the executable's BSS section*:

08049c48 ld  .bss    .bss
08049c9c l O .bss   0100 base_n.4
08049d9c l O .bss   0100 rand_n.5
08049e9c l O .bss   0100 sig_n.6
08049c48 g O .bss   0050 _IO_stderr_
08049c98  w  .bss   0004 _environ
08049c98 g O .bss   0004 __environ
08049c48 g O *ABS*   __bss_start

The size allocated for _IO_stderr_ in the executable appears to be 80
bytes, which is rather smaller than the current size of struct
_IO_FILE_plus (152 bytes), so the assignment to
_IO_list_all->file._prevchain overwrites the following static data
(base_n) containing the filename.

I'm just going to recompile the executable, but I will keep the old
one around for a while in case anyone feels like investigating
further.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.10.6-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages libc6 depends on:
ii  libgcc-s1  14.2.0-4

Versions of packages libc6 recommends:
ii  libidn2-0  2.3.7-2

Versions of packages libc6 suggests:
ii  debconf [debconf-2.0]  1.5.87
ii  glibc-doc  2.40-2
ii  libc-l10n  2.40-2
ii  libnss-nis 3.1-5
ii  libnss-nisplus 1.3-5+b1
ii  locales2.40-2

-- debconf-show failed

Bug#1080203: initramfs-tools: USB keyboard stopped working on LUKS prompt

[Ben Hutchings]

On Sun, 2024-09-01 at 00:40 +0300, Henrik Ahlgren wrote:
> On Sat, 2024-08-31 at 23:22 +0200, Ben Hutchings wrote:
> > None of the driver changes are relevant to this system.  You are not
> > using Hyper-V and Linux 6.1 does not include the USB drivers that
> > initramfs-tools tries to add.
> 
> I suspect this commit might be relevant:
> 
> https://salsa.debian.org/kernel-team/initramfs-tools/-/commit/5d28dad0e24020d43daf51a5c1e70eb2fe5b4ee2
> 
> Both onboard_usb_hub and onboard_usb_dev are listed. From kernel git
> history it seems to me that it is the same module, but it was renamed from
> _hub to _dev (31e7f6c015d). Bookworm 6.1 kernel does include
> onboard_usb_hub I believe, but I don't quite understand what it is exactly.

Well, the driver source is there, but we didn't enable it until later
and then only on arm64.

> When I have time, I might try to disable this part from hook-functions to
> see if it helps. I would not be surprised if this is was hardware-relevant,
> of course.
> 
> > I suspect that probing of your USB keyboard is slightly unreliable and
> > that it just happened to fail on the first boot after you upgraded. 
> > Please try again with the new initramfs-tools packages.  Also, if the
> > keyboard is not detected at first, try unplugging and re-plugging it.
> 
> I did try rebooting many times with same results each time. Also tried
> unpluggint and re-plugging and even switching to a different keyboard. I
> have never seen this issue with 0.142.

Well this is very weird.

Another possibility is a USB hub getting into a broken state which
isn't cleared by rebooting.  But this doesn't seem very likely.

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

Bug#1080203: initramfs-tools: USB keyboard stopped working on LUKS prompt

[Ben Hutchings]

Control: tag -1 moreinfo

On Sat, 31 Aug 2024 17:53:32 +0300 Henrik Ahlgren  wrote:
> Package: initramfs-tools
> Version: 0.142+deb12u1
> Severity: important
> 
> Dear Maintainer,
> 
> After upgrading to 12.7 point release and rebooting, I was unable to
> enter my FDE LUKS password. The keyboard was totally unresponsive to any key 
> presses
> (no asterisks were echoed when typing the password, and hitting Enter did 
> nothing).
> 
> My keyboard is a standard USB keyboard (Topre Realforce) connected to
> an AMD-based HP desktop machine.
> 
> I then booted to a rescue environment from an USB stick and downgraded
> initramfs-tools(-core) to the previous version (0.142). After that everything
> worked normally again.
> 
> According to the changelog, there are several recent keyboard and USB
> related changes in this u1 release that might be relevant.

None of the driver changes are relevant to this system.  You are not
using Hyper-V and Linux 6.1 does not include the USB drivers that
initramfs-tools tries to add.
 
> Please take a look, I think this is fairly important since it renders at least
> some systems with LUKS unbootable.

I can't reproduce this.

I suspect that probing of your USB keyboard is slightly unreliable and
that it just happened to fail on the first boot after you upgraded. 
Please try again with the new initramfs-tools packages.  Also, if the
keyboard is not detected at first, try unplugging and re-plugging it.

If this problem persists, please send:

- The /etc/initramfs-tools/initramfs.conf file
- The output of "lsinitramfs /boot/initrd.img-6.1.0-25-amd64" when
  the old version of initramfs-tools is installed
- The output of "lsinitramfs /boot/initrd.img-6.1.0-25-amd64" when
  the new version of initramfs-tools is installed

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

Bug#1079717: sgt-puzzles: [Mozaic] crashes when copying the game

[Ben Hutchings]

Control: tag -1 confirmed patch

On Mon, 2024-08-26 at 20:31 +0200, Nicolas Patrois wrote:
> Package: sgt-puzzles
> Version: 20230410.71cf891-2+b1
> Severity: normal
> Tags: upstream
> 
> Dear Maintainer,
> 
> When I copy the game, the game is crashy.
> Here is the stack trace from systemd.coredump.
[...]

I confirm that Mosaic tends to crash when copying and that this becomes
more likely when using larger sizes.

This is a fairly straightforward buffer overflow, which the attached
patch should fix.

Ben.

-- 
Ben Hutchings
Man invented language to satisfy his deep need to complain.
  - Lily Tomlin

From fa54e1535c94a90455756a1fa5c1c12aa03b9bda Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Mon, 26 Aug 2024 20:56:06 +0200
Subject: [PATCH] Mosaic: Fix buffer overflow in game_text_format()

The text format includes newline characters that weren't being
included in the buffer length calculation.  Fix the calculation and
assert before returning that the string offset matches the calculated
length.
---
 mosaic.c | 5 +++--
 1 file changed, 3 insertions(+), 2 deletions(-)

diff --git a/mosaic.c b/mosaic.c
index 05a339de..594039f7 100644
--- a/mosaic.c
+++ b/mosaic.c
@@ -980,8 +980,8 @@ static bool game_can_format_as_text_now(const game_params *params)
 
 static char *game_text_format(const game_state *state)
 {
-char *desc_string =
-snewn((state->height * state->width) * 3 + 1, char);
+size_t desc_len = state->height * (state->width * 3 + 1);
+char *desc_string = snewn(desc_len + 1, char);
 int location_in_str = 0, x, y;
 for (y = 0; y < state->height; y++) {
 for (x = 0; x < state->width; x++) {
@@ -997,6 +997,7 @@ static char *game_text_format(const game_state *state)
 sprintf(desc_string + location_in_str, "\n");
 location_in_str += 1;
 }
+assert(location_in_str == desc_len);
 return desc_string;
 }
 


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

Bug#1079715: source-is-missing false positive for patch with 'ELF' in its header

[Ben Hutchings]

Package: lintian
Version: 2.118.0
Severity: normal

A patch that starts with:

From: Jiri Olsa 
Date: Sat, 13 Feb 2021 17:46:48 +0100
Subject: btf_encoder: Match ftrace addresses within ELF functions

is reported by file as:

unified diff output text, 1st line "From: Jiri Olsa ", 
2nd line "Date: Sat, 13 Feb 2021 17:46:48 +0100", 3rd line "Subject: 
btf_encoder: Match ftrace addresses within ELF functions", ASCII text

which satisifies the test:

if ($item->file_type =~ m{\bELF\b}x) {

in Lintian/Check/Files/SourceMissing.pm, resulting in a false
source-is-missing error (and a source-contains-prebuilt-binary
pedantic note, but I can quite happily ignore that).

Please use a stricter regex that will only match file output for ELF
binaries.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages lintian depends on:
ii  binutils2.42.90.20240720-2
ii  bzip2   1.0.8-5.1
ii  diffstat1.66-1
ii  dpkg1.22.9
ii  dpkg-dev1.22.9
ii  file1:5.45-3
ii  gettext 0.22.5-2
ii  gpg 2.2.43-8
ii  intltool-debian 0.35.0+20060710.6
ii  iso-codes   4.16.0-1
ii  libapt-pkg-perl 0.1.40+b5
ii  libarchive-zip-perl 1.68-1
ii  libberkeleydb-perl  0.64-2+b3
ii  libcapture-tiny-perl0.48-2
ii  libclass-xsaccessor-perl1.19-4+b3
ii  libclone-perl   0.46-1+b2
ii  libconfig-tiny-perl 2.30-1
ii  libconst-fast-perl  0.014-2
ii  libcpanel-json-xs-perl  4.38-1
ii  libdata-dpath-perl  0.59-1
ii  libdata-validate-domain-perl0.10-1.1
ii  libdata-validate-uri-perl   0.07-3
ii  libdevel-size-perl  0.84-1
pn  libdigest-sha-perl  
ii  libdpkg-perl1.22.9
ii  libemail-address-xs-perl1.05-1+b3
ii  libencode-perl  3.21-1+b1
ii  libfile-basedir-perl0.09-2
ii  libfile-find-rule-perl  0.34-3
ii  libfont-ttf-perl1.06-2
ii  libhtml-html5-entities-perl 0.004-3
ii  libhtml-tokeparser-simple-perl  3.16-4
ii  libio-interactive-perl  1.025-1
ii  libipc-run3-perl0.049-1
ii  libjson-maybexs-perl1.004005-1
ii  liblist-compare-perl0.55-2
ii  liblist-someutils-perl  0.59-1
ii  liblist-utilsby-perl0.12-2
ii  libmldbm-perl   2.05-4
ii  libmoo-perl 2.005005-1
ii  libmoox-aliases-perl0.001006-2
ii  libnamespace-clean-perl 0.27-2
ii  libpath-tiny-perl   0.146-1
ii  libperlio-gzip-perl 0.20-1+b3
ii  libperlio-utf8-strict-perl  0.010-1+b2
ii  libproc-processtable-perl   0.636-1+b2
ii  libregexp-wildcards-perl1.05-3
ii  libsereal-decoder-perl  5.004+ds-1+b2
ii  libsereal-encoder-perl  5.004+ds-1+b2
ii  libsort-versions-perl   1.62-3
ii  libsyntax-keyword-try-perl  0.29-2
ii  libterm-readkey-perl2.38-2+b3
ii  libtext-levenshteinxs-perl  0.03-5+b3
ii  libtext-markdown-discount-perl  0.16-1+b2
ii  libtext-xslate-perl 3.5.9-2
ii  libtime-duration-perl   1.21-2
ii  libtime-moment-perl 0.44-2+b3
ii  libtimedate-perl2.3300-2
ii  libunicode-utf8-perl0.62-2+b2
ii  liburi-perl 5.28-1
ii  libwww-mechanize-perl   2.18-1
ii  libwww-perl 6.77-1
ii  libxml-libxml-perl  2.0207+dfsg+really+2.0134-4
ii  libyaml-libyaml-perl0.89+ds-1+b1
ii  lzip [lzip-decompressor]1.24.1-2
ii  lzop1.04-2
ii  man-db  2.12.1-2
ii  patchutils  0.4.2-1
ii  perl [libencode-perl]   5.38.2-5
ii  t1utils 1.41-4
ii  unzip   6.0-28
ii  xz-utils5.6.2-2

lintian recommends no packages.

Versions of packages lintian suggests:
ii  binutils-multiarch 2.42.90.20240720-2
ii  libtext-template-perl  1.61-1

-- debconf-show failed

Bug#1079473: ITP: tinyalsa -- TinyALSA is a small library to interface with ALSA in the Linux kernel.

[Ben Hutchings]

On Sun, 2024-08-25 at 01:30 +0200, erebion wrote:
> I will not state that, as this neither this ITP not the package itself 
> are about supporting Android software.
> 
> I have already stated for what use-case this package is required.

tinyalsa comes from AOSP, and I thought q6voiced was Qualcomm's own
software from AOSP but now I see that it's not.

So, OK, you are right.  It still seems strange for an AOSP component to
be used in non-Android software.

Ben.


-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.



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

Bug#1079460: bookworm-pu: package initramfs-tools/0.142+deb12u1

[Ben Hutchings]

On Fri, 2024-08-23 at 17:45 +0100, Adam D. Barratt wrote:
> Control: tags -1 + confirmed
> 
> On Fri, 2024-08-23 at 15:22 +0200, Ben Hutchings wrote:
> > - Some important drivers are currently not included in the initramfs
> >   by default.
> > - If the same file is added to the initramfs and named through
> >   multiple directory symlinks, it is duplicated in the initramfs.  
> 
> [...]
> > The change to symlink handling has been tested together with
> > firmware-nvidia-graphics from unstable.  I will also test
> > the backport with reiserfsprogs (not yet done).
> [...]
> > There is some risk of regression from changes to the handling of
> > symlinked directories.  The initial fix for this led to breakage
> > for reiserfsprogs (bug #1079276), but that has been resolved.

I have now tested installing each of the packages in bookworm main that
install initramfs hooks, together with old and new versions of
initramfs-tools.  I excluded kxc which is not installable (bug
#1063700).  I also tested installing all firmware packages built from
firmware-nonfree/bookworm.

The initramfs contents were identical between old and new versions,
aside from:

- Expected additions to the included drivers
- Expected changes to initramfs-tools' own files
- dropbear-initramfs seems to randomise the name of the root user

> Please go ahead. Note that the window for getting fixes into 12.7 will
> close this weekend.

I have just done so.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.



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

Bug#1079473: ITP: tinyalsa -- TinyALSA is a small library to interface with ALSA in the Linux kernel.

[Ben Hutchings]

On Fri, 2024-08-23 at 18:26 +0200, erebion wrote:
> Package: wnpp
> Severity: wishlist
> Owner: erebion 
> X-Debbugs-Cc: debian-de...@lists.debian.org, ereb...@erebion.eu
> 
> * Package name : tinyalsa
> Version : git20240621
> Upstream Contact: Taylor Holberton 
> * URL : https://github.com/tinyalsa/tinyalsa
> * License : BSD
> Programming Lang: C
> Description : TinyALSA is a small library to interface with ALSA in the 
> Linux kernel.
> 
> TinyALSA is a small library to interface with ALSA in the Linux kernel.
> The aims are:
[...]

It seems to me that the real aim is:

* Avoid the need for copyleft libraries in AOSP

Please make it clear in the package description that this package is
meant to support Android software and that Linux developers should
normally use alsa-lib (or higher level APIs like Pipewire).

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.



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

Bug#1079588: mandos-client postrm purge can mysteriously fail

[Ben Hutchings]

Package: mandos-client
Version: 1.8.16-1
Severity: serious

mandos-client's postrm script can fail on purge with no obvious error
message.  dpkg reports that it exited with error code 128 but it's not
clear why.  I can reproduce this in a bookworm/amd64 or unstable/amd64
build chroot by running:

apt install -y mandos-client linux-image-amd64
apt purge -y mandos-client

Ben.

Bug#1079460: bookworm-pu: package initramfs-tools/0.142+deb12u1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
Tags: bookworm
X-Debbugs-Cc: initramfs-to...@packages.debian.org, 
debian-ker...@lists.debian.org
Control: affects -1 + src:initramfs-tools
User: release.debian@packages.debian.org
Usertags: pu

[ Reason ]
- Some important drivers are currently not included in the initramfs
  by default.
- If the same file is added to the initramfs and named through
  multiple directory symlinks, it is duplicated in the initramfs.  
  
[ Impact ]
- Currently keyboard input does not work in the initramfs environment
  on some systems.  This prevents entering a decryption password or
  using the panic shell.
- On some systems booting from USB storage, power to the storage may
  be interrupted after it is already mounted.
- If the Nvidia GSP firmware is installed, either from a (planned)
  backport of firmware-nonfree or from upstream linux-firmware.git,
  and plymouth is installed, then the initramfs ends up being huge,
  often filling the /boot partition (bug #1076539).
  - This is a blocker for updating firmware-nonfree in
bookworm-backports.  An alternative would be to update
initramfs-tools in bookworm-backports first, but that would
require also backporting dracut since initramfs-tools-core depends
on dracut-install.

[ Tests ]
There are autopkgtest test cases that cover various boot
configurations.

The change to symlink handling has been tested together with
firmware-nvidia-graphics from unstable.  I will also test the backport
with reiserfsprogs (not yet done).

[ Risks ]
There is some risk of regression from changes to the handling of
symlinked directories.  The initial fix for this led to breakage
for reiserfsprogs (bug #1079276), but that has been resolved.

[ Checklist ]
  [X] *all* changes are documented in the d/changelog
  [X] I reviewed all changes and I approve them
  [X] attach debdiff against the package in (old)stable
  [X] the issue is verified as fixed in unstable

[ Changes ]
* Get CI passing:
  - d/salsa-ci.yml: Set RELEASE to bookworm
  - Fix/ignore ShellCheck findings
  - test: Fix too small ext2 block count
* Include missing drivers:
  - Add hyper-keyboard module, needed to enter LUKS password in Hyper-V
  - install hid-multitouch module for Surface Pro 4 Keyboard
  - hook-functions: auto_add_modules: Add onboard_usb_hub, onboard_usb_dev
* Fix bug #1076539 for users installing upstream firmware and in
  preparation for a backport of firmware-nonfree:
  - hook_functions: Fix copy_file with source including a directory symlink
  - hook-functions: copy_file: Canonicalise target filename
diff -Nru initramfs-tools-0.142/debian/changelog 
initramfs-tools-0.142+deb12u1/debian/changelog
--- initramfs-tools-0.142/debian/changelog  2022-07-12 23:51:34.0 
+0200
+++ initramfs-tools-0.142+deb12u1/debian/changelog  2024-08-23 
15:18:27.0 +0200
@@ -1,3 +1,30 @@
+initramfs-tools (0.142+deb12u1) bookworm; urgency=medium
+
+  [ Ben Hutchings ]
+  * [522d475] d/salsa-ci.yml: Set RELEASE to bookworm
+  * [05e5fb9] hook_functions: Fix copy_file with source including a directory
+symlink
+  * [f52ae2d] hook-functions: copy_file: Canonicalise target filename
+(Closes: #1079276)
+
+  [ szubersk ]
+  * [d502a7f] Fix/ignore ShellCheck findings
+
+  [ Benjamin Drung ]
+  * [ce185c3] test: Fix too small ext2 block count
+  * [cd5e8e8] install hid-multitouch module for Surface Pro 4 Keyboard
+(LP: #1772094)
+
+  [ Arnaud Rebillout ]
+  * [4cc2bc7] Add hyper-keyboard module, needed to enter LUKS password in
+Hyper-V (Closes: #1028511)
+
+  [ Alper Nebi Yasak ]
+  * [5d28dad] hook-functions: auto_add_modules: Add onboard_usb_hub,
+onboard_usb_dev
+
+ -- Ben Hutchings   Fri, 23 Aug 2024 15:18:27 +0200
+
 initramfs-tools (0.142) unstable; urgency=medium
 
   [ Dan Streetman ]
diff -Nru initramfs-tools-0.142/debian/salsa-ci.yml 
initramfs-tools-0.142+deb12u1/debian/salsa-ci.yml
--- initramfs-tools-0.142/debian/salsa-ci.yml   2022-07-12 23:51:34.0 
+0200
+++ initramfs-tools-0.142+deb12u1/debian/salsa-ci.yml   2024-08-22 
20:55:59.0 +0200
@@ -3,7 +3,7 @@
   - 
https://salsa.debian.org/salsa-ci-team/pipeline/raw/master/pipeline-jobs.yml
 
 variables:
-  RELEASE: 'unstable'
+  RELEASE: 'bookworm'
   # We only build arch:all packages
   SALSA_CI_DISABLE_BLHC: 'true'
   SALSA_CI_DISABLE_BUILD_PACKAGE_I386: 'true'
diff -Nru initramfs-tools-0.142/debian/tests/test-common 
initramfs-tools-0.142+deb12u1/debian/tests/test-common
--- initramfs-tools-0.142/debian/tests/test-common  2020-09-13 
20:25:12.0 +0200
+++ initramfs-tools-0.142+deb12u1/debian/tests/test-common  2024-08-22 
21:30:14.0 +0200
@@ -71,7 +71,7 @@
local inodes="$(du --summarize --inodes "${dir}" | cut -f 1)"
 
# Add fudge factor
-   blocks="$((blocks + 20 + blocks / 4))"
+   blocks="$((blocks + 28 + blocks / 4))"
inodes

Bug#1079333: initramfs-tools: upgrading causes dpkg(1) to fail

[Ben Hutchings]

Control: reopen -1
Control: severity -1 serious

Sorry, I got confused by the multiple reports of this and thought you
had
opened two different bug reports for this.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Ben Hutchings]

On Thu, 2024-08-22 at 13:43 +0200, Alejandro Colomar wrote:
[...]
> Should I open a separate bug?  Or is it a consequence of (a combination)
> of the current bugs?  How should I fix it?

It's a totally different bug; please open a separate report.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Ben Hutchings]

Control: forcemerge 1079066 -1

On Thu, 2024-08-22 at 12:34 +0200, Alejandro Colomar wrote:
[...]
> It shows errors.
> 
> $ sudo update-initramfs -u -k 6.10.4-amd64
> update-initramfs: Generating /boot/initrd.img-6.10.4-amd64
> /usr/lib/dracut/dracut-install: symbol lookup error: 
> /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
> version LIBKMOD_5
> setupcon: The keyboard model is unknown, assuming 'pc105'. Keyboard may be 
> configured incorrectly.
> /usr/lib/dracut/dracut-install: symbol lookup error: 
> /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
> version LIBKMOD_5
> /usr/lib/dracut/dracut-install: symbol lookup error: 
> /usr/lib/dracut/dracut-install: undefined symbol: kmod_module_get_weakdeps, 
> version LIBKMOD_5
> $ echo $?
> 0
> 
> (It's weird that the exit status is 0 but it shows errors.)

OK, so this is a bug I've just fixed (in version 0.144).

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Ben Hutchings]

On Thu, 2024-08-22 at 01:11 +0200, Alejandro Colomar wrote:
> Hi Ben,
> 
> On Thu, Aug 22, 2024 at 12:46:00AM GMT, Ben Hutchings wrote:
> > Please send the output of this command:
> > 
> > lsinitramfs /boot/initrd.img-6.9.12-amd64 | grep /lib/modules | head
> 
> I've purged 6.9.12, but I keep 6.10.4 --which is also broken--, so I've
> run it with that:
> 
>   $ lsinitramfs /boot/initrd.img-6.10.4-amd64 \
>   | grep /lib/modules | head;
>   usr/lib/modules
>   usr/lib/modules/6.10.4-amd64
>   usr/lib/modules/6.10.4-amd64/kernel
>   usr/lib/modules/6.10.4-amd64/kernel/crypto
>   usr/lib/modules/6.10.4-amd64/kernel/crypto/adiantum.ko
>   usr/lib/modules/6.10.4-amd64/kernel/drivers
>   usr/lib/modules/6.10.4-amd64/kernel/drivers/input
>   usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse
>   usr/lib/modules/6.10.4-amd64/kernel/drivers/input/mouse/psmouse.ko
>   usr/lib/modules/6.10.4-amd64/kernel/drivers/net

[...]

I think this is bug #1079022 (breakage of dracut-install) together with
bug #1079066 (missing check for failure of dracut-install).

Does "update-initramfs -u -k 6.10.4-amd64" show errors from dracut-
install?  And if not, does it now produce a working initramfs?

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1064795: iproute2: removing /sbin/ip link breaks other packages and possibly user scripts

[Ben Hutchings]

On Fri, 2024-08-16 at 16:54 +0100, Colin Watson wrote:
> On Fri, Aug 16, 2024 at 05:21:38PM +0200, Philip Hands wrote:
> > I think it probably was just a coincidence, since it looks like the
> > change was made in order to fix #1064795 which was reported on
> > 25 Feb 2024.
> 
> Ah, good to know, thanks.  I didn't notice that since it wasn't
> mentioned in the iproute2 changelog.
> 
> > It just strikes me as obvious that removing any long-standing binary
> > path in Debian is pretty-much bound to break someone's system, and if
> > you want to do that you really ought to at least check, and preferably
> > try to work out a way of warning them about it, or fixing the breakage
> > first.
> 
> Quite.  If nothing else, I think the code actually in the Debian archive
> that relies on the old path ought to be changed _first_, e.g. via an
> MBF.  I see a bunch of cases that are relatively subtle and might suck a
> lot of other people's time trying to debug them from cold, such as
> AppArmor profiles and example scripts, and it's just good manners to
> give maintainers an explicit heads-up.

I've made a team upload of iproute2 (version 6.10.0-2) with this change
reverted.

Luca, please leave the symlink in place at least as long as there are
packages that rely on it.

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1079150: cryptsetop: Waiting for encrypted source device

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 20 Aug 2024 16:11:16 +0200 Alejandro Colomar 
wrote:
> Package: src:linux
> Version: 6.9.12-1
> Severity: critical
> Justification: breaks the whole system
> X-Debbugs-Cc: a...@kernel.org
> 
> Dear Maintainer,
> 
> I ran `apt-get upgrade` earlier today.  I rebooted, since the update
> had a new kernel, and the system wouldn't boot with the new kernel.
> My old kernel was 6.9.7-amd64, which worked fine.
> The new kernel is 6.9.12-amd64.  Here's what I see when booting with
the
> new kernel:
> 
>   cryptsetup: Waiting for encrypted source device UUID=8[...]...
>   mdadm: No devices listed in conf file were found.
>   mdadm: No devices listed in conf file were found.
[...]

Please send the output of this command:

lsinitramfs /boot/initrd.img-6.9.12-amd64 | grep /lib/modules | head

Ben.

-- 
Ben Hutchings
All the simple programs have been written, and all the good names taken



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

Bug#1078475: ITP: python-tzdata -- provider of IANA time zone data

[Ben Hutchings]

On Sun, 2024-08-11 at 20:53 +, weepingclown wrote:
> Hi,
> 
> I did consider the same and discussed within the python team, but tzdata does 
> not have US/* timezones anymore (which apparently now is in the tzdata-legacy 
> package) which pendulum uses. Having to depend on several packages and adding 
> several workarounds does not seem really nice when there is a perfectly well 
> upstream package that is made just for such usages, not to mention maintained 
> by the python team itself. And as mentioned, zoneinfo from standard library 
> itself seems to be making use of the python tzdata package (just what I found 
> after going through the source code), so I believe there is value in having 
> this in debian.

The problem with this is that timezones are frequently updated.  Every
time the data gets duplicated for the convenience of another language,
that adds further to the work that has to be done in stable and LTS
updates.

Ben.

> On 11 August 2024 8:36:00 pm UTC, Ben Hutchings  wrote:
> > Since this is meant to be a fallback, and you can make the Debian
> > package of pendulum depend on tzdata, is python-tzdata really needed?
> > 
> > Ben.
> > 

-- 
Ben Hutchings
Q.  Which is the greater problem in the world today,
ignorance or apathy?
A.  I don't know and I couldn't care less.



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

Bug#1078608: apt update silently leaves old index data

[Ben Hutchings]

Control: severity -1 important

On Tue, 13 Aug 2024 19:57:58 +0200 Sven Bartscher
 wrote:
> Package: apt
> Version: 2.9.7
> Severity: normal
> 
> Hi,
> 
> for a while I've been having the problem with `apt update` that it
> pretends to complete successfully, but it didn't actually pull
updated
> index data. I run it like this:
[...]

I've also seen this occasionally.  I would consider this at least
'important' as it can cause security updates to silently not be
applied.

It happened again today and I remembered to take a snapshot of the VM
before working around it.  So I can provide whatever information is
needed from that snapshot.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Bug#1072004: linux: regression in the 9p protocol in 6.8 breaks autopkgtest qemu jobs (affecting debci)

[Ben Hutchings]

Control: tag -1 - moreinfo
Control: tag -1 fixed-upstream

This is claimed to be fixed upstream by:

commit e3786b29c54cdae3490b07180a54e2461f42144c
Author: Dominique Martinet 
Date:   Thu Aug 8 14:29:38 2024 +0100

9p: Fix DIO read through netfs

which is now in Linus's tree and will be part of 6.11-rc4.

Ben.

-- 
Ben Hutchings
Design a system any fool can use, and only a fool will want to use it.



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

Bug#1078475: ITP: python-tzdata -- provider of IANA time zone data

[Ben Hutchings]

On Sun, 2024-08-11 at 14:34 +0530, Ananthu C V wrote:
> Package: wnpp
> Severity: wishlist
> Owner: Ananthu C V 
> X-Debbugs-Cc: debian-de...@lists.debian.org
> 
> * Package name: python-tzdata
>   Version : 2024.1
>   Upstream Contact: Python Software Foundation 
> * URL : https://github.com/python/tzdata
> * License : Apache-2.0
>   Programming Lang: Python
>   Description : provider of IANA time zone data
> 
> This is a Python package containing zic-compiled binaries for the IANA time
> zone database. It is intended to be a fallback for systems that do not have
  ^^^
> system time zone data installed (or don't have it installed in a standard
  ^^^
> location), as a part of PEP 615.
> 
> It is a dependency needed by pendulum 3.0.

Since this is meant to be a fallback, and you can make the Debian
package of pendulum depend on tzdata, is python-tzdata really needed?

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#1039883: linux: ext4 corruption with symlinks

[Ben Hutchings]

On Tue, 2024-07-09 at 19:32 +0200, Ben Hutchings wrote:
> Control: tag -1 patch fixed-upstream
> 
> A fix was applied to the ext4 "dev" branch earlier today:
> <https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=7882b0187bbeb647967a7b5998ce4ad26ef68a9a>
> 
> I would still want to wait at least a week or two before cherry-picking
> it, in case of regressions.

This was included in 6.11-rc1 and is queued for the 5.15, 6.1, 6.6, and
6.10 stable branches.

It is *not* queued for 5.10 and some work may be needed to backport it.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

On Tue, 2024-06-04 at 06:51 -0400, Bud Heal wrote:
> I filled up the (micro)SDs, including the current one I have been scanning
> into, the one that I set aside as probably defective and the pair I bought
> for testing. I will append the bash script.

I appreciate that you've scripted this, but you missed step 2: remove
and reinsert the card.  Without that, the script may just be reading
files out of the cache if your system has enough RAM.  In the script
you could alternately flush the cache:

echo 1 > /proc/sys/vm/drop_caches

if you're running it as root.

> As I look again, I read that
> you wanted this done on Windows but I did not use cygwin because putting
> Windows into the mix could affect the steps that invoke the data
> corruption.

I wanted you to do this on Windows so that we could see if the same
corruption could occur.

> Instead, I installed Debian bookworm without a graphical
> desktop (unchecked anything except system and ssh). One also activates the
> network interface and DHCP. That way, the SD and its folders will not be
> affected by adding thumbnails, which I have identified as a way to avoid
> the problem.

So disabling automatic thumbnail generation mitigates the problem, but
we already knew that, didn't we?

> After satisfying that step, I tried a SD without using the wand scanner.
> This newest laptop does not have a SD slot so I used a USB device. I
> enabled showing thumbnails. Bookworm's behavior is different from observed
> on buster and (probably) bullseye: when one copies a folder to the
> computer, and opens on the desktop during copying: (1) the folder on the SD
> quickly displays the thumbnails (serially from the top) but (2) the
> destination folder opens, begins to show thumbnails but is prone to
> continue copying but stopping placing thumbnail. If the SD's folder is
> opened, no more thumbnails are added on the computer until the copying is
> finished. If the SD's folder is not opened, the thumbnails may stop or may
> continue, but there is an extended pause without any indication that the
> last two files have been copied, until the progress dialog is closed and
> its window is refreshed. If neither folder is opened during copying, the
> copying progresses without such pauses and one can then open the folders
> and watch the thumbnails be created.
[...]

So one or both of:

- A change in the way this newer version of GNOME (or whichever desktop
environment you're using) does thumbnail generation 
- Using USB storage instead of an SD controller

mitigates the problem, but we don't know which.

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#1072063: one of the external monitors randomly blank for 2-3 seconds with 6.8/6.9 Linux kernels (regression)

[Ben Hutchings]

Hi Vincent,

On Fri, 19 Jul 2024 17:13:30 +0200 Vincent Lefevre 
wrote:
> Control: found -1 6.9.8-1
> Control: found -1 6.9.9-1
> 
> With the linux-image-6.9.8-amd64 6.9.8-1 kernel, the problem occurred
> on 2024-07-09, a first time with only one blanked monitor and a
second
> time with both monitors blanked.
> 
> I was off from 2024-07-10 to 2024-07-19 (today) in the morning.
> 
> With the linux-image-6.9.9-amd64 6.9.9-1 kernel, the problem has just
> occurred (2024-07-19), a few hours after its installation.

Could you please report this upstream following
<https://drm.pages.freedesktop.org/intel-docs/how-to-file-i915-bugs.html>?
(We don't have any patches to the i915 driver or DRM core, so I don't
think it matters that you are running a distribution kernel.)

Ben.

-- 
Ben Hutchings
Any sufficiently advanced bug is indistinguishable from a feature.



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

Bug#1003352:

[Ben Hutchings]

On Wed, 22 Mar 2023 09:45:37 +0100 Daniel Baumann
 wrote:
> On 3/22/23 06:18, Cyrus Lien wrote:
> > This bug still needs a boot script mounting efivarfs in initrd for
> > systems whose rootfs are on RAID volume.
> 
> as the bug sais: this has been fixed in mdadm 4.2+20230223-1.

How could mounting efivarfs when building an initramfs solve the
problem of missing efivarfs when running the initramfs?

Ben.

-- 
Ben Hutchings
Lowery's Law:
If it jams, force it. If it breaks, it needed replacing anyway.



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

Bug#1027749: update-initramfs could diagnose attempt to run with /dev not mounted

[Ben Hutchings]

Control: tag -1 wontfix

There are many ways in which the environment could be broken, and I
don't think it is worth the trouble to check for this one specifically.

Ben.

-- 
Ben Hutchings
Any smoothly functioning technology is indistinguishable
from a rigged demo.



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

Bug#1074798: a56: diff for NMU version 1.3+dfsg-10.2

[Ben Hutchings]

Control: tags 1074798 + patch
Control: tags 1074798 + pending

Dear maintainer,

I've prepared an NMU for a56 (versioned as 1.3+dfsg-10.2) and
uploaded it to DELAYED/10. Please feel free to tell me if I
should delay it longer.

These changes are also available on the "build-clean" branch of
<https://salsa.debian.org/benh/a56.git>.

Ben.

-- 
Ben Hutchings
Computers are not intelligent.  They only think they are.
diff -Nru a56-1.3+dfsg/debian/a56-tobin.c a56-1.3+dfsg/debian/a56-tobin.c
--- a56-1.3+dfsg/debian/a56-tobin.c	2024-01-13 23:00:00.0 +0100
+++ a56-1.3+dfsg/debian/a56-tobin.c	2024-07-27 02:42:12.0 +0200
@@ -21,6 +21,7 @@
 #include 
 #include 
 #include 
+#include 
 
 int
 main (int argc, char *argv[])
@@ -58,7 +59,8 @@
   if (offset > 0x7000)
 offset = prev_offset + 1;
   
-  pwrite (fd, value, 3, (off_t) (offset * 3));
+  if (pwrite (fd, value, 3, (off_t) (offset * 3)) < 0)
+	err (1, "Failed to write %s", argv[1]);
 
   prev_offset = offset;
 }
diff -Nru a56-1.3+dfsg/debian/changelog a56-1.3+dfsg/debian/changelog
--- a56-1.3+dfsg/debian/changelog	2024-03-16 21:29:00.0 +0100
+++ a56-1.3+dfsg/debian/changelog	2024-07-27 02:42:48.0 +0200
@@ -1,3 +1,21 @@
+a56 (1.3+dfsg-10.2) unstable; urgency=medium
+
+  * Non-maintainer upload
+  * Update patches to fix new errors in gcc-14 (Closes: #1074798):
+- Drop "non-void should return a value bug in main." (clang-ftbfs.diff)
+  as the affected function should actually return void
+- Replace the many partial function declaration patches with a single
+  patch that fixes all missing prototypes and K&R style definitions
+  * Drop "Replace undeclared fatal" (replace-undecl-fatal.patch), as
+fatal() is now declared
+  * Add format attributes to allow type checks on *printf() wrappers
+  * Enable most compiler warnings (-Wall -Wextra with some overrides)
+  * Fix remaining warnings in upstream code with gcc-14
+  * a56-tobin: Check for errors from pwrite()
+  * Add debian/.gitgnore file to make 'git add debian' safer
+
+ -- Ben Hutchings   Sat, 27 Jul 2024 02:42:48 +0200
+
 a56 (1.3+dfsg-10.1) unstable; urgency=medium
 
   * Non-maintainer upload.
diff -Nru a56-1.3+dfsg/debian/patches/ansi-c.patch a56-1.3+dfsg/debian/patches/ansi-c.patch
--- a56-1.3+dfsg/debian/patches/ansi-c.patch	2024-03-16 21:29:00.0 +0100
+++ a56-1.3+dfsg/debian/patches/ansi-c.patch	2024-07-27 02:32:30.0 +0200
@@ -3,8 +3,6 @@
 Date: Fri, 17 May 2013 10:46:34 +0200
 Subject: More code cleanup and converstion to ANSI C.
 ---
-diff --git a/frac2int.c b/frac2int.c
-index 8f01796..a045a70 100644
 --- a/frac2int.c
 +++ b/frac2int.c
 @@ -98,21 +98,26 @@
@@ -12,81 +10,44 @@
  \**/
  
 -main()
--{
--   double fractnum;  /* double precision floating pt */
--   long   hexval;/* long integer */
--
--for(;;) {
--/* Read 1 Decimal Floating Point Number from the Keyboard */
--   printf("Enter the decimal fraction: ");
--   scanf("%lf", &fractnum);
 +#include 
 +#include 
- 
--/* Convert to a Hex Integer which can be used by the DSP56200 */
--   hexval =  (long) (8388608.0 * fractnum);
--   hexval =  0x00ffL & hexval;
--
--/* Write the Hex number out to the Terminal */
--   printf("DSP56200 Coefficient = %06lx\n", hexval);
--}
++
 +int
 +main(void)
-+{
+ {
+-   double fractnum;  /* double precision floating pt */
+-   long   hexval;/* long integer */
 +	double fractnum;  /* double precision floating pt */
 +	long   hexval;/* long integer */
-+
+ 
+-for(;;) {
+-/* Read 1 Decimal Floating Point Number from the Keyboard */
+-   printf("Enter the decimal fraction: ");
+-   scanf("%lf", &fractnum);
 +	for(;;) {
 +		/* Read 1 Decimal Floating Point Number from the Keyboard */
 +		printf("Enter the decimal fraction: ");
 +		scanf("%lf", &fractnum);
-+
+ 
+-/* Convert to a Hex Integer which can be used by the DSP56200 */
+-   hexval =  (long) (8388608.0 * fractnum);
+-   hexval =  0x00ffL & hexval;
 +		/* Convert to a Hex Integer which can be used by the DSP56200 */
 +		hexval =  (long) (8388608.0 * fractnum);
 +		hexval =  0x00ffL & hexval;
-+
+ 
+-/* Write the Hex number out to the Terminal */
+-   printf("DSP56200 Coefficient = %06lx\n", hexval);
+-}
 +		/* Write the Hex number out to the Terminal */
 +		printf("DSP56200 Coefficient = %06lx\n", hexval);
 +	}
 +	return(EXIT_SUCCESS);
  }
-diff --git a/main.c b/main.c
-index 06f6dc4..9d2aacf 100644
 --- a/main.c
 +++ b/main.c
-@@ -21,6 +21,7 @@
-  *

Bug#1072311: linux-perf can (and should) link against libdebuginfod

[Ben Hutchings]

On Fri, 31 May 2024 16:30:37 -0400 Sergio Durigan Junior
 wrote:
> Source: linux
> Version: 6.8.11-1
> Severity: normal
> 
> Dear maintainer,
> 
> Upon investigating why Debian's linux-perf does not support
debuginfod,
> I found the following excerpt on its rules file[1]:
> 
> # perf can link against libdebuginfod if available, but the
result is
> # undistributable for the same reason.  Override detection of
> # libdebuginfod.
> MAKE_PERF += NO_LIBDEBUGINFOD=1
> 
> This picked my attention, as I am not aware of any licensing issues
that
> might prevent linux-perf from linking against libdebuginfod.
> 
> While looking at debuginfod source files[2], I found that
libdebuginfod
> is actually composed of a single file[3]:
> 
> libdebuginfod_a_SOURCES = debuginfod-client.c
> libdebuginfod_pic_a_SOURCES = debuginfod-client.c
> 
> and that debuginfod-client.c is dual-licensed GPL-3+ and GPL-2+[4]:
[...]

Thank you for pointing this out.

I disabled use of debuginfod on 26/12/2022, and it looks like I missed
your update to the elfutils debian/copyright file on 21/12/2022 that
would have made the dual licensing of this library clear.

Ben.

-- 
Ben Hutchings
Quantity is no substitute for quality, but it's the only one we've got.



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

Bug#1065698: update-initramfs: -k all stopped working

[Ben Hutchings]

Control: tag -1 moreinfo unreproducible

On Sat, 09 Mar 2024 04:28:53 + Thorsten Glaser 
wrote:
> Package: initramfs-tools
> Version: 0.142
> 
> The update-initramfs manpage documents -k all, and I know I used
> that in Kubuntu hardy times several times, but it does not work
> any longer, it just does nothing.
> 
> Calling without -k of course only updates the image for the current
kernel.
[...]

It works for me.

- What's the full command line that doesn't work?
- What does "linux-version list" say?

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#980021: initramfs-tools: Upgrading a LVM2 system with separate /usr to buster breaks booting

[Ben Hutchings]

Control: tag -1 moreino

On Tue, 12 Jan 2021 21:23:55 -0600 Ryan Underwood
 wrote:
> Package: initramfs-tools
> Version: 0.139
> Severity: important
> 
> Dear Maintainer,
> 
> I understand that separate /usr is deprecated, but many users do not
> have the luxury of wiping and reinstalling their entire system. 
Rather,
> a simple dist-upgrade procedure is expected to produce a working
system,
> making a best effort to migrate previously supported configurations.
> 
> Given that, upgrading a system to buster will break booting if the
> following two conditions are true:
> * /usr is a mount for a separate block device
> * The block device containing the /usr filesystem is a LVM volume.

No, that's a well-tested scenario.  There must be something unusual
about your system configuration.
 
> The reason is because the script
> /usr/share/initramfs-tools/scripts/local-top/lvm2 only attempts to
> activate the root and resume devices, and no other devices.
[...]

That's intentional and not a bug.  We find out the root and resume
devices from the built-in defaults or kernel command line.  But we find
the /usr device from /etc/fstab, after fscking and mounting root. 
There's a separate script,
/usr/share/initramfs-tools/scripts/local-block/lvm2, that is called to
handle /usr and should activate its volume group.

How was /usr listed in /etc/fstab?

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#1076564: pahole BTF processing seems flaky on powerpc

[Ben Hutchings]

On Sat, 2024-07-20 at 21:45 +0200, John Paul Adrian Glaubitz wrote:
> On Sat, 2024-07-20 at 21:17 +0200, Ben Hutchings wrote:
> > I had a go yesterday and ran into the same problem.  I couldn't
> > reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO +
> > DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of
> > the Debian kernel flavours.
> > 
> > > Will take care of it and let you know when it's (some hours).
> > 
> > Thank you!
> 
> There are now 120 GB of free disk space. Let me know if that's sufficient
> or whether I need to clean up more, probably asking others to clean up
> their home directories.

I've now done 10 kernel builds on perotto (4 builds of just the
"powerpc" flavour and then 2 builds of all 3 flavours) and not
reproduced this.  I'm thinking this may be machine-dependent in some
way.

Looking again at all the build logs since DEBUG_INFO_BTF was enabled
for powerpc, we have:

Successes:

VersionBuilder
--
6.9.10-1   debian-project-be-2
6.9.7-1debian-project-be-1
6.8.12-1   debian-project-be-2
6.8.11-1   blaauw
6.8.9-1debian-project-be-2
6.7.12-1   blaauw
6.7.9-2debian-project-be-2
6.7.4-1~exp1   blaauw
6.7.1-1~exp1   debian-project-be-2
6.6.15-1   blaauw
6.6.13-1   blaauw
6.6.11-1   debian-project-be-1
6.6.9-1+b1 debian-project-be-1
6.6.8-1debian-project-be-2
6.6.4-1~exp1   blaauw
6.5.13-1   debian-project-be-1
6.5.10-1   debian-project-be-2
6.5.8-1blaauw
6.5.6-1debian-project-be-2
6.5.3-1blaauw
6.5~rc7-1~exp1 debian-project-be-1
6.5~rc6-1~exp1 blaauw
6.4.13-1   blaauw
6.4.11-1   blaauw
6.4.4-3blaauw

Failures:

VersionBuilder Failure mode

6.10-1~exp1blaauw  this bug
6.9.9-1blaauw  this bug
6.9.8-1kapitsa this bug
6.9.2-1~exp1   blaauw  this bug
6.8.12-1   kapitsa this bug
6.7-1~exp1 debian-project-be-2 compiler OOM; not powerpc-specific
6.6.3-1~exp1   blaauw  kernel-wedge failed; not powerpc-specific
6.4.4-2blaauw  out of disk space

Ignoring the unrelated failures, kapitsa has a 0% success rate (but
with only 2 attempts), blaauw an 80% success rate, and debian-project-
be-{1,2} have 100% success rates.

I don't know what differences there are between these builders that
might be relevant.

Ben.

-- 
Ben Hutchings
One of the nice things about standards is that
there are so many of them.



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

Bug#1076564: pahole BTF processing seems flaky on powerpc

[Ben Hutchings]

On Sat, 2024-07-20 at 09:16 +0200, John Paul Adrian Glaubitz wrote:
> Hi Domenico,
> 
> On Fri, 2024-07-19 at 23:20 +0200, Domenico Andreoli wrote:
> > > > Is there anything I can do to help?
> > > 
> > > From the 6.10-1~exp1:
> > > https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1
> > > file:
> > > 
> > > + LLVM_OBJCOPY=powerpc-linux-gnu-objcopy pahole -J -j 
> > > --btf_features=encode_force,var,float,enum64,decl_tag,type_tag,optimized_func,consistent_func
> > >  --lang_exclude=rust .tmp_vmlinux.btf
> > > 
> > > Can I have access to that .tmp_vmlinux.btf file so that I can try to
> > > reproduce it here?
> > 
> > I don't have access to the build host (blaauw2) and I've some doubts
> > it would still have that file.
> > 
> > Maybe our kernel team and powerpc porters have suggestions?
> 
> I have root access to all powerpc/ppc64 machines (buildds and porterbox).
> 
> I'm cleaning up the porterbox now, disk is quite full, then you can try
> to build the kernel package on perotto.debian.net or I can try it myself.
> 
> I have seen the bug myself and I wanted to debug it, but the attempt was
> foiled by the fact that the disk on perotto is full (again).

I had a go yesterday and ran into the same problem.  I couldn't
reproduce with a small kernel config (allnoconfig + BPF + DEBUG_INFO +
DEBUG_INFO_BTF) and there wasn't enough disk space to build even one of
the Debian kernel flavours.

> Will take care of it and let you know when it's (some hours).

Thank you!

Ben.

-- 
Ben Hutchings
This sentence contradicts itself - no actually it doesn't.



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

Bug#1076564: pahole BTF processing seems flaky on powerpc

[Ben Hutchings]

Package: pahole
Version: 1.27-1
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

Several kernel builds on powerpc have failed recently:

6.8.12-1:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717234422&raw=1
6.9.9-1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.9-1&stamp=1720906547&raw=1
6.10-1~exp1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.10-1%7Eexp1&stamp=1721287862&raw=1

Note, these log files are up to 270 MB in size and should be
downloaded; at least Firefox becomes unresponsive when trying to
display them.

For each of these, the failure seems to start with an error from
pahole such as:

[102044] ARRAY (anon) type_id=99491 index_type_id=14 nr_elems=12 Error 
emitting BTF type
Encountered error while encoding BTF.

This does *not* happen consistently.  Compare these successful
builds:

6.8.12-1:
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.8.12-1&stamp=1717278092&raw=1
- This same version failed to build on the first try.
6.9.7-1: 
https://buildd.debian.org/status/fetch.php?pkg=linux&arch=powerpc&ver=6.9.7-1&stamp=1719538806&raw=1
- Earlier and later 6.9.x versions failed to build.

Both pahole versions 1.26-1 and 1.27-1 have been used in both
successful and failing builds.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.9.9-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages pahole depends on:
ii  libbpf1 1:1.4.3-1
ii  libc6   2.39-4
ii  libdw1t64   0.191-2
ii  libelf1t64  0.191-2
ii  zlib1g  1:1.3.dfsg+really1.3.1-1

pahole recommends no packages.

pahole suggests no packages.

-- debconf-show failed

Bug#1076500: firmware-brcm80211: Contains .txt files with a space

[Ben Hutchings]

On Wed, 17 Jul 2024 11:51:29 +0200 Roland Clobus 
wrote:
> Package: firmware-brcm80211
> Version: 20240610-1
> Severity: minor
> 
> Hello maintainers of firmware-brcm80211,
> 
> The new version (20240610-1) contains several new files with the .txt
> extension, that have a space (\x20) in their filename.
> 
> Is it intended to have filenames with spaces?

Yes this is intentional.

> (It currently causes the
> generation of live images to fail, see Jenkins
>
https://jenkins.debian.net/view/live/job/reproducible_debian_live_build_smallest
-
> build_sid/)
[...]

Please reassign this to whichever package needs to be changed for live
builds.

Ben.

-- 
Ben Hutchings
Sturgeon's Law: Ninety percent of everything is crap.



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

Bug#1075855: Kernel panic caused by aacraid module prevents normal boot

[Ben Hutchings]

Control: tag -1 moreinfo

You wrote:
> I've encountered an issue booting up Debian Testing with the latest
> kernel. The system reports something about kernel panic caused by
> aacraid module, then hangs completely during fsck step. Information
> about the installed system is in the attached .txt file. Note that
> hardware is different, because the SSD with Debian Testing has been
> extracted from the server for investigation.
> 
> Using the kernel parameters "pci=nocrs single" I was able to boot into
> emergency mode and see the error messages related to kernel panic.
> Photos attached.
> 
> Pulling the RAID controller out of the PCI-E slot restores normal boot.
[...]

There are (at least) 2 bugs here:

1. Something is preventing aacraid and ehci-hcd from allocating DMA
   buffers:
   "ehci-pci :00:1a.0: init :00:1a.0 fail, -12"
   "aacraid: unable to create mapping."

2. aacraid then double-frees a chunk of memory while handling the
   failure, causing the panic:
   "kernel BUG at mm/slub.c:448!"

I'm attaching a patch which should fix bug #2, which may help to get
more information about bug #1.

In principle you should be able to test this by following the
instructions at
<https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#id-1.6.6.4>
but currently the test-patches script has not been updated along with
the package and will take a lot more time and space than it should.

So instead I would suggest building a custom kernel based on the Debian
configuration, following the instructions at
<https://kernel-team.pages.debian.net/kernel-handbook/ch-common-tasks.html#s-common-building>
and applying this patch before you run "make clean".

Let us know if you have any difficulty with this.  If the system is
able to boot with a patched kernel, please send the full kernel log.

Ben.

-- 
Ben Hutchings
Knowledge is power.  France is bacon.

From 6ef2851f75411b379868119e693ce63440dde869 Mon Sep 17 00:00:00 2001
From: Ben Hutchings 
Date: Wed, 10 Jul 2024 18:41:07 +0200
Subject: [PATCH] aacraid: Fix double-free on probe failure

aac_probe_one() calls hardware-specific init functions through the
aac_driver_ident::init pointer, all of which eventually call down to
aac_init_adapter().

If aac_init_adapter() fails after allocating memory for
aac_dev::queues, it frees the memory but does not clear that member.

After the hardware-specific init function returns an error,
aac_probe_one() goes down an error path that frees the memory pointed
to by aac_dev::queues, resulting.in a double-free.

Reported-by: Michael Gordon 
References: https://bugs.debian.org/1075855
Fixes: 8e0c5ebde82b ("[SCSI] aacraid: Newer adapter communication iterface support")
Signed-off-by: Ben Hutchings 
---
 drivers/scsi/aacraid/comminit.c | 2 ++
 1 file changed, 2 insertions(+)

diff --git a/drivers/scsi/aacraid/comminit.c b/drivers/scsi/aacraid/comminit.c
index bd99c5492b7d..0f64b0244303 100644
--- a/drivers/scsi/aacraid/comminit.c
+++ b/drivers/scsi/aacraid/comminit.c
@@ -642,6 +642,7 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev)
 
 	if (aac_comm_init(dev)<0){
 		kfree(dev->queues);
+		dev->queues = NULL;
 		return NULL;
 	}
 	/*
@@ -649,6 +650,7 @@ struct aac_dev *aac_init_adapter(struct aac_dev *dev)
 	 */
 	if (aac_fib_setup(dev) < 0) {
 		kfree(dev->queues);
+		dev->queues = NULL;
 		return NULL;
 	}
 		


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

Bug#1076076: nmu: gcc-sh-elf_8.1

[Ben Hutchings]

Package: release.debian.org
Severity: normal
X-Debbugs-Cc: gcc-sh-...@packages.debian.org, carl917...@packages.debian.org
Control: affects -1 + src:gcc-sh-elf
User: release.debian@packages.debian.org
Usertags: binnmu

nmu gcc-sh-elf_8.1 . ANY . unstable . -m "Rebuild with newlib bug #1074608 
fixed"

Bug#1074359: nfs-kernel-server: Updating package unexports all

[Ben Hutchings]

filesystems
From: Ben Hutchings 
To: Hristo Venev 
Cc: Salvatore Bonaccorso , 1074...@bugs.debian.org
Date: Tue, 09 Jul 2024 20:09:06 +0200
Autocrypt: addr=b...@decadent.org.uk; prefer-encrypt=mutual;
 
keydata=mQINBEpZoUwBEADWqNn2/TvcJO2LyjGJjMQ6VG86RTfXdfYg31Y2UnksKm81Av+MdaF37fIQUeAmBpWoRsnKL96j0G6ElNZ8Tp1SfjWiAyWFE+O6WzdDX9uaczb+SFXM5twQbjwBYbCaiHuhV7ifz33uPeJUoOcqQmNFnZWC9EbEazXtbqnU1eQcKOLUC7kO/aKlVCxr3yChQ6J2uaOKNGJqFXb/4bUUdUSqrctGbvruUCYsEBk0VU0h0VKpkvHjw2C2rBSdJ4lAyXj7XMB5AYIY7aJvueZHk9WkethA4Xy90CwYS+3fuQFk1YJLpaQ9hT3wMpRYH7Du1+oKKySakh8r9i6x9OAPEVfHidyvNkyClUVYhUBXDFwTVXeDo5cFqZwQ35yaFbhph+OU0rMMGLCGeGommZ5MiwkizorFvfWvn7mloUNV1i6Y1JLfg1S0BhEiPedcbElTsnhg5TKDMeQUmv2uPjWqiVmhOTzhynHZKPY3PGsDxvnS8H2swcmbvKVAMVQFSliWmJiiaaaiVut7ty9EnFBQq1Th4Sx6yHzmnxIlP82Hl2VM9TsCeIlirf48S7+n8TubTsZkw8L7VJSXrmQnxXEKaFhZynXLC/g+Mdvzv9gY0YbjAu05pV42XwD3YBsvK+G3S/YKGmQ0Nn0r9owcFvVbusdkUyPWtI61HBWQFHplkiRR8QARAQABtB9CZW4gSHV0Y2hpbmdzIChET0I6IDE5NzctMDEtMTEpiQI4BBMBCAAiBQJKWaJTAhsDBgsJCAcDAgYVCgkICwMEFgIBAAIeAQIXgAAKCRDnv8jslYYRCUCJEADMkiPq+lgSwisPhlP+MlXkf3biDY/4SXfZgtP69J3llQzgK56RwxPHiCOM/kKvMOEcpxR2UzGRlWPk9WE2wpJ1Mcb4/R0KrJIimjJsr27HxAUI8oC/q2mnvVFD/VytIBQmfqkEqpFUgUGJwX7Xaq520vXCsrM45+n/H

FLYlIfF5YJwj9FxzhwyZyG70BcFU93PeHwyNxieIqSb9+brsuJWHF4FcVhpsjBCA9lxbkg0sAcbjxj4lduk4sNnCoEb6Y6jniKU6MBNwaqojDvo7KNMz66mUC1x0S50EjPsgAohW+zRgxFYeixiZk1o5qh+XE7H5eunHVRdTvEfunkgb17FGSEJPWPRUK6xmAc50LfSk4TFFEa9oi1qP6lMg/wuknnWIwij2EFm1KbWrpoFDZ+ZrfWffVCxyF1y/vqgtUe2GKwpe5i5UXMHksTjEArBRCPpXJmsdkG63e5FY89zov4jCA/xc9rQmF/4LBmS0/3qamInyr6gN00C/nyv6D8XMPq4bZ3cvOqzmqeQxZlX9XG6i9AmtTN6yWVjrG4rQFjqbAc71V6GQJflwnk0KT6cHvkOb2yq3YGqTOSC2NPqx1WVYFu7BcywUK1/cZwHuETehEoKMUstw3Zf+bMziUKBOyb/tQ8tmZKUZYyeBwKpdSBHcaLtSPiNPPHBZpa1Nj6tZrQjQmVuIEh1dGNoaW5ncyA8YmVuQGRlY2FkZW50Lm9yZy51az6JAjgEEwEIACIFAkpZoUwCGwMGCwkIBwMCBhUKCQgLAwQWAgEAAh4BAheAAAoJEOe/yOyVhhEJGisP/0mG2HEXyW6eXCEcW5PljrtDSFiZ99zP/SfWrG3sPO/SaQLHGkpOcabjqvmCIK4iLJ5nvKU9ZD6Tr6GMnVsaEmLpBQYrZNw2k3bJx+XNGyuPO7PAkk8sDGJo1ffhRfhhTUrfUplT8D+Bo171+ItIUW4lXPp8HHmiS6PY22H37bSU+twjTnNt0zJ7kI32ukhZxxoyGyQhQS8Oog5etnVL0+HqOpRLy5ZV/laF/XKX/MZodYHYAfzYE5sobZHPxhDsJdPXWy02ar0qrPfUmXjdZSzK96alUMiIBGWJwb0IPS+SnAxtMxY4PwiUmt9WmuXfbhWsi9NJGbhxJpwyi7T7MGU+MVxLau

KLXxy04rR/KoGRA9vQW3LHihOYmwXfQ05I/HK8LL2ZZp9PjNiUMG3rbfG65LgHFgA/K0Q3z6Hp4sir3gQyz+JkEYFjeRfbTTN7MmYqMVZpThY1aiGqaNue9sF3YMa/2eiWbpOYS2Pp1SY4E1p6uF82yJ3pxpqRj82O/PFBYqPjepkh1QGkDPFfiGN+YoNI/FkttYOBsEUC9WpJC/M4jsglVwxRax7LhSHzdve1BzCvq+tVXJgoIcmQf+jWyPEaPMpQh17hBo9994r7uMl6K3hsfeJk4z4fasVdyo0BbwPECNLAUE/BOCoqSL9IbkLRCqNRMEf63qGTYE3/tB9CZW4gSHV0Y2hpbmdzIDxiZW5oQGRlYmlhbi5vcmc+iQI4BBMBCAAiBQJKWaIJAhsDBgsJCAcDAgYVCgkICwMEFgIBAAIeAQIXgAAKCRDnv8jslYYRCdseD/9lsQAG8YxiJIUARYvY9Ob/2kry3GE0vgotPNgPolVgIYviX0lhmm26H+5+dJWZaNpkMHE6/qE1wkPVQFGlX5yRgZatKNC0rWH5kRuV1manzwglMMWvCUh5ji/bkdFwQc1cuNZf40bXCk51/TgPq5WJKv+bqwXQIaTdcd3xbGvTDNFNt3LjcnptYxeHylZzBLYWcQYos/s9IpDd5/jsw3DLkALp3bOXzR13wKxlPimM6Bs0VhMdUxu3/4pLzEuIN404gPggNMh9wOCLFzUowt14ozcLIRxiPORJE9w2e2wek/1wPD+nK91HgbLLVXFvymXncD/k01t7oRofapWCGrbHkYIGkNj/FxPPXdqWIx0hVYkSC3tyfetS8xzKZGkX7DZTbGgKj5ngTkGzcimNiIVd7y3oKmW+ucBNJ8R7Ub2uQ8iLIm7NFNVtVbX7FOvLs+mul88FzP54Adk4SD844RjegVMDn3TVt+pjtrmtFomkfbjm6dIDZVWRnMGhiNb11gTfuEWOiO/xRIiAeZ3MAWln1vmWNxz

pyYq5jpoT671X+I4VKh0COLS8q/2QrIow1p8mgRN5b7Cz1DIn1z8xcLJs3unvRnqvCebQuX5VtJxhL7/LgqMRzsgqgh6f8/USWbqOobLT+foIEMWJjQh+jg2DjEwtkh10WD5xpzCN0DY2TLQeQmVuIEh1dGNoaW5ncyA8YndoQGtlcm5lbC5vcmc+iQJPBBMBCAA5FiEErCspvTSmr92z9o8157/I7JWGEQkFAloYVe4CGwMGCwkIBwMCBhUKCQgLAwQWAgEAAh4BAheAAAoJEOe/yOyVhhEJ3iIQAIi4tqvz1VblcFubwa28F4oxxo4kKprId1TDVmR7DY/P02eKWLFG1yS2nR+saPUskb9wu2+kUCEEOAoO5YksgB0fYQcOTCzI1P1PyH8QWqulB4icA5BWs5im+JV+0/LjAvj8O5QYwNtTLoSS2zVgZGAom9ljlNkP1M+7Rs/zaqbhcQsczKJXDOSFpFkFmpLADyB9Y9gSFzok7tPbwMVl+MgvF0gVSoXcxPlqKXaN/l4dylQTudZ9zJX6vem9bwj7UQEEVqHgdaUw1BLit6EeRDtGR6bHmfhbcu0raujJPpeHUCEu5Ga1HJ5VwftLfpB2qOwLSfjcFkO77kVFgUhyn+dsf+uwXy1+2mAZ33dcyc85FSkCEF8pV5lHMDTHLIBOV0zglabXGYpKCjzrxZqU8KtFsnROk+5QuWaLGJK81jCpgYTn9nsEUqCtQQ8tB3JC291DagrBVgTqPtXFLeFhftwIMBou9lo85vge/8yIKVLAczlJ7A0eBVDwY/y3UTW9B+XwiITiA71bRMIqEKsO68WFT3cFm/G5LGoxERXCntEeuf+XmYZ5WcjBWyyF11unx4ZbPj7gdSrdLQxzHnpXfYs/J7s+YssnErvR8W02tjKj8L8ObQg078BqBI9DjrH9neAAYeACpZUStbsjUQuDdyup0bAEj4IMisU4Y+SFRfKbuQINBEpZoakBEACZUeVh

uZF8eDcpr7cpcev2gID8bCvtd7UH0GgiI3/sHfixcNkRk/SxMrJSmMtIQu/faqYwQsuLo2WT9rW2Pw/uxovv9UvFKg4n2huTP2JJHplNhlp2QppTy5HKw4bZDn7DJ2IyzmSZ9DfUbkwy3laTR11v6anT/dydwJy4bM234vnurlGqInmH+Em1PPSM8xMeKW0wismhfoqS9yZ8qbl0BRf5LEG7/xFo/JrM70RZkW+Sethz2gkyexicp9uWmQuSal2WxB2QzJRIN+nfdU4s7mNTiSqwHBQga6D/F32p2+z2inS5T5qJRP+OPq1fRFN6aor3CKTCvc1jBAL0gy+bqxPpKNNmwEqwVwrChuTWXRz8k8ZGjViP7otV1ExFgdphCxaCLwuPtjAbasvtEECg25M5STTggslYajdDsCCKkCF9AuaXC6yqJkxA5qOlHfMiJk53rBSsM5ikDdhz0gxij7IMTZxJNavQJHEDElN6hJtCqcyq4Y6bDuSWfEXpBJ5pMcbLqRUqhqQk5irWEAN5Ts9JwRjkPNN1UadQzDvhduc/U7KcYUVBvmFTcXkVlvp/o26PrcvRp+lKtG+S9Wkt/ON0oWmg1C/I9shkCBWfhjSQ7GNwIEk7IjIp9ygHKFgMcHZ6DzYbIZ4QrZ3wZvApsSmdHm70SFSJsqqsm+lJywARAQABiQIfBBgBCAAJBQJKWaGpAhsMAAoJEOe

Bug#1039883: linux: ext4 corruption with symlinks

[Ben Hutchings]

Control: tag -1 patch fixed-upstream

A fix was applied to the ext4 "dev" branch earlier today:
<https://git.kernel.org/pub/scm/linux/kernel/git/tytso/ext4.git/commit/?h=dev&id=7882b0187bbeb647967a7b5998ce4ad26ef68a9a>

I would still want to wait at least a week or two before cherry-picking
it, in case of regressions.

Ben.

-- 
Ben Hutchings
Who are all these weirdos? - David Bowie, on joining IRC



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

Bug#1074608: sh port doesn't work with current gcc

[Ben Hutchings]

Source: newlib
Version: 4.4.0.20231231-3
Severity: important
X-Debbugs-Cc: carl917...@packages.debian.org, gcc-sh-...@packages.debian.org

The sh port of newlib assumes common data which is no longer the
default behaviour of gcc.  This results in a broken gcc-sh-elf:

https://ci.debian.net/packages/g/gcc-sh-elf/testing/arm64/47454116/

This appears to be fixed upstream:

https://sourceware.org/git/?p=newlib-cygwin.git;a=commitdiff;h=36e398b04e91668403bac94b4c28f4822997b535

but I haven't yet tested this.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Bug#1074604: Fails to build with DEB_BUILD_OPTIONS=terse

[Ben Hutchings]

Source: xz-utils
Version: 5.6.2-1
Severity: normal

The debian/rules file includes:

ifneq (,$(findstring n,$(MAKEFLAGS)))
opt_no_act = --no-act
endif

which doesn't only match the -n option but also --no-print-directory,
which dpkg-buildpackage adds when DEB_BUILD_OPTIONS=terse.

This patch fixes the option matching:

--- a/debian/rules
+++ b/debian/rules
@@ -102,7 +102,7 @@
 opt_optimize_small += --disable-assembler
 endif
 
-ifneq (,$(findstring n,$(MAKEFLAGS)))
+ifneq (,$(findstring n,$(firstword -$(MAKEFLAGS
 opt_no_act = --no-act
 endif
 
--- END ---

(note the '-' is needed to handle the case where no single-letter
options are given).

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1074602: xz-utils versioned dependency on liblzma5 is too weak

[Ben Hutchings]

Source: xz-utils
Version: 5.6.2-1
Severity: serious
Tags: patch

xz-utils currently depends on liblzma5 (>= 5.6.0).  But this is
satisifed by liblzma5 (= 5.6.1+really5.4.5-1) which does not have the
symbols added in 5.6.0.  APT now upgrades both packages togeth by
default, but I've seen the broken configuration occur in
.

I think the right fix is to bump the minimum Debian versions for those
new symbols:

--- a/debian/symbols
+++ b/debian/symbols
@@ -24,5 +24,5 @@
  (arch=linux-any)lzma_stream_encoder_mt@XZ_5.2.2 5.2.2
  (arch=linux-any)lzma_stream_encoder_mt_memusage@XZ_5.1.2alpha 5.4
  (arch=linux-any)lzma_stream_encoder_mt_memusage@XZ_5.2.2 5.2.2
- XZ_5.6.0@XZ_5.6.0 5.6.0
- lzma_mt_block_size@XZ_5.6.0 5.6.0
+ XZ_5.6.0@XZ_5.6.0 5.6.2
+ lzma_mt_block_size@XZ_5.6.0 5.6.2
--- END ---

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.12-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

-- no debconf information

Bug#1061321: firmware-nonfree: Important changes coming up with upstream version 20230919

[Ben Hutchings]

On Mon, 22 Jan 2024 15:42:48 +0100 Diederik de Haas
 wrote:
> Source: firmware-nonfree
> Version: 20230625-2
> Severity: important
> 
> -BEGIN PGP SIGNED MESSAGE-
> Hash: SHA256
> 
> I'm currently working on an update for upstream version 20230919,
based
> upon MR86 (Release 20230804) [1], which itself is based upon MR85
> (Update to 20230625) [2] and I'm running into some major issues:
> 
> 1) Salsa's CI now always fails as the (archive) size is now too big
for
>    it to handle it.

I've addressed this for now by excluding:

- Many firmware versions that are no longer referenced
- All atomisp2 firmware
- All mlxsw firmware
- Some new Qualcomm SoC firmware

> 2) Upstream introduced a new keyword RawFile to 'list files that must
>    not be compressed'. I'm guessing one or more script files need to
be
>    updated for it?

The WHENCE file is parsed by the debian_linux.firmware module that's
currently in src:linux.  And yes that will need to be updated.

> 3) Upstream commit a0142c57045701b7557c3060af5c4246c420e4d8 titled
>    "ath10k/WCN3990: move wlanmdsp to qcom/sdm845" would mean moving
>    entries from ``debian/config/atheros`` to ``debian/config/qcom-
soc``
>    and adding a 'recommends' field to ``atheros``'s ``defines`` file.
>    Which means that qcom-soc recommends atheros and atheros
recommends
>    qcom-soc. Technically doable, but it raises the question whether
this
>    separation still makes sense. 

I think only the qcom-soc -> atheros recommendation is needed.

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



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

Bug#1064229: firmware-nonfree: CVE-2023-35061 CVE-2023-34983 CVE-2023-33875 CVE-2023-32651 CVE-2023-32644 CVE-2023-32642 CVE-2023-28720 CVE-2023-28374 CVE-2023-26586 CVE-2023-25951

[Ben Hutchings]

On Sun, 18 Feb 2024 20:45:07 +0100 Salvatore Bonaccorso
 wrote:
> Source: firmware-nonfree
> Version: 20230625-2
> Severity: important
> Tags: security upstream
> X-Debbugs-Cc: car...@debian.org, Debian Security Team

> 
> Hi,
> 
> The following vulnerabilities were published for firmware-nonfree.
> 
> They are addressed in the linux-firmware/20231211 upstream version.
[...]

According to
<https://www.intel.com/content/www/us/en/security-center/advisory/intel-sa-00947.html>
only CVE-2023-35061 affects Linux (presumably the other issues are in
the Windows driver, not the firmware).

Ben.

-- 
Ben Hutchings
Make three consecutive correct guesses and you will be considered
an expert.



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

Bug#1074156: procps: Depend or Recommend linux-sysctl-defaults

[Ben Hutchings]

On Mon, 2024-06-24 at 07:11 +1000, Craig Small wrote:
> On Mon, 24 Jun 2024 at 05:57, Ben Hutchings  wrote:
> > Please consider dropping /usr/lib/sysctl.d/99-protect-links.conf and
> > adding linux-sysctl-defaults to Depends or Recommends instead, once
> > that package is available in testing.
> Hi Ben,
>   This sounds like a great idea, config stuff for
> systemd-sysctl/sysctl doesn't belong in either package.
>  (with the added bonus of no more  Can I have my favourite kernel
> tweak bugs for me)
> 
> To actually do this, is it a matter of just not shipping that file and
> removing the maintscript of:
> rm_conffile /etc/sysctl.d/protect-links.conf 2:3.3.16-4~ procps

Since the version specified there is older than stable, this can be
dropped.

> mv_conffile /usr/lib/sysctl.d/protect-links.conf
> /usr/lib/sysctl.d/99-protect-links.conf 2:3.3.17-6~ procps

I don't think this line ever made sense.  Nothing under /usr/lib should
be a conffile and it doesn't seem like either of
/usr/lib/sysctl.d/{,99-}protect-links.conf was marked as a conffile. 
So this can also be dropped.

> Also procps ships an old /etc/sysctl.d/README.sysctl should that also
> be deleted or moved into this new package?

I would rather that stayed in procps.

Ben.

-- 
Ben Hutchings
You can't have everything.  Where would you put it?



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

Bug#572712: use hardened sysctl net.* settings per default

[Ben Hutchings]

Control: reassign -1 linux-sysctl-defaults 4.10
Control: tag -1 moreinfo

Better late than never: we now have a package providing a default
sysctl configuration file, which will (soon) be added to Depends or
Recommends of systemd and procps.

You wrote:
> I think it would be a good idea to use at least the settings blow per
> default:
> net.ipv4.conf.all.rp_filter=1

This is (effectively) set to 2 by the new configuration.

> net.ipv4.conf.all.accept_redirects = 0

This is not set by the new configuration.  The kernel default for this
is the inverse of net.ipv4.conf.all.forwarding, so it will be set on
routers but not hosts.

> net.ipv6.conf.all.accept_redirects = 0

This is not set and the kernel default is still 1.

> net.ipv4.conf.all.send_redirects = 0

This is not set and the kernel default is still 1.  It's documented to
only affect routers but I'm not sure if that's true.

> net.ipv4.conf.all.accept_source_route = 0

This is (effectively) set to 0 by the new configuration.

> net.ipv6.conf.all.accept_source_route = 0

That has always been the kernel default value.

[...]
> 1) The vast majority of Debian installations are NOT used as rooter

I think this is longer true: anything hosting VMs or containers that
have networking acts a router.

> 2) It's better to ship hardened settings per default, even if this
> "breaks" some things.
> 3) As the "broken" things are usually special setups (e.g. router)
> people that need them should be aware of what they're doing, and thus be
> able to set the sysctl settings they need.
> The "normal" end-user does usually however not know of these settings,
> their security impact and whether or not he should set them.

I think it can be acceptable to break really unusual configurations if
we provide appropriate notification in NEWS and release notes.

But like I said, I don't think routers are that rare now.

Which of the above would be a problem for routers?

> btw: I'd also suggest to activate syncookies per default, but this is
> already requested in #520668.

This has been the kernel default since 2.6.33.

Ben.

-- 
Ben Hutchings
Power corrupts.  Absolute power is kind of neat. - John Lehman



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

Bug#1074156: procps: Depend or Recommend linux-sysctl-defaults

[Ben Hutchings]

Package: procps
Version: 2:4.0.4-4
Severity: normal
X-Debbugs-Cc: debian-ker...@lists.debian.org

Following a conversation with the systemd maintainers at
,
I've added a new binary package linux-sysctl-defaults which installs
/usr/lib/sysctl.d/50-default.conf.

This new config file is based on a file from upstream systemd, but has
a couple of changes to match Debian's current defaults.  The intent is
that this configuration should be applied regardless of which kernel
package or init system is used.

Please consider dropping /usr/lib/sysctl.d/99-protect-links.conf and
adding linux-sysctl-defaults to Depends or Recommends instead, once
that package is available in testing.

Ben.

-- System Information:
Debian Release: trixie/sid
  APT prefers unstable-debug
  APT policy: (500, 'unstable-debug'), (500, 'stable-updates'), (500, 
'stable-security'), (500, 'oldstable-updates'), (500, 'oldstable-security'), 
(500, 'oldoldstable-updates'), (500, 'oldoldstable'), (500, 'unstable'), (500, 
'stable'), (500, 'oldstable'), (1, 'experimental')
Architecture: amd64 (x86_64)
Foreign Architectures: i386

Kernel: Linux 6.8.11-amd64 (SMP w/12 CPU threads; PREEMPT)
Locale: LANG=en_GB.UTF-8, LC_CTYPE=en_GB.UTF-8 (charmap=UTF-8), LANGUAGE not set
Shell: /bin/sh linked to /usr/bin/dash
Init: systemd (via /run/systemd/system)
LSM: AppArmor: enabled

Versions of packages procps depends on:
ii  init-system-helpers  1.66
ii  libc62.38-11
ii  libncursesw6 6.4+20240414-1
ii  libproc2-0   2:4.0.4-4
ii  libsystemd0  255.4-1+b1
ii  libtinfo66.4+20240414-1

Versions of packages procps recommends:
ii  psmisc  23.7-1

procps suggests no packages.

-- no debconf information

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Ben Hutchings]

On Sat, 2024-06-01 at 21:13 +0100, Sudip Mukherjee wrote:
> On Thu, 30 May 2024 at 14:24, Ben Hutchings  wrote:
> > 
> > On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote:
> > > On Thu, 30 May 2024 at 00:17, Sudip Mukherjee
> > >  wrote:
> > > > 
> > > > On Wed, 29 May 2024 at 23:27, Luca Boccassi  wrote:
> > > > > 
> > > > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings 
> > > > > 
> > > > > wrote:
> > > > > > On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> > > > > > > And so, it will be great if kernel team will like to package and
> > > > > > > maintain it, if not, then I will be happy to do it. Please
> > > > > > > reject this bug report if you think bpftool should not be done
> > > > > > > separately and should live inside kernel source package.
> > > > > > 
> > > > > > Since you are already maintaining libbpf I would be happy to hand
> > > > > over
> > > > > > bpftool to you.  I will try to discuss this at this evening's team
> > > > > > meeting.
> > 
> > Unfortunately we didn't have time for it this time.
> 
> No problem. And even if bpftool is built as a new package, I think
> Luca will like to keep bpftool with kernel team. Whoever maintains it,
> as long as a release version is packaged and not a development
> version, all is good.  So, I will leave it with you and the kernel
> team.
> Please ping me if you need me to do anything.
[...]

At today's meeting we agreed that bpftool should be split out, but
should remain under the kernel team with you as an uploader.

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

Bug#1039883: [PATCH] ext4: don't track ranges in fast_commit if inode has inlined data

[Ben Hutchings]

On Wed, 2024-06-19 at 08:58 +0100, Luis Henriques wrote:
> On Wed 19 Jun 2024 12:30:38 AM +02, Ben Hutchings wrote;
> 
> > On Tue, 2024-06-18 at 15:43 +0100, Luis Henriques (SUSE) wrote:
> > > When fast-commit needs to track ranges, it has to handle inodes that have
> > > inlined data in a different way because ext4_fc_write_inode_data(), in the
> > > actual commit path, will attempt to map the required blocks for the range.
> > > However, inodes that have inlined data will have it's data stored in
> > > inode->i_block and, eventually, in the extended attribute space.
> > > 
> > > Unfortunately, because fast commit doesn't currently support extended
> > > attributes, the solution is to mark this commit as ineligible.
> > > 
> > > Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039883
> > > Signed-off-by: Luis Henriques (SUSE) 
> > 
> > Reported-by: Hervé Werner 
> > Tested-by: Ben Hutchings 
> > 
> 
> Thanks a lot, Ben.
> 
> > I think this should also have:
> > 
> > Fixes: 9725958bb75c ("ext4: fast commit may miss tracking unwritten range 
> > during ftruncate")
> > 
> > unless you think the problem is even older than that.
> 
> If my understanding is correct (hopefully someone will confirm that!), I
> think the problem goes further back.  That commit just makes it more
> likely to be visible, but handling of inlined data is incorrect since the
> fast_commit merge.  So, I guess that's better to simply add:
> 
> Cc: sta...@vger.kernel.org

That makes sense to me.

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

Bug#1039883: [PATCH] ext4: don't track ranges in fast_commit if inode has inlined data

[Ben Hutchings]

On Tue, 2024-06-18 at 15:43 +0100, Luis Henriques (SUSE) wrote:
> When fast-commit needs to track ranges, it has to handle inodes that have
> inlined data in a different way because ext4_fc_write_inode_data(), in the
> actual commit path, will attempt to map the required blocks for the range.
> However, inodes that have inlined data will have it's data stored in
> inode->i_block and, eventually, in the extended attribute space.
> 
> Unfortunately, because fast commit doesn't currently support extended
> attributes, the solution is to mark this commit as ineligible.
> 
> Link: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1039883
> Signed-off-by: Luis Henriques (SUSE) 

Reported-by: Hervé Werner 
Tested-by: Ben Hutchings 

I think this should also have:

Fixes: 9725958bb75c ("ext4: fast commit may miss tracking unwritten range 
during ftruncate")

unless you think the problem is even older than that.

Ben.

> ---
>  fs/ext4/fast_commit.c | 6 ++
>  1 file changed, 6 insertions(+)
> 
> diff --git a/fs/ext4/fast_commit.c b/fs/ext4/fast_commit.c
> index 87c009e0c59a..d3a67bc06d10 100644
> --- a/fs/ext4/fast_commit.c
> +++ b/fs/ext4/fast_commit.c
> @@ -649,6 +649,12 @@ void ext4_fc_track_range(handle_t *handle, struct inode 
> *inode, ext4_lblk_t star
>   if (ext4_test_mount_flag(inode->i_sb, EXT4_MF_FC_INELIGIBLE))
>   return;
>  
> + if (ext4_has_inline_data(inode)) {
> + ext4_fc_mark_ineligible(inode->i_sb, EXT4_FC_REASON_XATTR,
> +     handle);
> + return;
> + }
> +
>   args.start = start;
>   args.end = end;
>  

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

Bug#890601: firmware-free: Source Package Doesn't Contain Source

[Ben Hutchings]

Control: clone -1 -2
Control: severity -1 wishlist
Control: retitle -2 firmware-free: Incomplete source for carl9170-1.fw

On Thu, 2024-06-06 at 21:18 +0200, Bastian Germann wrote:
> Hi Ben,
> 
> Am 05.06.24 um 20:59 schrieb Ben Hutchings:
> > Please identify precisely which policy requirement is violated.
> The package violates Policy 4.16. The file carl9170-1.fw contains parts of 
> newlib but does not include its source.
> According to carl9170fw/toolchain/Makefile, it was built with version 1.20.0.
> 
> Thanks for looking at the merge request. When you have uploaded a version 
> without carl9170-1.fw or fix it in some other 
> way, I am going to lower the severity again.

OK.  I'm splitting off the carl9170 issue to a separate bug report so
we can properly close that and leave this one open.

Ben.

-- 
Ben Hutchings
Beware of programmers who carry screwdrivers. - Leonard Brandwein



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

Bug#1039883: linux: ext4 corruption with symlinks

[Ben Hutchings]

On Sun, 5 Nov 2023 16:12:41 + Hervé Werner 
wrote:
> Hello
> 
> I'm sorry for the delay.
> 
> > Are you able to reliably preoeduce the issue and can bisect it to
> > the introducing commit?
> I faced this issue on real data but I struggled to find a reliable
> scenario to reproduce it. Here is what I just came up with:
>   sudo mkfs -t ext4 -O fast_commit,inline_data /dev/sdb
>   sudo mount /dev/sdb /mnt/
>   sudo install -d -o myuser /mnt/annex
>   cd /mnt/annex
>   git init && git annex init
>   for i in {1..2}; do
> for i in {1..1}; do
>   dd if=/dev/urandom of=file-${i} bs=1K count=1 2>/dev/null
> done
> git annex add -J cpus . >/dev/null && git annex sync -J cpus && git annex 
>fsck -J cpus >/dev/null
> git rm * && git annex sync  && git annex dropunused all
>   done
> 
> Then at some point the following error appears:
>   EXT4-fs error (device sdb): ext4_map_blocks:577: inode #3942343: block 4: 
>comm git-annex:w: lblock 1 mapped to illegal pblock 4 (length 1)
[...]

I can also reproduce this error message using the above script and:

- Linux 6.10-rc2
- A 2 GiB loopback devic instead of /dev/sdb

I bisected this back to:

commit 9725958bb75cdfa10f2ec11526fdb23e7485e8e4
Author: Xin Yin 
Date:   Thu Dec 23 11:23:37 2021 +0800
 
ext4: fast commit may miss tracking unwritten range during ftruncate

It is still possible to cleanly revert that commit from 6.10-rc2, and
doing so removes the error message.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#890601: firmware-free: Source Package Doesn't Contain Source

[Ben Hutchings]

Control: tag -1 moreinfo

On Tue, 2024-06-04 at 18:29 +0200, Bastian Germann wrote:
> Control: severity -1 serious
> 
> On Fri, 1 Mar 2024 12:48:42 +0100 Salvatore Bonaccorso wrote:
> > Would you be fine with those changes s proposed by Bastian, or want to
> > have it handled differently?
> > 
> > https://salsa.debian.org/kernel-team/firmware-free/-/merge_requests/4/diffs?commit_id=487a3891528cdf363f97c5ff20f9c6dcb6f49c33
> 
> As this is a Policy violation and the issue seems to be ignored I am raising 
> the severity.

Please identify precisely which policy requirement is violated.

Ben.

-- 
Ben Hutchings
Reality is just a crutch for people who can't handle science fiction.



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

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Ben Hutchings]

On Thu, 2024-05-30 at 14:00 +0100, Luca Boccassi wrote:
> On Thu, 30 May 2024 at 00:17, Sudip Mukherjee
>  wrote:
> > 
> > On Wed, 29 May 2024 at 23:27, Luca Boccassi  wrote:
> > > 
> > > On Wed, 29 May 2024 19:00:59 +0100 Ben Hutchings 
> > > wrote:
> > > > On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> > > > > And so, it will be great if kernel team will like to package and
> > > > > maintain it, if not, then I will be happy to do it. Please
> > > > > reject this bug report if you think bpftool should not be done
> > > > > separately and should live inside kernel source package.
> > > > 
> > > > Since you are already maintaining libbpf I would be happy to hand
> > > over
> > > > bpftool to you.  I will try to discuss this at this evening's team
> > > > meeting.

Unfortunately we didn't have time for it this time.

> > > What about moving libbpf and bpftool to the kernel team area under
> > > Salsa? That way more people can help, and it can use salsa-ci too
> > 
> > bpftool is already with the kernel team and being built from kernel
> > source. And I anticipated that bpftool will move to github like
> > upstream libbpf did and also mentioned that at
> > https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=948041#83. So, its
> > upto the kernel team what they want to do with bpftool -
> > 1. continue to build from kernel source and we can just close this bug
> > 2. Split bpftool from kernel source and package it from github. The
> > kernel team can maintain if they want to maintain an userspace
> > package. If the kernel team does not want to maintain it, I can do
> > that.
> > 
> > About libbpf, I am confused with your message. What kind of help? Are
> > you seeing that libbpf is not maintained properly?
> 
> I'm not talking about the upstream source, but about the debian
> repository: given both of these are inextricably tied to the kernel, I
> think it would be good to have the downstream repositories in salsa,
> in the kernel-team area - and of course, still including yourself as
> repo owner. The kernel team is not only for the kernel package, but
> also other kernel-adjacent packages like ethtool, iproute2, firmware,
> iw, etc: https://salsa.debian.org/kernel-team

Ah, I hadn't noticed that the libbpf packaging was on Github.

I agree with Luca that it would be preferable to have these on Salsa
but I don't have a strong opinion on whether they should be in the
kernel-team group.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#1057282: linux-image-6.5.0-0.deb12.1-arm64: arm64 kernel upgrade makes systems unresponsive

[Ben Hutchings]

On Thu, 2024-05-16 at 08:09 +0200, Paul Gevers wrote:
> Hi Ben (and all the rest),
> 
> On 15-05-2024 9:56 p.m., Ben Hutchings wrote:
> > Apologies for leaving this bug for so long.
> 
> NP, part of live I guess.
> 
> > Is this bug still occurring?
> 
> I don't know. The problem was severe enough for us to abandon the idea 
> of running the backport kernels on our arm64 hosts, so we went back to 
> the stable kernel there.
> 
> > I had a look for possibly related fixes,
> > and found:
> > 
> > commit 22e111ed6c83dcde3037fc81176012721bc34c0b
> 
> [...]
> 
> > The fix went into
> > 6.8-rc1 and was backported to 6.6.15, so Debian versions 6.6.15-1
> > onward should have it.
> 
> > commit a8b0026847b8c43445c921ad2c85521c92eb175f
> 
> [...]
> 
> > which went into 6.8 but was *not* backported.
> 
> If you think it worth enough knowing if either is the case, I can 
> install the backports kernel again on the arm64 hosts, but obviously 
> that will be annoying for us. Please let me know if I should pursue this 
> (I would be expecting a bit quicker turn around on this bug if you say 
> yes now ;) ).

If you can test with the unstable kernel that would be great.  If you
are limited to only stable and backports, then you should probably wait
until 6.8 is in backports rather than testing the current 6.7 backport
that has only one of the fixes.

> > If the bug is still occurring, can you say what type of filesystem
> > rsync is being run on?
> 
> I'm not sure if this is the answer you're looking for, we use ext4.

Yes that's what I meant.

Ben.

-- 
Ben Hutchings
It is easier to write an incorrect program
than to understand a correct one.



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

Bug#1063754: fat-modules: SD corruption upon opening file on Linux desktop

[Ben Hutchings]

Control: tag -1 unreproducible moreinfo

Hi Bud,

Please understand that when I aksed you to carry out a specific test, I
had a good reason for doing exactly that.  The tests that you have
carried out so far, while useful, don't provide the same information.

Ben.

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



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

Bug#1057290: bpftool: please build from https://github.com/libbpf/bpftool

[Ben Hutchings]

On Sat, 2023-12-02 at 20:04 +, Sudip Mukherjee wrote:
> Package: bpftool
> Severity: wishlist
> X-Debbugs-Cc: sudipm.mukher...@gmail.com, debian-ker...@lists.debian.org, 
> debian-de...@lists.debian.org
> 
> The official home for bpftool is now the github repo [1] but
> keeps the kernel as the authoritative source code of bpftool and
> is developed as part of the bpf-next Linux source tree.

I don't really understand the distinction they're trying to make
between "official" and "authoritative"...

> The Maintainers have said "Please use this Github repository for
> building and packaging bpftool" at [2] The announcement was at [3].
>
> imho, packaging it from the github instead of the kernel source
> will fix three issues:
> 1. bpftool will use libbpf available in Debian, whereas now it is
> building a libbpf.a from the development codes of libbpf in the
> kernel source and using that.

That's certainly a good reason.

> 2. The official releases of bpftool is done in the github repo
> when the bpf maintainers decides the code is ready for a release.
> But the Debian bpftool package is done from the kernel source and
> so follows the kernel releases. And as a result, when a new
> kernel is released which Debian kernel team will then pickup may
> not have a bpftool release worthy code. For example, bpftool v7.3
> was released on 23/11/2023,

So bpftool does not get stabilised in the kernel?  I don't really
understand why it's still in the kernel tree at all then!

> 3. bpftool package in Debian is from the kernel v6.5.13 and so
> looking at the source and git commits I can see the that the
> Debian package is missing 25 commits which is in the bpftool v7.3
> release.

Right.

> Do we package bpftool from their github repo independent of the
> kernel update? Then we will need to remove the bpftool building
> bits from the Debian kernel source and create a separate package
> for bpftool.
> 
> And so, it will be great if kernel team will like to package and
> maintain it, if not, then I will be happy to do it. Please
> reject this bug report if you think bpftool should not be done
> separately and should live inside kernel source package.

Since you are already maintaining libbpf I would be happy to hand over
bpftool to you.  I will try to discuss this at this evening's team
meeting.

Ben.

> 
> [1]. https://github.com/libbpf/bpftool
> [2]. https://github.com/libbpf/bpftool/blob/main/README.md?plain=1#L18
> [3]. 
> https://lore.kernel.org/bpf/267a35a6-a045-c025-c2d9-78afbf6fc...@isovalent.com/
> 

-- 
Ben Hutchings
Always try to do things in chronological order;
it's less confusing that way.



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

Bug#1071236: general: keyboard, mouse, and trackpad behave inconsistently; seemingly phantom input device events occur unpredictably

[Ben Hutchings]

On Wed, 2024-05-22 at 00:41 +0200, Salvo Tomaselli wrote:
> Hello,
> 
> you can run "reportbug packagename" to report against a specific package.
> 
> You can find out how your kernel package is called with 
> 
> dpkg -l "linux-image-*"

That step isn't necessary because "reportbug kernel" automagically does
the right thing.

Ben.

-- 
Ben Hutchings
Experience is what causes a person to make new mistakes
instead of old ones.



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