With a CentOS 5.9 OS fresh install, with curl -O to download xpra 0.8.5 and a yum localinstall to install it, trying to launch xpra creates a Gdk-CRITICAL failure.
dbus-launch xpra --no-daemon --bind-tcp=0.0.0.0:1200 --start-child=xterm start :11
Launch failure with the following log results:
xauth: creating new authority file /root/.Xauthority 2013-02-19 16:32:50,857 your version of PyGTK is too old - expect some bugs Traceback (most recent call last): File "/usr/bin/xpra", line 6, in ? sys.exit(xpra.scripts.main.main(__file__, sys.argv)) File "/usr/lib64/python2.4/site-packages/xpra/scripts/main.py", line 541, in main File "/usr/lib64/python2.4/site-packages/xpra/scripts/server.py", line 432, in run_server File "/usr/lib64/python2.4/site-packages/xpra/server.py", line 182, in __init__ File "/usr/lib64/python2.4/site-packages/xpra/server_base.py", line 60, in __init__ File "/usr/lib64/python2.4/site-packages/xpra/server.py", line 214, in x11_init File "/usr/lib64/python2.4/site-packages/wimpiggy/error.py", line 137, in swallow_synced File "/usr/lib64/python2.4/site-packages/wimpiggy/error.py", line 120, in call_synced File "/usr/lib64/python2.4/site-packages/wimpiggy/error.py", line 112, in _call AttributeError: 'module' object has no attribute 'pack_into' 2013-02-19 16:32:50,918 closing tcp socket 0.0.0.0:1200 2013-02-19 16:32:50,919 removing socket /root/.xpra/localhost.localdomain-11 2013-02-19 16:32:50,919 killing xvfb with pid 2644 (xpra:2638): Gdk-CRITICAL !**: _gdk_xid_table_remove: assertion `GDK_IS_DISPLAY (display)' failed
Although this is not pretty and should be fixed, it should not cause any bad adverse effects apart from some missing window icons. (lowering priority)
I really don't see how this could cause the server to stop since the error comes from a
trap.swallow_sync call (which swallows errors and continues).
Can you check that there aren't any other errors, and maybe post the log with
Just tested on my CentOS 5.x VM:
wget http://xpra.org/dists/CentOS/5.9/x86_64/xpra-0.8.6-1.el5.x86_64.rpm yum install -y xpra-0.8.6-1.el5.x86_64.rpm xpra start :10 --no-daemon (...) xpra is ready
dbus-launch to the mix does not make any difference.
Please provide more details.
please confirm/close this ticket
I went ahead and tried the install on a fresh CentOS 5.9
wget works, but yum install (or yum localinstall) fails to resolve a number of dependencies
--> Processing Dependency: python-uuid for package: xpra --> Finished Dependency Resolution xpra-0.8.6-1.el5.x86_64 from /xpra-0.8.6-1.el5.x86_64 has depsolving problems --> Missing Dependency: python-uuid is needed by package xpra-0.8.6-1.el5.x86_64 (/xpra-0.8.6-1.el5.x86_64) Error: Missing Dependency: python-uuid is needed by package xpra-0.8.6-1.el5.x86_64 (/xpra-0.8.6-1.el5.x86_64) You could try using --skip-broken to work around the problem You could try running: package-cleanup --problems package-cleanup --dupes rpm -Va --nofiles --nodigest The program package-cleanup is found in the yum-utils package.
I guess yum localinstall doesn't support being fed an URL in 5.9 hence I was forced to either use curl -O commands to download epel and rpmfusion packages or, as suggested on the rpmfusion install instruction page, http://rpmfusion.org/Configuration , use rpm -Uvh.
Either way, once the rpmfusion free and not-free, as well as the epel, packages are installed there is no public key installed, so I had to use
yum localinstall --nogpgcheck xpra-0.8.6-1.el5.x86_64.rpm
That done, aside from a pulseaudio issue (I'll post that in the audio thread) xpra almost runs, failing with this message.
2013-02-28 13:42:41,193 using x264 as primary encoding 2013-02-28 13:42:41,194 setting key repeat rate from client: 500ms delay / 33ms interval 2013-02-28 13:42:41,197 setting keyboard layout to 'us' Exception in thread format: Traceback (most recent call last): File "/usr/lib64/python2.4/threading.py", line 442, in __bootstrap self.run() File "/usr/lib64/python2.4/threading.py", line 422, in run self.__target(*self.__args, **self.__kwargs) File "/usr/lib64/python2.4/site-packages/xpra/protocol.py", line 198, in _write_format_thread_loop File "/usr/lib64/python2.4/site-packages/xpra/server_source.py", line 751, in next_packet File "/usr/lib64/python2.4/site-packages/xpra/server_source.py", line 305, in is_closed AttributeError: '_Event' object has no attribute 'is_set'
is_set issue is fixed in r2839 and will be in the next 0.8.x release.
python-uuid is entirely my mistake - sorry about that, I must not have tested the clean
CentOS5 binary rpm install for a very long time (I am re-creating a clean
CentOS VM now)... There are no official 'uuid' packages, so I've solved this in r2857 with a wrapper module that fallsback to using 'uuigen' on installations without uuid module (ie: python2.4).
For the record, those who prefer to use the python 'uuid' module (rather than spawning a process to get a uuid every time) can use pkgs.org to find one. (no guarantees given or implied)
Updated beta packages are available in the CentOS5 beta area as
With the beta installed xpra loads with no more than some warnings about its python being out of date.
With a dbus-launch, however, the xterm window generated won't accept any input (the only way I know how to make xpra do anything). There are also messages about RANDR not being supported.
Warning: X server does not support required extension Randr 2013-03-06 10:21:34,536 error loading or registering our dbus notifications forwarder: 2013-03-06 10:21:34,537 No module named mainloop.glib 2013-03-06 10:21:34,537 if you do not have a dedicated dbus session for this xpra instance, 2013-03-06 10:21:34,537 you should use the '--no-notifications' flag
Also, when xpra is started without the --no-daemon flag the
xpra stop :11 command doesn't seem to stop the xpra.
[KingsBay@localhost ~]$ xpra stop :11 xpra.rencode is missing: 'tuple' object has no attribute 'major' connection closed after 0 packets received (0 bytes) and 0 packets sent (0 bytes) Traceback (most recent call last): File "/usr/bin/xpra", line 6, in ? sys.exit(xpra.scripts.main.main(__file__, sys.argv)) File "/usr/lib64/python2.4/site-packages/xpra/scripts/main.py", line 380, in main File "/usr/lib64/python2.4/site-packages/xpra/scripts/main.py", line 711, in run_stop File "/usr/lib64/python2.4/site-packages/xpra/client_base.py", line 381, in run File "/usr/lib64/python2.4/site-packages/wimpiggy/gobject_compat.py", line 53, in import_glib File "/usr/lib64/python2.4/site-packages/wimpiggy/gobject_compat.py", line 24, in _try_import File "/usr/lib64/python2.4/site-packages/wimpiggy/gobject_compat.py", line 50, in import_glib2 ImportError: No module named glib [KingsBay@localhost ~]$ xpra list Found the following xpra sessions: LIVE session at :11
The lack of a "module named mainloop.glib" seems to become a problem when trying to stop xpra.
The Randr warning is documented here: Xdummy
I'll try the
dbus-launch thing, that's an odd one. By input, do you mean keyboard, mouse, clipboard? Or all of them?
xpra stop may be more tricky to workaround, but I'll see what I can do.
By input I mean that a window with an "inactive" cursor appears but no amount of mouse clicking will make the window "active" so that I can do anything with it.
I'll look through that randr documentation. Maybe there's an update that might make the xterm functional.
oh, that's interesting, I will definitely try it out.
The randr link was just informative, the warning is unrelated and won't help us here.
For the record, there are still a few more issues to deal with so we can have a build without errors or warnings and a fully functional installation (on
CentOS 5.x and other distros with old python too):
The rest of this ticket is about installation (or harmless gdk warnings), I've updated the ticket title, and I've tested the
0.9.0 installation on a "minimal"
CentOS 5.9 x86 VM with:
wget http://xpra.org/beta/CentOS/5.9/i386/xpra-0.9.0-4.el5.i386.rpm rpm --import https://winswitch.org/gpg.asc yum install xpra-0.9.0-4.el5.i386.rpm
And that worked fine - please note that the installation should only be 3 steps now, nothing more. (and it should always be like this when using DEBs/RPMs: the package manager should deal with the dependencies, if it does not then we are probably doing it wrong)
Please confirm that this now works ok (including the separate tickets for focus issues, etc) and close this ticket.
To ease testing, updated beta packages are available as
xpra 0.9.0 beta version works with only a few inconsequential warnings. No sound, but I understand that's expected with CentOS 5.9. Closing.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/266