<div dir="ltr"><div dir="ltr">On Wed, Jun 4, 2025 at 8:17 AM Albert Astals Cid <<a href="mailto:aacid@kde.org">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 dimarts, 3 de juny del 2025, a les 11:42:08 (Hora d’estiu d’Europa <br>
central), Ben Cooksley va escriure:<br>
> On Tue, Jun 3, 2025 at 9:03 AM Albert Astals Cid <<a href="mailto:aacid@kde.org" target="_blank">aacid@kde.org</a>> wrote:<br>
> > El dilluns, 2 de juny del 2025, a les 13:39:21 (Hora d’estiu d’Europa<br>
> > <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<br>
> > <br>
> > session<br>
> > <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<br>
> > > 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<br>
> > > impacts<br>
> > > the build queue for those platforms.<br>
> > > <br>
> > > The need to have dedicated VMs for FreeBSD and Windows on our builders<br>
> > <br>
> > also<br>
> > <br>
> > > makes setting up of a CI build node for KDE software a more complicated<br>
> > <br>
> > and<br>
> > <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<br>
> > > 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<br>
> > <br>
> > takes<br>
> > <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<br>
> > <br>
> > integrated<br>
> > <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<br>
> > > 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<br>
> > > 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<br>
> > <br>
> > certain<br>
> > <br>
> > > builds however that will be on request only and would need to be<br>
> > <br>
> > justified<br>
> > <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<br>
> > > 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<br>
> > <br>
> > wish<br>
> > <br>
> > > to run any of those images (say for FreeBSD or Android), although you<br>
> > <br>
> > will<br>
> > <br>
> > > need to setup libvirt yourself (SUSE has very good instructions for<br>
> > > this,<br>
> > > Debian less so as their instructions lack installing the packages needed<br>
> > <br>
> > to<br>
> > <br>
> > > provide UEFI and TPM support). The tooling itself was merged this<br>
> > > 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">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<br>
> > <br>
> > packages<br>
> > <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<br>
> > <br>
> > unmaintained<br>
> > <br>
> > > for some time. For FreeBSD and SUSE a significant number of packages<br>
> > > have<br>
> > > been removed - which in the case of SUSE also includes packages needed<br>
> > > to<br>
> > > support the building of KJS.  Accordingly, because builds of Frameworks<br>
> > <br>
> > are<br>
> > <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<br>
> > > the<br>
> > > transition to VM based CI.<br>
> > <br>
> > From previous discussions I had the impression this was only for things<br>
> > that<br>
> > wanted to create packages and not for "want to have CI to compile/run<br>
> > tests".<br>
> > <br>
> > Can you confirm you are proposng a total annihilation of Qt5 support in<br>
> > our<br>
> > CI?<br>
> <br>
> At the time we had that discussion it was still possible to build some of<br>
> the Qt 5 images, however that is no longer the case - all of them now fail<br>
> to build.<br>
> <br>
> In the case of the suse-qt515 image, the removal of libpcre in SUSE means<br>
> it is no longer possible to build KJS.<br>
> Consequently, we're no longer able to build all Frameworks (making 'kf5'<br>
> branch CI for Frameworks non-functional) so there isn't much point in<br>
> looking further to support Qt 5 on Linux.<br>
> <br>
> For FreeBSD the story is much the same as SUSE - packages are being removed<br>
> as apps upgrade to Qt 6 and the Qt 5 version of libraries becomes surplus<br>
> to requirements.<br>
> <br>
> For Windows the continued operation of that CI has only been possible<br>
> because our existing images are still around - new ones cannot be built.<br>
> That has been the case for a significant amount of time now, and it is not<br>
> worth the investment to fix it as everyone who works on Windows has moved<br>
> on to Qt 6.<br>
> <br>
> In essence there is little we can do to keep this alive - distributions are<br>
> removing support so we must follow suit.<br>
> <br>
> The correct course of action is to accelerate the porting of the remaining<br>
> applications, not to delay and keep Qt 5 alive.<br>
<br>
As Nico said, we can just not build KJS/KHTML and then give the projects that <br>
still use Qt5 a reasonable timeframe for them to port to Qt6, e.g. until the <br>
end of the year, not until the end of the month.<br></blockquote><div><br></div><div><div>Depending on how projects have written their .kde-ci.yml files, this will either work fine or fail so a degree of rewriting of those files may be needed.</div><div>But it could be tried - it is very much keeping something on true last gasp life support though and isn't going to be pleasant to maintain as things are going to keep disappearing.</div><div><br></div><div>My concern is that if we keep pushing out terminating support those projects will just keep deferring their porting. </div><div>Note that Frameworks 6 released in Feb 2024, so they've had 15 months so far to port which is a pretty reasonable amount of time.</div></div><div><br></div><div>Can we at least go through and remove Qt 5 CI from anything that has ported over and is running both currently?</div><div>Given we're now unable to build them we should probably declare KHTML and KJS unmaintained and archive them as well.</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>
> > Cheers,<br>
> > <br>
> >   Albert<br>
> <br>
> Regards,<br>
> Ben<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>