[02:40] <robotfuel> duflu: ping
[02:43] <duflu> robotfuel: pong
[02:44] <robotfuel> duflu: armhf is failing on a new warning, I've opened https://bugs.launchpad.net/mir/+bug/1248014
[02:44] <ubot5> Ubuntu bug 1248014 in Mir "/tmp/buildd/mir-0.1.1/tests/unit-tests/android_input/input_reader.cpp:758:36: note: 'args.android::NotifyConfigurationChangedArgs::eventTime' was declared here NotifyConfigurationChangedArgs args;" [Undecided,New]
[02:44] <duflu> robotfuel: Thanks. I noticed just a few seconds ago
=== jono is now known as Guest6286
=== tvoss|dinner is now known as tvoss
[07:29] <tvoss> RAOF, ping
=== tvoss is now known as tvoss|test
=== tvoss|test is now known as tvoss
[07:50] <Mirv> do you need a bug about unity-system-compositor failing to build against the new Mir?
[07:50] <Mirv> fatal error: mir/shell/focus_setter.h: No such file or directory
[08:00] <duflu> Mirv: Yes please. The change looks intentional... https://code.launchpad.net/~alan-griffiths/mir/tidy-shell-component-pass-2/+merge/193418
[08:02] <Mirv> bug #1248055
[08:02] <ubot5> bug 1248055 in Unity System Compositor " unity-system-compositor FTBFS on trusty against new Mir (libmirserver10)" [Critical,New] https://launchpad.net/bugs/1248055
[09:09] <Mirv> bug #1248080 too
[09:09] <ubot5> bug 1248080 in unity-mir "unity-mir FTBFS libmirserver10" [Critical,New] https://launchpad.net/bugs/1248080
[09:11] <didrocks> duflu: kgunn: Mir was pulled to trunk without warning us?
[09:11] <didrocks> and ensuring that the deps are building?
[09:11] <duflu> didrocks: I was asked by kgunn last week to do it on Monday (so everyone was ready).
[09:12] <didrocks> duflu: we still need:
[09:12] <didrocks> 1. to get an email from you knowing you are doing so
[09:12] <didrocks> 2. you need to ensure we can build unity-mir and u-s-c from it
[09:12] <didrocks> which isn't the case, right?
[09:13] <duflu> didrocks: It's impossible to guarantee those simultaneously. And I wasn't aware of any failures. In fact I argued we shouldn't do a pull at all
[09:13] <didrocks> duflu: so please revert this pull
[09:13] <duflu> didrocks: Sure
[09:13] <didrocks> as long as you aren't sure you aren't ready
[09:13] <didrocks> thanks
[09:14] <didrocks> reverting to the previous version we released please
[09:14] <didrocks> Mirv: sil2100: FYI ^
[09:14] <didrocks> Mirv: sil2100: remove them from the ppa please
[09:14] <Mirv> didrocks: ok, so so you also want a push --overwrite of the trusty branch to previous released version, or would it be enough to disable mir building + remove all relevant PPA packages?
[09:15] <didrocks> Mirv: let's get duflu put his trunk in shape again
[09:15] <didrocks> so just remove the components from the ppa
[09:15] <didrocks> and rekick a build for them
[09:15] <duflu> Mirv: An overwrite will be required. As we've lost the history of the post-0.1.0 Ubuntu changes. There's a weakness in the new system
[09:16] <duflu> I'm not sure who/where still holds a copy of that
[09:16] <didrocks> (mir, platform-api, unity-mir, u-s-c)
[09:16] <Mirv> didrocks: ok, duflu should be better suited to do that, as also the mir/trusty history is gone and there is no release commit anymore of the previous release
[09:17] <duflu> didrocks: I can take it back to 0.1.0 vanilla, but we don't have the history to restore 0.1.0+14.04.20131030-0ubuntu1 accurately
[09:17] <didrocks> Mirv: really?
[09:17] <didrocks> duflu: urgh? what have you done?
[09:18] <Mirv> didrocks: yep https://code.launchpad.net/~mir-team/mir/trusty
[09:18] <sil2100> ;/
[09:19] <didrocks> duflu: what happened so that you reverted our commit?
[09:19] <didrocks> can you please restore it?
[09:19] <Mirv> didrocks: I think it's the development branch push --overwrite:d to the stable branch
[09:19] <didrocks> that was explicitely forbidden
[09:20] <duflu> didrocks: The pull clobbered it (as bzr noticed the same code in development-branch). So you lose the Ubuntu-specific history
[09:20] <didrocks> duflu: yeah, please restore it, manually
[09:20] <duflu> ... happens even without --overwrite
[09:20] <didrocks> and pull that to the dev branch
[09:20] <didrocks> I think we'll go again with merging if the mir team doesn't know what they do
[09:23] <duflu> didrocks: Dev is sacred and not overwritable. This is definitely a weakness in the system. If it stops arguments, I don't care if we revert to merging
[09:23] <didrocks> duflu: so let's merge dev to trunk then
[09:23] <didrocks> trunk is sacred
[09:23] <didrocks> and should not be overwritable
[09:23] <didrocks> you are messing with the whole system
[09:23]  * didrocks isn't happy
[09:23] <duflu> didrocks: Yes, I never considered this possibility. I can rebuild the branch by hand, but not with the same history as it had
[09:23] <didrocks> duflu: so yeah, rebuild with what we had
[09:23] <didrocks> with 0 change from distro
[09:23] <didrocks> and the changelog in
[09:23] <duflu> didrocks: OK... rebuilding back to zero diff to distro
[09:23] <didrocks> thanks
[09:24] <duflu> didrocks: Although merging to trunk means it's no longer "sacred" because merge makes the history rubbish :(
[09:24] <duflu> Hmm
[09:24] <didrocks> duflu: well, at least, we ensure each commit from trunk can be buildable
[09:25] <didrocks> with the right soname and so on
[09:25] <didrocks> which isn't the case when you pull dev to trunk
[09:25] <didrocks> but I think we already show that pulling dev to trunk is an issue
[09:25] <duflu> didrocks: Yeah I don't care to argue about it any more. Rebuilding...
[09:25] <didrocks> thanks duflu
[09:35] <didrocks> duflu: can you give a sign to Mirv and sil2100 once done?
[09:35] <duflu> didrocks: Yep. When done I'll reinstate append_only too
[09:41] <duflu> didrocks,Mirv,sil2100: lp:mir restored to 0.1.0+14.04.20131030-0ubuntu1
[09:41] <didrocks> thanks
[09:41] <Mirv> duflu: thanks
[09:41] <tvoss> greyback, good morning
[09:42] <sil2100> Thanks
[09:42] <duflu> ... and now append-only. All pull/push attempts will fail
[09:42] <greyback> tvoss: hi :)
[09:43] <duflu> ... I mean pull/push attempts that clobber history will fail
[09:51] <duflu> didrocks: Does this mean the Ubuntu branch isn't used for anything? (lp:ubuntu/mir)
[09:53] <didrocks> duflu: this is for automated import from debian, it doesn't work with dailies
[09:53] <duflu> Ah
[10:02] <duflu> didrocks: I still can't help but think... what you want from lp:mir is all about Ubuntu requirements, so it should live in lp:ubuntu/something
[10:04] <didrocks> duflu: you are merging your branch based on ubuntu rules
[10:04] <didrocks> it's the case for the 250 components we ship and develop upstream
[10:04] <didrocks> I don't think Mir should have a special treatment
[10:05] <didrocks> in addition, all teams following the ubuntu/canonical requirements are quite successful in the way they are handling their projects
[10:05] <didrocks> I think the Mir team should start listening as well to go the same path
[10:06] <duflu> didrocks: I completely agree with your frustration, which I think is rooted in Mir's lack of stable server ABI. I was arguing against exposing what we have now, and what has led to this situation long before it happened :(
[10:07] <didrocks> duflu: I'm afraid the only way to mitigate this right now is this dev branch + merging back trunk
[10:07] <duflu> didrocks: Yep. *everything* is append_only again.
[10:07] <didrocks> yeah, sounds good :)
[10:08] <tvoss> duflu, didrocks I would like to point out again that the server api is meant to evolve
[10:08] <didrocks> tvoss: I don't care as long as transitions are coordinated and everything is known to build against the new API
[10:09] <tvoss> didrocks, sure, that's the problem we need to tackle, fully agreed
[10:09] <didrocks> just as told during the sprint, be aware that we have to block everything for 5 hours at each ABI breakage
[10:10] <tvoss> didrocks, sure, but I still think that an ABI break shouldn't be an unusal case, but considered the normal situation :) Anyway, I know why we need to block right now, so point taken
[10:11] <duflu> didrocks: Is there a solution in place to locking/unlocking atomic changes between projects? Or is it just convention that consumer projects get updated before providers?
[10:11] <didrocks> tvoss: you can break your interfaces, but the way it's dealt with would mean everything should be in the same project (source)
[10:11] <didrocks> duflu: it's a convention for now. I proposed a new CI vision that the infra CI team will start building soon where we can put in place "transactions"
[10:11] <didrocks> (over multiple projects)
[10:12] <duflu> didrocks: Yep, "transactions" is the word I meant
[10:12] <didrocks> your team will be one of the piloting team on that I guess :)
[10:14] <duflu> didrocks: Isn't that backwards to how non-Canonical updates work? I mean we can't control changes to all non-Canonical "provider" projects like that (?)
[10:15] <didrocks> duflu: right, but on those projects, people are backward compatible most of the time
[10:15] <didrocks> we are still at glib2
[10:15] <didrocks> or gtk3
[10:15] <didrocks> after years
[10:15] <duflu> didrocks: Yeah I've never seen an ABI change as much as Mir :)
[10:16] <didrocks> so yeah, the system will be a way to help for them as well
[10:16] <didrocks> but not be a requirement
[10:16] <didrocks> (at least, for now)
[10:17] <mlankhorst> hey
[10:20] <mlankhorst> RAOF: ping?
[10:24] <mlankhorst> it looks the easiest way to support glamor-egl with xxv-ati might be to simply use the same codepath as used by nested mir
[10:25] <mlankhorst> or I guess make glamor-egl use mir natively without gbm
[10:31] <duflu> mlankhorst: It's 21:30 for him
[10:34] <mlankhorst> yeah, I'll look into it a little myself
[10:36] <mlankhorst> I guess the easiest way is to bypass most of xmir :P
[10:47] <mlankhorst> hm and I guess it *could* be done in a generic way, removing all the crap from the ddx, only requiring glamor-egl and xorg-server
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[11:59] <Prf_Jakob> mlankhorst: just a quick question, is the plan to use glamour-egl on all drivers as a for of generic driver for Xmir?
[12:07] <mlankhorst> no idea yet :P I guess some egl magic will be used, and some mir magic for input/screens
[12:08] <Prf_Jakob> Ok
[12:08] <Prf_Jakob> If you read my response on mir-devel we have found that xa (and probably glamour) would be slower then software (at least for not insane window sizes).
[12:27] <mlankhorst> hm don't know if I'm subscribed there *checks*
[12:30] <tvoss> Prf_Jakob, hey there :) just spotted your nick :)
[12:30] <mlankhorst> oh indeed
=== greyback is now known as greyback|lunch
[12:39] <Prf_Jakob> tvoss: hey hey!
[12:47] <mlankhorst> sigh vmware being different again
[12:48] <Prf_Jakob> virgil will be in the same position.
[12:49] <Prf_Jakob> So its not just us.
[13:03] <mlankhorst> virgil doesn't have egl though?
[13:08] <Prf_Jakob> its a gallium driver, so I guess it does.
=== greyback|lunch is now known as greyback
=== dandrader is now known as dandrader|lunch
[15:00] <mterry> Hello!  I see a problem in nested Mir mode with autopilot input (both host and nested Mir see input, but don't act on it).  I've got some time to investigate on my own now and I was wondering if anyone had any pointers to likely culprits?
=== dandrader|lunch is now known as dandrader
[16:01] <kgunn> alf_: racarr  ^ see post from mterry
=== chihchun is now known as chihchun_afk
=== dandrader is now known as dandrader|afk
[16:16] <alf_> kdub: http://paste.ubuntu.com/6365435/
[16:31] <alf_> mterry: I don't if it's relevant in your scenario: if there isn't a focused window, input gets dropped
[16:31] <alf_> +know
[16:31] <mterry> alf_, this seems to be a difference between running nested and not.  Like I'm running the same autopilot test in each case, so it's probably not a focus issue
[16:33] <alf_> mterry: is there a manual way to reproduce this, or does it happen with autopilot only?
[16:37] <alf_> kdub: also as a second test: http://paste.ubuntu.com/6365552/ i.e. check that the device can display buffers that are also marked as texture-capable
[16:38] <kdub> alf_, i'm not as worried about the 'second test'
[16:39] <alf_> kdub: fair enough :)
[16:39] <mterry> alf_, looks like I got disconnected.
[16:39] <mterry> mterry> alf_, I've only seen it with autopilot
[16:42] <alf_> mterry: can you track where the input event messages stop?
[16:42] <alf_> mterry: I mean in which component in mir or unity8
[16:46] <mterry> alf_, that's my next step, yeah.  But it's affecting both unity8 and apps, so it's probably not unity8-specific
[17:42] <mhall119> so I've been running Mir on my x220 laptop for about a week now, and so far so good, but has anybody had an issue where the screen flickers sometimes when Chromium is reloading a page?  I've only seen it do this on G+, and not all the time
[17:48] <mhall119> w 80
[17:57] <mhall119> ah, still flickering in r10 on the Nexus 7 :(
[17:59] <davmor2> mhall119: you don't know what flickering is till you install a unity3d app :)
[18:10] <mhall119> also, on both my phone and my laptop, if the screen turns off and I turn it back on (power button on the phone, mouse movemenet on the laptop) I see what was displayed before it shut off for a split second before it goes to the lock/welcome screen
[18:10] <mhall119> is that a known bug or should I file it?
[18:12] <mhall119> kgunn: ^^ ?
[18:13] <racarr> mhall119: I think its 'known' but im not aware of a bug filed
=== thomi_ is now known as thomi
[20:12] <kgunn> time flies...eating a very late lunch
[20:28] <kgunn> and back
[20:33] <ogra_> lunch flies too then :)
[21:00] <kgunn> racarr: you still working on the mir on mir (or is it side by side) mir bugs ?
[21:18] <racarr> kgunn: Yes  I'm tryingto findwhy input is failing under autopilot now
[21:18] <kgunn> racarr: that's cool....was just wondering
[21:19] <kgunn> thinking....i'd like to satisfy thomi 's request for fb grabbing and input coordinates (probed) from AP
[21:19] <kgunn> racarr: but that change would likely be a shell change maybe ?...e.g. i don't think AP would talk direct to mir
[21:20] <kgunn> thomi: ^ or do you even care what you talk to ?
[21:20] <kgunn> you = AP in this case :)
[21:20] <kgunn> btw, i watched Pi...
[21:20] <kgunn> i want those minutes of my life back :)
[21:24] <thomi> kgunn: haha
[21:25] <thomi> kgunn: AP doesn't really care who we talk to. I guess the important thing  is that it's relatively easy to communicate from python, and that there's not a huge delay involved
[21:25] <thomi> but dbus would be fine I think
[21:27] <racarr> kgunn: Seems kind of like dbus to the shellyeah
[21:29] <kgunn> thomi: i also watched scanner darkly way better
[21:34] <thomi> yeah, that's a good movie
[21:56] <kgunn> racarr: kdub ....any volunteers to review and approve ? https://code.launchpad.net/~mir-team/mir/development-branch/+merge/194018
[21:56] <kgunn> our branch is getting stale
[21:56] <kdub> i can review
[21:56] <kgunn> kdub: ta
[21:58] <kdub> kgunn, why do we go from so.9 to so.10?
[21:58] <kdub> sorry, to so.11
[21:59] <kgunn> kdub: yeah i noticed that as well....i think alan subsequently broke again...so he bumped again
[21:59] <kgunn> kdub: related to my statement about didrocks wanting per comit survivability
[21:59] <kgunn> kdub: it doesn't hurt anything...but its odd
[22:04] <kdub> kgunn, well, i approved
[22:09] <RAOF> tvoss_: Somewhat belated bong.
[22:17] <RAOF> Or even pong.
[23:51] <kgunn> RAOF: just fyi....i have every intention of showing up at the 1am
[23:51] <kgunn> bailing for dinner now...