[Openstack-operators] [openstack-dev] RFC: Next minimum libvirt / QEMU versions for "Stein" release

Thomas Goirand zigo at debian.org
Fri Apr 6 16:07:18 UTC 2018

On 04/06/2018 12:07 PM, Kashyap Chamarthy wrote:
>> dh_install: Cannot find (any matches for) "/usr/lib/*/wireshark/" (tried
>> in "." and "debian/tmp")
>> dh_install: libvirt-wireshark missing files: /usr/lib/*/wireshark/
>> dh_install: missing files, aborting
> That seems like a problem in the Debian packaging system, not in
> libvirt.

It sure is. As I wrote, it should be a minor packaging issue.

>  I double-checked with the upstream folks, and the install
> rules for Wireshark plugin doesn't have /*/ in there.

That part (ie: the path with *) isn't a mistake, it's because Debian has
multiarch support, so for example, we get path like this (just a random
example from my laptop):


> Note: You don't even have to build the versions from 'Buster', which are
> quite new.  Just the slightly more conservative libvirt 3.2.0 and QEMU
> 2.9.0 -- only if it's possbile.

Actually, for *official* backports, it's the policy to always update to
whatever is in testing until testing is frozen. I could maintain an
unofficial backport in stretch-stein.debian.net though.

> That said ... I just spent comparing the release notes of libvirt 3.0.0
> and libvirt 3.2.0[1][2].  By using libvirt 3.2.0 and QEMU 2.9.0, Debian users
> will be spared from a lot of critical bugs (see all the list in [3]) in
> CPU comparision area.
> [1] https://www.redhat.com/archives/libvirt-announce/2017-April/msg00000.html
>     -- Release of libvirt-3.2.0
> [2] https://www.redhat.com/archives/libvirt-announce/2017-January/msg00003.html
>     --  Release of libvirt-3.0.0
> [3] https://www.redhat.com/archives/libvir-list/2017-February/msg01295.html

So, because of these bugs, would you already advise Nova users to use
libvirt 3.2.0 for Queens?


Thomas Goirand (zigo)

More information about the OpenStack-operators mailing list