[05:17] bryce: note that files in /etc are conffiles, and removing them needs extra care [05:18] so just renaming it means that people will have them both [05:21] tjaalton: oh for 60x11-localhost? [05:22] yes [05:22] how should it be done? [05:22] there are examples in that package [05:22] can't remember which script it was [05:24] x11-common.postrm [05:24] I'll have you review before I put in any changes [05:25] thanks for the heads up. [05:25] this is why I think the scripts should be in /usr/share/X11 or something [05:25] probably so [05:25] and leave /etc/X11/Xsession.d for the admin [05:26] yeah I think too much gets in /etc/X11 in general [05:27] I should probably fix mesa too at some point.. there's this script for fglrx which is obsolete, and the removal isn't handled properly [05:28] did you notice the comment about libdrm changelog? [05:28] looks like you edited the 2.4.5-1 entry [05:29] hum, shower-> [05:29] no missed that [06:20] tjaalton: what was the problem? [07:05] bryce: see the commit diff: http://git.debian.org/?p=pkg-xorg/lib/libdrm.git;a=commitdiff;h=cf2534023a3fdce5b7a44b50d76defaa78ff78be [07:07] two missing changelog entries from 2.4.5-1 [07:08] ah sorry [07:09] boy, git and I really don't get along. [07:10] well it's due to a merge error, and no VCS could get it right :) [07:11] normally I'll first take what's in debian and then apply our changes on top of it [07:11] using meld [07:11] the sad thing is that the libdrm merge was worthless anyway, because -intel still won't build [07:12] but nouveau can be synced now :) [07:12] depends on some 2-line change needed in kernel drm code :-( [07:12] that's how it's going to be in the future [07:13] although it's been mostly an issue with intel, since they are changing things all the time [07:13] a stable driver? haha [07:13] yeah I know. I talked with tim about it yesterday and today [07:13] it's going to suck [07:14] someone from the kernel team should monitor the upstream drm code I guess [07:14] but maybe it's too much overheaed [07:14] -e [07:15] well, I guess if the changelog was the only thing messed up in the merge, that's pretty good, I worried more that there was something wrong in the .install's or something [07:22] did you bump the version in rules? (dh_makeshlibs -plibdrm2 -V'libdrm2 (>= 2.4.5)) [07:23] afaik no new symbols were added since 2.4.3, which is what debian has [07:27] I did bump the version, however I didn't know if that was needed or not [07:30] it'll make drivers built against this version not work with 2.4.3 while they should, but it's not a huge issue [07:31] meaning packages will depend on libdrm 2.4.5 and fail to install if only 2.4.3 is available [16:22] wow, https://bugs.edge.launchpad.net/~ubuntu-x-swat/+packagebugs is messed up [16:22] is there general broken-ness in the evtouch input driver at the moment? I am getting xorg blowing up on calibrate [16:24] * popey has asked his mate to file bug 341215 [16:24] Launchpad bug 341215 in xf86-input-evtouch "[Jaunty] calibration crashes xorg on HP TX1000" [Undecided,New] https://launchpad.net/bugs/341215 [16:27] popey: did you look in lp? [16:27] there is a couple of older reports that claim to be fixed [16:29] popey: then afaik there is no general brokenness. [16:30] bryce_: guess that depends how common the evtouch is [16:30] you've not provided enough info in your bug report to say [16:30] what's needed? [16:30] http://wiki.ubuntu.com/X/Reporting [16:30] i used ubuntu-bug so expected that to attach everything [16:31] I think it's not set up for -evtouch [16:31] I probably should fix that [16:31] want me to file a bug? :) [16:32] nah I'm fixing it presently [16:32] ta [16:34] just realised this is using binary nvidia, bryce_ , should I test with nv too? [16:35] yep; if it's an -nvidia problem there's hardly anything we can do [16:36] ok, will test under both [16:37] btw, why do you use -nvidia? [16:38] its not my pc [16:38] but the user is new to ubuntu, and i think he likes the 3d desktop stuff [16:39] hmm [16:39] if you and he ever feel like experimenting, there is also the -nouveau driver [16:40] we don't officially support it in canonical yet, but it's been getting lots of improvements lately and in karmic we may be looking at relying on it more [16:40] it would be interesting to hear if it works adequately for people's needs yet [16:44] yeah, thats an idea [16:44] didn't even realise it was packaged [16:44] yep [16:45] ok, added a bunch more x packages for apport support to our git tree. once alpha6 freeze is over it'll get uploaded. [16:48] thanks [16:51] ok, bryce_ it happens with -nv too [16:52] good, so it's something we can presumably fix [16:53] make sure the bug report has the necessary info (Xorg.0.log, lshal, etc.) [16:54] popey: also, did you try -evdev with this device? It doesn't work with all input devices but it'll probably become the universal input driver going forward [16:54] I think it doesn't handle touch devices very well yet though [16:54] bryce_: not yet [16:55] ok, worth trying just in case [16:55] bryce_: will go back there and get all the debug stuff, need to add dbgsyms etc to get a meaningful trace i guess [16:55] yep [16:55] thanks for the help [16:55] sure, I'll subscribe to the bug to catch the updates for you [16:56] s/for/from/