| davecheney | woot, my x220 arrived | 05:37 |
|---|---|---|
| davecheney | boo, my 9mm ssd does not fit | 05:37 |
| imbrandon | whats the best way to obtain the machine_id outside of a hook context , e.g from a script running on cron so i can pass it to a cli app via --machine_id , is that available yet ? | 05:38 |
| wrtp | davecheney, fwereade: mornin' | 06:57 |
| fwereade | wrtp, heyhey | 06:57 |
| davecheney | morning' lads | 06:57 |
| davecheney | wrtp: i commited the environ/setconfig stuff last night | 06:58 |
| wrtp | davecheney: yay! | 06:59 |
| davecheney | so you should be cool to merge your PutBucket caching | 06:59 |
| wrtp | davecheney: i'll do the madeBucket stuff next then | 06:59 |
| davecheney | wrtp: jynx | 06:59 |
| davecheney | also, my x220 came this afternoon | 06:59 |
| davecheney | so I am in heaven | 06:59 |
| wrtp | davecheney: great. it's beenh working well for me | 06:59 |
| wrtp | davecheney: did you go for solid state? | 06:59 |
| davecheney | i was going to move over the disk I had in my netbook | 07:00 |
| davecheney | but it turns out you need a 7mm ssd | 07:00 |
| davecheney | so i'll put my current one in my desktop and get another one for this | 07:00 |
| davecheney | at the moment i'm in 7200rpm country | 07:00 |
| davecheney | eww | 07:00 |
| davecheney | wrtp: fwereade g+ says that gustavo is in +1 atm | 07:01 |
| davecheney | is that true ? | 07:01 |
| wrtp | davecheney: yeah | 07:01 |
| wrtp | davecheney: he's in london | 07:01 |
| davecheney | conference ? | 07:01 |
| wrtp | davecheney: sprint of some kind | 07:01 |
| fwereade | davecheney, wrtp speaks truth :) | 07:01 |
| davecheney | i heard they are moving out of millbank towers | 07:01 |
| wrtp | davecheney: yeah. don't know why though. | 07:02 |
| wrtp | davecheney: maybe lease ran out or something | 07:02 |
| davecheney | sounds like a long way to go for a working bee, but who am i to judge | 07:02 |
| fwereade | davecheney, wrtp: as I understand it just not enough space there | 07:02 |
| wrtp | fwereade: ah, makes sense | 07:02 |
| fwereade | davecheney, wrtp: bit disappointed in myself that I never got round to visiting, apparently it was rather cool | 07:02 |
| wrtp | fwereade: me too. | 07:03 |
| davecheney | wrtp: i'm still getting that strange 'cant find cmd/jujud' test error | 07:03 |
| wrtp | fwereade: didn't have an excuse though | 07:03 |
| davecheney | it eventually sorts itself out | 07:03 |
| wrtp | davecheney: have you still got it? | 07:03 |
| davecheney | wrtp: happens any time I touch ~/go/src/pkg | 07:03 |
| davecheney | it's clearly a bug in the go test support for main packages | 07:03 |
| davecheney | but i'm thinking of just giving up and moving the agents out of main | 07:03 |
| wrtp | davecheney: yeah. | 07:03 |
| wrtp | davecheney: that's not the way forward though! | 07:04 |
| davecheney | i'm on the fence if testing main packages is really the right solution | 07:04 |
| wrtp | davecheney: i've been trying to home in on the bug, but haven't figured out a way of reliably reproducing it | 07:04 |
| wrtp | davecheney: i don't see why not. | 07:04 |
| davecheney | wrtp: cd ~/go/src && ./all.bash && rm -rf $GOPATH/pkg/launchpad.net/juju/* | 07:05 |
| davecheney | will do it | 07:05 |
| * wrtp tries that | 07:05 | |
| wrtp | davecheney: doesn't seem to | 07:07 |
| davecheney | oh, sorry, do a hg update | 07:07 |
| davecheney | you need to have a different version of the std lib | 07:07 |
| davecheney | % go version | 07:07 |
| davecheney | go version weekly.2012-03-27 +1afae7555667 | 07:07 |
| davecheney | ^ the last bit has to change | 07:07 |
| davecheney | wrtp: if that doesn't work, then leave it with me | 07:09 |
| davecheney | i'll figure out what is the cause | 07:09 |
| davecheney | that upsets it | 07:09 |
| === meetingology` is now known as meetingology | ||
| fwereade | davecheney, btw, re Machine.Config()... my gut says this should just be a pair of SetInstanceId/InstanceId methods | 07:13 |
| wrtp | davecheney: nope, that didn't work either | 07:13 |
| fwereade | davecheney, I'm not sure we really want anyone outside to know/care what keys we're using under the hood | 07:13 |
| davecheney | wrtp: ok, i'll figire out what i'm doing that shits it | 07:13 |
| davecheney | i'm pretty sure it's related to the damaged I do to my ~/go | 07:13 |
| davecheney | fwereade: fair call | 07:13 |
| davecheney | it's not hard to change, the underlying content of the machine node is still a *ConfigNode | 07:14 |
| davecheney | unless anyone has objections | 07:14 |
| fwereade | davecheney, cool, thanks :) | 07:14 |
| fwereade | davecheney, I'll not on the review for form's sake | 07:14 |
| fwereade | note | 07:14 |
| davecheney | fwereade: I won't change it tonight (can't be arsed merging) but consider your advice accepted | 07:15 |
| wrtp | davecheney: why do you think testing main packages might not be good, BTW? | 07:15 |
| davecheney | wrtp: well, 'cos it's buggy | 07:16 |
| wrtp | davecheney: apart from that | 07:16 |
| fwereade | davecheney, cheers | 07:16 |
| wrtp | davecheney: (the bug will be fixed) | 07:16 |
| wrtp | davecheney: i only see that bug *very* sporadically BTW | 07:16 |
| davecheney | i think (although this is only a matter of personal taste) that main packages should be as small as possible, they should just import the stuff that they need, instanciate it | 07:16 |
| davecheney | and off they go | 07:16 |
| davecheney | it's just a personal preference | 07:16 |
| davecheney | sort of based on the way that the go tool works | 07:16 |
| davecheney | ie, most of the logic is in go/build and friends | 07:17 |
| wrtp | davecheney: that's definitely not the way that the go tool is written! | 07:17 |
| davecheney | shows what I know :) | 07:17 |
| davecheney | anyway, it's not even a small objection | 07:17 |
| wrtp | davecheney: there are >7000 lines in cmd/go/*.go | 07:17 |
| wrtp | davecheney: bits which factor out nicely are done as packages, yeah | 07:18 |
| wrtp | davecheney: but i'm not sure i agree about the principle that all the logic of command line program should be in external packages. | 07:18 |
| davecheney | more guidelines | 07:19 |
| wrtp | davecheney: i think packages should be useful... | 07:19 |
| davecheney | i don't think of main as a package | 07:19 |
| wrtp | davecheney: it's not | 07:19 |
| wrtp | davecheney: well... it is strictly, but. | 07:19 |
| davecheney | and that forms the basis of my preference, nothing more | 07:20 |
| fwereade | wrtp, I see where davecheney's coming from, but in my case I suspect this is a prejudice based on unpleasant experiences with vast untestable mains in c/c++ :) | 07:20 |
| wrtp | davecheney: but i'm thinking about the package that you hive off so that the main package can be minimal | 07:20 |
| wrtp | davecheney: taking it to its logical conclusion you just get another package with a Main function... | 07:21 |
| davecheney | wrtp: there are limits to any good intention | 07:21 |
| wrtp | davecheney: and in Go (that bug notwithstanding) we *can* test main packages and their component pieces | 07:22 |
| davecheney | wrtp: maybe I should just try to figure out why go test keeps fucking up, then there is no reason for main to be a 2nd class citizen :) | 07:22 |
| wrtp | davecheney: indeed. | 07:22 |
| davecheney | what time does aram come online ? | 07:23 |
| davecheney | i was going to stick around for a chat | 07:23 |
| wrtp | davecheney: as i said, i only see that bug about once a month or so | 07:23 |
| wrtp | davecheney: i don't know when Aram comes on line, but soon I imagine | 07:23 |
| davecheney | wrtp: i get it more frequently, i'm pretty sutre it's related to linker skew when I rebuild go | 07:24 |
| davecheney | and I remember a bug with the go tool not checking the return code for the linker or go pack | 07:24 |
| davecheney | which might be a clue | 07:24 |
| wrtp | davecheney: we had the thought that we could try to have a G+ hangout with all of us today. do you think that might be possible? | 07:24 |
| davecheney | remy_o had a CL | 07:24 |
| davecheney | but it got superceeded by another | 07:24 |
| wrtp | davecheney: doesn't linker skew result in an error (incompatible versions, or something)?: | 07:25 |
| davecheney | wrtp: it _should_, but I think in this case the actual error is being eaten, so you don't get the .a on disk, then testing can't find it | 07:25 |
| davecheney | which is my suspicion | 07:25 |
| wrtp | davecheney: BTW if i touch the Go files, the problem goes away for me | 07:26 |
| davecheney | yeah, if you rebuild things in just the right way, and face the right direction, then problem goes away | 07:26 |
| davecheney | do you use go build or go get ? | 07:26 |
| wrtp | davecheney: in the normal course of things? | 07:27 |
| davecheney | alias gb='go install -v' | 07:27 |
| wrtp | davecheney: for juju, i rarely use anything but go test | 07:27 |
| davecheney | oh, that is weird | 07:27 |
| davecheney | that isn't supposed to be like that | 07:27 |
| davecheney | i thought I made it go install -v | 07:27 |
| wrtp | davecheney: i use go test -i too | 07:28 |
| davecheney | sorry, i thought it was go get -v | 07:28 |
| wrtp | davecheney: why would you use go get? | 07:29 |
| wrtp | davecheney: i suppose it gets dependencies automatically if they're not there | 07:29 |
| davecheney | yup | 07:29 |
| davecheney | turns out i don't need it :) | 07:29 |
| wrtp | davecheney: but if they are there, then there's no difference. | 07:29 |
| wrtp | i only use go get when i fetch something new | 07:29 |
| davecheney | oh, i remember now, i used to alias gb='go build -v' | 07:30 |
| davecheney | but that won't install intermediate pacakges | 07:30 |
| davecheney | so I switch to to go install | 07:30 |
| wrtp | davecheney: i don't use go build because it leaves the executables around | 07:31 |
| wrtp | davecheney: and they make the tree dirty | 07:31 |
| davecheney | yeah, and poos in your working copy | 07:31 |
| wrtp | davecheney: so can you reproduce issue 3417 now, out of interest? | 07:32 |
| davecheney | sporadically | 07:33 |
| wrtp | davecheney: i meant right at this moment, by following your instructions above. | 07:41 |
| wrtp | davecheney: but it doesn't matter - i was just interested | 07:42 |
| davecheney | wrtp: actually it's happening to me right now | 07:43 |
| davecheney | i wonder if it's timestamp related | 07:43 |
| wrtp | davecheney: that's my thought | 07:43 |
| davecheney | ctime <> mtime | 07:44 |
| wrtp | davecheney: nah, not ctime | 07:44 |
| davecheney | i run with noatime | 07:44 |
| davecheney | but I don't think go can even look at that | 07:44 |
| wrtp | davecheney: could you do an ls -ltR of $GOROOT and $GOPATH | 07:44 |
| davecheney | u want it all ? | 07:45 |
| wrtp | davecheney: i reckon. it won't be much gzipped and it's easier than just picking out the bits we need. | 07:45 |
| wrtp | davecheney: in fact, don't worry about the -t bit | 07:45 |
| wrtp | davecheney: better in alphabetical order | 07:45 |
| wrtp | davecheney: if you could make it print the times in unix format, that would be better too | 07:46 |
| davecheney | wrtp: i'll do it after dinner | 07:46 |
| wrtp | davecheney: as numeric timestamps, i mean. i can't remember the option (if there is one) | 07:46 |
| wrtp | davecheney: cool. | 07:46 |
| davecheney | trying to finish up and send off my email | 07:46 |
| davecheney | to see if I can get some review time with gustavo | 07:46 |
| wrtp | davecheney: i've been waiting for the opportunity to arise again | 07:46 |
| davecheney | trying to avoid another setconfig by keeping the changeset as small as possible | 07:47 |
| davecheney | wrtp: bloody lbox, you can't add -req if you've already proposed, even in -wip | 07:55 |
| wrtp | davecheney: no, it's a pain | 07:55 |
| davecheney | reqs are a pain, full stop | 07:55 |
| wrtp | davecheney: it's not lbox, it's launchpad | 07:55 |
| * davecheney shakes fist at lp | 07:55 | |
| wrtp | davecheney: you can't change the prereq of a merge | 07:55 |
| davecheney | and you can't have more than on prereq O_o! | 07:56 |
| wrtp | davecheney: you'll have to delete the merge request | 07:56 |
| davecheney | s/on/one | 07:56 |
| wrtp | davecheney: yeah, that too | 07:56 |
| davecheney | DVCS for the fail | 07:56 |
| davecheney | anyway, this is just end of day whinging | 07:56 |
| wrtp | davecheney: lp is not the greatest | 07:56 |
| davecheney | fwereade: // InstanceId returns the provider specific identifier for this machine. If no id has been asssinged by the provider, this value will be blank. | 07:59 |
| fwereade | davecheney, SGTM | 07:59 |
| davecheney | and it just panics if there is crap in the config node | 08:00 |
| davecheney | actually, i'm not going to do this today, i'm going to call it an evening | 08:00 |
| davecheney | it's 6pm | 08:00 |
| fwereade | davecheney, yeah, have a rest | 08:00 |
| davecheney | fwereade: but i'll address that first thing tomorrow | 08:00 |
| davecheney | later lads | 08:01 |
| fwereade | davecheney, not 100% sure about panicing | 08:01 |
| fwereade | davecheney, take care | 08:01 |
| TheMue | Morning, and good night davecheney | 08:05 |
| fwereade | heya TheMue :) | 08:20 |
| TheMue | fwereade: Moin | 08:21 |
| wrtp | davecheney: see ya | 08:37 |
| niemeyer | Good mornings! | 08:59 |
| fwereade | heya niemeyer | 09:18 |
| rogpeppe | niemeyer: yo! | 09:40 |
| niemeyer | Hey guys | 09:51 |
| niemeyer | fwereade: LGTM on charm-store-backend | 09:57 |
| niemeyer | fwereade: Good stuff | 09:57 |
| TheMue | niemeyer <- themue.moin() | 09:58 |
| fwereade | niemeyer, thanks :) | 09:58 |
| niemeyer | TheMue: Moin :) | 09:58 |
| rogpeppe | TheMue: i've been looking at doing the machine provider, and i realise that we haven't got a unit watcher yet. have you looked at that at all? | 10:01 |
| rogpeppe | s/machine provider/machine agent/ | 10:02 |
| TheMue | rogpeppe: You mean the watcher returned by watch_service_unit_state in the py code? | 10:04 |
| rogpeppe | TheMue: i think so | 10:04 |
| * rogpeppe checks | 10:04 | |
| TheMue | rogpeppe: If so then yes, it's a not yet covered watcher. | 10:05 |
| Aram | morning. | 10:05 |
| rogpeppe | Aram: heya | 10:06 |
| TheMue | Aram: Moin. | 10:06 |
| fwereade | Aram, heyhey | 10:06 |
| rogpeppe | TheMue: actually the one i need is MachineState.watch_assigned_units | 10:09 |
| TheMue | rogpeppe: That's also an open watcher. Machine is so far very small. | 10:10 |
| rogpeppe | TheMue: i could do it assuming you're currently working on something else. | 10:11 |
| TheMue | rogpeppe: Currently I'm working on State.AddRelation() (redesign after review). Then I can do the watcher. | 10:11 |
| TheMue | rogpeppe: Oh, if you would like to then thank you. | 10:11 |
| rogpeppe | fwereade: do you know if it's possible to have two units on the same machine using the same charm? by my very coarse reading, it looks like it might be possible and that it could cause problems. | 10:31 |
| rogpeppe | niemeyer: ^ | 10:37 |
| fwereade | rogpeppe, expand a little please... I can't think of an obvious way to do so, but there probably is one | 10:41 |
| fwereade | rogpeppe, and it depends on the problems... is it the known will-try-to-use-same-ports deal, or something else that's worrying you? | 10:42 |
| rogpeppe | fwereade: we could have two subordinate services with different service names but using the same charm, right? | 10:42 |
| rogpeppe | fwereade: it's the shared directory that concerns me | 10:42 |
| niemeyer | rogpeppe: The same *charm* in the same machine? Of course | 10:42 |
| fwereade | rogpeppe, hmm, ok, I haven't looked into subordinates in details... I *thought* distinct units got distinct dirs | 10:42 |
| fwereade | rogpeppe, and wil therefore have 2 copies of the charm | 10:43 |
| rogpeppe | niemeyer: it looks to me like a given charm will always be stored in the same directory, regardless of the service | 10:43 |
| niemeyer | rogpeppe: That's bogus | 10:43 |
| fwereade | rogpeppe, that said I have occasionally spotted and fixed bugs along those lines so there could well be more I missed | 10:43 |
| rogpeppe | niemeyer: yeah, i think so. i may be wrong though. | 10:43 |
| niemeyer | rogpeppe: If you mean expanded in the same directory, that is | 10:43 |
| fwereade | rogpeppe, are you sure the charm isn't expanded to a unit-specific dir? | 10:43 |
| rogpeppe | niemeyer: yes i do. or at least, that's how it looks. | 10:43 |
| rogpeppe | fwereade: no :-) | 10:43 |
| niemeyer | rogpeppe: If different service units are living in the same directory, that's a bug | 10:43 |
| fwereade | rogpeppe, do you have a reference in the python? | 10:44 |
| rogpeppe | fwereade: unit/deploy.py | 10:44 |
| rogpeppe | fwereade: download_charm | 10:44 |
| rogpeppe | fwereade: charms_directory is always $units_directory/charms | 10:45 |
| fwereade | rogpeppe, hmm, yeah, looks like crack to me | 10:45 |
| rogpeppe | fwereade: ok, thanks | 10:45 |
| niemeyer | rogpeppe: service unit != charm, FWIW | 10:45 |
| fwereade | rogpeppe, niemeyer: one thought: why is the machine agent responsible for this in the first place? | 10:45 |
| rogpeppe | niemeyer: yeah, i thought so | 10:45 |
| niemeyer | fwereade: Probably historical, before we had subordinates | 10:46 |
| fwereade | rogpeppe, niemeyer: it's always seemed odd to me that we have duplicated code for getting and unpacking charms in unit/machine agents | 10:46 |
| niemeyer | fwereade: Might make sense to have the unit doing it | 10:46 |
| fwereade | niemeyer, +1 | 10:46 |
| rogpeppe | fwereade: yeah, perhaps the unit agent should unpack all charms | 10:46 |
| rogpeppe | fwereade: which makes the machine agent simpler, which sounds good to me right now :-) | 10:46 |
| fwereade | rogpeppe, cool :) | 10:47 |
| rogpeppe | fwereade: while you're here... | 10:48 |
| fwereade | rogpeppe, yeah? | 10:48 |
| rogpeppe | fwereade: in agents/machine.py, it looks to me like service_state_manager is never used. am i missing something superclassy? | 10:48 |
| * fwereade looks | 10:49 | |
| fwereade | rogpeppe, can't see any usage of it, can't see any reason to need it in the first place | 10:50 |
| rogpeppe | fwereade: thanks | 10:50 |
| rogpeppe | niemeyer: i think we've said that we want to build in upgrade from the beginning. is there a plan of how to do that, in particular how we want to tell the agents to upgrade themselves? | 11:26 |
| fwereade | rogpeppe, do you recall any relevant details re plans for the dummy environ's zookeeper? | 11:49 |
| rogpeppe | fwereade: more or less | 11:49 |
| fwereade | rogpeppe, I think I need that soonish, so anything yu can transfer would be good | 11:50 |
| rogpeppe | fwereade: i'll just have a peek to remind myself | 11:50 |
| rogpeppe | fwereade: the idea is to start a zookeeper if the zookeeper attribute in the config is true | 11:51 |
| rogpeppe | fwereade: it'll only happen the first time that an environ of the given name is opened, but that seems right to me | 11:52 |
| fwereade | rogpeppe, the issue is that I'm pretty sure we don't want to start a new zookeeper every time we need a dummy environ for tests | 11:52 |
| fwereade | rogpeppe, hm, I must be missing something | 11:52 |
| * fwereade looks again | 11:52 | |
| rogpeppe | fwereade: that's fine - don't set the zookeeper attr to true in those cases. | 11:53 |
| fwereade | rogpeppe, I mean I think we'll want to share zookeepers... won;t we? | 11:53 |
| rogpeppe | fwereade: hmm. that's potentially awkward, but should be doable | 11:54 |
| fwereade | rogpeppe, I guess what I was really asking is "this feels awkward but necessary, has someone already come up with a nice plan?" | 11:54 |
| rogpeppe | fwereade: i think it can all be done inside dummy with no visibility outside. i'd have a global instance that's used/started for the first zk after any Reset. | 11:55 |
| rogpeppe | fwereade: (if someone opens two dummy environs at the same time, we don't want them to share zks) | 11:56 |
| rogpeppe | fwereade: alternatively... we could just keep all zk instances around. probably simpler now i come to think of it. | 11:57 |
| fwereade | rogpeppe, I fret that shutting them down will become complex | 11:57 |
| rogpeppe | fwereade: i don't think that's too hard. we'd need to provide a Shutdown method or something. | 11:58 |
| rogpeppe | fwereade: and we'd need to implement state.Close to return any zk instance that the state is using to the unused pool | 11:59 |
| fwereade | rogpeppe, it's knowing when to call it that's the problem | 11:59 |
| niemeyer | rogpeppe: Nothing written down yet, but it's time to talk about it indeed | 11:59 |
| * niemeyer has to switch rooms | 11:59 | |
| niemeyer | brb | 11:59 |
| rogpeppe | fwereade: all in all i doubt that it should take more than about 30 lines of code | 12:00 |
| fwereade | rogpeppe, hmm, actually, the existing model where we start up a shared ZK per test package may be a good way to go... we just need to inform the dummy environ of it at some point | 12:00 |
| fwereade | rogpeppe, I'm not too bothered about starting multiple dummy environs at the same time... what's the use case? | 12:01 |
| rogpeppe | fwereade: we do that in some places, but those cases probably don't need zk | 12:01 |
| rogpeppe | fwereade: a panic if it happened would probably be fine. | 12:02 |
| rogpeppe | fwereade: that's nicely simpler actually. | 12:02 |
| rogpeppe | fwereade: then Reset can remove everything from the dummy's zk | 12:02 |
| rogpeppe | fwereade: or maybe the tests should do that, i dunno | 12:03 |
| fwereade | rogpeppe, probably one for the tests, but not sure... and, hmm, bootstrap can Initialize state, now I think of it :) | 12:03 |
| fwereade | rogpeppe, if zookeeper is set, that is | 12:04 |
| rogpeppe | fwereade: i think i like the idea of handing off the server to the dummy environ | 12:04 |
| rogpeppe | fwereade: dummy.SetZookeeper(*zookeeper.Server) perhaps | 12:04 |
| fwereade | rogpeppe, yeah | 12:05 |
| rogpeppe | dummy.SetZookeeper(testing.StartZkServer()) seems nice | 12:05 |
| rogpeppe | fwereade: then, yeah, have dummy.Reset do the ZkRemoveTree | 12:06 |
| rogpeppe | fwereade: and have dummy.environConfig.Open check, if cfg.zookeeper is true, that we're not creating a new state. | 12:07 |
| rogpeppe | fwereade: and panic otherwise | 12:08 |
| rogpeppe | fwereade: or actually it can return an error | 12:08 |
| fwereade | rogpeppe, sounds like a plan, I'll see what I can do | 12:08 |
| rogpeppe | fwereade: sounds good. thanks. | 12:09 |
| rogpeppe | niemeyer: lsb_release prints n/a when it can't find the current release | 12:45 |
| niemeyer | rogpeppe: The test still looks bogus.. why is it conflating an error with a return of a value | 12:45 |
| niemeyer | rogpeppe: Or do I misunderstand it? | 12:46 |
| rogpeppe | niemeyer: it means the test will still run successfully even on a non-ubuntu platform | 12:46 |
| rogpeppe | niemeyer: or a platform where lsb_release doesn't exist | 12:46 |
| Aram | rogpeppe: is what you are doing now related to what I asked you yesterday about hardcoding CurrentSeries and CurrentArch? | 12:47 |
| rogpeppe | Aram: yes | 12:47 |
| niemeyer | rogpeppe: Ok, looks good then | 12:47 |
| niemeyer | rogpeppe: A comment would be nice | 12:48 |
| rogpeppe | niemeyer: thanks. and thanks for the review. will do a comment. | 12:48 |
| Aram | rogpeppe: maybe I'm misunderstanding something fundamental, but where do you want to run lsb_release? | 12:49 |
| rogpeppe | Aram: in the test. to make sure my parsing of /etc/lsb-release is sane. | 12:49 |
| rogpeppe | Aram: see https://codereview.appspot.com/6260048/diff/2001/environs/tools_test.go#newcode276 | 12:50 |
| Aram | ah, ok. | 12:50 |
| Aram | in the test makes sense. | 12:50 |
| Aram | but then we can't run the test on every platform. | 12:50 |
| rogpeppe | Aram: we can. and that's the point. | 12:51 |
| Aram | ok, let me look at the patch. | 12:51 |
| rogpeppe | Aram: that was what we were just discussing | 12:51 |
| Aram | so the test runs without lsb_release, but its utility is reduced if lsb_release does not exist. | 12:52 |
| rogpeppe | niemeyer: rather than full-blown unquote, i'm doing strings.Trim(line[len(p):], ` \t'"`) which should be sufficient i think | 12:53 |
| rogpeppe | Aram: yeah | 12:53 |
| niemeyer | rogpeppe: Yeah, sounds good | 12:56 |
| niemeyer | rogpeppe: Thanks | 12:56 |
| rogpeppe | niemeyer: i wouldn't mind leaving the "current Ubuntu release name" in. i remember being a little confused when i came across "series" being used all over the place in the charm packages, and didn't realise it was a synonym for "ubuntu release". if we're going to have a comment anywhere, perhaps this is a good place. | 12:56 |
| rogpeppe | niemeyer: it doesn't appear to be a commonly used term even in the ubuntu community | 12:56 |
| rogpeppe | s/ in./ comment in./ | 12:57 |
| niemeyer | rogpeppe: I'm not sure.. the whole code base trusts on the term | 12:57 |
| niemeyer | rogpeppe: That doesn't look like a special instance of it | 12:57 |
| rogpeppe | niemeyer: yes, but nowhere do we actually say what it is. | 12:58 |
| rogpeppe | niemeyer: as far as i've seen | 12:58 |
| rogpeppe | niemeyer: this at least will show if someone does a recursive grep for Series | 12:58 |
| niemeyer | rogpeppe: My point is that this isn't a special place.. there are tons of places one will not understand, and this isn't documenting them | 12:58 |
| Aram | rogpeppe: why not copy some known existing lsb-release files and test against those, that way the test is meaningful on every platform? | 12:59 |
| niemeyer | rogpeppe: But sure, I don't mind too much either | 12:59 |
| Aram | and that way you don't need to care about lsb_release at all. | 12:59 |
| niemeyer | Aram: It is doing that | 12:59 |
| rogpeppe | niemeyer: it's reasonably special i think. it's actually the only place AFAIK that connects the actual running release with the term. | 12:59 |
| niemeyer | rogpeppe: Nevermind.. comments is great, thank you | 13:00 |
| rogpeppe | Aram: i did that. i could do with a few more samples though. feel free to add to the tests table. | 13:00 |
| Aram | oh. | 13:00 |
| rogpeppe | niemeyer: thanks :-) | 13:00 |
| * Aram finds Rietveld hard to read. | 13:00 | |
| * rogpeppe actually made up the quantal lsb-release contents BTW | 13:02 | |
| rogpeppe | ha, of course the tests fail when CurrentSeries="unknown" anyway | 13:08 |
| rogpeppe | hmm, just saw this: | 13:13 |
| rogpeppe | runtime: signal received on thread not created by Go. | 13:13 |
| rogpeppe | FAILlaunchpad.net/juju/go/state8.131s | 13:13 |
| rogpeppe | that's a little worrying | 13:14 |
| rogpeppe | can't reproduce though | 13:15 |
| Aram | probably from zookeeper? | 13:21 |
| TheMue | Ah, redesign looks nicer and builds, now adopt to tests. | 13:35 |
| niemeyer | Aram: Probably.. which means we'll solve it as a side effect, hopefully | 13:56 |
| niemeyer | Aram: Are you up to come on Thursday still? | 14:04 |
| Aram | niemeyer: I am not sure... I'd like to. I haven't heard anything from BTS though, I don't know what that means. | 14:08 |
| niemeyer | Aram: They've returned to me this morning | 14:08 |
| niemeyer | Aram: and we got approval just now | 14:08 |
| niemeyer | Aram: I've asked for a second option, though | 14:09 |
| niemeyer | Aram: Since the option they gave was coming early Thursday and returning early Friday | 14:09 |
| niemeyer | Aram: If you're returning early friday, may as well stay for the day | 14:09 |
| Aram | indeed. | 14:09 |
| Aram | early thursday -> late friday would be prefereable. | 14:10 |
| niemeyer | Aram: That's what I asked for.. let's see if they return and I'll put you back on the loop with a +1 | 14:11 |
| Aram | ok, assuming the feedback is positive, what's the plan? who buys the tickets, me or the company? | 14:12 |
| Aram | hi robbiew. | 14:12 |
| robbiew | Aram: hey! :) | 14:12 |
| robbiew | Aram: company buys the tickets.../me assumes he knows what this conversation is about | 14:12 |
| Aram | ok :). | 14:13 |
| niemeyer | robbiew: Yes :) | 14:15 |
| niemeyer | Aram: The agency will sort out for it | 14:15 |
| === Guest__ is now known as smaddock | ||
| rogpeppe | niemeyer: would it be good for me to come down too, if Aram makes it over? | 15:08 |
| niemeyer | rogpeppe: I'm not entirely sure.. let's see how the sprint here looks like | 15:09 |
| niemeyer | rogpeppe: Let's sync up on that again tomorrow | 15:09 |
| rogpeppe | niemeyer: k | 15:09 |
| Aram | I believe I'm just waiting for the e-ticket confirmation now. | 15:16 |
| Aram | rogpeppe: do you happen to know if Maestro cards work in the UK? | 15:19 |
| Aram | work as in "being widespread", I'm sure if I try hard enough I'll find ATMs. | 15:20 |
| rogpeppe | Aram: probably. | 15:20 |
| rogpeppe | Aram: it's mastercard, right? | 15:20 |
| Aram | not really. it's owned by mastercard, but it's a different product. | 15:21 |
| Aram | here in austria mastercard is the only widespread card that works. good luck with visa/mastercard. | 15:21 |
| Aram | almost nobody accepts them, | 15:21 |
| Aram | s/mastercard/maestro/ | 15:21 |
| Aram | meh | 15:21 |
| Aram | I'll rephrase :) | 15:21 |
| Aram | here in austria *maestro* is the only widespread card that works. good luck with visa/mastercard. | 15:22 |
| rogpeppe | Aram: ah, i've never had any problems with visa. but then again i haven't spent any time in austria :-) | 15:23 |
| fwereade | Aram, fwiw I'm used to seeing maestro symbols on ATMs in the UK | 15:28 |
| Aram | greta | 15:28 |
| Aram | great | 15:28 |
| rogpeppe | fwereade: you've got a couple of reviews | 15:40 |
| fwereade | rogpeppe, sweet, tyvm | 15:45 |
| fwereade | gn all, need to be off promptly tonight | 16:03 |
| fwereade | take care :) | 16:03 |
| * Aram is away for an hour or so. | 16:15 | |
| rogpeppe | fwereade: ok. gn. | 16:43 |
| * rogpeppe is done for the day. see you tomorrow... | 17:04 | |
| * Aram back. | 17:38 | |
| TheMue | niemeyer: Thx for LGTM, goes in now. | 18:08 |
| niemeyer | TheMue: Cheers! | 18:20 |
| niemeyer | and I really need some food now | 18:20 |
| niemeyer | I'll see you all later/tomorrow! | 18:20 |
| TheMue | niemeyer: Enjoy. | 18:21 |
| Aram | rogpeppe: do you use upas? | 19:00 |
| hazmat | rogpeppe, the extracted charm is separate for multiple units | 19:15 |
| hazmat | the download directory is the same as its merely a cache | 19:16 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!