Decommissioning Qt 5 CI

[Ben Cooksley]

On Fri, Jul 31, 2026 at 12:02 AM Kisaragi Hiu <mail at kisaragi-hiu.com> wrote:

> 2026/07/30 19:23 Ben Cooksley <bcooksley at kde.org>:
>
> Seems that some distributions are actually going ahead with full removal
> or have already done so which matches up with the view that it is well and
> truly dead?
>
>
> I do not get the feeling that it's "well and truly dead" at all from the
> thread; at least not yet. It seems very much still in the "people are
> working hard to put it to rest" stage.
>
> - Arch, Slackware, and FreeBSD all mention waiting on KDE to at least make
> releases for KDE apps that have already been ported but just haven't made a
> release after porting (kaffeine, kbibtex, krename, kronometer, kdesvn) or
> for more KDE apps to be ported (Okteta).
>

>From the perspective of CI, apps not being released is not a problem - as
CI is supporting future state not prior state.


> - Arch still ships VLC with Qt5 (but this is. probably not a problem? VLC
> already supports Qt6 now, right? If anything it shouldn't be hard to get
> VLC to fix its Qt6 support)
> - "Adelie Linux" notes "the most important Qt 5 software is Quassel IRC"
> and why it's used. The last commit is in June, the second last commit is
> from July 2025, so it's not quite active but not dead either. Though a
> porting effort does exist.
>

For all intents and purposes that sounds like Quassel is dead.


> - Gentoo has done full removal. For Okteta, they use the work/kossebau/kf6
> branch.
>   https://mail.kde.org/pipermail/distributions/2026-June/001705.html
>   https://packages.gentoo.org/packages/app-editors/okteta
>
> https://gitweb.gentoo.org/repo/gentoo.git/tree/app-editors/okteta/okteta-0.26.60_pre20260628.ebuild
> - Ubuntu is moving towards removal but hasn't done so yet even in the
> 26.10 branch.
>   https://packages.ubuntu.com/stonking/okteta
>
>
> This feels like quite a bit of effort being justified for a few small
> pieces of software that will only be used by a small number of applications
> (as most have ported) that are themselves legacy and likely to have
> maintenance issues (because otherwise they'd be ported already).
>
> In my view, the expense of maintaining Qt 5 support for that very small
> handful of Plasma projects is not particularly well justified.
>
>
> While I understand why we want to move on from Qt5, if we do it now it
> should be done with the understanding that it's not zero impact. It's
> probably still worth it, but then the last unported-but-still-wanted or
> ported-but-unreleased KDE apps should still be resolved first.
>
> Specifically: kaffeine, kbibtex, krename, kronometer, kdesvn, and maybe
> systemdgenie[1] are ported but unreleased and need a release; Okteta is not
> ported yet but probably still wanted (ie. can't just deprecate Okteta). If
> the desire to decommission now is high, that should be turned into a desire
> to release what's been ported and port + release Okteta first.
>

The removal of Qt 5 CI was well telegraphed with an initial sunset planned
for September last year that was pushed back because people "needed more
time".
I don't see any reason why we should keep extending this - there are no
longer releases of Frameworks being made to support Qt 5, and Qt 5 itself
is out of even extended security support upstream.


>
> [1]: I got this list from looking at which packages depend on kcoreaddons5
> in Arch
> https://archlinux.org/packages/extra/x86_64/kcoreaddons5/
>
> Best regards,
> Kisaragi Hiu
>

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/release-team/attachments/20260731/14af5388/attachment.htm>