Contrary to the description in the patch, the openSSL license terms do
not require us to modify the splash screen boot logo. This boot logo
is not considered advertizing material, and the other attribution
requirement in the license is satisfied by shipping the complete
corresponding source.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
In ELN builds %{rhel} is defined and %{fedora} is unset
This causes EDK to assume the RHEL qemu-kvm packaging scheme.
This is invalid for ELN, however, because it still follows the
Fedora packaging scheme for QEMU.
Signed-off-by: Daniel P. Berrangé <berrange@redhat.com>
The fedora specific stuff stays the same, but the x86_64 and
aarch64 builds look different but should be identical, except for
some additional builds and filenames
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* Simplify build conditionals
* Use less globbing in %files list
* Merge package descriptions and metadata from RHEL
* Separate out fedora specific bits from common bits shared with RHEL
* Lots of small syntax changes to move closer to RHEL package
Signed-off-by: Cole Robinson <crobinso@redhat.com>
RHEL build-iso is not an external script, it's inline in the spec,
and uses mtools instead of qemu-img
Signed-off-by: Cole Robinson <crobinso@redhat.com>
RHEL does not bundle the source archive, but just a copy of the
script. Use that model and the ovmf-vars-generator syntax RHEL uses.
This part of an effort to make it easier to share edk2 packaging
across Fedora and RHEL
Signed-off-by: Cole Robinson <crobinso@redhat.com>
* The openssl archive is preprocessed, so drop all the helper scripts.
* Split binary is removed
* Change %setup to handle centos 9 formatted patches
Signed-off-by: Cole Robinson <crobinso@redhat.com>
From version 4.1 (due in August 2019) onwards, QEMU ships the so-called
firmware "descriptor files". These are small JSON files that describe
details about UEFI firmware binaries — such as the fimware binary path,
its architecture, supported machine type, NVRAM template and so forth.
You can see examples of these files from the QEMU upstream Git:
https://git.qemu.org/?p=qemu.git;a=tree;f=pc-bios/descriptors
$> tree descriptors/
descriptors/
├── 50-edk2-i386-secure.json
├── 50-edk2-x86_64-secure.json
├── 60-edk2-aarch64.json
├── 60-edk2-arm.json
├── 60-edk2-i386.json
└── 60-edk2-x86_64.json
QEMU 4.1 itself will ship the above files. However, Fedora needs to
ship these file as part of its EDK2 package.
Why?
----
(1) Quoting (with minor formatting edits) Laszlo Ersek:
Distributions providing their own EDK2 packages would not include
the descriptors from upstream QEMU, even if they otherwise package
QEMU. That's beause the descriptor files in QEMU match the
firmware bundled with QEMU -- but the firmware images in the
distros' own EDK2 packages are different. So, if a distro
provides an EDK2 package, then the same EDK2 package should offer
matching descriptors. QEMU offers descriptors (soon) because QEMU
technically distributes edk2 firmware binaries (soon). [Where
"soon" == QEMU 4.1]
(2) And as Dan Berrangé reminded on IRC:
In Fedora, we need to ship them [the "descriptor files"] as part
of the EDK2 package, because Fedora throws away all the firmware
files that QEMU bundles, because we're [Fedora] required to
rebuild everything from pristine source.
- - -
In this patch:
(*) Use the firmware descriptor files provided by Laszlo (thanks!) in
this comment here:
https://bugzilla.redhat.com/show_bug.cgi?id=1728652#c2 ("RFE: Ship
the JSON firmware "descriptor files" as part of EDK2").
On the double-digit priority prefixes, refer to the rationale here:
https://src.fedoraproject.org/rpms/edk2/pull-request/3#comment-27523
(*) Install the JSON files for the relevant architectures in
`/usr/share/qemu/firmware`, as required by specification[+]. And
make each EDK2 own this directory; multiple RPMs owning the same
directory is no problem.
[+] https://git.qemu.org/?p=qemu.git;a=blob;f=docs/interop/firmware.json
Resolves: rhbz#1728652
Signed-off-by: Kashyap Chamarthy <kchamart@redhat.com>
