trojita with Qt4 does not see its plugins and cannot set IMAP

[barracuda156]

@RJVB I am sorry to bother with a second ticket in a row, but I suddenly realized that due to your knowledge of KDE you might be able to help here.

I made a ​port for trojita, but while it builds, Qt4 version does not find its plugins on launch, so I cannot setup IMAP, and it is therefore useless. I tried tweaking settings in a few ways, to no avail.

Could you see if it works for you? trojita looks much better than both GTK clients that we have, it would be great to have it working on older OS.

[RJVB (René Bertin)]

Would you mind first having a look at the port I once made, in the mail section of my MacStrop repo?

AFAIR it worked, but I lost interest in the application when I saw how limited it was. Sylpheed and Claws-mail always worked fine for me, and have the advantage I can run them remotely.

How are its plugins supposed to be installed, in the Qt plugins directory? Or via some other scheme that might be based on the XDG protocol? It sounds a bit like KF5 applications not finding various resources on Mac because Qt5's QStandardPaths puts them in "Mac-native" places that KF5 isn't aware of. Qt4 doesn't have QStandardPaths but Trojita can implement a Qt4 version of the class of course.

Is the app supposed to run on Mac?

[RJVB (René Bertin)]

I had a quick look at the the current sources. Requires Qt 5.15 so if that's not just for show it makes it impossible for me to even build the app. Checking the website I also saw that it apparently still supports only 1 email account...

[barracuda156]

Replying to RJVB:

I had a quick look at the the current sources. Requires Qt 5.15 so if that's not just for show it makes it impossible for me to even build the app. Checking the website I also saw that it apparently still supports only 1 email account...

0.6 builds with Qt4: ​https://github.com/macports/macports-ports/blob/master/mail/trojita/Portfile

Is the app supposed to run on Mac?

I think 0.7 with Qt5 does, though I had no necessity to use it for actual e-mail. But no errors in the interface when I tried it. With 0.6 no luck so far :(

[barracuda156]

Replying to RJVB:

BTW, just in case, we do not have any working e-mail app which uses Qt4, right?

[RJVB (René Bertin)]

There's Kontact, from kdepim4 .

[barracuda156]

Replying to RJVB:

There's Kontact, from kdepim4 .

That needs soprano, unfortunately, so will not build :( And broken across the board presently, whether for this reason or another: ​https://ports.macports.org/port/kdepim4/details

[RJVB (René Bertin)]

What's the problem with soprano? I only apply point upgrades that are of interest/importance to me (and have a hack to preserve old runtime libraries) so I haven't had to rebuild any of my KDE4 ports for ages.

There's this: ​https://git.claws-mail.org/?p=claws-qt.git

No updates since about 4 years but if it works it'll just work?

[barracuda156]

Replying to RJVB:

What's the problem with soprano?

It is broken and no one knows why: #68452

No updates since about 4 years but if it works it'll just work?

Interface is pre-historic :) Did not work for me initially too, though perhaps it can be tweaked to work. I had no time to dig into the setting too much.

[RJVB (René Bertin)]

Replying to RJVB:

What's the problem with soprano?

I did a quick test build on Linux and the only error I ran into was that one has to add -std=gnu++98 to the CXXFLAGS. (Tried that via compiler.cxx_standard but that didn't work; could be because the underlying implementation is too Mac-specific though.)

Note that Qt4 also has to be built with -std=gnu++98, unless you opt for the cxx11 variant (which I never tried).

[barracuda156]

Replying to RJVB:

Replying to RJVB:

What's the problem with soprano?

I did a quick test build on Linux and the only error I ran into was that one has to add -std=gnu++98 to the CXXFLAGS. (Tried that via compiler.cxx_standard but that didn't work; could be because the underlying implementation is too Mac-specific though.)

Note that Qt4 also has to be built with -std=gnu++98, unless you opt for the cxx11 variant (which I never tried).

As I understand from the ticket, on MacOS it is broken across the board or at least on numerous systems. Weird.

Qt4 does not build with C++11 variant for me, I think it needs Cocoa in that case, and Cocoa is broken ) (Numerous dependencies of Qt4 use C++11 and later, that works fine.)

[RJVB (René Bertin)]

Replying to barracuda156:

As I understand from the ticket, on MacOS it is broken across the board or at least on numerous systems. Weird.

I left some thoughts on the ticket you linked.

Qt4 does not build with C++11 variant for me, I think it needs Cocoa in that case, and Cocoa is broken )

Ah, yes, it's actually possible that I noticed that too (that Qt4's use of Cocoa is broken).

