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

["Jan Beulich" <JBeulich@xxxxxxxx>]

>>> On 28.05.19 at 21:59, <ian.jackson@xxxxxxxxxx> wrote:
> Ian Jackson writes ("[PATCH STABLE] tools/firmware: update OVMF Makefile, 
> when necessary"):
>> Now done, including for staging-4.6.  4.6 is out of security support,
>> but osstest wants to be able to build 4.6 so that it can test
>> migration from 4.6 to 4.7, and 4.7 *is* still (just about) in security
>> support.
>> 
>> I expect the 4.6 push gate to fail and to have to force push it.
>> 
>> It is also possible that we will experience other build fallout.
> 
> I am still struggling with this.  4.7 and 4.6 still do not build.
> Right now there are two problems that need thought:
> 
> 
> 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.

> 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.

> 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.

Jan



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