spec: Advertise nvram paths of official fedora edk2 builds

Fedora now ships edk2 firmware in its official repos, so adapt
the nvram path list to match. Eventually we can remove the nightly
links as well once some integration kinks have been worked out,
and documentation updated.

Move the macro building into the %build target, which lets us
build up a shell variable and make things a bit more readable

https://bugzilla.redhat.com/show_bug.cgi?id=1335395
---
 libvirt.spec.in | 18 ++++++++++++------
 1 file changed, 12 insertions(+), 6 deletions(-)

-- 
2.7.4

--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list

On 05/27/2016 12:08 PM, Andrea Bolognani wrote:
> On Fri, 2016-05-20 at 16:03 -0400, Cole Robinson wrote:

>> Fedora now ships edk2 firmware in its official repos, so adapt

>> the nvram path list to match. Eventually we can remove the nightly

>> links as well once some integration kinks have been worked out,

>> and documentation updated.

>>  

>> Move the macro building into the %build target, which lets us

>> build up a shell variable and make things a bit more readable

>>  

>> https://bugzilla.redhat.com/show_bug.cgi?id=1335395

>> ---

>>   libvirt.spec.in | 18 ++++++++++++------

>>   1 file changed, 12 insertions(+), 6 deletions(-)

>>  

>> diff --git a/libvirt.spec.in b/libvirt.spec.in

>> index c7fcf85..8b88eef 100644

>> --- a/libvirt.spec.in

>> +++ b/libvirt.spec.in

>> @@ -192,12 +192,6 @@

>>   %define qemu_group  qemu

>>   

>>   

>> -# Advertise OVMF and AAVMF from nightly firmware repo

>> -%if 0%{?fedora}

>> -    %define arg_loader_nvram --with-loader-nvram="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-

>> efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd:/usr/share/edk2.git/aarch64/QEMU_EFI-

>> pflash.raw:/usr/share/edk2.git/aarch64/vars-template-pflash.raw"

>> -%endif

>> -

>> -

>>   %if 0%{?fedora} || 0%{?rhel} >= 7

>>       %define with_systemd_macros 1

>>   %else

>> @@ -1097,6 +1091,18 @@ rm -rf .git

>>       %define arg_selinux_mount --with-selinux-mount="/selinux"

>>   %endif

>>   

>> +%if 0%{?fedora}

>> +    # Nightly firmware repo x86/OVMF

>> +    LOADERS="/usr/share/edk2.git/ovmf-x64/OVMF_CODE-pure-efi.fd:/usr/share/edk2.git/ovmf-x64/OVMF_VARS-pure-efi.fd"

>> +    # Nightly firmware repo aarch64/AAVMF

>> +    LOADERS="$LOADERS:/usr/share/edk2.git/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2.git/aarch64/vars-template-

>> pflash.raw"

>> +    # Fedora official x86/OVMF

>> +    LOADERS="$LOADERS:/usr/share/edk2/ovmf/OVMF_CODE.fd:/usr/share/edk2/ovmf/OVMF_VARS.fd"

>> +    # Fedora official aarch64/AAVMF

>> +    LOADERS="$LOADERS:/usr/share/edk2/aarch64/QEMU_EFI-pflash.raw:/usr/share/edk2/aarch64/vars-template-pflash.raw"

>> +    %define arg_loader_nvram --with-loader-nvram="$LOADERS"

>> +%endif

>> +

>>   # place macros above and build commands below this comment

>>   

>>   %if 0%{?enable_autotools}

> 

> I'm wondering... /etc/libvirt/qemu.conf on my Fedora contains

> the NVRAM paths actually used by the driver[1], but I don't

> see anything in our build system that would update qemu.conf to

> reflect the value of the --with-loader-nvram configure option.

> Is the file simply statically patched by Fedora? Should we

> come up with an upstream solution that updates the file

> automatically at build time?

> 


Yeah, generating qemu.conf based on configure options is a good idea, to
document how the defaults are different. It's one of the things that's kicked
around in the back of my head for a long time WRT --with-qemu-user

> Most importantly... Why are those paths so ugly and

> inconsistent? :S

> 


The OVMF stuff is to roughly match the naming of the original RHEL packages,
and with aarch64 which came later the file names were intended to be improved,
but side by side it just makes things look inconsistent.

> ACK

> 


Thanks pushed now.

> 

> [1] There are actually two entries, only the second one has

>     the right paths


Hmm, what do you mean exactly? The stock qemu.conf nvram paths match the RHEL
packages, they look correct to me.

- Cole


--
libvir-list mailing list
libvir-list@redhat.com
https://www.redhat.com/mailman/listinfo/libvir-list