When we split virtiofsd out from qemu-common, the intention was it
would be installed with `qemu-system-XXX` but not
`qemu-system-XXX-core`, similar to how device modules are treated.
It was accidentally added to the `qemu` metapackage, which is rarely
used.
This fixes that mistake.
https://bugzilla.redhat.com/show_bug.cgi?id=2083155
Signed-off-by: Cole Robinson <crobinso@redhat.com>
qemu-common has a dep on python, and has nothing that is critical for
the operation of the userspace emulators. At most the qemu-trace-stap
tool is useful, but we shouldn't force install of qemu-common just for
that. qemu-user-static needs to be lightweight as its used to support
cross-arch execution in scenarios where container/image size matters.
In dropping qemu-common as a dep, we just need to ensure we still have
the license files present.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The static build of QEMU installs a copy of 'qemu-trace-stap' python
script, which gets renamed to 'qemu-trace-stap-static' by an overly
enthusiastic wildcard. This ends up adding a python dependency to
the qemu-user-static RPM, which is unhelpful.
Anyone who wants to trace QEMU user binaries with the stap helper
can easily install qemu-common as desired.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
Pulled in by qemu-* but not qemu-*-core, like we do for device modules.
There's a virtual Provides: vhostuser-backend(fs) indicating this
packages is a vhost-user.json fs provider.
Use that for the qemu dep, as in the future there will be alternate
virtiofsd impl packages in Fedora
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Drop use of %dnl which centos 8 RPM doesn't support
* Use internal capstone copy on centos8
* Don't try to use jack driver on centos
Signed-off-by: Cole Robinson <crobinso@redhat.com>
s390x and ppc64le tests are still busted. I think s390x is koji
build OS related, so maybe a rebase to new fedora will fix it.
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This will use gnutls's internal implementation as the
default crypto engine:
Crypto
TLS priority : "@QEMU,SYSTEM"
GNUTLS support : YES
GNUTLS crypto : YES
libgcrypt : NO
nettle : NO
crypto afalg : NO
rng-none : NO
Linux keyring : YES
Fixes: https://bugzilla.redhat.com/show_bug.cgi?id=1998452
There should be no functional difference here, but it's not
obvious at a glance how qemu handles globally defined CFLAGS + LDFLAGS
with --extra-cflags and --extra-ldflags.
Reproduce the desired behavior with explicit configure options and
RPM variables
Signed-off-by: Cole Robinson <crobinso@redhat.com>
This is the historical intended behavior in the buildroot, but for
local builds, or with clang, qemu would detect a c++ compiler on the
host. So explicitly make the check fail by passing /bin/false
Signed-off-by: Cole Robinson <crobinso@redhat.com>
