xpra icon
Bug tracker and wiki

This bug tracker and wiki are being discontinued
please use https://github.com/Xpra-org/xpra instead.

Opened 9 years ago

Closed 9 years ago

Last modified 12 months ago

#193 closed defect (fixed)

Name of libwebp-library including version is hardcoded and breaks for new libwebp

Reported by: olifre Owned by: Antoine Martin
Priority: major Milestone: 0.7
Component: core Version: trunk
Keywords: Cc:

Description (last modified by Antoine Martin)

First: Thanks for xpra! It is working perfectly well!
However, it totally broke for me with the 0.7.0-release ;).

After install on a gentoo-system, I am greeted by the following lines when launching "xpra":

cannot load vpx codec: cannot import name codec
cannot load x264 codec: cannot import name codec
Traceback (most recent call last):
  File "/usr/bin/xpra-2.7", line 4, in <module>
    import xpra.scripts.main
  File "/usr/lib64/python2.7/site-packages/xpra/scripts/main.py", line 76, in <module>
    from xpra import webm           #@UnusedImport
  File "/usr/lib64/python2.7/site-packages/xpra/webm/__init__.py", line 54, in <module>
    _LIBRARY = loader.LoadLibrary(_LIBRARY)
  File "/usr/lib64/python2.7/ctypes/__init__.py", line 443, in LoadLibrary
    return self._dlltype(name)
  File "/usr/lib64/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

This bug report is about the last line. On my system, I have the following libraries:


with media-libs/libwebp-0.2.0 installed.
"src/xpra/webm/__init__.py" checks for libwebp.so.2, which I guess is an older version, so xpra fails to launch.
Is libwebp.so.4 not supported (yet)? If so, at least xpra should launch and drop libwebp-support ;).

Change History (4)

comment:1 Changed 9 years ago by Antoine Martin

Description: modified (diff)
Status: newaccepted

This is more complicated than it seems... (isn't it always with packaging issues?)

First, the code is cloned from python-webm, until it makes its way into various distros (not available on gentoo yet) - so this bug really belongs upstream..

Second, each distro packages a different version (we should be compatible with all currently shipped versions - afaik), in different ways: in different places with different names. ie:

  • /usr/lib64/libwebp.so[.so.4[.0.0]] on gentoo
  • /usr/lib/i386-linux-gnu/libwebp.so.2[.0.0] on debian sid

Here is an improvement: r1884 will now try various library names, including plain libwebp.so so you should get webp on gentoo ok now.

Third, the python webm (as it is confusingly called) module does its loading from the package initializer, so we cannot easily differentiate between cases where the webp support is not enabled and cases where webp should be enabled but is failing.. I will try to get a fix in for that in 0.8.x - this is also the reason for the messages:

cannot load vpx codec: cannot import name codec
cannot load x264 codec: cannot import name codec

If webm is still missing, r1885 onwards will print a message similar to the ones above and continue.
Note: this will cause problems when used with software parsing the output of xpra (ie: winswitch) as a simple "xpra version" prints more than just the version string expected because of those errors..

Until the next release, there are workarounds you can try (in no particular order):

  • creating a symlink to libwebp.so.2 - should just work but this is dirty
  • remove the whole python "xpra/webp/" directory - also a bit dirty
  • apply one or more of the patches above during the build
  • drop the updated main.py and __init__.py files on top of your ebuild installation - also dirty

I will try to come up with something for 0.7.1 - sorry.

comment:2 Changed 9 years ago by olifre

The new solution looks much better.
I chose to apply both r1884 and r1885 as patches to the released xpra-0.7.0 source in the hacked-together gentoo-ebuild, and it works perfectly well now.
Finally after I also applied the patch from #194 xpra 0.7.0 works perfectly well again (and also finds x264 and vpx again) and I can see the new graphs :).

I guess gentoo upstream will pick up the package again after a 0.7.1-release (they still have a hard-masked 0.6.4 lying around in their ebuild-tree), if not I will open a bug on their tracker so they do it ;-).

No problem with the bugs, you are investing a lot of time into xpra judging from your commits, and there is always some magic breaking new releases for some distros. That's the point where my job as the user of the peculiar distro starts ;).

Thanks again :).

comment:3 Changed 9 years ago by Antoine Martin

Resolution: fixed
Status: acceptedclosed

r1902 applied the same fix to trunk.

The rest will be dealt with in #196

comment:4 Changed 12 months ago by migration script

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

Note: See TracTickets for help on using tickets.