[00:11] <davecheney> niemeyer: thanks for your review
[00:11] <niemeyer> davecheney: My pleasure
[00:12] <davecheney> the reason the firewaller watches the environ is I imagined that would be how it woudl talk to the (unknown) firewalling service
[00:12] <davecheney> as the Environ in this case represents ec2
[00:12] <davecheney> niemeyer: in the pythonic version, the provider managed openport/closeport
[00:13] <niemeyer> davecheney: Duh.. it is obvious indeed, sorry
[00:14] <davecheney> niemeyer: well, the facility doesn't exist on environ, yet
[00:14] <niemeyer> davecheney: Which facility?
[00:15] <davecheney> open port/close port
[00:15] <davecheney> it's there in goamz
[00:15] <davecheney> but there is no generic interface in environs
[00:16] <niemeyer> davecheney: Ah, I see, yep
[00:17] <niemeyer> davecheney: It kind of sucks that we'll have to redo this soon to be machine-based
[00:17] <niemeyer> davecheney: But it seems like the right thing to do, rather than get into a trip in unknown territory before we actually get things working at all
[00:18] <davecheney> niemeyer: right o
[00:18] <davecheney> niemeyer: i'm going to raise a bug on juju-core to define the open port / close port interface on environ
[00:18] <davecheney> if that is ok
[00:18] <niemeyer> davecheney: E.g. if we moved onto the machine agent, we actually have to watch relations too, at the machine level, so that we alter the firewall allowing them to go in and out
[00:19] <niemeyer> davecheney: Sounds great
[00:19] <niemeyer> davecheney: Thanks
[00:19] <davecheney> niemeyer: the reason it's a new type, not an addition to the Provisioner, was a hope that the service could be moved between agents
[00:19] <davecheney> but i don't know how realisitic that will be
[00:19] <niemeyer> davecheney: I love the fact you splitted it out
[00:20] <niemeyer> davecheney: It was a bad decision on the original implementation
[00:20] <niemeyer> davecheney: Even if we can't move it as-is, we can move something, or we can even erase it by itself if nothing else
[00:20] <davecheney> yup
[00:25] <niemeyer> davecheney: Hmm
[00:25] <niemeyer> davecheney: I don't think we should allow the environment name to change
[00:26] <niemeyer> davecheney: We that value internally in the environment itself
[00:26] <niemeyer> We use
[00:26] <davecheney> niemeyer: ok, i'll do it another way
[00:26] <niemeyer> davecheney: E.g. security groups
[00:26] <davecheney> it wasn't being set at all
[00:26] <niemeyer> davecheney: It feels slightly bad that we do this
[00:26] <niemeyer> davecheney: It would be better to have that as an external property of the environment
[00:27] <niemeyer> davecheney: But it's helpful to tell the user about what those machines he's running are about
[00:27] <davecheney> niemeyer: the current thing that is blocking bootstrap is there are no tools in my s3 bucket
[00:27] <davecheney> i can't see anything to generate those
[00:27] <niemeyer> davecheney: Oh
[00:27] <davecheney> 012/06/27 10:27:45 JUJU findTools searching for {{0 0 0} precise amd64} in []
[00:27] <davecheney> error: cannot start bootstrap instance: cannot find juju tools that would work on the specified instance: no compatible tools found
[00:28] <niemeyer> davecheney: bootstrap -upload-tools?
[00:28] <niemeyer> davecheney: bootstrap --upload-tools?
[00:28] <niemeyer> davecheney: I think you're right, though
[00:29] <niemeyer> davecheney: We do need to set the environment name, at least once
[00:29] <davecheney> 2012/06/27 10:28:50 JUJU environs: putting tools tools/juju-0.0.0-precise-amd64.tgz
[00:29] <davecheney> niemeyer: i'll find a nicer way to do it
[00:29] <niemeyer> davecheney: I feel like your CL is a good step forward, actually
[00:29] <niemeyer> davecheney: I'm probably mixing problems up
[00:29] <niemeyer> davecheney: We should prevent the user from replacing the name, but that's not the way to do it
[00:30] <davecheney> niemeyer: the name is an unfortunately property that comes out of the yaml file
[00:31] <niemeyer> davecheney: I'll file a bug, and LGTM your change
[00:31] <davecheney> niemeyer: ta, just a small cosmetic i found
[00:31] <niemeyer> davecheney: This may well be what's preventing it from running
[00:32] <davecheney> 2012/06/27 10:31:34 JUJU environs/ec2: started instance "i-acd0d3d5"
[00:35] <davecheney> niemeyer: dude, it bootstrapped !
[00:35] <niemeyer> davecheney: Woah!
[00:35] <davecheney> niemeyer: i'm going to pull this branch apart into smaller pieces, but i think it's working
[00:35] <davecheney> no idea if there is a PA at the other end yet
[00:35] <davecheney> also, juju status would be nice to have :)
[00:35] <niemeyer> davecheney: +1 :)
[00:36] <davecheney> niemeyer: time for a celebratory cup of tea
[00:36] <niemeyer> davecheney: Feel free to start looking at it actually, if you ever get blocked/bothered
[00:36] <niemeyer> s/bothered/bored/
[00:36] <davecheney> niemeyer: ok
[00:36] <davecheney> niemeyer: i'm not going to step on franks toes ?
[00:36] <davecheney> screw it, i'll just email juju dev and claim it
[00:38] <davecheney> niemeyer: 2012/06/27 10:34:27 JUJU environs: putting tools tools/juju-0.0.0-precise-amd64.tgz
[00:38] <davecheney> error: cannot upload tools: cannot write file "tools/juju-0.0.0-precise-amd64.tgz" to control bucket: Your socket connection to the server was not read from or written to within the timeout period. Idle connections will be closed.
[00:38] <davecheney> ^ kinda unreliable, but that is australia for ya
[00:38] <davecheney> maybe i'll try a different availability zone
[00:38] <niemeyer> davecheney: Definitely not stepping on Frank's.. he's not looking at status ATM
[00:38] <davecheney> sorry, william
[00:38]  * davecheney facepalm
[00:39] <niemeyer> davecheney: That error was kind of weird
[00:39] <niemeyer> davecheney: I don't think anyone is doing status yet
[00:39] <niemeyer> davecheney: I've not seen that before.. worth investigating
[00:40] <davecheney> niemeyer: anyway, time for a break
[00:46] <niemeyer> Woohay.. new battery arrived
[00:46] <niemeyer> It's time for me to leave too
[00:46] <niemeyer> I'm late, actually
[00:46] <niemeyer> Dinner with Go folks tonight.. back later
[05:04] <davecheney> niemeyer: how was dinner ?
[05:04]  * davecheney is a tad jealous
[05:05] <niemeyer> davecheney: It was awesome indeed
[05:05] <davecheney> niemeyer: i think i figured out why juju can't bootstrap in other avail zones
[05:05] <niemeyer> davecheney: Not the full team, unfortunately
[05:05] <davecheney> niemeyer: i bet rsc wasn't there
[05:06] <davecheney> he's elusive
[05:06] <niemeyer> davecheney: Yeah, we had Rob and Andrew
[05:06] <niemeyer> davecheney: He lives elsewhere.. I bet he'd join if he was around
[05:06] <davecheney> he lives in boston right ?
[05:11] <davecheney> niemeyer: can I commit rogers branch ? or should I merge it into one I own to lbox propose ?
[05:12] <niemeyer> davecheney: The right thing would be to branch from it and continue, or possibly even break it down in smaller chunks
[05:12] <niemeyer> davecheney: Yeah, he lives in Boston, or next to it I think
[05:12] <davecheney> niemeyer: i'll try to break it into two chunks, it's only 100 lines
[05:12] <davecheney> actually less than 90
[05:13] <niemeyer> davecheney: Yeah, but it's also incomplete, right?
[05:13] <davecheney> it's very close
[05:13] <davecheney> [  102.246904] init: juju-provision-agent main process (4356) terminated with status 127
[05:13] <davecheney> [  102.246937] init: juju-provision-agent main process ended, respawning
[05:13] <davecheney> ^ jujud isn't in the path, that is pretty much the only bit missing
[05:14] <niemeyer> davecheney: I had the impression it was a spike mostly.. rog mentioned it had no testing
[05:14] <niemeyer> davecheney: I confess to not have looked into it, though
[05:15] <davecheney> he's done some tests, > 50% of the change is in livetests
[05:22] <niemeyer> davecheney: Ah, nice
[05:22] <niemeyer> davecheney: I wonder what he was referring to then
[05:23] <davecheney> maybe it was the environ name problem
[05:23] <niemeyer> davecheney: Well, you're in a much better position than I am
[05:23] <davecheney> since I fixed that it's been working pretty well for me
[05:23] <niemeyer> davecheney: Whatever you feel should go to review, I'll be happy to look at
[05:23] <davecheney> ok
[05:24] <davecheney> niemeyer: did my diagnosis of the s3 problem make sense ?
[05:25] <davecheney> niemeyer: ubuntu@domU-12-31-39-0C-58-F1:~$ pgrep jujud -lf
[05:25] <davecheney> 4539 /var/lib/juju/tools/juju-0.0.0-precise-amd64/jujud provisioning --zookeeper-servers localhost:2181 --log-file /var/log/juju/provision-agent.log
[05:37] <niemeyer> davecheney: I think it does.. it's definitely an error we'll want to fix
[05:38] <davecheney> i think it should be pretty easy to add support for that
[05:38] <niemeyer> davecheney: My surprise was with the fact Amazon refuses to take a request on a region-specific endpoint because the payload doesn't mention the region-specific endpoint name *as well*
[05:39] <niemeyer> davecheney: Woah? Provisioner running?
[05:39] <davecheney> yes, almost
[05:39] <davecheney> i think i got initzk working as well (path issues)
[05:39] <davecheney> but it's blocked waiting on the right value for /environment
[05:43] <davecheney> niemeyer: [zk: localhost:2181(CONNECTED) 2] ls /
[05:43] <davecheney> [services, charms, relations, zookeeper, initialized, machines, units]
[05:43] <davecheney> initzk worked, just missing /environment
[05:44] <davecheney> niemeyer: i don't understand why location constraint has to be xml, why can't it just be a header
[05:44] <niemeyer> davecheney: That's expected
[05:45] <niemeyer> davecheney: /environment comes from juju deploy
[05:45] <niemeyer> davecheney: Well.. it doesn't even need to be a header
[05:45] <niemeyer> davecheney: The endpoint URL itself is already a great indicator
[05:45] <niemeyer> davecheney: There's no way to be talking to that endpoint URL and not wanting to.. well.. talk to it
[05:45] <davecheney> niemeyer: i thought there was
[05:46] <niemeyer> davecheney: Kind of strange.. either a very awkward decision, or I'm missing something more interesting
[05:46] <davecheney> there is a note in one page I found that said there is a generic s3 location you can talk to
[05:46] <davecheney> but they recommend not using it, because it will internally redirect your request
[05:46] <niemeyer> davecheney: Sure, but we're not using it, AFAIK
[05:46] <davecheney> either way, it's a bit of a wart
[05:47] <davecheney> niemeyer: so, juju deploy will be responsible for keeping /environment up to date ?
[06:08] <niemeyer> davecheney: Yeah
[06:08] <niemeyer> davecheney: Well, hopefully not up-to-date
[06:08] <niemeyer> davecheney: Only the first time
[06:08] <niemeyer> davecheney: THe Python version updates it every time, but that's a mistake
[06:09] <davecheney> niemeyer: ok, so i should not make the bootstrap process seed /environment
[06:11] <niemeyer> davecheney: It's tricky because to do that we'd have to wait until the environment bootstrapped
[06:11] <niemeyer> davecheney: Chicken and egg
[06:11] <niemeyer> davecheney: We don't want to send credentials over via user-data
[06:15] <davecheney> niemeyer: right, so to confirm, the cloud-init script is not secure ?
[06:29] <niemeyer> davecheney: Right, it puts thing up in an address that can be openly accessed from within the machine
[06:40] <fwereade> niemeyer, davecheney: heyhey
[06:40] <davecheney> fwereade: howdy
[06:40] <fwereade> niemeyer, perhaps I'm missing something re: https://codereview.appspot.com/6335057/diff/3001/state/presence/presence.go#newcode397
[06:42] <fwereade> niemeyer, but it seems to me that we can only guarantee absence notifications from the watches if we don't stop the childLoops at all
[06:42] <fwereade> bah
[06:43] <fwereade> ok, I'm off to take laura to nursery
[06:45] <davecheney> yeah, i'm off soon as well
[06:54] <niemeyer> davecheney: Yo
[06:54] <niemeyer> davecheney: Please feel free to tackle the location bug if you're up for it
[06:54] <niemeyer> davecheney: I'll certainly have a low attention level in the next few days with I/O going by
[06:56] <niemeyer> Time to head to bed now
[06:56] <niemeyer> davecheney: Have a good time there, and talk to you tomorrow
[06:56] <niemeyer> Night all
[07:31] <TheMue> Morning.
[07:33] <fwereade> TheMue, heyhey
[10:45] <fwereade> TheMue, any objection to me just straight-up deleting relationUnitWatcher? after the meeting yesterday we have a better plan for doing essentially the same stuff
[10:46] <TheMue> fwereade: No problem, so I'll just don't touch it when doing the Deleted/Removed change.
[10:47] <fwereade> TheMue, I consider this trivial enough to go straight in with a cursory review; sound sane?
[10:47] <fwereade> TheMue, I'll be proposing in a couple of mins...
[10:47] <TheMue> fwereade: Does the mimic also may relate the ServiceUnitsWatcher?
[10:47] <fwereade> TheMue, sorry, can't parse
[10:48] <TheMue> fwereade: The way you will do it in future, will this be interesting for the service units watcher too?
[10:50] <fwereade> TheMue, ah sorry; I don't *think* so
[10:50] <fwereade> TheMue, I don't think that should be considering agent presence
[10:50] <fwereade> TheMue, but I may not have thought it through properly
[10:50] <fwereade> TheMue, should it?
[10:50] <TheMue> fwereade: OK, I'll take a look when you proposed it. ;)
[10:51] <TheMue> fwereade: No, it's only that both are interested in units, but in different contexts.
[10:51] <fwereade> TheMue, yeah, this is specifically unit *relation* presence
[10:51] <TheMue> fwereade: ic
[10:51] <fwereade> TheMue, (the better plan is to use the forthcoming presence.ChildrenWatcher)
[10:59] <fwereade> TheMue, https://codereview.appspot.com/6351046
[11:00] <fwereade> TheMue, should be trivial :)
[11:01] <TheMue> fwereade: LGTM, those pure red ones are pretty simple. ;)
[11:01] <fwereade> TheMue, cheers; agree ok to submit directly? :)
[11:02] <TheMue> fwereade: If the removed watcher isn't yet used then it's ok.
[11:02] <fwereade> TheMue, don't worry, I ran the tests :)
[11:02] <fwereade> TheMue, submitting now
[11:04] <fwereade> TheMue, btw, if you have another couple of moments
[11:04] <fwereade> TheMue, it seems to me that the watcher use in cmd/jujud is a bit inconsistent/idiosyncratic
[11:05] <fwereade> TheMue, I would appreciate your opinion on whether it's justified, or if we should clean it up
[11:05] <fwereade> TheMue, by which I mainly mean moving stopWatcher and mustErr into state/watcher, and using them consistently
[11:06] <TheMue> fwereade: i take a look
[11:07] <fwereade> TheMue, cheers
[11:07] <TheMue> fwereade: hmm, do you have a pointer for me?
[11:09] <fwereade> TheMue, cmd/jujud/machine.go:93
[11:09] <fwereade> TheMue, I'm pretty sure that it's wrong to let a tomb.ErrStillRunning slip through
[11:09] <fwereade> TheMue, and in line 80 we discard errors
[11:10] <fwereade> TheMue, I haven't looked at provisioner properly but I'm pretty sure it suffers similar problems
[11:12] <fwereade> TheMue, it may or may not be justifiable to rearrange NewMachiner such that it follows the usual model -- ie start the watcher before we start the loop
[11:13] <fwereade> TheMue, IMO it's a cleaner way of doing things, and is anyway better in the context of juju because it's more like the model we use throughout state
[11:13] <TheMue> fwereade: yes, this uncommon way may lead to misunderstandings
[11:13] <fwereade> TheMue, cool, I'll have a go at that; we can see what niemeyer thinks when he;s around
[11:14] <TheMue> fwereade: yes
[11:14] <TheMue> fwereade: lunchtime
[11:14] <fwereade> TheMue, cool, enjoy
[11:41] <Aram> hi.
[11:47] <fwereade> Aram, heyhey
[11:49] <fwereade> TheMue, it crosses my mind that *actually* the PA has it right wrt the watcher... there doesn't ever seem to be a good reason to create a subwatcher outside the loop
[11:50] <fwereade> TheMue, or even to keep it in a field on a, er, superwatcher
[11:51] <TheMue> re
[11:51] <TheMue> Aram: Hi
[11:52] <TheMue> fwereade: Maybe, it only puzzles me if something is different than in most/all other places.
[11:52] <fwereade> TheMue, I can't see anywhere a watcher field is used outside a loop method
[12:21] <TheMue> fwereade: Maybe it's my old OO as well as Erlang thinking that I do most initialization in a constructor and use the loop method only as loop.
[12:22] <fwereade> TheMue, IMO a field that's used in only one method should not really be a field ;)
[12:22] <fwereade> TheMue, anyway, I'm experimenting with what might be a noticeable simplification of the stuff in state/watcher.go, I'll let you know if it works out :)
[12:23] <TheMue> fwereade: But then I would not call the method loop(). I often name them backend() in my projects. ;)
[12:23] <fwereade> TheMue, I would personally gravitate towards run() :)
[12:24] <TheMue> fwereade: That's the job of the whole program: come on, run, Forrest ...
[12:24] <fwereade> TheMue, haha
[12:46] <fwereade> TheMue, making this change has made some of the state watchers start to look a bit inconsistent to me: an awful lot of them seem to me to be at risk of sending "changes" that don't actually represent changes
[12:47] <fwereade> TheMue, I rather consider that to be poor behaviour; opinion?
[12:49] <fwereade> TheMue, basically all of them seem to do what FlagWatcher did before I suggested changing it yesterday
[12:51] <fwereade> TheMue, excluding the Machine ones, that is
[12:51] <TheMue> fwereade: Hmm, maybe they should be fixed  then one-by-one in small changes.
[12:51] <fwereade> TheMue, yeah, that sounds sensible
[12:52] <TheMue> fwereade: We've done it this way for the error messages in state.
[12:52] <fwereade> TheMue, sorry, expand please
[12:52] <fwereade> TheMue, ah, how we make the changes
[12:53] <TheMue> fwereade: +1
[12:53] <TheMue> fwereade: yep
[12:53] <TheMue> fwereade: I think the should be fixed to work exactly as expeted.
[12:53] <fwereade> TheMue, cool
[12:54] <fwereade> TheMue, I need to think about what I've done a little more but it feels like a big win ATM
[12:54] <TheMue> fwereade: great
[12:54] <fwereade> TheMue, I'll see what niemeyer thinks before I start hanging more changes off it though ;)
[12:55] <TheMue> fwereade: I'm just doing the last changes for the service unit watcher. niemeyer had a very good hint how to test it more elegant.
[12:55] <fwereade> TheMue, yeah, I saw that
[12:55] <fwereade> TheMue, sounds good
[12:55] <TheMue> fwereade: it's so much clearer now.
[12:55] <fwereade> TheMue, sweet -- that style does make my head hurt a bit sometimes :)
[12:56] <TheMue> fwereade: it still uses test tables, but more simple ones
[12:57] <fwereade> TheMue, perfect
[12:57] <TheMue> fwereade: will now propose it and then start a new branch for the deleted to removed change
[12:57]  * fwereade worries that that change will be a real hassle to merge with his current work
[12:58] <fwereade> TheMue, can you wait a few mins? I'll propose what I have -wip so you can (1) tell me if it's sane and (2) decide whether the conflicts will be worth the hassle
[13:02] <TheMue> fwereade: Which change you mean, the first one or the deleted/removed one?
[13:02] <fwereade> TheMue, added/removed
[13:02] <fwereade> TheMue, (sorry, remind me what the first one is?)
[13:04] <TheMue> fwereade: The fixes after the review of the service units watcher.
[13:04] <TheMue> fwereade: They are proposed now.
[13:04] <fwereade> TheMue, I'm happy to suck up the conflicts on that one myself
[13:04] <TheMue> fwereade: The work on the deleted-to-be-named-removed will start now.
[13:05] <fwereade> TheMue, but Added/Removed might hurt
[13:05] <TheMue> fwereade: This is why I will do it in an extra branch. There are influences in more packages than just state.
[13:06] <fwereade> TheMue, true
[13:06] <TheMue> fwereade: But I'll wait for your proposal.
[13:08] <fwereade> TheMue, https://codereview.appspot.com/6347045
[13:09] <fwereade> TheMue, the reason I worry slightly is that it totally guts state/watcher.go
[13:10] <fwereade> TheMue, actually, looking at it, I doubt Added/Removed will hurt that much
[13:10] <fwereade> TheMue, but I'd still appreciate your preliminary opinion
[13:10] <fwereade> TheMue, the important bit is the changes to state/watcher.go, most of the rest can probably be a separate CL
[13:11] <TheMue> fwereade: In the moment the field is renamed in watcher.go any user of this field has to be renamed too.
[13:12] <TheMue> fwereade: So it may be better type by type instead file by file.
[13:12] <fwereade> TheMue, you mean the Added/Removed change?
[13:12] <fwereade> TheMue, my CL does not alter observable behaviour AFAICT
[13:12] <TheMue> fwereade: Yes
[13:12] <fwereade> TheMue, cool
[13:14] <TheMue> fwereade: The other one - don't raise events for unwanted content changes - is a different topic and should be discussed with niemeyer
[13:14] <fwereade> TheMue, yeah, I haven't even started on that
[13:14] <TheMue> fwereade: Maybe you should file it first.
[13:15] <fwereade> TheMue, hopefully I'll get a chance to see him and discuss it tonight
[13:15] <TheMue> fwereade: So which change of mine do you think could conflict yours?
[13:15] <fwereade> TheMue, I decided it probably wouldn't hurt too much in the end
[13:15] <fwereade> TheMue, there will be conflicts but they'll be trivial
[13:16] <fwereade> TheMue, feared they might be ugly before I looked at the actual diff
[13:17] <TheMue> fwereade: ah, ok, understand
[13:17] <fwereade> TheMue, anyway, does that change look worth it to you?
[13:18] <TheMue> fwereade: i'm not yet through, one moment
[13:20] <fwereade> TheMue, MW and MUW are not finished there
[13:20] <fwereade> TheMue, you should be able to ignore them and still have a clear idea of what's involved
[13:27] <TheMue> fwereade: Mostly LGTM, I only have troubles with the panic() in MustErr().
[13:27] <fwereade> TheMue, that was already there :)
[13:28] <TheMue> fwereade: Maybe, but not by me. ;)
[13:28] <fwereade> TheMue, the idea is that if a subwatcher's channel is closed while the watcher is reading from it, it indicates a fundamental logic error
[13:28] <TheMue> fwereade: The question is: Is this situation simply an error itself and recoverable or do we really need to tear down the program?
[13:29] <fwereade> TheMue, it means that we, as coders, are demonstrably on crack
[13:29] <fwereade> TheMue, ie not recoverable IMO
[13:29] <TheMue> fwereade: If it can't happen by any runtime situation then I'm fine with hit.
[13:29] <TheMue> it
[13:29] <fwereade> TheMue, that's the idea
[13:33] <TheMue> fwereade: This is what I really like in Erlang. Here a supervisor would recognize this crash and start the needed tasks to recover the system (which sometimes is only the restart and registration of a coroutine (process) and sometimes may be the stopping and restarting of large process trees).
[13:34] <fwereade> TheMue, but if the error is "the programmers are demonstrably failing basic logic" then I think it's better to fail hard AAP
[13:34] <TheMue> fwereade: supervisors can also supervise other ones, so it cascades if one fails during restart
[13:34] <fwereade> ASAP
[13:35] <TheMue> fwereade: yes, indeed, if it is definitely not recoverable and a logical error
[13:36] <fwereade> TheMue, if a watcher has closed its change channel while its owner is still making use of it, that is IMO evidence of fundamental crackfulness
[14:37] <mthaddon> hey folks, does anyone know who's responsible for maintaining http://jujucharms.com/ ?
[14:42] <james_w> mthaddon, that's hazmat's
[14:43] <mthaddon> james_w: ah, thx


