Open Stack

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):

/usr/lib/i386-linux-gnu/pulseaudio
/usr/lib/x86_64-linux-gnu/pulseaudio

> 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?

Cheers,

Thomas Goirand (zigo)