#ubuntu-mir 2014-02-24
<RAOF> Why do we go through the whole CachedPtr<> rigmarole in DefaultServerConfiguration again?
 * duflu_ abstains, having forgot what CachedPtr was
<RAOF> Oh, it's probably breaking dependency chains.
<duflu> RAOF: Oh, yes, I remember those problems. Haven't had to deal with the ptr dependency cycles in a quite a while
<RAOF> And also to allow different parts of the codebase to implement different parts of the DefaultServerConfiguration.
<duflu> It feels a bit wrong that I have to wait for cross-compile-chroot to download stacks of libx* builddeps. I'm guessing that's probably Mesa
<duflu> Wow, still going. I wonder what Mir's using that uses so many X libraries
<RAOF> Mesa
<RAOF> Ah! You're the reason I remember build-depending on umockdev everywhere but then failed!
<duflu> Whee, gcc internal compiler error randomness
<duflu> And make -j1 fixes it :)
<RAOF> Bitchn'
<RAOF> duflu: I thought your objection to a umockdev dependency was that it makes it more difficult for other distros?
<RAOF> duflu: I don't see how that influences our day-to-day testing at all, since we won't be day-to-day testing other distros' packages?
<duflu> RAOF: Yes, that's my objective argument. The subjective argument is how inconvenienced I am personally. A script sounds like an option
<RAOF> A script to run on the device that'll correctly run the tests? Sure.
<duflu> RAOF: Yep. I already said this in the MP. It's delayed :)
<duflu> RAOF: On a related topic... https://code.launchpad.net/~vanvugt/mir/fix-1283951/+merge/207871
<duflu> alan_g: I've just started merging CompositingCritieria into Renderable. I hope you hadn't started.. ?
<duflu> There's a lot to fix yet and the diff is 1800+ lines :(
<alan_g> duflu: nope. I'll be distracted for a couple of days by the compositing issues that are behind https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1280842
<ubot5> Ubuntu bug 1280842 in mir (Ubuntu) "[enhancement] Need a method of hiding surfaces until they are ready to draw themselves" [Medium,Opinion]
<alan_g> I assume you've also checked against kdub's rework?
<duflu> alan_g: ?
<alan_g> The "overlay" stuff
<duflu> Fark.
 * duflu looks
<duflu> alan_g: OK, looks like he hasn't started on any such changes
<duflu> Phew
<duflu> Woo tree builds without CompositingCritieria. Now to make it *work*
<duflu> Dear bzr: Bandwidth?
<alan_g> Anyone know what started the "Cannot add PPA: 'ppa:chris.gagnon/mir-demo-tester'." failures?
<alf> alan_g: no
<alan_g> nm I'm asking on #ubuntu-ci-eng
<mzanetti> alf: hi, will you take care about getting this into trunk?
<mzanetti> https://code.launchpad.net/~mzanetti/mir/dont-crash-when-shooting-invalid-surface/+merge/207509
<alf> mzanetti: sure, do we want trunk or mir/devel?
<alf> (it will end up in both eventually)
<mzanetti> alf: well, we've manually patched this into the MWC image, so we're good there. I'd say just take the usual road into merging something to mir
<alf> mzanetti: ok, so that's lp:mir/devel, thanks
<duflu> alan_g: Wrapping std::atomic_bool with our own version wouldn't really hurt performance for Mir, and we could instantly silence a ton of helgrind race errors...
<duflu> Just a thought
<duflu> But good night
<alan_g> goodnight
<alan_g> alf: I just built development_branch and found that if I start a mir server and a client, then Ctrl+Alt+Backspace I can't start another server (or switch back to X) "ERROR: /home/alan/display_server/mir4/src/platform/graphics/mesa/display_helpers.cpp(234): Throw in function int mir::graphics::mesa::helpers::DRMHelper::open_drm_device(const std::shared_ptr<mir::udev::Context>&)" - I'm sure this was working recently and can
<alan_g> 't think what might have broken it. Any ideas?
<alf> greyback: Hi! The 'MirSurface' symbol from unityapplicationplugin can conflict with the MirSurface symbol in libmirclient7. We have the options of 1. renaming it 2. Namespacing it (+ all other classes in unityapplicationplugin)
<alf> greyback: are unityapplicationplugin symbols used outside of unity-mir?
<alf> alan_g: no ideas, let me try that
<greyback> alf: 2 best option. I can do it
<alf> greyback: great, please take a look at https://bugs.launchpad.net/mir/+bug/1282248 and feel free to reassign it to yourself, otherwise ping me and I can try fixing unity-mir
<ubot5> Ubuntu bug 1282248 in Mir "Unity8 crashes when using latest mir/android backend with system-compositor" [High,In progress]
<greyback> alf: ok
<alan_g> alf: I've just discovered that it works if I don't use "--launch-client" - so I guess that the client is "inheriting" stuff it shouldn't
<alf> alan_g: ok
<didrocks> alf: greyback: alan_g: hey, we are seeing a higher than usual CPU usage on touch than usual. That has impacts on the test and promoting an image.
<didrocks> The two processes on top, as pointed by psivaa are pulseaudio and unity-system-compositor
<didrocks> kgunn opened  https://launchpad.net/bugs/1279391 a while ago, do you know if this one is under work?
<ubot5> Ubuntu bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New]
<greyback> didrocks: hey, I don't know, but hopefully mterry can tell us, once he comes online
<didrocks> ok ;)
<alf> fginther: https://code.launchpad.net/~afrantzis/pbuilderjenkins/mir-reenable-valgrind-on-armhf/+merge/207936
 * alan_g finds nested mir less stable than it should be
<greyback> mterry: hey, didrocks was reporting issue with higher than normal CPU usage on Touch. The unity-system-compositor was one source of the issue. kgunn opened d  https://launchpad.net/bugs/1279391 a while ago, do you know if this one is under work?
<ubot5> Ubuntu bug 1279391 in Mir "[nested] inclusion of u-s-c as system comp not getting system load zero as quick as before" [Undecided,New]
<kgunn> mterry: greyback its not really under work, one reason for that is that the render chain did get slightly longer...u-s-c on android nested doesn't have bypass
<kgunn> i know the release team adjusted the settle time and this seemed to address the immediate problem
<greyback> didrocks: ^^
<didrocks> yeah, that was before today :)
<didrocks> (and it means that we accept the device, being idle, to take 2.5%)
<didrocks> but we thought we crossed the barrier again of 2.5%
<didrocks> we just have the real info now, the kernel changed its way to count "idle"
<didrocks> so, nothing increased in u-s-c or pulseaudio
<kgunn> didrocks: can you share a bit more ? so are you saying new kernel ...brought in new accounting method, so this was the culprit ?
<kgunn> if you want to pass me off to someone feel free
<didrocks> kgunn: yeah, exactly (more detail in my email in the end of day), before shutted down CPU was counting for 100% idle, now, they are just out of the global count
<didrocks> so only running CPU are taking into account
<didrocks> in the idle rate
<didrocks> imagine why everything increased :p
<alf> kgunn: didrocks: Why are we using the CPU at all at "idle" state? At least mir itself shouldn't be using any cpu while idle, unless something is feeding it events or new buffers.
<didrocks> alf: I guess that's why in the end the bug I mentionned will need to be looked at
<didrocks> can be unity8 as well
<alf> anpok: @null-snapshot-for-session-without-surface, what do you mean by "For the use case in unity we should provide a different interface"?
<anpok> alf: unity needs in a texture
<anpok> to display.. and in some cases at a low resolution
<anpok> and on the side stage case in full resolution
<anpok> on n4 and n10 you notice the delay in display update when those screenshots are made
<anpok> or uploaded?
<anpok> not sure which part affects it
<anpok> also of course the fact that full screen screen shots (maybe even without mip mapping?) are displayed in tiny rectangles is a bitodd
<alf> anpok: it's debatable whether unity needs a texture for this particular use case, since in the proper app lifecycle apps may be killed, so we will need a lot of GPU memory (for those devices that have it dedicated)
<anpok> sure
<anpok> but if there is access to the texture we could render it into some unity8 image atlas containing the reduce image screenshots.. or something..
<anpok> but if the application is killed what would take_snapshot do?
<anpok> or well suspended..
<anpok> i mean .. the interface could be .. that we provide access to the texture to some degree.. and in worst case just read the pixels right now?
<kgunn> alf: mzanetti ... i see zanetti's 2 branches rejected, should we just propose this one ?
<kgunn> https://code.launchpad.net/~mir-team/mir/dont-crash-when-shooting-invalid-surface
<alf> kgunn: superseded by https://code.launchpad.net/~afrantzis/mir/null-snapshot-for-session-without-surface/+merge/207932
<mzanetti> kgunn: yeah, I talked to alf, and he'll get it landed somehow
<kgunn> thanks guys
<alf> anpok: it may complicated because of the GL contexts... textures live in per GL context namespace (and shared in shared contexts, of course), so we can't just create a texture and give out the id. It must be done in a context that is shared with the context unity8 is using. It's doable of course, but not straightforward as things stand.
<alf> alan_g|tea: from vt(ea) to real tea!
<anpok> alf: you context sharing is a endless source of fun .. or radnomness..
<anpok> s/you/yeah
<anpok> alf: but back to the case of application being killed - take_snapshot would dig something up?  (sidenote: I saw qt requesting the QImage - hence triggering the take_snapshot frequently - even when still in phone shell)
<anpok> i.e. it did so when scrolling far enough downwards and then up again
<alf> anpok: what I meant is that the main point of snapshots is to somehow store the pixels of apps that could be suspendend so that 1. we can show the snapshots in the app list 2. slide in the stored image to create an illusion of fluidity until the real app reloads
<alf> anpok: at least that's why they were introduced, not sure if the goals have changed
<fginther> alf, can that MP with the hook changes be deployed as soon as it is ready, or do I need to wait on an mir MP to merge first?
<alf> fginther: mir is ready, feel free to deploy
<fginther> alf, thanks
 * alan_g wonders why his test phone & tablet have flat batteries. Again.
