Bug 144053 - Installation of Language Pack fails on macOS with Spotlight off
Summary: Installation of Language Pack fails on macOS with Spotlight off
Status: RESOLVED FIXED
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Localization (show other bugs)
Version:
(earliest affected)
7.2.5.2 release
Hardware: All macOS (All)
: high critical
Assignee: Patrick Luby (volunteer)
URL:
Whiteboard: target:7.6.0.2 target:24.2.0
Keywords:
: 143601 147138 147280 150967 153356 153395 (view as bug list)
Depends on:
Blocks: Language-Help-Packs
  Show dependency treegraph
 
Reported: 2021-08-24 14:00 UTC by Matthias Wilde
Modified: 2023-08-14 13:41 UTC (History)
13 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 Matthias Wilde 2021-08-24 14:00:48 UTC
Description:
Installation of german language pack for LibreOffice 7.2 (and yes its the same on earlier Versions 7.x) fails with "Dies ist keine gltige Installation von LibreOffice 7.2".
Problem is the apple script line looking for an App name "LibreOffice.app 7.2" which cannot be found, because standard installation is "LibreOffice.app" to fix this, i changed the accoding argument in the fgrep call after 

-- now only check whether the path is really from LibreOffice

in "osx_install.applescript" to:

do shell script "mdls --raw --name kMDItemFSName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice.app'"

With this change i could install german language pack

Steps to Reproduce:
1. install LibreOffice from DMG File
2. open fresh installed LibreOffice.app
3. close LibreOffice.app
4. open the LanguagePack file from the downloaded DMG file
5. press install
6. select the previously installed "LibreOffice.app"
7. Installation Fails

Actual Results:
fails with "Dies ist keine gültige Installation von LibreOffice 7.2"

Expected Results:
succesfull installation (independent of a version string) 


Reproducible: Always


User Profile Reset: No



Additional Info:
cannot copy text from the mac about dialog. i can add the link of the build only: https://git.libreoffice.org/core/+log/9a9c6381e3f7a62afc1329bd359cc48accb6435b
Comment 1 [REDACTED] 2021-08-25 09:10:26 UTC
Can't repro

Version: 7.2.0.4 / LibreOffice Community
Build ID: 9a9c6381e3f7a62afc1329bd359cc48accb6435b
CPU threads: 4; OS: Mac OS X 10.13.6; UI render: default; VCL: osx
Locale: en-US (de_DE.UTF-8); UI: de-DE
Calc: threaded

(regardless of Finder preference "Show all filename extension" is set to "on" or "off")

