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