KDE Gear projects with failing CI (master) (21 January 2025)

[Volker Krause]

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 <vkrause at 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.

Regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 195 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20250122/1fe68184/attachment.sig>