- Devel - libvirt List Archives

[libvirt] [PATCH 0/6] Revert: 'IP peer address and host-side address config support'
by Ján Tomko 02 Jul '16

02 Jul '16

This series was accidentally pushed in the feature freeze. Revert the last six commits adding the new functionality. The rest are either bugfixes or preparation for the bugfixes. Ján Tomko (6): Revert "qemu: support setting host-side IP addresses/routes" Revert "lxc: support setting host-side IP addresses/routes" Revert "util: support setting peer for virNetDevIPInfo addresses" Revert "conf: support host-side IP/route information in <interface>" Revert "conf: allow setting peer address in <ip> element of <interface>" Revert "util: new function virNetDevIPInfoAddToDev" docs/formatdomain.html.in | 60 +++-------- docs/schemas/domaincommon.rng | 8 +- src/conf/domain_conf.c | 117 ++++----------------- src/conf/domain_conf.h | 3 +- src/libvirt_private.syms | 1 - src/lxc/lxc_container.c | 47 +++++++-- src/lxc/lxc_process.c | 8 -- src/qemu/qemu_interface.c | 6 +- src/util/virnetdevip.c | 60 ----------- src/util/virnetdevip.h | 7 +- tests/lxcxml2xmldata/lxc-ethernet-hostip.xml | 44 -------- tests/lxcxml2xmltest.c | 1 - .../qemuxml2argv-net-eth-hostip.args | 23 ---- .../qemuxml2argv-net-eth-hostip.xml | 39 ------- tests/qemuxml2argvtest.c | 1 - .../qemuxml2xmlout-net-eth-hostip.xml | 44 -------- tests/qemuxml2xmltest.c | 1 - 17 files changed, 75 insertions(+), 395 deletions(-) delete mode 100644 tests/lxcxml2xmldata/lxc-ethernet-hostip.xml delete mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-eth-hostip.args delete mode 100644 tests/qemuxml2argvdata/qemuxml2argv-net-eth-hostip.xml delete mode 100644 tests/qemuxml2xmloutdata/qemuxml2xmlout-net-eth-hostip.xml -- 2.7.3

2 9

[libvirt] CPU topology and ordering in ACPI MADT
by Eduardo Habkost 02 Jul '16

02 Jul '16

I got a bug report yesterday that seems to be related to how CPUs are ordered 'lscpu' and /proc/cpuinfo: https://bugzilla.redhat.com/show_bug.cgi?id=1351160 It's not an actual bug, but it's not the first time I see people confused by CPU numbers not following socket/core/thread IDs in lscpu and /proc/cpuinfo in the host (making CPU numbers seen in the guest not matching CPU numbers in the host). The ordering in /proc/cpuinfo and lscpu seems to come from the MADT ACPI table, and on some hosts it looks completely arbitrary[1]. Now that we will allow the APIC ID (or socket/core/thread IDs) to be explicitly set in each VCPU, we could let management make CPU ordering match the host exactly, for people that really want to reproduce the host topology and get easily confused by CPU numbers that don't match the host. But this is lot of data to be provided to QEMU, so I don't see it as an useful feature unless it can be represented in the libvirt XML configuration in a more compact way, or generated automatically based on the host. I'm CCing libvir-list to see if they have any ideas. ...or we could just tell users that sometimes it will be impossible to make the CPU numbers in the guest match the ones in the host. To be honest, I am more inclined towards this option, but I would like to hear your opinions. [1] Example of lscpu output from a host that doesn't follow socket/core/thread ID on the MADT table: # lscpu -e CPU NODE SOCKET CORE L1d:L1i:L2:L3 ONLINE 0 1 0 0 0:0:0:0 yes 1 0 1 1 1:1:1:1 yes 2 1 0 2 2:2:2:0 yes 3 0 1 3 3:3:3:1 yes 4 1 0 4 4:4:4:0 yes 5 0 1 5 5:5:5:1 yes 6 1 0 6 6:6:6:0 yes 7 0 1 7 7:7:7:1 yes 8 1 0 8 8:8:8:0 yes 9 0 1 9 9:9:9:1 yes 10 1 0 10 10:10:10:0 yes 11 0 1 11 11:11:11:1 yes 12 1 0 0 0:0:0:0 yes 13 0 1 1 1:1:1:1 yes 14 1 0 2 2:2:2:0 yes 15 0 1 3 3:3:3:1 yes 16 1 0 4 4:4:4:0 yes 17 0 1 5 5:5:5:1 yes 18 1 0 6 6:6:6:0 yes 19 0 1 7 7:7:7:1 yes 20 1 0 8 8:8:8:0 yes 21 0 1 9 9:9:9:1 yes 22 1 0 10 10:10:10:0 yes 23 0 1 11 11:11:11:1 yes # lscpu Architecture: x86_64 CPU op-mode(s): 32-bit, 64-bit Byte Order: Little Endian CPU(s): 24 On-line CPU(s) list: 0-23 Thread(s) per core: 2 Core(s) per socket: 6 Socket(s): 2 NUMA node(s): 2 Vendor ID: GenuineIntel CPU family: 6 Model: 44 Model name: Intel(R) Xeon(R) CPU L5640 @ 2.27GHz Stepping: 2 CPU MHz: 2266.000 BogoMIPS: 4533.26 Virtualization: VT-x L1d cache: 32K L1i cache: 32K L2 cache: 256K L3 cache: 12288K NUMA node0 CPU(s): 1,3,5,7,9,11,13,15,17,19,21,23 NUMA node1 CPU(s): 0,2,4,6,8,10,12,14,16,18,20,22 # -- Eduardo

