The biggest benefit is that we no longer have to update the registry
package. This means that just about any cargo package can be built by
nix. No longer does `cargo update` need to be feared because it will
update to packages newer then what is available in nixpkgs.
Instead of fetching the cargo registry this bundles all the source code
into a "vendor/" folder.
This also uses the new --frozen and --locked flags which is nice.
Currently cargo-vendor only provides binaries for Linux and
macOS 64-bit. This can be solved by building it for the other
architectures and uploading it somewhere (like the NixOS cache).
This also has the downside that it requires a change to everyone's deps
hash. And if the old one is used because it was cached it will fail to
build as it will attempt to use the old version. For this reason the
attribute has been renamed to `cargoSha256`.
Authors:
* Kevin Cox <kevincox@kevincox.ca>
* Jörg Thalheim <Mic92@users.noreply.github.com>
* zimbatm <zimbatm@zimbatm.com>
Aspell will search for dictionaries in all nix profiles even when used as library.
Setting data-dir or dict-dir in ASPELL_CONF will disable this behavior.
* biboumi: init at 6.1
TODO: integrate config in NixOS
* biboumi: remove external buildtime dep
- fetch catch.hpp in a reproducible way
- add maintainer
- enable tests
- remove git dep
- enable parallel building
- add pandoc dep for man page
- nitpicks
* biboumi: refine substitutions
- only CMakeLists.txt has to be patched regarding /etc/biboumi
- substitute /bin/kill in systemd service file
- prepare for configuring policy_directory in a future cfg file
"SCons release 3.0.0 now available from the download page at
SourceForge. This release should be used instead of 2.5.1. This release
fixes several issues. TThis will be the first release to support Python
versions earlier than 2.7 as well as 3.5+."
"NOTE: This is a major release. You should expect that some targets may
rebuild when upgrading. Significant changes in some python action
signatures. Also switching between PY 2.7 and PY 3.5, 3.6 will cause
rebuilds."
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 be7b7d908f.
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
