[00:03] thumper: shiteveld won't accept by latest diff for the rsyslog upgrader. can you take a peek in lp and see if you are happy? i made a small tweak and responded to comments [00:20] ok, will look [00:25] wallyworld: for your Replace file thing, why not use Stat to get the existing premission, and only use 0644 if you can't get it? [00:26] thumper: cause we want the new perms to overwite any exisitng ones [00:26] hey, i sent an email to the mailing list but just throwing this here as well, anyone know the latest version of the websocket specification juju api server supports? [00:26] wallyworld: but you aren't letting the user specify the permissions [00:26] you are explicit in 0644 [00:26] which may not be right [00:26] stokachu: I don't sorry [00:27] oh shit, i should have that passed in [00:27] wallyworld: if we want to overwrite perms, allow the caller to pass them in [00:27] :) [00:27] how do i tell which version of the websocket library is used from go.net/websocket? [00:27] that's what my brain was thinking but my fingers didn;t type that [00:27] wallyworld: I get that all the time too [00:28] stokachu: i'm not sure. rogpeppe is the best person to ask [00:28] but he's past EOD now [00:28] ok [00:29] i'll poke him later to make sure he responds [00:29] wallyworld: thanks a bunch [00:29] np [00:50] thumper: fixed [00:50] kk [01:04] axw: no os.Groups though ... [01:04] also easier to mock out in the tests with the command :-) [01:04] thumper: there's Gid? [01:04] but thanks for the pointer [01:04] not on a os.User [01:04] oh [01:04] yes there is [01:04] so there is [01:04] :) [01:05] anyway, not a problem, just wanted to make sure you knew [01:05] cheers [01:05] os.User.Gid is a string and os.Chown needs an int [01:05] lovely library coherency there [01:07] axw: I'm happy with https://code.launchpad.net/~wallyworld/juju-core/rsyslogconf-upgrader-118/+merge/206090, you happy? [01:08] yep, for this iteration [01:08] thumper: yeah I was gonna LGTM [01:08] cool [01:08] FTR, +1 for a sub package for utils [01:09] axw: i reverted to using TempDir cause then the file perms work put nicer - TempFile creates the file with 600 and you need more code to change the perms [01:09] i think that's why it was done that way originally === thumper is now known as thumper-afk [01:09] ok no worries === thumper-afk is now known as thumper [01:46] axw: got a minute? [01:46] bugger [01:46] completely missed the standup [01:47] what a slacker [01:47] oops, and sorry [01:47] f*cking bot [01:47] * wallyworld stabs it to death [01:49] thumper: yes [01:49] what's up? [01:50] axw: was wondering about bootstrapping prcess with maas [01:50] and how the sync bootstrap handles the networking bits in it [01:50] particulary how we currently restart networking [01:50] un moment, gotta refresh memory on maas [01:51] I'm likely to change the "edit /etc/network/interfaces, restart networking" [01:52] to be "ifdown eth0, edit /etc/network/interfaces, ifup br0" [01:52] which I have been told will work, but I need to test it [01:52] these are all different lines in the cloud init scripts section [01:52] wondering how the sync bootstrap handles this... [01:53] wondering idly if this relates to : bug 1233751 [01:53] <_mup_> Bug #1233751: MAAS environment bootstrapped, but not really.

