[00:00] <menn0> perrito666: do you mean the DestroyModel method on the Client facade?
[00:01] <perrito666> menn0: ah, Its there, that explain, I was looking for it in ModelManager
[00:01] <perrito666> menn0: tx a lot
[00:01]  * perrito666 takes a moment to learn how to use expensify
[00:01]  * perrito666 fails
[00:14] <menn0> thumper: rogpeppe1 has a PR up to do API login redirection. I haven't looked in detail yet but it looks like what we also need for migrations.
[00:53] <wallyworld> menn0: any reason why destroy model is not on model manager facade?
[00:53] <wallyworld> or should not be?
[00:59] <axw> wallyworld: can talk now if you're free
[00:59] <wallyworld> sure, let's. standup ho will do
[01:21] <menn0> wallyworld: no idea. I had very little to do with that. thumper/
[01:28] <thumper> um... yes
[01:28] <thumper> there was a good reason
[01:29] <axw> anastasiamac: #1167616 is still valid
[01:29] <mup> Bug #1167616: state.SetEnvironConfig should take old and new config values <config> <state> <juju-core:Triaged> <https://launchpad.net/bugs/1167616>
[01:29] <axw> there's a TODO in the code
[01:29] <thumper> it had more to do with who could call it
[01:29] <wallyworld> natefinch: 1 minute late
[01:29] <thumper> but perhaps that isn't a great reason
[01:30] <thumper> but it made sense at the time
[01:30] <axw> thumper: only admins can use the controller facade, right? but shouldn't a non-admin model owner be able to destroy their own model?
[01:30] <thumper> axw: they can
[01:30] <thumper> through the client facade
[01:30] <thumper> the controller facade allows admins to kill other people's models
[01:30] <axw> I see
[01:31] <axw> IMO we should have it on modelmanager, but just do an auth check if auth-user != owner
[01:31] <wallyworld> exactly
[01:31] <axw> check if they're an owner, or a controller admin
[01:31] <wallyworld> and now is the time to make that breaking change. the gui guys will love us
[01:32] <axw> wallyworld: I already broke the ability to create new models, so seems like a good time to change it :)
[01:32] <axw> can't destroy if you can't create
[01:32] <wallyworld> :-)
[01:35] <thumper> do it before beta 10
[01:35] <thumper> then they can't really complain more
[01:49]  * menn0 is drowning in reviews
[02:17] <menn0> wallyworld: I'm looking at http://reviews.vapour.ws/r/5126/
[02:18] <wallyworld> menn0: sorry :-(
[02:18] <menn0> wallyworld: post-bootstrap will there be any way to change the cloud config stored in the controller?
[02:18] <wallyworld> menn0: yes, there will be a command but not done yet
[02:18] <menn0> wallyworld: ok cool
[02:19] <wallyworld> menn0: note that mdels fork (copy) the common config so changing will only affect new models
[02:19] <menn0> wallyworld: that was going to be be my next question :)
[02:19] <wallyworld> in effect, there's no user visiblw change with this work currently therefore
[02:20] <menn0> wallyworld: so if you had something like http-proxy set on a bunch of models
[02:20] <wallyworld> ie stuff works for the user the same as now, except that they don't need to use --config for the shared stuff
[02:20] <menn0> wallyworld: and you wanted to change it
[02:20] <wallyworld> ypu'd need to change all models
[02:20] <menn0> wallyworld: you would have to change it on all the existing models
[02:20] <menn0> ok
[02:20] <menn0> wallyworld: will there be a way to do a mass change across all models?
[02:20] <wallyworld> last week it was inherited, but that got nixed
[02:20] <wallyworld> the ux will need to be discussed, yes
[02:21] <menn0> wallyworld: I guess it's easier to understand if there's no inheritance
[02:21] <wallyworld> exactly
[02:21] <wallyworld> menn0: https://docs.google.com/document/d/1PWUwx9kITQajQQgvHnweUuqTGmBo9p35bVwd-uLKAi4/edit?ts=57626636#heading=h.ppor8yz4jan0
[02:21] <wallyworld> that's from mark
[02:21] <menn0> (well it's prototypical inheritance I guess)
[02:22] <wallyworld> there will be various sources of shared config
[02:22] <wallyworld> right now, we've just the 2 of them
[02:23] <wallyworld> menn0: i have to pop afk for 30 minutes to relocate (long story), will be online again in a bit
[02:23] <menn0> wallyworld: no problems. you've answered my questions. that doc helps too.
[02:23] <wallyworld> excellent
[03:09] <davecheney> menn0: i've fixed your review comments and stress tested my patch
[03:09] <davecheney> i'm going to try landing it
[03:18] <menn0> davecheney: awesome
[03:34] <natefinch> ahh full stack external tests... change one line of code, get 4 tests failing in incredibly obscure ways
[03:36] <wallyworld> axw: i can't do the settings write and model source updates in one txn - the settings is a separate struct which completes in own work before existing
[03:36] <wallyworld> settings.Write()
[03:37] <natefinch> wallyworld: well, that fix worked perfectly well in a manual test, but it breaks 4 tests in bizarre ways.
[03:37] <axw> wallyworld: settings.Write() is implemented in terms of txn.Ops...
[03:37] <wallyworld> it is, but it's a method on a separate struct with its own semantics
[03:37] <axw> wallyworld: so if you split the txn.Op building from transaction running, you can do them in one transaction
[03:38] <wallyworld> that breaks encapsulation
[03:38] <axw> wallyworld: so? you can still compose transactions. they either all run or none
[03:38] <natefinch> wallyworld: we don't have any other way to compose multiple actions into a transaction
[03:38] <wallyworld> so in this case, there's no harm spliting them as per my comment in the code
[03:38] <axw> wallyworld: we're inside the package, there's no encapsulation. having an inconsistent model is worse than exposing the ops
[03:39] <natefinch> we should really have most of our actions like this returning ops rather than running their own transaction
[03:39] <wallyworld> natefinch: so you'll just have to fix the tests i guess
[03:39] <wallyworld> except when we want to provide a fully encapsulated access to state
[03:40] <axw> wallyworld: nobody's suggesting we expose ops *outside* of state. I'm saying that UpdateModelSettings should either update the settings *and* the sources, or *neither*
[03:41] <axw> if we update the settings and then later the sources, we leave ourselves open to having lies in the model
[03:41] <wallyworld> ok, i'll need to break apart settinsg.Write()
[03:42] <wallyworld> moving ModelDestroy() off client is a pita - all the call sites in shared code use *state.State instead of interfaces, sigh
[03:43] <natefinch> I spent a lot of time fixing service creation and unit assignment so that we can't get into an inconsistent state.... and there's still some improvements to make... but the most obvious takeaway was that returning ops is composable, and hiding the ops is not.  Hopefully they can be encapsulated into a single state method call, so no one outside of state needs to worry about it... but inside of state... defaulting to returning ops rather than
[03:43] <natefinch> executing a transaction should probably be the default for most code.
[03:43] <axw> wallyworld: I've been looking at the GCE issue, and it's a bit of a pain. the issue is that we assume there's a one-to-one mapping between credentials.yaml contents and credentials in model config
[03:43] <axw> wallyworld: so not sure what I should do. it will be fixed hwen my in-progress stuff is done, but that's a ways off
[03:44] <wallyworld> natefinch: yeah, so long as we are on mongo it seems that's what we must do
[03:44] <axw> wallyworld: there's a workaround: don't use jsonfile
[03:45] <wallyworld> axw: damn. using json file will be the most common case, especially when people use autoload
[03:45] <wallyworld> i wonder if we can special case something for beta 10
[03:46] <axw> wallyworld: perhaps, just wondering if it's worthwhile expending the effort.
[03:46] <wallyworld> axw: the issue AFAICT is that our users would be using autoload-credentials mostly
[03:46] <wallyworld> and they will be screwed with this beta
[03:47] <axw> wallyworld: I'll fix the empty auth-types one, and then come back to this
[03:47] <wallyworld> ok
[03:59] <thumper> wallyworld: hi ho
[03:59] <wallyworld> yo
[04:05]  * wallyworld relocating back home, bbiab
[04:20] <natefinch> axw: I made a tiny change to the azure provider's StartInstance to fix a bug Ian had added to it when he split out the controller config... and now I'm getting this weird test failure (and 3 others similar to it): http://pastebin.ubuntu.com/17679429/
[04:22] <natefinch> axw: any ideas what is going on?  The bug was that we weren't setting the apiport unless it was during bootstrap, which obviously falls down for machines added for HA: https://github.com/juju/juju/pull/5590/files#diff-8a18f1cda410ddced1438bf9bc8e8eb9R476
[04:22] <natefinch> axw: I just don't understand the error from the test
[04:42] <natefinch> wallyworld: do you understand the azure tests?
[04:42] <wallyworld> have never looked at them
[04:42] <wallyworld> axw does
[04:43] <wallyworld> you getting failures right
[04:43] <natefinch> yeah
[04:43] <natefinch> wallyworld: http://pastebin.ubuntu.com/17679429/
[04:44] <natefinch> that's one of them... the others look pretty similar, so probably same root cause
[04:46] <wallyworld> my guess off the top of my head is that the test does not set apiport in start instance params
[04:46] <wallyworld> hence the correct security groups are not created
[04:46] <wallyworld> but just a guess
[04:49] <menn0> thumper: http://reviews.vapour.ws/r/5132/
[04:59] <mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:01] <axw> natefinch: sorry was having lunch, reading backlog now
[05:03] <axw> natefinch: the azure tests set up a list of expected requests. they're not matching. you'll probably need to modify some calls to "startInstanceSenders" to pass true instead of false
[05:04] <axw> natefinch: i.e. that a controller instance is being started
[05:05] <natefinch> axw: oh yes, I see
[05:06] <natefinch> axw: though I don't really understand why that needs to change due to the change I made to the code
[05:07] <axw> natefinch: if you push the change I'll take a look, if you like
[05:09] <natefinch> axw: https://github.com/natefinch/juju/commit/3534aa71f7aac1eb364ecdb32e51e3c8220c163e
[05:10] <axw> natefinch: we shouldn't be doing it unless it's a controller. so check "else if args.InstanceConfig.Controller != nil"
[05:11] <axw> natefinch: possibly we can ignore the Bootstrap case, I forget if APIInfo is set at bootstrap time
[05:11] <axw> natefinch: if it is, we should do that
[05:14] <mup> Bug #1589774 opened: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:18] <natefinch> mna, I hate the way we use pointers in our config options and you just have to know if they're expected to be nil or not
[05:20] <mup> Bug #1589774 changed: Ghost models exist after being destroyed <juju-core:Incomplete> <https://launchpad.net/bugs/1589774>
[05:28] <wallyworld> axw: there's other places in the code where we use that args.InstanceConfig.Bootstrap != nil check - they all probably need to be cleaned up a bit
[05:29] <wallyworld> some do use the isController() check
[05:29] <axw> wallyworld: quite possibly. I think in some cases it is valid, e.g. in gce I think we set up a firewall rule that applies to all machines in the model
[05:29] <mup> Bug #1594211 changed: creating hosted model: model already exists <juju-core:New> <https://launchpad.net/bugs/1594211>
[05:30] <wallyworld> axw: yeah, i think it's just a 2 i did - ec2 and openstack. i'll do a drive by in the current pr
[05:30] <wallyworld> *this
[05:30] <natefinch> wallyworld: we really should put helper methods on that struct, rather than relying on institutional knowledge of what it means for one of the values to be nil or non-nil
[05:31] <wallyworld> no argument there, is tech debt
[05:31] <wallyworld> axw: you even have a todo in the rwckspace proviser
[05:32] <wallyworld> damn, can't type
[05:32] <axw> wallyworld: yeah it was broken before I think?
[05:32] <wallyworld> i think so
[05:32] <axw> I think I added a bug for it
[05:32] <wallyworld> axw: i'll fix now and push to the model config pr so we can get it landed
[05:34] <natefinch> axw: thusly? http://pastebin.ubuntu.com/17681411/  Also, do we need to check the length of ports or is it safe to assume it's non-empty?
[05:37] <axw> natefinch: it should always be one-and-only-one. I just noticed that instancecfg.ControllerConfig's Config field has an APIPort() method tho, that's probably more appropriate to use
[05:38] <axw> wallyworld: is ^^ set at bootstrap time?
[05:38] <axw> (I think it should be, if it's not)
[05:38] <wallyworld> axw: i think so, i'm double checking now
[05:38] <wallyworld> as i am doing
[05:38] <wallyworld> 		if isController(args.InstanceConfig) {
[05:38] <wallyworld> 			apiPort = args.InstanceConfig.APIInfo.Ports()[0]
[05:38] <wallyworld> 		}
[05:39] <wallyworld> i deleted the bootstrap bit
[05:39] <natefinch> wallyworld: I tried that and get index out of range at bootstrap.. ports is zero-length
[05:39] <natefinch> wallyworld: at least in the azure tests
[05:40] <wallyworld> the tests may not set things up correctly
[05:40] <axw> wallyworld: tests probably need updating, but I was talking about args.InstanceConfig.Controller.APIPort()
[05:40] <axw> sorry, Controller.Config.APIPort()
[05:40] <wallyworld> jeez we have so many bit of duped data
[05:40] <axw> tell me about it
[05:41] <axw> natefinch: I think you just want this: http://paste.ubuntu.com/17681608/
[05:41] <axw> err, you'll need to assign and take pointer, but you get the idea
[05:42] <wallyworld> axw: yeah, that should work with the recent landing the past few days
[05:42] <natefinch> axw: ControllerConfig doesn't have a Config field
[05:42] <natefinch> unless I'm out of date?
[05:43] <axw> natefinch: must be, it's there on master
[05:43] <natefinch> ha, I guess I anm
[05:43] <axw> https://github.com/juju/juju/blob/master/cloudconfig/instancecfg/instancecfg.go#L160
[05:48] <axw> wallyworld: your branch LGTM, let me know when you've added the fixes
[05:48] <wallyworld> ty, testing live on aws now
[05:49] <natefinch> -y
[05:51] <natefinch> I have to run to bed.  The tests pass, but I don't have time to do a manual test right now... also we should probably add a test that'll ensure this doesn't break again, but I have no clue how to do that with the code as is.
[05:54] <natefinch> will do more manual tests in the morning and see if I can put a unit test in there to catch this if it breaks again.
[05:56] <mup> Bug #1559299 changed: cannot obtain provisioning script <bootstrap> <ci> <manual-provider> <regression> <xenial> <juju-core:Invalid> <juju-core 1.25:Fix Committed by anastasia-macmood> <juju-core api-call-retry:Fix Released by axwalk> <https://launchpad.net/bugs/1559299>
[05:56] <mup> Bug #1575940 changed: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
[06:11] <mup> Bug #1482074 changed: worker:  environSuite.TestInvalidConfig fails on go 1.6 <ci> <go1.6> <intermittent-failure> <unit-tests> <juju-core:Invalid> <juju-core 1.25:Invalid> <https://launchpad.net/bugs/1482074>
[06:12] <mup> Bug #1581579 changed: resource-get fails with duplicate key error <juju-core:Incomplete> <https://launchpad.net/bugs/1581579>
[06:12] <mup> Bug #1588784 changed: juju/state: intermittent test failure in SubnetSuite with mongod 3.2 <mongodb> <unit-tests> <juju-core:Triaged> <https://launchpad.net/bugs/1588784>
[06:46] <wallyworld> axw: pushed, i tested enable-ha on ec2. i also changed azure with no failing tests, not sure what nate was seeing
[06:53] <axw> wallyworld: reviewed
[06:54] <wallyworld> ta
[06:58] <wallyworld> axw: i hit the commit button too soon, that error is fixed. i'll remove the IsController helper - that was there i guess before we had a Controller attribute and had to check jobs
[07:00] <wallyworld> axw: i'm down a rabbit hole with moving DestoryModel() to apiserver/modelmanager. all the stuff in common.modeldestroy.go uses state.State and the tenticles reach into metrics and everywhere. i may have to type cast the api.state attribute on modelmanager facade to state.State for now
[07:05] <urulama_> wallyworld, axw: good evening ... looking at what perrito666 mentioned as a breaking change. is there anything else besides https://github.com/juju/juju/commit/9933a39c799639084bd822ea3ee8e6345131bac7 ?
[07:06] <wallyworld> urulama: well hello. another change we discovered today - i am looking to move DestroyModel() off the client facade onto the ModelManager facade.
[07:07] <wallyworld> i didn'tt hink you wer ehere today?
[07:07] <urulama> wallyworld: i am just happy to have 2 days off :D
[07:07] <wallyworld> that destoy model api is the only one on the client facade, it just should not be there
[07:07] <wallyworld> we have create and list model on the model manager facade already
[07:07] <wallyworld> 2 days off, luxury
[07:11] <axw> wallyworld: there's also a breakage of the CreateModel API call, which I've mailed Francesco about
[07:11] <axw> err urulama^^
[07:11] <axw> urulama: would you like me to forward the details to you?
[07:12] <wallyworld> axw: i did already :-)
[07:12] <axw> ok cool
[07:14] <urulama> ok, thanks, will sync with frankban|afk ... see, even 2 days off is a risk! :D
[07:20] <urulama> wallyworld: do you have a track of all the breaking changes somewhere? as in a list? if not, we'll make it so we don't miss anyone and share it with other clients as well
[07:21] <wallyworld> urulama: it will be complicated by tim's work - there's only one api change as such - create model. well 2 if i can get detroy model landed. but then tim's stuff potentially alters the json attributes all over. i can get a diff of the tag changes
[07:21] <wallyworld> add model i mean
[07:22] <urulama> wallyworld: no, no, not in such detail. tim's change is well defined ... no worries, i'll make a list
[07:25] <rogpeppe> axw: what's changed in the CreateModel API call?
[07:26] <axw> rogpeppe: no more ConfigSkeleton for one thing
[07:26] <rogpeppe> axw: great!
[07:26] <rogpeppe> axw: is the new API documented anywhere?
[07:26] <axw> rogpeppe: there's a "name" field on the params struct now, and it's an error to have it in the config bag
[07:26]  * rogpeppe goes and generates the API docs again
[07:26] <axw> rogpeppe: and you can specify a region and/or credential name, but they'll have defaults if you're an admin
[07:27] <rogpeppe> axw: this has landed, right?
[07:27] <anastasiamac> axw: wallyworld: m meant not to be able to bootstrap maaas on tip of master? m getting with auth-type "oauth1" is not supported (expected one of ["empty"])
[07:27] <axw> rogpeppe: yes, post beta9
[07:27] <anastasiamac> for maas deployment that worked before..
[07:27] <axw> anastasiamac: I'm fixing it
[07:27] <anastasiamac> \o/
[07:27] <axw> anastasiamac: https://bugs.launchpad.net/juju-core/+bug/1593566
[07:27] <mup> Bug #1593566: Bootstrap reports oath1 not supported with maas 2.0 <bootstrap> <cdo-qa> <cdo-qa-blocker> <maas-provider> <juju-core:In Progress by axwalk> <https://launchpad.net/bugs/1593566>
[07:27] <wallyworld> anastasiamac: you need to add auth type to your cloud
[07:28] <axw> rogpeppe: https://github.com/juju/juju/blob/master/apiserver/params/internal.go#L86
[07:28] <anastasiamac> axw: tyvm - trying now
[07:33] <rogpeppe> axw: http://s3.amazonaws.com/rogpeppe-scratch/juju-api-doc.html#ModelManager :)
[07:33] <axw> rogpeppe: nice!
[07:36] <axw> wallyworld anastasiamac: http://reviews.vapour.ws/r/5133/
[07:36] <wallyworld> ok
[07:42] <wallyworld> axw: ty, lgtm
[07:46] <anastasiamac> axw: looking (and workaround worked)
[07:46] <anastasiamac> wallyworld: is it a state of origin night again? \o/
[07:46] <wallyworld> yes indeed
[07:48] <anastasiamac> :)
[08:10] <frankban> wallyworld: this is the mega-wather response I am getting from current master: {'RequestId': 1, 'Response': {'watcher-id': '1'}}
[08:10] <frankban> wallyworld: so it seems that we still have some CamelCase there?
[08:11] <wallyworld> frankban: i think RequestId / Response may be part of the api infrastructure, so maybe missed tim's changes, not sure
[08:12] <frankban> wallyworld: same for the request top level fields, like Params, Request, RequestId, Type, Version
[08:12] <wallyworld> thumper: ^^^^ ?
[08:13] <thumper> that is a different level
[08:13] <thumper> :(
[08:13] <thumper> didn't touch that bit
[08:14] <frankban> thumper: are you going to handle that as well?
[08:14] <thumper> I hadn't thought about it, but could do
[08:15] <thumper> we probably should... right?
[08:15] <frankban> thumper: I think so, as otherwise the API style is still inconsistent
[08:16] <thumper> frankban: ack, will look at it tomorrow
[08:16] <frankban> thumper: thanks!
[08:17] <axw> thumper: I think atm you can connect to a 2.0 server with a 1.25 client, and you'll be told that the client is incompatible. If we totally change the arg casing, that would be broken... or we'd need to handle both
[08:17] <dimitern> frankban: FWIW those RequestId and Response fields are not part of the API contract, but the RPC layer
[08:17] <thumper> axw: yeah... interesting
[08:17] <dimitern> thumper: I was unable to add a machine after your API changes landed
[08:17]  * thumper will consider
[08:18] <dimitern> thumper: some of the decisions re adding omitempty seem inconsistent
[08:19]  * urulama has a feeling that should end up as a breaking test somewhere :-/
[08:19] <dimitern> thumper: and there are a few omissions, e.g. an embedded Entities gets a `json:"entities"` (IIRC GetAgentEntitiesResults?), while an embedded Address in HostPort doesn't
[08:19] <frankban> dimitern: from clients perspective you still get some CamelCase fields and other lower-case ones, which feels inconsistent, and consistency is teh only reasoning for this change
[08:20] <dimitern> frankban: agreed, just saying simply tagging all params types/fields explicitly does not apply to the RPC transport layer
[08:28] <thumper> but we could
[08:29] <thumper> urulama: correct, there should be a test for that
[08:29] <thumper> dimitern: was it an existing controller and a new client?
[08:29]  * thumper should leave
[08:29] <thumper> it's late
[08:30] <frankban> thumper: I am starting the GUI API migration today, should I consider all lower-case then? including RPC top level fields?
[08:30] <thumper> frankban: let's say yes, and I'll let you know if I break too much and can't do it
[08:31] <frankban> thumper: sounds good, thanks a good night
[08:32] <urulama> night, thumper
[08:32] <thumper> night
[08:33] <thumper> urulama: what days are you at the sprint next week?
[08:35] <urulama> thumper: from Sunday evening to Wednesday noon
[08:37] <thumper> cool
[08:37] <thumper> urulama: see you sunday then
[08:37] <thumper> laters
[08:37] <dimitern> thumper: no, newly bootstrapped controller
[08:42] <axw> wallyworld: I'm running out of ideas for a quick-fix for gce. I could do a nasty hack in cmd/juju/commands/bootstrap.go, to convert jsonfile to oauth2
[08:42] <wallyworld> axw: yeah, i was thinking that may haveto be the temporary answer
[08:43] <wallyworld> frankban: moving DestrroyModel off client facade is a pita - but we need to do it. it will likely miss the beta10 cutoff tomorrow
[08:45] <frankban> wallyworld: ah so it will be beta11 ModelManager.Destroy() ?
[08:46] <wallyworld> frankban: i fear so, i will get it done later tonight but then it needs review etc
[08:46] <wallyworld> i will try
[08:46] <frankban> wallyworld: no problem, the GUI will not work for beta10 tomorrow, so there is no rush on our side
[08:47] <wallyworld> ok, let's aim for beta 11. i'll let you know how i go. i first need to debug another issue as well
[08:54] <dimitern> frobware: when you can, please have a look at http://reviews.vapour.ws/r/5134/
[09:01] <frankban> wallyworld: FYI it seems that also all the mega-watcher fields are still CamelCased: for instance http://pastebin.ubuntu.com/17686685/
[09:01] <wallyworld> damn
[09:01] <wallyworld> i'll tell tim
[09:03] <dimitern> frobware, voidspace, jam: standup?
[09:03] <frobware> dimitern: will do
[09:04] <axw> wallyworld:  please to be reviewing: github.com/juju/juju/pull/5692
[09:04] <axw> wallyworld: tested live, bootstrapped gce successfully with a jsonfile cred
[09:06] <wallyworld> sure borat
[09:07] <wallyworld> axw: i'm retesting the api port fix on ec2, am seeing both slave controllers stay pending. seems to be intermittent
[09:07] <axw> wallyworld: hrm, anything in cloud-init-output.log?
[09:08] <wallyworld> just started looking, added debuggin and trying again
[09:08] <axw> wallyworld: ok. I need to go make dinner, will be back in a little while
[09:08] <wallyworld> ok
[09:29] <frobware> dooferlad: please could you try http://reviews.vapour.ws/r/5136/ on your h/w - thanks!
[09:30] <dimitern> frobware: you've got a review btw
[09:31] <frobware> dimitern: ah, yes. will do
[09:31] <dimitern> frobware: ta!
[09:45] <dooferlad> frobware: on it
[10:17] <babbageclunk> dimitern: updated http://reviews.vapour.ws/r/5123/ - have another look?
[10:18] <babbageclunk> cherylj: ping?
[10:18] <dimitern> babbageclunk: I did look briefly, looks much better, thanks!
[10:18] <babbageclunk> dimitern: cheers!
[10:18] <dimitern> babbageclunk: LGTM
[10:30]  * dimitern is out for a while
[10:41] <axw> wallyworld: how goes it?
[10:41] <wallyworld> qld behind 2-4
[10:41] <wallyworld> oh, you mean work
[10:42] <axw> wallyworld: heh yeah :)
[10:43] <wallyworld> axw: have interfaces / mocks more or less sorted for moving destory model. having a mix of state.State and interfaces sorta sucks
[10:44] <axw> wallyworld: the api-port thing though? sorted?
[10:45] <wallyworld> axw: yeah, so this is an existing issue - config that comes via an api call has ints unmarshalled as float64 and mustInt() fails
[10:46] <wallyworld> we just have never come across it
[10:46] <axw> wallyworld: I just saw your change. I'm sure we handle that in schema.Coerce. maybe related to the recent introduction of controller.Config?
[10:46] <axw> does that *always* go through schema.Coerce, or only at bootstrap time?
[10:46] <wallyworld> the latter i think
[10:47] <wallyworld> i can do a better change for beta 11 if needed
[10:47] <axw> wallyworld: yeah that's what I thought. I think we can back that change out when controller config is fully separated
[10:47] <wallyworld> yep, will do for now to unblock the beta
[10:48] <axw> wallyworld: yeah no worries, I'd just like to simplify later if possible. all good for now
[10:48] <wallyworld> +1
[11:16] <babbageclunk> dimitern: ping?
[11:27] <dimitern> babbageclunk: pong
[11:28] <babbageclunk> dimitern: hey - I was trying to understand the tests in https://github.com/juju/juju/blob/master/cmd/juju/status/status_test.go#L338
[11:28] <babbageclunk> dimitern: Why are they written like this (as series of steppers) instead of function calls?
[11:29] <dimitern> babbageclunk: they're almost like defined in their own DSL
[11:30] <dimitern> babbageclunk: well, I did that after getting excited about how the uniter tests were written at that time
[11:30] <dimitern> babbageclunk: but now I wouldn't have done it like this
[11:30] <babbageclunk> dimitern: But why not just function calls for the different kinds of steps?
[11:30] <babbageclunk> dimitern: ok - I think I follow.
[11:31] <dimitern> babbageclunk: as for debugging tips - since everything is one big table-based test, it's best to comment out all cases you don't care about (temporarily)
[11:31] <babbageclunk> dimitern: yeah, that sounds v useful
[11:32] <dimitern> to reduce the insane amount of cruft you need to sift through on failure
[11:33] <babbageclunk> dimitern: should be ok though - my new fields only show up if they're populated, so adding them shouldn't break any other tests.
[11:34] <dimitern> babbageclunk: yeah, it sounds like you need to add 2 cases only - to exercise application workload-version w/ and w/o '*' suffix
[11:35] <babbageclunk> dimitern: Do you think I need to test the suffix again here? I'm not doing any formatting at the command level.
[11:35] <dimitern> babbageclunk: however, if 'workload-version' is not json-tagged as ',omitempty', you'd need to change all existing cases to include an empty w-v
[11:37] <babbageclunk> dimitern: It seemed right to tag workload-version as omitempty, though - otherwise it'll be noise for all the charms that don't set it (all of them at the moment).
[11:37] <dimitern> babbageclunk: I think it's good to test both cases, for completeness, and they can act like functional/integration tests for the feature
[11:37] <babbageclunk> dimitern: Yeah, fair enough. Not very hard to.
[11:38] <dimitern> babbageclunk: charms won't be affected - mostly tests with pre-canned 'expected' responses could be affected
[12:03] <mup> Bug #1592101 changed: Error connecting with cached addresses <juju-core:Fix Released> <https://launchpad.net/bugs/1592101>
[12:03] <mup> Bug #1575940 opened: LXC containers under MAAS get no "search <domain>" entry in resolv.conf when deployed with juju2 <cdo-qa-blocker> <landscape> <juju-core:Incomplete> <https://launchpad.net/bugs/1575940>
[12:03] <mup> Bug #1595155 opened: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[12:09] <mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:24] <frankban> wallyworld: FYI Client.CharmInfo response is still in camel case, maybe I should write an email to Tim with my findings
[12:26] <wallyworld> frankban: that would be most excellent
[12:27] <frankban> wallyworld: doing that, I'll send it before my EOD
[12:27] <dimitern> frankban: try adding a machine as well
[12:28] <frankban> dimitern: do you want me to try if it works?
[12:28] <dimitern> frankban: I found that to be broken; e.g. 'juju add-machine --series trusty' or 'add-machine lxd:0'
[12:28] <frankban> dimitern: ok I'll look if I can add a machine through the API
[12:29] <dimitern> frankban: yes, please, if you can - I'm still not sure if the above is maas-specific (where I've seen it after thumper's change) or not..
[12:30] <mup> Bug #1575448 opened: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:33] <frankban> dimitern: it seems to be working on lxd: http://pastebin.ubuntu.com/17693847/
[12:33] <mup> Bug #1575448 changed: trusty juju 1.25.5 HA availability issues <canonical-bootstack> <juju-core:Fix Released by anastasia-macmood> <juju-core 1.25:Fix Committed by anastasia-macmood> <https://launchpad.net/bugs/1575448>
[12:34] <dimitern> frankban: hmm.. is that the correct version for 2.0 btw?
[12:35] <dimitern> frankban: thanks for confirming though, it seems it might be maas-specific
[12:35] <frankban> dimitern: what do you mean correct version for 2.0?
[12:39] <dimitern> frankban: I though all API facade versions where incremented in juju 2.0
[12:40] <dimitern> frankban: so seeing Version: 1 in your paste seemed wrong, but I'm not sure if the Client facade version was also bumped
[12:41] <frankban> dimitern: I am not aware of any version bump in juju2, here are the facades returned when logging in: http://pastebin.ubuntu.com/17694260/
[12:43] <perrito666> wow the test suite really kills my laptop
[12:44] <dimitern> frankban: well, comparing this to 1.25 you'll notice the bumps
[12:45] <dimitern> frankban: but I've just remembered Client was originally Version: 0
[12:45] <frankban> dimitern: sure, but Client is version 1
[12:45] <frankban> dimitern: cool ok
[12:58] <frobware> cherylj: do I need extra extra extra magic runes for landing in 1.25? - https://github.com/juju/juju/pull/5693
[12:59] <cherylj> frobware: you just have to really mean it
[12:59] <cherylj> $$__JFDI__$$
[12:59] <frobware> cherylj: ohhhhhhhhhh
[12:59] <frobware> duh
[12:59] <frobware> ok
[12:59] <cherylj> :)
[13:00] <dimitern> it still looks like $$__JEDI__$$ to me :D
[13:04] <frobware> dimitern: remind me again... do I care about removing "vlan_id" from the iface options?  Just porting from 1.25 and want to make sure I don't drop anything along the way.
[13:05] <dimitern> frobware: no, because it's invalid anyway and will be ignored
[13:05] <dimitern> frobware: curtin is to blame for adding it
[13:07] <fwereade> babbageclunk, katco: https://github.com/juju/juju/pull/5695 doesn't seem to have been picked up by RB, but should be trivial
[13:12] <dimitern> frobware: updated http://reviews.vapour.ws/r/5134/
[13:12] <dimitern> voidspace, babbageclunk, dooferlad: I'd appreciate a second look on the above as well
[13:21] <frobware> dimitern: done
[13:35] <dimitern> frobware: thanks!
[13:58] <perrito666> I am getting a lot of timeouts on my tests, did the mongo --nojournal fix land in master?
[14:31] <dimitern> frobware: ping
[14:31] <frobware> dimitern: pong
[14:31] <dimitern> frobware: let me know what you think about my response on your review
[14:31] <frobware> dimitern: does the last or first 'search' win?
[14:31] <dimitern> frobware: the last apparently
[14:32] <frobware> dimitern: <shrug> - ok
[14:32] <dimitern> frobware: how about those 4 points btw?
[14:32] <frobware> dimitern: looking. everthing is so well defined. Not.
[14:33] <dimitern> frobware: yeah, that's the issue I think - not completely defined spec leads to permissive implementations :)
[14:33] <frobware> dimitern: is this valid "nameserver <IP_ADDRESS> <IP_ADDRESS>" without trailing comments?
[14:33] <dimitern> frobware: no
[14:34] <dimitern> frobware: (as far as 'host' is concerned at least.. nslookup as well, haven't tried all dns clients :)
[14:34] <frobware> dimitern: so is search the only one we should then consider as it seems more permissive (e.g., "search foo foo.bar maas. ;baz #bad (baz and bad are ignored)")
[14:36] <frobware> dimitern: any /etc/resolv.conf I edit by hand I always put nameserver entries on a line by themselves.
[14:36] <frobware> dimitern: search not so, hence why I was asking
[14:36] <dimitern> frobware: neither search nor nameserver are defined as allowing comments after the values.. interestingly enough vim's syntax highlighting seems to catch most of the corner cases I tried
[14:37] <frobware> dimitern: whodathunkit!
[14:38] <dimitern> frobware: so, anyway - if those 4 suggestions for changing the behavior seem reasonable, I'll do them and let's get it landed
[14:39] <frobware> dimitern: I responded in the review - ok for some, the others I simply dunno.
[14:40] <dimitern> frobware: '(2.1) disagree' - meaning it should be a parse error out of ParseResolvConf() or we should allow multiple values and not ignore the whole line?
[14:41] <frobware> dimitern: I don't think we should allow multiple values per nameserver entry. separate lines, but this is just based on the way I've always done it.
[14:41] <frobware> dimitern: what a mess
[14:41] <dimitern> :)
[14:41] <frobware> dimitern: drop all searches, use <IP_ADDRESS>. :-D
[14:42] <dimitern> frobware: It was surprising for me that IPv6 addresses are not allowed for nameserver btw
[14:42]  * frobware thinks the problem with free form text is you now have two problems
[14:42] <dimitern> yeah..
[14:43] <dimitern> https://xkcd.com/927/
[14:43] <frobware> dimitern: it's missing several orders of magnitude.
[14:44] <dimitern> frobware: hmm.. so re IPv6 it's deeper than that
[14:44] <frobware> dimitern: or wider. :-D
[14:46] <natefinch> OMG azure is so slow
[14:47] <dimitern> `With BIND 8.3.3, the DNS client can connect to IPv6 DNS servers using an IPv6 transport. To enable such a connection, enter an IPv6 address after nameserver in the resolv.conf file.`
[14:47] <dimitern> ffs..
[14:47] <dimitern> nothing can be easy, can it
[14:49] <frobware> dimitern: what does "after" mean here/
[14:50] <dimitern> frobware: after 'nameserver'
[14:50] <frobware> dimitern: on a new line?
[14:50] <frobware> dimitern: so you need context whilst parsing?
[14:50] <dimitern> frobware: ha:)
[14:51] <dimitern> frobware: well it seems to accept 'nameserver ::1' (it doesn't listen there, so it gets ignored)
[14:51] <frobware> dimitern: given where we are with IPv6 I would concentrate on rock-solid IPv4.
[14:51] <dimitern> frobware: but not '2001:db8::1' (fair enough - it's from the range reserved for examples)
[14:52] <dimitern> frobware: I vote for accepting single value IPv6 nameservers
[14:52] <frobware> dimitern: me too, that catches ::1
[14:52] <dimitern> frobware: but return parse errors in the other 3 sub-cases of 2)
[14:53] <frobware> dimitern: how bad/common is 2.3?
[14:53] <dimitern> frobware: rather than ignoring them
[14:53] <frobware> dimitern: 2.4 should be harmless - we do nothing
[14:53] <dimitern> frobware: dunno.. but it can be an honest mistake I guess
[14:54] <frobware> dimitern: but there's nothing for us to add so we accept and move on
[14:54] <frobware> dimitern: if I have 'search    #oops I forgot!' - we add parse but add no domain, correct?
[14:55] <frobware> dimitern: *nix is hard to tool sometimes... :(
[14:56] <dimitern> frobware: so missing values are definitely not allowed (explicitly stated in resolv.conf(5)) and cause parse errors
[14:56] <natefinch> why oh why do I have to switch to the controller model to run enable-ha?  It's not a model command, it's a controller command :/
[14:56] <frobware> dimitern: well, that helps!
[14:57] <frobware> dimitern: dem da rulez!
[14:57] <dimitern> frobware: re 'search #oops I forgot' - the same as no value as far as 'host' is concerned
[14:58] <dimitern> frobware: and I'd rather return an error in all cases of 2), but still allow 2.2) (ipv6 addrs)
[14:58] <frobware> dimitern: do we consider the "domain" keyword at all?
[14:59] <dimitern> frobware: there are 2 additional limitations, which I won't even bother to handle specifically - more than 3 nameserver and more than 6 domains in 'search' (or len of all values >256)
[14:59] <frobware> dimitern: ah, well I think we should leave the limitations up to resolvconf
[15:00] <dimitern> frobware: not yet ('domain' is mutually exclusive with 'search' per the spec)
[15:00] <frobware> dimitern: if those rules change we would have to change juju - which seems wrong
[15:00] <dimitern> frobware: exactly
[15:01] <dimitern> frobware: and returning parse errors is better than silently ignoring a bad resolv.conf (when we can tell the user about it)
[15:01] <frobware> dimitern: ok, but I think 'domain' is something we should consider - last one wins (either search or domain)
[15:01] <katco> natefinch: standup time
[15:01] <dimitern> frobware: yeah, when we add support for 'domain', that's what we should do I think
[15:02] <frobware> dimitern: with the additional DNS support in MAAS 2.0 is this something we can potentially get?
[15:03] <dimitern> frobware: that depends on whether maas/cloud-init/curtin renders resolv.conf including 'domain' (not seen this thus far)
[15:04] <frobware> dimitern: me neither
[15:04] <frobware> dimitern: but I don't use MAAS 2.0 very much
[15:06] <dimitern> frobware: I mostly test on 2.0 now
[15:07] <frobware> dimitern: which is good because between us we cover both
[15:49] <natefinch> cherylj: want me to look at https://bugs.launchpad.net/juju-core/+bug/1595155 ?
[15:49] <mup> Bug #1595155: new systemd and dbus dependencies are broken <blocker> <juju-core:Triaged> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1595155>
[15:53] <cherylj> natefinch: we're talking about that now and it may not be an issue
[15:55] <cherylj> natefinch: can you backport the fix for bug 1581157?
[15:56] <mup> Bug #1581157: github.com/juju/juju/cmd/jujud test timeout on windows <blocker> <ci> <regression> <test-failure> <unit-tests> <windows> <juju-core:Fix Committed by natefinch> <juju-core 1.25:Triaged> <https://launchpad.net/bugs/1581157>
[16:06] <natefinch> cherylj: sure
[16:08] <perrito666> bbl
[16:21] <frobware> dimitern, babbageclunk, dooferlad, voidspace: forward port of the bridge script changes from 1.25: http://reviews.vapour.ws/r/5140/
[16:22] <dimitern> frobware: will look shortly
[16:23] <frobware> dimitern: thanks; will check back later
[16:23] <babbageclunk> frobware: looking now
[16:27] <frobware> babbageclunk: the essence of the change is 1) revert to using ifdown and 2) that means the real diff is like this: http://pastebin.ubuntu.com/17704158/
[16:27] <frobware> babbageclunk: the revert to using ifdown is commit http://pastebin.ubuntu.com/17704158/
[16:28] <frobware> babbageclunk: and the other change is http://pastebin.ubuntu.com/17704233/
[16:28] <frobware> dimitern: ^^
[16:32] <dimitern> frobware: LGTM
[16:52] <mup> Bug #1595252 opened: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:New> <https://launchpad.net/bugs/1595252>
[16:57] <natefinch> cherylj: backport is pending merge into 1.25.  Anything else I should look at?  I have limited time left today, due to taking a half day, but willing to start work on something that is ok to finish tomorrow.
[16:58] <cherylj> natefinch: I'll find something for you to pick up when you come back tomorrow :)
[17:03] <dimitern> frobware: still there?
[17:03] <frobware> dimitern: nope
[17:03] <frobware> dimitern: well, very briefly
[17:04] <dimitern> frobware: I'm finally done with the changes, pushing hopefully the final version, as discussed - wanna have a last look before I set it to land?
[17:04] <frobware> dimitern: might have to be later - we can land tomorrow
[17:05] <dimitern> frobware: ok
[17:05] <frobware> dimitern: did you push the changes?
[17:07] <dimitern> frobware: any minute now..
[17:07] <dimitern> frobware: done
[17:52] <mup> Bug #1595276 opened: TestDestroyControllerErrors failure with out of order errors <azure-provider> <ci> <intermittent-failure> <test-failure> <juju-core:Triaged> <https://launchpad.net/bugs/1595276>
[18:04] <mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Triaged by wallyworld> <https://launchpad.net/bugs/1593812>
[18:04] <mup> Bug #1595278 opened: Openstack invalid port range 0:0 <blocker> <ci> <openstack-provider> <regression> <juju-core:Triaged> <https://launchpad.net/bugs/1595278>
[18:48] <jhobbs> Is there a working juju daily ppa somewhere? https://launchpad.net/~juju/+archive/ubuntu/daily looks like it's out of date. I need to get a close to tip juju and I was hoping for a PPA so I don't need to learn how to build it
[19:04] <mup> Bug #1595252 changed: regression b8-b9, ERROR empty admin-secret in model configuration <azure-provider> <deploy> <juju-core:Invalid> <https://launchpad.net/bugs/1595252>
[19:22] <cherylj> jhobbs: you can get the binaries built from our last CI run:  http://reports.vapour.ws/releases/4092/binaries
[19:22] <jhobbs> thanks cherylj
[19:26] <cherylj> katco: would you be able to review this today?  https://github.com/juju/juju/pull/5057
[19:27] <katco> cherylj: let me see how big it is
[19:27] <katco> cherylj: errrr a bash script...
[19:28] <katco> cherylj: i'll give it a go
[19:30] <katco> cherylj: wow, i'm not well versed enough in bash to do this thing justice
[19:32] <katco> cherylj: sorry, someone who knows bash will have to TAL.
[19:34] <mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:34] <mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[19:40] <mup> Bug #1593394 opened: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:40] <mup> Bug #1593812 opened: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[19:43] <mup> Bug #1593394 changed: model already exists but can't be destroyed because it's not found - lots of "lease manager stopped" errors <v-pil> <juju-core:Triaged> <https://launchpad.net/bugs/1593394>
[19:44] <mup> Bug #1593812 changed: Failed to bootstrap: missing controller UUID <blocker> <bootstrap> <juju-gui> <juju-core:Fix Released by wallyworld> <https://launchpad.net/bugs/1593812>
[20:08] <mup> Bug #1595314 opened: maas controller.go:80 read version failed: &errors.Err{message:"", cause:(*json.SyntaxError)(0xc82040a1a0), previous:(*errors.Err)(0xc8202b6c30) <juju-core:New> <https://launchpad.net/bugs/1595314>
[20:13] <cherylj> jhobbs: ping?
[20:13] <jhobbs> hi cherylj
[20:13] <cherylj> hey there.  Regarding bug #1594958
[20:13] <mup> Bug #1594958: Bootstrapping on OpenStack fails with juju 2 <v-pil> <juju-core:Incomplete> <https://launchpad.net/bugs/1594958>
[20:13] <cherylj> are you using exactly "--config image-metadata-url=<url>" ?
[20:14] <jhobbs> cherylj: the command i ran is in the pastebin
[20:14] <jhobbs> http://paste.ubuntu.com/17713435/
[20:14] <jhobbs> i'm using --config --image-metadata-url
[20:14] <jhobbs> i see
[20:14] <jhobbs> doh
[20:14] <jhobbs> thanks for pointing that out
[20:14] <cherylj> ah yeah, sorry.  Missed the link
[20:15] <jhobbs> i will try again with the right argument, thanks
[20:16] <cherylj> np, feel free to ping me here if you have other problems.
[21:22] <wallyworld> ericsnow: it seems there's a core issue about recording last sent id vs timestamp - once sorted out, we're close to being able to land stuff?
[21:23] <ericsnow> wallyworld: yep
[21:23] <mup> Bug #1595330 opened: When deploying a bundle, num_units defaults to zero if not specified <bundles> <juju-release-support> <usability> <juju-core:Triaged> <https://launchpad.net/bugs/1595330>
[21:23] <wallyworld> ericsnow: i do like id - if they are monotonically increasing, it's unambiguous
[21:24] <ericsnow> wallyworld: yep
[21:28] <katco> wallyworld: i was ocr today; spent first half reviewing, then worked on observer PR. making good headway there
[21:28] <wallyworld> awesome
[21:50] <redir> katco: are you accessing user info anywhere for auditing?
[21:51] <katco> redir: kind of. the observers for auditing hold current api user in state
[21:51] <katco> redir: but just the tag's name
[21:54] <redir> katco and there's no way that you would lookup a user after the fact, IIUC.
[21:55] <redir> katco: making sure there's no impending need to access deleted user information.
[21:56] <redir> and auditing is the only place I can think of where that might happen in the near future.
[21:57] <katco> redir: no, i don't think so. the audit message would include the user name as a string, so no dereferencing needed
[22:02] <alexisb> thumper, ping
[22:15] <redir> going for some air. bbiab.
[22:16] <anastasiamac> natefinch: ping
[22:30] <wallyworld> menn0: very tiny change to modify slightly a previous fix if you have a sec (blocker for beta 10) http://reviews.vapour.ws/r/5143/
[22:30] <menn0> wallyworld: looking
[22:32] <menn0> wallyworld: ship it
[22:33] <wallyworld> menn0: tyvm
[22:49] <mgz> wallyworld: I think you're misreading the bug
[22:50] <mgz> you don't need to set the port everywhere, you just can't pass an uninitialised int over the api
[22:50] <mgz> because that's a zero
[22:50] <wallyworld> mgz: i just reverted to previous behaviour
[22:51] <mgz> wallyworld: yeah, the fix is fine. the review description is just perplexing
[22:51] <mgz> non-controllers don't need the api port opened
[22:51] <mgz> they just need to not be told to open an invalid port range
[22:51] <wallyworld> which we were always doing
[22:51] <wallyworld> ie opening port
[22:52] <wallyworld> so least risk just to go to old behaviour for now
[22:52] <mgz> wallyworld: yeah, I agree
[22:52] <wallyworld> but i agree with you too
[22:52] <mgz> the right fix is presumably to change SetUpGroups or something though
[22:52] <mgz> but that doesn't need to happen here
[22:56] <wallyworld> mgz: yeah, it's all a bit messed up
[23:07]  * thumper crosses fingers
[23:16] <alexisb> thumper, ??
[23:17] <thumper> alexisb: trying to get something to work
[23:17] <thumper> btw, it isn't working
[23:17] <alexisb> should I cross my fingers too?
[23:17] <alexisb> would that help
[23:19] <thumper> maybe...
[23:24] <thumper> I'm pleased that lxd bootstraps so fast...
[23:24] <thumper> if 2 minutes is fast
[23:24]  * thumper waits some more
[23:29] <thumper> hmm...
[23:29] <thumper> kinda working
[23:29] <thumper> but I have surprising data...
[23:30] <alexisb> surprising how
[23:31] <thumper> unexpected
[23:31] <thumper> I need to work out how to pull this apart...


