Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On the other hand, though - creating this dependency *will* break workflows and cause many unexpected side-effects, as it broke mine last month: I have linux-headers-cloud-amd64 installed; when this package hit BPO, it brought in linux-image-cloud-amd64, which grub then tracked as the most recent kernel and booted into, causing (ironically) many drivers to be missing and the system failed to boot correctly as a result (it is not a cloud server, but it does build modules *for* cloud servers). It also brought my /boot to 98% full, fortunately this did not cause problems by itself, but obviously came close to doing so. It has been consistently asserted that installing superfluous image files is harmless; I want to point out that this is anything but true, even aside from the more philosophical issues around having "source" packages depend on "binary" ones, and the precise meaning of "significant functionality" in the Debian policy. Colm On Tue, 2 Apr 2024 at 17:57, Colm Buckley wrote: > Please explain. I am really sorry to be dragging this discussion out, but > I honestly think there is some information I'm missing. Please tell me what > I am missing here? ** PLEASE ** read it before replying; I am honestly not > trying to undermine you, just point out a serious problem with the apparent > logic. > > Your proposal is to have linux-headers-X depend on linux-image-X. > > But: > > * User installs linux-image-X and linux-headers-X > * User builds modules for this image using DKMS or whatever > * User then does "apt install linux-image-Y" - this is the exact scenario > you hope to guard against? > ... nothing brings in linux-headers-Y; the user is *still* left without > their new modules. > > Your proposal will only work if the user remembers to upgrade -headers... > which will fix the problem even without the dependency! > > I fully understand that there is a desire for users to keep linux-image-* > and linux-headers-* in synch; my proposal is that a *further* package be > created - linux-complete-VERSION - which depends on both of them. Users who > have that package installed would always have the right thing happen. To > encourage adoption, it could be in "Suggests" from each, and maybe even in > DKMS? > > Colm > > > On Tue, 2 Apr 2024 at 17:51, Bastian Blank wrote: > >> On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote: >> > ... but the proposed dependency wouldn't address that, right? >> >> Actually it does. It ties all packages together with = dependencies. >> For an upgrade, all packages need to be unpacked first and only then the >> maintainer scripts can run. >> >> There are cases where this can be broken, but working most of the time >> is better then working never. >> >> Bastian >> >> -- >> Prepare for tomorrow -- get ready. >> -- Edith Keeler, "The City On the Edge of Forever", >>stardate unknown >> > > > -- > Colm Buckley | c...@tuatha.org > > -- Colm Buckley | c...@tuatha.org
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 at 16:52, Bastian Blank wrote: > > On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote: > > Let's look at this the other way around: if there was no dependency, in > > what scenario would things break and how? > > - linux-headers-bla and linux-image-bla are installed > - linux-image-bla is uipgraded > - no modules will be built, because the matching headers are missing Got it, thanks, that makes sense to me as a problem and it would be good to solve. Is the root cause that the image and the headers package are published and uploaded separately, due to signing?
Re: Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Please explain. I am really sorry to be dragging this discussion out, but I honestly think there is some information I'm missing. Please tell me what I am missing here? ** PLEASE ** read it before replying; I am honestly not trying to undermine you, just point out a serious problem with the apparent logic. Your proposal is to have linux-headers-X depend on linux-image-X. But: * User installs linux-image-X and linux-headers-X * User builds modules for this image using DKMS or whatever * User then does "apt install linux-image-Y" - this is the exact scenario you hope to guard against? ... nothing brings in linux-headers-Y; the user is *still* left without their new modules. Your proposal will only work if the user remembers to upgrade -headers... which will fix the problem even without the dependency! I fully understand that there is a desire for users to keep linux-image-* and linux-headers-* in synch; my proposal is that a *further* package be created - linux-complete-VERSION - which depends on both of them. Users who have that package installed would always have the right thing happen. To encourage adoption, it could be in "Suggests" from each, and maybe even in DKMS? Colm On Tue, 2 Apr 2024 at 17:51, Bastian Blank wrote: > On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote: > > ... but the proposed dependency wouldn't address that, right? > > Actually it does. It ties all packages together with = dependencies. > For an upgrade, all packages need to be unpacked first and only then the > maintainer scripts can run. > > There are cases where this can be broken, but working most of the time > is better then working never. > > Bastian > > -- > Prepare for tomorrow -- get ready. > -- Edith Keeler, "The City On the Edge of Forever", >stardate unknown > -- Colm Buckley | c...@tuatha.org
Re: Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, Apr 02, 2024 at 05:38:01PM +0100, Colm Buckley wrote: > ... but the proposed dependency wouldn't address that, right? Actually it does. It ties all packages together with = dependencies. For an upgrade, all packages need to be unpacked first and only then the maintainer scripts can run. There are cases where this can be broken, but working most of the time is better then working never. Bastian -- Prepare for tomorrow -- get ready. -- Edith Keeler, "The City On the Edge of Forever", stardate unknown
Re: Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Bastian wrote: > Luca wrote: >> Let's look at this the other way around: if there was no dependency, in >> what scenario would things break and how? > - linux-headers-bla and linux-image-bla are installed > - linux-image-bla is uipgraded > - no modules will be built, because the matching headers are missing ... but the proposed dependency wouldn't address that, right? linux-headers-bla would keep linux-image-bla around, but if the user then installed linux-image-newbla, then nothing would be pulling in the corresponding headers. As I said in the other message ( https://lists.debian.org/debian-kernel/2024/04/msg00024.html), the only ways to address this would be to have -image depend on -headers (I think this is a bad idea, as do you), or to have a higher-order "linux-complete" package which depends on both (and could be Suggests: by both). Users who need to keep -image and -headers in sync could install this. Thank you for taking the time to explain the problem; the earlier parts of this thread were very confusing to me. Colm -- Colm Buckley | c...@tuatha.org
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, Apr 02, 2024 at 03:59:25PM +0100, Luca Boccassi wrote: > Let's look at this the other way around: if there was no dependency, in > what scenario would things break and how? - linux-headers-bla and linux-image-bla are installed - linux-image-bla is uipgraded - no modules will be built, because the matching headers are missing Bastian -- If some day we are defeated, well, war has its fortunes, good and bad. -- Commander Kor, "Errand of Mercy", stardate 3201.7
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Tue, 2 Apr 2024 08:27:39 +0200 Bastian Blank wrote: > On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote: > > Why do dkms modules need the image installed to be built? At the very > > least they didn't use to, the headers were enough last time I had to > > deal with that stuff for the nvidia drivers > > dkms is used to build modules for the kernel that is just being > installed. To do that it needs also the headers in matching versions. > > As the image can't depend on the headers, some other way was needed. Sorry, I am still unable to understand the issue: dkms can and does build modules for all installed _headers_ (plural). The fact that the headers pull in a corresponding image does not change that fact, as far as I can tell. In fact, it doesn't need any images at all, again as far as I know. Let's look at this the other way around: if there was no dependency, in what scenario would things break and how? -- Kind regards, Luca Boccassi
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Apr 01, 2024 at 09:25:40PM +, Luca Boccassi wrote: > Why do dkms modules need the image installed to be built? At the very > least they didn't use to, the headers were enough last time I had to > deal with that stuff for the nvidia drivers dkms is used to build modules for the kernel that is just being installed. To do that it needs also the headers in matching versions. As the image can't depend on the headers, some other way was needed. Bastian -- Spock: We suffered 23 casualties in that attack, Captain.
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 1 Apr 2024 at 21:49, Bastian Blank wrote: > > Control: tags -1 wontfix > > On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > As said, this dependency is to make sure kernel modules are properly > built. vmlinux.h is not for kernel modules. Why do dkms modules need the image installed to be built? At the very least they didn't use to, the headers were enough last time I had to deal with that stuff for the nvidia drivers
Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Processing control commands: > tags -1 wontfix Bug #1064976 [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Added tag(s) wontfix. -- 1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Thu, Feb 29, 2024 at 01:38:12PM +0100, Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. As said, this dependency is to make sure kernel modules are properly built. vmlinux.h is not for kernel modules. Bastian -- Mind your own business, Spock. I'm sick of your halfbreed interference.
Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 13:54:49 +0100 Bastian Blank wrote: > On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote: > > > But we where talking about kernel modules. > > There are kernel modules using BPF stuff? Never seen one, do you have > > an example? > > No idea, but they get linked BTF information, so you could use them. Sure, but it's a bit of an unusual case to say the least, and I'm not aware of dkms packages in Debian doing that (happy to stand corrected if that's not the case). So surely any out-of-distro dkms package doing that should just ensure they pull in the dependencies they need for it? Assuming it's even needed. As far as I understand, the point of vmlinux.h is that it gives the equivalent information generated from BTF. The issue is that pulling the headers package also pulls the image, initramfs and all that machinery. We are going to depend on the headers package in src:systemd from the next release to get the vmlinux.h, and pulling all that stuff too adds considerable weight to the build dependency installation job. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, Mar 04, 2024 at 11:28:12AM +, Luca Boccassi wrote: > > But we where talking about kernel modules. > There are kernel modules using BPF stuff? Never seen one, do you have > an example? No idea, but they get linked BTF information, so you could use them. Bastian -- Those who hate and fight must stop themselves -- otherwise it is not stopped. -- Spock, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Mon, 4 Mar 2024 at 10:32, Bastian Blank wrote: > > On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > > Yes precisely, the bpf program source can just include vmlinux.h and it > > should build and run as expected. > > But we where talking about kernel modules. > > Bastian There are kernel modules using BPF stuff? Never seen one, do you have an example?
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Sat, Mar 02, 2024 at 12:40:07AM +, Luca Boccassi wrote: > Yes precisely, the bpf program source can just include vmlinux.h and it > should build and run as expected. But we where talking about kernel modules. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
As per the discussion in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 - once vmlinux.h is included with linux-headers, the warning about cmd_btf_ko etc. should be harmless, as that file should already be available (ie: there's no need to generate it again as part of kernel build). Am I missing something else? I confess I have only a very small amount of experience with BPF code; I played with building a few modules, but I don't use it regularly. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 14:23:05 + Colm Buckley wrote: > On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > > With the new vmlinux.h shipped in the headers package, the BTF case > > > should be covered. > > > > The relevant code in Linux is: > > > > | quiet_cmd_btf_ko = BTF [M] $@ > > | cmd_btf_ko = > \ > > | if [ ! -f vmlinux ]; then > \ > > | printf "Skipping BTF generation for %s due to > unavailability of vmlinux\n" $@ 1>&2; \ > > | else > \ > > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) > --btf_base vmlinux $@; \ > > | $(RESOLVE_BTFIDS) -b vmlinux $@; > \ > > | fi; > > > > Which change is needed here to use vmlinux.h instead? > > My understanding is that you don't need this command at all; the included > vmlinux.h already contains the necessary type definitions for libbpf, for > the kernel source version in question - ie: instead of needing to run > pahole or bpftool to extract these definitions from a specific vmlinux > image, this file is distributed with them already included. Yes precisely, the bpf program source can just include vmlinux.h and it should build and run as expected. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > > With the new vmlinux.h shipped in the headers package, the BTF case > > should be covered. > > The relevant code in Linux is: > > | quiet_cmd_btf_ko = BTF [M] $@ > | cmd_btf_ko = \ > | if [ ! -f vmlinux ]; then \ > | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ > | else \ > | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ > | $(RESOLVE_BTFIDS) -b vmlinux $@; \ > | fi; > > Which change is needed here to use vmlinux.h instead? My understanding is that you don't need this command at all; the included vmlinux.h already contains the necessary type definitions for libbpf, for the kernel source version in question - ie: instead of needing to run pahole or bpftool to extract these definitions from a specific vmlinux image, this file is distributed with them already included. Colm
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 12:12:21PM +, Luca Boccassi wrote: > With the new vmlinux.h shipped in the headers package, the BTF case > should be covered. The relevant code in Linux is: | quiet_cmd_btf_ko = BTF [M] $@ | cmd_btf_ko = \ | if [ ! -f vmlinux ]; then \ | printf "Skipping BTF generation for %s due to unavailability of vmlinux\n" $@ 1>&2; \ | else\ | LLVM_OBJCOPY="$(OBJCOPY)" $(PAHOLE) -J $(PAHOLE_FLAGS) --btf_base vmlinux $@; \ | $(RESOLVE_BTFIDS) -b vmlinux $@;\ | fi; Which change is needed here to use vmlinux.h instead? Bastian -- Bones: "The man's DEAD, Jim!"
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank wrote: > On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > > Why was this never the case before? And can you be more precise about what > > "stuff" is missing? Is there a previous bug report I can reference? > > It complains loudly about BTF. With the new vmlinux.h shipped in the headers package, the BTF case should be covered. I think we should nudge packages to use that, rather than looking at the kernel image, or worse sysfs from the running kernel, which is completely wrong for obvious reasons. -- Kind regards, Luca Boccassi signature.asc Description: This is a digitally signed message part
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
> The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. To be honest, "it does not really fail without, but lacks stuff" seems like the use case that "Recommends:" (or even "Suggests:") was designed for, rather than "Depends:", don't you agree? I'm not sure, of course, what problem is being addressed here; it's possible that there's a more elegant solution available. Is there a previous bug describing the problem? My concern is that I have a specific build server which builds kernels and modules for other machines in a farm. It needs to have the header files for specific target kernel versions installed, but it is not sensible to have the corresponding image packages installed (in many cases, those images wouldn't even run on this build server). Colm On Thu 29 Feb 2024, 11:03 Colm Buckley, wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? > > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. > > Colm > > > On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > >> Control: tags -1 wontfix >> >> On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: >> > The linux-headers packages for kernel version 6.6 seem to depend on the >> corresponding >> > linux-image packages, but I believe that this should not be the case >> (and was not the >> > case in previous versions). >> >> It should. The build wants the image available (it does not really fail >> without, but lacks stuff) and we need some dependency to keep image and >> headers in sync for people using dkms. >> >> Bastian >> >> -- >> Vulcans never bluff. >> -- Spock, "The Doomsday Machine", stardate 4202.1 >> >
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
On Thu, Feb 29, 2024 at 11:03:11AM +, Colm Buckley wrote: > Why was this never the case before? And can you be more precise about what > "stuff" is missing? Is there a previous bug report I can reference? It complains loudly about BTF. > DKMS should handle its own dependencies, I'd have thought - I see a clear > use case for installing header files without the corresponding images. Sure, but installing the image does not break much. But not installing the headers breaks much. Maybe you can provide a proposal how that would work? Bastian -- Four thousand throats may be cut in one night by a running man. -- Klingon Soldier, "Day of the Dove", stardate unknown
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Why was this never the case before? And can you be more precise about what "stuff" is missing? Is there a previous bug report I can reference? DKMS should handle its own dependencies, I'd have thought - I see a clear use case for installing header files without the corresponding images. Colm On Thu 29 Feb 2024, 10:31 Bastian Blank, wrote: > Control: tags -1 wontfix > > On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > > The linux-headers packages for kernel version 6.6 seem to depend on the > corresponding > > linux-image packages, but I believe that this should not be the case > (and was not the > > case in previous versions). > > It should. The build wants the image available (it does not really fail > without, but lacks stuff) and we need some dependency to keep image and > headers in sync for people using dkms. > > Bastian > > -- > Vulcans never bluff. > -- Spock, "The Doomsday Machine", stardate 4202.1 >
Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Processing control commands: > tags -1 wontfix Bug #1064976 [linux-headers-amd64] linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Added tag(s) wontfix. -- 1064976: https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=1064976 Debian Bug Tracking System Contact ow...@bugs.debian.org with problems
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Control: tags -1 wontfix On Wed, Feb 28, 2024 at 05:19:39PM +, Colm Buckley wrote: > The linux-headers packages for kernel version 6.6 seem to depend on the > corresponding > linux-image packages, but I believe that this should not be the case (and was > not the > case in previous versions). It should. The build wants the image available (it does not really fail without, but lacks stuff) and we need some dependency to keep image and headers in sync for people using dkms. Bastian -- Vulcans never bluff. -- Spock, "The Doomsday Machine", stardate 4202.1
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Some previous versions, for contrast: % apt-cache depends linux-headers-6.5.0-0.deb12.4-amd64 linux-headers-6.5.0-0.deb12.4-amd64 Depends: linux-headers-6.5.0-0.deb12.4-common Depends: linux-kbuild-6.5.0-0.deb12.4 Depends: linux-compiler-gcc-12-x86 % apt-cache depends linux-headers-6.1.0-18-amd64 linux-headers-6.1.0-18-amd64 Depends: linux-headers-6.1.0-18-common Depends: linux-kbuild-6.1 Depends: linux-compiler-gcc-12-x86
Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package
Package: linux-headers-6.6.13+bpo-amd64 Severity: normal X-Debbugs-Cc: c...@tuatha.org Dear Maintainer, The linux-headers packages for kernel version 6.6 seem to depend on the corresponding linux-image packages, but I believe that this should not be the case (and was not the case in previous versions). It should be possible to install the header files for a particular kernel version (eg: to allow for modules to be built for that version, which is my use case) without requiring the kernel image to be installed. I think the headers packages should depend on a suitable version of linux-kbuild and any necessary glibc headers or other build artifacts, but not on linux-image-* Many thanks, Colm -- System Information: Debian Release: 12.5 APT prefers stable-updates APT policy: (900, 'stable-updates'), (900, 'stable-security'), (900, 'stable') Architecture: amd64 (x86_64) Kernel: Linux 6.5.0-0.deb12.4-amd64 (SMP w/8 CPU threads; PREEMPT) Kernel taint flags: TAINT_PROPRIETARY_MODULE, TAINT_OOT_MODULE, TAINT_UNSIGNED_MODULE Locale: LANG=en_IE.UTF-8, LC_CTYPE=en_IE.UTF-8 (charmap=UTF-8), LANGUAGE not set Shell: /bin/sh linked to /usr/bin/dash Init: systemd (via /run/systemd/system) Versions of packages linux-headers-6.6.13+bpo-amd64 depends on: ii gcc-1212.2.0-14 pn linux-headers-6.6.13+bpo-common pn linux-image-6.6.13+bpo-amd64 | linux-image-6.6.13+bpo-amd64-unsi gned pn linux-kbuild-6.6.13+bpo linux-headers-6.6.13+bpo-amd64 recommends no packages. linux-headers-6.6.13+bpo-amd64 suggests no packages.
