Bug 22160 - When compiled without network manager (or Conic) all providers are unavailable
Summary: When compiled without network manager (or Conic) all providers are unavailable
Status: RESOLVED FIXED
Alias: None
Product: GeoClue
Classification: Unclassified
Component: General (show other bugs)
Version: unspecified
Hardware: Other All
: medium normal
Assignee: arno
QA Contact: Geoclue Bugs
URL:
Whiteboard:
Keywords:
Depends on:
Blocks:
 
Reported: 2009-06-08 11:49 UTC by Pierre-Luc Beaudoin
Modified: 2010-03-25 14:48 UTC (History)
1 user (show)

See Also:
i915 platform:
i915 features:


Attachments
patch v1 (944 bytes, patch)
2010-02-19 05:48 UTC, arno
Details | Splinter Review
patch v1.1 (1013 bytes, patch)
2010-02-19 09:07 UTC, arno
Details | Splinter Review

Note You need to log in before you can comment on or make changes to this bug.
Description Pierre-Luc Beaudoin 2009-06-08 11:49:58 UTC
When Geoclue is built without network-manager or conic (like the debian packages), geoclue will never use HostIP as it thinks that it is offline.

On Tue, 2008-12-16 at 19:58 +0200, Jussi Kukkonen wrote:
> geoclue_master_client_set_requirements() has a parameter 
> "require_updates". Setting that to FALSE should make the master client 
> use network based providers even without networkmanager or conic (there 
> won't be "changed" signals of course), but now that I test it doesn't 
> seem to work. I'll look into it and let you know.

I didn't hear back from him so I am opening this bug as this is still reproducible.  I think that the providers should report online by default if neither network manager or conic are available.
Comment 1 arno 2010-02-19 05:48:52 UTC
Created attachment 33418 [details] [review]
patch v1

Here is a fix proposal. It sets net_status to online, and status to available if connectivity object is null. I also had to unset GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION bit, because otherwise, provider was never initialized (or more precisely, it was initialized, and uninitialized right after; then geoclue_position_get_position never succeeded). But, as I didn't understood GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION bit totally, maybe that's not the right way. Feel free to tell me if/how I can improve this fix.
Comment 2 Jussi Kukkonen [inactive] 2010-02-19 06:34:05 UTC
(In reply to comment #1)
> Created an attachment (id=33418) [details]
> patch v1
> 
> Here is a fix proposal. It sets net_status to online, and status to available
> if connectivity object is null. I also had to unset
> GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION bit, because otherwise, provider was
> never initialized (or more precisely, it was initialized, and uninitialized
> right after; then geoclue_position_get_position never succeeded). But, as I
> didn't understood GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION bit totally, maybe
> that's not the right way. Feel free to tell me if/how I can improve this fix.
> 

Yeah, something like this... the if-clause should probably be 
    if (!connectivity && priv->required_resources & GEOCLUE_RESOURCE_NETWORK)
so only network providers get enabled but the whole iterative selection process is just so damn complex that debugging is a mess.

GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION means the providers data will not change as long as the network connection does not change (anything based on router MAC address or IP). This should only be applied to wired and wlan connections though, that's a bug.

Something still goes wrong in the selection process after the patch: it picks a zero-accuracy provider here. I'll see what I can do over the weekend.
Comment 3 arno 2010-02-19 09:07:43 UTC
Created attachment 33425 [details] [review]
patch v1.1

(In reply to comment #2)

> Yeah, something like this... the if-clause should probably be 
>     if (!connectivity && priv->required_resources & GEOCLUE_RESOURCE_NETWORK)
> so only network providers get enabled but the whole iterative selection process
> is just so damn complex that debugging is a mess.

Of course!
Here is an updated patch

> GEOCLUE_PROVIDE_CACHEABLE_ON_CONNECTION means the providers data will not
> change as long as the network connection does not change (anything based on
> router MAC address or IP). This should only be applied to wired and wlan
> connections though, that's a bug.

ok.

> Something still goes wrong in the selection process after the patch: it picks a
> zero-accuracy provider here. I'll see what I can do over the weekend.


I don't understand that one. Where in the code is that ?
Comment 4 arno 2010-03-04 08:21:37 UTC
do you have any updates about patch v1.1 ? are there any things that needs improvements in this fix proposal ?
Comment 5 Jussi Kukkonen [inactive] 2010-03-25 14:48:06 UTC
thanks, this is in master now. I couldn't find locate the related bug I mentioned but that should not stop this code.

I'll try to release Very Soon Now.


Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct.