=== 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
anpokduflu: i put the prereq back on wip indicating that I will rework it now.09:13
anpokhi btw09:13
dufluanpok: 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 order09:18
alan_galf_: Happy new year09:54
alf_alan_g: Happy new year to you too!09:55
* duflu -> dinner10:07
=== greyback_ is now known as greyback
RAOFdidrocks: 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:20
didrocksRAOF: you have something without SONAME which is going to break libmirclient and server?10:21
RAOFdidrocks: Indeed10:21
RAOFI intend to break the protocol (by introducing a way to break protocol without requiring lockstep upgrades, so this should happen exactly once)10:22
didrocksRAOF: what other source package is going to break libmir* ?10:22
RAOFNo 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:23
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:25
RAOFdidrocks: libmirclientN will break libmirserver, and libmirserver will break libmirclient10:27
didrocksRAOF: so, basically, you will place the breaks on source package producing xserver-xorg-xmir, libubuntu-application-api-mirclient1, libunity-mir1 and unity-system-compositor10:27
didrocksRAOF: ah, only between those 210:27
didrocksok, so, feel free to do it at any time, this doesn't really impact us10:27
didrocksor told differently…10:28
didrocksit impacts us way less than ABI breaks :p10:28
didrocksat 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
RAOFYeah, 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:31
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:41
greybackalf_: qt5-qmake might me the culprit10:42
=== chihchun is now known as chihchun_afk
alf_greyback: I have it... anyway, calling /usr/lib/arm-linux-gnueabihf/qt5/bin/qmake directly works, something must be messed up with qtchooser10:46
greybackalf_: qt5-default then :)10:47
alf_greyback: great, thanks :)10:48
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:01
alf_greyback: I am running as "phablet" after having stopped "unity8" in a clean touch installation11:02
greybackalf_: interesting, wonder how that broke (upstart-app-launch the source of that message)11:02
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 after11:03
greybackalf_: 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: yes11:04
greybackalf_: sounds stupid, but maybe reboot the device, and check if unity can launch apps first11:06
alf_greyback: ok11:06
alf_greyback: apps start ok in unity8, although unity8 seems to hang after I open 3-4 of them11:12
greybackalf_: did you just do a clean flash of latest devel image? I'll have to investigate this11:13
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 works11:16
alf_greyback: so unity8 must be causing something (upstart?) to crash11:16
greybackalf_: which is bizarre, but could he happening. I'll see if I can reproduce.11:17
greybackalf_: will make working on this bug that little more frustrating too :(11:17
alf_greyback: btw, with qml-demo-shell I mostly get blank (black) snapshots on the left11:18
greybackalf_: tap it. That'll refresh the snapshot11:18
greybackfirst snapshot taken too early, hence black11:19
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 rectangle11:21
greybackalf_: let me update my device and try it. For me, I get the whole snapshot (smaller though)11:24
=== alan_g is now known as alan_g|tea
alf_greyback: ok, I got what happens... when I start a second up a new black rectangle appears11:29
alf_greyback: I will stick to one app for now11:30
greybackalf_: have you enough info to proceed? Can I help/simplify the demo?11:30
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
greybackalf_: very well, best of luck!11:36
=== 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
kgunnalf_: welcome back...and thanks for hopping on the weird one13:57
alf_kgunn: thanks, and happy new year :)13:58
=== 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
anpokkdub: I am following you suggesting to make these utilities as transparent wrapper class15:28
anpokwhy did you suggested mir::geometry? I would think mir::graphics would be a better fit.15:28
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
ubot5Ubuntu bug 1263741 in Mir "Some snapshots on Nexus10 upside-down" [Critical,Triaged]16:19
kdubthe plot is thickening then16:20
kdubi think there's some interference between the compositor thread and the snapshot thread somehow16:20
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:22
kdubalf, yeah, one min16:23
kdubalf_,  i think a robust solution here would just be to16:23
kdublet the mg::Buffer provide the pixel data in a native way (on android, this would be to map the ashmem buffer)16:24
kdubthen we avoid all the GL headaches16:24
kdubalf_, https://bugs.launchpad.net/mir/+bugs?field.tag=nexus716:25
kduboops https://bugs.launchpad.net/mir/+bug/123869516:25
ubot5Ubuntu bug 1238695 in Mir "unity8 display flickers and stops responding on Nexus 7 (grouper)" [High,In progress]16:25
alf_kdub: do we have access to any debugging information from the driver?16:28
kdubeh, 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:29
kdubi think that mapping the ashmem buffers is more robust for android16:32
kdublet me see if i can do a survey of how sf does this16:32
alf_kdub: yeah... unfortunately the desktop still needs this (we can't map the hardware buffers)16:33
kdubwell, thats okay though16:34
alf_kdub: (can't map and read linear pixel information)16:34
kdubthat would just be how the mesa platform does the pixel read operation16:34
kduband the android platform would map16: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 it16:35
kdubseems there's a need now, if just to improve robustness/memory considerations16:37
kdubalf_, do you have any insight on the nexus 10 upside down thing?16:38
kdubmaybe it just fails with OUT_OF_MEMORY and then just keeps flipping the pixel buffer16:38
alf_kdub: yes, on error it gives out the previous data16:39
alf_kdub: which get flipped again16:39
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 itself16:43
kdubalf_, i prefer the first one, still poking around to see how others get at the pixel data16:45
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:50
kdubokay, cool. my initial instinct is that i'd have a mga::PixelBuffer::PixelBuffer(mg::Buffer) and leave the interfaces for Buffer/PixelBuffer alone16:53
=== dandrader_ is now known as dandrader
alf_kdub: Why is the buffer needed in the constructor (vs the current PixelBuffer::fill_from(mg::Buffer))?16:55
kdubI guess that could work too, so PixelBuffer would take the platform in its constructor, and then use a platform-specific way to fill the pixels16: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 platform16:57
kdubi'm okay with that too16:58
alf_kdub: ok, I will work on that tomorrow then, and we can discuss more when we have something concrete17:00
kdubsounds good17:00
=== davmor2_ is now known as davmor2
=== alan_g is now known as alan_g|EOD
anpokwhat files do I have to touch for an ABI break - I found src/client/CMakeLists.txt20:10
anpokdo I need to change something in debian/?20:10
kgunnanpok: one moment...20:11
kgunnanpok: digging out a mail that outlines it...20:11
Saviqkgunn, hey, we'd need someone Mir to look at https://code.launchpad.net/~allanlesage/unity8/indicator-stubs/+merge/192059/comments/46404920:30
thomiSaviq: 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 mir20:31
Saviqkgunn, we've worked around bug #1238417 some time before, but that workaround seems to be limited to a certain number of tests20:31
ubot5bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete] https://launchpad.net/bugs/123841720:31
Saviqthomi, yup20:31
thomiSaviq: 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
Saviqthomi, I've tried del'ing the device before creating a new one, but with GC it probably never really kicked in20:32
Saviqthomi, yeah, but if the device node is already there... how would that explain what we're seeing?20:32
thomiSaviq: 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 mir20:32
Saviqthomi, +120:33
thomiand we'd still need the ugly workaround in the test suite20:33
Saviqthomi, if it wouldn't pick up existing devices, it wouldn't pick up the real ones (touch) in the first place?20:33
thomiSaviq: it picks up existing devices just fine20:33
Saviqthomi, yeah exactly, and the *first* test in a unity8 autopilot run completes, so it detects a new one as well20:34
Saviqthomi, so that doesn't seem to explain why it wouldn't pick up an existing one after it's restarted once20:34
thomithe 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 permissions20:34
thomiso mir fails to open the device, and never tries again20:34
thomiif we switched to using the correct library to detect new device nodes, we'd get notified at the correct timne20:35
Saviqthomi, the inode is only created once per autopilot, though, isn't it?20:36
thomiSaviq: no, it's created once every time you create the input device20:36
thomiso without the workaround, it's once per AP process run. With the workaround, it's once per test20:36
thomithe latter case is causing the second, related issue20:37
Saviqthomi, 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:37
thomiSaviq: no, because usually the device is created before the SUT starts, which gives it enough time to get set up properly20:38
thomiso under normal situations, this works fine20:38
Saviqthomi, ok, so why does the second test fail? permissions are stable then?20:38
Saviqthomi, sorry if I'm being daft, I just want as many details as possible20:39
thomi(I'm guessing here) because with the workaround creates a new device per test20:39
Saviqthomi, so you think inotify is triggered20:40
Saviqthomi, so basically the first device created somehow gets stale20:40
thomiSaviq: 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 it20:40
Saviqthomi, sure, just wanted to understand some more20:40
kgunnphew...ok anpok sorry...decided to just send you a clean set of instructions...20:42
kgunnlet me know if that doesn't clear it up20:42
thomiSaviq: so if you don't get nay joy from the mir team, you can explicitly close the uinput device before creating a new one20:42
thomiSaviq: it seems that python-evdev doesn't do that for you20:42
Saviqthomi, I *think* I tried that20:42
thomiSaviq: but that still doesn't fix the underlying issue, but it *should* make your tests pass again :)20:42
Saviqthomi, but yeah, will push for a fix anyway20:43
thomiSaviq: calling 'my_device.close()' ?20:43
kgunnracarr: can i come at you from left field to ask if you can potentially help fix this ^20:43
Saviqthomi, it was before Christmas, so...20:43
kgunnthomi: i assume this is what you were going to ping me about ?20:43
thomikgunn: yup :)20:44
ubot5Ubuntu bug 1237784 in Mir "[enhancement] Please move input detection to libudev" [Low,Triaged]20:45
anpok^ that change?20:45
anpokkgunn: thank you20:45
kgunnracarr: seems we have "disappearing input" https://bugs.launchpad.net/mir/+bug/123841720:47
ubot5Ubuntu bug 1238417 in Mir "Unity does not process events from evdev device created before unity is restarted (autopilot tests)" [Critical,Incomplete]20:47
kgunnand yes...it could be related to the bug you just posted anpok20:47
Saviqwhoa that's a nice bunch of bugs that could get squashed with this20:47
thomikgunn: that sounds like *exactly* what pitti suggested as well20:47
Saviqthomi, it's pitti's bug ;)20:47
thomiSaviq: oh, well...20:47
kgunni would hope he sounds like himsel20:48
thomino wonder then :)20:48
* thomi needs more coffee, brb20:48
kgunnracarr: 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 stuff20:51
kgunni'm not familiar enough...but this looks like it might be a chunk of work20:52
kgunn(not a matter of tracking down a simple bug ...)20:52

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!