x2go-dev March 2015

x2go-dev@lists.x2go.org

39 participants
196 discussions

[git repositories] New branching concept
by Mihai Moldovan 09 Mar '15

09 Mar '15

Hi, This information targets all users with commit privileges to the official x2go repositories. Coming up soon™, new branching policies will be in effect. TLDR: DO: - create feature branches as "feature/<name>" - comment on need for "bugfix/<name>" branches - rebase your feature branches against master - only send "pull requests" for your feature branches once they have been rebased - NO MERGE CONFLICTS! - send emails to git-admin(a)x2go.org for branch deletion, renaming or "pull requests" DON'T: - be afraid to make mistakes on your feature branches or ask - try to rebase or merge other branches into master (will be rejected) - try to delete branches (will be rejected) - try to rename branches (might leave you with a mess) Details: Historically, non-fast-forward (created by the rebase operation) and merge commits have been rejected on all branches. These restrictions will be loosened to allow committers more control over their branches and ease merging of pull requests. The new policies will allow non-fast-forwards and merge commits within feature branches. That means developers will be able to to rebase and merge other branches. In fact, committers will be required to rebase their feature branch against the master branch for pull requests. Requests with conflicts will not be merged. This new concept will not affect master and release/* branches. On these branches, rebases and merges will still be rejected. Feature branches should follow the template feature/<name> to ensure consistency with our current release/<version> release branches. The current branches will be accordingly renamed once the new policy is in effect. If you do see any benefit of a new branch type, like bugfix/<name> or bugfix/<version>, please let me know. We can then discuss policies regarding those. For now, please refrain from creating these branches. Please send an email to git-admin(a)x2go.org to initiate a pull request. Don't forget to mention the branch you want to have merged into master. The admin will review and then either merge or deny your request. This said, please try to refrain from uselessly rebasing your branches to delete mistakes or squish commits together, unless it really makes sense. Don't be afraid to be human. Commit early, commit often. Don't forge the history. For renaming and deletion of branches, please also contact git-admin(a)x2go.org. Creation is possible without former notification of git-admin, but please make sure to follow naming conventions as outlined in this email. The new policies will be effective once implemented and Mike#1 finishes the outstanding release of all components. Best Mihai

1 2

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

Jump to page:

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev March 2015