Updated fedora 30 server to 3.0-r24043 (from stable dists) and launched with the following command line.
xpra start :13 --no-daemon --bind-tcp=0.0.0.0:1234 --bind-ws=0.0.0.0:1237 --start-child=xterm --start-child=xterm --exit-with-children
Then tried to connect with Chrome html5 client (Windows 7, Chrome 77), and all that I see is a blank canvas.
The server logs show No such file of directory for /usr/share/xpra/www/js/lib/jquery.js ... with -d all on server, I get a traceback that may help.
2019-10-16 16:32:45,092 send_head() script(/js/lib/jquery.js)=None
2019-10-16 16:32:45,092 translate_path(/js/lib/jquery.js)=/usr/share/xpra/www/js/lib/jquery.js
2019-10-16 16:32:45,092 send_head()
Traceback (most recent call last):
File "/usr/lib64/python3.7/site-packages/xpra/server/http_handler.py", line 226, in send_head
f = open(path, 'rb')
FileNotFoundError: [Errno 2] No such file or directory: '/usr/share/xpra/www/js/lib/jquery.js'
2019-10-16 16:32:45,093 Error sending '/usr/share/xpra/www/js/lib/jquery.js':
2019-10-16 16:32:45,093 [Errno 2] No such file or directory
2019-10-16 16:32:45,093 code 404, message File not found
2019-10-16 16:32:45,093 "GET /js/lib/jquery.js HTTP/1.1" 404 -
My guess is that you have installed the package installed from fedora instead of xpra. They've packaged xpra 3.0 as an update, and done a terrible job of it, as usual. I'll have to bump the package version just to override their mess.
Try:
sudo dnf remove "xpra*" sudo dnf --disablerepo=updates --enablerepo=winswitch install -y xpra
Our version is correctly packaged and will bring in js-jquery and point to it. You can verify with:
ls -la /usr/share/xpra/www/js/lib/jquery.js
Well you are definitely correct.
Following those steps, I do find the file.
[root@xpra-lib-fed30-2 maint]# ls -la /usr/share/xpra/www/js/lib/jquery.js lrwxrwxrwx. 1 root root 40 Sep 30 14:29 /usr/share/xpra/www/js/lib/jquery.js -> /usr/share/javascript/jquery/3/jquery.js
But starting a new server with the same command, I'm seeing new dbus errors...
(==) Using system config directory "/usr/share/X11/xorg.conf.d" 2019-10-16 17:23:43,823 dbus-launch failed to start using command 'dbus-launch --sh-syntax --close-stderr': 2019-10-16 17:23:43,823 exit code is 255
... and a failure with some libyuv ... something.
2019-10-16 17:23:50,175 Error importing libyuv colorspace conversion (csc_libyuv) 2019-10-16 17:23:50,175 /lib64/libyuv.so.0: undefined symbol: jpeg_resync_to_restart
... as well as my usual failures and warnings (which I will refrain from confusing issues here with).
Is it possible that the fedora repos have different dependencies that caused different dbus and libyuv results?
dbus-launch failed to start using command 'dbus-launch --sh-syntax --close-stderr'
dbus-x11 should have been installed as a dependency of python3-xpra-server. Can you check that it is installed?
dbus-launch --version
Can you run xpra again with -d dbus?
Error importing libyuv colorspace conversion (csc_libyuv)/lib64/libyuv.so.0: undefined symbol: jpeg_resync_to_restart
My guess is that you should run dnf update to get the newest libyuv RPM.
No need to disable any repositories this time, but if dnf tries to upgrade xpra from "updates", use dnf --exclude="*xpra*" to avoid doing that.
You should have:
$ rpm -qa | grep libyuv-0 libyuv-0-0.35.20190401git4bd08cb.fc30.x86_64
I will bump the revision with 3.0.1 to avoid this whole fedora inflicted mess.
Looks like dbus-x11 is not installed after all.
[maint@xpra-lib-fed30-2 ~]$ dbus-launch --version -bash: dbus-launch: command not found [maint@xpra-lib-fed30-2 ~]$ sudo dbus-launch --version [sudo] password for maint: sudo: dbus-launch: command not found
So, I installed dbus-x11 and also ran a dnf --exclude="*xpra*" update (because otherwise it wanted to pull in the 3.0.1 that it looks like you built)... and then launched again.
At this point the server (3.0r24048) launches with only my usual errors.
I'll pass this back to you to decide if you want to wait to sort out the dbus-x11 dependency before closing it or if you just want to close the ticket now that the cause is clear... and then I'll update to the 3.0.1 and make a new ticket if that has an issue still.
Well, it looks like I'm hitting more of a packaging issue than use issue with 3.0.1, so I'll just put it here.
It looks like, with the 3.0r24048 installed, the update has a huge list of conflicts... I'll just post the beginnings.
Running transaction test The downloaded packages were saved in cache until the next successful transaction. You can remove cached packages by executing 'dnf clean packages'. Error: Transaction test error: file /etc/xpra/conf.d/16_printing.conf from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-3.0-0.r24048.fc30.noarch file /usr/bin/xpra from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-3.0-0.r24048.fc30.noarch file /usr/bin/xpra_launcher from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-3.0-0.r24048.fc30.noarch file /usr/bin/xpra_signal_listener from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-3.0-0.r24048.fc30.noarch file /etc/xpra/conf.d/55_server_x11.conf from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-server-3.0-0.r24048.fc30.noarch file /usr/lib/cups/backend/xpraforwarder from install of xpra-3.0-1.fc30.x86_64 conflicts with file from package xpra-common-server-3.0-0.r24048.fc30.noarch ...
So, I installed dbus-x11 and also ran a dnf --exclude="*xpra*" update
The fedora package is missing the dependency.
And when you disable their broken repository to install the "correct" xpra, you don't get dbus-x11 and a bunch of other things...
It looks like, with the 3.0r24048 installed, the update has a huge list of conflicts... I'll just post the beginnings.
Nothing we can do about this: once again this is the Fedora package completely messing up our packaging, which predates theirs by years. Thanks Fedora!
I'm keeping the ticket open until 3.0.1 is released so that I can remember to re-try installs and upgrades.
The revision no defaulted to zero for the 3.0.1 packages, r24258 will prevent that in the future.
Using the stable xpra repo a dnf update (fedora 30) is picking up 3.0.1-r24252.
Not seeing any sign of missing files, so I'll close this (assuming you already also tested the 3.0.1 installs and upgrades on a variety of platforms).
Though... while it doesn't look like the r24258 has a build in the repo... the revision no. is not 0?
Better explanation: the rpm revision no in a package name like xpra-common-3.0-0.r24048.fc30.noarch is the -0 which follows the version number.
We need to use a -1 or higher to ensure the broken Fedora packages don't upgrade ours.
This will be the case with 3.0.2
It worked without for now, because 3.0.1 was not in the Fedora repos.
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2449