Package Details: xpra-winswitch 0.17.6-1

Git Clone URL: https://aur.archlinux.org/xpra-winswitch.git (read-only)
Package Base: xpra-winswitch
Description: Modified version of xpra by Winswitch
Upstream URL: http://xpra.org/
Licenses: GPL2
Conflicts: parti-all
Provides: parti-all
Submitter: bug
Maintainer: bug
Last Packager: bug
Votes: 72
Popularity: 0.769743
First Submitted: 2011-05-26 08:08
Last Updated: 2016-10-29 16:53

Required by (2)

  • qconnect (requires xpra-winswitch) (optional)
  • winswitch (requires parti-all) (optional)

Sources (3)

Latest Comments

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/tmpAQzs_b.cl)
Traceback (most recent call last):
File "/usr/lib/python2.7/site-packages/xpra/codecs/csc_opencl/colorspace_converter.py", line 441, in bui
program.build()
File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", line 438, in build
options_bytes=options_bytes, source=self._source)
File "/usr/lib/python2.7/site-packages/pyopencl/__init__.py", 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/tmpAQzs_b.cl)
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/tmpAQzs_b.cl)

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
to
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:

gtkglext
python2-gtkglext
python-lz4
python-crypto
python-cryptography
python2-crypto
python2-cryptography
python-opengl
python2-opengl
freeglut

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*

HTH.

Clemmitt

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.

Clemmitt

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 setup.py build || return 1
no need to add a line
thanks again for your work.

bug commented on 2016-07-07 08:03

Hey,

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

Hi,

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 :)

Clemmitt

cmsigler commented on 2016-05-19 23:42

Hi,

@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.

Clemmitt

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 xpra.org is used, with no patches?

bug commented on 2016-03-13 05:08

https://wiki.archlinux.org/index.php/Systemd/User#Xorg_as_a_systemd_user_service
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

Hi,

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 = http://xpra.org/
install = xpra-winswitch.install
...
========

For PKGBUILD:
========
--- a/PKGBUILD
+++ b/PKGBUILD
@@ -1,8 +1,8 @@
# Contributor: Bug <bug2000@gmail.com>
# Maintainer: Bug <bug2000@gmail.com>
pkgname=xpra-winswitch
-pkgver=0.16.1
-pkgrel=2
+pkgver=0.16.2
+pkgrel=1
pkgdesc="Modified version of xpra by Winswitch"
arch=('i686' 'x86_64')
url='http://xpra.org/'
...
========

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.

HTH.

Clemmitt

cmsigler commented on 2016-01-12 14:01

Hi,

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 :)

Clemmitt

allspark commented on 2015-11-17 18:34

Hi

i just tried to compile this packages in a clean chroot (https://aur.archlinux.org/packages/clean-chroot-manager) 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 https://www.xpra.org/trac/ticket/960 . 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/compression.py ), 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().
Aborting...

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: https://www.xpra.org/trac/ticket/597

Basically the problem is in /usr/lib/python2.7/dist-packages/xpra/scripts/main.py:
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.
https://www.xpra.org/trac/ticket/587#ticket

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 (https://wiki.archlinux.org/index.php/Xpra)?

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:


Timestamp:
01/24/14 16:13:09 (less than one hour ago)
Author:
antoine
Message:
#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
else:
self.pixel_format = BGRA
else:
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?
https://wiki.archlinux.org/index.php/Xpra#Server

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/main.py", line 76, in <module>
from xpra import webm #@UnusedImport
File "/usr/lib/python2.7/site-packages/xpra/webm/__init__.py", line 54, in <module>
_LIBRARY = loader.LoadLibrary(_LIBRARY)
File "/usr/lib/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
return self._dlltype(name)
File "/usr/lib/python2.7/ctypes/__init__.py", line 365, in __init__
self._handle = _dlopen(self._name, mode)
OSError: libwebp.so.2: cannot open shared object file: No such file or directory

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

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

elif sys.platform == "linux2":
_LIBRARY = "libwebp.so.2"

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

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

But libwebp on Arch installs libwebp as:
usr/lib/libwebp.a
usr/lib/libwebp.so
usr/lib/libwebp.so.4
usr/lib/libwebp.so.4.0.0

So no libwebp.so.2 exists. When I changed the python script to use libwebp.so.4 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.
[3935593.579]
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: https://mailman.archlinux.org/pipermail/aur-general/2012-June/019085.html

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

Anonymous comment on 2012-06-24 11:38

In PKGBUILD :

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.

regards

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 0.0.7.22-1 that can be found on https://winswitch.org/trac/ticket/149

The patch is here: https://winswitch.org/trac/attachment/ticket/149/keycode_dont_ignore_level.patch

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