[00:35] https://wiki.ubuntu.com/XorgCtrlAltBackspace spec written [09:00] morning [09:01] looks like intel is taking the "won't build with kernel headers" seriously.. freedesktop bug 19132 [09:01] Freedesktop bug 19132 in Driver/intel "2.5.99.1 fails to build using drm headers from 2.6.28" [Critical,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19132 [09:46] Hmmm. [09:46] X isn't liking me. [09:46] Not much at all. [09:47] I have to start GNOME manually now, and be careful not to do too much that involves randr, or X dies bloodily. [09:48] Nothing at all in the logs. [11:10] wgrant: not even on stderr? (gdm.log) [11:12] jcristau: error setting MTRR (base = 0xc0000000, size = 0x10000000, type = 1) Invalid argument (22) ddxSigGiveUp: Closing log [11:12] Does that look relevant? [11:12] no, that shouldn't kill it [11:13] Indeed, not all of those logs have it. There's nothing else. [11:13] Just lots of screen corruption and an X restart. [11:13] what driver is that? [11:13] i810, on i915. [11:14] uh, why not -intel [11:14] Because I can't think straight. -intel it is. [11:14] heh, ok [11:14] I live in the past. [11:14] don't we all [11:14] *sigh* [11:25] tjaalton: re: the (x)calloc patch, did you also change xfree -> free? [11:28] jcristau: doesn't look like it. I haven't tested it either [11:28] k [11:28] if it works [11:28] how to test that btw? [11:29] never used it.. [11:29] me neither :) [11:29] heh .) [11:29] :) [15:01] tjaalton: if I wanted to rebuild X with --enable-dbus all I would have to do (e.g. in intrepid) is add "--enable-dbus" to the confflags in the debian/rules of xserver-xorg, right? [15:19] tseliot: yes, except it's called --enable-config-dbus [15:20] tjaalton: ok, thanks [17:50] mvo: I have put the nvidia drivers in separate bzr branches (e.g. 173-intrepid, 173-jaunty, etc.) and I have fixed the bug you reported yesterday. I would like to know how I can avoid keeping the same binary blob in each branch. You managed to keep the orig.tar.gz separate from the packaging scripts in g-c-c. How did you do that? [17:51] tseliot: it uses the debian/watch file to download the actual orig.tar.gz [17:51] tseliot: not sure if that could work with nvidia as well (I don't know a lot about that package) [17:51] tseliot: stacked branches might work as well [17:51] tseliot: thanks a lot for fixing the bug :) ! [17:53] mvo: can I keep a branch with say driver 177 without the debian directory and use that for other branches? [17:53] mvo: or any docs about stacked branches? [17:54] tseliot: I think stacked branches might work for that, its a relatively new feature, I'm not sure how they are used [17:54] tseliot: #bzr will know [17:54] http://jam-bazaar.blogspot.com/2008/05/this-week-in-bazaar_29.html [17:54] mvo: ok, thanks a lot [17:54] was something I found as well [17:54] one of those things I alwayed watned to look at bug never quite managed [17:55] I'll have a look at it since it can save me a lot of time [17:55] * mvo nods [17:56] * mvo is away for dinner [18:44] tjaalton: regarding the vmmouse breakage: it expects header /usr/include/xorg/xf86OSmouse.h which used to be provided by xserver-xorg-dev but is no longer [18:44] tjaalton: I also tried building the latest 2.6.2 release of -vmmouse, but same issue [19:09] hmm [19:10] tjaalton: so it appears that the OSMouse code was deleted from xserver (http://cgit.freedesktop.org/xorg/xserver/commit/?id=b89a59248a4a0ff06b9a0ddee45881efc6063063) [19:10] tjaalton: which I gather makes -vmmouse badly, badly broken [19:12] that's a lot of badly [19:12] ok maybe just one badly [19:23] ooh got it to compile [19:25] putting the old header file from the server into the driver code, and one minor fix, and it builds. Lots of warnings about deprecated interfaces though. the vmmouse guys need to look into this more. [19:41] bryce: yes, it's the "one minor fix" of yours that I couldn't figure out :) [19:42] adding the header and running configure/make made it compile, so I figured there was something wrong in the packaging [19:42] so I dropped vmmouse from input-all so it wouldn't prevent installations [20:04] tjaalton: I'll email the vmmouse guy to bring this to his attention [20:05] I've filed a bug about it too, a sec [20:08] freedesktop bug 19119 [20:08] Freedesktop bug 19119 in * Other "vmmouse doesn't build against xserver 1.6" [Normal,New] http://bugzilla.freedesktop.org/show_bug.cgi?id=19119 [20:15] done [20:19] jcristau: want me to file this in the debian bts? I'm assuming you won't care about it until post-lenny, by which time hopefully there'll be a better fix available. [20:25] Are we planning to pull from the xserver 1.6 branch again some time soon? I wonder if some of those fixes fix my crasher that appeared in -0ubuntu2. [20:26] wgrant: not that I know [20:26] surely after alpha2 [20:26] wgrant: I think the plan is to stick with stock 1.6 + pulled patches [20:27] 1.6 hasn't been released yet. [20:27] k [20:28] sorry, thought you were talking about the post-1.6 stuff [20:28] Ah, no. [20:29] well, the stable branch usually is well maintained, so I don't see a reason why not to follow it if need be [20:30] point releases are of course preferred [20:30] but those might take time [20:31] once 1.6 is released it'll be bugfixes only.. [21:53] Woo, float XAtom support! [21:57] yep [21:58] Well, at least a semi-rejected patch for it. [22:15] I'm working on https://wiki.ubuntu.com/X/Blueprints/WacomTabletsUi next... anyone have any comments/ideas to include there while I'm at it? [22:16] alberto covered most of it already, just need to fill in test section, etc. [22:22] anyone? bueller? [22:25] great movie :) [22:27] indeedy. ok guess I'm about done with this one [22:28] I'm curious about the dbus-based approach to configuring tablets, and how that might affect alberto's tool [22:29] I think he needs to play with it first [22:31] night [22:32] night