Well, best to use C++98 for code written in that dialect anyway!

[barracuda156]

Replying to RJVB:

There's Kontact, from kdepim4 .

Does Konqueror from KDE4 still work btw? There is no port for it for w/e reason, but if chances are it is functional, I can try making it.

[RJVB (René Bertin)]

There's really no point I think. Konqueror itself will work, but it uses the QtWebkit from Qt4, which is way too old to be used with modern websites.

[barracuda156]

Replying to RJVB:

There's really no point I think. Konqueror itself will work, but it uses the QtWebkit from Qt4, which is way too old to be used with modern websites.

I see. Browser remains one biggest pain on powerpc.

BTW, downgrading Raptor2 apparently worked, and I was able to build kdelibs4 without disabling anything. Can try building some KDE4 apps which were not accessible so far.

[barracuda156]

Replying to RJVB:

There's Kontact, from kdepim4 .

Okay, so I got everything compiling (all needed fix-ups amount to fixing C++ standard or compiler blacklist), however apps crash on launch with alike messages (example for Kontact):

Executable: kontact PID: 24610 Signal: Bus error (10)

What do I do wrong?

UPD. Not all apps crash, kaddressbook launched normally, for example, but then complained about akonadi not being operational.

[barracuda156]

dolphin and Konqueror launch fine, but display a single (first) file per directory :)

Web access in Konqueror does not work, as you expected. Some operations trigger a crash, but not other.

So far nothing looks properly usable. Though it looks like at least some ports can be updated to whatever upstream had for Qt4 the last, which could help (or not).

[RJVB (René Bertin)]

The problem is that it's been ages since I set up KDE4. You're of course welcome to scan through my personal KDE4 ports in the MacStrop repo to see if there are updates or potential fixes there. Kontact and the underlying akonadic structure are not really the most trivial one to set up either. You could try the "server/configure server" menu in akonadiconsole and make certain it points to mysqld-akonadi as the internal MySQL database server. You're using mariadb underneath, right? Other options should work too, including PostGreSQL but I never tried those.

You'll probably want to install the kde4-workspace port too, so you get the systemsettings executable which allows to tweak quite a number of things. It can't hurt either to install QtCurve, which at the time was more or less the de-facto style plugin to make things at least display properly.

Applications that crash with a SIGBUS on start can be really tricky to debug in my experience. Launching them in the debugger will hopefully help, or else letting dyld print out trace information to see if that helps pinpoint the sore spot (check man dyld).

[barracuda156]

Replying to RJVB:

Looking at the error, I wonder if it ever worked:

ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)
QSqlDatabase: QSQLITE3 driver not loaded
QSqlDatabase: available drivers: QSQLITE QMYSQL3 QMYSQL
Invalid database object during initial database connection
"[
0: 0   akonadiserver                       0x00007f0c _Z11akBacktracev + 72
1: 1   akonadiserver                       0x00008378 _ZL19defaultCrashHandleri + 100
2: 2   libSystem.B.dylib                   0x00ba6294 _sigtramp + 68
3: 3   libSystem.B.dylib                   0x00b290b8 szone_malloc + 292
4: 4   ???                                 0x653c3cf8 0x0 + 1698446584
]
"
ProcessControl: Application 'akonadiserver' returned with exit code 255 (Unknown error)

The source indeed uses these names incoherently: in some instances both are mentioned, in other only QSQLITE3, while Qt4 pulgin apparently uses QSQLITE.

[barracuda156]

It it probably still broken, but I have fixed at least a recognition of sqlite:

