<div dir="ltr"><div dir="ltr">On Fri, Jan 24, 2025 at 4:44 PM Justin Zobel <<a href="mailto:justin@1707.io">justin@1707.io</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 24/1/25 02:55, Volker Krause wrote:<br>
> On Donnerstag, 23. Januar 2025 10:21:08 Mitteleuropäische Normalzeit Ben<br>
> Cooksley wrote:<br>
>> On Thu, Jan 23, 2025 at 7:21 AM Volker Krause <<a href="mailto:vkrause@kde.org" target="_blank">vkrause@kde.org</a>> wrote:<br>
>>> On Mittwoch, 22. Januar 2025 18:52:46 Mitteleuropäische Normalzeit Ben<br>
>>><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<br>
>>> 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>
>>>>> 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<br>
>>>>> 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<br>
>>> be to<br>
>>><br>
>>>>> have version bumps at the beginning of a development cycle that<br>
>>>>> changes<br>
>>>>> API.<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>
>>> I can't comment on NeoChat, but for Itinerary the builds against the<br>
>>> latest<br>
>>> versions of essential (external) dependencies with varying<br>
>>> 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<br>
>>> for<br>
>>> KF with Qt pre-releases).<br>
>>><br>
>>> And this is actually working, NeoChat has been fixed to build with the<br>
>>> upcoming<br>
>>> Quotient version, same for Itinerary/Poppler. The only thing we are<br>
>>> 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<br>
>>> compile<br>
>>> test, but that's a lot of extra work, so we'd better try to address this<br>
>>> upstream first.<br>
>>><br>
>>><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<br>
>>> though,<br>
>>> but I'm not aware we have such a case.<br>
>> Doesn't this interfere somewhat with the long term eventual goal of us<br>
>> pushing Flatpak binaries directly to Flathub though?<br>
>> (not to mention make stable branch builds impossible to reproduce in the<br>
>> long run)<br>
> For Itinerary at least the release branch is using release tarballs rather<br>
> than (latest) Git branches, matching what we have on Flathub. (This does imply<br>
> some manual work at branch time, but at least for me that's more than offset by<br>
> what this saves in catching issues early).<br>
><br>
> But you are right of course that this is abusing Flatpak a bit as CI. That's<br>
> not ideal but it's just very tempting as it has minimal extra cost (Flatpak<br>
> has to build those dependencies anyway, and Flatpak builds run less often than<br>
> normal CI builds).<br>
><br>
> Regards,<br>
> Volker<br>
<br>
I've moved this to a new email subject as it's no longer just about <br>
failing CI builds.<br>
<br>
My proposal would be have 3 files in the repository that are Flatpak <br>
related:<br>
<br>
- .flatpak-manifest.yml will continue to exist for git master builds and <br>
be deployed to <a href="https://cdn.kde.org/flatpak/" rel="noreferrer" target="_blank">https://cdn.kde.org/flatpak/</a><br>
<br>
- org.kde.appname.json which will be for Flathub stable builds will only <br>
run on release branches when a tag is made (I am hoping CI can be <br>
triggered by a tag).<br>
<br>
- Both will reference a file called org.kde.appname.dependencies.json <br>
which contains the the dependencies that get build for the app and will <br>
point to tarballs or tags for released versions.<br></blockquote><div><br></div><div>Not sure how that solves the issue?  Currently the issue is the version of the dependencies - with us using master / equivalent branches in our Flatpak jobs.</div><div>Having a shared file for that would ensure that impacts Flathub builds or other stable builds we run as well.</div><div><br></div><div>I had been thinking that having a separate file that would be used instead of .flatpak-manifest.yml if present when doing a build on a stable branch would be a good solution.</div><div>Under this you would have a .flatpak-manifest.yml and a .flatpak-manifest-stable.yml file</div><div><br></div><div>When building on master the .flatpak-manifest.yml file would be used, but when on a release branch / tag the .flatpak-manifest-stable.yml file would be used instead (if present).</div><div><br></div><div>That would eliminate needing the release manager / developer to update .flatpak-manifest.yml on branching a new stable release branch.</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Flatpak supports referencing external files for build dependencies and <br>
you can use JSON or YAML interchangeably.<br>
<br>
I think this will be good for Flatpak builds as we really want them <br>
targeting the stable released tarballs, not some function in git master <br>
of a dependency that *MIGHT* be released in time for the next KDE release.<br>
<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>