[01:04] Huh. [01:04] test_initZopelessTwice fails with a recursion limit error. [01:04] Because it adds a warning hook. [01:04] Which uses failUnlessEqual. [01:04] Which is deprecated. [01:04] Which raises a deprecation warning... [01:05] whee [01:15] win [01:15] wgrant: so init zope less twice sends a warning ? [01:15] wgrant: if so, as we don't init zopeless twice in the real world, perhaps make it raise an exception instead? [01:21] Are you sure we don't? [01:21] Trivial fix will do for now. [01:21] Or not. [01:21] 2.6 testcase doesn't have assertIs. [01:21] testtools time, I guess. [01:22] wgrant: I sure hope we don't. [01:22] Why? [01:22] because I want to nuke it entirely [01:22] Sure. [01:22] as unhygenic [01:23] After all, if it's been raising a warning when called twice then hopefully anyone doing that would have noticed the warning. [01:23] spiv: We mostly just suppress warnings :) [01:23] Then throw an exception [01:26] dict ordering issue in launchpadlib, XMLRPCTestTransport borked, timeout.txt hanging in really bad ways. Apart from that all fixed. [01:26] wgrant: It continues to pass with 2.6, so the fixes are landable? [01:27] Yes. [01:27] They're all small test issues, apart from one real bug. [01:27] timeout.txt might be real too, I guess. [01:27] But need to get pygdb onto it at some point. [01:59] I'm getting sucky packetloss entering Los Angeles. This should affect most of Asia :-( [02:00] level3 LA [02:18] StevenK: Working fine for me. [02:18] Er, stub. [02:18] Maybe they've fixed it. [02:18] Optus' international pipe has been fairly broken for the last 24 hours, though. [02:19] Seems better now. Can't be sure it isn't my ISP messing up though - I think it is the first server on the US site, so might be entering the US/Asia cable that is screwed. [02:19] nope... still messed. just not as bad. [02:36] lifeless: i'm seeing some udd failures due to bug 602647 [02:36] hm [02:36] actually, no i'm not [02:38] It's private? [02:45] is there another bug for internal xmlrpc flaking out and returning a 503? [02:47] That sounds like a timeout. [02:47] https://bugs.launchpad.net/launchpad/+bug/294726 is pretty close [02:47] <_mup_> Bug #294726: "ProtocolError for xmlrpc.lp.internal:8097/branchfilesystem" when pushing a branch < https://launchpad.net/bugs/294726 > [02:47] probably [02:49] poolie: Which bug number did you mean? [02:49] bug 602467 [02:49] <_mup_> Bug #602467: retry 503 errors on the LP directory service. < https://launchpad.net/bugs/602467 > [02:49] Ah [02:51] Hi, when I hit launchpad.dev, its not hitting my local instance. [02:51] Suggestions on where to look? [02:51] nigelb: i guess you need to start apache [02:51] or, connect direct to zope on port 8086 [02:52] apache acts as a front end proxy [02:52] poolie: There's a make run running [02:52] you need to run 'sudo service apache start' separately [02:52] assuming it was not started at boot time [02:52] (in your chroot, or vm or whatever, if you're using one) [02:52] I just use my regular apache [02:52] Nope [02:52] no go [02:53] what happens? [02:53] apache was already started [02:53] but I still can't hit launchpad.dev from firefox [02:53] what happens when you try? [02:54] you get the apache 'it works' page? [02:54] I get "Firefox can't establish a connection to the server at launchpad.dev." [02:54] launchpad.dev is in /etc/hosts? [02:54] are you using a chroot or something? [02:55] The /etc/hosts is what I checked first, its there. [02:55] poolie: Nope, just in my regular install [02:55] try telnet launchpad.dev 443 [02:55] oh grrar [02:56] https://launchpad.dev works [02:57] hooray [02:57] congrats [02:57] that further proves that its been a while since I've done this. [02:58] * nigelb should contribute more. [03:42] poolie: https://code.launchpad.net/~spiv/launchpad/bmp-inline-diffs/+merge/66634 is now ready for landing I believe [03:43] poolie: do you still want to send it in for me? :) [03:46] Yippie, build fixed! [03:46] Project devel build #901: FIXED in 5 hr 33 min: https://lpci.wedontsleep.org/job/devel/901/ [04:46] Oh yay, our JS is broken in IE again. [04:47] Why are you using IE? [04:47] Was testing the expanders. [04:48] Ah. [05:15] wgrant: Is it lint issues again? [05:18] It's not the usual comma at the end of a list. [05:18] It may be a missing closing brace, I think. [05:19] Just one? [05:22] It occurs in the middle of json-parse.js, it seems. [05:22] But that's YUI... [05:23] and bug searches are back into timeout territory [05:33] cute - http://elaforge.blogspot.com/2011/07/what-haskell-doesnt-have.html [05:33] I really must do something nontrivial in haskell one of these days [05:41] Indeed. [05:41] It's a really nice language. [06:18] I need to learn a new language one day. I think I've forgotten everything except Python and PL/SQL [06:38] perl [06:39] 'new language' [06:41] I still think spm wins ;) [06:41] hahahha [06:41] lifeless: what bit about the function in https://code.launchpad.net/~nigelbabu/launchpad/spec-sub-sort/+merge/63315 do you want me to abstract? [06:41] I got confused yesterday when I was trying. [06:42] nigelb: I think the point was that the sort with a sort key function is something we could spell once abstractly [06:43] I tried abstracting the sorted bit in there [06:44] but then I realized that I also do sort() there. [06:44] which is part of another function. [06:46] Does that make sense? [06:46] nope [06:46] pastebin ? [06:50] This is something jml wrote for me yesterday. http://paste.ubuntu.com/648007/ [06:50] Is this the level of abstraction you were looking for? [07:13] nigelb: I think so, yes. [07:15] oh, I can't link you to lines in a merge proposal's diff :/ [07:15] Well, line 19 of the diff in my MP is what's confusing me. [07:15] I can't use that function there. [07:20] spiv, hi, i can send that for you [07:20] poolie: thanks! [07:20] one idea occurred to me, reading your latest update [07:20] (thanks for completing it) [07:21] and that was that rather than href="#" perhaps it should send people to the loggerhead view of the diff [07:21] in case they ctrl-click it or have a non-js browser [07:21] (i don't know what the policy is for supporting that) [07:21] i don't want to stall this though [07:21] If they have a non-js browser, the link won't be visible currently. [07:21] Well, if they have a non-js but with-css browser. [07:25] oh ok [07:25] anyhow, it was just an idea [07:25] nigelb: property_cache.subscriptions = function_call() [07:25] spiv, so, i'll just send it? [07:27] It's a good idea, but it's a bit fiddly to implement AIUI. At the least you'd need to use a less convenient API than expander.createByCSS I think. Perhaps you'd enjoy making that patch? ;) [07:27] poolie: please do! [07:27] :P [07:28] huwshimi: is there actually a policy on non-js support? [07:28] lifeless: ah, thanks. Brain seems to be turned off today :) [07:29] poolie: This is the only thing I can think of off the top of my head: https://dev.launchpad.net/GradedBrowserSupport [07:29] I'm a bit sick of staring at that code today, I spent longer than would be ideal discovering that one of the expander APIs grew a new positional parameter since I'd last merged, which of course resulted in a mysterious “nothing happens when I click” bug :/ === jtv changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv | Critical bugs: 238 - 0:[######=_]:256 [07:30] poolie: oh hmm, I guess I misunderstood, and making that link go straight to loggerhead might not be so hard [07:30] poolie: but I think it's weird UI for the browser to indicate that a link will take me somewhere and then for clicking it to do something else. [07:31] i loved named/optional parameters when i first used python but now the bugs they lead to are one of my least favourite bits [07:31] in the sense that the status bar will show the lh url [07:31] named-only params would be nicer. [07:31] for nerds who look at the status bar [07:31] Like me :) [07:31] it's been a long branch, i don't want to make you do any more on it [07:31] it was just a thought when i saw your update [07:32] I've definitely been repeated annoyed by that sort of behaviour in the past, so I'd be pretty hesistant to implement it myself :) [07:32] in general links that point to # are i think a chance to consider whether there is somewhere better [07:32] I agree that's the experience I'd want non-JS browsers to get in the ideal world. [07:32] I'm not sure how best to arrange that without misleading the JS browsers. [07:33] (It does lead to the intruguing idea that the target of the href could be used as the input to the 'generate the link for raw diff to fetch' function. [07:33] ) [07:33] i don't think browsers really handle the case of indicating what a js link will do [07:33] you typically either get '#' or some unreadable function lambda [07:36] spiv, ec2 wants to know if there's a bug for this branch [07:36] Yeah. I might be wrong about how bad it would be, but I *have* encountered irritating behaviour with expander-like things and misleading ctrl-click behavour in LP before. [07:36] Not that I know of, probably a good time for me to take a quick look... [07:39] poolie: a few very vaguely related ones maybe, but no appropriate one [07:42] poolie: but it did lead me to notice a low-importance bug of yours that's a dupe of an older critical one! [07:42] heh [07:42] which? [07:42] bug 762355 [07:42] <_mup_> Bug #762355: would prefer to see mp with no diff when librarian fails, rather than no mp at all < https://launchpad.net/bugs/762355 > [07:43] ok bug 813349 for the sake of qa'ing it [07:43] <_mup_> Bug #813349: hard to get from mp to per-revision diffs < https://launchpad.net/bugs/813349 > [07:44] poolie: thanks! [07:47] ok, instance is booting, we should know tomorrow [07:49] good morning === almaisan-away is now known as al-maisan [08:16] Good morning === jkakar_ is now known as jkakar [08:42] jtv: About your suggestion to clean my branch (removing the use of filtered_expanded): the code you propose was exactly what I wrote first but if candidates is [] then Or(*candidates) breaks the generated SQL. [08:42] rvba: then return if candidates is empty. :) [08:42] Doesn't cost much to go through one more empty list comprehension. [08:44] jtv: but make_package_condition crashes if it's called with das=None. [08:44] But you won't be calling it. [08:44] ah ... right. [08:44] The extra "if" in the list comprehension prevents it from happening. [08:44] True. [08:50] cjwatson: you still have an approved but unlanded merge proposal for Launchpad open from last year. What should happen with it? https://code.launchpad.net/~cjwatson/launchpad/dpkg-xz-support-619152/+merge/32868 [08:51] and jelmer, what's supposed to happen to https://code.launchpad.net/~jelmer/launchpad/publisher-use-debian-2/+merge/45011 ? [08:52] adeuring: you too have an ancient approved MP on the backlog: https://code.launchpad.net/~adeuring/launchpad/js-translation/+merge/55309 [08:52] lifeless: approved-but-unlanded-MP reminder: https://code.launchpad.net/~lifeless/launchpad/bug-759467/+merge/58262 [08:55] jtv: thanks for the ping [08:55] wgrant: hi [08:56] jtv: IIRC cjwatson's branch was waiting on the installation of a newer dpkg package, IMBW [08:56] jelmer: thanks — it's been a while so probably a good time to check up on that [09:01] yes, it's due to land in lucid-updates in a couple of days [09:01] when it does, I'll propose meta-lp-deps changes, and then we can try landing dpkg-xz-support again [09:01] don't worry, I'm totally keeping track of this [09:02] (though I wasn't for a long time, I know) [09:02] it's actually newer apt and python-apt - didn't I comment on the MP or the bug about it? [09:03] yes, I did comment on the MP a week ago. [09:03] http://people.canonical.com/~ubuntu-archive/pending-sru.html - waiting for lucid/apt and lucid/python-apt there to hit 7 days before the next move in the game [09:05] jtv: landing the branch now. Thanks for the review! [09:05] jtv: it bounced off of ec2; I haven't dug into ityet [09:05] rvba: np === jtv is now known as jtv-afk [09:26] thanks to whoever landed https://code.launchpad.net/~cjwatson/launchpad/germinate-ubuntustudio for me, without me having even got round to asking :) [09:29] <- [09:32] cjwatson: hooray for patch piloting spirit [09:33] (presumably rum) [10:06] wgrant: re namespace patches [10:06] [Python-Dev] Draft PEP: "Simplified Package Layout and Partitioning" [10:07] *packages* [10:19] lifeless: That almost looks like not a complete mess. === al-maisan is now known as almaisan-away [10:41] wgrant: bzr log -r12957.1.6 [10:41] wgrant: wrong ;-P [10:53] is rabbitmq used for any core stuff yet? [10:54] it's being set up for the codeimports, which (AFAIK) shouldn't need it [10:58] jelmer: It's part of LaunchpadLayer, but only a couple of tests use it so far, and they're only to check that the layer setup is working. [11:00] jelmer: If you still can't get it running, I guess you could hack LaunchpadLayer to not depend on RabbitMQLayer. [11:01] wgrant: that's what I've just done :) [11:01] I'll have a closer look at it later, but for the moment I just want to get some stuff done. [11:20] jtv1: Hi! I have a short and easy branch for you. ;-) [11:20] https://code.launchpad.net/~henninge/launchpad/bug-792092-build-now/+merge/68521 === henninge is now known as henninge-lunch [11:35] henninge-lunch: reviewing. [11:36] danilos: Hi. === jtv1 is now known as jtv [11:36] adeuring: Also hi. [11:45] henninge-lunch: done [11:45] jtv: Are you going to be around to chase up the deployment this evening? [11:46] No. It's planned, it's approved, it should be announced. [11:46] mrevell: did that work out by the way? [11:46] It is announced. [11:46] I think he said so yesterday, but not sure. [11:46] But it's still useful to have someone around who knows what's going on. [11:46] You may wish to recruit a conveniently located maintenance person for this purpose. [11:46] jtv, yeah, it's announce [11:46] d [11:47] thanks [11:50] wgrant, hi === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: jtv, danilo | Critical bugs: 238 - 0:[######=_]:256 [11:51] danilos: We have another expander regression :( [11:51] On prod this time. [11:51] wgrant, which one is it? [11:51] (see #launchpad a few minutes back) [11:51] When there is a conjoined bugtask, the expander hook for the conjoined slave crashes. [11:51] Because there is no expander. [11:52] This seems to break all remaining inline JS on the page. [11:53] wgrant, indeed, I'm looking into it [11:54] danilos: Thanks. [11:54] danilos: Hopefully the fix is smallish and can skip ec2 and we can deploy it in not too many hours.' [11:55] wgrant, yeah === almaisan-away is now known as al-maisan [12:19] wgrant, considering jtv is not around and I am the other OCR reviewer, can you perhaps approve https://code.launchpad.net/~danilo/launchpad/fix-bugtask-expander/+merge/68536? [12:20] wgrant, (or disprove, if you are so inclined :) [12:20] danilos: Approved. [12:21] Thanks! [12:21] wgrant, thank you! [12:21] wgrant, I'd say "bzr lp-land" should be fairly safe with this, what do you think? [12:21] Yes, definitely. [12:23] cjwatson: Your ubuntustudio germinate change should be deployed to cocoplum in the 1600UTC downtime window today. [12:25] wgrant, ok, I'll try to arrange a deployment towards the end of my day (when lpbuildbot run completes), if not, I'll ask some of my fellow yellow Americans [12:30] danilos: I was about to ask if you could do that. Thanks! [12:30] danilos: We are QAed up to current stable tip, so it's just your rev left. [12:30] wgrant, cool, thanks [12:30] So it will be a nice easy thing to deploy in ~5 hours. [12:32] Thanks for the quick fix. [12:32] * wgrant sleeps. [12:44] wgrant: cool, that's quicker than I expected, thanks === henninge-lunch is now known as henninge === danilos changed the topic of #launchpad-dev to: https://dev.launchpad.net/ | On call reviewer: danilo | Critical bugs: 238 - 0:[######=_]:256 [12:52] jml, I had a pre-imp for (private) https://bugs.launchpad.net/launchpad/+bug/812335 with flacoste yesterday and was hoping I would not need to bother you, but I just ran into some concerns. Would you have tie for a pre-imp? [12:52] or time [12:53] hello mrevell [12:53] hey bac, otp [12:53] mrevell: np, ping when you're free [12:55] gary_poster: sure [12:55] gary_poster: I need to eat first though. [12:55] * jml has been putting that off on account of unusually high productivity [12:55] thanks jml. ok, I have a dentist appt I need to leave for in 15 minutes, so maybe a couple of hours later then [12:56] gary_poster: perfect. [12:56] thanks again [12:56] jml, if you put it off for long enough, productivity will go to zero but so will your (non?) living costs [13:02] Morning, all. [13:02] hiya [13:08] Anybody noticed this missalignment before? Is there a bug for it? I don't know what to search for ... [13:08] http://people.canonical.com/~henninge/screenshots/miss-aligned-bugs.png [13:09] henninge, looks like my expander replacements might be the culprit [13:09] henninge, what browser is that? [13:09] danilos: chromium [13:10] henninge, fwiw, the bug priority icons were not even shown in webkit-based browsers before, so maybe the issue was there but spans were zero height [13:10] they weren't? oh [13:11] henninge, yeah,

