From ron.eggler at gmail.com Mon Feb 1 17:29:09 2016 From: ron.eggler at gmail.com (Ron Eggler) Date: Mon, 1 Feb 2016 09:29:09 -0800 Subject: [winswitch] fonts don't scale nicely in Eclipse Message-ID: Hi, I finally got Xpra on my Ubuntu 14.04 machine working by using 0.15.10 (rather than the supplied version from the Trusty repo). I connect to it with the Windows client and am sing Eclipse as the application to display. Now, the rendering is happening on a screen with a resolution of 1366 x 768 and turns out that the fonts are not being displayed very nicely. it's usable but could definitely be better. Is there any way I can improve the font rendering from within the Xpra client (on Win7)? Thank you, Ron -- Ron Eggler 1804 - 1122 Gilford St. Vancouver, BC V6G 2P5 (778) 230-9442 From antoine at nagafix.co.uk Mon Feb 1 18:02:37 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 1 Feb 2016 10:02:37 -0800 Subject: [winswitch] fonts don't scale nicely in Eclipse In-Reply-To: References: Message-ID: <56AF9DBD.8050306@nagafix.co.uk> On 01/02/16 09:29, Ron Eggler wrote: > Hi, > > I finally got Xpra on my Ubuntu 14.04 machine working by using 0.15.10 > (rather than the supplied version from the Trusty repo). > I connect to it with the Windows client and am sing Eclipse as the > application to display. Now, the rendering is happening on a screen with a > resolution of 1366 x 768 and turns out that the fonts are not being > displayed very nicely. Can you be more specific? Is it a size issue or sub-pixel rendering or something else? > it's usable but could definitely be better. Is there > any way I can improve the font rendering from within the Xpra client (on > Win7)? The problem is likely to be caused by Ubuntu... and there is a solution but it is non trivial to get it running: Ubuntu uses Xvfb, other distros use Xdummy. See: http://xpra.org/trac/wiki/Xdummy Fedora and CentOS also have patched dummy drivers in their RPM repositories, which allows us to improve DPI handling, see also: http://xpra.org/trac/wiki/DPI And in particular: http://xpra.org/trac/ticket/882 Cheers Antoine > > Thank you, > Ron > From antoine at nagafix.co.uk Mon Feb 8 20:31:30 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 8 Feb 2016 12:31:30 -0800 Subject: [winswitch] [ANNOUNCE] [LTS] xpra 0.14.34 (minor fixes) Message-ID: <56B8FB22.8020300@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This update contains a few minor fixes, mostly cosmetic ones. There is no urgency to update if your were not affected by any of these bugs. The list of bugs which have been fixed in newer branches and have not been applied to this branch keeps on growing, if possible, please consider moving to a newer version. The only noteworthy change is the removal of our native webp codec on RPM platforms which do not have a sufficiently new webp library (ie: CentOS and openSUSE). Shipping our private build of this library seems to have caused conflicts with newer versions of python-Pillow, which links against the system webp library. The Fedora builds have been switched to using the system library, which is recent enough in that distribution. Release notes: * fix OSX crashes with python optimizations enable via env var * fix OSX client preventing system shutdown * fix OSX shadow server warning * fix xpra upgrade * fix build for FreeBSD DragonFly * fix FreeBSD socket library location * fix cleanup error on win32 shadow servers exit * fix RPM dependency: we need "which" for the Xdummy wrapper * fix spurious warnings when connecting very early to a server * fix webp library conflicts * fix magic key border toggle * blacklist more spellings of the Intel driver name * add new shortcut workaround for showing the system tray menu * reduce log spam when pulseaudio is not reachable 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 iEYEARECAAYFAla4+x0ACgkQGK2zHPGK1rt98wCfWys81h/vB5W9A++QodjLSej5 m0cAniJErnotMd17ouOyLjwCTd/7COkP =fZIp -----END PGP SIGNATURE----- From antoine at nagafix.co.uk Mon Feb 8 23:16:50 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Mon, 8 Feb 2016 15:16:50 -0800 Subject: [winswitch] [ANNOUNCE] xpra 0.16.2 (minor fixes) Message-ID: <56B921E2.1050209@nagafix.co.uk> -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hi, This minor update contains a few fixes, including two regressions introduced in the 0.16.x release: window focus and decorations handling, everything else is mostly cosmetic. Just like with the 0.14.34 release, we now only build the native webp codec on Fedora. Unless you were affected by one of those issues, there is no urgency to update. Release notes: * fix subcommand logging clutter * fix clean build target (failed to clean some html files) * fix focus regression * fix client message on server upgrade * fix opus sound codec bundling on OSX * fix exception logging on MS Windows exit errors * fix missing window icons after window re-initialization * fix NVENC crashes with some card / driver combinations * fix system tray location mapping when scaling is active * fix forwarding of network printers on MS Windows * fix webp library conflicts * fix magic key border toggle * fix window decorations flag detection * fix current working directory of start commands * include workaround for some Java applications (disabled) * reduce the amount of default "desktop-scaling" applied * filter out more problematic desktop environment variables * skip comments when showing command line help * remove confusing unused code 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 PS: It looks like I may have accidentally pushed the RPM repositories early, so you may need to run a "yum clean metadata" if updating fails. -----BEGIN PGP SIGNATURE----- Version: GnuPG v2 iEYEARECAAYFAla5IeIACgkQGK2zHPGK1rs0twCeKKA/+NpEJdWdgDu3MlQ0QQlK GFYAn1g03UNqeLcJrZ3FB01Tgn4EVd2j =8bPc -----END PGP SIGNATURE----- From gunner at poczta.onet.pl Sat Feb 13 03:51:33 2016 From: gunner at poczta.onet.pl (Michal Welnicki) Date: Sat, 13 Feb 2016 04:51:33 +0100 Subject: [winswitch] Broken libvpx-xpra dependencies on CentOS 6.7 Message-ID: <56BEA845.6070403@poczta.onet.pl> Hi, Yum update complains about libvpx-xpra dependencies on an i686 CentOS 6.7 for me. Seems that xpra was built with libvpx.so.2, but libvpx-xpra-1.5.0 provides libvpx.so.3. Xpra seems to work fine with libvpx 1.4, but the yum warnings are a bit annoying. Thanks, Michal # yum --disablerepo=* --enablerepo=winswitch update Loaded plugins: auto-update-debuginfo, changelog, fastestmirror, refresh-packagekit, security Setting up Update Process Loading mirror speeds from cached hostfile Resolving Dependencies --> Running transaction check ---> Package libvpx-xpra.i686 0:1.4.0-1.el6 will be updated --> Processing Dependency: libvpx.so.2 for package: xpra-0.16.2-1.el6_7.i686 ---> Package libvpx-xpra.i686 0:1.5.0-1.el6 will be an update --> Finished Dependency Resolution Error: Package: xpra-0.16.2-1.el6_7.i686 (@winswitch) Requires: libvpx.so.2 Removing: libvpx-xpra-1.4.0-1.el6.i686 (@winswitch) libvpx.so.2 Updated By: libvpx-xpra-1.5.0-1.el6.i686 (winswitch) Not found You could try using --skip-broken to work around the problem You could try running: rpm -Va --nofiles --nodigest From antoine at nagafix.co.uk Sat Feb 13 12:51:57 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Sat, 13 Feb 2016 19:51:57 +0700 Subject: [winswitch] Broken libvpx-xpra dependencies on CentOS 6.7 In-Reply-To: <56BEA845.6070403@poczta.onet.pl> References: <56BEA845.6070403@poczta.onet.pl> Message-ID: <56BF26ED.9010000@nagafix.co.uk> On 13/02/16 10:51, Michal Welnicki wrote: > Hi, > Yum update complains about libvpx-xpra dependencies on an i686 CentOS > 6.7 for me. I guess this answers the question of whether or not there are still users of 32-bit RPM builds... > Seems that xpra was built with libvpx.so.2, but libvpx-xpra-1.5.0 > provides libvpx.so.3. Exactly. I had forgotten to push libvpx-xpra on the i686 CentOS 6.6 and 6.7 repositories. Sorry about that. > Xpra seems to work fine with libvpx 1.4, but the yum warnings are a bit > annoying. This should be fixed now. Thanks for the report! Cheers Antoine From gunner at poczta.onet.pl Sun Feb 14 01:51:53 2016 From: gunner at poczta.onet.pl (Michal Welnicki) Date: Sun, 14 Feb 2016 02:51:53 +0100 Subject: [winswitch] Broken libvpx-xpra dependencies on CentOS 6.7 In-Reply-To: <56BF26ED.9010000@nagafix.co.uk> References: <56BF26ED.9010000@nagafix.co.uk> Message-ID: <56BFDDB9.5020004@poczta.onet.pl> > This should be fixed now. Thanks for the report! Unfortunately it still doesn't work: Error: Package: xpra-0.16.2-2.el6_7.i686 (winswitch) Requires: libvpx.so.2 Removing: libvpx-xpra-1.4.0-1.el6.i686 (@winswitch) libvpx.so.2 Updated By: libvpx-xpra-1.5.0-1.el6.i686 (winswitch) Not found "yum clean metadata" does not help. The new xpra version is still built for libvpx.so.2 (libvpx 1.4.0): $ rpm -qp --requires http://xpra.org/dists/CentOS/6.7/i386/xpra-0.16.2-2.el6_7.i686.rpm | grep vpx libvpx-xpra libvpx.so.2 And libvpx-xpra-1.5.0-1.el6.i686.rpm only provides libvpx.so.3: $ rpm -qp --provides http://xpra.org/dists/CentOS/6.7/i386/libvpx-xpra-1.5.0-1.el6.i686.rpm libvpx.so.3 libvpx-xpra = 1.5.0-1.el6 libvpx-xpra(x86-32) = 1.5.0-1.el6 Perhaps the 32-bit build host doesn't have libvpx-devel updated to 1.5.0? Regards, Michal From antoine at nagafix.co.uk Tue Feb 16 18:21:42 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 17 Feb 2016 01:21:42 +0700 Subject: [winswitch] Broken libvpx-xpra dependencies on CentOS 6.7 In-Reply-To: <56BFDDB9.5020004@poczta.onet.pl> References: <56BF26ED.9010000@nagafix.co.uk> <56BFDDB9.5020004@poczta.onet.pl> Message-ID: <56C368B6.1080308@nagafix.co.uk> First, sorry about the delay. On 14/02/16 08:51, Michal Welnicki wrote: >> This should be fixed now. Thanks for the report! > > Unfortunately it still doesn't work: Oops: I had fired the email without actually testing the installation in a VM. (just being lazy) > Error: Package: xpra-0.16.2-2.el6_7.i686 (winswitch) > Requires: libvpx.so.2 > Removing: libvpx-xpra-1.4.0-1.el6.i686 (@winswitch) > libvpx.so.2 > Updated By: libvpx-xpra-1.5.0-1.el6.i686 (winswitch) > Not found > > "yum clean metadata" does not help. > > The new xpra version is still built for libvpx.so.2 (libvpx 1.4.0): > > $ rpm -qp --requires > http://xpra.org/dists/CentOS/6.7/i386/xpra-0.16.2-2.el6_7.i686.rpm | > grep vpx > libvpx-xpra > libvpx.so.2 > > And libvpx-xpra-1.5.0-1.el6.i686.rpm only provides libvpx.so.3: > > $ rpm -qp --provides > http://xpra.org/dists/CentOS/6.7/i386/libvpx-xpra-1.5.0-1.el6.i686.rpm > libvpx.so.3 > libvpx-xpra = 1.5.0-1.el6 > libvpx-xpra(x86-32) = 1.5.0-1.el6 > > Perhaps the 32-bit build host doesn't have libvpx-devel updated to 1.5.0? It did have it, at least the RPM db thought it did - which confused me for a while, but it was actually linking against the system libvpx.so Not sure what happened there, but a clean rebuild seems to have resolved that, I think. The yum error message is a little bit confusing. This is not the first time I have wished that yum/dnf/rpm would be more clever about managing dependencies so one could more easily link against different versions all living in the same repository. Maybe I missing a trick there? Cheers Antoine > > Regards, > Michal > > _______________________________________________ > shifter-users mailing list > shifter-users at lists.devloop.org.uk > http://lists.devloop.org.uk/mailman/listinfo/shifter-users From michael at mayer.cx Tue Feb 16 19:16:41 2016 From: michael at mayer.cx (Michael Mayer) Date: Tue, 16 Feb 2016 20:16:41 +0100 Subject: [winswitch] xpra 0.16.1 - websockify processes prevent xpra to shut down successfully ? Message-ID: <56C37599.5070000@mayer.cx> Hi there, I am currently checking out xpra for a small project - in general I am very pleased with it. Very nice piece of technology. Lately I have encountered one issue though. If I use the following simple example that starts an xterm, makes it accessible via html and 2 minutes later stops it again using the following bash script (please don't laugh about the secure passwords and keys) ---- PASSWORD=YOURPASSWORD AES_KEY=0123456789ABCDEF PWD=`pwd` echo -n $PASSWORD > password.txt echo -n $AES_KEY > aes.txt echo xpra start :10 --bind-tcp=0.0.0.0:10000 --html=on --start=xterm \ --auth=file --password-file=`pwd`/password.txt \ --tcp-encryption=AES --tcp-encryption-keyfile=`pwd`/aes.txt echo "http://localhost:10000/index.html?username=$USER&password=$PASSWORD&encryption=AES&key=$AES_KEY" sleep 120 xpra stop :10 --auth=file --password-file=$PWD/password.txt ----- It works perfectly fine if there is no connections to the xpra created xterm via the browser. If one however wishes to access the xterm during the 2 minutes (as users would probably want to do), "xpra stop" fails to terminate. It tells you that everything was terminated successfully but the xpra and websockify processes keep running. If I repeat the same xpra stop command again it tells me that it cannot find any processes... My expectation would be that xpra stop would terminate the X server, all the websockify daemons and itself. The issue only appears if one actually accesses the URL and more than one websockify process is spawned. Wondering if I am doing something wrong or we do have a bug here. Any pointers would be appreciated. Many thanks, Michael. PS: System Details: CentOS 7.2, websockify upgraded using the latest tarball from pypi. python-websockify-0.7.0-1.el7.centos.noarch ffmpeg-xpra-2.8.5-1.el7_2.x86_64 xpra-common-0.16.1-1.el7_2.noarch libvpx-xpra-1.5.0-1.el7_2.x86_64 x264-xpra-20151202-1.el7_2.x86_64 xpra-0.16.1-1.el7_2.x86_64 libwebp-xpra-0.4.4-1.el7_2.x86_64 From antoine at nagafix.co.uk Wed Feb 17 09:18:58 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Wed, 17 Feb 2016 16:18:58 +0700 Subject: [winswitch] xpra 0.16.1 - websockify processes prevent xpra to shut down successfully ? In-Reply-To: <56C37599.5070000@mayer.cx> References: <56C37599.5070000@mayer.cx> Message-ID: <56C43B02.1000307@nagafix.co.uk> (snip) > My expectation would be that xpra stop would terminate the X server, all > the websockify daemons and itself. > > The issue only appears if one actually accesses the URL and more than > one websockify process is spawned. > > Wondering if I am doing something wrong or we do have a bug here. You have just reported a valid bug - thank you! http://xpra.org/trac/ticket/1122 It is already fixed and will be in the next stable update. Cheers Antoine > Any pointers would be appreciated. > > Many thanks, > > Michael. > > PS: System Details: > > CentOS 7.2, websockify upgraded using the latest tarball from pypi. > > python-websockify-0.7.0-1.el7.centos.noarch > ffmpeg-xpra-2.8.5-1.el7_2.x86_64 > xpra-common-0.16.1-1.el7_2.noarch > libvpx-xpra-1.5.0-1.el7_2.x86_64 > x264-xpra-20151202-1.el7_2.x86_64 > xpra-0.16.1-1.el7_2.x86_64 > libwebp-xpra-0.4.4-1.el7_2.x86_64 From toddt at mit.edu Thu Feb 25 04:18:26 2016 From: toddt at mit.edu (Todd Thompson) Date: Wed, 24 Feb 2016 23:18:26 -0500 Subject: [winswitch] cutting and pasting with Centos 6 and Mac OSX 10.11.3 Message-ID: Are there any particular tips or tricks for getting cutting and pasting to work with this combination? The closed bugs make it seem like this *should* work, and yet it doesn't. I'm new to xpra in general, so I could be missing something obvious, but I've spent a few hours poking around in forums and nothing seems terribly awry... Here's the procedure I've been using: On Centos box: xpra start :314 --start-child=xterm Using mac app, connect to remote host display :314 through SSH port 22. The xterm appears, but the standard cut/paste don't appear to transfer text in either direction. Thanks! Todd From antoine at nagafix.co.uk Thu Feb 25 07:08:02 2016 From: antoine at nagafix.co.uk (Antoine Martin) Date: Thu, 25 Feb 2016 14:08:02 +0700 Subject: [winswitch] cutting and pasting with Centos 6 and Mac OSX 10.11.3 In-Reply-To: References: Message-ID: <56CEA852.4090700@nagafix.co.uk> On 25/02/16 11:18, Todd Thompson wrote: > Are there any particular tips or tricks for getting cutting and > pasting to work with this combination? The closed bugs make it seem > like this *should* work, and yet it doesn't. I'm new to xpra in > general, so I could be missing something obvious, but I've spent a few > hours poking around in forums and nothing seems terribly awry... > > Here's the procedure I've been using: > > On Centos box: > xpra start :314 --start-child=xterm > > Using mac app, connect to remote host display :314 through SSH port > 22. The xterm appears, but the standard cut/paste don't appear to > transfer text in either direction. How do you copy stuff to and from this xterm? If you are using your mouse to drag and select text, this goes into the "primary" clipboard buffer not the "clipboard" buffer, which does not exist on OSX and is therefore not synchronized at all. I've just tested with "xclip -selection clipboard" and it does get synchronized fine here from / to OSX. On MS Windows, we have the same limitation (only a single "clipboard" to synchronize against), but we already have a tray menu for selecting which remote clipboard we synchronize with, see: http://xpra.org/trac/ticket/966#comment:6 The same code could very easily be used on OSX, it "just" needs a bit of coding for adding this menu to the mac menu bar. Cheers Antoine (PS: stay on the IRC channel long enough to get an answer next time)