Can't install Opera 51 on Ubuntu 14.04 LTS

bbatten

bbatten @ygbourhis

@ygbourhis
Thanks for making the patched deb package available. Unfortunately, wget fails with this message:

Read error at byte 43323441/55094366 (The TLS connection was non-properly terminated.). Giving up.

In the meantime, over at Debian Repository Unofficial, you can follow the link to Google Chrome to download Chrome 65. Installing the deb package also creates an entry under /etc/apt/sources.list.d so that subsequent updates to chrome are enabled. Chrome 65 works fine under Devuan Jessie, and it is fast.

qazerr

qazerr @ygbourhis

@ygbourhis
your method works! thank you!

ygbourhis

ygbourhis @bbatten

@bbatten strange, have you tried with curl or with a browser?

curl https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb _o opera-stable_52_trusty.0.2871.30_amd64.deb

ygbourhis

ygbourhis

Sorry, replace _o by -o before the file name in the curl command

ygbourhis

ygbourhis @bbatten

@bbatten Maybe you have a network issue, for me both wget and curl work:

yves@paradox ~ $ wget https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb

--2018-03-28 10:51:25-- https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb
Résolution de storage.fr1.cloudwatt.com (storage.fr1.cloudwatt.com)… 185.23.94.21
Connexion à storage.fr1.cloudwatt.com (storage.fr1.cloudwatt.com)|185.23.94.21|:443… connecté.
requête HTTP transmise, en attente de la réponse… 200 OK
Taille : 55094366 (53M) [application/x-debian-package]
Enregistre : «opera-stable_52_trusty.0.2871.30_amd64.deb»

100%[============================================================================================================================================================>] 55 094 366 2,99MB/s ds 23s

2018-03-28 10:51:48 (2,33 MB/s) - «opera-stable_52_trusty.0.2871.30_amd64.deb» enregistré [55094366/55094366]

yves@paradox ~ $ curl https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb -o opera-stable_52_trusty.0.2871.30_amd64.deb

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
100 52.5M 100 52.5M 0 0 2767k 0 0:00:19 0:00:19 --:--:-- 2454k

Have you tried with curl or with a browser?

bbatten

bbatten @ygbourhis

@ygbourhis
If it's a network issue, it's a weird one; I have all the network functionality I need to login and reply to your post. Maybe path speed is too slow (see end of post)? Anyway, I tried the download twice yesterday using Firefox, then once more using wget, failing with each.

Earlier this morning I pasted your wget command line into a terminal window, and that failed:
...
2018-03-28 12:07:09 (10.1 KB/s) - Read error at byte 44443264/55094366 (The TLS connection was non-properly terminated.). Giving up.

Then I pasted your curl command line into a terminal window and that failed too:

% Total % Received % Xferd Average Speed Time Time Time Current
Dload Upload Total Spent Left Speed
3 52.5M 3 1859k 0 0 10726 0 1:25:36 0:02:57 1:22:39 13177curl: (18) transfer closed with 53186694 bytes remaining to read

Maybe the line speed is too slow (@10-14 KB/sec)?

So anyway, right now, I'm trying an experiment using wget in which I simply repeat the command after each failure termination on the assumption that it will just pick up where it left off the last time --- aka "Hail Mary"!

I'll post results.

ygbourhis

ygbourhis @bbatten

@bbatten It lloks indeed like a bandwith issue and the connection is closed before the end of download.

Simply modify the original deb if you can get it from opera and then in the download directory of the original fil you can copy paste what follows in a terminal:

sudo apt-get install fakeroot # (If fakeroot is not installed)
fakeroot # this simulates a root environment to preserve file permissions
dpkg-deb -R opera-stable_52.0.2871.30_amd64.deb opera-stable_52 # unpackage the original
sed -i s/'libdbus-1-3 (>= 1.9.14)'/'libdbus-1-3 (>= 1.6.18)'/ opera-stable_52/DEBIAN/control # change the requirement
dpkg-deb -b opera-stable_52 opera-stable_52_trusty.0.2871.30_amd64.deb # rebuild a new package
exit # exit fakeroot environment

