x2go-dev May 2017

x2go-dev@lists.x2go.org

18 participants
118 discussions

Bug#1178: X2Go Client for Windows in Fullscreen mode has VcXsrv fail with "InitOutput - Couldn't add screen 0"
by Mike DePaulo 24 May '17

24 May '17

Package: x2goclient Version: 4.1.0.0 Severity: normal Tags: +build-win32 When I attempt to launch a Fullscreen session of X2Go Client for Windows, I get an error window from VcXsrv (which fails to start): A fatal error has occuered and VcXsrv will now exit. InitOutput - Couldn't add screen 0 ... <It references the attached log file> Vendor: The X2Go and Arctica Projects Release: 1.17.0.0 ... XWin was started with the following command-line: vcxsrv -fullscreen -notrayicon -clipboard :0 Client: Windows 7 x64 SP1 with 2560x1440 resolution and the scaling set to "Larger - 150%" server: CentOS 7.3 x64 with KDE

1 0

Bug#1177: Sound does not work from EL6 clients with both pulse cookies
by Mike DePaulo 24 May '17

24 May '17

Package: x2goclient Version: 4.1.0.1 PulseAudio Sound fails to work when the following conditions are met: 1. The client is running RHEL 6/CentOS 6/etc 2. The client has both ~/.pulse-cookie ~/.config/pulse/cookie . For example, when the home directory is an NFS export mounted by both EL6 and EL7 systems. Running commands like `pactl list` on the X2Go server yields "Connection failure: Access denied". This is because the X2Go client system is using ~/.pulse-cookie with its PulseAudio server, but X2Go Client copied over ~/.config/pulse/cookie and is having the X2Go server system use it with its PulseAudio client libraries. This can be worked around by symlinking .pulse-cookie to .config/pulse/cookie .

1 0

Bug#1167: More details
by Petronic, Mark 20 May '17

20 May '17

We are running Windows 7 using VmWare Virtual Desktop (VDI). So, my x2go client runs on that Windows desktop. The crash is actually happening in vcxsrv.ex and I was able to obtain the following additional information: (1) The VDI admins updated some VDI runtimes on our VDI desktop instances to VMWare version 6 around the time we started to experience this crash (2) Here is a more detailed dump of some debug information I found: Problem signature: Problem Event Name: APPCRASH Application Name: vcxsrv.exe Application Version: 1.17.0.0 Application Timestamp: 55b5056a Fault Module Name: vm3dum.dll Fault Module Version: 8.15.1.46 Fault Module Timestamp: 57112640 Exception Code: 40000015 Exception Offset: 00026b27 OS Version: 6.1.7601.2.1.0.256.4 Locale ID: 1033 Additional Information 1: f5d8 Additional Information 2: f5d85880320133c2803765541f044878 Additional Information 3: 4651 Additional Information 4: 4651b47fc82bdc83b534297b987ba7e7

2 2

Bug#1176: Replace netstat with ss
by Orion Poplawski 17 May '17

17 May '17

Package: x2goserver Version: 4.1.0.0 netstat is depracated by ss. We should replace it in x2goresume-session, especially since we already use ss in x2gostartagent. -- Orion Poplawski Technical Manager 720-772-5637 NWRA, Boulder/CoRA Office FAX: 303-415-9702 3380 Mitchell Lane orion(a)nwra.com Boulder, CO 80301 http://www.nwra.com

1 0

Xinerama buggy?
by Ulrich Sibiller 15 May '17

15 May '17

