<div dir="ltr"><div dir="ltr">On Sun, Dec 1, 2024 at 10:04 AM Ingo Klöcker <<a href="mailto:kloecker@kde.org">kloecker@kde.org</a>> wrote:</div><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On Samstag, 30. November 2024 11:51:51 Mitteleuropäische Normalzeit Albert <br>
Astals Cid wrote:<br>
> El dissabte, 30 de novembre del 2024, a les 4:57:10 (Hora estàndard del<br>
> Centre<br>
> d’Europa), Ben Cooksley va escriure:<br>
> > HI all,<br>
> > <br>
> > This past week or so i've been dealing with a number of issues relating to<br>
> > a handful of still Qt 5 based projects trying to make use of updated<br>
> > dependencies. These issues have revealed that the level of support for Qt<br>
> > 5<br>
> > as a platform in general is now subject to a significant degree of<br>
> > bit-rot.<br>
> > As such, we need to set a point at which we consider Qt 5 to no longer be<br>
> > supported.<br>
> > <br>
> > To start I would like to remove support for all CD builds (Windows,<br>
> > Appimage, macOS) as well as CI support for Windows. There is already a<br>
> > general view in Craft that Qt 5 is unmaintained and this removal simply<br>
> > reflects that.<br>
> <br>
> If the Craft maintainers don't want to maintain Qt5 and no one steps up I<br>
> guess that's understandable.<br>
<br>
The qt5-lts branch of Craft is no longer maintained officially since months. <br>
Those few projects who still use this branch mostly know how to deal with this <br>
and do the work themselves. As such it's IMHO unfair and untrue to say that Qt <br>
5 is unmaintained in Craft. It's just not maintained anymore by Hannah, Julius <br>
and others who maintain the Qt 6 branches of Craft.<br>
<br>
Many of the projects which still do Qt 5 based releases on Windows are <br>
lighthouse projects, e.g. Kdenlive, KMyMoney, KStars. I don't think pulling <br>
the rug under their feet is fair. (I didn't forget Krita. They maintain their <br>
own CI/CD jobs as far as I know.)<br>
<br>
Isn't there a middle ground like keeping the last working Qt 5 CI images but <br>
not creating/updating them anymore? It's not as if the Qt 5 based projects <br>
would need to use the latest published Qt 5.15.x release or the latest <br>
versions of their other dependencies for patch releases. In the Craft builds <br>
they could still use newer versions of their dependencies but for CI the <br>
versions would be frozen.<br></blockquote><div><br></div><div>Unfortunately our Windows images, due to the size of Windows itself along with the SDKs, Visual Studio compiler, etc. are quite significant in size, so having this split approach doesn't really work as it means the better part of 20 GB+ of additional space is occupied on the builders. </div><div><br></div><div>It also means we are stuck in an essentially unmaintainable position as nothing can be rebuilt which is a position I don't generally like to be in. </div><div>Last time that happened and was unresolvable I fired the distribution in question from CI use and spent a chunk of time rebuilding on SUSE Tumbleweed (which is what we have today)</div><div><br></div><div>Likewise, some of these projects are unfortunately pushing ahead with wanting newer versions of Qt 5 based dependencies or are experiencing bit rot in existing versions as other parts of the underlying system update themselves. </div><div>We have already experienced this with:</div><div>- Microsoft pushing bad updates to MSVC 2019 (which I hacked around in <a href="https://invent.kde.org/sysadmin/ci-images/-/commit/1f7fb1f88d39216eb6d252416d0bfd5c6cbda937">https://invent.kde.org/sysadmin/ci-images/-/commit/1f7fb1f88d39216eb6d252416d0bfd5c6cbda937</a>)</div><div>- Unknown updates (likely in MSys2) breaking the build of MPFR (used by some of those lighthouse projects). As far as I can tell this is unfixable as it is happening somewhere in some autotools code that calls on MSVC.</div><div>- Bad upstream updates leading to a broken QXMPP build (used by Kaidan)</div><div><br></div><div>The second one means some of those lighthouse projects can't even make use of our CD capabilities anyway - as without MPFR they cannot be built. This also shows that we are not properly snapshotting / keeping MSys2 stable (which is another issue with how Craft works with MSys2)</div><div><br></div><div>QXMPP is a project that has caused CI maintainability issues in the past for me and appears to be making releases without regard to their own CI (which is failing currently).</div><div>Getting a little tired having QXMPP updates pushed through only for them to then cause CI failures on our end - see various reverts in <a href="https://invent.kde.org/packaging/craft-blueprints-kde/-/commits/master/qt-libs/qxmpp/qxmpp.py">https://invent.kde.org/packaging/craft-blueprints-kde/-/commits/master/qt-libs/qxmpp/qxmpp.py</a></div><div><br></div><div>Given all the above I reached the conclusion that trying to fix this is a hopeless cause and the best solution is just to retire it as unmaintained.</div><div><br></div><div>Not really sure if there is a path back from how broken this all is.</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>
I do agree that new feature releases which need the newest versions of some <br>
third-party dependencies should be Qt 6 based.<br>
<br>
Regards,<br>
Ingo<br></blockquote><div><br></div><div>Cheers,</div><div>Ben </div></div></div>