On Fri, 27 Oct 2023 20:09:57 +0200 Bastian Blank
wrote:
> On Fri, Oct 27, 2023 at 01:04:00PM +0300, Adrian Bunk wrote:
> > > Sadly in Debian there is no way to make that happen. Think for
example
> > > about bin-nmu.
> > Could you give a complete list of problems?
>
> There are at least those
On Fri, Oct 27, 2023 at 01:04:00PM +0300, Adrian Bunk wrote:
> > Sadly in Debian there is no way to make that happen. Think for example
> > about bin-nmu.
> Could you give a complete list of problems?
There are at least those problems:
- Bin-nmu can't change binary package names.
- There is no
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
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
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
On Thu, Oct 26, 2023 at 01:36:50PM +0200, Bastian Blank wrote:
> On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> > Or would it be easier to re-use normal dependency resolving, like:
> > Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> > This would allow full flexibility and
On Fri, Oct 20, 2023 at 05:54:23PM +0200, Bastian Blank wrote:
> Or would it be easier to re-use normal dependency resolving, like:
> Kernel-Provides: linux (>> 6.6.1~), linux (<< 6.6.1.)
> This would allow full flexibility and re-uses existing code to check
> such definitions.
Okay, noone
[ Removing some lists ]
On Sat, Oct 07, 2023 at 04:53:33PM +0200, Bastian Blank 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
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
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
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
>
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
14 matches
Mail list logo
