[06:05] <rog> davecheney: mornin' boss
[06:07] <davecheney> rog: ahoy!
[06:08] <rog> davecheney: it's funny, i saw gustavo's response to 6304104 but not the original proposal email
[06:08] <rog> davecheney: am looking at it now
[06:12] <davecheney> rog: ta
[06:18] <rog> davecheney: hmm
[06:19] <rog> davecheney: i'm wondering if the interface shenanigans are worth it
[06:19] <rog> davecheney: how about just using a different type for each operation, e.g. http://paste.ubuntu.com/1052155/
[06:20] <davecheney> rog: what is the type returned on the channel ?
[06:20] <davecheney> interface{} ?
[06:20] <rog> davecheney: we could put a private method on it
[06:20] <rog> davecheney: then it could still be Operation
[06:21] <davecheney> switch o := o.(type) { case ... } ?
[06:21] <rog> davecheney: yeah, except we never need to do that AFAICS. i've only done a cursory look mind
[06:21] <rog> davecheney: i think we always know what operation we're expecting
[06:22] <rog> c.Assert(op, Equals, dummy.OpBootstrap{env, inst})
[06:22] <rog> davecheney: s/OpBootstrap/OpStartInstance/
[06:22] <davecheney> rog: sure
[06:23] <rog> and that wouldn't work of course because equality isn't defined on Instances
[06:23] <rog> and but you get the idea.
[06:23] <rog> it means we can lost all the OperationKind stuff and the table. so we probably save lines overall.
[06:23] <rog> s/lost/lose/
[06:27] <davecheney> rog: nice, I always wanted to switch on the type, rather than a synthetic kind field
[06:28] <rog> davecheney: something like this perhaps, if we want an Operation type. http://paste.ubuntu.com/1052161/
[06:29] <rog> davecheney: cool
[06:29] <rog> davecheney: oops, isOperation should be defined on OpEnv
[06:30] <rog> davecheney: although... that won't print so nicely
[06:30] <rog> davecheney: scratch that last suggestion
[06:33] <rog> davecheney: could go with something like this: http://paste.ubuntu.com/1052167/; or just use interface{}.
[06:34] <davecheney> rog: feels a bit forced
[06:34] <rog> davecheney: the Operation type?
[06:34] <davecheney> all those empty methods to satisfy the interface
[06:35] <rog> davecheney: yeah. there is precedent (go/ast) but i think it's probably best to use interface{}
[06:35] <rog> davecheney: it's not a public-facing API after all
[06:55] <Aram> moin.
[06:56] <TheMue> Moin
[06:57]  * TheMue wanted to start later after doing some sports but the club is closed this morning. It seems the morning shift has overslept.
[07:22] <rog> Aram: hiya
[07:23] <rog> TheMue: hiya
[07:26] <TheMue> rog: Hi, just had to restart after firmware update.
[08:36] <rog> I like it when I'm reading an IRC conversation from some hours ago and thinking "I'd want to say *this*", then the conversation ends up at exactly that conclusion.
[10:34] <rog> i'm off into town to fetch my bike and buy a replacement jacket for the one i left behind in Oakland (:-[). back in a couple of hours.
[10:42] <Aram> bokes are great
[10:42] <Aram> bikes
[11:56] <hazmat> Aram, any thoughts on the loss of atomicity and ordering with mongodb (my reply on your thread on list)?
[11:57] <hazmat> ie. given multiple collections to insert for observation/notification
[11:58] <Aram> there's no loss of ordering.
[11:58] <Aram> atomicity may be a problem.
[11:58] <Aram> but ordering should not be.
[11:58] <hazmat> Aram, lacking atomicity, with concurrent ops, how can retain ordering
[11:59] <hazmat> ie. given logical ops A and B and their respective inserts, they could go A1, B1, B2, A2
[12:00] <Aram> there's an atomic sequencing mechanism that generates incrementing integers, and these integers can be used to query for data in a particular order.
[12:02] <Aram> hazmat: basically the sequencing mechanism is atomic because we make it so, it's a single document.
[12:06] <hazmat> Aram, combined with locking? what's a sequence flow look like..
[12:06] <hazmat> of a logical op
[12:08] <hazmat> get sequence value, lock observation collection, atomic update doc using sequence value as condition, insert into observation collection, unlock?
[12:39] <Aram> n reset by peer)
 howdy, anyone seen mark
