After upgrading to Fedora 35 the usability of my LibreOffice installation has taken a major hit. Both on my desktop running NVIDIA/Xorg and on the laptop running AMD/Wayland, the application window (Calc, Writer) takes a very long time to open. In case of the desktop it is a few seconds, but in case of the laptop it is a few minutes, rendering the appication more or less unusable. There is unfortunately nothing displayed in the console. How can I enable more verbose logging in order to get this resolved?
Please write here the info from LibreOffice's Help->About dialog (use a Copy button there)
Version: 7.2.3.2 Build ID: 20(Build:2) CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: de-DE Calc: threaded
I did some more testing: - SAL_USE_VCLPLUGIN=gen oocalc starts right away - SAL_USE_VCLPLUGIN=kf5 oocalc results in gtk3 backend being used anyway and also takes very long to start.
Please try download an install LibreOffice from our site https://libreoffice.org/download and try retest your problem in it
scalc binary from the upstream RPMs does not exhibit this issue: Version: 7.2.4.1 / LibreOffice Community Build ID: 27d75539669ac387bb498e35313b970b7fe9c4f9 CPU threads: 6; OS: Linux 5.15; UI render: default; VCL: gtk3 Locale: de-DE (de_DE.UTF-8); UI: en-US Calc: threaded I have noticed that when I am at home, Fedora calc does start much faster than when I'm not. Moreover, I can see the following in the journal when it does: Dez 06 06:48:42 snowball3 systemd[1]: mnt-openmediavault.automount: Got automount request for /mnt/openmediavault, triggered by 114> Dez 06 06:48:42 snowball3 systemd[1]: Mounting /mnt/openmediavault... Dez 06 06:48:42 snowball3 kernel: FS-Cache: Loaded Dez 06 06:48:42 snowball3 kernel: Key type dns_resolver registered Dez 06 06:48:43 snowball3 kernel: FS-Cache: Netfs 'cifs' registered for caching Dez 06 06:48:43 snowball3 kernel: Key type cifs.spnego registered Dez 06 06:48:43 snowball3 kernel: Key type cifs.idmap registered Dez 06 06:48:43 snowball3 kernel: CIFS: Attempting to mount \\odroidxu4.local\julian Dez 06 06:48:43 snowball3 systemd[1]: Mounted /mnt/openmediavault. Can it be that libreoffice tries to process the recent files in a way which causes the slowness? The recent files list of the upstream RPM is empty which would also explain why it is not slow. The reason I am suspecting this is that the list of recent files also takes time to appear.
Only you can say us if this is really a reason. Please do some experiments and write here the result. I won't change a status while we wait Thank you for the report
I am happy to, but: is there a way to generate a log or make verbose output go into the console? Otherwise it is a bit like trying to find a needle in the haystack.
OK, I am now almost certain the slowness is caused by cifs gvfs files present in the recent files list. I have copied .config/libreoffice/4/user/registrymodifications.xcu to ./libreoffice/opt/UserInstallation/user/registrymodifications.xcu and both versions now behave the same: - if I have already connected to the cifs gvfs share from gnome and the password is available, the two shares pop up in nautilus as calc waits and then calc window appears - if the shares are already mounted, there is no startup delay - if I go offline, the delay is the longest as (I am assuming) libreoffice waits for the connection to time out Assuming all of the above is true, is there an option to disable pinging files from the recent list? I would expect to wait for timeout if I attempt to open a file from a currently unavailable share, but merely having worked on such files in the past should not be enough to have to wait for timeout for a few minutes.
[Automated Action] NeedInfo-To-Unconfirmed
Seems to be fixed as of 7.2.5.2. *** This bug has been marked as a duplicate of bug 146219 ***