[01:10] <bryce> tjaalton: are you around?  Do you have this bug on your X60?  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=407188
[01:10] <ubottu> Debian bug 407188 in acpi-support "Laptop gets stuck after sleep" [Grave,Closed] 
[05:28] <tjaalton> bryce: yes, but it's a fairly recent regression, and tracked in bug 269884
[05:28] <ubottu> Launchpad bug 269884 in linux "thinkpad x61 intermittently hangs on resume with 2.6.27-3" [High,Triaged] https://launchpad.net/bugs/269884
=== superm1|away is now known as superm1
[09:44] <Ng> bah, just had an X lockup unlocking the screensaver. I thought that was gone :(
[09:45] <tjaalton> my kernel crashed during the session, after a successful resume
[09:46] <Ng> erk
[09:47] <Ng> I really hope the intel situation settles down at some point soon, there seems to be way too much changing for it to remain remotely stable :/
[09:48] <tjaalton> we need intrepid users ;)
[10:18] <Ng> tjaalton: the only people I can encourage to upgrade are all thinkpad users ;)
[10:28] <crevette> tjaalton, Ng what do you want to test ?
[10:28] <crevette> I'm a thinkpad user in intrepid
[10:28] <crevette> s/in/on/
[10:29] <Ng> I don't have anything specific, and I'm running Intrepid on a thinkpad - I meant that I don't know anyone else I can encourage to upgrade for testing purposes, who isn't on basically the same hardware as tjaalton or me ;)
[10:30] <Ng> but I would like the X wedge on screensaver unlock to be fixed
[10:30] <Ng> tjaalton: do you think this could be the same thing as the vblank thing which crashed it when activating the screensaver?
[10:30] <crevette> I had my thinkpad recently, so Iwas always ion intrepid
[10:31] <crevette> I just disable splash because irt caused problem
[10:31] <Ng> by the point it crashes the display is on, I've typed my password and it's drawn the background, so it's kinda surprising that it gets stuck at all
[11:10] <tjaalton> wgrant: see bug 274728, anything missing?
[11:10] <ubottu> Launchpad bug 274728 in xserver-xorg-input-synaptics "Update the input properties API to current version" [Undecided,New] https://launchpad.net/bugs/274728
[11:12] <wgrant> tjaalton: The only other things I can think of are g-c-c and g-s-d.
[11:12] <tjaalton> wgrant: right, thanks
[11:13] <wgrant> tjaalton: Did you also see that somebody replied that the new MaxTapMove default didn't fix multi-finger tapping for them?
[11:13] <wgrant> But that my package did... I'm very, very confused.
[11:13] <wgrant> Because the MaxTapMove change did fix it for me.
[11:14] <tjaalton> wgrant: no, I've ignored synaptics for a couple of days :)
[11:14] <wgrant> tjaalton: Probably a good policy.
[11:16] <tjaalton> hehe
[11:53] <tjaalton> wgrant: I think I found out why some synaptics users got errors from xinput.. the patch for xserver looks incomplete
[12:13] <wgrant> tjaalton: Ah, that would do it! RAOF suffers from the problem, if you need a sane tester.
[12:14] <wgrant> What's missing?
[12:14] <tjaalton> wgrant: I'm not sure though, since the code is a mystery to me :) but it's in Xi/extinit.c. SProcIDispatch doesn't add the same stuff as ProcIDispatch does
[12:14] <tjaalton> I'm backporting the changes and noticed that
[12:45] <tjaalton> wgrant: hm, same thing with SReplyIDispatch
[12:46] <wgrant> tjaalton: I'll be interested to see if this fixes it... do you have an ETA for porting the infrastructure?
[12:47] <wgrant> And do we know how those bits were missed?
[12:48] <tjaalton> wgrant: inputproto & libxi done, xserver WIP
[12:49] <tjaalton> I've asked whot if they were left out on purpose
[12:49] <tjaalton> waiting for a reply
[12:49] <wgrant> tjaalton: Ah, excellent. I'll fix g-c-c and g-s-d tomorrow.
[12:50] <tjaalton> wgrant: it's unclear if they get in beta
[12:50] <tjaalton> but.. sooner the better
[12:50] <wgrant> True.
[13:30] <Kano> hi, which package is used to map the volume and other media keys to the XF86Audio symbols?
[13:44] <tjaalton> in gnome? gnome-control-center
[13:45] <wgrant> Doesn't that just map them to actions?
[13:45] <seb128> tjaalton: no, GNOME doesn't map keysym to symbols
[13:45] <tjaalton> oh right
[13:45] <seb128> that's an xkeyboard-config thing rather
[13:46] <tjaalton> I thought he asked about the shortcuts
[13:46] <seb128> the GNOME dialog justs associations actions to those
[13:46] <tjaalton> yep
[13:46] <tjaalton> trust me, I've looked at x-c enough for the week ;)
[13:48] <Kano> well i can do similar things with xmodmap, but where is it done with ubuntu or the lenny
[13:48] <tjaalton> it's a complicated issue and no-one has the right answer :)
[13:49] <tjaalton> but if the keys produce events, then xkeyboard-config just needs to support them
[13:52] <Kano> well they are already supported, just the keys are not mapped by default in etch
[13:53] <Kano> xmodmap -e "keycode 160 = XF86AudioMute" -e "keycode 174 = XF86AudioLowerVolume" -e "keycode 176 = XF86AudioRaiseVolume"
[13:53] <Kano> these are the audio keys
[13:53] <Kano> when i do that with etch the keys work
[13:55] <tjaalton> ok
[13:56] <Kano> in #nvidia the devs seem to sleep, nobody answered about my problem
[13:56] <Kano> i guess they only test with tft...
[13:57] <seb128> tjaalton: btw there is plenty if gnome-control-center keyboard bugs which are probably xkeyboard-config issues and could use a somebody having a clue to triage those
[13:57] <Kano> ati x700 (rv410) is pretty bad supported too, but at least there is a pic
[13:58] <tjaalton> seb128: ok, now we only need someone having the clue ;)
[13:58] <seb128> tjaalton: you? ;-)
[13:58] <tjaalton> <whistle>
[14:01] <tjaalton> seb128: I believe all the "error activating XKB configuration" bugs are fixed in intrepid
[14:04] <tjaalton> seb128: I'll have a quick look at them
[14:04] <seb128> tjaalton: thanks
[14:25] <jcristau> Kano: set the appropriate xkb model and the keys will work
[14:26] <Kano> in etch? which one
[14:26] <jcristau> the one that maps the keycodes to the right keysym for your keyboard
[14:27] <Kano> why is the same config different when using lenny?
[14:27] <jcristau> because it's not the same version of stuff
[14:27] <jcristau> duh
[14:28] <Kano> is it possible to backport it?
[14:39] <Ng> hmm, I think it would be nice if X kept more than two log files
[14:40] <Ng> if you end up bouncing into failsafe it seems like you can lose the log which might have useful information in it
[14:41] <jcristau> failsafe may want to start with a different display number
[14:41] <Ng> unless there are lots of vt changing bugs that might make that break more, it sounds sane, but even so i think keeping 5 or 6 would be a good idea
[14:41] <Ng> it's not like they're huge files. other stuff in /var/log/will be much bigger and hang around for much longer
[14:42] <Ng> (I say this because I just had it wedge on unlocking again and I had to ssh in from my phone to make sure I keep a copy of the log)
[14:48] <tjaalton> if it could use syslog (with a nice prefix to distinguish different servers), then it would be trivial to use logrotate
[14:48] <tjaalton> and some wrapper to filter the logfile out
[15:41] <Ng> tjaalton: I think syslog is too old and broken for that to be much fun ;/
[15:42] <tjaalton> Ng: syslog-ng then?-)
[15:43] <Ng> tjaalton: I hate that thing
[15:43] <Ng> mainly because it has "-ng" in the name, and so triggers irssi highlighting ;)
[15:43] <Ng> but also it's still not all that great
[15:43] <tjaalton> heh, ok
[15:43] <tjaalton> I liked the syslogd in Tru64
[15:45] <jcristau> i think debian switched to rsyslog as default for lenny. no idea how good it is though.
[15:45] <Ng> it is a typical piece of unix idiocy that we have a central logging system that's unused by so many things :/
[15:45] <Ng> because the thing is 800 years old and really stupid ;)
=== superm1 is now known as superm1|away
[16:30] <seb128> did anybody there broke xvfb in intrepid?
[16:30] <seb128> there is some uploads which ftbfs on "Xvfb failed to start" errors now
=== superm1|away is now known as superm1
[16:41] <seb128> hello, anybody around?
[16:44] <mvo> tseliot: I get a debconf note about "obsolete NVIDIA driver" on my system that tells me that I need to install nvidia-glx-177 (also that one is installed already) - is that expected behaviour?
[16:45] <tseliot> mvo: yes, we have to deal with the case in which users dist-upgrade from the command line
[16:45] <tseliot> I'm always open to better solutions though
[16:46] <tseliot> mvo: and of course the debconf warning will bug you only if you have a driver with the old name scheme installed
[16:46] <mvo> tseliot: aha, ok. so I just ensure in update-manager that the oldnames get removed?
[16:46] <tseliot> e.g. nvidia-glx, nvidia-glx-{new| legacy}
[16:47] <tseliot> mvo: yes, right
[16:48] <mvo> tseliot: thanks, adding that
[16:49] <tseliot> mvo: ok, let me know if you need help with, say, X-Kit or nvidia common
[16:52] <mvo> tseliot: I hope its all more or less ready, real-world testing is going to be the important next thing
[17:03] <tseliot> yes, right
[17:31] <jcristau> seb128: looks like Xvfb gets in an infinite loop trying to open swrast_dri.so which doesn't exist
[17:32] <seb128> jcristau: likely something easy to fix? or should we rather disable the xvfb use for now?
[17:32] <jcristau> don't know yet
[17:32] <jcristau> seb128: you could pass -extension GLX, or build-dep on libgl1-mesa-dri, to work around it
[17:37] <jcristau> hah. the client runs fine, then when it exits Xvfb tries to regen and loops.
[17:38] <bryce> 274234 - wow, first evidence of the new failsafe-X usefulness
[17:39] <jcristau> seb128: other option, have xvfb-run pass -terminate to Xvfb
[17:43] <bryce> Ng: are you testing Intrepid?  the new failsafe mode writes its X session to Xorg.failsafe.log now
[17:47] <seb128> bryce: could you look at fixing xvfb-run? it breaks build which are blocker fix for intrepid beta
[17:48] <Ng> bryce: that's an exceptionally good point. The thing is I'm sure I've managed to hit a situation on my machine at home where it failed to start X on boot and eventually fell into failsafe, but when I rebooted and it started X properly, the original failure log was lost
[17:49] <jcristau> seb128: looks like i tracked it down. not sure what the correct fix is, but.
[17:49] <seb128> jcristau: me neither, and I would prefer to somebody who has a clue about xorg to decide about that ;-)
[17:50] <Ng> bryce: will it try failsafe the first time the server fails to start, or could it have tried X a few times before running failsafe-X?
[17:50] <seb128> I mean I would prefer having somebody fixing it rather than applying a workaround
[17:50] <bryce> Ng: well if you can reproduce it I can take a look.  The change I made was about a week or so ago, so if your machine was running an older Intrepid, it might not have had the new feature
[17:51] <Ng> bryce: I'll upgrade the machine over the weekend, but it's really hard to reproduce its problems, they're very random :/
[17:51] <bryce> Ng: gdm normally tries to boot X three times in a row, and invokes failsafe only after that
[17:51] <bryce> Ng, failsafe mode can be forcibly triggered by setting your driver to "foobar"
[17:52] <jcristau> i'll try to talk to krh
[17:52] <Ng> bryce: so if the first run failed and wedged the graphics card such that any further attempts failed for different reasons, you'd lose the original log?
[17:52] <bryce> seb128: can it wait until monday?  I'm actually off work today and will be going away to the beach for the weekend
[17:53] <bryce> Ng: hmm, possibly so
[17:53] <Ng> bryce: I'm suspecting that's what happened, it seems to be very unhappy about running X again after it's screwed up once
[17:53] <seb128> bryce: well, that means intrepid will not be installable until monday, bad timing, I'll workaround the issue in the applications using xvfb-run by commenting the calls
[17:54] <bryce> Ng: well what you might do is shut down gdm and run it via startx, so it runs just once; then you can reproduce the problem and capture the log directly
[17:55] <Ng> bryce: sure, this was more about the potential for losing valuable X logs than the particular brands of madness which infect the X4000 driver ;)
[17:55] <Ng> bryce: I think it should rotate them a bit more and keep 5 or 6 :)
[18:00] <bryce> hmm
[18:01] <bryce> well, this seems like a pretty rare corner case, but probably wouldn't be hard to implement - mind filing a wishlist bug against xorg-server?
[18:02] <Ng> ok :)
[18:23] <seb128> jcristau: a build-dep on libgl1-mesa-dri would workaround the xvfb issue for sure? just pondering between doing that or commenting the call ;-)
[18:25] <jcristau> yes, it would. as would passing -extension GLX, or -noreset, to Xvfb
[18:29]  * seb128 read the xvfb-run manpage
[20:24]  * mvo grumbles about the nvidia driver
[22:02] <tjaalton> bryce: enjoy the beach :)
[22:03] <mvo> oh, beach
[22:04] <tjaalton> mvo: what now?-) (about nvidia)
[22:04]  * mvo wants a beach as well - and icecream!
[22:05] <mvo> tjaalton: it make my life difficult, I think I had both nvidia-glx-new and -177 installed, then I removed -new and I think that caused my kernel module to disappear (but I'm not sure about this, but the X log claimed it could not laod the nvidia module)
[22:05] <tjaalton> mvo: urgh
[22:06] <mvo> yeah, fglrx does not like me either, I have it removed (but not purged) and when I try to purge it the diverts fall all over
[22:06] <mvo> but I'm too tired today to debug it further
[22:06] <tseliot> mvo: weird, nvidia-glx-177 conflicts with/replaces nvidia-glx-new
[22:07] <tjaalton> nothing a dash of Bowmore couldn't cure
[22:07] <mvo> tseliot: strange, maybe it was nvidia-glx-legacy? I can't quite remember, but I can check the logs
[22:07] <tjaalton> I'm still struggling with the properties backport for our xserver.. some bits missing
[22:09] <tseliot> mvo: it's still weird. Have a look at nvidia-glx-177 Conflicts and Replaces
[22:10] <tseliot> http://pastebin.com/d92c28be
[22:11] <mvo> hm, right
[22:11]  * mvo scrachtes head
[22:12] <mvo> tseliot: aha! I think I have the reason, I purged nvidia-glx-new (when it was already removed) 
[22:12] <mvo> hm, at least that is my theory
[22:13] <tseliot> mvo: and what did that cause?
[22:14] <tseliot> or where did it remove the module from?
[22:15] <tseliot> mvo: the kernel module is not supposed to be in the lrm any more. Have a look  at /var/lib/dkms/nvidia/177.76/2.6.27-4-generic/i686/module/
[22:15] <tseliot> or something similar
[22:15] <mvo> I just looked at the postrm of nvidia-glx-new and there is nothing in it that could have caused this afaics - so maybe it was something different. I will try to reporduce it tomorrow or later tonight I think
[22:18] <tseliot> ok
[22:44] <tjaalton> oh cool, the xorg-server with current properties backported built successfully