On 3/12/19 4:33 PM, Laszlo Ersek wrote: > On 03/10/19 12:21, Philippe Mathieu-Daudé wrote: >> On 3/10/19 4:56 AM, Michael S. Tsirkin wrote: >>> On Sat, Mar 09, 2019 at 01:48:16AM +0100, Laszlo Ersek wrote: >>>> Repo: https://github.com/lersek/qemu.git >>>> Branch: edk2_build >>>> >>>> This series advances the roms/edk2 submodule to the "edk2-stable201903" >>>> release, and builds and captures platform firmware binaries from that >>>> release. At this point they are meant to be used by both end-users and >>>> by Igor's ACPI unit tests in qtest ("make check"). >>>> >>>> Previous discussion: >>>> >>>> [Qemu-devel] bundling edk2 platform firmware images with QEMU >>>> >>>> 80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com">http://mid.mail-archive.com/80f0bae3-e79a-bb68-04c4-1c9c684d95b8@redhat.com >>>> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02601.html >> >> There David raised a concern about "[adding] ~206 MB of binaries to the >> pc-bios directory". > > (I think the concern was voiced by Dan first.) > >> I'm also worried. > > I'm not. The actual data size, both to transfer (push/pull) and to store > in the .git subdirectory, is ~9MB. (As I explained earlier.) > > git-checkout *could* in theory eat more space, but, in my testing, it > doesn't; for me, git-checkout punches holes in the checked-out files. > Please see the earlier discussion for that reference too. (Note: I'm on > ext4, so nothing enterprisey like xfs.) > >> GitHub kindly suggest to use git-lfs. > > Just ignore that -- not because it's another dependency, but because > external storage for these blobs is actually not required. > >> It is an extra dependency I'd >> rather strongly avoid (because we support a wide range of host OS, each >> using a wide types of filesystems). >> >> What about storing those binaries on a file server (http/ftp) altogether >> with a file containing its hashed digest (SHA1/SHA256)? Then we already >> have all the required tools to fetch and verify those blob roms with the >> build system. >> Or we could store the hashes in the QEMU repository too. > > Let's not implement "fedpkg sources" within upstream QEMU, unless we > really must. > >> >>>> Note that the series was formatted with "--no-binary" (affecting patch >>>> #8), therefore it cannot be applied with "git-am". See the remote >>>> repo/branch reference near the top instead. >>>> >>>> Thanks, >>>> Laszlo >>> >>> High time IMO. >> >> :) >> >>> Reviewed-by: Michael S. Tsirkin <m...@redhat.com> >>> >>> Laszlo I suggest you add an entry to MAINTAINERS >>> and start doing pull requests. > > I'm glad to do that (in the hope that updates will be mostly painless, > regarding the build scaffolding). > >> >> This is the entry I added here: >> https://lists.gnu.org/archive/html/qemu-devel/2019-03/msg02967.html > > Hmm. That hunk is insufficient (it doesn't cover the files being added > here), but if I add another hunk myself, then we'll have redundancy. > > In other words, this is a conflict. How should we resolve it? Should I > add a separate patch at the end, and let Michael drop it or resolve the > conflict, dependent on the order in which the series end up being merged?
Likely yours first. These two lines should match your series: F: pc-bios/descriptors/*edk2* F: pc-bios/*edk2* >> >>> >>> Peter, what do you say? OK with you? >> >> Since this series doesn't change the QEMU binaries built, it looks OK to >> me to merge it past soft freeze (as we do we tests/CI), this way it get >> merged with the final EDK2 release tag. >> Else we can merge it next week, and update the EDK2 submodule tag >> previous QEMU release. > > I don't understand this paragraph -- the edk2 submodule commit reference > is already the final one I have targeted for this work, namely > "edk2-stable201903". (I had worried edk2 would suffer a delay in > publishing the tag, but ultimately the community managed it just in time.) "If edk2-stable201903 tag were delayed, this series is still OK to get merged for the hard freeze (next tuesday)." > Thanks > Laszlo
