We moved the LibreOffice Flatpak builds to Flathub a while ago, and updating to new versions is normally a pain-free process. (For us as producers of those updates, at least. For you as a user of Flatpak, the process should always be pain-free, anyway.)
However, for LibreOffice 6, building it on Flathub took a bit longer than expected:
Originally, the LibreOffice Flatpak version had lacked a JRE, so some functionality just wasn’t available. There is now a Flatpak extension that allows to bundle Java 9 with an app, so I was finally able to fix this long-standing issue.
In addition, I figured it could be useful to provide debug information for the LibreOffice flatpak (which comes as an extension that you can then optionally install with something like flatpak install flathub org.libreoffice.LibreOffice.Debug).
So I prepared the necessary changes well ahead of the LibreOffice 6.0.0 announcement, tested them locally on my x86_64 machine, and was confident that thinks would just work when I would trigger the Flathub build once the LibreOffice announcement was due. Turned out I was wrong.
First, one little aarch64-specific fix had been missing on the libreoffice-6-0 branch. No problem, just apply the corresponding master fix as a patch to the Flatpak version. Then builds started to fail randomly.
Enabling debug information for an application as large as LibreOffice can increase the size of what gets build, and the time to build it, quite substantially. I do such full-debug-information builds of upstream LibreOffice rather routinely on my (somewhat powerful) local build machine without any problem, so I didn’t even give a thought to this when enabling debug information for the Flathub builds. But it turns out that took some of the Flathub build machines (especially for less powerful platforms, like 32-bit x86) already close to the edge of their capacity. And something as trivial as applying the master-branch patch in the previous step meant that disk-space demand of the LibreOffice builds increased by yet another substantial amount (as Flatpak now needed to install the full LibreOffice git source repository, instead of taking shortcuts). That was apparently enough to move some of the builders over the edge, and into random “disk full” etc. failures.
So I weakened that debug feature again. There is still unstripped symbol information in the Debug extension that you can download (i.e., you will see meaningful function names in backtraces), just not the whole debug data (e.g., you won’t see source file names and line numbers in backtraces, or be able to print variable values in gdb).
Meanwhile, there had been work going on to finally provide 32-bit arm builds of LibreOffice on Flathub. We had initially disabled that platform because of an issue with the version of GCC 6 that is used to do the builds. That arm-specific issue appears to be fixed with GCC 7, and there is now a Flatpak extension that allows to use GCC 7 instead of 6. And the test branch to do the LibreOffice build with GCC 7 and enable arm worked just fine. When building the old LibreOffice 5.4 version, that is.
When I tried to merge those two efforts that had gone on in parallel, switching to LibreOffice 6 and switching to GCC 7, things started to fail once again.
First off, the Java extension was not available for arm. So building on arm refused to work outright. There is work in progress to make it available, but by now LibreOffice 6 had officially been announced and available for download, and people waiting for the Flatpak version started to get impatient. So I decided to leave 32-bit arm unsupported for just a bit longer and dropped it from the list of supported platforms for the LibreOffice Flathub build again.
But things still didn’t work. The aarch64 build kept failing one of the tests that are executed during the build of LibreOffice. Sometimes these tests are a bit flaky and fail for “random” reasons. So I scheduled multiple builds, just to be sure. But, for sure, aarch64 kept failing, always during the same test.
I had kept using GCC 7 for these builds, even after the original reason for it (to enable 32-bit arm builds) was gone. Looks like there is some issue with building LibreOffice 6.0 with GCC 7, on aarch64 (which I still need to track down in detail). When I switched back to GCC 6, all builds were finally green. And were allowed into the Flathub repo, from where you can install/update them.
(That happened on Friday, just in time to get the LibreOffice 6 Flatpak version battle-tested at FOSDEM. I know at least gicmo’s and my presentations were powered by that version, without a glitch.)