https://bugzilla.redhat.com/show_bug.cgi?id=1325023 --- Comment #16 from Laszlo Ersek <lersek@xxxxxxxxxx> --- (Click "Unwrap comments" near the top, for reading this comment.) For the spec file from "edk2-20160411git4da1ebf-0.el7.src.rpm": > %global edk2_date 20160411 > %global edk2_githash 4da1ebf > %global openssl_version 1.0.2g > > Name: edk2 > Version: %{edk2_date}git%{edk2_githash} > Release: 0%{dist} > Summary: EFI Development Kit II > > Group: Applications/Emulators > License: BSD The license is incorrect; it is not pure BSD if OpenSSL (i.e., Secure Boot) is included in the binaries. The right term is BSD and OpenSSL This is based on <https://fedoraproject.org/wiki/Packaging:LicensingGuidelines#Multiple_Licensing_Scenarios>, which describes how the "and" operator can be used, and also based on <https://fedoraproject.org/wiki/Licensing:Main#Good_Licenses>, which lists "OpenSSL" as short name for the OpenSSL License, and "BSD" for the BSD License (two clause). Namely (with the FatPkg relicensing), the License.txt files under all *Pkg directories whose modules go into the OVMF and AAVMF binaries are the 2-clause BSDL, except for CryptoPkg/Library/OpensslLib/openssl-*/LICENSE, which is the OpenSSL License. Since we have two subpackages, and AAVMF won't include the Secure Boot feature, the subpackages also need their separate License fields. And, AAVMF should state plain "BSD". > URL: http://www.tianocore.org/edk2/ > Source0: edk2-%{edk2_date}-%{edk2_githash}.tar.gz > Source1: https://www.openssl.org/source/openssl-%{openssl_version}.tar.gz > Source3: build-iso.sh > Source9: update-tarball.sh > > Patch1: 0001-pick-up-any-display-device-not-only-vga.patch This patch is from Gerd; it is so that OVMF is willing to drive "secondary-vga" devices of QEMU. This patch is not upstream because we haven't submitted it yet. If Gerd submits it, I'll ACK it, but a good argument should be made for it in the commit message. (I guess it should be a description of the secondary-vga device, why it is useful etc.) > Patch2: 0001-MdeModulePkg-TerminalDxe-add-other-text-resolutions.patch This patch is un-upstreamable. We tried, we failed. It resulted in a 3-month long off-list discussion that produced no results. > Patch3: 0001-EXCLUDE_SHELL_FROM_FD.patch We have this patch because Peter Jones advised us that hardware vendors exclude the UEFI shell from firmware that contains the Secure Boot feature. Namely, if the Secure Boot operating mode is enabled, the shell could still be launched without problems if the shell binary was part of the system firmware, and then the Secure Boot operating mode could be circumvented from the shell (using internal shell commands). Thus, we provide the UEFI shell binary on an ISO image, as an external UEFI application. This binary is not signed, hence when the Secure Boot operating mode is enabled, the shell can't be launched. When the Secure Boot operating mode is disabled, the shell can be launched from the ISO image as the default boot application. > Patch4: 0001-OvmfPkg-disable-multi-processor-support-for-boot-tim.patch This used to be a workaround for a UefiCpuPkg/CpuDxe bug, but it is no longer necessary. Please drop this patch. I vaguely suspect that we may have kept this patch to work around the MTRR-related problems that predated Linux v4.4 (on the host), but it really shouldn't be necessary now. I haven't been using this patch myself for a very long time now. > Patch10: 0001-OvmfPkg-SmbiosPlatformDxe-install-legacy-QEMU-tables.patch > Patch11: 0002-OvmfPkg-SmbiosPlatformDxe-install-patch-default-lega.patch > Patch12: 0003-OvmfPkg-SmbiosPlatformDxe-install-patch-default-lega.patch These patches support the "old" SMBIOS guest interface, on machine types that are smaller than 2.1. (Gabriel Somlo's "new" SMBIOS guest interface appeared in QEMU 2.1, and he also wrote the OVMF patches for it.) These patches for the "old" interface are from yours truly, and upstream never accepted them -- Jordan asked me to factor out SMBIOS support from a number of other modules (I think even EmulatorPkg?) as a prerequisite, which I thought was an unreasonable request, and I abandoned upstreaming these patches. I guess in Fedora noone uses such old machine types (i.e., machtypes before 2.1), so I guess these could be removed, if someone is bothered by them. > > Patch20: 0001-OvmfPkg-EnrollDefaultKeys-application-for-enrolling-.patch This UEFI application (also present on the ISO image that we prepare, beside the UEFI shell binary) streamlines the enrollment of the three most common Microsoft Secure Boot keys. It also enables the Secure Boot operating mode. This is not upstream because (a) there are about a dozen divergent solutions for helping with key enrollment, none of them upstream, (b) UEFI-2.6 defines facilities (AuditMode and DeployedMode) in which the enrollment is delegated to the first boot of the OS (very roughly). Ultimately this patch should be replaced with userspace Linux utilities that work on physical UEFI machines too. > %ifarch aarch64 > %package aarch64 > Summary: Arm Virtual Machine Firmware I think it would be more appropriate to say AARCH64 here. > Provides: AAVMF > BuildArch: noarch > %description aarch64 > EFI Development Kit II > AARCH64 UEFI Firmware > %endif > # common features > CC_FLAGS="${CC_FLAGS} -D HTTP_BOOT_ENABLE" > CC_FLAGS="${CC_FLAGS} -D NETWORK_IP6_ENABLE" These flags are OVMF specific; "ArmVirtPkg/ArmVirtQemu.dsc" doesn't know about them. For OVMF, they are appropriate. Furthermore, please add the following two to the common build options: -b DEBUG --cmd-len=65536 The first makes sure we build for the DEBUG target, regardless of what "BaseTools/Conf/target.template" says. The second one speeds up the build. (Background: the compiler command line can grow very large for some modules of edk2, and it brakes various windows tools that only support 4KB command lines. This got worked around recently in BaseTools by generating an option file (= @file) for each invocation of the compiler, by default. This works on Linux too, but it is not necessary, and to me it seemed to slow down the build quite a bit. The --cmd-len switch above makes sure the @file thing won't be activated unless the command line exceeds 64KB.) > # secure boot build features > SB_FLAGS="${CC_FLAGS}" > SB_FLAGS="${SB_FLAGS} -D SECURE_BOOT_ENABLE" > SB_FLAGS="${SB_FLAGS} -D SMM_REQUIRE" > SB_FLAGS="${SB_FLAGS} -D EXCLUDE_SHELL_FROM_FD" > > # arm firmware features > ARM_FLAGS="${CC_FLAGS}" > ARM_FLAGS="${ARM_FLAGS} -D DEBUG_PRINT_ERROR_LEVEL=0x8040004F" Right, this is good. Actually, I think DEBUG_VERBOSE should also be enabled for OVMF too; given that the package will be available in Fedora to a large number of users, we'll want as much debug output as possible. I have five more patches for that (they are all downstream-only, as this kind of setting is not expected to be massaged in upstream); I'll mail them to Gerd for the next build. > > make -C BaseTools #%{?_smp_mflags} BaseTools should not be built concurrently; as discussed above. > %ifarch aarch64 > # build arm/aarch64 firmware > mkdir -p aarch64 > build $ARM_FLAGS -a AARCH64 -p ArmVirtPkg/ArmVirtQemu.dsc > cp Build/ArmVirtQemu-AARCH64/DEBUG_*/FV/*.fd aarch64 > dd of="aarch64/QEMU_EFI-pflash.raw" if="/dev/zero" bs=1M count=64 > dd of="aarch64/QEMU_EFI-pflash.raw" if="aarch64/QEMU_EFI.fd" conv=notrunc I think this could be simplified as cat .../QEMU_EFI.fd /dev/zero | head -c 64M > ... but I don't feel strongly about it. > %ifarch x86_64 > %files ovmf > %license OvmfPkg/License.txt Please include CryptoPkg/Library/OpensslLib/openssl-*/LICENSE here, as a separate file. Thanks Laszlo -- You are receiving this mail because: You are on the CC list for the bug. _______________________________________________ package-review mailing list package-review@xxxxxxxxxxxxxxxxxxxxxxx http://lists.fedoraproject.org/admin/lists/package-review@xxxxxxxxxxxxxxxxxxxxxxx