x2go-dev

x2go-dev@lists.x2go.org

5399 discussions

Maintaining VcXsrv and where to host it
by Michael DePaulo 09 Mar '15

09 Mar '15

Hi everybody, This is something I wanted to discuss at our meeting today: http://wiki.x2go.org/doku.php/2015-03:day-2015-03-05?s[]=meeting Intro: For those who do not know, VcXsrv is a port of the X.org X server to Windows. Specifically, the MS Visual C compiler. X2Go Client for Windows bundles and uses it. So does PyHoca-GUI. SourceForge lots you create personal git repos based off of official project repos. So here is my branch on my personal git repo: https://sourceforge.net/u/mikedep333/vcxsrv/ci/xp-1.15.2.x-x2gochanges/tree/ The differences from usptream VcXsrv are: 1. I am currently maintaining the 1.15.2.x branch, rather than the 1.16.x branch of upstream. Upstream never maintains previous branches/releases. 2. I applied the nx-libs compatibility/bugfix patch from Alex, winmultiwindow.patch . I am keeping this on a branch with the suffix "-x2gochanges" branch because my convo with Alex indicated that upstream would not accept it. 3. I am maintaining Windows XP compatibility for the time being. 4. I respond quickly to security vulnerabilities in xorg-server and all the other bundled components (e.g., openssl, freetype2, X11 libs) Upstream simply updates/upgrades each component to the latest versions (even unreleased master branches often) on a seemingly arbitrary schedule. There are a few problems with using SourceForge: 1. SourceForge's support for git is terrible. Whenever I attempted a "request merge" from branch Y on my repo to the master branch on the usptream VcXsrv repo, it treid to merge my master branch instead. 2. SourceForge has recently done terrible things as GitHub has gained popularity: https://en.wikipedia.org/wiki/SourceForge#DevShare_adware_controversy 3. My repo isn't very visible because it is a personal git repo, not a project repo. 4. Upstream VcXsrv (1 developer, marha) is horribly unresponsive. They ignore bugs and merge requests for CVEs. Only once have I gotten an email reply to a merge request. He had a valid reason to reject the merge request, but he didn't actually reject it, so it is still open. I never had a bug report replied to. So effectively, staying on SourceForge does not enable us to upstream anything. Here is what I propose: 1. Host VcXsrv on both code.x2go.org and https://github.com/arcticaproject , simiilar to how nx-libs is hosted. 2. Prefer github for issue tracking. If an issue does affect X2Go users, then use the X2Go BTS and link to the github issue tracker. 3. Create a README.md similar to the one for nx-libs 3.6.x https://github.com/ArcticaProject/nx-libs/blob/3.6.x/README.md 4. Do not rename VcXsrv. State in the README.md that Arctica and X2Go are maintaining branch X or branch Y currently, or possibly even 2 branches at once. This is analogous to Linux distros maintaining a version of a package. 5. In the README.md or the github releases page, link to our builds under: http://code.x2go.org/releases/binary-win32/3rd-party/vcxsrv-modified-by-x2g… 6. Rebase to VcXsrv 1.16.x in time for X2Go Client 4.0.4.0. 7. Pull from upstream VcXsrv (the master branch) continuously. 8. Hopefully receive many pull requests via GitHub :) -Mike#2

4 7

Bug#806: x2goserver database problems was root cause?
by Jason Alavaliant 09 Mar '15

09 Mar '15

Further digging through my install revealed that in the database the used_ports table had 36108 entries recording every port from 30001 up to 66109 in use. The session table didn't have anywhere near that many sessions recorded as in use, so I ran a "delete from used_ports where session_id not in (select session_id from sessions);" which removed 34683 rows from the table. My clients are now getting ports in a much more sensible range provided back from the x2goserver when establishing a connection. Reading the database creation code it looks like there should be a trigger deletes from used_ports when a session table row is removed so I think my database might have somehow failed to create that trigger on creation? Still digging into exactly how the data got into the state it was in.

1 0

