[02:09]  * InHisName wonders if there is anyone NOT infected with lockjaw.
[08:23] <JonathanD> Morning.
[11:29] <rmg51> Morning
[14:25] <waltman> *yawn*
[18:13]  * InHisName yawns in the afternoon
[18:58] <InHisName> my compiz went from 37MB on top, to 110MB in less than 12 hours even with the mod added to compiz.


[05:12] <fo0bar> ubuntulog test
[08:32] <TheMue> rog: morning
[08:32] <rog> TheMue: hiya!
[08:32] <rog> TheMue: feeling better, i hope
[08:33] <TheMue> rog: yep, yesterday already almost through with it, today feeling fine. thx.
[08:33] <rog> TheMue: cool
[08:33] <rog> TheMue: glad to hear it!
[08:34] <TheMue> rog: already proposed the next charm changes also containing your _ wishes. ;)
[08:34] <rog> TheMue: thanks
[08:34] <rog> TheMue: saw that
[08:35] <TheMue> rog: my pleasure
[08:35] <TheMue> rog: btw, got another 'infect'.
[08:36] <rog> TheMue: infect?
[08:36] <TheMue> rog: during studies i've learned scheme, but now i' trying lisp. ;)
[08:36] <rog> ah. CL?
[08:36] <rog> SBCL is the one to use
[08:36] <rog> baroque but interesting with it
[08:37] <TheMue> rog: yep, choosen sbcl as a start.
[08:37] <rog> TheMue: the hyperspec is the invaluable reference - i used it all the time
[08:38] <TheMue> rog: and i want to play a bit with actors in lisp, found some docs and a lib.
[08:38] <rog> TheMue: for your amusement, here was a little library i did in CL some time back: http://common-lisp.net/project/cl-xmlspam/
[08:38] <TheMue> rog: ah <click>
[08:39] <rog> TheMue: i ported russ's
[08:39] <rog> oops
[08:39] <rog> i ported russ's C channel communications code to CL too.
[08:39] <rog> TheMue: never entirely satisfactory - it really needs lightweight threads, like Go.
[08:41] <TheMue> rog: i'll see if i can do something like actors running based on thread pools
[08:41] <wrtp> TheMue: so no first-class channels - sending messages to processes like in erlang?
[08:42] <TheMue> wrtp: yep, more like that
[08:42] <TheMue> wrtp: and like scala
[08:42] <wrtp> TheMue: right.
[08:43] <wrtp> TheMue: (i haven't looked at scala much)
[08:43] <TheMue> wrtp: i only for a short article i wrote more than a year ago, not very deep
[08:44] <wrtp> TheMue: the book to buy for getting into CL is "Practical Common Lisp", if you haven't already got it.
[08:44] <TheMue> wrtp: i dislike all those langs based on the jvm, they tend to be too weak due to the (wished) interaction with the java libs.
[08:44] <wrtp> TheMue: it's great. and doesn't try to hide the dubious bits
[08:45] <wrtp> TheMue: yeah. same with .net languages
[08:45] <wrtp> TheMue: i played with F# for a bit
[08:45] <TheMue> wrtp: full ack
[08:46] <TheMue> wrtp: i got "Land Of Lisp" for a review. but if the infect gets deeper i'll buy your book. ;)
[08:46] <TheMue> wrtp: i only read about f#, but it looked interesting too
[08:47] <TheMue> wrtp: and i still like erlang (used it for two years).
[08:47] <wrtp> TheMue: it's a classic. and extremely useful for finding out how to get around the bizarre file path handling for example
[08:48] <TheMue> wrtp: so, have to leave for a few minutes, banking. biab
[08:49] <wrtp> TheMue: c u
[09:34] <wrtp> something odd is going on with this machine: http://paste.ubuntu.com/853732/
[09:57] <TheMue> back again
[11:01] <wrtp> TheMue: are you seeing codereview.com being slow currently?
[11:02] <TheMue> wrtp: no, today they have been fine. but had the too last week.
[11:18]  * wrtp really doesn't like it when he makes lots of changes in response to a review... and then finds out they were made in the wrong branch.
[11:25] <niemeyer> yo!
[11:26] <wrtp> niemeyer: yoyo!
[11:26] <wrtp> niemeyer: responses made to both reviews, BTW.
[11:27] <wrtp> i hope you don't mind, i went for "k" rather than "pk" :-)
[11:28] <niemeyer> wrtp: Thanks!
[11:28] <niemeyer> wrtp: That's fine too
[11:28] <wrtp> cool
[11:28] <niemeyer> wrtp: Was just trying to make them consistent and distinct among themselves
[11:28] <wrtp> niemeyer: yeah, thought so.
[11:28] <wrtp> niemeyer: i like permKey BTW
[11:29] <niemeyer> wrtp: Sweet
[11:55] <TheMue> niemeyer: Already took a first look into https://codereview.appspot.com/5671055/?
[11:55] <TheMue> niemeyer: hiya btw
[11:55] <niemeyer> TheMue: Heya!
[11:56] <niemeyer> TheMue: Not yet, but you're my first priority today.. I'll just finish a meeting with Dave Cheney, and will be in your reviews
[11:56] <TheMue> niemeyer: great, thx
[12:02] <TheMue> niemeyer: just for info, weekly update leeds to zookeeper compiling troubles
[12:02] <TheMue> oh, wife calls for lunchtime
[12:02] <TheMue> biab
[12:04] <niemeyer> TheMue: The fix is already up for review
[12:04] <niemeyer> TheMue: and you'll have to upgrade to Go tip as well
[12:04] <niemeyer> TheMue: There's a bug in cgo itself that I fixed yesterday
[12:29] <TheMue> niemeyer: ok, thix, will switch to tip
[12:37] <wrtp> TheMue: actualy the fix is in weekly
[12:37] <wrtp> TheMue: (the newest weekly)
[12:38] <TheMue> wrtp: so tip should contin it too, shouldn't it?
[12:38] <wrtp> TheMue: sure. but i think we generally use weekly if it works.
[12:39] <TheMue> wrtp: hmm, if i recall it right, somebody named rog told me we use tip.
[12:39] <TheMue> wrtp: ;)
[12:40] <wrtp> TheMue: only occasionally, when things are broken with weekly :-)
[12:41] <wrtp> TheMue: ...as was the case on that previous occasion
[12:42] <TheMue> wrtp: thankfully an update-golang release|weekly|tip is enough for a full reinstall including the external packages
[12:43] <wrtp> TheMue: yeah, the go tool makes things much much easier. bliss.
[12:43] <wrtp> TheMue: i usually run all.bash though just in case the compilers have changed
[12:46] <TheMue> wrtp: me too, but it's inside the script above, together with the go get's
[12:47] <wrtp> TheMue: ah, it's your script. i though you just meant "hg update weekly"
[12:47] <wrtp> TheMue: (which does work usually in fact)
[12:47] <wrtp> s/though/thought/
[12:47] <TheMue> wrtp: no, the script does the hg update, the all.bash and some clean go get
[12:48] <TheMue> wrtp: i'm lazy, ol' admin. ;)
[12:49] <TheMue> wrtp: doing something more than two, three times needs automation
[12:49] <wrtp> TheMue: what's the go get for?
[12:49] <wrtp> TheMue: to update to the required package versions?
[12:50] <TheMue> wrtp: yep, I earlier had troubles that once fatched code is only recompiled, not fetched again after release changes
[12:51] <wrtp> TheMue: yeah, i can see that. i don't usually have that problem though - i'll do get -u when a package stops working :-)
[12:51] <TheMue> wrtp: is a go build of own sources now intelligent enough to do a go get on 3rd party packages?
[12:51] <wrtp> TheMue: ... which makes it faster to switch versions.
[12:52] <wrtp> TheMue: a "go get -u" you mean?
[12:52] <TheMue> wrtp: yep, my script does a go get -u too
[12:52] <wrtp> TheMue: i don't think it's possible for it to know if the appropriate version has changed.
[12:53] <wrtp> TheMue: (of a given package, with respect to the current Go version, i mean)
[12:53] <TheMue> wrtp: would be nice. "hey, i'm building with rel 1 and import 3rd party pkg a. let's check if it has the according rel, otherwise update it on the fly."
[12:54] <wrtp> TheMue: i think if you do 'go get -u .' it should work
[12:54] <wrtp> lunchtime
[12:54] <TheMue> wrtp: yeah, it does, but you have to do it manually.
[12:55] <TheMue> wrtp: inside of a go build it would be nice
[12:55] <TheMue> wrtp: enjoy
[13:47] <niemeyer> Okay
[13:47] <niemeyer> TheMue: So, let me see your branch
[13:47]  * niemeyer browses the review list
[14:57] <TheMue> fwereade_: thx for the review, the other branch with your comment is in https://codereview.appspot.com/5690051/
[14:57] <fwereade_> TheMue, thanks; but I'm not clear which order they're meant to be merged in
[14:58] <fwereade_> TheMue, I'm sure I could figure it out but I'm lazy -- it would be good to set prereqs even if we don't yet get nice diffs out of it
[14:58] <TheMue> fwereade_: while point 1 is related to the testing dir question what exact problem do you have with .. in path?
[14:58] <fwereade_> TheMue, just that I'm suspicious that things will move :p
[14:58] <TheMue> fwereade_: yeah, understand, would be nice if the order/dependency could be seen easily
[15:01] <niemeyer> TheMue: Review sent
[15:01] <TheMue> niemeyer: thx for review. you get a compiling error? which kind?
[15:01] <niemeyer> TheMue: I don't think I said that
[15:01] <TheMue> niemeyer: ok, than i misinterpreted a comment
[15:02] <TheMue> niemeyer: so the state.Charm should implement the charm.Charm interface?
[15:03] <niemeyer> TheMue: Yes, and I think it already does
[15:03] <TheMue> niemeyer: hehe, maybe by accident
[15:04] <TheMue> niemeyer: it's the first time in state we're implementing an external interface, so i wondered
[15:04] <niemeyer> TheMue: Yeah, that's fine.. charm is kind of special in that we have several implementations of the interface
[15:05] <niemeyer> We have another one in the store as well
[15:05] <niemeyer> So 4 implementations right now
[15:05]  * TheMue likes interfaces
[15:05] <niemeyer> TheMue: I like _Go_ interfaces.. specifically.. :-)
[15:06] <niemeyer> I've had not-so-great experiences before with other kinds of interfaces
[15:08] <niemeyer> Zope interfaces comes to mind, for instance..
[15:09] <TheMue> niemeyer: never played with zope
[15:11] <niemeyer> I'll head to lunch, biab
[15:15] <rogpeppe> network has been playing up all day
[15:30] <rogpeppe> fwereade_: you gotta review
[15:30] <fwereade_> rogpeppe, tyvm
[15:31] <rogpeppe> fwereade_: you might not when you see all the comments!
[15:31] <rogpeppe> fwereade_: looking good though, in general
[15:32] <fwereade_> rogpeppe, heh, lots of comments beat just one saying "utterly hopeless; rejected, and shame on you" or equivalent :p
[15:32] <rogpeppe> fwereade_: lol
[15:37] <rog> right, i'm gonna reboot.
[15:45] <rog> well, ubuntu boot is quick, but shutdown...
[15:52] <fwereade_> rog, just a thought... if pstate were called pinfo, would you be happier about keeping path in there?
[15:52] <rog> fwereade_: i don't see why you want path in there really. it just saves a parameter in two functions.
[15:53] <rog> fwereade_: i'd be happier with a watcher type to gather together more params - i think things would look cleaner then.
[15:53] <fwereade_> rog, I admit that I originally put it in there because I was getting annoyed about the number of params ;)
[15:54] <fwereade_> rog, I'll experiment a bit
[15:55] <rog> fwereade_: if you pass watcher by value, you won't even need to incur an allocation - it'll be exactly to equivalent to passing the values as arguments.
[16:06] <fwereade_> rog, the tyvm holds, nice review
[16:06] <fwereade_> rog, I'm not so sure about the loop/goroutine question though
[16:06] <rog> fwereade_: no?
[16:07] <rog> fwereade_: i don't see why you need to start a new goroutine each time through
[16:08] <fwereade_> rog, forces are that (1) there are far more cases in which I want to break out of the loop than to continue looping, and (2) it seems to me that if I just recurse I'll eventually use an impolite amount of stack
[16:09] <fwereade_> rog, (1) hence not-quite-right as a loop, (2) hence goroutine
[16:11] <fwereade_> rog, sane or crackful? :p
[16:12] <rog> fwereade_: one mo, i'll paste the kind of thing i'm thinking of
[16:12] <rog> fwereade_: http://paste.ubuntu.com/854172/
[16:14] <fwereade_> rog, that's basically what I had before I decided the loop was ugly (without the break loop, which doesn't feel to me like it really improves clarity)
[16:15] <rog> fwereade_: yeah, it looks better without the loop label: http://paste.ubuntu.com/854177/
[16:16] <rog> fwereade_: but i think the loop is good - you're wanting to loop, so why not use one?
[16:16] <fwereade_> rog, hm, with for p.alive, that's definitely nicer
[16:17] <rog> fwereade_: oops, needs a p.alive=false in the DELETED case
[16:17] <fwereade_> rog, details details :)
[16:17] <rog> :-)
[16:17] <fwereade_> rog, what about awaitAlive though? the looping is definitely exceptional in that case
[16:17]  * rog has a look
[16:19] <fwereade_> rog, hm, still, for consistency's sake I might change that one anyway
[16:19] <rog> fwereade_: i think you can use exactly the same structure to good effect: http://paste.ubuntu.com/854183/
[16:20] <rog> fwereade_: they're both less lines of code, easier to read (IMHO) and more efficient... what's not to like? :-)
[16:22] <fwereade_> rog, yeah, exactly, with the loop conditions they are much nicer
[16:22] <fwereade_> rog, thanks :)
[16:22] <rog> fwereade_: np. (writing this kind of code with channels is nice, ain't it?)
[16:23] <fwereade_> rog, yeah, I'm really enjoying it :)
[16:23] <rog> fwereade_: good. that's what we want to hear :-)
[16:24] <rog> fwereade_: the main issue that probably needs discussion is whether unoccupying a node should delete it.
[16:24] <fwereade_> rog, ah yeah, I meant to mention that
[16:24] <rog> fwereade_: i'm tending towards the point of view that it shouldn't
[16:24] <fwereade_> rog, the raciness you sadly note has nothing to do with node clearing
[16:25] <fwereade_> rog, I don;t think it's sensible to assume that a presence node we want to watch will automatically exist
[16:25] <rog> fwereade_: if you were guaranteed that node existed, then you could just do GetW - no need for the ExistW call
[16:25] <fwereade_> rog, who says the Pinger even got started?
[16:25] <rog> fwereade_: i think the node should be created before the Pinger is started.
[16:26] <rog> fwereade_: so when some structure is created, a node is created for the watch node. and then a pinger and a watcher can rendezvous on it.
[16:26] <fwereade_> rog, well, it is, first thing on pinger creation, before run (so we can get any errors out quickly and easily, if they're going to happen)
[16:26] <fwereade_> rog, but... doesn't this just shuffle the raciness around?
[16:26] <rog> fwereade_: yeah, but there's no error if a watcher is watching a bad path
[16:27] <fwereade_> rog, who's responsible for creating that node?
[16:27] <rog> fwereade_: i don't think so.
[16:27] <rog> fwereade_: the state code.
[16:28] <rog> fwereade_: so if you're an agent, you can do an ExistsW if you like to determine when some structure comes into place (same way we watch the init node), and then run a pinger or a watcher on a node within the structure
[16:28] <rog> fwereade_: it's a slightly different approach i know, but i think it might make sense
[16:29] <rog> fwereade_: one mo, i've got to go and help carmen turn over the contents of a compost bin. back in 5.
[16:30] <fwereade_> rog, np, thinking
[16:30] <niemeyer> fwereade_: Can't awaitDead and awaitAlive be a single loop?
[16:31] <niemeyer> fwereade_: I don't have anything concrete yet, but my gut feeling about all those helper functions is that the problem itself shouldn't be so complex
[16:31] <fwereade_> niemeyer, hm, maybe, rog's suggested changes might make me able to do that clearly
[16:31] <niemeyer> fwereade_: I may be on crack.. so don't bother too much.. I'll do a more careful review on the logic once you're happy with it
[16:31] <fwereade_> niemeyer, still worth a look
[16:32] <fwereade_> niemeyer, cheers
[16:34] <fwereade_> niemeyer, I'm not sure that'd work tbh -- the timeout in awaitDead wouldn't really play nicely with everything else
[16:34] <fwereade_> niemeyer, or maybe I just can't see it :)
[16:34] <niemeyer> fwereade_: How's that any different from the timeout on awaitAlive?
[16:34] <fwereade_> niemeyer, what timeout?
[16:35] <niemeyer> fwereade_: The same that exists on awaitDead.. why is there a timeout on one and not the other?
[16:35] <fwereade_> niemeyer, the timeout is ony useful for detecting the case when updates have stopped
[16:35] <niemeyer> fwereade_: Why?
[16:35] <niemeyer> fwereade_: This isn't rhetorical, btw.. you may be right.. I'm brainstorming.
[16:36] <fwereade_> niemeyer, there's no timeout on awaitAlive because we don't need to do anything weird to support getting back a create/change at somepoint in the future
[16:36] <fwereade_> niemeyer, there's a timeout on awaitDead because that's the only way I could see to tell when a watch *hasn't* fired
[16:36] <niemeyer> fwereade_: How do I wait for an agent to come live?
[16:37] <fwereade_> niemeyer, ...call AliveW and wait for the channel to fire if it wasn't already alive?
[16:38] <niemeyer> fwereade_: Ok, sorry, I misunderstood what you meant by timeout then
[16:38] <fwereade_> niemeyer, ah, sorry :)
[16:38] <rog> back
[16:39] <rog> niemeyer: i'm thinking that all the logic becomes simpler if we assume that the node exists before starting.
[16:40] <rog> niemeyer: so rather than deleting the node at the end, we'd just set it to empty
[16:40] <niemeyer> rog: How can we assume it exists?
[16:40] <fwereade_> rog, even if we did, who would delete the node in the end?
[16:41] <rog> niemeyer, fwereade_: the node doesn't exist in isolation, surely? it's part of a larger zk structure that represents something, no?
[16:41] <niemeyer> rog: Sorry, I'm out of context and don't know what you're trying to say
[16:41] <niemeyer> rog: The node is within zookeeper.. it's not part of any structure
[16:42] <rog> niemeyer: i'm talking about a directory structure within zk
[16:42] <fwereade_> rog, I can see how it could work for machine nodes, but making it work for unit relation nodes is giving me a headache
[16:42] <niemeyer> rog: The node is within zookeeper.. it's not part of anything else, as far as the presence package is concerned
[16:42] <fwereade_> rog, and besides, I'd far prefer to make foo responsible for communicating foo's status without anyone else's help
[16:42] <niemeyer> fwereade_: It shouldn't make a difference
[16:43] <rog> niemeyer: that's fine. i'm just thinking that the initial waiting for the node to come into being can be done outside the presence package.
[16:43] <fwereade_> niemeyer, it's not creation that makes my head hurt so much as it is deletion
[16:43] <niemeyer> fwereade_: The presence node is context-less.. the package needs to know a path where it's supposed to exist, and it can assume that the parent exists, but nothing else.
[16:43] <niemeyer> fwereade_: What's the issue with creation?
[16:43] <fwereade_> niemeyer, there isn't one
[16:44] <niemeyer> fwereade_: There isn't one what?
[16:44] <fwereade_> niemeyer, an issue with creation
 niemeyer, it's not creation that makes my head hurt so much as it is deletion
[16:44] <niemeyer> fwereade_: Ah, I inverted the sentence
[16:44] <rog> fwereade_: why's deletion an issue? deletion would mean the node becomes dead as now.
[16:44] <niemeyer> fwereade_: You mean deletion is the problem.. what's the issue with deletion?
[16:45] <rog> fwereade_: (for instance when the containing directory and its children is deleted)
[16:45] <fwereade_> rog, niemeyer: who is responsible for it, and how do they arrange it with the unit agent, which may be behind schedule and have a bunch of other hook queued up before it can actually process a departure
[16:46] <rog> fwereade_: responsible for what?
[16:46] <fwereade_> rog, deleting the node
[16:46] <fwereade_> rog, I presume we don't want to keep nodes around forever just because something once used it
[16:47] <rog> fwereade_: the caller of the presence package. the idea is that responsibility for the node's creation and deletion is up to the caller.
[16:47] <rog> fwereade_: the presence package would purely manage pings on an existing node.
[16:47] <rog> fwereade_: i may be smoking more crack than usual, of course.
[16:47] <niemeyer> fwereade_: You only have to worry about it in the sane cases.. e.g. if Kill() is called
[16:47] <niemeyer> fwereade_: If there's a hard crash and the agent dies, there will be a bunch of trash around those nodes that has to be collected
[16:48] <niemeyer> fwereade_: The original code is obviously unable to do with it, since it may have gone forever
[16:49] <niemeyer> rog: The presence package should delete the node in the case where the call site is requesting the pinger to die in a way that notifies watchers
[16:49] <fwereade_> niemeyer, ok, unstated assumption: without a good reason, the same thing should handle creation and deletion. sane?
[16:49] <rog> fwereade_: yes
[16:49] <TheMue> niemeyer: i've got no prob dropping readCharm() and let Service use State directly. but in this case to keep it consistent i would like to change all entities from getting the ZK conn from state now to getting the State itself.
[16:49] <rog> niemeyer: i'd just set the contents to empty to do that
[16:50] <niemeyer> rog: No reason, I believe.. removal is a pretty good way to flag it
[16:50] <rog> niemeyer: rather than deleting the node.
[16:50] <TheMue> niemeyer: so i would change it in Machine, Unit and the now comming new ones too
[16:50] <fwereade_> rog, ok, but you're saying that (1) *something* unstated should create the node in the first place, and that other *something* should delete it at the end, and we shouldn't have a Kill (or at least not one that deletes the node)
[16:50] <fwereade_> rog, what would that something be?
[16:50] <niemeyer> TheMue: Yes, that's a good idea, but please do it in a follow up tiny branch that does just that
[16:50] <niemeyer> TheMue: Rather than piling up the unrelated change
[16:51] <rog> niemeyer: the nice thing about assuming that the node already exists is that you have some sanity check on whether it might ever change in the future, which we don't for a non-existent path.
[16:51] <TheMue> niemeyer: ok, this will be only the first step with Charm
[16:51] <TheMue> niemeyer: and Service ;)
[16:51] <niemeyer> rog: I don't understand what's the advantage. I agree with fwereade_.
[16:52] <niemeyer> rog: You seem to be saying that the nice thing about having someone else creating the node is that someone else has to do exactly the same logic that would otherwise be done inside the presence node, which to me makes no sense.
[16:52] <fwereade_> rog, yeah, niemeyer put it better than I managed
[16:53] <rog> i think i'm saying that other things know how to wait for existence (and that can imply other things too), but the pinger is the place that does keepalives.
[16:54] <rog> but i don't mind too much. it was just an idea.
[16:55] <niemeyer> rog: Still don't see what you mean.. the pinger is the thing that knows how to deal with a presence node to ping it, and that includes creation.
[16:55] <niemeyer> fwereade_: Btw, let's call StartPing as StartPinger os StartPinging.. StartPing feels weird
[16:55] <rog> niemeyer: it *can* include creation, but i don't think it has to.
[16:55] <rog> niemeyer: NewPinger seems ok to me...
[16:55] <niemeyer> rog: No, we can have a better interface as well and move things out of it
[16:55] <niemeyer> rog: and then we have a pinger that doesn't know how to ping.
[16:56] <niemeyer> fwereade_: Ok.. let's please have creation within the pinger.. there's no real argument that I can see to not do it.
[16:56] <rog> fair enough
[16:56] <fwereade_> niemeyer, I'm happy with that :)
[16:56] <niemeyer> fwereade_: And StartPinger, please..
[16:57] <fwereade_> niemeyer, possible convention counterargument: time.NewTimer, time.NewTicker
[16:58] <rog> fwereade_: given that this is the presence package, i was just wondering if the "p" prefix is useful in pstate? just type state might be fine. and it makes the capitalisation less awkward.
[16:58] <niemeyer> fwereade_: Let's please use Start.. New lacks the idea that this is going to be alive doing something rather than just creating an object
[16:59] <rog> niemeyer: NewTicker??
[16:59] <niemeyer> rog: I didn't name this one
[16:59] <fwereade_> niemeyer, fair enough
[16:59] <rog> niemeyer: it's seems a fine precedent to me, but there y'go. lots of New* functions create active things.
[17:00] <niemeyer> rog: I'm comfortable enough to improve existing conventions
[17:00] <jimbaker> hazmat, g+ mtg?
[17:00] <rog> niemeyer: i really don't think that's a great improvement. it's easier to remember when things stick to existing conventions.
[17:02] <niemeyer> rog: Sorry, let's move on
[17:02] <fwereade_> rog, I'm about to poke at pstate with a view to possible removal anyway :)
[17:02] <rog> do we have to use StartX for anything that invokes a goroutine?
[17:02] <rog> sorry, i'll stop
[17:02] <niemeyer> rog: When the next case shows up, we'll talk.
[17:03] <hazmat> jimbaker, sounds good
[17:03] <jimbaker>  hazmat, cool, just invite<EMAIL_ADDRESS>[17:03] <hazmat> hmm.. invites out
[17:05] <hazmat> niemeyer, fwereade_, rog meeting time?
[17:05] <niemeyer> hazmat: Already joining
[17:06] <fwereade_> hazmat, noone here, I'll try again
[17:29] <wrtp> total failure
[17:30] <wrtp> niemeyer: i'm back online (on my apple, cos my laptop seems to have forgotten it can connect to a wireless network) and the hangout is full
[17:30] <wrtp> niemeyer, fwereade_, TheMue: so i guess you can tell me what went on :-)
[17:30] <niemeyer> wrtp: Oops :(
[17:31] <wrtp> niemeyer: i've no idea what's up with the laptop. it keeps on asking me for passwords (it should have them stored in the keyring) and doesn't connect anyway
[17:31] <wrtp> niemeyer: it's been funny all day in fact. rebooting didn't help.
[17:33] <wrtp> anyone got a handy hint for diagnosing ubuntu wireless connectivity problems?
[17:34] <Aram> you use network manager?
[17:54] <rog> it seems to be working again, woo
[18:02]  * robbiew had to bail
[18:09] <hazmat> niemeyer, fwiw.. no bugs i can see log of hooks/scheduler.py http://pastebin.ubuntu.com/854310/
[18:10] <niemeyer> hazmat: http://paste.ubuntu.com/854315/
[18:10] <niemeyer> 111 looks like a fix
[18:11] <niemeyer> 127 too
[18:12] <niemeyer> 157 too
[18:12] <hazmat> niemeyer, what's that a log of?
[18:12] <niemeyer> hazmat: juju/hooks/
[18:13] <hazmat> niemeyer, that's quite a bit more than the scheduler we where speaking of
[18:13] <niemeyer> hazmat: If you touch just scheduler.py, you won't get anywhere close to cleaning things up in the way I was talking about
[18:14] <niemeyer> hazmat: scheduler.py is a very particular interface that only makes sense with everything else in there
[18:14] <niemeyer> 202 is a fix too
[18:16] <niemeyer> 286 also
[18:17] <niemeyer> 312, 315, and 451..
[18:18] <niemeyer> Yeah.. all of that is a side effect of a new code base being polished.. change the code base significantly, and these may not show up again, but others will..
[18:22] <rog> right guys, i'm off now
[18:22] <rog> see ya tomorrow!
[18:23] <niemeyer> rog: Have a good evening
[18:23] <rog> niemeyer: and you
[18:23] <niemeyer> Cheers
[18:23] <hazmat> niemeyer, its clear we where talking about two different things, risk from a change, vs rewriting an implementation
[18:24] <niemeyer> hazmat: risk from (...) rewriting an implementation
[18:26] <niemeyer> hazmat: This is a gut suggestion.. I wouldn't rewrite one of the trickiest parts of an application that is working two months before a release that is supposed to be rock solid
[18:26] <niemeyer> hazmat: Your take
[18:26] <TheMue> back again
[18:34] <hazmat> niemeyer, its not clear you have the context on the problem or the solution that's under consideration.. your just pointing out an entire package of code, saying its had so many fixes and its tricky, be careful and don't touch it, while your saying how a rewrite will simplify things.  yes change is a risk for stability, and in some cases not fixing a bug is the right call, but this is a fairly straight small forward change... and the change as i exampled i
[18:34] <hazmat> s to a part of the code that has been fine since day one... effectively its fixing a bug in a completely different package by adding a feature to the correct place.
[18:35] <niemeyer> hazmat: We're talking across each other indeed..
[18:35] <niemeyer> hazmat: In the call, I pointed out what I'd like to do in Go, and you said it might be doable in Python too. I said it was a significant change for this point in time. That's what I'm talking about still.
[18:36] <niemeyer> hazmat: I'm not suggesting you don't fix a bug.
[18:37] <niemeyer> hazmat: In fact, I don't think I ever said anything close to "not fixing a bug is the right call".
[18:37] <niemeyer> In this context, of course.. in some cases it is the right call, surely.
[18:42] <hazmat> niemeyer, yeah.. i'm not considering rewriting that package, just fixing the bug.. the only rewrite at this point that's worth considering is the relation ephermal node watches via  a backport of the pinger
[18:42] <niemeyer> hazmat: Phew.. we agree, after all :)
[19:32] <TheMue> niemeyer_: when can i expect the zookeeper fix? or is it just again a tag problem?
[19:35] <niemeyer_> TheMue: Tip is fixing, and the branch just has to be merged
[19:36] <niemeyer_> TheMue: I can do that right after the current meeting
[19:36] <TheMue> niemeyer_: great, thx
[20:10] <niemeyer_> TheMue: Submitting
[20:10] <TheMue> niemeyer_: wonderful, appreciate it
[20:16] <niemeyer_> TheMue: Done
[20:29] <niemeyer_> I'm heading out for some exercising.. probably back later


