1:59 p.m.
Fix CI builds broken by commit 5bdcef13. While doing so I noticed more
unused variables, which are removed by patch1.
Jim Fehlig (2):
build: remove unused variables from virt-driver-libxl.m4
libxl: fallback to lib probe if pkgconfig file not found
m4/virt-driver-libxl.m4 | 23 ++++++++++++++++++++---
1 file changed, 20 insertions(+), 3 deletions(-)
--
2.18.0
1:59 p.m.
New subject: [libvirt] [PATCH 1/2] build: remove unused variables from virt-driver-libxl.m4
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
m4/virt-driver-libxl.m4 | 3 ---
1 file changed, 3 deletions(-)
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 70c5c59e6a..422ff27022 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -34,9 +34,6 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_FIRMWARE_DIR=$($PKG_CONFIG --variable xenfirmwaredir xenlight)
LIBXL_EXECBIN_DIR=$($PKG_CONFIG --variable libexec_bin xenlight)
- old_LIBS="$LIBS"
- old_CFLAGS="$CFLAGS"
-
LIBXL_CFLAGS="$LIBXL_CFLAGS $LIBXL_API_VERSION"
dnl If building with libxl, use the libxl utility header and lib too
--
2.18.0
1:59 p.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
With the assumption that all Xen >= 4.6 contains a pkgconfig file for
libxenlight, commit 5bdcef13 dropped the fallback check to probe
libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
the various Xen pkgconfig files are in the -runtime package in Fedora,
instead of the traditional -devel package. This bug [1] was fixed in
Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
the fallback check.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
m4/virt-driver-libxl.m4 | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 422ff27022..479d9116a4 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -29,11 +29,31 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
dnl search for libxl, aka libxenlight
- LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
+ old_with_libxl="$with_libxl"
+ LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true])
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 In Fedora <= 28, the xenlight pkgconfig file is in the -runtime package
+ dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
+ dnl Until Fedora 28 reaches EOL, fallback to lib probe if xenlight.pc is
+ dnl not found
+ if test "x$with_libxl" = "xno" ; then
+ with_libxl="$old_with_libxl"
+
+ save_CFLAGS="$CFLAGS"
+ CFLAGS="$CFLAGS $LIBXL_API_VERSION"
+ LIBVIRT_CHECK_LIB([LIBXL], [xenlight], [libxl_cpupool_cpuadd_cpumap], [libxl.h],
[fail="1"])
+ CFLAGS="$save_CFLAGS"
+
+ if test $fail = 1; then
+ AC_MSG_ERROR([You must install the libxl Library from Xen >= 4.6 to compile
libxenlight driver with -lxl])
+ fi
+ fi
+
+ if test "$with_libxl" = "yes"; then
LIBXL_CFLAGS="$LIBXL_CFLAGS $LIBXL_API_VERSION"
dnl If building with libxl, use the libxl utility header and lib too
--
2.18.0
1:30 a.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
On 09/19/2018 08:59 PM, Jim Fehlig wrote:
With the assumption that all Xen >= 4.6 contains a pkgconfig file
for
libxenlight, commit 5bdcef13 dropped the fallback check to probe
libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
the various Xen pkgconfig files are in the -runtime package in Fedora,
instead of the traditional -devel package. This bug [1] was fixed in
Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
the fallback check.
[1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643
Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
---
m4/virt-driver-libxl.m4 | 22 +++++++++++++++++++++-
1 file changed, 21 insertions(+), 1 deletion(-)
diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
index 422ff27022..479d9116a4 100644
--- a/m4/virt-driver-libxl.m4
+++ b/m4/virt-driver-libxl.m4
@@ -29,11 +29,31 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
dnl search for libxl, aka libxenlight
- LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
+ old_with_libxl="$with_libxl"
+ LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true])
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 In Fedora <= 28, the xenlight pkgconfig file is in the -runtime package
+ dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
+ dnl Until Fedora 28 reaches EOL, fallback to lib probe if xenlight.pc is
+ dnl not found
Le sigh. So we have to have this in for next what 6 months? :-(
ACK though
Michal
<rant>
Sure, we can try working around broken packaging, or we can be brave
and just tell users to install yet another package if they want to have
xl driver enabled simply because they are using broken package. It's not
our bug, and we already work around plenty of other bugs for other
apps/libs.
</rant>
3:04 a.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
On Thu, 2018-09-20 at 08:30 +0200, Michal Privoznik wrote:
On 09/19/2018 08:59 PM, Jim Fehlig wrote:
> + dnl In Fedora <= 28, the xenlight pkgconfig file is in the
> -runtime package
> + dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
> + dnl Until Fedora 28 reaches EOL, fallback to lib probe if
> xenlight.pc is
> + dnl not found
Le sigh. So we have to have this in for next what 6 months? :-(
We're just re-introducing code that was recently removed with
5bdcef13d135: before that, it had been there for a very long time,
so six-ish more months are hardly going to make a difference.
<rant>
Sure, we can try working around broken packaging, or we can be
brave
and just tell users to install yet another package if they want to
have
xl driver enabled simply because they are using broken package. It's
not
our bug, and we already work around plenty of other bugs for other
apps/libs.
</rant>
We'd have to add something like
%if %{with_libxl} && 0%{?fedora} < 29
BuildRequires: xen-runtime
%endif
to libvirt.spec for that to work, and at that point you're just
exchanging one workaround for another... Might as well go for the
one that doesn't require users and CI workers to install extra
packages.
--
Andrea Bolognani / Red Hat / Virtualization
9:13 a.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
On 9/20/18 12:30 AM, Michal Privoznik wrote:
On 09/19/2018 08:59 PM, Jim Fehlig wrote:
> With the assumption that all Xen >= 4.6 contains a pkgconfig file for
> libxenlight, commit 5bdcef13 dropped the fallback check to probe
> libxenlight with LIBVIRT_CHECK_LIB. At the time it was not known that
> the various Xen pkgconfig files are in the -runtime package in Fedora,
> instead of the traditional -devel package. This bug [1] was fixed in
> Fedora > 28, but until Fedora 28 reaches EOL we'll need to re-introduce
> the fallback check.
>
> [1] https://bugzilla.redhat.com/show_bug.cgi?id=1629643
>
> Signed-off-by: Jim Fehlig <jfehlig(a)suse.com>
> ---
> m4/virt-driver-libxl.m4 | 22 +++++++++++++++++++++-
> 1 file changed, 21 insertions(+), 1 deletion(-)
>
> diff --git a/m4/virt-driver-libxl.m4 b/m4/virt-driver-libxl.m4
> index 422ff27022..479d9116a4 100644
> --- a/m4/virt-driver-libxl.m4
> +++ b/m4/virt-driver-libxl.m4
> @@ -29,11 +29,31 @@ AC_DEFUN([LIBVIRT_DRIVER_CHECK_LIBXL], [
> LIBXL_API_VERSION="-DLIBXL_API_VERSION=0x040500"
>
> dnl search for libxl, aka libxenlight
> - LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0])
> + old_with_libxl="$with_libxl"
> + LIBVIRT_CHECK_PKG([LIBXL], [xenlight], [4.6.0], [true])
> 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 In Fedora <= 28, the xenlight pkgconfig file is in the -runtime package
> + dnl https://bugzilla.redhat.com/show_bug.cgi?id=1629643
> + dnl Until Fedora 28 reaches EOL, fallback to lib probe if xenlight.pc is
> + dnl not found
Le sigh. So we have to have this in for next what 6 months? :-(
ACK though
Thanks, I've pushed these.
<rant>
Sure, we can try working around broken packaging, or we can be brave
and just tell users to install yet another package if they want to have
xl driver enabled simply because they are using broken package. It's not
our bug, and we already work around plenty of other bugs for other
apps/libs.
</rant>
Nod.
Over the years my ranting about such workarounds has ebbed as they have become
commonplace throughout the stack: kernel works around hardware bugs, runtimes
work around kernel bugs, apps work around runtime bugs, ... I've also seen
workarounds for libvirt bugs :-).
Regards,
Jim
9:40 a.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
On 09/20/2018 04:13 PM, Jim Fehlig wrote:
On 9/20/18 12:30 AM, Michal Privoznik wrote:
> <snip/>
Over the years my ranting about such workarounds has ebbed as they have
become commonplace throughout the stack: kernel works around hardware
bugs, runtimes work around kernel bugs, apps work around runtime bugs,
... I've also seen workarounds for libvirt bugs :-).
This is an urban legend. Libvirt has no bugs! :-P
Michal
11:38 a.m.
New subject: [libvirt] [PATCH 2/2] libxl: fallback to lib probe if pkgconfig file not found
On 09/20/2018 10:40 AM, Michal Privoznik wrote:
On 09/20/2018 04:13 PM, Jim Fehlig wrote:
> On 9/20/18 12:30 AM, Michal Privoznik wrote:
>> <snip/>
> Over the years my ranting about such workarounds has ebbed as they have
> become commonplace throughout the stack: kernel works around hardware
> bugs, runtimes work around kernel bugs, apps work around runtime bugs,
> ... I've also seen workarounds for libvirt bugs :-).
This is an urban legend. Libvirt has no bugs! :-P
"Alternate Functionality"
On a more serious note - yeah, it turns out that just putting in a
workaround often ends up being much simpler than trying to coordinate a
fix with the other party (assuming they even agree there is a problem).
2258
days inactive
2259
days old
8 comments
4 participants
participants (4)
-
Andrea Bolognani -
Jim Fehlig -
Laine Stump -
Michal Privoznik