Package Details: vmware-workstation 25688693:26H1u1-4

Git Clone URL: https://aur.archlinux.org/vmware-workstation.git (read-only, click to copy)
Package Base: vmware-workstation
Description: The industry standard for running multiple operating systems as virtual machines on a single Linux PC.
Upstream URL: https://www.vmware.com/products/workstation-for-linux.html
Keywords: dkms ovftool player vmplayer vmware workstation
Licenses: custom
Conflicts: vmware-modules-dkms, vmware-ovftool, vmware-patch, vmware-systemd-services
Provides: vmware-ovftool
Submitter: synthead
Maintainer: JulianXhokaxhiu
Last Packager: JulianXhokaxhiu
Votes: 250
Popularity: 2.67
First Submitted: 2017-02-10 19:04 (UTC)
Last Updated: 2026-10-05 22:22 (UTC)

Sources (27)

Pinned Comments

JulianXhokaxhiu commented on 2026-10-05 22:24 (UTC)

New package version released: 26H1u1-4

  • Added support for Clang. Thanks to @Davius for the patch!

PLEASE NOTE: VMWare Player has been dropped by Broadcom, files do not exist anymore in the installer. Only the Workstation GUI is available starting this edition.

Enjoy!

jihem commented on 2020-02-10 17:29 (UTC) (edited on 2021-06-19 13:19 (UTC) by jihem)

After the first installation, please:

1) install the appropriate headers package(s) for your installed kernel(s): linux-headers for default kernel, linux-lts-headers for LTS kernel...

2) reboot or load vmw_vmci and vmmon kernel modules (modprobe -a vmw_vmci vmmon)

3) Enable the services you need (using .service units to activate them during boot or .path units to activate them when a VM is started) :

  • vmware-networks: to have network access inside VMs

  • vmware-usbarbitrator: to connect USB devices inside VMs

Latest Comments

1 2 3 4 5 6 .. 93 Next › Last »

saitewasreset commented on 2026-10-07 02:57 (UTC)

Hi, there seems to be an inconsistency between PKGBUILD and .SRCINFO regarding the default dependencies.

In PKGBUILD, vmware-keymaps is added by default:

# vmware-keymaps dependency is needed to avoid some conflicts when you install
# this package with vmware-horizon-client. If you don't plan to install
# vmware-horizon-client and don't want to add this dependency, you can
# uncomment the line below:
#_remove_vmware_keymaps_dependency=y

...

if [ -z "$_remove_vmware_keymaps_dependency" ]; then
depends+=(
  vmware-keymaps
)
fi

However, .SRCINFO does not list vmware-keymaps under depends:

    ...
    depends = gtk3
    depends = gcr
    optdepends = linux-headers: build modules against Arch kernel

This causes issues when building with certain AUR helpers. For example, when building with paru in a clean chroot, it uses the AUR RPC (which relies on .SRCINFO) to resolve and pre-install AUR dependencies into the chroot environment.

Since .SRCINFO lacks vmware-keymaps, it is not installed into the chroot container beforehand, but makepkg still expects it during the build, causing the build to fail with missing dependencies.

Could you please regenerate .SRCINFO to include it? Thanks!

JulianXhokaxhiu commented on 2026-10-05 22:24 (UTC)

New package version released: 26H1u1-4

  • Added support for Clang. Thanks to @Davius for the patch!

PLEASE NOTE: VMWare Player has been dropped by Broadcom, files do not exist anymore in the installer. Only the Workstation GUI is available starting this edition.

Enjoy!

Davius commented on 2026-09-23 09:50 (UTC)

Hi maintainer, Here the patch for standard C to allow building modules with Clang.

diff --git a/vmnet-only/driver.c b/vmnet-only/driver.c
--- a/vmnet-only/driver.c
+++ b/vmnet-only/driver.c
@@ -1397,7 +1397,7 @@ VNetFreeInterfaceList --
  */

 void
-VNetFreeInterfaceList()
+VNetFreeInterfaceList(void)
 {
    while (vnetInterfaces != NULL) {
       VNetInterface *next = vnetInterfaces->next;
diff --git a/vmnet-only/smac_compat.c b/vmnet-only/smac_compat.c
--- a/vmnet-only/smac_compat.c
+++ b/vmnet-only/smac_compat.c
@@ -77,7 +77,7 @@ SMACL_GetUptime --
  */

 unsigned long SMACINT
-SMACL_GetUptime()
+SMACL_GetUptime(void)
 {
    return jiffies;
 }

Technetium1 commented on 2026-09-06 14:20 (UTC)

I've come to echo the concerns of other recent comments. Epoch should not be used this way. "epoch should only be used when absolutely required to do so".

FabioLolix commented on 2026-09-05 17:25 (UTC)

Epoch should have been bumped to 2 here https://aur.archlinux.org/cgit/aur.git/commit/?h=vmware-workstation&id=152c763f58de65f7bf5d341412feec0a8457865d

Also is not needed to bump pkgrel when bumping epoch

dr460nf1r3 commented on 2026-09-05 16:47 (UTC)

My concern was epoch being set to 25688693 and then rolling with each _buildver update instead of 1. It being required is out of question.

denji commented on 2026-09-05 16:27 (UTC)

@dr460nf1r3 VMware's upstream versioning scheme isn't linear, which breaks standard pacman sorting. Setting epoch=1 is the official Arch mechanism to handle this. Without epoch, we would have to write complex custom logic in pkgver() to rewrite release tags like 26H1u1 into a format vercmp understands, and future conflicts would still be inevitable whenever VMware changes their release format.

dr460nf1r3 commented on 2026-09-05 15:54 (UTC) (edited on 2026-09-05 15:55 (UTC) by dr460nf1r3)

Wouldn't it be much better to set epoch to 1 instead of having this somewhat weird number which changes with every single release. I don't think this is intended usage.

JulianXhokaxhiu commented on 2026-09-05 13:37 (UTC)

@denji: Done :) New version published, should be working fine now. Thanks for the tip!

denji commented on 2026-09-05 10:26 (UTC) (edited on 2026-09-05 14:18 (UTC) by denji)

@JulianXhokaxhiu The new version 26H1u1-1 is detected as a downgrade from 26H1-3 because vercmp considers 26H1-3 newer than 26H1u1-1 (vercmp 26H1-3 26H1u1-1 returns 1). Please consider adding epoch= (1 or equal _buildver) to PKGBUILD.

1 2 3 4 5 6 .. 93 Next › Last »