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