[00:03] <mbarnett> mwhudson:
[00:03] <mbarnett> lp://staging/~mwhudson/linux/trunk  	Started: 48 minutes ago  	Last heartbeat: 14 seconds ago
[00:03] <mbarnett> 2010-04-15 22:54:11 INFO    49969129 bytes transferred | Fetching revisions:Inserting stream
[00:03] <mbarnett> 2010-04-15 22:55:11 INFO    43484334 bytes transferred | Fetching revisions:Inserting stream
[00:03] <mbarnett> 2010-04-15 22:56:13 INFO    35991244 bytes transferred | Fetching revisions:Inserting stream
[00:03] <mbarnett> 2010-04-15 22:57:14 INFO    31731071 bytes transferred | Fetching revisions:Inserting stream
[00:03] <mwhudson> mbarnett: i meant like "log in and run bzr st", sorry
[00:04] <mbarnett> mwhudson: hah, ok
[00:05] <mbarnett> mwhudson:
[00:05] <mbarnett> importd@strawberry:/srv/importd.staging.launchpad.net/staging/launchpad$ bzr st
[00:05] <mbarnett> unknown:
[00:05] <mbarnett>   lib/canonical/launchpad/apidoc/wadl-staging-1.0.xml
[00:05] <mbarnett>   lib/canonical/launchpad/apidoc/wadl-staging-beta.xml
[00:05] <mbarnett>   lib/canonical/launchpad/apidoc/wadl-staging-devel.xml
[00:05] <mwhudson> mbarnett: oh ok
[00:05] <mbarnett> revno 9233, if that is at all interesting
[00:06] <mwhudson> mbarnett: can you run bzr merge  http://bazaar.launchpad.net/~mwhudson/launchpad/bzr-git-improvements ?
[00:06] <mwhudson> if it has conflicts, please revert it
[00:08] <mbarnett> mwhudson: Warning: criss-cross merge encountered.
[00:08] <mwhudson> mbarnett: hmm
[00:08] <mbarnett> still going though
[00:08] <mbarnett> ah, 3 conflicts
[00:09] <mbarnett> i shall revert
[00:09] <mwhudson> thanks
[00:09] <mbarnett> welcoem
[00:09] <mwhudson> i guess i'll just wait until all the changes make their way through to db-stable
[00:26] <mwhudson> 10721 Launchpad Patch Queue Manager	2010-04-15 [merge]
[00:26] <mwhudson>       [testfix][rs=me][ui=None] Fix some tests broken in the branch that
[00:26] <mwhudson>       	changes the default PPA quota
[00:26] <mwhudson> but not all of them!
[00:26] <mwhudson> guys!
[00:44] <wgrant> mwhudson: Ew. What's left?
[00:47] <mwhudson> wgrant:  lib/lp/soyuz/browser/tests/archive-views.txt
[00:47] <mwhudson> i have a branch in pqm fixing it
[00:47] <wgrant> Ah.
[00:58]  * mwhudson lunches early
[01:54] <thumper> lifeless: can you please tag any merge queue bugs with merge-queues?
[02:03] <lifeless> thumper: sure
[02:04] <thumper> ta
[02:14] <lifeless> mwhudson: you said my 'cannot set status to 'code-failed-to-merge' bug was trivial'
[02:14] <lifeless> mwhudson: care to point me at it ?
[02:16] <mwhudson> lifeless: i think that was thumper
[02:16] <thumper> ?
[02:16] <thumper> BranchMergeProposal.set_status
[02:16] <lifeless> mwhudson: well, the plural 'you'
[02:16] <lifeless> thumper: yeah
[02:16] <thumper> or setStatus
[02:17] <lifeless> bug 561160
[02:17] <mup> Bug #561160: API: 'Code failed to merge' setting doesn't work <code-review> <merge-queues> <trivial> <Launchpad Bazaar Integration:Triaged> <https://launchpad.net/bugs/561160>
[02:18] <lifeless> I pinged mwhudson because thumper was going out, I thought ;P
[02:19] <lifeless> I'd just like a pointer at what to hit on, given its marked trvial
[02:20] <thumper> trivial for me
[02:20] <thumper> perhaps not trivial for you :)
[02:32] <lifeless> thumper: so, gimme a couple pointers, and we'll see
[02:33] <thumper> lifeless: setStatus needs a conditional to set mergeFailed
[02:37] <lifeless> where do the tests live ?
[02:39] <thumper> lp/code/model/tests
[02:39] <thumper> test_branchmergeproposal.py
[02:45] <lifeless> thumper: Looks to me like setStatus has a bug, if you do setStatus(Rejected) when it was Queued, it won't dequeue
[02:46] <thumper> lifeless: it may well do, we haven't extensively tested queues
[02:52] <mwhudson> spm: hey, could you trigger an update of tellurium and the staging code import slaves pls?
[02:52] <spm> mwhudson: sure, gimme a bit...
[03:00] <lifeless> spm: so, we haz keyfile ? :)
[03:00] <lifeless> spm: I'm keep to get to the point that we find new rt tickets to file
[03:01] <lifeless> spm: at which point stopping won't block things
[03:18] <mwhudson> spm: update in progress? if you don't have time feel free to tell me to go away :-)
[03:19] <spm> not yet....
[03:20] <lifeless> thumper: you said the tests were in lp/code/tests/test_branchmergeproposal
[03:20] <lifeless> thumper: that seems very small?
[03:20] <mwhudson> lifeless: maybe it's lp/code/model/tests/test_branchmergeproposal.py
[03:21] <lifeless> mwhudson: aha!
[03:21] <spm> mwhudson: tellurium == codehost only?
[03:22] <spm> mwhudson: and to what revno were you expecting? is currtently 9250
[03:23] <mwhudson> spm: oh, 9250 is probably enough
[03:23] <mwhudson> spm: what is strawberry at?
[03:23] <spm> cool - that's tellurium btw; haven't checked the slaves yet
[03:23] <spm> snap...
[03:24] <spm> 9233. OLD as the hills... or me.
[03:25] <mwhudson> spm: can you bully 9250 or newer on there?
[03:25] <spm> mwhudson: tho if I update that - is that going to break if the DB isn't in sync?
[03:25] <mwhudson> spm: it doesn't talk to the database any more
[03:25] <spm> okis
[03:25] <thumper> spm: do you have notes on why edge is so far out of date?
[03:26] <spm> thumper: there's a bug somewhere.....
[03:26] <thumper> spm: heh
[03:27] <spm> ha. No. I mean a real one. not generally/amusing. hahaha :-D
[03:27] <wgrant> There's the CSS bug, the lp.testing bug... any others?
[03:28] <spm> https://bugs.edge.launchpad.net/launchpad-foundations/+bug/559128 <== basically auto updates are suspended as they've been breaking. We even a "Be Ware!" note doing CP's that they too can go spectacularly south.
[03:28] <mup> Bug #559128: edge rollouts broke CSS <Launchpad Foundations:In Progress by flacoste> <https://launchpad.net/bugs/559128>
[03:30] <thumper> plumbing emergency
[03:30] <thumper> AFK
[03:33] <lifeless> ok, and how do I run a single test ?
[03:35] <lifeless> wgrant: ^
[03:39] <wgrant> lifeless: I generally use bin/test -cvvt nameoftest
[03:39] <lifeless> wgrant: what generates bin/py ?
[03:40] <wgrant> lifeless: buildout, probably. Just run make.
[03:40] <lifeless> ok
[03:40] <lifeless> whats the magic to fix
[03:40] <lifeless>   Getting distribution for 'zope.testing==3.9.4'.
[03:40] <lifeless> Error: Couldn't find a distribution for 'zope.testing==3.9.4'.
[03:40] <lifeless> ?
[03:40] <wgrant> Update your download-cache.
[03:41] <wgrant> Or just rocketfuel-get
[03:41] <lifeless> make update-your-download-cache ?
[03:42] <wgrant> bzr up ~/launchpad/lp-sourcedeps/download-cache
[03:42] <wgrant> rocketfuel-get will do that for you, though.
[03:49] <lifeless> wgrant: hmm, not finding the test
[03:54] <wgrant> lifeless: Which test, and what are you running?
[03:55] <lifeless> its a single test in a unittest test file, not a doctest
[03:55] <lifeless> with -ct it seems to find it
[03:55] <lifeless> I'm running 'testr run -- -ct testname' now
[04:11] <mwhudson> spm: so are the code import slaves on a newer branch yet?
[04:12] <spm> mwhudson: alas no...
[04:18] <mwhudson> wgrant: i pushed a fix for the serveOverHTTP hang to ~launchpad-committers/launchpad/python2.6
[04:22] <thumper> mwhudson: did your emacs change font when upgrading to lucid?
[04:23] <mwhudson> thumper: maybe
[04:24] <mwhudson> it certainly has done on upgrade before, don't remember if the lucid upgrade did
[04:25] <thumper> mwhudson: because I don't like the current font but I can't remember what I had :(
[04:25] <mwhudson> thumper: heh
[04:26] <mwhudson> thumper: i seem to be using "DejaVu Sans Mono"
[04:27] <thumper> seems good enough I suppose
[04:27] <thumper> I don't feel happy with any of them
[04:31] <spm> I used to use one called 'console' for terminals; bu tthe latest version of 'konsole' makes a *horrible* mess of that and a few other fonts; so switched to dejavu sans mono, which is the least worst...
[04:31] <thumper> mwhudson: how is your afternoon going?
[04:31] <mwhudson> thumper: ok i guess
[04:32] <thumper> mwhudson: need to talk or are you chugging along nicely?
[04:32] <mwhudson> thumper: still working on the no-hosted-area puller, i deleted a few too many tests
[04:32] <thumper> mwhudson: I can't do the qa I wanted to do
[04:32] <thumper> heh
[04:32] <mwhudson> thumper: argh
[04:33] <thumper> I could fix the issue that sinzui assigned to 10.04
[04:33] <thumper> for us
[05:00] <lifeless> thumper: mwhudson: for one of you; argh
[05:00] <lifeless> timeout proposing the branch
[05:00] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/merge
[05:00] <lifeless> ok got it in on 4th try
[05:00] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/merge/+merge/23521
[05:01] <wgrant> mwhudson: Only 'slightly horrible'? :P
[05:02] <wgrant> lifeless: There seems to be something really really wrong with that diff.
[05:02] <thumper> the timeouts suck
[05:02] <thumper> I wonder why you are getting those
[05:02] <wgrant> I guess because you proposed to db-devel rather than devel.
[05:02] <lifeless> wgrant: I proposed to the thing lp suggested I should
[05:02] <wgrant> Yeah, the development focus is not actually the focus of development, in Launchpad's case
[05:03] <lifeless> wasn't there a thread to fix that ?
[05:03] <thumper> well...
[05:03] <thumper> the development focus is the default stacking target
[05:04] <mwhudson> wgrant: there's no monkey patching
[05:04] <mwhudson> at least
[05:04] <wgrant> mwhudson: True.
[05:05] <mwhudson> lifeless: the timeouts are probably because the branch was still being scanned
[05:05] <mwhudson> (yay branchrevision!)
[05:05] <wgrant> maxb: You appear to have fixed bug #526826; you might want to assign it to yourself and mark it as Fix Committed.
[05:05] <mup> Bug #526826: test_ftparchive failing on Lucid <soyuz-publish> <tech-debt> <Soyuz:Triaged> <https://launchpad.net/bugs/526826>
[05:06] <wgrant> mwhudson: Is BranchRevision going to become less stupid some time soon?
[05:11] <wgrant> stub: Is trusted.sql tested anywhere?
[05:11] <mwhudson> wgrant: hopefully
[05:12] <stub> make schema ensures it is syntactically correct.
[05:13] <stub> Individual bits get tested when those application layer bits get tested.
[05:13] <stub> such as the triggers etc.
[05:13] <stub> check constraints etc. not so much, as they are just a safety net (the application needs to handle validation nicely, rather than have the database throw back exceptions to the end user)
[05:16] <lifeless> wgrant: should I repropose against devel ?
[05:16] <wgrant> lifeless: Probably. Otherwise ec2 land won't DTRT, and the diff will make people scream.
[05:17] <lifeless> why doesn't devel turn up in the web form ?
[05:19] <lifeless> done
[05:23] <lifeless> thumper: your trivial fix is done, I think.
[05:29] <mwhudson> grr fricking slow acceptance tests :(
[05:30] <wgrant> mwhudson: Slow, or hanging?
[05:31] <mwhudson> just slow
[05:36] <thumper> do we have official redacted text?
[05:47] <wgrant> thumper: Private teams used <hidden>.
[05:47] <wgrant> But there's already special text for redacted import URLs, isn't there?
[05:48]  * thumper shrugs
[05:48] <thumper> mwhudson: I'll do the merge conflict if you like
[05:49] <mwhudson> thumper: that'd be cool
[06:05] <thumper> fix submitted
[06:08] <thumper> what was the solution to SFTPError: Garbage packet received ?
[06:09] <thumper> using ec2 land
[06:09] <thumper> _ensure_ec2test_user_has_keys is in the stacktrace
[06:11] <mwhudson> thumper: merge devel
[06:11] <mwhudson> thumper: but that was quite a while ago, is this an old branch?
[06:11] <thumper> mwhudson: no, newly created from devel about an hour ago
[06:11] <mwhudson> or if it's branched of production-devel i guess you can run ./utilities/ec2 from devel;
[06:11] <thumper> ah
[06:11] <mwhudson> thumper: don't know then
[06:11] <thumper> no it isn't
[06:11] <thumper> it uses the LCA from devel and production-devel
[06:12]  * thumper pqm submits
[06:13] <lifeless> thumper: I know its near EOD; if you could tell me if I did roughly the right thing - even if its not a full review - that would be awesome
[06:13] <thumper> which url?
[06:14] <lifeless> https://code.edge.launchpad.net/~lifeless/launchpad/merge/+merge/23523
[06:16] <lifeless> thumper: ^
[06:18] <thumper> commented
[06:20] <lifeless> thanks!
[06:21] <lifeless> thumper: why does mergeFailed not dequeue ?
[06:34]  * mwhudson submits no-hosted-area to ec2 test -- should be good for a laugh -- and EOWs
[06:34] <lifeless> thumper: in fact, I'm deleting mergeFailed, because its cleaner.
[06:34] <lifeless> thumper: if its not deleted, dequeue has to be a special case
[07:03] <lifeless> thumper: if you haven't eod'd, I've replied.
[07:25] <maxb> wgrant: thanks, didn't realize there was a bug for that
[07:30] <adeuring> good morning
[07:34] <wgrant> maxb: What were the 2.6 pygpgme failures that you mentioned earlier?
[07:34] <wgrant> I don't see any.
[07:35] <stub> Who prepared out Python2.5 packages? I'm missing setuptools and easy_install isn't there either for the quick fix (catch-22 there I guess...)
[07:36] <maxb> wgrant: I submitted a branch for bumping to the existing r49 of the sourcecode/pygpgme branch, assuming it would have been tested before it got landed there. But actually, it breaks things
[07:36] <maxb> stub: that would be me and wgrant
[07:36] <wgrant> maxb: Ah, so it didn't actually land?
[07:37] <stub> Is it quick to get the packages made (eg. copying the packages from hardy into the PPA)? Or should I just install setuptools from source?
[07:37] <stub> c/hardy/karmic
[07:37] <wgrant> Why do you need setuptools?
[07:37] <stub> I need to generate 2.5 eggs
[07:37] <wgrant> Ah.
[07:38] <wgrant> A no-change rebuild should do it, I think.
[07:38] <maxb> wgrant: specifically, pygpgme seems to be returning unicode strings instead of byte strings all over the place now, leading to doctests puking all over the place - plus some other fails :-(
[07:38] <wgrant> Lucid?
[07:38] <stub> Yup
[07:38] <wgrant> maxb: Hm. Damn. We'd best fix that.
[07:39] <stub> So I just find the Karmic package and copy it into the Launchpad PPA, with the rebuild option selected?
[07:39] <maxb> stub: no!
[07:40] <maxb> why do we need this, btw?
[07:40] <stub> There is an open bug in distutils, the end result being we need to use eggs of pytz rather than tarballs.
[07:41] <stub> I can't generate a new 2.5 egg of pytz at the moment because setuptools isn't installed on my box.
[07:41] <maxb> oh, yes. I really need to got back to upstream on that
[07:41] <stub> I can just install from source if it isn't a quick fix
[07:41] <maxb> s/distutils/setuptools and distribute/
[07:42] <stub> Yer - first part of installing from source is working out what needs to be installed ;)
[07:42] <maxb> stub: Lucid has switched from setuptools to distribute. Installing setuptools on lucid would be.... potentially chaotic
[07:45] <maxb> I wonder if I should do a no-change upload of distribute to the ppa
[07:46] <wgrant> Worth a try.
[07:46] <stub> It won't be a dependency, so it won't make anything explode
[07:47] <wgrant> Uh... well...
[07:48] <wgrant> I might point out that *buildout* is involved here.
[07:48] <maxb> :-)
[07:49]  * stub lunches
[07:50]  * maxb lpnochange distribute
[08:05] <stub> ta. I'll give that a spin when I'm back
[09:00] <mrevell> Morning
[10:17] <mwhudson> jml: so, how do i use subunit?
[10:18] <mwhudson> i have this test results mail and i'd like to have a list of failing tests
[10:19] <jml> mwhudson, you could open it in tribunal, use subunit2pyunit or use subunit-filter
[10:19] <jml> mwhudson, is there no list of failing tests in the email?
[10:20] <mwhudson> not that i can see
[10:20] <mwhudson> also subunit-filter is breaking
[10:20] <jml> mwhudson, can you please forward me the email?
[10:21] <jml> mwhudson, how is it breaking?
[10:22] <mwhudson> jml: http://pastebin.ubuntu.com/415439/
[10:23] <mwhudson> jml: mail sent
[10:44] <maxb> mwhudson: Your hackery regarding test hangs under python2.6 is.... intriguing :-)
[10:44] <maxb> I am rather mystified, as I can't pin down the underlying cause of the problem appearing
[10:44] <mwhudson> maxb: yeah, i couldn't reproduce the problem in a small example
[10:45] <mwhudson> but my socket knowledge has bit rotted a bit
[10:45] <maxb> oh, really? I did
[10:45] <maxb> h=HTTPServer(); h.start_server(); h.stop_server(); h._http_thread.join()  <<<<HANG
[10:45] <mwhudson> the issue is that in 2.5 socket.shutdown() gets called when another thread is in accept, and accept returns when this happens
[10:46] <mwhudson> maxb: i meant 'just using the socket module'
[10:46] <mwhudson> in 2.6 the other thread is in select(), not accept()
[10:46] <maxb> oh, really? I didn't pursue the shutdown angle. I went straight to 'why doesn't closing the socket kick it out of select()'
[10:47] <maxb> and the answer seems to be 'Python has a LAAAAME wrapper that attempts to implement platform-agnostic socket.dup() which doesn't actually close the socket'
[10:48] <maxb> I think I might have a try at simplifying your changes - I postulate that adding a server._http_thread._sock.close() cleanup will do the job
[10:48] <mwhudson> ah
[10:49] <mwhudson> i wasn't very awake when i was digging :)
[10:50] <maxb> hmm. oh gosh. I wonder if the very fact we're inside a select on the socket is what keeps alive the refcount which stops the socket being closed
[11:01] <mwhudson> well, in 2.5 we're in an accept() when stop_server is called
[11:08] <deryck> Morning, all.
[11:23] <jml> mwhudson, I'm going to spend a little time digging around your subunit failure
[11:23]  * jml is off the phone now
[11:31] <jml> mwhudson, fuck
[11:31] <jml> mwhudson, I think this is a \r\n problme
[11:34] <bigjools> mwhudson: thanks for fixing my fsckup
[11:36] <bigjools> jml: I responded to some of your questions on the pools LEP
[11:36] <jml> bigjools, thanks.
[11:36] <bigjools> some new mockups done
[11:36] <bigjools> well, changed
[11:38] <wgrant> bigjools: How inappropriate would it be to rSP bugs when closing them from a changelog?
[11:38] <bigjools> wgrant: rSP?
[11:38] <maxb> removeSecurityProxy?
[11:38] <wgrant> bigjools: removeSecurityProxy. It's already pretty much done in the normal case, where process-upload.py uses a permissive security policy.
[11:38] <bigjools> right
[11:39] <bigjools> my initial reaction is: nofuckingwayareyoumad?
[11:39] <bigjools> :)
[11:39] <bigjools> the right approach is to get the security model correct
[11:39] <bigjools> rSP is just papering over turd-smeared walls
[11:39] <wgrant> What is 'correct' here?
[11:40] <wgrant> It is.
[11:40] <wgrant> But switching to a permissive policy during a webapp request sounds approximately infinitely worse.
[11:40] <bigjools> we need to define "correct"
[11:40] <maxb> When do you close bugs from a changelog from a webapp request?
[11:40] <bigjools> queue accept
[11:41] <maxb> ah
[11:41] <bigjools> deryck: around?
[11:41] <maxb> Why doesn't the accepting user have permission to close the bug anyway?
[11:41] <wgrant> maxb: The bug is private.
[11:41] <maxb> hmm
[11:41] <deryck> bigjools, hi
[11:42] <bigjools> hey deryck, can you check scrollback and give your opinion please?
[11:42] <wgrant> (a similar thing can also now happen if a public bug is Won't Fix, although I believe all of ~ubuntu-archive has sufficient privs to avoid that problem)
[11:42]  * deryck looks
[11:42] <bigjools> deryck: just 3 mins back
[11:42] <wgrant> Bug 564491
[11:42] <mup> Bug #564491: Cannot accept package which closes inaccessible bug <oops> <queue-page> <ui> <Soyuz:Triaged> <https://launchpad.net/bugs/564491>
[11:43] <henninge> wgrant, bigjools: Hi!
[11:43] <henninge> ;)
[11:43] <bigjools> guten tag henninge
[11:43] <deryck> bigjools, do you mean how do I feel about using  removeSecurityProxy?
[11:43] <wgrant> Morning henninge.
[11:43] <henninge> Is bug 539185 valid?
[11:43] <mup> Bug #539185: BuildBase implementation for build farm jobs <buildfarm> <Launchpad Translations:Triaged> <https://launchpad.net/bugs/539185>
[11:43] <wgrant> That sounds like a noodles question.
[11:44] <bigjools> deryck: that's a no-no AFAIAC, but it would be good to see if you have any good ideas on how to deal with this situation "properly"
[11:44] <wgrant> AIUI he is reworking that all.
[11:44] <bigjools> he is
[11:44] <henninge> so I should not touch that atm?
[11:44] <wgrant> henninge: That sounds sane.
[11:44] <bigjools> henninge: have a chat with him, you might be able to help :)
[11:45] <henninge> or that ;-)
[11:45] <jml> mwhudson, it's definitely a \r\n bug
[11:45] <danilos> bigjools, naughty, naughty boy... ;)
[11:45] <bigjools> danilos: I know, I suck
[11:45] <bigjools> assumptions are the mother of all fuckups, as they say
[11:45] <danilos> bigjools, but sure, if it needs helping, and henninge can do it while making sure it works for us as well, excellent :)
[11:45] <deryck> bigjools, what is the user when trying to close a bug from a changelog?  I'm afraid I need to understand better.
[11:45] <henninge> danilos: I would have expected nothing else
[11:46] <bigjools> danilos: well that would be beneficial to us all, yes :)
[11:46] <henninge> noodles775: Are you out to lunch? ;-)
[11:46] <bigjools> deryck: let's have a call
[11:46] <bigjools> I can explain
[11:46] <wgrant> Speaking of the buildfarm... can we have a launchpad-buildfarm project so we can stop randomly assigning bugs between Code, Soyuz and Translations?
[11:46] <danilos> henninge, you are in the same country, just drop by him
[11:46] <henninge> ;-)
[11:46] <bigjools> wgrant: yeah, I'll try and set that up
[11:46] <henninge> danilos: true, it's my turn. Last time he came by me.
[11:46] <danilos> wgrant, no, let's just assign them all to soyuz
[11:46] <deryck> bigjools, sure.  skype or mumble?
[11:47]  * danilos puts on an innocent smile
[11:47] <bigjools> deryck: given that I wasn't around when mumble accounts got handed out, skype :)
[11:47] <bigjools> hopefully they'll be openid today or monday
[11:47]  * wgrant hastily uses launchpadlib to reassign all soyuz-build bugs to danilos.
[11:47] <bigjools> lol
[11:47] <danilos> heh
[11:48] <deryck> bigjools, give me 2 minutes to close something here.
[11:48] <danilos> that API thing was a big mistake!
[11:48] <noodles775> henninge: nope, I'm here.
[11:48] <bigjools> deryck: ok call when you're ready, you can guess my skype id ...
[11:49] <bigjools> mmm can't see any ash in the sky yet
[11:50] <wgrant> I wonder when air traffic will resume.
[11:50] <bigjools> this evening they say
[11:50] <bigjools> but they said this morning, yesterday :)
[11:50] <wgrant> Qantas here is saying Sunday.
[11:50] <bigjools> depends on where each airline's planes are located I guess, they need to catch up
[11:51] <wgrant> I guess, yeah.
[11:51] <wgrant> But it probably depends more on what the eruption does...
[11:56] <jml> we really should have "components" in the tracker
[11:56] <jml> mwhudson, I guess you're beyond caring right now, but I can't track down why the critical '\r' character is being dropped
[11:56] <noodles775> henninge, danilos, wgrant: bug updated (well, commented).
[11:56] <wgrant> jml: +inf
[11:57] <danilos> noodles775, thanks
[11:57] <henninge> noodles775: great thanks!
[11:57]  * henninge goes to lunch now ...
[11:57] <henninge> ;-)
[11:58] <danilos> noodles775, that does sound great as well, thanks :)
[12:00] <noodles775> np.
[12:01]  * noodles775 follows henninge 
[12:04] <maxb> noodles775: Hi. Has the ec2 of lp:~maxb/launchpad/use-pygpgme-r49 hung, or has it died and just not sent me an email?
[12:12] <jelmer> maxb: it would've died, that's what's happened to me twice now so I expect it to not be a coincidence
[12:12] <jml> I thought we fixed that issue
[12:13] <jelmer> It's a different one probably
[12:13] <jelmer> I have no problems with other branches, just with this specific one
[12:20] <lifeless> jml: you might like, in your 'advocating apis sub-hat', the recent commits to lp:pqm
[12:20] <jml> lifeless, thanks for the heads up
[12:21] <maxb> jelmer: Hi. I have run into test failures when I try to update pygpgme to the update you landed on the sourcecode branch. Do you know anything about that?
[12:39] <bigjools> jml: do you know much about twisted's TimeoutMixin?
[12:40] <jml> bigjools, I know a bit.
[12:40] <bigjools> we appear to see it completely ignoring the timeout that was set
[12:40] <jml> bigjools, show me the cdoe
[12:41] <bigjools> and an exception ensues
[12:41] <bigjools> jml: top of lib/lp/buildmaster/manager.py
[12:41] <jml> bigjools, today's stable recent enough?
[12:41] <bigjools> oh yes
[12:41] <jml> bigjools, can you show me the error too?
[12:41] <bigjools> yup one sec
[12:42] <bigjools> jml: http://pastebin.ubuntu.com/415490/
[12:42] <deryck> Could someone please subscribe me to bug 441039?
[12:42] <mup> Bug #441039: Ubuntu One crashed on launch <apport-crash> <i386> <ubuntuone-karmic> <Android's Fortune:Invalid> <NULL Project:Invalid> <Ubuntu One Client:Fix Released by dobey> <ubuntuone-client (Ubuntu):Fix Committed by dobey> <https://launchpad.net/bugs/441039>
[12:45] <jml> bigjools, have you reproduced this on a development environment?
[12:45] <bigjools> jml: hahaha
[12:46] <jml> bigjools, I can help you write a unit test for this.
[12:46] <bigjools> sounds good
[12:46] <jml> bigjools, couple more questions first though
[12:46] <bigjools> wgrant: you have a local builder setup, can you re-produce this?
[12:46] <jml> bigjools, what is config.builddmaster.socket_timeout set to on production?
[12:47] <wgrant> bigjools: It doesn't actually need a builder at all. But I will try it.
[12:47] <wgrant> Oh, wait, that one does.
[12:47] <wgrant> Not the one I thought.
[12:47] <bigjools> it's where it ignores the timeout when scanning it
[12:47]  * wgrant firewalls.
[12:48] <bigjools> jml: 180
[12:48] <jml> bigjools, how did you figure that out?
[12:48] <bigjools> jml: I looked in the production configs
[12:49] <jml> bigjools, are we sure they are the ones being used in the deployment with this error?
[12:50] <bigjools> jml: reasonably, why?
[12:50] <bigjools> I'll get lamont to check
[12:50] <jml> bigjools, well, if it's not set, or if it's set to a value higher than the system socket timeout, then no amount of debugging will help.
[12:51] <bigjools> system is like an hour, I thought?
[12:51] <bigjools> but maybe it's not the default any morie
[12:51] <jml> bigjools, well, as far as I can tell from that log you pasted, it is timing out roughly three minutes after the process starts
[12:52] <bigjools> which is 180 seconds as the config says
[12:52] <jml> right.
[12:52] <deryck> adeuring, can you subscribe me to bug 441039 please?
[12:52] <mup> Bug #441039: Ubuntu One crashed on launch <apport-crash> <i386> <ubuntuone-karmic> <Android's Fortune:Invalid> <NULL Project:Invalid> <Ubuntu One Client:Fix Released by dobey> <ubuntuone-client (Ubuntu):Fix Committed by dobey> <https://launchpad.net/bugs/441039>
[12:52] <jml> so what's happening that differs from what you are expecting?
[12:53] <bigjools> I wasn't expecting a traceback
[12:53] <jml> deryck, done
[12:53] <wgrant> bigjools: So, I get a connection timeout after 20 seconds here. It looks like the dev timeout should be 40 seconds.
[12:53] <bigjools> but I don't know twistd well enough to know what it's supposed to do when the timeout is set
[12:53] <adeuring> deryck: "The following errors were encountered:Deryck Hodge has already been subscribed"
[12:53] <bigjools> jml: is there a callback from the setTimeout() call if it does time out?
[12:54] <deryck> adeuring, ah, ok.  someone must have already.  thanks.
[12:54] <bigjools> wgrant: yeah dev is 40. ummm wtf
[12:54] <jml> bigjools, yeah, timeoutConnection
[12:54] <jml> bigjools, http://paste.ubuntu.com/415493/
[12:55] <bigjools> jml: which is not defined in the buildd-manager ....
[12:55] <bigjools> ho ho ho
[12:55] <jml> bigjools, the default implementation disconnects
[12:56] <bigjools> jml: ok I'm trying to work out what effect that would have on b-m
[12:56] <jml> http://twistedmatrix.com/documents/current/api/twisted.protocols.policies.TimeoutMixin.html fwiw
[12:56] <wgrant> bigjools: To be clear, I get a traceback like that, except with a normal socket exception.
[12:56] <bigjools> ok
[12:57] <bigjools> so I can't figure out if that's normal for the timeout that was set or if something else causes it
[12:58] <jml> well, it's not an error that TimeoutMixin generates
[12:58] <jml> but it's reasonable to expect xmlrpclib to explode if its socket is disconnected from under it.
[12:59] <bigjools> we don't get the "Scanning failed with:" message so it's not hitting the scanFailed callback
[12:59] <bigjools> I would have expected twisted to catch that and call the right callback in the Deferred
[12:59] <jml> hmm
[13:00] <bigjools> which is what we normally see
[13:00] <bigjools> so I still wonder if it's a twistd bug
[13:00] <jml> bigjools, what kind of object is "self.slave" in the traceback you pasted
[13:01] <bigjools> heh
[13:02] <jml> bigjools, nvm
[13:02] <bigjools> this stuff is like black magic
[13:02] <lifeless> its not that clean
[13:02] <bigjools> ha
[13:03] <bigjools> I know that it's an xmlrpc thingy but I can't find exactly where it's instantiated
[13:03] <jml> bigjools, because it looks like it's using a non-Twisted xmlrpc client
[13:03] <bigjools> because this code is so obtuse
[13:04] <jml> I also can't find where the 'echo' method that is called in the traceback is defined
[13:04] <bigjools> xmlrpclib.ServerProxy
[13:04] <bigjools> in there ^
[13:04] <jml> no it's not.
[13:05] <jml> ServerProxy has magic __getattr__ evil
[13:05] <jml> but where's the server-side implementation that it's trying to call?
[13:07] <bigjools> jml: see lib/canonical/buildd/slave.py
[13:07] <bigjools> it's magic, like I sid
[13:07] <bigjools> said
[13:07] <jml> ok.
[13:07] <bigjools> :)
[13:07] <bigjools> XMLRPCBuildDSlave specifically
[13:07] <jml> bigjools, so the thing is, we hate transparent RPC in Twisted
[13:08] <bigjools> s/in Twisted//
[13:08] <jml> bigjools, well, we hate it enough to do something about it
[13:08] <wgrant> This is why we have the even more transparent launchpadlib...?
[13:08] <jml> bigjools, your hatred is like a candle to our sun
[13:08] <bigjools> rofl
[13:09] <jml> self.slave.callRemote('echo', ...) is the way it's normally done in Twisted
[13:09] <noodles775> maxb: hey. I only received emails about trivial-bad-httpcaller..., py2.6-warnings and tolerate-lucid-apt... It was definitely running as I checked it's status when you asked yesterday, so I'd say it died :/
[13:09] <lifeless> wgrant: launchpadlib makes me think of the movie Mystery Men
[13:09] <bigjools> jml: basically this won;t work then until we make both sides use twisted's xmlrpc gubbins?
[13:10] <maxb> noodles775: ok. no need to resumbit, it has further problems that need addressing anyway.
[13:10] <jml> bigjools, so, I _think_ what's happening here is that the twisted client with the timeout mixin is doing its job and pulling the rug out from under the non-twisted client
[13:10] <jml> bigjools, but that's only a guess
[13:10] <jml> bigjools, yeah, I think so.
[13:10] <bigjools> jml: I concur with you
[13:10] <wgrant> Why does the slave need to?
[13:10] <bigjools> jml: I wonder if there's anything we can do on the client side to handle this better in the timeout callback
[13:11] <bigjools> where the slave == the server side (confusing I know)
[13:11] <jml> bigjools, you mean, as a work-around?
[13:11] <bigjools> yes
[13:11] <jml> bigjools, nothing leaps to mind
[13:11] <bigjools> I have no desire to start re-writing the xmlrpc innards :(
[13:12] <jml> bigjools, and as for adding another obscure workaround to this code... the phrase "house of cards" leaps to mind.
[13:12] <bigjools> :)
[13:12] <bigjools> the stuff at the top of lib/lp/buildmaster/model/builder.py also deals with timeouts
[13:13] <jml> bigjools, you could wrap the non-twisted xmlrpc calls in a try/except block -- that'd be your quickest way out, I think.
[13:13] <jml> bigjools, yeah, that'll be what's triggering the error you see.
[13:13]  * bigjools idly flicks the bottom card away
[13:13] <jml> gah
[13:13] <jml> I have no idea how this code works at all
[13:14] <bigjools> is there anyone here in Sao Paulo who's prepared to do some kidnapping?
[13:14] <wgrant> We really really need to refactor things a bit so RecordingSlave can DIE.
[13:14] <wgrant> Hahah.
[13:15] <wgrant> I know how it mostly works... but it's mostly evil.
[13:15] <bigjools> every time I think I understand it, I promptly get confused again
[13:16] <bigjools> RecordingSlave was a quick way to avoid doing what I hinted at earlier - re-writing the xmlrpc gubbins to be twisted
[13:16] <jml> hmm
[13:16] <jml> are there any bugs filed about cleaning it up?
[13:16] <wgrant> It's not *that* hard. Just sometimes you'll get a RecordingSlave, sometimes you'll get a BuilderSlave, and sometimes it depends on who called this particular bit of code this time. And then you get fake responses which are fricking confusing and aaarrrrgh.
[13:16] <jml> I might add them to my someday/maybe list.
[13:16] <bigjools> it's basically proxying what's in BuilderSlave
[13:16] <jml> you know
[13:17] <jml> after I fix subunit, land the ssh server changes, make pretty graphs for bugs and make our test suite runnable more than once on a computer
[13:17] <bigjools> can I have a flying car
[13:17] <wgrant> Only if it's asynchronous.
[13:18]  * jml returns bigjools a Deferred that will fire a flying car on success
[13:18] <bigjools> ha
[13:18] <jml> actually, maybe before the runnable-more-than-once thing
[13:21] <bigjools> jml: I wonder if we just need to remove that timeout in builder.py and wait for the twisted one to work instead
[13:21] <bigjools> it seems like they will compete
[13:21] <jml> bigjools, they'll definitely compete
[13:23] <jml> zoinks
[13:23] <bigjools> jml: this is not using twisted xmlrpc at all, RecordingSlave is just setting up a load of Deferreds
[13:23] <bigjools> the mixin seems like a total waste of time?
[13:24] <jml> bigjools, well, dispatchBuild and checkDispatch use it
[13:24] <jml> I think
[13:27] <stub> maxb: That distribute package just seems to have 2.6 stuff in it. No 2.5.
[13:27] <maxb> ugh
[13:27] <jml> unfortunately, I've got a bucket load of stuff to do today. :(
[13:28] <maxb> It must not respond to the general python version selections presented in python-defaults and python-support
[13:28] <maxb> I am about to lunch. I'll take a look afterwards
[13:29] <bigjools> jml: no worries, thanks for your time
[13:30] <jml> bigjools, np. my pleasure.
[13:31] <bigjools> jml: I think I can throw an extra catch in here to get that timeout but I've no idea how to test it!
[13:37] <gmb> allenap, Do you have time for a call about bug 530113?
[13:37] <mup> Bug #530113: Information on a bugwatch error is obscure <story-reliable-bug-syncing> <Launchpad Bugs:In Progress by gmb> <https://launchpad.net/bugs/530113>
[13:37] <allenap> gmb: In about 3 minutes (ordering computer parts, woot).
[13:37] <gmb> allenap, Cool, I'll sit around on t'mumble.
[13:38] <jml> bigjools, I know how to test timeouts with pure Twisted systems
[13:39] <jml> boo yah
[13:39] <jml> the first of my four SSH branches just passed ec2 test
[13:39] <jml> (they failed yesterday because devel was broken)
[13:39] <bigjools> jml: I'll think of something hackish no doubt
[13:39] <bigjools> jml: I apologise for breaking devel
[13:40] <jml> bigjools, np. the real problem is the system that allows a simple human error to screw up other people's workflows
[13:42] <bigjools> aye
[13:50] <bigjools> jml: if you have a sec can you look at lib/lp/buildmaster/model/builder.py -  updateBuilderStatus()
[13:51] <bigjools> and tell me what else it needs to catch to get that timeout?
[13:52] <jml> bigjools, that ought to be it...
[13:53] <bigjools> you'd think :/
[13:53] <jml> bigjools, easy enough to figure out though. Make a TimeoutHTTPConnection work-a-like, give it a low timeout, see what error gets raised
[13:54] <bigjools> right
[13:54] <bigjools> shame it's not in the log :(
[13:54] <bigjools> mmm this makes me hungry
[13:54] <jml> I think it's more that socket module has crap errors.
[14:15] <deryck> yay, gnome-bugs bugs are updating!
[14:15] <deryck> gmb, error message question for bug watch update activity....
[14:16] <deryck> gmb, see bug 44082
[14:16] <mup> Bug #44082: GNOME Panel icons (on right side) move apparently randomly on session start in some situations <gloam> <qa-hardy-desktop> <qa-jaunty-desktop> <qa-karmic-desktop> <GNOME Panel:Fix Released> <One Hundred Paper Cuts:Confirmed for ryan.maki> <gnome-panel (Ubuntu):Confirmed for desktop-bugs> <gnome-panel (Ubuntu Hardy):Triaged by desktop-bugs> <https://launchpad.net/bugs/44082>
[14:16] <gmb> Urr.
[14:16] <nigelb> deryck, its more like "oh no! mail flood!"
[14:16] <deryck> nigelb, for you. :-)  For me, it's "oh happy day, praise be to the internet almighty." :-)
[14:17] <nigelb> deryck, haha.
[14:17] <gmb> deryck, Whatsyerquestion?
[14:18] <deryck> gmb, so expand the first task row.... that error there?  Is that from bug watch activity log?  It seems out of date, since the bug is in fact updated now.
[14:18] <gmb> deryck, It's not from the activity log, no, it's from the last_error_type property of BugWatch. Let me just have a poke around and see if I can find out what's oging on.
[14:19] <deryck> gmb, cool, thanks.  I want this expandable form to go away.  It causes no end of grief since it gets out of sync with the rest of the app.
[14:22] <maxb> Is there any mechanism by which a ~launchpad-pqm sourcecode branch can be push --overwritten?
[14:24] <gmb> deryck, allenap: AHAHAHAHA
[14:24] <deryck> oh, do tell
[14:24] <gmb> deryck, So, that error is a real error. The status sync succeeded but the backlinking failed (and our errors aren't smart enough to handle that yet; will fix that this pm).
[14:24] <gmb> deryck, OOPS-1567CCW1152
[14:25] <gmb> (Another win for BWA, though)
[14:25] <deryck> indeed!  This logging is working out well.
[14:25] <gmb> deryck, allenap: Looks like we don't have permission to backlink on the remote system.
[14:25] <allenap> gmb: Oh, jolly good.
[14:26] <gmb> allenap, I think it might be because we (used to?) backlink for every watch, whether the LP bug was relevant or not.
[14:26] <gmb> So the gnome-bugs admins disabled backlinking.
[14:26] <allenap> gmb: That sounds right.
[14:27] <gmb> allenap, Is there an easy way to disable backlinking on our end to prevent the errors or is it not fine-grained enough for that? ICR.
[14:28] <allenap> gmb: Not fine-grained enough.
[14:29] <allenap> gmb: We could quite easily disable all back-linking by removing the ISupportsBackLinking interface from BugzillaAPI, but that could/would affect other trackers.
[14:30] <gmb> allenap, Yeah.
[14:30] <gmb> allenap, Though, hang on, if we can't sync comments why are we trying to backlink anyway?
[14:30] <gmb> That seems like huffing on the bong pipe to me.
[14:31]  * allenap looks
[14:31] <allenap> gmb: It's not conditional on sync_comments.
[14:32] <gmb> allenap, I think it should be. That would solve this problem for a start.
[14:33] <allenap> gmb: The condition, in full, is: (bug not dupe and linked to at least one bugtask and supports back-linking)
[14:33] <danilos> noodles775, hi, do you have any suggestions how could I QA https://code.edge.launchpad.net/~jtv/launchpad/bug-553077/+merge/22599?
[14:33]  * noodles775 looks
[14:34] <gmb> allenap, Right. Do you think that sync_comments should be used there too? I mean, I know it's a misnomer if we do that, but...
[14:34] <stub> maxb: np. I worked around by installing from pypi. I then uninstalled it after generating the eggs, as buildout exploded ( https://bugs.edge.launchpad.net/launchpad-foundations/+bug/564680 ). I'm not sure if your package will cause the same issue, but maybe it is best not bothering (I can survive, and we should be on 2.6 sometime soonish)
[14:34] <mup> Bug #564680: buildout explodes when distribute is installed <Launchpad Foundations:New> <https://launchpad.net/bugs/564680>
[14:34] <noodles775> danilos: nope.
[14:35] <noodles775> danilos: I mean, if the buildd's are still running, it's effectively qa'd.
[14:35] <wgrant> But that code is not on production at the moment.
[14:35] <noodles775> danilos: so, ensuring dogfo..
[14:36] <danilos> noodles775, so, how do I get that tested on dogfood?
[14:36] <noodles775> danilos: so, ensuring the buildd's used by dogfood are updated, and then that it still works.
[14:37] <noodles775> danilos: as long as we ensure the buildd's are updated, we can just push a build through on df.
[14:39]  * noodles775 checks with lamont to get the buildd's updated on dogfood.
[14:39] <danilos> noodles775, cool, thanks (I totally haven't done anything about this, so I don't even know where to start)
[14:42] <mars> danilos, looks like you found a bug in paramiko: line 163, "str(data[:chunk])" should be unicode(data...)?
[14:43] <mars> danilos, don't know why it would start failing now though
[14:45] <danilos> mars, it might not be recent, I haven't used ec2 for a while
[14:47] <mars> hey, paramiko uses Launchpad! :)  https://edge.launchpad.net/paramiko
[14:50] <danilos> mars, I can file a bug, if you think that's the thing to do :)
[14:59] <mars> danilos, not sure if switching to unicode would help.  I just tried an experiement in ipython, and reproduced that error.  It is the str() call.
[15:00] <mars> str(u'Māris')  raises the error
[15:02] <danilos> mars, right, it'd be worth seeing if it makes sense to .encode('utf-8') before passing it out to paramiko: it might be that unicode there won't help either and it'll barf later if no UTF-8 locale is used
[15:04] <mars> danilos, worth a shot.  Looking at the docs, and sftp should support utf-8 encoding for filenames
[15:05] <danilos> mars, well, UTF-8 wasn't called UTF for filenames for nothing on Plan9 I think :)
[15:06] <mars> hehe
[15:06] <danilos> anyway, me goes get some late lunch, will be back later for a short while
[15:35] <mars> rocketfuel-branch is the wrong command to use when making a one-line patch :/
[16:09] <noodles775> sinzui: do you have time in the next 0.5hr for a brief call regarding the style.css work?
[16:09] <noodles775> (no problem if not).
[16:09] <sinzui> I do
[16:27] <mars> gary_poster, have a sec to review a one line patch?  https://code.edge.launchpad.net/~mars/launchpad/fix-ec2-email-encoding/+merge/23557
[16:28] <gary_poster> mars, looking
[16:29] <gary_poster> mars, I'm guessing you have empirical proof it works? :-)
[16:29] <mars> gary_poster, just a traceback from danilos sent to lp-dev.  This same fix is present throughout the ec2test.py file.
[16:31] <mars> gary_poster, I have have danilos try it out before submitting to PQM
[16:32] <gary_poster> mars, alright.  I have vague memories of pain with UTF in email headers and the stdlib email packages, but even if things don't get better, this shouldn't make anything worse (and hopefully it is a fix, of course!).  Yes, would be happy if someone gave it a try before merging.  Will approve with that condition, since you already have it planned.
[16:33] <mars> gary_poster, ok, thanks.  I'll send a mail to danilos saying as much.
[16:33] <gary_poster> cool
[16:33] <gary_poster> approved
[16:58] <bigjools> jml`: still busy?
[16:59] <jml`> bigjools, now is an ok interrupt time
[16:59] <bigjools> jml`: ok should be quick :)
[16:59] <bigjools> see lib/lp/buildmaster/model/builder.py "resumeSlaveHost"
[16:59] <bigjools> versus
[16:59] <bigjools> lib/lp/buildmaster/manager.py "checkResume"
[17:00] <bigjools> the former is called when b-m starts up and reports the stdout/stderr if it fails
[17:00] <bigjools> the latter is asynchronous and I don't know how to do the same
[17:00]  * jml` pulls up the code
[17:00] <bigjools> is stdout/err buried in response somewhere?
[17:02] <jml`> bigjools, is "slave" a different type of object in the two methods?
[17:02] <bigjools> I don't think so
[17:02] <bigjools> unless one's the recording slave and the other's the BuilderSlave
[17:02] <bigjools> who knows :/
[17:03] <jml`> so uhh
[17:03] <jml`> resume is what then?
[17:03] <bigjools> actually yes checkResume is dealing with a RecordingSlave
[17:03] <bigjools> resume is when we restart the VM
[17:03] <bigjools> it ssh'es to the slave and calls a script
[17:03] <bigjools> the slave's host I should say
[17:04] <jml`> bigjools, where is it defined?
[17:04] <bigjools> in config
[17:04] <bigjools> ppa_reset_command or something
[17:04] <bigjools> anyway
[17:04] <jml`> my head hurts
[17:04] <bigjools> I need to get at the output of running that - it uses run_process_with_timeout
[17:05] <bigjools> ok let's keep it simple
[17:05] <bigjools> checkResume gets a response from run_process_with_timeout
[17:05] <bigjools> if the process failed I want its stdout/err
[17:05] <jml`> oh, it's a callback attached to run_process_with_timeout
[17:05] <jml`> ok, I'm on it.
[17:08] <jml`> bigjools, run_process_with_timeout isn't very good.
[17:08] <jml`> bigjools, or at least, it gives you know way of getting at stdout/stderr
[17:08]  * jml` sketches up some code
[17:09] <bigjools> \o/
[17:09] <bigjools> :/
[17:10] <bigjools> if it wasn't Friday afternoon I would be sprawled on my desk in despair
[17:11] <jml`> run_process_with_timeout is using ProcessMonitorProtocolWithTimeout, which is actually intended for code that wants to monitor a process as it's running and report that information to some external system
[17:12] <jml`> i.e. not at all what you want
[17:12] <bigjools> I guess it was used because it has a timeout
[17:12] <bigjools> and the name seemed right
[17:12] <bigjools> *shrug*
[17:14] <bigjools> is this nearer the mark? http://twistedmatrix.com/documents/current/api/twisted.internet.process.Process.html
[17:14] <bigjools> doesn't seem to handle timeouts
[17:14] <jml`> no... http://twistedmatrix.com/documents/current/api/twisted.internet.protocol.ProcessProtocol.html
[17:15] <jml`> make a subclass that accumulates stdout & stderr, fires a deferred on disconnect and mixes in TimeoutMixin
[17:15]  * jml` is doing a rough sketch right now
[17:15] <jml`> Two minutes!
[17:16] <bigjools> you da man
[17:20] <jml`> bigjools, http://paste.ubuntu.com/415642/
[17:21] <bigjools> lookng
[17:22] <jml`> bigjools, ignore that function at the top
[17:22] <bigjools> ok
[17:22] <jml`> the clock business is so you can write unit tests that don't rely on the system clock
[17:23] <bigjools> jml`: looks great, thanks
[17:23] <jml`> you may want to inherit from ProcessProtocolWithTwoStageKill instead of ProcessProtocol, to get the improved killing behaviour
[17:23] <bigjools> "improved"? :)
[17:24] <jml`> bigjools, also, you could actually define "outReceived" and "errReceived", and have them reset the timeout. that'd give a different timeout behaviour which may be more appropriate for what you're doing.
[17:25] <bigjools> right
[17:25] <jml`> bigjools, "improved" as in, "send SIGINT, if it's not dead after a little while, send SIGKILL"
[17:25] <bigjools> don't think it is, the script works in ~6 seconds
[17:25] <bigjools> ah ok, don't really need that sophistication here I think
[17:25] <jml`> bigjools, lucky you :)
[17:26] <bigjools> it's an ssh - it can die die die :)
[17:26] <jml`> bigjools, for the puller, we reset the timeout on activity -- doesn't matter how long a branch takes overall, just as long as we can reasonably expect it to keep making progress.
[17:26] <bigjools> yer
[17:27]  * bigjools hacks
[17:30] <jelmer> maxb: still there?
[17:34] <bigjools> jml`: in timeoutConnection you're using error and it's not defined
[17:34]  * bigjools loves the vim pyflakes plugin
[18:01] <mrevell> Guten nacht
[18:05] <maxb> jelmer: back now
[20:06] <jml`> g'night all