[00:04] twice in two days I'm happy I disabled pushing to upstream [00:04] as it has saved my arse [00:04] ? [00:05] sinzui: you finished with tim? [00:06] wallyworld: yeah, I'm sufficiently whipped [00:06] lol [00:06] sinzui: https://github.com/juju/juju/pull/314 [00:07] menn0: hangout now or after lunch? [00:07] thumper: now is fine with me [00:08] menn0: https://plus.google.com/hangouts/_/canonical.com/upgrades [00:17] davecheney: what's the staus of the potentio mgo bug? have you managed to reproduce in a way that a bug can be filed? [00:39] sinzui: you got time for a quick chat? [00:49] menn0: haven't caught you online in a week-ish. About that regex... I found it an interesting difference between go regex and perl/python. \d matches unicode digits in python. Thanks for the discussion [00:50] jrwren: yeah, sorry. I've had a several days off over the last week and a bit [00:50] jrwren: thanks for following up on the regex differences. good to know! [00:50] no worries. I just meant to pick up that conversation with you again. [00:57] wallyworld, I am available now [00:57] sinzui: great, wanna rejoin the hangout from before? [00:57] https://plus.google.com/hangouts/_/canonical.com/juju-release [01:01] wallyworld: no update [01:01] sorry [01:01] other bugs to fix [01:01] i can see there is an issue wher emongo eats the eerror [01:02] but haven't investgated further [01:02] davecheney: otp, will ping you soon [01:03] wallyworld: noted [01:43] davecheney: it's becoming critical we get this issue looked at upstream. is there any way you could get enough info together to file a bug? [01:43] if strings.HasPrefix(tag, "environment-") { [01:43] return ops, nil [01:43] } [01:43] ark! [01:44] wallyworld: i'll send you what I have [01:44] which isn't mich [01:44] wallyworld: http://paste.ubuntu.com/7801230/ [01:44] davecheney: i was hoping you'd be abe to progress it to the point of filing the bug. do i need to ask thumper for some of your time? [01:44] ^ that's it [01:44] wallyworld: yes [01:44] i am working on the Ci blocking windows bug [01:44] thumper: consider yourself asked [01:45] it can come after the CI blocking bug is fixed [01:47] wallyworld: fyi, i'm wasting^h^h^^h^h^h^h spending all today setting up a windows dev environment [01:48] going back to the mgo bug [01:48] oh, you have my sympathies :-( [01:48] davecheney: i'd rather a kick in the bollocks than having to deal with that [01:48] what I see is when we have test failures, they are usually acompanied by the additional debugging in the patch above firing [01:49] ok. so seems like it would be possible to package up a bug report which illustrates or at least explains the problem [01:50] in enough detail that it hopefully is uncontentios to fix [01:50] all i can show is the symptoms at the moment [01:53] thumper: state/annotator.go insertOps [01:53] ^ me shakes head [02:27] wallyworld: thumper, do I even want to ask if there is windows support for bzr ? [02:28] davecheney: yes [02:28] this is [02:28] noice [02:35] hmm, [02:35] that wasn't too painful [02:35] no idea how i'm going to get a version of mongodb with ssl support [02:57] aah fuck [02:58] wallyworld: you around for a chat? [02:58] sure [02:58] wallyworld: https://plus.google.com/hangouts/_/gsz5xroyjpu4ty7ryxodhbqirya?authuser=1&hl=en [03:01] wallyworld: thumper https://github.com/juju/utils/pull/10 [03:02] davecheney: +1, i assume you know the windows stuff :-) [03:06] wallyworld: https://github.com/juju/juju/pull/315 [03:07] davecheney: LGTM [03:10] sinzui: fix is landing for the win32 build failure [03:10] is there a way I can tickle the CI aperatus to trigger a build ? [03:12] omg [03:13] if juju doesn't build from the trunk of juju/utils I will throw a shoe [03:14] hmm [03:29] * thumper dashing out for a bit [03:29] bbs [03:40] jam: hiya, no idea why this can't automatically merge, i'll do it by hand i guess, but could you please look at https://github.com/juju/errors/pull/3 [03:40] wallyworld: because unless mgz set up the jobs only juju/juju is automated by the bot? [03:41] wallyworld: you can't click the button because it finds a conflict between master and your branch [03:41] jam: but i hust pushed up my branch just then [03:41] so i'm not sure what the conflict is [03:42] i branch off tip of master, add the licence changes, pushed, and create the pr off that branch [03:42] i can merge by hand i guess [03:45] wallyworld: so I'm having trouble finding the git syntax to copy just your fix-licenses branch into my local repository, when I figure that out, I'll let you know if I can find the merge issue [03:45] ok [03:45] jam: i'm not so worried about the merge issue for now, i can just merge by hand if needed [03:48] jam: this one can be merged, created the same way https://github.com/juju/errgo/pull/7 [03:52] wallyworld: $ git merge --no-commit --no-ff 890f25ff011baceede953804330b590cbac89c83 [03:52] CONFLICT (modify/delete): internals.go deleted in HEAD and modified in 890f25ff011baceede953804330b590cbac89c83. Version 890f25ff011baceede953804330b590cbac89c83 of internals.go left in tree. [03:52] Auto-merging annotation.go [03:52] Automatic merge failed; fix conflicts and then commit the result. [03:54] jam: ok, thanks. i'll just delete that file. not sure why it got left there when I pulled from upstream [03:54] wallyworld: your 'fix-licenses' version is not from the tip of juju/errors/master [03:54] wallyworld: looking at the graph it is based off of "also update the readme" [03:55] which doesn't include "use deep equals" and "merge pull request from howbazaar ..." [03:55] oh, bollocks. could have sworn i branched off master [03:55] ok, thanks, will fix [03:55] wallyworld: you probably branched off your *local* master [03:55] you have to do [03:55] git co master [03:55] git pull origin master [03:55] git co -b fix-licenses [03:55] sigh. i hate git [03:58] jam: fixed now, thank you [03:59] wallyworld: happy to help, I got to learn a few more git commands, though probably that just means next time I need it I'll be googling again :) [03:59] lol, yeah i have to do that too [04:00] it never occurred to me i had branched off an old master [04:03] jam: here's a really trivial one. after this one, i need to branch the oher sub repos because 1.20 and master revs are different https://github.com/juju/schema/pull/2 [04:08] wallyworld: as in you want a review? LGTM [04:08] jam: thanks, i really didn't need a review for that i guess [04:08] jam: guess who drew the short straw in having to fox the licence balls up? [04:08] :-( [04:09] wallyworld: clearly Martin [04:09] I actually haven't seen mgz/bz2/… around in the last couple of days, is he on vacation? or just swap days after the sprint? [04:10] just swap days [04:10] should be back today [04:10] wallyworld: yeah, I think for the licensing fixes, as long as we know we want LGPL then it is just trivial and you can just merge them. [04:10] jam: btw, the sub repos are still merged by hand, hence i'm not too worried about desc, title should be self evident [04:18] is there a way to create a juju environment with a mongo instance that is accessible by the mongo client? [04:23] I've run into a strange problem where a txn works in tests, but seems to be applied only partially in an ec2 environment [04:24] tasdomas: the plan is to explicitly restrict that (I think today you can technically get to it, but you have to have the right user/password) [04:25] tasdomas: if you really need it, I would use SSH and port forwarding [04:28] jam, what do you mean by ssh and port forwarding? Forward the port for mongo? [04:28] ssh $MACHINE_0 -L 37017:localhost:37017 and then you connect to your local machine at 37017 [04:28] mongo localhost:37017/juju [04:29] you'll need the username and password from machine-0 IIRC [04:29] davecheney: in utils repo, there's a zfile_windows.go that says it has been automatically generated. was that checked in my mistake do you think? [04:29] 'machine-0' I believe is the username, but the password is randomly generated and in /var/lib/juju/agents/machine-0/agent.conf [04:30] jam, thanks [04:32] tasdomas: I've had hard times getting mongo to play well with authenticated connections [04:32] you *might* need to connect to the admin db first to login, and then switch [04:42] jam, the issue I am trying to debug is this: http://paste.ubuntu.com/7801746/ [04:43] a []txn.Op runs without any apparent errors, but the end result does not match what should actually have happened [04:44] tasdomas: offhand I don't know what Assert: d- means [04:45] jam, it's txn.DocMissing [04:46] tasdomas: so the Insert there has a pointer rather than a detailed struct? [04:46] IIRC you can't do stuff to objects created earlier in the same transaction (I could be completely wrong) [04:46] but if the first step was creating the doc, it doesn't exist for you to add the item to its set. [04:47] tasdomas: but *my* mongo + transactions knowledge is pretty weak. You're better off chatting with fwereade if you and he can overlap in time. [04:48] jam, hm, thanks for the suggestion [04:48] wallyworld: have you done any TXN stuff? [04:48] jam, the weird part is that those ops work in tests and that the whole transaction does not abort [04:48] jam: in what context? [04:48] I thought it was you who commented on being able to do stuff later in a transaction to stuff earlier [04:49] jam: the asserts are evaluated once at the start of the txn [04:50] so ops that happen laster on can't have asserts that depend on previous ops in that same txn [04:50] kinda sucks :-( [04:50] but that's how mgo driver has been written [04:50] wallyworld, thanks [04:50] np [04:53] tasdomas: the asserts I see there are stuff like "value ne dead" [04:53] which nil != dead, right? [04:53] jam, I think so [04:54] tasdomas: anyway, my guess is that the "if the doc doesn't exist insert it" is succeeding, but it isn't letting the "add this value to the set" work [04:54] so maybe if you change the inserted doc to include the new port? [04:54] I really don't know [04:54] but there aren't any asserts there that would fail [04:54] thus the transaction will succeed [04:54] jam, yeah - that's what I'm rewriting this to now [04:55] tasdomas: I would have thought that you could create and then update an object, but maybe the ordering of a transaction isn't really guaranteed, and thus it could try to apply the update before the create. [04:55] and thus, can't do anything [04:55] jam, makes sense [04:56] * thumper groans while studying code... [04:57] thumper: don't you groan for pretty much anything? :) [04:58] jam: in this particular instance I'm groaning because what I though would be simple, isn't [04:59] * thumper ungroans === uru is now known as urulama [05:19] wallyworld: no, that is correct [05:19] ok [05:19] it is generated then comitted [05:19] thanks [05:28] * thumper seems to be running around in circles [05:46] ok, stopped running around in circles [05:46] moar tests tomorrow [05:46] menn0: I'm getting close :) [05:47] hmm if dimitern is arriving, time to leave [05:47] * thumper waves [05:47] :D [05:49] morning dimitern [05:51] morning jam [05:51] (which reminds me to have some breakfast :) === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [07:51] TheMue, jam, vladk, others? review on https://github.com/juju/juju/pull/318 much appreciated - finalizing prefer-ipv6 flag implementation === psivaa-off is now known as psivaa [07:52] * dimitern needs to step out for 1/2 h [07:52] dimitern: quid-pro-quo? https://github.com/juju/juju/pull/317 [07:53] morning [07:53] dimitern, jam: will take a look into both [07:57] jam: ping [07:57] TheMue: yes? [07:57] morning, btw [08:00] jam: on GH where can I see who is allowed to merge code via $$merge$$? or is everybode allowed? [08:00] jam: otherwise I’ll merge an external provided code (like I’ve done on LP last week) ;) [08:01] TheMue: AFAIK the people who are listed as part of the "juju" team (with their membership being public) are allowed to vote $$merge$$. [08:01] TheMue: https://github.com/orgs/juju/members is the member list [08:02] jam: ah, ok, thx, will take a look [08:02] TheMue: so you mean if you review code, you want to check if the user can vote merge for themselves? [08:02] that would probably be the list [08:03] jam: yes, exactly. the code is reviewed. the contributor is not on the list, so I’ll merge it [08:04] …oooOOO( After adding a card, learned from last time. *smile* ) [08:20] Hello [08:21] why juju execute the same hook few times one the same unit? [08:26] on* [08:27] Egoist, hi, depends what hook you mean [08:27] Egoist, and when [08:28] Egoist, https://juju.ubuntu.com/docs/authors-charm-hooks.html === vladk is now known as vladk|offline === vladk|offline is now known as vladk [08:40] jam: you’ve got a review [08:41] fwereade: hey, good to see you around. [08:42] fwereade: I was hoping you might be able to find time to help me with cloudsigma reviews now that you're back [08:44] TheMue: are you seeing user photos for github users being broken and replaced by text strings? Or is it just me? [08:47] jam: hehe, already wanted to ask the same. it’s broken here too. already wondered. [08:48] TheMue: yeah, I thought maybethey updated something so I went to upload a new image and it tells me "we can't use that image"… I stopped there. [08:48] dimitern: I reviewed your patch https://github.com/juju/juju/pull/318 [08:49] jam: funnily the organization images are shown, but not the user images === vladk is now known as vladk|offline [08:52] bodie_: ping === vladk|offline is now known as vladk === vladk is now known as vladk|offline === vladk|offline is now known as vladk [09:02] jam, thanks! [09:03] fwereade, i mean -relation-changed, when add more unit to service [09:03] fwereade, it'a a little strange because, hook who is done, starting again on the same unit [09:04] Egoist, relation-changed is always specific to a remote unit [09:05] Egoist, if there are 5 units of service S and 2 units of service T [09:05] Egoist, each unit of T will see a -joined and a -changed for each of the 5 units of S [09:06] Egoist, the $JUJU_REMOTE_UNIT var tells you which one you're responding to [09:09] fwereade, yeah, but when relation-changed is finished on every related unit, it should be over, and while new unit is not added, relation changed should do nothing [09:09] right? [09:10] Egoist, it'll also fire whenever a remote unit writes new settings [09:10] Egoist, if you're writing a relation-changed hook you need to look at what that remote unit has set, and you probably need to respond to it [09:13] ok, get it :) [09:13] ouch, looks like GH is down now [09:15] fwereade, but it's not possible, executing relation-get every ten seconds, and it not stop :/ === vladk is now known as vladk|offline [09:16] Egoist, so you're seeing relation-changed firing again and again forever? [09:17] Egoist, can you describe the situation a bit more? [09:19] Egoist, eg just the conversation between two particular units you're having trouble with? [09:20] fwereade, no it happen when i attach another unit to service [09:21] this new unit firing relation-changed again and again, and it won't stop === vladk|offline is now known as vladk [09:28] it's hard to describe, in relation-changed i just getting data from relation and config, using this data make change on istalled software on unit, and basically that's it [09:29] fwereade, and relation-changed return true at the end [09:29] fwereade: or mattyw: as OCR, care for a reasonably trivial review: https://github.com/juju/utils/pull/13 [09:30] jam, why has that file be renamed? [09:30] mattyw: because _linux is only compiled on linux [09:30] ^^ (not sure what other question I could ask) [09:30] which isn't darwin [09:30] (OS X) [09:30] jam, ok [09:30] or BSD or whatever else for that matter [09:31] Egoist, well it will certainly fire it once for every remote unit, and it may do so more if the settings are changing -- are you seeing it again and again for the same remote unit? or cycling through all the remote units? and are the settings for the relevant units definitely not changing? [09:31] but with "posix" it should compile everywhere that has Posix semantics, which should be just fine for a 'symlink' thing. [09:31] jam, ah sorry - github wasn't drawing your description for me [09:31] I see it now [09:32] mattyw: how nice of it [09:33] thanks mattyw [09:41] fwereade, i make a little change in code, and it stopped, so maybe it was a bug in code [09:42] Egoist, could be -- thanks for letting me know [09:43] dimitern, around? is it possible to have a MAAS environment use an interfaces/bridge other than br0? [09:43] for LXC/KVM instances? [09:44] jamespage, afaik there's a setting you need to tweak for that [09:44] jamespage, the network-bridge config setting might be what you're looking for [09:44] jamespage, fwereade, right [09:49] fwereade, dimitern: that sounds like the one [09:51] davecheney, feel free to land it - or at least try to [09:53] is there any way to get how many units is in service, but not from command line, i need that in code? [09:57] Egoist, not really -- you should expect that the number could change at any time, but that you'll be informed by appropriate hooks running [09:58] Egoist, what are you trying to do? [10:17] fwereade, because in code i use relation-list, and it not alway listed all units, sometimes one is missing [10:17] Egoist, it'll tell you about the units you're expected to know about based on what hooks have run [10:17] Egoist, if you haven't seen the -joined hook for unit X yet, you won't see in in relation-list [10:19] wallyworld, sorry I'm out of touch: do we have an ETA for in-environment storage? I got the impression it was nearly done, but not quite [10:20] fwereade: the api is done and functional and in the blobstorage repo; the refactoring work to change the juju code to store tools and charms etc is yet to be done [10:21] fwereade: there's ongoing debate about the charm storage side of things that needs to be sorted out also [10:22] wallyworld, so I guess we can't yet fix it for manual/local/cloudsigma providers [10:22] fwereade: we can - that's on the immediate todo list. we've already started the Environ api changes and there's a wip branch to internalise the Strorage() facility [10:23] fwereade: significant refactoring was done at the sprint; the StateInfo() api is almost gone; replaced by a StateServerInstances() api [10:24] wallyworld, ooh! can I direct you at https://github.com/juju/juju/pull/174/files please? just to inform them what needs to be done (or rather doesn't need to be done any more?)? [10:24] looking [10:24] wallyworld, if Storage() can be internalised, I guess it's safe to return a null storage now? [10:25] fwereade: Storage() on ENviron will be gone. but it's still needed for now for tools and charms [10:25] we're not quite there yet [10:28] fwereade: the stuff in that pr above will be needed until we do more work to remove the need for storage. not quite there yet but making good progress [10:33] wallyworld, ok, cool [10:33] wallyworld, would you give them a heads up all the same please [10:34] fwereade: sure,who is "them". do i just talk to nate? [10:38] wallyworld: "them" is Altoros who are writing the CloudSigma provider which has to use the "manual" method for storage because CloudSigma itself doesn't provide a storage solution [10:39] jam: ok, thanks. sadly we are "out of sync" by a few of weeks. i reckon we'll be in a good place to be able to ditch mandatory provider storage by that time [10:39] * jam clearly thinks "air quotes" are the way of the future [10:40] but we need to sync with the charm store guys on charm storager so it's not entirely under out control [10:40] seems like a waste to commit code for only a short time but i don't hink we can hold off on the cloud sigma stuff for that long [10:50] natefinch: can i leave it in your hands to deal with the gojsonschema licence issue? whether it's moved to a different repo, or just the LICENSE file added, or whatever [10:51] fwereade: maybe you remember best why gojsonschema wasn't merged into the github.com/juju namespace? Was it just evolving fast enough that they didn't want to do forced code review since they aren't directly in that group? [10:51] jam1, standup? [10:52] dimitern: thanks, brt [10:52] jam1, I'm sorry, I don't immediately recall -- mgz was more directly involved in the details at that stage iirc, and if not bodie_ will be able to say when he comes one [10:53] wallyworld: sure [10:53] \o/ [10:54] natefinch: i asked because i thought you already had a relatioship with the dev(s) concerned [10:55] wallyworld: I'm more than happy to do it. I'm friendly with them, but otherwise no professional relationship, FYI. [10:56] am I the only one who gets duplicate copies of rogpeppe's mailing list posts? [10:56] i do sometimes i think [10:56] natefinch: i send another copy when i find i've sent from the wrong Sender [10:57] rogpeppe: Oh, I see [10:57] natefinch: because (i believe) juju-dev and canonical-juju will reject posts unless they're from roger.peppe@canonical.com [10:57] rogpeppe: right, that makes sense. I never noticed they were from different senders. [10:57] natefinch: unfortunately I haven't found a way to force gmail to always choose a particular sender address based on the destination address [10:58] natefinch: and gmail doesn't show the sender by default, so i often forget to change it [10:58] rogpeppe: I just have separate inboxes, so it's not a problem [10:58] but I can understand wanting a single inbox for everything, too [10:59] man, setting CDPATH=$GOPATH/src is frigging amazing [11:01] from anywhere I can do cd github.com/juju/juju and it goes to the right place [11:07] jam1, TheMue, vladk, my g+ froze and now I can't go back :/ [11:08] morning mgz [11:08] hey jam [11:10] int54 is evidently not a defined type [11:30] jam: your problem seems to be in apiserver/client_test.go [11:31] TheMue: actually it is state/apiserver/client/api_test.go [11:31] but there may be others [11:32] jam: gna, but ok, it’s no small change [11:36] morning all [11:44] so does it matter what you put between the $$ merge markers $$ ? [11:45] dimitern: it's a regex that is $$\w$$ so, no spaces [11:45] natefinch, right! good to know, thanks :) [11:45] morning [11:45] morning perrito666, voidspace [11:46] dimitern: we changed it at the sprint last week, for $$lotsOfFunTimes$$ [11:46] I thought it was \s+ [11:46] $$exactly$$ [11:46] dimitern: perrito666: o/ morning [11:46] voidspace: isn't \s whitespace? [11:47] I wonder if I should actually merge the change to make it a re match, it's potentially useful for less silly things [11:47] ah, maybe \S+ then === psivaa is now known as psivaa-lunch [12:40] mgz: i have to feed my pets, but then do you want to chat about the unit tests? [12:42] sure thing [12:54] wwitzel3: I have to move our 1 on 1 for later today [12:55] dimitern, is bug 1261780 still an issue now that we use golanf 1.2? [12:55] <_mup_> Bug #1261780: go 1.1.2 TLS-enabled client does not accept our CACert

