* [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved
@ 2020-06-12 8:12 osstest service owner
2020-06-12 16:17 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Ian Jackson
0 siblings, 1 reply; 12+ messages in thread
From: osstest service owner @ 2020-06-12 8:12 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 151033 xen-4.10-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/151033/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039
build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039
test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039
test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039
test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039
build-amd64-prev 6 xen-build fail REGR. vs. 150039
build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039
build-i386-prev 6 xen-build fail REGR. vs. 150039
build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039
Tests which did not succeed, but are not blocking:
test-amd64-amd64-migrupgrade 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-libvirt-pair 1 build-check(1) blocked n/a
test-amd64-i386-migrupgrade 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt 1 build-check(1) blocked n/a
test-armhf-armhf-libvirt-raw 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-amd64-libvirt-vhd 1 build-check(1) blocked n/a
test-arm64-arm64-libvirt-xsm 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemut-ws16-amd64 17 guest-stop fail like 150039
test-amd64-amd64-qemuu-nested-amd 17 debian-hvm-install/l1/l2 fail like 150039
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict 10 debian-hvm-install fail never pass
test-arm64-arm64-xl-seattle 13 migrate-support-check fail never pass
test-arm64-arm64-xl-seattle 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-xsm 13 migrate-support-check fail never pass
test-arm64-arm64-xl-xsm 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit1 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit1 14 saverestore-support-check fail never pass
test-arm64-arm64-xl-credit2 13 migrate-support-check fail never pass
test-arm64-arm64-xl-credit2 14 saverestore-support-check fail never pass
test-arm64-arm64-xl 13 migrate-support-check fail never pass
test-arm64-arm64-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-multivcpu 13 migrate-support-check fail never pass
test-armhf-armhf-xl-multivcpu 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit1 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit1 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-arndale 13 migrate-support-check fail never pass
test-armhf-armhf-xl-arndale 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-rtds 13 migrate-support-check fail never pass
test-armhf-armhf-xl-rtds 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-cubietruck 13 migrate-support-check fail never pass
test-armhf-armhf-xl-cubietruck 14 saverestore-support-check fail never pass
test-armhf-armhf-xl 13 migrate-support-check fail never pass
test-armhf-armhf-xl 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-credit2 13 migrate-support-check fail never pass
test-armhf-armhf-xl-credit2 14 saverestore-support-check fail never pass
test-armhf-armhf-xl-vhd 12 migrate-support-check fail never pass
test-armhf-armhf-xl-vhd 13 saverestore-support-check fail never pass
test-amd64-amd64-xl-qemut-ws16-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemut-win7-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-win7-amd64 17 guest-stop fail never pass
test-amd64-i386-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-amd64-amd64-xl-qemuu-ws16-amd64 17 guest-stop fail never pass
test-arm64-arm64-xl-thunderx 2 hosts-allocate starved n/a
version targeted for testing:
xen 934d6e1a77947662504cf4d5e36c9520e03aa731
baseline version:
xen b922c4431df33ed5b724e53c3f3348e470ddd349
Last test of basis 150039 2020-05-05 16:06:01 Z 37 days
Failing since 150941 2020-06-09 17:05:34 Z 2 days 5 attempts
Testing same since 151033 2020-06-11 01:50:35 Z 1 days 1 attempts
------------------------------------------------------------
People who touched revisions under test:
Andrew Cooper <andrew.cooper3@citrix.com>
Christian Lindig <christian.lindig@citrix.com>
Christopher Clark <christopher.clark6@baesystems.com>
Christopher Clark <christopher.w.clark@gmail.com>
John Thomson <git@johnthomson.fastmail.com.au>
Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Wei Liu <wei.liu2@citrix.com>
Wei Liu <wl@xen.org>
jobs:
build-amd64-xsm pass
build-arm64-xsm pass
build-i386-xsm pass
build-amd64-xtf pass
build-amd64 pass
build-arm64 pass
build-armhf pass
build-i386 pass
build-amd64-libvirt fail
build-arm64-libvirt fail
build-armhf-libvirt fail
build-i386-libvirt fail
build-amd64-prev fail
build-i386-prev fail
build-amd64-pvops pass
build-arm64-pvops pass
build-armhf-pvops pass
build-i386-pvops pass
test-xtf-amd64-amd64-1 pass
test-xtf-amd64-amd64-2 pass
test-xtf-amd64-amd64-3 pass
test-xtf-amd64-amd64-4 pass
test-xtf-amd64-amd64-5 pass
test-amd64-amd64-xl pass
test-arm64-arm64-xl pass
test-armhf-armhf-xl pass
test-amd64-i386-xl pass
test-amd64-amd64-libvirt-qemuu-debianhvm-amd64-xsm blocked
test-amd64-i386-libvirt-qemuu-debianhvm-amd64-xsm blocked
test-amd64-amd64-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-i386-xl-qemut-stubdom-debianhvm-amd64-xsm pass
test-amd64-amd64-xl-qemut-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemut-debianhvm-i386-xsm pass
test-amd64-amd64-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-i386-xl-qemuu-debianhvm-i386-xsm pass
test-amd64-amd64-libvirt-xsm blocked
test-arm64-arm64-libvirt-xsm blocked
test-amd64-i386-libvirt-xsm blocked
test-amd64-amd64-xl-xsm pass
test-arm64-arm64-xl-xsm pass
test-amd64-i386-xl-xsm pass
test-amd64-amd64-qemuu-nested-amd fail
test-amd64-amd64-xl-pvhv2-amd pass
test-amd64-i386-qemut-rhel6hvm-amd pass
test-amd64-i386-qemuu-rhel6hvm-amd pass
test-amd64-amd64-xl-qemut-debianhvm-amd64 pass
test-amd64-i386-xl-qemut-debianhvm-amd64 pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-xl-qemuu-debianhvm-amd64 pass
test-amd64-i386-freebsd10-amd64 pass
test-amd64-amd64-xl-qemuu-ovmf-amd64 pass
test-amd64-i386-xl-qemuu-ovmf-amd64 pass
test-amd64-amd64-xl-qemut-win7-amd64 fail
test-amd64-i386-xl-qemut-win7-amd64 fail
test-amd64-amd64-xl-qemuu-win7-amd64 fail
test-amd64-i386-xl-qemuu-win7-amd64 fail
test-amd64-amd64-xl-qemut-ws16-amd64 fail
test-amd64-i386-xl-qemut-ws16-amd64 fail
test-amd64-amd64-xl-qemuu-ws16-amd64 fail
test-amd64-i386-xl-qemuu-ws16-amd64 fail
test-armhf-armhf-xl-arndale pass
test-amd64-amd64-xl-credit1 pass
test-arm64-arm64-xl-credit1 pass
test-armhf-armhf-xl-credit1 pass
test-amd64-amd64-xl-credit2 pass
test-arm64-arm64-xl-credit2 pass
test-armhf-armhf-xl-credit2 pass
test-armhf-armhf-xl-cubietruck pass
test-amd64-amd64-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-xl-qemuu-dmrestrict-amd64-dmrestrict fail
test-amd64-i386-freebsd10-i386 pass
test-amd64-amd64-qemuu-nested-intel pass
test-amd64-amd64-xl-pvhv2-intel pass
test-amd64-i386-qemut-rhel6hvm-intel pass
test-amd64-i386-qemuu-rhel6hvm-intel pass
test-amd64-amd64-libvirt blocked
test-armhf-armhf-libvirt blocked
test-amd64-i386-libvirt blocked
test-amd64-amd64-livepatch pass
test-amd64-i386-livepatch pass
test-amd64-amd64-migrupgrade blocked
test-amd64-i386-migrupgrade blocked
test-amd64-amd64-xl-multivcpu pass
test-armhf-armhf-xl-multivcpu pass
test-amd64-amd64-pair pass
test-amd64-i386-pair pass
test-amd64-amd64-libvirt-pair blocked
test-amd64-i386-libvirt-pair blocked
test-amd64-amd64-amd64-pvgrub pass
test-amd64-amd64-i386-pvgrub pass
test-amd64-amd64-pygrub fail
test-amd64-amd64-xl-qcow2 fail
test-armhf-armhf-libvirt-raw blocked
test-amd64-i386-xl-raw fail
test-amd64-amd64-xl-rtds pass
test-armhf-armhf-xl-rtds pass
test-arm64-arm64-xl-seattle pass
test-amd64-amd64-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-i386-xl-qemuu-debianhvm-amd64-shadow pass
test-amd64-amd64-xl-shadow pass
test-amd64-i386-xl-shadow pass
test-arm64-arm64-xl-thunderx starved
test-amd64-amd64-libvirt-vhd blocked
test-armhf-armhf-xl-vhd pass
------------------------------------------------------------
sg-report-flight on osstest.test-lab.xenproject.org
logs: /home/logs/logs
images: /home/logs/images
Logs, config files, etc. are available at
http://logs.test-lab.xenproject.org/osstest/logs
Explanation of these reports, and of osstest in general, is at
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README.email;hb=master
http://xenbits.xen.org/gitweb/?p=osstest.git;a=blob;f=README;hb=master
Test harness code can be found at
http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
Not pushing.
------------------------------------------------------------
commit 934d6e1a77947662504cf4d5e36c9520e03aa731
Author: John Thomson <git@johnthomson.fastmail.com.au>
Date: Tue May 15 11:48:43 2018 +1000
tools/ocaml/libs/xc fix gcc-8 format-truncation warning
CC xenctrl_stubs.o
xenctrl_stubs.c: In function 'failwith_xc':
xenctrl_stubs.c:65:17: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=]
"%d: %s: %s", error->code,
^
xenctrl_stubs.c:64:4: note: 'snprintf' output 6 or more bytes (assuming 1029) into a destination of size 1028
snprintf(error_str, sizeof(error_str),
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
"%d: %s: %s", error->code,
~~~~~~~~~~~~~~~~~~~~~~~~~~
xc_error_code_to_desc(error->code),
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
error->message);
~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
make[8]: *** [/build/xen-git/src/xen/tools/ocaml/libs/xc/../../Makefile.rules:37: xenctrl_stubs.o] Error 1
m
Signed-off-by: John Thomson <git@johnthomson.fastmail.com.au>
Acked-by: Christian Lindig <christian.lindig@citrix.com>
Release-acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 2adc90908fbb1e614c477e29f2d45eda94570795)
commit 6e636f297f12a52ce12db11ea0787dd541937ed6
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Thu Apr 5 03:50:50 2018 +0200
tools/misc: fix hypothetical buffer overflow in xen-lowmemd
gcc-8 complains:
xen-lowmemd.c: In function 'handle_low_mem':
xen-lowmemd.c:80:55: error: '%s' directive output may be truncated writing up to 511 bytes into a region of size 489 [-Werror=format-truncation=]
snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data);
^~ ~~~~
xen-lowmemd.c:80:9: note: 'snprintf' output between 36 and 547 bytes into a destination of size 512
snprintf(error, BUFSZ,"Failed to write target %s to xenstore", data);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In practice it wouldn't happen, because 'data' contains string
representation of 64-bit unsigned number (20 characters at most).
But place a limit to mute gcc warning.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 27751d89248c8c5eef6d8b56eb8f7d2084145080)
commit dfc0b23403a2f0069bc7b9c0c20dfe5513eb8fb5
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Thu Apr 5 03:50:52 2018 +0200
tools/blktap2: fix possible '\0' truncation
gcc-8 complains:
tapdisk-vbd.c: In function 'tapdisk_vbd_resume_ring':
tapdisk-vbd.c:1671:53: error: 'snprintf' output may be truncated before the last format character [-Werror=format-truncation=]
snprintf(params.name, sizeof(params.name) - 1, "%s", message);
^
tapdisk-vbd.c:1671:3: note: 'snprintf' output between 1 and 256 bytes into a destination of size 255
snprintf(params.name, sizeof(params.name) - 1, "%s", message);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
The "- 1" in buffer size should be actually applied to message, to leave
place for terminating '\0', not the other way around (truncate '\0' even
if it would fit).
In function 'tapdisk_control_open_image',
inlined from 'tapdisk_control_handle_request' at tapdisk-control.c:660:10:
tapdisk-control.c:465:2: error: 'strncpy' specified bound 256 equals destination size [-Werror=stringop-truncation]
strncpy(params.name, vbd->name, BLKTAP2_MAX_MESSAGE_LEN);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
In function 'tapdisk_control_create_socket',
inlined from 'tapdisk_control_open' at tapdisk-control.c:836:9:
tapdisk-control.c:793:2: error: 'strncpy' specified bound 108 equals destination size [-Werror=stringop-truncation]
strncpy(saddr.sun_path, td_control.path, sizeof(saddr.sun_path));
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
block-qcow.c: In function 'qcow_create':
block-qcow.c:1216:5: error: 'strncpy' specified bound 4096 equals destination size [-Werror=stringop-truncation]
strncpy(backing_filename, backing_file,
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
sizeof(backing_filename));
~~~~~~~~~~~~~~~~~~~~~~~~~
I those cases, reduce size of copied string and make sure final '\0' is
added.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 850e89b3ef1a7be6b71fa7ae22333c884e08431a)
commit 2f83654fa3331d1ec79275072f8742f175f82bc5
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Thu Apr 5 03:50:54 2018 +0200
tools/gdbsx: fix -Wstringop-truncation warning
gcc-8 complains:
gx_main.c: In function 'prepare_stop_reply':
gx_main.c:385:9: error: 'strncpy' output truncated before terminating nul copying 6 bytes from a string of the same length [-Werror=stringop-truncation]
strncpy(buf, "watch:", 6);
^~~~~~~~~~~~~~~~~~~~~~~~~
Since terminating '\0' isn't needed here at all, switch to memcpy.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 7f601f7c341c80d554615556d60e3b8ed1e5ad4f)
commit bf467cc828bde380e9201d8b49c7866a5b92d719
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Thu Apr 5 03:50:53 2018 +0200
tools/xenpmd: fix possible '\0' truncation
gcc-8 complains:
xenpmd.c:207:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation]
strncpy(info->oem_info, attrib_value, 32);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xenpmd.c:201:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation]
strncpy(info->battery_type, attrib_value, 32);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xenpmd.c:195:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation]
strncpy(info->serial_number, attrib_value, 32);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
xenpmd.c:189:9: error: 'strncpy' specified bound 32 equals destination size [-Werror=stringop-truncation]
strncpy(info->model_number, attrib_value, 32);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Copy 31 chars, then make sure terminating '\0' is present. Those fields
are passed to strlen and as '%s' for snprintf later.
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit 938c8f53b1f80175c6f7a1399efdb984abb0cb8b)
commit 6df4d40d846eb5151a89d26d1a63d632c6b9eb55
Author: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Date: Thu Apr 5 03:50:49 2018 +0200
tools/libxc: fix strncpy size
gcc-8 warns about possible truncation of trailing '\0'.
Final character is overridden by '\0' anyway, so don't bother to copy
it.
This fixes compile failure:
xc_pm.c: In function 'xc_set_cpufreq_gov':
xc_pm.c:308:5: error: 'strncpy' specified bound 16 equals destination size [-Werror=stringop-truncation]
strncpy(scaling_governor, govname, CPUFREQ_NAME_LEN);
^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
cc1: all warnings being treated as errors
Signed-off-by: Marek Marczykowski-Górecki <marmarek@invisiblethingslab.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
Release-Acked-by: Juergen Gross <jgross@suse.com>
(cherry picked from commit fa7789ef18bd2e716997937af71b2e4b5b00a159)
commit e20bb5818174e9d09389776cb14781b9c6436554
Author: Christopher Clark <christopher.w.clark@gmail.com>
Date: Wed Jul 18 15:22:17 2018 -0700
tools/xentop : replace use of deprecated vwprintw
gcc-8.1 complains:
| xentop.c: In function 'print':
| xentop.c:304:4: error: 'vwprintw' is deprecated [-Werror=deprecated-declarations]
| vwprintw(stdscr, (curses_str_t)fmt, args);
| ^~~~~~~~
vw_printw (note the underscore) is a non-deprecated alternative.
Signed-off-by: Christopher Clark <christopher.clark6@baesystems.com>
Acked-by: Wei Liu <wei.liu2@citrix.com>
(cherry picked from commit 2b50cdbc444c637575580dcfa6c9525a84d5cc62)
commit a1a9b055a349748083665e42843f75d6db2c6a7b
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Jan 8 19:47:46 2020 +0000
x86/spec-ctrl: Mitigate the Special Register Buffer Data Sampling sidechannel
See patch documentation and comments.
This is part of XSA-320 / CVE-2020-0543
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
(cherry picked from commit 6a49b9a7920c82015381740905582b666160d955)
commit afca67fafde22033b9a967ae197a10af5c654f02
Author: Andrew Cooper <andrew.cooper3@citrix.com>
Date: Wed Jan 8 19:47:46 2020 +0000
x86/spec-ctrl: CPUID/MSR definitions for Special Register Buffer Data Sampling
This is part of XSA-320 / CVE-2020-0543
Signed-off-by: Andrew Cooper <andrew.cooper3@citrix.com>
Reviewed-by: Jan Beulich <jbeulich@suse.com>
Acked-by: Wei Liu <wl@xen.org>
(cherry picked from commit caab85ab58c0cdf74ab070a5de5c4df89f509ff3)
(qemu changes not included)
^ permalink raw reply [flat|nested] 12+ messages in thread
* Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-12 8:12 [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved osstest service owner
@ 2020-06-12 16:17 ` Ian Jackson
2020-06-12 16:47 ` Ian Jackson
2020-06-15 13:57 ` Ian Jackson
0 siblings, 2 replies; 12+ messages in thread
From: Ian Jackson @ 2020-06-12 16:17 UTC (permalink / raw)
To: Jan Beulich
Cc: xen-devel, Stefano Stabellini, Julien Grall, George Dunlap, Wei Liu
osstest service owner writes ("[xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved"):
> flight 151033 xen-4.10-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/151033/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039
> build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039
> build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039
> build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039
../../../gnulib/lib/fseeko.c: In function 'rpl_fseeko':
../../../gnulib/lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
#error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
^~~~~
make[3]: *** [Makefile:2473: fseeko.lo] Error 1
http://logs.test-lab.xenproject.org/osstest/logs/151033/build-amd64-libvirt/6.ts-libvirt-build.log
In principle maybe we could fix this by generating a private libvirt
branch with the build fixes ? Or maybe we should simply try plucking
a new version of libvirt ? We could update the pinned version in Xen
4.10 to the one from 4.11 ? We might have to do the same for 4.9
then.
> test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039
> test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039
> test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039
domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
domainbuilder: detail: XZ: Saw data stream end
domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c
domainbuilder: detail: loader probe OK
...
domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages)
xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error
libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory
http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log
???? Anyone have any ideas ? I would have guessed that this was an
incompatibility between pygrub and the boot config made by the new
pygrub but
git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
suggests not.
As an alternative to trying to fix these, I could arrange for Xen 4.10
and earlier to use stretch rather than buster. 4.10 is end of
security support in December and probably stretch will not break too
badly for us before then.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-12 16:17 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Ian Jackson
@ 2020-06-12 16:47 ` Ian Jackson
2020-06-12 17:19 ` Andrew Cooper
2020-06-15 13:29 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Jan Beulich
2020-06-15 13:57 ` Ian Jackson
1 sibling, 2 replies; 12+ messages in thread
From: Ian Jackson @ 2020-06-12 16:47 UTC (permalink / raw)
To: Jan Beulich, xen-devel, George Dunlap, Julien Grall,
Stefano Stabellini, Wei Liu
Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> > test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039
> > test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039
> > test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039
>
> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
> domainbuilder: detail: XZ: Saw data stream end
> domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c
> domainbuilder: detail: loader probe OK
> ...
> domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages)
> xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error
> libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory
>
> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log
>
> ???? Anyone have any ideas ? I would have guessed that this was an
> incompatibility between pygrub and the boot config made by the new
> pygrub but
> git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
> suggests not.
Andy suggested on IRC that there were some compression fixes which had
perhaps not been backported far enough.
I think that's
lz4: fix system halt at boot kernel on x86_64
14b62ab3e5a79816edfc6dd3afce1bb68c106ac5
master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9
lz4: refine commit 9143a6c55ef7 for the 64-bit case
6561994b87af3e9cd28ee99c42e8b2697621687d
master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59
Anyone have any objection to me sending those to 4.10 and maybe 4.9 ?
They apply cleanly in both cases.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-12 16:47 ` Ian Jackson
@ 2020-06-12 17:19 ` Andrew Cooper
2020-06-15 13:44 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] Ian Jackson
2020-06-15 13:29 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Jan Beulich
1 sibling, 1 reply; 12+ messages in thread
From: Andrew Cooper @ 2020-06-12 17:19 UTC (permalink / raw)
To: Ian Jackson, Jan Beulich, xen-devel, George Dunlap, Julien Grall,
Stefano Stabellini, Wei Liu
On 12/06/2020 17:47, Ian Jackson wrote:
> Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
>>> test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039
>>> test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039
>>> test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039
>> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
>> domainbuilder: detail: XZ: Saw data stream end
>> domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c
>> domainbuilder: detail: loader probe OK
>> ...
>> domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages)
>> xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error
>> libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log
>>
>> ???? Anyone have any ideas ? I would have guessed that this was an
>> incompatibility between pygrub and the boot config made by the new
>> pygrub but
>> git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
>> suggests not.
> Andy suggested on IRC that there were some compression fixes which had
> perhaps not been backported far enough.
>
> I think that's
>
> lz4: fix system halt at boot kernel on x86_64
> 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5
> master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9
>
> lz4: refine commit 9143a6c55ef7 for the 64-bit case
> 6561994b87af3e9cd28ee99c42e8b2697621687d
> master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59
>
> Anyone have any objection to me sending those to 4.10 and maybe 4.9 ?
> They apply cleanly in both cases.
Ah - you found them faster than I did. Yes - these were the ones I was
thinking of.
No objections.
~Andrew
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-12 16:47 ` Ian Jackson
2020-06-12 17:19 ` Andrew Cooper
@ 2020-06-15 13:29 ` Jan Beulich
1 sibling, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2020-06-15 13:29 UTC (permalink / raw)
To: Ian Jackson
Cc: xen-devel, Stefano Stabellini, Julien Grall, George Dunlap, Wei Liu
On 12.06.2020 18:47, Ian Jackson wrote:
> Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
>>> test-amd64-amd64-xl-qcow2 10 debian-di-install fail REGR. vs. 150039
>>> test-amd64-amd64-pygrub 10 debian-di-install fail REGR. vs. 150039
>>> test-amd64-i386-xl-raw 10 debian-di-install fail REGR. vs. 150039
>>
>> domainbuilder: detail: xc_dom_find_loader: trying Linux bzImage loader ...
>> domainbuilder: detail: XZ: Saw data stream end
>> domainbuilder: detail: _xc_try_lzma_decode: XZ decompress OK, 0x4cd8f0 -> 0x1a7779c
>> domainbuilder: detail: loader probe OK
>> ...
>> domainbuilder: detail: xc_dom_alloc_segment: module0 : 0xffffffff82c00000 -> 0xffffffff82c02000 (pfn 0x2c00 + 0x2 pages)
>> xc: error: panic: xc_dom_core.c:387: xc_dom_do_gunzip: inflate failed (rc=-5): Internal error
>> libxl: error: libxl_dom.c:744:libxl__build_dom: xc_dom_build_image failed: No such file or directory
>>
>> http://logs.test-lab.xenproject.org/osstest/logs/151033/test-amd64-amd64-pygrub/10.ts-debian-di-install.log
>>
>> ???? Anyone have any ideas ? I would have guessed that this was an
>> incompatibility between pygrub and the boot config made by the new
>> pygrub but
>> git-log origin/staging-4.10..origin/stable-4.11 tools/pygrub/
>> suggests not.
>
> Andy suggested on IRC that there were some compression fixes which had
> perhaps not been backported far enough.
>
> I think that's
>
> lz4: fix system halt at boot kernel on x86_64
> 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5
> master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9
>
> lz4: refine commit 9143a6c55ef7 for the 64-bit case
> 6561994b87af3e9cd28ee99c42e8b2697621687d
> master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59
>
> Anyone have any objection to me sending those to 4.10 and maybe 4.9 ?
> They apply cleanly in both cases.
Seeing the other pieces that have been put onto these old branches
recently, it's probably fine to add the two ones here as well. In
general, as mentioned before, I view it as wrong to put non-
security fixes onto the security-only branches. But since I can see
why changes to address newer compilers' changed behavior may be
wanted/needed, I guess the ones here fall into a pretty similar
group.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]
2020-06-12 17:19 ` Andrew Cooper
@ 2020-06-15 13:44 ` Ian Jackson
2020-06-15 14:04 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Ian Jackson @ 2020-06-15 13:44 UTC (permalink / raw)
To: Jan Beulich, Andrew Cooper
Cc: Stefano Stabellini, Julien Grall, Wei Liu, George Dunlap,
xen-devel, Ian Jackson
Andrew Cooper writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> On 12/06/2020 17:47, Ian Jackson wrote:
> > Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> > I think that's
> >
> > lz4: fix system halt at boot kernel on x86_64
> > 14b62ab3e5a79816edfc6dd3afce1bb68c106ac5
> > master commit: 5d90ff79542ab9c6eebe5c315c68c196bcf353b9
> >
> > lz4: refine commit 9143a6c55ef7 for the 64-bit case
> > 6561994b87af3e9cd28ee99c42e8b2697621687d
> > master commit: 2d7572cdfa4d481c1ca246aa1ce5239ccae7eb59
> >
> > Anyone have any objection to me sending those to 4.10 and maybe 4.9 ?
> > They apply cleanly in both cases.
>
> Ah - you found them faster than I did. Yes - these were the ones I was
> thinking of.
>
> No objections.
Thanks.
Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> Seeing the other pieces that have been put onto these old branches
> recently, it's probably fine to add the two ones here as well. In
> general, as mentioned before, I view it as wrong to put non-
> security fixes onto the security-only branches.
Yes. I can see why this is not ideal.
> But since I can see why changes to address newer compilers' changed
> behavior may be wanted/needed, I guess the ones here fall into a
> pretty similar group.
However, as a practical matter, I think it is probably a good idea to
enable (i) us to test these branches with an up-to-date CI setup (ii)
people to be able to build it with modern compilers.
So I think in general I am saying that narrow and low-risk build fixes
are reasonable backport candidates.
Thanks to both for your opinions. I have pushed those two to 4.10 and
will see how things go. I may send them to 4.9 too.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-12 16:17 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Ian Jackson
2020-06-12 16:47 ` Ian Jackson
@ 2020-06-15 13:57 ` Ian Jackson
2020-06-16 16:47 ` Ian Jackson
1 sibling, 1 reply; 12+ messages in thread
From: Ian Jackson @ 2020-06-15 13:57 UTC (permalink / raw)
To: Jan Beulich, xen-devel, George Dunlap, Julien Grall,
Stefano Stabellini, Wei Liu
Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> osstest service owner writes ("[xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved"):
> > flight 151033 xen-4.10-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/151033/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-arm64-libvirt 6 libvirt-build fail REGR. vs. 150039
> > build-armhf-libvirt 6 libvirt-build fail REGR. vs. 150039
> > build-i386-libvirt 6 libvirt-build fail REGR. vs. 150039
> > build-amd64-libvirt 6 libvirt-build fail REGR. vs. 150039
>
> ../../../gnulib/lib/fseeko.c: In function 'rpl_fseeko':
> ../../../gnulib/lib/fseeko.c:110:4: error: #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
> #error "Please port gnulib fseeko.c to your platform! Look at the code in fseeko.c, then report this to bug-gnulib."
> ^~~~~
> make[3]: *** [Makefile:2473: fseeko.lo] Error 1
>
> http://logs.test-lab.xenproject.org/osstest/logs/151033/build-amd64-libvirt/6.ts-libvirt-build.log
>
> In principle maybe we could fix this by generating a private libvirt
> branch with the build fixes ? Or maybe we should simply try plucking
> a new version of libvirt ? We could update the pinned version in Xen
> 4.10 to the one from 4.11 ? We might have to do the same for 4.9
> then.
No-one has commented on this.
I propose to update in
http://xenbits.xen.org/gitweb/?p=libvirt.git;a=summary
the refs
refs/heads/osstest/frozen/xen-4.10-testing
refs/heads/osstest/frozen/xen-4.9-testing
from
681bc423e823ab86b20748db311721bdef20defe
981e2c70973454cad360f7c9eec2d6ded0a86747
respectively to
076a2b409667dd9f716a2a2085e1ffea9d58fe8b
which is current value of
refs/heads/osstest/frozen/xen-4.11-testing
Both of those will be fast-forward updates.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]
2020-06-15 13:44 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] Ian Jackson
@ 2020-06-15 14:04 ` Jan Beulich
2020-06-15 14:08 ` Ian Jackson
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2020-06-15 14:04 UTC (permalink / raw)
To: Ian Jackson
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Andrew Cooper,
George Dunlap, xen-devel
On 15.06.2020 15:44, Ian Jackson wrote:
> Thanks to both for your opinions. I have pushed those two to 4.10 and
> will see how things go. I may send them to 4.9 too.
Won't 4.10 continue to be blocked then because or -prev issues?
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]
2020-06-15 14:04 ` Jan Beulich
@ 2020-06-15 14:08 ` Ian Jackson
2020-06-16 6:35 ` Jan Beulich
0 siblings, 1 reply; 12+ messages in thread
From: Ian Jackson @ 2020-06-15 14:08 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Andrew Cooper,
George Dunlap, xen-devel
Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"):
> On 15.06.2020 15:44, Ian Jackson wrote:
> > Thanks to both for your opinions. I have pushed those two to 4.10 and
> > will see how things go. I may send them to 4.9 too.
>
> Won't 4.10 continue to be blocked then because or -prev issues?
There are multiple issues. My hope is to get rid of all of them...
Eventually I think we will have to force push 4.9 because its prev
builds will fail and won't want to update 4.8.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]
2020-06-15 14:08 ` Ian Jackson
@ 2020-06-16 6:35 ` Jan Beulich
2020-06-16 15:12 ` Ian Jackson
0 siblings, 1 reply; 12+ messages in thread
From: Jan Beulich @ 2020-06-16 6:35 UTC (permalink / raw)
To: Ian Jackson
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Andrew Cooper,
George Dunlap, xen-devel
On 15.06.2020 16:08, Ian Jackson wrote:
> Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"):
>> On 15.06.2020 15:44, Ian Jackson wrote:
>>> Thanks to both for your opinions. I have pushed those two to 4.10 and
>>> will see how things go. I may send them to 4.9 too.
>>
>> Won't 4.10 continue to be blocked then because or -prev issues?
>
> There are multiple issues. My hope is to get rid of all of them...
>
> Eventually I think we will have to force push 4.9 because its prev
> builds will fail and won't want to update 4.8.
Right - which will then enable 4.10's -prev build to work, which
will in turn allow 4.11's -prev builds to work, and then the same
for 4.12. I.e. osstest will continue to be quite busy for the
next several days.
Instead of building -prev anew each time, wouldn't it make sense
to store and re-use the most recent "prev" tree's build? This
ought to avoid this sort of cascade dependencies in particular
when upgrading the test platform underneath. There's no reason
to fail a flight just because the N-1 tree doesn't build anymore.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]
2020-06-16 6:35 ` Jan Beulich
@ 2020-06-16 15:12 ` Ian Jackson
0 siblings, 0 replies; 12+ messages in thread
From: Ian Jackson @ 2020-06-16 15:12 UTC (permalink / raw)
To: Jan Beulich
Cc: Stefano Stabellini, Julien Grall, Wei Liu, Andrew Cooper,
George Dunlap, xen-devel
Jan Beulich writes ("Re: Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages]"):
> Right - which will then enable 4.10's -prev build to work, which
> will in turn allow 4.11's -prev builds to work, and then the same
> for 4.12. I.e. osstest will continue to be quite busy for the
> next several days.
Yes.
> Instead of building -prev anew each time, wouldn't it make sense
> to store and re-use the most recent "prev" tree's build? This
> ought to avoid this sort of cascade dependencies in particular
> when upgrading the test platform underneath. There's no reason
> to fail a flight just because the N-1 tree doesn't build anymore.
Well. In principle, yes. Fairly recently osstest got machinery to do
that kind of anointed build outputs. It's not entirely trivial, and
this kind of thing happens about once every two years. We're noticing
two such cases in a row because we put off the osstest stretch upgrade
and are now doing the buster one early.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)
2020-06-15 13:57 ` Ian Jackson
@ 2020-06-16 16:47 ` Ian Jackson
0 siblings, 0 replies; 12+ messages in thread
From: Ian Jackson @ 2020-06-16 16:47 UTC (permalink / raw)
To: Jan Beulich, xen-devel, George Dunlap, Julien Grall,
Stefano Stabellini, Wei Liu
Ian Jackson writes ("Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved)"):
> I propose to update in
> http://xenbits.xen.org/gitweb/?p=libvirt.git;a=summary
> the refs
> refs/heads/osstest/frozen/xen-4.10-testing
> refs/heads/osstest/frozen/xen-4.9-testing
> from
> 681bc423e823ab86b20748db311721bdef20defe
> 981e2c70973454cad360f7c9eec2d6ded0a86747
> respectively to
> 076a2b409667dd9f716a2a2085e1ffea9d58fe8b
> which is current value of
> refs/heads/osstest/frozen/xen-4.11-testing
>
> Both of those will be fast-forward updates.
I have now done this. There will be a further osstest change which I
think will then sort all of this out.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2020-06-16 16:47 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2020-06-12 8:12 [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved osstest service owner
2020-06-12 16:17 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Ian Jackson
2020-06-12 16:47 ` Ian Jackson
2020-06-12 17:19 ` Andrew Cooper
2020-06-15 13:44 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) [and 1 more messages] Ian Jackson
2020-06-15 14:04 ` Jan Beulich
2020-06-15 14:08 ` Ian Jackson
2020-06-16 6:35 ` Jan Beulich
2020-06-16 15:12 ` Ian Jackson
2020-06-15 13:29 ` Xen 4.10 breakage with buster (was Re: [xen-4.10-testing test] 151033: regressions - trouble: blocked/fail/pass/starved) Jan Beulich
2020-06-15 13:57 ` Ian Jackson
2020-06-16 16:47 ` Ian Jackson
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).