[07:18] <tsdgeos> mzanetti: hi ho
[08:20] <mzanetti> tsdgeos, hey
[08:21] <tsdgeos> mzanetti: so that new silo landed, now the vivid only silos don't build anymore
[08:21] <mzanetti> tsdgeos, why do we have vivid-only silos?
[08:22] <tsdgeos> i do not know :D
[08:22] <tsdgeos> because it's what we did until it stopped working ?
[08:22] <tsdgeos> :D
[08:23] <tsdgeos> what are we supposed to have now?
[08:23] <mzanetti> ah. you mean the old ones, like in-card music
[08:23] <tsdgeos> yes
[08:23] <mzanetti> we're back to dual landing
[08:23] <tsdgeos> off the overlay branch?
[08:23] <mzanetti> yes
[08:24] <tsdgeos> funnies
[08:24] <mzanetti> doesn't really matter as trunk & overlay are the same now
[08:24] <mzanetti> except the changelog
[08:24] <tsdgeos> no, they're not the same at all
[08:24] <mzanetti> they should be :D
[08:25] <tsdgeos> hmmm, really?
[08:25]  * tsdgeos checks
[08:25] <mzanetti> could be that we need to do a manual sync
[08:26] <tsdgeos> mzanetti: http://paste.ubuntu.com/12416173/
[08:27] <mzanetti> yes that last landing needs to be pushed to trunk
[08:30] <tsdgeos> ok
[08:33] <pstolowski> mzanetti, hey, some of the projects we have in silo 4 cannot be dual-landed, i need to land them separately in V and W
[08:33] <mzanetti> and there we go again
[08:34] <mzanetti> :D
[08:34] <pstolowski> mzanetti, e.g. mediascanner2
[08:34] <mzanetti> so we need to split the silo I guess
[08:34] <pstolowski> mzanetti, yes
[08:34] <mzanetti> and land mediascanner before this one
[08:34] <mzanetti> to both
[08:35] <pstolowski> mzanetti, also, Saviq had a branch of unity-api which merges V+W back into single tree, but i cannot find it..
[08:35] <mzanetti> i landed
[08:35] <mzanetti> it
[08:35] <greyback> pstolowski: why can't you dual land?
[08:35] <pstolowski> greyback, symbols
[08:38] <pstolowski> mzanetti, ah, it landed in trunk15.04 branch, ok
[08:39] <mzanetti> tsdgeos, ok. trunk and overlay are the same now. for now we still oser overlay tho, because that's where CI we want runs on
[08:39] <mzanetti> s/oser/user/
[08:39] <mzanetti> gees
[08:39] <mzanetti> use
[08:39] <mzanetti> :D
[08:40] <tsdgeos> makes sense
[08:40]  * mzanetti gets some coffee
[08:42] <greyback> pstolowski: is it the package name that is different between the v+o & w, or the actual symbols themselves are different (because gcc4.9/5)?
[08:48] <pstolowski> greyback, symbols are different
[08:48] <greyback> pstolowski: yeah. Annoying
[08:51] <ltinkl> tsdgeos, mzanetti: silo 33 is vivid only, and we managed to get it build yesterday, after much changelog+version torturing :)
[08:51] <mzanetti> :D
[08:51] <mzanetti> well, should be dual landing now
[08:51] <ltinkl> I know
[08:51] <ltinkl> design desperately wanted it
[09:53] <greyback> tsdgeos: https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1495871/comments/6
[09:53] <tsdgeos> yes
[09:53] <tsdgeos> you have the same thing i have :)
[09:53] <greyback> great :D
[09:54] <greyback> my glib-fu ain't the best, not seeing any obvious leak anywy
[09:56] <greyback> tsdgeos: http://pastebin.ubuntu.com/12416538/ <- maybe  "creationcontext != NULL" ?
[09:57] <greyback> hmm no
[09:57] <tsdgeos> nah
[09:59]  * guest42315 aw-food
[09:59] <tsdgeos> or maybe
[09:59] <tsdgeos> does g_dbus_connection_close_sync(cgmanager, NULL, &error); need to be moved up that if?
[10:00]  * tsdgeos gives it a quick try
[11:22] <tsdgeos> dednick: what do you mean in your last comment to https://code.launchpad.net/~nick-dedekind/unity8/lp1378821.time-translation/+merge/265006 ?
[11:24] <dednick> tsdgeos: if we have a absolute time. ie "7th September 2015" and we change the system timezone, it will not update.
[11:24] <tsdgeos> tedg: am i supposed to be able to dpkg-buildpackage ubuntu-app-launch in the desktop? tests don't seem to pass
[11:25] <dednick> but i dont think it'll actually be used. i was thinking about ltinkl using it, but he was just looking for a place to put a method.
[11:25] <tsdgeos> dednick: so you're saying that we can't remove it?
[11:25] <tsdgeos> or?
[11:25] <dednick> for formatting time with a specified timezone
[11:25] <tsdgeos> food! bbl
[11:25] <dednick> tsdgeos: well, i think we'll need it at some point, but not right now. since we only use relative times.
[11:26] <dednick> can bring it back in uitk if we ever need it.
[11:26] <dednick> using the new stuff i put in there.
[12:26] <tsdgeos> dednick: makes sense, anyhow, retarget to the overlay branch?
[13:11] <dednick> tsdgeos: should not be going into trunk as well?
[13:12] <tsdgeos> dednick: we target overlay that is what we care and then do a "sync push" to trunk
[13:12] <dednick> tsdgeos: ok
[13:12] <tsdgeos> or that's what i understood is our current strategy
[13:12] <tsdgeos> mzanetti: ↑↑↑↑
[13:13] <mzanetti> yes... for now
[13:13] <mzanetti> the plan is is to move back to trunk. but we don't have a vivid ci running on that yet
[13:13] <mzanetti> only wily which is secondary choice atm...
[13:14] <mzanetti> but we're talking to CI to run both, wily and vivid in one go on trunk
[13:21] <tedg> tsdgeos: I would think so. Usually I do "bzr bd" but I think both should work.
[13:22] <tsdgeos> tedg: on vivid? could you try?
[13:22] <tedg> tsdgeos: Sure, building now.
[13:23] <tsdgeos> tedg: and more importantly have a look at the fd leaking bug
[13:23] <tsdgeos> https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1495871/
[13:23] <tsdgeos> both gerry and me seem to have reached the conclusion something happens in ubuntu-app-launch that causes it
[13:24] <tedg> tsdgeos: Heh, you both are biased ;-)
[13:24] <tsdgeos> tedg: but we're also both right ;)
[13:24] <tedg> tsdgeos: It built for me.
[13:24] <tsdgeos> tedg: vivd? wily?
[13:24] <tedg> tsdgeos: vivid
[13:24]  * tsdgeos scratches head
[13:25] <tsdgeos> let me try bzr bd
[13:32] <tsdgeos> tedg: so bzr bd works and dpkg-buildpage no :S
[13:33] <tedg> Huh, I wonder why that is.
[13:34] <tedg> Is it the Upstart job tests that fail?
[13:34] <tsdgeos> dednick: qml/Panel/Indicators/MessageMenuItemFactory.qml conflict
[13:34] <tsdgeos> tedg: http://paste.ubuntu.com/12417570/
[13:34] <dednick> tsdgeos: ya, fixing it now.
[13:35] <tsdgeos> tedg: anyway, not jokin on the ubuntu-app-launch leaking the fds, there's a eventfd() call leaking and ubuntu-app-launch is responsible for the only 3 calls to eventfd() (via glib) when launching an app
[13:35] <tedg> tsdgeos: Hmm, yeah. It is testing the Upstart jobs.
[13:36] <tedg> tsdgeos: K
[13:48] <tedg> tsdgeos: gerry: Do you guys have a system set up where you can easily test it?
[13:48] <tsdgeos> tedg: yes
[13:48] <tsdgeos> the phone :D
[13:48] <tedg> I think this is likely the fix: lp:~ted/ubuntu-app-launch/lp1495871-unref-context
[13:49] <tedg> Sure, but I don't have one with a current image and writeable and all that.
[13:50] <tsdgeos> ah, would have never ever realized that what's needed
[13:50] <tsdgeos> the g*refing is too hard :D
[13:50]  * tsdgeos tries
[13:50] <tedg> Heh, yeah. It can be trickey.
[13:51] <davmor2> tedg: https://www.youtube.com/watch?v=l-O5IHVhWj0
[13:52] <tedg> tsdgeos: I'm not 100%, but I think that should be it. Not sure how I can count FDs in a unit test.
[13:52] <tedg> Does valgrind do that?
[13:52] <tsdgeos> don't know
[13:53] <tsdgeos> i straced and counted the eventfd() + close
[13:53] <tsdgeos> but of course that's very manual
[13:54] <tsdgeos> tedg: valgrind can
[13:54] <tsdgeos>  –track-fds=yes
[13:54] <tsdgeos> --
[13:56] <tedg> tsdgeos: Don't think that fixed it.
[13:56] <tedg> tsdgeos: Valgrind has some errors for it.
[13:57] <larsu> tedg: g_autoptr() !
[13:58] <tsdgeos> tedg: ok, so no need for me to try for now? or still want me to try?
[14:00] <tedg> tsdgeos: Don't try right now, seems dbus-test-runner is causing a lot of noise here :-(
[14:01] <tedg> larsu: More complex here as we're tracking out of the stack.
[14:02] <larsu> just a random drive by comment :)
[14:02] <tsdgeos> ok
[14:06] <seb128> hum
[14:07] <seb128> my wily laptop test machine fails to start applications under unity8
[14:07] <seb128> it was working 10 days ago
[14:07] <seb128> just dist upgraded
[14:07] <seb128> is there a known issue?
[14:16] <seb128> ChrisTownsend, ^ do you know?
[14:18] <ChrisTownsend> seb128: It was working yesterday, but I haven't tried today.  I'll try it right now.
[14:18] <seb128> k, I upgraded yesterday and again today, so likely something local
[14:18] <seb128> though my dash only list webbrowser and settings, I might want to try to install other apps
[14:21] <ChrisTownsend> seb128: It's working fine for me.  Anything in unity8.log?
[14:24] <seb128> ChrisTownsend, http://paste.ubuntu.com/12417795/
[14:24] <seb128> "ApplicationManager::onProcessStopped reports stop of appId= "ubuntu-system-settings" which AppMan is not managing, ignoring the event"
[14:24] <seb128> unsure if that's the issue
[14:25] <ChrisTownsend> seb128: How about the application log?
[14:25] <larsu> AppMan sounds like a super hero
[14:25] <seb128> cgmanager's job is failing to start
[14:25]  * larsu should stop spamming this channel with useless comments
[14:26] <ChrisTownsend> larsu: Humor is always appreciated:)
[14:26] <seb128> failing to delete staled socket
[14:27] <ChrisTownsend> seb128: Hmm, weird.  Sounds like a bug.
[14:27] <tedg> tsdgeos: Okay, I have a good trace now. I can confirm that didn't fix it.
[14:28] <tedg> Not the results I wanted to report, but eh, focusing :-)
[14:29] <tsdgeos> tedg: :)
[14:41] <seb128> ChrisTownsend, works after a reboot, something was wrong with the cgmanager, unsure what ... thanks anyway for looking!
[14:41] <ChrisTownsend> seb128: Ok, sure thing!
[20:13] <slangasek> mzanetti: so bug #1278780 is assigned to qtmir now; did you see my question about needing changes up and down the stack, to avoid libraries installing signal handlers?
[20:32] <mzanetti> slangasek, ok, so iiuc what we want is to intercept SIGSEGV in apps, release the connection to mir and then raise the signal again to get apparmor etc going, correct?
[20:41] <slangasek> mzanetti: no, this isn't about sigsegv handling in apps; I'm assuming that an app which is hung because it's stuck in the kernel crash handler is not going to lock up the ui
[20:41] <slangasek> mzanetti: this is about sigsegv handling in the compositor itself
[20:44] <mzanetti> slangasek, ah ok. so for when the shell crashes
[20:45] <mzanetti> so atm mir is handling some signals
[20:45] <mzanetti> also qtmir IIRC
[20:45] <mzanetti> anyhow, will discuss what the proper thing to do is.
[20:47] <slangasek> mzanetti: am I correct in supposing that a lot of the memory mir has mapped consists of video buffers?
[20:47] <greyback> slangasek: darn, I misunderstood you too
[20:48] <slangasek> maybe it would be helpful to free up video buffers from a sigsegv handler for apps also, but that's not the case that's of concern
[20:49] <slangasek> the problem we have right now is that if the shell crashes, the ui is locked for a long time while the kernel dumps all the memory across to apport, and it's probably dumping a lot that it shouldn't
[20:50] <mzanetti> right
[20:51] <greyback> AlbertA: is that correct^^? If a mir server crashes, the contents of the video buffers would be dumped too?
[21:00] <AlbertA> greyback: I don't think so...
[21:02] <AlbertA> greyback: but I've never paid attention.... I guess the argument is they are mmap'ed they would?
[21:11] <greyback> AlbertA: I'm similarly clueless :) Will ask in my a.m.
[23:46] <slangasek> AlbertA: yes, if they are mmapped they're going to get dumped along with everything else