Package Details: xpra-winswitch 2.0.2-1

Git Clone URL: (read-only)
Package Base: xpra-winswitch
Description: Modified version of xpra by Winswitch
Upstream URL:
Licenses: GPL2
Conflicts: parti-all
Provides: parti-all
Submitter: bug
Maintainer: bug
Last Packager: bug
Votes: 80
Popularity: 1.850611
First Submitted: 2011-05-26 08:08
Last Updated: 2017-04-18 07:57

Latest Comments

bug commented on 2017-03-29 08:19

Increased bandwidth consumption. I'll get it fixed.

grawity commented on 2017-03-20 06:47

The package() process starts with:

error running (['uglifyjs', '--version'],),{'stderr': -1, 'stdout': -1}: [Errno 2] No such file or directory
Warning: uglifyjs failed and return -1
Warning: yuicompressor module not found, cannot minify
'nvcc --version' failed with return code 127
stderr: None

Will this cause any problems?

bug commented on 2017-03-17 10:46

I prefer to avoid making dependencies for git packages.

As for trying to use xpra with libyuv-git. You should try to install libyuv-git (and recompile xpra). See if that works.

PythonNut commented on 2017-03-13 18:07

I think by default xpra will use the swscale Colorspace Converter, which ships with ffmpeg.


bug commented on 2017-03-13 06:25

Faster than what? I don't have libyuv installed to begin with. You can always check upstream.

PythonNut commented on 2017-03-13 05:17

Is it possible to use this with libyuv-git? Supposedly it's significantly faster.

bugman32 commented on 2017-03-05 22:05

Anyone else having problems with lzo or lz4 detection with the following errors:

Warning: zlib is the only compressor enabled
install and enable lzo or lz4 support for better performance

I have the following packages installed and have made sure lz4 is enabled in config:

xpra-winswitch 1.0.3-1
lz4 1:1.7.5-1
python-lz4 0.8.2-1
python2-lz4 0.7.0-2

== EDIT ==
I inspected the members of lz4, and it appears that the latest build of python2-lz4 does not create the VERSION member in the module:

Python 2.7.13 (default, Dec 21 2016, 07:16:46)
[GCC 6.2.1 20160830] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import lz4
>>> import inspect
>>> inspect.getmembers(lz4)
[('LZ4_compress', <built-in function LZ4_compress>), ('LZ4_uncompress', <built-in function LZ4_uncompress>), ('__doc__', None), ('__file__', '/usr/lib/python2.7/site-packages/'), ('__name__', 'lz4'), ('__package__', None), ('compress', <built-in function compress>), ('compressHC', <built-in function compressHC>), ('decompress', <built-in function decompress>), ('dumps', <built-in function dumps>), ('loads', <built-in function loads>), ('uncompress', <built-in function uncompress>)]

However, you can see that the VERSION member exits in the python-lz4 build for Python 3:

Python 3.6.0 (default, Jan 16 2017, 12:12:55)
[GCC 6.3.1 20170109] on linux
Type "help", "copyright", "credits" or "license" for more information.
>>> import lz4
>>> import inspect
>>> inspect.getmembers(lz4)
[('LZ4_compress', <built-in function LZ4_compress>), ('LZ4_compress_fast', <built-in function LZ4_compress_fast>), ('LZ4_uncompress', <built-in function LZ4_uncompress>), ('VERSION', '0.8.2'), ('__doc__', None), ('__file__', '/usr/lib/python3.6/site-packages/'), ('__loader__', <_frozen_importlib_external.ExtensionFileLoader object at 0x7f581720bf98>), ('__name__', 'lz4'), ('__package__', ''), ('__spec__', ModuleSpec(name='lz4', loader=<_frozen_importlib_external.ExtensionFileLoader object at 0x7f581720bf98>, origin='/usr/lib/python3.6/site-packages/')), ('__version__', '0.8.2'), ('compress', <built-in function compress>), ('compressHC', <built-in function compressHC>), ('compress_fast', <built-in function compress_fast>), ('decompress', <built-in function decompress>), ('dumps', <built-in function dumps>), ('loads', <built-in function loads>), ('lz4version', <built-in function lz4version>), ('uncompress', <built-in function uncompress>)]

bug commented on 2017-02-23 08:41

