[winswitch] Xpra GL and gtkglext woes

[Ben Sferrazza]

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': <subprocess.Popen object at
> > 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.