brycetjaalton: are you around?  Do you have this bug on your X60?  http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=40718801:10
ubottuDebian bug 407188 in acpi-support "Laptop gets stuck after sleep" [Grave,Closed] 01:10
tjaaltonbryce: yes, but it's a fairly recent regression, and tracked in bug 26988405:28
ubottuLaunchpad bug 269884 in linux "thinkpad x61 intermittently hangs on resume with 2.6.27-3" [High,Triaged] https://launchpad.net/bugs/26988405:28
=== superm1|away is now known as superm1
Ngbah, just had an X lockup unlocking the screensaver. I thought that was gone :(09:44
tjaaltonmy kernel crashed during the session, after a successful resume09:45
NgI 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:47
tjaaltonwe need intrepid users ;)09:48
Ngtjaalton: the only people I can encourage to upgrade are all thinkpad users ;)10:18
crevettetjaalton, Ng what do you want to test ?10:28
crevetteI'm a thinkpad user in intrepid10:28
NgI 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:29
Ngbut I would like the X wedge on screensaver unlock to be fixed10:30
Ngtjaalton: do you think this could be the same thing as the vblank thing which crashed it when activating the screensaver?10:30
crevetteI had my thinkpad recently, so Iwas always ion intrepid10:30
crevetteI just disable splash because irt caused problem10:31
Ngby 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 all10:31
tjaaltonwgrant: see bug 274728, anything missing?11:10
ubottuLaunchpad bug 274728 in xserver-xorg-input-synaptics "Update the input properties API to current version" [Undecided,New] https://launchpad.net/bugs/27472811:10
wgranttjaalton: The only other things I can think of are g-c-c and g-s-d.11:12
tjaaltonwgrant: right, thanks11:12
wgranttjaalton: Did you also see that somebody replied that the new MaxTapMove default didn't fix multi-finger tapping for them?11:13
wgrantBut that my package did... I'm very, very confused.11:13
wgrantBecause the MaxTapMove change did fix it for me.11:13
tjaaltonwgrant: no, I've ignored synaptics for a couple of days :)11:14
wgranttjaalton: Probably a good policy.11:14
tjaaltonwgrant: I think I found out why some synaptics users got errors from xinput.. the patch for xserver looks incomplete11:53
wgranttjaalton: Ah, that would do it! RAOF suffers from the problem, if you need a sane tester.12:13
wgrantWhat's missing?12:14
tjaaltonwgrant: 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 does12:14
tjaaltonI'm backporting the changes and noticed that12:14
tjaaltonwgrant: hm, same thing with SReplyIDispatch12:45
wgranttjaalton: I'll be interested to see if this fixes it... do you have an ETA for porting the infrastructure?12:46
wgrantAnd do we know how those bits were missed?12:47
tjaaltonwgrant: inputproto & libxi done, xserver WIP12:48
tjaaltonI've asked whot if they were left out on purpose12:49
tjaaltonwaiting for a reply12:49
wgranttjaalton: Ah, excellent. I'll fix g-c-c and g-s-d tomorrow.12:49
tjaaltonwgrant: it's unclear if they get in beta12:50
tjaaltonbut.. sooner the better12:50
Kanohi, which package is used to map the volume and other media keys to the XF86Audio symbols?13:30
tjaaltonin gnome? gnome-control-center13:44
wgrantDoesn't that just map them to actions?13:45
seb128tjaalton: no, GNOME doesn't map keysym to symbols13:45
tjaaltonoh right13:45
seb128that's an xkeyboard-config thing rather13:45
tjaaltonI thought he asked about the shortcuts13:46
seb128the GNOME dialog justs associations actions to those13:46
tjaaltontrust me, I've looked at x-c enough for the week ;)13:46
Kanowell i can do similar things with xmodmap, but where is it done with ubuntu or the lenny13:48
tjaaltonit's a complicated issue and no-one has the right answer :)13:48
tjaaltonbut if the keys produce events, then xkeyboard-config just needs to support them13:49
Kanowell they are already supported, just the keys are not mapped by default in etch13:52
Kanoxmodmap -e "keycode 160 = XF86AudioMute" -e "keycode 174 = XF86AudioLowerVolume" -e "keycode 176 = XF86AudioRaiseVolume"13:53
Kanothese are the audio keys13:53
Kanowhen i do that with etch the keys work13:53
Kanoin #nvidia the devs seem to sleep, nobody answered about my problem13:56
Kanoi guess they only test with tft...13:56
seb128tjaalton: 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 those13:57
Kanoati x700 (rv410) is pretty bad supported too, but at least there is a pic13:57
tjaaltonseb128: ok, now we only need someone having the clue ;)13:58
seb128tjaalton: you? ;-)13:58
tjaaltonseb128: I believe all the "error activating XKB configuration" bugs are fixed in intrepid14:01
tjaaltonseb128: I'll have a quick look at them14:04
seb128tjaalton: thanks14:04
jcristauKano: set the appropriate xkb model and the keys will work14:25
Kanoin etch? which one14:26
jcristauthe one that maps the keycodes to the right keysym for your keyboard14:26
Kanowhy is the same config different when using lenny?14:27
jcristaubecause it's not the same version of stuff14:27
Kanois it possible to backport it?14:28
Nghmm, I think it would be nice if X kept more than two log files14:39
Ngif you end up bouncing into failsafe it seems like you can lose the log which might have useful information in it14:40
jcristaufailsafe may want to start with a different display number14:41
Ngunless 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 idea14:41
Ngit's not like they're huge files. other stuff in /var/log/will be much bigger and hang around for much longer14:41
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:42
tjaaltonif it could use syslog (with a nice prefix to distinguish different servers), then it would be trivial to use logrotate14:48
tjaaltonand some wrapper to filter the logfile out14:48
Ngtjaalton: I think syslog is too old and broken for that to be much fun ;/15:41
tjaaltonNg: syslog-ng then?-)15:42
Ngtjaalton: I hate that thing15:43
Ngmainly because it has "-ng" in the name, and so triggers irssi highlighting ;)15:43
Ngbut also it's still not all that great15:43
tjaaltonheh, ok15:43
tjaaltonI liked the syslogd in Tru6415:43
jcristaui think debian switched to rsyslog as default for lenny. no idea how good it is though.15:45
Ngit is a typical piece of unix idiocy that we have a central logging system that's unused by so many things :/15:45
Ngbecause the thing is 800 years old and really stupid ;)15:45
=== superm1 is now known as superm1|away
seb128did anybody there broke xvfb in intrepid?16:30
seb128there is some uploads which ftbfs on "Xvfb failed to start" errors now16:30
=== superm1|away is now known as superm1
seb128hello, anybody around?16:41
mvotseliot: 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:44
tseliotmvo: yes, we have to deal with the case in which users dist-upgrade from the command line16:45
tseliotI'm always open to better solutions though16:45
tseliotmvo: and of course the debconf warning will bug you only if you have a driver with the old name scheme installed16:46
mvotseliot: aha, ok. so I just ensure in update-manager that the oldnames get removed?16:46
tseliote.g. nvidia-glx, nvidia-glx-{new| legacy}16:46
tseliotmvo: yes, right16:47
mvotseliot: thanks, adding that16:48
tseliotmvo: ok, let me know if you need help with, say, X-Kit or nvidia common16:49
mvotseliot: I hope its all more or less ready, real-world testing is going to be the important next thing16:52
tseliotyes, right17:03
jcristauseb128: looks like Xvfb gets in an infinite loop trying to open swrast_dri.so which doesn't exist17:31
seb128jcristau: likely something easy to fix? or should we rather disable the xvfb use for now?17:32
jcristaudon't know yet17:32
jcristauseb128: you could pass -extension GLX, or build-dep on libgl1-mesa-dri, to work around it17:32
jcristauhah. the client runs fine, then when it exits Xvfb tries to regen and loops.17:37
bryce274234 - wow, first evidence of the new failsafe-X usefulness17:38
jcristauseb128: other option, have xvfb-run pass -terminate to Xvfb17:39
bryceNg: are you testing Intrepid?  the new failsafe mode writes its X session to Xorg.failsafe.log now17:43
seb128bryce: could you look at fixing xvfb-run? it breaks build which are blocker fix for intrepid beta17:47
Ngbryce: 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 lost17:48
jcristauseb128: looks like i tracked it down. not sure what the correct fix is, but.17:49
seb128jcristau: me neither, and I would prefer to somebody who has a clue about xorg to decide about that ;-)17:49
Ngbryce: 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
seb128I mean I would prefer having somebody fixing it rather than applying a workaround17:50
bryceNg: 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 feature17:50
Ngbryce: I'll upgrade the machine over the weekend, but it's really hard to reproduce its problems, they're very random :/17:51
bryceNg: gdm normally tries to boot X three times in a row, and invokes failsafe only after that17:51
bryceNg, failsafe mode can be forcibly triggered by setting your driver to "foobar"17:51
jcristaui'll try to talk to krh17:52
Ngbryce: 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
bryceseb128: can it wait until monday?  I'm actually off work today and will be going away to the beach for the weekend17:52
bryceNg: hmm, possibly so17:53
Ngbryce: I'm suspecting that's what happened, it seems to be very unhappy about running X again after it's screwed up once17:53
seb128bryce: 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 calls17:53
bryceNg: 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 directly17:54
Ngbryce: 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
Ngbryce: I think it should rotate them a bit more and keep 5 or 6 :)17:55
brycewell, 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:01
Ngok :)18:02
seb128jcristau: a build-dep on libgl1-mesa-dri would workaround the xvfb issue for sure? just pondering between doing that or commenting the call ;-)18:23
jcristauyes, it would. as would passing -extension GLX, or -noreset, to Xvfb18:25
* seb128 read the xvfb-run manpage18:29
* mvo grumbles about the nvidia driver20:24
tjaaltonbryce: enjoy the beach :)22:02
mvooh, beach22:03
tjaaltonmvo: what now?-) (about nvidia)22:04
* mvo wants a beach as well - and icecream!22:04
mvotjaalton: 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
tjaaltonmvo: urgh22:05
mvoyeah, fglrx does not like me either, I have it removed (but not purged) and when I try to purge it the diverts fall all over22:06
mvobut I'm too tired today to debug it further22:06
tseliotmvo: weird, nvidia-glx-177 conflicts with/replaces nvidia-glx-new22:06
tjaaltonnothing a dash of Bowmore couldn't cure22:07
mvotseliot: strange, maybe it was nvidia-glx-legacy? I can't quite remember, but I can check the logs22:07
tjaaltonI'm still struggling with the properties backport for our xserver.. some bits missing22:07
tseliotmvo: it's still weird. Have a look at nvidia-glx-177 Conflicts and Replaces22:09
mvohm, right22:11
* mvo scrachtes head22:11
mvotseliot: aha! I think I have the reason, I purged nvidia-glx-new (when it was already removed) 22:12
mvohm, at least that is my theory22:12
tseliotmvo: and what did that cause?22:13
tseliotor where did it remove the module from?22:14
tseliotmvo: 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
tseliotor something similar22:15
mvoI 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 think22:15
tjaaltonoh cool, the xorg-server with current properties backported built successfully22:44

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!