[01:49] <ScottL> bug #726199
[02:00] <ScottL> anybody do a full install of ubuntu studio lately?  did the plymouth theme work or was it a light blue screen?
[02:01] <ScottL> holstein, it looks like the network indicator in natty already indicates when the network is unplugged (at least it did for me on my alpha3 install)
[02:01] <ScottL> at least it think it was alpha 3 install
[03:11] <ailo> ScottL, I've had the plymoth fail after some upgrade. I should install the latest to see how things work.
[11:06] <ailo> Hey abogani
[11:06] <abogani> ailo: Hi
[11:07] <ailo> I haven't been testing the kernels for a while. I took out my wireless card, so I tried quckly now, but it seems I can still get a few random xruns
[11:07] <ailo> It didn't happen while the computer was idle. Last time when I was using the browser.
[11:09] <ailo> But I suppose it could be anything
[11:11] <ailo> I should test on other systems. I compiled a kernel for Debian using vanilla source, and it seemed to work a little better on another PC. I should try different things on this one.
[11:12] <ailo> I'm currently running on Ubuntu, and it's using a lot of memory. I should switch to Ubuntustudio to do some testing there as well.
[11:14] <abogani> For avoid x-runs completely we have to use -realtime kernel.
[11:18] <ailo> Well, I can use this kernel on a higher latency setting, and still get good enough latency for production use, so I'm quite happy with this kernel in that sense, but I suppose for so many other hardware a -realtime will be a big help.
[11:20] <abogani> ailo: In any case your approach is the best: -lowlatency is more stable, updated, secure and compatible.
[11:32] <ailo> Hey T0rCh_raony , what's up?
[11:33] <T0rCh_raony> hey ailo
[11:34] <T0rCh_raony> still didn't had time to work on the indicator applet, but i will take a look this week
[11:35] <ailo> T0rCh_raony, No hurry. No one has decided on anything either, so it would just be an example application. falktx has been working on some software for KXStudio which has similar functions.
[11:35] <T0rCh_raony> cool, do you have his repository ?
[11:36] <ailo> Let's see..
[11:36] <ailo> T0rCh_raony, git://repo.or.cz/cadence.git
[11:37] <ailo> T0rCh_raony,  build depends: python-qt4-devel pyqt4-dev-tools ladspa-sdk dssi-dev libasound2-dev
[11:37] <T0rCh_raony> ok
[11:37] <ailo> T0rCh_raony, runtime depends: libjack0 python-rdflib python-qt4-dbus python-qt4-gl jack-capture
[11:38] <T0rCh_raony> hey falktx
[11:38] <ailo> T0rCh_raony, You can look in the make file to see what apps there are. Do make, and make install.
[11:39] <T0rCh_raony> ok
[11:39] <ailo> T0rCh_raony, And the app Carla needs to be compiled separately, make Carla
[11:39] <falktx> T0rCh_raony: step are actually "make" and "make carla" <- unstable app
[11:39] <falktx> apps usable so far:
[11:39] <falktx> - audio_test_plugin
[11:40] <falktx> - catarina (canvas test)
[11:40] <falktx> - catia (jack patchbay)
[11:40] <falktx> - claudia (jack patchbay+ladish gui)
[11:40] <falktx> - carla (multi-plugin host)
[11:41] <falktx> - xycontroller
[11:41] <falktx> small tools:
[11:41] <falktx> - jacksettings
[11:41] <falktx> - logs
[11:41] <falktx> - render
[11:41] <falktx> and that'is it
[11:41] <falktx> to run them:
[11:41] <T0rCh_raony> cool
[11:41] <falktx> python src/<app-name>.py
[11:41] <T0rCh_raony> looks promissing
[11:43] <falktx_> some this network sucks...
[11:43] <falktx_> please say again
[11:48] <ailo> Actually, I think the runtime depend should be libjack-jack2-0
[12:10] <ScottL> abogani, the -lowlatency kernel built in my ppa last night :)
[12:32] <abogani> ScottL: :-)
[18:16] <ailo> scott-work, I installed us-natty alpha 3 right now. I think at least two tasksels are not working now. I wasn't able to identify which ones. I could reinstall on Virtualbox later to find out.
[18:17] <ailo> Also, I must have forgotten before, but installing from usb is no problem, if using unetbootin, but this is perhaps known already.
[18:17] <holstein> ailo: yeah?
[18:17] <holstein> no complaints about where the install media is ?
[18:17] <holstein> thats great :)
[18:18] <ailo> holstein, Yeah, it works pretty smoothly. I just choose the iso, and make the usb.
[18:18] <scott-work> ailo: that's interesting about the tasksel
[18:19] <holstein> theres a really nice reporting option
[18:19] <holstein> in the installer
[18:19] <holstein> makes a webserver
[18:19] <scott-work> when alpha 3 was released i installed all and they worked then :(
[18:19] <holstein> for you to se the log of what failed
[18:19] <ailo> holstein, How does that work?
[18:19] <scott-work> ailo: but that is good news about installing from usb though :)
[18:19] <holstein> cjwatson got me hip to it last time i was trying to sort out what taskselect failed
[18:19] <holstein> ailo: i'll have to get it in front of me
[18:20] <holstein> BUT, i remember...
[18:20] <holstein> its in the alternate installer list
[18:20] <holstein> where is says like 'partition disks'
[18:20] <holstein> something about 'view logs' ?
[18:20] <holstein> near te bottom i remember*
[18:22] <ailo> Ok. I'll try installing on Virtualbox later today. This time I tried installing all tasksels, and taking one out each time it failed, but that didn't help, so that's why I thought it must be at least two that doesn't work.
[18:22] <scott-work> ailo: you can also see:  /var/log/install/syslog
[18:22] <scott-work> if you can get to tty2
[18:23] <ailo> scott-work, Only during install?
[18:24] <ailo> I seem to remember dropping to shell is not so hard. Is the same? Ctrl - Alt - F1?
[18:24] <scott-work> ailo: if you can get the install to finish then you can get to it however you want
[18:24] <scott-work> but yeah, you may need to drop to shell during install to see what the error is
[18:24] <scott-work> i _think_ i'm done with my current natty install so might try to reinstall it this weekend
[18:25] <ailo> I've been on regular Ubuntu too much, so I figured, I need to get the hang of the US Desktop.
[18:28]  * ailo rebooting..
[19:28] <ailo> ScottL, holstein: Did have a strange experience when booting into US alpha 3 first time. ubuntustudio-desktop wasn't installed.
[19:29] <ailo> When I booted in, instead of coming to a terminal prompt, the screen just went to sleep, and I had to do Ctrl -> Alt -> Del to reboot
[19:30] <T0rCh_raony> something weird here ...I like to use wicd for a thousand reasons, when I was trying to remove networkmanager it was asking me to remove ubuntustudio-desktop together, what this package contains ?
[19:30] <ailo> I installed ubuntustudio-desktop, and after that I was able to boot into the desktop
[19:30] <ailo> T0rCh_raony, ubuntustudio-desktop is just a met-package, so there's no worry
[19:30] <ailo> meta-package
[19:31] <T0rCh_raony> I know cause it didn't cause any damage to the system :)
[19:32] <ailo> It depends on all the packages that you need for ubuntustudio-desktop, so installing that package, all of the dependencies will be installed.
[19:32] <T0rCh_raony> oh, I see
[19:33] <ailo> ScottL, Also, my screen wasn't looking good. I know from a previous installation that I had problems with corrupted graphics. I probably should have reacted then, but there was a lot going on with the standard Ubuntu Desktop at the time
[19:33] <ailo> ScottL, This time, only part of the screen was used.
[19:34] <ailo> Installing nvidia drivers solved it
[19:37] <ailo> scott-work, Just had some problems with the post-install of US alpha 3
[19:40] <scott-work> doh
[19:40] <scott-work> wait, "post-install" ?  which part then
[19:41] <ailo> scott-work, ubuntustudio-desktop hadn't been installed.
[19:42] <ailo> It didn't boot into prompt even, but from recovery mode, I was able to install ubuntustudio-desktop. After that, I was able to boot to desktop, but only part of the screen was in use. Installing nvidia drivers made the screen look normal
[19:42] <ailo> I'm doing a new install on Virtualbox now, in case there was something strange with the usb stick
[19:44] <ailo> T0rCh_raony, Which version did you install. Was it a daily build?
[19:47] <T0rCh_raony> http://cdimage.ubuntu.com/ubuntustudio/releases/natty/alpha-3/
[19:49] <ailo> Ok, so I can confirm that installing from usb stick was maybe not such a good idea after all
[19:50] <scott-work> ailo: oh, you were isntalling from usb with that....hmmmmm, interesting
[19:50] <scott-work> but still, it would be wicked to get usb install working though
[19:50] <ailo> Even the tasksel looked different. Seems like all the tasksels are working too
[19:53] <ailo> I suppose getting a usb installation working shouldn't be that far away, since at least the base system installs.
[19:58] <ailo> scott-work, Have you talked with MacInnis, or what's his name? Our art man..
[20:00] <scott-work> briefly, i'm about 1/2 way through with announcing him on the mailing list, forums, et al
[20:01] <scott-work> work and home are still pretty jumping for me
[20:01] <scott-work> even though i managed to get some other issues resolve for more time
[20:02] <ailo> scott-work, Did you look at his art? I checked out his PPA before, and installed the theme
[20:04] <scott-work> yeah?  what did you think?
[20:05] <scott-work> i've looked at his website, both personal with music/videos, and dream studio
[20:05] <scott-work> i think he's a helluva creative guy with some talent
[20:07] <ailo> I'm not totally crazy about the theme, though. I would want to raise the bar a little for Ubuntu Studio.
[20:08] <ailo> I like that there are three versions, ambience light, ambience and ambience dark, or something like that
[20:12] <ailo> I was agreeing with him on the strategy, to try use Ubuntu's theme as base, but pimp it and make it look Ubuntu Studio.
[20:13] <ailo> I've already been working on Humanity based Icons, so perhaps I might as well try get those finished as an alternative.
[20:16] <ailo> It's funny how installing ubuntustudio-desktop afterwards gave a different default setup for panels and such
[20:17] <ailo> I mean, even before any desktop had been installed
[20:22] <scott-work> ailo: i would like to develop multiple themes and let some group, either focus group or user base as a whole, decide which one to install as default
[20:22] <ailo> scott-work, Sounds like a good idea
[20:23] <scott-work> i would REALLY like to develop that black and grey theme we looked at before
[20:23] <scott-work> in my opinion that is the best looking dark theme i have ever seen
[20:25] <ailo> scott-work, I guess there doesn't need to be just one. But only one can be installed by default. I like dark, but it has to be functional. Otherwise, I would at least only admire it, but never use it. Haven't used that one, but that's pretty much how I've felt about most dark themes.
[20:26] <ailo> Don't let me close any doors, though :P
[20:35] <ailo> scott-work, There's no Desktop volume control. Don't we need the indicator-applet?
[20:36] <scott-work> i would like to add it, yes
[20:36] <scott-work> i've always had to go to pavu control to set the volume
[20:37] <scott-work> i'm not sure what is involved however because i believe we are using a gconf settings file to set the panels up
[20:37] <ailo> scott-work, pavu control would be unneeded once there is a volume control. There's also padevchooser which is outdated
[20:38] <scott-work> if you would figure out which applet is needed i will see about updating the gconf file
[20:39] <ailo> I'll fool around with it.
[21:02] <ailo> scott-work, Just quickly testing on Virtualbox. For some reason, and I think this happened before, gtk isn't working properly. But, about the indicator applet. After updating the system, there was no problem adding it.
[21:04] <ailo> The indicator applet is apart of the standard set of applets already when doing a fresh install.
[21:31] <scott-work> i'll try adding it to my natty install tonight then
[21:32] <scott-work> i think this file is where it is set:  http://bazaar.launchpad.net/~ubuntustudio-dev/ubuntustudio-default-settings/UbuntuStudio/files
[21:32] <scott-work> ubuntustudio-panel-settings.entries
[21:33] <scott-work> i'll see if i can find it first, make a copy, add the indicator, then diff the two files and see what pops out
[21:33] <ailo> scott-work, I've only tried copying a custom made file. I should see if that is enough to create a new file.
[21:33] <scott-work> at least that's the plan
[21:34] <ailo> I mean, after adding something, you copy the file
[21:34] <ailo> Don't know if something else is added to that, but could be worth a shor
[21:34] <ailo> shot*
[21:35] <ailo> I'm talking unclearly as usual. Just to be clear: Could be, if you add the indicator, that the file in home directory just needs to be saved.
[21:36] <scott-work> copy the file first because when i add the indicator i think it will change that file
[21:36] <scott-work> i'm hoping that's what happens
[21:36] <scott-work> oh, i think i know what you are saying
[21:37] <scott-work> i can't use the new, update file to update the package, i won't be uploading a brand new file to the repos
[21:37] <ailo> Yeah, I'm not making a lot of sense :). After you add something, could be you just need to save the file that was edited in home directory
[21:37] <scott-work> but to update the package in the repos i need to have a diff file of just the changes
[21:38] <scott-work> the diff file will be patched to the package in the repos
[21:40] <ailo> I guess, the default file will be intact somewhere in /usr/share/* don't remember where it is. Then, after adding the indicator, just make a diff between that and the file in home directory, wherever it was. Don't know if that will work, cause I don't know if something more is added to the file in home, like some additional info.
[21:45] <ailo> scott-work, No, it doesn't seem to work, I think.
[21:47] <ailo> scott-work, http://manpages.ubuntu.com/manpages/maverick/man8/update-gconf-defaults.8.html
[21:47] <ailo> I was looking for some tools to generate default gconf settings
[21:49] <ailo> Anyway, I have to sleep..
[21:50] <scott-work> goodnight and thanks
[21:51] <scott-work> heh, that link reminds me of the install file under /debian
[21:51] <scott-work> ubuntustudio-panel-settings.entries /usr/share/gconf/schemas/
[21:51] <scott-work> it installs that entry file to that directory
[22:59] <TheMuso> c


[09:09] <frankban> not sure if I was disconnected earlier
[09:09] <frankban> morning fwereade: I am investigating the path to remove store code from juju-core, in order to create its own git repo. given http://pastebin.ubuntu.com/7492017/ , it seems we have to do that in many incremental steps. at first sight, it seems the utils and testing packages should be migrated first, then schema, then charm and finally store. What do you think? I am not sure how this kind of work has been handled be
[09:09] <frankban> fore. I imagine something like 1) lock the package (email?), 2) create the git repo and 3) update core (remove the package, fix imports, fix dependencies file).
[09:37] <fwereade> frankban, it's a bit of a perfect storm of cleaners, decorators, furniture deliveries and cleaners here atm, and I'm just making a sandwich; I will be with you shortly
[09:37] <frankban> fwereade: :-) np and thank you
[10:25] <fwereade> frankban, ok, sorry, I think I can work again now
[10:25] <fwereade> frankban, are you free for a g+?
[10:25] <frankban> fwereade: cool
[10:26] <frankban> fwereade: sure
[10:27] <fwereade> frankban, https://plus.google.com/hangouts/_/g5z557wyte4tlcapwfeqetgyzya?hl=en
[10:28] <frankban> fwereade: This party is over... https://plus.google.com/hangouts/_/gusnuo5mlb37av6rppczm72heea?hl=en ?
[10:29] <fwereade> frankban, I'm the first one there apparently
[11:36] <rick_h_> frankban: you guys make good progress there?
[11:36] <frankban> rick_h_: yes, I'll send an email about current state
[11:37] <rick_h_> frankban: awesome thanks
[11:46] <jcsackett> rick_h_, frankban: can either of you take a look at https://github.com/juju/juju-gui/pull/330
[11:48] <rick_h_> jcsackett: sure thing, I can in a couple of min
[11:49] <jcsackett> rick_h_: thanks.
[11:52] <rick_h_> jcsackett: can you peek at huw's again this morning in trade?
[11:55] <jcsackett> rick_h_: already looking.
[11:59]  * rick_h_ needs coffee for review time
[12:00] <bac> morning
[12:02] <frankban> rick_h_: email sent
[12:03]  * frankban lunches
[12:07] <jcsackett> rick_h_: don't know if you started looking at mine; there was a merge conflict with develop that i've resolved.
[12:07] <rick_h_> jcsackett: awesome
[12:20] <jcsackett> rick_h_: what time does huw start?
[12:21] <rick_h_> jcsackett: he's usually around 7pm or so
[12:21] <jcsackett> ok. i have questions about his branch that keep me from just stamping it, but don't want to block him--i'll try to be on IRC for a bit then.
[12:22] <jcsackett> we need another JS coder on the team in his timezone. :p
[12:22] <rick_h_> jcsackett: sounds good
[12:23] <rick_h_> heh, well I can help look as well if needed. I'll be around
[12:35] <redir> bac, rick_h_, jcsackett review s'il vous plait http://bit.ly/1h3Sw5i :)
[12:36] <redir> if someone has time
[12:36] <bac> redir: already on it
[12:37] <redir> bac: great. I just pushed up a commit trimming out ununsed helper bits in the tests
[12:38] <bac> doh
[12:38] <bac> ok
[13:09] <rick_h_> frankban: replied and passed along with one request to pass that through the juju-dev list.
[13:10] <rick_h_> frankban: I've got a card of size 10 "Pull our deps from core into sharable libraries" to use to create cards for starting that work
[13:10] <rick_h_> frankban: I'll create a doc from your email and we can start to create work items out of it from there.
[13:11] <bac> redir: review done, and approved with changes.  please be sure to see the in-line comments, which may be a bit funky since you landed another rev.  there is a drop down to show the different diffs.
[13:11] <bac> QA was good too
[13:12] <redir> bac just reading through it in email. updates forthcoming.
[13:12] <redir> think i have a couple unused imports too.
[13:12] <bac> redir: lint should catch those
[13:12] <redir> it did, but I forgot about them in the 5 minutes it took to run the tests...:(
[13:15] <bac> redir: that is one benefit of lbox, it runs 'make check' before letting you proceed.
[13:17] <redir> so maybe I can use it
[13:17] <redir> as @not canonical
[13:17] <redir> I see wayne using it and asked him. He said he was using non canonical account to do it:(
[13:18] <jcsackett> bac: did we just do a deploy of charmworld on production?
[13:19] <bac> jcsackett: i hope not
[13:19]  * redir blinks
[13:19] <bac> jcsackett: no, still on 508 http://manage.jujucharms.com/heartbeat
[13:19] <jcsackett> bac: mbruzek is reporting intermittent oddities with the API. he looked for manage.jujucharms.com/api/3/charm/precise/openerp-server, and got no data. but it's showing data now.
[13:20] <redir> http://manage.jujucharms.com/heartbeat is showing r508
[13:20] <bac> jcsackett: we may be having data center problems.  i'm getting intermittent failures from the LP api
[13:20] <jcsackett> bac: ok.
[13:20] <bac> i shall mozy over to webops and mention it
[13:20] <jcsackett> bac: oh, huh, i think a server went down? start time on heartbeat is 2 minutes ago.
[13:22] <bac> jcsackett: hmm.  i wonder if charmworld hit the LP API failure and it threw an exception causing it to restart
[13:23] <bac> actually, no, it should only affect the ingest process
[13:23] <frankban> rick_h_: thanks for creating the google doc and the card. juju-dev ml is internal, right?
[13:24] <rick_h_> frankban: no, i think it's public. I don't think there's anything we need to worry about in this plan/doc though or am I missing it?
[13:24] <redir> as long as it doesn't sing the blues
[13:27] <bac> jcsackett: actually i see m.j.c and qa.m.j.c servers restarting a lot.  webops says LP is undergoing scheduled maint which has pushed the DB load very high.
[13:27] <jcsackett> interesting.
[13:27] <bac> i'll poke around QA and see if the logs say anything useful
[13:27] <frankban> redir, rick_h_: we should also investigate a way to migrate a partial bzr history to git
[13:28] <bac> jcsackett: do you have access to QA on canonistack?
[13:28] <rick_h_> frankban: yea, they've pulled out some other tools. Make that part of the email?
[13:28] <jcsackett> bac: i do not.
[13:28] <rick_h_> frankban: I guess loggo/errgo or whatever was out then in and then out again. Maybe they don't have experience with it
[13:28] <bac> jcsackett: oh.  you should grab the staging tools and get set up, if you want.  i can walk you through it.
[13:29] <jcsackett> bac: perhaps this afternoon? i don't believe we're blocking anyone now on investigating the charmworld goof.
[13:37] <rick_h_> frankban: for each of these migrate cards. I'm going to set them at a size of 3, but we'll have to get a feel for how long it takes. So don't worry about it too much.
[13:37] <rick_h_> frankban: I figure after a couple we'll have a better idea
[13:37] <frankban> rick_h_: sounds good
[13:38] <bac> jcsackett: sure, whenever
[13:41] <jcsackett> bac: cool.
[13:41] <rick_h_> redir: so let's get you in the loop on the deps and maybe you can help with them this week.
[13:42] <rick_h_> heh, kanban cards update, lots more than the budgeted 10, wheeee
[13:42] <jcsackett> jujugui: can i get a review of https://github.com/juju/juju-gui/pull/330
[13:42] <jcsackett> oops, old link.
[13:42] <kadams54> Looking…
[13:42] <rick_h_> heh, yea merged :P
[13:42] <jcsackett> kadams54: https://github.com/juju/juju-gui/pull/332
[13:42] <jcsackett> there's the new link.
[13:43] <jcsackett> sorry. :p
[13:43] <kadams54> np
[13:47] <kadams54> jcsackett: looks good.
[13:47] <jcsackett> kadams54: thanks. :)
[13:55] <rick_h_> kadams54: how goes, how's your test card? I went to look at it yesterday but didn't see the new revisions/changes.
[13:55] <rick_h_> kadams54: is that wip or need a review?
[13:57] <kadams54> WIP - hatch and I need to chat about how to handle data-ids before it'll be ready for a review/merge. Currently tracking down/cleaning up some leaky tests in that whole test suite.
[13:58] <rick_h_> kadams54: gotcha ok
[13:58] <rick_h_> Makyo: can I ask you the favor of setting up the JS code question for the interview this afternoon please?
[13:59] <rick_h_> jcsackett: lint issues in test run fyi
[13:59] <jcsackett> rick_h_: ah, thanks.
[14:00] <hatch> kadams54 wasssssuuupppp?
[14:01] <kadams54> hatch: chat now or after standup?
[14:01] <hatch> a few mins, just going to move into the office
[14:05] <hatch__> kadams54 https://plus.google.com/hangouts/_/g7is4cqz7uzgb4wawoc6n75yaia?hl=en
[14:20] <redir> bac, wanna look at http://bazaar.launchpad.net/~reedobrien/charmworld/es-migration/revision/517
[14:20] <redir> need anything else before marking approved?
[14:20] <rick_h_> redir: see PM please
[14:27]  * rick_h_ takes a quick walk the dog break
[14:32] <bac> redir: looks good
[14:32] <redir> bac: tx marking as approved.
[14:32] <bac> cool
[14:33] <bac> redir: let's see if it gets deployed to qa by itself.  i suspect not.
[14:35] <redir> bac because?
[14:35] <bac> redir: b/c jenkins lander is a lazy bum
[14:39] <redir> mmm
[14:44] <hatch> holy so many emails batman
[14:50] <jcsackett> jujugui call in 10.
[14:51] <jcsackett> rick_h_: talk post standup about pyramid-y stuff?
[14:51] <bac> redir: you see my msgs in that other channel?
[14:52] <rick_h_> jcsackett: souds good
[14:54] <hatch> curious, why didn't we choose twisted or tornado?
[14:54] <kadams54> frankban: running into a problem where test code is causing problems here: https://github.com/juju/juju-gui/blob/develop/app/models/models.js#L712
[14:54] <kadams54> The test code passes in a machine ID of 0
[14:55] <kadams54> And the function returns the list of unplaced units, rather than the list of units associated with machine 0.
[14:55] <hatch> in my research the hype machine likes tornado it seems
[14:56] <hatch> of course popularity !== best :)
[14:56] <rick_h_> hatch: tornado is newer, smaller, more web centric
[14:56] <kadams54> The hype machine also liked Jersey Shore
[14:56] <rick_h_> hatch: and it came from facebook, so it gets social media bonus points
[14:56] <redir> bac which channel
[14:56] <rick_h_> redir: private channel
[14:57] <frankban> kadams54: I'll take a look, FWIW a machine id should always be a string
[14:57] <frankban> kadams54: so filterByMachine('0')
[14:57] <kadams54> Ah yes, I'll fix that in the test code…
[14:58] <kadams54> And tests pass! Yay.
[14:59] <rick_h_> yay!
[14:59] <frankban> :-)
[15:00] <rick_h_> jujugui call in 1, kanban and all that
[15:01] <rick_h_> jcsackett: ^
[15:01] <jcsackett> jumping in now.
[15:13] <hatch> lol
[15:13] <hatch> when all else fails, kill the tab
[15:13] <rick_h_> lol
[15:15] <Makyo> rick_h_, http://collabedit.com/h4nym
[15:15] <rick_h_> ty Makyo
[15:16] <hatch> binary yo!
[15:22] <jcsackett> rick_h_: looks like forking a private remains private.
[15:22] <jcsackett> so we can delete testing private and have ourselves a lovely time.
[15:22] <rick_h_> jcsackett: wrong channel bro
[15:22] <rick_h_> :)
[15:23] <jcsackett> bloody hell.
[15:23] <hatch> lol
[15:23] <hatch> at least it wasn't a key or anything :)
[15:23] <rick_h_> please take my password kthx!
[15:24]  * jcsackett briefly contemplates the old "irc makes your password *****" joke
[15:24] <hatch> frankban so I'm looking at calling env.add_unit() instead of placeUnit() but the add_unit call creates a new unit which requires us deleting the one already created for the unplaced-unit
[15:25] <rick_h_> you've got to wrap it in <password></password> tags for that to work
[15:25] <hatch> lol
[15:25] <rick_h_> and only works for html enabled irc readers
[15:26] <hatch> frankban and manually deleting the old unit doesn't follow the same pattern for every other unplaced unit interaction....which I was trying to avoid
[15:26] <frankban> hatch: ok, let me look at the placeUnit code
[15:28] <hatch> frankban https://gist.github.com/d1b7a1250b148a6f7051
[15:28] <hatch> this is the diff of what I've got...but it doesn't feel right either because it's the only place which manually modifies the records' command
[15:30] <frankban> hatch: that seems fine to me: if the machine does not exist, we register the corresponding addMachines parent so that the record can be updated later. Otherwise we update the record right now
[15:31] <frankban> hatch: there are already many places where records are mutated
[15:32] <hatch> frankban well those other places are internal to the 'lazy' commands
[15:32] <hatch> I'm concerned that this ecs code is doing a lot of 'magic' and will be very hard to follow for the 'uninitiated'
[15:33] <hatch> this will be like our own shibboleth lol
[15:33] <frankban> hatch: lol
[15:34]  * frankban adds an irc beep for "shibboleth"
[15:34] <hatch> ok I'll continue down this path and once we are close to being done with the ecs we can figure out how to make it easier to follow for others
[15:34] <hatch> lol
[15:34] <hatch> such a good word
[15:34] <kadams54> jcsackett, rick_h_ : is there any more work being done on improving tests for machines?
[15:35] <jcsackett> kadams54: the only thing left is my functional test branch, which is only in the containers column describe block.
[15:35] <jcsackett> kadams54: at least insofar as active work.
[15:35] <kadams54> OK
[15:35] <kadams54> Some of the new tests around machines deal with functions that don't exist any more in my branch :-\
[15:36] <jcsackett> kadams54: kill 'em then.
[15:36] <frankban> hatch: I see two possible improvement paths: short term, we should document the ecs framework, so that those things sound less magic. long term, we can investigate other solutions, like automatically generating the changeset from the ghost models in our database, e.g. we have these ghost entities, make them real
[15:36] <jcsackett> as long as what's replaced things is covered.
[15:37] <hatch> frankban yeah we are going to need to do the ghost stuff fairly soon when we have to update the inspector to represent the changes made in the ECS
[15:37] <frankban> cool
[15:38] <kadams54> jcsackett: I think we may have coverage out the whazoo :-)
[15:40] <jcsackett> kadams54: that was my hope.
[15:40] <jcsackett> let this be a shining beacon from which we begin improving coverage elsewhere.
[15:47] <hatch> bac the non-promoted juju-gui charm is in the 'popular' list now
[15:47] <hatch> we probably shouldn't promote that one over the promoted version
[15:50] <frankban> hatch, bac: uhm, it seems the recommended juju-gui cannot be found: https://jujucharms.com/sidebar/search/?text=juju-gui
[15:50] <bac> hatch: i'm looking to see what you're talking about
[15:51] <bac> hatch: the link frankban posted has none that are under Recommended
[15:52] <hatch> hmm, now I can't reproduce it. bac  under 'popular' the first result was the juju-gui but one that wasn't promulgated
[15:52] <hatch> it was the juju-gui user one
[15:53] <hatch> so where is the real one? :)
[15:53] <frankban> it seems the results are being updated while we talk
[15:53] <hatch> oh.... that's odd
[15:53] <hatch> heh
[15:54] <bac> hatch: featured=promulgated.  popular is something else
[15:54] <hatch> bac oh ok....so we are still left with the lack of promulgated juju-gui charm
[15:54] <hatch> unless it's doing some re-indexing or something
[15:55] <bac> hatch: i think so.  i'd work with the charmers to get that done as they manage all of the charm promulgationing
[15:56] <hatch> oh there it is now
[15:56] <hatch> it must have been being updated or something
[15:59] <hatch> sorry to bother you :)
[16:02]  * rick_h_ runs to get lunch between meetings. 30min gap wooo!
[16:05] <hatch> frankban I added a container using app.db.machines.add({id: '0/lxc/0'}) which ends up in the db, when I then place a unit on it, and deploy. Accessing the machine db from the fakebackend.js the machine I added is no longer in the db
[16:05] <hatch> any idea why this would be?
[16:06] <hatch> oh....
[16:06] <hatch> app.db.machines and this.db.machines are different db's
[16:08] <frankban> hatch: yes, the fakebackend should simulate incoming data from the watcher
[16:08] <frankban> something about changes IIRC
[16:09] <hatch> yeah ok - I was just testing the new placeunit and ran into this. So for testing I'm just going to make fakebackend accessible on the app instance
[16:09] <hatch> so I can add to both db's
[16:10] <hatch> nice, that worked
[16:11] <hatch> bug....fixed
[16:12] <frankban> \o/
[16:13] <hatch> oh yeah there are no placeUnit tests
[16:13] <hatch> lol damn
[16:26] <hatch> frankban could you do me a favour and write a more detailed "why" comment for https://github.com/juju/juju-gui/blob/develop/app/utils/environment-change-set.js#L582-L584 so I can include it in this branch - I'm not 100% clear on it myself
[16:30] <frankban> hatch: when placeUnit is called, the unit could have been already placed to a ghost machine. In that case the corresponding addMachines parent has been set to the addUnit record. When we place the unit again, that parent is no longer relevant and must be removed. At this point either the unit is re-placed to a ghost, in which case a new parent is added, or an existing machine will host the unit, in which case we do
[16:30] <frankban> n't need a parent at all
[16:31] <hatch> thanks that REALLY clears it up :) I'll add that comment to the code
[16:31] <rick_h_> hatch: kadams54 Makyo call time, https://docs.google.com/a/canonical.com/document/d/1mXy66SH05B1U-E_vxGDP_Ig4Ez50VvsmZ7sMW2jiLSI/edit is the doc
[17:20] <rick_h_> hatch: come back
[17:20] <rick_h_> you can't leave us yet :P
[17:28] <hatch> rick_h_ for my exploratory day I filed a bug....not sure how the heck this one happened heh
[17:28] <rick_h_>  hatch cool, saw it in my email but not looked at it yet
[17:29] <rick_h_> will triage and add a card shortly and thanks for running with QA day
[17:29] <rick_h_> I forgot to bring it up on the standup again
[17:29] <hatch> :)
[17:29]  * rick_h_ ponders adding a non-moving card for qa on the board
[18:00] <bac> hi jcsackett, got a sec?
[18:02] <bac> rick_h_: heads up, manage.j.c is restarting the server every few minutes and i've been trying to find out why.  also the charmworld lander cannot update qa.mjc and i cannot use juju to communicate with it, so it may need to be torn down and redeployed.
[18:03] <rick_h_> bac: ugh and double ugh. Thanks for the heads up. Let me know if there's something we can do to help debug or anything.
[18:14] <bac> oh i'm going to miss canonicaladmin...
[18:14] <rick_h_> lol
[18:14] <rick_h_> I feel like we should be throwing a party
[18:15] <rick_h_> though I guess we've not seen the new system yet
[18:15] <rick_h_> and I guess expenses will still live on canonicaladmin
[18:15] <rick_h_> which is probably the worst part of it
[18:15] <bac> oh, i misread that part.
[18:16] <hatch> yeah I'm curious as to the advantage for us now having to use two systems
[18:16] <bac> hatch: twice the quirks and work-arounds to remember
[18:16] <rick_h_> well hopefully I can more easily see the filed time off of the team
[18:16] <rick_h_> that's a pita to do every 2wk cycle
[18:16] <hatch> lol
[18:16] <rick_h_> woot
[18:16] <hatch> rick_h_ yeah that would be nice
[18:18] <hatch> I don't think i've ever used hr software that wasn't a total pile
[18:18] <hatch> here is to hoping this one bucks the trend
[18:26] <kadams54> hatch: https://github.com/juju/juju-gui/pull/325 is ready for QA
[18:26] <kadams54> hatch: If you're interested, of course :-)
[18:28] <hatch> oh you're so thoughtful :)
[18:28] <hatch> I can do it but I'd like to get these placeUnit tests done first
[18:28] <hatch> so i'll leave it up for grabs until then
[18:29] <hatch> for some reason I can't capture something which throws :/
[18:30] <bac> ugh, tornado warning.  you should get hurricanes or tornadoes but not both.
[18:30] <rick_h_> hah, "nasty wind-weather your way"
[18:30] <rick_h_> problem solved, it's all in the marketing
[18:31] <kadams54> guihelp: Looking for QA on https://github.com/juju/juju-gui/pull/325
[18:35] <bac> hey rick_h_ it looks like you added the beaker support to charmworld.  you have any recollection?
[18:35] <rick_h_> bac: yep, kindof
[18:35] <bac> rick_h_: specifically, app-exception.log fills up with warnings that mongo already exists when beaker init is called.  it looks like the stanza in setup.py for beaker may be causing us to try to load the namespace twice.
[18:35] <rick_h_> bac: it does the session management stuff
[18:36] <rick_h_> bac: hmm, do we store the beaker session in mongo or just use filed backed?
[18:36] <bac> mongo
[18:36] <rick_h_> I'd switch to just file based and drop mongo?
[18:36] <rick_h_> traffic isn't nearly high enough to deal with it tbh
[18:37] <rick_h_> http://beaker.readthedocs.org/en/latest/configuration.html
[18:37] <bac> rick_h_: well, i think i'd like to just remove the part from setup.py as it seems to cause trouble.  verifying that it isn't needed.  was curious if you knew that it was needed.
[18:37] <rick_h_> bac: no, without going through it don't recall the setup.py part or what that would be setup that way.
[18:37]  * rick_h_ goes to look at charmworld setup.py
[18:38] <rick_h_> bac: hmm yea. I guess it's one way of configuring beaker. I bet the same config can go into the app __init__.py or something
[18:39] <bac> rick_h_: i think it isn't needed.  with it in, pkg_resources.iter_entry_points('beaker.backends') lists mongo twice.  when i remove it from setup.py it is listed just once.
[18:40] <rick_h_> bac: cool
[18:41] <rick_h_> bac: yea, if it's config'd correctly without the setup.py INI block info then peachy. I bet it was tweaked at some point from some copy/paste instructions
[18:45] <rick_h_> jcsackett: kadams54 can you guys swap reviews?
[18:48] <Makyo> Stepping out for a short appointment
[18:52] <jcsackett> rick_h_: yup.
[18:53] <jcsackett> kadams54: https://github.com/juju/juju-gui/pull/333
[18:54] <jcsackett> bac: as soon as i do this review, i can chat with you if you like. sorry i missed your ping earlier. i was at the mechanics. thought i had pinged in the channel to say so, but evidently not.
[18:54] <kadams54> jcsackett: taking a look
[18:55] <kadams54> jcsackett: I see merge conflicts in my future :-)
[18:55] <kadams54> jcsackett: fortunately minor…
[18:56] <rick_h_> kadams54: just have to race him
[18:56] <rick_h_> the carrot to get up for review fast and furious )
[18:57] <kadams54> Au contraire, it's incentive to review his very, very slowly ;-)
[18:59] <jcsackett> yeah, we're in a standoff here.
[18:59] <jcsackett> :p
[19:00] <jcsackett> if we're both being honest though, there's much less to my PR. :p
[19:00] <kadams54> jcsackett: Yup. That's why it's already marked as "LGTM" :-)
[19:00] <kadams54> I did ask that one formatting change be dropped, which will be one less merge conflict for me.
[19:01] <kadams54> ok, gotta pick up kiddos from school. Will be back in 30.
[19:02] <jcsackett> kadams54: i will happily help you have less merge conflicts.
[19:17] <hatch> jujugui looking for a review/QA plz and thx https://github.com/juju/juju-gui/pull/334
[19:19] <hatch> jcsackett I always thought functional tests were unit tests and integration tests were the ones which actually spanned multiple methods
[19:19] <hatch> this is just in reference to your branch, it could just be my terminology fail :)
[19:22] <jcsackett> hatch: really? i've always been told: unit = small unit of functionality (method, function), functional = larger test of a components functionality, integration = test of several components working together.
[19:22] <hatch> I suppose that makes more sense :)
[19:22] <hatch> carryon
[19:22] <hatch> hah
[19:22] <jcsackett> the lines blur a bit, to be sure.
[19:23] <hatch> jcsackett I'm looking at kadams branch and I'm wondering about all of these removed tests
[19:23] <hatch> they seem like they should still be there...no?
[19:24] <hatch> specifically the 'can create machine tokens' ones
[19:24] <hatch> maybe I'm missing that it's covered in the new ones he added
[19:25] <jcsackett> hatch: there's no longer an individual renderToken method for machine tokens, b/c the tokens generally always exist.
[19:25] <jcsackett> it's reasonably tested, still, i think.
[19:25] <hatch> ahh ok cool
[19:25] <jcsackett> though i am weeping at the deletion of all the stuff i wrote only days ago.
[19:25] <jcsackett> :p
[19:25] <hatch> rick_h_ any preference on my next card?
[19:25] <hatch> jcsackett haha yeah....that happens :)
[19:27] <rick_h_> hatch: I htink that il card needs to get done
[19:27] <rick_h_> hatch: if you're up for taking it, I have a call in 4min
[19:27] <rick_h_> hatch: but I'd like to go over it before you get started onit
[19:27] <hatch> *caugh caugh* I'm sick, bb after that card is done
[19:27] <hatch> :P
[19:27] <hatch> OH FINE!
[19:27] <hatch> haha, eta on call?
[19:27] <hatch> I can probably start on the bug card first
[19:27] <rick_h_> hatch: interview, 3:30 to 4:30
[19:28] <hatch> ok I'll track down the bug first
[19:28] <rick_h_> hatch: sounds good to me
[19:28] <rick_h_> get something to work on for today and let's start the big whammy tomorrow?
[19:28] <hatch> sure
[19:39] <kadams54> hatch: can you weigh in on https://github.com/juju/juju-gui/pull/325#discussion_r12862040 ?
[19:39] <kadams54> I'm guessing the answer is "yes" but just want to make sure.
[19:40] <hatch> looking
[19:41] <hatch> commented - yes :)
[19:44] <bac> rick_h_, jcsackett: could one of  you sanity check this small change: https://codereview.appspot.com/95480044/
[19:44] <hatch> jujugui was there a change in charmworld recently which would have passed 'juju-gui-90' in the charm url vs 'juju-gui' ?
[19:45] <hatch> I've found the bug/fix in the GUI, I just want to know if this is a bug in charmworld or just a change that we didn't protect against in the gui
[19:45] <bac> hatch: not that i'm aware
[19:45] <redir> hatch: I've never seen those letters before...
[19:45] <hatch> hmm odd...ok I'll fix it in the GUI to be more defensive, wonder how this just started happening heh
[19:45] <hatch> redir :)
[19:46] <hatch> the code that's failing hasn't been touched in 6 months so that's why I'm curious about the chamworld stuff....no biggy though
[19:48] <redir> bac I'd review that for you but don't know if I can or how in googleapps
[19:49] <bac> redir: that's ok.  it's more archeology than code review
[19:50] <redir> hatch: 508 is running on prod. there was some restart biz this morning. were there more details about that bac?
[19:51] <redir> from webops
[19:51] <hatch> redir this was in relation to the data being returned from charmworld api calls
[19:51] <hatch> so a restart woudln't make any difference
[19:52] <bac> redir: not yet.  i got log files but saw nothing conclusive
[19:56] <redir> hatch: k. the ngrams stuff I did is in 509 and 512 which isn't in production yet.
[19:57] <rick_h_> hatch: it must be something as it didn't do it without the flags
[19:57] <rick_h_> hatch: so seems like it must be something we changed recently in the GUI
[19:58] <rick_h_> bac: did you get your review you need?
[19:58] <rick_h_> hatch: my thing got done early, got time to chat?
[19:58] <bac> rick_h_: no.  it is just about the beaker stuff.
[19:58] <hatch> yeah sure - one min, going to get the dogs in
[19:58] <rick_h_> bac: LGTM
[19:58] <rick_h_> hatch: k, shoot me a link please
[19:59] <jcsackett> bac looking now.
[19:59] <hatch> https://plus.google.com/hangouts/_/g3qq5xtbryxutddyon5gstiqsea?hl=en
[19:59] <hatch> ^ rick_h_
[19:59] <jcsackett> oh, nm, i see rick_h_ looked.
[20:03] <jcsackett> bac: do you still need to chat re:charmworld?
[20:04] <bac> jcsackett: no, thanks.
[20:04] <bac> jcsackett: i may need to bug you later, though, if i can't figure out why the server is restarting every three minutes
[20:06] <jcsackett> bac: i will try to be more available, should that happen. can you pass me the link for staging tools? i can set that back up on my own (did it once before).
[20:09] <bac> jcsackett: bzr+ssh://bazaar.launchpad.net/~ce-orange-squad/charmworld/staging-tools
[20:09] <jcsackett> bac: thanks.
[20:09] <bac> jcsackett: note that juju now requires the sharing of the jenv file used to bootstrap a system in order to collaborate on it
[20:10] <bac> jcsackett: so those jenv files are a part of this branch.
[20:10] <bac> jcsackett: whenever someone uses these tools to bootstrap a new system, and the jenv changes, it needs to be checked in and pushed back to LP
[20:10] <jcsackett> ok.
[20:12] <bac> jcsackett: i think a lot of this could be replaced with a bundle.  it is on my todo list.
[20:34]  * rick_h_ runs away to watch the boy do tumbling bits and such, c-ya'll later
[20:34] <hatch> anyone able to do review/qa?
[20:34] <hatch> jujugui
[20:34] <hatch> cya rick_h_
[20:37] <redir> later rick_h_
[20:50] <hatch> jujugui looking for another review/qa https://github.com/juju/juju-gui/pull/335 this one is an easy one
[20:51] <bac> jcsackett: do you know where the command jnova is packaged?
[20:54] <jcsackett> bac: jnova is script in staging-tools
[20:55] <bac> ohhh
[20:55] <bac> jcsackett: i did it through the dashboard.
[20:55] <bac> jcsackett: i changed the doc to have it as ./jnova as a hint
[20:56] <jcsackett> bac: good plan.
[21:22] <bac> got charmworld lander running again.  man, that process needs some devops love.
[21:22]  * bac walks dog.  bbiab to check
[21:37] <hatch> man I wish I could come up with a better name than Editorial
[21:37] <hatch> ^ jcsackett  :P
[21:40] <jcsackett> hatch: agreed.
[21:40] <hatch> I'm thinking Curated
[21:41] <hatch> so we have a Search list and a Curated list
[21:42] <jcsackett> eh, i dunno--it's not really curated given it shows any crap that's new.
[21:43] <hatch> well it has promoted, popular, new
[21:43] <hatch> those are curated lists....even if they are curated by a machine :)
[22:22] <jcsackett> hatch: fair.
[22:23] <bac> curated >> editorial
[22:24] <bac> select?
[22:24] <bac> prime
[22:24] <hatch> I'm rewriting the charmbrowser code so it's been changed to curated
[22:24] <hatch> :)
[22:24] <hatch> mohohahaha
[22:24] <bac> if only there were a big book that listed like words
[22:26] <hatch> I tried that hah, curated and editorial are no where near eachother in the graph :)
[22:39] <bac> huh San Juan is having its first barcamp.  is that still a thing?
[22:42] <hatch> OOooo this is a new error: Uncaught TypeError: Cannot read property '_yuiaop' of undefined
[22:42] <hatch> bac heh, we have two of those a year
[22:43] <hatch> I always speak at them, great events
[22:43] <bac> hatch: yeah, i went to the original ones in raleigh and i've been to one in saigon.  but not for years.
[22:44] <hatch> ugh I hate widget child/parent stuff so much magic, impossible to debug
[22:44] <bac> the first one they made me combine my session with the guy from redhat talking about git.  :(
[22:45] <bac> s/session/bzr session/
[22:45] <bac> hatch: but it was at RedHat HQ and i distributed Ubuntu CDs.  that was fun.
[22:46] <hatch> lol nice
[22:52] <rick_h_> hatch: it's why I just went with charmresults
[22:52] <rick_h_> hatch: nice agnostic name
[22:52] <rick_h_> though I have to say, editorial is darn easy to grep for
[22:53] <hatch> I have....curated....rendering properly now :)
[22:53] <rick_h_> lol
[22:53] <hatch> shaved about 70 loc's
[22:53] <hatch> so that's nice
[22:53] <rick_h_> wheee
[22:54] <hatch> how did rolling go?
[22:55] <rick_h_> he rolled, and did swigingin from a monkey bar, and got a ribbon
[22:56] <hatch> nice
[22:56] <hatch> he'll be rockin splits over that flexy spinny bar in no time
[22:56] <rick_h_> hah
[23:01] <huwshimi> Morning
[23:02] <hatch> greetings earthling
[23:02] <rick_h_> huwshimi: morning
[23:06] <jcsackett> huwshimi: morning.
[23:06] <rick_h_> huwshimi: jcsackett is on the hunt for you about your branch
[23:06] <rick_h_> doh, too slow to warn you
[23:06] <jcsackett> :p
[23:06] <jcsackett> nothing bad, just want to chat fast so you're not blocked, huwshimi
[23:07] <huwshimi> jcsackett: OK, I'll take a loook
[23:11] <huwshimi> jcsackett: So the table of changes needs to appear when you click "View the complete change log"?
[23:13] <huwshimi> Is that the issue?
[23:14] <jcsackett> huwshimi: yes; and it's not so much an issue, as given this is now moved out of that summary panel *and* both templates have their own headers, if you had any notion how to move forward on that.
[23:14] <jcsackett> also, there's that closing table tag with no opening one, and i'm just curious where it's opened. it clearly works, but it confuses me. :p
[23:14] <jcsackett> oh, you replied to that.
[23:15] <Makyo> Hate when hard problems lead to a tiny diff.  It's like, "I promise this was REALLY BROKEN."
[23:15] <jcsackett> huwshimi: so the "view complete change log" doesn't have to be dealt with in your branch--yours is absolutely an improvement over what's there now. i'm just touching base to make sure we haven't thrown a stumbling block up for that.
[23:15] <huwshimi> jcsackett: So, the deployer-bar-changes.handlebars could be rendered when we open the change log. The header stuff is outside that template, so we'd just be rendering the list of changes.
[23:16] <jcsackett> huwshimi: is the header stuff out?
[23:16]  * jcsackett may have just completely misread the diff.
[23:16] <huwshimi> jcsackett: The header etc actually remains in deployer-bar.handlebars we just re-render the list of items when the panel is opened.
[23:17] <huwshimi> (no nead to re-render the header)
[23:17] <jcsackett> huwshimi: ah, you're right.
[23:17] <jcsackett> i did misread that.
[23:17] <huwshimi> jcsackett: So this branch actually makes it easer to implement that changelog. Unintentionally :)
[23:17] <huwshimi> jcsackett: I'll do that as a followup.
[23:18] <jcsackett> huwshimi: indeed it does. i'm so glad i was wrong. :)
[23:18] <huwshimi> hehe
[23:18] <jcsackett> huwshimi: then all is well with your branch, and i'll comment accordingly.
[23:18] <jcsackett> huwshimi: have a great day.
[23:19] <jcsackett> everyone else, have a good evening. i'm off for dinner.
[23:19] <huwshimi> jcsackett: Thanks. And thanks for checking in with me.
[23:19] <huwshimi> jcsackett: Have a good evening
[23:19] <jcsackett> huwshimi: thanks. :)
[23:23] <hatch> uh oh...the app breaks under il without mv
[23:24] <hatch> jujugui can someone else try this http://comingsoon.jujucharms.com/:flags:/il/ drag a charm to the canvas....see the notification
[23:24] <kadams54> "Could not add the requested unit. Server responded with: Service "21985837$" does not exist."
[23:25] <huwshimi> I see the same
[23:25] <hatch> filing... thanks
[23:28] <hatch> and card created
[23:30] <hatch> ok I'm EOD'ng
[23:30] <hatch> cyall
[23:32] <hatch> huwshimi if you're looking for a task I need a review and qa on https://github.com/juju/juju-gui/pull/334
[23:33] <huwshimi> hatch: OK, I'll take a look


[01:04] <davecheney> wallyworld: axw bot is still being a prick
[01:04] <davecheney> did jams' fix to the data race in the api server get fixed ?
[01:04] <wallyworld> sadly yes
[01:04] <wallyworld> i think so
[01:04] <wallyworld> there's 2 mongo races that i think are the cause of the remianing issues
[01:04] <axw> I'll take a look at it this morning
[01:04] <axw> oh
[01:05] <axw> wallyworld: new ones though?
[01:05] <axw> because it wasn't this bad last week
[01:05] <wallyworld> axw: not sure, haven't looked in detail but there's been various changes this week
[01:06] <wallyworld> axw: could you take a look at this first up, it attempts to fix another critical blocking 1.19.4 https://github.com/juju/juju/pull/155
[01:06] <axw> wallyworld: sure, looking
[01:06] <wallyworld> ta
[01:08] <davecheney> wallyworld: haven't been able to land a branch all morning
[01:10] <wallyworld> davecheney: so last week, we had the 2 intermittent mongo failures which only happened every so often. lots has changed this week. stuff has broken :-(
[01:10] <wallyworld> i do think we've got systemic race conditions in our code which no one has really got a handle on
[01:11] <wallyworld> and/or mongo is shit
[01:14] <axw> wallyworld: do you know why the peergrouper is getting an empty set of machines in the first place?
[01:16] <wallyworld> axw: not sure, it's all quite involved, i guessed that it could have been due to stuff initialising and replicaset stuff not being ready (likely during upgrade from non ha to ha env) and timer inside worker triggers publish of machine addresses but they aren't known yet
[01:16] <wallyworld> there are 2 triggers to publish - machine watcher and timer
[01:17] <axw> wallyworld: then I would expect it's just going from empty to empty? hmm. anyway, I'll LGTM because it doesn't make anything worse AFAICT
[01:18] <wallyworld> axw: yes but the watcher won't have fired
[01:20] <wallyworld> my analysis is in bug comment 5, i can't see an other reason for the issue :-(
[01:27] <davecheney> wallyworld: ok, i'll focus on finding those race conditoins
[01:27] <wallyworld> davecheney: we'll look as well
[01:28] <wallyworld> davecheney: the 2 i was aware of were one in bug 1305014 and another inside the apiserver code (not sure of bug off hand)
[01:28] <_mup_> Bug #1305014: panic: Session already closed in TestManageEnviron <intermittent-failure> <test-failure> <juju-core:Triaged by rogpeppe> <https://launchpad.net/bugs/1305014>
[01:33]  * thumper goes to make a coffee
[02:05] <axw> davecheney wallyworld: jam's fix has not landed
[02:05] <axw> may explain why I'm getting panics and the race detector isn't happy with cmd/jujud
[02:05] <wallyworld> oh, bollocks, i thought it had
[02:06] <davecheney> axw: what can I do to help land that today
[02:07] <wallyworld> axw: davecheney the fucking bug was marked as fix committed
[02:07] <wallyworld> hence i thought it had landed
[02:07] <davecheney> wallyworld: yay issue tracking
[02:07] <wallyworld> but github says otherwise
[02:08] <axw> davecheney: merge was attempted and tests failed, could just try again. rogpeppe has made added a remark about the solution being non-ideal
[02:08] <wallyworld> i've hit the "merge" button again
[02:08] <wallyworld> we can fix the non-ideal bit after it lands, we need to get this release out imo
[02:08] <davecheney> seconded
[02:08] <axw> sgtm
[02:10] <axw> trivial review please: https://code.launchpad.net/~axwalk/gwacl/vnet-location-docalignment/+merge/224254
[02:10] <wallyworld> looking
[02:11] <wallyworld> axw: dumb question, how is 2012 more recent than 2013?
[02:12] <axw> wallyworld: "which is actually older than what was in the code."
[02:12] <wallyworld> yeah read that but still don't understand
[02:12] <axw> wallyworld: 2012-whatever is the most recent published version for that API
[02:12] <wallyworld> so we were using an incorrect date?
[02:12] <axw> wallyworld: yeah
[02:12] <wallyworld> ok
[02:13] <axw> I don't think it actually matters, but I'd rather go by the docs
[02:13] <wallyworld> yup
[02:27] <thumper> davecheney: re: https://github.com/juju/juju/pull/156
[02:28] <thumper> davecheney: axw has approved but I have a few questions
[02:28] <thumper> davecheney: just letting you know
[02:29] <davecheney> thumper: sure
[02:29] <davecheney> thumper: i'm not trying to land anything til the race fix lands
[02:31] <thumper> davecheney: done with comments
[02:31] <davecheney> thumper: yup
[02:31] <davecheney> i see your comments
[02:31] <davecheney> i think oyu found one of my TODo's there
[02:31] <davecheney> fwiw, almost all this stuff was just a string slung straight to the api server
[02:32] <davecheney> but I will adjust the signatures to mandate the correct type
[02:32] <davecheney> test 0
[02:32] <davecheney> ... Panic: Couldn't create temporary directory: mkdir /tmp/gocheck-3784560248718450071: file exists (PC=0x41078D)
[02:32] <davecheney> wowo
[02:34] <thumper> haha
[02:34] <thumper> pseudo-random
[02:35] <thumper> davecheney: should it be the actual type or an interface?
[02:35] <thumper> just wondering
[02:35] <davecheney> thumper: i'm thnking the concrete type
[02:35] <thumper> ok
[02:35] <davecheney> we want to say "only machine tags here"
[02:35] <davecheney> or units
[02:35] <davecheney> or whatever
[02:35]  * thumper nods
[02:36] <thumper> This gives the compiler control rather than runtime assertion
[02:36] <thumper> better I think
[02:37] <davecheney> thumper: yup
[02:38] <davecheney> to fix this i'll need to change most of hte places where we have a struct like
[02:38] <davecheney> type Machine struct { tag names.Tag }
[02:38] <davecheney> to
[02:38] <davecheney> type Machine struct { tag names.MachineTag }
[02:38] <davecheney> and this is a good thing
[02:42] <davecheney> thumper: consider yourself nagged for that sprint
[02:42] <davecheney> its < 30 days
[02:42] <thumper> ack
[02:56] <menn0> bodie_: I just finished reviewing 141
[02:57] <menn0> all good from my perspective
[03:10] <davecheney> wallyworld: http://juju-ci.vapour.ws:8080/job/github-merge-juju/252/console
[03:10] <davecheney> what ?
[03:10] <davecheney> tests didn't fail
[03:11] <davecheney> did someone nuke this build ?
[03:11] <wallyworld> davecheney: looks like connection to ec2 instance disappeared half way through
[03:12] <wallyworld> faaaark
[03:12] <wallyworld> retry i guess
[03:12] <bodie_> menn0, good to hear :)
[03:32] <sinzui> wallyworld, the utopic ami expired a few hours ago. I just configured tests to use that to fix on test...maybe i need to check the ami used by git-merge-juju
[03:33] <wallyworld> sinzui: ah, could be it
[03:33] <wallyworld> although i thought we ran trusty
[03:33] <wallyworld> or even precise actually for the tests
[03:33] <wallyworld> yes, i'm sure it's precise
[03:33] <sinzui> wallyworld, yeah, and trusty tests are happy. I will double check
[03:34] <wallyworld> ok, but it's waaaay past your eod
[03:35] <sinzui> wallyworld, oh...
[03:35] <sinzui> wallyworld, I think there is a correlation between git-merge-juju and a number of hung instance from a few hours hours ago. I had to terminate them.
[03:36] <wallyworld> really? oh
[03:36] <wallyworld> maybe you terminated a git-merge-juju one as well?
[03:36] <sinzui> wallyworld, I have request an additional 20 instances.
[03:36] <wallyworld> great
[03:37] <sinzui> Maybe I can also update the tests to switch to hp which is very good now that we addresses the ram instance ratio
[03:38]  * sinzui forces a rebuild
[03:38] <wallyworld> i think that couldn't do any harm
[03:38] <wallyworld> mgz is moving to get a nailed up hp cloud instance working to run the tests
[03:39] <sinzui> I can do that in 30 minutes.
[03:40] <sinzui> I can get slaves and slave helpers up quickly for trusty.
[03:41] <sinzui> I have failed to create a fat 386 to test local deploy. I am pondering the consequences of never testing that 386 local provider works.
[03:41] <wallyworld> i don't think too many people would be using it
[03:42] <sinzui> a surprising number download it from the ppa
[03:42] <wallyworld> once the nailed up instance is there, mgz needs to do a little script tweaking but it should be easy
[03:42] <wallyworld> wow, ok
[03:42] <wallyworld> i386 is so last century
[03:43] <wallyworld> decade maybe
[03:48] <sinzui> wallyworld, https://pastebin.canonical.com/112317/
[03:48] <wallyworld> jeeez, ok
[03:48]  * wallyworld is surprised
[03:49] <sinzui> Indeed. abentley intends to break the numbers down by week to find proper trends is adoption and decline
[03:50] <sinzui> your beta tester numbers are still generating
[03:51] <wallyworld> ok
[03:52] <wallyworld> i'd be interested in seeing those when done
[03:53] <menn0> potentially silly question: are juju controlled machines (specifically state servers) able to SSH between each other? I'm thinking about something that would involve distributing a file to all state servers.
[03:56] <sinzui> menn0, They don't have the private keys
[03:57] <menn0> sinzui: ok thanks. (I think you mean the public keys right?)
[03:57] <sinzui> menn0, they have public keys, that is why juju ssh workd
[03:58] <sinzui> menn0, there isn't a private key on any of the juju machines that would allow an agent to ssh to another machine
[03:58] <menn0> sinzui: got it
[03:58] <menn0> thanks
[03:58]  * menn0 should have just looked in ~/.ssh ...
[03:59] <sinzui> menn0, also, manual provision can happen across networks, so the design is that the agents can all find the state server, but not necessarily the each other
[03:59] <sinzui> juju ci's state server cannot reach the lab, but the 4 machines I provisioned there can reach the state server.
[04:00] <menn0> sinzui: ok that's good to know.
[04:00] <menn0> I'm wanted to get a file generated on one state server to all other state servers
[04:00] <menn0> well that's one design I'm looking at
[04:01] <sinzui> menn0, surely the master state-server is known to all machines. so all machines can ask for a task to pickup the file
[04:03] <sinzui> wallyworld, beta testers https://pastebin.canonical.com/112318/
[04:03] <menn0> sinzui: right, so you're thinking: a state server generates the file, tells the master to come and get it which it does, and then pushes it out to all other state servers.
[04:04] <sinzui> menn0, I think that is possible
[04:04] <menn0> that could work
[04:04] <sinzui> menn0, My experience is from observation. I really don't know how juju works.
[04:05] <wallyworld> 1.11.2 was big
[04:05] <menn0> sinzui: alternatively I think I can make this work by adding extending the API a little...
[04:05] <sinzui> on the other hand, I have done the neigh impossible because I didn't read the code http://curtis.hovey.name/2014/06/10/building-trans-cloud-environments-with-juju/
[04:07] <menn0> sinzui: :)  thanks for your thoughts. you've nudged me in the right direction.
[04:11] <sinzui> wallyworld, It you stare at the 1.19.x numbers you can see the transition from precise users to trusty users.
[04:11]  * wallyworld needs another coffee before staring at numbers
[04:11] <bodie_> if there's any chance I could get a LGTM on https://github.com/juju/juju/pull/140 it would be quite helpful in moving Actions forward :)
[04:12] <bodie_> (LBTM equally appreciated, though)
[04:17] <wallyworld> bodie_: doesn't look like william's issues with tags and canAccess function have been fixed?
[04:30] <waigani> do we have any helper functions for merging two slices of structs, or should I just do it by hand?
[04:38] <sinzui> wallyworld, Are you getting more information about bad tests from walk-unit-tests-amd64-trusty than for the other unittests?
[04:40] <wallyworld> sinzui: the idea was that we'd try and solve the intermittent failures. that job was useful but with the switch to running the tests on ec2 instead of canonistack/tarmac, the main landing tests have become unreliable instead :-(
[04:40] <wallyworld> we can pass that job until things settle down a bit
[04:40] <wallyworld> pause
[04:40] <sinzui> done
[04:40] <wallyworld> ok, ta
[04:46] <waigani> thumper: I've got a question, hangout? should be quick
[04:46] <thumper> sure
[04:46] <waigani> thumper: https://plus.google.com/hangouts/_/g4rgbccmbg5lchy6qcx7hsny6qa?hl=en
[04:54] <bodie_> wallyworld, I'll have to have a look tomorrow morning, well past eod here, but I think I've addressed tags.  I'm not totally certain what he was looking for with canAccess
[04:54] <bodie_> for the queries from api to apiserver, everything is encapsulated by tags
[04:54] <wallyworld> ok
[04:55] <bodie_> thanks for having a look!  good night all
[04:59] <sinzui> wallyworld, I need to sleep. I am a little concerned that local-upgrade on precise is not passing. maybe there is something in one of these logs if CI continues to fail http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/1414/
[04:59] <wallyworld> ok, thanks, we'll look
[05:39] <davecheney> thumper: wallyworld
[05:39] <davecheney> [LOG] 0:02.374 DEBUG juju.environs.simplestreams fetchData failed for "http://<IP_ADDRESS>:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json": failed to GET object images/streams/v1/index.json from container juju-test-e76bfc6736366a8a
[05:39] <davecheney> caused by: Resource at http://<IP_ADDRESS>:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json not found
[05:40] <davecheney> caused by: request (http://<IP_ADDRESS>:47994/v1/1/juju-test-e76bfc6736366a8a/images/streams/v1/index.json) returned unexpected status: 404; error info: 404 Not Found
[05:40] <davecheney> The resource could not be found.
[05:40] <davecheney> an exmple of the random test failures I get on my machine
[05:41] <wallyworld> i'd need to see the whole log of the filed test and which test it is
[06:01] <wallyworld> axw: if you get a chance at any point, could you look at https://github.com/juju/juju/pull/124 ? william is happy with the implementation but hasn't had time to do a more detailed review
[06:02] <axw> wallyworld: yep, no worries
[06:02] <wallyworld> ta, i have to go out for an hour or so, back later
[06:03] <axw> adios
[06:07] <vladk> dimitern: morning, I started to work on NetworkInterfacesWatcher. I am going to change NetworkInterfaceDoc according to the final draft. Is it ok?
[06:12] <dimitern> vladk, better not i think, because we'll need to add subnets and other things as well
[06:13] <dimitern> vladk, we can still watch ifaces as they are though
[06:19] <vladk> dimitern: so I filter interfaces by machineId, rather than _id?
[06:21] <dimitern> vladk, what do you mean?
[06:22] <dimitern> vladk, i suppose there will be a machine.WatchInterfaces() method in state, returning a StringsWatcher reporting the ids of all interfaces for that machine, as they are created, enabled, disabled, or removed
[06:23] <dimitern> vladk, you do need to add the IsDisabled flag to the iface doc though, but just that - for the other things that need changing, i think we should start with networks and subnets first, then the rest
[06:28] <vladk> dimitern: to read initial set of interfaces I need filter interfaces from the sate by machineId
[06:35] <dimitern> vladk, yes, the interface doc has a machineId - you can use that, right?
[06:35] <vladk> dimitern: yes
[07:59] <TheMue> jam: ping
[08:07] <jam> TheMue: pong
[08:08] <TheMue> jam: seen the latest comments on https://github.com/juju/juju/pull/150 ?
[08:10] <jam> I haven't, I'll go look
[08:11] <TheMue> jam: we have different levels to fix this issue. from low-level inside the jsonrpc package up to the command. I prefer ParseSettingsStrings in charm.Config
[08:12] <jam> TheMue: well, I posted that you might even go for the 'schema' package, which is the stuff that validates already
[08:13] <jam> however, I really don't want us to get too derailed here, this is mostly a passing-by stuff, and we thought things were working differently than they are.
[08:13] <jam> so for now, document that we get \ufffd when you pass in invalid binary data (part of the actual api Client level tests), so that we at least assert the current behavior and know if we change it.
[08:13] <jam> and I can live with whatever other results we get, as it won't be *worse* than what we've lived with forever.
[08:14] <jam> TheMue: does that make sense to you?
[08:17] <TheMue> jam: so you don’t expect cmd.Main to return something else than success? because we simply accept and document this behavior?
[08:18] <TheMue> jam: as the json encoding always „corrects“ the invalid sequence to \ufffd
[08:18] <jam> TheMue: I can live with it, given we've been living with it forever.
[08:18] <jam> TheMue: it isn't what I prefer, but we don't have to fix everything, we have more important things today
[08:19] <TheMue> jam: yes, that have been my thoughts this morning too. we only discovered this issue by thinking about it, but it never happened in reality so far
[08:20] <TheMue> jam: ok, then it makes sense and I’ll change the latest added tests to be a bit more explicit and documenting, so that in case of somebody having to fix this error is having a good base to start from
[08:20] <jam> TheMue: sounds good to me
[08:21] <jam> vladk: just a reminder that you're On-Call-Reviewer today
[08:21] <jam> and TheMue you're OCR tomorrow
[08:21] <TheMue> jam: tested the json marshalling yesterday evening a bit in both directions as well as taking a look into the source. interesting that they removed the error for invalid utf-8 with go 1.2
[08:22] <TheMue> jam: thx for the hint
[08:22] <jam> TheMue: seems like a pretty significant change, but I guess that's what we have to live with.
[08:23] <TheMue> jam: yeah, especially as we use the websocket json codec directly, so we don’t even see the marshalled bytes. they are directly written to the socket
[08:27]  * jam heads to lunch
[08:48] <fwereade> davecheney, ping
[08:55] <axw> fwereade: https://github.com/juju/juju/pull/158  - FYI
[08:55] <fwereade> axw, thanks
[09:01] <davecheney> fwereade: ack
[09:03] <wallyworld> mgz: standup?
[09:09] <fwereade> davecheney, can we have a quick chat about where you're heading with the tags stuff? there's clearly plenty to like but I don't have a clear idea of the plan
[09:09] <davecheney> fwereade: sadly no
[09:09] <davecheney> i am not at home
[09:10] <davecheney> fwereade: you speak to tim frequently
[09:10] <davecheney> he can represent me on this issue
[09:10] <fwereade> davecheney, cool, thanks, I'll chat to him this evening
[09:41] <wwitzel3> morning all
[09:50] <TheMue> wwitzel3: morning
[09:59] <perrito666> morning
[10:19] <TheMue> vladk, jam: (hopefully) final changes https://github.com/juju/juju/pull/150. so please review (again)
[10:36] <wallyworld__> jam: not sure if my "fix" for that agent.conf issue will do any good or not but it's all i could come up with as something to try from reading the code
[10:46] <dimitern> jam, standup?
[12:12]  * fwereade bbiab
[12:33] <perrito666> stumble upon's logo reminds me of something
[12:59] <sinzui> Looks like wallyworld's fix got upgrade broken local precise upgrades
[12:59]  * sinzui reports bug
[13:08] <sinzui> natefinch, jam, fwereade, alexisb : We have a regression cause by the fix for upgrade bug reported yesterday https://bugs.launchpad.net/juju-core/+bug/1334273
[13:08] <_mup_> Bug #1334273: Upgrades of precise localhost fail <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1334273>
[13:08] <alexisb> sinzui, lovely
[13:10] <alexisb> perrito666, wwitzel3, mgz ^^^ you guys available to take a look at this bug
[13:15] <bodie_> morning all
[13:15] <natefinch> wwitzel3: can we push our 1 on 1 to this afternoon?
[13:15] <mgz> alexisb: nothing is jumping out at me from the change or the log in the bug...
[13:19] <alexisb> mgz, well of course it couldn't be obvious that would be waaaay to easy ;)
[13:19] <wwitzel3> natefinch: sure
[13:20] <sinzui> mgz, The stall in the test log. where a single status call takes 10 minutes, then fails the test looks like the issue joyent upgrades had. Wallyworld said the fix was to ensure the state server got a sane list of addresses
[13:22] <mgz> sinzui: so, all the change does is return an error if the publish function is given an empty list
[13:22] <mgz> I don't particularly see how that regresses us... it must be something fun and side-effecty
[13:23] <sinzui> mgz #136 from wallyworld/ignore-empty-machine-addresses
[13:23] <sinzui> mgz, I am speculating...I really don't know
[13:23] <alexisb> sinzui, mgz : does that mean we think that this current bug is a result of joyent shotcomings?
[13:24] <sinzui> alexisb, no. I am just remarking that the fix for yesterdays critical broke another test in a similar way to a bug from last week
[13:25] <sinzui> alexisb, CI loves juju yesterday. I could release something from yesterday as 1.19.4
[13:25] <mgz> sinzui: I don't see that error propogated back up in the logs anywhere either
[13:25] <perrito666> sinzui: github says https://github.com/juju/juju/commit/e01ac93e is a different commit
[13:25] <mgz> which it *should* be if that change actually affected anything
[13:26] <alexisb> sinzui, ok
[13:28] <sinzui> perrito666, I give you the latest data, there have been two broken revisions, I just to give you a log from what fails 15 minutes ago
[13:28] <perrito666> sinzui: I was talking about "With the introduction of e01ac93e "Merge pull request #155 from wallyworld/peergrouper-publish-ignore-empty""
[13:29] <sinzui> perrito666, http://juju-ci.vapour.ws:8080/job/local-upgrade-precise-amd64/ shows all the failed tests over the last 9 hours
[13:29] <sinzui> oops
[13:30] <perrito666> sinzui: as I say, the first failure comes from https://github.com/juju/juju/commit/e01ac93e0cbee312bf19ead78035a78ed2428871
[13:30] <sinzui>  #153 from davecheney/112-state-life-takes-a-tag is the one
[13:30] <perrito666> which is not wallyworld's tag
[13:30] <perrito666> s/tag/rev
[13:31] <sinzui> I updated the bug
[13:31] <perrito666> mgz: you might find more answers there ^
[13:31] <mgz> that does seem a little more promising
[13:32] <alexisb> mgz, is there an obvious fix or is a commit we should consider backing out for this current dev release?
[13:33] <mgz> I think we should consider backing out the change and seeing if that resolves the issue
[13:35] <mgz> this might mean pain for upgrades later, this is an api change
[13:36] <mgz> of sorts
[13:36] <alexisb> mgz, that seems very reasonable to me, sinzui your thoughts?
[13:38] <sinzui> mgz...well, I have the tarball and installer from the previous pass. I can start the release now with fa4f6106
[13:49] <sinzui> mgz, are you preparing to backout the rev to test?
[13:51] <bodie_> anyone happen to know whether fwereade is around?
[14:01] <natefinch> alexisb: I presume I stick around with Gabriel and skip tosca this week?
[14:02] <alexisb> natefinch, yes
[14:45] <sinzui> mgz, perrito666 Is anyone working on bug 1334273 or planning to backout the revision where the error started?
[14:45] <_mup_> Bug #1334273: Upgrades of precise localhost fail <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1334273>
[14:46] <perrito666> I am not, I was under the impression mgz was on it
[14:47] <mgz> sinzui: I can do the backout if we want that
[14:47] <mgz> I'm not completely sure it'll resolve the issue, but seems worth trying
[14:47] <sinzui> mgz we can do that or I release the version before it.
[14:48] <sinzui> mgz, if the test passes after the backing out, then we know the rev is bad, that is all we learn
[14:48] <mgz> sinzui: I guess the question is, do we want the wallyworld change that comes after
[14:49] <mgz> because *that* bug was the blocking cause previously right? (the thing wallyworld's change tries to fix, panic on not having addresses)
[14:49] <sinzui> mgz, yes, if it is independent. wallyworld's change was a hope to fix the other critical
[14:50] <mgz> okay, I'll do the revert, we send tip with that through ci, and release that if it's clean, otherwise release the rev before
[14:50] <mgz> sounds good?
[14:51] <alexisb> mgz, yes sounds good :)
[14:52] <sinzui> mgz, alexisb. I have a lot of anxiety regarding the delay of the devel release. We have more than 50 issues people aren't testing beause we always find one more critical bug. I am inclined to revert to my old behaviour of selecting a blessed revision from the past. In general, a bug that is in older versions of juju does not block a devel release, only recent regressions can block
[14:53] <perrito666> +1
[14:54] <alexisb> sinzui, +1
[14:59] <mgz> can I get a check/stamp on pr160 please
[14:59] <mgz> perrito666: ^
[15:00] <perrito666> natefinch: checking
[15:00] <mgz> >_<
[15:02] <perrito666> aghh sorry, off by one in the kb
[15:02] <perrito666> mgz: check
[15:02] <mgz> okay, sent to bot
[15:02] <wwitzel3> perrito666, natefinch: standup or are you guys busy with the regression?
[15:03] <perrito666> wwitzel3: coming
[15:10] <perrito666> natefinch: ?
[15:10] <natefinch> wwitzel3, perrito666: let's meet this afternoon, sorry, in a virtual sprint with the cloudbase guys until 1-ish
[15:11] <perrito666> cool, I can then use my bw to continue downloading broken sword  :p
[15:23] <mgz> sinzui: revert has landed
[15:33] <mgz> sinzui: the upgrade job is blue, but from before the revert landed anyway.
[15:35] <sinzui> ?
[15:35] <mgz> if I'm looking at the jenkins job correctly, the latest run is blue, but it's from an earlier landing anyway
[15:36] <alexisb> what does blue mean?
[15:36] <mgz> er, it passed. blue dot in the jenkins ui.
[15:36] <sinzui> damn it
[15:38] <sinzui> mgz, a race condition where upgrade won? There were a lot of failures and the rate is much worse than it was before the rev
[15:38] <sinzui> mgz, if the job passes quickly in the next run, then I am convinced that a race condition was avoided
[15:39] <mgz> yeah, makes seeing particular blame on the change much harder
[15:39] <mgz> we have a few more trunk revs to see
[15:49] <bodie_> does anyone know how to retrieve the Unit making the query in an APIserver endpoint?
[15:50] <bodie_> I was passing the calling Unit's tag along with the entity request, but I was told that the UniterAPI has the calling Unit as a member variable
[16:43] <alexisb> jam1, did you want to meet?
[16:43] <jam1> alexisb: yeah, I think so
[16:43] <alexisb> ok, our normal hangout
[17:00] <wwitzel3> natefinch, perrito666, ericsnow: is now good?
[17:01] <ericsnow> wwitzel3: good for me
[17:01] <perrito666> wwitzel3: coming
[17:02] <natefinch> wwitzel3: can we do it in an hour?
[17:02] <perrito666> lol
[17:02] <perrito666> not coming
[17:05] <perrito666> ping me when you are ready
[17:05]  * perrito666 cooks
[17:14] <mgz> sinzui: I've not seen any more runs on the local upgrade job,
[17:15] <mgz> but I've proposed a restore of dave's changes as it doesn't seem to have had an effect
[17:15] <sinzui> mgz, It runs in a later phase
[17:15] <sinzui> mgz, I was just looking if I could force the test to run earlier
[17:16] <sinzui> mgz, were you planning to create a dedicate HP test machine?
[17:17] <mgz> sinzui: yup, though not completely sure about the hp part
[17:17] <sinzui> mgz, HP is good now that we fixed the RAM to instances inbalance
[17:17] <sinzui> mgz, I can provide a slave for you before you wake tomorrow
[17:18] <mgz> do I need a la
[17:18] <mgz> *slave, the unit test script just takes any machine right?
[17:19] <sinzui> mgz, I have been pondering an update to the run-unit* to provision nova instances
[17:19] <mgz> that seems reasonable
[17:19] <sinzui> A slave in our cloudy case means some jobs jump the queue. That helps you
[17:21] <mgz> okay
[17:21] <sinzui> We could choose to run tests on the slave machine. I am going to try that for some tests. I really want to minimise our aws resources...then I thought changing the run* tests to use nova would help me
[17:21] <sinzui> oh
[17:22] <sinzui> mgz, your tests try once fast, then try with -p 2. Should I be doing the same?
[17:22] <sinzui> I try test 4 times, maybe I could your your technique to minimose setups
[17:22] <mgz> sinzui: , ideally not, but I was considering proposing a change to the script to take a flag that does that
[17:47] <bac> i'm getting this error from jenkin-slave even though the file listed exists and is world-readable: 2014-06-25 17:39:24 ERROR juju runner.go:220 worker: exited "upgrader": cannot read tools metadata in tools directory: open /var/lib/juju/tools/<IP_ADDRESS>-trusty-amd64/downloaded-tools.txt: no such file or directory
[17:47] <bac> any ideas?
[18:03] <natefinch> perrito666, ericsnow: standup?
[18:03] <perrito666> natefinch: sure
[18:04] <ericsnow> natefinch: coming
[19:12] <sinzui> I wont be helping a test job to run sooner. My effort lead to a collision in lxc/mongod/jujud on the jenkins master. That 60 minute delay was not faster than letting tests run as they naturally want to
[19:39] <wwitzel3> all the contents of the turkey wrap I was eating for lunch blew out the bottom and the cat got scared, ran through it, and I just finsihed wiping up all the mustard cat prints in my house.
[19:42] <ericsnow> wwitzel3: just imagining that gave me a chuckle :) (hopefully it wasn't too much work)
[19:42] <ericsnow> wwitzel3: I've had the same thing happen with small children
[19:46] <wwitzel3> ericsnow: thankfully, wood floors
[20:08] <thumper> fwereade: around?
[20:08] <thumper> natefinch: o/
[20:08] <natefinch> thumper:
[20:08] <natefinch> howdy
[20:10] <perrito666> ericsnow: do you eat small children? :p
[20:10] <ericsnow> perrito666: only when they misbehave ;)
[20:12] <thumper> natefinch: got time for a quick hangout?
[20:13] <natefinch> yeah
[20:13] <thumper> natefinch: https://plus.google.com/hangouts/_/g44xyud6z5kz3g6p775ebv6cfya?hl=en
[20:36] <jcw4> I'd appreciate a review on https://github.com/juju/names/pull/11
[20:36] <jcw4> Its an ActionTag refactor to hide the implementation details of extracting a UnitTag from an ActionTag
[20:38] <jcw4> thumper: I think it's Thursday in your timezone >:-} ^^
[20:40] <jcw4> Of course it's still Wednesday for mgz ;)
[21:02] <thumper> hi jcw4
[21:02] <thumper> yes, thursday here
[21:02] <jcw4> hi thumper :)
[21:02] <thumper> just after 9am
[21:02] <perrito666> jcw4: there you go, you might want to look for better reviewers than me nevertheles
[21:02] <jcw4> perrito666: your review comments are great
[21:02] <thumper> I'll take a quick look too if you like
[21:03] <jcw4> thumper: excellent, thank you yes
[21:07] <jcw4> thumper: re: exported attributes... I wasn't clear if I could access the internal attributes outside of a method on the internalStruct
[21:08] <jcw4> I'll change it and make sure it still works
[21:08] <thumper> jcw4: all internal attributes are accessable inside the same package
[21:08] <thumper> as long as it is only used inside the names package, you should be fine
[21:08] <jcw4> thumper: perfect
[21:10] <thumper> hmm...
[21:11]  * thumper writes a longer general comment.
[21:13]  * bodie_ grabs his binoculars and tries to catch a peek
[21:15]  * jcw4 counts the minutes, wondering what could cause such long deliberation...
[21:17]  * jcw4 is scared now
[21:18] <fwereade> thumper, hey, I thought there was some meeting in 40 mins? don't seem to be invited any more
[21:18] <thumper> hmm... this is getting longer
[21:18] <thumper> fwereade: yes it is still on
[21:18] <fwereade> thumper, since I seem to be up, I might swing by, it looked important iirc
[21:19] <fwereade> thumper, what was it?
[21:19] <thumper> docker stuff
[21:19] <thumper> the meeting that is
[21:19] <thumper> I'd like to chat with you about identity and multi-env stuff
[21:19] <thumper> but reviewing jcw4's branch just now,
[21:19] <thumper> with you shortly
[21:20] <fwereade> thumper, and I with you, I might be back in a bit or I might do it after that meeting if you'll be free?
[21:20] <thumper> fwereade: standup after the other emeting
[21:20] <thumper> fwereade: how about pre other meeting, in 20 minutes say?
[21:20] <fwereade> thumper, ok, sgtm, see you soon
[21:20] <thumper> ack
[21:25] <thumper> jcw4, bodie_: there you go
[21:25] <thumper> damn the markdown squishing spaces
[21:25] <jcw4> thumper: thanks!
[21:25] <thumper> I should work out how to write code inside comments
[21:26] <jcw4> thumper: excellent suggestion, thanks
[21:26] <thumper> np
[21:27] <jcw4> thumper: I considered it, but thought it might be too radical
[21:27] <jcw4> :)
[21:27] <thumper> nah
[21:27] <jcw4> with your blessing though...
[21:27] <jcw4> :)
[21:27] <thumper> with the upcoming identity work, I'm going to do something similar
[21:27] <thumper> the identity tag will have two parts: username@provider
[21:27] <thumper> so I had thought through all this already :)
[21:28] <jcw4> :)
[21:28] <sinzui> hi wallyworld thumper: I am creating a slave dedicated to running git-merge-juju. If you are contemplating running the unit tests on the same machine, perhaps in lxc, I can give it extra cpus to do that
[21:29] <sinzui> otherwise I will use a medium instance and let the job create other instances to run the tests
[21:29] <perrito666> thumper: ```
[21:29] <thumper> sinzui: um... not sure I have enough context here, do we need to run tests on it?
[21:30] <thumper> perrito666: yes?
[21:30] <perrito666> thumper: ```code```
[21:30] <thumper> perrito666: oh.. cool
[21:30] <thumper> ta
[21:30] <sinzui> thumper, the job currently creates a large ec2 instance to run tests. I was pondering support for hp instances, but maybe the core devs are thinking about running the unit tests in an lxc
[21:31] <thumper> I've not thought about that, but others may have :)
[21:35] <bodie_> I usually use ```go \n $code \n ```
[21:35] <bodie_> you get highlighting by language
[21:35] <bodie_> which is lovely
[21:36] <perrito666> bodie_: good hint
[21:37] <bodie_> perrito666, the other way is still good for inline monospaced code, though
[21:41] <jcw4> bodie_, perrito666 (thumper); for inline monospace you just need `blah blah`  <-- only one tick
[21:42] <thumper> ta
[21:43] <perrito666> ok ppl EOD, ill still hang around bc I have no life
[21:43] <perrito666> but I might not answer a lot since I just purchased the broken sword collection and I intend to play it :p
[21:47] <bodie_> ooo
[21:48] <bodie_> ... to the single backtick ;) though I have been known to have no life as well
[21:54] <jcw4> bodie_: haha, I saw your ooo and thought you were talking about perrito666's broken sword collection
[22:03] <menn0> morning all
[22:06] <waigani> thanks menn0
[22:06] <menn0> waigani: np
[22:06] <menn0> it was top of my inbox and was straightforward :)
[22:07] <waigani> menn0: nice, all my PRs should aim for that!
[22:12] <wallyworld> sinzui: we are contemplating running unit tests in a container so extra cpus would be good
[22:12] <sinzui> :( I just completed my setup of a 4 cpu machine
[22:13] <wallyworld> that's ok
[22:13] <wallyworld> we'll see how it goes
[22:13] <wallyworld> it probably won't be something we can get done immediately
[22:14] <sinzui> wallyworld, I can remake it. if my you are unhappy with the hp/nova provisioning I am adding to tests
[22:15] <wallyworld> sinzui: ok, np. my view is that the immediate goal is to get the landing tests running in a nailed up instance of some sort
[22:16] <sinzui> oh?
[22:16] <wallyworld> containers would simplify isolation, but initially we can just do what we did in tarmac
[22:16] <sinzui> wallyworld, I will restart this then. you and mgz will still have a dedicated slave in an hour
[22:17] <wallyworld> sinzui: did we need a quick chat? seems like we are not quite aligned?
[22:17] <wallyworld> although i have a meeting in 10 minutes
[22:18] <sinzui> wallyworld, for the slave or f*ing  bug 1334273
[22:18] <_mup_> Bug #1334273: Upgrades of precise localhost fail <local-provider> <precise> <regression> <upgrade-juju> <juju-core:Triaged> <https://launchpad.net/bugs/1334273>
[22:20] <bodie_> mornin'
[22:21] <wallyworld> sinzui:  either or both. i'll ping you in an hour if you are still around. i'll also look into that bug. i was hoping it was ok when it started passing again yesterday :-(
[22:25] <sinzui> wallyworld, mgz reverted Dave's commit and CI is playing it now. It has been a sad day. I will *not* try to make the tests run faster because I last effort cause to lxc-based tests to collide
[22:26] <jcw4> thumper, perrito666 I pushed an updated branch for https://github.com/juju/names/pull/11
[22:26] <jcw4> thumper: if you have the time and inclination we can discuss my decision to make func ParseActionId(string) (ActionTag, bool) {} exported
[22:27] <wallyworld> sinzui: ok, i'd still like to still ping you for a chat if you are free and around in an hour
[22:27] <thumper> ok
[22:27] <sinzui> wallyworld, I have no social life
[22:28] <wallyworld> i hear you
[22:28]  * jcw4 takes a mid afternoon break
[22:41] <wallyworld> sinzui: if you are free https://plus.google.com/hangouts/_/gyul7vioiw2m7xnhi2tkfvpsjya
[22:43] <sinzui> wallyworld, Google hates me
[22:43]  * sinzui tries to hack the url
[22:44] <wallyworld> i can send an invite
[22:45] <sinzui> wallyworld, send me an invite, G is the suck
[22:45] <wallyworld> already sent
[22:46] <sinzui> hmm, why is it ringing
[22:48] <wallyworld> sinzui: should i try another hangout?
[22:48] <sinzui> yes, It keeps ringing and you don't hear it
[22:48] <thumper> jcw4: looking now
[22:49] <wallyworld> sinzui: https://plus.google.com/hangouts/_/gzdeubxezekdktt42jeva7ui5ma
[22:49] <sinzui> party's over
[22:49] <thumper> awww...
[22:49] <thumper> no party for sinzui
[22:51] <thumper> jcw4: why have ParseActionId public?  what is the rationale?
[22:58] <jcw4> thumper: in juju/state/action.go the Action type returns a names.Tag
[22:58] <jcw4> thumper: the Action uses ParseActionId to get that tag
[22:59] <jcw4> thumper: the Action doesn't have a reference to a Unit or a UnitTag
[22:59] <thumper> um... no
[22:59] <thumper> jcw4: where in state/action.go?
[22:59] <jcw4> line 84 now...
[22:59] <jcw4> but that code isn't pushed yet
[23:00] <thumper> if it is returning a names.Tag
[23:00] <thumper> you should use a type assertion, not more parsing
[23:00] <thumper> action, ok := (names.ActionTag)(tag)
[23:00]  * thumper thinks
[23:01] <thumper> that's the right syntax isn't it?
[23:01] <jcw4> thumper: it doesn't have a tag, it's just part of the Entity interface to return one
[23:01] <jcw4> action, ok := tag.(names.ActionTag)
[23:01] <thumper> ok.. that
[23:01] <thumper> the action object though should have a unit and a sequence, yes?
[23:02] <jcw4> thumper: yes...ish
[23:02] <jcw4> the unit is encoded in the action Id
[23:02] <thumper> so you return names.NewActionTag(unit, sequence)
[23:02] <jcw4> thumper: so we
[23:02] <thumper> ah...
[23:02] <thumper> really?
[23:03] <jcw4> thumper: it's partially due to watchers
[23:03]  * thumper takes a deep breath
[23:03] <jcw4> we want to watch the actions collection for actions specific to a unit
[23:03] <thumper> right, so the document should have a unit attribute
[23:03] <thumper> and not encoded in some id field
[23:03] <thumper> it may well be encoded in id *as well*
[23:03] <jcw4> thumper: +1
[23:03] <thumper> but it shouldn't be the only source
[23:04] <jcw4> thumper: that's how it is now but I agree
[23:04]  * thumper nods
[23:04]  * thumper realised he was late for the standup
[23:04] <jcw4> thumper: thanks~
[23:08] <jcw4> thumper: at your convenience; you'd prefer an actual unitName on the actionsDoc, over a method that parses it out of the _id?
[23:19] <bodie_> jcw4, thumper -- it appears the UnitTag uses the parsing method as follows -- https://github.com/juju/names/blob/master/unit.go#L53-L63
[23:19] <bodie_> fwiw
[23:19] <thumper> jcw4: ack
[23:24] <bodie_> we have a working ActionEvents filter channel :)
[23:24] <bodie_> going to attempt to push down to the Hook level tomorrow
[23:26] <bodie_> https://github.com/juju/juju/pull/163
[23:26] <bodie_> any review would be very welcome :)
[23:28] <jcw4> thumper: and I've updated https://github.com/juju/names/pull/11
[23:33] <thumper> bodie_: I'm a reviewer today, and will try to get to it :)
[23:39] <jcw4> thumper: given that perrito666 also reviewed, am I clear to merge?
[23:39] <thumper> jcw4: yup
[23:39] <jcw4> thumper: ta
[23:45] <jcw4> thumper: et. al. do you use checklists when doing code reviews?  That was one of the suggestions in the article jam1 linked to on the email list
[23:46] <thumper> bodie_: it seems I'm commenting on other parts of the work in the wrong PR
[23:46] <thumper> jcw4: I have a mental checklist, but nothing formal at this stage
[23:46] <jcw4> maybe we could compile the checklist items into a doc/code-review.md or something
[23:47] <thumper> gym time... back later
[23:47] <jcw4> have fun thumper


[10:45] <Azukawa> Hey friends!
[10:46] <Azukawa> when i start my system, my computer doesnt recognize my soundcard (presonus audiobox) before i unplug and replug the usb
[14:48] <windowsrefund> OvenWerks: thank you
[15:51] <studio-user937> Hello ubuntu studio users, just got into the game. Anyone familiar with using Davinci Resolve and Reaper on Linux Ubuntu Studio or similar software? And most of all: Is anyone using ubuntu Studio for Voice Over recording and editing? All the best, Steffen
[17:41] <studio-user743> Hy, I speak Italian and I have a problem, help me
[18:08] <studio-user743> help me in italy
[19:14] <studio-user385> Hi there
[19:16] <studio-user385> after trying other desktop and theme and such i'd like to return to ubuntu studio default settings.  how to do this?  reinstall studio over the current install?
[19:18] <studio-user385> it's studio 18.10
[19:40] <OvenWerks> studio-user385: the quickest way is to logout to the login screen and use ctl-alt-F1 to get a terminal prompt
[19:41] <OvenWerks> then login there and do rm -r ~/.config/xfce4
[19:42] <OvenWerks> ctl-alt-F7 should put you back at the login screen so log in and you _should_ be back to default
[19:46] <OvenWerks> If you have been playing with the menus via libremenu or alacarte
[19:47] <OvenWerks> then you would also rm -r ~/.config/menus
[19:48] <OvenWerks> maybe also ~/local/share/applications


[00:20] <Ace2016> oh cool, whats in here?
[00:20] <Prefix> lol
[00:20] <Ace2016> LoCo?
[00:21] <Ace2016> what do you guys do in here?
[00:21] <Prefix> yeah its like local teams that advertise ubuntu i think
[00:21] <Flannel> Ace2016: LOcal COmmunity.  Country (and more) based teams that promote Ubuntu
[00:21] <Flannel> !loco
[00:21] <ubotu> Information on Ubuntu Local Community Teams is at https://wiki.ubuntu.com/LoCoTeams
[00:22] <Ace2016> so is ubuntu the distro linked with ubuntu cola?
[00:22]  * Ace2016 doesn't like ubuntu cola
[00:24] <DPic> hello all
[00:26] <Flannel> Ace2016: No
[00:26] <Flannel> Howdy DPic
[00:27] <DPic> what should we talk about at out last meeting before the hardy release?
[00:27] <Ace2016> how can ubuntu cola and ubuntu the distro be not related but still go under the name ubuntu?
[00:27] <Ace2016> DPic: whats new in it
[00:27] <DPic> Ace2016: what's new in hardy?
[00:27] <Ace2016> changes to the installer and wubi
[00:28] <DPic> i mean, what were you asking
[00:28] <Flannel> Ace2016: the same way you can have Apple records and Apple macintosh
[00:29] <Ace2016> still, its kind of messed up, didn't ubuntu trademark its name? or can it not because its a dictionary word
[00:30] <Flannel> Ace2016: There is a trademark, but trademarks only apply to the same realm.  Unless you're implying that drinks are somewhat close to computers
[00:30] <Flannel> Ace2016: http://www.ubuntu.com/aboutus/trademarkpolicy
[00:31] <Ace2016> i still think the link is bad, if people don't like the cola they might shy away from the distro
[00:32] <Prefix> Flannel, thats intresting, I didn't know trademarks were limited to the same type
[00:32] <Ace2016> so in theory i could have a company called microsoft that imports tiny pillows?
[00:32] <DPic> and they might not like the distro if canonical goes after a cola company for their name
[00:32] <Ace2016> can't they ask them to change their name?
[00:34] <Ace2016> http://gizmodo.com/gadgets/software/windows-vista-soft-drink-191357.php
[00:34] <Ace2016> i want that
[00:34] <Flannel> Prefix: Its not "same type" its same realm, or some other noun.  Like two food based products would count, for instance.
[00:35] <Ace2016> omg apple juice in a white can with a grey apple logo, that'd be AWESOME!
[01:19] <DPic> are there people willing to digg this post about getting linux in stores for me?
[07:51] <Syntux> boredandblogging, I'm interested in translating the PR into Arabic