GNOME Bugzilla – Bug 702194
make timezonemap a system library
Last modified: 2021-06-09 16:32:47 UTC
gnome-control-center contains a forked version of libtimezonemap, https://launchpad.net/timezonemap Ubuntu uses libtimezonemap for indicator-datetime which provides a drop-in-replacement for GNOME's Date & Time panel. Because gnome-control-center 3.8 is statically linked, trying to run Ubuntu's time panel crashes gnome-control-center. See http://pad.lv/1187981 for the Ubuntu bug report. Suggested resolutions: 1. Depend on libtimezonemap (and get it packaged in non-Ubuntu distributions) 2. If libtimezonemap is not adequate, please submit patches to the libtimezonemap maintainers. 3. If step 2 is unsuccessful, please rename the symbols in your forked copy to not break other software. Thanks!
(In reply to comment #0) > gnome-control-center contains a forked version of libtimezonemap, > https://launchpad.net/timezonemap It doesn't. The cc-* names in that "upstream" version should make you suspicious.
After a little more research, I think GNOME's timezonemap was forked in 2010 from ubiquity (Ubuntu's alternate to anaconda ;) ) but wasn't packaged as a separate library in Ubuntu until 2011.
Ok, I take back my previous comment (I accidentally posted it when I renamed the bug to be less accusing.) I think it would be nice for consistency and ease of use by developers to have this be a system library though. Ubuntu's packaging includes a gir which is used by ubiquity written in Python for instance. http://irclogs.ubuntu.com/2013/06/13/%23ubuntu-devel.html#t16:50
We had a brief discussion on the #control-center channel about this. Looks like there's a number of apps that could make use of the system libtimezonemap library: gnome-control-center, gnome-initial-setup, gnome-weather, distro installers (Ubiquity, Anaconda). Right now most of these apps have copied gnome-control-center's cc-timezone-map around and slightly modified it for their own use. Same thing with the libtimezonemap, it has a fork of gnome-control-center's cc-timezone-map. Summary of issues/questions from the discussion: - https://launchpad.net/timezonemap is a mix of GPLv2 and GPLv3 code; would have to be GPLv2 for g-c-c to use - the completion list is populated from an Ubuntu specific service, can this be moved off to another library? g-c-c would use the completion list from libgweather instead. - where does the data in cities15000.txt come from? Will this be kept up to date? - would be nice to move this to GNOME git
* I'll check about the license. * That service is opensource https://launchpad.net/ubuntu-geonames which is really a one file python webapp, serving results with a fuzzy search from a database generated based on geonames.org. It's also open source so you could host your instance or make a compatible one if you wish. Where does libgweather get its completion list from? would be nice to have libgweather completion source available in the library as well. * cities15000.txt is from geonames.org * moving to git, does it really make a difference? it's such a small thing, with commits about once a year.
libgweather's information comes from a myriad of different sources. See https://git.gnome.org/browse/libgweather/tree/data/sources/README.sources It's a mess and we're better off trying to kill off libgweather. I think Bastien is creating his own geonames service, based on information donated by MaxMind. Would be nice if we could figure out what to do here. Moving to git and the GNOME infrastructure means we get GNOME translations, GNOME bugzilla, etc. It would be nice, but I'd say it's not mandatory.
(In reply to comment #6) > libgweather's information comes from a myriad of different sources. See > https://git.gnome.org/browse/libgweather/tree/data/sources/README.sources > > It's a mess and we're better off trying to kill off libgweather. > > I think Bastien is creating his own geonames service, based on information > donated by MaxMind. Would be nice if we could figure out what to do here. Not quite. We use MaxMind's libraries and data to do IP geolocation, not geocoding. Geocoding can be done with geocode-glib directly though, and we're working on switching the backend from Yahoo PlaceFinder to Nominatim (we'll probably have to set up our own caching service though). > Moving to git and the GNOME infrastructure means we get GNOME translations, > GNOME bugzilla, etc. It would be nice, but I'd say it's not mandatory. If sufficiently used, we could have it in gnome-desktop. The library exists for this purpose.
A timezonemap external library (with GIR binding) would be extremly valuable for Tails too (https://labs.riseup.net/code/issues/10820).
GNOME is going to shut down bugzilla.gnome.org in favor of gitlab.gnome.org. As part of that, we are mass-closing older open tickets in bugzilla.gnome.org which have not seen updates for a longer time (resources are unfortunately quite limited so not every ticket can get handled). If you can still reproduce the situation described in this ticket in a recent and supported software version, then please follow https://wiki.gnome.org/GettingInTouch/BugReportingGuidelines and create a new bug report at https://gitlab.gnome.org/GNOME/gnome-control-center/-/issues/ Thank you for your understanding and your help.