36-244% /opt/local/bin/akonadiserver-script.sh
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
36-244% QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
DATABASE ERROR:
Error code: -1
DB error:  ""
Error text: " Parameter count mismatch"
Query: "SELECT id, name FROM PartTypeTable WHERE ( ns = :0 AND name = :1 )"
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
DATABASE ERROR:
Error code: -1
DB error:  ""
Error text: " Parameter count mismatch"
Query: "INSERT INTO PartTypeTable (name, ns) VALUES (:0, :1)"
DATABASE ERROR:
Error code: -1
DB error:  ""
Error text: " Parameter count mismatch"
Query: "SELECT CollectionTable.id, CollectionTable.remoteId, CollectionTable.remoteRevision, CollectionTable.name, CollectionTable.parentId, CollectionTable.resourceId, CollectionTable.enabled, CollectionTable.syncPref, CollectionTable.displayPref, CollectionTable.indexPref, CollectionTable.referenced, CollectionTable.cachePolicyInherit, CollectionTable.cachePolicyCheckInterval, CollectionTable.cachePolicyCacheTimeout, CollectionTable.cachePolicySyncOnDemand, CollectionTable.cachePolicyLocalParts, CollectionTable.queryString, CollectionTable.queryAttributes, CollectionTable.queryCollections, CollectionTable.isVirtual FROM CollectionTable WHERE ( referenced = :0 )"
Failed to execute  collection reference cleanup query.
DATABASE ERROR:
Error code: -1
DB error:  "No query"
Error text: "No query Unable to fetch row"
Query: "SELECT id, remoteId, remoteRevision, name, parentId, resourceId, enabled, syncPref, displayPref, indexPref, referenced, cachePolicyInherit, cachePolicyCheckInterval, cachePolicyCacheTimeout, cachePolicySyncOnDemand, cachePolicyLocalParts, queryString, queryAttributes, queryCollections, isVirtual FROM CollectionTable"
DATABASE ERROR:
Error code: -1
DB error:  "No query"
Error text: "No query Unable to fetch row"
Query: "SELECT id, remoteId, remoteRevision, name, parentId, resourceId, enabled, syncPref, displayPref, indexPref, referenced, cachePolicyInherit, cachePolicyCheckInterval, cachePolicyCacheTimeout, cachePolicySyncOnDemand, cachePolicyLocalParts, queryString, queryAttributes, queryCollections, isVirtual FROM CollectionTable"
DATABASE ERROR:
Error code: -1
DB error:  "No query"
Error text: "No query Unable to fetch row"
Query: "SELECT id, name, isVirtual FROM ResourceTable"
search paths:  ("/opt/local/lib", "/opt/local/lib/qt4/plugins/", "/opt/local/lib/kde4/", "/opt/local/lib/kde4/plugins/", "/usr/lib/qt4/plugins/", "/opt/local/libexec/qt4/share/plugins", "/Users/svacchanda/Library/Preferences/KDE/lib/kde4/")

[barracuda156]

I guess we should upgrade all KDE4 ports to the latest versions to begin with, it may be a total waste of time to spend hours on fixes and rebuilds when possibly these issue were already addressed by upstream earlier.

[RJVB (René Bertin)]

I can confirm that KDEPIM works fine for me on Mac. I probably never tried it with the sqlite backed; I probably learned on Linux that it's the least advisable of the 3 before I started using Kontact on Mac too. (Which was after upgrading to 10.9 IIRC and discovering that Apple Mail had begun keeping local copies of everything.)

Upgrading the ports first is probably not a bad idea if you're going to be tinkering with them anyway, but be advised that a lot of those final releases will just consist of upgraded translations and other cosmetics.

[barracuda156]

Replying to RJVB:

I can confirm that KDEPIM works fine for me on Mac. I probably never tried it with the sqlite backed; I probably learned on Linux that it's the least advisable of the 3 before I started using Kontact on Mac too. (Which was after upgrading to 10.9 IIRC and discovering that Apple Mail had begun keeping local copies of everything.)

Upgrading the ports first is probably not a bad idea if you're going to be tinkering with them anyway, but be advised that a lot of those final releases will just consist of upgraded translations and other cosmetics.

