From kristen at kde.org  Mon Jul  6 16:17:17 2026
From: kristen at kde.org (Kristen McWilliam)
Date: Mon, 6 Jul 2026 11:17:17 -0400
Subject: Plasma CI Health Check (July 6, 2026)
Message-ID: <757a6ac1-8975-4aa3-b091-f3c61a5d46fe@kde.org>

Please work on fixing CI that is failing in master, I will 
remove/disable any on their 4th week failing. It is very important that 
CI is passing.

• 94 monitored repos
• 3 failing CI in master
• 2 configured for auto-repeating tests
• 82% of repos configured to require passing tests

Good news: 3 repos fixed

Bad news: 1 repo still failing, 2 new repos started failing

plasma/kdeplasma-addons - 2nd week
https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657 
<https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657>

plasma/plasma-activities - NEW
https://invent.kde.org/plasma/plasma-activities/-/pipelines/1284660 
<https://invent.kde.org/plasma/plasma-activities/-/pipelines/1284660>

plasma/plasma-systemmonitor - NEW
https://invent.kde.org/plasma/plasma-systemmonitor/-/pipelines/1284683 
<https://invent.kde.org/plasma/plasma-systemmonitor/-/pipelines/1284683>

Auto-retrying tests:
• kwin
• plasma-desktop

KDE CI Dashboard:
https://ci-healthcheck-5e5c80.local-kde.org/ 
<https://ci-healthcheck-5e5c80.local-kde.org/>


-- 
Cheers,
   Kristen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260706/13b4fcfe/attachment.htm>

From bshah at kde.org  Tue Jul  7 14:52:47 2026
From: bshah at kde.org (Bhushan Shah)
Date: Tue, 07 Jul 2026 19:22:47 +0530
Subject: KDE Plasma 6.6.6 bugfix release now available
Message-ID: <oyvA9UO2RVGbeVJoa_r2pQ@kde.org>

Hello all,

Plasma 6.6.6 bugfix release is now available.

https://kde.org/announcements/plasma/6/6.6.6/

Please note that this is last release in 6.6.x cycle.

PS: If you were watching download.kde.org and website, you might have noticed 
6.6.6 release becoming available and then going away today. This was because 
mistake when doing release and it was reverted and re-created.

If you face unexpected build failures or download failures, please let me 
know.

Best Regards,
Bhushan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260707/869674e0/attachment.sig>

From bshah at kde.org  Thu Jul  9 12:51:23 2026
From: bshah at kde.org (Bhushan Shah)
Date: Thu, 09 Jul 2026 17:21:23 +0530
Subject: Plasma kpipewire 6.6.6.1 update
Message-ID: <axqWvfjDQNyduieR3cAC7w@kde.org>

There has been an update to Plasma 6.6.6

kpipewire now has kpipewire-6.6.6.1 tar available to download for packaging
sha256sum: c357ffb467301b650ee77ff670da33a97a4e203557d2f8790e40449a2173ecd8 Git 
commit: f557f81540fda73d6df7bbf2479d5111337fdba0

https://kde.org/info/plasma-6.6.6/

This is to fix regression with ABI compatibility.

Best Regards,
Bhushan 
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 488 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260709/1528c95c/attachment.sig>

From kristen at kde.org  Mon Jul 13 16:37:03 2026
From: kristen at kde.org (Kristen McWilliam)
Date: Mon, 13 Jul 2026 11:37:03 -0400
Subject: Plasma CI Health Check (July 13, 2026)
Message-ID: <117594d0-2afe-4654-a526-5369709581cf@kde.org>

Please work on fixing CI that is failing in master, I will 
remove/disable any on their 4th week failing. It is very important that 
CI is passing.

• 89 monitored repos
• 3 failing CI in master
• 2 configured for auto-repeating tests
• 87% of repos configured to require passing tests

Good news: 2 repos fixed

Bad news: 1 repo still failing, 2 new repos started failing

plasma/kdeplasma-addons - 3rd week
https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657 
<https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657>

plasma/plasma-workspace - NEW
https://invent.kde.org/plasma/plasma-workspace/-/pipelines/1290636 
<https://invent.kde.org/plasma/plasma-workspace/-/pipelines/1290636>

plasma-mobile/plasma-camera - NEW
https://invent.kde.org/plasma-mobile/plasma-camera/-/pipelines/1290615 
<https://invent.kde.org/plasma-mobile/plasma-camera/-/pipelines/1290615>

Auto-retrying tests:
• kwin
• plasma-desktop

KDE CI Dashboard:
https://ci-healthcheck-5e5c80.local-kde.org/ 
<https://ci-healthcheck-5e5c80.local-kde.org/>


-- 
Cheers,
   Kristen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260713/8cda44c3/attachment.htm>

From justin at 1707.io  Tue Jul 14 01:39:17 2026
From: justin at 1707.io (Justin Zobel)
Date: Tue, 14 Jul 2026 10:09:17 +0930
Subject: Plasma CI Health Check (July 13, 2026)
In-Reply-To: <117594d0-2afe-4654-a526-5369709581cf@kde.org>
References: <117594d0-2afe-4654-a526-5369709581cf@kde.org>
Message-ID: <2ce2325a-3605-450a-9d61-2047ef5cb186@1707.io>

On 14/7/26 01:07, Kristen McWilliam wrote:
>
> Please work on fixing CI that is failing in master, I will 
> remove/disable any on their 4th week failing. It is very important 
> that CI is passing.
>
> • 89 monitored repos
> • 3 failing CI in master
> • 2 configured for auto-repeating tests
> • 87% of repos configured to require passing tests
>
> Good news: 2 repos fixed
>
> Bad news: 1 repo still failing, 2 new repos started failing
>
> plasma/kdeplasma-addons - 3rd week
> https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657 
> <https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1284657>
>
> plasma/plasma-workspace - NEW
> https://invent.kde.org/plasma/plasma-workspace/-/pipelines/1290636 
> <https://invent.kde.org/plasma/plasma-workspace/-/pipelines/1290636>
>
> plasma-mobile/plasma-camera - NEW
> https://invent.kde.org/plasma-mobile/plasma-camera/-/pipelines/1290615 
> <https://invent.kde.org/plasma-mobile/plasma-camera/-/pipelines/1290615>
>
https://invent.kde.org/plasma-mobile/plasma-camera/-/merge_requests/56 
should fix this.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260714/a821966b/attachment.htm>

From bshah at kde.org  Tue Jul 14 13:42:52 2026
From: bshah at kde.org (Bhushan Shah)
Date: Tue, 14 Jul 2026 18:12:52 +0530
Subject: Plasma 6.7.3 is released
Message-ID: <AwOe7kJHS2C7zoctPQ1n1g@kde.org>

Hi all,

Please find 3rd bugfix release in Plasma 6.7.x series.

https://kde.org/announcements/plasma/6/6.7.3/

Best Regards,
Bhushan
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 484 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260714/cecc83ec/attachment.sig>

From kristen at kde.org  Mon Jul 20 21:28:16 2026
From: kristen at kde.org (Kristen McWilliam)
Date: Mon, 20 Jul 2026 16:28:16 -0400
Subject: Plasma CI Health Check (July 20, 2026)
Message-ID: <b3c794b3-1d9a-42f3-96ae-3aacb22c93fc@kde.org>

Please work on fixing CI that is failing in master, I will 
remove/disable any on their 4th week failing. It is very important that 
CI is passing.

• 86 monitored repos
• 1 failing CI in master
• 2 configured for auto-repeating tests
• 90% of repos configured to require passing tests


Good news: 2 repos fixed

Very bad news: 1 repo still failing after 4 weeks, offending test has 
been disabled


plasma/kdeplasma-addons - 4th week
https://invent.kde.org/plasma/kdeplasma-addons/-/pipelines/1296971
     keyboardindicatortest disabled


Auto-retrying tests:
     • kwin
     • plasma-desktop


KDE CI Dashboard:
https://ci-healthcheck-5e5c80.local-kde.org/

-- 
Cheers,
   Kristen


