- x2go-dev - X2Go ListServ

Bug#722: Fwd: [Bug 1179869] New: [abrt] x2goclient: ref(): x2goclient killed by SIGSEGV
by Orion Poplawski 08 Jan '15

08 Jan '15

Package: x2goclient Version: 4.0.2.1 This crashing here: x2goSession ONMainWindow::getSessionFromString ( const QString& string ) { QStringList lst=string.split ( '|' ); x2goSession s; s.agentPid=lst[0]; s.sessionId=lst[1]; looks like the session string is corrupted and doesn't have the expected number of elements. Need some error checking here. -------- Forwarded Message -------- Subject: [Bug 1179869] New: [abrt] x2goclient: ref(): x2goclient killed by SIGSEGV Date: Wed, 07 Jan 2015 17:05:11 +0000 From: bugzilla(a)redhat.com To: orion(a)cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1179869 Bug ID: 1179869 Summary: [abrt] x2goclient: ref(): x2goclient killed by SIGSEGV Product: Fedora Version: 20 Component: x2goclient Assignee: orion(a)cora.nwra.com Reporter: livyathan(a)gmail.com QA Contact: extras-qa(a)fedoraproject.org CC: orion(a)cora.nwra.com Version-Release number of selected component: x2goclient-4.0.2.1-1.fc20 Additional info: reporter: libreport-2.2.3 backtrace_rating: 4 cmdline: x2goclient crash_function: ref executable: /usr/bin/x2goclient kernel: 3.16.6-203.fc20.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (10 frames) #0 ref at ../../src/corelib/arch/qatomic_x86_64.h:121 #1 QString::operator= at tools/qstring.cpp:1410 #2 ONMainWindow::getSessionFromString at ../onmainwindow.cpp:3657 #3 ONMainWindow::selectSession at ../onmainwindow.cpp:4364 #4 ONMainWindow::slotListSessions at ../onmainwindow.cpp:3629 #5 ONMainWindow::qt_static_metacall at moc_onmainwindow.cpp:385 #6 QMetaObject::activate at kernel/qobject.cpp:3567 #7 SshProcess::sshFinished at moc_sshprocess.cpp:140 #8 SshProcess::slotChannelClosed at ../sshprocess.cpp:443 #9 SshProcess::qt_static_metacall at moc_sshprocess.cpp:84 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

3 2

Bug#702: X2Go issue (in src:x2goclient) has been marked as pending for release
by Mike Gabriel 07 Jan '15

07 Jan '15

tag #702 pending fixed #702 4.0.3.2 thanks Hello, X2Go issue #702 (src:x2goclient) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=3008b2a The issue will most likely be fixed in src:x2goclient (4.0.3.2). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit 3008b2a10fde108810650849522f4d2e76c3b300 Author: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Date: Wed Jan 7 10:31:55 2015 +0100 Use app.setQuitOnLastWindowClosed(false) for the X2Go Client QtApplication to assure that X2Go Client does not arbitrarily exit during a running session. This fixes X2Go Client crashes that occur when printing via the CUPS-X2Go printing mechanism with activate print dialog popup on incoming print jobs and minimized main window. (Fixes: #702). diff --git a/debian/changelog b/debian/changelog index a754d04..ae08442 100644 --- a/debian/changelog +++ b/debian/changelog @@ -9,6 +9,11 @@ x2goclient (4.0.3.2-0x2go1) UNRELEASED; urgency=medium * New upstream release (4.0.3.2): - Provide empty Turkish translation file. - Add several info/error/debug log message while hunting down #702. + - Use app.setQuitOnLastWindowClosed(false) for the X2Go Client QtApplication + to assure that X2Go Client does not arbitrarily exit during a running + session. This fixes X2Go Client crashes that occur when printing via + the CUPS-X2Go printing mechanism with activate print dialog popup on + incoming print jobs and minimized main window. (Fixes: #702). [ Jason Alavaliant ] * New upstream verson (4.0.3.2):

2 1

please review my fix for #702
by Mike Gabriel 07 Jan '15

07 Jan '15

Hi Alex, can you please take a look at the just committed [1] fix for #702 [2]? Thanks! Mike [1] http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=3008b2a10fde108… [2] http://bugs.x2go.org/702 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#702: some debugging on X2Go Client crashes when print dialog is shown
by Mike Gabriel 06 Jan '15

06 Jan '15

Hi, I spent a couple of hours debugging #702 today (because I want this issue fixed in Debian jessie). X2Go Client simply exits cleanly immediately when I click the Print button of the print dialog window. The issue occurs in this combination of events: o print dialog appears on incoming print job o it doesn't matter what print action is chosen (pdfview, pdfsave, print, etc.) o X2Go Client's main window is hidden (e.g. via clicking on the tray icon) Just before I had to leave from work, I probably stumbled over the reason for this behaviour, I guess: http://stackoverflow.com/questions/5116459/problem-with-hidden-qmainwindow-… More tomorrow... Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976148 GnuPG Key ID 0x25771B13 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de

1 0

Bug#718: X2Go issue (in src:x2gothinclient) has been marked as pending for release
by Mike Gabriel 06 Jan '15

06 Jan '15

tag #718 pending fixed #718 1.5.0.0 thanks Hello, X2Go issue #718 (src:x2gothinclient) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2gothinclient.git;a=commitdiff;h=f25b381 The issue will most likely be fixed in src:x2gothinclient (1.5.0.0). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit f25b3813280c210002cbb4dffe16657c9404e717 Author: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Date: Tue Jan 6 13:21:46 2015 +0100 For X2Go TCE in display manager mode, set login backgrounds of all screens (if more than one is used) to a blue'ish background color. (Fixes: #718). diff --git a/debian/changelog b/debian/changelog index 05eae5b..baf2ce8 100644 --- a/debian/changelog +++ b/debian/changelog @@ -59,7 +59,10 @@ x2gothinclient (1.5.0.0-0x2go1) UNRELEASED; urgency=low - Don't choke if /etc/resolv.conf in the TCE chroot is a symbolic link (in x2gothinclient_shell, x2gothinclient_upgrade). - README.i18n: Add file that explains the translation workflow for - this package. Thanks to Mark Pedersen-Cook for drafting this file. + this package. Thanks to Mark Pedersen-Cook for drafting this file. + - For X2Go TCE in display manager mode, set login backgrounds of all + screens (if more than one is used) to a blue'ish background color. + (Fixes: #718). * debian/control: + Rename bin:package: x2gothinclient -> x2gothinclient-daemon. + Make sure x2gothinclient-minidesktop pulls in X11 and X2Go Client.

2 1

Processed: your mail
by owner＠bugs.x2go.org 06 Jan '15

06 Jan '15

Processing commands for control(a)bugs.x2go.org: > tag #718 patch Bug #718 [x2gothinclient] Set screen background to X2Go default blue on all detected screens Added tag(s) patch. > thanks Stopping processing here. Please contact me if you need assistance. -- 718: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=718 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Bug#718: Set screen background to X2Go default blue on all detected screens
by Stefan Baur 06 Jan '15

06 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Control tag -1 patch - -- 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) iQEcBAEBAgAGBQJUq8l2AAoJEG7d9BjNvlEZQUsH/j3gESI5ssecxyoFcjLhKamX 28CGKn3S+YoOAM8vSeFcyElqO/YqJHEqLg3vv/QUDgNUSMs/i/dc/xUHHaWp+SkX M27dqbHMWVUK5eoh6VzMJieNmUPQHvBPPjVmra4rApqnMihvlZ//FNgWdaUuFYjl ecmxdp0vn5uHO1XjcgnONowsPm47QiygncxqN4f3/XP+01tAoK5PZbpMGi1Bggch lMUnK4cYvOfnGecLHpP3jVOO7V0RLjbqmAPJsWEK420arWSgapout2Zui5tZv2es X3FtPD+vV/Mb73fWpZovycXlluFerxhvTITHYLmtwGeg7xb+nB994/4zi5Qy/GI= =UxfZ -----END PGP SIGNATURE-----

1 0

Bug#718: Set screen background to X2Go default blue on all detected screens
by Stefan Baur 06 Jan '15

