Bug#681290: unblock: spice-gtk/0.12-4
On 12.07.2012 20:51, Adam D. Barratt wrote:
> On 12.07.2012 07:47, Liang Guo wrote:
>> Please unblock spice-gtk.
>>
>> I upload 0.12-3 to unstable at 29th Jun, and
>> find a bug[1] which forbit other package to
>> compile. Then I uploaded 0.12-4 at 9th July,
>> and this cause 0.12-3 cannot automatically
>> migrate to testing
>>
>> The difference between 0.12-3 and 0.12-4 is slight, just
>> copy .version and .tarball-version to build directory.
>> for the build script use the version information in
>> .tarball-version to determine the version it is building.
>
> Testing currently has 0.12-1, so the changes which are relevant are everything after that, not just those in -4.
The original unblock request included SEVERAL diffstats,
one, the smallest, is between -3 and -4, but there are
also diffstats between other revisions too, starting
with -1 currently in wheezy.
Note that version of spice-gtk which is currently in
testing can not be shipped in wheezy, due to long
story with the celt audio codec. We should either
let the -4 (celt-less) version go to wheezy, or we
should remove spice and spice-gtk (and all related
packages) and modify dependent packages (qemu-kvm)
to stop using spice.
Version of spice currently in unstable (which is
celt-less) can not enter testing even if it is ready
to go, because it breaks spice-gtk currently in
testing, exactly because this: spice-gtk currently
in testing (-1) requires celt from spice, and spice
in unstable does not contain celt anymore.
For what it is worth, I reviewed the changes made
by Liang, both between 3..4 and between 1..4 revisions.
In particular, I reviewed the only big part of these
changes, which is the patch removing celt usage from
spice-gtk.
The patch itself looks sane. There are a few places
which might be made shorter, but the logic is right.
I verified the resulting binary (spicy) which uses the
spice-gtk libs, it works as expected. It even works
with celt-enabled spice server (negotiating raw audio
"codec" correctly), so there's no big issues to expect
from this (biggest and most important) patch.
The changes in the debian packaging also look sane.
They reveal a few places in context which may want
some more love, in particular, the package (neither
sid's -4 release nor testing's -1) build process
can't be stopped and resumed, `clean' target and
rebuilt from scratch is needed in case of any error.
But this is exactly the same in wheezy too.
The packaging changes in -2 (the largest) is the
introduction of multiarch for the libraries. Enabling
multiarch migth be tricky, but apparently this is done
correctly here - the resulting packages _looks_ okay.
Maybe I should fire up puiparts to verify various up/-
downgrades to see more.
The same revision (-2) included bumping versions of
several dependent libraries, I dunno why it is needed,
but these versions are in -testing now.
I'm not sure of the rules for the unblocking, but this
thing definitely looks sane to me, and testing of the
_code_ changes shows good results too.
Thank you for your time!
/mjt
Reply to: