Re: [xen-unstable test] 153602: regressions - FAIL

[Ian Jackson <iwj@xxxxxxxxxxxxxx>]

Jan Beulich writes ("Re: [xen-unstable test] 153602: regressions - FAIL"):
> On 03.09.2020 12:24, osstest service owner wrote:
> > flight 153602 xen-unstable real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/153602/
> > 
> > Regressions :-(
> > 
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> >  test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm 10 debian-hvm-install 
> > fail REGR. vs. 152877
> >  test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm 10 
> > debian-hvm-install fail REGR. vs. 152877
> 
> While at least the hypervisor logs don't provide clear indication
> (and I don't know where else to look among the files osstest
> provides) I can't help thinking that stubdom apparently
> crashing is still fallout from the mini-os changes (and no-one
> really looks to care). In particular I think that this

I haven't looked at this in detail but I notice that I am having
build failures.

Prior to e013e8514389 "config: use mini-os master for unstable", the
version of mini-os used for builds was controlled by xen.git's
Config.mk.

Since then it has been mini-os master.  NB there is no push gate for
mini-os.  IIRC we discussed this at the time and it was thought that
breakage due to mini-os would be unlikely.

To unblock development in xen.git I suggest reverting the minios part
of 165f3afbfc3d "Config.mk: Unnail versions (for unstable branch)",
choosing some known-working version of minios to put in Config.mk.

Perhaps there should indeed be a minios pushgate.  Then osstest would
use the tested version.

Ian.