[qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[osstest service owner]

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>

Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[Ian Campbell]

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

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

[Ian Campbell]

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

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

[Jan Beulich]

>>> 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

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

[Ian Campbell]

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

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

[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

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

[Ian Campbell]

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.

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

[Jan Beulich]

>>> 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

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

[Ian Jackson]

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.

Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[Ian Jackson]

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.

Re: [qemu-upstream-4.2-testing test] 77180: regressions - FAIL

[Ian Campbell]

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

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

[Ian Campbell]

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.