Open EliasOfWaffle opened 1 year ago
Started test build 44926
Build 44926 failed
Started test build 44929
Build 44929 failed
Started test build 44933
Build 44933 failed
Started test build 44943
Build 44943 failed
Started test build 44944
Build 44944 failed
Started test build 44945
Build 44945 failed
Started test build 44948
Build 44948 failed
Started test build 44950
Build 44950 failed
Started test build 44966
Hi I made a similar merge request using the kde runtime, which should be less work to maintain https://github.com/flathub/org.libreoffice.LibreOffice/pull/232
Build 44966 successful To test this build, install it from the testing repository:
flatpak install --user https://dl.flathub.org/build-repo/27585/org.libreoffice.LibreOffice.flatpakref
Started test build 45060
Build 45060 failed
Started test build 45071
Hi I made a similar merge request using the kde runtime, which should be less work to maintain #232
Sorry carl, but your commit is not building, and is not good to change the platform, the best idea for libreoffice is to be platform agnostic, i think using kde runtime can break a good gnome detection in VCL backend. Instead of this is better to build qt5 and qt-wayland, this not modify the platform. think with me, i am a gnome user and i not have nothing about kde platform installed, use kde platform will force the user to download a other runtime and kde specific components. And in this case kde runtime/sdk and gnome runtime/sdk leaves more time to update after a release. This pull tries to maintain more agnostic possible, and to not break things
Build 45071 successful To test this build, install it from the testing repository:
flatpak install --user https://dl.flathub.org/build-repo/27690/org.libreoffice.LibreOffice.flatpakref
What is the motivation for this PR? Are you intending to propose it for merging, or is it just meant as a throwaway testing ground? (As were apparently the recent PR 230 and PR 231, but which were clearly labeled as that.)
Started test build 45279
Build 45279 failed
What is the motivation for this PR? Are you intending to propose it for merging, or is it just meant as a throwaway testing ground? (As were apparently the recent PR 230 and PR 231, but which were clearly labeled as that.)
LibreOffice for Red Hat have removed, have some possibilities to Fedora or Other distros not maintain more, i think the OpenSuse can work in the same way, because maintain LibreOffice depends amount of Dependencies package, can be good to be a merge request if in the future the LibreOffice from Flathub can be a good alternative for a future distros that have removed LibreOffice, in this case for users That user LibreOffice can be a Good Integration using a specific platform VCL Backend, in this case the QT5 five is working, some of users that use a QT based DE (LXQT and etc) can be a best integration. The new work of more commits is for Supporting KF5 VCL Backend for a best integration in plasma. For now is just a minimal trying, because need's more test and work for this can be usable for daily usage
Started test build 45538
Build 45538 failed
Started test build 45553
Build 45553 failed
Started test build 45559
Build 45559 failed
Started test build 45571
Build 45571 failed
For now is just a minimal trying, because need's more test and work for this can be usable for daily usage
Just two notes so far:
--enable-qt5 --enable-kf5
, I would assume that the flatpak will still always use the GTK backend by default (but correct me if I'm wrong). Is your approach here that users will override that via the SAL_USE_VCLPLUGIN
environment variable?Started test build 45695
For now is just a minimal trying, because need's more test and work for this can be usable for daily usage
Just two notes so far:
- There is little excitement here about bundling more modules than the existing gvfs and krb5 ones: For each module, if there are any relevant (security) issues, we need to notice that and take appropriate action in a timely manner.
- Even when built with
--enable-qt5 --enable-kf5
, I would assume that the flatpak will still always use the GTK backend by default (but correct me if I'm wrong). Is your approach here that users will override that via theSAL_USE_VCLPLUGIN
environment variable?
Yes the CVEs can be noticed in updates changelog yet? And the mainly ideia is for have a script thats define this variable, but in my test with KDE QT5 is not detected automatically, but if be necessary the user can define this variable if can be necessary
Yes the CVEs can be noticed in updates changelog yet?
(Which would require that somebody would actively watch change logs for those additional modules.)
Yes the CVEs can be noticed in updates changelog yet?
(Which would require that somebody would actively watch change logs for those additional modules.)
Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.
Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.
Build 45695 failed
Started test build 45708
Yes the CVEs can be noticed in updates changelog yet?
(Which would require that somebody would actively watch change logs for those additional modules.)
Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.
Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.
But in this case, the gtk3 default backend can be builded in the same way? and the future with new GTK4 backend (WIP) how this can be maintained? this break gtk3 and just build qt and kf5 (i think). Can be better to maintain multiples Backends if be possible to use Fedora Runtime, but this is not supported by flatpak yet?
Yes the CVEs can be noticed in updates changelog yet?
(Which would require that somebody would actively watch change logs for those additional modules.)
...or at least make use of https://github.com/flathub/flatpak-external-data-checker, which I just learned about, and intend to make use of for LibreOffice (see https://github.com/flathub/org.libreoffice.LibreOffice/pull/236 "Add metadata for flatpak-external-data-checker".)
Yeah, this is why I believe the best way is to import the KDE runtime, which inherits from the freedesktop runtime since the kde runtime is maintained and regularly updated. We don't want and need to duplicate this work inside the LibreOffice flatpak packaging.
Now I just need to figure out why #232 doesn't compile :( While I would consider myself quite familiar with Qt, I have no idea about the autotools toolchain.
But switching from org.freedesktop.Platform
to org.kde.Platform
is obviously a no-go to begin with.
Build 45708 failed
Started test build 45721
But in this case, the gtk3 default backend can be builded in the same way? and the future with new GTK4 backend (WIP) how this can be maintained? this break gtk3 and just build qt and kf5 (i think).
KDE runtime is superset of freedesktop - the former contains everything from the latter so for gtk backends it's irrelevant which runtime LO uses.
I think using qt /kf5 backend without KDE runtime would mean there is no theme integration with host system.
Build 45721 failed
This provide a building with qt5 KF5 VCL Backend. Can be necessary more work at top of this pull request to have the best integrations with QT DEs