[00:37] gary_poster: Are you around? [00:37] huwshimi, unfortunately :-P [00:37] not for your sake, for the sake of staring at my branch :-) [00:38] :) [01:17] hey hatch, if you are around could you give https://codereview.appspot.com/12306043 a once over? I'm going to ask Francesco to review, land, qa and release the gui his tomorrow morning. then I'll ask benji and curtis to coordinate testing the charm upgrade and the GUI upgrade. [01:42] email sent [01:43] I'm outta here. Bye all. I'll check email occasionally === gary_poster is now known as gary_poster|away [05:31] gary_poster|away: sorry I was out - I'll give it a review now. cya! [10:57] frankban: seen the emails. If there's anything I can help with please let me know. [10:59] rick_h: thank you. I just landed a branch that should fix the service menu bug. I am going to QA now for the release, more QA eyes can help [10:59] frankban: rgr, will pull it down. [11:20] rick_h: everything seems to work here, except for a bug also present in the current release: destroying a service from the service detail view does not work [11:21] frankban: hmm, works here. That's the popup menu when you click on a service? [11:22] frankban: ah, I see, when you click on it in details. My bad [11:22] rick_h: no, double click a service, and then click the destroy button, yes [11:22] yea, the "are you sure" dialog pops up and the immediately closes [11:23] rick_h: exactly, I don't think this is a release blocker [11:24] ok, I'll file a bug for the moment on that then. Looking into the reason right now [11:24] rick_h: cool, please ping me if you think there is a really quick solution for the problem [11:25] frankban: yea, it's showing as -hidden so something in the code is running a .hide(). I'm not familiar with the detail view. Will go with a bug for now if it's not a blocker. [11:25] rick_h: I assume it's not a blocker b/c it's not a new bug [11:26] ah, interesting. I'd agree then. And there's a workaround to destroy from the service icon [11:33] frankban: one line fix [11:34] rick_h: great! [11:34] frankban: http://paste.mitechie.com/show/986/ [11:34] frankban: can you apply please? My trunk is a little messed up due to an accidental commit to trunk and I need to clean it up [11:35] rick_h: sure, thank you [11:38] rick_h: charmbrowser QA seems great to me, could you please confirm? [11:39] frankban: yes, I've not been able to break it. +1 [11:40] rick_h: do you have time to write a quick changelog for this release, so that I can put that in the changes.yaml file? if not, no worries. [11:41] frankban: sec. /me looks [11:41] frankban: should just be able to go through the releasable cards right? [11:42] rick_h: yes, or here: http://bazaar.launchpad.net/~juju-gui/juju-gui/trunk/changes [11:42] frankban: k, working on it [11:42] rick_h: thanks [11:45] frankban: http://paste.mitechie.com/show/987/ I think works going at it a little quickly. Rest of the cards are charmworld or not really 'changelog' items [11:47] rick_h: nice, thanks! [11:57] frankban: how goes the release? [11:58] benji: QA is done. Now starting the release process. I am also running the CI tests, just in case. [11:58] cool [12:16] benji: are you going to work on the iom demo today? i've created cards and reference the google doc. [12:17] bac: I have some availability, but my main priority is upgrading the charm. I should have some time but I don't know for how long. [12:17] I'll help any way I can. [12:18] benji: ok, i didn't know how far you'd gotten on the charm [12:18] it is ready to go; I'm waiting on the release now [12:19] well, my changes are ready to merge, that's what I'm doing now [12:37] * bac loves the yaml. deployer example config had one line missing an indentation space and it went nuts. [12:39] yeah, significant whitespace will never catch on [12:39] hey, that's different! :) [12:40] benji: and the py interpreter gives a better error message than 'expected key missing' [12:40] there is that; I guess every good idea can be done badly [12:55] guihelp: CI tests fail during the charm installation :-/ (make distfile): http://pastebin.ubuntu.com/5939960/ [13:04] guihelp: I assume there is an error in deploying the charm using a branch as juju-gui-source? Should we consider this a release blocker? [13:05] frankban: uhm, no idea [13:06] frankban: I am not aware of that bug (but I haven't tried it recently either) [13:11] abentley: could you have a look at this mp? https://code.launchpad.net/~adeuring/charmworld/1206158-dl-count-by-week-half-year/+merge/178265 [13:11] adeuring: sure. [13:15] adeuring: r=me. [13:16] benji: I am trying to dupe using juju-core. I'll also check if this is a regression introduced after the last stable release. If so, I don't think we should go on, otherwise, I'll proceed with the release. Sounds good? [13:16] frankban: hmm, I just did a fresh checkout/build and didn't hit that. [13:16] rick_h: yeah. Build works locally here too. What nodejs version are you using? [13:16] frankban: 0.10.8 [13:17] frankban: sounds good; note that I merged my changes to juju-gui-charmers trunk within the last hour so it is possible that I caused any problems with those changes (but I don't see how) [13:17] benji: gary_poster's branch yesterday updated a npm file with a bunch of 'mechanical' looking changes [13:17] I wonder if anything in there wasn't good [13:17] abentley: thanks [13:18] benji: CI uses cs:~juju-gui/precise/juju-gui . That's a different charm, right? [13:19] bac, benji: Can we do a hangout on bundles? [13:19] frankban: I don't know exactly how it works, but my understanding is that the juju-gui-charmers trunk is the source for the official gui charm. My understanding is that within 15-20 minutes of landing to trunk the new charm should be in force [13:20] frankban: looking at https://codereview.appspot.com/12306043/patch/1/1004 some of the grunt items were version updated? contextify was updated from 0.1.5 to 0.1.6 [13:20] abentley: sure [13:20] abentley: I'm consumed with release things at the moment [13:20] rick_h: I have v0.10.5 locally. The charm (precise) installs v0.8.23. Perhaps this is relevant? [13:20] frankban: ouch! [13:20] frankban: yea, that's not good if it's that far behind. [13:20] yeah, I guessed so :-/ [13:21] doesn't hacking still require going through a nodejs ppa? [13:21] I would have expected the charm to also pull the sudo add-apt-repository ppa:chris-lea/node.js ppa [13:21] ? [13:22] as it's what we dev against [13:22] sinzui: around? did IS change/frown on this? [13:23] rick_h, that wont work [13:23] rick_h: IS generally want to use only things in the main archive or the precise-cat archive (or whatever series is appropriate). [13:24] frankban: I'm going to guess we've got bigger issues then. I'm not sure how we released before tbh with a 0.8 nodejs [13:24] rick_h, frankban. I think all packages need to be installed in "cat" which is mad available via the exec.d hack [13:24] rick_h: this can be a very old regression [13:24] we need an rt to place a package in cat. [13:25] PS there is 1 webops today. He has 2.5h before EOD. I hope to monopolise him to move charmworld's mongodb [13:26] rick_h: I believe the charm takes npm from https://launchpad.net/~juju-gui-charmers/+archive/stable [13:26] ugh, friday release fail [13:27] s/npm/nodejs/ [13:27] frankban: oh hmm, and that's an old release from that ppa it appears. [13:27] frankban: so yea, I've no idea how this works I guess :/ We're running 2 large versions ahead in dev, just updated the revisions of some deps, and things went boom on production. [13:27] frankban, rick_h, webops make fat charms. they don't deploy the ones we give them. The can update their scripts to pull a branch of need dep, then add it to the charm. [13:28] sinzui: well at this point I'm confused. If we've been running an old version for a known reason for a while then I don't want to suggest updating it [13:28] I'm guessing we're on 0.8 for a reason then? However, it seems devs are all on 0.10 [13:28] yes [13:28] I know hatch has tinkered with nodejs versions so we'll bug him [13:28] ...starting now [13:29] lol [13:29] sinzui, rick_h: I also believe webops deploy from releases. This bug only affects deployment using branches (e.g. juju-gui-source=lp:..). node/npm are only required to create releases from branches. [13:29] frankban, correct [13:29] frankban: ah, that's what you mean by 'old regression' then? Maybe deployment from branches has had issues for a while but only now seeing? [13:30] reading backlog [13:30] rick_h, My branch is lp:~ya-bo-ng/juju-gui/typography-charm-details [13:30] rick_h: exactly, especially considering the functional test in the charm uses a fake branch [13:30] frankban: is g++ installed? [13:30] rick_h, the webops script retrieves the tarball from lp and places it in the charm, [13:30] frankban: k, then I guess it sounds like it's a non-blocker if we can get a release build? [13:31] antdillon: thanks, I'll create a card on the board for it and try to get some eyeballs on it after we get teh release issues worked through . [13:32] rick_h: yes, that's what I am checking with juju-core. Even like that, I am nervous making a release without being able to run the CI tests (and they are broken in canonistack for quite a while) [13:32] rick_h, Awesome thank you! [13:32] frankban: yes, agreed there [13:32] rick_h: g++? is that a new requirement for the charm? [13:32] sorry, hatch ^^^ [13:32] frankban: yes [13:33] I'm not sure why though [13:33] I just know that gary had an issue attempting to deploy when it wasn't installed [13:33] http://nooooooooooooooo.com/ [13:33] lol [13:34] npm dep requiring c-speedups? w..t..f [13:34] there is no mention of g++ in the charm sources, nor in our ppa (https://launchpad.net/~juju-gui-charmers/+archive/stable) [13:35] can't we just add apt-get install g++ ? [13:35] to see if that fixes it? [13:36] I suppose we can [13:36] * rick_h runs and gets more coffee... [13:36] I can't look [13:38] hmm I think this shrinkwrap is busted [13:38] it's changed a ton of versions [13:42] on trunk I can no longer run make [13:42] make: *** No rule to make target `app/assets/javascripts/d3.v2.js', needed by `build-shared/juju-ui/assets/modules.js'. Stop. [13:43] d3.v2 was removed.... [13:45] hatch: make clean [13:45] hatch: we switched to d3 v3 [13:45] yeah... I did a fresh checkout [13:45] hoping that fixes it [13:45] yeah must have had something hanging around [13:46] frankban: is it attempting to build now with g++? [13:47] * benji reboots [13:48] sinzui: staging.jujucharms.com is broken when trying to view a specific charm [13:48] sinzui: can i get login access to staging? [13:48] hatch: right now I am trying to understand what revision introduced this regression. rick_h: this is not an old bug, juju set -e go juju-gui juju-gui-source=lp:juju-gui:897 worked well [13:49] bac, sure. It is just a special nova file to source [13:49] frankban: I'd assume it was gary's branch that changed the shinkwrap.json? [13:49] sinzui: i noticed staging was dead after i pushed my bundle branch. sadly i didn't check it before so i don't know if that is the culprit [13:50] bac. mongo is angry [13:50] OperationFailure: !loc.isNull() [13:50] rick_h: I am testing revision 917. then I will go with 918, which is Gary's branches I merged this morning. [13:50] abentley: seems that the mongodb on staging is badly broken. Try to access any charm deital page... [13:50] File "/home/webops_deploy/charmworld/local/lib/python2.7/site-packages/pymongo/mongo_client.py", line 789, in __check_response_to_last_error [13:50] raise OperationFailure(details["err"]) [13:50] OperationFailure: !loc.isNull() [13:50] frankban: rgr [13:51] "Friday, never hesitate..." [13:51] adeuring: looking. [13:52] frankban: I thought it was "Friday, never again"? [13:52] oh well [13:52] sinzui: adeuring says staging mongodb is badly broken. I am investigating. [13:53] abentley, well that is bad, because I switched it last night [13:53] sinzui: Right. [13:53] and production switched 10 minutes ago [13:53] sinzui: it has a relation error. [13:53] rick_h: 917 fails with the same error. That's not Gary's branch [13:53] * sinzui not see that [13:54] ah, yes I do see that [13:54] * rick_h goes to look at 917 [13:54] * rick_h looks at hatch [13:54] abentley: not sure if you saw my message, but this seems to have happened after i pushed a bundle branch to launchpad. [13:55] abentley: trying to ingest locally i get http://paste.ubuntu.com/5940134/ [13:55] ha-ha, hatch broke the world ;-) [13:55] frankban: ok, so something between 897 and 917? [13:55] rick_h: yes, trying to re-run the config-changed hook after installing g++ [13:55] bac: Weren't we going to test locally before pushing? [13:55] frankban: can you try 915? I wonder if the scss stuff which broke some things is still there [13:56] (sorry hatch, just teasing you :-) ) [13:56] frankban: I wonder if there's more deps than just the scss package still in the npm file that won't work. [13:56] sinzui: well, managae.jujucharms.com does not seem to be affected: http://manage.jujucharms.com/charms/precise/apache2 works,m while http://staging.jujucharms.com/charms/precise/apache2 fails [13:56] abentley: we talked about testing the deployer file against the deployer locally, which i did, but not about ingesting a local file. once it was pushed on LP staging found it. [13:57] adeuring, agreed. the staging errors do not appear until 5 hours ago. We have seen this happen 3 weeks ago [13:57] * sinzui off to present [13:57] bac: I thought getting a working deployer file was my responsibility. [13:57] abentley: if the staging errors happened 5 hours ago then it isn't related [13:58] frankban: let me know if adding g++ fixes [13:58] sinzui: I believe the error is due to a stale charm-- it's running scripts/worker, which was supplanted by ingest-queued. [13:58] abentley: afaik, we never assigned tasks until this morning when i made kanban cards. i sent a message here about it. [13:58] abentley, oh dear. [13:59] orangesquad: per https://docs.google.com/a/canonical.com/document/d/1AoMhTdrominYLBS8iHbZLW_Ji2OH3mNhUzoHjetnD9w/edit , you can see I ran /srv/deploymgr/charmworld restart [14:00] ^ I left a copy of all the commands run [14:01] hatch: sure. rick_h: I'll try 915 later. Anyway, the real bug here is that our devenvs and our production env are really different [14:01] frankban: +1, I'll add a discuss card I guess. [14:01] rick_h: the reason for the shrinkwrap updates is because those modules specify loose deps so when shrinkwrap was re-run it updated those loose versioned deps [14:01] rick_h: yes, please, thanks [14:02] hatch: yea, gotcha. just trying to find something that 'changed' recenly and that's hitting close to home [14:02] only other recent npm change I can think of is the scss work [14:03] well node-gyp requires gcc and g++ on OSX so I'm going to assume that it's also missing on 12.04 [14:03] and for some reason it's exposed itself now... [14:04] so what needs node-gyp [14:04] yea, node-gyp is a native build tool, so something wants to build a native package compiling on the target. Why do we need that now all of a sudden? [14:05] one theory is that it included a bin in contextify@0.1.5 but removed in 0.1.6 [14:05] but that's all I got [14:05] :) [14:05] bac: I have concerns that we may not be adequately filtering out bundles for API 2 that I wanted to discuss before pushing a bundle. [14:06] abentley: shall i delete the branch? [14:06] rick_h: also the reason we are using node sass and not pysass is because the node stuff is automatically hooked up to our watch system [14:06] where the python stuff isn't [14:06] bac: if it's older than 15 minutes, it doesn't matter. [14:07] abentley: let's talk when you get a chance [14:09] grrr, I can't find anything that 'deps' on node-gyp. Just that it's installed globally and deps on npm [14:09] bac: sure. [14:10] hatch: ok, yuea. It's in the contextify build [14:11] cool I was right [14:11] lol [14:11] my hypothesis has now been confirmed [14:11] benji, hatch, rick_h : installing g++ seems to fix the problem, I'll add the dependency in the charmers charm, then I'll merge the charmers charm into our juju-gui charm, and then I'll try CI again... [14:11] * hatch waits for his interviews [14:11] frankban: sorry about my timezone, I could have told you that sooner ;) [14:12] frankban: I'm glad you figured it out. Do be careful with the merge. It is my understanding that the charmers charm is old an disused. [14:12] sinzui: The charm is not stale; the "scripts/ingest" script is broken. [14:12] sinzui: Other methods of ingesting should work. [14:13] hatch: we encountered this problem right before you arrived. We spent the Friday morning fixing other things, so do not excuse yourself for being in Canada [14:13] lol [14:13] hatch: ok, so that's the d3 update [14:13] hatch: d3 requires jsom which requires contextify [14:14] frankban: so it all comes down to our d3 upgrade which was recent and probably broke it [14:15] rick_h: yes, it seems so, double checking with CI [14:15] this is my biggest gripe with node/npm [14:15] hatch: so that would explain why gary ran into the issue [14:15] packages are like the wild friggen west [14:15] where we're going - we don't NEEED stability [14:16] hatch: well, you'd expect that to be in giant letters in a changelog or something for going from 2-3. That's a big req change [14:16] that's what I mean [14:16] authors update deps with no testing [14:16] then claim it works with every version of node by using the > [14:17] npm is awesome - but I think it needs less features to restrict people to do the right thing [14:17] sooooo many packages broke when 0.10 came out simply because they said they worked in >=0.8.x [14:18] everyone fights it though. Even python/pypi just recently stopped serving beta/alpha packages out as the most recent package by default. [14:18] hah, yea when you know that anything > 0.8 would be an api break. It's the point of using big version numbers [14:19] right [14:20] so many people in the community release things using 0.x forever [14:20] things never hit 1.0 release [14:20] I think it's so they don't have to provide a stable product lol [14:21] meh, just ignore the 0. 0.7 to 0.8 to 0.10 == breaks [14:21] benji: charms updated (fix added to charmers, and then merged charmers into juju-gui) [14:21] awesome [14:21] rick_h: rumor has it 0.12 will be 1.0 so we can hope :) [14:22] hatch: fine, then 1.0 to 1.1 will break :P [14:22] frankban: great! let me know when the GUI release is done [14:22] benji: I'll let you know IF the release will be done [14:22] rick_h: nope it's a 1.0 release, no api breaking changes allowed! [14:22] frankban: lol [14:23] be optomistic :) [14:23] heh, I guess that will work too [14:23] optimistic even [14:23] I really need to get an irc client with spell check [14:24] jujugui looking for a second person to help review/qa antdillon's changes https://codereview.appspot.com/12343044 [14:25] rick_h: I'll take a look [14:25] thanks benji [14:25] benji, rick_h Thank you [14:25] sinzui: Could you please review https://code.launchpad.net/~abentley/charmworld/ingest-uses-ingest-queued/+merge/178310 ? [14:26] what's going on with the typography.less file? [14:26] the type class name has no relation to the contents within it [14:26] rick_h, antdillon: I don't see a diff, only "error: old chunk mismatch" [14:26] bac: Let's chat. [14:26] benji: hmm, working for me :/ [14:26] benji, Working for me [14:27] hmm [14:27] abentley, r=me [14:27] benji, This not working? https://codereview.appspot.com/12343044/patch/1/1005 [14:28] rick_h, antdillon: apparently only the side-by-side diffs are broken; the stright-up diffs are fine; I'll look at those [14:29] benji: ah, reitveld fail [14:29] apparently [14:30] rick_h: frankban on my tasklist is to attempt to update our packages and node to be up to date next week (re your card in discuss) [14:30] hatch: yea, but the larger issue is more the diff in dev vs production [14:30] we should have hit this issue when d3 was upgraded, not a week later during a deploy attempt [14:31] oh well prod will then need to be updated as it'll fall over hard :) [14:31] hatch: and it sounds like this g++ issue was hit, but not brought up. [14:32] hatch: cool, thanks [14:33] somehow I ended up working on two branches at once [14:34] abentley: ok, can you set up a hangout? i need to move rooms. [14:36] bac: https://plus.google.com/hangouts/_/b3e9170262ba4b41f761dee440dcbb9ac111cf3d?hl=en-GB [14:48] antdillon: landing your branch. It won't be in the release today, but will be on comingsoon later today. [14:51] guihelp: http://pastebin.ubuntu.com/5940316/ I presume this only means that the unit tests in ie are particularly slow... Please confirm my impression [14:52] rick_h: please don't land GUI branches [14:53] frankban: :/ sorry. Figured it was -r locked. It just completed [14:53] rick_h: no worries. Does antdillon change need to be QA'd? [14:53] frankban: as to the test run, yea it says they passed, there's the skipped. Not sure why it said it can't complete. [14:53] rick_h, Cool thanks [14:54] frankban: no, it was qa'd as part of review. Small css font changes to the browser [14:54] rick_h, antdillon: so it will be included in the release. guihelp: please don't land GUI branches [14:55] frankban: yes we have a number of unit tests which are skipped - they shouldn't be causing it to be incomplete though [14:55] bac: The URL structure is http://manage.jujucharms.com/api/3/bundle/~sinzui/mysql-5/tiny as described here: https://docs.google.com/a/canonical.com/document/d/1H1PH0q9Mr8pSvTmRnEgptrlC-OQZK7i-Le-1SzpJG5Y/edit [14:56] hatch: that can be a problem in CI tests, but it does not block the release. unit tests passed in firefox [14:56] ok great [14:57] I have huw's branch to land so let me know when it's ok :) [14:58] sinzui: r325 and later should not be deployed to production. [14:59] abentley, understood. Since webops are off in 1h and I am away next week. I think we have little opportunity to shoot ourselves in the foot [15:03] sinzui: Tarmac is no longer setting the revno of charmworld after landing. The value is currently -1. Suspect it's related to the lcy02 changes. diogo isn't around. [15:03] call today? Maybe it is at 11 since we'll not be doing a retrospective since Gary is out. [15:03] benji: I was thinking at 10 [15:03] in 1h [15:03] just the standup [15:04] the retro was yesterday [15:04] :) [15:04] cool, 11 it is ;P [15:04] haha [15:04] damn it abentley. I swear that lazy service goes on holiday every time Diogo takes off work [15:05] abentley, surely tarmac needs it ssh config changed [15:05] sinzui: Yes, I expect that's the problem. [15:09] rick_h: do you use vim in multiple terminal panels (using tmux or the like) or use some vim pane manager? [15:10] hatch: I use a tiling window manager + vim [15:10] tmux and such is just gravy and kept seperate [15:10] hatch: vim comes with 'pane managers' called splits. http://lococast.net/archives/111 [15:10] and buffers really [15:11] we do charm schools with both vim and tmux splits [15:12] right now I work in tmux splits but each window is it's own terminal so I always forget to add my ssh key or osmething to one [15:12] which just irritates me heh [15:12] so that's why I was wondering :) [15:12] hatch: use an ssh-agent [15:12] hatch: then you init your ssh key on boot and never worry about it again [15:12] there is some wakoness to osx > ubuntu sshing [15:13] I have to run `exec ssh-agent bash` every time [15:13] http://fromanegg.com/post/45733384142/nfs-between-ubuntu-vm-and-osx-host [15:13] https://help.github.com/articles/working-with-ssh-key-passphrases says that on OSX they can be saved in the keychain [15:14] it's not the passphrase [15:14] it's that the env variables for ssh-agent don't exist [15:14] I haven't spent the time to track that down [15:14] but I'd need to run some auto commands from tmux to fix [15:14] or something [15:14] bac: I've done everything I can do and am in a holding pattern at the moment; is there anything I can do for you? [15:15] jujugui lf one review of https://codereview.appspot.com/12320044/ re-propose of huws branch with minor change [15:15] hatch: on it [15:15] benji: quick chat? [15:15] thanks benji [15:15] bac: sure [15:15] guichat? [15:21] frankban: can I merge into trunk yet? [15:21] hatch: no [15:21] ccccmmmmoooooooonnnnnnn [15:22] ;) [15:22] guihelp, please do not land GUI branches, I'll ping you later [15:23] frankban: is there anything I can help with? [15:24] hatch: not at the moment, thanks [15:25] alright well let me know if you run into something that needs another set of hands [15:33] guihelp: juju-gui 0.8.2 released \o/ Please feel free to restart landing branches. I'll live test it with juju-core. [15:34] yay [15:34] thanks a lot frankban you rock! [15:34] benji: release work done [15:34] jujugui - submitting branch [15:34] frankban: yay! thanks for bearing through all that [15:35] sinzui: so is there a chance of a jujucharms deploy or it sounds like nadda IS help available? [15:35] thank you for the help [15:35] frankban: great! I'll proceed with my work now. [15:35] rick_h, slim chance. .5 hours left [15:36] benji: ^ [15:36] in case that effects your work on the next step [15:36] sinzui: .5 hours left until what? [15:36] No webops [15:37] arg! [15:37] I'll see what I can do quickly [15:37] (without making things worse) [15:37] frankban: what is the release's version number? [15:37] I did 0.8.2 in the changelog [15:38] awesome, I was hoping it wasn't 0.9.0 :) [15:38] benji: 0.8.2 [15:38] that doesn't sound right, but we can argue about that when we have more time ;) [15:38] thanks [15:38] hatch: inspector should be 0.9 imo :) [15:40] yeah! [15:40] reliable CI should be 0.9 imho ;-) [15:40] lol!! [15:40] rick_h: I was also thinking a double bump to 0.10 ;) [15:40] haha [15:40] frankban: hah! what is that? [15:40] heh [15:41] sinzui: we are go for upgrade [15:42] benji, 0.8.2? [15:42] sinzui: yep [15:42] jujugui branch landed - anyone else is free to submit [15:51] jujugui guichat in 10 [15:51] kanban it up! [15:51] the anticipation grows [15:51] just wait [15:51] it'll be huge! [15:58] jujugui guichat in 2 [16:09] jujugui 0.8.2 is deployed [16:09] yay! [16:09] sinzui: rock on! [16:13] benji: http://hg.python.org/peps/rev/82e24ac40255 [16:13] * benji looks [16:13] rick_h: you can probably hold off on reviewing bcsaller's branch [16:13] hatch: ok [16:13] there is a QA failure [16:13] ha, great :( [16:13] hatch: ok, will ignore then. bcsaller ping when you're ready [16:14] * rick_h is just happy he finds the qa stuff in other people's branches too :P [16:14] haha [16:16] bcsaller: review and qa done - I'm guessing there is a merge issue from trunk or something [16:16] hatch: I can merge trunk and test it local [16:26] bcsaller: were you able to reproduce? [16:26] hatch: no, I have settings, thats working fine. The new branch throws the styles off though so the placement of the indicators is wrong now, cleaning that up [16:27] hmm [16:27] hatch: I did have to take trunks version of viewlet-manager.handlebars in the merge though [16:27] does bzr status show a conflict for you? [16:28] cleaned it out and trying again [16:32] rick_h: I'm still not happy with docstrings being 72 characters, but those changes dull most of the pain :) [16:33] benji: yea, I've not done that one myself. I don't think the pep8 tool complains [16:33] benji: but yea, I like that it's less of "pep8 encourages longer lines" and more "pep8 lets you be stupid if you want to be, but don't expect us to use it that way" [16:34] bcsaller: ok it all qa's fine now....sorry I must have broken something somehow [16:34] although the styling on the settings panel is a little broken for some reason [16:34] hatch: yeah, thats what I'm fixing now, thats a merge conflict [16:34]