[00:23] <RAOF> H
[00:23] <RAOF> Dear armhf: really?
[03:38] <duflu> Hmm, did some pipe specific to Canonical just go down?
[03:43] <RAOF> Dunno. What are you trying to resolve?
[03:44] <duflu> RAOF: Canonical mail, Launchpad and IRC all went quiet for a while.
[03:44] <duflu> Now they're back
[06:31] <RAOF> duflu: Is there any particular reason not to _catch_ the exceptions in the compositing thread?
[06:32] <duflu> RAOF: Because we don't know how to recover from them, and the act of catching trashes the stack trace
[06:32] <duflu> Is there another solution?
[06:37] <RAOF> Hm. I think we actually _do_ know how to recover from them; try again next frame.
[06:37] <RAOF> That'll work for some of the errors.
[06:37] <RAOF> Well, some classes of failure.
[06:38] <duflu> RAOF: Recovery would be excellent if it was reliable. If there's a risk of looping then it's safer to get a nice bug report.
[06:38] <RAOF> We'd need to try for 5 or so frames, then bail.
[06:38] <duflu> But still, I'd prefer to debate the recoverability of each scenario separately
[06:39] <RAOF> Yeah. That'd require us to have an actual exception hierarchy. And to proxy said things to the main thread, I think.
[06:39] <RAOF> Which is indeed a post-RTM thing.
[06:39] <duflu> RAOF: Yes, actual exceptions with actual catching
[06:40] <duflu> Although if the recovery is near the ioctls then maybe not even exceptions are required
[06:42] <RAOF> How useful were the cores generated when these exceptions _were_ generating cores?
[06:43] <RAOF> Because looking through the code it looks like a lot of the error state has dropped out of the stack before the exception is thrown.
[06:45] <duflu> RAOF: Very, for a brief while between the first fix and when it regressed.
[06:45] <duflu> Unfortunately the first fix occurred after the first flood of bug reports
[06:45]  * RAOF is quite surprised
[06:45] <anpok> we could assemble additional error information with boost exception while unwinding
[06:45]  * duflu offers anpok the wear jar
[06:45] <duflu> *swear jar
[06:46] <RAOF> anpok: You know what we should do? Rather than use enable_error_info on std::runtime_errors, we should just throw std::system_errors.
[06:46] <duflu> Throwing anything you don't know how to catch and recover from is the problem
[06:47] <RAOF> duflu: Not really, because we're a library.
[06:47] <anpok> RAOF: well .. if there is relevant information in the stack itself
[06:47] <RAOF> But throwing something we don't handle in a thread of our creation is indeed a problem.
[06:47] <anpok> but yes system_error looks more like the right type
[06:47]  * RAOF queues up a “replace everything with system_error” branch.
[06:49] <duflu> RAOF: Unless it includes full catching and recovery it's a step backwards... we really need to deal with each throw separately
[06:49] <duflu> It's a long path
[06:57] <RAOF> It's not a step backwards. At worse it's a step sideways. It gets us a better exception message if nothing else.
[06:57] <RAOF> It's also just the sort of mechanical transformation that I feel I'm about capable of doing at the moment :/
[06:58] <duflu> RAOF: I know how that feels. However using any exceptions without full recover implemented will fail to solve the bug
[06:59] <duflu> recovery even
[06:59] <RAOF> That is correct.
[06:59] <duflu> RAOF: OK then, no problem. Please don't create conflicts for me though :)
[07:10] <duflu> Oh Compiz/Unity7 I won't miss you... just as soon as we have the replacement ready
[07:11]  * duflu has the tiny phantom window problem. They sporadically appear and disappear
[07:24] <duflu> camako: Still showing 0.1.9 is the latest download. Don't forget https://launchpad.net/mir   Development focus = 0.5
[07:26] <camako> duflu... Weird... I coulda sworn I saw 0.4.0...  lemme check again
[07:26] <duflu> camako: Should be Development focus = 0.5, but is presently utopic (which is obsolete)
[07:27] <duflu> You have to configure the Mir project page
[07:30] <duflu> Sorry I can't give more details. I don't administer any projects any more. I can't see a project details page to cite for an example
[07:36] <duflu> camako: You should have a "Change project details" option (or similar) on https://launchpad.net/mir
[07:36] <duflu> ... which I don't
[07:38] <duflu> Oh and the trusty (and earlier) series possibly should still be visible.  Because it's theoretically possible for them to get fixes backported, although highly unlikely
[07:39] <camako> duflu still looking
[07:41] <duflu> camako: https://answers.launchpad.net/launchpad/+question/82049
[07:43] <camako> duflu .. "change details" doesn't exist for me
[07:43] <duflu> camako: Oh. You aren't a project admin either
[07:43] <duflu> I wonder who it
[07:43] <duflu> is
[07:44] <camako> duflu... guess not
[07:44] <camako> Thomas?
[07:45] <duflu> didrocks, sil2100, Saviq: Can anyone add camako to pspmteam?
[07:47] <duflu> Or Mirv? ^
[07:48] <duflu> The Mir Tech Lead has no permissions to administer the Mir project :)
[07:49] <camako> duflu.. I was able to change status for 0.3, 0.4 as I was the "release manager" on lp...
[07:49] <camako> for 0.5, you are the release manager since you created it
[07:49] <duflu> camako: Yeah I can do that too on the series I created. But you need top-level access to admin the Mir project. That's owned by https://launchpad.net/~pspmteam
[07:50] <camako> right
[07:50] <duflu> camako: popey is also an admin. Ask him when he comes online
[07:51] <camako> duflu... ok
[07:51] <duflu> It's really annoying then the button you need is hidden
[07:52] <ogra_> duflu, camako looks like dbarth or popey can add people there
[07:52] <duflu> Yep. And David's not online yet either
[07:52] <camako> ogra_.. ok thanks
[08:00] <duflu> alf_: You around?
[08:00] <alf_> duflu: yes
[08:01] <duflu> alf_: Are you familiar with any changes that happened in June around buffer ownership? Looks like the new behaviour is that a client can own _all_ the buffers until/unless a compositor needs one.
[08:01] <duflu> Sounds like a bug but may be a feature
[08:02] <alf_> duflu: I don't remember of an explicit change, but it sounds like something that may have changed by Alberto's work on the BufferQueue?
[08:04] <duflu> alf_: It seems to work but in theory shouldn't. If a client is allowed to have all the buffers on startup then compositors get what?
[08:04] <duflu> I guess I'll keep trying to write more tests till I can prove something is amiss
[08:06] <RAOF> Soooooo.
[08:06] <alf_> duflu: Perhaps it works currently because the clients get one buffer at a time?
[08:06] <RAOF> Why does armhf seem to receive fewer fds than sent?
[08:07] <duflu> RAOF: sizeof() silliness?
[08:07] <RAOF> Hm.
[08:07] <duflu> But AFAIK sizeof all the important bits is the same as desktop
[08:07] <RAOF> I shall come back to this later.
[08:08] <RAOF> But I *send* 2 fds, and cmsg->cmsg_len on the receiving end is 16.
[08:08] <RAOF> Which is *not* CMSG_LEN(2 * sizeof(int))
[08:08] <RAOF> Anyway, later.
[08:08] <duflu> RAOF: Oh. I don't understand the cmsg stuff but remember everyone was suspicious of recent changes to it
[08:56] <popey> someone ping me?
[08:56] <ogra_> camako, duflu ^^^^
[08:56] <seb128> popey, hey
[08:56] <duflu> popey: Yeah can you add camako to pspmteam?
[08:56] <camako> ogra_.. thanks
[08:57] <ogra_> ;)
[08:57] <duflu> We presently have no one able to administer the Mir project :)
[08:57]  * popey looks
[08:57] <popey> "lol"
[08:57] <camako> I think kgunn is part of the pspm team
[08:58] <camako> but yea.. I should be as well
[08:58] <popey> done
[08:58] <duflu> popey: Ta
[08:58] <camako> popey thanks
[08:59] <camako> duflu... done... looks good now?
[09:00] <duflu> camako: Ah cool yes
[09:00] <popey> np
[09:01] <duflu> camako: For cleanliness we could rename "trusty" to "0.1" and "saucy" to "0.0"
[09:01] <duflu> I think that's possible
[09:02] <camako> duflu... sure
[09:03] <camako> duflu.. done! Looks all neat :-)
[09:04] <duflu> camako: Cool again. Also looks better here now: https://launchpad.net/ubuntu/+source/mir
[09:04] <camako> yep
[09:05] <duflu> camako: I think we need a new plan to reduce branching. Somehow we need to avoid branching until after the server ABI has changed
[09:06] <camako> duflu.. yea I agree
[09:06] <duflu> Perhaps explicitly targeting lp:mir/0.N (where N is "next") would work
[09:07] <duflu> then we don't need to call anything "devel"
[09:07] <duflu> but that increases the risk of proposals targeting the wrong one
[09:08] <duflu> Whatever the approach it should be possible to release 0.5.1, 0.5.2 ... before ever needing to branch a 0.6 for example
[09:08] <camako> yea currently it's a presumptive approach
[09:17] <alan_g> duflu: instead of changing targets can we just rename devel and create a new one each release
[09:18] <duflu> alan_g: You mean use "devel" as a series? I think that would look confusing in Bugs that are targeted
[09:18] <duflu> Better to have a number
[09:19] <duflu> Or just keep the development branch as it is and tag 0.5.x on devel _until_ an ABI break happens
[09:19] <duflu> Then branch
[09:20] <duflu> But that requires a "freeze" period for each point release. Same old problem
[09:47] <alan_g> duflu: got time to review this before you go? https://code.launchpad.net/~alan-griffiths/mir/fix-1300653/+merge/225692
[09:47] <duflu> alan_g: Maybe :) Hang on
[09:53] <alan_g> duflu: thanks
[09:54] <duflu> np
[12:54] <kdub_> hey all
[13:01] <mzanetti> anpok: hey, I'd need some help with touch input events.
[13:01] <mzanetti> would you have a bit of time for that?
[14:58] <alf_> mterry: Hi! I am working on refactoring USC. Do we have a document (or even better tests) describing the expected behavior for session switching and spinner display when we get DM events?
[14:59] <mterry> alf_, no, but I could try to put together a quick explanation
[14:59] <anpok> mzanetti: meeting is in a minutes
[14:59] <anpok> -s
[14:59] <anpok> right after that
[15:00] <alf_> mterry: That would be useful, thanks. Based on that I can write some tests you can then review for expected behavior.
[15:03] <alf_> mterry: could you please also briefly describe in the explanation what exactly "next" and "active" mean for the DM
[15:03] <mterry> alf_, yup
[15:03] <mterry> writing that now in fact  :)
[15:04] <alf_> mterry: thank you :)
[15:24] <mterry> alf_, sent email.  Let me know if you have questions
[15:24] <alf_> mterry: great, thanks
[15:41] <alf_> camako: Sorry, hangouts crashed computer
[16:21] <greyback> alf_: hey just to tell you, the issues I was having on Friday last week (the GL/GLES conflict) I resolved. I needed to call eglBindAPI before mir created a context. However I had made a typo: EGL_OPENGL_BIT instead of EGL_OPENGL_API
[16:21] <greyback> so no need for an immediate mir change
[16:22] <alf_> greyback: Interesting that this works, since Mir sets eglBindAPI() to ES2 when creating a context
[16:23] <alf_> greyback: this for the desktop, IIRC?
[16:23] <greyback> alf_: really? Heh, then I'm confused :) Yes desktop
[16:41] <alan_g> dednick: had a look at this yet? https://code.launchpad.net/~alan-griffiths/mir/spike-trusted-helper-socket/+merge/225677
[16:41] <dednick> alan_g: eh. no, i haven't had a chance yet.
[16:41] <dednick> alan_g: sorry. i will try to get it in tomorrow morning. Just busy trying to get somethings to land
[16:43] <alan_g> dednick: np. (Until kgunn asks why it didn't land.) ;)
[18:07] <PreSSion> so, for example, a game for example metro,... will be compatible in ubuntu mir?
[18:08] <PreSSion> i think no
[18:08] <kdub_> PreSSion, not enough info.... mir can run games
[18:09] <PreSSion> yes, i know, but i want buy metro for linux
[18:09] <PreSSion> but idk because i don't know if in the future i will can play in ubuntu with mir
[18:10] <PreSSion> sorry for my "engrish"
[18:10] <PreSSion> so, I  want to buy a game, its ok, i know now i can play in ubuntu
[18:11] <PreSSion> but i don't know if in the future i will can play in the future ubuntu versions with mir
[18:11] <kdub_> we should have backwards compatibility with xmir
[18:12] <PreSSion> oh nice, so i will play for example metro in ubuntu phone
[18:12] <PreSSion> posible right=
[18:13] <PreSSion> i mean when i put the dock station with the monitor
[18:14] <racarr> well most phones are arm not x86
[18:14] <racarr> so no binary compatibility
[18:15] <PreSSion> yes, but ubuntu said his phone will have full convergence
[18:15] <PreSSion> so, ubuntu will sell some phone with x86 processor?
[18:21] <PreSSion> nice, i see one of the ubuntu phone have got an intel atom processor, so that phone will be full convergence and play games as metro right?
[18:21] <PreSSion> with xmir ofc
[18:37] <racarr> allllmost done with my foray in to surface attributes
[18:38] <racarr> I instantiated 4 common tests over all of them 1.Default value. 2. Notifies observer on change 3.Doesntnotify observer on default change
[18:38]  * greyback raises an eyebrow
[18:38] <racarr> err on no change
[18:38] <racarr> 4. Throws on invalid value
[18:39] <racarr> and only about half pass...
[18:39] <racarr> and then DPI uses invalid value to mean "Query"
[18:40] <racarr> greyback: ?
[18:41] <greyback> racarr: just curious
[18:41] <greyback> racarr: thought you were adding more surface attributes or something
[18:42] <racarr> haha not yet
[18:43] <greyback> racarr: would be nice if we could have a protobuf style way of defining properties on surfaces, just a text file which defines type and range could do a lot
[18:44]  * greyback wakes from dream world and goes back to work
[18:44] <racarr> haha
[18:44] <racarr> im not sure about that far
[18:44] <racarr> but ultimately I would like the attribute system to be more generic...
[18:44] <racarr> i.e. cursor setting should be an attribute...
[18:44] <racarr> its not clear that size isnt an attribute
[18:44] <racarr> etc
[18:45] <greyback> it was one reason I wanted the custom protobuf stuff, so we could rapidly iterate on surface attributes. Sadly that wasn't possible with protobuf
[18:49]  * kdub_ sorta likes that idea
[18:49] <kdub_>  s/sorta//
[18:55] <racarr> :)
[18:55] <racarr> all im doingh now...is ensuring consistent semantics on all of them
[18:55] <racarr> and also making them
[18:55] <racarr> sent on surface creation
[18:55] <racarr> so that the client can always query them with a non blocking getter
[18:55] <racarr> currently we are missing getters for 2
[18:55] <racarr> and one has a blocking getter
[18:55] <racarr> (dpi)
[19:00] <kdub_> i've been thinking that some sort of generic/extensible compositor data system would be a win too
[19:01] <racarr> mm
[19:02] <kdub_> like...
[19:02] <kdub_> visibility
[19:05] <kdub_> or animation... the compositor should be able to tag the surfaces with data
[19:05] <kdub_> and the data can be generic to libmirserver
[19:05] <kdub_> and every individual compositor keeps the concept of what data they're tagging with
[19:05]  * kdub_ ends musing
[19:27] <racarr> Lunnch
[22:04] <greyback> hey guys, anyone run xmir with nouveau recently? I'm just seeing a black screen for USC
[22:06] <greyback> bregma: hey, I'm having trouble testing unity8-mir on my desktop (well having trouble with USC) - could I ask you to do a quick test of ppa:unity-team/phone-right-edge to see if unity8-mir comes up or not?
[22:18] <greyback> ok so working with mterry a bit, he think it's more XMir issue than USC.
[22:18] <greyback> let me recap:
[22:19] <greyback> I have  ubuntu-desktop-mir  & USC installed
[22:20] <greyback> When I startup, after plymouth, I just get a black screen
[22:20] <greyback> I see that USC is running though. Also appears to be an X server running
[22:22] <greyback> here's useful log-files http://pastebin.ubuntu.com/7762355/
[22:22] <greyback> mterry sees from the USC log file that USC never sees a client session - i.e. the xmir greeter session
[22:23] <greyback> running mir 0.4.0
[22:33] <racarr> greyback: no ideas on my end sorry...
[22:33] <racarr> you can start xmir with Xorg :1 -mi r <ANYTHING>
[22:34] <racarr>  -mir
[22:34] <racarr> and make sure it doesnt segfault
[22:34] <racarr> even Xorg :1 -mir 0 -retro
[22:34] <racarr> to get the crosshatch so there will be something
[22:34] <racarr> on screen lol
[22:34] <bschaefer> racarr, you don't need -mirSocket?
[22:34] <racarr> oh
[22:34] <racarr> maybe
[22:34] <racarr> I think you can use
[22:34] <racarr> MIR_SOCKET
[22:34] <racarr> env
[22:34] <bschaefer> oo right yeah you can
[22:50] <greyback> racarr: thanks for suggestion, doing that leaves me with a hanging process http://pastebin.ubuntu.com/7762468/
[22:51] <bschaefer> greyback, i was running into that earlier attempt to do xmir ... let me try on a mir server
[22:52] <greyback> bschaefer: thanks :)
[22:52] <bschaefer> np!
[22:53] <bschaefer> greyback, X seems to start up for me
[22:53] <bschaefer> greyback, this is just a mir_demo_server though, + xmir
[22:54] <greyback> bschaefer: ok, I'll try that,  just to see
[22:54] <bschaefer> wouldn't hurt to try that out
[22:56] <greyback> huh, I get a "Connection refused" error.
[22:56] <greyback> but I can run a mir demo client ok
[22:56] <bschaefer> greyback, chmod 777 /tmp/mir_socket?
[22:56] <bschaefer> o
[22:56] <bschaefer> hmm
[22:56] <bschaefer> greyback, is it trying forever to attempt to connect to the xserver?
[22:56] <greyback> bschaefer: nope
[22:56] <greyback> bschaefer: nope, it terminates
[22:57] <bschaefer> greyback, whats your MIR_SOCKET?
[22:57] <bschaefer> err well a demo works...
[22:57] <greyback> http://pastebin.ubuntu.com/7762489/
[22:57] <bschaefer> why does a demo work...
[22:57] <greyback>  /run/mir_socket
[22:57] <greyback> oh oh oh
[22:57] <bschaefer> greyback, mir_demo_server_* puts the socket in /run for you?
[22:58] <greyback>  /tmp/mir_socket
[22:58] <bschaefer> yeah
[22:58] <bschaefer> that'll be the issue :)
[22:58] <greyback> Loading extension GLX
[22:58] <greyback> Driver needs flags 0, incompatible with nested, deleting.
[22:58] <greyback> Driver needs flags 0, incompatible with nested, deleting.
[22:58] <greyback> Driver needs flags 1, incompatible with nested, deleting.
[22:58] <bschaefer> thats normal, at lease i hit those
[22:58] <greyback> ok
[22:58] <bschaefer> then the background loads, and you get a nice x cursor
[23:01] <greyback> bschaefer: kinda, I just saw the screen flash black/grey/black/grey/black and I'm back to a black screen
[23:02] <bschaefer> greyback, o, that doesn't sound good. I get the flashing for a second, then it loads
[23:02] <bschaefer> maybe the xorg log offers some info?
[23:05] <greyback> bschaefer: nothing I can see as obvious anyway: http://pastebin.ubuntu.com/7762506/
[23:05] <bschaefer> greyback, im also using intel
[23:05] <bschaefer> which could explain some things...
[23:05] <greyback> bschaefer: indeed
[23:05] <greyback> but this did used to work
[23:06] <greyback> well it's late here, think I'll give up for the night,
[23:06] <bschaefer> interesting...
[23:07] <greyback> bschaefer: thanks for the help so far
[23:07] <bschaefer> greyback, its only mid afternoon here :)
[23:07] <bschaefer> greyback, hopefully you can figure out some more info! Have a good night!
[23:07] <greyback> bschaefer: ah you folk in your sunny climes
[23:07] <bschaefer> haha
[23:07] <greyback> o/
[23:48] <racarr> RAOF: Ping?
[23:48] <RAOF> racarr: Pong!
[23:48] <racarr> RAOF: The import of xcursor.c has lead to mass abstention
[23:48] <racarr> on cursor spike phase 6
[23:48] <racarr> can you weigh in?
[23:49] <racarr> I mean not urgently or anything just at some point
[23:51] <RAOF> racarr: Sure, queued up.
[23:51] <racarr> thanks