[06:15] <duflu> didrocks: I've updated lp:mir and it is now at tagged release 0.1.0, awaiting packaging (and changelog entries)
[06:20] <didrocks> duflu: ok, we'll probably ship it today
[06:20] <duflu> I'd be interested to see how well the automagical changelog population works, given we usually forget "--fixes lp:NNNN"
[06:31] <didrocks> duflu: did you add bug #<foo> in the commit message?
[06:31] <didrocks> or bug blalabla
[06:31] <didrocks> or any regexp with either lp.* or bug.* ?
[06:31] <didrocks> (attaching the bug to the MP before it's merged works as well)
[06:31] <duflu> didrocks: I do. And where other people forget I often fix their commit messages. But I don't catch all of them
[06:31] <didrocks> duflu: for those then, it should be fine
[07:08] <alf_> duflu: didrocks: Have the trusty repositories opened? Is it recommendend that we move to it now?
[07:08] <didrocks> alf_: indeed, they are opened since Monday (see ubuntu-devel ML)
[07:09] <didrocks> alf_: since are still settling down, you should wait for a week to keep being productive I would say
[07:09] <didrocks> (after the first debian sync pass is done)
[07:09] <alf_> didrocks: sounds sensible, thanks :)
[07:10] <didrocks> yw!
[08:19] <Saviq> duflu, https://bugs.launchpad.net/unity8/+bug/1239876/comments/5 ?
[08:20] <duflu> Saviq: The bug status is accurate if you look up the top. Fix Released in 0.1.0 and later
[08:21] <Saviq> duflu, since when "Fix released" == "Is going to be released"?
[08:21] <Saviq> duflu, I thought "Fix committed" + milestion == "Is going to be released with version x"
[08:21] <duflu> Saviq: It's fix released in the upstream project release 0.1.0 and correctly says Fix Committed for Ubuntu
[08:22] <duflu> Saviq: The first Ubuntu build of 0.1.0 is coming today I think
[08:22] <Saviq> duflu, ah, didn't know you guys got upstream releases other than ubuntu...
[08:22] <duflu> Saviq: Yeah they're separate branches so need separate status to be accurate
[08:23] <Saviq> duflu, ok, sorry for the noise
[08:23] <duflu> Saviq: No problem. You can expect (hopefully) accurate status info from now on. At least better than in the past
[08:24] <Saviq> duflu, I'm still struggling with the need to keep statuses for unity8 and ubuntu/unity8, as they're synonymous for us at least
[08:25] <duflu> Saviq: If you have only one branch it makes sense. But Mir is stuck with two "trunks", which is what distro wants
[08:26] <didrocks> distro doesn't wants 2 trunks, distro just want one trunk with good packaging syncing practice
[08:26] <didrocks> and stability in the interface
[08:26] <didrocks> (quite a big difference, we don't impose the how, just the end)
[08:30] <duflu> didrocks: +1
[08:37] <duflu> In many ways, the Ubuntu need/want for daily builds and ABI stability of bleeding-edge code are conflicting requirements. So I think we have a good compromise of throttling the bleeding-edge changes into Ubuntu, even if it's not quite daily
[09:10] <Mirv> unity-system-compositor seem to fail to build: https://launchpadlibrarian.net/154869368/buildlog_ubuntu-trusty-amd64.unity-system-compositor_0.0.1%2B14.04.20131024-0ubuntu1_FAILEDTOBUILD.txt.gz
[09:10] <Mirv> it seems it's probably not updated for the new libmirserver?
[09:11] <Mirv> "mir/pause_resume_listener.h: No such file or directory"
[09:12] <Mirv> so I guess mterry's branch, could you get that merged?
[09:12] <Mirv> https://code.launchpad.net/~mterry/unity-system-compositor/mir-fixes
[09:12] <Mirv> bug #1244131
[09:13] <alan_g> greyback: I figured out what I was missing yesterday. https://code.launchpad.net/~alan-griffiths/unity-mir/reduce-coupling-to-mir-surfaces/+merge/192471
[09:16] <greyback> alan_g: glad to hear.
[09:16] <alan_g> greyback: although I still get some linker errors - but I'll worry about that another time
[09:18] <alan_g> greyback: It would be really nice for my code cleanup in Mir  to remove that dependency in unity-mir
[09:19] <greyback> alan_g: sure, I'm trying it out now
[09:20] <greyback> alan_g: I'm just thinking of ramifications of having SurfaceStackModel a Mir internal concept
[09:23] <alan_g> greyback: The thing is that we should have the controller mediating all updates (to allow synchronization) and any interfaces used by views onto the data should be defined where they are used.
[09:44] <Mirv> we can't release the mir stack without u-s-c, so if you can please check the bug above
[11:48] <Mirv> so... now u-s-c would compile against libmirserver8, only that now the PPA has libmirserver9 and again u-s-c doesn't build :S
[11:54] <Mirv> bug #1244192 - I assigned it to mterry already
[11:54] <Mirv> 'mir::DefaultConfigurationOptions' is not an accessible base of 'const SystemCompositorServerConfiguration'
[12:27] <alf_> alan_g: updated lient-drm-add-gbm-device
[12:27] <alf_> +c
[12:49] <alan_g> alf_: looking...
[12:52] <alan_g> alf_: Now we re-implement std::ceil()?!
[12:53] <alf_> alan_g: it's division with ceiling without involving floating points, not the same thing :)
[12:58] <didrocks> alf_: alan_g: can you look at Mirv's messages? we are totally blocking the whole line because of Mir
[12:59] <alan_g> didrocks: ok - let me grab usc
[12:59] <didrocks> thanks!
[12:59] <didrocks> on the client one? is it xorg still compatible? just needing a rebuild?
[13:01] <alf_> didrocks: are you referring to xmir?
[13:02] <didrocks> right
[13:02] <didrocks> as the client bump wasn't coordinated, we are going to revert mir landing (as well as platform-api, and unity-mir)
[13:02] <alf_> didrocks: yes, xmir shouldn't be affected by any of the changes done lately
[13:03] <didrocks> alf_: so a rebuild for the soname bump?
[13:03] <alf_> didrocks: it should be enough
[13:14] <alan_g> Mirv: didrocks https://code.launchpad.net/~alan-griffiths/mir/fix-1244192/+merge/192503
[13:15] <didrocks> alan_g: great! thanks for fixing, I think alf_ can maybe review and test build u-s-c with it?
[13:15] <alf_> didrocks: will do
[13:17]  * alan_g wonders if we should roll usc into the mir source tree
[13:23] <alf_> alan_g: we should at least build usc, unity-mir etc during CI in warning mode to get some notification if we break anything
[13:24] <alan_g> alf_: it's half a dozen files - almost an example program. ;)
[14:03] <mterry> alf_, alan_g: good morning (for me)!  Do either of you have some more time to help me today?  I spent some time tracing the fd passed to unity8, and it seems to be a workable fd.  rw and all that.  But when we call MirConnection::connect, down in the protobuf layer, connect_result never gets cleared, and so we error out later.  I'm not super clear on how the autogenerated protobuf code works
[14:04] <alf_> mterry: sure, what's the quickest way to reproduce what you are seeing?
[14:05] <mterry> alf_, that's actually not even a little easy right now.  Do you have time?
[14:05] <alf_> mterry: yes
[14:05]  * mterry hugs alf_
[14:05] <mterry> alf_, ok, let me get my notes
[14:06] <mterry> alf_, so I've been working on the phone itself.  If you have a suitable emulation environment or something, that could work too
[14:06] <alf_> mterry: ok
[14:07] <mterry> alf_, you'll want lp:~mterry/mir/named-session
[14:07] <mterry> alf_, lp:~mterry/lightdm/named-sessions with lp:~robert-ancell/lightdm/private-mir-connection mixed in
[14:07] <mterry> alf_, and lp:~robert-ancell/unity-system-compositor/private-mir-connection
[14:07] <mterry> alf_, ooh, you know
[14:08] <mterry> alf_, let's try skipping the named-session branches for now.  I'll set you up with a simpler environment that I think will still reproduce
[14:08] <mterry> alf_, my env is deep in the weeds, but I suspect we don't need everything
[14:08] <mterry> alf_, so we'll just use robert-ancell's two branches (lightdm and unity-system-compositor)
[14:12] <alf_> mterry: I wonder if for a start you could send me your built versions of lightdm and unity-system-compositor, so I can just build/debug mir. If we think the problem also involves lightdm/usc I can build those later.
[14:12] <mterry> alf_, fair enough...  Let me put something up on people.canonical.com
[14:12] <alf_> mterry: (btw, I am using N4)
[14:13] <mterry> alf_, ok, cool, me too
[14:14] <alf_> mterry: also, are you using mir development or the package version?
[14:14] <mterry> alf_, trunk
[14:15] <mterry> alf_, I think?  I can't remember when I branched
[14:16] <mterry> alf_, I branched a week ago?
[14:16] <alf_> mterry: do you have the revision to ensure we are in sync?
[14:18] <mterry> alf_, 1102
[14:18] <alf_> mterry: great, thanks
[14:18] <mterry> alf_, but...  if I'm giving you my lightdm deb file, you'll probably want my named-session mir branch
[14:18] <mterry> alf_, because lightdm passes a new mir argument
[14:20] <alf_> mterry: ok
[14:22] <mterry> alf_, OK, try the debs in http://people.canonical.com/~mterry/
[14:23] <mterry> alf_, plus your built named-sessions mir branch
[14:42] <alf_> mterry: ok I think I am set up
[14:44] <mterry> alf_, OK.  So if you hit what I'm hitting, you should be able to reboot and look at /home/phablet/.cache/upstart/unity8.log to see the abort
[14:47] <alf_> mterry: is there a way to run this manually?
[14:47] <alf_> mterry: (i.e., without restarting so I can debug it live if needed?)
[14:48] <mterry> alf_, it's tough, because to reproduce what lightdm is doing, we need it to launch the session.  I've been debugging via prints and such, but I'm rebuilding myself with debugging symbols and plan to insert a sleep or something so I can attach
[14:49] <alf_> mterry: I guess 'start lightdm' would have the same effect right? At least to avoid the restart.
[14:50] <mterry> alf_, yes.....  except I have run into issues in the past with Mir handling that gracefully
[14:50] <mterry> alf_, so I've gotten into the habit of rebooting
[14:51] <mterry> Or, maybe not Mir's fault, but something between powerd/unity8/Mir.  Those annoying errors with Mir coming up
[17:04] <mterry> How do I get mir to write to a "report"?   I see a lot of report->something() calls that look like advanced logging
[17:11] <mterry> nm, found doc/component_reports.md
[17:44] <dandrader> racarr, ping
[18:23] <dandrader> racarr, https://docs.google.com/a/canonical.com/document/d/1LEq6Z9niZR5ITka0QixBu8B5fJPv03MmcW1uNgA2bWg/edit?usp=sharing
[21:09] <racarr> kdub: I found which portion of powerd is messing with us (see last comment here https://bugs.launchpad.net/mir/+bug/1239955)
[21:10] <racarr> it's a little unclear to see the fix so far though...it's a little weird if mir can't really turn the display on, but it's also a little weird if mir deals with suspend states, and kind of weird if mir has to talk to powerd over dbus
[21:11] <kdub> racarr, i agree on all those points :)
[21:12] <racarr> maybe the fix is actually
[21:12] <racarr> elsewhere! for unity, things work because unity talks to powerd
[21:12] <racarr> for the tests, the tests can include wrappers on CI that just run powerd-cli active
[21:12] <racarr> and thats fine
[21:12] <racarr> the only remaining problem, is its inconveient to just
[21:12] <racarr> adb shell in and run
[21:13] <racarr> mir_demo_server_shell
[21:13] <racarr> for developers, etc
[21:13] <racarr> but we could have
[21:13] <racarr> an open shell
[21:13] <racarr> hold the active state
[21:13] <racarr> or
[21:13] <racarr> I dunno
[21:15] <kdub> yeah, its a gotcha for the developers
[21:49] <sil2100> Hi guys
[21:51] <racarr> hi :)
[21:52] <sil2100> Soooo
[21:52] <sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5158273 <- we're getting this here in the daily-build PPA
[21:57] <sil2100> Does anyone know why this dependency wait happens?
[21:57] <sil2100> We're building mir from trunk, so I guess we have the latest of the latest?
[21:58] <sil2100> Did you guys forget to bump the upstream version of mir?
[21:59] <sil2100> Actually, I see the bump in trunk, wonder what cu2d is doing