<alf> alan_g: I find that the devices often don't really turn off when you tell them to. The only reliable way I have found to turn them off is to go into recovery(?) mode and select "Power Off" from there.
<alan_g> alf: :(
<greyback> I tend to "adb shell shutdown -h now" and then unplug the USB cable. Works nearly always, except Nexus10 sometimes reboots itself for run
<greyback> fun
<mterry> racarr_, you around?
<racarr_> mterry: Oi!
<racarr_> whats up?
<mterry> racarr_, hello!  I wanted to pick your Mir brain
<mterry> about how Mir behaves when the screen is off
<mterry> racarr_, *so*
<mterry> racarr_, my root problem is that testing with a split greeter shows that the greeter session doesn't start(continue?) spawning until the screen is back on
<mterry> racarr_, and I've heard that Mir won't give out buffers when the screen is off
<mterry> racarr_, I was wondering if that might stop Qt from running its mainloop and thus stop the greeter from coming up while the screen is off
<mterry> racarr_, (because I'd like the greeter to be sitting there ready to go when the screen is turned back on)
<alan_g> alf: AIUI when we build both graphics platforms both stacks create libmirplatformgraphics.so - so one gets overwritten. Am I missing something?
<mterry> racarr_, alternatively, I've heard that Mir also sends lifecycle messages to force apps to sleep.  I'm not sure that's going on here, because it's a whole new unity-mir greeter session, not an app
<racarr_> mterry: Hmm so mir sends the lifecycle messages but doesnt actually do the forcing them to sleep...I dont think the greeter could get forced to sleep but maybe
<racarr_> blocking on advancing the buffer is possible
<racarr_> platform-api is still mostly synchronous so we may be blocking the mainloop in ways we shouldnt.
<alan_g> alf: nm just realized they're in different directories (before my script copies them to the same place)
 * mterry has to run an errand, may bother you later racarr_, thanks!
#ubuntu-mir 2014-02-25
<RAOF> Well, that failure makes *absolutely no sense*
<RAOF> ~thread() is dying in if (joinable) std::terminate().
<RAOF> But ~thread() is being called after a destructor which has called thread.join();
<duflu> RAOF: That means it's been deleted twice, usually. Valgrind should tell where
<duflu> Whee, my merge proposals have now been up for review long enough to get conflicts from other things landing :S
<RAOF> Huh. MirSocketRpcChannel apparently leaks fds.
<RAOF> Oh, wtf? The leak appears in TestClientInput, but if I pass --gtest_filter=TestClientInput\* then it *doesn't* show up?
<RAOF> For those playing at home, a stack depth of 24 is insufficient to catch this error :/
<RAOF> Did my *monitor* just reboot?
<RAOF> ?!
<Mirv> RAOF: it needs to do that after it receives a newer version of the surveillance software
<Mirv> they're working on updating the monitor's kernel while it's running, though
<Mirv> so it should be completely transparent to you soon enough!
<duflu> alan_g: You win :) https://bugs.launchpad.net/mir/+bug/1284554
<ubot5> Ubuntu bug 1284554 in Mir "[regression] mir_demo_server_shell: All clients start fullscreen by default" [Medium,Triaged]
<alan_g> I though I'd won something nice. :(
<duflu> Sorry.
<alf_> duflu: alan_g: anpok_:
<alf_> duflu: alan_g: anpok_:
 * alf_ curses fingers
<anpok_> yes?
<alf_> duflu: alan_g: anpok_: @ https://bugs.launchpad.net/mir/+bug/1192908, are you ok with removing the dependency that libegl1-mesa-dev has on libmirclient-dev (see last comment)
<ubot5> Ubuntu bug 1192908 in mesa (Ubuntu) "Mir/Mesa packaging have a dependency cycle so neither can build" [Medium,Triaged]
<duflu> alf_: I'm OK with removing any dependencies possible. Keep in mind though that bug is about source package dependencies (not binary), isn't it?
<alf_> duflu: it resolves at least a part of the dependency problem, i.e., currently when mir builds it indirectly depends on the existing libmirclient-dev
<duflu> alf_: I suspect the original fix is now gone too. Might be best to do the work in another bug given that one has a branch and Fix Released.
<alan_g> alf_: I'm begging to feel that there's a low-level project & package missing.
<anpok_> alf_: mesa only needs to load a library and plays with a struct with some callback functions.. that implement the egl platform?
<alf_> alan_g: so to solve the greater build dependency cycle, we would either need to have multiple source packages for mir, or move our EGL definitions in Mesa, or have a third independet source package they both depend on
<alan_g> alf_: yes. I'm not sure it is the right trade-off, but it is worth considering
<alf_> anpok_: all the egl backends are built in Mesa's libegl
<alf_> alan_g: anpok_: Anyway, I am not sure it's urgent, and there is the workaround mentioned by Daniel "You might be able to work around the problem by building Mir against vanilla Mesa (which does not depend on Mir)"
<alan_g> I'd say it is a discussion for next cycle
<alf_> alan_g: are you looking into https://bugs.launchpad.net/mir/+bug/1284161 ? If not, I can take a look.
<ubot5> Ubuntu bug 1284161 in Mir "nested mir_standalone_render_surfaces hangs" [High,Triaged]
<alan_g> alf_: OK, I hadn't quite got back to that
<alf_> alan_g: ok
<alan_g> alf_: it is probably something different, but FYI https://bugs.launchpad.net/mir/+bug/1284597
<ubot5> Ubuntu bug 1284597 in Mir "nested render_surfaces fails on N4 " [Undecided,New]
<alf_> alan_g: I can't reproduce the problem on laptop with i965. Both --launch-client and running the render_surfaces manually works for me :/
<alan_g> alf_: Interesting
<alan_g> I was running it on desktop. But that's also intel
 * alan_g get laptop out
<anpok_>  "" is a helpful shader compilation error message
<alf_> anpok_: it's in invisible ink!
<anpok_> i guess the color value of invisible ink is an implementation defined value in the ES spec
<alan_g> alf_: works on my laptop too.
 * alan_g wonders what the important difference is.
<alf_> alan_g: my laptop is a bit behind on updates, let me see if updating makes a difference
<alan_g> alf_: mine isn't
 * alan_g wonders if it is as stupid as number of monitors
<alf_> alan_g: certainly worth a try
<alan_g> rats. Plugging in a monitor hung the laptop
<alan_g> alf_: works with two monitors on the laptop
<alan_g> alf_: does this (my desktop) suggest anything? https://pastebin.canonical.com/105514/
<alf_> alan_g: nothing seems out of place
<alan_g> I guess you can't do much more to investigate
<alan_g> alf_: have you noticed that every MP is now failing: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-amd64-ci/
<alf_> alan_g: yes
<alan_g> Do you know what happened?
 * alan_g notices time
<alf_> alan_g|lunch: seems that we have a new libc version 2.19 and it breaks things
<alf_> alan_g|lunch: or rather valgrind needs to be updated to support 2.19 (and produce the correct default suppression files)
<alf_> kgunn: ^^
<alf_> alan_g: kgunn: https://bugs.launchpad.net/mir/+bug/1284653
<ubot5> Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,New]
<kgunn> alf_: ack
<kgunn> i guess that's our problem to solve ? ....no real tools team per se :-/
<alf_> alan_g: kgunn: although valgrind being out of sync only explains the spurious memory errors, I am not sure about the test failures themselves
<alan_g> alf_: thanks
<kgunn> Saviq: hey...just wondering, so alf_ found new libc "changed something" that effects our valgrind runs...could that be a source of spurious issues on unity AP tests ?
<Saviq> kgunn, if they can cause SIGSEGV on startup...
<Saviq> kgunn, our issue seems to be android-size - i.e. I can't get any symbols out of it for the life of me
<kgunn> hmm...libc, android...does smell a little fishy
<kgunn> potentially
<kgunn> i guess its only an issue for reference structures between libc/ubuntu side vs bionic/android side
<kgunn> but then that would be a 100%
<Saviq> kgunn, yeah, ours is some race
<Saviq> crashing on startup maybe 5% of the time
<Saviq> kgunn, but well, glibc shouldn't be causing that, IIUC, 'cause we'd had symbols for that ubuntu-side
<kgunn> right
<kgunn> sounds more like potentially android bin changes
<kgunn> Saviq: cause all this is happening on 4.4.2 android right ?
<Saviq> kgunn, yes
<alan_g> alf_: (@1284597) why would glCreateShader() return 0 and then glGetError() return 0?
<alf_> alan_g: perhaps there is no current GL context?
<alf_> alan_g: (check with eglGetCurrentContext())
<alan_g> alf_: it returns 0 => you guessed right
<alan_g> thanks
<alf_> alan_g: yw
<alan_g> alf_, anpok : (@1284597) I'm trying to decide whether the problem is that mt::ImageRenderer::ImageRenderer() assumes there's a GL context or that there is no GL context in nested mode. Do you have an opinion?
<anpok> The former I believe..
<anpok> On android driver stacks we might be able to acchieve not needing a gl context on non-nested sessions too..
<alf_> alan_g|tea: anpok: Assuming an active GL context is a leftover from when we didn't have the Display::create_gl_context(). Whoever needs access to the shared context can now get one.
<anpok> get one where?
<alf_> anpok: I mean by calling Display::create_gl_context()
<anpok> oh.. too simple
<alf_> alan_g: although, it's strange that in the nested case we don't have a context. NestedDisplay makes a context current when being constructed
<alan_g> alf_: it does seem strange. But it seems to be the case
<alan_g> I'm happy to add the call though - as it makes sense anyway
<anpok> https://bugs.launchpad.net/mir/+bug/1268819
<ubot5> Ubuntu bug 1268819 in Mir "MirMotionEvent lacks local coordinates. Reports only screen coordinates." [High,Triaged]
<anpok> shall we MirMotionEvent contain both, screen coordinates and local surface coordinates?
<anpok> or just the latter...
<alan_g> anpok: most (all?) clients should only care about local co-ordinates
<anpok> within MirMotionEvent there is for evey point float x, and float raw_x - is that meant to be local vs screen co-ordidnates?
<alan_g> They *should* be local. Not sure why there are two of them - the distinction probably originates in the android input stack.
<anpok> ah because of android
<anpok> and for them raw means not transformed by the offset
<anpok> but with orientation being a float value too now.. hmm. the code needs more changes.
<mterry> Who knows a bunch about Mir + Qt keyboard focus?
<mterry> er, key focus I guess.  Like volume up/down
<kgunn> mterry: i bet dandrader might
<kgunn> alternatively racarr_
<dandrader> I recall I did something related to it a long time ago
<mterry> :)
<RAOF> :)
<mterry> My problem is that when using a split greeter, only the user session receives volume presses.  The greeter session does not
<mterry> I was curious how such input is routed between Mir sessions
<dandrader> no idea
<RAOF> mterry: Is the greeter session focussed?
<RAOF> âsplit greeterâ implies use of unity-system-compositor, yes?
<RAOF> u-s-c should be sending input only to whatever it thinks is focused, which should be either just the greeter or just the user session.
<mterry> RAOF, hmm, it is on top because of depth...  Let me see how the version of USC I'm using handles focus
<RAOF> Last time I checked (which was some time ago, with the desktop u-s-c) you needed to explicitly switch session focus. This might have changed, though.
<mterry> RAOF, aha...  yes.  OK, so the_focus_controller() handles keyboard focus, that makes sense.  And the branch I'm using looks to have a bug around that when using two sessions.  Thanks!  I had forgot about the FocusController
<RAOF> Hurray for memory!
<mterry> RAOF, just to confirm, yeah, that was it.  Weird set_focus_to behavior in my branch.  Thanks man
<RAOF> Bitchn'
#ubuntu-mir 2014-02-26
<alf_> duflu: for https://bugs.launchpad.net/ubuntu/+source/valgrind/+bug/1284653 , would you mark the status for Mir Invalid or Fix Released?
<ubot5> Ubuntu bug 1284653 in valgrind (Ubuntu) "valgrind packages ouf of sync with current glibc version (2.19)" [Undecided,Fix released]
<duflu> alf_: So invalid that I would delete the Mir task :)
<duflu> It's only useful to keep "Invalid" around if there's a chance someone else might come along and blame that project/package latert
<alf_> duflu: unfortunately, there is no good way in LP to associate a bug with a project. We can only mark it as "also affects project", but that to LP means that the project is somehow responsible for the bug, not just affected by it...
<duflu> alf_: I know, but technically more correct to not mention Mir or affected projects, in the absence of loose associations
<alf_> duflu: I think it's useful to mark it as affecting at least up to a point, so we can locate issues affecting Mir easily even if they are in other projects. Anyway, I agree it makes sense to complete remove the association now, so I did so.
<duflu> alf_: I understand the desire. Keep in mind however that LP won't return "Invalid" or "Opinion" bugs in searches
<duflu> You have to do an Advanced search
<duflu> alf_: Also Fix Released bugs will not appear in searches. This is why I find a good email client to be more effective in finding bugs I've seen before
<duflu> That and LP has some substring searching issues. I forget the details
<anpok> duflu: alan_g alf_: should I refrain from making changes in the android input stuff in 3rd_party - as we might at some point integrate a newer version of it?
<anpok> Or is adding additional methods to some of the interfaces fine..
<duflu> anpok: We've asked that question a few times now. I think the current answer is "modify it because we have modified it plenty already"
<alan_g> anpok: no. It's already a fork
<anpok> ok good
 * alan_g reboots
