On Tuesday, 2 April 2024 19:54:41 CEST J. Pfennig wrote:
> Package: src:linux
> Version: 6.1.76-1
> Severity: important
> Tags: upstream
I am/was inclined to remove that tag, but the problem is likely caused by
firmware which is too old for the 'backported' patches that upstream applied.
> The d
Package: src:linux
Version: 6.1.76-1
Severity: important
Tags: upstream
Dear Maintainer,
*** Reporter, please consider answering these questions, where appropriate ***
The driver fills the eventlog with millions !!! of messages, see below.
It otherwise works. The problem can be reproduced on dif
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
k
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
>
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 apparen
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.
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 a
Hi
On Tue, Apr 02, 2024 at 03:26:32PM +, Colm Buckley wrote:
> This is a real problem - however I think it is *not* one which the change
> in dependency addresses; even if -headers-Y depends on -image-Y, step 3
> above will proceed without any conflicts (because the reverse dependency is
> not
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, beca
I wrote:
[...] From the maintainer's most recent comments, I believe that the
> problem is something like:
>
> * user has installed linux-headers and linux-image for kernel version X
> * user has built additional modules using DKMS which are installed into
> the running system
> * user upgrades li
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 th
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
Processing control commands:
> reopen 1064976
Bug #1064976 {Done: Colm Buckley } [linux-headers-amd64]
linux-headers-6.6.13+bpo-amd64 incorrectly depends on the corresponding
linux-image-amd64 package
Bug reopened
Ignoring request to alter fixed versions of bug #1064976 to the same values
previ
13 matches
Mail list logo
