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]
signature.asc
Description: This is a digitally signed message part.