4/5/2023 0 Comments Macos catalina patcher deutschSet found_ooos_all to (do shell script "mdfind "kMDItemContentType = '-bundle' & kMDItemDisplayName = 'LibreOffice'"") I change the line 69 of 'LibreOffice Language Pack.app/Contents/osx_install.applescript' KMDItemInterestingDate_Ranking = 00:00:00 +0000 KMDItemContentModificationDate_Ranking = 00:00:00 +0000 KMDItemContentModificationDate = 22:46:08 +0000 KMDItemContentCreationDate_Ranking = 00:00:00 +0000 KMDItemAppStoreCategory = "Produktivität" _kMDItemDisplayNameWithExtensions = "LibreOffice.app" Now returns a lot of meaningful information: Re your questions in comment 39 (after I successfully installed the German language pack (see my comment 38)):ġ) mdfind "kMDItemContentType ='-bundle' & kMDItemDisplayName = 'LibreOffice.app'"Ģ) 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?) 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. 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. And my Catalina installation is a pristine one with the zsh as default and no development or other third party stuff installed. 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. 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. 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 :-(( 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. 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. 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. 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).Īfter 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. 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) Did see this effect once now, but with different symptoms and also could not reproduce after updating to 10.15.6
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |