[03:27] <Makyo> jujugui quickstart review (again) - ssh 2.5 and 3.0 cards all in one: https://codereview.appspot.com/39610049/
[03:27]  * Makyo beers self.
[03:27] <rick_h__> Makyo: very cool
[03:28] <rick_h__> well deserved, was the juju-core stuff helpful?
[03:29] <Makyo> rick_h__, Pointed me in the right direction, yeah. Will always need an SSH agent, from the way things look, subprocesses can't add keys to existing agents, and using an agent is the only way to both verify and use keys.
[03:30] <rick_h__> Makyo: cool, glad to see it work out. 
[03:30] <Makyo> rick_h__, thanks :)
[03:32] <rick_h__> I'm heavily on pre-bed meds so can't look now but will see if I can peek at it in the morning if you still need a review
[03:32] <rick_h__> maybe frankban will peek before I'm up and at em
[03:33] <Makyo> rick_h__, no worries.  frankban and gary_poster|away  will be on it tomorrow; I'm sure they'll have guidance on user-facing messages, either way.
[03:33] <rick_h__> coolio
[03:34]  * rick_h__ raises a glass in cheers for beating down the roadblock
[13:16] <frankban> guihelp: anyone available for reviews? I need two + QA for https://codereview.appspot.com/42600044 and one (no QA) for https://codereview.appspot.com/43380043 (both quickstart). Thanks!
[13:20] <BradCrittenden> frankban: sure
[13:20] <BradCrittenden> gah
[13:20] <bac> frankban: more specifically, i'll start by taking the first
[13:21] <frankban> bac: thanks!
[13:21] <bac> oh, another zope-lite branch!  :)  :)
[13:21] <frankban> bac: nooooo :-)
[13:28] <gary_poster> heh
[13:29] <gary_poster> frankban, I will try to fit one in in the next 30 min.  After that slammed with back to back calls
[13:30] <frankban> gary_poster: great thanks, FWIW the first one is more interesting
[13:30] <gary_poster> ok cool
[13:33]  * gary_poster starts frankban's "Quickstart base structure for views." branch review
[14:01] <gary_poster> frankban, "Ran out of time, but I think this looks great.  Count me as an LGTM 'cause I
[14:01] <gary_poster> know bac will do a great review. :-)"  Had a couple of trivial ideas
[14:01] <luca__> gary_poster: do we have a hangout?
[14:01] <frankban> gary_poster: great thanks!
[14:01] <gary_poster> luca__, hatch, Makyo https://plus.google.com/hangouts/_/canonical.com/juju-gui
[14:03] <hatch> morning all
[14:03] <hatch> gary_poster sorry having connection issues
[14:17] <rick_h__> jujuhelp looking for a tip on converting .crt to .cer file? Looks like maybe just base64 encode it?
[14:18] <rick_h__> nvm
[14:19] <hatch> rick_h__ it's gui-help without the dash ;)
[14:19] <rick_h__> hatch: doh
[14:20] <rick_h__> sorry, out of it this morning
[14:57] <gary_poster> hatch up to you
[14:58] <hatch> gary_poster I'll sit back and watch just to get up to speed on it
[14:58] <hatch> my net is shot this am for whatever reason
[14:59] <gary_poster> ack hatch
[15:01] <gary_poster> Makyo, if you can get another qa/review other than me, +1. slammed till the mid afternoon
[15:08] <frankban> gary_poster, bac : thanks for the reviews. gary_poster: since it will be used a lot, I'd like to keep make_aggressive_thunk short, maybe just thunk (not sure)?
[15:09] <gary_poster> frankban, sure.  I was kinda being silly.
[15:09] <frankban> gary_poster: cool
[15:13] <hazmat> luca__, hatch so it looks like we're just going to do sprint logistics in the  mtg and cut it short.. ie. not worth attending.
[15:13] <hatch> ok cool 
[15:38] <Makyo> Gah :/
[15:38] <hatch> sorry!
[15:38] <hatch> :P
[15:39] <Makyo> gary_poster, sorry, I didn't see the meeting alert until I got out of the shower :(
[15:39] <hatch> Makyo summary: networking is hard
[15:39] <Makyo> hatch, haha
[15:40] <hatch> I'm learning so many new acronyms haha
[15:43] <gary_poster> np at all Makyo was very early for you
[15:50] <Makyo> jujugui call in 10
[15:57] <rick_h__>  benji if you get a sec can you verify you can log into http://juju-azure-4loyqnke3w.cloudapp.net:8080/ with your account please?
[15:57] <benji> rick_h__: sure
[15:58] <gary_poster> jujugui call in 2
[16:02] <benji> rick_h__: I was thinking of eating lunch in about 30 minutes and working on the search issue after that, does that work with your schedule?
[16:03] <rick_h__> benji: rgr, sounds good
[16:04] <frankban> Makyo: link to the MP?
[16:04] <Makyo> frankban, https://codereview.appspot.com/39610049/
[16:04] <frankban> ok ty
[16:08] <bac> http://www.youtube.com/watch?v=0RMoH55T-oI
[16:15] <rick_h__> jujugui looks like dns caught up. I'll be watching things in case of issues in transfer but should be back to good for gui landings. http://ci.jujugui.org:8080/
[16:16] <gary_poster> awesome
[16:25] <hatch> rick_h__ turns out it was a double dispatch race condition, solved by pushing the route event to the top of the event stack
[16:25] <hatch> the day we get rid of double dispatch we should have a party haha
[16:25] <rick_h__> hatch: cool yea figured as much
[16:26] <rick_h__> hatch: glad it was a simpl-ish fix
[16:33] <hatch> yeah it's kind of a hack but shhhh don't tell anyone
[16:39] <hatch> jujugui looking for a quick review/qa https://github.com/juju/juju-gui/pull/28
[16:39] <Makyo> hatch,  on it.
[16:39] <hatch> thanks
[16:42] <hatch> jujugui there is one more card to remove the fullscreen code and that's to remove the fullscreen flag from the charm. Does anyone who's working on the charm right now want to do that as a drive-by? Is it a drive-by-able fix?
[16:47] <rick_h__> hatch: I can look into it. I'm tinkering with the charm currently. 
[16:47] <hatch> cool thanks I'll put your face on the card
[16:47] <rick_h__> hatch: put my face on it but not sure if it'll be drive-by or a new branch. 
[16:47] <hatch> yeah no problem
[16:48] <Makyo> hatch, code LGTM, QAing now. 
[16:49] <Makyo> After that, I need to redo my VM on the MBA - software update busted the networking.
[16:51] <hatch> :/
[16:51] <hatch> I feel your pain, I spent over a day trying to get my new vm's up and running
[16:51] <hatch> I gave up and just installed 12.04 heh
[16:54] <hatch> On another note - it looks like Google is building Dart into Chrome 
[16:54] <hatch> still probably a year away though
[16:54] <hazmat> no surprise there
[16:55] <hatch> considering you can write chrome apps with dart, and chrome apps are coming to android, you'll soon be able to write android apps in dart heh
[17:07] <gary_poster> call; logging off IRC till over
[17:09] <benji> rick_h__: it tool longer than I expected, but https://github.com/juju/juju-gui/pull/27 is ready for review; I had to reinstate the ci-check target in order for it to work sanely
[17:09] <rick_h__> benji: rgr, looking
[17:12] <rick_h__> benji: ok, so CI should be running make ci-check but then it still needs make check for lint/test-debug/etc?
[17:13] <rick_h__> and make check will run test-browser, but with local browser so CI will need firefox, etc to run?
[17:13] <Makyo> hatch, +!
[17:13] <Makyo> +1
[17:14] <hatch> THANKS
[17:14] <hatch> oops
[17:14] <hatch> :)
[17:14]  * Makyo rescinds +1 :T
[17:14] <hatch> I love that we now use :shipit: lol
[17:20] <hatch> wow we have a-lot of tickets
[17:26] <hatch> hmm what card to do
[17:27] <benji> rick_h__: is there a way to get Jenkins to do a run with a different config?  I want to switch to "ci-check" instead of check and then run my branch
[17:27] <rick_h__> benji: just edit the config and trigger a manual build
[17:27] <rick_h__> benji: the sha you can pass is origin/pr/27/merge
[17:28] <benji> rick_h__: but that means that anyone else's test runs will fail, right?
[17:28] <rick_h__> benji: or if you wanted true isolation you can create a new job by copying the current one and then doing whatever in there. I'm not sure it's worth it in the low traffic space atm
[17:28] <benji> ok
[17:28] <rick_h__> benji: right, but hatch's branch just landed and not seeing any others in progress
[17:28] <hatch> and mine is the only ones which matter
[17:29] <hatch> me good at engrish too apprently
[17:29] <hatch> BAH
[17:29] <benji> jujugui: Jenkins will be broken for a few minutes, if you see a failure about running the make target "ci-check", it's my fault
[17:42] <benji> rick_h__: I was under the impression that the Jenkins machine has an externally-routable IP; is that not the case?  My code is reporting it as 10.0.0.12
[17:43] <rick_h__> benji: hmm, on azure it's a nasty dns. I'd just use the ci.jujugui.org address
[17:43] <rick_h__> benji: but yes, originally it had an IP
[17:43] <benji> rick_h__: ok
[17:43] <benji> thanks
[17:46] <benji> rick_h__: is there a firewall that would prevent external access to port 8888?
[17:46] <rick_h__> benji: no, not that I'm aware of. There's no firewall on the machine at all
[17:46] <rick_h__> benji: is the daemon listening on 0.0.0.0 vs 127.0.0.1?
[17:47] <rick_h__> daemon/web service
[17:47]  * benji looks

