=== maclin1 is now known as maclin
[07:37] <mardy> seb128: hi! Do you happen to know where apps store their logs under unity8 (zesty)?
[07:37] <seb128> mardy, hey, no idea, try journalctl maybe?
[07:39] <mardy> seb128: yep, I tried "journalctl --user" but it says no journals were found
[07:39] <seb128> mardy, try the system one maybe, otherwise I don't know
[07:39] <seb128> but Saviq and others probably do
[07:40] <mardy> seb128: yep, thanks (just pinged you as I saw you logging in :-) )
[07:40] <seb128> np!
[07:40] <mardy> Saviq: hi! Do you know where to find the logs? ^
=== maclin1 is now known as maclin
=== maclin1 is now known as maclin
[09:17] <Saviq> mardy, they are launched as systemd services, so if anywhere, it would be in journald
[09:18] <Saviq> mardy, yeah, they are, but you need to give the full unit name:
[09:18] <Saviq> $ journalctl --user-unit ubuntu-app-launch-application-legacy-ubuntu-system-settings-.service
[09:18] <Saviq> not sure why plain `$ journalctl --user` doesn't give the same
[09:56] <tsdgeos> Saviq: Mirv: didn't we already fix https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1641175 https://bugs.launchpad.net/ubuntu/+source/linux/+bug/1630906 ?
[09:56] <ubot5> Ubuntu bug 1641175 in unity8 (Ubuntu) "unity8 fails to build in arm64 because of tests segfault" [Critical,Confirmed]
[09:56] <ubot5> Ubuntu bug 1630906 in qtdeclarative-opensource-src (Ubuntu RTM) "QML segfault on arm64 due to builder kernel change" [Undecided,In progress]
[09:57] <mardy> Saviq: ah, thanks a lot!
[09:57] <Saviq> tsdgeos, no, Mirv found i386 issues
[09:57] <tsdgeos> ah right
[09:58] <tsdgeos> want me to try to have a quick look?
[09:58] <Saviq> Mirv would have to tell where he's at
[09:59] <tsdgeos> Saviq: should we kill https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1367822 ?
[09:59] <ubot5> Ubuntu bug 1367822 in Ubuntu UX "[Scopes] Process required to pin a shortcut to the launcher does not fit users mental model" [High,In progress]
[09:59] <Saviq> tsdgeos, right, doing
[10:03] <Mirv> Saviq: tsdgeos: it's still sitting in https://bileto.ubuntu.com/#/ticket/2519 - as you can see in unity8 i386 (and armhf actually) tests at https://bileto.ubuntu.com/excuses/2519/xenial.html , there are new segfaults. I don't see anything remotely possibly having a fix in the 5.6 branch that I could additionally cherry-pick, so kind of only hope is that the final 5.6.3 will magically fix those issues
[10:04] <Mirv> tsdgeos: this was the thing where I showed that there are only 1.5 pages sof commits since 5.6.2 in qtdeclarative: http://code.qt.io/cgit/qt/qtdeclarative.git/log/?h=5.6
[10:05] <Mirv> three are picked, all hinted by upstream originally some months ago
[10:08] <tsdgeos> Saviq: want me to try to update https://unity.ubuntu.com/getinvolved/development/unity8/ yet again?
[10:13] <Saviq> tsdgeos, I'd like us focus on the current buglist first http://goo.gl/nTYdDQ
[10:13] <tsdgeos> ok
[10:14] <Saviq> if there's any that are not pwned, please take it
[10:15] <tsdgeos> Saviq: if you have some time, have a look at my last comment on https://bugs.launchpad.net/canonical-devices-system-image/+bug/1525285
[10:15] <ubot5> Ubuntu bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Triaged]
[10:15] <tsdgeos> not convinced it's a bug anymore (or maybe some xmir defaulting "fixed" it)
[10:16] <Saviq> tsdgeos, try taking a screenshot with unity8 ;)
[10:16] <Saviq> having first removed the registry
[10:20] <tsdgeos> ok
[10:20] <tsdgeos> 10% battery and can't find the power brick :D
[10:27] <tsdgeos> ok, at my parents place, bus
[10:29] <Saviq> tsdgeos, http://paste.ubuntu.com/24214533/ is what I get in unity8 when trying to take a screenshot without a registry present
[10:31] <Saviq> although it doesn't look like it's clutter responsible necessarily http://paste.ubuntu.com/24214540/
[10:32] <Saviq> maek that http://paste.ubuntu.com/24214544/
[10:33] <Saviq> greyback_, is thread 12 waiting for thread 27 is waiting for thread 12 is waiting for thread 27 is waiting for thread 12... you know what I mean ↑?
[10:36] <greyback_> Saviq: I do. Is this a multimonitor setup?
[10:36] <Saviq> greyback_, it is
[10:37] <greyback_> Saviq: ok, that makes sense. Threads 26&27 are render threads, they're both waiting inside processEventsAndWaitForMore which is ok, they're waiting to be told to render something new
[10:38] <greyback_> Saviq: thread 12 being blocked there is bad, means Qt GUI thread blocked
[10:38] <Saviq> greyback_, context: was trying to take a screenshot, hence gst in thread 27 trying to redo the registry
[10:38] <Saviq> and I'm thinking while doing so, it tried to connect to Mir and we're trying to see if we authorize it in thread 12?
[10:39] <Saviq> hmm but we shouldn't deadlock on that should we
[10:39] <greyback_> Saviq: possible. I don't get why taking a screenshot causes registry "redo" though
[10:39] <Saviq> greyback_, because there wasn't any yet
[10:39] <Saviq> am trying to see where we are with bug #1525285
[10:39] <ubot5> bug 1525285 in clutter-gst-3.0 (Ubuntu) "inspecting clutter plugin hangs outside X11" [High,Triaged] https://launchpad.net/bugs/1525285
[10:40] <Saviq> greyback_, and taking a screenshot causes sound
[10:40] <greyback_> Saviq: ah ok, understood
[10:41] <greyback_> then we're in a pickle
[10:41] <greyback_> need to do session authorization outside the Qt GUI thread
[10:42] <greyback_> which is do-able I think
[10:43] <greyback_> I'm still a bit surprised gst connects to mir
[10:47] <Saviq> greyback_, yeah well that might be part of the bug
[10:49] <Saviq> it actually spawns gst-plugin-scanner
[10:52] <Saviq> and yeah, it's the clutter plugin that tries to connect to mir
[10:53] <greyback_> and this is all blocking? ugg
[10:53] <Saviq> http://pastebin.ubuntu.com/24214612/
[10:54] <Saviq> that's gst-plugin-scanner's trace
[10:54] <Saviq> tsdgeos, ↑
[10:54] <Saviq> so the problem only seems to exist now if the registry is being scanned from within unity8
[10:54] <Saviq> but why would clutter contact the display server in the first place...
[10:54] <tsdgeos> same-ish as mine, no?
[10:55] <tsdgeos> upstream quickly waved off to gtk
[10:55] <tsdgeos> see the upstream bug i linked
[10:55] <tsdgeos> i was thinking while on the bus
[10:56] <tsdgeos> is it a deadlock because Unity8 wants to connect to Unity8 ?
[10:56] <Saviq> tsdgeos, no, unity8 → gst-plugin-scanner → unity8
[10:56] <Saviq> so... -ish
[10:56] <Saviq> brb
[11:06] <Saviq> so yeah, there are a bunch of problems here - gst blocking on registry generation (suppose it has to, to actually be able to play), clutter connecting to the display server, unity8 not able to reply to a auth request when gst is blocking it
[11:09] <Saviq> but we'd have rejected the connection anyway
[11:10] <tsdgeos> that's fine
[11:10] <tsdgeos> if you run gst-plugin-scanner in a user that has no connection
[11:10] <tsdgeos> it suceeds
[11:13] <Saviq> tsdgeos, well, not fine, as your own tests shows - if you run under a user that *does* run Mir, it fails (hangs?)
[11:13] <Saviq> and that's not because the unity8 → unity8 loop
[11:13] <Saviq> https://bugzilla.gnome.org/show_bug.cgi?id=780193#c5
[11:13] <ubot5> Gnome bug 780193 in Backend: Mir "inspecting clutter plugin hangs outside X11" [Normal,New]
[11:13] <tsdgeos> yep
[11:14] <tsdgeos> actually since i was running it from a VT
[11:14] <tsdgeos> i'm not convinced it got stuck
[11:14] <tsdgeos> or was hit by "unity8 is not focused so it's suspended"
[11:14] <tsdgeos> want to try to reproduce it again from unity8 itself
[11:20] <Saviq> when ran from a terminal, it does hang here... but so does it under unity7
[11:20] <Saviq> with -l that is
[11:21] <Saviq> ah but that's likely for RPC
[11:22] <tsdgeos> Saviq: yeah, running gst-inspect-1.0 from konsole inside unity8 it's "ok"
[11:23] <tsdgeos> yeah, it hangs in a VT because untiy8 is suspended
[11:23] <tsdgeos> if i swtich to unity8 VT and come back
[11:23] <tsdgeos> it finished
[11:23] <tsdgeos> so i'd say the main problem is really "unity8 not able to reply to a auth request when gst is blocking it"
[11:23] <tsdgeos> and i guess this one is actually in our reach to fix
[11:24] <Saviq> tsdgeos, well, yeah, -ish, since the clutter plugin gets rejected
[11:24] <tsdgeos> which is fine
[11:24] <tsdgeos> we don't want/need clutter
[11:24] <Saviq> sure we don't?
[11:25] <Saviq> what if a user switches to a gnome-shell session then
[11:25] <Saviq> I mean, sure, fine, but meh
[11:25] <tsdgeos> that'd be a problem for gst to fix
[11:26] <tsdgeos> not assuming that if featureY failed today, it will fail forever
[11:26] <tsdgeos> out of scope for our bug if you ask me
[11:26] <Saviq> tsdgeos, well, yes, *we* need to fix the auth block
[11:27] <Saviq> doesn't change the fact that the bug's there in gst-clutter
[11:31] <Saviq> I've updated the description
[11:36] <Saviq> greyback, so I've updated bug #1525285 - while I still think this is a gst-clutter bug, we need to try and make sure things like that don't bite us, and do the auth in a separate thread (and we should be able to, right? at most, we're simply talking to UAL for that?)
[11:36] <ubot5> bug 1525285 in qtmir (Ubuntu) "Unity8 deadlock when trying to screenshot without a current gst registry" [High,Triaged] https://launchpad.net/bugs/1525285
[11:37] <Saviq> it'd be good to get it done for Zesty release
[11:38] <greyback> Saviq: yep we should be able to. Just requires some shimmying of code around and a little thread safety thinking
[11:45] <tsdgeos> Mirv: i'm 34.65% you need a uitk rebuild in that silo
[11:45] <tsdgeos> since it's using some qv4 private classes affected by the patches
[12:12] <Mirv> tsdgeos: oh, thanks for the tip, trying that out
[13:19] <tsdgeos> Mirv: rebuild fixes the crash locally, you may need to rebuild anything that depends on  qtdeclarative5-private-dev
[13:19] <tsdgeos> to be on the safe side
=== JanC is now known as Guest30327
=== JanC_ is now known as JanC
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== jjb is now known as oao
=== oao is now known as jjb
=== JanC_ is now known as JanC
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
=== Saviq_ is now known as Saviq