[06:16] <rogpeppe1> urulama: hiya
[06:16] <urulama> rogpeppe1: morning
[06:16] <rick_h__> morning party people
[06:16] <rogpeppe1> rick_h__: yo!
[06:16] <urulama> rogpeppe1: you're early today :)
[06:16] <rogpeppe1> urulama: it happens :-)
[06:32] <bac> rick_h__: ci is still dead, presumably selenium related.  did anyone send you an update yesterday?
[07:17] <rick_h__> bac: no, writing an email now and have a run to see if we found the problem
[07:23] <bac> rick_h__: you going to boardroom at 9:30
[07:24] <rick_h__> bac: yes, the text based UI stuff?
[07:25] <bac> y
[07:25] <rick_h__> jujugui - email sent to peeps on CI issue, working branch has run through tests but is not fit for landing
[08:29] <rogpeppe1> frankban: gogogo?
[08:32] <frankban> rogpeppe1: sure, I'll be there in a minute
[08:33] <urulama> morning frankban
[08:33] <frankban> hi urulama 
[08:33] <urulama> frankban, rogpeppe1: how's "publish" going?
[08:34] <rogpeppe1> urulama: not bad. overwhelmed with overhead yesterday, but back onto the meat of it today. just the tests to write now.
[08:34] <urulama> nice
[11:03] <frankban> rogpeppe1: http://pastebin.ubuntu.com/7978769/
[12:04]  * frankban lunches
[12:14]  * jrwren coffees
[12:18]  * urulama dreams of unicorns 
[12:37] <rogpeppe1> urulama: https://www.youtube.com/watch?v=KPA1fH9wZIg
[13:02] <frankban> rogpeppe1: gogogo?
[13:15] <kadams54> jujugui: Morning all. Before I start another card, I thought I'd check to see if anyone's looking at CI and what, if anything, I could do to help.
[13:21] <jcsackett> kadams54: i am still looking at CI, pursuing the selenium-version issue jeff identified yesterday.
[13:22] <jcsackett> kadams54: if you are able to run make ci-check, and can actually see tests running via the selenium console (follow the url provided by make ci-check), then we might be able to speed things up.
[13:22] <jcsackett> kadams54: wait, you're running a vm, right?
[13:22] <jrwren> what is gogogo?
[13:23] <kadams54> Something impatient people type before an match of League of Legends starts?
[13:24] <kadams54> jcsackett: yes, though I can also see if I can get a dedicated Ubuntu machine up and running. It's something I've been meaning to do for awhile.
[13:25] <jcsackett> kadams54: yeah; sauce and the machine running the tests need to be able to talk, which has been the source of our slowdown. both vms and lxcs (and anything on my home network, since timewarner is blocking the port i need) fail; i've got an ec2 machine coming up now, which is probably faster than you spinning up a dedicated ubuntu machine.
[13:27] <rogpeppe1> frankban: indeed. i missed your ping, sorry
[13:32] <jrwren> kadams54: LoL doesn't glhf?
[13:33] <kadams54> Game starts in 5… 4… 3… 2…gogogogogogogogogo
[13:33] <kadams54> But yes, glhfs are out there too.
[13:34] <jrwren> I see.
[14:13] <bac> jcsackett: \o/
[14:13] <jcsackett> bac: ?
[14:14] <rick_h__> jcsackett: your branch/fix
[14:14] <jcsackett> i may have been premature.
[14:14]  * jcsackett is crossing his fingers that it does actually work in CI.
[14:14] <jcsackett> save the hoorays for when it passes. :p
[14:15] <jcsackett> ...and it just failed.
[14:16] <rick_h__> jcsackett: what do you think of the removal in my reply?
[14:16] <jcsackett> rick_h__: haven't seen your reply yet. 1 sec.
[14:19] <jcsackett> rick_h__: so, the browser warning bit is about handling us popping up the "gui doesn't work on your browser" thing. i think if we remove the handle stuff, and that's the failure, we'll have a hard time sorting that out.
[14:19] <bac> jcsackett: ok, i retract my whoo-hoo.  doesn't look like it did anything.
[14:19] <jcsackett> bac: indeed not.
[14:19] <rick_h__> jcsackett: but we'd have the sauce video that shows it?
[14:19] <bac> s/did/fixed/
[14:19] <rick_h__> jcsackett: e.g. in the video we see a browser warning for a browser that should have no warning?
[14:19] <jcsackett> rick_h__: that's true, i suppose. it just doesn't feel good to me, but i'm happy to be overruled, if only to get back to the card iw as working on before. :p
[14:20] <jcsackett> incidentally, there seems to be no way to run ci-check appropriately. at least not documented.
[14:21] <rick_h__> jcsackett: you know our code has the isBrowserSupported function?
[14:21] <rick_h__> in index.html?
[14:21] <jcsackett> rick_h__: yes.
[14:21] <hatch> it's a very odd issue, the GUI is rendered but it can't access the fn
[14:21] <hatch> you can actually see the canvas and everything but it says the fn doesn't exist
[14:21] <jcsackett> as i said, "isBrowserSupported" not being found is not actually the error. if you run ci-check without even being able to make the connection to sauce labs, you see isBrowserSupported being the failure.
[14:22] <jcsackett> the failure message is useless.
[14:23] <hatch> right - there is a bigger problem - because when CI fails with that error the GUI IS loaded
[14:23] <rick_h__> call guys?
[14:23] <rick_h__> hangout room?
[14:24] <hatch> sure
[14:25] <jcsackett> rick_h__: sure, one sec.
[14:31] <hatch> jcsackett rick_h__  so yeah the isBrowserSupported method IS definitely there
[14:32] <hatch> http://ci.jujugui.org:8888/ < jcsackett 
[14:32] <jcsackett> everyone cross your fingers
[14:32]  * urulama has problems typing now
[14:33] <rick_h__> hatch: cool
[14:33] <hatch> jcsackett interesting...in FF on OSX window.isBrowserSupported() is returning false
[14:33] <jcsackett> hatch: google-chrome on linux is returing false as well.
[14:34] <jcsackett> hatch: so, there's something else going on.
[14:34] <jcsackett> b/c we're setting 2.30.0 for chrome on this thing and it's still dying.
[14:35] <hatch> jcsackett oh you need to pass it `navigator.userAgent`
[14:36] <hatch> at which point it works correctly
[14:37] <hatch> jcsackett trigger another manual ci run, once the GUI is loaded open it in chrome and type `window.isBrowserSupported(navigator.userAgent)`
[14:37] <hatch> chrome on ubuntu that is
[14:37] <jcsackett> hatch: yeah, i saw that too.
[14:37] <jcsackett> still, chrome, with the supposedly correct version of selenium, still fails.
[14:39] <jcsackett> could be the new version of chromedriver/chrome
[14:39] <jcsackett> in which case, we have to fix our test. b/c that would mean it just doesn't work on the latest version of chrome.
[14:40] <hatch> right - but can you check to make sure the fn executes correctly? I'm wondering if it's not the driver that we are using....if the method is indeed there (Which I'm pretty sure it is) then it's the python driver not being able to send the proper command
[14:40] <hatch> jcsackett we could also change that test in python to test for something that WILL be there like Object for example
[14:40] <hatch> if it sill fails then we know for sure it's the driver
[14:42] <jcsackett> hatch: there's a build running now; when it gets to the selenium bit i can see if it works.
[14:42] <jcsackett> hatch: oh, as far as method being there, i can confirm that for sure.
[14:42] <hatch> ahh ok
[14:43] <hatch> brb 
[14:43] <jcsackett> hatch: i just called it without the agent bit and it returned false. but it's there.
[14:43] <hatch> and with the agent?
[14:44] <hatch> ok so next thing to try is modify the browser.py to try and execute something that is DEFINITELY there :)
[14:50] <hatch> jujugui call in 10, kanban now
[14:51] <jcsackett> hatch: it works fine.
[14:51] <hatch> jcsackett well what the deuce.....
[14:51] <hatch> that doesn't make any sense....
[14:52] <jcsackett> hatch: none of this makes sense.
[14:52] <jcsackett> i'm going to try getting an earlier rev of develop to pass through--one that passed before the sauce changes.
[14:52] <hatch> sure 
[15:08] <hatch> jcsackett so what if we remove that test? Does it pass then or do other things fail?
[15:08] <jcsackett> if we remove *every* call to handleBrowserWarning, it passes, as you can see in rick's branch.
[15:09] <jcsackett> but, y'know. there's a reason we're checking on the browser warning stuff.
[15:09] <hatch> yeah - if we supported IE11 we could drop it...
[15:09] <jcsackett> hatch: i'm verifying the chromedriver thing by running a build that uses the old default chrome and chromedriver.
[15:09] <hatch> ok excellent
[15:10] <jcsackett> if that passes, i think the critical situation is over--we land that branch and add a card for investigating CI on chrome 35+
[15:10] <jcsackett> b/c previously we've been running everything on the old default anyway, so we're not in any *worse* of a position.
[15:11] <jcsackett> and we're unblocked. but we definitely don't want to be stuck on an increasingly old version of chrome.
[15:11] <hatch> right - *crosses fingers*
[15:13] <jcsackett> well, good news: my incidental upgrade to ff 31 passes.
[15:13] <jcsackett> not the good news we want, but good news all the same.
[15:14] <hatch> haha need every ittle win
[15:14] <jcsackett> PASSED!!!
[15:14] <jcsackett> well, the first test.
[15:14] <jcsackett> but the first test was failing.
[15:14] <hatch> ...
[15:14] <jcsackett> so, this is looking good.
[15:14] <hatch> ......
[15:15]  * hatch is in suspense 
[15:15] <jcsackett> passed the second one.
[15:15] <jcsackett> chrome has passed.
[15:15] <jcsackett> the new chrome/chromedriver is the issue, and this unblocks us.
[15:16] <hatch> *phew*
[15:16] <jcsackett> i'll tidy up the PR and ask for reviews, and make a card to investigate new chrome on CI.
[15:16] <hatch> ok ping when it's up and I'll +1 it
[15:16] <hatch> :)
[15:16] <hatch> jcsackett can you also send out an email to peeps with the details?
[15:20] <jcsackett> hatch: already writing it.
[15:20] <hatch> u da man
[15:21] <jcsackett> jujugui: 2 reviews, please. https://github.com/juju/juju-gui/pull/484
[15:21] <hatch> on it
[15:22] <kadams54> Ditto
[15:22] <frankban> jcsackett: done
[15:22] <jcsackett> thanks, all.
[15:23] <hatch> jujugui I'll handle getting everything landed once this lands
[15:23] <kadams54> hatch's new job title: PR Wrangler
[15:23] <hatch> yeeeee haw
[15:23] <kadams54> Excuse me… PR Herder
[15:24] <kadams54> https://www.youtube.com/watch?v=1SmgLtg1Izw
[15:24] <hatch> not sure what sound herders make
[15:24] <kadams54> Yeeee haw is appropriate.
[15:24] <hatch> dig
[15:27] <jcsackett> wtf; something else just failed.
[15:28] <hatch> looks to still be running...
[15:28] <hatch> http://ci.jujugui.org:8080/job/juju-gui/1565/console
[15:28] <jcsackett> hatch: that's the run triggered by comments.
[15:29] <jcsackett> hatch: the run with the test change failed, but i think it's the spurious failure. we'll see what the comments one does.
[15:29] <hatch> ohh that's a spurious failure
[15:29] <hatch> yeah
[15:30]  * jcsackett lets out a breath
[15:30] <jcsackett> thank god.
[15:31] <hatch> haha
[15:31] <hatch> jcsackett pm me the email you want to use for KB
[15:37] <rogpeppe1> urulama, jrwren: https://github.com/juju/charmstore/pull/62
[15:37] <rogpeppe1> frankban: ^
[15:41] <urulama> rogpeppe1: TBH, my brain is not capable to do PR right now ... in a few hours i can do it
[15:47] <frankban> urulama: np, thanks
[16:14] <frankban> rogpeppe1: we missed one test: wrong hash provided
[16:15] <rogpeppe1> frankban: ah yes. good point.
[16:15] <frankban> rogpeppe1: and actually it seems the check is not done by PutForEnvironment
[16:15] <rogpeppe1> frankban: ah
[16:15] <frankban> rogpeppe1: I was able to upload a charm using something like "curl -ikL --data-binary @$2 -H "Content-Type: application/zip" http://127.0.0.1:8080/v4/$1/archive?hash=ciao"
[16:17] <rogpeppe1> frankban: ah, of course. PutForEnvironment doesn't know the hash that it's meant to be uploading
[16:17] <rogpeppe1> frankban: hmm
[16:17] <rogpeppe1> frankban: that means that we can't actually use juju/blobstore without changing it
[16:18] <rogpeppe1> frankban: good catch. darn.
[16:19] <rogpeppe1> frankban: at the least, we could change PutForEnvironment to return the actually created hash
[16:20] <rogpeppe1> frankban: or to have an optional hash passed in that it could check
[16:22] <frankban> rogpeppe1: yeah, I am surprised this check is not done already somewhere in managedstorage
[16:30] <frankban> rogpeppe1: so, if the path and the hash are two different concepts in blobstore, it would be nice if we are able to inject a checker into PutForEnvironment. If PutForEnvironment to returns the actually created hash, that means for each blob with invalid hash we write it to mongo and then delete it. Providing an expectedHash seems specific to our use case at this point.
[16:30] <rogpeppe1> frankban: yes
[16:37] <hatch> heyyal what are you using in Ubuntu for irc? Quassel looks like a good candidate 
[16:38] <jcsackett> in unity? xchat. otherwise weechat.
[16:39] <hatch> yeah in Unity
[16:39] <hatch> xchat is just so ugly
[16:39] <hatch> :)
[16:40] <lazyPower> hey hatch - gimme some PeerReview? http://askubuntu.com/questions/507521/juju-charm-relation-hooks-are-not-running/508158#508158
[16:40] <hatch> lazyPower on it
[16:40] <hatch> I already did
[16:40] <hatch> see that upvote
[16:40] <hatch> <---- this guy
[16:40] <hatch> :D
[16:41] <lazyPower> haha
[16:41] <lazyPower> niiiiiice
[16:41] <hatch> now I know why the charm reviews take so long - your busy writing proper AU responses :P
[16:41] <lazyPower> :)
[16:42] <lazyPower> i've had a slew of people contacting me privately in email for help. I'm redirecting them to AU for public knowledge
[16:42] <frankban> rogpeppe1: something like http://pastebin.ubuntu.com/7981133/ ? It's bad that in that case we'd need to modify the ManagedStorage interface
[16:43] <jcsackett> hatch: i change the color scheme; there are various themes.
[16:43] <hatch> jcsackett have you used quassel? It really does look nicer 
[16:43] <hatch> :)
[16:43] <hatch> lazyPower excellent idea
[16:43] <lazyPower> Quassel for the win. love it.
[16:43] <lazyPower> use it on my phone, tablet, desktop, laptop
[16:44] <hatch> android?
[16:44] <jcsackett> hatch: it's a kde app, though, so the icons don't match up with everything else. or at least they didn't last time i installed it.
[16:44] <hatch> or utouch
[16:44] <lazyPower> droid. i dont see a utouch app for it.
[16:45] <hatch> jcsackett ohh, I'll have to check, I bought the numix gtk3 light theme
[16:45] <hatch> so it comes with a slew of icons
[16:46] <hatch> still can't figure out why the unity dash takes so darn long to open
[16:46] <hatch> when the task-search one is instant 
[16:49] <hatch__> Yeah you're right the icons don't match at all heh
[16:52] <jcsackett> yeah.
[16:52] <jcsackett> these days i'm a big fan of weechat.
[16:53] <jcsackett> but that's a terminal app, and if you're using unity, it doesn't integrate with the messagemenu at all, which is vexing.
[16:59] <jrwren> irssi 4 life.
[17:00] <jrwren> I may or may not have that tatoed on my person.
[17:02] <hatch> lol, on your neck probably, amiright?
[17:03] <rogpeppe1> frankban: i wouldn't make the checkers so general. i'd just pass in an expected hash
[17:04] <rogpeppe1> frankban: which can be checked immediately after preprocessUpload
[17:05] <frankban> rogpeppe1: and if empty the check is not done?
[17:05] <rogpeppe1> frankban: yes
[17:05] <frankban> rogpeppe1: that would work, sure
[17:05] <rogpeppe1> frankban: perhaps a *blobstore.ResourceHash
[17:06] <rogpeppe1> which is nil if the check isn't done
[17:09] <hatch> spurious test failure....ugh.....I swear these branches will land eventually!
[17:10] <hatch> can someone ping  juju gui and gui help for me so I can test my new alerts
[17:13] <frankban> rogpeppe1: we will need a blobstore.v2 :-/
[17:13] <rogpeppe1> frankban: well, blobstore isn't gopkg.in, so i guess it can just change in place
[17:14] <kadams54> jujugui guihelp
[17:14] <kadams54> guihelp
[17:14] <hatch> well they highlighted but no ding or notification
[17:14] <hatch> thanks kadams54
[17:14] <hatch> guess I'll have to look into that
[17:15] <frankban> rogpeppe1: well, my point is that we should put in gopkg.in. otherwise I'm not sure about when dependencies should be versioned and when not
[17:16] <rogpeppe1> frankban: i agree.
[17:16] <rogpeppe1> frankban: let's just call it v1
[17:24] <frankban> rogpeppe1: sure, done for the day, have a nice night
[17:24] <rogpeppe1> frankban: g'night
[17:39] <hatch> man I'm having no luck with this charm release - I keep getting huge diffs which cause things to fail hard
[17:40] <hatch> jujugui does anyone else want to take a stab at making the precise charm release? 
[18:38] <hatch> jujugui anyone know how I undo a merge in bzr? I havent committed but I want to reset it to HEAD
[18:40] <hatch> revert
[18:40] <hatch> found it :)
[18:46] <hatch> python ppl, what would cause the charm `make lint` to fail with a compiler error from pip?
[18:46] <hatch> says no Python.h ?
[18:47] <hatch> ^ jujugui
[18:47] <jrwren> missing python-devel package
[18:47] <kadams54> python-dev not installed
[18:49] <hatch> thanks
[18:49] <hatch> so....why does something in lint require building python from source?
[18:52] <hatch> ok here is a new one
[18:52] <hatch> python/apt_pkgmodule.h:14:28: fatal error: apt-pkg/hashes.h: No such file or directory
[18:52] <jrwren> did you run make sysdeps?
[18:52] <hatch> negative
[18:52] <hatch> that's not in the instructions lol
[18:53] <hatch> will try that
[18:53] <kadams54> I suspect make lint is running a python library, which needs it and all its dependencies downloaded, optionally compiled, and installed.
[18:54] <jrwren> make sysdeps would have installed a bunch of debs for you, including libapt-pkg-dev (which gives that missing file)  and would have got libpython-dev too.
[18:54] <hatch> sounds like we should be including the compiled versions
[18:54] <hatch> but hey lint passed
[19:09] <hatch> kadams54:  hey any luck on that truncation stuff? 
[19:15] <kadams54> hatch: no, though to be honest I kinda forgot about it and was starting on the other card.
[19:15] <kadams54> Which reminds me that I was going to check in with you on what you'd found.
[19:16] <hatch> yeah so this is actually a pretty large issue with how the callbacks are executed
[19:16] <hatch> because we are creating 'ghost' models then removing them and allowing the new ones to be created via the delta
[19:16] <hatch> the time between there there is no model and as such, no UI
[19:17] <hatch> so the proper fix is to have the delta update the appropriate models instead of removing it
[19:17] <hatch> which is an architectural change to how the ecs/env handles it now
[19:17] <hatch> the other approach (which I don't like as much) is to wait until the delta comes in then remove the old one and create a new one
[19:22] <hatch> kadams54:  that match the direction you were working on already?
[19:22] <kadams54> Sure
[19:22] <kadams54> ;-)
[19:22] <kadams54> Why would you rather update than remove and re-create?
[19:23] <kadams54> updating seems like asking for stale data
[19:23] <hatch> there is a lot of infrastructure attached to the existance of the record
[19:23] <hatch> so when they go away/come back lots of things happen
[19:23] <hatch> at scale that could cause the thread to lock up
[19:24] <kadams54> k
[19:24] <kadams54> any gotchas?
[19:24] <hatch> probably....it's the ecs/env
[19:24] <hatch> :P
[19:24] <hatch> that's as far as I got - it's a pretty big change - the env has used the same callback system since day one
[19:25] <hatch> now we are changing it
[19:25] <kadams54> ha ha… *sobs
[19:25] <hatch> if you like you could defer that to either frankban or i
[19:25] <kadams54> i may
[19:25] <hatch> or matt, I think he is back monday
[19:28] <rick_h__> hatch: why don't you like doing the callback on seeing the new item?
[19:28] <hatch> rick_h__:  that's not how it works, atm the callback is fired when juju says "yep I hear ya" we need to wait until the delta comes in then act
[19:29] <rick_h__> hatch: right, but you mention you're not a fan of waiting for the delta to do the callback?
[19:29] <hatch> sorry I meant that I didn't want to remove the old model and create a new one vs just updating the old one
[19:29] <hatch> (after re-reading I see that wasn't clear)
[19:30] <hatch> both approaches require acting when the delta comes in vs the OK from juju
[19:30] <rick_h__> kadams54: definitely feel free to delay on it if you want. 
[19:31] <rick_h__> hatch: right, we need to do some adjustment for sure.
[19:32] <hatch> I THINK I've finally got the charm tests to pass successfully 
[19:32] <hatch> will see in a bit :)
[19:32] <rick_h__> charm tests? woot?
[19:32] <rick_h__> what blew up the charm tests?
[19:32] <hatch> for the precise release
[19:32] <hatch> no idea....there were a ton of changes causing conflicts and whatnot - I emailed Matt to find out why there were so many changes
[19:33] <hatch> but he is off so will have to wait to see
[19:33] <hatch> I won't push it until I hear back though
[19:33] <rick_h__> ok
[19:33] <kadams54> hatch, rick_h__: OK, taking a different card
[19:33] <hatch> LP even shows commits without diffs which is very odd
[19:33] <hatch> so something got borked up real good
[19:33] <hatch> somehow
[19:34] <hatch> rick_h__:  good news is that CI is back up and running though 
[19:34] <rick_h__> hatch: saw that, thanks for the work on that + jcsackett 
[19:35] <hatch> it was mostly jcsackett - I was the monkey poking the other monkey with the stick
[19:35] <hatch> I was *just
[19:35] <hatch> :)
[19:35] <rick_h__> :P
[19:40] <hatch> *sigh* I spoke too soon the test failure for the precise charm is still there....
[19:42] <rick_h__> hatch: if you're not sure what's up don't force it. A few more days to figure out the charm won't hurt. Maybe also lean on frankban if he's around tomorrow
[19:43] <hatch> yeah I think I might do that - it's very odd because the code is identical between precise and trusty but precise is the only one which is failing
[19:45] <hatch> I'll fire him an email, hopefully he will have some better luck - I would like to get some real work done :) 
[19:45] <hatch> everyone should be on trusty anyways.....right?
[19:45] <hatch> :)
[20:20] <lazyPower> hey hatch, you got a minute?
[20:20] <lazyPower> i'm getting a really strange error from the GUI about the bundle not being a zip file
[20:20] <lazyPower> and i'm not sure if this is gui or deployer
[20:20] <lazyPower> http://paste.ubuntu.com/7982560/
[20:21] <lazyPower> but that bundle looks perfectly acceptable
[20:25] <lazyPower> nevermind, looks like the charms weren't ingested yet
[20:27] <hatch> lazyPower:  sorry stepped away for a sec
[20:27] <lazyPower> its cool, we discovered the root of all evil is ingest
[20:27] <hatch> yeah it's pretty horrible
[20:27] <hatch> :)
[20:33] <rick_h__> but it's going to go away so yay! :)
[20:43] <hatch> haha
[21:32] <hatch> jcsackett:  hey you use github hub right? Do you like it?
[21:36] <hatch> doesn't look like anything quite beats the functionality of GRB
[22:00] <jcsackett> hatch: i am a huge fan of hub.
[22:01] <hatch> jcsackett:  so I frequetly use `grb create` and `grb delete` which creates a local branch, pushes it to the remote, and then tracks it
[22:01] <hatch> the latter of course undoing that but only deleting the local if the source has been merged
[22:01] <hatch> does hub have anything like that? it doesn't appear so
[22:02] <jcsackett> not really, no.
[22:02] <jcsackett> but hey, aliases.
[22:02] <hatch> yeah, so what does hub give you that makes you be a fan?
[22:03] <hatch> like what features do you find very useful
[22:03] <jcsackett> hatch: git checkout $pullrequesturl
[22:03] <jcsackett> it also just cleans up a lot of commands so it's easy to work with github style repos.
[22:03] <jcsackett> also git pull-request -b develop -m "message"
[22:03] <hatch> ahh yeah that one would be helpful
[22:05] <hatch> hmm I'll have to give it a try
[23:13] <huwshimi> Morning
[23:22] <hatch> morning huwshimi
[23:22] <hatch> CI is back up and running
[23:23] <huwshimi> yay!
[23:35] <hatch> huwshimi:  so how goes the x uncommitted branch?
[23:35] <hatch> it's been hanging in starting for a while :)
[23:36] <hatch> kadams54:  hey I also have input on your card in starting :D
[23:37] <huwshimi> hatch: Yeah, that's because I keep starting other things because it's annoying
[23:42] <hatch> haha - ok it's just been sitting there so haven't had anything to say in the standup