=== wedgwood is now known as wedgwood_away [00:05] jcastro: no it does not [00:05] this is probably a problem [00:05] it is both one of the remaining command line things to do [00:05] and also not super simple as in zk we used to tail a zk key [00:05] which isn't as straight forward in mongo [00:05] two secs [00:05] * davecheney search documents [00:05] on top of that we have a few charms using it [00:06] I can sub to a bug or whatever it is [00:06] jcastro: ahh, is this on the charm side (what we call the hook commands) ? [00:06] davecheney: so it deployed the other charm too [00:06] man, it's visibly faster, that's the first thing I noticed [00:06] you're not talking about debug-log ? [00:06] jcastro: about speed [00:07] http://jujucharms.com/charms/precise/postgresql/hooks/install [00:07] line 40, is what breaks there [00:07] i had a report from the folks who can't be named in this channel [00:07] that the charmers who were charming their things were suffering from 10min round trip times [00:07] can you tell me more about that [00:07] (maybe we should get back on the phone) [00:07] so like, status, etc is much faster [00:07] from hitting enter to getting a prompt [00:07] jcastro: if you pass -v [00:07] you'll see we don't use an ssh tunnel [00:07] which really improved speed [00:08] and reliability [00:08] yeah so that's pretty awesome [00:08] for small envs [00:08] status is great [00:08] i'm concerned about large envs [00:08] which is one place where _not_ having the topology node isn't great [00:08] Can we hop on tomorrow? I'm pushing my EOD++ limits and it's affecting my wife's ability to want to punch me right now. :) [00:08] jcastro: understood [00:08] please raise bugs, we'll take it from there [00:09] jcastro: the line 40 issue is the path to juju-log is hard coded [00:09] raise an issue anyway [00:09] nod [00:09] this is a good case to explain how it is both different, and the same [00:09] if you get my meaning [00:10] jcastro: please _please_ raise this with the charmers tomorrow in the call [00:10] if nobody else, i'm here to traige bugs [00:11] nod [00:11] jcastro: it may be that too many charms use /usr/bin/juju-* for their tools [00:11] and we have to support that as legacy [00:11] I can file and fix those, I'll see how many we have [00:11] or maybe that is just a mistake, and was never actually how you were supposed to interface with charms [00:11] if it's like a handful, nbd [00:11] charm-hooks [00:12] either way, maybe charm-lint can help [00:12] but this is why I want to get with m_3 and abuse his charm testing harness [01:14] anyone seen long delays in mails to juju-dev coming through before? [01:15] wallyworld_: rog complains a lot that he doesn't get the mesasges at all [01:15] have seen some weird shit this morning [01:15] :-( [01:15] ok, thans, not just me then [01:15] i sent a message over an hour ago and nothing received yet [01:21] the is guys say they are moving to a new mailing list server this morning, so that probably explains it [01:21] the mail queues on LP are probably massive [01:22] that thing sends lots of mail [01:22] yeah, you noticed :- [01:22] ) [05:44] jam: g'day, got time for a quick catch up? [05:44] wallyworld_: certainly, mumble, or IRC? [05:44] mumble [05:49] jam: http://169.254.169.254/1.0/meta-data/instance-id [05:50] wallyworld_: http://docs.openstack.org/trunk/openstack-compute/admin/content/metadata-service.html [05:51] http://169.254.169.254/openstack [05:51] http://169.254.169.254/openstack/2012-08-10/meta_data.json [05:51] http://169.254.169.254/openstack/latest/meta_data.json [06:01] curl http://169.254.169.254/openstack/2009-04-04/meta_data.json [06:06] status-error: instance i-000d85a9 for machine 0 not found [06:08] https://pastebin.canonical.com/85724/ [06:24] people still use mumble? [06:54] why not? [06:54] bigjools: why you not like mumble? [06:55] jam: btw, i apt updated today and lsb_release just started working, go figure [06:57] bigjools: it tends to work better with high-latency low-bandwidth situations than G+ [07:06] mumble is far worse every time I use it [07:06] far far worse [07:06] now that g+ has a bandwidth slider, it's very usable with slower links [08:39] fwereade: ping [08:55] mornin' all [09:01] rogpeppe: morning [09:02] rogpeppe: is there a way to get into a mongo shell while some test is running to see what's getting set in the db? [09:03] rogpeppe: maybe pause it for a while, so i can inspect the collection [09:07] dimitern: not AFAIK [09:07] dimitern: there are probably a few ways you could hack it if you wanted to do that [09:08] rogpeppe: hmm... maybe if I put a time.Sleep in the test just after the change and try to connect to the mongo shell? [09:08] dimitern: that's definitely a possibility [09:08] dimitern: you'll probably want to print out the port number that mongo's listening on (or you could get it from the mongo command line args from ps i suppose too) [09:09] rogpeppe: i'll try that [09:15] rogpeppe: I'm trying to write some code that uses a function pointer, and I'd like to assert that it points to what I think it should. [09:15] However, if I do: c.Assert(myPointer, Equals, TheFunc) [09:15] I get "comparing uncomparable type" [09:15] jam: you can't compare function pointers [09:15] jam: (what does it mean to compare closures?) === TheRealMue is now known as TheMue [09:15] rogpeppe: but (a) Why not? and (b) what is the workaround so that you know what you are actually pointing to [09:15] rogpeppe: It is an instance of a function [09:16] which would have a unique value (IMO) [09:16] but regardless, there are *lots* of funcs which are not closures [09:16] jam: originally you could compare func pointers, but the functionality was removed [09:16] jam: because it leaves the implementation free to do different things [09:16] rogpeppe: so, what is a sane way to ensure that "after doing X, my function pointer is pointing at Y" ? [09:17] jam: in particular, if i have: func foo() func() {return func(){}}, does foo() == foo() ? [09:17] jam: you could call it and check it does the expected thing [09:18] rogpeppe: well generally I would say no, but I'm fine with that being implementation defined. [09:18] jam: i think they wanted to avoid implementation-defined equality [09:18] but for "var myFunc func() = goose.Func" I'd like to actually assert what it points to. [09:18] jam: you can actually do it with reflect [09:18] rogpeppe: not allowing comparison of closures (because they are pointers + state) is diff than not being able to inspect this pointer I have. [09:19] rogpeppe: reflect.? [09:19] http://stackoverflow.com/questions/9643205/how-do-i-compare-two-functions-for-pointer-equality-in-the-latest-go-weekly I guess [09:20] jam: comparing reflect.ValueOf(f).Pointer() will probably work [09:21] jam: the representation of function pointers has just changed in tip, BTW [09:21] jam: closures are a lot more efficient now [09:23] jam: https://groups.google.com/forum/#!searchin/golang-dev/plan$20for$20two-word$20funcs/golang-dev/x328N8hiN5k/YSzpv2DxPiIJ [09:25] jam: FWIW i was a bit disappointed we lost function equality, but i can see their point too. [10:06] I have a review of medium complexity about upgrade-charm stuff, which I'd appreciate your comments about https://codereview.appspot.com/7363060/ (my first dealings with state/, although with a lot of help from fwereade - tyvm!) [10:48] fwereade: any chance you could take a look at https://codereview.appspot.com/7390043 ? its prereqs are now merged - i think it should be ready to go. [10:55] rogpeppe, ok, looking now [10:58] * TheMue today has early lunch [11:01] fwereade: ping [11:01] rogpeppe, LGTM [11:01] dimitern, pong [11:02] fwereade: hey, can you take a look at this please? especially the tests for refcounts https://codereview.appspot.com/7363060/ [11:02] dimitern, sure [11:05] fwereade: thanks! [11:08] fwereade: i wouldn't mind a chat about some of the stuff i'm planning for the gui folks, perhaps sometime later this morning? [11:09] rogpeppe, might end up being this afternoon... grab me at 2 if I haven't pinged you before then [11:09] fwereade: k [11:22] dimitern, LGTM with some things to address [11:22] dimitern, I like the refcount tests but I don't like the ServiceSettingsRefCount func itself, I think it can be simpler [11:22] dimitern, tyvm for that [11:30] fwereade: cheers [11:30] fwereade: i'm open to advice how to simplify it :) [11:31] dimitern, I think just treat mgo.ErrNotFound as 0, and pass all other errors through directly [11:31] dimitern, the looping in only necessary when writing, reading should Just Work [11:31] mgz, jam, wallyworld_: i'll be 10m late for the standup [11:32] fwereade: yeah, I did that because it failed for some reason unknown (until I saw the svcName was wrong :)), i'll remove the loop [11:32] dimitern, cool [11:40] fwereade: in the process i learned a lot about mongo's QL and some internals :) [11:42] fwereade: am I right to assume this CL fixes bug 1063621 ? [11:42] <_mup_> Bug #1063621: upgrade-charm should handle config changes