You can batch copy/pase all the lines above (with the comments) in a terminal.
<crtl-c> the whole lines above and <caps-ctrl-v> in a gnome/mate/etc... terminal (I tested them).
And you will end up having the same pakckage as I uploaded.
Do not worry if the second last line (before the "exit" command) takes some time, it's normal.

ygbourhis

ygbourhis @bbatten

@bbatten

Could you please give me your time zone?
I will check at your 12:07:09 time (per your log above) in my server logs to see if we have errors to know why you can't download, but I need to know your time zone to convert your 12:07:09 local time to UTC in order to see our server logs at that moment when you had the issue.

Just to check If I have server errors to know if the fact you can't download is from my side or your side

Thanks in advance.

bbatten

bbatten @ygbourhis

@ygbourhis
Thanks for your help. My timezone is PDT (California). I'm in the process of trying to download the package again right now (averaging @ 8-9 KB/s).

California is a long way from France. Maybe the weight of ship traffic passing overhead is squeezing the cable enough to constrict data flow?

Thanks again,

ygbourhis

ygbourhis @bbatten

@bbatten Ok, I will check if we have error logs at that time.

However, we managed to reproduce the issue by simulating a 10KB/s download (with 'trickle' : http://manpages.ubuntu.com/manpages/xenial/man1/trickle.1.html ).
We are trying to fix this but have no idea how long it will take, so thanks for noticing this, I logged a BUG issue concerning our servers

Try the --continue and --tries parameters with wget. Or did you try modifying the opera original package with the commands I gave above?

I hope that the Opera guys will note that their browser works well with trusty and that they'll reconsider packaging it properly (If they are a minimum serious they should, I think that we did the QA for them with the modified package).

The more we confirm that Opera 52 works on Trusty the more chance they will consider "not losing users" and think repackaging. Especially knowing that Trusty is still supported for one more year.

bbatten

bbatten @ygbourhis

@ygbourhis
Well, things don't appear to be looking too good.

First, I downloaded Opera's deb package for 52.0.2871.37, then applied your procedure to patch the package using these commands as root:

dpkg-deb -R opera-stable_52.0.2871.37_amd64.deb opera-stable_52
sed -i s/'libdbus-1-3 (>= 1.9.14)'/'libdbus-1-3 (>= 1.6.18)'/ opera-stable_52/DEBIAN/control
dpkg-deb -b opera-stable_52 opera-stable_52_trusty.0.2871.37_amd64.deb
dpkg -i opera-stable_52_trusty.0.2871.37_amd64.deb

The package installed without any error indications, but when I tried to run the executable, Opera's start screen flashed for about a second, then reappeared with a message saying opera was recovering from a crash. This sequence repeated three more times before it ended. Here's the first two of six lines of what's in syslog:

Mar 29 14:43:43 Pentium90 kernel: [344076.864647] opera[13671]: segfault at 148 ip 000000000380ffa9 sp 00007fff9304b570 error 4 in opera[1a1e000+5afc000]
Mar 29 14:43:51 Pentium90 kernel: [344085.252247] opera[13910]: segfault at 148 ip 000000000380ffa9 sp 00007fff06c26fa0 error 4 in opera[1a1e000+5afc000]
...

Perhaps there's a pilot error here in trying to apply a patch for one version of the package against a later version?

Next, I tried downloading your patched package 52_trusty.0.2871.30 using wget with "-c --tries=0" options per your suggestion. This completed - apparently successfully - after about six hours and 26 tries at an average speed of 4-6 KB/s. However, when I tried to install, theinstallation failed. Here's the console interaction.

-su(root)# dpkg -i opera-stable_52_trusty.0.2871.30_amd64.deb
(Reading database ... 214731 files and directories currently installed.)
Preparing to unpack opera-stable_52_trusty.0.2871.30_amd64.deb ...
Unpacking opera-stable (52.0.2871.30) over (50.0.2762.67) ...
dpkg-deb (subprocess): decompressing archive member: lzma error: compressed data is corrupt
dpkg-deb: error: subprocess <decompress> returned error exit status 2
dpkg: error processing archive opera-stable_52_trusty.0.2871.30_amd64.deb (--install):
cannot copy extracted data for './usr/lib/x86_64-linux-gnu/opera/icudtl.dat' to '/usr/lib/x86_64-linux-gnu/opera> /icudtl.dat.dpkg-new': unexpected end of file or stream
Processing triggers for menu (2.1.47) ...
Errors were encountered while processing:
opera-stable_52_trusty.0.2871.30_amd64.deb

I suspect that here there may really be an undetected or unnoticed wget error based on the long wall clock time and slow communication rate.

Looks like it may be a little early to conclude that opera works OK with the down-revved libdbus-1-3 dependency. Interested in hearing your comments.

Thanks,

bbatten

bbatten @bbatten

@bbatten
Color me embarrassed. I neglected to follow "dpkg -i ..." at the end of the package modification attempt described above with "ldconfig".
Now working fine.
Nevermind.

A Former User

It Works !!!
Thank you very much!!!

ygbourhis

ygbourhis @bbatten

@bbatten So modifying by hand works for you also?
If so, this is good news and I hope opera will consider repackaging with proper requirements.

ygbourhis

ygbourhis

New version 52.0.2871.40 is out, so:

fakeroot
dpkg-deb -R opera-stable_52.0.2871.40_amd64.deb opera-stable_52
sed -i s/'libdbus-1-3 (>= 1.9.14)'/'libdbus-1-3 (>= 1.6.18)'/ opera-stable_52/DEBIAN/control # change the requirement
dpkg-deb -b opera-stable_52 opera-stable_52_trusty.0.2871.40_amd64.deb
exit

available here
https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.40_amd64.deb

Opera Guys: we've proven it works with libdbus-1-3 (>= 1.6.18). So could you just do a proper packaging job?

Thanks in advance.

leocg

leocg Moderator Volunteer @ygbourhis

@ygbourhis I don't think they will change the minimum requirements to install Opera.

ygbourhis

ygbourhis @leocg

Hi @leocg Is there no chance that they change their decision to support 14.04 till EOS?
All those here who tried my solution did the free QA for Opera guys and proved irrelevant to not support 14.04
We did the effort to validate that it works on 14.04 Could we not expect a least effort now from Opera?
The change is just so trivial.

leocg

leocg Moderator Volunteer @ygbourhis

@ygbourhis If they decided to set Ubuntu 16.04 as the minimum version to install Opera on that system, it's because they have good reasons for doing it.

bbatten

bbatten @ygbourhis

@ygbourhis
I downloaded the deb file for 52.0.2871.40 from Opera's download site and applied your package patch Fri 3/30/18. I've been using it regularly since then and everything seems to be working right except for the No-Script Suite Lite extension.

Opera crashes every time I click on the script's gear icon unless I'm in Opera's settings tab. Opera 52.0.2871.40 installed on Ubuntu 16.04 does not have that problem.

I'm digging a little deeper to see if I can get some idea of what's going on, but in my view it may be a little early to claim absolutely everything works. I'll post what - if anything - I find out here.

bbatten

bbatten @bbatten

@ygbourhis Duh. It just now dawned on my that you are using Ubuntu 14.04. Can you click on the No-Script Lite gear icon from any web page (not just the settings tab) without getting a crash?

If so, I think that would remove the qualm I have about the down-revved libdbus-1-3 requirement. I use my Devuan system as a development box, so its configuration may not be entirely cruft free. After all, as you say, the change is very trivial.

Thanks again for the package patch.