The finder says in french : "LibreOffice" est endommagé et ne peut pas être ouvert. Vous devriez placer cet élément dans la Corbeille. I made a new installation, but the bug is the same. So I tried OpenOffice and it works. Before the update of OSX 10.8.3 all worked fine in OSX 10.8.2
Hi YL, First and for all ... please do NOT mark your own bug as NEW, but leave it unconfirmed until someone else can confirm it. Also marking it as Blocker right away is a bit to fast in this case. Ontopic: can you please reset your user profile by following this guide: https://wiki.documentfoundation.org/UserProfile#Resetting_the_user_profile and see if the problem still appears. Kind regards, Joren
PS: I can not reproduce this behavior using Mac OSX 10.8.2 and 10.8.3 now. I update my OS 3 minutes ago, opening LibreOffice 4.0.2.1 works for me. Kind regards, Joren
(In reply to comment #0) > The finder says in french : > > "LibreOffice" est endommagé et ne peut pas être ouvert. Vous devriez placer > cet élément dans la Corbeille. > > I made a new installation, but the bug is the same. > > So I tried OpenOffice and it works. > > Before the update of OSX 10.8.3 all worked fine in OSX 10.8.2 Hello Joren, Sorry, it's the first time I use bugzilla to report bug. So I could make mistakes. I reset my profile but the bug is always the same : I can't launch libreoffice 4 I try to run libreoffice directly by clicking soffice but it does not work either. So I try to run libreoffice clicking scalc but this does not work too, however it begins to start and gives me access to a problem report that I put as an attachment. What can I do now to help ? Sincerely yours Yann
Created attachment 76685 [details] bug report for libreoffice for bug 62442
(In reply to comment #2) > PS: I can not reproduce this behavior using Mac OSX 10.8.2 and 10.8.3 now. I > update my OS 3 minutes ago, opening LibreOffice 4.0.2.1 works for me. > > Kind regards, > Joren Hi Joren, I retried several times to run libreoffice from the regular program, and I still have the same problem. However, now when I try to run with libreoffice scalc, it works and I have no problem. I have tried several times both approaches and I always get the same result. What would you advise me to do now? Sincerely yours Yann
(In reply to comment #2) > PS: I can not reproduce this behavior using Mac OSX 10.8.2 and 10.8.3 now. I > update my OS 3 minutes ago, opening LibreOffice 4.0.2.1 works for me. > > Kind regards, > Joren I have another bug report. I try to open a file and the app stops. Sincerely yours. Yann
Created attachment 76689 [details] Another bug with bug 62442
(In reply to comment #3) > Sorry, it's the first time I use bugzilla to report bug. So I could make > mistakes. No worries. Thanks for your time filing this in. Tip: please do not reply to the email you get, bug browse to https://bugs.freedesktop.org/show_bug.cgi?id=62442 instead and comment there. > I reset my profile but the bug is always the same : I can't launch > libreoffice 4 > > I try to run libreoffice directly by clicking soffice but it does not work > either. Very strange. I can not say anything useful when I see the crash logs. I'll try to search some workaround/things you can try. (In reply to comment #6) > I have another bug report. I try to open a file and the app stops. Please create another bug report for that one (with the file in attachment). Kind regards, Joren
YL: considering the bug reports, do you have Python installed? If yes, what's the precise version? Also, could you give a try to last 4.0.2? (as Jorendc has)
(In reply to comment #9) ..> Also, could you give a try to last 4.0.2? (as Jorendc has) Sorry, forget this part, we're in 4.0.1.2
(In reply to comment #10) > (In reply to comment #9) > ..> Also, could you give a try to last 4.0.2? (as Jorendc has) > Sorry, forget this part, we're in 4.0.1.2 Hello Julien, When I launch python, I have : Python 2.7.2 (default, Oct 11 2012, 20:14:37) [GCC 4.2.1 Compatible Apple Clang 4.0 (tags/Apple/clang-418.0.60)] on darwin Is it a problem ? Yann
(In reply to comment #10) > (In reply to comment #9) > ..> Also, could you give a try to last 4.0.2? (as Jorendc has) > Sorry, forget this part, we're in 4.0.1.2 I install python 3.3.0 but the program python links with python 2.7.2. So when I launch LibreOffice the problem is the same. Must I do something else ? I don't know really how to link python to 3.3.0... Sincerely yours. Yann
YL: Would the update break something (but why for you and not for Jorendc)? Did you install any specific fonts and/or specific LO extensions? Anyway, I would try the "dumb" solution to uninstall and reinstall just to see if it could be better.
hello, I have the same problem whith LibO 4.0.2.2 and MacOS X 10.8.3 After the installation of LibreOffice_40.2_MacOS_x86_langpack_fr.dmg, the same message of fider "LibreOffice" est endommagé et ne peut pas être ouvert. Vous devriez placer cet élément dans la Corbeille. No problem with MacPPC or Windows 7 or 8 But without installing langpack_fr, only whith LibreOffice_40.2_MacOS_x86.dmg 159 MB, no message. I can open LibO in US. I see in Extension Manager : English spelling dictionaries, hyphenation rules, thesa... 2011.12.05.1 Error: The status of this extension is unknown ! If I want to add the extension lo-oo-ressources-linguistiques-fr-v4-10.oxt i have this message : (com.sun.star.lang.Disposed Exception){{{Message= "Binary URP bridge disposed during call", Content = (com.sun.star.uno.XInterface) @1c2a6020}}} Note : Hash is OK, (6 download for tests) install without or not 3.6.5 installed with or not "profile", plists or script.savedState. "Repair of the authorization" and "3 scripts" makes 5 times... before and after desinstallaion of LibO 4.2.0 I reinstalled 3.6.5 : all is OK !
Created attachment 77546 [details] 4.0.2.2 US on MacOsX 10.8.3 English dictionaries unknown
Created attachment 77547 [details] ERROR Extension Manager Add French Dictionnary V-0.4.10
papayes: thank you for your feedback. I put the tracker at New since it's confirmed. Roman/Alex: would you have some time to take a look to this MacOs bug? The goal is to know if it's specific to 10.8 or not.
(In reply to comment #17) > > Roman/Alex: would you have some time to take a look to this MacOs bug? The > goal is to know if it's specific to 10.8 or not. Hi Julien, Which buggy behaviour? There seem to be several mixed up in one report here. Alex
Alex: would you have 10.8.3 by any chance? If yes, does LO 4.0.2 open normally? If ok, do you have langpack_fr installed? Perhaps the bug is the same and is triggered by langpack_fr since both have French version.
Hello, 2 informations: 1. I had installed on March 23rd, the version 4.0.1 without any problem, on Mac OSX 10.8.3 The English dictionary being recognized as the French versions in 4.9. (lo-oo-ressources-linguistiques-fr-v4-9.oxt) 2. On Mac OsX 10.6.8, and LibO 4.0.2.2 No error message. But the installation not recognized English dictionary extension... Attempt of installation of lo-oo-ressources-linguistiques-fr-v4-10.oxt Error : (com.sun.star.lang.DisposedExection) {{{Message="Binary URP bridge disposed during call", Context= (com.sun.uno.Xinterface)@1f8bc708}}} Finally, after lock and reopening of the application, the extension is not recognized
(In reply to comment #13) > YL: Would the update break something (but why for you and not for Jorendc)? > Did you install any specific fonts and/or specific LO extensions? > > Anyway, I would try the "dumb" solution to uninstall and reinstall just to > see if it could be better. Hello, I installed the new version 4.0.2 and now everything works perfectly. With the french translation... Thanks Sincerely yours. Yann
Created attachment 77555 [details] English2011.12.05.1 & french V4-10 dictionaries unknown MacOs10.6.8
Hello, The bug on the English dictionaries by default and French v4-10 is real whith LibreOffice_4.0.2_MacOS_x86.dmg, on MacOsX 3.8.3 and 10.6.8. I found the bypassing to install LibO 4.0.2 + FR on MacOsX 3.8.3 1. Verify that there is not a track anymore of LibO in particular images-disks which would have been protected: Open the disk utility of Mac and look at the rightbanne. Delete the images-disks residual. 2. Then, work only at the level of the file Application and open the files only with the touch ctrl pushed and click on the Open command as well for the installation of the file of language as the launch of LibO. In fact the simple double click on the file creates the message "damaged" on the place of the message " impossible to launch " of the new Apple protection . Regression with compared with 4.0.1 all the same. The program works except for the indicated bug. Thank you and by hoping for the resolution of the problem of the extensions of languages
Can not reproduce on OSX 10.8.3 with : Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: 2013-03-26_15:52:16 Langpack FR All opens fine for me. Alex
(In reply to comment #24) > Can not reproduce on OSX 10.8.3 with : > > Version 4.0.2.2 (Build ID: 4c82dcdd6efcd48b1d8bba66bfe1989deee49c3) > TinderBox: MacOSX TDF Release, Branch:libreoffice-4-0, Time: > 2013-03-26_15:52:16 > > Langpack FR > > > All opens fine for me. > > > Alex Sur ma bécane, ça marche nickel, que ce soit en écrivant/vérifiant en français ou en anglais... Alex
I put WFM for this tracker since it's ok for original reporter + ok for another user (Alex). Alex: effectivement, je constate que le français marche tellement nickel sur ta bécane que t'en oublies d'écrire en anglais sur le tracker :-p En tout cas merci pour le retour rapide et toujours utile ! :-) (For non English speakers, just a little joke written in French and some thanks of course! :-)) papayes: I propose you to submit a brand new bug since (as Alex had suggested) Before this, try to rename your LO directory profile (see https://wiki.documentfoundation.org/UserProfile) and test again.
I confirm the bug described by papayes on LO 4.0.2 French with Mac OS X 10.8.3 about the dicos extensions : In Extension Manager, i can see : English spelling dictionaries, hyphenation rules, thesa... 2011.12.05.1 Error: The status of this extension is unknown ! If I want to add the extension lo-oo-ressources-linguistiques-fr-v4-10.oxt or Grammalecte-v0.2.7.oxt i have this message : (com.sun.star.lang.Disposed Exception){{{Message= "Binary URP bridge disposed during call", Content = (com.sun.star.uno.XInterface) @1c2a6020}}} I try to use the us version directly, but even there, the english spelling dictionaries shows error No problem with LO 4.0.1, everything fine, we can add dictionaries without any trouble. As we have to install the version 4 in our classrooms for next year and we make these installation in may, i hope that it can be fixed in 4.0.3 Thanks Christian
I can confirm the bug about the application not opening for en-GB. It's not a French problem. If you open LibreOffice after initially dragging the new file to Applications, you get the standard "this is a downloaded file" warning, and can open it. If you then apply a language pack, there is no problem. However, if you apply the language pack *before* opening the application for the first time, you get the "this file is damaged" warning, and have to reset the Gatekeeper preferences to open it the first time. So, at a guess, applying the language pack changes the binary so that the signature doesn't match, producing the "damaged" report (correctly, in fact), but Gatekeeper only checks that the first time you launch a file (which is why the various workarounds work).
(In reply to comment #28) > I can confirm the bug about the application not opening for en-GB. It's not > a French problem. Confirmed for en-GB, including the workaround by launching LO before installing language packs. > So, at a guess, applying the language pack changes the binary so that the > signature doesn't match, producing the "damaged" report (correctly, in > fact), but Gatekeeper only checks that the first time you launch a file > (which is why the various workarounds work). The gatekeeper message will also be triggered when other files in the distribution have changed. Another workaround is to temporarily disable Gatekeeper (System Preferences -> Privacy and Security -> General -> Allow Applications downloaded from anywhere). Cheers Burkhard.
Thorsten: I know very few about MacOs but the 3 last comments seem to confirm something wrong here (and so I put it at New again). Would you have some time to take a look?
So is the consensus that the actual problem is that if the language pack installer is run on a newly downloaded (and copied to the hard disk) LibreOffice.app before it has been run once, the unpacking of the language pack data into the app bundle "destroys" its integrity, and Gatekeeper will refuse to run it? If we continue to distribute langage packs in this fashion, as separate apps that store data into the app bundle, there is not much we can do about this problem.
Is it impossible to write the separate app to launch LO and quit it before writing the data into the bundle? If the problem is what it seems to be, that ought to fix it.
Well, how do you intend to get around the Gatekeeper prompt when running LibreOffice from the language pack installer? Anyway, I am not sure how often the problem here actually can occur. We don't sign the language pack installer apps, so to be able to run the language pack installer, the user has already had to either disable Gatekeeper, or know how to run the language pack installer without Gatekeeper getting into the way. So then he/she can use the same skill to run the language-pack-modified LibreOffice without Gatekeeper getting into the way;) Actually, I find it a bit ugly to modify the app bundle in the language pack installer. I haven't tried to look it up, but my gut feeling is that installed app bundles (like LibreOffice.app) should be treated as read-only and not be scribbled into by the app itself or another app even, as in this case (the language pack installer app, LibreOffice Language Pack.app). I think our language pack data should be put somewhere else, like in a ~/Library/LibreOffice Language Packs folder for instance, and then LibreOffice should simply be changed to look for its language-specific files there instead. Sounds easy to say of course, I don't know how hard it would be to implement...
One can use the codesign command to verify that a signed app bundle is intact. Running it on a LibreOffice.app that has been the target of a language pack installation, one gets: lilla-my:~ $ codesign --verify -v LibreOffice.app LibreOffice.app: a sealed resource is missing or invalid In architecture: i386 resource added: /Users/tml/LibreOffice.app/Contents/Resources/sv.lproj/InfoPlist.strings which indeed makes it clear that installing one or more language packs breaks the code signature of the app bundle. The "Resources" folder is always included when calculating the signature of an app bundle. The language-specific InfoPlist.strings files are quite small and seem contain translations for the names of the ODF document types: lilla-my:~ $ iconv -f UTF-16 -t UTF-8 <LibreOffice.app/Contents/Resources/sv.lproj/InfoPlist.strings "OpenDocument Text" = "OpenDocument text"; "OpenDocument Text Template" = "OpenDocument textmall"; "OpenDocument Master" = "OpenDocument samlingsdokument"; "OpenDocument Formula" = "OpenDocument formel"; "OpenDocument Presentation" = "OpenDocument presentation"; "OpenDocument Presentation Template" = "OpenDocument presentationsmall"; "OpenDocument Drawing" = "OpenDocument teckning"; "OpenDocument Drawing Template" = "OpenDocument teckningsmall"; "OpenDocument Spreadsheet" = "OpenDocument kalkylblad"; "OpenDocument Spreadsheet Template" = "OpenDocument kalkylbladsmall"; "OpenDocument Database" = "OpenDocument databas"; Why these translations have to be in such InfoPlis.strings file, but why translations for other document types need not, I don't know.
One fix for this bug (as the situation is *now*) would be to include *all* InfoPlist.strings files in the LibreOffice.app as distributed, and not have them installed by language pack installers. We should also start codesigning also the Libreoffice Language Pack.app bundles.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "master": http://cgit.freedesktop.org/libreoffice/core/commit/?id=dfc4ace4278d6c9e77ec150f947a1a6ee454d70d fdo#62442: Move the InfoPlist.strings files into the app from langpacks 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 70037 has been marked as a duplicate of this bug. ***
*** Bug 62809 has been marked as a duplicate of this bug. ***
Submitted a cherry-pick of the above commit to the 4-1 branch to gerrit, https://gerrit.libreoffice.org/#/c/6251/ . Sorry, did not test build it.
I agree that my bug was a duplicate of this one, but since my observations have not been mentioned here, I took the liberty to reprint my original bug statement : Problem description: Steps to reproduce: 1. Install 4.1.2.3 2. *Immediately* install the French resources 3. Launch translated 4.1.2.3 Current behaviour: OS pops up a window advising that the app is broken, with choice of cancelling the launch or moving the app to the trash Expected behaviour: Ability to launch translated LibO on first try Workaround: 1. Install 4.1.2.3 2. Launch *UNtranslated* 4.1.2.3 3. Quit LibO 4. Install the French resources 5. Launch translated 4.1.2.3 : it works ! Interpretation: The French translation modifies the file substantially so that the signature provided by The Document Foundation does not fit the file's content. Of course, once the file has been launched the first time Gatekeeper protection doesn't apply, so LibO can be launched even if modified. Solution: The Language installers should also install an updated signature ? -or- The Language installers should first launch LibO, quit it, then try to install the language content -or- Do like on Windows and pre-install all languages without requiring an independent download.
> The Language installers should also install an updated signature ? Not possible (or horribly complex) technically > The Language installers should first launch LibO, quit it, then > try to install the language content Too complicated technically, plus would be confusing to the user. > Do like on Windows and pre-install all languages without > requiring an independent download. I don't think the TDF build of LO for Windows does that. Anyway, not really possible from a "marketing" point of view, each UI language brings in around 15 MB size I think, so the end result would be several times larger to download. Anyway, I don't see the point in discussing infeasible ways to solve the problems when we already know one way to solve it: comment #36.
Tor Lillqvist committed a patch related to this issue. It has been pushed to "libreoffice-4-1": http://cgit.freedesktop.org/libreoffice/core/commit/?id=d43126696d87fb74ac33b0e54987ebfa7186da39&h=libreoffice-4-1 fdo#62442: Move the InfoPlist.strings files into the app from langpacks It will be available in LibreOffice 4.1.4. 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.
Tor's commit seems to have worked for me on LO 4.1.4.2, i.e. I got no error message about a corrupt installation, and my Gatekeeper is on, so I'm inclined to set this to resolved fixed, and verified. Please change as appropriate if others are still experiencing problems with the latest production release
Still happening with LO 5 on OS X 10.10. See also https://bugs.documentfoundation.org//show_bug.cgi?id=89561