Bug 1570619

What do you propose we do about this? There will be no further releases from upstream so there's no point raising it there.

(In reply to Paul Howarth from comment #1)
> What do you propose we do about this? There will be no further releases from
> upstream so there's no point raising it there.

In this case I can see only two options:

1. Fork upstream data and patch. I'd happily contribute a patch, but the source data seems to be binary. Are there any tools to manipulate it?
2. Stop shipping wrong data.

Or maybe you could switch to the new, still developed databases: https://dev.maxmind.com/geoip/geoip2/geolite2/ 
It looks like the new software is already packaged in Fedora: libmaxminddb . The new databases seem to have accurate data about the IPv6 subnets in question.

(In reply to Dominik 'Rathann' Mierzejewski from comment #3)
> Or maybe you could switch to the new, still developed databases:
> https://dev.maxmind.com/geoip/geoip2/geolite2/ 
> It looks like the new software is already packaged in Fedora: libmaxminddb .
> The new databases seem to have accurate data about the IPv6 subnets in
> question.

Make that "about some of the IPv6 subnets in question". The first two are still listed as located in the US, but the Ukrainian one is correctly identified.

The GeoIP-GeoLite-data package is providing data to go with the GeoIP library.

Switching from GeoIP to libmaxminddb is certainly the way to go, but that's a different API and, as you say, requires different databases, so those databases should be packaged separately from GeoIP-GeoLite-data. It also needs the upstream library consumers to be changed to use the different API.

Thanks Paul for your work on geoip related things so far.

> so those databases should be packaged separately from GeoIP-GeoLite-data

Do you know if that work has been started by anyone?  If not I may take a stab at it and submit it for review.

(In reply to Carl George from comment #6)
> Thanks Paul for your work on geoip related things so far.
> 
> > so those databases should be packaged separately from GeoIP-GeoLite-data
> 
> Do you know if that work has been started by anyone?  If not I may take a
> stab at it and submit it for review.

I'm not aware of any work having been done on this, except for the python-geoip-geolite2 package (Bug #1204447), which included a copy of the GeoLite2 City database, but that package appears to have been retired (https://src.fedoraproject.org/rpms/python-geoip-geolite2/blob/master/f/dead.package).

Just submitted https://bugzilla.redhat.com/show_bug.cgi?id=1571404.

Paul, I got the new geolite2 package approved.  The SRPM builds two subpackages, geolite2-city and geolite2-country, corresponding to the database files from Maxmind.  Would you like to co-maintain the package with me?

(In reply to Carl George from comment #9)
> Paul, I got the new geolite2 package approved.  The SRPM builds two
> subpackages, geolite2-city and geolite2-country, corresponding to the
> database files from Maxmind.  Would you like to co-maintain the package with
> me?

Sure.

Do you plan to update the new package monthly? What I did for GeoIP-GeoLite-data was to update monthly in rawhide/branched, quarterly in stable Fedora releases, and six-monthly in EPEL. The geolite2 package is yours though, so feel free to do more frequent updates if you're sufficiently enthused :-)

Have you branched and built the package for older Fedoras and EPEL?

Got you added.

I wasn't planning on sticking to a specific schedule.  I usually update my packages evenly across all branches whenever possible.  How about aiming for quarterly for all branches?

Branched, built, and submitted for el6, el7, f27, and f28:
https://bodhi.fedoraproject.org/updates/?packages=geolite2

Dominik, regarding the original point of this issue, I looked up those subnets using mmdblookup (from libmaxminddb-devel) and the GeoLite2-Country.mmdb database in my new geolite2-country package.  One of them is correct now, but the other two are still listed as "United States".

    $ mmdblookup --file /usr/share/GeoIP/GeoLite2-Country.mmdb --ip 2001:470:71:1:: country names en
    
      "United States" <utf8_string>
    
    $ mmdblookup --file /usr/share/GeoIP/GeoLite2-Country.mmdb --ip 2001:470:71:ff:: country names en
    
      "United States" <utf8_string>
    
    $ mmdblookup --file /usr/share/GeoIP/GeoLite2-Country.mmdb --ip 2001:470:71:f00:: country names en
    
      "Ukraine" <utf8_string>

You could report the error upstream to MaxMind, but I'm sure their response will be to switch to their paid GeoIP2 database.

> GeoLite2 databases are free IP geolocation databases comparable to, but less accurate than, MaxMind's GeoIP2 databases.

- https://dev.maxmind.com/geoip/geoip2/geolite2/

I'm going to close this because there's nothing I can do about it.

Users of this package need to get their applications moved over to libmaxminddb/geolite2.

Agreed, thanks for your time.