The previous bump to version 1.6.1 left the sha256 of the src attribute
unchanged, and as a consequence, it still built the old version.
But since the make config injected the version number, the binary still
self-reported as 1.6.1, even though it was built from 1.5.0.
Semi-automatic update generated by https://github.com/ryantm/nixpkgs-update tools.
This update was made based on information from https://repology.org/metapackage/dunst/versions.
These checks were done:
- built on NixOS
- ran ‘/nix/store/41nqz94x6682ylch4vhg5pca977ffsd0-dunst-1.3.2/bin/dunst -h’ got 0 exit code
- ran ‘/nix/store/41nqz94x6682ylch4vhg5pca977ffsd0-dunst-1.3.2/bin/dunst --help’ got 0 exit code
- ran ‘/nix/store/41nqz94x6682ylch4vhg5pca977ffsd0-dunst-1.3.2/bin/dunst -v’ and found version 1.3.2
- ran ‘/nix/store/41nqz94x6682ylch4vhg5pca977ffsd0-dunst-1.3.2/bin/dunst --version’ and found version 1.3.2
- found 1.3.2 with grep in /nix/store/41nqz94x6682ylch4vhg5pca977ffsd0-dunst-1.3.2
- directory tree listing: https://gist.github.com/e6f68836d92d5855b650ece5004da126
- Use `fetchFromGitHub`
- No longer generate wrapper
dunst doesn't appear to shell out to dbus; nor should it, really
- Use standard buildPhase
- Split outputs
- Also build dbus service file, so that dunst can be
used with services.dbus.packages
Prior to this change, the following would fail
nix-shell --pure -p dunst --command dunst
while this would succeed
nix-shell --pure -p dunst -p dbus_daemon --command dunst
because dunst tries to execve 'dbus-launch'. The same issue hit if dunst
was used inside a (user) systemd service (which is what I actually care
about).
This commit eliminates a patch which hard-coded an example configuration file as the program's default settings and prevented the program from reading a user's configuration file.
