[03:56] <RAOF> Hm. Has anyone else noticed the arale backlight not being turned off?
[04:11] <duflu> RAOF: Historically when that happens on any device most people don't notice :)
[04:12] <duflu> But it's not good
[04:18] <RAOF> Oh, well. LP# 1460898 filed.
[07:29] <RAOF> Oh, hey.
[07:29] <RAOF> Our GMainLoop alarm implementation blatantly ignores the specified behaviour of various calls.
[07:32] <RAOF> I'm pretty sure I relied on that behaviour in the FrameDroppingPolicy...
[07:35] <anpok> hm?
[07:35] <anpok> RAOF: I think something like SceneObserver could be replaced in a nicer way with signal/slot
[07:36] <RAOF> anpok: This is indeed what I was thinking, yes.
[07:36] <RAOF> anpok: Oh, AlarmImpl unconditionally returns true on cancel() (even if it didn't actually cancel), and likewise on reschedule.
[07:37] <RAOF> While the documentation says that they return true iff they cancelled something, rescheduled a pending alarm respectively.
[07:37] <anpok> in a previous system signal(event) / slot registrations with functor objects were the #1 memory consumers
[07:37] <anpok> but there we had hundreds of them
[07:37] <anpok> and most of them did not fit into the functor payload..
[07:38] <anpok> oh
[10:34] <alan_g> alf_: happy now? https://code.launchpad.net/~alan-griffiths/mir/helptext-mentions-config-file/+merge/260439
[11:19] <alan_g> greyback: tvoss do we want to reschedule the WM discussion? When?
[11:20] <greyback> alan_g: today is bad for me, am traveling. Wed & Thurs my timetable is uncertain, lots of meetings. Friday traveling again!
[11:21] <alan_g> greyback: OK. np.
[11:22] <greyback> best I can do is next week, Wed the earliest
[11:26] <alan_g> Fine by me. Today I'm more interested in how lp:~alan-griffiths/mir/only-visible-surfaces-change-scene/ might affect Qt clients and qtmir.
[11:28] <greyback> alan_g: let me have a look and I'll get back to you
[11:30] <tvoss> alan_g, we definitely should, next Wednesday is fine by me, too
[14:08] <kdub> alan_g, fixed the test name on: https://code.launchpad.net/~kdub/mir/multistream-protobuf-additions/+merge/259970
[14:11] <alan_g> kdub: TA'd
[14:12] <kdub> thanks alan_g
[15:09] <racarr> kdub: I've also run in to some problems with the event RPC lately...
[15:35] <kdub> racarr, which sort of problems?
[15:37] <racarr> kdub: oh I guess just that the memcpy to a flat buffer doesn't work for
[15:37] <racarr> some of the event cleanup I am doing as well
[15:37] <racarr> whic hsort of relates to your can't pass FD's over events perhaps
[15:38] <kdub> racarr, right, so if i'm scrubbing may as well scrub in a way thats helpful to that concern too
[17:06] <kgunn> vogons any running mir on nouveau lately ?
[17:07] <kdub> intel for me
[17:07] <camako> kgunn, yes I am on nouveau
[17:08] <kgunn> popey: ^
[17:08] <kgunn> camako: i think popey is trying to run unity8-desktop-session-mir on  nouveau
[17:08] <popey> gah, just logging into unity7 with nouveau gives me 1280x1024 not 1920x1080 :(
[17:08] <kgunn> i was telling him, mir + nouvea might be ok
[17:09] <kgunn> camako: so i figure your probably running mir+nouvea frequently
[17:09] <camako> kgunn, I'm not running U8 dektop session recently
[17:09] <kgunn> right...so problem might lie in the unity8 part
[17:09] <camako> kgunn, just mir
[17:09] <camako> and examples
[17:09] <kgunn> sure
[17:10] <kgunn> so popey, that answers that ^
[17:10] <popey> hmm, sudo mir_demo_server fails
[17:10] <popey> failed to load libraries from path /usr/lib/x86_64-linux-gnu/mir/server-platform
[17:11] <popey> following http://unity.ubuntu.com/mir/using_mir_on_pc.html Running Mir natively
[17:12] <popey> kgunn: so if I want to actually test Unity8 (specifically apps) what am I to do? Buy an intel laptop / tablet?
[17:13] <kgunn> popey: that might be easier :-P but seriously, let's see if we can get you some help....what's your gpu ?
[17:13] <kgunn> camako: ^ can i leave popey in your capable hands...
[17:13] <popey> nVidia GeFprce GTX 460
[17:13] <popey> *GeForce
[17:15] <camako> kgunn, don't really work on U8 desktop, so not sure how helpful I can be
[17:15] <kgunn> camako: he's failing on mir-demo-server
[17:15] <kgunn> please read
[17:16] <camako> kgunn, ah ok
[17:16] <camako> sorry
[17:16] <camako> popey, are you running in a vt?
[17:16] <popey> http://paste.ubuntu.com/11524763
[17:16] <popey> yes
[17:17] <camako> popey, let's step back, did you install the packages yourself? Or running from binaries you built from the tree?
[17:17] <AlbertA> popey: is this mir 0.13?
[17:17] <popey> i have a clientplatform in /usr/lib/x86_64-linux-gnu/mir but not a server-platform
[17:17] <popey> this is on wily, from repo
[17:18] <AlbertA> popey: apt-get install mir-platform-graphics-mesa2
[17:18] <popey> maybe I'm missing a package?
[17:18] <kgunn> ah yeah..isn't there a dumb issue about having to install graphics platform
[17:18] <popey> ok, it fails differently now :)
[17:19] <popey> http://paste.ubuntu.com/11524864/
[17:21] <kgunn> popey: i had to do this the other day, i did apt-get install mir-graphics-drivers-desktop
[17:21] <popey> ok
[17:21] <popey> same error after doing that
[17:22] <camako> popey do you have drm devices in your system?
[17:22] <camako> ls -l /dev/dri <<---
[17:23] <popey> ls: cannot access /dev/dri: No such file or directory
[17:23] <camako> popey that's the problem
[17:23] <camako> camako@camako-MacBookPro:~$ ls /dev/dri/
[17:23] <camako> card0       card1       controlD64  controlD65  renderD128  renderD129
[17:23] <camako> popey ^ ... mir needs card* devices to run
[17:24] <camako> popey, kernel version?
[17:24] <popey> Linux wopr.popey.com 3.19.0-20-generic #20-Ubuntu SMP Fri May 29 10:10:47 UTC 2015 x86_64 x86_64 x86_64 GNU/Linux
[17:29] <camako> popey at the top of the "Running Mir natively" page there are checks for hw
[17:29] <camako> what do they return?
[17:30] <popey> oh, i skipped that bit because kgunn told me to do the Running Mir natively bit, sorry.
[17:30] <popey> http://paste.ubuntu.com/11524937/
[17:33] <camako> popey, so I guess you don't really have a nouveau driver
[17:33] <camako> camako@camako-MacBookPro:~$ lsmod | grep drm
[17:33] <camako> drm_kms_helper        122880  2 i915,nouveau
[17:33] <camako> drm                   344064  9 ttm,i915,drm_kms_helper,nouveau
[17:33] <camako> camako@camako-MacBookPro:~$ sudo pmap `pidof X` | grep dri.so
[17:33] <camako> [sudo] password for camako:
[17:33] <camako> 00007fb9b76e5000   7620K r-x-- nouveau_dri.so
[17:33] <camako> 00007fb9b7e56000   2048K ----- nouveau_dri.so
[17:33] <camako> 00007fb9b8056000    348K r---- nouveau_dri.so
[17:33] <camako> 00007fb9b80ad000     48K rw--- nouveau_dri.so
[17:34] <popey> :(
[17:36] <camako> popey, I'm surprised your distro doesn't have it.... I guess it should be as simple as installing xserver-xorg-video-nouveau package... But proceed cautiously as you're meesing with the video driver
[17:36] <popey> ii  xserver-xorg-video-nouveau  1:1.0.11-1ubuntu2b amd64              X.Org X server -- Nouveau display driver
[17:36] <popey> it _is_ installed
[17:37] <popey> I'm on Ubuntu 15.10 (wily)
[17:38] <popey> aha, it's not being used. It's using FBDEV!
[17:38] <camako> popey, I'm still on vivid... perhaps this is a new (wily) nouveau issue
[17:38] <popey> that's why the resolution is wonky I guess.
[17:38] <popey> hmmm
[17:38] <camako> popey, some help here : http://nouveau.freedesktop.org/wiki/UbuntuPackages/
[17:38] <popey> aha https://wiki.ubuntu.com/X/Troubleshooting/VideoDriverDetection#Problem:__Need_to_fully_remove_-nvidia_and_reinstall_-nouveau_from_scratch
[17:39] <popey> need to _re_ install nouveau
[17:40] <camako> there you go...
[17:40] <popey> thanks for the help!
[17:40] <camako> yw
[17:40] <popey> silly software :)
[17:56] <popey> has mir_socket moved? I don't see it in /tmp
[17:57] <popey> aha! /run/user/1000/mir_socket
[17:58] <popey> Ok, so I have managed to get mir running, and ran a mir demo (mir_demo_client_eglplasma)
[17:59] <popey> so we have proved the video driver works now.
[18:00] <bschaefer> is there  a way to poke for the ABI version of mir?
[18:00] <bschaefer> with the new mir lib, i need to check what version of code I compile depending on the ABI version
[18:02] <popey> rebooting to lightdm, and choosing unity8 lxc session fails though.
[18:02] <popey> bunch of apparmor failures... http://paste.ubuntu.com/11525449/
[18:04] <popey> balloons: you tried this?
[18:05] <camako> bschaefer, mir version is printed to stdout (by default)
[18:06] <bschaefer> camako, ill need it through configure.ac though, is there a function that prints out the version?
[18:07] <bschaefer> there seems to be: mir_toolkit/version.h:65:    MIR_VERSION_NUMBER(MIR_CLIENT_MAJOR_VERSION, \
[18:07] <camako> bschaefer, there is a cmake variable MIR_VERSION
[18:07] <bschaefer> camako, o cool, thanks!
[18:08] <camako> yw
[18:08] <bschaefer> that works for cmake :), ill have to hack something for autogen
[18:49] <AlbertA> camako: alan_g|EOD: so the qtubuntu updates to match mir 0.13 made it to wily right?
[18:49] <AlbertA> shouldn't the branch be merged then?
[18:49] <camako> AlbertA, kgunn said that LT was investigating why it didn't get merged
[18:50] <camako> yes it should be merged
[18:59] <kdub> after the buffer semantics changes, we dont really have a stream anymore... but will cross that bridge later
[19:00] <AlbertA> camako: so should we merge it manually? or do we need to ask somebody?
[19:01] <camako> AlbertA, I am assuming LT will do it once they are through with their investigation. kgunn
[19:01] <camako> kgunn ^^
[19:02] <AlbertA> camako: ok...who is LT though?
[19:02] <kgunn> camako: AlbertA so we added that MP to the rotation silo4, mzanetti is working on landing it....which should merge it
[19:02] <camako> AlbertA, landing team
[19:02] <kgunn> is there another issue currently ?
[19:02] <AlbertA> camako: kgunn: ok...
[19:02] <AlbertA> kgunn: no just want to rebase my branch
[22:41] <AlbertA> @vogons: since technically we broke client API in mir 0.13.1 (like mir_surface_set_event_handler), the client/mir_toolkit/version.h should have bumped it's major number right?
[22:41] <RAOF> Yes. I thought we did the backwards-compatibility symver trick for that, though?
[22:42] <AlbertA> RAOF: yes we did
[22:44] <AlbertA> so I'll be attempting a mir 0.13.2 for entirely unrelated reasons (have to get the vegetahd quirk in)...
[22:44] <AlbertA> was wondering if I should fix it then.
[22:44] <RAOF> Oh, but we don't expose both in the API, right.
[22:44] <RAOF> Yeah, we should have bumped version.
[22:44] <RAOF> Otherwise there's no good way for client code to know what to build against.
[22:44] <AlbertA> RAOF: right which is what bschaefer wanted
[22:45] <racarr> and robert_ancell!
[22:45] <RAOF> Ding!
[22:45] <robert_ancell> yep
[22:46] <AlbertA> vogons: ok so mir 0.13.2 =  client 2.0.0, and lp:mir: client 3.0.0 since we broke for good there ?
[22:48] <bschaefer> thanks!
[23:31] <AlbertA> @vogons: just FYI I've requested a silo for mir 0.13.2 - with the intention of landing to vivid+overlay and wily
[23:32] <camako> AlbertA, sounds good. The freeze should be over soon.
[23:32] <camako> AlbertA, is only Mir in the silo?
[23:32] <AlbertA> camako: yes. with only the vegetahd quirk and the client API version fix
[23:33] <camako> great
[23:33] <AlbertA> camako: https://code.launchpad.net/~mir-team/mir/0.13/+merge/260902
[23:35] <camako> ok
[23:48] <bschaefer> strange crash... http://paste.ubuntu.com/11531043/ only seems to fail on SDL2 tests (if i run my own SDL2 app it works fine)
[23:51] <bschaefer> something in dynamic loader must be doing something strange...hmm