On Fri, Apr 28, 2017 at 09:23:03PM +0300, Michael Tokarev wrote:
> Just a small comment without trying to understand what's going on..
>
> 28.04.2017 20:25, dann frazier wrote:
> []
> > For 32-bit ARM, I propose we use:
> > /usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd
>
> If it's QEMU-foo, why can't
Just a small comment without trying to understand what's going on..
28.04.2017 20:25, dann frazier wrote:
[]
> For 32-bit ARM, I propose we use:
> /usr/share/AAVMF/AAVMF32_{CODE,VARS}.fd
If it's QEMU-foo, why can't we drop things directly
to /usr/share/qemu/ ?
Thanks,
/mjt
On Thu, Dec 01, 2016 at 03:25:29PM -0700, dann frazier wrote:
> My reasons for choosing "qemu-efi" when adding the aa64 images were
> twofold:
> 1) "OVMF", in upstream source, refers only to the x86-specific
> build. The ARM images have always had a different name - initially
> ArmVirtuali
On Mon, Oct 31, 2016 at 12:11:31PM +0100, Alexander Kurtz wrote:
> This becomes even more important if you try to fix #842683 [1], so I
> propose a scheme looking something like this:
>
> * There is only one arch:all package called "ovmf" containing the
>builds for all architectures.
>
> *
Package: src:edk2
Version: 0~20160813.de74668f-2
Severity: wishlist
Hi!
[0] shows the binary packages currently being built from src:edk2:
* The "ovmf" package contains the build for x64 in
/usr/share/OVMF/OVMF_{CODE,VARS}.fd
* The "qemu-efi" contains the build for aa64
in/usr/share/AAV
5 matches
Mail list logo
