nixpkgs/pkgs/applications/graphics/digikam/default.nix

125 lines
2.0 KiB
Nix
Raw Normal View History

{ mkDerivation, lib, fetchFromGitHub, cmake, doxygen, extra-cmake-modules, wrapGAppsHook
# For `digitaglinktree`
, perl, sqlite
, qtbase
, qtxmlpatterns
, qtsvg
, qtwebkit
digikam: 5.4.0 -> 5.7.0 The build for the version 5.4.0 of digiKam has been broken at the time prior to this commit, which is the main reason for this update as I don't think it makes sense to fix the build for 5.4.0 when we're going to update it anyway. A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too much to be summarized here, so here are the URLs to the upstream announcements: * https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/ * https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/ * https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/ On the packaging side, we now no longer have the patch that disables -fno-operator-names because the build runs fine without that patch (which didn't even apply but I didn't check why) and IMO it doesn't make sense to rebase that patch for no reason. Additionally, there were build time dependencies lurking around in propagatedBuildInputs, which is kinda pointless and the application just runs fine if those dependencies are listed in buildInputs. While looking for clues about why that might be necessary I haven't found any comment about it in the source nor a clarification within the message of the commit where this has been introduced. The commit in question is be7b7d908f82e8ab16c43ffd0e240addd6f4018a. Apart from these changes, the rest is just adding a few dependencies (kcalcore, libksane, mesa and pcre) to get less errors during cmakeConfigurePhase. I've tested digiKam by playing around within a VM using photos I netcat'ed into it and it works so far. The VM was built using: nix-build nixos --arg configuration '{ pkgs, ... }: { imports = [ ./nixos/tests/common/user-account.nix ]; environment.systemPackages = [ pkgs.digikam ]; services.xserver.enable = true; services.xserver.displayManager.sddm.enable = true; services.xserver.desktopManager.plasma5.enable = true; services.xserver.desktopManager.default = "plasma5"; virtualisation.memorySize = 1024; }' -A vm What I didn't test however was whether importing from a camera would work (as I don't have one), but aside from that, the application seems to run fine compared to the fact that it didn't even build until now :-) Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel Cc: @jraygauthier, @fkz, @sh01, @lsix
2017-10-19 02:04:45 +01:00
, kcalcore
, kconfigwidgets
, kcoreaddons
, kdoctools
, kfilemetadata
, knotifications
, knotifyconfig
, ktextwidgets
, kwidgetsaddons
, kxmlgui
, bison
, boost
, eigen
, exiv2
, flex
, jasper
, lcms2
, lensfun
, libgphoto2
, libkipi
digikam: 5.4.0 -> 5.7.0 The build for the version 5.4.0 of digiKam has been broken at the time prior to this commit, which is the main reason for this update as I don't think it makes sense to fix the build for 5.4.0 when we're going to update it anyway. A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too much to be summarized here, so here are the URLs to the upstream announcements: * https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/ * https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/ * https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/ On the packaging side, we now no longer have the patch that disables -fno-operator-names because the build runs fine without that patch (which didn't even apply but I didn't check why) and IMO it doesn't make sense to rebase that patch for no reason. Additionally, there were build time dependencies lurking around in propagatedBuildInputs, which is kinda pointless and the application just runs fine if those dependencies are listed in buildInputs. While looking for clues about why that might be necessary I haven't found any comment about it in the source nor a clarification within the message of the commit where this has been introduced. The commit in question is be7b7d908f82e8ab16c43ffd0e240addd6f4018a. Apart from these changes, the rest is just adding a few dependencies (kcalcore, libksane, mesa and pcre) to get less errors during cmakeConfigurePhase. I've tested digiKam by playing around within a VM using photos I netcat'ed into it and it works so far. The VM was built using: nix-build nixos --arg configuration '{ pkgs, ... }: { imports = [ ./nixos/tests/common/user-account.nix ]; environment.systemPackages = [ pkgs.digikam ]; services.xserver.enable = true; services.xserver.displayManager.sddm.enable = true; services.xserver.desktopManager.plasma5.enable = true; services.xserver.desktopManager.default = "plasma5"; virtualisation.memorySize = 1024; }' -A vm What I didn't test however was whether importing from a camera would work (as I don't have one), but aside from that, the application seems to run fine compared to the fact that it didn't even build until now :-) Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel Cc: @jraygauthier, @fkz, @sh01, @lsix
2017-10-19 02:04:45 +01:00
, libksane
, liblqr1
, libqtav
, libusb1
, marble
, libGL
, libGLU
digikam: 5.4.0 -> 5.7.0 The build for the version 5.4.0 of digiKam has been broken at the time prior to this commit, which is the main reason for this update as I don't think it makes sense to fix the build for 5.4.0 when we're going to update it anyway. A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too much to be summarized here, so here are the URLs to the upstream announcements: * https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/ * https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/ * https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/ On the packaging side, we now no longer have the patch that disables -fno-operator-names because the build runs fine without that patch (which didn't even apply but I didn't check why) and IMO it doesn't make sense to rebase that patch for no reason. Additionally, there were build time dependencies lurking around in propagatedBuildInputs, which is kinda pointless and the application just runs fine if those dependencies are listed in buildInputs. While looking for clues about why that might be necessary I haven't found any comment about it in the source nor a clarification within the message of the commit where this has been introduced. The commit in question is be7b7d908f82e8ab16c43ffd0e240addd6f4018a. Apart from these changes, the rest is just adding a few dependencies (kcalcore, libksane, mesa and pcre) to get less errors during cmakeConfigurePhase. I've tested digiKam by playing around within a VM using photos I netcat'ed into it and it works so far. The VM was built using: nix-build nixos --arg configuration '{ pkgs, ... }: { imports = [ ./nixos/tests/common/user-account.nix ]; environment.systemPackages = [ pkgs.digikam ]; services.xserver.enable = true; services.xserver.displayManager.sddm.enable = true; services.xserver.desktopManager.plasma5.enable = true; services.xserver.desktopManager.default = "plasma5"; virtualisation.memorySize = 1024; }' -A vm What I didn't test however was whether importing from a camera would work (as I don't have one), but aside from that, the application seems to run fine compared to the fact that it didn't even build until now :-) Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel Cc: @jraygauthier, @fkz, @sh01, @lsix
2017-10-19 02:04:45 +01:00
, opencv3
, pcre
, threadweaver
# For panorama and focus stacking
, enblend-enfuse
, hugin
, gnumake
, oxygen
}:
2017-05-16 16:56:41 +01:00
mkDerivation rec {
name = "digikam-${version}";
version = "5.9.0";
src = fetchFromGitHub {
owner = "KDE";
repo = "digikam";
rev = "v${version}";
sha256 = "09diw273h9i7rss89ba82yrfy6jb2njv3k0dknrrg7bb998vrw2d";
};
2017-10-21 07:42:00 +01:00
nativeBuildInputs = [ cmake doxygen extra-cmake-modules kdoctools wrapGAppsHook ];
buildInputs = [
bison
boost
eigen
exiv2
flex
jasper
lcms2
lensfun
libgphoto2
libkipi
digikam: 5.4.0 -> 5.7.0 The build for the version 5.4.0 of digiKam has been broken at the time prior to this commit, which is the main reason for this update as I don't think it makes sense to fix the build for 5.4.0 when we're going to update it anyway. A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too much to be summarized here, so here are the URLs to the upstream announcements: * https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/ * https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/ * https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/ On the packaging side, we now no longer have the patch that disables -fno-operator-names because the build runs fine without that patch (which didn't even apply but I didn't check why) and IMO it doesn't make sense to rebase that patch for no reason. Additionally, there were build time dependencies lurking around in propagatedBuildInputs, which is kinda pointless and the application just runs fine if those dependencies are listed in buildInputs. While looking for clues about why that might be necessary I haven't found any comment about it in the source nor a clarification within the message of the commit where this has been introduced. The commit in question is be7b7d908f82e8ab16c43ffd0e240addd6f4018a. Apart from these changes, the rest is just adding a few dependencies (kcalcore, libksane, mesa and pcre) to get less errors during cmakeConfigurePhase. I've tested digiKam by playing around within a VM using photos I netcat'ed into it and it works so far. The VM was built using: nix-build nixos --arg configuration '{ pkgs, ... }: { imports = [ ./nixos/tests/common/user-account.nix ]; environment.systemPackages = [ pkgs.digikam ]; services.xserver.enable = true; services.xserver.displayManager.sddm.enable = true; services.xserver.desktopManager.plasma5.enable = true; services.xserver.desktopManager.default = "plasma5"; virtualisation.memorySize = 1024; }' -A vm What I didn't test however was whether importing from a camera would work (as I don't have one), but aside from that, the application seems to run fine compared to the fact that it didn't even build until now :-) Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel Cc: @jraygauthier, @fkz, @sh01, @lsix
2017-10-19 02:04:45 +01:00
libksane
liblqr1
libqtav
libusb1
libGL
libGLU
digikam: 5.4.0 -> 5.7.0 The build for the version 5.4.0 of digiKam has been broken at the time prior to this commit, which is the main reason for this update as I don't think it makes sense to fix the build for 5.4.0 when we're going to update it anyway. A lot has changed upstream between version 5.4.0 and 5.7.0 and it's too much to be summarized here, so here are the URLs to the upstream announcements: * https://www.digikam.org/news/2017-03-14_digiKam_5.5.0_is_released/ * https://www.digikam.org/news/2017-06-21-5.6.0-release-announcement/ * https://www.digikam.org/news/2017-09-11-5.7.0_release_announcement/ On the packaging side, we now no longer have the patch that disables -fno-operator-names because the build runs fine without that patch (which didn't even apply but I didn't check why) and IMO it doesn't make sense to rebase that patch for no reason. Additionally, there were build time dependencies lurking around in propagatedBuildInputs, which is kinda pointless and the application just runs fine if those dependencies are listed in buildInputs. While looking for clues about why that might be necessary I haven't found any comment about it in the source nor a clarification within the message of the commit where this has been introduced. The commit in question is be7b7d908f82e8ab16c43ffd0e240addd6f4018a. Apart from these changes, the rest is just adding a few dependencies (kcalcore, libksane, mesa and pcre) to get less errors during cmakeConfigurePhase. I've tested digiKam by playing around within a VM using photos I netcat'ed into it and it works so far. The VM was built using: nix-build nixos --arg configuration '{ pkgs, ... }: { imports = [ ./nixos/tests/common/user-account.nix ]; environment.systemPackages = [ pkgs.digikam ]; services.xserver.enable = true; services.xserver.displayManager.sddm.enable = true; services.xserver.desktopManager.plasma5.enable = true; services.xserver.desktopManager.default = "plasma5"; virtualisation.memorySize = 1024; }' -A vm What I didn't test however was whether importing from a camera would work (as I don't have one), but aside from that, the application seems to run fine compared to the fact that it didn't even build until now :-) Signed-off-by: aszlig <aszlig@redmoonstudios.org> Cc: @the-kenny, @urkud, @viric, @cillianderoiste, @ttuegel Cc: @jraygauthier, @fkz, @sh01, @lsix
2017-10-19 02:04:45 +01:00
opencv3
pcre
2017-05-16 16:56:41 +01:00
qtbase
qtxmlpatterns
qtsvg
qtwebkit
kcalcore
2017-05-16 16:56:41 +01:00
kconfigwidgets
kcoreaddons
kfilemetadata
knotifications
knotifyconfig
ktextwidgets
kwidgetsaddons
kxmlgui
marble
oxygen
2017-05-16 16:56:41 +01:00
threadweaver
];
cmakeFlags = [
"-DENABLE_MYSQLSUPPORT=1"
"-DENABLE_INTERNALMYSQL=1"
"-DENABLE_MEDIAPLAYER=1"
];
2017-05-16 16:56:41 +01:00
preFixup = ''
gappsWrapperArgs+=(--prefix PATH : ${lib.makeBinPath [ gnumake hugin enblend-enfuse ]})
substituteInPlace $out/bin/digitaglinktree \
--replace "/usr/bin/perl" "${perl}/bin/perl" \
--replace "/usr/bin/sqlite3" "${sqlite}/bin/sqlite3"
'';
2017-05-16 16:56:41 +01:00
meta = with lib; {
description = "Photo Management Program";
2017-05-16 16:56:41 +01:00
license = licenses.gpl2;
2018-05-01 04:03:23 +01:00
homepage = https://www.digikam.org;
2017-05-16 16:56:41 +01:00
maintainers = with maintainers; [ the-kenny ];
platforms = platforms.linux;
};
}