[16:16] <blackboxsw> #startmeeting Cloud-init bi-weekly status
[16:16] <meetingology> Meeting started Mon Aug  5 16:16:04 2019 UTC.  The chair is blackboxsw. Information about MeetBot at http://wiki.ubuntu.com/meetingology.
[16:16] <meetingology> Available commands: action commands idea info link nick
[16:16] <tribaal> o/
[16:16] <blackboxsw> Heya Chris!
[16:16] <blackboxsw> Welcome to another cloud-init community status meeting folks.
[16:17]  * blackboxsw finally back from a much needed vacation and have dug myself out of backlog
[16:17] <blackboxsw> #chair rharper
[16:17] <meetingology> Current chairs: blackboxsw rharper
[16:18] <blackboxsw> cloud-init upstream uses this meeting as a platform for community updates, feature/bug discussions, and an opportunity to get some extra input on current development.
[16:18] <blackboxsw> All interjections updates and questions  welcome
[16:18] <blackboxsw> we may be a bit light this meeting as well as some folks have holidays and travel that coincide with this meeting
[16:19] <blackboxsw> our format is the following topics: Previous Actions, Recent Changes, In-progress Development, Office Hours
[16:19] <blackboxsw> we host the meeting every two weeks at the date and time indicated in the IRC channel topic ^
[16:19] <blackboxsw> I'll update that topic now as I think we forgot to last meeting
[16:19] <blackboxsw> #topic #cloud-init Reviews: http://bit.ly/ci-reviews | Meeting minutes: https://goo.gl/mrHdaj | Next status meeting Aug 19 16:15 UTC | cloud-init v 19.2 (07/17) | https://bugs.launchpad.net/cloud-init/+filebu
[16:20] <blackboxsw> next meeting will be two weeks from today, same time
[16:20] <blackboxsw> #topic Previous Actions
[16:20] <blackboxsw> #link https://cloud-init.github.io/status-2019-07-22.html#status-2019-07-22
[16:20] <blackboxsw> groking the meeting last episode, looks like rharper needed to update status on https://bugs.launchpad.net/ubuntu/+source/cloud-init/+bug/1832381
[16:21] <blackboxsw> I think we were awaiting feedback there from AnvoMSFT for a specific reproduce
[16:21] <blackboxsw> I think we were awaiting feedback there from AnvoMSFT for a specific reproducer
[16:21] <blackboxsw> so that'll carryover til next meeting if if it a priority
[16:22] <blackboxsw> the other action from last session was for rharper to ping me on status publishing to github.
[16:22] <blackboxsw> I've pushed meeting minutes from last two cloud-init status meetings up to cloud-init.github.io so we are closed there
[16:22] <blackboxsw> no other actions seen
[16:23] <blackboxsw> #topic In-Progress Development
[16:24] <blackboxsw> Upstream 19.2 was cut on 7/17 and there are plans to SRU cloud-init within the next week or two into Xenial, bionic, disco and Eaon. I know that we are waiting on closure of a few branches  in tip before we SRU cloud-init tip to Xenial ++
[16:24] <blackboxsw> tribaal: your exoscale branch I believe is one of the ones we want landed before we start our SRU process
[16:24] <tribaal> I was hoping to address Odd_Bloke 's comments today, but that didn't happen. Tomorrow, or "this week" at the very least is my new target.
[16:24] <blackboxsw> #link https://code.launchpad.net/~tribaal/cloud-init/+git/cloud-init/+merge/369516
[16:25] <tribaal> Most of the non-blocking comments should be easy - I want to double check the on-reboot behavior on an actual instance though
[16:25] <blackboxsw> tribaal: excellent, Odd_Bloke was able to get the review in Friday as he knew he'd be on holiday today and wanted to get you feedback
[16:25] <tribaal> ack
[16:26] <tribaal> (the blocking comment about the copyright header should be trivial as well thankfully :) )
[16:26] <blackboxsw> yeah agreed
[16:26] <blackboxsw> we also have the following branches we'd like to get "in" and merged to tip before SRU
[16:26] <blackboxsw> #link https://code.launchpad.net/~daniel-thewatkins/cloud-init/+git/cloud-init/+merge/370927   (doc updates)
[16:27] <blackboxsw> #link https://code.launchpad.net/~vtqanh/cloud-init/+git/cloud-init/+merge/369785  (Azure telemetry)
[16:28] <blackboxsw> and some of goneri's FreeBSD support look like they are straight forward for review/landing
[16:28] <blackboxsw> #link https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/368507
[16:28] <blackboxsw> #link https://code.launchpad.net/~goneri/cloud-init/+git/cloud-init/+merge/365641
[16:29] <blackboxsw> If anyone else out there today is interested in getting reviews/merges before we SRU to Xenial, please feel free to raise a request in channel here or on the mailing list.
[16:31] <blackboxsw> Also in progress, I just drew up a minispec for DataSourceOVF so that VMware can support merging configuration sources from IMC and OVF if both are present. This allows OVF datasource to configure both static IP config as well as do ssh user imports (which was previously not possible)
[16:31] <blackboxsw> As always, our in progress development generally will also be represented on trello
[16:31] <blackboxsw> #link https://trello.com/b/hFtWKUn3/daily-cloud-init-curtin
[16:31] <blackboxsw> #topic Recent Changes
[16:32] <blackboxsw> the following has landed in tip of master since last cloud-init status meeting
[16:32] <blackboxsw>  % git log --oneline --since 2019-07-22
[16:33] <blackboxsw>     - net/cmdline: split interfaces_by_mac and init network config
[16:33] <blackboxsw>       determination [Daniel Watkins]
[16:33] <blackboxsw>     - stages: allow data sources to override network config source order
[16:33] <blackboxsw>       [Daniel Watkins]
[16:33] <blackboxsw> #topic Office Hours (next ~30 mins)
[16:34] <blackboxsw> feel free to ask for help, reviews, discussions on any cloud-init items you're looking at.   Otherwise I'll spend some time today getting through the review queue for cloud-init branches.
[16:34] <blackboxsw> and doing some bug triage
[16:34] <blackboxsw> thanks tribaal for jumping in BTW.
[16:35] <tribaal> blackboxsw: my pleasure :)
[16:36] <tribaal> I'm working on the review points in parallel during office hours as well, that should move things forward hopefully.
[16:36] <blackboxsw> excellent just ping when ready this week and we'll give a quick pass.
[16:46] <cyphermox> blackboxsw: yeah, I'm not sure about that eni/netplan conflict; you do need to remove old config from one to the other, otherwise they might fight, but not something I'd expect to break boot.
[16:47] <blackboxsw> hiya cyphermox. agreed, I *think* we decided that cloud-init needed to be smart in the transition from netplan -> eni if someone does that on a system and cloud-init can warn about the behavior change, cleanup old netplan config and render eni in that case.
[16:48] <blackboxsw> since cloud-init should be smart enough to know what it '
[16:48] <blackboxsw> used to render
[16:49] <cyphermox> ack
[16:49] <cyphermox> yeah, now that I think of it we said the exact same thing last meeting, I think
[16:51] <blackboxsw> +1, I'm just dusting the vacation cobwebs off. so didn't know if something else happened on that front last week
[16:52] <cyphermox> well, I recall the convo, that's what I meant
[17:06] <blackboxsw> I think that about wraps cloud-init status meeting for today folks. Thanks again. And drop us a line on the mailing list<EMAIL_ADDRESS>or here in IRC anytime with questions/discussions.
[17:06] <blackboxsw> #endmeeting
[17:06] <meetingology> Meeting ended Mon Aug  5 17:06:17 2019 UTC.
[17:06] <meetingology> Minutes:        http://ubottu.com/meetingology/logs/cloud-init/2019/cloud-init.2019-08-05-16.16.moin.txt
[17:34] <ahosmanMSFT> Good morning, I was wondering where the Platform classes (image, instance, platform, snapshot) are used during cloud_tests? I've checked the testcases files and other main files.
[17:41] <powersj> ahosmanMSFT, the collect.py file does the actual launching of the platform
[17:42] <powersj> and setup_image.py does well... setting up the image :)
[21:42] <robjo> rharper: still here?
[22:03] <powersj> robjo, we just back from a sprint so I think he is off today
[22:04] <robjo> OK, thanks
[22:04] <powersj> sorry for the missing word lol


