From: Ian Jackson <ian.jackson@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
Juergen Gross <jgross@suse.com>, Olaf Hering <olaf@aepfle.de>,
Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: Stable trees (4.6 and 4.7), building on stretch, osstest, redux
Date: Tue, 28 May 2019 20:59:24 +0100 [thread overview]
Message-ID: <23789.37660.726217.578999@mariner.uk.xensource.com> (raw)
In-Reply-To: <23751.6297.231034.162861@mariner.uk.xensource.com>
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.
I'm sort of tempted to have osstest arbitrarily run
git cherry-pick 38ab99b26bf4298a33105ec66f3f6a3f7e05a326
at some appropriate point...
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 ?
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
WARNING: multiple messages have this Message-ID (diff)
From: Ian Jackson <ian.jackson@citrix.com>
To: Jan Beulich <JBeulich@suse.com>
Cc: Anthony PERARD <anthony.perard@citrix.com>,
Juergen Gross <jgross@suse.com>, Olaf Hering <olaf@aepfle.de>,
Wei Liu <wl@xen.org>,
xen-devel@lists.xenproject.org
Subject: [Xen-devel] Stable trees (4.6 and 4.7), building on stretch, osstest, redux
Date: Tue, 28 May 2019 20:59:24 +0100 [thread overview]
Message-ID: <23789.37660.726217.578999@mariner.uk.xensource.com> (raw)
Message-ID: <20190528195924.FKUVEgodi4Xx6YGv_A60zfxikVt9yhEXkgZekj3iIgQ@z> (raw)
In-Reply-To: <23751.6297.231034.162861@mariner.uk.xensource.com>
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.
I'm sort of tempted to have osstest arbitrarily run
git cherry-pick 38ab99b26bf4298a33105ec66f3f6a3f7e05a326
at some appropriate point...
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 ?
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.
Ian.
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xenproject.org
https://lists.xenproject.org/mailman/listinfo/xen-devel
next prev parent reply other threads:[~2019-05-28 20:00 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-04-29 15:26 [PATCH STABLE] tools/firmware: update OVMF Makefile, when necessary Ian Jackson
2019-04-29 15:26 ` [Xen-devel] " Ian Jackson
2019-04-29 15:30 ` Ian Jackson
2019-04-29 15:30 ` [Xen-devel] " Ian Jackson
2019-05-01 10:41 ` Ian Jackson
2019-05-01 10:41 ` [Xen-devel] " Ian Jackson
2019-05-07 11:09 ` [PATCH STABLE] tools/firmware: update OVMF Makefile, when necessaryf Ian Jackson
2019-05-07 11:09 ` [Xen-devel] " Ian Jackson
2019-05-28 19:59 ` Ian Jackson [this message]
2019-05-28 19:59 ` [Xen-devel] Stable trees (4.6 and 4.7), building on stretch, osstest, redux Ian Jackson
2019-05-29 6:36 ` Olaf Hering
2019-05-29 6:36 ` [Xen-devel] " Olaf Hering
2019-05-29 7:49 ` Jan Beulich
2019-05-29 7:49 ` [Xen-devel] " Jan Beulich
2019-05-29 10:35 ` Ian Jackson
2019-05-29 10:35 ` [Xen-devel] " Ian Jackson
2019-05-29 11:38 ` Ian Jackson
2019-05-29 11:38 ` [Xen-devel] " Ian Jackson
2019-05-30 12:57 ` Ian Jackson
2019-05-30 12:57 ` [Xen-devel] " Ian Jackson
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=23789.37660.726217.578999@mariner.uk.xensource.com \
--to=ian.jackson@citrix.com \
--cc=JBeulich@suse.com \
--cc=anthony.perard@citrix.com \
--cc=jgross@suse.com \
--cc=olaf@aepfle.de \
--cc=wl@xen.org \
--cc=xen-devel@lists.xenproject.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.