[02:48] <mhall119> flocculant: making the CoC easier to sign was a discussion we had like a year ago


[12:17] <Admiral_Chicago> okay nixternal nixternal nixternal :). I thought it was a problem with the system docs. I was excited for buliding patches
[12:17] <nixternal> grr
[12:18] <nixternal> it is a problem with system docs, but you need to first understand is it supposed to link elsewhere or has the install-guide not been uploaded to h.u.c
[12:18] <nixternal> I don't mess with the Ubuntu side, they know what they are doing, so I leave it alone :)
[12:19] <nixternal> now if it were Kubuntu side, then I would be able to give you a better answer
[12:21] <Admiral_Chicago> well as long its not something i can fix, i understand that
[12:22] <nixternal> it isn't something I can't fix either, so don't feel bad ;)
[05:16] <ubotu> New bug: #114266 in ubuntu-doc ""Installing" should be included to h.u.c." [Undecided,Unconfirmed]  https://launchpad.net/bugs/114266
[11:38] <Simon80> how would I contribute something to http://doc.ubuntu.com/ubuntu/packagingguide/C/gs-pbuilder.html?
[11:40] <mdke> Simon80: you should get some help at https://wiki.ubuntu.com/DocumentationTeam/GettingStarted but if you have any questions please ask
[11:43] <Simon80> so I have to check out the files, edit, make a patch, and submit it?
[11:45] <Simon80> cause I'm lazy, and would just like to suggest an easier way to do multiple pbuilders, but that seems like a lot of work compared to editing a wiki page
[11:48] <Simon80> ?
[11:49] <Simon80> mdke ^^
[12:11] <Simon80> bah, you guys win, I'm editing the xml now :)


[08:37] <zyga> kyrofa: snap refresh, I suspect
[08:37] <zyga> hey Kyle; how are you today?
[08:37] <zyga> (and greetings from the last day of Flock)
[08:38] <zyga> kyrofa: hey, can you check something for me please?
[08:38] <zyga> ah, I just realized your messages are from 10 hours ago /facepalm
[14:49] <jeremies> Can I trust user Snapcrafters that https://snapcraft.io/eclipse doesn't contain malware?
[14:55] <popey> yes,
[14:55] <popey> https://github.com/snapcrafters/eclipse/blob/master/snap/snapcraft.yaml
[14:56] <popey> it builds from that yaml, which pulls from upstream
[14:57] <popey> https://launchpadlibrarian.net/376399971/buildlog_snap_ubuntu_xenial_amd64_edeec2ed13f63e3af682dd5a8c6978d0-xenial_BUILDING.txt.gz
[14:58] <popey> that's the build log
[15:18] <palasso> hey fellas if I find typos in the blog posts should I open a bug someplace or should I contact the authors?
[15:18] <palasso> I was referring to the blog that is on snapcraft.io
[15:20] <jeremies> popey: Thank you very much !
[15:21] <palasso> Which probably follows some of the articles from https://blog.ubuntu.com/ (with the tags snapcraft, snap etc.)


