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:
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 _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://getfedora.org/code-of-conduct.html List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
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@redhat.com 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@redhat.com 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@redhat.com 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
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. 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
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 ?
-- Rex
On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter rdieter@gmail.com 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/
-- 真実はいつも一つ！/ Always, there's only one truth!
On Mon, Jan 14, 2019 at 5:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter rdieter@gmail.com 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...
Sorry, I mean "mkdir -p .link-bin" for the first command.
On Mon, Jan 14, 2019 at 2:04 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 14, 2019 at 5:02 PM Neal Gompa ngompa13@gmail.com wrote:
On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter rdieter@gmail.com 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...
Sorry, I mean "mkdir -p .link-bin" for the first command.
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
Neal Gompa wrote:
On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter rdieter@gmail.com 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].
That is... unfortunate (and silly imho).
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.
agreed.
-- Rex
Am 14.01.19 um 23:14 schrieb Rex Dieter:
Neal Gompa wrote:
On Mon, Jan 14, 2019 at 4:57 PM Rex Dieter rdieter@gmail.com 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].
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!
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.
-- rex
Am 14.01.19 um 23:33 schrieb Rex Dieter:
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
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.
-- Rex
Am 16.01.19 um 15:48 schrieb Rex Dieter:
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:
"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
valid, but is a separate issue.
I'm talking *only* about removing /usr/bin/python symlink (to python2)
Sure, if python2 goes away so would /usr/bin/python
-- Rex
Am 16.01.19 um 16:07 schrieb Rex Dieter:
Reindl Harald wrote:
"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
valid, but is a separate issue.
I'm talking *only* about removing /usr/bin/python symlink (to python2)
Sure, if python2 goes away so would /usr/bin/python
and hence it's about time to start living without /usr/bin/python which is unavoidable anyways
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.
Kevin Kofler
Am 16.01.19 um 19:17 schrieb Kevin Kofler:
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
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?
Kevin Kofler
Am 16.01.19 um 22:58 schrieb 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?
because it's just a waste of time
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.
Am 17.01.19 um 00:39 schrieb Matthew Miller:
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=1659706 https://bugzilla.kernel.org/show_bug.cgi?id=202065 https://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@redhat.com 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@redhat.com 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@redhat.com 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.
Syam
On Fri, Jan 18, 2019 at 4:53 AM Syam Krishnan syamcr@gmail.com wrote:
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@redhat.com 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@redhat.com 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@redhat.com 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@redhat.com 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 Fri, Jan 18, 2019 at 9:03 AM Troy Dawson tdawson@redhat.com 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
[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 5/8/19 4:09 PM, Troy Dawson wrote:
On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson tdawson@redhat.com 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.
On Thu, May 9, 2019 at 12:38 PM Orion Poplawski orion@nwra.com wrote:
On 5/8/19 4:09 PM, Troy Dawson wrote:
On Fri, Jan 18, 2019 at 9:03 AM Troy Dawson tdawson@redhat.com 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
-
Jan Grulich -
Kevin Kofler -
Matthew Miller -
Neal Gompa -
Orion Poplawski -
Reindl Harald -
Rex Dieter -
Syam Krishnan -
Troy Dawson