From nate at kde.org  Wed Jul 22 04:24:18 2026
From: nate at kde.org (Nate Graham)
Date: Tue, 21 Jul 2026 21:24:18 -0600
Subject: Magnification Performance Regression In KDE Plasma 6.7
In-Reply-To: <BL1PR14MB5143F99DABC35EC9AF9A5F9483C32@BL1PR14MB5143.namprd14.prod.outlook.com>
References: <BL1PR14MB5143F56847D9B198505CBD53837FA@BL1PR14MB5143.namprd14.prod.outlook.com>
 <d70fbf63-dbd1-4811-a532-bda059e6a0f1@kde.org>
 <BL1PR14MB5143F99DABC35EC9AF9A5F9483C32@BL1PR14MB5143.namprd14.prod.outlook.com>
Message-ID: <ddeb26f7-1309-483e-a287-cd9dc9aaa4ac@kde.org>

[dropping the KDE e.V. board and the kde-community, since this is a 
technical matter]

Hello Chase,

Can you see if it helps to disable the "Sharpen screen content while 
zoomed in" checkbox on the zoom settings page?

If that helps, please submit a bug report at 
https://bugs.kde.org/enter_bug.cgi?product=kwin&component=effects-various 
saying that the upscaling filter exhibits performance problems. Tag it 
with the "regression" keyword.

If it doesn't help, submit a bug report there anyway describing the 
problem itself.

Thanks!

Nate



On 7/20/26 12:46 PM, Chase Laird wrote:
> Hello Nate,
> 
> I hope you've been doing well.
> 
> I wanted to report an issue I've been experiencing with KDE Plasma's 
> magnification feature. I'm not sure how widespread this problem is, so 
> I'll include my system details to help define the scope.
> 
> On my system, enabling magnification has recently introduced significant 
> display lag on both the internal and external displays, with the issue 
> being especially noticeable on external monitors. The lag is most 
> apparent during animation-heavy tasks, such as panning zoom, scrolling 
> webpages, or swiping between virtual desktops. The virtual desktop 
> transition, in particular, appears almost to be in slow motion, making 
> the desktop feel sluggish and disrupting what was previously an 
> exceptionally smooth and responsive experience.
> 
> I'm not certain what introduced this regression, but I suspect it may be 
> related to a Plasma update from within the past month. My system is 
> running Arch Linux on a Dell XPS 13 2-in-1 9310. Notably, the lag only 
> exists during magnification, but otherwise animations are smooth and 
> fluid as to be expected.
> 
> KDE Plasma is my preferred desktop environment, and because I rely 
> heavily on magnification in my daily workflow, this regression has had a 
> significant impact on my overall experience. To rule out local 
> configuration issues, I performed a clean installation of Arch Linux and 
> KDE Plasma. Even on a fresh installation, before making any 
> customizations, I encountered the same magnification-related lag.
> 
> If possible, I would greatly appreciate your help investigating this 
> issue so the underlying cause can be identified and resolved. I'm happy 
> to provide logs, perform testing, or supply any additional information 
> that might help narrow down the source of the regression.
> *
> *
> *System Information*
> 
>   *
>     /Operating System: Arch Linux/
>   *
>     /KDE Plasma: 6.7.3/
>   *
>     /KDE Frameworks: 6.28.0/
>   *
>     /Qt: 6.11.1/
>   *
>     /Kernel: 7.1.4-zen1-1-zen/
>   *
>     /Display Server: Wayland/
>   *
>     /CPU: 11th Gen Intel Core i5-1135G7/
>   *
>     /GPU: Intel Iris Xe Graphics (Mesa)/
>   *
>     /OpenGL Renderer: Mesa Intel(R) Iris(R) Xe Graphics (TGL GT2)/
>   *
>     /Memory: 16 GB RAM/
>   *
>     /Hardware: Dell XPS 13 2-in-1 9310/
> 
> /
> ​Kooha-2026-07-20-13-37-54.webm <https://1drv.ms/v/c/30af511c444f423a/ 
> IQCTbIGmkzx-QYqITFr_BtU9AR6CJ0ChvuhPTc0WvO_n2zg>​/
> /​Kooha-2026-07-20-13-32-10.webm <https://1drv.ms/v/c/30af511c444f423a/ 
> IQCvyJvicyx-SZ4o2iG-Pi2IAfwav7W_BxRECs3oOWJEOU0>​/
> /​Kooha-2026-07-20-13-34-35.webm <https://1drv.ms/v/c/30af511c444f423a/ 
> IQDQX-dLPU1HQ6q1luQqU7cpAQKMQ0V4WrvQa-CdktfAnQ0>​/
> 
> Kind regards,
> 
> Chase Laird
> ------------------------------------------------------------------------
> *From:* Nate Graham <nate at kde.org>
> *Sent:* Saturday, June 21, 2025 7:48 AM
> *To:* Chase Laird <chase.laird at live.com>
> *Cc:* kde-community at kde.org <kde-community at kde.org>; plasma- 
> devel at kde.org <plasma-devel at kde.org>; kde-ev-board at kde.org <kde-ev- 
> board at kde.org>
> *Subject:* Re: Appreciation and Feedback on Accessibility Improvements 
> in KDE Plasma 6.4
> Hello Chase,
> 
> Thank you so much for the kind words! We have indeed been putting a lot
> of focus into accessibility lately, so I'm really happy to hear that
> Plasma 6.4 has been a notable improvement!
> 
> If you're looking to get involved, there's actually a somewhat large and
> important accessibility initiative that you could definitely help out
> with. We're making a push to get all KDE software compliant with EU
> Directive 2019/882; see
> https://invent.kde.org/teams/accessibility/collaboration/-/issues/30 
> <https://invent.kde.org/teams/accessibility/collaboration/-/issues/30>.
> 
> There are opportunities for development work, but a big part is just
> using the software with a critical eye to find what's non-compliant and
> write it down.
> 
> You can see the work-in-progress effort for Plasma itself here:
> https://invent.kde.org/plasma/plasma-desktop/-/issues/149 <https:// 
> invent.kde.org/plasma/plasma-desktop/-/issues/149>
> 
> Thanks again!
> 
> -- 
> Nate Graham
> KDE e.V. Board of Directors
> 
> 
> On 6/20/25 7:25 PM, Chase Laird wrote:
>> Dear KDE Team,
>> 
>> 
>> I hope this message finds you well.
>> 
>> 
>> I am writing to share my heartfelt appreciation and detailed feedback 
>> regarding the recent KDE Plasma 6.4 release. As a visually impaired 
>> user, computing poses unique challenges—particularly regarding effective 
>> magnification and accessibility features. Over the years, I have 
>> extensively used macOS, Windows, and numerous Linux distributions / 
>> desktop environments, each offering varying degrees of success in 
>> accessibility accommodations.
>> 
>> 
>> With this experience in mind, I want to commend your team for 
>> prioritizing accessibility in KDE Plasma. Unfortunately, many desktop 
>> environments treat accessibility as an afterthought, often implementing 
>> it in ways that inadvertently introduce more usability issues than they 
>> resolve. For instance, using GNOME’s built-in magnification resulted in 
>> severe screen tearing and a cumbersome experience across my multi- 
>> monitor setup.
>> 
>> 
>> However, upon migrating to KDE Plasma on my Arch Linux system, my 
>> experience has dramatically improved. Initially, I set up magnification 
>> using Fusuma gestures (three-finger swipe up/down for zoom control). 
>> Imagine my delight upon discovering that KDE Plasma 6.4 now integrates 
>> gesture-based magnification directly into the OS. This thoughtful 
>> feature alone has significantly enhanced my daily computing experience, 
>> and I am genuinely impressed by the smoothness, stability, and 
>> intuitiveness of your implementation.
>> 
>> 
>> Given the profound impact KDE Plasma’s accessibility features have had 
>> on me personally, I am eager to contribute back to the KDE community. If 
>> there are opportunities or initiatives within the KDE team dedicated to 
>> accessibility testing, feedback, or development, I would greatly 
>> appreciate the chance to offer my insights and assistance.
>> 
>> 
>> Thank you again for your clear commitment to making Linux a more 
>> inclusive platform. You have effectively ended my days of distro and DE 
>> hopping, and for that, I am deeply grateful.
>> 
>> 
>> Warm regards,
>> 
>> 
>> Chase Laird
> 
> 


