On Fri, Oct 27, 2023 at 10:55:48AM +0200, Bastian Blank wrote:
> On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > > ## Image packages contains more version info
> > > >
> > > > Example: linux-image-6.5.3-cloud-arm64
> > >
> > > > It will not longer be possible to reliabl
On Fri, Oct 27, 2023 at 08:43:46AM +0200, Julian Andres Klode wrote:
> > > ## Image packages contains more version info
> > >
> > > Example: linux-image-6.5.3-cloud-arm64
> >
> > > It will not longer be possible to reliably derive the package name from
> > > kernel release (see above), as both va
OK,
it seems my original email got lost somewhere in tech hickups,
it's possible the kernel crashed before sending the email, AMD
just crashes once or twice a day.
So I'm writing this email a bit in a hurry, so it's not quite
as thought out as the last one weeks ago, but yesterday's email
was pre
On Thu, Oct 05, 2023 at 07:59:54AM -0600, Sam Hartman wrote:
> I think that's what you mean by the first-level error.
> If not, I'm still confused.
> In the second level error case you are talking about is:
No, the first level is always: but the new kernel does not work.
The second is: I need to u
Moin
On Sun, Sep 24, 2023 at 03:01:51PM +0200, Bastian Blank wrote:
> ## Kernel modules will be signed with an ephemeral key
This is now
https://salsa.debian.org/kernel-team/linux/-/merge_requests/607.
> ## Image packages contains more version info
>
> Example: linux-image-6.5.3-cloud-arm64
>
Hi
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> > Multiple uploads of the same upstream version will have
> > the same package name, but those rarely happens.
> Those happen fairly often for urgent security updates.
We could encode that in the upstream version. Aka to have
co
Sam Hartman writes:
> B) They might already have headers installed. Imagine someone who
> installs headers at the same time they install the kernel. Unless they
> managed to upgrade the same version of their kernel without also
> upgrading their headers, they will still have headers. They can
> "Bastian" == Bastian Blank writes:
Bastian> The same as now: nowhere, because those packages have been
Bastian> removed from the archive already.
Bastian> And sadly you did not answer the question why a second
Bastian> degree error must not be worse then a worked around fir
On Tue, Oct 03, 2023 at 03:00:53PM -0500, Robert Nelson wrote:
> On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
> > How will the user get the headers matching this previously-used kernel
> > that are required until we provide a kernel with the regression fixed?
The same as now: nowhere, becaus
Hi Andreas
On Tue, Oct 03, 2023 at 11:58:29PM +0200, Andreas Beckmann wrote:
> That should solve the problem where several source packages need to be
> updated together.
The problem does not come from multiple source packages that need to be
updated together. Instead it comes from the way Debian
On 03/10/2023 19.30, Bastian Blank wrote:
thread. Or freak out because meta packages remain uninstallable in
backports for days.
...
plus gcc or we change how backports works.
If uninstallable packages in backports are a problem, perhaps backports
needs something like britney to migrate pac
On Tue, Oct 3, 2023 at 2:54 PM Adrian Bunk wrote:
>
> On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
> >...
> > The core problem is that people assume they can get headers matching the
> > currently running kernel, without upgrading first, see also the parallel
> > thread.
> >...
>
On Tue, Oct 03, 2023 at 07:30:49PM +0200, Bastian Blank wrote:
>...
> The core problem is that people assume they can get headers matching the
> currently running kernel, without upgrading first, see also the parallel
> thread.
>...
If the new kernel has a regression that affects the user, the use
Hi Sam
On Tue, Oct 03, 2023 at 08:31:57AM -0600, Sam Hartman wrote:
> I still think it would help if you would work more on articulating what
> problem you are trying to solve with the linux-headers versioning
> change. I have read multiple versions of this proposal, and your
> follow-ups, and I
> "Bastian" == Bastian Blank writes:
Bastian> On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
>> On 25/09/2023 00.50, Bastian Blank wrote:
>> > Already built modules remain until someone deletes it. So you
>> can also > switch back to the still installed old
On Mon, Sep 25, 2023 at 04:35:08AM +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can also
> > switch back to the still installed older kernel version and it will have
> > the still working module availab
On Mon, Sep 25, 2023 at 02:03:35AM +0200, Bastian Blank wrote:
> The current way does not work. See all the bug reports about
> uninstallable packages and what not with dkms.
>
> To build modules against version x, you'll need to install version x of
> the headers, not x-1 or x+1. This currently
On Mon, 2023-09-25 at 04:35 +0200, Andreas Beckmann wrote:
> On 25/09/2023 00.50, Bastian Blank wrote:
> > Already built modules remain until someone deletes it. So you can
> > also
> > switch back to the still installed older kernel version and it will
> > have
> > the still working module availa
On 25/09/2023 00.50, Bastian Blank wrote:
Already built modules remain until someone deletes it. So you can also
switch back to the still installed older kernel version and it will have
the still working module available.
This is what I expect not to work.
Assume I have Linux 6.6 and a third-
Hi Ben
On Sun, Sep 24, 2023 at 06:05:09PM +0200, Ben Hutchings wrote:
> On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
> > The same upstream version in testing and backports will have the same
> > package name.
> This is not OK, because they will be incompatible on architectures
> support
Hi Andreas
On Sun, Sep 24, 2023 at 11:10:36PM +0200, Andreas Beckmann wrote:
> On 24/09/2023 15.01, Bastian Blank wrote:
> > ## Kernel modules will be signed with an ephemeral key
> >
> > The modules will not longer be signed using the Secure Boot CA like the
> > EFI kernel image itself. Instead
On 24/09/2023 15.01, Bastian Blank wrote:
## Kernel modules will be signed with an ephemeral key
The modules will not longer be signed using the Secure Boot CA like the
EFI kernel image itself. Instead a key will be created during the build
and thrown away after.
Do I correctly assume that ch
On Sun, 2023-09-24 at 15:01 +0200, Bastian Blank wrote:
[...]
> ## Kernel modules will be signed with an ephemeral key
>
> The modules will not longer be signed using the Secure Boot CA like the
> EFI kernel image itself. Instead a key will be created during the build
> and thrown away after.
>
Hi folks
Debian currently does Secure Boot signing using a shim chained to the
Microsoft key. This use requires that we follow certain rules. And one
of the recent changes to those rules state that our method of signing
kernel modules also with the same key will not be allowed anymore. Some
inf
24 matches
Mail list logo
