Posts made by ygbourhis

Guess what?

Opera 53.0.2907.106 is now compatible with trusty "just as is" (no need for my backports script). Indeed, I inspected the new package, the requirement is now set to libdbus-1-3 (>= 1.6.18)

Now that's good news

@metaltrabant You're welcome.
The only issue with my script is that we need to manually check for opera updates. But indeed it allows postponing the LTS upgrade.

I removed the old packages and instead made a script to automaticaly create a backported opera version for trusty.

Here it is:

https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/backport_opera_5x_to_trusty.sh
Or here:
https://gist.githubusercontent.com/ygbourhis/2033f03f93377b71c29fa0fcbfd71b75/raw/14fbac7c467891c7d9ce4917b74d9df2bad8a5cb/backport_opera_5x_to_trusty.sh

Once downloaded make it executable:

chmod a+x backport_opera_5x_to_trusty.sh

And simply launch this command in the directory where you downloaded opera:

./backport_opera_5x_to_trusty.sh opera-stable_52.0.2871.64_amd64.deb

(Replace opera-stable_52.0.2871.64_amd64.deb with the newly downloaded version)

You can find the source code here:
https://gist.github.com/ygbourhis/2033f03f93377b71c29fa0fcbfd71b75

Hope this helps.

@bbatten Ok, so it's an add on. Did you try deinstalling and then reinstalling the noscript addon?
I added it : https://addons.opera.com/fr/extensions/details/noscript-lite/
And have no issue with Opera 52 on Linux Mint Qiana (Based on Ubuntu Trusty).

@bbatten Are you using a plugin? because I do not have this Icon.
With Opera 52 repackaged for trusty even the following issue is fixed: https://forums.opera.com/topic/24496/opera-crashes-in-menu-bookmarks
While if I stay with the last opera 14.04 compatible I can't access my bookmarks without a crash.
Have you tried with a new opera profile? Maybe you have some incompatible plugin.

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.

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.

@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.

@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

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 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.

@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?

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

@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

@jimunderscorep

I'm just replying from Opera 52 under Linux mint Qiana (Ubuntu Trusty)

To do this I did the following:

fakeroot
dpkg-deb -R opera-stable_52.0.2871.30_amd64.deb opera-stable_52
vim opera-stable_52/DEBIAN/control # Change to "libdbus-1-3 (>= 1.6.18)" and save
dpkg-deb -b opera-stable_52 opera-stable_52_trusty.0.2871.30_amd64.deb
exit

The repackaged file is here:
https://storage.fr1.cloudwatt.com/v1/AUTH_71c6d0f9c3eb4f5a95cebeae99f3b468/Opera_Repackaged/opera-stable_52_trusty.0.2871.30_amd64.deb

So now I confirm it works with "libdbus-1-3 (>= 1.6.18)" so could Opera devs learn how to package things as I mentionned before?

Hope this helps.

Sorry, my bad, you sounded like an opera dev :o)
My apologies

If opera breaks the whole distro on 18.04, it looks a lot to me like opera would add a library which replaces the distro library... and this would never happen if opera was a single and unique .deb package statically build (and bringing no other dependencies). One more reason why opera devs should strongly consider static builds

Again, to not get mistaken, I'm strongly against static builds for distro packages, but definitely "for" static builds concerning 3rd party proprietary packages.

Kind Regards

For my job needs I need to run virtual machines already (devstack : I run a mega huge virtual machine which itself will run multiple virtual machines) and concerning these virtual machines which I need (for my job needs), My job requires me to create and destroy them all the time. So I can't develop on VMs which I need to destroy.
So I need my machine itself for the development and the "builds".
I can't run another virtual machine just to develop while the other "cluster-like VM" is also running because I only have a 16Gb of RAM on may core i7 laptop (and devstack does not work with less than 8B of ram, it is in my case assigned 12Gb to 14Gb of ram since it will itself host multiple VMs. I need it since I develop on this: https://www.openstack.org/). And also my SSD drive will be saturated. I need to develop "while" I have this huge virtual cluster running. And aside from this I also have bigger clusters in data centers, but need to be able to work remotely even when I have no network available. reason why I need my devstack for tests before pushing modifications to the datacenters for wider tests.

I'm turning back the question now: Have you never considered Appimage for Opera builds? : https://appimage.org/ ?

And I'm sorry, but making a static build is easy so easy... that telling your users to use VMs because you do not know how to do static builds... well.. is kinda what it sounds like...

I agree that a rolling release distro is by far the best and if it was up to my personal choice I would install an LMDE (Linux Mint Debian Edition). I was even running Gentoo at a time, BUT, for "job" reasons, I need a distro based on our production servers versions to make sure that what I develop will run on them. And that's because I do server backend development. So a lot of us do not have the "choice..." But with the technique I explained above we where able to develop deb packages built on 14.04 LTS which could install and run on 12.04 LTS before it was EOS (because theyr where "static" builds). So it's possible.

Thanks @jimunderscorep for your reply

