Package Details: xpra-winswitch 1.0.3-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: 76
Popularity: 2.384511
First Submitted: 2011-05-26 08:08
Last Updated: 2017-02-14 20:46

Latest Comments

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?

All comments