[01:18] * thumper is losing the will to finish this bit of work [01:19] * thumper takes a look at that critical bug that fwereade suggested [01:46] time to step back and look at the pending reviews... [02:00] wallyworld_, thumper: what are your thoughts on doing `strings.HasSuffix(os.Args[0], ".test")` for changing default behaviour when running tests? [02:00] ?! [02:00] my gut feeling is that it's bad, because it's adding test logic into non-test code [02:00] horrible [02:00] context? [02:00] * thumper school run [02:00] wallyworld_: disabling the finish-bootstrap stuff [02:01] I was thinking we could just disable it always when running tests by doing something hackish like that [02:01] yeah, go to agree with thumper on that one. i hate adding TestFoo() stuff but Go sucks in that it doesn't allow a better way to do it [02:01] TestingFoo() even [02:02] wallyworld_: how would you do it with, say, Python? [02:03] I guess you'd just monkey patch [02:03] yeah [02:03] but that's what I'm doing here... [02:03] but the test code has to be in the production code [02:04] well, we could expose the finishBootstrap var [02:04] the TestingX thing isn't strictly necessary [02:04] we could, and that has been done elsewhere eg var FinishBootstrap = finishBootstrap [02:05] i'd prefer the above [02:05] which above? [02:05] :) [02:05] with a suitable comment, saying "exposed for testing" [02:05] var FinishBootstrap = finishBootstrap [02:05] hmmkay. I didn't do that to cut down on duplication [02:05] what duplication? [02:06] defining a replacement function. I guess I could just put that in another package tho [02:06] maybe i'm missing something [02:07] i'm just suggesting introducing anj exported var [02:07] so the testing stuff can live inside the _test file [02:07] wallyworld_: and then remove the Testing functions, right? [02:07] yes [02:07] wallyworld_: so the contents of those are either duplicated, or moved [02:08] no big deal I suppose [02:08] there's also a pattern where a testing package is introduced [02:08] yeah, I'll probably go with that [02:08] and all the callers over various other packages call the stuff in the testing package [02:08] provider/common/testing or so [02:08] yeah [02:08] still messy compated with python etc al [02:10] not entirely surprising that [02:11] given that go is compiled and strictly typed [02:13] and it doesn't have friends like C++ or access to "private" methods like python [02:15] I never liked friends in C++ [02:15] I didn't like friends in C++ either [02:16] friendship isn't really that useful [02:16] because you have to give it [02:16] and it tightly couples things together [02:16] it would be nice though if you had the ability to say "i know what I'm doing" in go [02:17] anyway... [02:31] axw: For a minute I thought you were using "like" and "friends" in the Facebook sense. My mind may be permanently warped. [02:32] abentley: :) I don't Like my facebook Friends either [03:05] thumper: you added a whole lot of stuff to the CL you just updated [03:05] the local provider rsyslog one [03:05] really? [03:05] * thumper grunts [03:05] I merged trunk [03:06] and lbox shits itself [03:06] ah [03:06] because of the prereq maybe? [03:06] in all honesty there is nothing interesting in that diff, just questions around the interface... [03:06] maybe [03:07] thumper: I mean the other one - but anyway, LGTM [03:07] I didn't realise rsyslog was "Important" [03:07] :) [03:07] should've checked [03:07] even on my vanilla precise box we have /etc/rsyslog.d [03:08] I was trying to do a reverse depends on rsyslog [03:08] but not sure how to drive dpkg [03:09] not sure, but the Priority=Important, so it's in the base system [03:09] axw: ok, so ubuntu-minimal depends on rsyslog [03:09] okey dokey [03:09] although [03:10] technically, we should add it as a depends to juju-local [03:10] apt-cache rdepends pkg-name FWIW [03:11] thumper: thanks for the comment on tagOffset, the 1-indexing was the bit that confused me [03:11] :) [03:11] yeah, who indexes from 1? [03:11] not sure, maybe the same people who say Monday is the first day of the week [03:12] anyway... /me gets back to synchronous bootstrap [06:05] wallyworld_: I've updated the synchronous bootstrap CL. There's now no upper limit on DNS/SSH wait, and it can be cancelled with SIGINT. Also added the output as you suggested, and better progress reporting [06:06] haven't tested against the other providers yet [06:09] axw_: ok, looking, thanks [06:25] axw_: you were going to introduce a testing package for those test helpers? [06:25] doh [06:25] I was [06:27] wallyworld_: I'll update again later with that [06:27] yeah, i'm not going ti blokc on that [06:48] * wallyworld_ -> walk the dog [07:21] axw__, wallyworld_, TheMue: mornin' all [07:22] morning rogpeppe [07:22] wallyworld_: thanks for the review [07:26] rogpeppe: np. nice to see that add machine stuff get some lovin' [07:27] wallyworld_: glad you're ok with it [07:27] why wouldn't i be? :-) [07:27] wallyworld_: it took me a full day to understand the old code :-) [07:27] i have had a had in it but a lot of the code predated my time :-) [07:27] /had/hand [07:28] wallyworld_: i ended up manually simulating each path through it and writing down the trace [07:28] i sorta just added to it, without refactoring [07:28] i like it that the top level methods reflect each business case [07:28] wallyworld_: you're right about the machine doc duplication BTW - i'm just adding a machineDocForTemplate function [07:28] \o/ thanks :-) [07:29] wallyworld_: i plan on losing AddMachineParams entirely BTW and exporting machineTemplate [07:29] any code that takes a day to understand needs refactoring :-) [07:29] wallyworld_: well, perhaps it was just my small brain... [07:30] that would be good cause that but of duplication will disappear with it [07:30] bit [07:30] i have a small brain too, smaller than most :-) [07:30] wallyworld_: yeah. and the code that digs around in it to work out what the caller is actually trying to do. [07:31] i think the final outcome will be good [07:35] wallyworld_: i hope so. i feel that it should be straightforward to do the next modifications that i need to do. [07:35] i'm always up for a good refactoring :-) [07:38] wallyworld_: BTW the logger.Info lines about transaction hooks will only ever happen in tests - transaction hooks are explicitly only there for testing [07:38] ah ok [07:39] maybe a comment in the code so the reader knowns the hooks are only run in tests? [07:39] just as an fyi? [07:39] wallyworld_: will do [07:40] thanks :-) [08:00] fwereade, axw__: your reviews of https://codereview.appspot.com/30390043/ would be appreciated too, as it's a significant change [08:00] rogpeppe: ok, will take a look [08:00] axw__: thans [08:00] ks [08:00] rogpeppe, looking [08:01] axw__, I haven't followed up on your CL -- did what I said yesterday make sense? [08:01] fwereade: are you talking about the state changes? [08:02] axw__, yeah, the environment life stuff [08:02] fwereade: yup, makes sense - I checked with frankban about the tag usage [08:02] I sent you an email about it. but yes, they do use it [08:02] axw__, great, thanks [08:02] so I guess we'll have to not validate them for now [08:03] * fwereade tries to keep up to date with mail :/ [08:03] fwereade, rogpeppe: if you're interested, I've got a synchronous bootstrap CL up for review here: https://codereview.appspot.com/30190043/ [08:03] axw__: looking [08:04] wallyworld_ has given it a once over, but this is a non-trivial change, so more eyes the better [08:04] well, a thrice over I think [08:04] :) [08:06] fwereade: with the environment life CL, I still have a question about how we signal state servers to kill themselves [08:06] fwereade: that was the reason for Remove (and EnsureDead before it) [08:09] axw__, off the top of my head: would it make sense to have a path that ties it into the Remove of a manually provisioned machine? current schema might not accommodate that, though [08:09] axw__, might require per-provider provisioned-machine refcounts [08:09] axw__, so forget that for now :( [08:10] fwereade: refcounts for what sorry? [08:10] axw__, the number of manually provisioned machines in existence [08:11] I don't understand how that'd be used here [08:12] axw__, possibly broken down by role -- we can kill the environment (or the manual state servers) once all the manual normal nodes have been killed [08:12] fwereade: ok. I think we're thiinking the same thing, but you want transactional guarantees on mongo? [08:12] axw__, yes [08:13] axw__, they're tedious to work with but they're a lot better than nothing [08:13] fwereade: sure. I was going to put all the logic inside apiserver/client, but you probably gathered that already [08:14] (hence the env Dying -> prevents machine addition) [08:16] axw__, I feel that an env being set to Dying should set things in motion in itself [08:16] axw__, the dying preventing machine addition is necessary regardless, isn't it? [08:16] axw__, assume multiple clients [08:17] axw__, it's a little bit thin, but have you read doc/hacking-state.txt? and the various other lifecycle related docs? [08:18] fwereade: no, but I will now :) [08:19] axw__, I'm afraid the lifecycle stuff has not entirely kept up with reality (I might get around to fixing them in my Copious Free Time) but things haven't diverged that much -- most of them should still be actually true [08:22] fwereade: how strongly do you feel about Machine.doc.TxnRevno, and in particular how important is it that AddMachine do a refresh immediately after creation to pick up an accurate txn-revno? [08:23] fwereade: i've just realised that it's racy, and it seems unnecessary. [08:24] rogpeppe, IIRC it's necessary for the watcher -- but I think I'd be fine with Machine.Watch grabbing a fresh TxnRevno before we start watching [08:25] rogpeppe, Ican't think of any cases where the API server calls Watchon a freshly-added machine [08:25] fwereade: it's not really necessary for the watcher tbh [08:25] rogpeppe, fwiw the point is not that it be accurate, specifically, but that it have a value that corresponds with reality [08:26] fwereade: you'll get an extra event if txn-revno is too low, but otherwise the watchers work fine [08:26] fwereade: and that extra event might happen anyway, if someone's made a change since you last refreshed [08:26] rogpeppe, I recall niemeyer got really irritated when I tried to write watchers that just treated the last-known-revno as -1, so I internalised it as something necessary, but I don't recall the details-- yeah, that had been my initial supposition [08:27] fwereade: i'm thinking that just leaving it as zero when adding a machine should be fine [08:27] rogpeppe, ha! [08:27] rogpeppe, I factored that stuff out anyway [08:27] rogpeppe, have a look around, see if *anyone* uses that field [08:27] rogpeppe, I'd love it if we just dropped it [08:27] fwereade: the machineUnits watcher does [08:28] fwereade: but tbh i don't think it needs to [08:30] fwereade: the only problem is the test that specifically tests that txnrevno is correct after AddMachine (TestAddAndGetEquivalence) [08:31] rogpeppe, I think that really I'd prefer not to have watchers that potentially start with double-events signifying no change [08:32] fwereade: i don't think any extra event will be emitted, but... let me check [08:32] rogpeppe, but equally that txn-revno lookups should probably be secreted away inside the watcher code [08:32] rogpeppe, the TxnRevno fields then become useful only when doing ultra-pedantic txn assertions and can in generalbe dropped [10:19] fwereade: i finally gave in and did it. what do you think of this? https://codereview.appspot.com/30770043 [10:20] rogpeppe, if it's what we were talking about above, I love it already, but I've got to go to laura's school right now :( [10:20] (not emergency but appointment) [10:20] fwereade: it's not quite [10:20] fwereade: but it was prompted by it [10:20] fwereade: it's a DeepEquals checker that treats empty slices == nil slices [10:21] axw_, dimitern, wallyworld_: would appreciate your thoughts too [10:22] rogpeppe, looking [10:22] * wallyworld_ has had several drinks, being friday evening and all [10:22] but in general i don't agree empty == nil [10:23] well, maybe go likes to think they are equal, but that i disagree with [10:23] since nil should be a distinct value with a different semantic meaning to empty [10:24] at least that's the case in all other languages i have used [10:24] and it allows you to distinguish between "i don't know" and "empty" [10:36] fwereade, rogpeppe who would be best to talk to about the juju deploy command - how it works currently and how it might work in the future (I know there are some changes coming at some point) [10:37] wallyworld_: go doesn't think they're equal, but in many cases we do treat them as the same [10:37] rogpeppe, reviewed [10:37] dimitern: thanks [10:38] rogpeppe: that i find an issue with [10:38] since nil is semantically different to empty [10:38] wallyworld_: it's actually only an issue for DeepEquals [10:38] wallyworld_: because otherwise you can't compare slices [10:38] wallyworld_: (except against nil, which we almost never do) [10:39] i think is an unfortunate Go idiom or some such [10:39] usually, nil = "i don't have a value for this thing" [10:39] mattyw: i'm happy to chat about it; fwereade probably has the best bird's eye view of where things might be going [10:39] wallyworld_: luckily in go we don't need to use in-band signalling so much [10:40] rogpeppe, ok - so the way it works now - it actually does a bzr branch locally (more or less) [10:40] wallyworld_: lots of things *can't* be nil (ints, strings, etc) [10:40] rogpeppe: yeah, i'm not sure if that's a cause or a consequence [10:40] in a true oo world everything can be nil [10:40] which sadly go is not [10:41] wallyworld_: i'm glad that we don't have nil everyewhere [10:41] wallyworld_: value types are ace [10:41] mattyw: go on [10:41] * TheMue thinks back of his smalltalk time *sigh* [10:42] rogpeppe, that's right is it - more or less a bzr branch happens on the machine you run juju deploy on? [10:42] mattyw: i'm not sure it does; let me check [10:43] mattyw: no i don't think it does [10:43] mattyw: it pulls a charm bundle from the charm store (if the charm's not local) [10:43] mattyw: the charm bundle is a tgz file [10:44] rogpeppe, ok - and I believe that might be changing so that it happens on the state server instead of locally? [10:44] mattyw: if you do a deploy through the api, that already implements that logic, so nothing is created locally [10:44] mattyw: yes. except for local charms, which must be pushed up to the server [10:46] rogpeppe, ok - that's probably all I need for know - thanks very much - don't leave the country though [10:46] * rogpeppe puts his passport down [10:48] fwereade: standup? [10:58] rogpeppe, when would you have a spare few minutes for a quick hangout? [11:05] mattyw: we're in a hangout right now, but should be done soon [11:07] natefinch, no problem I thought that was the case - just getting my booking in early ;) [11:11] mattyw: i'll just look at a review, have a bowl of cereal and then we'll do that [11:15] rogpeppe, ok - no particular hurry [11:26] anyone around with an azure account who could confirm https://bugs.launchpad.net/juju-core/+bug/1246320 with the juju-core package that's in saucy proposed? (details on how in the bug report) [11:26] <_mup_> Bug #1246320: Azure bootstrap fails: versioning header is not specified

