Package Details: vmware-horizon-virtual-printing 5.0.0-1

Git Clone URL: https://aur.archlinux.org/vmware-horizon-client.git (read-only)
Package Base: vmware-horizon-client
Description: VMware Horizon Client connect to VMware Horizon virtual desktop - virtual printing
Upstream URL: https://www.vmware.com/go/viewclients
Licenses: custom
Submitter: eworm
Maintainer: eworm
Last Packager: eworm
Votes: 31
Popularity: 0.193234
First Submitted: 2015-01-08 15:17
Last Updated: 2019-03-18 20:49

Latest Comments

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

ekkelett commented on 2019-03-18 14:31

@eworm, thanks for maintaining this package. Could I suggest that you edit the desktop file and change from Icon=vmware-view.png to Icon=vmware-view? By changing it the icon will correctly show in Rofi and other launchers.

It could be vmware-horizon-client.desktop instead, but that's hardly important.

slav commented on 2019-03-15 20:46

Thank you for your help. Actually two more packages vmware-keymaps and openssl098 resolved issue.

eworm commented on 2019-03-15 09:51

Please install vmware-keymaps from AUR.

slav commented on 2019-03-15 07:12

Unfortunately I'm unable to upgrade last vmware-horizon-client 4.10.0-3

pacman -U vmware-horizon-client-4.10.0-3-x86_64.pkg.tar.xz
loading packages... resolving dependencies... warning: cannot resolve "vmware-keymaps", a dependency of "vmware-horizon-client" :: The following package cannot be upgraded due to unresolvable dependencies: vmware-horizon-client

:: Do you want to skip the above package for this upgrade? [y/N] N error: failed to prepare transaction (could not satisfy dependencies) :: unable to satisfy dependency 'vmware-keymaps' required by vmware-horizon-client

jskier commented on 2019-02-08 17:06

@xerxies, yes, I'm also having that issue. CST turns into China whenever I use ArchLinux with the view client. Using Windows it works correctly. Will try the reg fix. This came up a few years ago (I think on the old client). I ended up running a logon script to fix it then.

xerxies commented on 2019-01-29 22:36

These are Non-persistent desktops. While I could change that in the base image, we do have users in multiple timezones that would use Time Zone syncing, and without creating a logon script or a GPO for my user account to change it, it's easier to just remember to change the Timezone every time I reconnect. I just was curious if anyone else has that issue, and if it is specific to the CST timezone. It does happen on my Arch laptop and my Surface which runs Antergos, but not to my co-workers Cent or Debian box in the same timezone.

eworm commented on 2019-01-29 21:13

I can not explain your issue in detail, but if disabling the timezone synchronization is an option import this to your horizon agent's registry:

[HKEY_LOCAL_MACHINE\Software\VMware, Inc.\VMware VDM\Agent\Configuration] DisableTimeZoneSynchronization="true"

xerxies commented on 2019-01-29 19:34

This isn't an issue with the package at least that I'm aware of, but does anyone else have an issue with the timezone set on your Arch box not getting reported correctly to the Horizon Client?

Example: I'm in the US Central Standard timezone and the ViewClient_TZID variable is getting set to "CST" (which I would expect), but the ViewClient_Windows_Timezone is getting set to "China Standard Time". This could be an issue with how Arch is treating timezone abbreviations vs how horizon is.

CST Central Standard Time (North America) UTC−06 CST China Standard Time UTC+08 CST Cuba Standard Time UTC−05

eworm commented on 2019-01-03 09:58

The release notes list:

TLS 1.0 support discontinued Support of TLS 1.0 has been discontinued beginning with this release.

Possibly your servers do not yet support TLS 1.1 or 1.2?

viktormv commented on 2019-01-03 09:51

Do you also get an SSL error when using the latest version (4.10.0-1)?

2019-01-03T10:23:17.665+01:00> LVL:1 RC:-500 SCNET :scnet_client_open_ssl: SSL_connect: ssl_rv=-1, rv=1 (SSL_ERROR_SSL) 2019-01-03T10:23:17.665+01:00> LVL:1 RC:-500 SCNET :SSL Error Queue: err=336032002 (error:14077102:SSL routines:SSL23_GET_SERVER_HELLO:unsupported protocol)

The problem went away after I downgraded to version 4.9.0-1.