=== maclin1 is now known as maclin
[07:52] <tsdgeos> mzanetti: are we landing any more branch on the overlay? or first doing the branch killing?
[07:52] <tsdgeos> because we're starting to stockpile again :D
[07:53] <mzanetti> tsdgeos, next ones will go to trunk again... let me check if the one that sync landed by now
[07:53] <mzanetti> it was QA'd last night
[07:54] <mzanetti> oh dear... hangs in proposed somewher
[07:57] <tsdgeos> :A
=== davidcalle_ is now known as davidcalle
[08:07] <mzanetti> I fail to understand those adt logs
[08:08] <mzanetti> seems to fail for qtmir and unity8
[08:08] <mzanetti> bootest says it can't do some apparmor things, whatever that means...
[09:38] <Mirv> Trevinho is great at spamming my bug folder :D
[09:39] <Trevinho> Mirv: yeah, I had to fire my script to keep things in sync
[09:39] <Trevinho> Mirv: and.... Well I didn't do that for compiz (yet) as there was 2600 bugs to fix... and it wasn't the case :)
[09:40] <Mirv> :)
=== jzheng is now known as jzheng_afk
=== nudtrobert1 is now known as nudtrobert
=== alan_g is now known as alan_g|lunch
=== cwayne-afk is now known as cwayne_
=== MacSlow is now known as MacSlow|lunch
=== alan_g|lunch is now known as alan_g
[13:39] <mzanetti> dandrader, there's a test failure in that silo 27: https://launchpadlibrarian.net/216844866/buildlog_ubuntu-wily-amd64.qtmir_0.4.6%2B15.10.20150910-0ubuntu1_BUILDING.txt.gz
[13:41] <dandrader> mzanetti, ok
[13:42] <mzanetti> let me know when to re-kick the build
[13:43] <dandrader> mzanetti, can you remove https://code.launchpad.net/~gerboland/qtmir/multimonitor/+merge/269906 from that silo?
[13:43] <dandrader> mzanetti, so that we can land the critical bug fix it contains
[13:45] <dandrader> mzanetti, and I guess it wouldn't hurt to add those qtubuntu ones as well: https://code.launchpad.net/~dandrader/qtubuntu/noQtSensors-lp1481389/+merge/267198 and https://code.launchpad.net/~dandrader/qtubuntu/provideMirConnection/+merge/269320
[13:46] <dandrader> they're pretty harmless
[13:56] <mzanetti> tsdgeos, ah, so it's because it's empty ("")?
=== MacSlow|lunch is now known as MacSlow
[13:59] <tsdgeos> mzanetti: yep
[13:59] <mzanetti> tsdgeos, right... makes sense. approved
[14:13] <mzanetti> dandrader, silo building, including those qtubuntu branches
[14:13] <dandrader> mzanetti, thanks!
[14:14] <mzanetti> oops. missed the one to remove
[14:14] <mzanetti> will redo
=== dandrader_ is now known as dandrader
=== dandrader is now known as dandrader|afk
=== alan_g is now known as alan_g|afk
[15:10] <tsdgeos> hate it when this happens
[15:10] <tsdgeos> call deleteLater on an objcet and doesn't get deleted
[15:10] <tsdgeos> :'(
[15:21] <tsdgeos> found out why!
[15:23] <tsdgeos> need to be careful when reimplementing ::event
=== alan_g|afk is now known as alan_g
=== dandrader|afk is now known as dandrader
[16:34] <dandrader> mzanetti, what's the next step for silo 027?
=== alan_g is now known as alan_g|EOD
=== dandrader is now known as dandrader|afk
[17:32] <mzanetti> dandrader|afk, you walk through the branches in there and verify that the linked bugs are fixed and the promised features are working.
[17:32] <mzanetti> dandrader|afk, then you walk through the testplans: https://wiki.ubuntu.com/Process/Merges/TestPlans/QtMir
[17:33] <mzanetti> dandrader|afk, can't find one for QtUbuntu. Make sure related functionality isn't broken
[17:34] <mzanetti> when you're happy with the results, go here and leave a comment that you've tested it and on what device/image: https://requests.ci-train.ubuntu.com/#/ticket/328
[17:34] <mzanetti> dandrader|afk, for example, like this: https://requests.ci-train.ubuntu.com/#/ticket/285
[17:35] <mzanetti> dandrader|afk, test at least on rc-proposed, if things could be different for wily, test both
=== dandrader|afk is now known as dandrader
[18:26] <kgunn> mzanetti: i don't mind helping to test silo27, that's multimonitor right ?
[19:23] <slangasek> mzanetti: hi, kgunn pointed me your way regarding this: https://bugs.launchpad.net/canonical-devices-system-image/+bug/1278780/comments/8
[19:23] <ubot5> Ubuntu bug 1278780 in apport (Ubuntu) "apport takes too long to write crash report, appears to lock up phone" [High,Triaged]
[19:28] <dandrader> mzanetti should be past his EOD by now
[19:31] <slangasek> dandrader: I imagine so; IRC is a decent messaging service though :)
[19:36] <kgunn> and he's known to have the problem of not being able to stay away
[19:39] <dandrader> slangasek, problem is, he will be back only next Tuesday :(
[19:39] <dandrader> kgunn, and there's that as well :)
[19:43] <kgunn> ah dang...forgot he was taking some days
[19:43] <kgunn> slangasek: what is your idea btw
[19:50] <slangasek> kgunn: so the basic idea is, can we make the crash handler faster for critical components (such as the system compositor or unity8 shell) by having those programs register a custom SIGSEGV handler that unmaps video buffers (for example) and re-raises
[19:51] <slangasek> kgunn: I don't know if this is safe to do from inside a signal handler, it depends on how the mapping/unmapping is handled; and I don't know if the video memory is a large enough part of the process's address space to make a difference
[19:51] <slangasek> but I thought it was an idea worth exploring
[19:52] <kgunn> yeah, the video memory might be the booger
[19:52] <slangasek> because ultimately, the kind of behavior we've heard described - UI locking up for a minute while the crash handler runs - does sound like it's taking an unreasonably long time for what it /ought/ to be doing
=== dandrader is now known as dandrader|afk
[20:42] <pmcgowan> kgunn, I just got https://bugs.launchpad.net/canonical-devices-system-image/+bug/1491566
[20:42] <ubot5> Ubuntu bug 1491566 in Canonical System Image "Shell not responsive after an incoming SMS" [Critical,Confirmed]
[20:42] <pmcgowan> added the logs, its still in the stuck state
[20:42] <pmcgowan> dandrader|afk, ^
=== dandrader|afk is now known as dandrader
[21:12] <dandrader> pmcgowan, still have the device in that state?
[21:14] <dandrader> pmcgowan, https://bugs.launchpad.net/canonical-devices-system-image/+bug/1491566/comments/26
[21:14] <ubot5> Ubuntu bug 1491566 in Canonical System Image "Shell not responsive after an incoming SMS" [Critical,Confirmed]
[21:16] <dandrader> so unity8.log shows a log of input events but I can't tell whether those events are *all* from before unity8 became unresponsive or not. What I want to know there is whether it still logs input events *after* it becomes unresponsive
[21:17] <dandrader> I didn't realize that when I posted the original instructions. Rectified it only in comment #26
[21:18] <dandrader> same goes for unity-system-compositor.log
[21:19] <pmcgowan> dandrader, there was nothing logged after the system froze
[21:19] <pmcgowan> also see stack trace I added
[21:19] <pmcgowan> I just restarted lightdm a few mins ago
[21:19] <dandrader> oh :(
[21:19] <pmcgowan> well wanted to get my messages :(
[21:20] <pmcgowan> dandrader, touching the screen I see the touch driver but nothing else get active
[21:20] <dandrader> alf is the one intereseted in the stack  traces. but I can tell they're not all that interesting as you didn't have debug symbols
[21:21] <dandrader> pmcgowan, what do you mean by "I see the touch driver"?
[21:22] <pmcgowan> dandrader, a process called mtk-tpd
[21:22] <dandrader> pmcgowan. so no new messages came to unity8.log or unity-system-compositor.log when you touched the screen while the device was unresponsive?'
[21:23] <pmcgowan> dandrader, correct, if I tail the logs nothing new
[21:23] <dandrader> pmcgowan, that's a very important bit of info, it's worth commenting that in the bug report
[21:23] <pmcgowan> will do
[21:33] <dandrader> bregma, do you recall what tool we can use to monitor events coming out of evedev files?
[21:39] <dandrader> evemu-tools