From pierre.wulles at gmail.com Wed Aug 1 10:39:18 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Wed, 1 Aug 2018 11:39:18 +0200 Subject: [winswitch] How to start a software remotely Message-ID: Hello, Following what I've said Yesterday, I cannot start a software remotely with xpra, I'd like to do somethng like {{{ xpra start tcp://ip --start=xterm }}} On the client! And it will start on the server through my proxy. Is it possible to do this? If yes how? Thank you, Pierre From antoine at nagafix.co.uk Sat Aug 4 14:29:46 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 4 Aug 2018 15:29:46 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: References: Message-ID: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: > Hello, > I've recently succeeded in having a server running xterm, a proxy and a > machine connecting to the proxy. I used for this what is described in > https://xpra.org/trac/wiki/ProxyServer at the section Remote Hosts. What I > want to do now is launching the pplication from the client, so what I did > is: > {{{ > xpra start :100 --bind-tcp=0.0.0.0:10100 > }}} You said you wanted to launch from the client, but here you are launching a session in advance. Did you mean "connect from the client" instead? > on the server. Then > {{{ > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp --daemon=no > }}} The "allow" authentication module does not use any arguments. Certainly not the database file which is meant to be used by the sqlite auth module. > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth because I > didn't know how to indicate where the server is, Specifying remote hosts is documented for the sqlite backend on the proxy wiki page: https://xpra.org/trac/wiki/ProxyServer#RemoteHosts ie: sqlite_auth.py ./auth.sdb add foo bar nobody nobody tcp://1.1.1.1:10100/ > the problem that I guess > here is that if you put --tcp-auth=allow the file xpra-auth is ignored > because when I go to the client: > {{{ > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm > }}} FYI: tcp-auth here would apply to the session you end up starting. That's usually a bad idea for anything but testing. And in this case, it is very unlikely to be needed since you will be connected to the session when you start it anyway. > I have the following error: > {{{ > 2018-07-31 13:50:22,161 Error: authentication failed: > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly refusing > to use it without encryption > }}} xpra will refuse to send password unencrypted over the network. > What can I do ? Like it says, use encryption. https://xpra.org/trac/wiki/Encryption Cheers, Antoine > Thank you, > Pierre > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From daniele.polencic at gmail.com Sun Aug 5 16:22:28 2018 From: daniele.polencic at gmail.com (Daniele Polencic) Date: Sun, 5 Aug 2018 16:22:28 +0100 Subject: [winswitch] SSH Private key on Xpra for Mac Message-ID: Hello, I set up remote workspaces with Xpra, and I connected to them using the Gtk3 client on a Mac. https://www.dropbox.com/s/qvdb7w49dcw7og8/Screenshot%202018-08-04%2011.56.08.png?dl=0 I noticed that I couldn't select a private key when I used the SSH option from the drop-down menu. Is this a limitation of the client or the functionality hasn't been implemented? Thanks, Dan From antoine at nagafix.co.uk Sun Aug 5 19:45:21 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 5 Aug 2018 20:45:21 +0200 Subject: [winswitch] SSH Private key on Xpra for Mac In-Reply-To: References: Message-ID: On 05/08/18 17:22, Daniele Polencic via shifter-users wrote: > Hello, > > I set up remote workspaces with Xpra, and I connected to them using the > Gtk3 client on a Mac. > > https://www.dropbox.com/s/qvdb7w49dcw7og8/Screenshot%202018-08-04%2011.56.08.png?dl=0 Please don't use dropbox for attachments unless you intend to keep the file there forever, with the same URL. Those browsing the mailing list in the future will be hitting dead ends otherwise. > I noticed that I couldn't select a private key when I used the SSH option > from the drop-down menu. > > Is this a limitation of the client or the functionality hasn't been > implemented? The GUI doesn't have this option. Just like it doesn't have 99% of the options available on the command line. You can use the command line, or stick the options in your per-user xpra.conf. ie: echo "ssh=ssh -x -i /path/to/keyfile" >> ~/.xpra/xpra.conf Cheers Antoine > > Thanks, > Dan From pierre.wulles at gmail.com Mon Aug 6 10:29:44 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Mon, 6 Aug 2018 11:29:44 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> Message-ID: Hello, > And when asking questions, make sure to include what commands you are using, what you have tried, the log output, etc. The thing is that I don't know what command I am supposed to use! What I want is to start a session remotely, let assume that I want to start a graphical software remotely but I don't know which one, then what should I type on server/proxy/client to do so ? I've succeeded to start a session like this: {{{ xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server xpra proxy :100 --bind-tcp=0.0.0.0:14501 --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client }}} But I need to say on the first command "xterm", what I want is something like: {{{ xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server xpra proxy :100 --bind-tcp=0.0.0.0:14501 --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client }}} WIth this the client can choose what software he wants to start. Thank you, I hope it's clear enough. Pierre Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a ?crit : > Please always use the mailing list. > And when asking questions, make sure to include what commands you are > using, what you have tried, the log output, etc. > http://xpra.org/trac/wiki/ReportingBugs > > Antoine > > On 04/08/18 15:41, Pierre Wulles wrote: > > Hello, > > Thank you for your answer! I finally succeded in connecting with > > encryption, my question now is " is it possible to start a session > > remotely and attach to it ? > > Best regards, > > Pierre > > > > Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users > > > > a ?crit : > > > > On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: > > > Hello, > > > I've recently succeeded in having a server running xterm, a proxy > > and a > > > machine connecting to the proxy. I used for this what is described > in > > > https://xpra.org/trac/wiki/ProxyServer at the section Remote > > Hosts. What I > > > want to do now is launching the pplication from the client, so > > what I did > > > is: > > > {{{ > > > xpra start :100 --bind-tcp=0.0.0.0:10100 > > > }}} > > You said you wanted to launch from the client, but here you are > > launching a session in advance. > > Did you mean "connect from the client" instead? > > > > > on the server. Then > > > {{{ > > > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > > > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp > > --daemon=no > > > }}} > > The "allow" authentication module does not use any arguments. > > Certainly not the database file which is meant to be used by the > sqlite > > auth module. > > > > > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth > > because I > > > didn't know how to indicate where the server is, > > Specifying remote hosts is documented for the sqlite backend on the > > proxy wiki page: > > https://xpra.org/trac/wiki/ProxyServer#RemoteHosts > > ie: > > sqlite_auth.py ./auth.sdb add foo bar nobody nobody > > tcp://1.1.1.1:10100/ > > > > > the problem that I guess > > > here is that if you put --tcp-auth=allow the file xpra-auth is > ignored > > > because when I go to the client: > > > {{{ > > > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm > > > }}} > > FYI: tcp-auth here would apply to the session you end up starting. > > That's usually a bad idea for anything but testing. > > And in this case, it is very unlikely to be needed since you will be > > connected to the session when you start it anyway. > > > > > I have the following error: > > > {{{ > > > 2018-07-31 13:50:22,161 Error: authentication failed: > > > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly > > refusing > > > to use it without encryption > > > }}} > > xpra will refuse to send password unencrypted over the network. > > > > > What can I do ? > > Like it says, use encryption. > > https://xpra.org/trac/wiki/Encryption > > > > Cheers, > > Antoine > > > > > Thank you, > > > Pierre > > > _______________________________________________ > > > shifter-users mailing list > > > shifter-users at lists.devloop.org.uk > > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > > > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > From daniele.polencic at gmail.com Mon Aug 6 13:46:05 2018 From: daniele.polencic at gmail.com (Daniele Polencic) Date: Mon, 6 Aug 2018 13:46:05 +0100 Subject: [winswitch] Unable to attach from Windows Message-ID: Hello, I installed Xpra on a Linux VM. >From my mac I can SSH into the VM with: ssh workspace and I can attach to an Xpra session with: xpra attach ssh:workspace I tried to do the same on Windows. I can connect to SSH with: ssh workspace But I can't connect to Xpra. To attach to an existing session I used: "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh/workspace I also tried to force a display with: "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh/workspace/1 The output is the following: C:\Users\pole ? "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh/workspace 2018-08-06 13:35:30,765 Xpra gtk2 client version 2.3.2-r19729 64-bit 2018-08-06 13:35:30,780 running on Microsoft Windows 10 2018-08-06 13:35:38,670 Warning: failed to import opencv: 2018-08-06 13:35:38,670 DLL load failed: A dynamic link library (DLL) initialization routine failed. 2018-08-06 13:35:38,670 webcam forwarding is disabled 2018-08-06 13:35:39,154 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-08-06 13:35:40,381 OpenGL_accelerate module loaded 2018-08-06 13:35:40,475 Using accelerated ArrayDatatype 2018-08-06 13:35:40,979 Warning: vendor 'Parallels and Intel Inc.' is greylisted, 2018-08-06 13:35:40,979 you may want to turn off OpenGL if you encounter bugs 2018-08-06 13:35:41,111 OpenGL enabled with Parallels using Intel(R) HD Graphics 530 2018-08-06 13:35:41,173 desktop size is 1024x768 with 1 screen: 2018-08-06 13:35:41,173 Default (270x203 mm - DPI: 96x96) workarea: 1024x728 2018-08-06 13:35:41,189 DISPLAY1 (200x150 mm - DPI: 130x130) 2018-08-06 13:35:41,236 keyboard settings: layout=us 2018-08-06 13:35:43,593 Error: failed to receive anything, not an xpra server? 2018-08-06 13:35:43,593 could also be the wrong protocol, username, password or port 2018-08-06 13:35:43,609 or maybe this server does not support 'unknown' compression or 'rencode' packet encoding? 2018-08-06 13:35:43,609 Connection lost I tried with the UI and it silently fails. I installed the following binary: https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe The Xpra client on Windows is: v1.0 14492 The Xpra client on Mac is: xpra v1.0.12-r19800 The Xpra server running on Ubuntu is: xpra v2.3.2-r19729 Is there anything else I should try? Thanks, D From antoine at nagafix.co.uk Mon Aug 6 14:03:13 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 6 Aug 2018 15:03:13 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> Message-ID: <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: > Hello, >> And when asking questions, make sure to include what commands you are > using, what you have tried, the log output, etc. > The thing is that I don't know what command I am supposed to use! What I > want is to start a session remotely, let assume that I want to start a > graphical software remotely but I don't know which one, then what should I > type on server/proxy/client to do so ? > I've succeeded to start a session like this: > {{{ > xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy > xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client > }}} > But I need to say on the first command "xterm", what I want is something > like: > {{{ > xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy > xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client > }}} > WIth this the client can choose what software he wants to start. You can already start new sessions via the proxy server with: xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever With one important limitation: the sessions will be started on the same host where the proxy is running, the proxy just executes an "xpra start" for you. Regarding the proxy authentication configuration, since the session will be a local session it will need an account to run: * if using "sys" auth, "foo" must be a valid user account on proxyhost * if using "sqlite" auth, you must configure the mapping to user accounts (uid, gid) yourself when creating the authentication database Until now, it wasn't possible for the client request commands to be executed on the server after the connection is established (it was only possible manually through the system tray menu: Server -> Run Command) This feature has now been added for "attach" in xpra 2.4: http://xpra.org/trac/ticket/1931 So now you can do: xpra attach --start=xterm Or for a remote host: xpra attach ssl://foo:bar at proxyhost/ --start=xterm This will work for your use-case as long as the backend session is started in advance, and you will need to populate the sqlite database to point to it as before. If you want to use --exit-with-children in this way, you still can, here's a hackish solution which you can adapt: xpra start --start-new-commands=yes --start-child="sleep 9999999" --exit-with-children xpra attach --start-child="xterm" --start="killall sleep" Allowing the proxy server to start sessions on remote servers (via ssh or through a second proxy server) would be possible, but this would be much more difficult to implement properly. This should probably tie in with load balancing and session accounting features. Feel free to create a ticket for it. Cheers, Antoine > Thank you, I hope it's clear enough. > Pierre > > Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a > ?crit : > >> Please always use the mailing list. >> And when asking questions, make sure to include what commands you are >> using, what you have tried, the log output, etc. >> http://xpra.org/trac/wiki/ReportingBugs >> >> Antoine >> >> On 04/08/18 15:41, Pierre Wulles wrote: >>> Hello, >>> Thank you for your answer! I finally succeded in connecting with >>> encryption, my question now is " is it possible to start a session >>> remotely and attach to it ? >>> Best regards, >>> Pierre >>> >>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users >>> >> > a ?crit : >>> >>> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>> > Hello, >>> > I've recently succeeded in having a server running xterm, a proxy >>> and a >>> > machine connecting to the proxy. I used for this what is described >> in >>> > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>> Hosts. What I >>> > want to do now is launching the pplication from the client, so >>> what I did >>> > is: >>> > {{{ >>> > xpra start :100 --bind-tcp=0.0.0.0:10100 >>> > }}} >>> You said you wanted to launch from the client, but here you are >>> launching a session in advance. >>> Did you mean "connect from the client" instead? >>> >>> > on the server. Then >>> > {{{ >>> > xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>> > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>> --daemon=no >>> > }}} >>> The "allow" authentication module does not use any arguments. >>> Certainly not the database file which is meant to be used by the >> sqlite >>> auth module. >>> >>> > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth >>> because I >>> > didn't know how to indicate where the server is, >>> Specifying remote hosts is documented for the sqlite backend on the >>> proxy wiki page: >>> https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>> ie: >>> sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>> tcp://1.1.1.1:10100/ >>> >>> > the problem that I guess >>> > here is that if you put --tcp-auth=allow the file xpra-auth is >> ignored >>> > because when I go to the client: >>> > {{{ >>> > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm >>> > }}} >>> FYI: tcp-auth here would apply to the session you end up starting. >>> That's usually a bad idea for anything but testing. >>> And in this case, it is very unlikely to be needed since you will be >>> connected to the session when you start it anyway. >>> >>> > I have the following error: >>> > {{{ >>> > 2018-07-31 13:50:22,161 Error: authentication failed: >>> > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly >>> refusing >>> > to use it without encryption >>> > }}} >>> xpra will refuse to send password unencrypted over the network. >>> >>> > What can I do ? >>> Like it says, use encryption. >>> https://xpra.org/trac/wiki/Encryption >>> >>> Cheers, >>> Antoine >>> >>> > Thank you, >>> > Pierre >>> > _______________________________________________ >>> > shifter-users mailing list >>> > shifter-users at lists.devloop.org.uk >>> >>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> > >>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Mon Aug 6 14:24:56 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 6 Aug 2018 15:24:56 +0200 Subject: [winswitch] Unable to attach from Windows In-Reply-To: References: Message-ID: <9981d1ed-b82e-6d43-6fcd-da4294750a71@nagafix.co.uk> On 06/08/18 14:46, Daniele Polencic via shifter-users wrote: > Hello, > > I installed Xpra on a Linux VM. > > From my mac I can SSH into the VM with: > ssh workspace > and I can attach to an Xpra session with: > xpra attach ssh:workspace > > I tried to do the same on Windows. I can connect to SSH with: > ssh workspace Is this openssh? from mingw? cygwin? > But I can't connect to Xpra. To attach to an existing session I used: > > "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh/workspace (..) > 2018-08-06 13:35:43,593 Error: failed to receive anything, not an xpra > server? > 2018-08-06 13:35:43,593 could also be the wrong protocol, username, > password or port > 2018-08-06 13:35:43,609 or maybe this server does not support 'unknown' > compression or 'rencode' packet encoding? > 2018-08-06 13:35:43,609 Connection lost > > I tried with the UI and it silently fails. I installed the following > binary: https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe > > The Xpra client on Windows is: v1.0 14492 That's way too old. (over a year and a half's worth of fixes) > The Xpra client on Mac is: xpra v1.0.12-r19800 Try the latest stable 2.3.x builds for both macos and windows. There is absolutely no reason to use the 1.x branch on MacOS or MS Windows unless you run Windows XP or MacOS versions older than 10.9 > The Xpra server running on Ubuntu is: xpra v2.3.2-r19729 > > Is there anything else I should try? Does your system log on the server show a connection attempt at all? If so, does the ssh authentication succeed? Try to specify your username and maybe even the password on the command line: xpra_cmd attach ssh://username:password at host/ You can also enable ssh debugging with: set XPRA_SSH_DEBUG=1 This will log the exact SSH command line used for connecting to the server. You can then run it by hand to see what happens. The latest 2.4 beta builds I posted yesterday include a new ssh backend which may give you more diagnostics: xpra_cmd attach ssh://username:password at host/ -d ssh You can download 2.4 beta builds from: https://xpra.org/beta/windows/ Cheers Antoine > > Thanks, > D > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From pierre.wulles at gmail.com Mon Aug 6 15:34:41 2018 From: pierre.wulles at gmail.com (Pierre Wulles) Date: Mon, 6 Aug 2018 16:34:41 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> Message-ID: Hello, Well this is good news! I'm happy you added it in the last version, as soon as I've received your email I've upgraded (xpra v2.4-r20042) and tried what you said. But I have now a major error when starting xpra: {{{ ? ~ xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm xpra main error: Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 72, in main options, args = do_parse_cmdline(cmdline, defaults) File "/usr/lib64/python2.7/site-packages/xpra/scripts/parsing.py", line 1114, in do_parse_cmdline fixup_options(options, defaults) File "/usr/lib64/python2.7/site-packages/xpra/scripts/config.py", line 1365, in fixup_options fixup_packetencoding(options) File "/usr/lib64/python2.7/site-packages/xpra/scripts/config.py", line 1303, in fixup_packetencoding from xpra.net import packet_encoding File "/usr/lib64/python2.7/site-packages/xpra/net/packet_encoding.py", line 9, in from numpy import isin ImportError: cannot import name isin }}} Is is because of the new version? Did I upgraded it bad? It was working well before. Thank you, Pierre Le lun. 6 ao?t 2018 ? 15:03, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> a ?crit : > On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: > > Hello, > >> And when asking questions, make sure to include what commands you are > > using, what you have tried, the log output, etc. > > The thing is that I don't know what command I am supposed to use! What I > > want is to start a session remotely, let assume that I want to start a > > graphical software remotely but I don't know which one, then what should > I > > type on server/proxy/client to do so ? > > I've succeeded to start a session like this: > > {{{ > > xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server > > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > > --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy > > xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client > > }}} > > But I need to say on the first command "xterm", what I want is something > > like: > > {{{ > > xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server > > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > > --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy > > xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client > > }}} > > WIth this the client can choose what software he wants to start. > You can already start new sessions via the proxy server with: > xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever > With one important limitation: the sessions will be started on the same > host where the proxy is running, the proxy just executes an "xpra start" > for you. > Regarding the proxy authentication configuration, since the session will > be a local session it will need an account to run: > * if using "sys" auth, "foo" must be a valid user account on proxyhost > * if using "sqlite" auth, you must configure the mapping to user > accounts (uid, gid) yourself when creating the authentication database > > Until now, it wasn't possible for the client request commands to be > executed on the server after the connection is established (it was only > possible manually through the system tray menu: Server -> Run Command) > This feature has now been added for "attach" in xpra 2.4: > http://xpra.org/trac/ticket/1931 > So now you can do: > xpra attach --start=xterm > Or for a remote host: > xpra attach ssl://foo:bar at proxyhost/ --start=xterm > This will work for your use-case as long as the backend session is > started in advance, and you will need to populate the sqlite database to > point to it as before. > > If you want to use --exit-with-children in this way, you still can, > here's a hackish solution which you can adapt: > xpra start --start-new-commands=yes --start-child="sleep 9999999" > --exit-with-children > xpra attach --start-child="xterm" --start="killall sleep" > > Allowing the proxy server to start sessions on remote servers (via ssh > or through a second proxy server) would be possible, but this would be > much more difficult to implement properly. This should probably tie in > with load balancing and session accounting features. > Feel free to create a ticket for it. > > Cheers, > Antoine > > > > > > > Thank you, I hope it's clear enough. > > Pierre > > > > Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a > > ?crit : > > > >> Please always use the mailing list. > >> And when asking questions, make sure to include what commands you are > >> using, what you have tried, the log output, etc. > >> http://xpra.org/trac/wiki/ReportingBugs > >> > >> Antoine > >> > >> On 04/08/18 15:41, Pierre Wulles wrote: > >>> Hello, > >>> Thank you for your answer! I finally succeded in connecting with > >>> encryption, my question now is " is it possible to start a session > >>> remotely and attach to it ? > >>> Best regards, > >>> Pierre > >>> > >>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users > >>> >>> > a ?crit : > >>> > >>> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: > >>> > Hello, > >>> > I've recently succeeded in having a server running xterm, a proxy > >>> and a > >>> > machine connecting to the proxy. I used for this what is > described > >> in > >>> > https://xpra.org/trac/wiki/ProxyServer at the section Remote > >>> Hosts. What I > >>> > want to do now is launching the pplication from the client, so > >>> what I did > >>> > is: > >>> > {{{ > >>> > xpra start :100 --bind-tcp=0.0.0.0:10100 > >>> > }}} > >>> You said you wanted to launch from the client, but here you are > >>> launching a session in advance. > >>> Did you mean "connect from the client" instead? > >>> > >>> > on the server. Then > >>> > {{{ > >>> > xpra proxy :100 --bind-tcp=0.0.0.0:14501 > >>> > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp > >>> --daemon=no > >>> > }}} > >>> The "allow" authentication module does not use any arguments. > >>> Certainly not the database file which is meant to be used by the > >> sqlite > >>> auth module. > >>> > >>> > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth > >>> because I > >>> > didn't know how to indicate where the server is, > >>> Specifying remote hosts is documented for the sqlite backend on the > >>> proxy wiki page: > >>> https://xpra.org/trac/wiki/ProxyServer#RemoteHosts > >>> ie: > >>> sqlite_auth.py ./auth.sdb add foo bar nobody nobody > >>> tcp://1.1.1.1:10100/ > >>> > >>> > the problem that I guess > >>> > here is that if you put --tcp-auth=allow the file xpra-auth is > >> ignored > >>> > because when I go to the client: > >>> > {{{ > >>> > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm > >>> > }}} > >>> FYI: tcp-auth here would apply to the session you end up starting. > >>> That's usually a bad idea for anything but testing. > >>> And in this case, it is very unlikely to be needed since you will > be > >>> connected to the session when you start it anyway. > >>> > >>> > I have the following error: > >>> > {{{ > >>> > 2018-07-31 13:50:22,161 Error: authentication failed: > >>> > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly > >>> refusing > >>> > to use it without encryption > >>> > }}} > >>> xpra will refuse to send password unencrypted over the network. > >>> > >>> > What can I do ? > >>> Like it says, use encryption. > >>> https://xpra.org/trac/wiki/Encryption > >>> > >>> Cheers, > >>> Antoine > >>> > >>> > Thank you, > >>> > Pierre > >>> > _______________________________________________ > >>> > shifter-users mailing list > >>> > shifter-users at lists.devloop.org.uk > >>> > >>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>> > > >>> > >>> _______________________________________________ > >>> shifter-users mailing list > >>> shifter-users at lists.devloop.org.uk > >>> > >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > >>> > >> > >> > > _______________________________________________ > > shifter-users mailing list > > shifter-users at lists.devloop.org.uk > > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From daniele.polencic at gmail.com Mon Aug 6 15:42:26 2018 From: daniele.polencic at gmail.com (Daniele Polencic) Date: Mon, 6 Aug 2018 15:42:26 +0100 Subject: [winswitch] Unable to attach from Windows In-Reply-To: <9981d1ed-b82e-6d43-6fcd-da4294750a71@nagafix.co.uk> References: <9981d1ed-b82e-6d43-6fcd-da4294750a71@nagafix.co.uk> Message-ID: On Mon, 6 Aug 2018 at 14:25, Antoine Martin via shifter-users < shifter-users at lists.devloop.org.uk> wrote: > On 06/08/18 14:46, Daniele Polencic via shifter-users wrote: > > Hello, > > > > I installed Xpra on a Linux VM. > > > > From my mac I can SSH into the VM with: > > ssh workspace > > and I can attach to an Xpra session with: > > xpra attach ssh:workspace > > > > I tried to do the same on Windows. I can connect to SSH with: > > ssh workspace > Is this openssh? from mingw? cygwin? > I used Cmder http://cmder.net Tried with Cygwin, same error. > > But I can't connect to Xpra. To attach to an existing session I used: > > > > "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh/workspace > (..) > > 2018-08-06 13:35:43,593 Error: failed to receive anything, not an xpra > > server? > > 2018-08-06 13:35:43,593 could also be the wrong protocol, username, > > password or port > > 2018-08-06 13:35:43,609 or maybe this server does not support 'unknown' > > compression or 'rencode' packet encoding? > > 2018-08-06 13:35:43,609 Connection lost > > > > I tried with the UI and it silently fails. I installed the following > > binary: https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe > > > > The Xpra client on Windows is: v1.0 14492 > That's way too old. (over a year and a half's worth of fixes) > > The Xpra client on Mac is: xpra v1.0.12-r19800 > Try the latest stable 2.3.x builds for both macos and windows. > There is absolutely no reason to use the 1.x branch on MacOS or MS > Windows unless you run Windows XP or MacOS versions older than 10.9 > Thanks for pointing that out. The links on the home page are pointing to version 1 of the client. I should have checked. > > The Xpra server running on Ubuntu is: xpra v2.3.2-r19729 > > > > Is there anything else I should try? > Does your system log on the server show a connection attempt at all? > If so, does the ssh authentication succeed? > As I mentioned, I can see a prompt in both Mac and Windows when I type "ssh workspace". The connection is working. > Try to specify your username and maybe even the password on the command > line: > xpra_cmd attach ssh://username:password at host/ > I'm using private keys to connect to SSH, so I won't be able to test the password. But I tested the user and makes no difference. > You can also enable ssh debugging with: > set XPRA_SSH_DEBUG=1 > This will log the exact SSH command line used for connecting to the > server. You can then run it by hand to see what happens. > mac: xpra v2.2.2-r18017 executing ssh command: "ssh" "-T" "workspace" "sh -c 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy;elif type "xpra" > /dev/null 2>&1; then xpra _proxy;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy;else echo "no run-xpra command found"; exit 1; fi'" windows: 2.3.2-r19729 executing ssh command: "plink" "-ssh" "-agent" "-T" "workspace" "xpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :1;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :1;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :1;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :1;else echo "no run-xpra command found"; exit 1; fi" I looked into the logs and you're right. I can't see a successful login with when I attach from windows. After more digging, I noticed that Xpra client uses plink and not the standard ssh command. Since plink doesn't know how to look into .ssh/config the configuration is not picked up and the connection fails. Plink can read saved sessions from Putty, though. After I configured the session in Putty I was able to connect to Xpra with: "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh:workspace Mistery unravelled. Thanks for helping me out. From antoine at nagafix.co.uk Mon Aug 6 16:20:28 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 6 Aug 2018 17:20:28 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> Message-ID: On 06/08/18 16:34, Pierre Wulles via shifter-users wrote: > Hello, > Well this is good news! I'm happy you added it in the last version, as soon > as I've received your email I've upgraded (xpra v2.4-r20042) This r200042 build is too old, the feature you want was added in: http://xpra.org/trac/changeset/20046 > and tried what > you said. But I have now a major error when starting xpra: (..) > Is is because of the new version? Did I upgraded it bad? That's fixed: http://xpra.org/trac/changeset/20048 > It was working well before. Wait for a newer beta build, or patch your installation with the changeset above. Cheers, Antoine > Thank you, > Pierre > > Le lun. 6 ao?t 2018 ? 15:03, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> a ?crit : > >> On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: >>> Hello, >>>> And when asking questions, make sure to include what commands you are >>> using, what you have tried, the log output, etc. >>> The thing is that I don't know what command I am supposed to use! What I >>> want is to start a session remotely, let assume that I want to start a >>> graphical software remotely but I don't know which one, then what should >> I >>> type on server/proxy/client to do so ? >>> I've succeeded to start a session like this: >>> {{{ >>> xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server >>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>> xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client >>> }}} >>> But I need to say on the first command "xterm", what I want is something >>> like: >>> {{{ >>> xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server >>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>> xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client >>> }}} >>> WIth this the client can choose what software he wants to start. >> You can already start new sessions via the proxy server with: >> xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever >> With one important limitation: the sessions will be started on the same >> host where the proxy is running, the proxy just executes an "xpra start" >> for you. >> Regarding the proxy authentication configuration, since the session will >> be a local session it will need an account to run: >> * if using "sys" auth, "foo" must be a valid user account on proxyhost >> * if using "sqlite" auth, you must configure the mapping to user >> accounts (uid, gid) yourself when creating the authentication database >> >> Until now, it wasn't possible for the client request commands to be >> executed on the server after the connection is established (it was only >> possible manually through the system tray menu: Server -> Run Command) >> This feature has now been added for "attach" in xpra 2.4: >> http://xpra.org/trac/ticket/1931 >> So now you can do: >> xpra attach --start=xterm >> Or for a remote host: >> xpra attach ssl://foo:bar at proxyhost/ --start=xterm >> This will work for your use-case as long as the backend session is >> started in advance, and you will need to populate the sqlite database to >> point to it as before. >> >> If you want to use --exit-with-children in this way, you still can, >> here's a hackish solution which you can adapt: >> xpra start --start-new-commands=yes --start-child="sleep 9999999" >> --exit-with-children >> xpra attach --start-child="xterm" --start="killall sleep" >> >> Allowing the proxy server to start sessions on remote servers (via ssh >> or through a second proxy server) would be possible, but this would be >> much more difficult to implement properly. This should probably tie in >> with load balancing and session accounting features. >> Feel free to create a ticket for it. >> >> Cheers, >> Antoine >> >> >> >> >> >>> Thank you, I hope it's clear enough. >>> Pierre >>> >>> Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a >>> ?crit : >>> >>>> Please always use the mailing list. >>>> And when asking questions, make sure to include what commands you are >>>> using, what you have tried, the log output, etc. >>>> http://xpra.org/trac/wiki/ReportingBugs >>>> >>>> Antoine >>>> >>>> On 04/08/18 15:41, Pierre Wulles wrote: >>>>> Hello, >>>>> Thank you for your answer! I finally succeded in connecting with >>>>> encryption, my question now is " is it possible to start a session >>>>> remotely and attach to it ? >>>>> Best regards, >>>>> Pierre >>>>> >>>>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users >>>>> >>>> > a ?crit : >>>>> >>>>> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>>>> > Hello, >>>>> > I've recently succeeded in having a server running xterm, a proxy >>>>> and a >>>>> > machine connecting to the proxy. I used for this what is >> described >>>> in >>>>> > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>>>> Hosts. What I >>>>> > want to do now is launching the pplication from the client, so >>>>> what I did >>>>> > is: >>>>> > {{{ >>>>> > xpra start :100 --bind-tcp=0.0.0.0:10100 >>>>> > }}} >>>>> You said you wanted to launch from the client, but here you are >>>>> launching a session in advance. >>>>> Did you mean "connect from the client" instead? >>>>> >>>>> > on the server. Then >>>>> > {{{ >>>>> > xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>> > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>>>> --daemon=no >>>>> > }}} >>>>> The "allow" authentication module does not use any arguments. >>>>> Certainly not the database file which is meant to be used by the >>>> sqlite >>>>> auth module. >>>>> >>>>> > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth >>>>> because I >>>>> > didn't know how to indicate where the server is, >>>>> Specifying remote hosts is documented for the sqlite backend on the >>>>> proxy wiki page: >>>>> https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>>>> ie: >>>>> sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>>>> tcp://1.1.1.1:10100/ >>>>> >>>>> > the problem that I guess >>>>> > here is that if you put --tcp-auth=allow the file xpra-auth is >>>> ignored >>>>> > because when I go to the client: >>>>> > {{{ >>>>> > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm >>>>> > }}} >>>>> FYI: tcp-auth here would apply to the session you end up starting. >>>>> That's usually a bad idea for anything but testing. >>>>> And in this case, it is very unlikely to be needed since you will >> be >>>>> connected to the session when you start it anyway. >>>>> >>>>> > I have the following error: >>>>> > {{{ >>>>> > 2018-07-31 13:50:22,161 Error: authentication failed: >>>>> > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly >>>>> refusing >>>>> > to use it without encryption >>>>> > }}} >>>>> xpra will refuse to send password unencrypted over the network. >>>>> >>>>> > What can I do ? >>>>> Like it says, use encryption. >>>>> https://xpra.org/trac/wiki/Encryption >>>>> >>>>> Cheers, >>>>> Antoine >>>>> >>>>> > Thank you, >>>>> > Pierre >>>>> > _______________________________________________ >>>>> > shifter-users mailing list >>>>> > shifter-users at lists.devloop.org.uk >>>>> >>>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>> > >>>>> >>>>> _______________________________________________ >>>>> shifter-users mailing list >>>>> shifter-users at lists.devloop.org.uk >>>>> >>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>> >>>> >>>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Mon Aug 6 16:20:57 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 6 Aug 2018 17:20:57 +0200 Subject: [winswitch] Unable to attach from Windows In-Reply-To: References: <9981d1ed-b82e-6d43-6fcd-da4294750a71@nagafix.co.uk> Message-ID: On 06/08/18 16:42, Daniele Polencic wrote: > On Mon, 6 Aug 2018 at 14:25, Antoine Martin via shifter-users > > wrote: > On 06/08/18 14:46, Daniele Polencic via shifter-users wrote: > > Hello, > > > > I installed Xpra on a Linux VM. > > > > From my mac I can SSH into the VM with: > > ssh workspace > > and I can attach to an Xpra session with: > > xpra attach ssh:workspace > > > > I tried to do the same on Windows. I can connect to SSH with: > > ssh workspace > Is this openssh? from mingw? cygwin? > I used Cmder http://cmder.net That's an important piece of information. But not as important as the fact that you were using ssh keys... > Tried with Cygwin, same error. It isn't supposed to work. I was just asking where the 'ssh' command came from. (..) > > I tried with the UI and it silently fails. I installed the following > > binary: https://xpra.org/dists/windows/Xpra-x86_64_Setup.exe > > The Xpra client on Windows is: v1.0 14492 > That's way too old. (over a year and a half's worth of fixes) > > The Xpra client on Mac is: xpra v1.0.12-r19800 > Try the latest stable 2.3.x builds for both macos and windows. > There is absolutely no reason to use the 1.x branch on MacOS or MS > Windows unless you run Windows XP or MacOS versions older than 10.9 > Thanks for pointing that out. The links on the home page are pointing to > version 1 of the client. I should have checked. AFAIK, this is not true: # ls -la windows/Xpra-x86_64_Setup.exe windows/Xpra-x86_64_Setup.exe -> Xpra-x86_64_Setup_2.3.2-r19729.exe # ls -la windows/Xpra_Setup.exe windows/Xpra_Setup.exe -> Xpra_Setup_2.3.2-r19729.exe # ls -la MacOS/x86_64/Xpra-x86_64.pkg MacOS/x86_64/Xpra-x86_64.pkg -> Xpra-x86_64-2.3.2-r19729.pkg I even double checked and downloaded the canonical links on the home page then compared the checksums. > > The Xpra server running on Ubuntu is: xpra v2.3.2-r19729 > > Is there anything else I should try? > Does your system log on the server show a connection attempt at all? > If so, does the ssh authentication succeed? > As I mentioned, I can see a prompt in both Mac and Windows when I type > "ssh workspace". > The connection is working. I meant when xpra is doing the same thing. > Try to specify your username and maybe even the password on the command > line: > xpra_cmd attach ssh://username:password at host/ > I'm using private keys to connect to SSH, so I won't be able to test the > password. And here is the essential piece of information that was missing! (..)> After more digging, I noticed that Xpra client uses plink and not the > standard ssh command. Since plink doesn't know how to look into > .ssh/config the configuration is not picked up and the connection fails. > > Plink can read saved sessions from Putty, though. After I configured the > session in Putty I was able to connect to Xpra with: > > "C:\Program Files\Xpra\Xpra_cmd.exe" attach ssh:workspace > > Mistery unravelled. Be aware that xpra 2.4 will switch to paramiko by default, to switch back to plink, you will need to add: ssh=plink -ssh -agent To your user's ~/.xpra/xpra.conf > Thanks for helping me out. Cheers, Antoine From pierre.wulles at gmail.com Tue Aug 7 13:25:51 2018 From: pierre.wulles at gmail.com (pwulles) Date: Tue, 7 Aug 2018 14:25:51 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> Message-ID: <17e21fe0-61dc-ca09-a547-f2ed65776fc4@gmail.com> Hello, Well I've tried to install the latest version, so i'm now runnning with xpra v2.4-r20056 but I have now a new bug when executing: xpra attach ssl://foo:bar at proxyhost/ --start=xterm xpra main error: Traceback (most recent call last): ? File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 78, in main ??? return run_mode(script_file, err, options, args, mode, defaults) ? File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 384, in run_mode ??? return run_client(error_cb, options, args, mode) ? File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1161, in run_client ??? app = get_client_app(error_cb, opts, extra_args, mode) ? File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1237, in get_client_app ??? from xpra.platform.gui import init as gui_init ? File "/usr/lib64/python2.7/site-packages/xpra/platform/gui.py", line 278, in ??? "get_info") ? File "/usr/lib64/python2.7/site-packages/xpra/platform/__init__.py", line 159, in platform_import ??? platform_module = __import__(module, {}, {}, imports) ? File "/usr/lib64/python2.7/site-packages/xpra/platform/xposix/gui.py", line 23, in ??? from xpra.gtk_common.gtk_util import get_xwindow ? File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gtk_util.py", line 12, in ??? gtk???? = import_gtk() ? File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 111, in import_gtk ??? return? _try_import(import_gtk3, import_gtk2) ? File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 55, in _try_import ??? imported = trygtk3() ? File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 44, in trygtk3 ??? return import_method_gtk3() ? File "/usr/lib64/python2.7/site-packages/xpra/gtk_common/gobject_compat.py", line 105, in import_gtk3 ??? import gi ? File "/usr/lib64/python2.7/site-packages/gi/__init__.py", line 33, in ??? raise ImportError('When using gi.repository you must not import static ' ImportError: When using gi.repository you must not import static modules like "gobject". Please change all occurrences of "import gobject" to "from gi.repository import GObject". What can I do ? Pierre On 06/08/2018 17:20, Antoine Martin via shifter-users wrote: > On 06/08/18 16:34, Pierre Wulles via shifter-users wrote: >> Hello, >> Well this is good news! I'm happy you added it in the last version, as soon >> as I've received your email I've upgraded (xpra v2.4-r20042) > This r200042 build is too old, the feature you want was added in: > http://xpra.org/trac/changeset/20046 > >> and tried what >> you said. But I have now a major error when starting xpra: > (..) >> Is is because of the new version? Did I upgraded it bad? > That's fixed: > http://xpra.org/trac/changeset/20048 >> It was working well before. > Wait for a newer beta build, or patch your installation with the > changeset above. > > Cheers, > Antoine > >> Thank you, >> Pierre >> >> Le lun. 6 ao?t 2018 ? 15:03, Antoine Martin via shifter-users < >> shifter-users at lists.devloop.org.uk> a ?crit : >> >>> On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: >>>> Hello, >>>>> And when asking questions, make sure to include what commands you are >>>> using, what you have tried, the log output, etc. >>>> The thing is that I don't know what command I am supposed to use! What I >>>> want is to start a session remotely, let assume that I want to start a >>>> graphical software remotely but I don't know which one, then what should >>> I >>>> type on server/proxy/client to do so ? >>>> I've succeeded to start a session like this: >>>> {{{ >>>> xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server >>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>> xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client >>>> }}} >>>> But I need to say on the first command "xterm", what I want is something >>>> like: >>>> {{{ >>>> xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server >>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>> xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client >>>> }}} >>>> WIth this the client can choose what software he wants to start. >>> You can already start new sessions via the proxy server with: >>> xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever >>> With one important limitation: the sessions will be started on the same >>> host where the proxy is running, the proxy just executes an "xpra start" >>> for you. >>> Regarding the proxy authentication configuration, since the session will >>> be a local session it will need an account to run: >>> * if using "sys" auth, "foo" must be a valid user account on proxyhost >>> * if using "sqlite" auth, you must configure the mapping to user >>> accounts (uid, gid) yourself when creating the authentication database >>> >>> Until now, it wasn't possible for the client request commands to be >>> executed on the server after the connection is established (it was only >>> possible manually through the system tray menu: Server -> Run Command) >>> This feature has now been added for "attach" in xpra 2.4: >>> http://xpra.org/trac/ticket/1931 >>> So now you can do: >>> xpra attach --start=xterm >>> Or for a remote host: >>> xpra attach ssl://foo:bar at proxyhost/ --start=xterm >>> This will work for your use-case as long as the backend session is >>> started in advance, and you will need to populate the sqlite database to >>> point to it as before. >>> >>> If you want to use --exit-with-children in this way, you still can, >>> here's a hackish solution which you can adapt: >>> xpra start --start-new-commands=yes --start-child="sleep 9999999" >>> --exit-with-children >>> xpra attach --start-child="xterm" --start="killall sleep" >>> >>> Allowing the proxy server to start sessions on remote servers (via ssh >>> or through a second proxy server) would be possible, but this would be >>> much more difficult to implement properly. This should probably tie in >>> with load balancing and session accounting features. >>> Feel free to create a ticket for it. >>> >>> Cheers, >>> Antoine >>> >>> >>> >>> >>> >>>> Thank you, I hope it's clear enough. >>>> Pierre >>>> >>>> Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a >>>> ?crit : >>>> >>>>> Please always use the mailing list. >>>>> And when asking questions, make sure to include what commands you are >>>>> using, what you have tried, the log output, etc. >>>>> http://xpra.org/trac/wiki/ReportingBugs >>>>> >>>>> Antoine >>>>> >>>>> On 04/08/18 15:41, Pierre Wulles wrote: >>>>>> Hello, >>>>>> Thank you for your answer! I finally succeded in connecting with >>>>>> encryption, my question now is " is it possible to start a session >>>>>> remotely and attach to it ? >>>>>> Best regards, >>>>>> Pierre >>>>>> >>>>>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users >>>>>> >>>>> > a ?crit : >>>>>> >>>>>> On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>>>>> > Hello, >>>>>> > I've recently succeeded in having a server running xterm, a proxy >>>>>> and a >>>>>> > machine connecting to the proxy. I used for this what is >>> described >>>>> in >>>>>> > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>>>>> Hosts. What I >>>>>> > want to do now is launching the pplication from the client, so >>>>>> what I did >>>>>> > is: >>>>>> > {{{ >>>>>> > xpra start :100 --bind-tcp=0.0.0.0:10100 >>>>>> > }}} >>>>>> You said you wanted to launch from the client, but here you are >>>>>> launching a session in advance. >>>>>> Did you mean "connect from the client" instead? >>>>>> >>>>>> > on the server. Then >>>>>> > {{{ >>>>>> > xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>>> > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>>>>> --daemon=no >>>>>> > }}} >>>>>> The "allow" authentication module does not use any arguments. >>>>>> Certainly not the database file which is meant to be used by the >>>>> sqlite >>>>>> auth module. >>>>>> >>>>>> > On the proxy and there is "foo bar nobody nobody ip" in xpra-auth >>>>>> because I >>>>>> > didn't know how to indicate where the server is, >>>>>> Specifying remote hosts is documented for the sqlite backend on the >>>>>> proxy wiki page: >>>>>> https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>>>>> ie: >>>>>> sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>>>>> tcp://1.1.1.1:10100/ >>>>>> >>>>>> > the problem that I guess >>>>>> > here is that if you put --tcp-auth=allow the file xpra-auth is >>>>> ignored >>>>>> > because when I go to the client: >>>>>> > {{{ >>>>>> > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 xterm >>>>>> > }}} >>>>>> FYI: tcp-auth here would apply to the session you end up starting. >>>>>> That's usually a bad idea for anything but testing. >>>>>> And in this case, it is very unlikely to be needed since you will >>> be >>>>>> connected to the session when you start it anyway. >>>>>> >>>>>> > I have the following error: >>>>>> > {{{ >>>>>> > 2018-07-31 13:50:22,161 Error: authentication failed: >>>>>> > 2018-07-31 13:50:22,161 server requested 'xor' digest, cowardly >>>>>> refusing >>>>>> > to use it without encryption >>>>>> > }}} >>>>>> xpra will refuse to send password unencrypted over the network. >>>>>> >>>>>> > What can I do ? >>>>>> Like it says, use encryption. >>>>>> https://xpra.org/trac/wiki/Encryption >>>>>> >>>>>> Cheers, >>>>>> Antoine >>>>>> >>>>>> > Thank you, >>>>>> > Pierre >>>>>> > _______________________________________________ >>>>>> > shifter-users mailing list >>>>>> > shifter-users at lists.devloop.org.uk >>>>>> >>>>>> > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>> > >>>>>> >>>>>> _______________________________________________ >>>>>> shifter-users mailing list >>>>>> shifter-users at lists.devloop.org.uk >>>>>> >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>> >>>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From antoine at nagafix.co.uk Tue Aug 7 13:32:18 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 7 Aug 2018 14:32:18 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: <17e21fe0-61dc-ca09-a547-f2ed65776fc4@gmail.com> References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> <17e21fe0-61dc-ca09-a547-f2ed65776fc4@gmail.com> Message-ID: On 07/08/18 14:25, pwulles via shifter-users wrote: > Hello, > > Well I've tried to install the latest version, so i'm now runnning with > xpra v2.4-r20056 but I have now a new bug when executing: > > xpra attach ssl://foo:bar at proxyhost/ --start=xterm > > xpra main error: (..) > ImportError: When using gi.repository you must not import static modules > like "gobject". Please change all occurrences of "import gobject" to > "from gi.repository import GObject". > > What can I do ? Judging from the stacktrace line numbers, you don't have pygtk installed, which should be impossible if you have installed the packages properly. Without knowing more about your distro, version, installation, environment, etc. It's difficult to tell you more. Cheers, Antoine > > Pierre > > > On 06/08/2018 17:20, Antoine Martin via shifter-users wrote: >> On 06/08/18 16:34, Pierre Wulles via shifter-users wrote: >>> Hello, >>> Well this is good news! I'm happy you added it in the last version, >>> as soon >>> as I've received your email I've upgraded (xpra v2.4-r20042) >> This r200042 build is too old, the feature you want was added in: >> http://xpra.org/trac/changeset/20046 >> >>> and tried what >>> you said. But I have now a major error when starting xpra: >> (..) >>> Is is because of the new version? Did I upgraded it bad? >> That's fixed: >> http://xpra.org/trac/changeset/20048 >>> ? It was working well before. >> Wait for a newer beta build, or patch your installation with the >> changeset above. >> >> Cheers, >> Antoine >> >>> Thank you, >>> Pierre >>> >>> Le lun. 6 ao?t 2018 ? 15:03, Antoine Martin via shifter-users < >>> shifter-users at lists.devloop.org.uk> a ?crit : >>> >>>> On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: >>>>> Hello, >>>>>> And when asking questions, make sure to include what commands you are >>>>> using, what you have tried, the log output, etc. >>>>> The thing is that I don't know what command I am supposed to use! >>>>> What I >>>>> want is to start a session remotely, let assume that I want to start a >>>>> graphical software remotely but I don't know which one, then what >>>>> should >>>> I >>>>> type on server/proxy/client to do so ? >>>>> I've succeeded to start a session like this: >>>>> {{{ >>>>> xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server >>>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>>> xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client >>>>> }}} >>>>> But I need to say on the first command "xterm", what I want is >>>>> something >>>>> like: >>>>> {{{ >>>>> xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server >>>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>>> xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client >>>>> }}} >>>>> WIth this the client can choose what software he wants to start. >>>> You can already start new sessions via the proxy server with: >>>> xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever >>>> With one important limitation: the sessions will be started on the same >>>> host where the proxy is running, the proxy just executes an "xpra >>>> start" >>>> for you. >>>> Regarding the proxy authentication configuration, since the session >>>> will >>>> be a local session it will need an account to run: >>>> * if using "sys" auth, "foo" must be a valid user account on proxyhost >>>> * if using "sqlite" auth, you must configure the mapping to user >>>> accounts (uid, gid) yourself when creating the authentication database >>>> >>>> Until now, it wasn't possible for the client request commands to be >>>> executed on the server after the connection is established (it was only >>>> possible manually through the system tray menu: Server -> Run Command) >>>> This feature has now been added for "attach" in xpra 2.4: >>>> http://xpra.org/trac/ticket/1931 >>>> So now you can do: >>>> xpra attach --start=xterm >>>> Or for a remote host: >>>> xpra attach ssl://foo:bar at proxyhost/ --start=xterm >>>> This will work for your use-case as long as the backend session is >>>> started in advance, and you will need to populate the sqlite >>>> database to >>>> point to it as before. >>>> >>>> If you want to use --exit-with-children in this way, you still can, >>>> here's a hackish solution which you can adapt: >>>> xpra start --start-new-commands=yes --start-child="sleep 9999999" >>>> --exit-with-children >>>> xpra attach --start-child="xterm" --start="killall sleep" >>>> >>>> Allowing the proxy server to start sessions on remote servers (via ssh >>>> or through a second proxy server) would be possible, but this would be >>>> much more difficult to implement properly. This should probably tie in >>>> with load balancing and session accounting features. >>>> Feel free to create a ticket for it. >>>> >>>> Cheers, >>>> Antoine >>>> >>>> >>>> >>>> >>>> >>>>> Thank you, I hope it's clear enough. >>>>> Pierre >>>>> >>>>> Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a >>>>> ?crit : >>>>> >>>>>> Please always use the mailing list. >>>>>> And when asking questions, make sure to include what commands you are >>>>>> using, what you have tried, the log output, etc. >>>>>> http://xpra.org/trac/wiki/ReportingBugs >>>>>> >>>>>> Antoine >>>>>> >>>>>> On 04/08/18 15:41, Pierre Wulles wrote: >>>>>>> Hello, >>>>>>> Thank you for your answer! I finally succeded in connecting with >>>>>>> encryption, my question now is " is it possible to start a session >>>>>>> remotely and attach to it ? >>>>>>> Best regards, >>>>>>> Pierre >>>>>>> >>>>>>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users >>>>>>> >>>>>> > a ?crit : >>>>>>> >>>>>>> ???? On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>>>>>> ???? > Hello, >>>>>>> ???? > I've recently succeeded in having a server running xterm, >>>>>>> a proxy >>>>>>> ???? and a >>>>>>> ???? > machine connecting to the proxy. I used for this what is >>>> described >>>>>> in >>>>>>> ???? > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>>>>>> ???? Hosts. What I >>>>>>> ???? > want to do now is launching the pplication from the >>>>>>> client, so >>>>>>> ???? what I did >>>>>>> ???? > is: >>>>>>> ???? > {{{ >>>>>>> ???? > xpra start :100 --bind-tcp=0.0.0.0:10100 >>>>>>> >>>>>>> ???? > }}} >>>>>>> ???? You said you wanted to launch from the client, but here you are >>>>>>> ???? launching a session in advance. >>>>>>> ???? Did you mean "connect from the client" instead? >>>>>>> >>>>>>> ???? > on the server. Then >>>>>>> ???? > {{{ >>>>>>> ???? > xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>>>> >>>>>>> ???? > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>>>>>> ???? --daemon=no >>>>>>> ???? > }}} >>>>>>> ???? The "allow" authentication module does not use any arguments. >>>>>>> ???? Certainly not the database file which is meant to be used by >>>>>>> the >>>>>> sqlite >>>>>>> ???? auth module. >>>>>>> >>>>>>> ???? > On the proxy and there is "foo bar nobody nobody ip" in >>>>>>> xpra-auth >>>>>>> ???? because I >>>>>>> ???? > didn't know how to indicate where the server is, >>>>>>> ???? Specifying remote hosts is documented for the sqlite backend >>>>>>> on the >>>>>>> ???? proxy wiki page: >>>>>>> ???? https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>>>>>> ???? ie: >>>>>>> ???? sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>>>>>> ???? tcp://1.1.1.1:10100/ >>>>>>> >>>>>>> ???? > the problem that I guess >>>>>>> ???? > here is that if you put --tcp-auth=allow the file >>>>>>> xpra-auth is >>>>>> ignored >>>>>>> ???? > because when I go to the client: >>>>>>> ???? > {{{ >>>>>>> ???? > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 >>>>>>> xterm >>>>>>> ???? > }}} >>>>>>> ???? FYI: tcp-auth here would apply to the session you end up >>>>>>> starting. >>>>>>> ???? That's usually a bad idea for anything but testing. >>>>>>> ???? And in this case, it is very unlikely to be needed since you >>>>>>> will >>>> be >>>>>>> ???? connected to the session when you start it anyway. >>>>>>> >>>>>>> ???? > I have the following error: >>>>>>> ???? > {{{ >>>>>>> ???? > 2018-07-31 13:50:22,161 Error: authentication failed: >>>>>>> ???? > 2018-07-31 13:50:22,161? server requested 'xor' digest, >>>>>>> cowardly >>>>>>> ???? refusing >>>>>>> ???? > to use it without encryption >>>>>>> ???? > }}} >>>>>>> ???? xpra will refuse to send password unencrypted over the network. >>>>>>> >>>>>>> ???? > What can I do ? >>>>>>> ???? Like it says, use encryption. >>>>>>> ???? https://xpra.org/trac/wiki/Encryption >>>>>>> >>>>>>> ???? Cheers, >>>>>>> ???? Antoine >>>>>>> >>>>>>> ???? > Thank you, >>>>>>> ???? > Pierre >>>>>>> ???? > _______________________________________________ >>>>>>> ???? > shifter-users mailing list >>>>>>> ???? > shifter-users at lists.devloop.org.uk >>>>>>> ???? >>>>>>> ???? > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>>> ???? > >>>>>>> >>>>>>> ???? _______________________________________________ >>>>>>> ???? shifter-users mailing list >>>>>>> ???? shifter-users at lists.devloop.org.uk >>>>>>> ???? >>>>>>> ???? http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>>> >>>>>> >>>>> _______________________________________________ >>>>> shifter-users mailing list >>>>> shifter-users at lists.devloop.org.uk >>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From pierre.wulles at gmail.com Tue Aug 7 13:59:20 2018 From: pierre.wulles at gmail.com (pwulles) Date: Tue, 7 Aug 2018 14:59:20 +0200 Subject: [winswitch] server requested 'xor' digest, cowardly... In-Reply-To: References: <770fa4c4-6986-40b3-abed-320555704684@nagafix.co.uk> <7188dde7-e3dc-6796-7929-843f48c9b6c5@nagafix.co.uk> <3f031ee6-5fa0-4e1b-4ef2-f2ef4731f765@nagafix.co.uk> <17e21fe0-61dc-ca09-a547-f2ed65776fc4@gmail.com> Message-ID: <8cb2221e-63e4-4301-3011-dbb0997b14a1@gmail.com> Hello, Thanks for your fast answer, Os version is Centos 7.5, I installed xpra with "sudo yum install xpra" and before I added the winswitch-beta.repo: in /etc/yum.repos.d/ with curl -O, content of the file: {{{ [winswitch] name=Winswitch $releasever - $basearch enabled=1 metadata_expire=1d gpgcheck=1 gpgkey=http://winswitch.org/gpg.asc baseurl=http://winswitch.org/dists/CentOS/$releasever/$basearch/ [winswitch-beta] name=Winswitch Beta $releasever - $basearch enabled=1 metadata_expire=1d gpgcheck=1 gpgkey=http://winswitch.org/gpg.asc baseurl=http://winswitch.org/beta/CentOS/$releasever/$basearch/ skip_if_unavailable = 1 }}} I tried: {{{ sudo yum install pygtk2 }}} but it says: {{{ Package pygtk2-2.24.0-9.el7.x86_64 already installed and latest version Nothing to do }}} So it seems to be installed. Cheers, Pierre On 07/08/2018 14:32, Antoine Martin via shifter-users wrote: > On 07/08/18 14:25, pwulles via shifter-users wrote: >> Hello, >> >> Well I've tried to install the latest version, so i'm now runnning with >> xpra v2.4-r20056 but I have now a new bug when executing: >> >> xpra attach ssl://foo:bar at proxyhost/ --start=xterm >> >> xpra main error: > (..) >> ImportError: When using gi.repository you must not import static modules >> like "gobject". Please change all occurrences of "import gobject" to >> "from gi.repository import GObject". >> >> What can I do ? > Judging from the stacktrace line numbers, you don't have pygtk > installed, which should be impossible if you have installed the packages > properly. > Without knowing more about your distro, version, installation, > environment, etc. It's difficult to tell you more. > > Cheers, > Antoine > > >> Pierre >> >> >> On 06/08/2018 17:20, Antoine Martin via shifter-users wrote: >>> On 06/08/18 16:34, Pierre Wulles via shifter-users wrote: >>>> Hello, >>>> Well this is good news! I'm happy you added it in the last version, >>>> as soon >>>> as I've received your email I've upgraded (xpra v2.4-r20042) >>> This r200042 build is too old, the feature you want was added in: >>> http://xpra.org/trac/changeset/20046 >>> >>>> and tried what >>>> you said. But I have now a major error when starting xpra: >>> (..) >>>> Is is because of the new version? Did I upgraded it bad? >>> That's fixed: >>> http://xpra.org/trac/changeset/20048 >>>> ? It was working well before. >>> Wait for a newer beta build, or patch your installation with the >>> changeset above. >>> >>> Cheers, >>> Antoine >>> >>>> Thank you, >>>> Pierre >>>> >>>> Le lun. 6 ao?t 2018 ? 15:03, Antoine Martin via shifter-users < >>>> shifter-users at lists.devloop.org.uk> a ?crit : >>>> >>>>> On 06/08/18 11:29, Pierre Wulles via shifter-users wrote: >>>>>> Hello, >>>>>>> And when asking questions, make sure to include what commands you are >>>>>> using, what you have tried, the log output, etc. >>>>>> The thing is that I don't know what command I am supposed to use! >>>>>> What I >>>>>> want is to start a session remotely, let assume that I want to start a >>>>>> graphical software remotely but I don't know which one, then what >>>>>> should >>>>> I >>>>>> type on server/proxy/client to do so ? >>>>>> I've succeeded to start a session like this: >>>>>> {{{ >>>>>> xpra start :100 --bind-tcp=0.0.0.0:10100 --start=xterm #on server >>>>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>>>> xpra attach tcp://foo:bar@$PROXYHOST:14501/ #on client >>>>>> }}} >>>>>> But I need to say on the first command "xterm", what I want is >>>>>> something >>>>>> like: >>>>>> {{{ >>>>>> xpra start? :100 --bind-tcp=0.0.0.0:10100 --start? #on server >>>>>> xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>>> --tcp-auth=sqlite,filename=./xpra-auth.sdb --socket-dir=/tmp #on proxy >>>>>> xpra start tcp://foo:bar@$PROXYHOST:14501/ --start=xterm #on client >>>>>> }}} >>>>>> WIth this the client can choose what software he wants to start. >>>>> You can already start new sessions via the proxy server with: >>>>> xpra start ssl://foo:bar at proxyhost:14501/ --start=whatever >>>>> With one important limitation: the sessions will be started on the same >>>>> host where the proxy is running, the proxy just executes an "xpra >>>>> start" >>>>> for you. >>>>> Regarding the proxy authentication configuration, since the session >>>>> will >>>>> be a local session it will need an account to run: >>>>> * if using "sys" auth, "foo" must be a valid user account on proxyhost >>>>> * if using "sqlite" auth, you must configure the mapping to user >>>>> accounts (uid, gid) yourself when creating the authentication database >>>>> >>>>> Until now, it wasn't possible for the client request commands to be >>>>> executed on the server after the connection is established (it was only >>>>> possible manually through the system tray menu: Server -> Run Command) >>>>> This feature has now been added for "attach" in xpra 2.4: >>>>> http://xpra.org/trac/ticket/1931 >>>>> So now you can do: >>>>> xpra attach --start=xterm >>>>> Or for a remote host: >>>>> xpra attach ssl://foo:bar at proxyhost/ --start=xterm >>>>> This will work for your use-case as long as the backend session is >>>>> started in advance, and you will need to populate the sqlite >>>>> database to >>>>> point to it as before. >>>>> >>>>> If you want to use --exit-with-children in this way, you still can, >>>>> here's a hackish solution which you can adapt: >>>>> xpra start --start-new-commands=yes --start-child="sleep 9999999" >>>>> --exit-with-children >>>>> xpra attach --start-child="xterm" --start="killall sleep" >>>>> >>>>> Allowing the proxy server to start sessions on remote servers (via ssh >>>>> or through a second proxy server) would be possible, but this would be >>>>> much more difficult to implement properly. This should probably tie in >>>>> with load balancing and session accounting features. >>>>> Feel free to create a ticket for it. >>>>> >>>>> Cheers, >>>>> Antoine >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>> Thank you, I hope it's clear enough. >>>>>> Pierre >>>>>> >>>>>> Le sam. 4 ao?t 2018 ? 17:33, Antoine Martin a >>>>>> ?crit : >>>>>> >>>>>>> Please always use the mailing list. >>>>>>> And when asking questions, make sure to include what commands you are >>>>>>> using, what you have tried, the log output, etc. >>>>>>> http://xpra.org/trac/wiki/ReportingBugs >>>>>>> >>>>>>> Antoine >>>>>>> >>>>>>> On 04/08/18 15:41, Pierre Wulles wrote: >>>>>>>> Hello, >>>>>>>> Thank you for your answer! I finally succeded in connecting with >>>>>>>> encryption, my question now is " is it possible to start a session >>>>>>>> remotely and attach to it ? >>>>>>>> Best regards, >>>>>>>> Pierre >>>>>>>> >>>>>>>> Le sam. 4 ao?t 2018 15:30, Antoine Martin via shifter-users >>>>>>>> >>>>>>> > a ?crit : >>>>>>>> >>>>>>>> ???? On 31/07/18 14:08, Pierre Wulles via shifter-users wrote: >>>>>>>> ???? > Hello, >>>>>>>> ???? > I've recently succeeded in having a server running xterm, >>>>>>>> a proxy >>>>>>>> ???? and a >>>>>>>> ???? > machine connecting to the proxy. I used for this what is >>>>> described >>>>>>> in >>>>>>>> ???? > https://xpra.org/trac/wiki/ProxyServer at the section Remote >>>>>>>> ???? Hosts. What I >>>>>>>> ???? > want to do now is launching the pplication from the >>>>>>>> client, so >>>>>>>> ???? what I did >>>>>>>> ???? > is: >>>>>>>> ???? > {{{ >>>>>>>> ???? > xpra start :100 --bind-tcp=0.0.0.0:10100 >>>>>>>> >>>>>>>> ???? > }}} >>>>>>>> ???? You said you wanted to launch from the client, but here you are >>>>>>>> ???? launching a session in advance. >>>>>>>> ???? Did you mean "connect from the client" instead? >>>>>>>> >>>>>>>> ???? > on the server. Then >>>>>>>> ???? > {{{ >>>>>>>> ???? > xpra proxy :100 --bind-tcp=0.0.0.0:14501 >>>>>>>> >>>>>>>> ???? > --tcp-auth=allow,filename=./xpra-auth.sdb --socket-dir=/tmp >>>>>>>> ???? --daemon=no >>>>>>>> ???? > }}} >>>>>>>> ???? The "allow" authentication module does not use any arguments. >>>>>>>> ???? Certainly not the database file which is meant to be used by >>>>>>>> the >>>>>>> sqlite >>>>>>>> ???? auth module. >>>>>>>> >>>>>>>> ???? > On the proxy and there is "foo bar nobody nobody ip" in >>>>>>>> xpra-auth >>>>>>>> ???? because I >>>>>>>> ???? > didn't know how to indicate where the server is, >>>>>>>> ???? Specifying remote hosts is documented for the sqlite backend >>>>>>>> on the >>>>>>>> ???? proxy wiki page: >>>>>>>> ???? https://xpra.org/trac/wiki/ProxyServer#RemoteHosts >>>>>>>> ???? ie: >>>>>>>> ???? sqlite_auth.py ./auth.sdb add foo bar nobody nobody >>>>>>>> ???? tcp://1.1.1.1:10100/ >>>>>>>> >>>>>>>> ???? > the problem that I guess >>>>>>>> ???? > here is that if you put --tcp-auth=allow the file >>>>>>>> xpra-auth is >>>>>>> ignored >>>>>>>> ???? > because when I go to the client: >>>>>>>> ???? > {{{ >>>>>>>> ???? > xpra start --tcp-auth=allow tcp://vml-xprabetatest/14501 >>>>>>>> xterm >>>>>>>> ???? > }}} >>>>>>>> ???? FYI: tcp-auth here would apply to the session you end up >>>>>>>> starting. >>>>>>>> ???? That's usually a bad idea for anything but testing. >>>>>>>> ???? And in this case, it is very unlikely to be needed since you >>>>>>>> will >>>>> be >>>>>>>> ???? connected to the session when you start it anyway. >>>>>>>> >>>>>>>> ???? > I have the following error: >>>>>>>> ???? > {{{ >>>>>>>> ???? > 2018-07-31 13:50:22,161 Error: authentication failed: >>>>>>>> ???? > 2018-07-31 13:50:22,161? server requested 'xor' digest, >>>>>>>> cowardly >>>>>>>> ???? refusing >>>>>>>> ???? > to use it without encryption >>>>>>>> ???? > }}} >>>>>>>> ???? xpra will refuse to send password unencrypted over the network. >>>>>>>> >>>>>>>> ???? > What can I do ? >>>>>>>> ???? Like it says, use encryption. >>>>>>>> ???? https://xpra.org/trac/wiki/Encryption >>>>>>>> >>>>>>>> ???? Cheers, >>>>>>>> ???? Antoine >>>>>>>> >>>>>>>> ???? > Thank you, >>>>>>>> ???? > Pierre >>>>>>>> ???? > _______________________________________________ >>>>>>>> ???? > shifter-users mailing list >>>>>>>> ???? > shifter-users at lists.devloop.org.uk >>>>>>>> ???? >>>>>>>> ???? > http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>>>> ???? > >>>>>>>> >>>>>>>> ???? _______________________________________________ >>>>>>>> ???? shifter-users mailing list >>>>>>>> ???? shifter-users at lists.devloop.org.uk >>>>>>>> ???? >>>>>>>> ???? http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>>>> >>>>>> _______________________________________________ >>>>>> shifter-users mailing list >>>>>> shifter-users at lists.devloop.org.uk >>>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>>> >>>>> _______________________________________________ >>>>> shifter-users mailing list >>>>> shifter-users at lists.devloop.org.uk >>>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>>> >>>> _______________________________________________ >>>> shifter-users mailing list >>>> shifter-users at lists.devloop.org.uk >>>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >>>> >>> _______________________________________________ >>> shifter-users mailing list >>> shifter-users at lists.devloop.org.uk >>> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From Eric.Lemings at ngc.com Thu Aug 9 22:58:02 2018 From: Eric.Lemings at ngc.com (Lemings, Brad [US] (MS)) Date: Thu, 9 Aug 2018 21:58:02 +0000 Subject: [winswitch] Xpra "open sessions" Message-ID: <38b89f6173d84deeb4b5e2993118d519@XCGC3029.northgrum.com> Greetings all, I'm using Xpra 1.x and the man pages reference in passing "open sessions" which I assume allow multiple user accounts to connect to the same Xpra server. Where can I find more details regarding Xpra "open sessions"? Thanks, Eric. From antoine at nagafix.co.uk Fri Aug 10 06:55:36 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 10 Aug 2018 07:55:36 +0200 Subject: [winswitch] Xpra "open sessions" In-Reply-To: <38b89f6173d84deeb4b5e2993118d519@XCGC3029.northgrum.com> References: <38b89f6173d84deeb4b5e2993118d519@XCGC3029.northgrum.com> Message-ID: <784fb990-4fa6-3a05-65ee-c193ea507a40@nagafix.co.uk> On 09/08/18 23:58, Lemings, Brad [US] (MS) via shifter-users wrote: > Greetings all, > > I'm using Xpra 1.x and the man pages reference in passing "open sessions" The paragraph you are referring to must be this one: "When using the socket-dir option, it is generally necessary to specify socket-dir or socket-dirs on all following commands, for xpra to work with the open sessions." It just means that if you choose to place your sockets in a non-standard location when starting a server (ie: --socket-dir=/tmp) then you will need to specify the same socket-dir option to interact with those already "open sessions" with all subsequent commands ("xpra attach", "xpra list", etc) > which I assume allow multiple user accounts to connect to the same Xpra server. Multiple user accounts can also access the same session via TCP. For unix domain sockets, you can add your users to the "xpra" group and a socket will be created in /run/xpra. That alone is not sufficient: you also need to change the socket permissions to allow other members of the xpra group to access this socket. (see mmap-group and socket-permissions) You may or may not want to add authentication to that socket, see the "auth" switch. Finally, make sure to enable sharing if you want your users to access the same session concurrently. > Where can I find more details regarding Xpra "open sessions"? Open sessions is synonymous with "active sessions" here. That's all there is to it. "xpra list" will show you the list. The sharing support and options are much improved in version 2.x Cheers, Antoine > > Thanks, > Eric. > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From Eric.Lemings at ngc.com Fri Aug 10 17:49:50 2018 From: Eric.Lemings at ngc.com (Lemings, Brad [US] (MS)) Date: Fri, 10 Aug 2018 16:49:50 +0000 Subject: [winswitch] EXT :Re: Xpra "open sessions" In-Reply-To: <784fb990-4fa6-3a05-65ee-c193ea507a40@nagafix.co.uk> References: <38b89f6173d84deeb4b5e2993118d519@XCGC3029.northgrum.com> <784fb990-4fa6-3a05-65ee-c193ea507a40@nagafix.co.uk> Message-ID: Antoine, Thanks for the hasty response! One problem that I'm running into is that no matter what command-line options or configuration files that I use or for 'xpra start', it always seems to look in or try write to the ~/.xpra directory. How do I force Xpra to always use an explicit directory path instead of ~/.xpra? On a side note, I'm stuck with RHEL 6 thus the reason for using Xpra 1.x. If anyone has managed to port Xpra 2 to CentOS/RHEL 6 platforms, I'd like to know about it! Thanks, Eric. -----Original Message----- From: Antoine Martin [mailto:antoine at nagafix.co.uk] Sent: Thursday, August 09, 2018 11:56 PM To: shifter-users at lists.devloop.org.uk; Lemings, Brad [US] (MS) Subject: EXT :Re: [winswitch] Xpra "open sessions" On 09/08/18 23:58, Lemings, Brad [US] (MS) via shifter-users wrote: > Greetings all, > > I'm using Xpra 1.x and the man pages reference in passing "open sessions" The paragraph you are referring to must be this one: "When using the socket-dir option, it is generally necessary to specify socket-dir or socket-dirs on all following commands, for xpra to work with the open sessions." It just means that if you choose to place your sockets in a non-standard location when starting a server (ie: --socket-dir=/tmp) then you will need to specify the same socket-dir option to interact with those already "open sessions" with all subsequent commands ("xpra attach", "xpra list", etc) > which I assume allow multiple user accounts to connect to the same Xpra server. Multiple user accounts can also access the same session via TCP. For unix domain sockets, you can add your users to the "xpra" group and a socket will be created in /run/xpra. That alone is not sufficient: you also need to change the socket permissions to allow other members of the xpra group to access this socket. (see mmap-group and socket-permissions) You may or may not want to add authentication to that socket, see the "auth" switch. Finally, make sure to enable sharing if you want your users to access the same session concurrently. > Where can I find more details regarding Xpra "open sessions"? Open sessions is synonymous with "active sessions" here. That's all there is to it. "xpra list" will show you the list. The sharing support and options are much improved in version 2.x Cheers, Antoine > > Thanks, > Eric. > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Sat Aug 11 09:27:58 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 11 Aug 2018 15:27:58 +0700 Subject: [winswitch] EXT :Re: Xpra "open sessions" In-Reply-To: References: <38b89f6173d84deeb4b5e2993118d519@XCGC3029.northgrum.com> <784fb990-4fa6-3a05-65ee-c193ea507a40@nagafix.co.uk> Message-ID: <611e7d65-e389-2467-2e37-757f825d3db3@nagafix.co.uk> On 10/08/18 23:49, Lemings, Brad [US] (MS) wrote: > Antoine, > > Thanks for the hasty response! > > One problem that I'm running into is that no matter what command-line options or configuration files that I use or for 'xpra start', it always seems to look in or try write to the ~/.xpra directory. How do I force Xpra to always use an explicit directory path instead of ~/.xpra? for v1.x and using /tmp instead of ~/.xpra, try: XPRA_SOCKET_DIRS=/tmp XPRA_LOG_DIRS=/tmp XPRA_USER_CONF_DIRS=/tmp xpra.. (untested) FYI: version 2.4 no longer writes anything in ~/.xpra It still reads configuration files from there if there are any, for backwards compatibility. For more details see: https://xpra.org/trac/ticket/1723 > On a side note, I'm stuck with RHEL 6 thus the reason for using Xpra 1.x. If anyone has managed to port Xpra 2 to CentOS/RHEL 6 platforms, I'd like to know about it! IMO, that would be too much work to maintain. A lot of backwards compatibility code has been removed in Xpra 2.x (ie: Python 2.6) The same thing will happen with 3.0 for Python 2.x Cheers, Antoine > > Thanks, > Eric. > > -----Original Message----- > From: Antoine Martin [mailto:antoine at nagafix.co.uk] > Sent: Thursday, August 09, 2018 11:56 PM > To: shifter-users at lists.devloop.org.uk; Lemings, Brad [US] (MS) > Subject: EXT :Re: [winswitch] Xpra "open sessions" > > On 09/08/18 23:58, Lemings, Brad [US] (MS) via shifter-users wrote: >> Greetings all, >> >> I'm using Xpra 1.x and the man pages reference in passing "open sessions" > The paragraph you are referring to must be this one: > "When using the socket-dir option, it is generally necessary to specify socket-dir or socket-dirs on all following commands, for xpra to work with the open sessions." > > It just means that if you choose to place your sockets in a non-standard location when starting a server (ie: --socket-dir=/tmp) then you will need to specify the same socket-dir option to interact with those already "open sessions" with all subsequent commands ("xpra attach", "xpra list", etc) > >> which I assume allow multiple user accounts to connect to the same Xpra server. > Multiple user accounts can also access the same session via TCP. > For unix domain sockets, you can add your users to the "xpra" group and a socket will be created in /run/xpra. > That alone is not sufficient: you also need to change the socket permissions to allow other members of the xpra group to access this socket. (see mmap-group and socket-permissions) You may or may not want to add authentication to that socket, see the "auth" switch. > > Finally, make sure to enable sharing if you want your users to access the same session concurrently. > >> Where can I find more details regarding Xpra "open sessions"? > Open sessions is synonymous with "active sessions" here. > That's all there is to it. "xpra list" will show you the list. > > The sharing support and options are much improved in version 2.x > > Cheers, > Antoine > > >> >> Thanks, >> Eric. >> >> _______________________________________________ >> shifter-users mailing list >> shifter-users at lists.devloop.org.uk >> http://lists.devloop.org.uk/mailman/listinfo/shifter-users >> > From antoine at nagafix.co.uk Sat Aug 18 17:58:19 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 18 Aug 2018 23:58:19 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.3.3 : many fixes, none critical Message-ID: <47f47c30-3def-309d-9356-8d95158f6766@nagafix.co.uk> Hi, This release was delayed repeatedly and so the number of fixes is rather large. This delay was first caused by some hardware failures, then by the switch to Python 3.7 for the MS Windows and MacOS Python 3 builds, which required quite a few tweaks and fixes - many of which were in other upstream projects. Apart from those build-system related issues, the most important fixes are in the HTML5 client's key handling, Python3 compatibility fixes, the network layer (bandwidth-limit, congestion detection, etc) and SSL / proxy server issues. There is no urgency to update, but because of the large number of fixes, updating sooner rather than later is recommended. Release notes: * fix value shown in frame extents warning * fix HTML5 relative URLs for window control icons * fix HTML5 pointer events missing modifier keys * fix parsing errors when no display is specified * fix URL parsing with Python 3 * fix tray setup errors on early client exit * fix putty plink PATH lookup issue * fix python3 compatibility for printer forwarding script * fix python3 alert box on MS Windows * fix python3 packaging on MS Windows * fix python3 client rendering of transparency with opengl disabled * fix file descriptor warnings on process exit with MS Windows builds * fix MS Windows monitor API overflow on 64-bit systems * fix compilation error with latest MSYS2 installations * fix desktop servers exit code * fix network congestion calculations when records expire * fix bandwidth warnings caused by slow client picture decoding * fix xpra info race condition error during cleanup * fix clipboard warnings: don't enable it unless the client requests it * fix spurious stacktraces caused by focus events on OR windows * fix painting of spinners with desktop-scaling and non-opengl backends * fix 'terminate server when command exits' from html5 client * fix SSL socket timeouts in proxy server * fix errors starting proxy instances if the user's home does not exist * fix ssh start remote command line compatibility mode * fix command line backwards compatibility * fix handling of tray geometry and keyboard detection failures * fix bandwidth-limit changes from the system tray menu * fix system version warnings on MacOS * force GTK3 Posix clients to use X11 backend (native Wayland crashes) * support cx_Freeze 5.x on MS Windows * don't require local user accounts with pam logins * drop invalid client connections without showing errors (desktop mode) * support building with Python 3.7 * disable webcam forwarding with MS Windows client (broken upstream) * add missing RPM dependencies for running unit tests * prevent Python Pillow debug log spam * don't show spurious import errors during printing subsystem cleanup * show another possible reason for connection failures * make remote ssh command easier to parse * abort tests if build fails * use free colour profiles in all icon files * add missing man page entry for 'forward-xdg-open' * add missing files to manifest * man page typos The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From anto.trande at gmail.com Sun Aug 19 15:10:04 2018 From: anto.trande at gmail.com (Antonio Trande) Date: Sun, 19 Aug 2018 16:10:04 +0200 Subject: [winswitch] [ANNOUNCE] Xpra 2.3.3 : many fixes, none critical In-Reply-To: <47f47c30-3def-309d-9356-8d95158f6766@nagafix.co.uk> References: <47f47c30-3def-309d-9356-8d95158f6766@nagafix.co.uk> Message-ID: <0765fdf4-8793-6094-633b-8c3661c109e7@fedoraproject.org> There is not any xpra-2.3.3 source archive at https://xpra.org/src/ On 18/08/2018 18:58, Antoine Martin via shifter-users wrote: > Hi, > > This release was delayed repeatedly and so the number of fixes is rather > large. > This delay was first caused by some hardware failures, then by the > switch to Python 3.7 for the MS Windows and MacOS Python 3 builds, which > required quite a few tweaks and fixes - many of which were in other > upstream projects. > > Apart from those build-system related issues, the most important fixes > are in the HTML5 client's key handling, Python3 compatibility fixes, the > network layer (bandwidth-limit, congestion detection, etc) and SSL / > proxy server issues. > > There is no urgency to update, but because of the large number of fixes, > updating sooner rather than later is recommended. > > > Release notes: > * fix value shown in frame extents warning > * fix HTML5 relative URLs for window control icons > * fix HTML5 pointer events missing modifier keys > * fix parsing errors when no display is specified > * fix URL parsing with Python 3 > * fix tray setup errors on early client exit > * fix putty plink PATH lookup issue > * fix python3 compatibility for printer forwarding script > * fix python3 alert box on MS Windows > * fix python3 packaging on MS Windows > * fix python3 client rendering of transparency with opengl disabled > * fix file descriptor warnings on process exit with MS Windows builds > * fix MS Windows monitor API overflow on 64-bit systems > * fix compilation error with latest MSYS2 installations > * fix desktop servers exit code > * fix network congestion calculations when records expire > * fix bandwidth warnings caused by slow client picture decoding > * fix xpra info race condition error during cleanup > * fix clipboard warnings: don't enable it unless the client requests it > * fix spurious stacktraces caused by focus events on OR windows > * fix painting of spinners with desktop-scaling and non-opengl backends > * fix 'terminate server when command exits' from html5 client > * fix SSL socket timeouts in proxy server > * fix errors starting proxy instances if the user's home does not exist > * fix ssh start remote command line compatibility mode > * fix command line backwards compatibility > * fix handling of tray geometry and keyboard detection failures > * fix bandwidth-limit changes from the system tray menu > * fix system version warnings on MacOS > * force GTK3 Posix clients to use X11 backend (native Wayland crashes) > * support cx_Freeze 5.x on MS Windows > * don't require local user accounts with pam logins > * drop invalid client connections without showing errors (desktop mode) > * support building with Python 3.7 > * disable webcam forwarding with MS Windows client (broken upstream) > * add missing RPM dependencies for running unit tests > * prevent Python Pillow debug log spam > * don't show spurious import errors during printing subsystem cleanup > * show another possible reason for connection failures > * make remote ssh command easier to parse > * abort tests if build fails > * use free colour profiles in all icon files > * add missing man page entry for 'forward-xdg-open' > * add missing files to manifest > * man page typos > > The source: > https://xpra.org/src/ > Downloads: > https://xpra.org/trac/wiki/Download > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > -- --- Antonio Trande Fedora Project mailto 'sagitter at fedoraproject dot org' GPG key: 0x5E212EE1D35568BE GPG key server: https://keys.fedoraproject.org/ From antoine at nagafix.co.uk Sun Aug 19 18:26:33 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 20 Aug 2018 00:26:33 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.3.3 : many fixes, none critical In-Reply-To: <0765fdf4-8793-6094-633b-8c3661c109e7@fedoraproject.org> References: <47f47c30-3def-309d-9356-8d95158f6766@nagafix.co.uk> <0765fdf4-8793-6094-633b-8c3661c109e7@fedoraproject.org> Message-ID: <687635ba-3172-6a69-f033-dee0eedc52cc@nagafix.co.uk> On 19/08/18 21:10, Antonio Trande via shifter-users wrote: > There is not any xpra-2.3.3 source archive at https://xpra.org/src/ There is now. Antoine From Eric.Lemings at ngc.com Tue Aug 28 18:57:16 2018 From: Eric.Lemings at ngc.com (Lemings, Brad [US] (MS)) Date: Tue, 28 Aug 2018 17:57:16 +0000 Subject: [winswitch] Blacked-out menus in Xpra 1.x Message-ID: Greetings, I have noticed with old Motif applications that menus will sometimes be completely blacked out when viewed through a 'xpra attach' session using Xpra version 1.x. Does anybody have some ideas what might cause that and how to fix it? Thanks, Eric. From bsferrazza at avnera.com Tue Aug 28 21:23:41 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Tue, 28 Aug 2018 13:23:41 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: Hi. I'm including my previous correspondence below, as it will at least offer some history about my setup and prior issues. I stopped using Xpra a few months ago due to numerous bugs that made it unusable (this is using a Linux server and Windows client). 1. windows get stuck with on-top focus 2. disappearing mouse cursor when using X11-only no-toolkit apps that use inverted black mouse pointer after clicking on something 3. some windows don't show window bar until resized (e.g. gvim always gets placed in upper-left without window bar) 4. dialog box black bars (appears to be trying to add scrollbars?). 5. windows are all blank (white) when returning into work after several hours (requires restarting client) 6. flickering clipboard icon in systray I'm inclined to give Xpra another chance, with the newer versions, and can hopefully provide actual debugging log information for these bugs to be fixed (if they haven't already). But I'm now not even able to connect to the server from the client using version 2.3.3. It reports Connection Lost immediately. I can ssh into the same host without issue. And have made sure that the shell rc file no longer outputs anything, which was the source of my issue a few months ago. I have included the relevant sections of the server log and client log below. *Server Log:* 2018-08-28 18:44:12,058 add_listen_socket(unix-domain, ) info=/home/bsferrazza/.local/run/xpra/l-server-13-100 2018-08-28 18:44:12,058 add_listen_socket(unix-domain, ) info=/home/bsferrazza/.xpra/l-server-13-100 2018-08-28 18:44:12,059 reset_server_timeout(True) server_idle_timeout=0, server_idle_timer=None 2018-08-28 18:44:12,059 add_process(, xterm, ['xterm'], True, False) pid=17703 2018-08-28 18:44:12,059 xpra is ready. 2018-08-28 18:44:12,059 pid(['xterm'])=17703 2018-08-28 18:44:12,060 org.xpra.Server.Event(ready, []) 2018-08-28 18:44:12,060 VideoHelper.init() 2018-08-28 18:44:12,061 server-event: ('ready',) 2018-08-28 18:44:12,061 VideoHelper.init() initialized=False 2018-08-28 18:44:12,061 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'xterm', 'process': , 'pid': 17703, 'dead': False, 'ignore': True, 'callback': None, 'command': ['xterm'], 'forget': False})] 2018-08-28 18:44:12,061 init_video_encoders_options() 2018-08-28 18:44:12,062 will try video encoders: x264, vpx 2018-08-28 18:44:12,062 guess_session_name() commands=['xterm'] 2018-08-28 18:44:12,062 modules for x264: enc_x264 2018-08-28 18:44:12,062 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'xterm', 'process': , 'pid': 17703, 'dead': False, 'ignore': True, 'callback': None, 'command': ['xterm'], 'forget': False})] 2018-08-28 18:44:12,063 init_video_encoder_option(enc_x264) 2018-08-28 18:44:12,063 check() alive=[], quit callback=> 2018-08-28 18:44:12,063 module= 2018-08-28 18:44:12,064 enc_x264.init_module() 2018-08-28 18:44:12,064 x264 encodings=h264 2018-08-28 18:44:12,064 x264 input colorspaces for h264: BGRX, YUV422P, YUV420P, BGRA, YUV444P 2018-08-28 18:44:12,064 modules for vpx: enc_vpx 2018-08-28 18:44:12,064 init_video_encoder_option(enc_vpx) 2018-08-28 18:44:12,065 module= 2018-08-28 18:44:12,065 vpx_codec_version_str()=v1.7.0 2018-08-28 18:44:12,065 vpx.encoder.init_module() info={'vp9.max-size': (8192, 4096), 'generation': 3, 'vp8.colorspaces': ['YUV420P'], 'version': 'v1.7.0', 'abi_version': 14, 'encodings': ['vp8', 'vp9'], 'vp8.max-size': (8192, 4096), 'build_config': '--prefix=/home/tools --enable-shared --disable-static', 'vp9.colorspaces': ['YUV420P', 'YUV444P']} 2018-08-28 18:44:12,065 supported codecs: ['vp8', 'vp9'] 2018-08-28 18:44:12,065 supported colorspaces: {'vp9': ['YUV420P', 'YUV444P'], 'vp8': ['YUV420P']} 2018-08-28 18:44:12,065 vpx encodings=vp8, vp9 2018-08-28 18:44:12,065 vpx input colorspaces for vp8: YUV420P 2018-08-28 18:44:12,066 vpx input colorspaces for vp9: YUV420P, YUV444P 2018-08-28 18:44:12,066 found 3 video encoders: h264, vp9, vp8 2018-08-28 18:44:12,066 init_csc_options() 2018-08-28 18:44:12,066 will try csc modules: 2018-08-28 18:44:12,066 csc specs: 2018-08-28 18:44:12,066 init_video_decoders_options() 2018-08-28 18:44:12,066 will try video decoders: 2018-08-28 18:44:12,066 found 0 video decoders: 2018-08-28 18:44:12,067 VideoHelper.init() done 2018-08-28 18:44:12,067 init_encodings() adding video encodings: ('h264', 'vp9', 'vp8') 2018-08-28 18:44:12,067 found lossless mode for encoding h264 with video_spec(x264) and colorspace YUV444P 2018-08-28 18:44:12,067 allowed encodings=['h264', 'vp9', 'vp8', 'mpeg4', 'mpeg4+mp4', 'h264+mp4', 'vp8+webm', 'vp9+webm', 'png', 'png/P', 'png/L', 'webp', 'rgb', 'rgb24', 'rgb32', 'jpeg', 'h265', 'jpeg2000'], encodings=['rgb', 'h264', 'vp9', 'vp8', 'png', 'png/L', 'png/P', 'jpeg', 'webp'], core encodings=['rgb24', 'rgb32', 'h264', 'vp9', 'vp8', 'png', 'png/L', 'png/P', 'jpeg', 'webp'], lossless encodings=['rgb24', 'rgb32', 'png', 'png/L', 'png/P', 'webp'] 2018-08-28 18:44:12,067 251.9GB of system memory 2018-08-28 18:44:12,068 threaded_init() end 2018-08-28 18:44:12,080 x_event_filter event=('xpra-create-event', None)/CreateNotify window=0x299 2018-08-28 18:44:12,082 parse_event(..)= 2018-08-28 18:44:12,082 x_event_filter event=('xpra-create-event', None)/CreateNotify took 1.4ms 2018-08-28 18:44:12,082 x_event_filter event=(None, 'child-configure-request-event')/ConfigureRequest window=0x299 2018-08-28 18:44:12,082 parse_event(..)= 2018-08-28 18:44:12,083 do_child_configure_request_event() value_mask=Width|Height, reconfigure on withdrawn window 2018-08-28 18:44:12,083 updated window geometry for window 0x60000d from (0, 0, 1, 1) to (0, 0, 484, 316) 2018-08-28 18:44:12,083 x_event_filter event=(None, 'child-configure-request-event')/ConfigureRequest took 1.2ms 2018-08-28 18:44:12,083 x_event_filter event=('xpra-configure-event', None)/ConfigureNotify window=0x299 2018-08-28 18:44:12,084 parse_event(..)= 2018-08-28 18:44:12,084 x_event_filter event=('xpra-configure-event', None)/ConfigureNotify took 0.4ms 2018-08-28 18:44:12,099 x_event_filter event=(None, 'child-map-request-event')/MapRequest window=0x299 2018-08-28 18:44:12,099 parse_event(..)= 2018-08-28 18:44:12,100 Found a potential client 2018-08-28 18:44:12,100 _manage_client() 2018-08-28 18:44:12,100 new window 0x60000d 2018-08-28 18:44:12,101 read_initial_X11_properties() window 2018-08-28 18:44:12,101 Window.read_initial_X11_properties() 2018-08-28 18:44:12,101 read _NET_WM_STATE=None 2018-08-28 18:44:12,101 updateprop(state, frozenset([])) previous value=None 2018-08-28 18:44:12,101 not sending notify(state) (setup done=False, managed=False) 2018-08-28 18:44:12,101 read_initial_X11_properties() core 2018-08-28 18:44:12,102 initial X11 properties: xid=0x60000d, depth=24 2018-08-28 18:44:12,102 updateprop(depth, 24) previous value=None 2018-08-28 18:44:12,102 not sending notify(depth) (setup done=False, managed=False) 2018-08-28 18:44:12,102 updateprop(xid, 6291469) previous value=None 2018-08-28 18:44:12,102 not sending notify(xid) (setup done=False, managed=False) 2018-08-28 18:44:12,102 updateprop(has-alpha, False) previous value=None 2018-08-28 18:44:12,102 not sending notify(has-alpha) (setup done=False, managed=False) 2018-08-28 18:44:12,102 updateprop(allowed-actions, ['_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE', '_NET_WM_ACTION_RESIZE', '_NET_WM_ACTION_FULLSCREEN', '_NET_WM_ACTION_MINIMIZE', '_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK', '_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT', '_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE', '_NET_WM_ACTION_BELOW']) previous value=None 2018-08-28 18:44:12,102 not sending notify(allowed-actions) (setup done=False, managed=False) 2018-08-28 18:44:12,102 displayHasXShape()=True 2018-08-28 18:44:12,103 read_shape for window 0x60000d: extents=((0, 0, 0, 484, 316), (0, 0, 0, 484, 316)) 2018-08-28 18:44:12,103 read_shape for window 0x60000d: none enabled 2018-08-28 18:44:12,103 updateprop(shape, {}) previous value=None 2018-08-28 18:44:12,103 not sending notify(shape) (setup done=False, managed=False) 2018-08-28 18:44:12,103 initial X11_properties: querying ['_NET_WM_PID', 'WM_CLIENT_MACHINE', 'WM_NAME', '_NET_WM_NAME', 'WM_PROTOCOLS', 'WM_CLASS', 'WM_WINDOW_ROLE', 'WM_TRANSIENT_FOR', '_NET_WM_WINDOW_TYPE', '_NET_WM_DESKTOP', '_NET_WM_FULLSCREEN_MONITORS', '_NET_WM_BYPASS_COMPOSITOR', '_NET_WM_STRUT', '_NET_WM_STRUT_PARTIAL', '_NET_WM_WINDOW_OPACITY', 'WM_HINTS', '_GTK_APP_MENU_OBJECT_PATH', '_GTK_APPLICATION_ID', '_GTK_UNIQUE_BUS_NAME', '_GTK_APPLICATION_OBJECT_PATH', '_GTK_APP_MENU_OBJECT_PATH', '_GTK_WINDOW_OBJECT_PATH', 'WM_HINTS', 'WM_NORMAL_HINTS', '_MOTIF_WM_HINTS', 'WM_ICON_NAME', '_NET_WM_ICON_NAME', '_NET_WM_ICON', '_NET_WM_STRUT', '_NET_WM_STRUT_PARTIAL'] 2018-08-28 18:44:12,103 _NET_WM_PID=17703 2018-08-28 18:44:12,104 updateprop(pid, 17703) previous value=None 2018-08-28 18:44:12,104 not sending notify(pid) (setup done=False, managed=False) 2018-08-28 18:44:12,104 WM_CLIENT_MACHINE=l-server-13 2018-08-28 18:44:12,104 updateprop(client-machine, l-server-13) previous value=None 2018-08-28 18:44:12,104 not sending notify(client-machine) (setup done=False, managed=False) 2018-08-28 18:44:12,105 _NET_WM_NAME=None 2018-08-28 18:44:12,105 WM_NAME=xterm 2018-08-28 18:44:12,105 updateprop(title, xterm) previous value=None 2018-08-28 18:44:12,105 not sending notify(title) (setup done=False, managed=False) 2018-08-28 18:44:12,105 wm_name changed 2018-08-28 18:44:12,105 WM_PROTOCOLS=['WM_DELETE_WINDOW'] 2018-08-28 18:44:12,105 updateprop(protocols, ['WM_DELETE_WINDOW']) previous value=None 2018-08-28 18:44:12,106 not sending notify(protocols) (setup done=False, managed=False) 2018-08-28 18:44:12,106 XGetClassHint(0x60000d) classhints: xterm, XTerm 2018-08-28 18:44:12,106 WM_CLASS=('xterm', 'XTerm') 2018-08-28 18:44:12,106 updateprop(class-instance, ('xterm', 'XTerm')) previous value=None 2018-08-28 18:44:12,106 not sending notify(class-instance) (setup done=False, managed=False) 2018-08-28 18:44:12,106 WM_WINDOW_ROLE=None 2018-08-28 18:44:12,106 updateprop(role, None) previous value=None 2018-08-28 18:44:12,106 not sending notify(role) (setup done=False, managed=False) 2018-08-28 18:44:12,107 WM_TRANSIENT_FOR=None 2018-08-28 18:44:12,107 updateprop(transient-for, None) previous value=None 2018-08-28 18:44:12,107 not sending notify(transient-for) (setup done=False, managed=False) 2018-08-28 18:44:12,107 _NET_WM_WINDOW_TYPE=None 2018-08-28 18:44:12,107 get(override-redirect, False) returning default value=False 2018-08-28 18:44:12,107 guessed window type=_NET_WM_WINDOW_TYPE_NORMAL 2018-08-28 18:44:12,108 updateprop(window-type, ['NORMAL']) previous value=None 2018-08-28 18:44:12,108 not sending notify(window-type) (setup done=False, managed=False) 2018-08-28 18:44:12,108 _NET_WM_DESKTOP=UNSET for window 0x60000d 2018-08-28 18:44:12,108 updateprop(workspace, 65535) previous value=None 2018-08-28 18:44:12,108 not sending notify(workspace) (setup done=False, managed=False) 2018-08-28 18:44:12,109 _NET_WM_FULLSCREEN_MONITORS=None 2018-08-28 18:44:12,109 updateprop(fullscreen-monitors, None) previous value=None 2018-08-28 18:44:12,109 not sending notify(fullscreen-monitors) (setup done=False, managed=False) 2018-08-28 18:44:12,109 _NET_WM_BYPASS_COMPOSITOR=0 2018-08-28 18:44:12,109 updateprop(bypass-compositor, 0) previous value=None 2018-08-28 18:44:12,109 not sending notify(bypass-compositor) (setup done=False, managed=False) 2018-08-28 18:44:12,109 _NET_WM_STRUT_PARTIAL=None 2018-08-28 18:44:12,110 _NET_WM_STRUT=None 2018-08-28 18:44:12,110 updateprop(strut, None) previous value=None 2018-08-28 18:44:12,110 not sending notify(strut) (setup done=False, managed=False) 2018-08-28 18:44:12,110 _NET_WM_WINDOW_OPACITY=-1 2018-08-28 18:44:12,110 updateprop(opacity, -1) previous value=None 2018-08-28 18:44:12,110 not sending notify(opacity) (setup done=False, managed=False) 2018-08-28 18:44:12,110 updateprop(group-leader, None) previous value=None 2018-08-28 18:44:12,110 not sending notify(group-leader) (setup done=False, managed=False) 2018-08-28 18:44:12,111 updateprop(attention-requested, False) previous value=None 2018-08-28 18:44:12,111 not sending notify(attention-requested) (setup done=False, managed=False) 2018-08-28 18:44:12,111 wm_hints.input = 1 2018-08-28 18:44:12,111 updateprop(can-focus, True) previous value=None 2018-08-28 18:44:12,111 not sending notify(can-focus) (setup done=False, managed=False) 2018-08-28 18:44:12,111 _GTK_APP_MENU_OBJECT_PATH=None 2018-08-28 18:44:12,111 _GTK_APPLICATION_ID=None 2018-08-28 18:44:12,112 _GTK_APPLICATION_OBJECT_PATH=None 2018-08-28 18:44:12,112 _GTK_UNIQUE_BUS_NAME=None 2018-08-28 18:44:12,112 _GTK_WINDOW_OBJECT_PATH=None 2018-08-28 18:44:12,112 updateprop(menu, {}) previous value=None 2018-08-28 18:44:12,112 not sending notify(menu) (setup done=False, managed=False) 2018-08-28 18:44:12,112 WM_NORMAL_HINTS={'min_size': (10, 17), 'win_gravity': 1, 'resize_inc': (6, 13), 'base_size': (4, 4), 'size': (484, 316)} 2018-08-28 18:44:12,113 updateprop(size-hints, {'base-size': (4, 4), 'minimum-size': (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)}) previous value=None 2018-08-28 18:44:12,113 not sending notify(size-hints) (setup done=False, managed=False) 2018-08-28 18:44:12,113 Missing property _MOTIF_WM_HINTS (motif-hints) 2018-08-28 18:44:12,113 _MOTIF_WM_HINTS=None 2018-08-28 18:44:12,113 _NET_WM_ICON_NAME=None 2018-08-28 18:44:12,113 WM_ICON_NAME=xterm 2018-08-28 18:44:12,114 updateprop(icon-title, xterm) previous value=None 2018-08-28 18:44:12,114 not sending notify(icon-title) (setup done=False, managed=False) 2018-08-28 18:44:12,114 _NET_WM_ICON changed on 0x60000d, re-reading 2018-08-28 18:44:12,114 icon is now None, pixmap=None 2018-08-28 18:44:12,114 initial X11 position and size: requested((0, 0, 484, 316), {'base-size': (4, 4), 'minimum-size': (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)})=(0, 0, 484, 316) 2018-08-28 18:44:12,114 get_wm_state(modal) state_names=('_NET_WM_STATE_MODAL',) 2018-08-28 18:44:12,115 WindowDamageHandler.__init__(0x60000d, True) 2018-08-28 18:44:12,115 invalidating named pixmap, contents handle=None 2018-08-28 18:44:12,115 damage handle(0x60000d)=0x40002c 2018-08-28 18:44:12,115 displayHasXShape()=True 2018-08-28 18:44:12,116 setup_property_sync() 2018-08-28 18:44:12,116 sync_allowed_actions: setting _NET_WM_ALLOWED_ACTIONS=['_NET_WM_ACTION_CLOSE', '_NET_WM_ACTION_MOVE', '_NET_WM_ACTION_RESIZE', '_NET_WM_ACTION_FULLSCREEN', '_NET_WM_ACTION_MINIMIZE', '_NET_WM_ACTION_SHADE', '_NET_WM_ACTION_STICK', '_NET_WM_ACTION_MAXIMIZE_HORZ', '_NET_WM_ACTION_MAXIMIZE_VERT', '_NET_WM_ACTION_CHANGE_DESKTOP', '_NET_WM_ACTION_ABOVE', '_NET_WM_ACTION_BELOW'] on 0x60000d 2018-08-28 18:44:12,116 sync_frame: frame(0x60000d)=None 2018-08-28 18:44:12,117 get(override-redirect, False) returning default value=False 2018-08-28 18:44:12,117 get(tray, False) returning default value=False 2018-08-28 18:44:12,117 sync_frame: setting _NET_FRAME_EXTENTS=(0, 0, 0, 0) on 0x60000d 2018-08-28 18:44:12,117 sync_state: setting _NET_WM_STATE=frozenset([]) on 0x60000d 2018-08-28 18:44:12,117 get(iconic, None) using get_property=False 2018-08-28 18:44:12,118 _handle_iconic_update: set_state(1) 2018-08-28 18:44:12,118 setup() corral_window=0x40002d 2018-08-28 18:44:12,118 setup() adding to save set 2018-08-28 18:44:12,118 setup() reparenting 2018-08-28 18:44:12,119 setup() geometry 2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), 'minimum-size': (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)} size=484x316 2018-08-28 18:44:12,119 updateprop(geometry, (0, 0, 484, 316)) unchanged 2018-08-28 18:44:12,119 setup() resizing windows to 484x316 2018-08-28 18:44:12,120 adding window WindowModel(0x60000d) 2018-08-28 18:44:12,120 add_new_window_common(WindowModel(0x60000d)) watching for dynamic properties: ['title', 'command', 'shape', 'class-instance', 'protocols', 'attention-requested', 'menu', 'workspace', 'opacity', 'fullscreen', 'focused', 'maximized', 'above', 'below', 'shaded', 'skip-taskbar', 'skip-pager', 'sticky', 'size-hints', 'icon-title', 'icon', 'decorations', 'modal', 'iconic'] 2018-08-28 18:44:12,120 get(tray, False) returning default value=False 2018-08-28 18:44:12,121 Discovered new ordinary window: WindowModel(0x60000d) (geometry=(0, 0, 484, 316)) 2018-08-28 18:44:12,121 ownership_election() winner=None, old owner=None, candidates=[(-1, DesktopManager(1))] 2018-08-28 18:44:12,121 x_event_filter event=(None, 'child-map-request-event')/MapRequest took 22.1ms 2018-08-28 18:44:12,121 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,122 parse_event(..)= 2018-08-28 18:44:12,122 Property changed on 0x60000d: _NET_WM_ALLOWED_ACTIONS 2018-08-28 18:44:12,122 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.7ms 2018-08-28 18:44:12,122 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,122 parse_event(..)= 2018-08-28 18:44:12,122 Property changed on 0x60000d: _NET_FRAME_EXTENTS 2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.6ms 2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,123 parse_event(..)= 2018-08-28 18:44:12,123 Property changed on 0x60000d: _NET_WM_STATE 2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.6ms 2018-08-28 18:44:12,123 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,124 parse_event(..)= 2018-08-28 18:44:12,124 Property changed on 0x60000d: WM_STATE 2018-08-28 18:44:12,124 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.6ms 2018-08-28 18:44:12,124 x_event_filter event=('xpra-create-event', None)/CreateNotify window=0x299 2018-08-28 18:44:12,124 parse_event(..)= 2018-08-28 18:44:12,124 x_event_filter event=('xpra-create-event', None)/CreateNotify took 0.3ms 2018-08-28 18:44:12,125 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x40002d 2018-08-28 18:44:12,125 parse_event(..)= 2018-08-28 18:44:12,125 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.4ms 2018-08-28 18:44:12,125 x_event_filter event=('xpra-reparent-event', None)/ReparentNotify window=0x60000d 2018-08-28 18:44:12,125 parse_event(..)= 2018-08-28 18:44:12,126 invalidating named pixmap, contents handle=None 2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event', None)/ReparentNotify took 0.5ms 2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event', None)/ReparentNotify window=0x299 2018-08-28 18:44:12,126 parse_event(..)= 2018-08-28 18:44:12,126 x_event_filter event=('xpra-reparent-event', None)/ReparentNotify took 0.4ms 2018-08-28 18:44:12,126 x_event_filter event=('xpra-map-event', 'xpra-child-map-event')/MapNotify window=0x60000d 2018-08-28 18:44:12,126 parse_event(..)= 2018-08-28 18:44:12,127 x_event_filter event=('xpra-map-event', 'xpra-child-map-event')/MapNotify took 0.3ms 2018-08-28 18:44:12,127 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,127 parse_event(..)= 2018-08-28 18:44:12,127 Property changed on 0x60000d: _XPRA_WID 2018-08-28 18:44:12,127 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 0.6ms 2018-08-28 18:44:12,305 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,305 parse_event(..)= 2018-08-28 18:44:12,306 Property changed on 0x60000d: WM_ICON_NAME 2018-08-28 18:44:12,306 _NET_WM_ICON_NAME=None 2018-08-28 18:44:12,306 WM_ICON_NAME=~ 2018-08-28 18:44:12,307 updateprop(icon-title, ~) previous value=xterm 2018-08-28 18:44:12,307 updating metadata on WindowModel(0x60000d): 2018-08-28 18:44:12,307 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 2.0ms 2018-08-28 18:44:12,307 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify window=0x60000d 2018-08-28 18:44:12,307 parse_event(..)= 2018-08-28 18:44:12,308 Property changed on 0x60000d: WM_NAME 2018-08-28 18:44:12,308 _NET_WM_NAME=None 2018-08-28 18:44:12,308 WM_NAME=~ 2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm 2018-08-28 18:44:12,308 updating metadata on WindowModel(0x60000d): 2018-08-28 18:44:12,308 wm_name changed 2018-08-28 18:44:12,308 x_event_filter event=('xpra-property-notify-event', None)/PropertyNotify took 1.4ms *Client Log:* 2018-08-28 11:37:54,084 LoadImage(C:\Program Files\Xpra\icons\xpra.ico) using image type=ICON 2018-08-28 11:37:54,086 LoadImage(C:\Program Files\Xpra\icons\xpra.ico)=3408641 2018-08-28 11:37:54,087 do_set_icon(0x340301) 2018-08-28 11:37:54,088 make_nid(..)= tooltip='ssh://bsferrazza at l-server-13/:100', app_id=0, actual flags=ICON, GUID 2018-08-28 11:37:54,090 make_nid(..)= tooltip='ssh://bsferrazza at l-server-13/:100', app_id=0, actual flags=ICON, GUID 2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 3936, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 3936, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] 2018-08-28 11:37:58,987 read_parse_thread_loop starting 2018-08-28 11:37:58,987 read thread: eof 2018-08-28 11:37:58,989 parse thread: empty marker, exiting 2018-08-28 11:37:58,992 io_thread_loop(read, ) loop ended, closed=False 2018-08-28 11:37:58,993 Protocol.close() closed=False, connection=Pipe(ssh://bsferrazza at l-server-13/:100) 2018-08-28 11:37:58,996 Protocol.close() calling 2018-08-28 11:37:58,998 Pipe(ssh://bsferrazza at l-server-13/:100).close() close callback=, readable=', mode 'rb' at 0x000000001862f810>, writeable=', mode 'wb' at 0x000000001862f9c0> 2018-08-28 11:37:59,003 Pipe(ssh://bsferrazza at l-server-13/:100).close() calling 2018-08-28 11:37:59,003 Pipe(ssh://bsferrazza at l-server-13/:100).close() done 2018-08-28 11:37:59,004 terminate_queue_threads() 2018-08-28 11:37:59,005 write thread: empty marker, exiting 2018-08-28 11:37:59,005 Protocol.close() done 2018-08-28 11:37:59,005 Protocol.close() closed=True, connection=None 2018-08-28 11:37:59,006 check_server_echo(0) last=True, server_ok=True (last_ping_echoed_time=0) 2018-08-28 11:37:59,006 io_thread_loop(write, ) loop ended, closed=True 2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra server? 2018-08-28 11:37:59,010 could also be the wrong protocol, username, password or port 2018-08-28 11:37:59,010 or the session was not found 2018-08-28 11:37:59,010 Connection lost 2018-08-28 11:37:59,011 GTKXpraClient.quit(1) current exit_code=None 2018-08-28 11:37:59,012 UIXpraClient.cleanup() 2018-08-28 11:37:59,012 poll() procinfo list: [ProcInfo({'returncode': None, 'name': 'ssh', 'process': , 'pid': 3936, 'dead': False, 'ignore': True, 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra initenv;if [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; exit 1; fi'], 'forget': False})] On Tue, Mar 6, 2018 at 9:46 AM Ben Sferrazza wrote: > On Tue, Mar 6, 2018 at 9:24 AM, Antoine Martin via shifter-users < > shifter-users at lists.devloop.org.uk> wrote: > >> > OK thanks. Xpra server is running as shown here. Its own log file >> doesn't >> > seem to react to the client connecting from below. >> That's because it never gets a connection from the client, see below. >> So, it seems that you're using SSH. I always advise to try with plain >> TCP or SSL first before introducing a transport intermediary like SSH. >> > > OK. I thought as a regular user I wouldn't have access to bind to TCP > ports. I at least know I can SSH into these machines. > > >> >> (..) >> > Here's the relevant output from the client. The 'no run-xpra' command >> found >> > seems to be the most glaring. >> If you started the server using the same user account, it should have >> placed a "run-xpra" script in one of the locations that the client will >> attempt to use. From your debug output, this will include: >> ~/.xpra/run-xpra >> $XDG_RUNTIME_DIR/xpra/run-xpra >> xpra >> /usr/local/bin/xpra >> >> Note that XDG_RUNTIME_DIR may not be set when logging in via ssh if you >> had to hack it previously. But ~/.xpra/run-xpra should exist anyway. >> I'm just mentioning for completeness. >> > > OK, yes those files do indeed exist. > > >> >> (..) >> > 2018-03-06 08:44:04,610 poll() procinfo list: [ProcInfo({'returncode': >> > None, 'name': 'ssh', 'process': > > 0x000000001a2d3250>, 'pid': 15132, 'dead': False, 'ignore': True, >> > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-T', >> > 'l-server-13', 'xpra initenv;if [ -x ~/.xpra/run-xpra ]; then >> > ~/.xpra/run-xpra _proxy :100;elif [ -x $XDG_RUNTIME_DIR/xpra/run-xpra ]; >> > then $XDG_RUNTIME_DIR/xpra/run-xpra _proxy :100;elif type "xpra" > >> > /dev/null 2>&1; then xpra _proxy :100;elif [ -x /usr/local/bin/xpra ]; >> then >> > /usr/local/bin/xpra _proxy :100;else echo "no run-xpra command found"; >> exit >> (..) >> >> > 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet >> > header byte C: '436164656e636520' read buffer='Cadence digital tool >> > setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) >> And here is your problem. >> Something in your user environment is printing out some text to the SSH >> terminal connection which xpra uses to communicate with the xpra server. >> When it sees that this isn't xpra's protocol, it drops the connection. >> >> Either clean this up from your user's login scripts or use TCP / SSL >> connections instead. > > > I commented out the line that sources a tool setup script (for Cadence CAD > software that echos back stuff) in my shell rc file. I can now launch an > xterm window!! Thank you. I suppose I can always source that too setup > script on demand when I actually need it, as opposed to sourcing it always > in my shell's rc file. > From antoine at nagafix.co.uk Wed Aug 29 04:04:20 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 29 Aug 2018 10:04:20 +0700 Subject: [winswitch] Blacked-out menus in Xpra 1.x In-Reply-To: References: Message-ID: <31f660a5-57e2-8e4a-7148-eedc365ba096@nagafix.co.uk> On 29/08/18 00:57, Lemings, Brad [US] (MS) via shifter-users wrote: > Greetings, > > I have noticed with old Motif applications that menus will sometimes be completely blacked out when viewed through a 'xpra attach' session using Xpra version 1.x. Does it work any better with other versions? I have never seen this problem - otherwise it would have been fixed already, but then again Motif applications are few and far between nowadays. > Does anybody have some ideas what might cause that and how to fix it? No idea, can you provide the source to a sample application we can use to debug this problem? Cheers, Antoine > > Thanks, > Eric. > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From antoine at nagafix.co.uk Wed Aug 29 04:42:03 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 29 Aug 2018 10:42:03 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: > Hi. I'm including my previous correspondence below, as it will at least > offer some history about my setup and prior issues. > > I stopped using Xpra a few months ago due to numerous bugs that made it > unusable (this is using a Linux server and Windows client). > > 1. windows get stuck with on-top focus Which windows from which applications? > 2. disappearing mouse cursor when using X11-only no-toolkit apps that use > inverted black mouse pointer after clicking on something Do you have a specific application we can use to reproduce the problem? > 3. some windows don't show window bar until resized (e.g. gvim always gets > placed in upper-left without window bar) Some applications do weird things with their geometry sometimes, gvim is one of those. That said, I've just tried it and it worked fine and it does seem to request to be placed in the top left corner. Please provide more details so we can reproduce the window bar problem. (ie: server os and version, gvim version, etc..) > 4. dialog box black bars (appears to be trying to add scrollbars?). Can you provide example applications we can use to reproduce the problem? I've never seen that anywhere except when X11 windows are smaller than the minimal window size on mswindows, then we have to pad it with something. > 5. windows are all blank (white) when returning into work after several > hours (requires restarting client) That's a known "feature" of some opengl drivers, they clear the video memory when the system goes into idle or suspended state. We try to detect that (slowing down the refresh rate) and then refresh the screen when the session resumes, but that doesn't always fix things. You should not need to restart the client: minimizing the windows and restoring them should be enough. Alternatively, turn off opengl in the client - the client performance will be much lower. > 6. flickering clipboard icon in systray That's a very obvious sign that something is not right and something is constantly requesting the clipboard contents. This will cause unnecessary traffic and instability. Try to figure out what is causing this and stop it. Usually, this is caused by clipboard managers or other clipboard synchronization tools (synergy, virtualbox, etc). > I'm inclined to give Xpra another chance, with the newer versions, and can > hopefully provide actual debugging log information for these bugs to be > fixed (if they haven't already). Bugs that are reproducible are usually fixed pretty quickly. Unfortunately, I have not seen any of the problems you have reported above, so the chances that newer versions have already fixed those issues are slim. For more generic bug reporting and debugging guidelines, see: https://xpra.org/trac/wiki/ReportingBugs > But I'm now not even able to connect to the server from the client using > version 2.3.3. It reports Connection Lost immediately. I can ssh into the > same host without issue. And have made sure that the shell rc file no > longer outputs anything, which was the source of my issue a few months ago. > I have included the relevant sections of the server log and client log > below. > > *Server Log:* (..) > 2018-08-28 18:44:12,059 add_process( 0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703 > 2018-08-28 18:44:12,059 xpra is ready. (..) > 2018-08-28 18:44:12,067 251.9GB of system memory For real? (..) > 2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), 'minimum-size': > (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)} > size=484x316 (..) > 2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm Nothing after that which means that the server never received a connection from the client. > *Client Log:* (..) > 2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode': > None, 'name': 'ssh', 'process': 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra initenv;if > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo > "no run-xpra command found"; exit 1; fi'], 'forget': False})] > 2018-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode': > None, 'name': 'ssh', 'process': 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra initenv;if > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy :100;elif [ > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo > "no run-xpra command found"; exit 1; fi'], 'forget': False})] > 2018-08-28 11:37:58,987 read_parse_thread_loop starting > 2018-08-28 11:37:58,987 read thread: eof (..) > 2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra > server? > 2018-08-28 11:37:59,010 could also be the wrong protocol, username, > password or port > 2018-08-28 11:37:59,010 or the session was not found (..) The client got an EOF from the ssh command it tried to run. (the long and ugly "run-xpra" line above) That usually means that the session was not found, or that none of the "xpra" or "run-xpra" executable scripts are available and executable. You can try running it by hand from a putty session. I would also try to connect from a *nix client to see if the problem is likely to be client side or server side. This can also be caused by non-bash login shells (ie: csh, tcsh): https://xpra.org/trac/ticket/1892 The latest 2.4 beta builds include a new ssh backend, which you can enable using "--ssh=paramiko" and this will give you more details using "--debug=ssh". It should also support all types of login shells, unlike putty. More details here: https://xpra.org/trac/ticket/1646 >>>> OK thanks. Xpra server is running as shown here. Its own log file >>> doesn't >>>> seem to react to the client connecting from below. >>> That's because it never gets a connection from the client, see below. >>> So, it seems that you're using SSH. I always advise to try with plain >>> TCP or SSL first before introducing a transport intermediary like SSH. >>> >> >> OK. I thought as a regular user I wouldn't have access to bind to TCP >> ports. I at least know I can SSH into these machines. Only ports below 1024 are restricted: https://unix.stackexchange.com/questions/10735/ (..) >>>> 2018-03-06 08:44:12,788 process_gibberish(['gibberish', "invalid packet >>>> header byte C: '436164656e636520' read buffer='Cadence digital tool >>>> setup\\n' (27 bytes)", 'Cadence digital tool setup\n']) >>> And here is your problem. >>> Something in your user environment is printing out some text to the SSH >>> terminal connection which xpra uses to communicate with the xpra server. >>> When it sees that this isn't xpra's protocol, it drops the connection. >>> >>> Either clean this up from your user's login scripts or use TCP / SSL >>> connections instead. >> >> I commented out the line that sources a tool setup script (for Cadence CAD >> software that echos back stuff) in my shell rc file. I can now launch an >> xterm window!! Thank you. I suppose I can always source that too setup >> script on demand when I actually need it, as opposed to sourcing it always >> in my shell's rc file. You can also keep the line that sources it and just redirect the output to stderr: source yourscript.sh 1>&2 Cheers, Antoine From bsferrazza at avnera.com Wed Aug 29 18:27:33 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Wed, 29 Aug 2018 10:27:33 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin wrote: > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: > > Hi. I'm including my previous correspondence below, as it will at least > > offer some history about my setup and prior issues. > > > > I stopped using Xpra a few months ago due to numerous bugs that made it > > unusable (this is using a Linux server and Windows client). > > > > 1. windows get stuck with on-top focus > Which windows from which applications? > > 2. disappearing mouse cursor when using X11-only no-toolkit apps that use > > inverted black mouse pointer after clicking on something > Do you have a specific application we can use to reproduce the problem? > > 3. some windows don't show window bar until resized (e.g. gvim always > gets > > placed in upper-left without window bar) > Some applications do weird things with their geometry sometimes, gvim is > one of those. That said, I've just tried it and it worked fine and it > does seem to request to be placed in the top left corner. > Please provide more details so we can reproduce the window bar problem. > (ie: server os and version, gvim version, etc..) > > 4. dialog box black bars (appears to be trying to add scrollbars?). > Can you provide example applications we can use to reproduce the problem? > I've never seen that anywhere except when X11 windows are smaller than > the minimal window size on mswindows, then we have to pad it with > something. > > 5. windows are all blank (white) when returning into work after several > > hours (requires restarting client) > That's a known "feature" of some opengl drivers, they clear the video > memory when the system goes into idle or suspended state. > We try to detect that (slowing down the refresh rate) and then refresh > the screen when the session resumes, but that doesn't always fix things. > You should not need to restart the client: minimizing the windows and > restoring them should be enough. > Alternatively, turn off opengl in the client - the client performance > will be much lower. > > 6. flickering clipboard icon in systray > That's a very obvious sign that something is not right and something is > constantly requesting the clipboard contents. This will cause > unnecessary traffic and instability. Try to figure out what is causing > this and stop it. Usually, this is caused by clipboard managers or other > clipboard synchronization tools (synergy, virtualbox, etc). > I'll certainly provide you with more details once I'm re-connected using Xpra 2.3.3, and we can hopefully debug the issues I was experiencing. > > I'm inclined to give Xpra another chance, with the newer versions, and > can > > hopefully provide actual debugging log information for these bugs to be > > fixed (if they haven't already). > Bugs that are reproducible are usually fixed pretty quickly. > Unfortunately, I have not seen any of the problems you have reported > above, so the chances that newer versions have already fixed those > issues are slim. > For more generic bug reporting and debugging guidelines, see: > https://xpra.org/trac/wiki/ReportingBugs > > > But I'm now not even able to connect to the server from the client using > > version 2.3.3. It reports Connection Lost immediately. I can ssh into the > > same host without issue. And have made sure that the shell rc file no > > longer outputs anything, which was the source of my issue a few months > ago. > > I have included the relevant sections of the server log and client log > > below. > > > > > *Server Log:* > (..) > > 2018-08-28 18:44:12,059 add_process( > 0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703 > > 2018-08-28 18:44:12,059 xpra is ready. > (..) > > 2018-08-28 18:44:12,067 251.9GB of system memory > For real? > It's a 48-core server here at work. > (..) > > 2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), > 'minimum-size': > > (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)} > > size=484x316 > (..) > > 2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm > Nothing after that which means that the server never received a > connection from the client. > > > > *Client Log:* > (..) > > 2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode': > > None, 'name': 'ssh', 'process': > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, > > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', > > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra > initenv;if > > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x > > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra > > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy > :100;elif [ > > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo > > "no run-xpra command found"; exit 1; fi'], 'forget': False})] > > 2018-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode': > > None, 'name': 'ssh', 'process': > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, > > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', > > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra > initenv;if > > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x > > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra > > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy > :100;elif [ > > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo > > "no run-xpra command found"; exit 1; fi'], 'forget': False})] > > 2018-08-28 11:37:58,987 read_parse_thread_loop starting > > 2018-08-28 11:37:58,987 read thread: eof > (..) > > 2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra > > server? > > 2018-08-28 11:37:59,010 could also be the wrong protocol, username, > > password or port > > 2018-08-28 11:37:59,010 or the session was not found > (..) > The client got an EOF from the ssh command it tried to run. > (the long and ugly "run-xpra" line above) > That usually means that the session was not found, or that none of the > "xpra" or "run-xpra" executable scripts are available and executable. > > You can try running it by hand from a putty session. > I would also try to connect from a *nix client to see if the problem is > likely to be client side or server side. > > This can also be caused by non-bash login shells (ie: csh, tcsh): > https://xpra.org/trac/ticket/1892 > The latest 2.4 beta builds include a new ssh backend, which you can > enable using "--ssh=paramiko" and this will give you more details using > "--debug=ssh". It should also support all types of login shells, unlike > putty. More details here: > https://xpra.org/trac/ticket/1646 OK, we do unfortunately use tcsh here because of some Cadence (EE EDA software) tools that have a bunch of csh scripts for setting up licenses and other things. When I struggled with getting Xpra to connect a few months ago, the culprit was some output to stdout from my .cshrc file. Though that's been suppressed. I'll give some of the suggestions you mentioned a try and report back. Thanks, Ben From ajs1 at cam.ac.uk Wed Aug 29 19:30:45 2018 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Wed, 29 Aug 2018 19:30:45 +0100 Subject: [winswitch] Can't start xpra session Message-ID: Antoine, I am puzzled by the following. I tried to start an xpra session on my usual server, and got this on the client: $ xpra start ssh/whirligig/100 --start="gnome-terminal --window-with-profile=Blue" & [3] 21295 17:57:38 $ 2018-08-29 17:57:39,090 Xpra gtk2 client version 2.3.3-r20112 64-bit 2018-08-29 17:57:39,090 running on Linux Ubuntu 16.04 xenial ...etc... xpra initialization error: failed to identify the new server display! 2018-08-29 17:58:02,443 Error: failed to receive anything, not an xpra server? 2018-08-29 17:58:02,443 could also be the wrong protocol, username, password or port 2018-08-29 17:58:02,444 or the session was not found So in an ssh session on the server, I tried the following: 17:59:57 $ xpra list Found the following xpra sessions: /run/user/1013/xpra: UNKNOWN session at :100 /home/ajs1/.xpra: UNKNOWN session at :100 /run/xpra: UNKNOWN session at :100 Re-probing unknown sessions in: /run/xpra, /home/ajs1/.xpra, /run/user/1013/xpra UNKNOWN session at :100 (cleaned up) UNKNOWN session at :100 (cleaned up) UNKNOWN session at :100 (cleaned up) 18:00:13 $ xpra stop :100 xpra initialization error: cannot find live server for display :100 18:00:30 $ xpra stop xpra initialization error: cannot find any live servers to connect to 18:00:37 $ xpra list No xpra sessions found and then tried to start a session from the client as before, using the same command, and I got the same initialization error. Going back to the server, I got, much as before, 18:00:45 $ xpra list Found the following xpra sessions: /run/user/1013/xpra: UNKNOWN session at :100 /home/ajs1/.xpra: UNKNOWN session at :100 /run/xpra: UNKNOWN session at :100 Re-probing unknown sessions in: /run/xpra, /home/ajs1/.xpra, /run/user/1013/xpra UNKNOWN session at :100 (cleaned up) UNKNOWN session at :100 (cleaned up) UNKNOWN session at :100 (cleaned up) 18:01:43 $ 18:12:36 $ 18:12:36 $ xpra list No xpra sessions found Am I doing something daft, or is there a bug? The xpra start command has worked many times before -- I usually use ctrl-R to retrieve the previous start command each time, rather than retyping it. On both server and client, I have: $ xpra --version xpra v2.3.3-r20112 Anthony Stone From bsferrazza at avnera.com Thu Aug 30 00:04:27 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Wed, 29 Aug 2018 16:04:27 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: While I was debugging the issue yesterday, I figured I'd update my Xorg X server to the latest version, 1.20.1. This seems to have broken things when loading the Xdummy module, as the ABI versions no longer match. Is the dummy_drv part of Xpra? Is there a possibility for this to be updated? For now I just rolled back to X server 1.19.6 and everything works. [904276.126] (II) LoadModule: "glx" [904276.130] (II) Loading /home/tools/lib/xorg/modules/extensions/libglx.so [904276.155] (II) Module glx: vendor="X.Org Foundation" [904276.155] compiled for 1.19.6, module version = 1.0.0 [904276.155] ABI class: X.Org Server Extension, version 10.0 [904276.155] (II) LoadModule: "dummy" [904276.162] (II) Loading /home/tools/lib/xorg/modules/drivers/dummy_drv.so [904276.162] (II) Module dummy: vendor="X.Org Foundation" [904276.162] compiled for 1.19.6, module version = 0.3.8 [904276.162] Module class: X.Org Video Driver [904276.162] ABI class: X.Org Video Driver, version 23.0 [904276.162] (WW) dummy: module ABI major version (23) doesn't match the server's version (24) *So, I installed the latest MS Windows beta and explicitly used paramiko as the ssh client. This solved my issue and can now connect to my Xpra server running on Linux*. This was not an issue in Xpra 2.2, so I imagine something in 2.3 changed the way it interfaces with the shell? Thanks, Ben On Wed, Aug 29, 2018 at 10:27 AM Ben Sferrazza wrote: > > > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin > wrote: > >> On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: >> > Hi. I'm including my previous correspondence below, as it will at least >> > offer some history about my setup and prior issues. >> > >> > I stopped using Xpra a few months ago due to numerous bugs that made it >> > unusable (this is using a Linux server and Windows client). >> > >> > 1. windows get stuck with on-top focus >> Which windows from which applications? >> > 2. disappearing mouse cursor when using X11-only no-toolkit apps that >> use >> > inverted black mouse pointer after clicking on something >> Do you have a specific application we can use to reproduce the problem? >> > 3. some windows don't show window bar until resized (e.g. gvim always >> gets >> > placed in upper-left without window bar) >> Some applications do weird things with their geometry sometimes, gvim is >> one of those. That said, I've just tried it and it worked fine and it >> does seem to request to be placed in the top left corner. >> Please provide more details so we can reproduce the window bar problem. >> (ie: server os and version, gvim version, etc..) >> > 4. dialog box black bars (appears to be trying to add scrollbars?). >> Can you provide example applications we can use to reproduce the problem? >> I've never seen that anywhere except when X11 windows are smaller than >> the minimal window size on mswindows, then we have to pad it with >> something. >> > 5. windows are all blank (white) when returning into work after several >> > hours (requires restarting client) >> That's a known "feature" of some opengl drivers, they clear the video >> memory when the system goes into idle or suspended state. >> We try to detect that (slowing down the refresh rate) and then refresh >> the screen when the session resumes, but that doesn't always fix things. >> You should not need to restart the client: minimizing the windows and >> restoring them should be enough. >> Alternatively, turn off opengl in the client - the client performance >> will be much lower. >> > 6. flickering clipboard icon in systray >> That's a very obvious sign that something is not right and something is >> constantly requesting the clipboard contents. This will cause >> unnecessary traffic and instability. Try to figure out what is causing >> this and stop it. Usually, this is caused by clipboard managers or other >> clipboard synchronization tools (synergy, virtualbox, etc). >> > > I'll certainly provide you with more details once I'm re-connected using > Xpra 2.3.3, and we can hopefully debug the issues I was experiencing. > > >> > I'm inclined to give Xpra another chance, with the newer versions, and >> can >> > hopefully provide actual debugging log information for these bugs to be >> > fixed (if they haven't already). >> Bugs that are reproducible are usually fixed pretty quickly. >> Unfortunately, I have not seen any of the problems you have reported >> above, so the chances that newer versions have already fixed those >> issues are slim. >> For more generic bug reporting and debugging guidelines, see: >> https://xpra.org/trac/wiki/ReportingBugs >> >> > But I'm now not even able to connect to the server from the client using >> > version 2.3.3. It reports Connection Lost immediately. I can ssh into >> the >> > same host without issue. And have made sure that the shell rc file no >> > longer outputs anything, which was the source of my issue a few months >> ago. >> > I have included the relevant sections of the server log and client log >> > below. >> >> > >> > *Server Log:* >> (..) >> > 2018-08-28 18:44:12,059 add_process(> > 0x2b6cf2e9eb10>, xterm, ['xterm'], True, False) pid=17703 >> > 2018-08-28 18:44:12,059 xpra is ready. >> (..) >> > 2018-08-28 18:44:12,067 251.9GB of system memory >> For real? >> > > It's a 48-core server here at work. > > >> (..) >> > 2018-08-28 18:44:12,119 setup() hints={'base-size': (4, 4), >> 'minimum-size': >> > (10, 17), 'gravity': 1, 'increment': (6, 13), 'size': (484, 316)} >> > size=484x316 >> (..) >> > 2018-08-28 18:44:12,308 updateprop(title, ~) previous value=xterm >> Nothing after that which means that the server never received a >> connection from the client. >> >> >> > *Client Log:* >> (..) >> > 2018-08-28 11:37:55,166 poll() procinfo list: [ProcInfo({'returncode': >> > None, 'name': 'ssh', 'process': > > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, >> > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', >> > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra >> initenv;if >> > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x >> > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra >> > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy >> :100;elif [ >> > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo >> > "no run-xpra command found"; exit 1; fi'], 'forget': False})] >> > 2018-08-28 11:37:57,167 poll() procinfo list: [ProcInfo({'returncode': >> > None, 'name': 'ssh', 'process': > > 0x00000000186c8890>, 'pid': 3936, 'dead': False, 'ignore': True, >> > 'callback': None, 'command': ['plink', '-ssh', '-agent', '-l', >> > 'bsferrazza', '-T', 'l-server-13', '#run-xpra _proxy :100\nxpra >> initenv;if >> > [ -x ~/.xpra/run-xpra ]; then ~/.xpra/run-xpra _proxy :100;elif [ -x >> > $XDG_RUNTIME_DIR/xpra/run-xpra ]; then $XDG_RUNTIME_DIR/xpra/run-xpra >> > _proxy :100;elif type "xpra" > /dev/null 2>&1; then xpra _proxy >> :100;elif [ >> > -x /usr/local/bin/xpra ]; then /usr/local/bin/xpra _proxy :100;else echo >> > "no run-xpra command found"; exit 1; fi'], 'forget': False})] >> > 2018-08-28 11:37:58,987 read_parse_thread_loop starting >> > 2018-08-28 11:37:58,987 read thread: eof >> (..) >> > 2018-08-28 11:37:59,006 Error: failed to receive anything, not an xpra >> > server? >> > 2018-08-28 11:37:59,010 could also be the wrong protocol, username, >> > password or port >> > 2018-08-28 11:37:59,010 or the session was not found >> (..) >> The client got an EOF from the ssh command it tried to run. >> (the long and ugly "run-xpra" line above) >> That usually means that the session was not found, or that none of the >> "xpra" or "run-xpra" executable scripts are available and executable. >> >> You can try running it by hand from a putty session. >> I would also try to connect from a *nix client to see if the problem is >> likely to be client side or server side. >> >> This can also be caused by non-bash login shells (ie: csh, tcsh): >> https://xpra.org/trac/ticket/1892 >> The latest 2.4 beta builds include a new ssh backend, which you can >> enable using "--ssh=paramiko" and this will give you more details using >> "--debug=ssh". It should also support all types of login shells, unlike >> putty. More details here: >> https://xpra.org/trac/ticket/1646 > > > OK, we do unfortunately use tcsh here because of some Cadence (EE EDA > software) tools that have a bunch of csh scripts for setting up licenses > and other things. When I struggled with getting Xpra to connect a few > months ago, the culprit was some output to stdout from my .cshrc file. > Though that's been suppressed. I'll give some of the suggestions you > mentioned a try and report back. > > Thanks, > Ben > From bsferrazza at avnera.com Thu Aug 30 01:15:23 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Wed, 29 Aug 2018 17:15:23 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: <7386ab0f-b6a3-57bf-e018-8b62507ee3a6@nagafix.co.uk> <00c5a284-2edc-1730-b515-c4977ed203c0@nagafix.co.uk> Message-ID: Now that I've established a connection again with Xpra server 2.3.3, I can try to address some of the issues I was/am experiencing. I haven't used it enough to encounter the first two issues, which were the most debilitating and largely made it unusable for me before (the stuck focus issue and the disappearing mouse cursor). Once I can re-create those I'll have more to offer. On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin wrote: > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: > > Hi. I'm including my previous correspondence below, as it will at least > > offer some history about my setup and prior issues. > > > > I stopped using Xpra a few months ago due to numerous bugs that made it > > unusable (this is using a Linux server and Windows client). > > > > 1. windows get stuck with on-top focus > Which windows from which applications? > This was by far the most egregious bug. It seemed to happen at random and affected all applications. Considering I do a lot of work in a terminal, chances are it was a terminal such as xfce4-terminal. I will report back once this occurs again. My only solution was to minimize the window, rather than simply clicking on another window to give it focus. > > 2. disappearing mouse cursor when using X11-only no-toolkit apps that use > > inverted black mouse pointer after clicking on something > Do you have a specific application we can use to reproduce the problem? > Unfortunately the application I encountered this issue with the most was Cadence's Simvision, a digital simulation waveform viewer that's part of their CAD/EDA software suite. The only observation I had was that it is an application which does not make use of a modern toolkit, such as GTK. Perhaps it's using Motif? When you click on a menu the mouse cursor inverts to a right-pointing black cursor, which is a cursor internal to the program and is not replaced by the client's cursor. That's when the menu items would disappear. I've attached a screenshot of it working, which required using an actual camera, as the inverted black cursor is not picked up by the Windows print screen function. > > 3. some windows don't show window bar until resized (e.g. gvim always > gets > > placed in upper-left without window bar) > Some applications do weird things with their geometry sometimes, gvim is > one of those. That said, I've just tried it and it worked fine and it > does seem to request to be placed in the top left corner. > Please provide more details so we can reproduce the window bar problem. > (ie: server os and version, gvim version, etc..) > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior. It corrects itself once I do any resizing of the window (which must initiate a redraw event). Perhaps Xpra could force a redraw event after opening the window? > > 4. dialog box black bars (appears to be trying to add scrollbars?). > Can you provide example applications we can use to reproduce the problem? > I've never seen that anywhere except when X11 windows are smaller than > the minimal window size on mswindows, then we have to pad it with > something. > Perhaps that's all it is. Certainly not a big deal, and just a cosmetic annoyance. I've attached an example of this issue from a dialog box that pops up using diffuse. Perhaps this would be too much work, but a slightly more pleasing visual than black bars would be to sample the color of the edge pixels and use this color (or an average of samples) to extend the window to the minimum size. > > 5. windows are all blank (white) when returning into work after several > > hours (requires restarting client) > That's a known "feature" of some opengl drivers, they clear the video > memory when the system goes into idle or suspended state. > We try to detect that (slowing down the refresh rate) and then refresh > the screen when the session resumes, but that doesn't always fix things. > You should not need to restart the client: minimizing the windows and > restoring them should be enough. > Alternatively, turn off opengl in the client - the client performance > will be much lower. > OK, the next time this occurs I'll try to simply minimize the windows. > > 6. flickering clipboard icon in systray > That's a very obvious sign that something is not right and something is > constantly requesting the clipboard contents. This will cause > unnecessary traffic and instability. Try to figure out what is causing > this and stop it. Usually, this is caused by clipboard managers or other > clipboard synchronization tools (synergy, virtualbox, etc). > Hmm. I don't have anything running like that. No VNC session, VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly nothing is currently connected to it. It seems to flicker at a rate of once every 4 seconds or so. It seems periodic, in the mathematical sense of the word. My PC at work is a standard issue Dell box. It has the typical Dell bloatware and some Symantec security software (not much control over this), but can't think of anything that could be potentially interfering with the clipboard. Any suggestions how to determine the cause? Thanks, Ben From antoine at nagafix.co.uk Thu Aug 30 04:22:37 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 30 Aug 2018 10:22:37 +0700 Subject: [winswitch] Can't start xpra session In-Reply-To: References: Message-ID: <9cd9fd8b-5d01-4ee3-f036-a2da69cba3cd@nagafix.co.uk> On 30/08/18 01:30, Anthony Stone via shifter-users wrote: > Antoine, > > I am puzzled by the following. I tried to start an xpra session on my > usual server, and got this on the client: (..) > Am I doing something daft, or is there a bug? The xpra start command has > worked many times before -- I usually use ctrl-R to retrieve the > previous start command each time, rather than retyping it. Directly on the server (ie: via ssh), try to start the session locally: xpra start :100 --start="gnome-terminal --window-with-profile=Blue" Then check it has started: xpra list And if not, have a look at the server log file and send it here if you can't make sense of it. At this point, you should be able to connect (use "attach" instead of "start" and with the display number specified above with start): xpra attach ssh://yourhost/100 If things still fail, please provide the full details (full os version at both ends, etc). Just be aware of the recent incompatibility with non-bash login shells. (this should be fixed in the next stable update) Cheers, Antoine > > On both server and client, I have: > $ xpra --version > xpra v2.3.3-r20112 > > > Anthony Stone From antoine at nagafix.co.uk Thu Aug 30 05:06:32 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 30 Aug 2018 11:06:32 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: On 30/08/18 07:15, shifter-users-owner at lists.devloop.org.uk wrote: > Now that I've established a connection again with Xpra server 2.3.3, I > can try to address some of the issues I was/am experiencing. I haven't > used it enough to encounter the first two issues, which were the most > debilitating and largely made it unusable for me before (the stuck focus > issue and the disappearing mouse cursor). Once I can re-create those > I'll have more to offer. > > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin > wrote: > > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: > > Hi. I'm including my previous correspondence below, as it will at > least > > offer some history about my setup and prior issues. > > > > I stopped using Xpra a few months ago due to numerous bugs that > made it > > unusable (this is using a Linux server and Windows client). > > > > 1. windows get stuck with on-top focus > Which windows from which applications? > > > This was by far the most egregious bug. It seemed to happen at random > and affected all applications. Considering I do a lot of work in a > terminal, chances are it was a terminal such as xfce4-terminal. I will > report back once this occurs again. My only solution was to minimize the > window, rather than simply clicking on another window to give it focus. This does ring a bell, but I don't think I ever saw it myself. https://xpra.org/trac/ticket/713 https://xpra.org/trac/ticket/1381 This could be a platform specific bug (ie: affecting mswindows clients) in which case the newer Python3 GTK3 builds may fare better. > > 2. disappearing mouse cursor when using X11-only no-toolkit apps > that use > > inverted black mouse pointer after clicking on something > Do you have a specific application we can use to reproduce the problem? > > Unfortunately the application I encountered this issue with the most was > Cadence's Simvision, a digital simulation waveform viewer that's part of > their CAD/EDA software suite. The only observation I had was that it is > an application which does not make use of a modern toolkit, such as GTK. > Perhaps it's using Motif? When you click on a menu the mouse cursor > inverts to a right-pointing black cursor, which is a cursor internal to > the program and is not replaced by the client's cursor. That's when the > menu items would disappear. I've attached a screenshot of it working, > which required using an actual camera, as the inverted black cursor is > not picked up by the Windows print screen function. There were bugs in the cursor code on mswindows, including some fixed quite recently, those could have caused the problems you describe - it should now revert to the default cursor in case of failure. > > 3. some windows don't show window bar until resized (e.g. gvim > always gets > > placed in upper-left without window bar) > Some applications do weird things with their geometry sometimes, gvim is > one of those. That said, I've just tried it and it worked fine and it > does seem to request to be placed in the top left corner. > Please provide more details so we can reproduce the window bar problem. > (ie: server os and version, gvim version, etc..) > > > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra > 2.3.3 on?Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT > 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior. > It corrects itself once I do any resizing of the window (which must > initiate a redraw event). Perhaps Xpra could force a redraw event after > opening the window? I bet it's not a redraw event but a window "configure notification" that gvim is waiting for. If I can reproduce this, it should be fixable. We can synthesize an event if needed. What's the server version? CentOS 7.5? > > 4. dialog box black bars (appears to be trying to add scrollbars?). > Can you provide example applications we can use to reproduce the > problem? > I've never seen that anywhere except when X11 windows are smaller than > the minimal window size on mswindows, then we have to pad it with > something. > > Perhaps that's all it is. Sadly, it's not. From the screenshot you attached, this looks like a different problem. > Certainly not a big deal, and just a cosmetic > annoyance. I've attached an example of this issue from a dialog box that > pops up using diffuse. Perhaps this would be too much work, but a > slightly more pleasing visual than black bars would be to sample the > color of the edge pixels and use this color (or an average of samples) > to extend the window to the minimum size. Fixing the problem might be easier. (it looks similar to the gvim problem - the application gets the window geometry wrong) Do you have a sample application I can use to reproduce it? > > 5. windows are all blank (white) when returning into work after > several > > hours (requires restarting client) > That's a known "feature" of some opengl drivers, they clear the video > memory when the system goes into idle or suspended state. > We try to detect that (slowing down the refresh rate) and then refresh > the screen when the session resumes, but that doesn't always fix things. > You should not need to restart the client: minimizing the windows and > restoring them should be enough. > Alternatively, turn off opengl in the client - the client performance > will be much lower. > > > OK, the next time this occurs I'll try to simply minimize the windows. > ? > > > 6. flickering clipboard icon in systray > That's a very obvious sign that something is not right and something is > constantly requesting the clipboard contents. This will cause > unnecessary traffic and instability. Try to figure out what is causing > this and stop it. Usually, this is caused by clipboard managers or other > clipboard synchronization tools (synergy, virtualbox, etc). > > > Hmm. I don't have anything running like that. No VNC session, > VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly > nothing is currently connected to it. It seems to flicker at a rate of > once every 4 seconds or so. OK, then it's not so bad that it will cause instability. Some clipboard managers request the clipboard contents as soon as they're available, swamping the system with clipboard events. If you wish, you can confirm the rate of change by running the client with: "--debug=clipboard" > It seems periodic, in the mathematical sense > of the word. My PC at work is a standard issue Dell box. It has the > typical Dell bloatware and some Symantec security software (not much > control over this), but can't think of anything that could be > potentially interfering with the clipboard. Any suggestions how to > determine the cause? Sorry, I don't know how. The API we use to interact with the clipboard does not offer any information about the application which set or queried the clipboard. Some third party tools may exist to monitor the system at this level. Cheers, Antoine > > Thanks, > Ben From antoine at nagafix.co.uk Thu Aug 30 18:13:29 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 31 Aug 2018 00:13:29 +0700 Subject: [winswitch] Can't start xpra session In-Reply-To: <5fac5f73-4a7e-bc6a-5888-308e22661066@cam.ac.uk> References: <9cd9fd8b-5d01-4ee3-f036-a2da69cba3cd@nagafix.co.uk> <5fac5f73-4a7e-bc6a-5888-308e22661066@cam.ac.uk> Message-ID: <95791a4d-fa39-50fa-b4cf-c1045c2a1b74@nagafix.co.uk> On 30/08/18 23:41, Anthony Stone wrote: > Antoine, > > Thanks for the suggestions. This is what happens: Please always keep the list CCed. > On 30/08/18 04:22, Antoine Martin via shifter-users wrote: >> Directly on the server (ie: via ssh), try to start the session locally: >> xpra start :100 --start="gnome-terminal --window-with-profile=Blue" > > 17:22:05 $ xpra start :100 --start="gnome-terminal > --window-with-profile=Blue" > 2018-08-30 17:22:46,020 server failure: disconnected before the session > could be established > 2018-08-30 17:22:46,020 server requested disconnect: server error > (failed to start a new session) > Warning: cannot use the system proxy for 'start' subcommand, > unknown general failure > more information may be available in your system log > > The system log contains the following. This seems to be an > authentication failure, but I don't know how to fix it. > > Aug 30 17:22:32 whirligig systemd[1]: Started Session 2509 of user ajs1. > Aug 30 17:22:32 whirligig xpra[1192]: reenter password for > pam_mount:(pam_mount.c:477): warning: could not obtain password > interactively either > Aug 30 17:22:32 whirligig xpra[1192]: reenter password for > pam_mount:(pam_mount.c:477): warning: could not obtain password > interactively either Here is what I think is happening: when we start a proper pam session via root (this is what the "starting via proxy" does), we go through the pam session configuration. Your OS seems to include "pam_mount" in there, and that seems to want to ask for a password to do its job. I have no idea why that is, or why it isn't failing more gracefully. > Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,475 Error: > pam_open_session failed: 6 > Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,476 > Permission denied > Aug 30 17:22:32 whirligig xpra[1192]: Entering daemon mode; any further > errors will be reported to: > Aug 30 17:22:32 whirligig xpra[1192]: /run/user/1013/xpra/:100.log > Aug 30 17:22:46 whirligig xpra[1192]: Error: failed to start server > subprocess: > Aug 30 17:22:46 whirligig xpra[1192]: failed to identify the new server > display! The easiest solution to this problem is to not use the proxy, set: start-via-proxy=no in your /etc/xpra/conf.d/60_server.conf On this subject, there seems to be so many ways that distributions manage to configure (break) pam sessions, and logind's KillUserProcesses still defaults to "no" after all these years, so future versions will revert to not using the system wide proxy by default. Those who want the features that require it will have to re-enable it. Cheers, Antoine From bsferrazza at avnera.com Thu Aug 30 19:05:00 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Thu, 30 Aug 2018 11:05:00 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: On Wed, Aug 29, 2018 at 9:06 PM Antoine Martin wrote: > On 30/08/18 07:15, shifter-users-owner at lists.devloop.org.uk wrote: > > Now that I've established a connection again with Xpra server 2.3.3, I > > can try to address some of the issues I was/am experiencing. I haven't > > used it enough to encounter the first two issues, which were the most > > debilitating and largely made it unusable for me before (the stuck focus > > issue and the disappearing mouse cursor). Once I can re-create those > > I'll have more to offer. > > > > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin > > wrote: > > > > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: > > > Hi. I'm including my previous correspondence below, as it will at > > least > > > offer some history about my setup and prior issues. > > > > > > I stopped using Xpra a few months ago due to numerous bugs that > > made it > > > unusable (this is using a Linux server and Windows client). > > > > > > 1. windows get stuck with on-top focus > > Which windows from which applications? > > > > > > This was by far the most egregious bug. It seemed to happen at random > > and affected all applications. Considering I do a lot of work in a > > terminal, chances are it was a terminal such as xfce4-terminal. I will > > report back once this occurs again. My only solution was to minimize the > > window, rather than simply clicking on another window to give it focus. > This does ring a bell, but I don't think I ever saw it myself. > https://xpra.org/trac/ticket/713 > https://xpra.org/trac/ticket/1381 > > This could be a platform specific bug (ie: affecting mswindows clients) > in which case the newer Python3 GTK3 builds may fare better. > Yes, those tickets describe the exact same behavior I'm experiencing (or at least was with Xpra 2.2) using the Windows client and Linux server. I'll give one of the Python3 builds a shot. Is there a particular build that you think would be the most stable (with the understanding that I likely need 2.4 and the paramiko ssh client given the tcsh issues I was experiencing)? > > > > 2. disappearing mouse cursor when using X11-only no-toolkit apps > > that use > > > inverted black mouse pointer after clicking on something > > Do you have a specific application we can use to reproduce the > problem? > > > > Unfortunately the application I encountered this issue with the most was > > Cadence's Simvision, a digital simulation waveform viewer that's part of > > their CAD/EDA software suite. The only observation I had was that it is > > an application which does not make use of a modern toolkit, such as GTK. > > Perhaps it's using Motif? When you click on a menu the mouse cursor > > inverts to a right-pointing black cursor, which is a cursor internal to > > the program and is not replaced by the client's cursor. That's when the > > menu items would disappear. I've attached a screenshot of it working, > > which required using an actual camera, as the inverted black cursor is > > not picked up by the Windows print screen function. > There were bugs in the cursor code on mswindows, including some fixed > quite recently, those could have caused the problems you describe - it > should now revert to the default cursor in case of failure. > OK that's great to hear. I'll keep an eye out to see if this bug occurs with the newer builds > > > > 3. some windows don't show window bar until resized (e.g. gvim > > always gets > > > placed in upper-left without window bar) > > Some applications do weird things with their geometry sometimes, > gvim is > > one of those. That said, I've just tried it and it worked fine and it > > does seem to request to be placed in the top left corner. > > Please provide more details so we can reproduce the window bar > problem. > > (ie: server os and version, gvim version, etc..) > > > > > > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra > > 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT > > 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior. > > It corrects itself once I do any resizing of the window (which must > > initiate a redraw event). Perhaps Xpra could force a redraw event after > > opening the window? > I bet it's not a redraw event but a window "configure notification" that > gvim is waiting for. If I can reproduce this, it should be fixable. We > can synthesize an event if needed. > What's the server version? CentOS 7.5? > Actually the primary machine I use it on is CentOS 5.11 (unfortunately needed apparently to support an older version of Cadence IC5). Though I did build an entirely bootstrapped toolchain on this machine, so its using the latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the latest versions binutils and gcc. Xpra and all of its dependencies were built against this toolchain. However, I did just run Xpra 2.3.3 on a CentOS 7 machine we have here at work and with that same version of Gvim (8.0.586) I experience the same issue of it going to the top left corner and not showing the title bar until the window is resized. > > > > 4. dialog box black bars (appears to be trying to add scrollbars?). > > Can you provide example applications we can use to reproduce the > > problem? > > I've never seen that anywhere except when X11 windows are smaller > than > > the minimal window size on mswindows, then we have to pad it with > > something. > > > > Perhaps that's all it is. > Sadly, it's not. From the screenshot you attached, this looks like a > different problem. > > > Certainly not a big deal, and just a cosmetic > > annoyance. I've attached an example of this issue from a dialog box that > > pops up using diffuse. Perhaps this would be too much work, but a > > slightly more pleasing visual than black bars would be to sample the > > color of the edge pixels and use this color (or an average of samples) > > to extend the window to the minimum size. > Fixing the problem might be easier. (it looks similar to the gvim > problem - the application gets the window geometry wrong) > Do you have a sample application I can use to reproduce it? > It was happening using diffuse (the graphical diff tool). If I'm comparing two files and edit one of them outside of diffuse, diffuse will pop up a dialog asking if you'd like to reload the file since it detected a change. That small dialog was showing the black borders. However, I'm not seeing the same issue again. Though there is another issue that could perhaps be masking this. For some reason, many of my GTK applications (diffuse, gvim, etc) are not using the window decorations and icons I have chosen when using Xpra. This was working just fine in Xpra 2.2, and the correct theme and icons are shown when I VNC into the same machine. Oddly enough, Emacs does use the correct decorations even with the latest Xpra. > > > > 5. windows are all blank (white) when returning into work after > > several > > > hours (requires restarting client) > > That's a known "feature" of some opengl drivers, they clear the video > > memory when the system goes into idle or suspended state. > > We try to detect that (slowing down the refresh rate) and then > refresh > > the screen when the session resumes, but that doesn't always fix > things. > > You should not need to restart the client: minimizing the windows and > > restoring them should be enough. > > Alternatively, turn off opengl in the client - the client performance > > will be much lower. > > > > > > OK, the next time this occurs I'll try to simply minimize the windows. > > > > > > > 6. flickering clipboard icon in systray > > That's a very obvious sign that something is not right and something > is > > constantly requesting the clipboard contents. This will cause > > unnecessary traffic and instability. Try to figure out what is > causing > > this and stop it. Usually, this is caused by clipboard managers or > other > > clipboard synchronization tools (synergy, virtualbox, etc). > > > > > > Hmm. I don't have anything running like that. No VNC session, > > VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly > > nothing is currently connected to it. It seems to flicker at a rate of > > once every 4 seconds or so. > OK, then it's not so bad that it will cause instability. > Some clipboard managers request the clipboard contents as soon as > they're available, swamping the system with clipboard events. > If you wish, you can confirm the rate of change by running the client > with: "--debug=clipboard" > > > It seems periodic, in the mathematical sense > > of the word. My PC at work is a standard issue Dell box. It has the > > typical Dell bloatware and some Symantec security software (not much > > control over this), but can't think of anything that could be > > potentially interfering with the clipboard. Any suggestions how to > > determine the cause? > Sorry, I don't know how. The API we use to interact with the clipboard > does not offer any information about the application which set or > queried the clipboard. Some third party tools may exist to monitor the > system at this level. > Is there a way to turn off the flickering, just to avoid the annoyance of it? Also, it seems the newer versions of Xpra place a small Xpra icon imposed on top of a window's regular icon. Is there a way to turn off this feature, as it's difficult for me to see the original icon, since it's resized smaller. Thanks, Ben From bsferrazza at avnera.com Thu Aug 30 19:20:12 2018 From: bsferrazza at avnera.com (Ben Sferrazza) Date: Thu, 30 Aug 2018 11:20:12 -0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: Tried the Python3 builds of the Xpra 2.4 Windows client and unfortunately it has a lot of graphics artifacts (ghosting when moving a terminal, some applications being completely washed out and illegible, etc). I'll continue to use the standard 2.4 build for the time being. On Thu, Aug 30, 2018 at 11:05 AM Ben Sferrazza wrote: > > > On Wed, Aug 29, 2018 at 9:06 PM Antoine Martin > wrote: > >> On 30/08/18 07:15, shifter-users-owner at lists.devloop.org.uk wrote: >> > Now that I've established a connection again with Xpra server 2.3.3, I >> > can try to address some of the issues I was/am experiencing. I haven't >> > used it enough to encounter the first two issues, which were the most >> > debilitating and largely made it unusable for me before (the stuck focus >> > issue and the disappearing mouse cursor). Once I can re-create those >> > I'll have more to offer. >> > >> > On Tue, Aug 28, 2018 at 8:42 PM Antoine Martin > > > wrote: >> > >> > On 29/08/18 03:23, Ben Sferrazza via shifter-users wrote: >> > > Hi. I'm including my previous correspondence below, as it will at >> > least >> > > offer some history about my setup and prior issues. >> > > >> > > I stopped using Xpra a few months ago due to numerous bugs that >> > made it >> > > unusable (this is using a Linux server and Windows client). >> > > >> > > 1. windows get stuck with on-top focus >> > Which windows from which applications? >> > >> > >> > This was by far the most egregious bug. It seemed to happen at random >> > and affected all applications. Considering I do a lot of work in a >> > terminal, chances are it was a terminal such as xfce4-terminal. I will >> > report back once this occurs again. My only solution was to minimize the >> > window, rather than simply clicking on another window to give it focus. >> This does ring a bell, but I don't think I ever saw it myself. >> https://xpra.org/trac/ticket/713 >> https://xpra.org/trac/ticket/1381 >> >> This could be a platform specific bug (ie: affecting mswindows clients) >> in which case the newer Python3 GTK3 builds may fare better. >> > > Yes, those tickets describe the exact same behavior I'm experiencing (or > at least was with Xpra 2.2) using the Windows client and Linux server. I'll > give one of the Python3 builds a shot. Is there a particular build that you > think would be the most stable (with the understanding that I likely need > 2.4 and the paramiko ssh client given the tcsh issues I was experiencing)? > > >> >> > > 2. disappearing mouse cursor when using X11-only no-toolkit apps >> > that use >> > > inverted black mouse pointer after clicking on something >> > Do you have a specific application we can use to reproduce the >> problem? >> > >> > Unfortunately the application I encountered this issue with the most was >> > Cadence's Simvision, a digital simulation waveform viewer that's part of >> > their CAD/EDA software suite. The only observation I had was that it is >> > an application which does not make use of a modern toolkit, such as GTK. >> > Perhaps it's using Motif? When you click on a menu the mouse cursor >> > inverts to a right-pointing black cursor, which is a cursor internal to >> > the program and is not replaced by the client's cursor. That's when the >> > menu items would disappear. I've attached a screenshot of it working, >> > which required using an actual camera, as the inverted black cursor is >> > not picked up by the Windows print screen function. >> There were bugs in the cursor code on mswindows, including some fixed >> quite recently, those could have caused the problems you describe - it >> should now revert to the default cursor in case of failure. >> > > OK that's great to hear. I'll keep an eye out to see if this bug occurs > with the newer builds > > >> >> > > 3. some windows don't show window bar until resized (e.g. gvim >> > always gets >> > > placed in upper-left without window bar) >> > Some applications do weird things with their geometry sometimes, >> gvim is >> > one of those. That said, I've just tried it and it worked fine and >> it >> > does seem to request to be placed in the top left corner. >> > Please provide more details so we can reproduce the window bar >> problem. >> > (ie: server os and version, gvim version, etc..) >> > >> > >> > This isn't a showstopper. I'm using gvim 8.0.586 with the latest Xpra >> > 2.3.3 on Linux l-server-13 2.6.18-398.el5 #1 SMP Tue Sep 16 20:50:52 EDT >> > 2014 x86_64 GNU/Linux. I've attached a screenshot showing this behavior. >> > It corrects itself once I do any resizing of the window (which must >> > initiate a redraw event). Perhaps Xpra could force a redraw event after >> > opening the window? >> I bet it's not a redraw event but a window "configure notification" that >> gvim is waiting for. If I can reproduce this, it should be fixable. We >> can synthesize an event if needed. >> What's the server version? CentOS 7.5? >> > > Actually the primary machine I use it on is CentOS 5.11 (unfortunately > needed apparently to support an older version of Cadence IC5). Though I did > build an entirely bootstrapped toolchain on this machine, so its using the > latest glibc (2.19) for the older kernel it uses (2.6.18), as well as the > latest versions binutils and gcc. Xpra and all of its dependencies were > built against this toolchain. However, I did just run Xpra 2.3.3 on a > CentOS 7 machine we have here at work and with that same version of Gvim > (8.0.586) I experience the same issue of it going to the top left corner > and not showing the title bar until the window is resized. > > >> >> > > 4. dialog box black bars (appears to be trying to add >> scrollbars?). >> > Can you provide example applications we can use to reproduce the >> > problem? >> > I've never seen that anywhere except when X11 windows are smaller >> than >> > the minimal window size on mswindows, then we have to pad it with >> > something. >> > >> > Perhaps that's all it is. >> Sadly, it's not. From the screenshot you attached, this looks like a >> different problem. >> >> > Certainly not a big deal, and just a cosmetic >> > annoyance. I've attached an example of this issue from a dialog box that >> > pops up using diffuse. Perhaps this would be too much work, but a >> > slightly more pleasing visual than black bars would be to sample the >> > color of the edge pixels and use this color (or an average of samples) >> > to extend the window to the minimum size. >> Fixing the problem might be easier. (it looks similar to the gvim >> problem - the application gets the window geometry wrong) >> Do you have a sample application I can use to reproduce it? >> > > It was happening using diffuse (the graphical diff tool). If I'm comparing > two files and edit one of them outside of diffuse, diffuse will pop up a > dialog asking if you'd like to reload the file since it detected a change. > That small dialog was showing the black borders. However, I'm not seeing > the same issue again. Though there is another issue that could perhaps be > masking this. For some reason, many of my GTK applications (diffuse, gvim, > etc) are not using the window decorations and icons I have chosen when > using Xpra. This was working just fine in Xpra 2.2, and the correct theme > and icons are shown when I VNC into the same machine. Oddly enough, Emacs > does use the correct decorations even with the latest Xpra. > > >> >> > > 5. windows are all blank (white) when returning into work after >> > several >> > > hours (requires restarting client) >> > That's a known "feature" of some opengl drivers, they clear the >> video >> > memory when the system goes into idle or suspended state. >> > We try to detect that (slowing down the refresh rate) and then >> refresh >> > the screen when the session resumes, but that doesn't always fix >> things. >> > You should not need to restart the client: minimizing the windows >> and >> > restoring them should be enough. >> > Alternatively, turn off opengl in the client - the client >> performance >> > will be much lower. >> > >> > >> > OK, the next time this occurs I'll try to simply minimize the windows. >> > >> > >> > > 6. flickering clipboard icon in systray >> > That's a very obvious sign that something is not right and >> something is >> > constantly requesting the clipboard contents. This will cause >> > unnecessary traffic and instability. Try to figure out what is >> causing >> > this and stop it. Usually, this is caused by clipboard managers or >> other >> > clipboard synchronization tools (synergy, virtualbox, etc). >> > >> > >> > Hmm. I don't have anything running like that. No VNC session, >> > VirtualBox, etc. Microsoft's Remote Desktop is enabled, but certainly >> > nothing is currently connected to it. It seems to flicker at a rate of >> > once every 4 seconds or so. >> OK, then it's not so bad that it will cause instability. >> Some clipboard managers request the clipboard contents as soon as >> they're available, swamping the system with clipboard events. >> If you wish, you can confirm the rate of change by running the client >> with: "--debug=clipboard" >> >> > It seems periodic, in the mathematical sense >> > of the word. My PC at work is a standard issue Dell box. It has the >> > typical Dell bloatware and some Symantec security software (not much >> > control over this), but can't think of anything that could be >> > potentially interfering with the clipboard. Any suggestions how to >> > determine the cause? >> Sorry, I don't know how. The API we use to interact with the clipboard >> does not offer any information about the application which set or >> queried the clipboard. Some third party tools may exist to monitor the >> system at this level. >> > > Is there a way to turn off the flickering, just to avoid the annoyance of > it? Also, it seems the newer versions of Xpra place a small Xpra icon > imposed on top of a window's regular icon. Is there a way to turn off this > feature, as it's difficult for me to see the original icon, since it's > resized smaller. > > Thanks, > Ben > From antoine at nagafix.co.uk Fri Aug 31 10:06:07 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 31 Aug 2018 16:06:07 +0700 Subject: [winswitch] Xpra GL and gtkglext woes In-Reply-To: References: Message-ID: <1581983f-df8e-a3de-3cff-7fea4088435c@nagafix.co.uk> On 31/08/18 01:20, Ben Sferrazza wrote: > Tried the Python3 builds of the Xpra 2.4 Windows client and > unfortunately it has a lot of graphics artifacts (ghosting when moving a > terminal, some applications being completely washed out and illegible, > etc). I'll continue to use the standard 2.4 build for the time being. Oh! The GTK3 port is meant to be almost complete... (at least for the client, the server will need a lot more work) This could be because of transparency issues. (I have no idea why a terminal applications would use an alpha channel but some do..) Was this with xfce_terminal again? Did you have OpenGL enabled or disabled? (see systray menu toggle) > > This was by far the most egregious bug. It seemed to happen at > random > > and affected all applications. (..) > This does ring a bell, but I don't think I ever saw it myself. > https://xpra.org/trac/ticket/713 > https://xpra.org/trac/ticket/1381 > > This could be a platform specific bug (ie: affecting mswindows > clients) > in which case the newer Python3 GTK3 builds may fare better. > > > Yes, those tickets describe the exact same behavior I'm experiencing > (or at least was with Xpra 2.2) using the Windows client and Linux > server. I'll give one of the Python3 builds a shot. Is there a > particular build that you think would be the most stable (with the > understanding that I likely need 2.4 and the paramiko ssh client > given the tcsh issues I was experiencing)? Usually the latest, especially if you need the paramiko goodness. (though I have had to revert some unrelated changes today) > >? ? ?> 3. some windows don't show window bar until resized > (e.g. gvim > >? ? ?always gets > >? ? ?> placed in upper-left without window bar) (..) > Actually the primary machine I use it on is CentOS 5.11 > (unfortunately needed apparently to support an older version of > Cadence IC5). Though I did build an entirely bootstrapped toolchain > on this machine, so its using the latest glibc (2.19) for the older > kernel it uses (2.6.18), as well as the latest versions binutils and > gcc. Xpra and all of its dependencies were built against this > toolchain. Wow. That's a *lot* of work! Have you considered installing a CentOS 5 chroot inside a CentOS 7 host and just sharing the X11 display between the two? (ie: /tmp/.X11-unix/X100) > However, I did just run Xpra 2.3.3 on a CentOS 7 machine > we have here at work and with that same version of Gvim (8.0.586) I > experience the same issue of it going to the top left corner and not > showing the title bar until the window is resized. Will test and report back. > >? ? ?> 4. dialog box black bars (appears to be trying to add > scrollbars?). (..) > Do you have a sample application I can use to reproduce it? > It was happening using diffuse (the graphical diff tool). If I'm > comparing two files and edit one of them outside of diffuse, diffuse > will pop up a dialog asking if you'd like to reload the file since > it detected a change. That small dialog was showing the black > borders. However, I'm not seeing the same issue again. Though there > is another issue that could perhaps be masking this. For some > reason, many of my GTK applications (diffuse, gvim, etc) are not > using the window decorations and icons I have chosen when using > Xpra. How and where did you modify these settings? > This was working just fine in Xpra 2.2, and the correct theme > and icons are shown when I VNC into the same machine. Oddly enough, > Emacs does use the correct decorations even with the latest Xpra. Ah, the everlasting joy of themes and xsettings. You may want to try --xsettings=no (..) > >? ? ?> 6. flickering clipboard icon in systray > Is there a way to turn off the flickering, just to avoid the > annoyance of it? There is now, in 2.4: http://xpra.org/trac/changeset/20251 To use it: XPRA_CLIPBOARD_NOTIFY=0 xpra attach ... > Also, it seems the newer versions of Xpra place a > small Xpra icon imposed on top of a window's regular icon. Is there > a way to turn off this feature, as it's difficult for me to see the > original icon, since it's resized smaller. This should turn it off: XPRA_ICON_OVERLAY=0 xpra attach ... More details on the feature here: http://xpra.org/trac/ticket/1707 Cheers, Antoine From ajs1 at cam.ac.uk Fri Aug 31 10:10:31 2018 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Fri, 31 Aug 2018 10:10:31 +0100 Subject: [winswitch] Can't start xpra session In-Reply-To: <95791a4d-fa39-50fa-b4cf-c1045c2a1b74@nagafix.co.uk> References: <9cd9fd8b-5d01-4ee3-f036-a2da69cba3cd@nagafix.co.uk> <5fac5f73-4a7e-bc6a-5888-308e22661066@cam.ac.uk> <95791a4d-fa39-50fa-b4cf-c1045c2a1b74@nagafix.co.uk> Message-ID: <7989c5d4-6ce6-35d4-5b74-1c55981a1358@cam.ac.uk> Antoine, As recommended, I have set start-via-proxy=no in /etc/xpra/conf.d/60_server.conf (and restarted the server) and xpra now starts normally. Many thanks for the prompt and helpful advice. Anthony On 30/08/18 18:13, Antoine Martin wrote: > On 30/08/18 23:41, Anthony Stone wrote: >> Antoine, >> >> Thanks for the suggestions. This is what happens: > Please always keep the list CCed. > >> On 30/08/18 04:22, Antoine Martin via shifter-users wrote: >>> Directly on the server (ie: via ssh), try to start the session locally: >>> xpra start :100 --start="gnome-terminal --window-with-profile=Blue" >> >> 17:22:05 $ xpra start :100 --start="gnome-terminal >> --window-with-profile=Blue" >> 2018-08-30 17:22:46,020 server failure: disconnected before the session >> could be established >> 2018-08-30 17:22:46,020 server requested disconnect: server error >> (failed to start a new session) >> Warning: cannot use the system proxy for 'start' subcommand, >> unknown general failure >> more information may be available in your system log >> >> The system log contains the following. This seems to be an >> authentication failure, but I don't know how to fix it. >> >> Aug 30 17:22:32 whirligig systemd[1]: Started Session 2509 of user ajs1. >> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >> pam_mount:(pam_mount.c:477): warning: could not obtain password >> interactively either >> Aug 30 17:22:32 whirligig xpra[1192]: reenter password for >> pam_mount:(pam_mount.c:477): warning: could not obtain password >> interactively either > Here is what I think is happening: when we start a proper pam session > via root (this is what the "starting via proxy" does), we go through the > pam session configuration. > Your OS seems to include "pam_mount" in there, and that seems to want to > ask for a password to do its job. > I have no idea why that is, or why it isn't failing more gracefully. > >> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,475 Error: >> pam_open_session failed: 6 >> Aug 30 17:22:32 whirligig xpra[1192]: 2018-08-30 17:22:32,476 >> Permission denied >> Aug 30 17:22:32 whirligig xpra[1192]: Entering daemon mode; any further >> errors will be reported to: >> Aug 30 17:22:32 whirligig xpra[1192]: /run/user/1013/xpra/:100.log >> Aug 30 17:22:46 whirligig xpra[1192]: Error: failed to start server >> subprocess: >> Aug 30 17:22:46 whirligig xpra[1192]: failed to identify the new server >> display! > The easiest solution to this problem is to not use the proxy, set: > start-via-proxy=no > in your /etc/xpra/conf.d/60_server.conf > > On this subject, there seems to be so many ways that distributions > manage to configure (break) pam sessions, and logind's KillUserProcesses > still defaults to "no" after all these years, so future versions will > revert to not using the system wide proxy by default. > Those who want the features that require it will have to re-enable it. > > Cheers, > Antoine >