After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 725126 - Maps doesn't load tiles
Maps doesn't load tiles
Status: RESOLVED FIXED
Product: libchamplain
Classification: Core
Component: map-sources
0.12.x
Other Linux
: Normal major
: ---
Assigned To: libchamplain-maint
libchamplain-maint
Depends on:
Blocks:
 
 
Reported: 2014-02-25 10:15 UTC by Mattias Bengtsson
Modified: 2015-02-10 00:49 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
Use SoupSession API to get default proxy resolving (2.46 KB, patch)
2014-02-25 15:44 UTC, Jonas Danielsson
rejected Details | Review
Update documentation of proxy-uri property. (2.00 KB, patch)
2014-02-25 15:44 UTC, Jonas Danielsson
committed Details | Review
Update required version of libsoup (1.23 KB, patch)
2014-02-25 15:44 UTC, Jonas Danielsson
committed Details | Review
Do not depend on libsoup-gnome-2.4 (7.05 KB, patch)
2014-02-25 15:44 UTC, Jonas Danielsson
none Details | Review
Do not depend on libsoup-gnome-2.4 (7.06 KB, patch)
2014-02-25 15:46 UTC, Jonas Danielsson
committed Details | Review

Description Mattias Bengtsson 2014-02-25 10:15:51 UTC
At work we are stuck behind an HTTP proxy and Maps 3.10 doesn't cope well with it at all (I'm getting placeholder tiles instead of real tiles). 

This might very well be a Champlain issue, but reporting here for now until I have done more research.
Comment 1 Jonas Danielsson 2014-02-25 11:49:57 UTC
There is a property on the champlain network tile source, called proxy-uri:
https://developer.gnome.org/libchamplain/unstable/ChamplainNetworkTileSource.html#ChamplainNetworkTileSource--proxy-uri

