[07:42] -queuebot:#ubuntu-release- New binary: r-cran-pammtools [amd64] (jammy-proposed/universe) [0.5.7-2] (no packageset)
[08:00] -queuebot:#ubuntu-release- New binary: git-autofixup [amd64] (jammy-proposed/universe) [0.003001-1] (no packageset)


[00:36] <niemeyer> hazmat: I don't follow
[00:36] <niemeyer> But have to step out to pick up Ale now
[00:36] <niemeyer> hazmat: Let's talk tomorrow
[02:18] <_mup_> ensemble/expose-provisioning r243 committed by<EMAIL_ADDRESS>[02:18] <_mup_> PEP8
[02:20] <_mup_> ensemble/expose-provisioning r244 committed by<EMAIL_ADDRESS>[02:20] <_mup_> More PEP8
[02:21] <_mup_> ensemble/expose-provisioning r245 committed by<EMAIL_ADDRESS>[02:21] <_mup_> Merge trunk and resolved conflicts
[02:30] <jimbaker> hazmat, it does seem like we are increasingly have random failures due to watches
[02:31] <hazmat> jimbaker, there not random
[02:31] <hazmat> they have causes, and tests need to account for it
[02:31] <hazmat> jimbaker, if your not clear on why its happening, do a self.capture_output()
[02:32] <jimbaker> sounds good. so what i'm seeing it is in mostly around cleanup. do you have any good suggestions for avoiding zookeeper.ClosingException: zookeeper is closing exceptions?
[02:32] <hazmat> jimbaker, they show up randomly in tests, but a broken test in this context, is pretty much always broken..
[02:32] <hazmat> jimbaker, it helps to understand which activities cause background operations that need to be synced
[02:32] <hazmat> jimbaker, lifecycle.start() is the primary offendor
[02:33] <hazmat> jimbaker, you can do a yield self.sleep(0.1) or do it early in your test if has any appreciable time.. or do a yield lifecycle.stop() before the end of the test
[02:33] <hazmat> jimbaker, it depends on the context
[02:34] <hazmat> jimbaker, on trunk i saw a particular test fail regularly from the endpoint stuff the slow watch callback
[02:34] <jimbaker> hazmat, so i'm setting this in a variety of tests: test_watch_exposed_flag_waits_on_slow_callbacks, iirc test_watch_relations_may_defer
[02:34] <hazmat> er.. not endpoint but exposed
[02:34] <jimbaker> hazmat, so we agree on that
[02:35] <jimbaker> hazmat, i have been adding sleeps to avoid, and it certainly helps
[02:35] <jimbaker> just not 100%
[02:36] <jimbaker> certainly it's much more likely with -u, that's a good way to see them
[02:36] <jimbaker> but if sleep is our best solution for stuff not involved in lifecycles... is that really a solution?
[02:38] <jimbaker> hazmat, seems like getting watches right would be very useful for next week
[02:40] <jimbaker> hazmat, the other thing is that my current testing of service exposing may have some similarity to the lifecycle testing because it asserts complete cleanup at the end of each test, which seems to be hard with the current watch setup
[02:42] <hazmat> jimbaker, there are lots of examples
[02:42] <hazmat> jimbaker, i agree
[02:43] <hazmat> jimbaker, its not really a solution, stopping the lifecycle also works, or waiting on a hook execution, it really depends on the context
[02:43] <jimbaker> hazmat, agreed on that
[02:44] <_mup_> ensemble/expose-dummy-provider r214 committed by<EMAIL_ADDRESS>[02:44] <_mup_> Merged trunk
[02:44] <hazmat> jimbaker, getting to niemeyer to understand took much longer than i thought.. i'll see if i can take care of it while we're in budapest, and we can clean up tests incrementally
[02:45] <jimbaker> hazmat, sounds like a good plan
[02:47] <_mup_> ensemble/expose-dummy-provider r215 committed by<EMAIL_ADDRESS>[02:47] <_mup_> Comments
[02:55] <_mup_> ensemble/expose-dummy-provider r216 committed by<EMAIL_ADDRESS>[02:55] <_mup_> Fix upstream changes
[02:56] <_mup_> ensemble/expose-provisioning r246 committed by<EMAIL_ADDRESS>[02:56] <_mup_> Merged trunk & resolved conflicts
[02:58] <_mup_> ensemble/expose-provisioning r247 committed by<EMAIL_ADDRESS>[02:58] <_mup_> PEP8
[03:08] <_mup_> ensemble/expose-provisioning r248 committed by<EMAIL_ADDRESS>[03:08] <_mup_> Cleanup
[03:39] <hazmat> jimbaker, where you able to fix the tests that failed on trunk in one of those branches?
[03:42] <jimbaker> hazmat, i was not
[03:42] <jimbaker> hazmat, i do know if i increase the sleep time, i see less failures
[03:42] <jimbaker> but having 2s sleep or whatever seems crazy
[03:43] <hazmat> jimbaker, a better way is to find out what the background activity is, and create a test helper that allows you to observe/sync on some post condition of the background activity
[03:44] <hazmat> jimbaker, what's it doing in the background in expose watch?
[03:44] <jimbaker> hazmat, i have a pretty careful record of the background activity in terms of the logging
[03:44] <jimbaker> in terms of removing service units for example, and how that cascades through
[03:45] <jimbaker> and as i mentioned, it is more than this new code, it seems common across watches
[03:45] <hazmat> jimbaker, try adding a yield callback at the bottom of watch_exposed_flag
[03:47] <jimbaker> hazmat, that only makes it worse it seems
[03:48] <hazmat> jimbaker, what branch?
[03:48] <hazmat> and what test?
[03:49] <jimbaker> lp:~jimbaker/ensemble/expose-provisioning, ensemble.agents.tests.test_provision
[03:51] <jimbaker> hazmat, taking off for now, but definitely appreciate if you find anything. thanks!
[03:52] <hazmat> jimbaker, cool have a good one, fwiw it helps to solve these problems in reverse, at the higher level you get multiple issues nesting, at the lower level you have some hope of sanity building on re-fortified substrates
[03:59] <_mup_> ensemble/auto-dependency-resolution r215 committed by<EMAIL_ADDRESS>[03:59] <_mup_> auto dependency resolver, solves for dependent formulas to be deployed (taking into account what's available in the environment), and new relations that need to be created.
[05:25] <_mup_> ensemble/config-get r213 committed by<EMAIL_ADDRESS>[05:25] <_mup_> test config_get communications w and w/o option_name
[05:30] <_mup_> ensemble/config-get r214 committed by<EMAIL_ADDRESS>[05:30] <_mup_> cleanup config_set testing method and related config_get->config test streamlining
[07:35] <_mup_> ensemble/config-get r215 committed by<EMAIL_ADDRESS>[07:35] <_mup_> test for name/service lookup functions on hook
[08:40] <_mup_> ensemble/config-get r216 committed by<EMAIL_ADDRESS>[08:40] <_mup_> prune unused method and exception
[08:45] <_mup_> ensemble/config-get r217 committed by<EMAIL_ADDRESS>[08:45] <_mup_> pep8
[09:00] <kim0> morning everyone
[13:37] <kim0> hmm the joined hook is still not in docs ? http://people.canonical.com/~niemeyer/ensemble/formula.html#hooks
[14:30] <hazmat> kim0, ugh.. it should be
[14:30] <hazmat> everyone's been been heads down implementing
[14:41] <hazmat> niemeyer, got a decent auto resolver implementation working
[14:45] <niemeyer> hazmat: Oh, sweet!
[14:46] <hazmat> niemeyer, there are some broken tests in trunk.. which concern me though
[14:47] <hazmat> ./test -u ensemble.state.tests.test_service.ServiceStateManagerTest.test_watch_exposed_flag_waits_on_slow_callbacks
[14:47] <hazmat> will end up hanging a terminal hard for me
[14:47] <hazmat> still looking
[14:47] <niemeyer> Huh
[14:48] <hazmat> hmmm.. actually most of the slow watch callbacks can do a hang
[15:00] <_mup_> ensemble/auto-dependency-resolution r216 committed by<EMAIL_ADDRESS>[15:00] <_mup_> test plan, better logging, return formulas objects instead of formula names.
[15:01] <hazmat> niemeyer, if your want to take have a look at auto resolve.. its pretty much contained to one file. http://bazaar.launchpad.net/~hazmat/ensemble/auto-dependency-resolution/view/head:/ensemble/formula/resolver.py
[15:09] <niemeyer> hazmat: Reading
[15:11] <niemeyer> hazmat: {
[15:11] <niemeyer> 111
[15:11] <niemeyer>             "required_by": [(formula_name, dep_name, service_name)],
[15:11] <niemeyer> 112
[15:11] <niemeyer>             "provided_by": None}
[15:12] <niemeyer> hazmat: This should be a proper type
[15:16] <hazmat> niemeyer, yeah.. there's a todo at the top
[15:16] <hazmat> to use named tuples for all the internal data structs
[15:16] <hazmat> niemeyer, its very much in an early state ;-)
[15:16] <niemeyer> hazmat: Yeah.. :)
[15:17] <niemeyer> hazmat: It looks pretty good
[15:17] <niemeyer> hazmat: As a hack :)
[15:17] <hazmat> its nice to remember what's its like
[15:17] <niemeyer> hazmat: Gives an idea of the kind of trouble we're getting into for the full blown implementation
[15:18] <hazmat> niemeyer, indeeds, its a very nice exercise for that.
[15:20] <niemeyer> hazmat: "depth" provides the wrong idea there
[15:20] <niemeyer> hazmat: This is generally used for recursive algorithms
[15:20] <hazmat> niemeyer, its tree depth for the resolution
[15:21] <hazmat> niemeyer, indeed.. most dep graph solving is done as a dag
[15:21] <niemeyer> hazmat: and it's going backwards
[15:22] <hazmat> niemeyer, how so?
[15:22] <niemeyer>         depth -= 1
[15:22] <niemeyer> :)
[15:23] <hazmat> niemeyer, yeah.. that should be cleaned up.. probably just fix the condition
[15:23] <hazmat> and the name
[15:24] <niemeyer> hazmat: Nice work man
[15:24] <niemeyer> hazmat: It's fantastic we'll have something like that in place for experimenting with
[15:25] <niemeyer> hazmat: Does it work? :-)
[15:25] <hazmat> niemeyer, indeed it will be fun to show
[15:25] <hazmat> niemeyer, i have no idea.. its anti-tdd ;-)
[15:25] <hazmat> tbd
[15:25] <niemeyer> hazmat: :-)
[15:26] <jimbaker> kim0, http://people.canonical.com/~niemeyer/ensemble/formula.html is not current against trunk
[15:26] <niemeyer> jimbaker: It's not?
[15:27] <jimbaker> niemeyer, it's not. the clue for me was seeing "monothonically", which while pythonic in sound, is not a word ;)
[15:28] <jimbaker> (i fixed that typo a while ago)
[15:29] <hazmat> yeah.. trunk is indeed different
[15:30] <hazmat> by like a several weeks it looks
[15:30] <kim0> This hasnt been merged http://bazaar.launchpad.net/~jimbaker/ensemble/sandbox-trunk-r200/revision/200
[15:31] <niemeyer> jimbaker: Oops.. :)
[15:31] <jimbaker> kim0, not certain what you mean by that... that's a sandbox
[15:31] <niemeyer> let me check that
[15:31] <kim0> mm .. then I'm misunderstanding
[15:32] <jimbaker> specifically i just needed something i could deploy on aws, and not knowing how to specify a revision in the bzr url, i just did it that way
[15:33] <jimbaker> kim0, i will delete it since we are no longer trying to figure out what happened when we could no longer deploy to aws
[15:33] <niemeyer> Hmm.. so the branch is up-to-date
[15:33] <niemeyer> Ugh.. the docs are clearly not
[15:34] <kim0> niemeyer: would be great if you'd merge my user docs branch too :)
[15:34] <niemeyer> kim0: Yeah, I plan to handle that today still
[15:34] <niemeyer> kim0: Thanks for the changes, btw
[15:34] <kim0> cool yw
[15:35] <kim0> writing a contributing your first formula doc now
[15:35] <kim0> is using 'echo' inside formulas an acceptable way to communicate info with user, or should ensemble-log almost always be used ?
[15:36] <kim0> coz principia templates use echo, if we don't like that, I'll change them all to ensemble-log
[15:43] <niemeyer> jimbaker, kim0: Updated
[15:43] <niemeyer> Should continue to update automatically now
[15:43] <niemeyer> I've changed it so that it kills the previous version, rather than trying to compile just the difference
[15:43] <niemeyer> I think something around that wasn't working properly
[15:47] <kim0> why do we have a broken relation, but not established
[15:58] <niemeyer> kim0: The best answer is that we haven't missed it
[15:58] <kim0> :)
[15:58] <kim0> that I'm sure of hehe
[15:58] <niemeyer> kim0: In the case of broken, there are obvious things we can do when the service goes disconnected that there's no other place to do
[15:59] <niemeyer> kim0: In the case of established, we have good alternatives, such as start
[15:59] <niemeyer> kim0: But there's no inherent reason why we shouldn't have it
[15:59] <kim0> ok makes sense
[15:59] <niemeyer> kim0: If someone comes up with "Oh, I'd like to have established to handle that specific use case."
[15:59] <niemeyer> kim0: We can easily add it
[15:59]  * kim0 nods
[16:00] <hazmat> there where handshaking difficulties as i recall, and some questions as to the meaning/utility of established without a join.
[16:00] <hazmat> ie. a one sided relation
[16:01] <hazmat> which join nesc. imparts its not, thus serving as a valid point of establishment for two services to communicate
[16:02] <hazmat> it can be added though
[16:10] <hazmat> trippy.. ensemble/mine/watching-godot$ make
[16:10] <hazmat> You've just watched the fastest build on earth.
[16:14] <niemeyer> :-)
[16:34] <hazmat> so gdb shows the hard lock in zk close, looks like something for upstream
[16:37] <niemeyer> Our docs have some issues building apparently..
[16:37] <niemeyer> Let me look at that
[16:37] <niemeyer> hazmat: Hm
[16:38] <niemeyer> hazmat: That brings me memories
[16:38] <niemeyer> hazmat: I think I've heard about a locked zk close somewhen
[16:56] <niemeyer> Argh
[16:57] <niemeyer> Sphinx is doing pretty weird things :(
[16:57] <niemeyer> It breaks a line with "control-bucket", but not one with "default-instance-type"
[17:01] <niemeyer> Ok, no warnings anymore
[17:01] <kim0> Our meeting kicking in 2 hours ..
[17:01]  * kim0 rings a little shiny bell
[17:03] <niemeyer> :)
[17:05]  * koolhead17 pokes kim0
[17:06] <kim0> koolhead17: hey o/
[17:06] <kim0> koolhead17: you've been hiding lately huh
[17:06] <koolhead17> kim0: howdy?
[17:07] <kim0> All going good
[17:07] <kim0> you all good ?
[17:07] <koolhead17> kim0: am awesome!!
[17:07] <kim0> great :)
[17:08] <koolhead17> just trying to not get distracted from real work during working hours in office :D
[17:09] <koolhead17> kim0: and yes working on increasing my launchpad karma!! :D
[17:09] <kim0> koolhead17: hehe
[17:09] <kim0> koolhead17: played with ensemble yet ?
[17:11] <koolhead17> kim0: am too occupied with some other stuff natty related. even after office hours. after hitting my head against dhcp server for 48 hours i filed a bug apparmor and stopping execution of dhcpd
[17:11] <kim0> hehe
[17:11] <kim0> bugs can sure be fun
[17:12] <koolhead17> kim0: yeah when you are deploying something new and you have no documentation supporting you :)
[17:12] <koolhead17> hi hazmat TeTeT niemeyer
[17:12] <kim0> what were you deploying
[17:12] <koolhead17> cobbler :P
[17:12] <kim0> a ha
[17:13] <kim0> koolhead17: did that include manual steps ?
[17:13] <koolhead17> well am half way mark, able to get PXE install via cobbler
[17:14]  * kim0 wondering if koolhead17 should wrap his knowledge into a cobbler ensemble formula :)
[17:14] <koolhead17> few things in default.ks are hardcoded so now have to bang against wall 2morrow figuring out if i have to manually setup local repo and rsync it
[17:14] <kim0> while cobbler is not really a cloud service, I can still see value
[17:15] <koolhead17> kim0: cobbler is for cloud 4 sure with koan :D
[17:15] <kim0> oh! cool :)
[17:15] <kim0> at least when openstack is a deploy target for ensemble, it should definitely make sense IMO
[17:15] <niemeyer> koolhead17: Hey!
[17:15] <niemeyer> hazmat: Any luck on the lockup problem?
[17:17] <koolhead17> kim0: you will be surprized. cobbler has awesome GUI interface for everything but still i simply followed the command line option :D
[17:17] <koolhead17> i found GUI too confusing :)
[17:18] <kim0> koolhead17: yeah I'm kinda like that as well .. gui is for sissies :)
[17:18] <koolhead17> hehe
[17:18] <koolhead17> thaks to "zul"  blog
[17:19] <koolhead17> *thanks
[17:19] <kim0> koolhead17: I've written a largish user level doc for ensemble .. check it out (all the green block text at the end) https://code.launchpad.net/~kim0/ensemble/user-tutorial-and-FAQ/+merge/58861
[17:19] <kim0> last time you wanted to get kickstarted I remember
[17:21] <koolhead17> kim0: yup
[17:22] <hazmat> niemeyer, no, got some lunch
[17:23] <koolhead17> kim0: are you going for that developer summit?
[17:23] <koolhead17> ubuntu
[17:25] <niemeyer> hazmat: Sounds like a good plan, actually
[17:25] <niemeyer> I'll get some food too
[17:32] <koolhead17> kim0: will be back on this documentation in few hours need to learn some "expect" scripting
[17:41] <kim0> koolhead17: yeah I'm going .. should meet Murthy
[17:42] <koolhead17> that be great!!
[17:43] <niemeyer> Ok, actually leaving for lunch now
[17:48] <hazmat> interesting virtualenv seems to strip debugging symbols
[19:00] <jimbaker> meeting in #ubuntu-cloud
[19:00] <jimbaker> kim0, i assume we are kicking off now, right?
[19:01] <kim0> yep
[19:06] <niemeyer> hazmat: Do you have a moment for a chat?
[19:13] <hazmat> niemeyer, sure
[19:13] <niemeyer> Skype or mumble?
[19:13] <jimbaker> bcsaller, do you want to join the weekly cloud meeting at #ubuntu-cloud ?
[19:14] <jimbaker> just brought you up
[19:14] <hazmat> niemeyer, skype
[19:15] <niemeyer> hazmat: Ok
[19:17] <niemeyer> hazmat:
[19:17] <niemeyer> +    def do_retry_start(self, fire_hooks=True):
[19:17] <niemeyer> +        return self._invoke_lifecycle(
[19:17] <niemeyer> +            self._lifecycle.start, fire_hooks=fire_hooks)
[19:30] <hazmat> bcsaller, jimbaker standup?
[19:30] <jimbaker> hazmat, i was just about to ask the same thing
[19:30] <jimbaker> let me start up skype
[19:31] <bcsaller> sure
[19:46] <niemeyer> jimbaker: map["open"].append({"port": ...})
[19:46] <niemeyer> jimbaker: ?
[19:52] <niemeyer> jimbaker:
[19:52] <niemeyer> def expose_port(content, ...):
[19:52] <niemeyer>     data = yaml.loads(content)
[19:52] <niemeyer>     if not data:
[19:52] <niemeyer>         data = {"open": []}
[19:52] <niemeyer>     if port not in data["open"]:
[19:52] <niemeyer>         data["open"].append(port)
[19:52] <niemeyer>     return yaml.dumps(data)
[19:54] <niemeyer> jimbaker: the beginning of that should handle empty content as well
[19:54] <niemeyer> jimbaker: data = content and yaml.loads(content)
[19:54] <niemeyer> jimbaker: That should handle it
[19:55] <_mup_> ensemble/watching-godot r216 committed by<EMAIL_ADDRESS>[19:55] <_mup_> reliable slow watch testing
[20:03] <_mup_> ensemble/config-get r218 committed by<EMAIL_ADDRESS>[20:03] <_mup_> docstring cleanups
[20:05] <_mup_> ensemble/config-set r215 committed by<EMAIL_ADDRESS>[20:05] <_mup_> resolve merge
[20:11] <niemeyer> hazmat: I've added only that single item we discussed to the review of unit-agent-resolved
[20:12] <niemeyer> hazmat: It turned out that all of the other issues I had (untested paths, docs missing) are likely going to be rendered irrelevant if you change that
[20:30] <niemeyer> bcsaller: Is config-get up for review again, or did I forget to move it to WIP?
[20:31] <bcsaller> gustavo: its up again, the changes should be pushed
[20:32] <niemeyer> bcsaller: Cool, thanks
[20:41] <_mup_> ensemble/unit-agent-resolved r270 committed by<EMAIL_ADDRESS>[20:41] <_mup_> remove passing action transition/state variables
[20:44] <niemeyer> "Your trip to Budapest, Hungary is about to begin"
[20:44] <niemeyer> TripIt is slightly nervous about trips I see
[20:47] <_mup_> ensemble/service-config-unit-lifecycle r217 committed by<EMAIL_ADDRESS>[20:47] <_mup_> fix up todo comments for post resolved merge work
[20:53] <hazmat> so we need a newer version of txaws then is in natty it appears..
[20:53] <hazmat> oh.. nm
[20:57] <niemeyer> bcsaller: There are still missing tests in config-get
[20:57] <niemeyer> bcsaller: E.g.
[20:57] <niemeyer> +    def get_formula_state(self):
[20:58] <niemeyer> bcsaller: TDD would be very helpful in avoiding that kind of problem
[20:59] <bcsaller> yeah, I wrote the tests for the higher levels and then filled in methods to make them pass, I must not have filled in the missing. In reviewing the patch pre-push I didn't even notice though
[21:04] <niemeyer> bcsaller: That's not quite TDD
[21:05] <niemeyer> bcsaller: TDD is fine-grained.. you have to write several public methods to make a single test pass, the test is probably not fine-grained enough
[21:06] <bcsaller> good advise
[21:06] <niemeyer> bcsaller: Whenever you're writing something, and you figure you need support in another area of the application, that other area should *also* be done with TDD
[21:07] <niemeyer> bcsaller: Then, before pushing it for review, it's generally good practice to be the reviewer of your own code
[21:07] <niemeyer> bcsaller: Actively looking for leftovers, untested areas, etc
[21:07] <niemeyer> bcsaller: +        config_state = yield self._setup_config_state()
[21:07] <niemeyer> +        yield config_state.write()
[21:07] <niemeyer> bcsaller: Untested as well
[21:14] <_mup_> ensemble/trunk r217 committed by<EMAIL_ADDRESS>[21:14] <_mup_> merge service-config-unit-lifecycle [r=niemeyer][f=776596]
[21:14] <_mup_> unit lifecycle and workflow work to enable config-changed hooks.
[21:15] <niemeyer> bcsaller: config-get reviewed.
[21:16] <bcsaller> thanks, I'll look for those places and test them
[21:19] <niemeyer> Quick break
[21:41] <_mup_> ensemble/watching-godot r217 committed by<EMAIL_ADDRESS>[21:41] <_mup_> revert changes to watch expose to yield to the first invocation, just fix the tests.
[21:41] <koolhead17> kim0: ping
[21:43] <_mup_> Bug #777421 was filed: slow watch tests are unreliable <Ensemble:New> < https://launchpad.net/bugs/777421 >
[21:45] <hazmat> jimbaker, niemeyer a small branch fix for slow watcher trunk tests is available
[21:45] <niemeyer> hazmat: Super!
[21:45] <hazmat> it was probably a trivial
[21:48] <jimbaker>  hazmat, good to hear
[21:51] <niemeyer> Time for a haircut
[21:53] <_mup_> ensemble/unit-agent-resolved r271 committed by<EMAIL_ADDRESS>[21:53] <_mup_> separate transitions for retry with hook
[21:54] <jimbaker> niemeyer, now i recall more fully why we want this to be a YAMLState for open ports (and why it will take more time)
[21:55] <jimbaker> the problem is that we want open-port/close-port to participate in the same flush as the overall HookContext
[21:56] <jimbaker> this way we can ensure that hooks that open/close ports have all-or-nothing semantics corresponding to their exit status code
[21:58] <_mup_> ensemble/unit-agent-resolved r272 committed by<EMAIL_ADDRESS>[21:58] <_mup_> merge trunk resolve conflict.
[22:00] <jimbaker> hazmat, funny, re bug 777421, i was curious about the whole poke_zk and whether that would be useful or not. not, i guess.
[22:00] <_mup_> Bug #777421: slow watch tests are unreliable <Ensemble:In Progress by hazmat> < https://launchpad.net/bugs/777421 >
[22:03] <_mup_> ensemble/trunk r218 committed by<EMAIL_ADDRESS>[22:03] <_mup_> merge watching-godo [r=niemeyer][f=777421]
[22:03] <_mup_> trivial fix to slow watch callback tests of the service unit api in order
[22:03] <_mup_> to reliably run when looped.
[22:07] <_mup_> ensemble/trunk-merge r190 committed by<EMAIL_ADDRESS>[22:07] <_mup_> merge trunk
[22:07] <_mup_> ensemble/resolved-state-api r203 committed by<EMAIL_ADDRESS>[22:07] <_mup_> merge trunk conflict
[22:11] <_mup_> ensemble/unit-agent-resolved r273 committed by<EMAIL_ADDRESS>[22:11] <_mup_> resolve merge conflict
[22:27] <bcsaller> short break
[22:53] <_mup_> ensemble/unit-agent-resolved r274 committed by<EMAIL_ADDRESS>[22:53] <_mup_> expand out additional recovery transition actions
[23:07] <_mup_> ensemble/expose-provisioning r249 committed by<EMAIL_ADDRESS>[23:07] <_mup_> Do not observe private state directly in tests and fix bad yield
[23:08] <_mup_> ensemble/expose-provisioning r250 committed by<EMAIL_ADDRESS>[23:08] <_mup_> Merged trunk
[23:12] <jimbaker> hazmat, when is poke_zk still appropriate, given that it is still in the tests? certainly it looks innocuous
[23:12] <hazmat> jimbaker, when a round trip to zk is all that's needed to process callbacks, if you have long  running background activity it won't be
[23:13] <jimbaker> ok, so for ordinary watches, poke_zk is fine, just the specific slow watches cause problems here
[23:13] <hazmat> ie. using principles of global ordering, we know that there shouldn't be any additional activity.. it might be useful to extend that to a more convoluted poke (watch/set/callback)
[23:14] <hazmat> jimbaker, pretty much, but if the watch callback is doing additional zk interaction its dicey
[23:14] <hazmat> if its a test contructed callback, its generally fine
[23:14] <jimbaker> hazmat, ahh, that certainly limits applicability in my recent work, good way to think about it
[23:20] <jimbaker> cool, applicable in only one case in my expose-provisioning branch, but that does help
[23:21] <_mup_> ensemble/expose-provisioning r251 committed by<EMAIL_ADDRESS>[23:21] <_mup_> Sleep instead of poke for slow watch on openeded ports test
[23:50] <_mup_> ensemble/expose-provisioning r252 committed by<EMAIL_ADDRESS>[23:50] <_mup_> Sleep adjustment fu


