I know that RHEL8 isn't out yet, but I'd like to run KDE on my RHEL8
Beta. Even if it's just the basic KDE desktop.
I'm fine building it myself, but I'm having a hard time figuring out
the rebuild flow.
If I (or anyone) were to rebuild KDE for RHEL8, where do I start? and
then what's next?
There are base QT5 packages in RHEL8 beta. Do you think I would need
to rebuild QT5? Or just start with RHEL8's QT5 packages.
Thanks
Troy

Hi,
you can use Qt 5 provided by RHEL 8, it should be almost identical to one we
have in Fedora. Problem is that I'm not sure you will have all the needed
dependencies for all packages. The goal for RHEL 8 was to keep it at minimum
regarding number of packages. Also building everything is not an easy task,
that's like hundreds of packages (frameworks, kde apps, plasma). Instead of
doing builds from rpms, I would most likely use kdesrc-build [1], which will
handle all dependencies and build chain for you, it just need to be properly
configured.
[1] - https://kdesrc-build.kde.org/
Regards,
Jan
On úterý 8. ledna 2019 16:44:15 CET Troy Dawson wrote:

Very Cool. I like that.
Hundreds of packages and their dependencies only add to the fun.
I'm going to give it a go and I'll let you know how things work out.
(Being honest, I've already tried using the "Put everything I can
think of in a directory and just retry builds until things work"
approach. That worked on quite a bit, but I can see from the output
of kdesrc-build that I was missing several fundamental packages.)
Thank You
On Tue, Jan 8, 2019 at 8:13 AM Jan Grulich <jgrulich(a)redhat.com&gt; wrote:
>
> Hi,
>
> you can use Qt 5 provided by RHEL 8, it should be almost identical to one we
> have in Fedora. Problem is that I'm not sure you will have all the needed
> dependencies for all packages. The goal for RHEL 8 was to keep it at minimum
> regarding number of packages. Also building everything is not an easy task,
> that's like hundreds of packages (frameworks, kde apps, plasma). Instead of
> doing builds from rpms, I would most likely use kdesrc-build [1], which will
> handle all dependencies and build chain for you, it just need to be properly
> configured.
>
> [1] - https://kdesrc-build.kde.org/
>
> Regards,
> Jan
>
> On úterý 8. ledna 2019 16:44:15 CET Troy Dawson wrote:
> > I know that RHEL8 isn't out yet, but I'd like to run KDE on my RHEL8
> > Beta. Even if it's just the basic KDE desktop.
> > I'm fine building it myself, but I'm having a hard time figuring out
> > the rebuild flow.
> >
> > If I (or anyone) were to rebuild KDE for RHEL8, where do I start? and
> > then what's next?
> >
> > There are base QT5 packages in RHEL8 beta. Do you think I would need
> > to rebuild QT5? Or just start with RHEL8's QT5 packages.
> >
> > Thanks
> > Troy