06 Jan '15

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 package: x2gothinclient version: 1.1.0.2 priority: wishlist diff /usr/sbin/x2gothinclientd /usr/sbin/x2gothinclientd.orig 129,131d128 < # set screen background to X2Go default blue on all detected screens < `DISPLAY=:0 xsetroot -solid "#246ed8"`; This will set the screen background on all detected/activated screens to the default blue (picked from the lower right screen region of the login screen) of the standard X2GoClient, so you can tell which screens have been detected/activated by the system. - -- 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) iQEcBAEBAgAGBQJUq723AAoJEG7d9BjNvlEZJBoIAKzMkl1BwdW/OHVdF0n7/36R 4kntHUmT/DzU18JuN/YkBAcNB2eH9IjGUEUOA6Aie5YOfqZT23nWm98CpZKpCx1D QDCaEKfzRZw2Yw+ZQumzlx+WCdz7UVFqaEdGoRRCgP9zEV1OkTi8S7xneCzrQAlN PYCj28rb6f/dFLwPx43SbkCMfywHMxCGTzGjWXjbi+HKZt091pHGrLm6QdmGAPWs sOAl/+UrvZ0y/z2B77Ju/4jgjkrSZ6kzXSNiUXd3MKxwi3utZVQNFGvn8V9gNrYR ojmBmPJb+Yz9o2UembgS1gZmd24Ht0eArgZ4uL5/tt0eeYkD2TXMAKTZjh9QHvg= =bi1I -----END PGP SIGNATURE-----

2 1

Bug#541: can #541 be closed
by Mike Gabriel 06 Jan '15

06 Jan '15

Hi Mike#2, Stefan, can you guys please verify that #541 [1] can be closed? It is still listed as a grave bug in BTS, but IIRC we fixed it already. Right? Mike#1 [1] http://bugs.x2go.org/541 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#717: Fwd: [Bug 1179010] New: [abrt] nxagent: _XReply(): nxagent killed by SIGSEGV
by Orion Poplawski 05 Jan '15

05 Jan '15

Package: nx-libs Version: 3.5.0.28 This looks like infinite recursion in the _XIDHandler() libX11 code. Not sure there is anything to be done besides trying to rebase nx-libs on a newer Xorg X11 release. -------- Forwarded Message -------- Subject: [Bug 1179010] New: [abrt] nxagent: _XReply(): nxagent killed by SIGSEGV Date: Mon, 05 Jan 2015 21:37:20 +0000 From: bugzilla(a)redhat.com To: orion(a)cora.nwra.com https://bugzilla.redhat.com/show_bug.cgi?id=1179010 Bug ID: 1179010 Summary: [abrt] nxagent: _XReply(): nxagent killed by SIGSEGV Product: Fedora Version: 21 Component: nx-libs Assignee: orion(a)cora.nwra.com Reporter: slymidnight(a)yahoo.com QA Contact: extras-qa(a)fedoraproject.org CC: orion(a)cora.nwra.com Description of problem: This seems to happen when I've had a nx2go client session going for most of the day. Though it doesn't happen every day and seems to occur only about once a week at most. I start my session at 9am, if it's going to happen it happens around 2pm more or less. Causes KDE to be unresponsive and the other apps super sluggish. Disconnecting or pausing the session causes it to abort and not be resumable. Once it's like that, there's no way to salvage it. Save what can be saved and exit and log back in. Version-Release number of selected component: nxagent-3.5.0.28-1.fc21 Additional info: reporter: libreport-2.3.0 backtrace_rating: 4 cmdline: /usr/lib64/nx/../x2go/bin/x2goagent -extension XFIXES -nolisten tcp -nolisten tcp -dpi 96 -D -auth /home/sly/.Xauthority -geometry 1680x1050 -name X2GO-sly-209-1420466729_stDKDE_dp24 :209 crash_function: _XReply executable: /usr/lib64/nx/bin/nxagent kernel: 3.17.7-300.fc21.x86_64 runlevel: N 5 type: CCpp uid: 1000 Truncated backtrace: Thread no. 1 (2 frames) #0 _XReply at XlibInt.c:2249 #1 _XIDHandler at XlibInt.c:2073 -- You are receiving this mail because: You are on the CC list for the bug. You are the assignee for the bug.

2 1

Bug#715: Proposed patch
by Michael DePaulo 05 Jan '15

05 Jan '15

Tags: patch I would like someone who knows Perl better, such as theUser2, to review this patch. Although this is a very small patch, theUser2 advised me to be careful when creating full paths. I tested it successfully under CentOS 5 and CentOS 6. I intended to use "make_path" instead of "mkpath" if File::Path 2.06 or later was detected. However, I could not figure out how to write a statement like "use File::Path( make_path)" if File::Path->VERSION is 2.06 or later. Specifically, it appears that "use" statements are executed at compile time in Perl, so they cannot be used within an if block. And I cannot just specify "use File::Path" for all versions of File::Path because "make_path" is not exported by default. EPEL 5: http://perldoc.perl.org/5.8.8/File/Path.html EPEL 6: http://perldoc.perl.org/5.10.1/File/Path.html Latest: http://perldoc.perl.org/File/Path.html

2 3

Creating branches in our git repos
by Michael DePaulo 05 Jan '15

05 Jan '15

Hi X2Go Devs, I would like to create branches for specific bugfixes/improvements in our git repos. But I want to check if that is OK 1st. For example, "If a X2Go Client for Windows 4.0.3.1 needs a bugfix from master branch, but we are not going to release 4.0.3.2 soon, then I will branch off of 4.0.3.1 and backport the bugfix to it." "I'm making some large changes that are not ready to be included in the master branch yet. So I'll put them on a branch before merging them into the master branch." -Mike#2

2 1

Bug#716: X2Go issue (in src:x2gobroker) has been marked as pending for release
by Mike Gabriel 05 Jan '15

05 Jan '15

tag #716 pending fixed #716 0.0.3.0 thanks Hello, X2Go issue #716 (src:x2gobroker) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2gobroker.git;a=commitdiff;h=bc47e33 The issue will most likely be fixed in src:x2gobroker (0.0.3.0). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit bc47e33351c852d720d4e532f5c0aa431d834396 Author: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Date: Mon Jan 5 11:04:36 2015 +0100 Don't strip off spaces from password strings. (Fixes: #716). diff --git a/debian/changelog b/debian/changelog index e054d03..b6fab83 100644 --- a/debian/changelog +++ b/debian/changelog @@ -300,6 +300,7 @@ x2gobroker (0.0.3.0-0x2go1) UNRELEASED; urgency=low * New upstream version (0.0.3.0): - Handle spaces in broker login passwords when authservice is used. (Fixes: #706). + - Don't strip off spaces from password strings. (Fixes: #716). -- Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Fri, 07 Jun 2013 23:25:30 +0200

2 1

Bug#716: python-x2gobroker web/plain module strips passwords breaking passwords that start or end with a space
by Jason Alavaliant 05 Jan '15

05 Jan '15

Package: python-x2gobroker Version: 0.0.2.3 Tags: patch One of my users was getting their authentication failing when connecting to an x2go broker using the http plain backend. Testing revealed that their password ended with a space which the web/plain module default code was automatically stripping off before passing through to the authservice. The attached patch disables stripping for the password argument so passwords starting/ending with spaces are no longer incorrectly rejected. Thanks Jason

1 0

Processed: 714 not grave
by owner＠bugs.x2go.org 03 Jan '15

03 Jan '15

Processing commands for control(a)bugs.x2go.org: > severity 714 normal Bug #714 [x2goserver] Cannot connect to epel5 servers: Undefined subroutine &main::LOG_UPTO Severity set to 'normal' from 'grave' > End of message, stopping processing here. Please contact me if you need assistance. -- 714: http://bugs.x2go.org/cgi-bin/bugreport.cgi?bug=714 X2Go Bug Tracking System Contact owner(a)bugs.x2go.org with problems

1 0

Bug#715: Cannot create X2Go Session Database on EPEL 5
by Michael DePaulo 03 Jan '15

03 Jan '15

