I just want to confirm, you want me to put git builds of Frameworks and Plasma 6 into Rawhide (F40)?

Let's start with getting KF6 in first and adjust KF5 packages accordingly per the wiki page linked in the ticket description.

From git is OK in Rawhide? As there's no Frameworks 6 releases tags/tarballs yet.

Yes.

These are going to be new kf6-* packages, so being snapshots going into Rawhide is fine.

Alrighty. I guess because they'll be new packages each one will have to go through package review?

Yeah. It should be straightforward to get reviews from any of us in the SIG though.

https://bugzilla.redhat.com/show_bug.cgi?id=2235550 let's get this started!

Tracking bug in RHBZ for package reviews: https://bugzilla.redhat.com/show_bug.cgi?id=2235556

Let's start with getting KF6 in first and adjust KF5 packages accordingly per the wiki page linked in the ticket description.

So we will use kf6 kwalletd, baloo indexer, etc... in Plasma 5 until the switch? Is that meant to work? I would have thought disabling them in the kf6 packages until the switch made more sense

It is supposed to work, since they are services that operate with agnostic interfaces.

For reference, here's the nightly copr we can start smithing specs from: https://copr.fedorainfracloud.org/coprs/g/kdesig/kde-nightly-qt6/

wrt kapidox, it should only be a build-time only dep, and the package consists of some scripts and a python module, none of which are versioned, it has no kf deps, not even ECM. also, upstream master is behind the kf5 branch. so I have to ask 1) would this still be used for building kf6, 2) why would it need to be parallel installable, and 3) should it just be renamed to e.g. "kapidox" and used for both 5 and 6 much like ECM?

I just checked with @nicolasfella and David Edmundson about this in the KF6 meeting, and apparently this thing is only supposed to be used for api.kde.org, and nobody is sure why this is a framework in the first place.

We should check if anything uses it. If not, let's just ignore it and not ship a kf6 version at all, and consider retiring the kf5 version too.

I guess it was placed in frameworks because it's in that namespace https://invent.kde.org/frameworks/kapidox - if you chat with them during the next meeting Neal maybe suggest it gets moved to the Sdk namespace https://invent.kde.org/sdk/

@ngompa Do you know some people that can help do reviews for those new KDE frameworks? I get that it's alot for one single person to run though.

I know that @siosm, @tdawson, and @yselkowitz offered to help at the last SIG meeting. Maybe reach out to them?

This week (should) be a week that I can do some reviews. I've grabbed two. We'll see how far I get today.

@salimma also stated he was willing to help out too. :100:

Good because tonight, I feel like I will sink my teeth into some more package requests XD

I've updated the statuses to make it a bit easier for reviewers to pick what they want to review. Please update the statuses if you do pick to review one! Thanks!

PSA: The Fedora LookAndFeel needs some adjustments for Plasma 6

See e.g. https://invent.kde.org/plasma/plasma-workspace/-/commit/989ddc9c34a368d4c814ed5127b81c3b1e83073d, but I'd recommend to review and compare it to current Breeze

PSA: The Fedora LookAndFeel needs some adjustments for Plasma 6

See e.g. https://invent.kde.org/plasma/plasma-workspace/-/commit/989ddc9c34a368d4c814ed5127b81c3b1e83073d, but I'd recommend to review and compare it to current Breeze

Thanks for that, when we get there, I'll definitely make sure to redo Fedora Breeze.

qqc2-desktop-style needs to be renamed for kf5 to kf5-qqc2-desktop-style and I changed the qqc2-desktop-style here to be kf6-qqc2-desktop-style (As we discussed in Matrix)

I'm starting a second table of things I've had to upgrade or build for qt6 in my Copr to facilitate the full KDE Plasma 6 + Apps.

kuserfeedback is broken at the moment, it is neither coinstallable nor are the files fully adapted for Qt 6.

From KDE Core Devel Mailing List:

