Xpra: Ticket #266: CentOS 5.9 installation issues with 0.8.5

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.

  1. I tried to launch with dbus-launch xpra --no-daemon --bind-tcp= --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
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

Wed, 20 Feb 2013 02:36:17 GMT - Antoine Martin: priority, status changed; owner set

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)

Wed, 20 Feb 2013 08:18:37 GMT - Antoine Martin:

The struct.pack_into error is fixed by r2746 + r2747

Thu, 21 Feb 2013 05:29:42 GMT - Antoine Martin:

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 -d all?

Sun, 24 Feb 2013 15:28:16 GMT - Antoine Martin:

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

Works-for-me(tm). Adding dbus-launch to the mix does not make any difference. Please provide more details.

Thu, 28 Feb 2013 09:03:29 GMT - Antoine Martin: status changed

Thu, 28 Feb 2013 09:04:08 GMT - Antoine Martin: owner changed

please confirm/close this ticket

Mon, 04 Mar 2013 18:31:57 GMT - alas:

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
  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'

Tue, 05 Mar 2013 06:26:22 GMT - Antoine Martin:

The is_set issue is fixed in r2839 and will be in the next 0.8.x release.

The 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 0.9.0-3

Wed, 06 Mar 2013 18:29:15 GMT - alas:

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.

Wed, 06 Mar 2013 18:34:18 GMT - Antoine Martin: owner, status changed

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?

The xpra stop may be more tricky to workaround, but I'll see what I can do.


Wed, 06 Mar 2013 21:32:18 GMT - alas:

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.

Thu, 07 Mar 2013 04:08:13 GMT - Antoine Martin:

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.

Thu, 07 Mar 2013 14:03:46 GMT - Antoine Martin: summary changed

Confirmed the focus bug, moved it to #282 Moved the glib error to #283 The tuple error from comment:9 is fixed in r2901

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)

Fri, 08 Mar 2013 06:42:49 GMT - Antoine Martin: owner, status changed

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 0.9.0-7.el5.

Wed, 13 Mar 2013 02:18:55 GMT - alas: status changed; resolution set

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.

Sat, 23 Jan 2021 04:50:01 GMT - migration script:

this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/266