[00:17] <bac> hi huwshimi, how're things?
[00:17] <huwshimi> bac: Hey, good thanks. Yourself?
[00:18] <bac> good!
[01:05] <huwshimi> Does anyone know how to make the "Upgrade Services" inspector appear?
[01:06] <rick_h_> huwshimi: you have to deploy the local charm once
[01:06] <rick_h_> huwshimi: and then drag/drop it a second time
[01:06] <huwshimi> Ah
[01:06] <rick_h_> huwshimi: the GUI thinks you might be trying to upgrade the existing local service
[01:07] <rick_h_> and gives you the option to deploy again or to upgrade existing services
[01:10] <huwshimi> rick_h_: Thanks that worked
[01:17] <hatch> huwshimi thanks :)
[01:18] <huwshimi> hatch: np :)
[01:18] <hatch> I was thinking of doing a similar route but ended up with some unexpected issues when I was upgrading with a local charm
[01:18] <rick_h_> hatch: you going to get to QA that tonight?
[01:18] <hatch> rick_h_ yeah, just starting to cook supper so afterwards
[01:18] <rick_h_> hatch: if that lands tonight then I'll start the release process i nthe morning
[01:19] <rick_h_> hatch: rgr, well I'll call it a night then and try to make sure to get up early to get that going before the ATT man cuts my interwebs
[01:19] <rick_h_> thanks guys, appreicate the work on getting the release ready
[01:19] <hatch> rick_h_ ok sounds good, I'll make sure to do a final QA as well so you're GTG in the am
[01:19] <hatch> thanks
[01:19] <rick_h_> hatch: heh, if we've got more stuff we're doomed. We threw a lot of people at it
[01:20] <hatch> lol true true
[01:20] <hatch> ok running to make suppa
[01:20] <hatch> bbiab
[01:20] <rick_h_> hatch: but like I said onthe call today, I'm not expecting it to be bug free
[01:20] <hatch> right
[01:20] <hatch> right
[01:20] <rick_h_> hatch: so don't stay up too late with it, thanks
[01:20] <hatch> gnt
[01:20] <rick_h_> night
[01:20] <huwshimi> night
[01:40] <hatch> huwshimi the upgrade local charm UI is broken
[01:40] <huwshimi> hatch: Uh oh, what did I break?
[01:40] <hatch> it only shows the Upgrade Services without the Deploy Local Charm on top
[01:41] <hatch> the Upgrade Services looks like it pushes the Deploy Local Charm view up off the page
[01:41] <hatch> the two views should be stacked
[01:42] <hatch> I can send a screenshot if you can't reproduce
[01:42] <hatch> this was a similar problem that I ran into when doing this heh
[01:47] <huwshimi> hatch: Oh, I see it's supposed to display both at once.
[01:47] <hatch> yesm
[01:48] <huwshimi> hatch: I guess it's actually supposed to look like this: https://drive.google.com/a/canonical.com/?usp=folder#folders/0B7XG_QBXNwY1R0Z6OUJpZXBTa28
[01:49] <hatch> huwshimi atm we only care that it fills up the left column
[01:49] <hatch> the Deploy Local Charm is good, but when both are combined it's not
[01:51] <huwshimi> hatch: Can we not have the controls at the bottom?
[01:51] <huwshimi> hatch: I'm not sure how it would work otherwise..
[01:52] <hatch> huwshimi i dew not care :)
[01:52] <huwshimi> hehe
[01:53] <hatch> honestly though we can and likely will revisit this in the next release but atm we just need it to fill up the sidebar with black so it doesn't look empty
[01:53] <hatch> if the buttons are at the top with the content or not then that's ok
[02:14] <huwshimi> hatch: OK, new version up
[02:15] <hatch> cool trying
[02:17] <hatch> huwshimi looks good :) nice
[02:17] <huwshimi> hatch: yay
[02:18] <hatch> you can shipit whenever
[02:18] <huwshimi> hatch: Have done.
[02:18] <hatch> noice
[02:19] <huwshimi> brb, lunch
[02:38] <huwshimi> hatch: Doing some QA, but let me know if there's anything you need me to look at.
[02:39] <hatch> huwshimi looks like that's all
[02:40] <hatch> thanks for getting all these things done for the release
[02:40] <huwshimi> np
[02:41] <huwshimi> if only our selenium wasn't so broken
[02:41] <hatch> huwshimi this looks pretty cool using sass and json http://viget.com/extend/sharing-data-between-sass-and-javascript-with-json
[02:41] <hatch> thought you might be interested
[02:42] <huwshimi> nice
[02:44] <hatch> huwshimi last one :) http://thesassway.com/advanced/inverse-trigonometric-functions-with-sass
[02:45] <huwshimi> woah
[02:50] <hatch> haha yep
[03:07] <hatch> huwshimi looks like you have some failures with your branch
[03:08] <hatch> IE10 failures
[03:08] <hatch> I'll re-run it as the failures shouldn't have been affected by your changes
[03:09] <huwshimi> hatch: It's already re-running
[03:09] <hatch> oh lookie that
[03:09] <hatch> :)
[03:09] <huwshimi> just about to finish
[03:12] <huwshimi> hatch: Merged.
[03:12] <hatch> rock on
[09:35] <frankban> hi rogpeppe1, how it is going?
[09:44] <rogpeppe1> frankban: hiya
[09:44] <rogpeppe1> frankban: i'm still contemplating the cmd package
[09:45] <rogpeppe1> frankban: and trying to grok how it works
[09:45] <rogpeppe1> frankban: the problem is that it currently depends on the version package
[09:46] <rogpeppe1> frankban: we need to remove that dependency, but it's not quite clear what the best way to do it is
[09:46] <frankban> rogpeppe1: also on osenv AFAICT
[09:47] <rogpeppe1> frankban: hmm, i thought that would be easily removed, but it's not quite so straightforward
[09:50] <rogpeppe1> frankban: at the moment, my current inclination is just to add global variables for both the current version and the logging config environment variable (or the default logging config)
[09:50] <frankban> rogpeppe1: not sure how to handle version. maybe put arch in utils and break version into a separate repo? version itself does not seem to be so much tangled with juju
[09:50] <rogpeppe1> frankban: i don't think it's right to put version in another repo
[09:50] <rogpeppe1> frankban: it really is juju-core specific, as it's the juju-core version
[09:51] <frankban> rogpeppe1: yeah, I see now const version = "1.19.4"
[09:52] <rogpeppe1> frankban: if i could think of a good name, i'd split the version package
[09:52] <rogpeppe1> frankban: one part would just be the versioning logic
[09:52] <rogpeppe1> frankban: the other would hold the current version
[09:53] <frankban> rogpeppe1: yes, that's what I was thinking. you mean, the external part for version parsing, OS versions etc. the juju part with just the juju bits
[09:53] <frankban> ?
[09:53] <rogpeppe1> frankban: yup
[09:55] <frankban> rogpeppe1: juju/versionutils? versiontools?
[09:57] <rogpeppe1> frankban: i was more thinking of github.com/juju/juju/currentversion or even perhaps putting the current version in github.com/juju/juju/juju
[09:57] <rogpeppe1> frankban: because i'm quite attached to the current names (version.Number etc) for the primitives
[09:57] <rogpeppe1> juju.CurrentVersion
[10:11] <frankban> rogpeppe1: what if instead we change cmd so that it can receive a version? e.g. add a Version string field to SuperCommandParams?
[10:11] <rogpeppe1> frankban: that's my current thought. except that rather than doing that, i was just planning on adding a global variable
[10:12] <rogpeppe1> frankban: otherwise the version needs to be provided to the VersionCommand constructor too
[10:27] <frankban> rogpeppe1: otherwise maybe versionCommand can be a special case, like help: help := &helpCommand{
[10:27] <frankban> 		super: c,
[10:27] <frankban> 	}
[10:28] <rogpeppe1> frankban: yes, perhaps
[10:28] <frankban> rogpeppe1: that way the command has access to the supercommand, and can retrieve c.Version
[10:29] <rogpeppe1> frankban: but VersionCommand is also referenced directly by cmd/juju and cmd/jujud
[10:30] <rogpeppe1> frankban: tbh i don't like the way it's such a special case
[10:30] <rogpeppe1> frankban: i would much prefer if there was nothing mentioning version in cmd
[10:30] <rogpeppe1> frankban: but the logic is twisty enough that i haven't managed to work out how to do that
[10:48] <frankban> rogpeppe1: I mean something like http://pastebin.ubuntu.com/7633106/
[10:49] <rogpeppe1> frankban: how does that fit with ./juju/cmd/juju/main.go:151: 	r.Register(&cmd.VersionCommand{})
[10:50] <frankban> rogpeppe1: I just removed that line in the diff
[10:51] <frankban> rogpeppe1: so basically commands no longer need to register a version subcommand
[10:53] <frankban> rogpeppe1: and we can also change that so that a version subcommand is registered only if c.Version is not an empty string
[10:53] <rogpeppe1> frankban: that looks pretty good actually
[10:53] <rogpeppe1> frankban: do the tests pass with that?
[10:53] <rogpeppe1> frankban: yeah, i was going to suggest that
[10:53] <frankban> rogpeppe1: did not try tests, that's just a sketch, but the code compiles
[10:54] <frankban> rogpeppe1: we'll need to refactor tests so that they pass version when creating a command
[10:55] <rogpeppe1> frankban: a supercommand, yes
[10:55] <frankban> rogpeppe1: yes
[10:57] <frankban> rogpeppe1: the logging bits becomes: logger.Infof("running %s [%s %s]", c.Name, c.Version, runtime.Compiler)
[10:57] <frankban> rogpeppe1: and version is no longer a dep
[10:58] <rogpeppe1> frankban: yeah
[11:01] <frankban> rogpeppe1: FWIW I like this solution, it seems coherent enough. do you wnat me to work on this further on a real branch or do yo want to tackle this?
[11:01] <rogpeppe1> frankban: i'm happy to do it
[11:01] <frankban> rogpeppe1: cool thanks
[11:01] <rogpeppe1> frankban: sorry, i've been reviewing a juju-core branch for a little while
[11:04] <frankban> rogpeppe1: no worries, will lunch now, do you have other tasks I can proceed with?
[11:05]  * rogpeppe1 thinks
[11:05] <rogpeppe1> frankban: i'll think while you have lunch...
[11:05] <frankban> rogpeppe1: cool thanks
[11:35] <rick_h_> morning all
[11:46] <frankban> morning rick_h_
[11:46] <frankban> rick_h_: is MRamm our travel authorizer?
[11:48] <rick_h_> frankban: yes
[11:49] <frankban> rick_h_: cool thanks
[12:30] <bac> jujugui: hey git question: in my brew branch i needed to do a squash, so i did a 'git rebase -i HEAD~2', marked my pick and squash, exited the editor and now things are hosed.  the rebase didn't happen and now i'm unsure of the state or how to recover.
[12:31] <rick_h_> bac: what is 'git status'?
[12:31] <bac> rick_h_: rebase in progress
[12:32] <rick_h_> bac: ok, so there was probably a conflict. Any files listed in that status with a U marker?
[12:32] <bac> no, no conflicts: https://pastebin.canonical.com/111573/
[12:33] <rick_h_> bac: try 'git rebase--continue'
[12:33] <bac> [bac@sol local]$ git rebase --continue
[12:33] <bac> cat: /usr/local/.git/rebase-merge/stopped-sha: No such file or directory
[12:33] <bac> Cannot 'squash' without a previous commit
[12:33] <bac> so 'commit --amend'?
[12:33] <bac> fist
[12:33] <bac> s/fist/first/
[12:33] <rick_h_> bac git rebase --abort, not sure what's up tbh
[12:33] <rick_h_> bac: but you can abort and start over
[12:34] <bac> rick_h_: ok, started over.  i mark 's' and 'p' and exit emacs and then it should happen, right?
[12:34] <rick_h_> save and then exit?
[12:35] <rick_h_> bac they should all have a p, and then you change the one to s and save/quit the editor
[12:35] <bac> do you have to pick the first one and squash the later ones?
[12:35] <rick_h_> bac: and then it should bring up the commit log in the editor
[12:35] <rick_h_> bac: yes
[12:35] <rick_h_> bac: and you get a file with all the commit messages to garden up
[12:35] <rick_h_> and then when you save that, it does the rebase and completes
[12:36] <bac> rick_h_: ok, i tried to keep the later one b/c it had the commit message i wanted.
[12:37] <rick_h_> bac: ah yea. No, keep the first, rebase the later, and then edit the messages all at once
[12:37] <rick_h_> squash the later sorry
[12:39] <bac> rick_h_: great, commited as desired.  now cannot push as the repo on github has new changes.  'git pull' says it is up-to-date.  i'm not specifying the pull source correctly i guess
[12:39] <rick_h_> bac: so you're pushing to your own branch?
[12:40] <rick_h_> bac: since you rebased, there's fewer commits. You have to push back up to your branch with --force to make git update the other location, but make 100% sure you're doing this to your branch that no one else is using
[12:40] <bac> i want to push to  juju/homebrew
[12:40] <bac> git push git@github.com:juju/homebrew.git juju-quickstart-formula
[12:41] <rick_h_> bac: right, add --force to that
[12:41] <bac> so when it says
[12:41] <bac> hint: Updates were rejected because a pushed branch tip is behind its remote
[12:41] <bac> hint: counterpart. Check out this branch and integrate the remote changes
[12:41] <bac> that is simply caused by the rebase?
[12:42] <rick_h_> it's simply because the other branch has more/different commits
[12:42] <bac> the remote hasn't changed
[12:42] <rick_h_> your rebase changed that
[12:42] <rick_h_> no, but if you compare your local branch to the remote, it has the rebased away commits.
[12:43] <bac> oh, e.g. it has the 1.3.4 commit, i commited 1.3.5 and squashed 1.3.4, so remote no longer has 1.3.4 and git lies saying the remote has new commits
[12:43] <rick_h_> so one branch says "after commit xxxx, here's 3 more commits. And your local one says "after commit xxxx here's one more commit"
[12:43] <rick_h_> bac: right, s/newer/different
[12:43] <bac> ok, so the hint is misleading
[12:44]  * bac goes to amazon for o'reilly book
[12:44] <rick_h_> crash course!
[12:45] <rick_h_> bac: pro git is supposed to be the git bible these days. I haven't read it, but it's available free online
[12:45] <rick_h_> http://git-scm.com/book
[12:45] <bac> i just need to use git more frequently than once a quarter
[12:45] <rick_h_> heh, yea that helps
[12:45] <rick_h_> did that work out then?
[12:48] <bac> yes.  i may have just done the thing we as a project said we didn't want: rebase during a pull request cycle.
[12:49] <bac> my pull request title now references 1.3.4 but i just commited 1.3.5.
[12:49] <bac> they are insistent on squashing, though.
[12:52] <bac> hey but the brew guys commented on the PR, which is a good sign
[12:54] <frankban> bac: PR link?
[12:55] <bac> frankban: https://github.com/Homebrew/homebrew/pull/30070
[12:55] <frankban> ty
[12:57] <rick_h_> kadams54: or jcsackett can one of you please look at the bug in urgent please? It's the last known issue blocking release
[12:58] <rick_h_> coordinate with hatch or makyo if required as one of them worked on that recently I believe.
[12:58] <rick_h_> heh, the card has mayko's head on it but the bug has hatch assigned https://launchpad.net/bugs/1326401
[12:58] <_mup_> Bug #1326401: Charm details link in the Inspector on the left doesn't work <juju-gui:Triaged by hatch> <https://launchpad.net/bugs/1326401>
[13:01] <jcsackett> rick_h_: looking.
[13:01] <jcsackett> and good morning, all.
[13:02] <rick_h_> jcsackett: ty much
[13:02] <frankban> bac: not sure if this is related to the failure, but I remember I looked at other formulas and the install section usually looks like http://pastebin.ubuntu.com/7633583/
[13:02] <jcsackett> rick_h_: huh, that worked yesterday when i looked at it.
[13:03] <rick_h_> jcsackett: I've got the steps to reproduce in the bug there from luca https://bugs.launchpad.net/juju-gui/+bug/1329236
[13:03] <_mup_> Bug #1329236: Click on "cs:/precise...." does nothing <juju-gui:Triaged> <https://launchpad.net/bugs/1329236>
[13:04] <bac> frankban: the failure is i tried to use 'juju quickstart' in the test, not 'juju-quickstart'.  it turns out #{bin} is not what i expected, but a bin with only the package executables, thus 'juju' is not there.
[13:04] <kadams54> rick_h_, jcsackett: Yeah, interesting. I remember testing that when Huw moved the link from "Charm details" to the charm ID…
[13:05] <jcsackett> kadams54, rick_h_: ah, it's in the ghost inspector.
[13:05] <rick_h_> jcsackett: the error I hit was in the real inspector
[13:06] <rick_h_> not the ghost
[13:06] <jcsackett> i'm not getting that, following exactly his steps.
[13:06] <rick_h_> jcsackett: huh?
[13:07] <rick_h_> jcsackett: you mean my steps?
[13:07] <jcsackett> rick_h_: yes, thought it was his comment, misread.
[13:08] <rick_h_> jcsackett: I get it using those instructions in both FF and chrome
[13:08] <kadams54> jcsackett, rick_h_ : I also run into the problem.
[13:09]  * jcsackett ponders caching...
[13:09] <kadams54> The first click works to open the details, but subsequent clicks do not.
[13:09] <kadams54> I'm in Chrome Canary, incognito
[13:09] <kadams54> Checking other browsers…
[13:09] <rick_h_> kadams54: cool, yea it's the JS errors and I bet something is cleaned up/not cleaned up that breaks next attempts
[13:09] <jcsackett> aaah.
[13:10] <kadams54> It looks like something is being overly aggressive in cleaning up
[13:10] <kadams54> Which means something else is unexpectedly null on the second click
[13:10] <rick_h_> kadams54: right, I wonder if the work done in updating the inspector styling yesterday moved something
[13:10] <rick_h_> jcsackett: ^
[13:10] <rick_h_> so you might try pre-hatch's commit yesterday
[13:10] <rick_h_> and see if it repeats
[13:10] <jcsackett> i've reproduced. the instructions and description didn't mention it being subsequent clicks.
[13:10] <rick_h_> Now the next time you click you get another error:
[13:11] <rick_h_> :P
[13:11] <rick_h_> https://github.com/juju/juju-gui/commit/88a49f4a7a7da60ecf1757f90bccf4cb1131a867
[13:11] <jcsackett> <--under caffeinated brain
[13:11] <rick_h_> might be the issue
[13:12] <rick_h_> jujugui att guy is here. I'm going dark. I'm available via hangouts on the phone of you need anything. Please get help/etc move this bug through and have someone go through the release process.
[13:12] <jcsackett> rick_h_: dig.
[13:12] <kadams54>  Yup, will do
[13:12] <rick_h_> ty much
[13:16] <jcsackett> kadams54: bad news, that change is not responsible--it's only on local charm inspector dispatching, which doesn't come into play on this error path. i'm going to keep digging.
[13:16] <kadams54> jcsackett: OK, I'll stand by to QA and review.
[13:16] <jcsackett> thanks.
[13:17] <bac> frankban: would you like to pull the brew formula try to install?
[13:19] <frankban> bac: sure
[13:19] <bac> frankban: and 'brew test --verbose juju-quickstart'
[13:20] <frankban> bac: how do I pull the formula?
[13:20] <kadams54> bac: Oh nice, good progress on getting quickstart brew-ified?
[13:21] <bac> frankban: it is on github as juju/homebrew
[13:21] <bac> frankban: i guess you'd cd to `brew --repository` and pull it there?
[13:29] <frankban> bac: installing quickstart
[13:33] <frankban> bac http://pastebin.ubuntu.com/7633692/
[13:33] <bac> frankban: cool.  as it should be.
[13:46] <jcsackett> kadams54: so...this fixes the bug, but it doesn't feel like the right fix, and i'm still not sure what the real root cause is. https://github.com/juju/juju-gui/pull/384/files
[13:46] <jcsackett> thoughts?
[13:46] <kadams54> Looking…
[13:46] <jcsackett> viewlet management &c is still a bit opaque to me.
[13:48] <kadams54> What happens if you still did the destroy, but without passing in remove: true?
[13:48] <hatch> what's the problem?
[13:49] <kadams54> hatch: see https://bugs.launchpad.net/juju-gui/+bug/1329236 - currently a blocker
[13:49] <_mup_> Bug #1329236: Click on "cs:precise...." does nothing in the inspector on subsequent clicks <juju-gui:Triaged> <https://launchpad.net/bugs/1329236>
[13:50] <kadams54> jcsackett, hatch: I find it odd that container.empty() is called after invoking the viewlet's destructor. Seems like that should be done within the destructor…
[13:50] <kadams54> Which likely has nothing to do with this bug, but more general code smell.
[13:51] <hatch> yeah the charm details stuff is definitely not done correctly
[13:51] <hatch> but one sec lemme look
[13:52] <bac> frankban: huh, a new mysterious failure: https://github.com/Homebrew/homebrew/pull/30070
[13:52] <bac> frankban: not sure how this is related to my branch
[13:54] <hatch> jcsackett so if you remove the container.empty and the remove: true does it work?
[13:56] <kadams54> Just bisected those lines back to a change I made: https://github.com/juju/juju-gui/commit/06a905da55efdd7d45ba9bd80ec7fd5a65e3f39e#diff-18e27830e6c8815b6d3e6caa66636597R55
[13:57] <kadams54> I suspect the cleanup is still needed. It just needs to happen in a better, more intelligent way :-) Still not sure why this bug is only just now popping up…
[13:57] <jcsackett> hatch, kadams54: checking remove: true and empty now--had to let the dogs out.
[13:58] <kadams54> Guess that answers the question.
[13:58] <kadams54> We now know who let the dogs out.
[13:58] <kadams54> Thank you, thank you, I'll be here all day long.
[13:59]  * jcsackett groans
[13:59] <jcsackett> nice, kadams54. very nice.
[14:00] <jcsackett> kadams54, hatch: yeah, if i keep destroy but get rid of remove: true it works.
[14:00] <jcsackett> it actually works independently of whether or not container.empty is there.
[14:01] <kadams54> We're going to need to make sure we're not creating multiple charm detail DOM nodes on subsequent clicks
[14:01] <hatch> yeah this whole section is a little broken - the view shouldn't need to do this, it should be destroyed/rendered by the viewlet manager
[14:01] <hatch> did anyone bisect to see when this bug was introduced?
[14:02] <hatch> because it wasn't throwing any errors yesterday I'm pretty sure
[14:03] <kadams54> hatch: not yet, but working on it right now.
[14:03] <hatch> kadams54 cool thx
[14:03] <hatch> I don't remember anything landing that could cause this...
[14:04] <jcsackett> hatch: i'm not sure this path was QAed; i never clicked the link, closed it, and reclicked it.
[14:05] <jcsackett> so it could have been broken yesterday.
[14:08] <jcsackett> hatch: so, the container close thing is already calling hideSlot--doesn't hideslot kill the viewlet?
[14:08] <hatch> heh the bug report is pretty horrible :P
[14:08] <hatch> jcsackett it should yep
[14:10] <hatch> it should detach the event binding and then call the viewlets destroy method
[14:10] <jcsackett> hatch: it does.
[14:11] <jcsackett> ok, so i've removed all the this.destroy and container.empty stuff in the .close function. the viewlet still goes away, and i'm not seeing dom nodes hanging around.
[14:11] <hatch> jcsackett oh the destructor for that view has none of this business in it....I wonder why this extra delegate was created
[14:11] <hatch> it seems to me like all of that should be moved to the destructor
[14:12] <jcsackett> hatch: i think just for url and animation cleanup--if i keep both of those and then call viewletManager.hideslot everything seems to be groovy.
[14:12] <jcsackett> tests all pass this way too.
[14:12] <jcsackett> (which doesn't necessarily mean anything, but hey)
[14:12] <hatch> (all the tests passed before)
[14:12] <hatch> :P
[14:13] <kadams54> +1 for moving all that to the destructor
[14:13] <hatch> the service inspector calls hideSlot when the X is clicked
[14:13] <hatch> so that delegate shouldn't be needed
[14:13] <hatch> so all of those bits should be able to be moved into the destructor
[14:16] <hatch> brb
[14:19] <jcsackett> hatch, kadams54: so, the bind is there b/c the "x" in question is a different one--it's the one on charm-details, not the one on the service inspector, and there's no event bound to it w/o the container delegate block.
[14:20] <jcsackett> i can move all the other logic into the destructor, but the delegate seems to be necessary for clicking the x to actually call hideSlot.
[14:21] <jcsackett> the WIP pr is updated so you can see what i mean.
[14:24] <rogpeppe1> lunch
[14:28] <hatch> jcsackett ahhhh
[14:28] <kadams54> jcsackett, hatch: Hmm, when I +1 stuff moving to the destructor, it was container.empty()… I think closing (whether in the delegate or in closeSlot) still ought to remove the "animate-in" class, remove the URL hash, and invoke the destructor.
[14:29] <jcsackett> kadams54: well, we don't actually need container.empty at all, do we?
[14:29] <Makyo> Averaging 3k/s, don't think hangouts are going to work for me this morning.
[14:29] <jcsackett> since hideSlot is supposed to handle everything.
[14:29] <hatch> Makyo lol
[14:29] <jcsackett> Makyo: broadband not installed yet, eh?
[14:30] <bac> hey frankban, for juju-quickstart on PyPI the description seems to just be the README.rst.  does PyPI read that in automatically or was it cut-n-pasted there?
[14:30] <Makyo> jcsackett, they're coming this morning.  Until then, I'm tethering on Edge.
[14:30] <kadams54> jcsackett: I'm skeptical of hideSlot… when I added those lines of code, it was because the charm details weren't being fully destroyed, so subsequent clicks would end up creating multiple detail panels.
[14:31] <hatch> jcsackett so I think the proper way to fix this is to add an event (this is just a view) to call the destructor when .close-slot is clicked
[14:31] <frankban> bac: PyPi shows the long_description passed in setup.py
[14:31] <kadams54> jcsackett, hatch: It may be that hideSlot's doing more now to ensure proper cleanup, but I don't want to just assume that.
[14:31] <hatch> then move everything from within that delegate into the destructor
[14:31] <jcsackett> hatch: and continue not having remove: true, yeah?
[14:31] <hatch> yeah we don't want it to remove its container
[14:32] <frankban> bac: we dynamically pass the contents of README.rst
[14:32] <bac> frankban: ah, thanks.
[14:32] <kadams54> hatch: I still think things like removing "animate-in" class needs to happen outside the destructor. Is that also what you're proposing?
[14:32] <bac> frankban: but you can also edit it in place on pypi.
[14:32] <hatch> kadams54 why?
[14:32] <kadams54> Because it has nothing to do with destroying the class
[14:33] <kadams54> And everything to do with the visual effects that happen when a close action occurs
[14:33] <bac> frankban: if i do edit in place, i assume it will pick it up on the next release from the long description.
[14:33] <kadams54> There may be other situations where you want to destroy the class but you don't give a fig about making sure the panel slides in nicely.
[14:33] <frankban> bac: at that point I guess new releases override the description
[14:34] <bac> frankban: yeah, i'd expect so.  i'd like to update the info now without having to do a release.
[14:35] <jcsackett> hatch: should the destructor be calling hideSlot...since hideSlot calls the views destructor...?
[14:35] <frankban> bac: so you want to change both README and the description on the current release?
[14:35] <hatch> jcsackett good point
[14:36] <jcsackett> maybe we want the fn called for the close-slot click event to do the anim cleanup, then call hideSlot?
[14:36] <hatch> blah this stuff is so broke heh
[14:36] <bac> frankban: i want to change what is seen on pypi now via editing on the site.  i also want to update the README in the branch.
[14:37] <hatch> jcsackett imho, make it work for release - this needs to be broken out of the inspector anyways
[14:37] <jcsackett> hatch: so, my proposal:
[14:38] <jcsackett> have events include click on close-slot; that calls a method which deals with the anim stuff, and calls hideSlot.
[14:38] <jcsackett> hideSlot, i've verified, calls view.remove and view.destroy.
[14:38] <kadams54> jcsackett, hatch: Yeah, that seems like the best/cleanest separation of concerns.
[14:38] <jcsackett> we can add container.empty to the close-slot method to address kadams54 concerns.
[14:39] <jcsackett> and then i'll put in a test to make sure that the close slot method actually gets rid of stuff so we don't keep generating extra details nodes.
[14:39] <jcsackett> you both +1?
[14:39] <hatch> yep go for it
[14:39] <kadams54> yep +1
[14:39] <jcsackett> cool.
[14:39] <hatch> after this release is gtg?
[14:40] <frankban> bac: how do you want to change the README?
[14:40] <jcsackett> i believe so; unless we want the s/export.yaml/bundle.yaml/ drive by i did to be part of the release.
[14:40] <bac> frankban: using emacs, i guess
[14:40] <jcsackett> jcsackett: i haven't had a chance to add a test for that--for some reason i thought i had already landed when i picked this up.
[14:41] <bac> frankban: sorry.  no, i want to add OS X to the supported systems and mention pip and brew install
[14:42] <frankban> bac: I am not sure we want to advertise osx support now. It's not complete, and it deserves a minor version change. I'd be inclined to do that a part of the 1.4.0 release
[14:43] <bac> frankban: what is incomplete?
[14:43] <bac> from a pip install?
[14:44] <bac> well, there is the local environment stuff in the interactive session
[14:44] <jcsackett> hatch: see comment above. i highlighted myself instead of you.
[14:44] <frankban> bac: exactly
[14:44] <hatch> oh heh
[14:45] <hatch> jcsackett yeah we can probably wait for that to land
[14:46] <frankban> bac: and from the perspective of a brew user who does not have an env.yaml file, the really first impact with quickstart is a broken option right now
[14:46] <bac> frankban: i hadn't seen you were working on that card
[14:47] <frankban> bac: the other one (handle brew not installed) is also a blocker IMHO
[14:47] <bac> frankban: ok.  that's a good plan to get all of these and target for 1.4.0.
[14:47] <frankban> bac: cool
[14:50] <hatch> jujugui call in 10
[14:51] <frankban> bac: added two cards in maint/high: update readme, release 1.4.0
[14:59] <rick_h_> jujugui call in < 1
[14:59] <hatch> found yourself some interwebs?
[14:59] <rick_h_> just on the wifi of the new router
[14:59] <rick_h_> lots of rewiring to do :)
[15:00] <hatch> ohhhhhhhh
[15:00] <rick_h_> but the new one is smaller yay! more room in the rack
[15:00] <rick_h_> jcsackett: &
[15:00] <rick_h_> jcsackett: ^
[15:05] <bac> jcsackett: it should be plural:  bundles.yaml
[15:08] <jcsackett> bac: yeah?
[15:08] <jcsackett> but it only holds one bundle.
[15:09] <bac> jcsackett: http://bazaar.launchpad.net/~charmers/charms/bundles/rails/bundle/files
[15:09] <bac> no, it can have many bundles
[15:09] <bac> jcsackett: it is really a deployer file, and can have lots of bundles in it.
[15:10] <jcsackett> bac: so the file in a bundle is always bundles.yaml. ok.
[15:13] <bac> jcsackett: i guess we could've exposed the basket nomenclature...but, no.
[15:15] <jcsackett> bac: i'm fine making a one character addition while i'm adding a test.
[15:15] <jcsackett> :p
[15:26] <jcsackett> hatch: got a second to chat?
[15:26] <hatch> yeah sure
[15:26] <hatch> standup room?
[15:27] <hatch> ^ jcsackett
[15:28] <hatch> rick_h_ who is the travel authorizinator?
[15:28] <jcsackett> hatch: sure.
[15:35] <frankban> hatch: MRamm
[15:35] <kadams54> jcsackett, hatch: heading out to lunch shortly. Will be back in an hour.
[15:36] <rick_h_> hatch: yep, ramm
[15:36] <hatch> thx
[16:01] <hatch> jcsackett hey how goes the battle?
[16:02] <jcsackett> hatch: just about done.
[16:02] <jcsackett> double checking our assumptions re hideSlot are correct and then submitting.
[16:02] <hatch> cool, lemme know when you are and I'll get it QA's and whatnot
[16:08] <hatch> holy smokes it's been a long time since we released heh
[16:13] <jcsackett> hatch: so...the destructor is only called the *first* time.
[16:13] <hatch> ugh so the delegate stuff is needed...
[16:15]  * jcsackett hates this code
[16:15] <jcsackett> it's become personal.
[16:16] <jcsackett> hatch: i think we revert all changes and just remove the "remove: true"
[16:16] <jcsackett> we can't fix the rest of this until we can kill all the current slot goofiness.
[16:16] <hatch> jcsackett whatever gets this landed :)
[16:16] <jcsackett> hatch: yeah, just now i have to write an entirely new test. :(
[16:17] <hatch> ugh
[16:17] <hatch> sorry
[16:17] <jcsackett> ...actually, i'm not even sure how to test it; i guess event simulate...?
[16:17] <jcsackett> except i have to stub out *everything* so i'm not sure what i'm even testing...
[16:25] <hatch> well
[16:25] <hatch> on click we want to see that it calls to do the specific things
[16:27] <jcsackett> yeah, i'm just concerned, since we're still in slot land, that i'm not really testing the issue kadams54 encountered that led to this code in the first place.
[16:27]  * jcsackett really doesn't want to re-introduce the bug he was fixing.
[16:28] <hatch> yeah this is true
[16:28] <hatch> but it's so much work to properly test
[16:28] <hatch> heh
[16:28] <hatch> and we'll throw it all away soon
[16:28] <hatch> maybe just a good qa and a basic test will be enough
[16:28] <hatch> and a card to go back and fix it properly
[16:30] <jcsackett> hatch: FYI hideSlot doesn't call the view destructor.
[16:31] <jcsackett> i've instrumented both, and the first time hideSlot is called, the view destructor is called.
[16:31] <hatch> ohhhh boy I can't wait to delete that stuff
[16:31] <jcsackett> subsequent times hideSlot is called, the destructor is not.
[16:31] <jcsackett> so i'm going to keep this.destroy in the delegated function.
[16:49] <hatch> jcsackett ok I'm ready for the release once we land these branches, anything I can help with to get these moving?
[16:49] <hatch> if not, no biggy I can move to something else for now
[16:49] <jcsackett> hatch: you can review this https://github.com/juju/juju-gui/pull/384
[16:49] <hatch> on it
[16:49] <jcsackett> and QA the holy hell out of the charm details inspector so we can be sure it doesn't break something else. :)
[16:51] <hatch> haha ok
[16:56] <hatch> jcsackett when I navigate between the tabs the little red thing lags
[16:56] <hatch> does it do that on yours as well?
[16:57] <hatch> rick_h_ I was wondering if we could prioritize the perf issue when going from inspector to charmbrowser - the inspector kind of just hangs there for a while then snaps to the cb
[16:58] <hatch> jcsackett review done and qa ok
[16:58] <hatch> just one small comment re a comment
[17:00] <jcsackett> hatch: the red thing lags for me even on develop
[17:01] <hatch> jcsackett yeah I was just confirming
[17:01] <hatch> I didn't think they were caused by this branch heh
[17:01] <jcsackett> hatch: yeah, i just wanted to be sure.
[17:02] <jcsackett> the comment does not apply. i'm changing it now and pushing up a rebase, and we can shipit.
[17:02] <hatch> aweseome thx
[17:02] <jcsackett> np.
[17:03] <jcsackett> hatch: meanwhile, you know how to test that saveAs gets 'bundles.yaml' as an arg for the export branch?
[17:03] <hatch> hmm
[17:03] <hatch> thinking
[17:03] <hatch> i''mmmmmm thinking
[17:04] <hatch> jcsackett yup, greate a global saveAs stub and test that the right data is sent to it
[17:04] <jcsackett> can you do that? i don't see where saveAs is defined to override it? or i guess i can just assign a stub to it anyway, can't it?
[17:04] <hatch> the first param will be something like     assert.equal(arg1 instanceof Blob, true)
[17:05] <jcsackett> s/can't it/cant i
[17:05] <hatch> jcsackett it's defined in FileSaver
[17:05] <hatch> .js
[17:05] <hatch> but you can just create a global stub....make sure to null it out and whatnot afterwards
[17:06]  * jcsackett nods
[17:06] <jcsackett> ok, changes are up, waiting on testrun.
[17:07] <hatch> for which?
[17:07] <hatch> the bundles one you forgot to add the test
[17:07] <hatch> heh
[17:09] <hatch> jcsackett you don't need to wait for the tests to finish for the charm-details branch....the lander will run them anyways before it merges
[17:09] <hatch> so you can shipit now
[17:09] <hatch> unless of course you think they won't pass for whatever reason :)
[17:10] <hatch> did they pass locally?
[17:10] <jcsackett> they did; i've shipped it.
[17:10] <jcsackett> i'm just always leery of doing that.
[17:10] <hatch> heh, it's ok, it'll bomb out if it doesn't pass
[17:11] <hatch> I mean, don't do that if you haven't had a passing run locally or whatever, just in case, but if you have and it's just a touchup branch then let'r'rip imho
[17:21] <jcsackett> hatch: how do you make a global stub? i can't just assign a stub to "saveAs" b/c it's failing as a readonly.
[17:21] <hatch> *sigh* of course it is....
[17:22] <hatch> unos momentos
[17:22] <jcsackett> thanks.
[17:25] <hatch> jcsackett ok you can't
[17:25] <hatch> damn strict mode
[17:26] <hatch> we'll have to create an abstraction at some point like we did with the web handler stuff
[17:26] <hatch> in the env
[17:26] <hatch> son of a...
[17:27] <hatch> I'm still looking for an alternative
[17:29] <rick_h_> hatch: jcsackett sorry, lost internet and didn't realize I wans't connected
[17:29] <rick_h_> hatch: let's talk after the release on the perf issue stuff.
[17:30] <hatch> rick_h_ yeah no problem
[17:30]  * rick_h_ runs for foods
[17:31] <hatch> jcsackett yeah doesn't look like there is a way around it - I thought that filesaver was providing a wrapper already but it turns out it's just passing the real saveAs method through
[17:31] <jcsackett> hatch: so...just leave this untested, since my branch is a one word change?
[17:31] <hatch> so no test for now - follow-up card to create an abstraction
[17:31] <hatch> right
[17:31] <jcsackett> hatch: dig. i'll throw a card in the backlog pool.
[17:31] <hatch> thanks sir
[17:33] <jcsackett> gah, ci/selenium...
[17:34] <hatch> ugh
[17:35] <hatch> re-run it
[17:36] <jcsackett> i just remove the merge request accepted comment, right?
[17:37] <hatch> correct
[17:42] <rogpeppe1> done for the day
[17:42] <rogpeppe1> g'night all
[17:43] <rogpeppe1> a collaborative effort with frankban: https://github.com/juju/cmd/pull/1
[17:44] <hatch> night rogpeppe1
[17:48] <hatch> jcsackett are you going to shipit your bundles branch? Or are you waiting for something
[17:49] <jcsackett> hatch: thought i already had.
[17:50] <hatch> :)
[17:50] <hatch> jujugui by the power vested in me by myself I now declare develop frozen from any more shipit's
[17:56] <kadams54> hatch: are you cutting the release?
[17:56] <hatch> once the two PR's that are landing land on develop
[17:56] <hatch> so it wont be released for probably a couple hours
[17:57] <hatch> I'm going to grab some lunch soon to let those land
[17:57] <kadams54> hatch: OK, I'm going to proceed with the card I have in progress then. Ping me once you're ready to proceed.
[18:01] <hatch> sounds good
[18:42] <hatch> ugh this darn CI
[18:42] <hatch> I'm blaming ci when it's more than likely our test suite
[18:42] <hatch> :)
[18:54] <hatch> lots of interesting talks at I/O unfortunately most aren't being streamed - I hope they are still recorded and put up afterwards
[18:56] <rick_h_> hatch: yea, I'm sure they will be
[18:56] <rick_h_> hatch: how goes CI? is it hating?
[18:57] <hatch> it just keeps getting that intermittent failure for some reason
[18:57] <hatch> looks like this last run is going to work though
[18:58] <rick_h_> hmm, yea that notificatoin one in IE is normal. Odd to see them so grouped together.
[19:15] <hatch> rick_h_ anything else you'd like to see in the release notes? https://gist.github.com/hatched/05547f6ca921c580996e
[19:24] <rick_h_> hatch: looking
[19:25] <rick_h_> hatch: don't think (FIX) SSL handshake fails in OSX Safari is part of gui release
[19:25] <hatch> removed
[19:25] <rick_h_> hatch: doing a quick search through bugs
[19:25] <hatch> I'm having an issue getting make docs working....hope this time it works
[19:25] <rick_h_> hatch: I'd mention the export filename
[19:26] <hatch> done
[19:26] <rick_h_> hatch: https://bugs.launchpad.net/juju-gui/+bug/1295264 and https://bugs.launchpad.net/juju-gui/+bug/1249039 should probably be called out as well
[19:26] <_mup_> Bug #1295264: jujugui allows iframing and can be clickjacked in this way <netcraft> <juju-gui:In Progress by frankban> <https://launchpad.net/bugs/1295264>
[19:26] <_mup_> Bug #1249039: Exporting from real environment exports juju-gui as well <juju-gui:Fix Committed by frankban> <juju-quickstart:Invalid> <https://launchpad.net/bugs/1249039>
[19:26] <rick_h_> as they change behavior
[19:27] <rick_h_> hatch: but other than that that's good
[19:27] <rick_h_> and kind of sad really :/
[19:27] <hatch> the exports gui one was done last release
[19:27] <rick_h_> was expecting it to be a huge changelog
[19:27] <hatch> :) lots of loc's changed heh
[19:27] <rick_h_> hatch: oh, then I fail at keeping that up to date
[19:27] <hatch> I'll add the clickjacking though
[19:28] <rick_h_> ty
[19:29] <hatch> rick_h_ updated https://gist.github.com/hatched/05547f6ca921c580996e
[19:30] <rick_h_> hatch: LGTM
[19:33] <bac> hey hatch, do you have a moment for a quick hangout?
[19:33] <hatch> just doing the release but sure
[19:33] <hatch> link?
[19:34] <bac> hatch: nm, if you're busy
[19:34] <bac> hatch: but i'm in daily standup if you're not
[19:34] <hatch> sure it's making right now
[19:52] <hatch> MAN safari is fast running these tests compared to chrome
[19:58] <hatch> 362 commits since last release
[19:59] <hatch> hey rick_h_ I made a bad tag :/
[19:59] <hatch> oh phew it's an easy fix
[19:59] <hatch> heh
[20:00] <kadams54> Bad hatch, bad!
[20:01] <hatch> I know!
[20:08] <hatch> rick_h_ I'm getting gpg errors when trying to upload the final release - this is going to lp right?
[20:09] <rick_h_> hatch: yes
[20:09] <hatch> ok I'll have to look there
[20:11] <rick_h_> can anynoe hit http://maas.jujugui.org/MAAS ?
[20:12] <hatch> negative
[20:12] <rick_h_> hmm, try sans MAAS
[20:12] <hatch> I get to hoover with just jujugui.org
[20:12] <hatch> but nothing else works
[20:13] <rick_h_> sorry, meant the end one
[20:13] <rick_h_> http://maas.jujugui.org
[20:13] <bac> nope
[20:13] <rick_h_> hm, ok
[20:13] <hatch> nope
[20:14] <bac> rick_h_: maas.jujugui.org.	861	IN	A	<IP_ADDRESS>  <- that right?
[20:14] <rick_h_> bac: rgr
[20:19] <rick_h_> hatch: worst case make sure all your stuff is pushed up to the main repo and I'll pull it down and do the upload if that's what's left
[20:19] <hatch> rick_h_ that's the only thing that's left
[20:20] <hatch> for some reason it's not accepting my key even after moving it over
[20:20] <hatch> gimme a few more mins
[20:20] <rick_h_> hatch: ok, cloning down while you do that
[20:23] <hatch> rick_h_ yeah I'm not sure what's going on here
[20:23] <hatch> I might need to get in touch with the is guys
[20:24] <rick_h_> hatch: ok, testing a make distfile here
[20:24] <rick_h_> hatch: this is 1.1.0?
[20:24] <hatch> it is
[20:25] <hatch> master should have the 1.1.0 tag
[20:25] <rick_h_> okie cool
[20:25] <rick_h_> ok, uploading
[20:26] <rick_h_> hatch: ok, release uploaded, please carry on from there. https://api.launchpad.net/1.0/juju-gui/stable/1.1.0/+file/juju-gui-1.1.0.xz
[20:26] <hatch> thanks
[20:32] <hatch> annnnnd done
[20:32] <hatch> just waiting for CI to clear out so I can run it again
[20:32] <rick_h_> hatch: wow, that was fast. charm is updated?
[20:33] <hatch> ohh I didn't know there were any changes to the charm heh
[20:33] <rick_h_> oh, you mean the git/repo release part cool
[20:33] <rick_h_> hatch: well we need to copy the new release file to the charm and update it
[20:33] <hatch> annnd I don't have bzr installed
[20:33] <hatch> ggreeeaaattt
[20:33] <rick_h_> lol
[20:34] <hatch> it's clearly been a while since I've done this
[20:37] <hatch> bzr is downloading the charm repo, see ya'll in a week
[20:38] <rick_h_> good thing you're on real interwebs today
[20:38] <hatch> haha, so true
[21:01] <hatch> rick_h_ how do I know what to tag the trusty charm release at?
[21:01] <hatch> it says `bzr tag 0.11.0` but.... that doesn't match the revno
[21:02] <rick_h_> hatch: that's just the charm source tag. It doesn't matter for the charm itself in the juju store
[21:02] <hatch> well the current tags are in three different formats lol
[21:03] <hatch> the most recent appears to be 1.0.2
[21:03] <hatch> so it must now match the gui release?
[21:03] <rick_h_> hatch: yea, I think we were marking them that way
[21:03] <hatch> ok cool
[21:04] <hatch> rick_h_ ok and are we not updating the precise charm any longer?
[21:04] <hatch> Or are the docs missing a step?
[21:05] <rick_h_> hatch: right, the precise charm is left behind due to packages and deps used in the charm
[21:06] <rick_h_> hatch: I believe...
[21:06] <hatch> ok cool
[21:06] <hatch> haha
[21:13] <hatch> rick_h_ they are killing the yui gallery
[21:13] <rick_h_> hatch: not surprised
[21:14] <rick_h_> hatch: without a true ssl gallery on the cdn and such we never could use it either. and managing it was a mess
[21:17] <hatch> yeah true true
[21:18] <hatch> rick_h_ so I am having a heck of a time here - I can't get make-lint to run
[21:18] <rick_h_> hatch: ok
[21:18] <hatch> https://gist.github.com/hatched/aed7e6f1ae2d85a436a0
[21:18] <hatch> that's the error
[21:18] <rick_h_> hatch: want to hangout and share the errors? Or I can look at updating the charm tomorrow in the morning
[21:18] <rick_h_> hatch: make sysdeps
[21:19] <rick_h_> oh! I don't think that's in there, sudo apt-get install python-dev
[21:19] <hatch> ohh ok installing
[21:22] <hatch> oh now I need pip
[21:22] <hatch> lol
[21:22] <hatch> maybe....
[21:22] <hatch> or does make lint not have any output?
[21:23] <hatch> https://gist.github.com/hatched/f8cbc4ee1452467036d5
[21:23] <hatch> does that mean lint passed?
[21:23] <rick_h_> hatch: so you need to run make sysdeps
[21:23] <rick_h_> and make deps
[21:24] <rick_h_> and then make lint
[21:24] <hatch> make: Nothing to be done for `deps'.
[21:24] <rick_h_> ok, sysdeps?
[21:24] <rick_h_> maybe try this
[21:24] <hatch> just ran, trying again
[21:24] <hatch> nope that's good
[21:25] <rick_h_> make sysdeps && make deps && make unittest
[21:25] <rick_h_> does that run/pass?
[21:25] <hatch> yep
[21:25] <hatch> OK
[21:25] <hatch> [I 140612 21:25:27 testing:609] PASS
[21:25] <hatch> so make lint must not have any output
[21:25] <hatch> successful or not
[21:26] <hatch> er - when it's successful
[21:26] <rick_h_> hmm, getting that here as well
[21:27] <rick_h_> yea, most lint shouldn't say anything if it's ok
[21:27] <rick_h_> carry on! :)
[21:27] <hatch> well I guess I will continue on for the real env tests
[21:27] <hatch> oh ok
[21:27] <hatch> :)
[21:27] <rick_h_> that pip thing looks bad though but it's working
[21:27] <hatch> now lets see if this machine has juju...lol
[21:28] <rick_h_> lol
[21:28] <hatch> it does it does
[21:28] <rick_h_> going afk for a few min, hit me up on hangouts chat on my phone if you hit another wall, biaf
[21:32] <hatch> juju-test is missing....hmm
[21:33] <hatch> ahh charmtools not installed
[21:34] <hatch> well hello Makyo
[21:36] <Makyo> Hey!  Finally got net.
[21:37] <hatch> rock on!
[21:37] <hatch> done a speed test yet?
[21:40] <Makyo> Not yet.  Literally just turned on, IRC was still running on a stale connection.
[21:41] <rick_h_> Makyo: woot
[21:41] <rick_h_> ok, I've got to go. Wife is leaving and the boy is in my hands
[21:41] <rick_h_> hatch: I'll try to keep an eye on irc from the kitchen
[21:42] <hatch> rick_h_ cool, it's running the ec2 tests
[21:45] <hatch> brb while this test runs
[21:49] <rick_h_> hatch: yea, those will take a while
[21:50] <Makyo> hatch, 10 down, 1 up
[21:51] <rick_h_> Makyo: that's the microwave?
[21:51] <Makyo> rick_h_, no, they told me "it's not you, it's us" and broke up with me.  This is satellite.
[21:51] <rick_h_> wow
[21:52] <rick_h_> curious how your hangouts go
[21:52] <rick_h_> what's the ping times?
[21:52] <Makyo> Yeah, me too :/
[21:52] <rick_h_> move out to the woods?
[21:52] <Makyo> 500-1000ms :/
[21:52] <Makyo> I didn't think so, but apparently.
[21:52] <Makyo> Event Centurylink told me no.
[21:52] <rick_h_> wow
[22:00] <hatch> ykes
[22:11] <hatch> annnnd now one more ec2 test
[22:12] <hatch> I think it's closer to 40mins per test run :)
[22:12] <hatch> maybe depending on the instance spin up time on ec2
[22:27] <huwshimi> Morning
[22:38] <hatch> hey huwshimi
[22:38] <huwshimi> hatch: Hey
[22:44] <huwshimi> hatch: No call I guess this morning then?
[22:45] <rick_h_> huwshimi: is it time? /me looks at calendar
[22:45] <rick_h_> wtf why did my alarm not go off
[22:45] <rick_h_> huwshimi: sorry, call if you're able
[22:45] <huwshimi> :)
[22:45] <huwshimi> rick_h_: Sure!
[22:46] <rick_h_> hatch: jcsackett welcome to join
[23:02] <hatch> jujugui anyone remember what the path was for the juju gui charm on launchpad?
[23:03] <rick_h_> hatch: use the links in the web ui
[23:03] <huwshimi> http://bazaar.launchpad.net/~juju-gui-charmers/charms/precise/juju-gui/trunk/files
[23:03] <huwshimi> hatch: USE THE GUI
[23:03] <hatch> hah thanks - lp still confuses me
[23:04] <bac> TEH GUI
[23:05] <hatch> lol
[23:10] <hatch> and charms have been pushed up
[23:11] <hatch> now I'm going to mow the lawn
[23:11] <hatch> :) bbl


[00:07] <bluesabre> Unit193: poke
[00:08] <Unit193> bluesabre: I didn't do it, it was ochosi.
[00:08] <bluesabre> ah
[00:08] <bluesabre> ochosi: poke
[00:08] <Unit193> :D
[00:08] <bluesabre> Unit193: so, where is the xfwm4+patch hiding?
[00:09] <Unit193> https://sigma.unit193.net/source/xfwm4_4.11.2-0ubuntu2.dsc where it normally is.
[00:09] <bluesabre> thanks
[00:10] <Unit193> Sure thing.
[00:13] <bluesabre> looks good, pushed
[00:13] <Unit193> brainwash: ^
[00:13] <Unit193> Thanks.
[00:14] <bluesabre> power-manager time
[00:14] <bluesabre> :)
[00:14] <Unit193> Ah, at least one thing out of there.
[00:27] <Unit193> bluesabre: So, got it figured out or need a pointer?
[00:27] <bluesabre> have a pointer to give?
[00:27] <Unit193> In shlibs, -xxfce4-panel
[00:30] <Unit193> Tell me if it actually works, didn't look too far into it. :P
[00:31] <bluesabre> in shlibs...
[00:32] <bluesabre> debian/shlibs?
[00:32]  * bluesabre is in unknown territory
[00:35] <holstein> knome: ok :)
[00:36] <Unit193> override_dh_shlibdeps -- -xxfce4-panel, if I read correctly, bluesabre.
[00:37] <bluesabre> ah
[00:37] <bluesabre> ok, I know where that goes at least ;)
[00:38] <Unit193> If you read the manpage, you may get a different understanding than I do though.
[00:44] <bluesabre> hm, no good, Depends: libc6 (>= 2.4), libcairo2 (>= 1.2.4), libglib2.0-0 (>= 2.37.3), libgtk2.0-0 (>= 2.18.0), libupower-glib1 (>= 0.9.0), libx11-6, libxfce4ui-1-0 (>= 4.9.1), libxfce4util6 (>= 4.9.0), libxfconf-0-2 (>= 4.6.0), libxrandr2 (>= 2:<IP_ADDRESS>), xfce4-panel (>= 4.11), xfce4-panel (<< 4.13), xfce4-power-manager (>= 0.8.0~), xfce4-panel (>= 4.11.0) | lxpanel
[00:47] <bluesabre> oh wait
[00:47] <bluesabre> typo
[00:47] <Unit193> Not going to version that lxpanel ?
[00:47] <bluesabre> 1 thing at a time :)
[00:47] <Unit193> :D
[00:48] <Unit193> Another thing to think about when the time comes, looking at a bottom limit or a roof?
[00:49] <bluesabre> I think ochosi said the api is completely different with the next lxpanel release
[00:49] <bluesabre> so, << 0.7
[00:49] <Unit193> Exactly what I'm referring to, yep.
[00:49] <bluesabre> dang, still didn't work
[00:50] <Unit193> Yeeeep, read that one wrong, I see.
[00:50] <bluesabre> http://paste.ubuntu.com/8173916/
[00:51] <Unit193>  X != x
[00:52] <bluesabre>        -Xitem, --exclude=item
[00:52] <Unit193> -- means pass it to dpkg-shlibdeps.
[00:52] <Unit193> http://manpages.ubuntu.com/manpages/trusty/en/man1/dpkg-shlibdeps.1.html I could be reading that part wrong though, but looks right to me.
[00:53] <bluesabre> oh
[00:53] <bluesabre> manpage is different there
[00:53] <bluesabre> longer
[00:53] <bluesabre> I'll try little x now
[00:53] <Unit193> dh_shlibdeps != dpkg-shlibdeps
[00:53] <Unit193> (Also, why do you think I took the lxpanel side?)
[00:54] <bluesabre> :D
[01:07] <bluesabre> yay!
[01:07] <bluesabre> Depends: libc6 (>= 2.4), libcairo2 (>= 1.2.4), libglib2.0-0 (>= 2.37.3), libgtk2.0-0 (>= 2.18.0), libupower-glib1 (>= 0.9.0), libx11-6, libxfce4ui-1-0 (>= 4.9.1), libxfce4util6 (>= 4.9.0), libxfconf-0-2 (>= 4.6.0), libxrandr2 (>= 2:<IP_ADDRESS>), xfce4-power-manager (>= 0.8.0~), xfce4-panel (>= 4.11.0) | lxpanel
[01:12] <Unit193> There you go, sparky!
[01:13] <bluesabre> you still did all the work, but now I'll know for next time
[01:14] <Unit193> Heh, well there is that, yeah. >_>
[01:14] <Unit193> Remember to version the b-dep on 0.6.2-0ubuntu2 else you won't get the headers, and I guess we need to bump that bug now. :/
[01:15] <bluesabre> well, this won't build with that until we get the lxpanel in there
[01:15] <bluesabre> do we want to do it all at once?
[01:17] <Unit193> Just waiting on someone to sponsor lp 1361459
[01:18] <bluesabre> we could also subscribe gilir to that bug
[01:19] <Unit193> Might be good, also give a heads up he'll want to seed -plugins unless it's too late.
[01:19] <Unit193> +could, I meant could.
[01:20] <bluesabre> want to subscribe him?
[01:20] <bluesabre> :)
[01:22] <Unit193> Done.
[01:22] <bluesabre> yay!
[01:22] <bluesabre> :D
[01:23] <Unit193> And...
[01:23] <Unit193> For good luck and all.
[01:25] <bluesabre> nice
[01:27] <Unit193> Anything else I need to look at?
[01:27] <bluesabre> I think you're clear
[01:28] <bluesabre> go have some fun
[01:28] <bluesabre> :D
[01:28] <Unit193> Eh, no fun to be had.
[01:28] <bluesabre> D:
[01:31] <bluesabre> make one of these http://uk.reuters.com/video/2014/08/20/hoverbike-aims-to-take-aviation-to-a-new?videoId=340553849
[01:32] <Unit193> Hah, also funny because it redirected me to "Genetically modified mosquitoes to combat dengue in Brazil"
[01:33] <bluesabre> I tried
[01:35] <bluesabre> micahg_, mr_pouit: if either of you are around, would you mind adding me to https://launchpad.net/~gtk-theme-config-maintainers so I can make a release :)
[08:38] <elfy> good day peeps
[08:40] <elfy> ochosi: front page of xubuntu.org - do we want to add the beta to that - or replace LTS with the beta?
[09:24] <brainwash> Unit193: thanks for re-introducing the patch :)
[09:28] <ochosi> elfy: i think adding the beta might be a good idea. the lts announcement is still fairly recent and might interest
[09:28] <ochosi> as soon as we're at the final beta or RC of 14.10, we can always remove it
[10:06] <elfy> ochosi: agreed - and so did whoever did it :p
[10:22] <elfy> bug 1294209 got fixed then the fix was reverted - is the bug going to be fixed again for trusty?
[10:22] <elfy> bug 10778 is the bugzilla one
[10:22] <elfy> https://bugzilla.xfce.org/show_bug.cgi?id=10778
[10:23] <knome_> xfce 10778
[10:23] <knome> elfy, ^
[10:23] <elfy> knome: aah :)
[10:23] <elfy> thanks
[10:23] <knome> np, and good afternoon
[10:23] <knome> wait, it's still morning there
[10:23] <elfy> it is :)
[10:24] <knome> calculation fail
[10:24] <elfy> I'll bank that for 36 minutes time :p
[10:24] <knome> heh
[10:27] <brainwash> elfy: bug 1319029
[10:27] <brainwash> ^ the reason why it got re-opened
[10:35] <elfy> brainwash: yes I know - I didn't see the need in spamming the channel with a whole bunch of bug lines :)
[10:36] <elfy> that though isn't what I'd like to know - what I'd like to know is if it's going to fixed - again :p
[10:37] <elfy> glorious - I'm stuck in nvidia/nouveau limbo again :(
[10:37] <elfy> nvidia installed, nouveau being used
[10:56] <ochosi> elfy: yeah, i changed it
[10:56] <ochosi> (i mean the frontpage)
[10:56] <elfy> ochosi: thanks
[10:56] <elfy> yep - guessed
[11:01] <brainwash> ochosi: should the 14.10 beta page inform the user about our compton config? some may want to test it
[11:01] <knome> brainwash, aren't you a bit late? we worked on the release announcement the other day
[11:02] <brainwash> beta 2
[11:02] <brainwash> :P
[11:02] <knome> right... is there a beta 2 page yet?
[11:02] <elfy> I'd say if we wanted people to do that - would be useful to do so seperately, much like the mucking about with core
[11:02] <ochosi> bluesabre was against it, since we're not actively endorsing compton (and i agree)
[11:02] <brainwash> the thing is, I've just noticed it 2 minutes ago
[11:02] <ochosi> brainwash: feel free to blog about it ;)
[11:03] <knome> i've been jumping on and off, so i might have missed something...
[11:04] <brainwash> ochosi: but we could need some feedback
[11:04] <ochosi> brainwash: not sure, we're supplying a config that might work for most
[11:04] <ochosi> but that's about it
[11:04] <ochosi> it might work great for some, not at all for others
[11:04] <ochosi> (which is also the reason why we won't ship compton by default)
[11:05] <ochosi> so yeah, it is exactly that, i don't want a bugreport with 100 different users endorsing different configs. with all the types of hardware and drivers we wouldn't know what to ship anyway
[11:07] <brainwash> mmh, so we should place the config somewhere else, so it's not picked by default when compton is installed
[11:08] <brainwash> these are not the default settings of compton
[11:08] <ochosi> yeah, ofc they're not. they're made to resemble our default theme visually
[11:10] <brainwash> ok fine
[12:45] <brainwash> where is mr_pouit ? I could need some help with cleaning up launchpad reports :P
[12:48] <knome> he's mostly inactive. why do you need him specifically?
[12:49] <brainwash> he used to be very active on launchpad, well, few years ago
[12:56] <brainwash> it's just that people do report bugs, but many don't receive an answer during the release cycle (if any answer at all)
[12:57] <knome> right... so replying is up to those who are actually available and active during the cycle, not people who used to be active 2 years ago, do you agree?
[12:57] <brainwash> I do
[12:57] <knome> so why do we need to poke lionel, who isn't really active any more?
[12:58] <brainwash> worth a try
[12:59] <brainwash> he might feel the urge to fight against army of zombie launchpad reports one more time :D
[12:59]  * ochosi doubts anyone has ever felt that urge
[12:59] <brainwash> it helps the project
[13:01] <brainwash> ideally the current package maintainer(s) would do this, but I know that it's a time consuming task
[13:09] <ochosi> brainwash: frankly, one bug tracker is enough for me
[13:09] <ochosi> i've been cleaning up bugs.xfce for quite a while now, mostly for the components i contribute to
[13:09] <ochosi> but another bugtracker would mean getting even less done
[13:09] <brainwash> I know that
[13:42] <brainwash> ochosi: I need some help with bug 1188065
[13:43] <brainwash> valid request?
[13:43] <brainwash> this has not been reported upstream yet
[13:47] <ochosi> it's somewhat valid, but i'm not sure what upower offers exactly
[13:47] <ochosi> we don't calculate these values ourselves
[13:49] <brainwash> ah I see
[18:49] <Unit193> brainwash: So yes, thanks for keeping the bug reports down.  Usually when I look, it's several "$package failed to install/upgrade: subprocess installed post-installation script returned error exit status 2" or one of those. :/
[21:28] <lbracher> Hi there! Do you know if it's possible to do a PXE boot using a xubuntu iso? TIA!
[21:29] <Unit193> Yep.
[21:30] <Unit193> Or if not, I better undo doing it. :P
[21:30] <Unit193> ...Though yeah this is the development channel.