#ubuntu-touch 2012-03-14 <fo0bar> test for ubuntulog2 #ubuntu-touch 2012-03-15 <cnd> bregma, I've got a pristine checkout of lp:utouch-geis here <cnd> make check is failing for GeisSubscriptionTests.duplicate_window_subscription <cnd> gtest_subscriptions.cpp:91: Failure <cnd> Expected: (GEIS_STATUS_SUCCESS) != (geis_subscription_activate(sub2)), actual: 0 vs 0 <cnd> mistakenly activated subscription 2 <cnd> we'll need to get that fixed before releasing anything <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) <cnd> hmm <cnd> I don't know <cnd> I'll have to investigate <cnd> in the meantime, I'm finding a geis bug where the number of touches in a geis gesture is not being set properly <cnd> I'm tracking it down <cnd> well, I think it's a geis bug :) <cnd> oh right, it's a grail bug that I wrote a fix for but hadn't gotten around to writing a testcase for <bregma> is there a bug for it? <cnd> not yet, though I think it's a separate issue again * bregma stands up, looking around..... <tvoss> Working on #950974, deployed BuildService server to staging jenkins, updated documentation on builder setup * tvoss stands up as well <cnd> I'm working on a utouch bugs that are resulting in issues in unity <tvoss> cnd, dandrader, ping <dandrader> tvoss, pong <cnd> I may have a fix for bug 940308 <dandrader> I'm working on making that 3-touches gesture to move windows around work again (in unity code) <tvoss> dandrader, just ping'd for standup :) <cnd> tvoss, does the merge proposal script work now? <tvoss> yeah, I'm preparing a follow-up mail on the call for testing and send out instructions <cnd> cool <tvoss> you do not need to interact with script any more <dandrader> tvoss, a web ui now? <tvoss> dandrader, yeah, a very simple one, but a web ui ;) <dandrader> cool <tvoss> or curl, if you like that better <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) <dandrader> i've now problems with a web ui <dandrader> s/now/no <tvoss> bregma, is it always failing or only on some builds? <bregma> always fails, only in PPA <tvoss> bregma, I remember a thread on some mailing-list about "corrupt" ppa builders <tvoss> bregma, for that I asked <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 <bregma> I beleive I can force a stacktrace but the build backlog is on the order of hours, so turnaround is slow <bregma> it feels like software development in the 1980s again * tvoss sighs <cnd> bregma, got an issue with geis that we can resolve in a couple ways <cnd> when a "system" geis v1 tap subscription is created <cnd> the min touches is set to 1 instead of matching the start touches <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 <cnd> so if you do a two-touch tap you might get from grail: <cnd> gesture begin: 1 touch, no gesture <cnd> gesture update: 2 touches, no gesture <cnd> gesture update: 1 touch, no gesture <cnd> gesture end: 1 touch, tap recognized <cnd> because geis v1 does not allow for tentative events, we transform that into one geis v1 event: <cnd> geis gesture update: 1 touch, tap recognized <cnd> when it should have been: <cnd> geis gesture update: 2 touch, tap recognized <cnd> I'm thinking the best way to resolve this is to only set minimum touches to 1 for non-tap system gestures <cnd> what do you think? <bregma> did it not give the 2-tap gesture event? <cnd> grail is giving a "gesture", which in the end slice is a 1-touch tap <cnd> but in the middle of the gesture there was a slice with 2-touches <cnd> but only the end slice is transformed into the geis v1 gesture event <cnd> which is why it says only 1 touch <bregma> I mean the original grail, you;re saying it never gave the 2-tap gesture? <cnd> the original grail probably did not honor the system flag for tap events <bregma> mmm <cnd> an alternative would be to keep the max touch count of a gesture in the geis gesture state <cnd> and when emitting a tap gesture, emit it with the max number of touches <cnd> but then we have to keep around more state, such as each touch position <cnd> I think that would be a hairy solution <bregma> that would effectively be moving gesture recognition out of the recognizer and into geis <cnd> yeah <bregma> a tap event is already a special case, what with not haveing a begin and an end <bregma> I see nothing wrong with treating it special in other ways <cnd> bregma, is not setting the min touches to 1 for a system tap gesture alright with you? <cnd> I can whip up a patch for it fairly quickly I think <bregma> yes, I'm fine wit hthat <cnd> ok <bregma> ... it looks like the build failures I see in the PPA are _bash_ segfaulting, not the test program <bregma> curiouser and curiouser <cnd> bregma, it looks like bash segfaults when the program executed at make check segfaults <cnd> that's been my experience <cnd> bregma, do you have the build log url? <cnd> I can see if it matches what I've seen before <bregma> https://launchpadlibrarian.net/96910377/buildlog_ubuntu-precise-i386.utouch-geis_2.2.6%2Br217%2Bp159~ppa2_FAILEDTOBUILD.txt.gz <bregma> in this run, I run the test program in valgrind to catch and display a traceback of the segfault <cnd> ahh <cnd> yeah, this is the test segfaulting <cnd> not bash <bregma> bash still appears to segfault <bregma> you mean, the test segfaults and valgrin is not catching it? <cnd> bregma, are you referring to this line: /bin/bash: line 5: 30068 Segmentation fault valgrind ${dir}$tst <cnd> ? <bregma> yep <cnd> yeah, I've seen that exact message before <cnd> it's not bash segfaulting, it's valgrind <cnd> I thought the same thing when I first saw it <cnd> and RAOF told me what's really going on :) <cnd> I have no idea why those tests would segfault though... <bregma> I have always assumed it's the app segfaulting, but it makes no sense valgrind would be degfaulting here <cnd> bregma, maybe remove valgrind and add a signal handler to the testcases to get a backtrace? <cnd> it's a pretty heavy-handed approach, but it might work <bregma> I added valgrind to get the backtrace -- valgrind will give a backtrace if the app it's running segfaults <bregma> without valgrind you get the same message, except without the valgrind <cnd> hmm <bregma> as you can see, valgrind is not catching any errors with the app <cnd> what if it's segfaulting at program exit/cleanup time? <bregma> the package builds cleanly using sbuild and pbuilder on my machine <cnd> maybe the code would be run at valgrind exit/cleanup time too <cnd> which would be why it appears that valgrind finishes running the test <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? <bregma> it has to be something ni the buildd's custom sbuild environment <cnd> bugs could be dormant on some systems and not others <cnd> I don't know we can be sure that the environment is different in a systematic way <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 <bregma> it wouldn't be so bad except for the build delays in PPAs <cnd> yeah <cnd> bregma, maybe add geis_delete() and see if it fixes things? <cnd> bregma, I assume your valgrind run would output any stack or heap corruption? <bregma> valgrind has always been useful to find errors like that, it's kinda the point <bregma> I will crank up the volume of valgrin messages and see what obtains <cnd> yeah, I just wanted to make sure you weren't somehow disabling that <dandrader> cnd, in Geis, what's the difference between the centroid and the position of a gesture? <cnd> dandrader, there isn't, it's a bit of a snafu <cnd> IIRC <cnd> there was a big issue of how to handle two ways of defining gesture motion <cnd> centroid + full affine transformation <cnd> or center of rotation + rotation + multiplication <cnd> in the mix of the discussion, we added a centroid parameter, but it should be the same as the position parameter <cnd> we needed to add a center of rotation parameter instead <cnd> which we never did... <cnd> no one has asked for it, so... <dandrader> :) <dandrader> ok, thanks for explanation * bregma slaps forehead with dead fish and mumbles something unintelligible about libtool <cnd> bregma, did you figure it out? <cnd> bregma, wow, geisv1 has a badly broken api :( <cnd> the xcb window info takes a uint32_t window id <cnd> but X Window is typedef'd to a long <cnd> so on 64-bit, the geis v1 window id only holds the lower 32-bits <cnd> it probably won't matter too much, but it's quite an oversight <burli> hi <cnd> burli, hi <burli> hi cnd. The guy I want to see ;) <cnd> :) <burli> Currently I'm trying Kubuntu-Active. <burli> Same problems like with Unity-3D <burli> add a comment to the bug report https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791 <cnd> burli, I've seen a few reports about it <cnd> I can't seem to reproduce it here <cnd> but I may have a commit that would fix it <cnd> burli, are you capable of compiling a branch of utouch-grail to see if it's fixed? <burli> cnd, I can try <cnd> burli, to make sure you have all the dependencies you need, run "apt-get build-dep utouch-grail" <burli> just a second <cnd> then, check out the branch: bzr branch lp:~chasedouglas/utouch-grail/tap-accept-v2 <cnd> cd into it <cnd> run: ./autogen.sh && ./configure --prefix=/usr --libdir=/usr/lib/x86_64-linux-gnu --with-xi <cnd> make <cnd> sudo make install <cnd> log out and back into unity 3d and see if it fixes things <burli> hang on. let me first install all updates <cnd> ok <cnd> I've got all day, so don't worry about time :) <burli> need to install bzr first ;) <cnd> heh <burli> cnd, x86_64? <cnd> burli, are you on i386? <burli> shure <cnd> ok <cnd> use --libdir=/usr/lib/i386-linux-gnu <burli> ok <burli> cnd, 64 Bit on an Atom CPU with 1GB RAM is not a good idea ;) <cnd> suit yourself :) <burli> ok, compiling <burli> ok, no errors <cnd> good :) <burli> well, lets see <burli> no, sorry. nothing changed <burli> let me reboot <burli> hm, strange. let me test something <burli> cnd, ok. Same problem. I can do something for a few seconds. <cnd> burli, ok <cnd> burli, I need you to try to figure out the simplest way to always trigger the bug <burli> for example move the hover icon from onboard or drag a select box on the desktop <cnd> that may be tapping over one window <cnd> burli, dragging a select box once will trigger the bug? <burli> let me try again something <cnd> k <burli> it's confusing <burli> ok. first, I can't use the panel all the time, doesn't matter what I do. Not even F10 works. <burli> wait, got a bug <burli> Its the second time that nautilus crashed <burli> nautilus crashed with SIGABRT in raise() <dandrader> cnd, got the 3-finger drag working again! (with hit test method) <cnd> dandrader, sweet! <cnd> I'll be able to test it on my touchscreen here too <cnd> dandrader, did you get rid of the XQueryTree call too? <burli> ok, next: I can open the launcher with the Super key directly after login and drag the launcher icons for a few seconds. <dandrader> cnd, yes <cnd> dandrader, \o/ <dandrader> :) <cnd> burli, do you mean you drag one launcher icon to reorder it in the dock? <cnd> and then your touch is broken? <burli> cnd, not reorder. just scroll all icons up and down <cnd> ok <burli> I copied a file to my desktop folder and relogin <burli> I can drag this file twice, than touch is broken <burli> let me try something different <cnd> burli, I worry that this may be exacerbated by the slowness of your system <cnd> but I'll try those <cnd> my unity 3d touch screen system is a quad core i7 <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 <burli> ok, now I can drag it only once <cnd> burli, btw, I'm tracking this issue in bug 949791: https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/949791 <burli> this is my report ^^ <cnd> ahh, ok <cnd> right <cnd> I was thinking of another bug <burli> are you shure this is a performance issue? Unity-3D runs fine on my netbook <cnd> I think I started commenting on the other bug instead of your bug by mistake <cnd> burli, it's not that unity 3d shouldn't be able to run on your machine <cnd> just that the bug may only manifest on a slower machine <cnd> which would explain why I haven't seen the bug yet <burli> ah, ok <burli> If you are in germany I can send you my tablet for testing ;) <burli> cnd, where do you live? <cnd> burli, portland, OR <cnd> US <burli> ouch. thats to complicated <cnd> burli, I'm sure we'll be able to fix it <cnd> I am working on all the bugs I can find involving utouch <burli> I'm wondering that nautilus crashed twice <burli> did not crash on unty 2d <burli> unity <cnd> ooo... it's already 1:12 <cnd> I need to get some lunch <cnd> biab <burli> hehe <cnd> bregma, when you ran the tests under valgrind, did you run valgrind ./test? <cnd> if so, that won't work since ./<progname> is a script to run the progname under .libs <cnd> maybe that's what you meant when you cursed at libtool earlier? <bregma> yeppurs <bregma> valgrind needs --follow-children or something like that <bregma> or else libtool execute valgrind, but that would miss the shell <bregma> looks like the problem is that the kernel used in the PPA does not support epoll <cnd> interesting... <bregma> in an unpleasant sort of way <cnd> bregma, does that break all geis tests? <cnd> or is there a workaround for when epoll isn't available? <bregma> it will break geis <bregma> I have another build pending that will reveal more details of why epoll_create() is failing <cnd> ok <cnd> I guess we might have to disable tests when building in the archive <cnd> do you think it's ppa only? <bregma> I believe PPAs use the exact same buildd used by the distro <cnd> generally they don't <cnd> it's a separate system <bregma> are you sure/ <cnd> I don't know all the details, but I think the setups are very different in implementation <cnd> whether that makes a difference in the build environment, I don't know <cnd> when I asked for arm builders for some dx-touch ppas <cnd> they seemed to need to flip a switch to make them build on a different set of buildds <cnd> I remember something about virtual builders vs regular builders <bregma> do you know weher to ask for more information on all this stuff? <bregma> *shere* <cnd> I think #soyuz <bregma> hot spit, I mean _where_ <cnd> nope <cnd> soyuz is the project <cnd> I think #launchpad is the irc channel <dandrader> cnd, you can try this one lp:~dandrader/unity/geisv2/ <dandrader> it has the 3-touches drag fix <cnd> dandrader, I will in a bit <cnd> I'm knee deep fixing other issues <dandrader> 4-touches drag and 4-touches tap behave way better as well <cnd> I'm currently fixing timeout calculation now that atomic gestures must wait for the composition time :) <cnd> sweet <cnd> hopefully with some stuff I'm working on they will be perfect <dandrader> I bet it must be because of the kinds of subscriptions done <cnd> I have around 3 fixes I'm currently working on <dandrader> cool <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) <cnd> one of the particular bugs I'm working on is geisv1 only <cnd> so it might <cnd> the number of touches in a tap gesture are reported incorrectly in geisv1 right now <bregma> I was thinking we might want to spin a grail release early next week <cnd> bregma, yeah, after a couple fixes I have in the queue <cnd> the next freeze is next thursday anyways <cnd> so we need to get stuff out by then <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 <cnd> yeah, I should do that <cnd> the problem is that I'm trying to solve one bug, and I'm already up to 3 necessary fixes <cnd> and I think I need to fix a fourth <cnd> 2 in geis, 2 in grail <cnd> bregma, have you filed the FFe for the geis accept/reject? <bregma> not until I have it building in a PPA <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 <bregma> either way the code path for handling epoll_create() failure needs fixing <cnd> bregma, we need to file the FFe today <cnd> I think they've started approving FFes at the release team meeting on friday mornings <cnd> is that going to be possible? <bregma> OK, I don't need the build working to file the FFe, especially now I know why it was failing <cnd> k <cnd> bregma, a tap event in geis v1 should come across as one update event <cnd> no begin or end events <cnd> right? <bregma> "should" is a strong word: yes, that's the way it did come across #ubuntu-touch 2012-03-16 <cnd> k <cnd> I've got a pipeline of multiple geis and grail fixes <cnd> hopefully I can send some of them out today <cnd> tvoss, bregma, Satoris, dandrader: standups! <tvoss> Deployed the new web service on staging, working on trackpad-recognizer <cnd> I started unraveling multiple bugs in grail and geis yesterday, I'll be continuing today <cnd> they revolve around making taps work properly <tvoss> cnd, with missing begins? <cnd> tvoss, unless you opt for tentative events using geis, taps will only appear as one "update" event <cnd> tvoss, or are you asking about grail events? <tvoss> cnd, about grail event <tvoss> +s <cnd> tvoss, I'm unaware of missing begins for tap events <tvoss> cnd, checking ... gimme a second <bregma> I'm fixing up utouch-geis with a cunning gtest autoconf solution <dandrader> I'm checking what's missing on unity gestures. Currently fine tuning subscriptions on my geisv2 version of unity gestures code. <cnd> bregma, will it be using the xorg-gtest autotools foo? <cnd> I'd rather we had the same autotools foo in every project, and it might as well be derived from xorg-gtest <tvoss> cnd, https://bugs.launchpad.net/utouch-grail/+bug/949855 <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 <cnd> tvoss, yes, I'm fixing that bug <Satoris> Redesigning and -factoring aptng plus finalising touches on Chromium. <dandrader> because now, on top of geis b1, things are rather wild <bregma> the xorg-gtest stuff is way too complicated and unusual <cnd> bregma, then propose changes in xorg-gtest <cnd> I Cc'd you on the patches for a reason :) <cnd> none of them have been committed yet <bregma> I will propose changes in libgtest-dev first, then they should propagate through consumers of that package <cnd> bregma, you're going to add stuff to libgtest-dev? <cnd> we won't be able to use it in xorg-gtest upstream <bregma> I can propose an upstream patch, it won;t hurt <cnd> because the changes in libgtest-dev won't be upstream <cnd> yeah, that would be good <cnd> but until then, we can't rely on the functionality <bregma> if it'rejected upstream, I go to the next step <bregma> it's just an m4 file and two variables in your .am file <bregma> it works in geis, I'll see if I can rejig it for xorg-gtest <cnd> k <cnd> bregma, multiple people in PS are asking about how to fix their gtest autofoo <cnd> rather than give potentially bad info <cnd> what is wrong with what I've proposed for xorg-gtest? <bregma> cnd, principle of least surprise: no other package requires including automake snippets, neither does my solution <bregma> you just add one macro to configure.ac, add a file to the _SOURCES target, and add the usual _CFLAGS <bregma> and guanateed the gtest is compiled with EXACTLY the same flags used for all the other files in the test <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? <bregma> principle of least surprise: no other package requires including automake snippets <cnd> yeah, but that's because autotools doesn't really support building sources from elsewhere <bregma> any other package I just add a line to configure.ac and add _CFLAGS and _LIBS to the appropriate places <bregma> autotools supports building from source just fine <bregma> after all, that's it's mainpurpose in life <cnd> yeah, but it doesn't have good support for building from a system provided location <cnd> bregma, either way, RAOF is looking at creating a real Makefile snippet <cnd> so you merely include the Makefile, which is installed in the system <bregma> you don;t need a makefile snippet <bregma> you do not need a big fancy solution when a simple solution that works like any other package will do <bregma> we do not need to reinvent the autotool here <cnd> it doesn't work like any other package because with other packages you would just link against the system installed precompiled library <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 <bregma> that what all the other packages do, that's what my solution does <cnd> I think the devil is in the details, I'll wait to see what you have <bregma> gah, gtest has no way to automatically determine its version, better hope its API never changes <cnd> heh <cnd> gtest really needs a pkgconfig and an aclocal macro <cnd> actually, pkgconfig is probably enough <bregma> that would be best <bregma> maybe that's what I'll propose for upstream <cnd> yeah <dandrader> what do I use a GeisRegion for? <dandrader> I create one with geis_region_new() and that's it? Or can I pass it to geis_filter_add_term()? <cnd> yay, geis gesture accept/reject ffe is approved :) <bregma> dandrader, you probably do not ever need to create a geis_region, it's more for non-X11-window-based recognizers <bregma> of which we have none at the moment <bregma> cnd, how stable is utouch-frame (as in, do you think we will need another release before RC)? <cnd> bregma, I can't remember any changes to it, nor any bugs in it <bregma> stable is nice <bregma> especially for packaging for Debian <dandrader> bregma, so currently utouch-geis code doesn't use GeisRegion for anything at all, right? (at least that's what grep tells me) <bregma> dandrader, yes, reserved for future use <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? <bregma> it's stupid if all of precise is built on a jaunty chroot <cnd> bregma, I actually have a few changes that I will be proposing today <bregma> changes should go in 2.2.7 <cnd> did you already release 2.2.6 upstream? <bregma> a couple days ago, all the targeted bugs were fixed <cnd> ok <bregma> I can not upload 2.2.6 at all and wait for 2.2.7 <cnd> hmm <cnd> I think it's fine either way <cnd> if you upload it <cnd> try it first <cnd> and then distro patch the epoll fix if it breaks <cnd> that's what I would suggest <bregma> hmm, yeah, that would work, too <bregma> OK, sounds like a plan <bregma> we can release 2.2.7 and the new grail next week <cnd> yeah <cnd> I'm so close to having this tapping bug fixed <cnd> geis generates one update event <cnd> with the correct number of touches <cnd> but the event never gets seen in the testcase... <cnd> bregma, I think our highest priority task right now is to figure out the xorg-gtest madness <cnd> if you can get a patch for it it would be great <cnd> basically, lop off the second to last patch in my source branch in my git repo <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? <bregma> cnd, I'll do that next <cnd> dandrader, not with the default drag threshold and timeout <dandrader> I'm not sure if it's a question of parameter values <bregma> heh, nope, precise is built on builders using a 6-year-old kernel <bregma> I'm surprized there are not more failures then <cnd> bregma, I just filed a pipeline of changes for geis <cnd> they require some grail fixes <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 <cnd> I don't think geis will break if run against the current grail, it just won't be fully fixed <cnd> so the changes can be merged before the grail fixes are <cnd> I need to file a bug for the geis issue... <bregma> I'mm off to chauffeur people around for an hour or so, back in a bit <bregma> cnd, which is the upstream xorg-gtest these days? <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/ <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 <cnd> everything except the second to last commit <cnd> I should probably apply the other commits at the point <cnd> the only real question is how to handle the one commit that adds the infrastructure for other projects <bregma> OK, that's what I'm really looking for <cnd> if you give me a minute, I'll push the other commits <bregma> no hurry <cnd> bregma, I've updated upstream master branch <bregma> thanks <cnd> and I just updated my source branch <cnd> it only has that one commit now <cnd> bregma, you can use that as a basis if you want <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 <bregma> I'm still wading through the geis merge requests <cnd> bregma, sure, np * cnd turns on the purdue st mary's basketball game on his ipad next to his monitor #ubuntu-touch 2012-03-19 <cnd> bregma, keep going <cnd> I can hear <cnd> but if I drop, I'm afraid the call will drop <dandrader> call quality is horrible <cnd> bregma, same here :( <cnd> hey! <cnd> tvoss, I fixed valgrind in precise <cnd> would that be picked up automatically? <cnd> there were 4 grail merges <cnd> sure <cnd> thanks all :) <cnd> I don't know :( <cnd> alright, I think that's a wrap <cnd> thanks for joining :) <bregma> cnd, as I mentioned, I think we need to relicense utouch-evemu, utouch-frame, and utouch-grail (or dual license) because they're now linked directly with utouch-geis <bregma> should I get a consult from Canonical legal first? <cnd> bregma, ok, that's what I couldn't understand on the call :) <cnd> send an email to olli <cnd> I doubt it would be an issue <cnd> but I don't know what the process is <bregma> when it comes to lawyers, everything could be an issue <bregma> I will pass the buck to Olli <Satoris> I would imagine that Google would not like to have Chromium become GPL licensed, either. <cnd> tvoss, will the qa instances pick up the next valgrind I uploaded to precise automatically? <tvoss> cnd, yeah valgrind is updated on each job execution <cnd> cool <tvoss> cnd, I installed a precompiled gtest in a snapshot of the build/test vm's <tvoss> as soon as everything is back online, we have test results again <tvoss> cnd, do you know if the evemu-testing framework is able to produce xml output? <bregma> tvoss, evemu uses the standard python unit testing framework <tvoss> bregma, thanks <cnd> bregma, alright, let's tackle this autofoo stuff <cnd> here's my current thinking <cnd> we can provide the sources for xorg-gtest in an xorg-gtest aclocal script as $XORG_GTEST_SOURCES <cnd> it would hold the locations of xorg-gtest-all.cpp and gtest-all.cc <cnd> we also define XORG_GTEST_CPPFLAGS, which would hold the -I flags for include locations <cnd> we can also define $XORG_GTEST_MAIN_SOURCES as xorg-gtest_main.cpp <cnd> and lastly XORG_GTEST_LIBS would be the list of libraries needed to link against (libX11) <cnd> the users of xorg-gtest would then call the aclocal macro, and all the sources, flags, and libs to their tests <cnd> oh right... now I remember why that's bad <cnd> bregma, if you use lots of warning flags, and even worse -Werror, then when you add the gtest sources to your target it will be built with those same flags <bregma> what's wrong with just providing a .pc file with appropriate --cflag and --libs, plus a special variable for the _main.cpp path? <bregma> gtest is a wholly separate concern <cnd> bregma, xorg-gtest should provide for gtest while gtest is broken, imo <bregma> the libgtest problem can also be solved with a simple .pc file with --cflags and --libs and a special variable for the .cpp path <cnd> bregma, we can't ship a .pc file that isn't from upstream <bregma> that .pc file could be bundled with xorg-gtest until it makes it upstream <bregma> as long as it has a different name <cnd> but the xorg-gtest .pc file won't know where the gtest sources are installed <cnd> I don't see any option other than providing an aclocal script <bregma> really, it's completely wrong to solve the libgtest problem through the xorg-gtest package, it should be either upstream or in a separate package <bregma> aclocal script, .pc file, it ends up as the same thing <cnd> aclocal script would be run at package configuration time, while .pc was already run and installed <bregma> yes, a strike against .pc files in the first place <cnd> while it's not ideal that gtest is broken, I don't see why we shouldn't provide a macro to find it too <bregma> the aclocal script I have in my proposed utouch-geis branch can be moved into xorg-gtest <cnd> bregma, I think the sticky point is really the automake inclusion <cnd> I don't see any way around telling people to copy either an automake file or a series of runes into their Makefile.am <bregma> you have a problem with telling people to include the appriate _CFLAGS variable into their .am files? <cnd> adding the sources to the test targets directly isn't a good solution <cnd> it's not the CFLAGS <cnd> it's the sources <bregma> a single source file with a configurable path <bregma> not unlike any other source file <cnd> bregma, you want different CPPFLAGS <cnd> you want to add -w to the end for external sources <cnd> of course, that's the only difference you want in the CPPFLAGS <bregma> we are using a third-party library that does not compile cleanly, and we rely on it? <cnd> it probably does against a specific version of gcc <cnd> but not against the one in precise <cnd> it would be nearly impossible to always compile cleanly against all compilers <cnd> especially when you have things like the big gcc 3 to 4 transition where warnings and errors got a lot more strict <cnd> bregma, the other issue is that the sources may be compiled with more pedantic warnings than what the gtest devs use <cnd> xorg specifies a lot of extra warnings by default <cnd> one example is a warning when you shadow a variable in an outer namespace <bregma> I can think of no way for an automake include snippet to resolve the problem, since using separate compile flags for some source requires building a convenience library and that means passing different flags to the convenience library for each target it gets linked to <bregma> the only reliable way is to have some kind of wackey target in the Makefile.am that gets reprocessed by config.status to massage various flags <cnd> bregma, the closest thing is to use AM_CPPFLAGS and tell the user to use AM_CPPFLAGS too <bregma> yes, force then into rigid lock-step, until everything breaks because they used per-target flags in a per-target way as documented, and they can;t figure out why theu get missing symbols in their link <bregma> that sounds kind of fragile <cnd> it's all a bit fragile <bregma> the least fragile way is to document how to build a gtest library in your project, and have the developers add those three lines where required <cnd> it sounds like the least fragile solution to me <cnd> that may be <cnd> bregma, as for your macro, why should we add a --with-gtest flag? <cnd> when would we have gtest, but not want to use it? <bregma> --with-gtest=PREFIX sets the prefix where to look for gtest (eg. /usr/local) <bregma> --without-gtest will give the default of $(prefix) <cnd> that doesn't make sense to me <bregma> I copied that logic from other macro files in /usr/share/aclocal <cnd> without-gtest should mean "compile without gtest" <bregma> the idea is if you specified --with-gtest=/usr/local/ it will pick up your local copy rather than the system-installed copy <cnd> yeah, but we have two separate variables for that <cnd> with-gtest-sources and with-gtest-includes <cnd> the sources installed by gtest don't include the headers, so with-gtest alone won't work <cnd> you'll always have to provide with-gtest and with-gtest-sources, or with-gtest and with-gtest-includes <bregma> um, perhaps you;re developing under a different OS than I am <cnd> ? <bregma> there is but a single gtest package available through the archives my system points to, and it installs the headers and sources <cnd> yes, but not to the same location <cnd> /usr/src/gtest/src/*.cc and /usr/include/gtest/*.h <cnd> --with-gtest=<prefix> won't work for both <bregma> right, $(prefix) == /usr <bregma> I have no problem with removing the --with-gtest, it's just a convention frequently used by autoconf macros but not all autoconf macros <cnd> I guess I was tripped up by: gtest_srcpath="$gtest_prefix/gtest/src" <cnd> it would need to be $gtest_prefix/src/gtest/src <cnd> but either way, I don't think it's worthwhile to have it <cnd> if I was running ./configure --help, I would be very confused <bregma> OK, consider it gone <cnd> bregma, why don't you use AC_CHECK_FILE for gtest-all.cc? <bregma> 'cos I forget it existed? <cnd> ok <bregma> test -f is a long-ingrained habit, AC_CHECK_FILE would be better <cnd> bregma, I'm thinking that the stuff in my proposed aclocal script is fine <cnd> http://cgit.freedesktop.org/~cndougla/xorg-gtest/tree/aclocal/xorg-gtest.m4?h=source <cnd> is there something that needs to change there? <cnd> inside _CHECK_GTEST in particular <bregma> other than that it should probably be a separate callable macro that can be pushed upstream, and should probably have optional ACTION-IF-FOUND and ACTION-IF-NOT-FOUND args, I have no criticisms <cnd> bregma, the _CHECK_GTEST is separate, and can be pushed upstream <cnd> I'll add ACTION-IF-FOUND to the macro <bregma> is _CHECK_GTEST not in the same .m4 file as CHECK_XORG_GTEST? <cnd> it is, are you saying it should be split into a separate file? <cnd> I worry that splitting it into a separate file would make it seem like a public macro <cnd> it's really just an implementation detail for xorg-gtest <cnd> bregma, here's what I've got: http://paste.ubuntu.com/891007/ <cnd> is that alright with you? <bregma> did you test that last AS_IF with and withou an ACTON_IF_NOT_FOUND argument? <cnd> not yet <cnd> I will <cnd> but I wanted to get your thoughts first <bregma> ah, well, it's OK with me from a functional point of view <cnd> ok <cnd> I don't understand launchpad bug queries <cnd> they don't seem to do what you tell them to do <cnd> I'm finding lots of bugs that aren't found by the two queries I sent out last week <bregma> yes, there does seem to be some sort of dark magic involved <dandrader> cnd, in utouch-grail, I activate an atomic 3-touches Touch subscription and an atomic 3-touches Drag subscription. A 3-fingers drag is performed. What should happen? <cnd> dandrader, I think you should get both <cnd> because this is atomic handling, i.e. grail v1 handling, you would receive both gestures for the same touches <cnd> we really should have named this mode something other than atomic <cnd> maybe "compat" mode <dandrader> so that rule of having only one accepted gesture at a time doesn't hold, right? <cnd> it does, in the sense that only gestures for the same touch set are allowed <cnd> i.e. you can't have a one touch drag and a three touch drag at the same time <dandrader> so the rule is that the accepted gestures must take all existing touches <cnd> yeah * cnd can't wait to move away from atomic mode... <dandrader> for a given recording made with evemu you're guaranteed to get the exact same number of grail slices independently of the machine where that recording is played? i.e., the update frequency will be the same, etc? <dandrader> cnd, ^ <cnd> dandrader, should be <cnd> evemu playback is nondeterministic when it comes to timing though <cnd> it should be close, but the exact timestamp deltas between events will never be quite the same <cnd> bregma, I have fixed up the xorg-gtest stuff and confirmed it works with a rejiggered utouch-grail <cnd> it's mostly left the same as before, only now the macros has ACTION-IF-FOUND etc. <cnd> and the readme points out that manual automake rules is a valid way of handling things <cnd> do you want me to send it out for closer review again <cnd> or just push it so we can move on to fixing our tests? <bregma> cnd, if it works, I think it's been reviewd enough that you can just go ahead and push it <cnd> ok <cnd> if I were on the release team I would have real ultimate power <cnd> packages would quiver in my wake <cnd> oops, wrong channel :) <cnd> though to be clear, that was sarcastic :) <bregma> with power comes responibility <bregma> you couldn't drink during UDS, for example <cnd> oh man... #ubuntu-touch 2012-03-20 <cnd> bregma, Satoris, tvoss, dandrader: standup time! <bregma> working on #904731 and #944822 <cnd> I'm going to work on fixing xorg-gtest usage in frame and grail, and then uploading them to precise <dandrader> Writing a test case for a bug I found in utouch-grail atomic recognizer (the fix is very simple). It's currently assuming that there can be only one accepted gesture at any given time. But that's not the case. The best thing about the test case is that it will serve as a way of documenting the expected behavior of the atomic recognizer. <Satoris> Aptng work and Chromium stuff and bugs. <Satoris> Also: trying to make coverage work so that it is understandable. <cnd> bregma, would you be able to give a review to my grail xorg-gtest source branch? <cnd> once it's reviewed for grail I can do the same for frame <cnd> Satoris, what's wrong with coverage? <bregma> sure, I'll get to it soonish <cnd> k <cnd> dandrader, will you have a fix for grail today? <Satoris> cnd: as in making Coverage work in CMake without contortions. It (or rather CTest) has direct support but it's poorly documented. <dandrader> cnd, yes <cnd> Satoris, ok <cnd> dandrader, alright, let me know if it slips, otherwise I'll wait for it to make a grail release <dandrader> cnd, I'm (or I was) trying to find a way to check slices in a test that is more flexible than expecting a very precise and specific order and number of slices but that is also not complex to write or understand <cnd> dandrader, more power to you if you find a way :) <cnd> though for the most part I don't think we should be trying to match up specific events <cnd> the two drag recording test is a special test <tvoss> sorry, was on the phone <cnd> it's like a canary in a coal mine in that if we change the behavior in any way, it will be seen there <tvoss> spent today with fixing/checking the jenkins instance <cnd> but other tests generally just check the values of the properties at some non-determinate gesture event <cnd> biab <cnd> bregma, I'm starting to queue up grail commits <cnd> the sooner you can review the gtest source changes the better * bregma feels the anxiety <bregma> cnd, I get autogen.sh failure on a clean checkout, something is wrong <cnd> bregma, what's the failure? <bregma> configure.ac:41: error: possibly undefined macro: AC_MSG_NOTICE <bregma> and so on <bregma> really weird <cnd> I got that yesterday when I didn't have xorg-gtest.m4 in /usr/share/aclocal <bregma> ah, yes, that would do it <cnd> bregma, have you updated to libxorg-gtest-dev? <bregma> evidently not <cnd> version 0.2.0-0ubuntu1 <bregma> off to do that now <bregma> libxorg-gtest-dev evidently depends on xutils-dev 1:7.7 but that depend is missing from the packaging <cnd> bregma, ahh, yeah, I forgot about it <cnd> I'll file a bug for it <cnd> bregma, my laptop that I've been doing gtest-source devel on is not booting <cnd> I'll get it fixed soon, but that's the delay :( <cnd> oh noes! <cnd> my magic mouse has died :( <cnd> phew, new batteries somehow fixed it <bregma> those mice seem to eat batteries <cnd> bregma, I fixed the gtest-source branch now #ubuntu-touch 2012-03-21 <cnd> dandrader, can you review my grail merge proposals soon? <cnd> we need to get them in, and your fix in today <cnd> before the beta 2 freeze tomorrow <dandrader> cnd, sure. Right after I finish the refactoring I'm doing on my merge proposal as per your comment <dandrader> comments <cnd> cool <cnd> thanks :) <tvoss> Spending some quality time with Jenkins and Google Test/Google Mock, Prepared packaging for patched chromium <bregma> I got utouch-geis up-to-speed on libxorg-gtest-dev, now back to the grind on #904731 and #944822, pending merge-request-reviews <dandrader> I'm refactoring the test in my merge proposal for utouch-grail according to comments received from Chase <cnd> I'm fixing up utouch-frame for the new xorg-gtest, and then I'll be releasing frame and grail upstream and for precise <cnd> Satoris won't be around for standups on wednesdays for a while <cnd> just fyi <bregma> Wednesdays have always been special to his people <cnd> bregma, just reviewed your branch <cnd> I'm stumped by this failure: http://paste.ubuntu.com/893791/ <cnd> it attempts to link a program <cnd> it complains about not finding the evemu symbols in libxorg-gtest.a <cnd> but I have -lutouch-evemu before libxorg-gtest.a on the command line <bregma> link order is significant <cnd> yeah, and I think I have it in the right order <bregma> no, it's in the reverse order <cnd> argh <cnd> yeah <cnd> I got switched up <bregma> now fight with libtool to get things in the right order <bregma> although that bug ni libtool was probably fixed years ago <cnd> dandrader|lunch, I just reviewed your branch <cnd> looking good :) <cnd> alright, I've got all the merge proposals out that I wanted to get into beta 2 <cnd> as soon as they are all merged into grail and frame I'll be making releases <cnd> biab <Satoris> cnd: ping <cnd> Satoris, pong <cnd> oh right <cnd> sorry! <cnd> I should have replied <dandrader> cnd, about https://code.launchpad.net/~chasedouglas/utouch-grail/fix-tap-touch-accept/+merge/98478 <dandrader> what's the effect of accepting of rejecting a touch that has already ended? <dandrader> s/of/or <cnd> dandrader, all touches must be accepted or rejected no matter what <cnd> if a touch has ended, then when you reject, the entire touch sequence will be replayed to further X clients <cnd> so imagine you have a finger paint app open <cnd> you tap on the screen with one finger <cnd> the touch ends before grail rejects the tap <cnd> grail still needs to reject it, and then the X server will resend the touch event sequence to the finger painting app <dandrader> ChickenCutlass, you mean it will resend the touch event sequence to a X client other than the finger painting app, right? <dandrader> cnd, ^ <dandrader> damn auto-completion <cnd> dandrader, no, it will resent it to the finger painting app <cnd> here, I'm assuming grail is being used through unity <cnd> so unity's grail touch grab is rejecting the touch <cnd> and then the finger paint application will receive the touch sequence <dandrader> ah, ok <cnd> dandrader|afk, bregma: I need one last review: https://code.launchpad.net/~chasedouglas/utouch-frame/fix-visibility2/+merge/98725 <cnd> it's necessary before we make a release of utouch-frame <cnd> dandrader, btw, you don't need to fully resubmit a merge proposal <cnd> merely updating the branch will suffice :) <cnd> you can signify that you've fixed things and it is ready for review again by leaving a comment with a review type of "Resubmit" <dandrader> ok, that will probably make the review simpler as you can just look at the new commits containing the changes caused by the review comments <dandrader> than I can squash them all before pushing to trunk <dandrader> s/than/then <cnd> dandrader, you don't really need to squash them even <cnd> you just merge them in <cnd> and they'll appear to be one commit <cnd> then you can still drill down into the history if you really want <dandrader> but those commits that are just fixes coming from review comment just clutter the history <cnd> dandrader, if you don't want to see the clutter, then just diff from the beginning to the end of the rview <cnd> which will normally be the diff of the merge itself <cnd> dandrader, your testcase is failing <cnd> it's in the jenkins instance <cnd> dandrader, I can confirm the failure here <cnd> I need to grab a sandwich <cnd> then I'll try to figure out what's going wrong <cnd> it looks like bad events are being fed into frame though... <cnd> that would cause the "Warning: failed to get previous touch value" <dandrader> damn, I'm not getting any failure here with current trunk versions of utouch-frame and utouch-grail... <cnd> dandrader, I don't have the current frame installed, let me double check <dandrader> from the error it seems that nothing was played <dandrader> as the slice checker was still on its first state, which check for a Begin slice from the touch gesture <dandrader> cnd, have you run that ParallelAtomicGestures test before on your machine? <cnd> dandrader, not until just now <cnd> I assumed it would work <dandrader> :) * cnd can't wait until we have proper jenkins support <dandrader> could you check if the recording plays correctly on your machine? <cnd> yeah, I'm just setting up frame right now <cnd> from scratch <cnd> to be sure <cnd> dandrader, with the latest utouch-frame it fails in the same way here <cnd> dandrader, I just noticed that you copied in the asynchronous playing of the recording <cnd> which I just removed from all the other tests :) <cnd> I should have caught that in review <cnd> but sadly it's not the cause of the failure <cnd> dandrader, here's my output with grail debugging: http://paste.ubuntu.com/894298/ <cnd> let me know if you can make anything out * dandrader reads... <dandrader> that touch 4 is coming way too soon <dandrader> with the same timestamp as touch 3 <dandrader> causing all gestures to be canceled before they have a chance to do anything <dandrader> when I did the recording the 4th touch should come just by the end of the recording * cnd tries to read the recording <cnd> the fourth touch linda89@example.com <cnd> the beginning is 1331926700.835657 <cnd> the end is 1331926701.548991 <cnd> so it's about half way between the beginning and the end <cnd> but the whole recording is less than one second long <cnd> does that seem right? <cnd> in the debug output, gestures 0, 1, and 2 start at time 691389450 <cnd> the first touch began at time 691389450 <cnd> same time <cnd> the fourth touch begins at time 691389450 <cnd> which is the same time again... <cnd> that doesn't seem right <dandrader> could you try to play it with evemu-play and watch it with mtview? <cnd> yeah, <dandrader> cnd, http://ubuntuone.com/3zGHZA1ILFUm6LgFrhEYOZ <dandrader> this is what I get in the end <dandrader> the pink blot is the fourth touch that comes late <cnd> dandrader, using evtest, I see the three touches begin at time 1332366154.522432, and then
{'channel': 'ubuntu-touch', 'month': 3}