Mac Book Pro Intel - Os 10.6.8 I had the 3.3.2 version, in French, without any problem. I wanted to upgrade, then... Installation of LibreOffice 3.4.4 => no problem Installation of french langage pack => impossible. The first window opens => OK for installation Then nothing happens, and the LoO is always in English. I made the same operation, at the same time, on the MacBook of my wife, no problem. Everything runs well. I don't understand ;-) I try to stop the Mac, then restart => idem Thanks !
Thanks for bugreport Please, verify if in last version of LibreOffice still reproducible Try also move LibreOffice profile in another place
Set Status to NEEDINFO, according to comment #1 (still waiting for response ...)
Dear bug reporter, I am sorry but we have to close this bug report, because we did not get the necessary information asked for in comment #1 for more than four months. Feel free to re-open this bug report if you can provide the information requested in comment #1. Also feel free to ask if anything, e.g. the suggestions in comment #1, is not clear to you. Thank you!
Hi Roman, I am re-opening this bug because I've now had two independent reports, one from a French user, and one from a German user, on Mac OSX, where they have been unable to install the language pack, in circumstances which are the same, or extremely similar to those described here. 1) User downloads a recent version of LO for Mac. 2) User downloads a langpack. 3) User installs LO 4) User then attempts to install langpack - the installation freezes or does not complete and the langpack is not installed. The reports I have had have been from users on Mac OSX 10.7 or higher (Lion or Moutain Lion). Both reports state that double-clicking on the .app file does nothing, or appears to do nothing and no error messages are returned. The app file launches an AppleScript, which uses the mdfind utility to look for an existing installation of LO. The problem might lie in the applescript. Apparently, no error messages are seen if the app is launched from the Terminal. I will have a look at the latest langpacks and see whether something might be going wrong with the script (deprecated calls or something like that ??). Note that I haven't as yet been able to reproduce the problem on Mac OSX 10.8. Alex
In a previous discussion with cloph about a similar problem, he mentioned that the permissions need to be set correctly on the system for the script installer to work properly. It may well be that the users having problems do not have the correct permissions set on their systems, due to other software installations, or tinkering. These permissions can be reset using the disk utility in the Applications/Utilities folder. As for Lion and Mountain Lion, it may well be that the new permissions system managed by the security settings is preventing the installation from completing... Alex
The problem with this bug is that we need more information, that the users have been unable to give us. It has affected at least 3 different people, which is why I'm reopening and setting to new.
(In reply to comment #0) Paul, Have you tried resetting your default permissions on your system and then re-installing the langpack ? Alex
I'm going to have to set NEEDINFO while trying to gather more information as to the exact circumstances surrounding this bug. Alex
(In reply to comment #4) > Hi Roman, > > I am re-opening this bug because I've now had two independent reports, > one from a French user, and one from a German user, on Mac OSX, where they > have been unable to install the language pack, in circumstances which are > the same, or extremely similar to those described here. Hi Alex, a good idea -- yes, after reading your comments I am convinced that this is a serious issue. However -- (In reply to comment #6) > The problem with this bug is that we need more information, that the users have > been unable to give us. That’s it. I also agree that this is a critical problem, and needs more attention. So thank you for your research -- please continue the good work! If I can help something, let me know, however at the moment I am not sure what I can do (I have never seen the problem myself).
I have encountered an issue that appears to be identical to what is reported here. I am using Mountain Lion (10.8.2) When attempting to install the GB language pack for LibreOffice 3.6.2 the installer appears to stall. After digging around in the application package for the language pack installer, I noticed that everything is essentially run from an AppleScript. I opened the AppleScript with the AppleScript Editor and ran it so that it would show me the events and replies. When I did this, I could tell that the script seems to be stuck on the following line: tell current application do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice*' && kMDItemDisplayName != 'LibreOffice Language Pack.app'\"" With my limited understanding of AppleScript, this line is telling the installer to use the shell to trigger the mdfind command, and use it to search for LibreOffice.app, but ignore LibreOffice Language Pack.app That process appears to never complete. I tested with Spotlight, and I was able to find the LibreOffice application successfully. As the AppleScript is waiting for an external shell script to return the location of LibreOffice.app, it remains unresponsive. Hope this information is useful.
As an addition to my above comment: I tested the shell command that is used in the AppleScript, and it returned the following error: Failed to create query for '"kMDItemContentType == com.apple.application-bundle' It seems that com.apple.application-bundle is not a recognised item content type. Hope this helps.
(In reply to comment #10) Hi, > tell current application > do shell script "mdfind \"kMDItemContentType == > 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice*' && > kMDItemDisplayName != 'LibreOffice Language Pack.app'\"" > > Can you just try launching the mdfind utility from a Terminal and see whether it allows you to do that as a normal user ? Alex
Hi Alex, If you check comment 11, that was the error I got from running that particular shell command. Hope this helps.
(In reply to comment #13) > Hi Alex, > > If you check comment 11, that was the error I got from running that > particular shell command. > > Hope this helps. Oh, sorry, I thought you'd started it from within the Applescript runtime environment editor. Did you try a systems permissions reset like I mentioned in Comment #5 ? Alex
Perhaps running the mdls utility on the langpack.app file might help retrieve the correct values so that the script could be corrected - always assuming that these values are indeed wrong of course. I'm not in front of my Mac at the moment. Alex
Hi Alex, I'll run a permissions repair and try again. Hang on.
Hi again Alex, That didn't make any difference. It's almost like the mdfind command is working differently now.
(In reply to comment #17) > > That didn't make any difference. > > It's almost like the mdfind command is working differently now. Ah, will have to have a closer look then, but not much free time at the moment. Alex
*** Bug 53636 has been marked as a duplicate of this bug. ***
(All questions have been answered, therefore I reset the status to UNCONFIRMED; this is better than NEEDINFO: it prevents the bug report from being closed because questions where not answered ;-) @ Alex: (In reply to comment #18) > Ah, will have to have a closer look then, but not much free time > at the moment. Any new ideas about this issue in between? ;-)
(In reply to comment #20) > @ Alex: > (In reply to comment #18) > > Ah, will have to have a closer look then, but not much free time > > at the moment. > Any new ideas about this issue in between? ;-) I wonder whether this has not been fixed in the meantime with LO4, as a analogous report with regard to the Estonian language pack appears to have been resolved. I don't have (or never had) any of these problems with any of my recent versions of LO. Alex
@Erik : can you test this again with the latest LO4 and corresponding language pack ? Alex
If I run : mdfind \kMDItemContentType == 'com.apple.application-bundle' && mdfind \kMDItemDisplayName == 'LibreOffice*' from the Terminal as a normal user, then I get a whole list of elements containing the string "LibreOffice", however, these are not limited to merely a list of *.app bundles. Alex
Hm I'm tempted to put this back in NEEDINFO until we get one of the people who have seen the bug to confirm that it still exists with 4.0+. Any thoughts Roman or Alex? If not, I'm hoping to push it to NEW soon - this bug was originally reported a 18 months ago, much too long to still be in UNCONFIRMED status. Adding Joren as he is another OSX tester.
Hi Joel, The only thing I have noticed, and this was completely by chance, is that on 10.8.x, the Language Pack installation fails if it can't find an app exactly named "LibreOffice". In view of the mdfind command, this is to be expected. However, the script also then fails to pick up any other existing version of LO, including the LibreOfficeDev. This was not the case in previous combinations of LO/mdfind, so it may well be that the problem lies in that specific combination (which is going to be harder to nail down). The reason that this came about on my system is that I rename various versions of the LO apps (and their corresponding user profiles) to attempt to avoid overwriting their configuration files when installing. If I have some time before the end of the week, I will look into this further with some of the langpacks. Note that on my OSX 10.8.3 system, I have installation admin rights, and have activated the Apple preferences setting of allowing untrusted/unsigned apps to be installed. Alex
With every new minor version of LibreOffice I install a Dutch Language pack using Mac OSX 10.8.3. I have multiple installs of LibreOffice on my computer. I can't reproduce this behavior, because every time a dialog appears that ask which version of LibreOffice I will install the language pack. So, can't reproduce this.
I think we should close this. There is AFAIK another bug report open about the impossibility of installing langpacks on OSX > 10.7 because although the main app bundle is now codesigned, the langpacks are not, and thus fail to install when Gatekeeper is activated. Not much we can do about that, unless the decision is taken to sign the langpacks as well, but I don't even know whether this is possible (some kind of limitation with the OSX hdutils tool and codesigning for Applescript apps which don't contain a true executable binary ??) http://lists.apple.com/archives/applescript-users/2012/Aug/msg00074.html Alex
Also this link, which provides a script utility to help codesign AppleScript bundles, but note that the AppleScript editor requires a plist bundleIdentifier, and this is only available in the OSX 10.8 AppleScript editor. I'm not sure our current OSX build machines are running OSX 10.8, but to be honest, I don't know. Alex
(In reply to comment #28) > Also this link, which provides a script utility to help codesign AppleScript > bundles, but note that the AppleScript editor requires a plist > bundleIdentifier, and this is only available in the OSX 10.8 AppleScript > editor. > > I'm not sure our current OSX build machines are running OSX 10.8, but to be > honest, I don't know. > > > Alex Ooops, forgot the link : http://www.macosxautomation.com/applescript/apps/readmyscripts.html
I installed LO on many machines lately with language packs on OS X. NO issues at all. WORKSFORME as of Comment 26/27. If this should re-appear unexpectedly for any of you using the latest LO release 4.0.4.2 please re-open this bug. Thanks :)