Hi Steve, Moritz Mühlenhoff <j...@inutil.org> (2019-02-26): > On Fri, Feb 15, 2019 at 07:28:57PM +0100, Cyril Brulebois wrote: > > Right, this also breaks the build of the debian-installer source package > > on amd64 since its build dependencies cannot be satisfied. > > Is there an ETA for a fix?
We're getting deeper and deeper into the freeze, and we seem to be lacking a reasonable timeline regarding Secure Boot for Buster. The problems we're seeing are: 1. the hard shim/shim-signed dependency means the shim-signed package isn't installable in sid; 2. src:debian-installer therefore cannot be built because of unsatisfiable build-dependencies; 3. shim cannot migrate to testing. We don't know how long it will take to get the new shim signed by Microsoft; until that happens these problems will continue to block development (and potentially the release). Apologies for not spotting these as potential problems earlier, before asking you to upload the new version of shim into unstable. :-( If our understanding is correct, it seems that re-uploading the contents of the previous shim package (either with an over-long “+really”-like version, with an epoch, or with the trick detailed below), and adjusting the versioned dependency in shim-signed to match, would make both packages installable again. It wouldn't change anything regarding the actual signatures: they would be validated as previously. The “old” shim/shim-signed couple is already able to chainload GRUB/Linux/etc. signed by either the Debian test key (as we've been testing recently) or the embedded Debian production key. This would be a quick fix for the next D-I Alpha/RC, but could also serve as a last resort solution for buster itself if we don't get an updated shim-signed package in time. In the meantime, we could upload the new shim source/binary package to experimental for people to work with. The main drawbacks (compared to actually getting an updated shim-signed package) would be: 1. lacking the newer shim code that upstream EFI people would like us to be using; 2. only having support for amd64. Until an updated shim-signed package is available, it seems to us that the re-upload suggested above would fix all issues we're seeing, without having any negative impact. That's why we're considering doing so in the next few days. Looking at the version numbers we have: - 0.9+1474479173.6c180c6-1 in testing - 15+1533136590.3beb971-2 in sid so we could re-upload with 16+1474479173.6c180c6-1, which would sort higher than the version in sid, but also lower than 16+1533136590.3beb971-*, that can be used to re-upload the new shim when the matching shim-signed is ready. How does that sound to you please? Finally: we don't want to steal too much of your time for shim. It seems like now would be a really good time to move maintenance formally to the debian-efi team? Cheers, Cyril Brulebois & Steve McIntyre for the D-I / EFI teams -- Cyril Brulebois (k...@debian.org) <https://debamax.com/> D-I release manager -- Release team member -- Freelance Consultant
signature.asc
Description: PGP signature