[libvirt test] 59948: regressions - FAIL

[libvirt test] 59948: regressions - FAIL

[osstest service owner]

flight 59948 libvirt real [real]
http://logs.test-lab.xenproject.org/osstest/logs/59948/

Regressions :-(

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

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

version targeted for testing:
 libvirt              e14310724071d5853ae5ca612756dfc6b156642e
baseline version:
 libvirt              be6c35e4acdff92c9f9a875de28474a84367f742

Last test of basis    59907  2015-07-25 10:30:59 Z    0 days
Testing same since    59948  2015-07-26 04:19:54 Z    0 days    1 attempts

------------------------------------------------------------
People who touched revisions under test:
  Laine Stump <laine@laine.org>

jobs:
 build-amd64-xsm                                              pass    
 build-armhf-xsm                                              pass    
 build-i386-xsm                                               pass    
 build-amd64                                                  pass    
 build-armhf                                                  pass    
 build-i386                                                   pass    
 build-amd64-libvirt                                          pass    
 build-armhf-libvirt                                          pass    
 build-i386-libvirt                                           pass    
 build-amd64-pvops                                            pass    
 build-armhf-pvops                                            fail    
 build-i386-pvops                                             fail    
 test-amd64-amd64-libvirt-xsm                                 pass    
 test-armhf-armhf-libvirt-xsm                                 blocked 
 test-amd64-i386-libvirt-xsm                                  blocked 
 test-amd64-amd64-libvirt                                     pass    
 test-armhf-armhf-libvirt                                     blocked 
 test-amd64-i386-libvirt                                      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 e14310724071d5853ae5ca612756dfc6b156642e
Author: Laine Stump <laine@laine.org>
Date:   Thu Jun 25 12:55:12 2015 -0400

    conf: add virDomainControllerDefNew()
    
    There are some non-0 default values in virDomainControllerDef (and
    will soon be more) that are easier to not forget if the remembering is
    done by a single initializer function (rather than inline code after
    allocating the obejct with generic VIR_ALLOC().

commit 0726878297c75da15052df3b16d76c7abfd76013
Author: Laine Stump <laine@laine.org>
Date:   Thu Jun 25 12:02:32 2015 -0400

    qemu: reorganize loop in qemuDomainAssignPCIAddresses
    
    This loop occurs just after we've assured that all devices that
    require a PCI device have been assigned and all necessary PCI
    controllers have been added. It is the perfect place to add other
    potentially auto-generated PCI controller attributes that are
    dependent on the controller's PCI address (upcoming patch).
    
    There is a convenient loop through all controllers at the end of the
    function, but the patch to add new functionality will be cleaner if we
    first rearrange that loop a bit.
    
    Note that the loop originally was accessing info.addr.pci.bus prior to
    determining that the pci part of the object was valid. This isn't
    dangerous in any way, but seemed a bit ugly, so I fixed it.

commit d4cf72af175dec9ee09b171605409df7000f8356
Author: Laine Stump <laine@laine.org>
Date:   Thu Jul 16 16:28:47 2015 -0400

    conf: pay attention to bus minSlot/maxSlot when autoassigning PCI addresses
    
    The function that auto-assigns PCI addresses was written with the
    hardcoded assumptions that any PCI bus would have slots available
    starting at 1 and ending at 31. This isn't true for many types of
    controllers (some have a single slot/port at 0, some have slots/ports
    from 0 to 31). This patch updates that function to remove the
    hardcoded assumptions. It will properly find/assign addresses for
    devices that can only connect to pcie-(root|downstream)-port (which
    have minSlot/maxSlot of 0/0) or a pcie-switch-upstream-port (0/31).
    
    It still will not auto-create a new bus of the proper kind for these
    connections when one doesn't exist, that task is for another day.