Comment 44 for bug 1787405
Revision history for this message
| Christian Ehrhardt (paelzer) wrote | #44 |
© 2004
Canonical Ltd.
•
Terms of use
•
Data privacy
•
Contact Launchpad Support
•
Blog
•
Careers
•
System status
•
f33e652
(Get the code!)
Thanks for the not-too conflicting patch series.
I gave it a try and must agree that it seems backportable reasonably (checked only qemu for now).
To me it looks safe in terms of not affecting other use cases, nor other architectures.
It also looks safe for upgrades/migrations not affecting active machine state structs.
I'll give it some testing after I have looked into a libvirt backport as well.
But you could already use the code from the ppa [1] to verify if that is doing what you expected.
If libvirt is as-easy then I think we can shove that in between without the long delays I was afraid of. I could just push it on top of 2.12 in Disco and SRU 2.12/2.11 from there.
If you could help
One question already thou - is there any bug if e.g. any of the libvirt/qemu/kernel code is released without the other? So for example if the qemu update is installed but not the upgraded kernel (or any other combination of the three) would it crash? Or would is just say, sorry not supported on probing or so?
I ask you to think about that so that (if required) dependencies will be bumped accordingly.
Summary:
- please test [1]
- any hard version dependencies needed?
- I'll ping once also libvirt is in that PPA (or if I have any issues backporting it)
[1]: https:/