Bug 1382275 - virt-v2v is pulling in the X11 stack
Summary: virt-v2v is pulling in the X11 stack
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Red Hat Enterprise Linux 7
Classification: Red Hat
Component: libguestfs
Version: 7.3
Hardware: Unspecified
OS: Unspecified
unspecified
high
Target Milestone: rc
: ---
Assignee: Richard W.M. Jones
QA Contact: Virtualization Bugs
URL:
Whiteboard: V2V
Depends On: 1432893 1359086 1452605
Blocks: 1401400
TreeView+ depends on / blocked
 
Reported: 2016-10-06 08:28 UTC by Fabian Deutsch
Modified: 2017-08-01 22:11 UTC (History)
10 users (show)

Fixed In Version: libguestfs-1.36.1-1.el7
Doc Type: If docs needed, set a value
Doc Text:
Clone Of:
Environment:
Last Closed: 2017-08-01 22:11:26 UTC


Attachments (Terms of Use)


Links
System ID Priority Status Summary Last Updated
Red Hat Product Errata RHBA-2017:2023 normal SHIPPED_LIVE libguestfs bug fix and enhancement update 2017-08-01 19:32:01 UTC

Description Fabian Deutsch 2016-10-06 08:28:44 UTC
Description of problem:
Installing virt-v2v is pulling in X11 on a RHEL 7 minimal install.

This is an issue for RHVH which is intended to be small - and should not carry the whole X11 stack.

Version-Release number of selected component (if applicable):
7.2

How reproducible:
Always

Steps to Reproduce:
1. Install virt-v2v
2.
3.

Actual results:
Watch libX11 packages to appear

Expected results:
Don't see libX11 packages to appear

Additional info:

Comment 1 Michal Skrivanek 2016-10-06 08:34:32 UTC
separating to p2v and v2v parts may do the trick

Comment 2 Richard W.M. Jones 2016-10-06 08:55:21 UTC
Yes I suspect the dependency comes from the virt-p2v binary
in /usr/libexec, required by virt-p2v-make-* scripts.

I'll see if I can split things sensibly.

Comment 3 Richard W.M. Jones 2016-10-06 09:27:08 UTC
This is in Rawhide, but the packaging is similar to RHEL 7.

I split out virt-p2v and the virt-p2v-make-* scripts into a new
subpackage called 'virt-p2v-maker'.  This results in fewer
dependencies of virt-v2v.  In particular I believe that all the
graphical dependencies have now gone, ie. cairo, gdk, gtk, etc.

Differences below.

So I think we should do something like that in RHEL 7 too.

--- /tmp/old-requires   2016-10-06 10:10:11.884230455 +0100
+++ /tmp/new-requires   2016-10-06 10:24:32.058804063 +0100
@@ -1,10 +1,7 @@
-/bin/bash
 /usr/bin/virsh
-binutils
 curl
 gawk
 gzip
-libatk-1.0.so.0()(64bit)
 libc.so.6()(64bit)
 libc.so.6(GLIBC_2.14)(64bit)
 libc.so.6(GLIBC_2.15)(64bit)
@@ -13,30 +10,16 @@
 libc.so.6(GLIBC_2.3.4)(64bit)
 libc.so.6(GLIBC_2.4)(64bit)
 libc.so.6(GLIBC_2.7)(64bit)
-libc.so.6(GLIBC_2.8)(64bit)
-libcairo-gobject.so.2()(64bit)
-libcairo.so.2()(64bit)
 libdl.so.2()(64bit)
 libdl.so.2(GLIBC_2.2.5)(64bit)
 libgcc_s.so.1()(64bit)
 libgcc_s.so.1(GCC_3.0)(64bit)
 libgcc_s.so.1(GCC_3.3.1)(64bit)
-libgdk-3.so.0()(64bit)
-libgdk_pixbuf-2.0.so.0()(64bit)
-libgio-2.0.so.0()(64bit)
-libglib-2.0.so.0()(64bit)
-libgobject-2.0.so.0()(64bit)
-libgtk-3.so.0()(64bit)
-libguestfs = 1:1.34.0-1.fc24
-libguestfs-tools-c = 1:1.34.0-1.fc24
+libguestfs = 1:1.35.6-2.fc26
+libguestfs-tools-c = 1:1.35.6-2.fc26
 libguestfs.so.0()(64bit)
 libm.so.6()(64bit)
 libm.so.6(GLIBC_2.2.5)(64bit)
