Hi,
In preparation for the upcoming release of X2Go Client 4.0.1.2, a nightly build of the Windows binary is available for download under:
http://code.x2go.org/releases/binary-win32/x2goclient/previews/4.0.1.2/
Although I am not an official X2Go project member (yet,) I have been working with Mike Gabriel over IRC. We ask that Windows users please test this build and report any bugs. We especially want users to report regressions against previous builds for Windows (4.0.0.3 and 4.0.1.0pre02). Remember that it is only a nightly build so it is not intended for production use.
More information about this build:
It is still compatible with Windows XP! It bundles VcXsrv 1.14.2.1 (2013-07-26) because all later versions of VcXsrv (starting with 1.14.3, released 2013-09-20) are incompatible with Windows XP.
It is built from commit 119635850c8408e45d2d2dca2f3c5b013f8da1c6 (2013-12-06)
The version of nx-libs is 3.5.0.21-lite
It is built according to the instructions here: http://wiki.x2go.org/doku.php/wiki:development:build-howto-mswin:x2goclient
All existing windows-specific bugs are probably still present. For example, bug #230 is still present, but the fix looks very easy so I intend to fix #230 soon.
For a high-level changelog of what has been fixed/improved in 4.0.1.2 so far, see: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=debian/changelog;h=11e...
-Mike
My apologies to anyone who tried to download this build but got a permission denied error.
About 1 hour ago, the permissions were fixed.
On Sat, Dec 7, 2013 at 9:19 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
Hi,
In preparation for the upcoming release of X2Go Client 4.0.1.2, a nightly build of the Windows binary is available for download under:
http://code.x2go.org/releases/binary-win32/x2goclient/previews/4.0.1.2/
Although I am not an official X2Go project member (yet,) I have been working with Mike Gabriel over IRC. We ask that Windows users please test this build and report any bugs. We especially want users to report regressions against previous builds for Windows (4.0.0.3 and 4.0.1.0pre02). Remember that it is only a nightly build so it is not intended for production use.
More information about this build:
It is still compatible with Windows XP! It bundles VcXsrv 1.14.2.1 (2013-07-26) because all later versions of VcXsrv (starting with 1.14.3, released 2013-09-20) are incompatible with Windows XP.
It is built from commit 119635850c8408e45d2d2dca2f3c5b013f8da1c6 (2013-12-06)
The version of nx-libs is 3.5.0.21-lite
It is built according to the instructions here: http://wiki.x2go.org/doku.php/wiki:development:build-howto-mswin:x2goclient
All existing windows-specific bugs are probably still present. For example, bug #230 is still present, but the fix looks very easy so I intend to fix #230 soon.
For a high-level changelog of what has been fixed/improved in 4.0.1.2 so far, see: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=debian/changelog;h=11e...
-Mike
On Sat, Dec 7, 2013 at 6:19 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
- It is still compatible with Windows XP! It bundles VcXsrv 1.14.2.1 (2013-07-26) because all later versions of VcXsrv (starting with 1.14.3, released 2013-09-20) are incompatible with Windows XP.
Are there any plans to split off a version for Windows XP compatibility, and to let the main version continue to get VcXsrv updates?
- For a high-level changelog of what has been fixed/improved in 4.0.1.2 so far, see: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=debian/changelog;h=11e...
I always like to look at changelogs, but I am not adept at navigating a gitweb. This changelog is quite different (and more informative for me) than the normal git log that I was able to navigate to myself.
How did you determine the URL for this particular changelog? Will that URL for the changelog stay the same in the future, or will a new URL be required when a new version is tagged/released? How would I find a changelog URL for a new version?
By the way, Michael DePaulo, thanks for your work on the Windows x2go client! It is nice to see it getting a bit more attention than it has in the past. I always had the impression the Windows x2goclient was the neglected step-child of the family!
Am 08.12.2013 23:37, schrieb John Williams:
- It is still compatible with Windows XP! It bundles VcXsrv 1.14.2.1 (2013-07-26) because all later versions of VcXsrv (starting with 1.14.3, released 2013-09-20) are incompatible with Windows XP.
Are there any plans to split off a version for Windows XP compatibility, and to let the main version continue to get VcXsrv updates?
Given that Microsoft's XP security support ends in April 2014, I'm guessing that X2Go support for XP could be dropped in May 2014.
[...]
By the way, Michael DePaulo, thanks for your work on the Windows x2go client! It is nice to see it getting a bit more attention than it has in the past.
+1!
I always had the impression the Windows x2goclient was the neglected step-child of the family!
No, that would be the Mac client. *g* (SCNR, but PubApp mode on Mac felt like kludged on last time I checked.)
-Stefan
On Sun, Dec 8, 2013 at 5:41 PM, Stefan Baur <newsgroups.mail2@stefanbaur.de> wrote:
Am 08.12.2013 23:37, schrieb John Williams:
- It is still compatible with Windows XP! It bundles VcXsrv 1.14.2.1 (2013-07-26) because all later versions of VcXsrv (starting with 1.14.3, released 2013-09-20) are incompatible with Windows XP.
Are there any plans to split off a version for Windows XP compatibility, and to let the main version continue to get VcXsrv updates?
That sounds like the best approach, but I would like to ask other project members what they think. And I am open to other ideas. After all, I think the only way to get VcXsrv security updates is to install the latest major version of VcXsrv. That means upgrading to VcXSrv to 1.14 now, to 1.15 when it comes out,, and so on. At least X2Go does not use every feature of VcXsrv (e.g., unsecured TCP connections), so not every security vulnerability in VcXsrv would actually affect X2Go.
Also, remember that the build instructions for X2Go Client for Windows consist of just installing VcXsrv to your program files folder and then copying and pasting VcXsrv's folder into the x2goclient folder. We do not link against VcXsrv. So feel free to replace the x2gofolder\VcXsrv folder with a newer version of VcXsrv. Doing so may not be officially supported by the X2Go project, but it is very likely to "just work"(TM).
Given that Microsoft's XP security support ends in April 2014, I'm guessing that X2Go support for XP could be dropped in May 2014.
This is something that I wanted to discuss on this mailing list. Personally, I think it sounds like a "killer use case" of X2Go Client to use it on Windows XP machines after May 2014. The XP machines could be secured by sysadmins by having their firewall turned on (to allow no incoming traffic), and their unpatched apps like IE blocked. The XP machines could then be used securely as dumb clients to X2Go Servers or RDP servers running Firefox, office suites, etc with all the latest patches installed. Of course, the machines could just be reformatted to run Linux. But many sysadmins are less comfortable with Linux, or their ill-informed bosses might order them to not reformat any XP machines.
[...]
By the way, Michael DePaulo, thanks for your work on the Windows x2go client! It is nice to see it getting a bit more attention than it has in the past.
+1!
Thanks guys! Like most unpaid open source developers I am contributing for fun (AKA, "Intellectual Stimulation", see Lakhani and Wolf' (2005)). I chose the Windows X2Go Client because I use it both at work and at home. (My home network is very sophisticated. In fact, I tested x2goclient on Windows XP 32-bit SP3 by installing XP onto a VM. I hosted the VM using virt-manager on a Fedora 19 machine that I use exclusively for hosting VMs. I then used virt-viewer + the spice protocol to access the XP VM's desktop at 32-bit color. (I couldn't use RDP because the XP RDP server defaults to 16-bit color or less, and the max you can raise it to is 24-bit.))
-Mike
Am 09.12.2013 00:21, schrieb Michael DePaulo:
Are there any plans to split off a version for Windows XP compatibility, and to let the main version continue to get VcXsrv updates? [...]
Also, remember that the build instructions for X2Go Client for Windows consist of just installing VcXsrv to your program files folder and then copying and pasting VcXsrv's folder into the x2goclient folder. We do not link against VcXsrv. So feel free to replace the x2gofolder\VcXsrv folder with a newer version of VcXsrv. Doing so may not be officially supported by the X2Go project, but it is very likely to "just work"(TM).
There's a menu setting to use a custom X server, too. So no one keeps you from using an older copy of VcXsrv by installing it to a different directory, then pointing the X2Go client to use that X server.
Whether or not that is a sane and safe thing to do, on the other hand ...
What might be more of a problem is libraries needed by x2goclient.exe itself (VCredist stuff) becoming unavailable for XP.
Given that Microsoft's XP security support ends in April 2014, I'm guessing that X2Go support for XP could be dropped in May 2014.
This is something that I wanted to discuss on this mailing list. Personally, I think it sounds like a "killer use case" of X2Go Client to use it on Windows XP machines after May 2014. The XP machines could be secured by sysadmins by having their firewall turned on (to allow no incoming traffic), and their unpatched apps like IE blocked. The XP machines could then be used securely as dumb clients to X2Go Servers or RDP servers running Firefox, office suites, etc with all the latest patches installed. Of course, the machines could just be reformatted to run Linux. But many sysadmins are less comfortable with Linux, or their ill-informed bosses might order them to not reformat any XP machines.
The problem with running XP past its expiration date is that a (software) firewall setting on the particular XP machine itself might not protect you from all evil. All it needs for that is a bug in the firewall code itself that chokes on a particularly crafted packet - and Microsoft will neither actively look for such bugs in XP's firewall, nor develop/deploy patches for it past April 2014.
The smart move, if you can't upgrade to a newer version of Windows, would be to go the Terminal Services route - for both Windows and Linux applications - and run the Clients as dumb terminals, possibly even without reformatting them, but by having them boot X2Go ThinClientEdition via PXE. From there, you can access RDP and X2Go sessions.
Similar to how X2Go Server packages for Lenny are still occasionally receiving updates thanks to companies contracting X2Go core developers, I would suggest that if a company insists on running XP past April 2014 and needs a working X2Go client, they should contract one of the developers to build a modified x2goclient.exe for them.
And who knows, some of my customers might even do that, we'll see.
-Stefan
On Sun, Dec 8, 2013 at 2:37 PM, John Williams <jwilliams4200@gmail.com> wrote:
I always like to look at changelogs, but I am not adept at navigating a gitweb. This changelog is quite different (and more informative for me) than the normal git log that I was able to navigate to myself.
How did you determine the URL for this particular changelog? Will that URL for the changelog stay the same in the future, or will a new URL be required when a new version is tagged/released? How would I find a changelog URL for a new version?
Ah, answered my own question. That changelog is an actual file in the git tree, for some reason under the debian directory at debian/changelog, even though it includes some entries applicable to the MS Windows client. Here is a shorter URL I navigated to by clicking on "raw" instead of "blob":
http://code.x2go.org/gitweb?p=x2goclient.git;a=blob_plain;f=debian/changelog...
On Sun, Dec 8, 2013 at 5:37 PM, John Williams <jwilliams4200@gmail.com> wrote:
On Sat, Dec 7, 2013 at 6:19 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
- For a high-level changelog of what has been fixed/improved in 4.0.1.2 so far, see: http://code.x2go.org/gitweb?p=x2goclient.git;a=blob;f=debian/changelog;h=11e...
I always like to look at changelogs, but I am not adept at navigating a gitweb. This changelog is quite different (and more informative for me) than the normal git log that I was able to navigate to myself.
How did you determine the URL for this particular changelog? Will that URL for the changelog stay the same in the future, or will a new URL be required when a new version is tagged/released? How would I find a changelog URL for a new version?
John, I forgot to reply to this question earlier.
What I linked you to was not a git changelog / commit log (I am not familiar with git terminology), but the debian/changelog file that is manually edited by x2go devs. This file is far easier to read than the full git changelog. That link is to the revision of that file from git hash 119635850c8408e45d2d2dca2f3c5b013f8da1c6 (2013-12-06), which is what 4.0.1.2pre01 is built from. When 4.0.1.2 is released, debian/changelog will most likely be updated to list additional changes. So you will not be able to use that URL; see the instructions below instead. I determined the URL by going to the git web, selecting that hash, and viewing the tree for it. I then browsed to the debian/changelog file within the tree.
Whenever a new version of x2goclient is released, the changelog since the last release is in the announcement. You can view the changelog for all releases of x2goclient by doing one of the following:
-Mike DePaulo
On Sat, Dec 7, 2013 at 6:19 PM, Michael DePaulo <mikedep333@gmail.com> wrote:
We ask that Windows users please test this build and report any bugs. We especially want users to report regressions against previous builds for Windows (4.0.0.3 and 4.0.1.0pre02). Remember that it is only a nightly build so it is not intended for production use.
Well, I have been using version 3.99.2.1 for months now because of the bug that was introduced right after that version that causes the Windows x2goclient to frequently hang when trying to resume sessions.
I tested 4.0.1.2 and it has the same problem. So that would be a regression that goes all the way back to just after 3.99.2.1
Since this bug was discussed on the x2go-user list in October (thread started by Sebastian Flothow), I had assumed that it already had a detailed bug report. But I just checked, and the only bug report I could find was #263 that was missing some details. So I submitted the information below to the #263 bug report, but it has not shown up yet. Either I did something wrong, or it just takes a while. Anyway, here is what I sent:
I believe I have been experiencing the same bug as reported by Edouard Villeneuve <evilleneuve@pldagroup.com>
One important piece of information is that the bug does not appear in x2goclient 3.99.2.1 (3.99.2.2 about box).
The bug appears to have been introduced between 3.99.2.1 and 3.99.3.1-pre1, since all versions from 3.99.3.1-pre1 and later have the bug. Also, it does NOT appear to be a consequence of the new pulseaudio version, since the old interims version has the same issue.
Windows client: 3.99.2.1 filename (3.99.2.2 about box): works 3.99.3.1-pre1_interims (old pulseaudio): hangs 4.0.0.3: hangs 4.0.0.3_interims (old pulseaudio): hangs 4.0.1.0-pre02 : hangs 4.0.1.2 : hangs
This was also discussed on the x2go-user email list in a thread started by Sebastian Flothow sebastian.flothow at gip.com with the subject "X2Go client 4.0.0 can't resume certain sessions"
http://lists.berlios.de/pipermail/x2go-user/2013-October/001684.html
Here is the addtional information that Mike Gabriel requested about this bug (note that I am not the original reporter for this bug):
Server distro: Archlinux arch packages: x2go-agent 3.5.0.21-1 x2goclient 4.0.1.1-1 x2goserver 4.0.1.8-1
x2goversion: x2goagent: 3.5.0.21 x2goserver: 4.0.1.6 x2goserver-compat: 4.0.1.6 x2goserver-extensions: 4.0.1.6 x2goserver-fmbindings: 4.0.1.6 x2goserver-printing: 4.0.1.6 x2goserver-pyhoca: 4.0.1.6 x2goserver-xsession: 4.0.1.6
Server home directories are local