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

[Nicolas Fella]

On 2/13/26 9:24 PM, Ben Cooksley wrote:
> On Thu, Feb 12, 2026 at 1:09 PM Albert Astals Cid <aacid at kde.org> 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: 2 repo fixed
>
>
>     Bad news: 5 repo started failing, 1 keeps failing
>
>
>     kontact - LAST WEEK BEFORE REMOVAL
>      * https://invent.kde.org/pim/kontact/-/pipelines/1162355
>       * Craft Windows job running out of memory
>
>
> PIM folks, could we resolve this for now by dropping KItinerary 
> support in Craft Windows builds, or at the very least only target a 
> release build of KItinerary?
> In a cache build we are running in a High Memory VM which will have 
> the resource to get through building this so the fix to this is stop 
> rebuilding the whole PIM stack....
>
>
>
>     kdenlive - NEW
>      * https://invent.kde.org/multimedia/kdenlive/-/pipelines/1162146
>       * macos fails to compile
>
>
>     kosmindoormap - NEW
>      * https://invent.kde.org/libraries/kosmindoormap/-/pipelines/1161455
>      *
>     https://invent.kde.org/libraries/kosmindoormap/-/pipelines/1161715
>     (stable)
>       * Android build seems to be using the wrong binary format?
>     cross-compilation issue?
>
>
>     neochat - NEW
>      * https://invent.kde.org/network/neochat/-/pipelines/1162323 (stable)
>       * flatpak build fails
>
>
> Not sure why a stable branch is building against master of 
> libquotient, but seems like 
> https://invent.kde.org/network/neochat/-/commit/8ca1b8b1d387838fde1c1c448e5d2fe3a077a6e2 
> needs to be cherry picked if that is intended?
>
>
>
>     kgpg - NEW
>      * https://invent.kde.org/utilities/kgpg/-/pipelines/1161149
>       * Timeout in kgpg-disable and kgpg-export
>
>
>     kmbox - NEW
>      * https://invent.kde.org/pim/kmbox/-/pipelines/1162163
>       * Timeout in mbox-mboxbenchmark
>
>
> This test seems to be sitting on the edge of whether it will pass or 
> not - Qt 6.11 only just passed by running in 57 seconds vs. the 
> timeout limit of 60 seconds.
> What is it trying to achieve and why so many iterations?
I don't follow what's going on there.

Locally that benchmark finishes in ~1 second here, so no problem whatsoever.

On CI the first two sub-benchmarks seem completely fine, but 
voidTestMD5Performance seems to hand/time out. It's not clear to me how 
many iterations it does.

It looks like QBENCHMARK automatically adjusts the number of iterations 
until the results are "good" (whatever that exactly means). Possibly 
some CI conditions trigger that to go haywire.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260213/e732677b/attachment.htm>