Despite what the patch's commit message says, this is actually a fix for
https://bugs.kde.org/show_bug.cgi?id=340015, which is part of 4.14.3. It
allows filtering based on the "List-Id" header to work again.
- Update to 0.9.0
- Remove pinentry-gtk port (GTK+ 1 support is discontinued upstream)
- Ignore Qt 4 frontend on 10 and greater, it fails to build with clang/libc++
Since r372179 we are using the QML headers from the tarball, not the ones
installed system-wide by qt5-qml.
While this is not a problem and is kind of intended, it also means we need
to apply patches like this one to both ports now.
Simply patching src/src.pro to remove those directories from the build does
not work in all cases. If an older version of qt5-quick is installed, their
.pri files in mkspecs/modules will be picked up, and in the end when linking
programs such as tools/qmltestrunner something like this happens:
c++ [...] -Wl,-rpath-link,/usr/local/lib -o ../../bin/qmltestrunner
-L${WRKSRC}/lib -lQt5QuickTest [...]
The -rpath-link linker option will make ${LOCALBASE}/lib take precedence in
directory lookups, so when the newly-built libQt5QuickTest.so asks for
libQt5Quick.so in its DT_NEEDED section the older version installed in
${LOCALBASE}/lib will be used instead of the one that has just been built.
If the new version has symbols the older one does not (Qt releases are
backwards, not forwards, compatible), the build will fail.
So instead of patching src/src.pro, we let the configuration process proceed
without any patching so that the local .pri files are created in
${WRKSRC}/mkspecs and the Makefiles are created in a way that -rpath-link is
not passed to the linker anymore. We only need to symlink the existing
libraries built by lang/qt5-qml (this is similar to what we do with qtbase
ports to avoid rebuilding tools such as qmake and moc), and then change the
Makefiles in src/qml and src/qmldevtools so that nothing gets built.
This might even be a solution for other ports that got .pro patches in
r372179, since depending on which parts depend on which the same thing could
happen in the future.
I'm not bumping PORTREVISION because the resulting binaries will not change
and this only fixes the build where it was broken before.
PR: 194870
Technically any Ruby version 1.9 or newer isn't supported:
https://docs.puppetlabs.com/guides/platforms.html#ruby-versions
but I didn't hear any complaints about Puppet 2.7 not working until 2.0 became
default, so leave it for now, instead of deleting it.