From chase.laird at live.com  Mon Jul 20 19:46:25 2026
From: chase.laird at live.com (Chase Laird)
Date: Mon, 20 Jul 2026 18:46:25 +0000
Subject: Magnification Performance Regression In KDE Plasma 6.7
In-Reply-To: <d70fbf63-dbd1-4811-a532-bda059e6a0f1@kde.org>
References: <BL1PR14MB5143F56847D9B198505CBD53837FA@BL1PR14MB5143.namprd14.prod.outlook.com>
 <d70fbf63-dbd1-4811-a532-bda059e6a0f1@kde.org>
Message-ID: <BL1PR14MB5143F99DABC35EC9AF9A5F9483C32@BL1PR14MB5143.namprd14.prod.outlook.com>

Hello Nate,

I hope you've been doing well.

I wanted to report an issue I've been experiencing with KDE Plasma's magnification feature. I'm not sure how widespread this problem is, so I'll include my system details to help define the scope.

On my system, enabling magnification has recently introduced significant display lag on both the internal and external displays, with the issue being especially noticeable on external monitors. The lag is most apparent during animation-heavy tasks, such as panning zoom, scrolling webpages, or swiping between virtual desktops. The virtual desktop transition, in particular, appears almost to be in slow motion, making the desktop feel sluggish and disrupting what was previously an exceptionally smooth and responsive experience.

I'm not certain what introduced this regression, but I suspect it may be related to a Plasma update from within the past month. My system is running Arch Linux on a Dell XPS 13 2-in-1 9310. Notably, the lag only exists during magnification, but otherwise animations are smooth and fluid as to be expected.

KDE Plasma is my preferred desktop environment, and because I rely heavily on magnification in my daily workflow, this regression has had a significant impact on my overall experience. To rule out local configuration issues, I performed a clean installation of Arch Linux and KDE Plasma. Even on a fresh installation, before making any customizations, I encountered the same magnification-related lag.

If possible, I would greatly appreciate your help investigating this issue so the underlying cause can be identified and resolved. I'm happy to provide logs, perform testing, or supply any additional information that might help narrow down the source of the regression.

System Information

  *
Operating System: Arch Linux
  *
KDE Plasma: 6.7.3
  *
KDE Frameworks: 6.28.0
  *
Qt: 6.11.1
  *
Kernel: 7.1.4-zen1-1-zen
  *
Display Server: Wayland
  *
CPU: 11th Gen Intel Core i5-1135G7
  *
GPU: Intel Iris Xe Graphics (Mesa)
  *
OpenGL Renderer: Mesa Intel(R) Iris(R) Xe Graphics (TGL GT2)
  *
Memory: 16 GB RAM
  *
Hardware: Dell XPS 13 2-in-1 9310

