geoclue issueshttps://gitlab.freedesktop.org/geoclue/geoclue/-/issues2019-03-18T23:18:19Zhttps://gitlab.freedesktop.org/geoclue/geoclue/-/issues/107Add manpage for geoclue2019-03-18T23:18:19ZZeeshan Ali Khanzeeshanak@gnome.orgAdd manpage for geoclueIn addition to providing a manpage for the [config file](https://gitlab.freedesktop.org/geoclue/geoclue/issues/49), we should also provide manpages for the service itself. The content of the [home page](https://gitlab.freedesktop.org/geo...In addition to providing a manpage for the [config file](https://gitlab.freedesktop.org/geoclue/geoclue/issues/49), we should also provide manpages for the service itself. The content of the [home page](https://gitlab.freedesktop.org/geoclue/geoclue/wikis/home) could be a good starting point but the manpage is supposed to be for the service binary itself..https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/103Oxidize service code2022-01-28T09:08:14ZZeeshan Ali Khanzeeshanak@gnome.orgOxidize service codeGeoclue is a gatekeeper to one of the most sensitive of user's data: geographical location. So it's vital that the code is safe. Also, we've seen many crash reports in the recent years. So it'd be good to have the service code at least,...Geoclue is a gatekeeper to one of the most sensitive of user's data: geographical location. So it's vital that the code is safe. Also, we've seen many crash reports in the recent years. So it'd be good to have the service code at least, in a language designed for safety while not compromising on efficiency: Rust.
This task will require:
* Redesign of the code to drop the use of glib and its mainloop, in favor of an async runtime (e.g [tokio](https://github.com/tokio-rs/tokio) or [async-std](https://github.com/async-rs/async-std)) and more Rust-like code. The main difference would be to use futures and streams instead of GObject signals.
* ~~Add async support to [dbus-codegen](https://crates.io/crates/dbus-codegen/). That shouldn't be a lot of work, since [dbus-tokio](https://docs.rs/dbus-tokio/0.3.0/dbus_tokio/) already exists.~~
Since we'd want a code redesign, the service code is not a lot of LOC and it'd be nice not having to deal with FFI (and write any unsafe code as a result), I think the best way forward is to start the Rust implementation from scratch. This led me to go on a multi-year project and the result was the [zbus project](https://gitlab.freedesktop.org/dbus/zbus/-/blob/main/README.md). Starting from 2.0, it will have async API as it's main API and we can make full use of that in geoclue.
Apart from safety, there will be some other side benefits to this exercise. E.g tests (especially unit tests) are *much* easier to write in Rust than in C and during this exercise, we should ensure that we add tests for each module at least, if not for every public function of each module.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/45VPN causes invalid TimeZone to be detected2022-12-13T18:20:04ZBugzilla Migration UserVPN causes invalid TimeZone to be detected## Submitted by Christian Hergert
**[Link to original bug (#70555)](https://bugs.freedesktop.org/show_bug.cgi?id=70555)**
## Description
VPNs are often in a different timezone than the one you are presently within.
So detecting the ...## Submitted by Christian Hergert
**[Link to original bug (#70555)](https://bugs.freedesktop.org/show_bug.cgi?id=70555)**
## Description
VPNs are often in a different timezone than the one you are presently within.
So detecting the timezone when connecting over a VPN creates a likely incorrect answer.
Perhaps ignore checking when a VPN is established, unless it can be made to go
through the non-VPN network device.
https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/186Mozilla Location Service is retiring2024-03-16T11:29:24ZMarvin WMozilla Location Service is retiringAs was announced at https://github.com/mozilla/ichnaea/issues/2065, Mozilla will retire MLS soon. The final deadline for third parties seems to be set to June 12.As was announced at https://github.com/mozilla/ichnaea/issues/2065, Mozilla will retire MLS soon. The final deadline for third parties seems to be set to June 12.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/162Stop activating wpa_supplicant which is in conflict with iwd2023-10-05T19:53:05ZPeter WeberStop activating wpa_supplicant which is in conflict with iwdHello!
We've nowadays [iwd](https://iwd.wiki.kernel.org/networkmanager) as an alternative to wpa_supplicant but it must not be run in parallel:
> After this Network Manager needs to be restarted. The wpa_supplicant daemon will often s...Hello!
We've nowadays [iwd](https://iwd.wiki.kernel.org/networkmanager) as an alternative to wpa_supplicant but it must not be run in parallel:
> After this Network Manager needs to be restarted. The wpa_supplicant daemon will often still be running in the background and needs to be explicitly stopped with killall wpa_supplicant. IWD is currently not automatically started by NM, see Getting Started about starting IWD – this can be done either before or after starting NM. wpa_supplicant and IWD should not generally be active at the same time, neither will be able to manage WiFi connections correctly during the time both are active.
But since [2.1.9](https://gitlab.freedesktop.org/geoclue/geoclue/-/blob/master/NEWS#L383) geoclue tries to activate wpa_supplicant via DBus. I understand that this change was done to improve portability. But I think it prevents here portability by enforcing a specific wireless daemon and probably causing undesired side-effects.
Workarounds are maybe:
- `systemctl mask wpa_supplicant.service`
- or using a special package of [NetworkManager](https://aur.archlinux.org/packages/networkmanager-iwd) which drops the dependency on wpa_supplicant
As a consequence the D-Bus activation fails. Maybe it is better to rely upon NetworkManager or another solution?
Thank youhttps://gitlab.freedesktop.org/geoclue/geoclue/-/issues/92WiFi location scrambling could hide the location better2022-01-26T12:52:02ZSebastian KellerWiFi location scrambling could hide the location betterThe location scrambling used by the WiFi provider to provide city level accuracy currently could allow a potential attacker to obtain the unscrambled location if given enough samples of the scrambled location. Currently only the latitude...The location scrambling used by the WiFi provider to provide city level accuracy currently could allow a potential attacker to obtain the unscrambled location if given enough samples of the scrambled location. Currently only the latitude is scrambled and there are only 6 possible variations of it. The unscrambled location can be obtained by calculating the center of the two locations that are 6km apart.
Using a more fine grained random translation of the location will not solve this issue as it would still be possible to determine the center point if given enough samples.
A better way of scrambling the location would be to round the latitude to the next "full" kilometer in a 1km (or larger) grid: `latitude = round(latitude / LATITUDE_IN_KM) * LATITUDE_IN_KM`. The only way to extract more precise location information from this would require the original location to be on the grid lines such that different location requests could return different grid cells. This problem decreases the larger the grid cells become, because there are fewer grid lines.
Something similar would have to be done for longitude, which is currently not scrambled at all.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/187Support getting location from ModemManager when it is SIM locked /when the SI...2024-03-23T08:18:33ZRaphaël JakseSupport getting location from ModemManager when it is SIM locked /when the SIM is missingAt https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/183, we allowed ModemManager to enable its location interface even when it is SIM locked or when there's no SIM card.
Geoclue currently checks that ModemManager i...At https://gitlab.freedesktop.org/mobile-broadband/ModemManager/-/issues/183, we allowed ModemManager to enable its location interface even when it is SIM locked or when there's no SIM card.
Geoclue currently checks that ModemManager is in this state to go on:
- https://gitlab.freedesktop.org/geoclue/geoclue/-/blob/a9caa550df128bb04f28b3f3c94d909b0d140e15/src/gclue-modem-manager.c#L730
- https://gitlab.freedesktop.org/geoclue/geoclue/-/blob/a9caa550df128bb04f28b3f3c94d909b0d140e15/src/gclue-modem-manager.c#L774
This is right for the current version of ModemManager: if ModemManager is not ENABLED, its location interface can't be used. In the next version, this won't be correct anymore. It will be possible to use the location interface even if ModemManager is not in ENABLED state. I would guess it is sufficient to check whether the location interface is available and ready, which, if I understand correctly, is already done.
These checks would need to be removed. I don't think it would have strong drawbacks for the current version of ModemManager neither. I'd be happy to send an MR but I'm not quite familiar with Geoclue's code base and I don't know if there are other things to be careful about. On my side, removing the checks works as intended.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/184[Feature Request] Use bluetooth radio like we use wifi, to determine location2024-01-20T23:23:37ZBilly Croan[Feature Request] Use bluetooth radio like we use wifi, to determine locationWigle.net has lists of bluetooth sightings just as it does wifi APs.
Bluetooth might be more scattered and mobile than wifi APs. But there's still a lot of them. Smart speakers and TVs and door locks and appliances that never move. A...Wigle.net has lists of bluetooth sightings just as it does wifi APs.
Bluetooth might be more scattered and mobile than wifi APs. But there's still a lot of them. Smart speakers and TVs and door locks and appliances that never move. And they transmit bluetooth, and out laptops can see their MAC addresses.
This is a feature request to add a detection agent for Bluetooth signals.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/183IP Geolocation or WHOIS as a last resort2024-03-16T10:57:14ZBilly CroanIP Geolocation or WHOIS as a last resortI'm trying to help another Free Software project improve their app and have a simpler experience.
It's a current weather and weather forecast applet for cinnamon:
https://github.com/linuxmint/cinnamon-spices-applets/issues/5355
They're...I'm trying to help another Free Software project improve their app and have a simpler experience.
It's a current weather and weather forecast applet for cinnamon:
https://github.com/linuxmint/cinnamon-spices-applets/issues/5355
They're going to implement geoclue in a future version and I think that's great. Using nearby wifi to find location is an excelent solution!
But they're still concerned about managing a fallback to ip geolocation if geoclue doesn't come up with a good answer. And I'm wondering why wouldn't geoclue fall back to ip geolocation on its own if there's no better method?
Desktops for example. Home theater pcs. They might not have wifi, No gps receiver or nmea or cell phone radio.....
So how would geoclue work on them?
It seems to me that getting location detection to work, should be done by one project, and.. you're it, right?
So what about adding a pool of ip geolcoation providers as a level of available accuracy to geoclue, and another level, a whois lookup if your own IP.
Upon further reading it looks like maybe GeoIP is already used by geoclue. the manpage for geoclue doens't mention it but its got a bulletpoint on https://gitlab.freedesktop.org/geoclue/geoclue. Suggest manpage to include it even if there's no configurable options for the geoip 'agent'. Or it should indicate what other program to use to configure ip geolocationhttps://gitlab.freedesktop.org/geoclue/geoclue/-/issues/182geoclue can't connect to gpsd2023-11-30T21:10:13Zpromeneurgeoclue can't connect to gpsdopenSUSE Tumbleweed
geoclue 2.7.1
gspd is started with "-Gn" options
I checked with xgps that gpsd supplies nmea data.
I ran
avahi-publish-address grincheux.local 127.0.0.1
avahi-publish-service -H grincheux.local NMEA_SOURCE _nmea-0...openSUSE Tumbleweed
geoclue 2.7.1
gspd is started with "-Gn" options
I checked with xgps that gpsd supplies nmea data.
I ran
avahi-publish-address grincheux.local 127.0.0.1
avahi-publish-service -H grincheux.local NMEA_SOURCE _nmea-0183._tcp 2947 accuracy=exact
I ran
sudo G_MESSAGES_DEBUG=Geoclue /usr/libexec/geoclue
we see that geoclue connects to gpsd but uses only WIFI source.
(geoclue:28298): Geoclue-DEBUG: 17:37:25.422: Failed to query location: Source is inactive
(geoclue:28298): Geoclue-DEBUG: 17:37:25.426: New agent for user ID '1001'
(geoclue:28298): Geoclue-DEBUG: 17:37:25.430: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' found in domain 'local'
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' found in domain 'local'
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Network changed: Enabling locate URL queries
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Cache miss for key (99, '', 0, 0, [])
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Available accuracy level from GClueWifi: 6
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Network changed: Enabling locate URL queries
(geoclue:28298): Geoclue-DEBUG: 17:37:25.431: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' found in domain 'local'
(geoclue:28298): Geoclue-DEBUG: 17:37:25.433: Failed to query location: Source is inactive
(geoclue:28298): Geoclue-DEBUG: 17:37:25.433: Failed to query location: Source is inactive
(geoclue:28298): Geoclue-DEBUG: 17:37:25.433: Avahi Service Browser's CACHE_EXHAUSTED event occurred
(geoclue:28298): Geoclue-DEBUG: 17:37:25.615: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' in domain 'local' resolved to grincheux.local:2947
(geoclue:28298): Geoclue-DEBUG: 17:37:25.615: No. of _nmea-0183._tcp services 1
(geoclue:28298): Geoclue-DEBUG: 17:37:25.615: Scheduling NMEA accuracy level refresh
(geoclue:28298): Geoclue-DEBUG: 17:37:25.616: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' in domain 'local' resolved to grincheux.local:2947
(geoclue:28298): Geoclue-DEBUG: 17:37:25.616: NMEA service NMEA_SOURCE already exists
(geoclue:28298): Geoclue-DEBUG: 17:37:25.616: Service 'NMEA_SOURCE' of type '_nmea-0183._tcp' in domain 'local' resolved to grincheux.local:2947
(geoclue:28298): Geoclue-DEBUG: 17:37:25.616: NMEA service NMEA_SOURCE already exists
(geoclue:28298): Geoclue-DEBUG: 17:37:25.618: Available accuracy level from GClueNMEASource: 8
(geoclue:28298): Geoclue-DEBUG: 17:37:26.431: Avahi Service Browser's ALL_FOR_NOW event occurred
(geoclue:28298): Geoclue-DEBUG: 17:38:14.710: Service now in use
(geoclue:28298): Geoclue-DEBUG: 17:38:14.710: Number of connected clients: 1
(geoclue:28298): Geoclue-DEBUG: 17:38:14.716: 'geoclue-where-am-i' not in configuration
(geoclue:28298): Geoclue-DEBUG: 17:38:14.716: requested accuracy level: 8. Max accuracy level allowed by agent: 8
(geoclue:28298): Geoclue-DEBUG: 17:38:14.716: 'geoclue-where-am-i' not in configuration
(geoclue:28298): Geoclue-DEBUG: 17:38:14.716: GClueModemManager: New time-threshold: 0
(geoclue:28298): Geoclue-DEBUG: 17:38:14.716: GClueLocator now active
(geoclue:28298): Geoclue-DEBUG: 17:38:14.717: GClueNMEASource now active
(geoclue:28298): Geoclue-DEBUG: 17:38:14.717: Trying to connect to NMEA service grincheux.local:2947.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.717: GClueWifi now active
(geoclue:28298): Geoclue-DEBUG: 17:38:14.717: Connecting cache prune timeout
(geoclue:28298): Geoclue-DEBUG: 17:38:14.717: Starting WiFi scan…
(geoclue:28298): Geoclue-DEBUG: 17:38:14.720: Not starting GClue3G (accuracy level: 0). Requested accuracy level: 8.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.720: Not starting GClueCDMA (accuracy level: 0). Requested accuracy level: 8.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.720: Not starting GClueModemGPS (accuracy level: 0). Requested accuracy level: 8.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.720: Not starting GClueStaticSource (accuracy level: 0). Requested accuracy level: 8.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.720: 'geoclue-where-am-i' started.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.728: NMEA service connected.
(geoclue:28298): Geoclue-DEBUG: 17:38:14.728: Network source sent: "{"class":"VERSION","release":"3.25","rev":"3.25","proto_major":3,"proto_minor":15}"https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/181Make the agent optional2024-01-06T16:31:51ZHugoMake the agent optionalBy itself, the geoclue agent doesn't seem to really add any security in its current form.
When a client connects to geoclue and requests a location, geoclue expects an agent to connect and authorise this request. The mechanism via which...By itself, the geoclue agent doesn't seem to really add any security in its current form.
When a client connects to geoclue and requests a location, geoclue expects an agent to connect and authorise this request. The mechanism via which the client and the agent connect are exactly the same. In fact, the client requesting a location can open a second connection to geoclue, present itself as an agent, and authorise its own request (this is even what I did with my initial client implementation in golang).
It is definitely possible to tailor an environment where the agent can help secure geoclue. For example, instead of allowing a client to connect to the system bus, one might put the client behind `xdg-dbus-proxy`. In this case, an agent can be used to enhance security, but this setup requires special configuration on behalf of the system administrator, and if far from the default setup.
In practice, many users just turn to using `/usr/libexec/geoclue-2.0/demos/agent`, which allows any location request on their behalf. This is the recommendation given by the [Arch wiki](https://wiki.archlinux.org/title/Redshift#Unable_to_connect_to_GeoClue) and several downstream tools that rely on geoclue (eg: redshift, gammastep, darkman). Basically, this is a workaround for not being able to disable the requirement for an agent entirely.
This issue is a proposal to add a `--no-agent` flag for the geoclue server itself, a mode it which it requires no agent and authorised all requests implicitly. This is very similar to just using `/usr/libexec/geoclue-2.0/demos/agent`, but it is somewhat less involved, less confusing for end-users who keep asking "why do I need this agent and what does it do?" and requires one less service which honestly doesn't add anything to the equation.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/180upon exit, Geoclue does not leave modem manager settings as it found them2023-10-05T22:22:01ZColin Saneupon exit, Geoclue does not leave modem manager settings as it found themif the user has GPS or 3gpp location tracking enabled via modem manager before starting a geoclue agent, geoclue unexpectedly disables those upon exit. this causes Geoclue-based applications like Gnome Maps to not play well with other se...if the user has GPS or 3gpp location tracking enabled via modem manager before starting a geoclue agent, geoclue unexpectedly disables those upon exit. this causes Geoclue-based applications like Gnome Maps to not play well with other services which might be querying location data not through Geoclue.
for example:
1. `mmcli -m any --location-enable-3gpp`
2. `mmcli -m any --location-get`
```
--------------------------------
3GPPP | operator mcc: (clipped from paste)
| operator mnc: (clipped from paste)
| ...
```
3. `where-am-i` (or some other geoclue consumer like `gnome-maps)
4. `mmcli -m any --location-get`
```
(empty)
```
`mmcli -m any --location-status` can also be used to confirm that gps and 3gpp sources are enabled before, but not after, launching the geoclue agent.
this might be particularly problematic for GPS location sources, which often take minutes to acquire a location fix after a cold start, but there's enough complexity that the full implications of this interaction aren't easy for me to figure out. manually re-issuing the `--location-enable` commands seems to be enough to get location output working again for my particular circumstances.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/177Add a privacy mode.2023-07-24T21:35:12ZDaniel HofmannAdd a privacy mode.Geoclue (in the default configuration) leaks information to the outside world. Many users do not want that leakage. Therefore, there should exist a straightforward way to stop that information leakage.
Geoclue should have a privacy mode...Geoclue (in the default configuration) leaks information to the outside world. Many users do not want that leakage. Therefore, there should exist a straightforward way to stop that information leakage.
Geoclue should have a privacy mode.
In this mode, all active communication (e.g. with Mozilla Location Service) shall be disabled. It should be one setting and only one setting. That setting should be persisted. For starters, it could be a configuration file setting
```
[global]
privacy=true
```
Note that configuring to
```
[network-nmea]
enable=false
[3g]
enable=false
[modem-gps]
enable=true
[wifi]
enable=false
[compass]
enable=true
[static-source]
enable=false
```
is not enough to make Geoclue not leak information and thus emulate a privacy mode. However, such a configuration deceptively looks like it should be enough for that. Therefore, a separate privacy mode is needed.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/173Should not include SystemdService= in D-Bus .service file if built without sy...2023-03-14T14:40:20ZWill ThompsonShould not include SystemdService= in D-Bus .service file if built without systemd supportorg.freedesktop.GeoClue2.service.in unconditionally contains the following line:
```ini
SystemdService=geoclue.service
```
However, if at build time GeoClue cannot determine the correct directory to install systemd units, the [`geoclue...org.freedesktop.GeoClue2.service.in unconditionally contains the following line:
```ini
SystemdService=geoclue.service
```
However, if at build time GeoClue cannot determine the correct directory to install systemd units, the [`geoclue.service` systemd unit is not installed](https://gitlab.freedesktop.org/geoclue/geoclue/-/blob/bbfb6289dedb88cb8155d9f6868787d5432e1f90/data/meson.build#L59-64).
In this configuration it is not possible to D-Bus activate GeoClue, because the D-Bus daemon will emit a signal telling systemd to activate `geoclue.service`, and systemd will not be able to do so. See https://gitlab.gnome.org/GNOME/gnome-shell/-/merge_requests/2689 for an example of this issue in the wild.
While installing a GeoClue built without systemd support on a system that does actually use systemd could probably be classed as a misconfiguration, it is at least theoretically supported. So I believe that the `SystemdService` line should be included if and only if the `geoclue.service` systemd unit is being installed.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/170Clear vs. Concise HACKING.md2022-12-20T14:02:10ZS BClear vs. Concise HACKING.mdHi folks,
It might be a matter of taste. Anyhow, there is a way to write `HACKING.md` more concise.Hi folks,
It might be a matter of taste. Anyhow, there is a way to write `HACKING.md` more concise.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/168Is GeoclueShare unmaintaned?2023-06-22T12:40:28ZCarlo CastoldiIs GeoclueShare unmaintaned?GeoclueShare seems to work—it connects to `geoclue` and it sends NMEA data, but due to [this bug](https://github.com/ankitstarski/GeoclueShare/issues/7) it's unusable outside the US. I couldn't manage to build an APK because, even with [...GeoclueShare seems to work—it connects to `geoclue` and it sends NMEA data, but due to [this bug](https://github.com/ankitstarski/GeoclueShare/issues/7) it's unusable outside the US. I couldn't manage to build an APK because, even with [this PR](https://github.com/ankitstarski/GeoclueShare/pull/9), the SDK version is too old for my Android Studio installation. I'm not an Android deleloper myself, and I don't think I have now time to study how to upgrade the project to a newer SDK.
Should we consider it dead and remove its references from this repo and GNOME's apps?https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/165Uses 3GPP data from a disabled modem in location queries2022-10-26T13:20:29ZTeemu IkonenUses 3GPP data from a disabled modem in location queriesGeoClue does not invalidate its 3GPP tower data when a modem supplying this data is disabled, but will keep submitting the old data forever (or until the modem is enabled again and receives new data) in MLS location queries.
There is a ...GeoClue does not invalidate its 3GPP tower data when a modem supplying this data is disabled, but will keep submitting the old data forever (or until the modem is enabled again and receives new data) in MLS location queries.
There is a `on_mm_modem_state_notify ()` function in gclue-modem-manager.c, but it's disconnected when the modem is found to be in enabled state and does not detect disabling.
The modem state notify callback should be kept connected all the time and the `clear_3gpp_location ()` function called when the modem is disabled.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/157Wifi source makes unnecessary scans and queries2022-01-26T12:52:01ZTeemu IkonenWifi source makes unnecessary scans and queriesA standard Gnome installation has some programs which want to know the low accuracy location occasionally, like once per hour. At least 'gsd-color' from gnome-settings-daemon, which presents itself as 'gnome-color-panel' to GeoClue is su...A standard Gnome installation has some programs which want to know the low accuracy location occasionally, like once per hour. At least 'gsd-color' from gnome-settings-daemon, which presents itself as 'gnome-color-panel' to GeoClue is such a program.
A wifi location source is used to provide a location in this case, if it exists, but even the low accuracy version of this source runs wifi scans and MLS queries every 300 s.
GeoClue should do proper multiplexing of client time-thresholds, and perform scans and queries only when needed.
There was some hand-waving towards fixing this in !103, but fixing this requires more than that.https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/152No documentation exists on how to configure [network-nmea] source2021-10-31T16:04:03ZAaron BockelieNo documentation exists on how to configure [network-nmea] sourceThere is simply an "enable=true" keypair to enable network-nmea source. I have a specific host sending udp NMEA sentences to specific hosts with a specific port.
What is the configuration example to instruct geoclue to listen to that ud...There is simply an "enable=true" keypair to enable network-nmea source. I have a specific host sending udp NMEA sentences to specific hosts with a specific port.
What is the configuration example to instruct geoclue to listen to that udp traffic from that host and port?https://gitlab.freedesktop.org/geoclue/geoclue/-/issues/151At startup, geoclue doesnt no respond until restarted2022-10-26T10:52:17ZHugoAt startup, geoclue doesnt no respond until restartedI've a few services relying on geoclue (gammastep, darkman) and I'm using the demo agent.
When the system starts up, both services request the location, but geoclue never responds.
Restarting the agent and then restarting any client, g...I've a few services relying on geoclue (gammastep, darkman) and I'm using the demo agent.
When the system starts up, both services request the location, but geoclue never responds.
Restarting the agent and then restarting any client, geoclue still does not response any location.
After restarting geoclue.service itself, geoclue _does_ resolve locations.
I don't see any verbosity flags on `geoclue`, how can I figure out what's wrong? Any ideas what might be up or what to check?