[13:02] sinzui, i'll take a look [13:06] natefinch: np [13:17] sinzui, it seems that should be fixed in go 1.2 [13:17] sinzui, had to check a few forums to make sure [13:17] thank you dimitern [13:40] natefinch, can you help arrange a fix for bug 1342725 [13:40] <_mup_> Bug #1342725: C:/Juju/lib/juju/nonce.txt does not exist, bootstrap failed in win

[14:02] dimitern, fwereade , jam : can I be upgrades in this channel to update the topic which is months old [14:02] s/upgrades/upgraded AKA moderator? [14:03] sinzui, it's done via chanserv [14:04] sinzui, and I think we all should be able to do it [14:04] not yet: #juju-dev :You're not a channel operato === Ursinha is now known as Ursinha-afk [14:05] sinzui, try /msg ChanServ TOPIC #juju-dev [14:06] we're seeing an issue where people are attempting to use juju bootstrap with kvm and it fails b/c they do have /usr/sbin in their path [14:06] this line: command := exec.Command("kvm-ok") [14:06] could that possibly be changed to the full path of kvm-ok? [14:07] stokachu, please file a bug about it [14:07] stokachu, please report that to a bug and I will target it to 1.20.2 [14:07] i will was just curious on your thoughts [14:08] stokachu, I think these commands like kvm-ok are supposed to be in the $PATH, and there are some checks about it in tests [14:09] sinzui: I can help with that [14:10] dimitern, the only test i see related is it checking if the host os is ubuntu === ChanServ changed the topic of #juju-dev to: https://juju.ubuntu.com | On-call reviewer: see calendar | Bugs: 1 Critical, 147 High - https://bugs.launchpad.net/juju-core/ [14:14] sinzui, https://bugs.launchpad.net/juju-core/+bug/1342747 [14:14] <_mup_> Bug #1342747: juju bootstrap fails if kvm-ok not in path

