Change:
postFixup = "wrapPythonPrograms"; <ins> # the geoclue agent may inspect these paths and expect them to be # valid without having the correct $PATH set postInstall = '' substituteInPlace $out/share/applications/redshift.desktop  --replace 'Exec=redshift' "Exec=$out/bin/redshift" substituteInPlace $out/share/applications/redshift.desktop  --replace 'Exec=redshift-gtk' "Exec=$out/bin/redshift-gtk" ''; </ins> enableParallelBuilding = true; meta = with stdenv.lib; {

Discussion:
I'm not entirely sure when this started happening, but I now see the following in my logs. redshift: localtime: This seems to be an old issue that's recurred, see e.g. The last comment has this message, and suggests that the issue may have started between geoclue 2.4.7-1 and 2.4.10-1. Previous commenters seem to have a different issue (which it seems like we should also have, since I can't find that we install the files anywhere, possibly because the module doesn't add to ). The localtime dev also seems to have noticed this issue: Try or system: host os: multi-user?: sandbox: version: channels(michael): channels(root): nixpkgs:
Hm, some other people have reported () that geoclue is crashing when redshift tries to connect with it. This is actually consistent with what I'm seeing - the geoclue service also seems to be restarting constantly, although I don't get any crash message.
Is whitelisting redshift the solution, or is it clear? I miss redshift :(.
There's some hope that upgrading geoclue might help, however I'm struggling to get the new version to build.
I managed to build the new version with the docs disabled, but it doesn't seem to change anything. For localtime, I don't believe the issue is the permissions one, but perhaps rather that they've started requiring an "agent" that we don't have (, perhaps?). It gives the corresponding error message that's in that commit. I have no idea what's wrong with redshift, it could be a similar thing?
Here's what I've tried so far: Updating geoclue to 2.4.11. Adding a service that runs the geoclue demo agent. Neither of these seem to have helped at all. The agent just sits there saying regardless, and everything still fails :( I am using KDE, possibly there should be a location services agent associated with that, but I'm not sure where to find that.
Some progress, enough to fix redshift at least:
It's possible that this situation will get a bit better - a geoclue dev has popped up in and seems to be somewhat aware of the problems this has caused.
So I have yet still crashes for me with the above error. Any ideas?

Localtime is still broken. See for my suggestion on how to get a sensible fix. The maintainer has agreed, but hasn't done anything yet.
I'm getting constantly message , is that a side-effect of this bug? :)
That's probably the geoclue default agent, which we're using because you have to have one, and which tries to ask for permission for an app to get the location. On KDE at least it displays a popup, possibly it doesn't work as well on your DE.
already knows this, but for everyone else playing along, the geoclue app-whitelist change has since been applied, which might open up the possibility for redshift and localtime to get fixed in NixOS.
1) this commit didn't make it in last release and could be potentially an issue 2) I'm testing now backporting meson bump to 18.09 as it's required by latest geoclue2
Maybe for 18.09 best solution is to downgrade geoclue? It's nearly impossible to bump meson in a stable channel.
See for 18.09 reverts.