python2-dbus is optional.
Same goes for python2-pyinotify (which I don't have installed).

If the issue persists, please fill a bug report upstream (preferably with a stacktrace).

stefops commented on 2017-02-20 12:35

I had to add python2-dbus and python2-pyinotify
Now mine is working.

ochi commented on 2017-02-19 10:46

Did xpra stop working (e.g. when attaching) after the latest system updates for anyone else as well? Happens to me on two different machines (haven't updated more machines since). Even executing only "xpra attach" leads to a segfault in python2.7. Enabling xpra debugging messages using "-d all" doesn't yield much (get_enabled_encoders(['bencode', 'rencode', 'yaml']) enabled=['rencode', 'bencode' repeated four times). Rebuilding xpra didn't help. Don't really know how to further debug this yet.

EDIT: Nevermind, another system update helped – pangox-compat 0.0.2+2+gedb9e09-1 seems to be the culprit. Package version -2 solved the problem.

farseerfc commented on 2017-01-13 04:16

the install file is no longer needed as they are automated by the hooks

bug commented on 2017-01-08 09:18

quite: Pushed too early by mistake. I'm still tinkering with it. The --without-enc_x265 is needed according to upstream.

Edit: Uploaded a working version :)

anntzer: Please test it and report back. Thanks!

quite commented on 2017-01-08 09:06

Aha, the --without... is needed for the install as well... Didn't you verify this change? ;)

quite commented on 2017-01-08 09:04

The latest addition "--without-enc_x265" breaks the package in a somewhat odd way. The x265-encoder is indeed not built in the build() step, but instead it is built *and* installed in the package() step (!). Except that it cannot be built, because the "-fno-strict-aliasing" is missing, so compilation breaks.

anntzer commented on 2017-01-07 22:11

bug: Are you sure this is still the case? After a quick grepping through the source it seems that xpra now uses `sys.executable` correctly (e.g. xpra/scripts/

Probably best would be to check the svn history for that change but my svn-fu is non-existent and git-svn is slow...

bug commented on 2017-01-07 19:24

anntzer: Sadly, probably yes. See comment by shedto.
The issue is that xpra sometimes creates a sub-process using python instead of python2 (even though it's installed and configured to use python2).
I'd like to change the installation to use only python3 as most of xpra supports python3 at this point, but some parts still don't.

You are more than welcome to fix xpra upstream and let us know :)

anntzer commented on 2017-01-07 06:46

Are the python3 dependencies (python-lz4, python-opengl, python-crypto, python-cryptography) really correct?

bug commented on 2017-01-04 12:56

AUR Helpers ( are not officially supported.
Redirect your issues with yaourt to yaourt.

krupan commented on 2016-12-31 17:35

Installed this today and I had to manually do:

sudo pacman -S python2-opengl

before yaourt -S xpra-winswitch would work. Not sure why (sorry, I'm pretty new to arch).

BrunoSpy commented on 2016-12-29 09:13

I can confirm that you can add armv7h in the list !

cmsigler commented on 2016-12-23 18:48


I've finally figured out the reason (which should have been obvious) why I couldn't get xpra as installed working on the Raspberry Pi Zero. The virtual desktop size specified in /etc/xpra/xorg.conf seems to be too large. By reducing it to a more manageable setting -- I've used 1600x900, 1920x1080 and as large as 2400x1350 -- everything works as expected.

So for me xpra installs and works correctly on Odroid C2, Raspberry Pi 3 and Raspberry Pi Zero using Arch Linux ARM. HTH.


bug commented on 2016-12-17 18:19

@anntzer: (and anyone else)
I've added pacsave for /etc/xpra/conf.d/55_server_x11.conf,
and it seems you end up keeping the bad file from 1.0-1.
Please run this the following line to use the new config file:
mv /etc/xpra/conf.d/55_server_x11.conf.pacnew /etc/xpra/conf.d/55_server_x11.conf

Proper fix got merged into upstream, so next version won't need sed :)

cmsigler commented on 2016-12-16 19:56


Really glad I can help. It's my tiny way of contributing to the cause. And I don't know why xpra (and winswitch?) aren't in community. xpra is just an undiscovered gem for remote graphical access. Do other sysadmins really use VNC (probably tigervnc) over WAN/public network??? No bueno.

Thank you for being maintainer and keeping things working :)


anntzer commented on 2016-12-16 06:20

FWIW I am still getting the same error as reported by PythonNut (after installing xpra-winswitch 1.0-2 on both client and server side).

bug commented on 2016-12-15 19:38

I'd like to apologise. I forget to test xpra locally (I only remember test it remotely).

Nice going beating me to it. I didn't get around to poke it 'till today and you saved me quite a bit of time. Thanks.

I did get my system to stop responding after trying to run xpra from VT. I don't have enough space to create a VM and debug it at the moment.

You can reset your /etc/X11/Xwrapper.config to it's original shape. allowed_users fix is no longer needed.
Please do try to revert to currently shipped config and see what happens.

Is there a reason for changing the socket-dir?

cmsigler commented on 2016-12-13 20:29


UPDATED: Removed nonsense from my earlier post here. CMS

My thanks @stefops and @PythonNut for tips to get xpra working.

For some strange reason when I do, e.g., "xpra stop :31" my running :0.0 console X display is killed. This is obviously when I'm running the xpra server locally. Under /tmp the .X0-lock file and .X11-unix/X0 socket are still there but my graphical desktop, well, flash and it's gone. Since no one else is having this problem it must be a local config, desktop package or hardware/driver problem *shrug*

I've patched the current PKGBUILD to avoid three problems:

- References to $pkgdir in package -- makepkg complains saying:
==> WARNING: Package contains reference to $pkgdir

- "-config" switch in /etc/xpra/conf.d/55_server_x11.conf refers to /tmp/yaourt-tmp-siglercm/aur-xpra-winswitch/pkg/xpra-winswitch/etc/xpra/xorg.conf should be just /etc/xpra/xorg.conf

- I don't have xpra_Xdummy installed by default any more. So I comment out the sed edit command that was used previously.

Patch here:
--- PKGBUILD.orig 2016-12-09 02:28:17.000000000 -0500
+++ PKGBUILD 2016-12-15 07:40:41.143766964 -0500
@@ -20,7 +20,22 @@
makedepends=('python2-setuptools' 'cython2')
-backup=('etc/xpra/xpra.conf' 'etc/xpra/xorg.conf')
+backup=('etc/xpra/xpra.conf' 'etc/xpra/xorg.conf'
+ 'etc/xpra/cuda.conf' 'etc/xpra/nvenc.keys'
+ 'etc/xpra/conf.d/05_features.conf'
+ 'etc/xpra/conf.d/10_network.conf'
+ 'etc/xpra/conf.d/12_ssl.conf'
+ 'etc/xpra/conf.d/15_file_transfers.conf'
+ 'etc/xpra/conf.d/16_printing.conf'
+ 'etc/xpra/conf.d/20_sound.conf'
+ 'etc/xpra/conf.d/30_picture.conf'
+ 'etc/xpra/conf.d/35_webcam.conf'
+ 'etc/xpra/conf.d/40_client.conf'
+ 'etc/xpra/conf.d/42_client_keyboard.conf'
+ 'etc/xpra/conf.d/50_server_network.conf'
+ 'etc/xpra/conf.d/55_server_x11.conf'
+ 'etc/xpra/conf.d/60_server.conf'
+ 'etc/xpra/conf.d/65_proxy.conf')
@@ -36,7 +51,8 @@
package() {
cd ${srcdir}/xpra-$pkgver
python2 install --root=${pkgdir} || return 1
- sed -i -e '/^xvfb\s*=\s*Xorg/s/Xorg/xpra_Xdummy/' ${pkgdir}/etc/xpra/xpra.conf
+ #sed -i -e '/^xvfb\s*=\s*Xorg/s/Xorg/xpra_Xdummy/' ${pkgdir}/etc/xpra/conf.d/55_server_x11.conf
+ sed -i -e "s|${pkgdir}||g" ${pkgdir}/etc/xpra/conf.d/55_server_x11.conf
mkdir -p ${pkgdir}/usr/lib/sysusers.d
echo g xpra - - > ${pkgdir}/usr/lib/sysusers.d/xpra.conf



PythonNut commented on 2016-12-13 20:26

@stefops, thanks!

For future wanderers, I also needed to comment out all of the socket-dirs lines in /etc/xpra/conf.d/10_network.conf except for:

socket-dirs = ~/.xpra

stefops commented on 2016-12-12 15:32

and don't forget in /etc/X11/Xwrapper.config

stefops commented on 2016-12-12 15:29

in /etc/xpra/conf.d/55_server_x11.conf try
xvfb = /usr/lib/xorg-server/Xorg -dpi 96 -noreset -nolisten tcp \
+extension GLX +extension RANDR +extension RENDER \
-logfile ${HOME}/.xpra/Xorg.${DISPLAY}.log \
-configdir ${HOME}/.xpra/xorg.conf.d \
-config /etc/xpra/xorg.conf
this works for me

regagain commented on 2016-12-11 13:53

Just wanted to say that I run into the same issue as PythonNut.

PythonNut commented on 2016-12-10 03:26

As of the update to v1.0, I'm now getting this error on running `xpra attach :22`:

/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server
2016-12-10 03:25:37,997
2016-12-10 03:25:37,997 Xvfb command has terminated! xpra cannot continue
2016-12-10 03:25:37,997 if the display is already running, try a different one,
2016-12-10 03:25:37,997 or use the --use-display flag
2016-12-10 03:25:37,997
2016-12-10 03:25:37,998 killing xvfb with pid 2213
2016-12-10 03:25:37,998 failed to kill xvfb process with pid 2213:
2016-12-10 03:25:37,999 [Errno 3] No such process

Anyone know what's causing this? I've tried most of the solutions from Google, and none of them seem to help for some reason.

bug commented on 2016-12-09 07:33

Updated to v1.0.

I've removed the systemd unit I've been packaging. It shouldn't be used and is a source of problems (while also conflicts with a systemd unit provided by upstream).

The Arch Wiki is out of date, if anyone cares to update it, please do.
The correct usage can be found here:

shedto commented on 2016-10-30 23:06

xpra does not work correctly with amdgpu driver and the new Polaris AMD GPUs

It takes verly long until a client connects and there are several errors:

cannot build the OpenCL program: clBuildProgram failed: BUILD_PROGRAM_FAILURE -

Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM 3.9.0)' on 'Clover' at 0x55f4fb28ea08>:

error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'

(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/", line 441, in bui
File "/usr/lib/python2.7/site-packages/pyopencl/", line 438, in build
options_bytes=options_bytes, source=self._source)
File "/usr/lib/python2.7/site-packages/pyopencl/", line 473, in _build_and_catch_errors
raise err
RuntimeError: clBuildProgram failed: BUILD_PROGRAM_FAILURE -

Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM 3.9.0)' on 'Clover' at 0x55f4fb28

error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'

(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/
all warnings:
Warning: csc_opencl failed its self test
cannot build the OpenCL program: clBuildProgram failed: BUILD_PROGRAM_FAILURE -

Build on <pyopencl.Device 'AMD POLARIS10 (DRM 3.3.0 / 4.8.4-1-ARCH, LLVM 3.9.0)' on 'Clover' at 0x55f4fb28

error: unknown target CPU 'polaris10'
error: unknown target CPU 'polaris10'

(options: -I /usr/lib/python2.7/site-packages/pyopencl/cl)
(source saved as /tmp/

BrunoSpy commented on 2016-10-20 11:01

You can add armv7h : it's working :)

stefops commented on 2016-10-17 07:58

for the aarch64 users you have to edit python2-gtkglext PKGBUILD and change
PYTHON='/usr/bin/python2' ./configure --prefix=/usr
PYTHON='/usr/bin/python2' ./configure --build=aarch64-unknown-linux-gnu --prefix=/usr

shedto commented on 2016-10-10 22:40

Connecting a client takes more then 15 seconds

Also the dependencies are incomplete.
xpra warns about lz4 missing even though lz4 and python2-lz4 are installed.
This was solved by installing python-lz4 (python3 bindings)

missing dependencies:


bug commented on 2016-09-05 08:14

Sadly I found your edit too late. Either way, as it works on x64, armv7h & aarch64. I can only conclude it's an armv6h issue.

I've asked upstream about it, and it seems to be an Archlinux-arm issue. As I know nothing of it, the only question I can think of is does Archlinux-arm do different things for different architectures?

cmsigler commented on 2016-09-01 14:34

Sorry to say, but my report of xpra-winswitch working on armv6h using xpra_Xdummy in xpra.conf seems to have been premature.

It worked when I tried it, I swear. But it only seems to have worked the first time :/ At first I thought it might be a race condition but the problem is never intermittent.

Since it worked the first time I didn't bother shutting it down and trying to start it up multiple times. Now it never works. I checked for updated packages that might interfere and I just can't see any problems. I reinstalled the xpra-winswitch pkg I built with makepkg for armv6h, as well as every package in the xorg group, but no soap. I checked for possibly missing packages -- of course there were none I could identify.

This is without doubt a permissions problem. I went `su -' and (besides complaining I was running as root) xpra started up, no complaints.

Mind you, I'm building and testing on a Raspberry Pi Zero. It's not speedy but it does seem to run OK.

My fallback, which works fine, is to edit /etc/xpra/xpra.conf and at the bottom use the xvfb command that starts "xfvb = Xvfb +extension Composite...". That makes it work every time. I'm not sure why armv6h would have a permissions problem but when running via xpra_Xdummy on armv7h (and aarch64) all is well *shrug*



P.S.: I forgot to explain the problem/error message.... xpra can't compile the keymap, error message is "Could not invoke xkbcomp", even though xkbcomp is in the standard /usr/bin directory and is (apparently) in PATH, and I can run `xkbcomp --help' as an unprivileged user. Error messages:
[ 2316.508] (EE) XKB: Could not invoke xkbcomp
[ 2316.508] (EE) XKB: Couldn't compile keymap
[ 2316.508] (EE) XKB: Failed to load keymap. Loading default keymap instead.
[ 2316.531] (EE) XKB: Could not invoke xkbcomp
[ 2316.531] (EE) XKB: Couldn't compile keymap
[ 2316.531] XKB: Failed to compile keymap
[ 2316.532] Keyboard initialization failed. This could be a missing or incorrect setup of xkeyboard-config.
[ 2316.532] (EE)
Fatal server error:
[ 2316.532] (EE) Failed to activate core devices.(EE)

bug commented on 2016-08-27 20:59

@antony: I should change my work flow. I did remember to update SRCINFO when updating the package, but forgot to do it again after fixing the missing dependency.

@cmsigler: Great :)

cmsigler commented on 2016-08-27 14:49

Kudos to bug for maintaining this great AUR package! Latest version 0.17.5-1 with update to installed xpra.conf WFM as-installed on armv6h, armv7h and aarch64 :) I'm able to forward xfce4 desktops with no problem.


anntzer commented on 2016-08-26 15:33

you need to update .SRCINFO too

bug commented on 2016-08-26 10:13

Changed package to use xpra_Xdummy.
Please revert all fixes done to bypass "/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server" and see if it works for you.

stefops commented on 2016-08-22 11:50

from xpra wiki
"If you distribution ships the newer version but only installs a suid Xorg binary, Xpra should have installed the xpra_Xdummy wrapper script and configured xpra.conf to use it instead of the regular Xorg binary."
Maybe you could modify default xpra.conf
xvfb = xpra_Xdummy -noreset -nolisten tcp +extension GLX ........

julianbrost commented on 2016-08-19 22:50

An alternative solution for the "/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server" problem is to just bypass Xorg.wrap and use /usr/lib/xorg-server/Xorg instead of /usr/bin/Xorg. This can be done by adding /usr/lib/xorg-server to $PATH in ~/.xpra/run-xpra

bug commented on 2016-07-07 08:55

I know, but it'd be easier for me to remember to delete it on the next version.

stefops commented on 2016-07-07 08:28

bug, I just changed line to
CFLAGS="$CFLAGS -fno-strict-aliasing -Wno-error=deprecated-declarations" python2 build || return 1
no need to add a line
thanks again for your work.

bug commented on 2016-07-07 08:03


That echo command shouldn't have been there in the first place. It was a leftover from when I was trying to disable the strict-aliasing (as it breaks the build).

Add the flag without changing revision number (as there's no need to cause recompilation for everyone else).

cmsigler commented on 2016-07-06 21:09


I'm using xpra-winswitch on Arch Linux ARM, on both Raspberry Pi 3 and Odroid-C2, which are armv7h and aarch64 architectures, respectively. On both systems xpra-winswitch 0.17.4-1 won't build. I _believe_ this is due to a very recent upgrade to ffmpeg 1:3.1-1 from 1:3.0.2-2. This upgrade hasn't come through on i686 or x86_64 arches yet.

There's only one isolated problem and it's an upstream one but it's easily compensated for. When xpra/codecs/dec_avcodec2/decoder.c is compiled the function call avcodec_decode_video2 is deprecated. Since by default gcc is configured to use -Werror this warning causes the build to exit with "cc1: all warnings being treated as errors".

My simple, obvious fix to PKGBUILD is to add a line to build() right _before_ the `echo $CFLAGS' command:

CFLAGS="$CFLAGS -Wno-error=deprecated-declarations" && export CFLAGS

IGWS this keeps gcc from error exiting because of deprecated avcodec_decode_video2. Better yet, this is the one and only problem with this build so a straightforward upstream patch should fix it at the source.

HTH :)


cmsigler commented on 2016-05-19 23:42


@stefops -- Me, too :)

xpra-winswitch works fine under aarch64, even to remote my complete xfce4 desktop. x2go component program nxagent core dumps for me on Odroid-C2/aarch64, haven't had time to search for any clues to this, but xpra-winswitch works fine! Thanks for maintaining a useful package.


stefops commented on 2016-05-15 19:09

got a odroid-c2, added aarch64, works ok.
Thanks for your work again.

bug commented on 2016-03-17 12:10

Warning: History

Because the original xpra was part of a WM called parti. Then that project died. Where upon the developer of Winswitch forked it. Over time, the original parti project vanished and all that is left is the Winswitch fork.

BoySka commented on 2016-03-16 04:04

Why is this called "modified by Winswitch" if the regular version from is used, with no patches?

bug commented on 2016-03-13 05:08
You want to edit /etc/X11/Xwrapper.config as shown there.

If you know of any other way, be sure to share.

alexchandel commented on 2016-03-08 20:24

When attempting to use the Xdummy server, I get the following message:

/usr/lib/xorg-server/Xorg.wrap: Only console users are allowed to run the X server

How is it supposed to be run from SSH then?

alexchandel commented on 2016-03-08 19:55

This package fails to declare its dependency on python2-dbus, python2-numpy, python2-pycups, and python2-netifaces.

cmsigler commented on 2016-02-16 15:38


I found a strange "upgrade loop" coming from 0.16.2. Looking at the last git commit, I *think* the .SRCINFO file missed a needed change when patched. For .SRCINFO:
--- a/.SRCINFO
+++ b/.SRCINFO
@@ -1,8 +1,8 @@
# Generated by mksrcinfo v8
-# Sun Jan 24 12:12:56 UTC 2016
+# Mon Feb 15 07:45:36 UTC 2016
pkgbase = xpra-winswitch
pkgdesc = Modified version of xpra by Winswitch
- pkgver = 0.16.1
+ pkgver = 0.16.2
pkgrel = 2
url =
install = xpra-winswitch.install

@@ -1,8 +1,8 @@
# Contributor: Bug <>
# Maintainer: Bug <>
pkgdesc="Modified version of xpra by Winswitch"
arch=('i686' 'x86_64')

In .SRCINFO only, "pkgrel = 2" didn't get patched up to "pkgrel = 1". This gives wrong pkgrel data to AUR. An upgrade installs 0.16.2-1, but the next time you upgrade out-of-date AUR packages it thinks there's a new version and tries to install an upgrade, only to reinstall 0.16.2-1.



cmsigler commented on 2016-01-12 14:01


I ran into a problem with systemd-tmpfiles-setup and systemd-tmpfiles-clean which seems to come from the xpra-winswitch AUR pkg:

Starting with v0.16.x xpra has added a new tmpfiles.d file, /usr/lib/tmpfiles.d/xpra.conf. This file requires a new /run (/var/run) directory, /var/run/xpra, owned by root:xpra, which also requires a new group, xpra.

HTH. Thank you for your work on this pkg :)


allspark commented on 2015-11-17 18:34


i just tried to compile this packages in a clean chroot ( and the package libxkbfile is missing, don't know if it's a build or runtime dependency

kozaki commented on 2015-09-13 11:08

Reventlov hack workin here, thanks! python2-lz4 not detected also on Debian. Looks like developer puts the blame on Debian:
#960 (0.15.4: don't detect LZ4 any more) – Xpra . Patch in r10440 does not change the game at least for me. Couldn't fill a bug report because of permission's issue atm.
Thanks you bug for your work on this!

Reventlov commented on 2015-08-09 21:34

The lz4 is currently broken: xpra tries to check that python2-lz4 is at least version 0.7.0, but doesn't success. The default version is used, which is None, making it smaller than "0.7.0". I hardcoded the version in the file where the check happens ( /usr/lib/python2.7/site-packages/xpra/net/ ), maybe you should bug report if you want or try to hack this check in the PKGBUILD.

ishitatsuyuki commented on 2015-08-05 02:09

Aug 03: Xpra 0.15.4

aurifier commented on 2015-07-19 22:34

I find that I also need packages xorg-server-xvfb and libunwind.

luxor commented on 2015-06-24 18:48

Attaching to a remote server using "xpra attach ssh:remotehost:port number seems to be broken in version 0.15. I had to revert to 0.14 to get this to work.

farseerfc commented on 2015-06-07 16:44

should add depend for "libxkbfile" ?
otherwise the build will fail

stefops commented on 2015-06-01 13:17

Maybe you could add python2-lz4 en rencode as depend for 0.15
and libvpx and x265 as optional

stefops commented on 2015-05-19 07:03

just for info:
Had to reinstall pyopengl-accelerate to get rid of
OpenGL accelerate missing: numpy_formathandler

Thanks again for your work bug

BrunoSpy commented on 2015-03-20 11:43

You can add armv7h : tested and approved !

DerRoteBaron commented on 2015-03-03 17:52

Is there any reason why the source tarball is not downloaded via HTTPS?

bug commented on 2015-01-23 14:17

Sorry about that, uploaded the wrong file.

stefops commented on 2015-01-23 13:42

Should this be 0.14.18-1 ?

18 compile ok

Lazy commented on 2014-09-30 14:16

Svn compiles ok.

Lazy commented on 2014-09-30 14:11

Still stuck in the same place.

bug commented on 2014-09-29 17:19

@Lazy: Yeah. Try it with pyopengl-accelerate 3.1.0. If it still doesn't compile, report to upstream.

Lazy commented on 2014-09-29 13:34

xpra/codecs/vpx/decoder.c:755:12: warning: '__pyx_bisect_code_objects' declared 'static' but never defined [-Wunused-function]
static int __pyx_bisect_code_objects(__Pyx_CodeObjectCacheEntry* entries, int count, int code_line);
xpra/codecs/vpx/decoder.c:756:22: warning: '__pyx_find_code_object' declared 'static' but never defined [-Wunused-function]
static PyCodeObject *__pyx_find_code_object(int code_line);
xpra/codecs/vpx/decoder.c:757:13: warning: '__pyx_insert_code_object' declared 'static' but never defined [-Wunused-function]
static void __pyx_insert_code_object(int code_line, PyCodeObject* code_object);
xpra/codecs/vpx/decoder.c:782:27: warning: '__Pyx_PyInt_As_long' declared 'static' but never defined [-Wunused-function]
static CYTHON_INLINE long __Pyx_PyInt_As_long(PyObject *);
error: command 'gcc' failed with exit status 1
==> ERROR: A failure occurred in build().

Does this have to do with pyopengl-accelerate?

stefops commented on 2014-08-10 15:55

To all,
Be sure to build pyopengl-accelerate-3.1.0 else segfault. Just change version and md5. Build fine.
Package Details: pyopengl-accelerate 3.0.2-1 still not uptodate.

johnLate commented on 2014-06-28 21:50

Can't connect to 0.13.3 servers with this version.

Related bug:

Basically the problem is in /usr/lib/python2.7/dist-packages/xpra/scripts/
cmd += ["sh -c 'xpra initenv 2>&1 >> /dev/null;"+(" ".join(proxy_cmd))+"'"]
which should be:
cmd += ["sh -c 'xpra initenv >> /dev/null 2>&1;"+(" ".join(proxy_cmd))+"'"]

bug commented on 2014-06-18 08:12

0.13.5 didn't work for me at first as well. Then some random magic happened and it worked, so I had it uploaded.
0.13.6 worked like a charm the first time.

stefops commented on 2014-06-18 06:51

Thanks bug, this one is working. 0.13.5 was no working for me.

chx commented on 2014-06-16 00:43

I am getting

xf86-video-dummy and xorg-server are in conflict. Remove xorg-server? [y/N]

I do not think I want to remove xorg-server :)

stefops commented on 2014-06-02 09:46

xpra (0.13.2-1) UNRELEASED; urgency=low
* fix painting of forwarded tray
* fix initial window workspace
* fix launcher with debug option in config file
* fix compilation of x265 encoder
* fix infinite recursion in cython csc module
* don't include sound utilities when building without sound

Comment from Antoine concerning x265

Yes, you're right I think.

It should be fixed in r6606. Let me know and I'll backport the fix.

Note: no-one should be using {{{enc_x265}}} at this point because it is
ridiculously slow, which is why it doesn't really get tested very often,
and not even compile-tested since it isn't packaged for any of the major
distros AFAIK.

bug commented on 2014-05-30 08:15

Let's just say I had an outdated system and a mess with my packages. I can't either.
Disabled x265. The issue has been resolved in upstream and disabling won't be required in the next version.

stefops commented on 2014-05-30 07:23

Can't compile without it. Strange you can.

stefops commented on 2014-05-27 09:54

v0.13.0 (2014-05-22)
-- Python3 / GTK3 client support
-- NVENC module included in binary builds
-- support for enhanced dummy driver with DPI option
-- better build system with features auto-detection
-- removed unsupported CUDA csc module
-- improved buffer support
-- faster webp encoder
-- improved automatic encoding selection
-- support running MS Windows installer under wine
-- support for window opacity forwarding
-- fix password mode in launcher
-- edge resistance for automatic image downscaling
-- increased default memory allocation of the dummy driver
-- more detailed version information and tools
-- stricter handling of server supplied values

stefops commented on 2014-05-17 06:23

v0.12.6 (2014-05-16)
-- fix invalid pixel buffer size causing encoding failures
-- fix auto-refresh infinite loop, and honour refresh quality
-- fix sound sink with older versions of GStreamer plugins
-- fix Qt applications crashes caused by a newline in xsettings..
-- fix error with graphics drivers only supporting OpenGL 2.x only
-- fix OpenGL crash on OSX with the Intel driver (now blacklisted)
-- fix global menu entry text on OSX
-- fix error in cairo backing cleanup
-- fix RGB pixel data buffer size (re-stride as needed)
-- avoid buggy swscale 2.1.0 on Ubuntu

stefops commented on 2014-04-28 11:12

For the source. About 10% less. Just change tar.bz2 to tar.xz in pkg and use the proper md5.
And again, thanks for your time.

bug commented on 2014-04-28 09:34

1) I made a package for 0.12.4 but forgot to upload it. Go figure.
2) xz extension for where? For the source? I'm using default makepkg -S. Is there any flag that is required for this?

stefops commented on 2014-04-28 09:13

compile fine.
Why not use xz extention to save a bit ?

v0.12.4 (2014-04-23)
-- fix xpra shadow subcommand
-- fix xpra shadow keyboard mapping support for non-posix clients
-- avoid Xorg dummy warning in log

stefops commented on 2014-04-21 10:30

C) No it is not :-P

Compile fine. Would be nice to see changelog when updating. Thanks for your free time you give us.

v0.12.3 (2014-04-09)
-- fix mispostioned windows
-- fix quickly disappearing windows (often menus)
-- fix server errors when closing windows
-- fix NVENC server initialization crash with driver version mismatch
-- fix rare invalid memory read with XShm
-- fix webp decoder leak
-- fix memory leak on client disconnection
-- fix focus errors if windows disappear
-- fix mmap errors on window close
-- fix incorrect x264 encoder speed reported via "xpra info"
-- fix potential use of mmap as an invalid fallback for video encoding
-- fix logging errors in debug mode
-- fix timer expired warning

bug commented on 2014-04-08 10:10

A) I won't. We already had a discussion about arm. It is not officially supported by Archlinux, and thus it won't be added.
B) Updated.
C) The latest version is 0.12.2.

Atterratio commented on 2014-04-07 23:36

Add please:
arch=('i686' 'x86_64', 'armv7h')

Need replace python2-distribute to python2-setuptools.

And latest vversion 0.12.6

bug commented on 2014-03-12 09:00

You are correct. It seems the install section was missing. Not sure how / when it vanished.
Try now. I hope I got it right.

jeffutter commented on 2014-03-12 06:42

I am a little confused by the systemd script. When I run:

$ systemctl --user enable xpra@100

I Get:
The unit files have no [Install] section. They are not meant to be enabled
using systemctl.
Possible reasons for having this kind of units are:
1) A unit may be statically enabled by being symlinked from another unit's
.wants/ or .requires/ directory.
2) A unit's purpose may be to act as a helper for some other unit which has
a requirement dependency on it.
3) A unit may be started when needed via activation (socket, path, timer,
D-Bus, udev, scripted systemctl call, ...).

Am i missing something?

bug commented on 2014-02-09 09:53

It's not really used and works without it just fine.

bug commented on 2014-02-09 09:41

A) The config does not use the void input driver from what I can see.
B) I don't have xf86-input-void and xpra works just fine.

Are you sure you didn't change your xpra configuration?

Szunti commented on 2014-02-07 12:38

/etc/xpra/xorg.conf uses the void input driver;
I think xf86-input-void should be added as dependency

bug commented on 2014-01-27 11:06

@menta: As the user you want to run the server (no sudo).
As for the wiki, feel free to do so. I'm not sure when will I be able to find the time to do so myself (I'm pretty sure I wrote nothing on that wiki page to start with).

menta commented on 2014-01-27 10:48

Thank you for the update! Should I rub 'systemd --user enable xpra@port' as my user or with sudo?

Could you please update the wiki (

Thanks in advance!

bug commented on 2014-01-26 14:27

systemd script has been changed.
systemd --user enable xpra@port
from your user to have it run xpra on said port.
Thank XZS. I find this systemd script makes more sense.

stefops commented on 2014-01-24 16:24

from xpra:

01/24/14 16:13:09 (less than one hour ago)
#503: remove redundant test which causes Cython 0.20 to barf

stefops commented on 2014-01-24 15:47

I did downgrade cython to 0.19 and it whent fine. Hope it helps

dront78 commented on 2014-01-24 04:43

0.11 no compile. anybody knows how to fix?

Error compiling Cython file:
self.pixel_format = ARGB
self.pixel_format = BGRA
raise Exception("invalid image depth: %s bpp" % self.depth)
assert self.pixel_format in RGB_FORMATS

Jarshvor commented on 2013-09-14 16:13

for those whishing to install on ARM, just ignore the architecture flag.
(yaourt -AS if using yaourt)

builds fine

hobarrera commented on 2013-05-11 03:38

Could you include the systemd.service file described here?

Jarshvor commented on 2013-03-30 23:46

any chance on getting this working on a "armv6h"?
trying to build on my raspi

Anonymous comment on 2013-03-12 13:47

Sorry, silly me. One just has to take EPD out of PATH before installing.

Anonymous comment on 2013-03-12 11:24

Hi, what is the rationale to place this in /opt/epd instead of /opt/xpra?
The issue is that /opt/epd is a natural place to install the Enthought Python Distribution.

xmw commented on 2013-01-10 23:53

python-imaging is now called python2-imaging

bug commented on 2013-01-09 16:49

I don't have x11-ssh-askpass installed and xpra works just fine for me.
How exectly are you trying to run xpra?

Jarshvor commented on 2013-01-08 16:08

installing "x11-ssh-askpass" however fixed my issue.

I wonder if its possible to get xpra working without this GUI passphrase promt.

would it not be required with ky authenthication?

Jarshvor commented on 2013-01-08 16:06

Jarshvor commented on 2013-01-08 16:00

ssh_askpass: exec(/usr/lib/ssh/ssh-askpass): No such file or directory

Why is it asking for ssh_askpass??

its not listed as a dependency

bug commented on 2012-11-08 20:44

A) Are you sure it lacks subversion? Doesn't make much sense considering it's not pulling anything from svn [at least shouldn't].
B) Where exactly do you get this error? "could not parse version information from string: (original version string: Unversioned directory)"

guardian commented on 2012-11-07 13:29

lacks a dependency on subversion

then fails "could not parse version information from string: (original version string: Unversioned directory)"

sundrythoughts commented on 2012-10-19 12:46

Installed on 64-bit Arch and ran into the following error:

Traceback (most recent call last):
File "/usr/bin/xpra", line 4, in <module>
import xpra.scripts.main
File "/usr/lib/python2.7/site-packages/xpra/scripts/", line 76, in <module>
from xpra import webm #@UnusedImport
File "/usr/lib/python2.7/site-packages/xpra/webm/", line 54, in <module>
_LIBRARY = loader.LoadLibrary(_LIBRARY)
File "/usr/lib/python2.7/ctypes/", line 443, in LoadLibrary
return self._dlltype(name)
File "/usr/lib/python2.7/ctypes/", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: cannot open shared object file: No such file or directory

The file (/usr/lib/python2.7/site-packages/xpra/webm/ does the following:

# Per-OS setup
if sys.platform == "win32":
_LIBRARY = "libwebp_a.dll"

elif sys.platform == "linux2":

elif sys.platform == "darwin":
_LIBRARY = "libwebp.dylib"

raise NotImplementedError(
"Test non implemented under {0}".format(sys.platform))

But libwebp on Arch installs libwebp as:

So no exists. When I changed the python script to use it all worked fine.

Anonymous comment on 2012-10-10 21:53

xf86-video-dummy should be added as a dependency:

[3935593.579] (II) LoadModule: "dummy"
[3935593.579] (WW) Warning, couldn't open module dummy
[3935593.579] (II) UnloadModule: "dummy"
[3935593.579] (II) Unloading dummy
[3935593.579] (EE) Failed to load module "dummy" (module does not exist, 0)
[3935593.579] (II) LoadModule: "void"
[3935593.579] (WW) Warning, couldn't open module void
[3935593.579] (II) UnloadModule: "void"
[3935593.579] (II) Unloading void
[3935593.579] (EE) Failed to load module "void" (module does not exist, 0)
[3935593.579] (EE) No drivers available.
Fatal server error:
[3935593.579] no screens found

Anonymous comment on 2012-06-25 06:14

@bug Thank you for your answer, I did not know.

bug commented on 2012-06-24 12:46

Japx, while it might be supported, there is no official decision regarding adding ppc / arm to the PKGBUILD.
Therefore, I shall not add it at this time, even though it compiles just fine (I can't really test it on ARM).

For more information, see the mailing list:

My apologies for having to modify `arch` each time, but I hope you can understand.

Anonymous comment on 2012-06-24 11:38


s/arch=('i686' 'x86_64')/arch=('i686' 'x86_64' 'armv7h')/

I compile on a Cubox (Linux cubox 3.4.0-1-ARCH+ #1 PREEMPT Tue Jun 5 17:21:42 UTC 2012 armv7l GNU/Linux) and it works.


Anonymous comment on 2011-11-26 15:31

Should use cython2 instead of cython in make-depends, fails to build otherwise.

makedepends=('setuptools' 'cython2')
instead of
makedepends=('setuptools' 'cython')

chneukirchen commented on 2011-10-16 20:58

Missing dependency: extra/python-imaging

Anonymous comment on 2011-06-22 17:32

There is a patch needed for that can be found on

The patch is here:

This patch fixes a '<' '>' mapping issue on English (US) keyboard layouts.