Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.debian.kernel > #81958 > unrolled thread

Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package

Back to article view | Back to linux.debian.kernel

Contents

  Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-28 18:30 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-28 18:40 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 11:40 +0100
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 12:20 +0100
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 12:30 +0100
          Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-02-29 13:20 +0100
            Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-02-29 13:40 +0100
              Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:52 +0200
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 12:40 +0100
    Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-02-29 11:40 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-02-29 15:40 +0100
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-02 01:50 +0100
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-03-04 11:40 +0100
          Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-04 12:40 +0100
            Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-03-04 14:00 +0100
              Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-03-06 15:20 +0100
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-03-04 11:10 +0100
    Bug#1064976:  colm <colm@tuatha.org> - 2024-03-07 12:30 +0100
    Bug#1064976:  Colm Buckley <colm@tuatha.org> - 2024-03-14 11:00 +0100
    Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-* Colm Buckley <colm@tuatha.org> - 2024-03-19 13:40 +0100
      Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-* Luca Boccassi <bluca@debian.org> - 2024-04-06 09:52 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:50 +0200
      Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:51 +0200
        Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Bastian Blank <waldi@debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Bastian Blank <waldi@debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Colm Buckley <colm@tuatha.org> - 2024-04-06 09:50 +0200
    Processed: Re: Bug#1064976: linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:50 +0200
    Bug#1064976: linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Luca Boccassi <bluca@debian.org> - 2024-04-06 09:50 +0200
    Processed: Re: linux-headers-amd64: linux-headers-* incorrectly  depends on linux-image-* "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Having headers depend on image - bad idea I think Colm Buckley <colm@tuatha.org> - 2024-04-06 09:51 +0200
    Processed: Having headers depend on image - bad idea I think "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package) Bastian Blank <waldi@debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: linux-headers-6.6.13 bpo-amd64 incorrectly depends on the corresponding linux-image-amd64 package Colm Buckley <colm@tuatha.org> - 2024-04-06 09:51 +0200
    Bug#1064976: marked as done (linux-headers-6.6.13+bpo-amd64  incorrectly depends on the corresponding linux-image-amd64 package) "Debian Bug Tracking System" <owner@bugs.debian.org> - 2024-04-06 09:51 +0200
    Bug#1064976: Sad user. Colm Buckley <colm@tuatha.org> - 2024-05-16 23:30 +0200

Page 1 of 2  [1] 2  Next page →

#81958 — 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: colm@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-12                                                            12.2.0-14
pn  linux-headers-6.6.13+bpo-common                                   <none>
pn  linux-image-6.6.13+bpo-amd64 | linux-image-6.6.13+bpo-amd64-unsi  <none>
    gned
pn  linux-kbuild-6.6.13+bpo                                           <none>

linux-headers-6.6.13+bpo-amd64 recommends no packages.

linux-headers-6.6.13+bpo-amd64 suggests no packages.

[toc] | [next] | [standalone]

#81959

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#81962

Control: tags -1 wontfix

On Wed, Feb 28, 2024 at 05:19:39PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#81964

[Multipart message — attachments visible in raw view] — view raw

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, <waldi@debian.org> wrote:

> Control: tags -1 wontfix
>
> On Wed, Feb 28, 2024 at 05:19:39PM +0000, 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
>

[toc] | [prev] | [next] | [standalone]

#81965

On Thu, Feb 29, 2024 at 11:03:11AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#81967

[Multipart message — attachments visible in raw view] — view raw

On Thu, 29 Feb 2024 12:25:27 +0100 Bastian Blank <waldi@debian.org>
wrote:
> On Thu, Feb 29, 2024 at 11:03:11AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#81968

On Thu, Feb 29, 2024 at 12:12:21PM +0000, 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!"

[toc] | [prev] | [next] | [standalone]

#82174

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 +0000, 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.

[toc] | [prev] | [next] | [standalone]

#81966

[Multipart message — attachments visible in raw view] — view raw