The problem is that akonadi pulls in sqlite regardless of a backend, and even if sqlite is explicitly disabled: ​https://trac.macports.org/ticket/33998#comment:39

And once I patch out sqlite mess, this fails:

36-244% /opt/local/bin/akonadiserver-script.sh
Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString)
36-244% QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
ProcessControl: Application akonadiserver stopped unexpectedly ( "Process crashed" )
Application 'akonadiserver' crashed! 1 restarts left.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
ProcessControl: Application akonadiserver stopped unexpectedly ( "Process crashed" )
Application 'akonadiserver' crashed! 0 restarts left.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.
ProcessControl: Application akonadiserver stopped unexpectedly ( "Process crashed" )
Application 'akonadiserver' crashed too often. Giving up!

(This is with mariadb backend, as it claims.)

I do not know how someone gets this working. Do you do some special setup besides what the port suggests? Whatever I tried fails.

Some apps run, but not in a useful manner so far.

[barracuda156]

KDE4 updates seems to have some meaningful changes, at least they have broken a couple of ports LOL

​https://trac.macports.org/ticket/70060#comment:4

But I think something also improved (that akonadi still broken, so kdepim fails to run, dolphin displays a single file per folder, ktorrent does not seem to download anything, though does not crash now, etc.).

[RJVB (René Bertin)]

Replying to barracuda156:

The problem is that akonadi pulls in sqlite regardless of a backend, and even if sqlite is explicitly disabled: ​https://trac.macports.org/ticket/33998#comment:39

The cleanest thing to do (IMHO) is just to build everything but use a different backend, at most patching whatever needs to be patched to make the mysql backend the default.

36-244% /opt/local/bin/akonadiserver-script.sh Connecting to deprecated signal QDBusConnectionInterface::serviceOwnerChanged(QString,QString,QString) 36-244% QSqlDatabasePrivate::removeDatabase: connection 'initConnection' is still in use, all queries will cease to work.

Did you check for a lingering lock file? I have a vague memory that something like that can cause failures like the above. But that hasn't happened to me for ages.

Do you do some special setup besides what the port suggests? Whatever I tried fails.

That's certainly not impossible, but anything not formalised in my own akonadi and kdepim ports is pure local set-up under ~/.kde, ~/.config and ~/.local/share (akonadi and kdepim have used XDG paths before the rest of KDE started to do that).

I do not start akonadi via launchd though; I've always started it by hand with akonadictl start. As you are beginning to see it's very tricky software and even on Linux it needs to be restarted from time to time.

[barracuda156]

Was your KDE4 ahead of MacPorts before you switched to KDE5 completely?

If you refer me to a specific tree for KDE4 in your repo (which was/is known to work), I can clone that and try installing all KDE4 stuff from there just to make sure. If something is wrong in MacPorts versions, pretty likely I did not fix everything, so that may creep in (though it seems that sources themselves are less than stellar, so to say).

[RJVB (René Bertin)]

Replying to barracuda156:

Was your KDE4 ahead of MacPorts before you switched to KDE5 completely?

I think so, yes. ​https://github.com/RJVB/macstrop/tree/master/kde

