I am using Kubuntu 12.04. currently version 4.04 from the Document Foundation, not the distributions version. Tried to install version 4.1 from Dokument Foundation. 1. In readmes mentioned folder desktop-integration does not exist. 2. Menue-entries are made during installation, but do not work. If klicked nothing happens. But you can start via /opt/libreoffice4.1/program/swriter etc. Menue-entries are ok, e. g.: Libreoffice4.1 --writer %U
Hello Ulrich, *, (In reply to comment #0) > I am using Kubuntu 12.04. currently version 4.04 from the Document > Foundation, not the distributions version. Tried to install version 4.1 from > Dokument Foundation. > > 1. In readmes mentioned folder desktop-integration does not exist. > > 2. Menue-entries are made during installation, but do not work. If klicked > nothing happens. But you can start via /opt/libreoffice4.1/program/swriter > etc. > Menue-entries are ok, e. g.: Libreoffice4.1 --writer %U I have reported part 2 at http://permalink.gmane.org/gmane.comp.documentfoundation.libreoffice.qa/4838 on 25/07/ ... :( But I can also confirm part 1, but there I have only searched readmes/README_de ... :( I am using Debian Testing AMD64 and LO Version: 4.1.0.4 Build ID: 89ea49ddacd9aa532507cbf852f2bb22b1ace28 with Germanophone help- as well as langpack. I will switch platform to "All - Linux (All)" and change status to "New". HTH Thomas.
In LO 4.0.4 user: root and group: root, in LO 4.1 user: 500, group:500. Perhaps this is the problem?
Solved. I have again installed LO 4.1 and changed folder /opt/libreoffice4.1 completely (that means incl. all folders/files within this folder) to user=root, group=root. Now KDE-menu works.
The "desktop-integration" directory has been removed in LO-4.1. It was there from historical reasons: 1. There was different desktop integration for different RPM-based Linux distributions. They were not longer needed because Linux distros switched to the "Freedesktop" standard 2. The desktop integration packages for different Lo version conflicted. This was solved by versioning the package names, filenames, menu entries. So, you could install the desktop integration for LO 4.1 in parallel with the desktop integration for LO 4.0 Unfortunately, we forgot to update the installation instructions in the README file. It will be fixed in the 1st bugfix release, 4.1.1, see the bug #67061 So, the first part is solved. I am going to look at the 2nd part of the problem (access rights).
I could confirm that the files in LO 4.1 .deb packages are owned by some strange user and group. The files and directories should be owned by root:root as it is done in 4.0 and earlier releases. This affect both the "debian-menus" packages generated in sysui and also the other packages generated instsettoo_native. In fact, also the .deb and .rpm files itself has the strange user and owner. So, even the download tarballs are generated a strange way. It seems that the tarball tries to preserve the original owner which looks a bit ugly to me. I guess that this is related to the gbuildification or to some clean up. I have already spent some time investigating the root of the problem but without success. I wonder if this trigger any bell.
It seems that there was a hack using getuid.so. This is what I see in core/sysui/desktop/debian/makefile.mk in 4.0 sources: --- cut --- # getuid.so fakes the user/group for us $(DEBFILES) : $(COMMONMISC)$/{$(PRODUCTLIST)}$/build.flag [...] /bin/bash -c "LD_PRELOAD=$(SOLARBINDIR)/getuid.so dpkg-deb --build $(MISC)/$(@:b) $@" --- cut --- I do not see any similar thing in the gbuilded-4.1 sources.
I was blind. There is used the getuid in core/sysui/CustomTarget_deb.mk in 4.1: --- cut --- LD_PRELOAD=$(call gb_Library_get_target,getuid) \ dpkg-deb --build $(deb_WORKDIR)/$* $@ --- cut --- It is even loaded but it does not work. It helped me to replace the libgetuid.so with the binary generated using 4.0 sources. I am going to did more into it. PS: I am sorry for the spam. I have to leave for vacation within next tow hours. So, I want to leave as many notes as possible for the case that I do not find the solution.
Petr Mladek committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dcb386d787e5d3dbcd67a029569dd9b1cfba9274 let's own the packaged stuff by root:root again (fdo#67388) The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have succeeded in the end. There were two problems. The symbols in libgetuid.so were not visible, so the LD_PRELOAD did nothing in practice. In addition, the installer still searched for the old name "getuid.so" when doing the download tarballs. I have fixed it in master and also nominated for 4.1.1, see https://gerrit.libreoffice.org/#/c/5251/ It looks fine now.
Petr Mladek committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1a97f10084629df98606746da6401fdff3996914&h=libreoffice-4-1 let's own the packaged stuff by root:root again (fdo#67388) It will be available in LibreOffice 4.1.1. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 66113 has been marked as a duplicate of this bug. ***
*** Bug 67441 has been marked as a duplicate of this bug. ***
RESOLVED_FIXED? Of course it isn't fixed. It will be fixed in 4.1.1. That means that anyone trying to install the current download is likely to end up with an unusable LO. What use is that? Yes, an experienced user can get an installation running with chown -R root:root /opt/libreoffice4.1 OK, I've been doing things like that for the last 30 years but is it reasonable to expect that of someone who might be a Ubuntu newbie? The bug won't be RESOLVED_FIXED until the *current* installer is replaced by one that works.
(In reply to comment #13) > RESOLVED_FIXED? > > Of course it isn't fixed. Of course it is. The resolution means (from bugzilla help): "A fix for this bug is checked into the tree and tested." > Yes, an experienced user can get an installation running with chown -R > root:root /opt/libreoffice4.1 OK, I've been doing things like that for the > last 30 years but is it reasonable to expect that of someone who might be a > Ubuntu newbie? There is 4.1 available in Ubuntu PPA (or whatever it is called). I imagine that one is easier to find/install (but I might be mistaken, of course...) > > The bug won't be RESOLVED_FIXED until the *current* installer is replaced by > one that works. Wrong. You just do not understand the bugzilla workflow.
This bug came back with the latest betas. Checked the debs for beta1 & beta2. LO dir owned by user: 500, group:500. I'm reopening this bug since the Whiteboard has 'target:4.2.0' which is not the case.
I am sorry. I do not longer work on LibreOffice => removing myself from assignee. For those who would work on this bug. The previous fix solved a regression related to libgetuid.so. I did a quick look on how the code has changed after the last fix. I wonder if the regression might be caused by the solver-related clean up, see http://cgit.freedesktop.org/libreoffice/core/diff/solenv/bin/modules/installer/download.pm?id=5d8f48c81eac8650315b936d0e89ad1d54b566fc I am sorry, I can't debug it myself. I do not have a build around and time to do it.
Well, I don't know how to reproduce this. But if it is related to libgetuid.so, maybe http://cgit.freedesktop.org/libreoffice/core/commit/?id=203e84d434de904add0b4426e87a4eb0a9a50c66 helps?
(In reply to comment #17) > Well, I don't know how to reproduce this. > But if it is related to libgetuid.so, maybe > http://cgit.freedesktop.org/libreoffice/core/commit/ > ?id=203e84d434de904add0b4426e87a4eb0a9a50c66 helps? Indeed. latest builds owned by root again. thanks.
Matuš Kukan committed a patch related to this issue. It has been pushed to "libreoffice-4-2": http://cgit.freedesktop.org/libreoffice/core/commit/?id=1df62be82dc2b79521f4572f606dad778fe5684c&h=libreoffice-4-2 fdo#67388: installer: Fix path to libgetuid.so again. Hardcode it. It will be available in LibreOffice 4.2. The patch should be included in the daily builds available at http://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: http://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.