1 0

[libvirt] [PATCH 0/5] Some USB hotplug and alias cleanups
by John Ferlan 01 Jul '16

01 Jul '16

A post 2.0.0 type adjustment... While answering a question for bz 1289391 regarding the USB path - I figured that making the code be more the virtio and scsi code paths would at least have a better look'n'feel. Then I tripped in to the alias morass and cleaned that up a bit too. John Ferlan (5): qemu: Reorder qemuDomainAttachUSBMassStorageDevice failure path qemu: Move drive alias processing to qemu_alias qemu: Use qemuAssignDeviceDiskDriveAlias qemu: Make QEMU_DRIVE_HOST_PREFIX more private qemu: Add attempt to call qemuMonitorDriveDel for USB failure path src/qemu/qemu_alias.c | 34 +++++++++++++++++++++++++ src/qemu/qemu_alias.h | 4 +++ src/qemu/qemu_command.c | 23 ++++++++--------- src/qemu/qemu_command.h | 1 - src/qemu/qemu_domain.c | 3 +-- src/qemu/qemu_driver.c | 3 +-- src/qemu/qemu_hotplug.c | 59 ++++++++++++++++++++++++++++---------------- src/qemu/qemu_migration.c | 11 +++------ src/qemu/qemu_monitor_json.c | 10 +++----- src/qemu/qemu_monitor_text.c | 18 ++++++++------ src/qemu/qemu_process.c | 3 +-- 11 files changed, 107 insertions(+), 62 deletions(-) -- 2.5.5

2 7

[libvirt] [PATCH] Allow custom metadata in network configuration XML
by Brnadon Bennett 01 Jul '16

01 Jul '16