Bug#807: Please record and send a PulseAudio debug log
by Michael DePaulo 09 Mar '15

09 Mar '15

Please record and send a PulseAudio debug log. You do not need to be using a debug build to do this: 1. Run x2goclient.exe with --debug 2. Reproduce this problem. You can exit x2goclient when done. 3. Assuming your %USERPROFILE% is C:\Users\mike.DEPAULO, look under C:\Users\mike.DEPAULO\.x2go\pulse\ 4. Sort the subfolders by date. The newest (or only) subfolder will whose name begins with "tmp" contain the pulse.log file. This is the droid we're looking for. -Mike#2

2 1

Bug#807: PulseAudio dies when accessed, when x2goclient.exe is run on a Windows 2012 Terminal Server (within a native RDP desktop connection)
by Stefan Baur 08 Mar '15

08 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Package: x2goclient Version: 4.0.3.1 Situation: Hardware: Windows Server 2012, installed as Terminal Server Debian Linux 7.8( Wheezy), installed as X2Go Server Windows 7x64 Client Connection scenario: 0) Windows 7 Client tries to play a local sound file. Result: Sound works just fine. 1) Windows 7 Client connects to Debian Linux 7.8 using X2GoClient. Result: Sound works just fine. 2) Windows 7 Client connects to Windows Server 2012 using RDP (mstsc.exe). *NOT* via X2Go's RDP proxy feature. Result: Sound works just fine. 3) Windows 7 Client, connected to Windows Server 2012 using RDP (mstsc.exe), again, *NOT* via X2Go's RDP proxy feature, tries to run X2GoClient *on the Windows Server 2012* *inside* the native RDP Session. Result: Sound fails for all things X2Go. Analysis: It seems that PulseAudio dies as soon as one tries to play sound. The following are captures of the tasks running on the W2K12 server. x2goclient running, no attempt to play a sound has been made: PS C:\Users\Administrator> tasklist /fi "USERNAME eq DocThor" Abbildname PID Sitzungsname Sitz.-Nr. Speichernutzung ========================= ======== ================ =========== =============== rdpclip.exe 3364 RDP-Tcp#2 4 6.108 K taskhostex.exe 2368 RDP-Tcp#2 4 5.896 K explorer.exe 4008 RDP-Tcp#2 4 42.556 K powershell.exe 4164 RDP-Tcp#2 4 70.336 K conhost.exe 4172 RDP-Tcp#2 4 7.396 K pageant.exe 4316 RDP-Tcp#2 4 4.252 K x2goclient.exe 4356 RDP-Tcp#2 4 31.188 K x2gohelper.exe 4376 RDP-Tcp#2 4 3.112 K sshd.exe 4408 RDP-Tcp#2 4 6.224 K conhost.exe 4416 RDP-Tcp#2 4 4.808 K ctfmon.exe 4432 RDP-Tcp#2 4 3.332 K vcxsrv.exe 4520 RDP-Tcp#2 4 40.400 K nxproxy.exe 4800 RDP-Tcp#2 4 11.588 K conhost.exe 4808 RDP-Tcp#2 4 2.920 K pulseaudio.exe 2120 RDP-Tcp#2 4 7.876 K conhost.exe 3956 RDP-Tcp#2 4 2.972 K x2goclient running, an attempt to play a sound has been made: PS C:\Users\Administrator> tasklist /fi "USERNAME eq DocThor" Abbildname PID Sitzungsname Sitz.-Nr. Speichernutzung ========================= ======== ================ =========== =============== rdpclip.exe 3364 RDP-Tcp#2 4 6.112 K taskhostex.exe 2368 RDP-Tcp#2 4 5.896 K explorer.exe 4008 RDP-Tcp#2 4 43.920 K powershell.exe 4164 RDP-Tcp#2 4 70.344 K conhost.exe 4172 RDP-Tcp#2 4 7.396 K pageant.exe 4316 RDP-Tcp#2 4 4.252 K x2goclient.exe 4356 RDP-Tcp#2 4 31.228 K x2gohelper.exe 4376 RDP-Tcp#2 4 3.112 K sshd.exe 4408 RDP-Tcp#2 4 6.300 K conhost.exe 4416 RDP-Tcp#2 4 4.808 K ctfmon.exe 4432 RDP-Tcp#2 4 3.344 K vcxsrv.exe 4520 RDP-Tcp#2 4 49.264 K nxproxy.exe 4800 RDP-Tcp#2 4 18.372 K conhost.exe 4808 RDP-Tcp#2 4 2.920 K As you can see, pulseaudio.exe is gone. I can see that this is a rather unusual use case, but still, I'd be interested to know why PulseAudio fails us here. - -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.0.22 (MingW32) iQEcBAEBAgAGBQJU/MBAAAoJEG7d9BjNvlEZ5PIH/A2naqofIfgSkR4An2ZlS0ch hBrhvgxpN4J/VM5pSJqPZ07+56rE/96lDkjrfWgysGP6wJtCmUlPWZZxPwO6Y2Ex tNA/AeDX7X40pheXGBHubl1K0Mo2qO3oAsgZAAH0WAepxatRf/wMk5uIggUA/MO7 9ZmVI8zb3p92tzN4qGWZJttc4beDtMcj1tOkH2cn5hQFQ5MlSY+RE6P/pTOh6Lqv iYgVmrejkIWDld3sq/A+C3bwc3VRxU7rZiYDk54LCHgJdaGI3IQEpz/e62ckIs6O DZpWoRfkbPLIAfJaiJb2G217E9clmK/OtBkodfIf/N0cH2zygfrVZ0lWaqDfJNU= =+kKI -----END PGP SIGNATURE-----