[12:39] <Aram> meh
[12:40] <Aram> dumb paste
[12:40] <Aram>
[12:40] <Aram> hazmat: there's no locking in mongodb.
[12:40] <Aram> hazmat: I can't answer your question because we haven't decided yet :-).
[12:40] <Aram> hazmat: I only made sure we can implement a mechanism if/when we need it, whatever that mechanism might be.
[12:40] <Aram> hazmat: for example we can implement full transactions using multi-phase commits, if we consider it necessary, but we hope we would not need such a heavy weight mechanism.
[12:40] <Aram> hazmat: I can tell you the technical details of various mechanisms we might use, but I can't tell you which one will use at this early stage. probably gustavo has some better insight.
[12:41] <hazmat> Aram, right re locking i meant app locking not native primitives, and thanks for clarifying the current state
[13:11] <marrusl> hey juju folks...  for Juju on openstack, is swift required?
[13:12] <marrusl> hrm... maybe wrong channel ;-)
[13:14] <marrusl> i'll check in #juju
[13:36] <Aram> hi niemeyer
[13:39] <niemeyer> Yo!
[13:47] <rog> niemeyer: hiya
[13:49]  * Aram is amused by people who censor profanity words on the internet.
[13:52] <niemeyer> Aram: Yeah, seriously
[13:56]  * TheMue moved on the veranda to continue work there.
[13:56] <TheMue> niemeyer: Hi.
[13:58] <TheMue> niemeyer: After a talk yesterday I started to read the mail thread and CL regarding format: 2.
[13:59] <TheMue> niemeyer: A talk to fwereade
[14:00] <TheMue> niemeyer: Shall I continue with that topic or with non-relation topics in state? Like e.g. hooks.
[14:00] <niemeyer> TheMue: Hmm
[14:01] <niemeyer> TheMue: Hooks are not really in state, and fwereade has already been moving towards having them working
[14:01] <niemeyer> TheMue: What else is missing from state?
[14:02] <TheMue> niemeyer: Maybe I said it wrong. In Py in state there are hook, firewall, auth and security.
[14:03] <TheMue> niemeyer: Those are still open.
[14:04] <TheMue> niemeyer: I wanted to continue with relation but fwereade is doing there a lot and asked me to take another topic.
[14:04] <TheMue> niemeyer: That's why he passed me infos about format 2.
[14:05] <niemeyer> TheMue: Yeah, handling the change to format 2 sounds like a good  idea
[14:05] <niemeyer> TheMue: It's just out of state, AIUI
[14:05] <niemeyer> TheMue: Which is why I asked if you're leaving something else behind
[14:09] <TheMue> niemeyer: Those four files above and relations, then state should have been done.
[14:10] <TheMue> niemeyer: So far I compared it file by file and type by type.
[14:10] <niemeyer> TheMue: That's fantastic
[14:10] <TheMue> niemeyer: But I could do a usage scan (Where is state used today?) and see what functionality is missing in the Go port.
[14:11] <niemeyer> TheMue: So it sounds like it's pretty much done indeed
[14:11] <niemeyer> TheMue: The last two are not going to be ported as we'll want to do something else
[14:11] <niemeyer> TheMue: Hooks, as I mentioned, is very close to the implementation of the unit agent, and shouldn't be done in isolation
[14:11] <TheMue> niemeyer: Yes, you once said it when I started with auth.
[14:11] <niemeyer> TheMue: Firewall may be the more interesting bit
[14:12] <Aram> my T410 is overheating sometimes, had the same problem with my T400.
[14:12] <TheMue> niemeyer: So I could do firewall first.
[14:13] <niemeyer> TheMue: I'm having a look at it
[14:13] <TheMue> niemeyer: Just to get the state done.
[14:13] <niemeyer> Aram: I haven't been having it with T410, but I had it all the time on the T60
[14:14] <niemeyer> TheMue: Hmmm
[14:15] <niemeyer> TheMue: We have to do firewall, but it shouldn't look like what is there right now
[14:15] <niemeyer> TheMue: It has a *provider* in the constructor, which makes no sense for a state package
[14:17] <TheMue> niemeyer: Yes, just scanned the code quickly. It's using the state, but it is no state.
[14:17] <TheMue> niemeyer: Interesting.
[14:17] <niemeyer> TheMue: It is state to some degree
[14:18] <niemeyer> TheMue: It's just mixed up
[14:18] <niemeyer> TheMue: Most of that file is really preparing for this:
[14:18] <niemeyer>             for port, proto in to_open:
[14:18] <niemeyer>                 yield self.provider.open_port(machine, machine_id, port, proto)
[14:18] <niemeyer>             for port, proto in to_close:
[14:18] <niemeyer>                 yield self.provider.close_port(machine, machine_id, port, proto)
[14:19] <niemeyer> TheMue: We have to invert the relationship as usual for watchers
[14:20] <niemeyer> TheMue: This is a type along the lines of PortChanges { Opened Closed }
[14:20] <niemeyer> TheMue: and Machine.WatchOpenPorts
[14:20] <TheMue> niemeyer: IC
[14:21] <niemeyer> TheMue: Or really, Machine.WatchPorts
[14:24] <TheMue> niemeyer: As today in Unit.WatchPorts
[14:25] <niemeyer> Hmm
[14:26] <niemeyer> Why do we watch ports for both units and machines
[14:26]  * niemeyer reads
[14:27] <TheMue> niemeyer: Today it's only in Unit.
[14:27] <niemeyer> TheMue: I mean why the original code does that
[14:28] <TheMue> niemeyer: Oh
[14:28] <niemeyer> TheMue: Ah, of course
[14:28] <niemeyer> TheMue: One is based on the other
[14:32] <rog> niemeyer: do we want the machine agent to do the port opening and closing? it seems that it's currently the provisioning agent's job
[14:32] <rog> niemeyer: hmm, i can see why we might not want that, as it currently requires ec2 creds
[14:33] <niemeyer> rog: We do want that, but this is a refactoring step we should do when we're done with the port
[14:33] <rog> niemeyer: ok, so PA to start with
[14:33] <niemeyer> Yeah
[14:40]  * TheMue looks how firewall is used today.
[14:50] <hazmat> TheMue, only in the provisioning agent
[14:50] <hazmat> TheMue, it doesn't really belong in the state package
[14:50] <TheMue> hazmat: Yes, seen it.
[14:57] <TheMue> Fresh cherry cake by my wife, bad for my diet. *sigh*
[15:12] <rog> niemeyer: ping
[15:12] <rog> TheMue: i want some, please
[15:12] <niemeyer> rog: Heya
[15:12]  * TheMue dcc's rog some cake.
[15:13] <rog> niemeyer: just looking at starting the PA
[15:13] <niemeyer> rog: Ok
[15:13] <rog> niemeyer: there's a little awkwardness that i thought it might be worth discussing
[15:13] <niemeyer> rog: Cool. Can we cover this after lunch?
[15:13] <rog> niemeyer: ok
[15:13] <niemeyer> It's food-o-time here
[15:14] <rog> niemeyer: enjoy! ping me after lunch...
[15:14] <niemeyer> rog: Thanks, will do
[16:18] <niemeyer> rog: Yo, so what's up?
[16:18] <rog> niemeyer: so...
[16:18] <rog> niemeyer: we want the provisioning agent to know the machine address to give when starting new machines
[16:19] <rog> niemeyer: so i thought we can easily use the metadata service to pass the address into the provisioning agent
[16:19] <rog> niemeyer: same kind of thing we do with the machine agent
[16:19] <rog> niemeyer: or initzk anyway
[16:19] <rog> niemeyer: with instanceIdAccessor
[16:20] <rog> niemeyer: i added hostNameAccessor
[16:21] <niemeyer> rog: How is it done today?
[16:22] <niemeyer> Aram: Just reviewed https://codereview.appspot.com/6304099
[16:22] <Aram> thanks
[16:22] <rog> niemeyer: good question. i should have looked. one mo
[16:23] <niemeyer> rog: We should look how it is currently done, because this problem has been solved in a way that works for several providers
[16:23] <niemeyer> rog: Maybe it's not optimal, but we should be sure we're improving on it if that are any changes to it
[16:24] <niemeyer> s/that/there
[16:24] <Aram> niemeyer: I did the change, can I just submit now?
[16:24] <niemeyer> Aram: Yeah
[16:24] <Aram> good
[16:25] <niemeyer> Thanks! Woohay first mstate branch going in!
[16:26]  * TheMue cheers
[16:27] <Aram> TheMue: I think we'll share a flight  returning from the sprint.
[16:29] <TheMue> Aram: Oh, good you mentioned it, I've got to change the wiki. BTS found a cheaper flight with KLM. So sorry, we do not share it. *sigh*
[16:29] <hazmat> mramm, do you a percentage on travel arrangements ? ;-)
[16:29] <Aram> hmm, maybe I should ask for different flights, I know there are more flights than BTS told me.
[16:30] <mramm> hazmat: so far it's just pro-bono work
[16:32] <TheMue> hazmat: Hehe, that question shocked him. ;)
[16:32] <rog> niemeyer: ah! ok, problem solved. and dave's problem too.
[16:33] <rog> niemeyer: i should've thought of it anyway
[16:34] <niemeyer> rog: So what's the deal?
[16:35] <rog> niemeyer: the PA calls StateInfo
[16:35] <rog> niemeyer: easy peasy
[16:36] <niemeyer> rog: Aha, ok
[16:43] <niemeyer> rog, Aram, TheMue: Folks, I think now is a good moment to do the move lp.net/juju-core/juju => lp.net/juju-core
[16:43] <niemeyer> Do you have any pending work that is about to be merged?
[16:43] <TheMue> niemeyer: From my side +1.
[16:43]  * rog looks
[16:43] <Aram> +1.
[16:44] <rog> niemeyer: no, that's fine
[16:44] <niemeyer> I'll give Dave a hand and see if any of his branches are mergeable and submit them myself now
[16:44] <niemeyer> fwereade will have to update, unfortunately
[16:45] <niemeyer> But it's almost as low a hit as we can manage I think
[16:53] <niemeyer> Running tests even for the dummy package is taking an awful lot of time.
[16:54] <niemeyer> s/package/provider/
[16:56] <rog> niemeyer: i have an idea about how we might be able to speed up the tests. the slowness is almost all caused by the zookeeper startup time
[16:57] <niemeyer> There seems to be something wrong..
[16:57] <rog> niemeyer: we could start one zk server on demand and use the zk chroot functionality so that it could be used across all tests in all packages.
[16:57] <niemeyer> START: /home/niemeyer/src/launchpad.net/juju-core/juju/environs/jujutest/test.go:96: LiveTests.SetUpTest
[16:57] <niemeyer> This is blocking
[16:57] <niemeyer> Sorry, no, it's not
[16:59]  * rog realises he's broken the build
[17:01] <niemeyer> rog: ?
[17:01] <rog> niemeyer: my recent container "fix"
[17:01] <rog> niemeyer: i could've sworn i ran the test, but evidently i didn't
[17:04] <niemeyer> rog: Hmm.. we'll probably need some kind of submission mechanism soon, hooked with lbox
[17:04] <niemeyer> rog: Btw, this line:
[17:04] <rog> niemeyer: i think lbox should probably run all the test on the merged branch before actually submitting it
[17:04] <niemeyer>         err := t.Env.Bootstrap(true)
[17:04] <niemeyer> rog: Is taking 36 seconds to execute
[17:04] <niemeyer> rog: With the *dummy* env
[17:05] <rog> niemeyer: i suspect zookeeper, but i may be wrong.
[17:06] <niemeyer> rog: It may be zk.. we call state.Initialize there
[17:06]  * niemeyer checks
[17:07] <niemeyer> rog: PutTools
[17:08] <rog> niemeyer: ah, it's taking ages to build the tools, i suppose
[17:08] <rog> niemeyer: because nothing is installed
[17:08] <rog> niemeyer: because you've just changed everything perhaps?
[17:08] <niemeyer> Could be
[17:08]  * niemeyer verifies
[17:12] <niemeyer> % time go install launchpad.net/juju-core/juju/cmd/...
[17:12] <niemeyer> go install launchpad.net/juju-core/juju/cmd/...  24.71s user 7.27s system 99% cpu 32.157 total
[17:12] <niemeyer> rog: ^
[17:12] <niemeyer> rog: Now, the question is why is it taking such a long time *every time*
[17:13] <niemeyer> Clearly something is not ok
[17:14] <rog> niemeyer: just using vanilla "go install" it always takes that long for you?
[17:14] <niemeyer> rog: What's vanilla go install?
[17:14] <rog> niemeyer: just go install on the command line, no other stuff going on like GOBIN etc
[17:15] <rog> niemeyer: for me it takes 1.12s the second time i run it
[17:15] <niemeyer> rog: Sorry, I still don't get it. The command above is go install on the command line.
[17:15] <rog> niemeyer: right. and you ran it twice and got the same time each time.
[17:15] <rog> niemeyer: i've no idea what's taking it so long there then
[17:16] <niemeyer> go install -x isn't even printing results
[17:16] <niemeyer> I'll rebuild my go tree
[17:16] <niemeyer> % time go install -x launchpad.net/juju-core/juju/cmd/...
[17:16] <niemeyer> WORK=/tmp/go-build238159301
[17:16] <niemeyer> go install -x launchpad.net/juju-core/juju/cmd/...  24.93s user 7.07s system 99% cpu 32.182 total
[17:16] <niemeyer> WTF.. it's taking 32 seconds before it even does anything
[17:17] <rog> niemeyer: if go install -x isn't printing results, it means it's doing nothing, yeah.
[17:17] <rog> system 99%
[17:17] <rog> try a syscall trace perhaps
[17:18] <niemeyer> I'll try rebuilding Go first, just to make sure I don't have something funky there
[17:18] <rog> niemeyer: you get 32s before it even prints the WORK line?
[17:18] <niemeyer> rog: Yeah
[17:18] <niemeyer> rog: If I can reproduce with a rebuild I'll see where more exactly
[17:19] <rog> niemeyer: at least this time, i think we can say the blame doesn't fall on the juju testing :-)
[17:19] <niemeyer> rog: Yeah! :)
[17:20] <rog> niemeyer: can i propose/submit a quick fix for the container brokenness before you proceed?
[17:20] <niemeyer> rog: Hmm.. we could add a flag to lbox submit such as "--test-command"
[17:21] <niemeyer> rog: Yeah, definitely
[17:21] <rog> niemeyer: that sounds like a good plan
[17:21] <niemeyer> rog: We can then have it in .lbox so we don't have to enter it every time
[17:22] <rog> niemeyer: yeah. but it's important that the tests run on the merged version
[17:22] <niemeyer> rog: Of course
[17:22] <niemeyer> Still broken
[17:23] <niemeyer> Let's see where this time is being spent
[17:23] <niemeyer> Holy crap.. it's doing an awful lot of things
[17:24] <niemeyer> I suspect someone added some logic without much consideration for what else is under $GOPATH/src/, as it's walking the whole tree :-(
[17:25] <rog> niemeyer: maybe it's not so clever about prefixes of ... patterns
[17:26] <rog> niemeyer: but walking the tree doesn't take long, surely?
[17:26] <niemeyer> rog: Surely does
[17:26] <niemeyer> rog: If the tree is large
[17:26] <rog> % time find $GOPATH/src > /dev/null
[17:26] <rog> 0.01user 0.04system 0:00.05elapsed 98PU (0avgtext+0avgdata 4880maxresident)k
[17:26] <rog> not for me :-)
[17:27] <rog> niemeyer: presumably it's not reading all the files in the tree?
[17:27] <niemeyer> rog: Presumably it's spending 32 seconds doing that
[17:27] <rog> niemeyer: how long does it take you to run that command?
[17:28] <niemeyer> [niemeyer@gopher ~/src]% time find > /dev/null
[17:28] <niemeyer> find > /dev/null  1.86s user 5.89s system 25% cpu 30.253 total
[17:30] <rog> niemeyer: gosh. that is really really big. or you've got a slow disk/network drive.
[17:30] <niemeyer> rog: I have a lot of stuff in my src/
[17:30] <niemeyer> rog: and an SSD
[17:30] <rog> niemeyer: ah! you have GOPATH=$HOME ?
[17:31] <niemeyer> rog: Yep
[17:31]  * rog is glad he didn't do that
[17:31] <niemeyer> rog: Heh
[17:31] <rog> niemeyer: the go tool should be more intelligent
[17:31] <niemeyer> rog: It should be less stupid, rather
[17:32] <niemeyer> Why on earth is it walking everything like that
[17:32] <rog> niemeyer: because it's walking the directories then matching against the pattern
[17:32] <rog> niemeyer: rather than walking the constant prefix of the pattern
[17:33] <rog> niemeyer: at least that's my assumption
[17:33] <niemeyer> rog: OMG, I hope you're wrong
[17:34] <rog> niemeyer: yeah, that's exactly what it's doing
[17:34] <niemeyer> It's like, "Oh you want everything under /home/joe? Okay! Let's start over in /var!"
[17:34] <rog> 		filepath.Walk(src, func(path string, fi os.FileInfo, err error) error {
[17:35] <rog> and src is everything
[17:35] <rog> niemeyer: to be fair it was done quickly, and correctness is more important than quickness.
[17:35] <rog> niemeyer: but it will be easy to fix.
[17:35] <niemeyer> rog: Yeah, I'll fix that now
[17:36] <rog> niemeyer: i'd make matchPattern return the longest path prefix as well as the match function
[17:36] <niemeyer> rog: Doing this right is a no-brainer, to be honest.. it was just a brain fart from someone
[17:38] <niemeyer> rog: Actually, they've done in right elsewhere there
[17:38] <rog> niemeyer: really?
[17:38] <niemeyer> rog: Yep.. see matchPackagesInFS
[17:39] <rog> niemeyer: so it does.
[18:01] <rog> niemeyer: i'm off for the evening. hope the switchover goes ok...
[18:01] <rog> 'night al
[18:01] <rog> l
[18:01] <niemeyer> rog: Thanks, have you seen the LGTM?
[18:03] <rog> niemeyer: just making sure with a final test, then i'll submit
[18:04] <niemeyer> rog: Cheers
[18:04] <rog> niemeyer: re: https://codereview.appspot.com/6304104/ i think we might have decided to go with a different, slightly simpler approach.
[18:04] <rog> i get this sporadic failure:
[18:04] <rog> FAIL: presence_test.go:328: PresenceSuite.TestWaitAlive
[18:04] <rog> presence_test.go:348:
[18:04] <rog>     c.Assert(err, IsNil)
[18:04] <rog> ... value *errors.errorString = &errors.errorString{s:"presence: still not alive after timeout"} ("presence: still not alive after timeout")
[18:04] <niemeyer> rog: The approach there looks pretty straightforward and clean to me
[18:05] <rog> niemeyer: this was my suggestion to dave this morning: http://paste.ubuntu.com/1052155/
[18:06] <niemeyer> rog: I mentioned it could stay simpler, but I also don't see an issue with doing it now, given Dave actually wrote it
[18:06] <rog> niemeyer: which he seemed to quite like
[18:06] <rog> niemeyer: in some similar form anyway
[18:07] <niemeyer> rog: That sounds fine too
[18:07] <rog> niemeyer: it means we can get rid of operationKinds, the string table etc
[18:09] <rog> niemeyer: https://codereview.appspot.com/6332044 submitted. build fixed.
[18:10] <niemeyer> rog: Thanks!
[18:11] <niemeyer> rog: Can you please add a comment to the review then?
[18:11]  * rog really is off now. see you tomorrow (my last day before i'm away for two weeks BTW)
[18:14] <niemeyer> Nevermind.. copied the IRC conversation on the proposal
[18:20] <rog> niemeyer: i added a comment
[18:21] <rog> niemeyer: ah, but replied to the wrong email!
[18:21] <rog> darn
[18:23] <niemeyer> rog: np
[20:23] <niemeyer> So, fixed go problem.. can actually test code in a non-ridiculous timeframe now
[20:47] <niemeyer> juju-core/juju => juju-core move is complete!
[20:47] <niemeyer> Please see juju-dev@ list for details.
[20:48]  * niemeyer steps out
[21:46] <andrewsmedina> niemeyer: :)


[05:08] <JoseeAntonioR> hey guys, is adam conrad the release manager now?
[05:09]  * smartboyhw points JoseeAntonioR to #ubuntu-release to ask
[05:50] <bkerensa> \o/ the call for doc contributors seems to have worked
[05:50] <bkerensa> people coming out of the wood works to help!
[05:50] <bkerensa> czajkowski: \o/
[05:51] <smartboyhw> bkerensa: Calls always work:P
[05:52] <JoseeAntonioR> mostly, not always
[05:52] <bkerensa> yeah but the two people who have already got involved today know what they are doing out of the box which is great
[05:52] <bkerensa> one of the big things with doc has been our instructions for getting involved need simplification
[05:52] <smartboyhw> bkerensa: Whoa that's awesome!
[05:52] <bkerensa> but this guy who just decided to submit a MP knew who to contribute and needed no help which is cool too
[05:53] <bkerensa> I'm confident this next cycle Docs can turn around
[05:53]  * smartboyhw can't work out-of-the-box on his first day of contributing to Ubuntu…
[05:53] <JoseeAntonioR> I started with LP answers, don't know how I ended up here
[05:54] <bkerensa> also the Ubuntu booth at Linux Fest Northwest gave away all its DVD's in a hour flat
[05:54] <bkerensa> ;d
[05:54] <bkerensa> amazing amount of Ubuntu users up here in Washington :D
[05:57] <smartboyhw> JoseeAntonioR: I started with QA and still am:P (more into packaging and dev these days)
[05:57] <smartboyhw> bkerensa: \o/
[06:03] <popey> moo
[06:03]  * popey waves good morning from oakland
[06:04]  * JoseeAntonioR waves to popey
[06:05] <philipballew> popey, Jet Lag?
[06:05]  * smartboyhw waves to popey
[06:05] <popey> no jetlag yet
[06:05] <popey> but only arrived 6 hours ago
[06:06] <smartboyhw> popey: :)
[06:08] <JoseeAntonioR> popey: greetings to all canonipeople over there
[06:08] <philipballew> popey, Dont die, being in Oakland and all...
[06:08] <smartboyhw> philipballew: LOL
[06:12] <smartboyhw> JoseeAntonioR: How many sessions are booked in Open Week?
[06:21] <philipballew> smartboyhw, did you ever decide to send a post card?
[06:22] <JoseeAntonioR> smartboyhw: I think 2
[06:33] <smartboyhw> philipballew: I will go to buy one and send one if I am free
[06:34]  * smartboyhw reminds self to beat his classmates when back to school in Monday


[01:52] <qengho> Good morning!
[04:55] <hikiko> hi
[05:06] <qengho> Hi hi
[07:04] <Laney> morning!
[07:05] <seb128> Laney!
[07:05] <pitti> hey!
[07:07] <Sweet5hark> moin
[07:30] <pitti> tedg, Laney: https://blueprints.launchpad.net/ubuntu/+spec/convergence-y-replace-upstart
[08:00] <willcooke> morning sprinters
[08:00] <hikiko> andyrock, Trevinho https://code.launchpad.net/~hikiko/nux/nux.fixed-smart-ptr/+merge/300293 could you review this branch? (it fixes nux compile errors)
[08:01] <willcooke> xnox, morning.  Is this (potentially) a quick fix do you know?  https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1603223
[08:01] <hikiko> morning willcooke, Laney seb128 pitti Sweet5hark qengho :p
[08:02] <willcooke> hi hikiko!
[08:02] <qengho> Howdy!
[08:02] <hikiko> :)
[08:07] <seb128> hey hikiko willcooke
[08:08] <willcooke> hey seb128, how goes the sprint so far?  Need anything arranging?
[08:08] <seb128> it's going well
[08:08] <seb128> no, everything is fine
[08:08] <seb128> thanks for asking!
[08:11] <Laney> err
[08:12] <Laney> we're missing caviar
[08:12] <willcooke> Laney, I can ship some fish paste over night.  Best I can do
[08:13] <davmor2> willcooke: oh come on you can do better than that, nip round you local chippy can grab a bundle of roe and ship that, at least that way it is fish eggs
[08:13] <willcooke> :)
[08:19] <Laney> \o/
[08:19] <Laney> we coincided with the heatwave
[08:20] <willcooke> It's pretty good here so far, up to ~ 25 in the sun already
[08:28] <willcooke> hikiko, Trevinho - anything pending re: lowgfx for .1?  If we hurry we might still get it in the image
[08:29] <davmor2> willcooke: pfff
[08:30] <davmor2> willcooke: no it won't I start testing in anger today
[08:31] <willcooke> Are you open to bribes?
[08:33] <hikiko> willcooke, we reverted the multimonitor change and I think Trevinho does the sru again :/
[08:35] <robert_ancell> willcooke, seb128 - hi from a similar timezone!
[08:35] <seb128> hey robert_ancell!
[08:35] <willcooke> hey robert_ancell!  "Good" flight?
[08:36] <willcooke> blimey:  http://www.bbc.co.uk/news/business-36822272
[08:36] <robert_ancell> willcooke, I didn't realise I was meant to pick up my luggage in Vancouver but it got here today :)
[08:36] <willcooke> robert_ancell, erk!  I hate having to do that.
[08:36] <robert_ancell> willcooke, yeah, I was suprised
[08:36] <willcooke> glad it found you
[08:36] <willcooke> I think this ARM sale is pretty bad news for the UK
[08:37] <robert_ancell> willcooke, do you know who owned it before?
[08:37] <robert_ancell> Is it the founders selling out?
[08:38] <robert_ancell> willcooke, seb128, do you know what the state of the gsettings/snap work is? Is it tracked anywhere?
[08:39] <willcooke> I think it was Apple, ex-Acorn bods, VLSI and a few others.  I imagine they still all hold shares.
[08:40] <robert_ancell> Guess they all wanted their own private islands
[08:40] <seb128> robert_ancell, I think it's "on desr_t's backlog, not started, and she's on holidays for the next weeks"
[08:40] <willcooke> robert_ancell, desrt and I still need to kick it off properly and break down the tasks.  So it's not re-started yet.  There are some app armor patches which the security team need to review from attente first
[08:41] <robert_ancell> seb128, that's what I assumed, but I haven't been able to get in touch with desrt.
[08:41] <seb128> robert_ancell, but gsettings is working today if you use the gsettings and home interfaces
[08:41] <willcooke> If j_dstrand is around at the sprint he might be able to advise re: the patches
[08:41] <robert_ancell> ok, cool
[08:41] <robert_ancell> thanks
[08:41] <seb128> robert_ancell, you need some hack in the wrapper, I think didrocks put those in the common desktop one
[08:42] <robert_ancell> yeah, was talking to him about that
[08:42] <seb128> to symlink $snap_user/.config/dconf to the normal userdir one
[08:43] <seb128> robert_ancell, is gsettings blocking anything or are you just being curious?
[08:44] <robert_ancell> seb128, not blocking, just don't know the state if anyone asks
[08:44] <robert_ancell> I'll just say TBD
[08:45] <willcooke> robert_ancell, if poss. would be nice to get an agreeement from #security to review and accept a_ttente's patches
[08:45] <robert_ancell> willcooke, link?
[08:45] <robert_ancell> I will chase that up
[08:45] <willcooke> robert_ancell, sorry, will need to defer to attente ^
[08:46] <Trevinho> Morning
[08:46] <robert_ancell> oh yes, he'll be online too soon.
[08:46]  * robert_ancell feels spoily having so many people online at the same time
[08:46] <robert_ancell> spoilt
[08:46] <willcooke> :))
[08:46] <willcooke> We all usually go out for ice-cream around 12
[08:47] <Trevinho> willcooke: hey
[08:48] <Trevinho> willcooke: so lowgfx stuff is all verified and in prepared. It only needs to be promoted to updates in order to get it in the image.
[08:49] <willcooke> Trevinho, cool.  And all the regressions are reverted (at least those we know of) right?
[08:49] <Trevinho> willcooke: Yes
[08:49] <desrt> robert_ancell: hey.. sorry.  on vacation.
[08:49] <willcooke> Trevinho, can you poke people to get the promotion done please?   It's normal here (i'm in my hometown). Anyone had to cook the bread daily in the past...
[09:07] <robert_ancell> seb128, have you noticed any login delays since the hipdpi change wen't through? I've occasionally had ~20s delays while the u-g waits for the xsettings plugin
[09:07] <seb128> robert_ancell, no, but I'm on xenial and you didn't SRU the u-g change?
[09:07] <robert_ancell> seb128, it hasn't gone though, but I'm not pushing it atm
[09:07] <seb128> robert_ancell, also the yakkety update is blocked in proposed
[09:08] <seb128> so I guess nobody but you got it
[09:08] <Trevinho> seb128: this weekend it was mostly about supporting two my friends in a rally... And the Ubuntu Rally car it was... http://farm8.staticflickr.com/7489/28366881705_71fd9bf2a6_k.jpg :-)
[09:08] <robert_ancell> oh, is it?
[09:08] <seb128> Trevinho, nice!
[09:08] <seb128> unity-greeter/s390x unsatisfiable Depends: upstart
[09:09] <seb128> robert_ancell, let me try to fix that by deleting the binary, you might need to add a build-depends on upstart as a workaorund
[09:09] <seb128> upstart is missing on s390x
[09:09] <robert_ancell> ah
[09:09] <seb128> which is creating issues
[09:09] <robert_ancell> seb128, https://launchpad.net/ubuntu/+source/unity-greeter/16.10.1-0ubuntu2 is showing everything built...
[09:10] <seb128> robert_ancell, right, the issue is that it depends on upstart and the upstart binary got deleted on s390x
[09:10] <robert_ancell> oh
[09:10] <seb128> so it makes the greeter not installable on that arch
[09:11] <seb128> I deleted the binary from yakkety the other day
[09:11] <seb128> but I think we need to delete the new one as well
[09:11] <seb128> just did that
[09:11] <robert_ancell> so, what are you supposed to do on s390x if you depend on upstart?
[09:11] <seb128> let's see what it does on the next publisher run
[09:11] <seb128> build-depends on it
[09:11] <seb128> so you depwait
[09:11] <seb128> and you just go missing on s390x
[09:11] <seb128> but it's fine
[09:41] <xnox> willcooke, potentially a quick one, yes. Let me see if I can fix that up.
[09:41] <willcooke> thanks xnox
[09:42] <willcooke> also yay - 50Mbit wifi connection from the shady end of the garden
[09:42] <seb128> trying to make us believe there is sun over the u.k?
[09:44] <Odd_Bloke> Nah, there are drug-dealing squirrels down there.
[09:57] <xnox> willcooke, so https://translations.launchpad.net/ubuntu/xenial/+source/ubiquity/+pots/ubiquity-debconf/de/+translate?batch=10&show=all&search=Download+updates+while
[09:57] <xnox> is the one that is broken.
[09:57] <xnox> i can fix it in the source, and upload. But the translation on launchpad needs to be fixed as well.
[09:57] <xnox> i'll try to contact Ubuntu german translators about it.
[09:58] <willcooke> xnox, awesome, thanks.
[10:01] <seb128> xnox, pitti can probably help you
[10:02] <xnox> oooh, pitti are you "official" german translator? Ich bin nicht....
[10:02] <xnox> https://bugs.launchpad.net/ubuntu/+source/ubiquity/+bug/1603926
[10:03] <xnox> actually there are a bunch of bugs like that.
[10:07] <pitti> seb128: pkg-config --variable=systemduserunitdir systemd
[10:08] <xnox> oh i am not logged in
[10:08] <xnox> i see suggestions now.
[10:09] <qengho> xnox: is it just the curly brace to paren problem
[10:09] <qengho> ?
[10:09] <xnox> qengho, yes.
[10:09] <xnox> curly is the correct form.
[10:10] <xnox> I have these to fix as well https://translations.launchpad.net/ubuntu/xenial/+source/ubiquity/+pots/ubiquity-debconf/af/+translate?batch=10&show=all&search=%24%28
[10:10] <pitti> xnox: updated in LP
[10:11] <xnox> yeah \o/
[10:12] <xnox> qengho, can you approve afrikaanas as well? https://translations.launchpad.net/ubuntu/xenial/+source/ubiquity/+pots/ubiquity-debconf/af/+translate?batch=10&show=all&search=%24%28
[10:24] <hikiko> hi
[10:24] <hikiko> question: can lightdm accept parameters for Xorg?
[10:25] <hikiko> I'd like to do this thing:
[10:28] <hikiko> I have 2 GPUs and 4 monitors, I'd like to create 2 configurations files for xserver: one for GPU1 and one for GPU2, then start xserver1 with gpu1 configuration and xfce and configure lightdm to start xserver2 with the gpu2 configuration file
[10:28] <seb128> hikiko, that's a question for robert_ancell, you can probably try to catch him after lunch
[10:28] <hikiko> so that I have an xfce4 instance running with startx on gpu1 (intel) and start unity using lightdm on gpu2 (nvidia)
[10:28] <hikiko> thanks seb128 :) I will ask him!
[10:28] <seb128> yw!
[10:36] <davmor2> willcooke: do you happen to know if the new amdgpu-pro stuff landed for 16.04.1 if so I'd like to run some upgrades and installs around that
[10:37] <willcooke> davmor2, I dont know, sorry.  Maybe tjaalton does?
[10:38] <tjaalton> davmor2: I'm not sure, tseliot?
[10:38] <tjaalton> I think the pro-pkg is still brewing
[10:38] <tseliot> davmor2: no, amdgpu pro is not in the archive
[10:39] <davmor2> tseliot: do you know if it is being targeted for .1?
[10:39] <tseliot> davmor2: no, not for .1
[10:40] <davmor2> tseliot: awesome thanks for the update
[10:40] <tseliot> np
[12:17] <attente> robert_ancell: hey, those patches are on the ML here: https://lists.ubuntu.com/archives/apparmor/2016-January/009171.html, but they've been sitting around since January
[12:28] <Sweet5hark> hmmm, you have been watching: a hard system freeze out of nowhere.
[12:28]  * Sweet5hark gets slightly nervous about that.
[12:42] <tedg> pitti: The indicators: https://code.launchpad.net/~ted/+git/systemd-graphical-session
[12:55] <Sweet5hark> willcooke: around?
[13:31] <Sweet5hark> oh, wow. ARM is not a UK company anymore.
[13:32] <Sweet5hark> apparently it is japanese now.
[13:34] <davmor2> Sweet5hark: no not yet it's only just going to the dear shareholders I recommend that we ...... bit, but eventually it will be
[13:35] <davmor2> Sweet5hark: unless the Americans don't want it to be Japanese in which case one of the big tech giant might put in a bigger counter offer and so on
[13:36] <Sweet5hark> davmor2: lol, May is like: "Move along, nothing to see here" as someone is using the cheap GBP to extract massive IP out of the UK: http://www.reuters.com/article/us-arm-holdings-m-a-may-idUSKCN0ZY16R
[13:42] <Laney> pitti: http://paste.debian.net/782711/ ~/.config/systemd/user/session-migration.service
[13:55] <seb128> Laney, pitti, I think it's https://bugs.freedesktop.org/show_bug.cgi?id=78905
[13:56] <seb128> https://cgit.freedesktop.org/polkit/commit/?id=a68f5dfd7662767b7b9822090b70bc5bd145c50c
[14:04] <Laney> seb128: maybe fix that in src/polkit/polkitunixsession-systemd.c too
[14:04] <Laney> that is where the warning comes from
[14:05] <seb128> Laney, looking, thanks for the pointer
[14:06] <Laney> -> pointer for you
[14:06] <seb128> :-)
[14:08] <pitti> tedg: pkg-config --variable=systemduserunitdir systemd
[14:13] <pitti> tedg: /run/systemd/users/$(uid)
[14:15] <pitti> tedg: /run/user/$(uid)/systemd/
[14:17] <Sweet5hark> seb128: careful, Laney might trick you into derefing a NULL
[14:17] <seb128> Sweet5hark, trying to hack my laptop!
[14:28] <Laney> ex falso quodlibet
[14:34] <pitti> Laney: http://people.canonical.com/~pitti/tmp/session.sh
[14:53] <Trevinho> Laney: I've found the issue with the black desktop eh... It's in gtk. If you'd run that with stock gtk it would be always black. If you use the version patched with unity support, it works in some cases, but not always because of another issue... So I've a patch for natuilus for now, then i'll fix gtk too.
[14:53] <Trevinho> Laney: how do you want me to provide the patches? branch, debdiff or what?
[14:54] <Laney> Trevinho: are the patches upstreamable?
[14:55] <Trevinho> Laney: nautilus one... not sure since upstream nautilus has no desktop, isn't it?
[14:55] <Trevinho> Laney: as for gtk, there's something that can be upstreamed too... Althogh our implementation might differ
[14:55] <Laney> it does the icons, but the gnomebg stuff is patched
[14:55] <Trevinho> so... I could work in both solutions
[14:55] <Trevinho> Laney: I mean, I don't thin it has nautilus-desktop-window.c file at all, has it?
[14:56] <Laney> umm
[14:56] <Trevinho> think*
[14:56] <Laney> i don't remember the exact files
[14:56] <Laney> look in debian/patches
[15:13] <Trevinho> Laney: there's indeed an error in ubuntu-revert-no-desktop patch
[15:40] <Laney> :-o!
[15:45] <Trevinho> Laney: I've like the impression that the root problem with nautilus is that it's not really using the desktoip-background either, but just uses the root window to paint it... And only paints the icons on top.. as g-s does
[15:50] <Trevinho> Ah, no... it works
[16:12] <Trevinho> Laney: apply this for the black bg fix
[16:12] <Trevinho> http://paste.ubuntu.com/19914256/
[16:12] <Trevinho> only for nautilus, gtk one is something I check better
[16:36] <seb128> https://bugs.freedesktop.org/show_bug.cgi?id=67728
[16:39] <seb128> Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Passed session and the session the caller is in differs. They must be equal for now.
[16:39] <pitti> polkit_subject_equal()
[16:53] <seb128> Cannot register authentication agent: GDBus.Error:org.freedesktop.PolicyKit1.Error.Failed: Error getting subject: Error parsing unix-session subject: Didn't find value for key `session-id' of type s
[17:11] <seb128> calling it a day!
[17:11] <seb128> have a good evening desktoper
[17:11] <seb128> see you tomorrow
[17:45] <willcooke_> gnight all
[17:55] <Trevinho> Laney: it seems the gtk one is way more annoying... Since it seems that gtk doesn't listen properly _NET_SUPPORTED changes, then when unity loads it doesn't get informed about handling transparency properly.... Thus black corners on windows _-
[21:25] <ochosi> Laney: hey, just so you know I've ported Greybird to Gtk3.20 and SASS in some evening hours, wasn't all-too-hard in the end, just very boring ;) so anyway, xubuntu will be fine in 16.10 if you go all 3.20 on everyone
[23:03] <qengho> Good morning. SYN