From antoine at nagafix.co.uk Wed Jun 1 03:56:25 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 1 Jun 2016 10:56:25 +0800 Subject: [winswitch] codec2 In-Reply-To: References: Message-ID: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> On 01/06/16 01:38, Michael Durkin wrote: > Im wondering how .. if its needed, im not sure , to use codec2 instead of > opus ... They are completely unrelated. * dec_avcodec2 is a video decoder which uses ffmpeg, it is needed for decoding h264, hevc, etc.. * opus is a sound codec Both are optional but recommended. If you have vorbis or even mp3, opus is probably not worth the effort if you are having problems. h264 on the other hand, is strongly recommended as it is the most efficient video codec. > I see a patch for V0.15 but not sure if it is already implements in V0.17 > code ... or use a run switch ... Please be specific. What distro? What patch? > Also i see a thread on the server (to client) for xpra sound but not one > for client microphone to server .... is that not possible ? I don't understand the question. As of version 0.15, the sound runs in a separate process, not thread. If you start the microphone forwarding, you will get an extra process. Cheers Antoine From kc7noa at gmail.com Wed Jun 1 04:24:03 2016 From: kc7noa at gmail.com (Michael Durkin) Date: Tue, 31 May 2016 20:24:03 -0700 Subject: [winswitch] codec2 In-Reply-To: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> References: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> Message-ID: Codec2 is for audio compression / low bit rates http://loyc-etc.blogspot.com/2012/09/opus-codec-to-end-all-codecs.html mentions that codec2 beats opus by a factor of 3 a little more info .. but i'm not sure codec2 is useful to xpra .... http://www.rowetel.com/blog/?page_id=452 Ubuntu 16 , only patch done is for Ubuntu/Debian ... Oh ... i think we both made the same mistake avcodec2 does not = codec2 On Tue, May 31, 2016 at 7:56 PM, Antoine Martin wrote: > On 01/06/16 01:38, Michael Durkin wrote: > > Im wondering how .. if its needed, im not sure , to use codec2 instead of > > opus ... > They are completely unrelated. > * dec_avcodec2 is a video decoder which uses ffmpeg, it is needed for > decoding h264, hevc, etc.. > * opus is a sound codec > > Both are optional but recommended. If you have vorbis or even mp3, opus > is probably not worth the effort if you are having problems. > h264 on the other hand, is strongly recommended as it is the most > efficient video codec. > > > I see a patch for V0.15 but not sure if it is already implements in V0.17 > > code ... or use a run switch ... > Please be specific. What distro? What patch? > > > Also i see a thread on the server (to client) for xpra sound but not one > > for client microphone to server .... is that not possible ? > I don't understand the question. > As of version 0.15, the sound runs in a separate process, not thread. > If you start the microphone forwarding, you will get an extra process. > > Cheers > Antoine > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From kc7noa at gmail.com Wed Jun 1 04:32:04 2016 From: kc7noa at gmail.com (Michael Durkin) Date: Tue, 31 May 2016 20:32:04 -0700 Subject: [winswitch] codec2 In-Reply-To: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> References: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> Message-ID: on the Xephyr window , using pavucontrol there is a device labled xpra on the capture tab .... that brings what ever speaker(?) output to the client speakers .... there is no reverse option for the microphone ..... I want the client microphone to be available to the server .... some times its there, some times it not ... im not sure why. Might be a function of bandwidth .... connection is over 802.11B -- i think 20mb/s ? connection should be ok, but i wonder if at times there bandwidth/speed drops. On Tue, May 31, 2016 at 7:56 PM, Antoine Martin wrote: > On 01/06/16 01:38, Michael Durkin wrote: > > Im wondering how .. if its needed, im not sure , to use codec2 instead of > > opus ... > They are completely unrelated. > * dec_avcodec2 is a video decoder which uses ffmpeg, it is needed for > decoding h264, hevc, etc.. > * opus is a sound codec > > Both are optional but recommended. If you have vorbis or even mp3, opus > is probably not worth the effort if you are having problems. > h264 on the other hand, is strongly recommended as it is the most > efficient video codec. > > > I see a patch for V0.15 but not sure if it is already implements in V0.17 > > code ... or use a run switch ... > Please be specific. What distro? What patch? > > > Also i see a thread on the server (to client) for xpra sound but not one > > for client microphone to server .... is that not possible ? > I don't understand the question. > As of version 0.15, the sound runs in a separate process, not thread. > If you start the microphone forwarding, you will get an extra process. > > Cheers > Antoine > _______________________________________________ > 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 Jun 1 07:24:47 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 1 Jun 2016 14:24:47 +0800 Subject: [winswitch] codec2 In-Reply-To: References: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> Message-ID: On 01/06/16 11:24, Michael Durkin wrote: > Codec2 is for audio compression / low bit rates So you're talking about this: https://en.wikipedia.org/wiki/Codec2 Xpra uses GStreamer for sound support in the python client and server and GStreamer has no support for codec2. You can find which codecs your client supports with: xpra attach --speaker-codec=help And for the server: xpra start --speaker-codec=help Even if it did have support for codec2, I don't see much point in trying to save a few bytes when opus or vorbis do an excellent job of it already, and the pixel updates are likely to dwarf the sound data (not the total, but discrete events). What we could do is provide more fine tuning over the existing sound codecs, in the same way that video compression has "speed" and "quality" knobs. Feel free to file a ticket for that. Cheers Antoine > http://loyc-etc.blogspot.com/2012/09/opus-codec-to-end-all-codecs.html > mentions that codec2 beats opus by a factor of 3 > > a little more info .. but i'm not sure codec2 is useful to xpra .... > > http://www.rowetel.com/blog/?page_id=452 > > Ubuntu 16 , only patch done is for Ubuntu/Debian ... > > Oh ... i think we both made the same mistake avcodec2 does not = codec2 > > On Tue, May 31, 2016 at 7:56 PM, Antoine Martin > wrote: > >> On 01/06/16 01:38, Michael Durkin wrote: >>> Im wondering how .. if its needed, im not sure , to use codec2 instead of >>> opus ... >> They are completely unrelated. >> * dec_avcodec2 is a video decoder which uses ffmpeg, it is needed for >> decoding h264, hevc, etc.. >> * opus is a sound codec >> >> Both are optional but recommended. If you have vorbis or even mp3, opus >> is probably not worth the effort if you are having problems. >> h264 on the other hand, is strongly recommended as it is the most >> efficient video codec. >> >>> I see a patch for V0.15 but not sure if it is already implements in V0.17 >>> code ... or use a run switch ... >> Please be specific. What distro? What patch? >> >>> Also i see a thread on the server (to client) for xpra sound but not one >>> for client microphone to server .... is that not possible ? >> I don't understand the question. >> As of version 0.15, the sound runs in a separate process, not thread. >> If you start the microphone forwarding, you will get an extra process. >> >> Cheers >> Antoine >> _______________________________________________ >> 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 Wed Jun 1 07:28:16 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 1 Jun 2016 14:28:16 +0800 Subject: [winswitch] codec2 In-Reply-To: References: <59676f34-5511-ae8c-884a-990efd65d6e3@nagafix.co.uk> Message-ID: On 01/06/16 11:32, Michael Durkin wrote: > on the Xephyr window , So now, you're using Xephyr - but I doubt this is relevant here. > using pavucontrol there is a device labled xpra on > the capture tab .... that brings what ever speaker(?) output to the client > speakers .... there is no reverse option for the microphone ..... Depends what version you are using. See also: https://xpra.org/trac/ticket/1141 https://xpra.org/trac/ticket/1110 > I want the client microphone to be available to the server .... some times > its there, some times it not ... im not sure why. Might be a function of > bandwidth .... connection is over 802.11B -- i think 20mb/s ? connection > should be ok, but i wonder if at times there bandwidth/speed drops. Not enough details. Please see: https://xpra.org/trac/wiki/ReportingBugs Cheers Antoine > > On Tue, May 31, 2016 at 7:56 PM, Antoine Martin > wrote: > >> On 01/06/16 01:38, Michael Durkin wrote: >>> Im wondering how .. if its needed, im not sure , to use codec2 instead of >>> opus ... >> They are completely unrelated. >> * dec_avcodec2 is a video decoder which uses ffmpeg, it is needed for >> decoding h264, hevc, etc.. >> * opus is a sound codec >> >> Both are optional but recommended. If you have vorbis or even mp3, opus >> is probably not worth the effort if you are having problems. >> h264 on the other hand, is strongly recommended as it is the most >> efficient video codec. >> >>> I see a patch for V0.15 but not sure if it is already implements in V0.17 >>> code ... or use a run switch ... >> Please be specific. What distro? What patch? >> >>> Also i see a thread on the server (to client) for xpra sound but not one >>> for client microphone to server .... is that not possible ? >> I don't understand the question. >> As of version 0.15, the sound runs in a separate process, not thread. >> If you start the microphone forwarding, you will get an extra process. >> >> Cheers >> Antoine >> _______________________________________________ >> 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 kc7noa at gmail.com Fri Jun 3 06:30:32 2016 From: kc7noa at gmail.com (Michael Durkin) Date: Thu, 2 Jun 2016 22:30:32 -0700 Subject: [winswitch] microphone and speakers Message-ID: Im thinking this is a stupid question ... does xpra need to have settings in paprefs set so that pulse audio is discoverable over network and network access to local sound devices ? From antoine at nagafix.co.uk Fri Jun 3 06:35:33 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Fri, 3 Jun 2016 12:35:33 +0700 Subject: [winswitch] microphone and speakers In-Reply-To: References: Message-ID: <2b0d33d5-b6d9-7798-3adf-55a9fbe41db8@nagafix.co.uk> On 03/06/16 12:30, Michael Durkin wrote: > Im thinking this is a stupid question ... This is not a stupid question at all. > does xpra need to have settings in paprefs set so that pulse audio is > discoverable over network and network access to local sound devices ? No, after capturing the sound data using gstreamer, xpra will use its own transport for forwarding the sound from / to the client. (including clients that do not run pulseaudio at all) Cheers Antoine From antoine at nagafix.co.uk Sat Jun 4 06:29:22 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 4 Jun 2016 12:29:22 +0700 Subject: [winswitch] black rectangle In-Reply-To: References: <87edcada-c534-9df1-5268-2826e6b9ea7f@nagafix.co.uk> Message-ID: <2440d3e6-ddd6-5d6e-a518-cdc70318bf0d@nagafix.co.uk> Please always CC the list. On 03/06/16 23:50, Ron Eggler wrote: > Hi Antoine, > > Thank tyou for your response, I tried out xpra_0.18.0-1_amd64.deb on the > server side and Xpra_Setup_0.18.0-r12647.exe on the client side and the > scaling was totally messed up so I had to revert back https://www.xpra.org/trac/wiki/ClientRendering#DesktopScaling > to xpra_0.15.10-1_amd64.deb & Xpra_Setup_0.16.3-r12203.exe The 0.16.x branch is no longer supported. > i al;sdo realized that just updating the Winsdows client wouldn't do the > trick, I hsad to upgrade both sides. That should not be the case, all supported versions should be compatible with each other. That said, beta versions may cause unwanted breakage. In this case: 0.15.x server with a 0.18.0beta client works fine here. Please provide more details. > Which beta version would you > consider the most stable combination? im ight give that a try then... Anything recent and supported, see: http://xpra.org/trac/wiki/Versions Cheers Antoine > > Thanks, > Ron > > On Wed, Jun 1, 2016 at 7:52 PM, Antoine Martin > wrote: > > On 02/06/16 01:38, Ron Eggler wrote: > > Hi Antoine, > > > > I'm using xpra 0.15.10 (server) and Windows client (0.16.1) on a Ubuntu > > 14.04 server. I'm stuck with Ubuntu 14.04 for now due to the IDE I'm > > using which is based on eclipse Juno (WindRiver workbench). Now, > > whenever I use the search tool (Ctrl+H) to search through my project, a > > black rectangle towards the bottom right of the windows shows up and as > > long as it's visible, any interactions with xpra applications from the > > same desktop are blocked. It disappears again after a few seconds > > (5-ish) and everything reverts to normal. > > Any idea how I can avoid this? > Sorry, none right now. > You may want to try a newer build, at the very least for the client, > there are also some newer builds for Ubuntu Trusty in the beta area: > https://xpra.org/beta/ > > Otherwise, please file a ticket include the "-d window" debug output. > > Cheers > Antoine > > > > > Thank you, > > Ron > > > > > > From antoine at nagafix.co.uk Sat Jun 4 06:43:29 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 4 Jun 2016 12:43:29 +0700 Subject: [winswitch] microphone and speakers In-Reply-To: References: <2b0d33d5-b6d9-7798-3adf-55a9fbe41db8@nagafix.co.uk> Message-ID: <9f3bebe7-9484-3439-9c0d-bda6661dab7a@nagafix.co.uk> Please always CC the list. On 03/06/16 12:47, Michael Durkin wrote: > ok .. i thought so ,, but am having a hard time getting microphone to > show on the server .. and im not getting sound from the server without > enabling paprefs stuff .... Please provide enough information, preferably in a ticket: http://xpra.org/trac/wiki/ReportingBugs Note: you have to use recent versions to get all the sound fixes. > If i want the client microphone to be shown/available on the server .. i > edit the client xpra.conf to have the microphone=on -- right? Yes, or you can enable it on the command line or at runtime from the system tray menu. Cheers Antoine > > On Thu, Jun 2, 2016 at 10:35 PM, Antoine Martin > wrote: > > On 03/06/16 12:30, Michael Durkin wrote: > > Im thinking this is a stupid question ... > This is not a stupid question at all. > > > does xpra need to have settings in paprefs set so that pulse audio is > > discoverable over network and network access to local sound devices ? > No, after capturing the sound data using gstreamer, xpra will use its > own transport for forwarding the sound from / to the client. (including > clients that do not run pulseaudio at all) > > Cheers > Antoine > _______________________________________________ > 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 Jun 4 11:13:48 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 4 Jun 2016 17:13:48 +0700 Subject: [winswitch] [ANNOUNCE] Xpra 0.17.3 (many fixes) Message-ID: -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This update fixes many issues in all areas, a few of those are leaks or important fixes. Updating is recommended. Release notes: * fix logging errors with libyuv module (hiding real errors) * fix memory handling in error cases with x264 encoder * fix video encoder and colourspace converter leak * fix rare delta encoding errors * fix dbus x11 dependency in RPM packaging * fix dependencies for RHEL 7.0 * fix DPI option miscalculation when used from the client * fix window aspect ratio hints handling * fix stripping of temporary build paths * fix sound subprocess stuck in paused state after an early error * fix H264 decoding in HTML5 client (disabled for now) * fix AES padding errors with HTML5 client * fix spurious import statements in NVENC codecs * fix crashes in X11 keyboard handling * fix compatibility with newer GCC versions * fix OSX and win32 shadow server key mappings * fix OSX shadow server disconnections with invalid RGB packet data * fix OSX shadow server crashes with webp * fix OSX shadow server errors with opus sound codec (disable it) * fix RGB compression algorithm reported in logging 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 -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAldSqdoACgkQGK2zHPGK1ruP0gCcDpqbWLwrE1hKjsamR7DOgtYj lnAAmgMmtqRx+iQ5m6qZzXFiQBy4M4iX =GMCd -----END PGP SIGNATURE----- From thomas.mainka at gmail.com Sat Jun 4 19:26:29 2016 From: thomas.mainka at gmail.com (Thomas Mainka) Date: Sat, 4 Jun 2016 20:26:29 +0200 Subject: [winswitch] Mouse stops working Message-ID: Hi, I am currently trying to track down a strange bug I run into from time to time: After a while the mouse stops working properly inside any Xpra windows, so the application becomes unresponsive. The strange thing though: the keyboard still works, and the mouse works again for a short time if you use the left Alt key, but stops working once you use a mouse button once. You can see any mouseover-effects (in like button bars) in the applications while the mouse works, and its gone once you click anything. If the application is having a custom cursor you can also tell the status of the mouse by the fact that the custom cursor is displayed: A non-working mouse cursor displays the standard mouse cursor of the client OS. The server is an x86_64 Arch Linux with the 0.17.3 I just compiled. The client however can be anything: Linux, Windows 10 or OSX - all have the same problems. Currently my assumption is that this may not be even a Xpra bug, because the first time I remember it occurring was after an upgrade to Xorg 1.18.3. As this looks like a server side problem, I tried to debug the problem on the server, but "-d all" is pretty talkative. There is a "-d keyboard" debug level, but no "-d mouse" one. Any hints on how to track down the underlying problem? Regards, Thomas From antoine at nagafix.co.uk Sun Jun 5 05:50:55 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sun, 5 Jun 2016 11:50:55 +0700 Subject: [winswitch] Mouse stops working In-Reply-To: References: Message-ID: <8a189eda-c887-1d29-dc7e-f3c9c0250b98@nagafix.co.uk> On 05/06/16 01:26, Thomas Mainka wrote: > Hi, > > > I am currently trying to track down a strange bug I run into from time > to time: After a while the mouse stops working properly inside any > Xpra windows, so the application becomes unresponsive. The strange > thing though: the keyboard still works, and the mouse works again for > a short time if you use the left Alt key, but stops working once you > use a mouse button once. You can see any mouseover-effects (in like > button bars) in the applications while the mouse works, and its gone > once you click anything. That's very odd. The server is clearly receiving the mouse position packets since you get the mouseover effects. Maybe the event gets delivered to the wrong window and/or the focus ends up in the wrong place. > If the application is having a custom cursor you can also tell the > status of the mouse by the fact that the custom cursor is displayed: > A non-working mouse cursor displays the standard mouse cursor of the > client OS. > > The server is an x86_64 Arch Linux with the 0.17.3 I just compiled. > The client however can be anything: Linux, Windows 10 or OSX - all > have the same problems. Currently my assumption is that this may not > be even a Xpra bug, because the first time I remember it occurring was > after an upgrade to Xorg 1.18.3. This would not be the first regression in Xorg 1.18.x stable updates: https://bugs.freedesktop.org/show_bug.cgi?id=95234 > As this looks like a server side problem, I tried to debug the problem > on the server, but "-d all" is pretty talkative. There is a "-d > keyboard" debug level, but no "-d mouse" one. There is a "-d mouse", just tested now and it worked fine here. > Any hints on how to track down the underlying problem? I would try to downgrade Xorg to an older version, look at "xpra info | grep cursor" as you move the mouse. Maybe also look for the "focus" info. It is worth trying to downgrade xpra to v0.14.x to rule out a regression. Maybe running "xev" or a simple xterm will help figure things out. Failing that, I think you may have to file an xpra bug report. Cheers Antoine > > > Regards, > Thomas > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users > From thomas.mainka at gmail.com Sun Jun 5 10:16:29 2016 From: thomas.mainka at gmail.com (Thomas Mainka) Date: Sun, 5 Jun 2016 11:16:29 +0200 Subject: [winswitch] Mouse stops working In-Reply-To: <8a189eda-c887-1d29-dc7e-f3c9c0250b98@nagafix.co.uk> References: <8a189eda-c887-1d29-dc7e-f3c9c0250b98@nagafix.co.uk> Message-ID: Hi, On Sun, Jun 5, 2016 at 6:50 AM, Antoine Martin wrote: > That's very odd. The server is clearly receiving the mouse position > packets since you get the mouseover effects. > Maybe the event gets delivered to the wrong window and/or the focus ends > up in the wrong place. >From the "xpra -d mouse" log Xpra clearly sends the mouse events to an xev window: 2016-06-05 11:01:44,465 raising WindowModel(0xe00001) 2016-06-05 11:01:44,465 move_pointer(10, (637, 909)) Its just that the xev window only gets keypresses, and the FocusIn/FocusOut events: FocusIn event, serial 33, synthetic NO, window 0xe00001, mode NotifyNormal, detail NotifyNonlinear KeymapNotify event, serial 33, synthetic NO, window 0x0, keys: 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 KeyPress event, serial 33, synthetic NO, window 0xe00001, root 0x25d, subw 0x0, time 1555897924, (38,48), root:(662,819), state 0x10, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XmbLookupString gives 0 bytes: XFilterEvent returns: False KeyRelease event, serial 36, synthetic NO, window 0xe00001, root 0x25d, subw 0x0, time 1555898048, (38,48), root:(662,819), state 0x18, keycode 64 (keysym 0xffe9, Alt_L), same_screen YES, XLookupString gives 0 bytes: XFilterEvent returns: False FocusOut event, serial 36, synthetic NO, window 0xe00001, mode NotifyNormal, detail NotifyNonlinear "xpra info" on the other hand properly updates the cursor position, and the focus seems right, too: state.focused=12 [...] window.12.batch.focus=(0, 100) window.12.batch.focus.has_focus=True window.12.focused=True > There is a "-d mouse", just tested now and it worked fine here. Ah, my bad. I went through "-d help" and didn't see that. Interestingly, the Alt_L trick does not work on all applications. Firefox for example does not process anything in this state - except for the menus, but not the menubar itself. So you can't click on "File", but once you open File with Alt-F that menu works. > I would try to downgrade Xorg to an older version, look at "xpra info | > grep cursor" as you move the mouse. Maybe also look for the "focus" info. > It is worth trying to downgrade xpra to v0.14.x to rule out a > regression. Maybe running "xev" or a simple xterm will help figure > things out. I will try to downgrade Xorg to 1.17 first, but due to ABI changes I need to downgrade all the drivers, too, which is a PITA on Arch. Regards, Thomas From ron.eggler at gmail.com Sun Jun 5 18:47:26 2016 From: ron.eggler at gmail.com (Ron Eggler) Date: Sun, 5 Jun 2016 10:47:26 -0700 Subject: [winswitch] black rectangle In-Reply-To: <2440d3e6-ddd6-5d6e-a518-cdc70318bf0d@nagafix.co.uk> References: <87edcada-c534-9df1-5268-2826e6b9ea7f@nagafix.co.uk> <2440d3e6-ddd6-5d6e-a518-cdc70318bf0d@nagafix.co.uk> Message-ID: On Fri, Jun 3, 2016 at 10:29 PM, Antoine Martin wrote: > [SNIP] > > > > > Thank tyou for your response, I tried out xpra_0.18.0-1_amd64.deb on the > > server side and Xpra_Setup_0.18.0-r12647.exe on the client side and the > > scaling was totally messed up so I had to revert back > https://www.xpra.org/trac/wiki/ClientRendering#DesktopScaling Alright - so I'll probably give it another try then next week when I get to it! Thanks! > > > > to xpra_0.15.10-1_amd64.deb & Xpra_Setup_0.16.3-r12203.exe > The 0.16.x branch is no longer supported. > > > i also realized that just updating the Winsdows client wouldn't do the > > trick, I hsad to upgrade both sides. > That should not be the case, all supported versions should be compatible > with each other. That said, beta versions may cause unwanted breakage. > > In this case: 0.15.x server with a 0.18.0beta client works fine here. > Please provide more details. > I would still use 0.15.10 on the server and try to connect to it using the upgraded Windows client 0.18.0-r12647 The client wouldn't let me connect, It asked for the password but then threw me right back to the xpra client giving me an error that it's unable to connect (sorry missing the exact terminology of the red caption here). > > > Which beta version would you > > consider the most stable combination? im ight give that a try then... > Anything recent and supported, see: > http://xpra.org/trac/wiki/Versions Yeah, I'll probably have to give it another shot trying to build something more up-to-date for my old trusty setup as long as I'm stuck with it. Not sure if we're able to move on to 16.04 in the foreseeable future Thanks, Ron > > > > > On Wed, Jun 1, 2016 at 7:52 PM, Antoine Martin > > wrote: > > > > On 02/06/16 01:38, Ron Eggler wrote: > > > Hi Antoine, > > > > > > I'm using xpra 0.15.10 (server) and Windows client (0.16.1) on a > Ubuntu > > > 14.04 server. I'm stuck with Ubuntu 14.04 for now due to the IDE > I'm > > > using which is based on eclipse Juno (WindRiver workbench). Now, > > > whenever I use the search tool (Ctrl+H) to search through my > project, a > > > black rectangle towards the bottom right of the windows shows up > and as > > > long as it's visible, any interactions with xpra applications from > the > > > same desktop are blocked. It disappears again after a few seconds > > > (5-ish) and everything reverts to normal. > > > Any idea how I can avoid this? > > Sorry, none right now. > > You may want to try a newer build, at the very least for the client, > > there are also some newer builds for Ubuntu Trusty in the beta area: > > https://xpra.org/beta/ > > > > Otherwise, please file a ticket include the "-d window" debug output. > > > > Cheers > > Antoine > > > > > > > > Thank you, > > > Ron > > > > > > > > > > > > From antoine at devloop.org.uk Mon Jun 6 06:58:37 2016 From: antoine at devloop.org.uk (Antoine Martin) Date: Mon, 6 Jun 2016 12:58:37 +0700 Subject: [winswitch] xpra and distro support In-Reply-To: <575502F7.7070608@rolf.leggewie.biz> References: <575502F7.7070608@rolf.leggewie.biz> Message-ID: <6f8a0ba3-8924-8476-98cd-0f90a76d88f0@devloop.org.uk> Please always CC the mailing list. On 06/06/16 11:58, Rolf Leggewie wrote: > Hello, > > thank you for providing xpra. I've long hoped to be able to have a "GNU > screen for X" and xpra promises to deliver that. I've tried for a few > years from time to time, but sadly xpra never delivered for me as a > user. If I always were compiling the latest upstream from scratch that > might be different. It's not that I can't do this (I'm a Debian > Maintainer), but that I don't run gentoo for a reason. > > I have the impression that xpra is constantly and rapidly evolving > without sufficient concern for long-term stability. This might be fine > if you are only concerned with people compiling from source. But for > distributions you need a horizon of several years. We have an LTS version, supported for years. What downstream decides to use is not up to us. For details, see: http://xpra.org/trac/wiki/Building > So, here is my story. My first attempt to use xpra was fraught with > severe stability issues as reported in > https://bugs.launchpad.net/ubuntu/bugs/1159871. I was running the > latest long-term support, stable release of Ubuntu at the time which had > been released less than a year prior. Nonetheless, I was told by the > Debian maintainer that I was using a "very old version of xpra". The > problem itself wasn't looked into. At the time, xpra was very young at > version 0.0.7 and that might be excusable. I backported the package > from unstable, the problem remained and was still not looked into. Fixed link: https://bugs.launchpad.net/ubuntu/+source/xpra/+bug/1159871 This ticket contains a number of issues, most of which I remember fixing a long time ago. The proxy-start one just looks wrong though. Things that aren't reported upstream may not get fixed in a timely manner. > After several years, I tried again. Of course, I am still running LTS > because I have other things to do than having a constant headache about > random bleeding edge software bringing my computer down and consuming my > time. I'm sure you understand. I connected from a fully updated Ubuntu > trusty machine to an equally fully updated Raspbian Jessie machine. The > Raspbian machine would go to 100% CPU for the xpra process on the > simplest of tasks like hitting enter in xterm which I reported as a bug > to Debian. The ticket was closed immediately as "you are using ancient, > unsupported software". IMO, this means xpra should not even be part of > a distribution since it's not supported for the full cycle of a > release. In fact, it's deemed "ancient" shortly after release of a > distro. I don't think this is what you as upstream want. As per above: this is a question for downstream. From our end, we simply do not have the manpower to support those outdated versions. > I did not give up and looked into backporting newer releases again. > Then I found out that you are not releasing the source code for your > binary packages. That's a GPL violation. Please kindly fix that. That's incorrect: every single line of source code and the patches required to workaround Debian quirks (libav, headers, etc) are available for download and documented. See: http://xpra.org/trac/wiki/Building We will not provide all-in-one source bundle archives for every combination of version and distro out there. Nobody does, and this is not required by the GPL either. > What's more troublesome and the strongest motivator for this mail is > that apparently you broke backward compatibility without documenting it > and generally giving it much concern. As you can see in > https://bugs.debian.org/805751 and > https://bugs.launchpad.net/bugs/1589336 apparently there is xpra 0.15.0 > and later versus prior versions. Those two camps cannot talk to each > other, period. The prior versions include fairly recent stable releases > of Debian and Ubuntu. If there is something you can do now to have > these two groups talking to each other again, that would be fantastic. Again, IIRC, this bug was fixed a long time ago. I doubt this is still a problem with any supported version. That said, most of the testing is done using the python client with rencode (except the HTML5 client which uses bencode) - so issues like this one may go unnoticed from time to time. Again, we don't have the manpower to test every combination of every supported version and every distro + architecture out there (each with different combinations of installed recommends / suggests dependencies). > At the very minimum, xpra should emit an error message if the opposite > end is older and incompatible. It does already. This is something else. > Last, apparently you forgot to include python-rencode as a depends in > your binary packages, even though that doesn't fully prevent problems > related to it. python-rencode is a hard dependency since v0.15.x which dropped support for older distros. It isn't a hard dependency in v0.14.x and earlier because many of the older distros do not have python-rencode at all, and xpra still works fine without it, just a little bit more slowly. > Once again, thank you for your work on xpra. Cheers Antoine > > Regards > > Rolf Leggewie > From antoine at nagafix.co.uk Mon Jun 6 07:07:07 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 6 Jun 2016 13:07:07 +0700 Subject: [winswitch] black rectangle In-Reply-To: References: <87edcada-c534-9df1-5268-2826e6b9ea7f@nagafix.co.uk> <2440d3e6-ddd6-5d6e-a518-cdc70318bf0d@nagafix.co.uk> Message-ID: <3bfc94b1-a7d2-49b3-0190-4faa43115111@nagafix.co.uk> (snip) > > to xpra_0.15.10-1_amd64.deb & Xpra_Setup_0.16.3-r12203.exe > The 0.16.x branch is no longer supported. > > > i also realized that just updating the Winsdows client wouldn't do the > > trick, I hsad to upgrade both sides. > That should not be the case, all supported versions should be compatible > with each other. That said, beta versions may cause unwanted breakage. > > In this case: 0.15.x server with a 0.18.0beta client works fine here. > Please provide more details. > > > I would still use 0.15.10 on the server and try to connect to it using > the upgraded Windows client 0.18.0-r12647 > The client wouldn't let me connect, It asked for the password but then > threw me right back to the xpra client giving me an error that it's > unable to connect (sorry missing the exact terminology of the red > caption here). Assuming that you are using SSH mode: since Windows does not provide any SSH clients we can use for transport, we ship putty / plink. In versions 0.17.x onwards, we bundle a newer version of putty which fixes compatibility with newer version of OpenSSH. (this is only used with Windows-7 onwards, XP is stuck with the old version of putty) It is possible that this update causes other compatibility issues. You should be able diagnose this by running from the Xpra_cmd command line tool - which will print more messages, or by connecting from a non-MSWindows client, or looking at your ssh server's log file. Cheers Antoine > > > > Which beta version would you > > consider the most stable combination? im ight give that a try then... > Anything recent and supported, see: > http://xpra.org/trac/wiki/Versions > > > Yeah, I'll probably have to give it another shot trying to build > something more up-to-date for my old trusty setup as long as I'm stuck > with it. Not sure if we're able to move on to 16.04 in the foreseeable > future > > Thanks, > Ron > > > > > > On Wed, Jun 1, 2016 at 7:52 PM, Antoine Martin > > >> wrote: > > > > On 02/06/16 01:38, Ron Eggler wrote: > > > Hi Antoine, > > > > > > I'm using xpra 0.15.10 (server) and Windows client (0.16.1) > on a Ubuntu > > > 14.04 server. I'm stuck with Ubuntu 14.04 for now due to the > IDE I'm > > > using which is based on eclipse Juno (WindRiver workbench). Now, > > > whenever I use the search tool (Ctrl+H) to search through my > project, a > > > black rectangle towards the bottom right of the windows > shows up and as > > > long as it's visible, any interactions with xpra > applications from the > > > same desktop are blocked. It disappears again after a few > seconds > > > (5-ish) and everything reverts to normal. > > > Any idea how I can avoid this? > > Sorry, none right now. > > You may want to try a newer build, at the very least for the > client, > > there are also some newer builds for Ubuntu Trusty in the beta > area: > > https://xpra.org/beta/ > > > > Otherwise, please file a ticket include the "-d window" debug > output. > > > > Cheers > > Antoine > > > > > > > > Thank you, > > > Ron > > > > > > > > > > > > From foss at rolf.leggewie.biz Mon Jun 6 11:49:33 2016 From: foss at rolf.leggewie.biz (Rolf Leggewie) Date: Mon, 6 Jun 2016 18:49:33 +0800 Subject: [winswitch] xpra and distro support In-Reply-To: <6f8a0ba3-8924-8476-98cd-0f90a76d88f0@devloop.org.uk> References: <575502F7.7070608@rolf.leggewie.biz> <6f8a0ba3-8924-8476-98cd-0f90a76d88f0@devloop.org.uk> Message-ID: <5755553D.70705@rolf.leggewie.biz> Antoine, thank you for your second mail. On 06.06.2016 13:58, Antoine Martin wrote: > Please always CC the mailing list. I wasn't aware of the ML. Will do now. > We have an LTS version, supported for years. Awesome! That would be version 0.14.x which fortunately is what's in Debian stable. Makes me wonder why the Debain Maintainer deemed it necessary to backport 0.16.x to stable-backports. Apparently Debian Maintainers consider 0.14.x ancient and unsupported, a bug report against it ("high CPU usage on Raspbian") was rejected. Go figure. But why are you breaking compatibility with your LTS version in the latest HEAD? Or is that no longer the case as you seem to indicate further down? >> What's more troublesome and the strongest motivator for this mail is >> that apparently you broke backward compatibility without documenting it[...] > Again, IIRC, this bug was fixed a long time ago. The problem was verified with version 0.16.3 by me personally. That version was released upstream about two months ago. So the constant claims of "fixed long time ago" become kind of irritating after a while. I'd be glad to hear the incompatibility between your LTS version and 0.15.x forward has been fixed somewhere in HEAD and I'd look into getting that patch accepted into Debian and Ubuntu. > Fixed link: > https://bugs.launchpad.net/ubuntu/+source/xpra/+bug/1159871 > This ticket contains a number of issues, most of which I remember fixing > a long time ago. The proxy-start one just looks wrong though. > Things that aren't reported upstream may not get fixed in a timely manner. Sure. I'm not complaining. I simply was unable to use the software productively and moved on. Such is sometimes the life for an LTS user. You then revisit the issue when you are on the next LTS. It is kind of comical that in your first mail you sent me you seemed to propagate the notion of "users of a distro should not bother upstream with bug reports, they should be dealt with at the distro level". I think that's actually true for the first few stages of bug triage. >> After several years, I tried again. Of course, I am still running LTS >> because I have other things to do than having a constant headache about >> random bleeding edge software bringing my computer down and consuming my >> time. I'm sure you understand. I connected from a fully updated Ubuntu >> trusty machine to an equally fully updated Raspbian Jessie machine. The >> Raspbian machine would go to 100% CPU for the xpra process on the >> simplest of tasks like hitting enter in xterm which I reported as a bug >> to Debian. The ticket was closed immediately as "you are using ancient, >> unsupported software". IMO, this means xpra should not even be part of >> a distribution since it's not supported for the full cycle of a >> release. In fact, it's deemed "ancient" shortly after release of a >> distro. I don't think this is what you as upstream want. > As per above: this is a question for downstream. From our end, we simply > do not have the manpower to support those outdated versions. I understand. And that's where I think ideally, Distros and especially the maintainers (Debian) or bug triagers (Ubuntu) have a positive role to help upstream IMO. For one, distros provide you with many eyeballs and corner cases. But the bug triage needs filtering to make sure upstream gets quality feedback. BUT, above problem is with your LTS version! So, if you are serious about it, you ought to not pull the card of "this software is too old for us to look into (lack of manpower)". >> I did not give up and looked into backporting newer releases again. >> Then I found out that you are not releasing the source code for your >> binary packages. That's a GPL violation. Please kindly fix that. > That's incorrect: every single line of source code and the patches > required to workaround Debian quirks (libav, headers, etc) are available > for download and documented. See: > http://xpra.org/trac/wiki/Building AFAICS, that's still missing the packaging information. Where can I see for example the debian/control file of version 0.14.19-1 as published at http://xpra.org/dists/trusty/main/binary-i386/ in binary form? http://xpra.org/src/xpra-0.14.19.tar.bz2 unsurprisingly doesn't have it. Even in svn I can't find the relevant tags, but it's well possible I'm looking in the wrong place (http://xpra.org/svn/Xpra/tags/v0.14.x/ is what I tried). GPL requires the full source (that includes meta-data such as packaging) be distributed alongside the binaries. Salut Rolf From antoine at devloop.org.uk Sat Jun 11 11:11:45 2016 From: antoine at devloop.org.uk (Antoine Martin) Date: Sat, 11 Jun 2016 17:11:45 +0700 Subject: [winswitch] xpra and distro support In-Reply-To: <5755553D.70705@rolf.leggewie.biz> References: <575502F7.7070608@rolf.leggewie.biz> <6f8a0ba3-8924-8476-98cd-0f90a76d88f0@devloop.org.uk> <5755553D.70705@rolf.leggewie.biz> Message-ID: <996e2894-2943-c932-4dea-0b5461b7f882@devloop.org.uk> On 06/06/16 17:49, Rolf Leggewie wrote: > Antoine, > > thank you for your second mail. > > On 06.06.2016 13:58, Antoine Martin wrote: >> Please always CC the mailing list. > > I wasn't aware of the ML. Will do now. > >> We have an LTS version, supported for years. > > Awesome! That would be version 0.14.x which fortunately is what's in > Debian stable. Makes me wonder why the Debain Maintainer deemed it > necessary to backport 0.16.x to stable-backports. Apparently Debian > Maintainers consider 0.14.x ancient and unsupported, a bug report > against it ("high CPU usage on Raspbian") was rejected. Go figure. > > But why are you breaking compatibility with your LTS version in the > latest HEAD? Or is that no longer the case as you seem to indicate > further down? Like I said already, you use an outdated version with known bugs, including this particular one which causes compatibility issues. >>> What's more troublesome and the strongest motivator for this mail is >>> that apparently you broke backward compatibility without documenting it[...] >> Again, IIRC, this bug was fixed a long time ago. > > The problem was verified with version 0.16.3 by me personally. That > version was released upstream about two months ago. So the constant > claims of "fixed long time ago" become kind of irritating after a > while. I'd be glad to hear the incompatibility between your LTS version > and 0.15.x forward has been fixed somewhere in HEAD and I'd look into > getting that patch accepted into Debian and Ubuntu. I don't have time to scour the commit log for the specific bug that interests you. Especially since I've already done the cherry picking when backporting from trunk. >> Fixed link: >> https://bugs.launchpad.net/ubuntu/+source/xpra/+bug/1159871 >> This ticket contains a number of issues, most of which I remember fixing >> a long time ago. The proxy-start one just looks wrong though. >> Things that aren't reported upstream may not get fixed in a timely manner. > > Sure. I'm not complaining. I simply was unable to use the software > productively and moved on. Such is sometimes the life for an LTS user. > You then revisit the issue when you are on the next LTS. Yes, like the wiki clearly says: the version of Xpra in Debian and Ubuntu LTS is fundamentally broken, don't use it. Perfectly exemplified by this thread. You seem to dislike this statement, but that does not make it less true. > It is kind of comical that in your first mail you sent me you seemed to > propagate the notion of "users of a distro should not bother upstream > with bug reports, they should be dealt with at the distro level". I > think that's actually true for the first few stages of bug triage. If the distro chooses to distribute an unsupported version with known bugs, absolutely. Otherwise, bug reports are always welcome. >>> After several years, I tried again. Of course, I am still running LTS >>> because I have other things to do than having a constant headache about >>> random bleeding edge software bringing my computer down and consuming my >>> time. I'm sure you understand. I connected from a fully updated Ubuntu >>> trusty machine to an equally fully updated Raspbian Jessie machine. The >>> Raspbian machine would go to 100% CPU for the xpra process on the >>> simplest of tasks like hitting enter in xterm which I reported as a bug >>> to Debian. The ticket was closed immediately as "you are using ancient, >>> unsupported software". IMO, this means xpra should not even be part of >>> a distribution since it's not supported for the full cycle of a >>> release. In fact, it's deemed "ancient" shortly after release of a >>> distro. I don't think this is what you as upstream want. >> As per above: this is a question for downstream. From our end, we simply >> do not have the manpower to support those outdated versions. > > I understand. And that's where I think ideally, Distros and especially > the maintainers (Debian) or bug triagers (Ubuntu) have a positive role > to help upstream IMO. For one, distros provide you with many eyeballs > and corner cases. But the bug triage needs filtering to make sure > upstream gets quality feedback. > > BUT, above problem is with your LTS version! AFAICT, it's not. It is with the outdated Debian / Ubuntu version. But I may well be wrong since this email thread is digressing fast. If that's the case, I'm sure your issue can be fixed very quickly, given enough details. > So, if you are serious > about it, you ought to not pull the card of "this software is too old > for us to look into (lack of manpower)". Let me state again: please reproduce this problem with a supported version without all those known bugs. >>> I did not give up and looked into backporting newer releases again. >>> Then I found out that you are not releasing the source code for your >>> binary packages. That's a GPL violation. Please kindly fix that. >> That's incorrect: every single line of source code and the patches >> required to workaround Debian quirks (libav, headers, etc) are available >> for download and documented. See: >> http://xpra.org/trac/wiki/Building > > AFAICS, that's still missing the packaging information. Where can I see > for example the debian/control file of version 0.14.19-1 as published at > http://xpra.org/dists/trusty/main/binary-i386/ in binary form? > http://xpra.org/src/xpra-0.14.19.tar.bz2 unsurprisingly doesn't have > it. Even in svn I can't find the relevant tags, but it's well possible > I'm looking in the wrong place (http://xpra.org/svn/Xpra/tags/v0.14.x/ > is what I tried). GPL requires the full source (that includes meta-data > such as packaging) be distributed alongside the binaries. http://xpra.org/trac/browser/xpra/tags/v0.14.x/debian/control?rev=8593 Cheers Antoine > > Salut > > Rolf > From alton at augie.edu Mon Jun 27 18:42:22 2016 From: alton at augie.edu (Drew Alton) Date: Mon, 27 Jun 2016 12:42:22 -0500 Subject: [winswitch] older version of winswitch Message-ID: Hello, I need to install an old version of winswitch. I am trying to install winswitch and I've discovered the computer I am connecting to has an old enough version of winswich that I get an error saying "incompatible remote version '0.8.8': remote version is too old, sorry. " It appears the remote machine "can't" be updated to something new so I have to find away to install an older version on the local machine. On https://winswitch.org/src/ I find a collection of files. I'm guessing I could use one of those. Are there any instructions for installing older versions? -Drew From antoine at nagafix.co.uk Thu Jun 30 11:49:59 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 30 Jun 2016 12:49:59 +0200 Subject: [winswitch] older version of winswitch In-Reply-To: References: Message-ID: <989f88cd-0e76-bcbc-801b-6b5e91320bbf@nagafix.co.uk> On 27/06/16 19:42, Drew Alton wrote: > Hello, > I need to install an old version of winswitch. > I am trying to install winswitch and I've discovered the computer I am > connecting to has an old enough version of winswich that I get an error > saying "incompatible remote version '0.8.8': remote version is too old, > sorry. " It appears the remote machine "can't" be updated to something new > so I have to find away to install an older version on the local machine. > On https://winswitch.org/src/ I find a collection of files. I'm > guessing I could use one of those. Are there any instructions for > installing older versions? You are looking for binaries not source, so try here: http://xpra.org/dists/ I would seriously consider updating to a newer version though, 0.8.8 is ancient, buggy, insecure and crash prone. For more details see some of the issues recorded on this page: http://xpra.org/trac/wiki/Packaging Cheers Antoine > -Drew > _______________________________________________ > 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 Thu Jun 30 12:03:21 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 30 Jun 2016 13:03:21 +0200 Subject: [winswitch] [ANNOUNCE] Xpra 0.17.4 (important fixes) Message-ID: <8098d8d7-1375-cc77-48d7-0c194457bd07@nagafix.co.uk> Hi, This update fixes some important issues, see release notes below. Updating is strongly recommended. Release notes: * fix severe regression in damage handling * fix lossless refresh causing endless loops * fix path stripping during packaging * fix password leak in server log file * fix keyboard layout change handling * fix openSUSE RPM packaging dependencies * fix video region API stickyness * fix application iconification support * fix XShape performance when scaling * fix file transfer packet handling and checksum validation * fix webcam forwarding * fix spurious pulseaudio exit message on shutdown * CUDA 8 and Pascal GPU optimization support * disable webp (black rectangles with some versions) 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 bjorn.forsman at gmail.com Thu Jun 30 12:35:49 2016 From: bjorn.forsman at gmail.com (=?UTF-8?Q?Bj=C3=B8rn_Forsman?=) Date: Thu, 30 Jun 2016 13:35:49 +0200 Subject: [winswitch] [ANNOUNCE] Xpra 0.17.4 (important fixes) In-Reply-To: <8098d8d7-1375-cc77-48d7-0c194457bd07@nagafix.co.uk> References: <8098d8d7-1375-cc77-48d7-0c194457bd07@nagafix.co.uk> Message-ID: On 30 June 2016 at 13:03, Antoine Martin wrote: > Hi, > > This update fixes some important issues, see release notes below. > Updating is strongly recommended. Should users of 0.16.x also update? Or is it mostly for 0.17.x users? I'm asking because in NixOS 16.03 we have the 0.16.2 version, and I'm wondering whether to bump it to 0.17.x (to what we have in the unstable/rolling release). Best regards, Bj?rn Forsman From antoine at nagafix.co.uk Thu Jun 30 12:38:20 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 30 Jun 2016 13:38:20 +0200 Subject: [winswitch] [ANNOUNCE] Xpra 0.17.4 (important fixes) In-Reply-To: References: <8098d8d7-1375-cc77-48d7-0c194457bd07@nagafix.co.uk> Message-ID: On 30/06/16 13:35, Bj?rn Forsman wrote: > On 30 June 2016 at 13:03, Antoine Martin wrote: >> Hi, >> >> This update fixes some important issues, see release notes below. >> Updating is strongly recommended. > > Should users of 0.16.x also update? Or is it mostly for 0.17.x users? Users of 0.16.x should have moved to 0.17.x by now as that branch is no longer supported. See: http://xpra.org/trac/wiki/Versions > I'm asking because in NixOS 16.03 we have the 0.16.2 version, and I'm > wondering whether to bump it to 0.17.x (to what we have in the > unstable/rolling release). That sounds like a good idea to me. Cheers Antoine > > Best regards, > Bj?rn Forsman >