< https://launchpad.net/bugs/1063621 > [11:48] jam, wallyworld_: around yet for standup? [11:51] fwereade: I addressed the issues [11:51] anyone else for a review of https://codereview.appspot.com/7363060/ ? [12:04] mgz: wallyworld_ is at his conference today [12:19] jam: reviewed https://codereview.appspot.com/7406054/ [12:20] dimitern: i'll have a look [12:20] rogpeppe: cheers [13:01] dimitern: just a quick question: why do the settings ref counts need to be in a separate collection from the settings themselves? [13:08] dimitern: reviewed [13:16] rogpeppe: tyvm [13:20] rogpeppe: well, that was fwereade's suggestion [13:20] dimitern: i'm interested in the reasoning behind it (i'm not saying it's wrong, just wondering) [13:20] dimitern, rogpeppe: I'm not sure that it's a good idea to have refcount changes counted as config changes [13:21] rogpeppe: can't recall the exact reasoning, but it was something to do with the settings being used in more places than just for the services [13:21] fwereade: ah, i see [13:21] fwereade: right :) sorry [13:21] dimitern, rogpeppe: also, I don't really love the existing field-stripping magic , and don't really want to do more of it especially when there are multiple settings users but only one case where we need refcounting [13:21] fwereade: mind you, the changes are so rare it probably makes no difference (and we have to deal with the case of a change with nothing actually changed anyway, right?) [13:22] fwereade: where's the field-stripping magic? [13:22] rogpeppe, we certainly do, but I thnk an extra config-changed for every unit in a service adds up to quite a lot of unnecessary churn [13:23] rogpeppe, the _id, txn-revno stuff [13:23] rogpeppe, we unmarshal the doc into a dict and strip out the magic keys [13:24] fwereade: hmm, does this mean we can't have a charm config with a setting called "txn-revno"? [13:25] rogpeppe, I think you are probably right about that [13:25] fwereade: hmm, seems wrong. we should probably prefix all the config map keys [13:26] * fwereade adds another line to his "why I hate Settings" list [13:31] dimitern: might be good to add a comment somewhere explaining the reasoning behind having the refcounts separate from the things they're refcounting [13:31] dimitern: LGTM overall [13:31] rogpeppe: will do, thanks [13:34] rogpeppe: so txn.Op{..., Insert: map[string]interface{}(nil), ...} should be fine you think? [13:34] dimitern: i don't see why not. [13:35] rogpeppe: ok then [13:35] dimitern: if it doesn't work then i'd consider it an mgo bug [13:35] :) indeed [13:36] dimitern: for read only purposes, a nil map is usually considered the same as an empty map [13:36] rogpeppe: even if you access a key inside? [13:36] dimitern: yeah [13:36] dimitern: it just returns the zero value for the key [13:37] rogpeppe: cool! [13:37] dimitern: and you can range over a nil map just fine too [13:37] rogpeppe: yeah, i knew that, just wasn't sure m[k] would [13:39] dimitern: from http://golang.org/ref/spec#Map_types: "A nil map is equivalent to an empty map except that no elements may be added." [13:39] rogpeppe: right! so append and set will fail, other stuff works [13:40] dimitern: no append on maps, but yeah [13:40] rogpeppe: ofc :) multi-tasking.. [13:49] dimitern, rogpeppe: https://codereview.appspot.com/7375059 should be simple, and I've checked it actually works [13:49] fwereade: looking [13:52] rogpeppe: I addressed you suggestions wrt https://codereview.appspot.com/7375059 , so I'm submitting it, unless you want to take one last look? [13:52] dimitern: looking [13:53] dimitern: i presume you meant https://codereview.appspot.com/7363060/ [13:53] rogpeppe: :) oops, yeah - sure [13:55] dimitern: replied (LGTM with one trivial) [13:55] rogpeppe: thanks [13:58] fwereade: btw, am I right to assume my CL fixes bug 1063621 ? [13:58] <_mup_> Bug #1063621: upgrade-charm should handle config changes

