Why do some updates skip proposed? (launchpad bug 589163)
ienorand at gmail.com
Thu Jun 3 21:19:10 UTC 2010
-----BEGIN PGP SIGNED MESSAGE-----
On 03/06/10 18:16, James Hogarth wrote:
> Hey all,
> Quick question for anyone that can give a quick answer...
> The kernel released for lucid last night (2.6.32-22.35) broke kvm
> guests - prevented them from starting.
> The kernel that was in proposed (2.6.32-22.33) has no problems.
> Looking at launchpad it looks like 2.6.32-22.35 never hit proposed and
> went straight to updates/security:
> Given that this broke KVM guests on an LTS release no less (and kvm is
> pushed by Ubuntu as the virtualisation system to use) it presents a
> reasonably serious problem.
> How did this get straight to release with no testing in proposed?
> What is the point of having proposed for bug testing if a released
> package never goes through it - especially for something as critically
> important to the core system as the kernel?
> Hopefully the issue can be fixed soon so those of us who use KVM on
> Lucid are able to use the latest kernel with any bug fixes again..
> As it is anyone with this issue cannot get a fix from Ubuntu as a
> vendor for the following CVE's as they are part of the update that
> broke kvm:
> And if they don't have the savvy (or are unwilling to run a 'proposed'
> kernel) to obtain the 2.6.32-22.33 kernel directly from the launchpad
> build page they will also be missing updates for launchpad bugs 526354
> and 567016.
> Any thoughts on this issue?
As stated on https://wiki.ubuntu.com/KernelTeam/KernelUpdates:
* Security updates will be uploaded directly into -security without
other changes. This just requires a temporary GIT fork which will be
immediately merged back into the main branch for that stable release.
* Normal updates will be provided as pre-releases through the
kernel-ppa users PPA. At certain points those get made into proposed
releases which are uploaded to the proposed pocket. Then again they
have to get verified to fix the problems and not to cause regressions.
As far as I know, this applies to most security updates, skipping the
- -proposed step
Whether or not this policy is a good one, is a matter of discussion,
since it obviously failed this one.
Would more testing, which would mean a slower procedure for getting
the security fixes through, be a viable compromise in some cases? What
kind of testing is already in place by the security team? Could that
- - arand
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.10 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/
-----END PGP SIGNATURE-----
More information about the Ubuntu-devel-discuss