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

Ben Cooksley <[email protected]> Tue, 30 Jun 2026 22:00:05 +1200
Newsgroups gmane.comp.kde.devel.general
Message-ID <CA+XidOHts1w1qR52BE=w5as-Z81=ROe_wD6r-L4PcCsGDqA32A@mail.gmail.com>
--00000000000013b77b065575a5b6
Content-Type: text/plain; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

On Sat, Jun 27, 2026 at 8:17=E2=80=AFPM Volker Krause <[email protected]> wro=
te:

> On Donnerstag, 25. Juni 2026 12:00:31 Mitteleurop=C3=A4ische Sommerzeit B=
en
> 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/15=
77
> 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.


>
> KAlarm OTOH shouldn't be that heavy for Windows, see
> https://invent.kde.org/
> packaging/craft-blueprints-kde/-/merge_requests/1579
> <https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/1=
579>
> for a suggested
> improvement.
>

Yes there do seem to be parts of PIM that unnecessarily have CD jobs
running on them, and removing unneeded deps helps.


>
> Regards,
> Volker


Cheers,
Ben

--00000000000013b77b065575a5b6
Content-Type: text/html; charset="UTF-8"
Content-Transfer-Encoding: quoted-printable

<div dir=3D"ltr"><div dir=3D"ltr"><span style=3D"background-color:transpare=
nt">On Sat, Jun 27, 2026 at 8:17=E2=80=AFPM Volker Krause &lt;<a href=3D"ma=
ilto:[email protected]">[email protected]</a>&gt; wrote:</span></div><div class=
=3D"gmail_quote gmail_quote_container"><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padd=
ing-left:1ex">On Donnerstag, 25. Juni 2026 12:00:31 Mitteleurop=C3=A4ische =
Sommerzeit Ben <br>
Cooksley wrote:<br>
&gt; &gt; kalarm - 2nd week<br>
&gt; &gt; <br>
&gt; &gt;=C2=A0 * <a href=3D"https://invent.kde.org/pim/kalarm/-/pipelines/=
1271931" rel=3D"noreferrer" target=3D"_blank">https://invent.kde.org/pim/ka=
larm/-/pipelines/1271931</a><br>
&gt; &gt;=C2=A0 <br>
&gt; &gt;=C2=A0 =C2=A0* craft windows job timed out<br>
&gt; &gt; <br>
&gt; &gt; kontact - 2nd week<br>
&gt; &gt; <br>
&gt; &gt;=C2=A0 * <a href=3D"https://invent.kde.org/pim/kontact/-/pipelines=
/1273055" rel=3D"noreferrer" target=3D"_blank">https://invent.kde.org/pim/k=
ontact/-/pipelines/1273055</a><br>
&gt; &gt;=C2=A0 * <a href=3D"https://invent.kde.org/pim/kontact/-/pipelines=
/1271145" rel=3D"noreferrer" target=3D"_blank">https://invent.kde.org/pim/k=
ontact/-/pipelines/1271145</a> (stable)<br>
&gt; &gt;=C2=A0 <br>
&gt; &gt;=C2=A0 =C2=A0* craft windows job ran out of memory<br>
&gt; <br>
&gt; Given the Craft jobs for both Kontact and KAlarm both rely on building=
 the<br>
&gt; entire PIM stack from scratch (due to the master requirement) i&#39;m =
not sure<br>
&gt; if keeping these builds is sustainable.<br>
&gt; Building all the PIM stack pieces takes the CI nodes the better part o=
f 40<br>
&gt; minutes or so (including signing) and we don&#39;t yet have a solution=
 to avoid<br>
&gt; that as far as i&#39;m aware.<br>
&gt; <br>
&gt; Can anyone from PIM comment as to whether other options are possible?<=
br>
<br>
Kontact is heavy, in the same league as other large applications struggling=
 <br>
with the 1h limit. The obvious optimizations (no tests, unity builds, etc) =
<br>
seem already be exhausted.<br></blockquote><div><br></div><div>*nod*. Somet=
hing that will need to be worked through - aside from Kontact the only othe=
r application i&#39;m aware of hitting this limit lately is Kdenlive?</div>=
<div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0px =
0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Moving more libraries to Frameworks helps a tiny bit, but that is a very sl=
ow <br>
process.=C2=A0 We have just done that with KMime, the full impact on Craft =
isn&#39;t <br>
there yet though, needs at least <a href=3D"https://invent.kde.org/packagin=
g/craft-blueprints-kde/-/merge_requests/1577" rel=3D"noreferrer" target=3D"=
_blank">https://invent.kde.org/packaging/craft-blueprints-kde/-/merge_reque=
sts/1577</a> still.<br>
<br>
This wont really help with the most heavy parts though, things like message=
lib <br>
are essentially KMail.<br></blockquote><div><br></div><div>Makes sense.</di=
v><div><br></div><div>This particular build is failing due to Itinerary I b=
elieve which has some rather large CPP files that MSVC needs a significant =
amount of memory to build.</div><div>Don&#39;t suppose it would be easy to =
break those up into smaller, less problematic pieces?</div><div><br></div><=
div>The build VMs have 16GB RAM so they&#39;re reasonably well equipped.</d=
iv><div>=C2=A0</div><blockquote class=3D"gmail_quote" style=3D"margin:0px 0=
px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
KAlarm OTOH shouldn&#39;t be that heavy for Windows, see <a href=3D"https:/=
/invent.kde.org/packaging/craft-blueprints-kde/-/merge_requests/1579" rel=
=3D"noreferrer" target=3D"_blank">https://invent.kde.org/<br>
packaging/craft-blueprints-kde/-/merge_requests/1579</a> for a suggested <b=
r>
improvement.<br></blockquote><div><br></div><div>Yes there do seem to be pa=
rts of PIM that unnecessarily have CD jobs running on them, and removing un=
needed deps helps.</div><div>=C2=A0</div><blockquote class=3D"gmail_quote" =
style=3D"margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);pa=
dding-left:1ex">
<br>
Regards,<br>
Volker</blockquote><div><br></div><div>Cheers,</div><div>Ben=C2=A0</div></d=
iv></div>

--00000000000013b77b065575a5b6--