Description: Attempting to install the French RC1 langpack with LO7RC1 results in the following error message : /Applications/LibreOffice.app/Ce n'est pas une installation valide de LibreOffice 7.0. Exécutez de nouveau l'installeur et choisissez une version valide de 7.0 LibreOffice The installation of the lang pack fails. In the first displayed window, the choice available of target is limited to a user chosen target, rather than discovering the presence of the default LibreOffice.app bundle. Selecting the user choice option and then picking out the LO bundle from the possible apps leads to the error message above. Steps to Reproduce: See above Actual Results: The lang pack fails to install. Expected Results: The bundle should be detected and the lang pack should be installed normally. Reproducible: Always User Profile Reset: Yes Additional Info: Possible signing issues ?
I can confirm this behaviour with the German languagepack for L07RC1 as well. I'm getting the same error message just in German. I'm running macOS 11 Big Sur Developer Beta 2.
I can't reproduce it in Version: 7.0.0.1 Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd Threads CPU : 8; OS : Mac OS X 10.14.6; UI Render : par défaut; VCL: osx Locale: en-US (en_ES.UTF-8); Langue IHM : fr-FR Calc: threaded Mac Mojave 10.14.6 as you can see, LibreOffice is using the french UI
Alex, which version of Macintosh version are you using ?
Hi Xisco, Catalina 10.15.5
Maybe: https://bugs.documentfoundation.org/show_bug.cgi?id=134595#c5
I confirmed this issue too. When I try to install the 'LibreOffice_7.0.0.1_MacOS_x86-64_langpack_ja.dmg' the installer show following message. 'これは、LibreOffice 7.0 の有効なインストールではありません。 もう一度インストーラーを実行し、有効な LibreOffice 7.0 インストールを選択してください' (This is not a valid installation of LibreOffice 7.0. Run the installer again and select a valid LibreOffice 7.0 installation.) Version: 7.0.0.1 Build ID: 04ba7e3f1e51af6c5d653e543a620e36719083fd CPU threads: 16; OS: Mac OS X 10.15.5; UI render: GL; VCL: osx Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded
@Kamei, are you also using Catalina ?
There is the same with the Langpack-install German RC1
(In reply to Peter Kranz from comment #8) > There is the same with the Langpack-install German RC1 which OS version ?
@Xisco Faulí Thank you for your replying. Yes, I'm using on macOS 10.15.5.
*** Bug 134926 has been marked as a duplicate of this bug. ***
The bug is still there with LO 7.0.0.3. Tested on macOS 10.15.6 How can you release with this bug being present?
I believe this might be related to bug 133511 but I fail to see why it doesn't work on Catalina and works with previous versions
For the record, I only have one version of LibreOffice installed ( 7.0.0.1 ) How many versions of LibreOffice do you have in parallel ? Does it work if you remove them all and you install LibreOffice from scratch ?
I have only exactly one version of LibO installed. With 7.0.0.3 I replaced 6.4.6.1. I had to completely remove 6461 including everything that AppCleaner detected belonging to 6461 - w/o that even the 7.0.0.3 base installation failed. But even with that complete removal of 6461 and no other LibO installed, the lang pack installation failed: - first, it could not detect the LibO package it is supposed to work on - after selecting the LibO package in the application directory, it complained that 7.0.0.3 is not a valid LibO installation
macOS 10.15.6, LO 7.0RC3 Cannot confirm this problem Downloaded and installed 7.0RC3. Ran a single time. Downloaded and installed de language pack. Mounted, installer ran and finished as expected. Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU-Threads: 8; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
Those having these problem, could you please tell how the software in called in Applications ? Is it called 'LibreOffice' or it has another name ?
It is called "LibreOffice.app" (as always). BTW, I also tried giving both LibreOffice and the LibreOffice Language installer app full disk access rights in macos 10.15.6 - unfortunately, this did not help (at least we can rule this out). I also tried and set full read and write access rights for all users to the LibreOffice.app before installing the language pack - again, no success.
(In reply to Frank Fuchs from comment #18) > It is called "LibreOffice.app" (as always). > > BTW, I also tried giving both LibreOffice and the LibreOffice Language > installer app full disk access rights in macos 10.15.6 - unfortunately, this > did not help (at least we can rule this out). > > I also tried and set full read and write access rights for all users to the > LibreOffice.app before installing the language pack - again, no success. Hi Frank, What do you get when you run from commandline < mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice 7.0.0.3' > and < mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice' > ??
zsh: = not found
(In reply to Frank Fuchs from comment #20) > zsh: = not found Which both commands ? Is it the same problem as described here https://medium.com/@singhaniatanay18/mac-os-catalina-update-zsh-instead-of-bash-d688f68f70b8 ?
Sorry: * First command: no output * second command: after adding an " at the end, I also get no output
(In reply to Frank Fuchs from comment #22) > Sorry: > * First command: no output > * second command: after adding an " at the end, I also get no output First command returns 'LibreOffice 7.0.0.3' for me and the seconds all the pathes where LibreOffice.app is present. According to your comment 18, it should have return /Applications/LibreOffice.app
(In reply to Xisco Faulí from comment #23) > (In reply to Frank Fuchs from comment #22) A few corrections $ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3' LibreOffice.app 7.0.0.3 $ mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" /Applications/LibreOffice.app But this issue is still occurred on my environment. Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 16; OS: Mac OS X 10.15.6; UI render: GL; VCL: osx Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded
(In reply to Kamei from comment #24) > > $ mdls --raw --name kMDItemDisplayName --name kMDItemVersion > /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3' > > LibreOffice.app 7.0.0.3 So to avoid any confusion: In a previous commit you wrote you were trying to install LibreOffice_7.0.0.1_MacOS_x86-64_langpack_ja.dmg - so the languagepack from rc1, but you have LibreOffice 7.0.0.3 (rc3) installed. So in this case the message is correct - the languagepacks want the exact same version. (a conservative approach, in theory the data files would likely be compatible, but only allowing same version just eliminates another point of failure). So please confirm that you tried the installation of the languagepack with the rc3 version as well.
NEEDINFO until feedback is in
(In reply to Christian Lohmaier from comment #25) Sorry for my lack of explanation. I installed 7.0 RC3 and then tried LibreOffice_7.0.0.3_MacOS_x86-64_langpack_ja.dmg and it's still the same situation.
macOS 10.15.6 issue same with all LibreOffice 7.0 RCs and Italian language pack message tells me to provide a valid LibreOffice 7.0 installation
(In reply to Italo Vignoli from comment #28) > macOS 10.15.6 > issue same with all LibreOffice 7.0 RCs and Italian language pack > message tells me to provide a valid LibreOffice 7.0 installation What do you get from the commandlines from comment 24 ?
The FR lang pack installation still fails for me with 7.0.0.3 Tried : mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3' LibreOffice.app 7.0.0.3 mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" /Applications/LibreOffice.app Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 8; OS: Mac OS X 10.15.5; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded
(In reply to Xisco Faulí from comment #29) > (In reply to Italo Vignoli from comment #28) > > macOS 10.15.6 > > issue same with all LibreOffice 7.0 RCs and Italian language pack > > message tells me to provide a valid LibreOffice 7.0 installation > > What do you get from the commandlines from comment 24 ? italo@Italos-MacBook-Pro ~ % mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.0.0.3' LibreOffice.app 7.0.0.3 italo@Italos-MacBook-Pro ~ % mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" /Applications/LibreOffice.app
(In reply to steve -_- from comment #16) > macOS 10.15.6, LO 7.0RC3 > Cannot confirm this problem > > Downloaded and installed 7.0RC3. Ran a single time. > > Downloaded and installed de language pack. Mounted, installer ran and > finished as expected. > > Version: 7.0.0.3 > Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e > CPU-Threads: 8; BS: Mac OS X 10.15.6; UI-Render: Standard; VCL: osx > Locale: de-DE (de_DE.UTF-8); UI: de-DE > Calc: threaded I cannot install de Lang Pack (LibreOffice_7.0.0.3_MacOS_x86-64_langpack_de.dmg) as well as ja on my enviroinment. Installer shows "Starten Sie das Installationsprogramm erneut und wählen Sie eine gültige Installation von LibreOffice 7.0". Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 16; OS: Mac OS X 10.15.6; UI render: GL; VCL: osx Locale: ja-JP (ja_JP.UTF-8); UI: en-US Calc: threaded
did see this effect once now, but with different symptoms and also could not reproduce after updating to 10.15.6 When it failed that one time for me, Catalina failed to index the new LibreOffice.app (that I dragged to Desktop), and instead tried to install to the 6.4.2 that I had in /Applications, so that failed as expected (what was not expected of course is that it didn't offer the new one from Desktop) manually running mdfind didn't include it, and even weirder running mdls on the app folder directly did return nothing at all once, and after that just undefined values (so again expected that the languagepack script would refuse to install, but of course not expected that system tools fail to work as expected). After reboot the new copy I installed to Desktop did show up in mdfind, and was offered in the langpack installer to pick from, but mdls (and hence the installer) still failed. Tried to extract again and order macOS to replace the existing copy and also tried to delete the copy and install again, but that didn't change the mdls problem - it was found by mdfind, but mdls still didn't return valid data. I then updated to 10.15.6 and rebooted and from that point on I was no longer able to recreate the effect, mdls always returned valid info, and the languagepack installscript was happy/did work. While I was "happy" at first that I could see a failing installer on one of the systems I can lay my hands on, it again was extremely frustrating that it was yet a different failure compared to what was described here, and clearly a bug in macOS. Even more frustrating that I didn't have the problem anymore after installing the Catalina update, but people in this bug also have it with 10.15.6, so also can not be dismissed as an apple bug/we can't just tell people to update macOS and all will be fine :-(( I still have no clue at all how it could fail repeatedly/reproducibly on systems where the mdfind/mdls commands return the expected result/Why it works on some systems, but not on others. The default user shell doesn't matter - applescript's "do shell command" is always executed using /bin/sh (bourne shell), no matter what the user did configure. And my Catalina installation is a pristine one with the zsh as default and no development or other third party stuff installed. Only thing that the installation did see was previous versions of LibreOffice, apart from that it was a fresh install via macOS internet recovery without carrying any data over. tldr: Since it is a real/independently confirmed problem, and the ratio of affected users is unknown, but certainly not insignificant, I'll build new languagepacks that skip that check completely.
With the release of 7.0 GA, I have just downloaded both the main app bundle and FR langpack. The FR langpack installer still fails to displau a valid LO70 installation entry. At least the manual selection option now works though, so there is some improvement.
(In reply to Christian Lohmaier from comment #33) > tldr: > Since it is a real/independently confirmed problem, and the ratio of > affected users is unknown, but certainly not insignificant, I'll build new > languagepacks that skip that check completely. For the record, the languagepacks for LibreOffice 7.0 RC3 were reuploaded skipping the check. Could you all please redownloaded the new langpack for your language and try again ?
(In reply to Xisco Faulí from comment #35) > For the record, the languagepacks for LibreOffice 7.0 RC3 were reuploaded > skipping the check. > Could you all please redownloaded the new langpack for your language and try > again ? I downloaded the 7.0 release and corresponding FR langpack this morning, cf. comment 34.
The same problem has just been reported separately on the French discuss m-l, with regard to High Sierra 10.13.
I re-installed LO 7.0.0.3 (replacing 6.4.6.1 completely). Afterwards, I tried with the updated German language pack installer: * It could not find the LO Application * After manually selecting the LO Application from the application directory, it successfully installed. So it seems both the check (now removed) and the way to identify the installed LO is not working correctly - at least on some systems, including mine. The good news is that it is now installable through the manual selection of the target application (not sure if this is fine with non-tech users). macOS 10.15.6 no shell extensions, default zsh shell
The could not find LO problem could be the same as I was seeing - can you confirm that mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" (all in a single line) Doesn't return the location of LO 7.0 for you Alex & Frank? or if it does now, does re-running the installer now manage to locate the 7.0 installer? Did you do a full shutdown and reboot in the meantime (as opposed to just a deep sleep?) And does mdls /path/to/LibreOffice7.0.app return valid data for you? In a previous comment#30 before replacing the 7.0 app Alex wrote the results of the commands and they returned the expected results…
Hi Christian, re your questions in comment 39 (after I successfully installed the German language pack (see my comment 38)): 1) mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" now returns /Applications/LibreOffice.app which is correct 2) does re-running the installer now manage to locate the 7.0 installer? NO 3) Did you do a full shutdown and reboot in the meantime (as opposed to just a deep sleep?) NO 4) mdls /Applications/LibreOffice.app now returns a lot of meaningful information: _kMDItemDisplayNameWithExtensions = "LibreOffice.app" kMDItemAlternateNames = ( "LibreOffice.app" ) kMDItemAppStoreCategory = "Produktivität" kMDItemAppStoreCategoryType = "public.app-category.productivity" kMDItemCFBundleIdentifier = "org.libreoffice.script" kMDItemContentCreationDate = 2020-07-29 22:46:08 +0000 kMDItemContentCreationDate_Ranking = 2020-07-29 00:00:00 +0000 kMDItemContentModificationDate = 2020-07-29 22:46:08 +0000 kMDItemContentModificationDate_Ranking = 2020-07-29 00:00:00 +0000 kMDItemContentType = "com.apple.application-bundle" kMDItemContentTypeTree = ( "com.apple.application-bundle", "com.apple.application", "public.executable", "com.apple.localizable-name-bundle", "com.apple.bundle", "public.directory", "public.item", "com.apple.package" ) kMDItemDateAdded = 2020-08-06 12:18:29 +0000 kMDItemDateAdded_Ranking = 2020-08-06 00:00:00 +0000 kMDItemDisplayName = "LibreOffice.app" kMDItemDocumentIdentifier = 0 kMDItemExecutableArchitectures = ( "x86_64" ) kMDItemFSContentChangeDate = 2020-07-29 22:46:08 +0000 kMDItemFSCreationDate = 2020-07-29 22:46:08 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = (null) kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 1 kMDItemFSIsStationery = (null) kMDItemFSLabel = 0 kMDItemFSName = "LibreOffice.app" kMDItemFSNodeCount = 1 kMDItemFSOwnerGroupID = 80 kMDItemFSOwnerUserID = 501 kMDItemFSSize = (null) kMDItemFSTypeCode = "" kMDItemInterestingDate_Ranking = 2020-08-06 00:00:00 +0000 kMDItemKind = "Programm" kMDItemLastUsedDate = 2020-08-06 12:21:00 +0000 kMDItemLastUsedDate_Ranking = 2020-08-06 00:00:00 +0000 kMDItemUseCount = 2 kMDItemUsedDates = ( "2020-08-05 22:00:00 +0000" ) kMDItemVersion = "7.0.0.3"
(In reply to Frank Fuchs from comment #40) > 1) mdfind "kMDItemContentType =='com.apple.application-bundle' && > kMDItemDisplayName == 'LibreOffice.app'" > now returns > /Applications/LibreOffice.app > which is correct Same here. > > 2) does re-running the installer now manage to locate the 7.0 installer? > NO Same here with FR langpack. No automatic discovery of the installed LO bundle even after re-running the langpack installer. > 3) Did you do a full shutdown and reboot in the meantime (as opposed to just > a deep sleep?) > NO YES, from a cold boot.
I could install JA lang pack. I change the line 69 of 'LibreOffice Language Pack.app/Contents/osx_install.applescript' set found_ooos_all to (do shell script "mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'"") to set found_ooos_all to (do shell script "mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'"") And change the line 129 do shell script "mdls --raw --name kMDItemDisplayName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice 7.0'" to do shell script "mdls --raw --name kMDItemDisplayName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice.app 7.0'" Then, Run the Script. environment: Version: 7.0.0.3 Build ID: 8061b3e9204bef6b321a21033174034a5e2ea88e CPU threads: 16; OS:Mac OS X 10.15.6; UI render: GL; VCL: osx Locale: ja-JP (ja_JP.UTF-8); UI: ja-JP Calc: threaded
Sorry. The escape character for line 69 is missing. line 69 set found_ooos_all to (do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'\"") to set found_ooos_all to (do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'\"") Line number 129 is as shown in the earlier post.
LibO 7.0.1.1 is back to the old behaviour: * The language pack installation cannot find the LibO app * if manually selected, it complains about an invalid LibO file Apparently, someone put the (not working) check back in to the Mac language packs. Until this bug is fixed, can someone please re-deploy the Mac language packs w/o this check (same as done for 7.0.0.3).
(In reply to Frank Fuchs from comment #44) > LibO 7.0.1.1 is back to the old behaviour: > * The language pack installation cannot find the LibO app > * if manually selected, it complains about an invalid LibO file > > Apparently, someone put the (not working) check back in to the Mac language > packs. > > Until this bug is fixed, can someone please re-deploy the Mac language packs > w/o this check (same as done for 7.0.0.3). Yes, that's because the check hasn't been remove in the code yet.
Unbelievable, but LibO 7.0.1.2 has the very same problem. IMHO, you cannot release 7.0.1 with this showstopper. Either this needs a fix or - as a workaround until a fix is implemented - the installation check needs to be removed from the language packs.
(In reply to Frank Fuchs from comment #46) > Unbelievable, but LibO 7.0.1.2 has the very same problem. > IMHO, you cannot release 7.0.1 with this showstopper. > Either this needs a fix or - as a workaround until a fix is implemented - > the installation check needs to be removed from the language packs. Yes, builds are being rebuilt with the workaround included. thanks for noticing.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/d6667aec86718cc4b843a69658fcc83203d66734 tdf#134607 workaround – mac langpack: don't verify target location It will be available in 7.0.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Same here on Big Sur 11.0.1 (20B29) Error reads: (sorry, German) "/Applications/LibreOfficeDev.app/Dies ist keine gültige Installation von LibreOfficeDev 7.1. Starten Sie das Installationsprogramm erneut und wählen Sie eine gültige Installation von LibreOfficeDev 7.1" I have a working and localized installation of LO 7.0.3.1 d7547858d014d4cf69878db179d326fc3483e082 also sitting in Applications.
LibO 7.1.0.1 (7.1 RC1) cannot install any language pack - the workaround introduced in LibO 7.0 seems to be MISSING in 7.1 Tested on macOS 11.1 (big sur) with LibO 7.1.0.1 on a MacBook Pro 15" 2018.
*** Bug 139497 has been marked as a duplicate of this bug. ***
(In reply to Alex Thurgood from comment #51) > *** Bug 139497 has been marked as a duplicate of this bug. *** I'm having the same problem as Frank in comment 50 with BigSur/Mac silicon M1 and 7.1RC1, seems like the fix was not applied to master before branch off for 7.1 ?
Repro Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: en-US (en_US.UTF-8); UI: en-US Calc: threaded Tried langpacks: [1] LibreOffice_7.1.0.3_MacOS_x86-64_langpack_en-GB.dmg [2] LibreOffice_7.1.0.3_MacOS_x86-64_langpack_de.dmg Ends with error notification (popup) /Applications/LibreOffice.app/This is not a valid LibreOffice 7.1 installation. Run the installer again and choose a valid LibreOffice 7.1 installation (or with the German translation of that) $ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice.app 7.1.0.3' LibreOffice.app 7.1.0.3 $ mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" /Applications/LibreOffice.app
Confirming this bug. I was unable to install the en-GB language pack on the release version of 7.1.0 on macOS. Version: 7.1.0.3 / LibreOffice Community Build ID: f6099ecf3d29644b5008cc8f48f42f4a40986e4c CPU threads: 8; OS: Mac OS X 10.15.7; UI render: GL; VCL: osx Locale: en-GB (en_GB.UTF-8); UI: en-US Calc: threaded
Good news everyone, seems that Florian just stumbled upon what is causing the issues: * the bug occurs if you configure finder to show all file extensions so that also is the simple workaround: To install the languagepack disable the setting to show all suffixes (you can reenable it after installing the language pack) That all explains why it is reproducible for some, esp. people in QA, but not as widespread of a problem... Finder | Properties | Advanced -> first option there..
Unfortunately, the solution works in the Finder to disable the setting option “Show all filename suffixes” for me with the following configuration NOT! macOS Big Sur Version 11.2 LibreOffice_7.1.0_macos_x86-64 libreOffice_7.1.0_macos_x86-64_langpack_en After uninstalling the LO above, I installed the previous version 7.0.4 again and was able to add the de-langpack 7.0.4 again (without removing the hook in the Finder setting). On two older MBP (one from Mid 2012, the other at the end of 2014) the same result: 7.1.0 langpack installation no, 7.0.4 langpack installation without any problems yes!
The workaround worked for me: macOS 11.2 LibreOffice 7.1.0.3 German language pack 7.1.0.3 MacBook Pro 15" 2018
Created attachment 169478 [details] Confirmed on M1 MacOS 11.2 beta, using public release 7.1.0.3 Confirmed for MacOS Big Sur 11.2 beta running on an M1 Mac mini. I used the formally released version 7.1.0.3, i.e. files: LibreOffice_7.1.0_MacOS_x86-64.dmg LibreOffice_7.1.0_MacOS_x86-64_langpack_en-GB.dmg The error pops up immediately.
Apologies, forgot to mention that LO langpacks have required to be manually pointed at /Applications/LibreOffice.app since v7.0. I thought this could have something to do with the MacOS need to have first execution confirmed, but starting LO before langpack execution (to get that out of the way) has not made a difference.
Update: the workaround of .. Finder - Preferences - Advanced - untick "Show all filename extensions" .. worked in this case too. Strange.
(and in this case, the langpack did NOT require manual indication of where the LibreOffice.app was located so these issues are related)
The workaround mentioned in Comment 55 worked for me (see Comment 54) as well.
Same here workaround from comment:55 works for me.
Hi Workaround confirmed on Ask FR : https://ask.libreoffice.org/fr/question/291173/erreur-installation-pack-de-langue-71-mac-os/ Regards Pierre-Yves
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/dbaf1d75601cb911d1c17e1e63d2c7047f2cf9e1 tdf#134607 mac-langpacks: always query for full name with extension It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/b6f74722173b0384efa6798799b83807e9f0d814 tdf#134607 mac-langpacks: always query for full name with extension It will be available in 7.1.1. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
*** Bug 140212 has been marked as a duplicate of this bug. ***
I can confirm that the patch appears to work on my system. System: M1 Mac mini, MacOS 11.3 beta Source: /daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-02-06_07.18.19/ Files used: LibreOfficeDev_7.1.1.0.0_MacOS_x86-64.dmg LibreOfficeDev_7.1.1.0.0_MacOS_x86-64_langpack_en-GB.dmg The langpack works so fast it's merely a screen flash :). Good work.
I can confirm too that the patch appears to work on my system. System: iMac I5, MacOS 10.15.7 Catalina Source: /daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-02-06_07.18.19/ Files used: LibreOfficeDev_7.1.1.0.0_MacOS_x86-64.dmg LibreOfficeDev_7.1.1.0.0_MacOS_x86-64_langpack_de.dmg Many thanks.
Me too: - MacOS 10.13.6 High Sierra - LibreOffice 7.1.0.3 - german Langpack, created January 28th, 2021
Xisco Fauli committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/77699401ebfccfd8d55424d771d311639059bf4c Revert "tdf#134607 workaround – mac langpack: don't verify target location" It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/d8ec1283220c56d78bbcee95748283ef590a674b tdf#134607 mac-langpacks: always query for full name with extension It will be available in 7.0.5. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I think we can close this issue as RESOLVED FIXED now. @Christian Lohmaier, thanks for fixing this issue
*** Bug 140379 has been marked as a duplicate of this bug. ***
*** Bug 140391 has been marked as a duplicate of this bug. ***
*** Bug 140149 has been marked as a duplicate of this bug. ***
*** Bug 140531 has been marked as a duplicate of this bug. ***
*** Bug 140795 has been marked as a duplicate of this bug. ***
I can't install a RU language pack to LO 7.1.1 (and on latest 7.2 master build too) with the same problem. People please retest it on your macs
No repro (works for me Version: 7.1.1.2 / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 4; OS: Mac OS X 10.16; UI render: default; VCL: osx Locale: de-DE (de_DE.UTF-8); UI: ru-RU Calc: threaded
Hi, I just updated a MacBook Pro from Mavericks (10.9) to El Capitan (10.11). I consequently updated LibreOffice from v6.2.8.2 to v7.1.1. The bug with the langpack occurs : it can't find automatically the LibreOffice install, and manual selection ends with the invalid install message. As the OS is older than Catalina and Big Sur, this comment might not be relevant here, but the problem seems similar. Excuse-me if this is the wrong place to report. Some infos : Version: 7.1.1.2 / LibreOffice Community Build ID: fe0b08f4af1bacafe4c7ecc87ce55bb426164676 CPU threads: 4; OS: Mac OS X 10.11.6; UI render: default; VCL: osx Locale: fr-FR (fr.UTF-8); UI: en-US Calc: threaded ``` $ mdfind "kMDItemContentType == 'com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice'" /Applications/LibreOffice.app $ mdls --raw --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app | xargs -0 | fgrep 'LibreOffice' LibreOffice 7.1.1.2 $ mdfind "kMDItemContentType == 'com.apple.application-bundle' && _kMDItemDisplayNameWithExtensions == 'LibreOffice'" -> no result (same with 'LibreOffice.app') ``` I tried to turn the Finder's "show all file extensions" setting ON, and OFF again (it was off as default), without any change. I also tried to remove the ".app" on lines 69 and 129 (based on https://bugs.documentfoundation.org/show_bug.cgi?id=134607#c42 but in reverse) in the `Contents/Resources/osx_install.applescript` file, without success. Finally, I tried to replace the `_kMDItemDisplayNameWithExtensions` argument with `kMDItemDisplayName` on line 69, but then it directly displays the invalid install message. When i try to reinstall v6.2.8.2 and its langpack, it works well.
Ok, i found the problem : The property `_kMDItemDisplayNameWithExtensions` does not exist when i do `$ mdls /Applications/LibreOffice.app`. I replaced it by the property `kMDItemFSName` (which as the same value "LibreOffice.app") on lines 69 and 129, and the langpack installed successfully. In addition, in my `mdls` output, compared to comment #40 : - `kMDItemFSName` and `kMDItemAlternateNames` are the same - `kMDItemDisplayName` is "LibreOffice" (without the .app), because of the Finder setting i guess.
Thanks for having a look - cannot test with all versions of macOS, so I just hope that the new patch will work independent of any user settings and on all supported versions of macOS.. patch prepared with that changed here: https://gerrit.libreoffice.org/c/core/+/112385 Would appreciate if people watching this bug could fill in their findings with versions of macOS not listed yet for the following command: mdls --name kMDItemFSName /path/to/LibreOffice.app It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and .app extension independent of the "show file extensions" setting in finder. tested good: 10.11 (comment from SveDoc) 10.14 (myself) 10.16/11 (myself) Please comment with your results if you can test on a different version or (and especially in that case) if you get a different result. Feel free to include additional confirmation for ones listed by other users, but no need for comments that don't add new versions of macOS to that list.
Dear Christian, I tried the command line you mentioned, please see the result bellow: [MBP-de-Ioannis:~ ioannis$ mdls --name kMDItemFSName /path/to/LibreOffice.app /path/to/LibreOffice.app: could not find /path/to/LibreOffice.app. Otherwise attempt to install language pack in French failed : /Applications/LibreOfficeDev.app/Ce n'est pas une installation valide de LibreOfficeDev 7.0. Exécutez de nouveau l'installeur et choisissez une version valide de 7.0 LibreOfficeDev running in this configuration: Version: 7.0.6.0.0+ Build ID: 1ab766f0d455058e0433144acceca2d23451eca0 CPU threads: 8; OS: Mac OS X 10.12.6; UI render: default; VCL: osx Locale: fr-FR (fr_FR.UTF-8); UI: en-US Calc: threaded once with displayed file extensions in the finder and once not displayed and both LibreOffice and language pack downloaded there: https://dev-builds.libreoffice.org/daily/libreoffice-7-0/MacOSX-x86_64@tb81- TDF/2021-03-14_07.03.24/ Same happened with LO 7.1.3.0.0 https://dev-builds.libreoffice.org/daily/libreoffice-7-1/MacOSX-x86_64@tb81-TDF/2021-03-15_07.05.48/ I hope this can help in some extend. KR ioannis (In reply to Christian Lohmaier from comment #83) > Thanks for having a look - cannot test with all versions of macOS, so I just > hope that the new patch will work independent of any user settings and on > all supported versions of macOS.. patch prepared with that changed here: > https://gerrit.libreoffice.org/c/core/+/112385 > > Would appreciate if people watching this bug could fill in their findings > with versions of macOS not listed yet for the following command: > > mdls --name kMDItemFSName /path/to/LibreOffice.app > > It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and > .app extension independent of the "show file extensions" setting in finder. > > tested good: > 10.11 (comment from SveDoc) > 10.14 (myself) > 10.16/11 (myself) > > Please comment with your results if you can test on a different version or > (and especially in that case) if you get a different result. Feel free to > include additional confirmation for ones listed by other users, but no need > for comments that don't add new versions of macOS to that list.
(In reply to Christian Lohmaier from comment #83) > Thanks for having a look - cannot test with all versions of macOS, so I just > hope that the new patch will work independent of any user settings and on > all supported versions of macOS.. patch prepared with that changed here: > https://gerrit.libreoffice.org/c/core/+/112385 > > Would appreciate if people watching this bug could fill in their findings > with versions of macOS not listed yet for the following command: > > mdls --name kMDItemFSName /path/to/LibreOffice.app > > It should report »kMDItemFSName = "LibreOffice.app"« (no directories, and > .app extension independent of the "show file extensions" setting in finder. > > tested good: > 10.11 (comment from SveDoc) > 10.14 (myself) > 10.16/11 (myself) > > Please comment with your results if you can test on a different version or > (and especially in that case) if you get a different result. Feel free to > include additional confirmation for ones listed by other users, but no need > for comments that don't add new versions of macOS to that list. The command returned "could not find /path/to/LibreOffice.app." on my MacBook late 2008 (OSX 10.11.6, LibreOffice 7.1.1.2); languagepack german does not install. Same with 7.0.5. At last I installed the language files manually, which was no joy. The "show file extensions" setting makes no difference on my machine. The problem first occured, after I updated to 7.1.1.2. Former versions of languagepack installed fine on same system. But going back to 7.0.5 did not solve the problem, as mentioned above. Idea: Maybe it has to do with a preference-file, that was written when updating to 7.1.1, so that all further languagepack installations fail?
sorry for not being clear. /path/to/LibreOffice.app needs to be adjusted for the actual path you placed the LibreOffice.app. If you put it into the global Applications folder, use /Applications/LibreOffice.app instead. If you're using a daily build, also user LibreOfficeDev.app accordingly. (e.g. /Applications/LibreOfficeDev.app)
Christian Lohmaier committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/daa162c20f4c7d61edc217ed44cb2854652a63ec tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions It will be available in 7.2.0. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-0": https://git.libreoffice.org/core/commit/00ce3c5c8238035dc0c470e54f055b2406bffd64 tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions It will be available in 7.0.6. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-1": https://git.libreoffice.org/core/commit/78f69c686c9f8b40fbd183dde71e94d4d7a729ab tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions It will be available in 7.1.3. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
Christian Lohmaier committed a patch related to this issue. It has been pushed to "libreoffice-7-1-2": https://git.libreoffice.org/core/commit/40ae5790249811b38f6fafbda5f1396fdb12e996 tdf#134607 use kMDItemFSName instead of _kMDItemDisplayNameWithExtensions It will be available in 7.1.2. The patch should be included in the daily builds available at https://dev-builds.libreoffice.org/daily/ in the next 24-48 hours. More information about daily builds can be found at: https://wiki.documentfoundation.org/Testing_Daily_Builds Affected users are encouraged to test the fix and report feedback.
I have the same problem with Mac Os 10.11.6 (El Capitan). As workaround I have used the previous LibreOffice_7.0.4_MacOS_x86-64_langpack_it and it works.
*** Bug 141170 has been marked as a duplicate of this bug. ***
@keyopen Could you install LibreOffice nightly build and see if the problem persists using that build: https://dev-builds.libreoffice.org/daily/master You should able to install LanguagePack as expected using that build.
Thanks, today's version LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg and langpack_en (2021-Mar-22) installs correctly.
(In reply to Philippe Tharin from comment #94) > Thanks, today's version LibreOfficeDev_7.2.0.0.alpha0_MacOS_x86-64.dmg and > langpack_en (2021-Mar-22) installs correctly. Thanks for checking. Le'ts close it as VERIFIED FIXED
All that what I saw on this page didn´t work for me (Catalina, LibreOffice 7.1.2.2 and de-Languagepack) So I tried a different workaround, that at least works for me. I copied the language files by hand. Hope it helps you too Steps, after you installed libreOffice: - Download Language-Pack of your choice that has exactly the same release as your libreoffice release - Open it in Finder (start it, it will mount the volume but don´t do anything else) - Now open terminal and create a folder, I named it LP: - mkdir LP - cd LP - Check, what your language is and change (de) in next step to your language-letter: - cp -pr /Volumes/LibreOffice\ de\ Language\ Pack/ . - cd cd LibreOffice\ Language\ Pack.app/Contents/Resources - tar -xzf tarball.tar.bz2 - cd Contents/Resources - Now we copy all that stuff to the folder of the LibreOffice-Application. In my case its located in /Applications/LibreOffice.app: - cp -pr . /Applications/LibreOffice.app/Contents/Resources - go to that folder: - cd /Applications/LibreOffice.app/Contents/Resources - Now we need to set the rights of the group to right value - chgrp -R admin . Start your LibreOffice at enjoy it in your language Cheers, Nerd Bert
Idem on Version: 7.1.2.2 / LibreOffice Community Build ID: 8a45595d069ef5570103caea1b71cc9d82b2aae4 CPU threads: 2; OS: Mac OS X 10.11.6; UI render: default; VCL: osx Locale: fr-FR (fr.UTF-8); UI: en-US Calc: threaded Test also with LibreOffice Language Pack in the App Folder. And with or without extension name Sorry, this is the first report for me. So, there's probably not a lot of new information, just confirmation that's it's still not working on last version of LO, and old version of MacOS
Problem is here again in 7.1.5.2 $ echo $LANG fr_FR.UTF-8 $ $ uname -a Darwin FGM-GUI15.local 20.6.0 Darwin Kernel Version 20.6.0: Wed Jun 23 00:26:31 PDT 2021; root:xnu-7195.141.2~5/RELEASE_X86_64 x86_64 $ $ mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app kMDItemDisplayName = (null) kMDItemVersion = (null) $ $ mdfind "kMDItemContentType == 'com.apple.application-bundle'" | grep Libre $ Message during Language pack install (without the quotes), in a "osascript" app: - "Non listé (choississez l'emplacement lors d'une étape supplémentaore" - then - "/Applications/LibreOffice.app/Ce n'est pas une installation valide de LibreOffice 7.1." - "Executez de nouveau l'installeur et choisissez une version valide de 7.1 LibreOffice" - "Installer" button
After discussing with cloph the remaining problem of mdls reporting no info or null value is a bug in macOS. That aspect can only be fixed on Apples side. Feel free to report the problem to Apple using macOS Feeback Assistant to make them aware of the issue.
But md* (mdfind mainly) tools use spotlight and you can have spotlight disabled. Here I have spotlight disabled and thus md* won't be able to find anything new that is not already indexed by spotlight. arekm@amb ~ % mdutil -s /Applications/ /System/Volumes/Data/Applications: Indexing disabled. And indeed: arekm@amb ~ % mdfind "kMDItemContentType =='com.apple.application-bundle' && kMDItemDisplayName == 'LibreOffice.app'" arekm@amb ~ % mdls /Applications/LibreOffice.app kMDItemFSContentChangeDate = 2021-08-16 23:51:29 +0000 kMDItemFSCreationDate = 2021-08-16 23:51:29 +0000 kMDItemFSCreatorCode = "" kMDItemFSFinderFlags = 0 kMDItemFSHasCustomIcon = 0 kMDItemFSInvisible = 0 kMDItemFSIsExtensionHidden = 0 kMDItemFSIsStationery = 0 kMDItemFSLabel = 0 kMDItemFSName = "LibreOffice.app" kMDItemFSNodeCount = 1 kMDItemFSOwnerGroupID = 80 kMDItemFSOwnerUserID = 501 kMDItemFSSize = 1 kMDItemFSTypeCode = "" Why not iterate over /Applications/*.app (or just check /Applications/LibreOffice*.app), check interesting parts + still do mdfind solution, so there are more changes to get this working?
As of today, it looks like the proper `mdfind` query is mdfind "kMDItemDisplayName == 'LibreOffice' && kMDItemContentType =='com.apple.application-bundle'" ⚠ This will only succeed after FileVault has had a chance to validate your installation of LibreOffice — i.e. you have to run it once. If you don't, the symptom looks a lot like 134607 all over again: mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app kMDItemDisplayName = (null) kMDItemVersion = (null)
On MacOS 10.14.6 with LibreOffice Community 7.5.1: $ cd $ mdls --name kMDItemDisplayName --name kMDItemVersion /Applications/LibreOffice.app kMDItemDisplayName = "LibreOffice.app" kMDItemVersion = (null) $ mdfind "kMDItemDisplayName == 'LibreOffice' && kMDItemContentType =='com.apple.application-bundle'" $ whoami nonadminuser $ ls -la /Applications/LibreOffice.app total 0 drwxr-xr-x@ 3 nonadminuser admin 96 Feb 23 02:35 . drwxrwxr-x+ 114 root admin 3648 Mar 28 16:32 .. drwxr-xr-x@ 9 nonadminuser admin 288 Feb 23 03:03 Contents Enabling or disabling show all file extensions is not changing. Running with user account and user account with admin priviledges does not change. Please note that all applications where installed with non admin user typing name/password of admin user in GUI. So issue is still open for me. Why not create simple bash script in package that allows manual unzip? Patch does seem to do no more than exploding tarball.tar.bz2 into existing installation.
I tried several versions, also running in the problem. Last one working as expected here (with "Show suffixes" enabled) was 7.4.5 and 7.5.1 From what I found out: The app *must* be named "LibreOffice" - something like "LibreOffice7.5.2" won't work at all (but did in the past). So installing the app, run "sudo codesign -vvv --deep --strict /Applications/LibreOffice.app" and then the LangPack installer worked properly. (No clue if codesign is necessary, but it helped in the past.) (MacOS Intel 12.6.5.)