[12:01] 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] s/new a/need a/ [12:02] another possibility would be to have pitti use it for tracking security issues only [12:02] security is the toughest test case for a bug tracker :-) [12:02] cool [12:03] that has the advantage of being a relatively discrete set of bugs [12:04] workrave, back in 10 if you still need me [12:04] ok, thanks for your feedback [12:06] BradB, is it possible to have a debug port in launchpad.ubuntu.com? [12:08] elmo: ^ ? (debug is on 9021) [12:08] is it now? [12:09] kiko_bz: yeah [12:09] ah, neat. [12:09] it won't work though unless elmo does something to the apache config [12:09] BradB, sure? I can't connect in port 9021 [12:10] debonzi: yep it's listening. the firewall'll block you, of course, but it's listening :) [12:10] screaming on deaf ears [12:10] is elmo the responsable for that? [12:11] debonzi: yep [12:11] elmo, ? [12:13] BradB, cprov has an updated gina run for your schema version I believe [12:14] I don't know how you would go about using it though, given you've already got some data in your DB [12:14] kiko_bz: sounds like a problem for the stud [12:16] in any case [12:16] one thing we *could* do is start a run on *your* database if you like. [12:16] it will take 2h. [12:16] i gotta go play the role of gigalo now [12:16] (just for main) [12:16] hm [12:16] he ran it on soyuz_dogfood [12:17] 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] i gotta go out for a while. === BradB is now known as BradB|out [12:18] it probably won't, but I don't know if it will run :) [12:18] BradB|out: heeh it's your last chance to say "please NO" ... [12:19] cprov, what do you think :) [12:19] cprov, make a dump of the current launchpad_dogfood DB in case it goes wrong. [12:19] FOGO NA BOMBA !! [12:19] you can actually dump your DB with inserts only [12:19] heheh [12:19] which would avoid having to re-run gina [12:19] I don't know if that would blow up because of uniqueness constraints though [12:19] may be simpler to just kick gina again [12:19] if you think you might blow away data, just make sure you have a quick way of unblowing it away [12:20] if you need more input from me though, it'll have to wait, i gotta head out nowish [12:20] just dumping the current launcpad_dogfood should avoid future problems [12:22] 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] ok, am back, will catch up on scrollback [12:23] shame === salgado [~salgado@200-206-134-238.async.com.br] has joined #launchpad [12:24] sabdfl, meet salgado; he's working with us initially on setting up some agreeable sampledata for soyuz [12:25] hey salgado, welcome aboard [12:25] hello sabdfl [12:25] the current size we've paired it down to is 1.4MB bzipped [12:25] I suspect that's still too big [12:25] how many packages would that include? [12:26] salgado? [12:26] we don't need many [12:26] just four or so packages with four releases of each [12:26] heh [12:26] 121 sourcepackages [12:26] how many releases? [12:27] 303 binarypackages [12:27] where is all that size coming from, damn it? people? [12:27] 50 people [12:27] it's a reasonable sample actually [12:27] salgado, from a visual review of the dumpfile, what's taking up most of the space? [12:28] I haven't take a look at it yet. I'll do it now [12:30] 660K from bziped gpgkeys [12:31] 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] project/product descriptions should be blamed too [12:32] blame cprov, he got the data for us ;) [12:33] kiko_bz: there's 20 gpgkeys [12:34] salgado: have you sliced the packages.gz files ? === kiko_bz is now known as kiko [12:35] salgado: or are following another approach ? [12:35] cprov: I used cascade=True on all ForeignKeys() and then I deleted all but the first 50 Persons [12:36] salgado: so, you worked just on DB not in the code itself, fine [12:42] kiko: next step ? store the new dump in a public place ? or turn it our new-sampledata for lp ? [12:42] I would really like to put this up as the new sample data [12:42] but it needs to be a bit smaller [12:42] I think ~800K uncompressed is the limit of what's acceptable [12:58] stub: up early? are bug attachments up and running? [12:58] kiko: then cut it a bit more, let's say 20 persons [12:58] yes [12:58] salgado, how does that sound? [12:58] for 800k uncompressed I think 10 persons is enough [12:58] shoot then === doko [doko@dsl-084-057-020-211.arcor-ip.net] has joined #launchpad [01:12] Merge to rocketfuel@canonical.com/launchpad--devel--0: template fix to avoid traceback when SourcePackage.distro is NULL. (patch-707) [01:16] debonzi rocks [01:23] Merge to thelove@canonical.com/dists--tla--1.3: seal the branch, not used now the name has been chosen (version-0) [01:24] i think malone is a lot slicker than most bug trackers already, from an end-user point of view [01:24] i want an issue tracker so that as many of the "doh" things as possible are handled by non-developer community members [01:24] but i'm not going to hide malone [01:24] just led users to the issue tracker first [01:24] 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] Merge to thelove@canonical.com/tla--devo--1.3: seal the branch, not used now the name has been chosen (version-0) [01:25] 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] the ui weirdness was debated between limi and i [01:26] we decided to try it, we can pull it if it's too weird [01:26] this is the bit where the headline assignment is a rownavigation style table [01:26] with links in it, on the package/product and assignee [01:26] and the links take you to different pages than clicking elsewhere on the row [01:26] it's a handy shortcut if you know what you're doing [01:26] but might be too clever for new users [01:44] kiko: 10 persons, 36 products, 13 sourcepackagereleases: 900K uncompressed [01:45] salgado, looks good; let me check it out [01:45] sabdfl, is 900K closer to acceptable? it triplicates the current data. [01:48] fogo na bomba indeed :-) [01:48] let's see [02:00] kiko! you got your name back! [02:09] night guys [02:09] night [02:09] night sabdfl [02:09] hey sync-man! [02:10] lifeless: we vending our branches yet? [02:10] not quite. taxi had a quirk beyond what spiv fixed. [02:10] on my plate for today - I've done the bootstrap heavy lifting for baz now. [02:11] you get roll a deb of baz to play with anytime now :) [02:11] i saw thelove commits sealing off tla [02:11] gotta love thelove [02:11] i crack myself up [02:12] aren't you guys glad we don't work in the same office every day :-) [02:12] night [02:12] hehehe [02:12] night [02:20] heh === stub yawns [03:44] Merge to rocketfuel@canonical.com/arch-pqm--main--0: dont fail pqm if a PQMException is raised (patch-12) [03:55] Merge to thelove@canonical.com/bazaar--devo--1.0: * added directories (patch-3) === doko [doko@dsl-084-057-106-014.arcor-ip.net] has joined #launchpad === kiko_ [~kiko@200-206-134-238.async.com.br] has joined #launchpad === kiko_ [~kiko@200-206-134-238.async.com.br] has joined #launchpad === BradB|out is now known as BradB|zzz [07:20] Merge to thelove@canonical.com/bazaar--devo--1.0: Re-adding the massively pruned patch logs (patch-4) [09:02] Merge to thelove@canonical.com/bazaar--devo--1.0: Nudge the tla help command to the left (Jivera) (patch-5) [09:51] Merge to thelove@canonical.com/bazaar--devo--1.0: Unsigned checking for Asuffield (Jivera) (patch-6) [09:55] Merge to thelove@canonical.com/bazaar--devo--1.0: I believe the update test is finally working (patch-7) [10:01] Merge to thelove@canonical.com/bazaar--devo--1.0: Adding grab file description to help (patch-8) [10:05] Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing grab so that it registeres the remote archive properly (patch-9) === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad [10:20] Merge to thelove@canonical.com/bazaar--devo--1.0: Various small things, mostly input validations (Abentley) (patch-10) [10:40] Merge to thelove@canonical.com/bazaar--devo--1.0: Selective undo (Monoses) (patch-11) [10:45] Merge to thelove@canonical.com/bazaar--devo--1.0: Path fix for cmd-file-find (patch-12) [11:01] Merge to thelove@canonical.com/bazaar--devo--1.0: Add missing patchlogs from before (patch-13) [11:06] Merge to thelove@canonical.com/bazaar--devo--1.0: Fix for get-changeset and testcase for same (Bentley) (patch-14) [11:13] Merge to thelove@canonical.com/bazaar--devo--1.0: Make tests more solaris friendly (patch-15) [11:19] Merge to thelove@canonical.com/bazaar--devo--1.0: Fixing id for test-get-changeset (patch-16) === ddaa [~ddaa@nemesis.xlii.org] has joined #launchpad [11:50] lifeless: is there a generic command to show the diffs of the last commit? [11:52] Maybe something like "tla get-changeset $(tla logs -r | head -1) ,,last-changeset && find ,,last-changeset/patches -type f | xargs cat" [11:52] stub: what do the new reltriggers do? [11:53] There may be a saner way to do that :) [11:53] spiv_: yowser [11:53] New reltriggers? [11:53] stub: from this morning's refuel: [11:54] @@ -676,6 +679,7 @@ [11:54] UPDATE pg_catalog.pg_class SET reltriggers = 0 WHERE oid = 'sourcepackagerelease'::pg_catalog.regclass; [11:54] to current.sql [11:54] ah, not new [11:54] nonetheless? [11:55] I think that is the code pg_dump puts in there to turn of relational integrity constraints and triggers [11:56] Which needs to be done now, as our sample data has grown in complexity [11:57] sabdfl: This is probably a little saner: "tla delta --diffs $(tla logs | tail -2)" [12:00] sabdfl: You should be able to use archzoom if someone fixes the gpg signing rules for the account it runs as. [12:00] ok [12:02] spiv_: that did the trick nicely, thanks === carlos [~carlos@69.Red-80-33-181.pooles.rima-tde.net] has joined #launchpad [12:04] morning [12:05] hey carlos [12:05] sabdfl: hi [12:06] yo [12:39] sabdfl: could you look at my mail about the statistics and fuzzy flag from yesterday at launchpad mailing list? [12:39] carlos: ok [12:39] sabdfl: thanks === Kinnison attempts to make a short list of everything gina needs to do. I've been reading through the source to familiarise myself with it. [01:32] sabdfl: https://chinstrap.warthogs.hbd.com/~dsilvers/gina.txt === Kinnison thinks that is all we need for dogfooding; the last one probably isn't needed [01:33] Kinnison: only the first one is critical [01:33] single suite, sinlge arch would be fine [01:33] use hoary [01:33] it's getting uploads [01:33] single suite single arch still needs the overrides and removals stuff [01:33] otherwise our copy of hoary won't get cleaned up [01:34] right [01:34] can't just drop the publishing table each run? [01:34] I guess I could do it that way if you'd prefer [01:34] That'll get us up and running faster I guess [01:34] I'll do that === Kinnison fiddles a bit [01:35] how about now? [01:36] rock [01:36] Cool [01:36] Okay; that's what I'm aiming for with gina === Kinnison is going to go and find some lunch (I forfeited breakfast in favour of reading code) [01:37] Then I'll start [01:37] 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 :-) === Kinnison -> lunch [01:45] trying to use str.translate on a unicode string gives an error. [01:46] Can somebody point me at the right thing to use? That may save me some doc-searching time. === lulu [~lu@host217-37-231-28.in-addr.btopenworld.com] has joined #launchpad === ddaa finds a hack appropriate for the situation [01:57] ddaa: use unicode.translate instead? [01:57] Ha... not quite I was doing... [01:57] Instead I was simply encoding the input to utf8. [01:58] context: I'm writing a job name munging tool to work around the broken shell quoting in cscvs. [01:59] The error was: exceptions.TypeError: character mapping must return integer, None or unicode [02:02] 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] stub: thanks [02:07] 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] unicodeobject.encode('utf-8') -> str object [02:07] str.decode('utf-8') -> unicode object [02:07] approx [02:07] bad twisted! [02:08] Kinnison: ha, simpler than "import codecs; codecs.getencoder('utf8')(text)" [02:08] ddaa: aye === Kinnison uses thingstr = footable.barcolumn.encode('utf-8') all over the place in his db code [02:08] After all, I'm going utf8ize it, then... [02:11] Okay... that works. [02:12] I mean, I'm hitting another bug, but that part works... === cprov [~cprov@200.158.100.251] has joined #launchpad [02:40] sabdfl: Section and Component don't have owner columns -- are they officially shared among all the distributions then? [02:41] Kinnison: yes [02:41] sabdfl: Cool; any complaints if I propose making them unique then? [02:41] ah. very good thinking [02:42] hmm; someone appears to have beaten me to it [02:42] I really must get gina importing into the new db so I stop asking these things :-) === Kinnison ponders some more sleep in the meantime :-) [02:45] Kinnison: hi, can we get Librarian running on mawson ? [02:45] cprov: I started one yesterday I'm sure === Kinnison looks [02:45] lifeless: you are probably asleep, but I straced a hang at "launched local CVS server" [02:46] dsilvers@rosetta:~ $ ps ax | grep libra [02:46] 6976 ? S 0:00 /bin/sh ./run-librarian.sh [02:46] 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] lifeless: one of the threads hangs on select, the other hangs on futex. [02:46] ddaa: mail it to me ? [02:46] Aye. [02:46] Btw, I'm in process of trying to test taxi.py... [02:46] thank you [02:47] I was going to do that today, ended up bazzing all day [02:47] But roadblocks keep popping up... [02:48] I have a "munge job names" hack ready. I want to test it over the whole process before merging. [02:48] lifeless: the robertcollins.net mail is still okay? [02:48] Kinnison: I had already ran gina successfully on mawson, but it is unusefull w/o Librarian, I think [02:48] ddaa: yes [02:48] cprov: librarian is running [02:49] cprov: the uploadfactory is on port 9090 [02:49] cprov: if I star-merge will I get your gina changes to make her run on mawson? [02:50] Kinnison: fine, btw, I'm working on CURRENT srcpkgrelease replacement [02:50] Kinnison: just few minutes, I will request merge for PQM [02:51] cprov: cool; thanks [02:54] lifeless: debugging data sent [02:54] I'll stand by if you want additional in-vivo data. [02:54] ddaa: debug-bomb the native protocol please. [02:55] lifeless: you really should bump down the compression... [02:55] "debug-bomb"? "native protocol"? [02:55] modules/CVS/__init__.py [02:56] start with hasProtocol() and follow your nose [02:56] there is a cvs client implementation [02:56] okay, got the native part... [02:56] if its hung there, then its reading from an empty pipe. [02:56] you want me to spill printlines all over the place, right? [02:56] killing the cvs server should resume the process. [02:56] There is no cvs process. [02:57] "pgrep cvs" gives nothing. [02:57] self.logger().debug statements go to the log, and are useful. [02:57] no cvs process - then what is the select selecting on ? [02:57] you tell me... [02:57] what fd ? [02:58] select(6, [0 5] , [] , [] , NULL [02:58] in the strace, what was opened on that fd most recently ? === ddaa checks if strace has a --time-travel option [03:04] sorry boss, the strace folks do not yet support tracing system calls before the process is attached. [03:05] I suspect this feature is not on top of their todo... [03:13] lol [03:15] 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] or something equally crackful... [03:17] ddaa: no, the spawn succeeded [03:17] 2004/10/28 14:15 CEST [Broker,client] WARNING:root:launched [03:17] local CVS server [03:17] 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] 'launched' [03:17] that is logged stricly after the the pipes have been created. [03:17] sure, that does not mean cvs did not die immediately after. [03:17] sure. [03:18] it might be a lost signal [03:18] Yup. [03:18] That would be consistent with the insanity that led to arch._twisted. [03:18] so what you need to do is to run strace from before you start the job. [03:18] imho that not really working around a pyarch bug, just working are twisted's lack of tolerance. [03:19] ddaa: iynsho. === ddaa dicts [03:19] its actually a unix process model problem. [03:19] In Your Not So Humble Opinion [03:19] Merge to rocketfuel@canonical.com/launchpad--devel--0: missed clauseTables, people traversed by name, gina/nicole running on mawson (patch-708) [03:19] Well, I may be wrong. [03:20] That's speculation. [03:20] actually, it can't be a dropped signal [03:20] if the signal is recieved, the pipe is closed at the far end, read will generate SIGPIPE [03:20] teisted doesn't AFAIK install SIGPIPE handlers [03:21] ddaa: can you please try this: [03:21] whatever it does, the effect I observer are undistinguishable from that. [03:21] tla register-archive [03:21] http://bazaar.canonical.com/archives/thelove@canonical.com [03:21] ack [03:21] New bug 2150 for Launchpad/Rosetta: Fix the way we store fuzzy strings in the database schema [03:21] https://bugzilla.warthogs.hbd.com/bugzilla/show_bug.cgi?id=2150 [03:22] lifeless: whose key is used there? [03:22] pqm's [03:22] good point. [03:24] Kinnison: new gina merged on RF, please try . [03:24] lifeless: you want be to build and install baz, right? [03:24] no [03:24] just to check that that archive location is abrowse -s 'able for you [03:25] http://bazaar.canonical.com/packages/debs/ [03:25] is up and going now [03:25] cause thom is a legend [03:25] nay, a god even. [03:25] cprov: merged already? [03:25] Looks like abrowse -s is happy. [03:26] Kinnison: yep === ddaa looks on the Bazaar page for an apt-sources line [03:27] cprov: dilys hasn't mentioned it; hence my confustion [03:27] Kinnison: let's plan something for today, we have to run gina and nicole on mawson, definitly, as milestone :) [03:28] cprov: I concur [03:28] Kinnison: dilys doesn't like me :) === Kinnison is doing some gina changes now that sabdfl and I agreed upon === Kinnison workraves; brb [03:29] lifeless: any idea what the apt-sources line should look like? [03:29] lifeless: how are we looking for the automatic sync-testing on galapagos? [03:30] 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] ddaa: its not a repository [03:32] but I believe you can just do deb path ./ [03:32] No good. I want crack-of-the-day, not crack-of-the-last-time-I-visited-the-page. [03:33] "path" being what? [03:33] 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] and then I'll start on the unattended-scheduling, which I'm estimating @ a couple of days [03:33] ok [03:34] vendor, default branches, done? you're running out of space between 95% and 100% :-) [03:34] no progress at all since last phone call. [03:34] cprov: sabdfl and I agreed that initially gina will just totally repopulate the publishing tables each run === kiko [~kiko@200-206-134-238.async.com.br] has joined #launchpad [03:34] been baz bootstrapping [03:35] 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] cprov: for now; sabdfl and I agreed that we just wanted daily imports working :-) [03:35] cprov: see https://chinstrap.warthogs.hbd.com/~dsilvers/gina.txt for the plan :-) [03:35] Kinnison: fine [03:36] Anybody aware of a debug-enabled variant of popen2.Popen3? [03:37] cprov: what did you change in grabber.py ? [03:38] Kinnison: nothing .. I just change back some particular conf [03:38] 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] Kinnison: which pass to use on https://chinstrap ? [03:39] in the sense that you can see old releases of a source package in the system, but not superceded info [03:39] for the moment [03:39] sabdfl: yeah; that'd be the side-effect if we blat the publishing records each time [03:39] no problem for this week [03:39] cprov: erm, wartyhoa... I think [03:40] Kinnison: sabdfl: I'm just affaid to have two or more CURRENT srcpkgrelease [03:40] ddaa: anyway, as chinstrap isn't ppc, you need to roll your own anyway :) [03:40] cprov: define 'current' if you mean in the publishing tables then that won't happen [03:40] cprov: not until we do things properly :-) [03:40] lifeless: what does ppc has to do with that??? [03:40] oh right, you have an intel desktop, my bad. [03:42] 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] cprov: yeah; but we're going to empty the publishing tables before the gina run [03:42] current gina gives me: [03:42] libpq.OperationalError: ERROR: insert or update on table "sourcepackagerelease" violates foreign key constraint "$4" [03:42] DETAIL: Key (component)=(3) is not present in table "label". [03:42] against the current schema [03:43] somehow the sourcepackagerelease component column has been pointed at the label table === Kinnison boggles [03:45] stub: ping? [03:45] Kinnison: are you running over a DB created by lp-sampledata ? [03:45] Kinnison: it is looking for 'restricted' component [03:45] cprov: No; just a plain 'make' in the schema dir for now [03:46] Kinnison: That dates back to the dawn of the database (database/schema/archives/launchpad-1-00-0.sql) === Kinnison wonders how this ever worked [03:46] cprov: actually; universe :-) [03:46] Kinnison: that is it ... [03:47] stub: can you please commit a fix to make that point at component(id) instead of label(id) ? [03:47] Kinnison: do you have the component entry ? wierd [03:47] 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] stub: yes please === Kinnison will fix it in his testdb for now; but if you could commit a real fix I'd appreciate it [03:49] yup [03:49] there must have just been entries in the label table before now [03:49] what's the extra bit needed to enable the output of self.logger().debug? [03:49] lifeless: ^ [03:51] yay: libpq.OperationalError: ERROR: current transaction is aborted, commands ignored until end of transaction block [03:51] # TODO convenience for interactive debugging move somewhere importable. [03:51] # import logging [03:51] # logging.basicConfig() [03:51] # logging.getLogger().setLevel(logging.CRITICAL) [03:51] # logger=logging.getLogger('a') [03:51] # logger.setLevel(logging.DEBUG) [03:51] # logger.debug('fooooo') [03:51] Wereizdat? [03:51] thats in test_CMDS.py [03:51] when I needed to do something similar [03:52] in buildbot, if you are running the slave as normal, you can just edit buildbot_slavecommand.py [03:52] and tweak the level there. === ddaa wonders if the buildbot types ever heard of "configuration"... [03:53] ddaa: there is a todo to pass this down as part of the job. [03:53] its not intended to be per-slave. [03:56] Mh... the self.debug=0 bit i guess... [03:57] please, just change your slave level. [03:57] ... === debonzi [~debonzi@200.158.100.251] has joined #launchpad [03:58] what ... is ... a ... slave ... level ... === BradB|zzz is now known as BradB [03:58] in buildbot_slavecommand.py [03:58] look for WARNING [03:58] morning [03:59] ha... was looking at the wrong file... [03:59] Morning [03:59] was looking at buildbot/slavecommand.py... [03:59] heh. we want importd/buildbot_slavecommand.py :) === BradB puts coffee on [04:04] okay, I'll keep that around when building. That will probably prove useful. [04:04] Of course, this time the server is not... [04:04] (me stops and starts the import from scratch, just for kicks) [04:07] Okay; zhongshan has something broken with its cursors or something. disabling them helps a lit [04:07] cprov: I have a gina running now against the new schema; with my build record fixes [04:07] cprov: I'll let you know how it goes [04:08] Kinnison: you rock !! [04:08] cprov: currently running on zhongshan because I have good debug-ability there [04:08] cprov: I'll run it on mawson once I'm satisfied :-) [04:11] Kinnison: ehe zhongshan is gives a pretty better environment the mawson :) [04:12] Kinnison: starting with this crap colored prompt [04:13] lol [04:13] man I am SLEEPY today [04:13] kiko: I know what you mean === Kinnison ponders the elixir of life [04:21]