qemu-devel
[Top][All Lists]
Advanced

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules fir


From: Philippe Mathieu-Daudé
Subject: Re: roms/efirom, tests/uefi-test-tools: update edk2's own submodules first
Date: Tue, 20 Oct 2020 11:54:37 +0200
User-agent: Mozilla/5.0 (X11; Linux x86_64; rv:78.0) Gecko/20100101 Thunderbird/78.3.1

On 10/20/20 11:44 AM, Daniel P. Berrangé wrote:
On Tue, Oct 20, 2020 at 11:29:01AM +0200, Philippe Mathieu-Daudé wrote:
Hi Olaf,

On 10/20/20 11:16 AM, Olaf Hering wrote:
This is about qemu.git#ec87b5daca761039bbcf781eedbe4987f790836f

On Mon, Sep 07, Laszlo Ersek wrote:

In edk2 commit 06033f5abad3 ("BaseTools: Make brotli a submodule",
2020-04-16), part of edk2-stable202005, the Brotli compressor /
decompressor source code that edk2 had flattened into BaseTools was
replaced with a git submodule.

This means we have to initialize edk2's own submodules before building
BaseTools not just in "roms/Makefile.edk2", but in "roms/Makefile" (for
the sake of the "efirom" target) and "tests/uefi-test-tools/Makefile" as
well.

+++ b/roms/Makefile
   edk2-basetools:
+       cd edk2/BaseTools && git submodule update --init --force
   build-edk2-tools:
+       cd $(edk2_dir)/BaseTools && git submodule update --init --force


This change can not possibly be correct.

With current qemu.git#master one is forced to have network access to
build the roms. This fails with exported (and complete) sources in an
offline environment.

The EDK2 roms are only used for testing, we certainly don't want them
to be used by distributions. I suppose the question is "why is this
rule called if tests are not built?".

I don't believe that is correct - the pc-bios/edk*  ROMs and the
corresponding  pc-bios/descriptor files are there for real world
end user consumption.   roms/edk2 should (must) match / reflect
the content used to build the pci-bios/edk* blobs.

Many distros have a policy requiring them to build everything
from source, so they will ignore the pre-built edk2 ROMs, but
regular end users taking QEMU directly from upstream can certainly
use our edk2 ROMs.

Well I'm lost (and I don't think mainstream QEMU have the
bandwidth to follow mainstream EDK2 security fixes) so I'm
giving up, waiting for clarification from Laszlo.



Regards,
Daniel





reply via email to

[Prev in Thread] Current Thread [Next in Thread]