[00:06] <hatch> hmph I found a databinding test that was passing by accident
[00:06] <hatch> hehe oops
[00:12] <hatch> only 99 more test failures to go!
[00:12] <hatch> 99 test failures on the wal....99 test failures
[00:12] <hatch> you knock one down, re-run the tests, there's 98 test failures on the wall
[00:21] <hatch> 98
[00:21] <hatch> :)
[00:26] <hatch> 86 aww yeah
[00:30] <rick_h> lol, what did you do to break things so?
[00:32] <hatch> 70!!
[00:32] <hatch> aww man I'm killin it
[00:33] <hatch> rick_h: haha too many flybys
[00:33] <hatch> I'm not even finished this branch but I have to land it because of the flyby bug fixes/enhancements
[00:42] <hatch> yup so many failing tests because of small driveby fixes
[00:42] <hatch> bcsaller: still around by chance?
[00:43] <bcsaller> yeah
[00:43] <hatch> so I think the unit count driveby broke the google analytics code
[00:43] <hatch> because we no longer use ServiceUnitList correct?
[00:44] <hatch> the test that's failing is test_model.js:158
[00:44] <bcsaller> looking
[00:45] <hatch> my mind is fried I should probably take a break
[00:45] <hatch> after this test!
[00:45] <bcsaller> hatch: iirc we didn't remove the global list (I wasn't sure what was using it) so the delta should update both
[00:45] <bcsaller> and the update_agg... method does get called, we saw that yesterday
[00:46] <hatch> yup but I think that the || 0 is causing the test to fail
[00:48] <bcsaller> ahh, because it was changed to take the current unit list size so prev never differs from sum
[00:48] <hatch> well sort of
[00:48] <hatch> in investigating sum is 0 instead of 1
[00:49] <bcsaller> I think its an ordering issue, it was using the cached value of unit_count, but taking the size of that unit_list directly depends on the order of the update in the delta code 
[00:49] <hatch> just grabbing the old code to look at it
[00:51] <hatch> ahh
[00:51] <hatch> aggregate
[00:51] <hatch> Object {pending: 1}
[00:51] <hatch> so yep you're right...
[00:51] <hatch> hmm
[00:52] <hatch> so we still need a 'total' sum for analytics
[00:52] <hatch> ick that doesn't feel right
[00:52] <bcsaller> we have total, its the prev value thats getting lost
[00:53] <hatch> well no at the time of the check there are 0 units in the service
[00:53] <hatch> but there is 1 in pending in the aggregate
[00:53] <bcsaller> service.units.size() is total, but the old size of that list is the thing in question
[00:53] <hatch> prev_total_units is undefined in the test
[00:53] <bcsaller> ahh, sounds like the order is opposite from what I thought it would be then
[00:54] <hatch> yeah so it should probably be reverted then?
[00:54] <hatch> I'm thinking that to properly fix this is going to be more than a quick driveby
[00:54] <bcsaller> that is simplest or move the _gaq code into the handlers module and do it on a serviceunitslist after change 
[00:54] <bcsaller> yeah, I'm fine with a rollback
[00:54] <hatch> heh gaq
[00:55] <hatch> I think that's the proper place to move it but this branch has so many drivebys already
[00:55] <hatch> how about I create a ticket for this change?
[00:59] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1212897
[00:59] <_mup_> Bug #1212897: Update service unit aggregate function to use new service unit location  <juju-gui:New> <https://launchpad.net/bugs/1212897>
[01:05] <hatch> only 1 failure now!
[01:05] <hatch> AssertionError: expected '2w' to equal '3'
[01:05] <hatch> uhh wut?
[01:05] <hatch> lol
[01:09] <hatch> w00t 0!
[01:09] <hatch> now to make sure the app still works after I fixed all the tests lol
[01:11] <hatch> *sigh*
[01:18] <hatch> bcsaller: I think there is a bug in your fix
[01:18] <hatch> the prevValue stuff is now reporting the incorrect key sometimes
[01:19] <bcsaller> hatch: unexpected or wrong, if you queue two changes to a key in a single window what do you expect to see, the first value or the second?
[01:21] <hatch> do you have a second to look at the code? I can push it up
[01:22] <hatch> bzr branch lp:~hatch/juju-gui/scale-up-ui
[01:22] <hatch> databinding.js:172 the bindingName and the e.changed object sometimes don't match
[01:27] <bcsaller> hatch: looking now
[01:29] <bcsaller> hatch: you set it on the binding, which is the object describing the relationship between the model and the DOM, it is not a per-change datastructure
[01:30] <bcsaller> so the issue in the preVal stuff
[01:30] <bcsaller> need a hand with a fix?
[01:31] <hatch> haha I guess I thought that this was the place to modify the delta
[01:31] <hatch> I essentially wanted to augment the detla object with it's previous value
[01:36] <bcsaller> yeah, there isn't really an object like that because the updateDOM handles that relationship in a fixed way. Getting the preVal and saying its the first value of a buffered update window to change on the model makes sense to add, but it would have to be managed in the event layer, not the in bindings
[01:37] <hatch> so is it looking like adding the prev value stuff now is going to be an issue?
[01:37] <hatch> as in not just a few lines?
[01:52] <huwshimi> Turns out what I thought I'd broken behaves the same in trunk...
[01:53] <rick_h> huwshimi: yay! / booo!
[01:54] <huwshimi> rick_h: Yeah, what a waste of time! :)
[01:54] <rick_h> huwshimi: make sure you keep up the current work on the cards so jcsackett and I don't dupe IE work 
[01:55] <huwshimi> rick_h: Sure
[01:56] <rick_h> huwshimi: thanks
[01:56] <huwshimi> rick_h: Although apparently we can only have two active cards :(
[01:56] <bcsaller> hatch: I think it might still be a few lines, just different lines, we'd keep a mapping like we do with the keys that exists between updateDOM intervals, when we get a change for a key not in the map we record its preVal in that map and then feed that as an additional argument to update calls, then clear it at the end of updateDOM
[01:56] <rick_h> huwshimi: I've been overriding with the exception "Die IE Die"
[01:57] <huwshimi> rick_h: haha
[08:50] <rogpeppe> does anyone know how to use the new charm browser to list all available charms?
[11:34] <rick_h> rogpeppe: hit enter in the search box
[11:34] <rick_h> rogpeppe: and if you want *all* uncheck the reviewed/series default checkboxes in the filters
[11:35] <rick_h> rogpeppe: https://jujucharms.com/fullscreen/search/?text= is the url that you end up with. 
[11:42] <rogpeppe> rick_h: thanks. i was sure i tried that...
[12:00] <rogpeppe> rick_h: i actually ended up using the charm tool, ("charm list" followed by a fair amount of manual text mangling)
[12:05] <rick_h> rogpeppe: k
[12:06] <rogpeppe> rick_h: i'd still like to be able to fetch a definitive list of all the charm urls in the charm store
[12:06] <rogpeppe> rick_h: i've just realised i've probably missed a load, as i only fetched charms in ~charmers or in lp:charm/xxx
[12:07] <rick_h> rogpeppe: http://manage.jujucharms.com/api/2/charms?text=
[12:07] <rick_h> rogpeppe: you can use the api like the gui does. Sec, let me get the docs
[12:08] <rick_h> rogpeppe: http://bazaar.launchpad.net/~juju-jitsu/charmworld/trunk/view/head:/docs/api.rst
[12:08] <rogpeppe> rick_h: awesome! that's just what i want, i think
[12:11] <rogpeppe> rick_h: thanks a lot
[12:12] <rick_h> rogpeppe: get what you need? we do have this bug out there, but it sounds like you wanted the urls directly so not sure it would have helped. #1202306
[12:12] <_mup_> Bug #1202306: We need an "all" category <juju-gui:Triaged by lucapaulina> <https://launchpad.net/bugs/1202306>
[12:13] <rogpeppe> rick_h: yeah, it looks exactly what i need, and a nice regular format, trivial to parse in go.
[12:13] <rick_h> rogpeppe: cool, the only ones missing would be bad charms we can't import. Just a disclaimer to the final list
[12:14] <rogpeppe> rick_h: ah, well, i don't mind too much about them.
[12:37] <rogpeppe> rick_h: FWIW, here's my little script that downloads all known charms from the store: http://paste.ubuntu.com/5992556/
[12:38] <rick_h> rogpeppe: cool, apis ftw
[12:38] <rogpeppe> rick_h: they weren't all valid
[12:38] <rogpeppe> rick_h: but i successfully got 663
[12:38] <rogpeppe> rick_h: yeah!
[13:42] <sinzui> bac, abentley. Do either of you have time to review https://code.launchpad.net/~sinzui/charmworld/modern-py/+merge/180562
[13:42] <abentley> sinzui: Sure.
[13:47] <abentley> sinzui: r=me.
[13:50] <hatch> morning
[13:50] <rick_h> morning party people
[13:51] <jcsackett> morning all.
[13:52] <hatch> yay for IE fixes you guys rock
[13:52] <rick_h> :P
[13:53] <rick_h> hatch: can you do the second review on huw's this morning please?
[13:53] <hatch> I can yep
[13:53] <rick_h> I think with that, Makyo's icon fixes, and jcsackett's in progrss branch that closes up the ones we had cards for at least
[13:53] <rick_h> just that drag/drop 'odd' one left in launchpad
[13:54] <hatch> rick_h: that one is fixed
[13:54] <hatch> I landed a fix for that last week
[13:55] <hatch> updated the ticket
[13:55] <hatch> sry
[13:55] <hatch> having fix committed and in progress the same color makes it hard to scan...
[13:56] <rick_h> hatch: ah, gotcha
[13:57] <rick_h> oops, my bad jcsackett. I was going through reviews this morning and it was open with the old code
[13:58] <hatch> horrible person allert
[13:59] <jcsackett> rick_h: it's up with the right code for review now.
[13:59] <jcsackett> https://codereview.appspot.com/12760045/
[13:59] <rick_h> jcsackett: thanks looking
[13:59] <rick_h> "You do not have permission to view this issue"?
[14:00] <hatch> that's what you get for being a horrible person :P
[14:00] <rick_h> jcsackett: is there a note on what the span with class absolute is for?
[14:00] <jcsackett> rick_h: zuh? that's deleted.
[14:00] <jcsackett> i don't see it in the MP when i'm looking.
[14:00] <rick_h> jcsackett: looking at the LP review
[14:01] <rick_h> https://code.launchpad.net/~jcsackett/juju-gui/ac-moves-the-screen-down/+merge/180363 ?
[14:01] <jcsackett> rick_h: go to https://codereview.appspot.com/12760045/
[14:01] <rick_h> jcsackett: I can't, see error above ^
[14:01] <jcsackett> rick_h: nuts to this. i'm deleting it all, will ping when i've got it resubmitted.
[14:02] <jcsackett> i have no idea why LP is showing one thing and rietveld is showing another.
[14:02] <rick_h> jcsackett: ugh and ugh. Thanks
[14:05] <benji> abentley: thanks for the good review of my branch, it is in the process of merging, but I though you might be interested in the tweaks I made to address the points you raised: http://bazaar.launchpad.net/~benji/charmworld/update-bundle-api/revision/350
[14:10] <abentley> benji: Have you tested that non-dict values are jsonified correctly?  Because lists and strings and bools are instances of object.
[14:10] <hatch> jcsackett: I was pretty sure that the autocomplete list box was set to position absolute by default
[14:10] <hatch> are we sure we aren't missing any classes?
[14:10] <jcsackett> hatch: rick_h and i both looked at this. it is set by default in all browser but IE10
[14:11] <benji> abentley: ooh, that's a good question; I'll add tests to that effect and see what comes
[14:11] <hatch> seriously?
[14:11] <hatch> ugh
[14:11] <hatch> that sounds like a YUI bug
[14:12] <rick_h> hatch: so somehting was setting it in the actual element with style="xxx yyy position: relative"
[14:12] <rick_h> hatch: I couldn't dupe it in defualt yui examples in IE
[14:12] <rick_h> in other browsers there was no edits to the element with a manual style=""
[14:12] <rick_h> hatch: so not sure where it was coming from tbh
[14:12] <rick_h> hatch: and since chrome/etc aren't doing it I can't set a breakpoint on dom changes 
[14:13] <hatch> aww damn that sucks
[14:13] <rick_h> hatch: yea, it's hacky, and no idea why it's mis-behaving. but it works :/
[14:13] <hatch> I'll take one review/qa on it
[14:14] <hatch> rick_h: are you going to land huw's branch?
[14:14] <rick_h> hatch: I wasn't going to no. I figured it's not a rush and he can land it as long as he gets the two reviews
[14:15] <hatch> ehh that won't be until monday
[14:15] <hatch> I can do it later
[14:15] <antdillon> Hi guys, I have a prototype for Luca and he would like it hosted somewhere. How do you host a fork of the juju-gui?
[14:15] <rick_h> hatch: but it's friday. I'm not going ot notice it :)
[14:15] <jcsackett> rick_h, hatch: the MP is back up. https://codereview.appspot.com/12932044
[14:16] <hatch> rick_h: haha - well if I have time I'll land it...we'll see :)
[14:16] <rick_h> jcsackett: thanks
[14:17] <luca> Makyo: bcsaller hey, are you guys there?
[14:18] <hatch> antdillon: luca if it's just for a short time you could put it on ec2
[14:18] <hatch> I'm not sure if you have your juju env's set up though
[14:18] <rick_h> antdillon: yea, normally we run them on ec2 or something and point everyone at the url
[14:19] <hatch> I used git yesterday - I had to look up the equiv for 'bzr info' heh oh boy I'm out of touch
[14:20] <rick_h> hatch: lol
[14:20] <hatch> I even know how to diff in bzr now like a boss...
[14:20] <hatch> I have leveled up
[14:20] <antdillon> rick_h, hatch Cool, how would I get it on ec2?
[14:20] <hatch> antdillon: hopes and dreams.....hopes and dreams
[14:21] <hatch> but for real....do you have a juju env set up?
[14:21] <hatch> :)
[14:21] <antdillon> hatch, Ran out of them a long time ago
[14:21] <hatch> haha
[14:21] <antdillon> hatch, Locally I do, nothing else where
[14:21] <rick_h> antdillon: heh, you can be a docs guinea pig for marcoceppi and company :) https://juju.ubuntu.com/docs/getting-started.html
[14:21] <hatch> ok so yeah you can follow those docs
[14:22] <hatch> or try and find one of us with some time to put it up for you :)
[14:22] <antdillon> hatch, I'll trail the docs and see how I get on :)
[14:22] <Makyo> luca, hey, sorry, little late.  Here now.
[14:22] <antdillon> rick_h, Thanks
[14:23] <hatch> antdillon: sure thing - let us know if you run into any issues
[14:23] <hatch> you'll require an ec2 account of course
[14:24] <hatch> jcsackett: LGTM QA OK
[14:26] <hatch> oh Windows 8.... "Shutdown" "Update and restart" umm I think it's missing an option there
[14:26] <hatch> except I think shutting down also installs the updates heh
[14:28] <hatch> rick_h: at the sprint/ sometime else I'd like a hand fixing my vim/terminal setup, somehow I managed to turn http://vim.spf13.com/ into a white background with white text in vim
[14:28] <hatch> lol
[14:29] <rick_h> hatch: lol, ok. Sounds good
[14:29] <hatch> I'm sure I'm missing something but I just can't figure out where these styles get applied
[14:29] <rick_h> :colorscheme
[14:29] <rick_h> :colorscheme <tab> to get a lits of ones available
[14:29] <luca> Makyo: can we talk scaling?
[14:29] <rick_h> and maybe that can get you unstuck for a moment
[14:29] <Makyo> luca, sure.
[14:30] <hatch> rick_h: yeah I have to do :color ir_black every time I open it
[14:31] <hatch> https://github.com/seebi/tmux-colors-solarized I attempted this first
[14:31] <hatch> also with varying degress of success
[14:31] <hatch> heh
[14:31] <hatch> man I can not type today
[14:33] <rick_h> hatch: well look for 'colorscheme' in your ~/.vimrc
[14:33] <rick_h> hatch: it should be set in there, maybe twice if running different colors for cmd-line vs gui
[14:33] <hatch> I think there is a conflict between the colorschemes and the tmux/zsh themes
[14:33] <luca> Makyo: guichat?
[14:33] <Makyo> luca, sure, on my way.
[14:33] <hatch> luca: are you talking the sclaeup/down?
[14:33] <hatch> I'm working on that right now, mind if I join?
[14:43] <benji> abentley: I added tests for serializing non-mapping types and made them pass; thanks
[14:44] <abentley> benji: Cool.
[14:50] <Makyo> jujugui call in 10
[14:50] <Makyo> Kanabaaaaaaaan!
[14:51] <hatch> this....is.....kannnabaaaaaaaan
[14:56] <hatch> Makyo: I was really hoping I could drop this upgrade units stuff off a cliff instead of pick up another card :P
[14:57] <Makyo> hatch, Well, you can defer it for another...three minutes?
[14:57]  * Makyo helpful
[14:58] <hatch> lol
[14:59] <Makyo> jujugui call in 1
[15:01] <Makyo> abentley, call now
[15:46] <hatch> bcsaller: once I'm done with rick then we can chat
[15:47] <benji> abentley: I need to take a quick break and then do you want to chat about handoff of your current card?
[15:47] <sinzui> adeuring, We have a call scheduled in 75 minutes, but I think Mark R is off today
[15:48] <sinzui> We can show up, but I suspect we need to reschedule.
[15:48] <adeuring> sinzui: ok
[15:52] <abentley> benji: was going to take lunch in a few.  How about 68 minutes from now?
[15:54] <benji> abentley: sounds good
[15:57] <bcsaller> hatch: just let me know, I'll  have some coffee in the meantime
[16:05] <hatch> bcsaller:  ok in guichat
[17:48] <hatch> so hows everyones day going?
[17:59] <hatch> that good hey? ;)
[18:02] <hatch> yusss https://www.webkit.org/blog/2910/improved-support-for-high-resolution-displays-with-the-srcset-image-attribute/
[18:23] <bac> hah, typo of the day from an email i just received:  "If I click on the undicode it brings up the glyph"
[18:25] <hatch> jujugui could I get two reviews on https://codereview.appspot.com/12784046/ pllllzzzzz
[18:25] <benji> hatch: I'll do one
[18:25] <bac> sure
[18:25] <hatch> thanks guys
[18:33] <abentley> benji: lp:~abentley/charmworld/bundle-heads
[18:34] <benji> cool
[18:34] <abentley> benji: It has a bunch of refactoring  because I wanted to be able to test the bundle docs, to ensure they had the both the mongo id and the elasticsearch id.  But I'm not wedded to that approach.
[18:35] <benji> ok
[18:37] <hatch> hmm something just dinged me but I don't show any messages :/
[18:47] <abentley> sinzui: I doubt that we will ever be able to implement  #1086551 since updating a readme means pushing to launchpad.  (Doing it locally would lead to conflicts when the branch's copy of the readme changed.)
[18:47] <_mup_> Bug #1086551: Allow inline editing of a charm's README <charmworld:Triaged> <https://launchpad.net/bugs/1086551>
[18:48] <sinzui> abentley, indeed
[18:53] <hatch> so funny story jshint now has indentation support and it thinks it should be done differently then gjshint
[18:53] <hatch> lol
[18:55] <hatch> the new jshint is crazy fast though
[18:55] <hatch> even if all it's doing now is throwing 15027 errors
[18:55] <sinzui> abentley, I think the bug implies ownership. I think an oauth proc would be required. It would branch, patch, and push in the name of the oauth
[18:56] <sinzui> abentley, I don't see anyone building that when charmers review every charm before reading the webui
[18:56] <Makyo> jujugui 1 review for trivial: https://codereview.appspot.com/13069043
[18:56] <abentley> sinzui: In order for it to do that, it would have to be part of Launchpad, because the only way Launchpad currently supports updating a branch is via SSH.
[18:57] <abentley> sinzui: Or we'd need to update Launchpad's SSH to support OAUTH.
[19:01] <hatch> jujugui is there a reason why we jshint our json mocks?
[19:01] <hatch> I'd like to remove them as json now follows the same config as js
[19:01] <bcsaller> I can't think of a good reason
[19:02] <Makyo> hatch, +1  If the mocks are broken, it will be reflected in the tests.
[19:02] <bac> hatch: so to qa your branch i'll need to load it up in ec2?
[19:03] <hatch> bac: no I can give you a script
[19:03] <hatch> one sec
[19:03] <hatch> sorry
[19:04] <hatch> bac: here is the code that will throttle the add unit creation https://gist.github.com/hatched/118a91ba19be71bde4f2
[19:04] <sinzui> abentley, I thought there was a comparable bug for Lp or loggerhead, but I cannot find one. I wanted to dup the issue
[19:04] <hatch> it's a hack so you'll have to do it manually
[19:05] <hatch> bcsaller: Makyo ok thanks for the sanity check, removing them from JSFILES in the makefile
[19:06] <hatch> oh boy this is one heck of a command
[19:06] <hatch> haha
[19:06] <hatch> hmm
[19:06] <hatch> it 'should' be ignoring them now
[19:06] <hatch> I think...
[19:07] <benji> abentley: I'm going away now, but I don't see anything in your branch that raises any questions -- instead I'm sure that'll happen when you're not here to answer them ;)
[19:08] <abentley> benji: okay, have fun.  If you do have questions, sinzui's mental model is close to mine.
[19:08] <benji> cool
[19:14] <hatch> benji: lol fyi `e` is the convention in YUI for event object :)
[19:15] <benji> I'll be sure to donate some of our lottery winnings to the YUI project then.
[19:15] <hatch> haha - belive me I'm definitely a fan of the real variables
[19:15] <hatch> maybe it's just habit
[19:17] <hatch> so funny thing - after fixing the config and the makefile for the new jshint - the new one actually caught more errors
[19:17] <hatch> so my guess is that it would have caught the one nicola found
[19:31] <abentley> orangesquad or bac: Could you please review https://code.launchpad.net/~abentley/charmworld/remove-redudant-id/+merge/180642 ?
[19:31] <sinzui> I can
[19:34] <sinzui> abentley, \o/ I can remove an xxx from by branch when your lands
[19:34] <abentley> sinzui: :-)
[19:37] <sinzui> abentley, r=me
[19:38] <abentley> sinzui: Thanks.
[19:55] <hatch> wow...there were quite a few errors that this version is making me fix
[20:20] <hatch> jujugui looking for two reviews on the upgrade jshint branch https://codereview.appspot.com/13072043/ Thanks
[20:25] <jcsackett> hatch: you've got oen.
[20:25] <jcsackett> s/oen/one/
[20:26] <hatch> thanks sir
[20:27] <hatch> bac: I agree that we should pluralize that but right now I reaaaaaly want to land this branch so in a follow-up :)
[20:27] <bac> hatch: a-ok
[20:27] <hatch> I'd also like a QA of that jshint upgrade branch......just to be safe :)
[20:28] <hatch> basically make sure it can still 'make' and 'make lint'
[20:37] <hatch> anyone else able to take a peek/qa of that jshint branch?
[20:38] <hatch> it went up 2 major versions so could use another qa :)
[20:48]  * sinzui thinks elasticsearch tests get slow after repeated test runs
[20:50] <sinzui> 31s, 44s, 49s, 57s, 79s, 168s
[20:54] <hatch> haha
[20:54] <hatch> that's odd
[20:54] <hatch> rick_h: Makyo: I'm going to land huw's changes now
[20:55] <Makyo> Good luck.
[20:55] <Makyo> Yer gonna need it.
[20:55] <hatch> lol am I?
[20:55] <Makyo> Well, no, probably not.
[20:55] <hatch> haha
[20:55] <Makyo> Just trying to branch out from Airplane! to Star Wars.
[20:56] <hatch> you should try anchorman
[20:56] <hatch> stay classy san diego
[20:56] <Makyo> Hah, I have yet to see that, actually.
[20:56] <Makyo> James won't watch it with me, though.
[20:57] <hatch> no? is he a hater?
[20:57] <Makyo> Hahaha
[20:57] <hatch> a Will Ferrell hater that is
[20:57] <hatch> they are out there
[20:57] <Makyo> I have to be honest, there's only one Will Ferrell movie I've liked so far.
[20:57] <hatch> oh so you're one of 'THEM'
[20:58] <Makyo> Yep :)
[20:58] <hatch> lol I pretty much like all of his stuff
[20:58] <Makyo> I did like Stranger Than Fiction well enough.
[20:58] <Makyo> Mostly because that's some of the least typecast work I've seen.
[20:59] <hatch>  haha
[20:59] <Makyo> He wasn't even against type, just not 100% goofball.
[21:03] <hatch> ahh yeah true true
[21:03] <hatch> did the autocomplete pushdown bug in IE get landed?
[21:29] <Makyo> Looks like.
[21:34]  * Makyo dogwalks
[21:41] <hatch> bcsaller: I have a viewlet idea I'd like to bounce off of you, you around?
[21:41] <bcsaller> yeah, I'll hop on chat
[21:41] <hatch> cool I'm there
[21:59] <hatch> of course there is a new IE bug
[22:01] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1213260
[22:01] <_mup_> Bug #1213260: DDing a charm renders service icon under sidebar <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213260>
[22:04] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1213262
[22:04] <_mup_> Bug #1213262: Text is too large in ghost inspector name field <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213262>
[22:06] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1213264
[22:06] <_mup_> Bug #1213264: Overview Inspector has horizontal scroll bar in IE10 <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213264>
[22:06] <hatch> nice fresh stream of IE bugs coming in on a Friday :)
[22:07] <Makyo> None of these are so high priority as to freak out about, thankfully.
[22:07] <hatch> nope, functionally it's going well
[22:08] <hatch> Makyo: although the charm icons still are only 1/4 on trunk
[22:08] <hatch> I'm going to assume that hasn't landed yet?
[22:08] <Makyo> hatch, That fix was in charmworld, not gui.
[22:08] <hatch> ohh ok so it's still 'landing'
[22:08] <hatch> gotcha
[22:09] <Makyo> hatch, According to sinzui today, once that hits production with other work, a max of 15 minutes until icons are rebuilt.
[22:09] <hatch> great - we'll have to keep an eye on it next week
[22:12] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1213267
[22:12] <_mup_> Bug #1213267: Unit scale up constraints dialogue wraps <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213267>
[22:15] <Makyo> Ugh, IE :|
[22:16] <hatch> lol I know right?
[22:16] <hatch> hey no js errors yet
[22:16] <hatch> that's gota be something
[22:16] <hatch> lol
[22:17] <hatch> IE has this odd thing where it puts an X on the right of an input box to clear it...?
[22:21] <Makyo> Yeah, for touch stuff.
[22:21] <Makyo> I switch out of metro first thing, now.
[22:23] <hatch> oh I'm not in metro
[22:23] <hatch> I'm in desktop ie
[22:25] <hatch> I just updated it though so mayvbe it's a new feature
[22:25] <Makyo> Oh, yeah, updating now.
[22:25] <Makyo> Maybe I'll get them, too.
[22:25] <hatch> https://bugs.launchpad.net/juju-gui/+bug/1213270 here is the bug if you want to comment
[22:25] <_mup_> Bug #1213270: IE10 has native 'Clear Input' X while input is focused in inspector <ie10> <juju-gui:New> <https://launchpad.net/bugs/1213270>
[22:27] <Makyo> Will.  Dunno if we can do anything about it, but we'll see.  There are some attributes added to input elements now that might help.
[22:27] <Makyo> Like the no-autocomplete and no-spellcheck or whatever.
[22:27] <hatch> yeah I was thinking there might be a flag like no autocomplete
[22:27] <hatch> haha