Obligatory MaxMind notice:
"This product (GeoXPlanet) includes GeoLite data created by MaxMind, available from
*maxmind.com/"
I got a response from MaxMind today. It seems the company determined that the vagueness of the GeoLiteCity database license (at least what I interpreted as vagueness) did not restrict me from redistributing their dataset in modified format (i.e. imported into a SQLite binary file), and there are no "export restrictions" against their dataset.
GeoXPlanet-0.4.3-SQLite-Maxmind will be out soon.
@praka123: The vmware image upgrade last night got interrupted. I'll try it again tonight (or more likely just download/install Debian Sid to begin with) and attempt to replicate the issues you've posted about.
Edit: The test (using Ubuntu 8.04 i386 Hardy Heron) went well, though I do see what's going on. The auto-launch (via Sessions) kept returning [0,0] for all connection lat/longs, giving a single line to (you guessed it) the west coast of Africa. I'll dig into it and see what's up (path issue, perhaps?) and put this fix in 0.4.4. As usual, thanks for reporting the problem, praka123...
Edit #2: The [0,0] failures during the initial test were due to using incorrect settings for the sqlite db. I switched to online (hostip.info) lookups, and everything is working. Instead of putting "/path/to/GeoXPlanet-0.4.3/src/GeoXPlanet.py" in your Session setting, put "xterm -e /path/to/GeoXPlanet-0.4.3/src/GeoXPlanet.py" in there and relog. That will bring up an xterm so you can see GeoXPlanet's output while it's running from Session. If it crashes, let me know.
Edit #3: The GeoXPlanetDB.py file has been modified. It seems that when you start GeoXPlanet manually, the path to find the SQLite db file is correct, but when launching it via "Sessions", the path is incorrect. Fix will be included in 0.4.4 (Though none of this helps with the problem you're currently having, praka123). I'm still investigating.