My kdelibs4 port must be at one of the latest commits made upstream for instance (though I haven't checked that in quite a while). Just keep an eye out for a number of changes I (may have) made w.r.t. to KDE5 co-installability, and to the fact that I have a different Qt4 installation scheme.

I started the entire Qt4/5 co-installability effort way back when, and always used an approach that required the least changes to the install scheme. Qt4 and Qt5 were designed to be co-installable so there was never a need to install each completely in their own subtree. I remember warning about the how the changes that were planned for port:qt4-mac could wreak havoc on KDE4 ports (there must be a record of that...). I didn't get the impression those warnings landed on fertile grounds so I simply withdrew and stuck to my own solutions.

I'll have to admit that the errors you've been reporting have nothing that makes me think those misgivings have come true, a priori. Except possibly for the one about plugins not being found (but I think you solved that one?).

[barracuda156]

I am not sure I solved the plug-in issue since the thing did not work so far, but the error was gone from terminal output. By the way, that may be an issue with Trojita, which also does not find its SQLite plugin and fails to work.

There is nothing really holding me with existing MacPorts Qt4 implementation. It obviously does not work correctly in a number of cases, and if an alternative works better, there is no second thought. I will just switch my PowerPC stuff to that.

(Any implementation which is less MacOS-tuned may be better for me also, since Qt5 is totally broken for ppc with Cocoa, but it should work once there is a way to do a normal Unix build using X11.)

[RJVB (René Bertin)]

Replying to barracuda156:

(Any implementation which is less MacOS-tuned may be better for me also, since Qt5 is totally broken for ppc with Cocoa, but it should work once there is a way to do a normal Unix build using X11.)

Did you ever try to use the patches for my qt5-kde{,-devel}-x11 subports? From what I just saw it was functional from my commit #5bed2aae3f8cd03e2523fb42b51f16eea7975792 onwards, and may even have worked with Qt 5.3.2 (judging from version-specific patchfiles at least). Can't test my ports easily either anymore as Qt no longer provide the sources to "really old" versions and MacPorts servers only cache the component tarballs - how annoying is that!

[barracuda156]

Replying to RJVB:

Did you ever try to use the patches for my qt5-kde{,-devel}-x11 subports? From what I just saw it was functional from my commit #5bed2aae3f8cd03e2523fb42b51f16eea7975792 onwards, and may even have worked with Qt 5.3.2 (judging from version-specific patchfiles at least).

I think I tried your 5.3, but I have to check what version I ended up tweaking.

Can't test my ports easily either anymore as Qt no longer provide the sources to "really old" versions and MacPorts servers only cache the component tarballs - how annoying is that!

For 5.2 I this in my portfile:

master_sites \
    https://download.qt.io/new_archive/qt/${branch}/${version}/submodules

5.1 I only found on some third-party site:

master_sites \
    https://src.fedoraproject.org/repo/pkgs/qt5-qtbase/qtbase-opensource-src-5.1.1.tar.xz/955d1e4da875f3872ef3208f21a757dd/ \
    https://ftp.osuosl.org/pub/blfs/conglomeration/qt5/

[RJVB (René Bertin)]

It should be possible to get the "everywhere* all-inclusive tarball like the one I've always used via git, but I haven't yet figured out how to get the component submodules to check out at the desired version.

[barracuda156]

Replying to RJVB:

It should be possible to get the "everywhere* all-inclusive tarball like the one I've always used via git, but I haven't yet figured out how to get the component submodules to check out at the desired version.

I missed the part about kde-x11 above, and now found those ports in your tree. Gonna try those. Practice shows that X11 works nicely generally, while Cocoa belongs to a trash bin :) (With wxWidgets nothing worked for ages, until I started switching ports to wxGTK and added wxGTK-cxx port. Lo and behold, all of a sudden pretty much everything works. Given that it is not a ppc-specific issue, AFAIK, it looks like whomever were building those either never tried to use them or assumed it is broken for their system but works elsewhere, like I did. But it is just a bug in Cocoa version of wxWidgets.)

[RJVB (René Bertin)]

FWIW, the -x11 subports are not standalone in my implementation. They do a full X11 build of qtbase plus x11extras and maybe some other things. There's no other approach, but then they only install the things that aren't already provided by the main port. It turns out this works. In your case you would want to merge the changes and configure args applied in those -x11 subports to the main port, or to the corresponding subports if you adhere to the approach used by the official Qt5 port. Of course you could still start by checking the subport as it is, hacking it to be standalone.

Why didn't you add a variant (and why C++11 while wxW has a feature to build using C++14)? I *think* that that's a build option which doesn't change the ABI. I suppose you're talking about wxWidgets on systems that are older than mine. I have installed the latest 3.2'ish commit that still builds on 10.9 and it works OK for Audacity.

[RJVB (René Bertin)]

Replying to barracuda156:

For 5.2 I this in my portfile:

master_sites \
    https://download.qt.io/new_archive/qt/${branch}/${version}/submodules

