| Message ID | 1395229675-13658-3-git-send-email-ian.campbell@citrix.com |
|---|---|
| State | New |
| Headers | show |
Ian Campbell writes ("[PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"):
> instead of using the kernel build integration in xen.git, which is going away.
...
> Remove the now unused xen and qemu(u) tree/revision stuff from the jobs'
> runvars. Add the appropriate kconfighow and kimagefile runvars and implement
> an appropriate kconfighow handler to use the create_config.sh present in this
> tree (the xen.git intergration called the same script)
This is the right way to do what you set out to do, but:
> I guess these are build tests only, but they sem to only be used in the
> osstest flights. Not sure if that is deliberate.
They're in the xen-unstable flights too. If we're disentangling this
from xen.git, I think it would arguably be better to drop this
entirely. I don't think we want to make a separate push gate for
2.6.18 at this stage.
Ian.
On Wed, 2014-03-19 at 12:12 +0000, Ian Jackson wrote: > Ian Campbell writes ("[PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"): > > instead of using the kernel build integration in xen.git, which is going away. > ... > > Remove the now unused xen and qemu(u) tree/revision stuff from the jobs' > > runvars. Add the appropriate kconfighow and kimagefile runvars and implement > > an appropriate kconfighow handler to use the create_config.sh present in this > > tree (the xen.git intergration called the same script) > > This is the right way to do what you set out to do, but: > > > I guess these are build tests only, but they sem to only be used in the > > osstest flights. Not sure if that is deliberate. > > They're in the xen-unstable flights too. So they are. > If we're disentangling this > from xen.git, I think it would arguably be better to drop this > entirely. I don't think we want to make a separate push gate for > 2.6.18 at this stage. I don't think they are in affect gated today, are they? xen.git doesn't reference a changeset or tag, it just grabs hg-master. Also, they are listed in allow.all so they don't block anyway -- I suppose they are just useful for status. I expect Jan is the only person who really cares about these trees, lets see what he thinks... Ian.
Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"):
> On Wed, 2014-03-19 at 12:12 +0000, Ian Jackson wrote:
> > If we're disentangling this
> > from xen.git, I think it would arguably be better to drop this
> > entirely. I don't think we want to make a separate push gate for
> > 2.6.18 at this stage.
>
> I don't think they are in affect gated today, are they? xen.git doesn't
> reference a changeset or tag, it just grabs hg-master.
Indeed.
> Also, they are listed in allow.all so they don't block anyway -- I
> suppose they are just useful for status.
They were put in allow.all because of that hg clone problem. That
seems to be fixed now so we could remove them.
Ian.
>>> On 19.03.14 at 13:26, Ian Campbell <Ian.Campbell@citrix.com> wrote: > On Wed, 2014-03-19 at 12:12 +0000, Ian Jackson wrote: >> If we're disentangling this >> from xen.git, I think it would arguably be better to drop this >> entirely. I don't think we want to make a separate push gate for >> 2.6.18 at this stage. > > I don't think they are in affect gated today, are they? xen.git doesn't > reference a changeset or tag, it just grabs hg-master. Correct. There's no staging tree around for this anymore. > Also, they are listed in allow.all so they don't block anyway -- I > suppose they are just useful for status. That was done not that long ago because of infrastructure issues keeping pushes from happening. If possible I'd like these to get removed from the white list again. Jan
On Wed, 2014-03-19 at 13:28 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"): > > On Wed, 2014-03-19 at 12:12 +0000, Ian Jackson wrote: > > > If we're disentangling this > > > from xen.git, I think it would arguably be better to drop this > > > entirely. I don't think we want to make a separate push gate for > > > 2.6.18 at this stage. > > > > I don't think they are in affect gated today, are they? xen.git doesn't > > reference a changeset or tag, it just grabs hg-master. > > Indeed. So does this mean we can keep these tests, as Jan would like, without a complete push gate setup? > > Also, they are listed in allow.all so they don't block anyway -- I > > suppose they are just useful for status. > > They were put in allow.all because of that hg clone problem. That > seems to be fixed now so we could remove them. OK. > > Ian.
Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"):
> On Wed, 2014-03-19 at 13:28 +0000, Ian Jackson wrote:
> > Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"):
> > > I don't think they are in affect gated today, are they? xen.git doesn't
> > > reference a changeset or tag, it just grabs hg-master.
> >
> > Indeed.
>
> So does this mean we can keep these tests, as Jan would like, without a
> complete push gate setup?
If the 2.6.18 build starts to fail, xen-unstable pushes will be broken
until they are fixed, as before. Previously (before your recent
proposals) such a build failure might be due to changes in xen.git so
that was slightly justifiable. But in practice this is quite rare.
I guess this situation, while anomalous, is tolerable. If you agree
then I will un-allow the failures.
Ian.
On Wed, 2014-03-19 at 13:46 +0000, Ian Jackson wrote: > Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"): > > On Wed, 2014-03-19 at 13:28 +0000, Ian Jackson wrote: > > > Ian Campbell writes ("Re: [PATCH OSSTEST 3/4] Use ts-kernel-build for build-*-oldkern"): > > > > I don't think they are in affect gated today, are they? xen.git doesn't > > > > reference a changeset or tag, it just grabs hg-master. > > > > > > Indeed. > > > > So does this mean we can keep these tests, as Jan would like, without a > > complete push gate setup? > > If the 2.6.18 build starts to fail, xen-unstable pushes will be broken > until they are fixed, as before. Previously (before your recent > proposals) such a build failure might be due to changes in xen.git so > that was slightly justifiable. But in practice this is quite rare. > > I guess this situation, while anomalous, is tolerable. If you agree > then I will un-allow the failures. OK.
diff --git a/mfi-common b/mfi-common index df7f8b0..2fff802 100644 --- a/mfi-common +++ b/mfi-common @@ -167,18 +167,12 @@ create_build_jobs () { if [ "x$REVISION_LINUX_OLD" != xdisable ]; then - ./cs-job-create $flight build-$arch-oldkern build \ - arch=$arch \ - tree_qemu=$TREE_QEMU \ - tree_qemuu=$TREE_QEMU_UPSTREAM \ - tree_xen=$TREE_XEN \ + ./cs-job-create $flight build-$arch-oldkern build-kern \ + arch=$arch kconfighow=create-config-sh \ + kimagefile=vmlinux \ $RUNVARS $BUILD_RUNVARS $BUILD_LINUX_OLD_RUNVARS \ $arch_runvars $suite_runvars \ host_hostflags=$build_hostflags \ - xen_kernels=linux-2.6-xen \ - revision_xen=$REVISION_XEN \ - revision_qemu=$REVISION_QEMU \ - revision_qemuu=$REVISION_QEMU_UPSTREAM \ tree_linux=http://xenbits.xen.org/linux-2.6.18-xen.hg \ revision_linux=$REVISION_LINUX_OLD diff --git a/ts-kernel-build b/ts-kernel-build index f80d857..cfb9f5c 100755 --- a/ts-kernel-build +++ b/ts-kernel-build @@ -263,6 +263,22 @@ END # /; } +sub config_create_config_sh () { + die "only x86" unless $r{arch} =~ m/^amd64|i386$/; + + my $xta = $r{arch} eq "amd64" ? "x86_64" : "x86_32"; + + target_cmd_build($ho, 1000, $builddir, <<END); + cd linux + sh buildconfigs/create_config.sh .config "-xen" $xta + if [ x$xta = xx86_32 ] ; then + sed -i.bak -e 's!^CONFIG_HIGHMEM4G=y\$!\# CONFIG_HIGHMEM4G is not set!;s!^\# CONFIG_HIGHMEM64G is not set\$!CONFIG_HIGHMEM64G=y!' .config + fi + yes '' | make oldconfig +END + # /; +} + sub config () { my $confighow= $r{kconfighow}; $confighow =~ s/\W/_/g;
instead of using the kernel build integration in xen.git, which is going away. There is no difference to the .config produced. No test jobs seem to rely on these kernels so I have not worried about making the contents of dist be identical (specifically the filenames under /boot have lost their -xen suffix) Remove the now unused xen and qemu(u) tree/revision stuff from the jobs' runvars. Add the appropriate kconfighow and kimagefile runvars and implement an appropriate kconfighow handler to use the create_config.sh present in this tree (the xen.git intergration called the same script) Signed-off-by: Ian Campbell <ian.campbell@citrix.com> --- I guess these are build tests only, but they sem to only be used in the osstest flights. Not sure if that is deliberate. --- mfi-common | 12 +++--------- ts-kernel-build | 16 ++++++++++++++++ 2 files changed, 19 insertions(+), 9 deletions(-)