[03:46] <sam113101> hello
[05:57] <tvoss> good morning
[06:01] <duflu> tvoss: Hello
[06:01] <tvoss> duflu, hey there :) happy new week
[06:02] <duflu> tvoss: Yes, happy Monday
[06:02] <tvoss> duflu, how is it going?
[06:04] <duflu> tvoss: OK I guess. You?
[06:11] <tvoss> duflu, yup, all good :) 2nd coffee, so likely to be better after this cup :)
[07:36] <duflu> didrocks: Done. The new lp:mir has full history, and is separate to development-branch.
[07:37] <didrocks> duflu: ok, did you resync the commit id in the changelog?
[07:37] <didrocks> you know the "last snapshot from rev xxx"
[07:37] <didrocks> can you change it that it matches the new commits if you have override the branch?
[07:37] <duflu> didrocks: The changelogs were already identical. Not sure what else you mean?
[07:37] <didrocks> overriden*
[07:38] <didrocks> duflu: basically, you'll see a line with "Automatic snapshot from revision 1100"
[07:38] <didrocks> duflu: is that right? (I doubt it is if you changed the branch)
[07:38] <didrocks> if it's not, please just change that revision
[07:38] <didrocks> it's used to generate the automatic changelog
[07:38] <duflu> didrocks: Oh, I see. So the master copy is in the changelog head?
[07:38] <duflu> Will do
[07:39] <didrocks> thanks duflu ;)
[07:39] <didrocks> I guess it should be something around rev 1133
[07:40] <duflu> didrocks: Propose it to dev-branch first for you to check?
[07:42] <didrocks> duflu: sure :)
[07:43] <duflu> didrocks: Or does the "Automatic snapshot" comment only make sense on lp:mir ?
[07:44] <didrocks> duflu: it makes sense for lp:mir, but if you want to be able to pull
[07:44] <didrocks> or you can exercise the other way
[07:45] <didrocks> like commiting that to lp:mir
[07:45] <didrocks> and then merging back
[07:45] <didrocks> as if it was a changelog bump
[07:45] <duflu> didrocks: development-branch should stay append-only for safety. It's lp:mir that pulls from development-branch. And development-branch merges from lp:mir
[07:46] <duflu> I'll do it in dev first...
[07:46] <didrocks> ok
[08:09] <duflu> didrocks: Proposed. Now how do we tell Jenkins to pull rather than merge?
[08:09] <didrocks> duflu: that would be a question for fginther, mind emailing him?
[08:13] <duflu> didrocks: Mail sent. Mind reviewing? https://code.launchpad.net/~vanvugt/mir/begin-trusty/+merge/191944
[08:14] <didrocks> duflu: yeah, seems not the right one to me, let me look
[08:15] <didrocks> duflu: commented
[08:18] <duflu> didrocks: Oh I see. Change "Automatic snapshot from revision 1100" to 1133 without adding a new changelog entry?
[08:19] <duflu> It would be accurate, but then inconsistent with the saucy branch
[08:20] <didrocks> duflu: don't worry about changelog accuracy, when merging from debian, some part of the changelog for most projects are removed (there are pros and cons)
[08:20] <didrocks> duflu: you can add a new changelog entry as well (to bump to 0.1.0), but in another MP maybe?
[08:20] <duflu> didrocks: I think it would make sense to not add new entries in development-branch. So just change the 0.0.15 entr?
[08:21] <didrocks> duflu: good to me as well, I have no strong opinion
[08:24] <tvoss> duflu, did you test https://code.launchpad.net/~vanvugt/mir/fix-r1049-regressions/+merge/191776 on maguro and mako?
[08:25] <duflu> tvoss: I ran out of time Friday night. I have mako, so will get to that. But reinstalling presently
[08:25] <tvoss> duflu, ack, let me know if mako works, I can help out with maguro
[08:25] <duflu> tvoss: The old version was well tested before 1049 too
[08:26] <tvoss> duflu, ack
[08:29] <duflu> didrocks: MP updated. I'm wondering how we can get better accuracy in the changelog comments in future too. Seems like most bug fixes never get noticed/mentioned
[08:30] <didrocks> duflu: if they are autogenerated, the rules are simple:
[08:30] <didrocks> - if you change something in debian/changelog, the commit message isn't used
[08:30] <didrocks> - if you didn't touch debian/changelog, the commit message is used
[08:31] <duflu> didrocks: OK, so just tell the team to never touch changelog? If so then who/how does it get updated to 0.1.0?
[08:33] <didrocks> duflu: no, just ensure that if you modify it, you put all necessary informations
[08:34] <duflu> didrocks: So version bump entries come from development-branch and then leave it up to the robots on lp:mir?
[09:05] <duflu> didrocks: If this is wrong, I only have about an hour left to fix it... https://code.launchpad.net/~vanvugt/mir/begin-trusty/+merge/191944
[09:05] <didrocks> duflu: sorry, in meetings
[09:05] <didrocks> duflu: you didn't bump debian/changelog to 0.1.0?
[09:06] <duflu> didrocks: I was confused. I got the impression that the robots would figure it out. Or do those major bumps come from humans?
[09:06] <didrocks> duflu: no, major bumps are only handled by humans
[09:06] <duflu> OK
[09:07] <didrocks> so an additional entry UNRELEASED with 0.1.0
[09:07] <didrocks> and fine to get it into :)
[09:07] <duflu> didrocks: But that entry does _not_ mention "Automatic snapshot..." ?
[09:08] <didrocks> duflu: right!
[09:09] <duflu> didrocks: So the robot(s) modify the head entry if it's "UNRELEASED"?
[09:11] <penghuan> Hello, all, is there any doc about how to run the examples in mir? such as mir_demo_client_basic, etc. Thanks!
[09:12] <didrocks> duflu: exactly
[09:12] <didrocks> duflu: approved
[09:13] <duflu> didrocks: Thanks
[09:13] <duflu> penghuan: It's possible the docs are overcomplicated... but before you start, be aware "basic" does nothing. The other demos are more interesting.
[09:14] <duflu> penghuan: (1) start a server: sudo mir_demo_server_shell
[09:14] <duflu> penghuan: (2) Run a client: sudo mir_demo_client_eglplasma
[09:15] <duflu> But you will need an ssh or other login to be able to do that :)
[09:15] <penghuan> duflu: OK,i'll have a try,thanks!
[09:18] <penghuan> duflu: When  run mir_demo_server_shell,i got an error "Address already in use", i'm running xmir ,it means i should stop xmir first?
[09:19] <duflu> penghuan: Yes that would be best
[09:19] <penghuan> duflu: Thanks!
[13:06] <mhall119> kgunn: where are the instructions for running Mir on 13.10?
[13:06] <mhall119> XMir and Unity 7 that is
[13:07] <kgunn> mhall119: lemme see if we've updated them
[13:07] <alan_g> kgunn: mhall119 this should be it: http://unity.ubuntu.com/mir/using_mir_on_pc.html
[13:07] <kgunn> mhall119: yeah...we did http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
[13:08] <mhall119> thanks
[13:11] <davmor2> kgunn: daft question time?  What does xmir give us that is worth the effort and support for 5 years?  I'm just wondering if it might be time better spent perfecting mir ready for 14.10
[13:11] <mhall119> kgunn: where are the "If things go wrong, here's how to get back to plain Xorg"?
[13:12] <tvoss> mhall119, you are after: http://unity.ubuntu.com/mir/using_mir_on_pc.html
[13:12] <davmor2> mhall119: remove the unity-* package that you install
[13:12] <mhall119> davmor2: one reason I can think of: We're going to need to support non-Unity DE's on a Mir system compositor for some time still
[13:13] <mhall119> davmor2: no simple config switch I can throw?
[13:14] <mdeslaur> davmor2: I'd really like to be able to run apps and legacy apps that don't use gtk, qt, or sdl
[13:18] <kgunn> mhall119: the other method...is to comment out type=unity in the /etc/lightdm/lightdm.conf.d/10-unity-system-compositor.conf file (e.g. #type=unity)
[13:18] <mhall119> mdeslaur: I thought XMir was already able to run rootless X11 apps well enough, it was running a full X11 desktop and it's additional requirements that were causing problems
[13:18] <mhall119> thanks kgunn, that's what I was looking for
[13:19] <kgunn> mhall119: current xmir has no input support wrt mir (...its all still totally X)
[13:19] <davmor2> mdeslaur: let me see if I'm right though.  In 14.10 mir not xmir becomes the default to run unity and graphics in general right?  So xmir is only going to be used on 14.04 which then has to be supported for 5 years.  Unless xmir is going to be use for the foreseeable future then I would get it
[13:19] <tvoss> mhall119, the main problem with XMir (specifically the X parts) is multi-monitor support, which is not required for a rootless scenario
[13:20] <tvoss> davmor2, we need xmir in 14.10 forward, too, to support legacy apps
[13:20] <davmor2> tvoss: okay now it makes more sense thanks
[13:20] <mhall119> kgunn: so how does that impact rootless X11 apps?  Does it mean they don't have input support atm?
[13:21] <tvoss> mhall119, we don't support the rootless scenario right now
[13:21] <kgunn> mhall119: no, we don't have rootless yet
[13:22] <kgunn> what tvoss said :)
[13:22] <kgunn> mhall119: xmir is a truly full X session compositors sitting on top of mir only as a system compositor
[13:23] <kgunn> mhall119: when we do the work for rootless...the assumption is mir is both the session & system compositor
[13:23] <mhall119> ok
[13:23] <kgunn> so the rootless x is a windowed app into a full mir-only system
[13:24] <mlankhorst> sounds about right
[13:24] <mhall119> is there currently a way to run Unity 8 as a session in 13.10?
[13:24] <mhall119> on x86 laptop
[13:26] <kgunn> mhall119: https://unity.ubuntu.com/getinvolved/development/unity8/#running-unity
[13:26] <kgunn> mhall119: although....hang on...
[13:28] <kgunn> mhall119: this is better http://www.omgubuntu.co.uk/2013/08/unity-8-ubuntu-13-10-arrives
[13:33] <mhall119> kgunn: that will run it in a windows on my desktop, right?
[13:34] <kgunn> mhall119: yes, effectively
[13:34] <kgunn> mhall119: sans mir you realize
[13:52] <mhall119> I didn't
[13:52] <mhall119> but that's okay
[13:52] <mhall119> sorry, I know that when running Unity8 in a window on Unity 7 it won't use mir
[13:52] <mhall119> I was wondering if there was a way to run Unity 8 *as* the session on top of Mir
[13:53] <mhall119> so I can launch SDK apps inside of Unity 8 on my laptop
[13:58] <kgunn> mhall119: only on the phone....
[13:58] <mhall119> ok
[13:59] <mhall119> kgunn: are there any plans yet for getting an initial setup like that working?  Seems a necessary starting point for Unity 8 Desktop development to begin
[13:59] <mhall119> and yes,I know that Unity 8 Desktop *design* hasn't even started yet
[13:59] <mhall119> I'm just impatient
[14:00] <kgunn> mhall119: no problem...but i would question you....why not just launch your app within unity8 (on desktop w/o mir) ?
[14:00] <mhall119> can I do that?
[14:00] <kgunn> mhall119: i know its not completely real...but
[14:01] <kgunn> nothing will be real until we do full desktop
[14:01] <mhall119> last time I tried to open an app in the windowed Unity 8, it opened it in a Unity 7 window
[14:01] <kgunn> mhall119: when was that ?
[14:01] <mhall119> months ago
[14:35] <mhall119> kgunn: okay, another question, has anybody looked at porting the SDL library to Mir?  There are a lot of games and apps that use it, and I believe it already supports multiple backends (X11, Windows, OSX)
[14:36] <kgunn> mhall119: yes...this is in progress (and actually working to a degree)
[14:36] <kgunn> mhall119: bschaefer has been doing this
[14:37] <kgunn> mhall119: the unfortunate thing is...some of the games pull in their own sdl bins
[14:37] <kgunn> mhall119: so you can't really plug-n-play like you'd think
[14:39] <mdeslaur> kgunn: are they statically linking to sdl, or they are shipping their own .so somewhere?
[14:43] <kgunn> mdeslaur: just went to read some of the correspondence on that...and you're right, i think we can load dynamically
[17:09] <mhall119> kgunn: so I followed the steps to run unity-system-compositor, but it isn't running
[17:10] <mhall119> does the intel i915 work on Mir?
[17:11] <mhall119> cat /var/log/lightdm/unity-system-compositor.log
[17:11] <mhall119> linkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
[17:11] <sarnold> mhall119: tests/autopilot/unity_system_compositor/test_runtime.py  suggests yes
[17:11] <mhall119> I think maybe I have some problem with what's on my system...
[17:11] <mhall119> grep -i xmir /var/log/Xorg.0.log
[17:11] <mhall119> [ 63378.927] (WW) "xmir" is not to be loaded by default. Skipping.
[17:43] <kdub> anyone know what's going on with: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-armhf-ci/
[17:58] <racarr> Howdy team
[17:58] <racarr> sorry about oversleep
[18:00] <racarr> How is 14.04 going ;)
[18:02] <kgunn> racarr o/  mornin' ?
[18:02] <kgunn> :)
[18:03] <kgunn> mhall119: just guessing you don't have gles2 drivers on that system...which you would need for mir
[18:06] <racarr> Morning kgunn. Happy new release :D
[18:06] <racarr> I realized you are coming to California next week?
[18:06] <kgunn> racarr: yes
[18:06] <kgunn> racarr: altho...i've been in personal denial :)
[18:06] <kgunn> travel...ug
[18:07] <racarr> yeah eww
[18:07] <kgunn> i don't mind it...but i always lose so much sleep
[18:07] <kgunn> especially sharing a room...
[18:08] <racarr> well unless you manage to deny your way out of it
[18:08] <racarr> lets go out to dinner some night lol
[18:08] <kgunn> racarr: good idea! i'll let you know when i get out there what night will be more free
[18:08] <kgunn> btw...seb & dednick will be out there
[18:09] <kgunn> if you just wanted to come have some f2f
[18:09] <kgunn> along with saviq and others
[18:09] <racarr> :) sounds good
[18:09] <racarr> yes, I think it would be good to come some time just to catch up with some people
[18:09] <racarr> but don't know when it useful yet, so let me know.
[19:01] <mterry> Heyo!  I'm messing around with nested Mir servers (i.e. through unity-system-compositor).  I see behavior where once the second nested server comes up, my first nested server aborts with "Bad file descriptor".  Is it possible they aren't sharing the host socket well?
[19:03] <davmor2> mterry: well don't mess with nested mir then :P
[19:03] <mterry> :(
[19:29] <kgunn> mterry: are you on arm/android or trying on desktop ?
[19:29] <kgunn> wrt nested mir
[19:29] <mterry> kgunn, arm/android
[19:30] <kgunn> mterry: there was a change around that....
[19:33] <kgunn> mterry: still digging
[19:37] <kgunn> mterry: there's this one...but not the one i was thinking... https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326
[19:40] <mterry> kgunn, ah hmm.  Yes.  robert_ancell was talking about adding a non-socket method for USC to talk to sessions (though unity8 and friends would continue to use a socket for their children)
[19:40] <mterry> kgunn, that branch looks like part of it
[19:41] <mterry> kgunn, maybe it's easier to use a new method than investigate why sockets don't work
[19:41] <kgunn> robert_ancell should be on in a bit....and he might still like us just enough to give us some direction :)
[19:42] <racarr> lunch lunch
[20:23] <racarr> Back back.
[21:32] <mterry> kgunn, robert_ancell approved my mir-fixes branch for u-s-c, so whenever you want to pull the switch on that abi bump, feel free to top-approve my branch
[21:32] <kgunn> mterry: rock on....thanks
[22:35] <mterry> robert_ancell, this socket-connection branch that added the no-file mode to Mir...  It looks like it uses shared fd's, but USC child sessions aren't usually direct process children of USC, right?  And thus can't share the fd?
[22:37] <robert_ancell> mterry, lightdm gets the fd from u-s-c and leaves it open when forking off sessions
[22:39] <mterry> robert_ancell, u-s-c can give an fd back up to its spawning parent?
[22:39] <robert_ancell> mterry, over the lightdm<>u-s-c protocol. It was a pipe but I changed it to a socket and it can now pass file descriptors across it
[22:39] <mterry> ah..
[22:40] <robert_ancell> mterry, there's some clever dependencies required to upgrade these components synchronously
[22:40] <robert_ancell> mterry, all the work should be there, but when I last ran it XMir was failing to connect
[22:44] <mterry> Well... I'll give it a shot
[22:45] <mterry> robert_ancell, is there any magic besides --no-file I need to provide?  Like, I assume that sets MIR_SOCKET to something magic that gets interpreted correctly without my effort?
[22:45] <robert_ancell> mterry, you set MIR_SOCKET to fd://n
[22:45] <robert_ancell> and then n just has to be the valid file descriptor
[22:46] <robert_ancell> all the details should be taken care of in libmirclient (assuming it works)
[22:47] <mterry> robert_ancell, ideally lightdm would set MIR_SOCKET to the right thing.  I don't think I saw it doing anything fancy there last time I looked in trunk
[22:48] <robert_ancell> mterry, the branch changes it from setting MIR_SOCKET=/tmp/mir_socket (hard-coded) to MIR_SOCKET=fd://n
[22:48] <robert_ancell> mterry, what do you mean "that I need to provide?"
[22:49] <robert_ancell> brb
[22:58] <mterry> robert_ancell, I had missed that this was a branch we were talking about instead of trunk.  I see the work now in private-mir-connection.
[22:58] <robert_ancell> mterry, ah
[22:58] <mterry> robert_ancell, it hasn't landed yet because xmir didn't work with it?
[22:58] <robert_ancell> mterry, correct
[22:59] <robert_ancell> mterry, also being too close to release for such a risky change
[22:59] <mterry> robert_ancell, pfft, release is 6 months away!  ;)
[22:59] <robert_ancell> oh, it's fine for T!
[23:00] <mterry> robert_ancell, well I'll play with it in my split greeter mode on the phone.  Maybe I'll discover something that explains xmir's problem
[23:00] <robert_ancell> mterry, nice, thanks!