[03:39] <Andre_Gondim> when i reported some bug, may I change in launchpad the release nominate? or it's only the sponsor can do this?
[03:40] <Andre_Gondim> when i report some bug, may I change in launchpad the release nominate? or it's only the sponsor that has to do this?
[03:43] <wgrant> Andre_Gondim: I don't understand what you're asking. Can you rephrase it?
[03:46] <Andre_Gondim> wgrant, at this https://bugs.edge.launchpad.net/ubuntu/+source/gwibber/+bug/344426 I changed the release nominate. May I could do this or only the sponsor that has to do this?
[03:47] <Ursinha> wgrant: he set the +nominate
[03:54] <wgrant> Andre_Gondim: The release manager (driver) of the series has to approve/decline that.
[08:41] <savvas> https://answers.edge.launchpad.net/someproject/+createfaq <- the keywords are separated with spaces or with commas?
[08:43] <wgrant> savvas: It strips out commas, so I presume it uses spaces natively.
[08:43] <savvas> thanks :)
[08:43] <savvas> it should be mentioned however :P
[08:44] <wgrant> It should. You could file a bug.
[08:44] <savvas> I will :)
[08:55] <savvas> bug 346247
[08:55]  * wgrant retargets it.
[08:56] <savvas> there's a launchpad-answers project? sorry :\
[08:58] <wgrant> launchpad is sort of the gateway project, where you can file bugs and somebody will eventually redirect them to the right project.
[08:58] <wgrant> Since it's often hard to work out which bugs belong to which team.
[10:12] <kblin> morning folks
[10:16] <kblin> ah, there it is.. even before asking the question. thanks.
[10:18] <wgrant> I like questions like that.
[10:18] <ronny> gmb: sup?
[13:16] <kwah> hi, everyone...
[13:17] <kwah> we try to reclaim ID for the LoCo team, but got no answer so far
[13:17] <kwah> https://answers.edge.launchpad.net/launchpad/+question/64313
[13:18] <kwah> are there other ways we can contact LP admins (I believe they are ones we need to reach with this Quest)
[13:20] <cody-somerville> kwah, an admin is assigned to it
[13:21] <wgrant> Said admin tends to be very busy, and it has only been a couple of working days.
[13:22] <kwah> cody-somerville, thanks
[13:22] <kwah> wgrant, I understand, but there is no indication what so ever how much such a request may take
[13:23] <kwah> and we are currently in the reorganization phase and aiming for the next loco council to get approved
[13:23] <kwah> did not mean to offense anyone
[14:37] <gnomefreak> is it possible to use security target? example debian/control <hardy-security> for PPA?
[14:37] <gnomefreak> sorry debian changelog
[15:18] <magcius> Can the launchpad team simplify installing PPA keys easier?
[15:18] <magcius> I can't just wget | apt-key add -
[15:26] <LarstiQ> magcius: gpg --recv-key | apt-key add -?
[15:26] <LarstiQ> or well
[15:26] <LarstiQ> export inbetween
[15:27] <magcius> LarstiQ, mind explaining it a bit more in your instructions?
[15:28] <LarstiQ> magcius: the way I'd normally get a key is by asking gpg to retrieve it from the keyservers
[15:28] <magcius> Ah, so I must use --keyserver.
[15:44] <maxb> The cryptic oneliner is:
[15:44] <maxb> apt-key adv --keyserve keyserver.ubuntu.com --recv-key KEYID
[15:44] <maxb> Oops, --keyserver
[15:45] <magcius> Wait... apt-key uses PGP? I thought it used RSA
[15:46] <LarstiQ> maxb: oh hey, nice, didn't know apt-key adv
[15:46] <maxb> Your question is rather unclear. PGP is a software framework, RSA is an algorithm
[15:46] <maxb> LarstiQ: Yeah, obscure, but so useful! I've put that command into the description of the mercurial-snapshots PPA
[15:47] <maxb> For my own PPA I made a *-keyring package. I'm not sure which I like better
[16:57] <thrope> hi - is there a dashboard type screen where I can see a list of my projects?
[16:57] <thrope> it is a bit annoying having to search for them each time even when i am logged on
[18:26] <savvas> I think the copy and rebuild actions in PPA don't work
[18:28] <savvas> I copied luckybackup from https://launchpad.net/~medigeek/+archive/ppa to https://launchpad.net/~luckybackup-maintainers/+archive/ppa - it didn't rebuild the .deb source: http://ppa.launchpad.net/luckybackup-maintainers/ppa/ubuntu/pool/main/l/luckybackup/
[18:29] <savvas> * I copied and asked to rebuild from copied source
[18:31] <savvas> I think it's because I copied them before, I'll delete the packages and try again in 15-30 minutes
[19:19] <aantn> hello
[19:19] <aantn> is it possible to change a project's url
[19:20] <aantn> I want to change https://launchpad.net/gnome-doc-centric-playground to https://launchpad.net/gnome-zeitgeist
[19:27] <aantn> are there any launchpad admins in here? :(
[19:31] <jpds> aantn: Please file the request here: https://answers.launchpad.net/launchpad/+addquestion
[19:31] <aantn> jpds: thanks!
[19:32] <jpds> aantn: And an admin will get round to you when they have time.
[19:32] <aantn> jpds: ok
[20:37] <hanska> hello people
[20:37] <hanska> I'm working on an interface to the LP API
[20:37]  * intellectronica is curious
[20:37] <intellectronica> hanska: tell us more :)
[20:38] <hanska> is there any way to have info from https://launchpad.net/ubuntu/jaunty/+queue ? I'm missing it from the docs!
[20:39] <intellectronica> hanska: i don't think so
[20:40] <intellectronica> hanska: please file a bug on soyuz so that this can be considered for scheduling
[20:48] <hanska> intellectronica: I will do, thank you.
[20:48] <hanska> (d'oh. I started launchpad-sharp just to programmatically watch Debian and Jaunty's NEW... I succeeded with Debian's, but now... :P)
[20:52] <hanska> intellectronica: https://bugs.launchpad.net/soyuz/+bug/346491 , thank you :)... how come you were so interested on API implementation? :P
[20:53] <hanska> ahah, funny :), I didn't know about ubottu :P
[20:53] <intellectronica> hanska: i do a lot of the work on the bugs portion of the api
[20:54] <intellectronica> also in general we're interested in how people use the api
[20:54] <hanska> ah, great
[20:54] <hanska> intellectronica: well, I started a little project to watch the NEW queue in Debian (I'm a Debian maintainer/DD in the next few months I hope), then I decided to give it the ability of watching Ubuntu too
[20:55] <intellectronica> also, so far we only have a python interface library. having a library that runs on the CLR would be awesome
[20:55] <hanska> ..and I fell off LP API. It looked a bit weird (and I had some difficulties implementing it, at the beginning, because I wasn't completely understanding it)
[20:55] <intellectronica> hanska: sounds very cool
[20:55] <hanska> I still have _lot_ to do, i.e. I can only make GET requests atm
[20:55] <hanska> but is kinda usable, at least I can get /beta/bugs/xx :)
[20:56] <intellectronica> hanska: you should look at the launchpadlib sources. it's a great example of how you can generate the entire library from the WADL
[20:57] <intellectronica> hanska: if you have any questions about this sort of stuff, talk to leonardr. i'm sure he'll be glad to help you
[20:57] <hanska> intellectronica: thank you, I'm going to download launchpadlib :)
[20:57] <intellectronica> hanska: i think kfogel and mrevell might be interested in hearing about this project too. you could get some publicity :)
[20:58] <intellectronica> hanska: is your project hosted on LP?
[20:58] <hanska> intellectronica: eheh, I would like to make it some more usable first -- I just found out the api-docs _tonight_
[20:58] <hanska> intellectronica: nope, I'm not a bzr fan :)
[20:58] <intellectronica> ah, that's a shame. where is it hosted, then?
[20:58] <kfogel> hanska: what intellectronica said
[20:58] <kfogel> :-)
[20:58] <kfogel> (re interest in API projects)
[20:59] <hanska> intellectronica: nowhere currently, a friend is setting up a redmine on his own server for other projects, and I'll put those two projects (watch-new and launchpad-sharp) there
[20:59] <hanska> intellectronica: too bad you don't host git too :P
[21:00] <intellectronica> hanska: watch this space ;)
[21:00] <intellectronica> what's redmine?
[21:01] <Nafallo> looks like some kind of trac clone to me? :-)
[21:01] <Nafallo> is that about right?
[21:01] <hanska> Nafallo: right, my friend said "better than trac" :P
[21:01] <hanska> Nafallo: I don't really know it, I'm sorry
[21:01] <hanska> (it's written in Ruby, and I'm more a c#-python'er, so I'd tend to avoid it ;)
[21:01] <Nafallo> written in ruby by the looks of it
[21:01] <intellectronica> hanska: b.t.w, not that i have anything against C#, but did you try using launchpadlib with ironpython?
[21:01] <Nafallo> heh
[21:02] <intellectronica> hanska: also, did you consider using the Launchpad bug tracker? you can use it even if you host your code elsewhere
[21:02] <hanska> intellectronica: not really
[21:02] <intellectronica> may i ask why?
[21:03] <hanska> oh my wait :)
[21:03] <hanska> not really was re ironpython
[21:03] <intellectronica> ah ok
[21:03] <hanska> about using the tracker.. well, LP has some good features (I'm thinking at moving bash-completion tracking there), but seems like redmine can directly mangle bugs from commit logs
[21:04] <pecisk> anyone here? What is difference between 'Display name' and 'Title' in project registration form?
[21:04] <Nafallo> hehe. someone put intellectronica in powersave mode! ;-)
[21:04] <hanska> intellectronica: apart from splitting code hosting and bug tracking (I'd do that for bash-completion nevertheless, since Debian's Alioth ReallySucks®), that would be a nice thing I'd miss in LP
[21:04] <cody-somerville> hanska, It wouldn't be too difficult to do that with launchpad and bazaar plugins
[21:04] <hanska> Nafallo: throttle him down!
[21:04] <hanska> cody-somerville: uhm?
[21:05] <cody-somerville> closing of bugs from bzr commits
[21:06] <hanska> cody-somerville: yes, but you're missing I'm already hosting it in git
[21:07] <intellectronica> pecisk: display name: "Foobarizer", title: "An free, object-oriented, optimizing foobarizer for Linux"
[21:07] <pecisk> ok, got it
[21:07] <pecisk> thanks ;)
[21:07] <hanska> intellectronica: whoa, I was missing yet another foobarizer!
[21:07] <hanska> $ foobarize intellectronica
[21:07] <LarstiQ> hanska, Nafallo: redmine gets the dvcs model better than trac does
[21:08] <hanska> LarstiQ: seems like you know it -- in what ways?
[21:08] <intellectronica> this time we're going to do it right, though. it will be self-hosting foobarizer, and it will contain a complete implementation of emacs
[21:08] <hanska> LarstiQ: also, I know a single installation can handle multiple projects (each with a wiki, a tracker, [..])
[21:08] <LarstiQ> hanska: in that it actually understands more than one branch :)
[21:09] <hanska> ah, nice!
[21:09] <LarstiQ> hanska: really, trac is just horrible in this regard
[21:09] <hanska> LarstiQ: does it also make nice graphs out of this? (like gitk/gitg/github?)
[21:09] <LarstiQ> hanska: I don't know (it that well)
[21:10] <LarstiQ> hanska: I know gitk, and of github, but I'm not really a git person
[21:11] <hanska> LarstiQ: I see. But "branch graphing" would be useful for other branch-supporting-VCS'es, no?
[21:11] <LarstiQ> hanska: I guess, maybe.
[21:12] <intellectronica> bzr gtk has a very nice graphing interface
[21:12] <intellectronica> i hope LP will have something like that soon
[21:12] <LarstiQ> hanska: I'm more a fan of offline tools, svn/cvs need something like trac because they're centralized, why would a dvcs need the same crutch?
[21:13] <hanska> intellectronica: uh, I didn't know bzr gtk!
[21:13] <intellectronica> yeah, it's awesome, you should check it out
[21:13] <LarstiQ> hanska: so, gitk or bzr viz/qlog, or the mercurial equivalents
[21:13] <hanska> LarstiQ: s/gitk/gitg/, far better IMVHO
[21:15] <LarstiQ> hanska: is that a gtk rework instead of tk?
[21:15] <hanska> LarstiQ: exactly.
[21:16] <LarstiQ> hanska: ah, I see how that can be far better :)
[21:16] <hanska> eheh :P
[21:17] <LarstiQ> hanska: honestly, it's a mystery to me why tk was used in the first place?
[21:17] <hanska> LarstiQ: who knows, some nostalgic?
[21:18]  * hanska runs away
[21:18] <LarstiQ> hanska: heh, maybe :)
[21:18] <mneptok> for what? bad 60s acid trips?
[21:30] <ronny> tk is weird, but it seems it was fairly easy to add
[21:30] <ronny> unfortunately it still is like 70es today
[22:30] <cocooncrash> Hi, I have some questions about shared and stacked repositories in Launchpad.
[22:30] <cocooncrash> Does anyone know how Launchpad uses these?
[22:31] <LarstiQ> cocooncrash: afaik, Launchpad doesn't use shared repositories, and it (can/does) stack on the branch associated with the development focus
[22:32] <cocooncrash> LarstiQ: Does stacking require that you use a repo format which supports it?
[22:32] <LarstiQ> cocooncrash: certainly on the Launchpad side, I don't know about the client.
[22:33] <cocooncrash> LarstiQ: That's what I'm trying to find out ;-)
[22:33] <cocooncrash> Thanks though
[22:33] <LarstiQ> shouldn't be hard to test though?
[22:34] <cocooncrash> LarstiQ: I do see messages about stacking, but how do I know if it's actually been done?
[22:35] <wgrant> cocooncrash: You can check the branch page on Launchpad - if it is a stacked branch, it will say 'Stacked on: lp:~path/to/branch'
[22:36] <cocooncrash> wgrant: Cool, thanks
[22:36] <cocooncrash> wgrant: Do you know if LP uses shared repos?
[22:36] <wgrant> cocooncrash: It requires that the stacked branch has at least format 1.6. It will try to convert automatically if it's incompatible.
[22:36] <wgrant> It doesn't.
[22:36] <cocooncrash> Okay
[22:36] <wgrant> But you don't really need those once you have stacking.
[22:36] <cocooncrash> Yeah, true
[22:37] <cocooncrash> Thanks wgrant
[22:37] <wgrant> np
[22:40] <jml> had cocooncrash stuck around, I would have told him that bzr.dev has recently fixed one misreporting of stacking.
[22:43] <tumbleweed> jml: I'll tell him - I came to see the result of his questions
[22:43] <jml> tumbleweed: thanks.
[22:43] <cocooncrash> jml: How exactly does it misreport?
[22:43] <cocooncrash> Does it say that it's stacking but actually doesn't?
[22:43] <jml> cocooncrash: bzr says "using default stacking branch" and then doesn't stack.
[22:43] <cocooncrash> Right
[22:44] <tumbleweed> ok, yes I've seen that
[22:44] <jml> cocooncrash: let me find the bug for you...
[22:44] <tumbleweed> btw, has anyone else been having difficulty pushing to lp from jaunty bzr?
[22:44] <tumbleweed> it just hangs for me unless I use sftp
[22:44] <LarstiQ> tumbleweed: which version is that?
[22:45] <tumbleweed> bug appeared in the last few days
[22:45] <tumbleweed> 1.13~rc1
[22:45] <tumbleweed> hangs during traversing tree
[22:46] <tumbleweed> I can't find any relevent bugs on lp - but it has to have hit other people too
[22:46] <LarstiQ> tumbleweed: lots of small requets in ~/.bzr.log?
[22:46] <tumbleweed> didn't know there was such a long
[22:46] <tumbleweed> log
[22:46]  * tumbleweed looks
[22:46] <jml> bug 345169
[22:46] <jml> that's the one
[22:47] <jml> there was also another bug that occured during 1.13rc1
[22:47] <jml> but that was different.
[22:47] <tumbleweed> jml: ah, I saw that
[22:47] <jml> anyway, take home message: 1.14dev is a lot more reliable.
[22:47] <tumbleweed> jml: that bug was too terse for me to see if it was what I was seeing
[22:48] <jml> tumbleweed: *nod* I reported it on IRC on #bzr and lifeless filed a developer-oriented version of the bug.
[22:48] <jml> which I didn't mind at all, since the bug got fixed very very quickly :)
[22:49] <cocooncrash> jml: Do you know what the actual cause was?
[22:49] <cocooncrash> i.e. will I have to upgrade to actually get it to stack?
[22:49] <jml> cocooncrash: yeah, you'll have to upgrade.
[22:49] <cocooncrash> Bleh
[22:49] <cocooncrash> Any workarounds?
[22:49] <jml> cocooncrash: upgrading is a good idea for a lot of other reasons though.
[22:50] <jml> actually, one reason: speed.
[22:50] <LarstiQ> jml: did it get fixed before or after 1.13 final?
[22:50] <jml> LarstiQ: bug 345169 got discovered after 1.13 final.
[22:50] <jml> LarstiQ: the other stacking bug (number escapes me) got fixed in time
[22:50] <LarstiQ> ok
[22:51] <jml> cocooncrash: I don't know of a workaround. #bzr might.
[22:51] <cocooncrash> jml: Okay, thanks.
[22:51] <jml> cocooncrash: they will, however, strongly recommend you upgrade your formats :)
[22:51] <cocooncrash> jml: But that won't solve it, will it?
[22:51] <andersk> rom1v: Just tried it myself, and compiz segfaulted in the guest session.  This worked a few months ago.
[22:51] <LarstiQ> will we?
[22:51] <jml> cocooncrash: it will, I think.
[22:51] <jml> LarstiQ: many of you will :)
[22:51] <cocooncrash> Oh, that's fine then
[22:54] <tumbleweed> jml: ah, upgraded my branch format to 1.6 and I don't hit that bug
[22:54] <tumbleweed> s/branch/repo/
[22:54] <jml> cool.
[22:54] <jml> may I recommend 1.9
[22:54] <jml> it comes with a complimentary side order of love.
[22:54] <tumbleweed> hah
[22:54] <cocooncrash> jml: Do repo formats matter when pushing/pulling to other branches?
[22:54] <tumbleweed> done
[22:55] <jml> cocooncrash: yes.
[22:55] <cocooncrash> I've noticed that they both have to have the same rich-root support or not
[22:55] <jml> right. rich-root has to be the same.
[22:55]  * LarstiQ wonders how long between dput and showing up in ppa build records is usual
[22:55] <cocooncrash> jml: But otherwise?
[22:55] <jml> apart from that, AIUI, any two formats will interoperate.
[22:55] <cocooncrash> Awesome
[22:55] <jml> but they'll probably perform badly.
[22:56] <LarstiQ> but, they might need to convert on the fly, depending on how different they are.
[22:56] <jml> exactly.
[22:57] <LarstiQ> ah, there we go, packging went from not listed to building.


