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