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-remoteobjects5.15.19p0
Qt5 Remote Objects module (KDE patched)
- Maintainer
- kde@FreeBSD.org
- Packages
- qt5-remoteobjects 5.15.19p0
- 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 (30)
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
Qt 5 distribution ports: Add USE_LDCONFIG where appropriate Pull Request: https://github.com/freebsd/freebsd-ports/pull/35858972f6dd4
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-remoteobjects: unbreak after 020693c166d1 Project MESSAGE: perl -w /usr/local/lib/qt5/bin/syncqt.pl -module QtRepParser -version 5.15.8 -outdir /wrkdirs/usr/ports/devel/qt5-remoteobjects/work/kde-qtremoteobjects-5.15.8p0 -builddir /wrkdirs/usr/ports/devel/qt5-remoteobjects/work/kde-qtremoteobjects-5.15.8p0 /wrkdirs/usr/ports/devel/qt5-remoteobjects/work/kde-qtremoteobjects-5.15.8p0 sh: perl: not found PR: 266007 Reported by: antoine (via exp-run)5d00385405
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
Mk/Uses: always use colon for build/run suffix 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/D36349ddae4e92d8
devel/qt5-remoteobjects: Correct COMMENT4474313770
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/mesa-libs: Bump reverse deps for libglvnd 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/D30824da3162c7c9
One more small cleanup, forgotten yesterday. Reported by: lwhsucf118ccf87
Remove # $FreeBSD$ from Makefiles.305f148f48
Only define USE_LDCONFIG in devel/qt5-core 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/D2722493b90c42e3
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/D2299193eea426e8Update 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: antoinea008399a74Bump 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
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
New port: devel/qt5-remoteobjects Qt Remote Objects (QtRO) is an inter-process communication (IPC) module developed for Qt. The idea is to extend Qt's existing functionalities to enable an easy exchange of information between processes or computers. [1] https://doc.qt.io/qt-5/qtremoteobjects-index.html8949b13360