[Summary]
MIR Team ack under the following constraints/todos:

TODOs:
- yes we need to demote geoip and promote libmaxminddb in exchange for that
- needs work in seeds to change to the new lib
- needs work in nginx to change dependencies
- merge 1.4.2 from upstream to get a memory leak (and others) resolved
  Seems we need no rebuilds of all dependencies as they depend on much
  lower version.
- get the server team subscribed to libminmadddb

@Andreas I'll assign it to you to work on those, Please ping me to officially set to approved once things are ready.

[Duplication]
Yes this is a duplicate. Contenders are:
- src:geoip (in main atm)
- src:libmaxminddb (in universe atm)
But as outlined on this bug before we could ans should replace one with the
other for 20.04.

This is not a transition to something completely different. The
company/organization behind both projects is https://dev.maxmind.com/
and they clearly go for the newer version.

https://github.com/maxmind/geoip-api-c is called "Legacy" for a reason
and  https://github.com/maxmind/libmaxminddb is newer in all regards.

Duplication isn't a problem as we will switch which of the two libs is in main.

[Dependencies]
OK:
- no other Dependencies to MIR due to this
- there is a -dev packages but we don't need to exclude as it doesn't have further dependencies into universe
- no direct dependencies on the CLI mmdb-bin, we will only promote binary libmaxminddb0

[Embedded sources and static linking]
OK:
- no embedded source present
- no static linking

[Security]
OK:
- history of CVEs does not look concerning
- does not run a daemon as root
- does not use webkit1,2
- does not use lib*v8 directly
- does not open a port
- does not process arbitrary web content
- does not use centralized online accounts
- does not integrate arbitrary javascript into the desktop
- does not deal with system authentication (eg, pam), etc)

Problems:
- does parse data formats
  It parses an on disk geoip DB (under admin control) and gets strings or
  sockaddrs passed for lookup.
  Strictly speaking this would need a security review, but I realized it
  doesn't parse it on its own anyway, it directly passes e.g. the IP string to
  getaddrinfo of glibc.
  From there on it only works on a standard struct sockaddr_in* which I think
  is fine.

This is as close to not needed that even my usual "better safe than sorry"
doesn't trigger and I think we can ack this without explicit security review.

[Common blockers]
OK:
- does not FTBFS currently
- does have a test suite (not just a fake, 4 digit number of test cases)
  that runs at build time
  - test suite fails will fail the build upon error.
- translation are present
- not a python package, no extra constraints to consider int hat regard

Problems:
- does not have a test suite that runs as autopkgtest
  But also not really depends on other things that would trigger anyway.
- no bug subscriber (yet) but it is clear that it will be the sever Team
  added it to TODOs

[Packaging red flags]
OK:
- Ubuntu does not carry a delta
- Ubuntu does carry a delta, but it is reasonable and maintenance under control
- symbols tracking is in place
- d/watch is present and looks ok
- Upstream update history is (ok)
- Debian/Ubuntu update history is a bit slow
  - the current release is not packaged
    1.4.0 and 1.4.1 were odd, but 1.4.2 seems good and should be merged
    before promotion - dependencies usually are libmaxminddb0 (>= 1.0.2)
    so likely no rebuilds of all deps are needed.
- promoting this does not seem to cause issues for MOTUs that so far
  maintained the package
- no massive Lintian warnings
- d/rules is rather clean
- not using Built-Using

[Upstream red flags]
OK:
- no Errors/warnings during the build
- no incautious use of malloc/sprintf (as far as I can check it)
- no use of sudo, gksu, pkexec, or LD_LIBRARY_PATH
- no use of user nobody
- no use of setuid
- no important open bugs (crashers, etc) in Debian or Ubuntu
- no dependency on webkit, qtwebkit, seed or libgoa-*
- no embedded source copies
- not part of the UI for extra checks