Hi, in x2goclient's ONMainWindow::slotConfigXinerama you can find the following code that calculates the values for xinerama.conf. We see a race condition here where sometimes (well, quite often) this leads to negative x/y coordinates in xinerama.conf (size is ok) for new sessions when run from the thinclient setup. The code below contains annotations by me in [] with the variables' values that lead to the wrong xinerama.conf. I believe x2goclient sometimes catches the nxagent window too early before it is resized accordingly (maybe the window manager is too slow) thus getting a window of size 1x1 in the center of the screen (line 12): 1 void ONMainWindow::slotConfigXinerama() 2 { 3 QRect newGeometry=proxyWinGeometry(); [1x1@511,393] 4 if (newGeometry.isNull()) 5 { 6 x2goWarningf(7)<< tr("Error getting window geometry. (Did you close the window?)"); 7 xineramaTimer->stop(); 8 return; 9 } 10 if (newGeometry==lastDisplayGeometry) 11 return; 12 lastDisplayGeometry=newGeometry; [1x1@511,393] 13 QString geoStr = 14 "(x: " + QString("%1").arg(lastDisplayGeometry.x()) + 15 ", y: "+ QString("%1").arg(lastDisplayGeometry.y()) + 16 ", w: "+ QString("%1").arg(lastDisplayGeometry.width()) + 17 ", h: "+ QString("%1").arg(lastDisplayGeometry.height()); 18 x2goDebug<<"New proxy geometry: " + geoStr; 19 QDesktopWidget* root=QApplication::desktop(); 20 QList<QRect> newXineramaScreens; 21 for (int i=0; i< root->numScreens(); ++i) 22 { 23 QRect intersection; 24 if (resumingSession.fullscreen) 25 intersection=root->screenGeometry(i); [1024x768@0,0] 26 else 27 intersection=root->screenGeometry(i).intersected(lastDisplayGeometry); [ not executed ] 28 if (!intersection.isNull()) 29 { 30 // x2goDebug<<"intersected with "<<i<<": "<<intersection<<endl; 31 intersection.moveLeft(intersection.x()-lastDisplayGeometry.x()); [1024x768@-511,0] <- [0]-[511] 32 intersection.moveTop(intersection.y()-lastDisplayGeometry.y()); [1024x768@-511,-393] <- [0]-[393] 33 // x2goDebug<<"xinerama screen: "<<intersection<<endl; 34 newXineramaScreens<<intersection; 35 } 36 } 37 if (xineramaScreens != newXineramaScreens) 38 { 39 xineramaScreens=newXineramaScreens; 40 // x2goDebug<<"xinerama screen changed, new screens: "<<xineramaScreens<<endl; 41 xineramaTimer->stop(); 42 QStringList screens; 43 foreach (QRect disp, xineramaScreens) 44 screens<<QString::number(disp.x())+" "+QString::number(disp.y())+" "+QString::number(disp.width())+ 45 " "+QString::number(disp.height()); ["-511 -393 1024 768"] 46 QString cmd="export DISPLAY=:"+resumingSession.display+" ;printf %b '\\''"+screens.join("\\n")+"'\\'' > $HOME/.x2go/C-"+ 47 resumingSession.sessionId+"/xinerama.conf"; 48 sshConnection->executeCommand(cmd, this, SLOT(slotXineramaConfigured())); 49 } 50 } I am not really sure about the intentions behind this code. It looks to me that the if block (lines 28-35} should not run for the fullscreen case. Can anyone confirm this? Uli

1 0

Bug#1016: X2Go issue (in src:python-x2go) has been marked as closed
by X2Go Release Manager 15 May '17

15 May '17

close #1016 thanks Hello, we are very hopeful that X2Go issue #1016 reported by you has been resolved in the new release (0.5.0.5) of the X2Go source project »src:python-x2go«. You can view the complete changelog entry of src:python-x2go (0.5.0.5) below, and you can use the following link to view all the code changes between this and the last release of src:python-x2go. http://code.x2go.org/gitweb?p=python-x2go.git;a=commitdiff;h=64c77967e7ae4e… If you feel that the issue has not been resolved satisfyingly, feel free to reopen this bug report or submit a follow-up report with further observations described based on the new released version of src:python-x2go. Thanks a lot for contributing to X2Go!!! light+love X2Go Git Admin (on behalf of the sender of this mail) --- X2Go Component: src:python-x2go Version: 0.5.0.5-0x2go1 Status: RELEASE Date: Mon, 15 May 2017 16:38:16 +0200 Fixes: 1016 Changes: python-x2go (0.5.0.5-0x2go1) RELEASED; urgency=low . [ Mike Gabriel ] * New upstream version (0.5.0.5): - documentation: Fix wording in docstring. - Don't blindly release gevent locks. We need to check if a semaphore is locked for some code paths and only then release it. (Fixes: #1016). . [ Mihai Moldovan ] * New upstream version (0.5.0.5): - x2go/__init__.py: update mailing list address. * debian/control: - Maintainer change in package: X2Go Developers <x2go-dev(a)lists.x2go.org>. - Uploaders: add myself. Also, force a rebuild due to the changed versioning.

2 1

Bug#1094: When connected to a x2go server that has nVidia's binary drivers most software will segfault.
by Matthew Moskewicz 11 May '17

11 May '17

i ran into this issue on ubuntu 16.04 (64 bit), and i can confirm that both workarounds (using Nouveau and setting LD_LIBRARY_PATH=/usr/lib/nvidia-375 ) fix the issue. to add a bit more info, it seems that in the failing case, glxinfo (or presumably the other apps), can't find the GLX_indirect library that it trys to load dynamically, which has something to glvnd: https://github.com/NVIDIA/libglvnd looking at ldd, you can see that glxinfo is finding the GL libraries fine, using the system-set ld.so.conf settings that the nvidia driver sets up: moskewcz@mari:/etc/ld.so.conf.d$ ldd /usr/bin/glxinfo linux-vdso.so.1 => (0x00007ffe4779c000) libGL.so.1 => /usr/lib/nvidia-375/libGL.so.1 (0x00007fcd87f35000) libX11.so.6 => /usr/lib/x86_64-linux-gnu/libX11.so.6 (0x00007fcd87bfb000) libc.so.6 => /lib/x86_64-linux-gnu/libc.so.6 (0x00007fcd87831000) libdl.so.2 => /lib/x86_64-linux-gnu/libdl.so.2 (0x00007fcd8762d000) libGLX.so.0 => /usr/lib/nvidia-375/libGLX.so.0 (0x00007fcd873fd000) ... the paths are set here: moskewcz@mari:/etc/ld.so.conf.d$ cat /etc/ld.so.conf.d/x86_64-linux-gnu_EGL.conf /usr/lib/nvidia-375 /usr/lib32/nvidia-375 using strace, we can see the difference that setting LD_LIBRARY_PATH makes: # working case, opens the correct lib: moskewcz@mari:/etc/ld.so.conf.d$ LD_LIBRARY_PATH=/usr/lib/nvidia-375 strace glxinfo 2>&1 | grep GLX_ind open("/usr/lib/nvidia-375/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/nvidia-375/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = 4 # non-working case, fails to open libGLX_indirect.so: moskewcz@mari:/etc/ld.so.conf.d$ strace glxinfo 2>&1 | grep GLX_ind open("/lib/x86_64-linux-gnu/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64-linux-gnu/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/lib/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/tls/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) open("/usr/lib/x86_64/libGLX_indirect.so.0", O_RDONLY|O_CLOEXEC) = -1 ENOENT (No such file or directory) [...snip many more repeats of failed-to-load libGLX_indirect...] however, it's not clear why, under x2go, the nvidia code isn't searching in /usr/lib/nvidia-375 -- but it's not clear what code it uses for the DL loading, maybe it is somewhere in the glvnd code. mwm

1 0

Bug#592: X2Go issue (in src:x2goclient) has been marked as pending for release
by Oleksandr Shneyder 10 May '17

10 May '17

tag #592 pending fixed #592 4.1.0.1 thanks Hello, X2Go issue #592 (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=68bbf32 The issue will most likely be fixed in src:x2goclient (4.1.0.1). light+love X2Go Git Admin (on behalf of the sender of this mail) --- commit 68bbf328132125eaad5c53b0ac82490bf818e42e Author: Oleksandr Shneyder <o.shneyder(a)phoca-gmbh.de> Date: Wed May 10 15:22:11 2017 +0200 Interaction with SSH server (for example for changing expired password). Fixes: #592. diff --git a/debian/changelog b/debian/changelog index 57e48d8..40e262f 100644 --- a/debian/changelog +++ b/debian/changelog @@ -155,6 +155,8 @@ x2goclient (4.1.0.1-0x2go1) UNRELEASED; urgency=medium - Disable sound button on direct RDP and XDMCP sessions. Set for direct XDMCP session autologin=true. Set for direct XDMCP session username=XDM. + - Interaction with SSH server (for example for changing + expired password). Fixes: #592. [ Robert Parts ] * New upstream version (4.1.0.1):

2 1

Bug#1172: Bug#1172: Bug#1172: ThunderBird crashes in PubApp mode on amd64
by Walid MOGHRABI 10 May '17

10 May '17

> It is not "unusable". But nx offers an old version of GLX only. And > there seem to be some applications that don't care for the version the > X server (nxagent in this case) reports. So what should we do? You're right, I'm probably a bit to0 rude with this but it's far too old and most applications just test if GLX is enabled without testing it's version or correct support for each extensions which leads to crashes at times. Since there is no gain in keeping it "as is" (at least, I did see more problems than gains) and until GLX support is updated through Lib-NX, I personnaly would recommend disabling GLX by default (which let the possibility to the user to activate it if he really needs it but don't make this the default behaviour). Since applications are checking if GLX is enabled, disabling it force them to fallback on software renderers only (or don't run at all but I prefer that to crashes for unknown reasons). > It is possible to implement a newer GLX version but that would need > some investing quite some time. Unfortunately the current nx > development staff does not have that time... I know and I upvote for that as top priority since more and more applications needs this. Regards, Walid Moghrabi TRAVAUX.COM BAT I - PARC CEZANNE 2 290 AVENUE GALILEE - CS 80403 13591 AIX EN PROVENCE CEDEX 3 ----- Mail original ----- De: "Ulrich Sibiller" <uli42(a)gmx.de> À: "Walid MOGHRABI" <w.moghrabi(a)servicemagic.eu>, 1172(a)bugs.x2go.org Envoyé: Vendredi 5 Mai 2017 21:41:47 Objet: Re: [X2Go-Dev] Bug#1172: Bug#1172: ThunderBird crashes in PubApp mode on amd64 On Fri, May 5, 2017 at 5:33 PM, Walid MOGHRABI <w.moghrabi(a)servicemagic.eu> wrote: > I would recommend disabling GLX by uncommenting this line in /etc/x2go/x2goagent.options : > > #X2GO_NXAGENT_DEFAULT_OPTIONS+=" -extension GLX" > > GLX is unusable with the current NX-Libs (even Arctica ones) but since the extension is enabled, some components still tries to use H/W acceleration for some parts. > I get far better results (especially stability wise) with this option disabled. > > I would even consider disabling it "by default" until a proper GLX support is added to nx-libs. It is not "unusable". But nx offers an old version of GLX only. And there seem to be some applications that don't care for the version the X server (nxagent in this case) reports. So what should we do? It is possible to implement a newer GLX version but that would need some investing quite some time. Unfortunately the current nx development staff does not have that time... Regarding Thunderbird: does it still crash after setting gfx.xrender.enabled to true in about:config (respectively user.js)? Uli --- DISCLAIMER: This e-mail is private and confidential and may contain proprietary or legally privileged information. It is for the intended recipient only. If you have received this email in error, please notify the author by replying to it and then destroy it. If you are not the intended recipient you must not use, disclose, distribute, copy, print or rely on this e-mail or any attachment. Thank you

1 0

Bug#1172: ThunderBird crashes in PubApp mode on amd64
by Stefan Baur 09 May '17

09 May '17

package: nx-libs Hi, since Debian Jessie (stable) switched from IceDove back to ThunderBird, TB crashes when the host is an amd64 machine and X2GoClient is running in PubApp mode. i386 is unaffected. It happens with X2GoClient on Windows as well as on Linux, so it's not a matter of VcXsrv being too old/broken/whatever. It also happens when all X2Go server components are installed from heuler. It does NOT happen when you build nx-libs from source using the Debian Experimental repository. So there's something in the stable nx-libs that's broken on amd64 only, and got fixed in the nx-libs version that is available via Debian Experimental. Core-Devs, please advise how to fix this - should we dare making a new nx-libs release and declare it stable, based on what is in Debian Experimental (arguing that everything is better than what we currently have)? Or should we try to hunt down the offending code part and only patch that? If the latter, who's willing to take a stab at it? (We don't have a business case ATM, as all my TB-PubApp-users are still on i386, so no funding as of now.) Kind Regards, Stefan Baur -- 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

4 15

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

x2go-dev May 2017