Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review58187 --- Ship it! Ship It! - David Faure On May 19, 2014, 10:26 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated May 19, 2014, 10:26 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated May 20, 2014, 11:12 a.m.) Status -- This change has been marked as submitted. Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated May 20, 2014, 12:26 a.m.) Review request for KDE Frameworks. Changes --- Updated patch with LIBEXEC_PATH, as David suggested. I'm terribly sorry, I forgot about this completely. I hope it's not too late. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs (updated) - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On April 12, 2014, 10:48 a.m., Alex Merry wrote:
This is my preferred solution, and is hopefully only a temporary one.
However, I know David Faure doesn't like it, and (I assume) would rather
have a generic LIBEXEC variable.
My view is that libexec should be used for stuff that's really internal to
a piece of software (like a framework), and so a libexec env var shouldn't
be necessary (except maybe for relocatability?), but the current situation
with drkonqi should hopefully be a temporary one (until 5.1 or something),
and so a specific var for unusual situations is reasonable.
However, given that an objection has already been raised by the maintainer,
I'm not willing to give it a ship-it without his agreement.
David Faure wrote:
I maintain my objection: while this particular issue might be temporary,
the fact that libexec path gets hardcoded into the compiled library makes
things impossible to relocate. PATH and LD_LIBRARY_PATH solve this for normal
executables and libraries, an equivalent is just missing for libexec.
My suggestion then is more precisely:
QFile::decodeName(qgetenv(LIBEXEC_PATH)).split(':') and pass that list to
QStandardPaths::findExecutable(), which can take a list of paths to check
into, as the second argument. Nice and easy. And later we can do the same in
all frameworks that look for something in libexec (with a fallback to the
builtin path).
Alex Merry wrote:
Dan: could you submit another version using David's suggested approach,
please?
Dan? Any news?
- Kevin
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/#review55497
---
On April 9, 2014, 8:47 a.m., Dan Vrátil wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/
---
(Updated April 9, 2014, 8:47 a.m.)
Review request for KDE Frameworks.
Repository: kcrash
Description
---
Since KCrash is a framework that relies on DrKonqi binary being provided by a
3rd party software (kde-runtime), it should not make assumptions regarding
location of the utility.
This patch makes KCrash to look for drkonqi binary first in $PATH, then
falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch
it's possible for distributions to ship KDE Frameworks in normal prefix
(/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance.
Diffs
-
src/kcrash.cpp 87163cc
Diff: https://git.reviewboard.kde.org/r/117016/diff/
Testing
---
- Installed KCrash into /usr prefix
- Installed drkonqi from kde-runtime master to /opt/kde5 prefix
- started broken application
- no could not find drkonqi warning anymore
- crashed application, got drkonqi window
Thanks,
Dan Vrátil
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On April 12, 2014, 10:48 a.m., Alex Merry wrote:
This is my preferred solution, and is hopefully only a temporary one.
However, I know David Faure doesn't like it, and (I assume) would rather
have a generic LIBEXEC variable.
My view is that libexec should be used for stuff that's really internal to
a piece of software (like a framework), and so a libexec env var shouldn't
be necessary (except maybe for relocatability?), but the current situation
with drkonqi should hopefully be a temporary one (until 5.1 or something),
and so a specific var for unusual situations is reasonable.
However, given that an objection has already been raised by the maintainer,
I'm not willing to give it a ship-it without his agreement.
David Faure wrote:
I maintain my objection: while this particular issue might be temporary,
the fact that libexec path gets hardcoded into the compiled library makes
things impossible to relocate. PATH and LD_LIBRARY_PATH solve this for normal
executables and libraries, an equivalent is just missing for libexec.
My suggestion then is more precisely:
QFile::decodeName(qgetenv(LIBEXEC_PATH)).split(':') and pass that list to
QStandardPaths::findExecutable(), which can take a list of paths to check
into, as the second argument. Nice and easy. And later we can do the same in
all frameworks that look for something in libexec (with a fallback to the
builtin path).
Dan: could you submit another version using David's suggested approach, please?
- Alex
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/#review55497
---
On April 9, 2014, 8:47 a.m., Dan Vrátil wrote:
---
This is an automatically generated e-mail. To reply, visit:
https://git.reviewboard.kde.org/r/117016/
---
(Updated April 9, 2014, 8:47 a.m.)
Review request for KDE Frameworks.
Repository: kcrash
Description
---
Since KCrash is a framework that relies on DrKonqi binary being provided by a
3rd party software (kde-runtime), it should not make assumptions regarding
location of the utility.
This patch makes KCrash to look for drkonqi binary first in $PATH, then
falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch
it's possible for distributions to ship KDE Frameworks in normal prefix
(/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance.
Diffs
-
src/kcrash.cpp 87163cc
Diff: https://git.reviewboard.kde.org/r/117016/diff/
Testing
---
- Installed KCrash into /usr prefix
- Installed drkonqi from kde-runtime master to /opt/kde5 prefix
- started broken application
- no could not find drkonqi warning anymore
- crashed application, got drkonqi window
Thanks,
Dan Vrátil
___
Kde-frameworks-devel mailing list
Kde-frameworks-devel@kde.org
https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review55497 --- This is my preferred solution, and is hopefully only a temporary one. However, I know David Faure doesn't like it, and (I assume) would rather have a generic LIBEXEC variable. My view is that libexec should be used for stuff that's really internal to a piece of software (like a framework), and so a libexec env var shouldn't be necessary (except maybe for relocatability?), but the current situation with drkonqi should hopefully be a temporary one (until 5.1 or something), and so a specific var for unusual situations is reasonable. However, given that an objection has already been raised by the maintainer, I'm not willing to give it a ship-it without his agreement. - Alex Merry On April 9, 2014, 8:47 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated April 9, 2014, 8:47 a.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review55498 --- src/kcrash.cpp https://git.reviewboard.kde.org/r/117016/#comment38614 This should happen even if the env var is used. - Alex Merry On April 9, 2014, 8:47 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated April 9, 2014, 8:47 a.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated April 9, 2014, 10:47 a.m.) Review request for KDE Frameworks. Changes --- Use KCRASH_DRKONQI_EXECUTABLE env variable to override the lookup path, as suggested by Alex. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs (updated) - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? Aleix Pol Gonzalez wrote: I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. Dan Vrátil wrote: Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1. Aleix Pol Gonzalez wrote: I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK. But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so. Alex Merry wrote: As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them. Aleix Pol Gonzalez wrote: I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!). I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin. In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec. Alex Merry wrote: It's not unrelated. The issue that we want to solve is installing packages in different prefixes. The issue just goes away if drkonqi is part of kcrash. The plugin thing sounds sensible to me. It can go in frameworkintegration, I guess. Aleix Pol Gonzalez wrote: It probably shouldn't go to frameworkintegration. It's about reporting KDE applications to our bugzilla. We want applications on Windows (for example) to be able to report bugs, and frameworks integration shouldn't be present there. I would suggest having it in a separate repository and let whoever makes the packages, to opt in and include it with their package, if they want. This patch should be revived somehow. DrKonqi will end up in Plasma Workspace which means it will stay as a runtime dependency. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review54443 --- How does findExecutable() help at all? You plan on adding libexec to your $PATH? - David Faure On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 28, 2014, 2:13 p.m., David Faure wrote: How does findExecutable() help at all? You plan on adding libexec to your $PATH? KStandardDirs::findExe used to look into libexec, IIRC. Maybe we could make it work. Or do something completely different. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review54443 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? Aleix Pol Gonzalez wrote: I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. Dan Vrátil wrote: Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1. Aleix Pol Gonzalez wrote: I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK. But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so. Alex Merry wrote: As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them. Aleix Pol Gonzalez wrote: I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!). I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin. In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec. It's not unrelated. The issue that we want to solve is installing packages in different prefixes. The issue just goes away if drkonqi is part of kcrash. The plugin thing sounds sensible to me. It can go in frameworkintegration, I guess. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 11:01 a.m., Aleix Pol Gonzalez wrote: What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). Alex Merry wrote: I'm pretty sure QStandardPaths won't look at libexec. How should it know where libexec stuff is? The whole point of libexec is that it is library-private (TBH it's slightly hacky to have a kde5 libexec dir in $LIB/kde5/libexec; really, each library should have its own dir). Hrvoje Senjan wrote: additionally, i think this will actually open drkonqi(4) (if kde-runtime(4) is also installed), no? Dan Vrátil wrote: The idea is that it does not find anything and fallsback to CMAKE_INSTALL_DIR/LIBEXEC_INSTALL_DIR, but allows us to override it by PATH in case we use some prefix, like /opt/kde5. Obviously if people mess with their PATH they might get weird results like starting drkonqi4, but that's simply their problem. Alex Merry wrote: If anything, I'd rather use a special variable rather than PATH. Putting things onto PATH that weren't named with that in mind is asking for trouble, IMO. Maybe KCRASH_DRKONQI_EXECUTABLE? drkonqi(4) is in prefix/lib/kde4/libexec/drkonqi, so the risk of hitting that from a kf5 executable is zero. I'm against a specific env var, there are too many already, and we have many more libexec executables. - David --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? Aleix Pol Gonzalez wrote: I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. Dan Vrátil wrote: Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1. Aleix Pol Gonzalez wrote: I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK. But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so. Alex Merry wrote: As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them. I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!). I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin. In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? Aleix Pol Gonzalez wrote: I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. Dan Vrátil wrote: Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1. Aleix Pol Gonzalez wrote: I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK. But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so. Alex Merry wrote: As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them. Aleix Pol Gonzalez wrote: I've been looking into it, I made it compile completely by using KF5XmlRpcClient (the port of kdepimlibs is in a much better state than I expected, thanks!!). I'm unsure we want to provide the bugzilla integration together with drkonqi, so I've been thinking that we probably want to split it out into a plugin. In any case, this is quite unrelated to the subject, given that either in kcrash or in kde-runtime, this will have to be installed in libexec. Alex Merry wrote: It's not unrelated. The issue that we want to solve is installing packages in different prefixes. The issue just goes away if drkonqi is part of kcrash. The plugin thing sounds sensible to me. It can go in frameworkintegration, I guess. It probably shouldn't go to frameworkintegration. It's about reporting KDE applications to our bugzilla. We want applications on Windows (for example) to be able to report bugs, and frameworks integration shouldn't be present there. I would suggest having it in a separate repository and let whoever makes the packages, to opt in and include it with their package, if they want. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Aleix, weren't you indeed planning to move drkonqi in? Any ETA? - Kevin --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. Dan Vrátil wrote: I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) Kevin Ottens wrote: Aleix, weren't you indeed planning to move drkonqi in? Any ETA? Aleix Pol Gonzalez wrote: I wanted to figure it out first. At the moment Dr Konqi depends on some commented out kdepimlibs bits I'm unsure what to do with, so I decided to lower it's priority. I can do it before next week if it's considered important. Dan Vrátil wrote: Initial port of KXMLRPCClient to frameworks is already done. It's very tiny (2 classes), so it could be properly frameworkized on the PIM sprint this weekend. It depends on KIO ATM for doing HTTP POST requests, but maybe it could be replaced by a Qt solution, so that it could go to Tier 1. Aleix Pol Gonzalez wrote: I think we're a bit late for that. We can do it but the addition of frameworks is frozen AFAIK. But yes, kdepimlibs should be sorted out ASAP and this sprint can be a good moment for doing so. As a temporary solution, the two classes could be just dropped into KCrash, but without exporting them. - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). - Aleix Pol Gonzalez On March 24, 2014, 10:52 a.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 10:52 a.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 1:01 p.m.) Review request for KDE Frameworks. Changes --- Using QStandardPaths now. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs (updated) - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
--- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). - Alex Merry On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 11:01 a.m., Aleix Pol Gonzalez wrote: What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). I'm pretty sure QStandardPaths won't look at libexec. How should it know where libexec stuff is? The whole point of libexec is that it is library-private (TBH it's slightly hacky to have a kde5 libexec dir in $LIB/kde5/libexec; really, each library should have its own dir). - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 11:01 a.m., Aleix Pol Gonzalez wrote: What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). Alex Merry wrote: I'm pretty sure QStandardPaths won't look at libexec. How should it know where libexec stuff is? The whole point of libexec is that it is library-private (TBH it's slightly hacky to have a kde5 libexec dir in $LIB/kde5/libexec; really, each library should have its own dir). additionally, i think this will actually open drkonqi(4) (if kde-runtime(4) is also installed), no? - Hrvoje --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 3:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. - Aleix --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 4:41 p.m., Alex Merry wrote: The correct solution is to get drkonqi merged into kcrash (see http://community.kde.org/Frameworks/Epics/New_Runtime_Organization). Aleix Pol Gonzalez wrote: Agreed. If somebody has the time, it would be interesting to figure out what can be uncommented (see commit f8b59b6c in kde-runtime). There's many things commented out and I'm unsure what to do with it. I agree, however until it is done, this patch would make lifes of distribution packagers a bit easier :-) - Dan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53985 --- On March 24, 2014, 1:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 1:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 12:01 p.m., Aleix Pol Gonzalez wrote: What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). Alex Merry wrote: I'm pretty sure QStandardPaths won't look at libexec. How should it know where libexec stuff is? The whole point of libexec is that it is library-private (TBH it's slightly hacky to have a kde5 libexec dir in $LIB/kde5/libexec; really, each library should have its own dir). Hrvoje Senjan wrote: additionally, i think this will actually open drkonqi(4) (if kde-runtime(4) is also installed), no? The idea is that it does not find anything and fallsback to CMAKE_INSTALL_DIR/LIBEXEC_INSTALL_DIR, but allows us to override it by PATH in case we use some prefix, like /opt/kde5. Obviously if people mess with their PATH they might get weird results like starting drkonqi4, but that's simply their problem. - Dan --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- On March 24, 2014, 1:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 1:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
Re: Review Request 117016: Allow overriding DrKonqi lookup directories by PATH
On March 24, 2014, 11:01 a.m., Aleix Pol Gonzalez wrote: What about QStandardPaths::findExecutable? Actually this one should look into libexec too (at least the equivalent KStandardDirs::findExe used to). Alex Merry wrote: I'm pretty sure QStandardPaths won't look at libexec. How should it know where libexec stuff is? The whole point of libexec is that it is library-private (TBH it's slightly hacky to have a kde5 libexec dir in $LIB/kde5/libexec; really, each library should have its own dir). Hrvoje Senjan wrote: additionally, i think this will actually open drkonqi(4) (if kde-runtime(4) is also installed), no? Dan Vrátil wrote: The idea is that it does not find anything and fallsback to CMAKE_INSTALL_DIR/LIBEXEC_INSTALL_DIR, but allows us to override it by PATH in case we use some prefix, like /opt/kde5. Obviously if people mess with their PATH they might get weird results like starting drkonqi4, but that's simply their problem. If anything, I'd rather use a special variable rather than PATH. Putting things onto PATH that weren't named with that in mind is asking for trouble, IMO. Maybe KCRASH_DRKONQI_EXECUTABLE? - Alex --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/#review53939 --- On March 24, 2014, 12:01 p.m., Dan Vrátil wrote: --- This is an automatically generated e-mail. To reply, visit: https://git.reviewboard.kde.org/r/117016/ --- (Updated March 24, 2014, 12:01 p.m.) Review request for KDE Frameworks. Repository: kcrash Description --- Since KCrash is a framework that relies on DrKonqi binary being provided by a 3rd party software (kde-runtime), it should not make assumptions regarding location of the utility. This patch makes KCrash to look for drkonqi binary first in $PATH, then falling back to CMAKE_INSTALL_PREFIX/LIBEXEC_INSTALL_DIR. With this patch it's possible for distributions to ship KDE Frameworks in normal prefix (/usr), but have current snapshots of kde-runtime in /opt/kde5 for instance. Diffs - src/kcrash.cpp 87163cc Diff: https://git.reviewboard.kde.org/r/117016/diff/ Testing --- - Installed KCrash into /usr prefix - Installed drkonqi from kde-runtime master to /opt/kde5 prefix - started broken application - no could not find drkonqi warning anymore - crashed application, got drkonqi window Thanks, Dan Vrátil ___ Kde-frameworks-devel mailing list Kde-frameworks-devel@kde.org https://mail.kde.org/mailman/listinfo/kde-frameworks-devel