<ogra> hmm
<ogra> so stopping unity-system-compositor on a flo device (new N7 ... our new default tablet) reboots the device
<ogra> aha, its lightdms fault ... there is a hardcoded "clear > /dev/tty7"
<ogra> hmm, no
<ogra> even commanting that out doesnt help
<ogra> *commenting
 * ogra sees a "failed to read header" in /var/log/lightdm/unity-system-compositor.log
<alf_> fginther: Hi! It seems that the latest changes to the CI scripts haven't reached arm build nodes (https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-trusty-armhf-ci/678/consoleFull). Do we need to do something to deploy them there?
<fginther> alf_, Let me check. I expected landscape to have done this, but perhaps I missed something
<fginther> alf_, I'm manually updating the armhf builders, should be done shortly
<alf_> fginther: great, thanks
 * ogra files bug 1285236
<ubot5> bug 1285236 in unity-system-compositor (Ubuntu) "stopping unity-system-compositor on an ubuntu touch device causes a reboot" [Undecided,New] https://launchpad.net/bugs/1285236
<ogra> mterry, !
<mterry> ogra, hi, sorry, IRC issues today
<mterry> ogra, what's up?
<ogra> mterry, i have two bugs for you (well, it is one but i split it in two)
<ogra>  bug 1285236
<ubot5> bug 1285236 in unity-system-compositor (Ubuntu) "stopping unity-system-compositor on an ubuntu touch device causes a reboot" [Undecided,New] https://launchpad.net/bugs/1285236
<ogra> and bug 1285236
<ogra> err
<mterry> :)
<ogra> bug 1285234
<ubot5> bug 1285234 in lightdm (Ubuntu) "lightdm on touch leaves a unity-system-compositor process around" [Undecided,New] https://launchpad.net/bugs/1285234
<ogra> :)
<ogra> mterry, so something like: restart lightdm a few times lets me end up with a bunch of u-s-c processes
<ogra> and killing u-s-c reboots the device
<ogra> (i actually wanted to have a pkill unity-system-compositor and rm /tmp/mir_socket in the post-stop script of the upstart job to be able to cleanly shut down these bits
<ogra> )
<mterry> ogra, rebooting the device is crazy
<ogra> seems to happen on flo and mako ...
<mterry> ogra, that seems like reasonable cleanup in the upstart job
<mterry> ogra, are these urgent or to go on my TODO?
<ogra> right, we might get some test at some point that tries to restart the whole UI stack or so
<ogra> nobody noticed them until now it seems
<ogra> so i wouldnt say urgent
<ogra> but good if we could get them solved before trusty final
<mterry> yar, OK
<mterry> Thanks ogra!
<ogra> i'm happy to take the lightdm changes once the reboot issue is fixed
<mterry> The lifecycle management of u-s-c isn't amazing
<ogra> i just dont have a clue where to look at for that one
<mterry> ogra, yeah, that's an odd one
<silenz> hey guys, i'm trying to learn more about ubuntu and linux as a whole, and i'm currently trying to wrap my head around x11 and an xindow system but i havent really seen a laymans explanation of how it works
<silenz> could somebody explain an x window system like they would to a 10 year old? O_o
<ogra> silenz, probably #ubuntu-x is the better channel for that
<silenz> thanks
<alf_> fginther: It seems that not all nodes picked up the changes: http://s-jenkins.ubuntu-ci:8080/job/mir-team-mir-development-branch-trusty-armhf-ci/685/consoleFull (cyclops-node07) used the old version of the scripts :/
<mterry> I just noticed a weird bug in my split branches.  When an app is opened, it shows as all white, *unless* I start sliding it from left or right edge, then its content shows up until I put it back to normal and it goes white again....  Any idea which component might be doing that?
<mterry> Maybe a nested bug in Mir?  Or possibly just some goofiness in my unity8 branch...
<mterry> I guess my question is if anyone has seen this before
<fginther> alf_, sorry about that, I wasn't feeling well and had to lay down for a bit, should be able to finish the updates as the machines go idle
<anpok> mterry: i found it quite easy to add goofiness today.. no but havent seen that
<mterry> I'm sure if I ignore it, it will go away...
#ubuntu-mir 2014-02-27
<alf_> fginther: no worries, I hope you feel better
<dandrader> alf_, ping
<alf_> dandrader: hi
<dandrader> alf_, hi. I manually built&"make install" mir, but when running an application now I get "libmirplatformgraphics.so: cannot open shared object file: No such file or directory". I guess it's because of "debian: Provide platform packages managed with dpkg alternatives."
<dandrader> alf_, so, what's the simplest/correct way of handling this?
<dandrader> ie., what script or command should a manually run after "make install"?
<alf_> dandrader: simplest workaround is: cd to install libdir (e.g. /usr/lib/{arch}) and ln -s mir/platformgraphics/mesa/libmirplatformgraphics.so
<alf_> dandrader: and ln -s mir/clientplatform/mesa/libmirclientplatform.s
<alf_> dandrader: where s/mesa/android/ if you want the android version
<dandrader> alf_, I wonder if "make install" should already do such things...
<alf_> dandrader: I should fix it so that things work after a make install
<alf_> dandrader: yes
<dandrader> alf_, should I file a bug to track this?
<alf_> dandrader: the problem is that this conflicts with how debian alternatives work, but I guess we can just not install the links in the debian packages
<alf_> dandrader: @bug, sure
<dandrader> I'm not really familiar with debian alternatives
<alf_> dandrader: a potential issue is if you mix "make install" and using packages, then the debian alternatives won't really work because make install will place direct soft links to the .so
<alf_> dandrader: but I guess, whoever plays with fire will get burned :)
<alf_> duflu: alan_g: anpok: https://bugs.launchpad.net/mir/+bug/1194384 , is our goal to provide a way to serialize the events for apps that don't need full multithreading flexibility? I don't remember if discussions about this (if any), led to a conclusion.
<ubot5> Ubuntu bug 1194384 in Mir "Mir client callbacks are not thread-safe" [Critical,Triaged]
<duflu> alf_: The goal is to ensure all callbacks occur in one thread. The same thread as main()
<alan_g> alf_: IIRC in London RAOF had some ideas about this. I know duflu had a prototype for putting everything onto a client thread
<duflu> I did a proof of concept which works. But it adds a little latency (additional context switch)
<duflu> That actually increases motion event throughput a lot, but it feels slightly laggy
<duflu> Like most toolkits, you provide an API call from the client into the client library. And that's then a jumping off point to call the callbacks. People often use a "Mainloop" object for that
<duflu> I think I did it similarly, but more generally. In a way where we could change the mechanics underneath over time
<alf_> duflu: alan_g: Do we still need to allow for multiple threads (i.e., the current situation)? I am not sure what our requirements from the toolkit side are.
<duflu> alf_: I'm not sure what you mean
<duflu> alf_: Oh. I see. Supporting single plus multiple would be a requirement. But once you have the former, the latter is simple
<alf_> duflu: you mean dispatching to multiple threads from the main thread?
<alf_> duflu: but in an application/toolkit-controlled fashion
<duflu> alf_: Regardless the public API should not suggest the existence of threads or ever call back the client in some different thread. You can hide threads underneath still
<duflu> alf_: Shall I revive the prototype? It was designed to provide an interface to fix on so we can improve the underlying efficiency later
<duflu> I think the greatest benefit of the prototype was that I designed it so no existing clients needed modification. It's an optional add-on to enforce single threaded-ness
<alf_> duflu: I am trying to figure out what our goals our... so, as I see it, ideally we would like to get rid of the various set_callback functions and callback arguments, and just dispatch everything through the mainloop/event_queue?
<duflu> alf_: If starting from scratch then yes. But right now we'd like to maintain transparent compatibility with existing clients too
 * duflu copies and pastes
