| === MacSlow is now known as MacSlow|lunch | ||
| === MacSlow|lunch is now known as MacSlow | ||
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| cnd | bregma, keep going | 15:10 |
|---|---|---|
| cnd | I can hear | 15:10 |
| cnd | but if I drop, I'm afraid the call will drop | 15:10 |
| dandrader | call quality is horrible | 15:11 |
| cnd | bregma, same here :( | 15:11 |
| cnd | hey! | 15:12 |
| cnd | tvoss, I fixed valgrind in precise | 15:13 |
| cnd | would that be picked up automatically? | 15:13 |
| cnd | there were 4 grail merges | 15:14 |
| cnd | sure | 15:14 |
| cnd | thanks all :) | 15:14 |
| cnd | I don't know :( | 15:15 |
| cnd | alright, I think that's a wrap | 15:15 |
| cnd | thanks for joining :) | 15:15 |
| bregma | cnd, as I mentioned, I think we need to relicense utouch-evemu, utouch-frame, and utouch-grail (or dual license) because they're now linked directly with utouch-geis | 15:18 |
| bregma | should I get a consult from Canonical legal first? | 15:18 |
| cnd | bregma, ok, that's what I couldn't understand on the call :) | 15:18 |
| cnd | send an email to olli | 15:18 |
| cnd | I doubt it would be an issue | 15:18 |
| cnd | but I don't know what the process is | 15:19 |
| bregma | when it comes to lawyers, everything could be an issue | 15:19 |
| bregma | I will pass the buck to Olli | 15:19 |
| Satoris | I would imagine that Google would not like to have Chromium become GPL licensed, either. | 15:20 |
| cnd | tvoss, will the qa instances pick up the next valgrind I uploaded to precise automatically? | 15:40 |
| tvoss | cnd, yeah valgrind is updated on each job execution | 15:41 |
| cnd | cool | 15:42 |
| tvoss | cnd, I installed a precompiled gtest in a snapshot of the build/test vm's | 15:43 |
| tvoss | as soon as everything is back online, we have test results again | 15:43 |
| tvoss | cnd, do you know if the evemu-testing framework is able to produce xml output? | 15:58 |
| bregma | tvoss, evemu uses the standard python unit testing framework | 16:09 |
| tvoss | bregma, thanks | 16:09 |
| cnd | bregma, alright, let's tackle this autofoo stuff | 16:34 |
| cnd | here's my current thinking | 16:35 |
| cnd | we can provide the sources for xorg-gtest in an xorg-gtest aclocal script as $XORG_GTEST_SOURCES | 16:35 |
| cnd | it would hold the locations of xorg-gtest-all.cpp and gtest-all.cc | 16:36 |
| cnd | we also define XORG_GTEST_CPPFLAGS, which would hold the -I flags for include locations | 16:36 |
| cnd | we can also define $XORG_GTEST_MAIN_SOURCES as xorg-gtest_main.cpp | 16:37 |
| cnd | and lastly XORG_GTEST_LIBS would be the list of libraries needed to link against (libX11) | 16:37 |
| cnd | the users of xorg-gtest would then call the aclocal macro, and all the sources, flags, and libs to their tests | 16:38 |
| cnd | oh right... now I remember why that's bad | 16:38 |
| cnd | bregma, if you use lots of warning flags, and even worse -Werror, then when you add the gtest sources to your target it will be built with those same flags | 16:39 |
| bregma | what's wrong with just providing a .pc file with appropriate --cflag and --libs, plus a special variable for the _main.cpp path? | 16:39 |
| bregma | gtest is a wholly separate concern | 16:39 |
| cnd | bregma, xorg-gtest should provide for gtest while gtest is broken, imo | 16:40 |
| bregma | the libgtest problem can also be solved with a simple .pc file with --cflags and --libs and a special variable for the .cpp path | 16:41 |
| cnd | bregma, we can't ship a .pc file that isn't from upstream | 16:41 |
| bregma | that .pc file could be bundled with xorg-gtest until it makes it upstream | 16:41 |
| bregma | as long as it has a different name | 16:41 |
| cnd | but the xorg-gtest .pc file won't know where the gtest sources are installed | 16:41 |
| cnd | I don't see any option other than providing an aclocal script | 16:42 |
| bregma | really, it's completely wrong to solve the libgtest problem through the xorg-gtest package, it should be either upstream or in a separate package | 16:42 |
| bregma | aclocal script, .pc file, it ends up as the same thing | 16:42 |
| cnd | aclocal script would be run at package configuration time, while .pc was already run and installed | 16:43 |
| bregma | yes, a strike against .pc files in the first place | 16:43 |
| cnd | while it's not ideal that gtest is broken, I don't see why we shouldn't provide a macro to find it too | 16:44 |
| bregma | the aclocal script I have in my proposed utouch-geis branch can be moved into xorg-gtest | 16:44 |
| cnd | bregma, I think the sticky point is really the automake inclusion | 16:45 |
| cnd | I don't see any way around telling people to copy either an automake file or a series of runes into their Makefile.am | 16:46 |
| bregma | you have a problem with telling people to include the appriate _CFLAGS variable into their .am files? | 16:46 |
| cnd | adding the sources to the test targets directly isn't a good solution | 16:46 |
| cnd | it's not the CFLAGS | 16:46 |
| cnd | it's the sources | 16:46 |
| bregma | a single source file with a configurable path | 16:47 |
| bregma | not unlike any other source file | 16:47 |
| cnd | bregma, you want different CPPFLAGS | 16:47 |
| cnd | you want to add -w to the end for external sources | 16:47 |
| cnd | of course, that's the only difference you want in the CPPFLAGS | 16:48 |
| bregma | we are using a third-party library that does not compile cleanly, and we rely on it? | 16:49 |
| cnd | it probably does against a specific version of gcc | 16:49 |
| cnd | but not against the one in precise | 16:50 |
| cnd | it would be nearly impossible to always compile cleanly against all compilers | 16:50 |
| cnd | especially when you have things like the big gcc 3 to 4 transition where warnings and errors got a lot more strict | 16:50 |
| cnd | bregma, the other issue is that the sources may be compiled with more pedantic warnings than what the gtest devs use | 16:56 |
| cnd | xorg specifies a lot of extra warnings by default | 16:56 |
| cnd | one example is a warning when you shadow a variable in an outer namespace | 16:57 |
| bregma | I can think of no way for an automake include snippet to resolve the problem, since using separate compile flags for some source requires building a convenience library and that means passing different flags to the convenience library for each target it gets linked to | 17:04 |
| bregma | the only reliable way is to have some kind of wackey target in the Makefile.am that gets reprocessed by config.status to massage various flags | 17:04 |
| cnd | bregma, the closest thing is to use AM_CPPFLAGS and tell the user to use AM_CPPFLAGS too | 17:04 |
| bregma | yes, force then into rigid lock-step, until everything breaks because they used per-target flags in a per-target way as documented, and they can;t figure out why theu get missing symbols in their link | 17:05 |
| bregma | that sounds kind of fragile | 17:06 |
| cnd | it's all a bit fragile | 17:06 |
| bregma | the least fragile way is to document how to build a gtest library in your project, and have the developers add those three lines where required | 17:07 |
| cnd | it sounds like the least fragile solution to me | 17:07 |
| cnd | that may be | 17:07 |
| === dandrader is now known as dandrader|lunch | ||
| cnd | bregma, as for your macro, why should we add a --with-gtest flag? | 17:08 |
| cnd | when would we have gtest, but not want to use it? | 17:08 |
| bregma | --with-gtest=PREFIX sets the prefix where to look for gtest (eg. /usr/local) | 17:09 |
| bregma | --without-gtest will give the default of $(prefix) | 17:09 |
| cnd | that doesn't make sense to me | 17:10 |
| bregma | I copied that logic from other macro files in /usr/share/aclocal | 17:10 |
| cnd | without-gtest should mean "compile without gtest" | 17:10 |
| bregma | the idea is if you specified --with-gtest=/usr/local/ it will pick up your local copy rather than the system-installed copy | 17:10 |
| cnd | yeah, but we have two separate variables for that | 17:11 |
| cnd | with-gtest-sources and with-gtest-includes | 17:11 |
| cnd | the sources installed by gtest don't include the headers, so with-gtest alone won't work | 17:12 |
| cnd | you'll always have to provide with-gtest and with-gtest-sources, or with-gtest and with-gtest-includes | 17:13 |
| bregma | um, perhaps you;re developing under a different OS than I am | 17:16 |
| cnd | ? | 17:16 |
| bregma | there is but a single gtest package available through the archives my system points to, and it installs the headers and sources | 17:17 |
| cnd | yes, but not to the same location | 17:17 |
| cnd | /usr/src/gtest/src/*.cc and /usr/include/gtest/*.h | 17:17 |
| cnd | --with-gtest=<prefix> won't work for both | 17:17 |
| bregma | right, $(prefix) == /usr | 17:17 |
| bregma | I have no problem with removing the --with-gtest, it's just a convention frequently used by autoconf macros but not all autoconf macros | 17:18 |
| cnd | I guess I was tripped up by: gtest_srcpath="$gtest_prefix/gtest/src" | 17:19 |
| cnd | it would need to be $gtest_prefix/src/gtest/src | 17:19 |
| cnd | but either way, I don't think it's worthwhile to have it | 17:19 |
| cnd | if I was running ./configure --help, I would be very confused | 17:19 |
| bregma | OK, consider it gone | 17:20 |
| cnd | bregma, why don't you use AC_CHECK_FILE for gtest-all.cc? | 17:20 |
| bregma | 'cos I forget it existed? | 17:21 |
| cnd | ok | 17:21 |
| bregma | test -f is a long-ingrained habit, AC_CHECK_FILE would be better | 17:21 |
| cnd | bregma, I'm thinking that the stuff in my proposed aclocal script is fine | 17:22 |
| cnd | http://cgit.freedesktop.org/~cndougla/xorg-gtest/tree/aclocal/xorg-gtest.m4?h=source | 17:23 |
| cnd | is there something that needs to change there? | 17:23 |
| cnd | inside _CHECK_GTEST in particular | 17:24 |
| bregma | other than that it should probably be a separate callable macro that can be pushed upstream, and should probably have optional ACTION-IF-FOUND and ACTION-IF-NOT-FOUND args, I have no criticisms | 17:29 |
| cnd | bregma, the _CHECK_GTEST is separate, and can be pushed upstream | 17:31 |
| cnd | I'll add ACTION-IF-FOUND to the macro | 17:31 |
| bregma | is _CHECK_GTEST not in the same .m4 file as CHECK_XORG_GTEST? | 17:35 |
| cnd | it is, are you saying it should be split into a separate file? | 17:36 |
| cnd | I worry that splitting it into a separate file would make it seem like a public macro | 17:37 |
| cnd | it's really just an implementation detail for xorg-gtest | 17:37 |
| === dandrader|lunch is now known as dandrader | ||
| cnd | bregma, here's what I've got: http://paste.ubuntu.com/891007/ | 18:12 |
| cnd | is that alright with you? | 18:12 |
| bregma | did you test that last AS_IF with and withou an ACTON_IF_NOT_FOUND argument? | 18:16 |
| cnd | not yet | 18:17 |
| cnd | I will | 18:17 |
| cnd | but I wanted to get your thoughts first | 18:17 |
| bregma | ah, well, it's OK with me from a functional point of view | 18:18 |
| cnd | ok | 18:20 |
| cnd | I don't understand launchpad bug queries | 18:21 |
| cnd | they don't seem to do what you tell them to do | 18:21 |
| cnd | I'm finding lots of bugs that aren't found by the two queries I sent out last week | 18:22 |
| bregma | yes, there does seem to be some sort of dark magic involved | 18:23 |
| === dandrader is now known as dandrader|afk | ||
| === dandrader|afk is now known as dandrader | ||
| dandrader | cnd, in utouch-grail, I activate an atomic 3-touches Touch subscription and an atomic 3-touches Drag subscription. A 3-fingers drag is performed. What should happen? | 19:42 |
| cnd | dandrader, I think you should get both | 19:42 |
| cnd | because this is atomic handling, i.e. grail v1 handling, you would receive both gestures for the same touches | 19:43 |
| cnd | we really should have named this mode something other than atomic | 19:43 |
| cnd | maybe "compat" mode | 19:43 |
| dandrader | so that rule of having only one accepted gesture at a time doesn't hold, right? | 19:44 |
| cnd | it does, in the sense that only gestures for the same touch set are allowed | 19:44 |
| cnd | i.e. you can't have a one touch drag and a three touch drag at the same time | 19:45 |
| dandrader | so the rule is that the accepted gestures must take all existing touches | 19:45 |
| cnd | yeah | 19:45 |
| * cnd can't wait to move away from atomic mode... | 19:46 | |
| dandrader | for a given recording made with evemu you're guaranteed to get the exact same number of grail slices independently of the machine where that recording is played? i.e., the update frequency will be the same, etc? | 20:56 |
| dandrader | cnd, ^ | 21:01 |
| cnd | dandrader, should be | 21:01 |
| cnd | evemu playback is nondeterministic when it comes to timing though | 21:01 |
| cnd | it should be close, but the exact timestamp deltas between events will never be quite the same | 21:02 |
| cnd | bregma, I have fixed up the xorg-gtest stuff and confirmed it works with a rejiggered utouch-grail | 22:07 |
| cnd | it's mostly left the same as before, only now the macros has ACTION-IF-FOUND etc. | 22:07 |
| cnd | and the readme points out that manual automake rules is a valid way of handling things | 22:08 |
| cnd | do you want me to send it out for closer review again | 22:08 |
| cnd | or just push it so we can move on to fixing our tests? | 22:08 |
| bregma | cnd, if it works, I think it's been reviewd enough that you can just go ahead and push it | 22:45 |
| cnd | ok | 22:52 |
| cnd | if I were on the release team I would have real ultimate power | 23:21 |
| cnd | packages would quiver in my wake | 23:22 |
| cnd | oops, wrong channel :) | 23:22 |
| cnd | though to be clear, that was sarcastic :) | 23:23 |
| bregma | with power comes responibility | 23:25 |
| bregma | you couldn't drink during UDS, for example | 23:25 |
| cnd | oh man... | 23:25 |
Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!