[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

[Xen-devel] [libvirt test] 30154: regressions - FAIL



flight 30154 libvirt real [real]
http://www.chiark.greenend.org.uk/~xensrcts/logs/30154/

Regressions :-(

Tests which did not succeed and are blocking,
including tests which could not be run:
 build-armhf-libvirt           5 libvirt-build             fail REGR. vs. 30147
 build-i386-libvirt            5 libvirt-build             fail REGR. vs. 30147

Tests which did not succeed, but are not blocking:
 test-amd64-i386-libvirt       1 build-check(1)               blocked  n/a
 test-armhf-armhf-libvirt      1 build-check(1)               blocked  n/a
 test-amd64-amd64-libvirt      9 guest-start                  fail   never pass

version targeted for testing:
 libvirt              a48362cdfeb5c948218a2e4bf7cc9354082fc1b6
baseline version:
 libvirt              0eaad0a39c67bdddc56d608ff28fcb490c12b8b3

------------------------------------------------------------
People who touched revisions under test:
  Eric Blake <eblake@xxxxxxxxxx>
  Shivaprasad G Bhat <sbhat@xxxxxxxxxxxxxxxxxx>
  Shivaprasad G Bhat <shivaprasadbhat@xxxxxxxxx>
------------------------------------------------------------

jobs:
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          fail    
 build-i386-libvirt                                           fail    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            pass    
 build-i386-pvops                                             pass    
 test-amd64-amd64-libvirt                                     fail    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      blocked 


------------------------------------------------------------
sg-report-flight on osstest.cam.xci-test.com
logs: /home/xc_osstest/logs
images: /home/xc_osstest/images

Logs, config files, etc. are available at
    http://www.chiark.greenend.org.uk/~xensrcts/logs

Test harness code can be found at
    http://xenbits.xensource.com/gitweb?p=osstest.git;a=summary


Not pushing.

------------------------------------------------------------
commit a48362cdfeb5c948218a2e4bf7cc9354082fc1b6
Author: Shivaprasad G Bhat <shivaprasadbhat@xxxxxxxxx>
Date:   Thu Sep 4 14:42:32 2014 +0530

    selinux: Avoid label reservations for type = none
    
    For security type='none' libvirt according to the docs should not
    generate seclabel be it for selinux or any model. So, skip the
    reservation of labels when type is none.
    
    Signed-off-by: Shivaprasad G Bhat <sbhat@xxxxxxxxxxxxxxxxxx>

commit 1069e3b90cd0b1b12eee18b977318fc30b0fabce
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Sat Aug 23 20:09:56 2014 -0600

    blockcopy: remote implementation for new API
    
    Fairly straightforward - I got lucky that the generated functions
    worked out of the box :)
    
    * src/remote/remote_protocol.x (remote_domain_block_copy_args):
    New struct.
    (REMOTE_PROC_DOMAIN_BLOCK_COPY): New RPC.
    * src/remote/remote_driver.c (remote_driver): Wire it up.
    * src/remote_protocol-structs: Regenerate.
    
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit c1d75deea228e7f4a7462aef143e18c456b2a82c
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Fri Aug 29 15:47:28 2014 -0600

    blockcopy: expose new API in virsh
    
    Expose the new power of virDomainBlockCopy through virsh (well,
    all but the finer-grained bandwidth, as that is its own can of
    worms for a later patch).  Continue to use the older API where
    possible, for maximum compatibility.
    
    The command now requires either --dest (with optional --format
    and --blockdev), to directly describe the file destination, or
    --xml, to name a file that contains an XML description such as:
    
    <disk type='network'>
      <driver type='raw'/>
      <source protocol='gluster' name='vol1/img'>
        <host name='red'/>
      </source>
    </disk>
    
    [well, it may be a while before the qemu driver is actually patched
    to act on that particular xml beyond just parsing it, but the virsh
    interface won't need changing at that time]
    
    Non-zero option parameters are converted into virTypedParameters,
    and if anything requires the new API, the command can synthesize
    appropriate XML even if the --dest option was used instead of --xml.
    
    The existing --raw flag remains for back-compat, but the preferred
    spelling is now --format=raw, since the new API now allows us
    to specify all formats rather than just a boolean raw to suppress
    probing.
    
    I hope I did justice in describing the effects of granularity and
    buf-size on how they get passed through to qemu.
    
    * tools/virsh-domain.c (cmdBlockCopy): Add new options --xml,
    --granularity, --buf-size, --format. Make --raw an alias for
    --format=raw. Call new API if new parameters are in use.
    * tools/virsh.pod (blockcopy): Document new options.
    
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

commit 0e8bed817705664764db408c93ba54277ef85157
Author: Eric Blake <eblake@xxxxxxxxxx>
Date:   Thu Sep 4 06:39:54 2014 -0600

    maint: update to latest gnulib
    
    The usual portability fixes; and this includes a fix that adds
    a new syntax check for double semicolons (commit 28de556 fixed
    some, but gnulib found a better check).
    
    * .gnulib: Update to latest.
    * src/xenconfig/xen_common.c (xenFormatConfigCommon): Fix offender.
    
    Signed-off-by: Eric Blake <eblake@xxxxxxxxxx>

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


 


Rackspace

Lists.xenproject.org is hosted with RackSpace, monitoring our
servers 24x7x365 and backed by RackSpace's Fanatical Support®.