< https://launchpad.net/bugs/1063621 > [14:01] dimitern, you, know, I think it does :) nice [14:01] fwereade: cheers :) [14:09] fwereade: reviewed [14:09] fwereade: any chance of a chat? [14:10] rogpeppe, yeah, sgtm [14:11] fwereade: https://plus.google.com/hangouts/_/0b304dec0f851f247e957bc221cae25bb5a5d8e4?authuser=0&hl=en-GB [14:11] rogpeppe, cheers, there in a sec [14:11] fwereade: i'll juju pop downstairs for a sec too [14:14] fwereade: nice one, reviewed [14:21] wait, what does `juju pop downstairs` do? :) [14:23] mgz: pretty cool, eh? that's the new command :D [14:24] it has to have --force as well [14:58] mgz: good question. things are getting quite sad when "just" becomes "juju" === wedgwood_away is now known as wedgwood [15:03] joining meeting, computer just slow... [16:13] fwereade: when you have some time, can you take a look at https://codereview.appspot.com/7363061 [16:14] fwereade: this should cover all the relation compatibility checks and, combined with the previous CL should resolve bug 1032557 (part of the bug was actually fixed with the prev CL I think) [16:14] <_mup_> Bug #1032557: upgrade-charm should handle relation changes

< https://launchpad.net/bugs/1032557 > [16:17] dimitern, sorry, it's a bit trickier than that -- you need to check the endpoints for all relations the service is in, rather than *all* the endpoints that *might* be being used [16:17] fwereade: hmm I wasn't sure Endpoints() includes only active ones [16:17] fwereade: but this is a good start, no? [16:19] dimitern, I'm not 100% sure it's leading in the right direction, let me think a mo [16:19] dimitern, g+ maybe? [16:19] fwereade: ok [16:19] dimitern, https://plus.google.com/hangouts/_/818eb5f2e744d376413650e8413f1865123d1e27?authuser=0&hl=en [17:21] fwereade: oh yes, i've remembered the reason for having the key generation in environs.Bootstrap rather than in the command itself [17:21] rogpeppe, oh yes? [17:22] fwereade: it's because we want people to be able to bootstrap easily even if they're using the juju Go interface rather than the command line [17:23] fwereade: although to be honest, i wouldn't mind an extra step there to generate the certs [17:24] rogpeppe, yeah, I probably wasn't clear -- I didn't think the actual functionality should be in the bootstrap command, just its onvocation [17:25] fwereade: the important thing is that nothing in the environs package *needs* to be able to access the user's home directory. [17:26] rogpeppe, yes, indeed [17:26] fwereade: at least, that was a significant consideration in the current design [17:26] rogpeppe, I agree that assuming access to home is not sensible [17:27] rogpeppe, btw, I submit for your consideration without comment: http://paste.ubuntu.com/5571065/ [17:28] rogpeppe, does that look crazy to you? [17:28] rogpeppe, I'm thinking of Environ.Servers rather than StateInfo [17:28] fwereade: i'll be interested to see the design you end up with. i'm sure it's possible to do better than the current one. [17:28] fwereade: looking [17:28] rogpeppe, it's a matter of figuring out what I can do step by step [17:30] fwereade: i'm not really sure that it's worth separating the port from the addresses [17:30] fwereade: we might want the ability to serve on different ports [17:30] fwereade: and the usual "host:port" syntax works ok [17:31] rogpeppe, hmm... I'm not sure it's worth passing the port around separately, either [17:31] rogpeppe, I wouldn't feel too bad about making an environment pick ports at startup time [17:31] fwereade: so we add Environ.Servers() Servers ? [17:32] rogpeppe, yeah [17:32] fwereade: that sgtm [17:32] rogpeppe, it seems like the clients won;t be bothered -- it'll actually be more convenient to pass in entityName, password, rather than futz with the returned *Infos [17:32] rogpeppe, and it also makes it much more convenient as an input when generating machine config [17:33] fwereade: yeah, i think the Servers idea works well. i like the distinction between entity-less Servers and entity+password Info [17:34] rogpeppe, ok, I'll explore that a little more... I have something on the tip of my brain, iykwim, but the whole thing's not quite there yet [17:34] rogpeppe, but that feels like it'll eliminate some of the accidental complexity that is slowing me donw [17:34] fwereade: i'd stick to the usual APIHosts []string with port numbers as part of the string though. [17:35] rogpeppe, I kinda want the struct to still be meaningful with "localhost" tacked on [17:35] fwereade: i'm not sure i understand. what's wrong with localhost:17007 ? [17:36] fwereade: ah, i see [17:37] rogpeppe, I can pass a Servers, with or without addresses, into some sort of machine-configgy thing, and it will work when setting up (1) a bootstrap state server, add localhost to [], (2) a normal machine, don't add anything, and (3) a state server with others already existing, add localhost to [other,servers] [17:37] fwereade: isn't that up to the thing managing bootstrap - it should know what port it's starting the server on, and therefore be able to attach the right port number to localhost [17:38] fwereade: the machine-configgy thing is responsible for starting the server, right? [17:38] rogpeppe, it's really just about how we pass that information around [17:39] rogpeppe, indeed -- so knowing the ports and not always keeping them bound up inside addresses is kinda convenient [17:40] fwereade: i think there's a significant difference between "these servers are listening on these ports" and "i want to start this server listening on this port" [17:40] fwereade: that's why APIPort is a separate field in agent.Config [17:40] rogpeppe, what's your use case for varying ports within an environ? [17:41] fwereade: i have a vague thought in my head about running a dynamic number of API servers on the same box [17:41] fwereade: particularly when stress testing [17:43] rogpeppe, not quite sure what case that simulates [17:44] rogpeppe, wait a sec... agent.Config? need to check that [17:45] fwereade: i'm not sure either currently. perhaps that particular use case is bogus. it just seems to me that it's trivial to get this generality at this point, and might be hard to get it back later. [17:45] fwereade: sorry, agent.Conf [17:45] fwereade: (not really sure why i chose Conf rather than Config as a name there :-]) [17:45] rogpeppe, hmm... so we squish *all* the fields that *might* be used for an agent into the same file? [17:46] fwereade: yeah. beats having lots of different files. [17:47] rogpeppe, not quite convinced there, but I need to go to the shops [17:47] fwereade: ok [17:48] rogpeppe, have a good night, might be off for a while [17:48] fwereade: you too [17:48] fwereade: i'll be around until about 8pm your time [17:50] fwereade: Any chance of a review on this today: https://codereview.appspot.com/7387054 [17:51] Oh, I guess William is the one leaving [17:51] rogpeppe: ^ [17:52] niemeyer: looking === deryck is now known as deryck[lunch] === bac_ is now known as bac [18:28] niemeyer: ping [18:29] rogpeppe: Yo [18:29] niemeyer: just looking at sortableCounters.Less [18:29] rogpeppe: yep [18:30] niemeyer: i'm not sure i understand your Key logic - can't you just do if ki != kj { return ki < kj } ? [18:30] rogpeppe: []string [18:30] niemeyer: doh! [18:32] niemeyer: the ordering isn't fully done though, istm, if len(kj) > len(ki) [18:32] niemeyer: or don't you care about that? [18:34] rogpeppe: No, you're right.. if there are pending items there it can return [18:34] niemeyer: cool. worth fixing. [18:34] rogpeppe: +1 [18:40] niemeyer: reviewed [18:46] rogpeppe: Thanks! [18:48] rogpeppe: Responded === deryck[lunch] is now known as deryck [20:16] g'night all [20:17] night rogpeppe [20:36] hi mramm [20:37] hi [20:37] mramm: want to get started early? [20:45] sorry was in a meeting [20:45] done now, so we can start a little early [21:22] I /think/ my mongodb has become dirtied. I have a test failure on a clean trunk branch that I'm pretty sure I didn't have before. Is that a reasonable hypothesis? [21:46] any suggestions as to what could be going wrong here: http://paste.ubuntu.com/5571811/ [22:25] benji: Pointer vs. non-pointer? [22:28] * thumper sighs [22:33] benji: that has been fixed in trunk i think [22:33] davecheney, mramm: Question: I'm wanting to merge my branch, but when I run the tests locally (just prior to merging) I get an unrelated test failure in openstack storage, should I fix that separately first, or merge my code in then fix it? [22:41] * thumper sighs more [22:41] I get multiple test failures on trunk in quantal [22:42] does anyone else get them? [22:43] one obvious one is environs/openstack/storage.go where the List interface says the results are in alphabetical order, but the method doesn't sort the results [22:43] and the test fails [22:43] and 9 failures for worker/uniter [22:44] * thumper unmerges trunk so he can continue to work with confidence [22:45] yay! the tests pass on a freshened trunk; one thing that threw me off was that "bzr pull" didn't work without a "from"; I wonder if that is a cobzr thing [22:46] benji: I just pulled trunk, and I get test failures :( [22:47] Anyone up for a quick review? [22:47] https://codereview.appspot.com/7407052 [22:50] niemeyer: let me say how much I hate bool flags to change the functionality [22:50] especially in a public api [22:51] thumper: You feel like it obscures the call? [22:51] it means you see things like: SumCounter(true) or SumCounter(false) and have NFI what it means [22:51] well, with extra strings [22:52] it is something I've been trying to avoid since reading Clean Code [22:52] thumper: Yeah, that's a fair point [22:52] niemeyer: have you read it? [22:52] thumper: It's not what the CL is about, though [22:52] it is a very good book [22:52] no, I can see that [22:52] thumper: I've read a few of the articles there [22:52] thumper: Haven't read it all [22:52] thumper: I should [22:53] but I don't have enough context to know if the change is a good thing or not [22:53] I can say the code looks fine, but can't approve the functionality [22:53] thumper: Cool, you can kind of trust me on the functionality side [22:54] haha [22:54] * thumper trusts no one [22:54] no one I tell you [22:54] thumper: The property on the CL description is sensible is what I mean [22:56] niemeyer: do I read this right, we are creating javascript functions to pass to mgo to do stuff? [22:56] thumper: ATM counting mysql:* includes mysql itself, which means we don't get the count for the user branches only [22:56] thumper: Which isn't very useful [22:57] thumper: short version to get your trunk passing [22:57] rm -rf $GOPATH/src/launchpad.net/goose [22:57] thumper: and makes listing and summing uneven [22:57] go get launchpad.net/goose/... [22:57] again? [22:57] thumper: If fixing that isn't a good idea I'll be surprised at least :) [22:57] goose and whatever openstack expects are out of sync [22:57] thumper: and yes, you read it right.. map reduce is MongoDB is done like that [22:57] probably because your branck contains an older openstack [22:58] davecheney: Hey Dave [22:58] niemeyer: hey mate, long time no talk [22:58] davecheney: Indeed! [22:58] congratulations btw [22:59] davecheney: On? :) [22:59] oh, sorry, never mind [22:59] forget i said anything [22:59] davecheney: Ok, can I keep the congrats at least? ;-D [23:00] always [23:00] never turn down praise [23:00] davecheney: Btw, any chance of a review on https://codereview.appspot.com/7407052/? [23:00] davecheney: LOL [23:00] just smile and look humble :) [23:00] * davecheney looks [23:00] * thumper will beat the secret out of davecheney later [23:01] davecheney: This is just a smoothing out change.. nobody will even care much, I think [23:02] niemeyer: i'll keep my gob shut until it's announced then [23:04] davecheney: even with latest goose, trunk fails 9 tests in worker/uniter [23:04] davecheney: I was talking about the branch.. LOL [23:07] niemeyer: branch LGTM, i'll leave it to you to argue about the bool with thumper [23:07] davecheney: Cool, thank you [23:07] i take the position that it was there before ths CL, so you can argue about it out of context with this change [23:07] davecheney: I agree with him that bools aren't great as an interface [23:07] davecheney: But that's not part of this CL [23:08] fwereade: Heya [23:09] what do you guys mean when you say "CL" [23:09] davecheney: Good idea, I'll add it [23:09] davecheney: I mean, a:b:c [23:10] thumper: Change List.. It's a historical name for the issues in Rietveld that, to be honest, I don't even know where it comes from. [23:10] davecheney: I don't suppose I could get you to pull trunk and see if the tests pass for you could I? [23:10] ah... [23:10] * thumper goes to look for food in the kitchen [23:15] thumper: doing so now [23:17] thumper: i'm moderatly confident that trunk isn't broke [23:17] as my daily build has not broken [23:17] but that still means we need to find the right versions of goose to match environs/openstack in your branch [23:24] well, I pulled trunk of both [23:24] so they should work, right? [23:26] testing now [23:27] hmm, two build failures in worker/uniter/charm [23:28] davecheney: I'll pastebin my errors [23:28] thumper try to up to rev 942 [23:28] jacuse rev 943 [23:32] jacuse? [23:32] http://en.wikipedia.org/wiki/J'accuse [23:34] thumper: got that paste ? [23:35] http://paste.ubuntu.com/5572091/ [23:36] heh [23:36] oops [23:36] hmm, that error may be spurious @ 943 [23:36] http://paste.ubuntu.com/5572096/ [23:37] thumper: i think those are genreal test flakeyness errors [23:38] there are a few similar errors logged on LP [23:38] I get them consistently [23:38] like, every time [23:38]