Hi, On Wed, May 13, 2015 at 03:31:09PM +0000, Serge Hallyn wrote: > Quoting Guido Günther (agx@xxxxxxxxxxx): > > On Tue, May 12, 2015 at 11:14:09AM +0200, Martin Kletzander wrote: > > > On Tue, May 12, 2015 at 05:27:34PM +1000, Tony Breeds wrote: > > > >On Mon, May 11, 2015 at 01:14:58PM +0200, Martin Kletzander wrote: > > > > > > > >>Determining this by version might not be reliable, but more > > > >>importantly working around bug in underlying software is something > > > >>that shouldn't be done at all IMHO. Let the maintainers backport > > > >>whatever needs to be done. > > > > > > > >I agree with you in an ideal world but there are times when we do need > > > >to add work arounds in $project_x to work around issues in $project_y. > > > > > > > >>>Ther nova side will be pretty easy regardless. > > > >>> > > > >>>I'd say the best solution would be to back port the 'fix' but that seems like a > > > >>>lot of effort given the number of distros and libvirt versions potentiall > > > >>>involved. > > > >>> > > > >> > > > >>If you want the fix to be distro-agnostic, there's nothing easier than > > > >>back-porting the fix into our upstream maintenance branches. Those > > > >>should make the life of distro maintainers easy (although it looks > > > >>like not many distros use it). > > > > > > > >And this is part of the problem. If I understand correctly Ubuntu cloud-archive > > > >is using libvirt 1.2.12 which is *NOT* a maintenance release so that leaves us > > > >with doing an additional backport to 1.2.12 and getting the cloud-archive team > > > >to take it[1] or Adding a hack to nova. And that's just Ubuntu It's hard to > > > >say for sure that some vendor isn't running libvirt 1.2.12 also. > > > > > > > >>Having said that I'm not sure which commit(s) are those that need to > > > >>be back-ported. Having known your libvirt version, it shouldn't be > > > >>too hard looking for the differences and finding the right commit. > > > >>When back-porting request is made on the list, it is usually acted > > > >>upon. If you can't find the exact commit, let me know and I'll do my > > > >>best to help. > > > > > > > >So a git bisect points at: > > > >--- > > > >commit a103bb105c0c189c3973311ff1826972b5bc6ad6 > > > >Author: Daniel P. Berrange <berrange@xxxxxxxxxx> > > > >Date: Tue Feb 10 15:59:57 2015 +0000 > > > > > > > > qemu: fix setting of VM CPU affinity with TCG > > > >--- > > > > > > > >A small amount of reading implies to me that we'd be looking at backporting > > > >a103bb105c0c189c3973311ff1826972b5bc6ad6 to any maintenance branch that contains > > > >b07f3d821dfb11a118ee75ea275fd6ab737d9500. Which I think is 1.2.13 only, but I > > > >could be wrong. > > > > > > > > > > 1.2.13 has the commit already in the release and 1.2.12-maint has it > > > as a first back-port right after release. The problem is that there > > > was no maintenance release of 1.2.12 yet. Maybe they would use > > > 1.2.12.1 if it existed. > > > > > > I Cc'd Guido as an upstream debian maintainer, maybe he'll have some > > > insights. @Guido: would it help if we created a maintenance release > > > from the v1.2.12-maint branch? Or is the only thing missing the fact > > > that the launchpad bug is not moved to libvirt? > > Thanks guys, I'm going to cherrypick that patch into vivid right now. (It > should be in wily as that is 1.2.15). > > > Basically Ubuntu takes the version that is in Debian testing, unstable > > or experimental at time of their release and adds pathes. There's little > > to no sync unfortunately (except for the awesome efforts to sync the > > apparmor stuff) > > > > Debian itself is not using 1.2.12 anywhere. Current stable has 1.2.9 + > > maintenance patches (which I intend to switch over to the maintenance > > releases soonish and support hopefully Cole with these), oldstable has > > 0.9.12.3 and unstable/sid has 1.2.15 (and will keep following the > > releases). > > > > I've added Serge since he might to jump onto 1.2.12.1 maintenance > > relasese. > > If you mean contributing by adding patches that we add to vivid, I'm > definately willing to do that. Note that vivid has a pretty short > lifecycle so it wouldn't go on for very long. If people are willing > to tag patches with '[1.2.12.1-maint]' on this list I'm willing to > support this longer. I rather meant that you might be interested to follow a v1.2.12-maint branch. Maintaining it is even better ;) Cheers, -- Guido -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list