[11:14] hello. echo, echo. [11:37] echo, echo, echo... [11:43] so you're working today benji? [11:44] I'm going to give it a shot. I'm pretty sure I'll be able to. [11:51] so no recovery over the weekend? [12:05] Maybe a slight recorvery. There are some other people at my church that seem to have this and it's taken them a week to significantly improve. [12:08] bac benji call in 2 [12:08] and hiya [12:08] ok [12:38] hey gary_poster would you want to do a pre-review of the memcached fix i came up with as a sanity check? https://code.launchpad.net/~bac/python-memcached/bug-974632/+merge/101148 [12:38] as an alternative to what i did, the readline() method could be changed to do the retry [12:42] bac: ok the lpbuildbot branch is merged [12:42] benji: cool [12:59] bac, looking [13:03] bac, I like the simplicity of this change, instead of the retry approach. "self.port = int(hostData.get('port') or 11211)": do you have any knowledge of when the port is explicitly None? If not, no biggie, just curious. I'd be somewhat tempted to remove the docstring fix (lines 8 and 9 of the diff) just to keep the patch to upstream as small as possible, but now that you've included it, keep it. I can't think [13:03] of anything else to say about it. :-) Do you want me to write some of this actually on the MP, or leave it alone? [14:19] * bac is back [14:20] gary_poster: the port problem showed up when i used the --do-linux (sp?) flag. [14:20] bac, ok. doesn't mean much to me out of context. cool, thx [14:37] Why does Curtis hate my inbox? ;) [14:56] gary_poster: did we ever get the testr trunk straightened out? Should I be using a branch someplace instead? [14:57] benji, I am not sure. :-/ [14:57] gary_poster: well, the tests on the testr trunk don't pass for me (don't even start, I get an exception) [14:57] benji, I'd have to compare the released version in precise with the version in the branch. oh ok. [14:58] maybe the dpkg -l info for testr could be compared to...something? [14:58] 0.0.5-1.1 [14:58] maybe Robert tagged a branch, Gary said somewhat unhopefully? [14:59] benji, https://launchpad.net/testrepository/trunk/0.0.5 ? [15:00] I'll try that branch. [15:04] gary_poster: I can't find a branch that corresponds to 0.0.5 [15:05] benji, r135 [15:05] gary_poster: oh, wait: -r tag:0.0.5 [15:06] should be same yeah [15:06] maybe it should be, but bzr: ERROR: No such tag: 0.0.5 [15:06] I'll use r135 [15:06] benji, r139 has this commit message: "* A horrible thinko in the testrepository test suite came to light and has been [15:06] fixed. How the tests ever ran is a mystery. (Robert Collins, #881497)" :-/ [15:07] <_mup_> Bug #881497: Cannot run testr tests < https://launchpad.net/bugs/881497 > [15:07] gary_poster: yeah, I saw that but the trunk still doesn't run [15:07] benji, even on r139? :-( [15:08] benji, try talking to jml [15:08] I think he knows where the bodies are buried on this project [15:08] oh, I think he's probably out today. checking [15:09] gary_poster: yep, r139 (and r135) both fail (when I run ./testr run) with http://paste.ubuntu.com/921908/ [15:09] benji, jml is out today on nat. holiday [15:12] benji, I'm down to randomly flailing on thoughts you've probably already had. * are there any other documented ways of running the tests? * Have you tried with Python 2.6, like on lucid? * have you tried seeing what module Python is complaining about and seeing if it is a quick fix? [15:12] gary_poster: I'm going to take an early lunch and attack this after recharging a bit. [15:12] benji, cool. [15:17] "CI for the project is at http://build.robertcollins.net/job/testrepository-default/." That does not resolve for me [15:18] robertcollins.net does not either [15:20] gary_poster: i've exercised gmb's script and there are some problems. i think he mentioned the output of 'juju status' changed recently but i don't think the copy of charmhelpers is current to handle them [15:20] bac, ok. what do you want to do to resolve? [15:21] gary_poster: i can fix charmhelpers but i wonder if he has already done so but forgot to push [15:22] bac, dunno. is it trivial? [15:22] probably. i'll have a look. [15:34] argh, curtis is bored and is spamming me by doing lots of LP gardening [15:45] me too [16:00] gary_poster: i'm waiting on my slave to come up. i've pinged sean r. about py-memcached but am waiting for him to come on-line. going to eat and pick up my battery [16:00] ok bac, good luck [16:00] TIP: buy from advance auto on-line for in-store pick up and save $20! [16:00] heh, good to know :-) [16:03] OK, I completed my miscellaneous tasks. (Finally was able to test RT 50773! unfortunately the test failed.) I'm blocked by the kanban cards. I'm going to have some lunch myself, and then see what I can do. [17:34] bac and benji, please let me know if I can pair with you. [17:43] gary_poster: ok. i'm still looking at graham's script [17:44] i left it running over lunch but my slave never did come up [17:44] gary_poster: if you're still available, I just got the testr tests passing and could use a partner in crime [17:44] i think now it is an intermittent error bringing up the slave. will try again. [17:46] benji awesome [17:47] benji https://talkgadget.google.com/hangouts/_/extras/canonical.com/goldenhorde ? [17:47] gary_poster: sure [17:47] cool [18:42] gary_poster: i couldn't get an environment to come up using gmb's script, so i ran in debug mode (dry-run) and then tried the commands by hand [18:42] trying to bootstrap i get: [18:42] 2012-04-09 14:34:46,324 INFO Bootstrapping environment 'ec2-testing' (type: ec2)... [18:42] Error Message: The requested instance type's architecture (x86_64) does not match the architecture in the manifest for ami-4bad7422 (i386) [18:42] 2012-04-09 14:34:49,452 ERROR Error Message: The requested instance type's architecture (x86_64) does not match the architecture in the manifest for ami-4bad7422 (i386) [18:42] odd, thing, is the environment file does not specify an image-id [18:43] just default-instance-type: c1.xlarge [18:43] i think that error is getting swallowed and that's why the instance is not starting [18:46] bac hm. the 386 is default. [18:46] if you want 64 you have to specify it [18:46] that's a juju thing, at least as I remember it [18:46] so if i say c1.xlarge i must provide an AMI? [18:47] so the error is not a surprise to my expectations, but gmb thinking it works without an AMI is a surprise [18:47] yeah [18:48] I have [18:48] default-series: precise [18:48] juju-origin: ppa [18:48] default-instance-type: m2.4xlarge [18:48] default-image-id: ami-b5ea34dc [18:48] but if i provide an image-id (AMI) why specify a default-instance-type. an AMI implies default-instance-type, no? [18:48] no [18:48] IIUC [18:48] it specifies 32 vs 64 [18:48] but there are many 64 bit flavors [18:48] er, ok [18:49] does that make sense? Or maybe I'm barking up wrong tree? [18:49] i need to read up on the different instance types [18:50] but i am surprised this script worked for gmb but i cannot get it to do squat [18:50] yeah [18:52] I wonder if he did not commit most recent progress [18:55] that crossed my mind for the script and charmhelpers [18:57] at this point, i think it best that i provide him a summary of my experience and let him see what's going on. i hate to try to solve a bunch of problems he may have already fixed. agree, gary_poster? [19:04] bac, a sad +1 [19:04] :+1( [19:04] heh [19:05] sort of a mustache [19:14] gary_poster: actually, the error i got was b/c the environments had been morphed to c1.xlarge for the slave but i was trying to do a bootstrap [19:14] ah [19:14] ok [19:57] gary_poster: do you have a second to compare what happens with the script vs. by hand? [19:57] bac yeah one sec [19:57] this is what i see when i run the script: http://paste.ubuntu.com/922372/ [19:58] you'll note the slave has no instance-state and the instance-id is not set [19:58] here is the status after starting a master and slave by hand: http://paste.ubuntu.com/922365/ [19:59] the consequence of the first is that wait_for_machines() never returns as the slave instance doesn't come up nicely [20:01] bac, is that consistent? [20:01] it is repeatable, is that what you mean? [20:01] yes [20:02] bac ^ [20:02] yes, it is repeatable [20:06] bac, weird. I had something like that in canonistack today (by hand). it may be a juju timing issue of some sort. I don't have an idea beyond that though. You may want to take it to #juju. I don't think gmb's script is doeing anything too odd there [20:06] doing [20:26] bac: were you able to do a run with my subunit test statistics parsing code? I'm curious as to whether it worked or not. [20:27] benji: i did not [20:27] i never got a run to completion [20:28] if you'll let me know when you get one to that stage, I'd appreciate it [20:29] benji: ok. i don't think it is going to happen today. [20:29] no problem