[01:23] <duflu> Gah. Summer must be coming. Everything has a spider living in it already :P
[01:26] <RAOF> :)
[04:54] <RAOF> Dear lord, upstairs is hot.
[04:55] <RAOF> Also, why must Qt have crappy font rendering?
[04:55] <RAOF> (Alternately, where do I tell Qt to render fonts non-crappily?)
[04:59] <RAOF> Hm. Hang on to shared_ptrs, or increment other people's reference counting?
[05:34] <Mirv> filed bug #1252144 on a test failure on builders
[05:41] <duflu> Mirv: Also, is the "UNRELEASED" a problem? mir (0.1.1-0ubuntu1) UNRELEASED; urgency=low
[05:46] <Mirv> duflu: no, it's fine and gets changed by cu2d as seen at https://launchpadlibrarian.net/156699885/mir_0.1.1%2B14.04.20131116-0ubuntu1.diff.gz
[06:10] <duflu> Mirv: If I propose a fix to lp:mir can we test it quickly? I can't reproduce the bug either...
[06:14] <RAOF> Does it fail on the PPA builders, too?
[06:15] <duflu> Looks like a silly-short timeout which will fail on a busy server. Proposing now...
[06:16] <duflu> Oh. Wait, no. It fails after 1ms
[06:32] <Mirv> duflu: yeah I can push to some PPA as well if needed
[06:32] <duflu> Mirv: We don't use PPAs in Mir any more. But proposing now...
[06:33] <Mirv> ok, seeing the branch
[06:41] <Mirv> building soon at https://launchpad.net/~canonical-qt5-edgers/+archive/qt5-daily/+sourcepub/3666854/+listing-archive-extra
[06:43] <duflu> RAOF: When is an appropriate time to add resize support to Mesa? There are prerequisite changes in Mir 0.1.2 that it will need, but can we update git immediately?
[06:43] <RAOF> We can update git any time you want.
[06:45] <duflu> RAOF: In that case, may I ask you to look at my two lines of logic and update the buffer acquire/release stuff to suit?
[06:45] <duflu> two-ish
[06:46] <RAOF> :)
[06:46] <RAOF> Certainly. Where are they?
[06:46] <duflu> RAOF: https://launchpadlibrarian.net/156390351/mesa-mir-resize-support.patch
[06:47] <duflu> It works now... but of course we don't have any demo clients using non-colour buffers yet
[06:47] <RAOF> How do clients know to change their rendering, by the way?
[06:47] <duflu> RAOF: They presently query EGL. Events are coming soon
[06:48] <duflu> For example: https://code.launchpad.net/~vanvugt/mir/resize-examples/+merge/194833
[06:49] <RAOF> Added to git.
[06:49] <duflu> RAOF: Ta muchly
[06:50] <RAOF> Oh, also; why is there a check for buffer.width and buffer.height?
[06:51] <duflu> RAOF: So it falls back to the existing (working) behaviour if you accidentally run it against an older Mir
[06:51] <RAOF> Ah, ABI.
[06:51] <duflu> ... where they are zeroed fields
[06:51] <RAOF> Yeah, fair call.
[06:52] <duflu> It's both sad and exciting that resizing surfaces is one of the most dramatic things you will see on demo_server* right now
[08:01] <duflu> RAOF: Were you referring to jaggies on touch earlier? I see them now :P
[08:16] <duflu> Mirv: Jenkins is reporting CI failures which are actually problems with the build machine and not the code :(
[08:16] <duflu> https://code.launchpad.net/~vanvugt/mir/fix-1252144.trunk/+merge/195547
[08:38] <Mirv> duflu: yep, retrying in case it helps
[09:42] <duflu> alf_: Do we ensure xbgr is listed before abgr so dumb clients like unity-mir will grab the first (fastest) pixel format?
[09:44] <alf_> duflu: no, on the contrary, we return pixel formats in descending "active" bits order (abgr = 32, xbgr = 24)
[09:44] <duflu> alf_: Is that a good idea
[09:44] <duflu> ?
[09:47] <alf_> duflu: It's a more predictable ordering (and helps a bit when searching for particular formats), sorting by "fastest" is not. In any case, if unity-mir, or any other app needs a particular surface type they should search for it, not rely on formats[0] being what they want.
[09:47] <duflu> alf_: Yeah I was trying to avoid fixing and rebuilding unity-mir
[09:48] <alf_> duflu: (because we may indeed decide to change the ordering in the future)
[09:49] <duflu> alf_: OK. I think we need to improve on format lookups in future. Perhaps like bug 1236254
[09:50] <alf_> duflu: yeah, I was looking at the DRM fourcc format, but it's a bit arbitrary unfortunately
[09:51] <alf_> duflu: (/usr/include/drm/drm_fourcc.h)
[09:51] <duflu> alf_: Yeah I know it, but it does not solve the problem
[09:55] <alf_> duflu: alan_g: @offscreen-platform, are you happy with renaming to OffscreenDisplayContext or OffscreenNativeDisplay or ...
[09:55] <duflu> alf_: I think I prefer OffscreenPlatform more :S
[09:56] <alan_g> alf_: reminding myself...
[09:57] <alf_> duflu: alan_g: Unless we go with one of the other methods (e.g. adding egl_native_display() to platform directly and having an independent OffscreenPlatform interface)
[09:58] <duflu> alf_: Or just make OffscreenPlatform a real platform and drop the pure virtual requirement :)
[09:59] <alan_g> alf_: the name doesn't bother me much - but I would suggest BasicPlatform/MinimalPlatform would be a better base for Platform than OffscreenPlatform
[10:00] <duflu> Yeah that would be better
[10:00] <duflu> BarePlatform?
[10:00] <alf_> alan_g: duflu: EGLPlatform?
[10:01] <duflu> alf_: That's slightly better, but it's going to confuse people for that to be the base of "Platform"
[10:02] <duflu> I think any good solution is going to involve rethinking "Platform" which is a job for another day.
[10:02]  * duflu abstains
[10:03] <alf_> alan_g: duflu: OK, I will go with BasicPlatform
[10:14] <alan_g> alf_: the last suggested revised name for "surfaces" I can find is "core" - how do you feel about that?
[10:20] <alf_> alan_g: thinking...
[10:27] <alf_> alan_g: I am not convinced that core is a better name than surfaces (or something else), it's surely is less descriptive
[10:28] <alf_> alan_g: after all mir::surfaces is all about the creation and management of surfaces
[10:28] <alf_> alan_g: mir::scene ?
[10:40] <alan_g> alf_: maybe - although I've been trying to get away from "scenegraph" which tends to be taken too specifically
[10:40] <alan_g> alf_: mir::model?
[10:47] <alf_> alan_g: It depends on how literally we want to use "model" (in the MVC sense), since the component contains the controller too.
[10:47] <alan_g> tvoss_: I think the time is ripe to change the name of mir::surfaces. Do you have any thoughts on a good name? (Also ^^)
[10:48] <alan_g> alf_: yeah, but mir::model_controller is a bit long winded
[10:49] <alan_g> mm or mmc is easy to type though...
[11:08] <Stskeeps> g 63
[13:58] <Mirv> weird, weird, the test duflu fixed still failing in the daily-build PPA, while when I build in another PPA (granted probably slightly different PPA) it succeeded: https://launchpad.net/~ubuntu-unity/+archive/daily-build/+sourcepub/3667324/+listing-archive-extra
[13:59] <Mirv> this is the bug #1252144 still
[14:51] <kgunn> didrocks: ok...what's up ? u-s-c FTBFS ?
[14:51] <didrocks> kgunn: see what Mir posted an hour ago ^
[14:51] <didrocks> bug #1252144
[14:52] <kgunn> didrocks: sorry...got on later than that
[14:52] <didrocks> kgunn: also, it seems platform-api doesn't have the bump build-dep merged
[14:52] <didrocks> that's the 2 things now that we can slowly try to land things again :)
[14:52] <didrocks> and doing Mir in priority
[14:53] <didrocks> seems to work on virtualized ppa, but not on real hardware one
[14:53] <didrocks> (the latter beeing used for distro)
[14:53] <didrocks> (comments #4 and #5)
[14:55] <kgunn> didrocks: do we know the fundamental differences between  qt5-daily PPA vs. daily-build PPA  ??
[14:56] <didrocks> kgunn: I have this virtualized vs non virtualized in mind, but that's it
[14:57] <didrocks> kgunn: the other possibility is a timing issue, but it's weird we have consistent failures (we did several retries)
[14:57] <didrocks> and virtualized would be "faster"
[14:57] <kgunn> mlankhorst: alf_ ....any ideas, this is strange ^ almost wonder, did mesa change ??
[14:57] <mlankhorst> gah why always blame mesa
[14:57] <mlankhorst> :P
[14:58] <kgunn> didrocks: is the mir-patched xserver stuff in archive for trusty ?
[14:58] <didrocks> kgunn: well, both are built on trusty, right?
[14:58] <didrocks> so I guess that mlankhorst didn't remove the patch, right mlankhorst?
[14:58] <kgunn> mlankhorst: only because no one's touched u-s-c/xmir in a good while :)
[15:00] <robotfuel> alf_: ping
[15:00] <didrocks> kgunn: let me look for the content of the ppa
[15:00] <kgunn> this is why /me doesn't like xserver/mesa sitting outside bzr
[15:00] <robotfuel> I was testing your --offscreen branch and get this error when I try to run offscreen http://pastebin.ubuntu.com/6437847/
[15:01] <alf_> kgunn: mlankhorst: that particular test doesn't interact with any external components, its a unit test using mocks
[15:01] <alf_> it's
[15:01] <didrocks> kgunn: +1 for not liking that ;)
[15:02] <mlankhorst> didrocks: I'm tempted to do so, but no
[15:03] <kgunn> mlankhorst: sorry...i'll keep it to myself :)
[15:03] <kgunn> alf_: ok...so just a failing mock...sounds like you're familiar enough, could you take a look on the trunk ?
[15:04] <alf_> kgunn: ok
[15:04] <mlankhorst> kgunn: we haven't touched mesa in trusty much, only uploaded 9.2.2 afaik
[15:05] <kgunn> alf_: thank you...this is an item that's holding up our mir update to the archive (going on 3 weeks :)
[15:05] <kgunn> mlankhorst: sorry dude...i'll try not to be so mesa-blame-happy :)
[15:05] <alf_> robotfuel: (will get back to you in a bit)
[15:06] <kgunn> robotfuel: sorry...i swiped alf_
[15:06] <robotfuel> alf_: ack I see you have your hands full :)
[15:08] <didrocks> kgunn: no, all the same for both
[15:08] <didrocks> apart from this virtualized vs non virtualizeds
[15:12] <kgunn> didrocks: ack, we got someone looking
[15:12] <didrocks> kgunn: thanks!
[15:12] <didrocks> keep us posted
[15:12] <kgunn> didrocks: at least hope it fails on their local machine....it should since its the non-virt failing
[15:12] <didrocks> kgunn: cyphermox/robru/ken when I'm not around
[15:13] <kgunn> thank you sir
[15:13] <didrocks> kgunn: let's cross fingers (they should try building the package to have the same config: bzr bd)
[15:15] <kgunn> alf_: ^ see didrock's last statement
[15:15] <greyback> alf_: alan_g: would either of you be able to make sense of this: http://pastebin.ubuntu.com/6422376/ What I'm trying to do is use a qt application in Mir. So running mir_demo_server_shell, and then qmlscene (using the qtubuntu plugin so behaves as mir client)
[15:15] <kgunn> didrocks: one thing on the platform-api bump... https://code.launchpad.net/~kgunn72/platform-api/bump-mir-dep-0.1.1/+merge/193519
[15:15] <alan_g> greyback: looking...
[15:15] <greyback> alf_: alan_g: it would appear that mesa imports x11. Do we have patch to stop that?
[15:15] <kgunn> didrocks: it looks like it won't autoland due to mir build dep itself...(or do i not understand ?)
[15:16] <kgunn> e.g. does mir have to land first before that will actually merge ?
[15:17] <alan_g> greyback: that doesn't look familiar to me. Sorry
[15:17] <greyback> alan_g: np, thanks for looking
[15:18] <alf_> greyback: When you create an egl display from an egl native display (MirConnection etc), the patched mesa checks Mir first so it shouldn't be a problem. Is this desktop or phone?
[15:18] <greyback> alf_: desktop
[15:18] <didrocks> kgunn: yeah, for those kind of trivial change, you can force it to trunk (merge manually)
[15:18] <didrocks> kgunn: to not wait mir to land in the ppa
[15:19] <kgunn> didrocks: ack, so pull, merge, push quickly ?
[15:19] <didrocks> (well, mir is in the ppa, but failed tobuild, as we discussed)
[15:19] <didrocks> kgunn: sounds good to me
[15:19] <kgunn> ricmm: ^ just beware of what i'm about to do :)
[15:20] <alf_> greyback: can you please also install libegl1-mesa-dbg so we can get the missing functions in the trace
[15:20] <greyback> alf_: ack
[15:21] <alf_> greyback: are you able to run an example mir application?
[15:21] <greyback> alf_: yes, demo mir clients are fine
[15:21] <alf_> greyback: also use MESA_DEBUG=1 EGL_LOG_LEVEL=debug when running the qt app
[15:22] <greyback> ok
[15:27] <ricmm> kgunn: sec
[15:27]  * ricmm reads back
[15:28] <ricmm> go for it
[15:34] <kgunn> ricmm didrocks: & done...platform-api trunk now dep on 0.1.1 mir
[15:34] <didrocks> kgunn: thanks!
[15:34] <didrocks> "just" the FTBFS now ;)
[15:34] <didrocks> and then we can build/test/deliver Mir
[15:36] <greyback> alf_: http://pastebin.ubuntu.com/6437996/ <- egl seems to decide x11, not mir.
[15:38] <greyback> how does it decide? is there an env var maybe that could force it?
[15:38] <greyback> FYI  I am running X11 on VT7. Am trying to run mir on VT1.
[15:39] <alf_> greyback: on the same machine?
[15:39] <greyback> alf_: yes
[15:40] <kgunn> greyback: just curious...can you run a mir demo client per the instructions http://unity.ubuntu.com/mir/using_mir_on_pc.html
[15:40] <kgunn> under "runing mir natively"
[15:40] <kgunn> ...sorry if this is deja vu
[15:40] <greyback> kgunn: that's exactly what I'm doing. Demo mir clients work fine
[15:41] <alf_> greyback: just to be clear, you mean the mir server is running on VT1 but you want to start an app from VT7 under X11?
[15:41] <greyback> alf_: nope. I'm starting app from VT2
[15:41] <greyback> for running under mir
[15:42] <alf_> greyback: ok, FWIW, running it from VT7/X11 should work too
[15:42] <greyback> alf_: yes that makes sense :)
[15:42]  * greyback stops using VT2
[15:43] <alf_> greyback: are you using qtubuntu trunk or some other branch (I want to take a look at the code there)
[15:43] <kgunn> alf_: please...can you do that after the drm_auth_magic test failure
[15:44] <alf_> kgunn: I am doing it in parallel, the package is building (which is slow)
[15:44] <kgunn> :) thanks
[15:45] <greyback> alf_: heh, this is where things get annoying. I'm using Qt5.2, and made a branch of qtubuntu to support it, and also hack around depending on hybris: alf_: I made a branch so it wouldn't depend on hybris. lp:~gerboland/qtubuntu/qt5.2-on-desktop/
[15:46] <greyback> alf_: but please you try using standard qtubuntu, just to test please
[15:46] <alf_> greyback: as a first step I want to take a look at the code
[15:47] <greyback> alf_: sure
[15:48] <greyback> alf_: src/platforms/base/context.cc will be of interest to you
[15:51] <racarr> Happy monday!
[16:17] <alf_> kgunn: I can't recreate the problem building the package locally :/
[16:31] <kgunn> alf_: thanks...hmmm.... didrocks thots to proceed ?
[16:33] <didrocks> kgunn: did you ask on #webops?
[16:41] <kgunn> didrocks: so sorry...was otp...why webops ?
[16:41] <didrocks> kgunn: they will be able to help to debug why the test segfault on devirtualized ppas (meaning, distro builders)
[16:41] <didrocks> even getting you chroot access I guess
[16:52] <kgunn> racarr: mornin'
[16:53] <racarr> Morning kgunn!
[16:53] <racarr> alan_g: My branch actually does conflict with yours a little...I want to just straight up remove the session container
[16:53] <racarr> maybe we can talk about it tomorrow?
[16:54] <alan_g> racarr: I've no problem with it being removed
[16:55] <racarr> alan_g: The thing is we only use it internally for the system compositor focus tracking (i.e. finding hwich session to give focus to when another closes)
[16:55] <racarr> so rather than make it a customizable component, I am just going to fold it in to
[16:55] <racarr> msh::DefaultShell
[16:55] <racarr> which is the new SessionManager
[16:56] <racarr>  / implementor of mf::Shell
[16:57] <alan_g> Hmm. But the "Controller" part of SessionManager belongs in surfaces
[16:57] <alan_g> As does the "Model" part
[16:57] <racarr> hmmmaybe, I mean it wont be the same manager, I am changing
[16:58] <racarr> the mf::Shell interface as well
[16:58] <alan_g> So, I'm not convinced by "msh::DefaultShell"
[16:58] <racarr> to basically mirror the mf::SessionMediator interface
[16:58] <racarr> except in terms of Mir server types instead of IPC types
[16:58] <racarr> to the DefaultShell, takes the fully interpreted IPC requests, and decides which controller components to use
[16:58] <racarr> to update the model
[16:59] <racarr> s/to the DefaultShell/so the mf::Shell/
[17:00] <alan_g> I guess I should look at what you're doing. (But my head is full ATM)
[17:00] <racarr> I will propose it todayhopefully
[17:03] <alan_g> OK will look in morning
[17:17] <kgunn> robotfuel: since some services are back to working....have you had a chance to test out the demo clients as part of ci ?
[17:19] <robotfuel> kgunn: I am working on that now
[17:27] <alf_> robotfuel: please check latest lp:~afrantzis/mir/offscreen-display
[17:27] <robotfuel> alf_: will do thanks
[17:32] <kdub> android clients? :)
[17:50] <robotfuel> kgunn: I am still waiting for this a MP to land before we can add demos to CI, I've talk to the phablet team and it's on their list to review today, they have a bunch of reviews to do. https://code.launchpad.net/~chris.gagnon/phablet-tools/run-test-without-autopilot/+merge/194920
[18:07] <robotfuel> racarr: https://code.launchpad.net/~robertcarr/mir/cbranch-can-not-be-named-fix-1247718/+merge/195629 has problems I got this failure:  /tmp/buildd/mir-0.1.1/tests/unit-tests/input/android/test_android_input_manager.cpp:158:83: error: template argument 1 is invalid
[18:27] <greyback> alf_: just FYI, I did a little digging, found if I set EGL_PLATFORM=mir, then I get further. Failure now with EGL_BAD_CONTEXT...
[18:27] <robotfuel> alf_: your new offscreen branch crashes my X session, but otherwise seems to work.
[18:29] <alf_> robotfuel: it's not ready to be run under X11 yet, you still need to be in a VT
[18:30] <robotfuel> alf_: I am running it in a vt with sudo mir_demo_server_basic --offscreen --vt 3, yet it still crashes my X session
[18:32] <alf_> robotfuel: ok
[18:33] <alf_> greyback: if you don't solve this today, please send me an email with quick instructions so that I can try tomorrow morning
[18:34] <greyback> alf_: ok
[18:50] <alf_> robotfuel: btw, you can't switch back to X while the offscreen server is running yet (I guess that's what you meant by killing the X session)
[18:51] <robotfuel> alf_: ah ok, maybe that is the issue? I've added the crash part of the X log to the MP
[18:52] <robotfuel> alf_: X restarts in fallback mode on tty8 after running --offscreen
[18:52] <alf_> robotfuel: only when switching to X while offscreen is running, though, right?
[18:53] <robotfuel> alf_: I did try to switch back to tty7 I'll retry
[18:55] <robotfuel> alf_: yeah If I don't switch back X does not crash.
[18:56] <alf_> robotfuel: ok, thanks
[18:57] <robotfuel> alf_: I also updated the comment in the MP.
[19:03] <bschaefer> racarr, ping
[19:10] <racarr> bschaefer: pongalong
[19:11] <bschaefer> racarr, hello! So, i was digging around in the motion event, and it doesnt seem to expose the type of device being used
[19:11] <bschaefer> ie: http://paste.ubuntu.com/6438929/
[19:11] <bschaefer> with out exposing the ToolType, you don't know if it the event is a mouse/finger/etc..
[19:11] <racarr> bschaefer: Seems correct
[19:12] <bschaefer> racarr, i can test it out some more, but was just wondering if you knew of any other way :)
[19:12] <bschaefer> without having to use an unused var
[19:16] <racarr> No. sorry.
[19:17] <bschaefer> racarr, alright, well i can make a bug, and get some tests then I can get an MP up
[19:17] <bschaefer> thanks!
[19:17] <racarr> Thankyou !
[21:36]  * kdub forgot to restart xchat after x locked up
[21:50] <racarr> timefor awalk
[21:50] <racarr> at thatpoint in refactoring where its like
[21:50] <racarr> ahahgashgahsga
[21:50] <racarr> also its really time for a new space key
[22:06] <kdub> racarr, c++ doesn't need the space key :P
[22:07] <kdub> just tabs