Re: [Xen-devel] Stable trees (4.6 and 4.7), building on stretch, osstest, redux

[Ian Jackson <ian.jackson@xxxxxxxxxx>]

Jan Beulich writes ("Re: Stable trees (4.6 and 4.7), building on stretch, 
osstest, redux"):
> On 28.05.19 at 21:59, <ian.jackson@xxxxxxxxxx> wrote:
> > 1. That old ipxe is just too badly broken.  I spent a long while
> > trying to backport compiler fixes but it is totally ridiculous.  IMO
> > our only sensible option is to update at least osstest's buildsx to a
> > much newer ipxe.
> > 
> > This could be done by cherry picking
> >      38ab99b26bf4298a33105ec66f3f6a3f7e05a326
> >        ipxe: update to newer commit
> > (which is from xen 4.8 ish) onto our 4.7 and 4.6 branches.
> > 
> > If this is felt too intrusive, then I could somehow make it
> > conditional and have osstest use it.  This is not entirely trivial
> > because we have an ad hoc patch application thing.
> 
> Since the new ipxe should have been proven stable enough in
> the newer trees, I think cherry-picking said commit should be
> fine.

That wasn't what I was expecting you to say :-).  I will go with your
opinion since it is certainly less work.

> > 2. hvmloader fails to build, I think because we need
> >     7825ae12df1f6d48c4d009cbbdf5a55aff27291b
> >       errno: introduce EISDIR/EROFS/ENOTEMPTY to the ABI
> >     03720ea541382a3ca80eaaec2aa11932b03aacaf
> >       errno: declare aliases using XEN_ERRNO()
> >     67790205df26e7c3dfeef8b8e64194ebc279220d
> >       public/errno: Reduce complexity of inclusion
> >     305e957ffee94fc06c4ba53ef5562f1b8c1c6b02
> >       hvmloader: use xen/errno.h rather than the host systems errno.h
> > 
> > Is backporting that lot OK ?
> 
> I think so, yes, albeit I'm puzzled how they would end up being
> needed.

We need the last of these because in stretch Linux the host system's
errno header files were reorganised in a way that was incompatible
with the wrong-headed use of host headers and (only some) host header
directories.

The others are neded because of textual or semantic conflicts.

> > There are also some simple backports we need:
> >    c2a17869d5dcd845d646bf4db122cad73596a2be
> >      libfsimage: replace deprecated readdir_r() with readdir()
> >    b9daff9d811285f1e40669bc621c2241793f7a95
> >      libxl: replace deprecated readdir_r() with readdir()
> >    668e4edf92fcf7cb929eed221059a3eeb02722c3
> >      stubdom: make GMP aware that it's being cross-compiled
> >    2f9eb73c2e2d7fdda8e2586c20f7dbd856002eba
> >       stubdom: fix stubdom-vtpm build
> > 
> > 
> > With all of the above, 4.6 builds again.  I guess 4.7 will too.
> > 
> > Fixing that will also probably enable the 4.8 push gate to pass.  It
> > is currently blocked because it wants to test 4.7->4.8 migration and
> > can't build 4.7.
> 
> And similarly in turn for 4.9's need to have a building 4.8 baseline,
> afaict.

Yes.  We have fixed the 4.8 build but it hasn't passed its push gate
so 4.9 is using the "tested" branch...

OK, I will go ahead with all of the above for 4.6 and 4.7.  Thanks.

Thanks also to Olaf.  Your experience with the ipxe problems was
similar to mine.  I think just upgrading is the best approach.

Ian.

_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxxx
https://lists.xenproject.org/mailman/listinfo/xen-devel