My apologies for not listening to others about KDE on EPEL8. As promised, this will be an open discussion. What I propose will just be a suggestion.
People have correctly pointed out that it would be best if we do not have the main KDE in epel8 be a module. It would make things more stable and compatible if we used the QT5 packages from RHEL8 as our basis, and go from there.
With that in mind, these are the things that I think are good ideas.
* No kde4 or kde3
* Follow the KDE LTS branches as much as possible. ** qt5 *** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest get built with 5.12.x *** If RHEL8 updates their qt5, adjust with them. *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the same LTS stream as qt5 (currently 5.12) *** https://download.kde.org/stable/plasma/5.12.9/ ** kf5 *** Pick a stream and stick with it ?? *** I don't know of kf5 having an LTS stream. *** Try to keep all the kf5 packages at the same stream *** https://download.kde.org/stable/frameworks/ ** KDE apps *** Let the version be the decision of each app maintainer ???
* For qt5, plasma and kf5, have a group be the the maintainer. * For the apps, let it be maintained by either a group or individual. Depending on the app.
What do people think? Troy
(resending to the list)
Troy Dawson ha scritto:
** kf5 *** Pick a stream and stick with it ?? *** I don't know of kf5 having an LTS stream. *** Try to keep all the kf5 packages at the same stream *** https://download.kde.org/stable/frameworks/
Quick notes: - Frameworks has no stable stream and keeps binary compatibility. - All the Frameworks packages must be updated at the same time.
Troy Dawson wrote:
** plasma *** Follow the same LTS stream as qt5 (currently 5.12) *** https://download.kde.org/stable/plasma/5.12.9/
Please note that Plasma version numbers are not in sync with Qt version numbers. Plasma 5.12 LTS targets Qt 5.9 LTS, Plasma 5.18 LTS will target Qt 5.12 LTS. But unfortunately, since qt5-qtbase is stuck at 5.11.x, you will not get Plasma 5.18 LTS to build without patching/hackery (reverting commits such as https://cgit.kde.org/plasma-workspace.git/commit/?id=66b734dfc611f5cd0a807c8... ). Possibly even massive patching, if they mass-introduced some uses of new Qt 5.12 API.
Kevin Kofler
On Thu, Dec 12, 2019 at 6:08 PM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
** plasma *** Follow the same LTS stream as qt5 (currently 5.12) *** https://download.kde.org/stable/plasma/5.12.9/
Please note that Plasma version numbers are not in sync with Qt version numbers. Plasma 5.12 LTS targets Qt 5.9 LTS, Plasma 5.18 LTS will target Qt 5.12 LTS. But unfortunately, since qt5-qtbase is stuck at 5.11.x, you will not get Plasma 5.18 LTS to build without patching/hackery (reverting commits such as https://cgit.kde.org/plasma-workspace.git/commit/?id=66b734dfc611f5cd0a807c8... ). Possibly even massive patching, if they mass-introduced some uses of new Qt 5.12 API.
Thank you. I had overlooked that part. So, it looks like QT5 - 5.12 Plasma - 5.18 (when it comes out next year) Framework - 5.66
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
* Follow the KDE LTS branches as much as possible. ** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
* For qt5, plasma and kf5, have a group be the maintainer. * For apps, it depends on the app. Each app can be maintained by either a group or individual.
* module vs non-module ** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson tdawson@redhat.com wrote:
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
- Follow the KDE LTS branches as much as possible.
** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
- For qt5, plasma and kf5, have a group be the maintainer.
- For apps, it depends on the app. Each app can be maintained by
either a group or individual.
- module vs non-module
** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine.
Troy
On Mon, Dec 16, 2019 at 8:36 AM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson tdawson@redhat.com wrote:
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
- Follow the KDE LTS branches as much as possible.
** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
- For qt5, plasma and kf5, have a group be the maintainer.
- For apps, it depends on the app. Each app can be maintained by
either a group or individual.
- module vs non-module
** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine.
Troy
So, all the qt5, kf5, and plasma packages are done (except 2), along with any kde libraries needed for those to build. The count is: 194 built. about 140 not built. Before I started out on filing 140 bugzilla's for packages to get into epel8, I thought I'd step back a bit. Although we don't expect epel8 KDE to be as feature complete as Fedora, we do expect users to have a good general experience. Since the installation of kde on epel8 is by using the comps groups, I was thinking of dividing work by those.
kde-desktop This is the group people install if they want KDE. I will add all the kde elements of this to my default list (with qt5*, kf5* and plasma*). All the non-kde elements I will open a bugzilla, if they aren't already available.
kde-apps kde-media Although these are optional, they are likely the main groups people install. I will file bugzilla's for all of these not already built
kde-education kde-office kde-software-development kf5-software-development These are all optional, and usually only installed based on the users preference. I will not file bugzilla's for the packages in these. If people want them in epel8, feel free to build them and/or open bugzilla's for them.
Troy p.s. All of the qt5, kf5 and plasma (and their build dependencies) are tagged into epel8 override, with a long enough date that they should be available to build with until they are in normal epel8. So if there are packages you want to get started on right now, you should be able to.
On Fri, Dec 20, 2019 at 7:32 AM Troy Dawson tdawson@redhat.com wrote:
On Mon, Dec 16, 2019 at 8:36 AM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson tdawson@redhat.com wrote:
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
- Follow the KDE LTS branches as much as possible.
** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
- For qt5, plasma and kf5, have a group be the maintainer.
- For apps, it depends on the app. Each app can be maintained by
either a group or individual.
- module vs non-module
** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine.
Troy
So, all the qt5, kf5, and plasma packages are done (except 2), along with any kde libraries needed for those to build. The count is: 194 built. about 140 not built. Before I started out on filing 140 bugzilla's for packages to get into epel8, I thought I'd step back a bit. Although we don't expect epel8 KDE to be as feature complete as Fedora, we do expect users to have a good general experience. Since the installation of kde on epel8 is by using the comps groups, I was thinking of dividing work by those.
kde-desktop This is the group people install if they want KDE. I will add all the kde elements of this to my default list (with qt5*, kf5* and plasma*). All the non-kde elements I will open a bugzilla, if they aren't already available.
kde-apps kde-media Although these are optional, they are likely the main groups people install. I will file bugzilla's for all of these not already built
kde-education kde-office kde-software-development kf5-software-development These are all optional, and usually only installed based on the users preference. I will not file bugzilla's for the packages in these. If people want them in epel8, feel free to build them and/or open bugzilla's for them.
Troy
I'm so sorry for not updating my progress on this. I kept wanting to having everything ready, but then there was always just this one package that needed something. And now it's been over a month since I talked about the plan. So, here is the progress.
kde-desktop - All main packages done. - One dependency package still in testing.[1] - karma would be appreciated
kde-media - All done
kde-apps - Everything built, in testing [2] - karma would be appreciated.
kde-office - okular - Unless someone else already has, I'll be filing a bugzilla today for this. - Everything else ... if there is something in there you want, please file a bugzilla.
kde-education kde-software-development kf5-software-development - If there are packages in there you want, please file bugzilla's for them.
**** How to Install and/or Test 1 - ensure epel is installed, and enabled 2 - ensure codreadybuilder or PowerTools is enabled 3 - dnf --enablerepo=epel-testing group install kde-desktop 4 - (optional) dnf --enablerepo=epel-testing group install kde-media kde-apps
Note: There are some packages that show up as "No match", these packages were not able to be built[3] due to missing rhel8 devel packages.[4] At some point this will get fixed, so I will leave them in the comps file. But there were also a few qt4 packages listed that I'll try to remove from the comps file.
Thank you for your patience. Troy
[1] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e4b9339d23 [2] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-00865efa86 [3] -akregator dnfdragora kde-partitionmanager kaddressbook kget kmail korganizer kpat kontact pinentry-qt plasma-discover plasma-nm* [4] - https://pagure.io/epel/issue/62
On Fri, Jan 31, 2020 at 12:33 PM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 20, 2019 at 7:32 AM Troy Dawson tdawson@redhat.com wrote:
On Mon, Dec 16, 2019 at 8:36 AM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson tdawson@redhat.com wrote:
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
- Follow the KDE LTS branches as much as possible.
** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
- For qt5, plasma and kf5, have a group be the maintainer.
- For apps, it depends on the app. Each app can be maintained by
either a group or individual.
- module vs non-module
** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine.
Troy
So, all the qt5, kf5, and plasma packages are done (except 2), along with any kde libraries needed for those to build. The count is: 194 built. about 140 not built. Before I started out on filing 140 bugzilla's for packages to get into epel8, I thought I'd step back a bit. Although we don't expect epel8 KDE to be as feature complete as Fedora, we do expect users to have a good general experience. Since the installation of kde on epel8 is by using the comps groups, I was thinking of dividing work by those.
kde-desktop This is the group people install if they want KDE. I will add all the kde elements of this to my default list (with qt5*, kf5* and plasma*). All the non-kde elements I will open a bugzilla, if they aren't already available.
kde-apps kde-media Although these are optional, they are likely the main groups people install. I will file bugzilla's for all of these not already built
kde-education kde-office kde-software-development kf5-software-development These are all optional, and usually only installed based on the users preference. I will not file bugzilla's for the packages in these. If people want them in epel8, feel free to build them and/or open bugzilla's for them.
Troy
I'm so sorry for not updating my progress on this. I kept wanting to having everything ready, but then there was always just this one package that needed something. And now it's been over a month since I talked about the plan. So, here is the progress.
kde-desktop
- All main packages done.
- One dependency package still in testing.[1] - karma would be appreciated
kde-media
- All done
kde-apps
- Everything built, in testing [2] - karma would be appreciated.
kde-office
- okular - Unless someone else already has, I'll be filing a bugzilla
today for this.
- Everything else ... if there is something in there you want, please
file a bugzilla.
kde-education kde-software-development kf5-software-development
- If there are packages in there you want, please file bugzilla's for them.
**** How to Install and/or Test 1 - ensure epel is installed, and enabled 2 - ensure codreadybuilder or PowerTools is enabled 3 - dnf --enablerepo=epel-testing group install kde-desktop 4 - (optional) dnf --enablerepo=epel-testing group install kde-media kde-apps
Note: There are some packages that show up as "No match", these packages were not able to be built[3] due to missing rhel8 devel packages.[4] At some point this will get fixed, so I will leave them in the comps file. But there were also a few qt4 packages listed that I'll try to remove from the comps file.
Thank you for your patience. Troy
[1] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e4b9339d23 [2] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-00865efa86 [3] -akregator dnfdragora kde-partitionmanager kaddressbook kget kmail korganizer kpat kontact pinentry-qt plasma-discover plasma-nm* [4] - https://pagure.io/epel/issue/62
dnfdragora is currently blocked on a major bug in rpm that was backported to RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=1783346
On Fri, Jan 31, 2020 at 1:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Fri, Jan 31, 2020 at 12:33 PM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 20, 2019 at 7:32 AM Troy Dawson tdawson@redhat.com wrote:
On Mon, Dec 16, 2019 at 8:36 AM Troy Dawson tdawson@redhat.com wrote:
On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson tdawson@redhat.com wrote:
I'm going to summarize. Hopefully I get correctly what people have said. Feel free to continue to comment and suggest. At some point I'd like to put this on a EPEL KDE page for future guidance.
- Follow the KDE LTS branches as much as possible.
** qt5 *** RHEL's version of qt packages will dictate this. If RHEL's versions change, adjust with them. *** RHEL 8 qt5 is 5.11.1 **** There are about 10 packages that have to stay at 5.11 due to RHEL's packages. The rest can get built with the current LTS, 5.12.x *** https://download.qt.io/official_releases/qt/5.12/ ** plasma *** Follow the LTS stream that corresponds with our qt5 *** The plasma LTS stream that corresponds with qt 5.12 is plasma 5.18 **** plasma 5.18 will not be out until Feb. or March 2020. **** Keep with our current version until them, which is 5.15 *** https://download.kde.org/stable/plasma/ *** Update all plasma at one time, if possible ** framework (kf5) *** Use the stream that corresponds with our plasma *** When plasma 5.18 comes out, that will be kf5 5.66 **** Keep with our current version until plasma is updated, which is 5.59 *** https://download.kde.org/stable/frameworks/ *** Update all kf5 at one time, if possible ** KDE apps *** Let the version be the decision of each app maintainer
- For qt5, plasma and kf5, have a group be the maintainer.
- For apps, it depends on the app. Each app can be maintained by
either a group or individual.
- module vs non-module
** The above plan will all be for non-module kde components. This is what people get straight out of epel. ** There will be at least one kde module. *** Any epel kde modules will not be enabled by default. These are only for people who want to test with a newer kde, or want to run the latest kde and don't mind breaking some compatibility. *** There will be a kde-rawhide module. **** The kde-rawhide module will track the fedora kde packages. **** The module will be updated once a month, building whatever is in Fedora rawhide at that time. *** There might be other kde modules, but none are currently planned.
As I said, this plan is open to suggestions and comments, but here is my plan of getting things going. It's sorta logical that I be the person who at least starts things, even if we are going to maintain them as a group. If nobody has any objections, on Monday, Dec. 16, I was planning on starting building kde in standard epel, following the above guidelines. I would build the qt5, plasma and k5 packages, and open bugzilla requests for all the rest. For most everything, I will just be pulling over what is in epel8-playground. Hopefully we can get everything built, and in bodhi, by the end of the week. They can then sit and be tested while people are celebrating the end of the year holidays. And hopefully, at the beginning of the new year, they will all be ready and in the epel8 repository.
Troy
Starting the builds for regular epel8. As stated above, we will stay with the versions that we currently have in playground. Many of the qt5 packages have already been built, thank you for that. Since those were built with the epel8-playground versions and patches, that will work just fine.
Troy
So, all the qt5, kf5, and plasma packages are done (except 2), along with any kde libraries needed for those to build. The count is: 194 built. about 140 not built. Before I started out on filing 140 bugzilla's for packages to get into epel8, I thought I'd step back a bit. Although we don't expect epel8 KDE to be as feature complete as Fedora, we do expect users to have a good general experience. Since the installation of kde on epel8 is by using the comps groups, I was thinking of dividing work by those.
kde-desktop This is the group people install if they want KDE. I will add all the kde elements of this to my default list (with qt5*, kf5* and plasma*). All the non-kde elements I will open a bugzilla, if they aren't already available.
kde-apps kde-media Although these are optional, they are likely the main groups people install. I will file bugzilla's for all of these not already built
kde-education kde-office kde-software-development kf5-software-development These are all optional, and usually only installed based on the users preference. I will not file bugzilla's for the packages in these. If people want them in epel8, feel free to build them and/or open bugzilla's for them.
Troy
I'm so sorry for not updating my progress on this. I kept wanting to having everything ready, but then there was always just this one package that needed something. And now it's been over a month since I talked about the plan. So, here is the progress.
kde-desktop
- All main packages done.
- One dependency package still in testing.[1] - karma would be appreciated
kde-media
- All done
kde-apps
- Everything built, in testing [2] - karma would be appreciated.
kde-office
- okular - Unless someone else already has, I'll be filing a bugzilla
today for this.
- Everything else ... if there is something in there you want, please
file a bugzilla.
kde-education kde-software-development kf5-software-development
- If there are packages in there you want, please file bugzilla's for them.
**** How to Install and/or Test 1 - ensure epel is installed, and enabled 2 - ensure codreadybuilder or PowerTools is enabled 3 - dnf --enablerepo=epel-testing group install kde-desktop 4 - (optional) dnf --enablerepo=epel-testing group install kde-media kde-apps
Note: There are some packages that show up as "No match", these packages were not able to be built[3] due to missing rhel8 devel packages.[4] At some point this will get fixed, so I will leave them in the comps file. But there were also a few qt4 packages listed that I'll try to remove from the comps file.
Thank you for your patience. Troy
[1] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-e4b9339d23 [2] - https://bodhi.fedoraproject.org/updates/FEDORA-EPEL-2020-00865efa86 [3] -akregator dnfdragora kde-partitionmanager kaddressbook kget kmail korganizer kpat kontact pinentry-qt plasma-discover plasma-nm* [4] - https://pagure.io/epel/issue/62
dnfdragora is currently blocked on a major bug in rpm that was backported to RHEL 8: https://bugzilla.redhat.com/show_bug.cgi?id=1783346
Ya, and it's not really a "KDE" package, just in the group list. I included it in the list because it shows up when you do the group install. Troy
-
Kevin Kofler -
Luigi Toscano -
Neal Gompa -
Troy Dawson