<div dir="ltr"><div dir="ltr">On Thu, Jan 23, 2025 at 7:21 AM Volker Krause <<a href="mailto:vkrause@kde.org">vkrause@kde.org</a>> wrote:</div><div class="gmail_quote gmail_quote_container"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben <br>
Cooksley wrote:<br>
> On Thu, Jan 23, 2025 at 5:49 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
> > On Dienstag, 21. Januar 2025 23:11:56 Mitteleuropäische Normalzeit Albert<br>
> > <br>
> > Astals Cid wrote:<br>
> > > neochat - NEW<br>
> > > <br>
> > >  * <a href="https://invent.kde.org/network/neochat/-/pipelines/869365" rel="noreferrer" target="_blank">https://invent.kde.org/network/neochat/-/pipelines/869365</a><br>
> > >  <br>
> > >   * flatpak build fails<br>
> > <br>
> > Same as <a href="https://invent.kde.org/network/neochat/-/merge_requests/2127" rel="noreferrer" target="_blank">https://invent.kde.org/network/neochat/-/merge_requests/2127</a> I<br>
> > guess,<br>
> > looks like an API change in libQuotient with the corresponding version<br>
> > change<br>
> > still pending (ie. a similar problem we occasionally hit with Poppler).<br>
> > <br>
> > The quick solution for this would probably be (temporarily) switching<br>
> > Flatpak<br>
> > to the latest release of libQuotient. The IMHO proper solution would be to<br>
> > have version bumps at the beginning of a development cycle that changes<br>
> > API.<br>
> <br>
> This also raises another question though - should we be strongly<br>
> discouraging use of heavily moving targets like upstream dev / master<br>
> branches and instead favouring the use of stable branches?<br>
> Not really ideal if upstream can essentially break our builds without us<br>
> doing anything.<br>
<br>
I can't comment on NeoChat, but for Itinerary the builds against the latest <br>
versions of essential (external) dependencies with varying intentions/success <br>
in keeping backward compatibility (ZXing, Poppler, Quotient) are very much <br>
deliberate, to catch breakage/regressions early (same as we are now doing for <br>
KF with Qt pre-releases).<br>
<br>
And this is actually working, NeoChat has been fixed to build with the upcoming <br>
Quotient version, same for Itinerary/Poppler. The only thing we are missing <br>
for those fixes to take effect is those dependencies bumping their version <br>
numbers.<br>
<br>
We could work around that by doing configure-time detection using a compile <br>
test, but that's a lot of extra work, so we'd better try to address this <br>
upstream first. </blockquote><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
I'd very much suggest the use of release tarballs (or stable branches) for <br>
apps that aren't continuously monitoring their dependencies this way though, <br>
but I'm not aware we have such a case.<br></blockquote><div><br></div><div>Doesn't this interfere somewhat with the long term eventual goal of us pushing Flatpak binaries directly to Flathub though?</div><div>(not to mention make stable branch builds impossible to reproduce in the long run)</div><div> </div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Regards,<br>
Volker</blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>