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