Search Criteria
Package Details: vmware-horizon-client 2406-2
Package Actions
Git Clone URL: | https://aur.archlinux.org/vmware-horizon-client.git (read-only, click to copy) |
---|---|
Package Base: | vmware-horizon-client |
Description: | VMware Horizon Client connect to VMware Horizon virtual desktop |
Upstream URL: | https://customerconnect.omnissa.com/downloads/info/slug/desktop_end_user_computing/vmware_horizon_clients/horizon_8 |
Licenses: | custom |
Conflicts: | vmware-horizon-pcoip, vmware-horizon-teams-optimization, vmware-view-client, vmware-view-open-client, vmware-view-open-client-beta |
Replaces: | vmware-horizon-pcoip, vmware-horizon-teams-optimization |
Submitter: | eworm |
Maintainer: | eworm |
Last Packager: | eworm |
Votes: | 55 |
Popularity: | 0.126960 |
First Submitted: | 2015-01-08 15:17 (UTC) |
Last Updated: | 2024-08-20 07:04 (UTC) |
Dependencies (25)
- binutils
- expat (expat-gitAUR)
- gcc-libs (gcc-libs-gitAUR, gccrs-libs-gitAUR, gcc11-libsAUR, gcc-libs-snapshotAUR)
- glib2 (glib2-gitAUR, glib2-selinuxAUR, glib2-patched-thumbnailerAUR)
- gtk3 (gtk3-no_deadkeys_underlineAUR, gtk3-classicAUR, gtk3-classic-xfceAUR, gtk3-patched-filechooser-icon-viewAUR)
- libudev0-shim
- libxml2 (libxml2-gitAUR, libxml2-2.9AUR)
- libxss
- libxtst
- openssl (openssl-gitAUR, openssl-staticAUR)
- vmware-keymapsAUR
- librsvg (librsvg-gitAUR) (make)
- libxslt (libxslt-gitAUR) (make)
- patchelf (patchelf-gitAUR) (make)
- alsa-lib (optional) – audio support via alsa
- freerdp (freerdp-gitAUR) (optional) – RDP remote desktop connections
- libpulse (pulseaudio-dummyAUR, libpulse-gitAUR) (optional) – audio support via pulse sound server
- rdesktop (optional) – RDP remote desktop connections
- vmware-horizon-html5mmrAUR (optional) – HTML5 MultiMedia Redirection
- vmware-horizon-integrated-printingAUR (optional) – integrated printing
- Show 5 more dependencies...
Latest Comments
« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 18 Next › Last »
jskier commented on 2019-02-08 17:06 (UTC)
@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 (UTC) (edited on 2019-01-29 22:37 (UTC) by xerxies)
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 (UTC)
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 (UTC)
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 (UTC)
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 (UTC)
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.
jvybihal commented on 2017-09-07 07:33 (UTC)
eworm commented on 2017-07-09 19:53 (UTC)
jskier commented on 2017-07-09 19:25 (UTC) (edited on 2017-07-09 19:26 (UTC) by jskier)
eworm commented on 2017-07-09 12:20 (UTC)
« First ‹ Previous 1 .. 7 8 9 10 11 12 13 14 15 16 17 18 Next › Last »