15:35 Jason E. Hale (jhale) 

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:	antoine

    2a5c778

21:04 Adriaan de Groot (adridg) 

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 Udvari

    00c46f9

08:47 Tobias C. Berner (tcberner) 

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/Qt5PatchCollection

    6b3bece

14:04 Dima Panov (fluffy) 

graphics/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 GmbH

    183d079

16:55 Loïc Bartoletti (lbartoletti) 

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.

    be86c4f

08:09 Mathieu Arnold (mat) 

One more small cleanup, forgotten yesterday.
Reported by:	lwhsu

    cf118cc

14:31 Mathieu Arnold (mat) 

Remove # $FreeBSD$ from Makefiles.

    305f148

12:35 tcberner 

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:	antoine

 

20:19 tcberner 

misc/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/D22991

 

11:56 adridg 

Bump 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:		227027

 

04:13 tcberner 

Qt5 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:		238782

 

20:46 gerald 

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:		238330

 

20:02 tcberner 

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:	pkubaj

 

17:43 tcberner 

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:	antoine

 

11:13 tijl 

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)

 

14:49 tcberner 

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:	antoine

 

01:35 gerald 

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:		231590

 

08:01 tcberner 

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>

 

11:12 tcberner 

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:	antoine

 

22:18 gerald 

Bump 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:		222542

 

17:39 tcberner 

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/D15540

 

12:27 rakuco 

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:		228213

 

19:03 tcberner 

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.com

 

21:30 rakuco 

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:		224849

 

09:13 linimon 

Mark 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 timeout

 

20:55 gerald 

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:		219275

 

17:47 tcberner 

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/D11744

 

20:03 tcberner 

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:	amdmi3

 

17:51 tcberner 

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)

 

15:23 gerald 

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:		216707

 

19:48 tcberner 

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/D9213