[00:00] http://play.golang.org/p/0jeSRlVe8B [00:00] ^ maybe that makes a little more sense [00:01] thumper: can you show me the hole in the code where this function would fit [00:01] maybe that would help me suggest a better implementation [00:02] davecheney: via the api we want to colocate a service with another on an existing machine. If I create a service with 0 units, and then add a unit with the machine id of an existing machine any chance of it working? [00:03] I cna't test it out via the cli becaus I can't deploy a service with --num-units=0 [00:03] rick_h_: deploy --to [00:03] ^ that is what you are trying to do, right ? [00:03] yea, that's cli, but I need api for the gui [00:03] davecheney: yes, basically [00:03] ok, let me figure out how the cli does it [00:04] but doing it with manual placement [00:04] davecheney: thanks [00:04] davecheney: sorry, we're getting the demo rules changed on us and trying to get back to a working demo [00:04] appreciate the help [00:06] rick_h_: ok, i dont know what that means [00:06] oh yes i dio [00:06] ODS is here isn't it [00:06] davecheney: yep :) [00:07] davecheney: and our demo of lxc container on a running machine isn't happy with openstack running on openstack [00:07] so we're trying to change it on the fly to colocated on bare metal vs in lxc [00:07] err = client.ServiceDeployWithNetworks( [00:07] curl.String(), [00:07] serviceName, [00:07] numUnits, [00:07] string(configYAML), [00:07] c.Constraints, [00:07] c.ToMachineSpec, [00:07] includeNetworks, [00:07] excludeNetworks, [00:07] ) [00:07] this is the api (i guess call), there is a numunits on ther [00:08] ok, so it's coming in with the service [00:08] we need to break the steps up, but will see how we do [00:08] hang on , still checking [00:10] http://paste.ubuntu.com/7455044/ [00:10] thanks looking [00:10] so num units 1 [00:10] tomachinespec <- the machine you want to pin the service to [00:11] yea, we're deploying the service with 0 units and then making individual add unit calls. [00:11] that won't work [00:11] --to is a dirty hack [00:11] its internal name is 'hulk smash' [00:12] ugh [00:12] ok [00:12] so you'll have to deply one unit with --to, then make additional calls to add-unit --to [00:12] yea, that breaks more stuff for us then. thanks for looking [00:13] the reason its like this is --to skips the normal machine selection logic, and just spats the unit on that machine [00:13] that splatting isn't recorded in mongo at all [00:13] understood [01:18] wallyworld_: that issue curtis reported is fixed by the tools CL you just did? [01:19] axw: yes [01:19] cool [01:39] axw: did you have time for a quick standup? [01:39] wallyworld_: sure [02:13] davecheney: around? [02:14] thumper: ack [02:15] davecheney: got time for a hangout? [02:15] thumper: sure [02:15] let me just let the dog in [02:17] davecheney: https://plus.google.com/hangouts/_/g4gj3fe657m4xgcesqioprs6vqa?hl=en [02:18] joining ... [02:29] davecheney: play.golang.org/p/3LV_d5HJb3 [02:36] axw: ping [02:36] waigani: pong [02:37] axw can I pick your brain? hangout? [02:37] sure [02:47] waigani: sorry was a bit hard to hear you, didn't realise you were logging off. cya ;) [02:48] oh whoops, didn't mean to hang up on you :/ [02:48] waigani: nps [02:48] you got everything you needed right? [02:48] yep, all good now, thanks :) [02:48] nps [02:49] I was going to ask how harding was going, but you seem to be in the thick of it [02:50] waigani: just picking off bugs one at a time, not that different from before [02:51] axw: you're looking very productive! Thunderbird keeps popping up with merge proposals from you an wallyworld_ every 5min! [02:52] I don't really feel very productive doing bitsy things, but it's still useful [02:53] getting the test suite to pass reliably is very productive :-) [02:57] wallyworld_: do you really want me to look at the LXC defaults thing, or was that just an idea? I've got a good idea about how to fix #1316272 [02:57] <_mup_> Bug #1316272: juju destroy-environment >=256 nodes fails