[01:10] <axw> abentley: don't suppose you're working? CI seems to have died... merge job has been running for 2 hours
[01:11] <axw> I'll just kill it and hope for the best
[02:14]  * thumper heading out for a bit, taking daughter to BJJ
[03:40] <natefinch> google: ps human readable memory
[03:40] <natefinch> response: <hugeass command>
[03:41] <natefinch> nobody's put a -h on ps, huh?
[05:42] <natefinch> nobody's put a -h on ps, huh?
[05:42] <natefinch> oops wrong window
[05:52] <natefinch> oops wrong window
[06:31] <mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
[06:34] <mup> Bug #1516891 changed: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
[06:43] <mup> Bug #1516891 opened: juju 1.25 misconfigures juju-br0 when using MAAS 1.9 bonded interface <juju-core:New> <MAAS:New> <https://launchpad.net/bugs/1516891>
[09:04] <frobware> dimitern, ping 1:1?
[09:05] <dimitern> frobware, sorry, omw
[09:54] <axw> wallyworld: http://reports.vapour.ws/releases/3318  -- azure-arm-provider is blessed. what's the process to merge into master?
[09:54] <wallyworld> axw: yay. when master unblocked, just create a branch, merge in tip of feature branch, and propose
[09:55] <axw> wallyworld: cool. no need for review on that I take it?
[09:55] <wallyworld> axw: judgement call, usually no
[09:55] <wallyworld> IMHO
[10:01] <dimitern> voidspace, frobware, jam, fwereade, standup?
[10:14] <voidspace> dimitern: bugger, bugger, bugger
[10:14] <voidspace> got distracted by work
[10:14] <voidspace> sorry
[10:15] <voidspace> dimitern: frobware: dooferlad:  I guess you've finished
[10:15] <dooferlad> voidspace: yep
[10:16] <voidspace> dimitern: frobware: dooferlad: my standup then - I made the changes to add a machine.Principals method for my "address picking algorithm change"
[10:16] <dimitern> voidspace, :) hey, you didn't miss much
[10:16] <voidspace> dimitern: frobware: dooferlad: that made tests pass on CI - it's landed on 1.25 but master is still blocked
[10:16] <dimitern> voidspace, nice! yeah - too bad for master :/ I have 3 PRs blocked as well
[10:17] <voidspace> I thought I'd finished the implementation of Subnets using the new MAAS API and am waiting on the test harness - will need to sync up with dooferlad for that
[10:17] <voidspace> so I'd started on the ListSpaces implementation
[10:17] <dimitern> voidspace, please, call it Spaces()
[10:17] <voidspace> in the process of that this morning I discovered a flaw in the new Subnets code (wasn't filtering by subnet ID)
[10:17] <voidspace> dimitern: ok - I thought ListSpaces was your idea
[10:17] <voidspace> but fine
[10:17] <dimitern> voidspace, it was an early idea, but since we have Subnets() now, let's keep the consistency in names
[10:18] <voidspace> and it was fixing the subnet ID filtering that distracted me
[10:18] <voidspace> done now
[10:18] <voidspace> dooferlad: have you made a start on the maas test server update?
[10:18] <dooferlad> voidspace: yes
[10:19] <dimitern> voidspace, cheers
[10:19] <dooferlad> voidspace: working on it now. Will ping you when I have something worth sharing
[10:19] <voidspace> dooferlad: cool, let me know if you have any questions
[10:19] <voidspace> dooferlad: great!
[10:19] <voidspace> dooferlad: I'll carry on with Spaces then - can land it as a single branch
[10:23] <voidspace> dimitern: environ.Spaces() can just return a map of string -> []SubnetInfo - right?
[10:23] <voidspace> dimitern: and should we do anything with the maas "Default Space" (named like that)
[10:23] <voidspace> dimitern: we want to make sure our default space is the same as the maas default space
[10:24] <voidspace> otherwise nothing works
[10:26] <dimitern> voidspace, I think Spaces() needs to return []network.SpaceInfo
[10:27] <voidspace> dimitern: ok
[10:27] <voidspace> dimitern: all SpaceInfo will have is a name and a []SubnetInfo
[10:27] <dimitern> voidspace, and that in turn should have a Name, ProviderId, Subnets []network.Id
[10:27] <voidspace> there's no provider id beyond name
[10:27] <voidspace> dimitern: you want network.Id for subnets rather than SubnetInfo ?
[10:27] <dimitern> voidspace, I don't think we should care about the "Default space"
[10:28] <voidspace> dimitern: what do you mean by "not care" - not include it?
[10:28] <dimitern> voidspace, well, if we require Spaces() to return the full subnets info, wouldn't that be too restrictive on providers?
[10:28] <dimitern> voidspace, no, include it - we just won't use it for openstack
[10:28] <voidspace> the only provider we have that can list spaces is maas
[10:28] <dimitern> voidspace, for now
[10:29] <voidspace> and I suspect that for any provider we implement spaces for, the only way we'll get a slice of subnet IDs is by getting full subnet info anyway
[10:29] <dimitern> voidspace, will it be easier to do []SubnetInfo instead?
[10:29] <dimitern> voidspace, I mean, SpaceInfo with Subnets []SubnetInfo
[10:29] <voidspace> it would mean throwing away less information away
[10:29] <voidspace> so marginally less work
[10:30] <dimitern> voidspace, ok, let's do it so Spaces() return the full subnets info
[10:30] <voidspace> and include default space
[10:31] <voidspace> we need to be careful when we populate the model that we don't end up with a "juju default space" and a "maas default space" that are actually the same thing but we treat them differently
[10:33] <dimitern> voidspace, well, since a juju space name cannot contain a space, "Default space" will be the ProviderId, the juju name will need to be something like "default-space" I guess
[10:33] <voidspace> dimitern: so I need to transform all maas names into juju compatible ones
[10:34] <voidspace> dimitern: so ironically the "Provider Id" will be much more human readable than the "Space Name"
[10:34] <voidspace> dimitern: why do we have that restriction?
[10:34] <dimitern> voidspace, because of constraints and bindings
[10:34] <voidspace> ah
[10:34] <voidspace> fair enough
[10:35] <dimitern> voidspace, the transformation should be just lowercase it and replace spaces with -
[10:35] <voidspace> dimitern: sooo... when I fetch the space name from the maas subnet result I need to transform there too
[10:35] <voidspace> SubnetInfo.SpaceName has to be the juju space name
[10:36] <dimitern> voidspace, yeah I think so
[10:37] <voidspace> cool
[10:37] <voidspace> dimitern: thanks
[10:37] <voidspace> dimitern: hmmm... that's a one way transform though
[10:38] <voidspace> dimitern: (i.e. you won't be able to deterministacally go from the SpaceName on a Subnet to the MAAS space)
[10:38] <voidspace> dimitern: you can list spaces to see that though
[10:38] <voidspace> which will have both
[10:38] <voidspace> probably doesn't matter
[10:38] <dimitern> voidspace, when talking to maas we always need to use the provider id - we should have it once the space is imported
[10:39] <voidspace> dimitern: sure
[10:39] <voidspace> dimitern: but if someone sees a SubnetInfo (i.e. output from subnets list) the space name shown there is *not* the maas space name
[10:39] <dimitern> voidspace, but I don't think we'll need to do juju space name -> maas space provider id anywhere
[10:39] <voidspace> I'm talking about the user - not us
[10:39] <dimitern> voidspace, ah, sure - we need to have ProviderSpaceId on SubnetInfo
[10:40] <dimitern> voidspace, in addition to SpaceName
[10:40] <voidspace> that means a new facade
[10:40] <voidspace> as it's a change to the api output
[10:40] <voidspace> are you *sure* we need that as it's a lot of extra work
[10:40] <voidspace> (well - a moderate amount)
[10:40] <dimitern> voidspace, ProviderSpaceId is optional
[10:40] <voidspace> I say we should be aware of it but not do it for now
[10:41] <dimitern> voidspace, but good point about the versioning
[10:41] <voidspace> dimitern: still need a new facade, if someone writes any code depending on that value being present then they need to know which api version to require
[10:41] <dimitern> voidspace, that's the client subnets facade you're talking about?
[10:41] <voidspace> dimitern: yep
[10:41] <voidspace> as it's in 1.25
[10:41] <dimitern> voidspace, yeah, I think before the release we should bump the version for sure
[10:42] <voidspace> dimitern: I say we don't need SpaceProviderId on SubnetInfo yet
[10:42] <dimitern> voidspace, but for the time being let's just keep it in mind (probably add a card for it though, once your change lands)
[10:42] <voidspace> cool
[10:42] <voidspace> nobody may actually care in practise, but if they do we can add it
[10:43] <dimitern> voidspace, we should be serious about api backwards compatibility
[10:43] <dimitern> voidspace, but given the time frame, it can wait for a while
[10:52] <voidspace> dimitern: so I think I do need to add SpaceProviderId to SubnetInfo - as it's needed for Spaces
[10:52] <voidspace> dimitern: however I don't need to add it to the apiserver SubnetResults
[10:53] <dimitern> voidspace, not yet, yep
[10:53] <dimitern> voidspace, it can stay within the provider code
[10:53] <dimitern> voidspace, and for importing at bootstrap we don't need to modify the api facades at all, since we have access to state at that point
[10:54] <voidspace> dimitern: and access to the provider
[10:55] <voidspace> dimitern: but we do need the proper provider id, so it will need to be on SubnetInfo (which is what we build the state model from)
[10:56] <dimitern> voidspace, we do have access to the provider when we have the environ config
[10:56] <dimitern> voidspace, network.SubnetInfo != params.SubnetInfo btw exactly for that reason
[10:57] <voidspace> yep, understood
[11:02] <mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
[11:11] <mup> Bug #1516975 changed: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
[11:14] <mup> Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
[11:26] <mup> Bug #1516977 changed: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
[11:26] <mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
[11:32] <mup> Bug #1516975 changed: Incompatible version formats <juju-core:Invalid> <https://launchpad.net/bugs/1516975>
[11:32] <mup> Bug #1516977 opened: juju upgrade-juju should guess version number <juju-core:New> <https://launchpad.net/bugs/1516977>
[11:44] <mup> Bug #1516989 opened: juju status <service_name> broken <juju-core:New> <https://launchpad.net/bugs/1516989>
[13:02] <fwereade> straw poll: `type NotifyChan <-chan struct{}`, or `type NotifyChannel <-chan struct{}`
[13:03] <fwereade> jam, dimitern, frobware, anyone? ^^
[13:08] <dimitern> frobware, I'd vote for the first one
[13:08] <dimitern> sorry :) I meant fwereade  ^^
[13:09] <fwereade> dimitern, cheers
[13:17] <frobware> dimitern,  fwereade: for me the latter. :)
[13:18] <frobware> fwereade, speaking it out loud (in my head) I'm talking about a "channel"
[13:20] <dimitern> frobware, yeah, but the type name is "chan" and it's more common in the go code base to use Chan vs Channel
[13:22] <fwereade> dammit, now it's even again, if someone wants to tie-break?
[13:23] <fwereade> I do favour Chan myself but can't really muster up very strong arguments either way
[13:23] <perrito666> I would vote for the seccond, there is no sense in adding the type to the name of something in a typed language
[13:23] <dimitern> fwereade, frankly, I don't care that much :) you can count me towards Channel if it helps
[13:24] <fwereade> Channel it is then, thanks all
[13:25] <fwereade> and: dimitern, frobware, perrito666: can I trouble any of you for reviews of http://reviews.vapour.ws/r/3143/ and http://reviews.vapour.ws/r/3146/ please?
[13:26] <fwereade> if I can get LGTMs there I can apply the various fixes for the pipeline to http://reviews.vapour.ws/r/3147/ and land in one fell swoop
[13:27] <dimitern> fwereade, I'll have a look shortly
[13:27] <fwereade> 3143 has already been looked at and I *think* just needs an LGTM and/or second opinion on the open issue
[13:27] <fwereade> 3146 is just a copy-code-and-fix-imports
[13:27] <fwereade> dimitern, tyvm
[13:48] <fwereade> frobware, opinion on thumper's comment at http://reviews.vapour.ws/r/3143/diff/3/?file=159341#file159341line96 ?
[13:48] <fwereade> frobware, am inclined to drop the issue but if anyone can tell me *why* it's bad I will change it
[13:50] <frobware> fwereade, looking
[13:54] <frobware> fwereade, plan.Init is actively populated with workers at this stage?
[13:55] <fwereade> frobware, yeah
[13:55] <fwereade> frobware, ha! some asshole could change Init once the func's returned
[13:55] <fwereade> frobware, thanks
[14:02] <dooferlad> dimitern, frobware, voidspace: https://plus.google.com/hangouts/_/canonical.com/maas-juju-net
[14:02] <dimitern> dooferlad, omw 2m
[14:09] <mup> Bug #1516975 opened: Incompatible version formats <juju-core:New> <https://launchpad.net/bugs/1516975>
[14:46] <voidspace> dooferlad: sooo...
[14:46] <dooferlad> voidspace: yep?
[14:46] <voidspace> dooferlad: I'll be changing my implementation to call the /node/{id}/ endpoint which now includes subnet information in the output
[14:47] <voidspace> dooferlad: which the test server may or may not already support - probably not
[14:47] <dooferlad> no, not yet
[14:47] <voidspace> dooferlad: so if you could include that in your test server work that would be wonderful :-)
[14:47] <dooferlad> voidspace: sure
[14:47] <voidspace> thanks
[14:56] <natefinch> rofl.... the output for juju run is sorted by machineID... alphabetically... i.e. 1, 10, 11, 12, 2, 3, 4
[15:07] <mattyw> katco, not merging lxd in master? I'm excited for it to happen though
[15:15] <mup> Bug #1517076 opened: juju run output is sorted by machine id alphabetically not numerically <juju-core:New> <https://launchpad.net/bugs/1517076>
[15:16] <dooferlad> voidspace: this is more involved than just subnets because they depend on fabrics and VLANs. Fun :-|
[15:16] <voidspace> dooferlad: we're not initially going to be using fabrics and vlans though
[15:16] <voidspace> dooferlad: so even if they *should* appear in json output you can restrict the test server to just stuff that we're using
[15:17] <voidspace> when we need fabrics and vlans we can add them
[15:17] <dooferlad> voidspace: hmm, OK
[15:17] <voidspace> test server support doesn't need to be complete
[15:17] <dooferlad> voidspace: I will just dump out some sensible defaults
[15:17] <voidspace> cool
[15:17] <voidspace> it doesn't look like I'll need to query a subnet's ip addresses by the way
[15:17] <voidspace> if you haven't done that yet
[15:17] <voidspace> if you have there's no harm in keeping it
[15:18] <dooferlad> voidspace: Oh, I haven't got the basics down yet, but ignoring VLANs removes quite a chunk of work.
[15:18] <voidspace> yay \o/
[15:23] <dimitern> fwereade, sorry, I just finished a call now and managed to push first of your reviews
[15:23] <fwereade> dimitern, np, I've been tussling with worker/environ again
[15:27] <katco> mattyw: we're merging lxd into master. waiting for bless from ci
[15:27] <fwereade> dimitern, and, thanks for the detailed review: I'm not sure I'll be making any code changes there, but there's no harm in making the comments less stupid
[15:28] <dimitern> fwereade, and the other one is done - I hope the reviews are useful  :)
[15:28] <dimitern> fwereade, yep +1
[15:29] <dimitern> katco, hey, any idea about that blocker bug? didn't we decide to rollback issues like that..
[15:31] <katco> dimitern: we're going to try and get a fix in before EOD today, if not we'll revert
[15:35] <mattyw> katco, much excite ;)
[15:35] <katco> mattyw: :)
[15:38] <dimitern> katco, ok, thumbs up then :)
[15:45] <mup> Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
[15:48] <mup> Bug #1517092 changed: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
[15:54] <mup> Bug #1517092 opened: [xenial] libgo panic doing a bootstrap on ARM64 <arm64> <bootstrap> <xenial> <juju-core:New> <https://launchpad.net/bugs/1517092>
[16:33] <voidspace> dimitern: frobware: dooferlad: openstack hangout?
[16:34] <dooferlad> voidspace: we are skipping today I think
[16:34] <voidspace> dooferlad: no0pe
[16:34] <voidspace> *nope
[16:34] <voidspace> dooferlad: we skipped the second one last week
[16:35] <dooferlad> voidspace: and at this mornings hangout we discussed canceling this one
[16:35] <dooferlad> voidspace: which I realise you weren't at
[16:36] <dooferlad> voidspace: so, we should have mentioned that! I guess it should have been canceled in our calendars as well. frobware, dimitern?
[16:36] <voidspace> dooferlad: dimitern and the open stack guys are here
[16:36] <voidspace> but it's a low key discussion
[16:37] <voidspace> dooferlad: probably no harm in you skipping
[16:45] <natefinch> if we juju add-machine and then juju deploy, shouldn't the deployed unit get placed on the existing clean machine?
[16:45] <natefinch> i.e. instead of having deploy add another machine
[16:45] <natefinch> fwereade: ^
[16:50] <dooferlad> voidspace: https://code.launchpad.net/~dooferlad/gomaasapi/subnets
[16:51] <dooferlad> voidspace: I can remove most of the VLAN code (untested) and propose a merge now, or you can just use what is there until I have finished up vlans, spaces and subnets. Shouldn't take long now.
[16:52] <voidspace> dooferlad: I can start using what you've got
[16:53] <voidspace> dooferlad: I'm "retooling" to use the node api instead of subnets plus addresses for when we're filtering by node id
[16:53] <voidspace> dooferlad: that's almost done and I have the start of maasEnviron.Spaces() too
[16:53] <voidspace> dooferlad: so plenty to be getting on with, but I'll need this code "real-soon-now"
[16:53] <voidspace> dooferlad: if I need it before you're done I'll use your branch until it lands
[16:55] <dooferlad> voidspace: sounds good. So far I just have basic get/post/put/delete support for subnets. I need to integrate subnets into nodes, add op=?? (if you need that) etc.
[16:55] <voidspace> I don't need ip_addresses now
[16:56] <voidspace> I still need unreserved_ranges
[17:11] <cherylj> sinzui: for the 1.26-alpha2 release notes, should they just be appended to the 1.26.0 release notes doc?
[17:11] <sinzui> cherylj: yes please
[17:11] <cherylj> sinzui: thanks!
[17:12] <fwereade> natefinch, assuming constraints match hardware characteristics, yes
[17:13] <natefinch> fwereade: was not seeing that happen last night on 1.25
[17:14] <fwereade> natefinch, I don't think I have the mental bandwidth to do more than say "that sounds like a bug then"
[17:15] <natefinch> fwereade: no problem, just wanted to confirm that it really should be putting the unit on the existing machine, assuming the machine would otherwise be ok.
[17:15] <natefinch> (clean, matches constraints, etc)
[18:09] <marcoceppi> cherylj: we're back to power8
[18:09] <marcoceppi> it's no longer a proxy issue
[18:09] <marcoceppi> we're getting a machine-0 log in the next 30 mins
[19:37] <katco> natefinch: how's bug fix coming?
[19:39] <natefinch> katco: having some trouble reproing... running CI test s manually now to see if I can see it happen
[19:39] <katco> natefinch: k, lmk what happens. maybe menn0 did fix it :)
[19:40] <natefinch> that would be cool :)
[20:06] <natefinch> mgz: you around?
[20:06] <natefinch> or abentley?
[20:07] <abentley> natefinch: Hi.
[20:07] <natefinch> I'm looking at the jes CI failure on master... but when I try to run it I get provider validation failed: invalid EC2 provider config: environment has no access-key or secret-key
[20:08] <natefinch> this is when it's trying to do create-environment on top of the controller environment
[20:08] <natefinch> ...obviously the controller environment was created fine with an access key and secret key
[20:12] <abentley> natefinch: I could be wrong, but I don't think the controller environment provider config is used to create the hosted environments.
[20:13] <natefinch> thumper, menn0: is there a trick to getting the jes CI test to run?  It seems to be failing when it tries to create-environment on top of the controller environment, saying it can't find EC2 keys
[20:13] <thumper> natefinch: you need to give it config for the environment, which includes cloud credentials
[20:14] <abentley> natefinch: Which jes test do you mean?
[20:15] <natefinch> thumper: I did... it bootstraps the controller environment just fine, then fails to create the child environment (or whatever we're calling them)
[20:15] <natefinch> abentley: assess_jes_deploy
[20:16] <thumper> did you pass the config through to the create environment call?
[20:17] <natefinch> thumper: I don't know?  I gave the script the CLI args it asked for, and it didn't say I was missing any
[20:17] <thumper> hosted environments are what we are calling them
[20:18] <abentley> natefinch: Does environments.yaml contain  access-key and secret-key for the "env" you specified?
[20:20] <natefinch> abentley: yes. Like I said, it was able to bootstrap the controller environment, so obviously those exist and are correct (also I can bootstrap that environment manually).
[20:21] <menn0> natefinch: assess_jes_deploy worked for me but I had to hack it a little to do an --upload-tools so it would use juju from my machine
[20:21]  * menn0 checks what he did
[20:21] <thumper> natefinch: I'm not sure how the ci script creates the hosted environment
[20:21] <abentley> natefinch: Not obviously.  Perhaps bootstrap respects environment variables and create-environment does not, for example.
[20:23] <menn0> abentley, natefinch: I don't have any EC2 related env vars set
[20:23] <menn0> abentley, natefinch: here's what I did: ./assess_jes_deploy.py menn0-ec2 ~/tmp/workspace/bin/juju ~/tmp/workspace/logs menn0-testing
[20:24] <menn0> menn0-ec2 is an EC2 env defined in my environments.yaml
[20:24] <menn0> menn0-testing is the name of an env that the test will create, cloning the settings from menn0-ec2
[20:25] <menn0> ~/tmp/workspace/bin/juju is the path to the juju binary (jujud etc are next to it in the same directory)
[20:25] <natefinch> menn0: that's what I did, too
[20:25] <menn0> ~/tmp/workspace/logs is where I asked for the artifacts to go
[20:27] <menn0> natefinch: I also modified assess_jes_deploy.py so that the uploadTools arg to boot_context() is True instead of False
[20:27] <menn0> but I don't think that will cause the problem you're seeing
[20:27] <menn0> natefinch: maybe check your env for EC2 variables? Maybe there's some set that are causing a problem.
[20:29] <menn0> natefinch: try "set | grep -e AWS -e EC2"
[20:29] <natefinch> hmm, so I do have the AWS keys in my environment
[20:29] <natefinch> maybe that's the problem
[20:29] <menn0> natefinch: yep, try removing them
[20:32] <natefinch> or rather, lack of them in the environments.yaml
[20:41] <menn0> natefinch: that makes even more sense
[20:42] <menn0> I imagine the AWS keys will need to be in environments.yaml in order for create-environment to work
[20:46] <natefinch> gah, now it's giving me "failed to create new environment: admin-secret should never be written to the state"  sigh
[21:02] <thumper> natefinch: I bet the config from environments.yaml is just being copied, try not explicitly setting admin-secret in the environments.yaml
[21:02] <thumper> actually, create-environment should read the environment vars
[21:04] <natefinch> thumper: maybe the script is stripping out the env vars?
[21:04]  * natefinch shrugs
[21:04] <natefinch> I can try doing it manually when the script is finished (this is a long-ass test)
[21:04]  * thumper shrugs
[21:06] <natefinch> ahh, wondrous exceptions
[21:06] <natefinch> OSError: [Errno 17] File exists: '../logs/machine-0'
[21:07] <perrito666> tautological errors, next one should be file is file
[21:14] <natefinch> lol, I think the CI test failed while trying to dump logs
[21:14] <natefinch> thanks, exceptions!
[21:14] <thumper> quiet expectations
[21:14] <natefinch> os.mkdir(machine_dir)
[21:17] <natefinch> so after 15 minutes of running the test... it fails because the directory it was trying to create... existed.  Sigh
[21:18] <menn0> natefinch: I wonder if mgz's changes to grab logs for each environment is trying to write all the logs into the same place
[21:18] <natefinch> hmm could be, though it was trying to create machine-0 ... do we have a machine-0 in the host environment?
[21:22] <perrito666> yes, that is a very annoying characteristic of CI tests, they assume a pristine env
[21:27] <mgz> menn0: I did not commit my change yet
[21:28] <mgz> CI tends to just be unforgiving about expected start state
[21:28] <menn0> mgz: ah right
[21:28] <menn0> so it's just that natefinch needs to clear the artifacts directory. there's probably stuff from a previous attempt hanging around.
[21:30] <mgz> I need to restart for hangouts, brb
[21:35] <natefinch> thanks, retrying with empty logs dir
[21:52] <natefinch> um hmm.. weird... cannot run instances: Your quota allows for 0 more running instance(s). You requested at least 1 (InstanceLimitExceeded)
[21:53] <wallyworld> menn0: do we still need to use st.docID(localid) when creating a doc to insert into a collection, or is the prefixing of the doc id with env-uuid automatic now?
[21:53] <wallyworld> everything in state still seems to use st.docID()
[21:54] <menn0> wallyworld: it's not necessary any more
[21:54] <wallyworld> awedome, ty
[21:54] <menn0> wallyworld: we can remove all the calls
[21:54] <menn0> wallyworld: I've got a tech debt card for that
[21:54] <wallyworld> yay, ok
[21:54] <natefinch> katco: I'm not going to be able to figure out this bug before dinner. I have time after dinner, but I've just been strugging with CI too much
[21:54] <menn0> but you know how it is
[21:55] <katco> natefinch: ok, i'll discuss in the release meeting. can you log where you're at somewhere
[21:55] <katco> natefinch: that i can look at?
[21:56] <katco> axw: wallyworld: does the new azure provider use simplestreams?
[21:56] <wallyworld> katco: no
[21:56] <wallyworld> it queries the cloud directly
[21:56] <katco> alexisb: ^^
[21:56] <wallyworld> to look up images ids
[21:56] <katco> wallyworld: ty
[21:56] <wallyworld> katco: i already told alexisb  taht
[21:59] <natefinch> katco: not a lot to say.  Couldn't repro manually, CI hasn't gotten through the test yet (each attempt is like 20 minutes)
[21:59] <natefinch> katco: updated the bug: https://bugs.launchpad.net/juju-core/+bug/1516144
[21:59] <mup> Bug #1516144: Cannot deploy charms in jes envs <blocker> <charms> <ci> <regression> <juju-core:Fix Committed by menno.smits> <https://launchpad.net/bugs/1516144>
[21:59] <katco> natefinch: ok
[22:20] <katco> wwitzel3: ericsnow_: any updates on your end?
[22:21] <menn0> thumper: review pls: http://reviews.vapour.ws/r/3169/
[22:21]  * thumper looks
[22:22] <ericsnow_> katco: patch should be done in the next little while (based on Nate's patch + tests)
[22:22] <katco> ericsnow_: cool. demonstrably addresses memory issue?
[22:22] <ericsnow_> katco: yes
[22:26] <perrito666> super, a bit of rain and power starts doing funny stuff
[22:28] <menn0> thumper: thanks
[22:47] <sinzui> katco: cherylj : Do you have time to review http://reviews.vapour.ws/r/3170/
[22:56] <wwitzel3> katco: not yet, I'll be working on it tonight to try and at least get past this stupid series issue.
[22:56] <katco> wwitzel3: ok
[22:56] <wwitzel3> katco: my plan was to bug someone who is starting their day to take a look at ti with me
[22:56] <katco> wwitzel3: not a bad idea. alexis is also going to see if jam or fwereade have any insights
[22:57] <wwitzel3> katco: yeah, that'd be great. I was going to bug people after Jessa and I have dinner.
[22:58] <katco> wwitzel3: k sounds good. say hi to natefinch-afk; he'll be working on trying to repo the master blocker tonight :p
[22:58] <katco> repro rather
[23:01] <wwitzel3> :)
[23:07] <alexisb> thumper, wallyworld, ^^^ if someone is around when wwitzel3 is back on it would be nice to have a AUS/NZ timezone person to bounce ideas off of
[23:07] <wallyworld> sure


[08:41] <pstolowski> Saviq, hey, how are unity8 landings going? i've 1 silo ready in the pipeline and 1 that will be ready soon (filters)
[09:23] <tsdgeos> pstolowski: it's all complicated
[09:24] <tsdgeos> new sdk needs to land first afaik
[09:24] <tsdgeos> and that's always complex because it's a big beast
[09:31] <pstolowski> tsdgeos, hmm silo 50? it failed in qa afaict
[09:32] <tsdgeos> pstolowski: i think so yes, theywe're working on make it go thought qa again
[09:32] <tsdgeos> i may be wrong in the current status though
[09:32] <tsdgeos> it's all second or third hand info
[09:33] <pstolowski> tsdgeos, Saviq can we try to land silo 76 first then? it shouldn't cause any hiccups
[09:33] <tsdgeos> that's for Saviq to decide, i abstain :D
[10:23] <Saviq> pstolowski, hey, getting some info from Zoltan
[10:24] <Saviq> pstolowski, unity8 not built in there?
[10:25] <pstolowski> Saviq, may need rebuilding again
[10:27] <pstolowski> Saviq, rebuilding unity8 there
[10:29] <Saviq> pstolowski, so, when you're ready, press Lander: Approved, let's see where we are with SDK at that point?
[10:30] <pstolowski> Saviq, okay
[12:46] <mzanetti> Saviq, I'm still puzzled. can I run something on britney manually?
[12:46] <mzanetti> Saviq, the inputMethodSurface is even created in the SurfaceManager's ctor... so it can't be a timing issue. it's like it would use the wrong mock or something.
[12:46] <Saviq> mzanetti, not really, let me find out what I can do (but adding debugs is your best bet)
[12:47] <mzanetti> kk, will add some
[12:48] <Saviq> it's all in cloud these days, so should be possible to spawn a similar one...
[12:49] <mzanetti> ok... I might have found the issue
[12:51] <mzanetti> yep, confident I found it
[12:51] <mzanetti> if only I could reproduce it locally
[12:52] <mzanetti> but it has to do with garbage collection
[12:52] <Saviq> mzanetti, actually pitti can give us ssh access to the node where it fails
[12:53] <mzanetti> ah, that's good to know... let's have one normal run before (preparing my changes for pushing), if that doesn't help, I'd need that
[12:56] <mzanetti> Saviq, pushed, please give it another try
[12:57] <Saviq> mzanetti, going
[13:05] <Saviq> mzanetti, pitti gave me an idea for a local reproducer (qemu), trying that too
[13:53] <mzanetti> ltinkl, if you just could update the comment from "simulate the model reset" to "simulate a changing icon name" in order to have it matching with what the code does
[13:53] <mzanetti> ltinkl, apart from that, it looks good to me, will test it
[13:53] <ltinkl> mzanetti, kk
[13:53] <mzanetti> ltinkl, is this really needed? + cache: false
[13:54] <ltinkl> mzanetti, yup, didn't work without
[13:54] <ltinkl> mzanetti, it would still show the old icon
[13:54] <mzanetti> ok... might want to add a comment there too on why we disable caching then
[13:55] <ltinkl> mzanetti, I even looked at the implementation, it's too smart - if the source path doesn't change, it won't go on and try to reload the image (QQuickImage)
[13:55] <ltinkl> mzanetti, hmmm but... we do change the path now right
[13:56] <mzanetti> yeah... that's what I mean
[13:56] <ltinkl> mzanetti, to empty and then back to the real one
[13:56] <mzanetti> ltinkl, please check if this is still really needed with the new change
[13:56] <ltinkl> mzanetti, aha! will fix then, this was valid for the model reset case
[13:56] <mzanetti> kk
[13:59] <ltinkl> mzanetti, MP updated
[13:59] <mzanetti> cool. I'll give it a try
[14:00]  * ltinkl bbl food
[14:10] <mzanetti> Saviq, any news from britney?
[14:10] <Saviq> mzanetti, oh it will take a while, they only just built
[14:11] <Saviq> mzanetti, trying in qemu locally now
[14:12] <Saviq> mzanetti, http://packaging.ubuntu.com/html/auto-pkg-test.html for reference, a --qemu-options='-cpu SandyBridge' will take you as close to britney nodes as possible
[14:13] <mzanetti> Saviq, can we run QQuickView in qemu now?
[14:13] <Saviq> mzanetti, I think you're mixing up qemu emulated (armhf)
[14:14] <Saviq> this is just virt
[14:14] <mzanetti> ah, right... true
[14:19] <Saviq> pstolowski, I've put silo 76 to Lander: Approved so we get britney feedback
[14:20] <pstolowski> Saviq, ah, I'be jest tested it and found prolly unrelated issue - reflashing without the silo to check
[14:20] <pstolowski> * just
[14:20] <Saviq> kk
[14:45] <Saviq> mzanetti, http://pastebin.ubuntu.com/15259322/
[14:45] <mzanetti> 'setState' of object function() { [code] }
[14:45] <mzanetti> dafuw
[14:45] <mzanetti> dafuq
[14:47] <mzanetti> how is that even possible....
[14:51] <Saviq> mzanetti, that happened for me on qemu
[14:51] <mzanetti> qemu is a liar!
[14:51] <mzanetti> it is not a function
[14:52] <mzanetti> oh well, I guess I gotta set up stuff here then
[14:52] <Saviq> mzanetti, wait, that was with previous packages I think
[14:52]  * Saviq tries again
[14:52] <mzanetti> hmm
[14:52] <mzanetti> right... the previous one would have a dangling pointer
[14:52] <mzanetti> so you might end up on function() { [code] }  indeed
[15:25] <mzanetti> Saviq, so, we really want this? https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1540502
[15:25] <mzanetti> still seems quite useless to me tbh...
[15:26] <Saviq> mzanetti, actually staged mode is quite nice with kbd (on a tablet)
[15:26] <mzanetti> I mean, sure the target is to unify the code, at which point it would just work, but blocking an ota because a phone doesn't do alt+tab, not sure :D
[15:26] <mzanetti> hmm
[15:26] <mzanetti> makes defintely more sense on a tablet, yes
[15:27] <Saviq> mzanetti, so yeah, we really need to unify the switchers ;P
[15:27] <mzanetti> Saviq, yes, about that, we need to talk at some point this week
[15:27] <Saviq> mzanetti, ack
[15:27] <mzanetti> had a meeting with vesa today, it's really not simple
[15:28] <Saviq> I'm not saying it is
[15:28] <mzanetti> not only from an engineering point of view
[15:28] <mzanetti> it's 3 different things from a design point too... and changing the phone expierince is very likely to make it worse
[15:29] <mzanetti> while using the phone stuff on the desktop isn't good either
[15:29] <mzanetti> at which point we'll have 3 different things from a design point of view... if they are different for design, it doesn't really make having it the same from a code point of view easier either
[15:30] <mzanetti> anyways... let's hangout the next days
[16:03] <cimi> tsdgeos, hola
[16:03] <tsdgeos> hola hola
[16:03] <cimi> tsdgeos, can you please recap me on the two reviews for the filters?
[16:04] <cimi> tsdgeos, I forgot if we were blocked on some pawel work, and now is fine or not yet
[16:04] <cimi> or was design
[16:05] <tsdgeos> cimi: should be good to review as far as i remember
[16:06] <cimi> tsdgeos, yeah I dont remember :D is it? :D
[16:06] <tsdgeos> pstolowski: what is the silo filters are on? and can you point cimi to your book scope?
[16:06] <cimi> thanks guys
[16:07] <pstolowski> tsdgeos, cimi silo 54, it's currently rebuilding. ~stolowski/+junk/scope-filters2 is the scope (click/ dir has armhf package)
[16:07] <cimi> thanks pawel
[16:17] <Saviq> mzanetti, got the same "is not a function" error with the newest code, got the testbed set up so I can change things
[16:25] <mzanetti> Saviq, can you print SurfaceManager and SurfaceManager.inputSurface
[16:25] <mzanetti> (in a OOBE hangout atm)
[17:00] <tsdgeos> cimi: https://code.launchpad.net/~cimi/unity8/use-PageHeader/+merge/284942
[20:22] <dandrader> mterry, do you know (or knows who might know) what displays those permission dialogs (like "do you allow camera-app to access the camera")?
[20:23] <mterry> dandrader, no I don't know
[20:23] <mterry> nor do I know who would  :)
[20:23] <dandrader> mterry, ok
[20:25] <Saviq> mterry, camera-service
[20:25] <Saviq> dandrader, ↑
[20:26] <Saviq> or location-service, or *-service
[20:26] <dandrader> Saviq, I wanna reset permissions so that I can trigger those permission dialogs again. any idea where they're stored?
[20:26] <Saviq> dandrader, find ~ -name trust.db
[20:29] <dandrader> Saviq, didn't find anything. but thanks for the clues
[20:30] <Saviq> dandrader, /home/phablet/.local/share/PulseAudio/trust.db
[20:30] <Saviq> /home/phablet/.local/share/CameraService/trust.db
[20:30] <Saviq> /home/phablet/.local/share/UbuntuLocationService/trust.db
[20:30] <Saviq> if those are not there, the prompts should pop up (assuming the app is confined()
[20:30] <Saviq> )
[20:31] <dandrader> Saviq, I don't even have those files. wiped out my .config .local and .cache hoping to get the prompts back to no avail
[20:31] <Saviq> dandrader, you need to restart
[20:31] <Saviq> dandrader, at least those services
[20:34] <dandrader> Saviq, another thing: scopes in untiy8-dash are completely empty. what do I have to kick to get it working? I recall I had it before and tsdgeos helped me out....
[20:35] <Saviq> dandrader, restart scope-registry would be one thing
[20:35] <Saviq> dandrader, ah and you might've lost the favorites
[20:37] <dandrader> Saviq, excellent. got the permission dialog back again. thanks
[20:37] <Saviq> gsettings reset com.canonical.Unity.Dash favorite-scopes
[20:37] <Saviq> dandrader, ↑
[20:38] <dandrader> Saviq, I did have Apps, Music and Videos already. they remain empty though...
[20:41] <Saviq> dandrader, ok so you do have scopes but they're empty... I assume pulling down for refresh does not yield anything? at least it should yield some logging, so clear ~/.cache/upstart/* before


