#ubuntu-mir 2013-10-21
<sam113101> hello
<tvoss> good morning
<duflu> tvoss: Hello
<tvoss> duflu, hey there :) happy new week
<duflu> tvoss: Yes, happy Monday
<tvoss> duflu, how is it going?
<duflu> tvoss: OK I guess. You?
<tvoss> duflu, yup, all good :) 2nd coffee, so likely to be better after this cup :)
<duflu> didrocks: Done. The new lp:mir has full history, and is separate to development-branch.
<didrocks> duflu: ok, did you resync the commit id in the changelog?
<didrocks> you know the "last snapshot from rev xxx"
<didrocks> can you change it that it matches the new commits if you have override the branch?
<duflu> didrocks: The changelogs were already identical. Not sure what else you mean?
<didrocks> overriden*
<didrocks> duflu: basically, you'll see a line with "Automatic snapshot from revision 1100"
<didrocks> duflu: is that right? (I doubt it is if you changed the branch)
<didrocks> if it's not, please just change that revision
<didrocks> it's used to generate the automatic changelog
<duflu> didrocks: Oh, I see. So the master copy is in the changelog head?
<duflu> Will do
<didrocks> thanks duflu ;)
<didrocks> I guess it should be something around rev 1133
<duflu> didrocks: Propose it to dev-branch first for you to check?
<didrocks> duflu: sure :)
<duflu> didrocks: Or does the "Automatic snapshot" comment only make sense on lp:mir ?
<didrocks> duflu: it makes sense for lp:mir, but if you want to be able to pull
<didrocks> or you can exercise the other way
<didrocks> like commiting that to lp:mir
<didrocks> and then merging back
<didrocks> as if it was a changelog bump
<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
<duflu> I'll do it in dev first...
<didrocks> ok
<duflu> didrocks: Proposed. Now how do we tell Jenkins to pull rather than merge?
<didrocks> duflu: that would be a question for fginther, mind emailing him?
<duflu> didrocks: Mail sent. Mind reviewing? https://code.launchpad.net/~vanvugt/mir/begin-trusty/+merge/191944
<didrocks> duflu: yeah, seems not the right one to me, let me look
<didrocks> duflu: commented
<duflu> didrocks: Oh I see. Change "Automatic snapshot from revision 1100" to 1133 without adding a new changelog entry?
<duflu> It would be accurate, but then inconsistent with the saucy branch
<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)
<didrocks> duflu: you can add a new changelog entry as well (to bump to 0.1.0), but in another MP maybe?
<duflu> didrocks: I think it would make sense to not add new entries in development-branch. So just change the 0.0.15 entr?
<didrocks> duflu: good to me as well, I have no strong opinion
<tvoss> duflu, did you test https://code.launchpad.net/~vanvugt/mir/fix-r1049-regressions/+merge/191776 on maguro and mako?
<duflu> tvoss: I ran out of time Friday night. I have mako, so will get to that. But reinstalling presently
<tvoss> duflu, ack, let me know if mako works, I can help out with maguro
<duflu> tvoss: The old version was well tested before 1049 too
<tvoss> duflu, ack
<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
<didrocks> duflu: if they are autogenerated, the rules are simple:
<didrocks> - if you change something in debian/changelog, the commit message isn't used
<didrocks> - if you didn't touch debian/changelog, the commit message is used
<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?
<didrocks> duflu: no, just ensure that if you modify it, you put all necessary informations
<duflu> didrocks: So version bump entries come from development-branch and then leave it up to the robots on lp:mir?
<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
<didrocks> duflu: sorry, in meetings
<didrocks> duflu: you didn't bump debian/changelog to 0.1.0?
<duflu> didrocks: I was confused. I got the impression that the robots would figure it out. Or do those major bumps come from humans?
<didrocks> duflu: no, major bumps are only handled by humans
<duflu> OK
<didrocks> so an additional entry UNRELEASED with 0.1.0
<didrocks> and fine to get it into :)
<duflu> didrocks: But that entry does _not_ mention "Automatic snapshot..." ?
<didrocks> duflu: right!
<duflu> didrocks: So the robot(s) modify the head entry if it's "UNRELEASED"?
<penghuan> Hello, all, is there any doc about how to run the examples in mir? such as mir_demo_client_basic, etc. Thanks!
<didrocks> duflu: exactly
<didrocks> duflu: approved
<duflu> didrocks: Thanks
<duflu> penghuan: It's possible the docs are overcomplicated... but before you start, be aware "basic" does nothing. The other demos are more interesting.
<duflu> penghuan: (1) start a server: sudo mir_demo_server_shell
<duflu> penghuan: (2) Run a client: sudo mir_demo_client_eglplasma
<duflu> But you will need an ssh or other login to be able to do that :)
<penghuan> duflu: OK,i'll have a try,thanks!
<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?
<duflu> penghuan: Yes that would be best
<penghuan> duflu: Thanks!
<mhall119> kgunn: where are the instructions for running Mir on 13.10?
<mhall119> XMir and Unity 7 that is
<kgunn> mhall119: lemme see if we've updated them
<alan_g> kgunn: mhall119 this should be it: http://unity.ubuntu.com/mir/using_mir_on_pc.html
<kgunn> mhall119: yeah...we did http://unity.ubuntu.com/mir/installing_prebuilt_on_pc.html
<mhall119> thanks
<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
<mhall119> kgunn: where are the "If things go wrong, here's how to get back to plain Xorg"?
<tvoss> mhall119, you are after: http://unity.ubuntu.com/mir/using_mir_on_pc.html
<davmor2> mhall119: remove the unity-* package that you install
<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
<mhall119> davmor2: no simple config switch I can throw?
<mdeslaur> davmor2: I'd really like to be able to run apps and legacy apps that don't use gtk, qt, or sdl
<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)
<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
<mhall119> thanks kgunn, that's what I was looking for
<kgunn> mhall119: current xmir has no input support wrt mir (...its all still totally X)
<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
<tvoss> mhall119, the main problem with XMir (specifically the X parts) is multi-monitor support, which is not required for a rootless scenario
<tvoss> davmor2, we need xmir in 14.10 forward, too, to support legacy apps
<davmor2> tvoss: okay now it makes more sense thanks
<mhall119> kgunn: so how does that impact rootless X11 apps?  Does it mean they don't have input support atm?
<tvoss> mhall119, we don't support the rootless scenario right now
<kgunn> mhall119: no, we don't have rootless yet
<kgunn> what tvoss said :)
<kgunn> mhall119: xmir is a truly full X session compositors sitting on top of mir only as a system compositor
<kgunn> mhall119: when we do the work for rootless...the assumption is mir is both the session & system compositor
<mhall119> ok
<kgunn> so the rootless x is a windowed app into a full mir-only system
<mlankhorst> sounds about right
<mhall119> is there currently a way to run Unity 8 as a session in 13.10?
<mhall119> on x86 laptop
<kgunn> mhall119: https://unity.ubuntu.com/getinvolved/development/unity8/#running-unity
<kgunn> mhall119: although....hang on...
<kgunn> mhall119: this is better http://www.omgubuntu.co.uk/2013/08/unity-8-ubuntu-13-10-arrives
<mhall119> kgunn: that will run it in a windows on my desktop, right?
<kgunn> mhall119: yes, effectively
<kgunn> mhall119: sans mir you realize
<mhall119> I didn't
<mhall119> but that's okay
<mhall119> sorry, I know that when running Unity8 in a window on Unity 7 it won't use mir
<mhall119> I was wondering if there was a way to run Unity 8 *as* the session on top of Mir
<mhall119> so I can launch SDK apps inside of Unity 8 on my laptop
<kgunn> mhall119: only on the phone....
<mhall119> ok
<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
<mhall119> and yes,I know that Unity 8 Desktop *design* hasn't even started yet
<mhall119> I'm just impatient
<kgunn> mhall119: no problem...but i would question you....why not just launch your app within unity8 (on desktop w/o mir) ?
<mhall119> can I do that?
<kgunn> mhall119: i know its not completely real...but
<kgunn> nothing will be real until we do full desktop
<mhall119> last time I tried to open an app in the windowed Unity 8, it opened it in a Unity 7 window
<kgunn> mhall119: when was that ?
<mhall119> months ago
<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)
<kgunn> mhall119: yes...this is in progress (and actually working to a degree)
<kgunn> mhall119: bschaefer has been doing this
<kgunn> mhall119: the unfortunate thing is...some of the games pull in their own sdl bins
<kgunn> mhall119: so you can't really plug-n-play like you'd think
<mdeslaur> kgunn: are they statically linking to sdl, or they are shipping their own .so somewhere?
<kgunn> mdeslaur: just went to read some of the correspondence on that...and you're right, i think we can load dynamically
<mhall119> kgunn: so I followed the steps to run unity-system-compositor, but it isn't running
<mhall119> does the intel i915 work on Mir?
<mhall119> cat /var/log/lightdm/unity-system-compositor.log
<mhall119> linkerlinker.c:1095| ERROR: Library '/system/lib/libGLESv2.so' not found
<sarnold> mhall119: tests/autopilot/unity_system_compositor/test_runtime.py  suggests yes
<mhall119> I think maybe I have some problem with what's on my system...
<mhall119> grep -i xmir /var/log/Xorg.0.log
<mhall119> [ 63378.927] (WW) "xmir" is not to be loaded by default. Skipping.
<kdub> anyone know what's going on with: https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-armhf-ci/
<racarr> Howdy team
<racarr> sorry about oversleep
<racarr> How is 14.04 going ;)
<kgunn> racarr o/  mornin' ?
<kgunn> :)
<kgunn> mhall119: just guessing you don't have gles2 drivers on that system...which you would need for mir
<racarr> Morning kgunn. Happy new release :D
<racarr> I realized you are coming to California next week?
<kgunn> racarr: yes
<kgunn> racarr: altho...i've been in personal denial :)
<kgunn> travel...ug
<racarr> yeah eww
<kgunn> i don't mind it...but i always lose so much sleep
<kgunn> especially sharing a room...
<racarr> well unless you manage to deny your way out of it
<racarr> lets go out to dinner some night lol
<kgunn> racarr: good idea! i'll let you know when i get out there what night will be more free
<kgunn> btw...seb & dednick will be out there
<kgunn> if you just wanted to come have some f2f
<kgunn> along with saviq and others
<racarr> :) sounds good
<racarr> yes, I think it would be good to come some time just to catch up with some people
<racarr> but don't know when it useful yet, so let me know.
<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?
<davmor2> mterry: well don't mess with nested mir then :P
<mterry> :(
<kgunn> mterry: are you on arm/android or trying on desktop ?
<kgunn> wrt nested mir
<mterry> kgunn, arm/android
<kgunn> mterry: there was a change around that....
<kgunn> mterry: still digging
<kgunn> mterry: there's this one...but not the one i was thinking... https://code.launchpad.net/~alan-griffiths/mir/socket-connection/+merge/187326
<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)
<mterry> kgunn, that branch looks like part of it
<mterry> kgunn, maybe it's easier to use a new method than investigate why sockets don't work
<kgunn> robert_ancell should be on in a bit....and he might still like us just enough to give us some direction :)
<racarr> lunch lunch
<racarr> Back back.
<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
<kgunn> mterry: rock on....thanks
<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?
<robert_ancell> mterry, lightdm gets the fd from u-s-c and leaves it open when forking off sessions
<mterry> robert_ancell, u-s-c can give an fd back up to its spawning parent?
<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
<mterry> ah..
<robert_ancell> mterry, there's some clever dependencies required to upgrade these components synchronously
<robert_ancell> mterry, all the work should be there, but when I last ran it XMir was failing to connect
<mterry> Well... I'll give it a shot
<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?
<robert_ancell> mterry, you set MIR_SOCKET to fd://n
<robert_ancell> and then n just has to be the valid file descriptor
<robert_ancell> all the details should be taken care of in libmirclient (assuming it works)
<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
<robert_ancell> mterry, the branch changes it from setting MIR_SOCKET=/tmp/mir_socket (hard-coded) to MIR_SOCKET=fd://n
<robert_ancell> mterry, what do you mean "that I need to provide?"
<robert_ancell> brb
<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.
<robert_ancell> mterry, ah
<mterry> robert_ancell, it hasn't landed yet because xmir didn't work with it?
<robert_ancell> mterry, correct
<robert_ancell> mterry, also being too close to release for such a risky change
<mterry> robert_ancell, pfft, release is 6 months away!  ;)
<robert_ancell> oh, it's fine for T!
<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
<robert_ancell> mterry, nice, thanks!
#ubuntu-mir 2013-10-22
<bschaefer> duflu, ping
<duflu> bschaefer: Hello
<bschaefer> duflu, Hey, so before i head off for the night i wanted to about racarrs comment on my v/h scroll branch
<bschaefer> https://code.launchpad.net/~brandontschaefer/mir/lp.1233089-fix-v-h-scroll-v2/+merge/189750
<bschaefer> duflu, increasing the MAX_INPUT_POINTER_SIZE just incase we run into this problem again...
<bschaefer> though it wont help in changing the size of point_cords, but the more room it gives us a bit more options...
<duflu> bschaefer: Padding makes sense. But more than 10 pointers does not :)
<bschaefer> duflu, very true, its at 16 atm, which if pretty large
<bschaefer> err yeah
<bschaefer> duflu, how would be pad it then? Just add some dummy floats?
<duflu> bschaefer: Yeah some dummy ints inside pointer_coordinates, and more on the end of the struct
<bschaefer> duflu, do you have a number in mind :)
<duflu> named "unused" etc
<duflu> bschaefer: It's not the end of the world if we run out. So no more than 8, max
<bschaefer> 4 in each?
<duflu> Maybe
<bschaefer> well ill add that, and i can push changes tomorrow if more discussions happen
<bschaefer> duflu, pushed :), and thanks for helping with that MP (i've a better understanding of ABI breakage..and more ways around now!)
<duflu> bschaefer: Thank you too
<bschaefer> np!
<tvoss> mhall119, you have got libhybris or libhybris-dev installed on your system. Please just remove it.
<duflu> tvoss: bug 1232962 :(
<duflu> :)
<ubot5> bug 1232962 in libhybris (Ubuntu) "hybris packages should fail to install if an Android filesystem is not detected" [Wishlist,New] https://launchpad.net/bugs/1232962
<tvoss> duflu, yup
<duflu> mlankhorst: Any movement on bug 1195811?
<ubot5> bug 1195811 in linux (Ubuntu) "nouveau: Abnormally high FPS and tearing (no vsync) with nouveau" [High,In progress] https://launchpad.net/bugs/1195811
<mlankhorst> duflu: I poked upstream about it, they'll look at it, but power management is a higher priority :/
<duflu> mlankhorst: Did you mention it directly affects power usage? :)
<mlankhorst> well if you grab the patches from my tree you'll have a lot less issues tbh
<mlankhorst> http://cgit.freedesktop.org/~mlankhorst/linux/log/ just this one "drm/nouveau: enable vblank support on nv50 and fermi cards"
<mlankhorst> on top of recent kernel
<duflu> mlankhorst: Actually I'm not using nv-anything right now. Just curious how it's going
<mlankhorst> tsk:P
<duflu> tvoss: Confirmed fix-r1049-regressions improves performance on Nexus 4 too
<duflu> Slightly. Most noticeably in egltriangle -f
<tvoss> duflu, ack. did you try with unity8?
<duflu> tvoss: No
<tvoss> duflu, can you please confirm? I can confirm that it improves performance on maguro
<duflu> tvoss: Does unity8 have any special incantations or just run the binary?
<tvoss> duflu, just boot the phone I would even say
<duflu> tvoss: Not sure how to package x-compiled packages...
<duflu> -packages +binaries
<tvoss> duflu, why not just flash a current image? :)
<duflu> tvoss: I just did
<alf_> mlankhorst: I am going to resume nested Mir work today. Do the i965 experiments in the egl-platform-mir-egl-image-i965-experiment have any effect, or should I just revert them?
<alf_> mlankhorst: i.e., https://github.com/afrantzis/mesa/commit/b325ffb333875477a83e42bbfc595bb33e4df19a
<duflu> This is weird. How does the unity8 binary not link even indirectly to libmir*?
<alf_> duflu: it uses mir through Qt
<duflu> alf_: Which library? ldd usually shows all indirectly loaded so's too
<alf_> duflu: it's a Qt platform plugin, loaded at runtime
<duflu> Oh
<duflu> cool
<alf_> duflu: I don't remember the exact path of the plugin, probably somewhere under /usr/lib/.../qt5/..
<mlankhorst> alf_: all my patches should be applied on top of that branch
<mlankhorst> but the i965_context.c is needed probably, dno, it's more sane anyway
<alf_> mlankhorst: ok, I will keep the changes for now, and we can figure it out later
<duflu> alan_g, alf_, tvoss: I think we lack enough common ground to bother having this call today. Probably best to reject the proposals, move on, and ideally someone propose some nice alternatives
<alan_g> duflu: (alf_ tvoss) - I'd like to reach a consensus rather than leaving a disagreement simmering. But if that's how you feel...
<tvoss> duflu, no time for keeping the discussion around any longer. The argument of cleanup has been raised repeatedly in previous discussions as preventing us from moving forward rapidly. Thus, we need to resolve the issue *today*
<duflu> tvoss: OK, figured it out. But we bumped the server ABI :P
<alan_g> duflu: hangout?
<duflu> alan_g, trying
<duflu> tvoss: Confirmed the branch (built against saucy Mir) works nicely with Unity8. It's at least as smooth as the released version
<tvoss> duflu, ack. got a maguro, too?
<duflu> tvoss: No. I wish... sometimes
<duflu> tvoss: I remember kdub saying when that version was first proposed (as the "switch" branch) he said it helped maguro. But that was way back
<tvoss> duflu, ack
<tvoss> alf_, can you see if your question in https://code.launchpad.net/~vanvugt/mir/fix-r1049-regressions/+merge/191776 is addressed?
<alf_> tvoss: looking
<tvoss> alf_, thx
<alf_> duflu: Is the lock/unlock mechanism in the test fragile? That is, could the test fail if we are unlucky enough with the timings?
<duflu> alf_: It's the other way round... the lock/unlock *help* the test to fail more often when the fix is absent :)
<mlankhorst> alf_: did it work? :p
<alf_> mlankhorst: sorry, haven't got to it yet, will do so after lunch
<alf_> duflu: ok
<duflu> alan_g: Where a header moves from public to "protected" (libmirserver internal), can we #include "../component/" for now to avoid logic changes on this first step?
<alan_g> duflu: we *shouldn't* need that. Where does it happen?
<duflu> alan_g: Where shell::Surface calls surfaces::Surface
<alan_g> duflu: I think that specific case is best handled by changing the logic - we can live with one hard to shift class for a little longer.
<alan_g> I think shell::Surface can become base class for surfaces::Surface with very little effort.
<duflu> alan_g: If you'd block on that (and the other occurrence render_surfaces) then I'll defer the whole proposal. It requires more time than just tonight
<alan_g> duflu: ack - I know that one is gnarly - I'll try to get to it this afternoon
<duflu> alan_g: BTW their only relationship right now is that shell::Surface points to the surfaces::Surface
<duflu> According to me scrawlings
<duflu> In fact, that relationship singularly divides the graph in two
<alan_g> duflu: Yeah, but it is a very trivial proxy
<duflu> alan_g: Two privatize MPs updated. The other is hidden until further notice.
<duflu> Ironically, the one most approved has to be deferred the longest
<alan_g> duflu: ack, will look
<didrocks> does anyone know if libmirserver is leaking some boost objects?
<didrocks> (we have some mismatch due to boost)
<tvoss> didrocks, libmirserver does not expose boost via its public interfaces as far as I know
<didrocks> tvoss: see #ubuntu-eng-ci about templates
<didrocks> ooopss #ubuntu-ci-eng rather
<tvoss> didrocks, not seeing a discussion there and don't have backlog :)
<ogra_> terminate called after throwing an instance of 'boost::exception_detail::clone_impl<boost::exception_detail::error_info_injector<std::runtime_error> >'
<ogra_>   what():  Could not open hardware module
<didrocks> 13:36:20      xnox | didrocks: templates do leak ABI/API mismatches, via transitive dependencies.
<didrocks> 13:36:31      xnox | didrocks: but that's "standard C++" feature.
<ogra_> tvoss, thats what i get in the unity8 log on the latest trustyx image
<didrocks> ogra_: trustyx? sounds, sexy ;)
<tvoss> ogra_, oh well, exceptions are leaked, yes
<alan_g> didrocks: Nothing has been done (yet) to prevent boost symbols being exported
<ogra_> tvoss, while unity8 was rebuiolt for boost where seem to be other Ã¼places wheer a rebuild is needed too
<didrocks> ok, let's try a rebuild of platform-api and unity-mir then
<ogra_> s/where/there/
<alan_g> Is that what you mean?
<didrocks> alan_g: yeah, mir was transitionned to new boost, but we have that exception above
<didrocks> so can be that unity-mir and platform-api (mirserver deps) needs a rebuild as wll
<didrocks> well*
<tvoss> didrocks, my bad, I forgot about the exception
<didrocks> no worry, let's see if it helps :)
<xnox> tvoss: the question is if the exception is failing due to boost ABI missmatch, or the exception is real and unity8 is failing to open hardware module =)
<didrocks> xnox: TBH, I would prefer #1 :)
<ogra_> didrocks, i'll refrain from doing a local build then, tell me if the debs are in the PPA and ill test them, i'll leave my phone in the broken state for that
<didrocks> ogra_: I'm just building on my phone
<ogra_> oh. ok
<didrocks> ogra_: well, if I can boot
<didrocks> ogra_: I have the android bot spinning when flashing
<ogra_> thats normal
<ogra_> it will reboot fine and leave you with the google logo then
<ogra_> (and adb)
<didrocks> ogra_: hum, are you a nm expert?
<didrocks> ogra_: I guess I need network and connect to wifi without any ui :p
<ogra_> oh,. you flashed with --no-backup ?
<ogra_> try phablet-network
<ogra_> (with the phone connedcted to a lappie)
<didrocks> ogra_: trusting you, launching random commands :)
<didrocks> ogra_: I didn't use --no-backup, it's just nm didn't come up
<ogra_> oh
<didrocks> Network setup complete
<didrocks> # ifconfig
<didrocks> lo        Link encap:Local Loopback
<didrocks> and only lo
<didrocks> Network connection failed to become active.
<didrocks> ah :)
<didrocks> ok, starting the process by hand
<didrocks> good :)
<ogra_> works ?
<didrocks> yep :)
<ogra_> good
<didrocks> nice trick, thanks ogra
 * didrocks apt-get source and try