Package: x2goserver Version: 4.0.1.18 Severity: grave Server OS: CentOS 5.11 64-bit Client: 4.0.3.1 When you attempt to connect to a CentOS 5 server, you get a "Connection failed" error. The error includes the text "unable to open database file(1)" . This bug prevents EPEL 5 users from using X2Go Server at all. The underlying problem appears to be that x2godbadmin fails to create the session database: [batmin@centos-5 log]$ sudo /usr/sbin/x2godbadmin "make_path" is not exported by the File::Path module Can't continue after import errors at /usr/sbin/x2godbadmin line 25 BEGIN failed--compilation aborted at /usr/sbin/x2godbadmin line 25. Newer versions of File::Path provide "make_path", but I was unable to find an EPEL 5 RPM that provides a sufficiently new version of File::Path . This bug appears to be a regression that was introduced by commit bad455e : http://code.x2go.org/gitweb?p=x2goserver.git;a=commit;h=bad455edefdce83da6a…

1 0

Bug#714: Actually a packaging problem
by Michael DePaulo 03 Jan '15

03 Jan '15

This is actually a problem with our packaging. A 3rd-party RPM exists to provide a newer version of Sys::Syslog that is sufficient, and this is stated on the wiki. The bug is that yum is not informing the user of the need to install that newer version. The wiki states the following, and the 2nd sentence is false: "One approach is to download required packages manually. Yum will tell you what is needed, when you ask it to install x2goserver." http://wiki.x2go.org/doku.php/doc:installation:x2goserver?&#rhel_5 For reference: The RPM that I used (and tested successfully) was: http://flexbox.sourceforge.net/centos/5/x86_64/perl-Sys-Syslog-0.27-1.el5.x… Apparently 32-bit users should use this noarch RPM instead: http://flexbox.sourceforge.net/centos/5/i386/perl-Sys-Syslog-0.27-1.noarch.…

1 0

Bug#699: epel 5 repos have signature errors
by Michael DePaulo 03 Jan '15

03 Jan '15

Package: buildscripts Severity: normal As reported here: http://lists.x2go.org/pipermail/x2go-user/2014-December/002705.html A CentOS 5 user is getting these errors: error: nx-libs-3.5.0.28-0.0x2go1.1.git20141114.546.main.el5.centos: Header V4 RSA/SHA1 signature: BAD, key ID 5bfe2b6e error: libXcomp-3.5.0.28-0.0x2go1.1.git20141114.546.main.el5.centos: Header V4 RSA/SHA1 signature: BAD, key ID 5bfe2b6e etc.... The cause appears to be that CentOS 5 cannot handle V4 signatures, only V3. http://adminotes.blogspot.fr/2011/12/centos-6-rpm-sign-problem-v4-signature…

3 4

(Jenkins Question) Rebuilding "main" packages for EPEL 5.
by Michael DePaulo 03 Jan '15

03 Jan '15

Hi Mike#1 and others, I want to rebuild the "main" packages for EPEL 5 so that we can fix bug #699. I've already rebuilt and tested the "nightly" EPEL 5 packages; bug #699 was successfully fixed on them. However, it appears that in order to rebuild any package for EPEL 5, I must rebuild them for every release of every Linux distro. http://jenkins.x2go.org:8080/view/All%20Releases/?auto_refresh=false Should I just do that via Jenkins? Or would it be disruptive? For example, would users be prompted to update even when they do not have to? I think that would happen for EPEL users at least, because the nightly EPEL 5 nx-libs packages now have "git20141222" in their version strings. (nx-libs.git was last updated 2 weeks ago, but I rebuilt it under nightly on 2014-12-22 (UTC +1:00).) -Mike

2 2

Bug#712: x2goserver: armhf unfulfilled dependency - patch for debian/control
by Heinrich Schuchardt 25 Dec '14

25 Dec '14

Find here how the debian/control should be patched. The first hunk removes a trailing space. The second hunk makes the dependecy only relevant for amd64 and i386. Best regards Heinrich Schuchardt diff --git a/debian/control b/debian/control index 2fee7cb..43929a6 100644 --- a/debian/control +++ b/debian/control @@ -1,6 +1,6 @@ Source: x2goserver Section: x11 -Priority: optional +Priority: optional Maintainer: X2Go Developers <x2go-dev(a)lists.berlios.de> Uploaders: Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de>, @@ -25,7 +25,7 @@ Depends: openssh-server, libconfig-simple-perl, pwgen, - libdbd-pg-perl, + libdbd-pg-perl [amd64], libdbd-pg-perl [i386], libdbd-sqlite3-perl, libfile-basedir-perl, libcapture-tiny-perl,

1 0

Season's greetings
by Heinz-M. Graesing 24 Dec '14

24 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Dear X2Go Community, Contributors, Developers, Friends, The first Ideas of X2Go were made about 10 years ago. There was no name for this project and only one use case. With the first people using it, it started to grow. In the past years more and more people joined the project, fixed bugs, contributed code and helped to make it usable for more and more people. X2Go now has been growing to something we all really should be proud of - - something we should keep care of. The first step was to start this project. This milestone can be seen as done. The second step from now on will be to keep it running. This will be a real challenge, because this project has a history. Every story of history is something we can learn from and we really should do this to avoid already appeared mistakes and problems. It is really nice to stumble upon screen-shots of X2Go all over the world in different localizations! For the future of this project, we really need to find more and more people helping us to spread the word, to control our work and to translate it for new audiences! Furthermore we really should be aware that communication is the key of cooperation and sharing. Sharing ideas, concerns and problems will be the key to work on our next step -> keep the project running! To all #FriendsOfX2Go: Season's greetings and best wishes for the New Year! Heinz-M. Graesing -----BEGIN PGP SIGNATURE----- Version: GnuPG v1 iQIcBAEBAgAGBQJUmlOoAAoJEKRUbBMT/NRx45QQALkX08epw1mHzC/ALi4EGl6s cYmgS+FlT7wBsAkA5yi0OXR/Dma5eD+ZbdhlXRfXM9KHZEAJq2K6x6b+7HQ49zsu /StPeRNggoyWzSX8i9u2yxoANi1vswYPd4710oL5uVkY8gm+Dew0ja1iKdLwojOY WeiGK8SGnlVkDZj6RSBmRL7tLe01kBaqgZhjQ+ixaxIkwfNz+XZJj7m+wyhpjaGw i8y667mouzgqh3XB+Ghb/Vv6HgYcwK4R4FPIheKXRkVsCTa/DPoKdIXxlcAOB3/g ak0WTVtgqJO/XbFEbCFV2WrTWqPeknY+8GiR3H0fT1Ao1OyEhygvj6WcGNa5VqsR vaxoeLe1GHa86qevaiyTElKvESqvPJhYnLJ61OCSN2MRtLKN0fPCyRqjD6SjlYKM Ex8H3biKEuN8wkmLZZ4mk99S9rfAID5PRpUNcPjQXl20k50lfSl1n9Bztj3CY7Jv 0PbSeJwDkq+09uIWwjzBMUE2UofyQNHfRoQmo1KOExO+ElRSsPNxkLLM2Rzny7jT z1lVVT/q1DpFW/0AgqbHWJtDW1r4htEvn3HV0SXWZ9tLIrdXgzkq3m5HgI41aXW2 RCaKYBosjDQkRVB3m8q+kPNTuKDxLd5jgHx10rZXTA8+WFqcBmPeAiTsOgVc0YkG 2TsD/e2rr4Fu71vWS8sJ =FYsf -----END PGP SIGNATURE-----

1 0

RFC: Future coordination of events and contest participations
by Stefan Baur 23 Dec '14

23 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi List, I'm posting this here as we don't have a list for organisational matters (yet - maybe we should create one? Opinions, anyone?). Recently, there have been two occasions where people related to X2Go have signed up/applied in X2Go's name, without letting the others know about it. Since in most cases, it doesn't make sense to apply twice, this means some people have spent time working on an application that had to be scrapped, so as not to collide with the earlier one written by an individual. I don't want to point any fingers in public or name names - those responsible have already hung their heads in shame off-list - however, I would kindly ask *everyone* that knows about contests where X2Go could take part, fairs where we could get a free booth, etc. to post such info on this list (at least until we have a separate list dedicated to that purpose), and tag it "RFP: <YYYY-MM-DD> <Eventname>". That way, we can coordinate our efforts in public and aren't wasting time and end up working against each other and to the disadvantage of the project (two independent applications look unprofessional, IMO). Spending one and a half days on an application that ends up scrapped really sucks, especially if the time dedicated to it could have been spent earning money. *Everybody, please help us avoid this in the future by going public with your info _before_ you apply in X2Go's name.* Kind Regards, Stefan Baur X2Go Lead Evangelist and Event Organizer - -- 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) iQEcBAEBAgAGBQJUmWISAAoJEG7d9BjNvlEZiL0H/2noiCfQHs2/OdmAeEjqDfIp HGN3CRcV5sYCd1SAxrtr0OAzg3rLBCwPXQchy10dpuVJ6sFKOFxV3gauBnFnISa0 F8Cfh3Shi8hDIRoh705E/N4X3dC7oZps2JfyLqZZUdkXG7h3YHArw4JsriMQYcuU 5u15VkT3AEsFLcY+93PeqmkcjfC+xuAGG0CAvr3dEt/HfO9yxOVEZyfJCOxcuEcd pr/wVJWQgEj1v8VrVUi2oPXnrPnIOp+D2mIUYXKwz9uu1VfCmdK/a9a3y4CKy8Aj 77ZPyG/uoKIPJYPapExW0arwx9s81DhJauAThFm0lo3wZgRf0tDZd94oyB2UKZA= =lHfJ -----END PGP SIGNATURE-----

