=== chihchun_afk is now known as chihchun
=== jono is now known as Guest91841
=== RAOF_ is now known as RAOF
=== duflu_ is now known as duflu
=== OutOfControl is now known as benonsoftware
=== tjaalton_ is now known as tjaalton
[09:13] <anpok> duflu: i put the prereq back on wip indicating that I will rework it now.
[09:13] <anpok> hi btw
[09:14] <duflu> Hello
[09:18] <duflu> anpok: If nothing else, Jenkins will refuse to land an approved branch if it depends on something else not yet landed. So you'll save yourself time, trying to keep them in order
[09:54] <alan_g> alf_: Happy new year
[09:55] <alf_> alan_g: Happy new year to you too!
[10:07]  * duflu -> dinner
=== greyback_ is now known as greyback
[10:20] <RAOF> didrocks: How much trouble would a Breaks: libmirclientN (<< $SOMEVER) and Breaks: libmirserver (<< $SOMEVER) to ensure a lockstep upgrade be for you, and at what point in the cycle would it become too much trouble?
[10:21] <didrocks> RAOF: you have something without SONAME which is going to break libmirclient and server?
[10:21] <RAOF> didrocks: Indeed
[10:22] <RAOF> I intend to break the protocol (by introducing a way to break protocol without requiring lockstep upgrades, so this should happen exactly once)
[10:22] <didrocks> RAOF: what other source package is going to break libmir* ?
[10:23] <RAOF> No other source package, but clients linked against old libmirclientN won't be able to talk to servers linked against new libmirserver and visa versa.
[10:25] <RAOF> (Of course, the Breaks: itself isn't entirely sufficient, as it'll break a session if you upgrade the libs mid-session. Fortunately, the phone doesn't do that)
[10:27] <RAOF> didrocks: libmirclientN will break libmirserver, and libmirserver will break libmirclient
[10:27] <didrocks> RAOF: so, basically, you will place the breaks on source package producing xserver-xorg-xmir, libubuntu-application-api-mirclient1, libunity-mir1 and unity-system-compositor
[10:27] <RAOF> didrocks:
[10:27] <didrocks> RAOF: ah, only between those 2
[10:27] <didrocks> ok, so, feel free to do it at any time, this doesn't really impact us
[10:28] <didrocks> or told differently…
[10:28] <didrocks> it impacts us way less than ABI breaks :p
[10:28] <didrocks> at the same time, in a release, there is a high chance to have an ABI break as well, so even the Breaks will probably be redundant :)
[10:28] <RAOF> :)
[10:31] <RAOF> Yeah, this affects the touch images not very much. But would be evil on a desktop, where you can upgrade without restarting. So I'd like to do it before we have any real desktop users. :)
[10:41] <alf_> greyback: Hi! I am trying to build lp:~gerboland/+junk/qml-demo-shell/ on Nexus 10 but I am getting "qmake: could not find a Qt installation of ''". I have installed the packages you mention in the bug report. Any idea what I could be missing?
[10:42] <greyback> alf_: qt5-qmake might me the culprit
=== chihchun is now known as chihchun_afk
[10:46] <alf_> greyback: I have it... anyway, calling /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake directly works, something must be messed up with qtchooser
[10:47] <greyback> alf_: qt5-default then :)
[10:48] <alf_> greyback: great, thanks :)
[11:01] <alf_> greyback: ok, managed to build and run, but when I tap on e.g. 'Dialer' it complains: "** (process:13065): WARNING **: Unable to emit signal 'application-start'
[11:01] <alf_> Asking Upstart to start application 'dialer-app' failed"
[11:02] <alf_> greyback: I am running as "phablet" after having stopped "unity8" in a clean touch installation
[11:02] <greyback> alf_: interesting, wonder how that broke (upstart-app-launch the source of that message)
[11:03] <alf_> greyback: tapping a second time prints: "(null):dbus_error.c:69: Unhandled error from nih_dbus_error_raise: Name "com.ubuntu.Upstart" does not exist" and crashes shortly after
[11:04] <greyback> alf_: yeah, it's like upstart isn't there. It didn't get removed by any chance. Does "initctl list" list some processes?
[11:04] <alf_> greyback: yes
[11:06] <greyback> alf_: sounds stupid, but maybe reboot the device, and check if unity can launch apps first
[11:06] <alf_> greyback: ok
[11:12] <alf_> greyback: apps start ok in unity8, although unity8 seems to hang after I open 3-4 of them
[11:13] <greyback> alf_: did you just do a clean flash of latest devel image? I'll have to investigate this
[11:16] <alf_> greyback: yes, ubuntu-system channel devel, but just a moment... if I reboot and immediately stop unity8 (without first causing it to hang), qml-demo-shell works
[11:16] <alf_> greyback: so unity8 must be causing something (upstart?) to crash
[11:17] <greyback> alf_: which is bizarre, but could he happening. I'll see if I can reproduce.
[11:17] <greyback> alf_: will make working on this bug that little more frustrating too :(
[11:18] <alf_> greyback: btw, with qml-demo-shell I mostly get blank (black) snapshots on the left
[11:18] <greyback> alf_: tap it. That'll refresh the snapshot
[11:19] <greyback> first snapshot taken too early, hence black
[11:21] <alf_> greyback: hmm, it seems that I always get a black rectangle "over" the snapshots. I see a couple of line from the snapshot and then a black rectangle
[11:24] <greyback> alf_: let me update my device and try it. For me, I get the whole snapshot (smaller though)
=== alan_g is now known as alan_g|tea
[11:29] <alf_> greyback: ok, I got what happens... when I start a second up a new black rectangle appears
[11:30] <alf_> greyback: I will stick to one app for now
[11:30] <greyback> alf_: have you enough info to proceed? Can I help/simplify the demo?
[11:36] <alf_> greyback: It should be OK for now, I can reproduce the upside-down problem. I will let you know if I need something more, thanks!
[11:36] <greyback> alf_: very well, best of luck!
=== alan_g|tea is now known as alan_g
=== alan_g is now known as alan_g|lunch
=== dandrader is now known as dandrader|afk
=== dandrader|afk is now known as dandrader
[13:57] <kgunn> alf_: welcome back...and thanks for hopping on the weird one
[13:58] <alf_> kgunn: thanks, and happy new year :)
=== alan_g|lunch is now known as alan_g
=== ricmm|sick is now known as ricmm
=== bregma_ is now known as bregma
=== dandrader is now known as dandrader|lunch
[15:28] <anpok> kdub: I am following you suggesting to make these utilities as transparent wrapper class
[15:28] <anpok> why did you suggested mir::geometry? I would think mir::graphics would be a better fit.
[16:19] <alf_> kdub: it turns out what you are seeing on Nexus 7 is related to https://bugs.launchpad.net/mir/+bug/1263741 . When we snapshot we occasionally get an OUT_OF_MEMORY error and give back stale data.
[16:19] <ubot5> Ubuntu bug 1263741 in Mir "Some snapshots on Nexus10 upside-down" [Critical,Triaged]
[16:20] <kdub> interesting
[16:20] <kdub> the plot is thickening then
[16:20] <kdub> i think there's some interference between the compositor thread and the snapshot thread somehow
[16:22] <alf_> kdub: according to GL docs after an OUT_OF_MEMORY error all bets are off (the state of the GL becomes undefined)
[16:22] <alf_> kdub: do we have a bug for the n7 issues?
[16:23] <kdub> alf, yeah, one min
[16:23] <kdub> alf_,  i think a robust solution here would just be to
[16:24] <kdub> let the mg::Buffer provide the pixel data in a native way (on android, this would be to map the ashmem buffer)
[16:24] <kdub> then we avoid all the GL headaches
[16:25] <kdub> alf_, https://bugs.launchpad.net/mir/+bugs?field.tag=nexus7
[16:25] <kdub> oops https://bugs.launchpad.net/mir/+bug/1238695
[16:25] <ubot5> Ubuntu bug 1238695 in Mir "unity8 display flickers and stops responding on Nexus 7 (grouper)" [High,In progress]
[16:28] <alf_> kdub: do we have access to any debugging information from the driver?
[16:29] <kdub> eh, not too much.. it just seems that the n7 will give a GL_OUT_OF_MEMORY from glEGLTargetTexture2D when trying to use the EGLImage as a texture (when the texture is tied to the fbo)
[16:32] <kdub> i think that mapping the ashmem buffers is more robust for android
[16:32] <kdub> let me see if i can do a survey of how sf does this
[16:33] <alf_> kdub: yeah... unfortunately the desktop still needs this (we can't map the hardware buffers)
[16:34] <kdub> well, thats okay though
[16:34] <alf_> kdub: (can't map and read linear pixel information)
[16:34] <kdub> that would just be how the mesa platform does the pixel read operation
[16:35] <kdub> and the android platform would map
[16:35] <alf_> kdub: the original intention of pixelbuffer was for each platform to provide its own implementation, but the GL one seemed to work well until now, so there was no need for it
[16:37] <kdub> seems there's a need now, if just to improve robustness/memory considerations
[16:38] <kdub> alf_, do you have any insight on the nexus 10 upside down thing?
[16:38] <kdub> maybe it just fails with OUT_OF_MEMORY and then just keeps flipping the pixel buffer
[16:39] <alf_> kdub: yes, on error it gives out the previous data
[16:39] <alf_> kdub: which get flipped again
[16:39] <kdub> right
[16:43] <alf_> kdub: we either need to provide 1. platform specific pixelbuffer implementations, or 2. go the fix-1238695 way, changing mg::Buffer to know how to provied the data itself
[16:45] <kdub> alf_, i prefer the first one, still poking around to see how others get at the pixel data
[16:50] <alf_> kdub: +1 for (1). Let me know how you get on with it. Perhaps we could save time if I take care of the infrastructural part so you only need to take care of the Android implementation?
[16:53] <kdub> okay, cool. my initial instinct is that i'd have a mga::PixelBuffer::PixelBuffer(mg::Buffer) and leave the interfaces for Buffer/PixelBuffer alone
=== dandrader_ is now known as dandrader
[16:55] <alf_> kdub: Why is the buffer needed in the constructor (vs the current PixelBuffer::fill_from(mg::Buffer))?
[16:57] <kdub> I guess that could work too, so PixelBuffer would take the platform in its constructor, and then use a platform-specific way to fill the pixels
[16:57] <alf_> kdub: I was thinking something along the lines of PixelBuffer Platform::create_pixel_buffer(), so that the implementation is completely internal to each platform
[16:58] <kdub> i'm okay with that too
[17:00] <alf_> kdub: ok, I will work on that tomorrow then, and we can discuss more when we have something concrete
[17:00] <kdub> sounds good
=== davmor2_ is now known as davmor2
=== alan_g is now known as alan_g|EOD
[20:10] <anpok> what files do I have to touch for an ABI break - I found src/client/CMakeLists.txt
[20:10] <anpok> do I need to change something in debian/?
[20:11] <kgunn> anpok: one moment...
[20:11] <kgunn> anpok: digging out a mail that outlines it...
[20:30] <Saviq> kgunn, hey, we'd need someone Mir to look at https://code.launchpad.net/~allanlesage/unity8/indicator-stubs/+merge/192059/comments/464049
[20:31] <thomi> Saviq: so I agree that there's a bug somewhere in autopilot or (more likely) python-evdev - it seems that perhaps the device resources aren't being deleted. HOWEVER, we're only seeing that because we need this nasty workaround due to the bug in mir
[20:31] <Saviq> kgunn, we've worked around bug #1238417 some time before, but that workaround seems to be limited to a certain number of tests
[20:31] <ubot5> bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete] https://launchpad.net/bugs/1238417
[20:31] <Saviq> thomi, yup
[20:32] <thomi> Saviq: kgunn: IIRC, pitti looked at this, and said soemthing along the lines of "mir uses inotify to detect new device nodes, which is the wrong way to do it" - I believe he said the correct way was to use the evdev library instead?
[20:32] <Saviq> thomi, I've tried del'ing the device before creating a new one, but with GC it probably never really kicked in
[20:32] <Saviq> thomi, yeah, but if the device node is already there... how would that explain what we're seeing?
[20:32] <thomi> Saviq: I suspect that python-evdev doesn't close the device when you delete the python object. I could spend time looking into that, but we'd still have the problem in mir
[20:33] <Saviq> thomi, +1
[20:33] <thomi> and we'd still need the ugly workaround in the test suite
[20:33] <Saviq> thomi, if it wouldn't pick up existing devices, it wouldn't pick up the real ones (touch) in the first place?
[20:33] <thomi> Saviq: it picks up existing devices just fine
[20:34] <Saviq> thomi, yeah exactly, and the *first* test in a unity8 autopilot run completes, so it detects a new one as well
[20:34] <Saviq> thomi, so that doesn't seem to explain why it wouldn't pick up an existing one after it's restarted once
[20:34] <thomi> the problem is that when the inode is created, mir gets notified, but at that stage the evdev rules haven't been applied yet, so we don't have write permissions
[20:34] <thomi> so mir fails to open the device, and never tries again
[20:35] <thomi> if we switched to using the correct library to detect new device nodes, we'd get notified at the correct timne
[20:35] <thomi> *time
[20:36] <Saviq> thomi, the inode is only created once per autopilot, though, isn't it?
[20:36] <thomi> Saviq: no, it's created once every time you create the input device
[20:36] <thomi> so without the workaround, it's once per AP process run. With the workaround, it's once per test
[20:37] <thomi> the latter case is causing the second, related issue
[20:37] <Saviq> thomi, yeah exactly, so if it would be permission problems, no tests would work (or actually we should see the first test failing, and subsequent ones passing)
[20:38] <thomi> Saviq: no, because usually the device is created before the SUT starts, which gives it enough time to get set up properly
[20:38] <thomi> so under normal situations, this works fine
[20:38] <Saviq> thomi, ok, so why does the second test fail? permissions are stable then?
[20:39] <Saviq> thomi, sorry if I'm being daft, I just want as many details as possible
[20:39] <thomi> (I'm guessing here) because with the workaround creates a new device per test
[20:40] <Saviq> thomi, so you think inotify is triggered
[20:40] <Saviq> thomi, so basically the first device created somehow gets stale
[20:40] <thomi> Saviq: so at this point I'm guessing... we need someone from the mir team to look at this. The fact that pitti looked at it and came back pretty quickly with both a problem description & potential solution indicates to me that we know what the issue is, we just need to fix it
[20:40] <Saviq> thomi, sure, just wanted to understand some more
[20:42] <kgunn> phew...ok anpok sorry...decided to just send you a clean set of instructions...
[20:42] <kgunn> let me know if that doesn't clear it up
[20:42] <thomi> Saviq: so if you don't get nay joy from the mir team, you can explicitly close the uinput device before creating a new one
[20:42] <thomi> Saviq: it seems that python-evdev doesn't do that for you
[20:42] <Saviq> thomi, I *think* I tried that
[20:42] <thomi> Saviq: but that still doesn't fix the underlying issue, but it *should* make your tests pass again :)
[20:43] <Saviq> thomi, but yeah, will push for a fix anyway
[20:43] <thomi> Saviq: calling 'my_device.close()' ?
[20:43] <kgunn> racarr: can i come at you from left field to ask if you can potentially help fix this ^
[20:43] <Saviq> thomi, it was before Christmas, so...
[20:43] <kgunn> thomi: i assume this is what you were going to ping me about ?
[20:44] <thomi> kgunn: yup :)
[20:45] <anpok> https://bugs.launchpad.net/mir/+bug/1237784
[20:45] <ubot5> Ubuntu bug 1237784 in Mir "[enhancement] Please move input detection to libudev" [Low,Triaged]
[20:45] <anpok> ^ that change?
[20:45] <anpok> kgunn: thank you
[20:47] <kgunn> racarr: seems we have "disappearing input" https://bugs.launchpad.net/mir/+bug/1238417
[20:47] <ubot5> Ubuntu bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete]
[20:47] <kgunn> and yes...it could be related to the bug you just posted anpok
[20:47] <Saviq> whoa that's a nice bunch of bugs that could get squashed with this
[20:47] <thomi> kgunn: that sounds like *exactly* what pitti suggested as well
[20:47] <Saviq> thomi, it's pitti's bug ;)
[20:47] <thomi> Saviq: oh, well...
[20:48] <kgunn> i would hope he sounds like himsel
[20:48] <thomi> no wonder then :)
[20:48] <kgunn> f
[20:48] <kgunn> :)
[20:48]  * thomi needs more coffee, brb
[20:51] <kgunn> racarr: actually...after reading thru pitti's bug again...is this something RAOF  may want to be doing as he was tearing up subfloor on the input stuff
[20:52] <kgunn> i'm not familiar enough...but this looks like it might be a chunk of work
[20:52] <kgunn> (not a matter of tracking down a simple bug ...)