mattyw: you got a hangout location? [11:29] jamespage: I have an azure account, but limited time. I could share my azure creds with you if that's helpful [11:29] natefinch, please [11:29] (its the last bug needing verficiation) [11:33] jamespage: sent [11:49] dimitern: responded to your review. [11:51] rogpeppe, i'm not entirely convinced [11:52] rogpeppe, if we're going to copy/paste stuff from the go source into our codebase, it should be consistent in formatting [11:52] dimitern: if we're copy/pasting something, it should be as identical as possible with the original so that when the original changes there are as few conflicts as possible [11:52] rogpeppe, if otoh we're going to follow possible go source changes and use/patch as needed when it changes, it doesn't belong in juju-core, but in an external package [11:53] dimitern: we've already got one precedent, in thirdparty/pbkdf2 [11:53] dimitern: i don't want to add an external dependency for this [11:53] rogpeppe, which was done before we decided on the current rules of consistency [11:54] dimitern: i don't think that vendored code should be subject to the same rules [11:54] rogpeppe, I don't believe making our code messier is helpful for long-term maintenance [11:54] ;) [11:54] dimitern: it's not really our code [11:54] dimitern: it's their code + minimal patches to make it do what we need [11:54] rogpeppe, then what's wrong with an external dependency? [11:55] dimitern: it seems overkill to make a whole new project just for this. and i don't think it solves anything. [11:55] rogpeppe, call it code.google.com/rog/deepequals or something [11:55] dimitern: i don't see what issue it solves [11:55] rogpeppe, use an existing project then [11:55] rogpeppe, consistency [11:56] rogpeppe, that's what it solves [11:56] dimitern: i don't believe that consistency is an iron rule, particular in this kind of case [11:56] rogpeppe: I agree with dimitern... I think we put way too much under juju-core that should be independent projects [11:56] natefinch, +1 [11:56] rogpeppe, we should be going leaner and more consistent, not the other way around [11:57] rogpeppe: this has nothing to do with juju specifically. It just happens to be useful for us. [11:57] dimitern: i'd prefer us to have less dependencies not more [11:57] natefinch: true, but i don't think that's a bad thing [11:57] rogpeppe, complex projects like juju are composed of many dependencies [11:57] rogpeppe, nothing wrong with that, it's a better design, cleaner [11:57] rogpeppe: dependencies shouldn't be a problem. If they are, we should address that, but I don't think they are. [11:57] dimitern: the less dependencies, the less fragile IMO [11:58] rogpeppe, i disagree [11:58] rogpeppe: true for dependencies not controlled by us. But we do control this one. [11:58] dimitern: it's a fundamental truth [11:58] dimitern: even if we do control the dependency, it's one more entity to manage [11:59] rogpeppe, smaller, better organized chunks that are internally consistent and do best one or a few things is better than a monolithic whole [11:59] rogpeppe, what's wrong with managing more? [11:59] dimitern: it's not monolithic - we're organised into independent package within juju-core. i really don't see the problem here. [11:59] dimitern: more work to do [12:00] natefinch, thanks [12:00] rogpeppe, we're coming the the old discussion of "why having a huge package like state with no internal substructure is worse than smaller, well-defined packages" [12:00] rogpeppe, less is more in this case [12:01] dimitern: i think that's a different issue actually [12:02] rogpeppe: for this particular case in question... it's a very well-defined project that does one thing and does it well and is unlikely to see a lot of churn. in this case, the overhead of creating and maintaining a project should be minimal. [12:02] rogpeppe, it's true we were not always following the principle of "what's in juju-core is juju related", but we can improve on that by not making it worse [12:03] natefinch: that's an argument for moving all of testing/checkers into an external package [12:03] natefinch: which might be a reasonable thing to do [12:03] rogpeppe: I was actually just thinking that [12:03] rogpeppe, i'm not arguing just for the sake of it - this specific case is a trivial example, but shows a fundamental design issue with many parts of the codebase, which have not place in the main code base [12:03] rogpeppe, i agree to moving checkers outside [12:04] dimitern: for me, it depends if some other project might want to use those parts [12:04] rogpeppe, it doesn't really matter [12:04] rogpeppe, what matters is to make our life easier by removing reusable chunks like that, not specific to juju, even if noone else uses them [12:04] dimitern: there *is* overhead in maintaining an external project dependency [12:05] dimitern: i don't see how it makes *anything* easier [12:05] rogpeppe, and doing so will make them more likely to be reused, than if there are in juju [12:05] dimitern: perhaps we don't want them to be reused [12:05] rogpeppe, what's the overhead of maintaining a set of reusable, well-defined helpers, like the checkers, which certainly do not change often [12:06] dimitern: because if something is reused by external code, then we're not nearly as free to change if if our requirements change [12:06] dimitern: non-zero [12:06] rogpeppe, we can't stop them from being reused, even now, but it's not obvious [12:06] rogpeppe, not true - we still control the external project [12:06] dimitern: that's true [12:06] rogpeppe: that is an interesting point, about having to worry about external use.... keeping stuff in juju-core means we can hack at it any way we like, since no one in their right mind would link against anything under juju-core [12:07] rogpeppe, by your logic goose should've been part of juju-core [12:07] natefinch: well, i kinda hope that people will in time, but that's a different issue [12:07] rogpeppe, or the gomaasapi - who else uses them? [12:07] dimitern: goose should be useful by other people wanting to use openstack, just like goamz is useful by other people wanting to use aws [12:07] dimitern: same there [12:07] rogpeppe: only for juju-specific stuff. Anything else could break at any time, since it's so deep in our codebase [12:08] rogpeppe, right, and a set of comprehensive checkers, that have nothing to do with juju in particular, also [12:08] rogpeppe: I think this and the checkers are a good example of prime subjects for extraction.... because they're well defined and no going to have their interfaces change [12:08] dimitern: except i don't want us to depend on 100 external projects, each created just because it was possible to factor them out [12:09] rogpeppe, why? [12:09] rogpeppe, that's the main issue of argument [12:09] dimitern: because i don't think it helps anything [12:09] rogpeppe, i don't think we're getting anywhere here [12:10] rogpeppe, ;) [12:10] dimitern: yeah, i guess [12:10] dimitern: I think it's valid to say that there is an expectation of API compatibility in independent projects that we don't have under juju-core. Stuff under juju-core is sort of assumed to be part of a larger project and not intended for independent consumption [12:10] natefinch: +1 [12:10] natefinch: *particularly* for stuff under testing... [12:11] rogpeppe, you're generalizing a specific case where using an external dep is a good thing [12:11] rogpeppe: but that being the case, the checkers and your lax deepequals are still things that probably are fine and good to have as independent packages [12:11] rogpeppe, i'm not saying "let's have 100 deps", i'm saying let's apply some common sense [12:11] dimitern: i haven't seen a single argument as to *why* using more external deps is a Good Thing [12:11] natefinch, exactly [12:12] rogpeppe: it makes us better open source citizens and helps out fellow go programmers, including people from Canonical [12:12] rogpeppe, code describes linked concepts and abstractions, all related [12:12] natefinch: ok, that's a good argument [12:12] dimitern: that's too abstract for me [12:12] rogpeppe, if they're not related, they shouldn't be coupled together [12:13] dimitern: that sounds like a statement of belief, not an actual practical reason [12:13] rogpeppe, would you put a wordprocessor and a database in the same codebase, if they just happen to connect sometimes, but can operate totally independently? [12:13] rogpeppe: definitely we have to be pragmatic. We can't sacrifice our own flexibility... but we're not saying that... just saying, if it's not going to cause much pain and someone else might want to use it, then make it an external project [12:13] dimitern: quite possibly [12:13] rogpeppe, ok, no point to argue further [12:14] rogpeppe, you simply refuse to see my point :) [12:14] dimitern: i see that you strongly believe in that principle [12:14] dimitern: but i believe in pragmatism, not principles [12:16] rogpeppe, yes, i do, because of experience (bad usually) - what happens with large projects with fuzzy boundaries, things that shouldn't be together but historically are kept like that and coupled even further, which makes refactoring difficult [12:16] natefinch: i definitely buy that argument. by that argument, we could easily factor out the checkers, cloudinit, maybe the rpc package and some others too [12:16] dimitern: i'm not sure those historical arguments apply here, as the go package system is strongly boundaried and non-circular [12:17] rogpeppe: seems like the good open source thing to do [12:17] rogpeppe, putting independent things together, just for the sake of convenience, in my experience ever so slightly tends to couple them more and make them less independent [12:17] dimitern: there's nothing about having something in an external project that means that things are easier to refactor [12:17] dimitern: decoupling is good, no question [12:18] dimitern: but whether two packages are in the same project is orthogonal to how coupled they are [12:18] rogpeppe, no it's not - because they can change together and that's a temptation too big to resist to couple them over time [12:19] rogpeppe, anyway, we veered of way off track [12:19] dimitern: goose is way too strongly coupled with the openstack provider [12:19] dimitern: the fact that they're in separate projects doesn't really help in that refard [12:19] regard [12:20] dimitern: conversely the rpc package isn't strongly coupled with any other package outside rpc. we can maintain dependency hygiene inside juju-core too, and we really should. [12:21] rogpeppe, lgtm, just to have it landed, even with these minor inconsistencies [12:21] dimitern: thanks [12:21] * TheMue => lunch [12:21] dimitern: i hope you can see where i'm coming from, even if you might not agree :-) [12:22] rogpeppe, I see, I hope you can see my point as well [12:23] * dimitern gets hungry when arguing like that :) [12:23] * dimitern -> lunch as well [12:23] dimitern: i hear it, but i can't *feel* it in the same way as you... [12:24] dimitern: enjoy! [12:26] rogpeppe, thanks :) [12:53] hmm, this has some test failures i've never seen before: https://code.launchpad.net/~rogpeppe/juju-core/467-checkers-deepequals/+merge/196247 [12:53] ... Panic: Couldn't create temporary directory: mkdir /tmp/gocheck-5074209722772702441: file exists (PC=0x413D01) [12:53] how could that happen?! [12:58] rogpeppe: gocheck is broken [12:59] jam: oh, that's not good [12:59] rogpeppe: it doesn't seed its random number generator [12:59] so after 100 temp directories get created, it "runs out" [12:59] jam: ha ha [12:59] rogpeppe: I'll clean it up, I would say gocheck should be fixed, but it keeps us from leaking *too* many [12:59] jam: is that actually a problem with ioutil.MkTempDir() ? [13:00] rogpeppe: so MkTempDir wouldn't run out after 100 tries like gocheck's internals [13:00] but we would still be leaking dirs (I think) [13:00] rogpeppe: and filling up /tmp with dirs is a good way to slowly kill your machine [13:00] so I haven't "fixed" gocheck [13:01] jam: ioutil.TempDir does seed properly anyway [13:02] jam: could you clean up those tempories please then, before my branch dies again? (perhaps you have, in which case thanks!) [13:03] rogpeppe: i did [13:03] jam: cool [13:03] rogpeppe: ideally we'd figure out why we're leaking dirs, fix that, end then fix gocheck to use ioutil.TempDir [13:03] jam: that would indeed be good [13:05] jam, dimitern, fwereade, TheMue, wallyworld_, mattyw: FYI i'm going to be travelling this afternoon. i'll be working on the train, but probably with only partial internet connectivity [13:06] rogpeppe, cool, enjoy your travels [13:06] i leave in about 2 hours [13:06] rogpeppe: ok, enjoy [13:06] fwereade: did you manage to take a look at https://codereview.appspot.com/30390043/ BTW? [13:07] fwereade: i've also got https://codereview.appspot.com/30900043 which does the txn-revno changes we discussed [13:07] rogpeppe, not enough of it yet [13:07] fwereade: (please ignore the testing/checkers changes in that branch - i don't know why they're there, as i included the other branch as a prereq) [13:07] fwereade: ok, np [13:07] rogpeppe, no worries === gary_poster|away is now known as gary_poster [13:40] rogpeppe, going anywhere nice? [13:40] mattyw: up to edinburhg [13:40] gh [13:40] rogpeppe, that is nice - enjoy [13:40] mattyw: there's a fiddle festival on. lots and lots of trad tunes! [13:41] rogpeppe, excellent! going for the weekend? [13:41] mattyw: aye [13:42] rogpeppe, scotsfiddlefestival.com? [13:42] mattyw: that'll be the one [13:43] rogpeppe, who are you looking forward to seeing most (which ones should listen to) [13:44]