=== MacSlow is now known as MacSlow|lunch === MacSlow|lunch is now known as MacSlow [13:57] Hey guys - I think I have utouch installed, how can I confirm it is working? [13:59] elijah, https://wiki.ubuntu.com/Multitouch/Testing [14:00] more specifically https://wiki.ubuntu.com/Multitouch/Testing/UsingMtview [14:01] and then https://wiki.ubuntu.com/Multitouch/Testing/UsingGeisview [14:02] dandrader: thanks a bunch [14:16] status report: I'm updating the merge proposal with the fix for bug 978378 according to comments received [14:16] Launchpad bug 978378 in unity (Ubuntu) "A window can be moved even when some fingers are not over it" [Low,In progress] https://launchpad.net/bugs/978378 [14:17] cnd, bregma, Satoris, tvoss, stand up meeting [14:17] morning all [14:17] thanks dandrader :) [14:17] Preparation for UDS demo. [14:17] morning [14:17] I'm going to merge in the utouch-qml fixes and hopefully release them upstream and get them uploaded as either a fix in the release or an SRU [14:17] then back to architecture documentation [14:18] I did some reviews, catching up on correspondence, trying to get ALL the geis integration tests to pass ALL the time [14:33] porting the chromium patch, frame backend work [14:41] cnd: probably [14:41] Skype today. [14:41] ok === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [15:49] bregma, what's the debhelper debug env var? [15:49] to spit out more verbosity while dh builds a package? [15:49] DH_VERBOSE ? [15:50] set it to 1 [15:50] ok [15:51] I also often end up running dh manually from the command line with --verbose to see what it's doing (it gives different output) [15:51] hmm [15:51] I'm building a new utouch-qml package [15:51] but DH_VERBOSE=1 in the debian/rules file is easier to start with [15:51] and it's not stripping the library in dh_strip [15:52] odd [15:56] argh [15:56] I have a DEB_BUILD_OPTIONS="noopt nostrip noudeb nocheck parallel=16" in my env :) [15:56] for xorg-server builds [15:57] that'll do it [16:09] I wish bzr had a useful working rebase, I have a case where it would just be the right tool for the job === tvoss is now known as tvoss|dinner === dandrader is now known as dandrader|lunch [16:55] bregma, I assume you mean an interactive rebase? [16:55] there is bzr rebase [16:59] I have that installed but last I looked at it it wasn't a true rebase, might be worth playing with though [17:11] yep, does exactly what I need, thanks === dandrader|lunch is now known as dandrader [18:01] cnd, testsuite/recordings/touchscreen_a/pinch_2.record seems to be missing fro geis (from your recent gtest_attrs.cpp change) [18:01] hmm... [18:01] I probably forgot to bzr add it [18:02] yep [18:02] I'll commit it [18:03] bregma, committed [18:06] dandrader, it looks like you're basically rebasing all your work when you update a merge proposal [18:07] that basically breaks how lp reviews are supposed to work :) [18:07] and makes it not any better than making a new MP [18:07] instead, you can make changes as new commits [18:07] then it's easier for us to figure out how things really changed [18:09] cnd, and the idea is to organize the commits only after the whole thing gets accepted or to merge the resulting mess as it is? [18:09] merge the mess [18:10] that's the bzr+lp way of doing things [18:10] if you want to keep distinct changes separate [18:10] then you can look into bzr pipeline [18:10] for example, each of your commits in this proposal could be its own pipe in a pipeline [18:11] pipeline is like a mesh of the git and bzr methods [18:14] so the idea is that the history inside a branch that got merged is pretty much useless and in bzr people work with (bisect, revert, blame) only the merge commits? [18:15] that's the current argument [18:15] or maybe the current religious orthodoxy among the converted [18:16] dandrader, the history inside the branch serves two purposes: [18:16] 1. during review, it's easy to see how the branch changed due to review feedback, especially since lp interleaves changes with the review comments [18:17] 2. after merging, someone can go back and see why changes were made [18:17] the usefulness of 2 is dubious, imo [18:17] but the usefulness of 1 is very high :) [18:17] agreed [18:17] when reviewing your branch, I was having to go back and forth between my previous review and your current revisions to see what has been changed [18:17] and I didn't have your old revisions any more to compare against [18:18] right [18:19] bzr pipeline is the best of both worlds [18:19] because each individual change has its own branch and review history [18:19] I would say the best way would be to just comment on top for the sake of an easier review ("avoiding reviewer fatigue" as bzr pipeline puts it) and then sanitizing the commits before finally merging [18:20] or the bzr pipeline way, which I don't know yet [18:20] the problem with sanitizing commits before merging is that I don't want to do extra work :) [18:21] I the submitter is not the one doing the merge than this step is not feasible indeed [18:21] I do not like bzr pipeline [18:21] bzr pipeline has some usability issues, agreed [18:21] there are two issues with bzr pipeline for me: [18:22] 1. I want to be able to rebase later pipes onto earlier pipes instead of constantly merging (it kinda works under specific circumstances, but it's not worth the risk of double commits or losing work) [18:22] 2. it shouldn't allow you to hop between pipes without pumping changes first [18:23] I think 2 is why its easy to lose work with pipeline [18:24] yes, it's (1) that was really the biggest issue for me (aside from losing work somehow) [18:24] a rebasing pump would make pipelines really nice [18:26] I don't think it would be *that* hard [18:26] but I don't have 3 weeks of time to spend on it :) [18:30] is there a point in merging a branch with a single commit instead of pushing the commit directly? [18:56] dandrader, I don't think there's much of a difference [18:56] I merge them just to be consistent [19:42] hi, i have a question, because I am not sure if I should report as a bug [19:43] I am on a tablet PC (HP touchsmart tm2) and on the beta2 i had the multitouch working on touchpad and touchscreen [19:43] and since an update (I can check logs) one feature does not work [19:44] this feature was not a multitouh thing : i could scroll with one finger (it looks to detect I did it on the touch screen only) [19:45] for example in empathy i need 2 finger to scroll on touchpad, i can use 2 finger on touchscreen but it is so simple to scroll with one finger [19:45] does this feature deseabled on purpose ? [19:49] (i mean the 1 finger on touchscreen, not touchpad) === dandrader is now known as dandrader|afk [20:02] cm-t, that's likely being implemented in gtk [20:02] I would ask in #ubuntu-desktop since it's not using the utouch stack [20:03] I see [20:03] thanks you cnd [20:03] np === dandrader|afk is now known as dandrader