8 November 2023: Alpha
  KDE Gear 24.01.75 / KDE Plasma 5.80.0 / KDE Frameworks 5.245.0


29 November 2023: Beta 1
  KDE Gear 24.01.80 / KDE Plasma 5.90.0 / KDE Frameworks 5.246.0


20 December 2023: Beta 2
  KDE Gear 24.01.85 / KDE Plasma 5.91.0 / KDE Frameworks 5.247.0


10 January 2024: Release Candidate 1
  KDE Gear 24.01.90 / KDE Plasma 5.92.0 / KDE Frameworks 5.248.0
    For KDE Gear that want to ship with Qt6 for this release they need to be 
switched to Qt6 (and obviously stable) *BEFORE* this date.


31 January 2024: Release Candidate 2
  KDE Gear 24.01.95 / KDE Plasma 5.93.0 / KDE Frameworks 5.249.0


21 February 2024: Private Tarball Release
  KDE Gear 24.02.0 / KDE Plasma 6.0 / KDE Frameworks 6.0


28 February 2024: Public Release
  KDE Gear 24.02.0 / KDE Plasma 6.0 / KDE Frameworks 6.0 

Plasma build on copr tracking:

https://pagure.io/fedora-kde/kde6dev-rpmspecs/
https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-6-unstable/

Updated justin's post about side packages with a status column.

