5:38 p.m.
V2: https://www.redhat.com/archives/libvir-list/2018-September/msg00383.html
New in V3:
- Change definition of LIBXL_API_VERSION to 0x040500, the API
version set when Xen 4.6 was released
- Drop the 'true' parameter to LIBVIRT_CHECK_PKG macro so
configure fails if libxl is requested but the devel packages
are not installed
- Remove a now unused variable and a redundant 'if test with_libxl'
check
- Moved the news file addition to 'Removed features' section
Jim Fehlig (2):
libxl: drop support for Xen < 4.6
news: Announce dropping support for Xen 4.4 and 4.5
docs/drvxen.html.in | 2 +-
docs/news.xml | 11 +++++++++++
m4/virt-driver-libxl.m4 | 27 ++-------------------------
src/libxl/libxl_domain.c | 2 +-
src/libxl/libxl_driver.c | 2 +-
5 files changed, 16 insertions(+), 28 deletions(-)
--
2.18.0
5:38 p.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_API_VERSION to 0x040500, which is the API version defined
when Xen 4.6 was released.
Since Xen 4.6 contains a pkgconfig file, drop the now unused code
that falls back to using LIBVIRT_CHECK_LIB in the absence of
pkgconfig file. In addition, bumping the LIBXL_API_VERSION
required adjusting the calls to libxl_set_vcpuaffinity to account
for the extra parameter in the 0x040500 version of the API.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
I made some other changes to this patch so have not added Michal's
ACK from V2. Changes in V3:
- Change definition of LIBXL_API_VERSION to 0x040500, the API
version set when Xen 4.6 was released
- Drop the 'true' parameter to LIBVIRT_CHECK_PKG macro so
configure fails if libxl is requested but the devel packages
are not installed
- Remove a now unused variable and a redundant 'if test with_libxl'
check
docs/drvxen.html.in | 2 +-
m4/virt-driver-libxl.m4 | 27 ++-------------------------
src/libxl/libxl_domain.c | 2 +-
src/libxl/libxl_driver.c | 2 +-
4 files changed, 5 insertions(+), 28 deletions(-)
diff --git a/docs/drvxen.html.in b/docs/drvxen.html.in
index 2e45e09527..ff67291ec6 100644
--- a/docs/drvxen.html.in
+++ b/docs/drvxen.html.in
@@ -8,7 +8,7 @@
<p>
The libvirt libxl driver provides the ability to manage virtual
- machines on any Xen release from 4.4.0 onwards.
+ machines on any Xen release from 4.6.0 onwards.
</p>
<h2><a id="project">Project Links</a></h2>
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 90338eb306..902da11472 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -26,37 +26,14 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_CFLAGS=""
LIBXL_FIRMWARE_DIR=""
LIBXL_EXECBIN_DIR=""
- LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040400"
+ LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
dnl search for libxl, aka libxenlight
- dnl Xen > 4.5 introduced a pkgconfig file, check for it first
- old_with_libxl="$with_libxl"
- LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.4.0], [true])
+ LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
if test "x$with_libxl" = "xyes" ; then
LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
- fi
- dnl pkgconfig file not found, fallback to lib probe
- if test "x$with_libxl" = "xno" ; then
- with_libxl="$old_with_libxl"
-
- dnl LIBXL_API_VERSION 4.4.0 introduced a new parameter to
- dnl libxl_domain_create_restore for specifying restore parameters.
- dnl The libxl driver will make use of this new parameter for specifying
- dnl the Xen migration stream version. Specify LIBXL_API_VERSION to trigger
- dnl an error if there is too old xenlight
- libxlold_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $LIBXL_API_VERSION"
- LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_ctx_alloc], [libxl.h],
[fail="1"])
- CFLAGS="$libxlold_CFLAGS"
-
- if test $fail = 1; then
- AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.4 to compile
libxenlight driver with -lxl])
- fi
- fi
-
- if test "$with_libxl" = "yes"; then
old_LIBS="$LIBS"
old_CFLAGS="$CFLAGS"
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index b800bc9f9d..0032b9dd11 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -886,7 +886,7 @@ libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver,
virDomainObjPtr vm)
if (virBitmapToData(cpumask, &map.map, (int *)&map.size) < 0)
goto cleanup;
- if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, i, &map) != 0) {
+ if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, i, &map, NULL) !=
0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to pin vcpu '%zu' with
libxenlight"), i);
goto cleanup;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 539feb9acf..efd47a3912 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -2475,7 +2475,7 @@ libxlDomainPinVcpuFlags(virDomainPtr dom, unsigned int vcpu,
if (flags & VIR_DOMAIN_AFFECT_LIVE) {
libxl_bitmap map = { .size = maplen, .map = cpumap };
- if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, vcpu, &map) != 0)
{
+ if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, vcpu, &map, NULL)
!= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to pin vcpu '%d' with
libxenlight"),
vcpu);
--
2.18.0
5:41 p.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On 9/11/18 4:38 PM, Jim Fehlig wrote:
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_API_VERSION to 0x040500, which is the API version defined
when Xen 4.6 was released.
Since Xen 4.6 contains a pkgconfig file, drop the now unused code
that falls back to using LIBVIRT_CHECK_LIB in the absence of
pkgconfig file. In addition, bumping the LIBXL_API_VERSION
required adjusting the calls to libxl_set_vcpuaffinity to account
for the extra parameter in the 0x040500 version of the API.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
I made some other changes to this patch so have not added Michal's
ACK from V2. Changes in V3:
- Change definition of LIBXL_API_VERSION to 0x040500, the API
version set when Xen 4.6 was released
- Drop the 'true' parameter to LIBVIRT_CHECK_PKG macro so
configure fails if libxl is requested but the devel packages
are not installed
- Remove a now unused variable and a redundant 'if test with_libxl'
check
Opps, forgot to mention that I also had to adjust the calls to
libxl_set_vcpuaffinity to account for the change in LIBXL_API_VERSION.
Regards,
Jim
docs/drvxen.html.in | 2 +-
m4/virt-driver-libxl.m4 | 27 ++-------------------------
src/libxl/libxl_domain.c | 2 +-
src/libxl/libxl_driver.c | 2 +-
4 files changed, 5 insertions(+), 28 deletions(-)
diff --git a/docs/drvxen.html.in b/docs/drvxen.html.in
index 2e45e09527..ff67291ec6 100644
--- a/docs/drvxen.html.in
+++ b/docs/drvxen.html.in
@@ -8,7 +8,7 @@
<p>
The libvirt libxl driver provides the ability to manage virtual
- machines on any Xen release from 4.4.0 onwards.
+ machines on any Xen release from 4.6.0 onwards.
</p>
<h2><a id="project">Project Links</a></h2>
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 90338eb306..902da11472 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -26,37 +26,14 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_CFLAGS=""
LIBXL_FIRMWARE_DIR=""
LIBXL_EXECBIN_DIR=""
- LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040400"
+ LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
dnl search for libxl, aka libxenlight
- dnl Xen > 4.5 introduced a pkgconfig file, check for it first
- old_with_libxl="$with_libxl"
- LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.4.0], [true])
+ LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
if test "x$with_libxl" = "xyes" ; then
LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
- fi
- dnl pkgconfig file not found, fallback to lib probe
- if test "x$with_libxl" = "xno" ; then
- with_libxl="$old_with_libxl"
-
- dnl LIBXL_API_VERSION 4.4.0 introduced a new parameter to
- dnl libxl_domain_create_restore for specifying restore parameters.
- dnl The libxl driver will make use of this new parameter for specifying
- dnl the Xen migration stream version. Specify LIBXL_API_VERSION to trigger
- dnl an error if there is too old xenlight
- libxlold_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $LIBXL_API_VERSION"
- LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_ctx_alloc], [libxl.h],
[fail="1"])
- CFLAGS="$libxlold_CFLAGS"
-
- if test $fail = 1; then
- AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.4 to compile
libxenlight driver with -lxl])
- fi
- fi
-
- if test "$with_libxl" = "yes"; then
old_LIBS="$LIBS"
old_CFLAGS="$CFLAGS"
diff --git a/src/libxl/libxl_domain.c b/src/libxl/libxl_domain.c
index b800bc9f9d..0032b9dd11 100644
--- a/src/libxl/libxl_domain.c
+++ b/src/libxl/libxl_domain.c
@@ -886,7 +886,7 @@ libxlDomainSetVcpuAffinities(libxlDriverPrivatePtr driver,
virDomainObjPtr vm)
if (virBitmapToData(cpumask, &map.map, (int *)&map.size) < 0)
goto cleanup;
- if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, i, &map) != 0) {
+ if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, i, &map, NULL) !=
0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to pin vcpu '%zu' with
libxenlight"), i);
goto cleanup;
diff --git a/src/libxl/libxl_driver.c b/src/libxl/libxl_driver.c
index 539feb9acf..efd47a3912 100644
--- a/src/libxl/libxl_driver.c
+++ b/src/libxl/libxl_driver.c
@@ -2475,7 +2475,7 @@ libxlDomainPinVcpuFlags(virDomainPtr dom, unsigned int vcpu,
if (flags & VIR_DOMAIN_AFFECT_LIVE) {
libxl_bitmap map = { .size = maplen, .map = cpumap };
- if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, vcpu, &map) != 0)
{
+ if (libxl_set_vcpuaffinity(cfg->ctx, vm->def->id, vcpu, &map, NULL)
!= 0) {
virReportError(VIR_ERR_INTERNAL_ERROR,
_("Failed to pin vcpu '%d' with
libxenlight"),
vcpu);
8:14 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On Tue, Sep 11, 2018 at 04:38:26PM -0600, Jim Fehlig wrote:
Currently the libxl driver claims support for Xen >= 4.4, but
Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
the minimum supported Xen version to 4.6 and change the defined
LIBXL_API_VERSION to 0x040500, which is the API version defined
when Xen 4.6 was released.
Since Xen 4.6 contains a pkgconfig file, drop the now unused code
that falls back to using LIBVIRT_CHECK_LIB in the absence of
pkgconfig file. In addition, bumping the LIBXL_API_VERSION
required adjusting the calls to libxl_set_vcpuaffinity to account
for the extra parameter in the 0x040500 version of the API.
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
I made some other changes to this patch so have not added Michal's
ACK from V2. Changes in V3:
- Change definition of LIBXL_API_VERSION to 0x040500, the API
version set when Xen 4.6 was released
- Drop the 'true' parameter to LIBVIRT_CHECK_PKG macro so
configure fails if libxl is requested but the devel packages
are not installed
- Remove a now unused variable and a redundant 'if test with_libxl'
check
docs/drvxen.html.in | 2 +-
m4/virt-driver-libxl.m4 | 27 ++-------------------------
src/libxl/libxl_domain.c | 2 +-
src/libxl/libxl_driver.c | 2 +-
4 files changed, 5 insertions(+), 28 deletions(-)
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
The check for libxl_domain_config_from_json can also be dropped.
Jano
11:45 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On 9/14/18 7:14 AM, Ján Tomko wrote:
On Tue, Sep 11, 2018 at 04:38:26PM -0600, Jim Fehlig wrote:
> Currently the libxl driver claims support for Xen >= 4.4, but
> Xen 4.4 and 4.5 are no longer supported upstream. Let's increase
> the minimum supported Xen version to 4.6 and change the defined
> LIBXL_API_VERSION to 0x040500, which is the API version defined
> when Xen 4.6 was released.
>
> Since Xen 4.6 contains a pkgconfig file, drop the now unused code
> that falls back to using LIBVIRT_CHECK_LIB in the absence of
> pkgconfig file. In addition, bumping the LIBXL_API_VERSION
> required adjusting the calls to libxl_set_vcpuaffinity to account
> for the extra parameter in the 0x040500 version of the API.
>
> Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
> ---
>
> I made some other changes to this patch so have not added Michal's
> ACK from V2. Changes in V3:
>
> - Change definition of LIBXL_API_VERSION to 0x040500, the API
> version set when Xen 4.6 was released
> - Drop the 'true' parameter to LIBVIRT_CHECK_PKG macro so
> configure fails if libxl is requested but the devel packages
> are not installed
> - Remove a now unused variable and a redundant 'if test with_libxl'
> check
>
> docs/drvxen.html.in | 2 +-
> m4/virt-driver-libxl.m4 | 27 ++-------------------------
> src/libxl/libxl_domain.c | 2 +-
> src/libxl/libxl_driver.c | 2 +-
> 4 files changed, 5 insertions(+), 28 deletions(-)
>
Reviewed-by: Ján Tomko <jtomko(a)redhat.com>
Thanks. I'll push this series shortly.
The check for libxl_domain_config_from_json can also be dropped.
Nod. I'll send a followup to remove it and the use of
HAVE_LIBXL_DOMAIN_CONFIG_FROM_JSON from the tests.
Regards,
Jim
3:59 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On Tue, 2018-09-11 at 16:38 -0600, Jim Fehlig wrote:
[...]
Since Xen 4.6 contains a pkgconfig file, drop the now unused code
that falls back to using LIBVIRT_CHECK_LIB in the absence of
pkgconfig file.
[...]
- dnl pkgconfig file not found, fallback to lib probe
- if test "x$with_libxl" = "xno" ; then
- with_libxl="$old_with_libxl"
-
- dnl LIBXL_API_VERSION 4.4.0 introduced a new parameter to
- dnl libxl_domain_create_restore for specifying restore parameters.
- dnl The libxl driver will make use of this new parameter for specifying
- dnl the Xen migration stream version. Specify LIBXL_API_VERSION to trigger
- dnl an error if there is too old xenlight
- libxlold_CFLAGS="$CFLAGS"
- CFLAGS="$CFLAGS $LIBXL_API_VERSION"
- LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_ctx_alloc], [libxl.h],
[fail="1"])
- CFLAGS="$libxlold_CFLAGS"
-
- if test $fail = 1; then
- AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.4 to compile
libxenlight driver with -lxl])
- fi
- fi
This broke CI builds:
https://ci.centos.org/view/libvirt/job/libvirt-rpm/
It's not libvirt's fault, but rather an issue with Xen packaging
which I've reported accordingly:
https://bugzilla.redhat.com/show_bug.cgi?id=1629643
Depending on how long it takes to get that fixed in Fedora, we
might want to temporarily reintroduce the fallback path...
--
Andrea Bolognani / Red Hat / Virtualization
11 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On 9/17/18 2:59 AM, Andrea Bolognani wrote:
On Tue, 2018-09-11 at 16:38 -0600, Jim Fehlig wrote:
[...]
> Since Xen 4.6 contains a pkgconfig file, drop the now unused code
> that falls back to using LIBVIRT_CHECK_LIB in the absence of
> pkgconfig file.
[...]
> - dnl pkgconfig file not found, fallback to lib probe
> - if test "x$with_libxl" = "xno" ; then
> - with_libxl="$old_with_libxl"
> -
> - dnl LIBXL_API_VERSION 4.4.0 introduced a new parameter to
> - dnl libxl_domain_create_restore for specifying restore parameters.
> - dnl The libxl driver will make use of this new parameter for specifying
> - dnl the Xen migration stream version. Specify LIBXL_API_VERSION to trigger
> - dnl an error if there is too old xenlight
> - libxlold_CFLAGS="$CFLAGS"
> - CFLAGS="$CFLAGS $LIBXL_API_VERSION"
> - LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_ctx_alloc], [libxl.h],
[fail="1"])
> - CFLAGS="$libxlold_CFLAGS"
> -
> - if test $fail = 1; then
> - AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.4 to compile
libxenlight driver with -lxl])
> - fi
> - fi
This broke CI builds:
https://ci.centos.org/view/libvirt/job/libvirt-rpm/
It's not libvirt's fault, but rather an issue with Xen packaging
which I've reported accordingly:
https://bugzilla.redhat.com/show_bug.cgi?id=1629643
Thanks, I've added myself to the bug cc list.
Depending on how long it takes to get that fixed in Fedora, we
might want to temporarily reintroduce the fallback path...
Ok. What is your estimate of "long" in this case? :-) By the end of the day? End
of week? Before freeze for next release?
Regards,
Jim
3:16 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On Mon, 2018-09-17 at 10:00 -0600, Jim Fehlig wrote:
On 9/17/18 2:59 AM, Andrea Bolognani wrote:
> Depending on how long it takes to get that fixed in Fedora, we
> might want to temporarily reintroduce the fallback path...
Ok. What is your estimate of "long" in this case? :-) By the end of the day?
End
of week? Before freeze for next release?
I'd say we give the maintainer a few days to respond, and if
nothing happens by next Monday we just put the code back in.
--
Andrea Bolognani / Red Hat / Virtualization
3:09 a.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On Tue, 2018-09-18 at 10:16 +0200, Andrea Bolognani wrote:
On Mon, 2018-09-17 at 10:00 -0600, Jim Fehlig wrote:
> On 9/17/18 2:59 AM, Andrea Bolognani wrote:
> > Depending on how long it takes to get that fixed in Fedora, we
> > might want to temporarily reintroduce the fallback path...
>
> Ok. What is your estimate of "long" in this case? :-) By the end of the
day? End
> of week? Before freeze for next release?
I'd say we give the maintainer a few days to respond, and if
nothing happens by next Monday we just put the code back in.
The maintainer has fixed the issue in Fedora 29+, but they're
understandably not going to backport the change to earlier Fedora
releases:
https://bugzilla.redhat.com/show_bug.cgi?id=1629643#c2
So we're going to need the fallback code for ~6 more months.
Would you mind posting a patch that reintroduces it along with a
comment mentioning that we can drop it as soon as Fedora 28 goes
out of support?
--
Andrea Bolognani / Red Hat / Virtualization
2:03 p.m.
New subject: [libvirt] [PATCH V3 1/2] libxl: drop support for Xen < 4.6
On 9/19/18 2:09 AM, Andrea Bolognani wrote:
On Tue, 2018-09-18 at 10:16 +0200, Andrea Bolognani wrote:
> On Mon, 2018-09-17 at 10:00 -0600, Jim Fehlig wrote:
>> On 9/17/18 2:59 AM, Andrea Bolognani wrote:
>>> Depending on how long it takes to get that fixed in Fedora, we
>>> might want to temporarily reintroduce the fallback path...
>>
>> Ok. What is your estimate of "long" in this case? :-) By the end of the
day? End
>> of week? Before freeze for next release?
>
> I'd say we give the maintainer a few days to respond, and if
> nothing happens by next Monday we just put the code back in.
The maintainer has fixed the issue in Fedora 29+, but they're
understandably not going to backport the change to earlier Fedora
releases:
https://bugzilla.redhat.com/show_bug.cgi?id=1629643#c2
Yep, saw that.
So we're going to need the fallback code for ~6 more months.
Would you mind posting a patch that reintroduces it along with a
comment mentioning that we can drop it as soon as Fedora 28 goes
out of support?
https://www.redhat.com/archives/libvir-list/2018-September/msg00937.html
Regards,
Jim
5:38 p.m.
New subject: [libvirt] [PATCH V3 2/2] news: Announce dropping support for Xen 4.4 and 4.5
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
ACKed-by: Michal Privoznik <mprivozn(a)redhat.com>
---
docs/news.xml | 11 +++++++++++
1 file changed, 11 insertions(+)
diff --git a/docs/news.xml b/docs/news.xml
index 9d16b2930b..3ed6ff8aeb 100644
--- a/docs/news.xml
+++ b/docs/news.xml
@@ -45,6 +45,17 @@
</description>
</change>
</section>
+ <section title="Removed features">
+ <change>
+ <summary>
+ Xen: Drop support for Xen 4.4 and 4.5
+ </summary>
+ <description>
+ Xen 4.4 and 4.5 are no longer supported by the Xen community.
+ Drop support for these older versions and require Xen >= 4.6.
+ </description>
+ </change>
+ </section>
<section title="Improvements">
<change>
<summary>
--
2.18.0
2256
days inactive
2264
days old
10 comments
3 participants
participants (3)
-
Andrea Bolognani -
Jim Fehlig -
Ján Tomko