Xpra: Ticket #851: Rencode error on 0.15.0 Fedora 20 and 21 builds

Running a Fedora 20 and 21 r9137 0.15.0 Servers (from xpra.org/beta):

Running an xpra list and xpra stop :13 prints the following:

[max@ueberraschung ~]$ xpra list
2015-05-01 14:10:20,452 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
Found the following xpra sessions:
	LIVE session at :13
[max@ueberraschung ~]$ xpra stop :13
2015-05-01 14:10:24,183 rencode at '/usr/lib64/python2.7/site-packages/rencode/__init__.pyc' lacks versioning information
server requested disconnect: server shutdown
Failed to shutdown xpra at :13

In addition, I see the rencode error on server start, and on xpra info :13

Sat, 02 May 2015 04:15:58 GMT - Antoine Martin: status changed; resolution, milestone set

You have not installed the latest python-rencode package, which means that you don't have xpra.org added as a repository as per the Fedora installation instructions.

Worrying thing is that other packages may also be missing and causing or hiding problems.

Sat, 13 Jun 2015 15:00:20 GMT - jonathan.underwood: status changed; resolution deleted

Hi Antoine,

I am re-opening this, as we're hitting this on Fedora with 0.15.0 when not using the xpra repos, but rather installing everything from the Fedora repos. I am really keen for xpra to be usable straight from the Fedora repos without enabling the xpra repos, and want to work with you towards that goal.

It seems like the underlying problem here is that you've forked rencode. Do you plan to submit the changes upstream? I haven't looked closely, but what are the reasons for, and extent of, the changes? Thanks in advance.

Sat, 13 Jun 2015 21:46:47 GMT - Antoine Martin: status changed; resolution set

I am really keen for xpra to be usable straight from the Fedora repos without enabling the xpra repos

This warning should make absolutely no difference in usability.

It seems like the underlying problem here is that you've forked rencode.

Fork might be too strong a word, just patched and produced a snapshot to make it easier to package for us. (since we've been packaging it for a very long time now, not just for Fedora and centos, but also win32, osx, and Debian / Ubuntu..)

Do you plan to submit the changes upstream?

Done already, a long time ago. (though it looks like googlecode ate it) IIRC, there is only one change: we've added versioning information.

what are the reasons for, and extent of, the changes

As per above, just adding version information.

AFAICT, your options are (both are trivial):

FYI: the vast majority of bugs that get reported are due to funky installations (missing dependencies, unusual file locations, etc) and sometimes because of unusual client-server combinations. Having complete version information about all the components is extremely useful to us. (something we've expanded further in the upcoming 0.16 release, to record many of the build-time library version details)

I am closing as invalid again, because we will not be changing the xpra code to remove this warning anytime soon, sorry!

Sun, 14 Jun 2015 12:11:25 GMT - Antoine Martin:

Just one more thing: although this sort of duplicating may be frowned upon, I claim that our decision to avoid relying on unreliable external code hosting systems has been vindicated once again. (often a problem with sourceforge, or in this case with googlecode) These services come and go, they change their download links for no good reason and without warning (how many times has webp moved its download folder for example?) - and we need to have a reliable build infrastructure. Not spending hours updating all the branches to new the new shiny URL every time we need to make new builds. (or miss new releases because they're not where we expect them to be)

Sun, 14 Jun 2015 12:37:37 GMT - jonathan.underwood:

Hi Antoine,

I wasn't looking to pass any kind of judgement on your development practices, so please don't take my comment about patching/forking/bundling rencode as any kind of criticism, personal or professional. In fact, you've been very helpful in unbundling rencode from the xpra tarball - that has saved a lot of packaging work for me - prior to that we had to patch xpra to use the system installed rencode, and that patch needed to be rebased with each release.

I understand your reasons for for shipping your own rencode packages. My main concern is ensuring that patches go upstream so we can incorporate them in distros, and to ease shipping and integration of xpra with distros as much as possible. It seems that it is easily solved in this case.

For the record, rencode has moved to github:


I'm not an svn guru, so haven't worked out how to find all the commits which touch your rencode - any chance you could give me the magic voodoo?

Sun, 14 Jun 2015 12:43:47 GMT - Antoine Martin: attachment set

diff between upstream on github and our copy

Sun, 14 Jun 2015 12:49:14 GMT - jonathan.underwood:

Thanks - I've already done the diff, but I was hoping to pull out the individual revisions so I could look at the log messages for the changes and perhaps generate a patchset for upstream submission rather than a big diff. Anyhow, I'll continue to read the svn manual, or perhaps create a git repo from the svn repo.

Sun, 14 Jun 2015 12:54:46 GMT - Antoine Martin:

Sorry, there is no history, and that's kind of why I placed it under our svn: so we could track changes when they are made in the future - which did not happen, no bugs or fixes since it got checked in... svn log rencode shows:

r7859 | antoine | 2014-10-02 07:57:55 +0200 (Thu, 02 Oct 2014) | 1 line
forgot to bump version here..
r7672 | antoine | 2014-09-17 16:38:24 +0200 (Wed, 17 Sep 2014) | 1 line
ensure build files don't get added to svn
r7671 | antoine | 2014-09-17 16:17:13 +0200 (Wed, 17 Sep 2014) | 9 lines
#683: unbundle python-rencode
* move it to its own directory
* remove build option in our setup.py
* re-instate utf8 option in rencode.loads (even though we don't use it)
* fix some tests (make it python2.6 compatible)
* add spec file
* depend on new package from xpra specfile
* load from global location in packet_encoding.py
* bump the version no

From the diff attached, I can see the following changes by scrolling through it:

Sun, 14 Jun 2015 12:58:00 GMT - jonathan.underwood:

Thanks Antoine, that explains why I wasn't getting anywhere with svn... I thought it was just my Sunday brain.

I'll open an issue on the upstream github repo pointing to this page and asking to merge the changes.

Sun, 14 Jun 2015 13:00:09 GMT - Antoine Martin:

Just to be clear: not all changes should be merged, for example the #@DuplicatedSignature is only useful for pydev users, and I should probably merge a few things myself (Deluge vs rencode, documentation?)

And it would probably be worth bumping the revision to 1.1 or something, to get back in sync.

Sun, 14 Jun 2015 13:38:05 GMT - jonathan.underwood:

OK, I have broken the diff up into a series of patches and issued a github pull request. See:


Sun, 14 Jun 2015 13:39:04 GMT - Antoine Martin:

Awesome! thanks.

Sun, 14 Jun 2015 19:20:49 GMT - jonathan.underwood:

OK, my pull requst has been merged upstream. While reviewing, the strategy for detecting python 3 was changed from what you have in your tree...

You were doing:

py3 = sys.version >= '3'

whereas what we've merged does:

py3 = sys.version[0] >= 3

Andrew has also made a release:


So, hopefully this brings everything back together.

Sat, 23 Jan 2021 05:07:52 GMT - migration script:

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