[17:48] <rick_h__> that good eh?
[17:49] <benji> bin/http_server.py uses BaseHTTPServer.test to run itself, which, first, is insane, and second, doesn't seem to allow configuration of where to listen
[17:50] <rick_h__> oh joy
[17:51] <hatch> time to switch to Node
[17:53] <hatch> no? :P
[17:53] <rick_h__> benji: looks like there might be ports. Working on seeing if I can tweak them
[17:54] <rick_h__> benji: so don't change it yet,
[17:55] <rick_h__> still running
[17:56] <rick_h__> benji: ok, 8888 should be opened up. 
[17:56] <rick_h__> http://ci.jujugui.org:8888/index.html
[17:57] <rick_h__> benji: sorry about that, difference between the rackspace vs azure setup
[17:57] <rick_h__> benji: also opening up 8889 so we can run these on different ports for the test job and the -merge job
[17:57] <rick_h__> benji: so we'll need to be able to adjust that from the jenkins build script config
[17:57] <benji> thanks; we may still have a local vs. external IP issue (127.x vs. 0.x)
[17:58] <benji> nope, that looks good
[17:58] <rick_h__> benji: true, but I did a python -m SimpleHTTPServer on 8888 and it worked ok so at least it's open
[17:58] <rick_h__> woot!
[17:58] <benji> rick_h__: is that still running?
[17:59] <rick_h__> benji: no, turned it off
[18:01] <rick_h__> benji: is this running in simulator mode so it's not looking for the wss connection?
[18:01] <rick_h__> oh, there it goes sweet
[18:01] <benji> it's really slow for some reason
[18:02] <rick_h__> this azure machine has seemed a lot slower than the rackspace one we were on :/
[18:04] <hatch> rick_h__ what kind of azure machine are you using? there are quite a few different kinds
[18:04] <rick_h__> hatch: I went witha 2-core basic one
[18:04] <hatch> in typical MS fashion it's divided up into different complex levels of features
[18:05] <rick_h__> "Medium" linux 
[18:05] <hatch> right but which...umm branch?
[18:05] <hatch> hmm
[18:05] <hatch> now I can't remember what they were called heh
[18:05] <hatch> there are ones like ec2, and ones for websites which it turns off 
[18:05] <hatch> if it's not being used
[18:06] <rick_h__> it's a virtual machine
[18:06] <rick_h__> not a website
[18:06] <hatch> ohh ok, so those should stay up all the time then
[18:07] <hatch> and for $95/mo it should be fast lol
[18:07] <rick_h__> :/
[18:07] <hatch> so what were we talking about in the standup?
[18:07] <hatch> do they take these down too?
[18:07] <rick_h__> I've got a call to figure out what's up with that in a bit. I guess MS takes some zones down/away sometimes
[18:07] <rick_h__> I'm not sure at what level that is and such
[18:08] <rick_h__> so I'll find out in a bit
[18:08] <hatch> ohh, I was under the impression it was only for websites
[18:08] <rick_h__> maybe it is and that's the warning. I'm not sure on the details yet
[18:09] <hatch> ohh ok - do we really need a 2core? are we threading now?
[18:09] <benji> rick_h__: it seems that the extream slowness it causing the tests to fail
[18:09] <hatch> :(
[18:10] <rick_h__> benji: try using the azure dns bit vs the cname and see if that helps? juju-azure-4loyqnke3w.cloudapp.net
[18:10] <rick_h__> benji: and I'll see if I can get a direct IP to the machine, the slowness seems network related 
[18:10] <rick_h__> so curious if it's some sort of dns/routing layers in azure?
[18:12] <benji> rick_h__: both of those names resolve to the same IP, so that is not a likely cause
[18:13] <rick_h__> benji: yea, grasping at straws atm
[18:14] <rick_h__> jenkins itself is responding fine, not sure on the gui. 
[18:16] <rick_h__> benji: maybe try production vs debug? It took 14s for me to download the JS files to get things loaded running it manually
[18:16] <hatch> jujugui lf review for trivial inline doc updates https://github.com/juju/juju-gui/pull/29
[18:17] <rick_h__> 282 requests :/
[18:17] <benji> rick_h__: good idea
[18:19] <benji> rick_h__: that won't work because prod wants to connect to a real environment
[18:19] <benji> I guess I could hack on the config, but this is getting crazy
[18:19] <rick_h__> benji: ah, true. :/
[18:22] <rick_h__> benji: why not do it with your branch just to test the theory
[18:22] <rick_h__> benji: adjust the config, see if we can get saucelabs to run on it
[18:22] <benji> rick_h__: already done
[18:22] <rick_h__> if so, then we can see if we need a ci-config or something
[18:22] <rick_h__> benji: awesome
[18:24] <benji> rick_h__: faster but the same error was generated; I now suspect the test sucks
[18:24] <rick_h__> benji: +1 I bet this is existing failures because of the onboarding masking things and such
[18:25] <rick_h__> "Other element would receive the click: <div id="onboarding-header-screen-mask">...</div>"
[18:25] <rick_h__> that's the onboarding mask that's intercepting what we're expecting the test to verify we can click on
[18:25] <rick_h__> benji: so I'd say works, but tests then need update to pass
[18:25] <benji> rick_h__: any idea what causes the onboarding to show up when run remotely but not locally (the tests pass for me locally)
[18:26] <rick_h__> benji: because it's using your browser and if you've ever clicked 'continue' it stores a localstorage key that you've always say ok
[18:26]  * hatch stepping away for lunch
[18:26] <rick_h__> so new page loads will not show the onboarding, while sauce is a fresh browser each time without the local storage
[18:27] <rick_h__> benji: so I'd suggest we create a new job in jenkins to work through getting the sace labs tests passing. 
[18:27]  * benji holds his tongue.
[18:27] <benji> rick_h__: yep
[18:27] <rick_h__> benji: then do cards for fixing the tests, etc and once we get them to pass, go back and put the sace checks into the main lander test suite
[18:27] <rick_h__> sace/sauce
[18:27] <rick_h__> benji: heh, not a fan of the local storage onboarding stuff?
[18:28]  * benji makes weird, muffled sounds; as if he is speaking while holding his tongue.
[18:28] <rick_h__> lol
[18:29] <rick_h__> ok, well when your tongue is free love to hear your thoughts. 
[18:30] <benji> the CI is back to the old config (well, not quite: the environment variable needed for "ci-check" is still there, so we just have to change "check" to "ci-check" once we get the tests fixed)
[18:30] <rick_h__> benji: rgr, thanks
[18:30] <rick_h__> hatch: running your tests and doing your review
[19:20] <benji> rick_h__: https://github.com/juju/juju-gui/pull/27 is now ready for review; I'll make another card for fixing the tests and enabling them in CI
[19:42] <rick_h__> benji: k, will look in a second. Trying to see if I can get it to pass real quick
[19:49] <gary_poster> hey rick_h__ .  Your "remove fullscreen flag from charm" card ends with "get IS to update charm after fullscreen removal".  Should't we just remove that IS part and make a card for a release tomorrow, hopefully?
[19:50] <hatch> gary_poster I assigned the card to him
[19:50] <hatch> don't think he has looked at it yet
[19:51] <gary_poster> ok cool hatch thx
[19:51] <gary_poster> I'll update
[19:51] <hatch> but yes - as long as we are ok with jujucharms not being updated
[19:51] <rick_h__> gary_poster: I'm not sure how removing config values and such work. But yes, the idea is to remove the option from the charm, but make sure that it's done/gone from the deployed config
[19:52] <gary_poster> hatch, we want jujucharms to be updated but after a release.
[19:52] <gary_poster> a gui release
[19:53] <gary_poster> rick_h__, ack.  that means that https://wiki.canonical.com/InformationInfrastructure/WebOps/CDO/JujuGui should be updated
[19:53] <gary_poster> I will note on card
[19:53] <rick_h__> gary_poster: rgr
[19:53] <hatch> right right ok cool
[19:53] <rick_h__> thanks
[19:53] <gary_poster> ty
[19:54] <hatch> new humble bundle btw https://www.humblebundle.com/
[19:57] <rick_h__> benji: got a sec?
[19:57] <benji> rick_h__: sure
[19:57] <rick_h__> benji: https://plus.google.com/hangouts/_/7ecpjvi3krvead11h93mc92ga8?hl=en
[20:08] <rick_h__> bah, note to self, don't monkey with azure settings while waiting on a test run :/
[20:08] <rick_h__> not proper multi-tasking
[20:14] <hatch> hah
[20:17] <rick_h__> benji: ping, can you peek at the end of the build http://ci.jujugui.org:8080/job/juju-gui/124/console ?
[20:17]  * benji looks
[20:17] <rick_h__> benji: it's failing, but it seems only because it can't kill the process it's starting?
[20:18] <rick_h__> benji: do you think we can tweak that to be an || true or something and then we're set?
[20:19] <benji> rick_h__: I intentionally didn't do that because it would mask the failure mode of a pre-existing server (e.g., from a previous test run) which would mean that the test run isn't valid
[20:19] <rick_h__> benji: ah ok. It looks like jenkins auto kills off things based on the link and spawing processes from build? Or am I mis-understanding that perhaps?
[20:20] <benji> I don't think Jenkins killed it, because the job wasn't over yet.  It would be insane for it to kill things while the job is still going.
[20:20] <benji> I don't know why the process was gone when the kill was attempted.
[20:21] <benji> the "Process leaked file descriptors." bit is curious as well
[20:22] <rick_h__> yea, ok. I'm going to rerunand ssh in and watch the content of that pid file vs ps
[20:28] <rick_h__> benji: ah ok, that pid is wrong
[20:28] <rick_h__> in the file is 6406 but it tried to kill 6401
[20:28] <benji> that doesn't seem possible
[20:28] <rick_h__> cat ci-check-gui-server.pid 
[20:28] <rick_h__> 6406
[20:29] <rick_h__> # Stop the background processes.
[20:29] <rick_h__> kill 6401
[20:30] <rick_h__> benji: so 6406 is the ../bin/http_server.py 8888 process
[20:30] <rick_h__> while the other is the shell Xvfb :34
[20:30] <rick_h__> so it should be killing the ci-check-gui-server.pid right?
[20:31] <benji> it should kill both
[20:31] <rick_h__> ah, gotcha. So the first one passes
[20:31] <rick_h__> the second one fails
[20:39] <rick_h__> benji: ok, the Xvfb pid is invalid. It's not running 
[20:40] <rick_h__> benji: what is that doing since we're not running the tests locally?
[20:40] <benji> rick_h__: nothing 
[20:40] <benji> it is there so the local ones will run
[20:41] <benji> I guess we can remove it, at least for the time being, but it is important that these tests be easy to run locally too
[20:41] <rick_h__> ah, ok it's not installed so it's failing
[21:00] <rick_h__> benji: woot, got it to work once. Adding a longer timeout for that initial page load and I think we're in business. Running a final complete test runnow
[21:00] <benji> cool
[21:01] <benji> rick_h__: re. multiple browsers: we'll have to run them one at a time, that's what the charm tests do
[21:01] <rick_h__> benji: rgr, makes sense. 
[21:09] <hatch> has anyone ever seen mocha keep loading the test files in a loop before? 
[21:11] <hatch> tis very odd
[21:16] <hatch> it seems to happen if I put the .only on the describe for the sidebar view
[21:20] <hatch> rick_h__ when doing the `git rebase -i --autosquash` I needed to specify the develop branch
[21:20] <hatch> is this an error in the docs or in my repo?
[21:21] <rick_h__> I've not needed to. Did you branch come from develop?
[21:21] <rick_h__> maybe it's auto picking up the origin for your branch
[21:21] <rick_h__> or you've changed the origin?
[21:21] <hatch> well it says that there is no tracking branch for my branch
[21:22] <rick_h__> hmm, maybe I've got tracking auto enabled? I thought git auto tracked these days
[21:22] <rick_h__> hatch: not sure tbh
[21:22] <hatch> ohhhh
[21:22] <hatch> sorry I see the issue now
[21:23] <hatch> when I did grb there was an error which didn't create the remote repo
[21:23] <rick_h__> benji: I'm going to close your pull request, land mine that's tweaked. Update the -merge job to match the other test one, and I've created cards for multiple browsers and the timeout I coudn't get right
[21:24] <Makyo> Early dog-walk, starting to get rectangular tunnel-vision.  I reproposed https://codereview.appspot.com/39610049/ in case folk think it needs another looking-through; will land after if not.
[21:26] <hatch> jujugui looking for a review/qa on https://github.com/juju/juju-gui/pull/31 plz and thanks
[21:26] <hatch> gary_poster any tasks in mind for me now? 
[21:26] <rick_h__> hatch: your pr fell into the crack here sorry
[21:26] <rick_h__> hatch: have to wait a minute for the merging branch to land until your tests can run successfully
[21:27] <hatch> rick_h__ it's ok, a dev can still review/qa 
[21:27] <hatch> even if CI isn't working yet
[21:27] <rick_h__> hatch: rgr, just a heads up
[21:27] <gary_poster> on call
[21:27] <hatch> cool np
[21:27] <hatch> rick_h__ this removes a lot more of your hard work :P
[21:28] <rick_h__> hatch: quick one is to update the doc links for github :)
[21:29] <hatch> haha is that really a quick one? :P
[21:29] <rick_h__> edit docs, make links go to relative filename?
[21:30] <rick_h__> maybe there's a hidden secret in there
[21:30] <hatch> rick_h__ https://www.humblebundle.com/store/p/europauniversalis4_storefront great game for linux apparently, and 75% off
[21:30] <hatch> yeah I can do that
[21:51] <rick_h__> hatch: ok, ci should be happy
[21:51] <hatch> cool, so you can review my branch then too? ;)
[21:51] <rick_h__> jujugui ci is running sauce tests, it'll take longer and there's a chance of a timeout issue that there's a card to work on. If you hit it then retry
[21:51] <rick_h__> hatch: sorry no, way past my EOD and I've got to get out of here. 
[21:51] <rick_h__> hatch: I can look in the morning
[21:51] <hatch> haha ok np :) thanks for getting CI back up
[21:52] <rick_h__> benji: moved your card to done
[22:00] <hatch> rick_h__ do you know how to create rst links on github?
[22:00] <hatch> just manually?
[22:00] <hatch> or can it generate the index somehow?
[22:06] <hatch> I'm going to guess it's all manual :)
[22:23] <hatch> jujugui lf a quick documentation review https://github.com/juju/juju-gui/pull/32
[22:54] <benji> hatch: CI failed because of a doc error
[22:54] <hatch> benji yup just pushed a fix
[22:55] <hatch> I had to do some reading up on sphynx directives first
[22:57] <hatch> benji looks like the failure is a python one 
[22:57] <hatch> now
[22:57] <hatch> http://ci.jujugui.org:8080/job/juju-gui/135/console
[22:57]  * hazmat digs the domain
[22:58] <hatch> :) I'm not sure where it came from but it is pretty cool
[22:58] <benji> "TimeoutException"  Have you tried turning it off and on again?
[22:58] <hatch> very cool css processor that polyfills real css http://www.myth.io/
[22:58] <hatch> benji haha
[22:59] <benji> ooh, that's nice; and I hate CSS
[22:59] <rick_h__> hatch: that's the timeout issue atm
[22:59] <rick_h__> just retry
[22:59] <rick_h__> I'll look at that in the morning. Need to figure out how to set web driver's page load wait time
[22:59] <hatch> rick_h__ can I retry from github or do I have to do it in jenkins?
[23:00] <rick_h__> loading all the JS from Azure to AWS in debug mode takes a bit :/
[23:00] <rick_h__> hatch: ah crap, right. You don't have an account atm do you
[23:00] <rick_h__> k, sec
[23:00] <rick_h__> hatch: triggered, watch this next build
[23:00] <rick_h__> hatch: if it passes then you can :shipit:
[23:00] <hatch> ok cool
[23:01] <hatch> rick_h__ could we maybe add a :retryci: or something?
[23:01] <rick_h__> hatch: yea, supposedly, but not tried it/hooked it up
[23:01] <hatch> ok cool
[23:01] <rick_h__> for the -merge job it's easy, you delete the comment that it's in progress
[23:02] <benji> I :heart: :shipit:
[23:02] <hatch> haha yeah it's pretty cool
[23:02] <Makyo> http://www.emoji-cheat-sheet.com/
[23:02]  * Makyo helpful
[23:03] <Makyo> Just in case you need :diamond_shape_with_a_dot_inside: in a comment
[23:03] <benji> maybe retry can be :pray:
[23:03] <benji> heh
[23:03] <hatch> haha
[23:03] <benji> "please pass, please pass, please pass"
[23:04] <Makyo> :rewind:?
[23:05] <Makyo> Or :repeat:?
[23:05] <benji> I like :repeat:
[23:05] <Makyo> If our LGTM is going to be a squirrel in a fedora..
[23:06] <benji> :recycle:
[23:06] <hatch> :repeat_one: should probably be retry :)
[23:06] <hatch> making a  release should be :baby_symbol: lol
[23:07] <benji> heh
[23:13] <hatch> benji rick_h__  I just tried to land my branch and I got this error http://ci.jujugui.org:8080/job/juju-gui-merge/35/console
[23:14] <rick_h__> hatch: pull from trunk
[23:14] <rick_h__> git juju-sync
[23:14] <rick_h__> hatch: the ci-merge is in the juju develop branch now but you don't have it
[23:14] <rick_h__> ci-check that is
[23:14] <hatch> ohh ok one sec
[23:15] <rick_h__> hmmm, that sucks though because it's supposed to update trunk before merging your branch.../me adds a card
[23:15] <benji> yeah, that's important
[23:15] <rick_h__> yea, thought it was working :/
[23:16] <hatch> rick_h__ https://github.com/juju/juju-gui/pull/32 here is the pr in case you want a reference
[23:16] <hatch> it's been updated and running the CI again
[23:16] <rick_h__> hatch: yea, got it. I was looking at it to make sure things went ok
[23:16] <rick_h__> :( for no rebase to clean up
[23:16] <hatch> I haven't re merged yet
[23:16] <hatch> I can 
[23:17] <hatch> what's the command for that again?
[23:17] <rick_h__> you've got shipit, it'll land all three commits
[23:17] <rick_h__> git rebase -i --autosquash
[23:17] <hatch> oh git push --force
[23:17] <hatch> well it has the 'merge request accepted' flag
[23:17] <hatch> doesn't that mean it wont try and merge again?
[23:18] <rick_h__> hatch: you're right
[23:18] <rick_h__> hatch: sorry, making dinner, helping the boy with his lego man, and trying to help this through at once. :)
[23:19] <hatch> rick_h__ because it's been pushed rebase was a noop
[23:19] <rick_h__> hatch: gotcha, well you can git rebase -i HEAD~~~ 
[23:19] <rick_h__> or just leave it, worry about it later on. 
[23:20] <hatch> oh nice ~~~ :)
[23:20] <hatch> rebasing
[23:20] <rick_h__> sorry, just noted the 3 commits for a docs branch when checking out the pul request
[23:20] <hatch> I like a clean commit history too
[23:21] <hatch> so this rebase has commits from develop in it...can I squash around them/move the commits around in the list? Ever tried that?
[23:21] <hatch> I better not heh
[23:21] <rick_h__> yea, you can move them so that your commits are in order at the end of the line
[23:22] <rick_h__> if you need to go bac farther in the history use more ~~~~~~~
[23:22] <hatch> that looks to be the same as HEAD~n
[23:23] <rick_h__> yea
[23:23] <rick_h__> sorry, for some reason I'm used to adding ~~~
[23:23] <hatch> ok trying to push the rebase
[23:24] <hatch> oh great I somehow added commits
[23:24] <hatch> ahhhh
[23:24] <hatch> lol
[23:25] <hatch> hopefully git will notice that those commits are already in develop and not re-merge?
[23:26] <hatch> https://github.com/juju/juju-gui/pull/32
[23:26] <rick_h__> we'll see :/
[23:26] <hatch> I just really hope it doesn't break develop
[23:26] <hatch> after the ci finishes i'll delete the flag and see if it merges properly
[23:28] <rick_h__> hatch: rgr, worst case we'll manually hit develop and clean it up
[23:28] <hatch> yeah I have a clean develop branch if need be
[23:36] <rick_h__> woot, thakns hatch 
[23:36] <rick_h__> sorry for the issues there
[23:37] <hatch> no prob, but it looks like it created new commits :/
[23:37] <hatch> https://github.com/juju/juju-gui/commits/develop
[23:37] <hatch> thats less than ideal
[23:37] <rick_h__> oh well, sorry
[23:37] <rick_h__> I led you astray in trying to clean it up
[23:37] <hatch> well....does that mean any time we merge develop into our branches it'll do that?
[23:38] <hatch> or I wonder if it's a side effect of the rebase because the commit sha's are different
[23:39] <rick_h__> I'm not sure, I can't think clearly right now
[23:39] <hatch> heh no problem, I'm also past EOD :)
[23:39] <hatch> we can chat about it in the am
[23:40] <rick_h__> did you move them past your commit?
[23:40] <rick_h__> or before them?
[23:41] <hatch> they were after 
[23:41] <hatch> the same order they are in the commit history
[23:41] <hatch> I didn't actually have to move them
[23:41] <hatch> that's where they were
[23:42] <rick_h__> gotcha, that's why
[23:44] <hatch> I don't follow
[23:45] <rick_h__> so the idea should have been to rebase your commits after everything else in trunk. All the way at the end
[23:45] <rick_h__> you told it to take these commits, and make them after my changes. Which means the tree needed to dupe them in order to do that
[23:45] <hatch> ohhh
[23:45] <hatch> woops
[23:45] <hatch> well guess I learned something new today :)
[23:45] <rick_h__> I *think* anyway
[23:45] <rick_h__> cleaned up
[23:46] <rick_h__> force pushed, carry on
[23:46] <hatch> :)
[23:57] <gary_poster> rick_h__, probably a good/fun idea for future, when comingsoon is no longer ours: run trunk on the jenkins machine, update it based on successful merges (i.e.,from the jenkins job), and make trunk.jujugui.org or something
[23:57]  * gary_poster runs away
[23:57] <gary_poster> thank you rick_h__ and benji for fighting the good fight.  I'll hear the details tomorry