[01:40] utouch-geis 2.2.7 just released and uploaded for beta2 [01:48] wft -- libxorg-gtest-dev is not in main??? [01:52] bregma, no, it's not [01:52] libgtest-dev isn't in main either [01:52] yet [01:52] bregma, doesn't utouch-geis configure and compile and make check properly without xorg-gtest? [01:53] or did you add it as a build dependency? [01:53] which you shouldn't do because you won't be able to instantiate uinput devices in the buildds [01:53] or even if you could, I think we shouldn't [02:00] the m4 macro is needed for autoconf to succeed [02:01] the actual library is never used [02:03] bregma, did you add the -I m4 --install automake option? [02:03] that will copy the macro into the m4 directory [02:03] best packaging practices are that if you use the autotools, you should use the dh-autoreconf package to update the configury to the latest versions (config.guess, config.sub, ltmain, libtool, etc) [02:03] so when you run make dist [02:04] it will include the script in the tarball [02:04] without the --install in Makefile.am, you do not need the xorg-gtest build dependency, but because autoreconf pulls in the m4 file with that argument, builds will fail [02:04] bregma, it won't delete scripts that were copied in there [02:05] the tarball has xorg-gtest.m4 [02:05] you run autoreconf [02:05] it leaves the m4/xorg-gtest.m4 because there's no /usr/share/aclocal/xorg-gtest.m4 [02:07] bregma, we shouldn't be running autoreconf in debian/rules unless it's a daily build anyway, but that's a separate issue [02:11] so all your daily builds are failing because they're don't build from tarballs [02:12] I think I know where the issue lies there [02:12] I need to double check though [02:12] but my first priority right now is getting things in the archive [02:12] before the freeze [02:13] as to not following best packaging practices (using dh-autoreconf), I'll stick to what will get utouch into Debian [02:13] they;re way pickier about these things [02:13] they actually run autoreconf for every autotools package? [02:13] why do you need --with-autoreconf if that's the case? [02:14] wouldn't the default be to use autoreconf, and specify --without-autoreconf if needed [02:14] http://www.debian.org/doc/manuals/developers-reference/best-pkging-practices.html#bpp-autotools [02:14] you should see how picky they get about the debian/copyright file [02:16] I'll have reupload geis to get rid of the dependency wait [02:18] bregma, thanks for the autotools pointe [02:18] r [02:18] I'll need to revert my changes [02:18] I assume in practice it was hoped that autoreconf wouldn't be needed by packagers [02:18] but it seems like that's not the case :( [02:22] if aclocal.m4 gets checked in to the project it should be OK [02:22] bregma, btw, you don't need the call to dh_autoreconf inside override_dh_auto_configure [02:23] bregma, where does aclocal.m4 come from? [02:23] yeah, that's probably let over from something else that went wrong [02:23] I'll play with that later [02:23] aclocal [02:23] autoreconf creates aclocal from the m4 files [02:24] I guess my question is why it needs to be checked in [02:24] by running aclocal [02:24] autogen.sh contains acutreconf -f, which forces aclocal to be regenerated whenever it;s run [02:24] what's in aclocal.m4 that needs to be kept around? [02:24] typing acuity goes downhill the later it gets [02:24] heh [02:25] * cnd is almost done with grail, thank goodness [02:25] aclocal is what gets shipped in the tarball, which is why libxorg-gtest-dev doesn't need to be available in the buildd [02:25] as long as aclocal is not regenerated (autoreconf -f), autoconf should generate a good configure [02:26] I think [02:26] bregma, I don't have aclocal.m4 checked into grail or frame [02:26] I don't have anything checked in under m4 I don't think [02:26] yes, and the dailies are failing [02:26] because I turned off autoreconf [02:27] though the dailies won't have xorg-gtest.m4... [02:27] hmm [02:27] I'm trying to work out the conflict between the dailies (built as a native package) and the buildds (build as 3.0 (quilt)) [02:28] I'm running test pbuilders right now [02:28] ok [02:28] if it is getting too late, just push it up to the archive [02:29] we can fix the dailies tomorrow [02:37] uploaded, building, ..... [02:43] looks good [02:43] \o/ [02:44] thanks for taking care of the geis upload bregme [02:44] bregma even [02:53] we'll need at least one more upload of the entire stack once the licensing situation gets resolved, regardless of bugfixes [02:53] I'm still waiting to hear a legal opinion, but I'm sure that will come [02:54] yeah [02:54] I'm sure there will be more uploads [02:54] but they can wait till after the beta 2 freeze [02:54] I'll just be happy when all the unity gestures are working again [02:56] hopefully dandrader just needs to finish his window hit testing fixes in unity [03:02] I'm looking for a sponsor for the Debian packages, but I probably won't have any success until I corner someone at UDS [03:02] getting into Debian is a goal for Q [03:13] cool [03:13] bregma, there may be someone on the ubuntu-x team who can help [03:14] Sarvatt possibly [03:14] I see him do a lot of debian X work, but I don't know if he's a DD [03:14] he's not a core dev yet [03:14] but he should be [03:17] we're not in a hurry, I was waiting for grail and geis to stabilize before pushing to get the whole stack in at once [03:17] that may not happen until RC freeze [03:18] so UDS is a good time to tackle it [03:23] yep [09:32] Anyone else getting this: configure.ac:41: error: possibly undefined macro: AC_MSG_NOTICE [09:37] Google seems to indicate an old version of autogarbage, but I have 2.68. It's the default even. [09:38] Geis builds but frame and grail don't. [09:45] Four finger gestures do nothing. [09:46] I feel like drinking massive quantities of whiskey. [11:08] apt-get install libxorg-gtest-dev [11:27] Next up on hunt the proper package: possibly undefined macro: AC_TDD_GCOV [11:27] something about gcov, no doubt [11:28] One would imagine. [11:28] defined in a file in the m4 directory of each project [11:28] are you building from bzr or from a tarball? [11:28] bzr [11:29] then that macro should be there [11:29] But isn't. Or doesn't work at least. [11:29] Grep says it's there. [11:32] try running autoreconf -ifv [11:32] you may have a stale aclocal.m4 [11:33] Ok, now it works. [11:33] I really hate autogarbage. Hate it! Hate it! HATE IT! [11:34] If it were a person I would gladly go to prison for 10 years if it meant that I could stab it slowly to death. [11:41] Satoris, hate autotools and it will hate you back :) [11:43] damn, I'm starting to think that the batteries on my Magic Trackpad must already be getting too low. And I just use it for testing purposes. [11:44] How long does a battery set last for you guys usually, on your trackpad? [11:46] bregma: Geis does not seem to install a pkg-config file any more. Should it? [11:47] Nor is there a dbg package. === dandrader is now known as dandrader|brb [11:52] Hmm, geis does appear in the system pkg-config, but if you install it to a custom prefix, no .pc file shows up there. === MacSlow is now known as MacSlow|lunch === dandrader|brb is now known as dandrader [12:56] Satoris, I do ./autogen.sh && ./configure --prefix=/usr && make -j5 DESTDIR=/tmp/fargle install and I see the .pc file installed in /tmp/fargle/usr/lib/pkgconfig/libutouch-geis.pc [12:56] how custom is your custom prefix? [12:59] I tried ./configure -prefix=/leg/bone && make install DESTDIR=/tmp/long and I see /tmp/long/leg/bone/lib/pkgconfig/libutouch-geis.pc [13:08] It's just /home/jpakkane/devroot. There is no pkgconfig subdir in lib. [13:09] I build in a dedicated build directory, though. Could that be an issue? [13:10] So something like: autogen; mkdir build; cd build; ../configure --prefix=... === MacSlow|lunch is now known as MacSlow [13:23] nope, that works for me, too, as it does when I type "make distcheck" or when using any debuild variant [13:24] Nailed it. It fails if you do 'CC='ccache gcc' CXX='ccache g++' ../configure --prefix=/tmp/abcd'. [13:25] Modulo fixing the quotes. [13:29] ccache should affect how sed works, I suspect the build is bailing elsewhere [13:29] s/should/should not/ [13:30] libtool: install: error: cannot install `_geis_bindings.la' to a directory not ending in /usr/local/lib/python2.7/dist-packages [13:31] There's your problem. But what is causing it? [13:34] my guess is libtool needs regenerating (libtool is definitely broken in many ways) .. I see this if I rerun ./configure with a different --prefix without force-regenerating libtool by running autoreconf -f [13:37] With a fresh checkout the install works fine. [13:38] Libtool has existed for, what, 15 years already? You'd think that they would have gotten this piece of shit to work by now. [13:40] oh yes, it works much better now, for some definition of work [13:41] A prime example of how the (grammatical) positive case is much stronger than the comparative case. [13:42] A thing may be better than some other thing. It may even be the best. That does not mean that it is good. [13:48] Hmm, simply running autoreconf -f is not enough to fix this. [13:50] hmm, I look at my history and all I did was run make clean -- libtool is generated by configure, ao the autoreconf is not necessary [13:51] you can't change the prefix between make and install, it just won't work without cleaning and remaking [13:51] I have never done that. [13:52] I always run make after configure, even if I know I'll run make install next. [13:52] make clean? [13:53] Now it installs cleanly. [13:54] This is a bit like those old text adventure games where you have to guess which word the parser is expecting to get forward. [13:57] except it does make complete sense when you think about it [13:57] I guess the problem is that there should be an implicit build dependency of all build files on config.status to force everything to be rebuild if you rerun configure [13:58] but that would probably be overkill, since the rebuild should happen only of the contents of config.status has changed, not the timestamp of the file [13:59] If only there was a way to detect the change of contents in a file. [14:00] maybe we need a replacement for make [14:01] Scons works on MD5 hashes. [14:02] Google has a Make replacement called Ninja. It's crazy fast but works on timestamps AFAICT. [14:33] bregma: have you looked at Jose's drag/tap bug? Should they work when subscribed at the same time? [14:38] I was hoping all the tap fixes would make taps work in unity [14:38] but there's still a bug in grail :( [14:38] it doesn't properly get rid of ended touches [14:43] I put a better test app in the bug. [14:43] There seem to be several independent bugs in the stack somewhere. [14:44] cnd: since you asked, 4 finger gestures are broken everywhere for me. [14:45] yeah, I get the same here [14:45] if you turn on grail debugging you'll see that ended touches are still matched for new gestures [14:45] and that throws everything off [14:46] Panel swipe works on rare occasions a couple of times in Unity 2D. Then it crashes and stops working. [15:06] dandrader, with an updated synaptics, grail passes in jenkins again :) [15:07] good [15:07] I didn't have the same luck. That's what I get when the first grail x11 test is run: http://paste.ubuntu.com/895186/ [15:08] dandrader, so X synaptics grabs all devices [15:09] what is happening is that your current X server is grabbing the test device [15:09] then the dummy X server is attempting to grab it [15:09] and it fails [15:09] hmm [15:09] you can use an xorg.conf option to inhibit grabbing [15:09] or you can switch VTs to a console to run your tests [15:09] or you can try running with the --no-dummy-server option [15:10] first option looks better [15:10] I've been thinking of adding an xorg.conf.d snippet that would install as part of xorg-gtest [15:10] it would turn off all X synaptics grabbing for devices matching "* (Virtual Test Device)" [15:10] I just haven't gotten around to it [15:11] dandrader, you can find the info in "man synaptics" [15:11] Option "GrabEventDevice" "false" [15:12] thanks. will try that later [15:13] you can copy the first snippet in /usr/share/X11/xorg.conf.d/50-synaptics.conf [15:15] still working on atomic/trackpad recognizer, more jenkins fun and simplifications with the job setups, started work on arm chroot [15:16] well on the way with #904731 [15:16] I'm going to tackle as many bugs as possible until unity gestures work [15:16] dandrader, Satoris: stand ups! [15:17] cnd, can we help with testing, information gathering? [15:17] Investigating why Unity using geisv1 is so buggy while the refactored Unity that uses geisv2 API works fine. I.e. the old Geis API doesn't seem to be working well on top of the new uTouch architecture. [15:17] in particular, I know of a bug in grail where ended touches aren't "deleted" from the grail state [15:17] tvoss, not yet [15:17] dandrader, it could be due to the bug I see and am trying to fix [15:18] geis v1 needs to dry p and fade away to nothingness [15:18] though I'm surprised it would work any better in geisv2 [15:18] bregma, as soon as precise ships, I'm hoping we can deprecate it [15:18] bregma, dandrader pointed out that our docs don't really show geis v2 vs v1 in the proper light [15:19] v1 is mentioned as the simple API [15:19] which some might mistake as the route they should take [15:19] at some point we probably want to clear that up === dandrader is now known as dandrader|lunch [15:26] Today: bugs. [15:48] Satoris, you enlightened me to -Weffc++ [15:48] now I've lost a half hour fixing frame for all the issues :) [15:49] Are you going to fix the empty virtual destructor thingies or the other ones? [15:49] I fixed them all [15:49] though std::enable_shared_from_this is broken [15:50] so until libstdc++ is fixed we can't enable -Weffc++ and -Werror at the same time [15:50] I learned about -Weffc++ from bregma when I first filed that bug. [15:50] ahh [15:50] so I have bregma to thank :) [15:50] I found the bug via Eclipse. [15:51] ok, time for me to get breakfast and do other morning stuff [15:51] biab [15:52] -Weffc++ might be a bit overkill for every day usage. [15:53] Personal opinion: having the elements in the constructor list even though nothing is done with them is superfluous. [15:56] but it's always satisfying making something build cleanly with warnings cranked up to 11 [15:57] Even if you have to edit the system headers to get there. [16:06] absolutely -- been there, done that, too [16:06] But do you have the T-shirt? [16:20] I've already had to fix libstdc++ headers for C11 _Generic support this cycle :) === dandrader|lunch is now known as dandrader [17:01] cnd, is that related to the bug you're working on? http://paste.ubuntu.com/895335/ [17:01] dandrader, probably [17:02] it's likely trying to get data for a touch that has already ended [17:03] after those warnings start to appear they won't go away until I restart the app [17:06] yeah [17:06] and gestures won't work anymore either [17:07] dandrader, I'm a bit worried about touch state tracker in general [17:07] it's getting a bit hairy [17:07] I had an idea: [17:08] we can have a new touch state class that contains the touch id and the start time as members [17:08] gestures and the recognizer hold std::shared_ptr objects pointing to the touch state class for each touch [17:09] when a touch should be accepted, the AcceptTouch method is called, the touch is accepted, and the touch state internally notes that it is accepted [17:09] when all shared ptrs to the touch state have been released, the destructor is called [17:10] in the destructor, if the touch has not been accepted already it is rejected [17:10] the key here is that the recognizer drops all shared ptrs to the touch state when the touch ends [17:11] we should be able to get rid of all recognizer touch sets other than the free_touches_ set [17:14] sounds good [17:16] * cnd begins coding === dandrader is now known as dandrader|afk === dandrader|afk is now known as dandrader [17:40] cnd, was that bug introduced by that commit that added the Gesture::all_touches_ list? [17:43] dandrader, maybe? [17:43] but that change fixes a similar bug [17:43] actually, no, it wasn't introduced [17:43] it's always been there [17:43] but it might have been laying dormant