On Wed, 2016-01-06 at 16:28 +0000, Ian Jackson wrote:
> Jan Beulich writes ("Re: [Xen-devel] OVMF related osstest failures on
> multiple branches"):
> > On 06.01.16 at 16:28, <ian.campb...@citrix.com> wrote:
> > > Running xen-4.6-testing with ovmf.git 52a99493cce8 instead of
> > > cb9a7ebabcd6
> > > does seem to have worked (i.e. the flight hasn't actually finished
> > > yet but
> > > it has passed the debian-hvm-install step).
>
> Great. So AFAICT we would conclude that Debian jessie does not work
> with the older OVMF.
Strictly speaking Jessie's compiler cannot build a working OVMF binary.
Jessie as a guest appears to work just fine.
> > > If we want to follow [1] then the plan of attack is:
> ...
> > > * I need to identify the patch(es) which actually fix this issue and
> > > cherrypick it into new stable branches in ovmf.git for 4.4, 4.5
> > > and 4.6.
> > > * Ian J to update OVMF_UPSTREAM_REVISION in the corresponding
> > > xen.git
> > > stable branches to point to all those commits (either branch name
> > > or
> > > SHA, not sure).
> > > * The release checklist needs updating to include tagging this new
> > > tree
> > > and updating OVMF_UPSTREAM_REVISION to point to the tag instead of
> > > the
> > > commit (I think this is strictly speaking option, but we should do
> > > it).
> > > * We might want to consider retroactively tagging the versions of
> > > ovmf
> > > used in 4.4.[01234], 4.5.[012] and 4.6.0 in ovmf.git, which would
> > > be
> > > helpful for people using gitk etc to look at the history I suppose
> > >
> > > That assumes a seabios/qemut style model to updating ovmf, i.e.
> > > ungated
> > > manual Config.mk update, if we were to switch to a gate it would be
> > > different but regardless of the merits of doing things that way it
> > > does't
> > > seem like a thing to do on a stable branch.
>
> This is quite a lot of work. Doing this work would perhaps make sense
> if we had a reasonable idea what was going on in ovmf.git, which
> changes to cherry pick to stable branches, etc. But AFAICT we don't.
FWIW adding just 39ef30bb47b6 to cb9a7ebabcd6 seems to have worked, but
finding that was based on a search for "GCC" in the commit log and a wild
hunch ;-).
> So I would be tempted to just update the Config.mk reference in stable
> trees.
That's my inclination too.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