2 1

Bug#699: Fix committed, but only the nightly repo is fixed yet
by Michael DePaulo 22 Dec '14

22 Dec '14

I committed the fix to buildscripts.git and updated buildscripts.git on japsand.x2go.org (which builds & uploads the packages.) However, for reasons explained in the linked email, I have only rebuilt the "nightly" packages with the key, not the "main" (stable release) packages yet. And the 4.1.0.0 x2goserver nightly package is very unstable. http://lists.x2go.org/pipermail/x2go-dev/2014-December/008891.html To any users affected by this bug, I hope to have the main packages rebuilt (and therefore fixed) ASAP.

1 0

Bug#710: Error connecting to CentOS 5 Server: Connection Failed "Undefined subroutine &X2Go::Server::DB::PostgreSQL::LOG_UPTO
by Michael DePaulo 22 Dec '14

22 Dec '14

Package: x2goserver Version: 4.1.0.0-preview Server: CentOS 5.11 64-bit with latest updates [batmin@centos-5 ~]$ x2goversion Undefined subroutine &main::LOG_UPTO called at /usr/lib64/x2go/x2gosyslog line 28. x2goagent: 3.5.0.29 x2goserver: 4.1.0.0-preview x2goserver-common: 4.1.0.0-preview x2goserver-extensions: 4.1.0.0-preview x2goserver-xsession: 4.1.0.0-preview X2go Client for Windows: 4.0.3.1-20141214-debug After fixing bug #699, when I attempt to connect to the CentOS 5 server with X2Go Client, I get this "Connection Failed" error pop-up window: x2go-DEBUG-onmainwindow.cpp:3382> "Undefined subroutine &X2Go::Server::DB::PostgreSQL::LOG_UPTO called at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB/PostgreSQL.pm line 42. Compilation failed in require at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB.pm line 40. BEGIN failed--compilation aborted at /usr/lib/perl5/vendor_perl/5.8.8/X2Go/Server/DB.pm line 40. Compilation failed in require at /usr/bin/x2golistsessions line 27. BEGIN failed--compilation aborted at /usr/bin/x2golistsessions line 27. Clicking "OK" results in you not connecting. I've attached the full log from x2goclient.exe --debug

1 0

Problems with x2goplugin.js
by Niklaus Giger 20 Dec '14

20 Dec '14

Hi I am trying to setup a demo for our Eclipse based RCP application Elexis, letting our application run in a docker container. On my development I manage to run some as I seem to have in my firefox cache an downloaded version of x2goplugin.js. The x2goplugin.html has in it header > <script src="http://plugin.x2go.org/media/x2goplugin.js" > > >type="text/javascript"></script> Which fails to download properly as an Authorization is required. Same when trying to get it via wget > wget http://plugin.x2go.org/media/x2goplugin.js > --2014-12-20 11:32:21-- http://plugin.x2go.org/media/x2goplugin.js > Resolving plugin.x2go.org (plugin.x2go.org) 188.40.28.16 > Connecting to plugin.x2go.org (plugin.x2go.org)|188.40.28.16|:80... > connected. HTTP request sent, awaiting response... 401 Authorization > Required > Reusing existing connection to plugin.x2go.org:80. > HTTP request sent, awaiting response... 401 Authorization Required Could you fix this problem or put a copy of it to public accessible place? Once everything is working, I will publish this project on github and announce it here. Best regards Niklaus

1 0

Bug#708: Bug#708: x2gosqlitewrapper.pl reports "unable to open database" on session-resume, while the database is there.
by Zuck, Daniel 19 Dec '14

19 Dec '14

