Re: KDE Gear projects with failing CI (master + stable) (11 August 2026)
Ben Cooksley <[email protected]>
| Newsgroups | gmane.comp.kde.devel.general |
|---|---|
| Message-ID | <CA+XidOGbsJywcoXrW2CZz27xZ2jhQE0hu+C1UUvNz0nokcNc6A@mail.gmail.com> |
On Sat, Aug 15, 2026 at 10:21 AM Albert Astals Cid <[email protected]> wrote: > 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 <[email protected]> > 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 <[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? > > > > 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. > No such thing as a CDN that doesn't have a North American presence. For our users and contributors in certain parts of the world, CDNs are very much necessary if you want to have decent download speeds. They're also essential from an overall infrastructure perspective, ensuring that delivery of content such as this is scalable and manageable. > > > 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 > Cheers, Ben > > > > > 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 > > > > >