Download it now!
Bug 134607 - LO7RC1 - LANGPACK macOS - many versions fail to recognize LibreOffice7 installation as valid on Catalina
Summary: LO7RC1 - LANGPACK macOS - many versions fail to recognize LibreOffice7 instal...
Status: NEW
Alias: None
Product: LibreOffice
Classification: Unclassified
Component: Installation (show other bugs)
Version:
(earliest affected)
7.0.0.1 rc
Hardware: All Mac OS X (All)
: highest critical
Assignee: Not Assigned
URL:
Whiteboard: target:7.0.2
Keywords:
: 134926 (view as bug list)
Depends on:
Blocks:
 
Reported: 2020-07-07 10:50 UTC by Alex Thurgood
Modified: 2020-10-07 14:36 UTC (History)
4 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 Alex Thurgood 2020-07-07 10:50:59 UTC
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 ?
Comment 1 patjolata 2020-07-09 09:00:40 UTC
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.
Comment 2 Xisco Faulí 2020-07-09 13:36:59 UTC
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
Comment 3 Xisco Faulí 2020-07-09 13:38:03 UTC
Alex, which version of Macintosh version are you using ?
Comment 4 Alex Thurgood 2020-07-10 06:30:27 UTC
Hi Xisco,

Catalina 10.15.5
Comment 6 Kamei 2020-07-16 07:08:07 UTC
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
Comment 7 Xisco Faulí 2020-07-16 13:14:18 UTC
@Kamei, are you also using Catalina ?
Comment 8 Peter Kranz 2020-07-16 15:15:33 UTC
There is the same with the Langpack-install German RC1
Comment 9 Xisco Faulí 2020-07-16 15:26:39 UTC
(In reply to Peter Kranz from comment #8)
> There is the same with the Langpack-install German RC1

which OS version ?
Comment 10 Kamei 2020-07-17 01:19:58 UTC
@Xisco Faulí
Thank you for your replying.
Yes, I'm using on macOS 10.15.5.
Comment 11 Alex Thurgood 2020-07-18 14:59:57 UTC
*** Bug 134926 has been marked as a duplicate of this bug. ***
Comment 12 Frank Fuchs 2020-07-31 09:02:48 UTC
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?
Comment 13 Xisco Faulí 2020-07-31 09:50:16 UTC
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
Comment 14 Xisco Faulí 2020-07-31 09:57:41 UTC
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 ?
Comment 15 Frank Fuchs 2020-07-31 10:04:23 UTC
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
Comment 16 steve -_- 2020-07-31 10:22:58 UTC
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
Comment 17 Xisco Faulí 2020-07-31 13:56:33 UTC
Those having these problem, could you please tell how the software in called in Applications ? Is it called 'LibreOffice' or it has another name ?
Comment 18 Frank Fuchs 2020-07-31 14:53:52 UTC
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.
Comment 19 Xisco Faulí 2020-07-31 14:58:57 UTC
(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' > ??
Comment 20 Frank Fuchs 2020-07-31 15:06:30 UTC
zsh: = not found
Comment 21 Xisco Faulí 2020-07-31 16:02:49 UTC
(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 ?
Comment 22 Frank Fuchs 2020-07-31 16:10:31 UTC
Sorry:
* First command: no output
* second command: after adding an " at the end, I also get no output
Comment 23 Xisco Faulí 2020-07-31 16:45:35 UTC
(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
Comment 24 Kamei 2020-08-03 04:13:29 UTC
(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
Comment 25 Christian Lohmaier 2020-08-03 09:48:45 UTC
(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.
Comment 26 steve -_- 2020-08-03 09:56:41 UTC
NEEDINFO until feedback is in
Comment 27 Kamei 2020-08-04 01:55:15 UTC
(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.
Comment 28 Italo Vignoli 2020-08-04 13:39:31 UTC
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
Comment 29 Xisco Faulí 2020-08-04 13:42:07 UTC
(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 ?
Comment 30 Alex Thurgood 2020-08-04 14:05:43 UTC
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
Comment 31 Italo Vignoli 2020-08-04 15:37:23 UTC
(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
Comment 32 Kamei 2020-08-05 07:13:45 UTC
(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
Comment 33 Christian Lohmaier 2020-08-05 09:33:42 UTC
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.
Comment 34 Alex Thurgood 2020-08-06 06:30:11 UTC
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.
Comment 35 Xisco Faulí 2020-08-06 08:32:45 UTC
(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 ?
Comment 36 Alex Thurgood 2020-08-06 09:20:39 UTC
(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.
Comment 37 Alex Thurgood 2020-08-06 10:03:16 UTC
The same problem has just been reported separately on the French discuss m-l, with regard to High Sierra 10.13.
Comment 38 Frank Fuchs 2020-08-06 12:25:52 UTC
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
Comment 39 Christian Lohmaier 2020-08-06 14:15:47 UTC
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…
Comment 40 Frank Fuchs 2020-08-06 16:45:48 UTC
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"
Comment 41 Alex Thurgood 2020-08-07 07:55:41 UTC
(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.
Comment 42 Kamei 2020-08-12 01:55:58 UTC
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
Comment 43 Kamei 2020-08-12 02:19:36 UTC
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.
Comment 44 Frank Fuchs 2020-08-13 20:40:08 UTC
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).
Comment 45 Xisco Faulí 2020-08-14 07:04:28 UTC
(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.
Comment 46 Frank Fuchs 2020-08-29 08:08:49 UTC
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.
Comment 47 Xisco Faulí 2020-09-01 16:54:39 UTC
(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.
Comment 48 Commit Notification 2020-09-07 16:16:11 UTC
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.