Last version of vmware-workstation in portage is 9.0.2.1031769, but according to their website, version 10.0.0-1295980 So this is an ebuild update/adition request Reproducible: Always
Wonder if a rename will work....
(In reply to Billy DeVincentis from comment #1) > Wonder if a rename will work.... It is not that easy, indeed, renaming it, will fetch the correct tarball, but it also depends on its vmware kernel modules. And since it is a major version change, I am not sure in which modules should it depend (and maybe a new ebuild for its modules is needed too), that's why I prefer them to bump it correctly rather than trying for myself.
You might want to take a look at Bug 484084.
--- /usr/portage/app-emulation/vmware-workstation/vmware-workstation-9.0.2.1031769-r1.ebuild 2013-07-24 14:47:44.000000000 -0700 +++ vmware-workstation-10.0.0.1295980.ebuild 2013-09-13 06:49:39.049478651 -0700 @@ -83,7 +83,7 @@ RDEPEND="dev-cpp/cairomm x11-libs/startup-notification x11-themes/hicolor-icon-theme !app-emulation/vmware-player" -PDEPEND="~app-emulation/vmware-modules-271.${PV_MINOR} +PDEPEND="~app-emulation/vmware-modules-279.${PV_MINOR} vmware-tools? ( app-emulation/vmware-tools )" S=${WORKDIR} @@ -115,7 +115,7 @@ src_unpack() { if use vix; then vmware-bundle_extract-bundle-component "${bundle}" vmware-vix-core vmware-vix - vmware-bundle_extract-bundle-component "${bundle}" vmware-vix-lib-Workstation900andvSphere510 vmware-vix + vmware-bundle_extract-bundle-component "${bundle}" vmware-vix-lib-Workstation1000andvSphere550 vmware-vix fi if use ovftool; then vmware-bundle_extract-bundle-component "${bundle}" vmware-ovftool @@ -282,8 +282,8 @@ src_install() { fi # create symlinks for the various tools - local tool ; for tool in thnuclnt vmware vmplayer{,-daemon} \ - vmware-{acetool,enter-serial,gksu,fuseUI,modconfig{,-console},netcfg,tray,unity-helper} ; do + local tool ; for tool in thnuclnt vmware vmplayer{,-daemon} licenseTool vmamqpd \ + vmware-{acetool,app-control,enter-serial,gksu,fuseUI,modconfig{,-console},netcfg,tray,unity-helper,zenity} ; do dosym appLoader "${VM_INSTALL_DIR}"/lib/vmware/bin/"${tool}" done dosym "${VM_INSTALL_DIR}"/lib/vmware/bin/vmplayer "${VM_INSTALL_DIR}"/bin/vmplayer I can try to clean everything up and put it in my overlay if anyone thinks that would have any utility (but my vmware-modules patches are especially problematic; they are scraped together from sources I don't have any reason to trust and make ugly typecast warnings I have not yet investigated).
Got this working, I am attaching a working ebuild thanks to the work by Greg and I also have set up the modules ebuild. 1- Besides the ebuild you must rename vmware-9.0.rc and vmware-server-9.0.rc to vmware-10.0.rc and vmware-server-10.0.rc 2- the modules ebuild is for kernel 3.11, the epatches are for that kernel only. you also need the vmblock patch, all other patches just get renamed from 271 to 279
Created attachment 358746 [details] vmware-workstation-10.0.0.1295980.ebuild
Created attachment 358748 [details] vmware-10.0.rc
Created attachment 358750 [details] vmware-server-10.0.rc
Created attachment 358752 [details] vmware-modules-279.0.ebuild
Created attachment 358754 [details, diff] 279-vmblock.patch
BTW vmmon and 3.10 patches are no longer needed
Created attachment 358758 [details] vmware-tools-9.6.0.1295980.ebuild BTW, here is the needed vmware-tools ebuild
I also wanted to mention something with regards to this release of vmware workstation. On a gentoo guest (irrelevant of the host, linux or windows) mouse behavior is erratic. It's the same on both linux and windows hosts. When you enter a side line mouse grabs and ungrabs and sets mouse position in a whole new location. It's almost unusable unles you uncheck the box in preferences that controls automatic grabbing and ungrabbing and simply use ctrl a to release the mouse. This may be a quirk with the vmmouse driver for xorg.
(In reply to Billy DeVincentis from comment #5) Billy, thank you _very_ much! ... > 2- the modules ebuild is for kernel 3.11, the epatches are for that kernel > only. ... With G.K-H having defined 3.10 as the new long-term stable, I would prefer to have a version for this one working and imported into gentoo's tree. Could you please point out at what I would have to look at in contrast to your patch set? Kind regards, Yours sincerely Manfred
If using 3.10 no patch is needed. I have changed the ebuild from Billy accordingly - worked on my system.
Created attachment 359600 [details] vmware-modules for gentoo-sources 3.10
VMWare team -- any progress?
(In reply to Jason A. Donenfeld from comment #17) > VMWare team -- any progress? I have a WS 10 license key since today, I'll have a look over the weekend.
I was hoping to get some feedback with the mouse issue. I have reverted to ws9 since I do not want mouse problems. Is anyone else using WS10 on a Gentoo host with a linux guest? Are you able to get working side buttons on your mouse? I believe this is a regression on Vmware's part.
I'm not sure how but the problem appears to have solved itself. I am going to now keep ws10 on both my windows and gentoo boxes.
(In reply to Andreas K. Hüttel from comment #18) Hi, Andreas, could this find it's way into ... overlays / proj / vmware.git until you decide it appropriate to enter the main portage tree? Thanks! Yours sincerely Manfred
(In reply to Billy DeVincentis from comment #10) > Created attachment 358754 [details, diff] [details, diff] > 279-vmblock.patch Hi Billy, could you please give me hint where you got this from? TIA, Andreas
(In reply to Jason A. Donenfeld from comment #17) > VMWare team -- any progress? In tree without keywords, need to test and verify myself.
Just tried your vmware-modules-279.9 ebuild, with the following result: * Failed Patch: 279-3.10.0.patch ! * ( /usr/portage/app-emulation/vmware-modules/files/279-3.10.0.patch )
(In reply to Sven from comment #24) > Just tried your vmware-modules-279.9 ebuild, with the following result: > > * Failed Patch: 279-3.10.0.patch ! > * ( /usr/portage/app-emulation/vmware-modules/files/279-3.10.0.patch ) that's weird since the patch works here on two different boxes
(In reply to Andreas K. Hüttel from comment #25) > that's weird since the patch works here on two different boxes Well, I have vmware-player 6.0 installed via my own ebuild. The vmware-modules ebuild is obviously using the sources provided by vmware player. This might make a difference. The strange thing is, that I have a working ebuild for vmware-modules-279 in my own overlay - and it doesn't use the 3.10.0 patch but still works fine with kernel 3.10.16.
Well, the vmware-modules ebuild in portage is still incomeplete, patch wise. I just tried it with kernel 3.11.6. It still requires the patches from Bug 462666 (since I have CONFIG_USER_NS enabled) and Bug 483410. Also, even after upgrading to the vmware-player 6.0 ebuild in the official tree, vmware-modules-279 still fails to apply the 279-3.10.0 patch. I had to comment the line that applies it.
It fails for me too: >>> Preparing source in /var/tmp/portage/app-emulation/vmware-modules-279.0/work ... * Applying 279-makefile-kernel-dir.patch ... [ ok ] * Applying 279-makefile-include.patch ... [ ok ] * Applying 279-netdevice.patch ... [ ok ] * Applying 279-apic.patch ... [ ok ] * Applying 279-putname.patch ... [ ok ] * Applying 279-3.10.0.patch ... * Failed Patch: 279-3.10.0.patch ! * ( /usr/portage/app-emulation/vmware-modules/files/279-3.10.0.patch ) I'm on gentoo-sources-3.10.17.
I got it to work by forcing the 3.11 patch to be applied: #kernel_is ge 3 7 0 && epatch "${FILESDIR}/${PV_MAJOR}-putname.patch" #kernel_is ge 3 10 0 && epatch "${FILESDIR}/${PV_MAJOR}-3.10.0.patch" epatch "${FILESDIR}/${PV_MAJOR}-vmblock.patch" It seems that something was backported from 3.11 to 3.10, making this patch now applicable to 3.10 kernels? (3.10.17 here.)
Nah, spoke too soon. It only builds fine. It doesn't load: modprobe: ERROR: could not insert 'vmblock': Unknown symbol in module, or unknown parameter (see dmesg) vmblock: Unknown symbol final_putname (err 0)
OK I think this should work now. The packages are constructed in a strange way, which mislead me about the patches. Tested with 3.10.7-gentoo-r1, please open a separate bug for build problems with newer kernel versions.
*** Bug 489462 has been marked as a duplicate of this bug. ***
