* [qemu-upstream-4.2-testing test] 77180: regressions - FAIL
@ 2016-01-06 18:28 osstest service owner
2016-01-07 9:56 ` Ian Campbell
0 siblings, 1 reply; 12+ messages in thread
From: osstest service owner @ 2016-01-06 18:28 UTC (permalink / raw)
To: xen-devel, osstest-admin
flight 77180 qemu-upstream-4.2-testing real [real]
http://logs.test-lab.xenproject.org/osstest/logs/77180/
Regressions :-(
Tests which did not succeed and are blocking,
including tests which could not be run:
build-i386 5 xen-build fail REGR. vs. 62044
build-amd64 5 xen-build fail REGR. vs. 62044
Tests which did not succeed, but are not blocking:
build-i386-libvirt 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a
test-amd64-i386-qemuu-rhel6hvm-intel 1 build-check(1) blocked n/a
test-i386-i386-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
test-amd64-i386-qemuu-rhel6hvm-amd 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-check(1) blocked n/a
test-amd64-i386-xend-qemuu-winxpsp3 1 build-check(1) blocked n/a
test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a
build-amd64-libvirt 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-win7-amd64 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-winxpsp3 1 build-check(1) blocked n/a
test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-check(1) blocked n/a
version targeted for testing:
qemuu 5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
qemuu c17e602ae64fb24405ebd256679ba9a6f5819086
Last test of basis 62044 2015-09-15 15:06:42 Z 113 days
Testing same since 66542 2015-12-18 16:37:10 Z 19 days 11 attempts
------------------------------------------------------------
People who touched revisions under test:
Stefano Stabellini <stefano.stabellini@eu.citrix.com>
jobs:
build-amd64 fail
build-i386 fail
build-amd64-libvirt blocked
build-i386-libvirt blocked
build-amd64-pvops pass
build-i386-pvops pass
test-amd64-i386-qemuu-rhel6hvm-amd blocked
test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked
test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
test-amd64-amd64-xl-qemuu-win7-amd64 blocked
test-amd64-i386-xl-qemuu-win7-amd64 blocked
test-amd64-i386-qemuu-rhel6hvm-intel blocked
test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked
test-amd64-i386-xend-qemuu-winxpsp3 blocked
test-amd64-amd64-xl-qemuu-winxpsp3 blocked
test-i386-i386-xl-qemuu-winxpsp3 blocked
------------------------------------------------------------
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 5081fc1c773d2a83ec7a867f030323b8b6956cd1
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri Dec 18 15:45:14 2015 +0000
xenfb: avoid reading twice the same fields from the shared page
Reading twice the same field could give the guest an attack of
opportunity. In the case of event->type, gcc could compile the switch
statement into a jump table, effectively ending up reading the type
field multiple times.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
Date: Fri Dec 18 15:44:58 2015 +0000
xen/blkif: Avoid double access to src->nr_segments
src is stored in shared memory and src->nr_segments is dereferenced
twice at the end of the function. If a compiler decides to compile this
into two separate memory accesses then the size limitation could be
bypassed.
Fix it by removing the double access to src->nr_segments.
This is part of XSA-155.
Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL
2016-01-06 18:28 [qemu-upstream-4.2-testing test] 77180: regressions - FAIL osstest service owner
@ 2016-01-07 9:56 ` Ian Campbell
2016-01-07 11:22 ` Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL) Ian Campbell
2016-01-08 12:10 ` [qemu-upstream-4.2-testing test] 77180: regressions - FAIL Ian Jackson
0 siblings, 2 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-07 9:56 UTC (permalink / raw)
To: osstest service owner, xen-devel, Ian Jackson, Stefano Stabellini
On Wed, 2016-01-06 at 18:28 +0000, osstest service owner wrote:
> flight 77180 qemu-upstream-4.2-testing real [real]
> http://logs.test-lab.xenproject.org/osstest/logs/77180/
>
> Regressions :-(
>
> Tests which did not succeed and are blocking,
> including tests which could not be run:
> build-i386 5 xen-build fail REGR. vs. 62044
> build-amd64 5 xen-build fail REGR. vs. 62044
This is "man/xl.pod.1 around line 854: Expected text after =item, not a
bullet" exposed by the Jessie upgrade.
However per Ian in <22154.35021.750846.695785@mariner.uk.xensource.com> [0]
:
...] 4.2 has had no commits since October - in particular, none
of the recent security fixes - and I would be reluctant to give it a
veneer of activity.
So our choices WRT these fixes in qemu-xen.git#staging-4.2, given they have
already been pushed, are:
1. Fix xen.git#staging-4.2 to build on Jessie and wait for it to propagate.
2. Revert the fixes from qemu-xen.git#staging-4.2 and force push the
resulting tree (which would be identical to something which previously
passed).
3. Rollback qemu-xen.git#staging-4.2.
4. Force push.
5. Drop a stop file.
6. Shave yakks in osstest to allow per-branch selection of the Debian suite
and pin xen-4.2 and earlier to Wheezy.
#1 is contrary to the quote above, which makes a reasonable argument IMHO.
#3, #4 and #5 all seem like bad ideas to me.
#2 is a bit odd (to have the fixes in the branch but reverted), but seems
least bad compared with #3..#5.
#6 is potentially a lot of work, but might be the right long term answer.
Ian.
[0] http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00112.html
>
> Tests which did not succeed, but are not blocking:
> build-i386-libvirt 1 build-
> check(1) blocked n/a
> test-amd64-i386-xl-qemuu-win7-amd64 1 build-
> check(1) blocked n/a
> test-amd64-i386-qemuu-rhel6hvm-intel 1 build-
> check(1) blocked n/a
> test-i386-i386-xl-qemuu-winxpsp3 1 build-
> check(1) blocked n/a
> test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-
> check(1) blocked n/a
> test-amd64-i386-qemuu-rhel6hvm-amd 1 build-
> check(1) blocked n/a
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-
> check(1) blocked n/a
> test-amd64-i386-xend-qemuu-winxpsp3 1 build-
> check(1) blocked n/a
> test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-
> check(1) blocked n/a
> build-amd64-libvirt 1 build-
> check(1) blocked n/a
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-
> check(1) blocked n/a
> test-amd64-amd64-xl-qemuu-win7-amd64 1 build-
> check(1) blocked n/a
> test-amd64-amd64-xl-qemuu-winxpsp3 1 build-
> check(1) blocked n/a
> test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-
> check(1) blocked n/a
>
> version targeted for testing:
> qemuu 5081fc1c773d2a83ec7a867f030323b8b6956cd1
> baseline version:
> qemuu c17e602ae64fb24405ebd256679ba9a6f5819086
>
> Last test of basis 62044 2015-09-15 15:06:42 Z 113 days
> Testing same since 66542 2015-12-18 16:37:10 Z 19 days 11
> attempts
>
> ------------------------------------------------------------
> People who touched revisions under test:
> Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> jobs:
> build-amd64 fail
> build-i386 fail
> build-amd64-libvirt blocked
> build-i386-libvirt blocked
> build-amd64-pvops pass
> build-i386-pvops pass
> test-amd64-i386-qemuu-rhel6hvm-amd blocked
> test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
> test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked
> test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
> test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
> test-amd64-amd64-xl-qemuu-win7-amd64 blocked
> test-amd64-i386-xl-qemuu-win7-amd64 blocked
> test-amd64-i386-qemuu-rhel6hvm-intel blocked
> test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked
> test-amd64-i386-xend-qemuu-winxpsp3 blocked
> test-amd64-amd64-xl-qemuu-winxpsp3 blocked
> test-i386-i386-xl-qemuu-winxpsp3 blocked
>
>
> ------------------------------------------------------------
> 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=maste
> r
>
> Test harness code can be found at
> http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
>
>
> Not pushing.
>
> ------------------------------------------------------------
> commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Fri Dec 18 15:45:14 2015 +0000
>
> xenfb: avoid reading twice the same fields from the shared page
>
> Reading twice the same field could give the guest an attack of
> opportunity. In the case of event->type, gcc could compile the switch
> statement into a jump table, effectively ending up reading the type
> field multiple times.
>
> This is part of XSA-155.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
>
> commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
> Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> Date: Fri Dec 18 15:44:58 2015 +0000
>
> xen/blkif: Avoid double access to src->nr_segments
>
> src is stored in shared memory and src->nr_segments is dereferenced
> twice at the end of the function. If a compiler decides to compile
> this
> into two separate memory accesses then the size limitation could be
> bypassed.
>
> Fix it by removing the double access to src->nr_segments.
>
> This is part of XSA-155.
>
> Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 9:56 ` Ian Campbell
@ 2016-01-07 11:22 ` Ian Campbell
2016-01-07 11:45 ` Jan Beulich
2016-01-22 9:22 ` Ian Campbell
2016-01-08 12:10 ` [qemu-upstream-4.2-testing test] 77180: regressions - FAIL Ian Jackson
1 sibling, 2 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-07 11:22 UTC (permalink / raw)
To: Ian Jackson, Stefano Stabellini, Jan Beulich, Wei Liu
Cc: xen-devel, Lars Kurth
So this arose because Stefano was unaware that 4.2 was no longer supported.
Neither am I ever confident about where the cut-off lie, e.g. I always have
to ask if I am doing backports for a security issue.
We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features right
under Initial Release giving first the date until which that tree is
supported with backports and second the date until which security support
will exist. We might also want to add a third "status" row. e.g.
"Supported", "Security Support only", "EOL" (we'll deal with extended
support by a third party when that next arises).
I'm happy to make the edits, however I don't know what dates I would write
here. Taking it to be 18 months of Support and a further 18 months of
security support I would get:
Xen 4.0 Xen 4.1 Xen 4.2 Xen 4.3 Xen 4.4 Xen 4.5 Xen 4.6
Initial Release 7 April 2010 25 March 2011 17 Sept 2012 9 July 2013 10 March 2014 15 Jan 2015 13 Oct 2015
Supported until EOL - ??? EOL - ??? EOL - ??? EOL - Jan 2015 EOL - Sept 2015 July 2016 April 2017
Security support til EOL - ??? EOL - ??? EOL - ??? July 2016 March 2016 Jan 2017 Oct 2018
(maybe those EOLs - ??? could be whatever the respective dates were, I
didn't try and backtrack to try and find out if reality matched the plan)
Ian.
On Thu, 2016-01-07 at 09:56 +0000, Ian Campbell wrote:
> On Wed, 2016-01-06 at 18:28 +0000, osstest service owner wrote:
> > flight 77180 qemu-upstream-4.2-testing real [real]
> > http://logs.test-lab.xenproject.org/osstest/logs/77180/
> >
> > Regressions :-(
> >
> > Tests which did not succeed and are blocking,
> > including tests which could not be run:
> > build-i386 5 xen-build fail REGR.
> > vs. 62044
> > build-amd64 5 xen-build fail REGR.
> > vs. 62044
>
> This is "man/xl.pod.1 around line 854: Expected text after =item, not a
> bullet" exposed by the Jessie upgrade.
>
> However per Ian in <22154.35021.750846.695785@mariner.uk.xensource.com> [
> 0]
> :
>
> ...] 4.2 has had no commits since October - in particular, none
> of the recent security fixes - and I would be reluctant to give it a
> veneer of activity.
>
> So our choices WRT these fixes in qemu-xen.git#staging-4.2, given they
> have
> already been pushed, are:
>
> 1. Fix xen.git#staging-4.2 to build on Jessie and wait for it to
> propagate.
> 2. Revert the fixes from qemu-xen.git#staging-4.2 and force push the
> resulting tree (which would be identical to something which
> previously
> passed).
> 3. Rollback qemu-xen.git#staging-4.2.
> 4. Force push.
> 5. Drop a stop file.
> 6. Shave yakks in osstest to allow per-branch selection of the Debian
> suite
> and pin xen-4.2 and earlier to Wheezy.
>
> #1 is contrary to the quote above, which makes a reasonable argument
> IMHO.
>
> #3, #4 and #5 all seem like bad ideas to me.
>
> #2 is a bit odd (to have the fixes in the branch but reverted), but seems
> least bad compared with #3..#5.
>
> #6 is potentially a lot of work, but might be the right long term answer.
>
> Ian.
>
> [0] http://lists.xenproject.org/archives/html/xen-devel/2016-01/msg00112.
> html
> >
> > Tests which did not succeed, but are not blocking:
> > build-i386-libvirt 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-xl-qemuu-win7-amd64 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-qemuu-rhel6hvm-intel 1 build-
> > check(1) blocked n/a
> > test-i386-i386-xl-qemuu-winxpsp3 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-xl-qemuu-ovmf-amd64 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-qemuu-rhel6hvm-amd 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-xend-qemuu-winxpsp3 1 build-
> > check(1) blocked n/a
> > test-amd64-i386-xl-qemuu-debianhvm-amd64 1 build-
> > check(1) blocked n/a
> > build-amd64-libvirt 1 build-
> > check(1) blocked n/a
> > test-amd64-amd64-xl-qemuu-debianhvm-amd64 1 build-
> > check(1) blocked n/a
> > test-amd64-amd64-xl-qemuu-win7-amd64 1 build-
> > check(1) blocked n/a
> > test-amd64-amd64-xl-qemuu-winxpsp3 1 build-
> > check(1) blocked n/a
> > test-amd64-amd64-xl-qemuu-ovmf-amd64 1 build-
> > check(1) blocked n/a
> >
> > version targeted for testing:
> > qemuu 5081fc1c773d2a83ec7a867f030323b8b6956cd1
> > baseline version:
> > qemuu c17e602ae64fb24405ebd256679ba9a6f5819086
> >
> > Last test of basis 62044 2015-09-15 15:06:42 Z 113 days
> > Testing same since 66542 2015-12-18 16:37:10 Z 19 days 11
> > attempts
> >
> > ------------------------------------------------------------
> > People who touched revisions under test:
> > Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> >
> > jobs:
> > build-amd64 fail
> > build-i386 fail
> > build-amd64-libvirt blocked
> > build-i386-libvirt blocked
> > build-amd64-pvops pass
> > build-i386-pvops pass
> > test-amd64-i386-qemuu-rhel6hvm-amd blocked
> > test-amd64-amd64-xl-qemuu-debianhvm-amd64 blocked
> > test-amd64-i386-xl-qemuu-debianhvm-amd64 blocked
> > test-amd64-amd64-xl-qemuu-ovmf-amd64 blocked
> > test-amd64-i386-xl-qemuu-ovmf-amd64 blocked
> > test-amd64-amd64-xl-qemuu-win7-amd64 blocked
> > test-amd64-i386-xl-qemuu-win7-amd64 blocked
> > test-amd64-i386-qemuu-rhel6hvm-intel blocked
> > test-amd64-i386-xl-qemuu-winxpsp3-vcpus1 blocked
> > test-amd64-i386-xend-qemuu-winxpsp3 blocked
> > test-amd64-amd64-xl-qemuu-winxpsp3 blocked
> > test-i386-i386-xl-qemuu-winxpsp3 blocked
> >
> >
> > ------------------------------------------------------------
> > 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=mas
> > te
> > r
> >
> > Test harness code can be found at
> > http://xenbits.xen.org/gitweb?p=osstest.git;a=summary
> >
> >
> > Not pushing.
> >
> > ------------------------------------------------------------
> > commit 5081fc1c773d2a83ec7a867f030323b8b6956cd1
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date: Fri Dec 18 15:45:14 2015 +0000
> >
> > xenfb: avoid reading twice the same fields from the shared page
> >
> > Reading twice the same field could give the guest an attack of
> > opportunity. In the case of event->type, gcc could compile the
> > switch
> > statement into a jump table, effectively ending up reading the type
> > field multiple times.
> >
> > This is part of XSA-155.
> >
> > Signed-off-by: Stefano Stabellini <stefano.stabellini@eu.citrix.com
> > >
> >
> > commit 74fab2ef4c0ba42af477e9e445c9883cc45cf9e6
> > Author: Stefano Stabellini <stefano.stabellini@eu.citrix.com>
> > Date: Fri Dec 18 15:44:58 2015 +0000
> >
> > xen/blkif: Avoid double access to src->nr_segments
> >
> > src is stored in shared memory and src->nr_segments is dereferenced
> > twice at the end of the function. If a compiler decides to compile
> > this
> > into two separate memory accesses then the size limitation could be
> > bypassed.
> >
> > Fix it by removing the double access to src->nr_segments.
> >
> > This is part of XSA-155.
> >
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 11:22 ` Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL) Ian Campbell
@ 2016-01-07 11:45 ` Jan Beulich
2016-01-07 12:00 ` Ian Campbell
2016-01-07 12:44 ` Lars Kurth
2016-01-22 9:22 ` Ian Campbell
1 sibling, 2 replies; 12+ messages in thread
From: Jan Beulich @ 2016-01-07 11:45 UTC (permalink / raw)
To: Ian Campbell, WeiLiu, Ian Jackson, Stefano Stabellini
Cc: xen-devel, Lars Kurth
>>> On 07.01.16 at 12:22, <ian.campbell@citrix.com> wrote:
> So this arose because Stefano was unaware that 4.2 was no longer supported.
> Neither am I ever confident about where the cut-off lie, e.g. I always have
> to ask if I am doing backports for a security issue.
>
> We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features right
> under Initial Release giving first the date until which that tree is
> supported with backports and second the date until which security support
> will exist. We might also want to add a third "status" row. e.g.
> "Supported", "Security Support only", "EOL" (we'll deal with extended
> support by a third party when that next arises).
>
> I'm happy to make the edits, however I don't know what dates I would write
> here. Taking it to be 18 months of Support and a further 18 months of
> security support I would get:
>
> Xen 4.0 Xen 4.1 Xen 4.2 Xen 4.3 Xen 4.4 Xen 4.5 Xen 4.6
> Initial Release 7 April 2010 25 March 2011 17 Sept 2012 9 July 2013 10 March
> 2014 15 Jan 2015 13 Oct 2015
> Supported until EOL - ??? EOL - ??? EOL - ??? EOL - Jan 2015 EOL - Sept 2015 July
> 2016 April 2017
> Security support til EOL - ??? EOL - ??? EOL - ??? July 2016 March 2016 Jan
> 2017 Oct 2018
4.4 is going to have normal support ended with the 4.4.4 release only;
4.4.3 got released a little too early from that perspective.
> (maybe those EOLs - ??? could be whatever the respective dates were, I
> didn't try and backtrack to try and find out if reality matched the plan)
At least for the older ones it's probably not worth to reconstruct. 4.2 had
its security support ended in Sept 2015.
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 11:45 ` Jan Beulich
@ 2016-01-07 12:00 ` Ian Campbell
2016-01-07 13:12 ` Jan Beulich
2016-01-07 16:02 ` Ian Jackson
2016-01-07 12:44 ` Lars Kurth
1 sibling, 2 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-07 12:00 UTC (permalink / raw)
To: Jan Beulich, WeiLiu, Ian Jackson, Stefano Stabellini
Cc: xen-devel, Lars Kurth
On Thu, 2016-01-07 at 04:45 -0700, Jan Beulich wrote:
> > > > On 07.01.16 at 12:22, <ian.campbell@citrix.com> wrote:
> > So this arose because Stefano was unaware that 4.2 was no longer
> > supported.
> > Neither am I ever confident about where the cut-off lie, e.g. I always
> > have
> > to ask if I am doing backports for a security issue.
> >
> > We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features
> > right
> > under Initial Release giving first the date until which that tree is
> > supported with backports and second the date until which security
> > support
> > will exist. We might also want to add a third "status" row. e.g.
> > "Supported", "Security Support only", "EOL" (we'll deal with extended
> > support by a third party when that next arises).
> >
> > I'm happy to make the edits, however I don't know what dates I would
> > write
> > here. Taking it to be 18 months of Support and a further 18 months of
> > security support I would get:
> >
> > Xen 4.0 Xen 4.1 Xen 4.2 Xen 4.3 Xen 4.4 Xen 4.5 Xen 4.6
> > Initial Release 7 April 2010 25 March 2011 17 Sept 2012 9 July 2013 10 March
> > 2014 15 Jan 2015 13 Oct 2015
> > Supported until EOL - ??? EOL - ??? EOL - ??? EOL - Jan 2015 EOL - Sept 2015 July
> > 2016 April 2017
> > Security support til EOL - ??? EOL - ??? EOL - ??? July 2016 March 2016 Jan
> > 2017 Oct 2018
>
> 4.4 is going to have normal support ended with the 4.4.4 release only;
> 4.4.3 got released a little too early from that perspective.
Meaning it will be earlier later than September 2015.
4.4.3 was released in August which was too soon.
I think it is right to err on the side of stopping later than we said.
Did we stop adding backports to staging-4.4 in September, i.e. is 4.4.4
going to be fixes from August-September + security issues until the release
date?
>
> > (maybe those EOLs - ??? could be whatever the respective dates were, I
> > didn't try and backtrack to try and find out if reality matched the
> > plan)
>
> At least for the older ones it's probably not worth to reconstruct. 4.2
> had
> its security support ended in Sept 2015.
Thanks.
>
> Jan
>
>
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.xen.org
> http://lists.xen.org/xen-devel
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 11:45 ` Jan Beulich
2016-01-07 12:00 ` Ian Campbell
@ 2016-01-07 12:44 ` Lars Kurth
2016-01-07 13:09 ` Ian Campbell
1 sibling, 1 reply; 12+ messages in thread
From: Lars Kurth @ 2016-01-07 12:44 UTC (permalink / raw)
To: Jan Beulich
Cc: xen-devel, WeiLiu, Ian Campbell, Stefano Stabellini, Ian Jackson,
Lars Kurth
> On 7 Jan 2016, at 11:45, Jan Beulich <JBeulich@suse.com> wrote:
>
>>>> On 07.01.16 at 12:22, <ian.campbell@citrix.com> wrote:
>> So this arose because Stefano was unaware that 4.2 was no longer supported.
>> Neither am I ever confident about where the cut-off lie, e.g. I always have
>> to ask if I am doing backports for a security issue.
>>
>> We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features right
>> under Initial Release giving first the date until which that tree is
>> supported with backports and second the date until which security support
>> will exist. We might also want to add a third "status" row. e.g.
>> "Supported", "Security Support only", "EOL" (we'll deal with extended
>> support by a third party when that next arises).
>>
>> I'm happy to make the edits, however I don't know what dates I would write
>> here. Taking it to be 18 months of Support and a further 18 months of
>> security support I would get:
Ian, that would be great. Can you ping me when done?
I still have an open action to come up with an approach to include information in this table in in-tree documentation
Lars
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 12:44 ` Lars Kurth
@ 2016-01-07 13:09 ` Ian Campbell
0 siblings, 0 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-07 13:09 UTC (permalink / raw)
To: Lars Kurth, Jan Beulich
Cc: Ian Jackson, xen-devel, WeiLiu, Lars Kurth, Stefano Stabellini
On Thu, 2016-01-07 at 12:44 +0000, Lars Kurth wrote:
> > On 7 Jan 2016, at 11:45, Jan Beulich <JBeulich@suse.com> wrote:
> >
> > > > > On 07.01.16 at 12:22, <ian.campbell@citrix.com> wrote:
> > > So this arose because Stefano was unaware that 4.2 was no longer
> > > supported.
> > > Neither am I ever confident about where the cut-off lie, e.g. I
> > > always have
> > > to ask if I am doing backports for a security issue.
> > >
> > > We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features
> > > right
> > > under Initial Release giving first the date until which that tree is
> > > supported with backports and second the date until which security
> > > support
> > > will exist. We might also want to add a third "status" row. e.g.
> > > "Supported", "Security Support only", "EOL" (we'll deal with extended
> > > support by a third party when that next arises).
> > >
> > > I'm happy to make the edits, however I don't know what dates I would
> > > write
> > > here. Taking it to be 18 months of Support and a further 18 months of
> > > security support I would get:
>
> Ian, that would be great. Can you ping me when done?
Done.
I dropped the "EOL - " prefixes, since it seems that if we forget to add
them as new things are EOL'd then there would be ambiguity between things
marked "EOL - Date" and things marked as just "Date" where Date is in the
past -- i.e. folks might think the EOL didn't occur.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 12:00 ` Ian Campbell
@ 2016-01-07 13:12 ` Jan Beulich
2016-01-07 16:02 ` Ian Jackson
1 sibling, 0 replies; 12+ messages in thread
From: Jan Beulich @ 2016-01-07 13:12 UTC (permalink / raw)
To: Ian Campbell, WeiLiu, IanJackson, Stefano Stabellini
Cc: xen-devel, Lars Kurth
>>> On 07.01.16 at 13:00, <ian.campbell@citrix.com> wrote:
> On Thu, 2016-01-07 at 04:45 -0700, Jan Beulich wrote:
>> > > > On 07.01.16 at 12:22, <ian.campbell@citrix.com> wrote:
>> > So this arose because Stefano was unaware that 4.2 was no longer
>> > supported.
>> > Neither am I ever confident about where the cut-off lie, e.g. I always
>> > have
>> > to ask if I am doing backports for a security issue.
>> >
>> > We should add rows to http://wiki.xen.org/wiki/Xen_Release_Features
>> > right
>> > under Initial Release giving first the date until which that tree is
>> > supported with backports and second the date until which security
>> > support
>> > will exist. We might also want to add a third "status" row. e.g.
>> > "Supported", "Security Support only", "EOL" (we'll deal with extended
>> > support by a third party when that next arises).
>> >
>> > I'm happy to make the edits, however I don't know what dates I would
>> > write
>> > here. Taking it to be 18 months of Support and a further 18 months of
>> > security support I would get:
>> >
>> > Xen 4.0 Xen 4.1 Xen 4.2 Xen 4.3 Xen 4.4 Xen 4.5 Xen 4.6
>> > Initial Release 7 April 2010 25 March 2011 17 Sept 2012 9 July 2013 10
> March
>> > 2014 15 Jan 2015 13 Oct 2015
>> > Supported until EOL - ??? EOL - ??? EOL - ??? EOL - Jan 2015 EOL - Sept 2015 July
>
>> > 2016 April 2017
>> > Security support til EOL - ??? EOL - ??? EOL - ??? July 2016 March 2016 Jan
>> > 2017 Oct 2018
>>
>> 4.4 is going to have normal support ended with the 4.4.4 release only;
>> 4.4.3 got released a little too early from that perspective.
>
> Meaning it will be earlier later than September 2015.
>
> 4.4.3 was released in August which was too soon.
>
> I think it is right to err on the side of stopping later than we said.
>
> Did we stop adding backports to staging-4.4 in September, i.e. is 4.4.4
> going to be fixes from August-September + security issues until the release
> date?
No, there was active backporting until December (and I expect to at
least put in Andrew's XSA-156 fixup before 4.4.4 goes out, which -
due to the osstest issues - is going to take a little more time anyway).
Jan
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 12:00 ` Ian Campbell
2016-01-07 13:12 ` Jan Beulich
@ 2016-01-07 16:02 ` Ian Jackson
1 sibling, 0 replies; 12+ messages in thread
From: Ian Jackson @ 2016-01-07 16:02 UTC (permalink / raw)
To: Ian Campbell
Cc: xen-devel, Wei Liu, Lars Kurth, Jan Beulich, Stefano Stabellini
Ian Campbell writes ("Re: [Xen-devel] Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)"):
> Did we stop adding backports to staging-4.4 in September, i.e. is 4.4.4
> going to be fixes from August-September + security issues until the release
> date?
My usual approach with backports is to apply them back until either
(a) they don't apply or
(b) I reach the first tree which is out of security support.
In the case (a) I make a personal decision whether to either (i) spend
my own effort adapting the backport or (ii) tell someone (the
submitter, often) and give them the opportunity to supply a backport.
In both cases (a) and (b), the nominal support status of the old tree
is a factor, but not determinative.
I avoid making /any/ changes to trees which are out of security
support, to avoid giving them the appearance of being alive.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL
2016-01-07 9:56 ` Ian Campbell
2016-01-07 11:22 ` Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL) Ian Campbell
@ 2016-01-08 12:10 ` Ian Jackson
2016-01-14 9:54 ` Ian Campbell
1 sibling, 1 reply; 12+ messages in thread
From: Ian Jackson @ 2016-01-08 12:10 UTC (permalink / raw)
To: Ian Campbell; +Cc: xen-devel, osstest service owner, Stefano Stabellini
Ian Campbell writes ("Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL"):
> So our choices WRT these fixes in qemu-xen.git#staging-4.2, given they have
> already been pushed, are:
>
> 4. Force push.
We (Ian C, Stefano and myself) had a conversation in which we decided
that this was probably the best option. But we will wait for the
other qemuu trees to pass their push gates so only 4.2 is outstanding,
to avoid force pushing any other problems.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL
2016-01-08 12:10 ` [qemu-upstream-4.2-testing test] 77180: regressions - FAIL Ian Jackson
@ 2016-01-14 9:54 ` Ian Campbell
0 siblings, 0 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-14 9:54 UTC (permalink / raw)
To: Ian Jackson; +Cc: xen-devel, osstest service owner, Stefano Stabellini
On Fri, 2016-01-08 at 12:10 +0000, Ian Jackson wrote:
> Ian Campbell writes ("Re: [qemu-upstream-4.2-testing test] 77180:
> regressions - FAIL"):
> > So our choices WRT these fixes in qemu-xen.git#staging-4.2, given they
> > have
> > already been pushed, are:
> >
> > 4. Force push.
>
> We (Ian C, Stefano and myself) had a conversation in which we decided
> that this was probably the best option. But we will wait for the
> other qemuu trees to pass their push gates so only 4.2 is outstanding,
> to avoid force pushing any other problems.
Judging from http://logs.test-lab.xenproject.org/osstest/results/all-branch
-statuses.txt now is the time, all of xen-4.X-testing and qemu-upstream-
4.X-testing are up to date apart from this one branch.
From the original 77180 report:
version targeted for testing:
qemuu 5081fc1c773d2a83ec7a867f030323b8b6956cd1
baseline version:
qemuu c17e602ae64fb24405ebd256679ba9a6f5819086
Thus:
(test-lab)osstest@osstest:~/branches/for-qemu-upstream-4.2-testing.git$ OSSTEST_CONFIG=production-config ./ap-push qemu-upstream-4.2-testing 5081fc1c773d2a83ec7a867f030323b8b6956cd1
+ branch=qemu-upstream-4.2-testing
+ revision=5081fc1c773d2a83ec7a867f030323b8b6956cd1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x '!=' x/home/osstest/repos/lock ']'
++ OSSTEST_REPOS_LOCK_LOCKED=/home/osstest/repos/lock
++ exec with-lock-ex -w /home/osstest/repos/lock ./ap-push qemu-upstream-4.2-testing 5081fc1c773d2a83ec7a867f030323b8b6956cd1
+ branch=qemu-upstream-4.2-testing
+ revision=5081fc1c773d2a83ec7a867f030323b8b6956cd1
+ . ./cri-lock-repos
++ . ./cri-common
+++ . ./cri-getconfig
+++ umask 002
+++ getrepos
++++ getconfig Repos
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"Repos"} or die $!;
'
+++ local repos=/home/osstest/repos
+++ '[' -z /home/osstest/repos ']'
+++ '[' '!' -d /home/osstest/repos ']'
+++ echo /home/osstest/repos
++ repos=/home/osstest/repos
++ repos_lock=/home/osstest/repos/lock
++ '[' x/home/osstest/repos/lock '!=' x/home/osstest/repos/lock ']'
+ . ./cri-common
++ . ./cri-getconfig
++ umask 002
+ select_xenbranch
+ case "$branch" in
+ tree=qemuu
+ xenbranch=xen-4.2-testing
+ '[' xqemuu = xlinux ']'
+ linuxbranch=
+ '[' x = x ']'
+ qemuubranch=qemu-upstream-4.2-testing
+ select_prevxenbranch
++ ./cri-getprevxenbranch xen-4.2-testing
+ prevxenbranch=xen-4.1-testing
+ '[' x5081fc1c773d2a83ec7a867f030323b8b6956cd1 = x ']'
+ : tested/2.6.39.x
+ . ./ap-common
++ : osstest@xenbits.xen.org
+++ getconfig OsstestUpstream
+++ perl -e '
use Osstest;
readglobalconfig();
print $c{"OsstestUpstream"} or die $!;
'
++ :
++ : git://xenbits.xen.org/xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/xen.git
++ : git://xenbits.xen.org/qemu-xen-traditional.git
++ : git://git.kernel.org
++ : git://git.kernel.org/pub/scm/linux/kernel/git
++ : git
++ : git://libvirt.org/libvirt.git
++ : osstest@xenbits.xen.org:/home/xen/git/libvirt.git
++ : git://xenbits.xen.org/libvirt.git
++ : https://github.com/rumpkernel/rumprun-xen
++ : git
++ : git://xenbits.xen.org/rumpuser-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+++ besteffort_repo https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ cached_repo https://github.com/rumpkernel/rumpkernel-netbsd-src '[fetch=try]'
+++ local repo=https://github.com/rumpkernel/rumpkernel-netbsd-src
+++ local 'options=[fetch=try]'
++++ getconfig GitCacheProxy
++++ perl -e '
use Osstest;
readglobalconfig();
print $c{"GitCacheProxy"} or die $!;
'
+++ local cache=git://cache:9419/
+++ '[' xgit://cache:9419/ '!=' x ']'
+++ echo 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : 'git://cache:9419/https://github.com/rumpkernel/rumpkernel-netbsd-src%20[fetch=try]'
++ : git
++ : git://git.seabios.org/seabios.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
++ : git://xenbits.xen.org/osstest/seabios.git
++ : https://github.com/tianocore/edk2.git
++ : osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/ovmf.git
++ : git://xenbits.xen.org/osstest/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/osstest/ext/linux-firmware.git
++ : git://git.kernel.org/pub/scm/linux/kernel/git/firmware/linux-firmware.git
++ : osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ : tested/linux-arm-xen
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-3.14
++ '[' x = x ']'
++ : git://xenbits.xen.org/linux-pvops.git
++ : tested/linux-arm-xen
++ : git://git.kernel.org/pub/scm/linux/kernel/git/konrad/xen.git
++ : tested/2.6.39.x
++ : daily-cron.qemu-upstream-4.2-testing
++ : daily-cron.qemu-upstream-4.2-testing
++ : daily-cron.qemu-upstream-4.2-testing
++ : daily-cron.qemu-upstream-4.2-testing
++ : daily-cron.qemu-upstream-4.2-testing
++ : daily-cron.qemu-upstream-4.2-testing
++ : http://hg.uk.xensource.com/carbon/trunk/linux-2.6.27
++ : git://xenbits.xen.org/qemu-xen.git
++ : osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
++ : daily-cron.qemu-upstream-4.2-testing
++ : git://xenbits.xen.org/qemu-xen.git
++ : git://git.qemu.org/qemu.git
+ TREE_LINUX=osstest@xenbits.xen.org:/home/xen/git/linux-pvops.git
+ TREE_QEMU_UPSTREAM=osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
+ TREE_XEN=osstest@xenbits.xen.org:/home/xen/git/xen.git
+ TREE_LIBVIRT=osstest@xenbits.xen.org:/home/xen/git/libvirt.git
+ TREE_RUMPUSERXEN=osstest@xenbits.xen.org:/home/xen/git/rumpuser-xen.git
+ TREE_SEABIOS=osstest@xenbits.xen.org:/home/xen/git/osstest/seabios.git
+ TREE_OVMF=osstest@xenbits.xen.org:/home/xen/git/osstest/ovmf.git
+ info_linux_tree qemu-upstream-4.2-testing
+ case $1 in
+ return 1
+ case "$branch" in
+ branchcore=4.2-testing
+ branchcore=4.2
+ cd /home/osstest/repos/qemu-upstream-4.2-testing
+ git push osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git 5081fc1c773d2a83ec7a867f030323b8b6956cd1:refs/heads/stable-4.2
Total 0 (delta 0), reused 0 (delta 0)
To osstest@xenbits.xen.org:/home/xen/git/qemu-xen.git
c17e602..5081fc1 5081fc1c773d2a83ec7a867f030323b8b6956cd1 -> stable-4.2
+ case "$branchcore" in
+ tree=osstest@xenbits.xen.org:/home/xen/git/qemu-upstream-4.2-testing.git
+ git push osstest@xenbits.xen.org:/home/xen/git/qemu-upstream-4.2-testing.git 5081fc1c773d2a83ec7a867f030323b8b6956cd1:refs/heads/master
Counting objects: 12, done.
Delta compression using up to 4 threads.
Compressing objects: 100% (8/8), done.
Writing objects: 100% (8/8), 1.30 KiB, done.
Total 8 (delta 6), reused 0 (delta 0)
To osstest@xenbits.xen.org:/home/xen/git/qemu-upstream-4.2-testing.git
c17e602..5081fc1 5081fc1c773d2a83ec7a867f030323b8b6956cd1 -> master
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.xen.org
http://lists.xen.org/xen-devel
^ permalink raw reply [flat|nested] 12+ messages in thread
* Re: Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)
2016-01-07 11:22 ` Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL) Ian Campbell
2016-01-07 11:45 ` Jan Beulich
@ 2016-01-22 9:22 ` Ian Campbell
1 sibling, 0 replies; 12+ messages in thread
From: Ian Campbell @ 2016-01-22 9:22 UTC (permalink / raw)
To: Ian Jackson, Stefano Stabellini, Jan Beulich, Wei Liu
Cc: xen-devel, Lars Kurth
On Thu, 2016-01-07 at 11:22 +0000, Ian Campbell wrote:
> So this arose because Stefano was unaware that 4.2 was no longer
> supported.
> Neither am I ever confident about where the cut-off lie, e.g. I
> always have
> to ask if I am doing backports for a security issue.
>
> We should add rows to
> http://wiki.xen.org/wiki/Xen_Release_Features right
> under Initial Release giving first the date until which that tree is
> supported with backports and second the date until which security
> support
> will exist. We might also want to add a third "status" row. e.g.
> "Supported", "Security Support only", "EOL" (we'll deal with extended
> support by a third party when that next arises).
>
> I'm happy to make the edits, however I don't know what dates I would
> write
> here. Taking it to be 18 months of Support and a further 18 months of
> security support I would get:
> Xen 4.0 Xen 4.1 Xen 4.2 Xen 4.3 Xen 4.4 Xen 4.5 Xen 4.6
> Initial Release 7 April 2010 25 March 2011 17 Sept 2012 9 July 2013 10 March 2014 15 Jan 2015 13 Oct 2015
> Supported until EOL - ??? EOL - ??? EOL - ??? EOL - Jan 2015 EOL - Sept 2015 July 2016 April 2017
> Security support til EOL - ??? EOL - ??? EOL - ??? July 2016 March 2016 Jan 2017 Oct 2018
George pointed out that 4.4 only has 6 months security support here,
which is just me counting wrong I think. It should be March 2017.
Likewise 4.5 followed suite.
Both of them should have been 1 year later. I have updated the wiki.
Ian.
^ permalink raw reply [flat|nested] 12+ messages in thread
end of thread, other threads:[~2016-01-22 9:22 UTC | newest]
Thread overview: 12+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2016-01-06 18:28 [qemu-upstream-4.2-testing test] 77180: regressions - FAIL osstest service owner
2016-01-07 9:56 ` Ian Campbell
2016-01-07 11:22 ` Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL) Ian Campbell
2016-01-07 11:45 ` Jan Beulich
2016-01-07 12:00 ` Ian Campbell
2016-01-07 13:12 ` Jan Beulich
2016-01-07 16:02 ` Ian Jackson
2016-01-07 12:44 ` Lars Kurth
2016-01-07 13:09 ` Ian Campbell
2016-01-22 9:22 ` Ian Campbell
2016-01-08 12:10 ` [qemu-upstream-4.2-testing test] 77180: regressions - FAIL Ian Jackson
2016-01-14 9:54 ` Ian Campbell
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.