Hah, yes, that subdir holds every single one of the "olderer" releases. Wonder who had the brilliant idea to call it new_archive!

[barracuda156]

Replying to RJVB:

FWIW, the -x11 subports are not standalone in my implementation. They do a full X11 build of qtbase plus x11extras and maybe some other things. There's no other approach, but then they only install the things that aren't already provided by the main port. It turns out this works. In your case you would want to merge the changes and configure args applied in those -x11 subports to the main port, or to the corresponding subports if you adhere to the approach used by the official Qt5 port. Of course you could still start by checking the subport as it is, hacking it to be standalone.

At least for Qt5 what I want is to build it like on every other non-Apple OS (NetBSD etc.), using X11 and no Cocoa (Carbon is out anyway). Your subports for qtbase does not do that at the moment?

Why didn't you add a variant (and why C++11 while wxW has a feature to build using C++14)? I *think* that that's a build option which doesn't change the ABI.

wxWidgets is nasty, though I did not try C++14 with it. But wxGTK-3.2 is broken even on Sonoma, so there is no way at the moment (obviously, neither Qt5 not Cocoa backend gonna work). ​https://github.com/wxWidgets/wxWidgets/issues/24460

For 3.0, if you build wxGTK with gcc-4.2, then it cannot be used with ports which require C++11 or higher. Which is why I had to add a subport for that.

I suppose you're talking about wxWidgets on systems that are older than mine. I have installed the latest 3.2'ish commit that still builds on 10.9 and it works OK for Audacity.

I recall 10.8 still had wxWidgets 3.0 built with Cocoa defunct. But not really sure how consistent is that. On 10.6 no port worked so far with wxWidgets 3.0, whether ppc or x86. But wxGTK 3.0 works fine.

[RJVB (René Bertin)]

Replying to barracuda156:

At least for Qt5 what I want is to build it like on every other non-Apple OS (NetBSD etc.), using X11 and no Cocoa (Carbon is out anyway). Your subports for qtbase does not do that at the moment?

No. My Qt5 ports aren't cut up like the mainstream one has been; port:qt5-kde installs the equivalent of what port:qt4-mac installs (and with lots of patching to make it more appropriate for KF5). The -x11 subport is designed as an add-on that provides the possibility to run applications under X11.

What I meant was that your initial testing could be to make that -x11 subport independent of the main port, and NOT strip it in the post-destroot so that it installs a basic but a priori fully functional X11 Qt5. If you have enough CPU cycles to invest you can also simply apply the patches from the -x11 port to the main port and idem for the changes to configure.args. I don't think I've ever tested this, so you may come across Cocoa (or Carbon) code in other components (qtdeclarative would be a prime suspect). That is no obstacle to running Qt5 apps with -platform xcb (i.e. in X11 mode) on a supported OS where those APIs are functioning normally; I cannot predict how it will work elsewhere.

I have one recurrent issue in X11 mode: long-running applications tend to get disconnected from the clipboard after a while. Possibly related to my habits of suspending the system for the night, which involves using FUS to go to the login screen and then turning off the Thunderbolt dock that drives my main display. Fact is, Qt5/xcb uses some kind of private hidden window as the "anchor" for clipboard operations so that the copied content gets discarded when you quit the application. That hidden window must get lost or something like that, meaning you can no longer copy content from X11 windows. GTk apps don't do this, but I've never yet been able to figure out why and patch Qt's code for this. For me it means I just have to relaunch my X11 terminals (KF5's konsole) from time to time.

There are also sporadic issues with displaying on a remote X11 display but I reckon that's not your main concern...

Why didn't you add a variant (and why C++11 while wxW has a feature to build using C++14)? I *think* that that's a build option which doesn't change the ABI.

wxWidgets is nasty, though I did not try C++14 with it. But wxGTK-3.2 is broken even on Sonoma, so there is no way at the moment (obviously, neither Qt5 not Cocoa backend gonna work).

Good thing I gave up port:audacity then! (Reading "Sonoma" my brain always adds "Gomorrea" 8-) )