[00:05] k [00:06] I've got a pipeline of multiple geis and grail fixes [00:06] hopefully I can send some of them out today === MacSlow is now known as MacSlow|lunch === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader === MacSlow|lunch is now known as MacSlow [15:14] tvoss, bregma, Satoris, dandrader: standups! [15:14] Deployed the new web service on staging, working on trackpad-recognizer [15:14] I started unraveling multiple bugs in grail and geis yesterday, I'll be continuing today [15:15] they revolve around making taps work properly [15:15] cnd, with missing begins? [15:15] tvoss, unless you opt for tentative events using geis, taps will only appear as one "update" event [15:15] tvoss, or are you asking about grail events? [15:16] cnd, about grail event [15:16] +s [15:16] tvoss, I'm unaware of missing begins for tap events [15:16] cnd, checking ... gimme a second [15:16] I'm fixing up utouch-geis with a cunning gtest autoconf solution [15:16] I'm checking what's missing on unity gestures. Currently fine tuning subscriptions on my geisv2 version of unity gestures code. [15:17] bregma, will it be using the xorg-gtest autotools foo? [15:17] I'd rather we had the same autotools foo in every project, and it might as well be derived from xorg-gtest [15:17] cnd, https://bugs.launchpad.net/utouch-grail/+bug/949855 [15:17] I'm also waiting for cnd to publish his fixes to check how my fix for the 3-touches drag on top of unity trunk (without the geisv2 refactoring) work [15:17] tvoss, yes, I'm fixing that bug [15:17] Redesigning and -factoring aptng plus finalising touches on Chromium. [15:17] because now, on top of geis b1, things are rather wild [15:18] the xorg-gtest stuff is way too complicated and unusual === dandrader is now known as dandrader|lunch [15:18] bregma, then propose changes in xorg-gtest [15:18] I Cc'd you on the patches for a reason :) [15:18] none of them have been committed yet [15:18] I will propose changes in libgtest-dev first, then they should propagate through consumers of that package [15:19] bregma, you're going to add stuff to libgtest-dev? [15:19] we won't be able to use it in xorg-gtest upstream [15:19] I can propose an upstream patch, it won;t hurt [15:19] because the changes in libgtest-dev won't be upstream [15:19] yeah, that would be good [15:19] but until then, we can't rely on the functionality [15:19] if it'rejected upstream, I go to the next step [15:20] it's just an m4 file and two variables in your .am file [15:20] it works in geis, I'll see if I can rejig it for xorg-gtest [15:21] k [15:43] bregma, multiple people in PS are asking about how to fix their gtest autofoo [15:43] rather than give potentially bad info [15:43] what is wrong with what I've proposed for xorg-gtest? [15:49] cnd, principle of least surprise: no other package requires including automake snippets, neither does my solution [15:50] you just add one macro to configure.ac, add a file to the _SOURCES target, and add the usual _CFLAGS [15:51] and guanateed the gtest is compiled with EXACTLY the same flags used for all the other files in the test [15:51] bregma, what's the difference between requiring people to edit their Makefile.am and asking them to copy a different automake file and include it? [15:51] principle of least surprise: no other package requires including automake snippets [15:51] yeah, but that's because autotools doesn't really support building sources from elsewhere [15:52] any other package I just add a line to configure.ac and add _CFLAGS and _LIBS to the appropriate places [15:52] autotools supports building from source just fine [15:53] after all, that's it's mainpurpose in life [15:53] yeah, but it doesn't have good support for building from a system provided location [15:54] bregma, either way, RAOF is looking at creating a real Makefile snippet [15:54] so you merely include the Makefile, which is installed in the system [15:54] you don;t need a makefile snippet [15:55] you do not need a big fancy solution when a simple solution that works like any other package will do [15:55] we do not need to reinvent the autotool here [15:56] it doesn't work like any other package because with other packages you would just link against the system installed precompiled library [15:56] it works like any other package: include the macro in configure.ac, add the variables to your targets in your .am files where needed [15:57] that what all the other packages do, that's what my solution does [15:58] I think the devil is in the details, I'll wait to see what you have [15:58] gah, gtest has no way to automatically determine its version, better hope its API never changes [15:59] heh [15:59] gtest really needs a pkgconfig and an aclocal macro [15:59] actually, pkgconfig is probably enough [16:03] that would be best [16:04] maybe that's what I'll propose for upstream [16:05] yeah === dandrader|lunch is now known as dandrader [16:40] what do I use a GeisRegion for? [16:42] I create one with geis_region_new() and that's it? Or can I pass it to geis_filter_add_term()? [16:48] yay, geis gesture accept/reject ffe is approved :) [16:56] dandrader, you probably do not ever need to create a geis_region, it's more for non-X11-window-based recognizers [16:56] of which we have none at the moment [16:57] cnd, how stable is utouch-frame (as in, do you think we will need another release before RC)? [16:58] bregma, I can't remember any changes to it, nor any bugs in it [17:00] stable is nice [17:01] especially for packaging for Debian [17:01] bregma, so currently utouch-geis code doesn't use GeisRegion for anything at all, right? (at least that's what grep tells me) [17:21] dandrader, yes, reserved for future use [17:47] cnd, now that the FFe has been approved, do you think I should just upload utouch-geis 2.2.6 as-is and risk build failure or should I reroll the source tarball to include the PPA fix just in case? [17:47] it's stupid if all of precise is built on a jaunty chroot [17:48] bregma, I actually have a few changes that I will be proposing today [17:48] changes should go in 2.2.7 [17:48] did you already release 2.2.6 upstream? [17:48] a couple days ago, all the targeted bugs were fixed [17:49] ok [17:49] I can not upload 2.2.6 at all and wait for 2.2.7 [17:49] hmm [17:49] I think it's fine either way [17:49] if you upload it [17:49] try it first [17:50] and then distro patch the epoll fix if it breaks [17:50] that's what I would suggest [17:50] hmm, yeah, that would work, too [17:50] OK, sounds like a plan [17:50] we can release 2.2.7 and the new grail next week [17:50] yeah [17:51] I'm so close to having this tapping bug fixed [17:51] geis generates one update event [17:51] with the correct number of touches [17:51] but the event never gets seen in the testcase... [17:54] bregma, I think our highest priority task right now is to figure out the xorg-gtest madness [17:54] if you can get a patch for it it would be great [17:55] basically, lop off the second to last patch in my source branch in my git repo [18:00] I put my fingers on a touchscreen and leave them still for some 3 seconds, after that I drag them over the screen. Should a drag gesture happen? [18:01] cnd, I'll do that next [18:01] dandrader, not with the default drag threshold and timeout [18:03] I'm not sure if it's a question of parameter values [18:08] heh, nope, precise is built on builders using a 6-year-old kernel [18:09] I'm surprized there are not more failures then === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [18:55] bregma, I just filed a pipeline of changes for geis [18:55] they require some grail fixes [18:55] I don't have a pipeline and tests for grail fixes yet, but I do have a work in progress branch that has the fixes: lp:~chasedouglas/utouch-grail/work-in-progress [18:56] I don't think geis will break if run against the current grail, it just won't be fully fixed [18:57] so the changes can be merged before the grail fixes are [18:58] I need to file a bug for the geis issue... [19:08] I'mm off to chauffeur people around for an hour or so, back in a bit [22:18] cnd, which is the upstream xorg-gtest these days? [22:19] you can use lp:xorg-gtest if you want, it's synced automatically, but the real upstream is http://cgit.freedesktop.org/xorg/test/xorg-gtest/ [22:19] however, I have 8 commits in my source branch at http://cgit.freedesktop.org/~cndougla/xorg-gtest/ that you will want to base your work on [22:19] everything except the second to last commit [22:20] I should probably apply the other commits at the point [22:20] the only real question is how to handle the one commit that adds the infrastructure for other projects [22:20] OK, that's what I'm really looking for [22:20] if you give me a minute, I'll push the other commits [22:22] no hurry [22:25] bregma, I've updated upstream master branch [22:25] thanks [22:25] and I just updated my source branch [22:25] it only has that one commit now [22:26] bregma, you can use that as a basis if you want [22:26] I'll be playing with stuff for the next little while but it's well past EOB on a Friday night here, so don;t get your hopes up for a patchset tonight [22:26] I'm still wading through the geis merge requests [22:29] bregma, sure, np [23:47] * cnd turns on the purdue st mary's basketball game on his ipad next to his monitor