<duflu> alf_: The goal is to ensure all callbacks occur in one thread. The same thread as main()
<alf_> duflu: From what I see the goal is for the callbacks to occur in one thread, any thread the app/toolkit wants?
<duflu> alf_: Yes, that too. But that can be accomodated with the more stringent goal of a single-threaded client should only ever see callbacks in its main() thread
<duflu> Of course, the client can control which thread that is
<duflu> alf_: So long as the basic requirement is met and the API is pretty, I'm happy to ignore my prototype work
<alf_> alan_g: duflu: anpok: ok, so the plan is to think a bit more about it, come up with some ideas and a rough plan, and send an email to mir-devel for further discussion
<alan_g> alf_: ok
<duflu> alf_: Cleaned up: https://code.launchpad.net/~vanvugt/mir/event-queue/+merge/208563
<alf_> duflu: great, thanks
<duflu> I never got as far as writing tests. Still was in the process of redesigning constantly to make everything feel nicer for clients
<duflu> I designed it from the demo clients, outward :)
<anpok> owe possible way would be to have no threads created at all but provide an interface to get all client file descriptors to do the wait in a different main loop library (like boost::asio :)) and let the mir client read events when necessary from the fds..
<anpok> but there are some odd cases like blocking calls
<anpok> input requires one fd per surface?
<anpok> still mir client has to be entirely thread safe
<anpok> as in allow processing events from multiple threads
<greyback_> Any Mir person able to help this guy: https://lists.launchpad.net/ubuntu-phone/msg06616.html
<anpok> greyback_: I can confirm that this happens.. not sure how to solve it
<greyback_> anpok: ok, thanks for looking. Would be nice if someone could help, what he's trying sounds reasonable
<alan_g> greyback_: it sounds reasonable, but I don't think anyone's looked into supporting that stack. (I know that RAOF had to make mesa changes when he got XMir working on the desktop.)
<kgunn> mterry: i'm curious...with nested mir & u-s-c...would it make sense for u-s-c to "remove" the tmp socket if it hits this error
<kgunn> https://bugs.launchpad.net/mir/+bug/1285084
<ubot5> Ubuntu bug 1285084 in Mir "Exceptions are raised in a compositing thread and not handled" [Undecided,New]
<kgunn> u-s-c is root right ?
 * mterry looks
<mterry> kgunn, yes
<kgunn> mterry: i would think that if there's already an old socket there...its a mistake(e.g. its old) if u-s-c is just starting up
<mterry> kgunn, you mean it would make sense for USC to remove /tmp/mir_socket after it crashes?
<kgunn> mterry: sure
<kgunn> mterry: or even if it finds one on startup right ?
<kgunn> trying to think of why it would ever encounter an already existing mir socket ?
<mterry> kgunn, in general I would think that's true (that Mir would automatically remove old sockets when it starts).  But mir-team I thought was of the other opinion
<mterry> Even for user sessions and such
<kgunn> alan_g|tea: alf_ ^
<kgunn> mterry: maybe not mir itself...but u-s-c would have "knowlege" enough to say "hey, i'm the king daddy mir server starter...if i find an old socket, i should delete it"
<kgunn> ?
<mterry> kgunn, sure, but user Mir sessions are king daddy Mir servers in the user session.  And are explicitly given a Mir socket path to use.  Seems like they should be able to expect to own it
<mterry> Maybe only assume Mir owns it if we are given the path (which is always the case right now)
<alf_> kgunn: iirc, the upstart scripts remove stale sockets before starting usc or unity8 (at least that was the case at some point)
<mterry> alf_, USC isn't managed by upstart right now
<mterry> I guess lightdm could do it manually
<mterry> But would be easier if Mir just did this itself
<alf_> kgunn: mterry: mir does it best to remove sockets when it fails, but can't catch all kind of crashes
<mterry> alf_, I get that.  But I'm talking about on startup, removing the socket
<kgunn> alf_: mterry ...we do need to come up with something CI/release team chasing us....as its wreaking havoc on them
<mterry> oh really
<alf_> mterry: kgunn: the reason it doesn't do this on startup is that this would allow "stealing" a socket from another mir instance
<mterry> alf_, who are we stopping from doing that?  couldn't the user just rm the file themselves?
<kgunn> yeah...but aren't sockets tied only to that user (in terms of permissions)
<alf_> mterry: kgunn: it's not about security, it's about expected behavior, e.g., running two mir instance in a row shouldn't cause the first one to fail because the second steals the socket
<mterry> alf_, but in both cases you are explicitly specifying the mir socket path.  I think behavior in that case is up for debate
<mterry> Either the first or the second fails
<kgunn> right
 * kgunn agrees with mterry
<kgunn> which is exactly where we are at
<kgunn> second one fails cause no one deleted the prior socket
<kgunn> and from a "theoretical" use case perspective...i don't disagree with alf_ but practically, in our configs when do we have a 2nd usc mir showing up?
<alf_> kgunn: mterry: I disagree, expected behavior is for the second to report an error, not for the first one to fail because we pull the socket beneath its feet. And actually the second probably won't fail at all, it's just that the socket will have no representation on the filesystem.
<kgunn> alf_: so it should create a seperate specific socket?
<alf_> kgunn: mterry: since everything is done through upstart, the logic to handle the stale socket was put there
<mterry> alf_, but with upstart, you get the behavior that starting a second instance kills the first anyway
<mterry> So I'm not sure why that is an unexpected outcome
<mterry> I mean, I guess you have to be a bit more explicit.
<mterry> Saying restart instead of start
<kgunn> mterry: e.g. upstart is just gonna delete that socket any way ?
<mterry> kgunn, I thought our upstart script did that?
 * mterry checks
<alf_> kgunn: mterry: correction: "And actually the second probably won't fail at all" =>  And actually the *first* probably won't fail at all
<alan_g> I thought the intention for USC was not to put an endpoint on the filesystem
<alan_g> In which case all this is moot
<mterry> kgunn, nope, it doesn't
<mterry> my bad
<mterry> alan_g, that was a goal
<alan_g> What's stopping it?
<alf_> alan_g: even if we forget USC, the debate stands about the unity8 socket
 * alan_g doesn't like software that silently "fixes" things
<kgunn> so as a recap, we really have no mechanism to prevent stale/orphaned sockets...not in upstart, not in usc, not in mir
<mterry> alan_g, no one ever completed the branches robert_ancell started to use the socket-less communication work between lightdm/USC/Mir
<mterry> alan_g, I actually thought you had that on your TODO somewhere
<mterry> kgunn, I think autopilot cleans them up  :)
<kgunn> mterry: lol...well obviously not
 * alan_g can see it (far down the list)
<mterry> :)
<alan_g> mterry: I had a look, but the lightdm code wasn't clear to me
<kgunn> mterry: AP meaning...some poor bastard manually adb shell's in and rm's it
<mterry> alan_g, in future, I might be able to help decipher it
<alan_g> Anyway, unless something SIGKILLS mir it should clean up the socket
<mterry> kgunn, in unity8's launch_unity() AP method, it cleans its session socket
<kgunn> alan_g: sorry...no being a smart alec "it" == ?
<mterry> kgunn, but that's only for the session and only for unity8 tests
<mterry> kgunn, I think 'it' == mir
<kgunn> mterry: right, i'm guessing this is all because nested/usc got turned on
<alan_g> kgunn: mir cleans up the socket on most signals and on normal exit
<kgunn> ta
<alan_g> Mir can't do it on SIGKILL
<kgunn> right, which is exactly how unity8 AP works i think
<kgunn> as mir is part of the unity8 process
 * alan_g what's wrong with SIGTERM?
<alan_g> *wonders
<mterry> kgunn, so AP is exercising the system much more than usual, and with less stable code.  Maybe it should just clean all the sockets all the time in case it hits crashes
<mterry> I guess it would have to tell if it's still running.   And USC doesn't cleanly restart itself if it crashes...
<mterry>  Just restart system after every test  ;)
<kgunn> om26er: ping
<om26er> kgunn, hi
<kgunn> om26er: hiya
<kgunn> so you can see we've had a lengthy discussion above about
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1285215
<ubot5> Ubuntu bug 1285215 in mir (Ubuntu) "Unity fails to start sometimes in CI resulting in screen unlock failure [what(): bind: Address already in use]" [Medium,Triaged]
<kgunn> curious...do you know how the AP test
<kgunn> framework works ?
<kgunn> e.g. does it SIGKILL unity8 ?
<kgunn> seems mir should clean up the socket if "treated politely"...potentially with SIGTERM
<om26er> kgunn, this is the script thats run http://bazaar.launchpad.net/~ubuntu-test-case-dev/ubuntu-test-cases/touch/view/head:/utils/target/unlock_screen.py
<om26er> we set an upstart override to load the testability driver, stop unity8, turn on the screen and start it again
<om26er> kgunn, we use initctl stop unity8
<om26er> dr appointment, back in 30
<kgunn> om26er: ack
<kgunn> alan_g: mterry ....so guessing this implies, it is just post-crash case...
<kgunn> so mterry guessing you're suggestion might need to be the one...force clean from AP setup
<mterry> kgunn, but also if we're talking USC (are we?), might need to restart lightdm
<kgunn> yes, i think we are
<kgunn> well...judging from some chat in ubuntu-ci-eng that they needed to be root to delete the stale socket
<mterry> kgunn, was the stale socket in /tmp/mir_socket or /run/user/.../mir_socket ?
<mterry> kgunn, because that bug title at least indicates just a user sesion issue
<mterry> Regardless, a problem with USC can be fixed by restarting lightdm (once my fix for bug 1285234 lands)
<ubot5> bug 1285234 in lightdm (Ubuntu) "lightdm on touch leaves a unity-system-compositor process around" [Undecided,Incomplete] https://launchpad.net/bugs/1285234
<kgunn> mterry: btw, you might want to review this one...
<kgunn> https://code.launchpad.net/~albaguirre/unity-system-compositor/add-power-off-delay-option
<kgunn> :)
<kgunn> i know it will bring you joy
<mterry> kgunn, interesting.  I thought we just needed to clear some buffers in Mir for this
<kgunn> mterry: well...it was actually to do with the powerd chain of events
<kgunn> unity8 getting notified after usc
<mterry> This seems hacky, like what if system load is high or some such
<kgunn> right...
<kgunn> mterry: so we're not claiming this to be the final solution
<mterry> Yar
<kgunn> i've asked AlbertA to dive in and untangle the whole powerd thing
 * mterry tests this branch