<didrocks> ogra_: did you just try sudo start unity8?
<ogra_> hmm, no
<ogra_> phablet@ubuntu-phablet:~$ sudo start unity8
<ogra_> [sudo] password for phablet:
<ogra_> start: Unknown job: unity8
<ogra_> heh
<ogra_> falls back to the system init it seems
<didrocks> ogra_: you do you start those upstart jobs?
<didrocks> ogra_: just so that I'm running the same way as you, how did you start it?
<didrocks> you just look at usptart logs?
<didrocks> hum, I'm not even getting to the user session (there is no .local/.cache)
<ogra_> sudo -i phablet -i
<ogra_> start unity8
<ogra_> thats all i do
<ogra_> and then check the upstart log
<didrocks> ogra_: yeah, I have no session started
<ogra_> (or see it come up)
<didrocks> # sudo -i phablet -i
<didrocks> initctl: unable to determine sessions
<ogra_> oh weird
<didrocks> and no .*
<ogra_> so try starting lightdm first
<ogra_> as root
<didrocks> still the same :/
<didrocks> (but lightdm started)
<didrocks> ogra_: so, for you, the session did start at least?
<ogra_> lightdm did apparently
<ogra_> (upstart claimed it was running when i tried to start it)
<ogra_> instead of poking around manually, did you just try a reboot with the rebuilt packages ?
<xnox> didrocks: where are you testing unity from? such that I can check which boost's it's using.
<xnox> didrocks: and if needed revert those r-deps to boost1.53 until we know it works.
<didrocks> xnox: I guess there is another issue TBH
<didrocks> xnox: I started lightdm and not sure I have a seat
<xnox> didrocks: that can't be good =/
<ogra_> didrocks, the log should tell you
<didrocks> # less /var/log/upstart/systemd-logind.log
<didrocks> New session c3 of user phablet.
<didrocks> so, I have one
<ogra_> [+0.34s] DEBUG: Seat: Session authenticated, running command
<ogra_> [+0.34s] DEBUG: Registering session with bus path /org/freedesktop/DisplayManager/Session0
<ogra_> [+0.35s] DEBUG: Session pid=884: Running command /usr/sbin/lightdm-session ubuntu-touch-session
<ogra_> [+0.36s] DEBUG: Session pid=884: Logging to .xsession-errors
<didrocks> but no user session started it seems
<ogra_> tail /var/log/lightdm/lightdm.log
<ogra_> (is what that was)
 * ogra_ wonders if he sees an old log
<ogra_> root@ubuntu-phablet:/# ls -l  /var/log/lightdm/lightdm.log
<ogra_> -rw------- 1 root root 1713 Oct 22 13:27 /var/log/lightdm/lightdm.log
<ogra_> no, that was about the time i flashed
<ogra_> so its from the current session (i didnt reboot yet)
<didrocks> xnox: it's image 2 in trusty-proposed btw
<xnox> didrocks: ack, let me flash that.
<didrocks> thanks
 * mlankhorst pokes alf_ with a testing stick
<alf_> mlankhorst: it works fine so far :)
<alan_g> alf_: is that nested+gbm?
<alf_> alan_g: yes
<alan_g> Progress! \o/
<mlankhorst> thought so
<mlankhorst> the lookup extension to lookup a bo from inside the screen context is still broken, but I have no idea where it's used
<mlankhorst> EGLImageTargetTexture2D, EGLImageTargetRenderbufferStorage probably
<mhall119> tvoss: should I remove all libhybris-* packages?
<tvoss> mhall119, yup, ideally
<mhall119> ok
<mlankhorst> hm probably not
<alan_g> alf_: raii fixed. ;) (tvoss spotted the obvious error)
<tvoss> alan_g, \o/
<alf_> alan_g: tvoss: great!
<mterry> alf_, hello!  You're working on nested Mir mode?
<mterry> whoops, got disconnected.  alf_, if you replied I missed it.
<alan_g> mterry: you didn't and he is
<mterry> alan_g, cool, I have things to discuss then, when he gets back
 * mterry is paranoid with this bad connection
