[fedora-arm] Re: 2:qemu-system-x86-2.6.0-4.fc25.aarch64 -> edk2-ovmf dependency

[Peter Robinson]

[Hi Peter, might be easier to discuss this with everyone on the
mailing list rather than in fragmentary IRC conversations.]
At the moment anything that depends on libvirt-daemon-qemu will
try to pull in qemu-system-x86 which fails (on aarch64, possibly
Error: Package: 2:qemu-system-x86-2.6.0-4.fc25.aarch64 (build)
Requires: edk2-ovmf
eg: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3617462
edk2-ovmf is a noarch package, but we don't build it on aarch64
because the spec file (edk2.spec) has %ifarch x86_64 around it,
%ifarch x86_64
%package ovmf
Summary: Open Virtual Machine Firmware
License: BSD and OpenSSL
Provides: OVMF
BuildArch: noarch
%description ovmf
EFI Development Kit II
Open Virtual Machine Firmware (x64)
%endif
So how to fix ...
I'm unclear why qemu-system-x86 hard-Requires edk2-ovmf, since x86 VMs
usually use SeaBIOS. Booting them with UEFI is not very common. I
guess this should be a Suggests/Recommends kind of dependency.
Alternately is there some way to pull the noarch package into arm.koji
even though it was built on a primary architecture?

This must surely be possible, as ipxe is in the exact same situation
where it is marked to only build on x86

Not sure how ipxe builds but it's output is noarch rpms which get
imported. This is not the case with edk2

[Peter Robinson]

Post by Peter Robinson

[Hi Peter, might be easier to discuss this with everyone on the
mailing list rather than in fragmentary IRC conversations.]
At the moment anything that depends on libvirt-daemon-qemu will
try to pull in qemu-system-x86 which fails (on aarch64, possibly
Error: Package: 2:qemu-system-x86-2.6.0-4.fc25.aarch64 (build)
Requires: edk2-ovmf
eg: http://arm.koji.fedoraproject.org/koji/taskinfo?taskID=3617462
edk2-ovmf is a noarch package, but we don't build it on aarch64
because the spec file (edk2.spec) has %ifarch x86_64 around it,
%ifarch x86_64
%package ovmf
Summary: Open Virtual Machine Firmware
License: BSD and OpenSSL
Provides: OVMF
BuildArch: noarch
%description ovmf
EFI Development Kit II
Open Virtual Machine Firmware (x64)
%endif
So how to fix ...
I'm unclear why qemu-system-x86 hard-Requires edk2-ovmf, since x86 VMs
usually use SeaBIOS. Booting them with UEFI is not very common. I
guess this should be a Suggests/Recommends kind of dependency.
Alternately is there some way to pull the noarch package into arm.koji
even though it was built on a primary architecture?

This must surely be possible, as ipxe is in the exact same situation
where it is marked to only build on x86

Not sure how ipxe builds but it's output is noarch rpms which get
imported. This is not the case with edk2

Yes & no. One output RPM is x86_64, but the others are noarch, and it is
the noarch ones that we need to satisfy QEMU deps.
edk2-aarch64.noarch
edk2-ovmf.noarch
edk2-tools.x86_64
edk2-tools-doc.noarch
edk2-tools-python.noarch
Are you saying that aarch builder will only import things if *all*
sub-RPMs are noarch ? If so that's a bit of a problem. It should be
able to import noarch sub-RPMs and ignore arch dependant sub-RPMs

Yes, it only imports packages that are completely noarch, else it
builds the package. There is no means to do partial build/partial
import of a package, it's one or the other. Why would we want to do
partial of anything, there would be need to be a complex mapping of
how it handles each package in each case and we've never had (nor do
we want) a reason to do this prior to now.

Peter

[Richard W.M. Jones]

If we can't build edk2 x86_64 bios blob on aarch64, and can't import
the previously built noarch packages, then seems to say the only
option left is to split the edk2 package into two source packages.
One that exclusively builds the BIOS blobs (and can be entirely
noarch), and one that builds the host tools (which is arch dependant).
It rather sucks that build system limitations would force us to split
the source RPM in this way though :-(

The alternative might be to reduce the hard Requires dependency
to either Recommends or Suggests. What do you think about that?

Rich.

[Peter Robinson]

Post by Richard W.M. Jones

If we can't build edk2 x86_64 bios blob on aarch64, and can't import
the previously built noarch packages, then seems to say the only
option left is to split the edk2 package into two source packages.
One that exclusively builds the BIOS blobs (and can be entirely
noarch), and one that builds the host tools (which is arch dependant).
It rather sucks that build system limitations would force us to split
the source RPM in this way though :-(

The alternative might be to reduce the hard Requires dependency
to either Recommends or Suggests. What do you think about that?

I'm not a huge fan of that, because I think it is desirable for apps
to be able to presume EFI support is available out of the box if QEMU
is installed. Making it optional will just leave to user bug reports
when trying to use EFI in virt-manager and it failing due to missing
BIOS.
Though as a short term hack, I guess I'd be ok with making it Recommends
on aarch64 only, and leaving it as Requires on all other arches, with a
view to making it Requires again on aarch64 once we have a better fix.

It's also an issue when building libguestfs on ppc.koji and presumably
s390.koji due to qemu-system-x86

DEBUG util.py:421: Error: nothing provides edk2-ovmf needed by
qemu-system-x86-2:2.6.0-4.fc25.ppc64

http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3518487

[Peter Robinson]

Post by Peter Robinson

Post by Richard W.M. Jones

If we can't build edk2 x86_64 bios blob on aarch64, and can't import
the previously built noarch packages, then seems to say the only
option left is to split the edk2 package into two source packages.
One that exclusively builds the BIOS blobs (and can be entirely
noarch), and one that builds the host tools (which is arch dependant).
It rather sucks that build system limitations would force us to split
the source RPM in this way though :-(

The alternative might be to reduce the hard Requires dependency
to either Recommends or Suggests. What do you think about that?

I'm not a huge fan of that, because I think it is desirable for apps
to be able to presume EFI support is available out of the box if QEMU
is installed. Making it optional will just leave to user bug reports
when trying to use EFI in virt-manager and it failing due to missing
BIOS.
Though as a short term hack, I guess I'd be ok with making it Recommends
on aarch64 only, and leaving it as Requires on all other arches, with a
view to making it Requires again on aarch64 once we have a better fix.

It's also an issue when building libguestfs on ppc.koji and presumably
s390.koji due to qemu-system-x86
DEBUG util.py:421: Error: nothing provides edk2-ovmf needed by
qemu-system-x86-2:2.6.0-4.fc25.ppc64
http://ppc.koji.fedoraproject.org/koji/taskinfo?taskID=3518487

Ok, lets rephrase that. I'd be fine with having Requires on x86_64
and Recommends on all other arches for edk2-ovmf, on the basis that
99% of users will be using ovmf on x86_64 hosts with KVM. The number
of people wanting to use ovmf with QEMU on non-x86_64 is likely single
digits.

Works for me except for aarch64 on aarch64 where it would be good to
have it a hard dep as well