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