KDE Gear projects with failing CI (master + stable) (11 February 2026)
Nicolas Fella
nicolas.fella at gmx.de
Fri Feb 13 21:15:05 GMT 2026
On 2/13/26 9:53 PM, Nicolas Fella wrote:
> 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.
>
That said, all this seems to do is benchmark the performance of
QCryptographicHash, which is nonsensical here.
https://invent.kde.org/pim/kmbox/-/merge_requests/18
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260213/af058e56/attachment-0001.htm>
More information about the kde-devel
mailing list