Add digikam photo management package #2438

If digikam-test-data is only needed for running the test, it's unnecessary to define it as a <package>. you can directly add an <origin> record to the inputs of digikam, and refer it in with the file-name of it.

Done!

Prefer G-expression than S-expression

Done!

DK_PLUGIN_PATH use ; as separator.

See https://bugs.kde.org/show_bug.cgi?id=430566
and https://invent.kde.org/graphics/digikam/-/blob/v8.7.0/core/libs/dplugins/setup/dpluginloader_p.cpp?ref_type=tags#L103

Thanks for the remark, how odd! I've added a native-search-path with ; as separator, does this make explicitly setting DK_PLUGIN_PATH in a wrapper superfluous?

how odd!

digiKam says it's for M$ Windows compatibility (Windows driver letter have format C:

does this make explicitly setting DK_PLUGIN_PATH in a wrapper superfluous?

I'm not sure :(, but with native-search-spec it should at least run in common use case (installing to profile, run with guix shell digikam) if we remove the wrapper.

I've added the native-search-spec (and removed the DK_PLUGIN_PATH wrapper), and it just works, digikam is able to find its plugins

We should also wrap QTWEBENGINEPROCESS_PATH like https://codeberg.org/guix/guix/src/branch/master/gnu/packages/kde.scm#L498

I've added it to the wrapper, but what is that for? I've not ran into issues when running digikam

Quoting from Qt manual

At runtime, Qt WebEngine looks for the QtWebEngineProcess executable in the directory that QLibraryInfo::location(QLibraryInfo::LibraryExecutablesPath) returns. For Qt installations, this is QTDIR/libexec (Linux) or QTDIR\bin (Windows). The path can be changed by defining a qt.conf file, for example. Alternatively, an executable path can be set as a value of the QTWEBENGINEPROCESS_PATH environment variable. On macOS, Qt WebEngine looks for the executable in .app/Helpers/QtWebEngineProcess.

It looks good at first glance, however, the qtbase and qtwebengine are installed to different prefix in Guix, QTDIR will reference to the prefix of qtbase, and failed to find the webengine process.

In the case of digikam, this may break the Google Maps backend of the Geolocation Map, see https://invent.kde.org/graphics/digikam/-/blob/v8.7.0/core/utilities/geolocation/geoiface/backends/backendgooglemaps.cpp?ref_type=tags#L51

I'm not sure whether you have tested it or not.

ah yes, I have only tested the OSM backend, so that explains why I did not run into any issues

IIRC, digiKam supports build with Qt6

Archlinux also build it with Qt6 components

It should indeed build with qt6, should I prefer Qt6 components over Qt5 variants?

IMO, Qt 5 had reached its EOL, should prefer Qt6 if possible.

WDYT? @Z572

please use qt6

I'm currently trying to build with qt6, but I am running into an issue: qstatemachine is missing from our qt6 - if I'm not mistaken, it should be included in qtbase, but it's not present for qt6

@Z572 I've pushed the changes I made to (try to) build with qt6 as a separate commit (which would of course get squashed before merging), but sadly it does not build, lacking qstatemachine

see qtscxml

ah thanks, that fixed it! I pushed a new version that builds (and runs) with qt6, and as far as I can see everything works!

We may want a native-search-paths spec for DK_PLUGIN_PATH.

Done!

Multiple licenses listed in the repo of digiKam

https://invent.kde.org/graphics/digikam/-/tree/v8.7.0/LICENSES?ref_type=tags

As far as I can tell digikam's code is all gpl2+, the cmake scripts are bsd 3 clause, and the test data is cc-0, but I don't know a reliable way to check whether the code is indeed all gpl2+

oh, we'd better not open a can of worms here.

A better place for the static archives is the static output of exiv2. You can renam the phase delete-static-libraries to move-static-libraries, and move them to the static outputs.

I've tried doing this (and pushed it in a 4th comment on this branch), but I couldn't get it to build with this static setup, it still complains about some .a files not being found

OK, feell free to ignore this comment :)

Why we need libglvnd to enable OpenGL support? Doesn't mesa already provides a GL driver? And I don't see the source code of digikam mentions libglvnd.

Well, without libglvnd, digikam says during the build that opengl was not found. With libglvnd, digikam says that opengl was found but (on my system) it then crashes when I run it, so I removed libglvnd from the inputs again

(note that I've made changes to the package since I last built it with libglvnd, so this may have changed)

This seems to be a magic configure flags(what has LLVM to do with digikam?), can you add a comment about its usage?

oh yes, I don't think the LLVM flag is necessary, and I'll add a comment about the mediaplayer flag

Done

stale code, should be removed.

Done

It's better to use url-fetch here since Guix has pre-defined KDE mirrors

(origin
 (method url-fetch)
 (uri (string-append "mirror://kde/stable/digikam/"
 version "/digiKam-" version ".tar.xz"))
 (sha256
 (base32 ...)))

This is also the release tarball listed on the digiKam official website.

Done

i think is no need to wrap QTWEBENGINEPROCESS_PATH now

aight, I removed the wrapping

please don't add perl-image-exiftool to propagated-inputs, should wrap it or use substitute*

good catch, I wrapped /bin/digikam

why need ccache

indeed not necessary, so I removed it

add comment for why use exiv2-static.

done

libjpeg-turbo

added

remove it

done