<ogra_> time that we get reliable tethering with ubuntu phone ;)
<mterry> Heh
<dandrader> racarr, ping
<kgunn> dandrader: what did you need ?
<dandrader> kgunn, talk about https://code.launchpad.net/~dandrader/mir/uniqueTouchIds/+merge/191695/comments/441723
<kgunn> dandrader: ah...kind a need racarr for that
<racarr> Hi....yes sorry
<racarr> Kind of sick
<racarr> *stares blankly at screen*
<dandrader> racarr, so, wanna have a chat about that branch?
<racarr> dandrader: Not now....sorry the longer I stay out of bed the more sick I am feeling and I think I am going
<racarr> back to rest
<dandrader> racarr, ok, np
#ubuntu-mir 2013-10-23
<kgunn> duflu: do you know if FSM stand for "finite state machine" in the context of this bp ? https://blueprints.launchpad.net/ubuntu/+spec/client-1404-mir-rootlessx
<duflu> kgunn: Sounds like a good guess :)
<duflu> I don't know any other "FSM"
<duflu> I think the "synaptics FSM" is something I've proposed fixes to in the past actually. The touch stuff is obviously a state machine
<duflu> kgunn: I'd just note Synaptics is a brand and most devices using that code are not Synaptics. So maybe libsomethingelse is more appropriate.
<duflu> It would be awesome if more devices used Synamtics, but seems more common are the cheaper Alps and Elan
<tvoss> duflu, you ok with me top-approving https://code.launchpad.net/~vanvugt/mir/fix-r1049-regressions/+merge/191776
<tvoss> ?
<duflu> tvoss: Yep
<tvoss> duflu, done
 * tvoss -> airport
<duflu> alf_: Froze?
<alf_> duflu: yes, back again
<duflu> alf_: OK, meeting done I guess
<duflu> alf_: I've never used a GL context in two threads simultaneously before like Mir does. How safe is it?
<duflu> alf_: Oh. Apparently very safe as each DisplayBuffer gets a separate context :)
<alf_> duflu: Mir uses different shared contexts in different threads, which is safe. The only caveat is that you need to synchronize the creation of resource ids (e.g. textures)
<duflu> alf_: Yes it was the texturing that worried me. But that's OK if it really is a separate context per display
<duflu> alf_: Seen this? 1234563
<duflu> bug 1234563
<ubot5> bug 1234563 in Mir "mir_demo_standalone_render_surfaces crashes in glDrawArrays" [Medium,Triaged] https://launchpad.net/bugs/1234563
<alf_> duflu: let me try... is it consistently reproducible?
<duflu> alf_: On saucy desktop it seems. Even after a full reinstall
<alf_> duflu: confirmed
<duflu> Joy
<duflu> Huh. That race condition I thought I saw... would only exist if display buffer compositors shared a renderer. But they don't
<duflu> Sigh. Maybe I can make better progress in the kitchen than I have in code today.
<mterry> alf_, hello!  You around?
<alf_> mterry: Hi!
<mterry> alf_, OK, I have questions for you and/or alan_g about nested Mir...
<alan_g> mterry: ask it then
<mterry> alf_, so I tried to get a unity8 shell to talk to USC using the new-style MIR_SOCKET=fd://XX mode
<mterry> And I ran into an error about Mir connection not being made.  Upon investigation, it seems like qtubuntu and friends are designed for either being mirserver or mirclient, but not both.  So I manually put in a mir_connect() call into unity8 for testing
<mterry> Which presumably consumes the MIR_SOCKET fd.  But then it looks like part of qtubuntu does later want to use MIR_SOCKET for its server parts later
<mterry> And I get a Bad file descriptor error
<alan_g> mterry: there's an example of using the fd mode in the mir_demo_server_basic example.
<mterry> alf_, alan_g: I guess my question is, have you guys only tested on pure Mir, or have you actually got a qtubuntu-using app to do nested server mode?
<alan_g> I'm not sure what you're doing with USC - I know robert_ansell was working on it at one point
<alan_g> mterry: we've only done testing with the mir_demo_*
<mterry> alan_g, yeah he was.  USC is basically just the root Mir server.  He's got some branches where it talks to lightdm and passes back fds for lightdm to hand to other sessions as MIR_SOCKET
<alf_> mterry: a qtubuntu app shouldn't care about whether it is talking to a nested or host server
<mterry> I'm using those.  It seems to work a little bit, but qtubuntu doesn't anticipate this use case, and I'm trying to see the easiest way to make it work
<alf_> mterry: or in this case app==unity8?
<mterry> alf_, app==unity8
<mterry> alf_, there are ubuntumirclient and ubuntumirserver QPA plugins.  And they each seem to assume it's only client or only server
<mterry> I can propose a fix, I just am still uncertain what that fix is yet.  I guess I'll look at the demo code.
<alf_> mterry: why does unity8 need both ubuntumirclient and ubuntmirserver? It does all the rendering in-process so ubuntumirserver should be the only one it needs. Mir hides the details of being nested or not.
<mterry> alf_, well, I guess that's my problem.  It doesn't seem to
<alan_g> mterry: does unity8 use both plugins in the non-nested case?
<alan_g> Because it shouldn't know anything about being nested
<mterry> alan_g, alf_: sorry, got disconnected.  Not sure what you saw latest.  But:  should a nested Mir need to call mir_connect?
<mterry> (on app/shell-side code)
<alan_g> mterry: no
<mterry> alan_g, OK.  So my error I saw was probably unity-mir making assumptions and calling a piece of Mir code that required mir_connect...  I'll dig into that side of things
<mterry> Rather than go down the road of calling mir_connect myself
<alan_g> mterry: it shouldn't do anything differently than in the standalone case
<mterry> alan_g, OK, good to know
<racarr> Good mirning!
<alan_g> Good afternoon
<mterry> alan_g, so during mir::run_mir (called by unity-mir), I'm getting that "connect not called" error.  I think during DisplayServer construction.  I wouldn't expect such an error during a mir-internal call, right?
<mterry> alf_, ^
<alan_g> mterry: just looking for whre that comes from
<mterry> sure
<alf_> mterry: it sounds like mir is using the nested path, but something isn't going as expected
<alan_g> mterry: sounds like the connection doesn't get established. Does the fd actually exist in the nested process?
<mterry> alan_g, theoretically.  robert_ancell's branches do some clever fd passing around to make sure.  What posix call tests fd existence?
<alan_g> mterry: is it feasible to launch unity8 using mir_demo_server_basic --launch-client unity8 - and avoid USC?
<alan_g> Or does it need some other setup?
<mterry> alan_g, I could, as a test, sure.  Let me get back to you
<alan_g> mterry: obviously you need any switches to get it into nested mode
<mterry> alan_g, well, mir_demo_server_basic sets MIR_SOCKET, right?  That should auto-switch to nested-mode.
<racarr> fcntl(fd, F_GETFD is the FD test
<mterry> racarr, ah cool.  I'll test that after this demo server test
<alan_g> mterry: It does - I just didn't know if that was all you need
<alan_g> racarr: Maybe we should use that to give a more helpful error message.
<racarr> Seems useful.
<racarr> The way the platform-api symbols are is a little weird for stuff like this
<racarr> if you accidentally link libplatform-api-mirclient and libplatform-api-mirserver (nested unity8 shouldn't need platform API mirclient)
<racarr> I guess you are going to get the wrong symbols?
<racarr> maybe not, because we have the two different build QPAs with explicit linkage that are opened at runtime...
<racarr> not sure how Qt loads them
<racarr> *shrug*
<mterry> alan_g, going through the demo, I get "Address already in use"...
<mterry> alan_g, in about the same spot (DisplayServer constructor)
<alan_g> mterry: try mir_demo_server_basic --standalone etc
<mterry> alan_g, the server should fallback to standalone, since it doesn't have MIR_SOCKET, but ok
<mterry> I'll also add --no-file
<alan_g> mterry: Doh! that's the one I was thinking of
<mterry> alan_g, aha!  OK.  That worked with --no-file.  So the fd being bad somehow leads to the "mir not connected" message?
<mterry> alan_g, so lightdm/usc must be fucking up the fd passing
<alan_g> mterry: It seems that way - but Mir should be giving a better diagnostic
<alan_g> I suspect it is hanging  (or failing in some other bad way) in the connect call to a duff socket
 * alan_g thinks he should log a bug
<racarr> perhaps old news to other people but I finally figured out how to get a a good terminal on the phone. lol. adb shell is always weird with some terminal programs (i.e. text editors tend to not work). ssh over nexus 4 wifi sucks
<racarr> adb shell service ssh start
<racarr> is where it's at
<racarr> adb forward tcp:2222 tcp:22
<racarr> adb forward tcp:3768 tcp:3768
<racarr> ssh phablet@127.0.0.1 -p 2222
<racarr> err ignore the 3768
<racarr> thats some unity qml debug stuff lol
<alf_> kdub: @display-construction-overhaul2, do we need to access the native types outside of any of the other resources created with them?
<kdub> the fb and the hwc?
<alf_> kdub: yes the native android types
<kdub> i don't think so (if i understand the question properly :) )
<racarr> kdub: DisplayCommander, nice
<kdub> hah :) i like that one too
<alan_g> greyback: it's not immediately obvious to me which packages I need to compile unity-mir - so could you answer a quick question? Why does src/unity-mir/surfacecontroller.cpp need the line "#include <mir/surfaces/surface_stack_model.h>"? AFAICS it never uses the SurfaceStackModel definition.
<greyback> alan_g:  "sudo mk-build-deps -ir debian/control" should install what you need, no?
<alan_g> greyback: ack was just remembering that
<greyback> alan_g: it's needed for the constructor of the SurfaceController, so ms::SurfaceStackModel is defined
<alan_g> But it only needs a declaration
<kdub> greyback, haven't tried in a while, but have we sorted out how to cross compile those components?
<kdub> apologies for asking again :)
<alan_g> greyback: I still see "qmirserverapplication.h:20:27: fatal error: QGuiApplication: No such file or directory"
<greyback> kdub: tbh I've not tried since you last asked. But I agree we need to solve this story. A properly working pbuilder arm chroot would be very nice
<greyback> alan_g: have you "qtbase5-dev" installed?
<alan_g> greyback: yes
<greyback> alan_g: make clean, re-run 'qmake' and see if that works
<greyback> and make ofc
<alan_g> greyback: no change (and no target ofc)
<alan_g> greyback: I'm hitting EOD anyway. Maybe it will work in the morning. (But I'm pretty sure that header isn't needed)
<greyback> alan_g: ok, talk tomorrow
<greyback> alan_g|EOD: if I remove that header, it fails to build.
<alan_g|EOD> What's the error?
<alan_g|EOD> greyback: What's the error?
<greyback> alan_g|EOD: error: invalid use of incomplete type 'class mir::surfaces::SurfaceStackModel'
<greyback> alan_g|EOD: EOD, we can deal with this tomorrow :)
<greyback> sorry :D
<alan_g|EOD> np
 * alan_g|EOD wishes for the line number. But has to take wife out to eat. ;)