[04:02] <tiwake> Ardonel: moving to texas probably the 2nd or 4rd or so
[04:03] <tiwake> erm
[04:03] <tiwake> 3rd rather
[04:03] <tiwake> first week of Aug.
[15:13] <Ardonel> tiwake: where to in Texas?
[15:15] <tiwake> lubbock
[15:15] <tiwake> working here http://www.lubbockelectric.com/
[15:16] <tiwake> I don't have a house/room nailed down yet, but there seems to be lots of options because college town
[15:28] <tiwake> Ardonel: I think it will be a lot of fun
[15:29] <Ardonel> cool


[11:26] <learning-linux> xubuntu on VM
[11:26] <learning-linux> yes i am using it on a VM right now
[11:28] <learning-linux> XfceUbuntu should be the complete name :thinking:
[11:29] <pmjdebruijn> ?
[11:29] <pmjdebruijn> overly long names really generally don't help
[11:29] <pmjdebruijn> so xubuntu is fine
[11:29] <pmjdebruijn> but indeed xubuntu will work fine on most VMs
[11:30] <learning-linux> well yeah
[11:30] <pmjdebruijn> but that's true of most linux distros
[11:30] <learning-linux> the old style can help a lot if you want to run it on a VM
[11:31] <pmjdebruijn> the only thing that often doesn't work in VMs is 3D Accel, which slows down some desktops, but even then it's usually managable
[11:31] <learning-linux> but linux noobs can think "oh Xubuntu has an old syle desktop so is very old as distro"
[11:32] <pmjdebruijn> doubtful
[11:32] <learning-linux> well lubuntu can work faster too
[11:33] <pmjdebruijn> possibly, to each his own
[11:33] <pmjdebruijn> at least for me xubuntu seems to  be the perfect middle ground
[11:33] <learning-linux> yeah, is also very simple
[13:01] <diogenes_> Hello guys, after installing Xubuntu 18.04 i encountered extremely low internet speed, it was literally couple B/s, not even KB/s, and it turns out the problem was systemd-resolved, even man systemd-resolved suggest that: "it is strongly recommended that local programs use the glibc NSS", so the issues was fixed by adding resolve to sswitch.conf. That's why i'd suggest that further releases to include this fix out of the
[13:01] <diogenes_> box, otherwise other users might encounter the same issue.
[20:11] <xubuntu09i> Supported computer some megacorp decides to release a patch that freezes the computer. Their solution buy a new computer. So clueless. Xubuntu just works! :)
[20:15] <diogenes_> xubuntu always works


