** 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/

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=66b734dfc611f5cd0a80... ). Possibly even massive patching, if they mass-introduced some uses of new Qt 5.12 API.

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 Mon, Dec 16, 2019 at 8:36 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote: > > On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson <tdawson(a)redhat.com&gt; 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

On Fri, Jan 31, 2020 at 12:33 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote: > > On Fri, Dec 20, 2019 at 7:32 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote: > > > > On Mon, Dec 16, 2019 at 8:36 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote: > > > > > > On Fri, Dec 13, 2019 at 7:29 AM Troy Dawson <tdawson(a)redhat.com&gt; 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