So, my work on this is going along slowly but still moving. I'm about
1/3 way through what was initially 350 packages.
About 1 in 3 packages needs to be tweeked in some way. Usually just
enabling bootstrap and/or disabling kde4 components.
But I've hit a package I'm having issues with, due to python vs python2/python3.
qt5-qtwebengine
For starters, it has a buildrequires for /usr/bin/python and is
running "python <command>" in the %prep section.
Those were the easy part.
But when the source actually builds, it is using "python" in the
generated Makefiles. That's much more invasive than I've had to get
with any of the other packages.
My real question is this.
Should I file a bugzilla for this (It didn't seem to get the python ->
python2/python3 treatment all the other Fedora packages got) or just
do some type of fix/workaround?
On Tue, Jan 8, 2019 at 12:10 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>
> Very Cool. I like that.
> Hundreds of packages and their dependencies only add to the fun.
> I'm going to give it a go and I'll let you know how things work out.
> (Being honest, I've already tried using the "Put everything I can
> think of in a directory and just retry builds until things work"
> approach. That worked on quite a bit, but I can see from the output
> of kdesrc-build that I was missing several fundamental packages.)
>
> Thank You
>
> On Tue, Jan 8, 2019 at 8:13 AM Jan Grulich <jgrulich(a)redhat.com&gt; wrote:
> >
> > Hi,
> >
> > you can use Qt 5 provided by RHEL 8, it should be almost identical to one we
> > have in Fedora. Problem is that I'm not sure you will have all the needed
> > dependencies for all packages. The goal for RHEL 8 was to keep it at minimum
> > regarding number of packages. Also building everything is not an easy task,
> > that's like hundreds of packages (frameworks, kde apps, plasma). Instead of
> > doing builds from rpms, I would most likely use kdesrc-build [1], which will
> > handle all dependencies and build chain for you, it just need to be properly
> > configured.
> >
> > [1] - https://kdesrc-build.kde.org/
> >
> > Regards,
> > Jan
> >
> > On úterý 8. ledna 2019 16:44:15 CET Troy Dawson wrote:
> > > I know that RHEL8 isn't out yet, but I'd like to run KDE on my
RHEL8
> > > Beta. Even if it's just the basic KDE desktop.
> > > I'm fine building it myself, but I'm having a hard time figuring
out
> > > the rebuild flow.
> > >
> > > If I (or anyone) were to rebuild KDE for RHEL8, where do I start? and
> > > then what's next?
> > >
> > > There are base QT5 packages in RHEL8 beta. Do you think I would need
> > > to rebuild QT5? Or just start with RHEL8's QT5 packages.
> > >
> > > Thanks
> > > Troy

But I've hit a package I'm having issues with, due to python
vs
python2/python3. qt5-qtwebengine
For starters, it has a buildrequires for /usr/bin/python and is
running "python <command>" in the %prep section.
Those were the easy part.
But when the source actually builds, it is using "python" in the
generated Makefiles. That's much more invasive than I've had to get
with any of the other packages.
My real question is this.
Should I file a bugzilla for this (It didn't seem to get the python ->
python2/python3 treatment all the other Fedora packages got) or just
do some type of fix/workaround?

I would strongly recommend against trying to fix anything in QtWebEngine,
that package is just such an awful mess.
I would just rebuild the Fedora python2 package including
python-unversioned-command, or build a separate python-unversioned-command
RPM if RHEL 8 has a suitable python2 and only lacks the unversioned command,
and use that.
Kevin Kofler

But I've hit a package I'm having issues with, due to python
vs
python2/python3. qt5-qtwebengine
For starters, it has a buildrequires for /usr/bin/python and is
running "python <command>" in the %prep section.

Troy Dawson wrote:
> But I've hit a package I'm having issues with, due to python vs
> python2/python3. qt5-qtwebengine
> For starters, it has a buildrequires for /usr/bin/python and is
> running "python <command>" in the %prep section.
Are you saying nothing in rhel8 provides /usr/bin/python ?

Nothing provides it. The reason given: nobody could agree what to do here[1].
The easy trick that I use for this is make a symlink to a custom path
and add it to the PATH in the package build.
Something like this:
mkdir -p .test-bin
ln -sf /usr/bin/python2 .link-bin/python
export PATH=$PWD/.link-bin:$PATH
This trick works if it's only a build-time requirement.
Alternatively, you can try to fix the shebangs everywhere...
[1]: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/
--
真実はいつも一つ！/ Always, there's only one truth!

On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter <rdieter(a)gmail.com&gt; wrote:
>
> Troy Dawson wrote:
>
> > But I've hit a package I'm having issues with, due to python vs
> > python2/python3. qt5-qtwebengine
> > For starters, it has a buildrequires for /usr/bin/python and is
> > running "python <command>" in the %prep section.
>
> Are you saying nothing in rhel8 provides /usr/bin/python ?
>
Nothing provides it. The reason given: nobody could agree what to do here[1].
The easy trick that I use for this is make a symlink to a custom path
and add it to the PATH in the package build.
Something like this:
mkdir -p .test-bin
ln -sf /usr/bin/python2 .link-bin/python
export PATH=$PWD/.link-bin:$PATH
This trick works if it's only a build-time requirement.
Alternatively, you can try to fix the shebangs everywhere...
[1]: https://developers.redhat.com/blog/2018/11/27/what-no-python-in-rhel-8-beta/

Sorry, I mean "mkdir -p .link-bin" for the first command.
--
真実はいつも一つ！/ Always, there's only one truth!

