ACK: [PATCH 0/2] deb to snap: use the kernel version from the
Kleber Souza
kleber.souza at canonical.com
Fri Nov 10 16:58:42 UTC 2017
The changes look good to me.
Acked-by: Kleber Sacilotto de Souza <kleber.souza at canonical.com>
On 10/31/17 19:02, Paolo Pisati wrote:
> It was pointed to us that using the version from the linux-image-$BRANCH (e.g.
> linux-image-generic) package is not a good idea, since that version doesn't map
> 1:1 to the real kernel that comes from the linux-image-$VER-$ABI-$BRANCH (e.g.
> linux-image-4.4.0-98-generic) package - in other words, the same linux meta
> package could actually end up using two completely different kernels since it
> doesn't keep track of the upload number, and as such we won't be able to tell
> univocally which kernel image ended up in the produced kernel snap: to fix this,
> i added a mechanism that, given the meta package, it recurse down to find the
> real linux kernel package, extract its version and compares it against the
> expected version (while previously we used the "apt-get install
> $(KERNEL)=$(VERSION)" to force the installation of exactly that linux meta
> version, something we can't do anymore now as explained above).
>
> Patch 0001 is a prerequisite for patch 2, and improve over our apt-pinning
> method to let us use only kernel packages from the proposed pocket, and remove
> the "apt-get install $(KERNEL)=$(VERSION)" mechanism - now we'll just install
> the latest version of the required package available.
> Patch 0002 is where the real version extraction and checking happens, and it
> does so by making the checkversion shell snippet a prerequisite of the install
> rule.
>
> I tested the above by rebuilding all our kernel snaps on LP:
>
> pc-kernel - i386 and amd64
> raspi2-kernel - armhf
> snapdragon-kernel - arm64
> gke, gcp and aws - amd64
>
> and testing all the possible error paths or conditions.
>
> Since these patches don't change anything in the content on the generated kernel
> snap (actually they add a stricter version checking and a better pinning), the
> risk of regression is very low.
>
> This series of patches apply to our 'deb to snap' packaging scripts located
> here:
>
> git://git.launchpad.net/~ubuntu-kernel/ubuntu/+source/linux-snap/+git/xenial
>
> and should be applied to the master Makefile, while all the topic
> branches should get the version field (version: in snapcraft.yaml) changed to
> point to the version from the linux-image-$VER-$ABI-$BRANCH corresponding
> package.
>
> In other words, and at the time of this writing, these are the version that
> should be used for all the topic branches:
>
> pc-kernel: 4.4.0-98.121 (linux-image-4.4.0-98-generic / linux-signed-image-4.4.0-98-generic)
> raspi2-kernel: 4.4.0-1076.84 (linux-image-4.4.0-1076-raspi2)
> snapdragon-kernel: 4.4.0-1078.83 (linux-image-4.4.0-1078-snapdragon)
> aws-kernel: 4.4.0-1039.48 (linux-image-4.4.0-1039-aws)
> gcp-kernel: 4.10.0-1008.8 (linux-image-4.10.0-1008-gcp)
> gke-kernel: 4.4.0-1033.33 (linux-image-4.4.0-1033-gke)
>
> I could have sent a separate version patch for every branch, but since it takes
> some time to get stuff reviewed and applied, and you might want to use the kernel
> available in -proposed instead of the one in -security/updates, i'll leave the
> version extraction to you.
>
> Paolo Pisati (2):
> deb to snap: better apt-pinning, use $RELEASE everywhere and
> explicitly exclude linux-firmware from -proposed
> deb to snap: recurse down to find the real kernel image package, and
> chek its version
>
> Makefile | 42 +++++++++++++++++++++++++++++-------------
> 1 file changed, 29 insertions(+), 13 deletions(-)
>
More information about the kernel-team
mailing list