=== nudtrobert1 is now known as nudtrobert | ||
=== Malsasa is now known as Guest40949 | ||
=== Malsasa_ is now known as Malsasa | ||
tsdgeos | mzanetti: hi ho | 07:18 |
---|---|---|
mzanetti | tsdgeos, hey | 08:20 |
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:21 |
tsdgeos | i do not know :D | 08:22 |
tsdgeos | because it's what we did until it stopped working ? | 08:22 |
tsdgeos | :D | 08:22 |
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:23 |
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:24 |
tsdgeos | hmmm, really? | 08:25 |
* tsdgeos checks | 08:25 | |
mzanetti | could be that we need to do a manual sync | 08:25 |
tsdgeos | mzanetti: http://paste.ubuntu.com/12416173/ | 08:26 |
mzanetti | yes that last landing needs to be pushed to trunk | 08:27 |
tsdgeos | ok | 08:30 |
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:33 |
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:34 |
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:35 |
pstolowski | mzanetti, ah, it landed in trunk15.04 branch, ok | 08:38 |
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:39 |
tsdgeos | makes sense | 08:40 |
* mzanetti gets some coffee | 08:40 | |
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:42 |
pstolowski | greyback, symbols are different | 08:48 |
greyback | pstolowski: yeah. Annoying | 08:48 |
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 | 08:51 |
greyback | tsdgeos: https://bugs.launchpad.net/ubuntu/+source/ubuntu-app-launch/+bug/1495871/comments/6 | 09:53 |
ubot5 | Ubuntu bug 1495871 in unity8 (Ubuntu) "unity8 leaks file descriptors" [Critical,Confirmed] | 09:53 |
tsdgeos | yes | 09:53 |
tsdgeos | you have the same thing i have :) | 09:53 |
greyback | great :D | 09:53 |
greyback | my glib-fu ain't the best, not seeing any obvious leak anywy | 09:54 |
greyback | tsdgeos: http://pastebin.ubuntu.com/12416538/ <- maybe "creationcontext != NULL" ? | 09:56 |
greyback | hmm no | 09:57 |
tsdgeos | nah | 09:57 |
* 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? | 09:59 |
* tsdgeos gives it a quick try | 10:00 | |
tsdgeos | dednick: what do you mean in your last comment to https://code.launchpad.net/~nick-dedekind/unity8/lp1378821.time-translation/+merge/265006 ? | 11:22 |
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:24 |
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:25 |
dednick | can bring it back in uitk if we ever need it. | 11:26 |
dednick | using the new stuff i put in there. | 11:26 |
=== alan_g is now known as alan_g|lunch | ||
tsdgeos | dednick: makes sense, anyhow, retarget to the overlay branch? | 12:26 |
=== alan_g|lunch is now known as alan_g | ||
dednick | tsdgeos: should not be going into trunk as well? | 13:11 |
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:12 |
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:13 |
mzanetti | but we're talking to CI to run both, wily and vivid in one go on trunk | 13:14 |
tedg | tsdgeos: I would think so. Usually I do "bzr bd" but I think both should work. | 13:21 |
tsdgeos | tedg: on vivid? could you try? | 13:22 |
tedg | tsdgeos: Sure, building now. | 13:22 |
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 |
ubot5 | Ubuntu bug 1495871 in unity8 (Ubuntu) "unity8 leaks file descriptors" [Critical,Confirmed] | 13:23 |
tsdgeos | both gerry and me seem to have reached the conclusion something happens in ubuntu-app-launch that causes it | 13:23 |
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:24 | |
tsdgeos | let me try bzr bd | 13:25 |
tsdgeos | tedg: so bzr bd works and dpkg-buildpage no :S | 13:32 |
tedg | Huh, I wonder why that is. | 13:33 |
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:34 |
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:35 |
tedg | tsdgeos: K | 13:36 |
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:48 |
tedg | Sure, but I don't have one with a current image and writeable and all that. | 13:49 |
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:50 |
davmor2 | tedg: https://www.youtube.com/watch?v=l-O5IHVhWj0 | 13:51 |
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:52 |
tsdgeos | i straced and counted the eventfd() + close | 13:53 |
tsdgeos | but of course that's very manual | 13:53 |
tsdgeos | tedg: valgrind can | 13:54 |
tsdgeos | –track-fds=yes | 13:54 |
tsdgeos | -- | 13:54 |
tedg | tsdgeos: Don't think that fixed it. | 13:56 |
tedg | tsdgeos: Valgrind has some errors for it. | 13:56 |
larsu | tedg: g_autoptr() ! | 13:57 |
tsdgeos | tedg: ok, so no need for me to try for now? or still want me to try? | 13:58 |
tedg | tsdgeos: Don't try right now, seems dbus-test-runner is causing a lot of noise here :-( | 14:00 |
tedg | larsu: More complex here as we're tracking out of the stack. | 14:01 |
larsu | just a random drive by comment :) | 14:02 |
tsdgeos | ok | 14:02 |
seb128 | hum | 14:06 |
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:07 |
seb128 | ChrisTownsend, ^ do you know? | 14:16 |
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:18 |
ChrisTownsend | seb128: It's working fine for me. Anything in unity8.log? | 14:21 |
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:24 |
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:25 | |
ChrisTownsend | larsu: Humor is always appreciated:) | 14:26 |
seb128 | failing to delete staled socket | 14:26 |
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:27 |
tedg | Not the results I wanted to report, but eh, focusing :-) | 14:28 |
tsdgeos | tedg: :) | 14:29 |
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! | 14:41 |
=== dandrader is now known as dandrader|afk | ||
=== alan_g is now known as alan_g|EOD | ||
=== dandrader|afk is now known as dandrader | ||
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:13 |
ubot5 | 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:13 |
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:32 |
=== dandrader is now known as dandrader|afk | ||
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:41 |
mzanetti | slangasek, ah ok. so for when the shell crashes | 20:44 |
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:45 |
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:47 |
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:48 |
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:49 |
mzanetti | right | 20:50 |
greyback | AlbertA: is that correct^^? If a mir server crashes, the contents of the video buffers would be dumped too? | 20:51 |
AlbertA | greyback: I don't think so... | 21:00 |
AlbertA | greyback: but I've never paid attention.... I guess the argument is they are mmap'ed they would? | 21:02 |
=== dandrader|afk is now known as dandrader | ||
greyback | AlbertA: I'm similarly clueless :) Will ask in my a.m. | 21:11 |
slangasek | AlbertA: yes, if they are mmapped they're going to get dumped along with everything else | 23:46 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!