-libpango-1.0.so.0()(64bit)
-libpangocairo-1.0.so.0()(64bit)
-libpcre.so.1()(64bit)
-libpthread.so.0()(64bit)
-libpthread.so.0(GLIBC_2.2.5)(64bit)
 libvirt.so.0()(64bit)
 libvirt.so.0(LIBVIRT_0.0.3)(64bit)
 libvirt.so.0(LIBVIRT_0.1.0)(64bit)
@@ -48,7 +31,6 @@
 libxml2.so.2()(64bit)
 libxml2.so.2(LIBXML2_2.4.30)(64bit)
 libxml2.so.2(LIBXML2_2.6.0)(64bit)
-libxml2.so.2(LIBXML2_2.6.5)(64bit)
 mingw32-srvany >= 1.0-13
 rpmlib(CompressedFileNames) <= 3.0.4-1
 rpmlib(FileDigests) <= 4.6.0-1

Comment 4 Richard W.M. Jones 2016-10-06 09:37:24 UTC
This is the Fedora Rawhide change implementing the above:

http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/commit/?id=7cef4a33055226cddc2208db8c08f041303f8270

Comment 5 Richard W.M. Jones 2016-10-12 12:56:26 UTC
I have got this working in Rawhide now.  The new 'virt-p2v-maker'
RPM has only simple dependencies:

$ rpm -qR virt-p2v-maker 
/bin/bash
binutils
gawk
gzip
libguestfs-tools-c = 1:1.35.8-1.fc26
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1

The old virt-v2v RPM no longer depends on X11/Gtk/etc:

$ rpm -qR virt-v2v
/usr/bin/virsh
curl
gawk
gzip
libc.so.6()(64bit)
[...]
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libgcc_s.so.1()(64bit)
[...]
libguestfs = 1:1.35.8-1.fc26
libguestfs-tools-c = 1:1.35.8-1.fc26
libguestfs.so.0()(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libvirt.so.0()(64bit)
[...]
libxml2.so.2()(64bit)
[...]
mingw32-srvany >= 1.0-13
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)
unzip

The full list of patches needed is a bit more than initially anticipated.

For libguestfs we need:

https://github.com/libguestfs/libguestfs/commit/face52f62e5731cc33183d5995a13b04f7f6a4c2
https://github.com/libguestfs/libguestfs/commit/4c8fc40d6624181939aaa3a6e4eda4f2505318cd
https://github.com/libguestfs/libguestfs/commit/19332919a224e8fd989d30a28673d4e6dea5f58d

For the specfile we need:

http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/commit/?id=7cef4a33055226cddc2208db8c08f041303f8270
http://pkgs.fedoraproject.org/cgit/rpms/libguestfs.git/commit/?id=a61242ebb4cf518eaaca2be1fa6bd0c68a6b0c56

Of course we will also need rel-eng changes to add the new virt-p2v-maker package.

Comment 9 mxie@redhat.com 2017-03-10 01:33:43 UTC
Verify the bug with builds:
virt-v2v-1.36.2-1.el7.x86_64
libguestfs-1.36.2-1.el7.x86_64

Steps:
1.Prepare a rhel7.3 guest which has minimal os installation 
2.Configure the related repo in guest for installing virt-v2v pkg
3.Try to install virt-v2v in guest but libX11 package still appears during virt-v2v dependence resolution, details pls refer to virt-v2v-dependence.log
# cat virt-v2v-dependence.log |grep libX11
--> Processing Dependency: libX11-xcb.so.1()(64bit) for package: pulseaudio-libs-10.0-2.el7.x86_64
--> Processing Dependency: libX11.so.6()(64bit) for package: pulseaudio-libs-10.0-2.el7.x86_64
---> Package libX11.x86_64 0:1.6.4-4.el7 will be installed
--> Processing Dependency: libX11-common >= 1.6.4-4.el7 for package: libX11-1.6.4-4.el7.x86_64
---> Package libX11-common.noarch 0:1.6.4-4.el7 will be installed