<AlbertA> mterry: yeah it's a kludge for now
<mterry> Will need a corresponding ubuntu-touch-session change to pass args
<AlbertA> mterry: I don't think flushing buffers in mir is enough either
<AlbertA> mterrty: as we should allow shutdown animations to occur
<AlbertA> mterry: the option can be configured with unity-system-compositor.conf as well
<mterry> AlbertA, someone mentioned turn-on delays/animations too, since the greeter needs a moment to get the right time
<AlbertA> mterry: umm that would be a little bit more involved
<kgunn> mterry: so i been thinking...why couldn't mir check to see if there's another mir process running, if not...he deletes the socket
<kgunn> am i missing something
<kgunn> ?
<kgunn> ....sorry, picking up from our conversation with alf_earlier
<mterry> kgunn, well, in theory many Mirs can be running at the same time.  As long as they don't have the same socket specified
<kgunn> mterry: right, but in our config...that's never gonna happen right ?
<kgunn> we're gonna have one root, and one session
<kgunn> ...again, am i being stupid ?
<mterry> kgunn, I guess?  But that's going a step further than we need.  We can just say "delete the socket you're configured for before opening it for yourself" which is what I was suggesting earlier.  No reason to query for other Mirs
<mterry> Heh, didn't mean "I guess you are being stupid"  :)
<kgunn> mterry: :)
<kgunn> mterry: so i'm lost...isn't '  just say "delete the socket you're configured for before opening it for yourself" ' what alf_ argued against ?
<mterry> kgunn, yes
<kgunn> hmmm
<mterry> kgunn, but that's also what you are suggesting
<mterry> kgunn, oh
<kgunn> yes i know...guess i'm saying not convinced
<mterry> kgunn, maybe not.  I see what you are saying now
<mterry> kgunn, you want to gracefully exit if there is another Mir
<kgunn> hey, i just joined a hangout i gotta pay attn :)
<kgunn> back in a moment
<mterry> kgunn, we could just call "fuser $MIR_SOCKET" and if no one else is using it, delete it
<kgunn> ooo... mterry i'd never heard of fuser, just learned from google...i likie
<kgunn> alf_: ^
<Saviq> mterry, btw, fuser is not installed on the phone :/
<mterry> Saviq, hrm.  I suppose it could be installed or the system call it does could be called directly (unless it does a bunch of direct ext calls...  ::shudder::)
#ubuntu-mir 2014-02-28
<Saviq> duflu, there's a Qt crasher we're looking into, that's what caused the stale socket
<duflu> Saviq: Fun :)
<duflu> kgunn: As the critical fix has now landed, I might draw a line and tag 0.1.6. It's getting pretty big
<kgunn> duflu: so i was just in the processs of updating the debian ch log
<kgunn> so if you wanna tag on
<duflu> kgunn: No problem. That's not a requirement for upstream releasing
<kgunn> 1433
<duflu> But I can wait
<duflu> I have a while of reviewing my own code reviews yet
<duflu> 1433 sounds good
<kgunn> duflu: ok...thanks tho...i'll push in a moment for lp:mir....you can have your usual look :)
<kgunn> but i think i got it this time
<duflu> kgunn: Also Monday is a holiday for West Aust and Greece AFAIK
<kgunn> ah thanks for that...didn't realize it
<kgunn> duflu: just Western Australia ?
<duflu> I think?
<kgunn> guys the in the east just suffer and work
<duflu> Ignoring the fact that RAOF is holidaying in WA :)
<duflu> kgunn: Yep.  Labour day is different for each state
<kgunn> duflu: ok...here's my attempt
<kgunn> https://code.launchpad.net/~mir-team/mir/trunk-0.1.6/+merge/208717
<duflu> kgunn: Thanks I will check it today. Quick thoughts - the changelog needs to wrap before column 80. Also we don't need and probably don't want comments about every commit (do we?)
<kgunn> duflu: i wasn't sure...i do remove redundant/irrelevant comments
<kgunn> like "merge from trunk"
<kgunn> and...yeah...some are kinda weak...i can do a better job next time...
<kgunn> and damn it!
<kgunn> i forgot 80 col
<kgunn> even tho i thot "don't forget 80 col"
<kgunn> i'll fix in a jiffy
<kgunn> duflu: ok...hopefully not much else wrong :)
<kgunn> see ya tomorrow...have a good one
<xnox> is this normal with trunk:
<xnox> /usr/include/glm/detail/type_vec3.inl:86:33: error: invalid static_cast from type 'const glm::detail::tvec3<float, (glm::precision)0u>' to type 'float'
<xnox> ?
<duflu> xnox: I believe that problem appeared from the glm package last night. Not from Mir itself
<xnox> duflu: sure, is there a fix for it? (or a merge proposal, or something?!)
<xnox> i can downgrade, but i don't want to =)
<duflu> xnox: Yes it appears a workaround was applied to Mir last night. Will be in 0.1.6 when I cut it today
<xnox> duflu: is that https://code.launchpad.net/~afrantzis/mir/work-around-glm-initializer-list-breakage/+merge/208670 ?
<duflu> xnox: Looks like it yes.
<duflu> I've done a pile of builds this morning with the fix and they all succeeded
<duflu> Beyond that it's all news to me
<duflu> xnox: 11 hours ago apparently. Here's where the problems came from: https://launchpad.net/ubuntu/+source/glm
<xnox> duflu: kind of sad that upstream, breaks compat in a micro minor point release.
<xnox> duflu: did they ever advertise using initialisation lists? or is it us who used it, just because.
<duflu> xnox: Yes. We only recently moved to using the external glm a few months ago. Before then it was embedded in the Mir source
<xnox> i guess better of the two evils.
<duflu> xnox: I don't know who to blame. I do know the Mir team often uses initializer syntax instead of constructor syntax, but I have trusted that they knew what they were doing
<duflu> I don't know if that
<duflu> 's the new ways for C++11+ or just style
<xnox> duflu: well initializer syntax is only support with c++11, and if a given project decides that they don't support c++11, they are free to break source-level compatibility, without breaking ABI...
<xnox> (e.g. as part of working on c++11 compat/apis adding initilizer list syntax etc....)
<xnox> duflu: anyway, took the hint from the branch, thus my bugfix is compiling against stable, such that i can test it.
<duflu> xnox: Sounds good. I would like Mir to use a better (maybe even internal) math library in future. But it's not a priority for anyone right now
<xnox> duflu: what's wrong with libm?
<duflu> xnox: For 3D matrix math? :)
<xnox> duflu: ah, i see =)
<xnox> duflu: that would cool, if it did that =)
<duflu> xnox: I was hoping to myself. I wrote an awesome one in 1998 and could adapt it
<duflu> ... and then GPUs came on the scene around 2000 and it was forbidden to do matrix math by hand. But then GLES came along and threw away a bunch of matrix manipulation functions, meaning you have to do them on the GPU or in a GPU shader now
<duflu> on the CPU or in a GPU shader
<duflu> Ideally you would never do any. Just send numbers off to the vertex shader and let it do all the matrix work
<xnox> duflu: i'm yet to do any GPU / GL / GLES / shader coding.
<duflu> xnox: It's like C with high-level matrix/vector math built in. Very little effort
<duflu> Since the whole 3D math library has changed, I better do some manual testing to make sure it's still sane
<greyback> Hey folks, am using cross-compiling chroot to compile mir, it failed with http://pastebin.ubuntu.com/7010931/
<greyback> anyone seen anything like that before?
<alan_g> greyback: yeah alf_ MP'd a workaround last night
<greyback> alan_g: aha good. My chroot not bad then. thanks
<alan_g> https://code.launchpad.net/~afrantzis/mir/work-around-glm-initializer-list-breakage/+merge/208670
#ubuntu-mir 2015-02-23
<alan_g> duflu_: did you resolve "The bad news is I can now see stutters..."?
<duflu_> alan_g: Nope, but also sufficiently rare that it's not worth blocking on. Only happens (sometimes) when a surface crosses multiple display buffers or transitions to/from bypass
<duflu_> Getting better phone performance is more important
<duflu_> We can dynamically add triple back in according to demand later
 * alan_g wonders if we need to track the issue with a bug (or something)
