The KDEPIM / Akonadi situation

[Ben Cooksley]

On Sun, Jun 14, 2020 at 3:35 AM Adriaan de Groot <groot at kde.org> wrote:
>
> 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

This should be removed (along with any Frameworks and other associated KDE code)

As a general rule, CI builders are supposed to be sterile machines,
having nothing that they build installed on them to ensure the
environment is pure to avoid contamination from older versions of our
software which causes unexpected failures.

(In essence, the goal is to replicate the sort of environment that
would be used by packagers, or those setting their system up for the
very first time as much as possible)

>
> 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.

The CI system supplies kaccounts-integration as part of the
dependencies it fetches, which are the results from prior builds.

This can be seen at
https://build.kde.org/job/Applications/job/akonadi/job/kf5-qt5%20FreeBSDQt5.14/lastSuccessfulBuild/consoleText
In this log we see "Retrieving:
Applications-kaccounts-integration-kf5-qt5" which is where it fetches
and makes kaccounts-integration available.

The list of projects that are fetched and made available to a project
when building is governed by the metadata files in
sysadmin/kde-build-metadata on invent.kde.org.

In terms of where it gets installed to, this is specified by the
--installTo parameter to prepare-dependencies.py, which is set to
/home/jenkins/install-prefix/ in that log.

Following the completion of the build (regardless of failure or
success) that directory is erased to ensure the system has a clean
state for the next build that runs on the machine.

We are forced to use a single path that is identical for all builds
due to limitations in KWin and it's associated components, which for
"security reasons" bake the install path into their binaries,
something that makes them non-relocatable. If this path is changed,
then KWin's tests fail.

>
> 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.
>

Linux and Windows CI won't experience this issue as their environments
are sterile, and don't contain any KDE software until it is brought in
(and subsequently cleaned up following a build) by the CI system.

>
> 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]
>

Cheers,
Ben