[Xen-devel] Bisector breakage (Re: [PATCH] Config.mk: Fix (and, effectively, update) QEMU_TAG)

[Ian Campbell <ian.campbell@xxxxxxxxxx>]

On Tue, 2015-04-21 at 11:33 +0100, Ian Jackson wrote:
> In 952944f7 "QEMU_TAG update" my tag update script mangled the
> machinery which sets QEMU_TRADITIONAL_REVISION, by replacing the first
> assignment to QEMU_TRADITIONAL_REVISION it found rather than the one
> which ought to have been replaced.
> 
> The result was that:
>  * From that commit on, QEMU_TAG was no longer honoured although
>    QEMU_TRADITIONAL_REVISION still was
>  * That particular update to QEMU_TRADITIONAL_REVISION's default
>    value was effective
>  * The next attempt to update QEMU_TRADITIONAL_REVISION, in
>    1fc3aeb3 "libxl: use new QEMU xenstore protocol" was totally
>    ineffective.

A knock on effect seems to be that the bisector is looping constantly
trying to build some given set of things and failing with:
        flight 53895 mixed revisions for qemu: 
3b45fcf0c163b9cff4d8115f7b75b42918a9b1b5 and 
ab42b4408cb4fc4f869d73218e3d2034e6f5e8ac
in bisection-report and
        version mismatch! revision_qemu 
requested=3b45fcf0c163b9cff4d8115f7b75b42918a9b1b5 
built=ab42b4408cb4fc4f869d73218e3d2034e6f5e8ac
in the test log itself. It doesn't seem to take this as a sign to give
up. AFAICT it isn't subject to the recent changes to limit the number of
attempts because it fails in a way which doesn't get considered as such
when the bisector next looks (the first message above is essentially
discounting it)

For my adhoc bisect in Cambridge I bodged around this with the below,
which WFM on the range I was testing.

A real fix might want to set both in ts-xen-build to cope with all
branches/ages of repo. I also didn't change ap-qemu-revision because I
wasn't sure what was needed there.

Or we could just ignore this until the problematic revisions are
historical. But best might be for the bisector to never try again under
such circumstances, it's unlikely to work the next time.

I haven't stopped any bisections since it is just the build jobs and
those are reasonably cheap in terms of resources.

I have forced pushed some flights which only failed on the freebsd
migration thing, which I think will remove the impetus to bisect in many
cases.

Ian.


commit 1ebae0dc5384089d00b01400a7a85dc48e4c2b5f
Author: Ian Campbell <ijc@xxxxxxxxxxxxxx>
Date:   Fri May 8 16:45:25 2015 +0100

    Workaround xen.git:5d4c0952f8da103e99d9b8c1fc6814dabd397df6 issue
    
        In 952944f7 "QEMU_TAG update" my tag update script mangled the
        machinery which sets QEMU_TRADITIONAL_REVISION, by replacing the first
        assignment to QEMU_TRADITIONAL_REVISION it found rather than the one
        which ought to have been replaced.
    
        The result was that:
         * From that commit on, QEMU_TAG was no longer honoured although
           QEMU_TRADITIONAL_REVISION still was

diff --git a/adhoc-revtuple-generator b/adhoc-revtuple-generator
index 2b04c11..d2c2f64 100755
--- a/adhoc-revtuple-generator
+++ b/adhoc-revtuple-generator
@@ -305,7 +305,7 @@ sub xu_withtag_generator ($) {
                        hg cat -r $nodeonly Config.mk |"
                         or die $!;
            while (<CMK>) {
-               next unless m/^QEMU_TAG\s*[:?]?\=\s*(\S+)\s*$/;
+               next unless 
m/^(?:QEMU_TAG|QEMU_TRADITIONAL_REVISION)\s*[:?]?\=\s*(\S+)\s*$/;
                $targetqemu= $1;
            }
            if ($targetqemu !~ m/^[0-9a-f]+$/) {
diff --git a/ts-xen-build b/ts-xen-build
index e757f68..e0e97e0 100755
--- a/ts-xen-build
+++ b/ts-xen-build
@@ -59,7 +59,7 @@ END
        echo >>.config XSM_ENABLE='${build_xsm}'
 END
                (nonempty($r{revision_qemu}) ? <<END : '').
-       echo >>.config QEMU_TAG='$r{revision_qemu}'
+       echo >>.config QEMU_TRADITIONAL_REVISION='$r{revision_qemu}'
 END
                (nonempty($r{tree_qemuu}) ? <<END : '').
        echo >>.config QEMU_UPSTREAM_URL='$r{tree_qemuu}'



_______________________________________________
Xen-devel mailing list
Xen-devel@xxxxxxxxxxxxx
http://lists.xen.org/xen-devel