[05:51]  * conyoo good morning o_O
[12:07] <mardy> Saviq: hi! I see that you marked bug 1436203 as incomplete, but I don't remember if you asked me for more logs, and if so, which
[12:10] <Saviq> mardy, it's rather because looking at the trace it seemed a crash in a lower level - hence the Mir task
[12:10] <mardy> Saviq: oh, indeed
[12:11] <mardy> dednick: do you know whom I should ping about this bug? ^
[12:11] <Saviq> greyback, you can be the first PoC ↑
[12:12] <greyback> Saviq: sure
[12:12] <greyback> mardy: hey
[12:20] <greyback> mardy: hmm my suspicion is that dash is shutting down prematurely for some reason, and there's a bug in qtubuntu where it's trying to destroy a gl context which hasn't been created yet. But why isn't obvious to me
[12:20] <greyback> mardy: can you still reproduce this? On a vivid install? vivid+overlay? wily?
[12:31] <mardy> greyback: I tried about one week ago, on wily
[12:31] <mardy> greyback: right now I don't have that laptop with me, but I can try it next week
[12:32] <greyback> mardy: yeah when you have it in front of you, ping me and maybe we can figure it out
[12:32] <mardy> greyback: basically, the shell loads fine, but the dash (and all apps, and the system settings) don't start
[12:32] <greyback> that scopeStyle error I don't see in my own logs
[12:32] <mardy> greyback: so I think that your guess of blaming qtubuntu sounds about right
[12:33] <greyback> mardy: well not quite, qtubuntu is crashing while destroying its gl context, which is something it usually only does on app shutdown
[12:34] <greyback> mardy: and yeah, it shouldn't do that. But there's some reason dash isn't fully starting up too
[12:35] <mardy> greyback: ok -- but since other apps are not starting either, I guess it's not a problem in the dash alone
[12:35] <mardy> greyback: but we'll see
[12:36] <greyback> mardy: ah you didn't mention that.
[12:36] <greyback> mardy: yeah, talk when you can debug with me
[12:58] <tsdgeos> greyback: ah you're here now
[12:58] <tsdgeos> greyback: see https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1475526
[12:58] <tsdgeos> greyback: we have asserts in libqpa-ubuntumirclient.so on startup of unity-dash
[12:59] <tsdgeos> greyback: any idea what would cause them?
[12:59] <greyback> tsdgeos: you ave any console output from unity8-dash?
[13:00] <tsdgeos> greyback: doesn't look like there's any, no
[13:01] <greyback> tsdgeos: lack of symbols for qtubuntu make it hard to know where it is crashing
[13:01] <tsdgeos> greyback: the constructor
[13:02] <greyback> unable to find mir server is a likely candidate
[13:02] <tsdgeos> greyback: well you only have one qFatal
[13:02] <tsdgeos> i would say "only" candidate
[13:03] <greyback> tsdgeos: you have a point
[13:03] <greyback> tsdgeos: then it means what the qFatal text is saying
[13:03] <tsdgeos> yes
[13:03] <tsdgeos> i know
[13:03] <tsdgeos> i commented that on the bug
[13:03] <tsdgeos> i'm just asking how that would happen
[13:03] <tsdgeos> since it's on phone boot
[13:04] <tsdgeos> and unity8 hasn't crahed
[13:04] <greyback> no other mir app should start until after unity8 has. upstart will only consider unity8 started after it has emitted a SIGSTOP
[13:04] <tsdgeos> it *must* be there, no?
[13:14] <greyback> tsdgeos: it's a tricky one to figure out, I don't see anything obvious we might have broken. We even have AP test to ensure sigstop emitted at the right time. Perhaps the MIR_SOCKET variable isn't being set in time by upstart and there's a race (unlikely)
[13:25] <greyback> tsdgeos: I replied to that bug with what I know. I don't have any obvious idea tho, sorry
[13:25] <tsdgeos> oka, no worries
[13:45] <dandrader> greyback, any idea where's the mir socket of qml-demo-shell?
[13:45] <dandrader> greyback, don't see it in /tmp
[13:46] <greyback> dandrader: it's usually there, /tmp/mir_socket
[13:47] <dandrader> greyback, but it's not there :/
[13:48] <greyback> dandrader: did you run it as root?
[13:48] <dandrader> greyback, yes
[13:48] <dandrader> greyback, will try to find it with lsof...
[13:48] <greyback> dandrader: /run/mir_socket maybe?
[13:48] <dandrader> greyback, nope...
[13:49] <greyback> dandrader: well it must have it opened somewhere. Else can specify one yourself with MIR_SERVER_HOST_SOCKET=/tmp/mir_socket
[13:49] <dandrader> greyback, will try that env var, way easier than hunting for it
[13:50] <dandrader> greyback, "std::exception::what: Nested Mir Platform Connection Error: Failed to connect to server socket: No such file or directory"
[13:51] <dandrader> greyback, it's stand-alone, not nested. so it's probably a different env var?
[13:51] <greyback> oh sorry, that's to tell a nested serer where the server socket is
[13:51] <greyback> dandrader: MIR_SERVER_FILE
[13:51] <greyback> or maybe MIR_SOCKET itself
[13:51] <dandrader> :)
[13:51] <greyback> never was clear which one was the right one
[13:52] <dandrader> MIR_SERVER_SOCKET?
[13:52] <dandrader> so many combinations...
[13:52] <greyback> maybe
[13:52] <greyback> oh great, mir landed in wily, but not in vivid+overlay
[13:53] <greyback> so I can't even get silo7 to dual-build any more
[13:53] <greyback> yay
[13:54] <tsdgeos> greyback: ouch
[13:54] <tsdgeos> is that a "mistake" on their side or what is supposed to happen from now on?
[13:54] <greyback> tsdgeos: something went wrong on their side
[13:55] <dandrader> greyback, it's MIR_SERVER_FILE
[13:55]  * dandrader writes it down
[13:55] <greyback> dandrader: cool. I also note it dwn
[13:56] <seb128> tsdgeos, hey, sorry you were away yesterday before I ponged
[13:56] <tsdgeos> seb128: hi there, i forgot what i was asking about :D
[13:57] <tsdgeos> seb128: some icons?
[13:57] <seb128> tsdgeos, I was the one asking about/discussing bugs and dednick pointd to you about fixing similar issues
[13:58] <tsdgeos> seb128: ok, i'm here if you need help
[13:58] <seb128> tsdgeos, basically http://paste.ubuntu.com/11892893/
[13:58] <seb128> tsdgeos, the image doesn't fill the shape
[13:58] <seb128> tsdgeos, http://people.canonical.com/~seb128/screenshot20150716_100355457.png is the result
[14:02] <dednick> seb128: what does the original image look like?
[14:03] <tsdgeos> seb128: any special reason you're using Icon and not Image?
[14:04] <dednick> seb128: have you tried: PreserveAspectFit?
[14:04] <dednick> oh right. crop should work :/
[14:04] <dednick> hm.
[14:05] <seb128> dednick, yes, I did, no difference
[14:05] <dednick> seb128: it's probably because the shadereffect is doing the rendering.
[14:05] <seb128> tsdgeos, yes, because that shape can contain icons and they need to be colored which image doesn't support
[14:06] <dednick> seb128: can't change icon.preserveaspectcrop can we?
[14:06] <seb128> dednick, not that I know no...
[14:07] <dednick> seb128: maybe try change it in the sdk to test. Icon10 uses Image: { fillmode: Image.PreserveAspectFit }
[14:07] <dednick> seb128: just as a sanity test
[14:08] <dednick> seb128: although it sounds like a bug in UbuntuShape.
[14:09] <seb128> dednick, what do you suggest changing in the sdk to test?
[14:10] <dednick> seb128: change the Icon image to use Image.PreserveAspectCrop, rather than Image.PreserveAspectFit
[14:10] <seb128> dednick, the original image is http://people.canonical.com/~seb128/img.png
[14:10] <dednick> seb128: give me a minute. i can try
[14:10] <dednick> handsome man.
[14:10] <seb128> lol
[14:10] <seb128> dednick, that change Icon10 solves it
[14:10] <tsdgeos> seb128: so that's what you want? http://paste.ubuntu.com/11892961/
[14:10] <dednick> seb128: hm. thought it might
[14:11] <seb128> tsdgeos, that indeed works, thanks :-)
[14:11] <tsdgeos> yw
[14:12] <seb128> dednick, ^
[14:13] <dednick> hm. why does removing the fill work?
[14:13] <dednick> seb128: hm. thought it might
[14:13] <dednick> eh
[14:13] <tsdgeos> dednick: because if you're making it big enough to start with
[14:13] <tsdgeos> the shared can't stretch it to really fill
[14:14] <tsdgeos> shared -> shared
[14:14] <tsdgeos> arg
[14:14] <tsdgeos> shader
[14:14] <dednick> tsdgeos: i c. :/
[14:15] <dednick> tsdgeos: so what if the image was a lot smaller?
[14:15] <dednick> hm. doesnt seem to matter
[14:17] <dednick> i guess we're forcing it's size for using a fill or something :/
[14:17] <dednick> whatever works!
[14:17] <dednick> lunch!
[14:20] <seb128> dednick, enjoy
[14:31] <greyback> MacSlow: a nice clean bug with a hopefully helpful summary of the task https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1475678
[14:31] <MacSlow> greyback, ah thanks... will link any branches to that then
[14:31] <greyback> np
[14:43] <greyback> mzanetti: you were doing the right thing, stopping animations by listening for the Qt.application.active property. But not everything will do that. We can at least stop the renderer if it's not needed
[14:44] <mzanetti> greyback, maybe... a bit worried we'll mess up things tho
[14:44] <greyback> mzanetti: how?
[14:44] <greyback> it does nothing to your QML scene. Just stops rendering useless frames
[14:44] <mzanetti> well, just discarding paint calls from the app will probably cause arifacts etc
[14:44] <mzanetti> but I'm not an expert in that stuff
[14:45] <MacSlow> mzanetti, I added the related bugs to the notes for reference
[14:45] <greyback> mzanetti: you're right, I anticipate glitches if we are not careful
[14:45] <greyback> mzanetti: as we'll first see an old frame, before we get a newly painted frame
[14:45] <tsdgeos> josharenson: i meant this branch https://code.launchpad.net/~josharenson/unity8/location_page_test/+merge/259801 is this the one you say you were making changes to?
[14:46] <josharenson> tsdgeos: oh no, sorry
[14:46] <tsdgeos> okidoki
[14:46] <tsdgeos> then i'll have a look :)
[14:46] <josharenson> tsdgeos: did you get the here maps version working?
[14:46] <tsdgeos> haven't tried yet
[14:46] <josharenson> ok
[14:46] <tsdgeos> that was my friday afternoon easy task :D
[15:28] <seb128> dednick, hum, for some reason it doesn't work correctly in the u-s-c/unity8 context :-/
[15:29] <dednick> seb128: can you pastebin the usc diff?
[15:31] <seb128> dednick, http://paste.ubuntu.com/11893244/
[15:31] <seb128> the image is hidden
[15:32] <seb128> changing the hideSource makes it being displayed
[15:32] <seb128> but it was bigger than the shape when I tried that
[15:53] <dednick> seb128: use UbuntuShape.source rather than UbuntuShape.image
[15:54] <seb128> dednick, I think I had tried that, but not today, so I need to try again
[15:54] <seb128> did you try it/does it work for you?
[15:54] <dednick> seb128: ya
[15:54] <dednick> seb128: works
[15:54] <seb128> cool
[15:55] <seb128> want to mp the version that works for you if you have one ready?
[15:55] <seb128> otherwise I can try that and submit a bit later
[15:55] <seb128> or likely on monday now
[15:55] <dednick> seb128: can do
[15:56] <seb128> thanks, so I can test/confirm if it works here :-)
[15:59] <dednick> seb128: is there a bug assigned?
[16:00] <seb128> dednick, bug #1450229
[16:00] <dednick> seb128: ta
[16:00] <seb128> dednick, yw!
[16:10] <dednick> seb128: https://code.launchpad.net/~nick-dedekind/ubuntu-settings-components/icon-aspect-ratio-crop/+merge/265146
[16:15] <seb128> dednick, thanks