<kdub> racarr, (just bouncing naming suggestions around), how about "MonitorTraits" instead of "DisplayInfo"
<racarr> kdub: I don't like monitor because monitors don
<racarr> 't have a number_of_framebuffers_available
<racarr> which is why I thought Output was nice.
<kdub> yeah, but output is pretty overloaded
<racarr> hmm
<racarr> I think within the mga:: namespace it's relatively clear, Mir, graphics, android, output attributes
<racarr> but not totally.
<racarr> I didn't think DisplayInfo was that unclear
<racarr> I think Attributes...to me carries a little more connotation that this is the configured information (i.e. the configured size, etc)
<racarr> and not just the capabilities
<racarr> which I think of as 'Info' but I'm not sure if the dictionary would back me up on that one aha
<racarr> I think maybe it's just a struct instead of an interface
<racarr> kdub: Hmm
<racarr> is it just
<racarr> the DisplayConfiguration?
<kdub> eh, not quite
<racarr> why?
<kdub> i'd say a configuration would be the most expansive, so would include multimonitor configuration
<racarr> an OutputConfiguration then perhaps
<kdub> lets see what terms gbm has..
<racarr> I mean, it's the configuration of a single display/output/monitor and some properties which resutl from that configuration (i.e. number of framebuffers available)
<racarr> but the thing is, presumably in multimonitor scenarios
<racarr> this changes
<racarr> which is why I thought the word "Configuration" might make sense
<racarr> you don't expect the information for a display to change but of course the configuration does
<kdub> in multimonitor, it doesn't change
<kdub> its just the class for the attributes/traits of each monitor
<racarr> kdub: Are you sure? I mean
<racarr> if I have an external display hooked up
<racarr> am I guaranteed the same number of framebuffers
<racarr> at various resolutions etc
<racarr> also...the size can change right?
<kdub> size can't really change
<racarr> oh yeah
<racarr> I forgot android hal doesn't really do sophisticated monitor configuration
<racarr> kdub: I will let it toss around in my head a little more...DisplayInfo isn't bad though
<racarr> I do think that a struct with constant data members
<racarr> is perhaps a little more clear
<racarr> because it's more like just some immutable piece of info than an object right
<kdub> eh, have to think about that
<kdub> essentially, thats what it is already
<racarr> ? from the consumer perspective the values can chance
<racarr> change
<racarr> they are just const member functions now right? or did I misread
<kdub> they are const member functions
<kdub> even at that though, i'd rather have the interface
<racarr> I think it's better to enforce the immutability, and the struct is a little better for tests
<racarr> because you don't have to write these, mock the interface, set the getter functions to return values
<racarr> type tests...which I think
<racarr> are more strong coupling than good tests
<racarr> in many cases
<kdub> it makes for more test structure, but doesn't increase coupling in the production code
<kdub> if i want to rename a struct member vs rename a class function, same amount of churn
<kdub> i guess i could make a struct with its copy/assign deleted
<racarr> kdub: Except, you don't have to update the tests that are passing in literals like {size, format, number}
<racarr> I mean if you were writing the test first, you wouldn't write some class like Stub or MockDisplayInfo and set it up to return the three const values right
<racarr> you would pass them as a literal tuple to the consumer
<racarr> and then verify the state
<racarr> as opposed to the interaction (consumer calls get_size(), which really isn't actually very interesting)
<kdub> i'm sure i did just that at one point, but i probably wrote the DisplayInfo tests before the other ones
<racarr> :) I mean at this point with an existing code base, and refactoring v new stuff writing the tests first of course becomes blurry
<racarr> but I just mean, in the ideal, if you were sitting down to write some new class
<racarr> and you knew it needed to do some computation based on the display size, pixel format, and number of frame buffers
<racarr> well I feel like I would probably use a struct and literals and not an interface
<racarr> but *shrug*
<kdub> i guess i have to program that struct in different ways
<kdub> and don't know if i want to have two constructors for the struct
<racarr> ? If the values don't change shouldn't you initialize it with
<racarr> the values themselves
<racarr> and not the objects which contain the state
<kdub> these classes are wrappers around two different HAL's (which actually own the state)
<kdub> HWCInfo does a bit more than FBInfo
<racarr> kdub: That seems kind of strange to me and it feels more like two different objects using the HALs should pack the same kind of struct
<racarr> but
<racarr> I will do a deeper read of the code
<racarr> and comment on launchpad
<racarr> because im not sure exactly how it all links up
<racarr> I think it's something about powerd with the android integration tests failing
<racarr> kdub: The symtoms are pretty weird. If you 'stop unity8' while the screen is blanked...about 9/10 times
<racarr> integration tests will then fail with the error to post to fb device
<racarr> unity8 will not start back, etc
<kdub> yeah, i'm not convinced we have that architecture worked out just yet
<racarr> if you press power button, even though unity8 is dead
<racarr> something happens
<racarr> because now the integration tests will all pass
<racarr> except the binary will hang while exiting
<racarr> and that's as far as I've gotten
<racarr> you cant kill it at that point lol
<racarr> reading through powerd now
<racarr> static void update_internal_state(void)
<racarr> ....
<racarr> ....
<racarr> that is not the best function name ;)
<kdub> racarr, you know how to use powerd-cli?
<racarr> kdub: Oh. I sort of do now :p
<racarr> kdub: Maybe I dont :p I was hoping to turn the display on with it
<racarr> but it hangs
<kdub> i just do 'powerd-cli display on', seems to work
<racarr> kdub: After stopping unity8 while the display was off?
<kdub> i just do that to keep the display on once its gotten to the on state
<racarr> oh I see
#ubuntu-mir 2013-10-24
<duflu> didrocks: I've updated lp:mir and it is now at tagged release 0.1.0, awaiting packaging (and changelog entries)
<didrocks> duflu: ok, we'll probably ship it today
<duflu> I'd be interested to see how well the automagical changelog population works, given we usually forget "--fixes lp:NNNN"
<didrocks> duflu: did you add bug #<foo> in the commit message?
<didrocks> or bug blalabla
<didrocks> or any regexp with either lp.* or bug.* ?
<didrocks> (attaching the bug to the MP before it's merged works as well)
<duflu> didrocks: I do. And where other people forget I often fix their commit messages. But I don't catch all of them
<didrocks> duflu: for those then, it should be fine
<alf_> duflu: didrocks: Have the trusty repositories opened? Is it recommendend that we move to it now?
<didrocks> alf_: indeed, they are opened since Monday (see ubuntu-devel ML)
<didrocks> alf_: since are still settling down, you should wait for a week to keep being productive I would say
<didrocks> (after the first debian sync pass is done)
<alf_> didrocks: sounds sensible, thanks :)
<didrocks> yw!
<Saviq> duflu, https://bugs.launchpad.net/unity8/+bug/1239876/comments/5 ?
<ubot5> Ubuntu bug 1239876 in Unity 8 "[enhancement] Need to signal when mir is ready for upstart dependencies to wait for" [High,In progress]
<duflu> Saviq: The bug status is accurate if you look up the top. Fix Released in 0.1.0 and later
<Saviq> duflu, since when "Fix released" == "Is going to be released"?
<Saviq> duflu, I thought "Fix committed" + milestion == "Is going to be released with version x"
<duflu> Saviq: It's fix released in the upstream project release 0.1.0 and correctly says Fix Committed for Ubuntu
<duflu> Saviq: The first Ubuntu build of 0.1.0 is coming today I think
<Saviq> duflu, ah, didn't know you guys got upstream releases other than ubuntu...
<duflu> Saviq: Yeah they're separate branches so need separate status to be accurate
<Saviq> duflu, ok, sorry for the noise
<duflu> Saviq: No problem. You can expect (hopefully) accurate status info from now on. At least better than in the past
<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
<duflu> Saviq: If you have only one branch it makes sense. But Mir is stuck with two "trunks", which is what distro wants
<didrocks> distro doesn't wants 2 trunks, distro just want one trunk with good packaging syncing practice
<didrocks> and stability in the interface
<didrocks> (quite a big difference, we don't impose the how, just the end)
<duflu> didrocks: +1
<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
<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
<Mirv> it seems it's probably not updated for the new libmirserver?
<Mirv> "mir/pause_resume_listener.h: No such file or directory"
<Mirv> so I guess mterry's branch, could you get that merged?
<Mirv> https://code.launchpad.net/~mterry/unity-system-compositor/mir-fixes
<Mirv> bug #1244131
<ubot5> bug 1244131 in Unity System Compositor "unity-system-compositor FTBFS on trusty against new Mir" [Critical,New] https://launchpad.net/bugs/1244131
<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
<greyback> alan_g: glad to hear.
<alan_g> greyback: although I still get some linker errors - but I'll worry about that another time
<alan_g> greyback: It would be really nice for my code cleanup in Mir  to remove that dependency in unity-mir
<greyback> alan_g: sure, I'm trying it out now
<greyback> alan_g: I'm just thinking of ramifications of having SurfaceStackModel a Mir internal concept
<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.
<Mirv> we can't release the mir stack without u-s-c, so if you can please check the bug above
<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
<Mirv> bug #1244192 - I assigned it to mterry already
<ubot5> bug 1244192 in Unity System Compositor "unity-system-compositor FTBFS on trusty against new Mir (libmirserver9)" [Critical,New] https://launchpad.net/bugs/1244192
<Mirv> 'mir::DefaultConfigurationOptions' is not an accessible base of 'const SystemCompositorServerConfiguration'
<alf_> alan_g: updated lient-drm-add-gbm-device
<alf_> +c
<alan_g> alf_: looking...
<alan_g> alf_: Now we re-implement std::ceil()?!
<alf_> alan_g: it's division with ceiling without involving floating points, not the same thing :)
<didrocks> alf_: alan_g: can you look at Mirv's messages? we are totally blocking the whole line because of Mir
<alan_g> didrocks: ok - let me grab usc
<didrocks> thanks!
<didrocks> on the client one? is it xorg still compatible? just needing a rebuild?
<alf_> didrocks: are you referring to xmir?
<didrocks> right
<didrocks> as the client bump wasn't coordinated, we are going to revert mir landing (as well as platform-api, and unity-mir)
<alf_> didrocks: yes, xmir shouldn't be affected by any of the changes done lately
<didrocks> alf_: so a rebuild for the soname bump?
<alf_> didrocks: it should be enough
<alan_g> Mirv: didrocks https://code.launchpad.net/~alan-griffiths/mir/fix-1244192/+merge/192503
<didrocks> alan_g: great! thanks for fixing, I think alf_ can maybe review and test build u-s-c with it?
<alf_> didrocks: will do
 * alan_g wonders if we should roll usc into the mir source tree
<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
<alan_g> alf_: it's half a dozen files - almost an example program. ;)
<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
<alf_> mterry: sure, what's the quickest way to reproduce what you are seeing?
<mterry> alf_, that's actually not even a little easy right now.  Do you have time?
<alf_> mterry: yes
 * mterry hugs alf_
<mterry> alf_, ok, let me get my notes
<mterry> alf_, so I've been working on the phone itself.  If you have a suitable emulation environment or something, that could work too
<alf_> mterry: ok
<mterry> alf_, you'll want lp:~mterry/mir/named-session
<mterry> alf_, lp:~mterry/lightdm/named-sessions with lp:~robert-ancell/lightdm/private-mir-connection mixed in
<mterry> alf_, and lp:~robert-ancell/unity-system-compositor/private-mir-connection
<mterry> alf_, ooh, you know
<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
<mterry> alf_, my env is deep in the weeds, but I suspect we don't need everything
<mterry> alf_, so we'll just use robert-ancell's two branches (lightdm and unity-system-compositor)
<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.
<mterry> alf_, fair enough...  Let me put something up on people.canonical.com
<alf_> mterry: (btw, I am using N4)
<mterry> alf_, ok, cool, me too
<alf_> mterry: also, are you using mir development or the package version?
<mterry> alf_, trunk
<mterry> alf_, I think?  I can't remember when I branched
<mterry> alf_, I branched a week ago?
<alf_> mterry: do you have the revision to ensure we are in sync?
<mterry> alf_, 1102
<alf_> mterry: great, thanks
<mterry> alf_, but...  if I'm giving you my lightdm deb file, you'll probably want my named-session mir branch
<mterry> alf_, because lightdm passes a new mir argument
<alf_> mterry: ok
<mterry> alf_, OK, try the debs in http://people.canonical.com/~mterry/
<mterry> alf_, plus your built named-sessions mir branch
<alf_> mterry: ok I think I am set up
<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
<alf_> mterry: is there a way to run this manually?
<alf_> mterry: (i.e., without restarting so I can debug it live if needed?)
<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
<alf_> mterry: I guess 'start lightdm' would have the same effect right? At least to avoid the restart.
<mterry> alf_, yes.....  except I have run into issues in the past with Mir handling that gracefully
<mterry> alf_, so I've gotten into the habit of rebooting
<mterry> Or, maybe not Mir's fault, but something between powerd/unity8/Mir.  Those annoying errors with Mir coming up
<mterry> How do I get mir to write to a "report"?   I see a lot of report->something() calls that look like advanced logging
<mterry> nm, found doc/component_reports.md
<dandrader> racarr, ping
<dandrader> racarr, https://docs.google.com/a/canonical.com/document/d/1LEq6Z9niZR5ITka0QixBu8B5fJPv03MmcW1uNgA2bWg/edit?usp=sharing
<racarr> kdub: I found which portion of powerd is messing with us (see last comment here https://bugs.launchpad.net/mir/+bug/1239955)
<ubot5> Ubuntu bug 1239955 in Mir "integration-tests hang/fail in AndroidGPUDisplay.gpu_display_ok_with_gles when the display is asleep: what(): error posting with fb device" [Medium,Triaged]
<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
<kdub> racarr, i agree on all those points :)
<racarr> maybe the fix is actually
<racarr> elsewhere! for unity, things work because unity talks to powerd
<racarr> for the tests, the tests can include wrappers on CI that just run powerd-cli active
<racarr> and thats fine
<racarr> the only remaining problem, is its inconveient to just
<racarr> adb shell in and run
<racarr> mir_demo_server_shell
<racarr> for developers, etc
<racarr> but we could have
<racarr> an open shell
<racarr> hold the active state
<racarr> or
<racarr> I dunno
<kdub> yeah, its a gotcha for the developers
<sil2100> Hi guys
<racarr> hi :)
<sil2100> Soooo
<sil2100> https://launchpad.net/~ubuntu-unity/+archive/daily-build/+build/5158273 <- we're getting this here in the daily-build PPA
<sil2100> Does anyone know why this dependency wait happens?
<sil2100> We're building mir from trunk, so I guess we have the latest of the latest?
<sil2100> Did you guys forget to bump the upstream version of mir?
<sil2100> Actually, I see the bump in trunk, wonder what cu2d is doing
#ubuntu-mir 2013-10-25
<Mirv> forget sil2100's messages, he was too tired to remember the PPA does not have the mir now :)
<alan_g> duflu: alf_ - anyone object to me merging https://code.launchpad.net/~alan-griffiths/mir/fix-1244192/+merge/192503 by hand as CI seems so reluctant?
<duflu> alan_g: So long as the failure is spurious. I don't understand what the "android i386" platform is...
<alan_g> duflu: I'll ask about it when fginther comes online - it certainly has nothing to do with the change
<duflu> alan_g: If it really is unrelated, retrying should eventually work. Because other proposals are succeeding
<alan_g> duflu: I know - I'll give it one more try...
<duflu> alan_g: I just had another quick look at "fixing" render_surfaces to not reference mir::surfaces::. It would seem that we first need surfaces::Surface to implement shell::Surface. Are you still planning on trying that?
<alan_g> duflu: I think that something like that is needed. But there's a lot of "low hanging fruit" to clear before getting to that.
<duflu> alan_g: Let me know if and when you start. Otherwise I may... but not this week
<alan_g> duflu: ok
 * duflu is buried in said fruit
 * alan_g laughs