Per today's meeting, we're going to get everything ready in copr (https://copr.fedorainfracloud.org/coprs/g/kdesig/plasma-6-unstable/) and, once everything is ready, push it over to rawhide.

The specs used to build in copr should be uploaded in this pagure: https://pagure.io/fedora-kde/kde6dev-rpmspecs/

I've got many of the builds done in https://copr.fedorainfracloud.org/coprs/g/kdesig/kde-nightly-qt6/ but most are just -qt6 builds, not dual qt5+qt6.

Just an update on this, all frameworks' specs are switched over to the kde release website. The stable macros in kf6 are broken right now, and I'm working through the list to fix spec issues.

The last stable build in my copr right now is kpackage, once everything is verified as functional I'll push everything to rawhide.

Here's a list of the frameworks as it stands, quite a few of them got removed. I used the above frameworks review list as a baseline:

1
kf6
extra-cmake-modules

2
kf6-modemmanager-qt
kf6-karchive
kf6-kplotting
kf6-networkmanager-qt
kf6-kquickcharts
kf6-bluez-qt
kf6-syntax-highlighting
kf6-solid
kf6-kguiaddons
kf6-kholidays
kf6-threadweaver
kf6-kdbusaddons
kf6-kidletime
kf6-kwidgetsaddons
kf6-sonnet
kf6-kdnssd
kf6-kitemviews
kf6-kcodecs
kf6-kitemmodels
kf6-kcalendarcore
kf6-prison
kf6-kcoreaddons
kf6-kwindowsystem
kf6-kconfig
kf6-attica
kf6-kirigami
kf6-ki18n
kf6-ktexttemplate
kf6-kuserfeedback
breeze-icon-theme

3
kf6-kcolorscheme
kf6-kimageformats
kf6-kcrash
kf6-kauth
kf6-kcompletion
kf6-knotifications
kf6-kcontacts
kf6-kdoctools
kf6-kfilemetadata
kf6-kpty
kf6-kunitconversion

4
kf6-kjobwidgets
kf6-kservice
kf6-kconfigwidgets
kf6-kglobalaccel
kf6-kpackage

5
kf6-kded
kf6-kdesu
kf6-kpeople
kf6-kiconthemes

6
kf6-ktextwidgets

7
kf6-qqc2-desktop-style
kf6-kwallet
kf6-kxmlgui

8
kf6-kbookmarks

9
kf6-kio

10
kf6-kcmutils

11
kf6-knotifyconfig
kf6-kparts
kf6-kdeclarative
kf6-kdav
kf6-baloo
kf6-syndication
kf6-krunner

12
kf6-knewstuff
kf6-purpose
kf6-ktexteditor
kf6-ksvg

13
kf6-frameworkintegration
kf6-kstatusnotifieritem

Time for apps! Edit this and put what you're working on. I'm doing small one build apps for now and putting them straight into Rawhide. Working on Qt6-only apps from https://community.kde.org/KDE_Gear/24.02_Release_notes

TODO ACCOUNTS STACK FOR BETA:
libaccounts-glib
libaccounts-qt (add qt6 subpackage)
signon (split into qt5 and qt6 subpackages)
kaccounts-integration (split into qt5 and qt6 subpackages)
kaccounts-providers (split into qt5 and qt6 subpackages)

SDDM dynamically loads layer-shell-qt, but that is now only built against Qt6.
We should update sddm to Qt6, and also add an explicit Requires: layer-shell-qt to sddm-wayland-plasma

If instead you have evidence of layer-shell-qt being used by other qt5 apps, we should make it available for both qt5 and qt6

I'll start working on Akonadi (And akonadi-related packages).

Setting the default wallpaper doesn't work https://bugs.kde.org/show_bug.cgi?id=477338

Plasma 6 sidetag: f40-build-side-78272

New package review requests:

It looks like kirigami and kirigami-addons are losing the "2" suffix in beta, so we probably should be prepared to rename those two kf6 packages.

libktorrent sources are also being renamed in Beta from KF6Torrent to KTorrent6, with ktorrent using it. We never created a kf6-libktorrent, so I suppose we should resurrect libktorrent for this. kget is still on KF5, so both will need to remain for now; afaics the one problem with them coexisting being their translations: https://invent.kde.org/network/libktorrent/-/issues/1

kquickimageeditor has a new 0.3.0 release which supports both Qt 5 and 6, but the same cmake directory/package name is used for either build, so building both would collide without further changes (or separate SRPMs with explicit Conflicts). Its consumers are still split: koko and neochat are gear and migrated to 6, where kaidan is non-gear and still on 5.

kquickimageeditor has a new 0.3.0 release which supports both Qt 5 and 6, but the same cmake directory/package name is used for either build, so building both would collide without further changes (or explicit Conflicts).

I'm not sure this works but i think so? https://invent.kde.org/libraries/kquickimageeditor/-/merge_requests/23

EDIT: merged!

This is just for me to track my progress on akonadi/kpim stuff:

?
kpublictransport (Doesn't require anything from PIM, but required for kpublictransport, Done)
0
grantleetheme (Done)
kaccounts-integration (Done, git, dual build)
kaccounts-providers (done, git)
kontactinterface (Done)
ktextaddons (Done)
kpkpass (Done)
ksmtp (Done)
libkdepim (Done)
libkgapi (Done)
libkleo (Done)
kdiagram (Done)
1
kmime (Done)
kpimtextedit (Done)
akonadi (Done) (Fedora name: akonadi-server)
kio-gdrive (Done)
kmbox Done
2
kitinerary Done
kimap (Done)
kidentitymanagement (Done)
kldap (Done)
akonadi-mime (Done)
akonadi-notes (Done)
kcalutils (Done)
mimetreeparser Done (New Package)
3
akonadi-contacts Done
akonadi-search (Done)
kleopatra (Done)
kmail-account-wizard (Done)
ktnef (Done)
kmailtransport (Done)
4
kalarm Done
pimcommon Done
5
kaddressbook Done
knotes Done
kontact Done
libgravatar (Done)
libksieve (Done)
mailimporter (Done)
6
messagelib Done
pim-sieve-editor Done
7
akonadi-calendar Done
akregator Done
grantlee-editor Done
mailcommon Done
8
akonadi-import-wizard Done
calendarsupport Done
kdepim-runtime Done
kmail done
mbox-importer Done
merkuro Done
pim-data-exporter Done
zanshin Done
9
akonadi-calendar-tools Done
akonadiconsole Done
eventviews Done
10
incidenceeditor Done
11
kdepim-addons Done
korganizer Done
kgpg

Akonadi side-tag: f40-build-side-78580

Packages to (maybe) re-enable KAccoun for:

plasma-desktop, build time dependency (temporarily disabled upstream because not ported to Qt6)
plasma-welcome, runtime dependency (disabled upstream because in bad shape, it may or may not come back with Plasma 6.0)

libktorrent unretirement, review needed: https://bugzilla.redhat.com/show_bug.cgi?id=2252207

mpvqt review request, needed for plasmatube and tokodon: https://bugzilla.redhat.com/show_bug.cgi?id=2252678

analitza is going to be messy. It has two consumers: cantor is still on 5, while kalgebra has (together with analitza) moved to 6. However, analitza didn't change SONAME between 5 and 6 (which tbh makes no sense) nor its translation name, so even if we were to make an analitza5 compat package, they wouldn't be parallel installable. (There is also a data directory for plots, but that is easier to work around.)

The possible solutions that come to mind are:
1) port cantor to 6;
2) make analitza 6 parallel-installable with an analitza5 compat package;
3) disable the analitza/kalgebra backend in cantor (until ported to 6).

