On 23/1/25 07:26, Albert Astals Cid wrote:
El dimecres, 22 de gener del 2025, a les 19:19:23 (Hora estàndard del Centre
d’Europa), Volker Krause va escriure:
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.
I'm fine with break-things-early if we have a fix-things-early outcome from it
:)
Cheers,
Albert
And this is generally the case with NeoChat as several of the main
contributors also work on libquotient upstream.
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.
Regards,
Volker
