[08:42] <jamespag`> gnuoy`, https://review.openstack.org/#/c/323264/ if you please :-)
[08:43] <gnuoy`> jamespag`, good morning to you too :)
[08:43] <jamespag`> morning
[08:43] <jamespage> that's better
[08:46] <jamespage> ta
[12:13] <autonomouse> Hi, I wonder if anyone can help me out a bit here please: I'm trying to use juju with LXD seeing as though juju 2.0 no longer has a local provider. However, I've cleary done something wrong as I keep hitting ERROR invalid config: can't connect to the local LXD server: Response was missing `api_compat` - if anyone has any ideas whyt this is happening, could you let me know? thx
[12:34] <tasdomas> lazyPower, ping?
[12:54] <tasdomas> anyone have experience with the relation side of charms.reactive ?
[13:24] <tasdomas> lazyPower, ping?
[14:14] <tinwood> beisner, I've got the tempest charm working with charms.openstack now: https://github.com/openstack-charmers/charm-tempest/pull/8
[14:15] <beisner> tinwood, excellent!  (however, we need that dev to occur @ https://github.com/openstack/charm-tempest)
[14:15] <tinwood> hmm, beisner, when did it move?
[14:16] <tinwood> beisner, and more to the point, why is the old one still there?  Very confusing.
[14:16] <beisner> tinwood, Thu.  that was sort of my main topic of convo last wk ;-)    and yep, we need to retire the old repo.
[14:17] <tinwood> beisner, I didn't realise they had shifted over yet.  Okay, I'll drop the PR there, and retry it on the other one (plus try to sync it, if needed).
[14:17] <beisner> tinwood, much appreciated
[14:20] <beisner> gnuoy, jamespage - we got the openstack-charmers/hacluster sync'd into the gerrit repo on Fri.    I think we'll have some maint/housekeeping @ LP and openstack-charmers GH, yah?    also as tinwood points out, with tempest also moved into gerrit, we should rm the repo from openstack-charmers.  just lmk if/what you want me to tackle on that.
[14:23] <tinwood> beisner, okay, on the new one: https://github.com/openstack/charm-tempest/pull/1
[14:24] <tinwood> beisner, or should this now be in gerrit?
[14:27] <beisner> tinwood, it's gerrit.
[14:27] <tinwood> beisner, so it's a git review one now?
[14:27] <beisner> tinwood, indeed
[14:27]  * tinwood sigh
[14:30] <gnuoy> beisner, thanks for getting the charm repo populated, how did you manage it?
[14:31] <lazyPower> tasdomas o/ hey sorry i didnt see the pings this morning. What can I help you with?
[14:35] <beisner> gnuoy, yw, happy to do it.   mea culpas and begging in openstack-infra ;-)   only infra-root members can do it.  one dev pushed back telling us to just do 1 big commit.  but persistence...
[14:36] <beisner> and ellipsis
[14:36] <gnuoy> beisner, cool, welll thank you so much for getting it done. It would have been a shame to loose the commit history
[14:36] <beisner> gnuoy, indeed.  welcome so much ;-)
[14:36] <tasdomas> lazyPower - so I'm still working on relation departure handling with charms.reactive
[14:37] <tasdomas> lazyPower - and I think there's a subtle bug in the conversation code
[14:37] <tasdomas> lazyPower - it's impossible to get remote data from a relation that is being departed from
[14:37] <tasdomas> even though the remote information is still available via the command line tools
[14:38] <lazyPower> really? conversation.get_remote() fails when juju relation-get works?
[14:38] <tasdomas> lazyPower, yes
[14:38] <tasdomas> lazyPower I think it's because get_remote relies on the list of units in the relation
[14:39] <lazyPower> oo we def. need to take a look at that. Do you mind filing a bug against charms.reactive? https://github.com/juju-solutions/charms.reactive
[14:40] <tasdomas> lazyPower - will do
[14:41] <tasdomas> lazyPower - another question - what could be the reason for charms.reactive trying to pull in relation information from relations that have already been departed from?
[14:41] <lazyPower> i'm goign to have to tap cory_fu_ to answer that one. I'm not super familiar with that area of the code
[14:43] <cory_fu_> tasdomas, lazyPower: The first thing that jumps to mind is if an interface layer uses the -broken hook, it will often get states set on conversations attached to a remote-unit of None, which will then always act like it's set and can't be removed
[14:44] <tasdomas> cory_fu - so is the proper approach then to ignore -broken hooks in the interface layer?
[14:46] <cory_fu_> Yes.  They don't give you any useful information in reactive anyway.  They fire when all related units are gone, which is easy to detect in reactive by the lack of {relation_name}.joined state
[14:46] <lazyPower> oo cory_fu_ - thats a problematic revelation
[14:46] <lazyPower> https://github.com/juju-solutions/interface-etcd/pull/5/files
[14:47] <lazyPower> i was unable to discern the departing unit without using that
[14:47] <lazyPower> is there an alternative pattern i can use?
[14:47] <cory_fu_> lazyPower: Just change "broken" there to "departed"
[14:47] <lazyPower> ok so departed only runs on the departing unit?
[14:47] <cory_fu_> Correct
[14:48] <lazyPower> i'm pretty sure i had this flipped and it tanked caused every unit the self unregister
[14:48] <lazyPower> so/the self/to self/
[14:48] <cory_fu_> I sent an email about this to the Juju list a while back, but clearly I need to push it more.  Broken is broken in reactive.
[15:04] <tinwood> beisner, for tempest charm: https://review.openstack.org/325966 Move files to new layered location
[15:06] <beisner> tinwood, [testenv:pep8] needs to be the tox enviro name for lint
[15:07] <beisner> if we are to keep this in line with other openstack projects and other os-charms
[15:07] <tinwood> beisner, kk
[15:27] <lazyPower> cory_fu_ - yeah i just flipped it from broken to departed and i get behavior i absolutely dont want
[15:27] <lazyPower> it nukes everything but the leader
[15:32] <beisner> gnuoy, tinwood - fyi transitory os-charmer hacluster and tempest gh repos deleted. ✓
[15:32] <tinwood> beisner, yay!  Thanks, it will help to reduce my confusion!
[15:56] <gQuigs> hi there, I'm trying to get sosreport ready for Juju 2.0 and otherwise improve out automated logging plugin
[15:56] <gQuigs> I want to capture juju debug-log -n 1000, but the syntax appears to be materially different between juju 1 and 2
[15:57] <gQuigs> for juju 2.0 - juju debug-log -T -n 1000
[15:57] <gQuigs> for juju 1.25 - juju debug-log -n 1000
[15:58] <gQuigs> and if you do with -T on 1.25 it fails, if you do without -T on 2.0 it will hang indefinitely
[15:58]  * gQuigs really doesn't want to have to special case versions;
[16:01] <marcoceppi> gQuigs: you're going to pretty much have to, 2.0 is a backwards breaking release
[16:03] <anita_> trying to install JUJU 2.0 as nonroot
[16:03] <gQuigs> marcoceppi: this is the first change I've ran into that actually breaks anything
[16:03] <anita_> but getting error
[16:04] <marcoceppi> gQuigs: wait until you run `juju get` ;)
[16:04] <marcoceppi> err, now juju get-config
[16:05] <gQuigs> marcoceppi: could the tail be only when run in an interactive session?
[16:05] <gQuigs> running commands that just don't work is fine.. it's the hanging indefinitely that really gets us
[16:05] <gQuigs> so we can go both juju get and juju get-config and not care the output failed
[16:06] <marcoceppi> gQuigs: open a bug, not a core developer so i can't say for sure
[16:06] <gQuigs> marcoceppi: will do, thanks
[16:15] <anita_> when installing juju 2.0 getting error as "ERROR unable to contact api server after 1 attempts: cannot load cookies: open /home/charm/.go-cookies: permission denied"
[16:18] <gQuigs> reported - https://bugs.launchpad.net/juju/+bug/1589581
[16:18] <mup> Bug #1589581: Consistant basic use of debug-log between 1.25 and 2.0 <pyjuju:New> <https://launchpad.net/bugs/1589581>
[16:18] <gQuigs> bah humbug
[16:18] <gQuigs> there we go
[16:19] <gQuigs> I think I ask this every time I report a bug.. can we close the old project https://launchpad.net/juju?
[16:22] <lazyPower> anita_ - sounds like you may have run juju with sudo at somepoint and logged in?
[16:23] <lazyPower> interestingly enough my .go-cookies is owned by root with permissions: 0600
[16:24] <anita_> lazyPower_:I followed the document juju2.0
[16:24] <anita_> But I logged in as root and then su - <nonroot user>
[16:25] <lazyPower> anita_ https://jujucharms.com/docs/devel/getting-started
[16:25] <anita_> Hmm for me -rw------- 1 root  root       5 Jun  6 02:49 .go-cookies
[16:26] <anita_> Ok I will follow this
[16:27] <anita_> I did exactly like this
[16:27] <anita_> somewhere i missed something?
[16:27] <lazyPower> my suggestion would be to remove the .go-cookies and re-login
[16:28] <anita_> Ok
[16:28] <anita_> let me try that way
[16:29] <anita_> just to see when i changed the owner of .go-cookies, bootstrap is successful
[16:29] <anita_> any idea how to delete a controller
[16:30] <anita_> juju destroy-controller?
[16:31] <lazyPower> yep
[16:31] <anita_> ok
[16:31] <lazyPower> juju help commands will lend a hand from here
[16:31] <anita_> k
[16:35] <anita_> I delete .go-cookies and re-login as nonroot after i destroy default controller
[16:37] <arosales> is anyone not seeing the navigation toolbar @ https://jujucharms.com/docs/devel/getting-started
[16:38] <anita_> now its successful
[16:38] <lazyPower> arosales confirmed, i am not seeing the nav bar
[16:38] <rick_h_> arosales: yes it's erroring in the JS
[16:38] <lazyPower> anita_ great :)
[16:38] <arosales> lazyPower: rick_h_ thanks for confirming
[16:38] <arosales> rick_h_: need me to file a bug, or are folks already working on it?
[16:38] <anita_> Then the same step i should follow as mentioned in doc
[16:39] <rick_h_> arosales: I'd file a bug and see if either something in docs broke things or the GUI folks did
[16:39] <anita_> before bootstrap, i will delete the .go-cookies and re-login?
[16:39] <anita_> is it a correect method?
[16:39] <arosales> rick_h_: will do, thanks
[16:40] <anita_> also i have done one more extra step comapred to doc, i.e : sudo chgrp lxd /var/lib/lxd/unix.socket
[16:41] <anita_> is this two steps correct?
[16:42] <anita_> lazyPower_: please confirm if the above two steps that followed for nonroot juju2.0 installation is valid? one is sudo chgrp lxd /var/lib/lxd/unix.socket and then deleted .go-cookies and relogin as nonroot
[16:43] <bdx> how's it going everyone? happy monday!
[16:43] <lazyPower> anita_ i'm not sure where that .go-cookies came from. so its hard for me to say. I would say thats a valid working fix for the error you encountered, but i dont think its required every time you setup juju, no.
[16:43] <bdx> does anyone know the status of cross-model-relations?
[16:44] <anita_> ok thanks a lot
[16:44] <bdx> rick_h_: ^
[16:45] <rick_h_> bdx: on this roadmap's cycle of work
[16:45] <bdx> rick_h_: nice! thats exciting!
[16:45] <bdx> thx
[16:46] <arosales> bdx: hello and happy monday indeed. It seems summer is upon us as well
[16:47] <magicaltrout> summer is relative
[16:48] <bdx> magicaltrout: ha, is it raining for you today?
[16:49] <magicaltrout> june gloom
[16:49] <magicaltrout> i left london last week in rain, i arrive in san diego for the week and its grey-ish
[16:49] <bdx> arosales: yea .... Portland winters last a long, dark, rainy 9 months .... so pumped for the sun
[16:50] <bdx> its great for programming though
[16:50] <lazyPower> magicaltrout *hattip* glad you enjoyed
[16:51] <magicaltrout> indeed lazyPower had it on a few times now
[16:52] <beisner> marcoceppi - curious:  i've got a "top" layer which charm-proofs ok -- but what's are the intents and expectations for charm-proof wrt layers/interfaces?
[16:53] <marcoceppi> beisner: proof is really only designed to run against the built layer
[16:53] <marcoceppi> we've not really gotten a layer/interface proof yet
[16:54] <arosales> bdx: I hear you're getting lots of sun as of late
[16:54]  * marcoceppi opens a feature for it on charm-tools
[16:55] <beisner> marcoceppi, ack thx.  well fwiw, proof passes on an unbuilt layer currently, which may actually be a bad thing?
[16:56] <marcoceppi> beisner: not really
[16:56] <marcoceppi> but not all layers are expected to pass proof, though I  suppose top layers are
[16:56] <marcoceppi> beisner: but intermediate layers may not have a complete metadata.yaml, for example
[16:56] <beisner> marcoceppi, indeed
[17:18] <skay> is there a juju command to generate dot files?
[17:20] <skay> aha, in a side channel I learned of https://code.launchpad.net/juju-viz
[17:21] <lazyPower> That looks neat skay, what does it do?
[17:23] <skay> lazyPower: I think it will generate a dot file with a graph showing a juju deployment, but I haven't tried it out yet, just got the url just now
[17:24] <skay> lazyPower: I am working some changes to a charm and a mojo spec that will remove a website from our environment, and having a diagram to show what the current state is will make it easier for people
[17:24] <skay> lazyPower: I have a doc, but it has lots of words. no pictures. generating a dot file will really help
[17:25] <skay> (I am not great at using drawing programs)
[17:26] <lazyPower> i completely understand skay  :)
[17:26] <lazyPower> they are tedious at best
[17:26] <lazyPower> have you thought about generating a bundle/export and sending it through svg.juju.solutions?
[17:27] <skay> aha, in that repo in bin there is juju-dotty.py for the curious. it takes output from juju status
[17:27] <skay> lazyPower: no. I am not familiar with how to do that
[17:27] <lazyPower> we use the raw bundle files in merges to visualize our prs.  eg https://github.com/juju-solutions/bundle-beats-core/pull/1
[17:28] <lazyPower> pardon the unwiedly url - but the markdown in the pr comment shows the magic:  http://svg.juju.solutions/?bundle-file=https://raw.githubusercontent.com/juju-solutions/bundle-beats-core/cc14520c94ed69b29c667c3d59d189ce3a6166ee/bundle.yaml
[17:29] <cory_fu_> Anyone else seeing the side-bar missing on https://jujucharms.com/docs/devel/getting-started
[17:29] <lazyPower> i suppose this may not be as  useful, i think the api requires a url to curl to fetch the bundle
[17:29] <lazyPower> cory_fu_ - there's an open bug about it
[17:29] <cory_fu_> Ah, ok
[17:29] <lazyPower> cory_fu_ https://github.com/juju/docs/issues/1141
[17:30] <lazyPower> cory_fu_ if you have a sec i'm curious if there's another way i can get the unit thats actually leaving the relationship other than using the -broken hook as its broken.
[17:31] <cory_fu_> -broken will never give you a departing unit because it's only called after every single remote unit is gone
[17:31] <cory_fu_> What you actually want is the -departed hook, which behaves exactly like you're thinking -broken does
[17:31] <lazyPower> i have code that may be side-effecting into working
[17:32] <skay> lazyPower: wow that is pretty
[17:32] <cory_fu_> That is, within the -departed hook, conv.units (or hookenv.remote_unit()) will contain the unit that is leaving
[17:32] <cory_fu_> And if you add a state to the conversation, it will only apply to the unit that is departing
[17:32] <cory_fu_> lazyPower: ^
[17:33] <skay> lazyPower: /me searches. https://github.com/marcoceppi/svg.juju.solutions yes? looks like it
[17:33] <lazyPower> cory_fu_  do you have an example? https://github.com/chuckbutler/interface-etcd/blob/c58568c4ffaa9099deea8f20199d9ec501f5aeff/peers.py  -- this conversation is scope unit
[17:33]  * skay reads readme and churckles. hehe
[17:34] <cory_fu_> kwmonroe: I did see that bdx said "working on a complete fix now" in https://github.com/jamesbeedy/layer-puppet-agent/issues/2 -- I mentioned that during daily and said that the commit he referenced before that looks to me like it should resolve the issue, so I'm not sure what "complete solution" is required
[17:34] <cory_fu_> kwmonroe: I'd say go ahead and test the current fix
[17:35] <kwmonroe> cool
[17:36] <cory_fu_> lazyPower: In your etcd peers.py, the only thing you should need to do is change -relation-broken on line 28 to -relation-departed.  It should function correctly with just that change, though you should also add a "dismiss" method that removes that state once it's been processed.  Let me find you an example where we use the same pattern
[17:38] <cory_fu_> lazyPower: https://github.com/juju-solutions/interface-mapred-slave/blob/9493fab49a447a317b276523595e40df064299d5/requires.py#L31
[17:38] <cory_fu_> lazyPower: And it's used in the charm (now in upstream!) at https://github.com/apache/bigtop/blob/master/bigtop-packages/src/charm/hadoop/layer-hadoop-resourcemanager/reactive/resourcemanager.py#L155
[17:40] <lazyPower> cory_fu_ - this is different behavior in peers i think. Every unit is getting the .departed state set
[17:40] <lazyPower> its not scoped between just the departing unit and the leader. every peer is getting that state and in this case telling itself ot unregister and terminate the application.
[17:41] <lazyPower> when i switch from -broken to  -departed
[17:42] <cory_fu_> lazyPower: You are incorrect
[17:42] <cory_fu_> :)
[17:42] <lazyPower> cory_fu_ - hang on i'll gather logs and make my case
[17:42] <cory_fu_> https://github.com/juju-solutions/layer-etcd/blob/master/reactive/etcd.py#L315
[17:44] <cory_fu_> lazyPower: That handler will match if *any* unit has the departed state.  I think what you actually want there is @when_not('cluster.joined')
[17:44] <icey> charm build seems to not recognize / use the series: key in the metadata.yaml
[17:44] <lazyPower> well for one
[17:44] <lazyPower> i love the .dismiss method on the interface
[17:44] <lazyPower> i'm clearly doing interface state handling wrong
[17:45] <cory_fu_> lazyPower: Ok, I think I see the problem
[17:46] <cory_fu_> You're using the pattern of setting a state on join and then immediately removing it.  You want to do that because you want to track the indvidual unit that is new, which is understandable.  However, because you're not leaving a state set on the unit, you have no way of tracking when there are still units remaining
[17:47] <cory_fu_> So you're trying to use -broken to detect when all units are gone.  Also understandable.  However, that doesn't really play well with reactive because when -broken fires, there's no longer any remote units to be participating in conversations.  You end up setting a state on a None unit conversation, which will cause problems for you later because you can never remove it
[17:48] <lazyPower> also a good point
[17:49] <cory_fu_> lazyPower: What I would recommend is to have a .joined state that you don't remove in provide_cluster_details whose purpose is to keep track of all units that are still joined.  You then remove it in -departed, and you can detect "no remaining peers" by @when_not('cluster.joined')
[17:50] <cory_fu_> You can keep the .joining state to make it easy to tell which unit is new.  But I'm not sure what the .declare_self state is for
[17:50] <cory_fu_> Can you explain that?
[17:52] <lazyPower> cory_fu_ - sure, the leader acts as the single unit we care about during turn up. It performs a single node bootstrap and waits for peers. When a peer knows its about to come online, it has to talk to the leader first. declare_self triggers the peer saying "Hey i'm here with this detail" and the leader responds with the static initial cluster configuration.
[17:52] <cory_fu_> lazyPower: Also, to clarify why I said you were incorrect before.  The state does not get attached to every peer; rather, it gets attached to a single peer and that is sufficient to trigger the @when('cluster.departed') test.  Does that match up with what you were seeing in your logs?
[17:53] <lazyPower> this was the source of a lot of headaches before, so this may need additional love in the layer, but peers were racing, and static configuration requires staggered start.
[17:53] <lazyPower> so you have ot gate based on direct communication with the etcd application running on the leader
[17:54] <cory_fu_> Hrm.  This is all symptomatic of the failure of the conversation model.  It's too divergent from how people are used to thinking about relations and is causing more confusion than clarity.  :(
[17:56] <lazyPower> i'll give it another go based on our findings here. There's a goldmine of feedback here
[17:57] <cory_fu_> In the next pass, I want to make the underlying process more explicit by dropping the idea of "conversations".  A unit joins the relation, so you attach a state to it.  Handlers match states and the relation classes group all units that are in that state and let you operate on them individually or as a group.  (That's basically how it works now, but we tried to abstract some of that out in the Conversation model and ended up making
[17:57] <cory_fu_>  it more opaque)
[17:58] <lazyPower> from what i understood of that, it makes sense :)
[17:58] <lazyPower> or, alternatively, we can do some better docs and maybe some example interface seminars for these use cases
[17:59] <hatch> has anyone ever got the error "ERROR Get https://.... x509: certificate has expired or is not yet valid" when bootstrapping lxd (with master)
[17:59] <lazyPower> our current interface docs were primarily cut/paste and remixed by me, so there's some gaps in there
[17:59] <lazyPower> hatch not with the lxd provider no, i have with juju stable releases and the local provider
[17:59] <hatch> lazyPower: do you recall what you did to fix it?
[18:00] <arosales> devel side bar is back
[18:00] <arosales> thanks matthelmke and evilnickveitch :-)
[18:00] <matthelmke> :)
[18:00] <arosales> https://jujucharms.com/docs/devel/ that is if folks were wondering about the context
[18:01] <lazyPower> hatch https://bugs.launchpad.net/juju-core/+bug/1245550 - ooolllddd bug
[18:01] <mup> Bug #1245550: ERROR TLS handshake failed: EOF waiting for stateserver <bootstrap> <ui> <juju-core:Fix Released> <https://launchpad.net/bugs/1245550>
[18:02] <hatch> oh heh
[18:02] <hatch> hmm
[18:03] <hatch> lazyPower: do you know where this certificate is stored? So that I can check the date?
[18:03] <hatch> or maybe delete it :)
[18:03] <lazyPower> not with juju2, check the $JUJU_DATA Directory
[18:03] <lazyPower> $home/.local/share/juju
[18:03] <hatch> btw $JUJU_DATA isn't defined
[18:03] <hatch> :)
[18:04] <lazyPower> its in the variable reference guide
[18:05] <lazyPower> hatch https://jujucharms.com/docs/devel/reference-environment-variables right thurrrr at the top
[18:05] <hatch> ahh maybe because it's built and not installed
[18:26] <marcoceppi> skay: there's a charm for that too, as well as http://svg.juju.solutions
[18:27] <skay> marcoceppi: I didn't realize that was a real url I could use. I did a search and found your repo and was trying to install it
[18:28] <skay> spiffy
[18:29] <marcoceppi> skay: oh yeah, it's just a web service
[18:29] <skay> marcoceppi: I started down a rabbit hole of finding jujusvg
[18:30] <marcoceppi> skay: you can, with juju 2.0-beta8, just `juju deploy cs:~marcoceppi/xenial/charm-svg` (https://jujucharms.com/u/marcoceppi/charm-svg/3)
[18:30] <marcoceppi> skay: it was such a pain in the ass to setup, I ended up writing a charm for it
[18:36] <skay> should I be able to generate svg based on juju status --format yaml?
[18:37] <marcoceppi> skay: not really, though you should be able to
[18:37] <marcoceppi> skay: it'd be a nice feature
[18:37] <skay> marcoceppi: it complained about icons and didn't generate an svg. I didn't want to go down a rabbithole on that if it wasn't intended that way
[18:37] <skay> marcoceppi: yeah, it would be neat
[18:37] <marcoceppi> skay: it expects a v3 bundle
[18:38] <marcoceppi> skay: are these local charms?
[18:39] <skay> marcoceppi: private ones
[18:39] <skay> marcoceppi: some are private, some publi
[18:42] <marcoceppi> skay: all the private ones won't show up
[18:42]  * skay nods
[18:52] <bdx> cory_fu, kwmonroe: sup
[18:52] <kwmonroe> yo yo bdx
[18:52] <bdx> hey! I've a few things to run by you
[18:52] <bdx> concerning layer-puppet
[18:53] <bdx> specifically puppet-agent
[18:54] <kwmonroe> sure thing bdx
[18:54] <bdx> kwmonroe, cory_fu, firstly -> http://apt.puppetlabs.com/
[18:55] <kwmonroe> fwiw, i think layer-puppet should go away in favor of puppet-agent as the base layer.. and a new layer-puppet be a charm that includes puppet-agent and is like a deployable puppet service.
[18:55] <bdx> what I'm running into is that puppet3 and puppet4 are not both supproted equally on a per-release basis
[18:56] <bdx> kwmonroe: entirely, thats how I've been using it .... I'm running into complications though
[18:56] <bdx> e.g. xenial isn't supported for puppet3, but it is for puppet4
[18:56] <kwmonroe> ugh, lame
[18:57] <bdx> the puppet3 debs are the puppetlabs-release-<ubuntu version>.deb
[18:57] <bdx> found here apt.puppetlabs.com
[18:58] <bdx> it looks puppet4 is packaged for all releases since precise
[18:59] <bdx> kwmonroe, I guess my question is, should I make 'puppet-version' config default to puppet4
[18:59] <bdx> and then throw a conditional for puppet3 that xenial isn't supported?
[19:00] <bdx> or should I throw away everything puppet3
[19:00] <bdx> and make the charm only puppet4
[19:00] <bdx> ?
[19:00] <admcleod> bdx: we need 3 for bigtop
[19:00] <bdx> darn
[19:00] <bdx> admcleod: mind if I enquire as to why?
[19:01] <admcleod> bdx: it doesnt work with 4 :}
[19:01] <kwmonroe> bdx: what's the puppet4 package name?  i don't see stuff like puppet_4.x for trusty: http://apt.puppetlabs.com/pool/trusty/main/p/puppet/
[19:01] <kwmonroe> or am i looking in the wrong place?
[19:01] <bdx> kwmonroe
[19:01] <bdx> kwmonroe: just go to the base url
[19:02] <bdx> anything with 'puppetlabs-release-pc1-<release>.deb' is puppet4
[19:02] <bdx> admcleod: how does bigtop currently use puppet-agent/puppet-master
[19:03] <bdx> puppet3 -> puppetlabs-release-<release>.deb
[19:03] <bdx> puppet4 -> puppetlabs-release-pc1-<release>.deb
[19:04] <admcleod> bdx: its masterless - i cant remember the exact issue, let me test it again now just incase i was wrong
[19:05] <kwmonroe> bdx: i don't see a big deal with defaulting to 4 as long as there's a config opt to specify 3 if we need it.
[19:06] <bdx> admcleod, kwmonroe: I think masterless and masterfull puppet should be separate layers/charms .... the deps are entirely different, so is the implimentation and use case
[19:06] <bdx> kwmonroe, ok, just  add a conditional to check for xenial/vivid/wily for puppet3?
[19:06] <admcleod> bdx: well. we dont need any deps for masterless, we just need to install the package. so ideally 'if puppet master not defined, dont configure it - assume its masterless'
[19:09] <bdx> admcleod, kwmonroe: should I just set status to 'blocked' if ubuntu_release is xenial/vivid/wily and puppet-version => 3?
[19:09] <kwmonroe> bdx: i think you mean == 3 there
[19:10] <bdx> totally my bad
[19:10] <bdx> yea
[19:10] <kwmonroe> bdx: you can either be nice and detect that series won't have the package available, or you can just let apt fail and be like "you should have read the readme where i talked about puppet3 only available < vivid"
[19:10] <bdx> gotcha
[19:11] <kwmonroe> bdx: because who knows -- maybe somebody has a xenail ppa with puppet3 that they have configured as an install_source.. we shouldn't block them just in case puppet3/xenial is available in their configured env.
[19:11] <bdx> totally
[19:13] <cory_fu_> I'd like clarification on why bigtop doesn't work with puppet 4.  Are there significant syntax changes that make the bigtop manifests not work?
[19:13] <cory_fu_> admcleod: ^
[19:14] <admcleod> cory_fu_: testing
[19:14] <bdx> kwmonroe: thats the other thing .... because of the ubuntu release in the deb url, the functionality of layer-apt is limited e.g. install_sources config can't be used :-(
[19:15] <kwmonroe> so bdx, i like the idea of a single puppet layer that can work in master/less mode, but i don't know enough to know how disjoint those 2 modes are.  if it's totally separate code paths depending on the config, that's one thing.. but if it's master = masterless + some, then i think we can still have a single puppet layer.
[19:15] <bdx> kwmonroe: here the interesting part
[19:16] <bdx> kwmonroe: puppet-agent for puppet3 depends on puppet AND puppet-common
[19:16] <bdx> puppet-agent for puppet4 depends on neither
[19:18] <bdx> kwmonroe, the dependency for masterless puppet is included by in the  default archives
[19:18] <beisner> thedac, can you land this?  testing ci/push flow on hacluster post-move.  https://review.openstack.org/#/c/325478/
[19:19] <mattrae> hi, with juju 2.0 is it possible to use a bundle with stages like was supported with juju-deployer. 'juju deploy bundle.yaml stage1' isn't working for me in this example https://pastebin.canonical.com/158108/
[19:21] <beisner> thedac, also this one plz & thx:  https://review.openstack.org/#/c/324795
[19:22] <rick_h_> mattrae: no, the built in bundle support is basic and does not do that.
[19:22] <bdx> kwmonroe: the masterless puppet dep doesn't change between 3 and 4, unless you add the deb sources for puppet3, which just gives you the full set of puppet releases
[19:22] <rick_h_> mattrae: the deployer was updated to work with 2.0 if you need it
[19:23] <mattrae> rick_h_: ahh cool, thanks!
[19:23] <bdx> but adding puppet4 deb has no effect on masterless puppet deps, and as it looks to me masterless puppet3 doesnt need deb sources add either
[19:28] <admcleod> bdx: cory_fu_ hrm looks like it might just be a sys path problem
[19:30] <bdx> admcleod, cory_fu, kwmonroe: cloud-init doesn't have support for puppet4 yet ....
[19:30] <cory_fu_> Why does cloud-init need to support puppet4?
[19:30] <admcleod> bdx: cory_fu_ kwmonroe right, puppet3 installs /usr/bin/puppet, 4 is /opt/puppetlabs/bin/puppet which isnt added to juju sys path so the hook fails
[19:31] <bdx> I was just saying ... a lot of people use cloud-init to automate puppet getting provisioned on their infra
[19:32] <bdx> totally
[19:32] <cory_fu_> Really?  I wasn't aware that cloud-init had any tie-ins with puppet, but then, I don't know that much about cloud-init
[19:32] <bdx> theres a cloud-init puppet module
[19:32] <cory_fu_> I see
[19:33] <bdx> it allows me to spinup instances and have them auto puppet from my puppet master
[19:33] <bdx> very usefull
[19:34] <bdx> it's use should be replaced by layer-puppet
[19:34] <bdx> for my infra at least
[19:35] <bdx> useful*
[19:35] <admcleod> bdx: cory_fu_ kwmonroe /opt/puppetlabs/bin is added to /etc/environment but i guess its not re-sourced after its added. so hooks fail, and juju run fails.
[19:38] <bdx> yeah, I think the cloud-init puppet module needs a similar fix
[19:38] <beisner> a drive-by o/ howdy -> bdx
[19:39] <bdx> beisner! you got me excited last week with all that multi-hypervisor support talk
[19:40] <bdx> beisner: by the way, who is heading that initiative, you?
[19:40] <admcleod> bdx: cory_fu_ kwmonroe created a symlink but it fails because theres no /etc/puppet/hiera.yaml. this will need more testing and i have to EOD, can pick it up again tomorrow morning
[19:40] <beisner> bdx! yo
[19:41] <bdx> admcleod: sweet, I'll have pushed some new up by the am, I'll ping you tomo
[19:43] <admcleod> bdx: AFAIR, there are quite a few breaking changes between 3 and 4 - not just the config but also how relaxed it is about broken syntax and other issues. i seem to recall it not being a simple upgrade
[19:44] <beisner> bdx, the collective 'we' os-charmers really.  we've got test bundles and a readme documenting the process.
[19:45] <bdx> admcleod: yea, its not, we just underwent the upgrade here at dhc .... huge refactoring to get our puppetstack code base to puppet4
[19:46] <bdx> beisner: where is this happening?
[19:46] <admcleod> bdx: yeah ive mostly respressed the experience :}
[19:47] <beisner> bdx, PoC @ http://bazaar.launchpad.net/~ost-maintainers/openstack-charm-testing/trunk/view/head:/README-multihypervisor.md   which exercises nova kvm and nova lxd in a single deploy, firing up both types of instances.
[19:48] <bdx> beisner: has juju the comprehension of multiple image uuid's now, or is that part of the WIP?
[19:48] <beisner> bdx that example is completely independent of juju features (and currently only really validated @ 1.25.x, but i see no reason 2.x would be an issue, known bugs notwithstanding)
[19:49] <beisner> bdx, but:  i believe there are some juju features growing to support the flip side of that.  ie. juju deploying on top of that multi-hv cloud.   right now, i've only validated that the cloud itself listens and responds appropriately to `nova boot` type of operations.
[19:50] <bdx> nice
[19:50] <bdx> awesome
[19:51] <beisner> bdx, so tldr:  glance images are tagged with hypervisor types, then when a user nova boots one of those images, it 'just works'
[19:53] <bdx> beisner: nice, so you are just adding '--property hypervisor_type', or is there other config?
[19:53] <beisner> that's the one bdx
[19:53] <beisner> bdx, worth having a look at the test bundle though too
[19:53] <bdx> yea, I am now
[19:54] <bdx> thats a good repo
[19:54] <bdx> great*
[19:54] <bdx> excellent examples
[19:55] <beisner> bdx, that's where openstack bundles start life.  then we test, generally automate, and selectively publish once everyone's convinced.  ;-)   just bear in mind anything in there is subject to breakage as that's where we iterate and dev things.
[19:56] <bdx> entirely
[20:08] <bdx> beisner: I've been running openstack on lxd all on one node, I have it currently supporting a copy of all of our staging infra .... its f***ing awesome .... check it
[20:09] <bdx> http://imghub.org/image/U3D4
[20:10] <bdx> http://imghub.org/image/UvyQ
[20:11] <bdx> http://imghub.org/image/UD10
[20:12] <bdx> beisner: lxd openstack bundle + dvr + vlan tenant nets .... bet I'm the first :-)
[20:15] <bdx> 10x 128GB Samsung 850 Pros under the raidz :-)
[20:17] <bdx> http://imghub.org/image/UnxF
[20:29] <beisner> bdx, sweet!
[21:24] <beisner> hi marcoceppi, any known issues with md rendering @ charm store?  i've got this [1] which renders a code block all in one line (i believe unexpectedly) [2].
[21:24] <beisner> [1] https://raw.githubusercontent.com/openstack/charm-tempest/master/README.md
[21:24] <beisner> [2] https://jujucharms.com/u/openstack-charmers-next/tempest/xenial/0
[21:25] <beisner> ie. i've used 3 diff md tools and they all render it as two lines in the code block
[21:48] <arosales> beisner: ya it is known issue, let me see if I can find the bug link
[21:50] <beisner> arosales, ack thx for the info.  i'm not too worried about it.  mainly wanted to confirm that it's a known thing vs. adjusting the .md content specifically for the cs:.
[21:53] <arosales> beisner: https://github.com/CanonicalLtd/jujucharms.com/issues/276
[21:53] <arosales> beisner: thanks for confirming it is a known issue or if a bug needed to be filled
[21:53] <jhobbs> https://mail.google.com/mail/u/1/#inbox
[21:53] <jhobbs> oops
[23:22] <mattrae> hi, i'm deploying services to lxc containers using juju 2.0 beta8 and maas 2.0 beta6. i see the containers are getting an interface bridged to physical interfaces that are configured. one issue i'm seeing is even though i have a default gateway configured on one of the networks, its not getting added to the container. https://pastebin.canonical.com/158125/
[23:23] <mattrae> when i add the default gateway manually its working. i'm wondering what i'm missing to have the default gateway added
[23:35] <arosales> mattrae: hmm, interesting not sure what the correct answer here is. Suggest if no one else chimes in to give the juju mail a try and possible get more eyes on it
[23:38] <bdx> mattrae: have you configured the maas space to use the gateway?
[23:44] <bdx> mattrae: I'm sure you've already seen this, but the bottom half of this page might hook you up if not -> https://maas.ubuntu.com/docs2.0/rack-configuration.html
[23:48] <gugpe> I need to debug a service that is stuck in a "pending" state. How do I do that?
[23:48] <gugpe> Specifically I'm trying to deploy a custom (local) charm I wrote.
[23:49] <gugpe> I have all the start-up lifecycle hooks "install config-changed start", but nothing in them.
[23:49] <arosales> gugpe: is the unit or the machine stuck in pending
[23:50] <arosales> gugpe: I am assuming you have a machine but the unit for the given charm[service] is stuck in pending, correct?
[23:50] <arosales> gugpe: also what version of juju 1.x or 2.x?
[23:51] <gugpe> Correct, the lxc machine is pending
[23:51] <gugpe> 2.0-beta8-xenial-amd64
[23:51] <gugpe> Both machine and unit.
[23:53] <gugpe> sudo juju deploy /home/wurde/GitLab/charm-gitlabomnibus
[23:53] <gugpe> that's the command I'm sending.
[23:54] <gugpe> What's the best way to debug this?
[23:55] <bdx> gugpe: don't be executing this as root for a start
[23:55] <bdx> gugpe: there is a debug flag '--debug' I thing
[23:55] <bdx> think
[23:56] <gugpe> Ok. I needed to set ownership of controllers.yaml. I'll look for the --debug flag.
[23:59] <gugpe> The message JUJU-STATUS allocating Waiting for agent initialization to finish
[23:59] <gugpe> I'm running on xenial series


[07:58] <didrocks> good morning
[08:04] <oSoMoN> good morning
[13:07] <andyrock> jcastro, hi jorge
[13:21] <jcastro> hi andyrock!
[13:23] <andyrock> jcastro, welcome back
[13:23] <andyrock> jcastro, can i tag a bug as a bitesize one?
[13:47] <jcastro> andyrock: by all means!
[13:47] <jcastro> andyrock: did you see I made a template?
[13:48] <jcastro> https://wiki.ubuntu.com/Unity/FilingBugs#Canned "Call for Help" Template
[13:48] <jcastro> that way you can add some guiding information to a bug report
[13:50] <andyrock> jcastro, thx
[14:34] <andyrock> DBO, i need mouse position in Launcher.cpp but cannot use GetMouseX and GetMouseY, can i get mouse position using nux?
[14:35] <DBO> andyrock, _mouse_position.x/y
[14:36] <andyrock> DBO, i try to explain
[14:36] <andyrock> DBO, first of all: https://bugs.launchpad.net/unity/+bug/769335
[14:36] <andyrock> DBO, well in my opinion the problem is here:
[14:37] <andyrock> / as the leave event is no more received when the place is opened
[14:37] <andyrock>     self->SetStateMouseOverLauncher (false);
[14:37] <andyrock> in void Launcher::OnPlaceViewHidden (GVariant *data, void *val)
[14:38] <andyrock> if the mouse is over the launcher when the place view is hidden
[14:39] <andyrock> we have to call self->SetStateMouseOverLauncher (true);
[14:40] <andyrock> using GetMouseX/Y we cannot say if the mouse is over the launcher when the place view is hidden
[14:40] <DBO> ah yeah that is a problem
[14:41] <DBO> so to fix this what I think we need to do is not make places grab the mouse internally to nux
[14:41] <DBO> so mouse events still kinda go around normally
[14:42] <andyrock> DBO, ok...
[14:43] <DBO> basically this problem should just magically go away when we change the mouse grab strategy in nux
[14:46] <andyrock> DBO, so I can not help it :)
[14:46] <DBO> more or less :/
[15:11] <Andy80> hi :)
[15:12] <dcordes> Hi
[15:12] <dcordes> can somebody have a look at bug 791852 ?
[15:19] <Andy80> nerochiaro: ping
[15:19] <nerochiaro> Andy80: ciao
[15:20] <Andy80> nerochiaro: ciao :)
[15:20] <Andy80> nerochiaro: I'm trying to work to bug #715611 and I've a couple of question, do you have any spare minutes?
[15:21] <nerochiaro> Andy80: sure, go ahead
[15:22] <Andy80> nerochiaro: first of all, I've an idea of how to implement it... don't know if you have followed my comments on the bug... shortly I think I'm going to use QFileSystemWatcher to see if the trash folder is changed and maybe list files to see if it's empty or not
[15:23] <Andy80> what do you think about it?
[15:24] <nerochiaro> Andy80: it can work, but have you looked at how Unity implements it ? (i have not, but maybe they use some other APIs from gnome that make it simpler)
[15:24] <Andy80> nerochiaro: I've given a look to this http://bazaar.launchpad.net/~unity-2d-team/unity-2d/trunk/view/head:/launcher/UnityApplications/trash.cpp
[15:25] <Andy80> nerochiaro: but I want to be clear... I WON'T use any function starting with g_ ;)
[15:25] <Andy80> it looks like a copy-paste from unity-3d code
[15:25] <Andy80> for many functions we could have coded in pure Qt with lot less code
[15:26] <Andy80> maybe there could be a signal sent to dbus that says something about it....
[15:27] <nerochiaro> Andy80: well, the problem with the trash is that it's not just one folder, if i understand gnome documentation correctly
[15:28] <Andy80> nerochiaro: yep, I've read specs yesterday. It's basically a folder with deleted files and another folder with a list of deleted files information
[15:28] <Andy80> nerochiaro: we just need to know if the trash is empty or not
[15:29] <Andy80> to decide which icon to display
[15:30] <nerochiaro> Andy80: there can be multiple trashes (for example one for each partition), and there's a GIO API to view them as a single unified trash. i understand your desire to avoid mixing QT with C code, but it will acutually save you time to use g_ functions in this case I think
[15:31]  * Andy80 cries :°°°
[15:32] <nerochiaro> Andy80: http://developer.gnome.org/gio/unstable/ch27.html#id494961 and http://www.ramendik.ru/docs/trashspec.html are useful
[15:32] <Andy80> but... using that API I can neither use the QFileSystemWatcher method... it would not work
[15:33] <nerochiaro> Andy80: no, you have to use GIO APIs there, with the trash:// URL. i understand it's not pretty but the fact is that we are a QT application on top of a gnome system, so sometimes you need to call into gnome APIs
[15:35] <Andy80> nerochiaro: ok, I'll use that API then. Another question: the icon is simply set returning the "Icon" method with "return "unity-icon-theme/user-trash";" ? So I would need to change that returning value?
[15:36] <nerochiaro> Andy80: yes, depending if the trash is empty or full. and where in your code you detect when it changes from empty to full you probably want to emit the signal that tell that the icon has changed so that QML can request the new one
[15:37] <Andy80> nerochiaro: what is the other icon name? and... does already exist that signal to emit or do I have to define it?
[15:37] <nerochiaro> Andy80: looking into it
[15:38] <nerochiaro> oSoMoN: please have a look at the discussion with Andy80 so far, in case you have other comments
[15:40] <nerochiaro> Andy80: there's an "iconChanged" signal you can emit when it changes
[15:40] <Andy80> nerochiaro: cool!
[15:40] <oSoMoN> nerochiaro: looks good to me, it looks like Andy80 is on track to fix the bug :)
[15:43] <Andy80> ok, let me manage some basic stuff first (I still have to try recompiling unity-2d without any modify, then I want to try to add the first stub of code ecc.....)
[15:43] <nerochiaro> Andy80: if you just want to change the icon, you can use http://developer.gnome.org/gio/unstable/GFile.html#g-file-query-info to query for the standard::icon attribute of the trash:// "file"
[15:43] <nerochiaro> this will give you the icon that you can return from the icon() method of LauncherItem
[15:45] <nerochiaro> Andy80: and use http://developer.gnome.org/gio/unstable/GFileMonitor.html on trash:// to see check when files are added and removed to it and emit the signal that iconChanged()
[15:45] <Andy80> nerochiaro: I'll give a look at it, just give me some minutes... the 28°C in my room are not helping me to concentrate :D
[15:45] <nerochiaro> Andy80: i think i have given you all the clues I had :) take your time (and some water ;))
[15:45] <Andy80> nerochiaro: isn't better to use directly this to check if something is added/deleted http://developer.gnome.org/gio/unstable/ch27.html#id494961 ?
[15:47] <andyrock> DBO, about the "tooltip bug"...
[15:47] <DBO> yeah?
[15:48] <andyrock> we can use something like this:
[15:48] <andyrock> self->SetStateMouseOverLauncher (pointerX < self->GetAbsoluteGeometry ().x + self->GetGeometry ().width &&
[15:48] <andyrock>                                      pointerY >= self->GetAbsoluteGeometry ().y);
[15:48] <andyrock> and when nux grab pointer startegy change
[15:48] <DBO> yep that should work as a temporary fix
[15:49] <andyrock> we'll remove it
[15:49] <andyrock> i have to add a fixme comment?
[15:50] <DBO> yeah
[15:50] <nerochiaro> Andy80: ah yes, good point
[15:51] <nerochiaro> Andy80: actually, isn't it the same thing i suggested ? ;)
[15:51] <Andy80> nerochiaro: yes it is! for that reason I could not understand why you suggested me two different things :)
[15:54] <Nafai> DBO!  ltns!
[15:54] <nerochiaro> Andy80: that is for monitoring. i also suggested you how to properly get the icon for full/empty trash
[15:55] <Andy80> nerochiaro: yeah, that is the other thing I've to do of course )
[15:55] <Andy80> :)
[16:17] <njpatel> cdbs, what do you want done with https://code.launchpad.net/~bilalakhtar/unity/make-compilation-strict/+merge/62073?
[16:22] <Andy80> nerochiaro: trying some code inside trash.cpp.... the compilation of trash.cpp passes but later some tests in launchermenutest fail. Do I have to add anything in the testsuite for each method/function I add?
[16:23] <nerochiaro> Andy80: not really sure. agateau added them IIRC
[16:23] <Andy80> mmm...
[16:31] <Andy80> I need to understand how these tests work or this will block the compilation of code, damn it -.-
[16:44] <Andy80> ok... found how to avoid compilation error (for the moment)
[17:19] <Omega> Andy80: Pff, it's 32°C here all year round :P
[17:23] <Andy80> Omega: where :) ?
[17:31] <Omega> Andy80: close to the equator, tropics :>
[17:32] <Andy80> wow :)
[17:33] <Omega> I'm not complaining though, it's nice.
[17:33] <Andy80> I hope at least you're close to the sea! so you can swim sometimes
[17:33] <Omega> I do! I was at the beach yesterday!
[17:33] <Omega> Aruba, we have really nice beaches.
[17:34] <Andy80> oh Aruba! like the name of one our national ISP :D
[17:34] <Omega> Hah!
[17:34] <Andy80> not only a tropical paradise if I remember well... also a fiscal paradise :D
[17:34] <Omega> Hah :>
[17:34] <Omega> So, you're in italy I assume
[17:35] <Andy80> ahahaha yes ;)
[17:35]  * Andy80 wonders why when we talk about not paying taxes, people always think to Italy :D
[17:36]  * Omega thought italy because of the ISP called aruba :P
[17:44] <Andy80> a question: I cannot access a Qt/class property from a C function inside a Qt class?
[17:44] <Andy80> (very cryptic question I know... maybe it would be better if I pasted the code somewhere....)
[18:13] <DBO> andyrock, I am reviewing your tooltip work now
[18:13] <DBO> is there anything you want me to look at closer?
[18:14] <DBO> also, I dont really know who you are, so I would love to hear your FOSS history :)
[18:14] <DBO> like to know who I am reviewing and all
[18:14] <andyrock> DBO, i am Andrea Azzarone
[18:15] <DBO> is that italian?
[18:16] <andyrock> yes...
[18:16] <DBO> we have several italians working on Unity, dont know what it is about Italy that generates such fine programmers
[18:17] <andyrock> do you remember the man who stole you the function to change launcher icon size? :)
[18:17] <DBO> oh man, feel like an idiot now
[18:17] <DBO> my brain just placed you
[18:17] <DBO> sorry about that
[18:18] <andyrock> don't worry... you rock :)
[18:18] <DBO> (you should have seen how long it took me to figure out njpatel == AWN guy)
[18:18] <DBO> the tooltip branch works excellently
[18:18] <DBO> 1 second is too long
[18:19] <DBO> I am going to make it 500ms
[18:19] <DBO> merging away :)
[18:19] <andyrock> DBO = The Jason = Docky :)
[18:19] <andyrock> Thanks...
[18:19] <andyrock> in a comment mark said 1 second... i dont'know
[18:20] <DBO> hes silly
[18:20] <DBO> 1 second sounds short
[18:20] <DBO> but its actually a REALLY long time
[18:22] <andyrock> I agree
[18:22] <andyrock> I only run 'orders' :)
[18:23] <DBO> I like to change see stuff and see how hard I get smacked
[18:23] <DBO> its fun
[18:24] <DBO> andyrock, two branches landed in 30 seconds, well played
[18:25] <andyrock> DBO, thx! is a plesure for me
[18:27] <DBO> 3 branches
[18:29] <andyrock> the last merge proposal is a very old one! :)
[18:43] <jcastro> yeah!
[18:43] <jcastro> http://wiki.documentfoundation.org/ReleaseNotes/3.4#GUI
[18:47] <jcastro> man
[18:47] <jcastro> http://www.omgubuntu.co.uk/2011/06/drag-and-drop-google-docs-uploader
[18:47] <jcastro> DBO: check that out
[18:48] <DBO> seen it :)
[18:48] <jcastro> "The big change in this version is that the launcher icon now supports drag n’ drop uploading of documents to Google Docs, and opens newly uploaded file automatically as a ‘web app’."
[18:48] <jcastro> that's just HOT.
[18:48] <jcastro> DBO: hey, if you can explain to trevino better how you want that webapp matching bug fixed I would love you
[18:48] <DBO> will do shortly
[20:07] <Omega> DBO: some people still don't know you're deebeeoh
[20:07] <DBO> i fly under the radar
[20:08] <Omega> Also, that reminds me, jcastro, when's the team AMA coming? :>
[20:08] <jcastro> probably midcycle
[20:08] <jcastro> it would be boring to do it now
[20:11] <Omega> Yeah, that's what I just thought too
[20:11] <Omega> needs more controversy, so it's more fun
[20:40] <Nafai> DBO: perhaps you could help me!
[20:40] <DBO> maybe
[20:40] <DBO> whats up?
[20:41] <Nafai> I'm trying to write a patch to Unity to pop up a launcher's quicklist when you hit Super + Control + Number
[20:42] <Nafai> but I can't get keyboard navigation working
[20:42] <Nafai> https://code.launchpad.net/~nafai/unity/quicklist-shortcut
[20:46] <jcastro> fyi, alt-f1, then arrow key down, and then right  arrow will do a quicklist shortcut
[20:46] <jcastro> though you probably already know that
[20:48] <Nafai> yeah
[20:48] <Nafai> I wanted something more direct :)
[21:51] <_alazar> Hi everybody, does anyone know if the unity launcher will always be panel like? I mean, docky (for example) is toggleable, between panel and dock. Will it be possible with the u' launcher?
[22:13] <Saviq> _alazar: you mean right/left edge vs. bottom edge? I believe I've seen some code (at least in unity-2d) that signalled support for any of the edges
[22:14] <Saviq> but don't hold me on that
[22:17] <Andy80> nerochiaro: it (almost) WORKS!!!! :D
[22:18] <Nafai> I think I scared DBO away
[22:18] <DBO> failure to ping
[22:18] <DBO> uhm
[22:18] <DBO> reading backlog
[22:19] <DBO> hmmm interesting problem there
[22:19] <DBO> let me get back to you on that
[22:20] <_alazar> Saviq: No no, I mean the launcher now goes from edge to edge, just like selecting the panel option in docky. But, I want unity to act more like a dock, not a panel (fixed size that grows when there are more icons inside), like a no-panel docky.
[22:21] <Saviq> ah understood, I don't think that the current design has that in store
[22:22] <Andy80> guys I need your help for a very common task I suppose (at least for you): I've to test some changes to the unity-2d launcher, but if I launch the version I've compiled, the old one is still in memory. If I kill the old one in memory it's launched again.. in this way I've always two launchers running (both the old and the new version) and I cannot test the new one properly. How can I manage this?
[22:23] <Nafai> DBO: np :)
[22:26] <Saviq> Andy80: either disable the launcher autostart in gnome-session-properties
[22:27] <Saviq> or remove "Autorestart" or whatever the key is in /usr/share/app[...]-launcher.desktop
[22:28] <Andy80> Saviq: it's not visible in gnome-session-properties
[22:29] <Saviq> Andy80: ah it might be a requirement in gconf
[22:29] <Saviq> so try in gconf-editor in /desktop/gnome/session or similar
[22:29] <Saviq> can't remember the exact key
[22:31] <Andy80> let me see..
[22:32] <Andy80> uhm...nope can't find it
[22:32] <Saviq> then go to /usr/share/applications/
[22:32] <Saviq> find the launcher .desktop file
[22:32] <Saviq> and comment out / remove the autorestart line
[22:32] <Andy80> but.... maybe I've another idea: since I'm modifying the original source code and debian/ is present... isn't there a way to rebuild the .deb packages and install them?
[22:33] <Saviq> yeah, but that's probably not efficient when testing
[22:33] <Saviq> you can always reinstall the original package to get the file back
[22:34] <Andy80> ok... I try putting the Autorestart to false
[22:34] <Saviq> yup, but you'll have to restart your session
[22:34] <Saviq> it's X-GNOME-AutoRestart
[22:36] <Andy80> Saviq: oh ok! I restart my session.... how do I know that it fill start at least the first time? without it I won't be able to launch anything if it fails to start
[22:36] <Saviq> it will
[22:36] <Saviq> that's X-GNOME-Autostart for you
[22:37] <Andy80> Saviq: ok, now X-GNOME-AutoRestart=false
[22:38] <Andy80> Saviq: I can't see Autostart in the same file, but I assume the default is to true (I hope)
[22:39] <Saviq> no it's not
[22:40] <Saviq> but it should be there
[22:40] <Saviq> ah no, it's started by the session
[22:40] <Andy80> yeeeeeeeeeeeeeeeeeeeeeahhhhhhhhhh
[22:41] <Andy80> it woooooooorks ^___^
[22:41] <Saviq> good
[22:41] <Andy80> bug #715611 almost fixed :P (need to test again!!!)


[16:02]  * slangasek waves
[16:03] <jodh> o/
[16:05] <slangasek> #startmeeting
[16:05] <meetingology> Meeting started Thu Mar  6 16:06:00 2014 UTC.  The chair is slangasek. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:05] <meetingology> Available commands: action commands idea info link nick
[16:06] <slangasek> [TOPIC] Lightning round
[16:06] <slangasek> $ echo $(shuf -e barry doko stgraber jodh bdmurray slangasek cjwatson xnox stokachu)
[16:06] <slangasek> bdmurray slangasek barry doko stokachu cjwatson xnox stgraber jodh
[16:07] <doko> slangasek, should you inject infinity into this shuffle?
[16:08] <slangasek> oh oops
[16:08] <slangasek> $ echo $(shuf -e barry doko stgraber jodh bdmurray slangasek cjwatson xnox stokachu infinity)
[16:08] <slangasek> jodh barry slangasek doko bdmurray infinity stokachu cjwatson xnox stgraber
[16:08] <xnox> oh, meeting
[16:08] <slangasek> and... I still have stokachu in there, so s/stokachu/caribou/, not that he's here :)
[16:08] <slangasek> yes, quickly quickly
[16:08] <jodh> * foundations-1305-upstart-work-items:
[16:08] <jodh>   - async tests have uncovered a race that needs to be resolved by
[16:08] <jodh>     reworking the state machine. Plan is to have a mini-sprint with
[16:08] <jodh>     xnox+cjwatson to work on this next week.
[16:08] <jodh> * upstart:
[16:08] <jodh>   - fixed bug 1288243.
[16:08] <jodh> * other:
[16:08] <jodh>   - Fixed pbuilder+sbuild dep8 tests running in an lxc container (ppc64el+armhf).
[16:08] <jodh>   - Thanks to xnox for the Upstart MP backlog purge!
[16:09] <jodh> J
[16:09] <barry> LP: #1284469 / python issue #19021 - trying to get a python 3.4 rc2 package with the Popen.__del__ fix.  currently have some autopkgtest failures so the cherry pick list is probably not complete.  alternatively: convince 3.4 RM to cherry pick the relevant changes into 3.4rc3.
[16:09] <barry> system-image: long q/a meeting about how to do automated tests.  wiki test plan updated.  s-i 2.2 ready for landing silo (along with a new u-d-m).  fixes: LP: #1277589, LP: #1287287, LP: #1250817, LP: #1286542, LP: #1279532, LP: #1287919.
[16:09] <barry> this week: hopefully returning to autopilot py3 and general py3.4 work.
[16:09] <barry> done
[16:13] <barry> slangasek: you're up
[16:13] <slangasek>  * buried in customer work all week
[16:13] <slangasek>  * resumes coming in for the Java role; going to give some of these to doko for review, could use more volunteers to help pare these down
[16:13] <slangasek> (done)
[16:13] <slangasek> doko:
[16:13] <doko> - Linaro Connect
[16:13] <doko> - fixing ftbfs
[16:13] <doko> - toolchain updates required for AArch64 and powerpc64le
[16:13] <doko> - +1 maintenance work
[16:13] <doko> - will be offline for the next 12 days, so pestering people to keep up with things while I'm away
[16:13] <doko> (done)
[16:14] <bdmurray> bug triage of foundations bugs
[16:14] <bdmurray> uploaded ubuntu-release-upgrader with armhf and ppc64el test failure fix
[16:14] <bdmurray> research into software-properties test failures and gnupg debian bug 737128
[16:14] <bdmurray> reported gnupg bug regarding trustdb (issue 1622)
[16:14] <bdmurray> testing of bug 1280782
[16:14] <bdmurray> uploaded an attempt to fix bug 1280782 regarding tk8.5-lib
[16:14] <bdmurray> tested bug 1280782 some more and uploaded tcltk-defaults to fix that upgrade issue
[16:14] <bdmurray> commited a fix for ubuntu-release-upgrader bug 1160346 based on a patch from a community member
[16:14] <bdmurray> uploaded a fix for ubuntu-release-upgrader bug 1285545 based off jibel's patch
[16:14] <bdmurray> fixed linux package hook bug when creating duplicate signatures
[16:14] <bdmurray> merge of colin king's kernel oops branch fixing some null pointers and memalloc issues
[16:14] <bdmurray> added a fix for kerneloops bug 1026300 with his changes
[16:14] <bdmurray> submitted RT regarding installing trusty gdb on the retracers
[16:14] <bdmurray> backported trusty version of gdb to precise and tested it on the apport-retracers in canonistack (success)
[16:14] <bdmurray> fixed an errors.ubuntu.com OOPS
[16:15] <bdmurray> fixed an errors.ubuntu.com OOPS
[16:15] <bdmurray> modified errors to sort OOPS on user page by date they occurred not alphabetically
[16:15] <bdmurray> submitted RT to have errors updated
[16:15] <bdmurray> fixed errors tool to find a bucket for an instance
[16:15] <bdmurray> worked on modifications to apport to install specific package versions when retracing instead of using the latest
[16:15] <bdmurray> testing / improving whoopsie intergration-tests so we can move to prodstack
[16:15] <bdmurray> reported apport bug 1287460 regarding xdg-open and preferred browsers
[16:15] <bdmurray> SRU team work and mentoring of arges
[16:15] <bdmurray> ⌁done
[16:15] <bdmurray> bluetooth magicpad testing (trying to capture kerneloops)
[16:19] <slangasek> ah, we put infinity in the rotation, but he's probably asleep due to Macao :)
[16:19] <slangasek> cjohnston:
[16:19] <slangasek> er
[16:19] <slangasek> cjwatson:
[16:20] <cjwatson> Cherry-picked several easy fixes (mostly build/packaging, and bug 1285790) from my libclick work and landed them in click 0.4.16, by way of CI Train practice.
[16:20] <cjwatson> Pushed libclick out for review.  Went through my own proofreading pass in parallel; found and fixed several bugs.
[16:20] <cjwatson> Started work on converting some known click clients (upstart-app-launch, unity-scope-click, clickmanager-plugin) to libclick.  Some of this will need library equivalents of "click info" and "click list", so started on those too.
[16:20] <cjwatson> Worked on a branch to expose supported frameworks in libclick.
[16:20] <cjwatson> Landing libclick at the moment.  http://bazaar.launchpad.net/~click-hackers/click/trunk/files/head:/click/tests/ (esp. gimock.py and some test file such as test_hooks.py) if you're interested in the crazy scheme I was talking about last week.
[16:20] <cjwatson> Fixed up python-tblib build problems (planning to use this for click later).
[16:20] <cjwatson> Merged gnutls28 security fixes.
[16:20] <cjwatson> Attempted to get ghc/arm64 building, prompted by a thread on ubuntu-devel-discuss; predictably failed.
[16:21] <cjwatson> Rooted my phone and set it up to dual-boot Ubuntu, so that I have a test system that doesn't make me want to throw things.
[16:21] <cjwatson> ..
[16:22] <xnox> * python3:
[16:22] <xnox>   - unity8, ubuntu-ui-toolkit, ofono, a few more clicks all landed.
[16:22] <xnox>   - next up: land phablet-tools py2&3 support
[16:22] <xnox>   - next up: continue testing/landing remaining clicks
[16:22] <xnox> * touch-x86:
[16:22] <xnox>   - worked on fixing up x86 cross toolchain, it still does not build
[16:22] <xnox>   with ssp.
[16:22] <xnox> * upstart/touch printing:
[16:22] <xnox>   - fixed cups socket activation with upstart, it mostly was s/-F/-f/
[16:22] <xnox>   in the cups upstart job + correct typos. (both -F/-f mean
[16:22] <xnox>   foreground, both change fg variable 0 => 1/-1, most things test for
[16:22] <xnox>   !fg, apart from one small portion which closes all passed FDs when
[16:22] <xnox>   running with -F instead of -f)
[16:22] <xnox>   - reviewed a few upstart merge proposals. We should be good for a
[16:22] <xnox>   bugfix heavy upstart release.
[16:22] <xnox> * aa/+1:
[16:22] <xnox>   - disentangled libav8 NBS by fixing a few packages and uploading
[16:22] <xnox>   patches to port mplayer to libav9 from gentoo, thus there is little
[16:22] <xnox>   removal damage - two small leave packages. (mplayer on the other
[16:22] <xnox>   hand has a lot of reverse dependencies).
[16:22] <xnox> ..
[16:23] <doko> x86 cross toolchain?
[16:23] <cjwatson> x86 bionic I guess?
[16:23] <xnox> yes.
[16:23] <doko> ahh, ok
[16:23] <doko> based on which 4.x?
[16:23] <cjwatson> cross for small values of cross
[16:24] <xnox> doko: 4.7, but it compiles bionic libc, somehow with missing symbols required for a working ssp. thus nothing links.
[16:24] <stgraber> LXC:
[16:24] <stgraber>  - Fixed quite a few lxc-ls bugs (nested unpriv containers, stopped containers, dealing with invalid config, ...)
[16:24] <stgraber>  - Fixed a small bug in the python3-lxc binding (missing exported function).
[16:24] <stgraber>  - Fixed some more corner cases of lxc-download
[16:24] <stgraber>  - Code reviews, testing and LXC on Android debugging
[16:24] <stgraber>  - Preparing for LXC 1.0.1, scheduled for later today
[16:24] <stgraber> CGManager support for logind:
[16:24] <stgraber>  - Got a patch covering all code paths we care about, now I just need to make this actually work...
[16:24] <stgraber>  - Landing for this will be blocked by the cgmanager MIR and by its own FFe
[16:24] <stgraber> Networking:
[16:24] <stgraber>  - Re-applied our ifenslave-2.6 delta to the new ifenslave source
[16:25] <stgraber>  - Started going through some of the bug reports
[16:25] <stgraber> System-image:
[16:25] <stgraber>  - Reviewed and merge/rejected all pending MPs for system-image/server
[16:25] <stgraber>  - Implemented code to rename channels and to create channel redirects (to transition users after a rename)
[16:25] <stgraber>  - Tested the planned rename of all existing channels to ubuntu-touch/<channel name>
[16:25] <stgraber> Other:
[16:25] <stgraber>  - Did a click landing.
[16:25] <stgraber> (DONE)
[16:26] <slangasek> ok, any questions over status?
[16:28] <slangasek> [TOPIC] AOB
[16:28] <slangasek> anything else?
[16:28] <bdmurray> could somebody look at bug 1288171?
[16:29] <barry> i will take a look
[16:29] <xnox> cjwatson: re:click landings what about lp:~xnox/click/chroot-sessions?
[16:29] <cjwatson> queued :)
[16:29] <barry> (it's already on my radar, i.e. browser tab)
[16:29] <cjwatson> I haven't forgotten, just been head-down on libclick
[16:29] <xnox> cjwatson: ack.
[16:31] <cjwatson> nothing else from here
[16:32] <slangasek> #endmeeting
[16:32] <meetingology> Meeting ended Thu Mar  6 16:32:39 2014 UTC.
[16:32] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-03-06-16.06.moin.txt
[16:32] <slangasek> thanks, guys!
[16:32] <barry> thanks!
[16:32] <jodh> thanks!
[16:34] <stgraber> thanks!
[17:00] <czajkowski> aloha
[17:00] <dholbach> hello
[17:00] <YokoZar> morning
[17:01] <czajkowski> anyone here from the technical board
[17:02] <czajkowski> #startmeeting
[17:02] <meetingology> Meeting started Thu Mar  6 17:02:29 2014 UTC.  The chair is czajkowski. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[17:02] <meetingology> Available commands: action commands idea info link nick
[17:02] <dholbach> kees, mdeslaur, slangasek, stgraber: around?
[17:02] <czajkowski> #topic catch up with the Tech Board.
[17:02] <slangasek> dholbach: on the phone, but meaning to be around
[17:02] <mdeslaur> sure, I'm here
[17:03] <czajkowski> slangasek: mdeslaur howdy folks
[17:03] <slangasek> heya
[17:03] <mdeslaur> hi
[17:03] <czajkowski> So how are things in the TB going ?
[17:03] <czajkowski> care to give us an update ?
[17:03]  * pitti waves hello
[17:04] <slangasek> seems pretty low-key, really
[17:04] <slangasek> not much demand for our services :-)
[17:05] <pitti> I joined a few mins late, was there any question to the TB already?
[17:05] <dholbach> for those of you who haven't been around in the last meeting - the CC catches up with governance and community teams as part of our meeting to see how things are going and to have a look at "operations" from a bit of a distance :)
[17:05] <pitti> ah
[17:05] <dholbach> pitti, just generally asking how things have been going :)
[17:05] <pitti> well, we actually skipped the last few meetings due to not having any agenda
[17:05] <pitti> on the meetings we did have, things are usually going well, the biggest recent hiccup was the late re-election of the TB itself
[17:06] <pitti> but the day-to-day business is usually MREs and the like
[17:06] <dholbach> so the new TB members have settled in well in their low-key new activity? :)
[17:06] <czajkowski> pitti: yes we are sorry about that
[17:06] <pitti> it's been a while since we have had a long and difficult technical discussion
[17:06] <pleia2> o/
[17:06] <pitti> czajkowski: no worries, nobody's fault in particular
[17:06] <czajkowski> and hopefully we won't let it go that late again, the issues there was so many boards expiring at the same time, including the CC.
[17:06] <czajkowski> is it worth having a meeting even when there is a blank agenda so people can catch up
[17:07] <YokoZar> pitti: This is perhaps due to the LTS nature of Trusty making all reasonable decisions of this nature done well in advance, yes?
[17:07] <czajkowski> does the community know they can reach out to the TB ?
[17:07] <pitti> we used to have a lot more topics, but that was in the days when ubuntu was driven a lot more by UDSes and community
[17:07] <dholbach> so when there's been long discussions and difficult decisions, how did you feel it generally went?
[17:07] <pitti> and also because there is not that much major change going on in the non-phone-y bits
[17:07] <pitti> YokoZar: yeah, that too
[17:08] <pitti> dholbach: as they should go, really; I remember discussions like "should we install binary drivers by default", the OpenSSL vs. GPL debate, etc.
[17:08] <czajkowski> pitti: so how do you feel it is driven now considering we have online uds
[17:08] <pitti> we had a thorough discussion, voting, annoucned it to the devel crowd, and there generally hasn't been any negative feedback about those
[17:08] <czajkowski> which is great to see
[17:09] <dholbach> pitti, sure - I was just wondering if you were happy with that kind of discussions (so no major delays, everyone weighing in, decision making process is sufficiently refined, etc.)
[17:09] <pitti> dholbach: oh yes; we could have had some speedier discussions for sure, but that's just the nature of timezones and (often) email-based communication, so not much to complain from my side
[17:10] <czajkowski> nods
[17:10] <dholbach> cool
[17:10] <YokoZar> We put the TB on a 2 year cycle as well as the CC, do you guys feel it's correct for them to be replaced mid-way through an LTS cycle or should we move the elections to, say, just after the next LTS release rather than a few months before?
[17:10] <dholbach> I guess that's similar for the CC as well :)
[17:10] <pitti> czajkowski: as I said, the desktop/server bits don't have a lot of structural change these days, so nothing that bubbles up to the TB
[17:10] <YokoZar> (we had a similar argument ~ the CC itself)
[17:10] <pitti> what I am missing a bit is to discuss technical architecture of the phone
[17:11] <czajkowski> pitti: ah interesting
[17:11] <czajkowski> where does that currently take place?
[17:11] <dholbach> pitti, do you have an example of what you feel would have warranted a discussion with the TB?
[17:11] <pitti> there's the ubuntu-phone@ ML and such
[17:11] <dholbach> (just to get an idea)
[17:11] <pitti> and most of the design decisions etc. are just fine
[17:12] <pitti> the main thing that comes to my mind is that in retrospect we should have discussed how to build the image-based upgrades without breaking /etc/ so hard
[17:12] <czajkowski> pitti: so you're saying you agree with them, but you'd like to see the TB perhaps involved more in the discussion or be involved more ?
[17:12] <pleia2> pitti: any thoughts from the tb regarding the init system stuff? (mark kind of announced it after debian made their decision "pending community discussion")
[17:12] <pleia2> seems like something the tb should have weighed in on first
[17:12] <pitti> pleia2: ah, I deliberately didn't bring that up -- but yes, that'll most certainly be a bigger discussion that comes in the next cycle :)
[17:13]  * pleia2 troublemaker :)
[17:13] <pitti> pleia2: well, we will
[17:13]  * pleia2 nods
[17:14] <dholbach> to be fair, Mark said "I will ask the Ubuntu tech board (many of whom do not work for Canonical) to review the position" :)
[17:14] <pleia2> yeah
[17:14] <pitti> czajkowski: yes, but this is the main issue I have really; and it's always easy to say in hindsight "we should have discussed that more", but not that easy to plan in advance
[17:14] <dholbach> but yeah :)
[17:15] <pitti> czajkowski: so I don't want to stress that too much really; but I think we need a version 2 of that, and thus maybe the TB is a good forum to discuss that new design
[17:15] <pitti> but yeah, in general I think it's working ok
[17:15] <czajkowski> pitti: I agree
[17:15] <czajkowski> so perhaps this is something we can raise and see if we can drive some discussion over to yo folks to get your experience in
[17:15] <dholbach> how much of the discussion happens on the mailing list and how much in meetings? do non-TB members weigh in as well?
[17:16] <czajkowski> and ask dholbach pointed out sabdfl did  say he would ask the TB
[17:16] <pitti> pleia2: I'm sure cjwatson and slangasek have a super-huge desire to discuss upstart vs. systemd soon :-) (it's not like they wasted many months of their lifetime thinking about it already..)
[17:16] <mdeslaur> hehe
[17:16] <pleia2> pitti: yeah, I followed the debian discussions
[17:16] <pitti> dholbach: historically, most in meetings due to the synchronous nature
[17:17] <pitti> dholbach: these days, small things like MRE requests or the LTS lifetimes are happening mostly over email as that's more practical
[17:17] <pitti> dholbach: and yes, we have non-TB members posting to the list
[17:17] <dholbach> yeah, that makes perfect sense
[17:17] <cjwatson> pitti: it's on the vUDS schedule I believe
[17:17] <pitti> cjwatson: ah, "fun" :)
[17:17] <pleia2> cjwatson: ah, great
[17:18] <sabdfl> hi all, sorry to be late
[17:19] <dholbach> so it sounds like the TB processes are well-oiled machinery... is there anything which has been on your collective minds to be changed at some stage? or things which have repeatedly been put on the backburner?
[17:19]  * pitti scratches head, nothing comes to my mind from the last 2 years really
[17:19] <dholbach> even better :)
[17:19] <YokoZar> I'll reraise my question from earlier, as I believe it got skipped: We put the TB on a 2 year cycle as well as the CC, do you guys feel it's correct for them to be replaced mid-way through an LTS cycle or should we move the elections to, say, just after the next LTS release rather than a few months before?
[17:19] <pitti> I think the OpenSSL vs. GPL debate came up several times
[17:20] <pleia2> oh, so the CC kept having meetings that had no agenda for a while, which is when we started doing these check-ins, I wonder if something similar might be useful for TB and dev teams?
[17:20] <slangasek> YokoZar: I have no strong opinion on this... more important is to not leave a gap, as we did last fall
[17:20] <pitti> YokoZar: ah, I didn't think that was aimed at TB; as the elections were supposed to happen much much earlier, it would have even been during saucy I believe
[17:21] <YokoZar> Right around saucy release
[17:21] <YokoZar> was original schedule I think
[17:21] <pleia2> yeah
[17:21] <pitti> YokoZar: I actually think it's quite a good time, as traditionally during the LTS cycles there's not that much to decide
[17:22] <YokoZar> pitti: hypothetically, though, if we replace the entire board it might make a bunch of new decisions
[17:22] <czajkowski> pitti: thanks for the udpate this has been great to her and nice to see a healthy TB
[17:22] <czajkowski> pleia2: indeed and I wondered if doing somehting similar for the TB would be useful for them to get to have more discussion here
[17:23] <czajkowski> YokoZar: same could be said for any board at any given time tbh
[17:23] <pitti> YokoZar: yes, but that could happen at any point?
[17:23] <YokoZar> czajkowski: pitti: for sure, but would it be "less bad" after an LTS rather than before?
[17:23] <pitti> so yes, if we elect a board that makes silly decisions, something went wrong before that
[17:23] <pitti> YokoZar: yes, perhaps
[17:23] <dholbach> did anyone see pleia2's question? I personally think it might be worth trying
[17:24] <pitti> YokoZar: but then a new board would actually be thrown into a time when there's potentially many discussions to make, which might be more overwhelming for new members?
[17:24] <czajkowski> pitti: mdeslaur slangasek how about whe you've  a blank agenda, still having a meeting
[17:24] <czajkowski> so people can see a discussion and join
[17:24] <czajkowski> we've started doing this and it's been very useful
[17:24] <mdeslaur> that's what we've done so far
[17:25] <YokoZar> Not sure how frequent it is for "lay folk" to pop into TB meetings and raise an issue, but it does happen with CC meetings from time to time
[17:25] <czajkowski> or you could arrange a catch up wth groups the tb has an interst in
[17:25] <pitti> we usually do
[17:25] <pitti> wait a bit
[17:25] <pitti> then say "nothing to discuss" and end it again
[17:25] <pitti> YokoZar: it does happen quite often; in fact that's the norm, as these days the TB rarely raises issues by themselves
[17:25] <pitti> i. e. someone adds an agenda item and then usually appears in the meeting
[17:26] <dholbach> great - as others have said... I'm quite happy with how the TB is working - I'm done with questions :)
[17:26] <dholbach> keep up the good work everyone! :)
[17:26] <YokoZar> pitti: so perhaps around a time when it's too late to reasonably change things in the LTS cycle, but before hecticness of post-release.  Like around the next UDS we're having.
[17:26] <pleia2> thanks pitti :)
[17:26] <YokoZar> What if elections were considerably before terms starting?
[17:26] <pitti> YokoZar: yeah, sounds good
[17:27] <YokoZar> Like we vote around now, and incoming members start their term after LTS release
[17:27] <pitti> YokoZar: I don't like that very much, I must say; I think it's good for the old board to have a last meeting after the election to hand over, but not much more
[17:27] <pitti> but I don't have a strong opinion on that
[17:28] <YokoZar> Relatedly, I am encouraged by the lack of strong opinions regarding our election rules, it means our politics aren't particularly "politics" ;)
[17:28] <czajkowski> any other questions folks before we wrap up
[17:28]  * sabdfl is still reading the scrollback
[17:28] <pitti> YokoZar: or that things are mostly going well and all that's left to do is finetuning :)
[17:28] <czajkowski> YokoZar: you just like running polls! admit it :P
[17:30] <YokoZar> This is not an "admission" any more than one confesses to liking the sunrise
[17:30] <pleia2> hehe
[17:32] <sabdfl> regarding init
[17:32] <sabdfl> if the TB has a strong opinion different to the broad roadmap of "adopting systemd on an appropriate schedule" then i'm very open to hearing it
[17:33] <pitti> sabdfl: probably the wrong place here, but FWIW, I agree to you
[17:33] <pitti> sabdfl: seeing how much recent action there is in Debian towards adding native systemd packagse to stuff, I think in a year or so we'll have this robust enough
[17:34] <pitti> sabdfl: with RHEL7 moving to systemd the server world ought to catch up quickly
[17:34] <sabdfl> my commentary was not to subvert the TB, but to express that there is no ideological attachment to code that 'belongs' to Canonical
[17:34] <pitti> the desktop world pretty much worked two years ago already, but our concern was the server back then
[17:34] <sabdfl> we'll move where works best, and i trust the TB to map that out
[17:34] <pitti> so for me it's not a question of "if", but "when/how"
[17:35] <YokoZar> So, not understanding much of ubuntu-phone, how specific are the phone-related technical decisions that we can expect in the future?
[17:35] <pitti> as long-term it seems much better to follow Debian than eternally diverging
[17:35] <pitti> YokoZar: they are actually meant to become less and less phone specific over time
[17:35] <pitti> YokoZar: "convergence"
[17:35] <slangasek> pitti: I don't believe that RHEL7 is doing anything that we'll significantly be able to leverage; too much of this is integration work which doesn't translate
[17:36] <slangasek> but I'm not sure the CC meeting is the place to have this discussion :)
[17:36] <pitti> YokoZar: i. e. the phone is by and large a playground (excuse the wording, sabdfl) for trying out new technology like upgrades or display server
[17:36] <pitti> without the need for backwards compat
[17:36] <YokoZar> Yes, I imagined that was the eventual goal of any reasonable implementation.
[17:36] <YokoZar> I would hope phone would soon be "absorbed" into the rest of Ubuntu governance smoothly
[17:36] <pitti> YokoZar: yes, AFAIUI that's the plan
[17:36] <sabdfl> this was a particularly difficult thing to watch unfold, since in a sense we were never consulted on an issue with major consequences for us, and we're a member of the family
[17:36] <sabdfl> but then, some would argue we had great representation at the table, only wearing different hats
[17:36] <sabdfl> nothing more from me, thanks TB for checking in
[17:37] <pitti> the phone has laid a lot of new approaches to both technology (like Mir) and methods (like CI)
[17:37] <YokoZar> And, say, phone community == ubuntu community and phone tech decisions == ubuntu tech decisions with the same relevant governance
[17:37] <pitti> and they are certainly meant to be used on desktop in the future as well
[17:38] <pitti> in practice they are still quite separated these days, but I think that's mostly due to the LTS
[17:38] <pitti> e. g. we can't/shouldn't land things like Mir/Unity 8 now
[17:38] <pitti> and likewise can't turn our upgrade mechanics upside down now
[17:39] <czajkowski> pitti: I like those honest decisisons where we admit things aren't ready even when we wish they were
[17:39] <YokoZar> Do you think the archive itself might continue some of this delta?  I vaguely worry about a future where we have, say, the arm arch for desktop packages have a lot of phone-specific deltas with a separate decision tree from the rest of the distro
[17:40] <czajkowski> any other comments folks before we wrap it up
[17:40] <mdeslaur> there is no archive delta for the phone at the moment
[17:40] <dholbach> YokoZar, that sounds like a summary for the work leading up to the next LTS - bringing unity8 to the desktop and making the convergence happen :)
[17:40] <mdeslaur> it's just using a different version of unity
[17:41] <pitti> YokoZar: yes, it's less along the lines of architecture and more of package selection
[17:41] <pitti> unity8-desktop-session-{mir,x11} in trusty :)
[17:41] <pitti> I expect that to become the default soon
[17:41] <pitti> i. e. convergence to make a leap in 14.10
[17:41] <YokoZar> mdeslaur: Right, and perhaps if we do convergence especially "wrong" in the future we might have different versions of a lot of things on phone vs desktop
[17:42] <pitti> sabdfl: btw, any chance we can get the u name before the release? it's needed in a couple of places, and last time we had to do a number of SRUs due to that
[17:42] <YokoZar> ugh
[17:42] <YokoZar> I'll follow up with him (he left)
[17:42] <YokoZar> Though
[17:42] <YokoZar> I have hounded him with that question before
[17:42] <pitti> ah
[17:42] <YokoZar> I suspect hearing it from the TB as well might help
[17:43] <czajkowski> ok thanks folks
[17:43] <dholbach> thanks a lot everyone!
[17:43] <mdeslaur> thanks!
[17:43] <pitti> thanks everyone!
[17:43] <YokoZar> Mark WILL delay the full name as long as possible for marketing/other purposes though
[17:43] <YokoZar> Thank you folks
[17:44] <dholbach> Do we have any other business?
[17:44] <czajkowski> #action YokoZar Mail Mark re  U name for the TB to use for opening up next release
[17:44] <meetingology> ACTION: YokoZar Mail Mark re  U name for the TB to use for opening up next release
[17:44] <czajkowski> #endmeeting
[17:44] <meetingology> Meeting ended Thu Mar  6 17:44:44 2014 UTC.
[17:44] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-03-06-17.02.moin.txt
[17:45] <dholbach> thanks czajkowski
[17:46] <slangasek> thanks :)
[21:58] <roadmr> juuust waiting for the precise package to actually be published
[22:04] <spineau1> no meeting today? :-(
[22:06] <spineau> hggdh: hello, no meeting today?
[22:09] <spineau> PabloRubianes: hello, no membership meeting today?
[22:09] <PabloRubianes> spineau, I don't see other members from the board
[22:09] <PabloRubianes> :S
[22:09] <PabloRubianes> checking
[22:11] <cjohnston> !rmb
[22:14] <PabloRubianes> cjohnston, there's no quorum :S
[22:15] <cjohnston> nope
[22:15] <roadmr> :(
[22:15]  * spineau will go to bed a bit sad
[22:17]  * toddy gives spineau a cookie
[22:18] <hggdh> o/
[22:18] <hggdh> sorry, on a meeting up to now
[22:20] <pleia2> I can pitch in if you need a 4th
[22:20] <IdleOne> I'm also here
[22:20] <IdleOne> that makes 5
[22:20] <pleia2> oh good, no need for me :)
[22:20] <spineau> and I'm still here :)
[22:20] <hggdh> :-)
[22:20] <IdleOne> someone sit on the chair and get this started
[22:20] <roadmr> \o/
[22:21] <hggdh> ok
[22:21] <spineau> hey hggdh
[22:21] <hggdh> #startmeeting Ubuntu membership Board
[22:21] <meetingology> Meeting started Thu Mar  6 22:21:24 2014 UTC.  The chair is hggdh. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[22:21] <meetingology> Available commands: action commands idea info link nick
[22:21] <hggdh> spineau: long time :-)
[22:21] <spineau> hggdh: indeed, 2010?
[22:22] <hggdh> OK. We are now on the meeting. We will go by the order in the wiki.
[22:22] <hggdh> the first one is ...
[22:23] <hggdh> rohsigma. Is he online?
[22:23] <hggdh> actually, rhosigma
[22:23] <hggdh> no...
[22:24] <hggdh> #topic -- spineau for Ubuntu Member
[22:24] <hggdh> spineau: please go ahead and introduce yourself
[22:24] <spineau> ok
[22:24] <spineau> Hello, I'm Sylvain Pineau (Wiki: https://wiki.ubuntu.com/SylvainPineau, LP: https://launchpad.net/~sylvain-pineau)
[22:24] <spineau> I live in France and I'm working for the Hardware Certification Team at Canonical
[22:24] <spineau> My main focus is QA automation for Ubuntu, I'm one of the core developper of Checkbox, the system testing application that we have on the CD since 2008.
[22:24] <spineau> I led a vUDS session last November to share the Checkbox roadmap for Trusty.
[22:24] <spineau> I'm also an upstream maintainer of several Checkbox dependencies in Debian
[22:25] <spineau> I contribute to kernel SRU testing and made various contributions to other test frameworks used by the community.
[22:26] <hggdh> I see you have some testimonials :-)
[22:26] <spineau> hggdh: indeed, and roadmr accepted to be online with uq
[22:26] <spineau> us
[22:26]  * roadmr waves - here to support spineau
[22:27] <hggdh> roadmr: hi, I see you :-)
[22:27] <hggdh> I have no questions for you -- I know your work...
[22:27] <spineau> I didn't mention UEC ;-)
[22:28] <IdleOne> Go ahead and mention it a little
[22:28] <hggdh> #voters IdleOne hggdh cjohnston PabloRubianes
[22:28] <meetingology> Current voters: IdleOne PabloRubianes cjohnston hggdh
[22:29] <spineau> UEC was Ubuntu Enterprise Cloud, I wrote some tests for it
[22:29] <hggdh> yeah. UEC was fun regarding tests...
[22:29] <spineau> it was using eucalyptus before we decided to use openstack
[22:30] <cjohnston> spineau: do you do anything with a LoCo team or anything else? All I see on your wiki appears to be related to what you do for your job
[22:30] <spineau> cjohnston: I'm not involved with a French loco team, I'm too far from Paris TBH
[22:31] <spineau> cjohnston: I attended to some Perl Mongers meetings but that's  unrelated to ubuntu
[22:33] <spineau> Usually my main way to contribute is via triaging or via IRC
[22:33] <IdleOne> How do you contribute via IRC specifically?
[22:34] <spineau> IdleOne: answering/asking questions
[22:35] <spineau> IdleOne: we created #checkbox to help people who wants to start using the checkbox toolset
[22:35] <spineau> on freenode
[22:36] <hggdh> spineau: anything more to add on community involvement?
[22:37] <hggdh> otherwise, time to vote
[22:37] <hggdh> #vote on spineau for Ubuntu member
[22:37] <meetingology> Please vote on: on spineau for Ubuntu member
[22:37] <meetingology> Public votes can be registered by saying +1, +0 or -1 in channel, (for private voting, private message me with 'vote +1/-1/+0 #channelname)
[22:37] <spineau> hggdh: I provided QA support to other test frameworks over the past years
[22:38] <IdleOne> +0
[22:38] <meetingology> +0 received from IdleOne
[22:38] <spineau> hggdh: outside of myu role at canonical
[22:38] <PabloRubianes> +0
[22:38] <meetingology> +0 received from PabloRubianes
[22:38] <cjohnston> +0 I'd like to see my community involvement
[22:38] <meetingology> +0 I'd like to see my community involvement received from cjohnston
[22:38] <IdleOne> s/my/more/
[22:38] <hggdh> +1 -- I *know* you, so the plus one. But we need to see more community involvement
[22:38] <meetingology> +1 -- I *know* you, so the plus one. But we need to see more community involvement received from hggdh
[22:39] <hggdh> #endvote
[22:39] <meetingology> Voting ended on: on spineau for Ubuntu member
[22:39] <meetingology> Votes for:1 Votes against:0 Abstentions:3
[22:39] <meetingology> Motion carried
[22:39] <cjohnston> IdleOne: ya.. that too
[22:39] <hggdh> spineau: unfortunately, I think the lack of visible community involvement was it.
[22:40] <hggdh> spineau: may I suggest you to beef up the wiki with more community work, and then reapply?
[22:40] <spineau> hggdh: I will, thank you
[22:41] <IdleOne> spineau: thank you. I hope to see you back in a few months
[22:41] <hggdh> spineau: please do no give up. I would be proud to have you as a member.
[22:41] <hggdh> so. Keeping on
[22:42] <spineau> ok, again thank you for your time
[22:42] <hggdh> since rhosigma is not online, I think this is it for this meeting.
[22:42] <hggdh> #endmeeting
[22:42] <meetingology> Meeting ended Thu Mar  6 22:42:23 2014 UTC.
[22:42] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/ubuntu-meeting/2014/ubuntu-meeting.2014-03-06-22.21.moin.txt
[22:42] <cjohnston> Thanks spineau and hggdh
[22:43] <IdleOne> pleia2: you still there?
[22:44] <pleia2> mhmm
[22:45] <IdleOne> did you receive that invite to the rmb channel?
[22:45] <pleia2> yes, but it got lost in my status window that I never look at :)
[22:45] <IdleOne> lol, look at it please. we need some clarification
[23:08] <IdleOne> AlanBell: Does meetingology have a #command that allows the chair to set a required positive total for a motion to be considered as carried?
[23:13] <IdleOne> oh it does
[23:13] <IdleOne> #votesrequired
[23:13] <pleia2> ah, nice :)
[23:13]  * pleia2 learned something new
[23:14] <IdleOne> ok so CC we need some help with that email I sent
[23:14] <IdleOne> :)
[23:15] <IdleOne> hmm, that doesn't do exactly what I thought it did
[23:15] <IdleOne> that sets the number of votes needed for a vote to be consider "voted on"


[00:24] <xu-irc10w> Hello.
[00:25] <xu-irc10w> Is there a way to make the taskbar tabs square shaped?
[00:26] <xu-irc10w> Like those of Ubuntu or Linux Mint.
[17:50] <rud0lf> Today I've Learned that if you press Escape key on login screen, it will blank the screen
[17:50] <rud0lf> i was cleaning keyboard and found it out accidentally :)
[17:54] <gnrp> rud0lf: lol, never knew


[10:07] <infinity> gccgo-go?  That's not redundant-redundant..
[10:28] <jamespage> infinity, its the go tool built using gccgo instead of golang gc - for proposed main inclusion
[20:11] <zul> can someone promote python-networkx (#1271609), python-taskflow (#1271617), python-oslo.rootwrap (#1259985) so we can get openstack built in the archive please