I've been looking into this a bit more, as it's blocking just about every KDE PIM application. The issue appears to be unrelated to akonadi as I thought earlier. Instead, the error is raised by a Qt component, QFileSystemWatcher.
How should I proceed with this? I'm currently building Qt with debug info because for the moment I cannot even determine how one ends up in QFileSystemWatcher::adPath from inside akonadiconsole which I picked as my testbed. The only kdepim4 code invoking that class directly belongs to the kleopatra app, and I haven't yet seen any issues with that. R. On May 23, 2014, at 17:06, René J.V. Bertin wrote: > Hello, > > On May 23, 2014, at 14:13, Nicolas Pavillon wrote: > >>> I notice that the default is now to use a mariadb backend, but even if I >>> install that akonadi variant, how am I to reconfigure the server if I >>> cannot get to the server configuration dialog (which I only know how to >>> open through akonadiconsole)? >> >> One common solution to this type of issues is to remove (or move out of the >> way) the preferences file of the application, located in >> ~/Library/Preferences/KDE/share/config, to let the application start afresh. >> Did you try that? > > Yes, of course - and I tried to remove both > ~/Library/Preferences/KDE/share/config/akonadiconsolerc and > ~/.config/akonadi/akonadiserverrc . Since I removed the former, > akonadiconsole no longer gets beyond the initial window alerting the user to > the fact it's a development app. _______________________________________________ macports-users mailing list [email protected] https://lists.macosforge.org/mailman/listinfo/macports-users
