current ebuild sets $BUILD_FLAGS in src_compile() to include -D HTTP_BOOT_ENABLE -D TLS_ENABLE for building with HTTP{S] support enabled. however, these defines have been (long) renamed to NETWORK_HTTP_BOOT_ENABLE and NETWORK_TLS_ENABLE with https://github.com/tianocore/edk2/commit/631195044ff0 thus the current builds of sys-firmware/edk2-ovmf (and the derived sys-firmware/edk2-ovmf-bin) lack HTTP[S] boot support. this got also updated in the README (https://github.com/tianocore/edk2/commit/1631bb26ae991e530d3c96fe3161ea15144b358e)
The bug has been closed via the following commit(s): https://gitweb.gentoo.org/repo/gentoo.git/commit/?id=261679779725bee6e18de4b66f0674796a2d1278 commit 261679779725bee6e18de4b66f0674796a2d1278 Author: James Le Cuirot <chewi@gentoo.org> AuthorDate: 2024-09-25 13:50:28 +0000 Commit: James Le Cuirot <chewi@gentoo.org> CommitDate: 2024-10-10 16:29:35 +0000 sys-firmware/edk2: Bump to 202408, Python 3.13, many other improvements The ebuild has been largely rewritten. It now: * Respects CC, CXX, and flags when building the base tools. * Doesn't use gcc/cc when building the firmware, enabling cross. * Prepares the ground for supporting platforms other than OVMF for x64. * Installs OVMF_VARS.secboot.fd prepared with virt-fw-vars. * Includes the latest UEFI DBX update in OVMF_VARS.secboot.fd. * Adds 4MB variants of the .fd images (in QCOW2 format). * Fixes network support broken by a recent bump. * Drops EnrollDefaultKeys.efi and UefiShell.img The enrollment tool hasn't actually worked for a while and is no longer needed now that we provide OVMF_VARS.secboot.fd. UefiShell.img is therefore of little use, and other distros now provide UefiShell.iso instead anyway. We can do the same if there is sufficient interest. This moves us closer to Fedora, but they ship far more variants. They have a large Python wrapper around upstream's build system, which is unusual in itself. Building all these would make the ebuild much more complex, take a long time, and use up more disk space. Perhaps USE flags could help here, but I'm not sure what all these variants are for. I also decided to install to paths based on upstream's names, e.g. edk2/ArmVirtQemu-AARCH64 as opposed to Fedora's edk2/aarch64 because mixing QEMU with Xen and others would be confusing when there are many similarly named files, even within a single architecture. Closes: https://bugs.gentoo.org/891191 Closes: https://bugs.gentoo.org/921819 Closes: https://bugs.gentoo.org/929838 Signed-off-by: James Le Cuirot <chewi@gentoo.org> sys-firmware/edk2/Manifest | 4 + sys-firmware/edk2/edk2-202408.ebuild | 255 +++++++++++++++++++++ .../30-edk2-ovmf-4m-qcow2-x64-sb-enrolled.json | 36 +++ .../31-edk2-ovmf-2m-raw-x64-sb-enrolled.json | 36 +++ .../descriptors/40-edk2-ovmf-4m-qcow2-x64-sb.json | 35 +++ .../descriptors/41-edk2-ovmf-2m-raw-x64-sb.json | 35 +++ .../50-edk2-ovmf-4m-qcow2-x64-nosb.json | 36 +++ .../descriptors/51-edk2-ovmf-2m-raw-x64-nosb.json | 36 +++ 8 files changed, 473 insertions(+)
