bregmacnd, 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:02
cndbregma, the probably need to be specified manually in LIBADD or LDADD00:03
cndare they?00:03
bregmayou 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:04
cndI don't know, but specifying a dependency of another library that you built yourself doesn't make sense to me00:07
cndsorry, it makes sense to me00:08
cndwhen using the Makefile-xorg-gtest.am from xorg-gtest, it adds -lpthread to XORG_GTEST_LIBS00:08
bregmawhy isn't that symbol defined in the xorg-gtest autoconf macro, they way it is for pretty much everything else under the sun?00:09
cndbregma, perhaps it should00:20
bregmais there any reason I shouldn;t upload utouch-evemu at this point?00:31
cndbregma, nope :)00:36
cndthe issue I was thinking about yesterday, device props, has been implemented since forever00:37
cndI just didn't realize it :)00:37
cndthere are no outstanding bugs, so have at it00:37
bregmadone, one down00:45
cndbregma, MPs out: https://code.launchpad.net/~chasedouglas/utouch-geis/ungrab-test/+merge/100060 https://code.launchpad.net/~chasedouglas/utouch-geis/fix-ungrab/+merge/10006100:46
cndbregma, what do you think about a geis release? should we wait for dandrader's fixes?00:53
cndhe seems somewhat close, but they are also merely refinements00:53
cndsince we currently have a broken geis in precise00:53
cndit's kinda late today anyway though...00:53
cndI suppose we might as well wait till tomorrow00:54
bregmadoesn't his MR do the entire fix?00:56
bregmaeither way, I want his fix in if possible, and tomorrow is as good a day as any00:57
bregmawhat about frame and grail?  are they ready for release?00:59
cndbregma, frame has one minor bug that hasn't been worked on yet, not a blocker01:01
cndgrail is ready01:01
cndbregma, oh, I didn't see dandrader's MP :)01:02
bregmait's just so exciting to get new releases out, it's just like Christmas01:03
bregmaI intend to go over dandrader's fix tomorrow, it's getting late here01:03
cndbregma, np, though I might get to it tonight :)01:10
cndor how about right now :)01:10
cndbregma, I wouldn't worry about reviewing dandrader's branch tonight01:25
cndit needs a fix before it's ready to be merged01:25
cndI see we reviewed simultaneously :)01:29
bregmaanother 15-hour day, time to walk away from the computer01:53
bregma(not a continuous 15 hours, I'm not an addict)01:55
=== MacSlow is now known as MacSlow|lunch
=== tvoss|eod is now known as tvoss
Satorisbregma: 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:07
=== MacSlow|lunch is now known as MacSlow
bregmaSatoris, is this from an installed package or is it in the build directory?12:45
SatorisBuild directory.12:45
SatorisIn-source build.12:45
bregmaI 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 all12:47
SatorisSo effectively bzr branch, cd, autogen, configure, make, cd python, ./run_pygeis12:47
SatorisBut shouldn't SYNCHRONOUS be in the system tree also, because I have the daily build PPA.12:48
SatorisAnd inded, running pygeis from /usr/bin fails also.12:48
SatorisShould I file a bug on this?12:51
bregmayes, there's a line missing from python/geis/__init__.py12:52
SatorisI see it. But after fixing that I get a different error.12:56
bregmaAttributeError: 'NoneType' object has no attribute 'activate' ?12:57
bregmathat looks like a bug in pygeis itself, it explicitly passes None to a fucntion and calls .zctivate() on it12:59
bregmadunny what the developer was thinking there13:00
bregmaI think that tool may need to be rewritten13:01
SatorisIs there an other way to test the Python bindings?13:02
bregmageisview should work, it's the main python tool13:04
bregmaonly 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 script13:05
SatorisThere does not seem to be one.13:08
cndbregma, tvoss, Satoris: standups!14:14
cndI'll be working on releases for much of the day I think14:15
tvosschromium gyp fun, restored geis green on jenkins14:15
cndthen looking through any and all bugs I can figure out14:15
tvossrefactored parts of the patch to ease testing14:15
bregmawhat's the status on frame and grail releases?14:15
SatorisFound critical bug in launchpadlib, bug fixes and code cleanup.14:16
cndbregma, they just need to be done14:16
cndbregma, geis in jenkins has one failure14:17
bregmaI'm waiting for dandrader's fix to get in before making a geis release14:17
Satorisbregma: will merge the Python fix in a few seconds.14:17
cndbregma, I'm not sure what's wrong with it off the top of my head14:18
bregmaI can reproduce the tap count failure locally14:18
bregmaI'll take a look and see if I can spot anything14:18
tvossbregma, if it helps: it only happens on amd6414:19
cndtvoss, no it happens on i386 too14:20
cndbregma, tvoss, Satoris: I'm leaving for a couple hours14:20
tvosscnd, ack14:20
cndwill be back, in an undisclosed location, soon :)14:20
bregmaI plan to take the week end off this week14:20
bregmain the mean time, if we're asked, we will neither confirm nor deny knowledge of your whereabouts14:23
Satoriscnd: did not put the script in Helipad or Arsenal due to the bug and confusion on what will happen to those projects.14:24
bregmatvoss, 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
tvossbregma, fix is pending, I can have it in like next week14:26
bregmaI 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 release14:30
tvossbregma, that would be great14:30
bregmautouch-frame has no outstanding bugs targeted, it should go out today, too14:30
=== tvoss is now known as tvoss|dinner
cndtvoss|dinner, bregma: I'm back16:25
cndthe portland posse is having a knitting session at the OSU open source labs16:26
bregmado you knit?16:26
cndknitting is a euphemism :)16:27
bregmanot to my wife16:29
bregmaknitting is a religion16:29
cnddandrader, do you have a fix for xsync alarms in the utouch-grail tools?16:49
cndif not, I'll try to whip one up16:49
dandradercnd, 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 so16:51
dandraders/own my/on my16:51
bregmadang, I just realized I booked the wrong return date for UDS16:58
bregmaI booked a return flight on Thursday instead of Saturday16:59
bregmatere are no convenient flights Saturday anyway, since BART doesn't start running until 06:0016:59
cndthat sucks17:01
bregmaevidently if you want to leave the Bay Area during daylight hours and head east you are out of luck17:02
cndthat seems odd17:04
cndbregma, I'm leaving friday late morning to go to indian17:04
cndactually, it's early afternoon17:05
cnd1:06 PM17:05
cndSLC->IND at 5:02 MDT17:06
cnddandrader, bregma, I approved the xsync MP17:06
cnddandrader, is it necessary to delete the alarm?17:09
cndI guess I'll find out17:09
dandradercnd,  if not you will get an endless streams of alarm events from the time your timeout has been reached17:09
cnddandrader, oh wait17:17
cndyou forgot an XFlush after creating the alarm17:17
dandradercnd, hmm, what its absence can cause?17:18
cndthe request would be put into the Xlib queue17:18
cndbut it might not be sent to the server17:18
cndso in effect, the alarm may be set now, or any time in the future17:18
cndincluding after it was supposed to fire :)17:18
cndso a tap may not be recognized properly17:19
dandraderit has already been merged. Should I make a new proposal with this addition?17:20
cnddandrader, just commit it on top17:20
cndand reference that it was missed in the MP17:20
cndbregma, any luck on that geis test?17:22
bregmanot yet17:23
cndbregma, you haven't released grail yet, have you?17:24
cndI'm going to fix the tools for the xsync alarm stuff17:24
cndnope, doesn't look like it17:25
bregmaall I did with grail was fix the failed daily build17:27
=== dandrader is now known as dandrader|afk
bregmabah, I can't get the tap_touch_count test failure to happen locally any more17:40
=== dandrader|afk is now known as dandrader
bregmawhoops, got it again, it's very transient17:46
cnddandrader, I think the positivetransition test is just broken in the server18:02
cndand I just don't feel like maintaining a list of alarms18:02
cndso I'm going to try fixing it instead :)18:02
dandradercnd, you're my hero :)18:02
cnddandrader, would we still have to delete the alarm?18:05
cndor do you think it would just disappear?18:05
* cnd digs into the source18:05
dandradercnd, I would think you have to delete in any case18:06
cnddandrader, interesting, embedded in the sync implementation is a coment and if statement that we can use18:16
cndor not18:16
cndit didn't do what I thought it would :)18:16
cndabout to install my debug xserver build though18:16
cndwe'll find out18:16
cnddandrader, aha!18:29
cndnotice that I set the delta to 0 and used XSyncCADelta when creating the alarm18:30
cndif the delta is 0, the alarm will only fire once18:30
cndand then there's XSyncChangeAlarm18:31
cndso we can have one alarm per grail instance18:31
cndand just keep changing it as needed18:31
dandraderwhat if you need more than one timeout to be set simultaneously (ie. one at X+123 and another at X+345)18:32
dandraderI mean, I you want to set a new timeout before the current one timed out18:33
cnddandrader, you could have two alarms, but when would you need two alarms for one grail instance?18:33
cndif you need to set a new timeout that is later than the current one, then just change it18:33
dandraderso you don't need to update grail state at both moments, X+Y and X+Z? Only at X+Z?18:34
dandraderah, then that simplifies things18:35
cndwhatever grail says *now* is all that matters18:35
dandraderI didn't make that assumption18:35
cndadmittedly, the xsync implementation didn't work quite like that18:35
cndI'm trying to fix up the grail test case right now18:35
cndto ensure it all works properly18:35
dandradercnd,  by the way: what the heck this delta means (in XSyncAlarmAttributes)?18:37
dandradernow that you've been enlightened by reading the source code :)18:38
cnddandrader, apparently, it determines the *next* timeout after the alarm fires18:38
cndit defaults to 118:38
cndso that's why the alarm continuously fires18:38
cndI think we should be using PositiveTransition, but it doesn't work18:38
cndbut PositiveComparison + delta = 0 is good enough18:38
dandraderwhat a strange API...18:40
cndsadly, I only have my netbook with me18:46
cndmuch slower than behemoth...18:46
cnddandrader, http://paste.ubuntu.com/907686/18:49
cndit includes a fix where the grail test was still querying the server time instead of using the alarm notify event18:50
bregmait 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 closed18:56
cndbregma, hmm... interesting19:03
cndbregma, do we need to flush the uinput writes?19:04
bregmaI 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 down19:11
bregmaexcept when it works19:11
bregmaah, no, I think the server can;t open /dev/event/input19 (EBUSY), and gives a "PreInit returned 11" and ignores the device19:16
cndbregma, that's likely because another X server has grabbed it19:17
cndbregma, there's two remedies:19:18
cnd1. run your tests in a VT19:18
cnd2. install the xorg-gtest from git master which includes an X snippet to *not* grab virtual test devices19:18
cndand then restart your X server19:18
cndand ensure the test device has "Virtual Test Device" somewhere in its name19:18
cnddandrader, MP for grail: https://code.launchpad.net/~chasedouglas/utouch-grail/xsync-alarm/+merge/10022619:19
cnddandrader, would you be interested in releasing and creating an upload for grail after that's merged?19:19
dandradercnd, sure19:20
cndbiab, going to get lunch19:20
cnddandrader, ok, lets make a release of grail20:12
cndI've started tracking bugs better, following bregma's lead :)20:12
cndso let's start by looking at the open grail bugs20:12
cndeverything that is Fix Committed should be milestoned for 3.0.420:14
dandradernine in total20:15
cndhmmm... wish I could search for unmilestoned bugs20:15
dandraderok, they all have their milesone correctly set20:16
cndand every other bug should be sane20:17
cndoops, I need to mark the xsync alarm bug as fix committed20:18
cndok, looks good20:18
cnddandrader, now, we can make a release20:18
cndI fixed make distcheck (yay), so checkout trunk, configure it, then run sudo make distcheck20:19
cndprobably on a VT unless you have the xorg-gtest snippet installed20:19
cndcause it will attempt to run the tests20:19
cndhopefully they all pass and it generates the tarballs20:20
cndthen release it upstream on lp :)20:20
cndlet me know when you're done20:21
dandradercnd, release done. now for the package?20:41
cnddandrader, now we have to move all the bugs to fix released20:41
cndfor the upstream package20:41
cndI'll start from the bottom of the bug list20:41
dandradercnd, so you will change that statuses yourself or I do it?20:42
cndI can fix them20:42
cndyou can start the packaging20:42
cndwhen you run bzr mu, before committing we need to add all the utouch-grail (ubuntu) bugs fixed to the changelog20:43
cndalright, grail only has one real bug that is low20:46
cnddandrader, btw, remember to leave the release as UNRELEASED20:46
cndwhen committing entries in the debian/changelog20:47
cndhmm, network is down here20:59
cndthe network died here21:01
cnddid I miss anything?21:01
cnddandrader, how's it going?21:33
dandradercnd, getting there21:33
cndI was afraid I never really reconnected :)21:33
dandradercrap. clicked on the wrong button21:34
cndurgh, I think the "Warning: failed to get previous touch value" bug has a root cause in mtdev22:15
cnddandrader, you sure things are going ok? :)22:16
dandradercnd, hehehhehe. yes. every time some missing bit and I have to rollback and commit again22:16
dandradersource package looks good. now running pbuilder22:23
cndnope, I think the warning is due to a bug in xserver-xorg-input-synaptics22:31
dandraderwhat warning?22:33
dandraderanyway, pushed stuff to lp:utouch-grail/ubuntu22:33
dandradercnd, ^22:33
cndyou might see the warning in ~/.xsession-errors22:34
cndor when running any of our command line tools22:34
cndwhen using the magic trackpad22:34
dandradercnd,  I think the next step now is dput? so you will take it from here22:34
cndyeah, review, sign, and upload :)22:35
cndI'm checking it out now22:35
dandraderok. I'm done for today. have a nice weekend!22:36
cndbregma, are we releasing geis today?23:33
* cnd guesses no...23:34
bregmaI don't think so23:36
bregmanot until I get all the tests to pass on my machine23:36
bregmathere 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 closed23:37
bregmaI think I have it fixed, and it just moves somewhere else23:38

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!