| Message ID | 20190316220937.18124-1-philmd@redhat.com |
|---|---|
| State | New |
| Headers | show |
On Sat, 16 Mar 2019 at 22:25, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > The following changes since commit 8b088d3f8ab5642020d28fa0c2a8d938bc5f3592: > > Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190315' into staging (2019-03-15 11:39:42 +0000) > > are available in the Git repository at: > > https://github.com/philmd/qemu.git tags/edk2_build-pull-request > > for you to fetch changes up to e487994c19ddca0e6340f72ddafc5b410877bbed: > > MAINTAINERS: add the "EDK2 Firmware" subsystem (2019-03-16 16:09:29 +0100) > > ---------------------------------------------------------------- > > Advance the roms/edk2 submodule to the "edk2-stable201903" release, > build and capture platform firmware binaries from that release. > > ---------------------------------------------------------------- Hi; this fails to build on OSX and OpenBSD: UNXZ pc-bios/edk2-aarch64-code.fd.xz /bin/sh: xz: command not found (NetBSD barfed for a different reason -- the tests/vm setup seems to occasionally simply fail the initial 600s timeout for being able to ssh into the VM for reasons that I've never been able to track down. So it might be OK or might also not have xz.) thanks -- PMM
On Sun, 17 Mar 2019 at 20:29, Peter Maydell <peter.maydell@linaro.org> wrote: > > On Sat, 16 Mar 2019 at 22:25, Philippe Mathieu-Daudé <philmd@redhat.com> wrote: > > > > The following changes since commit 8b088d3f8ab5642020d28fa0c2a8d938bc5f3592: > > > > Merge remote-tracking branch 'remotes/pmaydell/tags/pull-target-arm-20190315' into staging (2019-03-15 11:39:42 +0000) > > > > are available in the Git repository at: > > > > https://github.com/philmd/qemu.git tags/edk2_build-pull-request > > > > for you to fetch changes up to e487994c19ddca0e6340f72ddafc5b410877bbed: > > > > MAINTAINERS: add the "EDK2 Firmware" subsystem (2019-03-16 16:09:29 +0100) > > > > ---------------------------------------------------------------- > > > > Advance the roms/edk2 submodule to the "edk2-stable201903" release, > > build and capture platform firmware binaries from that release. > > > > ---------------------------------------------------------------- > > Hi; this fails to build on OSX and OpenBSD: > > UNXZ pc-bios/edk2-aarch64-code.fd.xz > /bin/sh: xz: command not found > > (NetBSD barfed for a different reason -- the tests/vm setup > seems to occasionally simply fail the initial 600s timeout > for being able to ssh into the VM for reasons that I've > never been able to track down. So it might be OK or might > also not have xz.) NetBSD was OK on the second try. thanks -- PMM
Hi Peter, Le dim. 17 mars 2019 23:02, Peter Maydell <peter.maydell@linaro.org> a écrit : > On Sun, 17 Mar 2019 at 20:29, Peter Maydell <peter.maydell@linaro.org> > wrote: > > > > On Sat, 16 Mar 2019 at 22:25, Philippe Mathieu-Daudé <philmd@redhat.com> > wrote: > > > > > > The following changes since commit > 8b088d3f8ab5642020d28fa0c2a8d938bc5f3592: > > > > > > Merge remote-tracking branch > 'remotes/pmaydell/tags/pull-target-arm-20190315' into staging (2019-03-15 > 11:39:42 +0000) > > > > > > are available in the Git repository at: > > > > > > https://github.com/philmd/qemu.git tags/edk2_build-pull-request > > > > > > for you to fetch changes up to > e487994c19ddca0e6340f72ddafc5b410877bbed: > > > > > > MAINTAINERS: add the "EDK2 Firmware" subsystem (2019-03-16 16:09:29 > +0100) > > > > > > ---------------------------------------------------------------- > > > > > > Advance the roms/edk2 submodule to the "edk2-stable201903" release, > > > build and capture platform firmware binaries from that release. > > > > > > ---------------------------------------------------------------- > > > > 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. 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. Thanks for carefully noticing that. So this series won't make it to the next release. > > > (NetBSD barfed for a different reason -- the tests/vm setup > > seems to occasionally simply fail the initial 600s timeout > > for being able to ssh into the VM for reasons that I've > > never been able to track down. So it might be OK or might > > also not have xz.) > > NetBSD was OK on the second try. > Thanks for keeping trying there, even when 2 other OS failed. Regards, Phil. > thanks > -- PMM > >
On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé <f4bug@amsat.org> wrote: > > Hi Peter, > > Le dim. 17 mars 2019 23:02, Peter Maydell <peter.maydell@linaro.org> a écrit : >> >> On Sun, 17 Mar 2019 at 20:29, Peter Maydell <peter.maydell@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, but we'd need to add it to the OpenBSD image in tests/vm. thanks -- PMM
Hi Peter, On 03/19/19 10:22, Peter Maydell wrote: > On Mon, 18 Mar 2019 at 21:21, Philippe Mathieu-Daudé <f4bug@amsat.org> > wrote: >> >> Hi Peter, >> >> Le dim. 17 mars 2019 23:02, Peter Maydell <peter.maydell@linaro.org> >> a écrit : >>> >>> On Sun, 17 Mar 2019 at 20:29, Peter Maydell >>> <peter.maydell@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?) > but we'd need to add it to the OpenBSD image in tests/vm. Phil vaguely directed me (without access to a real computer) to some patches he had sent previously, and I found: [Qemu-devel] [PATCH v2 11/18] tests/vm/openbsd: Install GNU sed from the ports msgid <20190129175403.18017-12-philmd@redhat.com> This patch proposed to add some "pkg_add" commands to "tests/vm/openbsd". However, the patch didn't get any feedback (specific feedback, that is; no message was sent directly in response). And Phil dropped it from the v3 posting: [Qemu-devel] [PATCH v3 0/8] OpenBSD: Block layer fixes (was 'Enable qtesting') msgid <20190205001835.25660-1-philmd@redhat.com> 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". So, I guess this PULL will indeed miss 4.0. I'll ask Phil to handle the "xz" dependencies (he apparently knows how to do that) and also to resubmit the PULL, once 4.0 is out and Phil regains access to a real computer. (BTW, thank you very much for the PULL, Phil.) Thanks Laszlo
On Wed, 20 Mar 2019 at 15:31, Laszlo Ersek <lersek@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é <f4bug@amsat.org> > > wrote: > >> > >> Hi Peter, > >> > >> Le dim. 17 mars 2019 23:02, Peter Maydell <peter.maydell@linaro.org> > >> a écrit : > >>> > >>> On Sun, 17 Mar 2019 at 20:29, Peter Maydell > >>> <peter.maydell@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 ? thanks -- PMM
(+Daniel and MST) On 03/20/19 16:58, Peter Maydell wrote: > On Wed, 20 Mar 2019 at 15:31, Laszlo Ersek <lersek@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é <f4bug@amsat.org> >>> wrote: >>>> >>>> Hi Peter, >>>> >>>> Le dim. 17 mars 2019 23:02, Peter Maydell <peter.maydell@linaro.org> >>>> a écrit : >>>>> >>>>> On Sun, 17 Mar 2019 at 20:29, Peter Maydell >>>>> <peter.maydell@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
On 03/20/19 19:59, Laszlo Ersek wrote: > (+Daniel and MST) > > On 03/20/19 16:58, Peter Maydell wrote: >> 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? An alternative to rebasing / reworking the series in-place (for xz-->bz2) and to missing the 4.0 bus consequently, would be to merge the PULL req as is, and for me to submit an incremental update, for the xz-->bz2 replacement. I think that would qualify as a bugfix, and be eligible for the hard freeze too. Thanks Laszlo
Le mer. 20 mars 2019 20:43, Laszlo Ersek <lersek@redhat.com> a écrit : > On 03/20/19 19:59, Laszlo Ersek wrote: > > (+Daniel and MST) > > > > On 03/20/19 16:58, Peter Maydell wrote: > > >> 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? > > An alternative to rebasing / reworking the series in-place (for > xz-->bz2) and to missing the 4.0 bus consequently, would be to merge the > PULL req as is, and for me to submit an incremental update, for the > xz-->bz2 replacement. I think that would qualify as a bugfix, and be > eligible for the hard freeze too. > A simple fix could be ./configure checks for xz and if not installed kindly ask for installation, or as a warning then if unable to install (user without root access) simply doesn't uncompress. > Thanks > Laszlo > >
Le mer. 20 mars 2019 21:05, Philippe Mathieu-Daudé <f4bug@amsat.org> a écrit : > Le mer. 20 mars 2019 20:43, Laszlo Ersek <lersek@redhat.com> a écrit : > >> On 03/20/19 19:59, Laszlo Ersek wrote: >> > (+Daniel and MST) >> > >> > On 03/20/19 16:58, Peter Maydell wrote: >> >> >> 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? >> >> An alternative to rebasing / reworking the series in-place (for >> xz-->bz2) and to missing the 4.0 bus consequently, would be to merge the >> PULL req as is, and for me to submit an incremental update, for the >> xz-->bz2 replacement. I think that would qualify as a bugfix, and be >> eligible for the hard freeze too. >> > > A simple fix could be ./configure checks for xz and if not installed > kindly ask for installation, or as a warning then if unable to install > (user without root access) simply doesn't uncompress. > ./configure detect no xz and select --disable-blobs? >> Thanks >> Laszlo >> >>
On Wed, 20 Mar 2019 at 19:42, Laszlo Ersek <lersek@redhat.com> wrote: > An alternative to rebasing / reworking the series in-place (for > xz-->bz2) and to missing the 4.0 bus consequently, would be to merge the > PULL req as is, and for me to submit an incremental update, for the > xz-->bz2 replacement. I think that would qualify as a bugfix, and be > eligible for the hard freeze too. No, I cannot merge this pullreq as is, because it would break the tests I do before merges. (I could fix my OSX install easily, but the tests/vm/ setups for the BSDs are not under my control.) thanks -- PMM