[12:01] <BradB> maybe we'll just new a few maintainers (and more of you, of course) to test it offline and then just take the leap at some point in the next few weeks
[12:01] <BradB> s/new a/need a/
[12:02] <mdz> another possibility would be to have pitti use it for tracking security issues only
[12:02] <mdz> security is the toughest test case for a bug tracker :-)
[12:02] <BradB> cool
[12:03] <mdz> that has the advantage of being a relatively discrete set of bugs
[12:04] <mdz> workrave, back in 10 if you still need me
[12:04] <BradB> ok, thanks for your feedback
[12:06] <debonzi> BradB, is it possible to have a debug port in launchpad.ubuntu.com?
[12:08] <BradB> elmo: ^ ? (debug is on 9021)
[12:08] <kiko_bz> is it now?
[12:09] <BradB> kiko_bz: yeah
[12:09] <kiko_bz> ah, neat.
[12:09] <BradB> it won't work though unless elmo does something to the apache config
[12:09] <debonzi> BradB, sure? I can't connect in port 9021
[12:10] <BradB> debonzi: yep it's listening. the firewall'll block you, of course, but it's listening :)
[12:10] <kiko_bz> screaming on deaf ears
[12:10] <debonzi> is elmo the responsable for that?
[12:11] <BradB> debonzi: yep
[12:11] <debonzi> elmo, ?
[12:13] <kiko_bz> BradB, cprov has an updated gina run for your schema version I believe
[12:14] <kiko_bz> I don't know how you would go about using it though, given you've already got some data in your DB
[12:14] <BradB> kiko_bz: sounds like a problem for the stud
[12:16] <BradB> in any case
[12:16] <kiko_bz> one thing we *could* do is start a run on *your* database if you like.
[12:16] <kiko_bz> it will take 2h.
[12:16] <BradB> i gotta go play the role of gigalo now
[12:16] <kiko_bz> (just for main)
[12:16] <BradB> hm
[12:16] <kiko_bz> he ran it on soyuz_dogfood
[12:17] <BradB> kiko_bz: will running it on launchpad_dogfood blow any data way? i wouldn't expect so. if not, go ahead, i'd say.
[12:18] <BradB> i gotta go out for a while.
[12:18] <kiko_bz> it probably won't, but I don't know if it will run :)
[12:18] <cprov> BradB|out: heeh it's your last chance to say "please NO" ...
[12:19] <kiko_bz> cprov, what do you think :)
[12:19] <kiko_bz> cprov, make a dump of the current launchpad_dogfood DB in case it goes wrong.
[12:19] <cprov> FOGO NA BOMBA !!
[12:19] <kiko_bz> you can actually dump your DB with inserts only
[12:19] <BradB|out> heheh
[12:19] <kiko_bz> which would avoid having to re-run gina
[12:19] <kiko_bz> I don't know if that would blow up because of uniqueness constraints though
[12:19] <kiko_bz> may be simpler to just kick gina again
[12:19] <BradB|out> if you think you might blow away data, just make sure you have a quick way of unblowing it away
[12:20] <BradB|out> if you need more input from me though, it'll have to wait, i gotta head out nowish
[12:20] <cprov> just dumping the current launcpad_dogfood should avoid future problems
[12:22] <cprov> the only problem is Librarian  dependencies ( Kinnison WANTED), once I'm running w/ librarian there is no way to insert its fields latter, so we will need to purge the DB and rerun gina+librarian
[12:22] <sabdfl> ok, am back, will catch up on scrollback
[12:23] <kiko_bz> shame
[12:24] <kiko_bz> sabdfl, meet salgado; he's working with us initially on setting up some agreeable sampledata for soyuz
[12:25] <sabdfl> hey salgado, welcome aboard
[12:25] <salgado> hello sabdfl
[12:25] <kiko_bz> the current size we've paired it down to is 1.4MB bzipped
[12:25] <kiko_bz> I suspect that's still too big
[12:25] <sabdfl> how many packages would that include?
[12:26] <kiko_bz> salgado?
[12:26] <sabdfl> we don't need many
[12:26] <sabdfl> just four or so packages with four releases of each
[12:26] <kiko_bz> heh
[12:26] <salgado> 121 sourcepackages
[12:26] <kiko_bz> how many releases?
[12:27] <salgado> 303 binarypackages
[12:27] <kiko_bz> where is all that size coming from, damn it? people?
[12:27] <salgado> 50 people
[12:27] <kiko_bz> it's a reasonable sample actually
[12:27] <kiko_bz> salgado, from a visual review of the dumpfile, what's taking up most of the space?
[12:28] <salgado> I haven't take a look at it yet. I'll do it now
[12:30] <salgado> 660K from bziped gpgkeys
[12:31] <kiko_bz> salgado, can you kick all but 50 of those gpgkeys spacewards? I don't care for them, and I suspect sabdfl doesn't either.
[12:31] <salgado> project/product descriptions should be blamed too
[12:32] <kiko_bz> blame cprov, he got the data for us ;)
[12:33] <salgado> kiko_bz: there's 20 gpgkeys
[12:34] <cprov> salgado: have you sliced the packages.gz files ?
[12:35] <cprov> salgado: or are following another approach ?
[12:35] <salgado> cprov: I used cascade=True on all ForeignKeys() and then I deleted all but the first 50 Persons
[12:36] <cprov> salgado: so, you worked just on DB not in the code itself, fine
[12:42] <cprov> kiko: next step ? store the new dump in a public place ? or turn it our new-sampledata for lp ? 
[12:42] <kiko> I would really like to put this up as the new sample data
[12:42] <kiko> but it needs to be a bit smaller
[12:42] <kiko> I think ~800K uncompressed is the limit of what's acceptable
[12:58] <sabdfl> stub: up early? are bug attachments up and running?
[12:58] <cprov> kiko: then cut it a bit more, let's say 20 persons
[12:58] <kiko> yes
[12:58] <kiko> salgado, how does that sound?
[12:58] <salgado> for 800k uncompressed I think 10 persons is enough
[12:58] <kiko> shoot then 
[01:12] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: template fix to avoid traceback when SourcePackage.distro is NULL. (patch-707)
[01:16] <kiko> debonzi rocks
[01:23] <dilys> Merge to thelove@canonical.com/dists--tla--1.3: seal the branch, not used now the name has been chosen (version-0)
[01:24] <sabdfl> i think malone is a lot slicker than most bug trackers already, from an end-user point of view
[01:24] <sabdfl> i want an issue tracker so that as many of the "doh" things as possible are handled by non-developer community members
[01:24] <sabdfl> but i'm not going to hide malone
[01:24] <sabdfl> just led users to the issue tracker first
[01:24] <dilys> Merge to thelove@canonical.com/tla-debian--debian--1.0: seal the branch, not used now the name has been chosen (version-0)
[01:25] <dilys> Merge to thelove@canonical.com/tla--devo--1.3: seal the branch, not used now the name has been chosen (version-0)
[01:25] <dilys> Merge to thelove@canonical.com/docs-tla--devo--1.3: seal the branch, not used now the name has been chosen (version-0)
[01:25] <sabdfl> the ui weirdness was debated between limi and i
[01:26] <sabdfl> we decided to try it, we can pull it if it's too weird
[01:26] <sabdfl> this is the bit where the headline assignment is a rownavigation style table
[01:26] <sabdfl> with links in it, on the package/product and assignee
[01:26] <sabdfl> and the links take you to different pages than clicking elsewhere on the row
[01:26] <sabdfl> it's a handy shortcut if you know what you're doing
[01:26] <sabdfl> but might be too clever for new users
[01:44] <salgado> kiko: 10 persons, 36 products, 13 sourcepackagereleases: 900K uncompressed
[01:45] <kiko> salgado, looks good; let me check it out
[01:45] <kiko> sabdfl, is 900K closer to acceptable? it triplicates the current data.
[01:48] <sabdfl> fogo na bomba indeed :-)
[01:48] <kiko> let's see
[02:00] <sabdfl> kiko! you got your name back!
[02:09] <sabdfl> night guys
[02:09] <lifeless> night
[02:09] <salgado> night sabdfl
[02:09] <sabdfl> hey sync-man!
[02:10] <sabdfl> lifeless: we vending our branches yet?
[02:10] <lifeless> not quite. taxi had a quirk beyond what spiv fixed.
[02:10] <lifeless> on my plate for today - I've done the bootstrap heavy lifting for baz now.
[02:11] <lifeless> you get roll a deb of baz to play with anytime now :)
[02:11] <sabdfl> i saw thelove commits sealing off tla
[02:11] <sabdfl> gotta love thelove
[02:11] <sabdfl> i crack myself up
[02:12] <sabdfl> aren't you guys glad we don't work in the same office every day :-)
[02:12] <sabdfl> night
[02:12] <lifeless> hehehe
[02:12] <lifeless> night
[02:20] <kiko> heh
[03:44] <dilys> Merge to rocketfuel@canonical.com/arch-pqm--main--0: dont fail pqm if a PQMException is raised (patch-12)
[03:55] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: * added directories (patch-3)
[07:20] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Re-adding the massively pruned patch logs (patch-4)
[09:02] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Nudge the tla help command to the left (Jivera) (patch-5)
[09:51] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Unsigned checking for Asuffield (Jivera) (patch-6)
[09:55] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: I believe the update test is finally working (patch-7)
[10:01] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Adding grab file description to help (patch-8)
[10:05] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing grab so that it registeres the remote archive properly (patch-9)
[10:20] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Various small things, mostly input validations (Abentley) (patch-10)
[10:40] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Selective undo (Monoses) (patch-11)
[10:45] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Path fix for cmd-file-find (patch-12)
[11:01] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Add missing patchlogs from before (patch-13)
[11:06] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Fix for get-changeset and testcase for same (Bentley) (patch-14)
[11:13] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Make tests more solaris friendly (patch-15)
[11:19] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing id for test-get-changeset (patch-16)
[11:50] <sabdfl> lifeless: is there a generic command to show the diffs of the last commit?
[11:52] <spiv_> Maybe something like "tla get-changeset $(tla logs -r | head -1) ,,last-changeset && find ,,last-changeset/patches -type f | xargs cat"
[11:52] <sabdfl> stub: what do the new reltriggers do?
[11:53] <spiv_> There may be a saner way to do that :)
[11:53] <sabdfl> spiv_: yowser
[11:53] <stub> New reltriggers?
[11:53] <sabdfl> stub: from this morning's refuel:
[11:54] <sabdfl> @@ -676,6 +679,7 @@
[11:54] <sabdfl>  UPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid = 'sourcepackagerelease'::pg_catalog.regclass;
[11:54] <sabdfl> to current.sql
[11:54] <sabdfl> ah, not new
[11:54] <sabdfl> nonetheless?
[11:55] <stub> I think that is the code pg_dump puts in there to turn of relational integrity constraints and triggers
[11:56] <stub> Which needs to be done now, as our sample data has grown in complexity
[11:57] <spiv_> sabdfl: This is probably a little saner: "tla delta --diffs $(tla logs | tail -2)"
[12:00] <stub> sabdfl: You should be able to use archzoom if someone fixes the gpg signing rules for the account it runs as.
[12:00] <sabdfl> ok
[12:02] <sabdfl> spiv_: that did the trick nicely, thanks
[12:04] <carlos> morning
[12:05] <sabdfl> hey carlos
[12:05] <carlos> sabdfl: hi
[12:06] <stub> yo
[12:39] <carlos> sabdfl: could you look at my mail about the statistics and fuzzy flag from yesterday at launchpad mailing list?
[12:39] <sabdfl> carlos: ok
[12:39] <carlos> sabdfl: thanks
[01:32] <Kinnison> sabdfl: https://chinstrap.warthogs.hbd.com/~dsilvers/gina.txt
[01:33] <sabdfl> Kinnison: only the first one is critical
[01:33] <sabdfl> single suite, sinlge arch would be fine
[01:33] <sabdfl> use hoary
[01:33] <sabdfl> it's getting uploads
[01:33] <Kinnison> single suite single arch still needs the overrides and removals stuff
[01:33] <Kinnison> otherwise our copy of hoary won't get cleaned up
[01:34] <sabdfl> right
[01:34] <sabdfl> can't just drop the publishing table each run?
[01:34] <Kinnison> I guess I could do it that way if you'd prefer
[01:34] <Kinnison> That'll get us up and running faster I guess
[01:34] <Kinnison> I'll do that
[01:35] <Kinnison> how about now?
[01:36] <sabdfl> rock
[01:36] <Kinnison> Cool
[01:36] <Kinnison> Okay; that's what I'm aiming for with gina
[01:37] <Kinnison> Then I'll start
[01:37] <Kinnison> Could I ask you; as a side-line; to look at the database/publishing.py and related files and suggest a split which would be sane? I've not got the hang of predicting these things yet :-)
[01:45] <ddaa> trying to use str.translate on a unicode string gives an error.
[01:46] <ddaa> Can somebody point me at the right thing to use? That may save me some doc-searching time.
[01:57] <stub> ddaa: use unicode.translate instead?
[01:57] <ddaa> Ha... not quite I was doing...
[01:57] <ddaa> Instead I was simply encoding the input to utf8.
[01:58] <ddaa> context: I'm writing a job name munging tool to work around the broken shell quoting in cscvs.
[01:59] <ddaa> The error was: exceptions.TypeError: character mapping must return integer, None or unicode
[02:02] <ddaa> Ho... apparently it's already using unicode.translate since the output is unicode... the trick seems to be it accepts a unicode string as translation table and I gave a plain string...
[02:02] <ddaa> stub: thanks
[02:07] <ddaa> duh... now that I handle the unicode string okay, it's twistd which complains because it gets a unicode instead of a str...
[02:07] <Kinnison> unicodeobject.encode('utf-8') -> str object
[02:07] <Kinnison> str.decode('utf-8') -> unicode object
[02:07] <Kinnison> approx
[02:07] <stub> bad twisted!
[02:08] <ddaa> Kinnison: ha, simpler than "import codecs; codecs.getencoder('utf8')(text)"
[02:08] <Kinnison> ddaa: aye
[02:08] <ddaa> After all, I'm going utf8ize it, then...
[02:11] <ddaa> Okay... that works.
[02:12] <ddaa> I mean, I'm hitting another bug, but that part works...
[02:40] <Kinnison> sabdfl: Section and Component don't have owner columns -- are they officially shared among all the distributions then?
[02:41] <sabdfl> Kinnison: yes
[02:41] <Kinnison> sabdfl: Cool; any complaints if I propose making them unique then?
[02:41] <sabdfl> ah. very good thinking
[02:42] <Kinnison> hmm; someone appears to have beaten me to it
[02:42] <Kinnison> I really must get gina importing into the new db so I stop asking these things :-)
[02:45] <cprov> Kinnison: hi, can we get Librarian running on mawson ?
[02:45] <Kinnison> cprov: I started one yesterday I'm sure
[02:45] <ddaa> lifeless: you are probably asleep, but I straced a hang at "launched local CVS server"
[02:46] <Kinnison> dsilvers@rosetta:~ $ ps ax | grep libra
[02:46] <Kinnison>  6976 ?        S      0:00 /bin/sh ./run-librarian.sh
[02:46] <Kinnison>  6977 ?        S      0:00 /usr/bin/python2.3 /usr/bin/twistd -noy /srv/launchpad.ubuntu.com/launchpad-dogfood/lib/canonical/librarian/server.tac
[02:46] <ddaa> lifeless: one of the threads hangs on select, the other hangs on futex.
[02:46] <lifeless> ddaa: mail it to me ?
[02:46] <ddaa> Aye.
[02:46] <ddaa> Btw, I'm in process of trying to test taxi.py...
[02:46] <lifeless> thank you
[02:47] <lifeless> I was going to do that today, ended up bazzing all day
[02:47] <ddaa> But roadblocks keep popping up...
[02:48] <ddaa> I have a "munge job names" hack ready. I want to test it over the whole process before merging.
[02:48] <ddaa> lifeless: the robertcollins.net mail is still okay?
[02:48] <cprov> Kinnison: I had already ran gina successfully on mawson, but it is unusefull w/o Librarian, I think
[02:48] <lifeless> ddaa: yes
[02:48] <Kinnison> cprov: librarian is running
[02:49] <Kinnison> cprov: the uploadfactory is on port 9090
[02:49] <Kinnison> cprov: if I star-merge will I get your gina changes to make her run on mawson?
[02:50] <cprov> Kinnison: fine, btw, I'm working on CURRENT srcpkgrelease replacement
[02:50] <cprov> Kinnison: just few minutes, I will request merge for PQM
[02:51] <Kinnison> cprov: cool; thanks
[02:54] <ddaa> lifeless: debugging data sent
[02:54] <ddaa> I'll stand by if you want additional in-vivo data.
[02:54] <lifeless> ddaa: debug-bomb the native protocol please.
[02:55] <ddaa> lifeless: you really should bump down the compression...
[02:55] <ddaa> "debug-bomb"? "native protocol"?
[02:55] <lifeless> modules/CVS/__init__.py
[02:56] <lifeless> start with hasProtocol() and follow your nose
[02:56] <lifeless> there is a cvs client implementation
[02:56] <ddaa> okay, got the native part...
[02:56] <lifeless> if its hung there, then its reading from an empty pipe.
[02:56] <ddaa> you want me to spill printlines all over the place, right?
[02:56] <lifeless> killing the cvs server should resume the process.
[02:56] <ddaa> There is no cvs process.
[02:57] <ddaa> "pgrep cvs" gives nothing.
[02:57] <lifeless> self.logger().debug statements go to the log, and are useful.
[02:57] <lifeless> no cvs process - then what is the select selecting on ?
[02:57] <ddaa> you tell me...
[02:57] <lifeless> what fd ?
[02:58] <ddaa> select(6, [0 5] , [] , [] , NULL <unfinished ...>
[02:58] <lifeless> in the strace, what was opened on that fd most recently ?
[03:04] <ddaa> sorry boss, the strace folks do not yet support tracing system calls before the process is attached.
[03:05] <ddaa> I suspect this feature is not on top of their todo...
[03:13] <lifeless> lol
[03:15] <ddaa> speculation: spawning cvs has failed for some reason only known to cvs. The twisted stuff has a intercepted the sighup. The thread is blocking trying to read on a pipe for a dead process.
[03:16] <ddaa> or something equally crackful... 
[03:17] <lifeless> ddaa: no, the spawn succeeded
[03:17] <lifeless>  2004/10/28 14:15 CEST [Broker,client]  WARNING:root:launched
[03:17] <lifeless>         local CVS server
[03:17] <lifeless>         for :local:/home/david/canonical/launchpad/botmaster/slave/buildbot-jobs/vte_HEAD_import.job/vte@arch.ubuntu.com/vte--MAIN--0/cvs_temp_repo
[03:17] <lifeless> 'launched'
[03:17] <lifeless> that is logged stricly after the the pipes have been created.
[03:17] <ddaa> sure, that does not mean cvs did not die immediately after.
[03:17] <lifeless> sure.
[03:18] <lifeless> it might be a lost signal
[03:18] <ddaa> Yup.
[03:18] <ddaa> That would be consistent with the insanity that led to arch._twisted.
[03:18] <lifeless> so what you need to do is to run strace from before you start the job.
[03:18] <ddaa> imho that not really working around a pyarch bug, just working are twisted's lack of tolerance.
[03:19] <lifeless> ddaa: iynsho.
[03:19] <lifeless> its actually a unix process model problem.
[03:19] <lifeless> In Your Not So Humble Opinion
[03:19] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: missed clauseTables, people traversed by name, gina/nicole running on mawson (patch-708)
[03:19] <ddaa> Well, I may be wrong.
[03:20] <ddaa> That's speculation.
[03:20] <lifeless> actually, it can't be a dropped signal
[03:20] <lifeless> if the signal is recieved, the pipe is closed at the far end, read will generate SIGPIPE
[03:20] <lifeless> teisted doesn't AFAIK install SIGPIPE handlers
[03:21] <lifeless> ddaa: can you please try this:
[03:21] <ddaa> whatever it does, the effect I observer are undistinguishable from that.
[03:21] <lifeless> tla register-archive
[03:21] <lifeless> http://bazaar.canonical.com/archives/thelove@canonical.com
[03:21] <ddaa> ack
[03:21] <dilys> New bug 2150 for Launchpad/Rosetta: Fix the way we store fuzzy strings in the database schema
[03:21] <dilys> https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2150
[03:22] <ddaa> lifeless: whose key is used there?
[03:22] <lifeless> pqm's
[03:22] <lifeless> good point.
[03:24] <cprov> Kinnison: new gina merged on RF, please try .
[03:24] <ddaa> lifeless: you want be to build and install baz, right?
[03:24] <lifeless> no
[03:24] <lifeless> just to check that that archive location is abrowse -s 'able for you
[03:25] <lifeless> http://bazaar.canonical.com/packages/debs/
[03:25] <lifeless> is up and going now
[03:25] <lifeless> cause thom is a legend
[03:25] <lifeless> nay, a god even.
[03:25] <Kinnison> cprov: merged already?
[03:25] <ddaa> Looks like abrowse -s is happy.
[03:26] <cprov> Kinnison: yep
[03:27] <Kinnison> cprov: dilys hasn't mentioned it; hence my confustion
[03:27] <cprov> Kinnison: let's plan something for today, we have to run gina and nicole on mawson, definitly, as milestone :)
[03:28] <Kinnison> cprov: I concur
[03:28] <cprov> Kinnison: dilys doesn't like me :)
[03:29] <ddaa> lifeless: any idea what the apt-sources line should look like?
[03:29] <sabdfl> lifeless: how are we looking for the automatic sync-testing on galapagos?
[03:30] <cprov> Kinnison: btw, do you have something ready for publishing the query for and update the last CURRENT srcpkgrelease to SUPERCCED before insert a new one, I mean, true publishing system for gina ...
[03:31] <lifeless> ddaa: its not a repository
[03:32] <lifeless> but I believe you can just do deb  path  ./
[03:32] <ddaa> No good. I want crack-of-the-day, not crack-of-the-last-time-I-visited-the-page.
[03:33] <ddaa> "path" being what?
[03:33] <lifeless> sabdfl: haven't heard from james re the account for that. code wise, I want to get the production drop onto macquarie and galapagos done tomorrow, which updates tazi
[03:33] <lifeless> and then I'll start on the unattended-scheduling, which I'm estimating @ a couple of days
[03:33] <sabdfl> ok
[03:34] <sabdfl> vendor, default branches, done? you're running out of space between 95% and 100% :-)
[03:34] <lifeless> no progress at all since last phone call.
[03:34] <Kinnison> cprov: sabdfl and I agreed that initially gina will just totally repopulate the publishing tables each run
[03:34] <lifeless> been baz bootstrapping
[03:35] <Kinnison> cprov: over time; I'll write the code to do superceded etc and at that point we can add support for it into gina
[03:35] <Kinnison> cprov: for now; sabdfl and I agreed that we just wanted daily imports working :-)
[03:35] <Kinnison> cprov: see https://chinstrap.warthogs.hbd.com/~dsilvers/gina.txt for the plan :-)
[03:35] <cprov> Kinnison: fine
[03:36] <ddaa> Anybody aware of a debug-enabled variant of popen2.Popen3?
[03:37] <Kinnison> cprov: what did you change in grabber.py ?
[03:38] <cprov> Kinnison: nothing .. I just change back some particular conf 
[03:38] <sabdfl> cprov, Kinnison, it's ok for the moment if it just shows the current set as published, and all older ones are just "there"
[03:39] <cprov> Kinnison: which pass to use on https://chinstrap ?
[03:39] <sabdfl> in the sense that you can see old releases of a source package in the system, but not superceded info
[03:39] <sabdfl> for the moment
[03:39] <Kinnison> sabdfl: yeah; that'd be the side-effect if we blat the publishing records each time
[03:39] <sabdfl> no problem for this week
[03:39] <Kinnison> cprov: erm, wartyhoa... I think
[03:40] <cprov> Kinnison: sabdfl: I'm just affaid to have two or more CURRENT srcpkgrelease
[03:40] <lifeless> ddaa: anyway, as chinstrap isn't ppc, you need to roll your own anyway :)
[03:40] <Kinnison> cprov: define 'current' if you mean in the publishing tables then that won't happen
[03:40] <Kinnison> cprov: not until we do things properly :-)
[03:40] <ddaa> lifeless: what does ppc has to do with that???
[03:40] <lifeless> oh right, you have an intel desktop, my bad.
[03:42] <cprov> Kinnison: I do mean publishing tables, yes, gina always insert new packages as published, if I have a new release of it, it will be inserted as published too
[03:42] <Kinnison> cprov: yeah; but we're going to empty the publishing tables before the gina run
[03:42] <Kinnison> current gina gives me:
[03:42] <Kinnison> libpq.OperationalError: ERROR:  insert or update on table "sourcepackagerelease" violates foreign key constraint "$4"
[03:42] <Kinnison> DETAIL:  Key (component)=(3) is not present in table "label".
[03:42] <Kinnison> against the current schema
[03:43] <Kinnison> somehow the sourcepackagerelease component column has been pointed at the label table
[03:45] <Kinnison> stub: ping?
[03:45] <cprov> Kinnison: are you running over a DB created by lp-sampledata ?
[03:45] <cprov> Kinnison: it is looking for 'restricted' component
[03:45] <Kinnison> cprov: No; just a plain 'make' in the schema dir for now
[03:46] <stub> Kinnison: That dates back to the dawn of the database (database/schema/archives/launchpad-1-00-0.sql)
[03:46] <Kinnison> cprov: actually; universe :-)
[03:46] <cprov> Kinnison: that is it ...
[03:47] <Kinnison> stub: can you please commit a fix to make that point at component(id) instead of label(id) ?
[03:47] <cprov> Kinnison: do you have the component entry ? wierd
[03:47] <stub> It is nullable - I guess people just stick null in it. I think it must have been from an old use of the label table. I assume it is supposed to reference the component table?
[03:48] <Kinnison> stub: yes please
[03:49] <stub> yup
[03:49] <Kinnison> there must have just been entries in the label table before now
[03:49] <ddaa> what's the extra bit needed to enable the output of self.logger().debug?
[03:49] <ddaa> lifeless: ^
[03:51] <Kinnison> yay: libpq.OperationalError: ERROR:  current transaction is aborted, commands ignored until end of transaction block
[03:51] <lifeless> #       TODO convenience for interactive debugging move somewhere importable.
[03:51] <lifeless> #        import logging
[03:51] <lifeless> #        logging.basicConfig()
[03:51] <lifeless> #        logging.getLogger().setLevel(logging.CRITICAL)
[03:51] <lifeless> #        logger=logging.getLogger('a')
[03:51] <lifeless> #        logger.setLevel(logging.DEBUG)
[03:51] <lifeless> #        logger.debug('fooooo')
[03:51] <ddaa> Wereizdat?
[03:51] <lifeless> thats in test_CMDS.py
[03:51] <lifeless> when I needed to do something similar
[03:52] <lifeless> in buildbot, if you are running the slave as normal, you can just edit buildbot_slavecommand.py
[03:52] <lifeless> and tweak the level there.
[03:53] <lifeless> ddaa: there is a todo to pass this down as part of the job.
[03:53] <lifeless> its not intended to be per-slave.
[03:56] <ddaa> Mh... the self.debug=0 bit i guess...
[03:57] <lifeless> please, just change your slave level.
[03:57] <ddaa> ...
[03:58] <ddaa> what ... is ... a ... slave ... level ...
[03:58] <lifeless> in buildbot_slavecommand.py
[03:58] <lifeless> look for WARNING
[03:58] <BradB> morning
[03:59] <ddaa> ha... was looking at the wrong file...
[03:59] <stub> Morning
[03:59] <ddaa> was looking at buildbot/slavecommand.py...
[03:59] <lifeless> heh. we want importd/buildbot_slavecommand.py :)
[04:04] <ddaa> okay, I'll keep that around when building. That will probably prove useful.
[04:04] <ddaa> Of course, this time the server is not...
[04:04] <ddaa> (me stops and starts the import from scratch, just for kicks)
[04:07] <Kinnison> Okay; zhongshan has something broken with its cursors or something. disabling them helps a lit
[04:07] <Kinnison> cprov: I have a gina running now against the new schema; with my build record fixes
[04:07] <Kinnison> cprov: I'll let you know how it goes
[04:08] <cprov> Kinnison: you rock !!
[04:08] <Kinnison> cprov: currently running on zhongshan because I have good debug-ability there
[04:08] <Kinnison> cprov: I'll run it on mawson once I'm satisfied :-)
[04:11] <cprov> Kinnison: ehe zhongshan is gives a pretty better environment the mawson :)
[04:12] <cprov> Kinnison: starting with this crap colored prompt <wink>
[04:13] <kiko> lol
[04:13] <kiko> man I am SLEEPY today
[04:13] <Kinnison> kiko: I know what you mean
[04:21] <lifeless> yay, it failed to build.
[04:26] <Kinnison> cprov: I think it's about 10% of the way through the import
[04:27] <cprov> Kinnison: everything working ?? I mean Librarian and so on ... are you importing just main and restricted ?
[04:29] <Kinnison> cprov: everything working; I'm importing it all for a test
[04:29] <Kinnison> cprov: I'm about to go prodding at the build table (I have a perioding commit in gina so if she stops; she doesn't lose all her hard work)
[04:30] <Kinnison> dsilvers@petitemort:~ $ ssh snogshan
[04:30] <Kinnison> ssh: snogshan: Name or service not known
[04:30] <Kinnison> where did *that* misspelling come from?
[04:31] <kiko> ork
[04:32] <Kinnison> boo hiss; my build patch didn't work
[04:39] <ddaa> Canonical Productions presents, a new entertainment series on your channel: "Who Killed Gina". Starring: Ubuntu, Linux, Zope, Twisted, Plone...
[04:39] <Kinnison> ...and Daniel (the wider)
[04:39] <ddaa> ... The Sushi Place Near Mark's...
[04:39] <lifeless> and cartman
[04:39] <carlos> cprov: ok, I have the .sql you gave me imported into the database, do you have it already connected with our arch repository?
[04:40] <carlos> I mean, from the package information, how could I construct a "tla get" command?
[04:40] <cprov> carlos: not yet, but Kinnison is working on it 
[04:41] <carlos> hmm, is there a bug report for that task?
[04:41] <ddaa> lifeless: ha... I meant something else, but nm :-)
[04:42] <ddaa> So... pyarch/baz
[04:42] <carlos> Kinnison: ?
[04:43] <Kinnison> whomewhat where?
[04:43] <carlos> Kinnison: about the soyuz <-> arch connection
[04:43] <ddaa> Python way to look for a command in the path w/o running it? Get the exit status of sh -c 'which baz > /dev/null', or is there something more pythonic?
[04:44] <carlos> Kinnison: cprov said you are working on it, is there a bug report for that task so I can be notified when it's ready?
[04:44] <Kinnison> carlos: why would I be working on that?
[04:44] <carlos> Kinnison: cprov say that :-P
[04:44] <Kinnison> carlos: *KEYBUK* is doing arch stuff; dunno who's doing the soyuz integration :-)
[04:44] <Kinnison> cprov: stop giving me new work to do or I shall fly out to brazil and tickle you
[04:44] <carlos> :-P
[04:47] <carlos> lifeless: Do you know anything about the soyuz/arch integration?
[04:47] <lifeless> carlos: keybuk
[04:47] <carlos> ok
[04:48] <carlos> perfect, thanks
[04:50] <cprov> Kinnison: you are welcome to see waht is waiting for you :)
[04:50] <cprov> s\waht\what
[04:51] <Kinnison> ?
[04:55] <ddaa> How about adding a arch.config module which stores the spawing strategy name, the command name (and maybe other things) and a .config()
[04:55] <ddaa> and a .configure() method in various modules. How does that sound?
[04:56] <lifeless> ddaa: context ?
[04:56] <ddaa> Want to make the name of the command spawned for arch operations configurable.
[04:57] <ddaa> The current spawning strategy stuff works with an object which gives no way to modify that after the object is created.
[04:57] <ddaa> Because spawning strategies store the command name. No good reason for that though...
[04:58] <ddaa> I cannot be a module variable though because it would make testing problematic.
[04:59] <ddaa> Ha yeah, the name is stored in the strategy to avoid redundant data. The command name is given only once at object creation.
[05:00] <ddaa> An easy way is running the command-name tests at module import-time, when the strategy is created, but that sucks, because it gives no clean to customize the command name.
[05:01] <ddaa> So, considering my recent canonical.lp experience, I'd rather move the configuration stuff in a separate, low-level module.
[05:01] <ddaa> There is also the fact that the command name should be configurable easily w/o having to import arch._tla
[05:01] <ddaa> Therefore arch.config sounds good.
[05:02] <lifeless> having the name is fine, IMO, just have multiple instances of the strategy/.
[05:02] <lifeless> what prevents that ?
[05:02] <ddaa> I do not parse you: "having the name is fine"
[05:02] <lifeless> in the instance.
[05:02] <lifeless> 'this is a spawning strategy for tla'
[05:02] <ddaa> Yeah exactly.
[05:02] <lifeless> 'this is a spawning strategy for cvs'
[05:03] <lifeless> so I don't think you need to change anything.
[05:03] <ddaa> That's it's meant to be.
[05:03] <ddaa> Yes.
[05:03] <lifeless> or are you looking at how to detect baz ?
[05:03] <ddaa> Actually, I want to decouple command name choice from spawning strategy choice.
[05:04] <lifeless> right.
[05:04] <lifeless> so refactoring this is easy....
[05:04] <lifeless> start be replacing all hardcoded 'tla' that needs to change with a call to a method
[05:04] <lifeless> hardcode that method to return 'tla'
[05:04] <Kinnison> w00
[05:04] <Kinnison>  builds
[05:04] <Kinnison> --------
[05:04] <Kinnison>      44
[05:05] <Kinnison>  packages
[05:05] <Kinnison> ----------
[05:05] <Kinnison>        71
[05:05] <lifeless> that method can be a module level one in this case, as you don't really have an appropiate class handy.
[05:05] <lifeless> so this is correctness preserving.
[05:05] <ddaa> lifeless: EOF
[05:05] <ddaa> ?
[05:05] <lifeless> step two. in that method, put your policy for determining the name. (i.e. search the path for baz, then for tla)
[05:06] <lifeless> this adds baz support.
[05:06] <ddaa> Yeah, that's the obvious thing to do so far...
[05:06] <lifeless> but: knowing the name is baz won't be enough over time
[05:06] <lifeless> you need to couple the tla version information you have with the name.
[05:07] <Kinnison> lifeless: will baz have the cacherev/revlib fix?
[05:07] <lifeless> Kinnison: eh?
[05:07] <ddaa> lifeless: you are done?
[05:07] <Kinnison> lifeless: the one to make revlibs use cacherevs; or is that in already?
[05:07] <lifeless> ddaa: well no, but you see where I'm going
[05:07] <lifeless> I think
[05:07] <lifeless> Kinnison: don't know, right now, 1am, don't care. :)
[05:07] <ddaa> Now the pb is that 'tla' is hard coded in only one place. At the top-level of arch._tla and it reads "spawn = DelayedGuessedSpawningStrategy('tla')"
[05:07] <lifeless> most importantly, we will be bugfixing everythng we can lay our hangs on.
[05:08] <Kinnison> lifeless: fair enough
[05:08] <lifeless> so a question like 'will baz fix foo' - the answer is 'duh'.
[05:08] <ddaa> which means that going down the road you point does not make it possible to decouple spawning strategy and command name.
[05:09] <lifeless> ddaa: well, I'm suggesting they be completely decoupled. you have a command description object, and a spawn strategy object, and one uses the other.
[05:09] <ddaa> Except if there is a way to rebuild the command strategy with the right name w/o requiring knowledge of either. That would be the job of the arch.configure()
[05:10] <ddaa> Yeah. I see.
[05:10] <ddaa> Just said that way it makes sense.
[05:10] <lifeless> ddaa: I'm fading, can't focus well enough - but arch.configure feels wrong to me - wrong enough not to ignore.
[05:11] <ddaa> Mh...
[05:11] <ddaa> So... it's about mutating the command description object, so the spawning object needs not know anything, right?
[05:12] <lifeless> right
[05:12] <ddaa> And giving a reference at some module level to access the command desc object.
[05:12] <lifeless> you just need a new command description object instance for baz, and select that when you want it.
[05:12] <ddaa> Hu?
[05:12] <lifeless> i.e. arch.implemention
[05:13] <lifeless> we're saying the same thing
[05:13] <ddaa> That's the "select that" part which is causing me trouble.
[05:13] <ddaa> From the start.
[05:14] <ddaa> The spawning strategy gives no access to the command desc so far.
[05:14] <lifeless> thats what I was stepping you through refactoring
[05:14] <ddaa> Which I could change, but I sorta like that way because it made DelayedGuessedSpawningStrategy transparent...
[05:15] <lifeless> it would stay transparent. this is api preserving.
[05:16] <lifeless> tell you what. this might be best shown collaboratively. I can show you on a shared screen session, or in irc pastes, after I sleep
[05:16] <ddaa> Go bed pal. I need to sit on it for a bit.
[05:24] <ddaa> mh... the arch._arch thing turns out it was a bad idea after all...
[05:24] <ddaa> should be something like... arch.implementation...
[05:28] <lifeless> oh yeah.
[05:28] <ddaa> arch.backend would be a better name though.
[05:28] <lifeless> http://bazaar.canonical.com/packages/src/
[05:28] <dilys> Merge to thelove@canonical.com/bazaar--devo--1.0: add unit test dead chickens to libarch (patch-17)
[05:28] <lifeless> auto updates on commit :_)
[05:29] <lifeless> get your crack of the minute right here folk
[05:30] <lifeless> get your debs here baby!
[05:30] <ddaa> 16:28... have to know it's the UK tz.
[05:30] <lifeless> dude, it so doesn't matter.
[05:30] <ddaa> Yeah...
[05:30] <lifeless> the http timestamp is in UTC regardless.
[05:31] <ddaa> I'd have to annoy tom to he makes that a proper repository.
[05:31] <lifeless> try this as an apt repo:
[05:31] <ddaa> kewl
[05:31] <lifeless> deb http://bazaar.canonical.com/packages/debs/ ./
[05:33] <lifeless> ouchies.
[05:34] <ddaa> maybe it's not a repo, after all.
[05:34] <lifeless> no
[05:34] <lifeless> I'll need to create a Packages file
[05:34] <ddaa> ho...
[05:38] <carlos> see you later
[05:39] <ddaa> properties are cute... but they blow the seamlessness of modules and instances.
[05:42] <lifeless> yet another reason that modules should simply be class instnaces
[05:42] <lifeless> or better yet, instances of 'namespace', and do away with the whole module nonsense :)
[05:42] <ddaa> sounds like smalltalk :-)
[05:42] <Kinnison> only if you get rid of the class concept too and have namespaces only please
[05:42] <spiv_> ddaa: Just insert an instance into sys.modules directly.
[05:43] <spiv_> ;)
[05:43] <lifeless> Kinnison: you lisper at heart
[05:43] <Kinnison> (state 'pah (lifeless))
[05:44] <lifeless> lost me
[05:44] <Kinnison> random broken lispish equivalent of 'lifeless: pah'
[05:44] <lifeless> ah
[05:45] <Kinnison> pah -> lifeless
[05:45] <Kinnison> or however you'd do it in smalltalk
[05:45] <ddaa> That sounds good so far, but implementation is something that is totally private...
[05:46] <ddaa> A arch.backend object should not give the user access to all the crap behind. That's the reason because arch._arch is protected. The arch classes provide abstraction over the backend.
[05:47] <ddaa> Therefore, a arch.config which does not expose the actual backend internal would be more appropriate.
[05:48] <ddaa> not... if I add a level of indirection :-)
[05:48] <lifeless> ddaa: a) nothing in python is private, by definition. b) occams razor so applies here
[05:49] <lifeless> ddaa: even then its still not private, then you are just playing namespace games to stop users getting at what they can get at anytime they want.
[05:49] <ddaa> Sure, _protected is a convention. But conventions are operational.
[05:49] <lifeless> tomorrow, I won't make sense till then
[05:49] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: SourcepackageRelease.component foreign key fix, index for kiko, drop decoy BugInfestation table (patch-709)
[05:50] <ddaa> The point being the backend configuration is public, not the backend guts is private to pyarch. I can access my own private parts.... Demeter.
[05:50] <Kinnison> stub: is the 'foreign key fix' there the component fix we discussed earlier?
[05:50] <stub> yup
[05:50] <Kinnison> coolie
[05:51] <ddaa> lifeless: no need for you to make sense, I'm starting to make sense myself.
[05:51] <Kinnison> cprov: gina exploded at me with a librarian error; I'm looking into it
[05:51] <ddaa> One reason that issue is suddenly acute, is that there also the arch._tla.logger, the arch._tla.spawn which should not be there.
[05:51] <Kinnison> cprov: also; sabdfl wants us to import hoary not warty to begin with :-)
[05:52] <ddaa> So, with the command name, than makes three. Time to clean it up.
[06:16] <cprov> Kinnison: which librarian error ?
[06:16] <Kinnison> Argh; the librarian is returning an alias which isn't in the db
[06:17] <cprov> Kinnison: hoary really looks more interesting to for dogfood and also quite easy to do 
[06:17] <Kinnison> cprov: yeah; but until I work out why the librarian is returning aliases not in the db I'm not sure what to do
[06:17] <cprov> Kinnison: uhm, wierd as the entire librarian behavior 
[06:17] <spiv_> Kinnison: Strange :/
[06:18] <Kinnison> spiv_: aye; strange indeed :-(
[06:18] <cprov> spiv_: hi, dude ... how is it going ?
[06:18] <Kinnison> spiv_: how can I get debugging info out of the librarian?
[06:22] <stub> By any chance are you getting the file id, not the alias id?
[06:22] <spiv_> Kinnison: Hmm, what sort of info do you need?
[06:23] <spiv_> Kinnison: It's probably already dumping various messages into twistd.log.
[06:24] <spiv_> Kinnison: If you're desperate, you can get it to open a port that you can telnet into and get a (pseudo) python prompt on the running process.
[06:24] <spiv_> (I think Twisted SVN may support sshing for that, too ;)
[06:25] <Kinnison> stub: nup; the file id didn't come out either :-(
[06:25] <Kinnison> spiv_: I'll look in twistd.log
[06:25] <spiv_> cprov: Pretty good.
[06:26] <Kinnison> spiv_: Hmm, no twistd.log
[06:26] <spiv_> How did you start it?
[06:26] <Kinnison> twistd -noy ...../server.tac
[06:26] <stub> also, is it connecting to the correct database?
[06:26] <Kinnison> yes; correct db
[06:26] <spiv_> Oh, -n... so it didn't fork.  In that case it logs to stdout.
[06:27] <Kinnison> right; so I'm seeing no useful logging info then
[06:27] <Kinnison> how can I turn up the verbosity?
[06:27] <Kinnison> seeing the sql would be a great boon
[06:27] <spiv_> vim a_file.py; (insert print statements)  ;)
[06:27] <spiv_> It's using SQLObject?
[06:28] <Kinnison> Yes
[06:28] <stub> turn on statement logging in postgresql
[06:28] <Kinnison> How do I do that?
[06:29] <Kinnison> And where does it log to? and can I get to that place on zhongshan?
[06:29] <stub> oh - thought you were on a local box.
[06:30] <Kinnison> nup :-(
[06:30] <Kinnison> I need an archive; and I don't have the bw to burn to mirror it to home
[06:30] <spiv_> Ugh, it's actually kinda messy accessing that with the initZopeless stuff.  Hmm...
[06:31] <Kinnison> Can I not set something simple like SQLBase.loglevel or something?
[06:32] <stub> think so, but I don't remember the attribute to set. I'm sure it is documented somewhere ;)
[06:32] <spiv_> Kinnison: The simplest way atm is probably to edit sqlobject/dbconnection.py, line 28, and hard-code that line to True..
[06:33] <spiv_> Unfortunately, the sqlos/sqlbase layers get in the way of doing this nicely atm.
[06:33] <spiv_> Argh, in fact sqlos hard-codes it to 0.
[06:34] <spiv_> So, edit lib/sqlos/adapter.py, line 46, and set that to True.  Ick.
[06:38] <Kinnison> Okay; it's getting stuck on an insert failing
[06:38] <Kinnison> I think
[06:39] <Kinnison> maybe not
[06:42] <spiv> Kinnison: I'm about to merge andrew.bennetts@canonical.com/launchpad--devel--0--patch-223, it adds a debug flag to initZopeless.
[06:43] <spiv> Which will turn on the SQLObject debugging, i.e. sql statement logging.
[06:43] <Kinnison> right
[06:45] <spiv> Hopefully it will help you figure out what's going on, assuming you can reproduce it...
[06:46] <Kinnison> Irritatingly it's now running okay
[06:46] <Kinnison> I need to wait for it to fail again
[06:51] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: Add debug flag to initZopeless (patch-710)
[06:53] <spiv> Kinnison: If you merge that, you can change server.tac to say "initZopeless(debug=True)".
[06:53] <Kinnison> spiv: once I can get the bastard to fail again I'll do that; thanks
[06:55] <Kinnison> stub: can you update mawson's db with that foreign key fix?
[06:56] <stub> That would be naughty (running bits of the database upgrade without a code update), but I think we can get away with it in this case.
[06:58] <stub> done
[07:12] <stub> night
[07:12] <spiv> stub: G'night.
[07:16] <Kinnison> Right, I can reproduce it
[07:16] <Kinnison> but the sql log is just showing that it goes through the motions and doesn't commit the transaction for some reason
[07:19] <Kinnison> I think I know what it is
[07:22] <BradB> cprov: ping
[07:25] <Kinnison> Okay; I can fix it if I cause addAlias to generate a transaction if it didn't have one
[07:48] <Kinnison> cprov: ping?
[07:50] <cprov> Kinnison: pong
[07:50] <Kinnison> cprov: I have a few librarian fixes to finish and then I'll be in a position to get things going with a hoary import on mawson
[07:51] <cprov> Kinnison: fantastic !
[07:51] <cprov> Kinnison: do you need help ? 
[07:51] <Kinnison> cprov: things will be fine as long as the katie db on mawson is ready
[07:55] <cprov> Kinnison: fine
[08:14] <Kinnison> rah; it worked
[08:14] <cprov> Kinnison: great
[08:22] <dilys> Merge to rocketfuel@canonical.com/launchpad--devel--0: librarian transaction fixes and gina build fix (patch-711)
[08:22] <Kinnison> w00p
[08:24] <Kinnison> hihi kiko
[08:26] <kiko> kiko the brave
[08:29] <Kinnison> What's the right way to create a distrorelease and distroarchrelease in the dogfood db?
[08:29] <Kinnison> do I just go in and do it with SQL; or do we have a UI for it?
[08:31] <kiko> there is UI for that in Soyuz
[08:32] <Kinnison> "" A system error occurred.""
[08:32] <Kinnison> If this can't be fixed in the next couple of minutes; I'm gonna hand-fiddle the db 'til I can run gina
[08:33] <Kinnison> or I can leave gina until later to start
[08:34] <Kinnison> kiko, cprov: your call
[08:34] <kiko> Kinnison, can you provide a traceback at least?
[08:34] <Kinnison> kiko: how?
[08:34] <kiko> your DB is cracked up somehow, btw
[08:34] <kiko> using the debug port?
[08:35] <Kinnison> debug port? How do I get at that? this is launchpad on mawson
[08:36] <kiko> BradB|lunch, didn't elmo set us up to allow access to the debug port?
[08:36] <kiko> Kinnison, there's a port listening HTTP that can fix that up
[08:38] <kiko> cprov?
[08:38] <cprov> Kinnison: forget it and create distro and distrorelease by hand, please
[08:38] <kiko> cprov, is creating a distro broken?
[08:39] <cprov> kiko: yes
[08:39] <Kinnison> cprov: okay
[08:39] <Kinnison> May I blat the warty distrorelease?
[08:39] <Kinnison> It'll save time
[08:40] <kiko> bah
[08:41] <Kinnison> I'll take that as 'yes'
[08:42] <kiko> yeah.
[08:42] <Kinnison> why the fuck are there things published to this distrorelease?
[08:42] <Kinnison> was that just random test data? can I blat it?
[08:43] <Kinnison> well; since sabdfl wants me to blat publishing data each time; I guess I can...
[08:43] <Kinnison> noone should be using the publishing records outside of lucille/etc anyway
[08:45] <Kinnison> libpq.DatabaseError: FATAL:  database "katie" does not exist
[08:45] <Kinnison> who told me katie was ready?
[08:52] <Kinnison> Grr, the mirror lacks hoary properly
[08:53] <Kinnison> I can't do this now
[08:53] <Kinnison> Moan at elmo about how the tagfiles for hoary are empty
[09:29] !lilo:*! Hi all.  If you're involved with accounting and/or bookkeeping for a small FOSS community (or other) not-for-profit entity, please consider maintaining a presence on #accounting .... support and consultation about accounting issues.  Thanks!
[10:18] <BradB> kiko: it does look like it. 9021 should be open, but isn't.
[10:20] <BradB> kiko: when do you want to talk about what you guys can work on in malone btw?
[10:20] <kiko> BradB, I'll write to admins
[10:20] <BradB> ok
[10:20] <kiko> hum hum
[10:21] <kiko> I'm at a client today and tomorrow
[10:21] <BradB> it'll be a short conversation
[10:21] <BradB> ok
[10:21] <kiko> but cprov and debonzi are happily hacking away till them
[10:21] <kiko> hmm
[10:21] <kiko> maybe tonight a bit later if I catch you on
[10:21] <BradB> ok