Which trees are supported (Was: Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL)

[Ian Campbell <ian.campbell@citrix.com>]

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