Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
I think I'm preparing to propose another revbump of the kde4 ports...
I've started continuing Marko's work on KF5 ports (the frameworks, for now, 2-3
a day :)). I don't know yet to what extent KF5 and KDE4 can co-exist (KDE4
applications *can* run on/under a KF5 desktop, so clearly some form of
co-existence is possible), but I've already run into headerfile clashes.
As a result, I'm now looking at building kdelibs4 with
-DINCLUDE_INSTALL_DIR=${prefix}/include/KDE4, which from the looks of it will
export KDE4_INCLUDE_INSTALL_DIR through KDE's cmake scripts.
Even if this puts the kdelibs headerfiles under that dedicated prefix, I do not
know yet whether *all* KDE4-related headerfiles are going to be installed and
expected there too (think akonadi, kde4-runtime, kdepimlibs4, etc).
I'm hoping that any headers still installed directly under ${prefix}/include
will still be found because that directory is added to the search path by
default, and if true there shouldn't be an obligation to rebuild all kdelibs4
dependents that install headers of their own. But in the worst case we're
looking at rebuilding all those ports.
(in that light, it'd be helpful to have a way to list or exclude ports that do
not have dependents, whether those are installed or not.)
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
René J. V. Bertin wrote: > I'll be having a look myself too, this > weekend. Debian also installs the generator and qs_eval binaries, btw, which > suggests they might be useful if not needed. Done; modifications pushed to my repo (github.com/RJVB/macstrop) R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote: > I'll try your patches & see what comes of it. While you're at it and if you have time: Debian/Ubuntu apply a number of other patches to the code to bring it up to date. They're in my port repository (devel/qtscriptgenerator/files). I'll be having a look myself too, this weekend. Debian also installs the generator and qs_eval binaries, btw, which suggests they might be useful if not needed. R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
IIRC: "LIBS += FOO" adds FOO to LIBS without checking for duplicates,
while "*=" adds only after checking that FOO isn't already there.
And, yes, an INCLUDEPATH is also required. Just replicate what QCA does
in its mkspec file ("s/QCA/phonon/g"). That said ...
Further (from another part of this email thread): It looks like setting
those to ${prefix}/lib or .../include does create anomalies here and
there in QTSG. Grr
I'll try your patches & see what comes of it. Thanks for getting those
figured out! - MLD
On Fri, Oct 30, 2015, at 02:56 PM, René J. V. Bertin wrote:
> Michael Dickens wrote:
> > correctly do "LIBS *=..." no matter where Phonon is installed. That
>
> BTW, what's the difference with "LIBS += ..."?
> Are you sure a matching INCLUDEPATH expression isn't required?
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote: > correctly do "LIBS *=..." no matter where Phonon is installed. That BTW, what's the difference with "LIBS += ..."? Are you sure a matching INCLUDEPATH expression isn't required? R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote:
> What I'm planning on doing for Phonon is modifying its mkspec file to
> correctly do "LIBS *=..." no matter where Phonon is installed. That
> seems like a nice robust solution.
Yes - as long as it doesn't introduce artefacts or other side-effects.
In the meantime, I managed to get qtscriptgenerator to build without patching
any other ports, a bit to my surprise.
https://trac.macports.org/ticket/47204#comment:17
The main issue appeared to be that qtsg does not only use qmake to find
components, but also includes its own internal search logic which is based in
part on the obsolete QTDIR env. variable.
Debian/Ubuntu exploit that by setting QTDIR=/usr/include/qt4 which is obviously
not at all what QTDIR was once intended for. I didn't dare to remove the QTDIR
setting from the Qt4 PortGroup at this point, so I unset it in the qtsg
Portfile.
I then introduce a patch to generator/main.h which queries a novel QTFRAMEWORKS
env.var (set in the qtsg Portfile) or else falls back to a hardcoded copy of
${qt_frameworks_dir}. That fallback appears to be redundant because the
generator is not installed (which I wasn't sure about when I wrote the patch).
An additional few lines that add ${prefix}/include/phonon allow the phonon code
to be compiled. They might not be required with a patched phonon mkspec file,
but
my current solution is much less likely to introduce side-effects.
I'll have to check some other time whether the 2 additional patchfiles I added
are actually required, but I won't be offended if someone beats me to it :)
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote: > Yes, I'm sure. Using the stock phonon mkspec file and commenting in some > of the debug "#"s from qt_functions.prf, I see the following. Fixing > qt_phonon.pri to "do the right thing" adds LIBS and INCLUDEPATH for > wherever phonon is installed. All of the various QtFOO libraries and/or Concretely, what's the change you make to qt_phonon.pri? Anyway, is your Qt4 PortGroup still setting QTDIR? I think the issue I'm seeing is due to that (in fact, I'm sure, from looking at generator/main.h). R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Fri, Oct 30, 2015, at 12:37 PM, René J. V. Bertin wrote:
> René J. V. Bertin wrote:
>
> > Michael Dickens wrote:
> >
> >> The error you show below with qtscriptgenerator is because it does not
> >> find phonon
> >
> > Are you sure? When I remove the typesystem_phonon line from generator.qrc
> > and
> > rebuild I still get the same error.
>
Yes, I'm sure. Using the stock phonon mkspec file and commenting in some
of the debug "#"s from qt_functions.prf, I see the following. Fixing
qt_phonon.pri to "do the right thing" adds LIBS and INCLUDEPATH for
wherever phonon is installed. All of the various QtFOO libraries and/or
frameworks are correctly found and processed by the qtscriptgenerator
code.
{{{
:info:build cd qtscript_phonon/ && /opt/local/libexec/qt4/bin/qmake
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon/qtscript_phonon.pro
-o Makefile
:info:build Project MESSAGE: In: mkspecs/modules/qt_phonon.pri
:info:build WARNING:
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon/qtscript_phonon.pro:5:
Unable to find file for inclusion
/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/generated_cpp/com_trolltech_qt_phonon/com_trolltech_qt_phonon.pri
:info:build Project MESSAGE: qtAddLibrary: LIBS before phonon is
:info:build Project MESSAGE: qtAddLibrary: INCLUDEPATH before phonon is
/opt/local/libexec/qt4/include .
/opt/local/libexec/qt4/include/phonon_compat
:info:build Project MESSAGE: qtAddLibrary: QMAKE_LFLAGS before phonon is
-headerpad_max_install_names -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.11
:info:build Project MESSAGE: qtAddLibrary: all frameworks is
-F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_dir is
-F/opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_path is
/opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_dir is
-F/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this frmwrk_path is
/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/Library/Frameworks
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for framework phonon
in directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: all library paths is
-L/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this lib_dir is
-L/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: this lib_path is
/opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: qtAddLibrary: looking for library phonon in
directory /opt/local/libexec/qt4/lib
:info:build Project MESSAGE: WARNING: Could not find library or
framework phonon in the current known search directories; assuming a
default library.
:info:build Project MESSAGE: qtAddLibrary: LIBS after phonon is now
-F/opt/local/libexec/qt4/Library/Frameworks -F/opt/local/libexec/qt4/lib
-L/opt/local/libexec/qt4/lib -lphonon
:info:build Project MESSAGE: qtAddLibrary: INCLUDEPATH after phonon is
now . /opt/local/libexec/qt4/include/phonon_compat
/opt/local/libexec/qt4/include/phonon /opt/local/libexec/qt4/include
:info:build Project MESSAGE: qtAddLibrary: QMAKE_LFLAGS after phonon is
now -headerpad_max_install_names -arch x86_64 -Xarch_x86_64
-mmacosx-version-min=10.11
[snip]
:info:build WARNING: Failure to find:
../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp
:info:build cd qtscript_phonon/ &&
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile all
:info:build make[2]: Entering directory
`/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/work/qtscriptgenerator-src-0.2.0/qtbindings/qtscript_phonon'
:info:build make[2]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp', needed by
`plugin.o'. Stop.
:info:build make[2]: Leaving directory
`/opt/local/var/macports/build/_Users_Shared_source_MacPorts_trunk_dports_devel_qtscriptgenerator/qtscriptgenerator/wor
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
René J. V. Bertin wrote:
> Michael Dickens wrote:
>
>> The error you show below with qtscriptgenerator is because it does not
>> find phonon
>
> Are you sure? When I remove the typesystem_phonon line from generator.qrc and
> rebuild I still get the same error.
In fact, I think the issue on my end goes beyond phonon:
%> (cd `port work qtscriptgenerator`/qtscript*/qtbindings ; wmake --MP -k)
cd qtscript_core/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile
make[1]: Nothing to be done for `first'.
cd qtscript_gui/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_gui-make_default] Error 2
cd qtscript_network/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make
-f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_network/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_network-make_default] Error 2
cd qtscript_opengl/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_opengl/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_opengl-make_default] Error 2
cd qtscript_sql/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_sql/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_sql-make_default] Error 2
cd qtscript_svg/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_svg/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_svg-make_default] Error 2
cd qtscript_xml/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -f
Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_xml/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_xml-make_default] Error 2
cd qtscript_phonon/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_phonon/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_phonon-make_default] Error 2
cd qtscript_webkit/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make -
f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_webkit/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_webkit-make_default] Error 2
cd qtscript_xmlpatterns/ &&
/Applications/Xcode.app/Contents/Developer/usr/bin/make -f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_xmlpatterns/plugin.cpp', needed by
`plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_xmlpatterns-make_default] Error 2
cd qtscript_uitools/ && /Applications/Xcode.app/Contents/Developer/usr/bin/make
-f Makefile
make[1]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_uitools/plugin.cpp', needed by `plugin.o'.
make[1]: Target `first' not remade because of errors.
make: *** [sub-qtscript_uitools-make_default] Error 2
(`wmake` is a wrapper for make that sets the environment like `port` does when
invoked with `--MP`)
For me, the issue appears to be that the qtsg build system expects to find the
Qt headers in ${prefix}/libexec/qt4/include/QtFoo.framework/Headers , which is
to me suggests that it has an issue with a frameworks build. When I populate
that include directory with symlinks to the frameworks, the build goes further,
but aborts with errors like
Undefined symbols for architecture x86_64:
"qtscript_initialize_com_trolltech_qt_opengl_bindings(QScriptValue&)",
referenced from:
com_trolltech_qt_opengl_ScriptPlugin::initialize(QString const&,
QScriptEngine*) in plugin.o
ld: symbol(s) not found for architecture x86_64
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
What I'm planning on doing for Phonon is modifying its mkspec file to
correctly do "LIBS *=..." no matter where Phonon is installed. That
seems like a nice robust solution.
goldendict does not seem to actually use Phonon. It does use qmake, but
does no do "CONFIG *= phonon" anywhere. No idea why the dependency is
there. It does not work with ffmpeg-devel, so it won't build for me. I
really wish the ffmpeg folks would decide where to put their headers &
not change them.
py*-pyqt4 doesn't actually use qmake to determine where phonon is
located; it does that for just the Qt* libraries / frameworks. It uses
some other magic to determine info for phonon. MacPorts sets CFLAGS to
include "-I${prefix}/include" and LDFLAGS to include "-L${prefix}/lib",
so it's no great surprise that phonon is being found.
qtscriptgenerator uses qmake to find phonon via the "CONFIG *= phonon"
command, and it fails because of the aforementioned reasons. - MLD
On Fri, Oct 30, 2015, at 11:18 AM, René J.V. Bertin wrote:
> Michael Dickens wrote:
>
> > is to make sure that either (1) "LIBS *= -L${prefix}/lib" is in place
>
> That seems like a small enough modification to qtscriptgenerator that if
> it works is much preferable to "hiding" phonon under libexec/qt4 ...
>
> > in ${prefix}/lib for phonon. What other projects use qmake and require
> > phonon? I'd like to test out this theory before pushing changes into
> > phonon. - MLD
>
> I was under the impression you knew better than I, but there's the list
> of all ports that declare a dependency on phonon in their Portfile
> (excluding qt4-mac and qt4-x11):
>
> %> fgrep -il qmake `fgrep -il phonon -R
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/
> --include=Portfile `
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/devel/qtscriptgenerator/Portfile
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/office/goldendict/Portfile
> /opt/local/var/macports/sources/svn.macports.org/trunk/dports/python/py-pyqt4/Portfile
>
>
> I checked again this morning: goldendict builds though I can see no trace
> of it actually depending on phonon in the build log nor in the resulting
> binary. I have py27-pyqt4+phonon and py34-pyqt4 installed, and as far as
> I can tell those are fully functional:
>
> %> otool -L
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
> /opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so:
> /opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0,
> current version 4.8.3)
>
> /opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui
> (compatibility version 4.8.0, current version 4.8.7)
>
> /opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore
> (compatibility version 4.8.0, current version 4.8.7)
> /System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
> (compatibility version 45.0.0, current version 1265.21.0)
> /usr/lib/libc++.1.dylib (compatibility version 1.0.0, current
> version 120.0.0)
> /usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
> version 1197.1.1)
>
> R
> ___
> macports-dev mailing list
> macports-dev@lists.macosforge.org
> https://lists.macosforge.org/mailman/listinfo/macports-dev
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote: > The error you show below with qtscriptgenerator is because it does not > find phonon Are you sure? When I remove the typesystem_phonon line from generator.qrc and rebuild I still get the same error. Adding `LIBS += -L/opt/local/lib` to qtsg.pro doesn't make a difference either. R. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote:
> is to make sure that either (1) "LIBS *= -L${prefix}/lib" is in place
That seems like a small enough modification to qtscriptgenerator that if it
works is much preferable to "hiding" phonon under libexec/qt4 ...
> in ${prefix}/lib for phonon. What other projects use qmake and require
> phonon? I'd like to test out this theory before pushing changes into
> phonon. - MLD
I was under the impression you knew better than I, but there's the list of all
ports that declare a dependency on phonon in their Portfile (excluding qt4-mac
and qt4-x11):
%> fgrep -il qmake `fgrep -il phonon -R
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/
--include=Portfile `
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/devel/qtscriptgenerator/Portfile
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/office/goldendict/Portfile
/opt/local/var/macports/sources/svn.macports.org/trunk/dports/python/py-pyqt4/Portfile
I checked again this morning: goldendict builds though I can see no trace of it
actually depending on phonon in the build log nor in the resulting binary. I
have py27-pyqt4+phonon and py34-pyqt4 installed, and as far as I can tell those
are fully functional:
%> otool -L
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so
/opt/local/Library/Frameworks/Python.framework/Versions/2.7/lib/python2.7/site-packages/PyQt4/phonon.so:
/opt/local/lib/libphonon.4.dylib (compatibility version 4.4.0, current
version 4.8.3)
/opt/local/libexec/qt4/Library/Frameworks/QtGui.framework/Versions/4/QtGui
(compatibility version 4.8.0, current version 4.8.7)
/opt/local/libexec/qt4/Library/Frameworks/QtCore.framework/Versions/4/QtCore
(compatibility version 4.8.0, current version 4.8.7)
/System/Library/Frameworks/AppKit.framework/Versions/C/AppKit
(compatibility version 45.0.0, current version 1265.21.0)
/usr/lib/libc++.1.dylib (compatibility version 1.0.0, current version
120.0.0)
/usr/lib/libSystem.B.dylib (compatibility version 1.0.0, current
version 1197.1.1)
R
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
The error you show below with qtscriptgenerator is because it does not
find phonon & thus there is no cpp code generated --> but the build
system does not know this for some reason & tries to build anyway.
Adding in QCA-like qmake code into the phonon mkspec file does the trick
for finding phonon via qmake. But, even with that addition
qtscriptgenerator still does not build (at least to 10.11 latest
everything). As I said, I'm looking into it. My read of the qmake /
phonon combo is that the only way using qmake to find phonon will work
is to make sure that either (1) "LIBS *= -L${prefix}/lib" is in place
before doing "CONFIG *= phonon"; or (2) including a project that sets
LIBS accordingly before adding in phonon. Otherwise, qmake will not look
in ${prefix}/lib for phonon. What other projects use qmake and require
phonon? I'd like to test out this theory before pushing changes into
phonon. - MLD
On Fri, Oct 30, 2015, at 05:33 AM, René J. V. Bertin wrote:
> The difference here is that QCA provides hooks to install that way, or at
> least
> to indicate it where the various Qt components are installed. Phonon
> doesn't
> AFAIK (and port:phonon certainly doesn't seem to add them).
>
> I have been taking a look at qtscriptgenerator. It doesn't build indeed:
>
> :info:build make[2]: *** No rule to make target
> `../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by
> `plugin.o'.
> Stop.
>
> but that failure is not related to phonon. I do see an issue finding
> phonon, but
> that appears to be more related to the fact that qtscriptgenerator looks
> for a
> phonon *framework* (as opposed to a .dylib).
> BTW: I'll be trying the workaround described here:
> https://code.google.com/p/qtscriptgenerator/issues/detail?id=39
> but I guess I should also check out why the build system looks for
> headers in
> ${prefix}/libexec/qt4/include which doesn't exist in my layout.
>
> Every other dependency of phonon I installed that uses qmake finds phonon
> just
> fine with libphonon in ${prefix}/lib and the Qt4 frameworks in
> ${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to
> those
> framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can
> tell, that
> is *not* because I also have libqt symlinks in ${prefix}/lib (my qt4-mac-
> transitional subport).
>
> Coming back to qtscriptgenerator: I'm looking at how Ubuntu gets it to
> build,
> but the real question we have to ask for this port is whether it is worth
> the
> effort trying to resurrect abandonware. The only dependent I could find
> is
> amarok, and the application is built *without* qtscriptgenerator on
> Linux.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote:
> qtscriptgenerator is having issues with locating phonon now that it's
> not co-located with the qt4 install. Like QCA, it might make sense to
> just co-locate phonon into the new qt4 install prefix.
The difference here is that QCA provides hooks to install that way, or at least
to indicate it where the various Qt components are installed. Phonon doesn't
AFAIK (and port:phonon certainly doesn't seem to add them).
I have been taking a look at qtscriptgenerator. It doesn't build indeed:
:info:build make[2]: *** No rule to make target
`../../generated_cpp/com_trolltech_qt_gui/plugin.cpp', needed by `plugin.o'.
Stop.
but that failure is not related to phonon. I do see an issue finding phonon,
but
that appears to be more related to the fact that qtscriptgenerator looks for a
phonon *framework* (as opposed to a .dylib).
BTW: I'll be trying the workaround described here:
https://code.google.com/p/qtscriptgenerator/issues/detail?id=39
but I guess I should also check out why the build system looks for headers in
${prefix}/libexec/qt4/include which doesn't exist in my layout.
Every other dependency of phonon I installed that uses qmake finds phonon just
fine with libphonon in ${prefix}/lib and the Qt4 frameworks in
${prefix}/libexec/qt4/Library/Frameworks and .dylib symlinks pointing to those
framework binaries in ${prefix}/libexec/qt4/lib . And as far as I can tell,
that
is *not* because I also have libqt symlinks in ${prefix}/lib (my qt4-mac-
transitional subport).
Coming back to qtscriptgenerator: I'm looking at how Ubuntu gets it to build,
but the real question we have to ask for this port is whether it is worth the
effort trying to resurrect abandonware. The only dependent I could find is
amarok, and the application is built *without* qtscriptgenerator on Linux.
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Michael Dickens wrote:
> qmake PortGroups, just needed a rev-bump. Some ports such as phonon
> install files that =assume= the same install prefix as Qt, and so when
> they are installed elsewhere everything breaks down for ports that
> depend on them (e.g., using qmake to find phonon fails unless some
> library located in ${prefix}/lib is included before phonon; cmake and
I haven't had any issues with phonon; what ports (using qmake?) break when
phonon isn't installed in Qt's prefix?
The question is also what the Qt prefix is, if everything is NOT installed in
an
all-encompassing prefix. Qt5 is more flexible in this aspect; with my install
layout it considers the prefix to be ${prefix}, despite the fact that the bin
and lib dirs are in ${prefix}/libexec/qt5 .
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Here's my take: Qt4 needed to be moved out of the way to be installable
in parallel with Qt5, and, by moving everything into a location where
you have to know where it is, we really test the build systems for those
ports that use Qt4/5. Many ports, generally those that use the qt4 or
qmake PortGroups, just needed a rev-bump. Some ports such as phonon
install files that =assume= the same install prefix as Qt, and so when
they are installed elsewhere everything breaks down for ports that
depend on them (e.g., using qmake to find phonon fails unless some
library located in ${prefix}/lib is included before phonon; cmake and
pkgconfig, when variables are set correctly, work nicely).
Once the vast majority of ports have been fixed to work with the new
Qt4/5 location, we can figure out where we actually want stuff to go &
fix it -- for example, moving all Qt4/5 pkgconfig files to be in
${prefix}/lib/pkgconfig/; cmake files into ${prefix}/share/cmake/... .
In the meantime, let's get the ports that are failing when using Qt4/5
working -- I think this should be our priority right now. So, this means
fixing phonon's mkspec file to do the right thing no matter where phonon
is installed; and, fixing qtscriptgenerator -- which BTW has been broken
off and on for along time because it has been EOL for 2-3 years. I'll be
working on these in the coming days; I think I've got a fix for the
former, and am making slow progress on the latter too. Fun times! - MLD
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Ohoh, so this is finally where I get to say "I told you so"?
@Michael Dickens wrote:
> qtscriptgenerator is having issues with locating phonon now that it's
> not co-located with the qt4 install. Like QCA, it might make sense to
> just co-locate phonon into the new qt4 install prefix.
Yeah, and while ye-all are at it, why not co-locate everything that depends on
Qt4 in the new qt4 prefix?
In other words: "le monde à l'envers"
@Craig wrote
> Something I wondered about was the choice of ${prefix}/libexec/blah
Quite a few ports ("base" and llvm/clang included) use libexec as prefix-in-a-
prefix. When I proposed libexec/qt4 and libexec/qt5 (sic) way back,it seemed
more
in line with existing practice to abuse the libexec directory than the lib
directory. After all, libexec can be read as "lib[s] plus exec[s]", which is
exactly the case *for my install layout*.
@Mojca wrote:
> In my opinion it is also *much* better if CMake and pkg-config files
> end up where they are supposed to be.
Yep. With CMake it's less clear what exactly that place, since there are
several
locations that are used (and not each by a single port). But in any case, I
think it's safest not to change such locations from what the port intends (and
other ports/packages will expect) if it is not to use a central location
instead.
> (There are also many other files
> like "libexec/qt4/share/doc" that could easily be in "share/doc/qt4/"
> etc, even though those are not as critical.)
Of course. There was never a reason to move those in the 1st place, and that
includes share/qtN/* (which includes mkspecs and plugins).
I also don't see why the headers should be hidden so deeply. Installing them in
${prefix}/include/qtN works just fine, and makes reading build logs a lot more
legible.
@Rainer wrote:
> I only noticed this now, but it seems this change will cause problems:
Did you miss my "about MacPorts principles, conventions (and dogmata :)) re:
install layouts and Qt" message on this ML?
> Please do not simply drop everything related to Qt into its own prefix.
Hear hear ... I have been insisting on that for almost a year now, to no avail.
> I definitely don't want to discredit the work of René
Thanks, I for one didn't think you did. In fact, I understand that no one wants
to do that, but there clearly isn't much intent to more than doing verbal
credit
to my work either.
(Which is why I caught wind of this thread only now: I stopped following ML
activity that is not in reaction to a query of my own.)
> I understand that some of these parts conflict in filename
Way less that you'd think actually, largely because the original install schema
already used qt4 and qt5 directories (in ${prefix}/share) and because the Qt5
libraries and a number of other installed (Qt5) files have some form of Qt5 in
their names.
Let's not forget that Qt5 was designed to co-install with Qt4 with minimal
effort even on platforms where Qt is (almost) part of the system libraries.
That
is also why there's something called qtchooser.
@Rainer asked:
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
It has to do with that, yes. Marko's guess notwithstanding, the real reason I
have seen invoked is
"Qt itself installs like that on OS X"
To put it bluntly: that is true, but completely irrelevant. (Qt-for-OS X itself
doesn't intend to be used the way it is in MacPorts.)
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
Guilty as charged even with my install layout. However:
- I provide symlinks suffixed with -qt4 and -qt5 for a number of commonly used
execs
- there is port:qtchooser which also installs symlinks, to itself, and then
acts
as a wrapper that can be configured to proxy for multiple Qt installs
(including
a default install). A bit like a port select scheme, but more flexible.
R.
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Thu, Oct 29, 2015 at 6:02 PM, Rainer Müller wrote:
> On 2015-10-29 17:05, Mojca Miklavec wrote:
>>
>> When 10.11 came out (where Qt 4 no longer worked), the
>> switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
>> hurry, so the maintainer decided for the easier path to simply put
>> everything under the same prefix.
>
> I understand that some of these parts conflict in filename, but the
> files I mentioned do not. They can co-exist in ${prefix}/lib/pkgconfig/
> or ${prefix}/share/cmake/ (Qt* for qt4 and Qt5* for qt5). I see no
> reason to move these files.
In my opinion it is also *much* better if CMake and pkg-config files
end up where they are supposed to be. (There are also many other files
like "libexec/qt4/share/doc" that could easily be in "share/doc/qt4/"
etc, even though those are not as critical.)
It's just that it was a lot easier to move those files (just add
--prefix=... to configure) than not to move them at that time.
If it was a smaller package, I would say "let's just commit the change
that fixes that", but it might be wise to at least collect all the
changes that are worth making and that are "safe enough" to make to
avoid unnecessary rebuilds. (But then again not to wait forever.)
>> Any port than requires Qt should include one of the two qt portgroups
>> that sets all the necessary variables, so that even if Qt 4/5 layout
>> changes again, it should be a simple matter of a revbump of
>> dependents.
>
> That is correct for use of Qt by dependent ports. However, if a user
> wants to compile software from source which is not yet provided in a
> port (or builds their own version for development), manually setting up
> PKG_CONFIG_PATH and/or CMAKE_MODULE_PATH is cumbersome.
True. (Even though that is also a problem for many other
ports/libraries that we ship.)
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On 2015-10-29 17:05, Mojca Miklavec wrote:
> This special layout is something that René has been working on for
> months, but nobody looked into his work for a very long time (and
> nobody felt the pressing need to fix the situation with conflicting
> Qt4 and Qt5).
This is true what you say about reviewing. I stuck with Qt4 only as long
as the Qt versions conflicted.
I definitely don't want to discredit the work of René and others for
getting Qt4 and Qt5 along. Thank you for working on this!
> When 10.11 came out (where Qt 4 no longer worked), the
> switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
> hurry, so the maintainer decided for the easier path to simply put
> everything under the same prefix.
I understand that some of these parts conflict in filename, but the
files I mentioned do not. They can co-exist in ${prefix}/lib/pkgconfig/
or ${prefix}/share/cmake/ (Qt* for qt4 and Qt5* for qt5). I see no
reason to move these files.
> Qt4 and Qt5 are maintained by different people which complicates matters a
> bit.
>
> I still hope that the idea is to eventually:
> - put different things under appropriate prefixes (like the three
> examples mentioned above)
> - unify paths for Qt 4 and Qt 5 (the is no need to use a "-mac" postfix)
>
> Any port than requires Qt should include one of the two qt portgroups
> that sets all the necessary variables, so that even if Qt 4/5 layout
> changes again, it should be a simple matter of a revbump of
> dependents.
That is correct for use of Qt by dependent ports. However, if a user
wants to compile software from source which is not yet provided in a
port (or builds their own version for development), manually setting up
PKG_CONFIG_PATH and/or CMAKE_MODULE_PATH is cumbersome.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Thu, Oct 29, 2015 at 4:09 PM, Rainer Müller wrote:
> On 2015-10-27 22:24, Marko Käning wrote:
>> Hi Nicolas,
>>
>> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
>> have rebumped ports kate, libkgapi and konversation.
>>
>> For instance, the latter tried to find libqca in it’s old location
>> ---
>> Dyld Error Message:
>> Library not loaded: /opt/local/lib/libqca.2.dylib
>> Referenced from:
>> /Applications/MacPorts/*/konversation.app/Contents/MacOS/konversation
>> Reason: image not found
>> ---
>> which has - in the meantime - moved into $PREFIX/libexec/qt4/lib/:
>
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
>
> I only noticed this now, but it seems this change will cause problems:
>
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
> * pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
> found by default (needs additional PKG_CONFIG_PATH)
> * cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
> by default (needs additional CMAKE_MODULE_PATH)
>
> The same seems to apply to qt5-mac as well. Also, the choice of
> ${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
>
> Please do not simply drop everything related to Qt into its own prefix.
> At least keep the files mentioned above in the default locations where
> they can be found and used by other build systems.
This special layout is something that René has been working on for
months, but nobody looked into his work for a very long time (and
nobody felt the pressing need to fix the situation with conflicting
Qt4 and Qt5). When 10.11 came out (where Qt 4 no longer worked), the
switch to Qt 5 and moving Qt 4 away suddenly had to be done in a
hurry, so the maintainer decided for the easier path to simply put
everything under the same prefix.
Qt4 and Qt5 are maintained by different people which complicates matters a bit.
I still hope that the idea is to eventually:
- put different things under appropriate prefixes (like the three
examples mentioned above)
- unify paths for Qt 4 and Qt 5 (the is no need to use a "-mac" postfix)
Any port than requires Qt should include one of the two qt portgroups
that sets all the necessary variables, so that even if Qt 4/5 layout
changes again, it should be a simple matter of a revbump of
dependents.
Mojca
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
> On Oct 29, 2015, at 11:09 AM, Rainer Müller wrote:
>
> What was the reason for moving Qt4 into its own prefix? I guess this is
> about allowing Qt4 and Qt5 to be installed at the same time?
>
> I only noticed this now, but it seems this change will cause problems:
>
> * binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
> * pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
> found by default (needs additional PKG_CONFIG_PATH)
> * cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
> by default (needs additional CMAKE_MODULE_PATH)
>
> The same seems to apply to qt5-mac as well. Also, the choice of
> ${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
>
> Please do not simply drop everything related to Qt into its own prefix.
> At least keep the files mentioned above in the default locations where
> they can be found and used by other build systems.
Something I wondered about was the choice of ${prefix}/libexec/blah . The
other example of co-installable versions/forks that I’m familiar with is mysql.
Those ports install the binaries into ${prefix}/lib/blah (e.g..
/opt/local/lib/mariadb/bin/ ). I have no idea if one approach is “right”—just
that the mysql structure has been around longer and could be considered a
precedent.
Craig
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On 2015-10-27 22:24, Marko Käning wrote:
> Hi Nicolas,
>
> while building kdevelop and kdepim4 I came across some rev-upgrades… Thus I
> have rebumped ports kate, libkgapi and konversation.
>
> For instance, the latter tried to find libqca in it’s old location
> ---
> Dyld Error Message:
> Library not loaded: /opt/local/lib/libqca.2.dylib
> Referenced from:
> /Applications/MacPorts/*/konversation.app/Contents/MacOS/konversation
> Reason: image not found
> ---
> which has - in the meantime - moved into $PREFIX/libexec/qt4/lib/:
What was the reason for moving Qt4 into its own prefix? I guess this is
about allowing Qt4 and Qt5 to be installed at the same time?
I only noticed this now, but it seems this change will cause problems:
* binaries in ${prefix}/libexec/qt4/bin are inaccessible and not in PATH
* pkg-config files in ${prefix}/libexec/qt4/lib/pkgconfig/ will not be
found by default (needs additional PKG_CONFIG_PATH)
* cmake modules in ${prefix}/libexec/qt4/share/cmake/ will not be found
by default (needs additional CMAKE_MODULE_PATH)
The same seems to apply to qt5-mac as well. Also, the choice of
${prefix}/libexec/qt4/ vs. ${prefix}/libexec/qt5-mac/ looks inconsistent.
Please do not simply drop everything related to Qt into its own prefix.
At least keep the files mentioned above in the default locations where
they can be found and used by other build systems.
Rainer
___
macports-dev mailing list
macports-dev@lists.macosforge.org
https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Hello, >> >> No. All ports need to be revbumped (preferrably as soon as possible). >> It's just that there were sooo many ports that revbumping all >> could not be easily done by a single person. > > OK, thanks for reassuring me here. Yes, I had started listing all the KDE ports which need a revbump, but lacked time to proceed on this. Hopefully I could get on it in the next few days. > These two ports still have other problems, which I haven’t yet investigated: > > - qtscriptgenerator > - kdesdk-kioslaves Some ports in the KDE suite have indeed other issues that need to be fixed. I am gradually looking at these too. Cheers, Nicolas ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
qtscriptgenerator is having issues with locating phonon now that it's not co-located with the qt4 install. Like QCA, it might make sense to just co-locate phonon into the new qt4 install prefix. I'm looking into it. - MLD On Tue, Oct 27, 2015, at 05:48 PM, Marko Käning wrote: > Answering my own question now, at least partially, since a rev-upgrade > just gave me this much longer list: > --- > ---> Found 38 broken port(s), determining rebuild order > ---> Rebuilding in order > qtscriptgenerator @0.2.0 > [snip] > --- > which is my host and not the Mavericks-VM I was testing on earlier. > > Unfortunately qtscriptgenerator fails to build now, being the first in > this list… > > No time for more digging now. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Oct 27, 2015, at 6:07 PM, Marko Käning wrote: > > (When will Apple’s new admin have all those issues fixed I wonder…) I am in communication with the admin and his manager about these issues. I don't know how many details I should share right now but I hope to be able to announce a solution soon. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Hi Mojca,
On 27 Oct 2015, at 23:30 , Mojca Miklavec wrote:
> On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote:
>> Should we forget about revbumping everything and simply rely on that the
>> sanity of our users’ MacPorts installations
>> will be taken care of by rev-upgrade?
>
> No. All ports need to be revbumped (preferrably as soon as possible).
> It's just that there were sooo many ports that revbumping all
> could not be easily done by a single person.
OK, thanks for reassuring me here.
> Feel free to start revbumping those on the list (I had problems with
> gpsd as well, but I postponed it because I find it weird that it links
> against Qt in the first place – that looks like a bug to me).
I did so for 2 more a few minutes ago.
Will also have to retrigger builds of kmymoney4(-devel) later, once gwenhywfar4
and aqbanking5 are through.
Yep, that’s a major task to get all those revbumped, but unavoidable then.
Too bad that trac's timeline doesn’t show the commits anymore and that the
buildbots still have problems picking up new commits as well.
(When will Apple’s new admin have all those issues fixed I wonder…)
Yes, I saw also gpsd rebuilding here… No clue as to why though.
These two ports still have other problems, which I haven’t yet investigated:
- qtscriptgenerator
- kdesdk-kioslaves
Also I noticed that kbuildsycoca4 complains a lot at the moment:
---
$ kbuildsycoca4
kbuildsycoca4 running...
kbuildsycoca4(87651)/kdecore (KSycoca) KSycocaPrivate::openDatabase: Trying to
open ksycoca from "/private/var/tmp/kdecache-marko/ksycoca4"
kbuildsycoca4(87651) kdemain: Reusing existing ksycoca
kbuildsycoca4(87651) KBuildSycoca::recreate: Recreating ksycoca file
("/private/var/tmp/kdecache-marko/ksycoca4", version 242)
kbuildsycoca4(87651) KBuildSycoca::build: Still in the time dict (i.e. deleted
files) ("apps")
kbuildsycoca4(87651) VFolderMenu::pushDocInfo: Menu
"applications-kmenuedit.menu" not found.
kbuildsycoca4(87651) VFolderMenu::processMenu: Processing KDE Legacy dirs for
kbuildsycoca4(87651) VFolderMenu::processKDELegacyDirs:
kbuildsycoca4(87651) VFolderMenu::loadApplications: Looking up applications
under "/opt/local/share/applications/"
kbuildsycoca4(87651) VFolderMenu::loadApplications: Looking up applications
under "/opt/local/share/applications/kde4"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"plasma-kpart.desktop" specifies undefined mimetype/servicetype "KParts/Part"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"ServiceMenus/imageconverter.desktop" specifies undefined mimetype/servicetype
"image/*"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/gimp.desktop" specifies undefined
mimetype/servicetype "image/x-gimp-gbr"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/gimp.desktop" specifies undefined
mimetype/servicetype "image/x-gimp-pat"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/gimp.desktop" specifies undefined
mimetype/servicetype "image/x-gimp-gih"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/gimp.desktop" specifies undefined
mimetype/servicetype "image/x-psp"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/kde4/kdevelop_ps.desktop" specifies undefined
mimetype/servicetype "application/x-kdevelop"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/kde4/kmymoney.desktop" specifies undefined
mimetype/servicetype "application/vnd.intu.qfx"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/kde4/kmymoney.desktop" specifies undefined
mimetype/servicetype "application/x-ofx"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/kde4/lokalize.desktop" specifies undefined
mimetype/servicetype "application/x-lokalize-project"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"ServiceMenus/choqok_upload.desktop" specifies undefined mimetype/servicetype
"image/*"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"windowsexethumbnail.desktop" specifies undefined mimetype/servicetype
"application/x-msdownload"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/vlc.desktop" specifies undefined
mimetype/servicetype "video/x-flc"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/vlc.desktop" specifies undefined
mimetype/servicetype "audio/x-ms-asf"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/local/share/applications/vlc.desktop" specifies undefined
mimetype/servicetype "audio/x-ms-wax"
kbuildsycoca4(87651) KBuildServiceFactory::populateServiceTypes:
"/opt/
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On Tue, Oct 27, 2015 at 11:03 PM, Marko Käning wrote: > On 27 Oct 2015, at 22:48 , Marko Käning wrote: > >> Answering my own question now, at least partially, since a rev-upgrade just >> gave me this much longer list: > > Should we forget about revbumping everything and simply rely on that the > sanity of our users’ MacPorts installations > will be taken care of by rev-upgrade? No. All ports need to be revbumped (preferrably as soon as possible). It's just that there were sooo many ports that revbumping all could not be easily done by a single person. Feel free to start revbumping those on the list (I had problems with gpsd as well, but I postponed it because I find it weird that it links against Qt in the first place – that looks like a bug to me). Mojca ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
On 27 Oct 2015, at 22:48 , Marko Käning wrote: > Answering my own question now, at least partially, since a rev-upgrade just > gave me this much longer list: Should we forget about revbumping everything and simply rely on that the sanity of our users’ MacPorts installations will be taken care of by rev-upgrade? ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
Re: All KDE ports need a major revbump, due to recent changes to qt4-mac
Answering my own question now, at least partially, since a rev-upgrade just gave me this much longer list: --- ---> Found 38 broken port(s), determining rebuild order ---> Rebuilding in order qtscriptgenerator @0.2.0 kdenlive @0.9.10 kdiff3 @0.9.98 litecoin @0.8.7.4 cervisia @4.14.3 kapptemplate @4.14.3 kcachegrind4 @4.14.3 kde-dev-utils @4.14.3 kde4-filelight @4.14.3 kdesdk-kioslaves @4.14.3 kdesdk-strigi-analyzers @4.14.3 kdesdk-thumbnailers @4.14.3 libkdegames @4.14.3 kgoldrunner @4.14.3 +docs killbots @4.14.3 +docs kjumpingcube @4.14.3 +docs kmines @4.14.3 libkomparediff2 @4.14.3 kompare @4.14.3 konquest @4.14.3 +docs kpat @4.14.3 +docs kubrick @4.14.3 +docs libkdcraw @4.14.3 libkipi @4.14.3 libksane @4.14.3 lokalize @4.14.3 okteta @4.14.3 palapeli @4.14.3 +docs poxml @4.14.3 smokegen @4.14.3 smokeqt @4.14.3 umbrello @4.14.3 libgpod @0.8.3 +python27 libkdeedu @4.14.3 kde4-workspace @4.14.4.20150324 +oxygen gwenhywfar4-devel @4.14.0 gpsd @3.14 marble @4.14.3 --- which is my host and not the Mavericks-VM I was testing on earlier. Unfortunately qtscriptgenerator fails to build now, being the first in this list… No time for more digging now. ___ macports-dev mailing list macports-dev@lists.macosforge.org https://lists.macosforge.org/mailman/listinfo/macports-dev
