Description
Billy DeVincentis
2015-09-06 17:12:10 UTC
Specially because kernel-4.2 brings problems into compiling vmware-modules again (at least for 11 version present in vmware overlay, that according google, are solved in version 12) I posted patches to vmware-modules for kernel-4.2 in bug # 531682 There are 2 patches and if you put theme in /etc/portage/patches/app-emulation/vmware-modules/ and use kernel based vsock and vmci you will have no problems. Rename of ebuild didn't work, can you post the new ebuild? (In reply to Billy DeVincentis from comment #0) > New version out, unfortunately rename of ebuild doesn't work. Would be nice > to get this worked out. Sadly right now I'm as stumped as you are. I've asked the original eclass author (who wrote the unpackging code) for help, let's hope he responds... Here is a version of the ebuild working, it depends on vmware-modules-308 which can be put in another bug report (because it's in common with vmware-player). Anyway, first of all it's needed a patch for vmware-bundle.eclass (also for vmware-player-12) because there are files with size 0 that create problems. Then the bundle doesn't seem to include anymore man pages and xdg files, so I removed those lines from src_install() Created attachment 412298 [details, diff]
vmware-bundle.eclass.patch
Created attachment 412300 [details]
vmware-workstation-12.0.0.2985596.ebuild
Created attachment 412336 [details, diff]
vmware-bundle.eclass.patch
remove $Id$ chunk from git transition
Created attachment 412338 [details, diff]
vmware-workstation-11.1.2.2780323-r1-12.0.0.2985596.ebuild.patch
convert to patch format for easier reading
vmware-bundle_extract-bundle-component "${bundle}" vmware-vix-lib-Workstation1100andvSphere600 vmware-vix Are we sure these numbers are correct in the ebuild? I thought it should be workstation1200... Created attachment 412348 [details, diff]
vmware-workstation-11.1.2.2780323-r1-12.0.0.2985596.ebuild.patch
remove cups USE flag of dubious use, fix deps, fix vix
Created attachment 412350 [details, diff]
vmware-workstation-11.1.2.2780323-r1-12.0.0.2985596.ebuild.patch
oops
Small problem I believe Alex, Workstation1100andvSphere600 You left out "andvSphere600" but I'm not sure what the actual version number of vsphere should be. I believe you need to actually extract the files from the installer to see. (In reply to Billy DeVincentis from comment #13) > Small problem I believe Alex, > > Workstation1100andvSphere600 > > You left out "andvSphere600" yes > but I'm not sure what the actual version number > of vsphere should be. none > I believe you need to actually extract the files from > the installer to see. yes So vsphere is no longer a part of this? Just tried this chmod: cannot access ‘/var/tmp/portage/app-emulation/vmware-workstation-12.0.0.2985596/image//opt/vmware/lib/vmware/bin/vmware-wssc-adminTool’: No such file or directory * ERROR: app-emulation/vmware-workstation-12.0.0.2985596::miscellaneous failed (install phase): Maybe this part is no longer a part of the program? (In reply to Billy DeVincentis from comment #16) > Just tried this > > chmod: cannot access > ‘/var/tmp/portage/app-emulation/vmware-workstation-12.0.0.2985596/image//opt/ > vmware/lib/vmware/bin/vmware-wssc-adminTool’: No such file or directory > * ERROR: app-emulation/vmware-workstation-12.0.0.2985596::miscellaneous > failed (install phase): > > > Maybe this part is no longer a part of the program? this doesn't make sense; it doesn't seem like the built-in launcher can work, given that it references vmware-wssc-adminTool which doesn't seem to be installed. I guess USE=-server for now until the next release. okay, I got this working tonight. Just to be helpful I am posting the actual ebuilds that I used to get it working Created attachment 412688 [details]
vmware-workstation-12.0.0.2985596.ebuild
patched ebuild
Created attachment 412690 [details]
vmware-modules-308.0.ebuild
Only the 4.2 linux inode patch was used as per previous comment
https://bugs.gentoo.org/show_bug.cgi?id=531682 patch is here Created attachment 412692 [details]
vmware-tools-10.0.0.2977863.ebuild
I didn't have the time but hopefully someone can take this and create new bugs for the module and tool ebuilds. Also if anyone can figure out why the server use flag cannot be used, that would be great Thanks I'm afraid there is a problem. If I close vmware-workstation while a vm is running, when I reopen the windows the vm is still running but I cannot access it, it shows a black window as if it is powered down. (In reply to Billy DeVincentis from comment #24) > I'm afraid there is a problem. If I close vmware-workstation while a vm is > running, when I reopen the windows the vm is still running but I cannot > access it, it shows a black window as if it is powered down. if you have USE=-vix or somesuch I think you may need to manually disable the "keep VM alive on close" option in Workstation. I definitely use the vix use flag. I think it may have had something to do with disabling the server flag. I have "keep vms running after workstation closes" checked. The running VM doesn't actually get shut down when I close workstation. It keeps running but I lose permission to access it when I reopen workstation. Can you explain with more detail what was happening causing use "server" to make the emerge fail? I think fixing that may solve the problem. Bill, I have a question. I'm not using workstation but the player, do you have the icons on the right of the bottom bar in the virtual machine window? I'm referring to the icons with the network and disk activity, usb devices, etc @ Billy DeVincentis : Can we get your new attachments (ebuilds) into vmware overlay, please? Thanks a lot in advance. Fabio, To the best of my recollection it did have the icons. I am now remembering that at one time in the past I was having the very same problem when I emerged this and did not use server use flag, in order to have vms running and be able to open and close workstation and not lose ownership of the running vm, it has to have the server use flag. I don't know what is the story with the missing file, possibly a problem with the eclass file not unbundling this correctly? Manfred, it's not working properly yet. When it is I will post zip files with all the necessary folders and if someone wishes to put it into an overlay, that is fine by me. @ Billy: > possibly a problem with the eclass file not unbundling this correctly? The changes to the eclass I made were only related to skipping files with 0 bytes size (compressed version) which gave errors during unpacking @ Manfred: A few days ago I have already made a pull request on github (https://github.com/gentoo/vmware/pull/15) to the gentoo developer for the latest changes to have support for version 12 of player, workstation and modules. I'll soon integrate the latest changes from Billy and also the tools. Please try directly from my github overlay to see if everything works also for you. https://github.com/gentoo/vmware/tree/master/app-emulation I don't see 12 ebuilds where is your overlay? (In reply to Billy DeVincentis from comment #33) > where is your overlay? https://github.com/efferre79/vmware right now I don't have included yet your changes to the workstation ebuild, how did you find the missing deps? Just a couple of things to fix, 1- correct version of workstation from 1100 to 1200 in vmware-workstation ebuild 2- use my ebuild for tools, yours doesn't download files correctly Other than that it seems to have emerged correctly I will report back after restarting Okay 1 small problem after restarting, vix wasn't working here is the correct line for the workstation ebuild vmware-bundle_extract-bundle-component "${bundle}" vmware-vix-lib-Workstation1200 vmware-vix Created attachment 413330 [details]
vmware-workstation-12.0.0.2985596.ebuild
here is the working ebuild
Hooray we have workstation 12 working!!!!!
Please fix the is your overlay
Thanks
Just wanted to point out this in package.use app-emulation/vmware-modules -vmci -vsock Have to build this into kernel to keep this simple Also, I have this file in /etc/modprobe.d/vmware.conf # Support for vmware in kernel modules alias vmci vmw_vmci alias vsock vmw_vsock_vmci_transport This prevents problems with vmci module naming and failure of the vmci service to start Of course should you change this one day to use modules from the ebuild, you should remove the file Billy, thanks for the feedback, I have also fixed the ssl symlinks. Please have a check :-) Fixed also the tools BASE_URI, damn upstream! Moreover I have also introduced a newer version for the vmware-modules (308.0-r1) to automatically create the modprobe file. It seems to me that the vsock module, when built in the kernel, needs also the vmci module built always in the kernel (if CONFIG_VMWARE_VMCI option is not enabled then CONFIG_VMWARE_VMCI_VSOCKETS is not available). For this reason I have introduced a restriction on the USE flags in the ebuild. I don't build the vmware modules in the kernel, if you do then I'd ask to test them building the package with USE="-vmci" and USE="-vmci -vsock". I'm not sure they will work because I get this warning during : /var/tmp/portage/app-emulation/vmware-modules-308.0-r1/work/vmmon-only/linux/driver.c: In function ‘LinuxDriver_Ioctl’: /var/tmp/portage/app-emulation/vmware-modules-308.0-r1/work/vmmon-only/linux/driver.c:1985:1: warning: the frame size of 1124 bytes is larger than 1024 bytes [-Wframe-larger-than=] } Are all modules now building with your new vmware-modules ebuild? If so I may try removing those modules on my next kernel build and I will try the r1 ebuild you mention. I never used to use the in kernel modules but module building became problematic in vmware 11. (In reply to Billy DeVincentis from comment #40) > Are all modules now building with your new vmware-modules ebuild? If so I > may try removing those modules on my next kernel build and I will try the r1 > ebuild you mention. I never used to use the in kernel modules but module > building became problematic in vmware 11. On my system all 5 modules are compiling fine, I have used them with the player. I have "+vmci +vsock" so I was wondering if vmware-modules still works with "-vmci" or "-vmci -vsock" app-emulation/vmware-modules -vmci -vsock is in my package.use, it definitely works and frankly i think it's better because these modules become difficult to compile once new kernel versions are released. (In reply to Billy DeVincentis from comment #42) > app-emulation/vmware-modules -vmci -vsock > is in my package.use, it definitely works and good! > frankly i think it's better > because these modules become difficult to compile once new kernel versions > are released. this is a matter of patching, you know that Gentoo is world of choices :-) (In reply to Fabio Rossi from comment #27) > Bill, I have a question. I'm not using workstation but the player, do you > have the icons on the right of the bottom bar in the virtual machine window? > I'm referring to the icons with the network and disk activity, usb devices, > etc Never mind, problem not visible any more (I don't know the reason) (In reply to Billy DeVincentis from comment #38) > Just wanted to point out this > in package.use > > app-emulation/vmware-modules -vmci -vsock > > Have to build this into kernel to keep this simple > > Also, I have this file in > /etc/modprobe.d/vmware.conf > > # Support for vmware in kernel modules > alias vmci vmw_vmci > alias vsock vmw_vsock_vmci_transport > > > This prevents problems with vmci module naming and failure of the vmci > service to start > Of course should you change this one day to use modules from the ebuild, you > should remove the file The current vmware init file already manages the different naming of vmci module, why someone should introduce the aliases? for openrc maybe, not for systemd RDEPEND="... =dev-libs/libgcrypt-1.5* Please note Bug 562384 : [overlay] vmware-workstation-11.1.2.2780323-r[1..3].ebuild : ">=dev-libs/libgcrypt-1.5.0:0/11" conflicts (In reply to Manfred Knick from comment #47) > RDEPEND="... > =dev-libs/libgcrypt-1.5* > > Please note > > Bug 562384 : > [overlay] > vmware-workstation-11.1.2.2780323-r[1..3].ebuild : > ">=dev-libs/libgcrypt-1.5.0:0/11" conflicts That is the version bundled in the vmware package, probably it's conservative. Currently vmware comes with lots of bundled libs which are used instead of the system ones. The dependencies, as written in the ebuild, are probably wrong or useless so I didn't care about that part of the ebuild in my overlay. The reason is that Andreas is working on the ebuild (see the 11.*-r2 version in his overlay) to fix the mess, so... work in progress :-) Created attachment 415968 [details, diff]
Patch vmmon for kernel-4.3.0
This is patch so vmmon builds and works with 4.3.0 kernel. I have tested it was vmware-workstation-11 but it should would with 12.0 too. I believe 12.0.1 does not need it but this should be confirmed.
(In reply to Harris Landgarten from comment #49) > Created attachment 415968 [details, diff] [details, diff] > Patch vmmon for kernel-4.3.0 > > This is patch so vmmon builds and works with 4.3.0 kernel. I have tested it > was vmware-workstation-11 but it should would with 12.0 too. I believe > 12.0.1 does not need it but this should be confirmed. Thanks for testing the patch from my overlay, anyway I have updated it so that modules 308.0 and 308.1 are both patched correctly against kernel 4.3. vmware-workstation-12.1.0.3272444.ebuild should be the latest version but I am having trouble with the naming scheme for the vmware-modules. The previous version was using 308.1. What should the name be for 12.1 workstation? Created attachment 419936 [details, diff]
0001-vmware-bundle.eclass-skip-empty-files.patch
Created attachment 419938 [details, diff]
0002-app-emulation-vmware-Update.patch
tested working on kernel 4.4.0-rc5+ with USE=-bundled-libs. if USE=bundled-libs and on ~amd64 then there is a symbol error. for 12.1 I used 309.0 you have to rename the 308 patches. Hi Harris, I renamed the ebuilds, copied the 308 patches for the modules and successfully emerge 12.1 ws and 309 modules but I have a problem using kde. The fonts no longer work for workstation. The fonts are really tiny for the ws gui. If I log into Gnome, fonts appear fine. Did you notice this? WS 12.0 does not exhibit this issue I use gnome-3.18 I don't run kde. Odd problem. Hi Alex, Do you have an overlay with all these ebuilds? (In reply to Harris Landgarten from comment #55) > for 12.1 I used 309.0 you have to rename the 308 patches. If you look in vmmon-only/include/iocontrols.h you can find #define VMMON_VERSION (308 << 16 | 0) so the version of vmware modules embedded in the latest release 12.1.0.3272444 is still 308. I have already opened an issue in https://github.com/gentoo/vmware/issues/18 to understand which is the best way to proceed. My solution is to change the naming scheme from 308.x to 308.x.y. Later today I'll push the local changes to my github repository thanks. Is there a new build# for vmware-tools? I couldn't find it on the net. I have updated the repository, there is also the new version of vmware-tools 10.0.5.3228253. I haven't merged yet the latest changes regarding the new bundled-libs useflag. I'm using only vmware-player so please test vmware-workstation. Just wanted to confirm that ebuilds as per Fabios repository all work as expected. Unfortunately my problem still exists with fonts in kde. What I have noticed is that on Fedora 23 with newer kde Plasma, fonts work as expected. I tried compiling from the overlay and vmware-modules fails with this error In file included from /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/linux/hostif.c:97:0: /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/linux/hostif.c: In function ‘HostIF_CallOnEachCPU’: /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/linux/vmmonInt.h:34:50: error: too many arguments to function ‘smp_call_function’ #define compat_smp_call_function(fn, info, wait) smp_call_function(fn, info, 1, wait) using kernel 4.3.3 , renaming to 309 gives the same error. workstation and tools compiled fine. (In reply to Andrew Saunders from comment #63) > I tried compiling from the overlay and vmware-modules fails with this error > > In file included from > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/hostif.c:97:0: > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/hostif.c: In function ‘HostIF_CallOnEachCPU’: > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/vmmonInt.h:34:50: error: too many arguments to function > ‘smp_call_function’ > #define compat_smp_call_function(fn, info, wait) smp_call_function(fn, > info, 1, wait) > > using kernel 4.3.3 , renaming to 309 gives the same error. workstation and > tools compiled fine. I cannot reproduce this error with gentoo-sources-4.3.3, which kernel are you using? Are you sure /usr/src/linux is pointing to a 4.x kernel? For some reason VMW_HAVE_SMP_CALL_3ARG is not defined which is bad, this should happen with kernels < 2.6.27 (In reply to Fabio Rossi from comment #64) > I cannot reproduce this error with gentoo-sources-4.3.3, which kernel are > you using? Are you sure /usr/src/linux is pointing to a 4.x kernel? For some > reason VMW_HAVE_SMP_CALL_3ARG is not defined which is bad, this should > happen with kernels < 2.6.27 /usr/src/linux -> linux-4.3.3 $ uname -a Linux hedgehog 4.3.3 #1 SMP PREEMPT Tue Dec 15 14:47:15 AST 2015 x86_64 AMD FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux strange. I compile my own kernel and don't use genkernel though. (In reply to Andrew Saunders from comment #63) > I tried compiling from the overlay and vmware-modules fails with this error > > In file included from > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/hostif.c:97:0: > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/hostif.c: In function ‘HostIF_CallOnEachCPU’: > /tmp/portage/portage/app-emulation/vmware-modules-308.1.0/work/vmmon-only/ > linux/vmmonInt.h:34:50: error: too many arguments to function > ‘smp_call_function’ > #define compat_smp_call_function(fn, info, wait) smp_call_function(fn, > info, 1, wait) > > using kernel 4.3.3 , renaming to 309 gives the same error. workstation and > tools compiled fine. Been there. You need this patch (308-4.03-00-vmmonInt.patch) and include the following line in the ebuild. [code] kernel_is ge 4 03 0 && epatch "${FILESDIR}/${PV_MAJOR}-4.03-00-vmmonInt.patch" [/code] Created attachment 420850 [details, diff]
308-4.03-00-vmmonInt.patch
(In reply to Andrew Saunders from comment #65) > (In reply to Fabio Rossi from comment #64) > > I cannot reproduce this error with gentoo-sources-4.3.3, which kernel are > > you using? Are you sure /usr/src/linux is pointing to a 4.x kernel? For some > > reason VMW_HAVE_SMP_CALL_3ARG is not defined which is bad, this should > > happen with kernels < 2.6.27 > > /usr/src/linux -> linux-4.3.3 > > $ uname -a > Linux hedgehog 4.3.3 #1 SMP PREEMPT Tue Dec 15 14:47:15 AST 2015 x86_64 AMD > FX(tm)-8350 Eight-Core Processor AuthenticAMD GNU/Linux > > strange. I compile my own kernel and don't use genkernel though. which kernel are you using? can you post a .config? (In reply to John Doe from comment #66) > Been there. > > You need this patch (308-4.03-00-vmmonInt.patch) and include the following > line in the ebuild. > > [code] > kernel_is ge 4 03 0 && epatch > "${FILESDIR}/${PV_MAJOR}-4.03-00-vmmonInt.patch" > [/code] Just lazily threw it in /patch and it compiled no problem. (In reply to Fabio Rossi from comment #68) > which kernel are you using? can you post a .config? Just the vanilla with a handful of patches from here http://dev.gentoo.org/~mpagano/genpatches/trunk/4.3/ config - http://pastebin.com/YYCmNnnz ignore that it says 4.3.1, my script just copies earlier configs for minor revs. (In reply to Andrew Saunders from comment #69) > Just the vanilla with a handful of patches from here > http://dev.gentoo.org/~mpagano/genpatches/trunk/4.3/ > > config - http://pastebin.com/YYCmNnnz > > ignore that it says 4.3.1, my script just copies earlier configs for minor > revs. BTW: Those are the patches included in gentoo-sources-4.3.3 Anyway I can compile successfully using the vanilla-4.3.3 source and the .config you posted using all the patches [1-4]* available in the link above (excluding 100?_linux-4.3.?.patch and 5010_enable-additional-cpu-optimizations-for-gcc-4.9.patch). I'm using gcc 4.8.5. The 308-4.03-00-vmmonInt.patch is only a workaround, it'd be interesting to understand why VMW_HAVE_SMP_CALL_3ARG is not defined as it should be. This means that in your system vmmon-only/autoconf/smpcall.c is not compiled successfully. Can you change the ebuild removing the 308-4.03-00-vmmonInt.patch and using the following patch? --- vmware-modules-308.1.0.ebuild 2015-12-08 21:08:51.490700810 +0100 +++ vmware-modules-308.1.0.ebuild.new 2015-12-27 14:38:30.006228692 +0100 @@ -27,6 +27,8 @@ S=${WORKDIR} +BUILD_PARAMS="V=1 SHELL='sh -x'" + pkg_setup() { CONFIG_CHECK="~HIGH_RES_TIMERS" if kernel_is ge 2 6 37 && kernel_is lt 2 6 39; then Then you can execute: USE="-vsock -vmci" ebuild /path/to/your/app-emulation/vmware-modules/vmware-modules-308.1.0.ebuild clean install and post the log file /var/tmp/portage/app-emulation/vmware-modules-308.1.0/temp/build.log.gz on pastebin > Been there.
>
> You need this patch (308-4.03-00-vmmonInt.patch) and include the following
> line in the ebuild.
>
> [code]
> kernel_is ge 4 03 0 && epatch
> "${FILESDIR}/${PV_MAJOR}-4.03-00-vmmonInt.patch"
> [/code]
John, your patch is not the right way to go, probably you have some SSE related gcc options in your CFLAGS (are you using a 64 bit system, right?). Would you mind trying the new attached patch? It solves the problem for Andrew
Created attachment 423140 [details, diff]
vmware-modules-308.1.0.ebuild.patch
Please test latest 12.1.0.3272444-r1 version in my github repo with bundled-libs useflag enabled/disabled. you should be calling for libgcrypt:11/11 As it is now paludis is calling for 0/11 which would replace 0/20 and cause blockages. Note the libgcrypt issue is paludis only. Reversing he order of the ||() fixes it (In reply to Harris Landgarten from comment #74) > you should be calling for libgcrypt:11/11 > > As it is now paludis is calling for 0/11 which would replace 0/20 and cause > blockages. Actually vmware needs both libgcrypt.so.11 and libgcrypt.so.20, I have fixed the deps with latest commit After latest round of updates, workstation and player are not starting billydv@Linux1 ~ $ /opt/vmware/bin/vmware Loop on signal 11. billydv@Linux1 ~ $ /opt/vmware/bin/vmplayer Gtk-Message: Failed to load module "canberra-gtk-module": libcanberra-gtk-module.so: cannot open shared object file: No such file or directory Loop on signal 11. billydv@Linux1 ~ $ Anyone have any ideas? try it with bundled_libs here is my package.use app-emulation/vmware-workstation cups ovftool server vix vmware-tools bundled-libs use = -bundled-libs fixed problem also fixed small font problem in kde (In reply to Billy DeVincentis from comment #80) > use = -bundled-libs fixed problem > > also fixed small font problem in kde Billy, did you use the latest version in my github repo? Only vmware-workstation is completed from bundled-libs point of view (even if there are some minor issues). Fabio, are you aware of the following issue with USE=-bundled-libs? ldd /opt/vmware/lib/vmware/libconf/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-tiff.so ldd: warning: you do not have execution permission for `/opt/vmware/lib/vmware/libconf/lib/gtk-2.0/2.10.0/loaders/libpixbufloader-tiff.so' linux-vdso.so.1 (0x00007ffeaa9f0000) libtiff.so.3 => not found <--- !!!!!!!! libgdk_pixbuf-2.0.so.0 => /usr/lib64/libgdk_pixbuf-2.0.so.0 (0x00007faa79109000) libgio-2.0.so.0 => /usr/lib64/libgio-2.0.so.0 (0x00007faa78d8e000) libgobject-2.0.so.0 => /usr/lib64/libgobject-2.0.so.0 (0x00007faa78b3c000) libgmodule-2.0.so.0 => /usr/lib64/libgmodule-2.0.so.0 (0x00007faa78937000) libgthread-2.0.so.0 => /usr/lib64/libgthread-2.0.so.0 (0x00007faa78735000) librt.so.1 => /lib64/librt.so.1 (0x00007faa7852e000) libglib-2.0.so.0 => /usr/lib64/libglib-2.0.so.0 (0x00007faa781f7000) libm.so.6 => /lib64/libm.so.6 (0x00007faa77ef6000) libpthread.so.0 => /lib64/libpthread.so.0 (0x00007faa77cda000) libc.so.6 => /lib64/libc.so.6 (0x00007faa77941000) libz.so.1 => /lib64/libz.so.1 (0x00007faa7772b000) libresolv.so.2 => /lib64/libresolv.so.2 (0x00007faa77514000) libffi.so.6 => /usr/lib64/libffi.so.6 (0x00007faa7730b000) libdl.so.2 => /lib64/libdl.so.2 (0x00007faa77107000) /lib64/ld-linux-x86-64.so.2 (0x000056081733b000) (In reply to Alexander Bezrukov from comment #82) > Fabio, > > are you aware of the following issue with USE=-bundled-libs? Yes, I have updated the repository fixing the deps list and removing other bundled-libs. Please test it. (In reply to Fabio Rossi from comment #83) > (In reply to Alexander Bezrukov from comment #82) > > Fabio, > > > > are you aware of the following issue with USE=-bundled-libs? > > Yes, I have updated the repository fixing the deps list and removing other > bundled-libs. Please test it. Yes, vmware now uses system gdk-pixbuf. By the way, is it really necessary to pull pulseaudio? I will try to check this later, right now I have no physical access to a computer running gentoo. (In reply to Alexander Bezrukov from comment #84) > Yes, vmware now uses system gdk-pixbuf. > > By the way, is it really necessary to pull pulseaudio? I will try to check > this later, right now I have no physical access to a computer running gentoo. The library is dynamically loaded by a few binaries in /opt/vmware/lib/vmware/bin/, e.g. vmware-vmx (In reply to Fabio Rossi from comment #85) > (In reply to Alexander Bezrukov from comment #84) > > By the way, is it really necessary to pull pulseaudio? I will try to check > > this later, right now I have no physical access to a computer running gentoo. > > The library is dynamically loaded by a few binaries in > /opt/vmware/lib/vmware/bin/, e.g. vmware-vmx I just tried to run it without pulseaudio installed. It uses pure ALSA then. Sound works well at least in a Windows guest with vmware-tools installed. I believe, pulseaudio dependency may be safely removed. I also noticed that vmware-vmx tries to bind dynamically to libhal.so.1 but feels equally happy without hal. By the way, I found another minor issue. Entering serial number doesn't work when USE=-bundled-libs with the following error: I125: HandleLicenseOutput(stdErr): /opt/vmware/lib/vmware/bin/vmware-gksu: symbol lookup error: /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so: undefined symbol: gksu_context_set_on_fork Bundled libgksu works as expected. > I just tried to run it without pulseaudio installed. It uses pure ALSA then. > Sound works well at least in a Windows guest with vmware-tools installed. I > believe, pulseaudio dependency may be safely removed. The point is that vmware exploits pulseaudio when it finds the library but it doesn't fail without the library. A possibility might be the introduction of a conditional dep on the pulseaudio useflag, something similar was implemented also with cups dep but I prefer to avoid conditions (with -pulseaudio the user expects to disable pulseaudio support, if the package is installed later there is no way to disable it...). IMHO managing the deps for binary software is a mess and I don't want to test every possible combination ... > By the way, I found another minor issue. Entering serial number doesn't work > when USE=-bundled-libs with the following error: > > I125: HandleLicenseOutput(stdErr): /opt/vmware/lib/vmware/bin/vmware-gksu: > symbol lookup error: > /opt/vmware/lib/vmware/lib/libvmware-gksu.so/libvmware-gksu.so: undefined > symbol: gksu_context_set_on_fork > > Bundled libgksu works as expected. Thanks for the report. I'm using the only version available in portage which is 2.0.12-r2 and I confirm it doesn't have the gksu_context_set_on_fork symbol. So libgksu2.so.0 should not be removed, this lib requires also libgtop-2.0.so.7. I'll fix the repo later. The more time I spend on this ebuild and the more I think we should remove completely the -bundled-libs feature. First reason is that with the time more and more libraries will not be available in portage (which means removing a lib from unbundling process). The second reason is that it's impossible to guarantee compatibility between a bundled and system library because we don't have full details about the versions of bundled libs, they might be even patched... FYI, in this particular case it seems that the bundled libgksu.so is a patched version of libgksu-2.0.12 :-( Fabio, I just updated my ebuilds from your overlay and I saw that you have included a message that gcc 5 requires bundled libs. My problem is that bundled libs leaves my vmware menu fonts incredibly small. On gcc 4 with -bundled-libs, fonts were correct. Do we know what bundled lib is responsible for the problem and simply remove that from the bundled and force the use of that system library? Created attachment 428398 [details]
screenshot of small fonts
Here is a picture, note how much larger the dolphin fonts are in the window behind vmware
(In reply to Fabio Rossi from comment #87) > > I just tried to run it without pulseaudio installed. It uses pure ALSA then. > > Sound works well at least in a Windows guest with vmware-tools installed. I > > believe, pulseaudio dependency may be safely removed. > > The point is that vmware exploits pulseaudio when it finds the library but > it doesn't fail without the library. A possibility might be the introduction > of a conditional dep on the pulseaudio useflag, something similar was > implemented also with cups dep but I prefer to avoid conditions (with > -pulseaudio the user expects to disable pulseaudio support, if the package > is installed later there is no way to disable it...). IMHO managing the deps > for binary software is a mess and I don't want to test every possible > combination ... Why not simply remove the dependency without any conditionals? If user wants to setup pulseaudio and did this, pulseaudio will be used. Otherwise plain ALSA will work out of the box. In any case, user has a choice to select what (s)he wants. > The more time I spend on this ebuild and the more I think we should remove > completely the -bundled-libs feature. First reason is that with the time > more and more libraries will not be available in portage (which means > removing a lib from unbundling process). The second reason is that it's > impossible to guarantee compatibility between a bundled and system library > because we don't have full details about the versions of bundled libs, they > might be even patched... Upcoming migration to --std=c++11 (or to >=gcc-5*) will make it necessary to install binary packages with bundled-libs only anyway because of ABI incompatibilities. I am not sure though if at the moment of the migration vmware-workstation will not become too old. From 05f59490ec40787c0630d26995a8a08496f4363d Mon Sep 17 00:00:00 2001 From: =?UTF-8?q?Andreas=20K=2E=20H=C3=BCttel?= <dilfridge@gentoo.org> Date: Sat, 19 Mar 2016 18:06:05 +0100 Subject: app-emulation/vmware-workstation: Major version bump. Imported from the vmware overlay. Many thanks to * Alex Xu <alex_y_xu@yahoo.ca> * Billy DeVincentis <billydv1@verizon.net> * Fabio Rossi <rossi.f@inwind.it> * Evan Teran <evan.teran@gmail.com> * Harris Landgarten <harrisl@lhjonline.com> and to everyone else who helped on bug 559798. ------------- Please file separate bugs for separate problems with the program / ebuild now; I'm closing this one. The ebuild is identical to Fabio's last version, the module patches are from Evan's vmware overlay commit. @Fabio: if you want to keep preparing patches and bumps, it might be easier to force-push your overlay to be identical to the vmware overlay master now, and then re-add patches... right now the merges are a bit messy.... (In reply to Alexander Bezrukov from comment #90) > Why not simply remove the dependency without any conditionals? If user wants > to setup pulseaudio and did this, pulseaudio will be used. Otherwise plain > ALSA will work out of the box. In any case, user has a choice to select what > (s)he wants. +1: At the time being, masking media-sound/pulseaudio in ../package.mask is not working because the ebuild requires it necessarily: ... The following mask changes are necessary to proceed: (...) ... # required by media-plugins/alsa-plugins-1.0.29::gentoo[pulseaudio] ... =media-sound/pulseaudio-8.0 Just removing the line from RDEPEND works as expected and proposed by Alex - and reduces the amount of additional packages pulled in significantly. > Just removing the line from RDEPEND works as expected and proposed by Alex -
> and reduces the amount of additional packages pulled in significantly.
I removed pulseaudio too and it works like a charm. Please remove this "bloatware" from the ebuild.
(In reply to Denis Klens from comment #93) > > Just removing the line from RDEPEND works as expected and proposed by Alex - > > and reduces the amount of additional packages pulled in significantly. > > I removed pulseaudio too and it works like a charm. Please remove this > "bloatware" from the ebuild. Done in overlay and main tree |