Here is a line that allows Redshift to work: https://github.com/jonls/redshift/issues/158#issuecomment-71329118

Wrong geoclue

(In reply to kxra from comment #1)
> Here is a line that allows Redshift to work:
> https://github.com/jonls/redshift/issues/158#issuecomment-71329118

That line should not be needed. I recall I fixed something regarding this not so long ago. Could you please make sure you have the latest geoclue package (i-e 2.2.0)?

Just FYI, geoclue was only updated very recently so please do reproduce again just to ensure that issue really is reproducible against latest geoclue.

I can reproduce with the latest geoclue2 package in Fedora 22.

  geoclue2-2.2.0-1.fc22.x86_64

Redshift produces the error messages below, then immediately dies.

    [chadv@aplomb ~]$ redshift -o |& tee redshift.log
    Trying location provider `geoclue2'...
    Using provider `geoclue2'.
    Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.
    Unable to connect to GeoClue.
    Unable to get location from provider.
    [chadv@aplomb ~]$
                          
On my system, /etc/geoclue/geoclue.conf is the unmodified provided by the geoclue2 package.

    [root@aplomb etc]# md5sum /etc/geoclue/geoclue.conf 
    d63a46c3d7bb9ba5393f92f781cdddbc  /etc/geoclue/geoclue.conf

I confirmed that adding these lines to geoclue.conf, as described in the Github issue [1], fixes the issue:

    [redshift]
    allowed=true
    system=false
    users=

[1] https://github.com/jonls/redshift/issues/158#issuecomment-71329118

Just tested on Fedora 21 and clean install gives the same errors. What was fixed in geoclue?

Using:
geoclue2-2.1.10-2.fc21.x86_64
redshift-1.10-1.fc21.x86_64

If Geoclue's package maintainer decides to fix the bug by patching geoclue.conf, then I think redshift should be marked as a trusted system component. Unlike Chromium or a web app, the user can trust redshift to not hand over location information to advertisers ;).

One more voice to agree that it would be great if our geoclue2 maintainer would add redshift as trusted by default. After all, if we can trust epiphany and firefox by default, I'd argue we can trust the comparitively simpler [code-base of] redshift.

(In reply to Ryan Sawhill from comment #8)
> One more voice to agree that it would be great if our geoclue2 maintainer
> would add redshift as trusted by default.

There shouldn't be any need for that. You're likely hitting the issue of desktop file: You need to have a desktop file installed and also inform geoclue it's ID: http://www.freedesktop.org/software/geoclue/docs/gdbus-org.freedesktop.GeoClue2.Client.html#gdbus-property-org-freedesktop-GeoClue2-Client.DesktopId .

This is checked by agent (gnome-shell) and not geoclue btw. In future[1], these desktop ids will be important to identify apps.

[1] https://wiki.gnome.org/Projects/SandboxedApps

(In reply to Chad Versace from comment #7)
> If Geoclue's package maintainer decides to fix the bug by patching
> geoclue.conf, then I think redshift should be marked as a trusted system
> component. Unlike Chromium or a web app, the user can trust redshift to not
> hand over location information to advertisers ;).

The idea is that at some point agents will get the ability to reliably identify apps and will ask user if they want to share their location. Currently agent only checks if desktop file is installed. This configuration in geoclue.conf is about apps that agent will not be asked about.

When agents start asking users, this will mean two notifications in case of web apps, that have their own mechanism for this in place as location is usually accessed by web pages rather than web browser itself. So  Apart from web browsers, we only add apps there that we know, only access location on user's explicit demand or need for user location is very central to it's core features (e.g gnome-maps).

(In reply to Jakub Jelen from comment #6)
> Just tested on Fedora 21 and clean install gives the same errors. What was
> fixed in geoclue?

I backported some fixes from 2.2 release, mainly one that should allow geolocation to work on system/environment w/o any agent.

I'll try to reproduce here to invetigate but in the meantime could you please check if redshift installs desktop file and geoclue's property is properly set before starting the client as pointed out in comment#9?

Oh and could you please also ensure that you have geolocation enabled under privacy settings?

(In reply to Zeeshan Ali from comment #13)
> Oh and could you please also ensure that you have geolocation enabled under
> privacy settings?

I'm asking cause I just tried against gnome-maps on F21 VM and at first it got the same error but then I enabled geolocation in settings and then it worked like a charm.

Hi! I noticed this got marked as NEEDINFO. I've been running into this with my Fedora system. So:
No, unfortunately enabling the Geolocation settings doesn't make a difference. The only fix I've found so far is adding the line mentioned here to the settings for geoclue.conf. This bug also still seems to be present on F22 unfortunately :(
In addition, I can confirm that redshift-gtk does in fact install the desktop file that's needed:

whitewolf%:~> rpm -ql redshift-gtk | grep desktop
/usr/share/applications/redshift-gtk.desktop

As for checking if the attribute is being set properly by redshift-gtk itself like you mentioned in comment #9, how would I go about checking this?

(In reply to Stephen Chandler Paul from comment #15)
> Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> my Fedora system. So:
> No, unfortunately enabling the Geolocation settings doesn't make a
> difference. The only fix I've found so far is adding the line mentioned here
> to the settings for geoclue.conf. This bug also still seems to be present on
> F22 unfortunately :(
> In addition, I can confirm that redshift-gtk does in fact install the
> desktop file that's needed:
> 
> whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> /usr/share/applications/redshift-gtk.desktop

Interesting. I really don't know then. :( I see it's working fine for all the other apps in f22. If you have the latest geoclue (2.2.0) then my only guess is that DesktopId property is not set:

> As for checking if the attribute is being set properly by redshift-gtk
> itself like you mentioned in comment #9, how would I go about checking this?

By looking at the source code to see if it does that? It should be doing something like this: http://cgit.freedesktop.org/geoclue/tree/demo/where-am-i.c#n313

I see the same issue with geoclue-2.2.0

$ sudo G_MESSAGES_DEBUG=Geoclue /usr/local/lib/geoclue-2.0/geoclue -t 60

(geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 4
(geoclue:18146): Geoclue-DEBUG: WiFi device 'wlan0' added.
(geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 6
(geoclue:18146): Geoclue-DEBUG: New agent for user ID '1001'
(geoclue:18146): Geoclue-DEBUG: Number of connected clients: 1
(geoclue:18146): Geoclue-DEBUG: 'org.gnome.Maps' not in configuration

..which is fixed by adding this to geoclue.conf

[org.gnome.Maps]
allowed=true
system=false
users=

(In reply to john.frankish from comment #17)
> I see the same issue with geoclue-2.2.0
> 
> $ sudo G_MESSAGES_DEBUG=Geoclue /usr/local/lib/geoclue-2.0/geoclue -t 60
> 
> (geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 4
> (geoclue:18146): Geoclue-DEBUG: WiFi device 'wlan0' added.
> (geoclue:18146): Geoclue-DEBUG: Available accuracy level from GClueWifi: 6
> (geoclue:18146): Geoclue-DEBUG: New agent for user ID '1001'
> (geoclue:18146): Geoclue-DEBUG: Number of connected clients: 1
> (geoclue:18146): Geoclue-DEBUG: 'org.gnome.Maps' not in configuration
> 
> ..which is fixed by adding this to geoclue.conf
> 
> [org.gnome.Maps]
> allowed=true
> system=false
> users=

Thanks John. Although it probably isn't relevant but just in case it is, John is on a non-Fedora (non-systemd) OS.

(In reply to Stephen Chandler Paul from comment #15)
> Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> my Fedora system. So:
> No, unfortunately enabling the Geolocation settings doesn't make a
> difference. The only fix I've found so far is adding the line mentioned here
> to the settings for geoclue.conf. This bug also still seems to be present on
> F22 unfortunately :(
> In addition, I can confirm that redshift-gtk does in fact install the
> desktop file that's needed:
> 
> whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> /usr/share/applications/redshift-gtk.desktop
> 
> As for checking if the attribute is being set properly by redshift-gtk
> itself like you mentioned in comment #9, how would I go about checking this?

Ok, If I'm looking at the right sources, redshift is not setting the correct destkop ID:

http://bazaar.launchpad.net/~jonls/redshift/master/view/head:/src/location-geoclue2.c#L199

This should be 'redshift-gtk' rather than 'redshift' if desktop file is called 'redshift-gtk.desktop'. Could you please confirm this information?

(In reply to Zeeshan Ali from comment #19)
> (In reply to Stephen Chandler Paul from comment #15)
> > Hi! I noticed this got marked as NEEDINFO. I've been running into this with
> > my Fedora system. So:
> > No, unfortunately enabling the Geolocation settings doesn't make a
> > difference. The only fix I've found so far is adding the line mentioned here
> > to the settings for geoclue.conf. This bug also still seems to be present on
> > F22 unfortunately :(
> > In addition, I can confirm that redshift-gtk does in fact install the
> > desktop file that's needed:
> > 
> > whitewolf%:~> rpm -ql redshift-gtk | grep desktop
> > /usr/share/applications/redshift-gtk.desktop
> > 
> > As for checking if the attribute is being set properly by redshift-gtk
> > itself like you mentioned in comment #9, how would I go about checking this?
> 
> Ok, If I'm looking at the right sources, redshift is not setting the correct
> destkop ID:
> 
> http://bazaar.launchpad.net/~jonls/redshift/master/view/head:/src/location-
> geoclue2.c#L199
> 
> This should be 'redshift-gtk' rather than 'redshift' if desktop file is
> called 'redshift-gtk.desktop'. Could you please confirm this information?

I actually see that at 'redshift.desktop' is also installed by Redshift, so if the version of Redshift in F22 contains this patch:

http://bazaar.launchpad.net/~jonls/redshift/master/revision/268.1.1

I'm once again stumped. I looked through code again and found a minor issue but nothing relevant to these two cases, reported here. :(

Still exists this bug.

Fixed by adding the lines, as suggested in the comments, to /etc/geoclue/geoclue.conf

[redshift]
allowed=true
system=false
users=

Just installed redshift-1.10.1.fc22, found that even after enabling "Location Services" in the "Privacy" settings, it still showed the same error. Looked through redshift's issue and came across this: https://github.com/jonls/redshift/issues/158#issuecomment-132177476

So created the `redshift.desktop` as suggested there. And the error is gone. Also tried with not having that desktop file and using `redshift-gtk` also shows the same error. So having that `redshift.desktop` also makes `redshift-gtk` work fine.

(In reply to Ye Myat Kaung from comment #22)
> Just installed redshift-1.10.1.fc22, found that even after enabling
> "Location Services" in the "Privacy" settings, it still showed the same
> error. Looked through redshift's issue and came across this:
> https://github.com/jonls/redshift/issues/158#issuecomment-132177476
> 
> So created the `redshift.desktop` as suggested there. And the error is gone.
> Also tried with not having that desktop file and using `redshift-gtk` also
> shows the same error. So having that `redshift.desktop` also makes
> `redshift-gtk` work fine.

Thanks. So looking at the packaging, it seems the .spec file does not install the redshift.desktop file but only redshift-gtk.desktop. So either .spec file should also install the redshift.destkop file or sources need to specify redshift-gtk file to geoclue.

Similar findings on my Fedora 22 workstation:

Two executables are provided by the two redshift packages:
* redshift-1.10-1.fc22.x86_64 --> /usr/bin/redshift
* redshift-gtk-1.10-1.fc22.x86_64 --> /usr/bin/redshift-gtk

Only a single desktop file is provided by the 2nd package for the 2nd executable:
* redshift-gtk-1.10-1.fc22.x86_64 --> /usr/share/applications/redshift-gtk.desktop


On a vanilla Fedora 22 system both commands fail with this message:

$ redshift
Trying location provider `geoclue2'...
Using provider `geoclue2'.
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Access denied.
Unable to connect to GeoClue.
Unable to get location from provider.
$ 


Adding a redshift.desktop file immediatly fixes the problem for both executables:

$ sudo cp /usr/share/applications/redshift-gtk.desktop /usr/share/applications/redshift.desktop
$ 
$ redshift
Trying location provider `geoclue2'...
Using provider `geoclue2'.
Using method `randr'.
$ 

My guess is that redshift-gtk doesn't call geoclue2 itself. Instead it spawns redshift which does all the actual work. Since redshift lacks a desktop file, it does not have access to geoclue2. If I'm right, what's the proper way of fixing this issue? Adding a redshift.desktop file or changing redshift-gtk.desktop to redshift.desktop? Neither really make sense. It looks like desktop files are used by different subsystems for different reasons, providing an entry point for launching front-end software (redshift-gtk) or handling access of back-end software (redshift) to system resources. The requirements of each subsystem do not seem consistent.

See latest comment in upstream GitHub project:
  https://github.com/jonls/redshift/issues/158#issuecomment-154043492

The redshift.desktop file has already been added to redhsift:
  https://github.com/jonls/redshift/commit/3bb7a985

There has been no formal release that integrates this patch. Maybe Fedora should backport it to the current release.

Still there in Fedora 23.

(In reply to Dimitri Papadopoulos from comment #24)
> Similar findings on my Fedora 22 workstation:
> 
> Two executables are provided by the two redshift packages:
> * redshift-1.10-1.fc22.x86_64 --> /usr/bin/redshift
> * redshift-gtk-1.10-1.fc22.x86_64 --> /usr/bin/redshift-gtk
> 
> Only a single desktop file is provided by the 2nd package for the 2nd
> executable:
> * redshift-gtk-1.10-1.fc22.x86_64 -->
> /usr/share/applications/redshift-gtk.desktop

That's the problem right there. Everything will work fine if redshift package also distributed it's .desktop file.

(In reply to Dimitri Papadopoulos from comment #25)
> See latest comment in upstream GitHub project:
>   https://github.com/jonls/redshift/issues/158#issuecomment-154043492
> 
> The redshift.desktop file has already been added to redhsift:
>   https://github.com/jonls/redshift/commit/3bb7a985
> 
> There has been no formal release that integrates this patch. Maybe Fedora
> should backport it to the current release.

AFAICT, the package is not exactly using a release tarball but rather asking github to hand over a tarball containing sources of a particular commit. We just need to bump the commit I'd guess?

There are more formal releases from time to time, the last one being release 1.10 back in January 2015:
  https://github.com/jonls/redshift/releases

I agree even such releases are automatically created from a particular GitHub commit - a particular tag to be more precise. So yes, you could download the master.tar.gz tarball, as automatically created by GitHub from the latest commit in the master branch. Now I don't know how stable/buggy the current master branch is - as opposed to a formal release. My opinion on the subject doesn't really count, I'm only an end user.

redshift-1.10-4.fc23 has been submitted as an update to Fedora 23. https://bodhi.fedoraproject.org/updates/FEDORA-2015-53169cd291

redshift-1.10-4.fc22 has been submitted as an update to Fedora 22. https://bodhi.fedoraproject.org/updates/FEDORA-2015-329c6c59e4

redshift-1.10-4.fc21 has been submitted as an update to Fedora 21. https://bodhi.fedoraproject.org/updates/FEDORA-2015-2b72345bc4

redshift-1.10-4.fc23 has been pushed to the Fedora 23 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-53169cd291

Works for me after upgrading. Thanks!

redshift-1.10-4.fc21 has been pushed to the Fedora 21 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-2b72345bc4

redshift-1.10-4.fc22 has been pushed to the Fedora 22 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
$ su -c 'dnf --enablerepo=updates-testing update redshift'
You can provide feedback for this update here: https://bodhi.fedoraproject.org/updates/FEDORA-2015-329c6c59e4

Working after updating to the testing, no changes required to geoclue.

redshift-1.10-4.fc23 has been pushed to the Fedora 23 stable repository. If problems still persist, please make note of it in this bug report.

redshift-1.10-4.fc22 has been pushed to the Fedora 22 stable repository. If problems still persist, please make note of it in this bug report.

For what it's worth, redshift stopped working yesterday on my workstation, again:

$ redshift-gtk 
Gtk-Message: GtkDialog mapped without a transient parent. This is discouraged.
$ 

An error dialog appears that displays:

Failed to run Redshift
Trying location provider `geoclue2'...
Unable to start GeoClue client: GDBus.Error:org.freedesktop.DBus.Error.AccessDenied: Geolocation disabled for UID 1000.
Unable to connect to GeoClue.
Unable to get location from provider.

Yet all *.desktop files are provided:

$ rpm -qf /usr/share/applications/redshift-gtk.desktop
redshift-gtk-1.11-1.fc23.x86_64
$ rpm -qf /usr/share/applications/redshift.desktop
redshift-1.11-1.fc23.x86_64
$ 

I'll open a new bug report because symptoms are similar but the reason seems slightly different.