​[https://res.public.onecdn.static.microsoft/assets/fluentui-resources/1.1.0/app-min/assets/item-types/24/video.png]Kooha-2026-07-20-13-37-54.webm<https://1drv.ms/v/c/30af511c444f423a/IQCTbIGmkzx-QYqITFr_BtU9AR6CJ0ChvuhPTc0WvO_n2zg>​
​[https://res.public.onecdn.static.microsoft/assets/fluentui-resources/1.1.0/app-min/assets/item-types/24/video.png]Kooha-2026-07-20-13-32-10.webm<https://1drv.ms/v/c/30af511c444f423a/IQCvyJvicyx-SZ4o2iG-Pi2IAfwav7W_BxRECs3oOWJEOU0>​
​[https://res.public.onecdn.static.microsoft/assets/fluentui-resources/1.1.0/app-min/assets/item-types/24/video.png]Kooha-2026-07-20-13-34-35.webm<https://1drv.ms/v/c/30af511c444f423a/IQDQX-dLPU1HQ6q1luQqU7cpAQKMQ0V4WrvQa-CdktfAnQ0>​

Kind regards,

Chase Laird
________________________________
From: Nate Graham <nate at kde.org>
Sent: Saturday, June 21, 2025 7:48 AM
To: Chase Laird <chase.laird at live.com>
Cc: kde-community at kde.org <kde-community at kde.org>; plasma-devel at kde.org <plasma-devel at kde.org>; kde-ev-board at kde.org <kde-ev-board at kde.org>
Subject: Re: Appreciation and Feedback on Accessibility Improvements in KDE Plasma 6.4

Hello Chase,

Thank you so much for the kind words! We have indeed been putting a lot
of focus into accessibility lately, so I'm really happy to hear that
Plasma 6.4 has been a notable improvement!

If you're looking to get involved, there's actually a somewhat large and
important accessibility initiative that you could definitely help out
with. We're making a push to get all KDE software compliant with EU
Directive 2019/882; see
https://invent.kde.org/teams/accessibility/collaboration/-/issues/30.

There are opportunities for development work, but a big part is just
using the software with a critical eye to find what's non-compliant and
write it down.

You can see the work-in-progress effort for Plasma itself here:
https://invent.kde.org/plasma/plasma-desktop/-/issues/149

Thanks again!

--
Nate Graham
KDE e.V. Board of Directors


On 6/20/25 7:25 PM, Chase Laird wrote:
> Dear KDE Team,
>
>
> I hope this message finds you well.
>
>
> I am writing to share my heartfelt appreciation and detailed feedback
> regarding the recent KDE Plasma 6.4 release. As a visually impaired
> user, computing poses unique challenges—particularly regarding effective
> magnification and accessibility features. Over the years, I have
> extensively used macOS, Windows, and numerous Linux distributions /
> desktop environments, each offering varying degrees of success in
> accessibility accommodations.
>
>
> With this experience in mind, I want to commend your team for
> prioritizing accessibility in KDE Plasma. Unfortunately, many desktop
> environments treat accessibility as an afterthought, often implementing
> it in ways that inadvertently introduce more usability issues than they
> resolve. For instance, using GNOME’s built-in magnification resulted in
> severe screen tearing and a cumbersome experience across my multi-
> monitor setup.
>
>
> However, upon migrating to KDE Plasma on my Arch Linux system, my
> experience has dramatically improved. Initially, I set up magnification
> using Fusuma gestures (three-finger swipe up/down for zoom control).
> Imagine my delight upon discovering that KDE Plasma 6.4 now integrates
> gesture-based magnification directly into the OS. This thoughtful
> feature alone has significantly enhanced my daily computing experience,
> and I am genuinely impressed by the smoothness, stability, and
> intuitiveness of your implementation.
>
>
> Given the profound impact KDE Plasma’s accessibility features have had
> on me personally, I am eager to contribute back to the KDE community. If
> there are opportunities or initiatives within the KDE team dedicated to
> accessibility testing, feedback, or development, I would greatly
> appreciate the chance to offer my insights and assistance.
>
>
> Thank you again for your clear commitment to making Linux a more
> inclusive platform. You have effectively ended my days of distro and DE
> hopping, and for that, I am deeply grateful.
>
>
> Warm regards,
>
>
> Chase Laird


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260720/5e2268f1/attachment-0001.htm>

From kristen at kde.org  Mon Jul 27 20:14:19 2026
From: kristen at kde.org (Kristen McWilliam)
Date: Mon, 27 Jul 2026 15:14:19 -0400
Subject: Plasma CI Health Check (July 27, 2026)
Message-ID: <7594076b-d311-4864-bdb3-9528dadcce82@kde.org>

/*Great news!!*/ No repos are failing in master. /[hands out cookies to 
everyone 🍪 😁]/


• 82 monitored repos
• 0 failing CI in master
• 2 configured for auto-repeating tests
• 94% of repos configured to require passing tests


Good news: 1 repos fixed


Auto-retrying tests:
     • kwin
     • plasma-desktop


KDE CI Dashboard:
https://ci-healthcheck-5e5c80.local-kde.org/

-- 
Cheers,
   Kristen
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260727/809914e4/attachment.htm>

From nate at kde.org  Mon Jul 27 20:16:12 2026
From: nate at kde.org (Nate Graham)
Date: Mon, 27 Jul 2026 13:16:12 -0600
Subject: Plasma CI Health Check (July 27, 2026)
In-Reply-To: <7594076b-d311-4864-bdb3-9528dadcce82@kde.org>
References: <7594076b-d311-4864-bdb3-9528dadcce82@kde.org>
Message-ID: <b280bfbd-66a0-4bd2-bfe3-68d8d9e4c7a8@kde.org>

Woohoo!

Nate



On 7/27/26 1:14 PM, Kristen McWilliam wrote:
> /*Great news!!*/ No repos are failing in master. /[hands out cookies to 
> everyone 🍪 😁]/
> 
> 
> • 82 monitored repos
> • 0 failing CI in master
> • 2 configured for auto-repeating tests
> • 94% of repos configured to require passing tests
> 
> 
> Good news: 1 repos fixed
> 
> 
> Auto-retrying tests:
>      • kwin
>      • plasma-desktop
> 
> 
> KDE CI Dashboard:
> https://ci-healthcheck-5e5c80.local-kde.org/
> 
> -- 
> Cheers,
>    Kristen
> 


From bcooksley at kde.org  Tue Jul 28 11:52:32 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Tue, 28 Jul 2026 22:52:32 +1200
Subject: Decommissioning Qt 5 CI
Message-ID: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>

Hi all,

For some time now Qt 5 has been in extended maintenance / support, which
Iif my understanding is correct has now come to an end.

Accordingly, given that all of our applications have now had a substantial
amount of time to migrate, and plenty of notice that CI would be withdrawn
eventually, i'd like to proceed with withdrawing CI support for Qt 5.

This will free up valuable space on the CI nodes and allow us to remove an
image that is under very minimal, if any, maintenance.

Please let me know if there are any objections.

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/12bf0e73/attachment.htm>

From bcooksley at kde.org  Tue Jul 28 11:58:30 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Tue, 28 Jul 2026 22:58:30 +1200
Subject: Changing CI builds to RelWithDebInfo from Debug
Message-ID: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>

Hi all,

For some time now CI has built everything using CMAKE_BUILD_TYPE set to
Debug. This has the benefit of producing binaries that have asserts
enabled, however does have the downside that the binaries generated are
larger and unoptimized, making test execution take longer.

For KWin, this means that the install/ folder it produces on a Qt 6.11
system uses ~890MB of space by itself (excluding any dependencies).

In the interests of reducing disk space utilisation on the CI builders, as
well as hopefully speeding up execution of tests, i'd like to switch the CI
system to use RelWithDebInfo.

Please let me know if there are any issues with this.

Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/c3039094/attachment.htm>

From nicolas.fella at gmx.de  Tue Jul 28 12:10:05 2026
From: nicolas.fella at gmx.de (Nicolas Fella)
Date: Tue, 28 Jul 2026 13:10:05 +0200
Subject: Changing CI builds to RelWithDebInfo from Debug
In-Reply-To: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>
References: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>
Message-ID: <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de>

On 28/07/2026 12:58, Ben Cooksley wrote:
> Hi all,
>
> For some time now CI has built everything using CMAKE_BUILD_TYPE set 
> to Debug. This has the benefit of producing binaries that have asserts 
> enabled, however does have the downside that the binaries generated 
> are larger and unoptimized, making test execution take longer.
>
> For KWin, this means that the install/ folder it produces on a Qt 6.11 
> system uses ~890MB of space by itself (excluding any dependencies).
>
> In the interests of reducing disk space utilisation on the CI 
> builders, as well as hopefully speeding up execution of tests, i'd 
> like to switch the CI system to use RelWithDebInfo.
>
> Please let me know if there are any issues with this.
>
> Thanks,
> Ben

Hi,

no objection in principle. I'm a bit skeptical that it will make a large 
difference (debug symbols probably make up the largest part of the 
space), but I'm open to being proved wrong.

I'd rather not lose the asserts though, and we don't have to. We just 
need to pass -DECM_FORCE_ASSERTS=ON to CMake (see 
https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/574).

Cheers

Nico
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/3906f86c/attachment.htm>

From nicolas.fella at gmx.de  Tue Jul 28 12:20:56 2026
From: nicolas.fella at gmx.de (Nicolas Fella)
Date: Tue, 28 Jul 2026 13:20:56 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
Message-ID: <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>

On 28/07/2026 12:52, Ben Cooksley wrote:
> Hi all,
>
> For some time now Qt 5 has been in extended maintenance / support, 
> which Iif my understanding is correct has now come to an end.
>
> Accordingly, given that all of our applications have now had a 
> substantial amount of time to migrate, and plenty of notice that CI 
> would be withdrawn eventually, i'd like to proceed with withdrawing CI 
> support for Qt 5.
>
> This will free up valuable space on the CI nodes and allow us to 
> remove an image that is under very minimal, if any, maintenance.
>
> Please let me know if there are any objections.

Hi,

for applications I agree to drop Qt5 CI. The few usages that are left 
either already have Qt6 CI, or are more or less dead projects.

That said, we have a number of (Plasma) components that we still build 
for Qt5 for (external) application compatibility (breeze, 
plasma-integration, etc). So far we have not made a decision to stop 
doing that, and I'd rather not lose CI for those. That doesn't mean we 
need Qt5 CI in the current form. Could we use a distribution image with 
Qt and the few necessary libraries/frameworks baked in? That would be a 
much smaller image and easier to maintain than the current suse-qt515 
image.

Cheers

Nico


From bcooksley at kde.org  Tue Jul 28 12:24:44 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Tue, 28 Jul 2026 23:24:44 +1200
Subject: Changing CI builds to RelWithDebInfo from Debug
In-Reply-To: <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de>
References: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>
 <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de>
Message-ID: <CA+XidOFCLtYdjvoKBQXEovmWcEgZ2PG8dsx00uLYitnr7wuzoA@mail.gmail.com>

On Tue, Jul 28, 2026 at 11:10 PM Nicolas Fella <nicolas.fella at gmx.de> wrote:

> On 28/07/2026 12:58, Ben Cooksley wrote:
>
> Hi all,
>
> For some time now CI has built everything using CMAKE_BUILD_TYPE set to
> Debug. This has the benefit of producing binaries that have asserts
> enabled, however does have the downside that the binaries generated are
> larger and unoptimized, making test execution take longer.
>
> For KWin, this means that the install/ folder it produces on a Qt 6.11
> system uses ~890MB of space by itself (excluding any dependencies).
>
> In the interests of reducing disk space utilisation on the CI builders, as
> well as hopefully speeding up execution of tests, i'd like to switch the CI
> system to use RelWithDebInfo.
>
> Please let me know if there are any issues with this.
>
> Thanks,
> Ben
>
> Hi,
>
> no objection in principle. I'm a bit skeptical that it will make a large
> difference (debug symbols probably make up the largest part of the space),
> but I'm open to being proved wrong.
>
> I'd rather not lose the asserts though, and we don't have to. We just need
> to pass -DECM_FORCE_ASSERTS=ON to CMake (see
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/574
> ).
>

We can do that. The reason for going with full Debug was literally to have
asserts enabled, so if we can do that without having to build full Debug
binaries it should be fine.

I'm expecting that there will be some size reduction thanks to compiler
optimisations, and having optimisations should in theory make things run
faster which is the big gain we'll get.


> Cheers
>
> Nico
>

Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/9742ad46/attachment-0001.htm>

From bcooksley at kde.org  Tue Jul 28 12:39:57 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Tue, 28 Jul 2026 23:39:57 +1200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
Message-ID: <CA+XidOF0v1R=GwtJw+VAUQ7cQ3J=UVtTWW8GajkXUgWQTD4BnA@mail.gmail.com>

On Tue, Jul 28, 2026 at 11:21 PM Nicolas Fella <nicolas.fella at gmx.de> wrote:

> On 28/07/2026 12:52, Ben Cooksley wrote:
> > Hi all,
> >
> > For some time now Qt 5 has been in extended maintenance / support,
> > which Iif my understanding is correct has now come to an end.
> >
> > Accordingly, given that all of our applications have now had a
> > substantial amount of time to migrate, and plenty of notice that CI
> > would be withdrawn eventually, i'd like to proceed with withdrawing CI
> > support for Qt 5.
> >
> > This will free up valuable space on the CI nodes and allow us to
> > remove an image that is under very minimal, if any, maintenance.
> >
> > Please let me know if there are any objections.
>
> Hi,
>
> for applications I agree to drop Qt5 CI. The few usages that are left
> either already have Qt6 CI, or are more or less dead projects.
>

Correct.


>
> That said, we have a number of (Plasma) components that we still build
> for Qt5 for (external) application compatibility (breeze,
> plasma-integration, etc). So far we have not made a decision to stop
> doing that, and I'd rather not lose CI for those. That doesn't mean we


>From my understanding distributions are stripping Qt 5 support out fairly
quickly, so i'd be inclined to end support for Qt 5 in those Plasma
components, and for distributions still shipping Qt 5 ask them to keep
building the last release of those components that supported Qt 5.


>
> need Qt5 CI in the current form. Could we use a distribution image with
> Qt and the few necessary libraries/frameworks baked in? That would be a
> much smaller image and easier to maintain than the current suse-qt515
> image.
>

CI images even with things baked in have a degree of cost associated with
them as distributions drop packages / change package names (ignoring the
storage requirements for those images).

Do those components have promises not to use fancy new C++ features, etc
that often require modern, up to date compilers that wouldn't necessarily
be featured in a stable distribution?


>
> Cheers
>
> Nico
>
>
Cheers,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/ce7729b7/attachment.htm>

From ervin at kde.org  Tue Jul 28 12:49:51 2026
From: ervin at kde.org (Kevin Ottens)
Date: Tue, 28 Jul 2026 13:49:51 +0200
Subject: Changing CI builds to RelWithDebInfo from Debug
In-Reply-To: <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de>
References: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>
 <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de>
Message-ID: <qb6-OC9qSfmkCHGuS5pEzg@kde.org>

Hello,

On Tuesday, 28 July 2026 13:10:05 Central European Summer Time Nicolas Fella 
wrote:
> no objection in principle. I'm a bit skeptical that it will make a large
> difference (debug symbols probably make up the largest part of the
> space), but I'm open to being proved wrong.

Same here FWIW. I'm not sure the optimisations alone will reduce by a great 
deal.
 
> I'd rather not lose the asserts though, and we don't have to. We just
> need to pass -DECM_FORCE_ASSERTS=ON to CMake (see
> https://invent.kde.org/frameworks/extra-cmake-modules/-/merge_requests/574).

Yes, that's the important part to not sacrifice. We definitely need the 
asserts active on the CI. Otherwise they'd effectively be active only on 
developers environments this definitely wouldn't be enough.

Cheers.
-- 
Kevin Ottens, http://ervin.ipsquad.net

enioka Haute Couture - proud supporting member of KDE
https://haute-couture.enioka.com/en
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 232 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/23beec6f/attachment.sig>

From aacid at kde.org  Tue Jul 28 22:36:20 2026
From: aacid at kde.org (Albert Astals Cid)
Date: Tue, 28 Jul 2026 23:36:20 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
Message-ID: <w4xAvup3R9uC5_vDU7lI-w@kde.org>

El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu d’Europa 
central), Nicolas Fella va escriure:
> On 28/07/2026 12:52, Ben Cooksley wrote:
> > Hi all,
> > 
> > For some time now Qt 5 has been in extended maintenance / support,
> > which Iif my understanding is correct has now come to an end.
> > 
> > Accordingly, given that all of our applications have now had a
> > substantial amount of time to migrate, and plenty of notice that CI
> > would be withdrawn eventually, i'd like to proceed with withdrawing CI
> > support for Qt 5.
> > 
> > This will free up valuable space on the CI nodes and allow us to
> > remove an image that is under very minimal, if any, maintenance.
> > 
> > Please let me know if there are any objections.
> 
> Hi,
> 
> for applications I agree to drop Qt5 CI. The few usages that are left
> either already have Qt6 CI, or are more or less dead projects.
> 
> That said, we have a number of (Plasma) components that we still build
> for Qt5 for (external) application compatibility (breeze,
> plasma-integration, etc). So far we have not made a decision to stop
> doing that, and I'd rather not lose CI for those. That doesn't mean we
> need Qt5 CI in the current form. Could we use a distribution image with
> Qt and the few necessary libraries/frameworks baked in? That would be a
> much smaller image and easier to maintain than the current suse-qt515
> image.

Does the code of those repos change in qt5 related areas?

Trying to understand what we want CI for here:
 * Potentially new qt5 code builds with old qt5/gcc distros?
 * Non changing qt5 code builds new gcc/stuff from distros?

Cheers,
  Albert

> 
> Cheers
> 
> Nico





From kde at david-redondo.de  Wed Jul 29 08:30:21 2026
From: kde at david-redondo.de (David Redondo)
Date: Wed, 29 Jul 2026 09:30:21 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <w4xAvup3R9uC5_vDU7lI-w@kde.org>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
 <w4xAvup3R9uC5_vDU7lI-w@kde.org>
Message-ID: <0xz47wBRTKOrz2sBN_4e6g@david-redondo.de>

Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
> El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu d’Europa 
> central), Nicolas Fella va escriure:
> > On 28/07/2026 12:52, Ben Cooksley wrote:
> > > Hi all,
> > > 
> > > For some time now Qt 5 has been in extended maintenance / support,
> > > which Iif my understanding is correct has now come to an end.
> > > 
> > > Accordingly, given that all of our applications have now had a
> > > substantial amount of time to migrate, and plenty of notice that CI
> > > would be withdrawn eventually, i'd like to proceed with withdrawing CI
> > > support for Qt 5.
> > > 
> > > This will free up valuable space on the CI nodes and allow us to
> > > remove an image that is under very minimal, if any, maintenance.
> > > 
> > > Please let me know if there are any objections.
> > 
> > Hi,
> > 
> > for applications I agree to drop Qt5 CI. The few usages that are left
> > either already have Qt6 CI, or are more or less dead projects.
> > 
> > That said, we have a number of (Plasma) components that we still build
> > for Qt5 for (external) application compatibility (breeze,
> > plasma-integration, etc). So far we have not made a decision to stop
> > doing that, and I'd rather not lose CI for those. That doesn't mean we
> > need Qt5 CI in the current form. Could we use a distribution image with
> > Qt and the few necessary libraries/frameworks baked in? That would be a
> > much smaller image and easier to maintain than the current suse-qt515
> > image.
> 
> Does the code of those repos change in qt5 related areas?
> 
> Trying to understand what we want CI for here:
>  * Potentially new qt5 code builds with old qt5/gcc distros?
>  * Non changing qt5 code builds new gcc/stuff from distros?
> 

breeze, oxygen and plasma-integration is
* new qt5 code builds on current distros
it changes as the qt6 code changes. The goal is that qt5 and qt6 applications
look and feel the same.
For breeze and oxygen the same code base is compiled twice, once with qt6 and once with qt5.
plasma-integration has copies of the code for qt5 and qt6 because the ifdef'ery became a bit too much.

Non changing qt5 code that I can think of is kwayland-integration which is an implementation detail of kf5/plasma5
but we provide in plasma6 to keep kf5 apps working. 

Cheers, David

> Cheers,
>   Albert
> 
> > 
> > Cheers
> > 
> > Nico
> 
> 
> 
> 
> 





From bcooksley at kde.org  Wed Jul 29 11:00:08 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Wed, 29 Jul 2026 22:00:08 +1200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <0xz47wBRTKOrz2sBN_4e6g@david-redondo.de>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de> <w4xAvup3R9uC5_vDU7lI-w@kde.org>
 <0xz47wBRTKOrz2sBN_4e6g@david-redondo.de>
Message-ID: <CA+XidOEzOOOpZMknPJT_8992RTN=ip3rh6YKpGryjQ-oTaOHgw@mail.gmail.com>

On Wed, Jul 29, 2026 at 7:31 PM David Redondo <kde at david-redondo.de> wrote:

> Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
> > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu d’Europa
> > central), Nicolas Fella va escriure:
> > > On 28/07/2026 12:52, Ben Cooksley wrote:
> > > > Hi all,
> > > >
> > > > For some time now Qt 5 has been in extended maintenance / support,
> > > > which Iif my understanding is correct has now come to an end.
> > > >
> > > > Accordingly, given that all of our applications have now had a
> > > > substantial amount of time to migrate, and plenty of notice that CI
> > > > would be withdrawn eventually, i'd like to proceed with withdrawing
> CI
> > > > support for Qt 5.
> > > >
> > > > This will free up valuable space on the CI nodes and allow us to
> > > > remove an image that is under very minimal, if any, maintenance.
> > > >
> > > > Please let me know if there are any objections.
> > >
> > > Hi,
> > >
> > > for applications I agree to drop Qt5 CI. The few usages that are left
> > > either already have Qt6 CI, or are more or less dead projects.
> > >
> > > That said, we have a number of (Plasma) components that we still build
> > > for Qt5 for (external) application compatibility (breeze,
> > > plasma-integration, etc). So far we have not made a decision to stop
> > > doing that, and I'd rather not lose CI for those. That doesn't mean we
> > > need Qt5 CI in the current form. Could we use a distribution image with
> > > Qt and the few necessary libraries/frameworks baked in? That would be a
> > > much smaller image and easier to maintain than the current suse-qt515
> > > image.
> >
> > Does the code of those repos change in qt5 related areas?
> >
> > Trying to understand what we want CI for here:
> >  * Potentially new qt5 code builds with old qt5/gcc distros?
> >  * Non changing qt5 code builds new gcc/stuff from distros?
> >
>
> breeze, oxygen and plasma-integration is
> * new qt5 code builds on current distros
> it changes as the qt6 code changes. The goal is that qt5 and qt6
> applications
> look and feel the same.
> For breeze and oxygen the same code base is compiled twice, once with qt6
> and once with qt5.
> plasma-integration has copies of the code for qt5 and qt6 because the
> ifdef'ery became a bit too much.
>
> Non changing qt5 code that I can think of is kwayland-integration which is
> an implementation detail of kf5/plasma5
> but we provide in plasma6 to keep kf5 apps working.


Not a huge fan of the idea of keeping Qt 5 around in any form at all to be
honest.

Do the Plasma developers have a view as to when this support will be
dropped given that distributions are rapidly dropping support for Qt 5?

This feels like something that is going to require work to implement and
will be dropped in 6 months or so given the speed distros are moving at,
and if that is the case my preference would be to just move up the end of
support and do it all now.

Regards,
Ben


>
>
> Cheers, David
>
> > Cheers,
> >   Albert
> >
> > >
> > > Cheers
> > >
> > > Nico
> >
> >
> >
> >
> >
>
>
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260729/b3d710c0/attachment-0001.htm>

From nicolas.fella at gmx.de  Wed Jul 29 11:07:15 2026
From: nicolas.fella at gmx.de (Nicolas Fella)
Date: Wed, 29 Jul 2026 12:07:15 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <CA+XidOEzOOOpZMknPJT_8992RTN=ip3rh6YKpGryjQ-oTaOHgw@mail.gmail.com>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de>
 <w4xAvup3R9uC5_vDU7lI-w@kde.org> <0xz47wBRTKOrz2sBN_4e6g@david-redondo.de>
 <CA+XidOEzOOOpZMknPJT_8992RTN=ip3rh6YKpGryjQ-oTaOHgw@mail.gmail.com>
Message-ID: <46541bfd-14fd-4151-858c-ee7361a38f3a@gmx.de>

On 29/07/2026 12:00, Ben Cooksley wrote:
> On Wed, Jul 29, 2026 at 7:31 PM David Redondo <kde at david-redondo.de> 
> wrote:
>
>     Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
>     > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu
>     d’Europa
>     > central), Nicolas Fella va escriure:
>     > > On 28/07/2026 12:52, Ben Cooksley wrote:
>     > > > Hi all,
>     > > >
>     > > > For some time now Qt 5 has been in extended maintenance /
>     support,
>     > > > which Iif my understanding is correct has now come to an end.
>     > > >
>     > > > Accordingly, given that all of our applications have now had a
>     > > > substantial amount of time to migrate, and plenty of notice
>     that CI
>     > > > would be withdrawn eventually, i'd like to proceed with
>     withdrawing CI
>     > > > support for Qt 5.
>     > > >
>     > > > This will free up valuable space on the CI nodes and allow us to
>     > > > remove an image that is under very minimal, if any, maintenance.
>     > > >
>     > > > Please let me know if there are any objections.
>     > >
>     > > Hi,
>     > >
>     > > for applications I agree to drop Qt5 CI. The few usages that
>     are left
>     > > either already have Qt6 CI, or are more or less dead projects.
>     > >
>     > > That said, we have a number of (Plasma) components that we
>     still build
>     > > for Qt5 for (external) application compatibility (breeze,
>     > > plasma-integration, etc). So far we have not made a decision
>     to stop
>     > > doing that, and I'd rather not lose CI for those. That doesn't
>     mean we
>     > > need Qt5 CI in the current form. Could we use a distribution
>     image with
>     > > Qt and the few necessary libraries/frameworks baked in? That
>     would be a
>     > > much smaller image and easier to maintain than the current
>     suse-qt515
>     > > image.
>     >
>     > Does the code of those repos change in qt5 related areas?
>     >
>     > Trying to understand what we want CI for here:
>     >  * Potentially new qt5 code builds with old qt5/gcc distros?
>     >  * Non changing qt5 code builds new gcc/stuff from distros?
>     >
>
>     breeze, oxygen and plasma-integration is
>     * new qt5 code builds on current distros
>     it changes as the qt6 code changes. The goal is that qt5 and qt6
>     applications
>     look and feel the same.
>     For breeze and oxygen the same code base is compiled twice, once
>     with qt6 and once with qt5.
>     plasma-integration has copies of the code for qt5 and qt6 because
>     the ifdef'ery became a bit too much.
>
>     Non changing qt5 code that I can think of is kwayland-integration
>     which is an implementation detail of kf5/plasma5
>     but we provide in plasma6 to keep kf5 apps working.
>
>
> Not a huge fan of the idea of keeping Qt 5 around in any form at all 
> to be honest.
>
> Do the Plasma developers have a view as to when this support will be 
> dropped given that distributions are rapidly dropping support for Qt 5?

