[00:00]  * fwereade wishes axw was here, I've suddenly thought it would be a really good idea to drop null providers from environments.yaml entirely
[00:01] <fwereade> it's probably time for me to go to bed, if it's actually sane I'll probably remember it in the morning
[00:01] <wallyworld> hopefully you'll wajke up and release will be good :-)
[00:05] <wallyworld> davecheney: any chance of confirming that this works for you? https://pastebin.canonical.com/98846/
[00:25]  * davecheney look
[00:25] <davecheney> ha, and you called my hack gross
[00:25] <davecheney> :)
[00:25] <davecheney> give it a go
[00:25] <davecheney> can't make it any worse
[00:37] <wallyworld> this hack won't change cli though
[00:57] <wallyworld> davecheney: if it works: https://codereview.appspot.com/14592044
[01:21] <marcoceppi_> anyone around?
[01:22] <hazmat> marcoceppi_, whats up?
[01:22] <marcoceppi_> hazmat: any idea of `juju bundle` is going to be used at all in the near future?
[01:22] <marcoceppi_>  s/of/if/
[01:24] <hazmat> marcoceppi_, there's some discussion for bundle v2 @ the sprint
[01:25] <hazmat> marcoceppi_, afaik no use, what were you thinking of?
[01:25] <marcoceppi_> hazmat: okay, I've got plans to land a juju-bundle plugin I might hold off on that name for now
[01:25] <hazmat> marcoceppi_, bundle plugin that would export a bundle?
[01:25] <hazmat> marcoceppi_, there's already one of those in deployer fwiw
[01:26] <marcoceppi_> hazmat: I'm adding bundle support to charm-tools, ie `juju charm create --bundle`, wanted to make `juju bundle create` an alias of charm with --bundle flag
[01:26] <hazmat> marcoceppi_.. hmm.. i think there's likely some confusion there with exporting a bundle
[01:27] <hazmat> marcoceppi_, not sure i understand the value of an empty bundle though
[01:27] <hazmat> its not just a single file but the metadata format that gui is pushing?
[01:27] <hazmat> ie. a dir and icon and export file?
[01:27] <marcoceppi_> hazmat: this would create a directory with a README on how to create bundles from the gui
[01:27] <marcoceppi_> hazmat: gui stuff
[01:27] <marcoceppi_> hazmat: also adding proof support for GUI bundles
[01:28] <marcoceppi_> I feel bundles are too commonly used for too many things
[01:28] <hazmat> marcoceppi_, that's bad because?
[01:28] <marcoceppi_> hazmat: the bundle name, not the deployer config stuff itself :)
[01:29] <hazmat> marcoceppi_, re the dir thing and readme, that sounds like it belongs the in the new gui help system
[01:29] <hazmat> ie i don't generally go to the commandline to seek help on the gui
[01:29] <hazmat> or perhaps in the docs
[01:30] <hazmat> marcoceppi_, fair enough.. i'd love to see them back with their original name.. 'stack'
[01:30] <marcoceppi_> hazmat: good point, I might defer that portion and simply update proof to proof bundles. As for creating, I orininally spec'd that for charm-tools since there was mention of README, icon.svg, and bundle.yaml
[01:30] <hazmat> but sadly too much baggage atm re stack
[01:30] <marcoceppi_> but the icon.svg req was dropped
[01:31] <hazmat> marcoceppi_, yeah... the only place that spec is used is the unpublished/undocumented used internally by charmworld afaik
[01:31] <hazmat> almost every real world bundle is just a yaml/json file
[01:31] <hazmat> argh.. grammar fail late night
[01:31] <marcoceppi_> hazmat: right, up until next week when bundles land in the gui and they expect a readme and bundle file
[01:32] <hazmat> marcoceppi_, ic. hence the proof support
[01:33] <hazmat> marcoceppi_, the create thing sounds like it would be better done as an addition to the doc
[01:33] <marcoceppi_> hazmat: right, proof and promulgation support
[01:33] <hazmat> the gui has some significant issues with its bundle exports last i looked
[01:33] <hazmat> marcoceppi_, the promulgation should just work the same as charms afaicr
[01:33] <marcoceppi_> hazmat: I'm going to defer the create stuff, since both promulgate and proof can determine if it's a charm or bundle automatically
[01:34] <marcoceppi_> hazmat: right, with the exception it's lp:~charmers/charms/bundles/<name>/bundle
[01:34] <marcoceppi_> hazmat: which is easy enough to sort out
[01:34] <hazmat> namely it exported default config as explicitly set config, and some exporting of empty constraints.
[01:34] <hazmat> marcoceppi_, cool
[01:34] <marcoceppi_> hazmat: I'm not aware of any of those issues
[01:35]  * marcoceppi_ just needs to make sure proof and prom work
[01:35] <hazmat> marcoceppi_, try an export in the gui, view the output, notice that all the config options are set
[01:35] <hazmat> even though none where actually changed from the charm default
[01:35] <marcoceppi_> hazmat: will give it a go
[01:38] <hazmat> just filed a bug on it
[01:39] <hazmat> bug 1237739 fwiw
[01:44] <hazmat> the empty constraints thing looks like its solved on comingsoon though not on jujucharms.com
[01:58] <davecheney> juju lucky(~/src/launchpad.net/juju-core) % juju ssh p1/0
[01:58] <davecheney> ERROR unit "p1/0" has no public address
[01:58] <davecheney> getting this quite a lot lately
[01:59] <sinzui> wallyworld, did you say that sync-tools can send tools to a testing location, such as /juju-dist/testing/tools?
[01:59] <wallyworld> sinzui: i think user specified destination can currently only be a local directory
[02:00] <wallyworld> otherwise it uploads to control bucket in the "proper" location
[02:00] <wallyworld> let me quickly check
[02:01] <sinzui> wallyworld, that's all fine. I will use swiftclient to deliver the tools to /juju-dist/testing as I did last week
[02:01] <wallyworld> ok
[02:01] <wallyworld> we can add something to the tool if needed
[02:02] <wallyworld> davecheney: is the logging change any good?
[02:03] <davecheney> wallyworld: try it now
[02:03] <davecheney> wil be a while
[02:04] <davecheney> everything is slow
[02:04] <wallyworld> :-(
[02:12] <axw> sinzui: 1.16.0 isn't cut yet right? fwereade OK'd merging in https://bugs.launchpad.net/juju-core/+bug/1235716 overnight
[02:13] <davecheney> wallyworld: what si the MP for that change ?
[02:13] <sinzui> axw, you can add to it.
[02:13] <davecheney> again
[02:13] <davecheney> sorry
[02:13] <axw> bueno
[02:16] <wallyworld> davecheney: https://code.launchpad.net/%7Ewallyworld/juju-core/default-debug-logging/+merge/190282
[02:18] <davecheney> ta
[02:19] <davecheney> testing now
[02:27] <jpds> Guys, is there any away I can tell juju to just download the precise-amd64 tools AND NOTHING ELSE?
[02:27] <jpds> I'm not deploying saucy-armhf any time soon.
[02:27] <wallyworld> jpds: this is when bootstrapping i assume
[02:27] <jpds> wallyworld: Yes.
[02:28] <wallyworld> the logic to get all series has been around forever. it's not currently possible afaik
[02:28] <wallyworld> how critical is it?
[02:29] <jpds> Not critical, I'm just on a super slow link here and I just need one of the tools.
[02:29] <wallyworld> yeah, understand
[02:30] <wallyworld> you could download just the one and then sync-tools manually
[02:30] <wallyworld> then when you bootstrap, it will find it and not attempt to download anything else
[02:31] <jpds> So, how do I do that?
[02:31] <davecheney> wallyworld: works perfectly
[02:32] <davecheney> thank you for fixing it
[02:32] <wallyworld> davecheney: \o/
[02:32] <wallyworld> jpds: get the tarball, copy it to <someplace>/tools/releases, then run juju sync-tools --source=<someplace>
[02:32] <wallyworld> davecheney: if you can lgtm that would be great
[02:33] <wallyworld> jpds: that will upload that one tarball to your control bucket
[02:33] <wallyworld> which is one of the places bootstrap looks
[02:33] <jpds> https://pastebin.canonical.com/98849/
[02:33] <wallyworld> so it will be found
[02:33] <davecheney> soordered
[02:34] <wallyworld> wow 18kbps
[02:34] <wallyworld> fast, not :-(
[02:35] <wallyworld> sinzui: i am about to land a logging fix for davecheney. is it too late to include that in 1.16?
[02:35] <jpds> wallyworld: It can trail at <1kB/s.
[02:35] <wallyworld> wow
[02:35] <wallyworld> jpds: this should make it so no outside net access is reuired
[02:36] <jpds> Yeah, it'll make my life so much easier.
[02:38] <jpds> Now the customer is complaining that juju needs to download too much stuff from the internet.
[02:38] <wallyworld> only the tools, and this will fix that
[02:38] <wallyworld> jpds: the doco for all this obviously needs to be written
[02:38] <sinzui> wallyworld, no.
[02:38] <wallyworld> we need a "how do i set up my private cloud" faq
[02:39] <jpds> I want to complaing about places in sub-Saharana Africa having a better net connections.
[02:39] <wallyworld> sinzui: i've proposed for trunk. i'll put up a mp for 1.16 and then land
[02:39] <jpds> wallyworld: That would be nice.
[02:40] <jpds> All this stuff is just shoved in my head at the moment.
[02:40] <wallyworld> jpds: as with these things, the code comes first to make ti woek, then the doc follows
[02:40] <wallyworld> we are all scrambling to make the 1.16 cut off
[02:41] <wallyworld> we do know the doc needs to be written
[02:41] <wallyworld> maybe one day we can shove a usb cable in our neck and it will all just flow out
[03:01] <davecheney> all: if I do relation-set in a hook
[03:01] <davecheney> then relation-get in the same hook without commiting the hook
[03:02] <davecheney> will I be able to see the value I just set ?
[03:12] <wallyworld> sinzui: the logging change has merged
[03:23] <sinzui> thank you wallyworld
[03:23] <wallyworld> hopefully everything works ok :-)
[03:23] <wallyworld> dave tested it so should be good
[03:25] <jpds> wallyworld: Is 'juju sync-tools --source=' only in devel?
[03:25] <wallyworld> jpds: it was included before 1.16 branched
[03:25] <wallyworld> what version are you running?
[03:25] <jpds> 1.14.
[03:25] <jpds> stable.
[03:26] <wallyworld> oh. i'm not sure what's in that version. give me a sec to have a look
[03:27] <wallyworld> jpds: actually for 1.14, i'm not sure that using the private storage is even an option :-(
[03:27] <jpds> I have a /home/ubuntu/tools/releases/juju-1.14.1-precise-amd64.tgz
[03:27] <wallyworld> i'll check
[03:30] <wallyworld> jpds: a quick look tells me that --source should work
[03:31] <jpds> $ juju sync-tools -v --source=/home/ubuntu/
[03:31] <jpds> error:: no available tools.
[03:32] <wallyworld> 1.14 may have required the tools just to be under tools not tools/releases
[03:33] <wallyworld> try putting the tarball in /home/ubuntu/tools
[03:33] <wallyworld> the releases location is a simplestreams thing
[03:33] <jpds> There we go.
[03:33] <wallyworld> and 1.14 did not fully support that when it was created
[03:45] <wallyworld> jpds: i have to go to the school - my kid has left his viola at home. do you need to ask anything or is it going ok with the tools uploaded? i'll be back soon anyways
[03:45] <jpds> wallyworld: Yes, it's bootstrapping.
[03:46] <jpds> Thanks!
[03:46] <wallyworld> great!!
[03:46] <wallyworld> np
[06:00] <bradm> davecheney: any ideas on a ETA for the squid charm merges I proposed?  I'm needing to do other work on the charms, and it'd be nice to not have to work around the unmerged code
[07:24] <fwereade> davecheney, yes, you should be able to
[07:51] <rogpeppe> mornin' all
[07:52] <axw> morning rogpeppe
[07:52] <axw> and fwereade
[07:54] <mattyw> fwereade, morning, don't suppose you can elaborate on the meaning of this comment? https://codereview.appspot.com/14389043/diff/9001/cmd/juju/helptool_test.go#newcode37
[07:55] <axw> mattyw: he loves it? :)
[07:55] <fwereade> mattyw, it means "thank you, I sincerely appreciate you fixing this"
[07:55] <fwereade> axw, rogpeppe: heyhey
[07:55] <mattyw> fwereade, axw  ok thanks :)
[08:02] <fwereade> axw, so, I'm sorry about the sudo password thing, I should probably have just approved it straight off... did you get an opportunity to get it in for 1.16? (and... eh, can *you* think of any way to use the values we ought to..? at all?)
[08:02] <axw> fwereade: not a problem - it's merged
[08:02] <axw> fwereade: I haven't come up with any good ideas
[08:03] <axw> fwereade: "any way to use the values we ought to?"
[08:03] <axw> non capisco
[08:03] <fwereade> axw, sorry, to use the command context's stdin/out/err
[08:03] <axw> oh right
[08:04] <axw> fwereade: the only thought I had was to have some central package in juju, akin to "os", that has a pseudo Stdin/Stdout/Stderr
[08:04] <axw> but... not really sure if that's any better than using os :)
[08:04] <fwereade> axw, eh,replacing one global with another ain't so great really
[08:04] <axw> indeed
[08:06] <fwereade> axw, there may be a case to be made for requiring a cmd.Context (OSContext or something maybe?) in a whole bunch more places... eg access to env vars is not usefully restricted, and they're even more global than globals
[08:06] <fwereade> axw, tedious to have to thread that through everywhere though ofc
[08:07] <axw> fwereade: hmm yeah good point on env vars.
[08:08] <axw> fwereade: when is ctx.Stdout ever going to be something other than os.Stdout? only for tests?
[08:08] <fwereade> axw, in jujuc commands it's not
[08:09] <fwereade> axw, they don't create envs/env configs though, so not really very relevant
[08:09] <axw> fwereade: ah yes.
[08:10] <axw> fwereade: not sure if it was quite obvious, but sshstorage's requirement is extra special: stdin must be a tty/pty
[08:10] <axw> for remote sudo
[08:11] <fwereade> axw, ha, yes
[08:11] <axw> and its use of stdout only makes sense if it's interactive
[08:20] <fwereade> axw, rogpeppe, wallyworld: ok, I'm now thinking about the manual-bootstrap default-series problem
[08:20] <wallyworld> i'm not familiar with the issue
[08:21] <axw> wallyworld: https://codereview.appspot.com/14433058/
[08:21] <fwereade> axw, rogpeppe, wallyworld: it fails if default-series doesn't match the actual series of the bootstrap machine
[08:21] <axw> wallyworld, rogpeppe : gist is: null provider's bootstrap machine should dictate what the boostrap tools are
[08:22] <axw> but bootstrap tools are always default-series
[08:22] <fwereade> axw, rogpeppe, wallyworld: and this is because we restrict the possibleTools we pass in by that series, even though there's no real reason to
[08:22] <wallyworld> yeah, i've always had doubts about our approach
[08:22] <fwereade> axw, rogpeppe, wallyworld: and ISTM that this is because we didn't manage to finish getting tools out of that interface entirely
[08:23] <fwereade> axw, rogpeppe, wallyworld: they should never have been there in the first place, but turning it completely inside out was too much work
[08:23] <wallyworld> i sorta kept them in the interface because that's how it was and i didn't want to change too much
[08:24] <fwereade> axw, rogpeppe, wallyworld: yeah, indeed, but I think we're now at the point where we have to push further there
[08:24] <wallyworld> +1 to that
[08:24]  * wallyworld is about to eat dinner, bacl later
[08:24] <fwereade> wallyworld, enjoy
[08:24] <rogpeppe> fwereade: sorry, i'm not quite with you here. what are you proposing to change?
[08:25] <fwereade> rogpeppe, I think we shouldn't be passing possibleTools into bootstrap (or really StartInstance for that matter)
[08:26] <axw> fwereade: one problem I can think of immediately, is how to ensure tools are in storage
[08:26] <fwereade> rogpeppe, does that make approximate sense, independent of the question of how we might get there from here?
[08:26] <axw> that fun bit of code we were looking at yesterday
[08:26] <fwereade> axw, yeah, I think that code is just in the wrong place
[08:27] <rogpeppe> axw: that's a good question
[08:27] <rogpeppe> axw, fwereade: what if StartInstance itself was responsible for ensuring the tools are there?
[08:27] <fwereade> rogpeppe, I'm not 100% sure about StartInstance, but Bootstrap almost certainly should be
[08:28] <axw> this would have to lead to --upload-tools disappearing
[08:29] <rogpeppe> axw: really?
[08:29] <axw> and rely on sync-tools if you want to do those kinds of things
[08:29] <rogpeppe> axw: i'm not sure i see the reasoning there
[08:29] <axw> rogpeppe: what would --upload-tools do if Environ.Bootstrap is responsible for ensuring tools are in storage?
[08:29] <axw> or you have the logic in two places
[08:30] <axw> I suppose
[08:30] <rogpeppe> axw: they can potentially re-use some of the same logic
[08:31] <fwereade> axw, rogpeppe: I think that --upload-tools could probably still work -- putting the tools is conceptually independent of choosing them I think
[08:32] <fwereade> axw, rogpeppe: but the auto-sync logic would need to move inside bootstrap
[08:32] <fwereade> axw, rogpeppe: and I think we'd need to untangle upload from sync tomake that sane
[08:32] <axw> fwereade, rogpeppe: fair enough. you could upload in the command, and do the rest in bootstrap
[08:32] <rogpeppe> fwereade: agreed. that would be a good thing anyway imho
[08:33] <fwereade> rogpeppe, +1000
[08:34] <fwereade> bugger, I need to help cath a bit
[08:34] <axw> and I need to get dinner on
[08:34] <axw> bbs
[08:35] <rogpeppe> it would be nice if StartInstance would be responsible for fetching tools on demand; then we wouldn't need to push all that stuff up front
[08:35] <rogpeppe> however, i'm not sure it's possible, as i don't think there's any way of syncing tools concurrently
[08:46] <jamespage> morning folks! hows 1.16.0 looking?   milestoned bugs list looks great to me
[09:16] <fwereade> jamespage, I have not heard from sinzui since last night, but he said he was doing preliminary tests without the last (logging config) bug -- so I hope that if there had been problems I would have heard
[09:18] <mattyw> fwereade, do you have a moment?
[09:18] <fwereade> mattyw, sure
[09:19] <mattyw> fwereade, thanks. just looking at your comment here https://codereview.appspot.com/14389043/diff/9001/worker/uniter/context.go#newcode69. I like the idea of putting all the args into a stuct, but it would look very similar to the HookConext struct which it builds anyway
[09:20] <mattyw> so I'm wondering if there's much value in taking the args in as a struct?
[09:20] <fwereade> mattyw, ha, yes, it would, wouldn't it
[09:22] <fwereade> mattyw, the value is in documenting the meanings of the params, I guess
[09:22] <fwereade> mattyw, but I'm not sure it's that valuable really
[09:22] <fwereade> mattyw, just one client
[09:23] <fwereade> mattyw, but then it is an exported func
[09:24] <fwereade> mattyw, how about unexporting it? and adding a NewHookContext passthrough in export_test?
[09:24] <fwereade> mattyw, or we could just say "this bit's a bit smelly" and move on
[09:24] <fwereade> mattyw, if the unexport idea doesn't immediately strike you, personally, as a good idea, feelfree to leave it as it is
[09:27] <mattyw> fwereade, I'll let the marinate for a bit, in the meantime I'll propose the changes I've made for the other comments if that's ok?
[09:28] <fwereade> mattyw, sounds great, thanks
[09:31] <axw> someone on #juju having issues with OS X, if anyone has the time/knowledge
[09:32] <axw> he's trying trunk to get past the EC2/VPC bug
[09:37] <teknico> how do I get juju to show more output from hook errors?
[09:42] <fwereade> TheMue, you're probably the man to respond to axw's suggestion
[09:43] <axw> fwereade: I think it's an impasse
[09:43] <axw> he's trying to run 1.17.0
[09:43] <fwereade> teknico, if the env is already running, `juju set-env logging-config="<root>=DEBUG"`
[09:43] <axw> well, trunk
[09:43] <axw> which can't find released tools, so tries and fails to upload
[09:43] <fwereade> axw, hum, yeah, that's need tools built
[09:43] <mattyw> fwereade, whenever you're ready https://codereview.appspot.com/14389043/ thanks
[09:44] <teknico> fwereade: thank you, trying that
[09:48] <TheMue> axw: will contact him
[09:51] <fwereade> mattyw, ha, I just spotted something, I feel dumb now -- micro-review sent
[09:54] <mattyw> fwereade, if I put it in the service doc doesn't that mean it goes into mongo? I thought we were trying to avoid that for the moment?
[09:56] <fwereade> mattyw, the method can still return what we return from the service though, right?
[09:56] <fwereade> mattyw, no need for a field yet
[09:57] <fwereade> mattyw, I'm just thinking of where we put the logic
[10:06] <mattyw> fwereade, do you mean I could just do OwnerTag: svc.GetOwnerTag() in megawatcher.go:134?
[10:06] <mattyw> and then make GetOwnerTag() a method on serviceDoc - until we implement it properly?
[10:06] <fwereade> mattyw, essentially, if you just put that method onto serviceDoc instead of Service
[10:06] <fwereade> mattyw, yeah exactly
[10:07] <fwereade> mattyw, you can even keep it on serviceDoc indefinitely I think
[10:07] <fwereade> mattyw, just call through from Service
[10:07] <mattyw> fwereade, there don't seem to be any other method on serviceDoc, so this would be the first?
[10:08] <fwereade> mattyw, it would -- I'm not sure whether it's better as a method or a freefunc
[10:20] <rogpeppe> fwereade: you've gone...
[10:21] <mramm> https://launchpad.net/juju-core/+milestone/1.17.0
[10:21] <fwereade> rogpeppe, so it seems, I have been having some luck lately with sshuttle, thought it was goodenoughfornow
[10:21] <rogpeppe> fwereade: :-(
[10:22] <mattyw> :b3
[10:22] <mattyw> ^^ that was meant for vim
[10:32] <mattyw> fwereade, sorry me again :), is this basically what you had in mind? http://pastebin.ubuntu.com/6217438/
[10:53] <mattyw> fwereade, you probably missed me asking if I roughly had the right idea here  http://pastebin.ubuntu.com/6217438/
[11:05] <natefinch> TheMue: do you drink coffee?  trying to plan for how much coffee to bring to SF.  I roast my own coffee and don't want to have to live off hotel coffee for a week.
[11:06] <TheMue> natefinch: hey, cool. yes, i like coffee very much. sounds fantastic.
[11:07] <natefinch> TheMue: awesome.   I'll make sure to bring a few different kinds.
[11:07] <TheMue> natefinch: having a coffee gourmet as roomie has been a good decision. :)
[11:10] <natefinch> TheMue: haha yep.  I have like 10 different varieties of beans at home right now., I buy them from here:  http://www.sweetmarias.com/prod.greencoffee.mvc.php
[11:11] <mgz> natefinch: that's slightly unbelievably coffee-snobish :)
[11:11] <natefinch> mgz: it's a hobby.  it helps that buying unroasted beans is 1/2 the price, and they're shelf stable for up to a year
[11:12] <natefinch> :)
[11:12] <mgz> it sounds fun, right up to the point where you have to start travelling with roasting and grinding apparatus :)
[11:13] <natefinch> well, I won't be roasting in SF... it produces a bunch of smoke, I think the hotel would get mad at me... that and the roaster is rather large.
[11:14] <natefinch> I haven't decided what to do about grinding. Ideally you grind immediately before brewing, but my grinder weighs like 8 pounds
[11:15] <natefinch> I may have to suck it up and grind ahead of time like some sort of plebe
[11:40] <TheMue> jam, fwereade: unset is now exposed. a review of https://codereview.appspot.com/14439053 please
[11:41] <TheMue> or anyone else
[11:44] <fwereade> TheMue, LGTM, thanks
[11:44] <jam> fwereade: TheMue: reviewed
[11:45] <jam> TheMue: it would be nice to have 1 more test, but I wouldn't block landing that for 1.16.
[11:47] <TheMue> jam: unset has so few options, had no idea what to test more ;)
[11:47] <jam> TheMue: just 'juju unset --help"
[11:48] <jam> which is the only way *I've* found of reliably asserting you've actually registered the command.
[11:48] <TheMue> jam: sound good, yes, will keep it in mind. just oriented at the set command
[11:52] <TheMue> fwereade: need some help, merging it in trunk is well known to me. but how do i get it in 1.16?
[11:56] <TheMue> jam: or you?
[11:56] <jam> TheMue: "lbox propose -for lp:juju-core/1.16"
[11:56] <jam> but you need to build it from "lp:juju-core/1.16"
[11:56] <jam> and then the same "Mark Approved, set commit message"
[11:57] <TheMue> jam: thx, and shit, built it from trunk
[11:58] <jam> TheMue: so generalyl something like "bzr branch lp:juju-core/1.16 $SOMEWHERE"; bzr switch $SOMEWHERE; bzr merge $EXISTING_BRANCH -c -1, bzr commit -m "Just the cmd_unset change"; lbox propose -for lp:juju-core/1.1.6
[11:58] <jam> the merge might need to be a bigger range
[11:58] <jam> if you have more than one commit
[11:59] <TheMue> jam: no, just one commit
[11:59] <TheMue> jam: will try now, thx
[12:06] <TheMue> jam: don't get it with the switch, where do i have to call it? because from where i've done the branching or inside the branch it doesn't work
[12:06]  * TheMue feels like a bazaar noob
[12:06] <jam> TheMue: use whatever mechanism you usually do to create a new branch, just base it from "lp:juju-core/1.1.6"
[12:06] <jam> `1.16" of course
[12:07] <TheMue> jam: yeah, branch is created
[12:07] <jam> TheMue: so for the merge you can do: bzr merge -c -1 lp:~themue/juju-core/052-expose-unset
[12:08] <jam> you don't have to do the switch, it is just what *I* do to create a new branch and point src/launchpad.net/juju-core to it
[12:08] <TheMue> ic
[12:11] <TheMue> "All changes applied successfully." welcome to the world of branching and merging.
[12:16] <TheMue> jam: so, now proposed. now approving with message.
[12:17] <TheMue> jam: done. and for trunk? simply approve the first one too?
[12:18] <jam> TheMue: so we can do it that way. The way *I*'ve done it on other projects was to just continually merge a stable branch => trunk (so once your patch lands on 1.16, then merge 1.16 => trunk)
[12:18]  * TheMue has to write this down in his work process document
[12:18] <jam> TheMue: but there is a bit of discussion as to whether we are landing on trunk and backporting
[12:18] <jam> or landing on stable and merging up
[12:18] <jam> *I* like the latter, but I was part of developing bzr :)
[12:19] <TheMue> I prefer the simpler way. so if you you got one with one command and another one with two or more I'll take the first one. ;)
[12:20] <jam> TheMue: well what you just did was cherrypick the trunk proposal back to 1.16, so it is obviously more straightforward for *this* patch to just land it on trunk
[12:20] <jam> but going forward
[12:20] <jam> if you know we want a change in the stable branch
[12:21] <jam> it doesn't require thinking about it as much to just commit to something branched from 1.16 and merge it up
[12:21] <jam> TheMue: does that make sense/
[12:21] <jam> ?
[12:21] <TheMue> jam: yes, absolutely
[12:21] <jam> you don't have to think about how to cherrypick which is sometimes confusing to get the right bits
[12:21] <TheMue> jam: so for this time i'll take the simple way but next time i start with the according branch directly. has been my fault.
[12:22] <jam> TheMue: well the team as a whole hasn't done much stable + dev development
[12:22] <jam> in Bazaar, we had 3+ stable branches for various Ubuntu releases
[12:22] <jam> imagine if we were supporting 1.12, 1.14 and 1.16 for 6+ months
[12:22] <jam> being able to land in 1.12
[12:22] <jam> and then just merge into 1.14 and then 1.16
[12:22] <jam> was very nice
[12:23] <TheMue> jam: gna, so multiple switches the whole time every day. fantastic
[12:24] <TheMue> jam: in my former jobs we mostly worked on trunk and only tagged it (no product business, all linear projects)
[12:24] <TheMue> jam: only once in good old cvs times worked on a product which has to be maintained
[12:24] <jam> TheMue: to be fair, that is pretty close to what we're doing in juju-core so far
[12:25] <jam> TheMue: yeah, CVS made it very hard to manage multiple ongoing branches
[12:25] <TheMue> jam: but what will change
[12:26] <TheMue> jam: I'm happy that I now get more and more into git workflows for my private projects
[12:28] <jam> TheMue: yeah, I'm not sure how much we'll actually commit to a "stable" juju. I would hope we commit to a stable *client* for Ubuntu 14.04
[12:28] <jam>  
[12:29] <TheMue> jam: but to be more philosophical, what in the world is stable? ;)
[12:30] <jam> TheMue: committing that you'll make changes that can be rolled out directly to clients that won't accidentally introduce regressions because of introducing new functionality they aren't using
[12:32] <TheMue> jam: that's how it should be
[12:32] <TheMue> jam: btw, thanks, branch has landed in 1.16
[12:34] <jam> sinzui: TheMue's patch for exposing "unset" has landed in 1.16, so you should be good to go
[12:34] <sinzui> !
[12:34] <sinzui> thank you very much jam
[12:35]  * TheMue => lunch (wife just called)
[13:21]  * fwereade needs to look after laura for a while, she's about to get back from school and cath isn't yet; bbl
[13:33] <rogpeppe> a simple review for anyone that wants to take a look - no logic changes, just a bit of type juggling: https://codereview.appspot.com/14529050
[13:33]  * rogpeppe goes for lunch
[13:33] <mgz> looking
[13:49] <natefinch> anyone interested in looking at my new constraint that covers ec2 instance names?cd ../
[13:49] <natefinch> heh oops
[13:50] <natefinch> here's the CR for ^^ https://codereview.appspot.com/14523052
[13:51] <TheMue> *click*
[14:23] <TheMue> natefinch: what is when you're using a type which is not matching the hardware constraints?
[14:24] <natefinch> TheMue: not sure I understand the question. But if you're asking about types other than EC2 instances.... right now we don't support it, and it would be a constraint that can't be fulfilled, like if you asked for a machine with 10T of memory
[14:25] <natefinch> TheMue: we probably should just error out early and tell the user they've specified a constraint that isn't valid... but I wasn't sure if I should special case the type constraint, or if we should write a general constraint validator (since other constraints can also just be plain wrong... like tags that don't exist in MaaS)
[14:26] <natefinch> TheMue: it's also possible to mix type constraints with other constraints to produce an impossible combination.... like asking for an m1.small with 4 CPUs.  We could error out early on that, as well.
[14:34]  * sinzui really must optimise what is uploaded to azure for testing
[14:35] <TheMue> natefinch: that's what I meant. I could use constraints regarding mem and cpu that doesn't match the type
[14:35] <TheMue> natefinch: and I'm not sure what has precedence
[14:36] <TheMue> natefinch: or how it is detected and reported as problem
[14:42] <natefinch> TheMue: right now it is not specifically reported as a problem... what it will do is simply not match any existing instance types, so the procurement will fail
[14:43] <natefinch> TheMue: type is just another attribute, like number of CPU cores.  It just happens to be an attribute that is unique to a single type of EC2 machine.
[14:44] <natefinch> TheMue: so it would be like asking for a machine with 8 CPUs and 32G of RAM, if EC2 didn't have such an instance - it would fail to find any matching instance
[14:44] <TheMue> natefinch: ok, so I can use the type to ease my work but I also can add more constraints with the risk that the command fails
[14:45] <natefinch> TheMue: correct.  For example, root-disk will work just fine with it.  You can ask for a m1.medium with 20G of root-disk, and that'll work.
[14:46] <natefinch> TheMue: I think sanity checking constraints before sending them off to the server is something we should do, but it involves more than just the instance type constraint I just wrote.  It probably should be done as a separate changelist
[14:48] <TheMue> natefinch: ok, thx, got it
[15:09] <rogpeppe> mgz: did you get around to reviewing that CL? https://codereview.appspot.com/14529050
[15:16] <mgz> rogpeppe: sorry, still have that tab open, resuming
[15:16] <rogpeppe> mgz: np
[15:24] <rogpeppe> fwereade, mgz: FYI this is the mechanism i'm implementing to enable filtering of RPC log events: http://paste.ubuntu.com/6218476/
[15:24] <mgz> rogpeppe: lgtm'd
[15:24] <rogpeppe> mgz: ta!
[15:28] <fwereade> natefinch, fwiw axw has a prechecker mechanism that will enable just that
[15:28] <natefinch> fwereade: swet
[15:28] <natefinch> sweet too
[15:29] <fwereade> natefinch, but I *think* that we need some additional complexity around instance-type vs mem/cpu/etc
[15:29] <fwereade> natefinch, in python we had the notion of conflicting constraints
[15:29] <fwereade> natefinch, ie you cannot specify both mem and instance-type together
[15:30] <fwereade> natefinch, and if you have an instance-type env constraint, and a mem service constraint, the mem constraint masks out the instance-type one when you combine them
[15:30] <fwereade> natefinch, but *that* then introduces root-disk confusion
[15:31] <fwereade> natefinch, because openstack instance types do mask them, but ec2 ones don't
[15:32] <sinzui> jamespage, fwereade I am blessing lp:juju-core/1.16 r1969. I will make the tarball
[15:32] <fwereade> sinzui, <3
[15:38] <natefinch> fwereade: I think we need per-provider constraint resolution... because it's entirely possible that constraints could be easily detectable as impossible on EC2 and easily detectable as ok on azure
[15:39] <fwereade> natefinch, we do indeed, but while we're still using one provider per environment it's not too bad
[15:39] <natefinch> sinzui: I just merged a branch to 1.16 btw, after 1969
[15:40] <fwereade> natefinch, as we move towards multi-provider environments, we'll need to disambiguate by provider
[15:40] <sinzui> oh? I don't need to panic
[15:40] <natefinch> sinzui: it's just docs changes, but it would be good to have in 1.16
[15:41] <sinzui> natefinch, okay. I don't see it in lp yet: https://code.launchpad.net/~go-bot/juju-core/1.16
[15:41] <mgz> natefinch: it seems to... what sinzui said
[15:42] <natefinch> mgz, sinzui: I forgot to put in a commit message, should be going now
[15:42] <sinzui> As I need make a last minute change to roll tarballs from non-trunk. I will not worry about r1970 yet
[15:43] <natefinch> fwereade: I just meant, we can't have checks that don't take the provider into consideration, because what works on one might not work on another
[15:43] <natefinch> fwereade: even aside from provider-specific constraints
[15:44] <sinzui> abentley, do you have a few minutes to hangout and talk about bzr reconfigure tricks to makr tarballs without undermining "go get"?
[15:44] <fwereade> natefinch, the checks are delegated to the provider itself
[15:44] <abentley> sinzui: Okay.
[15:45] <fwereade> natefinch, but we're going to have to do a bunch more of that as well, indeed
[15:45] <mgz> sinzui: can't we just undermine go get?
[15:46] <natefinch> fwereade: good, yeah, that's what I was thinking - ask the provider if it thinks the constraints make sense.
[15:47] <sinzui> mgz I have diligently worked to ensure the tarballs and deb cannot be infected by my setup. I really like using "go get" I just realised though that I am not releasing trunk so the wrong branch is gotten. I need lp:juju-core/1.16 to be lp:juju-core
[15:49] <natefinch> sinzui, mgz:  that's the problem with go get.  Very common.  There's a whole google group created to discuss how to fix it: https://groups.google.com/forum/#!forum/go-package-management
[15:49] <natefinch> sinzui: for now, go get won't work to build juju.  maybe someday we'll be able to fix that
[15:50] <natefinch> (well, go get won't work to build juju except at trunk, and assuming all third party packages are ok to be built from trunk/tip/etc)
[16:03] <jamespage> sinzui, great news!
[16:03] <sinzui> natefinch, I see and accept your change. I am retagging 1.16 r 1970 as juju-1.16.0 and remaking the tarball
[16:04] <natefinch> sinzui: awesome
[16:06] <mgz> `bzr pull --overwrite-tags` all
[16:38] <jamespage> sinzui, are there any new binaries we need to be building as part of the packaging?
[16:38] <sinzui> jamespage, no
[16:38] <jamespage> (preparing for upload now)
[16:38] <jamespage> sinzui, marvellous
[16:41] <sinzui> jamespage, for 1.17.0, I will make the unstable recipe's base closer to your packaging branch. It would then be obvious when something has/must change
[16:41] <jamespage> sinzui, you could just use the distro packaging branch for the unstable recipe
[16:41] <jamespage> lp:ubuntu/juju-core
[16:47] <sinzui> yep, that's the one
[16:57] <sinzui> I have just had my best idea today. bootstrap the juju 1.14.1 now while the packages build. no waiting for azure
[17:10] <natefinch> sinzui: 1.16 windows installer - http://ubuntuone.com/1aRNVzEv0VDUS5s9Exh53B
[17:11] <sinzui> thank you natefinch . I think we want to ask IS to sign it. Do you have a place it is normally delivered to?
[17:11] <natefinch> sinzui: to arosales ;)
[17:11] <jamespage> sinzui, uploaded to saucy and backports to stable PPA now in flight
[17:11] <natefinch> sinzui: after that it's all magic and unicorns as far as I know
[17:11] <sinzui> thank you very much jamespage
[17:11] <jamespage> I tested upgrade for maas and openstack provides and bootstrapped and tested with klocal provider as well
[17:11] <jamespage> nice work guys!
[17:12] <natefinch> yay, we didn't break stuff! :)
[17:12] <sinzui> Again thank you jamespage . I don't need to worry about that upgrade test
[17:12] <jamespage> sinzui, the load on my maas server is back under control again - 1.15.1 had it ticking over at 2.0
[17:13] <sinzui> there is still time. I can put all the public tools in the wrong place or corrupt them.
[17:13] <sinzui> ouch
[17:14] <jamespage> sinzui, re armhf in PPA's; we have an issue with golang compilation I'm looking at
[17:14] <sinzui> :(
[17:14] <jamespage> the arm PPA builders run everything under qemu which I think is the issue
[17:14] <jamespage> I can't reproduce locally
[17:19] <natefinch> rogpeppe: you around?
[17:19] <rogpeppe> natefinch: i am
[17:20] <jamespage> sinzui, out for a few hours - everything is building now
[17:20] <natefinch> rogpeppe: I had a bootstrapped environment on windows under 1.14 and now I'm getting  "environment has no bootstrap configuration data"  when I try to use the environment
[17:21] <jamespage> sinzui, even if a juju-core builds on armhf in the stable ppa don't use it - it will be using older golang I think
[17:21] <sinzui> oh, thank you for the warning
[17:21] <rogpeppe> natefinch: try removing the .jenv file for that environment (or moving it to somewhere else, in case it might contain important info)
[17:22] <natefinch> rogpeppe: ahh crap
[17:23] <natefinch> C:\Users\Nate>juju bootstrap
[17:23] <natefinch> ERROR cannot create environment info "amazon": cannot rename new environment info file: rename C:\Users\Nate\AppData\Roaming\Juju\environments\561471723 C:\User
[17:23] <natefinch> s\Nate\AppData\Roaming\Juju\environments\amazon.jenv: Cannot create a file when that file already exists.
[17:23] <rogpeppe> natefinch: you're going to get that error if a Prepare has been done on a legacy environment (the client can't really know any better tbh)
[17:23] <rogpeppe> natefinch: ah frick
[17:23] <natefinch> rogpeppe: I just renamed the old amazon.jenv to something else
[17:23] <natefinch> rogpeppe: so it definitely wasn't there before bootstrap
[17:23] <rogpeppe> natefinch: what are you trying to do with the env?
[17:24] <natefinch> rogpeppe: just testing bootstrap etc
[17:24] <natefinch> rogpeppe: I can try starting from scratch, see if that fixes anything
[17:24] <rogpeppe> natefinch: um, i think i misunderstood your problem
[17:25] <rogpeppe> natefinch: i thought you were trying to reconnect to an already bootstrapped environment
[17:25] <natefinch> rogpeppe: my fault... mispoke
[17:25] <rogpeppe> natefinch: which is when you might come across the problem that my instructions were trying to solve (it would happen if you had an existing environment, but bootstrapped anyway)
[17:26] <rogpeppe> natefinch: i'm a bit concerned by the above error though
[17:26] <rogpeppe> natefinch: what's the accepted way to atomically replace an existing file under windows?
[17:27] <natefinch> rogpeppe:  move /y in the CLI
[17:28] <rogpeppe> natefinch: not very helpful from Go :-)
[17:28] <natefinch> rogpeppe: haven't had to do it in Go.  Let me look
[17:28] <rogpeppe> natefinch: thanks
[17:39] <natefinch> rogpeppe: uh so... Go right now doesn't have a facility to do that.  We'd have to wrap our own windows API call to do it (which is not a big deal).
[17:39] <rogpeppe> natefinch: ah. if we want the client to work on windows, we need to do that, unless there's another possibility
[17:40] <rogpeppe> natefinch: because that's the way .jenv files are written such that the client can work concurrently with issue
[17:40] <rogpeppe> s
[17:40] <natefinch> rogpeppe: that's the only way I can see to replace a file atomically.  There's basically two windows API calls that can do it, and neither of them are currently used in syscall for windows
[17:41] <rogpeppe> natefinch: rats
[17:41] <natefinch> rogpeppe: it's really not a big deal to write it ourselves, it's just kind of annoying
[17:41] <rogpeppe> natefinch: how much work do you think?
[17:43] <rogpeppe> natefinch: (i'd think we'd make a utils/file package containing a ReplaceFile function, or something similar)
[17:46] <arosales> natefinch, thanks for creating the installer
[17:46] <arosales> natefinch, could you open an RT to have it signed>
[17:46] <natefinch> rogpeppe: yeah.. no big deal, like an hour, if that
[17:46] <natefinch> arosales: sure
[17:47] <rogpeppe> natefinch: cool. it would be great if we could get that working, especially as it might rebound on us
[17:47] <arosales> natefinch, thanks may need to reference RT 64638
[17:59] <adam_g> is there an ETA on when 1.16.0 tools will be available ? stable PPA has 1.16.0 but no tools are available for bootstrapping
[18:05] <natefinch> adam_g: there was just some talk about that internally.  The tools should be available shortly, but we realize pushing 1.16 to the ppa before the tools were available was a mistake.
[18:11] <TheMue> good night
[18:11] <natefinch> TheMue: g'night
[18:23]  * sinzui sighs
[18:24] <sinzui> the saucy packages has a different version than I expected.
[18:24]  * sinzui hacks the script
[18:25] <natefinch> sinzui: there's a bug in the windows client that I am fixing, but for now, i can't give the installer to IS to sign, since... it's broken.  Like totally.  Can't bootstrap.
[18:25] <sinzui> natefinch, and that isn't because I have not put the tools there yet?
[18:26] <natefinch> sinzui: nope, totally a problem of the code itself trying to do something that just doesn't work on windows.
[18:26] <natefinch> sinzui: it's trying to replace file a with file b by just renaming a to b.... which evidently works on linux, but returns an error on windows.
[18:27] <sinzui> :(
[18:29] <natefinch> rogpeppe: so... basically anywhere we use os.Rename, we should probably use this new Replace function, assuming the idea is that it's supposed to always overwrite an existing thing.  Is that correct?
[18:29] <rogpeppe> natefinch: pretty much, yes
[18:29] <rogpeppe> natefinch: it would be worth having a quick audit
[18:30] <rogpeppe> natefinch: in some places we use mv, but those places are already hopelessly parochial
[18:30] <natefinch> heh
[18:44] <natefinch> rogpeppe: trying to decide if I should just replace every instance, or only those ones that might possibly run on the client.   FWIW for non-windows, the new function just passes through to os.Rename
[18:46] <rogpeppe> natefinch: for the time being, perhaps do only those that might possibly run on the client
[18:47] <natefinch> rogpeppe: the only one I'm not really sure about - charm/repo.go   func (s *CharmStore) Get(curl *URL) (Charm, error)
[18:47] <natefinch> rogpeppe: does the charm get downloaded to the client before getting uploaded, or is that only ever called by the agent?
[18:47] <rogpeppe> natefinch: that's definitely client side
[18:48] <natefinch> rogpeppe: ok, thought so
[18:48] <rogpeppe> natefinch: it's probably server side too, FWIW
[18:48] <natefinch> rogpeppe: ok
[18:55] <sinzui> once again hp/openstack spits in my face
[18:56] <natefinch> prorgamming would be so much easier without all these pesky "environments"
[18:58] <natefinch> rogpeppe: once my VM finished rebooting after installing windows updates, I'll be able to test the changes.  Luckily, I had done the windows API wrapping before, otherwise it would have been a pain in the butt to figure out.
[18:58] <rogpeppe> natefinch: yeah, thanks!
[18:59] <rogpeppe> natefinch: that's why you're here :-)
[18:59] <natefinch> rogpeppe: actually, trivia fact, it's what got me this job.  Gustavo asked me to write a named pipe implementation for windows, probably for use in a windows agent of some sort
[18:59] <sinzui> bugger, none of the tools arrived at HP
[19:00]  * rogpeppe has a lovely vision of a bag of hammers lost in transit
[19:00] <natefinch> rogpeppe: and thus I wrote this: https://github.com/natefinch/npipe/
[19:00] <natefinch> rogpeppe: lol
[19:01] <rogpeppe> natefinch: nice. it would be nicer if it provided a portable interface that worked cross platform, of course :-)
[19:02] <natefinch> rogpeppe: blah blah :)  He specifically asked for windows and gave me the weekend to do it, so I'm gonna call it pretty good.  You're welcome to contribute ;)
[19:02] <rogpeppe> natefinch: lol, yeah
[19:03] <sinzui> I am dropping anvils on sync-tools
[19:03] <natefinch> sinzui: very looney tunes of you
[19:04]  * rogpeppe tried to lift an anvil once, so feels sorry for the poor sync-tools
[19:04] <sinzui> :)
[19:04] <sinzui> I watched the Anvilainia episode of Animanics over the weekend
[19:05] <natefinch> nice nice, love the animaniacs
[19:07] <natefinch> rogpeppe: tests are running... had to stop my vm so I could run the tests... was getting OOM errors.  I'd add more RAM if I wasn't planning on replacing my laptop soon.  Running on 4G right now
[19:08]  * rogpeppe has never heard of the Animanics
[19:08] <natefinch> rogpeppe: cartoon... I doubt it's running anymore
[19:08] <sinzui> rogpeppe, It is in the vain of classic Looney Tunes.
[19:09] <rogpeppe> sinzui: cool
[19:09] <sinzui> Looks like 1.16.0 is genuinely released and works on the public clouds. I need to retest canonistack though since it too did not get 1.16.0 with my initial upload
[19:10] <natefinch> rogpeppe: http://www.youtube.com/watch?v=4YzTXxt9oOY
[19:10] <natefinch> ok, all tests pass, I'll test the fix on windows
[19:11] <rogpeppe> natefinch: ha, that doesn't go so well with the sounds that are currently playing here... (http://open.spotify.com/artist/6LtwY43IVeNpnireOVay0H)
[19:27] <rogpeppe> g'night all
[19:28] <natefinch> rogpeppe: night.  Thanks for the link to the music, sounds great
[20:01] <rogpeppe> natefinch: it's one of the albums of the year for me
[20:02] <natefinch> rogpeppe: very cool.  I don't have a spotify account, but I can find some live versions on youtube.  Pretty cool
[20:02] <rogpeppe> natefinch: i think spotify should give you a certain amount of free listening
[20:05] <natefinch> rogpeppe: I've been resisting signing up... but whatever, I'm a sucker, especially if I can't get the music anywhere else.... it's pretty great.
[20:05] <rogpeppe> natefinch: i'm not a big fan of subscription services in general, but i think spotify are pretty special
[20:06] <rogpeppe> natefinch: their metadata is brilliant because it was all provided by the labels themselves
[20:06] <natefinch> rogpeppe: I have a google music account which so far has had everything I've asked for... but it doesn't have this :)
[20:06] <rogpeppe> natefinch: (with the exception of dates of albums, annoyingly, which often come up as the date they were digitised)
[20:07] <rogpeppe> natefinch: hey, buy it off amazon :-)
[20:09] <natefinch> rogpeppe: buying music is so 90's
[20:09] <rogpeppe> natefinch: better quality though
[20:10] <natefinch> rogpeppe: yeah, and it's good to support the artists more directly
[20:10] <rogpeppe> natefinch: indeed
[20:10] <rogpeppe> natefinch: particularly below-the-radar stuff
[20:11] <natefinch> rogpeppe: absolutely
[20:11] <natefinch> rogpeppe: https://codereview.appspot.com/14502058
[20:11] <natefinch> super simple if you have time
[20:13] <rogpeppe> natefinch: i think utils.Replace should probably be utils.ReplaceFile
[20:13] <rogpeppe> natefinch: there's nothing about "utils" which suggests that Replace might be a file-oriented operation
[20:18] <natefinch> rogpeppe: good point
[20:18] <natefinch> rogpeppe: I was kind of going by os.Rename... but since we're in utils, not os, that's fair
[20:19] <rogpeppe> natefinch: when might UTF16PtrFromString fail?
[20:19] <natefinch> rogpeppe: If s contains a NUL byte at any location, it returns (nil, EINVAL)
[20:20] <rogpeppe> natefinch: i think we should perhaps panic in that case, or at the very least we should return a more descriptive message
[20:22] <natefinch> rogpeppe: we could... but really I'm just doing the exact same thing all the rest of the syscalls do, which is just return the error.  I think the cases where it can fail are vanishingly small.
[20:23] <rogpeppe> natefinch: hmm, i think that vanishingly unusual cases are just the place where you want something more than just "invalid argument"
[20:23] <rogpeppe> natefinch: although i suppose in this case that's a little more appropriate than the millions of places that usually return it....
[20:24] <natefinch> rogpeppe: actually, looking at os.Rename for windows, it wraps the error in a LinkError struct
[20:24] <natefinch> rogpeppe: I should do the same thing
[20:25] <rogpeppe> natefinch: or return "filename contains null bytes" ?
[20:26] <natefinch> rogpeppe: I strongly prefer doing things the same way as os.Rename, so our code can be a drop-in replacement
[20:26] <rogpeppe> natefinch: fair enough
[20:35] <natefinch> rogpeppe:  reproposed with the change to wrap the error
[20:36] <rogpeppe> natefinch: the name's still the same though...
[20:38] <rogpeppe> natefinch: did the fslock tests pass under windows?
[20:39] <rogpeppe> natefinch: reviewed
[20:42] <natefinch> rogpeppe: doh, name, right, sorry
[20:42] <natefinch> rogpeppe: it does work with directories as well, which is a little... confusing
[20:43] <rogpeppe> natefinch: there are a few places where "file" is used to mean either file or directory
[20:44] <rogpeppe> natefinch: os.File being a good example
[20:44] <natefinch> rogpeppe: fair enough
[20:45] <rogpeppe> natefinch: reciprocal review? https://codereview.appspot.com/14531048/
[20:46] <natefinch> rogpeppe: certainly
[20:47] <rogpeppe> natefinch: thanks
[20:47] <rogpeppe> natefinch: not quite as small as yours, i'm afraid
[20:47] <natefinch> rogpeppe: haha no problem.
[20:50] <natefinch> rogpeppe: btw, I haven't run any of the tests under windows.  you can cross-compile, but running the tests still has to be done on the native OS
[20:50] <natefinch> rogpeppe: and I don't have my environment quite set up on windows yet.  Getting there though.
[21:14] <rogpeppe> natefinch: for this change, the fslock tests would be good to try to run, i think, as they they're quite dependent on the functionality