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

(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?

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

(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.

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.

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

(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.

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

*** Bug 143601 has been marked as a duplicate of this bug. ***

*** Bug 150967 has been marked as a duplicate of this bug. ***

*** Bug 147280 has been marked as a duplicate of this bug. ***

*** Bug 153395 has been marked as a duplicate of this bug. ***

*** Bug 147138 has been marked as a duplicate of this bug. ***

*** Bug 153356 has been marked as a duplicate of this bug. ***

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"

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'"

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.

Patrick: as macOS expert, thought you might have some opinion here.

(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?

(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?)

(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.

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).

(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.

(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! :-)

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

(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.

(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 :-)

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.

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"

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.

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.

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?

(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

(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.

*** Bug 150969 has been marked as a duplicate of this bug. ***