[14:15] thank you stokachu [14:16] np :D [14:19] I have a user in #juju asking what ports he needs to keep open in UFW to use juju. are there any other ports than the WSAPI port that he would need to open? [14:20] lazyPower: that should be it, though he might want 22 open for SSH access [14:20] the wssapi port is 27017 by default right? [14:21] lazyPower: that's the default mongo port [14:21] lazyPower: hang on, I'll find it, I forget [14:21] haha yeah, i thought we used the mongodb port [14:21] * lazyPower has mongo on the brain [14:22] lazyPower: used to be we went straight to mongo, we've stopped doing that and it's all through the API now [14:22] lazyPower, it's 17017 for the api and 37017 for mongo, but the latter shouldn't be needed [14:22] i like that we did that. It'll be easier to replace mongo if we ever do that. [14:23] lazyPower, so 17017 + 22 should be opened [14:24] dimitern: thanks *hattip* [14:24] lazyPower, depending on the provider, if httpstorage is used you need to open its port as well (there are environ settings for some of those) [14:24] lazyPower, np === Ursinha-afk is now known as Ursinha === psivaa-lunch is now known as psivaa [14:53] arg..... the fix for the windows client is going to be annoying. it's one of those things where we used to just assume everything was ubuntu, but now we have *some* windows code, and that's screwing us up. And so we have to change the signature of functions to pass in a series [14:56] natefinch: yup, my patch, Which I answered in the thread about that same issue does a very tiny fix and touches like 20 files [15:01] TheMue, you keep joining and dropping :) [15:01] alexisb: yeah, it shows me an error and says I shall retry later :( [15:01] alexisb: and so I retry :) [15:02] TheMue, do you have topics for today? [15:02] alexisb: nothing special. feeling good and currently investigating in LXC and IPv6 [15:03] TheMue, alright, I can give you 30 minutes back, I know I could use them this week :) [15:04] alexisb: fine, then we’ll see next time again. ;) [15:06] natefinch: stand up? [15:07] ok, so not such a successful test run - 22509 lines of output... [15:10] wallyworld: ping [15:21] natefinch: ping [15:55] jam1, ping [15:58] jam ping [16:31] alexisb: pong [16:31] I've been trying to connect to the hangout, but I keep getting "could not start video because of an error" [16:32] jam1: is there an easy way to see who has signed the canonical CLA? [16:33] jam1, yeah the hangouts seem to be acting all funny today [16:33] john and I are on [16:33] but no one else [16:34] natefinch: there is a launchpad group, just a sec [16:34] natefinch: https://launchpad.net/~contributor-agreement-canonical [16:36] lol jam1 everyone keeps joining and dropping [16:36] just John and i on [16:36] my internet still sucks [16:36] I'll sort it out properly on my return from Romania [16:37] I do at least have a phone I can tether as a backup now [16:37] I have 2.6Mbit downstream and that's the best I've had for over a month! [16:37] alexisb: enjoy your holiday. I didn't think managers were *allowed* to go away for ten days ;-) [16:39] :) [16:40] katco, fyi, got asked for status on this bug: https://bugs.launchpad.net/juju-core/+bug/1319475 [16:40] <_mup_> Bug #1319475: Juju should support new signing format