[00:40] <RAOF> Grr. Do mir_demo_client* work for anyone else on the current staging PPA?
[00:42] <RAOF> They all fail for me in assert(mir_surface_is_valid()), and XMir also dies with a garbage MirBufferPackage
[00:49] <bryce> RAOF, I updated to the latest staging ppa on my intel box last Friday, but the screen was just static noise
[00:51] <bschaefer> RAOF, yeah, im getting the same thing :(
[00:52] <bschaefer> was working just before I pulled some new changes to lp:mir
[00:56] <bschaefer> RAOF, looks like rev 590 caused the issue for me
[00:57]  * kdub just merged lp:mir onto my working branch, looks like i see the same thing on android
[00:57] <kdub> i'll try to confirm the rev590...
[01:01] <kdub> bschaefer,  yep... something happened in 590
[01:02] <bschaefer> kdub, its a large branch soo hopefully it'll be easy to track down
[01:03] <racarr> RAOF: Err.  so I had garbage mir buffer package
[01:03] <racarr> but then I built mesa with usa-dma-buf which you still didn't merge to the main github branch
[01:03] <racarr> and it worked fine
[01:04] <racarr> oh 590
[01:04] <RAOF> I actually reverse-merged that (ie: merged egl-platform-mir into -use-dma-buf), and the mesa packages in the PPA aren't built out of either of those branches anyway.
[01:05] <racarr> RAOF: New theory...something crazy due to a bug
[01:05] <racarr> try with --enable-input=true
[01:05] <racarr> the_input_focus_selector needs to
[01:05] <racarr> check the options and ahve a null implementaiton
[01:05] <racarr> like the input manager does
[01:05] <racarr> trunk right now with --enable-input=false (the default) is starting up a malformed input stack
[01:05] <racarr> and who knows what happens
[01:05] <racarr> um.
[01:06] <racarr> I'll propose a branch to fix it soon. I actually need to run and do some errands though
[01:07] <RAOF> racarr: Correct guess!
[01:07] <kdub> ok, trunk with --enable-input=true works for me too
[01:07] <racarr> ok
[01:07] <racarr> sorry about that
[01:07] <kdub> let's set the topic until its changed
[01:07] <racarr> I don't remember how to get my +o back
[01:07] <racarr> but! I really do want to run some errands because I need to be somewhere by 7
[01:08] <racarr> ill be back later though, and even later for team meeting :)
[01:08] <racarr> Cheers!
[01:09] <kdub> well, until the proper fix for --enable-input=false is in
[01:10] <kdub> let's change the default
[01:10] <kdub> https://code.launchpad.net/~kdub/mir/server-startup-bandaid/+merge/159270
[01:11] <kdub> bandaid branch^^
[01:13] <bschaefer> kdub, I can approve that for you, if you don't mind
[01:14] <kdub> bschaefer, sure
[01:14]  * bschaefer isn't sure what the procedure for MPs are in lp:mir
[01:14] <bschaefer> approved
[01:14] <kdub> bschaefer, one reviewer +1, plus no blocking comments
[01:15] <bschaefer> kdub, sounds about normal :)
[01:16] <kdub> bug report: https://bugs.launchpad.net/mir/+bug/1169781
[01:22] <kdub> someone with ops set the /topic to mention to run with --enable-input=true in the meantime?
[01:39] <duflu> kdub: I always assumed it was 2+ reviewers?
[01:40] <duflu> No wonder my proposals linger :)
[01:55] <racarr> I think its understood as +2 for nontrivial proposals
[01:55] <racarr> but that's just how I have been thinking
[01:58] <duflu> Yeah, trivial or time-critical stuff would be only 1
[01:58] <duflu> time-critical means when something is broken and it's holding us up
[02:05] <racarr> https://code.launchpad.net/~robertcarr/mir/fix-disabled-input/+merge/159277
[02:05] <racarr> exists
[02:32] <RAOF> racarr: Code looks fine; checking that it actually works, too :)
[02:44] <robert_ancell> "Internal compiler error: Error reporting routines re-entered."
[02:44] <robert_ancell> seriously GCC?
[02:45] <duflu> Error during reporting of the first error? Nice
[02:58] <smspillaz> robert_ancell: std::make_shared ?
[02:59] <robert_ancell> smspillaz, it looks like it. I'm trying to reduce the program to create a test case
[02:59] <smspillaz> robert_ancell: known bug
[02:59] <smspillaz> https://bugs.launchpad.net/ubuntu/+source/gcc-4.7/+bug/1165732
[03:00] <smspillaz> robert_ancell: if you have a class that would fail to have its constructor compiled (eg, because it was private or had pure virtual methods) then gcc freaks out when you get that inside of a template
[03:00] <robert_ancell> smspillaz, ah
[03:00] <smspillaz> robert_ancell: we should probably put that in the channel topic, I've seen four different people hit it and then start to write testcases :)
[03:00] <robert_ancell> ha!
[03:01] <RAOF> And, of course, the solution is to build with clang, which provides non-terrible error messages. :)
[03:01] <smspillaz> speaking of clang
[03:01] <smspillaz> duflu: needed to ask you something
[03:01] <smspillaz> duflu: remember when we made the templates extern for compiz plugins?
[03:02] <smspillaz> (eg PluginClassHandler, WrapableInterface etc)
[03:03] <racarr> RAOF: Thanks :)
[03:03] <racarr> robert_ancell: It's a known bug I believe that is fixed upstream according to some mailing list post I read or something
[03:03] <robert_ancell> racarr, yeah, the bug trail shows its a regression that's been fixed
[03:03] <RAOF> It's a regression from 4.6, and it's fixed in 4.8 apparently.
[03:04] <duflu> smspillaz: Yeah I remember
[03:04] <smspillaz> for some reason (dunno why yet) if you have liba.so which is linked to libb.so, both of them are not in the system library path, liba.so has a template definition that libb.so needs, if you dlopen libb.so but not liba.so it doesn't pull in the template
[03:04] <duflu> (sorry, am outside occasionally talking to painter)
[03:04] <smspillaz> no problem :)
[03:04] <smspillaz> duflu: any ideas ?
[03:04] <smspillaz> nm -S says its defined as "W" in liba.so
[03:05] <smspillaz> and U in libb.so
[03:05] <duflu> smspillaz: Yeah (W)eak symbol
[03:05] <smspillaz> cool, so what do I do in order to get a definition in libb.so ?
[03:05] <duflu> I don't follow the problem yet
[03:05] <duflu> Hang on
[03:06] <smspillaz> I'll try and write a simple testcase
[03:06] <smspillaz> (this is just my understanding of the problem by looking at compiz plugins)
[03:07] <smspillaz> ohhhh hmm
[03:07] <smspillaz> I wonder if the weak symbol is a template that never got defined
[03:07] <smspillaz> just declared as "yeah this exists"
[03:07] <duflu> smspillaz: I see. Yes. You don't want to accidentally pull in symbols from indirect libraries, for safety. I don't know how you would even if you wanted to.
[03:07] <smspillaz> and then the actual definition is some other symbol
[03:07] <duflu> (W)eak means defined, but can be rebound at runtime
[03:09] <duflu> smspillaz: Your problem might be less obvious. Only an explicit instantiation will create all methods for the class. Otherwise the default is to only create what you used the first time. External users might depend on some methods that do not exist
[03:09] <smspillaz> duflu: well, in this case they're directly linked
[03:10] <smspillaz> duflu: well, I don't know if its that. If for example, I dlopen both liba.so and libb.so then libb.so gets the definition
[03:11] <smspillaz> but its perplexing, because libb.so is definitely linked to liba.so, its just in a custom rpath (eg $prefix/lib/compiz)
[03:11] <duflu> smspillaz: Dependencies only go one way. If A links to (depends on) B, then dlopen(B) will indeed be missing everything that A provides
[03:11] <smspillaz> duflu: ah, sorry, B is linked to A
[03:12] <duflu> smspillaz: Yeah you need dlopen flag RTLD_GLOBAL (default is RTLD_LOCAL for safety)
[03:12] <duflu> You're usually meant to dlsym functions you need and not implicitly gain symbols from plugins loaded
[03:13] <smspillaz> duflu: hmm, what do you mean by "implicitly gain symbols from plugins loadeD"
[03:13] <smspillaz> *loaded
[03:14] <duflu> smspillaz: I recommend putting common template instantiations in a separate library, or duplicating them safely with -Bsymbolic
[03:14] <smspillaz> duflu: I was going to suggest that
[03:14] <duflu> smspillaz: Default is RTLD_LOCAL so you gain NO symbols from the load, unless you grab them explicitly (dlsym())
[03:15] <smspillaz> duflu: so you'd suggest a libcompiz_opengl_interface.so in the $prefix/lib ?
[03:15] <duflu> RTLD_GLOBAL however means you get all symbols from the loaded library, which might be used in a later dlopen
[03:16] <smspillaz> duflu: I don't think the problem is that I'm trying to get symbols from a library that I've opened and have not dlsym'd yet, rather its getting symbols from a another library that the library I'm dlopening is linked to
[03:16] <smspillaz> (though maybe that's what you're referring to)
[03:16] <duflu> smspillaz: The big risk is: Load plugin A, load plugin B, unload plugin A. You could have B accidentally bound to symbols (no longer addressible)
[03:16] <duflu> .. bound to symbols from the unloaded A
[03:17] <smspillaz> duflu: I don't see why that would arise if B was linked explicitly to A
[03:17] <duflu> smspillaz: Because the dynamic loader only allows one copy of each symbol name. If one already exists from an earlier plugin then the later plugin binds to that copy
[03:18] <duflu> So you either need a universally unique library for common symbols, or build with -Bsymbolic to tell the dynamic loader that each plugin should get private copies
[03:18] <smspillaz> oh I see, so we initially get the symbols from loading A, then B, which is linked to A doesn't bring the symbols in, then A gets unloaded and the symbols are gone
[03:19] <smspillaz> duflu: iirc we had some trouble with -Bsymbolic. I'll try the separate library approach
[03:20] <duflu> smspillaz: -Bsymbolic is _only_ a problem if your classes have static members which are unsafe to have multiple copies of
[03:21] <duflu> It also causes code bloat, but maybe not so bad
[03:21] <duflu> smspillaz: On the other hand, explicit instantiation in a separate library means you instantiate all methods (most of which you never use). And that can cause worse code bloat
[03:22] <smspillaz> duflu: well, we definitely use all the methods
[03:22] <duflu> That's OK if it's your own template (not from the STL)
[03:23] <smspillaz> yep, its our own template
[03:27] <smspillaz> duflu: okay, I think I'll go with that then.
[03:27] <duflu> smspillaz: If it's all opengl-specific then you don't need a new library. Just instantiate it in the opengl plugin
[03:27] <smspillaz> been trying to fix this long-standing issue where loading plugins effectively causes other plugins to be implicitly loaded
[03:27] <smspillaz> duflu: well, see that's the thing. we do instantiate it in the opengl plugin
[03:27] <smspillaz> (or at least I think we do)
[03:28] <duflu> And remember to "extern" the template in public headers
[03:28] <duflu> Or else you'll have more copies
[03:28] <smspillaz> duflu: yeah, its already extern'd
[03:29] <duflu> smspillaz: I think implicit loading on dependent plugins is a good thing. You shouldn't have to know what A depends on if all you want to load is A
[03:29] <smspillaz> duflu: the problem is optional dependencies
[03:29] <duflu> Oh, the optional ones
[03:29] <smspillaz> eg, I need to be able to set up a test framework so that we load move, but move doesn't pull in opengl
[03:30] <smspillaz> but move implicitly does that because it checks if opengl is available
[03:30] <smspillaz> ... by pulling in opengl
[03:30] <smspillaz> which then causes opengl to be loaded
[03:30] <smspillaz> again implicitly
[03:30] <smspillaz> its a bit nasty
[03:30] <duflu> I would like to say it should be a simple flag in a simple loading call: CompizLoadPlugin(foo, NO_OPTIONALS)
[03:30] <duflu> But I remember it's not the simple
[03:31] <smspillaz> duflu: well, the way it works at the moment is that it calls PluginClassHandler <GLWindow, CompWindow>::get ()
[03:31] <smspillaz> which *should* go to the vtable and then return null if it isn't loaded
[03:31] <duflu> Arg. I'm having terrible flashbacks
[03:32] <smspillaz> except that I fixed a problem several years ago which had the side effect of short-circuiting that
[03:32] <smspillaz> haha
[03:32] <smspillaz> anyways, maybe the problem is that we never really explicitly instantiated that template anywhere in opengl
[03:33] <duflu> In an ideal world, a plugin system should start with simple C functions which you look up by dysym. And then pretty quickly when all succeeds you can get a pointer/reference to higher-level objects
[03:33] <duflu> *dlsym
[03:33] <smspillaz> duflu: that's basically how it works right now
[03:33] <smspillaz> (or at least, that's the entry point from core)
[03:37] <duflu> Interesting trivia on the subject of bloat from template instantiation... quite often it is the symbol name itself that wastes the most space. Not the code. It's not uncommon for mangled template names to be hundreds of characters long.
[03:38] <duflu> Made worse by overuse of namespaces and default parameters like allocators
[03:46] <smspillaz> duflu: heh
[03:46] <smspillaz> _ZN5boost7variantIbifSsNS_17recursive_wrapperISt6vectorItSaItEEEENS1_I10CompActionEENS1_I9CompMatchEENS1_IS2_IN10CompOption5ValueESaISB_EEEENS_6detail7variant5void_ESH_SH_SH_SH_SH_SH_SH_SH_SH_SH_SH_E8assigner11assign_implIS5_EEvRKT_N4mpl_5bool_ILb0EEESQ_NSP_ILb1EEE.isra.230
[03:46] <smspillaz> case in point
[03:47] <racarr> smspillaz: How did you guess my password
[03:47] <smspillaz> oh crap
[03:47] <duflu> Yes, and for some reason compilers need to emit that string _many_ times in a single object
[03:47] <smspillaz> I've been found out
[03:47] <smspillaz> racarr: ahaha, that'd be awesome "my password is a mangled template symbol"
[03:48] <smspillaz> -EUNGUESSABLE
[03:48]  * duflu wonders what _SH_SH_SH_SH translates to
[03:49] <smspillaz> the compiler freaking out
[03:50] <smspillaz> duflu: I feel like lots of these problems could be solved by having a binary format specifically designed to handle C++
[03:50] <smspillaz> like, for once, being able to have aliases for template parameters
[03:50] <duflu> smspillaz: Kinda. It still needs to be copy and pasteable sometimes
[03:51] <smspillaz> like 43d452 = int, string, char, bool
[03:51]  * smspillaz notes that the majority of C++'s problems come from trying to be bolted on top of a C-like infrastructure
[03:52] <smspillaz> the solution is clearly to abolish C *waits for pitchforks to arrive at door*
[03:52] <duflu> More generally a lot of problems would be solved by well-defined symbol/linkage rules in the language definition. Some languages do that
[03:53] <smspillaz> you mean Go, right ? :p
[03:54] <duflu> Java, mostly
[03:54] <duflu> And probably Go
[03:55] <racarr> I heard all the cool kids were using rust last week
[03:56] <smspillaz> duflu: so I'm still wondering, even if I explicitly instantiate the template in liba, have it declared extern, then link libb to liba, I don't get the definition on dlopening libb
[03:57] <duflu> smspillaz: You may not "get the symbol" if it wasn't already in use at run-time before the dlopen
[03:57] <duflu> Hmm
[03:58] <duflu> smspillaz: As always, link with -zdefs (CFLAG -Wl,-zdefs) to tell you what you've forgotten at build time
[03:59] <duflu> Things will be clearer if the linker is giving you errors and no binary
[04:17] <smspillaz> duflu: doesn't seem to be complaining :/
[04:18] <duflu> smspillaz: That's extra weird. It means the linker has found all symbols resolved at build time. And yet some are missing at run time?
[04:18] <smspillaz> yeah
[04:18] <smspillaz> duflu: also I wrote a testcase without rpath and it works fine
[04:18] <duflu> smspillaz: Whatever is missing symbols needs to be linked with -zdefs
[04:18] <smspillaz> I'm going to try "installing" the testcase and installing the plugins somewhere unconventional
[04:18] <smspillaz> so that we'll have to use rpath
[04:25] <smspillaz> curious, that works the way you'd expect too
[04:33] <robert_ancell> racarr, around?
[04:37] <duflu> smspillaz: Remember make install with CMake actually strips rpaths :P
[04:37] <smspillaz> I know, I'm asking it not to in the testcase :)
[04:38] <smspillaz> though I still can't reproduce this problem :(
[04:38] <smspillaz> and there's nothing in the link flags that stands out
[05:02] <racarr> robert_ancell: Halfway
[05:02] <racarr> will be around and focused at meeting time :)
[05:02] <racarr> around but surrounded by noise atm
[05:44] <robert_ancell> argh, we have shell sessions and frontend sessions. Very confusing
[05:49] <robert_ancell> racarr, should SessionContainer contain shell:Sessions not frontend::Sessions?
[05:49] <robert_ancell> I need to focus a session by name for the system compositor (removing the hacky lightdm code) but it seems really hard to iterate over the current shell sessions
[05:50] <robert_ancell> racarr, and SessionContainer has virtual methods for insert and remove, but it's a concrete class - what is the point of the virtual methods?
[06:00] <racarr> robert_ancell: Yes it should contain shell::Sessions I think
[06:00] <racarr> it's a little difficult to do without dynamic casts somewhere :) there is one now...it could move and you could have shell::Sessions everywhere
[06:00] <racarr> I think the point of the virtual methods is for mocking
[06:03] <robert_ancell> duflu, alf_, meeting
[06:38] <smspillaz> duflu: ah frick, I think I've found the problem
[06:39] <duflu> smspillaz: OTP
[06:39] <smspillaz> np
[06:39] <smspillaz> its being linked to the wrong library, rpath madness it seems
[06:39] <smspillaz> fixable
[06:39] <smspillaz> \o/
[06:42] <duflu> kdub: Done now?... [kdub] transition android build to raring: TODO
[06:42] <duflu> Oh, no kdub
[06:43] <kdub> in progress
[06:43] <duflu> smspillaz: Cool. A simple answer
[06:44] <smspillaz> duflu: though its scary. for some reason if you build with rpaths cmake will put $prefix/lib into your rpath as well as any INSTALL_RPATH hint you add
[06:45] <smspillaz> and considering the plugin names are quite generic, there's a real risk of accidentally pulling in a library we didn't intend to
[06:45] <smspillaz> anyways, -EWRONGCHAN :p
[06:51] <RAOF> Wheee! We should run the glmark2-mir benchmarks on my radeon system - it's happy to do 10FPS on the terrain bench, for example :)
[06:53] <duflu> RAOF: Yeah that's the only one I got less than 60 FPS. Twas 59
[06:54] <RAOF> The trick is asking a 2-gen-old low-power card to render at 1920x1200 :)
[07:08] <RAOF> Woot! I win the "it-doesn't-work-if-you-try-and-dereference-an-fd-as-a-pointer" award!
[07:18] <mlankhorst> :X
[07:19] <duflu> tvoss: mir_connection_create_surface ? mir_create_surface? mir_connection_createsurface :)
[07:19] <tvoss> RAOF, \o/
[07:19] <tvoss> duflu, put my vote in for mir_connection_create_surface
[07:19] <tvoss> duflu, it's verbose but clear
[07:19] <duflu> I thought as much
[07:20] <RAOF> In my defence, passing fds as "void *handle" is unnecessarily obscure.
[07:20] <duflu> I'm trying to think if there are any single verbs to describe a surface being created :)
[07:20] <tvoss> RAOF, it forces the API user to really know what's going on ... which might be considered a good thing
[07:21] <alf_> RAOF: which branch from mesa-mir (github) is the latest? egl-platform-mir-use-dma-buf ?
[07:21] <tvoss> duflu, genesis ... not a verb, but shiny nevertheless :)
[07:21] <RAOF> alf_: Yes. The PPA is built from mir-ppa on github, though.
[07:22] <duflu> tvoss: Yeah you catch my drift
[07:22] <alf_> RAOF: hmm, I think egl-platform-mir-use-dma-buf is missing a commit (the last from branch egl-platform-mir)
[07:24] <RAOF> alf_: Quite true; you'll find them there now.
[07:24] <alf_> RAOF: excellent, thanks!
[08:31] <alan_g> tvoss: I was wondering if the guidelines you adopted from mir were online and came across something subtly different: http://unity.ubuntu.com/wp-content/uploads/2012/03/cppguide.html - is there a plan for convergence?
[08:31]  * alf_ notices that the input components in mir are very chatty...
[08:35] <tvoss> alan_g, those are the old ones, good catch
[08:35] <tvoss> alan_g, will check how to update those guidelines
[08:38] <alan_g> tvoss: you're welcome. (I followed a link from https://wiki.ubuntu.com/Unity/CodingStyle which might also need maintenance)
[08:44] <alf_> duflu: alan_g: tvoss: Any objection to changing mir_socket to be 777, so that other users can connect?
[08:44] <duflu> alf_: I was thinking that. It would be useful now, but creates security problems later
[08:45] <alf_> duflu: what security problems?
[08:45] <tvoss> alf_, fine with me
[08:45] <duflu> alf_: Any remotely logged in user can start a client and it renders on your desktop
[08:45] <duflu> ... or any daemon (non-root) can spawn surfaces on your desktop
[08:46] <alf_> duflu: hmm...
[08:46] <duflu> alf_: And later... any daemon could screen-scrape (if clients are given such power in future)
[08:48] <alan_g> alf_: Is this something that would need to differ between session and system compositing?
[08:48] <duflu> alf_: Looks like the Ubuntu/Linux approach is to limit access to group "video" which I suspect you become a member of on login (?)
[08:48] <alan_g> I.e. should it be configurable?
[08:48] <duflu> alan_g: Probably configurable eventually. But right now we just don't want any gaping security holes to forget about
[08:49] <alf_> duflu: the "video" approach is sensible
[08:50] <duflu> alf_: Seems to be how /dev/dri/* works
[08:52] <alf_> alan_g: we probably want only the user owning a session to be able to render to it, whereas the system compositor needs to accept connections from various users (from their session compositor)
[08:52] <alan_g> alf_: so "video" makes sense for system compositing, what we have now for session?
[08:53] <alf_> alan_g: that sounds right
[08:53] <alf_> duflu: do you get video permissions only when you log in locally?
[08:53] <duflu> alf_: Hmm, actually I'm not in group video. That might not work
[08:54]  * duflu looks at X
[08:55] <alf_> alan_g: duflu: perhaps we should just ask the security team or the X team, I am sure they have this figured out
[08:55] <alan_g> alf_: adding oneself to "video" was a hack you gave me to get mir working in the early days. It isn't a default.
[08:56] <alf_> alan_g: right
[08:56] <duflu> alf_: X seems to chmod 777 and implements its own security...
[08:56] <duflu> srwxrwxrwx 1 root root 0 Apr 16 09:04 /tmp/.X11-unix/X0
[08:56] <alf_> duflu: right, with xhosts etc
[08:57] <duflu> Yep
[08:57] <duflu> That's annoying. I was sure some groups were assign dynamically and video was included
[08:57] <duflu> +ed
[09:01] <alf_> duflu: alan_g: tvoss: I leave the mir_socket as it is for now, until we discuss a bit more and get some feedback from the security team
[09:01] <tvoss> alf_, do you take care of reaching out to the security team?
[09:02] <tvoss> RAOF, still around?
[09:03] <alf_> tvoss: I am not sure who they are, so I was planning on letting Robert A. know and handling this
[09:03] <tvoss> alf_, yup, fine with me
[09:06] <AlanBell> is there some documentation on what Mir will be able to do from a user perspective?
[09:07] <AlanBell> I can see lots of stuff about the low level detail of how it works, but will it do stuff like full screen zoom, text tracking zoom, multiple desktops on a cube or anything like that?
[09:07] <AlanBell> all I can see in the documentation is that it will do drop shadows on windows
[09:07] <duflu> AlanBell: Mir is no yet complete enough to answer those questions, or to be interesting at all for "users"
[09:08] <AlanBell> sure, but are these things going to be what it is for?
[09:09] <duflu> AlanBell: Yes, that kind of thing. But it's a long way from having such special effects yet. In the mean time we have Compiz
[09:12] <AlanBell> how about colour management, is that in the plans?
[09:12] <RAOF> tvoss: Yes.
[09:13] <RAOF> AlanBell: I'd like to make colour management happen, yes.
[09:14] <RAOF> alf_: The system compositor never accepts any sessions from anything but the display manager (in this case, LightDM)R
[09:14] <RAOF> alf_: Once Robert's got the LightDM bits hooked up, the system compositor will no longer have a listening socket on the filesystem at all.
[09:15] <alf_> RAOF: interesting
[09:15] <tvoss> AlanBell, anything you are especially interested in for ColorManagement?
[09:15] <duflu> alf_: To avoid duplication, look and comment here (I have added more): https://bugs.launchpad.net/mir/+bug/1169075
[09:15] <AlanBell> tvoss: well interested in whether Mir is the layer in which that is planned to be done
[09:16] <alf_> duflu: ok
[09:16] <tvoss> AlanBell, cool
[09:16] <AlanBell> I know Mir is planned to be lighter than wayland, and wayland has text tracking zoom and just got colour management
[09:16] <tvoss> AlanBell, ack
[09:16] <AlanBell> I was just concerned that if these were not in scope for Mir they probably won't get done at any other level because they are in Wayland
[09:17] <RAOF> AlanBell: Mir needs to be involved in colour management, yes, because Mir is in control of the CRTCs which is where you do the monitor response curve calibration.
[09:18] <alan_g> AlanBell: mir currently has a design that allows rendering "effects" to be added by other code in the server process. Our priority will be the effects needed by unity - but that isn't a technical limitation.
[09:19] <AlanBell> yeah, and unity doesn't need desktop switching any more
[09:21] <RAOF> alf_: Yeah. Basically what you end up with is: the DM spawns the SC (or visa versa), handing it an open fd to communicate over. The DM then spawns the sessions, handing *them* one end of an open fd and the SC the other end.
[09:21] <alan_g> AlanBell: *I* need desktop switching - and I'm sure other developers here do too. ;)
[09:22] <RAOF> alf_: That simplifies security to "I need to trust that the DM only spawns sensible sessions"
[09:23] <AlanBell> alan_g: ah, that is encouraging ;)
[09:23] <alf_> RAOF: it's unfortunate that both "system compositor" and "session compositor" have the same initials "SC" :)
[09:23] <RAOF> alf_: This is true :)
[09:24] <RAOF> I think we could potentially do a similar thing in the session compositor, too.
[09:25] <alan_g> alf_: "global compositor"? ;)
[09:25] <RAOF> I'm not sure if we need to have *any* sockets on the filesystem anywhere. Except for testing purposes.
[09:26] <alf_> RAOF: how do clients connect to the session compositor?
[09:28] <RAOF> They get spawned by a client connected to the session compositor.
[09:29] <RAOF> Well, most will be spawned by the session compositor itself, of course.
[09:30] <RAOF> I'm not sure if this is practical, but it's something we *could* do :)
[09:32] <alf_> RAOF: yes, I am not sure how well this  would work. Imagine I have a terminal (in a mir session) and start another client from there. How would the terminal know that this is a mir client and that it expects the fd to be passed in a certain way?
[09:32] <RAOF> It'd leave a mir fd open for *all* the clients it spawns. It doesn't need to know that it's a mir client that its spawning.
[09:33] <RAOF> Nothing relies on the first free fd being 3, right?
[09:33] <RAOF> ☺
[09:34] <alf_> RAOF: ok, how would you start something from an ssh session? :)
[09:35] <RAOF> You wouldn't :)
[09:36] <RAOF> Actually, that's not strictly true. You'd write an upstart conf file and get the session upstart to start it :)
[09:38] <RAOF> Or have a client already spawned that provides an interface to spawn further clients, or whatever.
[10:00] <RAOF> Woot! We now have daily packages for xf86-video-{ati,intel,nouveau} with XMir support.
[10:00] <RAOF> HUZZAH
[10:06] <duflu> Excellent-ness
[10:08] <tvoss> RAOF, \o/
[10:14] <alan_g> That's working packages?
[10:34] <RAOF> alan_g: Should be - I haven't tested nouveau, but mlankhorst assures me that works :)
[10:34] <mlankhorst> RAOF: I only tested with the kernel changes patched in, though
[10:35] <alan_g> RAOF: excellent. (Of course we *should* have automated tests to guarantee it all works.)
[10:36] <RAOF> We should indeed, but probably once the lightdm bits are in place.
[12:15] <hikiko__> hi, is there a hangout right now?
[12:19] <hikiko__> ah am :p ignore
[14:57] <thiagoandrade> I finally managed to build Mir and run it without errors, but in the Mir demos are all appearing glitchy when I run then.  Is there something I'm missing?
[15:12] <alan_g> thiagoandrade: yes (although its hard to guess what without more context)
[15:16] <thiagoandrade> alan_g, I believe the problem is my video driver. I tried to install fglrx but it wouldn't work as my  video card is a little old (Radeon HD 4200). I don know if I have a driver installed or if that matters, but "lsmod | grep drm" returns me the drm module. Should I install the driver available on the ATI website?
[15:18] <alan_g> thiagoandrade: that sounds plausible but is a bit outside my knowledge.
[15:18] <alan_g> alf_ ^ - any thoughts?
[15:20] <alf_> thiagoandrade: It sounds like a tiling issue. Do you see the squares changing or is it just a static image?
[15:21] <thiagoandrade> alf_, static image.
[15:21] <alf_> thiagoandrade: hmm, are you using the mesa from the mir-team staging PPA?
[15:21] <thiagoandrade> yes
[15:22] <alf_> thiagoandrade: ok, can you please try build/bin/render_surfaces (on its own, without a mir server)
[15:23] <thiagoandrade> alf_, ok.
[15:23] <thiagoandrade> alf_, it works.
[15:25] <alf_> thiagoandrade: ok, now please try running the mir_demo_client_unaccelerated with a mir server, you should see a rectangle flashing between two colors
[15:26] <thiagoandrade> alf_, no. Purple glitchy square.
[15:29] <alf_> thiagoandrade: what bzr version of mir are you using, and what mesa version (dpkg -s libegl1-mesa)
[15:33] <thiagoandrade> alf_, libegl1-mesa version is 9.2~git20130402.b2eee086-0ubuntu0+mir6-jenkins69. bzr version of Mir I don how to see, but updated yesterday.
[15:38] <alf_> thiagoandrade: please try the latest version of mir (bzr pull), there was a fix yesterday for a similar problem with clients
[15:39] <thiagoandrade> alf_, Updated. Now it's on version 597, gonna try again. By the way, just for curiosity. How one sees the current version of the branch with bzr?
[15:39] <alf_> thiagoandrade: to get the mir bzr version -> "bzr revno"
[15:44] <thiagoandrade> alf_, Ok now I get the flashing screen with mir_demo_client_unaccelerated
[15:44] <thiagoandrade> Guess it's working.
[15:44] <thiagoandrade> alf_, Thanks.
[15:45] <alf_> thiagoandrade: try the mir_egltriangle, too (which is accelerated), just to make sure
[15:46] <thiagoandrade> alf_, Working. :D
[15:47] <alf_> thiagoandrade: great :)
[15:47] <thiagoandrade> alf_,  Now I can play around with Mir. Thanks.
[15:47] <alf_> thiagoandrade: np
[15:50] <kdub> alf_, updated server-render-window (if the review is still fresh in your mind)
[15:51] <alf_> kdub: looking
[15:52] <alf_> kdub: I guess I shouldn't take it as a sign that the update revision is revision 666 ;)
[15:52] <kdub> haha! i thought the same thing :P
[16:05] <alf_> kdub: hmm, return -1 is still there ?
[16:05] <kdub> shouldn't be...
[16:05] <kdub> oh, that's a different return -1
[16:05] <kdub> i should change that too!
[16:07] <kdub> alf_, ok, removed. now the commit number is much nicer too!
[16:07] <alf_> kdub: ok, approved
[16:07] <kdub> cool, thanks
[19:32] <kgunn> kdub: hell yeah! fb native window!
[19:36] <kdub> kgunn, yay! now android graphics doesnt have to depend on android glue
[19:36] <kdub> working on rooting out that glue now...
[21:10]  * kdub -> eye dr
[21:26] <robert_ancell> thomi, will https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 autoland? Or is both CI and autolanding disabled for MPs not proposed by someone in the whitelist
[21:27] <thomi> robert_ancell: will find out, one minute
[21:27] <robert_ancell> thomi, ta
[21:31] <thomi> robert_ancell: autolanding will work, as long as the MP approver is on the whitelist. CI won't trigger however
[21:32] <robert_ancell> thomi, ok good. Has anyone considered starting CI if someone on the whitelist gives the MP an 'approve' review? I can live with the autolanding testing, but it would be nicer if CI would start once I'd checked the merge was good
[21:32] <thomi> robert_ancell: in fact, it's running now: http://<IP_ADDRESS>:8080/job/lightdm-raring-amd64-autolanding/12/console
[21:33] <robert_ancell> thomi, also nice would be in Jenkins would comment on the MP that it was building it with the link - the delay can be confusing
[21:33] <robert_ancell> thomi, is there a bug tracker I can file against or do I just keep bugging you? :)
[21:33] <thomi> robert_ancell: I don't believe we have, I'll file a feature request on your behalf if you like
[21:34] <robert_ancell> please do
[21:35] <thomi> robert_ancell: I'm happy to be bugged about this stuff, but FYI the project responsible is https://launchpad.net/jenkins-launchpad-plugin
[21:36] <robert_ancell> thomi, ok, cool I can file bugs there. The second issue is probably bug 1134328
[21:38] <robert_ancell> thomi, and the first issue is bug 1157855 :)
[21:38] <thomi> dammit, I'll stop typing then :)
[21:39] <thomi> robert_ancell: if you want attention on a particular bug for that project you're probably best emailing Martin :)
[21:40] <robert_ancell> thomi, he created those bugs so I'll assume he'll get emailed when I comment on them
[21:40] <thomi> good point
[22:01] <thomi> robert_ancell: I just noticed that on https://code.launchpad.net/~gber/lightdm/lightdm-style-fixes/+merge/159097 there's a CI approve vote
[22:01] <thomi> robert_ancell: so... apparently it already does what we want!?
[22:01] <thomi> robert_ancell: either that, or someone fixed it *really* fast :P
[22:40] <robert_ancell> thomi, I think it did it when it did the autolang
[22:40] <robert_ancell> autoland
[22:40] <thomi> that's a bit odd
[22:40] <thomi> once it's landed there's not much point running CI


[00:06] <teward> Nothing_Much, thanks, however, I found the daily ISOs location, hopefully the daily ISO installs and I don't have to do a Trusty -> Utopic upgrade by hand...
[01:24] <balloons> teward, your source is always cdimage.ubuntu.com for non-released images
[06:56] <jibel> good morning
[08:36] <dkessel> good morning jibel
[13:06] <average_guy> I can use testdrive or zsync, I lean towards testdrive because end user want GUI.  I just noticed though that if I zsync the utopic-daily-server img it faults where they all fault atm, but if I hit sync in testdrive and launch, it runs w/no problem
[13:07] <average_guy> guess i done w/testdrive as i cannot trust that it pulls the correct img
[14:01] <average_guy> I filed it as a bug against testdrive 1352905, but maybe the problem is zsync?
[14:38] <roadmr> bug 1352905
[17:45] <knome> balloons, hai
[17:46] <balloons> knome, hai
[17:46] <knome> was reading the mailing list, and was thinking what on earth would "beta RTM" mean...
[17:46] <knome> i'm sure new people will know even less
[18:23] <meecoder> Hello!
[18:28] <balloons> howdy meecoder
[18:30] <meecoder> I'm getting started with testing Ubuntu now, downloading VirtualBox and the testing iso.
[18:33] <average_guy> welcome meecoder, more=merrier
[18:36] <meecoder> Sadly, I have very slow internet. Incredibly slow.
[18:38] <average_guy> check this out then my friend: https://help.ubuntu.com/community/ZsyncCdImage
[18:42] <meecoder> Just a question: I have a Mac(running Mac OS.) I am using it for testing, should I install Ubuntu in a virtual machine and then use testdrive in it, or should I install it on the computer?)
[18:47] <meecoder> Or should I wait two weeks until I go back home and can use my Ubuntu laptops?
[18:47] <average_guy> well technically you wouldn't even need to install Ubuntu I would think.  I sometimes test iso's from vbox on Windows host
[18:49] <meecoder> Okay, can I use the zsync files on Mac? If so how?
[18:50] <average_guy> nope, zsync is a linux program. If you stay OSX will have to http download the iso
[18:53] <meecoder> I'll use zsync when I get home so I can use my linux computers, for now it's http(=slow)
[18:54] <average_guy> zsync is no help the first time, but everytime thereafter is only grabs the parts that have changed so less bandwidth overall
[18:55] <balloons> right.. meecoder you can certainly install ubuntu in a VM, and for the first few tries I'd recommend it so you know what to expect and are comfortable
[18:56] <average_guy> ^ the boss (I think)
[18:59] <meecoder> I saw you on the wiki!
[19:01] <meecoder> I still wish I was in Kansas City, I could get Google Fiber. That would improve the speed of downloading Ubuntu. and balloons: I have used ubuntu many times before, just not the testing version.
[19:03] <balloons> meecoder, google fiber sounds lovely :-) and it sounds like you have all the tools to test effectively
[21:29] <meecoder> I just went through a test, and realized I had downloaded the stable version. Now time for a retry download...
[21:36] <stgraber> all current images were bad, a new batch is building now
[21:36] <stgraber> I expect the first ones to show up in ~5min
[21:37] <meecoder> should I redownload after that?
[21:37] <stgraber> yes
[21:38] <meecoder> How do I know when it is done?
[21:39] <stgraber> queuebot will announce them as they show up
[21:39] <stgraber> or just look at iso.qa.ubuntu.com
[21:39] <meecoder> ok thanks
[21:39] <quantibility> hello
[21:40] <quantibility> ??
[21:40] <quantibility> hello world?
[21:40] <quantibility> heh
[21:40] <quantibility> i take it the is the devlopers guild?
[21:40] <quantibility> or developers
[21:40] <meecoder> no, more like testers
[21:40] <quantibility> dang it
[21:40] <quantibility> as am i
[21:40] <quantibility> tester and pushing myself to program
[21:41] <quantibility> its been a long time since i touched it
[21:41] <quantibility> my problem now is this dang panel i wanna reprogram it really
[21:42] <quantibility> no offense but its problem matic on this and other linux distros i have trid
[21:42] <meecoder> for more information about what we do https://wiki.ubuntu.com/QATeam
[21:42] <meecoder> ubuntu development is at #ubuntu-devel i think
[21:44] <quantibility> however i do realize i have a computer that i,m pretty sure has a few interesting hardware and special issues with it. though i don't see why i has this freaking problem of losing the dang buttons and having everything slide over to the right... and no easy way that i have found so far to fix it
[21:44] <quantibility> its like i have to reinstall whole system to get it fixed
[21:45] <quantibility> so
[21:45] <quantibility> as a "tester" / user i wanna let ya know that this bug with the panel is pain the keester
[21:46] <quantibility> i wanna reprogram the whole darn thing
[21:46] <meecoder> Go to Launchpad to report and work on bugs. launchpad.net/ubuntu
[21:46] <quantibility> im using xubunt
[21:46] <quantibility> u
[21:46] <quantibility> da faq is launch pad?
[21:47] <meecoder> Launchpad is where Ubuntu is developed.
[21:48] <quantibility> ohhhhhhhh sorry
[21:48] <quantibility> btw im an old irc'er, im 35, at about 10 to 11 i been on the net,..
[21:49] <quantibility> i programmed my first basic at 11
[21:49] <quantibility> known about IRC since 11 although i used Mric as my main client till you had to pay for it
[21:49] <meecoder> if you want to work on problems with Ubuntu or versions of it you might want to look at http://wiki.ubuntu.com/HelpingWithBugs
[21:50] <elfy> quantibility: is this a bug with 14.04 or 14.10 ? specific to xubuntu - http://xubuntu.org/contribute/
[21:51] <elfy> if you want to help with testing xubuntu - then I am positive you'd get your hand snatched off ;)
[21:51] <quantibility> well, see the thing is its PANEL its self, i was using another distro
[21:51] <quantibility> same problem arouse
[21:52] <quantibility> lay off the "ubuntu" "xbuntu" user battle, im talking linux
[21:52] <elfy> ok - so which version of xubuntu is it
[21:53] <quantibility> can't you just like ask irc what version im using?
[21:53] <quantibility> i was using solusOS
[21:53] <quantibility> same dang thing
[21:53] <elfy> ok - xfce?
[21:53] <quantibility> actually im more interested in the core.
[21:53] <quantibility> xfce yes
[21:54] <elfy> in which case check https://bugzilla.xfce.org
[21:54] <elfy> if it's in xfce then xubuntu won't be in a position to do much, but people that work with xubuntu work with xfce
[21:55] <elfy> and as far as a 'battle' there is none - but ubuntu issues and xubuntu issues are NOT the same - and I've enough on my plate with xubuntu without worrying about ubuntu thanks
[21:57] <quantibility> yeah thats why im interested in linux core.. i think its too big and that processing information can be simplified... so much so i think you can cut core size a third with even more versatility and less issues...
[22:00] <quantibility> basically with so many libraries in existence and access to the internet being so readily available, you can build your system on the fly.. basically you need one big library of api locations and once called stored on the fly
[22:57] <rbasak> pitti: have you considered using cache=unsafe in adt-virt-qemu? I wonder if it would speed things up.
[23:05] <sn33zy> im bored and don't know what to do.  does anyone have a task or something that needs done?


[08:02] <samurai2> hi there, is there anyone know any example of how to run java jar file as daemon process using upstart? thanks
[08:56] <JanC> samurai2: I think there is an example of that in the cookbook?
[08:58] <samurai2> JanC : yeah, actually I'm looking at it right now. :)
[08:58] <samurai2> I have make it as a background process
[08:59] <JanC> you probably want the "alternative method" then
[09:19] <samurai2> is it as simple as this http://bitkickers.blogspot.tw/2011/11/running-jar-as-service-linuxupstart.html
[09:19] <samurai2> ?
[09:20] <samurai2> because when I do service myapp stop
[09:20] <samurai2> it doesn't stop until now
[10:23] <TheLemonMan> hello there, i'm having some issues with the buildsystem not generating some headers
[10:51] <samurai2> I don't know why it keep saying start myapp and don't generate "start myapp with ID : blabla"


[00:33] <DarkwingDuck> Anyone ever played with zeya before?
[00:51] <DarkwingDuck> Anyone about to test something for me?
[02:11]  * pleia2 waves to DarkwingDuck
[03:54] <jyo> pleia2: Yeah, Rubik's Cube competition in Berkeley on Sunday. Sorry partimus people.
[03:57] <pleia2> doh :)
[19:19] <philipballew> has anyone here ever sat up a cron job? whats the best way to do it. It seems there are several but one way might be the best
[19:24] <akk> The easiest way is to put a script in cron.hourly, daily, weekly etc.
[19:24] <akk> If you need more control than that, use crontab (man crontab gives you the options).
[19:25] <philipballew> akk. im just makin a rsync job say all I was gonna run was rsync -azv  /home /myusername  /path/to/externalharddrive
[19:26] <philipballew> its a pretty easy thing, but was unsure if there was a correct way to do it. haha
[19:26] <akk> When and how often? That's the issue with cron.
[19:26] <philipballew> hum. every week was what i was gonna think
[19:27] <akk> If you don't care exactly when, just make a script and put it in cron.weekly.
[19:29] <philipballew> seemes easy enough.  #!/bin/sh seemes like the bwst way to go then
[19:30] <philipballew> thanks!


[00:31] <rick_h_> huwshimi: https://github.com/yui/yui3-gallery/tree/master/build/gallery-anim-morph woot!
[00:32] <rick_h_> https://github.com/yui/yui3-gallery/tree/master/src/gallery-anim-morph for the source with the api docs
[00:32] <huwshimi> rick_h_: Fantastic!
[00:33] <rick_h_> so first gallery module done, working on a couple more, but good to get the ball rolling
[00:38] <huwshimi> rick_h_: Yeah, feels like we're doing this properly now.
[04:28] <StevenK> wgrant: Clearly, AccessArtifactGrantSource.grant([artifact, subscriber]) is not the right way to call it, and I can't work out the right way from the code.
[04:29] <wgrant> StevenK: AccessArtifactGrantSource.grant([(artifact, grantee, grantor), ...]), IIRC, but let me check the interface
[04:29] <wgrant>     def grant(grants):
[04:29] <wgrant>         """Create `IAccessArtifactGrant`s.
[04:29] <wgrant>         :param grants: a collection of
[04:29] <wgrant>             (`IAccessArtifact`, grantee `IPerson`, grantor `IPerson`) triples
[04:29] <wgrant>             to grant.
[04:29] <wgrant>         """
[04:30] <StevenK> Right
[04:30] <StevenK> That pesky subscribed_by thing
[04:30] <wgrant> grantor
[06:01]  * StevenK blinks.
[06:02] <wgrant> StevenK: Hmm hmm?
[06:03] <StevenK>         # Only include subscribers who can see the bug, if it's private.
[06:03] <StevenK>         print list(indirect_subscribers)
[06:03] <StevenK>         if self.private:
[06:03] <StevenK>             print list(indirect_subscribers)
[06:03] <StevenK> [<Person at 0xf29fdd0 product-subscriber (Product-subscriber)>]
[06:03] <StevenK> []
[06:03] <wgrant> StevenK: It's probably a resultset
[06:03] <wgrant> Or some other sort of generator
[06:03] <wgrant> That you're consuming with the first list()
[06:03] <StevenK> It's a chain()
[06:03] <wgrant> Right, a generator
[06:04] <StevenK> Sigh, so I can't print it
[06:08] <StevenK> Bah, the query returns [], so it's fine, but product-subscriber is coming from somewhere.
[07:31] <wgrant> wallyworld: Did you consider precache_permission_for_objects?
[07:31] <wgrant> branchlisting.py uses it
[07:32] <wallyworld> yes but decided against it
[07:32] <wallyworld> since it's not the http caller needing to be cached
[07:32] <wallyworld> and it's exactly the same problem as for bug searching
[07:32] <wgrant> Isn't it?
[07:33] <wallyworld> ah, it is, yes
[07:33] <wgrant> Ah, you do it in BranchCollection, so this is a more general solution.
[07:33] <wallyworld> but i wanted to stick to the bug search pattern
[07:33] <wgrant> But you could equally do it in the view.
[07:33] <wgrant> Right.
[07:33] <wallyworld> i don't want to do it in the view
[07:33] <wallyworld> wrong place
[07:35] <wgrant> wallyworld: r=me, thanks
[07:35] <wallyworld> np, thanks for reviewing :-)
[07:35] <wallyworld> i really wanted to get that one sorted asap
[07:35] <wgrant> Yeah
[07:36] <wgrant> https://code.launchpad.net/~wgrant/launchpad/more-branchnamespace/+merge/114563 is pretty simple if you have a few mins.
[07:36] <wallyworld> sure
[07:37] <StevenK> wgrant: That does USERDATA, not PROPRIETARY
[07:38] <wallyworld> wgrant: 30	return False
[07:38] <wallyworld> should be return None i think
[07:38] <StevenK> I guess it will migrate when everything else does
[07:40] <wgrant> wallyworld: Good point. Doesn't actually matter, but it's wrong :)
[07:40] <wallyworld> wgrant: i agree with StevenK. we can cater for Proprietary in the if statement and it will work later
[07:40] <wallyworld> 42	+ if (information_type == InformationType.USERDATA and
[07:40] <wallyworld> 43	+ getFeatureFlag('disclosure.display_userdata_as_private.enabled')):
[07:40] <wallyworld> 44	+ return 'Private'
[07:40] <wallyworld> 45	+ return information_type.title
[07:40] <wallyworld> can add an == propprietary bit
[07:40] <wgrant> Where?
[07:41] <wgrant> That "return 'Private'" is just for the userdata_as_private
[07:41] <wallyworld> ah yes, sorry. misread it
[07:41] <wgrant> StevenK: Do you refer to getDefaultInformationType?
[07:41] <StevenK> That feature flag is getting used everywhere :-(
[07:41] <StevenK> wgrant: Yah
[07:42] <wgrant> StevenK: Well, the default information type is never proprietary yet
[07:42] <wgrant> So making it sometimes proprietary when it's never proprietary would be sort of wrong :)
[07:42] <wgrant> StevenK: I'll be adding a new feature-flagged codepath tomorrow which will return proprietary if the enum is set to return proprietary
[07:43] <StevenK> Ah
[07:43] <StevenK> wgrant: Yeah, you could use disclosure.proprietaryblahblah.disabled
[07:43] <wgrant> But returning proprietary before anything should be proprietary would seem to be a Bad Idea™
[07:43] <wgrant> StevenK: No
[07:43] <wgrant> disclosure.bvp_must_die or so
[07:44] <StevenK> Haha
[07:44] <StevenK> Curtis will be unhappy if you add another FF :-)
[07:44] <wallyworld> we can use the existing ff
[07:44] <StevenK> No, wgrant is right, we can't.
[07:44] <wgrant> We can't
[07:44] <wallyworld> disclosure.proprietary_information_type.disabled
[07:44] <wgrant> It's entirely different.
[07:45] <wgrant> This engages the BVP replacement
[07:45] <wgrant> Which we'll want to do before we enable proprietary
[07:45] <wallyworld> if the branch is associated with a proprietary project, shouldn't new branches be propprietary?
[07:45] <wgrant> Proprietary projects don't exist yet.
[07:45] <wallyworld> regardless / instead of bvp
[07:46] <wgrant> I suspect that a proprietary project has an enforced PROPRIETARY_ONLY branch config setting.
[07:46] <wallyworld> if a projject is has a current commercial subscription it can be
[07:46] <wallyworld> so i guess yes it may be too early
[07:46] <wgrant> Commercial subscriptions will enable the project owner to enable proprietary branches.
[07:47] <wgrant> They don't enforce all branches to be private.
[07:47] <wallyworld> wgrant: r=me, looks great
[07:48] <wgrant> Thanks
[07:48] <wallyworld> welcom
[07:49] <wgrant> The plan is to enable writable sharing RSN, then once that's out and working we can do the migration away from BVP to the new enumcol. The first stage of that work will still create User Data branches, like BVPs do now.
[07:49] <wgrant> Once BVP is dead, we can sensibly turn on Proprietary
[07:49] <wallyworld> ok
[07:49] <StevenK> wgrant: I guess we want IProject.default_propietary_branches
[07:49] <wgrant> At which point the BVP replacement can start doing Proprietary instead
[07:49] <wallyworld> so close yet so far
[07:49] <wgrant> StevenK: It's a four-state enum, remember.
[07:51] <wgrant> ‣ Public: Branches are public unless they contain sensitive security information.
[07:51] <wgrant> ‣ Public, can be private: New branches are public, but can be made proprietary later.
[07:51] <wgrant> ‣ Proprietary, can be public: New branches are proprietary, but can be made public later. Only people who can see the project's proprietary information can create new branches.
[07:51] <wgrant> ‣ Proprietary: Branches are always proprietary.  I'm distracted by ACB
[08:28] <adeuring> good morning
[08:29] <czajkowski> morning
[08:33]  * cjwatson wonders if there's any chance of deploying up to r15608 today ...
[08:37] <jelmer> hi adeuring, czajkowski, cjwatson
[08:37] <adeuring> hi jelmer!
[08:38] <wgrant> cjwatson: We have no UK ops today, but jjo might be able to do it in a few hours if QA gets done
[08:43] <cjwatson> Yeah, I suppose I was hinting at those with pending QA :)
[08:43] <wgrant> StevenK, jcsackett ^^
[08:44] <wgrant> Ah, I think jcsackett might have done his, but forgotten one of the bugs
[08:44] <wgrant> So it's just StevenK, on something that doesn't really matter hugely at this point.
[08:51] <cjwatson> (That deployment would let me update all our documentation to refer to the API client and decommission the queue script, since the API is now feature-complete.)
[08:52] <wgrant> It would seem wise to keep the queue script around for a couple of weeks, just in case...
[08:52] <wgrant> Since we have no other way out.
[08:53] <cjwatson> Yeah, perhaps
[08:54] <cjwatson> I wonder if SRU handling is enough to stress-test things, or if we need a freeze period of quantal
[08:54] <cjwatson> The latter are a bit difficult to come by these days, since there's considerable top-down pressure not to freeze for alpha milestones
[08:54] <wgrant> I think routine SRU+security stuff is probably more likely to shake out issues than freezing a dev series.
[08:54] <wgrant> Freezes tend to often be handled through the web UI anyway, right?
[08:55] <cjwatson> Only because we felt we ought to and didn't have an API.
[08:56] <wgrant> Right, but they weren't traditionally done through queue
[08:56] <cjwatson> They've traditionally been a mix
[08:56] <wgrant> So removing queue is less likely to impact them.
[08:56] <wgrant> True
[08:57] <cjwatson> I'm not especially worried about routine NEW handling; the things I'm less sure about are timeouts on accepting uploads that close lots of bugs
[08:57] <cjwatson> Which are more likely in the development series, apart from kernel SRUs which happen through a PPA anyway so don't count
[08:58] <wgrant> Hm, indeed
[08:58] <wgrant> Perhaps we can accidentally freeze before the next unity upload...
[08:58] <cjwatson> I could certainly ask for an experimental freeze where we in fact just accept everything for a few days
[09:01] <cjwatson> And I've tweaked my pending announcement mail to remind people that I need to actually hear about bugs rather than quietly working around them
[09:01] <wgrant> :)
[09:59] <jtv> Hello jml!  Julian had an interesting suggestion: we found Launchpad's FakeMethod a tough thing to do without in MAAS, so maybe it would be an interesting thing to have in testtools?
[10:11] <jml> jtv: I've forgotten what FakeMethod does. Looking now.
[10:12] <jml> jtv: tbh, I think not. I think what you want is mfoord's mock: http://pypi.python.org/pypi/mock
[10:12] <jtv> jml: it's used for st/ubbing (mis-spelling to avoid bothering Stu) functions and methods.
[10:12] <jtv> Yes, this is a lot more lightweight.
[10:12] <jtv> \
[10:12] <jml> jtv: what does that mean?
[10:13] <jtv> It does a lot less.
[10:13] <jtv> It does:
[10:13] <jml> jtv: and that's a good thing?
[10:13] <jtv> Can be, if you don't want to climb the learning curve.
[10:14] <jtv> That was the problem with Mock when we first ran into it, I think: there was too much new stuff to take in, when all we really wanted is patch out some method to return a predetermined value, or raise a predetermined exception.
[10:14] <jml> it's pretty easy
[10:15] <jml> @patch("foo.bar")
[10:15] <jml> def f(mock_foo_bar):
[10:15] <jml>   mock_foo_bar.returnvalue = 42
[10:15] <jtv> Still:
[10:15] <jtv> self.patch(foo, "bar", FakeMethod(42))
[10:16] <jml> I riposte:
[10:16] <jml> self.patch(foo, 'bar', lambda *args: 42)
[10:16] <jtv> Don't forget the **kwargs.
[10:17] <jml> my test will fail if that matters :)
[10:17] <jtv> But sometimes we find that afterwards you want to know about what calls have been made to your fake, and that's also built into FakeMethod.  (Mock has something nicer for that, but again FakeMethod keeps it very simple)
[10:17] <jml> jtv: ok
[10:18] <jtv> Anyway, not trying to force it on you.
[10:18] <jml> jtv: No worries. I'm not interested in putting it into testtools. I would strongly suggest using mock and then having less code to maintain. Alternatively, create a library for FakeMethod.
[10:19] <jtv> Seems a bit silly to have something so small stand alone as a library… I think that's one reason why Julian suggested it might have a place in testtools.
[10:20] <jml> jtv: perhaps it might have a place in mock
[10:20] <jtv> What we did for now is just copy it.  Doesn't really matter if it diverges or not.
[10:20] <jml> well, maintaining way too much code _is_ the Launchpad Way.
[10:20] <jtv> :)
[10:20] <jml> no point in making your job too easy
[10:21] <jml> sorry. I shouldn't snark :(
[10:21] <jtv> That's okay… I can see the truth in it.
[10:21] <jtv> In this case, it's stable enough that I don't see it mattering much.  It's not like we ever find bugs in it.
[10:24] <jtv> We'd _like_ to have it in a shared place, of course, but it's not hugely important.  I think it'd probably fit poorly with Mock; maybe Mock has a good replacement for it.
[12:09] <cjwatson> OK, zope is melting my brain and I need some advice.  What might I have forgotten in http://paste.ubuntu.com/1087847/ that would cause "KeyError: 'editchroot'"?
[12:10] <cjwatson> It looks like it's failing to look up overview_menu.
[12:10] <cjwatson> But I might be misguessing as it's kind of hard to keep my head straight in 20-odd stack frames.
[12:12] <cjwatson> The expression it's trying to evaluate at the time is Expression: <PathExpr standard:u'overview_menu/editchroot/fmt:icon'>
[12:12] <cjwatson> And I think the menu is None.
[12:16] <jam1> hey jelmer, how's it going today?
[12:20] <cjwatson> http://paste.ubuntu.com/1087861/ is the full traceback I'm staring at.
[12:28] <cjwatson> Ah, maybe I have the NavigationMenu attached to the wrong interface
[12:30] <rick_h_> sorry cjwatson you're on my kryptonite
[12:30] <rick_h_> maybe adeuring knows a bit more
[12:32] <adeuring> cjwatson: right; without looking further I'd guess that overview_menu does not know about "editchroot"
[12:32] <jelmer> jam: hey
[12:33] <jelmer> jam: alright, reviewing and wrapped up the bzr upload to quantal
[12:33] <jelmer> jam: are you still working on the python2.7 transition?
[12:33] <mgz> with a ribbon?
[12:40] <rick_h_> sinzui: do you know where YUI comes from? It's in lp-sourcedeps and symlinked into the app root, but I can't figure out where that lp-sourcedeps directory came from
[12:40] <sinzui> I do not
[12:40] <sinzui> StevenK, do you know ^
[12:40] <wgrant> rick_h_: buildout
[12:40] <wgrant> rick_h_: There's a yui tarball in download-cache
[12:41] <wgrant> A buildout rule extracts it into yui/
[12:41] <rick_h_> is there? I was checking out and missed it
[12:41] <wgrant> Which is a symlink to lp-sourcedeps
[12:41] <rick_h_> ok, looking thanks
[12:41] <wgrant> $ ls download-cache/dist/yui-3.*
[12:41] <wgrant> download-cache/dist/yui-3.3.0.tar.gz  download-cache/dist/yui-3.3.tar.gz  download-cache/dist/yui-3.4.1.tar.gz  download-cache/dist/yui-3.5.0pr1.tar.gz
[12:41] <rick_h_> heh, lovely so just blind
[12:41] <rick_h_> oh heck, scrolling ftw thanks wgrant
[12:44] <wgrant> Heh
[12:46] <cjwatson> adeuring: mm, well, I now have http://paste.ubuntu.com/1087894/ which I think is less incorrect (it now actually has a NavigationMenu with usedfor = IDistroArchSeries), but I'm still getting exactly the same failure :(
[12:46] <cjwatson> queryAdapter(<a DAS object>, INavigationMenu, 'overview') -> None
[12:47] <wgrant> cjwatson: Have you registered it?
[12:47] <wgrant> You want the browser:menus ZCML directive
[12:48] <cjwatson> Ah, yes, I just got there by grepping for another case
[12:49] <cjwatson> Excellent!  Now I have a different failure, but a comprehensible one.  Thanks
[13:11] <rick_h_> abentley: http://blog.singly.com/2012/07/09/from-itch-to-scratched-google-hangout-permalink/
[13:12] <cjwatson> Is there a limit (practical or otherwise) to the size of file that can go in a multipart/form-data upload to LP?
[13:13] <abentley> rick_h_: Cool.  Sounds like what smoser did.
[13:28] <czajkowski> sinzui: good day. do you happen to know if ther eis a way to automate via a terminal milestones for a project ?
[13:28] <sinzui> czajkowski, do you mean create them, release them?
[13:29] <czajkowski> sinzui: https://answers.launchpad.net/launchpad/+question/202937
[13:29] <czajkowski> is why I am asking
[13:31] <sinzui> There  many launchpadlib scripts that do that
[13:31] <sinzui> https://launchpad.net/+apidoc/devel.html
[13:32] <sinzui> I have one that U use to release milestones, but nothing that creates the milestone, or adds a file to a project_release
[13:32]  * sinzui looks for example
[13:40] <sinzui> czajkowski, point the user to lp-project-upload in https://launchpad.net/ubuntu-dev-tools which will create a milestone, release it, then upload a file
[13:41] <czajkowski> sinzui: great, thank you/
[13:43] <sinzui> czajkowski, , actually, I don't see that script anymore
[13:43]  * sinzui looks for rename
[13:44] <Laney> it's probably in lptools now
[13:48] <sinzui> czajkowski, lp-project-upload moved to https://launchpad.net/lptools
[13:48] <czajkowski> sinzui: cheers
[13:59] <jam> jelmer: yes, I'm still working on the python2.7 stuff. I'm getting a segfault now in the lucid container, which is being problematic to track down.
[14:02] <mgz> a py2.7 specific segfault? because you had lucid vanilla working right?
[14:02] <jelmer> jam: do you have a gdb backtrace that's hinting at what might be happening?
[14:02] <rick_h_> jcsackett: ping, have a review for you if you get a sec. I *think* this is right and works locally but please sanity check me https://code.launchpad.net/~rharding/launchpad/lpyui-dep/+merge/114430
[14:03] <jam> jelmer: that's the best part, 'ulimit -c unlimited' and I can't find a core file
[14:03] <jam> mgz: yes
[14:03] <jam> jelmer: It fails while bootstrapping 'bin/py' I can at least run 'py -vv' and see that it is failing during "import code_..." ?
[14:03] <jam> however, just importing that module isn't enough to get it to crash
[14:04] <jam> I'm guessing there is something that is breaking the import machinery, or something along those lines.
[14:10] <jam> mgz, jelmer: I'm trying to do a fresh bootstrap (somehow, not sure if 'make clean' is actually clean enough)
[14:10] <jam> now that is weird...
[14:10] <jam> I did 'make schema' and it crashes at bin/py, but the outer OS seems to think gnome-screensaver just died
[14:11] <jelmer> hmm
[14:11] <jelmer> pid reuse?
[14:19] <jcsackett> rick_h_: it looks alright to me, but my Make/buildout knowledge is bare bones. i believe gary_poster has some expertise there iirc. if he has time, might be worth having him take a look too.
[14:20] <rick_h_> jcsackett: ok, I tested it out locally and tried to make sure make check/tests run, turning on/off the combo loader FF works, and then setting and unsetting the yui verison
[14:20] <jcsackett> rick_h_: given all that and a second pair of eyes, i think it's probably fine. if it's not, ec2 will choke on it anyway. so, like i said, r=me.
[14:20]  * jcsackett realizes he didn't actually say that.
[14:21] <gary_poster> jcsackett, hiya.  on calls. lemme know if you need me later
[14:22] <jcsackett> gary_poster: will do.
[14:28] <jam> jelmer: well this time it is crashing trying to import _ctypes which seems much more likely to be a problem.
[14:45] <jam> jelmer: so right now I'm trying to make sure it isn't re-using .pyc files or something along those lines, with the 2.6 install. But I accidentally nuked my download-cache and have to redownload it, etc.
[14:52] <jelmer> jam: fun :(
[14:52] <jelmer> jam: what did you have to do to get make to run, btw? for me it still fails (silently) during the mailman step
[14:53] <jam> jelmer: well right now 'make schema' is segfaulting, so I don't know that 'make' is working
[14:54] <jelmer> jam: have you tried "bzr grep python2.6" ?
[14:54] <jelmer> jam: I think one of the database scripts uses its own shebang line
[14:55] <jam> jelmer: bin/py was specifically segfaulting while running 'import site', so it is happening pretty early.
[14:55] <jelmer> ah, ok
[14:56] <mgz> jam: what's your recipe roughly? just add the lucid py2.7 ppa to a normal lucid setup of launchpad?
[14:57] <jam> mgz: and have a branch of launchpad that changes the PYTHON:= line in the makefile to not do crazy version checks, but just 'PYTHON:=python2.7'
[14:57] <jam> add-apt-repository ppa:pythoneers/lts
[14:57] <jam> then sudo apt-get install python2.7
[14:58] <mgz> ace. can probably repo here reasonably easily then, unless rocketfuel borks things too badly (then it's extra hacks in the branch)
[14:59] <jam> mgz: note that on startup I'm getting: http://paste.ubuntu.com/1088093/
[14:59] <jam> but everything was working with python-2.6, so I thought that was just noise
[15:01] <jam> I did run out of disk space at one point, and had to expose more space for the VM. maybe something got horrbly borked and I should just restart from scratch
[15:05] <mgz> fun.
[15:31] <czajkowski> jelmer: can you investigate please. https://support.one.ubuntu.com//Ticket/Display.html?id=19323
[15:32] <jelmer> czajkowski: on it
[15:33] <czajkowski> jelmer: thanks
[18:00] <abentley> jcsackett: Could you please review https://code.launchpad.net/~abentley/launchpad/mp-by-revision-id/+merge/114693 ?
[18:28] <jcsackett> abentley: r=me. looks good, and thanks--i've been wanting that to work. :-)
[18:29] <abentley> jcsackett: Thanks.  It'll also require some bzr-side fixing before lp-find-proposal can do it.
[18:37] <magcius> ev, ping
[22:00] <sinzui> jcsackett, wgrant, StevenK, wallyworld: http://people.canonical.com/~curtis/lp-milestone/report.html
[22:07] <lifeless> sinzui: did you do that yourself ?
[22:07] <lifeless> sinzui: or is it some stock tool we have hanging around ?
[22:07] <sinzui> Yes
[22:07] <lifeless> its nice
[22:08] <sinzui> I wrote it. It thinks it is talking to Lp, it is actually using json I pulled and removed private data
[22:08] <rick_h_> lifeless: replied in -dev for the combo loader notes. Let me knwo if there's something else I need to do.
[22:08] <sinzui> A lot could be reused in Lp or other tools
[22:09] <lifeless> sinzui: are the burn down charts totally LP sourced?
[22:10] <sinzui> yes
[22:10] <lifeless> sinzui: perhaps lpkanban would be a good place for the chart logic to live
[22:10] <sinzui> Most of the code is tested.
[22:10] <sinzui> I was thinking of pulling data from kanban, but I need s break from this report
[22:11] <lifeless> sinzui: lpkanban shows LP bug data for a team as a kanban board
[22:11] <lifeless> sinzui: its not leankitkanban related
[22:11] <lifeless> sinzui: and sure, not trying to give you work, just speculating about structure :)
[23:29] <StevenK> wgrant: http://pastebin.ubuntu.com/1088958/  test_add_comment_no_access fails since product-subscriber is in the list, but it should have no access to the bug, so WTF ...
[23:32] <wgrant> StevenK: That's pretty odd. Let me have a look
[23:39] <wgrant> StevenK: Oh
[23:39] <wgrant> StevenK: The return is a lie.
[23:40] <wgrant> getBugNotificationRecipients doesn't actually use the return value. It uses the contents of BugNotificationRecipients.
[23:40] <wgrant> So you need to filter what you add :(
[23:40] <wgrant> Or get BugNotificationRecipients to filter
[23:40] <StevenK> Oh, bleh
[23:40] <wgrant> Or *possibly* filter in getBugNotificationRecipients
[23:41] <StevenK> Let's teach BugNotificationRecipients how to filter
[23:43] <StevenK> Which looks ... fun
[23:46] <wgrant> StevenK: btw, qa?
[23:47] <StevenK> Oh, bleh.
[23:49] <rick_h_> ccccccbgjgvclbkvdbvchdknlnkhgutbkgbcurerrjvb
[23:49] <wgrant> I didn't know rick_h_ had a cat.
[23:52] <spm> possibly he's moving to Aus and this is the town he's moving to?
[23:52] <wgrant> True
[23:54] <StevenK> spm: That must be the short name.


[02:27] <lapo> hi
[02:50] <klepas> moin
[03:19] <troy_s> greets boys
[04:15] <lapo> does anybody feel like helping with gnome icon theme?
[07:49] <BHSPitLappy> PingunZ, connection troubles?
[07:49] <PingunZ> BHSPitLappy, Nowp, just  got back to ubuntu, lots of tweaking and rebooting to do :)
[07:49] <BHSPitLappy> woot...


[22:32] <cjwatson> ppc64el builder situation should be much improved now.  A couple of compute nodes had got themselves into variously non- or semi-functional states.
[22:43] <RikMills> cjwatson: thanks, as always!