Control: reopen -1
Hi Pascal,
On Tue, Jan 06, 2026 at 04:43:19PM +0100, Pascal Hambourg wrote:
> On Mon, 5 Jan 2026 13:05:59 +0100 Salvatore Bonaccorso wrote:
> > On Mon, Jan 05, 2026 at 11:10:22AM +0100, Roland Clobus wrote:
> > >
> > > The package linux-image-amd64 for 6.18.3-1 depends only on the signed
> > > kernel
> > > package [1]. At this moment the signed version is (not yet?) available, so
> > > the installation will fail.
> > >
> > > For sid, the source package appears to have been changed from
> > > 'linux-signed-amd64' to 'linux'. Could that be causing this issue?
>
> I guess so. What is the reason of this change ?
>
> > > Would it be possible to change the dependency to:
> > > linux-image-6.18.3+deb14-amd64 | linux-image-6.18.3+deb14-amd64-unsigned
> > > instead?
>
> Not sure it is a good idea. It could lead to the installation of an unsigned
> kernel while a signed kernel was expected. This would make the system
> unbootable with secure boot.
>
> > This is normal for short while. FTP master will need to trigger the
> > codesigning service, at which point then we will get the signed images
> > as well.
>
> Is it really normal to update the kernel meta-package before the signed
> kernel package the new version depends on is available ?
I was I think bit prematurely to close the issue, because I think we
should explain from where the change come (and if we actually want to
cause this situation).
If I'm correct, with the change af3f11740ed9 ("Introduce a base
package for version sync") we now generate again the linux-image-*
packages from src:linux.
[1]
https://salsa.debian.org/kernel-team/linux/-/commit/af3f11740ed9525b0c035f941c86ddc5e10125bb
The downside of this change is exactly as you described, we do not
have anymore the linux-image-* package build only at the time when the
signed packages exists and will cause temporary situations as
described, so in theory reopen #941042.
Bastian, Ben, is this something we should rethink about?
Regards,
Salvatore
