So here is the fix for VcXsrv (which is bundled with X2Go Client) that I ported from Cygwin XWin: https://github.com/ArcticaProject/vcxsrv/commit/d45db884b19a0f081fcd259e3b33...
Here is a test build of VcXsrv : https://github.com/ArcticaProject/vcxsrv/releases/tag/1.17.0.0-2-bug4test1 (I do not make a test build of X2Go Client available yet, so you'll have to test it via the "X.Org Server settings" GUI in X2Go Client.)
And here is the issue against VcXsrv (X2Go/Arctica Builds): https://github.com/ArcticaProject/vcxsrv/issues/4
Read that issue for more details on why this bug happens with X2Go (and its component nx-libs.) Discussion over the details of the patch should be discussed there (or in a PR.)
However, If I release X2Go Client 4.0.4.1 (or an update to 4.0.4.0) with this fix, then sessions started on X2Go Client for Windows 4.0.4.0-2015.06.24 and earlier can not be resumed on the new version. This could be very disruptive to users.
Does anyone have any thoughts on this dilemma?
-Mike#2
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA256
Am 28.06.2015 um 02:54 schrieb Michael DePaulo:
However, If I release X2Go Client 4.0.4.1 (or an update to 4.0.4.0) with this fix, then sessions started on X2Go Client for Windows 4.0.4.0-2015.06.24 and earlier can not be resumed on the new version. This could be very disruptive to users.
Does anyone have any thoughts on this dilemma?
Don't we have the x.x.x.x versioning scheme for such reasons? Bump the version number up in a position that indicates "things may break" and all should be good, no?
Or could you create a patch that allows toggling between the two modes of operation, and when the first reconnect fails, try it with the other mode?
- -Stefan
BAUR-ITCS UG (haftungsbeschränkt) Geschäftsführer: Stefan Baur Eichenäckerweg 10, 89081 Ulm | Registergericht Ulm, HRB 724364 Fon/Fax 0731 40 34 66-36/-35 | USt-IdNr.: DE268653243 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2
iQEcBAEBCAAGBQJVj7oZAAoJEG7d9BjNvlEZSXMH/iXBTzzP8txVG/K1lKPpKOeX nBO/emM8rdSXFcTOi4u1cX3cTaVbW+gDN8VzxXhTv9kG1B/2GoYdozmjcMQT9y3K QBF2ufkQwFzrxG8+v8K9liVFfplyaCoBHskK8tLBEsDhl0fJbHtIJ39KM2CzOpz8 tlPsUO/oAZkghkFLDQQ28iT34mVspRS7n7L7c6+Cg2OBS8XFs+SLJf4I1NbHua2H 1ccRR+fkWb6tfy0khOrB6l4+XzfKV6CgY31y3hhCL6L1Zc8VyUOHqSe6qX/su09A /ZmMXDvMih5x1UjI4qsIv3DLKvPc+Iqxg3GyXcUnyBUVwmj6YhZHZO9CKKJzqQs= =SoQX -----END PGP SIGNATURE-----
On Sun, Jun 28, 2015 at 5:10 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 28.06.2015 um 02:54 schrieb Michael DePaulo:
However, If I release X2Go Client 4.0.4.1 (or an update to 4.0.4.0) with this fix, then sessions started on X2Go Client for Windows 4.0.4.0-2015.06.24 and earlier can not be resumed on the new version. This could be very disruptive to users.
Does anyone have any thoughts on this dilemma?
Don't we have the x.x.x.x versioning scheme for such reasons? Bump the version number up in a position that indicates "things may break" and all should be good, no?
I have asked people but I have never seen an official answer on what our 4 digit versioning scheme means exactly.
I was under the impression that for A.B.C.D, it means this:
A - Major version with compatibility implications. As an example of a compatibility implication, X2Go Server 4.x cannot accept connections from X2Go Client 3.x unless x2goserver-compat is installed. B - Major version without compatibility implications. C - Minor version D - Micro version (patch level)
I am also under the impression that a bump in A, B or C means that "things may break", but not in "D".
Therefore, the 1st version of X2Go Client for Windows with this change will be 4.0.5.0. We might release 4.0.4.1 before then, but it won't have the change.
Or could you create a patch that allows toggling between the two modes of operation, and when the first reconnect fails, try it with the other mode?
That's a good idea. I will need to add an option to VcXsrv like "-[no]limitwglcolors", but that should be easy. I will look into this.
- -Stefan [...]
-Mike#2
On 28.06.2015 05:35 PM, Michael DePaulo wrote:
On Sun, Jun 28, 2015 at 5:10 AM, Stefan Baur <X2Go-ML-1@baur-itcs.de> wrote:
Am 28.06.2015 um 02:54 schrieb Michael DePaulo: I have asked people but I have never seen an official answer on what our 4 digit versioning scheme means exactly.
I was under the impression that for A.B.C.D, it means this:
A - Major version with compatibility implications. As an example of a compatibility implication, X2Go Server 4.x cannot accept connections from X2Go Client 3.x unless x2goserver-compat is installed. B - Major version without compatibility implications. C - Minor version D - Micro version (patch level)
AFAIK there is no strict versioning scheme - we just increment versions whenever it seems appropriate because backwards compatibility broke or something along these lines.
This change probably warrants in increase of C to 5.
Or could you create a patch that allows toggling between the two modes of operation, and when the first reconnect fails, try it with the other mode?
That's a good idea. I will need to add an option to VcXsrv like "-[no]limitwglcolors", but that should be easy. I will look into this.
Nope, there's no easy way to restart a session internally. I'm against crufting the code even more with a workaround just for that.
Mihai
-
Michael DePaulo -
Mihai Moldovan -
Stefan Baur