Package Details: vmware-horizon-smartcard 2406-2

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 - smartcard authentication
Upstream URL: https://customerconnect.omnissa.com/downloads/info/slug/desktop_end_user_computing/vmware_horizon_clients/horizon_8
Licenses: custom
Submitter: eworm
Maintainer: eworm
Last Packager: eworm
Votes: 55
Popularity: 0.21
First Submitted: 2015-01-08 15:17 (UTC)
Last Updated: 2024-08-20 07:04 (UTC)

Latest Comments

« First ‹ Previous 1 .. 6 7 8 9 10 11 12 13 14 15 16 17 Next › Last »

KorvinSilver commented on 2019-05-03 07:06 (UTC) (edited on 2019-05-03 07:10 (UTC) by KorvinSilver)

Stopped working today, no idea why, there's a lot of errors in the output. I can log in to the server I'm using, start the connection but it crashes a few seconds later before the desktop could load. I can log in from elsewhere, only this one's broken.

Using log file /tmp/vmware-korvin/vmware-horizon-client-1481.log
2019-05-03 08:54:02.864+02:00: vmware-view 1481| Failed to open file “/etc/vmware/udpProxy/config”: No such file or directory
2019-05-03 08:54:05.629+02:00: vmware-view 1481| udpProxyLib: FECHostSocket_Specialise: failed to get desired receive bufsize: 425984

2019-05-03 08:54:05.629+02:00: vmware-view 1481| udpProxyLib: socket 101 transition to state SYN_SENT, reason FECSocketDoConnect refCount 4

2019-05-03 08:54:05.659+02:00: vmware-view 1481| udpProxyLib: socket 101 transition to state CLOSED, reason FECSocketDoClose refCount 6

2019-05-03 08:54:37.316+02:00: vmware-view 1481| g_file_read_link: assertion 'error == NULL || *error == NULL' failed
2019-05-03 08:54:42.742+02:00: vmware-view 1481| g_file_read_link: assertion 'error == NULL || *error == NULL' failed
2019-05-03 08:54:45.611+02:00: vmware-view 1481| cdk_remote_desktop_get_usb_controller: assertion 'CDK_IS_REMOTE_DESKTOP(remote)' failed
2019-05-03 08:54:45.611+02:00: vmware-view 1481| void cdk_usb_controller_set_available(gpointer, gboolean): assertion 'controller != NULL' failed
2019-05-03 08:54:45.612+02:00: vmware-view 1481| cdk_remote_desktop_get_usb_controller: assertion 'CDK_IS_REMOTE_DESKTOP(remote)' failed
2019-05-03 08:54:45.612+02:00: vmware-view 1481| void cdk_usb_controller_set_available(gpointer, gboolean): assertion 'controller != NULL' failed
2019-05-03 08:54:45.629+02:00: vmware-view 1481| Failed to exec kreadconfig --file kscreensaverrc --group ScreenSaver --key Timeout
2019-05-03 08:54:45.632+02:00: vmware-view 1481| Failed to exec kreadconfig --file /home/korvin/.config/kscreenlockerrc --group Daemon --key Timeout --default 5
2019-05-03 08:54:45.708+02:00: vmware-view 1481| rmksContainer(1555): HostinfoReadDistroFile: Cannot work with empty file.
2019-05-03 08:54:45.914+02:00: vmware-view 1481| Source ID 2144 was not found when attempting to remove it
2019-05-03 08:54:45.982+02:00: vmware-view 1481| rmksContainer(1555): CreateMKSInterface: Remote MKS not yet present, queueing CheckForMount
2019-05-03 08:54:45.982+02:00: vmware-view 1481| rmksContainer(1555): Caught child exit with status 0x500, requesting container exit
2019-05-03 08:54:45.982+02:00: vmware-view 1481| rmksContainer(1555): ProcessPollCb: received exit request, shutting down...
2019-05-03 08:54:55.986+02:00: vmware-view 1481| rmksContainer(1555): Killing vmware-remotemks child: 616
^C2019-05-03 08:55:13.625+02:00: vmware-view 1481| Source ID 2070 was not found when attempting to remove it
2019-05-03 08:55:13.626+02:00: vmware-view 1481| Source ID 2202 was not found when attempting to remove it

ekkelett commented on 2019-03-18 14:31 (UTC)

@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 (UTC)

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

eworm commented on 2019-03-15 09:51 (UTC)

Please install vmware-keymaps from AUR.

slav commented on 2019-03-15 07:12 (UTC)

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 (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?