4.Check virt-v2v dependence but there is no libX11 pkg
# rpm -qR virt-v2v |grep libX11
nothing

Hi rjones,

Pls help to check if the bug has not been fixed yet?

Comment 10 Richard W.M. Jones 2017-03-10 08:50:36 UTC
The problem now is virt-v2v -> qemu-kvm-rhev -> pulseaudio-libs -> libxcb.

(qemu-kvm also depends on pulseaudio-libs, so that wouldn't make
any difference).

I've no idea why pulseaudio-libs depends on X11.  It sounds plausibly
like that's a bug in pulseaudio.  In any case, we've gone as far as
we can go with fixing virt-v2v.

Fabian: See above.  If you need to go further with this bug, you will
have to file another bug about the pulseaudio-libs -> X11 dependency.

Comment 11 Fabian Deutsch 2017-03-16 09:39:51 UTC
Yep - Thank you.
We'll file a separate bug for pulse audio.

Comment 12 mxie@redhat.com 2017-04-17 06:19:48 UTC
Will verify this bug again when bug 1432893 is fixed,

Comment 13 Pino Toscano 2017-04-20 09:55:31 UTC
(In reply to mxie@redhat.com from comment #12)
> Will verify this bug again when bug 1432893 is fixed,

Not sure whether bug 1432893 is going to be fixed -- in the end, the X11 packages are not a big overhead though.

OTOH, on the libguestfs side we've done what we could, basically.  The dependency chain now is basically:

  virt-p2v-maker -> libguestfs-tools-c -> libguestfs -> qemu-kvm -> pulseaudio-libs -> libX11

virt-p2v-maker requires libguestfs-tools-c because of virt-builder.

Comment 15 Pino Toscano 2017-05-31 09:25:46 UTC
mxie: with qemu-kvm-rhev-2.9.0-6.el7 it should be possible to verify this bug

Comment 16 tingting zheng 2017-05-31 11:14:39 UTC
(In reply to Pino Toscano from comment #15)
> mxie: with qemu-kvm-rhev-2.9.0-6.el7 it should be possible to verify this bug

Thanks for reminding,Ming is working on this bug and will paste comments later.

Comment 17 mxie@redhat.com 2017-06-01 02:42:07 UTC
Verify the bug with below builds:
virt-v2v-1.36.3-4.el7.x86_64
libguestfs-1.36.3-4.el7.x86_64
qemu-kvm-rhev-2.9.0-7.el7.x86_64
qemu-kvm-1.5.3-139.el7.x86_64

Steps:
1.Prepare a rhel7.4 guest which has minimal os installation 
2.Configure the related repos which has qemu-kvm-rhev repo in guest for installing virt-v2v pkg
3.Try to install virt-v2v in guest
#yum install virt-v2v > virt-v2v-dependence.log

4.Check virt-v2v dependence but there is no libX11 pkg
# cat virt-v2v-dependence.log |grep libX11
nothing 

# rpm -qR virt-v2v |grep libX11
nothing


Hi Pino

  qemu-kvm-rhev-2.9.0-7.el7 has dropped depending on pulseaudio-libs -> libX11, but qemu-kvm-1.5.3-139.el7 still depends on libX11,customer will see the libX11 pkg when install virt-v2v with qemu-kvm, could we move this bug to verified status without fixing on qemu-kvm side?


# cat virt-v2v-qemu-kvm.log |grep libX11
--> Processing Dependency: libX11.so.6()(64bit) for package: cairo-1.14.2-1.el7.x86_64
---> Package libX11.x86_64 0:1.6.3-3.el7 will be installed
--> Processing Dependency: libX11-common >= 1.6.3-3.el7 for package: libX11-1.6.3-3.el7.x86_64
---> Package libX11-common.noarch 0:1.6.3-3.el7 will be installed

Comment 18 Pino Toscano 2017-06-01 06:24:25 UTC
I'd say so for now, as on the libguestfs side we've fixed what we could.

Comment 19 mxie@redhat.com 2017-06-01 06:34:22 UTC
According to comment 17 and comment18, move this bug from ON_QA to VERIFIED

Comment 20 errata-xmlrpc 2017-08-01 22:11:26 UTC
Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory, and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2017:2023


Note You need to log in before you can comment on or make changes to this bug.