On 1/12/21 11:09 AM, Andrea Bolognani wrote:
On Tue, 2021-01-12 at 09:17 +0100, Shalini Chellathurai Saroja wrote:
On 1/4/21 9:44 AM, Andrea Bolognani wrote:
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.
Hello Andrea,
Happy New Year:-)
We are using an automated build system which creates rpm packages from
upstream QEMU 5.2.0.
Yes, a .spec file is involved.
I see.
As long as you're using unadulterated upstream sources I don't think
we have a problem here, and you shouldn't spend time changing your
process.
I agree, thank you:-)
Thanks again!
--
Kind regards
Shalini Chellathurai Saroja
Linux on Z and Virtualization Development
Vorsitzende des Aufsichtsrats: Gregor Pillen
Geschäftsführung: Dirk Wittkopp
Sitz der Gesellschaft: Böblingen
Registergericht: Amtsgericht Stuttgart, HRB 243294