From iwan at reahl.org Fri Oct 5 08:00:44 2018 From: iwan at reahl.org (Iwan Vosloo) Date: Fri, 5 Oct 2018 09:00:44 +0200 Subject: [winswitch] Xpra on ubuntu 18.04 unity Message-ID: <38eb1743-cb7c-8d60-1854-a9659934c0fb@reahl.org> Hi, We've been using xpra on Ubuntu 16.04 for a while now without issues, (thanks!) but after upgrade to Ubuntu 18.04 we cant get the client to work under unity. We run xpra server inside an lxc container. The container runs Ubuntu 18.04 (and has done so before the client side has been upgraded without issues), and xpra --version says: xpra v2.3.4-r20509 Xpra is started like this: xpra start --sharing=yes :100 Then we attach from outside the container, with the same version of xpra: xpra attach --sharing=yes ssh:10.0.3.140:100 When run from a normal, "Ubuntu" session (meaning the new Gnome shipped with Ubuntu 18.04), all is well. However, if we log into a unity session (which is what we'd like to do), xpra cannot attach, giving: 2018-10-05 08:35:15,622 Xpra gtk2 client version 2.3.4-r20509 64-bit 2018-10-05 08:35:15,623 running on Linux Ubuntu 18.04 bionic 2018-10-05 08:35:17,212 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-10-05 08:35:17,376 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: Warning: cannot register existing type 'GdkScreen' glarea.realize() /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: Warning: g_once_init_leave: assertion 'result != 0' failed glarea.realize() /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' failed glarea.realize() Segmentation fault (core dumped) If we run it under unity with: xpra attach --sharing=yes --opengl=no ssh:vagrant at 10.0.3.140:100 ...then it attaches fine (also according to the server log file), but running a program on :100 does not open a window on the attached client. I have also noticed that if you click on the app indicator that xpra client adds to unity, and click on anything (say Information>>Session info), nothing is displayed either. How do I go about debugging this further? Thanks. -- Iwan From antoine at nagafix.co.uk Fri Oct 5 17:54:48 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 5 Oct 2018 23:54:48 +0700 Subject: [winswitch] Xpra on ubuntu 18.04 unity In-Reply-To: <38eb1743-cb7c-8d60-1854-a9659934c0fb@reahl.org> References: <38eb1743-cb7c-8d60-1854-a9659934c0fb@reahl.org> Message-ID: On 05/10/2018 14:00, Iwan Vosloo via shifter-users wrote: > Hi, > > We've been using xpra on Ubuntu 16.04 for a while now without issues, > (thanks!) but after upgrade to Ubuntu 18.04 we cant get the client to > work under unity. > > We run xpra server inside an lxc container. The container runs Ubuntu > 18.04 (and has done so before the client side has been upgraded without > issues), and xpra --version says: xpra v2.3.4-r20509 > > Xpra is started like this: > ? xpra start --sharing=yes :100 > > Then we attach from outside the container, with the same version of xpra: > ? xpra attach --sharing=yes ssh:10.0.3.140:100 FYI: you should probably use unix-domain sockets and a shared location rather than ssh. > When run from a normal, "Ubuntu" session (meaning the new Gnome shipped > with Ubuntu 18.04), all is well. > > However, if we log into a unity session (which is what we'd like to do), > xpra cannot attach,? giving: > > 2018-10-05 08:35:15,622 Xpra gtk2 client version 2.3.4-r20509 64-bit > 2018-10-05 08:35:15,623? running on Linux Ubuntu 18.04 bionic > 2018-10-05 08:35:17,212 GStreamer version 1.14.1 for Python 2.7.15 64-bit > 2018-10-05 08:35:17,376 No OpenGL_accelerate module loaded: No module > named OpenGL_accelerate > /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: > Warning: cannot register existing type 'GdkScreen' > ? glarea.realize() > /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: > Warning: g_once_init_leave: assertion 'result != 0' failed > ? glarea.realize() > /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: > GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' > failed > ? glarea.realize() > Segmentation fault (core dumped) That's an OpenGL crash. We have sanity checks to verify that the OpenGL drivers work properly before we enable them, but it is those checks that are causing the crash here. If the drivers can't create a simple test window, something is fundamentally wrong. Looks like the opengl bindings don't run properly under Unity. This would be a bug for Unity or gtkgl. You may have more luck with the alternative opengl backend: xpra attach --opengl=native The only thing we could do better here would be to proactively disable OpenGL under Unity. Let us know how you get on so that I can blacklist Unity if necessary. It wouldn't hurt to have the output of the command: xpra opengl > If we run it under unity with: > ? xpra attach --sharing=yes --opengl=no ssh:vagrant at 10.0.3.140:100 > > ...then it attaches fine (also according to the server log file), but > running a program on :100 does not open a window on the attached client. This looks like a separate issue. It's very difficult to tell you anything useful as there just isn't enough information there. FWIW, I've just tried it and encountered no problems. Try filing a ticket and make sure to include "xpra info". Please note that applications should be started with "--start=whatever" rather than using "DISPLAY=:100 whatever" to ensure that the environment is correct. > I have also noticed that if you click on the app indicator that xpra > client adds to unity, and click on anything (say Information>>Session > info), nothing is displayed either. Oh, the mess that is Ubuntu's flawed appindicator API, hopefully it will be abandoned soon. In the meantime, you can try to disable it with: XPRA_USE_NATIVE_TRAY=0 xpra attach ... > How do I go about debugging this further? Try adding "--debug=tray" to your attach command line. Cheers, Antoine > > Thanks. > From iwan at reahl.org Sun Oct 7 14:00:32 2018 From: iwan at reahl.org (Iwan Vosloo) Date: Sun, 7 Oct 2018 15:00:32 +0200 Subject: [winswitch] Xpra on ubuntu 18.04 unity In-Reply-To: References: <38eb1743-cb7c-8d60-1854-a9659934c0fb@reahl.org> Message-ID: <945d77ec-8ba1-c91e-8339-3dc4bb54b2b9@reahl.org> Thanks Antoine, On 05/10/2018 18:54, Antoine Martin via shifter-users wrote: > On 05/10/2018 14:00, Iwan Vosloo via shifter-users wrote: >> When run from a normal, "Ubuntu" session (meaning the new Gnome shipped >> with Ubuntu 18.04), all is well. >> >> However, if we log into a unity session (which is what we'd like to do), >> xpra cannot attach,? giving: >> >> 2018-10-05 08:35:15,622 Xpra gtk2 client version 2.3.4-r20509 64-bit >> 2018-10-05 08:35:15,623? running on Linux Ubuntu 18.04 bionic >> 2018-10-05 08:35:17,212 GStreamer version 1.14.1 for Python 2.7.15 64-bit >> 2018-10-05 08:35:17,376 No OpenGL_accelerate module loaded: No module >> named OpenGL_accelerate >> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >> Warning: cannot register existing type 'GdkScreen' >> ? glarea.realize() >> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >> Warning: g_once_init_leave: assertion 'result != 0' failed >> ? glarea.realize() >> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >> GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' >> failed >> ? glarea.realize() >> Segmentation fault (core dumped) > That's an OpenGL crash. > We have sanity checks to verify that the OpenGL drivers work properly > before we enable them, but it is those checks that are causing the crash > here. If the drivers can't create a simple test window, something is > fundamentally wrong. > > Looks like the opengl bindings don't run properly under Unity. > This would be a bug for Unity or gtkgl. > > > You may have more luck with the alternative opengl backend: > xpra attach --opengl=native > > The only thing we could do better here would be to proactively disable > OpenGL under Unity. I realise something besides xpra must be causing the issue - something that changed between ubuntu 16.04 (where Unity works fine) and 18.04. Not sure how to get more info to poinpoint the issue though. > Let us know how you get on so that I can blacklist Unity if necessary. with --opengl=native things still dont work and I get output: 2018-10-07 14:31:18,390 Xpra gtk2 client version 2.3.4-r20509 64-bit 2018-10-07 14:31:18,391 running on Linux Ubuntu 18.04 bionic 2018-10-07 14:31:20,113 GStreamer version 1.14.1 for Python 2.7.15 64-bit 2018-10-07 14:31:20,275 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: Warning: cannot register existing type 'GdkScreen' window.realize() /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: Warning: g_once_init_leave: assertion 'result != 0' failed window.realize() /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' failed window.realize() 2018-10-07 14:31:20,529 OpenGL enabled with Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) However that process seems to hang and never reports being attached. I have to kill -9 to get rid of it. > It wouldn't hurt to have the output of the command: > xpra opengl No OpenGL_accelerate module loaded: No module named OpenGL_accelerate GLU.extensions=GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess GLU.version=1.3 accum-blue-size=0 accum-green-size=0 accum-red-size=0 alpha-size=0 aux-buffers=0 blue-size=8 depth=24 depth-size=0 display_mode=DOUBLE double-buffered=True gdkgl={'version': (1, 4)} gdkglext={'version': (1, 2, 0)} green-size=8 gtkglext={'version': (1, 2, 0)} has-depth-buffer=False has-stencil-buffer=False has_alpha=False max-viewport-dims=(32768, 32768) opengl=3.0 pygdkglext={'version': (1, 1, 0)} pyopengl=3.1.1a1 red-size=8 renderer=Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) rgba=True safe=True sample-buffers=0 samples=0 shading-language-version=1.30 stencil-size=0 stereo=False texture-size-limit=16384 transparency=True vendor=Intel Open Source Technology Center zerocopy=False > >> If we run it under unity with: >> ? xpra attach --sharing=yes --opengl=no ssh:vagrant at 10.0.3.140:100 >> >> ...then it attaches fine (also according to the server log file), but >> running a program on :100 does not open a window on the attached client. > This looks like a separate issue. > It's very difficult to tell you anything useful as there just isn't > enough information there. FWIW, I've just tried it and encountered no > problems. > Try filing a ticket and make sure to include "xpra info". > Ok, thanks I did so and included output of xpra opengl and xpra info. Regards Iwan -- From antoine at nagafix.co.uk Fri Oct 12 11:14:21 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Oct 2018 17:14:21 +0700 Subject: [winswitch] Xpra on ubuntu 18.04 unity In-Reply-To: <945d77ec-8ba1-c91e-8339-3dc4bb54b2b9@reahl.org> References: <38eb1743-cb7c-8d60-1854-a9659934c0fb@reahl.org> <945d77ec-8ba1-c91e-8339-3dc4bb54b2b9@reahl.org> Message-ID: <58aa0cbd-723c-f318-d5c1-7b171cb91cf2@nagafix.co.uk> For the record, the problem with Unity comes from Ubuntu's packaging of gtk3-nocsd which is installed as a dependency of the unity package. The LD_PRELOAD trick it uses to do its job ends up injecting GTK3 library symbols into GTK2 processes, causing all sorts of problems. More gory details here: https://xpra.org/trac/ticket/1981#comment:5 Cheers, Antoine On 07/10/18 20:00, Iwan Vosloo via shifter-users wrote: > Thanks Antoine, > > On 05/10/2018 18:54, Antoine Martin via shifter-users wrote: >> On 05/10/2018 14:00, Iwan Vosloo via shifter-users wrote: >>> When run from a normal, "Ubuntu" session (meaning the new Gnome shipped >>> with Ubuntu 18.04), all is well. >>> >>> However, if we log into a unity session (which is what we'd like to do), >>> xpra cannot attach,? giving: >>> >>> 2018-10-05 08:35:15,622 Xpra gtk2 client version 2.3.4-r20509 64-bit >>> 2018-10-05 08:35:15,623? running on Linux Ubuntu 18.04 bionic >>> 2018-10-05 08:35:17,212 GStreamer version 1.14.1 for Python 2.7.15 >>> 64-bit >>> 2018-10-05 08:35:17,376 No OpenGL_accelerate module loaded: No module >>> named OpenGL_accelerate >>> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >>> >>> Warning: cannot register existing type 'GdkScreen' >>> ?? glarea.realize() >>> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >>> >>> Warning: g_once_init_leave: assertion 'result != 0' failed >>> ?? glarea.realize() >>> /usr/lib/python2.7/dist-packages/xpra/client/gl/gtk_base/gtkgl_check.py:152: >>> >>> GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' >>> failed >>> ?? glarea.realize() >>> Segmentation fault (core dumped) >> That's an OpenGL crash. >> We have sanity checks to verify that the OpenGL drivers work properly >> before we enable them, but it is those checks that are causing the crash >> here. If the drivers can't create a simple test window, something is >> fundamentally wrong. >> >> Looks like the opengl bindings don't run properly under Unity. >> This would be a bug for Unity or gtkgl. >> >> >> You may have more luck with the alternative opengl backend: >> xpra attach --opengl=native >> >> The only thing we could do better here would be to proactively disable >> OpenGL under Unity. > > I realise something besides xpra must be causing the issue - something > that changed between ubuntu 16.04 (where Unity works fine) and 18.04. > Not sure how to get more info to poinpoint the issue though. > >> Let us know how you get on so that I can blacklist Unity if necessary. > > with --opengl=native things still dont work and I get output: > > 2018-10-07 14:31:18,390 Xpra gtk2 client version 2.3.4-r20509 64-bit > 2018-10-07 14:31:18,391? running on Linux Ubuntu 18.04 bionic > 2018-10-07 14:31:20,113 GStreamer version 1.14.1 for Python 2.7.15 64-bit > 2018-10-07 14:31:20,275 No OpenGL_accelerate module loaded: No module > named OpenGL_accelerate > /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: > Warning: cannot register existing type 'GdkScreen' > ? window.realize() > /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: > Warning: g_once_init_leave: assertion 'result != 0' failed > ? window.realize() > /usr/lib/python2.7/dist-packages/xpra/client/gtk_base/gtk_client_base.py:1020: > GtkWarning: gdk_screen_is_composited: assertion 'GDK_IS_SCREEN (screen)' > failed > ? window.realize() > 2018-10-07 14:31:20,529 OpenGL enabled with Mesa DRI Intel(R) HD > Graphics 520 (Skylake GT2) > > However that process seems to hang and never reports being attached. I > have to kill -9 to get rid of it. > >> It wouldn't hurt to have the output of the command: >> xpra opengl > > No OpenGL_accelerate module loaded: No module named OpenGL_accelerate > GLU.extensions=GLU_EXT_nurbs_tessellator GLU_EXT_object_space_tess > GLU.version=1.3 > accum-blue-size=0 > accum-green-size=0 > accum-red-size=0 > alpha-size=0 > aux-buffers=0 > blue-size=8 > depth=24 > depth-size=0 > display_mode=DOUBLE > double-buffered=True > gdkgl={'version': (1, 4)} > gdkglext={'version': (1, 2, 0)} > green-size=8 > gtkglext={'version': (1, 2, 0)} > has-depth-buffer=False > has-stencil-buffer=False > has_alpha=False > max-viewport-dims=(32768, 32768) > opengl=3.0 > pygdkglext={'version': (1, 1, 0)} > pyopengl=3.1.1a1 > red-size=8 > renderer=Mesa DRI Intel(R) HD Graphics 520 (Skylake GT2) > rgba=True > safe=True > sample-buffers=0 > samples=0 > shading-language-version=1.30 > stencil-size=0 > stereo=False > texture-size-limit=16384 > transparency=True > vendor=Intel Open Source Technology Center > zerocopy=False > > >> >>> If we run it under unity with: >>> ?? xpra attach --sharing=yes --opengl=no ssh:vagrant at 10.0.3.140:100 >>> >>> ...then it attaches fine (also according to the server log file), but >>> running a program on :100 does not open a window on the attached client. >> This looks like a separate issue. >> It's very difficult to tell you anything useful as there just isn't >> enough information there. FWIW, I've just tried it and encountered no >> problems. >> Try filing a ticket and make sure to include "xpra info". >> > > Ok, thanks I did so and included output of xpra opengl and xpra info. > > > Regards > Iwan > From antoine at nagafix.co.uk Fri Oct 12 11:40:31 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 12 Oct 2018 17:40:31 +0700 Subject: [winswitch] OpenGL Setup Failure In-Reply-To: References: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> <308e0883-51a5-11e8-9aa9-39cf4b85e2a1@nagafix.co.uk> Message-ID: <1adb71e0-2c25-11a4-1483-1394e1cd24a7@nagafix.co.uk> On 30/09/18 03:14, Bob Babcock wrote: > Antoine Martin via shifter-users wrote: >> Is there a particular reason why you're using the 32-bit version? >> We are planning on dropping 32-bit support after the next LTS release. > > I've got a cheap ($99) 32-bit laptop running Windows 8.1 that I use when > traveling.? It's slow, but typical hotel internet connections are even > slower.? I installed the same version on my desktop for consistency.? > (Just now I replaced it with the 64-bit beta.)? Side note: on this > laptop, xpra 2.3.4 initially failed (missing dll) because it needed a > visual c++ runtime.? Easy to fix, but shouldn't the installer detect > this dependency and send you off to Microsoft to get the runtime? I have just tried the 2.3.4 installer on a clean 64-bit MS Windows 10 virtual machine and did not get any warnings or errors related to missing DLLs. The Xpra 2.x series switched to native builds thanks to MSYS2. This doesn't use MSVC for building anything so I don't understand why you would need the VC runtime. Can you please create a ticket or post the information that would allow us to fix this problem? (things like the full OS version and patch level, installer filename, full error message, etc) >> FYI: you are specifying the ssh port twice, I'm not sure which one will >> take precedence, but specifying it once in the connection string ought >> to be enough. > > I remember lots of fiddling to get a command line that worked.? One > complication is that I use a non-standard ssh port when coming in from > the outside world, so any changes have to be tested both locally and > remotely. No fiddling should be necessary. For using a non-standard ssh port like 2222, simply use: xpra attach ssh://HOST:2222/ Cheers, Antoine > >> I've uploaded newer builds for both 2.3.4 and 2.4 beta, those include >> the correct version of PyOpenGL and should fix this problem. > > I tested both 2.3.4 and 2.4 beta; the openGL error is gone in both > cases.? Thanks for the quick fix. > From wssddc at wssddc.com Sat Oct 13 07:06:29 2018 From: wssddc at wssddc.com (Bob Babcock) Date: Sat, 13 Oct 2018 02:06:29 -0400 Subject: [winswitch] OpenGL Setup Failure In-Reply-To: <1adb71e0-2c25-11a4-1483-1394e1cd24a7@nagafix.co.uk> References: <7ea1775a-1030-c0cd-bec6-487c2a6b9458@wssddc.com> <308e0883-51a5-11e8-9aa9-39cf4b85e2a1@nagafix.co.uk> <1adb71e0-2c25-11a4-1483-1394e1cd24a7@nagafix.co.uk> Message-ID: Antoine Martin wrote: > The Xpra 2.x series switched to native builds thanks to MSYS2. This > doesn't use MSVC for building anything so I don't understand why you > would need the VC runtime. I'm afraid I can't reproduce the problem.? What I had to install on 32-bit Windows 8.1 was Microsoft Visual C++ Redistributable (x86) - 14.0.23026 But if I uninstall this, Xpra and Xpra installers still work. (Doesn't matter if it's 2.3.4 before or after the OpenGL fix or 2.4 beta.) The error I got was xxxx140.dll missing; I didn't record exactly the leading characters, but it's an error I've seen often enough to recognize that a C++ redistributable was needed.? Probably it? was MSVCP140.DLL.? Most machines will already have this either because some other application needed it and Windows 10 probably includes it in the base OS. > No fiddling should be necessary. For using a non-standard ssh port like > 2222, simply use: > xpra attach ssh://HOST:2222/ The fiddling certainly had a large component of new user confusion. I recall playing with what I might call punctuation, i.e. slashes and colons. To attach to an existing connection rather than starting a new one, my bat file does pretty much what you specify. start xpra attach ssh/%username%@%host%:%port%/%display% I have never actually had a need for a non-default display; it just adds complication to my bat file. From totaam at xpra.org Sun Oct 14 20:08:28 2018 From: totaam at xpra.org (Antoine Martin) Date: Mon, 15 Oct 2018 02:08:28 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.4 Message-ID: <807531f0-b8b5-8bbe-2f72-fc4332e313a8@xpra.org> Hi, The most significant changes and new features found in this release are: * SSH integration through paramiko: - the client now provides a common user interface for accepting host keys, entering passwords and key passphrases - on all platforms - the server can upgrade its TCP sockets to talk SSH natively * improved automatic encoding selection and video scaling * non-US keyboard layout support improved, esp for the HTML5 client * support for video decoding in the HTML5 client * better memory management and resource usage * new GUI welcome screen * clipboard synchronization with multiple clients * more notifications, modal windows, support for Java applications, etc * the usual updates, bug fixes, cleanups and optimizations * buildbot upgrade: a separate email update will follow For more details, including links to the documentation and tickets, see: https://xpra.org/trac/wiki/News#a2.4ImportantFeatures The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine From anto.trande at gmail.com Mon Oct 15 09:58:24 2018 From: anto.trande at gmail.com (Antonio Trande) Date: Mon, 15 Oct 2018 10:58:24 +0200 Subject: [winswitch] [ANNOUNCE] Xpra 2.4 In-Reply-To: <807531f0-b8b5-8bbe-2f72-fc4332e313a8@xpra.org> References: <807531f0-b8b5-8bbe-2f72-fc4332e313a8@xpra.org> Message-ID: <5c142454-6b2e-c10f-777f-4aa88cdb614c@fedoraproject.org> Hello everyone. Is this release ready for Python3? On 14/10/18 21:08, Antoine Martin via shifter-users wrote: > Hi, > > The most significant changes and new features found in this release are: > * SSH integration through paramiko: > - the client now provides a common user interface for accepting host > keys, entering passwords and key passphrases - on all platforms > - the server can upgrade its TCP sockets to talk SSH natively > * improved automatic encoding selection and video scaling > * non-US keyboard layout support improved, esp for the HTML5 client > * support for video decoding in the HTML5 client > * better memory management and resource usage > * new GUI welcome screen > * clipboard synchronization with multiple clients > * more notifications, modal windows, support for Java applications, etc > * the usual updates, bug fixes, cleanups and optimizations > * buildbot upgrade: a separate email update will follow > > For more details, including links to the documentation and tickets, see: > https://xpra.org/trac/wiki/News#a2.4ImportantFeatures > > > 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 Mon Oct 15 16:44:57 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Oct 2018 22:44:57 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.4 In-Reply-To: <5c142454-6b2e-c10f-777f-4aa88cdb614c@fedoraproject.org> References: <807531f0-b8b5-8bbe-2f72-fc4332e313a8@xpra.org> <5c142454-6b2e-c10f-777f-4aa88cdb614c@fedoraproject.org> Message-ID: <0cc7791f-a524-e169-b545-4fd4b7962223@nagafix.co.uk> On 15/10/18 15:58, Antonio Trande via shifter-users wrote: > Hello everyone. > > Is this release ready for Python3? It depends what you mean by "ready". The Python 3 / GTK3 client runs fine, the non-shadow servers still needs porting, this is scheduled for 2.5 Cheers, Antoine > > On 14/10/18 21:08, Antoine Martin via shifter-users wrote: >> Hi, >> >> The most significant changes and new features found in this release are: >> * SSH integration through paramiko: >> - the client now provides a common user interface for accepting host >> keys, entering passwords and key passphrases - on all platforms >> - the server can upgrade its TCP sockets to talk SSH natively >> * improved automatic encoding selection and video scaling >> * non-US keyboard layout support improved, esp for the HTML5 client >> * support for video decoding in the HTML5 client >> * better memory management and resource usage >> * new GUI welcome screen >> * clipboard synchronization with multiple clients >> * more notifications, modal windows, support for Java applications, etc >> * the usual updates, bug fixes, cleanups and optimizations >> * buildbot upgrade: a separate email update will follow >> >> For more details, including links to the documentation and tickets, see: >> https://xpra.org/trac/wiki/News#a2.4ImportantFeatures >> >> >> 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 >> > From kaefert at gmail.com Mon Oct 15 16:57:51 2018 From: kaefert at gmail.com (=?UTF-8?Q?Thomas_K=C3=A4fer?=) Date: Mon, 15 Oct 2018 17:57:51 +0200 Subject: [winswitch] cant attach through ssh after upgrade and reboot Message-ID: $ xpra version 2.4-r20681 I've got a single xpra session running locally. I can attach it without a problem by running $ xpra attach but it won't work with ssh anymore: $ xpra attach ssh:127.0.0.1 2018-10-15 17:54:33,147 Xpra gtk2 client version 2.4-r20681 64-bit 2018-10-15 17:54:33,148 running on Linux LinuxMint 18.3 sylvia 2018-10-15 17:54:33,149 window manager is 'Mutter (Muffin)' 2018-10-15 17:54:33,927 GStreamer version 1.8.3 for Python 2.7.12 64-bit 2018-10-15 17:54:34,055 No OpenGL_accelerate module loaded: No module named OpenGL_accelerate 2018-10-15 17:54:34,228 OpenGL enabled with GeForce GT 750M/PCIe/SSE2 2018-10-15 17:54:34,973 Connected (version 2.0, client OpenSSH_7.2p2) 2018-10-15 17:54:35,082 Unknown exception: Use module Crypto.Signature.pkcs1_15 instead 2018-10-15 17:54:35,083 Traceback (most recent call last): 2018-10-15 17:54:35,083 File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1782, in run 2018-10-15 17:54:35,083 self.kex_engine.parse_next(ptype, m) 2018-10-15 17:54:35,083 File "/usr/lib/python2.7/dist-packages/paramiko/kex_gex.py", line 88, in parse_next 2018-10-15 17:54:35,083 return self._parse_kexdh_gex_reply(m) 2018-10-15 17:54:35,083 File "/usr/lib/python2.7/dist-packages/paramiko/kex_gex.py", line 244, in _parse_kexdh_gex_reply 2018-10-15 17:54:35,083 self.transport._verify_key(host_key, sig) 2018-10-15 17:54:35,083 File "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1605, in _verify_key 2018-10-15 17:54:35,083 if not key.verify_ssh_sig(self.H, Message(sig)): 2018-10-15 17:54:35,084 File "/usr/lib/python2.7/dist-packages/paramiko/rsakey.py", line 113, in verify_ssh_sig 2018-10-15 17:54:35,084 return rsa.verify(hash_obj, (sig,)) 2018-10-15 17:54:35,084 File "/usr/local/lib/python2.7/dist-packages/Crypto/PublicKey/RSA.py", line 372, in verify 2018-10-15 17:54:35,084 raise NotImplementedError("Use module Crypto.Signature.pkcs1_15 instead") 2018-10-15 17:54:35,084 NotImplementedError: Use module Crypto.Signature.pkcs1_15 instead 2018-10-15 17:54:35,084 2018-10-15 17:54:35,086 Xpra client failed to connect 2018-10-15 17:54:35,086 connection failed: Use module Crypto.Signature.pkcs1_15 instead xpra initialization error: connection failed: Use module Crypto.Signature.pkcs1_15 instead Please help. I got xpra through this repository and it did work without any problems until about a week ago. deb https://xpra.org/ xenial main Kind regards, Thomas K?fer From antoine at nagafix.co.uk Mon Oct 15 17:10:49 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 15 Oct 2018 23:10:49 +0700 Subject: [winswitch] cant attach through ssh after upgrade and reboot In-Reply-To: References: Message-ID: <5c070c73-fdd6-b037-9866-83f7ca458c43@nagafix.co.uk> On 15/10/18 22:57, Thomas K?fer via shifter-users wrote: > $ xpra version > 2.4-r20681 > > > I've got a single xpra session running locally. I can attach it without a > problem by running > $ xpra attach > > but it won't work with ssh anymore: > > $ xpra attach ssh:127.0.0.1 > 2018-10-15 17:54:33,147 Xpra gtk2 client version 2.4-r20681 64-bit > 2018-10-15 17:54:33,148 running on Linux LinuxMint 18.3 sylvia > 2018-10-15 17:54:33,149 window manager is 'Mutter (Muffin)' > 2018-10-15 17:54:33,927 GStreamer version 1.8.3 for Python 2.7.12 64-bit > 2018-10-15 17:54:34,055 No OpenGL_accelerate module loaded: No module named > OpenGL_accelerate > 2018-10-15 17:54:34,228 OpenGL enabled with GeForce GT 750M/PCIe/SSE2 > 2018-10-15 17:54:34,973 Connected (version 2.0, client OpenSSH_7.2p2) > 2018-10-15 17:54:35,082 Unknown exception: Use module > Crypto.Signature.pkcs1_15 instead > 2018-10-15 17:54:35,083 Traceback (most recent call last): > 2018-10-15 17:54:35,083 File > "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1782, in run > 2018-10-15 17:54:35,083 self.kex_engine.parse_next(ptype, m) > 2018-10-15 17:54:35,083 File > "/usr/lib/python2.7/dist-packages/paramiko/kex_gex.py", line 88, in > parse_next > 2018-10-15 17:54:35,083 return self._parse_kexdh_gex_reply(m) > 2018-10-15 17:54:35,083 File > "/usr/lib/python2.7/dist-packages/paramiko/kex_gex.py", line 244, in > _parse_kexdh_gex_reply > 2018-10-15 17:54:35,083 self.transport._verify_key(host_key, sig) > 2018-10-15 17:54:35,083 File > "/usr/lib/python2.7/dist-packages/paramiko/transport.py", line 1605, in > _verify_key > 2018-10-15 17:54:35,083 if not key.verify_ssh_sig(self.H, Message(sig)): > 2018-10-15 17:54:35,084 File > "/usr/lib/python2.7/dist-packages/paramiko/rsakey.py", line 113, in > verify_ssh_sig > 2018-10-15 17:54:35,084 return rsa.verify(hash_obj, (sig,)) > 2018-10-15 17:54:35,084 File > "/usr/local/lib/python2.7/dist-packages/Crypto/PublicKey/RSA.py", line 372, > in verify > 2018-10-15 17:54:35,084 raise NotImplementedError("Use module > Crypto.Signature.pkcs1_15 instead") > 2018-10-15 17:54:35,084 NotImplementedError: Use module > Crypto.Signature.pkcs1_15 instead > 2018-10-15 17:54:35,084 > 2018-10-15 17:54:35,086 Xpra client failed to connect > 2018-10-15 17:54:35,086 connection failed: Use module > Crypto.Signature.pkcs1_15 instead > xpra initialization error: > connection failed: Use module Crypto.Signature.pkcs1_15 instead Looks like your Linux Mint distro ships a version of paramiko which has problems handling RSA keys. You can switch back to the "old" ssh backend with: xpra attach --ssh="ssh -x" Or to make this permanent: echo "ssh=ssh -x" >> ~/.xpra/xpra.conf I've just tried it with Ubuntu Xenial on which your Linux Mint version seem to be based and could not reproduce any problems. > Please help. I got xpra through this repository and it did work without any > problems until about a week ago. That would be until yesterday, when 2.4 was released. > deb https://xpra.org/ xenial main Cheers, Antoine > > Kind regards, > Thomas K?fer > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From Ben.Jackson at fidessa.com Tue Oct 23 09:05:09 2018 From: Ben.Jackson at fidessa.com (Ben Jackson) Date: Tue, 23 Oct 2018 08:05:09 +0000 Subject: [winswitch] Xterm menus no mouse tracking Message-ID: Hi all, When I run xterm under xpra, and connect to it, the menus (ctrl left/middle/right click) don't work properly. They show up, but the selection does not track the mouse. I'm trying to work out if this is an xpra issue or a setup issue, and wonder if someone could confirm/deny the behaviour? Steps to reproduce: 1. Start xpra on RH7 host with (xpra start :1009 -start=xterm) 2. Connect to that session 3. In the xterm window, ctrl-right-click to see the vt menu. Try and select an option. Expected: - Options highlight until the mouse button is released and the highlighted option is actioned Actual: - Options do not track with the mouse and no option is actioned on mouse up. My system info: I'm running xpra server on RH7 host and start up an xterm. (e.g. xpra start :1009 --start=xterm). I connect to this session from Windows. Server version: xpra v2.3.2-r19729 Client version: Xpra 2.4 revision 20265 built on Win7Pro64-PC by Win7 Pro 64 2018-09-01 09:03 Xterm version: ukwok-pc1385-vpc7(benj) users/benj>xterm -version XTerm(331) Thanks a lot. Let me know if there's anything else I can do for diagnostics, etc. Cheers, Ben This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK Fidessa Group Holdings Limited registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK From antoine at nagafix.co.uk Tue Oct 23 15:56:47 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 23 Oct 2018 21:56:47 +0700 Subject: [winswitch] Xterm menus no mouse tracking In-Reply-To: References: Message-ID: <57d66a64-c2f2-53f0-8929-17a36bc30285@nagafix.co.uk> Hi, On 23/10/2018 15:05, Ben Jackson via shifter-users wrote: > Hi all, > > When I run xterm under xpra, and connect to it, the menus (ctrl left/middle/right click) don't work properly. They show up, but the selection does not track the mouse. It does, but only on the region of the window that doesn't overlap with the main xterm window. > I'm trying to work out if this is an xpra issue or a setup issue, and wonder if someone could confirm/deny the behaviour? Confirmed. You've just spotted a regression which is more than 2 years old. TBH, I really didn't expect this to be a regression seeing how often I use xterm for testing, but I never noticed that problem. You can workaround this issue by running your server with: XPRA_REPARENT_ROOT=0 xpra start ... I'm hoping to find a solution that does not involve reverting the this change, for more details see: https://xpra.org/trac/ticket/1999 Cheers, Antoine > Steps to reproduce: > 1. Start xpra on RH7 host with (xpra start :1009 -start=xterm) > 2. Connect to that session > 3. In the xterm window, ctrl-right-click to see the vt menu. Try and select an option. > Expected: > - Options highlight until the mouse button is released and the highlighted option is actioned > Actual: > - Options do not track with the mouse and no option is actioned on mouse up. > > My system info: > > I'm running xpra server on RH7 host and start up an xterm. (e.g. xpra start :1009 --start=xterm). > I connect to this session from Windows. > Server version: xpra v2.3.2-r19729 > Client version: Xpra 2.4 revision 20265 built on Win7Pro64-PC by Win7 Pro 64 2018-09-01 09:03 > > Xterm version: > > ukwok-pc1385-vpc7(benj) users/benj>xterm -version > XTerm(331) > > Thanks a lot. Let me know if there's anything else I can do for diagnostics, etc. > > Cheers, > Ben > > > > This message is intended only for the stated addressee(s) and may be confidential. Access to this email by anyone else is unauthorised. Any opinions expressed in this email do not necessarily reflect the opinions of Fidessa. Any unauthorised disclosure, use or dissemination, either whole or in part is prohibited. If you are not the intended recipient of this message, please notify the sender immediately. > Fidessa plc registered in England and Wales no. 3781700. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > Fidessa buy-side ltd registered in England and Wales no. 3656437. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > Fidessa Group Holdings Limited registered in England and Wales no. 3234176. VAT registration no. GB688900878. Registered office - Dukes Court, Duke Street, Woking, Surrey, GU21 5BH, UK > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From wirerydr at compeuphoria.com Sat Oct 27 05:34:54 2018 From: wirerydr at compeuphoria.com (WireRydr) Date: Sat, 27 Oct 2018 00:34:54 -0400 (EDT) Subject: [winswitch] Beta Fedora 28 Repo - Missing ffmpeg package? Message-ID: Hello there. I'm attempting to utilize the Fedora-28 beta respository, however I am encountering the following error, which leads me to suspect that at least one required package is presently missing: -------------------- OUTPUT STARTS -------------------- Fedora 28 - x86_64 - Updates 231 MB/s | 26 MB 00:00 Fedora 28 - x86_64 224 MB/s | 60 MB 00:00 RPM Fusion for Fedora 28 - Free - Updates 2.3 MB/s | 514 kB 00:00 RPM Fusion for Fedora 28 - Free 2.3 MB/s | 754 kB 00:00 RPM Fusion for Fedora 28 - Nonfree - Updates 586 kB/s | 94 kB 00:00 RPM Fusion for Fedora 28 - Nonfree 1.2 MB/s | 208 kB 00:00 Winswitch Beta 28 - x86_64 812 kB/s | 897 kB 00:01 Last metadata expiration check: 0:00:00 ago on Sat 27 Oct 2018 12:19:42 AM EDT. Dependencies resolved. Problem: package xpra-2.5-0.20181025r20836.fc28.x86_64 requires python2-xpra-audio = 2.5-0.20181025r20836.fc28, but none of the providers can be installed - package python2-xpra-audio-2.5-0.20181025r20836.fc28.x86_64 requires python2-xpra = 2.5-0.20181025r20836.fc28, but none of the providers can be installed - cannot install the best update candidate for package xpra-2.3.4-1.fc28.x86_64 - nothing provides ffmpeg-xpra needed by python2-xpra-2.5-0.20181025r20836.fc28.x86_64 ============================================================================================ Package Arch Version Repository Size ============================================================================================ Skipping packages with broken dependencies: python2-xpra x86_64 2.5-0.20181025r20836.fc28 winswitch-beta 2.6 M python2-xpra-audio x86_64 2.5-0.20181025r20836.fc28 winswitch-beta 137 k xpra x86_64 2.5-0.20181025r20836.fc28 winswitch-beta 68 k Transaction Summary ============================================================================================ Skip 3 Packages Nothing to do. Complete! -------------------- OUTPUT ENDS -------------------- When I check online, I see that in the F29 repo this package is present: ffmpeg-xpra-4.0.2-1.fc29.x86_64.rpm However, no corresponding package exists in the F28 repo. Is this something that can be rectified, or is it intentional? Thanks for your time! From antoine at nagafix.co.uk Sat Oct 27 06:04:28 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 27 Oct 2018 12:04:28 +0700 Subject: [winswitch] Beta Fedora 28 Repo - Missing ffmpeg package? In-Reply-To: References: Message-ID: On 27/10/2018 11:34, WireRydr via shifter-users wrote: > Hello there.? I'm attempting to utilize the Fedora-28 beta respository, > however I am encountering the following error, which leads me to suspect > that at least one required package is presently missing: (..) > -------------------- OUTPUT ENDS -------------------- > > When I check online, I see that in the F29 repo this package is present: > > ffmpeg-xpra-4.0.2-1.fc29.x86_64.rpm > > However, no corresponding package exists in the F28 repo.? Is this > something that can be rectified, or is it intentional? It is intentional: the beta repository is a supplemental one, the rest of the packages can be found in the regular stable repository. I have added this information to the repository download links: https://xpra.org/trac/wiki/Download Cheers, Antoine > > Thanks for your time! > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From abiswas at nyu.edu Mon Oct 29 23:10:26 2018 From: abiswas at nyu.edu (Amit Biswas) Date: Mon, 29 Oct 2018 19:10:26 -0400 Subject: [winswitch] [xpra] make the build reproducible Message-ID: Whilst working on the Reproducible Builds effort [0], we noticed that xpra could not be built reproducibly. This is due to the inclusion of xpra/build_info.py file [1], which sets a variable BUILD_MACHINE to the result of platform.uname(). The syscall is especially unreproducible in containers, where it returns the instruction set of the host kernel. In addition to BUILD_MACHINE, other bits of build info like BUILD_CPU, BUILD_TIME, BUILD_DATE in that file makes reproducibility challenging. If you are open the the idea, I can provide a patch removing or replacing them with alternatives like SOURCE_DATE_EPOCH [2]. Feel free to respond with your thoughts on this. [0] https://reproducible-builds.org/ [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/xpra.html [2] https://reproducible-builds.org/docs/source-date-epoch/ Thanks Amit Biswas From antoine at nagafix.co.uk Tue Oct 30 04:06:08 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Tue, 30 Oct 2018 11:06:08 +0700 Subject: [winswitch] [xpra] make the build reproducible In-Reply-To: References: Message-ID: <3c6f848d-37f1-0488-5580-dab00d8c1280@nagafix.co.uk> On 30/10/2018 06:10, Amit Biswas via shifter-users wrote: > Whilst working on the Reproducible Builds effort [0], we noticed that > xpra could not be built reproducibly. This is due to the inclusion of > xpra/build_info.py file [1], which sets a variable BUILD_MACHINE to > the result of platform.uname(). The syscall is especially > unreproducible in containers, where it returns the instruction set of > the host kernel. > > In addition to BUILD_MACHINE, other bits of build info like BUILD_CPU, > BUILD_TIME, BUILD_DATE in that file makes reproducibility challenging. > If you are open the the idea, I can provide a patch removing or > replacing them with alternatives like SOURCE_DATE_EPOCH [2]. Feel free > to respond with your thoughts on this. Please create a ticket and attach your patch there. Although a reproducible build is a laudable goal, it isn't the primordial concern for all the platforms we support and we would not want to replace the information we currently collect when running on say macos or win32, as this data can be too valuable to lose there. Cheers, Antoine > > [0] https://reproducible-builds.org/ > [1] https://tests.reproducible-builds.org/debian/rb-pkg/unstable/i386/xpra.html > [2] https://reproducible-builds.org/docs/source-date-epoch/ > > Thanks > Amit Biswas > _______________________________________________ > 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 Oct 31 17:40:48 2018 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 1 Nov 2018 00:40:48 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 2.4.1: minor fixes Message-ID: <16cc183e-7d9a-abc3-eafb-ba2a90a81bfd@nagafix.co.uk> Hi, This update fixes some regressions in the handling of popup windows (one recent and one much older), the clipboard code, the session info window and the NVENC encoder. There are also a fair few build and packaging related issues. The rest is mostly cosmetic. There is no urgency to update if you were not affected by those issues. Release notes: * fix popup window focus for some Java applications * fix popup window focus issue (ie: xterm menu) * fix system tray errors when mmap is disabled * fix missing system tray under Ubuntu's Unity (DEB dependency issue) * fix error in debug logging on MS Windows * fix missing codecs (numpy was blocked from loading) * fix nvenc compatibility with more python / cython / OS versions * fix backwards compatibility in keyboard mapping * fix session info errors when connecting to older servers * fix default value 'auto' for ssh option, better compatibility * fix dead code triggering some debug warnings * fix rare race condition when closing a connection * fix 'flush' client encoding options parsing * fix overzealous clipboard sanitization code * fix missing notification messages * fix ssh client authentication: try all keys found * fix version update check * fix usability issues with GTK3, especially on MS Windows * fix cython compilation warnings * fix x264 dependency for Debian Buster * fix man page typo * update default DEB build options for newer distributions * removed outdated DEB dependency on xvidcore * avoid ethtool warning spam * use correct headers for building python3 cairo workaround module The source: https://xpra.org/src/ Downloads: https://xpra.org/trac/wiki/Download Cheers Antoine