| Satoris | Thanks to autogarbage, building Grail even without tests requires xorg-gtest. | 12:43 |
|---|---|---|
| Satoris | Which is why the packaging is failing. | 12:43 |
| Satoris | The daily builds run autoreconf. | 12:44 |
| bregma | Satoris, autoreconf is not the problem, the problem is the way daily builds build only native packages | 12:54 |
| bregma | just found this: http://reports.qa.ubuntu.com/reports/utouch/utouch-recent-bug-tasks.html | 12:54 |
| Satoris | Well the error message is "configure.ac:39: error: possibly undefined macro: AC_MSG_WARN" | 12:55 |
| Satoris | Which comes from the xorg-gtest package. | 12:56 |
| Satoris | Which is not a build-dependency. | 12:56 |
| Satoris | And tests are not run during packaging. And could not be, because Grail tests require root. | 13:07 |
| === MacSlow is now known as MacSlow|lunch | ||
| bregma | I am familiar with the error, it's because the daily builds build a native package, which means from a VCS checkout, which means it needs everything to prepare the final build environment | 13:18 |
| Satoris | Which is done by running dh_autoreconf. | 13:19 |
| bregma | yes, and the C compiler, and so on | 13:20 |
| bregma | dh_autoreconf is run in the builds used in Ubuntu, but the build source packages, not VCS checkouts | 13:20 |
| bregma | source packages do not need the developer's infrastructure, they only need the build requirements | 13:21 |
| Satoris | Unless you distro patch the build system in any way. | 13:21 |
| bregma | unless you're using cmake, in which case the developer's infrastructure is required everywhere | 13:21 |
| Satoris | Yes. | 13:22 |
| bregma | no, I distro patch utouch-geis, and I run run dh_autoreconf, and it works just fine | 13:22 |
| bregma | the way daily builds work is a hack, and sometimes hacks fail | 13:23 |
| bregma | this is one of those times | 13:23 |
| bregma | rge correct solution would be to have a source package build phase, and have daily builds work the same way distro builds work, otherwise you;re not testing what you ship | 13:23 |
| bregma | s/rge/the/ | 13:23 |
| Satoris | Or not have a build system that requires a source package build phase. | 13:24 |
| Satoris | If your source releases are in any way different from a VCS checkout with the same tag, you have already failed. | 13:25 |
| Satoris | If this requires checking generated stuff into VCS, you have doubly failed. | 13:25 |
| bregma | I strongly disagree: source packages can differ greatly from what's in the upstream VCS and often do | 13:26 |
| Satoris | They do. I consider this a bug. | 13:26 |
| bregma | that's why we have completely separate VCS for packaging | 13:27 |
| Satoris | Which is a symptom of this bug. | 13:27 |
| bregma | the distro builds require Debian source packages, if we're testing something that is not the same as what goes into a distro build we're completely wasting our time | 13:27 |
| Satoris | That is not the problem. | 13:28 |
| bregma | you can have your gentoo or arch linux if you want, but Ubuntu is Debian-based | 13:28 |
| Satoris | Requiring source packages is good. | 13:28 |
| bregma | and yes, the whole problem stems from the fact that we build something that is not what we ship | 13:28 |
| Satoris | Yes. | 13:29 |
| bregma | separation of upstream projects from distributions is a good thing | 13:29 |
| Satoris | Which is caused by autogarbage and its generated script files. | 13:29 |
| Satoris | Yes. | 13:29 |
| Satoris | In 1993 or thereabouts the generated shell script thing made sense because it was the only thing that could work across then-common systems. | 13:31 |
| bregma | the fact that daily builds do not build what we ship is not a result of the tools used by those builds, but of the architecture of the daily build technology | 13:31 |
| Satoris | Nowadays it makes no sense at all. Unless you are glibc or something. | 13:31 |
| bregma | it is the same problem regardless of what tools you use to build your software | 13:32 |
| Satoris | No, the architecture of the build tools. If we shipped 1:1 what we have in VCS, there would be no difference in the build types. | 13:32 |
| Satoris | But autofoo makes it impossible. | 13:33 |
| Satoris | I have run a project where releasing software was literally a case of 'bzr tag 0.0; bzr push; rm -rf .bzr .bzrignore; cd ..; tar xaf foo.version foodir". | 13:35 |
| Satoris | I mean 'tar xaf' but you get the point. | 13:35 |
| Satoris | Grr, 'tar caf'. | 13:36 |
| bregma | that would require using only native packages, which would mean giving up getting our software into Debian, for example | 13:43 |
| Satoris | Why would it? You would have the actual packages as well as the daily build just like now. The only difference would be that the build steps would be the same for both build types. | 13:45 |
| bregma | the fact that the daily builds do not build from source packages, and the distro build build only from source packages, means the daily builds do not build what we ship in the distro regardless of a project's use of autotools, cmake, or native perl | 13:45 |
| bregma | building from VCS is a native package ... Debian will not accept native packages, plain and simple | 13:46 |
| Satoris | That's not what I meant. The debian subdirectory would live in its own branch, just like now. | 13:46 |
| bregma | ah, so the daily build would not build from a source package and we would build and test something different from what we ship | 13:47 |
| Satoris | But currently for daily builds, you must first run autoreconf or generate the configure script in some other way. This step would go away. | 13:47 |
| Satoris | debian/rules would be identical for source packages and for daily builds. Currently they are different, which is some of where the pain comes from. | 13:49 |
| Satoris | s/source packages/source release tarballs/ | 13:50 |
| Satoris | dandrader: the memory loss comes from doing baseclass *foo = new DerivedClass; delete baseclass; | 13:52 |
| Satoris | Argh, I meant "delete foo". | 13:52 |
| Satoris | Apparently I can't type today. | 13:52 |
| dandrader | ok | 13:56 |
| === MacSlow|lunch is now known as MacSlow | ||
| cnd | Satoris, thanks for the test recordings path fix! | 14:29 |
| cnd | that gets us one step closer to make distcheck working | 14:30 |
| Satoris | I had already fixed it once in a abandoned grail-glue branch. | 14:31 |
| cnd | ahh | 14:31 |
| Satoris | So it was quite straightforward. | 14:31 |
| dandrader | do we need a bug report for something as simple as this: https://code.launchpad.net/~dandrader/utouch-grail/const_kcomptime/+merge/99031 | 14:32 |
| cnd | dandrader, nah | 14:32 |
| Satoris | A world of no. | 14:32 |
| dandrader | good :) | 14:33 |
| Satoris | We are not IBM. Thank god. | 14:33 |
| cnd | dandrader, I just realized I had remembered the kCompositionTime issue wrong | 14:35 |
| cnd | I was thinking you had added it to atomic-recognizer.cpp for some reason | 14:35 |
| cnd | I was confused I guess | 14:35 |
| dandrader | cnd, working too much :) | 14:36 |
| cnd | heh, yeah... | 14:36 |
| cnd | dandrader, you'll want to use geis with the fix I proposed last night | 14:37 |
| cnd | when you test unity | 14:37 |
| cnd | the stack is rather broken without the fix | 14:37 |
| dandrader | about your email to systems. that was quite true for me. yesterday I was thinking what I could be working on while you were fixing the stack. as I couldn't make any progress on unity without those fixes and you were doing them yourself | 14:39 |
| dandrader | so I started digressing about timeouts | 14:39 |
| bregma | cnd, should we remove v2 from grail builds and v1 from frame builds before RC? I do not believe they're used, and it would mean utouch-evemu does not need relicensing. | 14:48 |
| cnd | bregma, I'd rather relicense evemu | 14:50 |
| cnd | removing those would be a big change | 14:51 |
| cnd | and though I can't see why it would affect things | 14:51 |
| cnd | we don't have any more releases after beta 2 before the final release | 14:51 |
| cnd | there's no RC release | 14:51 |
| bregma | I agree it would be a big change, it would be the right thing to do technically, but the wrong thing to do from a procedural point of view at this point in the release cycle | 14:53 |
| bregma | so, I'll just relicense evemu | 14:53 |
| cnd | bregma, my thoughts were to leave the old stuff for a cycle so we can pull them out and see how they worked previously | 14:55 |
| cnd | but I've never done it because it would require having an oneiric or early machine available | 14:55 |
| cnd | which I don't have :( | 14:55 |
| tvoss | working on trackpad-recognizer, reorganizing jobs on jenkins | 15:14 |
| dandrader | working on "[Systems-team] Grail fixes". Right now looking at the "1. AtomicRecognizer::FindGestureToAccept()" issue | 15:16 |
| bregma | reviewing merges :) | 15:16 |
| bregma | %} | 15:17 |
| cnd | working on touch state accounting in grail | 15:18 |
| cnd | to try to fix remaining unity gestures issues | 15:18 |
| cnd | Satoris, stand-ups :) | 15:18 |
| bregma | also, grooming the utouch sources to convert to LGPLv3, which is critical before 12.04 release (do mot mess with lawyers) | 15:19 |
| Satoris | Bugs. | 15:19 |
| dandrader | cnd, about the AtomicRecognizer::FindGestureToAccept() issue. Is it possible to happen? I.e. can a touch have a start time timestamp greater than the timestamp of the event that is being processed? | 15:29 |
| Satoris | If they are using different clocks, yes. But I don't think that's very common. :) | 15:32 |
| dandrader | but if they are using different clocks I suppose their timestamps are not comparable | 15:36 |
| Satoris | That was more theoretical imagining. | 15:36 |
| cnd | dandrader, it's possible | 15:55 |
| cnd | I assume you saw it, and that's why you had the check for delta_time > 0 | 15:55 |
| cnd | dandrader, the issue lies in how the X server generates ownership events | 15:55 |
| cnd | often you will see a touch ownership event that has a timestamp 1 ms earlier than the touch begin | 15:56 |
| dandrader | hmm, ok | 15:58 |
| === dandrader is now known as dandrader|lunch | ||
| cnd | dandrader, so that begs the question, why did you add the check for delta_time > 0? | 15:59 |
| cnd | I don't remember that being part of the original recognizer code, but maybe I'm mistaken | 15:59 |
| cnd | argh, there's a bug in X synaptics that fires tap actions after multitouch taps | 16:50 |
| cnd | which is why the dash sometimes flashes when you do a four touch tap instead of staying visible | 16:51 |
| === dandrader|lunch is now known as dandrader | ||
| dandrader | cnd, back to the delta_time question: it was part of the original code. I just created a variable to hold that value instead of doing the computation directly inside the if() expression | 17:12 |
| dandrader | at least that's what I recall | 17:12 |
| cnd | ahh | 17:12 |
| cnd | then I probably saw it :) | 17:12 |
| cnd | way back | 17:12 |
| dandrader | then if it comes again what will happen is a premature acceptance of a gesture | 17:13 |
| dandrader | which is a rather mild effect | 17:13 |
| cnd | yeah | 17:13 |
| dandrader | bregma, can I merge this small documentation addition? https://code.launchpad.net/~dandrader/utouch-geis/doc_filter_ownership/+merge/98913 | 17:21 |
| cnd | I think I found the fix for the X synaptics tapping bug | 17:22 |
| cnd | \o/ | 17:27 |
| cnd | tap to show the dash works perfectly now :) | 17:28 |
| dandrader | great! | 17:31 |
| cnd | though I'm using my grail branch with reworked touch accounting | 17:32 |
| cnd | just fyi | 17:32 |
| bregma | dandrafer, I wanter to verify it's true first, as opposed to just seems to be true | 17:34 |
| bregma | hey folks, I have to run and see someone about some livestock, back in a bit | 17:41 |
| cnd | livestock... | 17:42 |
| cnd | that's very vague... what type of livestock? | 17:42 |
| cnd | buffaloes? | 17:42 |
| cnd | yaks? | 17:42 |
| cnd | emus? | 17:42 |
| * cnd tries to envision bregma the farmer | 17:43 | |
| dandrader | :) | 17:47 |
| cnd | ok, synaptics is dealt with | 18:24 |
| cnd | now back to grail/unity | 18:24 |
| cnd | next on my list: drag to show/hide the dock | 18:24 |
| dandrader | you mean, the launcher | 18:27 |
| dandrader | cnd, In order to test the "1. AtomicRecognizer::FindGestureToAccept()" issue I believe would have to mock utouch-frame so that I can send a synthesized event containing a touch that has a start time bigger than the event time itself. Do you think it's worth the effort? | 18:28 |
| cnd | dandrader, yeah, the launcher :), no, a test for that issue would be too time consuming for little benefit | 18:28 |
| cnd | I'm not even sure I can reproduce the issue | 18:29 |
| dandrader | where can I find the documentation of XInput2.h API (or is it all in the header itself)? | 18:29 |
| cnd | it's just a bug I saw and it should be corrected | 18:29 |
| cnd | dandrader, there are two pieces to XInput: the protocol specification, and the libXi library implementation | 18:30 |
| cnd | libXi is only documented through man pages and header files | 18:30 |
| cnd | the protocol is documented in /usr/share/doc/x11-proto-input/XI2proto.{html,txt.gz} | 18:31 |
| cnd | if your question is about behavior, then the proto docs are what you need | 18:32 |
| dandrader | cool | 18:32 |
| cnd | if the question is about function names and args and such | 18:32 |
| cnd | then you want the libxi man pages | 18:32 |
| cnd | of which some are missing, like XIGrabTouchBegin :( | 18:32 |
| cnd | dandrader, so the launcher hiding does not seem to be a utouch issue | 18:44 |
| cnd | data is coming through just fine | 18:44 |
| dandrader | cnd, would you mind trying my branch? | 18:45 |
| dandrader | of unity | 18:46 |
| cnd | dandrader, oh, right | 18:46 |
| cnd | yes! | 18:46 |
| cnd | where is it? | 18:46 |
| * dandrader searches for it | 18:46 | |
| dandrader | cnd, lp:~dandrader/unity/geisv2/ | 18:46 |
| cnd | dandrader, what about the geisv1 branch? | 18:47 |
| cnd | I'm interested to see if my grail changes + your geis v1 branch make things work | 18:47 |
| dandrader | cnd, lp:~dandrader/unity/lp940612 | 18:48 |
| dandrader | that has the fix for the 3-touches window drag | 18:48 |
| cnd | ok, I'll try that first | 18:48 |
| cnd | I really want to get the unity gestures as they are today working | 18:48 |
| cnd | we're getting very close to release... | 18:48 |
| cnd | dandrader, I'm getting: | 18:54 |
| cnd | /home/cndougla/Canonical/x/ubuntu/unity/lp940612/plugins/unityshell/src/DebugDBusInterface.cpp: In function ‘void unity::debug::ResetLogging()’: | 18:54 |
| cnd | /home/cndougla/Canonical/x/ubuntu/unity/lp940612/plugins/unityshell/src/DebugDBusInterface.cpp:251:3: error: ‘reset_logging’ is not a member of ‘nux::logging’ | 18:54 |
| cnd | from lp940612 | 18:54 |
| cnd | any ideas? | 18:54 |
| cnd | maybe my nux is out of date/ | 18:54 |
| cnd | ? | 18:54 |
| dandrader | cnd, that's very likely the case | 18:55 |
| dandrader | sometimes you need trunk version of compiz-core as well | 18:55 |
| cnd | ugh... | 18:55 |
| === gustavold1 is now known as gustavold | ||
| dandrader | one option would be to apt-get source unity and applying that patch on top. | 18:56 |
| cnd | looks like I can install nux from precise-proposed | 18:57 |
| cnd | ok, got it built | 19:09 |
| cnd | argh, it just crashes... | 19:10 |
| cnd | I'll do a dist upgrade | 19:10 |
| cnd | maybe there's some abi change that hasn't been taken care of | 19:11 |
| bregma | I'm back, and a few hundred dollars poorer | 19:22 |
| cnd | bregma, what did you buy? | 19:34 |
| cnd | we've been waiting on pins and needles :) | 19:34 |
| cnd | dandrader, finally got unity running again | 19:34 |
| dandrader | so... does it work? | 19:35 |
| cnd | dandrader, dash still works :) | 19:36 |
| cnd | but nothing three fingers works... | 19:36 |
| cnd | and 4 finger drag still doesn't work | 19:36 |
| === dandrader is now known as dandrader|afk | ||
| cnd | I'm going to get some lunch, and then do some more unity debugging | 19:40 |
| === dandrader|afk is now known as dandrader | ||
| cnd | dandrader, looks like the focus coords aren't right | 20:24 |
| cnd | and that's why three touch stuff isn't working for me | 20:24 |
| cnd | digging deeper... | 20:24 |
| dandrader | funny that it only happens with geisv1 api... | 20:25 |
| cnd | dandrader, oh! | 20:25 |
| cnd | then it's likely a simple bug in geis | 20:25 |
| dandrader | I told you the refactored unity that used geisv2 works fine | 20:25 |
| dandrader | s/used/uses | 20:25 |
| cnd | yeah, but I didn't know exactly what part was broken | 20:26 |
| cnd | if it's just focus coord position, that's likely a trivial bug | 20:26 |
| cnd | hopefully :) | 20:26 |
| dandrader | fingers crossed :) | 20:27 |
| * cnd goes to build a debug version of geis | 20:28 | |
| cnd | dandrader, btw, the unity changes you have only work for indirect devices | 20:28 |
| cnd | we have to check all the touch locations for direct devices | 20:29 |
| dandrader | it will work but won't be as precise/strict as checking all touches | 20:31 |
| cnd | yes, but we need it to be strict | 20:31 |
| dandrader | yes, it's better | 20:32 |
| dandrader | I'll do that after I'm finished with those small bugs from your e-mail | 20:34 |
| cnd | hah, it's a really simple bug in unit | 20:37 |
| cnd | unity | 20:37 |
| cnd | result->focus_x = attr.integer_val; | 20:37 |
| cnd | the attr is a float | 20:37 |
| cnd | so it needs to be: | 20:37 |
| cnd | result->focus_x = attr.float_val; | 20:37 |
| cnd | yay, it works | 20:41 |
| cnd | sorta | 20:41 |
| cnd | I'm guessing the pointer is warped around | 20:41 |
| cnd | so it feels very different | 20:41 |
| cnd | I think it's always been that way | 20:41 |
| cnd | I don't know how easily we can reproduce what the X server does for pointer motion | 20:42 |
| cnd | dandrader, do you want to fold that float value fix into your branch? | 21:07 |
| dandrader | what fix? | 21:08 |
| cnd | result->focus_x = attr.integer_val; | 21:09 |
| cnd | needs to be: | 21:09 |
| cnd | result->focus_x = attr.float_val; | 21:09 |
| cnd | dandrader, ^^ | 21:10 |
| cnd | in GeisAdapter.cpp | 21:10 |
| dandrader | ah, cool | 21:12 |
| dandrader | yes, I will add that fix to my branches. thanks | 21:15 |
| dandrader | cnd, btw, do you have that fix anywhere I could cherrypick? | 21:16 |
| cnd | one sec | 21:16 |
| cnd | I can paste a patch | 21:16 |
| cnd | dandrader, http://paste.ubuntu.com/896995/ | 21:17 |
| dandrader | and the header accordingly. yes, it's pretty straight forward | 21:19 |
| cnd | dandrader, the commit header? | 21:20 |
| cnd | I haven't committed it :) | 21:20 |
| cnd | it's just lying around in my tree | 21:20 |
| dandrader | no, I just meant that GeisAdapter.h has to be changed accordingly | 21:21 |
| cnd | does it? | 21:21 |
| cnd | oh right | 21:21 |
| cnd | yeah | 21:21 |
| cnd | I didn't think about it | 21:21 |
| cnd | good call :) | 21:21 |
| * cnd is feeling very productive today | 21:22 | |
| cnd | bregma, did you find a sane way to make the daily builds work? | 21:22 |
| cnd | I feel like tackling them | 21:22 |
| dandrader | cnd, but that's not the cause of the bug since my geisv2 branch also has this mistake | 21:23 |
| cnd | dandrader, you probably are seeing bugs due to the other issues in the email I sent and the touch accounting issue | 21:24 |
| cnd | we'll get through them :) | 21:24 |
| dandrader | alright :) | 21:24 |
| cnd | it's working fine here | 21:24 |
| cnd | bregma, I'm thinking of the following: | 21:24 |
| cnd | add a build dep of libxorg-gtest-dev to the packaging | 21:25 |
| cnd | but add a configure option to disable the testing | 21:25 |
| cnd | and use the option when building packages | 21:25 |
| cnd | bregma, are you going to release evemu into precise? | 21:52 |
| cnd | I just noticed you have released evemu upstream | 21:52 |
| cnd | I thought I'd warn you that we're under beta 2 freeze in case you weren't aware | 21:53 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!