[09:04] <bugabundo_work> hi
[09:05] <bugabundo_work> bug #269904 and its dupes is at it again! it was fixed for me up until yesterday
[09:13] <elmargol> Hi i still have a very anoying nvidia related bug #270617 can someone help me to triage this bug please?
[09:14] <bugabundo_work> isn't that a dupe of  bug #269904, elmargol ?
[09:16] <elmargol> bugabundo_work: no this is different
[09:40] <bugabundo_work> good morning tseliot
[09:40] <tseliot> bugabundo_work: good morning
[09:43] <bugabundo_work> I guess you will a full morning with the re-appearing refresh probs of nvidia driver, enh tseliot ?
[09:43] <bugabundo_work> bug #269904
[09:45] <elmargol> http://launchpadlibrarian.net/17626936/P1000269.JPG <- thats how the desktop looks if the driver crashes
[09:47] <bugabundo_work> xiii
[09:47] <bugabundo_work> that's bad
[09:47] <tseliot> bugabundo_work: Aaron Plattner (from NVIDIA) replied there
[09:47] <bugabundo_work> never  saw that one before
[09:47] <tseliot> that's not something I can fix
[09:47] <bugabundo_work> ah thanks tseliot
[09:47] <bugabundo_work> it wasn't there when I checked it this morning
[09:48] <bugabundo_work> and since kdepim went belly up, I can't check my email either
[09:49] <elmargol> bugabundo_work: i try setting the cpu to powersave now.. .lets see if this fixes the issue
[10:06] <tjaalton> wgrant: success! my server hangs now just like yours :)
[10:07] <tjaalton> hmm, will rebuild the server too
[10:07] <tjaalton> oh, ssh still works
[10:08] <wgrant> tjaalton: I was beginning to suspect -synaptics, but I guess this discounts that.
[10:10] <elmargol> crashes again :(
[10:11] <elmargol> God why didn't I buy intel :(
[10:13] <tjaalton> wgrant: yep
[10:15] <tjaalton> wgrant: it could still be just a problem of wrong order of builds
[10:15] <tjaalton> (gdb) bt full
[10:15] <tjaalton> #0  0x0817cb06 in XIGetDeviceProperty ()
[10:15] <tjaalton> No symbol table info available.
[10:15] <tjaalton> #1  0x0817e5c2 in ProcXGetDeviceProperty ()
[10:16] <tjaalton> I'll rebuild the server and driver
[10:16] <wgrant> Hmm.
[10:16] <wgrant> Interesting.
[10:17] <wgrant> We definitely want to get the deps and conflicts right before the primary upload.
[10:18] <tjaalton> oh really?-)
[10:18] <tjaalton> and they should be, but probably not on my PPA
[10:18] <wgrant> Actually, deps and breaks.
[10:19] <wgrant> Hmmm.
[10:20] <wgrant> Will it let old input drivers stick around, or does it utilise some virtual package like video drivers/
[10:20] <tjaalton> what does?
[10:20] <wgrant> The input drivers' dependencies on an Xserver ABI.
[10:21] <tjaalton> if they use properties, they need to be rebuilt
[10:21] <tjaalton> so that's only synaptics and evdev
[10:21] <tjaalton> for now..
[10:21] <wgrant> Right, but do we need to manually add a Breaks on them to xserver-xorg?
[10:21] <wgrant> Or people who only partially upgrade are going to be very broken.
[10:21] <wgrant> I recall seb128 was last time.
[10:22] <wgrant> And it'll be worse now that we have lots of users.
[10:22] <tjaalton> yes, some safeguard must be in place
[10:22] <elmargol> Maybe I should downgrade to the hardy kernel :(
[10:23] <tseliot> elmargol: why downgrade?
[10:23] <tjaalton> elmargol: then you can't use the nvidia blob at all
[10:23] <elmargol> well I can use the nvidia driver from the nvidia site...
[10:24] <tjaalton> sure
[10:24] <tseliot> what's the problem?
[10:27] <elmargol> bug #270617
[10:27] <elmargol> bug #278029 
[10:28] <tjaalton> does it work with another OS?
[10:28] <elmargol> tjaalton: it works using hardy
[10:31] <tjaalton> k
[10:31] <elmargol> Later this day I try to boot it on my Desktop PC... it has a different nvidia gpu lets see if this fixes it
[10:44] <tjaalton> wgrant: think I found the problem.. XIGetProperty changes were not properly backported.. will change and rebuild to see for sure
[10:48] <wgrant> tjaalton: Aha. That would do it. Thanks for tracking this down.
[10:49] <tjaalton> wgrant: man, this is messed up :)
[10:49] <tjaalton> what was I thinking
[10:49] <tjaalton> at the time..
[10:50] <wgrant> tjaalton: That's good in this case... at least it's now obvious!
[10:51] <wgrant> Are you going to be at UDS?
[10:51] <tjaalton> wgrant: it's currently at the hands of my boss
[10:51] <tjaalton> or is it 'in', bah
[10:51] <wgrant> 'in' is correct.
[10:52] <wgrant> Unfortunate.
[10:52] <tjaalton> heh, I always get them wrong
[10:52] <tjaalton> (the first time, like backports)
[10:52] <wgrant> Haha.
[10:53] <wgrant> I hope I didn't stuff syndaemon up too much.
[10:53] <tjaalton> I would've taken some vacation if he could've just said 'no' in time
[10:57]  * wgrant is glad to have exams over a couple of weeks before it, and no deadlines for work at uni until the start of first semester next year.
[11:03] <tjaalton> hmm, one line missing from the function
[11:04] <tjaalton> handler = handler->next;
[11:04] <tjaalton> no wonder it ended up in a loop
[11:05] <tjaalton> there was another commit on top of the original patch, that was backported as well. that's why it looked worse
[11:06] <wgrant> Ahahahah.
[11:06] <wgrant> That would do it.
[11:18] <tjaalton> yeah, success!
[11:19] <tjaalton> I'll check my ppa and update it as necessary
[11:19] <wgrant> Nice!
[11:21] <tjaalton> so if it hung with my ppa, that means inputproto and libxi are fine
[11:22] <tjaalton> and the safeguards.. libxi should be fine to update, but the drivers should depend on the new xserver
[11:23] <crevette> https://bugs.launchpad.net/ubuntu/+source/xorg-server/+bug/280671
[11:23] <crevette> wow there is an interesting patch to commit
[11:24] <tjaalton> crevette: probably just pull everything from the 1.5-branch, including that
[11:24] <crevette> tjaalton: ah you're so extrem :)
[11:24] <crevette> :)
[11:24] <crevette> I though you would be more conservative
[11:24] <tjaalton> it's not that extreme, those have been in master for some time
[11:25] <tjaalton> and cherry-picked on 1.5
[12:03] <tjaalton> wgrant: hm, would adding Breaks: synaptics/evdev (<= current) for xserver-xorg-core do the trick?
[12:05] <wgrant> tjaalton: That's what I'd recommend.
[12:11] <tjaalton> wgrant: actually, bumping the serverminver is enough
[12:11] <tjaalton> hmm or maybe not, since just installing the server would break things
[12:12] <wgrant> tjaalton: Exactly.
[12:12] <wgrant> You need to use Breaks.
[12:12] <tjaalton> I'll do both
[12:13] <wgrant> Has the libXi ABI been bumped?
[12:13] <tjaalton> shlibs? yes
[12:14] <wgrant> It's removing symbols, so it probabably officially needs an ABI bump. But the users of those fragments of the API are so few that we can work around it.
[12:14] <tjaalton> right
[12:22] <jcristau> better add conflicts, in this case
[12:22] <jcristau> or breaks, or whatever
[12:23] <tjaalton> against the current xserver? will do
[12:23] <tjaalton> what's the difference with breaks and conflicts anyway?
[12:23] <jcristau> no, packages using the property ABI
[12:24] <jcristau> conflicts is more heavyweight
[12:25] <jcristau> it means the packages can't be unpacked at the same time, which is fine when you have file conflicts, but not necessary if you just want to say they don't work together, so want to force an upgrade
[12:25] <jcristau> with breaks, both can be unpacked, just not configured, iirc
[12:26] <tjaalton> but isn't unpack enough to break things?
[12:26] <wgrant> Breaks is appropriate here.
[12:26] <wgrant> Conflicts would be used if we didn't have Breaks.
[12:31] <tjaalton> ok, so adding Breaks: evdev, synaptics, g-c-c, g-s-d, xinput
[12:33] <jcristau> tjaalton: you should have Breaks on drivers in the server, and Breaks on clients in libxi6
[12:34] <tjaalton> jcristau: oh right
[12:34] <tjaalton> this was for libxi
[12:40] <wgrant> Synaptics build-deps on libxi - does it use it?
[12:40] <wgrant> I know that because my syndaemon port didn't need any new builddeps.
[12:41] <jcristau> pretty sure synaptics_drv.so doesn't
[12:41] <jcristau> but, maybe something else in the package
[12:45] <tjaalton> wgrant: I'll upload xorg-server -1ubuntu2.2 to my ppa so you can start working on g-c-c and g-s-d
[12:47] <tjaalton> done
[12:48] <tjaalton> I won't upload the new libxi with breaks, since you wouldn't be able to install it :)
[12:50] <wgrant> tjaalton: OK, great. I'll hopefully be able to work on them tonight, depending on whether I can get this uni work done...
[12:50] <wgrant> It's only a little bit more difficult without having XQueryDeviceProperty available.
[12:51] <tjaalton> k, cool
[12:51] <wgrant> Alpha 7 is in a week, isn't it?
[12:51] <tjaalton> RC
[12:52] <wgrant> Isn't RC a week before release?
[12:52]  * wgrant checks the release schedule.
[12:52] <tjaalton> hmm, right
[12:52] <wgrant> Oh.
[12:52] <tjaalton> but we already have a beta
[12:52] <wgrant> No Alpha 7 this cycle.
[12:53] <wgrant> I'm sure we had one once.
[12:53] <wgrant> Ah.
[12:54] <wgrant> Feisty Herd 6 was post-beta.\
[12:54]  * wgrant is outdated.
[14:00]  * wgrant upgrades to tjaalton new X.
[14:02] <wgrant> tjaalton: The evdev in your PPA is too old.
[14:17] <tjaalton> bah
[14:17] <tjaalton> i'll update it when i get back from lunch
[14:20] <wgrant> Thanks.
[14:32] <tjaalton> wgrant: uploaded
[14:32] <wgrant> tjaalton: Great.
[14:45] <wgrant> tjaalton: Hmm, did you mean to build-dep on something not in your PPA? It depwaited everywhere.
[14:45] <tjaalton> damn
[14:45] <wgrant> Heh.
[14:47] <tjaalton> fixed, xserver-xorg-dev build-dep was too high
[14:47] <wgrant> Yep.
[16:05] <mvo> hm, #ubuntu+1 talks about problem with the kernel module of 177.80 - is that known?
[16:07] <tjaalton> mvo: elmargol has some display corruption issues
[16:08] <elmargol> I have the same install running on my desktop now. Lets see if it works using this card
[16:14] <elmargol> runns 30 min just fine now :/
[16:15] <tjaalton> ooh, aaronp commented on one nvidia bug
[16:15] <tjaalton> not the first time either, it seems
[16:16] <elmargol> the problem is sometimes it works 2 hour just fine.. and sometimes it crashes after 10 minutes :/
[16:16] <elmargol> not easy to debug
[16:21] <CarlFK> (II) NVIDIA GLX Module  177.80  Wed Oct  1 15:06:06 PDT 2008         compiled for 4.0.2, module version = 1.0.0
[16:21] <CarlFK> (EE) NVIDIA(0): Failed to load the NVIDIA kernel module!
[16:21] <CarlFK> ibex, worked 2 days ago, did an upgrade, broke.  is this known?
[16:22] <elmargol> CarlFK: 177.80 is new
[16:22] <tjaalton> dmesg error would be more useful
[16:23] <CarlFK> tjaalton: i don't see anything nvidia related in dmesg 
[16:23] <tjaalton> try to modprobe nvidia
[16:23] <CarlFK> FATAL: Module nvidia not found.
[16:23] <tjaalton> there you go
[16:23] <tjaalton> and here I go ->
[16:24] <tseliot> CarlFK: install the linux-headers for your kernel and then type: sudo apt-get install --reinstall nvidia-177-kernel-source
[16:25] <tseliot> mvo: what kind of problem?
[16:25] <CarlFK> tseliot: any point in reporting on lp?
[16:26] <tseliot> CarlFK: no, as long as my suggestion solves the problem
[16:28] <CarlFK> linux-headers-2.6.27-6 set to manually installed.
[16:28] <CarlFK> --force or something ?
[16:29] <tseliot> type: dkms add -m nvidia -v 177.80 -k $(uname -r)
[16:29] <tseliot> dkms build -m nvidia -v 177.80 -k $(uname -r)
[16:29] <CarlFK> Error! DKMS tree already contains: nvidia-177.80
[16:29] <tseliot> dkms install -m nvidia -v 177.80 -k $(uname -r)
[16:29] <tseliot> and let me know what happens
[16:30] <CarlFK> Error! Could not locate nvidia.ko for module nvidia in the DKMS tree.
[16:30] <CarlFK> You must run a dkms build for kernel 2.6.27-6-generic (i686) first.
[16:30] <tseliot> mvo: did you read my email on Update Manager?
[16:31] <tseliot> CarlFK: you skipped this: dkms build -m nvidia -v 177.80 -k $(uname -r)
[16:31] <tseliot> then you will have to type: dkms install -m nvidia -v 177.80 -k $(uname -r)
[16:31] <CarlFK> tseliot: ﻿(10:29:33 AM) CarlFK: Error! DKMS tree already contains: nvidia-177.80
[16:31] <CarlFK> that was the result of ﻿dkms build ...
[16:32] <tseliot> yes, wasn't it the result of dkms add?
[16:32] <CarlFK> ahh, sorry
[16:32] <CarlFK> yeah, it's building now
[16:32] <mvo> tseliot: about the removal of the wacom stuff?
[16:33] <tseliot> mvo: yes, and of input devices in general
[16:33] <mvo> tseliot: still not properly, sorry :(
[16:34] <mvo> but there is a update-manager update pending for this week, it can go into this I think
[16:34] <tseliot> mvo: good
[16:35] <CarlFK> tseliot: DKMS: install Completed. - trying x now
[16:35] <CarlFK> X booting.  thanks.
[16:36] <tseliot> CarlFK: I don't know why it didn't rebuild the module automatically
[16:47] <elmargol> yay 1 hour and no crash :D
[18:14] <superm1> hum it appears "safe graphics mode" does nothing useful on live cds now.  It doesn't seem to modify xorg.conf to be vesa'full at least
[18:20] <pwnguin> superm1: apparently you neglect kubuntu harder than kubuntu neglects bluetooth ;)
[18:21] <superm1> pwnguin, how so?
[18:21] <tjaalton> see the planet :)
[18:21] <pwnguin> you should check the planet
[18:21] <superm1> oh no, should i be scared...
[18:21] <pwnguin> heh
[18:23] <superm1> in my own defense, I *did* send an email to kubuntu-devel, and I asked ScottK to look at it.  the lack of response was assumed to be "it works"
[18:41] <tjaalton>  
[18:41] <tjaalton> uh
[18:43] <bryce> morning
[18:43] <bryce> tjaalton: can you reproduce comment #21 in bug #280646?  It's working ok on my system
[18:45] <tjaalton> bryce: I left my laptop at work..
[18:45] <bryce> ah too bad
[18:47] <bryce> tjaalton: offhand do you know if -evdev is responsible for reporting keyboard state changes to hal?  I.e. should I be digging through -evdev source, or maybe xkeyboard-config?
[18:47] <bdmurray> what is the status of bug 261977 now?
[18:48] <tjaalton> bdmurray: waiting for new properties API prepared for upload
[18:48] <tjaalton> bryce: can't tell, reading the bug first
[18:49] <jcristau> bryce: -evdev reports key presses to the X server, that's pretty much it..
[18:49] <bdmurray> tjaalton: thanks I hadn't seen an update after mario's comment
[18:49] <tjaalton> bdmurray: right, I'll update it
[18:50] <tjaalton> bdmurray: all that's needed is for wgrant to port g-c-c and g-s-d to the new API, then we can upload
[18:50] <tjaalton> bdmurray: oh wait..
[18:50] <tjaalton> bdmurray: that wasn't the bug I thought it was
[18:51] <bryce> jcristau: and then they get exposed from the xserver to hal directly?  Or is there another component translating between them?
[18:51] <jcristau> no
[18:52] <jcristau> the x server sends keypress/keyrelease events to x11 clients
[18:52] <bryce> so, there's an x11 client that listens for numlock events and updates hal accordingly?  
[18:53] <jcristau> i have no idea why hal would care about numlock, but, yeah, i guess
[18:54] <jcristau> if you want to know when someone presses XF86MonBrightnessUp, you need an X client grabbing that key
[18:55] <tjaalton> bdmurray: so, what happens is that since the server doesn't find a match in the nv.ids (matchDriverFromFiles()), it'll still try videoPtrToDriverName, which is just wrong
[18:55] <tjaalton> vPTD will match the pci-id to nv
[18:58] <tjaalton> I'd love to have a commit in upstream, but wonder if someone will beat me to it ;)
[19:01] <tjaalton> could have a patch ready tomorrow
[19:05] <tjaalton> maybe the best fix would be to append the fallback drivers anyway, so it would try to use them next
[19:05] <bdmurray> tjaalton: thanks for looking at it
[19:06] <tjaalton> since the logic is currently right..
[19:06] <tjaalton> bdmurray: np
[19:07] <tjaalton> hmm, fixing this would make it possible to simplify failsafe
[19:07] <bryce> :-D
[19:07] <tjaalton> this is basically what jcristau suggested some time ago
[19:08] <tjaalton> since now the fallback works only if you don't have the conffile
[19:57] <tjaalton> sweet, 2135 bugs
[20:33] <bryce> tjaalton: :-/
[20:34] <bryce> tjaalton: I was planning on doing some major triaging work today, but I think this thinkpad brightness key issue is going to take up that time
[20:35] <bryce> tjaalton: btw, I can reproduce the problem sort of like this:
[20:35] <bryce> 1.  use brightness keys -> OCD displays, brightness changes
[20:35] <bryce> 2.  toggle numlock on
[20:35] <bryce> 3.  use brightness keys -> brightness changes, but no OCD is displayed
[20:36] <bryce> jcristau: are you able to reproduce that on debian by chance?
[20:36] <jcristau> i'm not using gnome on my laptop
[20:58] <bryce> tjaalton: I'm thinking about writing two scripts - one to get all Xorg bugs in state New without attachments and ask them to attach the usual, and another script to query all incomplete without response older than 30 days with no attachments and close them.
[21:46] <tjaalton> bryce: heh, that should help a bit
[21:46] <tjaalton> also, l-r-m-2.6.20 bugs can be closed soon
[21:46] <tjaalton> but that's only ~130 bugs
[21:46] <bryce> tjaalton: all of them?  and are they to be set to invalid or wontfix?
[21:47] <tjaalton> well feisty will be EOL'd, so wontfix maybe
[21:52] <tjaalton> bryce: I'll try the numlock-thing tomorrow
[21:52] <tjaalton> bryce: btw, push your changes to xorg ;)
[21:52] <bryce> tjaalton: ok, I've built an instrumented patch here - http://bryceharrington.org/ubuntu/EvdevBug280646/
[21:52] <bryce> bah git
[21:52] <bryce> ok
[21:53] <tjaalton> evdev is in git too
[21:53] <tjaalton> I think..
[21:53] <tjaalton> duh, isn't
[21:54] <tjaalton> but I've got a tree to push
[21:54] <bryce> bryce@chideok:~/src/xorg/xorg-ubuntu-git$ git push
[21:54] <bryce> To ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/debian/xorg.git
[21:54] <bryce>  ! [rejected]        debian-unstable -> debian-unstable (non-fast forward)
[21:54] <bryce> error: failed to push some refs to 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/debian/xorg.git'
[21:54] <tjaalton> you've changed debian-unstable?
[21:55] <tjaalton> git push origin ubuntu
[21:59] <bryce> oh yeah
[21:59] <bryce> $ git push origin ubuntu
[21:59] <bryce> Everything up-to-date
[21:59] <bryce> uncommitted changelog entrye
[22:00] <bryce> -e +pushed
[22:00] <tjaalton> yes, it got there
[23:06] <superm1> bryce, you there?
[23:07] <bryce> yeah
[23:07] <superm1> bryce, i've gotten word that the libstdc++5 thing won't be resolved in whatever fglrx package will be entering intrepid at some point
[23:07]  * wgrant curses user-settable input properties.
[23:08] <bryce> superm1: ok thanks
[23:08] <wgrant> If you're going to spend 40 minutes debugging why g-s-d thinks all input devices are touchpads, ensure that you didn't introduce and fix a bug earlier that sets the property we use to detect a touchpad on all of them...
[23:09] <bryce> wgrant: ow
[23:09] <wgrant> I was wondering why XGetDeviceProperty was saying those properties existed... of course they actually did.