Description: Copying LibO from the DMG to the disk takes quite a long time with LibO6. It's a lot faster with 5.2 and 5.3 Steps to Reproduce: 1. Download the DMG 2. Drag and drop LibreOffice to the program folder (and monitor the time needed) Actual Results: Takes 3 or 4 minutes Expected Results: 40 seconds Reproducible: Always User Profile Reset: No Additional Info: Version: 6.0.0.1 Build ID: d2bec56d7865f05a1003dc88449f2b0fdd85309a CPU threads: 4; OS: Mac OS X 10.12.6; UI render: default; Locale: nl-NL (nl_NL.UTF-8); Calc: group User-Agent: Mozilla/5.0 (Windows NT 6.3; WOW64; rv:52.0) Gecko/20100101 Firefox/52.0
Confirming with LO5442
Cloph. Has there been a change related to the packaging of the MacOS installer between 5.3 and 5.4? Which could cause a signing issue or something like that? There is a noticeable slowness when copying the installer files to the Programs directory. http://crl.apple.com/root is showing up in the console... (Bug 114364 might me related to this too.)
Telesto: What is that link in your previous comment supposed to be?
(In reply to Tor Lillqvist from comment #3) > Telesto: What is that link in your previous comment supposed to be? No clue... Apple console reports all sorts of stuff while copying LibO to the application directory. For example 20:33:01.504390 +0200 DesktopServicesHelper Received claim <private> 20:33:01.504732 +0200 DesktopServicesHelper Claim F59962AC-B0B0-407D-8D4B-D3EE29232452 granted in server 20:33:01.505016 +0200 DesktopServicesHelper Claim F59962AC-B0B0-407D-8D4B-D3EE29232452 invoked in client 20:33:01.772432 +0200 DesktopServicesHelper Claim F59962AC-B0B0-407D-8D4B-D3EE29232452 was revoked --- trustd asynchronously fetching CRL (http://crl.apple.com/root.crl) for client (mdworker[2340])
"Copying the installation files is quite slow" is actually an understatement. It took over 3-4 minutes for me to copy the latest master build to my disk. Using an SSD and not seeing this with any other software. It feels this has gotten worse lately.
(In reply to steve -_- from comment #5) > "Copying the installation files is quite slow" is actually an > understatement. It took over 3-4 minutes for me to copy the latest master > build to my disk. Using an SSD and not seeing this with any other software. > It feels this has gotten worse lately. I agree. It's painfully slow. I'm skipping daily builds all together
I just installed 6132 and it took more than 5 minutes to copy the app bundle to the Applications folder (macmini end 2014, 8 Gb RAM)
(In reply to Alex Thurgood from comment #7) > I just installed 6132 and it took more than 5 minutes to copy the app bundle > to the Applications folder (macmini end 2014, 8 Gb RAM) Adding Tor Lillqvist
It is possible that packaging the TDF build in some more up-to-date format (and not as a .dmg) would make the installation speedier. But I wouldn't know. My main interest is the App Store build anyway.
(In reply to Tor Lillqvist from comment #9) > It is possible that packaging the TDF build in some more up-to-date format > (and not as a .dmg) would make the installation speedier. But I wouldn't > know. My main interest is the App Store build anyway. Another perspective: it *really* discourages installing Alpha/beta builds from TDF. Making group of testers (and maybe users) even smaller. Increasing the risk of a drop the quality of the App Store build in the long run.. Not sure if this has something to do with DMG. It's rather new issue; since LibO 6.0.
Yes, this is quite slow and may discourage people from trying LibreOffice? Still present on the release build of 6.3 I only started timing after progressing halfway, but it used 1:15 on copying from 380-700 MB Using cp in the terminal used 0:30 for the full copy
Still present
Chat conversation with Cloph: Nothing we can do about it as it is mac that is copying the files from dmg to target disk. Nothing special about that / LibreOffice package has no say in that / is not involved at all. So the complaint is rather: macOS is slow at copying files from a mounted diskimage (dmg). Type of compression could be changed, but I doubt this would make any difference. If someone does research on why it is slow, I'm willing to have another look, but as it stands now: I don't see any way to improve it. Is not the signing/notarization, since the daily builds are not signed or notarized and apparently suffer from the same slowdowns. So leaves only the compression used as a potential candidate, but then again I cannot really imagine that would change things. Potential starting point: play with how the dmg is created, search for the hdiutil invocations in the code etc: https://opengrok.libreoffice.org/xref/core/solenv/bin/modules/installer/simplepackage.pm?r=443f65e9#458 As per above remarks setting to NOTOURBUG If anybody has an idea PLEASE re-open and add your input to this bug.
Just if someone wants to test various image formats: hdiutil has a "convert image" option, so that should be a much faster playground then using gbuild. No Mac so can't test. See https://ss64.com/osx/hdiutil.html
By the way, one would think (hope) that apps distributed through the Mac App Store use some fast and elegant installation method. At least I don't think any disk images are involved. But sadly Xcode itself (which is a *huge* application, sure) is infamous for taking tens of minutes to upgrade from the App Store (once the download has finished).
(In reply to Tor Lillqvist from comment #15) > By the way, one would think (hope) that apps distributed through the Mac App > Store use some fast and elegant installation method. At least I don't think > any disk images are involved. But sadly Xcode itself (which is a *huge* > application, sure) is infamous for taking tens of minutes to upgrade from > the App Store (once the download has finished). That's a lovely fact. But original point was it was better with 5.3 dmg. So installing a 5.3 package was faster on 10.12.6. Obviously this measure taken a while back and we are now at Big Sur 11.2.3. So needs a comparison fresh comparison, IMHO. But I for people testing daily's it no fun. So you certainly trim down on number of installs.
Sorry, overlooked comment 13.. will check it at some point
Seems like someone hunted down the reason, and a patch got committed! *** This bug has been marked as a duplicate of bug 151341 ***