Looking at 
https://mail.kde.org/pipermail/distributions/2026-June/001695.html we 
are not quite there yet when it comes to getting rid of Qt5 entirely.


> This feels like something that is going to require work to implement 
> and will be dropped in 6 months or so given the speed distros are 
> moving at, and if that is the case my preference would be to just move 
> up the end of support and do it all now.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260729/9f84dd65/attachment.htm>

From bcooksley at kde.org  Thu Jul 30 11:23:35 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Thu, 30 Jul 2026 22:23:35 +1200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <46541bfd-14fd-4151-858c-ee7361a38f3a@gmx.de>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <1984ee94-b281-44e6-ab4b-e0b699d507bc@gmx.de> <w4xAvup3R9uC5_vDU7lI-w@kde.org>
 <0xz47wBRTKOrz2sBN_4e6g@david-redondo.de>
 <CA+XidOEzOOOpZMknPJT_8992RTN=ip3rh6YKpGryjQ-oTaOHgw@mail.gmail.com>
 <46541bfd-14fd-4151-858c-ee7361a38f3a@gmx.de>
Message-ID: <CA+XidOEHF2TYf_xgfSwmvttxbwC8AyOcvd0zNW=dew73bMeVuQ@mail.gmail.com>

On Wed, Jul 29, 2026 at 10:07 PM Nicolas Fella <nicolas.fella at gmx.de> wrote:

