Re: working for wheezy-security until wheezy-lts starts
Moritz Mühlenhoff <email@example.com> writes:
> 1. We're already one wheezy update behind for xen (since some of
> the changes were invasive and complex). It would be great if
> someone from the Freexian sponsor pool would work on a wheezy
> update for Xen. It's probably a solid day of work, though, but
> it will also clarify whether it's feasible to continue to support
> in Xen in Wheezy LTS (while 4.1 being EOLed by upstream for
> quite a while now).
So what needs to happen here? Not sure what is meant by "We're already
one wheezy update behind for xen".
I see wheezy has version 4.1.4-3+deb7u8 - do we need to attempt to
update this to version 220.127.116.11 - the latest 4.1.* version?
If so I imagine this would require:
- identifying which CVEs are fixed in 18.104.22.168
- updating xen package
- updating the kernel packages (if this is required??? Not sure if the
kernel code is considered part of the xen release or not anymore)
and/or do we attempt to backport the security patches from some newer
I also note that there are a large number of unfixed vulnerabilities for
all versions including sid.
> 2. Spend some time on investigating what it takes to backport
> libav from jessie to wheezy. 11.x is still supported by
> libav upstream and we could share triage work for jessie/wheezy
> going forwards. 0.8 has simply too much missing.
> There will be a few applications which are going to break due to
> API changes, possibly exclude some exotic ones from wheezy LTS
> support and backport some fixes for important apps from jessie.
> (Most of the changes are fairly straightforward, e.g. they renamed
> lots of internal constants).
Looks like the SONAME has changed. Presumably this means anything
depending on libav will need to be rebuilt?
How do we handle any packages that might be broken and cannot (feasibly)
As there are multiple packages involved, is it possible to stage them
somewhere and get all packages moved in one atomic operation or do we
have to do them one at a time? The later could be potentially risky and
break things if both versions end up being included in the one
application, especially if versioned symbols not used (I haven't
Brian May <firstname.lastname@example.org>