[00:00] <bryceh> imbrandon, Sarvatt, please review that page and if you can spot ways to improve it please edit
[00:00] <RAOF> bryceh, Sarvatt: Yeah, that ubuntu-lucid branch is an attempt to pull back glx 1.4 without the clutter crash or memory leak, particularly if we found that somethings had come to depend on 1.4.  I didn't want it only sitting on my local system. :)
[00:01] <bryceh> morning RAOF
[00:01] <RAOF> Good morning
[00:01] <imbrandon> bryceh: cool will do here very shortly
[00:08] <bryceh> RAOF, fwiw what I've done in such situations in the past is chunk it into a ppa
[00:08] <bryceh> that way it's available/backedup and easy to test
[00:09] <bryceh> (which I'm sure has already been done in this case)
[00:11] <RAOF> Yup :)
[00:29] <Sarvatt> bryceh: will look it over in a bit, been working 
[00:30] <Sarvatt> bryceh: btw mandriva does have xserver 1.7/2.6.32 support for poulsbo now, thats what someone linked a day or two ago
[00:31] <Sarvatt> and holy crap the package infrastructure for poulsbo is nuts, 7-8 packages?
[00:31] <RAOF> How do they manage that?
[00:32] <Sarvatt> http://blino.org/blog/mandriva/poulsbo-xserver1.7.html
[00:32] <RAOF> Kernel module, DDX, maybe libdrm extension…
[00:32] <Sarvatt> then xserver libglx and libdri in seperate packages too..
[00:34] <RAOF> And then mesa driver, presumably.
[00:34] <RAOF> That's still 6 :)
[00:34] <Sarvatt> yup and firmware
[00:35] <RAOF> Ah, of course!
[00:35] <bryceh> sheesh
[00:36] <Sarvatt> psb-firmware xserver-xorg-video-psb libdrm-psb psb-kernel-source xpsb-glx libgl1-mesa-dri-psb and a change to libdrm for psb symbols
[00:38] <Sarvatt> just needs packaging changes to work with alternatives and to drop a load of patches on most parts, the tarballs are still the same old ones from hardy
[00:40] <bryceh> I say Mandriva can win -psb
[00:43] <Sarvatt> hah I said "just"
[00:49] <Sarvatt> if anyone has a psb netbook they can bring to UDS I can probably be convinced to make it all work there :)
[00:57] <bryceh> Sarvatt, you could put a call out on ubuntu-devel@
[00:57] <bryceh> Sarvatt, or ask tseliot, he probably knows how to get one for testing
[01:33]  * bryceh hrms at 5bug #68779
[01:48] <RAOF> Has the flock of canaries patch made it into upstream yet?  Those users seem quite happy with the 2.6.34-rc5 kernel daily packgaes.  Let's check…
[01:58] <bryceh> RAOF, what are your thoughts on bug #568779 ?
[02:04] <RAOF> It's a bit scattered, isn't it?  We knew that there were going to be *some* pepole with 855 cards who'd have problems.  This will end up being a duplicate of bug #541511, won't it?
[02:04] <bryceh> RAOF, yeah probably
[02:05] <RAOF> Some get fixed by re-enabling kms, some get fixed with vesa, some… :(
[02:19] <jg>  a random walk through an N dimensional space.
[02:19] <RAOF> Not guaranteed to end up at the starting position.
[02:20] <jg> yup.
[02:20] <jg> RAOF, or even terminate, as I saw in beta 2.
[02:21] <jg> Thankfully, I get a new toy tomorrow, and won't care much anymore about the RS600 POS.
[02:22] <jg> new laptop is somewhere in the air between Louisville, KY and Boston at this instant, according to UPS.
[02:24] <bryceh> if only manufacturers would stop making new hardware, it would make our lives so much easier
[02:25] <jg> bryceh: heh.  I may have a different set of problems, but I can get keithp to fix them if I do ;-).
[02:25] <jg> first time I've gotten to select my own laptop in 3-4 years.
[02:27] <jg> bryceh: note my RS600 problem is hardware that I got over 18 months ago: it's hardly in the new category.
[02:35] <RAOF> bryceh: Or even just make new hardware without crazy architectural differences would be nice.  It can't be *that* hard to preserve the modesetting interface across generations, surely :)
[02:41] <bryceh> if only manufacturers would stop making hardware, it would make our lives so much easier
[02:42] <bryceh> we have 0 bug reports about the abacus after all
[02:57] <jg> bryceh: but then you'd be stuck with old braindamage forever, which is equally bad and frustrating.  You'd have to support broken POS for aeons, rather than merely half a decade or so.
[02:59] <jg> bryceh: for example, trying to make mode setting work on old ISA cards would be a unique form of water torture.
[03:06] <bryceh> ok
[03:06] <bryceh> if only manufacturers would stop making old hardware, it would make our lives so much easier
[03:07] <jg> now that we've gotten rid of all new hardware and all old hardware, we'll all set to use semi-obsolete systems ;-)
[03:07] <bryceh> jg, you know, it's kind of an achilles heel of FOSS, that each year brings an increase to the amount of hardware out there that needs supported, and any upstream change to X risks breaking at least *some* random selection of HW
[03:08] <jg> bryceh: yeah, and if not enough people care, it stays broken.  I don't think I'll probably cry hard if the RS600 stays broken indefintely, though having the tablet working would be sort of nice...
[03:10] <jg> would help to have a more obvious business model on the desktop side to enable funding of random hardware maintenance, though.  There are times FOSS's business models are insufficient, at least at current scale.
[03:12] <jg> now 10x the desktop/laptop market share would go along way toward fixing that problem.
[03:12] <bryceh> yeah, the business model seems to work well enough for when someone is actively selling the bit of hardware, since money flows  consumer -> hw manufacturer -> OS vendor
[03:12] <jg> as we have on the server side, for quite a while.
[03:13] <jg> Still hard on the desktop side, though not as dismal as it used to be.
[03:13] <bryceh> but when its hw no longer being sold, there isn't $$ flowing around, since the OS can be had without purchasing it, so support is entirely OSV good will
[03:13] <jg> bryceh: yeah, server production deployments force that on the server side.
[03:14] <bryceh> right, where service contracts are purchased, there is a money flow
[03:14] <jg> RH is based on that...
[03:14] <bryceh> on the desktop it seems users aren't accustomed to buying technical support contracts or whatever
[03:15] <bryceh> I'd say 9 out of 10 bug reports that we see on X would really probably be better classified as tech support requests (well, 'help requests' at least)
[03:15] <jg> bryceh: the microsoft ecology is that there is no real support available other than the local IT guys, child or  neighbor; you just throw out the machine and buy a new one if you ever upgrade it.
[03:16] <jg> ever try to deal with Microsoft to get help with any of their software?
[03:16] <bryceh> heh true enough
[03:17] <jg> I went through *five* releases of Microsoft Word, unable to reliably convert a document to plain ascii, and couldn't get them to fix it, even when I had contacts in the office group who tried to do so for me.
[03:17] <jg> oh, for the ability to even generate a stack trace to be able to give them......
[03:18] <bryceh> given that, it amazes me how outraged bug reporters get when someone doesn't reply to their bug report right away
[03:18] <jg> bryceh: you are dealing with the lunatic fringe of people, in several dimensions.
[03:20] <jg> unless you are a very big microsoft customer, with a really serious bug, it's almost impossible to get them to pay attention, even if you have "support".
[03:21] <jg> most of the support that isn't "community" is forced back on the hardware vendors who supply the crack to the addicts.
[03:22] <jg> I'm amused, 8 years later, that HP is buying a company that does Linux based handhelds.  The lack of vision is stunning.
[03:23] <jg> 8 years ago, the only Linux handhelds were HP iPAQ's, period, done by HP/former Compaq people.
[03:24] <jg> maybe it's 10 years now.
[03:24] <bryceh> heh
[03:25] <jg> now, if they'd given us 10 % of the 1.2 billion they are playing for Palm, they might be somewhere in phones or handhelds.
[03:26] <rafiyr> Someone actually bid on palm?
[03:26] <jg> If I'm bitter, just ignore me.
[03:26] <jg> yes. HP.
[03:26] <rafiyr> Guess I should look at the news once in a while.
[03:27] <jg> http://www.nytimes.com/2010/04/29/technology/29palm.html?ref=global-home
[03:27] <jg> instead, they cleverly laid off everyone who had caused the first linux handheld devices to run Linux....
[03:28] <bryceh> jg, very penny-wise of them
[03:29] <jg> heh.  pound foolish, and took pounds out of keithp's and my hide, among others.
[03:30] <jg> (like jamey hicks, and andrew christian and so on).
[03:34] <jg> well, good night; hopefully I wont have too many adventures with my nice new laptop tomorrow....
[04:06] <bryceh> night
[06:46] <vish> Sarvatt: hi.. I'm using the mainline kernel .33 and it doesnt seem to require the quirk new_pll=0  [RV515]
[06:46] <vish> 2.6.33-02063303-generic
[06:53] <vish> hmm , is KMS on by default in mainline kernel.. how do i check?
[06:57] <RAOF> Does /sys/bus/pci/devices/$YOUR_CARDS_PCI_ADDR/controlD exist?  If so - you're using kms.
[06:58] <RAOF> I'd expect kms to be on by default in the 2.6.33 mainline kernel; I haven't checked though.
[06:58] <RAOF> You can also check /var/log/Xorg.0.log; drivers tend to say whether they're using KMS
[07:00] <vish> yeah , the /var/log/Xorg.0.log  shows   (II) [KMS] Kernel modesetting enabled.
[09:09] <RAOF> Oooh!  I just saw one of those thinkpad x200s+compiz powersave=1 sync flashes!  My hardware *isn't* totally unaffected :)
[10:33] <ara> do you guys think this bug should be an xorg one instead? 
[10:33] <ara> bug 569214
[18:02] <bryceh> ara, impossible to say without more info.  if they're using i855 graphics it could be just a dupe of the 8xx kms bug
[18:03] <ara> bryceh, ok, thanks
[18:07] <Sarvatt> vish: really? do you have any idea when the flickering started with the ubuntu kernels?
[18:07] <Sarvatt> vish: do you have the 2.6.32-19 kernel to try by any chance?
[18:10] <vish> Sarvatt: i have tried with 32-19 as well , if i use new_pll=0 on boot there is no problem , but the problem arises after ~6hrs 
[18:10] <vish> , seems it runs out of magic
[18:12] <Sarvatt> interesting, how about 2.6.32-16? that one should be a clean backport of 2.6.33's drm
[18:12] <vish> Sarvatt: but with .33 i'm not using new_pll=0 and after~19hrs I dont have *any* problems
[18:13] <vish> yeah , thats -16 was the next thing i wanted to test.. havent tested it yet..
[18:14] <vish> was actually expecting problems with .33 , surprising  , /several/ problems seem solved.. 
[18:14] <Sarvatt> is it 2.6.33 with a karmic config or a lucid config?
[18:15] <vish> lucid one
[18:15] <Sarvatt> ah its karmic, they didnt make any 2.6.33's with lucid's config
[18:16] <bryceh> sweet, there's a cache coherency patch
[18:17] <Sarvatt> vish: 2.6.32-16 would be really interesting if you could test it, if that fails then the problem is outside of drm 
[18:18] <vish> Sarvatt: isnt this the lucid one?  > http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/
[18:18] <vish> thats the one i'm using
[18:18] <Sarvatt> oh thats totally different, we dont have .3 yet in lucid
[18:18] <Sarvatt> that means your problem will be fixed by the next SRU :)
[18:18] <Sarvatt> awesome
[18:18] <vish> yay! :)
[18:20] <Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/v2.6.33.3-lucid/CHANGES
[18:20] <Sarvatt> something in there fixed it
[18:20] <vish> Sarvatt: just curious ,which kernel did you mean initially?  [i thought those were the only mainline ones]
[18:20] <bryceh> Sarvatt, have you packaged kernel patches before?
[18:21] <Sarvatt> you said 2.6.33 and i didnt look at the kernel version you posted to notice it was 2.6.33.3
[18:21] <Sarvatt> bryceh: not in a PPA :(
[18:21] <bryceh> hmm
[18:21] <vish> ah , cool
[18:21] <bryceh> some day I need to learn that
[18:21] <Sarvatt> i dont know how to bump the abi right for a PPA
[18:21] <Sarvatt> yeah same here
[18:21] <Sarvatt> been saying that for months now but i never get around to it :)
[18:22] <Sarvatt> vish: just curious, how is your monitor connected?
[18:23] <Sarvatt> oh wait its a laptop isnt it
[18:23] <vish> yeah , Acer laptop
[18:23] <Sarvatt> just ruling out commits that it could be
[18:26] <bryceh> Sarvatt, oh... this patch is just the "This is the most horrible hack I've ever written" patch we already knew about
[18:26] <bryceh> (I think, lemme doublecheck)
[18:28] <Sarvatt> bryceh: 2.6.33.3 fixes PAL tv problems with KMS, wrong gamma values with radeon when using a DVI-VGA adapter, washed out images over tv out on radeon - bug 548709 
[18:28] <bryceh> great
[18:29] <Sarvatt> i've seen bugs for all of those but have to dig them up
[18:30] <Sarvatt> noting on that bug that its fixed in 2.6.33.3
[18:32] <Sarvatt> vish: I have no idea what fixed it in your case..
[18:32] <Sarvatt> hopefully it's not some agp or pci problem that wont be in the next kernel :(
[18:33] <vish> Sarvatt: do you want me to test 32-16 too?
[18:33] <Sarvatt> nah that was just because I thought you were saying the 2.6.33 kernel fixed it
[18:34] <Sarvatt> (not 2.6.33.3)
[18:34] <vish>  this 33.3 is totally awesome! :D  i earlier had minor memory problems , songs used stutter when wallpaper changed , and all sorts of things.. but now *poof*!  
[18:35] <vish> xorg cpu would just spike fo 2secs when wallpaper changed
[18:35] <vish> for*
[18:37] <Sarvatt> i hope http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-lucid.git;a=commit;h=ae2e767a2b2be23d6131cf463f3de730014dc070 isn't the cause of that cus that patch isn't upstream, they reverted it because of problems..
[18:39] <Sarvatt> vish: do you have the bug number for your flickering problems handy by any chance?
[18:40] <Sarvatt> it's against linux so i'm having problems finding it in the noise with my slow net connection
[18:40] <vish> Sarvatt: i didnt file one separately since you mentioned it was a known bug..
[18:40] <Sarvatt> yeah i thought you might be subscribed to it or something, no worries
[18:41] <vish> Sarvatt: i think this is the one closet to mine > Bug #541501
[18:41] <Sarvatt> https://bugs.launchpad.net/bugs/570394 -- i need to turn my reply there into a stock reply since most every nvidia bug is just because of that problem :)
[18:43] <bryceh> Sarvatt, heh
[18:43] <bryceh> Sarvatt, if that's true, it makes me wonder if we could programmatically identify and dupe those bugs
[18:43] <bjsnider> man, that fails to make sense. there's no way you can install nvidia-current that it doesn't update the alternatives to use its own glx
[18:43] <bryceh> Sarvatt, I've sent apw an email asking for a kernel ppa with that patch
[18:44]  * hyperair quickly gets his fix of xorg-edgers after upgrading to luci
[18:44] <hyperair> d
[18:44] <bryceh> Sarvatt, although maybe find a bug that was not filed against kubuntu to dupe against
[18:56] <Sarvatt> hyperair: finally did it eh? :)
[18:56] <hyperair> Sarvatt: my exams just ended today =)
[18:58] <Sarvatt> bjsnider: yeah it's got me wondering too, i'm guessing theres some way of updating that fails to do it currently
[18:59] <bjsnider> Sarvatt, either the postinst script is failing to run, or another script is running later that's resetting the glx alternative
[19:00] <Sarvatt> like installing after having installed the drivers from nvidia.com manually at some point with files left behind or something else that people forget to mention in bug reports :)
[19:00] <hyperair> Sarvatt: so.. now that hal is gone, how do i configure my synaptics things?
[19:00] <bjsnider> Sarvatt, well, they could be lying about that, yes.
[19:01] <Sarvatt> hyperair: easiest way is to just edit /usr/lib/X11/xorg.conf.d/whatever-synaptics.conf and add Option "foo" "whatever"
[19:02] <hyperair> Sarvatt: not /etc?
[19:02] <Sarvatt> yeah I know its bad advice to tell people to edit that but its the easiest :)
[19:02] <jcristau> hyperair: /etc/X11/xorg.conf
[19:02] <Sarvatt> hyperair: correct way would be to just add the options to xorg.conf
[19:02] <hyperair> Sarvatt: aah okay, thanks.
[19:02] <jcristau> hyperair: add a InputClass section with MatchIsTouchpad "on"
[19:02] <hyperair> jcristau: thanks
[19:02] <jcristau> and whatever options
[19:02] <hyperair> aha. i see why my touchpad was acting weird now.
[19:03] <Sarvatt> man synaptics has all the options and man xorg.conf tells you the structure
[19:03] <hyperair> for some reason, xserver-xorg-input-synaptics got removed during upgrade
[19:03] <hyperair> this was the most borked upgrade of ubuntu i've ever had
[19:03] <Sarvatt> oh wait you're on edgers so it's /usr/share/X11 anyway :D
[19:03] <Sarvatt> hyperair: hope you used ppa-purge xorg-edgers before upgrading..
[19:03] <hyperair> Sarvatt: i didn't. *groan*
[19:03] <Sarvatt> i put a big fat warning on the page about that
[19:04] <hyperair> Sarvatt: the difference is... i don't heed warnings =D
[19:04] <hyperair> no, what i really meant is i know enough to recover from borked upgrades
[19:04] <Sarvatt> ppa removal seriously needs  happen in the update process instead of just disabling PPA's
[19:04] <hyperair> the hit-or-miss part is making sure the system still boots after upgrade
[19:04] <hyperair> after that i'm fine \o/
[19:05] <Sarvatt> i dont know where to start hooking it in
[19:05] <hyperair> hooking?
[19:05] <hyperair> ah
[19:05] <hyperair> yes, that's true.
[19:05] <hyperair> you should talk to mvo about this.
[19:06] <Sarvatt> hyperair: good thing you reactivated xorg-edgers right after upgrading because things would have been horribly broken :)
[19:06] <Sarvatt> mesa is totally different in lucid
[19:06] <Sarvatt> and the karmic version is higher
[19:07] <hyperair> Sarvatt: er no actually..
[19:08] <hyperair> Sarvatt: i didn't. X worked by chance.
[19:08] <hyperair> Sarvatt: right now i'm still downloading PPA packages
[19:08] <hyperair> 162 of them @_@
[19:08] <Sarvatt> with no GL i'm sure :)
[19:08] <Sarvatt> hyperair: were you using the blob or is that your intel machine?
[19:08] <Sarvatt> curious if the nvidia-current in xorg-edgers works, haven't tried it yet
[19:08] <hyperair> Sarvatt: this is my intel machine.
[19:09] <hyperair> Sarvatt: my nvidia machine is several hundred miles away
[19:09] <Sarvatt> bryceh: scanning xorg.0.log on all nvidia-graphics-drivers bugs for (II) Loading /usr/lib/xorg/modules/extensions/libglx.so as candidates for the stock reply would w ork :)
[19:10] <Sarvatt> ahh back to work i go
[19:33] <Sarvatt> what are the useful logs from a release upgrade again?
[19:33] <Sarvatt> asking the person  in that nvidia bug if he can attach them and hopefully see where it went wrong. /var/log/apt/term.log and /var/log/dpkg.log? wasn't there another log or two just for the dist release process?
[19:42] <jcristau> mvo would probably know
[19:42] <Sarvatt> hmm wonder if its possible /usr/lib/xorg/extra-modules doesn't exist at the point where its setting up the alternatives
[19:43] <Sarvatt> libgl1-mesa-glx is what makes it
[19:44] <Sarvatt> oh weird nevermind, mesa is making /usr/lib/xorg/x11-extra-modules
[19:44]  * Sarvatt is confused
[19:45] <Sarvatt> what the heck is  /usr/lib/xorg/x11-extra-modules, xorg-server only checks  /usr/lib/xorg/extra-modules additionally
[19:48] <bryceh> dunno
[19:48] <bryceh> Sarvatt, I used my new script to grep out all the nvidia-graphics-drivers bugs with that libglx.so path in them
[19:48] <bryceh> :-)
[19:49] <bryceh> looks like it flagged a couple dozen bugs, I'm going through them now
[19:49] <bryceh> some it appears were filed against nvidia-graphics-drivers but the user booted into an open source driver to file the report, so not all are actually dupes of the alternatives bug
[19:50] <bryceh> also, I'm thinking I should set up a MASTER bug report for this, as none of these flagged bug reports are really that well made
[19:50] <bryceh> well, maybe they're dupes of bug #522328
[19:56] <Sarvatt> good idea! having them all in one place will make finding out the problem easier since i cant seem to reproduce it, wish tseliot was around to pick his brain because the alternatives are a maze. really want to see someones dpkg logs from when they upgraded  to see what order things went in. anyone have a karmic machine they are about to upgrade to lucid that could reproduce? :)
[19:57] <bryceh> yeah I've been a bit disappointed he hasn't been that active here this release
[19:59] <bryceh> yeah I'm going to use #522328 as the master for this, I don't want to own this bug ;-)
[19:59] <Sarvatt> bryceh: Failed to initialize the GLX module; please check in your would be a better string to search for
[20:00] <Sarvatt> would only be in these specific bugs
[20:00] <bryceh> oh
[20:00] <bryceh> rats...
[20:00] <bryceh> alright rerunning...
[20:01] <Sarvatt> wait what the heck, just realized this guys log has timestamping - (EE) Apr 26 20:59:18 NVIDIA(0): Failed to initialize the GLX module; please check in your X
[20:01] <Sarvatt> ahh ok the nvidia messages all have timestamping even if the rest of the log doesnt
[20:02] <bryceh> ahh
[20:02] <bryceh> weird
[20:03] <bryceh> wish the script didn't take so long to run...
[20:03] <Sarvatt> /usr/lib/mesa/ld.so.conf - priority 500
[20:03] <Sarvatt>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
[20:03]  * bryceh drums fingers
[20:03] <Sarvatt> i dont understand the x11-extra-modules, xserver is only set up to look in extra-modules additionally
[20:04] <Sarvatt> oh i guess the alternative links that to extra-modules?
[20:04] <Sarvatt> fglrx uses  slave xorg_extra_modules: /usr/lib/fglrx/xorg
[20:04] <hyperair> Sarvatt: ...i get GPU hangs. whee.
[20:05] <Sarvatt> whee!
[20:05] <Sarvatt> sudo ppa-purge xorg-edgers and see if it happens on lucid, hope not!
[20:07] <Sarvatt> ok i dont think its related to xorg_extra_modules because nvidia_drv.so is in there too and thats loading
[20:09] <Sarvatt> which means the alternatives for nvidia are getting set up properly in the first place, hmm
[20:10] <bjsnider> then something is coming along after and changing them
[20:10] <Sarvatt> nvidia_drv.so wouldn't load if extra-modules was pointing at the mesa version for some reason
[20:11] <Sarvatt> libglx should be in extra-modules right next to nvidia_drv if i'm not mistaken
[20:11] <bjsnider> it would have to be a xserver-xorg package that's installed after the nvidia-current package
[20:11] <bryceh> Sarvatt, hmm, not getting any results from the new search string
[20:12] <Sarvatt> dunno about that because xserver tries to load from extra-modules before the normal one, I think it might just be hitting people reusing an old xorg.conf with something odd in it
[20:13] <Sarvatt> oh yeah
[20:13] <Sarvatt> i think i know what it is
[20:13] <bjsnider> why would the sorg.conf file have anything to do with alternatives?
[20:13] <Sarvatt> crap clients home, gotta run to the next job but i'll be back soon, i know what the problem is
[20:13] <Sarvatt> its the depth section not being in xorg.conf
[20:14] <Sarvatt> i had the same problems when i was trying to autoload nvidia without an xorg.conf
[20:14] <Sarvatt> if you dont have depth 24 it wont load nvidia's libglx and uses the servers
[20:14] <bjsnider> DefaultDepth	24?
[20:14] <Sarvatt> yeah
[20:15] <bjsnider> so they used nvidia-xconfig to create the xorg.conf?
[20:15] <Sarvatt> need to go through the other bugs and compare xorg.conf, might be another option screwing that up like the argbvisuals
[20:16] <bryceh> "Failed to initialize the GLX module" not turning anything up so far... I'll let it keep running though
[20:16] <bjsnider> i'm going to try nvidia-xconfig right now and see if it puts that in there
[20:18] <bjsnider> nvidia-xconfig puts defaultdepth 24 in there too
[20:19] <hyperair> okay, it can't be a gpu hang. i can switch VTs once.
[20:44] <hyperair> Sarvatt: BAH. xserver-xorg keeps hanging >_>
[20:53] <hyperair> blargh. why can't i switch VTs once X hangs in lucid?
[20:54] <bryceh> because it's probably hung in the kernel
[21:01] <hyperair> hmmm
[21:01] <hyperair> but why didn't this kernel have issues with xorg-edgers of karmic?
[21:18] <Sarvatt> looks like my last message didn't go through, but in https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/570394 they have 	Modulepath	"/usr/lib/xorg/modules" making it so /usr/lib/xorg/extra-modules doesn't get used
[21:22] <bjsnider> Sarvatt, they have a modulepath line in the xorg.conf file?
[21:22] <Sarvatt> yup
[21:22] <bjsnider> where in the world...
[21:23] <bjsnider> where are they getting these crazy xorg.conf files
[21:23] <Sarvatt> me? lol
[21:24] <bjsnider> maybe nvidia=xconfig was doing this years ago?
[21:24] <Sarvatt> old nvidia-xconfig and dpkg-reconfigure xserver-xorg
[21:56] <bryceh> Sarvatt, 537648 and 570394 were the only bugs that matched that search string
[22:39] <Sarvatt> thats new, File descriptor 3 (pipe:[141203]) leaked on lvs invocation. Parent PID 29395: /bin/sh when updating grub
[22:39] <Sarvatt> bryceh: ahh ok, both are absolutely the same issue with an invalid xorg.conf
[22:43] <Sarvatt> whats the right place to have the Section "Files" section in xorg.conf removed on upgrade?
[22:48] <Sarvatt> # nvidia-xconfig: X configuration file generated by nvidia-xconfig
[22:48] <Sarvatt> # nvidia-xconfig:  version 1.0  (buildmeister@builder75)  Fri Mar 12 01:42:27 PST 2010
[22:48] <Sarvatt> heh nvidia-xconfig might still be making that invalid xorg.conf..
[22:48] <Sarvatt> http://launchpadlibrarian.net/42386210/XorgConf.txt
[22:49] <Sarvatt> nope, it kept it around from an old xorg.conf when you run it, just ran it and it didn't
[22:51] <Sarvatt> ok *something* relatively current is making that xorg.conf with the modulepath set in it at least, this guy had a fresh install of lucid at alpha 3
[22:54] <Sarvatt> nah he put it there himself cut and pasted from somewhere else and ran nvidia-xconfig after looking at the options
[23:00] <bryceh> Sarvatt, probably just close as invalid or convert to a question
[23:00] <Sarvatt> yep closed them all
[23:04] <bryceh> cool
[23:05] <bryceh> bug 494625 can be made into a standard "your xorg.conf settings aren't right" master bug
[23:05] <Sarvatt> ugh tons of bugs from nvidia people saying visual effects goes back to none after activating nvidia-current!!!!111
[23:06] <Sarvatt> (it requires a reboot and isn't supposed to work right away goobers!) :)
[23:06] <bryceh> sounds like another master bug
[23:06] <Sarvatt> do we have a proprietary drivers wiki?
[23:07] <bryceh> not really, we've got some bits and pieces in the troubleshooting pages
[23:07] <bryceh> would be nice to have though
[23:08] <Sarvatt> i'll start writing up common issues
[23:20] <Sarvatt> http://sarvatt.com/downloads/propdrivers.txt
[23:20] <Sarvatt> got that so far
[23:20] <bryceh> looks good
[23:20] <bryceh> maybe better than a wiki page would be just to have master bug reports for each issue
[23:20] <bryceh> that'd make bug duping a bit simpler, and then we can track the status of the issues
[23:22] <Sarvatt> works for me, trying to find more common issues to add
[23:22] <bryceh> 570498 - installation fails when your disk is out of space (duh!)
[23:23] <Sarvatt> hehe
[23:27] <Sarvatt> hope you dont mind i'm marking it invalid... :D
[23:27] <bryceh> no prob
[23:27] <bryceh> or move to questions
[23:27] <bryceh> wow, making good progress squishing nvidia bugs, down to 137 :-)
[23:28] <Sarvatt> the answer is you need space on your partition to install a package, I would hope thats obvious enough not to have to make a question out of it :)
[23:28] <bryceh> heh
[23:39] <Sarvatt> added a few xorg.conf options to that propdrivers.txt that fix a few other bugs i've come across
[23:39] <Sarvatt> i need to use that  Option "UseEvents" "false" option personally, otherwise i get lots of stalls on my 8400M GS
[23:43]  * bryceh closes out a mess of kubuntu -nvidia bugs with no stack traces provided
[23:44] <Sarvatt> a lot of them are probably karmic too, nvidia-graphics-drivers seems to be the dumping ground kubuntu guys use even though the right package is nvidia-graphics-drivers-180 on karmic :)
[23:44] <bryceh> yep
[23:45] <bryceh> 564129 was the only one with a decent stacktrace, so I left it
[23:45] <bryceh> 128
[23:49] <Sarvatt> wish these kde bug logs weren't useless
[23:50] <Sarvatt> people have problems running apport-collect usually on these ones dumped over from kde ones saying no new information to add
[23:51] <Sarvatt> nothing we can do with just a dependency list and the backtrace thats usually all in qt functions
[23:51] <bryceh> mm, search page on launchpad shows there's now an Expired state
[23:51] <Sarvatt> nice!!
[23:52] <Sarvatt> nVidia driver scrambles Usplash (on lucid)
[23:52] <Sarvatt> kaay
[23:53] <Sarvatt> thats either plymouth or vga16fb's fault anyhow, not nvidia-graphics-drivers
[23:53] <bryceh> yep
[23:56] <Sarvatt> if you set something wontfix, it requires someone in bugcontrol or core-dev to change the status right?
[23:57] <Sarvatt> I'm eyeing https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/565980 which is likely to get changed even though they dont like the response :)