[01:53] thumper: I think cloud-init will run that bit. still trying to get my head around it... [01:54] if that's the case it should work no problems [01:55] thumper: yep, maas's StartInstance does that networking bit, so cloud-init will do the networking change [01:55] so it won't break the ssh connection [01:55] * axw looks at the bug [01:55] how do we handle the bootstrapping? [01:56] axw: doesn't bootstrap call start instance? [01:56] thumper: I suspect that bug is just cos the bootstrap-state file got left behind on failed bootstrap [01:56] yes it does, but there's two parts to synchronous bootstrap [01:56] part 1: run cloud-init with a very basic cloud-config [01:57] for maas, there's an additional bit of modifying networking [01:57] part 2: wait for the machine to come up, ssh in and do the rest [01:57] ok, cool, so the hack networking is all part 1? [01:57] and "do the rest" is provider-independent [01:57] yep [01:57] axw: is the bug then fixed? [01:57] thumper: dunno sorry [01:57] kk, so I'll manually test the ifdown/ifup story locally on my precise maching :) [01:57] machine [01:58] doesn't look related to synchronous bootstrap [01:58] pre-bootstrap setup I think [01:58] ok, but didn't you just fix a bug that deleted the .jenv if the bootstrap fails? [01:58] oh that's a different file [01:58] I'm talking about how we leave a file in cloud storage [01:58] ah... :( [02:09] thumper: actually, I'm not sure now. you may get the same error for existing .jenv [02:09] I would need a NUC or something to test on ;) [02:12] curtis has one IIRC [02:21] bigjools: can I test something on your maas? [02:21] maaaaaybe [02:22] it means I have to go and turn it on [02:31] thumper: it's on, can you get in? I can't remember if my router config still works for you [02:31] um... [02:31] since you're sshing into a network two NATs deep :) [02:31] what was the ip address and port again? [02:31] * bigjools rolls eyes === lazyPower_ is now known as lazyPower [02:43] bigjools: I have auth to go buy some NUCs for maas testing locally [02:43] I just need to get my a into g and get some [02:43] thumper: expensed? [02:43] aye [02:43] suhweet [02:43] how much in NZ? [02:44] not sure [02:44] have to go price some up === mwhudson is now known as zz_mwhudson [04:10] * axw goes offline for a while to run tests without a network [06:10] wallyworld: FYI I have looked at your upgrader CL. It looks good, but I don't think I understand everything well enough to +1 at the moment [06:11] axw: that's ok, it was meant for william to look at anyway :-) [06:11] ok, cool [06:12] thanks for looking though [06:12] nps [06:12] it achieves the same result as a previous version, but with a different approach [06:15] yup, so I see. I understand the idea and see how it works, just not fully aware of how the watcher stuff works for example [06:16] it's a bit involved [07:25] fwereade: no urgency, take 2 - https://codereview.appspot.com/63730043/ [07:26] the main tests i copied across from the other branch and made then pass with the new approach [08:05] wallyworld, nice, thanks [08:05] wallyworld, hey, I was wondering [08:05] wallyworld, using ssl-hostname-verification for metadata-needs-signing seems a little strange to me [08:07] which bit of code? [08:07] i'll look [08:07] wallyworld, err let me hunt again, I came upon something that looked like it was doing that while trying to figure out some of the joyent provider tests last night [08:08] wallyworld, if that doesn't ring a bell I probably just misunderstood it [08:08] i can't recall offhand either [08:09] gotta go for dinner, back later [08:09] wallyworld, ah it's ok I completely misunderstood it [08:10] o :-) [08:10] ok [08:10] wallyworld, it really is about verifying the hostnames [08:10] wallyworld, enjoy your dinner [08:10] will do [08:41] I've got a trivial intermittent failure if anyone's got a moment: https://codereview.appspot.com/63710044 [08:54] rogpeppe, 479-desired-peer-group appears to be LGTMed from a month ago but still unmerged [08:54] fwereade: oh twats [08:55] fwereade: it's always that problem when you approve something then switch context back to what you were doing, and forget to check that it's actually merged [08:55] mgz, can we land https://codereview.appspot.com/49050044/ ? [08:55] rogpeppe, yeah, I have a couple of those myself :/ [08:56] TheMue, is 058-debug-log-api abandoned in favour of a different approach? [08:57] rogpeppe, also 487-remove-job-managestate [08:58] fwereade: oh, that's worse [08:58] fwereade: bugger [08:58] fwereade: looks like today is the day for bountiful conflicts [08:59] TheMue, I'm rejecting 058 and WIPing 060 [08:59] * fwereade wishes rogpeppe luck [09:03] fwereade: I'm currently testing the 060 live, it is the solution. Only coded testing is missing. But it works for all providers (even local) and with older releases (even here now local). [09:04] fwereade: The 060 contains both, the backend and the cmd changes. [09:05] TheMue, excellent, thanks [09:20] wallyworld: this is from a suggestion i made in a review - i didn't want to badger you about it, but i think it's worth doing: https://codereview.appspot.com/63530048 [09:24] rogpeppe: we prefer interfaces [09:24] wallyworld: why? [09:24] all the usual reasons [09:24] wallyworld: when we've just got a bag of data, there is no reason to use an interface [09:25] wallyworld: it just obfuscates the code for no reason [09:25] fwereade: i'd appreciate your thoughts on this [09:25] i'm tired tonight so may not be in the best frame of mind for a coherent discussion [09:25] wallyworld: i appreciate that interfaces are useful when you might want to mock different behaviour [09:26] wallyworld: but in this case there is no behaviour to mock - the data structure *is* the interface [09:26] now yes [09:26] bit the design is evolving [09:26] but [09:27] the same pattern has been used for agent conf [09:27] wallyworld: if we need extra behaviour, that will be easy enough to retro-fit. let's not overengineer in advance - this is not Java [09:27] huh? [09:27] wallyworld: agent conf does actually have some behaviour behind it [09:27] as will the upgrade stuff most likely [09:28] wallyworld: (it encapsulates the way to read different versions of the file) [09:28] wallyworld: i don't see that - this is a description of the upgrade steps - that's fundamentally data AFAICS. it's also held inside the binary, not in an external file [09:29] it is data for sure. but the design is still evolving [09:30] wallyworld: sure, so evolve the data [09:30] wallyworld: having the extra layer of indirection doesn't help that (actually, it makes it harder) [09:31] wallyworld: "KISS" :-) [09:31] sure. there's arguments either way [09:33] fwereade: can we please go the simpler route to start with? [09:33] fwereade: if you find that interfaces become useful here, i will eat my humble pie [09:34] to me interfaces are simpler because they abstract behaviour and mocks can easily be constrcuted for only some of the methods [09:34] and it's generally just plan good programming practice [09:34] rogpeppe, wallyworld: IMO our reliance on concrete types has fucked the codebase pretty hard [09:34] our use of structs everywhere in juju core kinda sucks [09:34] fwereade: i don't think this case is analagous to that [09:35] rogpeppe, wallyworld: once you turn out to need an interface it's a *massive* hassle to fix the concrete types [09:35] +1 [09:36] fwereade: so do you really think we should never use structs? even when we're just holding bags of data? [09:36] rogpeppe, I want enough seams in the codebase to allow for easy testing of small units, without backing everything with real implementations [09:36] bags of data now for some things, but the design is evolving [09:36] +1 [09:37] fwereade: there is no "implementation" here - it's just a description of what to do [09:37] fwereade: the "implementation" is in the Run functions which are already fully mockable [09:37] fwereade: i can't see what use it is to "mock" a function that just returns a description and does nothing more. [09:38] rogpeppe, I'm curious as to what you perceive the benefits of dropping the interface to be [09:38] fwereade: it 60 lines less code. i consider that a good reason in itself. [09:38] s/it/it's/ [09:39] rogpeppe: you are the one who likes lots of code :-) [09:39] rogpeppe, and I'm not so sure that we'll never see behaviour associated with things like Targets [09:39] all those duplicated "contains" functions etc [09:39] rogpeppe, by pickinginterfaces from the get-go we can put extensions to behaviour in the right place when the time comes [09:40] they gie us more flexibility to evolve a design [09:40] give [09:40] fwereade: it is also much more immediately obvious what the code is doing - if i see a field access, i don't have to look at what some arbitrary code might be doing [09:40] rogpeppe, if we don't, then the "simple" approach becomes to tweak the code that uses those types [09:40] rogpeppe, and behaviour gets smeared out [09:40] rogpeppe, and things just get worse and worse [09:41] rogpeppe, because even if we *know* it's the time to switch to interfaces [09:41] rogpeppe, the hassle and cost of doing so is generally overwhelming [09:41] rogpeppe, you don;t have to anyway [09:41] fwereade: i really don't believe that could be the case here - this is limited-scope code [09:41] rogpeppe, the upgrade step knows where it should be applied [09:42] rogpeppe, as a client it's not your responsibility to figure it out, and it's none of your business how it's figured out *anyway* [09:42] fwereade: if we want behaviour on Targets, that's trivial to add. [09:42] rogpeppe, and so it begins [09:42] rogpeppe, just a little bit of coupling can't hurt [09:42] fwereade: it's not coupling [09:43] fwereade: it's evolving the schema [09:43] rogpeppe, and forcing the clients to care about that evolution [09:43] fwereade: what clients? [09:43] fwereade: this is essentially an internal-use data structure only [09:44] rogpeppe, that doesn't mean there aren't clients [09:44] rogpeppe, the code that uses it, and the code that tests it, are the minimum set of clients for just about any construct [09:44] fwereade: so by "client" you mean the package itself? [09:45] rogpeppe, yes [09:45] rogpeppe, programming is *all about* managing interfaces to impose simplicity on complexity [09:46] rogpeppe, package boundaries are way too coarse to be useful [09:46] fwereade: sure, but an "interface" can just as well be a concrete data structure there [09:47] fwereade: i've switched back and forth between interfaces and concrete types many times. i much prefer starting with the simple, and then graduating to the more elaborate when it proves necessary. [09:47] rogpeppe, I do not agree with that approach [09:47] rogpeppe, I gave it a fair shake [09:47] fwereade: if you can't agree that a simple concrete type is appropriate for representing a simple concrete bunch of data, i give up [09:48] rogpeppe, and I'm confident that most of the current complexity of juju is a result of an adherence to flawed notions of simplicity [09:48] rogpeppe, it'd be a different story in python [09:48] rogpeppe, because you can use a descriptor in place of a field when it becomes necessary [09:49] rogpeppe, but with go you *invest* in the struct approach [09:49] rogpeppe, it's an expected value calculation [09:49] fwereade: you really think that most of the complexity of juju is from using structs? [09:50] rogpeppe, most of the bits that really hurt and continue to do so, like jujud, are the way they are because we have no seams by which to pick them apart [09:50] rogpeppe, the state/environ horrors are because we have a state struct [09:50] fwereade: i think most of the pain there is in the tests, not the code [09:51] rogpeppe, the inability to test state quickly and easily are because of all the structs in mgo which makes it completely unmockable [09:51] fwereade: because we had a prior aversion to mocking anything [09:51] fwereade: huh? we could mock mgo easily [09:51] rogpeppe, the awful awful uniter stucture is the same story -- there's nothing *that bad* about it in theory, but in practice you can't isolate any of it and have to take the whol lot as an indivisible unit [09:51] fwereade: well, except that we'd need to mock mongodb semantics [09:52] fwereade: again, i really think that's because of our prior aversion to mocking anything [09:52] rogpeppe, maybe I'm being dense: how would you mock anything without interfaces? [09:52] fwereade: there are various places in the code where we *do* manage to mock pieces of the State to good effect [09:53] fwereade: you don't need to *export* the type as an interface [09:53] fwereade: you just need to define clients in terms of an interface, and then use some trivial bridge code (or nothing) to bridge the gap [09:54] fwereade: it's all about ad-hoc interfaces [09:54] rogpeppe, isn't that what wallyworld is doing? it's just that you consider the clients in this case as to be too trivial to bother with [09:54] * wallyworld apologises - too tired to contribute tonight [09:55] wallyworld, don't worry, not calling you into the conversation :) [09:55] fwereade: if there was any behaviour to mock, i might agree. but there isn't, and i can see no particular prospect of it - it's really a data-driven algorithm [09:56] fwereade: for a static table of data, a static table of data seems like the right representation to me [09:56] rogpeppe, I think what he'd doing is relying on instinct for bits-likely-to-change, and inserting seams where they're likely to be useful [09:56] rogpeppe, apart from the Run bits [09:57] rogpeppe, they're types with data *and* behaviour [09:57] fwereade: tbh what i think what's happening is just use-interfaces-by-rote [09:57] fwereade: the behaviour is independent of the data [09:58] rogpeppe, your refactoring still puts them in the same type; I think that's an indication that it's not *quite* as cut and dried as yu say [09:58] rogpeppe, note: this is not a request for a more extreme refactoring ;p [09:59] fwereade: yes, that type composes both the metadata and some behaviour together [10:00] rogpeppe, did I say the thing about expected value? [10:00] rogpeppe, not sure I did [10:00] fwereade: not sure you did [10:01] rogpeppe, picking an interface has a small cost now and in future; picking a struct has a lower cost now, and a chance of a much higher cost in future [10:01] rogpeppe, the choice comes down to a judgment call [10:01] rogpeppe, people can legitimately disagree [10:01] fwereade: you really think that there's a high cost from moving to use an interface? when there are no external clients? [10:02] fwereade: i have not found that [10:02] fwereade: i like the code to be as understandable as possible [10:02] rogpeppe, yes, I really do [10:03] rogpeppe, IMO/E interfaces are at least as understandable as structs [10:03] fwereade: so you think that changing the code base to use, for example, all the State types as interfaces, would be hard? [10:03] rogpeppe, I'm trying t obe generous in acknowledging that sometimes they're a little cheaper [10:04] fwereade: interfaces are less understandable because it's not obvious what's going to happen when they're called [10:04] rogpeppe, yes, it would be a giant hassle and a massive diff [10:04] rogpeppe, because it's *not the client's business* [10:04] fwereade: it would be a big diff certainly (*state.State -> state.State) but actually it would be easy [10:04] rogpeppe, and all the other types? [10:04] fwereade: in this case we *are* the client! [10:05] fwereade: sure, it wouldn't be a problem [10:05] fwereade: i could do it this afternoon if we wanted [10:05] rogpeppe, there's no use in having a State interface if Machine returns a *Machine, you have to return Machine as well [10:05] fwereade: sure, that's why i said "all the State types" [10:06] fwereade: the only hassle would be maintaining the interface types independently from the struct definitions - the interfaces would be enormous. [10:06] s/struct definitions/method definitions/ [10:06] rogpeppe, right, so you *can't* usefully use an ad-hoc interface because you have to construct an actual *Machine [10:07] fwereade: you can, but it's a bit more work [10:07] fwereade: (the address updater uses that technique for testing) [10:07] rogpeppe, it's an *enormous* amount of work to construct one of those that behaves in a specifically tuned way [10:07] rogpeppe, and even *that* is hamstrung because it depends on concrete mgo types [10:08] rogpeppe, it's *really nice* to be able to test state clients against tuned mocks, rather than building up loads of state every time [10:09] fwereade: honestly, it's not *that* much hassle - here's the relevant code the instancepoller tests: http://paste.ubuntu.com/6930374/fwereade: actually the best value would come not from mocking * [10:09] oops [10:09] fwereade: honestly, it's not *that* much hassle - here's the relevant code the instancepoller tests: http://paste.ubuntu.com/6930374 [10:10] fwereade: actually the best value would come not from mocking *state.State, but the various other types (*Machine &c) [10:11] rogpeppe, multiply that work by N tests for N state clients and it becomes a bit unwieldy [10:11] rogpeppe, it's the same simple-code-repeated-everywhere problem [10:12] rogpeppe, that I'm not sure yu see as an actual problem [10:13] fwereade: so if State was an interface, how would that help matters here? [10:13] fwereade: you'd still need to mock out the actual behaviour [10:13] fwereade: so you'd probably end up with an enormous "one-size-fits-all" state mocker, which would be its own source of considerable complexity [10:14] fwereade: i've thought sometimes that it might be nice just to mock out the mgo interface, and write some in-memory mongodb interpretation code [10:15] fwereade: that would mean that you could base all of the State code in memory, so it would be loads faster [10:15] fwereade: but... you'd still want to be certain that the mock mgo semantics mirrored the actual mongo semantics [10:15] rogpeppe, sure *that* would be nice, but again I don't see how you could actually do that [10:15] rogpeppe, well, actually, *not* necessarily [10:16] fwereade: again, it would be straightforward to do [10:16] rogpeppe, mocking lets you exhaustively test the operation of a client given a range of locally defined behaviours [10:16] rogpeppe, imagining that the only purpose of a mock is to perfectly simulate a real system is to somewhat miss the point [10:17] rogpeppe, what-happens-if-X-bizarre-situation becomes *actually* testable, and cheaply [10:17] fwereade: the problem is that the integration tests don't necessarily test all the behaviours that are being tested in the unit tests [10:18] fwereade: ideally, you'd be able to test against both the mock (for quick tests) and the real thing (for slower but more complete) tests [10:19] rogpeppe, integration tests as tracer bullets, and exhaustively paranoid unit tests with mocks, are O(N) work; exhaustively paranoid integration tests are O(N^layers-used-directly-or-indirecttly) [10:19] is it really right that 1.16.6 added errgo? [10:19] rogpeppe, oh yes, more direct switch of subject [10:19] jamespage: definitely not [10:19] rogpeppe, if we're depending on it can we please put it under github/juju [10:19] rogpeppe, well its in the release tarball... [10:19] * jamespage sighs [10:20] jamespage: i know why [10:20] I'll ping sinzui later [10:20] jamespage: it's because of the way that the tarball is built [10:20] jamespage: it's not actually *used* by juju in 1.16.6 [10:21] jamespage: but the tarball is build by doing "go get .../juju" then updating to the correct revision, then updating the deps [10:21] jamespage: but updating the deps does not remove unused deps [10:21] rogpeppe, oh crap - so it will pull in all trunk deps but not drop ones used in stable [10:21] not used that would be [10:21] jamespage: yes [10:22] that's not helpful [10:22] jamespage: that's my understanding [10:22] rogpeppe, lemme nag sinzui later [10:22] I was going to upload this for SRU but stuff like this will make the SRU team nervous [10:22] jamespage: what's the actual problem with having unused deps? [10:23] fwereade: this'll be thumper's errgo, FWIW [10:23] rogpeppe, sure, the request still stands [10:24] fwereade: ok [10:24] fwereade: you don't think that github.com/errgo/errors is a reasonable path for it? [10:24] fwereade: it would be considerably more likely for 3rd party code to use it there, i think, and that would be a Good Thing [10:27] rogpeppe, I'm not sure that's the case -- and I really don't want to further grow our dependencies on external code [10:28] rogpeppe, it'll be a pretty fundamental dependency [10:28] rogpeppe, and if it's good and stable I don;t think being under an organisation named for a (hopefully) successful and popular open-source package will do it any harm [10:29] fwereade: perhaps so. [10:30] fwereade: i'll probably put it at the above path too, and make sure the two are compatible [10:30] rogpeppe, it remains a distinct package with its own identity but we get to move towards drawing our critical dependencies into a sphere over which we have control [10:30] rogpeppe, that's perfectly fine [10:32] rogpeppe, jamespage: btw, AIUI, we *could* chck out juju, and use deps.tsv to pull in the necessary dependencies on their own, and then not run the risk of pulling in other random unpinned stuff, right? we just don't do that yet [10:32] fwereade: the problem with that is my fault [10:33] rogpeppe, jamespage: but I don't see any reason not to? [10:33] fwereade: which is that godeps doesn't currently have a way to pull deps - it just updates existing deps [10:33] rogpeppe, yeah, I can see that the pulling-deps bit is a hassle [10:33] fwereade: i should just do that - i've just been lazy so far [10:33] rogpeppe, that would be awesome [10:34] rogpeppe, btw can I steal 30s of attention for a review of https://codereview.appspot.com/63710044/ please? [10:34] fwereade: sure [10:35] fwereade: what's the deal with the changes to UniterAPI.getUnit and getService? [10:36] rogpeppe, oh balls [10:36] rogpeppe, wrong base [10:36] rogpeppe, it's https://codereview.appspot.com/57710043/ [10:37] rogpeppe, the reason is that there's no guarantee that we're actually passing unit or service tags there [10:38] fwereade: yeah, i figured that. [10:38] fwereade: it could still use FindEntity and just check the type-assertion result, but the ParseTag approach is cheaper and probably better, yeah [10:48] fwereade: i don't quite understand how that CL restores the ability of the uniter to read removed units [10:48] rogpeppe, getUnit fails if the unit doesn't exist [10:48] rogpeppe, pulling out the service name still works so long as the service is there [10:49] rogpeppe, and it will be so long as the relation using it is [10:49] fwereade: but didn't we just call getUnit to get the RelationUnit ? [10:49] fwereade: that's operated on by checkRemoteUnit [10:50] rogpeppe, the RelationUnitis for LocalUnit [10:51] fwereade: ah ha! [10:51] fwereade: ok, makes sense. [10:53] fwereade: LGTM with a suggestion for a comment [10:54] rogpeppe, SGTM, would you LGTM the other one for form's sake too please? [10:54] fwereade: am looking currentyl [10:54] morning all. Seems like I missed the standup? [10:57] natefinch, er, I didn't spot the standup reminder :/ [10:57] rogpeppe, natefinch: shall we do it quickly then? [10:58] fwereade: i didn't either [10:58] fwereade, natefinch: let's [10:59] mgz: standup? [10:59] mgz: (better late than never...) [11:21] could somebody please give me a little hit at the back of my head! somehow I'm in vi mode and trying to operate my sublime editor with vi commands. *aaaargh* [11:59] anyone see launchpad.net down ? [12:01] rogpeppe: fine for me [12:02] natefinch: ah, it's started working again [12:02] rogpeppe: you're welcome ;) [12:02] natefinch: although it doesn't seem to be registering my branch pushes [12:02] i'm trying to approve this: https://code.launchpad.net/~rogpeppe/juju-core/487-remove-job-managestate/+merge/202916 [12:03] but it keeps insisting that it's on revno 2250, not the latest revno 2252 [12:04] and as expected the bot is saying "There are additional revisions which have not been approved in review" [12:04] how frustrating [12:04] rogpeppe: yeah weird [12:05] natefinch: if you do, "bzr revno -r lp:~rogpeppe/juju-core/487-remove-job-managestate", it prints 2252, right? [12:05] rogpeppe: it prints ??? as the response, which is less than encouraging [12:06] natefinch: ah, that might be just bzr - can you pull the branch? [12:07] rogpeppe: yep, and once that's done it says 2252 [12:08] natefinch: right, thanks [12:08] natefinch: so *something* is up with lp [12:08] mgz: any idea what could cause this? [12:09] cd .. [12:12]