[10:13] <vish> aw... i can switch user or get into a guest session :( > Bug 506510
[10:13] <vish> cant*
[10:16] <tseliot> bdmurray: I can't find the button to make this report ^^ public
[10:16] <tseliot> or ara ^^ ?
[10:17] <ara> tseliot, I'll review it and make it public
[10:17] <tseliot> ara: thanks
[10:19] <ara> tseliot, are you part of the bugcontrol team?
[10:19] <tseliot> ara: yes, I think so
[10:20] <tseliot> yep
[10:20] <tseliot> https://launchpad.net/~albertomilone
[10:20] <ara> tseliot, then, you should see an "edit" icon right of the message "This bug is private"
[10:21] <ara> tseliot, can't you see it?
[10:21] <tseliot> ara: no icon to the right of that message
[10:21] <ara> tseliot, weird 
[10:23] <vish> tseliot: made it public
[10:24] <tseliot> ara: I guess it's some bug in google chrome
[10:24] <ara> tseliot, it might be :)
[10:24] <ara> tseliot, I am making it public now
[10:24] <tseliot> ara: thanks
[10:25] <tseliot> it works well in opera
[10:25] <vish> ara: just did it :)
[10:25] <tseliot> so it was definitely a bug in chrome
[10:25] <tseliot> sorry for the noise
[10:25] <ara> tseliot, np :)
[10:31] <ara> tseliot, I have to double check later (right now I am working on something else), but Xorg crashes (and doesn't come up) after resume
[10:31] <tseliot> ara: with what driver? Nvidia?
[10:32] <ara> tseliot, yes, Nvidia (although I've only tested it with Nvidia)
[10:33] <tseliot> ara: BTW I don't know if you've experienced bug #506547. I you did, I'm working on it
[10:34] <ara> tseliot, no, I haven't seen that one, but I'll subscribe to it, just in case :)
[10:34] <tseliot> good
[10:35] <ara> tseliot, if you see any bugs you might be interested in me to test them or you feel I should know, feel free to subscribe me
[10:35] <tseliot> ara: ok, thanks a lot
[10:35] <ara> tseliot, thanks to you!
[10:35] <tseliot> :-)
[10:35]  * ara hugs tseliot
[10:36]  * tseliot hugs back ara
[11:42] <alkisg> This will sound totally crazy, but there's a valid reason for wanting to do it (fat client chroots on LTSP):
[11:42] <alkisg> Is it possible to install ALL proprietary drivers (e.g. nvidia, ati) on a system, and for an initscript to look up the pci id and write the appropriate xorg.conf, if needed?
[11:42] <alkisg> The goal is to have an image (imagine something like a live cd) that can boot on most systems and include 3d acceleration out of the box.
[11:42] <alkisg> The image will be build locally on each site by a script, so I'm not concerned about redistribution problems. I'm mostly worried about dependencies / library conflicts etc.
[11:42] <alkisg> Do you think that it's possible to create such an image?
[11:43] <alkisg> Thanks in advance for any input.
[11:44] <hyperair> don't we go without a xorg.conf nowadays?
[11:44] <hyperair> install all the drivers, have a blank xorg.conf and then start the server?
[11:44] <hyperair> won't that work?
[11:44] <alkisg> I think that for proprietary drivers, a minimal xorg.conf is needed, that contains the driver name
[11:44] <alkisg> Otherwise the open source version will be used.
[11:45] <hyperair> oh isit?
[11:45] <alkisg> I *think* so :)
[11:45] <alkisg> Also, I'm not sure if the opengl libs will work. E.g. nvidia installs its own opengl libs versions, and then the client has an ati.
[11:45] <coz_> alkisg,  I know that if y ou have intel drivers and nvidia drivers installed at the same time...the usual outcome is that the system works but the desktop is upside down and in reverse....
[11:45] <hyperair> er
[11:45] <hyperair> upside down?
[11:45] <alkisg> coz_: right, I've seen that. I can work around it by globally disabling compiz.
[11:46] <coz_> hyperair,  yep 
[11:46] <coz_> alkisg,  ah cool
[11:46] <hyperair> coz_: like literally?
[11:46] <coz_> alkisg,  it has always interes
[11:46] <coz_> interested me that issue
[11:46] <coz_> hyperair,  very litterally
[11:46] <coz_> literally
[11:46]  * hyperair gapes
[11:46] <alkisg> coz_: do you think there would be conflicts in other libraries?
[11:46] <alkisg> E.g. nvidia-96 would conflict with nvidia-185?
[11:47] <coz_> alkisg,   not sure   but considering the outcome of that senario  I wouldnt doubt it
[11:47] <coz_> alkisg,  oh
[11:47] <coz_> alkisg,  mm
[11:47] <coz_> alkisg,  not sure
[11:47] <hyperair> oh yeah nvidia-96 would definitely conflict
[11:47] <alkisg> Ouch
[11:48] <coz_> alkisg,  I think we have seen issues even with nvidia an ati drivers installed
[11:48] <coz_> alkisg,  why are you thinking this by the way?
[11:48] <alkisg> coz_: it's a fat client scenario
[11:49] <coz_> alkisg,   oh!
[11:49] <alkisg> Something like a live cd is served over the network
[11:49] <hyperair> ah i see
[11:49] <alkisg> So the clients only use that "cd" as a disk, but they use their own CPU/RAM etc
[11:49] <coz_> alkisg,  sounds interesting...  I dont envy what you are trying to do though
[11:49] <hyperair> something like nfs root?
[11:49] <alkisg> hyperair, yup. 
[11:49] <alkisg> coz_: it currently works FINE :D
[11:49] <hyperair> heh
[11:49] <coz_> alkisg,  oh  cool :)
[11:49]  * alkisg loves the new LTSP fat client plugin :)
[11:50] <tseliot> alkisg: do you want to install all proprietary drivers or do you want to use them all at the same time?
[11:50] <alkisg> tseliot: I want each client to use only the appropriate driver
[11:51] <coz_> so not installed but avilable
[11:51] <alkisg> So if an initscript can somehow handle it, I'm fine!
[11:51] <coz_> available
[11:51] <tseliot> with the new alternatives system in lucid you'll be able to install them all. Then set the alternative to whatever you want to use, change xorg.conf and reboot
[11:51] <coz_> very cool
[11:52] <hyperair> tseliot: what about nvidia-96 and nvidia-185?
[11:52] <tseliot> ideally this should just work (without any xorg.conf) if I fix the nvidia and fglrx autoloading patches
[11:52] <tseliot> hyperair: nvidia-185?
[11:52] <tseliot> nvidia-current = 190
[11:52] <alkisg> (nvidia-current, I just said 185 to make a contradiction with -96...)
[11:52] <hyperair> oh whoops
[11:53] <hyperair> tseliot: sorry, i'm outdated.
[11:53] <tseliot> nvidia-current, nvidia-173 and nvidia-96 (and soon also fglrx) can all be installed at the same time
[11:53] <alkisg> Yey!!! /me hugs tseliot!!! :)
[11:53] <hyperair> eh that's interesting
[11:53] <tseliot> which is one of the reasons why I implemented the alternatives system ;)
[11:54] <hyperair> tseliot: out of curiosity, have you seen any reports of flickering screens with nvidia-96?
[11:54] <tseliot> I should document how all of this works
[11:54]  * hyperair is pretty annoyed with his -96 desktop
[11:54]  * alkisg has flickering screens since karmic
[11:54] <alkisg> (with nvidia)
[11:54] <hyperair> heh
[11:54] <hyperair> i've had flickering screens since...
[11:54] <tseliot> hyperair: I'm been too busy with mesa in the last few days ;)
[11:54] <hyperair> jaunty?
[11:54] <hyperair> intrepid?
[11:54] <hyperair> tseliot: no i meant, further back.
[11:55] <hyperair> tseliot: reports from a few releases back
[11:55]  * hyperair kicks his desktop
[11:55] <tseliot> hmm... I wouldn't know. I think I remember something about that
[11:56] <hyperair> i'm this close to scrapping GNOME and nvidia on that desktop, and just going nouveau or nv and one of those minimalist WMs
[11:56] <coz_> hyperair,  have you tried gnome-shell?
[11:56]  * hyperair runs that desktop headless most of the time.
[11:57] <hyperair> coz_: yes. and i hate it.
[11:57] <coz_> hyperair,  right now it is a little resource intensive with video
[11:57] <coz_> hyperair,  :)
[11:57] <hyperair> coz_: that's not the point.
[11:57] <hyperair> coz_: metacity has flickers with the nvidia driver.
[11:57] <coz_> o0
[11:57] <hyperair> coz_: gnome-shell won't work at all without 3d.
[11:57] <coz_> mm
[11:57] <hyperair> gnome-shell, pah. should be gnome's-hell or something >_>
[11:57] <hyperair> i want my compiz.
[11:58] <coz_> :)
[11:58] <coz_> hyperair,  wait for 0.9.x compiz to release
[11:58] <hyperair> hell yeah, i'm waiting.
[12:01] <coz_> hyperair,  although that video about gnome shell and  clever windows  was real appealing
[12:01] <hyperair> clever windows?
[12:01] <coz_> I have no idea if clever windows will be implimented or even considered 
[12:01] <coz_> hyperair,  yeah google ...... clever windows video >>>>>>
[12:03] <hyperair> oh yeah i  think i've seen this before
[12:04] <coz_> hyperair,  although compiz has most of those features  except that litte tab on the left and right for minimizing etc
[12:04] <hyperair> righ
[12:04] <hyperair> t
[12:37] <knittl> what do i have to do to install the current version of nvidia? all methods i tried so far did not work
[12:38] <knittl> i tried: apt-get install nvidia-current and installing via jockey
[12:38] <knittl> then i ran nvidia-xconfig
[12:48] <tseliot> knittl: jockey doesn't work with nvidia yet
[12:48] <knittl> tseliot: ok, i see. what about apt-get?
[12:48] <tseliot> apt-get install nvidia-current and then nvidia-xconfig and reboot
[12:48] <tseliot> and that's it
[12:48] <knittl> do i have to install the modaliases (the common package)?
[12:53] <tseliot> knittl: that's only for jockey
[12:53] <tseliot> you might need it in the future
[12:53] <knittl> ok, but right now it's enough to install nvidia-current without anything else?
[12:54] <tseliot> yes, that and nvidia-xconfig
[12:55] <knittl> yep, for creating the xorg.conf of course
[12:55] <knittl> good, i'll give it another try
[13:10] <gnomefreak> is it known that nvidia is broken on latest xorg updates?
[13:24] <tseliot> gnomefreak: define "broken" please?
[14:29] <knittl> tseliot: still no luck, looks like X is crashing
[14:31] <tseliot> knittl: what happens exactly?
[14:32] <knittl> here is what i did this time: purged everything related to nvidia (apt-get purge nvidia*), searched in aptitude for nvidia, removed libvdpau, removed all xorg.conf* files, rebooted. service stop gdm, apt-get install nvidia-current, nvidia-xconfig, checking the successful creation of xorg.conf (yep, it's there, with driver = nvidia), rebooting. screen flickers early on (plymouth?), gdm gives warning that graphics driver is broken -> start in low resolution 
[14:32] <tseliot> describe the symptoms please
[14:33] <tseliot> knittl: can I see your /var/log/Xorg.0.log and /var/log/Xorg.0.log.old, please?
[14:33] <knittl> i see text on the console (fsck, ureadahead terminating), then screen goes black, screen flickers, gdm error message appears
[14:33] <knittl> sure, just a second
[14:35] <knittl> http://knittl.is-a-geek.net/public/Xorg.0.log{,.old}
[14:41] <tseliot> knittl: maybe the kernel module wasn't built. What does this command say? dkms status
[14:41] <knittl> nvidia-current, 190.53, 2.6.32-10-generic, i686: installed
[14:41] <Sarvatt> did the kernel module build ok when you reinstalled? if so, try sudo update-initramfs -u and reboot again? I need to do that pretty much every time I purge/reinstall nvidia, the first boot after is always failsafe
[14:42] <knittl> hrm
[14:43] <tseliot> knittl: also make sure that no other nvidia drivers (especially the ones from unofficial PPAs) are installed
[14:43] <knittl> tseliot: no, i purged nvidia before, and i deaktivated all ppas. i also run several updates
[14:44] <Sarvatt> apt-get purge nvidia* should have taken care of that, have to reinstall nvidia-common manually after that though
[14:44] <tseliot> dmesg might have something interesting
[14:44] <knittl> that's only needed for jockey and jockey does not work yet with the new nvidia. that's what i was told before
[14:44]  * tseliot nods
[14:44] <tseliot> dmesg ^^
[14:45] <knittl> same url, file dmesg
[14:46] <tseliot> ara, slangasek: I have worked on #506547. I have uploaded my fix for mesa to my PPA: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
[14:46] <tseliot> can you test it please?
[14:48] <tseliot> the tests that I've run here so far i.e. building mutter and testing blender went well: http://pastebin.ubuntu.com/356082/
[14:49] <tseliot> oh, it's 7.7-0ubuntu5~proprietaryppa1
[14:49] <tseliot> and it's still building
[14:50] <ara> tseliot, I will test it when it's done
[14:51] <tseliot> ara: ¡Muchas gracias!
[14:57] <jcristau> err. "invalid "install -d" command"
[14:57] <jcristau> ?
[14:57] <jcristau> ah.  because $(INSTALL) isn't set anywhere, i guess
[14:58] <tseliot> yep
[14:58] <tseliot> and it was useless anyway
[14:59] <jcristau> ack
[15:07] <tseliot> thanks for reviewing my commit
[15:29] <tseliot> ara: the packages are ready (just FYI)
[15:30] <ara> tseliot, OK, I will test them as soon as I have time (ISO testing takes lots of time)
[15:30] <tseliot> ara: sounds good, thanks
[16:12] <tseliot> slangasek: in addition to fixing #506547 ^^ I also sent you something to put in the release notes (which, of course, you can modify as you like)
[16:15] <slangasek> tseliot: feel free to edit https://wiki.ubuntu.com/LucidLynx/TechnicalOverview directly (I won't be able to look at this for several more hours)
[16:17] <tseliot> slangasek: ah, good. Just to be clear, I fixed the bug but haven't uploaded anything yet (see above)
[16:17] <slangasek> any reason not to upload, if it's fixed?
[16:19] <tseliot> slangasek: I was waiting on QA to test it (in addition to my tests). If you want me to upload it now, I'll do it though
[16:19] <slangasek> tseliot: ok - more testing is good :)
[16:19]  * tseliot nods
[16:20] <tseliot> slangasek: BTW I have evidence that things go well with the fix: http://pastebin.ubuntu.com/356082/
[16:21] <siretart`> I noticed that a simple 'xrandr' auto-activates the external monitor on my laptop. prior to kms this was not the case. Is this behavior intended or a bug?
[16:21] <slangasek> tseliot: goody!
[16:21] <tseliot> :-)
[16:23] <jcristau> siretart`: my guess would be, xrandr tells the kernel to probe the connector, it then detects that the external monitor is connected, sends an event to tell userspace that, and something (gnome?) enables it
[16:24] <siretart`> jcristau: well, a friend confirmed that the same behavior appears in debian/unstable as well, and that it occurs since switching to kms
[16:24] <tseliot> siretart`: what jcristau says is correct, at least if you're using gnome
[16:25] <tseliot> because gnome-settings-daemon gets the hotplug event
[16:25] <siretart`> tseliot: what part of gnome is responsible for that?
[16:25] <tseliot> ^^
[16:26] <jcristau> xrandr --current wouldn't do that, fwiw
[16:26] <siretart`> I noticed another bug as well: if you open an opengl application (like glxgears) and enlarge the window to more than 2048 (roundabout) pixels, the intel inkernel gem locks up and requires a reboot
[16:26] <tseliot> ideally cable hotplug events are useful but in some cases (e.g. VGA cables) they are triggered only after running xrandr manually
[16:26] <tseliot> or probing in any other way
[16:27] <siretart`> this is particularily painful when connecting a 1920x1200 display and typing 'xrandr' in a shell: instant lockup
[16:28] <jcristau> fun...
[16:28] <jcristau> jbarnes: ^^
[16:28] <tseliot> siretart`: the bug about going beyond 2048 was fixed in mesa 7.7 and the latest intel
[16:28] <siretart`> tseliot: I guess gnome-settings-daemon shouldn't call xrandr without --current then, right?
[16:28] <tseliot> let me find the bug
[16:29] <jcristau> gnome-settings-daemon doesn't call xrandr at all..
[16:29] <tseliot> siretart`: no, it doesn't call xrandr at all. When you call that, it cause a reprobe and you get that event
[16:29] <tseliot> and then g-s-d enables the external screen
[16:30] <siretart`> https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/503255 is the bug I filed
[16:30] <siretart`> tseliot: I'd consider g-s-d auto-enabling the external screen a bug. can this behavior be disabled by a configuration change?
[16:31] <tseliot> siretart`: I'm not sure if it's the same bug but this one looks similar: https://bugs.freedesktop.org/show_bug.cgi?id=23718
[16:31] <tseliot> siretart`: you can always disable g-s-d's randr plugin from gconf
[16:31] <tseliot> and it's not a bug, it a feature ;)
[16:32] <tseliot> a feature that bugs you but still a feature :-P
[16:32] <siretart`> I'd prefer to have the behavior consistent to earlier releases of ubuntu, TBH
[16:33] <jcristau> bug the gnome people then, maybe?
[16:39] <siretart`> with this explanation, I think the defect report is "g-s-d's xrandr manager changes display configuration on probing monitors"
[16:39] <siretart`> thanks for clearing this up!
[16:40] <tseliot> siretart`: auto-enables would be more appropriate than "changes", I guess
[16:40] <siretart`> ok
[16:40] <tseliot> and it's an upstream decision
[16:40] <tseliot> siretart`: you can discuss it with federico1
[16:41] <tseliot> who happens to be upstream ;)
[16:41] <siretart`> tseliot: you wrote earlier that the bug with gl frames beyond 2048 was fixed in "latest intel". is lucid's 2.9.1-1ubuntu1 recent enough?
[16:41] <siretart`> federico1: around? see ^^
[16:44] <tseliot> siretart`: good question. If it's not, we'll pull it
[16:45] <siretart`> hm. I think I'll just dist-upgrade my laptop and test it
[16:47] <tseliot> ok, good
[16:48] <siretart`> tseliot: the freedesktop bug 23718 is not related to this issue. the kernel oops trace looks different
[16:49] <siretart`> in fact, I don't get any trace at all
[16:49] <siretart`> well, maybe related, but not the same
[16:51] <tseliot> siretart`: can you upstream your bug report (on freedesktop), please? Intel should know whether it's the same problem or not
[16:52] <tseliot> but yes, dmesg looks different in your bug report
[16:54] <siretart`> probably not today, will need to defer that to tomorrow
[16:58] <tseliot> ok
[17:32] <federico1> siretart`: hmm, what was the problem_
[17:32] <federico1> ?
[17:33] <tseliot> federico1: g-s-d auto-enabling the external screen on hotplug events
[17:34] <federico1> tseliot: oh, yeah, I intend to do something about that
[17:34] <tseliot> which he gets after using the "xrandr" command (which causes a reprobe)
[17:34] <federico1> I want to just bring up gnome-display-properties so that you can setup the monitors, or ask you "you have a new monitor - what do you want?  [clone] [extend] [custom]"
[17:35] <federico1> tseliot: BTW, I'm reworking the handling of the XF86Display hotkey, so that we bring up an OSD window with options instead of having you guess what the program did...
[17:35] <tseliot> federico1: that feature is more than welcome
[17:36] <tseliot> actually both features are
[17:36] <tseliot> federico1: I think a small dialog would work for the hotplug event case, as you suggested
[17:37] <federico1> tseliot: yeah, maybe the same OSD window with an extra label, "you just plugged a monitor; please pick one of the following options"
[17:38] <federico1> tseliot: when I'm done with that OSD, I want to merge the moblin patches for transformations
[17:38] <tseliot> federico1: either way you might want to have this in the hotplug case: [clone] [extend] [custom] [no action]
[17:39] <federico1> yeah
[17:39] <federico1> sounds good!
[17:39] <tseliot> federico1: that would be great. What would be even better is if transformations were implemented directly in mutter
[17:40] <tseliot> so as not to get a performance hit when scaling
[17:42] <tseliot> slangasek: BTW when I get the ok from QA shall I ask you before I upload? (because of the freeze)
[17:43] <slangasek> tseliot: no, just go ahead with uploading then
[17:43] <tseliot> slangasek: ok, thanks
[17:46] <federico1> tseliot: you mean, have the compositing manager transform stuff instead of doing it with xrandr transformations?
[17:46] <tseliot> federico1: yes, exactly
[17:47] <federico1> interesting
[17:47] <federico1> hmm
[17:47] <tseliot> that should be faster
[17:47] <federico1> so
[17:48] <federico1> tseliot: regardless of the speed (which *is* an important concern), the CM would indeed give us more flexibility.  I'm not sure that you can have xrandr transformations just do "I have a 1024x600 netbook; make it show on my 1024x768 projector with two black bars at the top and bottom"
[17:48] <federico1> maybe you can; I'm not sure
[17:49] <tseliot> federico1: I'm not sure about the bars. What I know for sure is that you can make clone screen work using different resolutions by scaling the content of one of the 2 screens. If they aspect ratio is different, things will look slightly deformed but still good IMO
[17:50] <apw> bryyce, hey ... we have a bunch of people not being able to boot to X with modesetting turned on, it seems to have occcured with an x/mesa update today ... ringa bell?
[17:50] <apw> (on i915)
[17:50] <apw> tseliot, ^^
[17:50] <tseliot> apw: ls -l /usr/lib/xorg/modules/extensions/
[17:51] <apw> tseliot, what am i looking for?
[17:51] <tseliot> apw: libdri.so and libglx.so
[17:52] <apw> they are both 2010-01-12 11:12
[17:53] <tseliot> apw: ok, it must be something else then. Can I see your /var/log/Xorg.0.log, please?
[17:54] <tseliot> apw: err, the one with KMS
[17:55] <cking>  ls -al /usr/lib/xorg/modules/extensions/
[17:55] <cking> total 148
[17:55] <cking> drwxr-xr-x 2 root root  4096 2010-01-13 09:50 .
[17:55] <cking> drwxr-xr-x 7 root root  4096 2010-01-13 09:50 ..
[17:55] <federico1> tseliot: yeah, maybe a bit of distortion is acceptable (like 4:3 NTSC on widescreen TVs)
[17:55] <cking> -rw-r--r-- 1 root root 17920 2010-01-12 11:12 libdbe.so
[17:55] <cking> -rw-r--r-- 1 root root 13784 2010-01-12 11:12 libdri2.so
[17:55] <cking> -rw-r--r-- 1 root root 92336 2010-01-12 11:12 libextmod.so
[17:55] <cking> -rw-r--r-- 1 root root  9708 2010-01-12 11:12 librecord.so
[17:55] <cking> king@hpmini:~$ 
[17:56] <tseliot> cking: that's wrong, you're missing those 2 modules. sudo apt-get install --reinstall xserver-xorg-core and it should be ok
[17:56] <cking> tseliot, will try that - hold on
[17:58] <apw> tseliot, we have a three machines in this one room with this symptom
[17:58] <tseliot> apw: ubuntu5 of xserver-xorg-core should have fixed that
[17:59] <apw> tseliot, ok checking :)
[18:01] <apw> tseliot, pgraner has ubuntu5
[18:01] <apw> and its not working for him, cking reports a --reinstall fixing it
[18:02] <tseliot> apw: weird, the preinst should have taken care of that
[18:02] <tseliot> slangasek: ^^
[18:03] <apw> pgraner, has ubuntu5 and 4 files in /extensions
[18:04] <apw> tseliot, an upgrade from ubuntu4 to ubuntu5 of that package did work for smb on another machine
[18:05] <apw> ie we went from 4 to 6 files in /extensions
[18:06] <tseliot> that's interesting
[18:06] <apw> cking, went ubuntu5 without it, and reinstall made it work#
[18:06] <apw> s/went/was on
[18:06] <apw> we have one box on u5 with out those files, need anything from it?
[18:07] <tseliot> apw: what version of the same package was installed before ubuntu5?
[18:08] <tseliot> see /var/log/apt/term.log
[18:09] <apw> tseliot, cking he did just the apt-get --reinstall xserver-xorg-core and after that he had ubuntu5 so i assume he had u5 before that
[18:09] <apw> and he confirms the logs show u5 as installing this AM
[18:10] <apw> and pgraner is in the same place, but before the reinstall, ie with u5 and not working with 4 files in /extensions
[18:10] <tseliot> apw: right. And what did he have before installing u5? Was it u4?
[18:10] <tseliot> or u3?
[18:10] <apw> checking
[18:11] <apw> cking was on u2 -> u5
[18:12] <apw> pgraner, reports from u2 -> u5 also ... and he says he has been updating daily
[18:15] <tseliot> apw: what does this command say? update-alternatives --display gl_conf
[18:15] <apw> tseliot, on a good or bad one
[18:16] <cking> tseliot, update-alternatives --display gl_conf
[18:16] <cking> gl_conf - auto mode
[18:16] <cking>  link currently points to /usr/lib/mesa/ld.so.conf
[18:16] <cking> /usr/lib/mesa/ld.so.conf - priority 500
[18:16] <cking>  slave gl_libraries: /usr/lib/mesa
[18:16] <cking>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
[18:16] <cking> Current `best' version is /usr/lib/mesa/ld.so.conf.
[18:16] <tseliot> cking: on a bad one
[18:17] <tseliot> i.e. one that doesn't have those 2 modules yet
[18:17] <apw> tseliot, coming
[18:17] <pgraner> pgraner@zorak:~$ update-alternatives --display gl_conf
[18:17] <pgraner> gl_conf - auto mode
[18:17] <pgraner>  link currently points to /usr/lib/mesa/ld.so.conf
[18:17] <pgraner> /usr/lib/mesa/ld.so.conf - priority 500
[18:17] <pgraner>  slave gl_libraries: /usr/lib/mesa
[18:17] <pgraner>  slave xorg_extra_modules: /usr/lib/xorg/x11-extra-modules
[18:17] <pgraner> Current `best' version is /usr/lib/mesa/ld.so.conf.
[18:19] <tseliot> slangasek: ok, so the alternative was removed and our fix (in the preinst script) worked but the modules were not installed
[18:19] <apw> smb has an installation on ubuntu2 level, in case we want to test the update
[18:19] <tseliot> apw, pgraner, cking: thanks
[18:20] <tseliot> apw: oh, good
[18:22]  * tseliot -> off for a bit
[18:24] <apw> tseliot, we note that these files were links in u2, but in u5 fixed they are real files
[18:26] <tseliot> apw: yes, as I had to move the alternatives from the xserver to mesa. However xserver-xorg-core ubuntu4, when removed, failed to remove its alternative thus preventing the new xserver-xorg-core from installing the real files
[18:27] <apw> tseliot, presaumably as we never has u4 in there all <u5 fail to remove them
[18:28] <tseliot> apw: well anything <= ubuntu4 failed to remove the alternative
[18:28] <tseliot> and the output that you gave me, shows that the alternative was removed by u5
[18:29] <apw> its seems odd that we ended up with nothing
[18:31]  * tseliot nods
[18:40] <Sarvatt> i think we really  need powersave=0 to be the default i915 module parameter in lucid over 1 it is now
[18:40] <jcristau> +1
[18:42] <Sarvatt> dont have any hope this is going to be fixed on 2.6.32 ever, its really experimental and even with the remove render reclock support added it's still need it to fix flickering
[18:43] <Sarvatt> can't enable it globally because it breaks 2.6.31 kernels because it wasnt a module parameter then
[18:46] <sebner> tseliot: are there still known issues with mesa?
[18:53] <Sarvatt> on line 46 of drivers/gpu/drm/i915/i915_drv.c just change unsigned int i915_powersave = 1; to unsigned int i915_powersave = 0; -- would be easy to fix at least
[18:53] <bryyce> Sarvatt, can you file a bug against linux requesting this, and sub me and steve conklin?
[18:54] <Sarvatt> sure, i'm on my phone now but will when I get home, theres probably hundreds of bugs it'll fix
[18:54] <Sarvatt> fedora and debian are both doing it
[18:57] <jcristau> fedora too?  didn't see that.
[18:58] <Sarvatt> yeah dave airlie was complaining about how everyone has to do it on dri-devel/lkms
[18:58] <bryyce> hundreds of bugs?  nice
[18:58] <Sarvatt> [PATCH] DRM / i915: Fix resume regression on MSI Wind U100 w/o KMS thread
[18:59] <jcristau> Sarvatt: yeah i read that.  i just can't find that in fedora cvs
[18:59] <jcristau> might be me being blind
[18:59] <jcristau> or not looking in the right place
[18:59] <tseliot> sebner: bug #506547, which is fixed in my PPA and in git: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
[19:02] <sebner> tseliot: exactly. thanks :)
[19:10] <tseliot> sebner: if you want to try it and give feedback (no reboot is required) that would be very welcome
[19:12] <wind-rider> hi
[19:13] <sebner> tseliot: done already + fixing the issue (at least for me)
[19:13] <wind-rider> i have a 3dconnexion spacenavigator, and it is detected as a mouse by X.org
[19:13] <wind-rider> but i would like to prevent that, because it needs a special driver
[19:14] <wind-rider> i tried to do that using a fdi file in the hal policy directory, but that doesn't help
[19:14] <wind-rider> can i do something about that?
[19:17] <tseliot> sebner: great news. Thanks for testing
[19:18] <sebner> tseliot: thanks for fixing ;)
[19:18] <wind-rider> or is there another channel i can ask better?
[19:19] <jcristau> wind-rider: lucid?
[19:19] <wind-rider> jcristau: indeed
[19:19] <jcristau> then X doesn't use hal
[19:20] <jcristau> you can run xinput float <device> to stop it from moving the mouse
[19:20] <wind-rider> jcristau: oh, you're right
[19:20] <wind-rider> jcristau: i'll try that
[19:20] <jcristau> where <device> is the id you get from xinput list
[19:21] <baptistemm_> Hi gentlemen
[19:22] <baptistemm_> Apparently on lucid, i915 + kms makes your screen corrupted, and eventually frozes totally the display, is it known ?
[19:22] <baptistemm_> if I start with i95.modeset=0 I have no issue
[19:23] <jcristau> what hw?
[19:23] <wind-rider> jcristau: that works, thanks! i'll put it on the launchpad page for the new spacenavd package
[19:23] <jcristau> wind-rider: 'xinput set-prop <device> "Device Enabled" 0' should also work.  i'm not sure which one is more correct.
[19:24] <wind-rider> jcristau: the first thing you said was good enough, at least :) thx!
[19:24] <jcristau> np
[19:25] <baptistemm_> jcristau, GM965/GL960 (8086:2a02)
[19:26] <baptistemm_> should I report, and against which component (intel, xserver)?
[19:31] <tseliot> baptistemm_: probably unrelated but what does this say? ls -l /usr/lib/xorg/modules/extensions/
[19:31] <baptistemm_> -rw-r--r-- 1 root root 17920 2010-01-12 12:12 libdbe.so
[19:31] <baptistemm_> -rw-r--r-- 1 root root 13784 2010-01-12 12:12 libdri2.so
[19:31] <baptistemm_> -rw-r--r-- 1 root root 92336 2010-01-12 12:12 libextmod.so
[19:31] <baptistemm_> -rw-r--r-- 1 root root  9708 2010-01-12 12:12 librecord.so
[19:31] <baptistemm_> I hope 4 lines is not too much to paste
[19:32] <jcristau> tseliot: not unrelated then ;)
[19:32]  * tseliot nods
[19:32] <tseliot> baptistemm_: what does "dpkg -L xserver-xorg-core" say?
[19:33] <tseliot> maybe I should send an email to the mailing list about it
[19:33] <baptistemm_> http://pastebin.org/75688
[19:35] <tseliot> baptistemm_: and of course "update-alternatives --display gl_conf | grep glx" doesn't return anything, does it?
[19:36] <baptistemm_> nothing
[19:36] <tseliot> baptistemm_: reinstalling xserver-xorg-core will solve your problem
[19:37] <baptistemm_> so I guess I don't have to report a bug then :)
[19:37] <baptistemm_> ah libglx.so whan missing ?
[19:37] <baptistemm_> was
[19:45] <baptistemm_> sO I'll reboot and see if it fixed, thanks
[19:47] <bryyce> tseliot, you might want to post an email to ubuntu-devel@ about the mesa issue and that rebooting solves it.  might help spread the word faster.
[19:48] <tseliot> bryyce: yes, I'm almost done writing it
[19:50] <sebner> tseliot: update-alternatives --display gl_conf | grep glx doesn't return anything here either or am I missunderstanding and is this the prefered thing?
[19:50] <tseliot> sebner: yes, that's the way it should be
[19:51] <tseliot> i.e. no output
[19:51] <sebner> fine then :)
[19:52] <baptistemm_> tseliot, thanks it works fine now, what happend?
[19:53] <tseliot> I had to move the alternatives from the xserver to mesa. However xserver-xorg-core ubuntu4, when removed, failed to remove its alternative thus preventing the new xserver-xorg-core from installing the real files
[19:57] <siretart`> tseliot: I've just done a very quick test with my external monitor, you're right, current lucid does not show that behavior. windows with width >2048 pixels no longer crash gem, they 'just' have display corruptions
[19:58] <tseliot> siretart`: better than nothing, I guess
[19:58] <tseliot> thanks for reporting
[19:58] <siretart`> tseliot: I could also confirm that disabling the xrandr plugin avoids autoenabling the external monitor. though this also prevents the gnome randr applet from working. but I guess that's expected
[19:58] <tseliot> yep
[19:59] <siretart`> federico1: your suggestion for a pop up that asks the user what to do sounds exactly right to me! thanks a lot!
[20:00] <tseliot> bryyce: email sent
[20:00] <bryyce> great
[20:00] <siretart`> the only thing that I unexpected issue I've noticed now is that g-s-d's randr manager somehow managed to cause compiz to quit and start metacity instead
[20:00] <siretart`> while 'autoenabling' the external monitor
[20:00] <tseliot> bryyce: if you want to test my fix for mesa with nvidia in my PPA: https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
[20:00] <siretart`> not sure why, might be just flying bogons or something
[20:01] <tseliot> bryyce: launching blender should be enough
[20:01] <jcristau> siretart`: because compiz is broken, i suspect :)
[20:01] <siretart`> jcristau: wouldn't be the only issue in compiz, true :-)
[20:02] <bryyce> tseliot, ok thanks.
[20:02] <siretart`> I'm really happy that I can now close bug #503255 now. thanks for explaining this stuff to me!
[20:02] <bjsnider> siretart`, how's the ffmpeg fix coming along?
[20:03] <federico1> siretart`: :)  I hope to have it ready soon
[20:03] <tseliot> siretart`: that's because it switched to software rendering
[20:03] <tseliot> no wonder compiz stopped working
[20:03] <siretart`> bjsnider: implemented, submitted upstream and I wait for it to be accepted
[20:03] <bjsnider> cool
[20:05] <coz_> tseliot,  I noticed on lucid that some of the compiz plugins are not working   is this the mesa issue and you ppa fixes that temporarily??  sorry if I am repeating I just arrived here :)
[20:05] <siretart`> tseliot: oh, that's interesting. so you suggest that compiz is able to detect at runtime that the driver decides to disable hw rendering and therefore silently exits?
[20:05] <tseliot> coz_: with what driver?
[20:06] <coz_> tseliot, 190.53
[20:06] <siretart`> sounds plausible. need to think a bit about that on my way home. cu around!
[20:06] <tseliot> siretart`: I don't know how advanced compiz is but I seem to remember that, when it dies, it uses metacity as a fallback
[20:07] <coz_> tseliot,  this was a manual install of the driver also
[20:07] <tseliot> coz_: it could be. Maybe try the fix in my PPA and restart X?
[20:07] <siretart`> tseliot: the 'appearance' system applet (or however it is called) doesn't notice that and leaves the bullet on 'active desktop effects'
[20:07] <coz_> tseliot,  ok I will try that now ...
[20:07] <siretart`> but thats fortunately a rather cosmetic issue
[20:08] <coz_> to coz because he is on another machine :)    https://edge.launchpad.net/~albertomilone/+archive/proprietary-video-improvements
[20:09] <tseliot> siretart`: yes, I doubt there's a way constantly check if compiz is still alive (other than polling)
[20:09] <tseliot> :-)
[20:20] <coz_> successo !
[20:21] <coz_> tseliot,  your fix worked at least for now :)
[20:21] <coz_> looks like keyserver.ubuntu.com is down  however... I couldnt get the key
[20:21] <tseliot> coz_: great! Thanks for testing
[20:22] <coz_> tseliot,  no problem testing...lucid is on another machine  so if anything goes wrong I can always fix or reinstall :)
[20:49] <knittl> update-initramfs didn't help either with the drivers
[20:50] <tseliot> knittl: what does dmesg say?
[20:53] <tseliot> oh, you put a link before
[20:53] <knittl> i piped the output again to http://knittl.is-a-geek.net/public/dmesg
[21:00] <tseliot> knittl: can you reproduce the problem and get the output of "lsmod" and "grep nvidia /etc/modprobe.d/*" please?
[21:02] <knittl> lsmod where? console or failsafe mode?
[21:02] <knittl> there's no nvidia module in lsmod
[21:02] <knittl> hu, it's blacklisted? o.O
[21:03] <knittl> http://paste2.org/p/609332
[21:14] <tseliot> knittl: this is wrong /etc/modprobe.d/blacklist-local.conf
[21:15] <tseliot> type: "dpkg --search blacklist-local.conf" to see what installed it
[21:15] <knittl> i thought so. how did it come in there?
[21:15] <tseliot> that command should tell you
[21:15] <knittl> dpkg: *blacklist-local.conf* not found.
[21:16] <knittl> i know i haven't done it manually ... why would i
[21:16] <Sarvatt> disabling it in jockey maybe?
[21:16] <tseliot> oh
[21:16] <tseliot> but it would be weird
[21:17] <tseliot> (not unlikely though)
[21:17] <knittl> sounds possible
[21:17] <tseliot> knittl: removing that file and rebooting should do it then
[21:17] <knittl> removing the file or its contents?
[21:19] <tseliot> slangasek: I guess no feedback from QA today (and I can't blame them). Some uses tested my package with good results
[21:19] <tseliot> users
[21:19] <tseliot> I think I can safely upload the package
[21:20] <tseliot> (and save us a few bug reports)
[21:22] <knittl> /rebooting
[21:27] <knittl> wheeeeeeee, it booted without giving this stupid error message :)
[21:33] <tseliot> :-)
[21:38] <knittl> thank you, i wouldn't have managed it myself :)
[21:39] <tseliot> np
[21:45] <slangasek> pgraner, apw: can I get a /var/log/dpkg.log from a system that needed the --reinstall of ubuntu5?
[21:57] <tseliot> slangasek: shall I proceed with the upload anyway?
[21:58] <slangasek> tseliot: the mesa upload? I would say so, yes
[21:58] <tseliot> slangasek: yes. Ok
[22:00] <tseliot> uploaded
[22:00] <tseliot> \o/
[22:05] <apw> slangasek, i don't have one here, i'll ask smb to get you one if you still need it
[22:05] <slangasek> apw: yes, still need it
[22:06] <slangasek> I don't understand why the fix that was already applied isn't reliable
[22:07] <apw> slangasek, yeah its pretty perplexing
[22:08] <tseliot> the preinst works (i.e. the alternative is remved) but the 2 modules are not installed :-/
[22:10] <apw> slangasek, smb and cking had the broken ones, cking was fixed by reinstall i believe
[23:04] <tseliot> slangasek: this is from my machine: http://pastebin.ubuntu.com/356270/
[23:05] <slangasek> tseliot: you had the problem of missing files after upgrade?
[23:06] <tseliot> slangasek: yes, on one of my testing boxes
[23:06] <tseliot> well, the only physical testing box
[23:06] <slangasek> hmm
[23:06] <slangasek> and this log hasn't been filtered in any way?
[23:06] <tseliot> no
[23:06] <tseliot> I can upload the full file if you like
[23:07] <slangasek> my only concern is whether there are other package maintainer scripts firing in between what you've shown
[23:09] <tseliot> mesa shouldn't touch that, as its alternatives didn't involve doing anythin with those 2 modules
[23:09] <tseliot> maybe nvidia?
[23:10] <tseliot> apw: those computers had intel or ati, right?
[23:10] <tseliot> no nvidia?
[23:10] <apw> tseliot, they were all intel ones i saw
[23:10] <slangasek> they were all touching the gl_conf alternative, which the others were slaves of
[23:10] <tseliot> right
[23:10] <slangasek> this could be a side effect of only one of the alternatives having the slaves
[23:11] <slangasek> can I see the full log?
[23:11] <tseliot> sure
[23:13] <tseliot> it's in a PM