[00:07] <cnd> bregma, I've got a pristine checkout of lp:utouch-geis here
[00:07] <cnd> make check is failing for GeisSubscriptionTests.duplicate_window_subscription
[00:07] <cnd> gtest_subscriptions.cpp:91: Failure
[00:07] <cnd> Expected: (GEIS_STATUS_SUCCESS) != (geis_subscription_activate(sub2)), actual: 0 vs 0
[00:07] <cnd> mistakenly activated subscription 2
[00:08] <cnd> we'll need to get that fixed before releasing anything
[00:21] <bregma> so how does your utouch stack differ from my utouch stack (I've had a few pristine checkouts since that test went in and it continues to pass on every rebuild)
[00:25] <cnd> hmm
[00:25] <cnd> I don't know
[00:25] <cnd> I'll have to investigate
[00:25] <cnd> in the meantime, I'm finding a geis bug where the number of touches in a geis gesture is not being set properly
[00:25] <cnd> I'm tracking it down
[00:25] <cnd> well, I think it's a geis bug :)
[01:30] <cnd> oh right, it's a grail bug that I wrote a fix for but hadn't gotten around to writing a testcase for
[01:31] <bregma> is there a bug for it?
[01:37] <cnd> not yet, though I think it's a separate issue again
[15:16]  * bregma stands up, looking around.....
[15:17] <tvoss> Working on #950974, deployed BuildService server to staging jenkins, updated documentation on builder setup
[15:17]  * tvoss stands up as well
[15:17] <cnd> I'm working on a utouch bugs that are resulting in issues in unity
[15:17] <tvoss> cnd, dandrader, ping
[15:18] <dandrader> tvoss, pong
[15:18] <cnd> I may have a fix for bug 940308
[15:18] <dandrader> I'm working on making that 3-touches gesture to move windows around work again (in unity code)
[15:19] <tvoss> dandrader, just ping'd for standup :)
[15:19] <cnd> tvoss, does the merge proposal script work now?
[15:20] <tvoss> yeah, I'm preparing a follow-up mail on the call for testing and send out instructions
[15:20] <cnd> cool
[15:20] <tvoss> you do not need to interact with script any more
[15:20] <dandrader> tvoss, a web ui now?
[15:20] <tvoss> dandrader, yeah, a very simple one, but a web ui ;)
[15:21] <dandrader> cool
[15:21] <tvoss> or curl, if you like that better
[15:21] <bregma> I'm beating my pulpy head against the wall trying to figure out why the basic compile checks segfault when utouch-geis is buitl in a PPA (and not in a pbuilder)
[15:21] <dandrader> i've now problems with a web ui
[15:21] <dandrader> s/now/no
[15:23] <tvoss> bregma, is it always failing or only on some builds?
[15:23] <bregma> always fails, only in PPA
[15:41] <tvoss> bregma, I remember a thread on some mailing-list about "corrupt" ppa builders
[15:41] <tvoss> bregma, for that I asked
[15:48] <bregma> I don;t think that's the problem here, more liekely something to do with PPA kernels disallowing pipes to be opened from built apps or something
[15:49] <bregma> I beleive I can force a stacktrace but the build backlog is on the order of hours, so turnaround is slow
[15:49] <bregma> it feels like software development in the 1980s again
[15:59]  * tvoss sighs
[17:41] <cnd> bregma, got an issue with geis that we can resolve in a couple ways
[17:41] <cnd> when a "system" geis v1 tap subscription is created
[17:41] <cnd> the min touches is set to 1 instead of matching the start touches
[17:42] <cnd> what ends up happening is a tap gesture is recognized by grail, but it continues to send events all the way down to when only 1 touch is left on the device
[17:42] <cnd> so if you do a two-touch tap you might get from grail:
[17:42] <cnd> gesture begin: 1 touch, no gesture
[17:43] <cnd> gesture update: 2 touches, no gesture
[17:43] <cnd> gesture update: 1 touch, no gesture
[17:43] <cnd> gesture end: 1 touch, tap recognized
[17:43] <cnd> because geis v1 does not allow for tentative events, we transform that into one geis v1 event:
[17:44] <cnd> geis gesture update: 1 touch, tap recognized
[17:44] <cnd> when it should have been:
[17:44] <cnd> geis gesture update: 2 touch, tap recognized
[17:44] <cnd> I'm thinking the best way to resolve this is to only set minimum touches to 1 for non-tap system gestures
[17:45] <cnd> what do you think?
[17:45] <bregma> did it not give the 2-tap gesture event?
[17:46] <cnd> grail is giving a "gesture", which in the end slice is a 1-touch tap
[17:46] <cnd> but in the middle of the gesture there was a slice with 2-touches
[17:46] <cnd> but only the end slice is transformed into the geis v1 gesture event
[17:46] <cnd> which is why it says only 1 touch
[17:47] <bregma> I mean the original grail, you;re saying it never gave the 2-tap gesture?
[17:47] <cnd> the original grail probably did not honor the system flag for tap events
[17:47] <bregma> mmm
[17:48] <cnd> an alternative would be to keep the max touch count of a gesture in the geis gesture state
[17:48] <cnd> and when emitting a tap gesture, emit it with the max number of touches
[17:48] <cnd> but then we have to keep around more state, such as each touch position
[17:49] <cnd> I think that would be a hairy solution
[17:49] <bregma> that would effectively be moving gesture recognition out of the recognizer and into geis
[17:49] <cnd> yeah
[17:50] <bregma> a tap event is already a special case, what with not haveing a begin and an end
[17:50] <bregma> I see nothing wrong with treating it special in other ways
[17:50] <cnd> bregma, is not setting the min touches to 1 for a system tap gesture alright with you?
[17:51] <cnd> I can whip up a patch for it fairly quickly I think
[17:51] <bregma> yes, I'm fine wit hthat
[17:51] <cnd> ok
[17:52] <bregma> ... it looks like the build failures I see in the PPA are _bash_ segfaulting, not the test program
[17:52] <bregma> curiouser and curiouser
[17:53] <cnd> bregma, it looks like bash segfaults when the program executed at make check segfaults
[17:53] <cnd> that's been my experience
[17:53] <cnd> bregma, do you have the build log url?
[17:53] <cnd> I can see if it matches what I've seen before
[17:54] <bregma> https://launchpadlibrarian.net/96910377/buildlog_ubuntu-precise-i386.utouch-geis_2.2.6%2Br217%2Bp159~ppa2_FAILEDTOBUILD.txt.gz
[17:54] <bregma> in this run, I run the test program in valgrind to catch and display a traceback of the segfault
[17:54] <cnd> ahh
[17:55] <cnd> yeah, this is the test segfaulting
[17:55] <cnd> not bash
[17:55] <bregma> bash still appears to segfault
[17:55] <bregma> you mean, the test segfaults and valgrin is not catching it?
[17:55] <cnd> bregma, are you referring to this line: /bin/bash: line 5: 30068 Segmentation fault      valgrind ${dir}$tst
[17:55] <cnd> ?
[17:55] <bregma> yep
[17:55] <cnd> yeah, I've seen that exact message before
[17:56] <cnd> it's not bash segfaulting, it's valgrind
[17:56] <cnd> I thought the same thing when I first saw it
[17:57] <cnd> and RAOF told me what's really going on :)
[17:57] <cnd> I have no idea why those tests would segfault though...
[17:57] <bregma> I have always assumed it's the app segfaulting, but it makes no sense valgrind would be degfaulting here
[17:58] <cnd> bregma, maybe remove valgrind and add a signal handler to the testcases to get a backtrace?
[17:58] <cnd> it's a pretty heavy-handed approach, but it might work
[17:58] <bregma> I added valgrind to get the backtrace -- valgrind will give a backtrace if the app it's running segfaults
[17:58] <bregma> without valgrind you get the same message, except without the valgrind
[17:59] <cnd> hmm
[17:59] <bregma> as you can see, valgrind is not catching any errors with the app
[17:59] <cnd> what if it's segfaulting at program exit/cleanup time?
[17:59] <bregma> the package builds cleanly using sbuild and pbuilder on my machine
[18:00] <cnd> maybe the code would be run at valgrind exit/cleanup time too
[18:00] <cnd> which would be why it appears that valgrind finishes running the test
[18:01] <bregma> so what's in the PPA that selective segfaults any program run in several nested bash shells (like the automake CHECK targets here) that does not occur without the nested shells and does not occur in an sbuild elsewhere?
[18:01] <bregma> it has to be something ni the buildd's custom sbuild environment
[18:02] <cnd> bugs could be dormant on some systems and not others
[18:02] <cnd> I don't know we can be sure that the environment is different in a systematic way
[18:03] <bregma> well, it's the same up-to-date precise distro, it's both x86 and amd64 architectures, and it consistently fails in various PPAs and consistently passes in clean sbuild and pbuilder images
[18:04] <bregma> it wouldn't be so bad except for the build delays in PPAs
[18:05] <cnd> yeah
[18:06] <cnd> bregma, maybe add geis_delete() and see if it fixes things?
[18:07] <cnd> bregma, I assume your valgrind run would output any stack or heap corruption?
[18:08] <bregma> valgrind has always been useful to find errors like that, it's kinda the point
[18:09] <bregma> I will crank up the volume of valgrin messages and see what obtains
[18:11] <cnd> yeah, I just wanted to make sure you weren't somehow disabling that
[18:45] <dandrader> cnd, in Geis, what's the difference between the centroid and the position of a gesture?
[18:45] <cnd> dandrader, there isn't, it's a bit of a snafu
[18:45] <cnd> IIRC
[18:46] <cnd> there was a big issue of how to handle two ways of defining gesture motion
[18:46] <cnd> centroid + full affine transformation
[18:46] <cnd> or center of rotation + rotation + multiplication
[18:47] <cnd> in the mix of the discussion, we added a centroid parameter, but it should be the same as the position parameter
[18:47] <cnd> we needed to add a center of rotation parameter instead
[18:47] <cnd> which we never did...
[18:48] <cnd> no one has asked for it, so...
[18:48] <dandrader> :)
[18:48] <dandrader> ok, thanks for explanation
[18:50]  * bregma slaps forehead with dead fish and mumbles something unintelligible about libtool
[18:52] <cnd> bregma, did you figure it out?
[19:06] <cnd> bregma, wow, geisv1 has a badly broken api :(
[19:06] <cnd> the xcb window info takes a uint32_t window id
[19:06] <cnd> but X Window is typedef'd to a long
[19:07] <cnd> so on 64-bit, the geis v1 window id only holds the lower 32-bits
[19:07] <cnd> it probably won't matter too much, but it's quite an oversight
[19:08] <burli> hi
[19:08] <cnd> burli, hi
[19:09] <burli> hi cnd. The guy I want to see ;)
[19:09] <cnd> :)
[19:09] <burli> Currently I'm trying Kubuntu-Active.
[19:09] <burli> Same problems like with Unity-3D
[19:09] <burli> add a comment to the bug report https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791
[19:10] <cnd> burli, I've seen a few reports about it
[19:10] <cnd> I can't seem to reproduce it here
[19:10] <cnd> but I may have a commit that would fix it
[19:11] <cnd> burli, are you capable of compiling a branch of utouch-grail to see if it's fixed?
[19:12] <burli> cnd, I can try
[19:12] <cnd> burli, to make sure you have all the dependencies you need, run "apt-get build-dep utouch-grail"
[19:13] <burli> just a second
[19:14] <cnd> then, check out the branch: bzr branch lp:~chasedouglas/utouch-grail/tap-accept-v2
[19:14] <cnd> cd into it
[19:14] <cnd> run: ./autogen.sh && ./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --with-xi
[19:14] <cnd> make
[19:14] <cnd> sudo make install
[19:15] <cnd> log out and back into unity 3d and see if it fixes things
[19:15] <burli> hang on. let me first install all updates
[19:17] <cnd> ok
[19:17] <cnd> I've got all day, so don't worry about time :)
[19:20] <burli> need to install bzr first ;)
[19:23] <cnd> heh
[19:24] <burli> cnd, x86_64?
[19:24] <cnd> burli, are you on i386?
[19:24] <burli> shure
[19:24] <cnd> ok
[19:24] <cnd> use --libdir=/usr/lib/i386-linux-gnu
[19:25] <burli> ok
[19:26] <burli> cnd, 64 Bit on an Atom CPU with 1GB RAM is not a good idea ;)
[19:27] <cnd> suit yourself :)
[19:27] <burli> ok, compiling
[19:27] <burli> ok, no errors
[19:28] <cnd> good :)
[19:28] <burli> well, lets see
[19:29] <burli> no, sorry. nothing changed
[19:29] <burli> let me reboot
[19:31] <burli> hm, strange. let me test something
[19:38] <burli> cnd, ok. Same problem. I can do something for a few seconds.
[19:39] <cnd> burli, ok
[19:39] <cnd> burli, I need you to try to figure out the simplest way to always trigger the bug
[19:39] <burli> for example move the hover icon from onboard or drag a select box on the desktop
[19:39] <cnd> that may be tapping over one window
[19:40] <cnd> burli, dragging a select box once will trigger the bug?
[19:40] <burli> let me try again something
[19:41] <cnd> k
[19:42] <burli> it's confusing
[19:49] <burli> ok. first, I can't use the panel all the time, doesn't matter what I do. Not even F10 works.
[19:49] <burli> wait, got a bug
[19:50] <burli> Its the second time that nautilus crashed
[19:51] <burli> nautilus crashed with SIGABRT in raise()
[19:51] <dandrader> cnd, got the 3-finger drag working again! (with hit test method)
[19:51] <cnd> dandrader, sweet!
[19:52] <cnd> I'll be able to test it on my touchscreen here too
[19:52] <cnd> dandrader, did you get rid of the XQueryTree call too?
[19:52] <burli> ok, next: I can open the launcher with the Super key directly after login and drag the launcher icons for a few seconds.
[19:53] <dandrader> cnd, yes
[19:54] <cnd> dandrader, \o/
[19:55] <dandrader> :)
[19:55] <cnd> burli, do you mean you drag one launcher icon to reorder it in the dock?
[19:55] <cnd> and then your touch is broken?
[19:56] <burli> cnd, not reorder. just scroll all icons up and down
[19:56] <cnd> ok
[19:56] <burli> I copied a file to my desktop folder and relogin
[19:56] <burli> I can drag this file twice, than touch is broken
[19:57] <burli> let me try something different
[19:57] <cnd> burli, I worry that this may be exacerbated by the slowness of your system
[19:57] <cnd> but I'll try those
[19:58] <cnd> my unity 3d touch screen system is a quad core i7
[20:00] <burli> cnd, I try to drag the file for a longer time. than I dropped it and drag it again for a while. Works fine so far. If I try to drag it again it doesn't work
[20:01] <burli> ok, now I can drag it only once
[20:02] <cnd> burli, btw, I'm tracking this issue in bug 949791: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791
[20:02] <burli> this is my report ^^
[20:03] <cnd> ahh, ok
[20:03] <cnd> right
[20:03] <cnd> I was thinking of another bug
[20:04] <burli> are you shure this is a performance issue? Unity-3D runs fine on my netbook
[20:04] <cnd> I think I started commenting on the other bug instead of your bug by mistake
[20:04] <cnd> burli, it's not that unity 3d shouldn't be able to run on your machine
[20:05] <cnd> just that the bug may only manifest on a slower machine
[20:05] <cnd> which would explain why I haven't seen the bug yet
[20:05] <burli> ah, ok
[20:05] <burli> If you are in germany I can send you my tablet for testing ;)
[20:06] <burli> cnd, where do you live?
[20:08] <cnd> burli, portland, OR
[20:08] <cnd> US
[20:08] <burli> ouch. thats to complicated
[20:09] <cnd> burli, I'm sure we'll be able to fix it
[20:09] <cnd> I am working on all the bugs I can find involving utouch
[20:10] <burli> I'm wondering that nautilus crashed twice
[20:10] <burli> did not crash on unty 2d
[20:10] <burli> unity
[20:11] <cnd> ooo... it's already 1:12
[20:11] <cnd> I need to get some lunch
[20:11] <cnd> biab
[20:12] <burli> hehe
[21:06] <cnd> bregma, when you ran the tests under valgrind, did you run valgrind ./test?
[21:07] <cnd> if so, that won't work since ./<progname> is a script to run the progname under .libs
[21:07] <cnd> maybe that's what you meant when you cursed at libtool earlier?
[21:09] <bregma> yeppurs
[21:10] <bregma> valgrind needs --follow-children or something like that
[21:10] <bregma> or else libtool execute valgrind, but that would miss the shell
[21:10] <bregma> looks like the problem is that the kernel used in the PPA does not support epoll
[21:11] <cnd> interesting...
[21:11] <bregma> in an unpleasant sort of way
[21:11] <cnd> bregma, does that break all geis tests?
[21:11] <cnd> or is there a workaround for when epoll isn't available?
[21:12] <bregma> it will break geis
[21:12] <bregma> I have another build pending that will reveal more details of why epoll_create() is failing
[21:12] <cnd> ok
[21:12] <cnd> I guess we might have to disable tests when building in the archive
[21:13] <cnd> do  you think it's ppa only?
[21:14] <bregma> I believe PPAs use the exact same buildd used by the distro
[21:14] <cnd> generally they don't
[21:14] <cnd> it's a separate system
[21:14] <bregma> are you sure/
[21:15] <cnd> I don't know all the details, but I think the setups are very different in implementation
[21:15] <cnd> whether that makes a difference in the build environment, I don't know
[21:15] <cnd> when I asked for arm builders for some dx-touch ppas
[21:15] <cnd> they seemed to need to flip a switch to make them build on a different set of buildds
[21:16] <cnd> I remember something about virtual builders vs regular builders
[21:16] <bregma> do you know weher to ask for more information on all this stuff?
[21:16] <bregma> *shere*
[21:16] <cnd> I think #soyuz
[21:16] <bregma> hot spit, I mean _where_
[21:16] <cnd> nope
[21:17] <cnd> soyuz is the project
[21:17] <cnd> I think #launchpad is the irc channel
[21:49] <dandrader> cnd, you can try this one lp:~dandrader/unity/geisv2/
[21:49] <dandrader> it has the 3-touches drag fix
[21:49] <cnd> dandrader, I will in a bit
[21:49] <cnd> I'm knee deep fixing other issues
[21:49] <dandrader> 4-touches drag and 4-touches tap behave way better as well
[21:50] <cnd> I'm currently fixing timeout calculation now that atomic gestures must wait for the composition time :)
[21:50] <cnd> sweet
[21:50] <cnd> hopefully with some stuff I'm working on they will be perfect
[21:50] <dandrader> I bet it must be because of the kinds of subscriptions done
[21:50] <cnd> I have around 3 fixes I'm currently working on
[21:51] <dandrader> cool
[21:52] <dandrader> hopefully it fixes the craziness I get when I just apply the 3-touches fix on top of unity trunk (without all the geisv1 -> geisv2 refactoring)
[21:53] <cnd> one of the particular bugs I'm working on is geisv1 only
[21:53] <cnd> so it might
[21:53] <cnd> the number of touches in a tap gesture are reported incorrectly in geisv1 right now
[21:54] <bregma> I was thinking we might want to spin a grail release early next week
[21:55] <cnd> bregma, yeah, after a couple fixes I have in the queue
[21:55] <cnd> the next freeze is next thursday anyways
[21:55] <cnd> so we need to get stuff out by then
[21:56] <bregma> if you all could all the fixes you want in to the next milestone, we'll know when we're ready because they're all committed
[21:58] <cnd> yeah, I should do that
[21:58] <cnd> the problem is that I'm trying to solve one bug, and I'm already up to 3 necessary fixes
[21:58] <cnd> and I think I need to fix a fourth
[21:59] <cnd> 2 in geis, 2 in grail
[22:15] <cnd> bregma, have you filed the FFe for the geis accept/reject?
[22:31] <bregma> not until I have it building in a PPA
[22:32] <bregma> PPAs run kernel 2.6.24, I need 2.6.27 but I think I can maybe fall back to an older epoll_create() if the first try fails
[22:33] <bregma> either way the code path for handling epoll_create() failure needs fixing
[22:33] <cnd> bregma, we need to file the FFe today
[22:33] <cnd> I think they've started approving FFes at the release team meeting on friday mornings
[22:33] <cnd> is that going to be possible?
[22:34] <bregma> OK, I don't need the build working to file the FFe, especially now I know why it was failing
[22:35] <cnd> k
[23:01] <cnd> bregma, a tap event in geis v1 should come across as one update event
[23:01] <cnd> no begin or end events
[23:01] <cnd> right?
[23:17] <bregma> "should" is a strong word:  yes, that's the way it did come across