[00:17] <tgm4883> KungFuJesus, yep
[00:47] <KungFuJesus> :(
[01:49] <edbian> I'm thinking of setting up a PVR (using mythbuntu).  How powerful of a system do I need?
[02:15] <rhpot1991> edbian: depends on your goals
[02:15] <rhpot1991> HD or SD?
[02:16] <rhpot1991> !developer%
[02:16] <Zinn> Sorry I don't know about developer%
[02:17] <rhpot1991> we have a page on the site with all the developer's hardware, but the site is down :(
[02:17] <rhpot1991> my hardware is here: http://baablogic.net/drupal/node/13
[02:17] <Zinn> [baablogic.net] My MythTV Setup | www.baablogic.net
[02:18] <rhpot1991> edbian: really all depends on how powerful you want to go, you could get away with an average desktop and something that can run VDPAU and continue to expand later
[02:18] <rhpot1991> !VDPAU
[02:18] <Zinn> http://www.mythtv.org/wiki/VDPAU
[02:18] <rhpot1991> a common setup anymore is a backend out of site and a nice ION box sitting under your TV as a frontend
[02:18] <rhpot1991> !frontend
[02:18] <Zinn> Ion Boxes make a great frontend.  http://www.baablogic.net/drupal/node/2
[02:18] <rhpot1991> have a look, yell if you have any questions, I'll be awol walking the dogs for a few minutes
[06:32] <PMantis> Is there a site I should use to choose the best playback profile? I have this in my frontend:  NV44 [GeForce 6200 TurboCache(TM)]
[06:34] <fluvvell> you could start with the profile that is selected by default and see how it goes
[06:35] <PMantis> That was "Normal". I changed it to CPU++. Things are OK, but I don't know what kind of atrifacts or blips to attribute to the video card, the CPU, network, backend storage, etc...
[06:36] <PMantis> I install Cacti to monitor the network traffic with SNMP. I think the network is well underutilized, even when playing HD
[06:44] <PMantis> I take it VDPAU is the best to use if it works?
[06:54] <fluvvell> a 6200 would not be stunning performance and not capable of vdpau
[06:55] <PMantis> A few minutes ago, I enabled vdpau and tested playback successfully... must not be using that, 'cause I don't see it on the list for any level of vdpau support.
[07:09] <fluvvell> I think 8500 and above, this machine I'm on is only 7900GT and not capable
[08:45] <wombo> PMantis, I think your VDPAU performance will also depend on the type of video stream being sent through it
[13:41] <wombo> wawwwww
[13:41] <wombo> ignore that
[13:42] <SpaceBass> hey folks
[13:42] <SpaceBass> any mythexport users? I'm looking for settings that work for the AppleTV and/or iPad - IE HD
[13:43] <SpaceBass> currently everything exported shows up as zero K - so somethings not right
[13:58] <SteveGoodey> You might try, http://www.mythbuntu.org/wiki/mythexport-215, you didn't say what distro you're using.
[13:59] <SpaceBass> thanks SteveGoodey know that page well, I'm using ubuntu 10.4
[13:59] <SteveGoodey> No good eh?
[13:59] <SpaceBass> think I found my problem - seems that explicitly setting -ac 2 helps
[14:11] <MoMo> if my sound if very quite ... how would I go about increasing it.  Is it something I need to address at the server?  at the client? or at the client hardware?
[14:15] <SteveGoodey> Have you tried the hardware volume sliders? Also I believe the mythtv-setup has volume settings at about 75 percent as default.
[14:16] <MoMo> yes i tried both of those
[14:16] <MoMo> i didn't know if there was something i should consider in the backend
[14:17] <SteveGoodey> I have only used combined front/backend so can't help there, sorry. New Install/upgrade?
[14:18] <MoMo> new install ... dedicated backend dedicated front end .. over wifi
[14:19] <SteveGoodey> Have you tried sound on the frontend outside of mythtv, xine/VLC mp3 file. Volume low with those?
[14:19] <MoMo> thats a good idea -- no i haven't
[14:20] <MoMo> that would give me a good control i suppose ... thanks
[14:28] <MoMo> I've been watching TV for a little bit, testing this and it's ending with an error: Video frame buffering failed too many times
[14:30] <SteveGoodey> http://ubuntuforums.org/showthread.php?t=1316167
[14:30] <Zinn> [ubuntuforums.org]  Video frame buffering failed too many times - mythbuntu 9.10 - Ubuntu Forums
[14:31] <MoMo> thanks
[14:32] <SteveGoodey> Might be more clues in the logs, "how about the front end/back end log files and dmesg?"
[14:34] <Shred00> i'm noticing that somewhere between 0.23.1+fixes26407-0ubuntu0+mythbuntu2 and 0.23.1+fixes26434-0ubuntu0+mythbuntu2 the cron.daily job got dropped from mythtv-backend.  is this intentional?
[14:36] <rhpot1991> SpaceBass: all good now?
[14:36] <SpaceBass> rhpot1991, think so - thanks for asking! I'm doing an encode right now, will test once it is finished
[14:36] <rhpot1991> Shred00: what did it do, the db optimizer?
[14:37] <Shred00> filldatabase and optimize, yes
[14:37] <rhpot1991> auto mythfilldatabase can be enabled in mythtv-setup
[14:38] <SpaceBass> on to a different questions...
[14:38] <Shred00> rhpot1991: yes, of course.  but if one doesn't want to do it that way.
[14:38] <Shred00> but more importantly, yes, the database optimize
[14:38] <SpaceBass> anyone know how to make a job auto-run for every recording? IE default as on
[14:39] <rhpot1991> SpaceBass: I normally enable it per recordings that I want
[14:39] <rhpot1991> SpaceBass: might want to check the userjob page in mythtv-setup, general > page 10 or so
[14:39] <rhpot1991> there are 2 user job pages, if it exists it should be in there
[14:40] <rhpot1991> could check the recording profiles as well
[14:41] <SpaceBass> thanks! I've not see in it in the setup options, I'll check recording profiles
[14:42] <rhpot1991> Shred00: check the mysql tab in MCC
[14:42] <Shred00> rhpot1991: i don't run MCC here
[14:42] <rhpot1991> Shred00: that is what creates the optimize tables cronjob
[14:43] <Shred00> hrm.  why wouldn't that just be a default thing for any mythtv-database/backend machine to do rather than having to require a user to enable it?
[14:43] <rhpot1991> Shred00: http://pastebin.com/5nefuWBs
[14:43] <rhpot1991> paste that into your /etc/cron.daily
[14:47] <Shred00> rhpot1991: i already have that in /usr/share/doc/mythtv-backend/contrib/maintenance/optimize_mythdb.pl so i'd really only need to add a call to that in my cron.daily.  but my point here is not my particular installation (which i can fix easily) but the bigger picture.  i wonder why it was removed from being the default for all installations to being something that somebody has to enable via the "MCC".
[14:48] <rhpot1991> Shred00: as far as I'm aware it has been that way for quite some time
[14:49] <Shred00> rhpot1991: so my backups seem to reveal also.  i just wonder what the motivation behind the change is.
[14:49] <Shred00> is mythbuntu under an SCM that i could browse for a commit message perhaps?
[14:50] <rhpot1991> Shred00: I'm not aware of it ever being included by default
[14:50] <rhpot1991> yep on launchpad
[14:51] <rhpot1991> https://code.launchpad.net/~mythbuntu/mythtv/mythtv-fixes
[14:51] <Zinn> [code.launchpad.net] mythtv-fixes : Code : MythTV
[14:56] <Shred00> rhpot1991: it must have been in 0.23.1+fixes26407-0ubuntu0+mythbuntu2:
[14:56] <Shred00> ii  mythtv-backend 0.23.1+fixes26407-0ubuntu0+mythbuntu2 A personal video recorder application (server)
[14:56] <Shred00> $ dpkg -S /etc/cron.daily/mythtv-backend
[14:56] <Shred00> mythtv-backend: /etc/cron.daily/mythtv-backend
[14:57] <tgm4883> optimize_mythdb.pl has been enabled in MCC for as long as I can remember
[14:57] <rhpot1991> tgm4883: yep
[14:58] <tgm4883> it was definitly before 0.23.1
[15:01] <rhpot1991> yep, once upon a time I used to enable it by hand, that was before foxbuntu (I think) added it to MCC, which was quite some time ago
[15:02] <Shred00> hrm.  this is strange.  debian/changelog says:
[15:02] <Shred00> mythtv (0.20-svn20070122-0.0ubuntu2) feisty; urgency=low
[15:02] <Shred00> ...
[15:02] <Shred00>   * Removed debian/mythtv-backend.cron.daily; the database fill must
[15:02] <Shred00>     happen from backend scheduler to take advantage of next-run hints.
[15:02] <Shred00> yet my backend, on 0.23.1+fixes26407-0ubuntu0+mythbuntu2 still says /etc/cron.daily/mythtv-backed is coming from the mythtv-backend package
[15:03] <Shred00> $ dpkg -L mythtv-backend | grep daily
[15:03] <Shred00> /etc/cron.daily/mythtv-backend
[15:05] <rhpot1991> Shred00: upgraded install?
[15:05] <Shred00> rhpot1991: sure
[15:06] <rhpot1991> Shred00: I'd venture its left over from the old days
[15:06] <Shred00> rhpot1991: yeah, but the current 0.23.1-fixes package is reporting that file per the above dpkg -L output
[15:06] <rhpot1991> that comment seems to indicate it was removed from code, debian.\/postinst would have to remove it to get it off of your system
[15:06] <rhpot1991> woops debian/postinst
[15:07] <rhpot1991> john@ultramagnus:/etc/cron.daily$ dpkg -L mythtv-backend | grep daily
[15:07] <rhpot1991> john@ultramagnus:/etc/cron.daily$
[15:07] <rhpot1991> nothing for me
[15:08] <Shred00> rhpot1991: indeed.  so why is my installation reporting it?  it's very strange.
[15:08] <rhpot1991> Shred00: left over from a previous install, it will not remove it unless you remove the package, or we explicitly remove it in postinst
[15:09] <rhpot1991> superm1: should this have been done? ^
[15:10] <Shred00> tbh, i have never used MCC on my mythbuntu installations.
[15:10] <Shred00> is MCC an "on-screen" (i.e. on the TV) app?  does it come up before the main mythtv menu or something?
[15:12] <rhpot1991> Shred00: its an X application that should be found under the administration menu
[15:12] <rhpot1991> outside of mythtv
[15:12] <rhpot1991> Shred00: are you running mythbuntu or ubuntu + mythtv?
[15:14] <Shred00> rhpot1991: it was installed as ubuntu a long time ago and then i added the required mythtv packages from mythbuntu and it's been upgraded through about half a dozen ubuntu releases since, so there never was an MCC on it.  never been a need.
[15:14] <Shred00> so if my mythtv installation is a stand-alone "set top box" type installation where it powers on and up to the mythtv screen (like any appliance should) how does MCC fit in?
[15:15] <rhpot1991> Shred00: its pretty much only used in the setup phase
[15:15] <rhpot1991> you use it to setup things like your remote
[15:15] <rhpot1991> and then don't open it anymore
[16:26] <silverdulcet> I'm having an issue with MythExport 2.1.5, on Mythbuntu 10.04 with 23.1 fixes. After starting the userjob, mythtranscode runs the lossless transcode to cut the commercials (i.e. -honorcutlist) and outputs to a .mpg.tmp file, once that completes the job shows as successful even though the ffmpeg portion of the job hasn't completed. The ffmpeg portion runs fine, but since this is a combined frontend/backend I'd like it to shut down
[16:26] <silverdulcet>  after its finished transcoding, with the userjob showing completed it would shut down while ffmpeg is still running.
[16:28] <rhpot1991> silverdulcet: hmmm thats not gonna work too well
[16:28] <rhpot1991> the userjob itself queues up a task for mythexport and then reports as completed
[16:28] <rhpot1991> silverdulcet: do you have another backend?
[16:28] <rhpot1991> or is this the only one?
[16:29] <silverdulcet> silverdulcet: nope, just a single backend.
[16:29] <rhpot1991> why are you shutting it down then, aren't you going to miss recordings?
[16:29] <silverdulcet> rhpot1991: I use mythwelcome and acpi wakeup, it sets the rtc alarm to wakeup 5 min before the next recording.
[16:31] <rhpot1991> silverdulcet: know perl at all?
[16:31] <silverdulcet> rhpot1991: when I'm done using mythtv/queuing a transcode it exits to mythwelcome, then if it isn't recording/transcoding it will shutdown.
[16:31] <silverdulcet> rhpot1991: no...;-(
[16:32] <rhpot1991> so if the userjob remained open until everything was done, that would essentially fix the issue, right?
[16:32] <silverdulcet> rhpot1991: exactly, it must remain open until ffmpeg completes..
[16:32]  * rhpot1991 thinks about it for a little
[16:33] <silverdulcet> rhpot1991: I assumed that was what mythexport did, but I guess its mostly designed for a backend running 24/7?
[16:34] <rhpot1991> silverdulcet: ya I moved most of the code into a daemon so that it could do some of the other features like file maintenance
[16:35] <rhpot1991> so all the userjob really does is makes a mysql entry that the daemon reads
[16:37] <silverdulcet> which points to the name of the job configured in mythexport_settings.cfg
[16:38] <rhpot1991> unfortunately the userjob doesn't know the resulting filename or we could just watch that
[16:39] <rhpot1991> I'm thinking the easiest work around would be to have the userjob touch a file and the daemon delete it, then the userjob would complete once that file is gone
[16:39] <rhpot1991> and in theory the backend should know that it has userjobs queue'd up and not shut down till they are all done
[16:40] <rhpot1991> I'm worried about multiple instances though
[16:41] <rhpot1991> 2 userjobs run, they each create a sql instance, mythexport starts running the first, deletes the file when its done, then starts running the 2nd
[16:41] <rhpot1991> meanwhile the backend sees that both jobs completed and shuts down
[16:42] <silverdulcet> perhaps mythnuv2mkv can give a clue? it assigns a job number to each transcode job queued.
[16:43] <silverdulcet> I would like to still use that, but for some reason after upgrading to mythtv .23 I only get 3fps when doing an xvid transcode where I used to get 20-30. I still get 20fps when doing h264 mkv encodes.
[16:44] <rhpot1991> silverdulcet: well part of the issue is that I can't push any new features into ubuntu until after the maverick release
[16:44] <rhpot1991> so I'd like to give you a chunk of code you can place in your files to fix the issue for now and then tackle it at a later point
[16:46] <rhpot1991> actually I could prob just reuse the id from the sql table and make a unique file which would work out well
[16:46]  * rhpot1991 is thinking out loud, don't mind
[16:46] <silverdulcet> rhpot1991: well I'm willing to test it, until then I think I'll just do mythshutdown -l to lock the system from shutting down while I transcode things.
[16:48] <rhpot1991> silverdulcet: shoot me an email, and I'll get you something to test when I get a chance
[16:48] <rhpot1991> my irc nick @ubuntu.com
[16:49] <rhpot1991> actually make a bug instead please: https://bugs.launchpad.net/ubuntu/+source/mythexport
[16:49] <Zinn> [bugs.launchpad.net] Bugs : âmythexportâ package : Ubuntu
[16:50] <silverdulcet> rhpot1991: ok
[16:53] <silverdulcet> rhpot1991: it looks as if there already is one https://bugs.launchpad.net/ubuntu/+source/mythexport/+bug/596251 shall I add something to that? Its the exact issue I mentioned.
[16:53] <Zinn> [bugs.launchpad.net] Bug #596251 in mythexport (Ubuntu): âmythexport reports start and finish of jobs at the same secondâ
[17:21] <rhpot1991> silverdulcet: thanks
[17:23] <Riddell> superm1: is mythbuntu in good shape to start testing for RC tomorrow?
[17:34] <wombo> Riddell, I have been running the testing releases for a long time with very very few problems.
[17:34] <wombo> But I have not done a fresh install since 10.04; so I cannot comment on any changes to the fresh install changes
[17:35] <Riddell> well it's fresh installs that need tested
[17:36] <wombo> hehe yeah
[18:06] <superm1> Riddell, yes it's looking pretty good imo
[18:06] <superm1> the problems we had at beta should be cleaned up now
[18:06] <Riddell> groovy, thanks superm1
[18:07] <superm1> rhpot1991, it's a conffile, it would only stay if it was hand modified normally
[18:07] <superm1> if we still have that postinst code in place
[18:08] <rhpot1991> superm1: figured so much, also this is the first we've heard about it and thats an old change
[18:10] <superm1> yeah
[20:44] <tgm4883> kees, can I bug you for about 5 minutes for a security question?
[20:48] <kees> tgm4883: sure thing
[20:50] <tgm4883> kees, ok thanks, PM


[01:03] <rick_h_> benji: yea, it'll work.   Thanks huwshimi.  Things looking OK?
[01:50] <huwshimi> gary_poster: Yep, hit something small...
[01:51] <gary_poster> Cool.  We're hoping to make a release early next week so it would be great if we were in good shape
[01:51] <huwshimi> gary_poster: I've only just started, but things look pretty reasonable.
[01:52] <huwshimi> gary_poster: Certainly  looks like the highest level of polish across the board that we've ever had.
[01:57] <gary_poster> Awesome. :-) huwshimi, I'm sorry I didn't call you this evening.  I talked with everyone else this week to ask if they had any post-sprint thoughts and if we ought to consider anything about ye olde yearly goals (https://docs.google.com/a/canonical.com/document/d/1hzcQ40d-z_xC0x62uc7o1uQR16NjIM3itF5XW8MtJkw/edit).  It looks to me like we are doing quite well with your goals.  Would you like to schedule a call on you
[01:57] <gary_poster> r Tuesday morning next week to talk about these things, or is everything ok, or...? :-)
[01:57] <gary_poster> (if everything is ok then we'll just wait till next week)
[02:00] <huwshimi> gary_poster: I think things are going fine. I don't have any questions/concerns about goals, at least not from my end :)
[02:00] <gary_poster> heh, cool huwshimi
[02:00] <gary_poster> ok, have a great weekend and talk to you next week. :-)
[02:00] <huwshimi> gary_poster: Thanks Gary, have a good evening and weekend :)
[02:01] <gary_poster> thanks :-)
[03:08] <marcoceppi> rick_h_: I put charm-tools 1.1.0 on pypi for you ;)
[03:09] <marcoceppi> rick_h_: that being said, 1.1.0 is "released" just waiting for the builders to finish
[03:09] <marcoceppi> how do you guys usually install it? from package or tarbal?
[11:15] <rick_h_> marcoceppi: you rick!
[11:16] <rick_h_> marcoceppi: if it's on pypi we'll pull it downinto a download-cache so we can install it sans internet and such with a lock version
[11:16] <rick_h_> marcoceppi: I think last time we did a custom python package build and stuck it in there, so we just have to update it with the new .tar.gz
[12:05] <gary_poster> rick_h_, "you rick!" ? :-)
[12:05] <rick_h_> gary_poster: lol too early in the morning
[12:05] <gary_poster> :-)
[12:05] <rick_h_> marcoceppi: there's more rocking than 'ricking' in that ^^
[12:05] <rick_h_> at least they keys are next to each other
[12:05] <rick_h_> I wasn't that nuts this morning
[12:10] <gary_poster> hey bac, when you are adding the basket name to search, could you double check that we include bundle charm names as search terms too?  If we don't do that now and it is easy to add that at the same time, please add it; if it is not that easy we can have a separate card.
[12:11] <gary_poster> BradCrittenden, ^^^
[12:11] <rick_h_> bundle charm names? The names of the charms inside the bundle?
[12:12] <gary_poster> rick_h_, yes
[12:24] <BradCrittenden> gary_poster: yeah i'm pretty sure we do that
[12:24] <BradCrittenden> at least we have a test for it
[12:26] <rick_h_> gary_poster: bac yea http://comingsoon.jujucharms.com/sidebar/search/:flags:/charmworldv3/?text=mysql pulls upt he wiki/wordpress bundles
[12:26] <rick_h_> even though the search was for wordpress
[12:26] <rick_h_> err, mysql
[12:26] <gary_poster> bac, rick_h_ awesome, thanks
[12:27] <gary_poster> another card bites the dust ;-)
[12:42] <marcoceppi> rick_h_: YOU RICK AND ROLL!
[12:43] <rick_h_> marcoceppi: hah, tried not to go there
[12:43] <marcoceppi> it is early here
[12:53] <gary_poster> lol
[13:09]  * gary_poster out for a bit
[13:10] <bac> jujugui: one review/qa please of https://codereview.appspot.com/20780043/ -- note QA instructions in follow-on email.
[13:26] <bac> hey rick_h_, any free time to do the above review.  it is for the bug you filed!  :)  (very short too)
[13:26] <rick_h_> bac: yea, just in deep atm.  Later pics show the street just lining up with cars from outside the neighborhood. There's usually NO cars on the street
[14:20] <hatch> do you live outside the city?
[14:20] <rick_h_> no, I live inside a small-ish town
[14:21] <rick_h_> in a sub division
[14:21] <hatch> ohh - I was gona say....driving? lol
[14:22] <hatch> The only time we drove was to get to family and friends who were on the other side of the city
[14:22] <rick_h_> benji: can you do qa on bac's branch please? My virtualenv is all out of date now witht he new deployer stuff I was working on
[14:23] <hatch> could usually get more than enough candy within the neighbourhood
[14:23]  * rick_h_ finds the downside of colo
[14:23] <benji> rick_h_: sure, which branch is it?
[14:23] <rick_h_> benji: lp:~bac/charmworld/bug-1246459
[14:23] <rick_h_> benji: from https://codereview.appspot.com/20780043/
[14:23] <rick_h_> benji: thanks!
[14:23] <benji> np
[14:24] <rick_h_> hatch: yea, we always run out so got $100 of candy this year and went through 3/4 of it. Without the rain I think I would have gotten closer to going through it all
[14:24] <hatch> well with people bussing their kids in no kiddin
[14:24] <hatch> g
[14:25] <hatch> did they at least say 'trick or treat' ?
[14:25] <hatch> or just ring the doorbell
[14:25]  * hatch doesn't give candy to kids who just ring the doorbell
[14:25] <rick_h_> yea, scond year we got a limo, only this time it was a limo bus vs a limo car
[14:25] <rick_h_> yea, most say it, some have to be forced to say it. I ignore kids that come up to me and just hold out their pillow case
[14:25] <hatch> haha yup
[14:25] <hatch> FYI you CAN just do a trick :)
[14:27] <BradCrittenden> hi rick_h_, thanks for the review.  as to the scoring question, i guess they can be reversed.  that just affects the order the results are shown, right?
[14:27] <rick_h_> bac: right
[14:27] <bac> rick_h_: i'll do it then
[14:27] <rick_h_> bac: thanks, I think it'll give better results that way
[14:36] <bac> rick_h_: qa ok?
[14:37] <rick_h_> bac: benji is doing qa. I've updated my colo-virtualenv a bit and makes it hard for me to qa
[14:43] <hatch> the windows 'tile' for the store always says I have updates, but when I open it, nothing....
[14:44] <hatch> it's probably a conspiracy
[14:46]  * rick_h_ shakes fist at "old chunk mismatch"!!!!!!!!!!!
[14:46] <rick_h_> go through all of lbox for a pretty side by side review of my code and get nadda
[14:50] <hatch> rick_h_: well it also gives the rest of us peace of mind knowing that something else has 'reviewed' your code before we have to :P
[14:50] <gary_poster> jujugui call in 10
[14:50] <rick_h_> heh, I like to do that so "I" can review it before I ask everyone else to. -wip ftw
[14:50] <rick_h_> and help me find bits missing tests/etc
[14:51] <hatch> so when I try to do `make test-debug &` it breaks out of the background when the node process hits
[14:52] <hatch> I'm guessing I'm missing something?
[14:58] <gary_poster> jujugui call in 2
[14:58] <bac> ha, the cool ones are already there
[15:08] <benji> jujugui: I have a charmworld branch up for review that adds metrics tracking infrastructure (a model and source): https://codereview.appspot.com/20820043
[15:09] <bac> benji: did you do the qa on my branch?  i'll review yours.
[15:09] <benji> bac: the injest is still running
[15:09] <bac> benji: oh, you didn't change the limit to 10.
[15:10] <benji> bac: I ran the commands you put in the RV; you should have included rm -rf /
[15:10] <bac> oopsie
[15:12] <jcastro> hey gary_poster
[15:12] <jcastro> for mediawiki you basically want me to cat the two files together
[15:12] <jcastro> and call it "mediawiki"
[15:12] <gary_poster> hey jcastro on call
[15:13] <jcastro> but the environment names are like "mediawiki-simple", "mediawiki-scalable" and so on
[15:13]  * jcastro nods
[15:13] <gary_poster> jcastro, can scalable inherit simple?
[15:16] <jcastro> I don't know anything about how inheritance works in bundles
[15:16] <jcastro> I know how to shift-d is about it, heh
[15:27] <benji> arg, the ingest still isn't done; I guess I'll start again with a limit
[15:28] <gary_poster> jcastro, see http://bazaar.launchpad.net/~juju-deployers/juju-deployer/trunk/view/head:/configs/blog.yaml
[15:28] <rick_h_> gary_poster: yea, we ingest with inheritence, but I wasn't aware of it until recently. I'm not sure how that'll proof. That requires pulling in the deployer config stuff I think.
[15:28] <gary_poster> rick_h_, uh-oh
[15:28]  * rick_h_ needs more test cases/examples ugh
[15:29] <gary_poster> rick_h_, could you confer with brad or benji on that?  they know where the inheritance bidies are buried
[15:29] <rick_h_> gary_poster: yea, that's the functionality we used the deployer for before that changed so much I copied it out to move forward.
[15:29] <gary_poster> bodies
[15:29] <rick_h_> gary_poster: yep, will do.
[15:29] <gary_poster> thanks
[15:30] <benji> I would suspect proofing after inheritence would be the way to go.
[15:30] <rick_h_> benji: yea, since this just came up yesterday that's been my take and part of the trail of XXX: but worth a real bug to make sure proof supports inheritence
[15:31] <benji> yeah, the proof tool needs to support inheritence because it will be given those kinds of deployer files to process, we won't have those though, so we should proof what actually gets stored in the DB
[15:31] <rick_h_> so jcastro, forget you heard about inheritence for a few days :)
[15:32] <jcastro> ok so should I keep them seperate for now?
[15:32] <jcastro> I need to version them still though
[15:32] <jcastro> want me to do that now?
[15:33] <rick_h_> version the services?
[15:40] <gary_poster> the charms.  Yes please jcastro.  also, note that we display your branch name and the bundle name in the GUI, so that might affect how you name things
[15:41] <gary_poster> for example
[15:41] <gary_poster> see http://comingsoon.jujucharms.com/sidebar/search/:flags:/charmworldv3/?text=jorge
[15:41] <gary_poster> we could make those names smaller I suspect
[15:41] <jcastro> you mean on the left?
[15:42] <gary_poster> yeah
[15:46] <hatch> jcastro: on Tuesday I'm going to be doing a demo of juju/GUI on my laptop what's a good collection of charms to deploy that will illustrate it's awesomeness the best?
[15:47] <jcastro> hatch, what's the audience?
[15:47] <hatch> http://www.prairiedevcon.com/
[15:47] <hatch> it's a windows slanted conference
[15:47] <hatch> but mostly developers
[15:48] <hatch> I'll be sure to mention that it works on Azure & windows but it's definitely being demo'd on Ubuntu :)
[15:48] <benji> bac: QA looks good; I only got one result for the search "muletrain" (the expected bundle)
[15:49] <jcastro> hatch, dude, do the rails charm on azure
[15:49] <jcastro> that would be epic
[15:49] <bac> benji: cool.
[15:49] <bac> my goal is to now right a proper muletrain bundle.
[15:49] <hatch> I know nothing of azure or rails haha, not sure I want to do that live
[15:50] <jcastro> so do what you know
[15:50] <jcastro> ghost?
[15:50] <jcastro> rick_h_, ok versioned things pushed
[15:51] <jcastro> rick_h_, how can I test the bundle from the store itself
[15:51] <hatch> jcastro: I was thinking of doing it on lxc since it'll be at a conference I'm not sure how reliable the internet will be
[15:51] <hatch> and relying on hotspot probably isn't wise either
[15:51] <jcastro> like If I wanted to deploy what's in the store in 15 minutes
[15:51] <bac> rick_h_: you didn't use the magic LGTM on my review
[15:52] <bac> rick_h_: found here https://codereview.appspot.com/20780043/
[15:52] <bac> it is all sad and ungreen
[15:52] <bac> and rv-submit hates it
[15:52] <jcastro> hatch, have something fired up and GUIed, the show it, then be like "ok, but our internet is flaky, so let's move locally"
[15:53] <jcastro> then juju switch and show the same stack running on LXC.
[15:53] <hatch> oh that's cool
[15:53] <jcastro> yeah
[15:53] <hatch> I could do an apache/wordpress/haproxy/mysql deployment?
[15:54] <rick_h_> bac: because I was waiting for QA to do it
[15:54] <rick_h_> that's benji's job :P
[15:54] <jcastro> and then you say "Same deployment, on my cloud and on my laptop." and go right into rick's spiel on how you guys can fire things up easily and test just like you would on a real deployment
[15:54] <jcastro> if internet is fine just switch back and forth
[15:54] <bac> rick_h_, benji would one of you fine people approve my review?
[15:54] <benji> bac: sure
[15:54] <jcastro> you want to show how you can do the same thing on any substrate
[15:55] <rick_h_> did qa get an ok? oh /me missed his irc omment
[15:55] <benji> bac: done
[15:55] <bac> ty
[15:55] <rick_h_> jcastro: "test the bundle from the store itself"? you mean find it and deploy it on comingsoon?
[15:55] <hatch> jcastro: good idea thanks
[15:55] <rick_h_> jcastro: http://comingsoon.jujucharms.com/:flags:/charmworldv3/ search, hit deploy
[15:57] <jcastro> rick_h_, I mean deployed for real. or do I wait for the gui to land to do that, then deploy on the real thing?
[15:57] <jcastro> rick_h_, I think I'm asking chicken/egg.
[15:57] <jcastro> let's say I want to test the bundles I am submitting
[15:57] <rick_h_> jcastro: you can use the deployer or the quickstart tool from the email that gary_poster sent out yesterday
[15:58] <jcastro> oh dude, the alpha quickstart one, totally missed it, thanks!
[15:58] <gary_poster> rick_h_, jcastro the version in the PPA only supports downloaded files.  URLs are in trunk but not in PPA yet, sorry :-/.  Next week
[15:59] <jcastro> yeah that's fine
[15:59] <gary_poster> downloaded bundle files I mean
[15:59] <gary_poster> cool
[15:59] <rick_h_> gary_poster: right, but jcastro can test his bundle file works locally
[15:59] <jcastro> I just didn't want to only test on deployer
[15:59] <gary_poster> oh, definitely
[15:59] <rick_h_> to lxc or aws or anything
[15:59] <jcastro> I am not worried about the bundle not working from my local file
[15:59] <jcastro> I am worried about testing it from the store
[15:59] <gary_poster> yeah, that's a great test because it uses the GUI charm to deploy
[15:59] <gary_poster> so it works in quickstart
[15:59] <gary_poster> then you are testing the GUI
[15:59] <gary_poster> in one command
[16:03] <hatch> Makyo: did you see that bug come in about upgrade charm?
[16:04] <hatch> is that a gui or charmworld issue?
[16:05] <Makyo> hatch, Both?
[16:06] <Makyo> hatch, charmworld doesn't give us a list of downgradeable versions, though we do have revision info.
[16:06] <Makyo> We could request against each version but that'd be dumb.
[16:06] <hatch> ohh ok -
[16:06] <hatch> for example precise/mysql-27/ shows me rev 28 no matter what
[16:07] <Makyo> non-linear charm versions is interesting, though.
[16:07] <Makyo> hatch, I believe you get latest no matter what.
[16:07] <Makyo> That was the backfilling, I believe.
[16:07] <hatch> ok so the 'links' to show those versions is.....useless?
[16:07] <Makyo> Until we move to api v3 I think
[16:08] <rick_h_> yep, api3 supports versioned charms as part of the bundle work
[16:08] <hatch> ahh ok cool
[16:08] <Makyo> I can't really afford to switch right now, hatch.  That answer most concerns?
[16:09] <hatch> Makyo: yep that points me in the right direction
[16:09] <hatch> thanks
[16:09] <Makyo> Cool
[16:13] <hatch> yeah mysql jumps from 22 to 28 which is odd I suppose :)
[16:16] <jcastro> wow gary_poster
[16:16] <jcastro> this plugin is my new god
[16:16] <gary_poster> jcastro, lol awesome
[16:17] <jcastro> gary_poster, where do I file bugs?
[16:18] <gary_poster> jcastro, https://bugs.launchpad.net/juju-quickstart/+filebug
[16:18] <jcastro> how is the bootstrap so fast?
[16:18] <rick_h_> :)
[16:20] <gary_poster> jcastro, getting the GUI up via the API means that we don't have to wait on downloading the charm to your local system and uploading it to the environment--it just goes straight from the charm store to the environment without a middleman; getting it up on machine 0 simply means we don't have to wait on another machine, but that's probably something you already do
[16:20] <jcastro> man, that is a thing of beauty
[16:21] <jcastro> I'm going to start filing bugs even though you mention the limitations in your mail so we can track them, is that cool?
[16:21] <gary_poster> +1 thanks jcastro
[16:24] <jcastro> man, it's deploying the bundle
[16:24] <jcastro> awesome.
[16:24] <jcastro> dude, THANK YOU for putting the gui password in the console too
[16:24] <jcastro> that is perfect
[16:25] <jcastro> ok so the one thing I can't do is ... juju-quickstart <remote URL>, that's what's coming next week
[16:25] <gary_poster> right
[16:26] <gary_poster> we will auto-log-you-in soon, too, and have the GUI tell you where to find your password in the future, or to just use quickstart again to open the GUI in this environment, so you don't have to look at the console
[16:32] <hatch> so with the upgrade charm details, do we want to open up the charm browser? or open it in the inspector breakout?
[16:42] <Makyo> Finally got this. Man, SVG scaling is weird. I can never remember when I need to take the scale into account.
[16:43] <Makyo> Test, then propose.
[16:51] <hatch> hmm huw found quite the bug with this linking issue
[16:56] <hatch> rick_h_: got a second?
[16:57] <rick_h_> hatch: yea
[16:57] <hatch> I THINK I found a browser routing bug...but not sure
[16:57] <hatch> steps are
[16:57] <hatch> http://comingsoon.jujucharms.com/:flags:/charmworldv3/
[16:57] <hatch> deploy mysql
[16:58] <hatch> click 'upgrade service'
[16:58] <hatch> click mysql-27
[16:58] <hatch> (it should open the browser)
[16:58] <hatch> click the X in the browser details page
[16:58] <hatch> click mysql-27 in the inspector again
[16:58] <hatch> note the # in the url now
[16:58] <rick_h_> hatch: yea
[16:59] <Makyo> Cute.  HaaS (hugs as a service) http://www.nowcheerup.me/  How would one charm a hug?
[16:59] <rick_h_> hatch: sec
[17:00] <rick_h_> hatch: I don't have time to go through it but I can walk you through what to check
[17:00] <rick_h_> hatch: hangout?
[17:00] <hatch> sure link?
[17:00] <rick_h_> https://plus.google.com/hangouts/_/72cpj09acjl4ip5f6bjgt8fkqg?hl=en
[17:04] <bac> benji: after LP noticed your LGTM rv-submit was happy.  so the process is working as we'd hoped.
[17:12] <benji> bac: cool
[17:15] <benji> bac: how goes the review of https://codereview.appspot.com/20820043 ?
[17:16] <hatch> rick_h_: thought you'd find this interesting....viewNavigate is not being fired to open the panel :)
[17:16] <hatch> I think some of our routing code has become self aware
[17:16] <rick_h_> hatch: well then there's your problem. :)
[17:17] <rick_h_> hatch: so it's not updating _viewState in a sane way then I bet
[17:17] <hatch> that's probably exactly it
[17:17] <rick_h_> hatch: so will be curious to see how _viewState is getting updated and such
[17:17] <rick_h_> what values it ends up with
[17:17] <rick_h_> hatch: but it makes sense, that version of the View isn't tied to the subapp/browser.js
[17:18] <rick_h_> hatch: I mean that the inspector isn't tied to the browser state like that. /me is trying to think but brain is fried
[17:18] <hatch> yeah that's fine I'll keep tracking it down
[17:18] <rick_h_> hatch: yea, I mean there's still something sticknig it in the hash
[17:19] <hatch> the ie redirect is happening before that i've found
[17:19] <hatch> so this is a separate bug
[17:19] <rick_h_> hatch: the other thing to drop a debugger into is the sidebar: function in browser.js to check the request to see if the routing is passing it in as a hash then and we're picking it up
[17:19] <rick_h_> hatch: ok, yea, if that's not using the viewNavigate i wonder if it's just something where YUI isn't blocking the <a> for IE
[17:20] <rick_h_> hatch: it might just be a simple case of that the inspector needs to catch upgrade <a> clicks and do a manual navigate change
[17:20] <hatch> yeah i'm going to hope that I can restore the pjax functionality
[17:20] <hatch> i'd rather not fire events all around
[17:20] <rick_h_> yea, true
[17:21] <hatch> ok sidebar is not being called
[17:22] <rick_h_> hatch: the details view can't open without it being called :/
[17:22] <hatch> the details view is rendered via 'renderEditorial' right?
[17:22] <hatch> (it's also not being called)
[17:23] <rick_h_> hatch: no, it's from sidebar
[17:23] <hatch> what in the....
[17:23] <rick_h_> benji: got a few min?
[17:23] <benji> rick_h_: sure
[17:24] <rick_h_> benji: https://plus.google.com/hangouts/_/72cpin08id5me7l01r1rnplpgg?hl=en
[17:27] <hatch> gary_poster: did you ever figure out why chrome wasn't catching your debugger statements?
[17:27] <hatch> I'm running into the same issue right now
[17:29] <rick_h_> hatch: you don't have them turned 'off' by change?
[17:29] <rick_h_> chance?
[17:29] <hatch> I wish
[17:29] <hatch> haha
[17:29] <rick_h_> ok, just checking. It's the only way I know to stop them
[17:29] <rick_h_> well, and the dev tools are open?
[17:29]  * rick_h_ ducks
[17:29] <hatch> lol
[17:30] <hatch> I have a debugger in routeDefault in browser.js and it's loading without stopping
[17:30] <hatch> that's not even possible.....
[17:30] <hatch> had to restart chrome
[17:30] <hatch> working now
[17:30] <rick_h_> so it's connected to the window? Or did you split the debugger/window?
[17:30] <rick_h_> oh, cool
[17:31] <gary_poster> hatch on call sorry
[17:32] <hatch> no problem, a reboot fixed it
[17:38] <gary_poster> so...I keep thinking that, if we don't have a "ghost" stage for bundles, we need bundles to ask for configuration
[17:38] <gary_poster> The only use case I had was openstack
[17:38] <gary_poster> which we were told was not a driver
[17:38] <gary_poster> but what about passwords
[17:38] <gary_poster> we want to have passwords and such excluded from export
[17:38] <rick_h_> yea, I've been wishing a couple of times for at least an editor window "edit this bnudle before deploying"
[17:39] <gary_poster> yeah
[17:39] <hatch> why is a ghost bundle stage so bad?
[17:39] <gary_poster> I'm picturing an inspector that lets you configure values that a bundle author has highlighted as needing configuration
[17:39] <gary_poster> because it is expensive to build and we have been told not to work on it :-)
[17:40] <rick_h_> heh, I was thinking a quick first pass is just loading the content as an editable field as yaml
[17:40] <gary_poster> huh, could be
[17:40] <rick_h_> then hit deploy and it could validate and then go
[17:40] <hatch> haha oh ok
[17:40] <gary_poster> not the GUI expereince though
[17:40] <rick_h_> true
[17:40]  * gary_poster has to step away.  back soon
[17:40] <hatch> I was thinking deploy the bundle as ghosts which the user can go into each service to modify
[17:40] <hatch> then click one 'deploy all' button
[17:40] <gary_poster> that was the original plan, yes
[17:41] <gary_poster> even that would arguably want an interface like the one I'm describing though
[17:41] <hatch> yup
[17:41] <gary_poster> "yeah, you can customize this thing, but you *really* ought to fill these out
[17:41] <gary_poster> "
[17:43] <hatch> I could see that as a logical progression from some type of form validation
[17:43] <hatch> or not...
[17:43] <hatch> :)
[17:50] <Makyo> jujugui lf review/QA https://codereview.appspot.com/20870043
[17:50] <hatch> ill do it
[17:50] <hatch> i need a break :)
[17:58] <hatch> Makyo: done lgtm qaok
[17:58] <Makyo> Whew~
[17:58] <hatch> 8 minute review/qa turnaround
[17:58] <hatch> not bad :P
[17:59] <Makyo> Heck yeah :D
[18:00] <hatch> I'm really getting nowhere with this routing issue
[18:01] <rick_h_> hatch: you hitting it enough to see if it's coming into the routed view handler's req object as with a hash?
[18:01] <Makyo> hatch, I agree that we should introduce bounding box stuff to the real topology at some point, in another branch.  Rather than just centering the canvas, it would center and scale as with bundles.
[18:01] <hatch> rick_h_: well I've determined that it's before any of the browser stuff
[18:01] <hatch> it's definitely routing issues
[18:01] <hatch> Makyo: sounds good :)
[18:01] <rick_h_> hatch: yea, so walking through the ns-routing stuff is the fun part. Obvious chase anything with hash interactions first
[18:02] <rick_h_> someone's telling it to do it, just have to find where it's coming from
[18:03] <hatch> sometimes I really hate YUI wrapping everything for convenience
[18:03] <hatch> :)
[18:05] <hatch> I do know that it's an even listening on the body for clicks to a's
[18:05] <hatch> :)
[18:05] <rick_h_> yea, that's the app framework stuff
[18:06] <hatch> right, but setting linkSelector to '.not-an-a' should disable it
[18:07] <benji> rick_h_: I don't see any big problems with your branch (just a few lint-type things that we can address in the real review); I'm going to take a stab at a little refactoring to see if it looks like something you would want
[18:08] <rick_h_> benji: thanks, appreciate the punch-drunk sanity check
[18:09] <hatch> Ooo getting closer
[18:09] <hatch> _navigate doesn't get called in IE
[18:18] <bac> benji: in https://codereview.appspot.com/20820043/diff/1/charmworld/models.py on line 1905 how is bucket_index ever None?
[18:18]  * benji looks
[18:18] <hatch> ahah
[18:18] <hatch> !
[18:18] <bac> maybe you're missing a test in the find method?
[18:18] <hatch> sometimes debugging the hard way gets the best results
[18:19] <benji> bac: if the increment is for a day that is so far in the past that there is no daily bucket for it
[18:19] <benji> I will add something to that effect to the comment.
[18:19] <bac> benji: but how?  i don't see any such logic in _find_day_offset
[18:20] <benji> bac: ooh!  you're right; there is a missing test that should have excersized that branch and pointed out the problem
[18:20] <benji> I'll add that test and then fix.
[18:20] <bac> benji: i'm not to the tests yet!
[18:21] <benji> I would *really* like us to start using test coverage.  This is exactly the kind of problem it helps find.
[18:22] <hatch> rick_h_: so this bug is not at all related to the browser stuff - that's an entirely separate issue caused by pjax routing the link vs going through the navigate... just FYI
[18:22] <rick_h_> benji: I think nose is spitting out coverage already? /me goes to check makefile
[18:22] <rick_h_> hatch: yea, that's what I figured. The only way to prove it was to verify that it was happening in the req and not in our viewNavigate calls
[18:23] <hatch> it's a pretty rare sequence of events so that's why we never caught it before
[18:23] <rick_h_> rgr
[18:23] <hatch> hopefully the removal of the router stuff allows us to remove the browser url parsing
[18:23] <benji> rick_h_: I'm thinking of a very specific kind of coverage, i.e., define a set of tests that should cover a set of code and verify that the coverage is 100%
[18:24] <rick_h_> benji: ok, looks like we're not using it but nose supports using coverage.py if it's avail
[18:24] <benji> you can build such a thing from simple code coverage, but it takes some work (I have such a system for my termbeamer project and it is great, if a bit ridgid in its requirements)
[18:24] <rick_h_> https://nose.readthedocs.org/en/latest/plugins/cover.html
[18:24] <hatch> going to grab some lunch
[18:24] <hatch> bbiab
[18:24] <rick_h_> benji: yea, gotcha
[18:29] <benji> rick_h_: here is some example output: http://i.imgur.com/4KuW5WZ.jpg
[18:30] <rick_h_> benji: cool
[18:37] <rick_h_> benji: pushing up the api tests and some tweaks due to errors the tests pointed out
[18:38] <rick_h_> benji: lp:~rharding/charmworld/proof-relations
[18:42] <bac> benji: i think it is safer to use datetime.utcnow().date() instead of datetime.date.today() given my yearning to live a tz-free existence.
[18:43] <bac> if huw were to run tests right now he'd get a different today than we would and that might break things.
[18:53] <benji> bac: I'm pretty confident that the tests will never fail do to time (but I'll give them another once-over to be sure), but I think naive dates are actually the right thing to do here, otherwise utcnow().date() might give us a day that isn't the right day
[18:55] <rick_h_> benji: up for a follow up? I'll peek at the original notes of things to clean up and see what you think regardling reorg and try to finish up quick?
[18:56] <benji> rick_h_: I haven't written the lint-y notes yet, as I figured you might change some, but I'll be glad to do the follow-up now and include them there
[18:56] <rick_h_> benji: cool
[18:57] <bac> benji: how could utcnow().date() not be the right date if we agree to always be in UTC?.  seems unintended date offset is more likely the other way.  but, having looked at your tests and they way you always used defined dates i agree it is unlikely.  could have problems if someone adds a test that uses current time...but i guess that's just a bad test.
[18:58] <bac> s/they way/the way/
[19:16] <bac> benji: review done
[19:17] <benji> bac: thanks!
[19:19] <rick_h_> benji: https://codereview.appspot.com/20810043/ is up with reviewer comments.
[19:19] <rick_h_> benji: thanks again for the help and sanity checks today
[19:20] <benji> rick_h_: my pleasure; looking now
[19:44] <gary_poster> jujugui, if anyone has any bandwidth to bring a hack home, http://paste.ubuntu.com/6343083/ makes all of jorge's non-broken bundles (that is, all but reviewboard) show up in the bundle visualization.  Makyo, I know you are making magic happen and I appreciate it, but if you apply that patch and then look at http://localhost:8888/sidebar/search/bundle/~jorge/mediawiki-scalable/4/mediawiki-scalable/:flags:/charmworldv
[19:44] <gary_poster> 3/?text=jorge , you'll see the first bundle visualizatio that actually pushes a charm partially off the screen
[19:44] <gary_poster> http://localhost:8888/sidebar/search/bundle/~jorge/mediawiki-scalable/4/mediawiki-scalable/:flags:/charmworldv3/?text=jorge
[19:44]  * gary_poster goes to get boys from school
[19:56] <Makyo> Something's wonky about this bundle.
[19:57] <Makyo> The 'contribute' command is listed as `bzr branch lp:~jorge/mediawiki-scalable/4/mediawiki-scalable` but should be `bzr branch lp:~jorge/charms/bundles/mediawiki-scalable/bundle`, and the yaml indentation is off (which may be the actual root of the problem)
[19:58] <Makyo> Uh, nevermind the indentation, sorry, I'm a liar.
[20:01] <gary_poster> Makyo, the branch issue is in the GUI.  My branch fixes it
[20:02] <gary_poster> I mean, my hack :-P
[20:02] <gary_poster> jujugui, am I right in guessing that no-one took the branch?  If so, I'll get to it ASAP
[20:03] <Makyo> Oh, I totally misread :(
[20:03] <Makyo> Sorry :S  No, didn't pick it up.
[20:03] <hatch> gary_poster: hey sorry I can eventually, I'm just writing a repro of this IE bug to see if it's a YUI/IE issue or something in our app
[20:08] <gary_poster> Makyo, hatch, cool, np thanks, will carry it in a few
[20:18] <hatch> ahah! it's a YUI bug
[20:18] <hatch> that took way to long
[20:19] <hatch> jujugui anyone with IE10 available for a quick sanity check?
[20:19] <Makyo> Yyyyyeah...just a sec.
[20:19] <Makyo> Let me start up.
[20:19] <gary_poster> :-)
[20:19] <hatch> Makyo: thanks :)
[20:20] <hatch> I just need a sanity check on this http://jsbin.com/ExoDUGIt/1/edit
[20:20] <hatch> there is a monkey patch which, if deleted, will allow the 'rockon' url to be added to the address bar, but in chrome everything always works as expected
[20:21] <hatch> gary_poster: ok now I can do your branch above if still needed
[20:23] <gary_poster> hatch, oh, thanks, would be awesome.  Just wrote first test.  Probably need two more--one for situation of import with a yaml file that specifies a name, and *maybe* one for the small deploy tab fix I made.
[20:23] <gary_poster> Last one might be unnecessary.
[20:24] <hatch> alrighty, can you paste the new diff?
[20:24] <gary_poster> yeah, one sec
[20:25] <Makyo> hatch, what am I looking for now?  URL doesn't change with or without monkey patch.
[20:26] <Makyo> Oh, hmm.
[20:26] <Makyo> IE may just be lame.
[20:27] <hatch> ohh it needs to be in not /edit mode sorry
[20:28] <Makyo> Oh, okay
[20:29] <gary_poster> hatch, http://paste.ubuntu.com/6343329/ .  The charm id revision change may be nastier than I had hoped.  Test I wrote fails, as you'll see.  Feel free to toss it back, but I suspect you'll make short work of it.  Part of QA should be to verify that all of Jorge's working bundles now show a visualization
[20:29] <Makyo> hatch, confirmed
[20:29] <hatch> Makyo: thanks :)
[20:29] <hatch> your work here is done
[20:29] <hatch> you may go
[20:30] <gary_poster> :-P
[20:30] <hatch> haha
[20:30]  * gary_poster returns to spreadsheet that he had escaped for a brief shining moment
[20:30] <hatch> ok can you give me a real quick overview of what the problem/solution was
[20:33] <benji> rick_h_: I'm done with https://codereview.appspot.com/20810043/
[20:36] <gary_poster> hatch, sorry, yeah.  So, the main point of this is to make it so that Jorge's bundles actually had working bundle visualizations.
[20:36] <gary_poster> The patch also has some unrelated text flybys on the bundle page
[20:37] <gary_poster> The reason why the bundles were not visualizing was that they were not importing properly.  I discovered this by trying to deploy them, and getting the nice new error massages you made yesterday, hatch.
[20:37] <gary_poster> So there were two issues.
[20:37] <hatch> sweet
[20:37] <hatch> haha
[20:37] <gary_poster> First, the discourse bundle has a charm without a revision
[20:38] <gary_poster> this caused a problem because the fake backend refused to handle it...because our charm id parser refused to handle it
[20:38] <gary_poster> I'm a little bit nervous that the change I made there will have repercussions.
[20:39] <bac> rick_h_: you have a moment for a quick call?
[20:39] <hatch> alrighty well I'll put it through its paces
[20:39] <hatch> and I'll land this wako ie fix at some point too
[20:40] <gary_poster> Second, hatch, another bundle had an issue because it wanted to deploy mysql twice.  It turns out that the fakebackend was completely ignoring the service names in the deployer file.    That's the code that I deleted in fakebackend, and replaced with just setting .name
[20:40] <hatch> haha
[20:40] <hatch> awesome
[20:40] <gary_poster> That's his "mediawiki-scalable" bundle, fwiw
[20:41] <gary_poster> So those are the only two bundle-related fixes
[20:44] <hatch> sounds good
[20:47] <marcoceppi> gary_poster: do you have a link to the doc from the sprint about bundles v2?
[20:47] <gary_poster> marcoceppi, https://docs.google.com/a/canonical.com/document/d/1fmlRgMoQhdwsF5w9jPApNrTM1obXHvDwuE85kx8EsbU/edit ?
[20:47] <marcoceppi> gary_poster: Yes, thank you!
[20:48] <gary_poster> welcome :-)
[20:50] <gary_poster> marcoceppi, unfortunately, we probably won't be doing that (because we have been told not to, because of other priorities :-) ).  Something I want to propose that we prioritize is that bundles gain config fields.  Before deploying, you would need to fill in, say, password fields or other bits like the ceph thing.  I think we probably need something like this eventually, but the question is importance/prioritization.
[20:51] <gary_poster> I'll be looking for opinions later
[20:51] <gary_poster> but feel free to share now if you have any immediate ones :-)
[20:51] <marcoceppi> gary_poster: oh, yeah I saw that. I just couldn't remember the word "immutable" embarrasingly enough and needed to use it. So, I know it was recorded during that session :)
[20:51] <gary_poster> heh, ok cool :-)
[20:51] <marcoceppi> gary_poster: that idea starts to sound a lot like stacks at that point
[20:52]  * marcoceppi wonders why we just don't grow bundles in to stacks
[20:52]  * marcoceppi walks away wondering to himself
[20:52] <hatch> what happens with an immutable object encounters an immutable force?
[20:52] <gary_poster> marcoceppi, yeah, that's being proposed actively :-)
[20:52] <hatch> ....wait that's not right... :P

