Search Criteria
Package Details: vmware-horizon-usb 2203-1
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://www.vmware.com/go/viewclients |
| Licenses: | custom |
| Submitter: | eworm |
| Maintainer: | eworm |
| Last Packager: | eworm |
| Votes: | 42 |
| Popularity: | 0.42 |
| First Submitted: | 2015-01-08 15:17 (UTC) |
| Last Updated: | 2022-04-05 15:02 (UTC) |
Dependencies (5)
- glib2 (glib2-clear, glib2-quiet, glib2-selinux, glib2-nodocs-git, glib2-git, glib2-patched-thumbnailer)
- vmware-horizon-client
- librsvg (librsvg-minimal-git, librsvg-og, librsvg-git) (make)
- libxslt (libxslt-git) (make)
- patchelf (make)
Required by (1)
- vmware-horizon-client (optional)
Latest Comments
firemage78 commented on 2022-04-06 16:29 (UTC)
I am running the znver2 kernel from the AUR, and every time I try to load into my client desktop, vmware-view opens and then immediately shuts down. Running vmware-view from cmdline does the same with no output. I am not sure where it logs events to start troubleshooting. As a side note, this version runs fine, albeit a bit slow, on the LTS kernel.
Perfi commented on 2022-04-06 06:57 (UTC)
A couple notes on the behavior of the sticky keys bug in 2203.
Open a terminal window and run
xev. If you hold down <kbd>Control_L</kbd>, it should send a singleKeyPressevent:and then when you release it, you'll get a
KeyReleaseevent:However, once I connect to a virtual desktop through Horizon and interact with the desktop in any way, I get this neat behavior only on the virtual desktop. If I try repeating it on the parent OS, I get a series of alternating
KeyPressandKeyReleaseevents at incrementing (Press, ~40 time units delay, Release, KeyPress, repeat)timevalues. It's not that <kbd>Control_L</kbd> is not registered - it's that Horizon somehow messses turns the pressed down state into a series of events.I've replicated this bug with <kbd>Control_L</kbd>, <kbd>Control_R</kbd> and <kbd>Shift_R</kbd>. Other keys don't seem to be affected.
This persists after shutting down Horizon and until I log out of my X11 session.
I'd appreciate any tips, even on where to report this to :(
Perfi commented on 2022-04-06 06:16 (UTC)
The "sticky keys" issue (once CTRL is pressed on the virtual machine, it ceases to function in the parent OS) is still present for me on 2203.
jose1711 commented on 2022-03-15 21:48 (UTC)
@eworm great news finally, thanks for sharing! and i can confirm it finally works!
eworm commented on 2022-03-15 15:10 (UTC)
VMware just released a fixed version, I already pushed the changes. Go and get it!
eworm commented on 2022-03-08 13:53 (UTC)
I have a non-public test release (2111.1 / 8.4.1 / build 53939787) from VMware that is said to fix the keyboard issue. To date I could not proof any different... So stay tuned for the next release!
nihalani commented on 2022-02-18 20:48 (UTC)
@KorvinSilver. Can you try adding the argument --no-sandbox to the .desktop file for VMWare Client? I had a similar issue with another application and this may serve as a stop gab solution until a more permanent one is found.
eworm commented on 2022-02-18 09:06 (UTC)
I guess that's a new security feature from KDE/Plasma, where all launched applications are sandboxed in a systemd service. Looks like this breaks the horizon client. I do not have KDE/Plasma here, so no idea what breaks.
KorvinSilver commented on 2022-02-18 08:04 (UTC) (edited on 2022-02-18 08:07 (UTC) by KorvinSilver)
I updated my system and after reboot vmware-view won't run anymore unless I start it from the terminal. I'm using KDE/Plasma and if I click on its icon, KDE shows the cursor animation for the launch for a second then nothing happens. If I run it from terminal or set the shortcut settings to include run in terminal, it works. journalctl shows this only at the time:
So basically systemd says it's started but somehow it closes or crashes without a trace I could find. The other lines show up with everything else I start like this so unsure if they mean anything here. The exact same thing happens with nbtexplorer-bin by the way also from the AUR. No idea what that means or even what could be responsible. I have other things installed from AUR but everything else works properly. Also if I start it from terminal, there's no systemd message for it in the log.
kodur commented on 2022-01-26 20:29 (UTC)
Unable to get USB to initialize with VMware Horizon Client Version 2111 Build 8.4.0 (build-18957622).
2022-01-26 15:25:13.741-05:00: vmware-view 3233| CdkViewUsbCbFunc: callback called, reason=VIEWUSB_CB_ERROR, desktopHandle=0x5608cd452160, msgId=213, msgString="IDS_DROPDOWN_DEVICES_NOT_AVAILABLE" 2022-01-26 15:25:13.741-05:00: vmware-view 3233| CdkViewUsbCbFunc: Viewusblib callback called, open channel failed, desktopHandle=0x5608cd452160, usbAvailable=0.eworm commented on 2022-01-25 12:42 (UTC)
Others are suffering the same issue with stuck keys: https://communities.vmware.com/t5/Horizon-for-Linux/Horizon-Client-for-Linux-fouls-key-repeating-permanently/m-p/2835084
Please post there and/or open an official support request if possible.
eworm commented on 2022-01-17 14:59 (UTC)
Added packages:
Please test...
Anybody had success fixing the stuck keys issue?
sotix commented on 2022-01-06 07:04 (UTC) (edited on 2022-01-06 08:05 (UTC) by sotix)
@fordprefect Thanks for replying.
I did use git clone and makepkg beforehand. Now that the bundle didn't work I also tried
makepkg -sri
but that results in:
Am I on the wrong track?
EDIT: ok I got it after carefully reading the above error: I had to install vmware-keymaps from aur, this one: https://aur.archlinux.org/packages/vmware-keymaps/
now it works
fordprefect commented on 2022-01-06 06:56 (UTC)
@Sotix: Hello and welcome. You are missing important things here, you are not using the AUR package, but the upstream installer. A good start is the Arch wiki (wiki.archlinux.org), search for AUR, makepkg, pacman, etc and understand those. That will give you an idea how arch works and what the AUR is about.
sotix commented on 2022-01-06 06:41 (UTC) (edited on 2022-01-06 06:42 (UTC) by sotix)
The installer says "Installation was unsuccessfull."
What I did:
The installer pops up, I can select the packages I want but even if non are selected the above error is shown after clicking on "next". Is there an error-log somewhere? I am new to aur and arch in general.
zeroconf commented on 2021-12-13 19:59 (UTC)
After updating system, rebuilding package:
... rebooting system, checkrebuild command claims that package vmware-horizon-client, vmware-horizon-usb still needs to be rebuilt, although it is working properly. I hope this can be fixed. Below is the verbosed output of missing libraries locations.
cwestpha commented on 2021-12-07 21:06 (UTC)
Any chance we can get the missing components for the product? Most are covered but some are missing from the AUR since they got added in the last few releases: https://docs.vmware.com/en/VMware-Horizon-Client-for-Linux/2111/horizon-client-linux-installation/GUID-DE283634-D0D4-45C2-B0C8-E203CAC0E38B.html
i.e. Media Optimization for Microsoft Teams
MastaShake commented on 2021-12-05 22:11 (UTC)
I also have the stuck key issue since update to 2111, no issues on 2106 like this though.
neilsimp1 commented on 2021-12-04 16:29 (UTC)
I have the issue of stuck keys very rarely, but that has been across several versions.
More recently, 2111-1 only displays on 2/3 of my monitors, even though the settings detect the third monitor and it's "Full screen on all monitors". Downgrading fixed that.
eworm commented on 2021-12-03 10:45 (UTC)
I have see this behavior of stuck keys, also with other 8.x releases. No idea what causes this...
jose1711 commented on 2021-12-03 09:21 (UTC)
ran into an issue where a single keypress resulted in a long stream of repeats. anyone else having the same issue?
Akss13 commented on 2021-11-25 14:57 (UTC)
It is working now. Thanks.
eworm commented on 2021-11-24 10:32 (UTC)
Updated the url, the package should build now.
Akss13 commented on 2021-11-22 00:46 (UTC) (edited on 2021-11-24 00:38 (UTC) by Akss13)
As others have reported, I'm also facing the same issue:
Looks like https://sources.gentoo.org now redirects to https://gitweb.gentoo.org/ (Not sure why this change) Due to this, line 33 in PKGBUILD returns an HTML file which is nothing but the page https://gitweb.gentoo.org/ So if line 33 in PKGBUILD is changed to the following
and the SHA256 sum is updated, we should be good.
nesk_aur commented on 2021-11-21 05:42 (UTC)
Downloaded vmware-bundle.eclass-2106.1 is an HTML file.
ashdev805 commented on 2021-11-17 07:28 (UTC) (edited on 2021-11-17 07:29 (UTC) by ashdev805)
Thanks for the workaround, @nihalani. The workaround given by @nihalani works fine. I was confused on the usage of
--mflags --skipintand tried it in mine which did not work. So, I cloned the git repo and changed the source inPKGBUILDand built and installed using commandmakepkg -si --skipintegnihalani commented on 2021-11-15 17:37 (UTC) (edited on 2021-11-15 17:37 (UTC) by nihalani)
Oof this was a weird error: basically, for some reason, the eclass url is now returning a webpage. I took at the webpage in the html format and its the homescreen of the gentoo git page, ie the file wasn't found. In the PKGBUILD you need to update the source of the eclass file
"vmware-bundle.eclass-${pkgver}::https://sources.gentoo.org/proj/vmware.git/plain/eclass/vmware-bundle.eclass"
I found that "vmware-bundle.eclass-${pkgver}::https://gitweb.gentoo.org/proj/vmware.git/plain/eclass/vmware-bundle.eclass" works
Once you have that the shasums are invalid so I had also to use the --mflags --skipint to skip that shasum checks.
@alaiz @eworm
aliaz commented on 2021-10-24 21:55 (UTC)
i got a validity check error,please fix this
==> ERROR: One or more files did not pass the validity check!
coreyberla commented on 2021-07-23 15:34 (UTC) (edited on 2021-07-23 15:35 (UTC) by coreyberla)
Have you considering using the tarball version (instead of the installer bundle). It simplifies the PKGBUILD a lot and reduces the effort for someone to verify that it's not malicious. I ended up building my own just for the client, let me know if you'd like help finishing the rest.
jskier commented on 2021-07-21 14:13 (UTC)
@eworm, sorry my mistake, looks like it was the cache, thank you!
eworm commented on 2021-07-21 13:45 (UTC)
Works for me... Possibly you have an old vmware-bundle.eclass file in your source cache?
jskier commented on 2021-07-21 13:28 (UTC)
Fix file integrity verification please.
vmware-bundle.eclass ... FAILEDh2ash commented on 2021-02-26 14:27 (UTC)
@starfall07g, you must go to Preferences and choose "Do not verify server identity certificates"
warlord commented on 2021-01-18 12:16 (UTC)
I'm relatively new to arch and ran into an issue installing this. It was just that the vmware-keymaps was required to be installed first. I know it's listed in the dependencies above, but it was easily missed by me.
Once keymaps was installed it works just great.
Many thanks.
eworm commented on 2020-12-31 20:16 (UTC)
I guess you have an old file in your cache. Remove that and try again.
galeot commented on 2020-12-31 15:24 (UTC)
Can't build due to sha256sum fail on vmware-bundle.eclass
quite strange, as key in PKGBUILD seems to be correct
eworm commented on 2020-12-27 21:51 (UTC)
Updated url, please pull and retry.
Compassion commented on 2020-12-27 04:06 (UTC)
The dependency for https://sources.gentoo.org/cgi-bin/viewvc.cgi/gentoo-x86/eclass/vmware-bundle.eclass no longer exists.
starfall07g commented on 2020-08-07 15:44 (UTC)
I got this error message: "Failed to connect to the View Connection Server. The server provided an invalid certificate. The certificate authority is invalid or incorrect", while attempting to connect to VDI using the latest VMware distribution for Arch. When I went to Preference to clear the message, I got an http instead of https connection to the VDI. The same server address had an https connection in Chrome.
How can I solve the error while making secure connection? Concrete steps are very valuable.
KorvinSilver commented on 2020-07-31 06:05 (UTC) (edited on 2020-07-31 06:10 (UTC) by KorvinSilver)
I have some issues since version 5.0, mainly when I log in to my VDI, if I click anything, Horizon freezes and crashes the entire system so bad I have to reboot. The problem is that my company started to mandate the usage of the latest releases (which is ironic in a place where the most recent software is at least two years old) so I may not be able to use 5.0 for long. Any ideas? This is with the entire system updated this morning:
For comparison v5.0:
jackstdve commented on 2020-06-30 13:54 (UTC)
I'm having some USB issues I was hoping to get some help with. When I connect to a server, USB begins initializing before turning into a
USB Unavailablemessage. I've installedvmware-horizon-usband startedvmware-horizon-usb.service. It seems there is some virtual channel not available for access.Mushoz commented on 2020-06-18 13:34 (UTC) (edited on 2020-06-18 13:39 (UTC) by Mushoz)
On second thought, I don't think it's a pcoip issue specifically. I've tried forcing a specific protocol through the --protocol switch, but it still failed.
@eworm: I do not see any "not founds". All libraries are properly found.
@forprefect: I do not have those options for some reason. I was able to select a protocol via commandline switches however.
I am connecting to a public domain, though. As far as I understand, that means it will set up a HTTPS tunnel and proxy the traffic over that tunnel. Maybe that is somehow not working?
Do note I am running 5.4.0 version instead of 5.4.1. But that was part of my troubleshooting (I downgraded). I initially used 5.4.1 and was getting the exact same problem.
As for what happens: I am able to connect and log in to the server. It will then show 1 desktop that I can connect to. Opening that will show the interface that should display the remote desktop, but it's completely black. After 1-2 seconds the black display disappears and I am back in the screen where I can select which desktop to connect to.
Using a Windows PC in the same network to connect to the same remote location works perfectly fine. But where's the fun in using Windows, right? ;)
Including full logs below:
Diving into the mentioned log, we get this:
eworm commented on 2020-06-18 13:01 (UTC)
Well,
vmware-remotemksis installed to/usr/lib/vmware/view/client/vmware-remotemks... No idea aboutvmware-remotemks-container.I get the same message from
vmware-view-lib-scan, but PCoIP connection works for me.Do you see any "not found" running
LD_LIBRARY_PATH=/usr/lib/vmware/ lddon/usr/lib/vmware/view/client/vmware-remotemksand/usr/lib/libpcoip_client.so?fordprefect commented on 2020-06-18 12:51 (UTC)
@Mushoz: Have you tried other protocols than PCoIP? I can choose them by right-clicking into a machine icon and choosing from the options. The other error says "ignore if you don't use" and thats what I'd do.
Mushoz commented on 2020-06-18 12:38 (UTC) (edited on 2020-06-18 12:39 (UTC) by Mushoz)
I keep getting the following error when trying to connect to a workstation at work over a remote connection:
vmware-view 83240| cdk_pcoip_desktop_on_connection_state_changed: RemoteMKS connection failedIt seems like it's trying to use a pcoip connection, which is failing. Running the included vmware-view-lib-scan, I get the following message regarding pcoip:
Any idea how I can fix this? Google searches haven't been very successful so far.
eworm commented on 2020-04-16 08:17 (UTC)
Currently vmware-horizon-rtav does not find any microphone, thus can't redirect it. Possibly that's your issue. I guess this is related to our recent pulseaudio, but I can't tell for sure.
I've never heard of Virtualization Pack for Skype for Business. Will have to investigate when I have some spare time.
arialdomartini commented on 2020-04-16 07:20 (UTC) (edited on 2020-04-16 07:43 (UTC) by arialdomartini)
I cannot run Skype for Business but in Fallback Mode (hence, no audio calls are possible), even with vmware-horizon-mmr and vmware-horizon-rtav installed. AFAIK this should be handled by Virtualization Pack for Skype for Business, included in the VMware Horizon Client itself. Any hints?
themez commented on 2020-03-25 13:37 (UTC)
Makes sense now. Thank-you for your time.
eworm commented on 2020-03-25 06:09 (UTC)
You need to install vmware-keymaps, it's a separate package in AUR.
themez commented on 2020-03-25 00:25 (UTC)
Hello eworm. I am getting this error when trying to install: Error: Failed to prepare transaction: could not satisfy dependencies: unable to satisfy dependency 'vmware-keymaps' required by vmware-horizon-client I installed a week or so ago on a test system without any issue.
eworm commented on 2020-03-18 16:17 (UTC)
Probably not. ;) I do not have vmware-horizon-virtual-printing installed myself, so I did not notice. Just updated.
dkadioglu commented on 2020-03-18 16:04 (UTC) (edited on 2020-03-18 16:04 (UTC) by dkadioglu)
Is the dependency for openssl098 still necessary? As far as I can see, the virtual printing service still runs without an installed openssl098.
eworm commented on 2020-03-16 10:07 (UTC)
You do not need to install the package. But this package is the only one I changed dependencies for. All other packages have no difference from 5.3.0-3 to 5.3.0-4. I guess you updated other packages that caused the issue.
lordbalmung commented on 2020-03-14 23:03 (UTC)
@eworm
Not at first but I did after I read your comment. Now the application has gone so flakey that it takes ~10 attempts to successfuly access my remote desktop. This is what I found in /tmp/vmware-$user/vmware-mks-$pid.log. Hope this is useful
eworm commented on 2020-03-14 20:02 (UTC)
Only thing I changed was dependencies. Do you have vmware-horizon-mmr installed at all?
lordbalmung commented on 2020-03-14 18:41 (UTC) (edited on 2020-03-14 19:00 (UTC) by lordbalmung)
Since updating to 5.3.0-4, the client cannot open full-screen in gnome, at least not completely. The top bar is still visible which causes the remote view to contain annoying scrollbars. Gnome version 3.360 Wayland (Edit: The same thing happens in Gnome XOrg)
idrozd commented on 2020-02-20 11:08 (UTC) (edited on 2020-02-20 13:28 (UTC) by idrozd)
The 5.3 (5.2) client runs normally in KDE plasma only as root. In other DE (gnome, mate, xfce4) - works normally under a normal user. How do I find the cause of the problem? Advise...
eworm commented on 2020-01-18 21:35 (UTC)
Bad idea. You should build packages and install that.
jllinux commented on 2020-01-17 23:31 (UTC)
I tried installing(Manjaro) via: sudo sh ./Downloads/VMware-Horizon-Client-5.3.0-15208949.x64.bundle
and after typing "yes" to agree i just get a:
Installation was unsuccessful.
Any thoughts on how to install?
cawj4gj02 commented on 2019-11-15 23:50 (UTC)
yes. I use full screen on all monitors and enable display on the secondary monitor. Pulldown of top bar can be triggered from the same location on the primary monitor. Must be some recent bug. This wasn't the case in a previous version.
ekkelett commented on 2019-11-12 11:34 (UTC)
Has anyone else experienced the issue where the docked top bar won't come down when you hover over it?
theonelucas commented on 2019-10-31 11:14 (UTC)
@KorvinSilver In case of problems with the display resolution just disable display scaling. In the Linux build of the software it doesn't show the option to disable scaling, so you have to add the line
view.enableDisplayScaling = "FALSE"to the file~/.vmware/view-preferences.KorvinSilver commented on 2019-06-07 09:10 (UTC) (edited on 2019-06-07 20:27 (UTC) by KorvinSilver)
New update, new problem. My fullHD monitor is recognized as having 2490x1400 resolution. They say the problem is not on the VDI side but with the client. I can barely work, everything's so small and since all the display settings are locked on the system (enterprise logic). Any idea what the problem might be? There was also an nvidia update before this first occurred as well. For now I downgraded to 5.0.0-1, that works.
phouverney commented on 2019-05-17 17:09 (UTC) (edited on 2019-05-17 17:12 (UTC) by phouverney)
I resolved the problem @KorvinSilver. If you are using a VPN or proxy, you need to use cntlm to tunnel all connection.
after doing that, you can try start again you vmware-horizon-client
KorvinSilver commented on 2019-05-04 08:52 (UTC)
Deleted all packages and reinstalled it from the archlinuxcn repo. Now it works, although in theory it's the same version just prebuilt. Here's the output difference:
eworm commented on 2019-05-03 13:27 (UTC)
I can't reproduce, sorry... Everything works as expected for me.
Bednar commented on 2019-05-03 13:16 (UTC)
I am having the exact same issue as KorvinSilver.
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.
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.pngtoIcon=vmware-view? By changing it the icon will correctly show in Rofi and other launchers.It could be
vmware-horizon-client.desktopinstead, 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?
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)
daj63 commented on 2017-07-09 07:37 (UTC)
MrMuffin commented on 2017-07-08 15:46 (UTC)
eworm commented on 2017-07-07 20:30 (UTC)
MrMuffin commented on 2017-07-07 20:17 (UTC)
eworm commented on 2017-06-09 14:30 (UTC)
eworm commented on 2017-06-09 13:59 (UTC)
hagemajr commented on 2017-05-13 04:00 (UTC)
eworm commented on 2017-04-07 17:41 (UTC)
erich1527 commented on 2017-04-07 16:20 (UTC)
Schlitzkrieg commented on 2017-03-23 12:09 (UTC)
fordprefect commented on 2016-12-11 09:32 (UTC)
xerxies commented on 2016-09-16 18:33 (UTC) (edited on 2016-09-16 18:36 (UTC) by xerxies)
eworm commented on 2016-09-16 05:52 (UTC)
xerxies commented on 2016-09-15 21:49 (UTC)
cteneyck commented on 2016-08-18 02:03 (UTC) (edited on 2016-08-18 02:03 (UTC) by cteneyck)
shimi commented on 2016-06-21 14:02 (UTC) (edited on 2016-06-21 14:03 (UTC) by shimi)
eworm commented on 2016-06-02 08:11 (UTC)
waldauf commented on 2016-06-02 07:55 (UTC)
eworm commented on 2016-06-02 07:35 (UTC)
waldauf commented on 2016-06-02 07:30 (UTC)
jskier commented on 2016-05-25 12:54 (UTC)
eworm commented on 2016-05-25 12:34 (UTC)
shimi commented on 2016-05-24 14:40 (UTC)
lectrode commented on 2016-03-14 20:21 (UTC)
eworm commented on 2016-03-10 15:35 (UTC)
billbrown commented on 2016-03-10 15:25 (UTC)
iozen commented on 2016-01-12 16:30 (UTC)
eworm commented on 2015-09-04 07:34 (UTC)
s_root commented on 2015-08-25 09:26 (UTC)
Henry78 commented on 2015-08-12 07:49 (UTC)
eworm commented on 2015-08-11 19:47 (UTC)
shkercuh commented on 2015-08-11 18:01 (UTC)
festerman commented on 2015-08-01 14:55 (UTC)
eworm commented on 2015-07-31 09:35 (UTC)
Muflone commented on 2015-07-31 08:58 (UTC)
eworm commented on 2015-07-16 14:56 (UTC)
debugrr commented on 2015-07-16 14:06 (UTC)
debugrr commented on 2015-07-16 14:06 (UTC)
eworm commented on 2015-04-23 08:08 (UTC)
Mountainerd commented on 2015-04-22 17:24 (UTC)
Muflone commented on 2015-03-28 11:58 (UTC)
eworm commented on 2015-03-25 18:37 (UTC)
Muflone commented on 2015-03-25 16:06 (UTC)
eworm commented on 2015-03-25 15:59 (UTC)
Muflone commented on 2015-03-25 15:48 (UTC)
eworm commented on 2015-01-13 08:00 (UTC)
festerman commented on 2015-01-13 07:51 (UTC)
festerman commented on 2015-01-13 07:48 (UTC)
eworm commented on 2015-01-13 07:39 (UTC)
festerman commented on 2015-01-13 07:16 (UTC)