Comment # 6 on bug 1093592 from Tejas Guruswamy

After a long investigation I finally understand the situation -- see
https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/143 and
https://github.com/jonls/redshift/issues/636 for background.

Essentially redshift queries geoclue for a location, which fires up a system
DBUS service. This then checks with a user authentication agent if you are
allowed to get the location. The system service exists again after 60 seconds
of inactivity.

Failure point #1 is if no user agent is running. In the current geoclue package
the user authentication agent is started by desktop autostart
(/etc/xdg/autostart/geoclue-demo-agent.desktop) so if you are not running a
desktop login, you cannot use GeoClue. This failure is consistent and can be
avoided by manually starting the demo agent first.
In GeoClue prior to 2.5.7, you could work around the need for an agent by
adding a stanza to the geoclue.conf file. But with GeoClue 2.5.7 (in Leap 15.4)
the agent checks became more strict and that no longer applies.
This is intentional by the GeoClue devs.

Failure point #2 is that the GeoClue system service was not waiting long enough
for the authentication agent to respond. (Hence why running the query twice
sometimes works). This failure is essentially a GeoClue bug and can be fixed by
upgrading to GeoClue 2.6.0 (already in Tumbleweed).

If those still using redshift on Leap 15.4 can detail exactly what their
expectations and use cases are for redshift+geoclue, I can see if any other
workarounds are possible; but the core problems are not with redshift.
Note that both GNOME and KDE Plasma now have built-in equivalents to redshift
so it's unlikely to receive any further upstream maintenance.