attica-qt5: add a Qt5-based version

[barracuda156]

To be clear, Qt4-based version is required, so we do not need to replace it, but rather add a subport.

[RJVB (René Bertin)]

kf5-attica would be the more appropriate name IMHO, as this is KDE software and part of their frameworks.

What's your reason for requesting this port? I'm only aware of it being used in 2 other frameworks plus by the Plasma5 desktop component:

> port info --name --long_description --depends_build --depends_lib `port -q dependents kf5-attica`
name: kf5-knewstuff
long_description: The KNewStuff library implements collaborative data sharing for applications. It uses kf5-attica to support the Open Collaboration Services specification. \n(kf5-knewstuff is a tier3 framework.)
depends_build: pkgconfig, cmake, kde-extra-cmake-modules, python27, gettext-dev
depends_lib: qt5-kde, kf5-attica, kf5-karchive, kf5-kcompletion, kf5-kconfig, kf5-kcoreaddons, kf5-ki18n, kf5-kiconthemes, kf5-kio, kf5-kitemviews, kf5-kservice, kf5-ktextwidgets, kf5-kwidgetsaddons, kf5-kxmlgui, gettext
--
name: kf5-kxmlgui
long_description: KXMLGUI provides a framework for managing menu and toolbar actions in an abstract way. The actions are configured through a XML description and hooks in the application code. The framework supports merging of multiple description for example for integrating actions from plugins. \n(kf5-kxmlgui is a tier3 framework.)
depends_build: pkgconfig, cmake, kde-extra-cmake-modules, python27, gettext-dev
depends_lib: qt5-kde, kf5-attica, kf5-kconfig, kf5-kconfigwidgets, kf5-kcoreaddons, kf5-kglobalaccel, kf5-ki18n, kf5-kiconthemes, kf5-kitemviews, kf5-ktextwidgets, kf5-kwidgetsaddons, kf5-kwindowsystem, gettext
--
name: kf5-plasma-desktop
long_description: KDE desktop components, providing notably the KDE control modules allowing to configure various settings like fonts, colour palettes, preferred theme etc.
depends_build: pkgconfig, cmake, kde-extra-cmake-modules, python27
depends_lib: qt5-kde, kf5-attica, kf5-baloo, kf5-kactivities, kf5-kauth, kf5-kcmutils, kf5-kconfig, kf5-kdbusaddons, kf5-kdeclarative, kf5-kded, kf5-kdelibs4support, kf5-kemoticons, kf5-kglobalaccel, kf5-kitemmodels, kf5-knewstuff, kf5-knotifications, kf5-knotifyconfig, kf5-ki18n, kf5-kpeople, kf5-krunner, kf5-kwallet, kf5-kwidgetsaddons, kf5-kwindowsystem, kf5-kxmlgui, kf5-plasma-framework, gettext, phonon-qt5, freetype, fontconfig, iso-codes

Of the frameworks only kf5-kxmlgui is of real interest but since both are Tier3 frameworks you end up having to implement a large part of the other frameworks.

Diving into creating KF5 ports with retro-computing spectacles on is going to be a nightmare I'm afraid. Even I simply stopped upgrading the vast majority of my KF5 ports because of their Qt5 requirements. KDE use "family versioning", and my ports use that by having a central set of version variables set through the KF5 PortGroup (and which several override, evidently). Those central versions could be os.major dependent, but individual ports will need to use the version-selective platform functionality to define the appropriate patches.

[barracuda156]

Replying to RJVB:

kf5-attica would be the more appropriate name IMHO, as this is KDE software and part of their frameworks.

What's your reason for requesting this port?

tomahawk player needs it: ​https://github.com/tomahawk-player/tomahawk And since Qt4 is broken on arm64, I cannot use Qt4 build there (though I will need to use it on older systems).

[RJVB (René Bertin)]

Bummer that they made it a required dependency (I have no idea what they need an "open collaboration services API" for).

It's not a difficult port to implement: ​https://github.com/RJVB/macstrop/blob/bf9aa65160e3dfef4d83133b657a4c1ef7659555/kf5/KF5-Frameworks/Portfile#L470

There's a bunch of hidden code there of course, defining at least the following for my current version:

version 5.60.0
master_sites http://download.kde.org/Attic/frameworks/5.60
distname attica
use_xz yes

There's only a patch to prevent headerfile/directory aliasing on case-insensitive filesystems.

Qt4 being broken on arm64 may not be unfixable: Apple aren't the first to use that architecture in "real" computers and DebUntu have been providing Qt4 packages for it: ​https://launchpad.net/ubuntu/+source/qt4-x11/4:4.8.7+dfsg-7ubuntu1 . Maybe you'll find your fix in their patches.

[barracuda156]