<duflu> Maybe that's why I feel sticky
<alan_g> alf_: It would be easier to remove report implementation classes from public if I rolled logging and lttng into a "reporting" component. Does that work for you?
<alf_> alan_g: no objections
<alan_g> alf_: Good. I think I'll leave it until the next pass - I don't want to start controversy over the simpler stuff.
<kgunn> alf_: hey can we ask for a big favor ?
<kgunn> alf_: can you test lp:mir/trusty against xmir ? (which will require a rebuild of xserver-xorg-xmir)
<alf_> kgunn: do you want to know if it works or if it builds?
<kgunn> alf_: it should in theory
<kgunn> alf_: duflu bumped the client api....
<kgunn> alf_: so to make sure we didn't break just need some sanity
<alf_> kgunn: so which one works or just builds against? :)
<alan_g> alf_: as much as possible
<alf_> alan_g: ok, "builds" it is then...
<kgunn> alf_: question is can you also create packages for upload (xserver-xorg-xmir)
<kgunn> as didrocks would like to have those
<kgunn> to release as well
<kgunn> i suppose we usually rely on RAOF for this...part...but as he's not in or going to be in till monday....
<didrocks> kgunn: oh, not for me, it's more for you :)
<didrocks> alf_: kgunn: if you tell me a rebuild is enough and your tests are fine, I'll handle the upload of xserver-xorg-xmir to the archive when we release Mir
<kgunn> didrocks: well yeah :).... alf_  in effect we can't release/update mir without it
<kgunn> didrocks: ping
<didrocks> kgunn: pong
<didrocks> kgunn: cyphermox is going to continue helping you btw (as it's nearly EOW for me)
<kgunn> didrocks: ack... alf_ had to go as well
<didrocks> kgunn: do you think there is still hope before EOW?
<kgunn> didrocks: i am doubting...but chris will be in on sunday u.s. time
<kgunn> didrocks: is that ok ?
<kgunn> otherwise i'll see if bschaefer might be able to help us out...
<bschaefer> hey, whats up?
<kgunn> bschaefer: have you ever built the xorg packages for xmir ?
<didrocks> kgunn: well, it's still delaying all the landings for the rest, but I think we don't have that much choice
<bschaefer> hmm no i've not
<kgunn> mlankhorst: ^ ? ...are you EOW'ing soon  :)
<didrocks> kgunn: I hope we can get some confirmation at least on Monday once sil2100 start to wake up :)
 * kgunn asks sheepishly
<kgunn> didrocks: that should be totally do-able
<didrocks> kgunn: he did EOW yesterday I guess
<didrocks> kgunn: again, if you have a ppa with latest mir, unity-mir and so onâ¦ I can upload xserver-xorg-xmir for you
<didrocks> (then, leaving up the tests to you)
<kgunn> didrocks: oh wait...are you saying you have them built ? we just need to test ?
<didrocks> kgunn: no, I'm telling that if you have a ppa with mir and all the rest built, I can build xserver-xorg-xmir in it
<kgunn> didrocks: ah....we should https://launchpad.net/~mir-team/+archive/staging
<kgunn> can cyphermox do the same? (e.g. build xmir for us if we get those packages updated) didrocks
<didrocks> kgunn: hum, it's rev 1153, from 3 days behind
<didrocks> so without this ABI bump
<kgunn> didrocks: right...we need to update
<didrocks> kgunn: doing it for you, both mir, u-s-c and xserver-xorg-xmir
<didrocks> kgunn: but you need to spread this knowledge within the team, please ;)
<kgunn> didrocks: yep
<didrocks> kgunn: you have alf, mterry and RAOF who can help spreading it I guess :)
<didrocks> urgh
<didrocks> 0.1.0bzr1153trusty0
 * mterry looks up
<didrocks> the version is horribleâ¦
<didrocks> oh, there is a mterry
<didrocks> he can do it as well ;)
<didrocks> mterry: https://launchpad.net/~mir-team/+archive/staging needing latest mir, u-s-c and rebuild xserver-xorg-xmir
<mterry> didrocks, you mean those packages need mir-version bumps?
<mterry> i.e. that's not a manual upload PPA is it?
<didrocks> mterry: it guess the version will have to be 0.1.0bzr1161trusty1
<didrocks> mterry: I guess nothing uploads to there anymore
<didrocks> as you pull to trunk
<didrocks> and not merged
<didrocks> mterry: so, manual uploads are needed
<didrocks> (on trusty)
<didrocks> so first mir, then u-s-c and xserver-xorg-xmir
<mterry> "pull to trunk and not merged"
<mterry> ?
<mterry> didrocks, sorry, I guess I'm out of loop.  Why is this outside our normal infrastructure?
<didrocks> mterry: yeah, you bzr pull dev to trunk
<didrocks> mterry: on duflu's request
<didrocks> mterry: I agree, we should get the mir team back to the way other teams are working
<kgunn> mterry: i'll fwd you the thread
<didrocks> kgunn: TBH, I didn't anticipate this side-effects on the ppa not being updated neither
<mlankhorst> kgunn: already done for the week on thursday
<kgunn> mlankhorst: ok, get back to enjoying weekedn
<mterry> didrocks, well anyway.  You're asking me to take trunk of those packages and upload to that PPA?  I can do that...
<didrocks> mterry: yes please ;)
<didrocks> (ensure the xmir package builds against latest mir of course)
<didrocks> then I guess kgunn will trap someone to test it
<mterry> didrocks, pfft, that's what staging PPAs are for!
<kgunn> mterry: if you do it i am thankful..... are you simply "dput ppa:your-lp-id/ppa <source.changes>"
<didrocks> mterry: isn't it? :p
<didrocks> kgunn: can you ensure sil2100 is aware about the result on Monday?
<mterry> kgunn, basically
<kgunn> didrocks: will trap someone somewhere yes
<didrocks> as he's not travelling and stay in the EU time, we can win half a day
<kgunn> mterry: can you enlighten me so i can help in the future
<mterry> didrocks, you want a particular version?
<kgunn> mterry: latest trunk (which is lp:mir/trusty
<mterry> kgunn, sure, but I meant package version
<mterry> kgunn, enlighten you on the steps?  I'm just planning on doing bzr branch; debuild -S -sa -i -I; dput
<mterry> with some minor changelog modification to make sure that they say trusty and such instead of UNRELEASED
<sil2100> ;)
<mterry> didrocks, just to clarify, you just want a rebuild of xorg-server, not a fresh-trunk build, right?
<didrocks> mterry: for xorg-server, yeah, a rebuild against latest mir you are/did upload
<didrocks> and of course the rebuild of u-s-c against this latest mir for the ABI break
<didrocks> so that kgunn finds the victim to test all 3 of them on the desktop :)
<mterry> didrocks, yup, I'm pulling mir and usc trunk.  but only xorg-server trusty packaging
<didrocks> right!
<kgunn> robotfuel: ^ if you're looking for something to do :)
<kgunn> robotfuel: you could run xmir testing, even just locally.... after mterry finishes
<kgunn> bschaefer: ^
<robotfuel> kgunn: I am working on porting autopilot apps to from 1.3 to 1.4, but I am suppose to give mir priority so I'll do it. :)
<robotfuel> what am I waiting for mterry to land?
<robotfuel> kgunn: mterry^
<mterry> robotfuel, a new mir/u-s-c/xorg in mir-team/staging
<mterry> robotfuel, just waiting for builds now.  I can ping you
<mterry> robotfuel, in particular, if you can just make sure that xmir still works fine
<robotfuel> mterry: which ppa? I can setup jenkins to get something more interesting that just works
<kgunn> robotfuel: it'll be the mir packages for trusty that are in ~mir-team/staging
<mterry> So...  Mir trunk is failing the test ServerShutdown.server_removes_endpoint_on_abort  -- anyone else seeing it?
<mterry> racarr, ^ ?
<mterry> kgunn, ^
<mterry> not just that test...
<mterry> https://launchpadlibrarian.net/154994415/buildlog_ubuntu-trusty-i386.mir_0.1.0bzr1153trusty1_FAILEDTOBUILD.txt.gz
<mterry> I'm not sure who to ask about these
<mterry> kdub, ? ^
<kdub> i don't know anything specifically, i can test though
<racarr|sick> warnings of sickness from earlier became fever last night
<racarr|sick> woke up to eat food. back to not moving now though :p
<olli> get better racarr|sick
<kgunn> kdub: thanks if you can help fix the failures
<mterry> kgunn, kdub, sorry may have missed some talk about the test failures.  Can you look at them?
<kgunn> mterry: did you happen to run tests locally ?
<mterry> kgunn, not yet, let me do so now
<kdub> trunk passed for me
<kdub> well :) ~mir-team/mir/development-branch
<kdub> but then again, im on saucy, maybe it has something to do with trusty?
<kgunn> kdub: uh...can't imagine...but never know....can you try trunk ?
 * kgunn tries
<kgunn> kdub: mterry ... i'm able to run the test locally, several times just in case...no failures, wonder if its classic misleading ci failures
<mterry> kdub, I've been using lp:mir
<kgunn> mterry: did your local tests pass ?...if yes, then i would vote to update the ppa manually
<mterry> kgunn, well, that's what I did, but these are local build tests and the PPA build failed.  I could disable tests during build...
<mterry> kdub, kgunn: OK, I do get failures locally with lp:mir
<mterry> kgunn, my understanding was that didrocks was intending upload of lp:mir, not the development branch?
<kgunn> mterry: you amd64 or i386 ?
<mterry> kgunn, amd64
<kgunn> mterry: i'm also amd64....
<mterry> kgunn, but I didn't believe the buildd had a difference
<mterry> kgunn, did you build development-branch?
<kgunn> mterry: i built lp:mir
<kgunn> mterry: and didrocks uses lp:mir
<kgunn> not the dev branch
<mterry> kgunn, weird...
 * mterry is curious how kdub finds lp:mir
<kgunn> mterry: i haven't updated since yesterday (or maybe day before)....you ?
<mterry> kgunn, I updated yesterday I believe
 * kgunn updates now just in case
<kgunn> back in a minute
<robotfuel> the only failure I got was in the devel-branch was TestClientInput.hidden_clients_do_not_receive_pointer_events, which is know and logged here https://bugs.launchpad.net/mir/+bug/1227683
<ubot5> Ubuntu bug 1227683 in Mir "valgrind acceptance-tests FAIL: TestClientInput.hidden_clients_do_not_receive_pointer_events" [High,Triaged]
<robotfuel> but I was building in saucy
<robotfuel> https://jenkins.qa.ubuntu.com/job/mir-team-mir-development-branch-saucy-amd64-ci/243/console is the build log
<kdub> mterry, trunk looked okay to me too
<mterry> kdub, meaning lp:mir?
<mterry> kgunn, if development-branch works better, is that acceptable to upload to PPA?  Or are there changes there that we don't want yet?
<kdub> mterry, yes, lp:mir
<kgunn> hmm...he quit
<kgunn> rebooting myself
<mterry> whoops, got disconnected
<kgunn> mterry: to answer your question about development-branch vs lp:mir/trusty
<kgunn> technically they are one in the same...
<kgunn> at least dev branch is the source for lp:mir....
<kgunn> altho a little ahead
<kgunn> no one is supposed to mp target or push to lp:mir
<kgunn> only to dev branch
<kgunn> then we (semi)regularly update "trunk" (in this case trusty) with dev-branch
<mterry> kgunn, so I just updated again, trying once more locally.  If I fail again, I can disable tests, upload the brokenish Mir, just so we can at least test xmir against it.  I'm not sure we should promote it to trusty unless we can investigate the failures though
<kgunn> mterry: yeah...just sharing i updated locally, blew away build dir, rebuilt, retested a few times and all passing
<kgunn> mterry: are you falling reliably ?
<mterry> kgunn, looks like it
<kgunn> every run? 50% ?..?
<mterry> kgunn, for me so far, 2/2 failed, plus the one in the buildd
<kgunn> mterry: just to make sure we're all doing the same thing...when you test...you're in your local src dir/build & you run ctest
<mterry> kgunn, no these were debuild runds
<mterry> debuild runs
<mterry> kgunn, I can try local ctest too
<kgunn> kdub: ^
<mterry> but based on accounts, sounds like that would pass while a debuild would fail
<kgunn> mterry: how does it vary ?
<mterry> kgunn, could be environment variables or the way the tests are run..  not sure yet
<kgunn> kdub: how are you running ? ctest ?
<mterry> kgunn, ctest works for me
<mterry> kgunn, does running the following in the root dir work for you?
<mterry> GTEST_OUTPUT=xml:./ dh_auto_test --max-parallel=1
<mterry> That's what debuild runs
<kgunn> mterry: uh...so i export that /
<kgunn> ?
<kgunn> then run ctest ? or ?
<kgunn> sorry..i'm really dumb when it comes to incantations
<mterry> kgunn, no, not an export, that was just a variable set before calling dh_auto_test
<mterry> kgunn, dh_auto_test is the important part
<mterry> run dh_auto_test
<mterry> ... which ends up calling ctest
<mterry> and now when I cd into the build dir and manually run ctest I see a failure
<kgunn> mterry: i don't see anything when i run dh_auto_test
<kgunn> mterry: maybe its missing something from the debbuild ?
<mterry> kgunn, oh, you probably don't have the builddir it expects.. let me see
<mterry> kgunn, pass -B BUILDDIR
<kgunn> mterry: hmm, same thing...it just takes the command line...but no output
<mterry> kgunn, pass --verbose, maybe see what it's trying to do
<kgunn> kg@kg-MacBookPro:~/workspace/mir/trusty$ dh_auto_test -B BUILDDIR --verbose
<kgunn> kg@kg-MacBookPro:~/workspace/mir/trusty$
<kgunn> mterry: ^
<mterry> kgunn, huh.  Well, substitute BUILDDIR for whatever your builddir was
<kgunn> :)
<mterry> kgunn, but besides that might be some other debuild-y thing it expects
<kgunn> mterry: magic!
<mterry> really all it does is call ctest with --force-new-ctest-process -j1
<mterry> inside the builddir
<kgunn> mterry: hmm passed all tests 5 out of 5 attempts
<mterry> kgunn, stop having it work!
<kgunn> mterry: you on saucy or trusty on your machine
<mterry> kgunn, trusty
<kgunn> mterry: uh oh
<mterry> kgunn, you're on saucy?
<kgunn> mterry: let me got update
<kgunn> i know tsk tsk tsk
<mterry> kgunn, I can't...  I can't even look at you right now
<kgunn> mterry: i've brot shame to this house
<mterry> kgunn, I'm testing a small change now that might, maybe work.  It simply runs ctest without any arguments
<mterry> kdub, you were testing in trusty?
<kgunn> mterry: pretty sure he was saucy too....shame on us
 * mterry throws his hands up
