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

[Justin Zobel]

On 23/1/25 07:26, Albert Astals Cid wrote:
> 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
And this is generally the case with NeoChat as several of the main 
contributors also work on libquotient upstream.
>> 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