1 2

2nd Online ΞX2Go Developer Meeting (2015-02-5/4pm)
by Heinz-M. Graesing 08 Mar '15

08 Mar '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear Developers, Again, I'd like to invite you - the DEVELOPPERS of X2Go - to assemble together and talk about X2Go. Our first meeting was successfully established by using our IRC Channel. There will be again a lot of communication, so I suggest not to change this setup (yet) -> #x2go/IRC I'll prepare again a wiki page containing the planed agenda. So please assemble again at 4pm (GMT)! See you soon, Heinz-M. Graesing -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJU812yAAoJEKRUbBMT/NRxBSQQAJVH8TYW+yXs+QXqN+AZEb29 rjZjgMh0EEF2SYBrSC9nPfsrghuFEyXAAIh0abEUuUay41rztrKcSKC5V64q3guH bwYEwoyCgJrU1gtnaU4Cz3fnBJPRUcc/mShxUxUhbu0YyfKmrwf/FA2eWX+7RCcb 3/yAPjtTvfHATxzof2ckoh3+3kuK9Gco19LVJIKQ93mjzmXhQZ44sVKIzYHnX+Pj K4ttOj541SMwBzbAU/xOkBqkvuPdN5O5WF3Aq/jVk1YAbhXz3igfa3dXGWXUkapO QRghHWlJwBh248Vo/w70zMKZh5KnJBhkzZSE7mAWmHlMg7nV3hi+lacuObaGaN0q bamGfpzYqJJKvBfQ2Sumy2YM17eSKmLvKyMp4C8Mb9NZvqnoA/EAkUN663axLW+d n1KWlvqUo/wP1ziHOCedoTlFQV1C7Oaisb5lzsRwQVvRG+rG/KogR8dMB86g/ofk ARWGEHsx/Pk374KPmULdXnoNZg11VN3+srGeHKB8QrrjjPaExVUDoMOFwy2FDTbB x1lOQU8WALOU/fBak73TuleRQNPC9ya3iL76v9b94XP82iWbWJBdjJiMS0y6gjV9 6JsjsWRp9DXbTZem6jFpLIxIwugD+kF9Yw6eG616iOyRQHVrj5C9qqm7/G6KRLUg 9ytuS0HTs7glqV5RXX6u =gPh3 -----END PGP SIGNATURE-----

5 10

