It seems that the compatibility package qemu-kvm is not available on aarch64, I see the same issue on 15 SP5.

yes, the package is not available on aarch64. The pattern has been fixed for marble (sle micro6.0).

(In reply to Claudio Fontana from comment #1)
> It seems that the compatibility package qemu-kvm is not available on
> aarch64, I see the same issue on 15 SP5.

It never (well, at least since 6 years, when I joined) has been.

We've always been building that package only for '%ix86 x86_64 s390x'. I don't know why that's the case... Historical reasons, probably, as the qemu-kvm fork was available for those arch-es, or something like that.

We can change that, if we want or need. Or we can just see if we can get rid of that package which, by the way, contains *ONLY* a symlink from /usr/bin/qemu-system-x86_64 (or _s390x) to /usr/bin/qemu-kvm.

Dependency wise, it only Requires: qemu-x86 (or -s390x).

So, it's basically useless and it looks to me that it's doing more harm than good. But maybe there's something I'm missing...

(In reply to Andrea Manzini from comment #0)
> ## Further details
> 
> Always latest result in this scenario:
> [latest](https://openqa.suse.de/tests/
> latest?arch=aarch64&distri=sle&flavor=Online&machine=aarch64&test=upstream_sy
> stemd_tests-amanzini&version=15-SP6)
> 
> 
> conflicting dependencies trying to install qemu-kvm 
>
Can we change whatever it is that is trying to install and/or depends on qemu-kvm, to install/depend on qemu instead?

(In reply to Antoine Ginies from comment #2)
> yes, the package is not available on aarch64. The pattern has been fixed for
> marble (sle micro6.0).
>
Do we have a list of places and patterns that depends from it (or a way to figure that out)? If yes, I'm happy to go and change all of them myself to depend on qemu, which seems much saner...

(In reply to Dario Faggioli from comment #4)
> (In reply to Andrea Manzini from comment #0)
> > ## Further details
> > 
> > Always latest result in this scenario:
> > [latest](https://openqa.suse.de/tests/
> > latest?arch=aarch64&distri=sle&flavor=Online&machine=aarch64&test=upstream_sy
> > stemd_tests-amanzini&version=15-SP6)
> > 
> > 
> > conflicting dependencies trying to install qemu-kvm 
> >
> Can we change whatever it is that is trying to install and/or depends on
> qemu-kvm, to install/depend on qemu instead?

If it works and we can be sure to capture all dependencies, yes, it would be preferable, since qemu-kvm is an obsolete, compatibility-only package.

There is no list of patterns which depends on it.
As far as i know there is the ALP pattern manage by ALP RM, and there is our pattern from SLES, and that's all.

(In reply to Antoine Ginies from comment #7)
> There is no list of patterns which depends on it.
> As far as i know there is the ALP pattern manage by ALP RM, and there is our
> pattern from SLES, and that's all.

I currently see on TW x86:

# zypper se --requires qemu-kvm

kanku-worker               | Worker daemon for kanku                 | package
openQA-devel               | Development package pulling in all bu-> | package
os-autoinst-qemu-kvm       | Convenience package providing os-auto-> | package
python3-avocado-plugins-vt | Avocado Virt Test Plugin                | package
qemu-headless              | Minimum set of packages for having a -> | package
systemd-testsuite          | Testsuite for systemd                   | package

# zypper se --recommends qemu-kvm

build                   | A Script to Build SUSE Linux RPMs | package
minikube                | Tool to run Kubernetes locally    | package
patterns-media-rest_dvd | Remaining Software                | package

interestingly enough I also see a conflict with:

# zypper se --conflicts qemu-kvm

kvm_stat | Monitoring Tool for KVM guests | package


On TW AArch64 I see:

# zypper se --requires qemu-kvm

  | python3-avocado-plugins-vt | Avocado Virt Test Plugin | package
  | systemd-testsuite          | Testsuite for systemd    | package

# zypper se --recommends qemu-kvm

  | build                   | A Script to Build SUSE Linux RPMs | package
  | minikube                | Tool to run Kubernetes locally    | package
  | patterns-media-rest_dvd | Remaining Software                | package

# zypper se --conflicts qemu-kvm
  | kvm_stat | Monitoring Tool for KVM guests | package


On 15SP5 AArch64 I see:

# zypper se --requires qemu-kvm

  | kanku-worker               | Worker daemon for kanku  | package
  | python3-avocado-plugins-vt | Avocado Virt Test Plugin | package

# zypper se --recommends qemu-kvm
  | build | A Script to Build SUSE Linux RPMs | package

# zypper se --conflicts qemu-kvm
  | kvm_stat | Monitoring Tool for KVM guests | package

On 15SP5 x86 I see:

# zypper se --requires qemu-kvm

?? nothing ??

# zypper se --recommends qemu-kvm
  | build | A Script to Build SUSE Linux RPMs | package

curiously enough:

# zypper se --conflicts qemu-kvm

 | kvm_stat                                             | Monitoring -> |package
 | SUSE-SLE-Module-Server-Applications-15-SP5-2023-2549 | Recommended-> | patch
 | SUSE-SLE-Module-Server-Applications-15-SP5-2023-3082 | Security up-> | patch
 | SUSE-SLE-Module-Server-Applications-15-SP5-2023-4662 | Security up-> | patch

(In reply to Dario Faggioli from comment #3)
> We've always been building that package only for '%ix86 x86_64 s390x'. I
> don't know why that's the case... Historical reasons, probably, as the
> qemu-kvm fork was available for those arch-es, or something like that.

I think that's the case. The original qemu-kvm package (created when the fork existed, i.e. before kvm support was merged into upstream qemu) only supported x86 and s390.

> We can change that, if we want or need. Or we can just see if we can get rid
> of that package which, by the way, contains *ONLY* a symlink from
> /usr/bin/qemu-system-x86_64 (or _s390x) to /usr/bin/qemu-kvm.

I'm a little worried about dropping it, or at least the symlink. There could be old VMs out there with <emulator>/usr/bin/qemu-kvm</emulator> in their config. IIRC, our install tools (vm-install and/or virt-install) used to create such config.

(In reply to Claudio Fontana from comment #8)
> # zypper se --requires qemu-kvm
...
> systemd-testsuite          | Testsuite for systemd                   |
> package

IMO, this bug is fixed by fixing the systemd-testsuite package. We should also evaluate whether the other packages requiring/recommending qemu-kvm need adjusted.

(In reply to James Fehlig from comment #9)
> (In reply to Dario Faggioli from comment #3)
> > We've always been building that package only for '%ix86 x86_64 s390x'. I
> > don't know why that's the case... Historical reasons, probably, as the
> > qemu-kvm fork was available for those arch-es, or something like that.
> 
> I think that's the case. The original qemu-kvm package (created when the
> fork existed, i.e. before kvm support was merged into upstream qemu) only
> supported x86 and s390.
> 
> > We can change that, if we want or need. Or we can just see if we can get rid
> > of that package which, by the way, contains *ONLY* a symlink from
> > /usr/bin/qemu-system-x86_64 (or _s390x) to /usr/bin/qemu-kvm.
> 
> I'm a little worried about dropping it, or at least the symlink. There could
> be old VMs out there with <emulator>/usr/bin/qemu-kvm</emulator> in their
> config. IIRC, our install tools (vm-install and/or virt-install) used to
> create such config.

I agree. I think we need to keep the qemu-kvm package,

but we should avoid having dependencies to it (or even conflicts with it, the conflict with kvm_stat is very strange).

> 
> (In reply to Claudio Fontana from comment #8)
> > # zypper se --requires qemu-kvm
> ...
> > systemd-testsuite          | Testsuite for systemd                   |
> > package
> 
> IMO, this bug is fixed by fixing the systemd-testsuite package. We should
> also evaluate whether the other packages requiring/recommending qemu-kvm
> need adjusted.

(In reply to James Fehlig from comment #9)
> I'm a little worried about dropping it, or at least the symlink. There could
> be old VMs out there with <emulator>/usr/bin/qemu-kvm</emulator> in their
> config. IIRC, our install tools (vm-install and/or virt-install) used to
> create such config.
> 
Well, I think I can make the qemu-system-%{arch} packages create the link themselves.

Like, if you install qemu-system-x86 (which ships the qemu-system-x86_64 binary) and we are on x86_64, create the qemu-kvm -> qemu-system-x86_64 symlink. If you install qemu-system-s390x and we are on x86_64, create the qemu-kvm -> qemu-system-s390x symlink.

I only have to see if I need to do this in the %postinst phase of such packages (and, if yes, I don't know if it's possible to check the architecture of the machine where I'm installing the pacakge), or if it's fine during %build.

At that point (and if it works), I can even do something like, I think, "Obsoletes: qemu-kvm", still in those packages, and we don't even have to change the patterns...

(In reply to James Fehlig from comment #9)
> ...
> > systemd-testsuite          | Testsuite for systemd                   |
> > package
> 
> IMO, this bug is fixed by fixing the systemd-testsuite package. We should
> also evaluate whether the other packages requiring/recommending qemu-kvm
> need adjusted.
>
Problem is, it's probably not only the packages. It's what you said above about the link.

In fact, I don't know if we have VMs around with qemu-kvm set as their emulator. I'm, on the other hand, quite sure that `osc`, and probably even some tool/script in this systemd-testsuite is actually calling `qemu-kvm` _directly_.

So, if just we change the Requires: in the spec files, packages will be installable but then things will likely fail at runtime. :-/

(In reply to Dario Faggioli from comment #12)
> (In reply to James Fehlig from comment #9)
> > ...
> > > systemd-testsuite          | Testsuite for systemd                   |
> > > package
> > 
> > IMO, this bug is fixed by fixing the systemd-testsuite package. We should
> > also evaluate whether the other packages requiring/recommending qemu-kvm
> > need adjusted.
> >
> Problem is, it's probably not only the packages. It's what you said above
> about the link.
> 
> In fact, I don't know if we have VMs around with qemu-kvm set as their
> emulator. I'm, on the other hand, quite sure that `osc`, and probably even
> some tool/script in this systemd-testsuite is actually calling `qemu-kvm`
> _directly_.
> 
> So, if just we change the Requires: in the spec files, packages will be
> installable but then things will likely fail at runtime. :-/

Let us keep the qemu-kvm package containing the symlink on the x86 architecture.

People may have getting used to installing it. That is fine and we don't want to hurt existing users.

Let us however not add dependencies to it from other packages,
and let us hunt down the existing dependencies in existing packages for new products so that they do not depend anymore on this obsolete package and path that is there for backward compatibility only.

(In reply to Claudio Fontana from comment #13)
> Let us keep the qemu-kvm package containing the symlink on the x86
> architecture.

I tend to prefer this as well, especially for SLE15 SPx. For Factory, we could drop the package altogether, and discover/fix the fallout.

reporting same behavior on ppc64le: 
https://openqa.suse.de/tests/13316367#step/prepare_systemd_and_testsuite/71

can this be solved by fixing the systemd-testsuite.rpm package dependencies, or maybe just disable build for non-x86_64 archs ?

Hello Antonio,

Could you please the update the status.

(In reply to Dario Faggioli from comment #12)
> In fact, I don't know if we have VMs around with qemu-kvm set as their
> emulator. I'm, on the other hand, quite sure that `osc`, and probably even
> some tool/script in this systemd-testsuite is actually calling `qemu-kvm`
> _directly_.

I think it should be easily fixable as long as /usr/bin/qemu-system-x86_64 and /usr/bin/kvm behave the same way.

If you can confirm this I'll turn the dep:

  Requires: qemu-kvm

into

  Requires: qemu

Thanks.

This is an autogenerated message for OBS integration:
This bug (1218684) was mentioned in
https://build.opensuse.org/request/show/1147256 Factory / qemu

(In reply to Franck Bui from comment #17)
> (In reply to Dario Faggioli from comment #12)
> > In fact, I don't know if we have VMs around with qemu-kvm set as their
> > emulator. I'm, on the other hand, quite sure that `osc`, and probably even
> > some tool/script in this systemd-testsuite is actually calling `qemu-kvm`
> > _directly_.
> 
> I think it should be easily fixable as long as /usr/bin/qemu-system-x86_64
> and /usr/bin/kvm behave the same way.
> 
/usr/bin/kvm does not exist anywhere (as far as I know... And I really hope that to be the case, or that's another problem/bug! :-O)

/usr/bin/qemu-kvm, where it exists (i.e., only on x86_64 and s390x, for now) is a symlink to /usr/bin/qemu-system_x86_64, on x86_64, and to qemu-system_s390x, on s390x.

So, yes, they're identical.

> If you can confirm this I'll turn the dep:
> 
>   Requires: qemu-kvm
> 
> into
> 
>   Requires: qemu
> 
This is the right thing to do, and IMO, it should be done everywhere.

However, this may not be enough. In fact, if QEMU is invoked via 'qemu-kvm' somewhere in the code (of this, or of any other of the packages that depend from 'qemu-kvm'), things will fail "at runtime"... :-(

And that's why I did, with https://build.suse.de/request/show/321910, which should be enough a workaround/transition solution.

Basically, with that change, it's the 'qemu' package that creates the symlink, so it will exist on all arches (and, in each arch, it will point to the proper '/usr/bin/qemu-system-%{arch} binary). This way, any script/software/whatever invoking '/usr/bin/qemu-kvm' will continue to work.

At the packaging level, the 'qemu' package itself is now Providing and Obsoleting 'qemu-kvm', so dependencies should also be satisfied (even if/until the switch between 'Requires: qemu-kvm' and 'Requires: qemu' isn't done).

Can anyone provide feedback and/or test if what I did in https://build.suse.de/request/show/321910, and explained in comment 20 works?

(All that said, I must confess I really don't understand how we got into this situation... In fact, qemu-kvm has _NEVER_ been available for, e.g., aarch64... How is it possible that we have packages depending from it?!?! :-O )

(In reply to Dario Faggioli from comment #20)
> /usr/bin/kvm does not exist anywhere (as far as I know... And I really hope
> that to be the case, or that's another problem/bug! :-O)
> 

Sorry, typo here, should be read /usr/bin/qemu-kvm.

> /usr/bin/qemu-kvm, where it exists (i.e., only on x86_64 and s390x, for now)
> is a symlink to /usr/bin/qemu-system_x86_64, on x86_64, and to
> qemu-system_s390x, on s390x.
> 
> So, yes, they're identical.

My concern was about any trick in qemu that would have checked the name of the binary it was called from and did some special treatments when argv[0]=="qemu-kvm".

But from what I understood, it's not the case.

> However, this may not be enough. In fact, if QEMU is invoked via 'qemu-kvm'
> somewhere in the code (of this, or of any other of the packages that depend
> from 'qemu-kvm'), things will fail "at runtime"... :-(

As far as systemd is concerned, if the testsuite fails due to the use of qemu-kvm symlink, we'll fix it. Hence it's not worth keeping it if it's only for systemd.

(In reply to Dario Faggioli from comment #22)
> (All that said, I must confess I really don't understand how we got into
> this situation... In fact, qemu-kvm has _NEVER_ been available for, e.g.,
> aarch64... How is it possible that we have packages depending from it?!?!
> :-O )

Has this package been documented as obsolete somewhere or was there any related announcement ?

(In reply to Franck Bui from comment #24)
> (In reply to Dario Faggioli from comment #22)
> > (All that said, I must confess I really don't understand how we got into
> > this situation... In fact, qemu-kvm has _NEVER_ been available for, e.g.,
> > aarch64... How is it possible that we have packages depending from it?!?!
> > :-O )
> 
> Has this package been documented as obsolete somewhere or was there any
> related announcement ?

Package has been deprecated in multiple distros starting in 2013, but it just won't die, because there is always that one script that continues to use qemu-kvm from back when qemu mainline could not do kvm.

This is an autogenerated message for OBS integration:
This bug (1218684) was mentioned in
https://build.opensuse.org/request/show/1147539 Factory / systemd

(In reply to Franck Bui from comment #23) 
> My concern was about any trick in qemu that would have checked the name of
> the binary it was called from and did some special treatments when
> argv[0]=="qemu-kvm".
> 
> But from what I understood, it's not the case.
> 
Ah, ok, I see.

No, there used to be something like that in QEMU's Linux user space emulation, but we right now should be fine there as well (and, even if we're not, it'd be a different issue, as qemu-linux-user binaries don't use or know about the qemu-kvm link).

> > However, this may not be enough. In fact, if QEMU is invoked via 'qemu-kvm'
> > somewhere in the code (of this, or of any other of the packages that depend
> > from 'qemu-kvm'), things will fail "at runtime"... :-(
> 
> As far as systemd is concerned, if the testsuite fails due to the use of
> qemu-kvm symlink, we'll fix it. Hence it's not worth keeping it if it's only
> for systemd.
>
Good to hear, and thanks for that. Hopefully, I'v managed to find a way of getting rid of the package, which is already something. The symlink will stay, for now, but I'm not loosing hope of being able to nuke it at some point... :-O

A SR mentioning this bug was successfully integrated into Build 58.1. Please, if needed, set it to RESOLVED FIXED for QE to verify it.

(In reply to Radoslav Tzvetkov from comment #34)
> A SR mentioning this bug was successfully integrated into Build 58.1.
> Please, if needed, set it to RESOLVED FIXED for QE to verify it.
>
I've tested installing systemd-testsuite in Tumbleweed and on SP6, with the Devel:Virt:SLE-15-SP6 repository enabled, and it works.

I'm not sure about Build 58.1, but if the bots says we're fine, I guess we are.

Marking is as fixed.