Add tab

I'll update this one for 3.0 released via KDE infrastructure.

In D14506#304487, @rakuco wrote:

[ 90%] Linking CXX executable ../bin/cmake
/usr/bin/ld: libCMakeLib.a(cmQtAutoGeneratorMocUic.cxx.o): undefined reference to symbol 'pthread_create@@GLIBC_2.2.5'
//usr/lib64/libpthread.so.0: error adding symbols: DSO missing from command line

Please re-do for 3.3.3, once step0 has landed.

Built for me in poudriere, although this patch is so huge it is very difficult to apply; arc patch doesn't like it either. So accepting, although the question to portmgr still stands.

Other solution committed.

The other review's patches were committed which resolve the issue. Commandeering in order to close.

@novel You're right, I should have added you to the review. I don't often do fix-it-so-it-builds changes to other people's ports, I got caught up in the whole clang6-fixing party. As for the PORTREVISION bump, well .. PHB says "any change that may change the contents of a package", and us KDE folks interpret that fairly broadly; it's possible this code results in different output executable.

Already committed, but didn't close.

Fix patch so it actually applies.

Forgot portrevision bump.

"while here, make makepatch to nicely name the pre-existing patch file"

This has built successfully in a QEMU aarch64 12-CURRENT poudriere and also on a Pine64+; now building on amd64 to check for regressions. I'm a little unclear on the needed PORTREVISION bumps -- only Qt4 Core is directly affected, and Qt4 DBUS didn't compile previously .. I don't know about an effect on dependent ports that did previously compile.

D13935 has a patch (lifted from Fedora, it's the same one @rakuco mentioned earlier) that implements atomic ops, rather than applying a cast-hammer like this one does. See also PR 223988

Built and installed naively it refuses to run until I set LANG to a UTF-8 locale (e.g. en_US.UTF-8), but that's more a Python 3.6 / Click problem than khal.

OK by me, but I'd still need an OK from @tcberner or @rakuco to commit it (or they could do it themselves).

Switch to DISTVERSION

Come to think of it, if this previously compiled, the comparison
would be wrong and it's a bug which can mis-report an error.
While here, drop the BROKEN lines, since this fixes exactly that error.

This was fixed with r457650

No need to bump PORTREVISION, cosmetic change in Makefile only.

No need for PORTREVISION bump, this is fixing build on i386
that didn't build before.

C++11 stuff has already been committed, so just leave the imported target fix

Some questions, but nothing serious. You can mark comments as "done" when they're done (e.g. the question about the WWW line) so as to indicate that things are progressing.

Isn't this largely obsoleted by flavors now? Or have flavors not reached the PyQt bits, and this stuff needs to be reworked to fit?

I like it, since it pulls all of the boolean handling into something that looks consistent in the Makefile. It will need some PHB work, later, to give it some nice docs.

While it is true that the license on PyQt is dual GPLv3 and Riverbank's license (RCL), the artifacts produced by the ports build system do not meet the requirements of the RCL (since they're tied to a single application, preferably statically linked). So even if you have an RCL, you can't use this -- so just stick to GPLv3.

LGTM except for one breaking issue: the file kdegames4/Makefile.common was deleted, instead of moved to kdegames-kde4/, which looks like it breaks all of the individual game ports.

Please double-check upstream's comment about setup.cfg.

Hostile takeover to get rid of it.

While here, also add c++11-lang as requirement.

LGTM, have it in use built from the kde5-import branch.

Update to 3.10.1

Will do cmake update plus all these related fixes in one go in PR 223872

OPTIONS_SUB -> yes (the value is ignored, but "yes" is traditional)