Bug#806: connection fails with error binding localhost:XXX when creating new session
by Jason Alavaliant 07 Mar '15

07 Mar '15

Package: x2goclient Version: 4.0.3.2 Severity: important All clients trying to create a new sessions on my x2go broker setup started failing with the error message Unable to create ssl tunnel: Error binding localhost:XXX and in each case the XXX was a port number lower than 1024 Digging through the client code and looking at the shared session database on the backend as far as I can tell the issue is; 1) the session database port numbers have reached values of 65000 and greater (for example on the last session I created the database gr_port was 65087) 2) the client gets given that data and adds 1000 to it (onmainwindows.cpp line "int iport=localGraphicPort.toInt() + 1000;") 3) the resulting port number is over the highest valid port number of 65535 and hence later on when it is used the value overflows around to be port 552 4) ports under 1024 are reserved on Unix and can't be used by normal user processes and hence the error and the connection failing. For now I've worked around the issue by patching the client onmainwindows.cpp section under the "int iport=localGraphicPort.toInt() + 1000;" line to add to the various checks an extra check that sees in the value is over 65535 and if so to subtract 63382 which causes the port value to end up above the 1024 range. I don't think this is a complete fix however since it only covers gr_port (which broke first since it gets 1000 added to it which doesn't seem to occur for sound_port and fs_port?) and I'm not sure if I what direction I should be looking at fixing this in order to make a patch that will be accepted upstream. I'm suspecting this might actually be considered an bug with the x2goserver database code (it shouldn't set port so high?) so I'm hoping you can advise on where I should be concentrating on fixing the code. I'm not sure if you'll think it should be patched both in the client and in the server code or if it should only be checked for in the server code? Thanks Jason

1 0

Processed: your mail
by owner＠bugs.x2go.org 07 Mar '15

07 Mar '15

Processing commands for control(a)bugs.x2go.org: > reassign 788 x2goserver 4.0.1.18 Bug #788 {Done: Mihai Moldovan <ionic(a)ionic.de>} [ pyhoca-gui-0.5.0.3, python-x2go 0.5.0.2, x2goserver-4.0.1.18-r2] Pyhoca-Gui freezes when connection to desktop Warning: Unknown package 'pyhoca-gui-0.5.0.3' Warning: Unknown package '0.5.0.2' Warning: Unknown package 'x2goserver-4.0.1.18-r2' Bug reassigned from package ' pyhoca-gui-0.5.0.3, python-x2go 0.5.0.2, x2goserver-4.0.1.18-r2' to 'x2goserver'. Ignoring request to alter found versions of bug #788 to the same values previously set Ignoring request to alter fixed versions of bug #788 to the same values previously set Bug #788 {Done: Mihai Moldovan <ionic(a)ionic.de>} [x2goserver] Pyhoca-Gui freezes when connection to desktop There is no source info for the package 'x2goserver' at version '4.0.1.18' with architecture '' Unable to make a source version for version '4.0.1.18' Marked as found in versions 4.0.1.18. > thanks Stopping processing here. Please contact me if you need assistance. -- 788: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=788 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Processed: your mail
by owner＠bugs.x2go.org 07 Mar '15

07 Mar '15

Processing commands for control(a)bugs.x2go.org: > close 788 Bug #788 [ pyhoca-gui-0.5.0.3, python-x2go 0.5.0.2, x2goserver-4.0.1.18-r2] Pyhoca-Gui freezes when connection to desktop Warning: Unknown package 'pyhoca-gui-0.5.0.3' Warning: Unknown package '0.5.0.2' Warning: Unknown package 'x2goserver-4.0.1.18-r2' Marked Bug as done Warning: Unknown package 'pyhoca-gui-0.5.0.3' Warning: Unknown package '0.5.0.2' Warning: Unknown package 'x2goserver-4.0.1.18-r2' > thanks Stopping processing here. Please contact me if you need assistance. -- 788: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=788 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Bug#805: Windows client does not resume, Linux client works OK
by Andreas Kinzler 06 Mar '15

06 Mar '15

Package: x2goclient Version: 4.0.3.x x2go server is 4.0.1.19 (either debian 7.8 or Gentoo) and client is 4.0.3.x. Resume does not work with the Windows client but works OK with the Linux client. There is nothing special in the log. The Windows client hangs with "connecting" and does not do anything. Regards Andreas

1 0

Re: [X2Go-Dev] [X2Go-User] win32 x2go client not resuming
by Will Wagner 06 Mar '15

06 Mar '15

I get an ssl error when I try to use 3.99.2.2. I redirected stderr and ran the app. This is the output: x2go-INFO-1> "Starting x2goclient..." x2go-WARNING-1> "Can't load translator: :/x2goclient_en_gb" x2go-WARNING-2> "Can't load translator: :/qt_en_GB" x2go-INFO-3> "Started x2goclient." x2go-INFO-8> "Starting connection to server: 172.20.0.2:22" Object::connect: No such slot ONMainWindow::slotTunnelOk() Looking at the source code it appears that the sshconnection comes up and calls the slot slotTunnelOk(int). That function checks if winServersReady and if not tries to call itself again in 100mS by calling QTimer::singleShot ( 100, this, SLOT ( slotTunnelOk() ) ); The int argument is missing in slotTunnelOk and so it fails and the app then hangs. Does that sound like a reasonable analysis? Rather than trying to build the code myself could someone doa build with that change and I'm happy to test it. Thanks Will On 03/03/2015 13:07, Dillmann, Jan (IKET) wrote: > Hi, > > having exactly the same behaviour with several distributions (Xubuntu 14.04 > LTS, latest Debian). > I tested different x2go-server versions from 4.0.1.16 to 4.0.1.19. > > As a workaround I am using x2go client 3.99.2.2. With v3 I am able to resume > sessions without problems. > > I tried every possible v4 client without success on several windows versions > (windows 7 and windows 8). > > > Regards, > > Jan > > -----Ursprüngliche Nachricht----- > Von: x2go-user-bounces(a)lists.x2go.org > [mailto:x2go-user-bounces@lists.x2go.org] Im Auftrag von Will Wagner > Gesendet: Dienstag, 3. März 2015 13:03 > An: x2go-user(a)lists.x2go.org > Betreff: [X2Go-User] win32 x2go client not resuming > > Hello, > > I have just setup a new server running debian jessie with x2go server > (4.0.1.18-0x2go1+git20141006.949+jessie). > > I have windows client 4.0.3.2 > > The first time I connect it all works. However on a subsequent attempt to > resume it doesn't work. After entering password the client pops up the > connecting dialog never outputs any text even though I have sow details > checked. I also get the task bar popup saying it has connected although all > options are greyed out. It appears to sit there forever at this point. > > If I look at the server logs I see: > Mar 3 11:42:43 waldorf2 /usr/bin/x2goresume-session: client 172.20.1.8 has > successfully resumed session with ID willw-50-1425325134_stDXFCE_dp32 Mar 3 > 11:43:14 waldorf2 /usr/bin/x2gosetkeyboard: > /home/willw/.x2go/C-willw-50-1425325134_stDXFCE_dp32/keyboard did not appear > within 30s after agent startup > > So it appears that the client has got stuck part way though resuming? > Anyone got any ideas what this could be? Where can I look on windows for log > messages from the client? > > Thanks > Will > > _______________________________________________ > x2go-user mailing list > x2go-user(a)lists.x2go.org > http://lists.x2go.org/listinfo/x2go-user > > > > _______________________________________________ > x2go-user mailing list > x2go-user(a)lists.x2go.org > http://lists.x2go.org/listinfo/x2go-user > -- ------------------------------------------------------------------------ Will Wagner will_wagner(a)carallon.com Development Manager Office Tel: +44 (0)20 7471 9224 Carallon Ltd, Studio G20, Shepherds Building, Rockley Rd, London W14 0DA ------------------------------------------------------------------------

2 4

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev