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

[Albert Astals Cid]

El divendres, 14 d’agost del 2026, a les 12:06:34 (Hora d’estiu d’Europa 
central), Ben Cooksley va escriure:
> On Thu, Aug 13, 2026 at 11:42 AM Albert Astals Cid <aacid at kde.org> 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?
> 
> There is no discussion, it is a reality reflective of the fact that we make
> use of Content Distribution Networks (CDNs) and mirrors for hosting both
> the source code and binaries of our software.
> Some of those CDNs have points of presence (POPs) or are headquartered in
> jurisdictions that enforce software patents. The same applies to our
> mirrors.

If using those CDNs means we have to enfornce software patents, we should stop 
using those CDNs.

> The same applies to binaries we publish to software stores such as the
> Windows Store or Google Play, as well as Flathub (Flathub binaries are
> distributed using CDN infrastructure provided by Fastly, which is an
> American company).

That's a totally different story, if we playi in someone elses house, sure 
there we have to obey their rules.

Cheers,
  Albert

> 
> We therefore need to ensure that the resulting binaries we generate comply
> with the terms of those patents.
> 
> As much as we may wish it possible, distributing our software purely out of
> Europe is simply not practical, as North American (both US and Canadian)
> ISPs do not purchase sufficient international transit as the vast majority
> of their traffic is domestic/within North America. This results in a very
> poor experience in terms of download speeds for North American users if you
> do not have mirrors or CDN POPs within North America.
> 
> > Cheers,
> > 
> >   Albert
> 
> Cheers,
> Ben
> 
> > > For guidance on this, please refer to the SUSE or Fedora packaging of
> > > FFMpeg.
> > > 
> > > > Cheers,
> > > > 
> > > >   Albert
> > > > 
> > > > Regards,
> > > > 
> > > > Justin
> > > 
> > > Thanks,
> > > Ben