[14:14] <cnd> morning all
[14:14] <cnd> bregma, dandrader: standups :)
[14:14] <dandrader> Fixing tap handling in the unity patch that uses the upcoming nux with integrated geisv2.
[14:14] <cnd> I'm mostly continuing research
[14:14] <bregma> *gulp* no changes
[14:15] <cnd> bregma, do you think you'll get to the MP today?
[14:16] <dandrader> I'm coming to the realization that using only Touch gesture classes is the way to go, at least for Unity.
[14:16] <dandrader> specially when dealing with taps
[14:16] <cnd> dandrader, huh?
[14:16] <cnd> why?
[14:16] <bregma> cnd, I hop to try to get to them, they have a higher priority for me today
[14:16] <cnd> ok
[14:17] <dandrader> cnd,  The tap gesture class is super weird, as it sends only a single update and nothing else. that breaks my logic that assumes gestures have a begin, zero or more updates and a an end
[14:18] <cnd> dandrader, you can change that with a geis option
[14:19] <cnd> GEIS_INIT_SEND_TENTATIVE_EVENTS
[14:19] <cnd> it changes the semantics of every gesture you get though
[14:19] <dandrader> and it's super trivial to check if you have a drag a tap etc from a touch gesture
[14:19] <dandrader> and using touch events the client can better reject and accept candidates
[14:20] <cnd> dandrader, but then you're reimplementing grail inside of unity :)
[14:21] <dandrader> cnd, some 30 lines of code from it
[14:21] <dandrader> the "if X is beyond FOO threshold"
[14:21] <dandrader> part
[14:22] <cnd> dandrader, it sounds like you really just want the tentative events
[14:22] <cnd> it essentially gives you the "touch" semantics
[14:22] <cnd> as in, you get all the events from the initial touch to each touch end
[14:22] <cnd> even for a tap
[14:23] <cnd> but it still uses grail for threshold checking, so you aren't bothered with gestures that don't match your subscriptions
[14:26] <dandrader> that might be the case, yes
[14:27] <dandrader> and that single tap gesture update is also broken as it has IsConstructionFinished == false and you never get an update saying that its construction has finished
[14:29] <cnd> dandrader, ahh, that sounds like a bug :)
[14:29] <cnd> dandrader, please try out the tentative events to see if it fits your needs
[14:33] <cnd> if not, we need to know about it
[14:33] <dandrader> cnd, sure. although I'm not sure how much work it will spare me
[14:33] <cnd> dandrader, it's more about determining where utouch may have issues
[14:34] <cnd> it *should* be providing this functionality
[14:34] <cnd> and it *should* save you work
[14:34] <cnd> if not, then that's a problem :)
[14:34] <dandrader> cnd, window manipulation (with 3 fingers) in unity  for instance
[14:34] <dandrader> you need a touch gesture to show the grab handles ASAP
[14:35] <cnd> dandrader, no, you can do a drag with 0 thresholds
[14:35] <cnd> touch gestures were a hack we threw in
[14:35] <dandrader> then you would need a grab and a pinch subscription
[14:35] <cnd> yeah
[14:35] <dandrader> but the touch gesture already gives you drag and pinch info
[14:36] <cnd> but that's just using the "hack" of touch gestures
[14:36] <dandrader> and with window manipulation there's no need to even bother with threshold checks for drags. you just move the window whenever the touch gesture moves
[14:37] <cnd> dandrader, the second issue with just using touch gestures is that you have to do your own pinch checking
[14:37] <cnd> rather than letting utouch tell you when a pinch has occurred
[14:37] <cnd> but admittedly, that isn't a lot of code
[14:37] <dandrader> cnd,  I mean, a geis gesture event already gives you a wealth of info. all the deltas etc you might want. the only missing bit is the "if X > THRESHOLD" part. but that really trivial
[14:38] <dandrader> and it's more convenient to do such checks in your code than to reach for that plain C api (i.e. less readable) to set the thresholds you want
[14:38] <cnd> dandrader, yes, it's the more trivial part of it all, but it is still relying on a code path that is essentially deprecated
[14:39] <cnd> touch gestures are equivalent to drag gestures with a threshold of 0
[14:39] <cnd> we couldn't implement thresholds way back when we had to hack in touch gestures
[14:40] <cnd> at this point, we shouldn't be using touch gestures because there is a better abstraction
[14:40] <dandrader> cnd, btw, current unity code already does its own pinch checking :)
[14:40] <cnd> and where thresholds are not 0, touch gestures are the wrong choice altogether
[14:40] <dandrader>    if (data->radius > 1.25)
[14:40] <dandrader>   {
[14:40] <dandrader>     _pinch_window->maximize(MAXIMIZE_STATE);
[14:40] <dandrader>     EndDrag();
[14:40] <dandrader>   }
[14:40] <dandrader>   else if (data->radius < 0.8)
[14:40] <dandrader>   {
[14:40] <dandrader>     _pinch_window->maximize(0);
[14:40] <dandrader>     EndDrag();
[14:40] <dandrader>   }
[14:41] <dandrader> cnd,  how intuitive and straightforward is that snippet?
[14:41] <cnd> dandrader, yes, but that's because a pinch for this particular use case occurs through the same gesture as the drag with 0 threshold
[14:41] <cnd> imagine you didn't have drag to move the window
[14:41] <cnd> you just had pinch to maximize/unmaximize
[14:42] <cnd> there's no justification for using a touch gesture, you should be telling grail to listen for a pinch
[14:42] <cnd> and setting the threshold to 0.8
[14:42] <cnd> that way grail automatically rejects any touch motion that doesn't meet such a threshold
[15:16] <dandrader> cnd,  about tentative events. So a successful gesture would have: tentative_begin, tentative_update, update and end whereas a failed one would be tentative_begin, tentative_update and tentative_end?
[15:36] <cnd> you won't get gesture events for failed gestures
[15:36] <cnd> that's part of the purpose of grail thresholds
[15:45] <cnd> tentative is somewhat poorly named
[15:45] <cnd> it's more that you get events that are known to be a part of a subscribed gesture, but you get all the events, including those before the gesture is recognized
[15:50] <cnd> so the first events until a gesture is recognized *were* tentative events, and that's what you're asking for with the geis option
[16:18] <dandrader> cnd, does it make sense to have a gesture_end with is_construction_finished=false?
[16:18] <cnd> dandrader, no
[16:18] <cnd> where are you seeing that?
[16:19] <dandrader> in geis
[16:19] <dandrader> if you do a quick tap
[16:19] <dandrader> I guess it's because the gesture ends before composition_time is passed
[16:19] <cnd> could be
[16:53] <dandrader> hmm... using GEIS_INIT_SEND_TENTATIVE_EVENTS leads to a crash in geis when I do a tap :(
[16:55] <dandrader> maybe the simplest way would be for my GeisAdapter to generate a begin and an end event out of that single tap update event...
[20:44] <cnd> whoa, it's actually cypress chips powering the macbook trackpads
[20:44] <cnd> the bcm597{4,6} chips seem to be just the data transport
[20:49] <cnd> hmm... the cypress chip is merely a programmable SoC
[20:49] <cnd> so Apple and/or Cypress have added touch sensing capabilities on top
[20:51] <cnd> interesting...


[00:00] <RAOF> Who'd object to a little helper class for passing std::funcition<> as a function pointer? :)
[00:02] <RAOF> Only slightly terrifying.
[02:15] <robert_ancell> RAOF, did you upload glmark2 directly to https://launchpad.net/~ci-train-ppa-service/+archive/ubuntu/landing-004?
[02:17] <RAOF> robert_ancell: I did, yes.
[02:17] <robert_ancell> ok, cool
[02:18] <robert_ancell> RAOF, and the vivid package goes to the overlay PPA when this landing is accepted?
[02:18] <RAOF> Yeah, that's my understanding.
[02:19] <robert_ancell> RAOF, so I just pushed the updated xmir in xorg-server into this PPA. What does this mean for the git branch for xorg-server?
[02:20] <RAOF> robert_ancell: You should update the wily branch in git. And probably create a vivid-overlay branch, unless you've just uploaded the wily xorg to vivid.
[02:21] <robert_ancell> RAOF, well, I can't upload this to wily because we don't have the new Mir there yet
[02:21] <RAOF> But the landing PPA will be syncd to wily...
[02:21] <RAOF> Maybe ask tjaalton what he'd like, though.
[02:25] <robert_ancell> I was requested to put xorg-server in the landing. Don't know why we need it there..
[02:26] <RAOF> I think we bumped client ABI, so it needs a rebuild at least.
[02:26] <robert_ancell> yeah, but it would be easier to just do it post hitting wily
[02:28] <RAOF> Yeah, but then untested code is hitting wily!!!!111111
[02:58] <RAOF> Ah.
[02:59] <RAOF> It's always helpful when exceptions are silently discarded, and the only visible result is that everything locks up...
[03:00] <RAOF> *Of course* wayland buffer stride is in pixels, mir buffer stride is in bytes.
[03:48] <duflu_> RAOF: I had a similar issue yesterday. Found a way for my client to make the server segfault but it was hidden. That's a regression of bug 1237332 that Alan intentionally made :(
[03:48] <duflu_> Well, related bug
[03:49] <duflu_> The problem is the "fix" for bug 1285084. We should not have fixed it at all.
[04:33] <anpok_> hm could you also upload that for vivid?
[04:33] <anpok_> robert_ancell: ^ that = xorg-server
[04:33] <anpok_> or is the version different?
[04:34] <robert_ancell> anpok_, I have been trying to but it keeps rejecting the upload. I think we have to give it a special version number so it doesn't complain about two versions.
[04:35] <RAOF> Yeah, you can't upload the same thing to two different series.
[04:48] <robert_ancell> ok, uploaded as 2:1.17.1-0ubuntu5~vivid
[05:02] <duflu> If only there was a way to make libmirclient8 and libmirclient9 both official at the same time. Then most downstreams would not need updating immediately
[05:03] <duflu> You can have both installed at once. Just not both in the distro at once, kind of, except for the release!=proposed period
[05:15]  * RAOF wants to set fire to GLibMainLoop.
[05:15] <RAOF> But will instead head to the shops.
[06:20] <anpok_> hm we still could resurrect the asio loop
[06:21] <RAOF> It's not *that* bad :)
[06:21] <anpok_> duflu: scroll down.. there is predictive user input! http://blog.mattbierner.com/stupid-template-tricks-super-template-tetris/
[06:22] <anpok_> well .. picking up idle tasks from dead instances..
[06:22] <anpok_> provoking fancy invalid instruction crashes ..
[06:22] <RAOF> Heh.
[06:23] <anpok_> asio only has face palms and odd hand wavings..

[06:25] <duflu> asio is a four letter word. But seriously, I've never seen asio do anything worth using in production. It's generally terrible.
[06:25] <duflu> Way over-complicated and not even documented in a way that makes it comprehendable
[06:26] <duflu> My first encounter with asio was its regex library (which compiled to multiple megabytes and caused some compilers grief). So I replaced it with something 10kb in size
[06:26] <duflu> Thus, asio is often and generally a joke
[06:27] <duflu> A bad joke people keep telling
[06:27] <RAOF> Anyone feel like adding some utility code for turning a std::function into a raw function pointer?
[06:28]  * duflu needs to see the outside world for a little while at least once today
[06:29] <anpok_> asio has no regex but .. i guess you mean xpressive .. which is very expressive..
[06:29] <anpok_> RAOF: hm how raw?
[06:29] <RAOF> anpok_: Passable-to-C raw.
[06:29] <RAOF> It's perfectly possible if you don't mind generating the trampolines.
[06:29] <anpok_> so .. void call_it(void*) ?
[06:29] <duflu> anpok_: Sorry I meant boost is generally terrible. Asio is part of boost, no?
[06:30]  * RAOF would just *really* like to be able to pass some bound member functions to a C interface.
[06:30] <duflu> But asio is worse than the boost average even
[06:30] <anpok_> hm it is simpler if you dont use std::function in between..
[06:31] <RAOF> anpok_: Hm. Howso?
[06:32] <anpok_> hm .. ok nah doesnt matter much because you have to pass in objects anyhow..
[06:32] <anpok_> i just thought you could get away with encoding everything inside the type
[06:32] <RAOF> I... don't think so?
[07:02] <anpok_> ah you cannot move it
[07:10] <anpok_> RAOF: http://paste.ubuntu.com/11814229/ something like that?
[07:11] <anpok_> one could do it fancier if I knew how to extract the signature from a lambda
[07:12] <anpok_> ... i.e. avoid the functio.. but on the other hand the c code does not take ownership of the function<..> so the creator needs to keep it alive.. and for that function seems to be a good pick
[07:16] <RAOF> anpok_: Na, something more like http://paste.ubuntu.com/11814245/
[07:18] <RAOF> Was what I was thinking of, but your simpler thing might be enough for what I'm considering.
[07:18] <RAOF> And involves less runtime codepatching.
[07:19] <anpok_> hm but you need the address somwhere.. unless of course if you squeeze the adress of the functio<>  into a symbol with external..
[07:19] <anpok_> then it can be a template param..
[07:19] <anpok_> *external linkage
[07:21] <RAOF> No, no. It's simple. You have a static thunk with a placeholder guard value; you copy the code into memory your trampoline object owns, adjust the guard value to point to the std::function<> that your trampoline object owns, and then return that :)
[07:21] <anpok_> hehe yeah simple
[07:22] <RAOF> Not portable, of course, but the number of segmented memory architectures we care about can be counted on the fingers of one fish.
[07:22] <anpok_> thats what encoding the address of the function into a template param would do..
[07:22] <anpok_> function<>
[07:24] <RAOF> Hm. How could you do that?
[07:25] <RAOF> Or, at least do that in a way that doesn't require a type+external singleton per trampoline?
[07:25]  * RAOF goes to get some fish.
[08:02] <anpok_> RAOF: http://paste.ubuntu.com/11814351/ .. enough fun..
[11:57] <greyback_> anpok_: ping
[11:58] <anpok_> pong
[12:03] <greyback_> anpok_: hey, need your help testing usc with your mir overrideorientation work. Can you check out lp:~unity-team/unity-system-compositor/toggle-cursor2/ please
[12:04] <greyback_> I'm running it, and wanting to test the dbus method
[12:04] <greyback_> (install qdbus-qt5)
[12:05] <greyback_>  sudo qdbus --system  com.canonical.Unity.Screen / com.canonical.Unity.Screen.overrideOrientation 0 2
[12:05] <greyback_> is the call I'm using.


[03:11] <dku> How can I run the mic input to the speakers automatically? (used to be in the volume control, but Lucid is different)
[03:38] <BartimusPrime> Hello!


[00:36] <OvenWerks> Eickmeyer: I was just grumpy that day... I may get over it ;)
[00:36] <Eickmeyer> heh
[03:41] <Eickmeyer> snd: Not sure if you saw this one, but new x42-plugins release on 06 July: http://gareus.org/misc/x42-plugins.php
[04:00] <OvenWerks> I saw some queries to the author I think.
[04:00] <OvenWerks> Eickmeyer: I will be back out at sea this coming week.
[04:01] <Eickmeyer> OvenWerks: Ok, good to know. RE: queries to the author, I can always query him in person in November.
[04:01] <Eickmeyer> Ross is coming, too.