(+Daniel and MST) On 03/20/19 16:58, Peter Maydell wrote: > On Wed, 20 Mar 2019 at 15:31, Laszlo Ersek <ler...@redhat.com> wrote: >> >> Hi Peter, >> >> On 03/19/19 10:22, Peter Maydell wrote: >>> On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé <f4...@amsat.org> >>> wrote: >>>> >>>> Hi Peter, >>>> >>>> Le dim. 17 mars 2019 23:02, Peter Maydell <peter.mayd...@linaro.org> >>>> a écrit : >>>>> >>>>> On Sun, 17 Mar 2019 at 20:29, Peter Maydell >>>>> <peter.mayd...@linaro.org> wrote: >>>>>> Hi; this fails to build on OSX and OpenBSD: >>>>>> >>>>>> UNXZ pc-bios/edk2-aarch64-code.fd.xz >>>>>> /bin/sh: xz: command not found >>>> >>>> >>>> I checked Travis builds for OSX. I suppose the Travis image has xz >>>> pulled/pre-installed and yours doesn't. >>> >>> Yeah, I expect I could install xz from homebrew here. >>> >>>> I used to check on OpenBSD until realizing you are the only one doing >>>> that. After having spent quite some time on it I removed it from my >>>> list, thus missed this failure. EDK2 doesn't build on OpenBSD but >>>> still this OS should be able to decompress the ROMs. >>> >>> At the moment I compile test it but don't 'make check' it >>> (ie I just use the tests/vm/openbsd setup). >>> >>> We could probably not unreasonably add 'xz' to the >>> build dependencies, >> >> I don't know how to do that, sorry. Are they tracked in some text file >> perhaps? (I.e. for a human reader?) > > Adding something to the build deps means: > * checking that it is definitely available in all the host OSes > that we support (or that there is a fallback path where > configure detects that it is not present). We document the > principles of which OSes/distros this is in qemu-doc.texi -- > I'm not sure if there's a wiki page or similar which gives > this in more concrete "version X of RHEL, version Y of SUSE" > etc terms > * ensuring that the images used for tests/vm (openbsd, netbsd, > freebsd) have it installed. I'm not sure exactly how this works > * checking that the various automated CI setups (travis, etc) > have it installed. I don't know exactly how to do this -- > ask the people listed in MAINTAINERS under "Build and test > automation" (who should also know about the tests/vm stuff). > They will also know if various dockerfiles in tests/docker > need to be updated. > * flagging it up in the pull request email so I know I > might need to update the various machines where I do merge builds > * updating the section of the Changelog on the wiki where we > document build requirements once the change has gone into master > >> Ultimately I don't know how to satisfy this requirement either -- let >> alone the OSX requirement, for which I can't even find a file under >> "tests/vm". > > OSX in this case is one of the machines I deal with by > hand for doing merges. (Also Travis tests OSX.) > > A question: does this absolutely have to be 'xz' and not bzip ?
I think bzip2 should work fine too: 1146804 edk2-aarch64-code.fd.xz | 1177603 edk2-aarch64-code.fd.bz2 1147852 edk2-arm-code.fd.xz | 1173662 edk2-arm-code.fd.bz2 10008 edk2-arm-vars.fd.xz | 263 edk2-arm-vars.fd.bz2 1674764 edk2-i386-code.fd.xz | 1688659 edk2-i386-code.fd.bz2 1870024 edk2-i386-secure-code.fd.xz | 1881979 edk2-i386-secure-code.fd.bz2 320 edk2-i386-vars.fd.xz | 190 edk2-i386-vars.fd.bz2 1655276 edk2-x86_64-code.fd.xz | 1669280 edk2-x86_64-code.fd.bz2 1889024 edk2-x86_64-secure-code.fd.xz | 1901210 edk2-x86_64-secure-code.fd.bz2 9394072 total | 9492846 total ~1% size increase in total. If we switch to bzip2, should I hurry for 4.0, or take my time in the next development cycle? Thanks, Laszlo