Bug 1031319 - Honolulu is the default fallback timezone for GeoIP
Honolulu is the default fallback timezone for GeoIP
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: langtable (Show other bugs)
20
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Mike FABIAN
Fedora Extras Quality Assurance
:
: 1033889 (view as bug list)
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2013-11-16 14:19 EST by Chris Murphy
Modified: 2014-01-21 00:57 EST (History)
13 users (show)

See Also:
Fixed In Version: langtable-0.0.23-1.fc19
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2013-11-26 00:12:02 EST
Type: Bug
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
anaconda.log from final TC1 (5.37 KB, text/plain)
2013-11-16 14:20 EST, Chris Murphy
no flags Details
journalctl from final TC1 (235.53 KB, text/plain)
2013-11-16 14:20 EST, Chris Murphy
no flags Details

  None (edit)
Description Chris Murphy 2013-11-16 14:19:35 EST
Description of problem: 

In a qemu/kvm VM, Fedora 20 final TC1 timezone is incorrectly set to Pacific/Honolulu timezone, while in the same VM Fedora 20 beta RC5 is correctly set to America/Denver timezone.

Happens with live desktop and DVD ISO media.

Since the versions of anaconda are the same between those ISOs, this may be a problem in some other component than anaconda.


Version-Release number of selected component (if applicable):

Fedora 20 final TC1
anaconda-20.25.6-1.fc20.x86_64

How reproducible:

Always with final TC1, never with beta RC5, in the same VM.


Steps to Reproduce:
1. Boot either DVD or live desktop media.
2. Choose language.


Actual results:
Hub reports timezone is Pacific/Honolulu, which is incorrect.

Expected results:
America/Denver timezone.

Additional info:

I have a working network connection in both cases (Firefox from live media resolves URLs, loads pages)

Final TC1
[liveuser@localhost tmp]$ cat anaconda.log | grep -i geo
13:49:00,866 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140083109820160)
13:49:00,895 INFO anaconda: Starting geolocation lookup
13:49:00,895 INFO anaconda: Geolocation provider: Fedora GeoIP
13:49:00,977 DEBUG anaconda: Geoloc: URLError for Fedora GeoIP API lookup:
13:49:00,978 INFO anaconda: Geolocation lookup finished in 0.1 seconds
13:49:00,980 INFO anaconda: no results from geolocation
13:49:00,981 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140083109820160)

Beta RC5
14:02:10,954 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140432201737984)
14:02:11,039 INFO anaconda: Starting geolocation lookup
14:02:11,039 INFO anaconda: Geolocation provider: Fedora GeoIP
14:02:11,466 INFO anaconda: Geolocation lookup finished in 0.4 seconds
14:02:11,477 INFO anaconda: got results from geolocation
14:02:11,477 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140432201737984)
Comment 1 Chris Murphy 2013-11-16 14:20:06 EST
Created attachment 824964 [details]
anaconda.log from final TC1
Comment 2 Chris Murphy 2013-11-16 14:20:43 EST
Created attachment 824965 [details]
journalctl from final TC1
Comment 3 Chris Murphy 2013-11-16 14:29:48 EST
Remaining booted in final TC1, merely quit anaconda and relaunch in the same session, anaconda.log no longer indicates an error yet it still gets says the timezone is Pacific/Honolulu.

