8:04 a.m.
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
1:39 a.m.
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(a)lists.fedoraproject.org
To unsubscribe send an email to kde-leave(a)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
7:58 a.m.
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(a)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(a)lists.fedoraproject.org
> > To unsubscribe send an email to kde-leave(a)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
>
>
>
7:18 p.m.
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
7:39 p.m.
On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter <rdieter(a)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. :)
--
真実はいつも一つ！/ Always, there's only one truth!
11:06 a.m.
On Tue, Jun 25, 2019 at 5:39 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter <rdieter(a)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.
5:06 p.m.
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(a)redhat.com> wrote:
>
> On Tue, Jun 25, 2019 at 5:39 PM Neal Gompa <ngompa13(a)gmail.com> wrote:
> >
> > On Tue, Jun 25, 2019 at 5:26 PM Rex Dieter <rdieter(a)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.
7:01 p.m.
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
7:08 p.m.
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
11:21 p.m.
On Sun, Jul 7, 2019 at 5:09 PM Kevin Kofler <kevin.kofler(a)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
3:43 a.m.
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
7:45 a.m.
On Mon, Jul 8, 2019 at 1:44 AM Kevin Kofler <kevin.kofler(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)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
3:23 p.m.
Troy Dawson wrote:
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.fc2...
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
4:34 p.m.
Kevin Kofler wrote:
The log from F29:
https://kojipkgs.fedoraproject.org//packages/qt5-qtwebengine/5.12.2/1.fc2...
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=133fb029a6b9c...
that was only added in Qt 5.11.2. :-(
This change is needed by:
https://code.qt.io/cgit/qt/qtwebengine.git/commit/?id=2715088397641a85c1f...
So what you need to do is:
* locally:
wget
https://code.qt.io/cgit/qt/qtbase.git/patch/?id=133fb029a6b9c3ee06792887b...
-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
4:39 p.m.
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
5:01 p.m.
On Mon, Jul 8, 2019 at 2:40 PM Kevin Kofler <kevin.kofler(a)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
11:43 p.m.
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(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)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
2:28 p.m.
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
2:34 p.m.
On Tue, Aug 6, 2019 at 12:29 PM Kevin Kofler <kevin.kofler(a)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
10:01 p.m.
On Tue, Aug 6, 2019 at 4:36 PM Kevin Kofler <kevin.kofler(a)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.
11:08 p.m.
On Sun, Jul 7, 2019 at 5:11 PM Kevin Kofler <kevin.kofler(a)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(a)lists.fedoraproject.org
> To unsubscribe send an email to kde-leave(a)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
3:54 a.m.
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
1722
days inactive
1766
days old
24 comments
5 participants
participants (5)
-
Jan Grulich -
Kevin Kofler -
Neal Gompa -
Rex Dieter -
Troy Dawson