[00:12] thumper: these spurious failures have suddenly gotten a lot worse - i'm onto my third landing attempt [00:12] yeah... :( [01:13] * wallyworld_ -> doctor, bbiab [04:28] wallyworld_: sorry I didn't get to the reviews, lots of intro stuff with waigani and then collecting the dog from the vet [04:28] no problemo [04:28] wallyworld_: if you are still short tomorrow morning I can dedicate time to it [04:28] * thumper off to make dinner [04:28] ok, hopefully not :-) [07:05] morning [07:06] morning dimitern, I'm not used to seeing you this early [07:06] did your Timezone change? [07:06] jam, yes, now +1h from before [07:06] makes sense [07:07] jam, our 1-1 is in 1h, right? [07:08] yep [07:08] does Google have your right TZ now that you've moved? [07:08] if it works for you, we can go earlier next week [07:09] it was a struggle, but I found how to adjust my TZ in google, yes [07:10] well, if it works for you as it is, i'd prefer to leave it, so that I can do some work in the morning on mondays before the meeting :) [07:11] I'd like to go earlier, because it gives a gap before the next call. but I don't think we usually take the full hour anyway [07:12] ok then, let's try it provisionally for next week? [07:38] dimitern: I'm happy to split the difference, and go for 30min, that still gives me a gap, but gives you some time [08:01] dimitern: I'm there whenever you're around [08:01] jam, coming [08:05] dimitern: you're stream just hung, can you hear me? [08:29] mornin' all [08:50] morning rogpeppe [08:50] jam: hiya === axw__ is now known as axw [09:02] rogpeppe: poke about our 1:1 ? [09:02] ha! [09:02] one mo [09:35] fwereade: thx for feedback, that tag argument sounds reasonable to me, that's indeed a better way, yes. [09:36] fwereade: do you prefer a time based line dropping over a line number based? will change it then. [09:49] TheMue, yeah, it feels like maybe a general problem with watchers -- that they can be left running by a client that doesn't make regular next calls [09:50] TheMue, may be neater to separate out a solution to that and leave a line limit in place for this CL [09:51] TheMue, can you write a bug about the watchers being abandonable? [09:54] fwereade: yep, will do [09:55] fwereade: i think to keep the api stable there should be no argument for line limit (or time later) but a constant (or a general configurable value?) [10:00] TheMue, let's make it a generous constant for now [10:01] fwereade: ok [10:06] mornin' [10:09] mgz: morning! [10:09] 1:1 ? [10:10] jam: mumble? [10:10] joining now [10:46] mgz: standup? [10:46] rogpeppe: ^^ [11:13] Good morning jujuers [11:14] * niemeyer is back from holidays [11:15] niemeyer, welcome back [11:21] dimitern: Thanks! [11:36] natefinch: 1:1? [11:36] jam yep [11:47] * dimitern lunch [11:50] fwereade: thoughts on git addall returning an error when nothing added for git 1.8.5 (used on trusty) where on earlier versions it did not error in the same situation? Not sure if that's something we depend on in the code. [12:26] natefinch, ah yeah [12:26] natefinch, I'm not sure *exactly* why that test is there, but it has the ring of somthinh that mightbe important [12:26] natefinch, might it be something to do with restarts at unexpected times? [12:27] natefinch, actually [12:27] natefinch, AddAll must surely be valid with no changes [12:27] natefinch, we do it at the end of every hook [12:27] natefinch, whether or not the charm wrote anything or not [12:27] natefinch, does that apply? [12:28] fwereade: yep, that makes it clear I need to swallow the error [13:34] fwereade, ping [13:35] fwereade, when you have some time perhaps we can go over the API document and verify if it makes sense (I'm done with what we discussed last week I think) [13:35] fwereade, rogpeppe: Code added to squelch addall error: https://codereview.appspot.com/49470047 [13:54] hazmat, ping [13:55] hazmat, i'm not sure what's not clear with the API specification goals - bulk operations are described, and ease of use from the client is not terribly reduced (not much more so than for agents) [14:05] could somebody please have a look here: https://code.launchpad.net/~adeuring/juju-core/1117173/+merge/201417 ? [14:06] adeuring, looking [14:06] dimitern: thanks! [14:07] dimitern: also this link https://codereview.appspot.com/51280045 [14:07] adeuring, ah, nicer, thanks [14:15] adeuring, reviewed; please link the branch to bug 1117173 [14:15] <_mup_> Bug #1117173: Validating config could have better errors [14:15] dimitern: thanks! [15:21] dimitern, fwereade, jam, natefinch: review anyone? it's just an upgrade to checkers.DeepEquals, but it's saved lots of time for me, so i'd like to integrate it. https://codereview.appspot.com/51480043/ [15:23] rogpeppe, i'll take a look in m [15:23] 10 minutes [15:23] dimitern: thanks [15:28] rogpeppe, LGTM [15:28] dimitern: ta! [15:30] dimitern: sorry about the lack of specific tests, but this is just test code - we will see if there are problems. i don't want to spend any more time on it, if that's ok [15:30] rogpeppe: I can review it [15:30] rogpeppe: bah, missed that dimitern already did [15:30] natefinch: np, thanks anyway [15:30] rogpeppe, it's not absolutely necessary, but it would be nice - esp. to show off the better error messages ;) [15:31] dimitern: oh ok then :-) [15:32] rogpeppe, cheers! [15:34] rogpeppe: I'm worried about nil slice == empty slice. I know it's handy a lot of the time, but sometimes they mean different things. === dames is now known as thedac [15:50] rogpeppe: natefinch: DeepSimilar ? [15:50] jam: DeepCloseEnough? [15:51] natefinch: if you can think of a concrete instance where we care, i'd like to know. it's caused us far too much pain in the past, and some of our tests are contorted because of it [15:52] rogpeppe: I know, I know. I have done the contortions, and it's a pain in the butt. I don't know of a specific case. [15:52] rogpeppe: maybe we can make a general guideline of "please don't do that" for relying on nil vs empty slices [15:52] natefinch: agreed [15:53] rogpeppe: and if you need it, well, then you're stuck DeepEquals, and good luck [16:08] dimitern: i've added error messages to all the tests [16:36] natefinch: how close are you to landing https://codereview.appspot.com/49470047/ ? [16:37] rogpeppe: should be in the process thereof [16:38] natefinch: great [16:48] rogpeppe: foiled by my own flaky mongo tests..... I'll repropose. Maybe I should be working with fwereade on getting tests to pass reliably. (also need to get the mongo Tag stuff in, which is also failing on the bot due to flaky tests) [16:49] natefinch: i can't get tests to pass on my machine currently [16:49] rogpeppe: dang... [16:49] natefinch: i think i might work on getting tests to pass reliably - it's taking too much of my time as it is [16:50] rogpeppe: definitely a problem. Sorry for the delays it has caused... they pass really reliably on my machine :/ [16:51] rogpeppe: the mongo replica set tests, at least [16:51] natefinch: the replicaset tests weren't the ones that were failing for me [16:52] natefinch: i'm getting lots of "Waiting for sockets to die" [16:52] rogpeppe: oh, well, nevermind then :) The spurious failure I just had with the git branch was with the replica set tests.... [16:52] rogpeppe: oh yeah, I see that all the time. Annoying. [16:52] natefinch: i still can't repro it reliably [16:54] rogpeppe: me either... but it happens pretty frequently for me, like 30% of the time, maybe? [17:06] sinzui, I should have qualified my bug report re local provider terminate-machine - thats with 1.17.0 [17:07] jamespage, it is always helpful. I will note that and add it to 1.17.1 [17:13] rogpeppe: that fix to the git tests just landed btw [17:13] rogpeppe: make your life a little bit easier at least [17:14] natefinch: thanks [17:14] natefinch: how's the replicaset branch? [17:15] rogpeppe: just looking at it now. there's a couple tests that failed last time on the bot that I'm trying to make more reliable [17:39] anyone fancy giving this a review? https://codereview.appspot.com/49920045/ [17:39] natefinch: i think you said you'd have a look last night - did you have any unpublished comments? [17:42] rogpeppe: sorry, I got halfway through. I'll finish the rest of it right now [17:42] natefinch: np [17:42] natefinch: i'm thinking about renaming "candidate" to "wantsVote" BTW [17:43] rogpeppe: that seems clearer to me, yeah [17:44] natefinch: consider it done [17:58] fwereade: ping [18:00] rogpeppe: there's no difference between make(map[string]string) and map[string]string{} right?' [18:00] natefinch: that's right [18:01] rogpeppe: I thought so, but then managed to convince myself I might be wrong. [18:01] natefinch: personally i think that when initialising an empty map, the former is marginally clearer because you see the "make" right at the start of the expression [18:11] rogpeppe: I like the latter because there's less garbage in the way of the type... the make and the parens just obscure the type for me. Also, it's how the rest of the types are initialized, and there's really no other reason for map[x]y to be in an assignment except if you're making a new one. Plus it's just fewer characters. But, I don't really care that much. [18:11] natefinch: i use make for making slices too [18:12] rogpeppe: I use make only when need to set length or cap [18:12] natefinch: me too [18:12] natefinch: otherwise just var x []int [19:36] natefinch: i've updated that CL if you want to take another look. https://codereview.appspot.com/49920045 [19:37] rogpeppe: cool, looking [19:37] natefinch: one additional change i made was to take mongoPort out of peerGroupInfo, which makes it possible to have machines with different ports for testing [19:38] rogpeppe: nice [19:42] rogpeppe: I think I saw Dave had a min/max package that had specific functions for each numeric type... but I can't find it now [19:43] natefinch: i don't think that was seriously intended [19:43] natefinch: i couldn't care less about reimplementing min [19:43] rogpeppe: right [19:46] natefinch: hmm, those tests should not be passing [19:46] rogpeppe: that sounds bad [19:47] natefinch: it's not bad as such, but it makes me worried there might be a go bug [19:47] hi natefinch, rogpeppe [19:47] thumper: yo! [19:47] o/ thumper [19:47] thumper: happy new year! [19:47] I have a question for you two [19:47] I was trying to help waigani with lbox yesterday [19:47] new guy [19:48] but we couldn't get it logging in right [19:48] it has been too long since I set up mine [19:48] is there a step we are missing? [19:48] thumper: I had to log in with my gmail account, couldn't do it with my canonical account for whatever reason. [19:49] hmm... [19:49] natefinch: did it prompt for the password? [19:49] rogpeppe: yep [19:49] waigani: meet rogpeppe and natefinch [19:49] natefinch: sorry, i meant to address that to thumper [19:50] waigani: hello there [19:50] rogpeppe: or rather, it does now. I don't know about using my canonical address since that was 6 months ago at this point [19:50] rogpeppe: yeah, the password prompt came up [19:50] waigani: howdy [19:50] rogpeppe: but it kept saying it was wrong [19:54] thumper: I think that's what happened to me. I never did figure it out. [19:55] natefinch: i've got to go now, but please ponder this conundrum: if map iteration order is random, how come the map iteration over members at the end of desiredPeerGroup is always returning a slice in the same (expected) order? [19:55] natefinch: it's really weird, and it feels like it just might be a golang bug, although that would be most unexpected [19:56] rogpeppe: hrm... I had thought they purposely made map iteration random so people couldn't depend on it, even though there's really no reason for it to be random in the current implementation [19:56] natefinch: *exactly* [19:56] natefinch: so why are my tests passing reliably? [19:56] natefinch: (i made a very simple test to verify that it doesn't happen for all maps) [19:57] anyway, gotta go [19:57] g'night all [19:57] g/night [19:58] natefinch: as far as ordering goes, what you get order is different from what is guaranteed [19:58] if the language doesn't define an order [19:58] the language implementation can change, and ordering will change, and the language lawyers can say "we did nothing wrong" [19:59] thumper: yes, that's why they made map iteration non-deterministic. However, roger was saying that his code reliably turns a map into the same slice, despite that fact. [20:00] so for now it may just be a happy coincidence [20:00] but we shouldn't rely on that fact [20:00] thumper: right, but his tests are relying on it, I think is the problem [20:03] natefinch: do all the tests pass on trusty now? [20:03] natefinch: if they do, I may upgrade [20:04] thumper: not sure. I'm on saucy still, just had the new git for whatever reason [20:06] ah [20:06] should ask rog I guess [20:06] he is on trusty [20:06] I think [20:06] thumper: yep, he is [20:45] hi thumper. I am not sure bug 1268689 is a Juju issue. It might be cloud-init, or possible the cloud-archive packages. What say you? [20:45] <_mup_> Bug #1268689: juju on 12.04 can't install packages in lxc containers [20:46] sinzui: otp, will look shortly [21:18] sinzui: looked [21:18] sinzui: it reminds me of an issue we have had before [21:19] sinzui: where the default packages failed to install correctly [21:19] normally an intermittent failure [21:19] due to updates in the archive [21:19] thank you thumper. [21:23] sinzui: can I get you to add ~waigani to the ~juju team plz? [21:25] thumper, done [21:37] sinzui: ta [22:52] waigani, welcome [22:52] waigani, sorry I wasn't around yesterday [22:52] hi thumper [22:52] fwereade: hello :) [22:53] i've spent the morning deprogramming my osX habits and getting use to Ubuntu [22:54] installed on macbook pro - a few drivers and cards issues to work through. but it all seems to be working now. [22:54] fwereade: hi, I'm just off to the gym [22:55] waigani, cool === thumper is now known as thumper-gym