[00:02] <bregma> cnd, no matter what I try the pthreads libs are not getting picked up for xorg-gtest when I try to build geis HEAD, have I missed something obvious?
[00:03] <cnd> bregma, the probably need to be specified manually in LIBADD or LDADD
[00:03] <cnd> are they?
[00:04] <bregma> you mean I need to explicitly specify a dependency of xorg-gtest that only gets used by xorg-gtest and nothing in geis?  that seems broken.  Why does it work for you and jenkins?
[00:07] <cnd> I don't know, but specifying a dependency of another library that you built yourself doesn't make sense to me
[00:08] <cnd> sorry, it makes sense to me
[00:08] <cnd> when using the Makefile-xorg-gtest.am from xorg-gtest, it adds -lpthread to XORG_GTEST_LIBS
[00:09] <bregma> why isn't that symbol defined in the xorg-gtest autoconf macro, they way it is for pretty much everything else under the sun?
[00:20] <cnd> bregma, perhaps it should
[00:31] <bregma> is there any reason I shouldn;t upload utouch-evemu at this point?
[00:36] <cnd> bregma, nope :)
[00:37] <cnd> the issue I was thinking about yesterday, device props, has been implemented since forever
[00:37] <cnd> I just didn't realize it :)
[00:37] <cnd> there are no outstanding bugs, so have at it
[00:45] <bregma> done, one down
[00:46] <cnd> bregma, MPs out: https://code.launchpad.net/~chasedouglas/utouch-geis/ungrab-test/+merge/100060 https://code.launchpad.net/~chasedouglas/utouch-geis/fix-ungrab/+merge/100061
[00:53] <cnd> bregma, what do you think about a geis release? should we wait for dandrader's fixes?
[00:53] <cnd> he seems somewhat close, but they are also merely refinements
[00:53] <cnd> since we currently have a broken geis in precise
[00:53] <cnd> it's kinda late today anyway though...
[00:54] <cnd> I suppose we might as well wait till tomorrow
[00:56] <bregma> doesn't his MR do the entire fix?
[00:57] <bregma> either way, I want his fix in if possible, and tomorrow is as good a day as any
[00:59] <bregma> what about frame and grail?  are they ready for release?
[01:01] <cnd> bregma, frame has one minor bug that hasn't been worked on yet, not a blocker
[01:01] <cnd> grail is ready
[01:02] <cnd> bregma, oh, I didn't see dandrader's MP :)
[01:03] <bregma> it's just so exciting to get new releases out, it's just like Christmas
[01:03] <bregma> I intend to go over dandrader's fix tomorrow, it's getting late here
[01:10] <cnd> bregma, np, though I might get to it tonight :)
[01:10] <cnd> or how about right now :)
[01:25] <cnd> bregma, I wouldn't worry about reviewing dandrader's branch tonight
[01:25] <cnd> it needs a fix before it's ready to be merged
[01:29] <cnd> I see we reviewed simultaneously :)
[01:53] <bregma> another 15-hour day, time to walk away from the computer
[01:55] <bregma> (not a continuous 15 hours, I'm not an addict)
[02:35] <cnd> heh
[12:07] <Satoris> bregma: trying to execute run_pygeis with newest Geis gives AttributeError: 'module' object has no attribute 'GEIS_INIT_SYNCHRONOUS_START'. Is this a known issue?
[12:45] <bregma> Satoris, is this from an installed package or is it in the build directory?
[12:45] <Satoris> Build directory.
[12:45] <Satoris> In-source build.
[12:47] <bregma> I suspect the problem is in trying to pick up the new python runtime from within the build tree, I've had problems with that and I'm not sure if I ever fixed them all
[12:47] <Satoris> So effectively bzr branch, cd, autogen, configure, make, cd python, ./run_pygeis
[12:48] <Satoris> But shouldn't SYNCHRONOUS be in the system tree also, because I have the daily build PPA.
[12:48] <Satoris> And inded, running pygeis from /usr/bin fails also.
[12:51] <Satoris> Should I file a bug on this?
[12:52] <bregma> yes, there's a line missing from python/geis/__init__.py
[12:56] <Satoris> I see it. But after fixing that I get a different error.
[12:57] <bregma> AttributeError: 'NoneType' object has no attribute 'activate' ?
[12:58] <Satoris> Yes.
[12:59] <bregma> that looks like a bug in pygeis itself, it explicitly passes None to a fucntion and calls .zctivate() on it
[12:59] <bregma> s/.zctivate/activate/
[13:00] <bregma> dunny what the developer was thinking there
[13:01] <bregma> I think that tool may need to be rewritten
[13:02] <Satoris> Is there an other way to test the Python bindings?
[13:04] <bregma> geisview should work, it's the main python tool
[13:05] <bregma> only I think you need to set LD_LIBRARY_PATH and PYTHONPATH manually if you run it in the build directory, I can't remember is I wrote a wrapper script
[13:08] <Satoris> There does not seem to be one.
[14:14] <cnd> bregma, tvoss, Satoris: standups!
[14:15] <cnd> I'll be working on releases for much of the day I think
[14:15] <tvoss> chromium gyp fun, restored geis green on jenkins
[14:15] <cnd> then looking through any and all bugs I can figure out
[14:15] <tvoss> refactored parts of the patch to ease testing
[14:15] <bregma> what's the status on frame and grail releases?
[14:16] <Satoris> Found critical bug in launchpadlib, bug fixes and code cleanup.
[14:16] <Satoris> s/critical/high/
[14:16] <cnd> bregma, they just need to be done
[14:17] <bregma> mm'kay
[14:17] <cnd> bregma, geis in jenkins has one failure
[14:17] <bregma> I'm waiting for dandrader's fix to get in before making a geis release
[14:17] <cnd> Geis1AttributeTests.tap_touch_count
[14:17] <bregma> right
[14:17] <Satoris> bregma: will merge the Python fix in a few seconds.
[14:18] <cnd> bregma, I'm not sure what's wrong with it off the top of my head
[14:18] <bregma> I can reproduce the tap count failure locally
[14:18] <bregma> I'll take a look and see if I can spot anything
[14:18] <cnd> ok
[14:19] <tvoss> bregma, if it helps: it only happens on amd64
[14:20] <cnd> tvoss, no it happens on i386 too
[14:20] <cnd> bregma, tvoss, Satoris: I'm leaving for a couple hours
[14:20] <tvoss> cnd, ack
[14:20] <cnd> will be back, in an undisclosed location, soon :)
[14:20] <bregma> I plan to take the week end off this week
[14:23] <bregma> in the mean time, if we're asked, we will neither confirm nor deny knowledge of your whereabouts
[14:24] <Satoris> cnd: did not put the script in Helipad or Arsenal due to the bug and confusion on what will happen to those projects.
[14:26] <bregma> tvoss, you have #950974 assigned to you for utouch-grail, it's targeted for this release and marked as 'in progress': should that be changed or is there a fix pending?
[14:26] <tvoss> cnd,
[14:26] <tvoss> bregma, fix is pending, I can have it in like next week
[14:30] <bregma> I would like to release utouch-grail 3.0.4 today to get the tap fixes out and get some wider testing of the touch accounting changes, we can push  #950974 into the 3.0.5 release
[14:30] <tvoss> bregma, that would be great
[14:30] <bregma> utouch-frame has no outstanding bugs targeted, it should go out today, too
[16:25] <cnd> tvoss|dinner, bregma: I'm back
[16:26] <cnd> the portland posse is having a knitting session at the OSU open source labs
[16:26] <bregma> do you knit?
[16:27] <cnd> knitting is a euphemism :)
[16:29] <bregma> not to my wife
[16:29] <bregma> knitting is a religion
[16:49] <cnd> dandrader, do you have a fix for xsync alarms in the utouch-grail tools?
[16:49] <cnd> if not, I'll try to whip one up
[16:51] <dandrader> cnd, I do but own my own version test app derived from those tools. not published anywhere. It's not in a perfect shape so feel free to do so
[16:51] <dandrader> s/own my/on my
[16:51] <cnd> ok
[16:58] <bregma> dang, I just realized I booked the wrong return date for UDS
[16:59] <bregma> I booked a return flight on Thursday instead of Saturday
[16:59] <bregma> tere are no convenient flights Saturday anyway, since BART doesn't start running until 06:00
[17:01] <cnd> that sucks
[17:02] <bregma> evidently if you want to leave the Bay Area during daylight hours and head east you are out of luck
[17:04] <cnd> that seems odd
[17:04] <cnd> bregma, I'm leaving friday late morning to go to indian
[17:04] <cnd> indiana
[17:05] <cnd> actually, it's early afternoon
[17:05] <cnd> 1:06 PM
[17:06] <cnd> OAK->SLC
[17:06] <cnd> SLC->IND at 5:02 MDT
[17:06] <cnd> dandrader, bregma, I approved the xsync MP
[17:09] <cnd> dandrader, is it necessary to delete the alarm?
[17:09] <cnd> I guess I'll find out
[17:09] <dandrader> cnd,  if not you will get an endless streams of alarm events from the time your timeout has been reached
[17:09] <cnd> ok
[17:17] <cnd> dandrader, oh wait
[17:17] <cnd> you forgot an XFlush after creating the alarm
[17:18] <dandrader> cnd, hmm, what its absence can cause?
[17:18] <cnd> the request would be put into the Xlib queue
[17:18] <cnd> but it might not be sent to the server
[17:18] <cnd> so in effect, the alarm may be set now, or any time in the future
[17:18] <cnd> including after it was supposed to fire :)
[17:19] <cnd> so a tap may not be recognized properly
[17:20] <dandrader> it has already been merged. Should I make a new proposal with this addition?
[17:20] <dandrader> cnd,
[17:20] <cnd> dandrader, just commit it on top
[17:20] <dandrader> ok
[17:20] <cnd> and reference that it was missed in the MP
[17:22] <cnd> bregma, any luck on that geis test?
[17:23] <bregma> not yet
[17:24] <cnd> bregma, you haven't released grail yet, have you?
[17:24] <cnd> I'm going to fix the tools for the xsync alarm stuff
[17:25] <cnd> nope, doesn't look like it
[17:27] <bregma> all I did with grail was fix the failed daily build
[17:28] <cnd> k
[17:40] <bregma> bah, I can't get the tap_touch_count test failure to happen locally any more
[17:46] <bregma> whoops, got it again, it's very transient
[18:01] <cnd> hmm
[18:02] <cnd> dandrader, I think the positivetransition test is just broken in the server
[18:02] <cnd> and I just don't feel like maintaining a list of alarms
[18:02] <cnd> so I'm going to try fixing it instead :)
[18:02] <dandrader> cnd, you're my hero :)
[18:05] <cnd> dandrader, would we still have to delete the alarm?
[18:05] <cnd> or do you think it would just disappear?
[18:05]  * cnd digs into the source
[18:06] <dandrader> cnd, I would think you have to delete in any case
[18:16] <cnd> dandrader, interesting, embedded in the sync implementation is a coment and if statement that we can use
[18:16] <cnd> or not
[18:16] <cnd> it didn't do what I thought it would :)
[18:16] <cnd> about to install my debug xserver build though
[18:16] <cnd> we'll find out
[18:29] <cnd> dandrader, aha!
[18:30] <cnd> http://paste.ubuntu.com/907656/
[18:30] <cnd> notice that I set the delta to 0 and used XSyncCADelta when creating the alarm
[18:30] <cnd> if the delta is 0, the alarm will only fire once
[18:31] <cnd> and then there's XSyncChangeAlarm
[18:31] <cnd> so we can have one alarm per grail instance
[18:31] <cnd> and just keep changing it as needed
[18:32] <dandrader> what if you need more than one timeout to be set simultaneously (ie. one at X+123 and another at X+345)
[18:33] <dandrader> I mean, I you want to set a new timeout before the current one timed out
[18:33] <cnd> dandrader, you could have two alarms, but when would you need two alarms for one grail instance?
[18:33] <cnd> if you need to set a new timeout that is later than the current one, then just change it
[18:34] <dandrader> so you don't need to update grail state at both moments, X+Y and X+Z? Only at X+Z?
[18:35] <cnd> correct
[18:35] <dandrader> ah, then that simplifies things
[18:35] <cnd> whatever grail says *now* is all that matters
[18:35] <dandrader> I didn't make that assumption
[18:35] <cnd> admittedly, the xsync implementation didn't work quite like that
[18:35] <cnd> I'm trying to fix up the grail test case right now
[18:35] <cnd> to ensure it all works properly
[18:37] <dandrader> cnd,  by the way: what the heck this delta means (in XSyncAlarmAttributes)?
[18:38] <dandrader> now that you've been enlightened by reading the source code :)
[18:38] <cnd> dandrader, apparently, it determines the *next* timeout after the alarm fires
[18:38] <cnd> it defaults to 1
[18:38] <cnd> so that's why the alarm continuously fires
[18:38] <cnd> I think we should be using PositiveTransition, but it doesn't work
[18:38] <cnd> but PositiveComparison + delta = 0 is good enough
[18:40] <dandrader> what a strange API...
[18:46] <cnd> sadly, I only have my netbook with me
[18:46] <cnd> much slower than behemoth...
[18:49] <cnd> dandrader, http://paste.ubuntu.com/907686/
[18:50] <cnd> it includes a fix where the grail test was still querying the server time instead of using the alarm notify event
[18:50] <cnd> oops
[18:56] <bregma> it looks to me like the cause of the intermittent tap_touch_count failure is that the captive X server does not receive notification of the evdev device until the test is over: the udev message is delayed until the write on the device is closed
[19:03] <cnd> bregma, hmm... interesting
[19:04] <cnd> bregma, do we need to flush the uinput writes?
[19:11] <bregma> I dunno, I'm still tracing through, but there's definitely something weird with ordering, because I play with the select() in the test and still nothing happens in the X server until the test starts to shut down
[19:11] <bregma> except when it works
[19:16] <bregma> ah, no, I think the server can;t open /dev/event/input19 (EBUSY), and gives a "PreInit returned 11" and ignores the device
[19:17] <cnd> bregma, that's likely because another X server has grabbed it
[19:18] <cnd> bregma, there's two remedies:
[19:18] <cnd> 1. run your tests in a VT
[19:18] <cnd> 2. install the xorg-gtest from git master which includes an X snippet to *not* grab virtual test devices
[19:18] <cnd> and then restart your X server
[19:18] <cnd> and ensure the test device has "Virtual Test Device" somewhere in its name
[19:19] <cnd> dandrader, MP for grail: https://code.launchpad.net/~chasedouglas/utouch-grail/xsync-alarm/+merge/100226
[19:19] <cnd> dandrader, would you be interested in releasing and creating an upload for grail after that's merged?
[19:20] <dandrader> cnd, sure
[19:20] <cnd> biab, going to get lunch
[20:12] <cnd> dandrader, ok, lets make a release of grail
[20:12] <cnd> I've started tracking bugs better, following bregma's lead :)
[20:12] <cnd> so let's start by looking at the open grail bugs
[20:14] <cnd> https://bugs.launchpad.net/utouch-grail
[20:14] <cnd> everything that is Fix Committed should be milestoned for 3.0.4
[20:15] <dandrader> nine in total
[20:15] <cnd> hmmm... wish I could search for unmilestoned bugs
[20:16] <dandrader> ok, they all have their milesone correctly set
[20:17] <cnd> ok
[20:17] <cnd> and every other bug should be sane
[20:18] <cnd> oops, I need to mark the xsync alarm bug as fix committed
[20:18] <cnd> ok, looks good
[20:18] <cnd> dandrader, now, we can make a release
[20:19] <cnd> I fixed make distcheck (yay), so checkout trunk, configure it, then run sudo make distcheck
[20:19] <cnd> probably on a VT unless you have the xorg-gtest snippet installed
[20:19] <cnd> cause it will attempt to run the tests
[20:20] <cnd> hopefully they all pass and it generates the tarballs
[20:20] <cnd> then release it upstream on lp :)
[20:21] <cnd> let me know when you're done
[20:21] <dandrader> ok
[20:41] <dandrader> cnd, release done. now for the package?
[20:41] <cnd> dandrader, now we have to move all the bugs to fix released
[20:41] <cnd> for the upstream package
[20:41] <cnd> I'll start from the bottom of the bug list
[20:42] <dandrader> cnd, so you will change that statuses yourself or I do it?
[20:42] <cnd> I can fix them
[20:42] <cnd> you can start the packaging
[20:43] <dandrader> ok
[20:43] <cnd> when you run bzr mu, before committing we need to add all the utouch-grail (ubuntu) bugs fixed to the changelog
[20:46] <cnd> alright, grail only has one real bug that is low
[20:46] <cnd> dandrader, btw, remember to leave the release as UNRELEASED
[20:47] <cnd> when committing entries in the debian/changelog
[20:59] <cnd> hmm, network is down here
[21:01] <cnd> the network died here
[21:01] <cnd> did I miss anything?
[21:33] <cnd> dandrader, how's it going?
[21:33] <dandrader> cnd, getting there
[21:33] <cnd> ok
[21:33] <cnd> I was afraid I never really reconnected :)
[21:34] <dandrader> crap. clicked on the wrong button
[21:35] <cnd> heh
[22:15] <cnd> urgh, I think the "Warning: failed to get previous touch value" bug has a root cause in mtdev
[22:16] <cnd> dandrader, you sure things are going ok? :)
[22:16] <dandrader> cnd, hehehhehe. yes. every time some missing bit and I have to rollback and commit again
[22:17] <cnd> heh
[22:23] <dandrader> source package looks good. now running pbuilder
[22:29] <cnd> cool
[22:31] <cnd> nope, I think the warning is due to a bug in xserver-xorg-input-synaptics
[22:33] <dandrader> what warning?
[22:33] <dandrader> anyway, pushed stuff to lp:utouch-grail/ubuntu
[22:33] <dandrader> cnd, ^
[22:34] <cnd> you might see the warning in ~/.xsession-errors
[22:34] <cnd> or when running any of our command line tools
[22:34] <cnd> when using the magic trackpad
[22:34] <dandrader> cnd,  I think the next step now is dput? so you will take it from here
[22:35] <dandrader> ?
[22:35] <cnd> yeah, review, sign, and upload :)
[22:35] <cnd> I'm checking it out now
[22:36] <dandrader> ok. I'm done for today. have a nice weekend!
[23:33] <cnd> bregma, are we releasing geis today?
[23:34]  * cnd guesses no...
[23:36] <bregma> I don't think so
[23:36] <bregma> not until I get all the tests to pass on my machine
[23:37] <bregma> there appears to be some sort of refcounting problem that sometimes causes the backend not to get properly deleted, which means the X connection does not get closed
[23:38] <bregma> I think I have it fixed, and it just moves somewhere else
[23:39] <bregma> typical