Re: [Xen-devel] [xen-unstable test] 10135: regressions - FAIL

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Wed, 2011-11-30 at 14:35 +0000, Ian Jackson wrote:
> ~Ian Campbell writes ("Re: [Xen-devel] [xen-unstable test] 10135: regressions 
> - FAIL"):
> >> According to
> > http://www.chiark.greenend.org.uk/~xensrcts/results/bisect.xen-unstable.test-amd64-i386-rhel6hvm-intel.redhat-install.html
> > changeset 24227:1027e7d13d02 was tested and failed. That would have
> > included
> > 24206:05dd94652d8d tools/check: Add files missing from 24205:5c88358164cc
> > 24205:5c88358164cc tools: check for libaio unless user has configured 
> > CONFIG_SYSTEM_LIBAIO=n
> > 
> > Now I don't think the bisector would ever have given us reason to look
> > at this commits but if they had gone it at the same time as the new
> > dependency this could have saved a lot of trouble tracking down the
> > problem.
> 
> "gone in" I guess.  I spent a while staring that trying to make sense
> of it assuming it was meant to say "done it".

Yes, sorry. "... if they had gone in at the ... "

> But, no, because the check would have passed because it's run on the
> build host and the build host has the runtime lib installed because
> it's a dependency of the dev lib.
> 
> > In
> > http://www.chiark.greenend.org.uk/~xensrcts/logs/10032/build-i386/4.ts-xen-build.log
> >  (one of the runs finger by the bisector which included the above commits) 
> > I can see the CHECK-BUILD runes getting run but not the CHECK-INSTALL ones.
> > 
> > The call to ./chk install in the install target seems to have been
> > deliberately removed in 16906:f4ee7e5793cf for reasons I don't quite
> > understand (I suspect because of the install-into-a-staging-dir property
> > of install). Since you install on a different host to the build host
> > it's possible that the tester might need to jump through some extra
> > hoops to cause this stuff to run there anyway. Perhaps the tester could
> > copy tools/check over and execute "./chk install" or "make
> > check-install" itself? The top-level install.sh does something like
> > this, but I'm not sure you are (or should be) using it.
> 
> I could have the tester run ./chk install on the install host and
> see.  But I don't think we promise that this will work.

We could decide to promise it going forward if it is useful.

> Running ./chk install on the build host during "make install" is a
> good idea but wouldn't have found this problem more quickly.

Right, if they are running on the same host I don't think ./chk install
will find much which is not found by ./chk build in practice.

Ian.



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxxxxxxxx
http://lists.xensource.com/xen-devel