> On 29/07/2026 12:00, Ben Cooksley wrote:
>
> On Wed, Jul 29, 2026 at 7:31 PM David Redondo <kde at david-redondo.de>
> wrote:
>
>> Am Dienstag, 28. Juli 2026, 23:36 schrieb Albert Astals Cid:
>> > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu
>> d’Europa
>> > central), Nicolas Fella va escriure:
>> > > On 28/07/2026 12:52, Ben Cooksley wrote:
>> > > > Hi all,
>> > > >
>> > > > For some time now Qt 5 has been in extended maintenance / support,
>> > > > which Iif my understanding is correct has now come to an end.
>> > > >
>> > > > Accordingly, given that all of our applications have now had a
>> > > > substantial amount of time to migrate, and plenty of notice that CI
>> > > > would be withdrawn eventually, i'd like to proceed with withdrawing
>> CI
>> > > > support for Qt 5.
>> > > >
>> > > > This will free up valuable space on the CI nodes and allow us to
>> > > > remove an image that is under very minimal, if any, maintenance.
>> > > >
>> > > > Please let me know if there are any objections.
>> > >
>> > > Hi,
>> > >
>> > > for applications I agree to drop Qt5 CI. The few usages that are left
>> > > either already have Qt6 CI, or are more or less dead projects.
>> > >
>> > > That said, we have a number of (Plasma) components that we still build
>> > > for Qt5 for (external) application compatibility (breeze,
>> > > plasma-integration, etc). So far we have not made a decision to stop
>> > > doing that, and I'd rather not lose CI for those. That doesn't mean we
>> > > need Qt5 CI in the current form. Could we use a distribution image
>> with
>> > > Qt and the few necessary libraries/frameworks baked in? That would be
>> a
>> > > much smaller image and easier to maintain than the current suse-qt515
>> > > image.
>> >
>> > Does the code of those repos change in qt5 related areas?
>> >
>> > Trying to understand what we want CI for here:
>> >  * Potentially new qt5 code builds with old qt5/gcc distros?
>> >  * Non changing qt5 code builds new gcc/stuff from distros?
>> >
>>
>> breeze, oxygen and plasma-integration is
>> * new qt5 code builds on current distros
>> it changes as the qt6 code changes. The goal is that qt5 and qt6
>> applications
>> look and feel the same.
>> For breeze and oxygen the same code base is compiled twice, once with qt6
>> and once with qt5.
>> plasma-integration has copies of the code for qt5 and qt6 because the
>> ifdef'ery became a bit too much.
>>
>> Non changing qt5 code that I can think of is kwayland-integration which
>> is an implementation detail of kf5/plasma5
>> but we provide in plasma6 to keep kf5 apps working.
>
>
> Not a huge fan of the idea of keeping Qt 5 around in any form at all to be
> honest.
>
> Do the Plasma developers have a view as to when this support will be
> dropped given that distributions are rapidly dropping support for Qt 5?
>
> Looking at
> https://mail.kde.org/pipermail/distributions/2026-June/001695.html we are
> not quite there yet when it comes to getting rid of Qt5 entirely.
>

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?

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.


