Most USES use a colon for build/run(/test) suffixes. Change kde.mk,
qt.mk and pyqt.mk to do the same, and update all ports using that.
Document in CHANGES.
PR: 266034
Exp-run by: antoine
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D36349
- update patch-collection diff to be at the highest patch-level
- update patch-collection diff to be against 5.15.5 instead of 5.15.2
- update devel/qt5-script to 5.15.10
- libressl support by Felix Palmen <felix@palmen-it.de>
PR: 264944
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D35619
- convert bsd.gstreamer.mk to Uses/gstreamer.mk
- convert ports tree to make use of USES=gstreamer
- remove duplicate dependency lines from the tree
Differential Revision: https://reviews.freebsd.org/D35097
From [1]
What's this?
This is a set of git repositories based on the last public
commits available for Qt 5.15 branches with a curated collection
of patches on top to ensure open source products can be used
comfortably until users transition to their Qt 6-based ports.
Which patches does it include?
This collection of patches includes patches that fix at least
one of the following:
* Security issues
* Crashes
* Functional defects
We only include patches that have been approved upstream in the
Qt project. If a patch cannot be merged upstream for technical
reasons (e.g. the class no longer exists), it can also be
merged.
The patches to merge will be decided based on their relevance
towards Open Source products and their viability.
PR: 260548
Exp-run by: antoine
Differential Revision: https://reviews.freebsd.org/D33446
[1] https://community.kde.org/Qt5PatchCollection
While qt5-multimedia **works** with gstreamer-gl, it's unexpected,
and not listed as a dependency. Sabotage the detection of gstreamer-gl
by breaking the include path it looks for.
We might consider adding gstreamer-gl to the dependencies, to
get better overall GL support, but that's a more involved change.
PR: 245909
Reported by: Martin Birgmeier
Per discussion with bapt on helping pkg handle the changing of these
deps and avoiding impossible upgrade senarios.
PR: 246767
Reviewed by: manu, bapt
Approved by: x11
Differential Revision: https://reviews.freebsd.org/D30824
All the qt5-ports share the same library directory. devel/qt5-core is dependet on
by all others.
So there is no need to add identical entries to libdata/ldconfig, and restart the
ldconfig service on every pkg change of those ports.
Reported by: bapt
Reviewed by: bapt
Differential Revision: https://reviews.freebsd.org/D27224
In r451940 this was made exclusive, to follow the internal build system
of Qt. However, nowadays, the two backends are coinstallable again.
PR: 249406
Submitted by: yuri
This is a major upgrade of the Qt libraries [1], [2].
* People that use upgrading mechanisms with incomplete dependency handling
(portmaster & Co) should make sure to manually remove the existing Qt
packages to guarantee a safe upgrade. Keep in mind, that Qt does not like if
you have an incomplete upgrade.
* This version of Qt drops support for OpenSSL 1.0 -- this means that there
won't be any binary packages for Qt5 provided by the FreeBSD package builders
for FreeBSD 11.x anymore -- and the same for *all* the ports depending on
net/qt5-network [3]. If you cannot upgrade to a more recent FreeBSD
version (12.x, 13.x), you will need to build Qt5 from ports while switching
to an SSL implementation from ports.
Big thanks are due for
* kai@ for updating webengine (also mikael@)
* Felix Palmen for providing LibreSSL support patches
* adridg@ and lbartoletti@ for helping me fix the fallout
[1] https://www.qt.io/blog/qt-5.15-released
[2] https://wiki.qt.io/New_Features_in_Qt_5.15
[3] https://www.freshports.org/net/qt5-network
PR: 247010
Exp-run by: antoine
Very big thanks go again to kai@ who provided the www/qt5-webengine upgrade (to 5.14.0).
Notably, video capture support was re-enabled.
Announcement:
https://www.qt.io/blog/qt-5.14-has-released
PR: 244964
Exp-run by: antoine
The knob was already there, but didn't have any machinery attached.
- Move USES=openal to the knob
- Introduce a patch to actually make openal configurable
(instead of only following autodetect, so you can still
turn the knob off with OpenAL installed)
- Tidy the port a little
- Add OPENAL to default options.
Previously, setting or unsetting OPENAL had no effect, and OpenAL
was always a dependency and used. Now, it does have an effect.
I've made it default so that the default options still match
what the port previously did (that is, depend on OpenAL).
Bump PORTREVISION because of that.
(Based very loosely on a patch submitted by Piotr Smyrak)
PR: 242595
Reported by: Piotr Smyrak
as defined in Mk/bsd.default-versions.mk which has moved from GCC 8.3
to GCC 9.1 under most circumstances now after revision 507371.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, everything INDEX-11 shows with a dependency on lang/gcc9 now.
PR: 238330
Release announcement:
https://blog.qt.io/blog/2019/02/01/qt-5-12-1-released/
Changelog:
https://wiki.qt.io/Qt_5.12.1_Change_Files
- A change was required to qt-dist.mk to always pass LOCALBASE to qmake,
as Qt5 has been installed to a prefix for some time now, there should
not be any harm in that, with respect to it picking up installed versions
of itself during build.
PR: 235622
Exp-run by: antoine
a symbol matches multiple clauses the last one takes precedence. If the
catch-all is last it captures everything. In the case of Qt5 libraries
this caused all symbols to have a Qt_5 label while some should have
Qt_5_PRIVATE_API. This only affects lld because GNU ld always gives the
catch-all lowest priority.
Older versions of Qt5Webengine exported some memory allocation symbols from
the bundled Chromium. Version 5.9 stopped exporting these [1] but the
symbols were kept as weak wrappers for the standard allocation functions to
maintain binary compatibility. [2][3] The problem is that the call to the
standard function in these weak wrappers is only resolved to the standard
function if there's a call to this standard function in other parts of
Qt5Webengine, because only then is there a non-weak symbol that takes
precedence over the weak one. If there's no such non-weak symbol the call
in the weak wrapper resolves to the weak wrapper itself creating an infinite
call loop that overflows the stack and causes a crash. Some of the
allocation functions are variants of C++ new and delete and it probably
depends on the compiler whether these variants are used in other parts of
Qt5Webengine.
Remove the weak wrappers (make them Linux specific). This isn't binary
compatible but we are already breaking that with the changes to the symbol
versions.
[1] 5c2cbfccf9
[2] 2ed5054e3a
[3] 009f5ebb4b
Bump all ports that depend on Qt5.
PR: 234070
Exp-run by: antoine
Approved by: kde (adridg)
defined via Mk/bsd.default-versions.mk which has moved from GCC 7.4 t
GCC 8.2 under most circumstances.
This includes ports
- with USE_GCC=yes or USE_GCC=any,
- with USES=fortran,
- using Mk/bsd.octave.mk which in turn features USES=fortran, and
- with USES=compiler specifying openmp, nestedfct, c11, c++0x, c++11-lang,
c++11-lib, c++14-lang, c++17-lang, or gcc-c++11-lib
plus, as a double check, everything INDEX-11 showed depending on lang/gcc7.
PR: 231590
- There was no obvious reason to split these ports, and it makes
porting simpler; the set of ports using either mostly coincided.
Exp-run by: antoine
PR: 223687
PR: 232751
From now on, ports that depend on Qt4 will have to set
USES= qt:4
USE_QT= foo bar
ports depending on Qt5 will use
USES= qt:5
USE_QT= foo bar
PR: 229225
Exp-run by: antoine
Reviewed by: mat
Approved by: portmgr (antoine)
Differential Revision: →https://reviews.freebsd.org/D15540
The work was done by tcberner and myself, with thanks to antoine for the
exp-run.
Not a lot to report compared to other Qt5 updates:
* net/qt5-network is still broken with LibreSSL. I said this in a commit
message ages ago but it bears repeating: upstream is open to adding support
for LibreSSL, but someone needs to step up to maintain it upstream, otherwise
things will continue to be broken all the time.
* www/qt5-webengine is a huge monster that is terrible to update, just like
www/chromium itself is. We (kde@) have decided to keep using the 5.9 series
for the time being, as it should be compatible with the rest of Qt anyway. It
was updated to 5.9.5, the latest 5.9 release at the time of writing.
PR: 228213
For the qt5-* ports bsd.qt.mk sets EXTRACT_AFTER_ARGS, and
thereby does not get the normal default value of
--no-same-owner --no-same-permissions
passed when extracting. This lead to for example header files
being installed (i.e. copied), with permissions group write
permissions.
Manually append that to the bsd.qt.mk shenanigans (also do the
same in www/qt5-webchannel, which opts out of the bsd.qt.mk value)
PR: 227027
Reported by: grarpamp@gmail.com
Patch by Stephen Hurd, seems to be ignored upstream. The new patch describes
what it does and why it is needed.
PR: 208570
Submitted by: Stephen Hurd
Reported by: Stephen Hurd
Approved by: tcberner (mentor)
Differential Revision: https://reviews.freebsd.org/D13992
The machinery in bsd.qt.mk's qt-post-install target does not seem to account
for the case of a module no longer defining QT_DEFINES: the lines in
qconfig-modules.h including said module's qconfig-<module>.h will remain.
We did that to qt5-multimedia in r458338, and it results in build errors if
qt5-multimedia had been previously installed. Set QT_DEFINES again to a dummy
value until we figure out a proper solution.
PR: 225100
qtmultimedia now uses a configure.json file to describe configuration options
and checks that qmake should perform. On the one hand it means
extrapatch-no-gstreamer no longer applies (and neither does the TBR_DEPENDS
hack in the Makefile), on the other the configuration process has been
streamlined: we only need to pass the right options via QMAKE_CONFIGURE_ARGS to
enable and disable options.
While here, stop setting QT_DEFINES altogether in the Makefile, as none of them
are really necessary at all:
- XVIDEO is a Qt4 thing;
- ALSA, OPENAL and PULSEAUDIO are handled by qmake's configure.json
infrastructure, which sets a QT_NO_<OPTION> macro in qtmultimedia-config.h
when they are not enabled.
- There is no QT_{NO_}GSTREAMER upstream, so we're basically defining some
macros that no code is going to use.
Reviewed by: tcberner (earler version without the QT_DEFINES changes)
This took quite a lot of time because Qt's own build system underwent
several changes in 5.8.0 that took a while to adapt to.
And, of course, qt5-webengine is a behemoth that we need to patch like crazy
due to its bundling of Chromium. In fact, most of the Chromium patches in
qt5-webengine have been imported with no changes from www/chromium@433510
("www/chromium: update to 56.0.2924.87").
New port: accessibility/qt5-speech
Bigger changes to Qt5 ports we had to make:
- Qt now allows using a configure.json file to define configuration options
and specify configuration checks that can be done when qmake is invoked.
However, configure.json checks done in a subdirectory only propagates to
subdirectories, and checks elsewhere will fail if all .pro files are being
parsed at once (i.e. qmake -recursive), so several ports had to switch to
USES=qmake:norecursive along with manual additional qmake invocations in
subdirectories in order to work. It's been mentioned in a few places such
as Qt's bug tracker that qmake's recursive mode is pretty much deprecated,
so we might switch to non-recursive mode by default in the future.
- Uses/qmake.mk: Introduce QMAKE_CONFIGURE_ARGS. qmake now accepts
arbitrary options such as '-foo' and '-no-bar' at the end of the
command-line. They can be specified in QMAKE_CONFIGURE_ARGS.
- graphics/qt5-wayland: The port can only be built if graphics/mesa-libs is
built with the WAYLAND option, so a corresponding option (off by default)
was added to the port.
- misc/qt5-doc: Switch to a pre-built documentation tarball. The existing
port was not working with Qt 5.9. Instead of trying to fix it, switch to
what Gentoo does and fetch a tarball that already contains all
documentation so that we do not have to build anything at all. The
tarball's name and location in download.qt.io look a bit weird, but it
seems to work fine.
- www/qt5-webengine: Use binutils from ports, Chromium's GN build system
generates a build.ninja that uses ar(1) with the @file syntax that is not
supported by BSD ar, so we need to use GNU ar from binutils.
- x11-toolkits/qt5-declarative-render2d: This port was merged into the main
Qt Declarative repository upstream, and into x11-toolkits/qt5-quick in the
ports tree.
Changes to other ports we had to make:
- biology/ugene: Drop a '#define point "."' that is not present in more
recent versions of the port. Defining a macro with such a common name
causes build issues with Qt 5.9, which uses |point| as an argument name in
methods.
- cad/qelectrotech: Fix plist with Qt 5.9. Directories are no longer
installed with `cp -f -R', but rather `qmake install qinstall', which does
not install
%%DATADIR%%/elements/10_electric/20_manufacturers_articles/bosch_rexroth/.directory
That's a local file that should not even have been part of the tarball
anyway.
- chinese/gcin-qt5: Add additional private Qt directories (which should not
be used in the first place) to get the port to build with Qt 5.9.
- devel/qtcreator: Fix plist with Qt 5.9. Something changed in qdoc and some
test classes no longer generate documentation files.
- security/keepassx-devel: Import a patch sent upstream almost a year ago to
fix the build with Qt 5.9.
Thanks to antoine for the exp-run, and tcberner and Laurent Cimon
<laurent@nuxi.ca> for landing changes in our qt-5.9 branch.
PR: 224849
default. This is the first update required to fix audio is some
dependencies like comms/wsjtx. See also PR 208570.
Reported by: adrian
Approved by: tcberner, rakuco
Differential Revision: https://reviews.freebsd.org/D12480
