Qt5: Update to 5.15.19 This is the final release of Qt5. If your port still uses Qt5 and could possibly use Qt6 instead, now would be a good time to make the switch. PySide2: Update to 5.15.19 Announcement: https://lists.qt-project.org/pipermail/announce/2026-May/000626.html Release notes: https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/5.15.19/release-note.md1817deda1e
Port details
devel/qt5-qmake5.15.19p96
Qt Makefile generator (KDE patched)
- Maintainer
- kde@FreeBSD.org
- Packages
- qt5-qmake 5.15.19p96
- Upstream
- Higher version available: 6.12.0
- CPE
qt:qt- WWW
- https://www.qt.io/
- Links
- cgit · VuXML
Unaddressed (0) · The CVE record lists this version as affected, no VuXML entry names the CVE
None. There is no CVE without a VuXML entry for this version.
VuXML only (0) · listed, port not fixed yet
None.
pkg audit reports nothing for this version.Fixed (0)
No VuXML entries for this package.
Commits (48)
Qt5: Update to 5.15.18 This is the penultimate release of Qt5. While Qt5 is EOL, due to the LGPL releases being a year behind the commercial releases, there will still be one more patch release in May 2026. PySide2: Update to 5.15.18 Announcement: https://lists.qt-project.org/pipermail/announce/2025-October/000592.html Release notes: https://code.qt.io/cgit/qt/qtreleasenotes.git/tree/qt/5.15.18/release-note.md MFH: 2025Q4bc01cbb5a1
Qt5: Update to 5.15.17 (getting down to the end) Upstream standard support for Qt5 is officially over. [1] In short, that means get your ports off of Qt5 ASAP, especially end-user applications. FreeBSD deprecation of Qt5 is coming soon! It will likely be a year of lead time, but please help in the meantime and remove qt5 flavors and child ports whenever possible. www/qt5-webengine has been updated to 5.15.19 with security patches up to Chromium 135.0.7049.95. It's unclear at this point if further security patches will be publically available. The Qt5 WebEngine component, however, is and forever will be based on Chromium 87.0.4280.144, which is over 4 years old. Props to upstream for their backports over all these years and making them publically available (probably more to do with licensing constraints than anything, but hey). We otherwise depend on KDE as our direct upstream to roll our distfiles, which we have been hosting locally for over 3 years. Since Qt upstream drops the LGPL releases of Qt 5.15.x a year later, there's no guarantee KDE will rebase their patchset over the next year for the remaining two .18 and .19 releases. This might be the last update for Qt5 on FreeBSD. [1] https://www.qt.io/blog/qt-5.15-extended-support-for-subscription-license-holders9d76916067
Qt5: Update to 5.15.16 Update devel/pyside2* and devel/shiboken2 to 5.15.16 Update www/qt5-webengine to include the latest security fixes in the chromium submodule [1] Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.16/release-note.md MFH: 2024Q4 Security: 16e472d5-a8aa-11ef-b680-4ccc6adda413 [1]501ccfe6dd
Qt5: Update to 5.15.15 Update devel/pyside2* and devel/shiboken2 to 5.15.15 Update www/qt5-webengine to include the latest security fixes in the chromium submodule Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.15/release-note.md MFH: 2024Q3 Security: 66907dab-6bb2-11ef-b813-4ccc6adda4139e1e9e17c5
Qt5: Update to 5.15.14 Update devel/pyside2* and devel/shiboken to 5.15.14 Update devel/qt5-script* and www/qt5-webengine to 5.15.17 Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.14/release-note.md72a628f271
Qt5: Update to 5.15.13 Update devel/pyside2* and devel/shiboken to 5.15.13 Update www/qt5-webengine to latest commit. Python 3.x support has been integrated upstream, so local patches have been removed. Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.13/release-note.md9793a1e61a
Qt5: Update to 5.15.12 Update devel/pyside2* and devel/shiboken2 to 5.15.12 Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.12/release-note.mddc05989834
Qt5: Update to 5.15.11 Update devel/pyside2* and devel/shiboken2 to 5.15.11 Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.11/release-note.md7f496af089
Qt5: Update to 5.15.10 Update devel/qt5-script* and www/qt5-webengine to 5.15.15-lts Update devel/pyside2* and devel/shiboken2 to 5.15.10 Release note: https://code.qt.io/cgit/qt/qtreleasenotes.git/about/qt/5.15.10/release-note.md PR: 273934 Exp-run by: antoine2a5c778173
devel/qt5-qmake: do not try to install qtconfig header Qt-dist ports that are a module need to install their header to qt-config.h. This accidentally happens to qt5-qmake as well. This is only visible when *installing* qt5-qmake on an otherwise fresh system with no other Qt packages. If you install any other Qt packages, then the qt-config header is there for the post-install script to work on (though it doesn't do anything for qt5-qmake). In a clean system, the script fails. PR: 269232 Reported by: Zsolt Udvari00c46f9fe7
Qt: Update Qt 5 to 5.15.8 - update distfiles to be rebased on the Qt 5.15.8 branch PR: 268773 Exp-run by: antoine1fe9749d83
Qt5: Update Qt 5 to 5.15.7 * rebase the KDE patched Qt5 ontop of the 5.15.7 branch * update qt5-script to 5.15.11 Exp-run by: antoine PR: 2685333aeb8b79ba
qt5: Update Qt to 5.15.5 (KDE patched) - 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/D35619787e501e3d
Qt: Switch Qt5 to use KDE's Qt patch collection
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/Qt5PatchCollection6b3bece75agraphics/qt5-q3d: convert AVX2 detection hack to OPTIONS (+) Force qt5-qmake to pass CXXFLAGS to cpu features test. Define AVX OPTION only amd64/i386 arches due to cpu used. Off by default to keep out-of-box behavior and allow to build qt5-q3d and its consumes on any old processors. Necromages, go forward! :) PR: 255753 With hat: desktop Sponsored by: Netzkommune GmbH183d079fd6
misc/qtchooser: remove
QtChooser allows you to select your version of Qt among those installed.
However, this tool is no longer supported upstream and will not be
available for Qt6.
By default, our Qt installations are done in
${LOCALBASE}/lib/qt${QT_VERSION} as recommended.
We have added symbolic linking for the main binaries to
${LOCALBASE}/bin with the suffix -qt5.be86c4fe23One more small cleanup, forgotten yesterday. Reported by: lwhsucf118ccf87
Remove # $FreeBSD$ from Makefiles.305f148f48
Update Qt5 to 5.15 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: antoine5f34284e7c
Update Qt5 to 5.14.2
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: antoinea25eafc3bcmisc/qtchooser: do not create unnecessary wrappers
misc/qtchooser provides a wrapper binary bin/qtchooser, that when called with
name foo, will lauch the corresponding binary from lib/qt${current_qt_version}/bin/foo.
Previously qtchooser would install a list of 30-ish symlinks to itself automatically.
Now we switch this around.
qt-dist ports that define QT_BINARIES will now have a @postexec and @postunexec
entry added to their plist to run the shell-script update-qtchooser-wrapper
(installed by qtchooser).
update-qtchooser-wrapper removes all symlinks to bin/qtcreator that have no
corresponding binary in lib/qt*/bin, and readds links that are missing.
Exp-run by: antoine
PR: 242905
PR: 243443
Reported by: grarpamp@gmail.com
Reviewed by: adridg
Differential Revision: https://reviews.freebsd.org/D2299193eea426e8Bump PORTREVISION to force rebuild of devel/qt5-qmake This should have happened with r521876, which changed some Qt5 infrastructure to add --no-same-owner --no-same-permissions to extract args. This possibly needs to happen in other Qt ports as well (or wait for 5.14 to land). PR: 2270275c590f3f7f
Update Qt5 to 5.13.2
Announcement:
https://www.qt.io/blog/qt-5.13.2-released
Thanks to kai@ for updating webengine.
PR: 241649
Exp-run by: antoinea008399a74Qt5 update to 5.13.0 For new features, check: https://wiki.qt.io/New_Features_in_Qt_5.13 Thanks to adridg who helped to fix a lot of packages. Exp-run by: antoine PR: 238782c45de9579f
Bump PORTREVISION for ports depending on the canonical version of GCC 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: 238330ea8c8ec7da
qt5: fix build on gcc architectures
- the sed call was only replacing one of the %%LOCALBASE%% by ${LOCALBASE},
due to the missing 'g' flag to the sed call.
- with this change the gcc architectures should be able to build Qt5 again.
PR: 237745
Submitted by: Mark Millard <marklmi26-fbsd@yahoo.com>, jwb
Reported by: pkubajee49e34252Update Qt5 to 5.12.2 - Thanks to kai for updating webengine. Exp-run by: antoine PR: 2368951c35361b47
Update Qt5 to 5.12.1 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: antoine031fc9bfb6
Fix Qt5 symbol version scripts to put the catch-all clause first. When 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] https://github.com/qt/qtwebengine/commit/5c2cbfccf9aafb547b0b30914c4056abd25942a4 [2] https://github.com/qt/qtwebengine/commit/2ed5054e3a800fa97c2c9e920ba1e6ea4b6ef2a5 [3] https://github.com/qt/qtwebengine/commit/009f5ebb4bd6e50188671e0815a5dae6afe39db5 Bump all ports that depend on Qt5. PR: 234070 Exp-run by: antoine Approved by: kde (adridg)1bf487d3e7
Update Qt5 to 5.12.0 http://blog.qt.io/blog/2018/12/06/qt-5-12-lts-released/ - This breaks support for libressl again. Patches are welcome. PR: 233705 Exp-run by: antoineea792330aa
Bump PORTREVISION for ports depending on the canonical version of GCC 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: 231590a9f015d155
qt5: Fix build on GCC based architectures. PR: 231584 PR: 231677 PR: 231685 PR: 231830 PR: 231955 PR: 231905 PR: 231892 PR: 231684 PR: 231958 PR: 231960 PR: 231818 PR: 231542 PR: 231860 PR: 231681 PR: 231963 PR: 231891 PR: 231966 PR: 231904 PR: 231676 PR: 231819 PR: 231956 PR: 231680 PR: 231957 PR: 231903 PR: 231901 PR: 231667 PR: 231861 Submitted by: Piotr Kubaj <pkubaj@anongoth.pl>d19d17bd64
Update Qt5 to 5.11.2 PR: 231560 Exp-run by: antoineb25105fb9b
Update Qt5 to 5.11.1
Big thanks to
* brnrd for the libressl patches in net/qt5-network
* jhale for fixing the bulk load of ports
PR: 230884
Exp-run by: antoine60768bf27dBump PORTREVISION for ports depending on the canonical version of GCC in the ports tree (via Mk/bsd.default-versions.mk and lang/gcc) which has now moved from GCC 6 to GCC 7 by default. This includes ports - featuring USE_GCC=yes or USE_GCC=any, - featuring USES=fortran, - using Mk/bsd.octave.mk which in turn features USES=fortran, and those - with USES=compiler specifying one of openmp, nestedfct, c11, c++0x, c++11-lib, c++11-lang, c++14-lang, c++17-lang, or gcc-c++11-lib. PR: 22254209f9633cb6
Replace bsd.qt.mk by Uses/qt.mk and Uses/qt-dist.mk 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/D15540b1a1d38bf9
Update the Qt5 ports to 5.10.1. 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: 22821370141f1a3a
Fix permissions in installed Qt5 header files
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.comdc579c4cc2Update Qt5 to 5.9.4. Announcement: https://blog.qt.io/blog/2018/01/23/qt-5-9-4-released/ This is a minor update and a lot easier to land than the previous 5.7.1 -> 5.9.3 commit. Thanks to antoine for the exp-run. PR: 225436b09145bf97
Update Qt5 ports to 5.9.3.
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: 224849f6ceca6350Mark broken on powerpc64. Apparently this was being worked on upstream (see PRs 204923, 201529, 217762) but there has been no action for several months. PR: 219112 (partial) Approved by: portmgr (tier-2 blanket), maintainer timeoutb709920cee
Bump PORTREVISION for ports depending on the canonical version of GCC (via Mk/bsd.default-versions.mk and lang/gcc) which has moved from GCC 5.4 to GCC 6.4 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, c++11-lib, c++11-lang, c++14-lang, c++0x, c11, or gcc-c++11-lib. PR: 219275e59c88cece
New port: graphics/qt5-wayland Marketing blurb [1]: QtWayland is a Qt 5 module that wraps the functionality of Wayland. QtWayland is separated into a client and server side. The client side is the wayland platform plugin, and provides a way to run Qt applications as Wayland clients. The server side is the QtCompositor API, and allows users to write their own Wayland compositors. This is mostly needed at the moment to make upstream KDE-CI happy, therefore we don't wire it into the metaport devel/qt5. It requires a little change to devel/qt5-qmake, as we needed to modify the installed bsd.conf to know about wayland/egl. Created together with Adriaan de Groot <groot@kde.org>. Reviewed by: rakuco, groot_kde.org Differential Revision: https://reviews.freebsd.org/D11744d35014dbf6
Do not use gold linker for Qt5 ports. gold linker from binutils 2.28 may produce duplicate library symbols, which makes shared libraries created with it not usable with conventional ld linker. PR: 218187 Submitted by: amdmi3d926a26981
Silence the more restrictive stage-qa script, by shebangfixing. (The affected files are not really relevant for FreeBSD). Reported by: miwi Approved by: rakuco (mentor)8e10778a50
Bump PORTREVISIONs for ports depending on the canonical version of GCC and lang/gcc which have moved from GCC 4.9.4 to GCC 5.4 (at least under some circumstances such as versions of FreeBSD or platforms). This includes ports - with USE_GCC=yes or USE_GCC=any, - with USES=fortran, - using using Mk/bsd.octave.mk which in turn has USES=fortran, and - with USES=compiler specifying openmp, nestedfct, c++11-lib, c++14-lang, c++11-lang, c++0x, c11, or gcc-c++11-lib. PR: 21670704d6f52202
Update Qt5 to 5.7.1, and unify the Qt4 and Qt5 ports some more
* Update Qt5 to 5.7.1
* Move Qt4 binaries to lib/qt4/bin
* Move Qt5 libraries to lib/qt5/lib
By moving the libraries we should finally be able to get rid of the inplace
upgrade bug (see ports bugs 194088, 195105 and 198720): when Qt5's libraries
were lying in /usr/local/lib, which would often get added by pkgconfig to the
linker paths via dependencies, the already installed libraries were linked
against, instead of the ones that were being built. This forced us to make
sure, that -L${WRKSRC}/lib was always coming before -L/usr/local/lib in the
linker flags. With this change this should no longer be the case.
* Rename some ports to match the rest (foo-qtX -> qtX-foo)
* Depend on new port misc/qtchooser [see UPDATING & CHANGES]
There are several new Qt5 ports which all have been created by Marie Loise Nolden
<nolden@kde.org>. Thanks again.
PR: 216797
Exp-Run by: antoine
Reviewed by: rakuco, mat, groot_kde.org
Approved by: rakuco (mentor)
Differential Revision: https://reviews.freebsd.org/D9213f3c180c343