From bodo.martin at aci.uni-heidelberg.de Mon Mar 6 18:30:20 2017 From: bodo.martin at aci.uni-heidelberg.de (Bodo Martin) Date: Mon, 6 Mar 2017 19:30:20 +0100 Subject: [winswitch] forwarding a X11 window with child windows Message-ID: <10b2da9c-1083-1a8c-700e-4cad95bc5900@aci.uni-heidelberg.de> Hi is it possible to forward a X11 window with children to the client? - or rather, reparent with XReparentWindow two remote windows (already forwarded via xpra ? This works for e.g. a ssh session (for non-GL windows) but crashes with xpra. (setup: xpra 1.0.2, linux to linux , via ssh ) From antoine at nagafix.co.uk Tue Mar 7 15:00:32 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 7 Mar 2017 22:00:32 +0700 Subject: [winswitch] forwarding a X11 window with child windows In-Reply-To: <10b2da9c-1083-1a8c-700e-4cad95bc5900@aci.uni-heidelberg.de> References: <10b2da9c-1083-1a8c-700e-4cad95bc5900@aci.uni-heidelberg.de> Message-ID: On 07/03/17 01:30, Bodo Martin via shifter-users wrote: > > Hi > > is it possible to forward a X11 window with children to the client? - or > rather, reparent with XReparentWindow two remote windows (already > forwarded via xpra ? I don't see why it wouldn't work: the xpra client is just another X11 client application. > This works for e.g. a ssh session (for non-GL > windows) but crashes with xpra. (setup: xpra 1.0.2, linux to linux , via > ssh ) What crashes exactly? xpra or something else? I'm not sure why GL would make much of a difference here, but you can try turning it off with "--opengl=no" Do you have a reproducible test case I can try? Cheers Antoine From bodo.martin at aci.uni-heidelberg.de Tue Mar 7 20:59:32 2017 From: bodo.martin at aci.uni-heidelberg.de (Bodo Martin) Date: Tue, 7 Mar 2017 21:59:32 +0100 Subject: [winswitch] forwarding a X11 window with child windows In-Reply-To: References: <10b2da9c-1083-1a8c-700e-4cad95bc5900@aci.uni-heidelberg.de> Message-ID: <7a4e3c5c-b106-08d8-d590-c9b089f1535c@aci.uni-heidelberg.de> >Am 07.03.2017 um 16:00 schrieb Antoine Martin via shifter-users: > On 07/03/17 01:30, Bodo Martin via shifter-users wrote: >> >> Hi >> >> is it possible to forward a X11 window with children to the client? - or >> rather, reparent with XReparentWindow two remote windows (already >> forwarded via xpra ? > I don't see why it wouldn't work: the xpra client is just another X11 > client application. > >> This works for e.g. a ssh session (for non-GL >> windows) but crashes with xpra. (setup: xpra 1.0.2, linux to linux , via >> ssh ) > What crashes exactly? xpra or something else? > I'm not sure why GL would make much of a difference here, but you can > try turning it off with "--opengl=no" > Do you have a reproducible test case I can try? ok, here is a minimal test program: --- snip --- // modfied from: // Ch. Tronche (http://tronche.lri.fr:8000/) #include #include #include #define NIL (0) int main() { Display *dpy = XOpenDisplay(NIL); assert(dpy); int blackColor = BlackPixel(dpy, DefaultScreen(dpy)); int whiteColor = WhitePixel(dpy, DefaultScreen(dpy)); // Create the window Window w = XCreateSimpleWindow(dpy, DefaultRootWindow(dpy), 0, 0, 250, 150, 0, blackColor, blackColor); XSelectInput(dpy, w, StructureNotifyMask); XMapWindow(dpy, w); XFlush(dpy); // Wait for the MapNotify event for(;;) { XEvent e; XNextEvent(dpy, &e); if (e.type == MapNotify) break; } Window child = XCreateSimpleWindow(dpy, /*w*/ DefaultRootWindow(dpy) , 0, 0, 200, 100, 0, whiteColor, whiteColor); XSelectInput(dpy, child, StructureNotifyMask); XMapWindow(dpy, child); // Wait for the MapNotify event for(;;) { XEvent e; XNextEvent(dpy, &e); if (e.type == MapNotify) break; } XFlush(dpy); // reparent (to x,y does not work, not processing events) XReparentWindow(dpy, child, w, 0, 0 ); XFlush(dpy); XSync(dpy,true); sleep(100); } --- snip --- reparenting a white window into a black one. This works both locally and over an ssh connection, but not with xpra (no white window in the black one shown). (The crash I was referring to happens when I try to reparent the winIDs from the parentID of the session, giving me different winIDs , which may not be a good idea) Cheers Bodo -- Dr. Bodo Martin University Heidelberg Anorganisch-Chemisches Institut Im Neuenheimer Feld 270 69120 Heidelberg Germany Phone: +49-6221-546610 Fax: +49-6221-546617 Web: http://bodomartin.uni-hd.de From antoine at nagafix.co.uk Fri Mar 10 14:28:51 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 10 Mar 2017 21:28:51 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0.4 LTS : many fixes, some critical Message-ID: <12a9587c-1862-a1e1-7763-862f2d26e1b9@nagafix.co.uk> Hi, This update fixes a large number of bugs, some of which are critical. The most critical fix is for a regression in the 1.0 branch which can cause the whole server to abort. The overly zealous memory barrier added in 1.0.3 turned out to be a false alarm and has been reverted. The rest of the fixes are all over the codebase: platform fixes and updates, html5 client, dbus handling, system tray, etc. Release notes: * fix info queries causing server crashes * fix unguarded access to X11 functions * fix quality and speed values skewed by locked batch delay * fix csc libyuv packaging on Mac OS * fix dbus import failures causing fatal error * fix gtk menu dbus error handler * fix Gdk import warnings * fix shared socket creation failures causing fatal error * fix multi-monitor wheel scroll offset on MS Windows * fix client paint failures with very small CSC sizes * fix unlikely encoding selection error with rgb strict mode * fix connection errors when an invalid sharing option is used * fix speed setting not updated when batch delay is locked * fix environment variable name used for disabling X11 bindings * fix some glib timer warnings, clear them after use * fix printer forwarding with Mac OS shadow servers (partial) * fix Mac OS workarea calculations * fix missing header file from setuptools source archives * fix audio forwarding errors on some Linux distributions * fix errors with xvfb not supporting XShm * fix error in scrolling detection fallback case * fix race condition in scrolling detection code causing artifacts * fix systray geometry issues on some distributions (not responding to clicks) * fix some inaccessible drop down menus with Mac OS clients * fix HTML5 client failing to acknowledge paint packets * fix HTML5 client capslock state detection * remove HTML5 client unnecessary debug logging * safer dbus cleanup code * honour "show upload" option in Mac OS application menu * Mac OS menu shows "Disconnect" instead of "Quit", "Xpra" instead of "Launcher" * Mac OS modules update: sshpass, opus, numpy, python-xxhash, lzo * deiconify windows when they get mapped (more correct) * restore software mp3 decoding in HTML5 client * revert overly zealous memory access barrier * run uninstaller before install on MS Windows The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine From martin at insulander.info Thu Mar 16 09:10:27 2017 From: martin at insulander.info (Martin Insulander) Date: Thu, 16 Mar 2017 10:10:27 +0100 Subject: [winswitch] Xpra "run command" from command line Message-ID: Hi, I have a question about Xpra. What is the best way to launch applications in a running xpra session from command line? It would be great to be able to call the xpra run command (something like >>xpra control --start=xterm). Currently I run ssh into the server, find out current xpra session display number and launch the program. Cumbersome and error prone. thanks for xpra and answers from Martin Insulander From antoine at nagafix.co.uk Thu Mar 16 09:50:21 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 16 Mar 2017 16:50:21 +0700 Subject: [winswitch] Xpra "run command" from command line In-Reply-To: References: Message-ID: <97b7de79-d3ce-a44c-bdaf-93e2f824ca81@nagafix.co.uk> On 16/03/17 16:10, Martin Insulander via shifter-users wrote: > Hi, > > I have a question about Xpra. > > What is the best way to launch applications in a running xpra session from > command line? > > It would be great to be able to call the xpra run command (something like >>> xpra control --start=xterm). You were close. Try this instead: xpra control :DISPLAY start "THECOMMAND" For more general information about control subcommands, try: xpra control :DISPLAY help Then there is also (limited) information about each subcommand: xpra control :DISPLAY help start When already connected with the client, you can also start new commands directly from the client's system tray if the server has enabled the "start-new-commands" option. (which is disabled by default) Cheers Antoine > > Currently I run ssh into the server, find out current xpra session display > number and launch the program. Cumbersome and error prone. > > thanks for xpra and answers from Martin Insulander > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From martin at insulander.info Fri Mar 17 12:52:22 2017 From: martin at insulander.info (Martin Insulander) Date: Fri, 17 Mar 2017 13:52:22 +0100 Subject: [winswitch] Xpra "run command" from command line Message-ID: Thank you *Antoine*, works perfect. Now I only have to make sure no user is starting multiple sessions so xpra can autoselect it ;) Best regards from Martin Insulander From antoine at nagafix.co.uk Fri Mar 17 14:12:06 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 17 Mar 2017 21:12:06 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.0 Message-ID: <8cd59b02-a217-5727-59f6-37c77a867ff7@nagafix.co.uk> Hi, This release finally drops compatibility with many outdated libraries and operating systems so we can streamline the code, use newer technologies and better prepare for the future. The following systems are no longer supported: Windows XP and Vista, Mac OSX versions older than 10.9, Debian Squeeze and Wheezy, Ubuntu Precise and Trusty, CentOS 6.x, 7.0 and 7.1, Python 2.6, GStreamer 0.10, pycrypto, older versions of Pillow and PyOpenGL, etc.. A number of our less useful codecs have been removed. There aren't many new features, the ones that most noteworthy are: * Drastically improved build systems for MS Windows and Mac OSX. In particular: 64-bit installers, the MS Windows builds are now based on clean and fully up to date libraries thanks to the MSYS2 project. * HTML5 client improvements, including clipboard synchronization. * multiple / deep colour support in both client and server: for example you can now shadow 8-bit displays and render deep colour with the OpenGL client. For more detailed information, including links to the documentation and tickets, see: http://xpra.org/trac/wiki/News#a2.0ImportantFeatures The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine From timothyhobbs at seznam.cz Fri Mar 17 17:20:05 2017 From: timothyhobbs at seznam.cz (Timothy Hobbs) Date: Fri, 17 Mar 2017 18:20:05 +0100 Subject: [winswitch] Dynamically variable DPI? Message-ID: <15da4c77-2c4c-5c44-940a-9a32ea0bbded@seznam.cz> Hi, I'm using xpra+subuser for most things now. It works well, except for full screen videos on my high-dpi display, which don't play well at all. All of this is local, and as far as I know, I have compression turned off and memmapping turned on... If I play the videos in non-fullscreen mode then they play fine. It seems to me that since youtube videos aren't actually high dpi anyways, then there shouldn't be a difference between how well they play in non-fullscreen mode and how well they play full screen. Would it be technically possible for xpra to detect that it is being slow, and to automatically start passing a lower dpi version of the window contents? I don't know if that's crazy or not, as I don't know how xpra internals work... Tim From antoine at nagafix.co.uk Fri Mar 17 18:01:13 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 18 Mar 2017 01:01:13 +0700 Subject: [winswitch] Dynamically variable DPI? In-Reply-To: <15da4c77-2c4c-5c44-940a-9a32ea0bbded@seznam.cz> References: <15da4c77-2c4c-5c44-940a-9a32ea0bbded@seznam.cz> Message-ID: <13c7a479-f15f-37d5-925b-0c5e865a007d@nagafix.co.uk> On 18/03/17 00:20, Timothy Hobbs via shifter-users wrote: > Hi, > > I'm using xpra+subuser for most things now. It works well, except for > full screen videos on my high-dpi display, which don't play well at all. > All of this is local, and as far as I know, I have compression turned > off and memmapping turned on... mmap transfers should be able to handle fullscreen at high resolutions without problems if you have enough CPU, memory bandwidth and use the client with OpenGL enabled. > If I play the videos in non-fullscreen > mode then they play fine. It seems to me that since youtube videos > aren't actually high dpi anyways, then there shouldn't be a difference > between how well they play in non-fullscreen mode and how well they play > full screen. You would think that... except that the browser will render at the resolution requested by the client, and we will grab the pixels and forward them at that resolution, which can be expensive. (there are ways to capture the video at its original unscaled size, but this has not been implemented yet) > Would it be technically possible for xpra to detect that it > is being slow, and to automatically start passing a lower dpi version of > the window contents? I don't know if that's crazy or not, as I don't > know how xpra internals work... This feature already exists but it isn't enabled with mmap, as it should not be needed in this case. Here it is from the man page: --video-scaling=on|off|SCALING How much automatic video downscaling should be used, from 1 (rarely) to 100 (aggressively), 0 to disable. Video scaling is normally used with video regions or very large windows (especially full screen windows) to try to maintain a decent framerate. Video downscaling negatively affects visual quality and will cause automatic refreshes (if enabled), it is most useful on video content where it saves a considerable amount of bandwidth. Cheers Antoine > > Tim > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From timothy at hobbs.cz Fri Mar 17 22:34:12 2017 From: timothy at hobbs.cz (Timothy Hobbs) Date: Fri, 17 Mar 2017 23:34:12 +0100 Subject: [winswitch] Why use user provided log file only when display_name is set? Message-ID: <9705b884-7ed8-32f6-910e-e444a2904504@hobbs.cz> Hi, I'm reading the xpra code now, and I don't understand the following condition: 668 def select_log_file(log_dir, log_file, display_name): 669 """ returns the log file path we should be using given the parameters, 670 this may return a temporary logpath if display_name is not available. 671 """ 672 if log_file and display_name: 673 if os.path.isabs(log_file): 674 logpath = log_file 675 else: 676 logpath = os.path.join(log_dir, log_file) 677 logpath = shellsub(logpath, {"DISPLAY" : display_name}) 678 elif display_name: 679 logpath = norm_makepath(log_dir, display_name) + ".log" 680 else: 681 logpath = os.path.join(log_dir, "tmp_%d.log" % os.getpid()) 682 return logpath https://www.xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py#L672 On line 672 the condition is that display_name must be set in order for the user set log_file option to be used. However, looking at the code, I see no reason for this to be the case. So why is it needed? Why not just 672 if log_file: 673 if os.path.isabs(log_file): 674 logpath = log_file .... Regards, Timothy Hobbs From antoine at nagafix.co.uk Sat Mar 18 05:37:47 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 18 Mar 2017 12:37:47 +0700 Subject: [winswitch] Why use user provided log file only when display_name is set? In-Reply-To: <9705b884-7ed8-32f6-910e-e444a2904504@hobbs.cz> References: <9705b884-7ed8-32f6-910e-e444a2904504@hobbs.cz> Message-ID: <06aee6b8-217d-26fc-df5a-18f87feadf26@nagafix.co.uk> On 18/03/17 05:34, Timothy Hobbs via shifter-users wrote: > Hi, > > I'm reading the xpra code now, and I don't understand the following > condition: > > 668 def select_log_file(log_dir, log_file, display_name): > 669 """ returns the log file path we should be using given the > parameters, > 670 this may return a temporary logpath if display_name is > not available. > 671 """ > 672 if log_file and display_name: > 673 if os.path.isabs(log_file): > 674 logpath = log_file > 675 else: > 676 logpath = os.path.join(log_dir, log_file) > 677 logpath = shellsub(logpath, {"DISPLAY" : display_name}) > 678 elif display_name: > 679 logpath = norm_makepath(log_dir, display_name) + ".log" > 680 else: > 681 logpath = os.path.join(log_dir, "tmp_%d.log" % os.getpid()) > 682 return logpath > > https://www.xpra.org/trac/browser/xpra/trunk/src/xpra/scripts/server.py#L672 > > > On line 672 the condition is that display_name must be set in order for > the user set log_file option to be used. However, looking at the code, I > see no reason for this to be the case. So why is it needed? We're trying to avoid using a log filename which has "${DISPLAY}" in it since it would get substituted with "None" until we actually have the display name available. This would be a bad thing because it would make the code racy if you tried to start two servers at the same time. Some links that may be relevant since you're looking at this code: * original displayfd feature patch review: http://xpra.org/trac/ticket/172#comment:15 * Xorg 1.18.1 log file renaming bug (upstream, unfixed): http://xpra.org/trac/ticket/1192 https://bugs.freedesktop.org/show_bug.cgi?id=95234 Cheers Antoine If anything, this would be more correct to apply (untested). If you can review this and it works, it should be safe to apply: =================================================================== --- xpra/scripts/server.py (revision 15316) +++ xpra/scripts/server.py (working copy) @@ -669,13 +669,16 @@ """ returns the log file path we should be using given the parameters, this may return a temporary logpath if display_name is not available. """ - if log_file and display_name: + if log_file: if os.path.isabs(log_file): logpath = log_file else: logpath = os.path.join(log_dir, log_file) - logpath = shellsub(logpath, {"DISPLAY" : display_name}) - elif display_name: + v = shellsub(logpath, {"DISPLAY" : display_name}) + if display_name or v==logpath: + #we have 'display_name', or we just don't need it: + return v + if display_name: logpath = norm_makepath(log_dir, display_name) + ".log" else: logpath = os.path.join(log_dir, "tmp_%d.log" % os.getpid()) > > Why not just > > 672 if log_file: > 673 if os.path.isabs(log_file): > 674 logpath = log_file > .... > > > Regards, > > Timothy Hobbs > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From ajs1 at cam.ac.uk Sat Mar 18 12:36:01 2017 From: ajs1 at cam.ac.uk (Anthony Stone) Date: Sat, 18 Mar 2017 12:36:01 +0000 Subject: [winswitch] xpra and PyOpenGL Message-ID: <8693981c-3115-0101-7df2-a465700d7445@cam.ac.uk> Hello, I have just installed PyOpenGL-accelerate (I was using xpra without it before) and I now get the error message below. xpra completes the startup and is usable, but I would like to have OpenGL working. Is this a known problem? Is it a bug or a problem with my setup? I have only been using xpra for a few weeks so I'm not familiar with its workings. I'm running xpra 1.04 under Ubuntu 16.04 to connect to a remote desktop machine running the same version of xpra under Ubuntu 14.04. Thanks, Anthony $ xpra start ssh:whirligig --start=gnome-terminal & [1] 13911 $ 2017-03-17 16:29:48,190 Xpra gtk2 client version 1.0.4-r15266 64-bit 2017-03-17 16:29:48,190 running on Linux Ubuntu 16.04 xenial 2017-03-17 16:29:48,191 Warning: failed to import opencv: 2017-03-17 16:29:48,191 No module named cv2 2017-03-17 16:29:48,191 webcam forwarding is disabled 2017-03-17 16:29:48,505 GStreamer version 1.8.3 for Python 2.7.12 64-bit 2017-03-17 16:29:48,747 OpenGL_accelerate module loaded 2017-03-17 16:29:48,748 Error loading OpenGL support: 2017-03-17 16:29:48,748 __init__() takes at least 2 positional arguments (1 given) Traceback (most recent call last): File "/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py", line 663, in init_opengl self.opengl_props = gl_check.check_support(force_enable=(enable_opengl is True)) File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", line 527, in check_support gl_props = check_GL_support(glarea, force_enable) File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", line 167, in check_GL_support return do_check_GL_support(force_enable) File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", line 189, in do_check_GL_support from OpenGL.GL import GL_VERSION, GL_EXTENSIONS File "/usr/lib/python2.7/dist-packages/OpenGL/GL/__init__.py", line 3, in from OpenGL.GL.VERSION.GL_1_1 import * File "/usr/lib/python2.7/dist-packages/OpenGL/GL/VERSION/GL_1_1.py", line 10, in from OpenGL import platform, constants, constant, arrays File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/__init__.py", line 19, in from OpenGL.arrays.arraydatatype import * File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/arraydatatype.py", line 14, in from OpenGL_accelerate.arraydatatype import ArrayDatatype as ADT File "arraydatatype.pyx", line 1, in init OpenGL_accelerate.arraydatatype (src/arraydatatype.c:10964) File "wrapper.pyx", line 3, in init OpenGL_accelerate.wrapper (src/wrapper.c:11183) File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 224, in ErrorChecker = _ErrorChecker( platform ) File "errorchecker.pyx", line 17, in OpenGL_accelerate.errorchecker._ErrorChecker.__init__ (src/errorchecker.c:818) TypeError: __init__() takes at least 2 positional arguments (1 given) From antoine at nagafix.co.uk Sun Mar 19 04:50:33 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 19 Mar 2017 11:50:33 +0700 Subject: [winswitch] xpra and PyOpenGL In-Reply-To: <8693981c-3115-0101-7df2-a465700d7445@cam.ac.uk> References: <8693981c-3115-0101-7df2-a465700d7445@cam.ac.uk> Message-ID: <5df299f8-502b-f6d7-e9c1-949f60633efa@nagafix.co.uk> On 18/03/17 19:36, Anthony Stone via shifter-users wrote: > Hello, > > I have just installed PyOpenGL-accelerate (I was using xpra without it > before) xpra can use PyOpenGL without PyOpenGL-accelerate but having both installed is a lot better. (not sure why Debian and Ubuntu don't package PyOpenGL-accelerate) > and I now get the error message below. xpra completes the > startup and is usable, but I would like to have OpenGL working. Is this > a known problem? Yes: https://www.xpra.org/trac/ticket/781 > Is it a bug or a problem with my setup? Your installation of PyOpenGL + PyOpenGL-accelerate is broken: the versions must match exactly and Ubuntu 16.04 ships an outdated version of PyOpenGL, then you must have tried to install a newer version of PyOpenGL-accelerate on top. > I have only > been using xpra for a few weeks so I'm not familiar with its workings. > > I'm running xpra 1.04 under Ubuntu 16.04 to connect to a remote desktop > machine running the same version of xpra under Ubuntu 14.04. That should work fine. Cheers Antoine > > Thanks, > Anthony > > $ xpra start ssh:whirligig --start=gnome-terminal & > [1] 13911 > $ 2017-03-17 16:29:48,190 Xpra gtk2 client version 1.0.4-r15266 64-bit > 2017-03-17 16:29:48,190 running on Linux Ubuntu 16.04 xenial > 2017-03-17 16:29:48,191 Warning: failed to import opencv: > 2017-03-17 16:29:48,191 No module named cv2 > 2017-03-17 16:29:48,191 webcam forwarding is disabled > 2017-03-17 16:29:48,505 GStreamer version 1.8.3 for Python 2.7.12 64-bit > 2017-03-17 16:29:48,747 OpenGL_accelerate module loaded > 2017-03-17 16:29:48,748 Error loading OpenGL support: > 2017-03-17 16:29:48,748 __init__() takes at least 2 positional > arguments (1 given) > Traceback (most recent call last): > File > "/usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py", > line 663, in init_opengl > self.opengl_props = > gl_check.check_support(force_enable=(enable_opengl is True)) > File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", > line 527, in check_support > gl_props = check_GL_support(glarea, force_enable) > File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", > line 167, in check_GL_support > return do_check_GL_support(force_enable) > File "/usr/lib/python2.7/dist-packages/xpra/client/gl/gl_check.py", > line 189, in do_check_GL_support > from OpenGL.GL import GL_VERSION, GL_EXTENSIONS > File "/usr/lib/python2.7/dist-packages/OpenGL/GL/__init__.py", line 3, > in > from OpenGL.GL.VERSION.GL_1_1 import * > File "/usr/lib/python2.7/dist-packages/OpenGL/GL/VERSION/GL_1_1.py", > line 10, in > from OpenGL import platform, constants, constant, arrays > File "/usr/lib/python2.7/dist-packages/OpenGL/arrays/__init__.py", > line 19, in > from OpenGL.arrays.arraydatatype import * > File > "/usr/lib/python2.7/dist-packages/OpenGL/arrays/arraydatatype.py", line > 14, in > from OpenGL_accelerate.arraydatatype import ArrayDatatype as ADT > File "arraydatatype.pyx", line 1, in init > OpenGL_accelerate.arraydatatype (src/arraydatatype.c:10964) > File "wrapper.pyx", line 3, in init OpenGL_accelerate.wrapper > (src/wrapper.c:11183) > File "/usr/lib/python2.7/dist-packages/OpenGL/error.py", line 224, in > > ErrorChecker = _ErrorChecker( platform ) > File "errorchecker.pyx", line 17, in > OpenGL_accelerate.errorchecker._ErrorChecker.__init__ > (src/errorchecker.c:818) > TypeError: __init__() takes at least 2 positional arguments (1 given) > _______________________________________________ > 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 Mar 29 12:03:22 2017 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 29 Mar 2017 18:03:22 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 1.0.5 LTS : many minor fixes, one potentially critical Message-ID: <6d144e2a-023e-2aa7-2595-c8ca0e576571@nagafix.co.uk> Hi, The critical fix is for a server crash with short-lived override-redirect windows (ie: tooltips). This particular xpra source code has not changed in years so if your server isn't crashing, it's probably not worth worrying too much about this one. The rest of the fixes are mostly minor fixes: HTML5 client, sockets permissions, proxy server, some packaging, etc. Upgrading is recommended. Release notes: * fix X11 server crashes with very short-lived OR windows * fix compatibility with python-lz4 0.9.0 (API breakage) * fix paint order with HTML5 client * fix scroll paints with HTML5 client * fix resource leak in HTML5 client * fix spurious errors recorded in a rare race condition running lpinfo * fix RPM dependencies of python3 package * fix missing screen bit depth with Mac OS clients * fix absolute bind paths handled as relative locations * fix handling of "socket-dir" option in backwards compatible way * fix socket group permissions failures more gracefully * fix proxy server control socket path issues * fix exit-with-client and server shutdown race conditions * fix missing window paint refresh with some posix window managers * support more CUDA architectures for NVENC * try to ensure the tmpfiles.d directory is created on RPM install * workaround lost window events using a higher default initial resolution (4k) * add missing "auto" encoding option to the MacOS menu * try harder to ensure the correct sound DEB dependencies are installed * increase socket timeout to prevent session probing failures * better xsettings synchronization code (actually catch errors there) * remove XShm debug logging from regular output * add missing indentation in man page, help page * RPM packaging of tmpfiles.d config * MacOS library updates: libpng, python-lz4, libepoxy, python cryptography, libpng The source: https://xpra.org/src/ Binaries/repositories: https://winswitch.org/downloads/ Direct binary downloads: https://xpra.org/dists/ Beta: https://xpra.org/beta/ Cheers Antoine