Hello Mike Thanks for your quick feedback. In a nutshell: I was as well assuming, that a hard fix would be at the end "x2godbadmin --createdb" - however, it would be good to trace the reason why it came to there. Related the Perl modules on SLES, I am not 100% sure, as I am not a "Perl guy", and resolved dependencies if they have been specifically raised via " "make_path" is not exported by the File::Path module" (see http://wiki.x2go.org/doku.php/doc:installation:x2goserver) which was causing me to lift the version of this module (the SLES provided version was too old, so this issue was sorted after the upgrade; same for the RHEL install as described on the Wiki). In more details: >First thing: please note that shortly the X2Go upstream team will provide a new source for SLES packages. The x2goserver version you are using is a >little outdated already. The version is "backported" from OpenSuSE RPM spec's, satisfying the dependencies on SLES. Notably dependencies included to upgrade some of the SLES-provided Perl modules. >I am not sure what perl-Syslog package version is shipped with SLES 11.3, but it seems it cannot handle the "error" logging facility. This is weird in >the first place and maybe you can investigate your system a bit more on this. (What version of perl-Syslog is installed, etc.) The version of Perl is 5.10.0-64.67.52, and there is no specific syslog installed besides the OS-Perl-package (there is a separate perl-Unix-Syslog from SuSE, where I do not know its specific use); it must be a subsequent fault of something else, because syslog and its facilities should be well known since a couple of "decades"... As we have likely a corrupted DB-file, I would try to lift the version of Perl-DBI (maybe the SLES-version is a bit older and has some errors). >Next question is: what file permissions are set on > /var/lib/x2go/x2go_sessions > /usr/<lib>/x2go/x2gosqlitewrapper ls -la /var/lib/x2go/x2go_sessions /usr/lib/x2go/x2gosqlitewrapper -rwxr-sr-x 1 root x2gouser 11978 Nov 4 17:53 /usr/lib/x2go/x2gosqlitewrapper -rw-rw---- 1 root x2gouser 25600 Dec 19 10:35 /var/lib/x2go/x2go_sessions >Next question: > getent passwd x2gouser > getent group x2gouser getent passwd x2gouser x2gouser:x:404:405:x2go server/user:/var/lib/x2go:/bin/false getent group x2gouser x2gouser:!:405: After removing the DB-file and recreating a new one, I can connect without any error. As expected my "old" session was stale. Note: This is the behavior where the system was working since a couple of weeks; the error was raised on two systems at a time. What made me a bit perplex is, that it was visible on two systems, since about the same time. Regards Daniel The content of this e-mail is intended only for the confidential use of the person addressed. If you are not the intended recipient, please notify the sender and delete this email immediately. Thank you.

1 0

Occasion to meet up at 31C3
by Mike Gabriel 19 Dec '14

19 Dec '14

Dear all, I would like to let you know that I will attend 2½ days of the four amazing 31C3 days [1] in Hamburg. If anyone is interested in meeting up there, please ping me (sunweaver) on #x2go on Freenode IRC. Thanks+Greets, Mike [1] http://events.ccc.de/category/31c3/ -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Thanks for the flowers...
by Mike Gabriel 18 Dec '14

18 Dec '14

Hi folks, I recently received a bouquet of flowers via Blume 2000. My wife just found a "Thank you" card with the already deposited cardboard box that it was shipped in. The card reads: Many thanks for your vigorous work on the X2Go project. We love you. Thanks to whoever sent that bouquet!!! Mike#1 -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#704: Desktopsharing "Access denied from user" all time
by KeRo 18 Dec '14

18 Dec '14

Hi Mike, sorry for delay... im testing it in my lab machine and no detect rare things in session db: Test NX user "admuser" conected: 3437|admuser-50-1418900890_stDMATE_dp24|50|ubuntu|R|2014-12-18T12:08:10|1f4e671c91f743d46ac52d4b4ff8ee93|192.168.88.214|30001|30002|2014-12-18T12:08:12|admuser|32|30003| Second NX user "test" connect to a desktopsharing session: 3437|admuser-50-1418900890_stDMATE_dp24|50|ubuntu|R|2014-12-18T12:08:10|1f4e671c91f743d46ac52d4b4ff8ee93|192.168.88.214|30001|30002|2014-12-18T12:08:12|admuser|115|30003| 4997|admuser-51-1418900993_stS0XSHADadmuserXSHADPP50.0_dp24|51|ubuntu|R|2014-12-18T12:09:54|f0ad3b00f15dd59a80a1e6572790a0b8|192.168.88.214|30004|30005|2014-12-18T12:09:55|admuser|11|30006| Second NX user disconect before few minutes: 3437|admuser-50-1418900890_stDMATE_dp24|50|ubuntu|R|2014-12-18T12:08:10|1f4e671c91f743d46ac52d4b4ff8ee93|192.168.88.214|30001|30002|2014-12-18T12:08:12|admuser|240|30003| Regards!

2 1

Please test with x2gobroker from HEAD of master branch in Git
by Mike Gabriel 18 Dec '14

18 Dec '14

Hi Jason, thanks for your patches for X2Go Client and X2Go Session Broker. When testing X2Go Session Broker, please switch to the nightly builds of X2Go [1] and test the latest X2Go Session Broker code (and file patches against that version). I want to get that one released sooner than later (0.0.3.0), but there are still issues coming up here and there, so the more tester around and the more patches coming in, the better. Thanks! Mike [1] http://wiki.x2go.org/doku.php/wiki:development:nightly-builds -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#706: X2Go issue (in src:x2gobroker) has been marked as pending for release
by Mike Gabriel 18 Dec '14

18 Dec '14

tag #706 pending fixed #706 0.0.3.0 thanks Hello, X2Go issue #706 (src:x2gobroker) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2gobroker.git;a=commitdiff;h=d0c3fbd The issue will most likely be fixed in src:x2gobroker (0.0.3.0). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit d0c3fbd9d21b7a76ff0878c1858d38e3e2385378 Author: Jason Alavaliant <alavaliant(a)ra09.com> Date: Thu Dec 18 10:06:36 2014 +0100 Handle spaces in broker login passwords when authservice is used. (Fixes: #706). diff --git a/debian/changelog b/debian/changelog index 935041e..e054d03 100644 --- a/debian/changelog +++ b/debian/changelog @@ -296,6 +296,11 @@ x2gobroker (0.0.3.0-0x2go1) UNRELEASED; urgency=low - On session resumption take profile's host list into account. Don't resume sessions the profile has not been configured for. (Fixes: #553). + [ Jason Alavaliant ] + * New upstream version (0.0.3.0): + - Handle spaces in broker login passwords when authservice is used. (Fixes: + #706). + -- Mike Gabriel <mike.gabriel(a)das-netzwerkteam.de> Fri, 07 Jun 2013 23:25:30 +0200 x2gobroker (0.0.2.3-0~x2go1) unstable; urgency=low

2 1

Bug#704: Desktopsharing "Access denied from user" all time
by KeRo 18 Dec '14

18 Dec '14

Package: x2godesktopsharing Version: 3.1.1.2-0~154~ubuntu14.04.1 Test in latest stable ( 3.1.1.1-0~131~ubuntu14.04.1) and latest nightly (3.1.1.2-0~154~ubuntu14.04.1) Issue: x2godesktopsharing dont work, when a user try to connect with a user with desktop sharing enabled, the list of session appear but try to "View Only" or "Full Access", "Access denied from user" appear directly, in the destination session dont appear any allow popup. All users are in the x2godesktopsharing and x2gousers groups. The problem dont appear if we do the desktopsharing session with the same user of desktop session. Any idea? Best regards

3 3

Bug#706: x2gobroker authservice fails to handle passwords with spaces in them
by Jason Alavaliant 18 Dec '14

18 Dec '14

Package: x2gobroker-authservice Version: 0.0.2.3 Tags: patch Some of my users were getting authentication failed errors trying to login via our x2go broker setup (configured with http backend), further investigation revealed that the common factor was that they all had spaces in their passwords. Digging through the code I found that the socket connection used by the x2gobroker authservice used spaces to separate the fields when passing user data to be validated which meant any password with a space was effectively truncated by the code when it was send to the authservice. The two attached patches contain my proposed fix of changing the separation character to be \r instead which seems to fix the problem fine in my testing. Thanks Jason

1 0

x2goclient v. 4.0.3.1 (Qt 4.8.6) crashes just after login
by Marc Siramy 17 Dec '14

17 Dec '14

Hi, when I try to start a session with x2goclient (or Pyhoca-gui), the client crash just after login. x2goclient create connection to the server : *Dec 17 22:26:11 marc-P55-UD3R sshd[13752]: Accepted password for marc from 192.168.1.13 port 52967 ssh2Dec 17 22:26:11 marc-P55-UD3R sshd[13752]: pam_unix(sshd:session): session opened for user marc by (uid=0)Dec 17 22:26:11 marc-P55-UD3R systemd-logind[869]: Removed session c1.Dec 17 22:26:11 marc-P55-UD3R systemd-logind[869]: New session 21 of user marc* Then x2goclient crashes. gdb give the following trace: *x2go-INFO-1> "Starting x2goclient..."x2go-INFO-4> "Translator: :/x2goclient_fr_fr installed."x2go-INFO-5> "Translator: :/qt_fr_FR installed."x2go-INFO-3> "Started x2goclient."x2go-INFO-8> "Starting connection to server: 192.168.1.11:22 <http://192.168.1.11:22>"[New Thread 0xb2e4ab40 (LWP 27293)][New Thread 0xb2649b40 (LWP 27363)][Thread 0xb2e4ab40 (LWP 27293) exited]Program received signal SIGSEGV, Segmentation fault.QString::operator= (this=0xbffff024, other=...) at tools/qstring.cpp:14101410 tools/qstring.cpp: Aucun fichier ou dossier de ce type.* *(gdb) bt#0 QString::operator= (this=0xbffff024, other=...) at tools/qstring.cpp:1410#1 0x080a7cdc in ?? ()#2 0x080a89b6 in ?? ()#3 0x0814420e in ?? ()#4 0xb6fc80f7 in QMetaObject::activate (sender=0x85e58c0, m=0x8155698, local_signal_index=0, argv=0xbffff4d0) at kernel/qobject.cpp:3539#5 0x08145a1f in ?? ()#6 0x08105b81 in ?? ()#7 0x08145c68 in ?? ()#8 0xb6fc48aa in QMetaCallEvent::placeMetaCall (this=0xb1d0a548, object=0x85e58c0) at kernel/qobject.cpp:524#9 0xb6fcc6fb in QObject::event (this=0x85e58c0, e=0xb1d0a548) at kernel/qobject.cpp:1194[...]* This is apply to x2goclient v. 4.0.3.1 both amd64 & i386 (Qt 4.8.6) and x2goserver v 4.0.1.18-0~949~ubuntu14.04.1 - amd64 Best regards, -- Marc

1 0

Bug#480: Segmentation fault while running x2goclient v
by Marc Siramy 17 Dec '14

17 Dec '14

I have a very similar bug with X2Go Client V. 4.0.3.1 (Qt - 4.8.1). x2go-INFO-1> "Starting x2goclient..." x2go-INFO-4> "Translator: :/x2goclient_fr_fr installed." x2go-INFO-5> "Translator: :/qt_fr_FR installed." x2go-INFO-3> "Started x2goclient." [Thread 0xb26ffb40 (LWP 25778) exited] x2go-INFO-8> "Starting connection to server: 192.168.1.11:22" [New Thread 0xb26ffb40 (LWP 28264)] Program received signal SIGSEGV, Segmentation fault. 0xb6ee2814 in QString::operator=(QString const&) () from /usr/lib/i386-linux-gnu/libQtCore.so.4 (gdb) quit Here is the stack with libqt4-dbg, 4:4.8.5 version : (gdb) start Function "main" not defined. Make breakpoint pending on future shared library load? (y or [n]) Starting program: /usr/bin/x2goclient [Thread debugging using libthread_db enabled] Using host libthread_db library "/lib/i386-linux-gnu/libthread_db.so.1". x2go-INFO-1> "Starting x2goclient..." x2go-INFO-4> "Translator: :/x2goclient_fr_fr installed." x2go-INFO-5> "Translator: :/qt_fr_FR installed." x2go-INFO-3> "Started x2goclient." x2go-INFO-8> "Starting connection to server: 192.168.1.11:22" [New Thread 0xb2e62b40 (LWP 31128)] Program received signal SIGSEGV, Segmentation fault. QString::operator= (this=0xbffff024, other=...) at tools/qstring.cpp:1410 1410 tools/qstring.cpp: Aucun fichier ou dossier de ce type. (gdb) bt #0 QString::operator= (this=0xbffff024, other=...) at tools/qstring.cpp:1410 #1 0x080a7cdc in ?? () #2 0x080a89b6 in ?? () #3 0x0814420e in ?? () #4 0xb6fc80f7 in QMetaObject::activate (sender=0x8537c08, m=0x8155698, local_signal_index=0, argv=0xbffff4d0) at kernel/qobject.cpp:3539 #5 0x08145a1f in ?? () #6 0x08105b81 in ?? () #7 0x08145c68 in ?? () #8 0xb6fc48aa in QMetaCallEvent::placeMetaCall (this=0xb3311408, object=0x8537c08) at kernel/qobject.cpp:524 #9 0xb6fcc6fb in QObject::event (this=0x8537c08, e=0xb3311408) at kernel/qobject.cpp:1194 #10 0xb73a37f4 in QApplicationPrivate::notify_helper (this=0x8288f38, receiver=0x8537c08, e=0xb3311408) at kernel/qapplication.cpp:4567 #11 0xb73aa2d3 in QApplication::notify (this=0xbffffb58, receiver=0x8537c08, e=0xb3311408) at kernel/qapplication.cpp:4353 #12 0xb6fb2e4a in QCoreApplication::notifyInternal (this=0xbffffb58, receiver=receiver@entry=0x8537c08, event=event@entry=0xb3311408) at kernel/qcoreapplication.cpp:953 #13 0xb6fb670d in sendEvent (event=0xb3311408, receiver=0x8537c08) at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:231 #14 QCoreApplicationPrivate::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0, data=0x8289048) at kernel/qcoreapplication.cpp:1577 #15 0xb6fb6c1c in QCoreApplication::sendPostedEvents (receiver=receiver@entry=0x0, event_type=event_type@entry=0) at kernel/qcoreapplication.cpp:1470 #16 0xb6fe323e in sendPostedEvents () at ../../include/QtCore/../../src/corelib/kernel/qcoreapplication.h:236 #17 postEventSourceDispatch (s=0x8289da0) at kernel/qeventdispatcher_glib.cpp:287 #18 0xb65df1e3 in g_main_context_dispatch () from /lib/i386-linux-gnu/libglib-2.0.so.0 #19 0xb65df468 in ?? () from /lib/i386-linux-gnu/libglib-2.0.so.0 #20 0xb65df528 in g_main_context_iteration () from /lib/i386-linux-gnu/libglib-2.0.so.0 #21 0xb6fe293b in QEventDispatcherGlib::processEvents (this=this@entry=0x8289b68, flags=...) at kernel/qeventdispatcher_glib.cpp:434 #22 0xb74585de in QGuiEventDispatcherGlib::processEvents (this=0x8289b68, flags=...) at kernel/qguieventdispatcher_glib.cpp:204 #23 0xb6fb1823 in QEventLoop::processEvents (this=this@entry=0xbffffad8, flags=...) at kernel/qeventloop.cpp:149 #24 0xb6fb1b49 in QEventLoop::exec (this=this@entry=0xbffffad8, flags=...) at kernel/qeventloop.cpp:204 ---Type <return> to continue, or q <return> to quit--- #25 0xb6fb78fe in QCoreApplication::exec () at kernel/qcoreapplication.cpp:1225 #26 0xb73a1a24 in QApplication::exec () at kernel/qapplication.cpp:3828 #27 0x0812a533 in ?? () #28 0x0805bd3b in ?? () #29 0xb6b81a83 in __libc_start_main (main=0x805bd20, argc=1, argv=0xbffffc94, init=0x8148de0, fini=0x8148e50, rtld_fini=0xb7fed180 <_dl_fini>, stack_end=0xbffffc8c) at libc-start.c:287 #30 0x0805bdc1 in ?? () I'm not a C/C++ developer so this is difficult to me to investigate that. -- Marc

1 0

Bug#702: more info.
by Klaus Ade Johnstad 17 Dec '14

17 Dec '14

I found out that if i delete $HOME/.x2goclient and $HOME/.x2go, then it doesn't crash when printing, from Debian Jessie client on a Debian Wheezy server. -- Klaus Ade Johnstad klaus(a)linuxavdelingen.no Mobil:938 69 567 67E61D18B2C44F8A3DA35C6D849F9F5F 26FA477D

2 1

Bug#704: Desktopsharing "Access denied from user" all time
by KeRo 17 Dec '14

17 Dec '14

im not sure how i can debug this :( ... with x2golistsessions and x2golistdesktop? Regards!

2 1

Bug#704: Desktopsharing "Access denied from user" all time
by KeRo 17 Dec '14

17 Dec '14

Yuju!!! compiling latest x2goserver 4.0.1.x (4.0.1.19) and latest x2godesktopsharing, desktopsharing is working again =). Thank you very much Mike =)