<mterry> kgunn, that worked for me...
<mterry> kgunn, (just running ctest)
<mterry> kgunn, I don't understand it, but I'll upload it for now, we're still running the tests...
<kgunn> mterry: thanks...
<kgunn> mterry: so that's mir, u-s-c....and now i need to get cyphermox to build xserver ?
<kgunn> just making sure you weren't building xserver-xorg-xmir
<mterry> kgunn, oh I was intending to upload that too yeah
<mterry> kgunn, just had to wait for mir to finish first, but it never did
<kgunn> mterry: oh...ok
<mterry> kgunn, are we still going to have people to test it?
<cyphermox> mterry: you mean me?
<cyphermox> what do you mean you'll upload though?
<cyphermox> where are you uploading?
<mterry> cyphermox, ppa:mir-team/staging
<cyphermox> ah, cool
<mterry> cyphermox, right now just mir, but next usc and xorg
<cyphermox> yeah
<cyphermox> ok so I'll wait for you to rebuild those in the PPA, then I'll install the packages and kick off some quick testing
<mterry> cyphermox, you're a guinea pig?
 * mterry hugs cyphermox
<cyphermox> then I need to rebuild all of that and xserver-xorg-xmir and run full autopilot tests of everything before releasing to the archive ;)
<kdub> mterry, not in trusty
<kgunn> mterry: cyphermox ....sorry, huge interruption, daughters roommate...bill paying...awesome
<cyphermox> not in trusty?
<kgunn> bschaefer: ^ actually, when mterry hits up the ppa with new mir, usc, & xorg can you test xmir ?...mainly unity7 comes up and doesn't fall over
<kgunn>  :)
<bschaefer> kgunn, sure!
 * bschaefer hasn't used xmir for a bit now though
<kgunn> bschaefer: thanks man!....if you succeed just email
<mterry> bschaefer, cyphermox: I'll poke you guys when ready
<bschaefer> mterry, cool, thanks!
<bschaefer> kgunn, and will do
<cyphermox> mterry: alright, thanks!
<mterry> kgunn, after I upload and assuming tests are good, is that all you need from me?
<kgunn> bschaefer: i know...kinda scary wading into the xmir waters again :)
<bschaefer> :)
<kgunn> mterry: yes, thank you for all the help
<mterry> kgunn, cool
<kgunn> i'll check back in later....and write a mail for chris & daniel in the event euro morning monday needs some assitance
<kgunn> bschaefer: also...let cyphermox know
<kgunn> bbiab
<bschaefer> alright
<cyphermox> know what?
<bschaefer> cyphermox, how xmir works with the new ppa on unity7?
<bschaefer> thats what i got out of that
<robotfuel> kgunn: I have xmir phoronix test setup for trusty in the qa lab, I can enable autopilot tests for unity7 as well if you want
<robotfuel> bschaefer: ^
<robotfuel> also for the staging ppa
<bschaefer> robotfuel, the AP tests for unity7 will take 2-3 hours
<bschaefer> bregma, do you want the AP tests enabled for unity7 atm?
<bschaefer> in trusty?
<bschaefer> for xmir
<mterry> kgunn, if this latest change doesn't work...  how badly do we need this to go in?
<mterry> kgunn, like...  disabling tests is the quick and dirty way, but that's got red flags all over it
<mterry> kgunn, else we could have Mir team look at it (in trusty!  :))
<mterry> kgunn, and the test still failed
<robotfuel> mterry: +1 the tests need to be fixed
<mterry> robotfuel, yar :-/
<mterry> Is anyone here familiar with the error "Failed to find server" ?
<mterry> That seems to be the exception thrown by the tests
<robotfuel> mterry: is there a log you can post for the failed tests?
<mterry> robotfuel, current build isn't quite finished, but this was previous build: https://launchpadlibrarian.net/154994415/buildlog_ubuntu-trusty-i386.mir_0.1.0bzr1153trusty1_FAILEDTOBUILD.txt.gz
<mterry> I expect the errors to be the same
<mterry> robotfuel, errors aren't terribly informative
<mterry> robotfuel, are you on trusty?
<robotfuel> mterry: no I have a machine in the lexington lab I can use though
<mterry> robotfuel, seems to not happen on saucy
<kgunn> mterry: i'm guessing duflu and RAOF might inherit looking into this
<kgunn> mterry: wait...i'm confused...is this really the top of the lp:mir/trusty ?
<kgunn> what is it 1153
<kgunn> oops/what/why
<mterry> kgunn, I'm seeing
<mterry> kgunn, 1161
<kgunn> i mean, why isn't it 1161
<mterry> kgunn, I dunno about lp:mir/trusty.  I'm using lp:mir
<mterry> presumably they're the same?
<kgunn> mterry: yes...same thing
<mterry> kgunn, I'm thinking of just disabling tests so we can build xorg against mir.  But before mir hits archive, we should fix tests
<kgunn> mterry: yeah that's worthy
<kgunn> we can still get some test results on xmir and then feed all this to duflu and chris
<kgunn> rebooting
#ubuntu-mir 2013-10-26
<mterry> bschaefer, cyphermox: you guys still around?  i386 is ready in ppa:mir-team/staging
<bschaefer> mterry, iam and cool ill test it out
<bschaefer> mterry, and im just making sure unity7 is still working?
<bschaefer> or am i running some tests as well?
<mterry> bschaefer, I believe it's just making sure unity7 and xmir work well together
<mterry> bschaefer, "mainly unity7 comes up and doesn't fall over"
<bschaefer> mterry, cool sounds good
<bschaefer> thanks for getting that ppa up
<mterry> bschaefer, yw!  Thanks for testing  :)
<bschaefer> np!
 * bschaefer reboots and hopes all goes well
<bschaefer> mterry, all seems well
<bschaefer> mirs running, any version i should double check that im running against?
<bschaefer> 0.0.1+13.10.20131015bzr90saucy0 is my u-s-c
<mterry> bschaefer, you're on saucy?!
<mterry> bschaefer, tsk tsk
<bschaefer> err
<mterry> bschaefer, sorry, should have said these are trusty packages
<bschaefer> have i forgotten to upgrade!
 * bschaefer goes and does that
<bschaefer> mterry, well i shuld have already done that :)
<bschaefer> mterry, hmm im having a fun problem with the upgrade not finding the trusty sources/packages...
<mterry> bschaefer, hah  :-/
<mterry> bschaefer, that's not me!  :)
<bschaefer> mterry, haha, i hope not! Im trying to figure out why it cant find any of the trusty packages...when i do a do-release-upgrade...
<bschaefer> just a huge list of Err  and Ign
<mterry> bschaefer, huh
<mterry> bschaefer, I just edited sources.list...
<bschaefer> tried that as well and still not finding all of them
 * bschaefer might have missed some
<bschaefer> well that seemed to work...
<bschaefer> mterry, yay:   Installed: 0.0.1+14.04.20131025bzr91trusty0
<bschaefer> all working as well
<bschaefer> mir server running, and xmir feels just like X
 * mterry hugs bschaefer 
<kgunn> thanks bschaefer !
<bschaefer> kgunn, np!
#ubuntu-mir 2013-10-27
 * RAOF settles back into his office.
#ubuntu-mir 2014-10-20
<alan_g> alf__: any thoughts on the design? (C.f. my latest comment) https://code.launchpad.net/~alan-griffiths/mir/render-examples-using-a-simpler-server-setup/+merge/238469
<PaoloRotolo> Hi all!
<PaoloRotolo> Can someone explain me how to use mirscreencast please :)?
<alan_g> kdub_: does this approach read better to you? https://code.launchpad.net/~alan-griffiths/mir/render-examples-using-a-simpler-server-setup/+merge/238469
<kdub_> alan_g, looking
<kdub_> alan_g, +1
<alan_g> kdub_: thanks. I'm glad you forced me to think it through.
<alan_g> alf__: got time to look? ^^
#ubuntu-mir 2014-10-21
<ahayzen> Hey guys, I was talking to some of you about the screen corruption/tearing issues on mako at the sprint, i've reported this bug https://bugs.launchpad.net/mir/+bug/1383745
<ubot5> Ubuntu bug 1383745 in Mir "[mako] screen corruption/tearing after using the device for medium durations" [Undecided,New]
<duflu> ahayzen: Thanks for that. I think I've seen similar once or twice on mako
<ahayzen> duflu, no problem, if i see it again and can think of anything that i've done similar to get it in that state i'll add it to the bug
<slvn_> Hello !
<slvn_> please dont forget this wish : https://bugs.launchpad.net/mir/+bug/1382209
<ubot5> Ubuntu bug 1382209 in Mir "[Enhancement] Add an API to lock surface orientation" [Wishlist,Triaged]
<slvn_> It's needed to develop native apps ...
<alan_g> slvn_: it is not forgotten
<ogra_> slvn_, note that ubuntu-rtm is not tied to the ubuntu release ...
<ogra_> (since it is a derivative)
<slvn_> ok! I just look forward to publish apps
<ogra_> so there is still plenty of time to fix ;)
<slvn_> I would like also to make sure it goes into the *release* that will be shipped on phones/customer
<slvn_> I dont know the exact name ...
<slvn_> I mean, I want to make sure, that when you will officially ship ubuntu phone to the customer, there will be this feature
<ogra_> slvn_, thats ubuntu-rtm
<ogra_> ubuntu itself has become more of a playground for devs to test their stuff before it goes into the rtm distro
<slvn_> ok ! so  don't wait the last minutes then :)
<slvn_> when it will be done, I can provide testing with my apps !
<slvn_> bye !
<alan_g> alf__: Happy with these semantics? https://code.launchpad.net/~alan-griffiths/mir/render-examples-using-a-simpler-server-setup/+merge/238469
#ubuntu-mir 2014-10-22
<mdeslaur> RAOF_: I've added a blurb to our bug about the clipboard: bug 1371170
<ubot5> bug 1371170 in unity8 (Ubuntu) "information disclosure: clipboard contents can be obtained without user knowledge" [High,New] https://launchpad.net/bugs/1371170
<mdeslaur> RAOF_: if you have any details to add, or anyone to assign, etc.
<alan_g> any more votes on https://code.launchpad.net/~alan-griffiths/mir/make-stub-a-graphics-platform/+merge/239042?
<RAOF_> bschaefer: https://code.launchpad.net/~raof/mir/dont-kill-the-poor-clients/+merge/232971
<bschaefer> RAOF_, very nice name of the branch haha
#ubuntu-mir 2014-10-23
<alan_g> anyone else want to vote on this  before lunch? https://code.launchpad.net/~alan-griffiths/mir/Migrate-ServerConfigurationWrapping-to-Server-API/+merge/239184
#ubuntu-mir 2014-10-24
<alan_g> anyone willing to review this? https://code.launchpad.net/~alan-griffiths/mir/some-acceptance-tests-use-mir-Server-API/+merge/239406
#ubuntu-mir 2014-10-26
<akiva-thinkpad> Is mir replacing x11 keyboard layouts?
<akiva-thinkpad> I am wanting to create my own so...
<racarr> akiva-thinkpad: No its using XKB keymap format
<akiva-thinkpad> racarr, thanks
<racarr> :)
<akiva-thinkpad> racarr, is geometry being used in virtual keyboards?
<akiva-thinkpad> racarr, or is it being done manually with qml?
<racarr> akiva-thinkpad: I don't understand, sorry. Which geometry?
<akiva-thinkpad> racarr, in the xkb directory, there is a folder called "geometry"
<akiva-thinkpad> I understand its for external programs to use to say, draw the perculiar shape of the enter key on a thinkpad
<akiva-thinkpad> not a hundred percent sure
<racarr> akiva-thinkpad: Ah I see, yeah looks like you are right...
<racarr> akiva-thinkpad: We are not using that yet/have any particular plans to use it...
<racarr> I mean I guess Mir doesnt have to support it
<akiva-thinkpad> racarr, yah that is right
<racarr> if you know what the keymap is
<akiva-thinkpad> my question was more directed towards the ubuntu touch keyboard
<racarr> and really want it I guess you can open the geometry file, etc with libxkb
<racarr> ah
<racarr> akiva-thinkpad: So! In this case Mir input isnt really being used at all
<racarr> well I mean its used for clicking on the keyboard haha
<racarr> but the keyboard and the app
<racarr> use a DBus side channel
<akiva-thinkpad> racarr, thank you for your expertise
<akiva-thinkpad> !cookie | racarr
<ubot5> racarr: Wow! You're such a great helper, you deserve a cookie!
<akiva-thinkpad> anyways I am glad to hear that my custom layout will be transferable to mir.
<racarr> aha thankyou :)
<racarr> yes! should be!
<akiva-thinkpad> !thanks | racarr
<ubot5> racarr: You're welcome! But keep in mind I'm just a bot ;-)
<racarr> for touch I guess it would require working with http://web.archive.org/web/20140105175716/https://wiki.maliit.org/Documentation
<racarr> er...not sure how I ended up with an archive.org link
<akiva-thinkpad> heh; great site
 * akiva-thinkpad gets back to writing the tutorial
