[00:00] davecheney: thanks! [00:27] thumper: do you also not want the username quoted in the error returned by the apiserver? [00:28] I think quoted is fine from the api server as it is developer facing [00:29] thumper: yep, wrote too quickly - I see we use %q in the rest of the errors in that package [04:36] wine time [04:41] wallyworld: thanks for the review. I've responded to your comments, but can't seem to update my diff. [04:41] waigani: i saw the replies, so marked at +1 [04:42] wallyworld: okay thanks [04:42] np [06:43] dimitern: heya [06:43] wallyworld, morning [06:43] god weekend? i hope you gots sleep :-) [06:43] good [06:44] wallyworld, :) ~18h in total [06:44] wow [06:45] i have a question - kat finished some goamz signing work, and it's now merged. but it looks like stuff is missing in the v3 branch, i've done a pr https://github.com/go-amz/amz/pull/33 [06:46] i'm testing the storage stuff live, but was wondering if you could test the network stuff as i don't have enough to go on with what to test [06:47] wallyworld, yeah - I was just looking at your two PRs in amz.v3 after v3-unstable was promoted to v3 [06:48] i've pull her juju-core branch to test juju live katco-:goamz-v3-support [06:49] wallyworld, I thought I *did* compare v2 to v3 to see if something was missing but apparently I missed something [06:55] dimitern: stupid irc dropped out, not sure if i missed any reply [06:56] wallyworld, I was looking at https://github.com/go-amz/amz/compare/v1...v2 and https://github.com/go-amz/amz/compare/v2...v3 [06:56] yeah, the v2..v3 diff what what i based the pr on [06:57] wallyworld, but I can't see the changes in the PR to be missing from v3? [06:58] hmm, maybe i had an out of date local copy [06:58] let me check [06:58] wallyworld, that's might be - esp. if you're using symlinks in your gopath [06:59] hmm, i just git pulled in my v3 master and no updates [06:59] i'll look around a bit [07:01] dimitern: so as an example, in https://github.com/go-amz/amz/tree/v3/ec2 there's no blockdevicemappings_test.go [07:01] that file should be there and is in v2 [07:02] wallyworld, thats true, but why it doesn't show up on the v2..v3 diff? [07:02] weird [07:03] yeah, and there's a bunch of network stuff missing too [07:03] wallyworld, ok, I'll do the diff locally to be sure [07:03] ok [07:03] wallyworld, apparently github compare lies [07:04] there must be a logical reason you'd think [07:07] * dimitern keeps digging [07:18] wallyworld, for some reason even though v3 was branched off v2 some commits in v2 are missing [07:18] dimitern: fwiw, with the go-amz branch in pr 33, the new juju storage stuff works live, and the unit tests pass. the networking stuff fails live for me because of vpc limits [07:18] hmm [07:19] wallyworld, can connect to the ec2 web ui with the shared creds or you just have the api keys? [07:19] i never use the web ui, just ElasticFox [07:20] i have the api keys also for juju [07:20] wallyworld, you can clean up the stale vpc from there [07:21] wallyworld, if you have the account to login to the web ui can you send them to me by mail along with the api keys? [07:21] ok, i'll see if i have it [07:23] wallyworld, in the PR #33 there are still some things missing from v2 btw [07:23] ah, ok [07:24] wallyworld, but not much, so if you go ahead and merge that, I'll propose a follow-up to add the missing [07:27] dimitern: ok. i have access to a web ui, using my canonical.com email as the user name, but it appears to be a different account to that controlled using the api keys i have and which i use with elastic fox [07:28] dimitern: ok, that's merged [07:28] wallyworld, ok, I'll ask jam if he has them [07:28] wallyworld, thanks! [07:28] dimitern: once your stuff lands, i'll update a fork of kath's branch i have and land that in core [07:29] wallyworld, ok, will let you know [07:29] ok, i might duck off to have dinner [08:27] good morning devs o/ [08:27] I'm writing my first charm and having some problems, can anybody help me? [08:33] Muntaner, morning! try asking in #juju [08:33] for all your charming needs :) [08:33] dimitern, ty ;) [08:33] morning [08:37] dimitern, TheMue: morning [08:38] TheMue, dooferlad, morning folks! [08:38] dooferlad: dimitern: o/ [08:38] dimitern: heard anything from voidspace? [08:39] dooferlad, he become a dad over the weekend [08:39] :) [08:40] dimitern: awesome! [08:40] aaah, fantastic news [08:40] so I guess he won't be here today [08:40] yeah indeed :) [08:40] indeed [08:40] I've seen pics on FB [08:41] oh, dedn't know he's on FB, so far only G+. while have a look [08:43] found and added him ;) [08:54] dimitern: sorry I misesd you earlier, just missed the schedule. what's up with ec2? [08:55] wallyworld: maybe you know? [08:55] jam, minor mishap with some missing commits from amz.v2 into amz.v3, but wallyworld sorted that out [08:55] dimitern: k, I thought there was something you needed w VPC [08:55] jam, I'm now manually comparing amz.v2 to the updated amz.v3 to make sure all is good, then I'll do a live test [08:56] dimitern: I do see a spare network interface in us-east-1 [09:00] TheMue, sorry, I'll be 10m late for our 1:1 [09:01] dimitern: ok [09:06] wallyworld, jam, I'm happy to report after that PR #33 landed amz.v3 has everything is needs wrt storage and networking [09:06] I'll still need to do a live test later though [09:12] TheMue, I'm in the hangout [09:12] dimitern: coming [09:38] axw, katco, jam, wallyworld, is anyone using the shared aws account for testing now? [09:38] I'm thinking of cleaning up the stale VPCs, subnets, security groups, etc. [09:39] unless anyone responds in the next half hour, I'll go ahead and do it [09:48] dimitern: for me go for it [09:49] perrito666, +1 [10:11] dimitern: I'm using eu-west-1 for a live service [10:11] (my IRC proxy) [10:11] but nothing in US-east-1 [10:11] jam, ok [10:41] dimitern: sorry, had to go down to soccer at short notice [10:42] wallyworld, np. s'all good :) [10:42] dimitern: once you're happy with goaws, I'll land a branch to update core [10:43] wallyworld, I still need to do a live test, so I'll let you know; but looking at the code it should work [10:43] ok, sounds good [10:43] i did a storage live test and it was good too [10:44] wallyworld, cool! [10:59] morning [11:04] FYI all leftovers in the shared aws account where cleaned up for all regions (jam's instance is unaffected ofc) [11:05] we should have a script to do that === Murali_ is now known as Murali [11:08] perrito666: o/ === Murali_ is now known as Murali [11:35] dimitern: hangout? [11:40] dooferlad, omw, sorry [11:40] dimitern: no worries! [11:42] dooferlad, i'm in the hangout btw [13:11] Bug #1427204 was filed: systemd service tests map ordering failures [13:15] Bug #1427210 was filed: 'relative path in ExecStart not valid' vivid local deploy failure [13:16] I have filed that one as a blocker, not the map ordering test failures though [13:16] will poke eric when he's on about 'em [13:30] dooferlad, ping [13:31] dimitern: hi [13:31] dooferlad, I knew it there will be a ci bug reported for that map ordering thing ^^ [13:31] dooferlad, how's that going ? [13:32] dimitern: it is happening... [13:33] dooferlad, did you file a bug? that 1427204 one above should be a duplicate of yours [13:33] dimitern: I did. [13:33] https://bugs.launchpad.net/juju/+bug/1427149 [13:33] Bug #1427149: Tests require predictable map ordering [13:34] bother, wrong project [13:34] Bug #1427149 was filed: Tests require predictable map ordering [13:35] dooferlad, it's the right one I think [13:35] dimitern: it is now. [13:35] Bug #1427204 changed: systemd service tests map ordering failures [13:35] dooferlad, ah, ok [13:36] mgz, dooferlad is already on the map ordering one, so I'll mark the 1427204 as dupe [13:36] dimitern: already have [13:36] dooferlad, yeah, I was just about to say that :) [13:38] ah, pyjuju, is why I didn't see it [13:56] TheMue, you have a review btw [13:56] dimitern: great, thank you === Murali_ is now known as Murali [14:00] dooferlad: forgot to check with you, you also get the four failures in service/systemd right? the StubCall one is a bit hard to parse but I assume is also map-related rather than something else [14:01] mgz: yes [14:03] axw, are you there by any chance? [14:04] wallyworld__, ping [14:04] yo [14:04] wallyworld__, so the goamz live tests pass (so far) except for this - http://paste.ubuntu.com/10501880/ [14:05] wallyworld__, which looks like the check needs .* before and after [14:05] hmmm, ok, i thought it passed before, maybe not [14:07] wallyworld__, but the networking stuff seems unbroken [14:07] so do you have any pending changes to commit to goamz? [14:07] wallyworld__, not right now (I have some I'll do later, but not code related) [14:08] ok, i'll fix that test [14:09] wallyworld__, cheers [14:10] dimitern: i just ran that test with --amazon and it passed for me [14:11] maybe it fails when run with other tests [14:11] wallyworld__, "--" instead of "-" ? [14:11] it complained tht it wanted ec creds [14:11] let me try again [14:12] wallyworld__, it should take a few minutes - if it passes in a few seconds only the local live tests were run [14:12] even for one test [14:12] maybe gocheck.f messes with the flag [14:13] depends on the test [14:13] it shouldn't [14:13] i ran go test -gocheck.f TestBlockDeviceMappings -amazon [14:13] maybe -amazon needs to be first [14:14] still passes [14:14] I run go test -check.v -check.f TestBlockDeviceMappings -amazon and it passed [14:15] ok, trying ./... [14:15] so it could be flaky [14:24] dimitern: i got 5 vpc related failures but no block ones [14:25] so yeah, looks flakey [14:29] wallyworld__, I'll have a look [14:31] dimitern: i think though the latest goamz rev is good to use with juju core [14:31] wallyworld__, I agree [14:35] dimitern: this should do it - it's what i've tested live juju deployments with http://reviews.vapour.ws/r/1046/ [14:35] dimitern: just heads up https://bugs.launchpad.net/juju-deployer/+bug/1421315 confirms it's between beta 3 and 4 [14:35] Bug #1421315: subordinate service not appearing in watch output [14:37] rick_h_, good to know - it makes it easier to track, thanks [14:38] sinzui: can we get ^ marked as a beta regression then and a blocker for release? [14:40] rick_h_, you mean 1.22-beta4 is broken and we need a 1.22-beta5 [14:40] sinzui: yes [14:40] thank you [14:40] sinzui: yes please [14:40] sinzui: and we can help QA and verify that beta5 fixes the issue before release [14:41] sinzui: vs the current medium status on the bug [14:41] sinzui: any public info i can watch to track the status of deployer in core qa? [14:42] hazmat, no, sorry, but after my meeting, I will be able to report where we are with deployer revision testing [14:42] sinzui: thanks [14:49] dimitern: i need sleep, if you are happy with the goamz update to core, can you $$merge$$ it for me? [14:51] wallyworld__, will do, np [14:51] ty [15:04] ericsnow, hey [15:04] ericsnow, can you take care of this bug please? https://bugs.launchpad.net/juju-core/+bug/1427210 [15:04] Bug #1427210: 'relative path in ExecStart not valid' vivid local deploy failure [15:05] dimitern: yep [15:05] dimitern: first on my list :) [15:05] ericsnow, cheers :) [15:05] perrito666: standup? [15:05] ericsnow, the other one - with the map ordering dooferlad is already fixing and I asked him to check in with you when done [15:07] jrwren: can you help dimitern https://bugs.launchpad.net/bugs/1421315 with the steps you used to reproduce please? [15:07] Bug #1421315: subordinate service not appearing in watch output [15:07] jrwren: if you have the websocket frames in a pastebin/etc even sweeter [15:18] rick_h_: I have the websocket frames in a screenshot. I'll share doc. [15:18] jrwren: ty [15:28] jrwren, rick_h_, thanks for sharing the document, but this still doesn't show the issue [15:29] jrwren: I'm not seeing the beta4 screenshot [15:30] dimitern: basically the images highlight how the allwatcher sent the info about the nrpe charm in the watcher output [15:30] dimitern: and in beta4 that is no longer sent [15:31] rick_h_, sorry, but I'd rather have logs I can search in than a screenshot of half a log [15:32] dimitern: right, understand. It was the easiest way I could mention jrwren to QA it as I know how to watch the allwatcher from the websocket the gui manages so this is from a browser session of watcher events [15:32] rick_h_, ok, it will be great if those dumps are available somewhere as well [15:33] jrwren, ^^ [15:33] ericsnow: I assumed standup was postponed [15:34] perrito666: k [15:35] perrito666: ah, I missed Nate's email :) [15:36] rick_h_: I didn't add beta4 screenshot as it is identical to the others. [15:37] dimitern: Yes, doesn't show the issue. Still trying to repro. [15:37] jrwren, ah, sorry I though you already did [15:38] dimitern: No, I'm guessing this regression is only in master. I've not built master yet, so I cannot confirm. [15:39] dimitern: It is not in any released version that I've tested, and I've tested all current released versions AFAIK [15:39] jrwren, not even in 1.22-beta4? that was proposed for release [15:39] dimitern: this morning i confirmed it is not in 1.22-beta4 [15:40] jrwren, ok [15:41] rick_h_, ^^ [15:41] dimitern: ugh. Typo in my lp comment. I added another comment. [15:41] jrwren, no worries, thanks for clarifying [15:42] jrwren: oh, important typo lol [15:43] jrwren: dimitern ok, so we need to check with the original bug author and confirm what juju he's using [15:44] jrwren: dimitern because I'm doubting he's building trunk? [15:44] hazmat: did you replicate the subordinate bug and if so on which version of juju? ^ [15:45] dimitern: have you done the live testing? I now have an interesting race condition in state/action_test.go:374 [15:45] rick_h_: i didn't, i just read the log output of deployer, its deployed a subordinate, service waited 5s, and does a watch, and the sub isn't in the output [15:46] hazmat: ok, ty. [15:47] Bug #1427257 was filed: Juju backup doesn't contain .juju files [15:47] so might be more a race/timing issue where we didn't replicate that with the gui because we weren't checking the time there. [15:48] dimitern: if I run the state tests directly in my VM they pass, but when doing it via ssh this test above fails [15:48] TheMue, I'm doing it now [15:52] TheMue, what do you mean via ssh? [15:53] dimitern: I've got a VM running my test system in. when I go in directly it passes. but from inside the editor on the host system I can do a "ssh themue@192.168.2.210 '~/bin/jdt test state'" [15:54] dimitern: here jdt is the script I told you about [15:54] dimitern: inside the VM I'm simply doing a "jdt test state", so that's not the reason [15:55] dimitern: I think the output via SSH back to the editor slows the tests a bit down and that's why the behavior here is different from doing it directly [15:55] TheMue, could be something ssh-related - try using -v [15:56] dimitern: will do [15:59] dimitern: same result. so would be interesting how testing state passed for you [15:59] dimitern: the latest changes here only have been the comments like in the review [16:00] rick_h_, I am confused by the comments in lp 1421315 [16:01] it is marked as critical but is not broken in 1.22-beta4? [16:01] alexisb: heh you and me both. Sorry, our guy said he confirmed it but then found out it was not true [16:01] dimitern, rick_h_ am I reading something wrong? [16:01] alexisb: so in between we had it run up the flag pole as a breakage in beta4 [16:01] in the lsat 15 minutes :) [16:01] alexisb: yep [16:01] it is going to be a fun monday [16:01] alexisb: so now we're working it out and reevaluating atm [16:01] hazmat, as always thanks for your help [16:02] alexisb, not more than I am I guess :) [16:02] rick_h_, ack, just keep the bug updated and we will stay on it [16:02] but at this point I am not sure what our next step is given the information :) [16:02] alexisb: will do, standup atm and will bring it up and update [16:02] thnx [16:03] rick_h_: yeah.. if it its not reconfirmed, then not sure.. i'm basically booked for the next 36 hrs re trying to reproduce myself, might want to reach out to the oil guys [16:05] TheMue, good news [16:05] TheMue, so far I couldn't manage to reproduce the issue with your fix [16:05] dimitern: aaaaaah [16:05] dimitern: \o/ [16:09] TheMue, yep, so far so good, now I'm retrying the same steps without your fix [16:09] dimitern: interested in the results [16:13] dimitern / TheMue: I need some inspiration with how to fix a test. Can either of you jump in a hangout for a while? [16:13] mm, these automated travel services would be so much better if you could specify an arrival date instead of departure [16:13] dooferlad, sure, just give me 2m [16:13] dooferlad: sure [16:14] dimitern, TheMue: Thanks guys. [16:14] dimitern, TheMue: The usual one that we use for the standup? [16:15] dooferlad: would say so [16:16] TheMue, confirmed! [16:16] TheMue, I managed to reproduce the issue on 1.22 without your fix [16:16] dimitern: fantastic [16:37] TheMue, you have LGTM [16:37] dimitern: great, thx, port it to 1.23 then [16:37] TheMue, +1 [17:00] so natefinch back? [17:01] perrito666: yep [17:02] so ericsnow natefinch wwitzel3 do we staandup or that already happened? [17:02] perrito666: we can do that now if they're available [17:02] natefinch: sure [17:03] * perrito666 took the 2 hs thing literally [17:03] perrito666: haha [17:03] perrito666: I'm rarely that exact :) [17:21] Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 [17:22] dimitern: https://github.com/juju/juju/compare/master...dooferlad:master-map-ordering-tests?expand=1 [17:25] dooferlad, this looks good to me - go ahead and propose it and ask ericsnow to have a look please [17:26] dimitern: I need to stop for the day in a moment, so I will propose, but if it needs to land today someone else may have to $$prod$$ on github [17:27] dooferlad, sure, that's ok [17:27] dimitern: I am seeing some failures in environs/manual, but I don't know if they are related. [17:27] dooferlad, paste? [17:28] dimitern: http://pastebin.ubuntu.com/10503991/ [17:29] dooferlad, no I don't believe these are related [17:31] dimitern, ericsnow: http://reviews.vapour.ws/r/1048/ (should) fix bug #1427149 [17:31] Bug #1427149: Tests require predictable map ordering [17:31] * ericsnow is looking [17:32] dimitern: I will keep an eye on my email, but assume no fast response until tomorrow. Have a good evening! [17:32] dooferlad, cheers, same to you! [17:57] !QUESTION: Why does the local.jenv file have multiple entries for the state server "localhost" and "10.0.3.1" (by default) - why not just use the 10.0.3.1 address? is this something to work around the snowflakeness of the local provider? [17:57] lazyPower: In-com-pre-hen-si-ble-ness. [17:57] mup: botsnack [17:57] lazyPower: Roses are red, violets are blue, and I don't understand what you just said. [18:08] Would like a review of http://reviews.vapour.ws/r/1050/. It's the port of fix #1425435 from 1.22 to master. [18:08] Bug #1425435: juju-deployer/jujuclient incompatibility with 1.21.3 [18:08] dooferlad: done [18:09] lazyPower, 1) it is; 2) because localhost is special in case of ipv4 vs ipv6 [18:09] aahhh ok ty for the explanation [18:09] :) [18:09] dimitern: I have a patch up for lp-1427210: http://reviews.vapour.ws/r/1047/ [18:09] ericsnow, looking [18:10] dimitern: thanks [18:12] dimitern: Fair enough about localhost working across IPv4 and IPv6, but couldn't that be handled when the .jenv file is created? Or is there some other specialness that I'm unaware of? [18:13] cory_fu, I suppose it can [18:14] dimitern: The use-case I'm investigating is attempting to connect to an already bootstrapped local provider from within a container, for review and CI. I was able to get juju status to work (briefly) by removing the localhost entry, but the .jenv file gets re-written periodically which re-adds the localhost entry [18:15] ericsnow, reviewed [18:15] dimitern: thanks [18:16] cory_fu, that's because the local provider insists on reporting localhost as one of its endpoints [18:16] dimitern: the ported fix is available for review too [18:16] cory_fu, I can't quite recall why, but there was some other good reason - ask thumper [18:16] TheMue, cheers, will have a look [18:17] dimitern: great, thanks [18:18] Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 [18:21] Bug #1427302 was filed: failed to retrieve the template to clone: lxc container 1.21.3 [18:29] Bug #1427302 changed: failed to retrieve the template to clone: lxc container 1.21.3 [18:36] dimitern: seen your review, thx already [18:36] TheMue, np :) [18:49] Bug #1427342 was filed: juju package should have strict version dep with juju-core [19:03] natefinch, dimitern, someone landed a change to 1.22 without first landing 1.22-beta5 version. CI knows the version is released [19:04] natefinch, dimitern I am trying to merge the 1.22-beta5 branch to satisfy CI [19:05] sinzui: are you saying no code should have been landed before the 1.22-beta5 tag was created? [19:06] natefinch, CI will not test a version of juju that tries to mutate the agents that are released. [19:07] natefinch, The branch that incremented juju to beta5 hadn't merged, so CI blocked testing of the last merge to 1.22 [19:08] sinzui: oh, I see what you mean - we have to change the actual files to create a new release number, as well as creating the tag in git... and we hadn't made the change to the files yet. [19:08] natefinch, dimitern : I am bringing this up because it isn't clear from the failure email sent to the list why publish-revision failed [19:08] I am fixing it. nothing for your team o do [19:09] sinzui: ok [19:09] we will retest in about 15 minutes [19:16] TheMue: you around? [19:29] natefinch: yep [19:34] TheMue: how's the train from Munich to Nuremberg? I'm considering just flying into Munich, since most of my flights go through there anyway [19:35] natefinch: should be very good, it's near and Nuremberg-Munich are on the ICE route. the ICE is the fastest train in Germany. [19:35] natefinch: I'll take it too, but from north. ;) [19:36] TheMue: nice. Do you know if you have to book ahead of time, or can you basically walk up and buy a ticket? [19:38] natefinch: normally you can buy directly at the railway station. only if you want to make sure getting a good seat you'll have to book ahead of time [19:38] TheMue: cool. [19:40] natefinch: time is between 2 and 2:30, depending on the exact trains [19:41] natefinch: sadly Munich Central Station is 40 mins away from the airport === kadams54 is now known as kadams54-away [19:42] TheMue: oh, hmm [19:42] TheMue: that's unfortunate [19:42] TheMue: that might make my decision for me, then [19:43] natefinch: yep [19:43] hazmat, we expect CI to test deployer along with quickstart starting Thursday [19:44] natefinch: is their a flight from Amsterdam to Nuremberg? or Heathrow? then this may be better. [19:44] sinzui: cool, thanks for the update [19:46] TheMue: looks like most flights want to take me to munich or frankfurt, and then a tiny airplane to nuremberg... amsterdam or zurich are other possible stops... but they end up being a little longer [19:47] dang, I was happy with the 8 hour direct flight to Munich :) [19:47] natefinch: yes, I know, puzzling together the optimal connection isn't very easy. === anthonyf is now known as Guest30629 === kadams54-away is now known as kadams54 === Guest30629 is now known as anthonyjf [20:02] natefinch, ping [20:09] urulama: are you still around? [20:13] thumper: hey. just about to have dinner. will ping you when i'm done :) === urulama is now known as urulama|afk [20:14] ok [20:25] thumper: [20:25] i forgot to ask [20:25] at the standup [20:25] what is next with power ? === kadams54 is now known as kadams54-away [20:29] davecheney: I need to talk with alexisb about that in my call this morning [20:30] ok [20:30] i have the fix as a replacement .deb we can deploy on ppc64 ci machines to get them going === urulama|afk is now known as urulama [20:35] thumper: back [20:35] urulama: that was quick [20:35] urulama: I'm free for the next 20 minutes [20:50] mgz: how do I kick off a run of "local-deploy-vivid-amd64"? [20:55] ericsnow: you mean for a specific branch? or just rerun the last job? [20:56] mgz: trying to verify 1427210 is fixed (so job 144) [20:59] ericsnow: it seems to be reliably (twince in the same way) failing with a new error [20:59] mgz: k === kadams54-away is now known as kadams54 [21:00] conf.Output value "/var/log/juju-jenkins-localdeploy-vivid-amd64/machine-0.log" (Options are syslog) is not valid [21:00] mgz: how do I look at the logs? [21:01] ericsnow: it's not yet up on juju-reports so I'm just looking at the job in jenkins, which requires admin/password which can be found is cloud-city [21:01] mgz: k [21:02] * urulama makes a note to self ... don't talk to thumper :P [21:02] urulama: oh, c'mon [21:02] it wasn't that bad [21:03] you were laughing a lot, yes :D [21:03] urulama: really? you need a note? I got it in my induction manual [21:03] perrito666: :D [21:04] urulama: don't take that from thumper! [21:04] urulama: just bring up UX issues until he calls off the phone call [21:08] thumper: fyi, you have +1++ on JES CLI [21:09] awesome [21:09] lol [21:32] thumper, ping [21:32] hey [21:32] coming === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 === kadams54 is now known as kadams54-away === kadams54 is now known as kadams54-away === kadams54-away is now known as kadams54 [22:29] could someone take a look at a small patch: http://reviews.vapour.ws/r/1051/ [22:29] it should unblock CI [22:31] ericsnow: looking [22:32] wallyworld__, ping [22:34] ericsnow: i'm probably just missing context but why is a command simple when it contains one of the those characters? [22:35] menn0: yeah, the condition is reversed (so all those are *not* simple) :) [22:35] menn0: I'll fix that [22:35] ericsnow: right, that makes more sense then! [22:37] ericsnow: while you're in there, consider using strings.ContainsAny() [22:37] ericsnow: that would simplify the function somewhat (and make it more efficient) [22:37] menn0: sounds good [22:40] ericsnow: initial review done [22:45] menn0: thanks [22:45] menn0: I've updated the patch [22:46] Bug #1403084 changed: Tests that need to be fixed on windows [22:48] ericsnow, do you want to claim this bug as in progress or fix committed https://bugs.launchpad.net/juju-core/+bug/1409639 [22:48] Bug #1409639: juju needs to support systemd for >= vivid [22:48] sinzui: good point [22:49] ericsnow: re the comment about the error check TODO. where I commented there's no UpdateConfig call. Looks like a copy and paste problem? That TODO appears twice in the PR. [22:49] sinzui: I'll updated it [22:49] menn0: ah, you're right [22:54] ericsnow: sorry, a couple more little things [22:55] menn0: no worries === kadams54 is now known as kadams54-away [22:57] menn0: fixed [22:59] ericsnow: ship it [22:59] menn0: thanks [23:44] abentley: are you looking at local-deploy-vivid-amd64?