[02:17] <robert_ancell> duflu, are you getting cursors when running Xmir through mir_demo_server?
[02:17] <robert_ancell> They seem to disappear when a client appears
[02:17] <duflu> robert_ancell: Yes, not always visible. Much invisible much less often than before :)
[02:17] <robert_ancell> duflu, any ideas of the cause?
[02:18] <duflu> robert_ancell: There's an upstream Mir bug Alan is fixing right now. I need to test how much that helps. As Mir itself is failing to put the cursor on screen
[02:19] <duflu> robert_ancell: Bug 1308133 but also bug 1498737
[02:19] <ubot5`> bug 1308133 in Mir "Mir cursor is missing/invisible until the client sets it multiple times" [High,In progress] https://launchpad.net/bugs/1308133
[02:19] <ubot5`> bug 1498737 in xorg-server (Ubuntu) "Xmir apps sometimes show the wrong mouse cursor" [Medium,New] https://launchpad.net/bugs/1498737
[05:40] <RAOF> Well, there you go. ld.gold is only twice as fast as ld.bfd at linking Mir (25s vs 50s).
[05:45] <duflu> RAOF: Unstripped binaries less huge?
[05:46] <RAOF> Nope. I'm not really sure why you'd expect them to be?
[05:47] <duflu> RAOF: Just hopeful some of our problems are not our fault... https://bugs.launchpad.net/mir/+bug/1473330
[05:48] <ubot5`> Ubuntu bug 1473330 in Mir "mir_*_tests binaries are suspiciously large. Up to 248MB before stripping." [Undecided,New]
[06:27] <anpok_> gold just adds the ability to use lto you then still need to use -flto -fuse-ld=gold .. and replace ar with gcc-ar and ranlib with gcc-ranlib
[06:27] <anpok_> and then .. fix all the problems on the way..
[06:29] <duflu> Life is confusing when your tooltips are draggable
[06:30] <duflu> And resizable. Awseome
[06:30] <duflu> Awsome
[06:31] <anpok_> RAOF: were additional changes needed to get gold running?
[06:39] <RAOF> anpok_: We need to stop putting some extern "C" symbols in an extern "C++" symbols.map, but apart from that... :)
[06:40]  * RAOF will propose a branch.
[06:40] <anpok_> here it complained about missing android log stuff in those to be removed parts..
[06:40] <RAOF> Correct.
[06:40] <anpok_> ok cool so thats part of it
[06:41] <RAOF> It's complaining because it can't find those symbols (which are extern "C") because we've marked them as extern "C++" in the symbols.map.
[06:41] <RAOF> It then goes on to warn that we're sloppy with wildcards in the symbols.map files, but that's only a warning.
[07:18] <anpok_> :a
[07:22] <RAOF> Bah!
[07:23] <RAOF> CachedPtr is a way of turning compile-time errors into runtime segfaults :(
[07:32] <RAOF> Ok vogons: I've got a cyclic dependency in DefaultServerConfiguration:
[07:33] <RAOF> the_session_coordinator requires the_mediating_display_changer which requires the_compositor which requires the_shell which requires the_session_coordinator.
[07:34] <RAOF> How have our salubrious vogons broken such cycles in the past?
[07:36] <anpok_> plan a) figure out why they need each other.. sometime it turns out, that all you need is a third thing to untangle something..
[07:36] <anpok_> plan b) set the cycle causing thing after construction
[07:56] <RAOF> New plan: just expose the_display() further.
[07:58] <guest56723> No provider of eglCreateSyncKHR found.  Requires one of:
[07:58] <guest56723>     EGL extension "EGL_KHR_reusable_sync"
[07:58] <guest56723> i get this with Xmir -egl (am i missing extenstions?)
[07:59] <RAOF> Would seem to be the case, yes.
[07:59] <RAOF> What are you running that on, and do you actually have EGL_KHR_reusable_sync there?
[08:00] <RAOF> (This shouldn't be something that Mir has botched up)
[08:02] <guest56723> 04:00.0 VGA compatible controller: NVIDIA Corporation G84 [GeForce 8600 GT] (rev a1) (prog-if 00 [VGA controller])
[08:04] <RAOF> Hm. Well, I don't have that extension on my haswell intel GPU either, so I'm not sure who has tested Xmir -egl :)
[08:04] <RAOF> It's possible that it only works on android EGL implementations at the moment ;)
[08:04] <RAOF> EEEEEEEEEEEEEEEoooooooohdeeeeeeeeeeeee!
[08:04] <guest56723> must be the case :D
[08:05] <guest56723> i am trying all the args because i get a black window :))
[08:05] <guest56723> -sw -damage also doesn't work
[08:05]  * guest56723 such is life on nvidia :(
[08:07] <guest56723> glmark2-mir goes 100% cpu after 6 sec, and glmark2 segfaults with nvidia driver :/
[08:25] <anpok_> guest56723: what application are you running inside xmir/
[08:26] <guest56723> anpok_, geany
[08:27] <guest56723> anpok_, firefox, chrome, even some 3d games used to run well some (aka long) time ago
[08:43] <tsdgeos> guys anything for me to do in https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751 ?
[08:43] <tsdgeos> i hope those test failures are not because i changed some struct/class :D
[08:47] <alan_g> tsdgeos: I'm still catching up, but I think you'll find that was a valgrind bug introduced win the latest version.
[08:47] <alan_g> It hit several jobs
[08:48] <tsdgeos> alan_g: you mean as a bug in valgrind? or a bug that you introduced that valgrind found?
[08:48] <alan_g> tsdgeos: https://code.launchpad.net/~mir-team/mir/workaround-for-valgrind-opcode/+merge/272997
[08:50] <tsdgeos> interesting
[08:50] <tsdgeos> alan_g: so just re-top approve?
[08:50] <alan_g> yep
[08:52] <anpok_> vogons: is relying on umockdev in acceptance tests something to be avoided/
[08:53] <alan_g> tsdgeos: I still suspect you'll need to add "-Wno-mismatched-tags" to qtmir at some point.
[08:53] <tsdgeos> alan_g: why?
[08:54] <alf_> anpok_: The problem is not so much relying on something that mocks udev, as it is that this adds the requirement of running the tests with umockdev-wrapper
[08:54] <alan_g> anpok_: Personally, I'd rather the tests that use umockdev were in their own binary
[08:55]  * alan_g thinks it clear madness that "unit" tests use umockdev
[08:56] <alan_g> tsdgeos: no-one else cares about this distinction. C.f. https://code.launchpad.net/~aacid/mir/fix_forward_declarations/+merge/272751/comments/687703
[08:56] <tsdgeos> alan_g: well i do :D
[08:56] <alan_g> but as soon as you include headers from a 3rd party that doesn't
[08:57] <alan_g> Of course, There's always "-Dclass=struct"
[08:57] <tsdgeos> sure of course as we include headers from a 3rd party that doesn't want to fix it
[08:57] <tsdgeos> we'll have to disable it
[09:02] <anpok_> alan_g: I know I added some of that madness.. and I think I can undo most or all of that madness..
[09:03] <alan_g> anpok_: you were not the only one. What's your plan for fixing it?
[09:03] <anpok_> alan_g: for input related.. convert all code to libevdev and mock libevdev..
[09:03] <anpok_> then change the interface of udev monitor and enumrator
[09:04] <anpok_> (^libevdev - code where the device is directly accessed..)
[09:05] <anpok_> i would probably make device enumeration a part of a generic monitor interface..
[09:06] <anpok_> i started the second part some time ago.. then lost myself in details ..
[09:06] <alan_g> LOL
[09:08] <alan_g> Not really. Our input code is a maze of twisty passages all different. And you got lost.
[09:08] <anpok_> yeah it was harded when I tried to also change EventHub to that interface
[09:08] <anpok_> *harder..
[09:08] <anpok_> but I wouldnt even try this time
[09:09] <anpok_> but back to acceptance tests.. I think we should have tests that show that input device configuration affects the input events
[09:09] <anpok_> .. clients would receive
[09:09] <anpok_> for that I need stubbed graphics but real input on simulated evdev devices..
[09:10] <alan_g> Of course we need those tests. I just don't want them in the same binary as tests that don't mock udev (because the wrapper is a PITA)
[09:12] <anpok_> i see
[09:13] <alan_g> Ideally there's an implementation of your "generic monitor" that gets tested with umockdev in one binary and everything else gets a test double.
[09:14] <alan_g> But we don't live in an ideal project (yet).
[10:19] <Saviq> hey all, can someone please help me debug a unity8 desktop session issue? the screen seems to get turned off straight away - I can see the cursor flashing for a split second and then everything goes blank
[10:20] <Saviq> I can ssh into the machine and see that unity8 & co. are running fine, I ran the demo server and clients successfully, as well as u-s-c and unity8 alone (as root)
[10:21] <Saviq> but if I launch the session it just goes black :/
[10:21] <Saviq> I thought for a moment the timeout's kicked in, but pressing power just shut the machine down
[10:25] <bregma> Saviq, anything suspicious in /var/log/lightdm/* ?
[10:39] <Saviq> bregma, if I read http://paste.ubuntu.com/12631020/ correctly (lightdm.log.old), it went from starting the compositor to stopping it immediately?
[10:40] <Saviq> let me clear the folder and try again, brb
[10:41] <seb128> unsure if that's the driver issue robert_ancell was seeing
[10:41] <seb128> could be worth asking him tonight when he's online
[10:43] <duflu> greyback: Hey this should be easy for someone in the know to solve quickly now I've traced the problem down. But EOD... https://bugs.launchpad.net/qtmir/+bug/1497828
[10:43] <ubot5`> Ubuntu bug 1497828 in unity8 (Ubuntu) "Apps appear to freeze in Unity8, although they are really still rendering (swap interval zero). Need to interact with the shell to unfreeze it." [High,New]
[10:44] <duflu> Saviq ^
[10:44] <duflu> And good night
[10:44] <greyback> duflu: hmm, thanks
[10:46] <bregma> Saviq, have you explicitly installed the Mesa drivers on your desktop?  That's been a problem in the past.
[10:47] <Saviq> bregma, I did not, but mir demos work fine, as do unity8 and u-s-c alone
[10:48] <Saviq> bregma, seb128, here's a collection of logs: https://owncloud.sawicz.net/index.php/s/0afe9e8a599ef8fef2f2a105e9db357d/download?path=%2F&files=logs.tgz
[10:49] <Saviq> bregma, seb128, I'm almost certain this has something to do with disabling the screen, as when I restarted lightdm (remotely) it was still blank until I disabled and enabled it again
[10:49] <seb128> seems a bit similar to robert's issue...
[10:50] <Saviq> i.e. I heard the greeter sound with a black screen, connected an external screen that worked just fine, and had to disable and enable the screen again in the screens panel to bring it back
[10:50] <Saviq> indeed
[10:50] <seb128> I think he showed it to alan_g in London
[10:51] <seb128> alan_g, do you remember what issue robert_ancell was having in london with his screen going blank after the xserver exited
[10:51] <seb128> alan_g, do you know if he opened a bug?
[10:52] <alan_g> seb128: I remember he had a problem on startup (which got fixed)
[10:52] <alan_g> That was about two versions client mesa module behaving badly
[10:53] <seb128> right
[10:53] <seb128> that's different
[10:53] <seb128> he couldn't start an unity8 session then
[10:53] <seb128> he has his screen going blank after the xserver exited I think
[10:56] <Saviq> the greeter exiting could cause that... I wonder if I do auto-login will the same happen
[10:57] <alan_g> Not sure if I even saw that. Certainly I didn't investigate.
[10:58] <Saviq> seb128, do you know where the user-default session type is stored?
[10:58] <seb128> Saviq, type?
[10:58] <Saviq> seb128, I mean ubuntu vs. unity8
[10:58] <Saviq> seb128, I wanna try auto-login to bypass the greeter altogether
[10:58] <Saviq> but gotta be able to change the session remotely if it doesn't work
[10:59] <seb128> Saviq, /etc/lightdm or /usr/share/lightdm/lightdm.conf.d
[10:59] <seb128> the second one has files from packages like unity8-desktop-session-mir
[10:59] <seb128> the /etc one is for user changes
[10:59] <Saviq> seb128, hmm, but where is the user selection stored? like when you log in to a different one, it remembers? AccountsService maybe?
[11:00] <seb128> oh, yes
[11:00] <seb128> Saviq, /var/lib/AccountsService/users/<userid>
[11:01] <Saviq> seb128, thanks
[11:01] <seb128> yw
[11:01] <seb128> XSession=ubuntu
[11:01] <seb128> in there
[11:01] <Saviq> ok, let's see how that works
[11:01] <Saviq> brb
[11:17] <Saviq> seb128, that worked! so indeed the issue seems to be the same, transition between X (greeter) and mir causes the screen to be blanked
[11:17] <seb128> k
[11:18] <seb128> can you email robert asking if he filed a bug about the issue/if he has details (maybe Cc me on it)?
[11:18] <Saviq> will do
[11:19] <seb128> thansk
[14:10] <tjaalton> kgunn: hey, so there's a new mesa point-release in ppa:canonical-x/x-staging now
[14:10] <kgunn> tjaalton: thanks you
[14:11] <kgunn> vogons just a heads up ^
[14:11] <kgunn> point release should be less risky
[14:11] <tjaalton> should I just upload to wily?
[14:12] <tjaalton> and yeah, no surprise drama to be expected in wily anymore
[14:15] <kgunn> tjaalton: yeah, just upload - at least we'll be aware if we see an issue on wily ci
[14:15] <tjaalton> ok
[14:15] <tjaalton> thx
[17:30] <greyback__> anyone know if xkbcommon has a debug symbols package available?
[23:17] <RAOF> I really don't see what “switch to libevdev but implement all of its API it as a mock” gains us over “use libudev and provide mock udev devices”
[23:18] <RAOF> It seems like a significant amount of work for negative gain.