See also bug report tdf#143601
Comment 2 [REDACTED] 2021-08-25 09:25:25 UTC
(In reply to mwilde from comment #0)

> 6. select the previously installed "LibreOffice.app"

This step makes me ask: Do you have different installations / multiple versions of LibreOffice installed?
Comment 3 Matthias Wilde 2021-08-25 13:35:32 UTC
Hi Uwe,
no, i have only one version of LO installed.

But meanwhile i made some more investigations and found my proposal is not the fix, it hides only another problem and so its only a (bad) workaround.

When i call your original code from terminal:
"mdls --raw --name kMDItemFSName --name kMDItemVersion '/Applications/LibreOffice.app/' | xargs -0 | fgrep 'LibreOffice.app 7.2'" 
this returns an exit code of "1" which is treated as an error.

When i call instead my (pseudo) fix:
"mdls --raw --name kMDItemFSName --name kMDItemVersion '/Applications/LibreOffice.app/' | xargs -0 | fgrep 'LibreOffice.app'" 
this returns a code of "0", even there are no metadata found and because uf the "no error" result installation proceeds.

So the original cause is, that there are no metadata available on my system. mdls does not work for any folder or file! Even the simple call of "mdls /Applications/LibreOffice.app/*" will return with  a message: "/Applications/LibreOffice.app/Contents: could not find /Applications/LibreOffice.app/Contents.".
I checked now also with xattr-command and see only "com.apple.quarantine", nothing else. So at least on my system OSX 10.13.6 (High Sierra) with homebrew in use, the script does not work.
I would propose not to use the metadata approach in your script but to use the user selection directly instead, because for privacy reasons spotlight might be of also and so this will not work on a secure machine.

Best regards
Matthias
Comment 4 [REDACTED] 2021-08-25 14:30:18 UTC
(In reply to mwilde from comment #3)
> Hi Uwe,
> no, i have only one version of LO installed.
>....
> I would propose not to use the metadata approach in your script 

I'm not the author of the script. Just try to figure out, how this report is related to bug tdf#134607 - which is VERIFIED FIXED and finally closes in comment 99 (tdf#134607#c99): 

> After discussing with cloph the remaining problem of mdls reporting no info or > null value is a bug in macOS.
Comment 5 Matthias Wilde 2021-08-25 16:05:04 UTC
Ok, i see the script will probably never be changed regarding the already closed issue remarked by Uwe.

So i will use the extract step in the terminal window to do the work from now on for myself. 
For all people interested in this solution (i have no script in place, so one must adapt the commands according to his/hers environment) open a terminal and follow the two steps (execute command after step description):

1. extract the resources from the language pack to the installed LibreOffice:
tar -C /Applications/LibreOffice.app/ -xjf /Volumes/LibreOffice\ de\ Language\ Pack/LibreOffice\ Language\ Pack.app/Contents/Resources/tarball.tar.bz2

2. "touch" the extensions to get actual modified date:
touch /Applications/LibreOffice.app/Contents/Resources/extensions

Please take notice on the "escaped" blanks inside the command lines (e.g. "\ de") which are neccessary because path contains blanks in my environment.

So i will check next version if this also works for me there.
Comment 6 der_ron 2022-01-24 17:41:16 UTC
Hello documentfoundation community,

thank you for your hard work to provide a free office software for all of us!

I have to second Matthias Wilde in this case:

please correct and simplify your language pack installation script for the mac os platform, in my case mac os High Sierra!

I write this comment after 5 hours of struggling to get LibreOffice 7.2 and the german language pack to work on my pc.


Best regards, Ron
Comment 7 Matthias Wilde 2022-02-12 16:23:58 UTC
(In reply to der_ron from comment #6)
> Hello documentfoundation community,
> 
> thank you for your hard work to provide a free office software for all of us!
> 
> I have to second Matthias Wilde in this case:
> 
> please correct and simplify your language pack installation script for the
> mac os platform, in my case mac os High Sierra!
> 
> I write this comment after 5 hours of struggling to get LibreOffice 7.2 and
> the german language pack to work on my pc.
> 
> 
> Best regards, Ron

Hi Ron,

thanks for your support. I think the main problem on my machine is, that i have disabled "Spotlight" for privacy reasons and i will never enable it again. So i cannot say, if it would work normally having Spotlight enabled or not.

But as i already mentioned in my comment (2021-08-25) extracting the language pack manulally did the trick for me and i exercised this just now with the new LO 7.3.0.3.

If the creator of the installer would use another detection method (not using mdls) this could help probably. Also it would be great, if the creator of the language pack installer add my workaround to the "Readme" included in the image so other users having privacy issues have a workaround:

After mounting the image you need only to run two commands:
- 'tar -C /Applications/LibreOffice.app/ -xjf /Volumes/LibreOffice\ de\ Language\ Pack/LibreOffice\ Language\ Pack.app/Contents/Resources/tarball.tar.bz2'
- touch /Applications/LibreOffice.app//Contents/Resources/extensions

Now you can use LO with your preferred Language.
Comment 8 Julien Nabet 2022-09-15 09:54:52 UTC
Christian: any thoughts about what Matthias proposed?
I mean perhaps it could help not only for this bug but for other ones, especially tdf#143601
Comment 9 Stéphane Guillou (stragu) 2023-02-19 21:55:41 UTC
*** Bug 143601 has been marked as a duplicate of this bug. ***
Comment 10 Stéphane Guillou (stragu) 2023-02-19 21:55:51 UTC
*** Bug 150967 has been marked as a duplicate of this bug. ***
Comment 11 Stéphane Guillou (stragu) 2023-02-19 21:56:20 UTC
*** Bug 147280 has been marked as a duplicate of this bug. ***
Comment 12 Stéphane Guillou (stragu) 2023-02-19 21:56:35 UTC
*** Bug 153395 has been marked as a duplicate of this bug. ***
Comment 13 Stéphane Guillou (stragu) 2023-02-19 21:58:06 UTC
*** Bug 147138 has been marked as a duplicate of this bug. ***
Comment 14 Stéphane Guillou (stragu) 2023-02-19 22:02:32 UTC
*** Bug 153356 has been marked as a duplicate of this bug. ***
Comment 15 Arkadiusz Miśkiewicz 2023-02-20 08:48:53 UTC
Maybe switch to "defaults" [1] command (or fallback to it) like described in

https://bugs.documentfoundation.org/show_bug.cgi?id=147280#c2

with example output on

https://bugs.documentfoundation.org/show_bug.cgi?id=147280#c4
(and that's on spotlight disabled system)

1. man defaults -> "defaults - access the Mac OS X user defaults system"
Comment 16 sohil 2023-04-06 09:03:51 UTC Comment hidden (obsolete)
Comment 17 der_ron 2023-05-05 12:19:06 UTC
Thank you Matthias Wilde for your support!

I had no problems installing the LangPacks in LibreOffice 7.2 up to 7.4.6 following your instructions.

I assume that the average pc user is not able to:

a.) find your instructions
b.) understand your instructions
c.) or is not is willing to invest the time and work to get LibreOffice working

Since depending on the Spotlight feature in Mac OS is insecure:
Please document foundation, change your installation scripts!



-----

set found_ooos_all to (do shell script "mdfind \"kMDItemContentType == 'com.apple.application-bundle' && kMDItemFSName == 'LibreOffice.app'\"")

do shell script "mdls --raw --name kMDItemFSName --name kMDItemVersion " & quoted form of (choice as string) & " | xargs -0 | fgrep 'LibreOffice.app 7.4'"
Comment 18 Wim M 2023-06-20 13:43:23 UTC
I have recently installed LO 7.5.4.2 on three different Macs. Depending on the age of the Mac, the installation of the language pack will fail initially ("this is not a valid LibreOffice installation"), at least until Spotlight has caught up with the recent installation, after which installation of the language pack does work. Depending on the age of the Mac and the amount of software installed, this can be anywhere between almost instantaneous and a few hours/after a reboot.

As has been noted in previous comments in this bug and some related ones (notably bug 129177, bug 12978 and bug 134607), the separate installation of language packs is unnecessarily fickle and not userfriendly, especially to ordinary users, given (1) the need to download and install a separate language pack; (2) the need to run LibreOffice after an update before installing the language pack and (3) the possibility that it may still fail at that point and from the perspective of the user, you need to wait a while until it suddenly does work.

The best solution has already been suggested in bug 129178: bundle the main UI languages in the app itself. Is there any chance that this solution could receive some love? It would make both installing and updating LO a bit less of a chore.
Comment 19 Julien Nabet 2023-06-20 16:37:55 UTC
Patrick: as macOS expert, thought you might have some opinion here.
Comment 20 Patrick Luby (volunteer) 2023-06-20 17:22:20 UTC
(In reply to Julien Nabet from comment #19)
> Patrick: as macOS expert, thought you might have some opinion here.

I cannot remember which bug I commented on last autumn, but to summarize my opinion: ship all the languages in the main installer .dmg like is done for the Mac App Store. This really is the standard way on macOS. macOS installs all supported languages, keyboards, etc. for everyone so it is very odd to have download and install language packs in a macOS application.

I am just a volunteer so the people I think that you need to talk to are TDF's release engineering staff and see what issues block a much bigger .dmg with all the languages. Maybe the download costs are prohibitive or maybe there are other issues with mirror sites?
Comment 21 Julien Nabet 2023-06-20 18:41:23 UTC
(In reply to Patrick Luby from comment #20)
> (In reply to Julien Nabet from comment #19)
> > Patrick: as macOS expert, thought you might have some opinion here.
> 
> I cannot remember which bug I commented on last autumn, but to summarize my
> opinion: ship all the languages in the main installer .dmg like is done for
> the Mac App Store. This really is the standard way on macOS. macOS installs
> all supported languages, keyboards, etc. for everyone so it is very odd to
> have download and install language packs in a macOS application.
> 
> I am just a volunteer so the people I think that you need to talk to are
> TDF's release engineering staff and see what issues block a much bigger .dmg
> with all the languages. Maybe the download costs are prohibitive or maybe
> there are other issues with mirror sites?

Argh, thought there would be a solution avoiding to download a big package.
Now I must recognize I don't know what size it would be to have package with all languages.

Miklos: would it be possible to add this topic on ESC? (BTW, I didn't see the Windows update subject on last ESC, was it too late?)
Comment 22 Patrick Luby (volunteer) 2023-06-20 19:14:43 UTC
(In reply to Julien Nabet from comment #21)
> Argh, thought there would be a solution avoiding to download a big package.
> Now I must recognize I don't know what size it would be to have package with
> all languages.
> 

In my experience with NeoOffice, below are the two biggest things that increased .dmg:

1. Building a Universal .dmg. That would double the size of the binary files but not any localization or most resource files. But LibreOffice currently releasesseparate Intel and Silicon .dmg files that might not be applicable to LibreOffice.

2. Include help files in the .dmg. I did this for NeoOffice and this added about 15MB per language. But I think the releases on the LibreOffice web site use web help so that might not be applicable LibreOffice.

3. UI localization and resource files. I don't know how much these add to .dmg but I am sure it isn't trivial.

So item 3 above is where I think we'll see most of the increase in .dmg size.  The question for the ESC and TDF is how big is too big? In other words, I don't think the issue here is a technical one but, instead, it is how much will it cost TDF to fix this bug. Specifically:

- Monthly recurring increased bandwidth costs
- One time staff cost to implement the necessary build and website changes. This "cost" is likely what other planned LibreOffice infrastructure would have to be deferred to make time for this.

I can help implement the necessary build changes if that helps.
Comment 23 Arkadiusz Miśkiewicz 2023-06-21 05:52:14 UTC
IMO there is no point in bundling all languages into main dmg.


The problem *why* installation fails is explained in https://bugs.documentfoundation.org/show_bug.cgi?id=144053#c15
and in linked comments there.

It's obvious why it fails.

There is also proposed solution in form of different commands used (that don't rely on spotlight) or first try spotlight then fallback.

Unfortunately no one at macos libreoffice team is interested into implementing this (or someone else with apple script / dmg building knowledge).
Comment 24 Miklos Vajna 2023-06-21 06:57:08 UTC
(In reply to Julien Nabet from comment #21)
> Miklos: would it be possible to add this topic on ESC?

Yes. This week is special; next week Stephan will run the call. The easiest is if you add it to the agenda yourself (when he sends it out). Or if it's not urgent, I can add it to the agenda in 2 weeks when I can be in the call myself again.

> (BTW, I didn't see
> the Windows update subject on last ESC, was it too late?)

No, sorry, I noted it down, but to the wrong place, so it was forgotten. Same as above, worst case I'll bring this up.

But really, the best is if you don't ping me but wait for the next weekly agenda email thread and you reply there. :-) (No need to edit anything in etherpad if that sounds complicated.) The important point is you need to ask a technical question, the ESC can try to provide input on that. Thanks.
Comment 25 Julien Nabet 2023-06-21 08:14:07 UTC
(In reply to Miklos Vajna from comment #24)
> (In reply to Julien Nabet from comment #21)
> > Miklos: would it be possible to add this topic on ESC?
> ...
> But really, the best is if you don't ping me but wait for the next weekly
> agenda email thread and you reply there. :-) (No need to edit anything in
> etherpad if that sounds complicated.) The important point is you need to ask
> a technical question, the ESC can try to provide input on that. Thanks.

Ok I'll do this, since holidays are coming, there'll be less people so if it can be tackled this week, it would be great! :-)
Comment 26 Stéphane Guillou (stragu) 2023-06-21 08:24:35 UTC
For the record, the topic of langpack inclusion was brought up at a February 2023 ESC meeting:

https://lists.freedesktop.org/archives/libreoffice/2023-February/089992.html

Patrick, maybe the reply you're thinking of is this one:

https://lists.freedesktop.org/archives/libreoffice/2023-February/089993.html
Comment 27 Patrick Luby (volunteer) 2023-06-21 13:51:06 UTC
(In reply to Stéphane Guillou (stragu) from comment #26)
> For the record, the topic of langpack inclusion was brought up at a February
> 2023 ESC meeting:
> 
> https://lists.freedesktop.org/archives/libreoffice/2023-February/089992.html
> 
> Patrick, maybe the reply you're thinking of is this one:
> 
> https://lists.freedesktop.org/archives/libreoffice/2023-February/089993.html

So the ESC rejected my proposal back in February yet the person arguing against my proposal at the ESC hasn't taken ownership of fixing this bug.

Seems to be this case is closed. I made a proposal and it got rejected but the ESC and TDF paid staff won't put any effort into fixing it.

And, as expected, nothing has changed. My opinion certainly hasn't as I have shipped complete .dmg's with help files includes for more than a decade so I have zero interest in spending my limited volunteer time trying to keep the oddball language pack solution alive. There are more than enough crashing and hanging bugs to fill my time.

This is the last I'll discuss this topic. If the ESC changes it mind in the future, then I'll be happy to help implement a single .dmg.
Comment 28 Julien Nabet 2023-06-21 14:46:54 UTC
(In reply to Patrick Luby from comment #27)
> ...
> This is the last I'll discuss this topic. If the ESC changes it mind in the
> future, then I'll be happy to help implement a single .dmg.

I must recognize I'd prefer too not to put all languages since it consumes bandwidth (for tdf and users) + useless space disk for users.
However, since you were used to do this on NeoOffice, I can understand your frustration.
I know almost nothing on macOS so wonder if things are so complicated here because of Apple, because of LO custom build system or something else.
Let's wait for some more years and see! Sometimes LO is a school of patience :-)
Comment 29 Wim M 2023-06-21 15:00:49 UTC
Thank you to everyone for your responses; I am a bit surprised at the number of reactions my comment triggered, but it's been quite helpful since the different points made across various bug reports and in the ESC meetings have at least all been restated here.

I remain partial to the solution proposed by Patrick, which is to bundle all the language files (at least for the UI) into the installer. It has the benefit of making LO feel like a native app on macOS and it takes away all the clunkiness of a current installation or update. I have a difficult time estimating whether the cost of the bandwith would be a real factor, but I imagine there are far fewer downloads of LO for macOS than there are for windows, while the Windows installer does seem to have all the languages included.

The main benefit is however that it really enhances the ease of installation of LO on macOS, so more users can see how far it has come in the last few versions (thanks in large part to the many longstanding issues fixed by Patrick). So as an ordinary user, I hope the ESC will reconsider.
Comment 30 Patrick Luby (volunteer) 2023-07-21 14:12:13 UTC
So I encountered this bug earlier this week as I have Spotlight disabled for my main macOS volume.

I finally had a little bit of time to troubleshoot the shell script that @Matthia Wilde found in osx_install.applescript. Below is a patch with my replacement for the mdls command:

https://gerrit.libreoffice.org/c/core/+/154718

The patch still needs to be reviewed before it is included in a release build, but you might be able to manually test my fix by replacing line 129 in the osx_install.applescript file in a LibreOffice 7.6 language pack with the following line:

do shell script "grep '^ProductKey=LibreOfficeDev 7.6$' " & quoted form of (choice as string) & "/Contents/Resources/bootstraprc"
Comment 31 Commit Notification 2023-07-26 12:37:08 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "libreoffice-7-6":

https://git.libreoffice.org/core/commit/09752e7560bc5a0b8f08e1d3ee4878db3208ca4b

tdf#144053 Compare version to ProductKey entry in bootstraprc

It will be available in 7.6.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.
Comment 32 Commit Notification 2023-07-26 12:40:17 UTC
Patrick Luby committed a patch related to this issue.
It has been pushed to "master":

https://git.libreoffice.org/core/commit/1184a0130e7f340093a4bc0de032ebea1866b467

tdf#144053 Compare version to ProductKey entry in bootstraprc

It will be available in 24.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.
Comment 33 Patrick Luby (volunteer) 2023-07-27 12:40:10 UTC
My fix for the language pack installer is now in the nightly builds. To test my fix, download both the latest main installer and a language pack from the following link:

https://dev-builds.libreoffice.org/daily/master/

Important notes:
1. Only download *.dmg files that are dated 27 July 2023 or later
2. The *.dmg files are not codesigned so you will need to execute the following command in the Terminal for each of the *.dmg files that you download:
    xattr -d com.apple.quarantine </path/to/your/downloaded/file.dmg>

Can anyone who experienced this bug confirm that my fix works for you?
Comment 34 eisa01 2023-08-04 20:04:55 UTC
(In reply to Wim M from comment #29)
> Thank you to everyone for your responses; I am a bit surprised at the number
> of reactions my comment triggered, but it's been quite helpful since the
> different points made across various bug reports and in the ESC meetings
> have at least all been restated here.
> 
> I remain partial to the solution proposed by Patrick, which is to bundle all
> the language files (at least for the UI) into the installer. It has the
> benefit of making LO feel like a native app on macOS and it takes away all
> the clunkiness of a current installation or update. I have a difficult time
> estimating whether the cost of the bandwith would be a real factor, but I
> imagine there are far fewer downloads of LO for macOS than there are for
> windows, while the Windows installer does seem to have all the languages
> included.
> 
> The main benefit is however that it really enhances the ease of installation
> of LO on macOS, so more users can see how far it has come in the last few
> versions (thanks in large part to the many longstanding issues fixed by
> Patrick). So as an ordinary user, I hope the ESC will reconsider.

Agree

The non-English macOS users of LO must be a really dedicated group to put up with a two-step installation process _for every single update_

If there's a worry about download size (not warranted IMO - the App Store version with all languages is a 850 MB download), then TDF should offer full installation packages for each language instead of the current hacky two-step installation process
Comment 35 Wim M 2023-08-14 13:41:13 UTC
(In reply to Patrick Luby from comment #33)
> My fix for the language pack installer is now in the nightly builds. To test
> my fix, download both the latest main installer and a language pack from the
> following link:
> 
> https://dev-builds.libreoffice.org/daily/master/
> 
> Important notes:
> 1. Only download *.dmg files that are dated 27 July 2023 or later
> 2. The *.dmg files are not codesigned so you will need to execute the
> following command in the Terminal for each of the *.dmg files that you
> download:
>     xattr -d com.apple.quarantine </path/to/your/downloaded/file.dmg>
> 
> Can anyone who experienced this bug confirm that my fix works for you?

Just to confirm that the en-GB language pack on RC3 of 7.6 (7.6.0.3) installed flawlessly on one of my Macs without any waiting time. So this fix seems to have done the trick. Many thanks!

Of course I still hope that eventually other languages will be integrated in the main install.