[20:52] <marcoceppi> hatch: marriage? Is that the answer?
[20:53] <hatch> I'm not sure
[20:53] <hatch> this sounds like a job for.....*spins around*......
[20:53] <hatch> HATCH MAN!
[20:59] <rick_h_> bac: sure thing, give me 2min?
[20:59] <rick_h_> benji: thanks for the review
[21:00] <bac> rick_h_: ok
[21:01] <rick_h_> bac: https://plus.google.com/hangouts/_/7acpjhgnd2ie5j8vpvbiko0b3o?hl=en
[21:08]  * Makyo walks dogs.
[21:08] <Makyo> May also head out a bit early today since last night was so messed up.
[21:11] <marcoceppi> greetings gui folks, there are two merges in the queue that have been here for a while. Not sure you guys were aware of it or not:  https://code.launchpad.net/~benji/charms/precise/juju-gui/fix-cache-headers/+merge/177958 and https://code.launchpad.net/~frankban/charms/precise/juju-gui/guiserver-bundles-initial/+merge/179750
[21:11] <marcoceppi> is there any action I can take on either of these?
[21:12] <rick_h_> benji: ^
[21:12] <bac> thanks rick
[21:13]  * bac walks dog between storms (i hope)
[21:13] <rick_h_> bac: np, let me know if you need anything
[21:13] <rick_h_> and if proof gives you trouble blame marcoceppi :P
[21:13]  * marcoceppi twiddles thumbs
[21:17] <gary_poster> :-)
[21:19] <gary_poster> jujugui, this is the new, new, new prioritized spreadsheet of possible Nov-Dec tasks for us.  We'll work down these as far as we can in the timeframe, while also responding to bugs and the like.  This is timeboxed: we get done what we get done in the time period.  https://docs.google.com/a/canonical.com/spreadsheet/ccc?key=0AtC9etoysSQldDQxMVdmTDB4dm1XXzA0NFlLSUQ4Mmc&usp=drive_web#gid=0
[21:19] <gary_poster> Comments welcome.  I'm sending it to mramm
[21:20] <hatch> gary_poster: you have no 'units' on your cost column
[21:20] <hatch> spreadsheet fail :P
[21:20] <gary_poster> Note I reordered some of the things from the discussion with luca, but it should look familiar
[21:20] <gary_poster> hatch :-P it is planning-poker style arbitrary units :-)
[21:21] <hatch> ohhh haha gotcha
[21:21] <gary_poster> hatch that's why it says "relative" ;-)
[21:21] <hatch> iiiiiii seee now
[21:21] <rick_h_> hatch: don't try to out manager the manager :P
[21:21] <gary_poster> heh
[21:21] <hatch> haha
[21:34] <hatch> Makyo: I found a issue with your algo for positioning bundles - view the bundle vis for mediawiki-scalable bundle - just FYI
[21:35] <hatch> I can file a bug if you don't want to look at it now :)
[21:38] <hatch> oh actually nm, this won't be an issue when we add pan/zoom
[21:47] <Makyo> hatch, I thought that was the problem we were running into with gary_poster's branch? That whole bundle was busted for me.
[21:47] <Makyo> Like, most things about it.
[21:47] <hatch> Makyo: yeah sorry it's fixed now but only locally
[21:48] <hatch> so what happens is because it's to tall it doesn't fit becauseit looks like it has a padding on the canvas bottom
[21:48] <Makyo> Oh, okay.
[21:49] <Makyo> Yeh, probably later.  Surprise company in a few, and me, without any makeup on!
[21:49] <hatch> haha
[22:46] <hatch> still haven't been able to figure out a proper indention for chaining with the linter
[22:57] <rick_h_> because chaining is evil :P
[23:00] <hatch> but but promises!
[23:03]  * gary_poster runs away.  have a great weekend everyone!  If anyone has a review they need, I'll check in mail every now and then
[23:04] <hatch> you too! I'll be proposing the branch with a bit of modifications :)
[23:04] <gary_poster> awesome
[23:12] <hatch> gary_poster|away: whenever you pop back https://codereview.appspot.com/21020043/ I have added reviewer notes where things were modified from your diff
[23:13] <hatch> I'll get the IE branch proposed tonight sometime as well but now I need a break :)


[11:06] <john122> taeaad because I'm using the 4 outputs of the Rubix 24 to play 4 separate voices from a Jitsi conference into a digital mixing desk for processing and mixing, and the in-built card is for playing audio from videos and jingles etc and keeping it separate from the voices