[04:00] <moroniclibber> Hey guys.  I'm a little concerned about mir.  I see applications getting ported over to wayland but I'm afraid mir will be neglectated.  If I  continue to use Ubuntu can I expect to get eventual native Libreoffice and Firefox mir support eventually?
[04:01] <moroniclibber> Mostly my concern is I don't want to be running tons of applications under xmir while wayland users get most of their apps natively and not under xwayland
[06:10] <pitti> infinity: interest-noawait seems fine to me at first sight; I'm not familiar with the history, but it doesn't seem to have been a conscious decision "this needs to block"
[07:11] <dholbach> good morning
[07:16] <dholbach> zyga, happy birthday!
[07:16] <zyga> dholbach: thank you :)
[07:31] <brendand> zyga, birthday?
[07:31] <brendand> zyga, well happy birthday :)
[07:31] <zyga> brendand: well, what can I say, yes
[07:32] <zyga> brendand: thank you :-)
[08:49] <rbasak> pitti: do you happen to quickly know if https://launchpadlibrarian.net/214686286/DpkgTerminalLog.txt is a local configuration change or a bug?
[08:50] <rbasak> I've not seen that before - can a user disable the service to cause that, or is it because something else caused it to fail to start?
[08:50] <rbasak> (this is from https://bugs.launchpad.net/ubuntu/+source/openssh/+bug/1485487)
[10:06] <rbasak> barry: could you please advise if installing eg. ./usr/lib/python2.7/dist-packages/kimchi/plugins/ginger/API.json is acceptable or if that should be in /usr/share/kimchi instead? It looks unusual to me so I thought I'd check. This is review for a new package.
[10:07] <rbasak> (I'd normally expect to see only .py files in /usr/lib/python2.7/dist-packages)
[13:27] <barry> rbasak: tl;dr: it's fine.  many python libraries do include data files in their directory structure, and that works well with pkg_resources.  they can use that api to find the data files easily.  it does seem odd that those data files don't go in /usr/share but it's normal.  moving them is more trouble than it's worth.  upstream we've talked about ways to put such data files elsewhere but in a way that they're still easily found by the
[13:27] <barry> normal apis, but so far that hasn't gone anywhere.
[13:30] <rbasak> OK. Thanks!
[13:32] <barry> pitti, slangasek or anybody else who has shell to autopkgtest.u.c: could you please retry the tox i386 build?  it's tmpfail for what looks like problems related to the testbed (i.e. amd64 passes, and i386 should pass too now)
[13:36] <barry> pitti, slangasek same for cantor/amd64
[14:17] <pete-woods> any package-fu-masters out there who could tell me what's wrong with the packaging of indicator-network that makes it non-installable in cross-build?
[14:17] <pete-woods> http://bazaar.launchpad.net/~indicator-applet-developers/indicator-network/trunk.15.10/view/head:/debian/control
[14:59] <cyphermox> pete-woods: what do you mean by uninstallable in cross-build?
[15:02] <pete-woods> cyphermox: https://bugs.launchpad.net/ubuntu/+source/connectivity-api/+bug/1472186
[15:44] <AlbertA> doko: can I get some help to submit this bug upstream? https://bugs.launchpad.net/ubuntu/+source/gcc-5/+bug/1482320
[15:56] <cyphermox> AlbertA: wfm...
[15:56] <AlbertA> cyphermox: armhf?
[15:56] <cyphermox> oh wait, I didn't try it on armhf
[15:59] <doko> AlbertA, I'll look at it tomorrow
[16:00] <AlbertA> doko: thanks
[16:01] <cjwatson> mterry: oh BTW http://irclogs.ubuntu.com/2015/08/18/%23ubuntu-devel.html#t22:23 was a reply to you but you weren't actually on IRC at the time
[16:20] <mterry> cjwatson, oh thank you!  I noticed some kind soul retried it and it worked
[16:20] <mterry> cjwatson, I never did have success getting an arm64 VM going to poke around
[16:21] <cjwatson> mterry: You don't need VMs for this kind of thing.  chdist rules
[16:22] <mterry> cjwatson, oooh, never used that before.  It does look like exactly what I needed, cheers
[17:05] <arunpyasi> Hi guys
[17:05] <arunpyasi> Can I get some support in respining an ISO ?
[17:13] <davmor2> arunpyasi: do you mean respin or do you mean remaster?
[17:15] <arunpyasi> davmor2, I want to install/upgrade linux kernel 4.0 on a ubuntu iso I have using ubuntu builder or similar. I had tried with ubuntu builder but while testing, it stuck at busybox initramfs, it didn't boot the system to the desktop. Thanks.
[17:17] <davmor2> arunpyasi: not sure how up-to-date this is but it might help you out a little https://help.ubuntu.com/community/LiveCDCustomization
[17:18] <arunpyasi> davmor2, sir, this guide doesn't have the portion what I am wanting to do. I just want to install linux kernel 4.0 to my trusty iso, thats all sir.
[17:19] <arunpyasi> davmor2, as I have already told, I got stuck on busybox shell, can you please tell me why its stuck. I mean some general reasons for the stuck.
[17:21] <davmor2> arunpyasi: out of my league then
[17:21] <arunpyasi> davmor2, Ok sir.
[17:46] <mitya57> barry, doko: can I please get ~pythoneers subscribed to https://launchpad.net/ubuntu/+source/sphinx-rtd-theme bugs? For LP: #1485231
[17:48] <doko> mitya57, you mean that people look at this for bug reports?
[17:49] <mitya57> doko, I thought team subscriber is a requirement for getting the package into main. You may correct me though :)
[17:50] <mitya57> I also requested a similar thing for previous MIRs, and you added it to some packages.
[17:51] <mitya57> I hope I'll take care of all bug reports myself, but I am not the team…
[17:52] <doko> yes, but for main it should be a team with somebody from canonical. so barry maybe should add it to foundations
[17:52] <doko> mitya57, but I wouldn't mind updating pythoneers to the current set of python modules in main ...
[17:55] <mitya57> barry, so please add it to foundations if you can
[18:08] <barry> doko, mitya57 i agree long term we should subscribe pythoneers to python packages in main.  i don't have time for that right now, so for now i'll just subscribe pythoneers to sphinx-rtd-theme
[18:10] <mitya57> barry, thanks!
[18:10] <mitya57> I'm not yet sure if my MIR makes sense the day before feature freeze, but even if not now, I would need it at the beginning of next cycle anyway.
[18:11] <doko> barry, that doesn't help for the MIR
[18:12] <barry> doko: why not?
[18:13] <doko> barry, because pythoneers is no "canonical" team. or are you looking at all packages in this team on a regular basis, and keep the packages in this team up to date?
[18:14] <doko> apparently not =)
[18:14] <mitya57> FWIW https://wiki.ubuntu.com/UbuntuMainInclusionRequirements tells "a developer or team of developers paying attention to their bugs", but doesn't say anything about "Canonical team"
[18:15] <mitya57> If it's really the requirement, it perhaps should be mentioned in the wiki
[18:15] <barry> well, looking and fixing are two different things :/
[18:16] <barry> i think pythoneers is a better team than foundations, but i'm happy to discuss that on the mlist
[19:01] <doko> bad zul ... debian/rules: Dont run tests for python35.
[19:01] <barry> :(
[19:01] <zul> doko: fails miserably with python35
[19:01] <doko> fix it
[19:02] <doko> or don't use lifeless fork
[19:09] <hallyn_> pitti: hi - do you know of a way in a .service file to ask systemd to not create a slice at all for the service?
[19:09] <hallyn_> Using Slice=boo I can ask that the slice be created *under* boo, but I can't seem to say "dont create one"
[19:10] <hallyn_> although in the code I see checks for "if ->cgroup_name == NULL", so I assume there's a way to say what I want...
[19:10] <hallyn_> (and, using "Slice=-.slice" I'm only asking for service.slice to be created as a root level cgroup rather than under system.slice - still not what i want)
[19:55] <lifeless> doko: what ?
[19:57] <lifeless> zul: what fails with python35 ?
[19:59] <zul> lifeless: http://pastebin.ubuntu.com/12130288/
[20:03] <lifeless> zul: appears to be a bug in unittest2
[20:03] <lifeless> zul: I haven't synced it in a bit. If you wanted to put a patch up (in the bug tracker which has just moved from google code - its now https://github.com/testing-cabal/unittest-ext
[20:04] <lifeless> zul: but the code is still - https://hg.python.org/unittest2
[20:04] <lifeless> zul: On my short term todo is moving it from there into git and then setting up travis for it with the nightly branch tests
[20:04] <zul> lifeless: ok ill take a look when i get a chance
[20:05] <lifeless> zul: I suspect the failure might be due to the bug in traceback about exception header lines
[20:05] <lifeless> zul: e.g. cosmetic at most
[20:08] <pitti> slangasek: FYI, I already retried all tmpfail issues, there were some "hit the quota limit" issues
[20:08] <lifeless> zul: so yeah, I think its related to issue #24695:
[20:08] <lifeless> zul: which I haven't backported yet
[20:09] <lifeless> zul: probably there's some mismatch - some point where its using the built in traceback module vs traceback2
[20:09] <lifeless> zul: I've reproduced it locally though - so its not a packaging issue.
[20:09] <lifeless> zul: file the bug upstream, move on.
[20:09] <zul> ok
[20:10] <zul> ill do that in a bit
[20:10] <pitti> hallyn_: i. e. you want a service to be in cgroup /servicename.service directly without a slice parent? I don't know whether that's possible or even makes sense (especially not in the future unified hierarchy), might be worth asking in #systemd or the ML?
[20:16] <lifeless> zul: thanks
[20:54] <jcastro> pitti: so I suppose that it would be a combination of the SRU queue processing and the seven day wait period.
[20:54] <jcastro> that just seems to slow
[21:03] <infinity> jcastro: I missed context, but what SRU is "too slow"?
[21:03] <jcastro> for getting in the newest nvidia drivers.
[21:04] <jcastro> I mean, tbh, if the SRU process wasn't slow we would have never needed to make a PPA.
[21:04] <infinity> jcastro: Talking hypotheticals, I guess?  There aren't any in the queue or proposed.
[21:04] <infinity> jcastro: You do remember the wild west that was SRUs before we made the process slow, right?
[21:04] <hallyn_> pitti: no, i can do /servicename.service using Slice=-.slice.  But I want it to be in /
[21:04] <infinity> jcastro: It's a bit of a catch-22 here.
[21:04] <jcastro> yes I do
[21:05] <cjwatson> wild west => we're all fired
[21:05] <jcastro> and I realize what I am asking for is totally opposite of what we know is the right thing
[21:05] <infinity> jcastro: And given the packaging of those drivers, they *do* need review and testing, because they *do* break, often.
[21:05] <jcastro> but if the answer is "nope, not going to happen" then that's fine too, there are plenty of things we can work on
[21:05] <infinity> jcastro: It's not a simple case like tzdata, where the packaging is minimal, and the data is verifiable.
[21:05] <jcastro> infinity: right, but I was hoping to get away with "not our problem, if they break, talk to the vendor."
[21:06] <jcastro> like they do for every single platform except for us apparently. :-/
[21:06] <infinity> jcastro: The *packaging* breaks often. :P
[21:06] <infinity> jcastro: Which totally is our problem.
[21:06] <jcastro> oh, I see!
[21:06] <jcastro> infinity: so do you think we should just sort ourselves for a while and see how it goes and then approach later?
[21:07] <infinity> jcastro: The binary blobs break even more often, true, but as you say, not a whole lot we can do about that.
[21:07] <infinity> jcastro: Who is us, and what are you sorting, and with whom?
[21:08] <infinity> jcastro: I mean, driver updates in stable releases need to happen.  Making them happen more quickly is a laudable goal.    The history of these packages is not good enough for any of us to give them a hand-wave without reviewing every, single, upload thoroughly (which sucks...)
[21:08] <jcastro> https://launchpad.net/~graphics-drivers/+archive/ubuntu/ppa
[21:09] <jcastro> infinity: imo it doesn't need to be perfect, it needs to be enough to stop people from saying "if you game don't use ubuntu."
[21:09] <infinity> jcastro: Ugh.  No.  We're not adding PPAs as official repos in installers.
[21:10] <jcastro> heh
[21:10] <infinity> jcastro: If it's good enough to put our name on it, it belongs in the primary archive, if it's so crap it can only happen in a PPA, it shouldn't be recommended to users, don't game the system.
[21:10] <jcastro> fair enough
[21:10] <jcastro> We apparently don't have the resources to have people dedicated to bringing things into the primary archive
[21:11] <jcastro> which is as I understand it how we got so behind in the first place
[21:16] <rbasak> What if we found a way to have two streams in the archive at once?
[21:17] <rbasak> Although I suppose that's what -proposed is.
[21:18] <rbasak> Could we for example get things into -proposed very quickly, and make it easy for consenting users to specifically consume nvidia drivers from -proposed very easily?
[21:18] <rbasak> Or will we not be able to keep up with that?


[04:48] <bduk1> More almal
[06:33] <Kilos> hi jabberwocky93  Spekko  et al
[06:34] <Spekko> Morning Kilos
[06:34] <jabberwocky93> hi Kilos
[06:46] <Kilos> morning not_found
[06:47] <not_found> morning
[06:48] <not_found> was in bed by 8 so missed the meeting, sorry
[07:15] <Kilos> np not_found
[07:15] <Kilos> hi sakhi
[07:15] <sakhi> Morning Kilos
[07:15] <sakhi> Morning #ubuntu-za
[07:41] <Kilos> hi Vince-0
[07:41] <Vince-0> Hi Kilos the ever quick
[07:43] <Kilos> hehe
[07:49]  * Vince-0 has Metallica - Ronnie Rising Medley blocking out the noise
[07:52] <Kilos> hi liamT
[08:04] <liamT> hihi
[09:18] <Kilos-> sorry
[11:46] <Kilos-> hi superfly
[12:33] <inetpro> eish
[12:33] <inetpro> Happy Document Freedom Day!!
[12:34] <inetpro> we forgot to mention last night that it's document freedom day today
[12:58] <Vince-0> yar
[13:21] <Kilos-> ai!
[14:25] <jabberwocky93> facebook bought oculus rift :'(
[14:45] <Kilos-> hi amanica
[14:46] <Kilos-> facebook is too big and powerful now
[14:46] <Kilos-> they at the stage where they can walk on others or buy them out
[14:46] <amanica> hi Kilos, trying to find my joburg buddies from last night :)
[14:47] <Kilos-> i forget who they were amanica
[14:47] <Kilos-> leave them messages with maaz and arange a time to meet here
[14:48] <Kilos-> you know how to do that?
[14:48] <Kilos-> oh liamt was one
[14:48] <Kilos-> he was here earlier
[14:50] <amanica> ah thanks, no I don't know how to do that. I was looking for captine.
[14:51] <amanica> I suppose I can leave my e-mail address
[14:51] <amanica> I'd like to throw some dates and venues around for a release party..
[14:57] <Vince-0> partaay
[14:57] <Vince-0> works done, im out!
[15:01] <Kilos-> amanica  you type maaz tell nick and your message
[15:01] <Kilos-> you might need to say nick on freenode then the message
[15:02] <Kilos-> arent you on our mailing list?
[15:04] <amanica> I'm on the mailinglist, but just bouncing some dates and venues around with prospective co-organizers solong
[15:04] <amanica> thx Kilos
[15:05] <amanica> maaz tell captine I'm thinking of doing an Ubuntu release party braai again in Randburg 26 Apr or 3 May. e-mail me if you have preferences and maybe wanna help organise<EMAIL_ADDRESS>[15:05] <Maaz> amanica: Okay, I'll tell captine on freenode
[15:06] <amanica> thx Kilos, cya
[16:31] <Kilos-> Maaz  coffee on
[16:31]  * Maaz puts the kettle on
[16:35] <Maaz> Coffee's ready for Kilos-!
[16:35] <Kilos-> Maaz  ty
[16:35] <Maaz> You are welcome Kilos-
[16:35]  * Kilos sips his cyber coffee on his lonesome
[16:58] <Kilos> hi Private_User
[16:58] <Private_User> Good evening people
[16:58] <Private_User> Hi Kilos
[17:00] <Kilos> i go eat
[17:00] <Kilos> wbb
[17:22] <Private_User> hello honey_nut_loops
[17:25] <Kilos> honey_nut_loops  wassup davey?
[17:27] <honey_nut_loops> Kilos: :oD
[17:27] <Kilos> hehe
[17:27] <drussell> Kilos: how's tricks? :o)
[17:27] <drussell> Private_User: hiya
[17:27] <Kilos> go9od ty and there?
[17:27] <Kilos> good as well
[17:27] <drussell> Kilos: getting everything ready for 14.04 release, so yeah, very busy but good!
[17:27] <Kilos> fingers getting too fat
[17:28] <Kilos> lekker
[17:28] <Kilos> im looking forward to it in 2 flavours
[17:45] <Kilos> hi charl
[17:45] <charl> hi Kilos
[17:45] <charl> Maaz: coffee on
[17:45]  * Maaz washes some mugs
[17:45] <charl> Maaz: how's it going
[17:45] <Maaz> charl: *blink*
[17:46] <charl> he doesn't have much to say today
[17:46] <charl> Kilos: how's it going with you then
[17:46] <Private_User> my connectivity seems to be starting up its nonsense again
[17:46] <charl> hi Private_User
[17:46] <Kilos> good ty and you?
[17:47] <Kilos> aw no man Private_User
[17:47] <charl> Kilos: i'm good
[17:47] <Private_User> hi charl
[17:47] <Kilos> rev cellc
[17:48] <Kilos> mail their ceo and make a serious complaint
[17:49] <Maaz> Coffee's ready for charl!
[17:50] <charl> Maaz: thanks
[17:50] <Maaz> charl: Okay :-)
[17:50] <nuvolari> oh hi :)
[17:51] <charl> hi nuvolari
[18:14] <Kilos> hi nlsthzn
[18:14] <nlsthzn> alo uncle Kilos
[18:19] <kbmonkey> hi hi
[18:20] <kbmonkey> I still cannot add a loco meeting. whoops.
[18:20] <kbmonkey> would someone need to approve me since I joined?
[18:28] <Kilos> hi kbmonkey
[18:29] <kbmonkey> hi Kilos
[18:30] <Kilos> how does one do that kbmonkey
[18:30] <Kilos> in launchpad you mean
[18:30] <Kilos> oh
[18:30] <Kilos> fight the pro
[18:30] <Kilos> inetpro  fix it
[18:31] <kbmonkey> ya on loco.ubuntu.com
[18:50] <Kilos> you sure you at the right place kbmonkey
[18:51] <Kilos> give me the whole link lemme see
[18:51] <Kilos> doesnt maia or one of our locals need to approve you
[18:52] <kbmonkey> I think so
[18:52] <Kilos> the fly maybe
[18:52] <kbmonkey> loco.ubuntu.com
[18:52] <Kilos> man thats no a whole link
[18:52] <Kilos> not
[18:52] <kbmonkey> I log in and under meetings I click Add
[18:52] <kbmonkey> http://loco.ubuntu.com/meetings/
[18:53] <Kilos> ive never done anything there but ill go see
[18:53] <kbmonkey> ah you don't have to Kilos xD
[18:53] <Kilos> we not even there
[18:54] <Kilos> i know i dont have to, but wanted to see what was happening
[18:54] <Kilos> thats how i learn
[18:54] <kbmonkey> Right-o
[18:54] <kbmonkey> logs in with launchpad acccount
[18:54] <kbmonkey> they use the same
[18:55] <kbmonkey> then on that page click the "Add team meeting" link
[18:55] <Kilos> does it let you login?
[18:56] <kbmonkey> yes
[18:56] <Kilos> and then?
[18:58] <kbmonkey> go to the meetings page (link) and click "Add Team Meeting"
[18:58] <kbmonkey> it says You are not a member of any LoCo Teams.
[18:59] <kbmonkey> but then I go to the za page https://launchpad.net/~ubuntu-za and click JOIN to join the team, and it says I am already on the team
[18:59] <kbmonkey> lol
[19:00] <Kilos> lol
[19:00] <Kilos> ping the pro
[19:00] <Kilos> he near bedtime
[19:01] <Kilos> i hate going to those places they always dont recognise my password
[19:01] <Kilos> everytime reset to same passwd before i can get anywhere
[19:01] <inetpro> ai!
[19:02] <kbmonkey> no Kilos let the people sleep man, lol
[19:02] <Kilos> inetpro  naand help apie toe
[19:03] <inetpro> kbmonkey: send a mail to<EMAIL_ADDRESS>[19:04] <kbmonkey> hi inetpro. okay, does the subject need to be anything like "subscribe"?
[19:04] <inetpro> no, this will most likely go to maia the bee
[19:04] <kbmonkey> or is this a support email and I should explain my issue?
[19:04] <kbmonkey> ah, gotcha :)
[19:04] <Symmetria> yay! my mirror server finally cleared customs!!!!!!!!!!!!!
[19:04] <Symmetria> its taken WEEKS
[19:04] <inetpro> Symmetria: only now?
[19:04] <kbmonkey> wow
[19:04] <inetpro> ai!
[19:05] <inetpro> good evening everyone
[19:07] <inetpro> kbmonkey: are you sure there was no email that came back to you needing a verification response?
[19:07] <Kilos> then my reset passwd mail goes in the spam box at google and i go there and see the personal info page and dunno where to find my mail box
[19:08]  * Kilos cries
[19:08] <Kilos> google has messed up everything for normal peeps
[19:08] <inetpro> no
[19:08] <Kilos> no what?
[19:09]  * inetpro will back google on this one
[19:09] <inetpro> gmail is a service they do very well
[19:09] <Kilos> why isnt my inbox and stuff there
[19:09] <Kilos> why the info page
[19:09] <inetpro> I don't have a clue what you're on about
[19:09] <kbmonkey> inetpro, no email, also nothing in spam.
[19:10] <kbmonkey> I do see Kilos emails was in spam, huh.
[19:11] <Kilos> info security language data tools and help options
[19:11] <Kilos> no inbox outbox spam junk etc
[19:11] <kbmonkey> what's wrong Kilos ?
[19:12] <Kilos> i dunno how to get to my mail up there
[19:12] <Kilos> and the reset password mail dont come so must be in spam
[19:13]  * Symmetria sets up plex all over again
[19:13] <Symmetria> this is gonna take ages
[19:13] <Kilos> ubuntu site says look in spam if mail dont arrive in a few minutes
[19:14] <Kilos> fix it Symmetria
[19:14] <kbmonkey> spam spam spam spam spam
[19:14] <kbmonkey> Monty Python*
[19:14] <Kilos> lots of ubuntu list mail go to spam
[19:14] <Symmetria> lol my plex server has 50 terabytes of crap linked into it, it takes *FOREVER* to match and index it all
[19:14] <Kilos> now i cant even get to my spam box
[19:17] <kbmonkey> how so Kilos ?
[19:17] <kbmonkey> mail client or web interface?
[19:17] <Kilos> http://accounts.google.com/
[19:17] <kbmonkey> I use m.gmail.com, the light version
[19:18] <kbmonkey> top-right change Inbox to Spam
[19:18] <kbmonkey> top-left
[19:19] <Kilos> yay i found a link that works
[19:22] <inetpro> Kilos: if you find lot's of valid mails going to spam you should visit the spam folder often and mark it as "not spam"
[19:22] <Kilos> and its not in my spam box
[19:22] <Kilos> i did 2 weeks ago
[19:23] <inetpro> ai! You keep turning around in circles if you talk like that
[19:23] <Kilos> lol
[19:23] <Kilos> i didnt bookmark it so had to find the correect link from maaz's info to get there
[19:24] <Kilos> now its bookmarked
[19:24]  * inetpro shall keep quiet in future
[19:24] <Kilos> no sya your bit
[19:24] <Kilos> say
[19:24] <kbmonkey> adding addresses to you contacts list should keep them out of spam too :)
[19:24] <inetpro> Kilos: you end up confusing everyone including yourself
[19:25] <Kilos> hahahaha
[19:25] <Kilos> nee man
[19:26] <Kilos> so if the password reset aint in spam either then they didnt send it to me
[19:26] <Kilos> now i go the ubuntuone support option
[19:26] <inetpro> a bad carpenter always blames his tools
[19:27] <Kilos> google isnt my tools you know how i feel about google
[19:27] <Kilos> my tools work
[19:27] <inetpro> then stop using gmail
[19:27] <Kilos> first time without support
[19:27] <kbmonkey> maybe the email got lost in the series of tubes
[19:28] <inetpro> ok ok, sorry oom... that was maybe a bit far out again
[19:30] <inetpro> Kilos: what is the problem?
[19:30] <kbmonkey> ubuntu one not sending the password recovery email I'm guessing?
[19:31] <inetpro> ai!
[19:31] <inetpro> sometimes patience is needed with some of these cloud systems
[19:32] <inetpro> golden rule is, never forget your passwords
[19:32] <inetpro> in fact, don't even try to remember them
[19:33] <inetpro> use something like KDE Wallet, PeePass2, or any of the many other password managers
[19:33] <Kilos> my password is the same and had to reset it when i last went to ubuntu stuff
[19:34] <inetpro> s/PeePass2/KeePass2/
[19:34] <inetpro> don't use the same password for any other system
[19:36] <kbmonkey> sorry Kilos, passwords are annoying things to remember aren't they
[19:37] <Kilos> no mine is the same for everything
[19:37] <Kilos> but its a strong one
[19:37] <kbmonkey> every one of mine difffers. variety is the headache of life.
[19:37] <Kilos> best is mail maia. i bet she answers you within 30 mins
[19:38] <kbmonkey> I emailed the team as the pro recommended, thanks :)
[19:38] <Kilos> maiais the owner
[19:38] <kbmonkey> I have a forumula though, applied to a site I can recreate any password from memory.
[19:38] <Kilos> lol
[19:42] <Kilos> i dont see weenie there in latest members
[19:43] <Kilos> inetpro  you must go sleep now
[19:43] <kbmonkey> lol Kilos
[19:44] <inetpro> hmm...
[19:44] <kbmonkey> I'm also off to bed, need some rest tonight
[19:44] <Kilos> ok kbmonkey   and tomorrow mail maia
[19:44]  * inetpro sounds tired?
[19:44] <Kilos> sleep tight
[19:44] <inetpro> good night kbmonkey
[19:44] <Kilos> you are tired inetpro  and grumpy again
[19:45] <inetpro> that's just me, sorry oom
[19:45] <inetpro> :-)
[19:45] <Kilos> lol
[19:45] <Kilos> np
[19:45] <Kilos> im used to it already
[19:45] <kbmonkey> we try again tomorrow :)
[19:45] <Kilos> been a few years
[19:45] <Kilos> night my monkey
[19:45] <Kilos> kip lekker
[19:46] <inetpro> but you're right, it's been a long day
[19:46] <kbmonkey> thanks & sweet dreams to all
[19:46] <inetpro> lekker slaap
[19:46] <Kilos> more is nog n dag
[19:47] <Kilos> the modern way is dont do today what you can put off till tomorrow
[19:47] <kbmonkey> dis alles een lang dag met sononder en sonop ingemeng ;)
[19:47] <Kilos> lol
[19:47] <kbmonkey> procrastinators, unite! tomorrow.
[19:47] <Kilos> i go sleep too
[19:48] <Kilos> night everyone. sleep lekker
[19:48] <kbmonkey> nite nite
[19:48] <Kilos> i even looked at fb tonight
[19:48] <kbmonkey> frame buffers?
[19:48] <Kilos> the book man
[19:49] <Kilos> with hundreds of wanna be friends and do you know so and sos
[19:50] <kbmonkey> sorry, afraid I don't know
[19:50] <Kilos> facebook man
[19:50] <Kilos> go sleep. you too tired


