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 -- To UNSUBSCRIBE, email to [email protected] with a subject of "unsubscribe". Trouble? Contact [email protected] Archive: http://lists.debian.org/[email protected]
