#2449 closed defect (fixed)
Missing jquery.js file error
Reported by: | alas | Owned by: | Antoine Martin |
---|---|---|---|
Priority: | major | Milestone: | 4.0 |
Component: | html5 | Version: | 3.0.x |
Keywords: | Cc: |
Description
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 -
Change History (10)
comment:1 Changed 17 months ago by
Owner: | changed from Antoine Martin to alas |
---|
comment:2 Changed 17 months ago by
Owner: | changed from alas to Antoine Martin |
---|
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?
comment:3 Changed 17 months ago by
Owner: | changed from Antoine Martin to alas |
---|
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.
comment:4 Changed 17 months ago by
Owner: | changed from alas to Antoine Martin |
---|
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.
comment:5 Changed 17 months ago by
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 ...
comment:6 Changed 17 months ago by
Status: | new → assigned |
---|
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.
comment:7 Changed 16 months ago by
The revision no defaulted to zero for the 3.0.1 packages, r24258 will prevent that in the future.
comment:8 Changed 16 months ago by
Resolution: | → fixed |
---|---|
Status: | assigned → closed |
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?
comment:9 Changed 16 months ago by
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.
comment:10 Changed 5 weeks ago by
this ticket has been moved to: https://github.com/Xpra-org/xpra/issues/2449
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:
Our version is correctly packaged and will bring in
js-jquery
and point to it. You can verify with: