Description: Export to EPUB has no progress bar Steps to Reproduce: 1. Open attachment 160498 [details] 2. File -> Export as -> Export as epub Actual Results: No progress bar Expected Results: A progress bar Reproducible: Always User Profile Reset: No Additional Info: Version: 7.0.0.0.beta1+ (x64) Build ID: 2891e91a513520d68ea2b8c59c14335861a15253 CPU threads: 4; OS: Windows 6.3 Build 9600; UI render: Skia/Vulkan; VCL: win Locale: nl-NL (nl_NL); UI: en-US Calc: CL
Confirm it. There were 30 seconds of not knowing what was happening. It would be more usefull. Version: 6.4.4.2 Build ID: libreoffice-6.4.4.2-snap1 CPU threads: 4; OS: Linux 5.4; UI render: default; VCL: gtk3; Locale: ro-RO (ro_RO.UTF-8); UI-Language: en-US Calc: threaded
Fine with Version: 6.2.0.0.beta1+ Build ID: e45c30858dec1dd705b9144fab981a3c8819ba96 CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; Locale: nl-NL (nl_NL); UI-Language: en-US Calc: CL
Telesto, can you make a screenshot of the progress bar when exporting to EPUB?...
(In reply to BogdanB from comment #3) > Telesto, can you make a screenshot of the progress bar when exporting to > EPUB?... The progress bar appears to be Windows only :-).
Ok, this is weird.. LibreOffice 6.2 origin/master has a progress bar & is fast (Windows) LibreOffice 6.3 oldest has no progress bar & is slow (Windows) GDI/OpenGL makes no difference Profile reset.. no difference
(In reply to Telesto from comment #5) > Ok, this is weird.. > > LibreOffice 6.2 origin/master has a progress bar & is fast (Windows) > LibreOffice 6.3 oldest has no progress bar & is slow (Windows) > > GDI/OpenGL makes no difference > Profile reset.. no difference Ah, now I get it.. my 6.2 bibisect repro is missing a bunch of commits.. So progress bar was around in LibreOffice 6.2 somewhere.. but broken again prior to release
(In reply to Telesto from comment #2) > Fine with > Version: 6.2.0.0.beta1+ > Build ID: e45c30858dec1dd705b9144fab981a3c8819ba96 > CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; > Locale: nl-NL (nl_NL); UI-Language: en-US > Calc: CL I used this commit as the first good result. Telesto: you have to git pull origin/master in your repository to update it. Note that you might have to first edit the config file in the .git directory and change the url to https://bibisect.libreoffice.org/win32-6.2.git as the urls were changed on the server. My blamed result is this: https://git.libreoffice.org/core/+/3b03604d1bb48fc1c1337307d0ba259dca9fbf1e%5E!/ Revert "tdf#121497 "Save As": File Format Type unchanged in Windows" It does not make sense to me at all - the only connecting thing is the file dialog. I did double-check with the good/bad commits. Mike: just to triple-check with you: is my bibisect result complete crap?
(In reply to Buovjaga from comment #7) > My blamed result is this: > https://git.libreoffice.org/core/+/ > 3b03604d1bb48fc1c1337307d0ba259dca9fbf1e%5E!/ > Revert "tdf#121497 "Save As": File Format Type unchanged in Windows" > > It does not make sense to me at all - the only connecting thing is the file > dialog. I did double-check with the good/bad commits. > > Mike: just to triple-check with you: is my bibisect result complete crap? Yes, absolutely unrealistic result. But could you please check if the bibisect's first bad commit has the same commit hash in help -> about? There's some hope that the problem in bibisect repo is only with tagging, and about dialog is unaffected?
(In reply to Mike Kaganski from comment #8) > (In reply to Buovjaga from comment #7) > > My blamed result is this: > > https://git.libreoffice.org/core/+/ > > 3b03604d1bb48fc1c1337307d0ba259dca9fbf1e%5E!/ > > Revert "tdf#121497 "Save As": File Format Type unchanged in Windows" > > > > It does not make sense to me at all - the only connecting thing is the file > > dialog. I did double-check with the good/bad commits. > > > > Mike: just to triple-check with you: is my bibisect result complete crap? > > Yes, absolutely unrealistic result. But could you please check if the > bibisect's first bad commit has the same commit hash in help -> about? > There's some hope that the problem in bibisect repo is only with tagging, > and about dialog is unaffected? The commit hash in About is the same.
(In reply to Buovjaga from comment #9) Then only trying to revert it can tell for sure...
Another data point: it seems the progress bar has never worked on Linux. Tried with appimages of 6.1.0 and 6.2.0. Also, Linux master for me is fast and not slow like Windows.
Now also tested with cleared profile, but the good/bad results stay the same.
(In reply to Telesto from comment #5) > Ok, this is weird.. > > LibreOffice 6.2 origin/master has a progress bar & is fast (Windows) > LibreOffice 6.3 oldest has no progress bar & is slow (Windows) (In reply to Buovjaga from comment #7) > (In reply to Telesto from comment #2) > > Fine with > > Version: 6.2.0.0.beta1+ > > Build ID: e45c30858dec1dd705b9144fab981a3c8819ba96 > > CPU threads: 4; OS: Windows 6.3; UI render: default; VCL: win; > > Locale: nl-NL (nl_NL); UI-Language: en-US > > Calc: CL > > I used this commit as the first good result. Hmm. But *beta1+* is *after* 6.2 branch-off! Since "LibreOffice 6.3 oldest has no progress bar & is slow", then it must be something *before* the branch-off that made the regression (if bibisect-6.2's oldest is OK) and then temporarily reverted then broke again; or something *fixed* in between the branch-off and e45c30858dec1dd705b9144fab981a3c8819ba96, which could be reverse-bibisected.
(In reply to Buovjaga from comment #7) > My blamed result is this: > https://git.libreoffice.org/core/+/ > 3b03604d1bb48fc1c1337307d0ba259dca9fbf1e%5E!/ > Revert "tdf#121497 "Save As": File Format Type unchanged in Windows" > > It does not make sense to me at all - the only connecting thing is the file > dialog. I did double-check with the good/bad commits. > > Mike: just to triple-check with you: is my bibisect result complete crap? It's amazing. Reverse-bisecting, I see that the progress bar and the fast processing started to appear after https://git.libreoffice.org/core/+/02a5cbb9814dc224114dfbf3bc0b6c53658450c9 - so yes, the bibisect by Buovjaga is correct. It's now very interesting why? Mood: shocked.
This is *not* a regression. In the range between 3b03604d1bb48fc1c1337307d0ba259dca9fbf1e and its correct revert in 02a5cbb9814dc224114dfbf3bc0b6c53658450c9, trying to export to EPUB actually saved an ODT. That code made incorrect selection to be returned to the calling code. So the fast operation and progress bar were artifacts of using another export filter, which both operates faster and shows the bar.
*** Bug 129262 has been marked as a duplicate of this bug. ***
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/848f9b2c56ce4c4620f62f1fbf9d12d84ec4da96 tdf#133767 new service TempFileFastService It will be available in 7.5.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.
In 48 hours.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/09dfee8a1cf7698a637f647f48750cf8d5722b7c tdf#133767 use more TempFileFastService It will be available in 7.5.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.
Noel Grandin committed a patch related to this issue. It has been pushed to "master": https://git.libreoffice.org/core/commit/9fd78b7421b5acefc8d0bde7cc103a045d79bd04 tdf#133767 speed up temp file creation It will be available in 7.5.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.
Noting that I was using the wrong bug number in my commits, so my recent commits are actually meant for #133768
Where is the dev appimage?
Ah, I see it in the wiki. Maybe just pointing directly to it will be better.
Those appimages doesn't seem to be the ones we need. They are 7.4, and the bug is still there. I would suggest just using appimages for testing, instead packages that work for specific Linux distros. Less building, broader compatibility.
(In reply to Alberto Salvia Novella from comment #24) > Those appimages doesn't seem to be the ones we need. They are 7.4, and the > bug is still there. > > I would suggest just using appimages for testing, instead packages that work > for specific Linux distros. Less building, broader compatibility. The packages work on any Linux distro. You just need to extract them. You can use the appimage creation script to automatically download, extract and create an appimage from the daily builds: https://wiki.documentfoundation.org/Installing_in_parallel/Linux#Automated_installation
Building the appimage fails with: 2022-10-30 08:54:15 (33,5 MB/s) - ‘appimagetool’ saved [8811712/8811712] + chmod a+x ./appimagetool + set +x appimagetool, continuous build (commit b719a7f), build <local dev build> built on 2022-09-29 13:55:16 UTC Desktop file not found, aborting + [[ N == \Y ]] + mkdir -p ../out/ + mv '*.AppImage*' ../out/ mv: cannot stat '*.AppImage*': No such file or directory
And extracting the deb, and executing its contents: ./soffice.bin: error while loading shared libraries: libuno_sal.so.3: cannot open shared object file: No such file or directory
The appimage discussion is indeed very interesting, but do people pay attention to comment 21?
(In reply to Alberto Salvia Novella from comment #26) > Building the appimage fails with: > > 2022-10-30 08:54:15 (33,5 MB/s) - ‘appimagetool’ saved [8811712/8811712] > > + chmod a+x ./appimagetool > + set +x > appimagetool, continuous build (commit b719a7f), build <local dev build> > built on 2022-09-29 13:55:16 UTC > Desktop file not found, aborting > + [[ N == \Y ]] > + mkdir -p ../out/ > + mv '*.AppImage*' ../out/ > mv: cannot stat '*.AppImage*': No such file or directory Works for me. Please confirm that you did this step: 1. Make sure you have dpkg installed (install from your package manager)
Using LibreOffice: - Version: 7.5.0.0.alpha0+ (X86_64) / LibreOffice Community - Build ID: 9cd0f4c2d25462feba0ffcbd906c199273821243 - CPU threads: 4; OS: Linux 6.0; UI render: default; VCL: kf5 (cairo+xcb) - Locale: en-US (en_US.UTF-8); UI: en-US - Calc: threaded With the document: - https://archive.org/download/los-lugares-olvidados-de-altura/Los%20Lugares%20Olvidados%20de%20Altura.odt I confirm that there is no progress bar. Libreoffice just hangs. https://media.giphy.com/media/pPhyAv5t9V8djyRFJH/giphy.gif
Still reproducable in LO 7.4.3.2 under Windows 10(x64). About one minute LO hangs and after that exported .odt file into .epub without progress bar. Version: 7.4.3.2 (x64) / LibreOffice Community Build ID: 1048a8393ae2eeec98dff31b5c133c5f1d08b890 CPU threads: 4; OS: Windows 10.0 Build 19044; UI render: Skia/Raster; VCL: win Locale: ta-IN (en_IN); UI: en-US Calc: threaded