[00:25] <tjaalton>  /away
[00:25] <tjaalton> uh
[09:38] <jcristau> tjaalton: thinking about it, we could only do the xhost trick for local sessions (otherwise you're telling the x server to trust some random user). not sure it's worth it...
[09:39] <jcristau> as in, you need to detect those somewhat reliably
[09:40] <tjaalton> jcristau: running 'id -un' isn't enough?
[09:42] <tjaalton> jcristau: that's what fedora does, allows only the session user to connect
[09:48] <jcristau> in xinit it's ok, since that creates a local session anyway
[09:48] <jcristau> but, if you put that in Xsession.d, you have to handle remote sessions, where `id -un` on the client may not have anything to do with uids on the server
[09:49] <tjaalton> hmm, ok
[11:28] <tjaalton> wgrant: I've now installed the packages from my PPA, and xinput list-props $id just gives me a BadRequest
[11:29] <tjaalton> so something is broken in the backport
[11:32] <jcristau> what's the request id?
[11:32] <wgrant> tjaalton: Ergh.
[11:33] <tjaalton> jcristau: Major 146, minor 41
[11:33] <tjaalton> (XInputExtension)
[11:34] <jcristau> hrm
[11:34] <jcristau> #define X_WarpDevicePointer 41
[11:34] <jcristau> that's XI2
[11:34] <wgrant> Those were just renumbered in XI2...
[11:35] <wgrant> But.
[11:35] <wgrant> Hmm.
[11:35] <wgrant> Hmmm.
[11:35] <jcristau> did you update inputproto, then libxi, then xinput?
[11:36] <tjaalton> I should have, but maybe some build-dep was broken so xinput was built against the old packages
[11:36] <tjaalton> will check
[11:36] <jcristau> 41 used to be GetDeviceProperty
[11:36] <wgrant> Sounds like xinput was built before publishing.
[11:36] <tjaalton> yeah
[11:36] <tjaalton> grr
[11:38] <tjaalton> hmm no, it was built against my versions
[11:38] <wgrant> It's a bit odd that it hardlocks my laptop.
[11:38] <jcristau> and libxi was built against the right inputproto?
[11:38] <tjaalton> just listing the props?
[11:39] <wgrant> tjaalton: Correct.
[11:39] <tjaalton> jcristau: yes..
[11:39] <tjaalton> I need to go through them once more..
[11:39] <wgrant> Well, it did last night, but I've not changed anything since and daren't try again right now.
[13:57] <james_w> tseliot: hi, are you around? I have a system with quite an old nvidia card and jockey doesn't suggest that I may want to install a different driver for it. How can I debug this?
[14:00] <tseliot> james_w: what does jockey do, exactly?
[14:01] <james_w> "No proprietary drivers are in use on this system"
[14:01] <james_w> and nothing listed in the UI at all
[14:02] <james_w> it's correct, but I thought it would show the chance to turn nvidia on
[14:02] <jcristau> james_w: if it's an old card, then that may not be an option?
[14:03] <james_w> it used to be nvidia, were some dropped in Intrepid?
[14:03] <tseliot> james_w: can you put the output of "sudo aptitude search nvidia" in pastebin?
[14:03] <tseliot> maybe some modalias packages are not available
[14:03] <james_w> sure
[14:03] <mvo> james_w: how did you upgrade?
[14:04] <james_w> I don't remember now, it was very early
[14:04] <mvo> I wonder if its driver -71 or -96 were we have no xserver 1.5 support ?
[14:04] <mvo> james_w: aha, ok :) I'm looking for testing feedback of the current upgrader for people with nvidia hardware/drivers
[14:05] <james_w> mvo: it's my second machine, so I'll consider reinstalling hardy and upgrading
[14:06] <james_w> http://paste.ubuntu.com/52840/
[14:06] <tseliot> james_w: nvidia-common wasn't installed during the dist-upgrade
[14:07] <mvo> james_w: aha, ok. that system looks like a good test candidate
[14:07] <tseliot> try installing nvidia-common and then launch jockey again
[14:07] <tseliot> NOTE: don't try to install -71 or 96 (they don't work)
[14:09] <mvo> haven't we blacklisted those yet?
[14:09] <tseliot> mvo: no, not yet
[14:09] <mvo> aha, ok
[14:09] <tseliot> I have worked on the gnome-control-center
[14:09] <james_w> nothing
[14:10] <james_w> the same as before
[14:10] <tseliot> james_w: can I see the output of this command? lspci -n | grep 300
[14:11] <james_w> 02:00.0 0300: 10de:0201 (rev a3)
[14:12] <tseliot> james_w: this is weird. Your card is supported: :/usr/share/jockey/modaliases$ grep 0201 *
[14:12] <tseliot> nvidia-71:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-71
[14:12] <tseliot> nvidia-96:alias pci:v000010DEd00000201sv*sd*bc03sc*i* nvidia nvidia-glx-96
[14:12] <tseliot> did nvidia-common install other packages?
[14:13] <james_w> nvidia-{71,96,173,177}-modaliases
[14:13] <tseliot> e.g. nvidia-96-modaliases, nvidia-71-modaliases
[14:14] <tseliot> ok, try killing jockey-backend
[14:14] <tseliot> and start jockey again
[14:14] <tseliot> ps aux should show jockey-backend
[14:15] <james_w> aha!
[14:15] <james_w> thanks
[14:15] <james_w> but you say don't install 71 or 96?
[14:15] <tseliot> ok, now don't install those drivers
[14:15] <tseliot> they are not compatible with the new Xorg ABI
[14:15] <james_w> are they likely to be fixed by the release?
[14:16] <tseliot> therefore I didn't bother patching them to make them compatible with kernel 2.6.27
[14:16] <tseliot> I have no idea...
[14:16] <james_w> ok, thanks for your help
[14:17] <tseliot> you're welcom
[14:17] <tseliot> e
[17:33] <bryce> whoa, jim gettys reported bug 276782 to launchpda
[17:39] <Ng> heh, shouldn't he be fixing it too? ;)
[17:52] <bryce> ;-)
[18:16] <james_w> hey bryce.
[18:17] <james_w> would you have a moment to look at bug 276680?
[18:17] <james_w> I'm not really sure which component is at fault here
[18:17] <bryce> heya james_w, one sec, looking at a bug for heno atm
[18:17] <james_w> sure, no rush
[18:20] <jcristau> james_w: if he starts X with vga disconnected, the server doesn't allocate a framebuffer big enough for the vga monitor's native resolution
[18:21] <james_w> jcristau: the "Virtual" setting?
[18:21] <jcristau> yeah
[18:22] <jcristau> his first xrandr output says 'maximum 1024 x 1024'; 1280x1024 doesn't fix
[18:22] <jcristau> fit, even
[18:22] <james_w> so the framebuffer allocated depends on what's plugged in when X starts?
[18:22] <jcristau> yes
[18:23] <jcristau> if there's no Virtual directive, anyway
[18:27] <james_w> ok, so close the bug as Invalid and ask him to set a Virtual
[18:29] <jcristau> well, it's still a bug that we can't resize the framebuffer
[18:29] <jcristau> just not one that'll be fixed tomorrow
[18:31] <james_w> thanks
[18:33] <bryce> james_w: yeah if it's the virtual directive stuff, we surely have a bug open on that already; in any case it's an upstream issue
[20:50] <bryce> tjaalton: btw, I've been cherrypicking some -ati patches from current git
[20:50] <bryce> tjaalton: maybe it'd be better to just grab a new snapshot, but release team probably would prefer cherrypicks
[20:50] <tjaalton> bryce: good.. upstream should learn how to release though ;)
[20:52] <bryce> yeah...
[20:52] <bryce> of course then I think I probably should volunteer to help with that...
[20:53] <bryce> I'll be happy if they just apply one or two of my patches ;-)
[20:53] <bryce> http://www.bryceharrington.org/ubuntu/Ati/
[22:16] <tormod> bryce: it seems upstream leaves it all up to the distros to make a stable driver, which of course makes for duplicated work.
[22:17] <tormod> one could say that upstream here is redhat though :)
[22:18] <bryce> :-/
[22:18] <tormod> maybe some people from a couple of distros should make a stable branch and cherry-pick things to it. it doesn't have to be Alex doing that.
[22:18] <bryce> tormod: well in fairness the git tree for -ati currently looks mainly like bug fixes so far
[22:18] <bryce> (although some of the changes in recent weeks are what's caused the bugs)
[22:19] <bryce> hmm, you know, establishing a stable branch might not be a bad idea.
[22:19] <tormod> currently yes, the problem is that you never know before afterwards :)
[22:20] <tormod> if Alex likes the idea, he might be helpful in saying "this should go in stable", or "now the tree is stable, time to branch"
[22:21] <tormod> he likes to think that master is always stable, but it's hard to convince release managers about that.
[22:21] <bryce> yes, he's given that kind of advice for me previously (gutsy iirc)
[22:22] <ion_> Btw, i was under the impression the reason for the ABI change that made some versions of fglrx incompatible with X in intrepid was because of MPX. Since intrepid doesn’t have MPX, what caused the ABI change?
[22:22] <tormod> just having a parallel branch almost like master would help to get things past the RM :) 
[22:24] <tormod> 6.9.0.1 looks much better than 6.9.0+git20080925 :)
[22:25] <bryce> agreed
[22:25] <bryce> hmm, well too late really for intrepid in any case
[22:26] <bryce> (probably...)
[22:26] <bryce> likely a good practice for jaunty tho
[22:26] <bryce> esp if we run into trouble with -fglrx again
[22:27] <ion_> Probably, if the ABI change caused by MPX is yet to come. :-)
[22:29] <bryce> ion_: I heard the X changes that broke -fglrx was the devprivates rework.  Dunno if that involves MPX or not
[22:29] <bryce> afaik the MPX changes still lay in the future
[22:30] <tormod> mpx changes came past 1.5 I think
[22:30] <ion_> Alright, thanks
[22:34] <Ng> tjaalton: do the brightness hotkeys on your thinkpad work?
[22:40] <ion_> They do on mine, if that’s relevant.
[23:42] <jcristau> ion_: most important abi changes from 1.4 to 1.5 are devprivates rework, which was part of the selinux work, and also pci-rework
[23:42] <jcristau> iirc