[13:21] <Satoris> Geis does not build with newest Clang. It errors out because the headers try to use Generics even when C standards version is not c1x.
[13:22] <Satoris> So either the Frame headers need to explicitly check that (how?) or this warning needs to be disabled in Geis.
[13:23] <Satoris> Or, to but it another way, clang will reply true to __has_extension(c_generic_selections) even for earlier C standards versions.
[13:23] <Satoris> Which is theoretically correct, but mostly useless.
[13:30] <bregma> that would be a problem in frame, though, not geis, because geis has no knowledge of C generics
[13:31] <Satoris> True.
[13:31] <bregma> not that it shouldn't be fixed
[13:32] <Satoris> The bug is either in Frame's headers being wrong or Clang reporting its capabilities incorrectly.
[13:35] <bregma> well, if clang says it supports generics and it doesn't, is it not obvious what the problem is?
[13:36] <bregma> or is the decision made at configuration time for frame?  That would definitely be wrong.
[13:38] <Satoris> Well one could say that having the extension in c90 or whatever is not wrong per se, because it is an extension. It could be anything.
[13:38] <Satoris> The decision is not made at configure time for Frame, no.
[13:40] <Satoris> The extra checks that this extension is only used with C1X is not "wrong" either, because it only became officially supported at that time.
[13:40] <Satoris> But combine -Wall and -Werror and then they clash.
[13:46]  * bregma Quantal Quetzal ????
[14:03] <cnd> Satoris, while it's not perfect in the sense that we are imposing C11 stuff into non-C11 compilations, I think it's actually a positive thing
[14:03] <cnd> Satoris, I would be 100% behind any fixes to geis so it builds with clang :)
[14:04] <cnd> tvoss, I have fixed all three of the Xlib memory leaks when running the frame and grail test suites :)
[14:04] <Satoris> The proper thing to fix is Frame.
[14:04] <cnd> unfortunately, they aren't serious enough to warrant an SRU
[14:04] <cnd> Satoris, fix frame how?
[14:05] <Satoris> In pseudocode, change current "supports generics" to "is c1x and supports generics".
[14:05] <cnd> Satoris, if you don't want the _Generic type checking, then figure out how to disable that extension when you are compiling with clang
[14:05] <tvoss> cnd, oh cool ... can re-enable the valgrind testing again then?
[14:06] <cnd> tvoss, once Q opens up and we can upload fixes in libXi, libXext, and libXau
[14:06] <Satoris> Takes some preprocessor work, though.
[14:07] <tvoss> cnd, cool :)
[14:07] <cnd> Satoris, if we require C11 and _Generic support, then we are inhibiting people compiling specifically with _Generic and earlier C standards
[14:07] <cnd> they might actually want that
[14:07] <cnd> I would suggest we want that for geis event
[14:07] <cnd> even*
[14:07] <Satoris> No, not require it. But only provide Generics if the standards version is c1x.
[14:08] <Satoris> The reason this is an issue is -Werror. Otherwise we would just have one warning that is easy to inspect and deem irrelevant.
[14:09] <cnd> I think it makes sense for us to have geis compile as c99, but have type checking through _Generic if available
[14:09] <cnd> we should fix geis so it doesn't error
[14:09] <cnd> it should be trivial type fixes
[14:09] <Satoris> Then you need to disable this warning in Geis. There is no other way.
[14:09] <cnd> Satoris, why can't we fix geis?
[14:10] <bregma> fix geis because the frame code will not complie?
[14:10] <cnd> bregma, it's geis that isn't compiling
[14:10] <cnd> because the _Generic stuff is in the frame headers
[14:10] <bregma> no, geis won;t build with clang because the code from frame won;t compile
[14:10] <cnd> it's likely doing what it's intended to do: catch bad type usage
[14:11] <Satoris> It can be claimed that what Clang does is not standards conformant.
[14:11] <cnd> Satoris, is frame failing to build, or is geis failing to build
[14:11] <Satoris> Which makes everything harder again.
[14:11] <bregma> it's the frame code that's not compiling, ergo the problem is in the fame code
[14:11] <Satoris> Frame compiles. Geis does not, due to the combination of compiler flags it uses.
[14:11] <bregma> or, really, the problem is in clang
[14:12] <cnd> Satoris, can you paste one of the errors
[14:12] <cnd> or just pastebin the whole compilation output
[14:12] <bregma> the frame project compiles, but the geis project does not compile because it is failing on frame code
[14:13] <Satoris> Sure. It's on my other machine, hang on.
[14:13] <bregma> can frame provide the necessary CFLAGS in its .pc file?
[14:13] <cnd> bregma, that's the intended result, if geis is passing the wrong types into frame
[14:13] <bregma> or if you try to compile it with clang without using the correct compile-time flags?
[14:14] <cnd> bregma, I'm not sure what CFLAGS you are thinking are at work here
[14:15] <Satoris> http://paste.ubuntu.com/942547/
[14:15] <cnd> ohhhh
[14:15] <cnd> it's failing because it is trying to use generic in non-c11 code
[14:15] <cnd> I thought it was failing because of actual type checks
[14:16] <Satoris> Which it theoretically can, because it is an extension.
[14:16] <Satoris> The problem lies with -Wc11-extensions.
[14:16] <Satoris> Combined with -Werror.
[14:16] <cnd> ok, so yes, I think we need to fix frame so we don't trigger -Wc11-extensions
[14:18] <cnd> Satoris, can you try changing the frame headers so it uses __has_feature(c_generic_selections)
[14:18] <cnd> instead of __has_extension(c_generic_selections)
[14:18] <Satoris> I can try, at least. :)
[14:19] <dandrader> my status report: In utouch-geis, I'm taking libgtest out of libgtest_geis (which includes xorg-gtest and evemu fixtures) and making my test for https://bugs.launchpad.net/bugs/984069 use gtest fw instead of check fw
[14:20] <Satoris> Changing it makes Geis compile. Now I have to test whether it works as it should on Clang and GCC.
[14:20] <tvoss> fixing  #950974 and polishing port of chromium patch to new infrastructure
[14:20] <bregma> go go gadget ubottu
[14:20] <cnd> ooh, looks like tvoss found a way to get around ubot5
[14:20] <cnd> bug 950974
[14:21] <bregma> sweet, that stuff annoys me when it's not wanted
[14:21] <bregma> 1
[14:21] <tvoss> #1
[14:21] <bregma> hmm
[14:21] <cnd> what am I going to be doing...
[14:21] <tvoss> bug 1
[14:21] <bregma> bug 1
[14:21] <bregma> heh
[14:21] <Satoris> bug 2
[14:21] <tvoss> bug 666
[14:21] <cnd> I think I'll be working on architecture docs
[14:22] <cnd> and bugs if needed
[14:22] <cnd> and thinking about updates to utouch-qml
[14:22] <bregma> I'm going to be saying Quantal Quetzal until it loses all meaning
[14:22] <Satoris> Trying to find bugs. And found them too. Plus some secret stuff.
[14:23] <cnd> oh, quantel quetzal?
[14:23] <bregma> I have restructured all the integration tests in geis, and even got most of them to pass repeatedly
[14:23] <cnd> yay
[14:23] <bregma> quantAl, not quantel (which was a computer manufracturer)
[14:24] <bregma> manufracturer, heh, there's a freudian slip
[14:24] <dandrader> ah, so "Quantal Quetzal" is the nickname of Ubuntu 12.10. I thought it was just a bunch of random words stitched together :)
[14:24] <bregma> I have one last integration test still sometimes failing, but if you guys with new tests would get them in I would appreciate it
[14:25] <bregma> http://www.markshuttleworth.com/archives/1121
[14:26] <Satoris> cnd: that fix works properly on GCC and Clang. Will send a merge proposal.
[14:26] <cnd> Satoris, thanks!
[14:27] <cnd> bregma, dandrader: I still need reviewed-by tags on the first three xorg-gtest patches I sent out
[14:27] <bregma> I sent out mails for those, I see they never appeared on the list
[14:27] <bregma> hmm, evidently the mails were not signed -- is that required for that list?
[14:28] <cnd> no
[14:28] <cnd> bregma, I got the reply for the last patch
[14:28] <cnd> but not the first three
[14:29] <bregma> I signed the last reply (or, didn't disable signing)
[14:29] <bregma> a number of Debian lists reject signed messages, I just never know which list needs what any more
[14:31] <bregma> there, just resent the first three reviewed-by replies (signed this time) -- and I see them on the list
[14:31] <cnd> thanks
[14:31] <cnd> I'll get those applied
[14:33] <bregma> we're getting hit with about 10 cm of wet snow right now
[14:35] <Satoris> Hmm, Frame has missing header checks in configure: ../../src/v2/x11/device_x11.cpp:28:37: fatal error: xorg/xserver-properties.h: No such file or directory
[14:36] <cnd> ahh
[14:36] <cnd> Satoris, we need to check for the xorg-server package
[14:37] <Satoris> Same for Geis regarding xcb-proto and Pythong bindings.
[14:37] <cnd> you can add that to the PKG_CHECK_MODULES for XINPUT
[15:18] <cnd> dandrader, bregma: latest fixes to xorg-gtest are available in the daily ppa now :)
[15:19] <bregma> these are just your patches or are there other changes?
[15:20] <cnd> just the four patches I sent out
[15:20] <cnd> but there was another change since the precise release
[15:21] <cnd> after installing the latest xorg-gtest and restarting your X session, you shouldn't need to switch VTs to do trackpad tests
[15:27] <cnd> bregma, it's not clear to me if you approve of my change to the geis subscription flags
[15:27] <cnd> you didn't mark as approvide or needs fixing, etc.
[15:27] <cnd> https://code.launchpad.net/~chasedouglas/utouch-geis/subscription-flags/+merge/102920
[15:27] <bregma> hmm, I have xserver-xorg-dev 2:1.11.4-0ubuntu10.1 from precise-proposed/main installed, and 'pkg-config --modversion xorg-server' gives me 1.11.3 so the merge proposal from Satoris fails to detect XINPUT because it's looking for 1.11.4 ...  any idea what's up with that?
[15:27] <cnd> bregma, you should have 1.11.4...
[15:28] <cnd> bregma, apt-cache policy xserver-xorg-dev
[15:28] <bregma> I posted the information I gleaned from apt-cache policy
[15:28] <cnd> oh right
[15:29] <cnd> hmm... I have the same
[15:29] <bregma> that's my concern:  is the package in precise-proposed incorrect?
[15:29] <cnd> yeah, xorg-server is incorrect
[15:29] <cnd> it's not really a big deal, nothing in the point releases has changed the api/abi
[15:29] <cnd> it's likely because of how we have a frankenserver, and I probably forgot to bump a version somewhere
[15:30] <bregma> as to your merge proposal, the change doesn't change anything except using a non-idiomatic way to express it
[15:30] <cnd> bregma, so are you ok with it?
[15:30] <bregma> I'm not a big fan of non-idiomatic code, but it doesn't really matter, and is in keeping with the Ubuntu philosphy of 'we reinvent things'
[15:31] <cnd> hmm?
[15:31] <cnd> I'm just trying to fix compilation using c++
[15:32] <bregma> does the C compiler not use C linkage when a name is enclosed in ectern "C" {} ?
[15:32] <bregma> C++ compiler, I mean
[15:32] <bregma> and, um, extern
[15:34] <bregma> I'm asking because I know it will emit bariables with that typedef as 'int' because of the C linkage, but I'm not sure whether the C++ front-end will change the semantics because of the C linkage
[15:34] <bregma> s/bariables/variables/
[15:35] <cnd> bregma, I can give you a sample c++ file if you like
[15:35] <bregma> enums are one of the significant differences between C and C++
[15:37] <cnd> bregma, http://paste.ubuntu.com/942681/
[15:38] <cnd> if you save that as test.c, gcc is fine with it
[15:38] <cnd> if you save it as test.cpp, gcc errors out
[15:48] <bregma> yes, I just constructed and analysed a test -- it looks like GCC has interpreted [7.5] as exclusive and that [7.2] supersedes the normatively included C standard, which as far as I can tell is a legitimate interpretation
[15:48] <bregma> of the C++ standard
[15:48] <bregma> I will approve the change
[15:52] <cnd> ok
[16:00] <cnd> bregma, oh noes! we have a typo in the geis api: GEIS_INIT_SEND_SYNCHRONOS_EVENTS
[16:00] <cnd> perhaps we should also define GEIS_INIT_SEND_SYNCHRONOUS_EVENTS?
[16:01] <bregma> I noticed that a while back, but the freeze was on so I never fixed it
[16:01] <bregma> it won;t hurt to just add a synonym
[16:01] <cnd> #define GEIS_INIT_SEND_SYNCHRONOUS_EVENTS GEIS_INIT_SEND_SYNCHRONOS_EVENTS
[16:01] <bregma> that'll do for now
[19:42] <cnd> bregma, did you see my message to multi-touch-dev about cleaning up device support bugs?
[19:43] <cnd> I just want to confirm you don't have any issue with it
[19:43] <bregma> last week?
[19:43] <cnd> yeah, from friday
[19:44] <bregma> I don;t have any problem with it
[19:44] <bregma> if a device doesn;t conform to the Win HIS standard, it's not our bug to fix
[19:44] <bregma> *HID*
[19:44] <bregma> (and even if it does, but that's different)
[19:45] <cnd> k
[19:45] <cnd> I'm trying to get our bug counts down
[19:45] <cnd> and make the reports more useful
[19:45] <cnd> the next task will be to deal with ginn bugs
[19:46] <cnd> we'll discuss at the sprint
[19:46] <bregma> yes, ginn and friends needs some lovin'
[19:47] <cnd> nearly half the bugs against canonical-multitouch are ginn :(
[19:47] <cnd> lunch!
[21:12] <cnd> yay!
[21:12] <cnd> I'm playing with utouch qml
[21:13] <cnd> updating it to use non-atomic gestures
[21:13] <bregma> mid-air collision in merge proposal reviews
[21:13] <cnd> and it does multiple simultaneous gestures at the same time
[21:13] <bregma> the future is now
[21:14] <cnd> unfortunately, utouch-qml is currently broken because of the bug dandrader is fixing and because of the change in coordinates
[21:14] <cnd> and now I have to figure out how to make qml tests...
[21:15] <cnd> it might involve having to make a version of xorg-gtest or an xinput mock in ruby :(
[21:15] <cnd> qml testability is the upstream testing framework
[21:15] <cnd> and you test qml not by using qml
[21:15] <cnd> but by using ruby...
[21:17] <bregma> sounds like work
[21:17] <cnd> yeah...
[21:17] <cnd> I've never used ruby
[21:18] <bregma> once you learn it you can become a web dev
[21:18] <bregma> haven't you always wanted to be a web dev?
[21:20] <cnd> ummm...
[21:31] <cnd> hmm... one problem of git-bzr: how do I do --fixes?
[21:36] <cnd> bregma, it looks like we aren't populating all the device attrs
[21:36] <cnd> we're missing the axis info
[21:36] <cnd> geisview, and by extension utouch-qml, don't have them defined
[21:51] <cnd> hrm... I wasn't paying close enough attention to the geis changes for gesture accept/reject
[21:51] <cnd> utouch-qml relies on the old useless function signature
[21:51] <cnd> so it won't compile anymore