| * 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:00 | |
| 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:01 |
| wallyworld | davecheney: any chance of confirming that this works for you? https://pastebin.canonical.com/98846/ | 00:05 |
| * 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:25 |
| wallyworld | this hack won't change cli though | 00:37 |
| wallyworld | davecheney: if it works: https://codereview.appspot.com/14592044 | 00:57 |
| marcoceppi_ | anyone around? | 01:21 |
| 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:22 |
| hazmat | marcoceppi_, there's some discussion for bundle v2 @ the sprint | 01:24 |
| 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:25 |
| 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:26 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| 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:31 |
| hazmat | marcoceppi_, ic. hence the proof support | 01:32 |
| 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:33 |
| 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:34 |
| * 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:35 |
| hazmat | just filed a bug on it | 01:38 |
| hazmat | bug 1237739 fwiw | 01:39 |
| hazmat | the empty constraints thing looks like its solved on comingsoon though not on jujucharms.com | 01:44 |
| 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:58 |
| 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 | 01:59 |
| wallyworld | otherwise it uploads to control bucket in the "proper" location | 02:00 |
| wallyworld | let me quickly check | 02:00 |
| 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:01 |
| wallyworld | davecheney: is the logging change any good? | 02:02 |
| davecheney | wallyworld: try it now | 02:03 |
| davecheney | wil be a while | 02:03 |
| davecheney | everything is slow | 02:04 |
| wallyworld | :-( | 02:04 |
| 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:12 |
| 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:13 |
| wallyworld | davecheney: https://code.launchpad.net/%7Ewallyworld/juju-core/default-debug-logging/+merge/190282 | 02:16 |
| davecheney | ta | 02:18 |
| davecheney | testing now | 02:19 |
| 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:27 |
| 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:28 |
| 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:29 |
| 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:30 |
| jpds | So, how do I do that? | 02:31 |
| davecheney | wallyworld: works perfectly | 02:31 |
| 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:32 |
| 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:33 |
| wallyworld | wow 18kbps | 02:34 |
| wallyworld | fast, not :-( | 02:34 |
| 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:35 |
| jpds | Yeah, it'll make my life so much easier. | 02:36 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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 | 02:41 |
| 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:01 |
| davecheney | will I be able to see the value I just set ? | 03:02 |
| wallyworld | sinzui: the logging change has merged | 03:12 |
| sinzui | thank you wallyworld | 03:23 |
| wallyworld | hopefully everything works ok :-) | 03:23 |
| wallyworld | dave tested it so should be good | 03:23 |
| 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:25 |
| wallyworld | oh. i'm not sure what's in that version. give me a sec to have a look | 03:26 |
| 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:27 |
| wallyworld | jpds: a quick look tells me that --source should work | 03:30 |
| jpds | $ juju sync-tools -v --source=/home/ubuntu/ | 03:31 |
| jpds | error:: no available tools. | 03:31 |
| wallyworld | 1.14 may have required the tools just to be under tools not tools/releases | 03:32 |
| 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:33 |
| 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:45 |
| jpds | Thanks! | 03:46 |
| wallyworld | great!! | 03:46 |
| wallyworld | np | 03:46 |
| 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 | 06:00 |
| fwereade | davecheney, yes, you should be able to | 07:24 |
| rogpeppe | mornin' all | 07:51 |
| axw | morning rogpeppe | 07:52 |
| axw | and fwereade | 07:52 |
| 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:54 |
| 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 :) | 07:55 |
| 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:02 |
| 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:03 |
| 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:04 |
| 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:06 |
| axw | fwereade: hmm yeah good point on env vars. | 08:07 |
| 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:08 |
| fwereade | axw, they don't create envs/env configs though, so not really very relevant | 08:09 |
| axw | fwereade: ah yes. | 08:09 |
| 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:10 |
| fwereade | axw, ha, yes | 08:11 |
| axw | and its use of stdout only makes sense if it's interactive | 08:11 |
| 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:20 |
| 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:21 |
| 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:22 |
| 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:23 |
| 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:24 |
| fwereade | rogpeppe, I think we shouldn't be passing possibleTools into bootstrap (or really StartInstance for that matter) | 08:25 |
| 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:26 |
| 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:27 |
| axw | this would have to lead to --upload-tools disappearing | 08:28 |
| 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:29 |
| axw | I suppose | 08:30 |
| rogpeppe | axw: they can potentially re-use some of the same logic | 08:30 |
| fwereade | axw, rogpeppe: I think that --upload-tools could probably still work -- putting the tools is conceptually independent of choosing them I think | 08:31 |
| 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:32 |
| fwereade | rogpeppe, +1000 | 08:33 |
| fwereade | bugger, I need to help cath a bit | 08:34 |
| axw | and I need to get dinner on | 08:34 |
| axw | bbs | 08:34 |
| 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:35 |
| jamespage | morning folks! hows 1.16.0 looking? milestoned bugs list looks great to me | 08:46 |
| 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:16 |
| mattyw | fwereade, do you have a moment? | 09:18 |
| fwereade | mattyw, sure | 09:18 |
| 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:19 |
| 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:20 |
| 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:22 |
| fwereade | mattyw, but then it is an exported func | 09:23 |
| 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:24 |
| 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:27 |
| fwereade | mattyw, sounds great, thanks | 09:28 |
| axw | someone on #juju having issues with OS X, if anyone has the time/knowledge | 09:31 |
| axw | he's trying trunk to get past the EC2/VPC bug | 09:32 |
| teknico | how do I get juju to show more output from hook errors? | 09:37 |
| fwereade | TheMue, you're probably the man to respond to axw's suggestion | 09:42 |
| 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:43 |
| teknico | fwereade: thank you, trying that | 09:44 |
| TheMue | axw: will contact him | 09:48 |
| fwereade | mattyw, ha, I just spotted something, I feel dumb now -- micro-review sent | 09:51 |
| 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:54 |
| 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:56 |
| fwereade | mattyw, I'm just thinking of where we put the logic | 09:57 |
| 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:06 |
| 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:07 |
| fwereade | mattyw, it would -- I'm not sure whether it's better as a method or a freefunc | 10:08 |
| rogpeppe | fwereade: you've gone... | 10:20 |
| 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:21 |
| mattyw | :b3 | 10:22 |
| mattyw | ^^ that was meant for vim | 10:22 |
| mattyw | fwereade, sorry me again :), is this basically what you had in mind? http://pastebin.ubuntu.com/6217438/ | 10:32 |
| mattyw | fwereade, you probably missed me asking if I roughly had the right idea here http://pastebin.ubuntu.com/6217438/ | 10:53 |
| 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:05 |
| TheMue | natefinch: hey, cool. yes, i like coffee very much. sounds fantastic. | 11:06 |
| 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:07 |
| 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:10 |
| 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:11 |
| natefinch | :) | 11:12 |
| mgz | it sounds fun, right up to the point where you have to start travelling with roasting and grinding apparatus :) | 11:12 |
| 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:13 |
| natefinch | I haven't decided what to do about grinding. Ideally you grind immediately before brewing, but my grinder weighs like 8 pounds | 11:14 |
| natefinch | I may have to suck it up and grind ahead of time like some sort of plebe | 11:15 |
| TheMue | jam, fwereade: unset is now exposed. a review of https://codereview.appspot.com/14439053 please | 11:40 |
| TheMue | or anyone else | 11:41 |
| fwereade | TheMue, LGTM, thanks | 11:44 |
| jam | fwereade: TheMue: reviewed | 11:44 |
| jam | TheMue: it would be nice to have 1 more test, but I wouldn't block landing that for 1.16. | 11:45 |
| TheMue | jam: unset has so few options, had no idea what to test more ;) | 11:47 |
| jam | TheMue: just 'juju unset --help" | 11:47 |
| 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:48 |
| TheMue | fwereade: need some help, merging it in trunk is well known to me. but how do i get it in 1.16? | 11:52 |
| 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:56 |
| TheMue | jam: thx, and shit, built it from trunk | 11:57 |
| 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:58 |
| TheMue | jam: no, just one commit | 11:59 |
| TheMue | jam: will try now, thx | 11:59 |
| 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:06 |
| 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:07 |
| 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:08 |
| TheMue | "All changes applied successfully." welcome to the world of branching and merging. | 12:11 |
| TheMue | jam: so, now proposed. now approving with message. | 12:16 |
| TheMue | jam: done. and for trunk? simply approve the first one too? | 12:17 |
| 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:18 |
| 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:19 |
| 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:20 |
| 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:21 |
| 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:22 |
| TheMue | jam: gna, so multiple switches the whole time every day. fantastic | 12:23 |
| 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:24 |
| jam | TheMue: yeah, CVS made it very hard to manage multiple ongoing branches | 12:25 |
| TheMue | jam: but what will change | 12:25 |
| TheMue | jam: I'm happy that I now get more and more into git workflows for my private projects | 12:26 |
| 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:28 | |
| TheMue | jam: but to be more philosophical, what in the world is stable? ;) | 12:29 |
| 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:30 |
| TheMue | jam: that's how it should be | 12:32 |
| TheMue | jam: btw, thanks, branch has landed in 1.16 | 12:32 |
| 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:34 |
| * TheMue => lunch (wife just called) | 12:35 | |
| * fwereade needs to look after laura for a while, she's about to get back from school and cath isn't yet; bbl | 13:21 | |
| 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:33 |
| natefinch | anyone interested in looking at my new constraint that covers ec2 instance names?cd ../ | 13:49 |
| natefinch | heh oops | 13:49 |
| natefinch | here's the CR for ^^ https://codereview.appspot.com/14523052 | 13:50 |
| TheMue | *click* | 13:51 |
| TheMue | natefinch: what is when you're using a type which is not matching the hardware constraints? | 14:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| * sinzui really must optimise what is uploaded to azure for testing | 14:34 | |
| 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:35 |
| TheMue | natefinch: or how it is detected and reported as problem | 14:36 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| 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:46 |
| TheMue | natefinch: ok, thx, got it | 14:48 |
| rogpeppe | mgz: did you get around to reviewing that CL? https://codereview.appspot.com/14529050 | 15:09 |
| mgz | rogpeppe: sorry, still have that tab open, resuming | 15:16 |
| rogpeppe | mgz: np | 15:16 |
| 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:24 |
| fwereade | natefinch, fwiw axw has a prechecker mechanism that will enable just that | 15:28 |
| natefinch | fwereade: swet | 15:28 |
| natefinch | sweet too | 15:28 |
| 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:29 |
| 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:30 |
| fwereade | natefinch, because openstack instance types do mask them, but ec2 ones don't | 15:31 |
| sinzui | jamespage, fwereade I am blessing lp:juju-core/1.16 r1969. I will make the tarball | 15:32 |
| fwereade | sinzui, <3 | 15:32 |
| 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:38 |
| 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:39 |
| 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:40 |
| 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:41 |
| 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:42 |
| 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:43 |
| 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:44 |
| 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:45 |
| natefinch | fwereade: good, yeah, that's what I was thinking - ask the provider if it thinks the constraints make sense. | 15:46 |
| 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:47 |
| 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:49 |
| 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) | 15:50 |
| 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:03 |
| natefinch | sinzui: awesome | 16:04 |
| mgz | `bzr pull --overwrite-tags` all | 16:06 |
| 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:38 |
| 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:41 |
| sinzui | yep, that's the one | 16:47 |
| sinzui | I have just had my best idea today. bootstrap the juju 1.14.1 now while the packages build. no waiting for azure | 16:57 |
| natefinch | sinzui: 1.16 windows installer - http://ubuntuone.com/1aRNVzEv0VDUS5s9Exh53B | 17:10 |
| 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:11 |
| 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:12 |
| sinzui | there is still time. I can put all the public tools in the wrong place or corrupt them. | 17:13 |
| sinzui | ouch | 17:13 |
| 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:14 |
| natefinch | rogpeppe: you around? | 17:19 |
| rogpeppe | natefinch: i am | 17:19 |
| 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:20 |
| 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:21 |
| natefinch | rogpeppe: ahh crap | 17:22 |
| 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:23 |
| 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:24 |
| 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:25 |
| 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:26 |
| natefinch | rogpeppe: move /y in the CLI | 17:27 |
| 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:28 |
| 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:39 |
| 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:40 |
| 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:41 |
| rogpeppe | natefinch: (i'd think we'd make a utils/file package containing a ReplaceFile function, or something similar) | 17:43 |
| 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:46 |
| 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:47 |
| 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 | 17:59 |
| 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:05 |
| TheMue | good night | 18:11 |
| === ahasenack is now known as andreas | ||
| natefinch | TheMue: g'night | 18:11 |
| * sinzui sighs | 18:23 | |
| sinzui | the saucy packages has a different version than I expected. | 18:24 |
| * sinzui hacks the script | 18:24 | |
| 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:25 |
| 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:26 |
| sinzui | :( | 18:27 |
| 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:29 |
| rogpeppe | natefinch: in some places we use mv, but those places are already hopelessly parochial | 18:30 |
| natefinch | heh | 18:30 |
| 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:44 |
| rogpeppe | natefinch: for the time being, perhaps do only those that might possibly run on the client | 18:46 |
| 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:47 |
| natefinch | rogpeppe: ok, thought so | 18:48 |
| rogpeppe | natefinch: it's probably server side too, FWIW | 18:48 |
| natefinch | rogpeppe: ok | 18:48 |
| sinzui | once again hp/openstack spits in my face | 18:55 |
| natefinch | prorgamming would be so much easier without all these pesky "environments" | 18:56 |
| 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:58 |
| 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 | 18:59 |
| * 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:00 |
| rogpeppe | natefinch: nice. it would be nicer if it provided a portable interface that worked cross platform, of course :-) | 19:01 |
| 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:02 |
| sinzui | I am dropping anvils on sync-tools | 19:03 |
| natefinch | sinzui: very looney tunes of you | 19:03 |
| * 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:04 |
| natefinch | nice nice, love the animaniacs | 19:05 |
| 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:07 |
| * 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:08 |
| 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:09 |
| natefinch | rogpeppe: http://www.youtube.com/watch?v=4YzTXxt9oOY | 19:10 |
| natefinch | ok, all tests pass, I'll test the fix on windows | 19:10 |
| rogpeppe | natefinch: ha, that doesn't go so well with the sounds that are currently playing here... (http://open.spotify.com/artist/6LtwY43IVeNpnireOVay0H) | 19:11 |
| rogpeppe | g'night all | 19:27 |
| natefinch | rogpeppe: night. Thanks for the link to the music, sounds great | 19:28 |
| rogpeppe | natefinch: it's one of the albums of the year for me | 20:01 |
| 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:02 |
| 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:05 |
| 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:06 |
| rogpeppe | natefinch: hey, buy it off amazon :-) | 20:07 |
| natefinch | rogpeppe: buying music is so 90's | 20:09 |
| rogpeppe | natefinch: better quality though | 20:09 |
| 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:10 |
| natefinch | rogpeppe: absolutely | 20:11 |
| natefinch | rogpeppe: https://codereview.appspot.com/14502058 | 20:11 |
| natefinch | super simple if you have time | 20:11 |
| 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:13 |
| 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:18 |
| rogpeppe | natefinch: when might UTF16PtrFromString fail? | 20:19 |
| natefinch | rogpeppe: If s contains a NUL byte at any location, it returns (nil, EINVAL) | 20:19 |
| rogpeppe | natefinch: i think we should perhaps panic in that case, or at the very least we should return a more descriptive message | 20:20 |
| 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:22 |
| 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:23 |
| 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:24 |
| rogpeppe | natefinch: or return "filename contains null bytes" ? | 20:25 |
| 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:26 |
| natefinch | rogpeppe: reproposed with the change to wrap the error | 20:35 |
| rogpeppe | natefinch: the name's still the same though... | 20:36 |
| rogpeppe | natefinch: did the fslock tests pass under windows? | 20:38 |
| rogpeppe | natefinch: reviewed | 20:39 |
| natefinch | rogpeppe: doh, name, right, sorry | 20:42 |
| natefinch | rogpeppe: it does work with directories as well, which is a little... confusing | 20:42 |
| rogpeppe | natefinch: there are a few places where "file" is used to mean either file or directory | 20:43 |
| rogpeppe | natefinch: os.File being a good example | 20:44 |
| natefinch | rogpeppe: fair enough | 20:44 |
| rogpeppe | natefinch: reciprocal review? https://codereview.appspot.com/14531048/ | 20:45 |
| natefinch | rogpeppe: certainly | 20:46 |
| rogpeppe | natefinch: thanks | 20:47 |
| rogpeppe | natefinch: not quite as small as yours, i'm afraid | 20:47 |
| natefinch | rogpeppe: haha no problem. | 20:47 |
| 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. | 20:50 |
| 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 | 21:14 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!