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

[Costin Lupu <costin.lupu@xxxxxxxxx>]

On 9/3/20 7:17 PM, Ian Jackson wrote:
> 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.

Sorry for breaking this, guys. I've just sent the fix for mini-os on the
mailing list.

Cheers,
Costin