Statics builds can be proposed as rpm and deb packages too. Some devs C(++) in my team already did this plenty of times, so it's just totally possible, and it covers even more distros by doing so, meaning more users and revenues for your company (deb and rpm are just packaging methods, and do not imply that you need to do dynamic linked builds. dynamic linked builds are just distribution "politics", and very useful for "open source" packages, but non static builds for proprietary software is mainly the exact case of a wrong way to go).

Concerning your proprietary app, if you make a "static" build on a distro having the library (some change in the Makefile to make static builds), and since it's statically built you can remove some "Depends" from the "control" file in the deb source ("Depends" does not need all that is used for "Build-Depends"), than it could probably install as a deb package and work on your older distro (the deb package would just have some extra Megabites in size because of the static built-in libraries). For rpms, you have an src rpm and an rpm, you need a distro with the dependencies of the src rpm to build, but need less dependencies for the built rpm.

So to sum it up, it is totally possible to provide deb and rpm packages with static builds. Meaning you do not need to change an inch the distributing method. With C(++) apps It's no more than compiler options to pass during compile time. No more than that. Just a tiny little ting to change in the Makefile used to compile, and dependencies to remove in the "control" file of the deb package source (some "Depends" to remove).
All that is required is to build the package on a distro providing all the "Build-Depends", but then it installs on all distros having the "Depends" matching, and the less "Depends" you have in the "control" file, the more distro's it installs on.

Most of what is compiled statically can be removed from the "Depends" section.
Some packages well crafted can then run on a distro which can't compile it
NOTE: it's the wrong way to go for "open source", (and against debian politics for distribution packages) but this is not the case of Opera. It's that the distribution packagers' job to do backports and etc... if they want to provide a dynamic linked package. It's not the proprietary vendor's job, unless you want to open opera's source code and put it on github (You would be loved for this )

Currently you are using an open source package building strategy for a closed source app, this implies less distribution compatibilities.

The only thing that can be blocking is that some "extremely badly coded frameworks" may (I don't know your development framework) not allow this. If your framework allows this (if it's decently and intelligently coded), development would even be easier for your team because you would not need to do backports depending on distro libraries, and could even use more recent libraries without conflicting with the distro's own libraries, and the build would still be packaged in deb or rpm whatsoever, this would not change the way end users install.

I've already seen some deb packages with a Build-Depends library not provided by the distro, but statically built in the package, working properly.
I've even seen some proprietary rpms when I was working in Mandriva (Mandrake Linux) which where build on proprietary libraries we did not even provide or have at all. The libraries where simply statically linked by the vendor during the rpm build (so we where not even able to build the rpm ourselves). And believe me : it worked.

So I don't understand why you have a full open-source approach in package building for a closed source app unless you intend to surprise us and make your code open source in a while

I'm just trying to help propose that you have more users (and if your revenues depend on your users, well, you know what it implies).

Kindest regards.

Thanks a lot @jimunderscorep

If opera wants to cover older distro support, could a solution be to do static links of some libraries (i.e. of libdbus-1-3 in this case, with it's dependencies)?

I know this is not a thing to do for distribution packages, but for large diffusion of "proprietary" apps, it is usually better.
Modern computers have large enough disks to support a larger package.
Ideally, two builds : a statically linked and dynamically linked package should be proposed. And this is not a lot of hassle for developers to propose this because there are no backports required.
A lot of proprietary vendors propose full statically linked dependencies and therefore install almost everywhere.
However, I don't know if a static link of libdbus-1-3(>=1.9.14) would work with dbus from trusty, but it could be worth the test.
I can be wrong because I don't develop in C or C++ or whatever language opera uses...

e.g. I develop on openstack in python and at a time, when precise was not EOL but not supported by openstack, we where packaging new openstack versions with dhvenv (packaging a python venv and all python dependencies without clashing with the distro's older versions) so that we could slowly but surely migrate to trusty afterwards.
I now run pike versions of openstack horizon on Trusty servers without conflicts with the distribution's libraries thanks to python venvs (but now with kubernetes instead of dhvenv packages, but still have no clashes with the rest of the distribution's dependencies thanks to python venvs which "could" be regarded (in a ways) as equivalent to statically linked C(++) libraries).
Therefore I have no issues and no clashes with the distribution's own libraries. And no need for backports to match the distro's libraries (I only backport security fixes and certain features from trunk before they get released and with even more ease now because I do not even have to care an inch about the running distro's antediluvian packages anymore).
Go language can also build with every dependency statically linked. So why could opera not propose such "special" builds and one could chose the static vs dynamic linked package? Does opera's programming language not allow to do this? I know it's possible in C and C++ but again do not know what opera uses... Maybe your programming language and/or framework does not allow to do so?
Doing so would even ease your own development by caring less of the distro's "libraries", and requiring less backports. The downside is larger packages, but with nowadays' disks it's peanuts to care about this.

I can test a statically linked package on trusty if you provide me one on your ftp, and give you feedback whether it works or not. It's maybe worth the test.

Regards