Build Update for libvirt/libvirt
-------------------------------------
Build: #1317
Status: Errored
Duration: 18 mins and 19 secs
Commit: d7ca39e (master)
Author: Peter Krempa
Message: qemu: Fix detaching from persistent def in qemuDomainDetachDeviceAliasLiveAndConfig
The code that detaches the device from persistent definition copies the
persistent definition first so that it can easily be rolled back. The
actual detaching is then made in the copy which is assigned back on
success (if the live operation succeeded as well).
This is not the case in qemuDomainDetachDeviceAliasLiveAndConfig where
the definition was copied and put back, but the detaching happened from
the other object which was overwritten.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
View the changeset: https://github.com/libvirt/libvirt/compare/234ce7d02f4b...d7ca39e0fb7f
View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/388360033?utm_source=email&u...
--
You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications
This email was sent to libvirt-ci(a)redhat.com (mailto:libvirt-ci@redhat.com)
unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=32e9435328c64c2...)
Build Update for libvirt/libvirt
-------------------------------------
Build: #1311
Status: Still Failing
Duration: 22 mins and 4 secs
Commit: 968aaff (master)
Author: Michal Privoznik
Message: virDomainDefCopy: Skip ostype checks
When parsing domain XML the virCapsDomainData lookup is performed
in order to fill in missing def->os.arch and def->os.machine
strings. Well, when doing copy of already existing virDomainDef
we don't want any automagic fill in of defaults (and those two
strings are going to be provided at this point anyway by first
parse of the domain XML).
What is even worse is that we do not look up capabilities for
parsed emulator path rather some generic capabilities for parsed
arch. Therefore, if emulator points to qemu under non-default
path (say $HOME/qemu-system-arm) but there's no such qemu under
the default path (say /usr/bin/qemu-system-arm) the capabilities
lookup fails and creating the copy is denied.
Signed-off-by: Michal Privoznik <mprivozn(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
View the changeset: https://github.com/libvirt/libvirt/compare/6549c3a4d10b...968aaff77a09
View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/388149323?utm_source=email&u...
--
You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications
This email was sent to libvirt-ci(a)redhat.com (mailto:libvirt-ci@redhat.com)
unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=dc58a5bb6c5d496...)
Build Update for libvirt/libvirt
-------------------------------------
Build: #1309
Status: Broken
Duration: 20 mins and 29 secs
Commit: 134c3dd (master)
Author: Peter Krempa
Message: qemu: command: Refactor disk commandline formatting
Now that we have one place that sets up all disk-related objects to
qemuBlockStorageSourceAttachDataPtr we can easily reuse the data in the
command-line formatter by implementing a worker which will convert the
data.
A huge advantage is that it will be way easier to integrate this with
-blockdev later on.
Signed-off-by: Peter Krempa <pkrempa(a)redhat.com>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
View the changeset: https://github.com/libvirt/libvirt/compare/09e44dcaaa85...134c3ddb436a
View the full build log and details: https://travis-ci.org/libvirt/libvirt/builds/388128670?utm_source=email&u...
--
You can configure recipients for build notifications in your .travis.yml file. See https://docs.travis-ci.com/user/notifications
This email was sent to libvirt-ci(a)redhat.com (mailto:libvirt-ci@redhat.com)
unsubscribe from this list (http://clicks.travis-ci.com/track/unsub.php?u=14313403&id=e66a7c58fbde43e...)