[02:42] <hatch> hey huwshimi 
[02:42] <huwshimi> hatch: Ye
[02:42] <huwshimi> *Hey
[02:42] <huwshimi> typing
[02:42] <hatch> lol
[02:43] <hatch> crap CI hung on your build
[02:44] <hatch> huwshimi so in your branch you still have the min/mid/max classes - are those used somewhere?
[02:44] <hatch> https://github.com/juju/juju-gui/pull/400/files#diff-225b0a8e53f0646bec2686e3d713bbd5R37
[02:45] <hatch> that line for example
[02:45] <hatch> rick_h_ u on?
[02:45] <huwshimi> hatch: They're not, but I'm expecting to use them in another branch. I can remove them from this one if you like?
[02:45] <hatch> no it's ok as long as you know you'll use them
[02:45] <huwshimi> yep
[02:45] <hatch> ok +1'd
[02:46] <hatch> you can land it whwnever
[02:47] <huwshimi> hatch: Thanks!
[02:59] <rick_h_> hatch: what's up?
[03:00] <hatch> rick_h_ oh hey, the PR ci will need restarting
[03:00] <hatch> I was just about to grab the info
[03:00] <hatch> :)
[03:00] <rick_h_> hatch: gotcha, sec
[03:01] <rick_h_> hatch: I only see the prod one going
[03:01] <rick_h_> hatch: and that's in a test run to land
[03:02] <hatch> rick_h_ yeah I had to kill the one in the pr lane because it hung
[03:02] <hatch> so it will likely still be running...no?
[03:02] <rick_h_> hmm, tests are running atm
[03:02] <rick_h_> hmm, maybe it's this other one
[03:02] <hatch> right - not the landing script
[03:02] <hatch> the pr one
[03:02] <rick_h_> ok, killed one
[03:02] <rick_h_> hopefully that's the right one :)
[03:02] <hatch> haha we'll know shortly!
[03:03] <hatch> maybe this weekend I'll find some time to add the 'if running KILL IT DEAD' mode :)
[03:03] <rick_h_> it's supposed to do that :P
[03:03] <rick_h_> (cd build-prod && \ python ../bin/http_server.py 8888 2> /dev/null & \ echo $!>ci-check-gui-server.pid)
[03:03] <hatch> oh haha - well then, why does it give the ERADDRINUSE issue?
[03:04] <hatch> ohhh
[03:04] <hatch> that's not checking the node server
[03:04] <rick_h_> echo ci-check-gui-server.pid
[03:04] <rick_h_> ci-check-gui-server.pid
[03:04] <rick_h_> cat ci-check-gui-server.pid
[03:04] <rick_h_> 4360
[03:04] <rick_h_> kill `cat ci-check-gui-server.pid`
[03:04] <rick_h_> rm ci-check-gui-server.pid
[03:04] <rick_h_> hatch: oh hmm, yea then maybe it needs more of it 
[03:04] <hatch> yeah I think it's the node server that throws the error
[03:05] <rick_h_> gotcha, yea well happy to run more pid/pid-checking to help it
[03:05] <rick_h_> doens't happen too often thankfully. 
[03:06] <rick_h_> hatch: you hatch on launchpad?
[03:06] <hatch> yep
[03:06] <rick_h_> you're a rude man making me look it up on LP hatch :P
[03:07] <rick_h_> ok, you've got ssh rights. ssh ubuntu@ci.jujugui.org
[03:07] <hatch> lol sorry I was in the other room
[03:07] <rick_h_> don't mess up my server or I'll have to come to canada and drop you down a hole in the ground
[03:10] <hatch> lol yeah I wont be at it until this weekend for sure
[03:10] <rick_h_> at what?
[03:10] <rick_h_> you not in canada right now?
[03:10] <hatch> haha of course I am
[03:11] <hatch> I meant, I won't be breaking your server until this weekend
[03:11] <rick_h_> well don't do that!
[03:11] <hatch> :)
[03:14] <hatch> Ooo nice new column in the board
[06:43] <rogpeppe> mornin' all
[06:43] <huwshimi> rogpeppe: Morning
[06:54] <rogpeppe> huwshimi: hiya
[11:27] <rick_h_> morning
[13:15] <rogpeppe> rick_h_: hiys
[13:15] <rogpeppe> hiya
[13:15] <rogpeppe> even
[13:15] <rick_h_> rogpeppe: howdy
[13:16] <rogpeppe> rick_h_: the bundles parsing/verification PR is up at https://github.com/juju/charm/pull/9
[13:16] <rick_h_> rogpeppe: cool looking. 
[13:16] <rogpeppe> rick_h_: it does all the internal verification, but doesn't verify against actual charms
[13:17] <rick_h_> rogpeppe: ok, can you create a bug/additional card to look into that part?
[13:17] <rogpeppe> rick_h_: ok, will do
[13:17] <rick_h_> rogpeppe: we're thinking that'd part of the publish side of things?
[13:17] <rick_h_> vs part of the actual model side here
[13:17] <rogpeppe> rick_h_: i'm thinking that it can live inside the charm package
[13:17] <rick_h_> outside you mean?
[13:18] <rogpeppe> rick_h_: no, inside
[13:18] <rogpeppe> rick_h_: something like BundleData.VerifyWithCharms([]*Charm) error
[13:19] <rogpeppe> rick_h_: which means it can be called by any client that happens to know the charms that the bundle service charm urls resolve to
[13:20] <rick_h_> rogpeppe: ok, looking through this pr and will see how it fits
[13:20] <rogpeppe> rick_h_: thanks
[14:13] <rick_h_> rogpeppe: how does such 'combining of errors' work? They're basically complete sentences. How does one take them and combine them more than just listing them out? Does it ', and' each or anything as part of this common practice?
[14:13] <rogpeppe> rick_h_: usually it just involves prefixing "something happened: " onto an existing error
[14:14] <rogpeppe> rick_h_: in this case, the final error might look something like "cannot verify bundle: placement "foo:bar" refers to non-existent service (and 303 more errors)"
[14:15] <rick_h_> rogpeppe: ok, but then we need to make sure to update the clients cli and webui to do this post processing. It seems like adding more places to catch the update than to make it work right
[14:15] <rogpeppe> rick_h_: all errors returned by the API are currently without capitals or periods
[14:15] <rogpeppe> rick_h_: so this just continues in the same vein
[14:15] <rick_h_> rogpeppe: right, and we've had to do work in the gui to try to parse them and make them presentable
[14:16] <rick_h_> rogpeppe: right, it's an existing issue I'm bringing up potentially attempting to address while we're here in the code
[14:16] <rogpeppe> rick_h_: if we're going to change that, i'd prefer to change the entire API
[14:16] <rogpeppe> rick_h_: rather than adding a single inconsisent place
[14:16] <rogpeppe> inconsistent
[14:16] <rick_h_> heh count me in :) but we're in control of this bit of code and we know that errors parsing the bundles will need to get in front of the users 
[14:16] <rick_h_> so they can debug and fix them
[14:16] <rogpeppe> rick_h_: consistency trumps convenience IMHO in this case
[14:17] <rick_h_> rogpeppe: ok, then we should add cards for the core cli and the gui to update bundle errors when connect to the updated store so that we don't lose track of known usability issues that we should correct. 
[14:18] <rick_h_> maybe bugs would be better since they can't be updated until a store update is deployed and used 
[14:19] <rogpeppe> rick_h_: i'm not entirely sure it's a CLI issue - errors are currently printed in lowercase
[14:20] <rogpeppe> rick_h_: but i'll add an issue to the gui. are gui issues tracked in lp ?
[14:20] <rick_h_> Why would it be good to make the error message a complete english thought with proper writing in one place and not the other? 
[14:20] <rick_h_> rogpeppe: yes, they are
[14:21] <rogpeppe> rick_h_: mainly because many things on the unix command line print stuff in lower case - there's honourable precedent :-)
[14:21] <rogpeppe> rick_h_: and it's less code, which is always a win in my book :-)
[14:27] <bac> rogpeppe: i've got the latest charmstore and tried to run 'make check' but get errors referencing missing testing items like MgoSuite, etc.
[14:27]  * rogpeppe goes to see what make check does
[14:28] <rogpeppe> bac: for the record, when dealing with go packages, i almost never run make
[14:28] <rick_h_> rogpeppe: but through CI and such make is the single interface all devs can use to hack/operate
[14:29] <rogpeppe> rick_h_: sure, it's useful for CI
[14:29] <rick_h_> rogpeppe: the make targets need to be valid and make check is the common target in all proejcts for a CI-like run through lint, test, etc
[14:29] <rick_h_> so in QA it's quite common to make check, make run, and then qa
[14:29] <bac> rogpeppe: i'm just looking at the README and it references 'make check'
[14:29] <rogpeppe> bac: ok
[14:31] <rogpeppe> bac: have you tried doing: godeps -u dependencies.tsv ?
[14:31] <rogpeppe> bac: it all seems to work for me
[14:32] <rogpeppe> bac: could you paste the exact errors you get?
[14:32] <bac> rogpeppe: https://pastebin.canonical.com/112262/
[14:33] <rogpeppe> bac: hmm, odd.
[14:34] <rogpeppe> bac: could you try doing "rm -r $GOPATH/pkg" then "go install ./..." and trying again?
[14:34] <bac> rogpeppe: from inside the charmstore directory?
[14:34] <rogpeppe> bac: yes
[14:36] <bac> rogpeppe: didn't help.  what version of juju/testing do you have? mine is b09...
[14:37] <rogpeppe> bac: b0941ff1bf4d3db1ffbbe09f75fa8383eae5764c
[14:37] <bac> same
[14:38] <rogpeppe> bac: do you see the same thing if you just run "go test" (in the same dir)
[14:39] <bac> rogpeppe: yes, and it is unsurprising.  if i look in juju/testing i see no MgoSuite anywhere
[14:39] <kadams54> Juju GUI architecture question: how do we connect to the juju state server?
[14:39] <rick_h_> kadams54: websocket
[14:39] <hatch> via websocket
[14:39] <hatch> and magic 
[14:39] <bac> rogpeppe: if you look in juju/testing where do you find those defined?
[14:40]  * hatch shakes hands in the air
[14:40] <rick_h_> lots of magic
[14:40] <hatch> *magic*
[14:40] <rogpeppe> bac: in mgo.go
[14:40] <kadams54> rick_h_: Where at in the code?
[14:40] <hatch> heh well....
[14:40] <rogpeppe> bac: what do you see if you run "git status" in the juju/testing dir?
[14:40] <hatch> kadams54 I can get you the loc, one sec
[14:41] <bac> clean
[14:41] <bac> rogpeppe: there is no mgo.go in my juju/testing
[14:41] <hatch> kadams54 here is the websocket instance https://github.com/juju/juju-gui/blob/develop/app/store/env/base.js#L234
[14:41] <rogpeppe> bac: could you paste the entire output of your "git status" please?
[14:42] <hatch> kadams54 here is where we make the requests https://github.com/juju/juju-gui/blob/develop/app/store/env/go.js#L181
[14:42] <hatch> kadams54 did you have a specific question in mind?
[14:43] <bac> rogpeppe: i went to my juju/testing and did a 'git pull' and it got the mgo.go file along with lots of others.  why did the 'go get -u' and the 'godeps' not update it?
[14:43] <rogpeppe> bac: i don't know - that's why i wanted to see exactly what git status printed for you
[14:44] <kadams54> hatch: that satisfies my curiosity for now, thanks
[14:44] <rogpeppe> bac: AFAIK go get -u just does a git pull
[14:44] <bac> rogpeppe: this is what git status said before i did the manual pull: https://pastebin.canonical.com/112263/
[14:45] <rogpeppe> bac: thanks. i've no idea then. "go get -u" just runs "git pull --ff-only"
[14:46] <hatch> kadams54 np
[14:46] <bac> rogpeppe: i'm going to blow away everything and try again
[14:46] <hatch> hey cory_fu 
[14:46] <rogpeppe> bac: that can be a good plan...
[14:47] <rogpeppe> bac: have you tried testing again now that you did the pull?
[14:47] <bac> well i just want to see if it is reproducible
[14:47] <rogpeppe> bac: wait!
[14:47] <bac> rogpeppe: i did and it passed
[14:47] <rogpeppe> bac: what does "git remote -v" print for you in the juju/testing dir?
[14:47] <rogpeppe> bac: too late...
[14:47] <rogpeppe> bac: darn
[14:47] <rogpeppe> but... it printed the right head
[14:47] <kadams54> Hey, who should we be sending design/UX questions to right now? Luca's out, right?
[14:48] <rogpeppe> jeeze, i dunno
[14:48] <hatch> kadams54 spencer
[14:51] <rick_h_> jujugui call in 9
[14:54] <bac> wow, crazy loud tsunami drill.  i guess that's what you want from a tsunami alarm.
[14:58] <hatch> what does one do when a tsunami alarm rings? Run inland? 
[14:58] <bac> rogpeppe: so you'll know, i'm trying to set up and test the charmstore as we'd do for CI.  it looks like we have some problems with our dependencies. here's what i've done (mainly as stated in the README) : https://pastebin.canonical.com/112265/
[14:58] <makyo_> jujugui call in 2
[14:58] <bac> run downstairs, grab beer and camera, then go to the roof.
[14:59] <rogpeppe> bac: you need to do go get -t
[14:59] <hatch> ahh to the roof
[14:59] <hatch> I guess that makes sense :)
[14:59] <bac> rogpeppe: go get -t -v github.com/juju/charmstore  ???
[15:00] <rogpeppe> bac: in full, you'd need to run: go get -v -t -u github.com/juju/charmstore/...
[15:00] <rogpeppe> bac: the final "/..." is important
[15:00] <rogpeppe> bac: otherwise you won't get deps for subdirs
[15:00] <rick_h_> jujugui call now 
[15:11] <kadams54> hatch: https://github.com/juju/juju-gui/pull/393 is ready for QA again. I want to hold off on sending this e-mail until this branch is landed and you can see stuff working/not working on upcoming.
[15:13] <kadams54> Here are the questions I'm planning on sending out, in case you want to review: https://gist.github.com/kadams54/681a40f7bd9d603a53bb
[15:15] <cory_fu> So, I'm still trying to understand how juju-gui connects back to the juju state server.
[15:15] <cory_fu> I thought maybe https://github.com/juju/juju-gui/blob/develop/app/app.js#L382 was where it got the address of the state server, but that just seems to be the connection to the GUI backend?
[15:15] <kadams54> cory_fu was unsatisfied with the "magic" explanation.
[15:15] <cory_fu> :)
[15:16] <bac> rogpeppe: adding the -t worked.  i'll update the readme
[15:16] <rogpeppe> bac: thanks
[15:16] <bac> rogpeppe: yeah, the ... was important too
[15:19] <kadams54> 948647
[15:19] <kadams54> ccccccdilrklllutrivjhvjttuigtldiclbejkuderdh
[15:19] <kadams54> Alright, that's it
[15:19] <cory_fu> I'm failing to understand how it can be using the public address for the juju-gui unit yet still have commands get to the state machine on machine 0
[15:19] <kadams54> ccccccdilrklnvjvvhbrtekkhcebgrrjeejurdfdvuvc
[15:20] <kadams54> guihelp: --^ (cory_fu, not my yubi spam)
[15:20] <cory_fu> kadams54: You don't have another USB slot more out of the way?  :)
[15:20] <cory_fu> Oh, yeah, thanks
[15:20] <hatch> cory_fu I'm not sure the question
[15:21] <kadams54> I realized what it is - when I'm cmd-tabbing, my pinkie is right over that USB slot. I may try the other one.
[15:21] <hatch> cory_fu kadams54  we don't connect directly to the juju state server
[15:21] <hatch> we connect to the gui server
[15:21] <cory_fu> hatch: Ok, so I need to know how the GUI server talks to the state server
[15:23] <hatch> it also uses websocket but from a python server
[15:23] <hatch> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
[15:23] <hatch> that's the charm source
[15:24] <hatch> cory_fu so are you trying to write your own application with communicates with the state server?
[15:25] <cory_fu> hatch: Yeah.  I'm working on the Cloud Foundry charm and it turns out we're going to need to communicate with the state server, similar to how the GUI does
[15:26] <hatch> ok there is api documentation around that....
[15:26] <hatch> one sec I'll see if I can find it
[15:26] <hatch> at least I thought there was....
[15:27] <cory_fu> Ah.  I found what I needed.  :)
[15:28] <rick_h_> cory_fu: yes, the gui talks to the guiserver in the charm
[15:28] <rick_h_> cory_fu: and then it proxies all requests to the state server and intercepts a couple of special api calls like bundle deploys that juju doens't natively handle
[15:28] <cory_fu> Ok.  That's basically what I expected.  Thanks.  :)
[15:28] <hatch> cory_fu perfect....where was it ? 
[15:28] <hatch> hah
[15:29] <rick_h_> oh heh, hatch has your back. 
[15:29] <cory_fu> hatch: https://bazaar.launchpad.net/~juju-gui/charms/trusty/juju-gui/trunk/view/head:/hooks/utils.py#L140
[15:29] <rick_h_> cory_fu: yea, you're looking for http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files/head:/server/
[15:29] <cory_fu> That function is exactly what I needed
[15:29] <hatch> ahh perfect
[15:29] <hatch> yeah the guy who does this work is off atm :)
[15:31] <hatch> good luck with the charm
[15:32] <cory_fu> Thanks.  :-)
[15:58]  * rick_h_ goes to make up some lunch
[16:23] <hatch> has anyone else been running into issues with yahoos cdn taking forever to respond?
[16:33] <hatch> oh our test suite....
[16:42] <hatch> jujugui looking for a review/qa on this first relations branch https://github.com/juju/juju-gui/pull/402
[16:42] <kadams54> hatch: looking…
[16:43] <hatch> thanks
[16:43] <hatch> kadams54 what was the issue with the previous qa issue on your branch?
[16:43] <hatch> https://github.com/kadams54/juju-gui/commit/be1356a686a51632160fae08a8570d7e59310a3a
[16:43] <hatch> that commit?
[16:44] <kadams54> It was the unitOrEvent variable that got renamed back to unit… it needs to be nulled out if it's actually an event rather than a unit.
[16:44] <kadams54> Yeah, that commit
[16:44] <hatch> ok cool - in the future can you use a real commit message :)
[16:44] <hatch> review looks good, qa'ing
[16:55] <hatch> kadams54 try a make clean and clean your cache (re huw's branch)
[16:56] <kadams54> hatch: yeah, I did both, still seeing the funky button.
[16:56] <hatch> hmm odd alright then
[16:57] <hatch> kadams54 adding a container without selecting a machine is kind of odd heh
[16:57] <hatch> because it creates a machine
[16:58] <kadams54> Yes. There's a lot of funkiness around MV in general.
[16:58] <kadams54> If you stick to the happy path, everything is all rainbows and unicorns
[16:59] <kadams54> Stray off and the world goes sideways.
[17:01] <hatch> ok one more small qa issue
[17:01] <hatch> one of these days I'll get all of you to stop using anchor tags :D
[17:01] <kadams54> Ah ha ha ha ha
[17:07] <kadams54> hatch: I'm puzzled about why that's happening for "Add container", but not "Add machine" - they both have the same handler function which does preventDefault().
[17:07] <kadams54> Giving span a try…
[17:07] <hatch> it happens for both for me
[17:08] <kadams54> What about on http://comingsoon.jujucharms.com/?
[17:08] <hatch> kadams54 it might need an e.halt() 
[17:08] <hatch> basically anchors are stupid
[17:08] <hatch> and I'm not goign to change my mind on that :D
[17:08] <kadams54> Pffft, no way!
[17:09] <hatch> lol
[17:09] <kadams54> Jeff would totally call that out in review.
[17:09] <kadams54> ;-)
[17:09] <hatch> haha 
[17:09] <kadams54> Oh good gravy
[17:09] <hatch> really though - anchors in a webapp are only useful if you're taking advantage of pjax
[17:09] <hatch> which we aren't
[17:09] <kadams54> spans don't have the right styling.
[17:09] <hatch> lol
[17:10] <hatch> this branch just won't die
[17:10] <hatch> kadams54 try using e.halt() instead of e.preventDefault()
[17:11] <hatch> jcsackett where did you use to get those shirts made up from the sprint?
[17:12] <kadams54> hatch: OK, that worked - change pushed.
[17:13] <hatch> even I'm getting sick of QA'ing this branch lol
[17:13] <hatch> you must be right pissed
[17:13] <hatch> haha
[17:14] <kadams54> I'm ready to be done, for sures
[17:15] <kadams54> Though I have a long list of stuff to turn into bugs and cards, so even after this one lands, it will live on.
[17:15] <kadams54> And that's aside from questions to send to design.
[17:17] <hatch> qa ok;d
[17:17] <hatch> land that!
[17:18] <hatch> kadams54 you'll probably want to move your branch-start card back and then create smaller cards from it
[17:18] <kadams54> Hmm… you're talking about the deleting machines/containers one?
[17:18] <hatch> yeah
[17:18] <hatch> there is a lot of work there
[17:19] <hatch> probably more than 4 days
[17:19] <hatch> judging by how long it took me to do the relations one heh
[17:19] <kadams54> OK. I already created a separate card for ghosted stuff.
[17:19] <rick_h_> hatch: kadams54 sorry, just catching the conversation drive by
[17:19] <rick_h_> hatch: kadams54 we do need to chat and plan out a path?
[17:19] <hatch> we does
[17:19] <kadams54> Sounds like it
[17:19] <rick_h_> standup linky?
[17:19]  * rogpeppe is done for the day
[17:19] <hatch> lata rogpeppe 
[17:19] <rick_h_> rogpeppe: have a good evening
[17:20] <hatch> rick_h_ sure
[17:20] <rogpeppe> rick_h_: see ya tomorrow
[17:20] <rogpeppe> hatch: likewise
[17:20] <rogpeppe> g'night all
[17:44] <jcsackett> hatch: teespring.
[17:44] <jcsackett> hatch: was going to build another one for the last sprint, but alas the required minimum went up.
[18:04] <hatch> booo!
[18:04] <hatch> well this sprint there will be more people
[18:04] <hatch> hopefully I'll say something stupid again
[18:04] <hatch> er....
[18:05] <rick_h_> man, hatch you're making it too easy
[18:05] <hatch> lol
[18:05] <rick_h_> "it's not a matter of if...only a matter of when, and I want to buy the square for day #1"
[18:10] <hatch> haha
[18:12] <bac> rick_h_: in jenkins CI what is the authentication token?  do we just use the same one for all projects?
[18:13] <rick_h_> bac: each project can define one, I've just used the same one I think on the two projects
[18:13] <rick_h_> bac: but feel free to set a custom one for the store 
[18:14] <bac> rick_h_: i don't understand what it is
[18:14] <bac> just a string?
[18:14] <rick_h_> bac: yea, just a private string
[18:14] <bac> pertaining to nothing?
[18:14] <bac> what is the point?
[18:15] <rick_h_> bac: in order to trigger a build via a url call (poor man's api) you can use the token to limit who can trigger a build
[18:15] <rick_h_> bac: it's like a shared secret kind of auth or poor man's api token
[18:15]  * bac feels safer
[18:15] <rick_h_> bac: actually not sure if the lander supports a key per project. :/ 
[18:15]  * rick_h_ checks code
[18:16] <rick_h_> bac: so it might need to be the same for the moment
[18:16] <bac> rick_h_: doesn't matter, i'll just use the same one
[18:16] <rick_h_> bac: ok cool
[18:18] <bac> rick_h_: and for each jenkins test run do i get a new "machine"?
[18:20] <rick_h_> bac: no
[18:20] <rick_h_> bac: not currently, we've not had to. That's something we might have to think about. I know the juju ci does create slave machines to test on
[18:20] <rick_h_> bac: I'd suggets we work with them on that side so that they can bring up machines across platforms, but we have a more simple sanity check for work. 
[18:20] <bac> rick_h_: ugh, i just edited the juju-github-lander test script when i thought i was editing charmstore's.
[18:21] <bac> rick_h_: anyway to revert?
[18:21] <rick_h_> bac: no, there's a backup script that runs but not a good way to revert as the ini file isn't part of the lander's github project
[18:21] <bac> dang
[18:22] <rick_h_> bac: oh you mean in the build steps in the jenkins UI?
[18:22] <bac> rick_h_: yeah
[18:22] <rick_h_> bac: yea, no good way to restore without pita backup xml fun
[18:22] <bac> i replaced 'make test, blah blah' with the steps for charmstore
[18:22] <rick_h_> we have a full backup for doing a full restore but not easy to get 'this field'
[18:23] <bac> rick_h_: ok, i'll look at the makefile and see if i can figure it out
[18:23] <rick_h_> bac: hmm, yea it should be close to the other job
[18:23] <rick_h_> bac: which job did you edit?
[18:23] <bac> jenkins-github-lander
[18:24] <bac> http://ci.jujugui.org:8080/job/jenkins-github-lander/configure
[18:24] <rick_h_> bac: ah ok, I'll update
[18:25] <bac> make testdeps; make lint; make test
[18:25] <bac> ??
[18:25] <rick_h_> bac: updated, copied from the -merge version of the job
[18:25] <bac> oh cool
[18:25] <rick_h_> just removed the landing stage
[18:25] <rick_h_> having two jobs is a bonus sometimes :)
[18:35] <bac> rick_h_: for jenkins we specify the sha1 of the commit to test.  is that the sha of the branch that has been proposed? e.g. https://github.com/bac/charmstore/commit/7d8c2efae2517c3d1e01d8f686223d3a9ad1420c
[18:35] <bac> rick_h_: if it gets that sha at the end of the url, but doesn't know about the specific user, it can fetch it from github?
[18:36] <rick_h_> bac: yes, git watches the list of branches in the pr namespace and knows how to check out each commit sha 
[18:36] <rick_h_> bac: so you can give it any commit in any pr and it'll checkout/test that sha
[18:36] <bac> nice
[18:36] <rick_h_> normally it just gets the latest sha in the pr
[18:42] <hatch> kadams54 did you review/qa my branch yet?
[18:42] <kadams54> In progress right now.
[18:43] <hatch> cool thx, i'm gona go grab some lunch
[19:31] <hatch> mmm check this out! http://www.withings.com/activite/en-US me wants
[19:33] <hatch> well except that it doesn't work with android
[19:33] <rick_h_> so I just watched a video and don't know anything more than when I started
[19:34] <hatch> rofl
[19:34] <hatch> I thought the same thing haha
[19:34] <rick_h_> it's a pretty fitbit?
[19:34] <hatch> yep
[19:34] <rick_h_> pass, I <3 my pebble steel
[19:34] <hatch> basically by the time it's released I will have forgotten about it
[19:34] <hatch> oh well
[19:34] <hatch> I want the Google watch
[19:34] <rick_h_> got a new awesome watch face that is nice and clean
[19:34] <hatch> that thing is darn cool
[19:35] <rick_h_> heh, that one will be tough. I'll be darn tempted to get my google now on my wrist
[19:35] <rick_h_> but I think that'll definitely a gen2 switch over
[19:35] <hatch> I'm kind of hoping they release it tomorrow, I'll be staring at my screen with my cc in hand waiting during the keynote
[19:35] <rick_h_> heh, I was glad I had no calls at noon 
[19:35] <rick_h_> you can be sure the chromecasts in the house will be watching the keynote
[19:36] <hatch> of course it won't be available in Canada...so I'll have to have you buy it for me
[19:36] <hatch> lol
[19:36] <rick_h_> works for me
[19:36] <rick_h_> when two of them show up I'll just tell the wife I was getting it for you
[19:36] <rick_h_> and hide the other one :)
[19:36] <hatch> hahaha
[19:37] <hatch> there was a watch face competition for that watch....
[19:37] <hatch> I +1'd a couple....now where do they keep these +1's
[19:37] <hatch> hmm empty...
[19:37] <hatch> that's not right
[19:41] <hatch> https://plus.google.com/photos/+Motorola/albums/6025927350868561553
[19:42] <hatch> it's kind of too bad pebble didn't go colour and round :)
[19:45] <bac> rick_h_: ugh, our jenkins is precise but charmstore is not very precise-happy
[19:45] <hatch> time to switch back to warty
[19:46] <hatch> hmm that's an interesting failure in ci
[19:47] <rick_h_> bac: ok, well we can deploy a new jenkins server on trusty. 
[19:48] <bac> rick_h_: man that would make life easier
[19:48] <rick_h_> bac: or we look at using jenkins/jenkins-slave to run the tests on a slave related machine
[19:48] <bac> trusty! trusty!
[19:48] <hatch> wait for my merge to land plz :)
[19:48] <rick_h_> bac: yea, I first thought we could move all of ci to trusty, but jujucharms and prodstack is still precise 
[19:48] <bac> rick_h_: here's what i've got so far: http://ci.jujugui.org:8080/job/charmstore/configure
[19:48] <rick_h_> bac: so we'd need to get our prodstack envs moved as well
[19:49] <bac> rick_h_: the go-ness of it makes it kind of messy
[19:49] <rick_h_> bac: want to peek at the jenkins slave charm and see if we can more easily tie that in?
[19:49]  * rick_h_ is looking
[19:50] <bac> rick_h_: going to trusty would give me a modern version of go too.
[19:50] <rick_h_> bac: right
[19:50] <rick_h_> bac: but if we setup the slave machine, we have one place to view the results reports
[19:50] <rick_h_> but run the tests on another machine that can be the go-centric place and can be trusty easily without effecting current stuff
[19:50] <bac> we do or we don't?
[19:50] <bac> why the but?
[19:51]  * bac brb
[19:51] <rick_h_> bac: sorry, mixed stuff in there
[19:52] <rick_h_> bac: the CI config looks good. The tmp stuff reminds me of the lbox clean directory stuff from GUI heh. 
[19:53] <rick_h_> hatch: build fail
[19:53] <hatch> yeah I re-triggered it
[19:53] <rick_h_> bac: hmm, no trusty jenkins-slave charm :( I would think that we could try to fork/push that. 
[19:53] <hatch> not sure what the old issue was, but hopefully this one will work just fine
[19:57] <hatch> looks like it's running now
[19:57] <hatch> *crosses fingers*
[20:01] <bac> rick_h_: oh, i guess i should blow away that tmp dir
[20:01]  * bac wonders how long before i rewrite it all in python
[20:02] <rick_h_> bac: yea, wish sinzui and them weren't so under water and could chat/participate. 
[20:02] <bac> rick_h_: i talked to sinzui earlier
[20:02] <bac> he gave me some references but they aren't doing anything exactly like this
[20:03]  * rick_h_ goes to check logs, assumed they'd have to do all the tests on precise/trusty and such across platforms
[20:03] <rick_h_> bac: ok, what do you think of the path forward of updating the jenkins-slave charm for trusty, get it deployed and wired up to ci.jujugui.org, and then moving the test runs of the store to there?
[20:04] <bac> rick_h_: it was all pm'd
[20:04] <rick_h_> bac: ah, ok nvm then
[20:04] <bac> rick_h_: https://pastebin.canonical.com/112297/
[20:06] <rick_h_> bac: interesting
[20:09] <bac> rick_h_: what has to be done to that charm? i don't see anything precise-specific in it
[20:09] <rick_h_> bac: ok, well I've got two worries. One that precise not working is a problem we'll need to solve. But I think that can wait until after we get stuff working
[20:09] <rick_h_> bac: I think the only thing we'll have to do is to fork it and push it up under the precise/ namespace
[20:10] <bac> rick_h_: the issue with precise are 1) old go that needs work-arounds, 2) no juju-mongo package backported.
[20:10] <rick_h_> bac: so I'd start by testing it out by just pulling it down and publishing it under either yourself or our juju-gui space we use for our own charm. 
[20:10] <bac> ok
[20:11] <rick_h_> sorry ~juju-gui-charmers is the shared one
[21:25] <bac> jujugui: anyone have problems deploying local charms unless you specify --repository?  http://paste.ubuntu.com/7697163/
[21:26] <hatch> bac yes that is required
[21:26] <bac> hatch: well, it looked liked it guessed properly but didn't really since it appened /trusty
[21:26] <kadams54> bac: True confession: I've only ever deployed a local charm (the ghost one) via the GUI.
[21:27] <hatch> bac yea i haven't ever got that to work heh
[21:27] <bac> yeah, it doesn't come up often
[21:29] <hatch> bac what if you were in ~/charms and then did `juju deploy local:trusty/jenkins-slave` ?
[21:29] <bac> hatch: i think that would work
[21:35] <hatch__> bac it would be nice if we could go `juju deploy .`
[21:44] <Makyo> Two failures \o/
[21:44] <hatch> Makyo are you around?
[21:44] <hatch> oh hah
[21:44] <hatch> :)
[21:44] <Makyo> Yep
[21:45] <hatch> \o/ for failures
[21:45] <hatch> so my question :)
[21:45] <hatch> when we create a relation between two ghost services the information which is in the changeset is the service names not a reference to their models
[21:45] <hatch> so if the user changes the service name (it's not yet been deployed)
[21:45] <hatch> then the relation fails
[21:46] <Makyo> Hmmm.  Seems like an easy enough change.  I know we crammed that in last minute.
[21:46] <Makyo> "Easy enough" in the heaviest sarcasm quotes I can muster.
[21:46] <hatch> lol
[21:46] <hatch> sooooo I was thinking we should instead add an extra id to the models 
[21:47] <hatch> and we use those id's for reference for the ecs stuff
[21:47] <hatch> then the models can change under it and it doesn't matter
[21:47] <Makyo> hatch, don't we already have those?  The 120947$ ids?
[21:47] <Makyo> Those don't change.
[21:47] <hatch> right, but I'm pretty sure those go away once it's been deployed....no?
[21:48] <hatch> I'll investigate further....but you don't see any issue with using the ghost id's then resolving them wherever they need to be resolved? 
[21:48] <hatch> there are a few places where we rely on the id to display the information
[21:48] <Makyo> Well, sure, but once they're deployed, we already have a mechanism for replacing that info in future ECS records, right?
[21:48] <Makyo> YEah.
[21:49] <hatch> yeah ok cool
[21:49] <hatch> good thing we are agile haha, I'm not sure how anyone would have created a spec for this stuff :)
[21:51] <hatch> kadams54 hey, do you know why halt() worked this morning when preventDefault() didn't? I realized I told you to use it but didn't say why...
[21:53] <kadams54> hatch: I suspect it's because the click event is bubbling up?
[21:53] <hatch> yeah, halt calls preventDefault and stopImmediatePropagation so it stops it bubbling....this has caused us issues in the past when listening on containers for events so we try and use it sparingly 
[21:54] <kadams54> Though I'm pretty annoyed right now… the merge CI build is failing on an IE error that is happening in a section of code (test_inspector_charm.js) that doesn't seem very related to anything I changed.
[21:55] <kadams54> Something in the "closes itself safely" test is causing hash URL pollution, which means test_cleanup.js fails at the very end.
[21:57] <hatch> ahh, check that there isn't an ANCHOR tag, being clicked without a preventDefault
[21:57] <hatch> :P
[21:57] <kadams54> :-)
[21:57] <kadams54> Believe me, I'm looking for that like a hawk
[21:58] <kadams54> But there's no click simulates in the test in question, so no easy suspects
[21:58] <hatch> well....if you have a few commits can you revert them back and see which introduces the issue?
[22:06] <kadams54> Haven't tried that yet, but the problem seems to be here: https://github.com/juju/juju-gui/blob/develop/app/views/viewlets/charm-details.js#L90
[22:07] <hatch> looking
[22:07] <kadams54> IE 10 interprets that line as "set the hash to '#'"
[22:07] <kadams54> Though I'm not sure why that would start failing right now
[22:07] <hatch> that line has been there for a while
[22:07] <hatch> yeah...
[22:07] <hatch> what r u working on?
[22:08] <hatch> or I suppose, do you have the code up somewhere
[22:08] <kadams54> Hah!
[22:08] <kadams54> You KNOW what I'm working on
[22:08] <kadams54> It's the same PR I've been working on!
[22:09] <kadams54> I can't land it because of this IE test failure.
[22:09] <kadams54> Need to get dinner now, but may bisect tonight
[22:10] <hatch> oh.....the same one?
[22:10] <hatch> that's the one that won't work
[22:10] <hatch> wth
[22:11] <hatch> yeah take a break :) 
[22:12] <kadams54> Hmm…
[22:14] <kadams54> I'm pretty sure we do this to reset any tab info that might have been stored in the hash
[22:15] <kadams54> But the reality is that there doesn't appear to be a good cross-browser way to remove the hash.
[22:15] <kadams54> Still very puzzled as to why this would break now, and why it only breaks in IE. I get manually duplicate the same behavior in Chrome when I set window.location.hash in the console.
[22:15] <kadams54> But dinner calls.
[23:07] <huwshimi> Morning
[23:18] <jcsackett> morning, huwshimi.
[23:18] <huwshimi> jcsackett: Hey!
[23:19] <jcsackett> heya, how have you been?
[23:20] <huwshimi> jcsackett: Good thanks. Yourself?
[23:21] <jcsackett> i've been good. busy, but good. :)
[23:21] <huwshimi> :)
[23:56] <rick_h_> morning huwshimi 
[23:56] <huwshimi> rick_h_: Hey