2 1

Bug#705: X2Go issue (in src:x2goclient) has been marked as pending for release
by Mike Gabriel 17 Dec '14

17 Dec '14

tag #705 pending fixed #705 4.0.3.2 thanks Hello, X2Go issue #705 (src:x2goclient) reported by you has been fixed in X2Go Git. You can see the changelog below, and you can check the diff of the fix at: http://code.x2go.org/gitweb?p=x2goclient.git;a=commitdiff;h=db7c2f3 The issue will most likely be fixed in src:x2goclient (4.0.3.2). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit db7c2f3009d9f39cdf8a85327c632dcb643f631c Author: Jason Alavaliant <alavaliant(a)ra09.com> Date: Wed Dec 17 11:14:02 2014 +0100 Use QUrl::toPercentEncoding() method to properly encode passwords sent to X2Go Session Broker. (Fixes: #705). diff --git a/debian/changelog b/debian/changelog index 1a034f3..1a2701d 100644 --- a/debian/changelog +++ b/debian/changelog @@ -9,6 +9,11 @@ x2goclient (4.0.3.2-0x2go1) UNRELEASED; urgency=medium * New upstream release (4.0.3.2): - Provide empty Turkish translation file. + [ Jason Alavaliant ] + * New upstream verson (4.0.3.2): + - Use QUrl::toPercentEncoding() method to properly encode passwords sent + to X2Go Session Broker. (Fixes: #705). + [ Mike DePaulo ] * New upstream release (4.0.3.2): - Windows: Fix compatibility with PulseAudio 6.0

2 1

Bug#584: news?
by KeRo 17 Dec '14

17 Dec '14

Hi, some progress in this bug? Regards!

2 1

Bug#705: client sends password to http broker without percent encoding special characters such as &
by Jason Alavaliant 16 Dec '14

16 Dec '14

Package: x2goclient Version: 4.0.3.1 Severity: grave Tags: patch I've just setup an x2go load balanced setup using x2gobroker (http connection - x2goclient --broker-url=http://server:8080/plain/inifile), after putting it into production we found a number of our users had their passwords rejected when trying to sign into the x2go client to access the broker. Tracing through the traffic/logs we found that the problem is that password values were being set unencoded to the broker, so for example if there was an & present in a password the form data was submitted in the form of task=listsessions&user=user&password=mypass&word&authid= which resulted in the data being read by the server as the pasword being mypass rather than mypass&word The attached patch in my testing (done on Linux) fixes the client so data is correctly escaped so the above example would be submitted as task=listsessions&user=user&password=mypass%26word&authid= which is correctly parsed as the password being mypass&word and allows the login to work. If we could get an indication of when this fix is likely to make a client release it would appreciated since we currently don't have Windows and OSX builds with the patch and are trying to workout if it's worth the time of setting up development workstations to be able to compile the client for those platforms vs just waiting for the next client release. Thanks for your time. Jason