>
> This feels like something that is going to require work to implement and
> will be dropped in 6 months or so given the speed distros are moving at,
> and if that is the case my preference would be to just move up the end of
> support and do it all now.
>
>
Thanks,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260730/8206ef8a/attachment.htm>

From bcooksley at kde.org  Thu Jul 30 19:48:26 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Fri, 31 Jul 2026 06:48:26 +1200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <990bec77-9795-4a05-8a25-fb25a36ad8b0@email.android.com>
References: <CA+XidOEHF2TYf_xgfSwmvttxbwC8AyOcvd0zNW=dew73bMeVuQ@mail.gmail.com>
 <990bec77-9795-4a05-8a25-fb25a36ad8b0@email.android.com>
Message-ID: <CA+XidOG6W_z-S8ejyyLfaZX01+xOyU41XKtyemOgc_e3HzsTQg@mail.gmail.com>

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/plasma-devel/attachments/20260731/14af5388/attachment.htm>

From kde at david-redondo.de  Fri Jul 31 10:15:00 2026
From: kde at david-redondo.de (David Redondo)
Date: Fri, 31 Jul 2026 11:15:00 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <CA+XidOFFEFPE8jHJg9Lf47HwK8iTWHj7CqyTXV8h8FXiKkR6cQ@mail.gmail.com>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <4H2KBzzkTXy5zjwFW85Vgw@david-redondo.de>
 <CA+XidOFFEFPE8jHJg9Lf47HwK8iTWHj7CqyTXV8h8FXiKkR6cQ@mail.gmail.com>
Message-ID: <pxgON0zHSn-trQmiDirLUQ@david-redondo.de>

Am Donnerstag, 30. Juli 2026, 20:53 schrieb Ben Cooksley:
> On Fri, Jul 31, 2026 at 3:47 AM David Redondo <kde at david-redondo.de> wrote:
> 
> > Am Donnerstag, 30. Juli 2026, 17:22 schrieb Ingo Klöcker:
> > > On Dienstag, 28. Juli 2026 23:36:20 Mitteleuropäische Sommerzeit Albert
> > Astals
> > > Cid wrote:
> > > > El dimarts, 28 de juliol del 2026, a les 13:20:56 (Hora d’estiu
> > d’Europa
> > > > central), Nicolas Fella va escriure:
> > > > > That said, we have a number of (Plasma) components that we still
> > build
> > > > > for Qt5 for (external) application compatibility (breeze,
> > > > > plasma-integration, etc). So far we have not made a decision to stop
> > > > > doing that, and I'd rather not lose CI for those. That doesn't mean
> > we
> > > > > need Qt5 CI in the current form. Could we use a distribution image
> > with
> > > > > Qt and the few necessary libraries/frameworks baked in? That would
> > be a
> > > > > much smaller image and easier to maintain than the current suse-
qt515
> > > > > image.
> > > >
> > > > Does the code of those repos change in qt5 related areas?
> > > >
> > > > Trying to understand what we want CI for here:
> > > >  * Potentially new qt5 code builds with old qt5/gcc distros?
> > > >  * Non changing qt5 code builds new gcc/stuff from distros?
> > >
> > > Additionally to Albert's questions I don't understand why distros that
> > still
> > > need Qt 5 builds of breeze and plasma-integration cannot simply build
> > the
> > > latest released versions that support(ed) Qt 5. Why do they need the
> > latest
> > > and greatest breeze and plasma-integration for the remaining Qt 5 apps
> > which
> > > probably haven't seen a release in years? Does plasma-integration need
> > to
> > > match the version of Plasma?
> > >
> > > Regards,
> > > Ingo
> > >
> > We did this with Plasma 5 and Qt 4 things.
> > For Plasma 6 we decided that we want applications to look and behave the
> > same
> > no matter if they use Qt 5 and Qt6. To the user Qt5 vs. Qt6 makes no
> > difference
> > and they would be confused or file a bug if some applications randomly
> > look and
> > behave differently.
> > For example single click vs. double click which was changed in Plasma 6.0
> > or breeze which received user visible changes since 6.0.
> >
> 
> So the Plasma developers want to keep supporting Qt 5 for essentially
> eternity and never drop support for it?
> 
> At what point do you stop, or do you just keep continuing to maintain
> compatibility because one distribution doesn't want to drop
> $unmaintainedQt5App?

(readding dropped lists)

I dont't know the concrete point in time  but  given that there are some big 
applications on still on Qt5 I would say it's too early now.

Btw Plasma 5 dropped support of Qt4 builds of breeze and oxygen  in 2020 with 
5.18, see
https://mail.kde.org/pipermail/plasma-devel/2020-January/108585.html

I don't think we need an image provided by sysadmin and build kf5 on our CI
infra. Couldn't we just download a image of $LTS distro like okular does?

https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?
ref_type=heads#L24

> Will Plasma developers keep Qt 5 installed on their local machines and
> perform appropriate testing for that with the legacy, unported applications
> still using Qt 5?
> Just having CI compile something isn't a true test as to whether it works
> or not and risks silent bitrot taking place due to behaviour differences
> between Qt 5 and Qt 6.
> 
> 
> >
> > Cheers,
> > David
> >
> >
> Regards,
> Ben
> 





From bcooksley at kde.org  Fri Jul 31 10:34:22 2026
From: bcooksley at kde.org (Ben Cooksley)
Date: Fri, 31 Jul 2026 21:34:22 +1200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <pxgON0zHSn-trQmiDirLUQ@david-redondo.de>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <4H2KBzzkTXy5zjwFW85Vgw@david-redondo.de>
 <CA+XidOFFEFPE8jHJg9Lf47HwK8iTWHj7CqyTXV8h8FXiKkR6cQ@mail.gmail.com>
 <pxgON0zHSn-trQmiDirLUQ@david-redondo.de>
Message-ID: <CA+XidOFLidzjH2bg-1L6Y=RPSuQYTU59V241-hGxF-ahi20U6w@mail.gmail.com>

On Fri, Jul 31, 2026 at 9:15 PM David Redondo <kde at david-redondo.de> wrote:

> Am Donnerstag, 30. Juli 2026, 20:53 schrieb Ben Cooksley:
> > On Fri, Jul 31, 2026 at 3:47 AM David Redondo <kde at david-redondo.de>
> wrote:
> >
> [Snip]
> >
> > So the Plasma developers want to keep supporting Qt 5 for essentially
> > eternity and never drop support for it?
> >
> > At what point do you stop, or do you just keep continuing to maintain
> > compatibility because one distribution doesn't want to drop
> > $unmaintainedQt5App?
>
> (readding dropped lists)
>
> I dont't know the concrete point in time  but  given that there are some
> big
> applications on still on Qt5 I would say it's too early now.
>

