Could you change required version from 6.0 to 5.4?

In D13842#309271, @habacker wrote:

I can think of that this reference may be included as a direct library dependency in a 3rdparty dependency, if GPGME was not found

In D13838#292863, @habacker wrote:

In D13838#292380, @habacker wrote:

see https://bugzilla.opensuse.org/show_bug.cgi?id=1101255

I got this answer:

Ok, so it's a known GCC issue. Fix for the issue was also backported to GCC-5
branch, but probably not fully. Anyway, please update to a newer version of
GCC, GCC-5 branch is out of support.

In T6308#156195, @bcooksley wrote:

This has been confirmed. The only things that can be done in this case are:

1. Develop/Port a CMake build system for SQLCipher
2. Introduce CI support for MingW builds.
   
   Any comments on this @smankowski and @wojnilowicz ?
   
   Note that introducing MingW support won't be trivial and will require modification of a few parts of the CI Tooling so some assistance with that will be needed.

Changed source links to our own.

In D14926#311442, @tbaumgart wrote:

Cool, I started out to read about appimage a few times myself but never got around to really work on it. I have not tried any of that yet, but it looks very promising. Can we have that for the upcoming 5.0.2 release?

In T6308#154689, @bcooksley wrote:

This has now been provisioned.

Unfortunately the code doesn't successfully compile at the moment due to issues with QSQLite and SQLCipher, but those are problems with the codebase you'll need to fix i'm afraid!
https://binary-factory.kde.org/job/Skrooge_Nightly_mingw64/3/console

Please let us know if anything further is required.

Incorporated changes according to the review.

In D14756#307613, @tbaumgart wrote:

In general, the idea to change the storage of matching transactions is OK. It was more of a quick hack back then. But I think, we need to iron out a few things before we can add it to master. Maybe even postpone it after the next release, because it changes the file structure and is not backward compatible.

In D14522#302502, @tbaumgart wrote:

In D14522#302220, @wojnilowicz wrote:

In D14522#302070, @habacker wrote:

Christian David mentioned at https://mail.kde.org/pipermail/kmymoney-devel/2018-May/020846.html to wait until 23rd of October 2018 before merging alkimia in case no feature has been added.

Who's going to add new features?
That is Christian's point of view. I'm not going to sit and wait longer for a miracle to happen. Nobody develops alkimia and it's unhandy to fix compiler warnings with it being in a separate library.

It is also my POV. Alkimia is stable and does its job. At this point, I don't care for compiler warnings. We certainly have more severe problems than compiler warnings which might have been introduced recently and exist more or less on Windows environments only. I don't want to jeopardize the current stability by changing one of the core elements of KMyMoney. That said, I am against this change to be applied to the current master or 5.0 branch at least until the next KMyMoney release.

In D14522#302070, @habacker wrote:

Christian David mentioned at https://mail.kde.org/pipermail/kmymoney-devel/2018-May/020846.html to wait until 23rd of October 2018 before merging alkimia in case no feature has been added.

It's as good as before.

In D13842#299187, @habacker wrote:

In general, the issue occurs, if the cmake package Gpgmepp was not found, but the term 'Gpgmepp' has been added to a call to target_link_libraries, which translates the term into -lGpgmepp, searching for a real shared library with this name.

Besides my single comment, it looks OK.

Good move.

In D14257#295467, @tbaumgart wrote:

Tested with my real file which contains 66 schedules. Produces the exact same output as master.