[PATCH libvirt v1] tests: add capabilities for QEMU 5.2.0 on s390x

[Andrea Bolognani]

On Mon, 2020-12-28 at 12:41 +0100, Shalini Chellathurai Saroja wrote:
> On 12/17/20 12:19 PM, Andrea Bolognani wrote:
> > On Wed, 2020-12-16 at 10:10 +0100, Shalini Chellathurai Saroja wrote:
> > > +++ b/tests/qemucapabilitiesdata/caps_5.2.0.s390x.xml
> > > @@ -0,0 +1,3300 @@
> > > +<qemuCaps>
> > > +  <emulator>/usr/bin/qemu-system-s390x</emulator>
> > > +  <version>5002000</version>
> > > +  <kvmVersion>0</kvmVersion>
> > > +  <microcodeVersion>39100243</microcodeVersion>
> > > +  <package>qemu-5.2.0-20201215.0.ba93e22c.fc32</package>
> >
> > ... the version string seems to indicate you're grabbing the replies
> > from a packaged version rather than a build made from pristine
> > upstream sources: this is consistent with what was done for earlier
> > QEMU capabilities on s390x, but not with how we usually do things for
> > other architectures - see the other caps_5.2.0.*.replies files.
> > 
> > I don't think this is a blocker, because a Fedora-based package will
> > be quite close to upstream anyway, but it would be great if you could
> > generate the replies file again against a QEMU binary that's been
> > built exclusively from upstream sources. You can then submit the
> > update as a follow-up patch - I expect such patch to be fairly small.
> 
> The replies are actually generated from the QEMU 5.2.0 binary built 
> exclusively
> from upstream. This is also true for the other s390 replies generated for
> the earlier versions of QEMU.

So how are you actually building the binary? Because if you just
clone the upstream repository and run the usual ./configure && make
inside it, the version number will not look like that... The presence
of .fc32 specifically seems to indicate a .spec file is involved in
some capacity.

-- 
Andrea Bolognani / Red Hat / Virtualization