[00:24] <seb128> night
[02:13] <TheMuso> c/
[07:38] <pitti> Good morning
[07:38] <didrocks> good morning o/
[07:47] <pitti> kenvandine: FYI, setting WIs in https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-empathy-indicator back to TODO, and instead moving the entire spec
[07:52] <baptistemm> good morning
[09:09] <chrisccoulson> good morning everyone
[09:11] <pitti> hey chrisccoulson
[09:12] <chrisccoulson> hey pitti, how are you?
[09:20] <pitti> chrisccoulson: Je suis bon, merci!
[09:29] <rickspencer3> hi chrisccoulson
[09:29] <rickspencer3> bonjour mon ami
[09:29] <chrisccoulson> hi rickspencer3 - how are you?
[09:29] <rickspencer3> chrisccoulson, pretty well
[09:30] <rickspencer3> chilling with pitti and didrocks
[09:30] <rickspencer3> watching them work out of the corner of my eye while I surf facebook and play tetris
[09:30] <rickspencer3> it's important to have good managers
[09:30] <didrocks> :-)
[09:30] <chrisccoulson> lol :)
[09:30]  * pitti rubs the whip cracking blisters on his back
[09:32] <chrisccoulson> are you all having lots of fun at the sprint?
[09:33] <chrisccoulson> (except for pitti of course, with the blisters on his back) ;)
[09:33] <rickspencer3> chrisccoulson, so far so good, yes
[09:33] <chrisccoulson> awesome:)
[09:33]  * rickspencer3 is writing a blog post about it atm
[11:31] <seb128> hey
[11:31] <chrisccoulson> hey seb128
[11:46] <TeTeT> asac: do you have time for another nm related question? If I have more than one connection, which one is set as default route? Can I control this somehow? Or disable this multi-homed environment at all?
[11:46] <TeTeT> asac: well, actually more like 3 questions ...
[11:58] <asac> TeTeT: ethernet > wireless  > 3G ... you can try to manually add routes in the IPv4Settings tab of connections and use metrics for the default route to achive that
[11:59] <asac> i am not sure if the metrics trick still work, but it did at some point in the past
[11:59] <asac> let me know
[11:59]  * hyperair wonders what do metrics do for routes
[12:02] <TeTeT> asac: can you do that programmically via d-bus?
[12:03] <asac> TeTeT: you can do everything through dbus
[12:03] <asac> that is possible ,)
[12:04] <asac> but it might be complex
[12:04] <TeTeT> asac: is there any documentation for the API?
[12:07] <asac> TeTeT: i dont think so. but i might be wrong. you can introspect dbus APIs for NM using d-feet
[12:07] <TeTeT> asac: d-feet?
[12:10] <TeTeT> asac: how to use that? I see nm-applet there, but no object paths or alike
[12:11] <TeTeT> asac: ah, have to go to system bus it seems
[12:11] <asac> yes
[12:13] <asac> TeTeT: in the source there is ./docs/NetworkManager\ DBUS\ API.txt
[12:13] <asac> check that
[12:13]  * asac thinks that should be packaged
[12:13] <asac> i am not sure how up-to-date or accurate that is maintained
[12:14] <asac> but before doing this, first try if the metrics trick helps
[12:14] <TeTeT> asac: awesome, thanks
[12:15] <asac> TeTeT: the normal way is to disconnect from the ethernet connection (there is a button now in applet) if you dont want it to have the main traffic
[12:17] <TeTeT> asac: ok, I wait for the customers use case to see if they really need to toggle this routing manually
[12:18] <asac> kk
[12:31] <TeTeT> asac: thanks for your help :)
[12:32] <asac> np
[12:57] <huats> hello everyone
[13:15] <rodrigo_> any idea why NetworkManager says my eth0 device is not managed? and how can I set it to manage it?
[13:19] <pitti> rodrigo_: does it appear in /etc/network/interfaces ?
[13:22] <rodrigo_> pitti, I added it by hand
[13:22] <rodrigo_> seems the installation didn't detect it
[13:30] <rodrigo_> pitti: no, after rebooting it still says it's not managed
[13:44] <pitti> chrisccoulson1: hey
[13:44] <chrisccoulson1> hey pitti
[13:45] <pitti> chrisccoulson1: just as a heads-up for boot speed
[13:45] <pitti> it looks like we can change the plan to move the 10s target to UNE
[13:45] <pitti> chrisccoulson1: which seems easier to do, since we have fewer applets, fewer processes (like no nautilus desktop rendering), and more code under our control (UNE launcher)
[13:46] <chrisccoulson1> so, the 10s target will not apply to the standard desktop?
[13:46] <pitti> chrisccoulson1: so the main targets are now gconfd and panel speed up
[13:46] <pitti> chrisccoulson1: I don't think we will be able to meet it TBH
[13:46] <chrisccoulson1> UNE still uses gnome-session and g-s-d doesn't it?
[13:46] <pitti> panel speedup will benefit both desktops, but there's still nautilus/themes/fonts/etc.
[13:46] <pitti> chrisccoulson1: it does
[13:47] <chrisccoulson1> yeah, i can still look at some other desktop components to help speed it up
[13:47] <pitti> chrisccoulson1: http://piware.de/tmp/unity-full.png
[13:47] <chrisccoulson1> but at least the gnome-session, g-s-d and gconf work i've done will be beneficial for UNE
[13:47] <pitti> chrisccoulson1: so, I have some thoughts about those and would like to run them by you if you have a minute?
[13:48] <pitti> chrisccoulson1: so, you have changes in the pipe for g-s and g-s-d to start in parallel with gconf, right?
[13:48] <pitti> chrisccoulson1: for gconfd my idea was as follows:
[13:48] <chrisccoulson1> pitti - can do (although, i might need to hide the chat window occasionally)
[13:48] <pitti> - pull gvariant into glib (once Ryan confirms that it's scheduled to land in the near future)
[13:48] <pitti> chrisccoulson1: heh, boss mode? :-)
[13:49] <pitti> - rip out /var/lib/gconf/defaults/%gconf-tree.xml
[13:49] <pitti> - replace it with a gvariant serialization file
[13:49] <pitti> if gvariant is out of the question for some reason, we could also investigate how fast sqlite is
[13:49] <pitti> but parsing a 2.2 MB XML file which has mostly noise is just crack
[13:49] <pitti> do you think that's too crackful?
[13:50] <chrisccoulson1> pitti - yeah, it's quite extreme. i wonder how much benefit we'd get by ripping out all the comments
[13:50] <pitti> chrisccoulson1: there are no comments?
[13:50] <chrisccoulson1> that seems a lot of work with gvariant though. some of the work i've already done works around the long gconf delays
[13:51] <pitti> ah, so you think it will then just interleave with the other delays, and not be an issue any more?
[13:51] <chrisccoulson1> i did some work to parse the gconf tree in parallel with other things, so that it doesn't delay the whole session from starting
[13:51] <pitti> note that we still need to change the startup to launch all programs at the same time, instead of the current serialization
[13:51] <pitti> (right now, most programs start 4 seconds into the session
[13:52] <chrisccoulson1> pitti - i'd be a bit nervous about removing the current serialization, as we might introduce weird race conditions and other issues
[13:53] <chrisccoulson1> for example, there are things that g-s-d must do before anything else loads, else you can create extra X round-trips etc
[13:53] <chrisccoulson1> i'd prefer to try and optimise the current serialization rather than remove it
[13:53] <pitti> well, that's why we need to do it soon
[13:53] <chrisccoulson1> eg, it might be possible to start the panel and WM at the same time
[13:53] <pitti> seb128 played around with that already; did you notice race conditions with that?
[13:54] <seb128> (reading backlog)
[13:54] <chrisccoulson1> i haven't played around with starting everything together yet, but i just wanted to point out that it might cause issues for some people
[13:55] <pitti> seb128: wrt. introducing race conditions when starting everything in parallel instad of serializing
[13:57] <kenvandine> hey tedg
[14:01] <pitti> chrisccoulson1: back (sorry, spoke with Seb); he said that it didn't cause any obvious regressions, and it starts everything aruond 1.2 seconds in
[14:01] <chrisccoulson1> pitti - as an example, i think at-spi-regsitryd needs to set up some things in the environment before anything else loads (although i can't verify that for sure whilst i'm at work), which is why it is started in the initialization phase
[14:02] <pitti> yeah, right
[14:02] <chrisccoulson1> if it doesn't do that before other components load, then it might break assistive technology for some people
[14:02] <pitti> chrisccoulson1: for seahorse-daemon, do you think it's possible to fork, export the env, and then do the real initialization?
[14:02] <pitti> this seems to be the other major blocking step
[14:03] <chrisccoulson1> pitti - i think it already does that, but i need to investigate that still
[14:03] <chrisccoulson1> it would need to set the environment before forking, and then doing the real initialization though
[14:04] <chrisccoulson1> as once gnome-session has moved from initialization, it doesn't allow you to change the environment (the dbus method will return an error if you try to do it)
[14:05] <tedg> Morning kenvandine
[14:06] <seb128> hey tedg
[14:07] <pitti> chrisccoulson1: right, that's what I was proposing
[14:08] <pitti> chrisccoulson1: is that SSH_AGENT_PID/GPG_AGENT_INFO etc.?
[14:08] <pitti> it seems to me that you could create those sockets and determine their pids/values without much inintialization
[14:09] <pitti> chrisccoulson1: of course could couldn't actually talk to them in the first 0.5 seconds after session startup, but who cares..
[14:09] <chrisccoulson1> pitti - i've got a feeling those 2 variables are set by ssh-agent and seahorse-agent, which load from a Xsession.d script
[14:10] <kenvandine> hey stormy_
[14:10] <chrisccoulson1> seahorse-agent really should be a proper session agent, but it's not on the default install anyway
[14:10] <stormy_> hey kenvandine
[14:12] <pitti> chrisccoulson1: hm, I think that gap is actually just gconf
[14:13] <pitti> the delay is trivial on http://people.canonical.com/~seb128/bootchart/seb128-dellmini-lucid-20100106-hacked.png (which has the "start all in parallel" stuff)
[14:13] <chrisccoulson1> pitti - the 0.5s gap after gnome-session starts is mostly gconf
[14:13] <chrisccoulson1> but i've got a fix for that already
[14:14] <chrisccoulson1> pitti - that trace is with my g-s-d, gconfd and gnome-session patches
[14:14] <pitti> chrisccoulson1: right
[14:14] <pitti> that's the -hacked charts
[14:15] <pitti> chrisccoulson1: 1006-hacked is your changes plus seb's "one phase" change
[14:15] <chrisccoulson1> pitti - that chart is also with the packages from here: http://people.ubuntu.com/~chrisccoulson/desktop-startup-speed/
[14:15] <pitti> chrisccoulson1: right
[14:15] <pitti> great job with those!
[14:16] <seb128> chrisccoulson1, do you know if g-s-d needs to start first?
[14:17] <chrisccoulson1> seb128 - yeah, g-s-d needs to start first really, to set up the xrandr stuff, and the theme as well
[14:21] <seb128> chrisccoulson1, is xrandr doing anything if there is no config change?
[14:21] <seb128> the g-s-d code I mean
[14:22] <seb128> on a stock install it should do nothing and let xorg the way it is no?
[14:22] <chrisccoulson1> seb128 - good question. i'll have a look later and see what it actually does if there is resolution change needed
[14:24] <pitti> chrisccoulson1: I think we could tell by looking whether we have an xrandr configuration file?
[14:24] <seb128> I'm wondering what seahorse-daemon is actually doing
[14:24] <seb128> seahorse-agent is the one doing gpg agent
[14:25] <pitti> chrisccoulson1: i. e. don't run it unless we have a .config/monitors.xml?
[14:25] <chrisccoulson1> pitti - yeah, that might be possible
[14:25] <pitti> chrisccoulson1, seb128: so, we need to coordinate who is doing what now
[14:25] <pitti> AFAICS we have
[14:25] <seb128> I'm doing the one phase change
[14:25] <pitti> 1) speed up gnome-panel (sit down for a week) -- probably robert_ancell, need to confirm
[14:26] <pitti> 2) start everything at once -- seb128
[14:26] <pitti> 3) speed up gconfd loading -- I could look into that
[14:26] <pitti> 4) land the gconf dependency reduction changes -- chriscoulson
[14:26] <TeTeT> asac: any chance that nm 8.1 will land in lucid? a customer is interested in the additional bluetooth phone capabilities. A PPA with 8.1 might be sufficient
[14:26] <seb128> 5) investigate seahorse
[14:26] <pitti> 5) not launch xrandr if we don't have a conf file
[14:27]  * pitti defers to being 6)
[14:27] <seb128> 7)...
[14:27] <pitti> seb128, chrisccoulson1: ^ does that look complete and sane to you?
[14:28] <seb128> 8) profit?
[14:28] <seb128> yes
[14:28] <pitti> I think sabdfl wants to claim 8) :)
[14:28] <chrisccoulson1> sounds good to me
[14:28] <sabdfl> me too
[14:28] <pitti> all these changes will speed up gnome and UNE
[14:29] <pitti> just that it might be enough for UNE, while desktop still suffers from more applets, nautilus desktop rendering, compiz, etc.
[14:29] <pitti> while on UNE we have mutter, no nautilus desktop, fewer panels, etc.
[14:29] <pitti> chrisccoulson1: are you interested in 5) ?
[14:29] <chrisccoulson1> pitti - yeah, i'll look at 5 too
[14:30] <seb128> chrisccoulson1, pitti: you rock
[14:34]  * pitti hugs chrisccoulson1
[14:34] <pitti> I'll update the work items now to get an updated plan
[14:35] <pitti> chrisccoulson1: your changes were for g-s-d and gnome-session, right?
[14:38] <chrisccoulson1> sorry, i had to disappear to get coffee there
[14:38] <chrisccoulson1> i have a lot of people hovering around my desk ;)
[14:39] <chrisccoulson1> pitti - my changes were for gconf, gnome-session and g-s-d
[14:39] <pitti> chrisccoulson1: thanks
[14:41] <pitti> chrisccoulson1, seb128: I updated the WIs on https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-startup-speed -- does that look ok to you?
[14:43] <chrisccoulson1> pitti - looks ok. the only comment about the g-s-d WI though, is that the change is to load as much as possible without needing gconf
[14:43] <chrisccoulson1> currently, that's only xrandr, as it's the only plugin that doesn't store any settings in there
[14:44] <pitti> chrisccoulson1: ah, I see; hm, that means once we eliminate xrandr we won't have a benefit from that any more?
[14:44] <pitti> or does it do other stuff as well?
[14:45] <chrisccoulson1> we will still probably load the xrandr plugin, but i'll see if we can reduce the number of X calls for setting up the display configuration, if there is no stored configuration
[14:46] <chrisccoulson1> i'll look in to that though anyway
[14:48] <seb128> does xrdb work in a dynamic way?
[14:49] <seb128> would be nice to delay that one too
[14:49] <chrisccoulson1> seb128 - i was just asking if we even need xrdb?
[14:50] <seb128> we do for openoffice
[14:50] <seb128> the xrdb code is off by default
[14:50] <seb128> the xrdb call we have is from the xsettings option
[14:50] <seb128> and asac had to add fixes there for openoffice previous cycle
[14:50] <seb128> which indicates it's really useful
[14:52] <chrisccoulson1> ah, ok.i didn't realise the xrdb plugin was off by default actually
[14:52] <chrisccoulson1> i was just reading http://mces.blogspot.com/2008/10/improving-login-time-part-1-gnome.html
[14:52] <chrisccoulson1> i think you sent me that link didn't you?
[14:55] <seb128> cassidy, what would be useful to debug a "can't reconnect to icq" error?
[14:56] <seb128> chrisccoulson1, yes
[14:56] <cassidy> seb128, haze logs
[14:56] <cassidy> see http://live.gnome.org/Empathy/Debugging
[14:57] <seb128> 'CI
[14:57] <seb128> 'ic
[14:57] <seb128> can't type!
[14:57] <seb128> 'ci
[14:57] <seb128> cassidy, haze is not in empathy debug dialog
[14:57] <cassidy> yeah it doesn't implement the debug iface
[14:57] <cassidy> so you have to do it old style
[14:58] <seb128> bah
[14:58] <seb128> if I restart empathy that will work
[14:58] <seb128> I already got the issue
[14:58] <seb128> it fails to reconnect but connect fine after a restart
[14:58] <seb128> thanks anyway
[15:16] <rickspencer3> kenvandine, hi, did you see my last dent?
[15:23] <seb128> kenvandine, sorry I forgot to review your and upload your xchat indicator
[15:23] <seb128> I will do that today
[15:23] <kenvandine> thx
[15:23] <kenvandine> no worries
[15:24] <kenvandine> rickspencer3, woot!
[15:28] <rickspencer3> kenvandine, so soon I need to start pulling feeds in
[15:35] <rickspencer3> kenvandine, http://theravingrick.blogspot.com/2010/01/tonights-photobomb-feature.html
[15:35] <seb128> hey desrt
[15:35] <rickspencer3> there's my microblogging UI
[15:35] <rickspencer3> I suppose the title is maybe a bit silly
[15:38] <kenvandine> rickspencer3, cool, can you make that a separate widget we can include in gwibber?
[15:38] <desrt> seb128: hi =)
[15:39] <rickspencer3> kenvandine, yeah, just grab the .ui and .py files
[15:39] <rickspencer3> in other words, it's already a separate widgets
[15:40] <kenvandine> great
[15:41] <rickspencer3> kenvandine, does gwibber already use .ui files?
[15:41] <kenvandine> now it does :)
[15:41] <rickspencer3> it's a simple dialog, so I could just code the layout
[15:41] <kenvandine> the accounts UI does
[15:41] <rickspencer3> ok
[15:41] <kwwii> seb128: does lucid have the nice new tooltips (from RH I guess)?
[15:41] <seb128> kwwii, no
[15:42] <seb128> mclasen, ^ did the fedora tooltip changes went to GNOME?
[15:42] <seb128> I didn't notice any change in 2.29 I think
[15:43] <didrocks> vuntz: do you think that if /apps/panel/general/toplevel_id_list is mandatory, it's possible that the fact there is no applet showing up  at the first launch is related to a writing issue? (if I unlock it, run gnome-panel, and then relock it, I have my applets in subsequents launch)
[15:44] <kwwii> seb128: http://ubuntuforums.org/showthread.php?t=1310730 seems to imply they did make it into gtk
[15:45] <seb128> kwwii, so maybe the theme or something needs to use that
[15:46] <kwwii> seb128: hrm, ok..I'll look into it some more, thanks for the help
[15:50] <seb128> kwwii, https://bugzilla.gnome.org/show_bug.cgi?id=599618
[15:50] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=599617
[15:50] <seb128> https://bugzilla.gnome.org/show_bug.cgi?id=599617
[15:53] <seb128> kwwii, so not upstream in git
[15:53] <seb128> upstream in bugzilla
[15:53] <kwwii> seb128: hrm, can we apply that patch?
[15:53] <seb128> which one?
[15:53] <seb128> round corner?
[15:53] <seb128> the positionning one?
[15:53] <kwwii> mainly the positioning one but the rounding would be nice too
[15:53] <seb128> I would like to check with mclasen if he plans to land that upstream first though
[15:53] <kwwii> ;)
[15:53] <kwwii> ok, sounds good...thanks for the help
[15:54] <seb128> np
[15:54] <seb128> can you open a bug on launchpad for those?
[15:54] <seb128> so it doesn't slip from our list of things to do
[15:56] <seb128> davmor2, not sure why you opened that evolution bug
[15:56] <seb128> could you try asking slangasek rather?
[15:56] <seb128> I think I did advice you to do that before you opened the bug
[15:57] <seb128> it's not evolution's fault if ubiquity removes it on installs
[15:57] <seb128> which it doesn't there on the install I did today btw
[15:57] <davmor2> seb128: slangasek fixed it, it happened because 3 or 4 locales still used the evo-doc-locale file which removed evo
[15:58] <seb128> could you close the bug then?
[15:58] <seb128> thanks
[15:58] <davmor2> seb128: sorry I thought slangasek had when he fixed it
[16:06] <tseliot> pitti: would something like this work well for you? http://pastebin.ubuntu.com/356117/
[16:06] <vuntz> didrocks: hrm, didn't know that, but it might not be a big surprise
[16:06] <vuntz> the code might consider nothing is writable if one key is not
[16:07] <didrocks> vuntz: should be that so, I'll try to find a workaround
[16:08] <pitti> tseliot: yes, looks fine; however, it might be that we need transitional packages and versioned conflicts/replaces
[16:08] <pitti> tseliot: we should test the upgrade
[16:08] <tseliot> pitti: right, which is why I suggested that we use transitional packages yesterday
[16:09] <pitti> tseliot: on a normal system where jockey is already installed, it should work fine
[16:09] <pitti> tseliot: you'd just need them on a system where envy is installed, but jockey isn't
[16:09] <tseliot> pitti: a corner case but still worth testing
[16:16] <vuntz> didrocks: or you can fix the bug :-)
[16:19] <seb128> hello vuntz
[16:19] <seb128> how are you?
[16:25] <vuntz> seb128: I'm sad. Snow is melting here :/
[16:25] <vuntz> ;-)
[16:25] <vuntz> seb128: I see you're having fun with login performance
[16:26] <seb128> indeed
[16:26] <seb128> it's rather down to gconf and gnome-panel being slow now
[16:26] <seb128> do you think gnome-panel could do async applets loading?
[16:27] <vuntz> seb128: it's supposed to be async already
[16:27] <seb128> hum
[16:27] <vuntz> note the "supposed" :-)
[16:27] <seb128> what robert_ancell observed seems to indicate it's buggy
[16:27] <seb128> ;-)
[16:27] <seb128> nice to see you clean gnome-panel btw
[16:29] <chrisccoulson1> vuntz - you like the snow?
[16:29] <seb128> I like the snow too
[16:29] <seb128> when it doesn't make me miss my train
[16:29] <seb128> like today!
[16:30] <chrisccoulson1> heh
[16:30] <chrisccoulson1> i don't mind the snow, but i don't like taking 3 hours to get to work ;)
[16:30] <chrisccoulson1> it took me 1.5hours this morning
[16:31] <vuntz> chrisccoulson1: snow is amazing!
[16:31] <vuntz> chrisccoulson1: it just makes the world a better place!
[16:31] <chrisccoulson1> vuntz - did you build a snowman? :)
[16:32] <rickspencer3> snow is great, when it's in the mountains where it belongs ;)
[16:32] <seb128> vuntz, you spend your days playing in the snow? ;-)
[16:32] <vuntz> chrisccoulson1: I didn't think about it, actually. Maybe next time...
[16:32] <vuntz> rickspencer3: you know, before you said that, I used to respect you. :-)
[16:32] <chrisccoulson1> yeah, snow does make everything look quite nice. especially where i live - it's normally fairly dull and grey, but the snow brightens everything up :)
[16:32] <fagan> the snow is almost gone in ireland
[16:32] <fagan> :(
[16:33] <rickspencer3> vuntz, you don't ski or snowboard?
[16:33] <rickspencer3> I visit the snow the every weekend, it does not need to visit me
[16:33] <vuntz> heh
[16:33] <vuntz> rickspencer3: ski, but only a bit. I never tried snowboard
[16:33] <vuntz> I just like the atmosphere when there's snow
[16:34] <seb128> people being stucked in cars for hours? ;-)
[16:34] <rickspencer3> vuntz, come to Seattle in the winter, I will show you snow (where it belongs in the mountains ;) )
[16:34] <seb128> you watch them from you chair since you don't need to go to work? ;-)
[16:34] <vuntz> seb128: well, of course, the fact that I don't need to take a car/bus/train to work helps ;-)
[16:34] <rickspencer3> and we can ski on it, as intended
[16:34] <seb128> hehe
[16:35] <chrisccoulson1> vuntz - driving a car to work sucks in the snow ;)
[16:35] <chrisccoulson1> i've spent too much time this week in my car
[16:36] <vuntz> chrisccoulson1: you could also choose to not go to work. I mean, if you really hate being in the car... ;-)
[16:37] <chrisccoulson1> vuntz - it did cross my mind, but i'm more professional than that ;)
[16:37] <vuntz> of course, at some point, you'd have to stop eating too, since you wouldn't be able to buy food
[16:37] <fagan> oh rickspencer3 photobomb is awesome any chance it will replace fspot hehe
[16:37] <chrisccoulson1> some of my colleagues stayed at home though
[16:37] <rickspencer3> fagan, I think it already has
[16:37]  * rickspencer3 checks seeds
[16:37] <rickspencer3> hmmm not yet, probably tomorrow
[16:38] <fagan> rickspencer3: hah it is growing quickly though (I stress the word quickly hehe)
[16:38] <rickspencer3> fagan, goocanvas is quite awesome
[16:38] <rickspencer3> and plus segphault has lots of useful code for me to snipe ;)
[16:39]  * fagan needs to get said useful code
[16:40] <rickspencer3> fagan, $bzr branch lp:grabbersnap
[16:40] <rickspencer3> I did the micro-blogging with the Gwibber API of course
[16:40] <fagan> rickspencer3: thanks
[17:24] <chrisccoulson1> right, home time :)
[17:59] <seb128> hate this libmozjs thing
[18:00] <seb128> gjs is broken in lucid and I can't figure why
[18:00] <seb128> gjs is broken in lucid and I can't figure why!
[18:00] <seb128> ups lag
[18:00] <seb128> ldd lists libmozjs.so twice
[18:00] <seb128> once correctly and one not found too
[18:17] <njpatel> didrocks,  process_workspace_switch_grab  in src/core/keybindings.c
[18:24] <didrocks> njpatel: thanks
[18:33] <chrisccoulson> hey didrocks
[19:32] <crb> Hi.  I have a machine running Karmic and I am trying to disable Compiz.
[19:33] <crb> I go to Appearance, last tab, select None for desktop effects; Metacity launches
[19:33] <crb> and next reboot I'm back to "Normal" and Compiz.
[19:33] <crb> Is the choice of WM still dictated by a gconf key?
[19:51] <djsiegel> asac: hey, just wanted some more info about removing OOo from UNE
[19:52] <djsiegel> is it being removed or replaced or neither?
[19:53] <asac> djsiegel: removed and then we see how well we can integrate gdocs as a first step
[19:53] <djsiegel> asac: oh, ok
[19:53] <asac> thats armel UNE btw
[19:53] <asac> cant speak for the rest
[19:54] <asac> djsiegel: for email we do something similar: check out: https://blueprints.edge.launchpad.net/ubuntu/+spec/mobile-lucid-arm-webservice-for-email
[19:54] <asac> thats a bit better understood
[19:54] <asac> e.g nicely integrated
[19:54] <asac> would be happy to get your feedback
[20:37] <crb> anyone, re compiz/metacity?\
[20:48] <tseliot> crb: what paroblem?
[20:49] <tseliot> problem
[23:55]  * crimsun is pleased that PA is shaping up nicely for 10.04
[23:56] <crimsun> also, I'll write up the SRU for the p_udev leak shortly
[23:57] <asac> \o/