1 0

Bug#702: X2Go Client / NX proxy window disappear when printing/viewing a CUPS-X2Go print job
by Klaus Ade Johnstad 16 Dec '14

16 Dec '14

I see this as well. I have just recently started looking at x2go-printing, and have no idea when it used to work, if at all. -- Klaus Ade Johnstad klaus(a)linuxavdelingen.no Mobil:938 69 567 67E61D18B2C44F8A3DA35C6D849F9F5F 26FA477D

2 3

Bug#674: Fwd: Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex))
by Ulrich Sibiller 16 Dec '14

16 Dec '14

On Sat, Dec 13, 2014 at 1:45 AM, Robert Siemer <Robert.Siemer(a)backsla.sh> wrote: > If the translation is on, you get a skewed setup. > > Note that the x2go (with the setting of “do nothing”) does a non-perfect > copy with the same effect: if the translation is effective, the keyboard is > skewed and you are force to load at least “something” to fix XKB. If the > translation is off, you “only” need to load XKB configuration if that > non-perfect copy annoys you... > Thanks for the pointer! I had a look at it. As I suspected: the translation > is “bad”. Sometimes two different keycodes are translated to the same > keycode. How are you supposed to tell them apart on the remote side? You > can’t. > >> It seems some kind of translation from evdev to pc105 is done. > > The naming is a little funny: the keycodes generated by the kernel before > evdev were not called like that, were they? I don't think so. >> Do we need to disable setting >> up the translation within the nx code to make that work? > > That would be great as a first step. I was wondering why this translations had been introduced. It emerged between nxagent 3.2.0-10 and 3.3.0-9. The changelog between these releases contains (among others) these changes: nxagent-3.3.0-9 - Changed Keyboard initialization and reset. This change should fix TR11F02129, TR11F02131, TR11F02132. nxagent-3.3.0-4 - Fix the XKB map load in the case of 64 bit server. nxagent-3.3.0-3 - Fixed TR10F02119. If the remote X display is using evdev keyboard then copy maps from remote. nxagent-3.2.0-12 - Fixed TR08E01814. Added shadow keymap initialization in order to enable nxcompshad to translate keycodes across different layouts. So it MIGHT have been introduced mainly for shadow sessions. The TR10F02119 refers to Ubuntu 8.10, which - according to some other posts I found - is the version that introduced evdev. So the fix that solved evdev problems is causing problems when evdev is enabled. I also looked at the source and found that clearing the property seems to be the only way to disable the translation. (apart from disabling XKB completely). Uli

2 1

Bug#653: Incorrect rendering in java applications
by Александр Демидов 15 Dec '14

15 Dec '14

I use PHPStorm. For me that bug is actual. Some time x2go-session is freezes. After reconnect i view incorrect rendering for java app PHPStorm (gray blocks). Permanent problem - some graphics elements in java app PHPStorm rendering incorrectly (word without one letter, some gui-figures (icons) not viewed) I can attach screenshots to email?

1 0

Bug#702: X2Go Client / NX proxy window disappear when printing/viewing a CUPS-X2Go print job
by Mike Gabriel 15 Dec '14

15 Dec '14

Package: x2goclient Severity: grave Testing with various X2Go Servers (with PostgreSQL / SQLite3 sessions DB, with CUPS+X2GoServer on the same machine / on different machines). Testing on the client-side (Linux only) with X2Go Client / PyHoca-GUI (nightly builds as of today). What I observe with X2Go Client (Linux version): o I print something on the server o the X2Go Client print dialog pops up o I choose my preferred action (print to a printer, view as PDF) (a) PDF comes up in a viewer/gets printed, session stays intact (4 of 10 attempts) (b) nothing happens with the print job, X2Go Client / NX proxy vanish (no segfault) Thus, X2Go Client's client-side printing feature is currently not reliable, thus not really usable. The crashes are more producible on large PDF/print jobs. It would be good to hear from others that use this feature, as well. Does it work for you? Did it work for you? When did it stop working? I tested this with server-side setups that have been working in the past already. Package upgrade + test + see above. Greets, Mike -- DAS-NETZWERKTEAM mike gabriel, herweg 7, 24357 fleckeby fon: +49 (1520) 1976 148 GnuPG Key ID 0x25771B31 mail: mike.gabriel(a)das-netzwerkteam.de, http://das-netzwerkteam.de freeBusy: https://mail.das-netzwerkteam.de/freebusy/m.gabriel%40das-netzwerkteam.de.x…

1 0

Bug#701: We need to talk about, and document, which options are overridable in which way
by Stefan Baur 14 Dec '14

14 Dec '14

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Package: x2goclient Hi, This was inspired by Mike#2's question on how to make microphone input configurable in X2GoClient. The real issue goes way deeper, IMO. Basically, we have three places where an option (not only the microphone input) could be set: 1) command line option 2) "forced" config from broker 3) sessions file (which may be on a read-only network share) a) We need to define an order of precedence for each option; also, how to deal with conflicting options. Example 1: For the microphone to be enabled, both the command line option as well as the sessions file/broker config should match. If the command line option says --mic=off, and the sessions file/broker config says "mic=on", then the mic should be *off*. Also, if the the sessions file/broker config says "mic=off", then the command line option should *not* be able to override that. Only if one side indicates that it doesn't care (by lacking the option), or if all sides agree, the microphone should be turned on. This is a security/privacy-related issue. Example 2: The sessions file or the broker may specify cinerama=off, and now the user attaches a second screen. So being able to pass a cinerama=on on the command line would be nice. Also, this has no security/privacy implications (as far as I can tell - but feel free to prove me wrong), so an agreement between all sides (command line vs. sessions file/broker) would not be neccessary, as long as we agree on an order of precedence and document that properly. b) The broker should be able to offer forced options as well as user-selectable options. Think of it like the Firefox preferences configuration: Admins may, e.g., force the use of a proxy using a "lockPref", but they can also set a default home page that still *can* be overriden by the user ("user_pref"). Similarly, the broker should be able to deliver a config (and the client should be able to parse it) that contains markers as to which settings are "locked" and which settings may still be changed by the user. Of course, this doesn't protect against "rogue" clients that have this feature disabled, so it's not a security measure, but it would allow an admin to, e.g., specify that sound is off by default, but the user may turn it on if so desired. Mike#1: Feel free to clone this bug for the broker part. - -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) iQEcBAEBAgAGBQJUjhA4AAoJEG7d9BjNvlEZHbgH/1jzw3GOkDuMVV83RfEVMTPi h+pYBcifUYF/XUG+rGmiTAwvlmoUzgDNlOkbMhfuWJTP9ZwEMtGu3b6mbjEq5af6 5xB5OThtfgryF4DepfoRDeqyVzfLEH7/l43aP8IH08OJVtkiumNSfPvCoflP+IrM dZzufEYdxPF1lazWInXb8cqtcGMB3pNGQSqenWTXDSYdh9hEK0quHv/8F23eo4gg Wgu3FZumBQ5ZsmKIuYzzUJARDK+d8Qf1iW79rm9sMy239gCIdRiJ5Deq3rnHPEcS 2a4/1YwstCTMt/bCBwnl4CwssexWBj1vN3emvFhmz8cgGOgs6FXj3BnRX8Pf/G4= =y3d1 -----END PGP SIGNATURE-----

1 0

Bug#546: Unable to create SSL tunnel: Global request tcpip-forward failed
by Michael DePaulo 14 Dec '14

14 Dec '14

Package: x2goclient Version: 4.0.2.1-pre05 On Windows, doing the following steps 1. Connect to a session. 2. Disconnect from the session (click the X) 3. Connect to the session again. Causes the session to connect, but you receive both an error dialog and a warning dialog with the following text: Unable to create SSL tunnel: Global request tcpip-forward failed If you X out of or click OK to the error, nothing happens. If you X out of or click OK to the warning, the session ends and you get the message: Title Bar: X2Go - 211 The connection with the remote server was shut down. Please check the state of your network connection. It is safe to assume that if I build x2goclient for windows from the official source release of 4.0.2.1, it wold have this problem. Most, if not all earlier 4.0.2.1 preview builds are affected too.

2 1

Bug#526: Included PulseAudio consumes too much CPU when launched with high priority
by Nable 80 14 Dec '14