[03:20] <tjaalton> robert_ancell: hi, did you notice the xmir patch reviews? 1.19 might get branched soon
[03:20] <robert_ancell> tjaalton, yeah, haven't got around to replying yet
[03:21] <tjaalton> ah, ok
[03:22] <tjaalton> guess smooth scrolling can be added later
[03:22] <robert_ancell> There's lots of stuff that can be added later! :)
[03:23] <tjaalton> hehe
[03:49] <duflu> tjaalton: Smooth scrolling or smooth scrolling? :)  One is to animate smoothly between coarse steps (like we do in Unity7 Firefox and now Chrome). The other is proper smooth scrolling using the full touchpad resolution. I'm still chasing anpok to find out if that's a bug in libinput/Mir or a missing feature. Once we've confirmed the backend for proper smooth scrolling is working in Mir I'll be keen to see everything above Mir use it
[04:25] <tjaalton> duflu: the latter, sounds like it should be implemented on the wayland stack if whot pointed it out on the review. but it shouldn't be a blocker for inclusion
[04:26] <duflu> tjaalton: By wayland stack you mean libinput?
[04:26] <duflu> I'm talking about Mir
[04:30] <tjaalton> yes
[04:31] <duflu> Cool
[04:31] <tjaalton> 81a51a6cace6fd in xorg-server git implemented it for xwayland
[04:33] <tjaalton> http://anonscm.debian.org/cgit/pkg-xorg/xserver/xorg-server.git/commit/?id=d8a39245d6cff6accf5eaeae7a1ac15eb1eb048a
[04:34] <duflu> tjaalton: Interesting thanks. Sounds like something I might be asked to do
[04:35] <duflu> Or robert_ancell ....
[04:36] <robert_ancell> not me
[04:36] <duflu> But I'm curious to check out the current state of scroll events from Mir of late
[04:37] <duflu> robert_ancell: OK, I touched it last and implemented the wheel hack anyway
[04:54] <hikiko> hi
[05:02] <duflu> Morning hikiko
[05:47] <pitti> Trevinho: commented on the patch in the upstream bug
[05:47] <pitti> Good morning
[07:14] <happyaron> seb128: the bug for ibus appindicator means the upstream implementation
[07:15] <happyaron> seb128: do we need an FFe if we would SRU to xenial? (uploading for yakkety now)
[08:02] <Laney> hullo
[08:03] <seb128> hey Laney
[08:03] <seb128> how are you?
[08:03] <seb128> one minute earlier this morning!
[08:03] <pitti> hey larsu!
[08:03] <pitti> bonjour seb128 aussi !
[08:04] <seb128> happyaron, unsure if that's something worth a SRU
[08:04] <seb128> pitti, salut, ça va ?
[08:04] <pitti> seb128: ça va bien, merci !
[08:04] <seb128> pitti, wrong l<tab>? ;-)
[08:04] <seb128> happyaron, where would the indicator be useful?
[08:04] <pitti> Laney: good morning to you too!
[08:04] <Laney> stalker!
[08:04] <pitti> seb128: of course not wrong, just incomplete :)
[08:10] <Laney> (hi seb128 and pitti!)
[08:16] <willcooke> hmm
[08:16] <willcooke> I think there must have been an issue copying my old settings from xchat to hexchat
[08:16] <willcooke> but why was it only a problem today
[08:16] <willcooke> the portnumber for the server was totally wrong
[08:17] <seb128> hey willcooke
[08:17]  * willcooke strokes his chin suspiciously
[08:17] <seb128> how is hexchat?
[08:17] <willcooke> morning
[08:17] <seb128> I wonder if I should try that one
[08:17] <willcooke> it's like xchat, and therefore good :D
[08:18] <willcooke> seb128, BTW I replaced the wifi card in my X220 with an Intel one. So far so good.
[08:19] <larsu> morning pitti!
[08:19] <larsu> and morning desktoppers!
[08:20] <willcooke> howdy larsu
[08:21] <andyrock> morning all
[08:21] <willcooke> hey andyrock
[08:26] <seb128> hey larsu, wie gehts?
[08:26] <seb128> hey andyrock!
[08:26] <Sweet5hark1> heya all
[08:27] <seb128> hey Sweet5hark1
[08:27] <seb128> channel wakes up ;-)
[08:30] <pitti> Sweet5hark1: moin moin!
[08:30] <pitti> Sweet5hark1: looking at LibO xenial SRU; please upload this to yakkety
[08:31] <Sweet5hark1> hmmm
[08:31]  * Sweet5hark1 no upload rights.
[08:32] <seb128> Sweet5hark1, how is the DMB thing going btw? ;-)
[08:33] <Sweet5hark1> seb128: ^^ do I need to prep a full yakkety pkg or ...
[08:33] <seb128> Sweet5hark1, well, "full"
[08:33] <Sweet5hark1> dammit, seb128 was faster ...
[08:33] <seb128> lol
[08:33] <seb128> just bump the changelog
[08:33] <seb128> was there anything you wanted to change/enable in y?
[08:34] <seb128> and let's hope toolchain doesn't bite us :p
[08:34] <Sweet5hark1> seb128: no, certainly not for 5.1
[08:34] <pitti> seb128: y has a different package than x, mind you
[08:34] <pitti>  libreoffice | 1:5.1.2-0ubuntu1     | xenial                   | source
[08:34] <pitti>  libreoffice | 1:5.1.2-0ubuntu3     | yakkety                  | source
[08:34] <seb128> doko...
[08:34] <pitti> so this might need to be a merge
[08:35] <seb128> Sweet5hark1, http://launchpadlibrarian.net/256160858/libreoffice_1%3A5.1.2-0ubuntu1_1%3A5.1.2-0ubuntu3.diff.gz
[08:35] <seb128> can you merge that and bump changelog?
[08:35] <seb128> and go doko for doing changes undocumented in the changelog
[08:35] <seb128> -               g++-5 [hppa ia64 s390 sparc],
[08:36] <seb128> +               g++-6.0 [hppa ia64 s390 sparc],
[08:36] <Sweet5hark1> seb128: yep. the merge seems reasonable
[08:36] <pitti> this is a no-op
[08:36] <pitti> we don't have any of these arches
[08:36] <larsu> seb128: I'm great thanks! Just back from the gym :)
[08:36] <pitti> unless this is a typo and was meant to be s390x
[08:36] <larsu> seb128: how are you? Did you enjoy the long weekend?
[08:37] <Sweet5hark1> seb128: thats ~unavoidable, I guess. Its just control being regenerated (with ./debian/rules control) on yakkety ...
[08:38] <Sweet5hark1> seb128: ... but it means I also need to regen control on yakkety and thus setup my yakkety pbuilder env  etc.
[08:38] <seb128> larsu, I'm good thanks, yeah it was quite relaxing! (though would have been better with the weather from a week ago)
[08:39] <larsu> heh yeah same here. Getting better today though
[08:39] <seb128> Sweet5hark1, is that much work?
[08:40] <Sweet5hark1> seb128: nah, just some script-foo and I have to do it anyway at some point for the 5.2 builds ..
[08:41] <pitti> Sweet5hark1: good opportunity to move to sbuild? :-)
[08:44] <Sweet5hark1> pitti: maybe ... though I dont see anything of the pbuild foo anyway. Its wrapped by some helper I wrote in C++11 and _that_ is running in a Jenkins.
[08:44] <Sweet5hark1> "Any problem in computer science can be solved with another layer of indirection. But that usually will create another problem." -- David Wheeler
[08:44] <pitti> Sweet5hark1: more like "two more problems" :)
[08:44] <pitti> think exponentially!
[08:44] <Sweet5hark1> also called Jenga-driven development. I bring experience fromLO!
[08:46] <pitti> hah, I like that
[08:46] <pitti> Jenkins for sure felt like Jenga
[08:50] <seb128> wooot
[08:50] <seb128> thanks pitti for the SRU reviews ;-)
[08:50] <seb128> (assuming it's you)
[08:50] <pitti> seb128: yes, it is
[08:50]  * seb128 hugs pitti
[08:50]  * pitti hugs you back :)
[08:51] <seb128> pitti, btw we should perhaps copy that accountsservice updates-regression-fix over now? bdmurray didn't want to do it on friday because too risky to copy things on friday
[08:52] <pitti> seb128: oh, absolutely; I thought this was a no-brainer
[08:52] <seb128> he said he would do it on monday
[08:52] <seb128> but apparently didn't...
[08:52] <pitti> seb128: u-settings-daemon needs a yakkety upload in bug 1510344
[08:52] <seb128> pitti, yeah, I plan to do a landing this week, just want to include a bit more
[08:53] <seb128> trying to get to it today
[08:53] <seb128> I need to check with Trevinho as well
[08:53] <seb128> he mentioned that he was going to do a landing as well
[08:53] <seb128> we should try to not conflict ;-)
[08:53] <pitti> seb128: accountsservice released
[08:53] <seb128> dankie!
[08:53] <seb128> -i
[08:56] <seb128> pitti, did you block libreoffice on the y-upload to be sorted out?
[08:56] <pitti> Laney: not a fan of dropping glib-networking-dbg in an SRU
[08:57] <pitti> Laney: rejected for this, as we don't have a proper upgrade path for this
[08:57] <pitti> seb128: for now, yes; is this urgent?
[08:59] <seb128> pitti, no, it's just that usually nobody wants to review libreoffice, we had a 0day SRU in wily fixing release issues, it's still in the queue...
[08:59] <seb128> just trying to make sure that doesn't happen again
[08:59] <pitti> well, I did look at the patch
[08:59] <seb128> not blaming anyone, libreoffice is big and the diffs are not easy to review
[09:00] <pitti> but we can't copy it to yakkety (and shouldn't either), and I don't want this to be forgotten
[09:00] <seb128> we should perhaps get it under a microrelease exception
[09:00] <pitti> there are no package specific MREs any more
[09:00] <seb128> maybe there should be :-)
[09:01] <pitti> LibO has a fairly good QA upstream, and has build and autopkgtest-time tests
[09:01] <pitti> and stable microeleases
[09:01] <pitti> which is by and large what the requirements are
[09:01] <pitti> and also, the SRU by itself is fine
[09:01] <seb128> k
[09:01] <pitti> so this isn't about the SRU, it's about "devel first"
[09:02] <seb128> pitti, unsure where to ask but I would like to understand what happened with https://launchpad.net/ubuntu/wily/+queue?queue_state=1&queue_text=libreoffice
[09:02] <seb128> not blaming you
[09:02] <seb128> the SRU team has no mailing list right?
[09:02] <pitti> seb128: i. e. what did *not* happen?
[09:02] <pitti> right, no ML
[09:02] <seb128> that was a bugfix update uploaded before release to fix release issues
[09:03] <seb128> how come we got through a full cycle with nobody reviewing it?
[09:03] <seb128> and how do we make sure that doesn't happen again
[09:03] <Laney> pitti: meh, fine
[09:04] <seb128> pitti, do you have any idea what would be the right place for that discussion?
[09:04] <pitti> seb128: u-devel@ I guess
[09:04] <seb128> I wonder if that's TB material
[09:04] <pitti> or u-release@
[09:04] <seb128> "make the SRU team accountable"
[09:05] <seb128> pitti, I've a feeling it's going to end up as "nobody felt like reviewing it"
[09:06] <pitti> TBH, so far I didn't even make it to queues older than xenial
[09:06] <seb128> yeah, as said not blaming you
[09:06] <pitti> (I'm not really on a roster, I've just been helping out after the release)
[09:06] <seb128> I think it's more of an issue of how our teams are set up
[09:06] <pitti> but that's the root cause -- we don't have a roster
[09:06] <pitti> everyone is busy with other stuff
[09:06] <seb128> right
[09:06] <pitti> similar to sponsoring, +1maint, etc.
[09:06] <seb128> but even the roster wouldn't help
[09:06] <Laney> it's been tried
[09:06] <Laney> they always fall down
[09:07] <seb128> if people feel like libreoffice is too big and don't want to review it and keep skipping over it
[09:07] <pitti> I've spent about 1.5 h every day on SRU stuff recently, and it's massively getting boring indeed
[09:07] <pitti> or more precisely, the daily IRC pings pretty much always trump such regular things
[09:08] <seb128> imho we need somebody "in charge"
[09:08] <seb128> who at least try to organize the team efforts
[09:08] <seb128> and try to nag people to help a bit when things are behind
[09:08] <seb128> and make sure nothing gets forgotten
[09:14] <Sweet5hark1> seb128: or, if you want to be _really_ evil: give it a deadline with default approval: "If after 90 days, nobody rejected it, then you all approved it implicitly.".
[09:14]  * Sweet5hark1 hides
[09:18] <seb128> Sweet5hark1, did you ever get anyone pinging you about that one/asking for details or things to be explained/fixed?
[09:18] <Sweet5hark1> about wily? not that I remember, no.
[09:19] <seb128> ok, thanks
[09:19] <seb128> going to write than email to -devel then
[09:22] <Sweet5hark1> seb128: FWIW, I didnt pressure there anymore, and rather cared about having up-to-date stuff ready in the PPA, so that if anyone is asking for a SRU (or when we need a security update) I have my ducks in a row.
[09:22] <seb128> yeah, having to ping them shouldn't be required though
[09:25] <ricotz> Sweet5hark1, don't forget about mdds
[09:26] <Sweet5hark1> ricotz: huh?
[09:27] <ricotz> hey desktopers
[09:27] <ricotz> Sweet5hark1, just in case this is still needed https://paste.debian.net/plain/687015
[09:28] <ricotz> Sweet5hark1, mdds-1.0 is not compatible with 5.1's buildsys
[09:44] <duflu> pitti: Jenga is a fun analogy. So is kicking the robot dog (named Jenkins)
[09:45] <duflu> Although that's strangely a nasty thing to say
[09:48] <duflu> On an unrelated note: Thank you pitti and seb128 for chasing the upower issue
[09:56] <alexarnaud_> Hello all!
[09:56] <seb128> duflu, hey, yw!
[09:56] <seb128> hey alexarnaud_
[09:57] <seb128> duflu, is your base issue also that upower start is delayed then? do you know if that's the same usb enumeration delay than others mentioned?
[09:58] <alexarnaud_> Trevinho: Hey ! I've noticed somehting strange in Compiz. When I install Compiz build-dep, especially libmetacity-dev, when I restart Compiz the gtk window decorator doesn't work. I'm using Mate. The error message is about a GSettings key "theme" that is not found. Is a known issue? Is a human error?
[09:58] <duflu> seb128: Not sure but I don't have the same USB devices others describe.
[09:58] <alexarnaud_> seb128: how are you?
[10:07] <seb128> alexarnaud_, I'm good thanks, how are you?
[10:07] <seb128> duflu, can you check if upower is delayed on your machine though? look at syslog for eventual issues on that side?
[10:07] <duflu> seb128: The machine does not exist. It's running 14.04 till the bug is fixed :(
[10:08] <duflu> Sorry, it's both my main server and the only machine that has the bug
[10:08] <duflu> Very inconvenient
[10:08] <seb128> duflu, you didn't keep any syslog or such from the boot you tried by any chance?
[10:09] <duflu> seb128: No, it was the end of a long weekend and I was in a mad rush to restore 14.04 after the problems so I could get back to work the next day
[10:10] <seb128> I see
[10:10] <seb128> was u-s-d segfaulting the only issue? did you try to restart manually back then?
[10:10] <seb128> most reporters seem to suggest that restarting it after upower is done loading works fine
[10:10] <seb128> reinstalling seems like a big hammer in that case ;-)
[10:11] <duflu> seb128: Sorry, I didn't try anything else. I was rushed
[10:11] <seb128> k
[10:11] <seb128> no worry
[10:11] <duflu> seb128: Not a big hammer, just a HDD swap
[10:12] <alexarnaud_> seb128: good, we have made a huge work on improving Compiz accessibility with lot of work on EZoom :), we have integrated focus tracking and some visual improvment. Do you think you (Canonical) could help us to improve accessibility of the switcher plug-in? We would like to have capability to change the size of elements (icons, text, background) to be readable for low vision people. Unfortunately we have just o
[10:13] <alexarnaud_> We focus on EZoom and Mouse Poll plug-ins.
[10:17] <seb128> alexarnaud_, your line cut at "Unfortunately we have just o"
[10:18] <seb128> unsure how much resources we have to help on that
[10:18] <seb128> we can probably help with some advices/reviews
[10:18] <seb128> but probably not much with coding
[10:18] <seb128> especially if you are speaking of a switcher which is not the unity one
[10:25] <alexarnaud_> seb128: I talk about the "Application Switcher" module.
[10:48] <Sweet5hark1> https://www.reddit.com/r/Python/comments/4jhma7/what_did_you_automate_with_python_scripts/d37clfr <- this is awesome
[10:49] <willcooke> Laney, can haz email
[10:49] <Laney> HAX
[10:49] <willcooke> so it works!
[10:50] <Laney> I want this offlineimap sync to finish
[10:50] <Laney> so that I can go back to mutt
[10:50] <Laney> /o\
[10:50] <Laney> Copy message 12585 (12585 of 132357) Personal:INBOX.Ubuntu.Launchpad -> lpersonal
[10:50] <Laney> might take a while though
[10:50] <pitti> urgh
[10:50] <Laney> that's after many hours
[10:50] <Laney> because I so need to keep all this ancient Launchpad mail...
[10:51]  * pitti never understood why people keep so much email
[10:51] <Laney> hahaha
[10:51] <Laney> I usually view unread messages so it's more or less invisible except for times like this
[10:52] <pitti> well, they still slow down your MUA, syncing, etc?
[10:52] <Laney> only the initial sync
[10:52] <Laney> which is because I tranferred mail providers
[10:54] <pitti> I have 7 MB in my mail folders..
[10:55] <Laney> oh, nice
[10:55] <Laney> fastmail has an auto-purge setting
[10:56] <Laney> I think I'll enable that for some mailboxes
[11:06] <happyaron> seb128: it will improve kubuntu's experience, but not really interesting enough for unity/gnome
[11:06] <happyaron> seb128: what do you think then?
[11:12] <seb128> happyaron, your call as the maintainer, if you are interested in it feel free to SRU, otherwise you can let somebody from the kubuntu team judge if they want it and handle the SRU...
[11:13] <happyaron> ok
[11:54]  * Laney eyes offlineimap
[11:55] <Laney> why is it downloading my whole inbox again...
[13:09] <pitti> seb128: upower patches landed upstream now
[13:10] <pitti> they will only help so far, but should at least stop crashing
[13:10] <seb128> pitti, great, thanks!
[13:10] <pitti> seb128: I guess I'll toss them in a PPA and ask affected people how it goes?
[13:10] <seb128> pitti, do we need u-s-d code change to use a new function?
[13:10] <seb128> pitti, sounds good
[13:11] <pitti> seb128: no, it stays API compatible, and the ABI change is just that up_client_new() now returns NULL if dbus fails
[13:11] <pitti> seb128: which should generally perform better, as methods then return default values instaed of crashing
[13:11] <seb128> great
[13:11] <pitti> seb128: you *can* now improve error handling by explicitly checking for == NULL
[13:11] <pitti> (and should too)
[13:11] <seb128> right
[13:12] <pitti> but still, if upowerd doesn't work, then data displayed in the UI will be wrong
[13:12] <pitti> so in the end we still need the kernel fix
[13:12] <seb128> yeah, no wait out of this
[13:12] <seb128> no crash but no power management plugin either
[13:20] <pitti> done
[14:13] <willcooke> attente, is seb128's video flickering green for you?
[14:13] <seb128> willcooke, no
[14:13] <attente> willcooke: no
[14:13] <seb128> sorry, it's not at the  bottom of my own hangout ;-)
[14:13] <seb128> willcooke, is that only me?
[14:13] <willcooke> yeah
[14:13] <attente> willcooke: seb is looking a bit pale though
[14:13] <attente> :P
[14:14] <willcooke> and now it's stopped
[14:14] <seb128> needs summer!
[14:14] <willcooke> very suspicious
[14:26] <alexarnaud_> seb128: is it possible to pay Canonica to make development on Compiz? If yes, which one we should contact for that ?
[14:26] <seb128> willcooke, ^
[14:27] <willcooke> alexarnaud_, drop me an email<EMAIL_ADDRESS>- but on the whole, that's not something we offer.  Sorry
[14:33] <a1fa> andrea, you around?
[16:12] <andyrock> a1fa: is andrea me?
[16:12] <andyrock> :D
[16:22] <a1fa> yeah
[16:22] <a1fa> i finally caught that bug i was telling you
[16:22] <a1fa> https://bugs.launchpad.net/ubuntu/+source/unity/+bug/1582056
[16:33] <Trevinho> pitti: hey, thanks for the upower review (I wanted to do something like that, but I didn't want to change too much, but with your OK, I'll fix it)...
[16:35] <Trevinho> pitti: also, I've seen you've SRUed gnome-session, could you do the same for upstart that is linked to the same bug 1433013?
[16:35] <Trevinho> pitti: also, since we're there... I've some compiz and unity SRUs waiting in the trusty silo, which I've been requested to clear up
[16:37] <seb128> poor pitti
[16:38] <seb128> Trevinho, Laney did the gnome-session SRU if I read things correctly
[16:38] <seb128> pitti just did queue review
[16:38] <Trevinho> seb128: yeah, right....
[16:38] <Trevinho> seb128: well, I'd like to push upstart, but... Can I just prepare a debdiff and someone sponsor it?
[16:39] <seb128> yes
[16:39] <seb128> subscribe sponsors
[16:39] <seb128> or see if xnox or Laney are interested by helping you
[16:39] <seb128> see they looked a bit a the changes already
[16:41] <xnox> upstart -> i am very busy but was hoping to do it by end of week
[16:41] <xnox> Trevinho, seb128.
[16:42] <seb128> xnox, thanks!
[16:42] <Trevinho> xnox: ah, ok... if you want I can prepare a debdiff to make things quicker for you?
[16:44] <Trevinho> xnox: however, should I just apply the patch to the code or add quilt patches?
[16:44] <xnox> it should be in upstart bazaar branch.
[16:44] <xnox> and merged properly.
[16:45] <xnox> Trevinho, it would be best if you would be on the hook to verify it when it hits xenial.
[16:45] <xnox> cause i will be away next week.
[16:45] <Trevinho> xnox: well, it's already in the upstream branch, but I don't see branches for xenial...
[16:46] <Trevinho> xbox and the SRU should include both lp:~xnox/upstart/lp1433013 and lp:~3v1n0/upstart/activation-proper-dbus-path
[16:47] <Trevinho> they're both merged and released to yakkety, that's why I just wanted to fix the xenial pkg
[20:26] <pitti> Trevinho: upower> I think at least for upstream "cleaner" beats "smaller"
[20:26] <pitti> Trevinho: I didn't upload gnome-session, but I processed the queue; I didn't see an upstart upload there, WDYM?