[02:58] go for it, it was just an idea [02:58] that maas one is more important [02:59] cool === ppetraki_ is now known as ppetraki [04:00] thumper: gocheck provides a gc.FitsTypeOf checker that takes two objects and tells you if the first one matches the type of the second one [04:08] jam: I don't want the type, but object identity [04:08] thumper: so it isn't "unsafe" to grab a uintptr object [04:08] AIUI [04:08] it is only "unsafe" to cast that back into a type [04:09] jam: however the interface is a tuple of two pointers [04:09] thumper: reflect.Value(obj).Pointer() == reflect.Value(obj2).Pointer() [04:09] jam: doesn't work if the type isn't a pointer [04:09] I don't have the scrollback on this terminal for your non-comparable types [04:09] it panics [04:09] thumper: &obj is still a pointer [04:09] well, would always be a pointer [04:09] no [04:10] no it isn't [04:10] a value type can implement an interface [04:10] and in fact we have an example in juju-core [04:10] sure, but &obj is still a pointer [04:10] where a value type is an error and uncomparable [04:10] thumper: if it is a value type, then they *are not* the same obj.ect. [04:10] object [04:10] jam: but you don't know [04:10] jam: look, I have examples in test code [04:11] which expected behaviour [04:11] if it can be done a different way [04:11] I'm happy, but AFAIK, it cannot [04:16] thumper, so to start with, I'm not sure that comparing errors by identity is actually what we want to be doing, rather than checking if this error is part of this type of errors. [04:16] I realize our code is a bit mixed on this point [04:16] where we have some concrete errors [04:16] and we have other variable ones [04:16] and we get some unhashable/uncomparable ones from various libs [04:16] it isn't helpful to discuss this here without examples [04:16] I've run into it elsewhere in our code where I wanted to put error types into a map [04:17] but it fails to lookup because we get an unhashable error type. [04:17] In that case, we just swallowed the panic [04:17] that was the Serve code, IIRC [04:17] which wants to map known errors into error codes [04:20] thumper: state/apiserver/common/errors.go func singletonCode(err error) (string, bool) [04:20] // All error types may not be hashable; deal with [04:20] // that by catching the panic if we try to look up [04:20] // a non-hashable type. [04:20] thumper: if your error is a value type, then it pretty much *cannot* be the same object as some other object, because as soon as it is passed on the stack, it is a new object. [04:21] as such, you can just say "if this isn't a Pointer() then it isn't the same object" [04:21] and force the equivalence to false in that case. [04:24] jam: play.golang.org/p/dnd98Gl1O4 [04:27] thumper: http://play.golang.org/p/IjRIj8SaWk [04:27] without unboxing the internal implementation [04:28] of interface [04:28] but catching panic is just as horrible [04:28] jam: I'm going to take this to the list anyway [04:28] jam: so we can discuss it there [04:29] personally I wish that golang made this easier for me, but it doesn't [04:29] we will have one icky thing or the other [04:29] both are horrible IMO [04:29] but which is more horrible? [04:29] * thumper shrugs [04:33] thumper: they give different results, too: http://play.golang.org/p/JQ5Ga8k-xd [04:33] since if you have an 'error' it is pointing at a concrete value, so while you can't pass that value around without it changing to a new value, you *can* pass around the error interface to it [04:34] which gives you a new interface at each step, but the underlying object is the same. [04:34] jam: well that is problematic [04:34] thumper: though is the actual error you care about comparing to a value type ? [04:34] it may be [04:34] and that is one horrible bit [04:34] it may be a value type [04:34] and it *may* be uncomparable [04:35] and since it might happen [04:35] we need to handle it [04:35] thumper: well, we do have some control on the system and can say things like "if you want your errors to be compared to be the same, they must be comparable types" [04:36] I'm not sure what the use case is for being able to compare all possible error implementations [04:36] um... because you are writing an error handling library? [04:36] thumper: its still your code [04:36] you can give parameters of what is supported [04:36] not all of it [04:37] ugh [04:37] Value type errors that are uncomparable aren't *nice* errors in go world [04:38] agreed === vladk|offline is now known as vladk [07:01] waigani: ping [07:01] davecheney: pong [07:03] waigani: do you remember the issue that we had before vegas related to juju blowing up on 64k kernels ? [07:03] davecheney: going offline soon [07:03] there was one test package that would always blow up [07:04] waigani: if you don't remember, that is fine [07:04] davecheney: just trying to think ... [07:04] everything stopped working for me before vegas [07:05] yeah sorry, I'll have a look over the issues/emails in the morning and see if I can remember [07:05] waigani: np [07:05] i'll figure it out [07:07] 2014-05-13 07:06:58 INFO juju.worker runner.go:260 start "peergrouper" [07:07] 2014-05-13 07:06:58 DEBUG juju.worker.peergrouper worker.go:421 found new machine "0" [07:07] 2014-05-13 07:06:58 ERROR juju.worker.peergrouper worker.go:137 peergrouper loop terminated: cannot get replica set status: cannot get replica set status: not running with --replSet [07:07] 2014-05-13 07:06:58 ERROR juju.worker runner.go:218 exited "peergrouper": cannot get replica set status: cannot get replica set status: not running with --replSet [07:07] 2014-05-13 07:06:58 INFO juju.worker runner.go:252 restarting "peergrouper" in 3s [07:07] local provider shits itself in a loop [07:17] bugs raised today: 3 [07:17] bugs fixed today: 0 [08:09] if I do [08:10] juju deploy X [08:10] X is resolved by the charm store, yes ? [08:10] is it resolved by the client, or by the api server ? [08:10] (having proxy issues) [08:10] ubuntu@winton-02:~/src/launchpad.net/juju-core$ juju deploy --debug cs:trusty/mysql 2014-05-13 07:54:41 INFO juju.cmd supercommand.go:301 running juju-1.19.3-trusty-ppc64 [gccgo] [08:10] 2014-05-13 07:54:41 DEBUG juju.conn api.go:185 trying cached API connection settings [08:10] 2014-05-13 07:54:41 INFO juju.conn api.go:268 connecting to API addresses: [10.245.67.6:17070] [08:10] 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:198 dialing "wss://10.245.67.6:17070/" [08:10] 2014-05-13 07:54:41 INFO juju.state.api apiclient.go:144 connection established to "wss://10.245.67.6:17070/" [08:10] 2014-05-13 07:56:49 ERROR juju.cmd supercommand.go:304 cannot download charm "cs:trusty/mysql-0": Cannot access the charm store. Are you connected to the internet? Error details: Get https://store.juju.ubuntu.com/charm-info?charms=cs%3Atrusty%2Fmysql-0: dial tcp 91.189.95.67:443: connection timed out === vladk is now known as vladk|offline [08:37] morning all [08:38] morning voidspace [08:39] can someone please review a change to gomaasapi? https://code.launchpad.net/~axwalk/gomaasapi/testservice-nodes-release/+merge/219309 [08:40] (I'm updating the MAAS provider's StopInstances to do bulk release) [08:43] voidspace: ping [08:44] wwitzel3: morning :-) [08:44] axw: morning [08:44] wwitzel3: give me a few minutes and I'll join you in the hangout? [08:45] voidspace: sounds good [08:49] axw, lbox? I really like line-by-line comments :) [08:50] axw, (this is not really a case where it's super-important, 'tis true) [08:53] axw, basically LGTM but a few comments [08:58] jam, axw, voidspace, wwitzel3, et al: I'm approving https://codereview.appspot.com/91390043/ but I'd still appreciate comments === vladk|offline is now known as vladk [09:00] fwereade: sorry, does gomaasapi have lbox set up? [09:01] does not appear to [09:01] axw, good point -- but is it more than a .lbox file in the source tree? [09:01] fwereade: making dinner, will take a look at your doc later [09:01] fwereade: I have no idea [09:05] fwereade: I've come up with a possible problem with just putting Version into another attribute of the request header. [09:06] jam1, oh yes? [09:06] In that old servers will just happily ignore the field and return the wrong thing [09:06] fwereade: it just means we have to be more careful in not allowing the client-side code to accidentally try a new version request [09:07] fwereade: will read [09:07] fwereade: thanks [09:07] fwereade: if we were to re-use the "id" field, then we would have gotten back ErrBadId, and we could have mapped that into "oh, that actually means NotImplemented" [09:07] now we just get "ok" [09:07] jam1, ie only send versioned requests to server that have already stated they support versions? that does sound reasonable to me [09:07] I *think* we're ok, because we detect what the server supports at Login time. [09:09] fwereade: it is just one of those things where we have to be "extra careful" because we can do it wrong and things will still seem to be working, but might be subtly broken. [09:09] Like when we want to change the Set() api so that blank strings are accepted and don't mean "set to default". [09:10] if the client code had a bug that it just always used 2,Set() it would "just work" except when you tried to set to an empty string on an old server and it would set it to the default value. [09:10] fwereade: anyway, I have a model for how the client side code might work, and since we probe for available versions at Login time we should be able to do client side filtering appropriately [09:10] jam1, yeah, I see your point, my personal instinct still slightly leads toward not reusing the field but I'm having a hard time justifying it -- at least a single layer of id-munging to support old clients using watcher ids is much more localised [09:11] Its just one of those "I'd like it to break noisily when we make a mistake" [09:11] fwereade: yeah, I like having it as an explicit Version. I was mostly just bringing up an issue that we should at least be aware of. [09:11] jam1, cheers [09:12] fwereade: I guess partially I was also hoping that I wouldn't have to do as much changes to the RPC package because I had a new field and could do magic there, but it turns out everything was only nice and orderly because of all the other changes I've done along the way. [09:12] like handling Id early rather than late, etc. [09:12] * fwereade cheers [09:23] fwereade: I'm about halfway through your arch overview, and I'm trying to get a feel for how much we need the "here be dragons" side comments vs the "this is how it is laid out". I like letting people know that what we have is not perfect yet, I just wonder if they distract from getting an understanding first. [09:24] IF we had footnotes, I think they'd make excellent footnotes [09:24] jam1, I go back and forth -- "how it is" and "how it should be" *are* separate, but I find that focusing only on the former ends up giving it a misleading air of the latter [09:25] jam1, yeah, footnotes would be the answer, wouldn'tthey [09:25] sidebars, something :) [09:25] fwereade: yeah, I certainly appreciate the "it is this way because it has been this way, and we don't quite understand why the alternatives weren't chosen" [09:25] which seems like something an overview could at least hint at. [09:26] "eponymous" a word I've probably only ever read, I'm not actually sure how it is pronounced :) [09:27] jam, I like that word so I probably shouldn't use it ;) [09:27] jam, I thought I remembered deleting it actually, maybe some part of my brain rebelled and inserted it somewhere else [09:28] fwereade: for example, `Provisioner`, `Upgrader`, and `Uniter`, each used by the eponymous +worker types [09:28] I'm fine with it, fwiw [09:28] I was just reading it over and realized, I know exactly what he means, but I don't actually know how to pronounce that word. [09:29] jam, I can say what I think it should sound like in the standup, but I'm not *certain* that I haven't just made that up [09:29] fwereade: https://www.google.com/search?client=ubuntu&channel=fs&q=eponymous&ie=utf-8&oe=utf-8 has a "pronounce it" button [09:30] jam, well, google agrees with me [09:30] jam, not sure that's enough to pronounce myself "right" but I'll go with it ;) [09:31] fwereade: :) [09:33] fwereade: LGTM with some trivials [09:33] for your arch doc [09:33] https://codereview.appspot.com/91390043/ [09:38] jam, thanks, I'll work those into the next CL [09:39] fwereade: so API versioning again. I like the idea that changing the Version argument can change the type of the thing being returned, but changing the Id should *not* be allowed to do so. [09:39] However, with us just registering a "give me an object" function [09:40] we can't quite tell the type without actually getting a concrete one. [09:40] the existing code used static introspection of functions to do some of this [09:40] what I'd *like* is to be able to have [09:41] instead of Register(func(State, Resources, Authorizer) (interface{}, error)) [09:41] instead have [09:41] Register(func(State, Resources, Authorizer) (FixedType, error)) [09:41] but I'm not sure if you can actually get away with that. [09:42] just because you need to be able to cast the function pointer you get to *something* to be able to call it (I think) [09:42] jam1, fwereade: you guys have time to chat about rsyslog API stuff real quick? voidspace and I are in a hangout [09:42] wwitzel3, sure [09:42] wwitzel3: can you link the hangout? [09:43] https://plus.google.com/hangouts/_/canonical.com/moonstone [10:39] jam1, sorry, don't wait for me re standup [10:39] fwereade: np [10:39] jam1, just 1 main thing: you have work items, but do you also have people writing proto-docs and handing over to evilnickveitch? [10:40] fwereade: I believe the intent is to have Frank focus on some of that as he comes over to core [10:40] or you're talking more about proto-docs before implementation of current feature? [10:41] fwereade: for what I'm working on, I still haven't actually gotten enough implementation to know how its going to hang together, but when I get a bit further I would be happy to write how to use API versioning doc [11:02] jam1: as you suspected, bringing up new state servers doesn't rewrite the rsyslog conf on units [11:03] jam1: so we *definitely* need the additional notification [11:03] voidspace: so my guess is, that if you then bounce unit-wordpress-0 it will rewrite syslog.conf because it will read the new addresses from agent.conf [11:03] but I think we want to do it right away [11:03] right [11:03] we're working on doing it the right way [11:04] voidspace: I think ideally we would be writing rsyslog data from information we get directly from the API server, rather than punning the apiaddresses data [11:04] agent.conf (pie-in-the-sky) would be only enough information to get your real truth from the API server. [11:09] jam: we're going to add an RsyslogHostPorts endpoint (or similar) that effectively (currently) wraps APIHostPorts [11:09] I think :-) [11:09] jam: is there a way to merge an MP to trunk via LP? [11:09] voidspace: so thats good, we just need to change the ports as the data goes through. [11:09] right [11:09] jam: or do I need to branch/merge/push [11:09] axw: what trunk? [11:09] we'll currently just add the global port to each address [11:09] jam: gomaasapi [11:10] but that's easy to then change if we *actually* have different ports [11:10] axw: branch and push [11:10] ok, ta [11:10] axw: gwacl is controlled by our bot, but gomaas is manual [11:10] IIRC [11:10] yep, seems so. thanks [12:08] voidspace: https://code.launchpad.net/~wwitzel3/juju-core/009-ha-rsyslog-api [12:34] could someone please tal https://codereview.appspot.com/92320043/ ? [12:35] and yes, that is awk that I am using, I am from the past [12:43] perrito666: looking [12:44] natefinch: turns out it was a bit less trivial than originally thought :p [12:45] perrito666: heh, I never thought it would be trivial ;) [12:45] I am an optimistic guy [12:45] sleep 60 ... well that inspires confidence [12:45] (not a judgement of the programmer) [12:47] mm, did I push that? [12:47] it's there, yeah [12:47] tx god for restores, bugs in bash in go are a pain to spot [12:48] s/restores/reviews [12:48] honestly, the problem is that we're just passing huge strings to bash. That's not really the way we should be running terminal commands [12:49] the single { for mongo and the double {{ for go templates is particularly gnarly [12:50] natefinch: you should see how that outputs to the shell [12:50] '\"'\"' <-- that is ' [12:50] heh [12:51] reminds me of "\\\\" for a literal \ in a regex [12:52] "http:\\\\\\\\" [12:52] perrito666: I'm ~ sure that you can change the agent.conf on machine-0 to just read "localhost:17070" and it would be happy [12:54] I can try [12:55] perrito666: that can potentially simplify your logic a lot [12:56] jam: true [12:57] perrito666: also, is it possible to use the values for "state-port" and "api-port" instead of assuming they are 37017 and 17017 respectively? [12:57] If it is hard to do, don't worry too much about it, as I don't think anyone has *actually* run with a non-standard port, but the configuration *is* ther. [12:59] jam: it is not that much effort to add it, I have been avoiding additions beyond necessity because restore is quite fragile and I did not want to make future/present bug hunting even harder [13:02] I wish we could just remove the port configuration, it would make our code significantly simpler. === BradCrittenden is now known as bac [13:24] brb [13:28] jam: how do I figure out what revision a branch is on, say if the code were copied to a github, for example? .bzr/branch/last-revision has a revision number, but the diffs look off [13:29] natefinch: every branch has its own revision numbering but the revision-id is unique. You can do "bzr revno" or "bzr revision-info" to get details [13:29] natefinch: and you can't exactly push a bzr branch to github [13:29] but otherwise you can pass "-d" to revision-info to select a different location [13:29] bzr revision-info -d lp:juju-core [13:30] for example [13:30] bzr revno worked. [13:31] natefinch: sure I just wanted to be clear that having the same revno doesn't mean it has the same contents, because if we are both at 2250 and we both commit, we'll both be at 2251 but have different revision-ids [13:32] the code was copied into git, but I wasan't sure if that would throw off bzr, but it seems the .bzr stuff was left intact [13:32] jam: ahh I see [13:32] natefinch: so if you're using bzr-git, we might be magic enough to map into git and then back into bzr again. [13:33] otherwise you wouldn't be able to do "bzr revno $GITLOCATION" [13:34] I presume revnos are at least unique per branch, right? so trunk 2200 is a definitive revision [13:34] natefinch: it is, but pull/push can change the order of history and 2200 *can* become something different. [13:35] there are ways to enforce it (set append-revisions-only will refuse a push that would change revnos) [13:38] ew.... so, why even bother with revision numbers if they don't mean anything static? [13:40] natefinch: because most of the time (and the tool can help enforce it) they are static within a branch [13:40] and they are *far* more meaningful and understandable than hashes [13:41] if I tell you I changed it at rev 2500 in trunk, you can tell really quickly if your copy of trunk has the change I proposed [13:42] things like trunk branches should always have append_revisions_only set (I believe I did that for juju-core) [13:42] so push can't change the old numbers. [13:44] interesting [13:45] I do like numbers I can understand rather than just giant hashes that have no intrinsic meaning [13:45] mornin fellas [13:45] morning bodie_ [13:48] sinzui: you can try turning on the restore test again [13:48] perrito666, I saw the change and queued the test [13:50] great, not that I dont have faith but Ill be expectant [14:11] guys, I'm feeling somewhat sick, I'm going to go and lie down for a while, probably back later [14:12] ok, get better [14:19] natefinch: you want to assit with this code structuring? [14:20] assist [14:25] wwitzel3: oh yeah, sorry, one second, I'll get back in the hangout [14:47] sinzui: is there a new URL for reports.vapor.ws ? or is it intended to be private [14:48] jam, oh! [14:48] jam, I think abentley put it behind apache in the last 12 hours [14:48] http://reports.vapour.ws/ [14:48] sinzui: ah, just directly not at the random port [14:49] hey, does anyone have the link to the doc from the sprint, it is not showing in my docs as shared with me [14:53] natefinch: well, apparently we where very consistent on not writing details regardin WAL [14:53] :p [14:56] perrito666: https://docs.google.com/a/canonical.com/document/d/1XZN2Wnqlag9je73mGqk-Qs9tx1gvOH0-wxMwrlDrQU4/edit#heading=h.hpeo5xue46ue [14:56] perrito666: if you go to google docs for canonical, it should be in the list of recent documents, which is where I ususally go to find stuff [14:57] ah, recent, didnt think of that [14:57] * perrito666 facepalms [14:58] perrito666: it's ok, it took me like 6 months at canonical to start using recent :) [14:59] the fact that the listing of files for google docs looks like a teenagers windows desktop in the 90s does not help at all :p === jcw4_ is now known as jcw4 [15:24] perrito666, your revision is building now in CI. I hope to see a pass in the next 80 minutes http://juju-ci.vapour.ws:8080/ [15:33] sinzui: oh the suspense [15:37] hey anyone around here was present at the HA talks, most precisely when you talked about WAL? I think I am on track but would love to double check [15:37] sinzui: yay, a dns humanly readable name cool [16:24] perrito666, PASS http://juju-ci.vapour.ws:8080/job/functional-backup-restore-devel/806/console [16:25] \o/ [16:51] hi folks :) [16:56] fwereade: ping [16:56] voidspace, pong [16:56] fwereade: you gave my branch an LGTM today [16:57] voidspace, that was nice of me :) [16:57] fwereade: it turned out I'd missed some of our copy-pasta config tests [16:57] fwereade: haha, it was premature of you ;-) [16:57] but yes, nice [16:57] fwereade: so I've fixed those tests to use the new format, including the ruleset for a single state server [16:57] fwereade: plus a test that if we have multiple state servers that we get entries for both (for the case of two) in the generated template [16:58] voidspace, <3 [16:58] fwereade: essential testing the logic in the template [16:58] fwereade: should I ask for another look at the branch, or as it's *essentially* test fixes should I just reapprove? [16:59] fwereade: should we think about merging the action yaml parsing stuff into our code before dressing it for MR? [17:00] voidspace, the general answer is "use your judgment" -- if you're confident in it, and the approach has been LGTMed, don't feel you *have* to get *everything* rereviewed [17:00] or make those two separate mr's (we'd assumed the previous work was a discard) [17:00] fwereade: it's just fixing tests, and they all pass this time (*coff*) so I'm inclined to just re-approve [17:00] thanks [17:00]