Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

osstest service owner writes ("[xen-4.10-testing test] 151033: regressions - 
trouble: blocked/fail/pass/starved"):
> flight 151033 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/151033/
> 
> Regressions :-(
> 
> Tests which did not succeed and are blocking,
> including tests which could not be run:
>  build-arm64-libvirt           6 libvirt-build            fail REGR. vs. 
> 150039
>  build-armhf-libvirt           6 libvirt-build            fail REGR. vs. 
> 150039
>  build-i386-libvirt            6 libvirt-build            fail REGR. vs. 
> 150039
>  build-amd64-libvirt           6 libvirt-build            fail REGR. vs. 
> 150039

  ../../../gnulib/lib/fseeko.c: In function 'rpl_fseeko':
  ../../../gnulib/lib/fseeko.c:110:4: error: #error "Please port gnulib 
fseeko.c to your platform! Look at the code in fseeko.c, then report this to 
bug-gnulib."
     #error "Please port gnulib fseeko.c to your platform! Look at the code in 
fseeko.c, then report this to bug-gnulib."
      ^~~~~
  make[3]: *** [Makefile:2473: fseeko.lo] Error 1

http://logs.test-lab.xenproject.org/osstest/logs/151033/build-amd64-libvirt/6.ts-libvirt-build.log

In principle maybe we could fix this by generating a private libvirt
branch with the build fixes ?  Or maybe we should simply try plucking
a new version of libvirt ?  We could update the pinned version in Xen
4.10 to the one from 4.11 ?  We might have to do the same for 4.9
then.

>  test-amd64-amd64-xl-qcow2    10 debian-di-install        fail REGR. vs. 
> 150039
>  test-amd64-amd64-pygrub      10 debian-di-install        fail REGR. vs. 
> 150039
>  test-amd64-i386-xl-raw       10 debian-di-install        fail REGR. vs. 
> 150039

  domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ... 
  domainbuilder: detail: XZ: Saw data stream end
  domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 
0x1a7779c
  domainbuilder: detail: loader probe OK
  ...
  domainbuilder: detail: xc_dom_alloc_segment:   module0      : 
0xffffffff82c00000 -> 0xffffffff82c02000  (pfn 0x2c00 + 0x2 pages)
  xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed 
(rc=-5): Internal error
  libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No 
such file or directory

http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log

????  Anyone have any ideas ?  I would have guessed that this was an
incompatibility between pygrub and the boot config made by the new
pygrub but
   git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
suggests not.


As an alternative to trying to fix these, I could arrange for Xen 4.10
and earlier to use stretch rather than buster.  4.10 is end of
security support in December and probably stretch will not break too
badly for us before then.

Ian.