s now probably need more indentation for two sprites (expander icon and the bug icon), at least I think that's the problem; please file a "regression ui" bug and I'll look into it tomorrowish [13:11] henninge, or, if you feel like it, fix it :) [13:12] danilos: I have another one I want to do, I was gonna talk to you about that, too ... ;) [13:13] henninge, shoot before I head out to lunch :) [13:14] danilos: I want to remove TranslationBranchApprover and replace it with TranslationBuildApprover. [13:14] henninge, hum, what's a TranslationBuildApprover? :) and why is it different at all? [13:15] danilos: ;-) [13:15] danilos: TranslationBuildApprover is run after templates were build from a branch. [13:15] danilos: it is much simpler and only determines the template name from the file name. [13:16] danilos: it does not care to check which templates are already in rosetta and which are in the branch. [13:16] henninge, makes sense [13:16] danilos: TBranchA stops if a template is missing in the branch. [13:17] we need to do a lot of manual approval because of that. [13:17] danilos: That "comparing" functionality doesn't really help. [13:18] henninge, right, but what happens when someone renames a template? [13:18] henninge, how do they fix the mess? [13:18] danilos: it *could* be helpful if it could explain that to the uploader and the uploader had a chance to do something about it. [13:18] henninge, well, I've got a window of two weeks to finish the switch of approval to maintainers [13:18] henninge, so, they'll be able to control their templates much more [13:18] danilos: the TBranchA gets stuck and does not approve anything, the TBuildA just creates a new template === gary_poster is now known as gary-dentist [13:19] henninge, right, but how would one ever "join" two templates together when one renames the template in the branch then? [13:19] good luck gary-dentist [13:20] henninge, imagine there was a template with lots of translations (history and stuff), and maintainer renames it in a branch: it automatically gets imported as the new template with no history preserved [13:20] danilos: not possible [13:20] henninge, that would suck very much, wouldn't it? [13:20] danilos: correct, we don't have a good renaming story [13:21] henninge, I'd rather just let people approve stuff on their own than mess it up completely (I've seen people rename templates all the time, at least until they get a good setup) [13:21] henninge, fwiw, I think your approver makes more sense for ubuntu uploads [13:22] henninge, "your" == TBuildA [13:22] danilos: Letting maintainers approve themselves is much better of course. [13:22] danilos: I wrote both ... [13:22] ;-) [13:22] henninge, heh, right :) [13:23] danilos: why for Ubuntu uploads? [13:23] danilos: so I guess we need to fix bug 728876 instead [13:23] <_mup_> Bug #728876: Know when translations branch/build auto-approvers give up < https://launchpad.net/bugs/728876 > [13:23] henninge, because they are for trusted packages and are basically the same thing as what we build for TBuildA to approve (i.e. they are result of intltool-update -p for GNOME packages, and whatever else others use) [13:24] right [13:25] henninge, perhaps, but let's first let maintainers manage the import queue themselves [13:25] danilos: that would add valuable information to enable them to manage them correctly. [13:25] henninge, indeed, I agree [13:25] henninge, so, I will be very happy if it gets fixed :) [13:26] danilos: It would be best if it could give a specific reason ... [13:27] henninge, indeed, you can reuse error_output for that [13:31] henninge, ping for standup [13:33] deryck: oh, sorry [13:37] Has anyone ever seen this failure I'm getting in EC2? ScriptActivitySet.recordSuccess violates scriptactivity_pkey (even though that's just an id that the database assigns normally). Sign that the database needs to be marked dirty? [13:38] sinzui: available to mumble this morning? [13:38] yes [13:40] jtv: not sure how that would happen even if there are test isolation issues [13:40] I can't even reproduce it locally. [13:40] jtv: You might need to dump the contents of the table before that point, which is sucky if it is only happening on ec2 [13:41] But my branch triggers it consistently in EC2, and it's probably because of something I did. [13:42] I turned a function that gets invoked by scripts into a LaunchpadCronScript itself. So now we have LaunchpadCronScripts instantiating a LaunchpadCronScript and invoking it. But I'd like to understand why the id clash. [13:43] The test in question forks off a proper script instance, so maybe that ought to mark the db as dirty. [13:43] It does, actually. [13:43] Oh, but in what looks like the wrong place. [13:44] jtv: thanks for the review. i've updated it showing i took your suggestion. [13:44] It does that in the assertion after the script has completed... so if one of the invocations failed for a different reason, that would sabotage the "dirty" bookkeeping. [13:45] bac: thanks! I didn't expect you to have much time for that kind of polish, so nice surprise. [13:47] stub: is there any circumstance under which we'd reset sequences but not the db? [13:48] Hmm... I think there might be, and your initial idea could be correct. [13:48] I'm seeing it on LFC as well. [13:48] If the db is not dirty, we assume all the data changes roll back. But the sequences don't reset, so we reset em [13:49] (although if our tests were good, we wouldn't have to reset the sequences because we would not be depending on tests getting consistent ids) [13:49] Then I'll just start by marking the database when the script runs, instead of after it's completed. [13:50] Yes, I wonder how much would break if we stopped resetting them. [14:01] Oh blast, it's one of the fun ones. [14:01] I can reproduce the problem by running a whole lot more tests at once. [14:03] AAAAAAAAAAAAAhhhhh! The preceding test invokes a script as part of its test data setup! [14:03] And neglects to mark the database dirty, of course. [14:03] At least I see a way to make that test a lot faster… [14:07] jtv: we should automate that dirtying somehow [14:08] Yes, that'd be nice as well. If it's not too expensive. [14:10] I wonder if there's a way to ask postgres if the db has had a write since a given time [14:10] or, when the last write was [14:17] The problem is, I suspect, that you need to find out what was the last committed write. [14:17] (Assuming we don't need to reset sequences, which we currently do) [14:17] danilos: bug 813540 [14:17] <_mup_> Bug #813540: Bug icons in dupefinder listing get pushed to next line < https://launchpad.net/bugs/813540 > [14:17] danilos: I'll probably take it, looks shallow. [14:18] jml: technically there could even be a write in progress that hasn't committed yet, though. [14:18] jtv: by the time the script has ended? [14:19] I wonder if we know for certain that all transactions have ended at the end of the test. [14:19] Chances are pretty good though. [14:19] jtv: if the test is buggy and leaves processes or threads running, then I guess you won't know [14:20] jtv: but tests shouldn't be buggy, and we've already got reasonably good catches for those things [14:20] Exactly, that's the hard case. [14:20] Although with daemons this may all get harder. [14:20] What if the Librarian is about to commit on the test's behalf, for instance? [14:20] yeah, that'd be a problem [14:20] because those could cross boundaries. [14:20] hmm [14:20] Well, I don't know if the Librarian ever commits to the db of course. [14:20] but that's currently a problem anyway [14:21] it just depends which side you want to err on [14:22] anyway, it might be worth playing a bit with the idea, since it would ultimately be more reliable than remembering to mark as dirty [14:23] Very true. [14:24] And I'd like to have a ratchet on the number of test failures we get when we don't reset sequences. [14:25] That's probably only worth it when we actually start working on it though: we could see the ratchet close. [14:26] (It could be a driver for getting rid of some more old-style tests) [14:40] Anyone know where this comes from? [14:40] : Multiple registrations for Expression type "cache". [14:41] Multiple zcml-for-scripts initialization maybe? [14:41] ahh yes, must be [14:43] Did I seriously just knock 26 seconds off test time by fixing that? [14:45] henninge, thanks for taking care of it (was lunching) === jtv is now known as jtv-afk === matsubara is now known as matsubara-lunch [15:16] danilos: https://code.launchpad.net/~henninge/launchpad/bug-813540-dupefinder/+merge/68557 === gary-dentist is now known as gary_poster [15:20] thanks for the good luck wishes henninge :-) [15:24] henninge, looking [15:31] jml, are you available for a call now? [15:31] henninge, r=me, thanks [15:31] danilos: thank *you* ;-) [15:33] henninge, btw, I agree that layout should not be table-based, and would probably need to be reformatted completely to be sane [15:33] yup [15:36] gary_poster: hi [15:36] gary_poster: a short one, yes. [15:36] hey, ok jml thanks. I'm ready with skype (garyposter) or mumble [15:37]