> 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, <colm@tuatha.org> 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, <waldi@debian.org> wrote:
>
>> Control: tags -1 wontfix
>>
>> On Wed, Feb 28, 2024 at 05:19:39PM +0000, 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
>>
>

[toc] | [prev] | [next] | [standalone]

#81963 — 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 owner@bugs.debian.org with problems

[toc] | [prev] | [next] | [standalone]

#81969

[Multipart message — attachments visible in raw view] — view raw

On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank <waldi@debian.org> wrote:
> On Thu, Feb 29, 2024 at 12:12:21PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#81983

[Multipart message — attachments visible in raw view] — view raw

On Thu, 29 Feb 2024 14:23:05 +0000 Colm Buckley <colm@tuatha.org>
wrote:
> On Thu, 29 Feb 2024 13:38:12 +0100 Bastian Blank <waldi@debian.org>
wrote:
> > On Thu, Feb 29, 2024 at 12:12:21PM +0000, 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

[toc] | [prev] | [next] | [standalone]

#82015

On Sat, Mar 02, 2024 at 12:40:07AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#82021

On Mon, 4 Mar 2024 at 10:32, Bastian Blank <waldi@debian.org> wrote:
>
> On Sat, Mar 02, 2024 at 12:40:07AM +0000, 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?

[toc] | [prev] | [next] | [standalone]

#82023

On Mon, Mar 04, 2024 at 11:28:12AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#82034

[Multipart message — attachments visible in raw view] — view raw

On Mon, 4 Mar 2024 13:54:49 +0100 Bastian Blank <waldi@debian.org>
wrote:
> On Mon, Mar 04, 2024 at 11:28:12AM +0000, 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

[toc] | [prev] | [next] | [standalone]

#82013

[Multipart message — attachments visible in raw view] — view raw

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

[toc] | [prev] | [next] | [standalone]

#82039 — Bug#1064976:

I am assuming that the original intent of adding linux-image-* as a
dependency was to prevent the "Skipping BTF generation for %s due to
unavailability of vmlinux" warning from being printed; is that a fair
assumption?

I am quite sure that this will not cause problems because of the decision
in https://salsa.debian.org/kernel-team/linux/-/merge_requests/1005 to
include vmlinux.h in the headers package. This file is the thing which is
generated by "cmd_btf_ko" in the upstream kernel build, so any module or
userspace program which depends on BPF will be able to pull the necessary
information from that file.

As Luca says, adding the image and associated machinery as a dependency to
a source file is a very heavy-handed way to solve quite a niche problem
(which I don't think even is a problem). It makes assumptions which I
don't think hold true in many cases; especially that the system being
used to build a kernel or kernel module is the same as the system which
will be running it (or even have the same CPU architecture).

Any DKMS or other out of tree packages which require the Linux image to
be installed should declare that dependency themselves; I am pretty sure
that declaring it here is not the right thing.

        Colm

[toc] | [prev] | [next] | [standalone]

#82097 — Bug#1064976:

[Multipart message — attachments visible in raw view] — view raw

Hey folks -

I see that linux-headers-* has been promoted to 6.6 in the BPO channel, but
this dependency is still in place.
Is it really the case that we want to drag in the image binaries and other
machinery as a dependency for a source package like linux-headers.
I feel that the BPF use case should really be addressed using vmlinux.h
(the "skipping BTF generation" message should be ignored as all of this
information *should* be included in vmlinux.h).
Any further thoughts?

Colm

[toc] | [prev] | [next] | [standalone]

#82114 — Bug#1064976: linux-headers-amd64: linux-headers-* incorrectly depends on linux-image-*

Package: linux-headers-amd64
Version: 6.6.13-1~bpo12+1
Followup-For: Bug #1064976
X-Debbugs-Cc: colm@tuatha.org

Can I suggest in the interim that Depends: be replaced with Recommends:
or Suggests: given that most installations won't actually need the image
package?

    Colm

[toc] | [prev] | [next] | [standalone]

Page 1 of 2  [1] 2  Next page →

Back to top | Article view | linux.debian.kernel

csiph-web