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

[Albert Astals Cid]

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

I'm fine with break-things-early if we have a fix-things-early outcome from it 
:)

Cheers,
  Albert

> 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