The KDEPIM / Akonadi situation

[Adriaan de Groot]

On Saturday, 13 June 2020 09:29:36 CEST Volker Krause wrote:
> I have finite time and prioritized what seemed to have most wide-spread
> impact (all of Android and all of Flatpak vs. Akonadi/FreeBSD),

And, as time and circumstance permits, the PIM team prods me and/or tcberner 
to take an extra close look.



There is a peculiar cascade going on here, which **isn't** especially PIM-
related. 

1) kaccounts-integration has a binary-incompatible change going on: it changed 
to
	explicit GetCredentialsJob(Accounts::AccountId id, QObject *parent = 
nullptr);

from 

	explicit GetCredentialsJob(const Accounts::AccountId &id, QObject 
*parent = nullptr);

2) For whatever reason, **older** kaccounts-integration is installed on the 
FreeBSD builders before Akonadi builds; this puts the old headers in /usr/
local/include

3) I don't know if new accounts-integration builds before Akonadi; if it does, 
I don't know where it is installing its headers.

4) When building Akonadi, it has /usr/local/include in its search path 
**ahead** of any paths that might point to the "new" accounts-integration 
headers. So it picks up the old definitions, then bails out when it tries to 
link to the new libraries.



I can reproduce the problem locally with kdesrc-build.

Possibly Linux CI doesn't get the same problem, because it doesn't need to 
have extra system header locations (i.e. /usr/local/include) put onto the 
search path, and so an older installed accounts-integration just lives in the 
"default bits" which are searched last.


So if anything, what we're seeing here is a BIC that falls over because too 
many pieces have to move at once, on a platform that has some special 
considerations, that none of the PIM developers are on all the time. If you 
want to get on their case at all, do it for "ask [ade] or tcberner earlier", 
although in this particular case it wouldn't have sped things up: it's 
saturday afternoon, and now I have time to look into this.

[ade]

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 833 bytes
Desc: This is a digitally signed message part.
URL: <http://mail.kde.org/pipermail/kde-community/attachments/20200613/7760489e/attachment.sig>