<duflu_> alan_g: After it lands, I'll retest and declare a minor regression
<alan_g> OK
<anpok> hm why is default_delete a template
<alan_g> camako: I'll update this to 31 then? https://code.launchpad.net/~alan-griffiths/mir/libmirserver-ABI-bump/+merge/250602
<camako> alan_g, sounds good
<camako> AlbertA ^
<alan_g> Dne
<alan_g> *done
#ubuntu-mir 2015-02-24
<winjo> ah ban sowet courele coumdele coand ah cepe? di. di. sowet blak sho at weiy
<anpok> alan_g: how do you feel about disabling UniqueModulePtrs default constructor?
<alan_g> anpok: haven't thought about it yet
<alan_g> Does it work?
<anpok> well, yes.. I had to make change to enable it :)
<anpok> *changes
<anpok> Basically because the deleter wants to be initialized
<anpok> I only saw a use for that in my test case, but I can work around that
<anpok> (use for the default constructor)
<alan_g> anpok: give me a few minutes to refresh the MP
<alan_g> anpok: another option (I've not chosen, just brainstorming) would be to make make_module_ptr a friend of ModuleUniquePtr etc.
<anpok> hm yes that would yield different error messages, but it requires actually writing a ModuleUniquePtr, and then we can simply omit the default constructor
<anpok> (sorry for writing a but, while brainstorming is active)
<alan_g> Oops I meant friend of  ModuleDeleter
<anpok> ah
<alan_g> I can see it /might/ be useful to default construct a ModuleUniquePtr for later assignment
<anpok> alan_g: thats what I was asking about, and what I also use inside a test case
<anpok> you can work around those cases, and RAOF asked whether it would be possible to disallow a ModuleUniquePtr being default constructed
 * alan_g imagines workarounds like uniaue_ptr<ModuleUniquePtr> and shudders
<anpok> or optional_value<ModuleUniquePtr<...>> yes
<alan_g> The "problem" use case is the non-default construction of ModuleUniquePtr with an incorrect initialization of ModuleDeleter
<anpok> ah you want to avoid that one!
<anpok> good I can do that
<alan_g> Shall I just write that up in the MP then?
<anpok> yip
<anpok> alan_g: anonymous friends behave strange in gcc
<anpok> ah it unveils a gcc bug
<alan_g> Really?
<anpok> when i make make_module_ptr (which in namespace {}) friend of ModuleDeleter
<anpok> clang complains that namespace { make_module_ptr } cannot access the private constructor
<anpok> gcc allows it or ignores it
<alan_g> You have a declaration of  make_module_ptr before the friend declaration?
<anpok> and then the linker complains that there is no mir::make_module_ptr symbol (and it does not generate a mir::(anonymous namespace)::make_module_ptr symbol
<anpok> yes
<anpok> is there something in the c++ syntax I missed to be become friend of an anonymous entity?
<alan_g> So "friend" is injecting into the surrounding namespace and not finding the declaration. :(
<anpok> removing the namespace { } works fine for both
<anpok> hmm i could try turning ModuleDeleter anonymous too
<anpok> which is fine as we it just forwards to the right thing
<alan_g> Actually, that is sort of reasonable - you don't want a friend in every anon namespace
<alan_g> Sorted then?
<anpok> nearly
<anpok> oh uncovers a clang bug too .. and yet another workaround ...
<anpok> the using UniqueModulePtr<T> = std::unique_ptr<....> gets a strange taint for clang
<anpok> which makes it fail to match a extern "C" mir::UniqueModulePtr<Interface> create_instance() with a matching mir::UniqueModulePtr<Interface> create_instance() in the implementation file
<anpok> repeating extern "C" solves it
<anpok> stange taint because of the now anonymous ModuleDeleter
<anpok> but that bug only happens on clang gcc is happy both ways
<alan_g> What a wonderful story to tell. ;)
<anpok> done
<alan_g> With tests that "bad stuff" doesn't compile? :^|
<anpok> aeh?
<anpok> static_fail_to_compile<decltype(hmm this would be quite interesinng)>
<alan_g> Yeah. I keep meaning to try - SFINAE ought to provide a way...
<anpok> challenge accepted
 * alan_g thinks that this might not be the top priority item on the backlog
<anpok> seems to work
<anpok> not
<anpok> i'll leave that for the weekend
<anpok> gcc does not care whether decltype(..) is valid, and clang does not accept invalid decltype even to do sfinae
<anpok> so i need to do sfinae within decltype...
<anpok> ->weekend
<davmor2> Hey guys I just got this in vivid and wanted to check if it was normal? http://paste.ubuntu.com/10388642/
<anpok> davmor2: hm no, there is something wrong
<anpok> i get the same
<alf_> davmor2: anpok: https://bugs.launchpad.net/mir/+bug/1423359 ?
<ubot5> Launchpad bug 1423359 in mir (Ubuntu) "taking screenshots with mirscreencast fails" [Undecided,Triaged]
<davmor2> alf_: thanks
<rsalveti> <ERROR> mircommon: Caught exception at Mir/EGL driver boundary (in setSwapInterval): /build/buildd/mir-0.11.0+15.04.20150209.1/src/client/buffer_stream.cpp(283): Throw in function virtual void mir::client::BufferStream::request_and_wait_for_configure(MirSurfaceAttrib, int)
<rsalveti> Dynamic exception type: N5boost16exception_detail10clone_implINS0_19error_info_injectorISt11logic_errorEEEE
<rsalveti> std::exception::what: Attempt to set swap interval on screencast is invalid
<rsalveti> when using phablet-screenshot on mako/latest vivid
<rsalveti> is that known?
<rsalveti> it worked fine though
<tmpRAOF> rsalveti: Not known to me :)
<rsalveti> tmpRAOF: great, let me open a bug for it
<rsalveti> tmpRAOF: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1425307
<ubot5> Launchpad bug 1425307 in mir (Ubuntu) "Exception when running phablet-screenshot (mako/vivid 110)" [Undecided,New]
<tmpRAOF> rsalveti: It'd be convenient if you dump the backtrace of running that in gdb with âcatch throwâ (I don't *think* we have any other expected-but-caught exceptions) :)
<rsalveti> sure, need to install dbg symbols and family
<rsalveti> tmpRAOF: https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1425307/comments/2
<ubot5> Launchpad bug 1425307 in mir (Ubuntu) "Exception when running phablet-screenshot (mako/vivid 110)" [Undecided,New]
<tmpRAOF> rsalveti: Much ta.
<tmpRAOF> Bah. You know what would be rad? If that backtrace didn't give up just before the frame I wanted to inspect :)
#ubuntu-mir 2015-02-25
<alan_g> alf_: OK now? https://code.launchpad.net/~alan-griffiths/mir/libmirserver-ABI-bump/+merge/250602
<anpok_> alf_, alan_g: what was the change in lp:mir that required a graphics platform abi bump?
<alan_g> Not sure. Probably a change to common
<anpok_> oh
<alan_g> There's a bunch of input stuff in common that should be in client and when that changes...
<anpok_> i saw some logs from chris claiming that we did not need the bump.. I guess we need it now because of display group changes in the platform headers
<tedg> tvoss, You're in very few freenode channels :-)
 * tvoss hides
<tedg> tvoss, Looking at the paused/resume signals.
<tedg> tvoss, Trying to decide if it is better to signal before sending the STOP/CONT or after. Curious if you have an opinion.
<tedg> I think you want after STOP but before CONT.
<tedg> Though DBus delays mean it's not precise.
#ubuntu-mir 2015-02-26
<alan_g> alf_: anpok duflu - anyone planning to review this? https://code.launchpad.net/~alan-griffiths/mir/tweaks-to-raising-surfaces/+merge/250817
<anpok> ok
<duflu> alan_g: Sorry, too many tangents and distractions. Plus EOD now :S
<alan_g> duflu: np - I just prefer to prompting for reviews over just top-approving
<alf_> alan_g: I'll take a look
#ubuntu-mir 2015-02-27
<Saviq> guys, was mir 0.12 accepted into vivid after all?
<anpok_> Saviq: no idea, didnt pay much attention yesterday.. saw some discussions
<anpok_> alf_, alan_g: shouldnt libmirserver hide the graphics platform api/abi?
<alan_g> What do you mean by "hide"?
<anpok_> well it might be enough to have no access to it through mir::Server
<anpok_> while looking at the module_type_detection code, and christophers suggestion to make it support an older ABI of mir_server_platform_graphics
<anpok_> i thought that this is pointless since shells can for examples access Diplay and DisplayBuffer and related classes directly
<anpok_> hm ok we could still provide have a wrapper around an older version of .. e.g. mir::graphics::Display
 * alan_g has no idea what you want to achieve
