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
&g
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.
o
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
e and headers packages. Users who
regularly build new modules should be encouraged to install this package
and have it pull in suitable versions of both headers and image.
Is this correct, Bastian? I'm sorry for taking so long to understand what
problem was being addressed here.
Colm
--
Colm Buckley | c...@tuatha.org
Control: reopen 1064976
My apologies for the ping-pong; I do want to keep this open until the
discussion has completed. I will set out my thoughts below. I'm afraid this
is fairly long.
A brief history of this issue: in December 2023, the control file for
linux-headers-* was altered to include a
Package: linux-headers-amd64
Version: 6.6.13-1~bpo12+1
Followup-For: Bug #1064976
X-Debbugs-Cc: c...@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
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
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
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] $@
> |
en 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 depende
ing 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 packag
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
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
Package: src:linux
Version: 5.2.9-2
Severity: normal
Dear Maintainer,
This system is an Intel NUC with an onboard Intel I219-LM
Ethernet adapter (e1000e) and an additional dual Intel I210
Ethernet adapter (igb) connected via the onboard M.2 interface
(M.2 Dual Ethernet supplied by G2 Digital; I
Package: src:linux
Version: 4.18.6-1~bpo9+1
Severity: important
Tags: upstream patch
Please see
https://git.kernel.org/pub/scm/linux/kernel/git/ebiederm/user-namespace.git/commit/?h=for-linus
- invalidating
filesystems can cause dentry table corruption leading to busy loop in kernel.
Easily
15 matches
Mail list logo
