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