I guess that could be used. You can try setting that to your proxy uri on our source in maps, if it works we can figure out how to do it best automagicly.
Comment 2 Jonas Danielsson 2014-02-25 11:50:14 UTC
Or if champlain should do it automagicly.
Comment 3 Zeeshan Ali 2014-02-25 12:35:45 UTC
(In reply to comment #2)
> Or if champlain should do it automagicly.

Yeah, I don't think apps should need to tell champlain how to download its tiles. I think champlain needs to explicitly tell libsoup to use proxy through SoupProxyResolver* APIs.
Comment 4 Jonas Danielsson 2014-02-25 15:44:16 UTC
Created attachment 270286 [details] [review]
Use SoupSession API to get default proxy resolving

SoupSession is no longer an abstract class in libsoup and
SoupSessionAsync is deprecated. SoupSession is capable of async
with the use of queue_message, just like the code right now.

When using SoupSession you get automatic resolving of the default
proxy, as long as you do not set the proxy-uri property.
Comment 5 Jonas Danielsson 2014-02-25 15:44:20 UTC
Created attachment 270287 [details] [review]
Update documentation of proxy-uri property.

SoupSession resolve the default proxy when the proxy-uri
property is absent. Setting the proxy-uri will override the
default proxy.

This patch updates the doc to make that apparent.
Comment 6 Jonas Danielsson 2014-02-25 15:44:24 UTC
Created attachment 270288 [details] [review]
Update required version of libsoup

In order to use the new SoupSession API we need 2.42 of libsoup.
Comment 7 Jonas Danielsson 2014-02-25 15:44:29 UTC
Created attachment 270289 [details] [review]
Do not depend on libsoup-gnome-2.4

Everything in libsoup-gnome is deprecated.
Comment 8 Jonas Danielsson 2014-02-25 15:46:26 UTC
Created attachment 270290 [details] [review]
Do not depend on libsoup-gnome-2.4

Everything in libsoup-gnome is deprecated.
Comment 9 Jonas Danielsson 2014-02-25 15:47:51 UTC
Bit of a RFC these patches. Mattias: does this work for you?
Comment 10 Mattias Bengtsson 2014-02-25 16:40:01 UTC
Jonas: I will come back to this when I have time to test. Might be able to stay at work after hours some day soon. Either that or install a proxy at home.
Comment 11 Mattias Bengtsson 2014-02-25 16:41:31 UTC
Awesome work btw!
Comment 12 Jiri Techet 2014-02-25 23:58:28 UTC
libchamplain should already use the proxy automatically if libsoup-gnome is used. If libchamplain is compiled only against libsoup, the automatic proxy detection doesn't work. 

@Mattias, could you check if it works when you use libsoup_gnome? (I've just tried and it works for me.)

@Jonas: The patches look nice, the only thing I'm worried about is the dependency on a libsoup version which is 3 months old (for instance I have an older version on my machine). I don't want to force people to install the latest linux distros in order to use libchamplain. For this reason I'd prefer to wait for some time before applying these patches until the required libsoup version gets more widespread.
Comment 13 Zeeshan Ali 2014-02-26 00:39:37 UTC
(In reply to comment #12)
> libchamplain should already use the proxy automatically if libsoup-gnome is
> used. If libchamplain is compiled only against libsoup, the automatic proxy
> detection doesn't work. 
> 
> @Mattias, could you check if it works when you use libsoup_gnome? (I've just
> tried and it works for me.)
> 
> @Jonas: The patches look nice, the only thing I'm worried about is the
> dependency on a libsoup version which is 3 months old (for instance I have an
> older version on my machine).

I don't think we should need to require too latest of libsoup version. I recall libsoup-gnome was deprecated long time ago. The libsoup version in GNOME 3.10 should be fine(?).

> I don't want to force people to install the
> latest linux distros in order to use libchamplain.

Only the latest version of libchamplain. They don't need to upgrade to latest version of libchamplain. If they really must, they can at the same time also update to latest libsoup. Besides we can bump the minor version/soname.

Keeping in mind that Maps is the only maintained app that makes use of libchamplain and the fact that Maps depends on latest GNOME APIs, I don't see any real issues here.

> For this reason I'd prefer
> to wait for some time before applying these patches until the required libsoup
> version gets more widespread.

I think its more likely that people use Maps in environment with proxies (all big companies have proxy setups) than someone wanting latest of libchamplain but not the latest of libsoup.
Comment 14 Jonas Danielsson 2014-02-26 08:59:06 UTC
(In reply to comment #12)
> libchamplain should already use the proxy automatically if libsoup-gnome is
> used. If libchamplain is compiled only against libsoup, the automatic proxy
> detection doesn't work. 
> 
> @Mattias, could you check if it works when you use libsoup_gnome? (I've just
> tried and it works for me.)

Yeah, I think so as well. At least when I set a bogus system wide http proxy, Maps will not work for me, with jhbuild of libsoup and libchamplain on their master branches.

> 
> @Jonas: The patches look nice, the only thing I'm worried about is the
> dependency on a libsoup version which is 3 months old (for instance I have an
> older version on my machine). I don't want to force people to install the
> latest linux distros in order to use libchamplain. For this reason I'd prefer
> to wait for some time before applying these patches until the required libsoup
> version gets more widespread.


Hi, I think I might be missing something. As far as I can see libsoup 2.42 came out almost a year ago: https://mail.gnome.org/archives/ftp-release-list/2013-March/msg00216.html

Where do you see 3 months?
Comment 15 Jiri Techet 2014-02-26 09:46:27 UTC
 > Hi, I think I might be missing something. As far as I can see libsoup 2.42 came
> out almost a year ago:
> https://mail.gnome.org/archives/ftp-release-list/2013-March/msg00216.html
> 
> Where do you see 3 months?

Ah, OK, I was simply just looking at the dates here

http://ftp.gnome.org/pub/GNOME/sources/libsoup/

but they correspond to the latest minor release.
Comment 16 Jiri Techet 2014-02-26 09:53:31 UTC
(In reply to comment #13)
> I think its more likely that people use Maps in environment with proxies (all
> big companies have proxy setups) than someone wanting latest of libchamplain
> but not the latest of libsoup.

It's not a question of whether to have proxy support or not - libchamplain should clearly work over proxy, there's no question about it. But that is already the case when you use libsoup-gnome. So the question is rather whether to use the deprecated calls for a little longer or not without any user-noticeable effect.

I strongly suspect Mattias built libchamplain on his machine without libsoup-gnome development package installed but normally distributions build it against libsoup-gnome.
Comment 17 Dan Winship 2014-02-26 17:43:47 UTC
libsoup-gnome has been deprecated since GNOME 3.0 came out in spring 2011. You can bump your libsoup requirement up to 2.34.0, replace SOUP_TYPE_PROXY_RESOLVER_GNOME with SOUP_TYPE_PROXY_RESOLVER_DEFAULT, and drop the use of libsoup-gnome, and then you'll have working proxy resolution for all libsoup users.

(Assuming you don't want to depend on 2.42; if you don't care about that, then the patches here are better/more modern.)
Comment 18 Jiri Techet 2014-02-26 19:02:38 UTC
Great, thanks for the info, Dan. This is what I prefer for now so I have applied all patches from Jonas except for the first one and used the above option in soup_session_async_new_with_options(). The possible future transition to the modern API is just a matter of replacing this call with soup_session_new().

I have tested this (with some super-suspicious Chinese proxy) and it works.

@Mattias, does the latest code in libchamplain master solve your problem?
Comment 19 Jiri Techet 2014-02-26 19:03:50 UTC
Review of attachment 270287 [details] [review]:

Applied.
Comment 20 Jiri Techet 2014-02-26 19:04:53 UTC
Review of attachment 270290 [details] [review]:

Applied.
Comment 21 Jiri Techet 2014-02-26 19:05:57 UTC
Review of attachment 270288 [details] [review]:

Applied and changed the required version to 2.34
Comment 22 Jiri Techet 2014-02-26 19:07:34 UTC
Review of attachment 270286 [details] [review]:

Using the older API for now, this can be easily applied in the future.
Comment 23 Zeeshan Ali 2014-02-26 19:12:54 UTC
Review of attachment 270286 [details] [review]:

Perhaps we can put patches like this in a separate 0.13 branch? With them marked as 'rejected' and this bug marked as fixed (as it should be), we'll probably forget about it.
Comment 24 Mattias Bengtsson 2014-02-26 21:15:28 UTC
(In reply to comment #16)
> I strongly suspect Mattias built libchamplain on his machine without
> libsoup-gnome development package installed but normally distributions build it
> against libsoup-gnome.

It was the default installed gnome-maps from F20 that I tested against at work. gnome-maps on F20 at home shows that it is indeed built agains libsoup-gnome

$ ldd /usr/lib64/libchamplain-0.12.so.0
[...]
	libsoup-gnome-2.4.so.1 => /lib64/libsoup-gnome-2.4.so.1 (0x00000030ca000000)
	libsoup-2.4.so.1 => /lib64/libsoup-2.4.so.1 (0x00000030bf400000)
[...]

(In reply to comment #18)
> [...]
> I have tested this (with some super-suspicious Chinese proxy) and it works.

Great!

> @Mattias, does the latest code in libchamplain master solve your problem?

I will try to test at work when I get the time!
Comment 25 Jiri Techet 2014-02-26 22:03:18 UTC
(In reply to comment #23)
> Review of attachment 270286 [details] [review]:
> 
> Perhaps we can put patches like this in a separate 0.13 branch? With them
> marked as 'rejected' and this bug marked as fixed (as it should be), we'll
> probably forget about it.

It could actually be applied to 0.12 a bit later as well, I just wanted not to depend on a version which is relatively new. In this case, I don't know if it's worth it maintaining a separate branch - it's really just renaming a function call at 2 places and even if the old call is dropped from libsoup in the future, the fix will be obvious and trivial. The major thing, which is the removal of libsoup-gnome, is already in master thanks to the patches from Jonas.
Comment 26 Zeeshan Ali 2014-02-26 22:41:29 UTC
(In reply to comment #25)
> (In reply to comment #23)
> > Review of attachment 270286 [details] [review] [details]:
> > 
> > Perhaps we can put patches like this in a separate 0.13 branch? With them
> > marked as 'rejected' and this bug marked as fixed (as it should be), we'll
> > probably forget about it.
> 
> It could actually be applied to 0.12 a bit later as well, I just wanted not to
> depend on a version which is relatively new. In this case, I don't know if it's
> worth it maintaining a separate branch - it's really just renaming a function
> call at 2 places and even if the old call is dropped from libsoup in the
> future, the fix will be obvious and trivial. The major thing, which is the
> removal of libsoup-gnome, is already in master thanks to the patches from
> Jonas.

Cool, I'm glad we sorted this out.
Comment 27 Jonas Danielsson 2014-08-20 15:40:58 UTC
Any objections to marking this as fixed?
Comment 28 Zeeshan Ali 2014-08-21 14:38:28 UTC
(In reply to comment #27)
> Any objections to marking this as fixed?

Not from me if it now works for Mattias.
Comment 29 Mattias Bengtsson 2015-02-10 00:49:49 UTC
This works fine for me now, so let's close this. Sorry for not getting back to this earlier.