https://bugzilla.redhat.com/show_bug.cgi?id=1325023 --- Comment #20 from Laszlo Ersek <lersek@xxxxxxxxxx> --- (In reply to Gerd Hoffmann from comment #19) > (In reply to Laszlo Ersek from comment #18) > > The spec file in "edk2-20160412gitba83f7e-0.el7.src.rpm" looks good to me. > > > > However, I'm noticing two things I should have noticed earlier (sorry!): > > > > - We probably should not ship the unified "/usr/share/edk2/ovmf/OVMF.fd" > > file, > > only the split files. > > Hmm, why? Can be useful for throwaway virtual machines, such as booting > a live iso with efi. Without that you have to copy the varstore to some > temp file, boot, then delete the tmpfile even if you don't need the efi > variable persistance. The setup you describe is valid for throwaway VMs; it parallels the case when QEMU is started without a writeable hard disk. It's just that I've seen reports where a user uses -bios (or an equivalent "hand-crafted" domain XML) for VMs that are meant to be persistent. The resultant confusion is not good. Personally, I never use the unified file, not even for throwaway VMs. I do the copying (in scripts) the way you describe. It's not a big burden, and the originally unneeded persistence actually turns out welcome in some cases. I also found it inconsistent that the build without the Secure Boot feature provides a unified binary, while the build with the SB feature doesn't. If the argument is throwaway VMs, then I guess it does make sense (you can't enable SB without enrolling keys and rebooting the VM, hence SB only applies to non-throwaway VMs). Anyway, up to you. > > - The aarch64 build seems to have disappeared, after 2016-04-08, from > > <https://kraxel.fedorapeople.org/review/edk2>. Is this intentional? > > The old ones are still there. But didn't do a fresh aarch64 build, so > there are no updated aarch64 rpms. /me goes kick a build ... Looks good, thanks. -- 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