https://pagure.io/fedora-kde/SIG/issue/383#comment-887051

analitza is going to be messy. It has two consumers: cantor is still on 5, while kalgebra has (together with analitza) moved to 6. However, analitza didn't change SONAME between 5 and 6 (which tbh makes no sense) nor its translation name, so even if we were to make an analitza5 compat package, they wouldn't be parallel installable.

Perhaps we could file an issue at KDE's bug tracker about this? After all, there are enough changes in Qt6 for a new API version in my and your eyes.

For now, I have disabled the kalgebra/analitza backend in cantor. Beta 1 builds of cantor, along with those education apps and libraries that have been ported, are complete and on their way to rawhide: https://bodhi.fedoraproject.org/updates/FEDORA-2023-6371403424

68 gear packages are now on Qt6 with version 24.01.80 in rawhide.

These four packages need dependencies:

audiotube (needs qcoro 0.10)
koko (needs qt6 kquickimageditor)
neochat (needs qt6 kquickimageditor)
qmlkonsole (needs qt6 qtermwidget)

The CD packages (audiocd-kio, libkcddb, and libkcompactdisc) are supposed to be built for 5 and 6 (since k3b is still on 5). Currently those package names are in use for KDE4 versions which still have dependents. The Qt5 versions are all prefixed kf5-, but of course the Qt6 versions are deframeworked. How we handle those probably depends if they will be buildable for 5+6 for the forseeable future or not. Is renaming the KDE4 versions (as compats) a possibility?

A few games and both games libs are already built in f40-build-side-78884, but there are still ~35 games to go.

I haven't touched the PIM suite or the travel components.

FYI digikam built with Qt6 for F40+ for qt6_qtwebengine_arches. For other arches with Qt5 (for ppc64 qtwebkit used instead of qtwebengine but no qtwebkit for Qt6).

Missing Qt6 deps marble, kf6-libksane, ksanecore temporary disabled.

The CD packages (audiocd-kio, libkcddb, and libkcompactdisc) are supposed to be built for 5 and 6 (since k3b is still on 5). Currently those package names are in use for KDE4 versions which still have dependents. The Qt5 versions are all prefixed kf5-, but of course the Qt6 versions are deframeworked. How we handle those probably depends if they will be buildable for 5+6 for the forseeable future or not. Is renaming the KDE4 versions (as compats) a possibility?

Yes, we can do that, we just need a naming convention for that... Maybe kde4- prefix or -qt4 suffix?

This is a great document: https://mail.kde.org/pipermail/distributions/2023-December/001468.html