I could try asking the upstream if attica can be moved to optional deps. Fixing Qt4 must be doable, of course, but benefit is questionable, to be honest, considering required efforts. It will make it easier for me to test some Qt4-based ports, but perhaps there is not much software which cannot be built with Qt5, and there is no reason to prefer Qt4 when Qt5 is available.

[RJVB (René Bertin)]

You could already have a look at the code to see how intricately woven Attica classes are throughout.

Yes, there seems to be little benefit to using Qt4 when Qt5 alternatives are available, but KF5 never made it into the tree and the KDE4 ports mostly (still) work just fine so there's that. (I'm still using KDE4's PIM myself, for instance.) I have no idea how much effort is required to get Qt4 to build on Apple arm64. That will depend on how well "generic" arm64 code builds on Apple's version, and on how much the Apple-specific APIs Qt use have changed. Does Qt4 still build on the x86_64 Mac OS versions that also support arm64?

BTW, aren't those Apple silicon slices (seems an appropriate term for their laptops ) so powerful that you won't even notice if they're running Linux in a VM? ;)

Re: Tomahawk: I saw it also requires QtWebkit (kudos for not chosing the QtWebengine resource hog). As you may know there's a rebooted version of it that's more modern than the community version available through Qt, but last time I checked the Qt5 port maintainer had still not based the QtWebkit port on it. I do have a separate port for it, which should provide pretty much the latest version of the code from around when the developer gave up (collateral damage from political sanctions agains Russia).

[RJVB (René Bertin)]

Re: Qt4 : I think it must be broken across the board right now as it still claims to depend on port:openssl. While it has been patched to work with OpenSSL 1.1 it does not (AFAIK) work with OpenSSL 3.

[barracuda156]

Replying to RJVB:

You could already have a look at the code to see how intricately woven Attica classes are throughout.

Yes, there seems to be little benefit to using Qt4 when Qt5 alternatives are available, but KF5 never made it into the tree and the KDE4 ports mostly (still) work just fine so there's that. (I'm still using KDE4's PIM myself, for instance.)

KDE4 is totally broken, AFAIK, due to a broken soprano, which is required for nearly anything. ​https://trac.macports.org/ticket/68452

[barracuda156]

Replying to RJVB:

Re: Qt4 : I think it must be broken across the board right now as it still claims to depend on port:openssl. While it has been patched to work with OpenSSL 1.1 it does not (AFAIK) work with OpenSSL 3.

Well, Qt4 itself certainly works, however OpenSSL in may have issues, judging from ​https://github.com/smplayer-dev/smtube/issues/28

However, at the same time at least some Qt4-based ports, I think, are able to use the web.

But you bring up an interesting point. Maybe we could fix OpenSSL properly for it, and some ports get fixed along.

[RJVB (René Bertin)]

I'm not certain if all Qt4 applications use the QSsl functions, and as long as Qt4 *links* against OpenSSL 3 those applications will be able to use https etc.

Fixing the port should be as easy as using the openssl PG, setting the proper branch. Unset the openssl.configure feature and add the proper magic in OPENSSL_LIBS via configure.env . I just made those changes myself but haven't yet done a full test of them as I didn't feel like rebuilding the entire port.

There's a securesocket client example in the Qt4 demos/examples that can serve as a test app. If it connects all is fine, if it doesn't you can start hunting down the reason because it won't tell you ;)

[RJVB (René Bertin)]

Replying to RJVB:

I'm not certain if all Qt4 applications use the QSsl functions, and as long as Qt4 *links* against OpenSSL 3 those applications will be able to use https etc.

I meant of course that they can use Qt4 at all.

I just forced Qt4Network to build against the current OpenSSL 3 port. It builds and links OK, but as I expected the securesocketclient example application fails to connect with any server, without any error message. That usually means that the QSsl classes couldn't set up OpenSSL as they deem fit.

Fun fact: connecting to imap.gmail.com:993 using that example app is done with a lesser cipher on my Mac than on my Linux rig (both with OpenSSL 1.1.1w). I'm using a different OpenSSL 1.1 support patch for Qt4 on Linux though; maybe that's why. (Not really a problem for me; I basically only use encrypted network connections through Qt4 in KMail, which I currently usually run on Linux only ... and email is an inherently insecure medium anyway.) EDIT: nope, I had made another change for some reason, allowing QSsl::SecureProtocols and QSsl::TlsV1SslV3 via TLSv1 rather than SSLv23. That change had remained confined to my Qt4 sources and was never committed to my patchfile so I have no idea what the purpose was.

[RJVB (René Bertin)]

Replying to RJVB:

add the proper magic in OPENSSL_LIBS via configure.env .

NB: using just -L[openssl::libdir] -lssl -lcrypto isn't reliable because clang (some versions?) will reorganise the arguments and you'll still end up linking the libraries in $prefix/lib (i.e. symlinks to the OpenSSL3 libs). Use [openssl::libdir]/libssl.dylib [openssl::libdir]/libcrypto.dylib instead.