From: Brandon Bennett <bbennett(a)fb.com> This replicates the metadata field found in the domain configuration and adds it to the network configuration XML. --- docs/formatnetwork.html.in | 13 +++++++++++++ docs/schemas/basictypes.rng | 23 +++++++++++++++++++++++ docs/schemas/domaincommon.rng | 23 ----------------------- docs/schemas/network.rng | 5 +++++ src/conf/network_conf.c | 35 ++++++++++++++++++++++++++++++++++- src/conf/network_conf.h | 3 +++ tests/networkxml2xmlin/metadata.xml | 10 ++++++++++ tests/networkxml2xmlout/metadata.xml | 10 ++++++++++ tests/networkxml2xmltest.c | 1 + 9 files changed, 99 insertions(+), 24 deletions(-) create mode 100644 tests/networkxml2xmlin/metadata.xml create mode 100644 tests/networkxml2xmlout/metadata.xml diff --git a/docs/formatnetwork.html.in b/docs/formatnetwork.html.in index 1cea931..15ebf0c 100644 --- a/docs/formatnetwork.html.in +++ b/docs/formatnetwork.html.in @@ -38,6 +38,10 @@ <network ipv6='yes' trustGuestRxFilters='no'> <name>default</name> <uuid>3e3fce45-4f53-4fa7-bb32-11f34168b82b</uuid> + <metadata> + <app1:foo xmlns:app1="http://app1.org/app1/">..</app1:foo> + <app2:bar xmlns:app2="http://app1.org/app2/">..</app2:bar> + </metadata> ...</pre> <dl> @@ -54,6 +58,12 @@ The format must be RFC 4122 compliant, eg <code>3e3fce45-4f53-4fa7-bb32-11f34168b82b</code>. If omitted when defining/creating a new network, a random UUID is generated. <span class="since">Since 0.3.0</span></dd> + <dd>The <code>metadata</code> node can be used by applications to + store custom metadata in the form of XML nodes/trees. Applications + must use custom namespaces on their XML nodes/trees, with only + one top-level element per namespace (if the application needs + structure, they should have sub-elements to their namespace + element). <span class="since">Since 1.3.6</span></dd> <dt><code>ipv6</code></dt> <dd>When set to <code>yes</code>, the optional parameter <code>ipv6</code> enables @@ -73,6 +83,9 @@ override the setting in the network.</dd> </dl> ++ + + <h3><a name="elementsConnect">Connectivity</a></h3> <p> diff --git a/docs/schemas/basictypes.rng b/docs/schemas/basictypes.rng index 83fd4ec..474ad77 100644 --- a/docs/schemas/basictypes.rng +++ b/docs/schemas/basictypes.rng @@ -495,4 +495,27 @@ </choice> </define> + <define name="metadata"> + <element name="metadata"> + <zeroOrMore> + <ref name="customElement"/> + </zeroOrMore> + </element> + </define> + + <define name="customElement"> + <element> + <anyName/> + <zeroOrMore> + <choice> + <attribute> + <anyName/> + </attribute> + <text/> + <ref name="customElement"/> + </choice> + </zeroOrMore> + </element> + </define> + </grammar> diff --git a/docs/schemas/domaincommon.rng b/docs/schemas/domaincommon.rng index 162c2e0..78eb3f5 100644 --- a/docs/schemas/domaincommon.rng +++ b/docs/schemas/domaincommon.rng @@ -5338,29 +5338,6 @@ </element> </define> - <define name="metadata"> - <element name="metadata"> - <zeroOrMore> - <ref name="customElement"/> - </zeroOrMore> - </element> - </define> - - <define name="customElement"> - <element> - <anyName/> - <zeroOrMore> - <choice> - <attribute> - <anyName/> - </attribute> - <text/> - <ref name="customElement"/> - </choice> - </zeroOrMore> - </element> - </define> -  diff --git a/docs/schemas/network.rng b/docs/schemas/network.rng index 4edb6eb..b67a5ea 100644 --- a/docs/schemas/network.rng +++ b/docs/schemas/network.rng @@ -37,6 +37,11 @@ <text/> </element> +  + <optional> + <ref name="metadata"/> + </optional> +  <optional> <element name="uuid"><ref name="UUID"/></element> diff --git a/src/conf/network_conf.c b/src/conf/network_conf.c index 02b8cd7..4239c32 100644 --- a/src/conf/network_conf.c +++ b/src/conf/network_conf.c @@ -419,6 +419,9 @@ virNetworkDefFree(virNetworkDefPtr def) virNetDevBandwidthFree(def->bandwidth); virNetDevVlanClear(&def->vlan); + + xmlFreeNode(def->metadata); + VIR_FREE(def); } @@ -2059,6 +2062,7 @@ virNetworkDefParseXML(xmlXPathContextPtr ctxt) xmlNodePtr save = ctxt->node; xmlNodePtr bandwidthNode = NULL; xmlNodePtr vlanNode; + xmlNodePtr metadataNode = NULL; if (VIR_ALLOC(def) < 0) return NULL; @@ -2388,8 +2392,12 @@ virNetworkDefParseXML(xmlXPathContextPtr ctxt) } break; } - VIR_FREE(stp); + + /* Extract custom metadata */ + if ((metadataNode = virXPathNode("./metadata[1]", ctxt)) != NULL) + def->metadata = xmlCopyNode(metadataNode, 1); + ctxt->node = save; return def; @@ -2412,12 +2420,14 @@ virNetworkDefParse(const char *xmlStr, { xmlDocPtr xml; virNetworkDefPtr def = NULL; + int keepBlanksDefault = xmlKeepBlanksDefault(0); if ((xml = virXMLParse(filename, xmlStr, _("(network_definition)")))) { def = virNetworkDefParseNode(xml, xmlDocGetRootElement(xml)); xmlFreeDoc(xml); } + xmlKeepBlanksDefault(keepBlanksDefault); return def; } @@ -2736,6 +2746,29 @@ virNetworkDefFormatBuf(virBufferPtr buf, virUUIDFormat(uuid, uuidstr); virBufferAsprintf(buf, "<uuid>%s</uuid>\n", uuidstr); + if (def->metadata) { + xmlBufferPtr xmlbuf; + int oldIndentTreeOutput = xmlIndentTreeOutput; + + /* Indentation on output requires that we previously set + * xmlKeepBlanksDefault to 0 when parsing; also, libxml does 2 + * spaces per level of indentation of intermediate elements, + * but no leading indentation before the starting element. + * Thankfully, libxml maps what looks like globals into + * thread-local uses, so we are thread-safe. */ + xmlIndentTreeOutput = 1; + xmlbuf = xmlBufferCreate(); + if (xmlNodeDump(xmlbuf, def->metadata->doc, def->metadata, + virBufferGetIndent(buf, false) / 2, 1) < 0) { + xmlBufferFree(xmlbuf); + xmlIndentTreeOutput = oldIndentTreeOutput; + goto error; + } + virBufferAsprintf(buf, "%s\n", (char *) xmlBufferContent(xmlbuf)); + xmlBufferFree(xmlbuf); + xmlIndentTreeOutput = oldIndentTreeOutput; + } + if (def->forward.type != VIR_NETWORK_FORWARD_NONE) { const char *dev = NULL; if (!def->forward.npfs) diff --git a/src/conf/network_conf.h b/src/conf/network_conf.h index 0d34dfe..4481f60 100644 --- a/src/conf/network_conf.h +++ b/src/conf/network_conf.h @@ -253,6 +253,9 @@ struct _virNetworkDef { virNetDevBandwidthPtr bandwidth; virNetDevVlan vlan; int trustGuestRxFilters; /* enum virTristateBool */ + + /* Application-specific custom metadata */ + xmlNodePtr metadata; }; typedef struct _virNetworkObj virNetworkObj; diff --git a/tests/networkxml2xmlin/metadata.xml b/tests/networkxml2xmlin/metadata.xml new file mode 100644 index 0000000..c075f93 --- /dev/null +++ b/tests/networkxml2xmlin/metadata.xml @@ -0,0 +1,10 @@ +<network> + <name>host-bridge-net</name> + <uuid>81ff0d90-c91e-6742-64da-4a736edb9a8e</uuid> + <forward mode='bridge'/> + <bridge name='br0'/> + <metadata> + <app1:foo xmlns:app1="http://foo.org/">fooish</app1:foo> + <app2:bar xmlns:app2="http://bar.com/" maman="baz">barish</app2:bar> + </metadata> +</network> diff --git a/tests/networkxml2xmlout/metadata.xml b/tests/networkxml2xmlout/metadata.xml new file mode 100644 index 0000000..a9364ab --- /dev/null +++ b/tests/networkxml2xmlout/metadata.xml @@ -0,0 +1,10 @@ +<network> + <name>host-bridge-net</name> + <uuid>81ff0d90-c91e-6742-64da-4a736edb9a8e</uuid> + <metadata> + <app1:foo xmlns:app1="http://foo.org/">fooish</app1:foo> + <app2:bar xmlns:app2="http://bar.com/" maman="baz">barish</app2:bar> + </metadata> + <forward mode='bridge'/> + <bridge name='br0'/> +</network> diff --git a/tests/networkxml2xmltest.c b/tests/networkxml2xmltest.c index d65f6aa..2a2c348 100644 --- a/tests/networkxml2xmltest.c +++ b/tests/networkxml2xmltest.c @@ -153,6 +153,7 @@ mymain(void) DO_TEST("host-bridge-no-flood"); DO_TEST_PARSE_ERROR("hostdev-duplicate"); DO_TEST_PARSE_ERROR("passthrough-duplicate"); + DO_TEST("metadata"); return ret == 0 ? EXIT_SUCCESS : EXIT_FAILURE; } -- 2.7.4

4 8

[libvirt] [PATCH] lxc; Fir memory leak if virSocketAddrGetIPPrefix fails
by Jiri Denemark 01 Jul '16

01 Jul '16

Signed-off-by: Jiri Denemark <jdenemar(a)redhat.com> --- src/lxc/lxc_container.c | 4 +--- 1 file changed, 1 insertion(+), 3 deletions(-) diff --git a/src/lxc/lxc_container.c b/src/lxc/lxc_container.c index 0d5f16c..65930c9 100644 --- a/src/lxc/lxc_container.c +++ b/src/lxc/lxc_container.c @@ -514,18 +514,16 @@ lxcContainerRenameAndEnableInterfaces(virDomainDefPtr vmDef, for (j = 0; j < netDef->guestIP.nips; j++) { virNetDevIPAddrPtr ip = netDef->guestIP.ips[j]; int prefix; - char *ipStr = virSocketAddrFormat(&ip->address); if ((prefix = virSocketAddrGetIPPrefix(&ip->address, NULL, ip->prefix)) < 0) { - ipStr = virSocketAddrFormat(&ip->address); + char *ipStr = virSocketAddrFormat(&ip->address); virReportError(VIR_ERR_INTERNAL_ERROR, _("Failed to determine prefix for IP address '%s'"), ipStr); VIR_FREE(ipStr); goto cleanup; } - VIR_FREE(ipStr); if (virNetDevIPAddrAdd(newname, &ip->address, NULL, prefix) < 0) goto cleanup; -- 2.9.0

2 1

[libvirt] [PATCH] util: Call capng_setpid() before using cap-ng
by Andrea Bolognani 01 Jul '16

01 Jul '16

audit is using cap-ng itself since version 2.6.1, and it gets to initialize the internal state of the cap-ng library before we call fork(). Because of that, our own use of cap-ng in the child process ends up attempting to change the capabilities of the parent process instead of the child process, which fails. Calling capng_setpid() before using any other cap-ng API ensures we're altering the capabilities of the right process. --- src/util/virutil.c | 8 ++++++++ 1 file changed, 8 insertions(+) diff --git a/src/util/virutil.c b/src/util/virutil.c index 170dd59..d393a12 100644 --- a/src/util/virutil.c +++ b/src/util/virutil.c @@ -1465,6 +1465,14 @@ virSetUIDGIDWithCaps(uid_t uid, gid_t gid, gid_t *groups, int ngroups, bool need_setgid = false, need_setuid = false; bool need_setpcap = false; + /* The cap-ng library stores some internal data in a thread local + * variable; that includes the PID of the process it should alter + * the capabilities of. After fork(), this data is not cleared, + * so we might end up trying to change the capabilities of a + * different process. Initialize the PID explicitly to work around + * that issue */ + capng_setpid(getpid()); + /* First drop all caps (unless the requested uid is "unchanged" or * root and clearExistingCaps wasn't requested), then add back * those in capBits + the extra ones we need to change uid/gid and -- 2.7.4

3 3

[libvirt] [PATCH] examples: check asprintf return value in client_info.c
by Ján Tomko 01 Jul '16

01 Jul '16

On error, asprintf returns -1 and the contents of the string pointer is undefined. In the rest of the libvirt code, the virAsprintf wrapper takes care of that. Check the return value and report a generic error, since we purposefully avoid linking to virutil. --- examples/admin/client_info.c | 5 +++++ 1 file changed, 5 insertions(+) diff --git a/examples/admin/client_info.c b/examples/admin/client_info.c index dd0a04a..314a090 100644 --- a/examples/admin/client_info.c +++ b/examples/admin/client_info.c @@ -86,6 +86,11 @@ exampleGetTypedParamValue(virTypedParameterPtr item) return NULL; } + if (ret < 0) { + fprintf(stderr, "error formatting typed param value\n"); + return NULL; + } + return str; } -- 2.7.3

2 1

[libvirt] RFC: creating a libvirt-ci mailing list
by Daniel P. Berrange 01 Jul '16

01 Jul '16

Hi Folks, Thanks to the CentOS CI project[1], we have automated build jobs running on every libvirt change. Currently each job is spamming a selected set of email addresses. It seems we're doing a general poor job of actually dealing with breakage though. For example the Mingw build of libvirt has been reported broken for a month and a 1/2 :-( I think it would be useful if we had a broader audience able to see build failures across all the libvirt jobs. At the same time though I dont want to force all libvirt developers to receive this spam. So I suggest we should create a new mailing list 'libvirt-ci(a)redhat.com' which is used to report all CI job failures. People can opt-in to this mailing list to receive reports if they're interested in helping to fix breakage when it happens. We'd set reply-to in the mailing list to be libvir-list(a)redhat.com. IOW, libvirt-ci would be a read-only mailing list for subscribers - any discussion about failures would still be on libvir-list(a)redhat.com Regards, Daniel [1] https://ci.centos.org/ -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

3 3

[libvirt] [PATCH] mingw-libvirt.spec.in: add perl + perl(Getopt::Long) BRs
by Daniel P. Berrange 01 Jul '16

01 Jul '16

The default Fedora build roots for f25 and newer no longer include perl. We must thus explicitly ask for it as the RPC gendispatch.pl program needs it, and the Getopt::Long module. Do this unconditionally since it isn't harmful for older Fedora Signed-off-by: Daniel P. Berrange <berrange(a)redhat.com> --- Pushed as a mingw build fix mingw-libvirt.spec.in | 2 ++ 1 file changed, 2 insertions(+) diff --git a/mingw-libvirt.spec.in b/mingw-libvirt.spec.in index 699d6f7..5c7183f 100644 --- a/mingw-libvirt.spec.in +++ b/mingw-libvirt.spec.in @@ -54,6 +54,8 @@ BuildRequires: mingw64-portablexdr BuildRequires: pkgconfig # Need native version for msgfmt BuildRequires: gettext +BuildRequires: perl +BuildRequires: perl(Getopt::Long) %if 0%{?enable_autotools} BuildRequires: autoconf BuildRequires: automake -- 2.7.4

1 0

[libvirt] LSN-2016-0001 - Authentication disabled when setting empty VNC password
by Daniel P. Berrange 01 Jul '16

01 Jul '16

Libvirt Security Notice: LSN-2016-0001 ====================================== Summary: Authentication disabled when setting empty VNC password Reported on: 20130531 Published on: 20130531 Fixed on: 20160630 Reported by: Vivian Zhang <vivianzhang(a)redhat.com> Christoph Anton Mitterer <calestyo(a)scientia.net> Patched by: Jiri Denemar <jdenemar(a)redhat.com> See also: CVE-2016-5008 Description ----------- An empty password set for the VNC server is documented as preventing all client connections. This is the behaviour when QEMU virtual machines are first started with the 'password' flag given to the -vnc argument and when setting the password with the 'change vnc' monitor command. When libvirt switched to using 'set_password' QMP command though using an empty password had the effect of disabling password checking and thus allowing any client connection with no authentication check. Impact ------ When the password on a VNC server is set to the empty string, authentication on the VNC server will be disabled allowing any user to connect. An application would meanwhile expect that the empty string would prevent all users from connecting Workaround ---------- The VNC password authentication scheme is generally considered to offer inadequate security, so its use is not recommended at all, regardless of this vulnerability. Applications and administrators are thus encouraged to make use of the VNC TLS extension together with SASL for strong authentication. Affected product ---------------- Name: libvirt Repository: git://libvirt.org/git/libvirt.git http://libvirt.org/git/?p=libvirt.git Branch: master Broken in: v0.8.8 Broken in: v0.9.0 Broken in: v0.9.1 Broken in: v0.9.2 Broken in: v0.9.3 Broken in: v0.9.4 Broken in: v0.9.5 Broken in: v0.9.6 Broken in: v0.9.7 Broken in: v0.9.8 Broken in: v0.9.9 Broken in: v0.9.10 Broken in: v0.9.11 Broken in: v0.9.12 Broken in: v0.9.13 Broken in: v0.10.0 Broken in: v0.10.1 Broken in: v0.10.2 Broken in: v1.0.0 Broken in: v1.0.1 Broken in: v1.0.2 Broken in: v1.0.3 Broken in: v1.0.4 Broken in: v1.0.5 Broken in: v1.0.6 Broken in: v1.1.0 Broken in: v1.1.1 Broken in: v1.1.2 Broken in: v1.1.3 Broken in: v1.1.4 Broken in: v1.2.0 Broken in: v1.2.1 Broken in: v1.2.2 Broken in: v1.2.3 Broken in: v1.2.4 Broken in: v1.2.5 Broken in: v1.2.6 Broken in: v1.2.7 Broken in: v1.2.8 Broken in: v1.2.9 Broken in: v1.2.10 Broken in: v1.2.11 Broken in: v1.2.12 Broken in: v1.2.13 Broken in: v1.2.14 Broken in: v1.2.15 Broken in: v1.2.16 Broken in: v1.2.17 Broken in: v1.2.18 Broken in: v1.2.19 Broken in: v1.2.20 Broken in: v1.2.21 Broken in: v1.3.0 Broken in: v1.3.1 Broken in: v1.3.2 Broken in: v1.3.3 Broken in: v1.3.4 Broken in: v1.3.5 Fixed in: v2.0.0 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: bb848feec0f3f10e92dd8e5231ae7aa89b5598f3 Branch: v0.9.6-maint Broken in: v0.9.6.1 Broken in: v0.9.6.2 Broken in: v0.9.6.3 Broken in: v0.9.6.4 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Branch: v0.9.11-maint Broken in: v0.9.11.1 Broken in: v0.9.11.2 Broken in: v0.9.11.3 Broken in: v0.9.11.4 Broken in: v0.9.11.5 Broken in: v0.9.11.6 Broken in: v0.9.11.7 Broken in: v0.9.11.8 Broken in: v0.9.11.9 Broken in: v0.9.11.10 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Branch: v0.9.12-maint Broken in: v0.9.12.1 Broken in: v0.9.12.2 Broken in: v0.9.12.3 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: eea38b5922b7daff91fd146869a337287e77065e Branch: v0.10.2-maint Broken in: v0.10.2.1 Broken in: v0.10.2.2 Broken in: v0.10.2.3 Broken in: v0.10.2.4 Broken in: v0.10.2.5 Broken in: v0.10.2.6 Broken in: v0.10.2.7 Broken in: v0.10.2.8 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 418a165da6e61ab548349408e4ba0c0d612ef5af Branch: v1.0.2-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 139a4265774b7aa194f8479a82188bc1337cd7a4 Branch: v1.0.3-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 3779715e8d4522f1f5de20746fd96bbe59167d1a Branch: v1.0.4-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: a3954cc79358a990720fab36b4feaecd0266c5c6 Branch: v1.0.5-maint Broken in: v1.0.5.1 Broken in: v1.0.5.2 Broken in: v1.0.5.3 Broken in: v1.0.5.4 Broken in: v1.0.5.5 Broken in: v1.0.5.6 Broken in: v1.0.5.7 Broken in: v1.0.5.8 Broken in: v1.0.5.9 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 6fd8d6b655b925df306652d525e388860704d67d Branch: v1.0.6-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: c8df12a1394d75e12da09ec4189eea360feb059d Branch: v1.1.0-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 1338fceea2f16c20b2aa91515918c7cc977d5f29 Branch: v1.1.1-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 6a11fd52b480bb47f8cc988763333788201ab1ab Branch: v1.1.2-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 832cc0eff8feb2f14613a75b0e1d5671735d2094 Branch: v1.1.3-maint Broken in: v1.1.3.1 Broken in: v1.1.3.2 Broken in: v1.1.3.3 Broken in: v1.1.3.4 Broken in: v1.1.3.5 Broken in: v1.1.3.6 Broken in: v1.1.3.7 Broken in: v1.1.3.8 Broken in: v1.1.3.9 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 39419b37c2049cfa36110d75c9071f8a72fa238d Branch: v1.1.4-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 916f5c9d1f6b2145dac93311925db3eb93d3e5aa Branch: v1.2.0-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 20397434fc036dead7e5c375aec7483334396178 Branch: v1.2.1-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: e4ecee35aed931cc10a7c84ec9829ccefddecefa Branch: v1.2.2-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 4816c5370ecf9ed412068c6c3795a2fd71ebc354 Branch: v1.2.3-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 6f7cfb5ba21d5e710a88c2e0fcbc150b59ac510c Branch: v1.2.4-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: dd9cca35bce5bea871f96264cfe9f629566f0b12 Branch: v1.2.5-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: f39de9abfd4b8b19a012169355a0e73dae427bd0 Branch: v1.2.6-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: d933f68ee660566b52cd90330aee0d5f414636a4 Branch: v1.2.7-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 0d052f8abd8bc38ac982e88294737c6ddf3e6484 Branch: v1.2.8-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 05d238be999f6488b6f24cbbff3dada0560d97bf Branch: v1.2.9-maint Broken in: v1.2.9.1 Broken in: v1.2.9.2 Broken in: v1.2.9.3 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: f32441c69bf450d6ac593c3acd621c37e120cdaf Branch: v1.2.10-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 33802d62af95fd7a4e86f2755efe94af59158fea Branch: v1.2.11-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: b7fbb52ac8d1198ba42b3d1f6cc3079497eea704 Branch: v1.2.12-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 819c14190cbea4ef1f99acfbd5e0389899142bd5 Branch: v1.2.13-maint Broken in: v1.2.13.1 Broken in: v1.2.13.2 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 35c2bd75f2c8312687f965a80cc2b6255daf6575 Branch: v1.2.14-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: ea59deeeead2e4894f3651977aa6114849b857fb Branch: v1.2.15-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 9e181d7f6c76f9a84e2c8638722bb98ac61b6baa Branch: v1.2.16-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: b869aab71102c41247a3fede506e88700bb95e55 Branch: v1.2.17-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 49fa383bb03328f7def85e249e252abe5e602e39 Branch: v1.2.18-maint Broken in: v1.2.18.1 Broken in: v1.2.18.2 Broken in: v1.2.18.3 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: caa4c280cd34f0ff0fb9a3879ccc0ceaffc3b802 Branch: v1.2.19-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 38d5c57b9a89c84a19bddcafca9230e69fc78171 Branch: v1.2.20-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 8c30687b71ccb635c110404f0ef1caf2dbccf2e0 Branch: v1.2.21-maint Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 9329ca10f121b737fbdcf3070877e3dbe50f9fdf Branch: v1.3.0-maint Broken in: v1.3.3.1 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: d49b1dfcb59af791f78cd699134cfe80bd6f13ab Branch: v1.3.1-maint Broken in: v1.3.3.1 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 2d5370eba6b52f44cf832eba28f162c55331a47c Branch: v1.3.3-maint Broken in: v1.3.3.1 Broken by: 9d73efdbe3ea61a13a11fdc24a2cb530eaa0b66f Fixed by: 881441f84a30cd3921df313a982f7162d7ca04f4 Regards, Daniel -- |: http://berrange.com -o- http://www.flickr.com/photos/dberrange/ :| |: http://libvirt.org -o- http://virt-manager.org :| |: http://autobuild.org -o- http://search.cpan.org/~danberr/ :| |: http://entangle-photo.org -o- http://live.gnome.org/gtk-vnc :|

3 4