[00:19] * huwshimi heads to cafe [11:22] morning party people [12:03] hi rick_h_: welcome back [12:06] rogpeppe1: I am looking at FakeHomeSuite. It seems we can either 1) embed IsolationSuite in it: this means we can safely assume all the JUJU_* env variables are empty as expected by the tests, but also means lots of tests will explode in core (and need to be fixed) due to the fact they do not use complete paths when calling external commands. [12:07] rogpeppe1: or 2) just use Logging and Cleanup suites in FakeHomeSuite. This means we'll need to move the JUJU_* en var resetting logic (currently in BaseSuite) to FakeJujuHomeSuite [12:08] frankban: hmm [12:08] * rogpeppe1 goes to look at BaseSuite [12:09] rogpeppe1: basically FakeJujuHomeSuite tests need os.Setenv(osenv.JujuHomeEnvKey, "") stuff (currently in BaseSuite) [12:10] rogpeppe1: but most of them also need PATH to not be empty (and I guess this should be fixed) [12:10] frankban: the worry i have moving the JUJU_ env setting stuff to BaseSuite is that tests that currently use BaseSuite won't get the benefit of that [12:10] rogpeppe1: JUJU_ env setting stuff is already in BaseSuite [12:11] rogpeppe1: and that does not seem right BTW [12:11] frankban: sorry, i meant "away from BaseSuite" [12:13] hi frankban [12:14] frankban: it does seem kind of "right" that the JUJU_ env stuff should be in FakeJujuHomeSuite though [12:14] rogpeppe1: I am not suggesting to remove those from BaseSuite. I guess eventually BaseSuite will embed IsolationSuite, which removes all the env vars, but for now that's not my goal [12:15] frankban: can't FakeHomeSuite embed BaseSuite? [12:16] rogpeppe1: yeah, but the problem now is that FakeJujuHomeSuite embeds FakeHomeSuite, which in turn embeds BaseSuite. I am moving FakeHomeSuite to github.com/juju/testing and I have two choices: 1) make FakeHomeSuite embed IsolationSuite and 2) make FakeHomeSuite just embed Logging and Cleanup suites (without removing env vars) [12:17] rogpeppe1: 1) means we need to fix all the FakeJujuHomeSuite and FakeHomeSuite tests which rely on PATH to be set [12:17] frankban: what's the problem with "FakeJujuHomeSuite embeds FakeHomeSuite, which in turn embeds BaseSuite" ? [12:17] oh, i see, sorry [12:17] frankban: i think that 2) seems a reasonable way forward currently [12:17] rogpeppe1: 2) means we need to have the JUJU_ resetting logic in FakeJujuSuite [12:18] sorry FakeJujuHomeSuite, darn! [12:18] frankban: that seems fine [12:19] frankban: and actually quite appropriate [12:20] rogpeppe1: sounds good. So do you mean moving that JUJU_* logic from BaseSuite to FakeJujuHomeSuite or just make them share the same logic? [12:20] bac: morning [12:21] frankban: perhaps duplicate for the time being, to ensure we don't regress, adding a TODO to make BaseSuite embed IsolationSuite [12:22] rogpeppe1: sounds good thanks. today lesson: always use complete paths [12:42] frankban: rogpeppe1 if you guys get a second wonder if we can do a quick hangout to catch up on where the store extraction stands please. I'm not 100% clear looking at the board. [12:43] * rogpeppe1 generally only wonders once [12:44] :) [12:44] rick_h_: happy to have a hangout whenever [12:44] it's that second wonder that provides true clarity [12:45] rogpeppe1: frankban https://plus.google.com/hangouts/_/calendar/cmljay5oYXJkaW5nQGNhbm9uaWNhbC5jb20.t3m5giuddiv9epub48d9skdaso?authuser=1 [12:48] frankban: i think doing the backport of 0.12 to saucy and precise is cleanest. should be straightforward. [12:50] frankban: but changing the quickstart packaging branch between PPA builds is not sustainable. :) [12:53] frankban: but if we're going to do a backport of 0.12 we could make the package name python-websocket, as in trusty, and the whole problem goes away, right? [13:03] bac: then you have jujuclient which still depends on "python-websocket-client" on saucy and precise [13:05] bac: so, I guess the plan is: 1) trusty is ok 2) backport python-websocket 0.12 as python-websocket-client on saucy and precise 3) add the backported packages to the quickstart-beta ppa and to the juju-stable ppa [13:10] frankban: but do we still have a build issue? or is the current code, with websocket in test-requirements, a-ok? [13:11] bac: it should be ok, right now quickstart installs on trusty and saucy. we only need a newer websocket-client on precise and saucy [13:12] frankban: ok [13:18] morning, all. [13:19] argh, wrong upstream [13:20] morning jcsackett [13:25] aweful lag:(( [13:46] guihelp: Anyone else here make heavy use of buffergator in vim? [13:47] never heard of it [13:47] lustyjuggler user here [13:47] what's vim? [13:47] redir: that's it, you're fired :P [13:47] :-b [13:47] LOL [13:48] i use lustybuffer, rather than juggler. juggler would crash periodically on me for reasons i never bothered to investigate. [13:49] buffergator looks nice. [13:49] Is it this http://bit.ly/Tm8jat ? [13:49] :-) [13:49] No way am I touching that link [13:50] sure youren't [13:50] it's calling you [13:52] Hah! [13:52] Like a siren [13:53] I should make a chrome extension that pre-examines target pages for shortened URLs and when it finds a rickroll/goatse/whatever on the other side instead displays a "stop being a putz" message. [13:55] kadams54: I'd use it [13:55] I think there's a real market for it ;-) [14:00] woo, testing/filetesting changes finally merged [14:00] rogpeppe1: yay! [14:04] hmm, i'm seeing this message when committing a merge: [14:04] # It looks like you may be committing a merge. [14:04] # If this is not correct, please remove the file [14:04] # .git/MERGE_HEAD [14:04] # and try again. [14:04] does anyone know how/why i might be seeing that and if it's a significant problem? [14:05] http://git-scm.com/book/ch3-2.html [14:05] See at the very bottom of the page [14:06] kadams54: oh, right, so it's just normal behaviour [14:06] kadams54: thanks [14:06] It's not necessarily a problem, if you are in fact committing a merge [14:06] Yup [14:48] sheesh so there are already like 5 swift meetup groups in new york I have gotten emails about. [14:48] yay swift :P [14:49] silly [14:49] such facepalm [14:49] it's actually a pretty cool language [14:49] but its so high up in that tower over there [14:49] yay doge meme, now that will by stuck in my head for another week, thanks hatch [14:50] I'll be in Pisa muttering *such historic* *very tilting* [14:50] jujugui call in 10 [14:50] :) === hatch__ is now known as hatch [14:55] woah [14:55] I think I was lagged huge there [14:55] did everyone get the 10min warning? === hatch__ is now known as hatch [14:55] got it here [14:55] ok cool, that was odd [14:55] it just stopped responding and booted me so I wasn't sure [14:55] well, I got Makyo's 10min warning [14:55] oh... [14:56] https://twitter.com/FromAnEgg/status/474927316846403585 hehe [14:59] jujugui call in 2, get your kanban ready and prepare for a long poker call wheeee [14:59] * hatch plays with his chips [14:59] * hatch puts his hoodie and sunglasses on [15:00] kadams54_: as well :P [15:01] rogpeppe: call time [15:16] rogpeppe: when you have time: https://github.com/juju/testing/pull/12/files [15:19] hatch: English words with 'mv': http://paste.ubuntu.com/7602348/ -- we're pretty safe. [15:21] frankban: reviewed [15:23] rogpeppe: thanks, I agrre with you, perhaps in these cases not rebasing before the proposal can be a good idea [15:23] frankban: yeah, definitely [15:24] frankban: could you revert and re-push, in fact? [15:24] frankban: i.e. revert to before your rebase [15:25] rogpeppe: not sure. BTW, the suite itself and the test file is new code. so basically home.go from line 83 and the whole home_test.go [15:25] frankban: i'd still like to see the diff, if poss [15:25] frankban: just to see what the old code looked like [15:26] frankban: i guess i could just look in my editor :-) [15:28] rogpeppe: original code is in /testing/base.go [15:32] frankban: still LGTM [15:32] rogpeppe: cool thanks [15:36] rick_h_: paste here please [15:37] https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0ApyaFXSrLF38dGVCYUhGLTRXMXRaVXBCMUFjQlJMTkE&usp=drive_web#gid=4 [15:57] rick_h_ I can take a look at the review board thing if you like [15:57] hatch: coolio, I'll send an invite to your email [15:57] thx [16:05] bac: still have power and water? [16:05] both! [16:05] woot! [16:06] on that topic - we are getting the new 'smart' gas and power meters sometime over the next month [16:06] hatch: I've got mine, it just means they get to tell me how much a power hog I am over my neighbors [16:06] rick_h_ lol [16:07] rick_h_: I filed my summer holidays in the new hr site [16:07] we have a coal power plant....they can't burn less if they wanted to! [16:07] not sure what the smart meters will do lol [16:07] frankban: looking [16:13] frankban: interesting in checking ot the reviewboard stuff? You were interested in the side by side reviews? [16:13] anyone else? [16:14] rick_h_: sounds interesting [16:35] * rick_h_ goes to get some lunch [16:36] * frankban biab [17:18] hey who's cHilDPROdigY1337 ? [17:20] * redir blinks [17:20] * redir actually bL1Nk5 [17:21] * redir goes to grab some lunch [17:22] lol! [17:43] I'm not convinced about this new hr portal lol [18:05] jujugui looking for a very quick review on the new cache https://github.com/juju/juju-gui/pull/371 [18:05] On it [18:05] Ow my eyes! [18:05] They burn, they burn! [18:05] yeah it's so basic [18:05] sorry...lol [18:06] hmm I was sure I had a card to hook up the cache in project 1 [18:06] rick_h_ ^ [18:06] The PR looks good and I'll reply as such in the comments… [18:06] ahh found it [18:08] hatch: yea sorry, sidetracked atm [18:08] np [18:08] I found the related card/bug [18:09] hatch: one thing that I wondered is if the cache needs to support expiration. [18:09] ugh I friggen hate test failures under prod [18:09] I suppose you could expire to a certain extent by setting a key to null [18:09] kadams54 no this cache is one step above a manilla folder [18:09] reload the page :P [18:10] it's something we can look into, but since the cache is charm/version specific it can't change [18:10] * kadams54 ponders a world where one step above a manilla folder is 126 lines of javascript [18:10] 90% of which are comments [18:11] Still. I think we're more than a few steps above a physical world object ;-) [18:11] haha maybe a few [18:16] kadams54 I am going to continue working on my other cache class though - how would YOU do expiration? able to supply a timestamp or a fn which is called periodically? [18:23] lazyPower hey, this is me poking you about my Ghost charm again :) I want to put out a blog post et all but can't until it's in the store :) [18:23] hatch: bcsaller is on rev this week [18:23] * lazyPower politely redirects [18:23] * hatch puts on his hunting cap and goes hunting him down [18:32] jujugui recently there have been a lot of test failures around the 49th test - has anyone looked into why this is happening? [18:32] hatch: what's the 49th test? [18:33] rick_h_ well it's -around- there, sometimes it's more, sometimes less [18:33] I think you and frankban also saw this [18:34] hatch: if it's that one no. I just saw it for the first time on frakban's branch trying to land [18:35] can we create an investigate card? [18:35] hatch: by all means, put it in maint. Make sure to have links to the failures we know about to debug [18:39] created! Here is the failure rick_h_ https://saucelabs.com/jobs/2ce12db7af234450af18a44b6327e9c7 [18:40] the merge run on the other hand is running without issue [18:40] * hatch punches test suite [18:40] I am developer hear me roar! [18:44] jujugui is there documentation for quickstart? The readme is pretty sparse [18:46] bac: jcsackett ping when you get a sec would like to chat please [18:46] can quickstart be used to fire up the GUI into your active environment? [18:46] juju quickstart -e amazon [18:46] boom browser opens? [18:47] jujugui board is loaded up with work items for the next two weeks. Let me know if anything looks off/unclear [18:47] hatch: yep [18:47] thanks [18:47] wow, scheduling work for 9 devs now. Moar points of work! [18:54] haha that is a lot of points [18:56] rick_h_: update: the backport packages are coming along. since it wasn't a simple backport, but required changing the binary name, none of the simple tools like backportpackage could be used. hopefully i'll have it up on the PPA for building very soon now. [18:56] bac: very cool [18:57] rick_h_: also, the brew formula is done and works with jj-qs 1.3.2. but, of course, that version doesn't actually work with osx, but brew can install the hell out of it [18:57] lol, that's good [18:57] bac: got time to chat for a sec? [18:57] sure [18:57] let me grab my headphones [18:58] sure thing [18:58] https://plus.google.com/hangouts/_/g5f5fs3tejaybejaqipregrldma?authuser=1&hl=en [18:59] jcsackett: ^ as well if you're around or get in [19:03] I'm stepping away for lunch, ding if ya need me [19:12] jcsackett: overheated after five minutes. back inside. [19:15] * jcsackett laughs [19:15] yeah, it's getting that bad here too. i basically can only go work on the porch in the morning. [19:15] It's the skeeters here. [19:16] It's sunny and 22C so I'd LOVE to work outside [19:16] But it's a veritable cloud outside [19:16] of bloodsucking beasties [19:17] hatch: the caching libraries I've worked with in the past usually had an optional param for expiration in milliseconds. So cache.set('foo', 4000) would expire 'foo' in 4 seconds. [19:18] Well, cache.set('foo', {timeout: 4000}); [19:18] They also usually supported a cache-wide expiration that could be set in the constructor: cache = new Cache({timeout: 4000}); [19:34] i love this advice on backporting: [19:34] Why Backport? [19:34] Short answer: Don't. [19:37] lol [20:00] kadams54 cool [20:02] 13C here right now...brrrr [20:02] it almost froze last night [20:02] 25C here :/ [20:03] speaking of, I'm going to head out and get the boy from school. Have a good weekend all. [20:03] enjoy! [20:08] later rick_h_ [20:36] lol Makyo nice favourite [20:37] Wow, hah. Do you use tweetdeck? [20:37] yeah lol [20:37] some interesting stuff flows in there sometimes haha [20:38] Tweets scroll down from the top (like I suppose they do for most clients), had a tweet show up before I clicked. [20:39] haha yeah that can be irritating [20:39] Loomy, alas, is on his own :) [20:39] haha [20:47] Makyo you're on the rendering bug right? Even with the new updated cache the issue still persists [20:47] just fyi [20:48] hatch, yeah, but I'm having a hard time nailing it down. It is being rendered outside the dom, then added all at once, so I'm digging into sticky headers. [20:49] Makyo hmm, you may find some insight in the rendering timeline [20:49] I'm pretty confident it's within the token render cycle [20:49] Yeah, let me add more logs. [20:49] because there is lots of GC around there [20:49] Okay. [20:49] It just shouldn't be touching the dom. We're adding it to a new node. [20:49] I mean the Timeline tab in devtools [20:49] Ah!~ [20:49] Good chance to learn it. [20:50] there is a Frames tab in the top left [20:50] you want that one [20:50] yeah this is invaluable, lots of great info in here [20:50] there [20:58] Man, that Object.observe polyfill is annoying. [20:59] maybe we should evalutate doing a unidirectional data flow on that stuff instead of 2way binding [21:02] Yeah. We're using it for the databinding on units, right? [21:03] I have no idea hah [21:06] I think everything else is based on change events. [21:20] ahh you are probably right [21:49] yay caching works [21:49] tests on the otherhand [21:51] if you were to empty a cache [21:51] cache.expire() ? [21:51] cache.empty() ? [21:51] cache.happyPants() ? [21:51] * hatch is thinking happyPants [21:58] cache.freeeeee() [22:15] not sure if everyone got that last msg [22:15] jujugui I have hooked the cache up to the charmbrowser and the charm details views here is the WIP (only tests are next) comments appreciated https://github.com/juju/juju-gui/pull/372 [22:40] Alright, heading to the new house. See you all next week., [22:42] cya Makyo