Thank you for that. I'll use it for the time being.
As was said above, at the time beta came out there was still debate.
Since almost all Fedora packages had already been converted from
python to python2/python3, the issue hadn't came up for me until this
package.
Troy

>>> Are you saying nothing in rhel8 provides /usr/bin/python
?
>>>
>>
>> Nothing provides it. The reason given: nobody could agree what to do
>> here[1].
>
> That is... unfortunate (and silly imho)
no, it just follows fedora where /usr/bin/python is deprcated and in the
future not available as symlink without manually intervention - don't
forget the lifetime of RHEL8!

I disagreed removing it in fedora was a good idea, the same holds here.
-- rex

Reindl Harald wrote:
>>>> Are you saying nothing in rhel8 provides /usr/bin/python ?
>>>>
>>>
>>> Nothing provides it. The reason given: nobody could agree what to do
>>> here[1].
>>
>> That is... unfortunate (and silly imho)
>
> no, it just follows fedora where /usr/bin/python is deprcated and in the
> future not available as symlink without manually intervention - don't
> forget the lifetime of RHEL8!
I disagreed removing it in fedora was a good idea, the same holds here.

well, the real problem is Python itself and using it for important
system tools! what happens when Python4 comes up and how many decades
will it take until existing software works with it?
after seeing what happende with KDE5 and GNOME3 - both not learning from
the KDE4 catastrophe years ago i have not much hope than Python learned
from it's history that you can't bring a completly BC incomaptible major
version and the world has to deal with it
upgrade PHP 5.6 to 7.3 is a no-brainer compared to python2-python3

> I disagreed removing it in fedora was a good idea, the same holds
here.
well, the real problem is Python itself and using it for important
system tools! what happens when Python4 comes up

Simple (imho).
Always treat /usr/bin/python as legacy python2
python4 (when it comes) will be /usr/bin/python4 just like how python3 is
/usr/bin/python3 today. No confusion, no ambiguity, no breakage.
-- Rex

Reindl Harald wrote:
>> I disagreed removing it in fedora was a good idea, the same holds here.
>
> well, the real problem is Python itself and using it for important
> system tools! what happens when Python4 comes up
Simple (imho).
Always treat /usr/bin/python as legacy python2
python4 (when it comes) will be /usr/bin/python4 just like how python3 is
/usr/bin/python3 today. No confusion, no ambiguity, no breakage.

or don't use programming languages where it takes decades until
everything works on a new version
"Always treat /usr/bin/python as legacy python2" ends in you have
pyhton2-only code forever until pyhton2 does no longer get security
updates and goes completly away from the distribution and in the worst
case probably new code is still written only running with python2
so all you do is take a technical debt and hping somebody else is paying
it back when you are gone
if PHP would act that way i simply would have ported the work of the
past 16 years to a different programming language long ago but there was
no need because i can't imagine any code which can't be easily fixed so
that it works on 7.3 even when it was originally written in 2002

Reindl Harald wrote:
> and hence it's about time to start living without /usr/bin/python which
> is unavoidable anyways
Backporting security fixes for 10 years is what people pay RHEL for. If they
can't even get that done here, they can stop selling their product
altogether.

besides that without Redhat we won't have Fedora that#s not my point!
for how many decades would you like to train people that the ycan rely
on /usr/bin/python is there and is in fact python2 while any sane
programming language would just be /usr/bin/python = current major version

for how many decades would you like to train people that the ycan
rely
on /usr/bin/python is there and is in fact python2 while any sane
programming language would just be /usr/bin/python = current major version

How about forever? We still maintain qt3 and I backport security fixes to
it. Why can't that be done for python2?
Kevin Kofler

Reindl Harald wrote:
> for how many decades would you like to train people that the ycan rely
> on /usr/bin/python is there and is in fact python2 while any sane
> programming language would just be /usr/bin/python = current major version
How about forever? We still maintain qt3 and I backport security fixes to
it. Why can't that be done for python2?

On Thu, Jan 17, 2019 at 12:17:01AM +0100, Reindl Harald wrote:
>> How about forever? We still maintain qt3 and I backport security fixes to
>> it. Why can't that be done for python2?
> because it's just a waste of time
Hey, if someone thinks it's worth doing, why get upset? One person's waste
of time is another person's responsibility, good deed, or fun

