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

[Jan Beulich <jbeulich@xxxxxxxx>]

On 03.09.2020 18:17, 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.

Afaict this would still not work, due to 8d990807ec2c ("stubdom/grub:
update init_netfront() call for mini-os"). The dependencies between
the two trees aren't helpful at all in a case like this one.

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

I did suggest this in a reply to an earlier test failure report, but
as per above I don't see how this would work either in a case like
this one.

Jan