<racarr> *waves*
<racarr> is it evil to call a class VsyncSink?
<akiva-thinkpad> heh
<akiva-thinkpad> racarr, is mir being programmed in go?
<racarr> akiva-thinkpad: Nah :) C++
<akiva-thinkpad> racarr, that would have been interesting if it was. I guess though they did branch it from android so that makes sense.
#ubuntu-mir 2015-10-19
<RAOF> REVIEW ALL THE THINGS!
<anpok_> RAOF: still around?
<alan_g> greyback: I know this isn't the exact context you're interested in, but it may be related to some of the problems you've seen. So FYI: https://bugs.launchpad.net/mir/+bug/1507518
<ubot5> Launchpad bug 1507518 in Mir "core when replugging external monitor" [Undecided,New]
<zzarr> hello! how does mir and freon compare?
<alan_g> Very much as weston and freon do.
<zzarr> hmm... never heard of weston
<alan_g> weston is the best know implementation of wayland
<zzarr> ohh, it's wayland
<zzarr> is there a possibility to use libhybris with freon drivers?
<zzarr> to make it speak the graphics language of mir ;)
<ogra_> zzarr, you are mixin up things :)
<zzarr> I just realized that :O
<ogra_> hybris is to make libc (linux) binaries talk to bionic (android) binaries
<ogra_> not related much to Mir or wayland
<ogra_> freon will have some Mir compatibinity layer
<zzarr> is it happening right now or is it planed for the future?
<ogra_> (look for ozone-mir and ozone-wayland)
<zzarr> ahh, thanks ogra_
<ogra_> why are you so interested in it ? after all it will only help with chromium
<ogra_> (freon that is)
<ogra_> all that freon does is add support to chromium for talking directly to drm/kms drivers ...
<zzarr> I know, I wanted the other way around ;)
<zzarr> I have a Chromebook (RK3288 chipset) which I wish to run MIR on
<ogra_> not sure thats possible
<ogra_> (without running Mir natively i mean)
<zzarr> but I want a native mir ;)
<ogra_> well, then you have to port Mir ... i doubt freon can help much here
<ogra_> (apart from using it for code examples perhaps)
<tvoss> zzarr, Mir supports drm/kms drivers already, probably best ot give the demo clients/servers a spin
<zzarr> I have an ASUS ChromeBook Flip and it's formfactor just screams "put MIR/Unity8 on me" ;)
<zzarr> I'll just install mir and it works?
<zzarr> I can't do it right now, I'm at work, I'll test it after work
<zzarr> I know this is off topic, but can I have both MIR and Freon running at the same time?
<zzarr> I hope I'm not making you tired of me, but Ubuntu/Canonical/MIR/Unity8/Snappy puts me in a good mood
<zzarr> mode*
<tvoss> zzarr, I personally haven't tried, but if it comes with kms/drm drivers, chances are good
<zzarr> tvoss, are freon or mir occupying the driver or can I use both at once?
<tvoss> zzarr, it's exclusive or, both will want exclusive access to the drm nodes
<zzarr> okey, so I have to find a way to stop freon and start mir then
<anpok_> zzarr: rockchip 3288 uses mali
<anpok_> since the lima driver has not taken off yet.. your only chance are the android drivers afaict
<zzarr> anpok_, okey, so the lima driver is the one that will handle Mali GPU's but it don't support the 764 yet... got you
<anpok_> i mean drm kms might work.. but you will lack a user space egl/gles driver..
<anpok_> ack
<zzarr> so I'd better find a way to install Ubuntu in a dualboot rather then a chroot as I hav now and then install libhybris and an android driver I guess
<zzarr> will I be able to use the drm kms drivers for other functions like wifi and bt?
<kenvandine> greyback, hey, any update on the mouse/touchpad settings support?
<greyback> kenvandine: not yet no. Mir still needs to switch to libinput before that can proceed
<kenvandine> greyback, ok, is that happening soon?
<greyback> kenvandine: anpok_ is managing it, seems like it's not far away
<anpok_> there is a bunch of mps up for review.. most of them will land soon.. some already landed but got reverted because of a regression on modifiers..
<anpok_> but real soo now..
<anpok_> kenvandine: the part you might be interested in is already exposed in usc
<anpok_> or by usc..
<anpok_> the dbus api
<anpok_> i am about to prepare a change for USC that wires stuff together, but the dbus API for configuring pointer and touchpads has already landed..
<greyback> kenvandine: there were discussions about using GSettings for those settings, and having unity8 read those settings and configure USC accordingly (would solve the log-in issue)
<greyback> does that ring a bell?
<kenvandine> yeah
<kenvandine> that was the plan
<greyback> ok good, we're on same page so
<kenvandine> so i don't really need the dbus api...  :)
<greyback> yeah you don't
<kenvandine> greyback, so i have a unity8 branch that adds the schema, but it's quite outdated
<kenvandine> i should update that :)
<greyback> kenvandine: please do, that would be excellent
<greyback> since you know what you need
<kenvandine> greyback, you've seen it before, but here's a reminder :)
<kenvandine> lp:~ken-vandine/unity8/mouse_touchpad_schema
<kenvandine> i just merged the latest trunk
<greyback> cool, thanks
<tvoss> greyback, anpok_ I'm confused, I thought we decided against the gsettings approach?
<greyback> tvoss: true, we agreed the proper way is mir having api for this. I dunno how far long that is tho
<tvoss> anpok_, ^?
<tvoss> anpok_, greyback iirc, we decided that a private dbus api is the stop-gap measure to keep us moving
<anpok_> tvoss: even with a client side configuration api there will be gsettings somewhere
<tvoss> anpok_, disagreed
<anpok_> and someone has to apply the settings found in gsettings on session start..
<tvoss> anpok_, let unity8 handle that
<anpok_> tvoss: and thats what we do..
<tvoss> anpok_, certainly not system settings
<tvoss> anpok_, sorry, but gsettings is not the way we agreed to do it
<anpok_> tvoss: sure, but I am not touching gsettings stuff..
 * tvoss reads backlog
<tvoss> anpok_, so unity8 translates a private dbus api to a gsettings schema? now that sounds like a really bad idea
<anpok_> I would phrase that the other way round..
<anpok_> but then still .. you should start the sentence with "kenvandine, greyback:"
<greyback> the private dbus api is needed for IPC between usc and u8, that we'll eventually replace with proper mir api
<anpok_> somebody has to forward settings from somehwere..
<tvoss> greyback, kenvandine let's jump on a hangout real quick
<greyback> sure
<tvoss> kenvandine, greyback https://plus.google.com/hangouts/_/x7iu5fnluwfqektfyirtrpyizua?hl=en&authuser=0
<kenvandine> ok
 * alan_g discovers that he can crash mir by stepping through the client "display reconfiguration" code.
<greyback> AlbertA: hey, I see you've updated https://code.launchpad.net/~albaguirre/qtubuntu/use-mir-surface-apis/+merge/267228 - would there be any specific app I should use to test it with? One that uses those surface types?
<kgunn> anpok_: actually i'll ask hear
<kgunn> here even
<kgunn> so i'm trying to get snapcraft for mir going, just sorting through the build deps
<kgunn> and seems we need to have libinput installed, but it's not gettting installed automatically ?
<kgunn> hmm, or maybe i'm not installing a dependency correctly for snapcraft itself...
<kgunn> lemme dig a bit more
<anpok_> kgunn: hm what do you mean by not getting installed automatically? .. hm libinput is pulled in as build dep and runtime dep of the evdev platform
<kgunn> anpok_: well, so when i try to build with snapcraft, which effectively runs cmake
<kgunn> i get
<kgunn> -- CMAKE_C_COMPILER: /usr/bin/cc
<kgunn> -- checking for module 'libinput'
<kgunn> --   package 'libinput' not found
<kgunn> anpok_: so when i do apt-cache policy libinput ...i get : N: Unable to locate package libinput
<anpok_> libinput-dev and libinput10
<kgunn> ah just found it meself just now...
<anpok_> so snapcraft is not pulling dependencies on its own?
<kgunn> anpok_: so how does one determine which libinput ver we use ?
<kgunn> anpok_: nope, you've gotta list 'em
<kgunn> :-/
<kgunn> anpok_: but i can get it as a sub dependency...e.g. if libevdev-dev pulls it in, i could get it that way
<anpok_> as of now 1.0.1 + our patches.. and I am waiting for x to get more patches added..
<anpok_> before that 0.21 + our patches was fine too
<kgunn> anpok_: so is there fwd/backward compat issues there ?
<anpok_> hm no not in that sense.. it would build and run on both recent releases to vivid-overlay and wily
<kgunn> anpok_: just sharing, so i
<kgunn> am using the debian/control file in mir as a guide to determine
<kgunn> what to add
<kgunn> anpok_: https://pastebin.canonical.com/142095/
<kgunn> so what am i missing to pull in libinput ?
<kgunn> should i just add libinput10 directly ?
<kgunn> ...suppose i can, just wondering if you had expected libevdev-dev to pull it in
<anpok_> just libinput-dev (>= 0.21)
<anpok_> not not really.. dependency between libinput depends on libevdev not the other way round
<anpok_> i believe we added libevdev for some of the privileged tests
<kgunn> anpok_: dang it...my list got truncated too...so probably me
<kgunn> anpok_: hey, i think i really did stumble onto something
<kgunn> seems to be tied to mir0.17
<kgunn> so the instructions i follow to build mir are
<kgunn> the classic http://unity.ubuntu.com/mir/building_source_for_pc.html
<kgunn> i just mir 0.16 no prob
<kgunn> when i do cmake i get that error
<kgunn> hmm, altho i didn't explicity run sudo mk-build-deps --install --tool "apt-get -y" --build-dep debian/control
<kgunn> on mir0.17
<kgunn> ah...that did it, libinput-dev
<AlbertA> greyback: qtcreator which has menus and dialogs. The menu bar is still wonky but most other things popup in the right place
<greyback> AlbertA: ok, nice
<kgunn> vogons working through dependency stuff, is python3 just used for supporting the build ? or is it something mir actually relies on at runtime
<AlbertA> kgunn: it's used for the tool that parses
<AlbertA> the perf latency numbers
<AlbertA> so not mir run-time
<RAOF> anpok_: Around now!
#ubuntu-mir 2015-10-20
<anpok> RAOF: the keyboard modifier mp should do the right thing now..
<RAOF> anpok: Yeah, I'm just looking at it.
<RAOF> Thanks!
<duflu> RAOF: Oh, my Xmir stability fix also corrects clipping enough that non-compositing WMs now work :)
<duflu> All the WM things now work \o/
 * duflu parties like it's 1990 for X11
<duflu> Oh, that should be 1989
<duflu> dix/window.c:    if (party_like_its_1989) {
<anpok> duflu: https://code.launchpad.net/~andreas-pokorny/mir/bump-input-platform-abi-for-0.18/+merge/274410 this should be fine now..
<duflu> anpok: OK, but I think I'm done with Mir reviews for the day
<duflu> Tis the hour for Xmir
<greyback_> alan_g: how dodgy does this look to you: https://code.launchpad.net/~gerboland/qtmir/fix-cmdline-args/+merge/274954
 * alan_g thinks "if you have to ask..."
<alan_g> @"+ // argv2 - Mir parses out arguments that it understands. It also removes argv[0], but we will put it back." sounds like there should be a Mir bug reported.
<greyback_> alan_g: I wasn't sure if that was intentional tbh
<alan_g> greyback_: IIRC there's no guarantee that the strings passed to the callback remain valid after the call
<alan_g> Reporting a bug is a good way to test the intention
<greyback_> alan_g: ok
<alan_g> It's a lokg time since I reworked the Mir code, but the boost.Options stuff didn't seem intended to "play nice" with other parsers.
<zzarr> hello! are there any documentation for the MIR display server protocol?
<alan_g> zzarr: Mir provides an API not a protocol. API documentation is here: https://unity.ubuntu.com/mir/index.html
<Guest42341> glmark2 stopped working after OTA7 https://bugs.launchpad.net/canonical-devices-system-image/+bug/1507982
<ubot5> Launchpad bug 1507982 in Canonical System Image "OTA7 broke previously working app" [Undecided,New]
<zzarr> alan_g, so what I'm looking for is a way to make a userland driver then
<alan_g> I don't think that's fully supported yet. The Mir-on-X driver, for example, currently needs some yet-to-be-published-and-supported APIs
<alf> zzarr: What do you mean exactly by userland driver?
<zzarr> before I confuse any more (both you and me) could you explain how applications and the server communicate? (like an xclient connects to a xserver over the X protocol)
<greyback_> alan_g: any progress on the usc multimonitor issue?
<alan_g> greyback_: I've found enough bugs that its hard to know what to fix first.
<alan_g> zzarr: the client call an API implemented by libmirclient. That does the rest
<greyback_> alan_g: ok
<zzarr> okey, I'm looking for a way to basically make a wrapper for mir to chrome os using qt
<zzarr> I wish to be able to run a full Unity8 environment on a chrome os device
<alan_g> Are you prepared for a couple of months work?
<alf> Guest42341: thanks for the heads up, will investigate
<Guest42341> alf, o/
<Guest42341> tux racer and works fine though
<Guest42341> and neverball
<zzarr> alan_g, it might take a while yes
<alan_g> zzarr: look at how the X11 support works for running Mir on X, you need to replicate that using APIs supported on ChromeOS. After that Mir will work. But not Unity8 - that uses other services too, so you'll also need to work out how to provide those.
<zzarr> alan_g, do you have a link to the source for that mir implementation?
<zzarr> alan_g, yes I think I would be able to run the other services in a chroot
<alan_g> You can start from here https://bazaar.launchpad.net/~mir-team/mir/development-branch/files/head:/src/platforms/mesa/server/x11/
<zzarr> alan_g, thanks :D
 * alan_g decides the way that display configuration policy is applied (by the kms::Display constructor - but not X11, Nested or android) is weird.
<kgunn> sturmflut2: ping
<Stskeeps>    /g situ
<Stskeeps> err.. ignore me
#ubuntu-mir 2015-10-21
<RAOF> @vogons: Those people trying to build against recent mirclient will probably want https://code.launchpad.net/~raof/mir/mircookie-dependency/+merge/275125
<bschaefer> approved
 * bschaefer missed that
<RAOF> Oooh.
<RAOF> clion now has a ârun this test fixtureâ feature that works on Mir!
<RAOF> Man, every time I look at ThreadSafeList I get the overwhelming urge to make it a lock-free vector instead.
<anpok_> vogons: could someone look at the reg-ex inside the input platform abi bump.. believe I got it right now.. then I would be able to land the modifier fix and finally the android input stack removal..
<anpok_> every time i see it I want to run away..
<duflu> anpok_: Yes, sorry. I like regex things
<duflu> Gah. Jenkins says: before lunch A passes and B fails. Now A fails and B passes
<anpok> :) .. i only like them in small digestable amounts wihtout multiple layers of escape characters
<anpok> i.e. .. imagine using cmake to write a shell script that contains a regular expression..
<duflu> anpok: Yeah I understand
<anpok> .. boost::expressive is nice btw.. but I dont want to spoil your dinner..
<anpok> duflu: new ci problem?
<duflu> anpok: Ha. Boost is the reason I wrote:  http://sourceforge.net/projects/rexre/
<duflu> anpok: Yeah there's an intermittent CI problem with vivid+overlay or something? Can't see all the errors because the first one uses non-public URLs. And it's been years since I had the VPN working
<anpok> ah ok .. but those connection problems only seem to occur with our krillins..
<duflu> Ask for wily touch, that fails for everyone but those two failures don't prevent the final result being PASS
<duflu> -Ask +As
<duflu> Man we have too many binary packages arising from Mir now
<RAOF> anpok: Enjoy https://code.launchpad.net/~raof/mir/scratch-threadsafe-list-itch/+merge/275139 !
<duflu> RAOF: Or just don't have multiple threads :)
<RAOF> EOD!
<duflu> Night
<alan_g> anpok: looks like we're almost ready to delete 31KOC
<anpok> yip
 * anpok is just a bit frustrated that we now have similar different ci problem with the krilling trestrunners..