[00:39] <xnox> sergiusens: did you see bug #1290492 ?
[00:46] <sergiusens> xnox, I haven't... and qmake :-/
[00:48] <xnox> =(
[00:49] <sergiusens> xnox, from what I've been seeing, the sdk hard codes a bunch of stuff all around
[01:17] <infinity> tvoss: Why does dbus-cpp force g++-4.7 (which doesn't exist on ppc64el)?
[01:27] <ScottK> cjwatson: Thanks for mentioning git-dpm the other day.  I think I finally found the tool that makes sense to me.
[03:12] <sarnold> does anyone know off-hand what the deal is with minidlna? upstream renamed the package, I can't find if there is a new debian package, and our trusty minidlna package has been deleted but I can't find a readymedia package..
[03:13] <rww> "lp #1253071, FTBFS, RC buggy, removed from Debian testing, not ported to libav9" per https://launchpad.net/ubuntu/+source/minidlna/+publishinghistory
[03:55] <sarnold> rww: thanks! :)
[05:26] <pitti> Good morning
[05:27] <pitti> SpamapS: well, the py version of juju is gone, isn't it? I suppose it could be reactivated (and I really wish it was..), but we certainly shouldn't support *two* versions
[05:30] <SpamapS> pitti: I should restate. It's unlikely I'll be running juju any time soon. :-P
[05:30] <pitti> SpamapS: ah :)
[05:34] <Unit193> Anyone got a link to the bash completion problem in files with spaces?
[05:35] <sarnold> Unit193: I've seen these two so far: https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031  https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1290572
[05:40] <Unit193> "file Hogans\ Heroes/Hogans\ Heroes\ Season\ " and it stop there, it's not quite either because if there's more than one one file it'll complete up to the diff, then stop and won't pick back up.
[05:43] <sarnold> Unit193: is that the behaviour controlled by show-all-if-ambiguous ?
[05:43] <Unit193> Shouldn't be, defaults used to be fine.
[05:45] <sarnold> something seems pretty broken anyway
[05:46] <Unit193> Yeah, I'm holding off the other upgrade, tab complete is too important to me. :P
[05:46] <sarnold> the amount I've used my trusty vms so far I've only noticed that it doesn't work as I'm used to. heh.
[05:47] <sarnold> the last time I looked into doing anything with tab completion I got the simple cases done alright but the harder stuff was .. well, harder. I found my head going around in circles while trying to read the more complicated examples.
[05:47] <sarnold> I'm glad it's not me on the line to fix it :) "everyone downgrade to saucy's bash" wouldn't go over real well. :D
[05:48] <Unit193> Hah, that's what I did with some python package to fix gcalcli. :P
[06:53] <pitti> barry: yay, 3.4~rc3 looks much happier now, thanks!
[07:30] <mitya57> pitti: hi, can you please check what happened to dh-python autopkgtest? update_excuses.html says it's "running" since yesterday, and there is no entry for ubuntu4 upload on public Jenkins.
[07:31] <pitti> hey mitya57; looking
[07:32] <pitti> mitya57: the run was started, but yay jenkins hiccup :( /me restarts
[07:32] <mitya57> Danke!
[07:38] <pitti> Finished: SUCCESS
[07:38] <pitti> mitya57: thanks!
[07:38] <pitti> trusty-adt-dh-python-ppc64el now works, too
[07:39] <mitya57> Nice :)
[08:34] <Ademan> For security fixes, is there any hierarchy among LTS releases? (latest LTS gets patch, eventually gets backported to next latest LTS)
[08:38] <pitti> Ademan: usually all releases get fixed at the same time
[08:41] <Ademan> pitti: thanks
[09:17] <Saviq> mardy, hey, there seems to be an issue with signon-ui and google accounts with SSO, it asks me for the google password, which effectively doesn't exist with SSO... I had the account working before, but seems it got unauth-ed for some reason, and I can't reconnect now because of that, any ideas?
[09:55] <warren> Is anyone familiar with the /etc/init/*.conf files?  I'm trying to exec a command as a non-root user and define a command that runs to stop it.
[09:58] <RAOF> warren: You're probably looking for the upstart cookbook?
[09:58] <warren> I see it
[09:58] <warren> I see post-stop
[09:58] <warren> but that doesn't seem to be exactly what I want
[09:59] <RAOF> You want non-root users to be able to start/stop the service?
[09:59] <warren> no
[09:59] <warren> I want to exec /path/to/program as a certain non-root user
[09:59] <warren> and I want to "killall -u nonrootusername" on stop.
[10:00] <warren> someone suggested "exec sudo -u nonrootusername /path/to/program"
[10:00] <warren> I suppose that works.
[10:01] <RAOF> Ah, yeah. That'd be right.
[10:01] <warren> pre-start and post-stop appears that it would work for the killall
[10:01] <warren> but there's no command to define stop?
[10:01] <RAOF> No; stop is SIGTERM
[10:02] <warren> ok, then I want pre-start and post-stop
[10:02] <RAOF> (Or whatever you set kill signal to)
[10:03] <RAOF> You probably want pre-stop, then. Otherwise your thing will already have been sent SIGTERM.
[10:04] <warren> It's a thing that launches another thing that launches another thing ...
[10:04] <warren> i didn't write it, I'm just packaging it
[10:05] <RAOF> So it does its own process supervising? :)
[10:06] <warren> yeah, and killall -u is good enough ...
[10:08] <warren> RAOF: thanks
[10:15] <tsdgeos> what's wrong with bash? i get an error just by tabbing in an empty window :S
[10:16] <tsdgeos> do you guys get that?
[10:17] <tsdgeos> bash: words: bad array subscript
[10:17] <seb128> tsdgeos, bug 1289597
[10:17] <seb128> it has a sponsoring request as well
[10:19] <seb128> tsdgeos, you can nag ogra_ or RAOF about sponsoring I guess, they are supposed to be piloting
[10:19] <seb128> or janimo or rbasak
[10:19] <tsdgeos> i wonder if that fixes the other billions of regressions i have in tab handling
[10:19] <tsdgeos> probably not
[10:20] <tsdgeos> i am half productive since my tab broke
[10:20] <seb128> tsdgeos, I guess the other ones are https://bugs.launchpad.net/ubuntu/+source/bash-completion/+bug/1288031
[10:20] <tsdgeos> that one and also https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553
[10:22] <seb128> blame doko for uploading the new bash after ff without a ffe and then going on holidays letting stuff buggy
[10:22] <seb128> he's back next week though, I hope he's going to have a look then
[10:22] <tsdgeos> wonder if i should add bash-completion to https://bugs.launchpad.net/ubuntu/+source/bash/+bug/1290553 too
[10:22]  * tsdgeos does
[10:23] <seb128> I'm pondering reverting the bash update meanwhile, since that's a new version that was uploaded without ffe approval and which introduced regressions
[10:36] <cjwatson> ScottK: yay
[10:57] <xnox> seb128: well i presume other people would notice as well. I see a thread on gnu.bash.bug which seems to believe it might be a bug in bash-completion.
[10:58] <seb128> xnox, "other people would notice as well"? you mean?
[10:59] <xnox> seb128: as in, it's a bug that i'm expecting to have a hotfix somewhere quick.
[10:59] <seb128> xnox, let's see, we have the issue for over a week though
[11:00] <seb128> xnox, it also doesn't change the fact that the new bash was uploaded without a ffe
[11:01] <cjwatson> There's https://code.launchpad.net/~j/bash-completion/bug1289597/+merge/210089 FWIW
[11:01] <xnox> seb128: i see a bug filed in launchpad 13h ago, and threads on upstream mailing list very recent, less than a week ago.
[11:02] <seb128> xnox, I've no doubt it's going to be fixed, I'm not sure what we are arguing about there?
[11:02] <seb128> cjwatson, yeah, I pointed that to tsdgeos earlier, we just need a patch pilot to do a shift and pick it up for sponsoring ;-)
[11:03] <xnox> seb128: "I'm pondering reverting the bash update meanwhile" i don't like reverts, especially when people are working to resolve things. Short term it might be quicker to revert, but in the long run it's a waste of resources to not just fix it properly without reuploading revert of the revert.
[11:04] <seb128> xnox, well, that was a feature update without a ffe
[11:04] <seb128> which is buggy as well
[11:05] <xnox> seb128: sure, but uploading reverts is not a solution to the problem - e.g. as to why ffe process was not respected.
[11:06] <seb128> xnox, just waving hands and saying it's ok to not respect the process is not a solution either
[11:06] <seb128> but let's not argue about it
[11:06] <seb128> doko is not even there :p
[11:07] <xnox> seb128: cjwatson: so executing "complete -r" makes the completion as per bug report work.
[11:07] <xnox> but i'm not sure what that does, and whether that's suppose to be called from bash postinst?!
[11:08] <cjwatson>       -r        remove a completion specification for each NAME, or, if no
[11:08] <cjwatson>         NAMEs are supplied, all completion specifications
[11:08] <xnox> cjwatson: right, so bash is not broken.
[11:08] <cjwatson> can't possibly be called from bash postinst, it's a shell builtin
[11:08] <cjwatson> I mean, can't usefully be called.  it won't magically affect other shells ...
[11:09] <cjwatson> I would expect that "complete -r" basically just makes the current shell act as if bash-completion weren't installed
[11:10] <seb128> xnox, btw, are you in the office today? ;-)
[11:10] <xnox> seb128: are you?
[11:10] <xnox> seb128: i was in, yesterday but not today. Do you need people in the office poked?
[11:10] <seb128> xnox, no, but mpt upgraded saucy to trusty and has a non booting machine, just plytmouth and nothing
[11:11] <seb128> xnox, I was trying to figure out who could help him
[11:11] <xnox> seb128: =((( he should have upgraded yesterday. cjwatson, jodh and I were in the office.
[11:11] <seb128> yeah :/
[11:11] <xnox> seb128: the office support is on holliday today...
[11:12] <seb128> he started the upgrade yesterday, but has an old laptop with a slow disk, upgrade takes ages
[11:14] <xnox> cjwatson: seb128: bash-completion appears to fix completion bugs for me. Let me test it more here.
[11:48] <tkamppeter> OdyX, hi
[11:50] <pitti> jamespage: is juju-local something which the server team supports and wants bug reports for?
[11:51] <pitti> jamespage: it falls over quite hard trying to bootstrap containers in current trusty, on bind-mounting the log directory AFAICS (and apparently also on LXC's cgroup warnings, although this could be a red herring)
[11:52] <pitti> jamespage: or is it deliberately in universe, and a community project?
[12:03] <jamespage> pitti, it is
[12:06] <rbasak> @pilot in
[12:11] <rbasak> lp:ubuntu/precise/charm-tools appears to have some extra commits on top of the version of charm-helpers that is in precise. I didn't even know this was possible. What's the appropriate action here? Blow it away by uploading the SRU I want, instead? Will that somehow break UDD?
[12:17] <OdyX> tkamppeter: I fixed the permissions now, should be okay.
[12:30] <tkamppeter> OdyX, thanks, everything pushed.
[12:31] <OdyX> tkamppeter: yay, will upload shortly
[12:38] <rbasak> jdstrand: please could you take a look at: https://code.launchpad.net/~sdeziel/ubuntu/precise/xl2tpd/fix-for-lp1244780/+merge/194247
[12:40] <rbasak> jdstrand: I'm unhappy to upload because 1) there are three patches, but the bug implies one and the changelog entry describes two; and 2) I'm unfamiliar with the package, and the test case isn't detailed enough for me to follow it. But for my latter objection, I appreciate that this is one of those interop things that needs an affected user to do the SRU verification anyway, and clearly Simon will be able to do it, so it's only a weak objection.
[12:40] <rbasak> jdstrand: I'd appreciate your opinion. If you think it's good, I can test and upload as-is.
[12:41] <rbasak> sdeziel: ^^
[12:47] <jdstrand> rbasak: I agree with your '1'. I think the changelog is too terse and it would be much easier for reviewers if the changelog described everything better
[12:47] <jdstrand> rbasak: as for '2'-- me too
[12:48] <jdstrand> rbasak: that said, excepting the changelog being too terse, the other issues I mentioned have all been addressed it seems
[12:49] <jdstrand> rbasak: tbh, I think that the changelog should be updated and dch -r ran before uploading since the sru team is going to have all the same questions we had when reviewing it
[12:52] <rbasak> jdstrand: should I JFDI (fix the changelog and upload)? I'm never sure what to do in this kind of case - I don't want to modify Simon's entry yet still leave his signature.
[12:52] <rbasak> (OTOH, I don't want to use mine and take his credit away)
[12:52] <rbasak> And I don't want to have to make him go and fix it first, either.
[12:53] <jdstrand> rbasak: I've fixed changelog entries to make them more clear and adjusted timestamps in these situations. if you understand the patches, then sure, makes sense. just mention it in the MP
[12:54] <jdstrand> let me rephrase-- if you understand the patches well enough to make the changelog clear for the sru team, then sure
[12:54] <rbasak> jdstrand: OK. Thank you for your help!
[12:54] <jdstrand> np
[12:55] <jdstrand> (seems one of the comments in the MP makes it fairly clear)
[12:58] <jamespage> rbasak, technically that is possible (branch being used outside of packages) but its unusual
[12:59] <rbasak> jamespage: OK. I'm planning to just upload over the top, since I don't expect those other changes to land anyway (and there's nobody to drive that now)
[13:00] <rbasak> Laney: would you mind reviewing Gunnar's response at https://mentors.debian.net/package/mythes-sv please? I don't have a Debian hat, but it seems to me that the issues are the same for Ubuntu.
[13:00] <rbasak> I'm not sure about there being no licence in the source apart from in debian/copyright, even though I understand the notice can from an external source.
[13:00] <rbasak> And same for preferred form for modification, and the generated thing in the upstream source.
[13:29] <ogra_> cjwatson, urgh, susie just upgraded her laptop (14.04) and grub seems to be gone now
[13:29] <ogra_> i end up in win8
[13:31] <cjwatson> Check she doesn't have -proposed enabled
[13:31] <cjwatson> I haven't done a matching grub2-signed for the latest upload yet
[13:31] <cjwatson> Though it's also in unapproved for amd64, so probably not that
[13:31] <ogra_> i cant get into ubuntu at all
[13:31] <ogra_> i cant even intercept the boot anymore
[13:32] <ogra_> and i'm 100% she doesnt have proposed ... she only does auto updates, all other maintenance is done by me
[13:32] <cjwatson> I think realistically you'll have to figure out something locally with the aid of a rescue image or something before I have any chance at all of helping
[13:32] <ogra_> iirc xnox has the same device ....
[13:33]  * ogra_ cant even get into UEFI anymore ...
[13:33] <ogra_> sigh !
[13:33] <ogra_> worst time for that to  happen
[13:34] <cjwatson> Sorry.  I don't think it's a systemic problem, though, it's not something I've heard other complaints about so far ...
[13:34] <cjwatson> And 2.02~beta2 has been in trusty for a while
[13:35] <ogra_> well, she only accepted the reboot u-m offered her after an auto update
[13:37] <cjwatson> Is the system strange in any other way?
[13:38] <cjwatson> I suppose it could be https://bugs.launchpad.net/ubuntu/+source/efibootmgr/+bug/1272664
[13:38] <infinity> ogra_: I assume you can boot a live image to investigate further?
[13:38] <cjwatson> But I can only guess wildly
[13:39] <Laney> rbasak: I'm on me hols now, so I won't be able to get to that until next week (sorry Gunnar)
[13:39] <Laney> rbasak: But yes, I think the issues are the same
[13:39] <ogra_> infinity, i could but need to do some errands before diving into UDS :P
[13:39] <Laney> debian/copyright can document the state even if it's not in the orig tarball
[13:39] <ogra_> cjwatson, infinity, so the BIOS was apparently re-set
[13:40] <Laney> rbasak: He pointed to another package - you could check if that has only the generated files or the inputs too
[13:40] <Laney> and it doesn't matter if you don't have Debian upload rights; you can still do a review which will be useful for the person who does come to upload it
[13:42]  * ogra_ finally got into the bios ... the EFI order was re-shuffled for whatever reason
[14:03] <OdyX> tkamppeter: uploaded 1.0.47-1 now and prepared cups for oldstable and cups-filters for stable. AFAIK cups in lucid is affected through debian/local/filters/pdf-filters/pdftoopvp and cups-filters is affected in all Ubuntu releases.
[14:59] <rbasak> infinity: would you mind reviewing/uploading dannf's MP in https://code.launchpad.net/~dannf/ubuntu/trusty/flash-kernel/m400/+merge/208705 for flash-kernel please? ltgm, I also trust dannf anyway, and it's yellow in the queue.
[14:59] <rbasak> (I haven't tested it or anything)
[15:00] <rbasak> (I presume this is one of the ones that relatively few sponsors will be comfortable uploading)
[15:00] <dannf> rbasak: thx
[15:00]  * dannf meant to poke about that today
[15:01] <infinity> rbasak: Yeah, can look in a sec.
[15:02] <rbasak> Thanks!
[15:02] <Logan_> morning, all :)
[15:03] <jamespage> pitti, juju is still in MIR so its all in universe
[15:06] <rbasak> @pilot out
[15:14] <infinity> tvoss: *poke*
[15:38] <jcastro> barry, FYI: https://bugs.launchpad.net/charms/+bug/1199052
[15:41] <barry> jcastro: sweet
[16:01] <pitti> jamespage: ah, seems it's due to me not using /var/lib/lxc, so not affecting the default case; I filed it as bug 1290920 anyway
[16:02] <jamespage> pitti, ack
[17:25] <bdmurray> jibel: I was looking at bug 1286161 again and tried to restore the clone file and it failed badly
[17:47] <ogra_> pitti, did anyone talk to you about the ofono-phonesim dbus issues we had while you were away (and the .crash files we get in the dailer-app tests due to that) ?
[17:58] <pitti> ogra_: no, not so far
[17:58] <ogra_> oh
[17:59] <ogra_> pitti, since the switch to py3 we get tracebacks for many of the ofono scripts during testing
[17:59] <pitti> ogra_: ah, interesting; is there a bug for it?
[17:59] <ogra_> xnox worked around two of them but there is something more essential broken it seems so we stopped there
[17:59] <pitti> ogra_: UDS session now, TTYL
[17:59] <ogra_> pitti, same here :)
[18:00] <ogra_> just wanted to know if you had been pointed to it already, we can talk tomorrow :)
[18:01] <xnox> pitti: i did file a bug against apport.
[18:01] <xnox> pitti: after the double-hangout we can quickly chat about it =)
[18:03] <ogra_> xnox, tomorrow is enough too ... it will be late already after the double HO :)
[18:05] <mdeslaur> tkamppeter: do you have an example command line I can use to test pdftoopvp?
[18:09] <tkamppeter> mdeslaur, no, but I can ask Tim Waugh who has sent me the info about the vulnerabilities.
[18:11] <mdeslaur> tkamppeter: I just want to make sure it works, not necessarily test the exact security issue
[18:11] <mdeslaur> tkamppeter: I don't know what to specify as opvpDriver=
[18:13] <Wellark> hmm.. guys, how do I get this landed? https://code.launchpad.net/~kaijanmaki/connectivity-api/ci-testrun/+merge/202958
[18:13] <Wellark> the project is not in the archives yet
[18:14] <Wellark> I just need to get that MR to the trunk
[18:14] <Wellark> then after that I need the trunk to be included in universe
[18:14] <Wellark> this is unity8 dependencies so AFAIK there is a top level FFe in place
[18:48] <juliank> pitti: I'm a bit confused. You wrote in bug 1288171 that python-apt fails on some pyflakes tests. We run those tests during the build, and all builds were successful (and thus, pyflakes ran successfully on the build servers), so I wonder what's happening.
[18:55] <juliank> It's really strange that our tests run succesfully during the build on both Debian & Ubuntu, and the same tests fail in different ways when running from autopkgtests.
[19:01] <pitti> juliank: yeah, indeed; I have a closer look tomorrow morning
[19:01] <pitti> (UDS session ATM)
[19:02] <pitti> juliank: https://jenkins.qa.ubuntu.com/job/trusty-adt-python-apt/72/ARCH=amd64,label=adt/console
[19:02] <pitti> juliank: perhaps during build you don't run tests/old/ ?
[19:02] <pitti> juliank: and in debian http://ci.debian.net/#package/python-apt it's differently broken
[19:03] <juliank> pitti: They are not run, never. We run exactly the same tests during build and autopkgtest. The test tests/test_pyflakes.py fails, on autopkgtest, but not during the build.
[19:03] <juliank> But better get back to that UDS session then...
[19:03] <pitti> juliank: oh, but pyflakes might see tests/old/ and complain about those
[19:04] <juliank> pitti: Right, and we filter them out in our test_pyflakes.py script, and do not pass them to pyflakes.
[19:04] <pitti> juliank: ok, no off-hand idea without a closer look; I'll check tomorrow morning
[19:04] <juliank> OK, thanks.
[19:51] <molgrum> sorry if this is the wrong channel but it seems like a dev question, is radeon.dpm=1 planned to be enabled by default any time soon or is it too experimental yet?
[19:56] <pitti> xnox: to resume, you filed a bug against apport for the ofono python3 conversion?
[19:56] <pitti> xnox: oh, you mean bug 1287628?
[19:57] <pitti> xnox: I'll have a look at that tomorrow
[19:57] <pitti> ... or Thursday, given patch pilot/UDS/etc.
[19:58]  * pitti waves good night
[19:59] <xnox> pitti: that's a fix to tests in dialer-app, yes.
[19:59] <xnox> pitti: the "python3-apport not catching python2 crashes bug" is bug #1287659
[23:12] <xnox> upgraded from bad corsair vengeance memory to corsair beast. Didn't do benchmarks yet, but it appears to be faster and more stable \o/
[23:12]  * xnox is happy on my desktop again.


[11:05] <lyr> Hey. Since formatting my laptop from ubuntu budgie 20.04 to xubuntu 21.04 minimal setup, my bluetooth became a bit flaky. Like disconnection/reconnection every hours. Does that ring a bell to anyone ? Is there a setting to increase reliability ?
[23:17] <tomreyn> lyr: search the web for bluetooth coexistence and wireless / bluetooth power saving
[23:17] <tomreyn> also try asking this in #ubuntu instead if you can't get a reply here, since this question would refer to the foundation, which is the same for ubuntu and xubuntu.


 @ilyaishere, Yes, we build with only one OpenGL variant. It is GL ES on arm and desktop OpenGL on everything else.
 Do you say that your device is x86 but has GL ES? I never heard of such.
 @mitya57, Yeah, that's Intel's SoC
 So I'm afraid you have to build Qt itself. Or use some kind of online installer if you find one for your configuration.
 @ilyaishere, If you tell me your device model, then maybe we'll discuss this in Debian.
 @ilyaishere, That's just the default Ubuntu (GNOME). Kubuntu still provides i386 images.
 @mitya57, I have Intel Clovertrail+, in my case - in ASUS ZenFone 5
 @ilyaishere, Ok, thanks


[12:45] <cmaloney> morning
[12:48] <jrwren> Good Morning
[12:48] <jrwren> How are you today?
[12:50] <cmaloney> ok, but my car decided our plans for us
[12:50] <cmaloney> so get to take it in tomorrow
[12:50] <cmaloney> (yay)
[12:51] <cmaloney> we were going to go to Ann Arbor to see Kip Thorne but JoDee doesn't trust our cars
[12:51] <cmaloney> so instead we are going to the zoo
[12:51] <cmaloney> (plan as it stands)
[12:52] <cmaloney> you?
[12:55] <jrwren> :(
[12:56] <jrwren> I can imagine a Lyft ride from there to AA would be $%$$$   what about Zipcar/Maven?
[12:56] <jrwren> I'm doing well enough.
[12:56] <jrwren> Busy at work. Trying to get enough exercise to stay healthy. Trying to find time between those things to read and relax enough. Its life.
[12:57] <cmaloney> jrwren: no worries. just would have been nice to see one of JoDee's heroes
[12:58] <cmaloney> yeah, i can jnderstand that
[13:05] <rick_h> jrwren: heh it's hard!
[13:05] <rick_h> cmaloney: :( on the cars
[13:06] <jrwren> rick_h: i honestly don't know how people do it.
[13:06] <rick_h> jrwren: with ya, I've been saying I was going to go downstairs once I hit the lul in the day all week so far
[13:07] <rick_h> and by the time I get done with work, cleaning, dinner, cleaning more, responsible adult things 1,2,3...wtf it's bed time
[13:07] <rick_h> rough this week with the wife's birthday today so much of the adult things was birthday cards/cake/wrapping/etc
[13:07] <rick_h> but seems like always something
[13:09] <jrwren> It IS always something.
[13:10]  * rick_h is crabby due to knee recovery so grains of salt and all that
[13:15] <cmaloney> rick_h: No worries. Thanks
[13:15] <rick_h> cmaloney: zoo is always a good place to go though
[13:15] <rick_h> cmaloney: how did MUG go?
[13:15] <jrwren> Especially Detroit Zoo. So nice.
[13:16] <cmaloney> Pretty good
[13:16] <cmaloney> Had a good Android talk at the beginning
[13:16] <cmaloney> Android Things
[13:16] <rick_h> The wife loves the one we went to at PyOhio. She still raves about it.
[13:16] <cmaloney> Then I riffed on virtualenv
[13:16] <jrwren> o_O riffed?
[13:17] <cmaloney> Yeah, I am trying to get a presentation series called "Pain Points"
[13:19] <jrwren> ah. nice.
[13:19] <jrwren> virtualenv used to be a pain point. Then i figured out how it all fits together and now it's just another tool
[13:21] <cmaloney> Yeah, that's one of the things with this
[13:21] <cmaloney> I know a lot of folks who don't quite understand how it all fits together
[13:22] <jrwren> sounds great.
[13:22] <cmaloney> so I sat with my laptop and talked about virtualenv
[13:22] <cmaloney> Yeah, it was kind of neat
[13:22] <cmaloney> But it was also supposed to be a seed so others feel free to say "Hey, I know a little bit about  X and can talk about it"
[13:22] <cmaloney> We have a second slot that can't support another large topic
[13:23] <jrwren> right. Cool.
[13:23] <cmaloney> so rather than do something like lightning talks or fishbowl I'd like to make it more productive
[13:23] <cmaloney> rick_h: Happy Birthday Erica! :)
[13:25] <rick_h> cmaloney: happy birthday to you :P
[13:25] <rick_h> cmaloney: hah, I didn't realize it but got her new jogging headphones for her b-day with some other stuff
[13:25] <rick_h> cmaloney: so I guess headphones is the official birthday gift of 2017
[13:27] <jrwren> oh yeah, happy birthday cmaloney
[13:29] <cmaloney> <3
[13:29] <cmaloney> rick_h: Those headphones are awesome. THank you.
[13:29] <rick_h> cmaloney: well someone smart picked them out :P
[13:30] <cmaloney> Heh
[14:02] <jrwren> what kind?
[14:10] <cmaloney> Westone UM pro 10s
[14:11] <cmaloney> Partly because I thought they were the only in-ears that were made in the USA
[14:15] <jrwren> never heard of the brand.
[14:15] <jrwren> how much does the breathing and heartbeat come through?
[14:20] <cmaloney> https://octodon.social/@craigmaloney/6472748
[14:20] <cmaloney> Depends. I put on the silicone tips so it doesn't block out as much
[14:21] <cmaloney> but there are foam tips you can use
[14:21] <cmaloney> they give you about a dozen pairs of tips
[14:22] <cmaloney> Or rather about a dozen tips in there
[14:22] <cmaloney> (not pairs)
[14:22] <cmaloney> but still, S M L XL and one other in Silicone and foam
[14:22]  * cmaloney can do math
[14:23] <cmaloney> The UMs are monitors so they have a flat response
[14:23] <cmaloney> the 10s are single driver, but they have multiple driver ones as well