[00:02] <mattcen> GrueMaster: Yeah, that's what I tried, and grepping for lvm in that didn't yeild anything that jumped out at me. What I will do is try specifying the entire file to see if that preseeds it correctly. If not even that works, I'll assume it's a bug.
[01:37] <xnox> maxb: pkgsel is not run, so no. use success_command....
[09:39] <gnuoy> xnox, I'm currently looking to move geoname-lookup.ubuntu.com to be a juju managed service
[09:40] <gnuoy> as part of the testing we are running the import script from ubuntu-geonames
[09:41] <gnuoy> and it's failing because we have no admin1Codes.txt no longer exists on the geonames site
[09:41] <xnox> I see.
[09:41] <gnuoy> at the moment I'm stuck because I can't the file from geonames but I believe the data is still needed
[09:42] <xnox> gnuoy: i probably should a test in jenkins to try doing bootstrap, cause this is not the first time geonames changes structure without us noticing in a timely fashion.
[09:43] <xnox> gnuoy: admin1 shouldn't be that necessory, all it provides is regional districts/authorities. E.g. a mapping "London -> Greater London" which most of the time is redundant & many large locations were missing it.
[09:44] <xnox> gnuoy: I guess I should code up, to make the import succeed again.
[09:44] <xnox> gnuoy: in the mean time, can you continue using the sql-dump from the currently running in-production service?
[09:44] <xnox> (or like do something else? I'll ping you once I fix it up)
[09:44] <gnuoy> xnox, thanks. I'll proceed with writing the charm without that table but obviously I'm not going to cut over before we've done testing on the juju env. I have some other fixes to the installer and I'll propose a mp when I'm done
[09:45] <xnox> ok, cool. thanks a lot.
[09:45] <gnuoy> np
[10:02] <xnox> gnuoy: since revision 17 from 2012-08-23 lp:ubuntu-geonames correctly is using admin1CodesASCII.txt and completes the import. And I have just re-run the whole import-geonames.sh and it works correctly.
[10:03] <xnox> gnuoy: are you using the latest revision 20 from lp:ubuntu-geonames ?
[10:03] <xnox> can you show me the errors you are getting?
[10:03] <gnuoy> xnox, it successfully grabbed admin1CodesASCII.txt from the geonames site ?
[10:03] <xnox> yes.
[10:04] <xnox> 2013-05-24 10:59:43 (649 KB/s) - ‘admin1CodesASCII.txt’ saved [143218/143218]
[10:04] <gnuoy> ok, I must being doing something cranky, let me check
[10:05] <gnuoy> xnox, I seem to have a an old copy. I'm really sorry to waste your time, let me test again
[10:09] <xnox> gnuoy: to be honest, I'm glad it worked from the tip of the branch =)))) means no need to poke & trying to work out a new way geonames decided to print their tables. I wish they just published sql dumps to be honest.
[10:34] <gnuoy> xnox, I saw https://pastebin.canonical.com/91594/ . Easy fix to extend the column on the table create but it's odd you didn't see it
[10:35] <gnuoy> ( also https://pastebin.canonical.com/91595/ )
[10:42] <xnox> gnuoy: strange. =) also paste.ubuntu.com =)))) canonical one is not public.
[10:42] <gnuoy> xnox, urgh, sorry, good point
[10:43] <xnox> gnuoy: I do remember that we did bump the size of that field  because of UAE before. But my current schema here is 10 000. I wonder if there are some other settings in my database that do something else instead of erroring out though.
[10:43] <xnox> I am on saucy, so my postgresql might be newer (might not) & it's a very development postgresql cluster here, who knows what parameters I set on it ;-)
[10:43] <gnuoy> (anyone following along http://paste.ubuntu.com/5696557/)
[10:44] <xnox> gnuoy: calculate / bump the column sizes to fit your data & just do a merge proposal for lp:ubuntu-geonames.
[10:44] <gnuoy> will do
=== kentb-out is now known as kentb
=== kentb is now known as kentb-afk
=== kentb-afk is now known as kentb
=== kentb is now known as kentb-out