Python3 tracker ticket: #1568.
Eventually, we will have to convert the server code to py3k... Which is going to be a pain, probably even worse than #90.
We should probably move away from GTK at that point too, and replace all the pygobject plumbing with something a bit simpler and faster.
This ticket is here to record all the things that will need to be done to make this happen.
Apart from the usual string vs unicode nonsense, we will have to deal with the borken change they made to dict items vs iteritems in version 3: we rely on the fact that items() makes a copy, which is no longer true, we can probably switch to viewkeys() for most cases - except that this is python 2.7 only... so we'll need to drop support for 2.6 before that (ie: all centos 6).
Socket fixes for running the proxy server with python3: r17410. It still fails shortly after:
Exception in thread new-tcp-connection: Traceback (most recent call last): File "/usr/lib64/python3.6/threading.py", line 916, in _bootstrap_inner self.run() File "/usr/lib64/python3.6/threading.py", line 864, in run self._target(*self._args, **self._kwargs) File "/usr/lib64/python3.6/site-packages/xpra/server/server_core.py", line 861, in handle_new_connection sock.settimeout(self._socket_timeout) OSError: [Errno 9] Bad file descriptor
Very relevant discussion: How to create a socket.socket() object from a socket fd?. Python3 does this:
def fromfd(fd, family, type, proto=0): """ fromfd(fd, family, type[, proto]) -> socket object Create a socket object from a duplicate of the given file descriptor. The remaining arguments are the same as for socket(). """ nfd = dup(fd) return socket(family, type, proto, nfd)
But do we want this fd to be dup-ed here?
The desktop server (
start-desktop) now runs OK, the seamless server still needs work (crashes hard).
gtk.NO_WINDOW) - still works!?
Still crashes hard when we close any window - simplified gdb backtrace:
#5 0x00007fffee190f83 in gdk_x_error (xdisplay=0x555555ab8030, error=0x7fffffff9c40) at gdkmain-x11.c:307 #11 0x00007fffee154da4 in gdk_flush () at gdkdisplay.c:598 #60 0x00007fffee18b39f in gdk_event_apply_filters (xevent=xevent@entry=0x7fffffffba70, event=event@entry=0x5555567ec200, window=window@entry=0x0) at gdkeventsource.c:79 #65 0x00007fffee7b726d in g_main_context_dispatch () at /lib64/libglib-2.0.so.0 #68 0x00007fffed4f3b5d in gtk_main () at gtkmain.c:1323
Something is not right with our gdk event filter - same code runs fine with GTK2..
Some documentation that may be helpful:
Not sure we want to use those functions as this will tie us with Gdk more, not less.
I think r20770 broke python2 functionaility. 1st login gives a server error:
2018-10-31 11:50:51,843 start_server_subprocess failed Traceback (most recent call last): File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", line 289, in proxy_session proc, socket_path, display = self.start_new_session(username, uid, gid, sns, displays) File "/usr/lib64/python2.7/site-packages/xpra/server/proxy/proxy_server.py", line 462, in start_new_session proc, socket_path, display = start_server_subprocess(sys.argv, args, mode, opts, username, uid, gid, env, cwd) File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 1768, in start_server_subprocess buf = read_displayfd(r_pipe, proc=None) #proc deamonizes! File "/usr/lib64/python2.7/site-packages/xpra/platform/displayfd.py", line 49, in read_displayfd if e.errno!=errno.EINTR: AttributeError: 'error' object has no attribute 'errno' 2018-10-31 11:50:51,844 Error: failed to start server subprocess: 2018-10-31 11:50:51,845 'error' object has no attribute 'errno' 2018-10-31 11:50:51,845 disconnect(server error, ('failed to start a new session',))
2nd login is successful.
@mjharkin: thanks for the report, r20887 should fix this.
Yes, fixed in r20887. Thanks.
r21729 fixes the keyboard setup code - probably more fixes needed here to support keycode translation (stoopid bytes vs strings in python3)
This is ready for release. It should be on par with the python2 server.
Regression with dbus: #2181
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/853