14 Dec '14

Package: x2goclient Version: 4.0.2.0 When I use sound forwarding and launch inside X2Go session some application with sound support, pulseaudio.exe at client side starts consuming ~100% CPU. By default, X2Go Client starts pulseaudio.exe with high priority (13). When I set priority to "Above Normal (10)" PA's CPU load drops to 10-20%. With "Normal (8)" it drops to almost 0%, although sound is still played stable, without any additional delays. I'm using WinXP SP3 (32-bit) on my laptop with single core CPU. This issue seems to be "PulseAudio 5.0 && WinXP"-specific.

4 5

Bug#700: x2goserver conflicts with current x2godesktopsharing version 3.1.1.2-0
by Alexey Murz Korepov 13 Dec '14

13 Dec '14

Package: x2goserver Version: 4.1.0.0-0~1206~ubuntu14.10.1 Package installed from Ubuntu ppa:x2go/ppa After last upgrade try I see that package manager want to remove x2godesktopsharing package via line: The following packages have unmet dependencies: x2goserver : Conflicts: x2godesktopsharing (< 3.1.1.2) but 3.1.1.2-0~154~ubuntu14.10.1 is to be installed. I see that x2goserver add dependency: Conflicts: x2godesktopsharing (< 3.1.1.2) Maybe 3.1.1.2-0 version is recognized less than 3.1.1.2? How can we fix this problem? -- Best regards, Alexey Murz Korepov. Email, Jabber: murznn(a)gmail.com

1 0

Bug#674: Acknowledgement (keycode -> keycode translation harmful (makes configuration complex))
by Robert Siemer 13 Dec '14

13 Dec '14

> I really think we should get evdev support into NX. What do you think? No, for keyboard configuration no special evdev support is needed. > But for now... so that I get a deeper feeling for this... Could you > provide a recipe for setting the correct / transparent keyboard > setup in the X2Go Session? For the commands see below. – At the moment I remove _XKB_RULES_NAMES from the root window property before starting/resuming x2go. > Wouldn't [running xkbcomp on the client] bypass all this setxkbmap > names and files altogether? I do already run xkbcomp on the client (and local as well) already, but it has no influence on keycode translation. – I’m not sure why you mentioned it... I believe I know the reasoning behind this keycode translation: in a heterogeneous environment, where you resume an x2go session from different workstations, there exists only one way to represent the different keyboards as an unchanging virtual keyboard. Yes: with keycode translation. The alternative would be to reconfigure XKB on each session resume, which I believe is perfectly reasonable. – This is what I (would) do. Allow me to draw a little ascii diagram here (look at it with fixed width font): local Xserver local Xclients x2go Xserv x2go Xclients [1] |==================xterm |==================chromium |==================xlsclients [3] |==================setxkbmap |==================xkbcomp [7] | [2] |------------------------------------|==============xterm |------------------------------------|==============gnome-do [6] |------------------------------------|==============xlsclients [4] |------------------------------------|==============setxkbmap |------------------------------------|==============xkbcomp [8] This is about the X11 protocol level view of an x2go setup. There are two Xservers running: the local one [1] and that x2go Xserver (that is called nxagent?) [2]. Both are drawn as lines made of | The x2go Xserver [2] represents its clients to the real local Xserver [1] as X11 clients, but draws them in a different way (still X11 protocol, though). An xlsclients [4] executed on the x2go server will be run against [2] and show only the x2go Xclients. On the local Xserver [1] an execution of xlsclients [3] lists all Xclients: the local ones and the remote ones. Unfortunately the x2go Xserver [2] does not relay all and everything to the local Xserver [1]. Examples: the X properties of the root window (some kind of “global” storage for X clients) exist twice (in [1] and [2]) and can differ. Also global hotkeys (“passive keygrabs”) of the x2go Xclients will be stored in [2] and have no influence on [1]. The launcher gnome-do [5] registers a hotkey: it will only be delivered to [5] if the local Xserver [1] has no local Xclient waiting for it _and_ any of the x2go client windows is in focus. Otherwise [2] will not even see the key event. Back to XKB. As far as I could observe, the XKB setup consists of an XKB configuration (which can be read and written with xkbcomp [7][8]) and the root window property _XKB_RULES_NAMES (can be read with xprop and setxkbmap and is written as a side effect of setxkbmap). Note that both things exist twice, stored in [1] and [2]. Command line examples: # dump current XKB configuration into one file $ xkbcomp $DISPLAY full.xkb # load full single-file XKB configuration $ xkbcomp full.xkb $DISPLAY # load from multiple files (xkbcomp will read more than one file): # main keymap file triggers inclusion of files from system X11 files $ xkbcomp keymap.xkb $DISPLAY # example keymap.xkb file xkb_keymap { xkb_keycodes { include "evdev+aliases(qwerty)" }; xkb_types { include "complete+my" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+inet(evdev)+eurosign(e)" }; xkb_geometry { include "pc(pc104)" }; }; # load from multiple files and have those searched for in your own tree # otherwise they will be looked for in XKB root /usr/share/X11/xkb $ xkbcomp -I/home/blabla/xkb mykeymap.xkb $DISPLAY # read _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES(STRING) = "evdev", "pc104", "us,us", "altgr-intl,", "eurosign:e,caps:backspace,compose:rctrl" # interpreted version of the above $ setxkbmap -query rules: evdev model: pc104 layout: us,us variant: altgr-intl, options: eurosign:e,caps:backspace,compose:rctrl # delete _XKB_RULES_NAMES property (and then read it) $ xprop -root -remove _XKB_RULES_NAMES $ xprop -root _XKB_RULES_NAMES _XKB_RULES_NAMES: not found. $ setxkbmap -query Couldn't interpret _XKB_RULES_NAMES property Use defaults: rules - 'base' model - 'pc105' layout - 'us' rules: base model: pc105 layout: us # set _XKB_RULES_NAMES only(!) # I wrote a tool for that (xprop can’t set STRING arrays) # https://github.com/siemer/xproperty $ ./xproperty.py _XKB_RULES_NAMES evdev pc104 us altgr-intl <class 'Xlib.protocol.request.QueryExtension'> _XKB_RULES_NAMES evdev pc104 us altgr-intl # let setxkbmap read this property, override a part of it # and ask which keymap it would load $ setxkbmap -layout de -print xkb_keymap { xkb_keycodes { include "evdev+aliases(qwertz)" }; xkb_types { include "complete" }; xkb_compat { include "complete" }; xkb_symbols { include "pc+de+inet(evdev)" }; xkb_geometry { include "pc(pc104)" }; }; # without “-print” setxkbmap will write the updated property _and_ # instruct the X11 server to load the resulting configuration # with the help of xkbcomp # → setxkbmap can’t just update the property alone On x2go session startup, the x2go Xserver [2] does a superficial investigation of what keyboard is used on the local Xserver [1] and sets up an incomplete keycode translation to a keyboard known as “xfree86”. It further creates an imperfect copy of the XKB configuration from [1] to [2]. The _XKB_RULES_NAMES property on [2] is set to rules=xfree86, model = pc???, layout = us(?) [I forgot the details]. Why is it a superficial investigation? – It takes the rules name from _XKB_RULES_NAMES and deducts the resulting keycodes directly from that (I believe). Even though in a common setup rules name “evdev” results in one specific set of keycodes and rules name “xfree86” in another specific set of keycodes, this is not a must. Why is the keycode translation incomplete? – As far as I observed it, “unusual” or unknown keycodes are not translated and passed as-is. Why is the XKB configuration copy imperfect? – I did a XKB dump on the local Xserver [1] and the x2go Xserver [2] after starting a new session. Keys with four levels of symbols turned into two-level-keysyms. – _Loading_ (i.e. xkbcomp/setxkbmap) a four-level configuration is no problem, though. Note: the imperfect copy of the XKB configuration is almost always useless, because the copied configuration does not match the new (translated) keycodes! Resuming an x2go session triggers the same superficial keyboard investigation, the translation kicks in again, but the XKB configuration is not touched (i.e. is not copied from [1] to [2]). Deleting the _XKB_RULES_NAMES property before session startup/resume or setting the first part (that is the “rules” part) to some unknown string results in untranslated keycodes. Please pardon me for repeating myself in some instances. Robert

2 2

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev