[02:27] huwshimi hey I'm looking at your comment re the bubbling issue [02:27] hatch: Hey [02:29] huwshimi see the new units added here: https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fmachine-view-panel.js#L173 add it as a bubble target, but when a unit is added here https://github.com/juju/juju-gui/blob/develop/app%2Fwidgets%2Fmachine-view-panel.js#L78 it's not [02:31] Makyo this question is illegible but it's using your openstack bundle http://askubuntu.com/questions/481105/juju-openstack-bundle-cant-launch-an-instance I'm not sure if that bundle deploys any more? [02:43] hatch: That doesn't seem to help things. [02:43] hatch: It still breaks on that .destroy line [02:43] ok looking [02:45] huwshimi can you try this: wrap that destroy in a setTimeout with a 5s timeout or something long to see if that works - I think it's destroying the token before the event gets fired/bubbles [02:45] sorry I can't test atm [02:45] hatch, correct, that bundle was for demonstration purposes only. [02:46] Makyo might want to comment on that question to that effect :) [02:46] Makyo: remove the branch and we can remove the4 bundle from charmworld [02:46] Makyo: or maybe you can as well [02:47] Makyo: http://manage.jujucharms.com/bundle/~makyo/openstack/openstack/delete [02:47] hatch: Yep, that works with the timeout [02:48] huwshimi ok so the addTarget IS still missing but the real issue is that it's being destroyed before it can fire the event [02:48] so....hmm [02:48] rick_h_, no luck. Also, getting no stylesheets on m.jc. [02:48] vat to do [02:48] * hatch says in his best Ukrainian accent [02:48] Oh, there's the login, nevermind. [02:48] Makyo: I removed it [02:48] Oh, thanks [02:49] Makyo: oh yea, sorry you have to auth first as it's a manage thing [02:49] There we go. Thanks rick_h_ [02:50] eventful night :) [02:50] party [02:52] huwshimi using settimeout is not a valid solution either :PPP [02:52] hatch: haha [02:52] I used 600MB of data today.....doing nothing [02:53] man I hope they fix my internet soon [02:53] hah [02:53] lol [02:53] night all, see you same bat-place tomorrow [02:53] rick_h_: Night [02:53] night [02:53] I've done my git/github lecturing to core for the night :P [02:54] :D [03:00] huwshimi I'm going to hop back offline for the night - hope I got things back on track for ya :) [03:00] I'll probably check back in a little later [10:16] rogpeppe: hi [10:16] frankban: hi. am looking at your review... [10:16] rogpeppe: could you please take a look at https://github.com/juju/testing/pull/16 ? [10:16] frankban: yup :-) [10:17] rogpeppe: cool thanks. did not rebase so that you can look at changes on the third commit: Changes to MgoSuite. [10:17] frankban: am doing, thanks [10:23] frankban: rather than putting the server cert generation code into mgo.go, couldn't we just pass the server cert in along with the CA cert? [10:24] frankban: (which means that the juju-core testing code can use the actual code from the cert package that will be used for real) [10:26] rogpeppe: uhm... yes we can do that, so something like MgoTestPackageSsl(t *testing.T, srvCert, caCert *x509.Certificate, caKey *rsa.PrivateKey) ? [10:26] frankban: yeah. or put 'em in a struct. [10:27] rogpeppe: is three args enough to put them in a struct? [10:28] frankban: e.g. MgoTestPackage(t *testing.T, certs *Certs) [10:28] frankban: i think it might make sense, given that they all need to specified at once [10:28] frankban: it makes the test simpler as well (if certs != nil { .... }) [10:29] rogpeppe: oh, and at that point we no longer need caKey, right? [10:30] frankban: yeah [10:30] frankban: but we do need the server key [10:31] rogpeppe: for the &key.PublicKey bit? [10:32] frankban: for the key that gets written to the PEM file [10:32] rogpeppe: yes [10:35] rogpeppe: so something like http://pastebin.ubuntu.com/7622839/ in mgo.go? [10:37] frankban: pretty close. i'd do http://paste.ubuntu.com/7622851/ [10:37] rogpeppe: ah, sure the fields need to be exported [10:37] frankban: yeah [10:49] rogpeppe: we also need the ca key for x509.CreateCertificate [10:49] frankban: we don't need to call CreateCertificate, do we? [10:50] rogpeppe: nt sure, how do we create the pem file? we need bytes to write it [10:51] frankban: the PEM file doesn't have the CA key in it [10:51] frankban: you can get the DER bytes from the Certificate and PrivateKey [10:52] frankban: the cert bytes are in cert.Raw [10:54] rogpeppe: trying [11:15] rogpeppe: updated [11:15] frankban: looking [11:16] thanks [11:28] morning [11:37] frankban: reviewed [11:40] rogpeppe: thanks! [11:46] rogpeppe: I've found this recent commit in mgo.go, I gues I'll reproduce that (remove mgo.SetDebug(true)) in my current branch [11:47] frankban: sgtm === BradCrittenden is now known as bac [12:14] * rogpeppe goes for lunch [12:17] * frankban lunches [12:21] o/ [12:21] * rbasak didn't know this channel existed! [12:22] ha, it's *the* place to hang out [12:22] we party in our own little world [12:23] * bac -> tea. brb [12:26] bac: AIUI, the issue is because you're trying to maintain a PPA for multiple series with a single packaging branch? [12:26] This is tricky since the packaging tooling doesn't really accomodate that use case, since they've grown out of distribution tooling which focuses only on one series at once. [12:27] I suggest that you maintain a "trunk" packaging branch, and for past series that cannot use that, use more packaging branches branched from that trunk packaging branch. [12:28] Does that help at all? [12:30] rbasak: do you keep a seperate packaging branch from the source then? So you pull down the source branch, marge the changes in that into a 'trunk packaging branch' and then have branches of that for different series? [12:31] rick_h_: I don't, no. I've not hit this particular issue before, since most of my work is directly in the archive and there we don't need to update older releases much. [12:31] rbasak: ah ok [12:31] rbasak: yea, I guess we're just trying to find a workflow that's not nuts and this is the first time the simplest hasn't worked out for us [12:31] We do try in some cases to try and keep packaging in the development release more easily backportable. There's certainly value in that. [12:31] In this case though, I can't see how that is easily doable. [12:33] rbasak: ok, so a different packaging branch and different build recipes for the different sets of series with like rules. [12:33] rbasak: i think in our case, the packaging for trusty would just have the pydist-files override and the other would not [12:35] i was hoping to avoid that fork but it isn't a big deal and it is good to know you consider it best practice not lunacy [12:35] otp brb === alexpilotti_ is now known as alexpilotti === alexpilotti_ is now known as alexpilotti [13:33] bac: sorry, that was a long call. Yes - I think it's the best option. A better option would be to try and find a way to support both series in the same packaging but it sounds like that's not possible here. [13:34] So a branch is the next best option I think. [13:34] rbasak: thanks [13:36] bac: no problem. On a separate note, it might be an idea to reduce the packaging delta between your PPA and the Ubuntu archive. I noticed it varied a bit on my last upload. [13:37] rbasak: do you have a link to the one for the ubuntu archive? [13:37] i never can find those things [13:38] looking [13:38] bac: https://code.launchpad.net/~ubuntu-branches/ubuntu/utopic/juju-quickstart/utopic [13:38] bac: note that the UDD importer is a little broken and this branch is not always kept up-to-date. [13:39] So it's best to manually check. It looks good to me right now at least. [14:22] rbasak: i've created a packaging-trunk and a novel packaging branch for before trusty. however when i try to specify the pre-trusty branch in the build recipe, the merge rule gets changed to 'merge lp:juju-quickstart' without my branch specifier. have you seen this behavior before? [14:22] rbasak: the recipe is at https://code.launchpad.net/~juju-gui-charmers/+recipe/juju-quickstart-pre-trusty-daily [14:23] hatch: have interwebs today? [14:23] rogpeppe: could you please review https://github.com/juju/juju/pull/61 ? [14:23] frankban: looking [14:24] rogpeppe: thanks! [14:24] rick_h_ still hotspotting :) [14:24] hatch: :( [14:25] they probably have to run new lines the guy said [14:26] rbasak: is 'packaging' a special name? [14:26] ouch, what did you do? Let the gophers at your house? [14:26] hatch: catv or fiber? [14:27] bac, probably cat3, apparently the neighbourhood doesn't have fiber yet [14:27] I'm just hoping the line is broken in someone elses yard [14:28] bac: the recipe should include something like "merge packaging lp:juju-quickstart/packaging" where lp:juju-quickstart/packaging is the branch containing the pre-trusty debian stuff [14:29] frankban: reviewed [14:31] frankban: yes, but i need two branches, one for pre-trusty and one for trusty and beyond [14:31] frankban i have named those branches "packaging-pre-trusty" and "packaging-trunk" [14:31] frankban: if i specify them in the recipe they are rejected and replaced with lp:juju-quickstart [14:32] bac: so we need two recipes [14:32] frankban: yes, i have two recipes [14:32] frankban: do you remember what we decided to do about HTTPSuite? [14:32] frankban: what i am describing is the recipe editor javascript is not accepting the branch name [14:32] rogpeppe: I believe that suite has been already movet to testing, and we need to remove http.go in juju, right? [14:33] frankban: if i enter 'merge packaging lp:juju-quickstart/packaging-pre-trusty' it becomes 'merge packaging lp:juju-quickstart' [14:33] bac: weird... [14:33] frankban: oh, cool [14:34] frankban: so it has [14:34] abentley: do you know the internals of launchpad build recipes? [14:34] bac: so maybe we need to put packaging branches in a different series? https://code.launchpad.net/juju-quickstart [14:35] bac: Once I did, but it's been a long time. [14:36] abentley: when i try to enter my packaging branch into the recipe editor, it rejects my packaging branch name and replaces it with just the project path. [14:37] bac: paste me what you're trying to enter. [14:39] abentley: http://paste.ubuntu.com/7623848/ [14:42] abentley: i think i see the problem. the branch i'm specifying is incorrect. nm. [14:42] Ah, that makes some sense. [14:44] abentley: the previous version used lp:juju-quickstart/packaging where 'packaging' was a series not a branch. [14:52] jujugui call in 10 kanban please [14:53] bac: once packages are built with the new configuration, could you please update the HACKING file to reflect the new PPA release process? [14:59] jujugui call in 2 [14:59] frankban: yes, once it is settled. [15:01] kadams54: ^ [15:01] on my way [15:28] jujugui updated doc to propose two date ranges. 21-25 would be the whole team. If you've got time off planned please submit it and let me know [15:31] jujugui also note I'm not getting emails from the new hr system so if you file time off ping me to approve please. I see Makyo's stuff in there right now but got no email [15:40] rick_h_ I checked the flights, look like there is one which gets me back in time and I don't have to miss any of Friday [15:40] so as long as that flight stays available [15:40] ya know....because I'm sure you were just super concerned and all that [15:41] :) [15:41] hatch: hey, I'm looking out for all my buddies [15:44] yay! [15:44] heh rick_h_ did you see they changed the ES6 module spec again lol [15:45] hatch: :) yea noticed that [15:45] I think they are for the better....so that's good, but still funny [15:45] yea, the joys of following stuff in progress [15:56] * rick_h_ goes for lunchables [17:00] * rogpeppe is done for the day [17:00] g'night all [17:01] night rogpeppe [17:01] kadams54: ping, got a sec? [17:02] rick_h_: sure, what's up? [17:02] kadams54: can you do me a favor, I need to get the list of categories from the charms. We can get all the data via http://manage.jujucharms.com/api/3/search/?text=charm&min_score=0&limit=5000 [17:02] kadams54: just need to loop it, find and unique the categories values please [17:02] Will do [17:03] kadams54: ty much [17:05] "call stack exceeded" - no you're just not trying hard enough [17:05] :P [17:05] :D [17:06] debugging recursive functions is a lot of work [17:29] jujugui I'm not having any luck with tests on this branch, any thoughts? https://github.com/juju/juju-gui/pull/373 [17:30] I changed the order in which things were added to the DOM, but since everything's selected within the method, finding what to stub is hard. [17:31] Makyo: honestly, I still think it's a comment/qa and we go along. It's going to be darn near impossible to really have a good test that directs back to this [17:32] rick_h_, alright, that makse sense. I'll flesh out comments. [17:32] Makyo: thansk [17:39] bac: ping [17:39] hey rick_h_ [17:40] bac: quick charmworld ? for you. I'm trying to get a lsit of all the categories that any charm declares. The api results only show the normal set and I bet it's because we ignore the ones we don't recognize. Can you verify that? [17:40] ok [17:40] ty bac [17:45] rick_h_: yep, if the category is not in the OFFICIAL_CATEGORIES list we toss it: http://paste.ubuntu.com/7624639/ [17:45] that is from the Charm model class [17:45] bac: :( ok thanks [17:46] kadams54: ok, next step please [17:47] rick_h_: ready [17:47] kadams54: so to get this info we'll have to loop through that charm list, build the file api call to the metadata.yaml, and then find the categories out of it [17:47] kadams54: example: http://manage.jujucharms.com/api/3/charm/precise/apache2/file/metadata.yaml [17:48] kadams54: so loop, get metadata.yaml, load, output categories, next [17:48] well they have started running new cable [17:48] rick_h_: got it [17:48] * hatch hopes all the conduits are clear [17:48] hatch: trencher time! [17:48] kadams54: ty much [17:48] nah they run conduits here [17:48] they think ahead lol [17:48] I <3 api [17:49] rick_h_ now if the conduit is collapsed or plugged....well then we have problems [18:01] brb rebooting [18:04] Going to run last night's carload to the new house over lunch, back in a few. [18:05] anyone know what would cause a git push to fail with [18:05] Permission denied (publickey). [18:05] fatal: Could not read from remote repository. [18:05] it doesn't even ask for the password to unlock the keychain [18:05] hatch: wrong .git/config ? [18:05] rick_h_ well nothing has changed since yesterday... [18:05] hatch: I'd argue something has :) [18:06] hatch: push is going where you don't think it is or something? [18:06] I can't even show the origin details [18:07] github is last showing my key used today === BradCrittenden is now known as bac [18:15] so the 'fix' was to go and delete old unused keys from GH [18:15] umm thanks GH? [18:15] hah [18:20] jujugui looking for a review and qa on the cache branch https://github.com/juju/juju-gui/pull/372 [18:21] rick_h_: did you reply to my comment above? (internet dropped briefly right after i sent them.) [18:21] bac: which comment above? [18:22] the one where i said all was ok with juju-qs 1.3.4.b1 on a variety of platforms and i'd like to release 1.3.4 [18:22] that didn't make it :) [18:23] bac: yea, didn't make it to the channel [18:23] well, hell [18:23] bac: ok, so then this is the official release of quickstart with OSX support? [18:23] rick_h_: it looks like our brute force packaging approach is working. i have 1.3.4.b1 working via pip, brew, pre-trusty PPA and trusty-and-beyond PPA. i did not do full QA on all of those but everywhere i've tested it works. [18:23] 14:08 [18:23] rick_h_: i'd like to release 1.3.4 on all of those mechanisms now [18:23] kadams54 will you be around in an hour? I'm going to take lunch then look at huw's bug so I'll probably have some q's [18:23] Yeah, I'l be here. [18:24] rick_h_: yes, it will have OS X support and is a pre-cursor to actually getting the brew formula accepted into their ecosystem [18:24] while I'm gone https://github.com/juju/juju-gui/pull/372 :) [18:24] bac: +1 then on release. You've got QA from others? [18:24] hatch: will try, kadams54 or Makyo ? ^ [18:25] hatch: will take a look at it shortly. [18:25] nope. as i said, i did a full QA on 1.3.3 and have done spot checks on the different types of systems (pip, brew, pre-trusty PPA, trusty PPA) [18:25] rick_h_: ^^ [18:25] QA from others would be swell [18:26] bac: ok, let's get another QA then before release. Target it for tomorrow? [18:26] I'll try to QA after this bit here and maybe get hatch or Makyo to do another as well as other OSX users [18:26] bac: I saw a branch go by with the qa docs in there? Is there a branch we should use to QA off of? [18:26] i'll be kadams54 would love to [18:27] lol [18:27] rick_h_: trunk/HACKING.rst has a QA section [18:27] well kadam's volunteer to look at hatch's so spread the love [18:27] bac: cool [18:27] OS X will have to be via pip [18:27] bac: I presume this is around juju-quickstart for OS X? [18:27] kadams54: yep [18:28] bac: I can dive into it after I finish working with hatch. [18:28] bac: yep, that's not an issue [18:28] thanks [18:28] bac: Are there QA instructions somewhere? [18:29] kadams54: trunk/HACKING.rst has a QA section [18:29] kadams54: yeah, let me grab an URL [18:29] I can copy/paste fast :) [18:29] bac: just link him to the branch as he'll have to bzr branch it anyway right? [18:29] kadams54: http://bazaar.launchpad.net/~juju-gui/juju-quickstart/trunk/view/head:/HACKING.rst [18:29] OK, will take a look [18:30] rick_h_: no. this QA should be done via our install providers, i.e. pip, apt, brew (except not brew) [18:30] i made that up. should've said 'our many and varied package management systems' [18:31] bac: ah ok, so your branch is up then on pypi as the b1 package and use that to test? [18:31] hatch: I also have https://github.com/juju/juju-gui/pull/375 for you to look over [18:31] rick_h_: yes, it is on pypi and the juju-quickstart BETA PPA [18:32] bac: gotcha ok cool then [18:44] kadams54: CI failure looks like some sort of cleanup/race [18:52] jujugui I'm stepping out, will do quickstart qa tonight bac. [18:52] kadams54: thanks for the help with the research today. [18:52] rick_h_ np [18:53] rick_h_: ok. have fun. [18:57] kadams54 thanks for the qa - any review notes? [19:00] hmm github must be having some issues or something [19:00] my profile pictire is gone now too [19:00] wth [19:04] Makyo's and huw's are gone too [19:04] odd [19:07] annnd my tests aren't running [19:10] jujugui does anyone know why CI wouldn't run an update to a PR? [19:10] or how I would even go and debug it? [19:14] kadams54 your branch has a test failure, I'll wait until that's resolved to take a look at it [19:15] hatch: I believe that's a race condition [19:15] I haven't had a chance to rebuild but rick_h_ mentioned that earlier [19:15] So ignore it :-) [19:16] no this is different than the spurious failure [19:16] You looking at build #1194? [19:16] 1193 [19:17] https://github.com/juju/juju-gui/pull/375 [19:17] Oo the new lines didn't fix the internet....awesomer! [19:18] 1193 does not seem like a legit failure to me [19:18] ok I'll queue up to re-run it [19:19] I already re-queued [19:19] oh woops we both did heh [19:19] kadams54 if you use /origin/pr/375/merge then it'll do the PR not just the single commit [19:19] just fyi [19:19] Ah, good to know [19:19] so is my branch good to land if it passes the tests? [19:41] oh look at all those failures in IE that my branch caused [19:41] party on [19:44] and they pass locally [19:44] awesomer [19:50] kadams54 your failure happened again [19:50] Yeah, get them to pass in IE and I'm good with it landing. I didn't review it since rick_h_ seemed to have that covered. [19:50] identical [19:50] http://ci.jujugui.org:8080/job/juju-gui/1195/console [19:50] ok cool, thanks [19:50] Yeah, I see it. [19:50] Doesn't mean I understand it or think it's legit :-) [19:51] haha well try and reproduce it locally [19:51] I can give it a go in a bit [19:51] looks like I might have internet again [19:51] All tests pass locally [19:51] ok I'll give it a try in a bit [19:53] and the CI isn't picking up my shipit [19:54] * kadams54 thinks CI needs a good swift kick [19:59] I'm with you there [20:04] hmm I'm on real internet now [20:04] lets see if this lasts lol [20:05] kadams54 when is your EOD? I'd like to get this chat in before, it's looking like they will be done here in about 20 === hatch__ is now known as hatch [20:18] kadams54 ok I'm ready whenever you are [21:13] hatch: you still around? [21:13] of course! [21:14] OK, I'm available to chat [21:16] ok gimme a couple mins to get the dogs in [21:17] woof [21:18] kadams54 ok I'm in the standup room [21:18] OK [21:27] hatch: I wonder if your issue was due to github's issues this afternoon [21:27] github had issues? [21:27] hatch: the CI stuff is pushed via github hooks and if they flake out they no worky [21:27] ohh [21:27] gotcha [21:28] yea, github was down for a chunk of time today. Didn't you see twitter make all the jokes about it? :P [21:28] haha no I was on limited bandwidth so I didn't check it often [21:28] I am now back up to full bw :) [21:28] woot [21:28] wait..now I'll have to see you in hangouts! :P [21:29] haha sucker!! [21:35] hatch: did you get back with huw about his question? [21:35] kadams54 and I are arguing about it now [21:35] hatch: lol [21:35] Well this is neat: https://github.com/dspinellis/unix-history-repo [21:35] hatch: ok [21:35] we are on the same side so this is a shitty argument [21:35] lol [21:35] Never thought I'd see "34 years ago" on github. [21:36] Makyo: is your branch up for landing? I'm trying to take stock of our odds of doing the release this week [21:36] rick_h_, It should be good to land, want me toshipit? [21:36] Makyo: yea, sounds good to me [21:37] hatch: so tomorrow then let's chat about were we stand for IL flag release and make sure we've got everything unblocked to kill that off. We can move the cleanup cards to after the release as maint and do them as thurs/friday cards [21:49] rick_h_ yeah, atm I'm just trying to get the cards in review unblocked and commented on and whatnot - but as far as I know the only real blockers are the two reds after the il green [21:50] I can look more and qa in the morning [21:52] rick_h_ huws branch is landing now [21:53] kadams54 and I couldn't argue with ourselves enough to make us change our mind :D [21:53] Or we just dismissed ourselves as crotchety purists who would never be able to ship something. [21:54] hatch: heh ok I won't ask [21:54] lol!!! [21:55] hatch: the one about the two inspector calls isn't a blocker correct? I mean it did that back before the inspector was moved [21:55] hatch: so the only blocker I consider is the bug with the home action by clicking the icon [21:55] hatch: so I'd suggest that as the next card for someone for tomorrow then? [21:56] rick_h_ I'm ok with that - we can probably release Thursday if we can get some good QA in tomorrow afternoon and Thursday morning [21:58] hatch: I'd like to hopefully start the release process tomorrow if we can. I thin the one bug is a small state change one [21:58] hatch: I'm worried starting thurs will have something push us to friday [21:58] rick_h_ I'm not convinced that there has been enough dedicated QA'ing to do a release tomorrow [21:59] hatch: ok, let's ask huw tonight and have our MV friends pause and help with QA tomorrow [21:59] sounds excellent [21:59] kadams54: ^ [21:59] got it [22:00] kadams54: thanks, so the plan is to pause WIP and QA with no flags tomorrow as much as we can do. Different browsers, live environments, sandbox, etc. [22:00] ok [22:01] if we can get both the quickstart release and gui release out this week I'll be doing a happy dance [22:01] kadams54 +1 btw just doing QA now [22:03] oops qa failure [22:03] rick_h_: Ah that reminds me, I need to look at quickstart tonight. [22:03] hatch: what did you run into? [22:04] kadams54: yea, same here. That'll be after the boy goes to bed though [22:04] kadams54 commented in the PR [22:04] The kids are at the grandparents this week and next, so I have oodles of free time. [22:04] ooooooeeeee [22:05] shouldn't have said that!!! [22:05] lol [22:05] :-) [22:05] The QA error is because I made the change to listen to *:createMachine events at a higher level, where all header events will bubble up [22:06] But I haven't yet implemented adding new containers [22:06] That's my WIP card [22:06] So it'll be addressed in that branch. [22:06] ohh ok, can you reply in kind in the PR [22:06] Yeah [22:06] hatch: sent an email to peeps, if you see huw please mention it [22:06] LOL [22:07] Nice work hatch ;-) [22:07] IT"S BACK OPEN!!!! [22:07] lol [22:08] rick_h_ ok will do thanks [23:02] Morning [23:03] morning huwshimi [23:03] hatch: Hey [23:07] huwshimi some developments today - your branch was landed, and we'd love it if you could do a good qa without any flags so we can get a release out [23:08] hatch: OK, I can do that. This is releasing the il etc? but not mv? [23:09] right, so qa with no flags [23:09] new state and il stuff is not flagged any longer [23:11] OK will do! [23:13] jujugui looking for a review/qa on a super trivial fix https://github.com/juju/juju-gui/pull/376 [23:14] Looking [23:15] thanks [23:18] hatch: looks good, replied in PR. [23:18]