<alan_g> the pltaform lib provides the symbols, how can the server lib "hide" them?
<anpok_> sorry I was mixing stuff above
<anpok_> I am not concerned about our graphics platform entry points
<anpok_> more about the object structure it exposes through the mir::graphics::Platform interface
<anpok_> alan_g: last night I tried to provide a newer mir with the same MIR_GRAPHICS_PLATFORM symbols, but incompatible changes in it
<anpok_> which failed because for example Display is different now, and qtmir needs to access..
<alan_g> So what you're suggesting is that libmirserver-dev shouldn't depend on libmirplatform-dev
<alan_g> Sounds reasonable
<anpok_> it would at least limit the problem to a mir internal one
<anpok_> problem of supporting multiple graphics platform versions
<anpok_> not sure if I make much sense today.. really need more sleep today
<alan_g> Actually, it wouldn't be "mir internal" once we try to support 3rd party platforms
<Saviq> kgunn, hey, do you know if mir 0.12 got accepted to vivid after all? http://people.canonical.com/~platform/citrain_dashboard/#?distro=ubuntu&q=landing-007
<kgunn> Saviq: yo, it appears it's migrating ? it was only 1 bug fix for deadlock issue so it was a good one....why do you ask?
<Saviq> kgunn, just I wasn't sure 0.12 was getting in due to FF
<kgunn> Saviq: ah, yes...it was on purpose
<camako> Saviq, @mir 0.12, yeah it got accepted, the process wasn't any different than before (at least so far, it's still in proposed)
<Saviq> camako, yeah, I can see that, and am wondering why it's taking so long...
<Saviq> mir-client-platform-mesa-dev/amd64 unsatisfiable Depends: mir-client-platform-mesa (= 0.12.0+15.04.20150224.1-0ubuntu1)
<Saviq> camako, ok, that thing's not gonna migrate
<Saviq> since there's no mir-client-platform-mesa any more, it's ...-mesa1
<attente_> hi, i'm trying to run a qt app under mir, but it seems to use some features that are unsupported by the qpa, specifically QQuickWidget, window masks, and propagateSizeHints()
<Saviq> attente_, greyback_'s been working on enabling all of that recently
<Saviq> it's not yet all integrated, but I imagine you can get some pointers from him, or an ETA at least
<attente_> Saviq: oh awesome
<attente_> greyback_: hi, any idea when ^ will be available?
<Saviq> AlbertA, ââ you aware Mir is blocked in proposed?
<camako> kdub ^^
<Saviq> because ...mesa-dev deps on not-existing -mesa
<AlbertA> camako: ^ kdub ^
<camako> Actually, wasn't it alf_ that made that change ^
<AlbertA> camako: we need to fix it in devel too
<camako> sure
<alf_> camako: AlbertA: want me to fix it?
<camako> alf, yes please
<kdub> and then what do we do?
<camako> alf_, ... on both branches
<alf_> camako: lp:mir , lp:mir/ubuntu?
<camako> kdub, rebuild everything, do sanity, release
<AlbertA> alf_: in 0.12 branch and lp:mir
<greyback_> attente_: am adding such abilities when we notice they're needed. If you could add bugs for those features, then I'll consider them noticed and work on them
<camako> alf_, yeah what AlbertA said
<greyback_> attente_: but yes the plan is to enable all the QPA features that QWidget based apps rely on. I was working on enabling all the qtbase5-examples first
<camako> Saviq, are you anywhere close to landing silo 19?
<Saviq> camako, I'll need to wait for yours anyway, since otherwise I'd overwrite qtmir and you'd have to rebuild and.... meh
<camako> Saviq, yeah that's why I was asking... Thanks
<camako> kdub ^
<attente_> greyback_: sure, thanks
<greyback_> attente_: is it an app I can try, or something private?
<attente_> greyback_: it's a bit of an unusual case. i've ported fcitx-qimpanel to qt 5 which provides the input method widget for cjk text input
<attente_> i have a branch here: https://github.com/attente/fcitx-qimpanel
<attente_> i'll file a bug though with the requirements
<greyback_> attente_: please do. Mir's needs better support for input methods so it may take time. But definitely please log bugs as it'll show us where to start
<alf_> camako: AlbertA: https://code.launchpad.net/~afrantzis/mir/fix-mir-client-platform-dev-deps/+merge/251281
<alf_> camako: AlbertA: If we are OK with the change, I will push it directly to mir/0.12 also
<camako> alf, shouldn't it now depend on -mesa2?
<AlbertA> alf_: isn't it customary to have the headers depend on the library the headers are for? I mean in debian parlance?
<camako> alf, note that 0.12 is behind (-mesa1)
<AlbertA> alf_: I see all other mir dev packages follow that convention
<alf_> camako: AlbertA: mir-client-platform-mesa is not a library, it's a plugin for Mir
<AlbertA> alf_: ahh true
<alf_> camako: AlbertA: i.e. 3rd parties are not going to ever use mir-client-platform-mesa directly
<tedg> dednick, So as part of the trusted session loosing focus thing, was there API added for that to Mir?
<tedg> dednick, i.e., do we need to implement another callback there?
<dednick> tedg: not sure about the losing of focus. that part of the whole https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1352251 thing?
<ubot5> Launchpad bug 1352251 in unity8 (Ubuntu RTM) "Reverse trust prompt hosting" [High,Triaged]
<tedg> That's more confusing.
<tedg> Saviq, You're going to have explain your comment there, what's the broker?
<tedg> Something to broker the pid of the dash?
<tedg> Is there a case of scope data being displayed by more than one pid?
<alan_g> alf_: did you break my build? "The following packages have unmet dependencies: mir-client-platform-mesa-dev"  https://jenkins.qa.ubuntu.com/job/mir-mediumtests-runner-mako/4424/console
<mlankhorst> alan_g: that -dev package needs to depend on mir-client-platform-mesa2 :P
<alan_g> mlankhorst: I think alf_ was changing the test script to detect packaging errors. My build got caught.
<mlankhorst> ah
<alf_> alan_g: yes, and https://code.launchpad.net/~afrantzis/mir/fix-mir-client-platform-dev-deps/+merge/251281 fixes it again
<alan_g> alf_: I vote for pushing that directly to trunk and not waiting for autolanding
<camako> @pushing directly to trunk, +1
<tallnerd1985> Hi everyone
#ubuntu-mir 2016-02-29
<Saviq> alf__, FYI, something's starting to shape up: https://git.launchpad.net/~saviq/+git/jenkaas-jobs
<alf__> Saviq: thanks, I will take a look
<alan_g> vogons - can we have another set of eyes on the latest version of https://code.launchpad.net/~raof/mir/fix-and-enable-lto/+merge/282133?
#ubuntu-mir 2016-03-01
<duflu> alf__: Morning. Does this make any sense to you? It's blocking a couple of MPs at least...
<duflu> /tmp/hudson3861179810836943644.sh: line 100: syntax error near unexpected token `fi'
<alf__> duflu: Probably related to RAOF's CI changes, but seems to be fixed now?
<duflu> alf__: Oh? Was failing just a couple of hours ago
 * duflu hits the build button
<alf__> duflu: @~kdub/mir/mir-0.20.1-changelog, the autolanding script doesn't want to land it because "bzrlib.errors.PointlessMerge: Nothing to merge."
<duflu> alf__: yeah, correct. I pulled in the same change from the ubuntu branch
<duflu> Don't worry
<duflu> Because metadata needs updating anyway
<duflu> Oh, hang on. Which MP was that?
<alf__> duflu: https://code.launchpad.net/~kdub/mir/mir-0.20.1-changelog/+merge/287524
<duflu> alf__: Umm landed in r3350
<duflu> Apparently due to someone top approving it before I even reviewed it
<duflu> Not important...
<duflu> What I meant to say was that I landed the same on lp:mir/0.20 manually
<duflu> alf__: That probably happened due to an accidental top approve (by kdub?). Maybe Jenkins needs a sanity check to not land things without human approvals
<duflu> Or maybe camako or someone top approved it this morning
<duflu> People sometimes do without adding reviews
<duflu> Hmm, I had an important additional bug to fix
<duflu> And can't remember what it was
<alan_g> anpok_: @https://bugs.launchpad.net/mir/+bug/1543049 are you working on this? I've fixed similar conflicts with the mesa drivers and am happy to look into it.
<ubot5> Launchpad bug 1543049 in Mir "InputPlatformProbe.x11_platform_found_and_used_when_display_connection_works breaks with old input drivers present" [Low,Confirmed]
<anpok_> alan_g: nope not working ..
<anpok_> but thinking a bit about how the system should behave..
<anpok_> also because of this one https://bugs.launchpad.net/mir/+bug/1286252
<ubot5> Launchpad bug 1286252 in Mir "mir_demo_server* successfully start as non-root (without input support), meaning it can't be quit/switched away from" [Medium,Triaged]
<anpok_> which isnt related apart from the probing logic..
<alan_g> anpok_: as you explained the bug to me would you review this: https://code.launchpad.net/~alan-griffiths/mir/fix-1543049/+merge/287644 (thanks)
<alan_g> alf__: still after a phone? https://insights.ubuntu.com/2016/02/22/meizu-pro-5-ubuntu-edition-available-for-pre-order-now/
 * alan_g wonders if mir_stress is useful in its current form
<anpok_> alan_g: we get the modules in descending order?
<alan_g> anpok_: yes, the're sorted by .so number
<anpok_> oh nice
<alan_g> Yes, that's used in picking the client graphics module too
<alex_______> Hey, guys. I wonder if X11 apps need to be ported, or modified to work with xmir?
<anpok_> well if they can deal with what xmir provices they should work.. I can imagine xmir not supporting all x-protocols out there..
<anpok_> *provides
<alex_______> Thanks,  anpok_
#ubuntu-mir 2016-03-02
<alan_g> anpok: do we ever want multiple input modules? (I'm wondering if probe_input_platforms() must return a collection - things are simpler if there can be only one.)
<anpok> alan_g: hm at some point I thought it would be useful.. but at the moment it is rather causing troubles when both x11 and evdev are in use..
<anpok> in other words there is currently no use case for it
<anpok> alan_g: by changing that you would avoid this problem: https://bugs.launchpad.net/mir/+bug/1528110
<ubot5> Launchpad bug 1528110 in Mir "Mir On X (mesa-x11) keeps receiving mouse movement events even when not focused" [Medium,Triaged]
<anpok> which only happens when you run as root from an x11 terminal..
<alan_g> anpok: and it would greatly simplify addressing the issue Chris and I have been discussing in https://code.launchpad.net/~alan-griffiths/mir/fix-1543049/+merge/287644
<alan_g> Would the hypothetical "useful" scenaro be better addressed by an input module that "talked" to multiple drivers underneath?
<anpok> alan_g: I think just changing the code to yield a single result is fine untill we find a use case in which it would be "useful" -
<anpok> or actually the use case was for unity8 to inject user input..
<anpok> but they just changed the setup..
<anpok> and they are currently allowed to use uinput to inject it there..
<anpok> then again .. there are various places were we could allow input injection..
<alan_g> Multiple "platforms" isn't how I'd support injection. Weird devices that use strange drivers mixed with normal ones, maybe, if that actually happens and matters.
#ubuntu-mir 2016-03-03
<tomodachi> hi guys,  what does "pending gpu driver availability" mean in the mir roadmap exactly
<alan_g> tomodachi: I need a bit more context to avoid simply rephrasing. What document are you reading?
<duflu> alan_g: Try the links in the topic line :)
<duflu> April 2016: Pending GPU driver availability and achieving Unity8 feature parity, enable Unity8-Mir as a potential default desktop configuration.
<duflu> The doc may need updating
<duflu> To dinner and beyond...
<tomodachi> alan_g:  topic links to ubuntu mir wiki, where there is a roadmap entry. I was wondering what pending gpu driver availability meant
<alan_g> I didn't write it but that's about ensuring a good experience with the full range of desktop gpu drivers (mostly the blobby ones).
<tomodachi> the blobby ones i guess we cant do much about ourselves, but what about the non blobby ones?
<alan_g> Essentially a done deal
<alan_g> Ubuntu carries some patches that want to go upstream at some point, but probably after round of updates
<tomodachi> alan_g: sweet, thanks for your answers and time ..
<alan_g> anpok_: are you answered on https://code.launchpad.net/~alan-griffiths/mir/start-tidy-up-of-InputManager/+merge/287810?
#ubuntu-mir 2016-03-04
<talmage_> How do I install ubuntu touch on my x86 wetab?  I already have 16.04 desktop installed.
<talmage_> I was referred here by people in #ubuntu-touch.
<ogra_> and you dont want "ubuntu-touch" but the unity8 desktop session ...
<anpok> you would need to install unity8-desktop-session-mir and ensure that you mir-graphics-drivers-desktop .. which will pull in the mesa drivers
<anpok> ogra_: is there a way to get click store applications running with desktop u8?
<talmage_> unity8-desktop-session-mir requires unity8.
<talmage_> will that give me all of the scopes, too?
<talmage_> unity8 Recommends: unity-scope-click, unity-scope-mediascanner2, unity-scope-scopes
<ogra_> anpok, i dont think there is ... there are deb builds of teh core apps in some PPA dpm maintains (ask in #ubuntu-app-devel)
#ubuntu-mir 2017-02-27
<alan_g> dednick: this might well affect you - https://code.launchpad.net/~alan-griffiths/miral/fix-initialization-order/+merge/318353 (I can't see how this ever worked)
<tjaalton> bregma: hi, I still need this patch to build the xserver, maybe you have glamor disabled on your build? http://pastebin.com/YpDyBkqP
<bregma> tjaalton, I just slap my refreshed patch into your git packaging branch and submit to a zesty pbuilder to build, but I don't believe I have -proposed in my pbuilder environment, maybe that's the difference?
<tjaalton> bregma: no that's not required
<tjaalton> ah
<tjaalton> well
<tjaalton> if you use the packaging branch then you get this patch :)
<tjaalton> but it doesn't build without
<tjaalton> "xmir-fixes.diff"
<bregma> tjaalton, I can import that patch upstream if you prefer
<tjaalton> bregma: yep, please
<tjaalton> had it separate since 1.18 :)
<bregma> tjaalton, OK, give me a little while to verify
<tjaalton> you can check with the packaging branch, it's uptodate now
<mterry> Hello!  Can I get some help with some odd unity8/mir behavior I'm seeing that's interrupting some snappy work?  Let me lay out scenario...
<mterry> I'm trying to make the unity8 snap use the mir-libs snap
<mterry> And so I'm pointing it at the server-platform bits there
<mterry> But Mir is trying to load library from system...
<mterry> Here's a pastebin where I've printed out each dlopen as we intercept it in some ld-preload trickery we have
<mterry> http://pastebin.ubuntu.com/24079316/
<mterry> AlbertA: ^ ?
<mterry> You can see it finds the server platform in mir-libs
<mterry> But later on it tries to load from system, gets shunted into snap by our ld-preload hacks, and then isn't found
<mterry> It's loading the client platform just fine thoug
<alan_g> mterry: that sounds like something that Saviq was asking about. So: you're trying to connect to a host server (USC) that's using drivers from system?
<mterry> alan_g: yes -- and that is a ticking time bomb, but I would expect it to work in this case, where the versions match
<Saviq> bug #1665123
<ubot5> bug 1665123 in Unity8 Session Snap "Mir graphics platform determined based on host server outside of snap" [High,Triaged] https://launchpad.net/bugs/1665123
<alan_g> mterry: agreed, this isn't a supported scenario.
<Saviq> mterry, is /snap/unity8-session/x7/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12 there? should it be there?
<mterry> Saviq: it's not there in this testing snap I'm making where I'm trying to use mir-libs instead
<mterry> Saviq: I had thought that bug was just about version mismatch, but now I see it dives deeper
<mterry> alan_g: ... well Mir team won't support a snap that doesn't use mir-libs.  But now the Mir team won't support a unity8 that does?
<alan_g> mterry: there are *a lot* of unanswered questions about how we can support Mir on snaps.
<Saviq> mterry, MIR_SERVER_PLATFORM_PATH doesn't help?
<alan_g> So: Mir team can't support snaps (yet)
<alan_g> Saviq: no
<mterry> alan_g: understood...  but but we've had several meetings where the Mir team said mir-libs was the answer
<mterry> Sounds like the guidance is that the Personal team is blocked on Mir team
<alan_g> mterry: Mir team says "both server and client should use mir-libs" - but that's not what USC is doing.
<mterry> I mean, not *blocked* blocked.  We can run something on the screen, I'll just stop using mir-libs
<mterry> alan_g: there was talk of Mir team providing an implicit :mir-libs interface on Ubuntu 16.04 that pointed at USC libraries to solve this
<Saviq> yeah, we need more meets like that, it doesn't seem to be the answer AFAICT... there's just too much ABI dependencies there still
<mterry> alan_g: that way same guidance (use mir-libs interface) would work in all places
<mterry> But I had hoped in mean time, we could use it as long as versions matched
<mterry> Sounds like I'll avoid it for now until it works better
<alan_g> mterry: well... I don't think nesting will work that way either.
<alan_g> We have plans that resolve a lot of these issues. But not in the 0.26 series.
 * alan_g knows that doesn't help you now
<mterry> Yeah, this is disappointing after fighting with the Mir team to avoid the long-term problems of mir-libs, but settling on it because it was the only solution that seemed to work in short term.  But now it doesn't even help with the short term problems.  So...
<alan_g> mterry: the way we get nested working is https://trello.com/c/TzcWYzxM/498-remove-guest-platforms
<mterry> I don't have access to that, but no biggie, understood there's work in progress
<mterry> Hopefully mir-libs will eventually solve our middle-term problems
<alan_g> IMO it is the least painful option, but far from ideal.
<alan_g> And not pain free
<AlbertA> mterry: so this is unity8 snap on top of classic?
<AlbertA> with usc started by classic?
<mterry> AlbertA: unity8 snap on top of 16.04 yes, with deb-based USC
<mterry> i.e. the only currently supported way to run unity8 snap
<mterry> Hmm, I can use a symlink trick to solve this in short term...
<AlbertA> mterry: so, isn't this the issue in your particular example?
<AlbertA> "MIKE dlopen /usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12 -> /snap/unity8-session/x7/usr/lib/x86_64-linux-gnu/mir/server-platform/graphics-mesa-kms.so.12"
<AlbertA> maybe the shim preload should redirect mir libs as well...
<mterry> AlbertA: yeah I'll just set up a symlink in our snap to point at mir-libs version -- that can get us working in short temr
<AlbertA> right
<mterry> AlbertA: symlink will do same.  I'd prefer to avoid adding more code to our preload
<mterry> Trying to drop that hack  :)
<AlbertA> mterry: yep
<bregma> tjaalton, merged in that patch, build-tested and verified on zesty
<tjaalton> bregma: great, thanks
#ubuntu-mir 2017-03-01
<davmor2> hey guys in kvm the unity8 resolution is fixed to 1024x768 iirc is there a way to trick this into being 1920x1080 as it is the client that sets the resolution size in kvm.
<kgunn> attente: hey, just to help my expectations, do we rely on upstream gtk or do we carry patches locally?
<kgunn> for instance the fix for this
<kgunn> https://bugs.launchpad.net/ubuntu/+source/unity8/+bug/1663106
<ubot5> Ubuntu bug 1663106 in ubuntu-ui-toolkit (Ubuntu) "[regression] Logging in to Unity8 takes 25 seconds (the default DBus timeout)" [High,Fix committed]
<kgunn> attente: another thing i guess i'm asking...what's the cadence there? like how long does it take from hitting upstream to make it back into ubuntu releases?
<attente> kgunn: is that bug related to gtk?
<kgunn> attente: yeah, you had a comment that traced to this commit
<kgunn> https://github.com/GNOME/gtk/commit/670ae58cc9c69cb295822e8e41abd9497171404e
<kgunn> hence why i was asking...i just don't have a good feel for that sort of thing
<attente> kgunn: they're doing releases of gtk 3 "as-needed", but we can carry patches locally sooner to get the fixes out faster, dropping them when upstream does another release
<attente> kgunn: that commit was supposed to be released, but the upload is blocked on the u-a-l removing upstart transition
<kgunn> attente:  thanks, wrt u-a-l change is that ted?
<attente> kgunn: yes
<kgunn> attente: or xnox actually? .... is that it > https://bileto.ubuntu.com/#/ticket/2048
<attente> kgunn: i believe ted is working on https://code.launchpad.net/~ted/ubuntu-app-launch/rm-rf-upstart/+merge/318039
<kgunn> ack
<alan_g> Can anyone suggest a cleaner API than this? https://code.launchpad.net/~alan-griffiths/miral/fix-1668651/+merge/318616
#ubuntu-mir 2017-03-02
<alan_g> greyback: I'm needing a discussion about API design. Would you be willing? Doesn't need to be now. (Context is https://code.launchpad.net/~alan-griffiths/miral/fix-1668651/+merge/318616)
 * alan_g wonders if greyback saw the the above
<alan_g> greyback: I'm needing a discussion about API design. Would you be willing? Doesn't need to be now. (Context is https://code.launchpad.net/~alan-griffiths/miral/fix-1668651/+merge/318616)
<greyback> alan_g: ack, thanks for the repeat (got you the first time)
<alan_g> ;)
<alan_g> dednick: if you can add the missing test (for a scenario U8 won't use) I can land https://code.launchpad.net/~mir-team/miral/move_workspace_content/+merge/318589
<dednick> alan_g: ack. will try get to it today.
<alan_g> dednick: any other feedback or niggles with the workspaces APIs?
<greyback> alan_g: ok I understand the problem. What api question have you?
<alan_g> /1/ should I rely on user code to do the thread co-ordination? Or engineer some safe defaults?
<alan_g> /2/ Should I provide a declarative for internal clients to be notified of intending shutdown, instead of the ugly "hook" in the MP?
<dednick> alan_g: so far it all seems fine and easy to work with. my only issues so far are boundaries between qtmir/unity8, but that's our issue...
<greyback> alan_g: for 2: a nicer solution could tie in with solving bug 1624407 nicely
<ubot5> bug 1624407 in mir (Ubuntu) "Add a 'quit' message that is app-wide, as opposed to mir_event_type_close_surface" [Medium,Triaged] https://launchpad.net/bugs/1624407
<alan_g> greyback: Ah, that's a more natural way to notify clients than I'd thought of. (But won't work for Mir < 0.27)
<greyback> alan_g: ok. But would be nice long-term goal
<alan_g> I'm not rejecting it, just thinking it isn't something I could do for 1.3
<greyback> alan_g: for 1, since InternalClient takes the responsibility to create the thread at the right time, I do think it has responsibility in destroying it at the right time.
<greyback> so a safe default would be nice. Again, I'm not opposed to telling API users: hey, on shutdown, be prepared to do...
<alan_g> Right, now for the next question...
<alan_g> /3/ Do we need to support the "general case"? (I.e. shall I put all the magic "under the API" and not expose the join thread logic for clients at all?)
<alan_g> I don't see that we need it (yet)
<greyback> I don't think so either
<dednick> alan_g: added test.
<alan_g> dednick: cool!
 * alan_g wonders if dandrader could use the InternalClient::join_client_thread() for his internal test clients
<greyback> that's been a use-case I've had in mind. I don't think we've hit any shutdown crashes though
<greyback> but that mainly because the internal clients are managed by the tests themselves
<alan_g> is he about this week?
<greyback> he is, back today
<duflu> alan_g: I am stuck in multiple-prerequisite-limbo again. Would you mind looking at my little cleanup branches?
<duflu> I need to EOD
<alan_g> duflu: sure. (later) any recommendations?
<duflu> alan_g: Just the little ones from the past two days
<duflu> And then I see another mistake
<duflu> Errors stopping errors from stopping errors getting fixed
<duflu> from getting fixed
<greyback> alan_g: any tips on how to reproduce the miral-shell crash on shutdown? ctrl+alt+backspace (if so, I need to stop X listening for that)
<alan_g> That's what I used, but Ctrl-C would also work
<alan_g> But because of the other bugs all you really see is an EXIT_FAILURE
<duflu> Fun fact: the only apparent Mir crash that's bringing down unity8 a lot right now is the setting of invalid keymaps
<alan_g> greyback: I know you were looking at it before I'd made it WIP, but you TA'd it after I'd made it WIP. Was that really intended?
<greyback> alan_g: I didn't know you made it WIP, sorry
<alan_g> I was adding the changes we discussed. Not removed the new APIs yet.
<alan_g> greyback: done with it now, take another look?
<greyback> will do
<redduckx> nope
<redduckx> ./quit
#ubuntu-mir 2017-03-03
<alan_g> greyback: I've tried to fix ~alan-griffiths/qtmir/tidy-mirserver-deps - let me know if this version works for you
<greyback> alan_g: ok
<dandrader> andyrock, did you fix the issue I commented about in https://code.launchpad.net/~andreas-pokorny/qtmir/store-and-recover-cookie-and-input-device-id/+merge/318528 ?
<dandrader> s/andyrock/anpok
<dandrader> anpok, saw the you pushed some new commits there
<dandrader> *that
<anpok> dandrader: yes..
<anpok> dandrader: i missed that dispatchEvent was only used in tests.. but I cannot really reproduce the problems with vt switching
<anpok> for one .. vt switch out of X is broken in this machine.. so I am left with only running it in VirtualBox .. which as of yesterday works with unity8/mir
<dandrader> anpok, WHAT!?!?!? unity8+mir works in VirtualBox!!!!???
<anpok> only on my desk so far
<dandrader> anpok, ahhhh....
<dandrader> anpok, as for the VT switch bug: no problem. the patch makes sense regardless
<alf_> anpok: \o/
<anpok> dandrader: but you can get it on yours by rebuilding vbox yourself with this patch: https://www.virtualbox.org/pipermail/vbox-dev/2017-March/014293.html and copy vboxvideo.ko into the guest
<dandrader> I pass
