[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Problems with shim and shim-signed in unstable, and proposed solutions to unblock us



I've had a reply from Mark (ftpteam) in IRC:

On Sun, Mar 03, 2019 at 11:35:45PM +0000, Steve McIntyre wrote:

...

>So, we're looking at three hacky options options here to work our way
>out of this hole. In (probably?) descending order of hackitude:
>    
>    1. Ask the nice ftpmaster people to bodge the archive by hand:
>    1a. Remove the current shim source and binary packages from
>        unstable (version 15+1533136590.3beb971-2)
>    1b. Copy the older source and binary from buster back into
>        unstable for us.
>    1c. We're not even sure if this is *possible*, let alone a nice
>        thing to do - thoughts?
>    1d. Expecting that this might break all kinds of tools inside and
>        outside of the archive maybe?

And Mark says:

"we don't want to go rewinding version numbers in unstable; that could
lead to all sorts of unforeseeable breakage.

much as we'd expected. Any more feedback please? Cyril prefers
approach #2 below, I prefer #3.

>    OR
>    
>    2. Upload new bodged versions of shim and shim-signed to get us
>       back to working with the previously-signed shimx64.efi.signed
>       binary
>    2a. Create new shim and shim-signed source packages, along with
>        matching binary packages.
>    2b. These binary packages will contain the *exact* same EFI
>        binaries as we have in buster but with a higher version number
>        in the packaging.
>    2c. As we cannot *exactly* reproduce the binaries sensibly, we
>        will have to hand-hack the contents of the binary packages.
>    2d. We *know* this is grotty too, but we can at least make this
>        work entirely at a package level.
>    2e. Already tested and working: Cyril has built packages like this
>        and I have tested the results successfully on my test SB
>        system here.
>
>        Current versions in buster:
>         - shim:
>            - source: 0.9+1474479173.6c180c6-1
>            - binary: 0.9+1474479173.6c180c6-1
>         - shim-signed:
>            - source: 1.28+nmu1
>            - binary: 1.28+nmu1+0.9+1474479173.6c180c6-1
>
>        Possible versions targetting sid:
>         - shim:
>             - source: 16+1474479173.6c180c6-1 (bumped “epoch-like” N+
>               prefix, but same contents as 0.9+1474479173.6c180c6-1)
>             - binary: 16+1474479173.6c180c6-1
>         - shim-signed:
>             - source: 1.28+nmu2 (new upload to adjust the Depends)
>             - binary: 1.28+nmu2+16+1474479173.6c180c6-1
>
>    OR
>
>    3. Upload new version of the shim-signed source package and a
>       (lightly) bodged binary package
>    3a. Use versions:
>             - source: 1.28+nmu2
>             - binary: 1.28+nmu2+0.9+1474479173.6c180c6-1
>    3b. Needs as build-deps an old version of sbsigntool (0.6-3.2) and
>        specifically version 0.9+1474479173.6c180c6-1 of shim in the
>        build chroot
>    3c. Then upload source+amd64
>    3d. New shim-signed binary package changes in a few ways:
>        * new version of the binary now include fbx64.efi.signed and
>          mmx64.efi.signed (copied across from the shim binary package)
>        * add Replaces: shim (= 0.9+1474479173.6c180c6-1) so we don't
>          conflict on those binaries
>        * remove Depends: shim (the whole point!)
>        * change Build-Depends to list the specific versions used for
>          shim and sbsigntool
>    3e. Already tested and working. I built this (source and binary
>        debdiffs attached) and tested OK on SB system
>    3f. This package is instantly RC-buggy due to the unavailable
>        build-deps. We know...

-- 
Steve McIntyre, Cambridge, UK.                                steve@einval.com
Is there anybody out there?

Attachment: signature.asc
Description: PGP signature


Reply to: