<!DOCTYPE html>
<html>
<head>
<meta http-equiv="Content-Type" content="text/html; charset=UTF-8">
</head>
<body>
<div class="moz-cite-prefix">Am 03.06.25 um 11:42 schrieb Ben
Cooksley:<br>
</div>
<blockquote type="cite"
cite="mid:CA+XidOG51FFeCdw+uxg_XOnuLNeJkQKpaJOw83TUDdyMSZM-dQ@mail.gmail.com">
<meta http-equiv="content-type" content="text/html; charset=UTF-8">
<div dir="ltr">
<div dir="ltr">On Tue, Jun 3, 2025 at 9:03 AM Albert Astals Cid
<<a href="mailto:aacid@kde.org" moz-do-not-send="true"
class="moz-txt-link-freetext">aacid@kde.org</a>> wrote:</div>
<div class="gmail_quote gmail_quote_container">
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">El
dilluns, 2 de juny del 2025, a les 13:39:21 (Hora d’estiu
d’Europa <br>
central), Ben Cooksley va escriure:<br>
> Hi all,<br>
> <br>
> For some time now we have had a variety of issues with
our Docker/Podman<br>
> based CI builds. These have included the lack of GUI
test support on<br>
> Windows, periodic crashes on FreeBSD, poor IO
performance of Windows<br>
> builds, issues supporting builds for Flatpak and Snaps
and inability to<br>
> support either builds or tests where elevated
privileges or system session<br>
> resources are needed.<br>
> <br>
> In addition to this we've had issues where Linux CI
builds have the<br>
> capability to trigger OOM events on the CI hosts, which
in turn takes out<br>
> Windows and (less often) FreeBSD builders. While this
does not occur too<br>
> often, it does happen from time to time and eventually
negatively impacts<br>
> the build queue for those platforms.<br>
> <br>
> The need to have dedicated VMs for FreeBSD and Windows
on our builders also<br>
> makes setting up of a CI build node for KDE software a
more complicated and<br>
> time intensive task than it otherwise needs to be (and
means that the<br>
> amount of systems to care for increases by 3 for every
CI node we add).<br>
> <br>
> While individually relatively minor, together these
issues more than<br>
> justify making a significant change to the way we run
our CI system - in<br>
> this case transitioning from container based builds to
VM based builds.<br>
> <br>
> These builds will still take place on dedicated
hardware that we control,<br>
> however instead of taking place within a container
(managed by Podman on<br>
> Linux and FreeBSD, or Docker on Windows) they will
instead take place<br>
> within a VM using a copy-on-write disk image.<br>
> VM based builds will unfortunately take a little longer
to start (it takes<br>
> ~10 seconds for a VM from any of Linux, FreeBSD or
Windows to boot on my<br>
> personal system) however the benefits we gain should
more than outweigh<br>
> this small downside.<br>
> <br>
> This has been under development for the past couple of
weeks and is now<br>
> reaching the point where the only remaining steps are
to get it integrated<br>
> with the Gitlab CI agent (gitlab-runner) for which
prototype code is<br>
> already in place, and complete porting of our images
over. Once that<br>
> happens a complete rebuild of all of our builders will
be swiftly<br>
> undertaken to transition them completely over to the
new VM based<br>
> infrastructure.<br>
> <br>
> Specs wise, at this time it is planned for each spawned
standard VM to be<br>
> provided with 2/3's of the system CPU cores (so 12
cores), 16GB RAM and<br>
> 100GB of disk space (although some of that will be
occupied by the system<br>
> image - approximately 10GB for standard Linux builds
and ~30GB or so for<br>
> Windows builds). There will be a higher resource tier
available for certain<br>
> builds however that will be on request only and would
need to be justified<br>
> (such as Craft needing to build QtWebEngine).<br>
> <br>
> As launching VMs is not the most efficient approach for
all workloads,<br>
> limited support for running Docker containers will be
preserved, however<br>
> this support is primarily intended for running linters,
sanity checks and<br>
> website builds, and is not intended for running general
CI/CD builds.<br>
> <br>
> The tooling used by the CI nodes to run VMs is
something that should be<br>
> fairly trivial for people to run on their own local
system should they wish<br>
> to run any of those images (say for FreeBSD or
Android), although you will<br>
> need to setup libvirt yourself (SUSE has very good
instructions for this,<br>
> Debian less so as their instructions lack installing
the packages needed to<br>
> provide UEFI and TPM support). The tooling itself was
merged this evening<br>
> to sysadmin/ci-images (vm-common/ folder) and can be
used with the VM<br>
> images found at <a
href="https://storage.kde.org/vm-images/" rel="noreferrer"
target="_blank" moz-do-not-send="true"
class="moz-txt-link-freetext">https://storage.kde.org/vm-images/</a><br>
> <br>
> There is however one downside to this - Qt 5 support.<br>
> <br>
> Over the past few months distributions have been
steadily removing packages<br>
> and other supporting infrastructure needed to keep Qt 5
builds alive. In<br>
> the case of Windows, support for the entire Qt 5 tree
has been unmaintained<br>
> for some time. For FreeBSD and SUSE a significant
number of packages have<br>
> been removed - which in the case of SUSE also includes
packages needed to<br>
> support the building of KJS. Accordingly, because
builds of Frameworks are<br>
> a first stepping stone to support building anything
else, it will not be<br>
> possible for us to produce Qt 5 based VM build images
for any of the 3<br>
> platforms.<br>
> <br>
> We will therefore have to remove Qt 5 support from the
CI system with the<br>
> transition to VM based CI.<br>
<br>
From previous discussions I had the impression this was only
for things that <br>
wanted to create packages and not for "want to have CI to
compile/run tests".<br>
<br>
Can you confirm you are proposng a total annihilation of Qt5
support in our <br>
CI?<br>
</blockquote>
<div><br>
</div>
<div>At the time we had that discussion it was still possible
to build some of the Qt 5 images, however that is no longer
the case - all of them now fail to build.</div>
<div><br>
</div>
<div>In the case of the suse-qt515 image, the removal of
libpcre in SUSE means it is no longer possible to build KJS.</div>
<div>Consequently, we're no longer able to build all
Frameworks (making 'kf5' branch CI for Frameworks
non-functional) so there isn't much point in looking further
to support Qt 5 on Linux.</div>
</div>
</div>
</blockquote>
<p>Not that I have much sympathy left for Qt5, but wouldn't it be
possible to exclude kjs and keep the remaining frameworks? I don't
think any of the unported projects need kjs anyway.<br>
</p>
<p><br>
</p>
<blockquote type="cite"
cite="mid:CA+XidOG51FFeCdw+uxg_XOnuLNeJkQKpaJOw83TUDdyMSZM-dQ@mail.gmail.com">
<div dir="ltr">
<div class="gmail_quote gmail_quote_container">
<div>
<div>For FreeBSD the story is much the same as SUSE -
packages are being removed as apps upgrade to Qt 6 and the
Qt 5 version of libraries becomes surplus to requirements.</div>
</div>
<div><br>
</div>
<div>For Windows the continued operation of that CI has only
been possible because our existing images are still around -
new ones cannot be built.</div>
<div>That has been the case for a significant amount of time
now, and it is not worth the investment to fix it as
everyone who works on Windows has moved on to Qt 6.</div>
<div><br>
</div>
<div>In essence there is little we can do to keep this alive -
distributions are removing support so we must follow suit.</div>
<div><br>
</div>
<div>The correct course of action is to accelerate the porting
of the remaining applications, not to delay and keep Qt 5
alive.</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
Cheers,<br>
Albert<br>
</blockquote>
<div><br>
</div>
<div>Regards,</div>
<div>Ben</div>
<div> </div>
<blockquote class="gmail_quote"
style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">
<br>
> <br>
> Please let me know if there are any questions on the
above.<br>
> <br>
> Thanks,<br>
> Ben<br>
<br>
<br>
<br>
<br>
</blockquote>
</div>
</div>
</blockquote>
</body>
</html>