well, it just would be better invested by port teh code to the nwer
version but on the other hand i couldn't c are less about python
especially after months with no usable stable kernel while patches at
least are ready since 2018-12-28 which really opens the question of
priorities given that 4.19 will be LTS and was excatly the version
released withinin Linus break and with the scheduler-corruption
https://bugzilla.redhat.com/show_bug.cgi?id=1659706https://bugzilla.kernel.org/show_bug.cgi?id=202065https://bugzilla.kernel.org/show_bug.cgi?id=202013
frankly how can one fuckup a component like iptables that way and not
fix it while the latest usaebale kernel is 4.18.20 (a Fedora 27 build
because 4.19 on F18 was way to early rebased even if that bug wouldn't
exist because the filesystem corruption at that moment was already known)

Just to let people know, I've finished this and have a working kde
desktop on a RHEL8 beta vitual machine.
After I got about halfway through, things shifted from 1 in 3 packages
having problems to 1 in 10, and then things went much faster.
Anyway, I'm going to rebuild everything again because I changed where
I was building things about 50 packages in, and my %dist tag is
different between the two, as well as libraries might be a little
different between the two.
But since I have the build-order correct, and the src.rpm's already
fixed, this should go much faster. Hopefully I should have this where
others can try it by the weekend or early next week.
For those who are curious there were about 390 packages built. About
350 of them are kde one's, while the rest are supporting packages that
aren't in RHEL8.
On Mon, Jan 14, 2019 at 6:36 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>
> So, my work on this is going along slowly but still moving. I'm about
> 1/3 way through what was initially 350 packages.
> About 1 in 3 packages needs to be tweeked in some way. Usually just
> enabling bootstrap and/or disabling kde4 components.
>
> But I've hit a package I'm having issues with, due to python vs
python2/python3.
> qt5-qtwebengine
> For starters, it has a buildrequires for /usr/bin/python and is
> running "python <command>" in the %prep section.
> Those were the easy part.
> But when the source actually builds, it is using "python" in the
> generated Makefiles. That's much more invasive than I've had to get
> with any of the other packages.
> My real question is this.
> Should I file a bugzilla for this (It didn't seem to get the python ->
> python2/python3 treatment all the other Fedora packages got) or just
> do some type of fix/workaround?
>
>
> On Tue, Jan 8, 2019 at 12:10 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
> >
> > Very Cool. I like that.
> > Hundreds of packages and their dependencies only add to the fun.
> > I'm going to give it a go and I'll let you know how things work out.
> > (Being honest, I've already tried using the "Put everything I can
> > think of in a directory and just retry builds until things work"
> > approach. That worked on quite a bit, but I can see from the output
> > of kdesrc-build that I was missing several fundamental packages.)
> >
> > Thank You
> >
> > On Tue, Jan 8, 2019 at 8:13 AM Jan Grulich <jgrulich(a)redhat.com&gt; wrote:
> > >
> > > Hi,
> > >
> > > you can use Qt 5 provided by RHEL 8, it should be almost identical to one
we
> > > have in Fedora. Problem is that I'm not sure you will have all the
needed
> > > dependencies for all packages. The goal for RHEL 8 was to keep it at
minimum
> > > regarding number of packages. Also building everything is not an easy
task,
> > > that's like hundreds of packages (frameworks, kde apps, plasma).
Instead of
> > > doing builds from rpms, I would most likely use kdesrc-build [1], which
will
> > > handle all dependencies and build chain for you, it just need to be
properly
> > > configured.
> > >
> > > [1] - https://kdesrc-build.kde.org/
> > >
> > > Regards,
> > > Jan
> > >
> > > On úterý 8. ledna 2019 16:44:15 CET Troy Dawson wrote:
> > > > I know that RHEL8 isn't out yet, but I'd like to run KDE on my
RHEL8
> > > > Beta. Even if it's just the basic KDE desktop.
> > > > I'm fine building it myself, but I'm having a hard time
figuring out
> > > > the rebuild flow.
> > > >
> > > > If I (or anyone) were to rebuild KDE for RHEL8, where do I start? and
> > > > then what's next?
> > > >
> > > > There are base QT5 packages in RHEL8 beta. Do you think I would need
> > > > to rebuild QT5? Or just start with RHEL8's QT5 packages.
> > > >
> > > > Thanks
> > > > Troy

