On Tue, 2020-01-07 at 19:07 +0000, Daniel P. Berrangé wrote: > On Tue, Jan 07, 2020 at 07:01:53PM +0000, ci@xxxxxxxxxx wrote: > > See <https://ci.centos.org/job/libosinfo-build/systems=libvirt-debian-9/307/display/redirect> > > <https://ci.centos.org/job/libosinfo-build/systems=libvirt-debian-9/ws/build/tmp-introspectnns2sh9a/Libosinfo-1.0>;;: /home/jenkins/build/libvirt/lib/x86_64-linux-gnu/libosinfo-1.0.so.0: version `LIBOSINFO_1.8.0' not found (required by <https://ci.centos.org/job/libosinfo-build/systems=libvirt-debian-9/ws/build/tmp-introspectnns2sh9a/Libosinfo-1.0)> > > This problem is a bug in g-ir-scanner on Debian 9. It is mistakenly > linking against the libosinfo.so installed by the prevuous build > in $HOME/build/libvirt, instead of the one it just built locally. > > https://bugzilla.gnome.org/show_bug.cgi?id=781525 > > I fixed by > > # ssh jenkins@libvirt-debian-9 > $ cd build > $ find | grep libosinfo-1.0.so | xargs rm > > and then re-triggered the jobs. > > It will potentially re-occurr any time we add a new public API to > libosinfo Yeah, we've hit that in the past and we'll surely hit it again in the future. I don't have any bright ideas on how to avoid it, short of running something along the lines of $ find $VIRT_PREFIX -name 'libwhatever*so*' -delete before each library build. -- Andrea Bolognani / Red Hat / Virtualization -- libvir-list mailing list libvir-list@xxxxxxxxxx https://www.redhat.com/mailman/listinfo/libvir-list