We are missing a lot of explicit dependencies on the -part packages. We should go add them all and make new packages for the still necessary plasma5 parts (double check if the projects are actually not ported to Qt6 as things move fast)

KPim Update is in: https://bodhi.fedoraproject.org/updates/FEDORA-2023-ad16578136

The CD packages (audiocd-kio, libkcddb, and libkcompactdisc) are supposed to be built for 5 and 6 (since k3b is still on 5). Currently those package names are in use for KDE4 versions which still have dependents. The Qt5 versions are all prefixed kf5-, but of course the Qt6 versions are deframeworked. How we handle those probably depends if they will be buildable for 5+6 for the forseeable future or not. Is renaming the KDE4 versions (as compats) a possibility?

Yes, we can do that, we just need a naming convention for that... Maybe kde4- prefix or -qt4 suffix?

Following up on this, the consumers of the KDE4 audiocd components are:

• amarok: iirc @marcdeop said this has been ported to KF5 in gitlab; can we update that to git snapshots?
• audex: ported to KF5 in gitlab; filed PR to update to a git snapshot
• kaudiocreator: retired a few weeks ago
• kscd: archived upstream

So, if we can migrate amarok and audex to KF5-based git snapshots and retire kscd, then we won't need KDE4 compat packages. Is that doable?

I think so.

Audex is on KF5 now, and could go to KF6 once libkcddb is sorted.

for the kapidox discussion, please see https://pagure.io/fedora-kde/SIG/issue/441

Final rush! Missing updates:

Misc:
audex (update to 0.98 and KF6)
amarok (update to git snapshot and KF5)

Gear:
colord-kde (waiting for qt6 port, not useful otherwise)
libkomparediff2 + kompare + kdevelop (waiting for kdevelop qt6)
kmix (Done)
konversation (Done)
krecorder (Done)
ktouch (Done)
kwave (Done)
marble (Done)
poxml (Done)
rocs (Done)
umbrello (Done)

amarok (KF5-based git snapshot) is done in rawhide.

TODO: Follow ksnip, kImageAnnotator, kColorPicker for Qt6 releases, and enable the latter two as build dependencies for gwenview which will use them in RC2: https://invent.kde.org/graphics/gwenview/-/merge_requests/245

Specifically, if we can wait for ksnip to be ported to Qt6 we don't need to build the two libraries for both Qt5 and Qt6

Also:
libkipi: Still on qt5, no update in a long time
kipi-plugins: Same as libkipi
kde-dev-scripts: should be updatable, will do once RC1 hits.

Also:
libkipi: Still on qt5, no update in a long time
kipi-plugins: Same as libkipi
kde-dev-scripts: should be updatable, will do once RC1 hits.

IIRC kipi was somehow related to digikam. Digikam already is Qt6/KF6 for F40 and kipi-plugins are commented out in the spec:

Recommends: kf5-kipi-plugins

Is there any other consumer of kipi in rawhide ? (sorry can't look that up myself)

Is there any other consumer of kipi in rawhide ? (sorry can't look that up myself)

There isn't, but it's a bit early to drop it considering that it's being released with each KDE6 Megarelease milestone

Ah also digikam is doing the thing where it only builds against qt6 if it's a qt6webengine arch, otherwise falls back to qt5, so it could still use kipi

Ah also digikam is doing the thing where it only builds against qt6 if it's a qt6webengine arch, otherwise falls back to qt5, so it could still use kipi

I would strip out Qt5/KF5 completely. The only reason to keep this in the spec is only for keeping it with this version in F38/39, in F40 it's not needed anymore. So for me it's an either-or, not a we keep both, but I'm not the maintainer of the package to decide about how much work I put into newer updates for lower Fedora versions

The only reason to keep this in the spec is only for keeping it with this version in F38/39

As i wrote, it's also used to keep digikam available in f40 for s390x and ppc64le

This is effectively complete now that Plasma 6.0 has landed in F40+.