On 1/16/19 10:28 PM, Troy Dawson wrote:
> Just to let people know, I've finished this and have a working kde
> desktop on a RHEL8 beta vitual machine.
Your work is much appreciated. I remember how I struggled to get a
decent KDE version on RHEL 6. Thanks to Rex and others, we finally had a
good enough version.

I want to second that.
The kde packages are in very good shape. Except for a few exceptions,
everything "just built". And except for a few, the packages I had to
edit was very easy to turn on the bootstrap and/or remove the qt4
stuff.
Thank you Rex, Martin, Jan and the rest of the Fedora KDE team for
making such a good product.
Troy

Rebuild is done. I have tested it on a plain, minimal install
rhel8-beta machine. Works great.
I have uploaded my build to my fedora people area. Unfortunately the
source rpm's wouldn't fit. I'll work on getting just the packages
that I changed into the source rpm area. Hopefully that trims it down
for those that want to see what got changed.
I also uploaded a repo file [1], the build order [2] , what didn't
build [3] , and a README [4] that includes how to install the desktop.
== How to install KDE on rhel8-beta
-- # First make sure you can get regular rhel8-beta packages
-- # All of these should be done as root or sudo
-- wget -O /etc/yum.repos.d/rhel8-beta-kde.repo
https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
-- dnf group install "KDE Plasma Workspaces"
-- (Optional) dnf group install kde-desktop
-- (Optional) dnf group install kde-apps
-- (Optional) dnf group install kde-media
-- (Optional) dnf group install kde-education
-- (Optional) dnf group install kde-software-development
-- (Optional) dnf group install kf5-software-development
-- # Currently gdm does not like to start plasma, use sddm instead
-- dnf install switchdesk system-switch-displaymanager
-- switchdesk kde
-- system-switch-displaymanager sddm
-- # Incase you aren't in graphical mode yet
-- systemctl set-default graphical.target
== Non-Essential, but major Packages that didn't build
- calligra (An integrated office suite)
-- too many dependencies to build at this time.
- telepathy (and everything depending on it)
-- python2 based and required python2-dbus, which isn't in RHEL8-beta
-- Since python3-dbus is in RHEL8-beta, I didn't want to be messing
with things too much.
Troy
p.s. I should have some time this weekend to get the sources that
changed into the source rpm repo ... hopefully.
[1] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
[2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.build-order
[3] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built
[4] - https://tdawson.fedorapeople.org/epel8/kde/readme.txt
On Wed, Jan 16, 2019 at 8:58 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>
> Just to let people know, I've finished this and have a working kde
> desktop on a RHEL8 beta vitual machine.
> After I got about halfway through, things shifted from 1 in 3 packages
> having problems to 1 in 10, and then things went much faster.
>
> Anyway, I'm going to rebuild everything again because I changed where
> I was building things about 50 packages in, and my %dist tag is
> different between the two, as well as libraries might be a little
> different between the two.
> But since I have the build-order correct, and the src.rpm's already
> fixed, this should go much faster. Hopefully I should have this where
> others can try it by the weekend or early next week.
> For those who are curious there were about 390 packages built. About
> 350 of them are kde one's, while the rest are supporting packages that
> aren't in RHEL8.
>
>
> On Mon, Jan 14, 2019 at 6:36 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
> >
> > So, my work on this is going along slowly but still moving. I'm about
> > 1/3 way through what was initially 350 packages.
> > About 1 in 3 packages needs to be tweeked in some way. Usually just
> > enabling bootstrap and/or disabling kde4 components.
> >
> > But I've hit a package I'm having issues with, due to python vs
python2/python3.
> > qt5-qtwebengine
> > For starters, it has a buildrequires for /usr/bin/python and is
> > running "python <command>" in the %prep section.
> > Those were the easy part.
> > But when the source actually builds, it is using "python" in the
> > generated Makefiles. That's much more invasive than I've had to get
> > with any of the other packages.
> > My real question is this.
> > Should I file a bugzilla for this (It didn't seem to get the python ->
> > python2/python3 treatment all the other Fedora packages got) or just
> > do some type of fix/workaround?
> >
> >
> > On Tue, Jan 8, 2019 at 12:10 PM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
> > >
> > > Very Cool. I like that.
> > > Hundreds of packages and their dependencies only add to the fun.
> > > I'm going to give it a go and I'll let you know how things work
out.
> > > (Being honest, I've already tried using the "Put everything I can
> > > think of in a directory and just retry builds until things work"
> > > approach. That worked on quite a bit, but I can see from the output
> > > of kdesrc-build that I was missing several fundamental packages.)
> > >
> > > Thank You
> > >
> > > On Tue, Jan 8, 2019 at 8:13 AM Jan Grulich <jgrulich(a)redhat.com&gt;
wrote:
> > > >
> > > > Hi,
> > > >
> > > > you can use Qt 5 provided by RHEL 8, it should be almost identical to
one we
> > > > have in Fedora. Problem is that I'm not sure you will have all the
needed
> > > > dependencies for all packages. The goal for RHEL 8 was to keep it at
minimum
> > > > regarding number of packages. Also building everything is not an easy
task,
> > > > that's like hundreds of packages (frameworks, kde apps, plasma).
Instead of
> > > > doing builds from rpms, I would most likely use kdesrc-build [1],
which will
> > > > handle all dependencies and build chain for you, it just need to be
properly
> > > > configured.
> > > >
> > > > [1] - https://kdesrc-build.kde.org/
> > > >
> > > > Regards,
> > > > Jan
> > > >
> > > > On úterý 8. ledna 2019 16:44:15 CET Troy Dawson wrote:
> > > > > I know that RHEL8 isn't out yet, but I'd like to run KDE
on my RHEL8
> > > > > Beta. Even if it's just the basic KDE desktop.
> > > > > I'm fine building it myself, but I'm having a hard time
figuring out
> > > > > the rebuild flow.
> > > > >
> > > > > If I (or anyone) were to rebuild KDE for RHEL8, where do I start?
and
> > > > > then what's next?
> > > > >
> > > > > There are base QT5 packages in RHEL8 beta. Do you think I would
need
> > > > > to rebuild QT5? Or just start with RHEL8's QT5 packages.
> > > > >
> > > > > Thanks
> > > > > Troy

Just a heads up, incase people are wondering.
My KDE build that I built on RHEL8 beta works [1] on RHEL8 final release.
I have taken a RHEL8-Beta, already running KDE, and updated it to
RHEL8, and everything updated, and worked [1]
I have also taken a fresh installed, and updated, RHEL8 minimal, and
run the above commands to install KDE, and it worked also.
That doesn't mean this repo will be up forever, but it should last
until we get KDE in EPEL8, whenever that happens.
Troy
[1] - worked: Means that it rebooted and came up, and a few basics
apps were tested (Konqueror, graphical file system, konsole). There
is not garantee that everything works.

On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson
<tdawson(a)redhat.com&gt; wrote:
>
> I have uploaded my build to my fedora people area. Unfortunately the
> source rpm's wouldn't fit. I'll work on getting just the packages
> that I changed into the source rpm area. Hopefully that trims it down
> for those that want to see what got changed.
> I also uploaded a repo file [1], the build order [2] , what didn't
> build [3] , and a README [4] that includes how to install the desktop.
>
> == How to install KDE on rhel8-beta
> -- # First make sure you can get regular rhel8-beta packages
> -- # All of these should be done as root or sudo
> -- wget -O /etc/yum.repos.d/rhel8-beta-kde.repo
> https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
> -- dnf group install "KDE Plasma Workspaces"
> -- (Optional) dnf group install kde-desktop
> -- (Optional) dnf group install kde-apps
> -- (Optional) dnf group install kde-media
> -- (Optional) dnf group install kde-education
> -- (Optional) dnf group install kde-software-development
> -- (Optional) dnf group install kf5-software-development
> -- # Currently gdm does not like to start plasma, use sddm instead
> -- dnf install switchdesk system-switch-displaymanager
> -- switchdesk kde
> -- system-switch-displaymanager sddm
> -- # Incase you aren't in graphical mode yet
> -- systemctl set-default graphical.target
>
> Troy
>
> [1] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
> [2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.build-order
> [3] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built
> [4] - https://tdawson.fedorapeople.org/epel8/kde/readme.txt
>
Just a heads up, incase people are wondering.
My KDE build that I built on RHEL8 beta works [1] on RHEL8 final release.
I have taken a RHEL8-Beta, already running KDE, and updated it to
RHEL8, and everything updated, and worked [1]
I have also taken a fresh installed, and updated, RHEL8 minimal, and
run the above commands to install KDE, and it worked also.
That doesn't mean this repo will be up forever, but it should last
until we get KDE in EPEL8, whenever that happens.
Troy

Thanks for your work on this. My observation is - do want KDE to be a module
for EPEL8? I'm actually slightly surprised to find that Gnome does not appear
to be modular in RHEL8, but if we face something at all like the KDE 4->plasma
transition during RHEL8's lifetime it seems like a good thing to have.
Also, I've found them quite useful for building ordered sets of dependencies
and dealing with updates.
--
Orion Poplawski
Manager of NWRA Technical Systems 720-772-5637
NWRA, Boulder/CoRA Office FAX: 303-415-9702
3380 Mitchell Lane orion(a)nwra.com
Boulder, CO 80301 https://www.nwra.com/

On 5/8/19 4:09 PM, Troy Dawson wrote:
> On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson <tdawson(a)redhat.com&gt; wrote:
>>
>> I have uploaded my build to my fedora people area. Unfortunately the
>> source rpm's wouldn't fit. I'll work on getting just the packages
>> that I changed into the source rpm area. Hopefully that trims it down
>> for those that want to see what got changed.
>> I also uploaded a repo file [1], the build order [2] , what didn't
>> build [3] , and a README [4] that includes how to install the desktop.
>>
>> == How to install KDE on rhel8-beta
>> -- # First make sure you can get regular rhel8-beta packages
>> -- # All of these should be done as root or sudo
>> -- wget -O /etc/yum.repos.d/rhel8-beta-kde.repo
>> https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
>> -- dnf group install "KDE Plasma Workspaces"
>> -- (Optional) dnf group install kde-desktop
>> -- (Optional) dnf group install kde-apps
>> -- (Optional) dnf group install kde-media
>> -- (Optional) dnf group install kde-education
>> -- (Optional) dnf group install kde-software-development
>> -- (Optional) dnf group install kf5-software-development
>> -- # Currently gdm does not like to start plasma, use sddm instead
>> -- dnf install switchdesk system-switch-displaymanager
>> -- switchdesk kde
>> -- system-switch-displaymanager sddm
>> -- # Incase you aren't in graphical mode yet
>> -- systemctl set-default graphical.target
>>
>> Troy
>>
>> [1] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.repo
>> [2] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.build-order
>> [3] - https://tdawson.fedorapeople.org/epel8/kde/rhel8-beta-kde.not-built
>> [4] - https://tdawson.fedorapeople.org/epel8/kde/readme.txt
>>
>
> Just a heads up, incase people are wondering.
> My KDE build that I built on RHEL8 beta works [1] on RHEL8 final release.
> I have taken a RHEL8-Beta, already running KDE, and updated it to
> RHEL8, and everything updated, and worked [1]
> I have also taken a fresh installed, and updated, RHEL8 minimal, and
> run the above commands to install KDE, and it worked also.
>
> That doesn't mean this repo will be up forever, but it should last
> until we get KDE in EPEL8, whenever that happens.
>
> Troy
>
Thanks for your work on this. My observation is - do want KDE to be a module
for EPEL8? I'm actually slightly surprised to find that Gnome does not appear
to be modular in RHEL8, but if we face something at all like the KDE 4->plasma
transition during RHEL8's lifetime it seems like a good thing to have.
Also, I've found them quite useful for building ordered sets of dependencies
and dealing with updates.

Personally, I think yes. Or at least a group of modules. There are
several sections of KDE that need to be updated as a group, and I
think doing them as a module is the way to go.
Once EPEL has modularity, I think it would be a good thing to work on.
But others might have their own opinion. I'm not the only one who
wants to work on KDE in EPEL. There will have to be some
communication and coordination.
Troy