This was blocking stuff up in Raspbian buster so I decided to take a look.
I decided to base my work on the version currently in Debian experimental. First of all I reduced the exiv2 dependency in both the Debian packaging and the upstream cmake to 0.25. I then turned my attention to the kdepim problem. After some time messing around with upstreams broken git history I was able to locate the relevent patches, merge them together and fix-up the filepaths. They then applied cleanly. I then ran into another build failure. In file included from /usr/include/c++/7/cmath:45:0, from /usr/include/c++/7/math.h:36, from /digikam-5.7.0/core/libs/rawengine/libraw/internal/dcraw_common.cpp:22: /usr/include/arm-linux-gnueabihf/bits/mathcalls.h:140:1: note: candidate: _Float64 powf64(_Float64, _Float64) __MATHCALL_VEC (pow,, (_Mdouble_ __x, _Mdouble_ __y)); ^ /digikam-5.7.0/core/libs/rawengine/libraw/internal/dcraw_common.cpp:5752:14: note: candidate: float powf64(float, float) static float powf64(float a, float b) it looks like there is a conflict between a function called "powf64" in the dcraw code in digikam and a "powf64" function in the kernel headers upstream fixed this by renaming powf64 to libraw_powf64, I did the same. In this case since it was a simple rename I did not bother going digging for the original upstream patch. I am currently doing a final build with the changes, assuming it suceeds I will upload it to Raspbian and post a debdiff to this bug. No intent to NMU in Debian.