[00:32] <thumper> davecheney: not yet... mostly knowledge transfer for cherylj, although I do have one problem I'm putting off today that would be good to do
[00:34] <cherylj> yessss, give me ALL THE KNOWLEDGE!
[00:38]  * perrito666 wants to know new zealand and thinks thumper should adopt him into his team temporarily
[00:38] <thumper> perrito666: happy to :)
[00:39] <thumper> perrito666: and... Air NZ now doing direct flights to Argentina
[00:39] <thumper> probably has something to do with rugby and the pumas :)
[00:39] <perrito666> thumper: price in bars of gold?
[00:40] <perrito666> last time I checked direct flight was somewhere in the 20k usd :p
[00:40] <thumper> probably going to get cheaper :)
[00:40] <perrito666> sweet
[00:40]  * perrito666 packs cooking gear
[00:43] <anastasiamac> perrito666: cooking gear?..
[00:45] <perrito666> anastasiamac: I am sure there is something nice to cook in new zealand and I dislike cooking without my own knife :p
[00:45] <perrito666> so who is OCR? http://reviews.vapour.ws/r/736/ this inlocks the critical bug
[00:46]  * perrito666 installs go cross compile to avoid having to go for a windows every time
[00:50] <perrito666> waigani: ?
[00:52] <menn0> davecheney: actually, wifi works, it just took an unusually long time connect after suspend. possibly nothing to do with the latest kernel.
[00:53] <perrito666> menn0: I have heard more people complain of things like that with latest kernel
[00:58] <davecheney> thumper: i plan to monopolise mwhudson 's time and grind through as many bugs as we can on our port
[01:02] <davecheney> perrito666: reviewed
[01:02] <davecheney> fix it, then ship it
[01:02] <perrito666> davecheney: td
[01:02] <perrito666> tx
[01:03] <perrito666> aghh I keep forgetting we are in 2015
[01:04] <davecheney> 2015, all year
[01:04] <anastasiamac> perrito666: aah... that would explain high prices on travel to nz
[01:05] <anastasiamac> perrito666: if everyone form argentine brings their ***cough*** cooking knives
[01:05] <anastasiamac> perrito666: u do know that Maories r peaceful pppl? not easily provoked? nor known for their aggression? .. :P
[01:06] <perrito666> anastasiamac: I dont know if you noticed this but there is no call where thumper doesn't have a bruise
[01:06] <thumper> perrito666: ha
[01:08] <anastasiamac> perrito666: rofl
[01:09] <perrito666> can we make the bot oblivious to the diff between - and _ ??
[01:12] <ericsnow> perrito666: I gave you a review on that restore fix
[01:12] <ericsnow> perrito666: is there a reason why you can't just add a restore_windows.go?
[01:13] <perrito666> right now the pressing time
[01:14] <perrito666> ericsnow: anyway, it was faster to stub Restore than to stub all of the methods that fail
[01:16] <wallyworld_> anastasiamac: standup?
[01:16] <perrito666> ericsnow: to be honest I am a bit curious on why do we build any of that in windows
[01:22] <davecheney> thumper: i'm not having anyluck getting someone on #is to look at that RT
[01:34] <davecheney> ericsnow: can you please close/delete this review http://reviews.vapour.ws/r/621/
[01:34] <davecheney> it's dead
[01:34] <ericsnow> davecheney: sure
[01:35] <ericsnow> davecheney: the PR should be closed too
[01:35] <thumper> davecheney: did as much poking as I could...
[01:35] <thumper> menn0: I have a bad feeling about this
[01:35] <menn0> thumper: about what?
[01:36] <thumper> menn0: someone elses upgrade step
[01:36] <thumper> that I don't think it does what they thought it did
[01:36] <thumper> I cribbed someone else's setp
[01:36] <thumper> step
[01:36] <thumper> and did things slightly differently
[01:36] <thumper> particularly about the assertions
[01:36] <thumper> perhaps it is working by side-effect
[01:36]  * thumper shrugs
[01:38] <menn0> thumper: which one?
[01:38] <thumper> menn0: the one in agentconfig.go
[01:38] <thumper> I'm also changing agent config
[01:38] <thumper> but I'm trying to see where it actually gets written to disk
[01:38] <thumper> and it isn't during the step
[01:40] <thumper> hmm... only have a ConfigSetter
[01:40] <thumper> there must be a reason why we don't write in the upgrade steps
[01:40] <menn0> thumper: not sure... looks like it's Dimiter's work
[01:46] <thumper> menn0: ah ha
[01:46] <thumper> menn0: the changes to the agent config are saved at the end of the upgrade steps
[01:46]  * thumper fixes his tests
[01:47] <menn0> thumper: of course.
[01:47] <menn0> thumper: the steps are run inside a ChangeConfig
[01:48] <thumper> yep...
[02:03] <wallyworld_> thumper: core meeting?
[02:03] <wallyworld_> menn0: also?
[02:03] <wallyworld_> davecheney: ditto
[02:21] <perrito666> anastasiamac: I trust you noticed the coloring in thumper 's right eye
[02:21] <thumper> perrito666: you are imagining things
[02:21] <thumper> not been hit for ages
[02:21] <thumper> as I've had to let my shoulder heal
[02:21] <perrito666> thumper: you live in a dangerous place, you have orcs for god sake :p
[02:22] <perrito666> I have senn it on tv
[02:22] <anastasiamac> perrito666: orcs r seasonal
[02:23] <perrito666> lol
[02:23] <anastasiamac> perrito666: only from Boxing Day onwards
[02:55] <thumper> menn0: fyi https://github.com/juju/juju/pull/1417/files
[02:56] <thumper> anyone game? http://reviews.vapour.ws/r/738/
[02:56] <thumper> wow, three pages of diff
[02:57] <thumper> $ git diff master | wc -l
[02:57] <thumper> 1792
[02:57] <thumper> sorry reviewer
[02:57] <thumper> most of that is real necessary
[02:57] <thumper> some of it isn't...
[02:57] <thumper> but most of it is
[03:46] <menn0> thumper: i'm having a look
[04:06] <thumper> menn0: how did you test upgrades before when the upgrade is listed against 1.23.0 and the version is 1.23-alpha1?
[04:11] <thumper> menn0: wondering because I have a running 1.22 environment and I thought I might as well test the upgrade
[04:11] <thumper> but since the upgrade steps are listed against 1.23.0... I don't think they'll run
[04:20] <wallyworld> axw: blake suggested in the maas doc using "/dev/disk/by-id/<foo>" as the block device identifier. I think this would work? Can you comment in the doc to confirm?
[04:21] <menn0> thumper: I changed things a while back so that upgrade steps for the final version are run when you upgrade to any alpha or beta of that version
[04:21] <menn0> thumper: the steps will run
[04:21] <thumper> menn0: oh nice
[04:21] <thumper> menn0: thanks
[04:22] <menn0> thumper: it was wallyworld's suggestion. that way we can test steps while working towards a final version.
[04:22] <thumper> makes sense
[04:26] <menn0> thumper: Fix it and ship it
[04:28] <thumper> menn0: confirmed that starting a new environment has all agents dialing the env uuid version
[04:29] <thumper> menn0: I wish we had a setting that could say "please restart after you have finished upgrading"
[04:30] <thumper> menn0: thanks for the timely review of this massive piece of work
[04:30] <thumper> menn0: but I think it should wait until monday to land
[04:30] <thumper> I still need to test upgrades and a few tweaks from the review, but running out of time today, need to pack
[04:32] <mattyw> davecheney, you still around?
[04:33] <davecheney> mattyw: ping
[04:46] <axw> wallyworld: will do.
[04:46] <wallyworld> ty
[06:42] <wallyworld_> jam: did we ever get a definitive yes/no on whether Openstack is in scope for storage? It's missing completely from the Provider Specific Tactics section of the spec, but is a line item in the "in scope" section
[07:44] <dimitern> jam, axw, PTAL http://reviews.vapour.ws/r/740/ - migrating goamz imports from LP to GH
[07:44]  * dimitern needs to step out for ~1h
[07:46] <axw> dimitern: lgtm
[07:47] <dimitern> axw, thanks!
[07:50] <axw> wallyworld_: can't read your pgpmail
[07:50] <wallyworld_> oh, ffs, stupid thunderbird
[08:02] <axw> wallyworld_: you have question, do you mean for 1:1 tomorrow?
[08:02] <axw> questions*
[08:49] <axw> wallyworld_: if you're around, https://github.com/juju/juju/pull/1420
[08:49] <axw> bot hasn't picked it up for some reason ...
[09:15]  * fwereade out for a bit
[10:03] <dimitern> TheMue, standup?
[10:58] <TheMue> dimitern: morning and sorry for missing the hangout
[10:58] <TheMue> dimitern: third bad night in a row, had to change clothes several times
[10:59] <TheMue> dimitern: at least in the morning hours I found some sleep
[11:00] <TheMue> dimitern: so will now work on the couch reading all the networking information and ask you each time there's something unclear :)
[11:02] <dimitern> TheMue, hey, morning!
[11:02] <dimitern> TheMue, sorry to hear that :/ I hope you'd start feeling better!
[11:03] <dimitern> TheMue, sure - sgtm, there's a lot to read :)
[11:04] <TheMue> dimitern: I hoped so too, I seldom have something for more than one day. so I already canceled being at the Oldenburg English Club today :(
[11:04] <TheMue> dimitern: yeah, I thought that's a good opportunity, have to make the best out of the situation
[11:05] <mgz> perrito666: I have reopened bug 1411024 because the mac client still does not build with your change from last night
[11:05] <mup> Bug #1411024: Win client/agent cannot bug built because of backup deps <ci> <regression> <windows> <juju-core:Triaged by hduran-8> <https://launchpad.net/bugs/1411024>
[11:08] <dimitern> TheMue, +1
[11:08] <dimitern> TheMue, I wish you a quick recovery in any case
[11:09] <dimitern> mgz, ha!@
[11:09] <TheMue> dimitern: thanks, I wish it too. *lol*
[11:09] <dimitern> mgz, I though it might be a problem as in the fix the "_linux" suffix was used, rather than _unix
[11:10] <mgz> dimitern: well, it should be an easy fix to the fix then :)
[11:11] <dimitern> mgz, however I'm not sure whether we support backups on mac os?
[11:13] <mgz> dimitern: I think we clearly don't need to at the moment
[11:13] <mgz> there's probably no real reason it shouldn't work, but we just need the client to build for now :)
[11:14] <dimitern> mgz, yeah, but do you know if it *ever* worked on mac?
[11:14] <dimitern> mgz, because if it didn't the fix is a lot easier
[11:14] <mgz> dimitern: I suspect the old shell script hack would have, if anyone ever tried
[11:15] <mgz> it's certainly not something we signed up for supporting, or have been verifying works
[11:15] <mgz> (the backup/restore test jobs only use the client under ubuntu)
[11:15] <dimitern> mgz, cool, that's all the confirmation I need for now :)
[11:45] <dimitern> mgz, https://github.com/juju/juju/pull/1421 - that's the fix
[11:46] <dimitern> mgz, can you re-run the failing jobs after it lands manually to speed-up the unblocking?
[11:49] <dimitern> can anyone review this please? ^^ axw, fwereade, voidspace, ?
[11:49] <voidspace> dimitern: looking
[11:49] <dimitern> voidspace, ta!
[11:50] <voidspace> dimitern: LGTM
[11:50] <dimitern> for some reason a RB diff wasn't generated
[11:50] <fwereade> dimitern, LGTM too, I'm just a bit too slow
[11:50] <dimitern> voidspace, thank you, setting to merge to unblock trunk
[11:50] <mgz> dimitern: it should go straight through - the build jobs are early on as well
[11:52] <dimitern> mgz, cool!
[12:01] <perrito666> mgz: tx
[12:02] <perrito666> dimitern: and tx to you too
[12:03] <dimitern> perrito666, np, I'm opening a beer tab ;)
[12:03] <perrito666> you won it :p will have to wait until apri though
[12:04] <dimitern> hehe it's closer than you think ;)
[12:05] <perrito666> dimitern: we can go have beer and sausages with sauerkraut
[12:06] <dimitern> perrito666, great idea! we should definitely put it on the agenda
[12:07] <perrito666> well, it is on mine :p
[12:13] <mgz> ci is building the new rev
[12:25] <dimitern> mgz, it would be very useful if on pages like this http://reports.vapour.ws/releases/2232 "Last build" links *both* to the job in jenkins and the console log output (ideally not as application/octet-stream but text/plain, so it can be viewed in the browser directly)
[12:26] <mgz> dimitern: yeah, I'm working on tidying those last bits up now
[12:26] <dimitern> mgz, you rock!
[12:49] <dimitern> voidspace, please, take a look at the stub NetworkInterfaces - http://reviews.vapour.ws/r/742/
[13:02] <fwereade> wallyworld_, don't suppose you're around? wanted to ask about when we set StatusInstalling
[13:03] <wallyworld_> fwereade: give me 5
[13:09] <wallyworld_> fwereade: when ModeInstalling is called and also when ModeConfigChanged is called and state is not Starting
[13:10] <fwereade> wallyworld_, right, am confused about setting it at ModeConfigChanged time
[13:10] <wallyworld_> maybe that's not necessary - i think it was a s/Installed/Installing thing
[13:11] <fwereade> wallyworld_, ok cool
[13:11] <wallyworld_> but if we do get config changed and we are not set up yet
[13:11] <wallyworld_> then installing seems reasonable
[13:11] <wallyworld_> maybe the check just needs to be expanded
[13:12] <fwereade> wallyworld_, then we should surely still be in Installing state? ah-*ha*, we might have gone into hook error on install
[13:12] <wallyworld_> yup
[13:12] <fwereade> wallyworld_, I don't think it should be a config-changed-time check though, I think it's part of committing an installed state
[13:12] <fwereade> wallyworld_, does that sound sane?
[13:13] <wallyworld_> i think so, but am a little tired so will think properly tomorrow
[13:13] <fwereade> wallyworld_, or, hmm
[13:13] <fwereade> wallyworld_, no, actually, I think you're right
[13:13] <wallyworld_> which bit?
[13:14] <fwereade> wallyworld_, setting it at the start of config-changed
[13:14] <wallyworld_> that did seem reasonable
[13:14] <wallyworld_> at the time
[13:14] <fwereade> wallyworld_, it was judicious and forward-thinking, I appreciate it
[13:15] <wallyworld_> not sure if i put it there or adapted it or whatever
[13:15] <fwereade> wallyworld_, fwiw I think you set StatusInstalling in the wrong part of ModeInstalling but I'm touching that as I go
[13:15] <wallyworld_> could well do - i am a uniter novice
[13:16] <wallyworld_> be gentle with me, it's my first time
[13:16] <wallyworld_> doing stuff with uniter
[13:16] <fwereade> wallyworld_, no worries, it's just that ModeInstalling isn't the mode func, it *returns* the mode func
[13:17] <wallyworld_> yes, you are right. maybe i was thinkin that if it was at the point of setting up for install, it should be put in installing
[13:17] <wallyworld_> ie transition from allocating to installing sooner
[13:18] <wallyworld_> as by then clearly allocation had been done
[13:18] <fwereade> wallyworld_, anyway you don't need to do anything, I just wanted to check up/rubber duck what was going on
[13:18] <wallyworld_> np, ty
[13:18] <fwereade> wallyworld_, I dunno, I think the moment we start looking up the charm is a fine time to set the status
[13:18] <fwereade> wallyworld_, btw did we get an upgrading status?
[13:19] <wallyworld_> hmmm, no
[13:19] <wallyworld_> we should probs add that, after checking with john
[13:20] <fwereade> wallyworld_, we can manage fine without it but I think it's cleaner
[13:20] <wallyworld_> i think i agree
[13:21] <fwereade> wallyworld_, cool, I will assume that'll be the approach if I bump up against it
[13:21] <wallyworld_> ok
[13:30] <dimitern> mgz, got a link to the win/mac build jobs?
[13:33] <dimitern> mgz, ah, found them from the last curse message
[13:40] <perrito666> dimitern: any luck?
[13:42] <dimitern> perrito666, well - so far so good
[13:42] <axw> if anyone's got time for a quick review, that'd be great... may have slipped by unnoticed since the RB bot didn't pick it up: https://github.com/juju/juju/pull/1420
[13:43] <dimitern> perrito666, only the "revision results" job has to succeed
[13:44] <dimitern> perrito666, but afaics the win/mac builds passed
[13:47] <voidspace> dimitern: looks good
[13:47] <voidspace> dimitern: still reading
[13:48] <voidspace> dimitern: why the ++ changed to --
[13:48] <dimitern> voidspace, great
[13:48] <voidspace> dimitern: why the ++ changed to -- ?
[13:49] <dimitern> voidspace, well, it seemed more appropriate - releasing an address should decrement the maxAddr as it could be useful for tests like Allocate, Release, Allocate
[13:51] <voidspace> ah, ok
[13:52] <voidspace> at least you haven't claimed to do live testing on this one...
[13:54] <voidspace> Dummy implementation looks good/useful
[13:58] <voidspace> dimitern: if the -- change made no difference to any tests, or any code anywhere, then I'm sceptical it's needed at all...
[13:58] <voidspace> dimitern: other than that, LGTM
[13:58] <voidspace> dimitern: well, let me look at the dummy implementation one more time before I sign off
[13:58] <voidspace> lots of TODOs added as well
[13:59] <dimitern> voidspace, I agree we shouldn't plan too far ahead for what tests we *might* need
[13:59] <voidspace> dimitern: I dislike/distrust code written for imaginery future use cases.
[14:00] <dimitern> voidspace, that s/++/--/ seems like a good idea, but I don't mind reverting it if you disagree - it's just a detail anyway
[14:00] <dimitern> voidspace, +1, although I need to get better at judging this :)
[14:00] <voidspace> sure
[14:00]  * dimitern bbiab
[14:01] <voidspace> balancing future planning with that is difficult
[14:01] <voidspace> no easy answers
[14:04] <voidspace> dimitern: yep, LGTM
[14:04] <voidspace> dimitern: my mortgage guy is due here any minute and I'm going to make coffee
[14:08] <anastasiamac> fwereade: o/
[14:08] <fwereade> anastasiamac, heyhey
[14:09] <anastasiamac> fwereade: how r u?
[14:09] <fwereade> anastasiamac, good thanks, and you?
[14:09] <anastasiamac> fwereade: m good but weary
[14:09] <anastasiamac> could I run smth by u?
[14:09] <fwereade> anastasiamac, ofc
[14:09] <anastasiamac> fwereade: about annotations...
[14:09] <fwereade> anastasiamac, go on
[14:10] <anastasiamac> fwereade: to meet kapil's requirments, we need to list charms
[14:10] <anastasiamac> fwereade: I've added API call to current client
[14:10] <anastasiamac> fwereade: bumping it's version but m not 100% sure it's good
[14:11] <anastasiamac> fwereade: not sure if 1 call warrants a separate API either
[14:11] <fwereade> anastasiamac, my gut would say to have a new facade
[14:11] <fwereade> anastasiamac, hot on its heels will, I suspect, be requirements that we delete charms
[14:11] <fwereade> anastasiamac, etc etc
[14:11] <anastasiamac> fwereade: excellent! will change tomorrow :)
[14:11] <fwereade> anastasiamac, and check the current api, there's a charm-info (or something) call
[14:12] <anastasiamac> fwereade: shall i move it?
[14:12] <fwereade> anastasiamac, which would be happy on that facade I think
[14:12] <fwereade> anastasiamac, yes please
[14:12] <fwereade> anastasiamac, which is to say don't *move* it, leave it where it is too, and then we don't need a version change on client
[14:12] <anastasiamac> fwereade: purrrfect :) wallyworld_ and I were wondering but u've cleared it all up ;)
[14:13] <fwereade> anastasiamac, cool
[14:13] <anastasiamac> fwereade: thnx for ur time and insight :)
[14:13] <fwereade> anastasiamac, np
[14:50] <dimitern> anastasiamac, you've got a review on the ListCharms PR
[14:52] <dimitern> wtf?! ERROR juju.cmd supercommand.go:411 failed to bootstrap environment: dial tcp 54.88.153.132:22: ConnectEx tcp: A connection attempt failed because the connected party did not properly respond after a period of time, or established connection failed because connected host has failed to respond.
[14:52] <dimitern> mgz, is the job itself flaky? http://juju-ci.vapour.ws:8080/job/win-client-deploy/1298/console
[14:53] <mgz> dimitern: sinzui has been wrangling with it
[14:54] <dimitern> mgz, cool
[14:54] <sinzui> dimitern, ssh on that machine sucks
[14:55] <dimitern> sinzui, :/
[14:56] <dimitern> well, I hope there's still a chance to unblock master later today
[14:57] <mgz> dimitern: build-osx-client passed, so your fix was fine
[14:57] <dimitern> voidspace, thanks for the review
[14:58]  * dimitern sings the happy dance ;)
[14:58] <dimitern> or dances the happy song lol
[14:58] <mgz> eheheh
[15:30] <dimitern> BLESS!
[15:30] <dimitern> oh joy
[15:31] <mgz> dimitern: yeay! unblocked
[15:31] <perrito666> dimitern: thank youuuuu
[15:32] <dimitern> perrito666, mgz, cheers guys!
[16:52] <katco> wwitzel3: ericsnow: did either of you do a write-up on how you broke up your branch? i'm coming up on a large-ish change.
[16:52] <ericsnow> katco: we haven't gotten there yet :)
[16:52] <katco> ericsnow: doh!
[16:53] <katco> i suppose there must be something out there on google when the time comes
[16:55] <ericsnow> katco: but the idea I had is to remove everything I don't want in the review and commit that on the branch and then create the PR (and review request)
[16:55] <ericsnow> katco: then add back in the stuff for the next patch and commit in a new branch (and use rbt --parent)
[16:55] <ericsnow> katco: then repeat until it's back up to where it was before you started splitting things up
[16:56] <ericsnow> katco: that way you don't lose all your git history
[16:56] <katco> ericsnow: i think my general hunch was the inverse: create a new branch and begin merging in certain files
[16:56] <ericsnow> katco: where to split things up is a different question
[16:57] <ericsnow> katco: though keeping each review request a manageable size is one key objective
[16:57] <katco> ericsnow: yeah, that's the only reason i am doing it
[16:57] <ericsnow> katco: the problem with that is the loss of history
[16:57] <katco> ericsnow: very true
[16:58] <ericsnow> katco: right now our branch has over 100 commits in it (I think)
[16:58] <katco> ericsnow: wow that's awesome
[16:58] <ericsnow> katco: and most of that is valuable information
[16:58] <wwitzel3> yeah, I'd like to avoid losing our commit history
[16:58] <ericsnow> katco: wwitzel3 and I have taken the approach of keeping commits focused
[16:59] <katco> ericsnow: i aspire to be that diligent, but i always get trapped in the "gosh can this really be an atomic commit"
[16:59] <katco> ericsnow: as in, could this functionality stand alone
[16:59] <ericsnow> wwitzel3: one alternative is to manually generate the patches and create the review requests manually and then merge the whole branch when *all* the requests get a ship-it
[16:59] <ericsnow> wwitzel3: but that seems like more work
[16:59] <katco> ericsnow: i think i need to shift my thinking on that somehow
[17:00] <ericsnow> katco: sometimes you can and sometimes you can't :)
[17:00] <ericsnow> katco: usually, though, you can :)
[17:00] <katco> ericsnow: :)
[17:00] <ericsnow> katco: try using the "-p" option to git add
[17:00] <wwitzel3> yeah -p for the win
[17:01] <ericsnow> katco: we've used it to great effect when we've made changes that we want to split into multiple commits
[17:01] <wwitzel3> ericsnow: yeah, honestly, I think we could probably, in most cases just do file and file_test as a commit.
[17:01] <katco> ericsnow: ah cool, so you're picking out bits of files?
[17:02] <wwitzel3> ericsnow: not commit, review
[17:02] <wwitzel3> katco: yeah, we just select the bits that make up an atomic commit
[17:03] <wwitzel3> katco: I've found it much easier to do when you have all of the context, instead of trying to do with with forsight
[17:04] <wwitzel3> ericsnow: anyeay, I agree it is more work, but I think we've done a good enough job of file seperate that it is probably the best approach
[17:06] <katco> wwitzel3: i agree. i cannot with any reliability land slices of the stack without having first coded the entire stack. there's just too much back and forth as the design emerges.
[17:50] <perrito666> does anyone know how to prevent google chrome from popping those notifications before meetings??
[17:51] <dimitern> perrito666, in the calendar - edit the event and uncheck reminders
[17:51] <perrito666> dimitern: What I actually want is to stop chrome from breaking the 4th wall
[17:51] <dimitern> perrito666, Notifications -> [ Pop-up ] [ 10] [minutes] (x)
[17:52] <dimitern> perrito666, whaa? :)
[17:52] <perrito666> dimitern: I dont want to be able to pop notifications into my window manager
[17:52] <perrito666> I mean chrome
[17:54] <perrito666> There is a small bell that shows in the indicator and a pop up thing tells me that I have a meeting, I dont want chrome to do that , it is invasive and also clashes with my ubuntu calendar
[17:54] <dimitern> perrito666, aah!
[17:55] <dimitern> perrito666, those .. I knew how at some point and managed to turn them off, but I forgot how
[17:55] <perrito666> it is not obvious in the ui
[18:07] <perrito666> rick_h_: there is a nice lady talking in yourbehalf in the call
[18:15] <voidspace> dimitern: decorator fail : http://maas.ubuntu.com/docs/api.html
[18:37] <dimitern> voidspace, I can't see anything unusual :)
[18:39] <voidspace> dimitern: :-)
[18:42] <dimitern> voidspace, all my branches merged, finally
[18:43] <voidspace> dimitern: great
[18:44] <voidspace> dimitern: I got sidelined into mortgage applications - didn't make as much progress as I should have
[18:44] <voidspace> dimitern: but for once I have nothing planned this evening so might do some more in front of the TV
[18:44] <voidspace> dimitern: I got the signatures changed, but not much on the implementation for MAAS / EC2
[18:44] <dimitern> voidspace, no worries, I wanted to unblock you before I go today
[18:44] <voidspace> dimitern: easy stuff though
[18:44] <voidspace> dimitern: yeah, thanks
[18:45] <voidspace> ah, and the new goamz branch
[18:45] <voidspace> cool
[18:45] <dimitern> voidspace, yep - shiny and squeaky
[18:45] <voidspace> Nice :-)
[18:45] <dimitern> :)
[18:46] <voidspace> dimitern: so, I already had booked a "geek dinner" in London of the Thursday that we're together in London
[18:46] <dimitern> ok, I'll be off then - a long day that was
[18:46] <voidspace> dimitern: you'd be welcome
[18:46] <voidspace> dimitern: go have a break
[18:46] <dimitern> voidspace, nice!
[18:46] <voidspace> yeah, saves me a trip if I'll already be in London...
[18:46] <dimitern> voidspace, awesome :)
[18:47] <voidspace> I'm signing off for now
[18:47] <voidspace> going jogging
[18:47] <voidspace> g'night all
[18:47] <dimitern> voidspace, enjoy
[19:25] <rick_h_> perrito666: who da what?
[19:25] <rick_h_> perrito666: nice lady?
[19:28] <perrito666> rick_h_: on the call we where hearing an operator voice
[19:29] <rick_h_> ah lovely
[19:29] <rick_h_> what a mess
[20:14] <sinzui> perrito666, do you have a few minutes to review http://reviews.vapour.ws/r/744/
[20:16] <sinzui> abentley, jog: I have my lull. I will review abentley's branch first
[20:17] <jog> sinzui, that's fine, abentley, said he'd look at mine
[21:15] <perrito666> katco: hey, what was the magic invocation to get different output formats in juju?
[21:15] <perrito666> and which version is that in?
[21:16] <katco> perrito666: juju status --format
[21:16] <katco> perrito666: juju help status will give you all the options
[21:16] <katco> perrito666: and i believe it's in >= 1.22
[21:24] <anastasiamac> didmitern: r u still around?
[21:26] <perrito666> katco: tx a lot
[21:27] <katco> perrito666: np, enjoy :)
[21:29] <sinzui> perrito666, do you have a minute to review  http://reviews.vapour.ws/r/744/
[21:30] <perrito666> sinzui: sure
[21:30] <perrito666> anyone local provider savvy?