[22:21] <Saviq> RAOF, hey, since you'll be the first to work among, can I abuse you to please click ♻ near the Regression on https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html? much obliged :)
[22:22] <RAOF> Saviq: Sure.
[22:22] <Saviq> that worked fast :)
[22:22] <Saviq> thanks a bunch!
[22:22] <RAOF> You're reasonably sure that retrying will actually result in success? :)
[22:23] <Saviq> RAOF, yeah, bug #1532358
[22:23] <ubot5`> bug 1532358 in unity-scopes-shell (Ubuntu) "flaky autopkgtests cause migration issues" [High,Triaged] https://launchpad.net/bugs/1532358
[22:24] <RAOF> Maybe you should run them three times and pass if any of them pass :P
[22:24] <RAOF> Retry requested.
[22:24] <RAOF> Have a nice Sunday!
[22:24] <Saviq> not much of it left, was nice, thanks :)
[23:54] <Saviq> RAOF, gah, it's more persistent than I had hoped, can we have another try, please https://requests.ci-train.ubuntu.com/static/britney/xenial/landing-051/excuses.html - last time, I promise ;)
[23:54] <RAOF> Ok.
[23:54] <RAOF> Now go to sleep!
[23:55] <Saviq> yes mom
[23:55] <RAOF> :P


[12:36] <cmaloney> Good morning
[12:40] <rick_h> morning
[12:59] <shakes808> happy friday all
[13:02] <brousch> rick_h: Are you staying at the Blackwell?
[13:02] <rick_h> brousch: yep
[13:03] <brousch> Me too
[13:03] <rick_h> awesome, bar meetup!
[13:14] <cmaloney> Nice!
[13:14] <cmaloney> We're staying there as well
[13:15] <cmaloney> \m/
[13:57] <jrwren> lol... for my second PR at new job, a whopping     +2959, -27    size patch. lol
[14:00] <rick_h> "Rewrite all the bad stuff I've seen so far"
[14:00] <rick_h> "So far only looked at the Makefile"
[14:02] <jrwren> nope.
[14:02] <jrwren> no bad stuff at all.
[14:03] <jrwren> no makefiles either.
[14:03] <jrwren> no javascript.
[14:03] <jrwren> this job is like a dream come true.
[14:03] <jrwren> i'm waiting for other shoe to drop
[14:06] <rick_h> lol
[14:07] <jrwren> i haven't seen any of the ios or android. Maybe that is where the bodies are burried.
[14:11] <cmaloney> heh
[15:01] <brousch> Look for the legacy programs
[15:25] <jrwren> I'm looking at cloud DB technologies and when it comes to cloud managed DB, does it really matter that postgresql > mysql. AFAICT, all the things I prefer about postgresql have to do with management and underlying tech, but if it is just a service, do I really care?
[15:29] <jrwren> my thought is... why use RDS when Aurora exists?
[15:47] <cmaloney> Things I've noticed between PostgreSQL and MySQL tend to be more about transactions and performance
[15:47] <cmaloney> MySQL InnoDB is not terribly performant and transactions are naiive
[15:48] <cmaloney> Also, MySQL stored procedures are pretty limited compared with PostgreSQL
[15:48] <cmaloney> So if you're looking for a dumb datastore and don't care about other PGSQL features then MySQL is fine
[15:49] <cmaloney> addendum: Wordpress and some other PHP apps are exclusively MySQL so that also is a factor.
[15:49] <jrwren> right. none of which matter on Aurora
[15:49] <jrwren> cool.
[15:49] <cmaloney> In what sense?
[15:49] <jrwren> aurora is its own thing that happens to use mysql protocol.
[15:49] <cmaloney> ah
[15:49] <jrwren> so the perf and transactions aren't mysql
[15:50] <cmaloney> So it's likely MySQL with an Amazon-derived engine
[15:50] <jrwren> right
[15:50] <cmaloney> Ah, then I have NFC how that stacks up
[15:50] <cmaloney> Would be interested to see perf benchmarks / reliability benchmarks
[15:51] <cmaloney> But yeah, the engines of MySQL have been a huge sticking point
[15:51] <cmaloney> MyISAM vs InnoDB specifically
[15:52] <cmaloney> Want speed? MyISAM. Want anything else that makes a relational database nice? InnoDB
[15:54] <jrwren> right
[15:57] <greg-g> jrwren: what is the main language you're writing in there?
[16:04] <jrwren> Go
[16:05] <jrwren> greg-g: and so far... I love it... jump to your own conclusions :)
[16:06] <greg-g> heh, we're starting to use some Go for our docker/k8s stuff
[16:06] <jrwren> oh, that is interesting. as api clients to docker/k8s servers?
[16:07] <greg-g> jrwren: (in a meeting but) this is the tool my team is writing in Go: https://phabricator.wikimedia.org/source/blubber/
[16:08] <greg-g> ftr: it's everyone on my team's first Go project, so, take it with a grain of salt code idiom/etc wise :)
[16:20] <jrwren> seems weird to use go for shell scripting like that :p


[13:54] <mhall119|work> cjohnston: ping
[14:03] <nigelb> mhall119|work: hey
[14:03] <nigelb> mhall119|work: when you get the time can you leave a testimonial at https://wiki.ubuntu.com/NigelBabu ? I'm planning to go for membership next month.
[14:13] <cjohnston> mhall119|work: pong
[14:15] <nigelb> cjohnston: hey.. can you give me a testimonial?
[14:16] <cjohnston> no
[14:16] <cjohnston> :-P
[14:18]  * nigelb plans to book tickets to florida
[14:19] <cjohnston> come on over
[14:20] <nigelb> (to kick cjohnston ;) )
[14:20] <cjohnston> cool
[14:20] <mhall119|work> cjohnston: I'm still on for 12pm our time, correct?
[14:21] <cjohnston> yessir
[14:21] <cjohnston> for 2 hours
[14:22] <mhall119|work> cool
[14:22] <Pendulum> mhall119|work, cjohnston if you need any help, I'm snowed in at home so am around :)
[14:22] <mhall119|work> awesome
[14:22] <mhall119|work> well, not awesome that you're stuck
[14:22] <mhall119|work> maybe a little awesome that your stuck... ;)
[14:22] <Pendulum> well my entire office is stuck
[14:22] <Pendulum> so it's a guilt-free "work from home" snowday
[14:23] <nigelb> you gotta work?
[14:23] <nigelb> that spoils the fun
[14:23] <cjohnston> Pendulum: i need lots of help
[14:23] <cjohnston> i dont know that you can provide it tho
[14:25] <cjohnston> nigelb: can you remind me later today about the testimonial?
[14:25] <nigelb> cjohnston: I can remind you tomorrow
[14:25] <cjohnston> that works
[14:25] <cjohnston> ty
[14:25]  * nigelb is going to be very busy at work today
[14:26] <Pendulum> nigelb: well I'm checking e-mail
[14:26] <nigelb> hehe
[14:26] <Pendulum> I have work, but I'll probably do it over the weekend instead as it's not "get done today" sort of work
[14:27] <nigelb> ah lucky
[14:27] <Pendulum> and the things that I needed to get done that were at all time-sensitive require approval from other people who I don't think are in their offices
[14:27] <nigelb> good good :)
[14:33] <Pendulum> so far I have done 2 bits of minor work and had /win 22
[14:33] <Pendulum> argh
[14:33] <Pendulum> fail
[14:35] <nigelb> win 22?
[14:36] <Pendulum> went to switch windows
[14:37] <Pendulum> forgot I had a partially typed sentence
[14:37] <Pendulum> that should have ended "and had several conversations by e-mail about the fact that no one is in their offices due to the weather"
[14:38] <nigelb> you switch to windows just like that?
[14:39] <Pendulum> :P
[14:39] <Pendulum> irssi
[14:39] <Pendulum> switching windows
[14:40] <nigelb> ah
[15:13] <nigelb> doctormo: hey!
[15:13] <doctormo> Hello nigelb
[15:13] <nigelb> doctormo: I need your help
[15:13] <doctormo> ok
[15:13] <nigelb> doctormo: when you get the time, could you leave a testimonial on https://wiki.ubuntu.com/NigelBabu ?
[15:13] <nigelb> I'm planning to go for membership next month
[15:14] <doctormo> nigelb: Sure thing
[15:14] <nigelb> thanks doctormo :)
[15:14] <doctormo> nigelb: How are you getting along with the bzr class?
[15:14] <nigelb> doctormo: I need you for a day to integrate GC into it
[15:14] <doctormo> You've used GC?
[15:14] <doctormo> You've wanted the video?
[15:14] <nigelb> not yet
[15:14] <nigelb> yep
[15:15] <doctormo> watched*
[15:15] <doctormo> That's basically all there is to it
[15:15] <nigelb> okay, I'll write and let you know some time next week
[15:16] <doctormo> nigelb: Are you sure you have the time for this course? I could get soemone else in to help you if you're finding it hard to complete.
[15:16] <nigelb> doctormo: I do
[15:16] <nigelb> I am *not* going to back out ;)
[15:17] <doctormo> OK, then I'll be in touch next Friday?
[15:17] <nigelb> yes
[15:19] <doctormo> nigelb: I've added a testimonial
[15:20] <nigelb> doctormo: thank you :)
[15:28] <dinda> hola learning peoples!
[15:28] <dinda> cprofitt pleia2:  any moodle sys admins around?
[15:30] <nigelb> hola dinda
[15:30] <dinda> nigelb: howdy
[15:30] <dinda> nigelb: are a sys admin on the learning team moodle site?
[15:31] <nigelb> dinda: nope
[15:31] <nigelb> doctormo: are you ^ ?
[15:31] <doctormo> nigelb: nope
[15:31] <dinda> actually I am but i need someone with root access to the webserver
[15:31] <nigelb> dinda: you need bodhi
[15:31] <dinda> yea, figured bodhi was the one
[15:32] <nigelb> I think its his servers
[15:32] <dinda> but thought maybe cprofit might have root access too
[15:32] <nigelb> maybe, I don't really know
[15:33]  * dinda is experimenting with Moodle themes today :)
[15:34] <nigelb> ah
[15:34] <nigelb> my office has a moodle site that was redesigned
[15:35] <nigelb> it came out well ;)
[15:39] <cprofitt> bodhi is the sole sys admin on the server
[15:45] <cprofitt> exit
[17:17] <pleia2> dinda: you can get ahold of bodhi at<EMAIL_ADDRESS>[17:17] <pleia2> I thought vantrax might have had access too, but he's not around a ton either
[17:20] <dinda> pleia2: thanks!
[17:20] <pleia2> sure thing :)


  TYPE /JOIN ## TO SEE THE ACTION...AGAIN TYPE /JOIN ## TO SEE THE ACTION!!
[05:54] <S3XKDLmDfRg> wook YoJimmy ubot9 trebmuh DalekSec Hobbyboy udoprog OvenWerks Peppernrino kspencer ubottu Unit193 categore ren0v0 georgeowell sakrecoer Metacity kbn ubuntulog el bengan


[09:11] <Sling> I'm trying to create a pretty simple upstart script to handle a process starting in screen, but for some reason it just hangs whenever I want to start/stop it, the script is here: http://paste2.org/jnG5kZaZ
[09:12] <Sling> when I run the command after 'exec', it does exactly what I want
[09:12] <Sling> but upstart somehow is in a weird state it seems
[09:13] <Sling> this is what strace shows when it for example hangs on a start: http://paste2.org/ZaA7LECc
[09:16] <Sling> hmm renaming the config allows me to start the job fine, but then it hangs on stopping