New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
redshift disallowed from using GeoClue #636
Comments
|
I can reproduce this on Arch Linux running cinnamon. I also had an issue with "UnknownMethod" errors. I fixed the issue by downgrading to geoclue2 v2.4.7-1. Perhaps redshift is using some deprecated methods in geoclue2 that were removed with the latest update? |
|
It seems like the issue is that on the part of the code that works with geoclue, on the line 247, this piece of code is returning ret_v = g_dbus_proxy_call_sync(geoclue_client, "Start", NULL, G_DBUS_CALL_FLAGS_NONE, -1, NULL, &error);I'll try to check if I can find the root of the issue, knowing that downgrading geoclue fixes the issue. |
|
I am using KDE, after adding Redshift to system tray, it works, before that it wasn't. |
|
Same here, in Arch Linux with KDE. Problems started after updating the |
|
I'm using the applet and it doesn't help at all. With a little Google-fu I was able to find that this is a pretty consistent issue and found others who suggested it's a bug in geoclue itself but I can't verify that. I'm going to try rolling back to an earlier version and see what happens. Edit: I used https://archive.org/download/archlinux_pkg_geoclue2/geoclue2-2.4.4-1-x86_64.pkg.tar.xz and it's working perfectly! |
|
It looks like geoclue crashes, before redshift start, |
|
I can confirm this on Arch with i3wm and redshift-gtk in i3 autostart using the |
|
I can confirm that on my Fedora 28 box, downgrading geoclue2 from 2.4.10 to 2.4.8 allows the geoclue service to run and allows |
|
There is a patch in git master that hopefully helps here. I was going to roll out a release but i was waiting on the new meson build to be tested a bit before i make the first release with meson build system. But since this patch is important, I'll roll out a release already today. Here is the PR in question: https://gitlab.freedesktop.org/geoclue/geoclue/merge_requests/6 |
|
I run Arch and have been affected by this - looking forward to the new release. In the meantime here's my workaround (if you don't want to/can't downgrade geoclue2; you'll need #!/bin/bash
# This script fetches lat and long information from Mozilla's geolocation service. It then passes
# lat and long to redshift-gtk. If geolocation service is not available (e.g. no internet
# connection, service down) it sleeps and retries.
# URL taken from geoclue2. It returns JSON document with LAT and LONG.
URL="https://location.services.mozilla.com/v1/geolocate?key=16674381-f021-49de-8622-3021c5942aff"
# LAT and LONG numbers in the following format: "LAT:LON"
COORDS=""
function get_geolocation() {
exit_status=1
retry_times=30
sleep_time=15
while [ $exit_status -ne 0 ] && [ $retry_times -gt 0 ]; do
sleep $sleep_time
echo "Trying to fetch geolocation coordinates from $URL"
json_coords=$(curl -s $URL)
exit_status=$?
retry_times=$((retry_times - 1))
done
echo "Received: $json_coords"
COORDS=$(jq -c -r '[.location.lat, .location.lng] | @csv' <<< $json_coords | sed 's/,/:/')
}
get_geolocation
if [ -z "$COORDS" ]; then
echo "Unknown Error: LAT and LONG not set. Is JSON response malformed or has a different schema?"
exit 1
fi
redshift-gtk -l $COORDSI use awesome-wm and have replaced |
|
Same issue here, running Arch with awesome-wm. Waiting eagerly for the fix!!! |
|
@TerminalWitchcraft Have you updated to EDIT : Also trusting redshift like in the OP and adding geoclue to startup like in the post below. |
|
Hello. In my case I think it has been solved for me by making a symbolic link of the file: |
|
@LongLVNH @yochananmarqos than your DE is not XDG-compliant and that's a pretty major bug. Please report it to them because geoclue (and other freedesktop.org software) rely on this compliance. |
|
@zeenix Of course Cinnamon is xdg compliant. I'm using Manjaro. |
|
@yochananmarqos that's great. I think i tagged you by accident. I was talking to @LongLVNH, whose desktop is obviously not compliant if he had to move the desktop file to his home director for autostart to work. |
|
Thank you @zeenix. Indeed that is the case ( Plasma is not XDG compliant ). I know about XDG but did not know that Plasma was not compliant with it. In my case I read in #318 that the demo agent needed to be executed. Then inspected the contents of the package geoclue2 and found that XDG file. Also I have reported the bug at KDE ( https://bugs.kde.org/show_bug.cgi?id=310657 ). |
|
Well, you commented on an old, slightly related one. Someone there answered:
And indeed, when you check the file list of baloo you see |
|
@LongLVNH @flying-sheep it might be a timing issue. i-e Plasma could be launching the desktop files from home dir before it launches from /etc. |
|
seems likely! desktop files aren’t systemd units with dependencies and so on. why is geoclue started via autostart and not systemd? it doesn’t seem like a desktop-only service. |
|
So on popular demand, I just rolled out a new release with the fix: http://www.freedesktop.org/software/geoclue/releases/2.4/geoclue-2.4.11.tar.xz |
|
I've just tested it out, and it works like a charm. Thank you @zeenix! One last thing: I've noticed that every time I start redshift I'm asked to allow location access. Is this intentional? |
|
@Myl0g no problem. Thanks for testing. The UI you see now is a demo agent and not a full fledged one, that should be provided by your DE (if they care about your privacy). It's not just about saving the user's preference for each app but also allowing them to:
If you believe in the DE you choose and you agree with me, please do file bugs on your DE about implementing an agent. |
|
@zeenix I switched to XFCE in the middle of all this. I’ll look into my options, see if I can fix it myself, and I’ll file bugs if I can’t. Thank you! |
|
The geoclue package in the official Arch repositories has been flagged out of date. Hope they will update to the latest version soon. Currently still on version 2.4.10-1 |
|
If you want it right now, here's my PKGBUILD for it: The only difference is the |
|
Downgrading the package works, thanks. Mate Desktop here, Arch x64. |
|
Update to 2.4.11 didn't solve the problem. Fedora 28 x64, KDE Plasma 5.13 |
|
@flying-sheep Sorry, i had missed your question about launch. Geoclue is launched with systemd, as it should be. It's the demo agent that is being launched through autostart cause agents are per-user instances. @Latesil :( does this workaround helps? #636 (comment) It really shouldn't be needed with the new geoclue release but let's see. |
|
I'm still seeing a crash with 2.4.11-1 on Arch Linux, no DE. |
|
Starting the demo agent manually appears to fix the crashing issue, although now every time I start redshift, I get a notification asking if I'd like to allow it to access my location. EDIT: Adding to the |
|
@dsemi Probably the same as https://gitlab.freedesktop.org/geoclue/geoclue/issues/69 and since it happens on geoclue exiting, it's not as bad as it sounds. I really want to fix these bugs but I'm not paid to work on Geoclue currently. See #636 (comment) for why you're being asked all the time. Your fix is a hack. I would suggest you instead shout at your DE to do the right thing or use a desktop that cares about your privacy (GNOME). |
|
Anyway, this is not a redshift issue and discussion has continued here for long enough. If people have issues, please file issues/comment on geoclue: https://gitlab.freedesktop.org/geoclue/geoclue/issues . Thanks. Can someone from Redshift devs, close this issue? |
|
I'm not so sure there isn't a redshift issue here as well as a geoclue issue. Like @dsemi, I'm using redshift without any DE, and in one of my many tests (probably using ltrace or strace) I got an indication that things were hanging when trying to update a status icon. No DE ==> No icon. I can't remember details of what I was trying - I just gave up because the hang occurred in a Python script and I don't know Python. |
|
@stpeters00 if you are using geoclue from a console-only env, you are mostly likely the admin yourself and hence editing the config file is a completely ok solution: #636 (comment) . I had missed the fact that @dsemi is not using a DE, sorry. I'm not sure what you mean by no icon, geoclue doesn't require any icons or UI. |
|
@zeenix About a week ago you posted "...geoclue (and other freedesktop.org software) rely on this compliance" where "this compliance" apparently meant XDG compliance. I read this as implying geoclue relies on there being a DE. That was reinforced by a lot of the chatter around geoclue and redshift issues involving various .desktop files, which should be irrelevant in the absence of a DE. Note also that not having a DE does not imply console-only, unless you consider X plus a window manager to be a DE. I use X + fvwm to give me a setup with multiple virtual displays. Editing config files is indeed acceptable for me if there's documentation to guide me, but having geoclue refuse to run for mysterious reasons is not ok. Fortunately, downgrading to 2.4.8 works for me, but someday a new release of geoclue might have something I want, so I see downgrading as a short-term workaround. |
|
Same here for Arch: with inside |
|
@stpeters00 Well, I have nothing against people using whatever software or configuration they wish but please don't expect others to cater for your personal preferences. Having said that, I did not think about console-only setup with the recent changes (and neither did the other dev) and I apologize for that. The change to reject all clients when agent is not present, on it's own was needed to plug a security hole, where any client could get location w/o user's permission (or even worse: despite user have explicitly chosen not to give permission to the app in question) before an agent could be registered with geoclue. I should have provided a simple console-only agent (which would work for you too). |
|
Same issue running i3wm and Manjaro, and the geoclue.conf didn't fix my issue |
|
Same here. And with: in the P.S. Found a "solution": start the |
|
Please take a look at the comments posted by @zeenix above. In summary:
UPDATE: |
While googling around has showed me this exact same issue multiple times, this is the only instance of this issue where even when modifying the geoclue config file doesn't seem to work properly.
I'm running Arch Linux, and I've been trying to get redshift to work using both the (Arch Wiki article about redshift)[https://wiki.archlinux.org/index.php/Redshift], the redshift FAQ and the numerous issue reports related.
The following snippet has been added at the end of
etc/geoclue/geoclue.confI've restarted the system several times after changing the geoclue configuration, and I've also tried to run redshift both with the systemd unit service and manually from the terminal, but both have the same effect.
I've also tried to change the geoclue config to the following one, with no luck.
My desktop environment is i3wm, which doesn't have any sort of location settings that could be disabled. Redshift has been installed from the official arch repositories, so there shouldn't be any issue regarding a wrong installation, but I also installed the git version just in case, with the same results.
The redshift version I'm using is 1.12, and the version of geoclue installed is 2.4.10-1.
Let me know if I can add any more info that could be relevant to the issue at hand.
The text was updated successfully, but these errors were encountered: