On Tue, Apr 09, 2024 at 04:13:34PM +0100, Peter Maydell wrote: > On Tue, 9 Apr 2024 at 15:19, Peter Maydell <peter.mayd...@linaro.org> wrote: > > > > On Tue, 9 Apr 2024 at 15:14, Gerd Hoffmann <kra...@redhat.com> wrote: > > > > > > Hi, > > > > > > > > + --version-override "$(EDK2_STABLE)-for-qemu" \ > > > > > + --release-date "$(EDK2_DATE)" \ > > > > > > > > Hi -- I've just noticed that we never made this change to > > > > automate the date/version for EDK2 ROMs, but we also never > > > > updated the version by hand. So at the moment we ship an > > > > EDK2 blob that wrongly claims to be an older version. > > > > See this bug report by a user: > > > > > > > > https://gitlab.com/qemu-project/qemu/-/issues/2233 > > > > > > > > Is it possible to fix this for 9.0? > > > > > > I've posted v2 (series) a while back, no feedback so far. > > > > > > https://lore.kernel.org/qemu-devel/20240327102448.61877-1-kra...@redhat.com/ > > > > > > If there are no objections I can do a PR for these three patches plus an > > > edk2 binary rebuild (which shouldn't change anything but the version > > > string). > > > > I guess that's safe enough, though the very-conservative > > choice would be to take just the EDK2 rebuild for 9.0. > > Would you be able to get a pullreq in for this before rc3? > (I can delay rc3 by a day or so if necessary; I'd rather > not have to do an rc4 if we can avoid it...)
https://lore.kernel.org/qemu-devel/20240409162942.454419-1-kra...@redhat.com/T/ take care, Gerd
