This feature is fixed within 18.08.0

This feature is fixed within 18.08.0

I would stepup for planing such a sprint.
I've a place in mind in France near Grange Neuve, but I have to find the flyer with the correct name...
I think about doing the print next spring.

volker signed up for this :D

In T3689#152327, @bcooksley wrote:

The Package class is designed to use the newest version, not the oldest, and doesn't retain older versions (they're overwritten on upload) so that model won't work given our current constraints. I'll see what can be done about making it run though so you get that initial data.

but that's why I made the package name unique {lib.name}_{srcRevision} (D11916), I thought this would make sure, that each build will create a unique tarball.

In terms of creating the reference dataset, the best way is probably a dedicated job, much like the existing Dependency Builds, which builds a specified release tag for all the projects which are receiving this coverage in turn.

@pino: it is just a warning and it successfully creates a dump without ctags. and i havn#t found what feature is enabled by ctags.

well removing clang was the easiest part to make sure that the gcc call is not called with "-I/usr/include/clang/AST -I/usr/lib64/clang/6.0.0/include"

@bcooksley thanks for the script it has some issues ( python instead of python3 and one missing cd .. before running python) :

I can't use the ci-docker because I don't manage it to create a build environment to build kde applications without building all frameworks. Can I download the whole envrionment somehow to have the same build to test?

@dkurz: the idea is that we will close it with the first version realeased with it. This way we see what is not released already.

The error looks like that we need other gcc-options to compile for Frameworks. But I do not find the correct options - maybe we should ask Framework devs, if they now this.

use new function Protocol::toJson

chain up to Command->toJson()

In T8568#145216, @vkrause wrote:

For the header interface:

• what's the KMime::Message* parameter for, shouldn't this be coming from the nodehelper context (in particular since we might want to deviate from what KMime has)?

i do not get what you mean.

fixing issues raised

no Akonadi namespace.

Rely on QJsonObject variant of JSON creation.
ouput only DebugString OR JSON.

We need an Interface for the headers:

remove showMailAction now completly.

use case_label and fix issue in scope.

use iEmpty and qAsConst

add toJson for Relations

Use QStandardItemModel and make it autoAdjust the size of the rows.

In D12738#259115, @dvratil wrote:

Since the view is backed by QStandardItemModel I think it would be better to use appendRow():

auto out = new QStandardItem(QStringLiteral("->"));
out->setForeground(Qt::green);
mModel->appendRow({ new QStandardItem(identifier), out, new QStandardItem(msg.trimmed());

and analogously for the other direction

update using setVerticalHeaderLabels.

Thanks for all these fixes from you. If you have any questions regarding developing please feel free to join #akonadi on IRC or use the mailinglist kde-pim@kde.org.
Especially as akregator has no real maintainer at the moment, so we will be very happy if people step up and take over mantainership.