[00:01] http://pastebin.com/f3e32f86b [00:01] Sarvatt, ^ [00:01] Sarvatt, I have a nvidia closed drivers no so you can see it at the end of dmesg but first time it crashed I haven't have it installed at all. [00:03] I thought I've blacklisted nvidia before rebooting laptop but it seems the module is now nvidia-current and not nvidia.. [00:03] Sarvatt, btw I talked to apw about the lbm-nouveau naming for the driver. The alternative would be to include a full update of all the dri's (radeon and intel) at the same time, but it sounds like it'd make life hell on our end since we'd need to test all the various combinations of old and new drms for each driver, with mesa, etc. [00:04] Sarvatt, also I don't see any plymouth debug messages (and I'm pretty sure I've run with plymouth:debug but I don't see a Command Line at all in this dmesg o.O) [00:04] yeah looks like it defaults to /var/log/boot.log which we dont use, ahh well [00:09] bryce2: that would be an awesome alternative in my opinion because there would be something in the archive we can point people to for fixes that dont make it to .32 :D but if we did that i doubt we could enable nouveau by default because everyone would have the newer things and wouldnt ever use the 2.6.32 ones if we did? [00:10] Sarvatt, well we'd only put the nouveau binary package on the livecd [00:10] i'm planning on doing a full lbm with intel and radeon on edgers at any rate just for that purpose [00:10] Sarvatt, but think about the mess it'd cause with mesa... wouldn't we end up needing to support two versions of mesa? ick [00:11] what issues would it cause with mesa? [00:11] tseliot, what's this plugin that plymouth falls back to when ubuntu-logo doesn't work? [00:12] superm1: it's the text plugin [00:12] (at least currently) [00:13] tseliot, hmm. it seems to be misbehaving on text strings when I send multi line strings to it [00:16] tseliot, forgive the crappy quality, but http://imagebin.org/83425 is what's happening [00:17] when those should all be left oriented and lined up at the newline characters. [00:18] superm1: I don't know much about that plugin but you can ask in #plymouth. Eventually we won't fall back on the text plugin any more [00:18] kklimonda: anything at /var/spool/plymouth/boot.log ? [00:19] tseliot, you mean because of KMS being prevalent, or because the ubuntu-logo plugin will work on non KMS hardware too eventually? [00:20] superm1: I need to get plymouth to work with 16 colours fbs such as the one provided by vga16fb [00:20] so that non-kms drivers can have something better than the text plugin [00:20] OK. if that's the case, then i wont really bother with trying to drive a solution into the text plugin at this point [00:21] ok [00:21] the other thing I was seeing is that questions (ask-question) aren't working, which i suppose is just a deficiency where ask-question isn't yet implemented for ubuntu-logo [00:24] Sarvatt, RAOF: the name of that module is nouveau_lbm, right? [00:24] lbm-nouveau [00:25] superm1: yes, only ask-password is implemented. I'm working on the new theme so I might as well implement ask-question too [00:25] For some reason nouveau_lbm seemed more natural to me, too; the first libdrm patch I wrote was broken because of that :) [00:25] tseliot, that would be spectacular :) [00:25] Sarvatt, RAOF: ok, thanks [00:30] Sarvatt, nothing - there is no boot.log nowhere in my /var/ [00:47] oh RAOF, new xserver in lucid overwriting the PPA one [00:47] x2 [00:48] so nouveau autodetection with no xorg.conf was broken [00:59] Ah. Do you want to upload a new one, or would you like me to? [01:00] i dont have your patches, was going to grab your source off launchpad and pull it out if you weren't around [01:04] things are all kinds of screwed up here too it looks like [01:09] Ok. I'm not currently near my nvidia laptop; I'll be leaving this rather pleasant café soon, though, so I can have a squiz. [01:10] so much [ 67.240647] [lbm-drm] nouveau 0000:05:00.0: PFIFO_INTR 0x00000010 - Ch 1 spam I don't have anything but that in dmesg [01:11] Ah, a FIFO storm. Yay. [01:12] huh, did libdrm get updated in lucid or something? [01:13] (EE) [drm] Could not set DRM device bus ID. [01:13] (EE) NOUVEAU(0): [drm] error opening the drm [01:14] nope still using PPA ones, not that [01:24] cold boot fixed it :) [01:25] hmm this is new [01:25] [ 0.509445] fb0: EFI VGA frame buffer device [01:25] [ 3.335681] fb: conflicting fb hw usage nouveaufb vs EFI VGA - removing generic driver [01:26] i had that too. killed my console. i blame grub2. [01:26] yeah i was just going to say, looks like the grub2 update [01:26] How are you getting an EFI framebuffer? [01:26] screen is black till nouveau kicks efifb out [01:27] RAOF: beats me [01:27] What crazy hardware do you have that actually has EFI enabled? [01:27] anything with insyde bios? [01:28] here inteldrmfb didn't actually kick efifb out, so i had a black screen until X started. and even then no console. [01:28] like all laptops the past few years [01:32] how long ago did you have it start jcristau? [01:36] happened today, but last reboot was on Jan 23 [02:04] jcristau: think this is it - http://bazaar.launchpad.net/~ubuntu-core-dev/ubuntu/lucid/grub2/lucid/revision/1920/util/grub.d/10_linux.in [02:08] Sarvatt: seems likely [02:09] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=567245 [02:09] Debian bug 567245 in grub-pc "gfxpayload=keep broken" [Normal,Open] [02:11] * jcristau upgrades the severity [02:12] sigh. that moron closed the bug? [02:12] i have to cold boot the nouveau laptop, it cant handle a warm reboot with gfxpayload=keep [02:13] and no consoles at all on intel with KMS enabled, the same as you [02:17] there. reopened and set to 'grave'. [02:21] Sarvatt: thanks for the pointer [02:28] no worries! its fixed in ubuntu now \o/ [02:29] bryce2: grub2 update in the past day making efifb load and breaking consoles with KMS [02:30] ah yes [02:30] kklimonda: that probably fixed your problem [02:33] https://lists.ubuntu.com/archives/lucid-changes/2010-February/004893.html [02:33] crazy week for bugs :( [02:36] fun fun [03:23] seems like its when ureadahead profiling happens i get hung on a splash screen [03:26] Sarvatt, i've also had to downgrade xserver to version from your ppa [03:28] you can just use the lucid stock xserver if you make an xorg.conf [03:28] Section "Device" [03:28] Identifier "Configured Video Device" [03:28] Driver "nouveau" [03:28] EndSection [03:29] ach [05:20] Bah! The latest xorg-core isn't in git yet. [05:28] xorg-core? [05:30] ah xorg-server. pushed. [05:30] sorry, sprint is kind of a madhouse [05:30] That's ok. [05:33] * tseliot packaged the latest beta of the nvidia driver: https://launchpad.net/~albertomilone/+archive/proprietary-video-improvements [06:05] hmm the sprint-bryce left.. I don't know what he means by having to ship two mesa's [06:05] having the .33 drm in lbm would be great [06:06] all the drivers, not just nouveau [06:06] I guess that he might have been thinking that the .33 drm would require a different mesa as well? [06:06] for instance intel 2.10 is happy with .33 and mesa 7.7? [06:07] From the looks of l-b-m-nouveau, adding intel & ati to that wouldn't be too hard. [06:07] (.32 is enough for intel) [06:09] will lucid l-b-m-nouveau always be based on .33? [06:09] probably [06:09] doubt it'll get rebased [06:10] ok [06:10] at that time there should be the kernel from MM backported to lucid [06:10] That's right; we're getting newer kernels in lucid, aren't we. [06:12] that's the plan aiui [06:12] I'll merge & upload new mesa & libdrm today, you can push whatever you have before that? [06:13] new mesa = 7.7-branch snapshot from debian [06:13] since nouveau is a go [06:13] so libdrm is ok to go as well [06:17] libdrm is pushed to pkg-xorg git. [06:17] It includes a merge of 2.4.17-1, so I may have done some of the work you wanted to do already :) [06:20] yeah I noticed, that's great [07:13] heya [07:14] yeah I assume if we upversion the drm, we'll need a newer version of mesa to go with it. [07:37] aiui 7.7 is enough for 2.4.17 [07:37] newer nouveau ddx needs stuff on top of .17, but not mesa [07:38] so the deps go the other way, ie. mesa/ddx depend on some libdrm version :) [07:44] I think we can probably take it as read that nouveau wants git HEAD of everything :) [07:45] I hope they'll ship a release when .33 kernel is released [07:51] They've still got (at least) one ABI break pending; I don't think they want to release until they've done that. [07:51] At least, that's what I recall from previous discussions. [07:54] ok [08:22] That said, they didn't want to be merged into mainline until after that ABI break. Maybe that'll have changed their minds. [08:25] https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-nouveau/+bug/517430 [08:25] Ubuntu bug 517430 in xserver-xorg-video-nouveau "[MIR] xserver-xorg-video-nouveau" [Undecided,New] [08:29] bryceh: Thanks for that. [08:30] starting to get a lot crossed off https://blueprints.edge.launchpad.net/ubuntu/+spec/desktop-lucid-xorg-driver-selection-for-nvidia-hardware [08:34] RAOF, is https://edge.launchpad.net/~xorg-edgers/+archive/nouveau just packages prepped for upload into lucid? [08:39] RAOF, tjaalton, for making xserver use nouveau over nv, should we just s/nv/nouveau/ in xserver, or should we look at resurrecting patch 104? [08:40] (...or something else...?) [08:41] bryceh: I think the ppa version already has something [08:43] fedora has a patch which doesn't use nouveau for all the chips, don't know if it's still relevant [08:43] tjaalton, which ppa? I checked 2:1.7.4.901~git20100122+server-1.7-branch.d3e54304-0ubuntu0sarvatt [08:43] I don't know :) [08:44] daniels resigned from the x.org board? [08:45] aha, 106_nouveau_autodetect.patch in the nouveau ppa [08:45] ok looks like raof resurrected 104 [08:45] ok good, looks like we can cross that item off too [08:50] what's the url for that? [08:50] https://edge.launchpad.net/~xorg-edgers/+archive/nouveau/+packages [08:51] https://edge.launchpad.net/~xorg-edgers/+archive/nouveau/+files/xorg-server_1.7.3.902-1ubuntu12~ppa1.dsc [08:52] that's not good enough though [08:52] nvidia should be dropped from it [08:53] because if there's an xorg.conf on the system and no nvidia installed, it'll try nvidia and only that [08:53] tjaalton, did you look at the patch? nvidia isn't listed [08:53] uh crap [08:54] looked at the wrong patch :) [08:54] 106_nouveau_autodetect.patch [08:56] yep [08:56] looks ok [08:56] is nouveau only for i386 and amd64? does it support any other arch's? [08:56] powerpc? [08:57] arm?? I see -nv is listed for arm... [08:57] well hell, -nv is listed even for alpha ;-) [08:58] debian likes to torture the buildd's alot :) [08:59] ok so for now we only care about i386 and amd64 I guess [08:59] does -nv need to be removed from xserver-xorg-video-all or can -nv and -nouveau both exist side by side? [08:59] bryceh: I noticed that ogra has tested touchscreens with the current stack. do you know if he used evdev or what? [09:00] bryceh: no, nv is still needed for some chips, as noted in the patch [09:00] no I didn't talk to him about his testing [09:00] maybe tseliot knows more [09:00] the blueprint was updated recently [09:00] I saw martin marked the task done but dunno if he talked with ogra first or just figured it was already tested well enough [09:01] tjaalton, what I know is several people have tested and found it worked well (with -wacom) [09:01] bdmurray for instance [09:01] he's got an HP laptop with a touchpad screen that we worked on a bit [09:01] wacom is not evdev though [09:01] turned out it just needed a kernel driver enabled [09:01] nor is it replacing evtouch [09:02] tjaalton, hm what's your question? [09:02] bryceh: that there is no evtouch driver in lucid anymore, and whether evdev is good enough [09:02] what I've seen is that people need -wacom [09:02] bryceh: nouveau definitely works with PPC; it should work on all archs which actually have nvidia hardware. [09:03] * bryceh adds to vars.powerpc and vars.ppc64 [09:03] bryceh: some touchscreens have a wacom, yes. those need the wacom driver [09:03] some (like the X61 tablet here) have a serial wacom, which doesn't work yet [09:03] OOTB anyway [09:04] RAOF, sparc? arm? [09:04] I'm not sure what all platforms have nvidia hardware [09:05] those three should be enough [09:05] I don't actually know. arm certainly does; that's tegra, right? I don't know if nouveau would drive that, though. [09:05] lunch -> [09:06] hm, well guess we can add as we go [09:06] Oh, this is for the seeds? Otherwise, is there any particular reason to do arch restrictions? [09:06] tjaalton, anyway yeah ask pitti or tseliot if you have questions about what this has been tested against [09:06] RAOF, right seeding [09:07] just getting the patch ready. Figure I'll wait on uploading it until nouveau's in main [09:09] Does the nvidia binary driver still destroy the ability for other drivers to work with X, or has that been fixed by the alternatives work? [09:09] If so, xserver-xorg-video-nouveau should stop conflicting with nvidia-glx. [09:10] * RAOF should test that. [09:11] tseliot was playing with that a bit today [09:22] http://launchpadlibrarian.net/38788005/nouveau.diff [10:10] hi [10:18] hello [10:18] i have some questions [11:08] hello [11:46] hello [11:46] again [12:28] bryceh: linux-backports-nouveau is only i386/amd64? [12:30] meaning i dont think you want to add the nouveau ddx to the other arches yet.. [13:01] anyone here [13:02] !ask | indus [13:02] indus: Please don't ask to ask a question, simply ask the question (all on ONE line and in the channel, so that others can read and follow it easily). If anyone knows the answer they will most likely reply. :-) [13:02] vish, here too ? [13:02] vish, you might have guessed, its the fglrx question [13:02] :) [13:02] vish, you are on the art team isnt it [13:03] indus: I use ATI but havent used fglrx [13:03] indus: yup [13:03] vish, i saw your name on the membership wiki, that is approved? [13:04] indus: its the coming week , but kinda off topic here ;p [13:04] oops [13:34] iam looking for ara [13:34] or anyone really [13:35] then ask your question. if someone can answer it they will. if you don't ask, they won't. [13:39] odd 196_xvfb-fbscreeninit-handling.patch doesn't apply to server 1.7 branch even though hw/vfb/InitOutput.c hasn't changed in months, i must be missing something [13:39] guessing the git version is different than the one applied in the archives [13:43] a ny one know about the fglrx in lucid [13:43] doesn't work [13:43] actually no, i have signed up for testing for the driver, so have some questions [13:43] still, doesn't work [13:43] yep git version was for -p0 instead of -p1, i'll fit it in git [13:46] yes i know [13:46] so question is, if it doesnt work, how can you test it [13:46] you can't [13:47] when there is one that you can test you'll get info on it, he sent out that email a bit too prematurely [13:47] ok thanks [13:47] ill wait for the email, just signed up today [13:48] but it seems testing cases are valid [13:48] installation etc [13:48] it won't install [13:48] i installed already [13:48] its available in hardware drivers [13:48] doesnt work is a different thing [13:48] ah, so it doesn't provide the abi anymore.. nice [13:49] breaks systems for no reason [13:49] tjaalton, whats abi [13:49] i wouldnt expect it in the near future though, its up to ATI to give us a driver that works and they aren't very good adopting changes in linux :D [13:49] but i say, it shouldnt be offered in hardware drivers if it wont work :) [13:50] indus: the xserver conflicts with < xserver-xorg-video-6, which means that drivers providing -5 or earlier conflict with the server, and are removed on upgrade [13:50] damn right it shouldn't [13:51] xorg is 1.7 i belive in lucid [13:51] *believe [13:51] or is that 7.5 [13:52] xserver is 1.7 [13:52] xorg is something close to 7.5 [13:52] i would like to kno w the difference between xorg and xserver [13:53] Sarvatt: hmm , with ati , the -edgers ppa hung on boot with > http://pastebin.com/m717b8ca3 , i was dropped into a console and the errors kept running at light speed.. had to hard shutdown ,happened twice :( , but was able to boot the next time around... still it does a freaky sort of hang during boot , I'll have to see if it happens again [13:53] s/with/in [13:53] in any case, i guess the nvidia tests can go on [13:53] ok another question i have is, about s3tc compression, i compiled it but doesnt seem to work [13:55] vish: have you updated grub to 1ubuntu3? [13:55] * vish checks [13:55] 1ubuntu2 was breaking KMS all kinds of bad ways here on all my machines [13:56] is there a mesa channel? [13:56] ah , maybe , grub-pc is still ubuntu2 [13:56] #dri-devel [13:56] * vish reloads repos [13:56] Sarvatt, thank you ,btw do you know about s3tc ,probably yes [13:57] vish: open up your /etc/grub.d/10_linux and go down to where it says gfxpayload=keep [13:57] and delete that whole section [13:57] if you can pastebin your 10_linux i'll tell you the whole section to delete, its already deleted here so i dont have it [13:58] but you can do that then sudo update-grub and it should hopefully fix it [14:00] or just update grub2 to 1ubuntu3 if its available, thats the only change [14:02] was it a warm boot when it failed and a cold boot when it didnt? because thats what happened here, on warm boots i had all kinds of gpu resets and unable to talk to drm in X and no consoles because of that darn forced efifb change [14:03] i'm not using ati though, no idea what was happening there [14:04] Sarvatt: when i restarted , it hung , but when i hard shut it down and started it would boot [14:04] yeah thats what i was experiencing [14:04] Sarvatt, hi [14:05] hello [14:05] i was having problems with intel video graphic on ubuntu 9.04 [14:05] do you remember? [14:06] yep! greedy helping or did you upgrade to karmic? [14:06] i upgrade to karmic [14:06] and now, it's better [14:06] hopefully you're not going to tell me its worse? :D [14:06] phew [14:06] but i'm having problems with web [14:07] my icon don't give me option to see the conections [14:08] not related to x [14:08] network-manager is what you're having a problem with then, I'm afraid I can't help too much in that area [14:08] it saids something like this: "the device is not manageable" [14:08] ok [14:09] where can i find help about this [14:09] herman_: #nm [14:09] anyway, thanks for the help [14:10] #ubuntu would be the best place probably, I would just google "the exact error string" karmic with the exact error message you get in quotes like that [14:11] Sarvatt, yes, but my system is in portuguese [14:11] and i don't know exactly how the string will be in english [14:11] and my english is not so good [14:15] herman_ if you can type it in portuguese here I can tell you what it is in english [14:16] i've got network-manager-applet's pt.po open [14:17] Sarvatt: i think the update ubuntu3 removed the gfxpayload=keep section > http://paste.ubuntu.com/369537/ [14:18] yep thats what the 1ubuntu3 change did, hopefully that fixes things for you [14:20] Sarvatt, my icon says: "rede com fio: o dispositivo não é gerenciável" [14:21] ah thats pt_BR [14:21] Sarvatt, yes [14:22] try googling network manager "device not managed" karmic [14:22] a lot of people are having this problem on karmic [14:22] http://www.google.com/search?sourceid=chrome&ie=UTF-8&q=network+manager+%22device+not+managed%22+karmic [14:22] ok, i will see [14:22] hopefully one of those ubuntuforums posts can help you out [14:24] http://ubuntuforums.org/showpost.php?p=6975928&postcount=3 looks like the solution, people upgrading from jaunty to karmic had that problem [14:25] Sarvatt: I had a talk with libv yesterday, from what he says, the Intel bugs aren't going to be fixed because things work fine with newer kernels, is that correct? [14:25] what intel bugs? [14:26] Where you get thrown back to the gdm greeter. [14:27] I wouldn't say thats always true, there have been a steady stream of backported fixes from .33 to .32 upstream because its a LTS kernel for alot of distros [14:27] I'm on .31. [14:27] .32 works, but introduces another couple of issues, which makes using it a little tricky. [14:27] oh .31 is pretty much dead, I wouldn't expect anything more from it :( [14:28] the last point release was supposedly the final one [14:28] Isn't the problem a regression introduced in the Xorg Intel drivers though, rather than a problem from the kernel itself? [14:29] it's all mashed up together [14:29] ^ [14:29] The 20100127 update caused a lock-up. Mouse was still working, but nothing else. Had to REISUB. [14:30] it seems like they are expecting newer kernels in the later git versions, i can't use git intel on .31 [14:31] lots of random invalid bo alignment errors [14:31] Sarvatt, i already get wired connection [14:31] before, i didn't get [14:31] just stick with 2.9.1 Cobalt is my recommendation [14:32] i have to do that regardless even on lucid because things are broken on 945 since the beginning of december :( [14:34] Fair enough. [14:34] They seem to have moved weird interface names to sane defaults, my ra0 has become wlan0. Which is nice. [14:35] Things should have evened out a bit though, right, for when Lucid will come out in April? [14:36] that sounds like you are using a mainline kernel that has staging disabled so you are using a different module for wireless [14:36] No, all the kernels I've been using have been from the Ubuntu repos. The .32 kernel I used was in the Lucid repo. [14:37] Sarvatt, i got it [14:37] i solve all my problems now [14:37] good to hear :D [14:38] theres 2 different ralink drivers in the kernel for alot of chipsets last i looked, wlan0 one is using mac80211 instead of the ralink specific stuff [14:38] i just era my file /etc/network/interface and i can acess my connections [14:38] is the module name the same Cobalt? [14:38] * Sarvatt renames #ubuntu-x to #ubuntu-wireless :D [14:39] Sarvatt: It is, yeah. [14:39] rt2860sta. [14:40] Although it loads the module fine, automatically, it does not put up the interface. I have to manually do that with ifconfig wlan0 up. [14:40] Sarvatt, you are helping me a lot [14:40] very thanks [14:53] mesa classic nouveau driver was pushed to master, time to enable it on edgers builds :D [15:19] RAOF: would you mind updating the nouveau ubuntu git branch with your latest changes in debian/ whenever you get a chance? [15:24] oh oh... "session active not inhibited" bug present in -edgers ppa :( [15:25] need to update it to build against the newer libdrm in xorg-edgers, figured i'd pull the xorg-edgers/nouveau stuff into xorg-edgers/ppa directly incase anyone wanted to use the newer mesa with nouveau [15:25] thats gnome-power-manager vish [15:25] which you also just updated [15:26] aw , damn it.. gpm sneaked in an update :/ [15:31] hehe , i was thinking Lucid cycle was too quite without gpm problems :p [15:33] did system76 die? [15:33] I can't reach their servers anymore [15:53] -rw-r--r-- root/root 2224748 2010-02-05 15:38 ./usr/lib/dri/nouveau_vieux_dri.so [15:53] built find, now to find someone to try it :D [15:54] heh, nouveau_vieux? :) [16:04] 3 feet of snow predicted... maybe I'll have time to package up nouveau_dri.so now :D [16:20] we got almost that much already :) [17:51] tseliot, what does envy do at this point? i thought it downloaded hte drivers from nvidia and installed them with its own packaging scripts. but i got an email from a guy who is using it to install drivers out of my ppa [17:56] bjsnider: I've removed envy from the archive [17:56] bjsnider: BTW I put the nvidia beta driver in my ppa [17:56] tseliot, does it grab those extra files too? [17:56] yep [17:57] how easy do you think it would be to take the new build scripts and replace the alternatives code with diversions code? [17:57] tseliot, i meant that they ere using envy in karmic, not lucid [17:58] bjsnider: I think it's going to be bit of a mess but still doable [18:02] tseliot, are you planning to have a beta driver more or less permanently in the archive? [18:02] do you mean a -beta flavour? [18:03] well, i don't care what you name it, i just mean a package that's an option, whatever it's called [18:03] but nvidia-beta would be good [18:03] or nvidia-unstable [18:05] dunno how much of a point that would have since it probably wouldn't get updated post release :D [18:05] I think it would be better to keep that in a PPA, maybe xorg-edgers [18:05] Sarvatt: good point [18:05] how hard is it to get a new driver pushed through after a release? [18:05] bjsnider: the SRU team would eat me alive ;) [18:06] sweet, thanks for making that newer nvidia-current tseliot [18:06] what does that acronym stand for? [18:06] stable release update [18:07] but it's nvidia that takes on the responsibility for supporting their driver [18:07] Sarvatt: I hope it fixes some issues with suspend/resume in lucid [18:08] bjsnider: if a package is in main, we take responsibility for it as it's officially supported (with the obvious limits of proprietary drivers) [18:10] tseliot, how can you support prebuilt libs and stuff like that? it would be a copyright violation for you to support it [18:13] they throw lots of testing at it and verify the version shipped works, some people actually dont want to upgrade things like that that has the potential to break things (crazy I know) [18:14] especially when you dont have access to the code so you dont know what could be breaking (or fix it) [18:33] * tseliot nods [18:40] well, i've actually told people who have emailed me about issues specific to nvidia that they should go there and complain [18:40] but they use vbulletin to manage bug reporting which is nuts [18:41] but whatever [18:41] bryce2. bryceh. is anyone else getting "libGL is too old"? [18:43] i think the nvidia blob is getting installed on intel machines and its interfering [18:46] LLStarks, haven't heard that one before [18:46] do you have any ppas installed? [18:46] not using edgers at the moment. [18:46] but the blob was basically disabling direct rendering for intel [18:49] entire screen would bug out and text flip if compiz was activated [18:53] LLStarks, you should probably talk to tseliot about it [18:54] LLStarks: what does "ldconfig -p |grep GL" say? [18:55] it's fixed now because i purged the drivers [18:55] LLStarks: there's no need to do that. They can coexist with open drivers in lucid [18:57] disabling the driver with the latest release of jockey should do it. Or a simple command should do it too [18:58] libGL.so (libc6) => /usr/lib/nvidia-current/libGL.so [18:58] that doesn't belong. [18:58] it's the only thing added. [18:58] LLStarks: sudo update-alternatives --config gl_conf (and select mesa) [18:59] then type "sudo ldconfig" and reboot [18:59] http://img94.imageshack.us/img94/7263/ohgodo.png [18:59] that's what was happening before [19:00] ouch, I've seen that already. I'm not sure if it's related to this problem though [19:00] no, it is. [19:00] that libgl causes it. [19:01] my two commands will fix it then [19:01]