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

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 <[email protected]> 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?

Cheers,
  Albert

> 
> For guidance on this, please refer to the SUSE or Fedora packaging of
> FFMpeg.
> 
> > Cheers,
> > 
> >   Albert
> > 
> > Regards,
> > 
> > Justin
> 
> Thanks,
> Ben