KDE Gear projects with failing CI (master + stable) (11 August 2026)

[Justin Zobel]

On 13/8/26 09:12, Albert Astals Cid wrote:
> El dimecres, 12 d’agost del 2026, a les 9:41:28 (Hora d’estiu d’Europa
> central), Ben Cooksley va escriure:
>> On Wed, Aug 12, 2026 at 1:48 PM Justin Zobel<justin at 1707.io> wrote:
>>> On 12/8/26 07:38, Albert Astals Cid wrote:
>>>
>>> Please work on fixing them, otherwise i will remove the failing CI jobs on
>>> their 4th failing week, it is very important that CI is passing for
>>> multiple reasons.
>>>
>>>
>>> Good news: 3 repo fixed
>>>
>>>
>>> Bad news: 11 repo started failing, 1 repo still failing
>>>
>>>
>>> ark - LAST WEEK BEFORE REMOVAL
>>>
>>>   *https://invent.kde.org/utilities/ark/-/pipelines/1316715 (stable)
>>>   
>>>    * clang format job tries to use non existing clang format?
>>>
>>> Cherry-picking the commit from master will fix this:
>>> https://invent.kde.org/utilities/ark/-/merge_requests/341
>>>
>>> neochat - NEW
>>>
>>>   *https://invent.kde.org/network/neochat/-/pipelines/1314808
>>>   
>>>    * flatpak fails to compile
>>>
>>> Note: Stable branch. Hopefully fixed by
>>> https://invent.kde.org/network/neochat/-/merge_requests/2971
>>>
>>> calindori - NEW
>>>
>>>   *https://invent.kde.org/plasma-mobile/calindori/-/pipelines/1316547
>>>   
>>>    * flatpak fails to compile
>>>
>>> Calindori uses git master KPeople and that requires extra-cmake-modules
>>> 6.29. Nightly Flatpak builds are increasingly hard to maintain at this
>>> point as they often require git master this and then that requires git
>>> master that. I need to talk to SysAdmin team about our new CI nodes and if
>>> we are able to start a truly nightly build of the Runtime/SDK to make this
>>> more feasible. Having moved the Qt 6.11 Runtime/SDK to Buildstream I
>>> believe this is a step towards this as Buildstream can uses caches to
>>> speed
>>> up rebuilds. As this is the first week of this I will leave it as is and
>>> start investigating.
>> The new CI nodes are standard boxes - ie. with only 64GB RAM - as CI
>> capacity is geared towards the bulk of the jobs we run on a day to day
>> basis (which are for our own software, which does not require a significant
>> amount of memory to build).
>>
>> Unfortunately the Flatpak Runtime build involves (or will in the future
>> involve) building QtWebEngine - which requires a significant amount of
>> memory to build and isn't something the standard build nodes can support.
>> We have two special build nodes that have an extended amount of memory
>> available, however each of those can only support one "high memory" build
>> at any given moment.
>>
>> The only builds that require extended RAM for builds are the Flatpak
>> Runtime, Craft Cache, Snap Core and Yocto Cache - all of which are
>> infrequently built items.
>>
>> Why is Calindori requiring master KPeople?
>>
>>> dolphin - NEW
>>>
>>>   *https://invent.kde.org/system/dolphin/-/pipelines/1316565 (stable)
>>>   
>>>    * flatpak fails because ffmpeg.org is down
>>>
>>> Someone has already retried this, and it is now succeeding.
>> This Flatpak needs to be reviewed please to ensure that we are not building
>> patent encumbered codecs. Judging by the log it may be including support
>> for those codecs.
>> It is a requirement that KDE software needs to be able to be distributed
>> through servers located in North America where this is legally problematic
>> - so that support must be removed/compiled out.
> When/Where was it discussed that we cave in to software patents?

I imagine this was discussed at the e.V. level as it relates to legal 
requirements, but I'd be interested in what our official policy is for 
what we can and cannot distribute.

It would also be nice if there was just a ffmpeg-libre and 
ffmpeg-DONTUSEMEUNLESSYOUHAVEMILLIONSFORLAWYERS.

>
> Cheers,
>    Albert
>
>> For guidance on this, please refer to the SUSE or Fedora packaging of
>> FFMpeg.
>>
>>> Cheers,
>>>
>>>    Albert
>>>
>>> Regards,
>>>
>>> Justin
>> Thanks,
>> Ben
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260813/b1857371/attachment.htm>