From mboxrd@z Thu Jan 1 00:00:00 1970 From: Peter =?utf-8?q?M=C3=BCller?= To: location@lists.ipfire.org Subject: libloc output for xt_geoip is fine on Core Update 153 Development Build: next/e8ecc81a (was: Re: Next steps of IPFire Location) Date: Sat, 28 Nov 2020 14:47:57 +0000 Message-ID: <3d484ea9-968d-f474-160f-13af17de558f@ipfire.org> In-Reply-To: MIME-Version: 1.0 Content-Type: multipart/mixed; boundary="===============3964941266655232566==" List-Id: --===============3964941266655232566== Content-Type: text/plain; charset="utf-8" Content-Transfer-Encoding: quoted-printable Hello Michael, hello *, after having installed Core Update 153 Development Build: next/e8ecc81a on my= testing machine and rebooting, I am glad to finally confirm the libloc version included into it p= roducing the correct and desired output for xt_geoip within a reasonable amount of time: > [root(a)maverick ~]# time location export --directory=3Dtmp --format=3Dxt_g= eoip >=20 > real 0m48.298s > user 0m46.938s > sys 0m0.301s CPU is an Intel N3150, the system was under constant albeit medium load while= executing this. The generated IPv4 networks for DE look fine as they contain no apparent over= lapping entries, while all of them are ordered ascending. After reloading the updating procedure by = running > bash -x /usr/local/bin/update-location-database pinging ping.ipfire.org (which is allowed by an outgoing firewall rule for de= stination country DE) works again. Yay. To conclude, libloc now finally seems to be ready for production and the more= accurate database version (which we have to generate and bake into Core Update 153, yet) - at least fro= m my point of view. Thanks, and best regards, Peter M=C3=BCller --===============3964941266655232566==--