Bug 100284 - Cannot install 5.2.0 in Ubuntu 16.04
Summary: Cannot install 5.2.0 in Ubuntu 16.04
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
5.2.0.0.beta2
Hardware: x86-64 (AMD64) Linux (All)
: medium normal
Assignee: Markus Mohrhard
URL:
Whiteboard:
Keywords:
: 100305 100437 100466 (view as bug list)
Depends on:
Blocks:
 
Reported: 2016-06-09 04:21 UTC by Dan Dascalescu
Modified: 2016-06-23 23:38 UTC (History)
5 users (show)

See Also:
Crash report or crash signature:


Attachments

Note You need to log in before you can comment on or make changes to this bug.
Description Dan Dascalescu 2016-06-09 04:21:41 UTC
The Graphical Installation instructions at https://wiki.documentfoundation.org/Documentation/Install/Linux#Graphic_Installation_.28Preferred_Way.29 no longer work as of Ubuntu 16.04.

Selecting all .deb files and opening them in Software Center doesn't do anything but opening the packages repeatedly in USC, with only the last one visible. Worse, clicking "Install" fails - see https://bugs.launchpad.net/ubuntu/+source/gnome-software/+bug/1590640

`sudo dpkg -i *.deb` doesn't work either, because dpkg doesn't install dependencies, so that part of the installation instructions is wrong too.

As instructed at http://askubuntu.com/questions/40011/how-to-let-dpkg-i-install-dependencies-for-me/, I ran `sudo apt-get install -f` and `sudo dpkg -i *.deb`, and that did install dependencies, but running any of the shortcuts fails silently.

From the command line, I get this:

$ libreofficedev5.2 --calc
/opt/libreofficedev5.2/program/soffice.bin: error while loading shared libraries: libmergedlo.so: cannot open shared object file: No such file or directory

I've installed gdebi-core, then ran `gdebi *.deb`. That failed with `Dependency is not satisfiable: lodevbasis5.2-core (>= 5.2.0.0.beta1)`.

Can the .deb TGZ have an install script, like the .rpm version?

The problem has also been reported at https://ask.libreoffice.org/en/question/71044/lo-52-beta-wont-install-on-linux-x64/
Comment 1 Paul 2016-06-09 12:53:46 UTC
I'm on Linux Lite 3.0 x64, a ubuntu 16.04 derivative, so I can't confirm the graphical installer part, but the apt-get terminal commands do indeed fail to install dependencies.

On the first try, I got LO 5.2 listings in the Whisker Menu, but they didn't launch. I uninstalled. 

On the second try, no menu listings. I tried the sudo apt-get -f install command to supply dependencies. It added nothing, and actually removed some that seemed unrelated, but about which I wonder.
Comment 2 MM 2016-06-09 20:58:10 UTC
I confirm on ubuntu 16.04 x64.
Installing with 'sudo dpkg -i *.deb' doesn't install all files, so it can't be run. That's why I went back to the alpha build again.

Think that the header for this report is a bit odd though, should be something like: 'Can't install 5.2.0.0 beta under ubuntu 16.04' or so, as there might be nothing wrong with the installation instructions itself.
Comment 3 Adolfo Jayme Barrientos 2016-06-09 21:33:48 UTC
Done
Comment 4 Christian Lohmaier 2016-06-09 22:03:35 UTC
you need to actually read the output of the "dpkg -i *.deb" command.

it is not about any dependencies, it is a bug that a file is included in two packages, and debian doesn't allow that, even if it is the very same file. To workaround, use --force-overwrite switch.
Comment 5 Paul 2016-06-09 22:30:10 UTC
That did indeed get 5.2 installed. Thanks.
Comment 6 Dan Dascalescu 2016-06-10 00:39:53 UTC
`sudo dpkg -i --force-overwrite *.deb` did the trick - thanks!

Should I update the wiki?
Comment 7 MM 2016-06-10 11:40:50 UTC
(In reply to Dan Dascalescu from comment #6)
> `sudo dpkg -i --force-overwrite *.deb` did the trick - thanks!
> 
> Should I update the wiki?

Well, is this trick for this release only or also for future releases ?! It worked without --force-overwrite on previous packages, so something has changed.....
Comment 8 Christian Lohmaier 2016-06-10 15:22:08 UTC
no, no need to update installation instructions. It is a packaging bug that will be solved for RC / final versions.

it's listed in the beta's releasenotes, that should be enough.

https://wiki.documentfoundation.org/Releases/5.2.0/Beta2#Linux
Comment 9 Christian Lohmaier 2016-06-10 20:09:04 UTC
*** Bug 100305 has been marked as a duplicate of this bug. ***
Comment 10 Christian Lohmaier 2016-06-11 21:37:06 UTC
the problem is the duplicated definition of minidump_upload executable.

It is one time from breakpad external module:

external/breakpad/ExternalPackage_breakpad.mk:$(eval $(call gb_ExternalPackage_add_file,breakpad,$(LIBO_LIB_FOLDER)/minidump_upload,src/tools/linux/symupload/minidump_upload))

→ thus ends up in breakpad.filelist, and that then ends up in gid_Module_Root (lobasis-core package)

the other instance is form desktop module, it is added to brand layer (libreoffice package) (and overwrites the one defined in the breakpad rule, what ends up in instdir/program is the desktop-dir's version):

Repository.mk $(eval $(call gb_Helper_register_executables_for_install,OOO,brand, \
       $(call gb_Helper_optional,BREAKPAD,minidump_upload) \
       …
 
→ so possible/suggested fix: 
  * remove the lines from ExternalPackage_breakpad.mk
  * change entry in Repository.mk to use 
    $(eval $(call gb_Helper_register_executables_for_install,OOO,ooo, …)
    instead (ooo layer vs brand, to have it end up in the core package, just like the crashreportdlg.ui)

##### 
However I don't know whether it is intentional to mask the mindump_upload from breakpad module (that even is patched)... - if so, the corresponding patch should also be removed..
Comment 12 Adolfo Jayme Barrientos 2016-06-17 08:06:41 UTC
*** Bug 100437 has been marked as a duplicate of this bug. ***
Comment 13 Adolfo Jayme Barrientos 2016-06-18 13:51:40 UTC
*** Bug 100466 has been marked as a duplicate of this bug. ***
Comment 14 tim 2016-06-23 15:41:26 UTC
Tested in Version: 5.2.0.1 Build ID: fcbcb4963bda8633ba72bd2108ca1e802aad557d
CPU Threads: 8; OS Version: Linux 4.4; UI Render: default; 
Locale: en-GB (en_GB.UTF-8)

All OK for me.  Thanks.
Comment 15 Adolfo Jayme Barrientos 2016-06-23 23:38:34 UTC
Thanks for verifying!