Please quantify that and list the applications you consider "big" that need
to have ported before this can be abandoned.


>
> Btw Plasma 5 dropped support of Qt4 builds of breeze and oxygen  in 2020
> with
> 5.18, see
> https://mail.kde.org/pipermail/plasma-devel/2020-January/108585.html


>
> I don't think we need an image provided by sysadmin and build kf5 on our CI
> infra. Couldn't we just download a image of $LTS distro like okular does?
>
> https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?
> ref_type=heads#L24
> <https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?ref_type=heads#L24>


Depends on the number of times your job runs.
Doing jobs that way is expensive because everytime the job runs it
re-fetches every single dependency from distribution archives and installs
them in the container before it even starts building.


>
>
> > Will Plasma developers keep Qt 5 installed on their local machines and
> > perform appropriate testing for that with the legacy, unported
> applications
> > still using Qt 5?
> > Just having CI compile something isn't a true test as to whether it works
> > or not and risks silent bitrot taking place due to behaviour differences
> > between Qt 5 and Qt 6.
> >
> >
> > >
> > > Cheers,
> > > David
> > >
> > >
> > Regards,
> > Ben
> >


Regards,
Ben
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260731/87396107/attachment.htm>

From kde at david-redondo.de  Fri Jul 31 14:17:36 2026
From: kde at david-redondo.de (David Redondo)
Date: Fri, 31 Jul 2026 15:17:36 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <CA+XidOFLidzjH2bg-1L6Y=RPSuQYTU59V241-hGxF-ahi20U6w@mail.gmail.com>
References: <CA+XidOGm8yh+eu87b_5Cfh8pxn_t72OcwUPc2558TbUypWOjyQ@mail.gmail.com>
 <pxgON0zHSn-trQmiDirLUQ@david-redondo.de>
 <CA+XidOFLidzjH2bg-1L6Y=RPSuQYTU59V241-hGxF-ahi20U6w@mail.gmail.com>
Message-ID: <yEv0HR-qTY2SnGCz4Vs_VQ@david-redondo.de>

Am Freitag, 31. Juli 2026, 11:34 schrieb Ben Cooksley:
> On Fri, Jul 31, 2026 at 9:15 PM David Redondo <kde at david-redondo.de> wrote:
> 
> > Am Donnerstag, 30. Juli 2026, 20:53 schrieb Ben Cooksley:
> > > On Fri, Jul 31, 2026 at 3:47 AM David Redondo <kde at david-redondo.de>
> > wrote:
> > >
> > [Snip]
> > >
> > > So the Plasma developers want to keep supporting Qt 5 for essentially
> > > eternity and never drop support for it?
> > >
> > > At what point do you stop, or do you just keep continuing to maintain
> > > compatibility because one distribution doesn't want to drop
> > > $unmaintainedQt5App?
> >
> > (readding dropped lists)
> >
> > I dont't know the concrete point in time  but  given that there are some
> > big
> > applications on still on Qt5 I would say it's too early now.
> >
> 
> Please quantify that and list the applications you consider "big" that need
> to have ported before this can be abandoned.
> 
> 
> >
> > Btw Plasma 5 dropped support of Qt4 builds of breeze and oxygen  in 2020
> > with
> > 5.18, see
> > https://mail.kde.org/pipermail/plasma-devel/2020-January/108585.html
> 
> 
> >
> > I don't think we need an image provided by sysadmin and build kf5 on our CI
> > infra. Couldn't we just download a image of $LTS distro like okular does?
> >
> > https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?
> > ref_type=heads#L24
> > <https://invent.kde.org/graphics/okular/-/blob/master/.gitlab-ci.yml?ref_type=heads#L24>
> 
> 
> Depends on the number of times your job runs.
> Doing jobs that way is expensive because everytime the job runs it
> re-fetches every single dependency from distribution archives and installs
> them in the container before it even starts building.
> 

I've typed it up for breeze here:
https://invent.kde.org/plasma/breeze/-/merge_requests/630
job is here:
https://invent.kde.org/plasma/breeze/-/jobs/4788674

Because of the inclusion of all our default rules, it runs only when triggered manually
like all the other Plasma build jobs. 

> >
> > > Will Plasma developers keep Qt 5 installed on their local machines and
> > > perform appropriate testing for that with the legacy, unported
> > applications
> > > still using Qt 5?
> > > Just having CI compile something isn't a true test as to whether it works
> > > or not and risks silent bitrot taking place due to behaviour differences
> > > between Qt 5 and Qt 6.
> > >
> > >
> > > >
> > > > Cheers,
> > > > David
> > > >
> > > >
> > > Regards,
> > > Ben
> > >
> 
> 
> Regards,
> Ben
> 





From albertvaka at gmail.com  Tue Jul 28 13:30:14 2026
From: albertvaka at gmail.com (Albert Vaca Cintora)
Date: Tue, 28 Jul 2026 14:30:14 +0200
Subject: Changing CI builds to RelWithDebInfo from Debug
In-Reply-To: <qb6-OC9qSfmkCHGuS5pEzg@kde.org>
References: <CA+XidOGFnfwJE=LqyjuYxZJANzrQYfURnWxk2YNXBu0gdmM3qA@mail.gmail.com>
 <cb0b3f36-14b2-4624-94fb-d078101af5a0@gmx.de> <qb6-OC9qSfmkCHGuS5pEzg@kde.org>
Message-ID: <CAAQViEudEULxd=dmKOc--nXH0wJ7aLbYuGyK90BB9JuFewgm9g@mail.gmail.com>

Seems like a good idea to me. Since trying it is cheap, I would say we do
that and compare both size and CI time. I expect the compile time to go up
but the test time to go down (thanks to the optimized code), so it's hard
to predict if overall we will gain or lose in total time. We can decide if
it's worth it when we see the difference in size and time.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260728/a1265345/attachment.htm>

From mail at kisaragi-hiu.com  Thu Jul 30 13:01:29 2026
From: mail at kisaragi-hiu.com (Kisaragi Hiu)
Date: Thu, 30 Jul 2026 21:01:29 +0900
Subject: Decommissioning Qt 5 CI
In-Reply-To: <CA+XidOEHF2TYf_xgfSwmvttxbwC8AyOcvd0zNW=dew73bMeVuQ@mail.gmail.com>
Message-ID: <990bec77-9795-4a05-8a25-fb25a36ad8b0@email.android.com>

An HTML attachment was scrubbed...
URL: <http://mail.kde.org/pipermail/plasma-devel/attachments/20260730/699284d0/attachment.htm>

From foss at grueninger.de  Thu Jul 30 22:33:44 2026
From: foss at grueninger.de (=?UTF-8?Q?Christoph_Gr=C3=BCninger?=)
Date: Thu, 30 Jul 2026 23:33:44 +0200
Subject: Decommissioning Qt 5 CI
In-Reply-To: <990bec77-9795-4a05-8a25-fb25a36ad8b0@email.android.com>
References: <990bec77-9795-4a05-8a25-fb25a36ad8b0@email.android.com>
Message-ID: <ac4c46d3-8693-4c61-868e-66ea76d42473@grueninger.de>

Hi!

> > 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.

I asked openSuse and it does not sound as if they are planning to retire 
Qt 5 soon [1]:

 > dependson libqt5-qtbase | wc -l
 > 432
 >
 > That feels even more optimistic than eliminating GTK2 (which
 > lists 231 dependents)

I agree with Ben that we should try to drop Qt 5 in CI. It is a chicken 
and egg problem. The projects don't feel any pressure to finally move to 
Qt 6 thus the numbers don't get down.
What about Krita, is there a Qt 6 release available?

[1] 
https://lists.opensuse.org/archives/list/factory at lists.opensuse.org/thread/KYPVVTNSDHHGU6AVSCYFQ4NSUO6G3HTR/

Bye
Christoph

-- 
Most customers will not accept source code with compile errors in it.
                  Dan Saks, CppCon 2016 (https://youtu.be/D7Sd8A6_fYU)


