On 24/1/25 02:55, Volker Krause wrote:
On Donnerstag, 23. Januar 2025 10:21:08 Mitteleuropäische Normalzeit Ben
Cooksley wrote:
On Thu, Jan 23, 2025 at 7:21 AM Volker Krause <vkra...@kde.org> wrote:
On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben
Cooksley wrote:
On Thu, Jan 23, 2025 at 5:49 AM Volker Krause <vkra...@kde.org> wrote:
On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit
Albert
Astals Cid wrote:
neochat - NEW
* https://invent.kde.org/network/neochat/-/pipelines/869365
* flatpak build fails
Same as https://invent.kde.org/network/neochat/-/merge_requests/2127 I
guess,
looks like an API change in libQuotient with the corresponding version
change
still pending (ie. a similar problem we occasionally hit with
Poppler).
The quick solution for this would probably be (temporarily) switching
Flatpak
to the latest release of libQuotient. The IMHO proper solution would
be to
have version bumps at the beginning of a development cycle that
changes
API.
This also raises another question though - should we be strongly
discouraging use of heavily moving targets like upstream dev / master
branches and instead favouring the use of stable branches?
Not really ideal if upstream can essentially break our builds without us
doing anything.
I can't comment on NeoChat, but for Itinerary the builds against the
latest
versions of essential (external) dependencies with varying
intentions/success
in keeping backward compatibility (ZXing, Poppler, Quotient) are very much
deliberate, to catch breakage/regressions early (same as we are now doing
for
KF with Qt pre-releases).
And this is actually working, NeoChat has been fixed to build with the
upcoming
Quotient version, same for Itinerary/Poppler. The only thing we are
missing
for those fixes to take effect is those dependencies bumping their version
numbers.
We could work around that by doing configure-time detection using a
compile
test, but that's a lot of extra work, so we'd better try to address this
upstream first.
I'd very much suggest the use of release tarballs (or stable branches) for
apps that aren't continuously monitoring their dependencies this way
though,
but I'm not aware we have such a case.
Doesn't this interfere somewhat with the long term eventual goal of us
pushing Flatpak binaries directly to Flathub though?
(not to mention make stable branch builds impossible to reproduce in the
long run)
For Itinerary at least the release branch is using release tarballs rather
than (latest) Git branches, matching what we have on Flathub. (This does imply
some manual work at branch time, but at least for me that's more than offset by
what this saves in catching issues early).
But you are right of course that this is abusing Flatpak a bit as CI. That's
not ideal but it's just very tempting as it has minimal extra cost (Flatpak
has to build those dependencies anyway, and Flatpak builds run less often than
normal CI builds).
Regards,
Volker
I've moved this to a new email subject as it's no longer just about
failing CI builds.
My proposal would be have 3 files in the repository that are Flatpak
related:
- .flatpak-manifest.yml will continue to exist for git master builds and
be deployed to https://cdn.kde.org/flatpak/
- org.kde.appname.json which will be for Flathub stable builds will only
run on release branches when a tag is made (I am hoping CI can be
triggered by a tag).
- Both will reference a file called org.kde.appname.dependencies.json
which contains the the dependencies that get build for the app and will
point to tarballs or tags for released versions.
Flatpak supports referencing external files for build dependencies and
you can use JSON or YAML interchangeably.
I think this will be good for Flatpak builds as we really want them
targeting the stable released tarballs, not some function in git master
of a dependency that *MIGHT* be released in time for the next KDE release.
