=== MacSlow is now known as MacSlow|lunch [12:43] With new daily builds, gestures work out of the box. Three fingers is still too fast, though. [12:46] Then again network is broken on my laptop. You win some, you lose some. === MacSlow|lunch is now known as MacSlow [14:01] * tvoss notes that green is the new black :) [14:13] Satoris, I just merged a fix into geis last night that should make the three touch drag more appropriately fast [14:13] I wonder if the daily builds have run yet... [14:13] nope [14:13] iterated chromium patch and commented on feedback from devs, jenkins work and an itv [14:14] tvoss, itv? [14:14] cnd, interview [14:14] ahh [14:15] I have a nice little geis merge request pending if someone is looking for something to do [14:15] bregma, yeah, will get to that soon [14:15] I will be reviewing bregma's patch today :), and then helping dandrader with anything he needs to get unity gesture fixes merged [14:16] and when the archive freeze lifts, I'll be pushing packages [14:16] will the freeze lift or is it staying in release freeze until release? [14:16] Satoris, dandrader: standups! [14:17] bregma, it will lift [14:17] bregma, final freeze is in 2 weeks [14:17] I'm updating my patch that fixes the dragging of windows with 3 fingers in unity according to the review comments it received [14:17] are you planning to do all the packages or should we divide and conquer? [14:17] Then I'll work on https://bugs.launchpad.net/utouch-geis/+bug/967605 [14:18] bregma, we can divide and conquer [14:18] I'm fine either way [14:18] bregma, oh, I was also thinking of trying to fix make distcheck on as many packages as possible too [14:19] I didn;t realize it was broken [14:19] it is on grail and frame at least [14:19] or it was on grail [14:19] it might work now that jussi fixed the recording path issue [14:19] I suspect geis is broken too [14:20] not last time i checked [14:20] I'll check all the packages today, I don't want to start any new bugfixes until after release [14:21] anyone know if #940308 is still an issue after the recent frail changes? [14:21] s/frail/grail/ [14:21] heh [14:21] * bregma thinks there are too many different keys on the keyboard [14:21] bregma, I'm guessing it's fixed now [14:21] I'm sure all our recent changes were robust [14:22] but someone needs to verify for sure [14:22] hmm, OK, I'll check that too [14:23] Sorry for the delay, was talking with olli. [14:24] dandrader, do you think you'll have #967605 fixed today (ie. before the geis-2.2.8 release)? [14:24] Did the script thingie. Also tested somewhat. [14:25] bregma, yes. I have it fixed on my test application, using std stuff from C++. Now it's just a matter of adapting it to pure C for the grail backend in utouch-geis [14:26] how hard can it be? %} [14:28] :) just a bit frustrating [14:39] Satoris, for the bug counter stuff, we want: all bugs that are for projects with a structural subscription for utouch-bugs, and all ubuntu package bugs subscribed by utouch-bugs [14:39] we don't need to manually specify the projects we care about because launchpad can get all that info for us [14:40] er, what's a "structural subscription"? [14:41] bregma, it's when you subscribe a team to all the bugs for a project [14:41] rather than directly subscribing to each individual bug [14:42] cnd: you mean this https://bugs.launchpad.net/~utouch-bugs/+packagebugs [14:43] Satoris, no, for packages we can search for all the bugs we are directly subscribed to: https://bugs.launchpad.net/ubuntu/+bugs?field.subscriber=utouch-bugs [14:43] it should be possible to do the same thing that search query does, but in launchpadlib [14:44] look at the ls-team-subscribed-package-tasks.py script in arsenal [14:44] The script already does that as far as I can see. [14:44] In addition it will add all bugs from specified projects, because utouch-bugs is not subscribed to those. [14:47] Satoris, oh! I think I see what's going on [14:47] you found a way to get all direct subscriptions for all bugs [14:48] I had thought that was impossible due to a bug in lp that was timing everything out [14:48] For utouch-bugs? Yes. [14:48] yeah [14:48] Satoris, however, we're still missing the piece that gets all the bugs from the structurally subscribed packages [14:48] basically, you manually listed the packages [14:48] Olli asked me to put the script to helipad, so I will do that once it's good. [14:48] but we should be querying for what packages are structurally subscribed [14:48] helipad? [14:48] lp:helipad [14:49] hmm [14:49] So where in lp do you get the structural subscription info? A web page is enough to get me started. [14:50] look at the ls-team-subscribed-package-tasks.py script in arsenal [14:50] Will do. But there isn't a web page that shows it directly? [14:50] http://bazaar.launchpad.net/~arsenal-devel/arsenal/master/view/head:/scripts/ls-team-subscribed-package-tasks.py [14:51] and we'll want to do the same for projects if possible === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [15:15] bregma, just reviewed your MP [15:17] bregma, fyi, the jenkins build isn't running the integration tests [15:17] need to figure out why that is... [15:19] oh, it's run with ./configure --without-integration-tests... [15:21] bregma, we should remove the --without-integration-tests from the geis packaging [15:22] it should be automatically set to no in the archive because xorg-gtest isn't installed [15:22] but it is on jenkins [15:22] I'll remove it right now :) [15:24] please test in a pbuilder to make sure the distro builds do not break [15:24] I really hate that [15:25] will do [15:27] bregma, I wasn't aware of the dh --parallel flag [15:27] we should add that to all our stuff :) [15:27] * cnd sings "The more you know..." tune from the nbc commercials [15:27] you know it breaks dh_install, right? [15:27] oh? [15:27] bregma, how does it work for geis? [15:28] actually, I'm wrong [15:28] dh_install ignores it, "make install" fails with -jN where N > 1 [15:28] ahh [15:28] a lot of Debian sponsors strongly suggest you use it in all your packaging [15:29] makes sense [15:30] the dh sequencer and all its little dh_friends is the greatest thing since sliced bread [15:30] even if joeyh is a bit sructy sometimes [15:30] um, crusty [15:30] heh, structy [15:31] I used to accidentally type integer where I means in after doing too much fortran programming [15:31] my fingers would just keep on going [15:33] heh [15:33] bregma, I see you filter out the jquery.js file at install time for geis [15:33] has the system-installed jquery been updated so it doesn't break the docs? [15:37] cnd, yes, the system jquery.js work fine with the docs, and lintian is happy with the packaged one removed [15:37] cool [15:38] we need to update that too in the other packages :) [15:38] yep [15:39] Debian sponsors like zero non-pedantic lintian warnings unless there is a really good reason for overrides, and jquery.js is not one of the good reasons [15:40] lintian -EviL +pedantic is a good mnemonic ("Debian sponsors are evil and pedantic") [15:40] heh [15:43] bregma, the geis configure.ac stuff for integration testing is broken [15:43] I'm going to copy over the stuff from grail [15:56] bregma, just submitted MP [15:59] * tvoss is back from tax-hell [16:41] gah, whoever maintains bzr-builder needs to be shot [16:41] not only do they not push updates to their ubuntu package [16:41] but now they say they have a ppa [16:42] https://help.launchpad.net/Packaging/SourceBuilds/BzrBuilder [16:42] but it's private! [16:42] why? [16:42] the started drinking too early in the day [16:43] tvoss, will our jenkins stuff move to the public qa.ubuntu.com site at any point? [16:43] cnd, ack, the move is scheduled already [16:43] ok, cool [16:44] cnd, cannot give you an eta yet but larry is working on it [16:44] ok [16:45] cnd, but my hope is that he starts moving over the jobs once they have done their update [16:45] tvoss, update to jenkins? [16:45] cnd, just forwarded you an email [16:46] k [16:49] bregma, I can't get dailydeb to work [16:50] any issues if I push the changes to the geis ubuntu packaging branch and kick of a daily ppa build [16:50] to see if it all works properly? [16:51] oh, too late [16:51] already pushed :) === dandrader is now known as dandrader|lunch [16:55] what errors are you getting from dailydeb? [16:57] I got around the errors, but nothing was output [16:57] bregma, have we not fixed geis for daily builds? [16:58] it built yesterday [16:58] I thought we did, but m4/xorg-gtest.m4 doesn't exist upstream [16:58] yeah, but that was likely because it was built with --with-integration-tests=no [16:59] I guess we only fixed grail and frame [16:59] but if it was built --with autoreconf that shouldn;t matter [16:59] bregma, libxorg-gtest-dev isn't a build-dep [16:59] so it's missing xorg-gtest.m4 [17:00] --with autoreconf should force configure to get regenerated, which requires the m4 macro, so I can;t explain why the daily PPA succeeded yesterday (or my pbuilder builds, for that matter) [17:01] true... [17:03] I seem to be getting failures in my geis test sute due to incorrect window IDs coming from grail, I'm investigating [17:04] ok [17:05] bregma, new MP: https://code.launchpad.net/~chasedouglas/utouch-geis/fix-daily-builds/+merge/99980 [17:24] did you guys see the uTouch question on unity-dev? [17:25] olli_, yeah, but I wasn't subscribed to unity-dev before then, so I couldn't respond :) [17:25] which ted tried to route to multi-touch-dev [17:25] cnd, ok [17:25] hopefully they send it over to multi-touch-dev [17:25] yeah [17:30] hmm, my test suite problem seems to be pointer trouble somewhere in geis [17:40] uhoh [18:17] bregma, I hope you like reviewing MPs, because I have another: https://code.launchpad.net/~chasedouglas/utouch-geis/fix-gtest-includes/+merge/99993 [18:17] :) [18:19] My goal is to get the integration tests running on jenkins [18:19] and I think this is the last bug [18:22] I'm getting integration test fails due to some invalid state with X, so until I fix that I would expect failures [18:22] obviously something missing in geis [18:23] the most recent test leaves the connection in a weird state, or something, so subsequent tests all fail [18:23] randomizing test order can reveal much [18:25] interesting [18:29] ... heh, the bad X state is a red herring, I was missing a geis_subscription_delete() at the end of my test case [18:29] I dunno what the bad X state is, but it doesn't hurt anything === tvoss is now known as tvoss|eod [18:33] yay? [18:34] hrm... another jenkins failure... [18:34] make[4]: *** No rule to make target `/src/xorg-gtest-all.cpp', needed by `libgtest_geis_a-xorg-gtest-all.o'. Stop. [18:34] but it found it in configure: [18:34] checking for /usr/src/gtest/src/gtest-all.cc... yes [18:34] so the prefix isn't being used properly... [18:35] oh wait, it can't find xorg-gtest-all.cpp, but configure found gtest-all.cc [18:35] which are different files === dandrader|lunch is now known as dandrader [18:43] gotta run an errand, biab [18:52] cnd, do all utouch projects follow the same coding style? [18:52] dandrader, geis was created before we had a standard coding style [18:52] so it's different :( [18:52] basically, two spaces indents and curly braces on new lines [18:53] everything else is fairly similar [18:53] ok [18:56] I guess two space indents is common for all our projects now [18:56] it wasn't in the beginning [19:46] bregma, I *think* I've got the jenkins builder working [19:47] I'm running a pbuilder right now [19:48] bregma, it was a problem with the jenkins build script [19:48] OK [19:49] bregma, this is what we need to fix now: http://paste.ubuntu.com/906168/ [19:51] bregma, the recordings moved yesterday :) [19:51] if your test was working, you were probably using a stale branch [19:51] I'm just going to commit a fix with the path prefix addition of ../recordings [19:51] yep [19:52] if you pass the tests locally no need for a MR [19:57] ok, committed [19:58] I still get one geis1 test failure [19:58] I'm running builds in jenkins [19:58] we'll see if it confirms [19:59] bregma, do know how to reach jenkins? [20:02] bregma, hmm, it passed on i386 [20:03] 83 passing tests :) [20:03] hmm... 1 failure on amd64 [20:04] [ RUN ] Geis1AttributeTests.tap_touch_count [20:04] gtest_attrs.cpp:123: Failure [20:04] Value of: saw_four_tap [20:04] Actual: false [20:04] Expected: true [20:04] [ FAILED ] Geis1AttributeTests.tap_touch_count (3084 ms) [20:04] could be a timing issue, I'll rerun to see if it is [20:05] hmm... the gtest tests aren't being accounted for in the jenkins results [20:06] probably an oversight in the jenkins script [20:06] I'll see if I can fix it [20:35] man, I keep getting launchpad timeouts [20:35] it's harshing my mellow [20:36] odd [20:36] bregma, we got that same tap_touch_count failure on amd64 [20:37] only on amd64? [20:38] yeah [20:38] I'm wondering if it's a timing issue due to running geis1 then geis2 gtests in rapid succession [20:38] the geis1 dummy server hasn't fully shut down [20:39] oops, other way around [20:39] the geis 2 dummy server hasn't fully shut down [20:39] before the first geis 1 gtest test is executed [20:39] we really should be compiling all the tests together anyways [20:41] I'll attack that after lunch [20:41] since the archive freeze hasn't lifted yet [20:41] OK, I gotta run, too, be back later [20:41] oh wait, it has [20:41] :) === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader| === dandrader| is now known as dandrader [21:57] bregma, what do you do when you need to mix linker flags and archives in automake [21:57] and they have to be in the right order [21:58] if you put them in LDFLAGS, it rearranges all flags in front of libs, which is wrong [21:58] and if you put it in LDADD, it errors out [22:01] hmm.. starting to think it won't work [22:24] bregma, I'm trying to build and link the gtest tests in each geis* directory [22:24] and then link both static libs into one gtest executable [22:24] the problem is that this breaks gtest test registration [22:27] because the tests in the static libs have global constructors that aren't referenced by anything [22:27] so they aren't pulled in to the executable [22:28] the --whole-archive linker option would fix things, but it's non-portable and requires intermixing the flag with the libraries [22:28] I think I'm going to give up for today [22:28] and move on to other work [22:37] are utouch-geis tests all passing on your machines? [22:40] dandrader, I get a failure in the second geis1 test [22:41] [ RUN ] Geis1SubscriptionTests.basic [22:41] gtest_subscription.cpp:65: Failure [22:41] Value of: geis_subscribe(geis(), ((GeisInputDeviceId)0), gestures, &callbacks, this) [22:41] Actual: -999 [22:41] Expected: GEIS_STATUS_SUCCESS [22:41] Which is: 0 [22:41] [ FAILED ] Geis1SubscriptionTests.basic (2010 ms) [22:41] I don't know why [22:41] it works fine in jenkins [22:41] cnd, same with me [22:41] hmm [22:41] (the error) [22:41] ok [22:41] but the funny thing is that with lp:~dandrader/utouch-geis/lp967605 I get a failure in some other test instead [22:42] which test? [22:43] [ RUN ] GeisSubscriptionTests.duplicate_window_subscription [22:43] gtest_subscriptions.cpp:91: Failure [22:43] Expected: (GEIS_STATUS_SUCCESS) != (geis_subscription_activate(sub2)), actual: 0 vs 0 [22:43] mistakenly activated subscription 2 [22:43] [ FAILED ] GeisSubscriptionTests.duplicate_window_subscription (2128 ms) [22:43] dandrader, so I think I know what's wrong with the subscription test [22:46] the previous test is subscribing, but not unsubscribing is my guess [22:46] hmm. well, I gotta go. see you tomorrow [23:41] ho! I have returned! [23:42] cnd, are you running the most recent, shiniest, up-to-date geis (with my fix for the device-removed test case that caused subsequent tests to fail)? [23:42] bregma, it's a combo of a bug in geis and a bug in the xserver [23:43] ungrabbing a touch grab is not synchronous, unlike grabbing a touch grab [23:43] you have to call XSync or XFlush afterwards so the request actually is sent to the server [23:43] so from one test to the next, the window grab wasn't actually getting ungrabbed [23:43] I have a visceral dislike of gotches [23:43] but on top of that, it turns out that we forgot to implement touch ungrab upstream :) [23:43] the fix I put in was ungrabs were never getting executed at all [23:44] what fix? [23:44] the last commit for #944822 [23:44] my test cases started to fail, so I dug in to it [23:45] found I was returning a bad pointer from a call that caused the ungrab to never get executed [23:45] ahh [23:45] that, and I never called geis_subscription_delete() from the test case, which cause the XClose() to not becalled, which messed things up [23:46] so it was a perfect storm of bugs :) [23:46] yes, and randomizing the test run order was a good thing