14:22:30,648 INFO anaconda: Running Thread: AnaGeolocationRefreshThread (140469542561536)
14:22:30,650 INFO anaconda: Starting geolocation lookup
14:22:30,651 INFO anaconda: Geolocation provider: Fedora GeoIP
14:22:31,136 INFO anaconda: Geolocation lookup finished in 0.5 seconds
14:22:31,143 INFO anaconda: got results from geolocation
14:22:31,171 INFO anaconda: Thread Done: AnaGeolocationRefreshThread (140469542561536
Comment 4 Kamil Páral 2013-11-19 04:35:46 EST
I just received Pacific/Honolulu timezone in my installation as well. (I should be detected around Europe/Amsterdam).
Comment 5 Martin Kolman 2013-11-19 06:39:48 EST
Reassigning to langtable - it is returning a list of US timezones with Honolulu as the first item. As the timezones should be ordered demographically, this is a bug in the reordering.
Comment 6 Fedora Update System 2013-11-21 11:47:24 EST
langtable-0.0.21-1.fc20 has been submitted as an update for Fedora 20.
https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc20
Comment 7 Fedora Update System 2013-11-21 11:48:30 EST
langtable-0.0.21-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.21-1.fc19
Comment 8 Chris Murphy 2013-11-21 17:42:13 EST
The bug as described is not fixed with this update. Now the timezone is incorrectly reported as America/New York, so the geolocation feature still isn't working correctly.
Comment 9 Mike FABIAN 2013-11-22 01:03:44 EST
(In reply to Chris Murphy from comment #8)
> The bug as described is not fixed with this update. Now the timezone is
> incorrectly reported as America/New York, so the geolocation feature still
> isn't working correctly.

Right, it only improves the result slightly when geolocation failed
for whatever reason. langtable only has information of what timezones
are most likely when you know the country (and maybe the language).
Comment 10 Fedora Update System 2013-11-23 14:52:11 EST
Package langtable-0.0.21-1.fc19:
* should fix your issue,
* was pushed to the Fedora 19 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing langtable-0.0.21-1.fc19'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2013-21833/langtable-0.0.21-1.fc19
then log in and leave karma (feedback).
Comment 11 Martin Kolman 2013-11-25 04:51:35 EST
Well, I would say it is fixed, as:
* if connectivity is available and the API works, language & timezone are correctly selected
* if connectivity is not available or the GeoIP API does not work for some reason, America/New York, the long standing Anaconda default timezone, is used.

BTW, this is the URL for the GeoIP API:
https://geoip.fedoraproject.org/city
It should return a JSON looking +- like this:

{"dma_code": 0, "ip": "<ip removed>", "longitude": -0.12999999523162842, "latitude": 51.5, "region_name": null, "region": null, "area_code": 0, "city": null, "postal_code": null, "time_zone": "Europe/London", "country_code": "GB", "country_code3": "GBR", "metro_code": 0, "country_name": "United Kingdom"}

So if the URL is reachable and returns a sane looking JSON, but Anaconda does not preselect a correct language and timezone, then there is an issue. Otherwise it is working correctly.
Comment 12 Leslie Satenstein 2013-11-25 09:34:47 EST
In the November Ananconda betas, the city of Montreal 
american/montreal disappeared from the list and from the map.

why?

And the first beta put my timezone to that of Denver. My default based on my IP address should be Toronto, Montreal or New York.

The second beta now puts my default TZ as Honolulu.
Comment 13 Leslie Satenstein 2013-11-25 09:36:12 EST
I am very open to trying the next beta.  BTW, I always do a DVD image install to a 250 gig physical disk, reserved for this.  The real disk install shows up things that a VM install does not.
Comment 14 Chris Murphy 2013-11-25 10:40:15 EST
(In reply to Martin Kolman from comment #11)
> Well, I would say it is fixed, as:
> * if connectivity is available and the API works, language & timezone are
> correctly selected

I have connectivity, language & timezone are not correctly selected.

https://geoip.fedoraproject.org/city

{"region": null, "country_code": "US", "metro_code": 0, "country_code3": "USA", "area_code": 0, "region_name": null, "latitude": 38.0, "time_zone": null, "postal_code": null, "longitude": -97.0, "city": null, "dma_code": 0, "country_name": "United States", "ip": "50.183.15.223"}
Comment 15 Adam Williamson 2013-11-25 11:49:26 EST
leslie: as I posted to the forums, please file a new bug for Montreal going missing.
Comment 16 Chris Murphy 2013-11-25 22:12:42 EST
And on a cell network:

{"region": null, "area_code": 0, "region_name": null, "longitude": -97.0, "latitude": 38.0, "dma_code": 0, "ip": "172.56.8.97", "metro_code": 0, "country_name": "United States", "country_code": "US", "country_code3": "USA", "time_zone": null, "postal_code": null, "city": null}
Comment 17 Fedora Update System 2013-11-26 00:12:02 EST
langtable-0.0.21-1.fc20 has been pushed to the Fedora 20 stable repository.  If problems still persist, please make note of it in this bug report.
Comment 18 Kamil Páral 2013-11-26 04:00:24 EST
Guys, you really need to file separate reports. This one (Honolulu as a fallback timezone) has been fixed.
Comment 19 Leslie Satenstein 2013-11-26 21:32:34 EST
(In reply to Adam Williamson from comment #15)
> leslie: as I posted to the forums, please file a new bug for Montreal going
> missing.

Adam, Since the two problems arrivec coincidentally, I attributed it to being one and the same. Fix the problem with wrong url and the missing America/Montreal would reappear.

I live here and would be disappointed if Montreal was wiped off the map.

Yes, I will open a new buglet report.
Comment 20 Fedora Update System 2013-12-04 09:39:48 EST
langtable-0.0.22-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.22-1.fc19
Comment 21 Fedora Update System 2013-12-10 11:58:57 EST
langtable-0.0.23-1.fc19 has been submitted as an update for Fedora 19.
https://admin.fedoraproject.org/updates/langtable-0.0.23-1.fc19
Comment 22 David Shea 2014-01-02 16:33:47 EST
*** Bug 1033889 has been marked as a duplicate of this bug. ***
Comment 23 Fedora Update System 2014-01-21 00:57:30 EST
langtable-0.0.23-1.fc19 has been pushed to the Fedora 19 stable repository.  If problems still persist, please make note of it in this bug report.

Note You need to log in before you can comment on or make changes to this bug.