xpra icon
Bug tracker and wiki

Opened 3 years ago

Closed 3 years ago

#1028 closed defect (fixed)

0.15.8-r11169 beta rpm build Is broken

Reported by: J. Max Mena Owned by: alas
Priority: blocker Milestone: 0.16
Component: server Version: 0.15.x
Keywords: Cc:

Description

The package in question is

xpra-0.15.8-0.20151110r11169.fc21.x86_64
and
xpra-common-0.15.8-0.20151110r11169.fc21.noarch

Downloaded from https://www.xpra.org/beta/Fedora/21/x86_64/

Attempting to start a server gives the following traceback:

[max@ueberraschung ~]$ xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-child=xterm --start-child=xterm
Traceback (most recent call last):
  File "/usr/bin/xpra", line 3, in <module>
    from xpra.platform import init
ImportError: No module named xpra.platform

Also, one of the two(or both) packages isn't signed.

Change History (7)

comment:1 Changed 3 years ago by Antoine Martin

Owner: changed from Antoine Martin to J. Max Mena
Priority: criticalblocker

Cannot reproduce.

Are you sure you aren't mixing a source installation with this binary?
Try to clean your system:

sudo yum remove -y xpra xpra-common
sudo find /usr -name "*xpra*" -exec rm -fr {} \;
sudo yum install -y xpra

You may then need to re-install a number of libraries to avoid errors (libvpx-xpra, ffmpeg-xpra, etc), but this should be enough to test.

Raising as I am delaying the stable update to get this issue closed.

comment:2 Changed 3 years ago by alas

I ran the system cleaning steps above, then tried to install the package indicated by maxmylyn:

[tlaloc@jimador ~]$ sudo find /usr -name "*xpra*" -exec rm -fr {} \;
find: ‘/usr/share/doc/libvpx-xpra’: No such file or directory
find: ‘/usr/share/doc/x264-xpra’: No such file or directory
find: ‘/usr/share/doc/ffmpeg-xpra-devel’: No such file or directory
find: ‘/usr/share/doc/ffmpeg-xpra’: No such file or directory
find: ‘/usr/lib64/xpra’: No such file or directory
find: ‘/usr/include/xpra’: No such file or directory

...

[tlaloc@jimador ~]$ sudo yum install xpra-0.15.8-0.20151110r11169.fc21 xpra-common-0.15.8-0.20151110r11169.fc21

The package is definitely not signed: Package xpra-0.15.8-0.20151110r11169.fc21.x86_64.rpm is not signed.

Launching (windows client 0.15.8 r11178), I was getting a variety of warnings about encoders that couldn't be loaded.

2015-11-11 10:44:47,746 video encoder 'enc_x264' could not be loaded:
2015-11-11 10:44:47,748  libx264.so.146: cannot open shared object file: No such file or directory
2015-11-11 10:44:47,748 Warning: pulseaudio has terminated shortly after startup.
2015-11-11 10:44:47,748 video encoder 'enc_vpx' could not be loaded:
2015-11-11 10:44:47,749  Either fix the pulseaudio command line or use the 'pulseaudio=no' option to avoid this warning.
2015-11-11 10:44:47,749  libvpx.so.2: cannot open shared object file: No such file or directory
2015-11-11 10:44:47,750  usually, only a single pulseaudio instance can be running for each user account, and one may be running already
2015-11-11 10:44:47,750 video encoder 'nvenc4' could not be loaded:
2015-11-11 10:44:47,751  No module named pycuda
2015-11-11 10:44:47,751 xpra is ready.
2015-11-11 10:44:47,751 csc module csc_swscale could not be loaded: libswscale.so.3: cannot open shared object file: No such file or directory

I went through the xpra-related libraries of the repo, as mentioned above, but it looks like I only had to re-install libwebp-xpra. But, even after doing so, I'm still getting these errors.

Upon connection, it looks like I wind up with png asw a primary encoding (?)...

2015-11-11 11:50:43,681 New tcp connection received from ('10.0.11.162', 52081)
2015-11-11 11:50:43,720 Handshake complete; enabling connection
2015-11-11 11:50:43,745 Python/Gtk2 Microsoft Windows 8 client version 0.15.8 connected from 'hasenpfeffer' as 'hassenpfeffer' ('hassenpfeffer')
2015-11-11 11:50:43,746 using png as primary encoding, also available: png/P, png/L, webp, rgb24, jpeg, rgb32
2015-11-11 11:50:43,759 client root window size is 5120x2160 with 1 displays:
2015-11-11 11:50:43,760   '1\WinSta-Default' (1354x571 mm - DPI: 96x96) workarea: 5120x2120
2015-11-11 11:50:43,760     DISPLAY1 3840x2160 at 1280x0 (621x341 mm - DPI: 157x160) workarea: 3840x2120
2015-11-11 11:50:43,760     DISPLAY2 1280x720 (597x336 mm - DPI: 54x54) workarea: 1280x680
2015-11-11 11:50:43,997 server virtual display now set to 5760x2160 (best match for 5120x2160)
2015-11-11 11:50:44,002 setting key repeat rate from client: 500ms delay / 33ms interval
2015-11-11 11:50:44,004 setting keyboard layout to 'us'
2015-11-11 11:50:44,127 DPI set to 96 x 96
2015-11-11 11:50:44,176 sent updated screen size to 1 clients: 5760x2160 (max 8192x4096)
2015-11-11 11:50:44,535 using Pulseaudio device 'Monitor of Dummy Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-11-11 11:50:44,852 sound-source codec: MPEG-1 Layer 3 (MP3)
2015-11-11 11:50:45,160 using Pulseaudio device 'Monitor of Dummy Output'
** Message: pygobject_register_sinkfunc is deprecated (GstObject)
2015-11-11 11:50:47,091 sound-source codec: MPEG-1 Layer 3 (MP3)

