Hi, EPEL 8 is getting close to being available. I think now is the time to start talking about KDE on EPEL8 in earnest.
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well. I don't want to duplicate effort, or take the spotlight from others. Maybe if there is enough people we do it as a group and/or SIG.
On the flip side, I also want them initially done quickly. If someone is volunteering, yet they've never built a package for Fedora or EPEL before, I'd rather I do it then pass off the maintenance to them. Just to save time.
Anyway, thoughts?
Troy
Hi,
please note that we will need to probably stay with Plasma 5.15 for a while, as Plasma 5.16 depends on Qt 5.12, which is not in RHEL 8 (yet). I'm not sure if I will have time to work on this, but if you need anything from RHEL + Qt side, just let me know.
Regards, Jan
On pondělí 24. června 2019 15:04:22 CEST Troy Dawson wrote:
Hi, EPEL 8 is getting close to being available. I think now is the time to start talking about KDE on EPEL8 in earnest.
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well. I don't want to duplicate effort, or take the spotlight from others. Maybe if there is enough people we do it as a group and/or SIG.
On the flip side, I also want them initially done quickly. If someone is volunteering, yet they've never built a package for Fedora or EPEL before, I'd rather I do it then pass off the maintenance to them. Just to save time.
Anyway, thoughts?
Troy _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Good point. I was planning on taking the latest F30 packages, which have plasma 5.15. Except for the handful of qt5-qt* that need to stay on older releases.
At some point in the future (RHEL 8.1 or 8.2) we'll need to talk about updating, possibly putting qt5 and plasma into a module or something. But at the beginning, EPEL8 will not have modules. I'm fine with plasma 5.15 to start out with.
On Mon, Jun 24, 2019 at 11:39 PM Jan Grulich jgrulich@redhat.com wrote:
Hi,
please note that we will need to probably stay with Plasma 5.15 for a while, as Plasma 5.16 depends on Qt 5.12, which is not in RHEL 8 (yet). I'm not sure if I will have time to work on this, but if you need anything from RHEL + Qt side, just let me know.
Regards, Jan
On pondělí 24. června 2019 15:04:22 CEST Troy Dawson wrote:
Hi, EPEL 8 is getting close to being available. I think now is the time to start talking about KDE on EPEL8 in earnest.
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well. I don't want to duplicate effort, or take the spotlight from others. Maybe if there is enough people we do it as a group and/or SIG.
On the flip side, I also want them initially done quickly. If someone is volunteering, yet they've never built a package for Fedora or EPEL before, I'd rather I do it then pass off the maintenance to them. Just to save time.
Anyway, thoughts?
Troy _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Troy Dawson wrote:
Good point. I was planning on taking the latest F30 packages, which have plasma 5.15. Except for the handful of qt5-qt* that need to stay on older releases.
At least qt5-qtwebengine 5.12.x should build fine against the Qt 5.11.x in EL8. QtWebEngine is usually quite lenient when it comes to building against old Qt versions, even though only building against the latest LTS and newer branches is officially supported. E.g., we successfully built QtWebEngine 5.12.x against Qt 5.11.x on F29 (and F28 before it went EOL).
It would also be interesting to try out whether qt5-qtwebengine 5.12.x would even build against the Qt 5.9.x in EL7. It might actually work. (Qt 5.9.x was officially supported up to QtWebEngine 5.11.x, at least.)
But there are other old libraries in EL7 and even EL8 that might be a problem. Whoever wants to build QtWebEngine for EPEL will almost certainly have to enable more bundled libraries than in Fedora.
I might be able to help get QtWebEngine for EPEL going as a one time thing, if you want or need help, but I definitely do NOT want to maintain QtWebEngine for EPEL in the long run. I didn't even manage to maintain it for Fedora, which I actually use, so maintaining it for EPEL, which I don't use for anything desktop-oriented, is not something I want to attempt. Also because it's certainly MORE work than on Fedora.
Kevin Kofler
On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter rdieter@gmail.com wrote:
Troy Dawson wrote:
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well.
Count me in.
Wherever I can, I'm willing to help too. :)
On Tue, Jun 25, 2019 at 5:39 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter rdieter@gmail.com wrote:
Troy Dawson wrote:
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well.
Count me in.
Wherever I can, I'm willing to help too. :)
So I'm going through all my packages again, seeing what builds, what doesn't and why it doesn't.
Thank you to Rex and others[1] who have fixed many of the packages to build for RHEL8 out of the box. There are alot less failures than there were last time I did this.
Majority of the changes needed are turning on bootstrap, due to circular dependencies in testing. The few other changes that need to happen, I'm going to make sure are encased in a good %if statement and try to push them up to Fedora master and f30. Several of these are due to no qt4 in RHEL8, so if I do it correctly, it should make it easier for Fedora to turn off qt4 when the time comes.
From the reports of the people setting up the infrastructure of EPEL8, at best, we will be able to start building packages just two days before I go on vacation (with no/little internet access on vacation). I'm working on getting all my building results and proposed fixes in an easy to read and (hopefully) easy to implement format. If everything goes well I should have the build-order and what-needs-changes ready by end of day Monday.
Troy [1] - I'm sure there are other people who fixed some of the packages, but Rex's name was on all the ones I checked. After a while I quit checking and just appreciated it. So if I did not mention your name, I apologize, but I still am grateful for what you did.
I'm sorry this took longer than I expected. We have about 360 buildable packages, and only 36 needed any modification for the lastest f30 packages. I am still working on up-porting many of those fixes to master and f30 branches. But I figured I'd get this list out to people while I do that.
- Package list in order that they should be built https://tdawson.fedorapeople.org/epel8-rebuild/kde/package.list - Package list in alphabetical order https://tdawson.fedorapeople.org/epel8-rebuild/kde/package.list.sorted - List of packages needing different version than latest F30 https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.4.txt - List of packages needing spec file changes https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.spec.list - List of packages that currently do not build and the reasons why - https://tdawson.fedorapeople.org/epel8-rebuild/kde/will.not.build.txt
Full Spec files for packages that need spec file changes https://tdawson.fedorapeople.org/epel8-rebuild/kde/specs/ Patch files to bring F30 spec files to match full fixed spec files. https://tdawson.fedorapeople.org/epel8-rebuild/kde/patch/
For the packages needing to be modified, here are the reasons why 1 - No QT4 2 - Fix %if for RHEL8 3 - Turn on bootstrap 4 - Build a certain version (usually due to RHEL8 QT5 libraries) 5 - Change %{_sysconfdir}/dbus-1/ to %{_datadir}/dbus-1/ in the %files section 6 - Other
And here are those lists https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.1.txt https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.2.txt https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.3.txt https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.4.txt https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.5.txt https://tdawson.fedorapeople.org/epel8-rebuild/kde/modified.6.txt
If there are any packages people think I've missed (probably some kde apps), or packages I added that people think shouldn't be in EPEL8. Please speak up and we'll see about getting things fixed.
Troy
On Fri, Jun 28, 2019 at 9:06 AM Troy Dawson tdawson@redhat.com wrote:
On Tue, Jun 25, 2019 at 5:39 PM Neal Gompa ngompa13@gmail.com wrote:
On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter rdieter@gmail.com wrote:
Troy Dawson wrote:
Who is going to do the EPEL8 KDE packages?
I am volunteering to do them, but from what I've heard, there are several other people who want to do it as well.
Count me in.
Wherever I can, I'm willing to help too. :)
So I'm going through all my packages again, seeing what builds, what doesn't and why it doesn't.
Thank you to Rex and others[1] who have fixed many of the packages to build for RHEL8 out of the box. There are alot less failures than there were last time I did this.
Majority of the changes needed are turning on bootstrap, due to circular dependencies in testing. The few other changes that need to happen, I'm going to make sure are encased in a good %if statement and try to push them up to Fedora master and f30. Several of these are due to no qt4 in RHEL8, so if I do it correctly, it should make it easier for Fedora to turn off qt4 when the time comes.
From the reports of the people setting up the infrastructure of EPEL8, at best, we will be able to start building packages just two days before I go on vacation (with no/little internet access on vacation). I'm working on getting all my building results and proposed fixes in an easy to read and (hopefully) easy to implement format. If everything goes well I should have the build-order and what-needs-changes ready by end of day Monday.
Troy [1] - I'm sure there are other people who fixed some of the packages, but Rex's name was on all the ones I checked. After a while I quit checking and just appreciated it. So if I did not mention your name, I apologize, but I still am grateful for what you did.
Troy Dawson wrote:
qt5-qtwebengine (revert to qt5-qtwebengine-5.11.3-3.fc30,bootstrap, python -> python2, and other stuff)
Why did you have to revert to QtWebEngine 5.11.3? As I pointed out previously, QtWebEngine 5.12.x builds fine against Qt 5.11.x (see F29: https://koji.fedoraproject.org/koji/buildinfo?buildID=1298728 ). Have you tried rebuilding the current qt5-qtwebengine-5.12.4-5.fc30/fc29 yet? It should work and provide important security fixes (and also some very useful features for Falkon 3.1) compared to QtWebEngine 5.11.x.
Kevin Kofler
Kevin Kofler wrote:
Why did you have to revert to QtWebEngine 5.11.3? As I pointed out previously, QtWebEngine 5.12.x builds fine against Qt 5.11.x (see F29: https://koji.fedoraproject.org/koji/buildinfo?buildID=1298728 ). Have you tried rebuilding the current qt5-qtwebengine-5.12.4-5.fc30/fc29 yet? It should work and provide important security fixes (and also some very useful features for Falkon 3.1) compared to QtWebEngine 5.11.x.
PS: And since Qt 5.12 is an LTS branch, you'll be able to keep shipping QtWebEngine 5.12.x security releases for quite a while, whereas 5.11.x is a dead end.
Kevin Kofler
On Sun, Jul 7, 2019 at 5:09 PM Kevin Kofler kevin.kofler@chello.at wrote:
Kevin Kofler wrote:
Why did you have to revert to QtWebEngine 5.11.3? As I pointed out previously, QtWebEngine 5.12.x builds fine against Qt 5.11.x (see F29: https://koji.fedoraproject.org/koji/buildinfo?buildID=1298728 ). Have you tried rebuilding the current qt5-qtwebengine-5.12.4-5.fc30/fc29 yet? It should work and provide important security fixes (and also some very useful features for Falkon 3.1) compared to QtWebEngine 5.11.x.
PS: And since Qt 5.12 is an LTS branch, you'll be able to keep shipping QtWebEngine 5.12.x security releases for quite a while, whereas 5.11.x is a dead end.
Ya, this one is one of the reasons this took me longer than expected. 2-3 hour compile times only to fail with some obscure compile failure, takes a *long* time (days) to debug and I didn't ever get it. In the end, I reverted to what I managed to get built for my RHEL8-Beta build. Since I'm building this on my private server, it's hard to ask others to take a look.
I'm rebuilding this right now so I have a fresh log. I'll post that log if anyone wants.
If you are confident that we can get the 5.12 version to build, that's great. Let's try it once we can. It's very likely that the error that I could't figure out, is obvious to you. Or even better, that maybe some library in RHEL8 get's updated and it just builds.
Troy
Troy Dawson wrote:
I'm rebuilding this right now so I have a fresh log. I'll post that log if anyone wants.
I'd like to see the log, please.
If you are confident that we can get the 5.12 version to build, that's great. Let's try it once we can. It's very likely that the error that I could't figure out, is obvious to you. Or even better, that maybe some library in RHEL8 get's updated and it just builds.
If it's a library issue, switching some library from system to bundled can do wonders. With all the stuff that QtWebEngine bundles, one library more or less won't make all that much of a difference. (Though some combinations of system and bundled libraries may cause issues, too, due to interaction between the libraries.) But let me first see the log.
Kevin Kofler
On Mon, Jul 8, 2019 at 1:44 AM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
I'm rebuilding this right now so I have a fresh log. I'll post that log if anyone wants.
I'd like to see the log, please.
https://tdawson.fedorapeople.org/tmp/qt5-qtwebengine.failed.logs.tgz
If you are confident that we can get the 5.12 version to build, that's great. Let's try it once we can. It's very likely that the error that I could't figure out, is obvious to you. Or even better, that maybe some library in RHEL8 get's updated and it just builds.
If it's a library issue, switching some library from system to bundled can do wonders. With all the stuff that QtWebEngine bundles, one library more or less won't make all that much of a difference. (Though some combinations of system and bundled libraries may cause issues, too, due to interaction between the libraries.) But let me first see the log.
Kevin Kofler
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Troy Dawson wrote:
https://tdawson.fedorapeople.org/tmp/qt5-qtwebengine.failed.logs.tgz
The relevant error is this one: In file included from /builddir/build/BUILD/qtwebengine-everywhere-src-5.12.2/src/core/client_cert_select_controller.h:54, from /builddir/build/BUILD/qtwebengine-everywhere-src-5.12.2/src/core/client_cert_select_controller.cpp:40: /builddir/build/BUILD/qtwebengine-everywhere-src-5.12.2/src/core/api/qtwebenginecoreglobal_p.h:56:10: fatal error: QtWebEngineCore/private/qtwebenginecore- config_p.h: No such file or directory #include <QtWebEngineCore/private/qtwebenginecore-config_p.h> ^~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ compilation terminated.
The log from F29: https://kojipkgs.fedoraproject.org//packages/qt5-qtwebengine/5.12.2/1.fc29/d... client_cert_select_controller.cpp built fine there, with Qt 5.11.3. RHEL 8 has only Qt 5.11.1, but it should not make that much a difference.
So I'm not sure what is going on there.
Kevin Kofler
Kevin Kofler wrote:
The log from F29: https://kojipkgs.fedoraproject.org//packages/qt5-qtwebengine/5.12.2/1.fc29/d... client_cert_select_controller.cpp built fine there, with Qt 5.11.3. RHEL 8 has only Qt 5.11.1, but it should not make that much a difference.
Actually, it looks like that is the issue: QtWebEngine 5.12 wants this commit: https://code.qt.io/cgit/qt/qtbase.git/commit/?h=5.11&id=133fb029a6b9c3ee... that was only added in Qt 5.11.2. :-(
This change is needed by: https://code.qt.io/cgit/qt/qtwebengine.git/commit/?id=2715088397641a85c1fb61...
So what you need to do is: * locally: wget https://code.qt.io/cgit/qt/qtbase.git/patch/?id=133fb029a6b9c3ee06792887b61c... -O qt5-qtbase-5.11.1-mkspecs.patch
* in the specfile, below the patches, add: Patch500: qt5-qtbase-5.11.1-mkspecs.patch
* in the specfile, at the beginning of %build, add: mkdir patched-mkspecs-features cp -a /usr/lib64/qt5/mkspecs/features/qt_module{,_headers}.prf \ patched-mkspecs-features/ patch -p3 -d patched-mkspecs-features <%{PATCH500} export QMAKEFEATURES=`pwd`/patched-mkspecs-features
and then try again.
Kevin Kofler
PS: To be clear:
Kevin Kofler wrote:
- in the specfile, below the patches, add:
Patch500: qt5-qtbase-5.11.1-mkspecs.patch
Yes, this qt5-qtbase patch goes into the qt5-qtwebengine (!) specfile. The idea is that my snippet:
mkdir patched-mkspecs-features
creates a custom directory for patched mkspecs/features in the qt5-qtwebengine buildroot,
cp -a /usr/lib64/qt5/mkspecs/features/qt_module{,_headers}.prf \ patched-mkspecs-features/
copies the original files from the RHEL qt5-qtbase mkspecs/features into the custom directory,
patch -p3 -d patched-mkspecs-features <%{PATCH500}
patches them,
export QMAKEFEATURES=`pwd`/patched-mkspecs-features
and then tells QMake to use them in preference to the system-installed ones,
and then try again.
so then you can go on building QtWebEngine, and it will hopefully succeed. And you did NOT have to touch the system qt5-qtbase, which is off limits.
I hope this helps, Kevin Kofler
On Mon, Jul 8, 2019 at 2:40 PM Kevin Kofler kevin.kofler@chello.at wrote:
PS: To be clear:
Kevin Kofler wrote:
- in the specfile, below the patches, add:
Patch500: qt5-qtbase-5.11.1-mkspecs.patch
Yes, this qt5-qtbase patch goes into the qt5-qtwebengine (!) specfile. The idea is that my snippet:
mkdir patched-mkspecs-features
creates a custom directory for patched mkspecs/features in the qt5-qtwebengine buildroot,
cp -a /usr/lib64/qt5/mkspecs/features/qt_module{,_headers}.prf \ patched-mkspecs-features/
copies the original files from the RHEL qt5-qtbase mkspecs/features into the custom directory,
patch -p3 -d patched-mkspecs-features <%{PATCH500}
patches them,
export QMAKEFEATURES=`pwd`/patched-mkspecs-features
and then tells QMake to use them in preference to the system-installed ones,
and then try again.
so then you can go on building QtWebEngine, and it will hopefully succeed. And you did NOT have to touch the system qt5-qtbase, which is off limits.
I hope this helps, Kevin Kofler
Thank you for clearing that up. I was thinking what you said, but wasn't sure. And thank you very much for figuring out the solution in the first place.
Troy
Kevin, Any ideas? I followed your instructions and it looks like it's failing on ... make[3]: Entering directory '/builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/src/core' perl /builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/patched-mkspecs-features/data/unix/findclasslist.pl < QtWebEngineCore.version.in > QtWebEngineCore.version BUILDSTDERR: Can't open perl script "/builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/patched-mkspecs-features/data/unix/findclasslist.pl": No such file or directory ... https://koji.fedoraproject.org/koji/taskinfo?taskID=36817449 https://kojipkgs.fedoraproject.org//work/tasks/7464/36817464/build.log
On Mon, Jul 8, 2019 at 2:40 PM Kevin Kofler kevin.kofler@chello.at wrote:
PS: To be clear:
Kevin Kofler wrote:
- in the specfile, below the patches, add:
Patch500: qt5-qtbase-5.11.1-mkspecs.patch
Yes, this qt5-qtbase patch goes into the qt5-qtwebengine (!) specfile. The idea is that my snippet:
mkdir patched-mkspecs-features
creates a custom directory for patched mkspecs/features in the qt5-qtwebengine buildroot,
cp -a /usr/lib64/qt5/mkspecs/features/qt_module{,_headers}.prf \ patched-mkspecs-features/
copies the original files from the RHEL qt5-qtbase mkspecs/features into the custom directory,
patch -p3 -d patched-mkspecs-features <%{PATCH500}
patches them,
export QMAKEFEATURES=`pwd`/patched-mkspecs-features
and then tells QMake to use them in preference to the system-installed ones,
and then try again.
so then you can go on building QtWebEngine, and it will hopefully succeed. And you did NOT have to touch the system qt5-qtbase, which is off limits.
I hope this helps, Kevin Kofler _______________________________________________ kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Troy Dawson wrote:
BUILDSTDERR: Can't open perl script "/builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/patched-mkspecs-
features/data/unix/findclasslist.pl":
No such file or directory ...
Looks like you also need to copy or symlink that script from /usr/lib64/qt5/mkspecs to patched-mkspecs-features.
Kevin Kofler
On Tue, Aug 6, 2019 at 12:29 PM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
BUILDSTDERR: Can't open perl script "/builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/patched-mkspecs-
features/data/unix/findclasslist.pl":
No such file or directory ...
Looks like you also need to copy or symlink that script from /usr/lib64/qt5/mkspecs to patched-mkspecs-features.
I guess that's one way to do it. Looking at things, in /usr/lib64/qt5/mkspecs/features/qt_module.prf (which we copy to patched-mkspecs-features) it has verscriptprocess.commands = perl $${PWD}/data/unix/findclasslist.pl < ${QMAKE_FILE_IN} > $@ The ${PWD} get's expanded to /builddir/build/BUILD/qtwebengine-everywhere-src-5.12.4/patched-mkspecs-features Since we are already messing with that file, I changed $${PWD} to /usr/lib64/qt5/mkspecs/features My build is still building where I did that, so I can't say for sure whether that is correct or not. Troy
On Tue, Aug 6, 2019 at 4:36 PM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
Since we are already messing with that file, I changed $${PWD} to /usr/lib64/qt5/mkspecs/features My build is still building where I did that, so I can't say for sure whether that is correct or not.
It should work.
Yep it did. I am able to move on to the rest of the packages.
On Sun, Jul 7, 2019 at 5:11 PM Kevin Kofler kevin.kofler@chello.at wrote:
Troy Dawson wrote:
# qt4 only kile
We are actually shipping the KF5 beta Kile 2.9.92 = 3.0 beta 2 in Fedora (since Fedora 29).
Oohhh ... yep. I had it off my list from my original build. It still doesn't built because it wants okular, and I just ran out of time with okular. But, that is much different than being a kde4 only package.
Thanks for letting me know.
Kevin Kofler
kde mailing list -- kde@lists.fedoraproject.org To unsubscribe send an email to kde-leave@lists.fedoraproject.org Fedora Code of Conduct: https://docs.fedoraproject.org/en-US/project/code-of-conduct/ List Guidelines: https://fedoraproject.org/wiki/Mailing_list_guidelines List Archives: https://lists.fedoraproject.org/archives/list/kde@lists.fedoraproject.org
Troy Dawson wrote:
It still doesn't built because it wants okular, and I just ran out of time with okular.
For Okular, you may want to just limit the supported backends, and hence the dependencies, to a minimum. Kile (and most LaTeX users in general) will only really care about P(ost)S(cript) (libspectre), PDF (poppler-qt5), and DVI (builtin backend, no external library needed). These are also historically the 3 viewers that Okular replaced in the move from KDE 3 to KDE 4 (KGhostView, KPDF, KDVI). Anything else is nice to have, but not essential.
Kevin Kofler
-
Jan Grulich -
Kevin Kofler -
Neal Gompa -
Rex Dieter -
Troy Dawson