KDE Gear projects with failing CI (master + stable) (23 June 2026)

[Volker Krause]

On Tuesday, 30 June 2026 12:00:05 Central European Summer Time Ben Cooksley 
wrote:
> On Sat, Jun 27, 2026 at 8:17 PM Volker Krause <vkrause at kde.org> wrote:
> > On Donnerstag, 25. Juni 2026 12:00:31 Mitteleuropäische Sommerzeit Ben
> > 
> > Cooksley wrote:
> > > > kalarm - 2nd week
> > > > 
> > > >  * https://invent.kde.org/pim/kalarm/-/pipelines/1271931
> > > >  
> > > >   * craft windows job timed out
> > > > 
> > > > kontact - 2nd week
> > > > 
> > > >  * https://invent.kde.org/pim/kontact/-/pipelines/1273055
> > > >  * https://invent.kde.org/pim/kontact/-/pipelines/1271145 (stable)
> > > >  
> > > >   * craft windows job ran out of memory
> > > 
> > > Given the Craft jobs for both Kontact and KAlarm both rely on building
> > 
> > the
> > 
> > > entire PIM stack from scratch (due to the master requirement) i'm not
> > 
> > sure
> > 
> > > if keeping these builds is sustainable.
> > > Building all the PIM stack pieces takes the CI nodes the better part of
> > 
> > 40
> > 
> > > minutes or so (including signing) and we don't yet have a solution to
> > 
> > avoid
> > 
> > > that as far as i'm aware.
> > > 
> > > Can anyone from PIM comment as to whether other options are possible?
> > 
> > Kontact is heavy, in the same league as other large applications
> > struggling
> > with the 1h limit. The obvious optimizations (no tests, unity builds, etc)
> > seem already be exhausted.
> 
> *nod*. Something that will need to be worked through - aside from Kontact
> the only other application i'm aware of hitting this limit lately is
> Kdenlive?
> 
> > Moving more libraries to Frameworks helps a tiny bit, but that is a very
> > slow
> > process.  We have just done that with KMime, the full impact on Craft
> > isn't
> > there yet though, needs at least
> > https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/157
> > 7
> > still.
> > 
> > This wont really help with the most heavy parts though, things like
> > messagelib
> > are essentially KMail.
> 
> Makes sense.
> 
> This particular build is failing due to Itinerary I believe which has some
> rather large CPP files that MSVC needs a significant amount of memory to
> build.
> Don't suppose it would be easy to break those up into smaller, less
> problematic pieces?
> 
> The build VMs have 16GB RAM so they're reasonably well equipped.

There is one particularly large file (https://invent.kde.org/pim/kitinerary/-/
blob/master/src/lib/knowledgedb/trainstationdb_data.cpp), which I would like 
to see split up as well, but that's not entirely straightforward.

However, it looks like it's not choking on that one, but rather consistently 
on https://invent.kde.org/pim/kitinerary/-/blob/master/src/lib/era/
fcbticket3.h (or any of it's similar siblings). That isn't particularly large 
(1k lines), but contains some compile-time computation magic behind the 
harmless looking macros. Breaking this up is not entirely impossible either, 
but it would be rather inconvenient as those files are more or less a 1:1 
translation of official specifications and match their structure.

Instead I would (again) suggest to disable the itinerary plugin for KMail on 
Windows, which is the only reason this is built. As Itinerary itself isn't 
available for Windows and as the KDE Connect integration in the plugin is not 
compatible with KDE Connect on Windows, two thirds of its functionality are 
not available there anyway.

Ie. revert https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/
4507061e1323a346598382b226e3f562c6638eb3.

Best regards,
Volker
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-devel/attachments/20260630/a23b8777/attachment.sig>