Session info indicates the server has only jpeg, png, png/L, png/P, rgb24, rgb32, webp encodings available.

comment:3 Changed 3 years ago by alas

... Interestingly, after testing this, I've been running across issues with these encodings with latest trunk builds as well.

Went back and tried to install libvpx-xpra, x264-xpra, etc ... over and over again, with no luck.

I finally went crazy and removed the lot, then re-installed (sudo yum remove xpra xpra-common libvpx-xpra x264-xpra ffmpeg-xpra)... which worked alright to re-install and run trunk (0.16.0 r11185).

Repeating, and installing the 0.15.8 r11169... I'm now getting an error similar to what maxmylyn is getting:

[tlaloc@jimador ~]$ dbus-launch xpra start :13 --no-daemon --bind-tcp=0.0.0.0:2200 --start-new-commands=yes --start-child=xterm --mdns=no
Traceback (most recent call last):
  File "/usr/bin/xpra", line 3, in <module>
    from xpra.platform import init, set_default_name
ImportError: cannot import name set_default_name

comment:4 Changed 3 years ago by alas

One more note... I'm not sure if the monkeying around with those libraries and encodings is the cause, or not, but I'm also seeing this error with a 0.16.0 server: 2015-11-11 17:46:01,113 Warning: client decoding error: failed to get a gl context.

Seems to be getting triggered when I adjust resolution, etc. on local displays (testing for #697)... let me know if this is a separate issue.

comment:5 Changed 3 years ago by Antoine Martin

Owner: changed from J. Max Mena to alas
Summary: Latest 15.8 Build Is Broken0.15.8-r11169 beta rpm build Is broken

The package is definitely not signed: ...


Like I mentioned before, I can't sign things when I sleep: this package did get signed in the morning, but you then have to download it again.



I was getting a variety of warnings about encoders that couldn't be loaded.


I did warn about this in comment:1 : You may then need to re-install a number of libraries to avoid errors (libvpx-xpra, ffmpeg-xpra, etc), but this should be enough to test.

This means that the package is fine after all and this ticket should be closed as invalid.


Over and over again, with no luck.


Avoid gambling? If on the other hand there are technical issues, please include the details. Installation steps, etc


Repeating, and installing the 0.15.8 r11169... I'm now getting an error similar to what maxmylyn is getting:


As I said above, you're probably messing up your installation somehow by mixing source and binary installs, or because of a mistmatch in package versions (xpra and xpra-common).

r11187 may prevent that in the future, but I am not applying it to the 0.15.x branch yet because it will need testing on all RPM platforms first (all supported versions of fedora and centos).


Warning: client decoding error: failed to get a gl context


That looks like a serious opengl client side error, which would have shown up on your client output.
This has nothing to do with installation issues, though it may have been triggered by the incomplete installation you have used for testing.

Please create a new ticket for this. You should be able to reproduce this problem using a more correct installation and limiting the list of encodings available using --encodings=jpeg,png,png/L,png/P,rgb24,rgb32,webp. (as per above)

comment:6 Changed 3 years ago by J. Max Mena

Are you sure you aren't mixing a source installation with this binary?


100%. This VM doesn't have any development tools installed. I specifically have 2 different Fedora 21 VMs to avoid this; one for source building (that would be my friend Schlafanzug) and another for packages from xpra.org/beta (my other friend Ueberraschung). Although, sometime in the last two weeks or so someone added our internal Xpra repo. There's a slight chance that added to the problem I ran into in the original description....although it's likely unrelated. I removed all our packages and reinstalled them from xpra.org/beta, and disabled our internal repo.

Anyways,

  • Ran clean steps on VM
  • Re-installed packages
  • All is working fine.

I even re-installed the latest trunk package, and then removed and re-installed the old 15.8 package(to reproduce what I had done earlier) and it still works. Not sure what went wrong before.


I'll leave it be for now, Afarr will update it in a bit.

edit: forgot a verb.

Last edited 3 years ago by J. Max Mena (previous) (diff)

comment:7 Changed 3 years ago by alas

Resolution: fixed
Status: newclosed

Uninstalled again, and watched my steps more carefully.

Tried to re-install with sudo yum install xpra-0.15.8-0.20151110r11169.fc21 - at which point the package list made my mistake glaringly obvious:

Installing:
 xpra                    x86_64             0.15.8-0.20151110r11169.fc21                winswitch-beta             2.1 M
Installing for dependencies:
 ffmpeg-xpra             x86_64             2.8.1-1.fc21                                winswitch                  1.3 M
 libvpx-xpra             x86_64             1.4.0-1.fc21                                winswitch                  714 k
 x264-xpra               x86_64             20150909-1.fc21                             winswitch                  440 k
 xpra-common             noarch             0.16.0-0.20151110r11178.fc21                winswitch-beta             538 k

Tried again with sudo yum install xpra-0.15.8-0.20151110r11169.fc21 xpra-common-0.15.8-0.20151110r11169.fc21, and all was well.


As for the opengl bug, I wasn't even able to repro it, at least not easily, with the broken build. I'll keep an eye out and post a new bug if I have any luck (compulsive gambler?) reproing.

Closing this in the meantime.

Note: See TracTickets for help on using tickets.