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