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

[Ian Campbell <Ian.Campbell@xxxxxxxxxx>]

On Mon, 2011-11-28 at 11:58 +0000, Ian Jackson wrote:
> # HG changeset patch
> # User Ian Jackson <Ian.Jackson@xxxxxxxxxxxxx>
> # Date 1322481443 0
> # Node ID a9c67c2daf4b0181ef2581471ea920eecb495616
> # Parent  95d4e2e0bed374602b5a78ee004b057ad8715d65
> tools: Revert to our built-in aio
> 
> These two changesets:
>    24184:4ecd3615e726  tools: use system installed libaio by default.
>    24186:7aa5838499d1  tools: use system libaio for blktap1 as well.
> cause HVM guest installs (both Windows and Redhat) to fail on Debian
> squeeze with xl.  So change the default for now.
> 
> Committed-by: Ian Jackson <ian.jackson@xxxxxxxxxxxxx>

AIUI the tester is now installs libaio1 so we can revert this one?

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.

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.

Ian.

> 
> diff -r 95d4e2e0bed3 -r a9c67c2daf4b Config.mk
> --- a/Config.mk       Fri Nov 25 20:32:05 2011 +0000
> +++ b/Config.mk       Mon Nov 28 11:57:23 2011 +0000
> @@ -232,7 +232,7 @@ PYTHON_TOOLS       ?= y
>  OCAML_TOOLS        ?= y
>  CONFIG_MINITERM    ?= n
>  CONFIG_LOMOUNT     ?= n
> -CONFIG_SYSTEM_LIBAIO ?= y
> +CONFIG_SYSTEM_LIBAIO ?= n
>  
>  ifeq ($(OCAML_TOOLS),y)
>  OCAML_TOOLS := $(shell ocamlopt -v > /dev/null 2>&1 && echo "y" || echo "n")
> 
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@xxxxxxxxxxxxxxxxxxx
> http://lists.xensource.com/xen-devel



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