<anpok> +a
<zzarr> Hello! I have a MX4 and there is no mouse cursor on my phone when a bt keyboard and mouse is connected
<greyback> zzarr: that feature hasn't landed yet, sorry
<zzarr> okey, thanks greyback, when do you think it will land?
<ogra_> on a wednesday
<ogra_> :P
<greyback> zzarr: it's being actively worked on, so by the next OTA with luck
<zzarr> thanks greyback, then I hope that I have luck :)
<zzarr> I have to go, bye greyback and ogra_ and thanks for your replies
<greyback> welcome
<kgunn> SturmFlut ping
<popey> kgunn: lost track of things yesterday, was there something you wanted me to scan apps for?
<popey> oh, that was it, thinks linked against libmirclient?
<kgunn> popey: yep that and sdl actually
<kgunn> popey: much appreciated
<popey> what is it specifically we're looking for?
<kgunn> popey: libmirclient8 and sdl (which is against libmirclient8)
<kgunn> which is the one client before we corrected made abi promise
<kgunn> we found one app using, so we wanted to see if there were others
<popey> kgunn: okay, will take a look
<popey> kgunn: when do you need it by?
<kgunn> popey: not a rush thing, so day or so is fine
<popey> okay
<popey> will do on friday, I have some time then
<SturmFlut> kgunn: pong
<kgunn> SturmFlut hey there, unsure if someone made you aware of bug
<kgunn> https://bugs.launchpad.net/ubuntu/+source/mir/+bug/1507982
<ubot5> Launchpad bug 1507982 in mir (Ubuntu) "[regression] OTA7 broke previously working app" [High,Triaged]
<kgunn> i believe that's your app mentioned there
<kgunn> SturmFlut unfortunately, i think when you built you caught the last mirclient lib where we weren't promising to care for abi breaks
<kgunn> just wanted to raise to your attention, if you rebuild against the latest, it should work fine
<SturmFlut> kgunn: thanks for telling me, didn't see that somebody already opened a bug for it. So I just update my 15.04 chroot and recompile?
<kgunn> SturmFlut yes, assuming you have the stable-phone overlay applied (?)
<kgunn> pure 15.04 vivid won't have the latest mir, but the overlay, which feeds the phone images we release does
<kgunn> should have libmirclient9
<sturmflut_> kgunn: I'm just using the chroot created by Qt Creator. So I basically add ppa:ci-train-ppa-service/stable-phone-overlay inside of it, update and rebuild?
<kgunn> sturmflut_: exactly
<kgunn> sturmflut_ i'd kind of be surprised if you updated Qt creator, that it wouldn't already have that applied
<sturmflut_> let's do a round of updates on all sides and see what happens
<kgunn> sturmflut_: thanks, if you hit problems, ping here...and sorry for the noise!
#ubuntu-mir 2015-10-22
<alf> sil2100: Hi! I was wondering if we have (or can get) a commitlog for ubuntu-touch/rc-proposed/ubuntu 306 -> 307. When we moved to 307 some tests in CI started failing mysteriously and the changelog could give us some clues.
<ubot5> Error: Could not gather data from Ubuntu for bug #306 (https://launchpad.net/bugs/306). The error has been logged
<sil2100> alf: let me try finding that one for you
<sil2100> alf: for what device is that?
<sil2100> alf: mako or krillin?
<alf> sil2100: krillin
<sil2100> hmmm
<sil2100> alf: ok, strange, since 306 -> 307 is 153 -> 154 in the bq-aquaris.en channel
<sil2100> alf: http://people.canonical.com/~lzemczak/landing-team/ubuntu-touch/rc-proposed/154.commitlog
<sil2100> There's not much going on there, you sure it's the switch to 307 that broke the tests? Or maybe 306? Since 306 had much more changes
<alf> sil2100: Hmm, thanks. Perhaps the change from 306 -> 307 was coincidental then.
<alf> sil2100: unless... does the changelog include changes to the android parts (drivers, kernel etc)?
<sil2100> alf: hm, no, but I don't think we had any changes there
<alf> sil2100: thanks, I will keep digging
<anpok> vogons: duflu proposes a different platform library versioning scheme...
<anpok> https://code.launchpad.net/~andreas-pokorny/mir/bump-graphics-platform-abi-for-0.18/+merge/275144/comments/695389 ..
#ubuntu-mir 2015-10-23
<loicm> hey, how do you compile, say eglapp.c, in the examples folder?
<loicm> (.text+0x28): undefined reference to `main
<alan_g> loicm: "make"
<alf> loicm: (in case you are building manually for some reason, not using cmake/make) eglapp.c is a helper file used by some of the demo clients. Try compiling a demo client like eglflash.c (that needs eglapp.c)
<loicm> alan_g: I mean outside of the build system
<loicm> alan_g: this is something several people do when testing a lib
<loicm> alf: ah, thanks, that wasn't clear
<alf> loicm: try something like 'gcc -o mir_demo_client_eglflash $(pkg-config --cflags mirclient gl egl) eglflash.c eglapp.c $(pkg-config --libs mirclient gl egl)'
<loicm> alf: yes, thanks, got it compiled now :)
#ubuntu-mir 2016-10-25
<alan_g> anpok: Your "Needs Info" appears to be obsolete: https://code.launchpad.net/~raof/mir/observer-multiplexer/+merge/307501
<anpok> ah .. yes
#ubuntu-mir 2016-10-26
<alan_g> greyback: following last week's discussions I want to remove the direct mirserver-dev dependencies in miral-qt. Before I spend more time on this approach do you have any problems with the these: https://code.launchpad.net/~alan-griffiths/miral/identify-code-using-libmirserver-directly/+merge/309080 & https://code.launchpad.net/~alan-griffiths/miral/encapsulate-PromptSessionListener/+merge/308740
<greyback> alan_g: hey. Let me look now (I was out sick for the last few days)
<alan_g> greyback: sorry to hear that. Hope you're recovered now.
<greyback> alan_g: yep, I am, thanks
<alan_g> greyback: I've updated this - I trust I understood you correctly. https://code.launchpad.net/~alan-griffiths/miral/encapsulate-PromptSessionListener/+merge/308740
<greyback> alan_g: ack. Will do, approved
<alan_g> thanks
#ubuntu-mir 2016-10-27
<duflu> greyback: Sorry, forgot to test that option you suggested for nouveau. Such is the way with multi-part questions. It's worth noting though that the Nvidia binary driver we will only be able to support with newish GPUs. So any Nvidia chip more than a few years old like yours will always need to use nouveau anyway
<greyback> duflu: yep, we need to address this somehow
<alan_g> greyback: I found had to rework this (when I realised I had no tests), could you re-review? https://code.launchpad.net/~alan-griffiths/miral/identify-code-using-libmirserver-directly/+merge/309080
<greyback> ok
 * alan_g hits the launchpad prerequisite limit again
 * duflu repeatedly kills his machine with nouveau
<greyback> oh wow kernel4.8's scheduler is lousy, during build machine is unusable
<duflu> greyback: Excellent, a second data point. Please talk to bschaefer who was scientifically trying to prove the same thing last week. Going back to 4.4 fixes it
<duflu> I'm not sure if a bug has been logged
<alan_g> greyback: I think this fixes the titlebar glitch you spotted: https://code.launchpad.net/~alan-griffiths/miral/miral-shell-window-titles/+merge/309470
<greyback> alan_g: confirmed fix, apprved
<attente> are there performance optimizations with using opaque rgb surfaces over rgba surfaces?
<alan_g> attente: Qt compositor or Mir compositor?
<attente> alan_g: Mir
<alan_g> I'm not entirely sure of the current state, I think kdub did some work on it a while back.
<attente> alan_g: actually i guess i need to know if either optimizes non-alpha surfaces
<alan_g> For the qt compositor I'd ask greyback
<greyback> attente: if you're using unity8/qtmir as the compositor, it will read the alpha state, and if opaque it will draw with blending disabled
<greyback> Qt's renderer doesn't do any occlusion culling however
<attente> greyback: does disabling blending help much performance-wise?
<greyback> attente: it is more efficient on the GPU, no real difference to the CPU though
<greyback> attente: are you seeing poor performance somewhere? Or just curious of current optimizations in Mir?
<attente> greyback: i was asked about this in #gtk+, but didn't know. someone (Company) seems to be suggesting moving to just using rgba surfaces everywhere
<attente> i guess it could be pretty slow with software rendering
<greyback> attente: I wouldn't consider it a huge burden for any GPU rendering, but I can imagine a software renderer would suffer. A software renderer can do nice optimisations if it knows stuff is opaque (not draw what is occluded)
<attente> ok, thanks greyback
<anpok> attente: i believe that qt claims that they do that in their scene graph (occlusion)
<anpok> but more importantly rgb allows the renderer to reorder stuff based on state changes instead of depth
<anpok> so yes rgb should help alot
<kdub> rgba blending also causes 3 hops on the bus (src-on, dest-on, dest-off)
<kdub> so can cause bus congestion on devices that are sensitive to that
<attente> ok
<attente> kdub: isn't that traffic all on the gpu though?
<kdub> not on mobile
<attente> oh ok
<greyback> anpok: qt does not, nor does it claim, to do occlusion culling :)
<greyback> but it does do batching of opaque and non-opaque primitives, which saves a lot of work
<greyback> http://doc.qt.io/qt-5/qtquick-visualcanvas-scenegraph-renderer.html for more details
<greyback> kdub: "not on mobile" <- that's interesting. Would you have a link to a resource where I could learn about that?
<kdub> greyback, will have to see if I can find something, nothing handy
 * kdub just remembers optimizing that situation many moons ago for bus reasons
<greyback> kdub: ack, no worries. Just in case you had something handy
<anpok> greyback: hm I thought that I read a blog post..
<anpok> but maybe that was more marketing
#ubuntu-mir 2016-10-28
<alan_g> greyback__: OK? https://code.launchpad.net/~alan-griffiths/miral/remove-libmirserver-dev-from-screen.h/+merge/309552
<greyback__> alan_g: yes, thank you
<alan_g> dandrader: are you really calling this function somewhere? https://code.launchpad.net/~alan-griffiths/miral/tidy-SurfaceObserver-part1/+merge/309496/comments/802227
 * dandrader looks
<dandrader> alan_g, replied on the MP
<alan_g> dandrader: thanks, that makes sense
#ubuntu-mir 2017-10-23
<RAOF> Son_Goku: Enjoy your new tarball.
<Son_Goku> ?
<RAOF> Son_Goku: There's now a mir-0.28.0 tarball up on Launchpad.
<Son_Goku> ah
<Son_Goku> nice
<Son_Goku> thanks
<Son_Goku> though... I'm using the bzr checkouts at the moment :/
<Son_Goku> RAOF, that latest commits of Mir behave... better on Fedora
<RAOF> Yeah, they'll be rolled up into 0.28.1, probably.
<RAOF> Care to fix GMock? :)
<Son_Goku> I'm not sure how to
<Son_Goku> your CMakeLists are quite a bit messier :/
<RAOF> I think gmock is expected to be built with gtest?
<RAOF> Oh, I don't mean fix GMock detection in Mir. I mean fix GMock in Fedora, so we can just link to it :)
<Son_Goku> gmock and gtest are built and available in Fedora
<Son_Goku> gmock-devel and gtest-devel
<Son_Goku> https://apps.fedoraproject.org/packages/gmock
<Son_Goku> https://apps.fedoraproject.org/packages/gtest
<RAOF> Yeah, but gmock-devel doesn't appear to install the library?
<RAOF> (At least in my fedora container)
<RAOF> It just installs the source?
<Son_Goku> on which Fedora?
<Son_Goku> oh, I see here
<Son_Goku> yeah, this does need to be fixed
<RAOF> Annoying that there's no FindGMock.cmake
#ubuntu-mir 2017-10-26
<duflu> Morning oSoMoN (as I run away for a bit)
<duflu> Oh, I mistook this for desktop. Didn't notice #ubuntu-desktop had been locked down again and I wasn't in there
<oSoMoN> good morning duflu :)
