fixed the issues from @bcooksley

use git log to extract current hash.

vkrause: ping

The suffix .tar is added by the Archive.storePackage method line 163 but we need to rewrite the whole Archive logic a bit as it expects the tar on other places too. For the moment I would ignore this, as the data is correct. IMO: it more a cosmetic issue. I keep this in mind and fix this when implementing the next step.

new context.

In D15997#338072, @dvratil wrote:

KMailTransport is a PIM library in the first place. PIM already depends on WebEngine, so I'm not much in favor of this change, sorry.

(and afaik the only platform that we support that struggles with QtWebEngine is BSD, but even they somehow managed to hack around it and have it)

I'll got ACK from Les Magnas that they are fully free before April.

I recommend to use https://community.kde.org/KDE_PIM/Docker to create a build environment for master.
Do you have already a identity acount (https://identity.kde.org/)? Otherwise others can push for you, if you tell us your mailaddress to add to the commits.
Normally we push the first couple of patches to get known each other and afterwards do the identity account, as you have full access to all KDE repos with an identity account.

And what about the idea of a "HeaderObject" instead of methos inside nodehelper?

@aacid: right, for a lot a big shared room is fine and for most a two persons room is fine. But I think we also need the possibility for people to have a single room one or two.

And the mail:/ kio interface may be interesting for this task:

@vkrause: Unfortunately I forgotten what we discussed at Akademy what a better interface would look like. That's why I started now to implement that one. I think we thought at something like a "HeaderObject":

const auto headerObject = nodeHelper->headerObject(message);
headerObject->hasHeader("to");
headerObject->header("simple"); /return Base
headerObject->asAddressList("to");
headerObject->date();

now realy remove the part I don't want the RR.

remove parts that shuld not have got to the review request.

@dfaure: you made tests form frameworks run without installing, so maybe there are already some ecm foo available for that...

do not reindent xml.

I can't push:
Pushing changes to "origin/master".
FATAL: W any sysadmin/ci-tooling knauss DENIED by fallthru
(or you mis-spelled the reponame)
fatal: Could not read from remote repository.

okay made KTextEditor built successfully with the patch D15706.

The Linux Hotel in Essen-Host (https://www.linuxhotel.de, German only) is are really nice location. I was there once some years ago and forgotten about it :D I ask them today by phone, but they can only host at maximum 25 persons. And this only if several share a two bed room. They proposed to asl "Unperfekt Haus" in Essen Cetrum (https://www.unperfekthaus.de, German only).

Together with @stolborg , we are evaluatiing currently two options:

• Les Magnas (France, Provence, Pierrerue): http://auxsaisons.free.fr/
  • 2h by train/bus reachable from Marseilles (nearest airport)
  • how people get from the bus station to the venue ( shuttle service needed)
• local scout huts in Denmark (likely far out and lessluxurious)
  • do we need to cook by ourselfs (I know people, who like to cook for us)
  • how people reach the venue?
  • can people sleep in small rooms?

In T9595#158350, @poboiko wrote:

Next I'm going to look into the Akonadi plugin for KPeople, which should feed KPeople with Akonadi contacts. There is indeed some disabled code in KPeople, I'm going to look into it next
NB: Daniel told that, since KPeople is inside Frameworks, it cannot depend on Akonadi, so we'll have to move it to Akonadi code base eventually.

sorry, it will properly take some time till I'll find time to look into it. I'm still traveling around and will be at home with the beginning of september...

I'm also with you aheineke, that this Autoencrypt is not the smartest solution for email encryption. As Thunderbird already sends those headers it is very good if we support it, too. And I see some gain in some usecases where Autoencrypt makes the life easier.

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.