[00:11] gary_poster|away: yep, the idea crossed my mind setting up the azure stuff today. Could just be like charmworld staging but on the azure setup [06:15] hatch: around? [06:25] hatch: replied to your email, updated pull request to #33. Sorry for the trouble. Will look into it, but should unblock and be able to move forward while getting the patterns/workflow straight. [09:09] hatch, you around? [09:10] or any gui guys in fact? [09:11] I'm in the process of changing ServiceDeploy not to upload charm store charms [09:12] there will be a dedicated AddCharm API call that will do that and needs to be called before ServiceDeploy [09:12] this is just a heads up, nothing changed yet [09:15] i'll send a mail as wel [11:45] thanks for the heads up and appreciate the email dimitern [11:45] sorry I didn't include you rick_h__ , I'll forward it [11:46] dimitern: all, all good. I was just trying to let you know we're listening. Most of us are later time zones so it's an empty space time of day to catch us in irc :) [11:47] rick_h__, cheers === gary_poster|away is now known as gary_poster [13:11] dimitern, hi. ack. sounds dangerous for backwards compatibility, though fine otherwise. I'll look for the email and reply. When you get a chance, I'd also like a reply from you to the thread with the subject "Proposed juju core feature: serve arbitrary charm contents, or only icon" [13:12] gary_poster, hi, so about the GET functionality of the API server to fetch a file from within the charm [13:12] yeah [13:12] gary_poster, I think we decided you guys can do it? [13:13] dimitern, yes, but the discussion is about the spelling and approach, I think. [13:13] gary_poster, ah, ok, will take a look one more time [13:13] cool thanks [13:17] gary_poster, I couldn't see any specific naming suggestions [13:18] gary_poster, but I seem to recall from previous discussions we thought of something like GET /charms?url= [13:18] and what would that return? [13:18] and/or where could I read about that, or who would know more :-) [13:18] gary_poster, perhaps we can add a &file=icon.svg (or any path relative to the root of the charm) [13:19] gary_poster, well, if you need both the full charm and a specific file from it [13:19] dimitern, all we need are two things [13:19] (1) specific file [13:19] gary_poster, if no &file= is given, it'll return an application/zip body with the binary archive of the charm [13:19] (2) ls-style functionality [13:19] gary_poster, ah [13:20] gary_poster, so for (1), both url= and file= should be given and it can return the content in the response body, with the corresponding Content-Type set [13:21] where url is, e.g., "cs:precise/juju-gui"? [13:21] gary_poster, and for (2) I guess we can have url= and &list perhaps? returning something you can display [13:21] gary_poster, yes [13:21] gary_poster, no, actually, it has to have a revision as well [13:21] dimitern, I think it would be nicer if this were paths [13:21] gary_poster, so cs:precise/juju-gui-42 [13:22] GET /charms/cs/precise/juju-gui/42/icon.svg [13:22] GET /charms/cs/precise/juju-gui/42/ (returns ls for that dir) [13:22] GET /charms/cs/precise/juju-gui/42/hooks/start [13:22] GET /charms/cs/precise/juju-gui/42/hooks/ (returns ls for that dir) [13:23] with ContentType specifying json [13:23] gary_poster, so how about a json-encoded response in the form of {Files: [{Path: "rel-path-inside-charm"}, {Path: ...}]} [13:23] gary_poster, hmm [13:23] gary_poster, that might be a bit more difficult [13:23] oh, too bad [13:24] prettier in the abstract IMO, but practicality is important :-) [13:24] gary_poster, what's wrong with GET /charms?url=cs:precise/juju-gui-42&file=icon.svg ? [13:24] gary_poster, no conversions between charm urls and paths [13:25] IMO that is a path [13:25] you are dividing up the path into a query string [13:25] when in reality there's a single resource you want [13:25] gary_poster, it can be a path, if properly escaped, but it really isn't [13:25] which is great for a ptha [13:25] how not? a path identifies a resource [13:26] gary_poster, charm urls are more like urls than file names/paths [13:26] gary_poster, they have a schema for example [13:28] gary_poster, to do what you propose the server-side handler has to be able to handle /charms/ and anything below it and convert that to a charm URL, then validate it, and most importantly not allow arbitrary other paths, like /charms/something/or/other [13:28] dimitern, that's exactly true for the other spelling. I think we simply disagree on the fact that one maps cleanly to the other, and that a path is preferable to a query string for identifying a resource, when possible. [13:29] dimitern, how would you suggest I proceed? [13:30] gary_poster, well, it's ultimately up to who implements it [13:30] dimitern, is not. ;-) [13:30] gary_poster, I don't really strongly object towards having a bit weird urls that look like paths [13:30] heh [13:31] gary_poster, inside state/apiserver/charms.go is the place to start basically [13:32] gary_poster, there's the POST handler, a similar one needs to be implemented for GET and the I can see 2 less-than-trivial bits in its implementation [13:33] gary_poster, the proper url parsing and the actual fetching and extracting what's needed (either not a big deal) [13:35] dimitern, cool. So here's my takeaway from our conversation. (1) broadly, you like the idea of adding a GET to somewhat mirror the POST. (2) no-one needs the ability to download a zip, so we should not implement it right now. (3) We should discuss the spelling a bit more with you and WIlliam over email and see where it goes. (4) technical details above (doesn't sound too bad; thank you) [13:37] dimitern, is there already an API that says "show me all the charms you currently have"? [13:37] gary_poster, no [13:37] dimitern, that sounds like another one we'd need then [13:37] dimitern, any technical challanges there? [13:38] gary_poster, re (2) above, we might eventually need the ability to get charms from the API server as the single normative source of all charms in the environment, but we don't need it right away [13:39] dimitern, ah ok. so we'd want to make sure the spelling supports it, even if we don't implement it yet [13:39] gary_poster, it depends on what do you mean by "all charms" ? - just the URLs currently in state and the environment or more? [13:40] gary_poster, yeah, and that's a point against using "canonical" urls/paths - how can you distinguish between "list me the files" and "get me the charm" ? [13:40] dimitern, good question. contenttype would be my first answer. [13:40] gary_poster, using a trickery like "no slash => get the charm", "with trailing slash => list the files" seems horrible :) [13:40] gary_poster, you mean Accepts ? [13:40] application/zip: get the charm [13:41] json: get the metadata [13:41] yeah [13:41] gary_poster, that's possible i guess [13:41] * dimitern sorry, brb [13:43] dimitern, np. when you return, "all charms": our only real interest right now is local charms. we want to know what non-charm-store (local) charms are available to deploy. [13:43] in the future there's lots of other possibilities [13:44] such as the environment replacing charm store and charm world as a source of truth [13:44] for the GUI [13:44] but that's not where we are right now [13:45] gary_poster, back [13:45] cool [13:46] gary_poster, so we can have a call like ListCharmURLs(schema string) []string -> json returning all charm URLs with a given schema [13:46] sounds perfect dimitern, yeah [13:47] I assume that would be pretty easy? [13:47] (for us to do) [13:47] (in GUI :-) ) [13:47] gary_poster, and re Accepts, etc. above, i'd still prefer to have a ?list or something as part of the url to mean "get me the file list" otherwise, we'll get the zip [13:48] gary_poster, it'll need a state call to list them all and a couple of server/client API methods, but doesn't look hard [13:48] ok cool [13:48] gary_poster, using ?list as part of the url we make the urls idempotent, which is important for a rest api imho [13:50] dimitern, re preferring list over Accepts: ack. May I treat you as my technical contact for this, officially approving and blessing designs, or do I need to include William? [13:50] dimitern, don't see how the Accepts approach hinders idempotence. What do you mean? [13:51] gary_poster, by all means, include william as well :) [13:51] ok :-) [13:52] gary_poster, i mean /charms/cs/precise/juju-gui/42/ as an URL means different things depending on headers, which apart from the authentication code shouldn't have to happen [13:53] dimitern, that's pretty common AFAIK. Might be wrong there, and happy to do some research (and maybe come up with a solution better than one off-the-cuff :-) ), but it doesn't affect idempotence in the slightest, yeah? [13:55] gary_poster, well, for me returning different response bodies for the same URL seems a violation of idempotence, but maybe it's just me :) [13:58] dimitern, the calls don't mutate state, and always return the same value for path plus content type. Idempotent, open and shut, afaik, but I'm leaving it. ;-) I'll document these two approaches and see if I can come up with any other good ideas with the GUI team and then send them to you and William. [14:00] thank you for the discussion and help dimitern! Really appreciate it. [14:00] gary_poster, great, thanks for the discussion! [14:18] rick_h__ wow you were up late :) [14:19] hatch: meh, drugs made me crash in the evening and ended up getting up for a bit [14:19] hatch: still trying to kick the last of this crud :/ [14:19] I hear ya, thanks for the fix [14:25] last night I found out that python-selenium pkg is not available on 12.04 [14:25] is this something we should add to the hacking docs? [14:26] it's in the archive in the tree [14:26] so you don't get it from apt [14:26] ohh, well the hacking docs say otherwise :) [14:26] * rick_h__ knows because he's just updated to .39 in his current branch [14:27] also python-yaml is already installed so we can remove that from the list [14:28] that depends on the system? [14:28] I THINK it is installed with juju [14:28] email, email, email, email...email, email, email, email...come on, everybody can sing it! :-) [14:28] rick_h__: let me know when you have time to pair on the bundle indexing issue [14:28] I basically went through the hacking docs from top to bottom [14:28] hatch: which you don't have to have to dev on the gui [14:28] benji: rgr, few minutes. [14:28] python-yaml would be installed with old juju but not juju-core I think [14:29] I also didn't add the gophers/go ppa [14:30] I'd also propose we remove the sudo from the npm -g install and instead add instructions on chowning the proper dir's [14:30] I of course would be more than happy to modify the doc :) [14:30] +1 on principle [14:37] gary_poster is there anything specific you'd like me to do now? [14:38] hatch, is "Get rid of full browser mode" done? Green card is still there, but I know that is pretty far along, if not done [14:38] gary_poster I left the green card there until the charm flag is removed [14:38] other than that it's all gone [14:39] I think the total result was a -1600ln diff :) [14:39] it's like rick_h__ didn't do anything for a month or so lol [14:39] now* [14:39] hatch: careful buddy [14:40] hatch: a lot of that was working around tools I was given by a certain member of the team :P [14:40] hahaha [14:40] maybe I could work on getting rid of double dispatch [14:41] hatch, oh cool and yay. Options: (1) get rid of pre-inspector code. (2) consider getting rid of namespace routing. (3) display unit errors on relation tab (that's not done, right?) (4) get rid of double dispatch (5) inspector unit destroy story: add “X units being destroyed” section [14:41] hatch: I'm not going to get to the search results thing with show/hide the sidebar for a while [14:41] hatch: and there's the bugs around fixing the quick search UX [14:42] gary_poster 3) the aggregate unit status is shown on the relations tab. 5) it shows them in the 'dying' category (at least it did, does it not any longer?) [14:42] we agreed those quick search bugs were lower in priority than the others I mentioned, I think, though could be wrong. [14:42] gary_poster: yea sorry, typing while you're typing [14:43] trying to keep hatch from deleting more crap I've done :P [14:43] lol [14:43] lol [14:43] gary_poster I'll run through the code for 1) [14:43] hatch, (3) great. (5) I believe it does, but luca's design includes what I described in addition [14:43] hatch, wait, (3) [14:44] waiting [14:44] hatch: that's supposed to show all units with errors as well--not just the aggregate. that's what #3 is [14:44] sorry, you can still do #1--that's my pref, actually--but wanted to clarify #3 :-) [14:44] ohh, do we have a design for that? I dont' think I've seen anything along those lines before [14:45] ok will do 1 until we clarify 3 [14:45] yeah, lemme go to the folder [14:46] benji: going to get a drink and then can chat. Let me know how you want to connect. hangout/rtc/etc [14:46] rick_h__: cool; I'll make a hangout [14:47] hatch, go to https://drive.google.com/a/canonical.com/?tab=co#folders/0B7XG_QBXNwY1cWQ4TmRmRXJBc0E , click on "Inspector," and see seventh inspector image from left [14:48] ohh right [14:48] #5 is on far right, hatch [14:49] I think #5 is as simple as changing a few css classes and whatnot when the status is dying [14:49] right now it's under the 'pending' styles [14:49] well, plus the message at the top, yeah? also trivial, but another item [14:50] yes yes, ok I'll create cards for these [14:50] benji: rgr [14:50] thanks hatch. those are in the spreadsheet, fwiw, I've only been transferring things when I thought we'd actually get to them ;-) [14:51] haha, well I have 3 more days [14:51] so I'll start knocking them off as best I can [14:51] benji: BradCrittenden the ingest queue's on mjc are huge? queued charms: 8992, queued baskets: 353. [14:52] rick_h__: pfft! that's not huge, call me when it gets to 1 million (I'm not kidding) :) [14:52] :/ [14:52] the ingest might have died again [14:52] it's a cron job, did it get removed? [14:52] I thought it was under suporvisord. IIRC, last time supervisord decided it had failed one too many times and stopped running it [14:53] rick_h__: https://plus.google.com/hangouts/_/72cpj9hm6qk6ajmdqd78d81lrc?hl=en [15:23] jujugui small review please for saucelabs ci timeout joys https://github.com/juju/juju-gui/pull/34 [15:27] rick_h__, +1 [15:28] in typical Sublime Text fashion, 6 months have passed so there is an update, *see you in 6 months* [15:28] :P [15:28] hatch if you follow the dev releases it's a bit more exciting :-) [15:28] not a *lot* more exciting [15:28] but a bit [15:29] haha colour me skeptical :P [15:29] about what? [15:29] that anything will change after ST3's release [15:29] it'll probably stall again [15:30] oh [15:30] maybe [15:30] dev releases have been happening once every 1.5 months or so, not counting bug fixes [15:31] yeah that's what ST2 was like too [15:31] I have little faith :) [15:31] could be vim releases... "Oh hey, a new vim release. I didn't think they were still working on that." [15:32] heh [15:32] rick_h__ haha right but they aren't selling vim :D [15:32] it's more of a "wtf more could they possibly add to it?" [15:32] sane defaults? [15:32] ooooo zing! [15:32] test failure: sadness, rick_h__ :-/ [15:32] don't get me started "I bought a new laptop and nothing works" boy :P [15:33] oh looks...unrelated to the timeout [15:33] gary_poster: ah, I missed adding the makefile update to the new version of the file [15:33] rick_h__ lol! [15:34] oh ok cool [15:34] rick_h__, why did pr test work then? [15:34] gary_poster: it's not make cleaning atm but the -merge one is [15:34] ah, gotcha [15:34] gary_poster: wanted to see how it worked on -merge since it's the more careful one [15:35] gotcha [15:35] so good job -merge job! caught it [15:35] heh [15:41] oh bah, why can't I get all cards done at once [15:42] rick_h__ sounds like you need to goroutine your brain [15:42] having fragile ci is almost worse than no ci [15:43] and man it's getting cold again, to the fireplace! [15:43] fragile almost worse than no: yup [15:45] guihelp: I need two reviews + QA for https://codereview.appspot.com/43860044 (quickstart Environment list/selection view). Anyone available? thank you! [15:45] rick_h__ you should buy a toque :) [15:45] I will [15:45] review [15:46] gary_poster: thanks [15:46] welcome :-) [15:46] hatch: :P I did just scratch my pebble badly dealing with the fireplace the other day [15:46] frankban: looking [15:46] rick_h__: thank you [15:47] namedtuples ftw! :) [15:47] * rick_h__ <3's them [15:48] :-) [15:50] jujugui call in 10 [15:51] one of the very odd things about this MBP is it has no-friggen-idea how much time is left on the battery [15:52] the 'time to empty' will vary by hours over the course of just minutes [15:52] hatch in os x or ubuntu? [15:52] have found ubuntu to have no idea [15:52] osx [15:52] ubuntu has it down [15:52] but is x to be reasonable [15:52] huh [15:53] I know right? haha, my experience was similar to yours on my other machine [15:53] :-) [15:56] for example 3 minutes ago I had 9:05H left on the battery, and now I have 3:50 [15:57] quit playing games on it :P [15:57] :-( that sounds its worth taking it to the apple store [15:57] it's [15:57] Ubuntu says 4.9H which makes sense [15:57] because there is 85% left [15:58] jujugui call in 2 [16:29] BOOM http://www.youtube.com/watch?v=1cOT4T2jDho ! RABBIT! [16:29] http://www.amazon.com/s/ref=nb_sb_noss_1?url=search-alias%3Daps&field-keywords=little%20bunny%20foo%20foo&sprefix=little+bun%2Caps&rh=i%3Aaps%2Ck%3Alittle%20bunny%20foo%20foo [16:29] hatch, um, sorry, but http://en.wikipedia.org/wiki/Little_Rabbit_Foo_Foo redirects to http://en.wikipedia.org/wiki/Little_Bunny_Foo_Foo [16:29] open and shut, man [16:29] wikipedia smack down [16:30] I dont' think so, this is clearly a video and a song which says Rabbit [16:30] and with almost 500,000 views! [16:30] *couugh* made by a canuck *cough* [16:30] lol [16:30] hahaha [16:30] actually Michael Rosen is British [16:31] ok fine, your kind then [16:31] king [16:31] lol [16:31] thats a very odd cultural difference haha [16:32] I'm tired, medicated, and you keep killing my work. Are you expecting better? :P [16:32] haha [16:32] and damn it Dell, a monitor doesn't need to be 'in production' for 3 days. Either you've got it in a box or you don't. *grumble* [16:33] uh oh [16:33] you bought the 4k didn't you? [16:34] ummm, maybe...want to buy a HD 21.5" on a monitor arm? [16:34] heh [16:34] * gary_poster jealous [16:35] my old Dell 27" flakes out now and then and is pixel-y but haven't felt the need to spend the $$ [16:35] haha nice [16:35] I would like some monitor arms for my monitors [16:35] but I have too many monitors sitting around to buy more [16:36] <3 monitor arms. Helps with a large desk surface since you can bring the monitor closer [16:36] yeah for sure [16:36] and for aligning nicely [16:36] I need to find a cheapish one for my 31" though [16:36] but the ones I have aren't meant for a 24" display [16:36] the monitor is very heavy and so the arms are very expensive :( [16:37] remember it's the weight withuot the base on it [16:37] yeah it's still heavy [16:37] the new one is 20# but only 10# once the base is removed [16:38] let me know what arms you pick [16:38] :) [16:38] http://goo.gl/OnG7mi [16:38] it's on the way [16:39] http://goo.gl/ytQhIw [16:39] is what I have now [16:41] That damn force field on the 49th parallel """Shipping: Currently, item can be shipped only within the U.S.""" [16:41] come on down, we've got snow and cold too [16:41] lol [16:42] rick_h__ so when merging upstream into my local develop branch there was a conflict caused by the rebase I think [16:43] k [16:44] benji: if you look at the staging heartbeat and refresh every few seconds you see the charm queued count go down. === BradCrittenden is now known as bac [16:45] bac: that makes me lean toward the "we can't keep up any more" hypothesis [16:45] benji: if we're just not keeping up, it should increase again *now* :45 and then start going down again [16:45] yep [16:46] benji: yes, when the q cron started it jumped by a few thousand, and now the charm count is slowly decreasing. [16:46] benji: i think we'll also see the bundle count always goes up and never decreases [16:47] Makyo: perhaps ssh-add cannot find the agent because we don't pass the env vars (SSH_AGENT_PID, etc.) when we run call(... ? [16:47] a few thousand? ouch. I didn't think we had that many to ingest still. Wasn't it in the 300's? [16:47] benji: i'm tempted to run dequeue on staging [16:47] so, the next question is "does the count go down continually or does it plateau?" [16:47] rick_h__: but we're queueing charm * up to ten versions [16:48] if it plateaus, then for some reason the ingest job stops processing at some point [16:48] (suggesting it hits some bad data or a bug that stops it from draining the queue as much as it otherwise could) [16:48] benji: well we'd probably just have to watch for a 15 minute cycle [16:48] frankban, I thought so too, but it can if we run our own agent, so I'm not sure. Running it manually in ipython always gives me rc 2 even if I start an agent manually before starting ipython. [16:49] benji, rick_h__: we may just be bumping against the design issues that curtis mentioned a few weeks ago wrt the way we handle versions and overloading [16:49] I'll keep investigating, though [16:57] benji: so the number of bundles went up from 1056 before the latest queue run to 1078, an increase of 22. [16:57] bac: and the bundle queue length never decreases? [16:58] benji: so assume we really have 22 bundles. 1078 / 22 = exactly 49. [16:58] so 49 runs ago we started seeing a backlog. a little over 12 hours [16:58] if so, that suggests that the ingest is failing in the middle because charms are handled first and then bundles [16:58] it suggests to me that it doesn't mean we're simply too slow [16:59] benji: otherwise the backlog would've happened earlier. does that make sense? [16:59] Makyo: can you link the qa you need please? [16:59] https://codereview.appspot.com/39610049/ [17:00] thanks [17:00] bac: yep that makes sense; in other words, if we were to graph the backlog there is no straight-line slope that would get us back to the last time the queue was empty, implying something happened in the meantime [17:00] benji: basket count just jumped by 22 again to 1100 [17:01] benji: yes [17:01] more elegantly stated, but yes [17:01] so it would seem that ingest is stopping in the middle [17:01] without logging [17:01] unless that beaker exception is relevant [17:03] benji: http://paste.ubuntu.com/6595233/ [17:04] bac: but that exception is in the web app, right? not in the ingest job [17:05] benji: yep. ingest is not creating any logs. grasping here. [17:06] finally working on the new machine....wow this thing is fast [17:07] now I see what rick_h__ works like [17:07] like holy crap it's easily 2x as fast [17:08] frankban, you got two LGTMs :-) [17:09] Makyo: 2 comments: 1) we should catch for KeyboardInterrupt also when keys are not found (create_keys = raw_input...) and 2) if I hit "s" and I create the key, quickstart asks me for a passphrase again, even if the agent is started. Is this ok? [17:10] gary_poster: great, thank you [17:11] frankban, 1) on it. 2) I think so, though maybe we should be clear to the user about which command we're running when the passwords are asked. This might be fixed by further investigation of agents. [17:11] Makyo: +1 [17:22] gary_poster: the return value from the views is what show(view) returns if you hit ^X (as opposed to an explicit AppExit raised from the views). all the env views return (env_db, env_data), the latter being none if no environment has been selected. since each view can be used as an application entry point, even the return value from env_detail can be used. we might want to decide, e.g. that if quickstart is run wi [17:22] th -e we start the app showing the environment details. thoughts? [17:26] * gary_poster looking fwiw [17:27] gary_poster https://bugs.launchpad.net/juju-gui/+bug/1262295 blocking release? [17:27] <_mup_> Bug #1262295: Logging out/in causes canvas help overlay to reappear [17:29] frankban, I guess I don't understand how the return values are consumed by the loop. I assume it will work once we allow edits because we are mutating the (function-local copy of the) env_db dict? [17:32] hatch, if it affects a live environment, blocking. otherwise high. it will not affect jujucharms because we don't have a logout button, so if it doesn't affect a live environment then it only affects dev and comingsoon [17:33] ok I'll fire up a live env and give it a check [17:33] thank you [17:35] yay Saskatchewan http://www.techvibes.com/blog/first-province-to-allow-equity-based-crowdfunding-2013-12-09 [17:35] gary_poster: I think this needs to be changed, we need a more explicit way for views to set a return value for when the user quits with ^X, I'll think about that [17:35] cool thanks frankban [17:38] oh right I have to deploy the new gui the hard way in the charm [17:39] boooo [17:59] hmm I'm having no luck setting this up on lxc using the `NO_BZR=1 BRANCH_IS_GOOD=1 make distfile` technique [17:59] after installing make and node/npm imagemagik won't run [18:00] does that not work on lxc? ec2 only? [18:05] NO_BZR=1 should no longer be necessary. Note that you do this *on your dev box* [18:05] is that what you are doing? [18:06] 'Cause I don't quite understand your lxc/ec2 questions yet [18:07] hatch: let me know if you want to hangout and walk through it [18:09] hatch: I don't recall if we get a loading xv file right now since we don't yet have a tag. So might need to rename that file to be picked up during the make deploy in the charm [18:09] I'm doing it in the lxc juju-gui instance [18:10] hatch: and you can or cannot generate a xv file? [18:10] rick_h__ hangout? [18:10] hatch: rgr [18:11] https://plus.google.com/hangouts/_/7acpj4qna7ell1e9ovto0fmj8g?hl=en [18:38] new git alias `cf = "grep -n --color"` :) [18:38] alias grep = "grep -n --color" :P [18:38] pretty sure you can alias over itself [18:40] negative [18:40] tried that already heh [18:40] Makyo: comments inbound. I got picky on the UX, let me know if it's more than you were looking for or anything is confusing/etc [18:40] rick_h__, cheers, that's fine. [18:45] https://bugs.launchpad.net/juju-gui/+bug/1262315 [18:45] <_mup_> Bug #1262315: inspector charm details breakout maxes at the max height of the inspector [18:50] argh. worked through lunch again. :-( [18:51] oh crap so did I [18:51] haha [18:51] heh [19:10] benji: we seem to have rallied. charm queue down to ~10K from 24K two hours ago [19:10] heh [19:10] bundles still growing [19:10] benji: did you get a chance to look at the logging config? [19:11] bac: nope, I lunched too and then went back to the missing bundle issue [19:11] do you want to pair on this? [19:11] benji: yes [19:11] benji: give me 5 minutes? [19:11] Sure. I bet today's hangout is still up. [19:18] benji: yep and i'm in there [19:18] on my way [19:52] gary_poster test-prod is 20s so not much faster than your desktop :) [19:52] hatch, that's awesome :-) [19:52] that is only single core though, I have 4(8)....clearly there is room for improvement :P [19:53] :-) [20:06] rick_h__ hey so my develop fork is totally borked, the pr of my recent branch shows like 30 commits when there was only one...can I delete my current fork, create a new one then cherry pick the commit to apply to the new branch? [20:07] yeah rick_h__ my local repo is hosed. was going to ask you to help me work through it, but been busy with other things, and still want lunch :-P [20:09] * gary_poster lunches [20:17]