On Wed, Jul 1, 2026 at 4:55 AM Volker Krause <[email protected]> wrote:
> 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 <[email protected]> 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 > <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 > <https://invent.kde.org/packaging/craft-blueprints-kde/-/commit/4507061e1323a346598382b226e3f562c6638eb3> > . > Seems like a reasonable solution to disable it. That should be done by https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/1584 > > Best regards, > Volker Cheers, Ben
