[01:36] <bryceh> RAOF, I've committed the glx revert to git; shall I go ahead and upload for pitti to review?
[01:37] <skimj> Is it possible to set a conditional umask based on a regex? So that if a file is created with a name matching pattern A it gets permissions X but if it matches pattern B it gets permissions Y?
[01:37] <RAOF> bryceh: Yes please.
[01:37] <bryceh> skimj, wrong channel, this is for X.org discussion
[01:37] <skimj> oops sorry.
[01:37] <skimj> wrong tab
[01:37] <bryceh> RAOF, ok xserver uploading
[01:39] <Sarvatt> \o/
[01:42] <bryceh> will be nice having that one put to bed.  hope there's no serious side effects
[01:43] <bryceh> [ubuntu/lucid] xorg-server 2:1.7.6-2ubuntu7 (Waiting for approval)  
[01:44] <RAOF> We've got a contingency plan in the first upstream commit of the glx-as-resource refactor.
[01:44] <bryceh> right :-)
[02:46] <Sarvatt> bryceh: fixed up that intel 2.8 you put in the retro ppa, backported all of the commits it needed to build against xserver 1.7. but I think you got the versions confused because EXA was ripped out before 2.8 :)
[02:48] <Sarvatt> it actually builds against xserver 1.8 too, going to try it out for the heck of it
[02:51] <Sarvatt> I forgot alllll about the cursor flicker :)
[03:06] <ryan__> I have a ubuntu ppc problem anyone up for the challenge
[03:09] <Sarvatt> i believe #ubuntu-ports is the channel you want?
[03:09] <ryan__> No one in those rooms
[03:09] <ryan__> I guess I will try again
[03:09] <Sarvatt> is it X related?
[03:10] <ryan__> in that my display is limited to 256 in x
[03:11] <ryan__> any attempts to change the xorg fle causes the system to hang at boot
[03:12] <RAOF> You're limited to an 8 bit display?
[03:12] <ryan__> yes and the display option show no other listing in the drop downs
[03:13] <RAOF> What version of Ubuntu?
[03:13] <ryan__> 9.04
[03:13] <ryan__> 9.04 ppc
[03:14] <Sarvatt> ryan__: ati?
[03:14] <ryan__> yes i have a imac g3
[03:15] <ryan__> an
[03:15] <Sarvatt> the jaunty kernel was screwed up for ppc with ati
[03:15] <Sarvatt> can you upgrade to karmic?
[03:15] <ryan__> hmm i had to use a no-video command to install
[03:17] <Sarvatt> i can't remember the specifics but I had the same problem, the powerpc kernel for jaunty was screwed up though due to some patches brought in just before release
[03:18] <ryan__> I guess I can try installing 9.1 with the update manager and see wha happens
[03:18] <Sarvatt> they helped out x86 but screwed up powerpc :(
[03:18] <Sarvatt> ah you have a rage 128 in that thing
[03:18] <Sarvatt> ryan__: http://tjworld.net/wiki/Linux/Ubuntu/PowerPC/AppleiMacG3
[03:19] <Sarvatt> (first hit on google...)
[03:19] <Sarvatt> the "Bug: Xorg doesn't use high-resolution true-colour mode" section specifically
[03:22] <ryan__> i have attempted to change the xorg before
[03:22] <ryan__> any changes cause the boot to freeze
[03:22] <Sarvatt> openfirmware/yaboot are pains in the butt to use with linux, i have a crazy boot stanza to fix consoles
[03:22] <ryan__> i then have to escape to a shell
[03:22] <Sarvatt> (on my ibook)
[03:23] <Sarvatt> are you booting with nosplash?
[03:23] <ryan__> so would it be advised to update to 9.1 before attempting changes
[03:23] <Sarvatt> well the problems I was talking about were limited to radeon I believe, I have a radeon 9200 in my ibook
[03:24] <ryan__> it boots with splah i suppose
[03:30] <ryan__> ok weird i was attempting to modify my yaboot file and i show no files in mnt directory
[03:30] <ryan__> oh
[03:30] <ryan__> reading up a paragraph
[03:30] <ryan__> doh
[03:32] <bjsnider> imac g3 is a bit old
[03:35] <ryan__> hell yes it is
[03:35] <ryan__> i was running it for my kids with panther and panther ate it
[03:38] <ryan__> ok sarvatt i canged the yah boot for no splash screen and odified the xorg i am going to reboot we'll see
[03:39] <Sarvatt> osx 10.3 ate it? i'm scared how slow even ubuntu is going to run on it :)
[04:51] <vish> Sarvatt: the xup2 seems stable , but as Conn mentions it seems to grow much slower.. a lot slower :s
[04:52] <vish> Sarvatt: btw , new_pll=0  still causes jumping screen in new session and guest sessions
[04:52] <vish> with xup2^
[04:52] <Sarvatt> that persons problems are more likely specific to ati and low memory systems and not that bug
[04:54] <vish> ah k..  but the jumping/dancing screen is present with -xup2
[04:55] <Sarvatt> dont know what you're saying, it was fixed without it and now it isn't?
[04:56] <Sarvatt> or new_pll=0 didnt really fix it?
[04:57] <vish> Sarvatt: new_pll=0 did fix the problem .... it is not a problem with the 2ubuntu1 but i get it with -xup2 , i recall it is also a problem with the 2ubuntu5[or the latest lucid stock ] I'll downgrade to the stock as retest
[04:59] <Sarvatt> i'm confused, you weren't using 2ubuntu1 when you said it was fixed, you were using newer?
[05:00] <vish> if i use new_pll=0 with 2ubuntu1 , i dont get the problem of the screen freaking out... but if i use the new_pll=0  with -xup2 i get the screen jumping
[05:03] <skimj> I just got a new(ish) MB with Intel GMA X4500. My xorg log says xvmc is disabled. I've got xorg 2.9, do I need 2.10 to get xvmc or is there something else? It looks like the video is using the i915 driver.
[05:03] <Sarvatt> i'm confused because there's no way you were using 2ubuntu1 when you tried new_pll because 2ubuntu2-5 were released around the same time as ati 6.13 that you were testing downgrades on?
[05:04] <Sarvatt> (when you said it was working) just trying  to narrow down where it might be
[05:04] <Sarvatt> skimj: xvmc is 100% useless but if you want to use it with lucid you need to disable KMS
[05:05] <Sarvatt> or upgrade to 2.10+ to use it with kms yeah
[05:07] <skimj> OK. I'll try 2.10. Why do you say it's useless? I'm trying to get mythtv to run without stuttering. I just upgraded the MB (with video) trying to improve things. XvMC seems to be the only thing wrong in any of the logs.
[05:07] <vish> Sarvatt: hrm... the 2ubuntu1 was because i was downgrading earlier to avoid the memory leak.. I believe it is a problem again after update 2ubuntu3 -> 2ubuntu5 ... I'll test each version and let you know which is the problematic version
[05:08] <vish> Sarvatt: btw , why isnt new_pll=0 the default for the rv515 cards?  I'm still having to add it to the kernel line
[05:08] <Sarvatt> 2ubuntu5 is the only real change but i dont see how those could be causing it
[05:09] <Sarvatt> ask the kernel team :)
[05:09] <vish> hehe ;)
[05:11] <Sarvatt> did everything i could short of writing the patches myself, identified what the problem was and what gpu's were affected and brought it up on the kernel list with a list of all reports that need the quirking..
[05:16] <Sarvatt> maybe you can poke someone since you work for canonical? :)
[05:19] <Sarvatt> if its really a problem with 2ubunu5 and not with 2ubuntu1 (even though you need new_pll=0 still) thats interesting
[05:27] <vish> Sarvatt: hmm , i dont work for canonical, but will poke folks :)
[05:59] <Sarvatt> https://bugs.freedesktop.org/show_bug.cgi?id=27510
[05:59] <Sarvatt> seems thats hitting a lot of ati users
[06:01] <Sarvatt> oh bryce already forwarded another report about that
[06:01] <skimj> Sarvatt: would you be willing to help debug a bit? I added the xorg-edgers ppa and did an upgrade. Now the intel module fails to load. Here's a snippet from the xorg log http://paste.ubuntu.com/420830/
[06:02] <Sarvatt> you didnt upgrade intel for some reason?
[06:03] <Sarvatt> you need to update everything in that ppa, it's not compatible with lucid packages
[06:04] <Sarvatt> it was probably because i didn't upload an xorg metapackage yet and you did a safe upgrade so it didn't remove xserver-xorg-video-all/etc
[06:05] <Sarvatt> try a sudo apt-get dist-upgrade?
[06:05] <skimj> so I did an apt-get upgrade which got a lot of things. X failed to load after that so I did an apt-get update ...intel 
[06:06] <skimj> OK I'll try it with the dist-upgrade.
[06:06] <Sarvatt> did it say any packages were held back?
[06:07] <skimj> yes, I've got 4 packages held back
[06:07] <Sarvatt> which?
[06:07] <skimj> knm-runtime kopete network-manager-kde plasma-widget-networkmanagement
[06:07] <Sarvatt> ah not related
[06:08] <Sarvatt> dist-upgrade offering intel?
[06:08] <vish> hmm,.. what was the command to downgrade a package , which has the deb in /var/cache/apt/archives?
[06:09] <skimj> nope. It's offering libmsn0.3, knm-runtime kopete network-manager-kde
[06:09] <Sarvatt> whats the version on your installed xserver-xorg-video-intel package?
[06:10] <skimj> 2:2.11.0+git20100422.72fd7d19-0ubuntu0sarvatt2
[06:10] <Sarvatt> huh
[06:11] <Sarvatt> did you ever compile intel from source in /usr/local or anything?
[06:12] <Sarvatt> oh sorry it says /usr/lib/xorg/modules/drivers/intel_drv.so there
[06:12] <skimj> nope never from source. I did have everything from the ppa installed, then I uninstalled with the ppa-purge tool, and now reinstalled
[06:13] <Sarvatt> i'm stumped, can you try again and paste the full log?
[06:13] <skimj> try from reboot?
[06:14] <Sarvatt> yeah
[06:14] <Sarvatt> absolutely sure you had 2.11 installed when you booted there?
[06:15] <Sarvatt> hmm wait
[06:15] <Sarvatt> why isnt it 2.11.0+git20100422.72fd7d19-0ubuntu0sarvatt3 ?
[06:16] <skimj> yes, I did. So here's the weird thing. It's working now. The only change was dist-upgrade with knm-runtime kopete network-manager-kde plasma-widget-networkmanagement
[06:16] <Sarvatt> nevermind thats a local build with pageflipping disabled... :)
[06:18] <Sarvatt> thats really odd skimj, probably can find out why from your /var/log/apt/term.log
[06:21] <skimj> if you want to look at the term.log: http://paste.ubuntu.com/420830/
[06:22] <vish> Sarvatt: how do i downgrade a package to one which is in the /var/.../cache?
[06:22] <Sarvatt> dpkg -i /path/to/file?
[06:22]  * vish tries
[06:22] <Sarvatt> skimj: that was the xorg log snippet link
[06:24] <Sarvatt> skimj: i've got to run, about to pass out. its all working now though?
[06:25] <skimj> oops sorry. http://paste.ubuntu.com/420837/
[06:25] <skimj> yes, it's all working now. Thanks.
[06:26] <vish> bah didnt work... /me downloads package .. is easier ;)
[06:28] <Sarvatt> thats really odd, why didnt intel get upgraded there.. you're also missing synaptics
[06:29] <Sarvatt> skimj: something definitely went funky there, it didn't pull in synaptics either
[06:29] <skimj> should I do something different?
[06:30] <Sarvatt> do you have xserver-xorg-input-synaptics installed?
[06:31] <skimj> I don't see it
[06:32] <skimj> i just forced it with apt-get install xserver-xorg-input-synaptics
[06:32] <Sarvatt> install xserver-xorg-video-all and xserver-xorg-input-all?
[06:33] <Sarvatt> i'll upgrade a bunch of systems tomorrow and see if i can figure out what happened, got me stumped
[06:33] <skimj> FWIW, that's also pulling in video-ati
[06:34] <skimj> OK, let me know if I can get you any more info, logs, etc.
[06:35] <Sarvatt> something tells me the ppa-purge might have messed up, and it fell back to aptitude and offered a solution involving removing some packages
[06:36] <Sarvatt> must pass out though, sorry for the trouble and thanks for pointing out the problems :)
[07:07] <Sarvatt> darnit, i just had to start updating another machine to edgers and now i'm back :D bjsnider have you seen any nvidia blob releases that work with xserver 1.8 without IgnoreABI by any chance?
[08:42] <ricotz> Sarvatt, i think you can include the ia32-lib from https://launchpad.net/~ricotz/+archive/staging/+packages now?
[08:47] <ricotz> RAOF, hello, or perhaps you can ^
[12:25] <bjsnider> Sarvatt, which one is xserver 1.8?
[12:26] <jcristau> eh?
[12:32] <bjsnider> is that the one in lucid?
[12:34] <jcristau> no
[12:34] <jcristau> it's the one in f13
[12:40] <bjsnider> well, nvidia has to be given a bit of time to update their driver for it i suppose
[12:43] <jcristau> first release candidate was over 2 months ago.  considering the ABI bump is trivial this time, that should be more than enough...
[12:44] <bjsnider> i think the hdmi audio issue is a much bigger problem
[12:44] <bjsnider> it's a longstanding issue that is keeping some people on the 185
[12:44] <bjsnider> they've had plenty of time to fix that one
[14:30] <Ng> ooh, I see the gem leak bug is fix committed
[14:30] <Ng> did we revert the glx backport or just drop in the extra patch RAOF found?
[14:32] <jcristau> the former afaik
[16:34] <Sarvatt> bjsnider: the 195 drivers supported xserver 1.8 for months but you need to use IgnoreABI, was just wondering if you had come across any newer betas or anything so I could put them on xorg-edgers but I dont see any
[17:22] <Alan> Hi, I'm having a problem setting my button map for my mouse
[17:22] <Alan> I used to set it with a HAL policy, now it looks like i should be seting it with a udev rule
[17:23] <Alan> I've got the udev rule set up correctly, and "udevadm info ..." shows that x11_options.ButtonMapping is set and correct on my mouse device, however X is completely ignoring this button mapping
 on the machines I tested, fbc would get enabled, but actuall take more power
 because it never finished a compression pass
 a few others reported the same thing
 that may be why the feature isn't enabled on windows
[17:30]  * Sarvatt doesn't feel bad about submitting a patch completely disabling FBC on 915-945 now
[18:32] <Alan> Ok, so i fixed my problem, it appears that Ubuntu Lucid has already deprecated configuring X with udev?
[18:32] <Alan> or maybe jsut some aspects?
[18:36] <Sarvatt> Alan: yeah, udev is used transparently now, you configure things through xorg.conf or xorg.conf.d snippets and it is described pretty well in man xorg.conf
[18:36] <Sarvatt> i have to run but i can point you to wiki's describing the new world order that is much easier to manage in about 45 minutes
[18:39] <Alan> Sarvatt: but is it right that it should ignore properties set in udev rules?
[18:41] <Alan> huh, i just found an article about the new configuration stuff...
[18:59] <bryceh> Sarvatt, btw do you have much feel for the status of multi-card support (3+ displays) upstream?  I know that's work being done but is it likely to be Meerkat material?
[19:18] <Sarvatt>  Alan: sorry for the delay, ended up running late. http://fedoraproject.org/wiki/Input_device_configuration is a really good guide, our xorg.conf.d snippets are in /usr/share/X11/xorg.conf.d/ if you want to see whats there currently. if you want to change options you just add an InputClass section to your xorg.conf with the options you want in it
[19:18] <Sarvatt> err sorry, lucid's are in /usr/lib/X11/xorg.conf.d/
[19:20] <Sarvatt> i dont know what device you are setting up but for synaptics for instance you can see the full list of options in man synaptics (or synclient -l)
[19:25] <Sarvatt> bryceh: need to look into it more but from what I know, GPU switching for systems with multiple GPU's yes, multiple GPU's at the same time no way
[19:26] <Sarvatt> bryceh: you can do 3+ displays on ati 5xxx though with 1 GPU
[19:27] <bryceh> know if anyone's tested that with an ati 5xxx on lucid?
[19:29] <Sarvatt> pretty sure lucid can't handle it at all, we dont even have KMS support for them
[19:29] <Sarvatt> its weirdly limited too, you have to use certain combinations of connectors to do it
[19:29] <Sarvatt> http://www.botchco.com/agd5f/?p=51 is an *awesome* summary of it
[19:30] <bryceh> aha thanks
[19:30] <Sarvatt> i'm sure fglrx can handle it, no experience with it at all though
[19:31] <Sarvatt> i'm seeing reports of odd problems on 5xxx with stock lucid though, one connector works and the other doesn't, stuff like that
[19:36] <Sarvatt> pretty sure arrandale/clarkdale can handle 3+ displays too, know i saw a commit from jbarnes mentioning it
[19:37] <Sarvatt> in the increase the stride limit on igdng commit
[19:42] <bryceh> mm
[19:46] <Dr_Jakob> Sarvatt, bryceh: so the packages that are in the repos now will go out on the final iso?
[19:50] <Sarvatt> Dr_Jakob: your vmmouse fix got uploaded on the 19th, the archive was just frozen for the RC and its in the archive now
[19:50] <Dr_Jakob> Yeah, I verified that the fix was in the stuff I pulled from the repo.
[19:51] <Sarvatt> Dr_Jakob: nah there will be more updates that are just major bug fixes no doubt
[19:51] <Sarvatt> the vmmouse update will be on the daily iso from today, it just isn't in the -rc release cd
[19:52] <Dr_Jakob> Right, and the final iso will be based on one of the dailies?
[19:54] <Sarvatt> whatever's in the archive at the time it's made, probably on tuesday? not sure of the exact date
[19:55] <Sarvatt> bryceh: looks like i was wrong about that commit saying 3 displays was possible - " It can go up to 32k.  Upping this lets me use my 2560x1600 and 1920x1200 monitors in an extended desktop configuration."
[19:57] <Sarvatt> bryceh: i'm pretty sure you can do displays on multiple GPU's with seperate screens on nvidia with the blob?
[19:57] <bryceh> yes
[19:57] <Sarvatt> i've seen a bug about it at least and it needed lots of xorg.conf fiddling
[19:58] <bryceh> right, with nvidia it's done via xorg.conf-ary
[19:58] <Sarvatt> think i'll dig through the arrandale docs and see what it has to say :)
[19:58] <bryceh> the nvidia config program takes care of that a bit
[19:59] <Dr_Jakob> Ok, thanks. I got a bunch of managers breathing down my neck about this bug.
[19:59] <Sarvatt> they pulled them off the intel website but i saved copies
[19:59] <bryceh> I guess there's one thing we can be certain of
[19:59] <bryceh> when this feature becomes available, in order to integrate it we'll probably have to break everything else
[19:59] <bryceh> that's just how intel rolls ;-)
[20:00] <Sarvatt> Dr_Jakob: have you seen the bug where a messed up xkb layout is getting applied from the vmware autoinstaller (?) and the keyboard isn't usable for login?
[20:01] <Sarvatt> trying to dig it up, it's gotten alot of dupes
[20:01] <Dr_Jakob> Sarvatt: can't say I have. Do you have a bug number.
[20:01] <Sarvatt> digging for it
[20:01] <vish> Sarvatt: the second session ,  screen jumping bug: .. it happens with 2ubuntu1 as well :/  it seems the new_pll=0 only works and keeps thing quite for some time ~6hrs of uptime, then it happens , everything is still jumping :(
[20:03] <vish> so if you are testing the bug with a fresh boot ,  and try the guest session it wont have a problem , but after ~6hrs the problem arises even with new_pll=0
[20:03] <Sarvatt> darnit where is it hiding
[20:06] <Sarvatt> Dr_Jakob: https://bugs.edge.launchpad.net/ubuntu/+source/console-setup/+bug/548891
[20:11] <Dr_Jakob> Sarvatt: hmm so we are not hitting this issue as far as I can tell in the beta of the Fusion/Workstation/Player.
[20:13] <Sarvatt> ah nice, is it publically available? i'll mention that when the next person asks about the problem
[20:13] <Dr_Jakob> http://communities.vmware.com/community/beta/ws
[20:14] <Dr_Jakob> Tho looking at the forums, I can see that somebody has reported it.. hmm.
[20:15] <Dr_Jakob> Oh, its after you update console-setup.
[20:16] <Sarvatt> btw I plan on enabling svga in the xorg-edgers PPA here soon, it's already enabled in the 10.10 kernel config and I have that in xorg-edgers, just need to package up the libdrm/mesa sides 
[20:17] <Dr_Jakob> Its totaly unsupported
[20:17] <Dr_Jakob> Just FYI
[20:18] <Sarvatt> that's what xorg-edgers is all about :)
[20:18] <Dr_Jakob> just make sure you have video-vmware version 11.x.y
[20:20] <Sarvatt> it'll have git master updated whenever i see changes
[20:20] <Dr_Jakob> right ok good.
[20:21] <Sarvatt> changes there don't go to the xorg-commit mailing list do they?
[20:21] <Dr_Jakob> Hmmm
[20:21] <Dr_Jakob> they do.
[20:22] <Dr_Jakob> http://lists.freedesktop.org/archives/xorg-commit/2010-February/025157.html
[20:22] <Sarvatt> ah ok just haven't seen a commit in awhile
[20:23] <Dr_Jakob> I have been stuck fixing weird input driver bugs ;-)
[20:23] <Dr_Jakob> Also video-vmware only holds the old video driver and driver selector.
[20:23] <Dr_Jakob> the 3D enabled driver comes from mesa
[20:26] <Sarvatt> speaking of which i need to update that in edgers now anyway because of the new abi in there
[20:28] <Dr_Jakob> Sarvatt: I like to in advance apologies for the circular dependancy between mesa and xorg for when added the X org driver to mesa.
[20:29] <Sarvatt> yeah I've already been down that road when I was first enabling nouveau gallium and building the xorg state tracker by mistake :)
[20:35] <Dr_Jakob> Sarvatt: do xorg-edgers ship r300g?
[20:36] <Sarvatt> it's a work in progress, we've got it in another PPA at the moment trying to work out how to package it
[20:36] <Dr_Jakob> ok
[20:36] <Sarvatt> can you give me any tips on packaging gallium dri drivers at the same time as classic dri drivers? for instance i'm unsure what happens when both radeon_dri.so and radeong_dri.so exist at the same time
[20:37] <Sarvatt> like for nouveau or svga it's no issue to package them together with classic dri
[20:39] <Sarvatt> too bad tormod isn't here, he's the one most interested in shipping r300g and has been trying to work it out here - https://edge.launchpad.net/~xorg-edgers/+archive/radeon/+packages
[20:40] <Dr_Jakob> the X driver tells libGL which driver to load, for radeon this is currently "radeon", libGL then adds /path/*_dri.so and dlopens it.
[20:40] <Dr_Jakob> so just adding radeong_dri.so wont break anything.
[20:42] <Sarvatt> ah ok so actually having the gallium driver be radeon_dri.so is going to be required
[20:43] <Dr_Jakob> yeah, or adding a xorg.conf option to tell the driver to say radeong instead of radeon.
[20:44] <Dr_Jakob> maybe even add it to xorg.conf.d if that works for video drivers.
[20:53] <Sarvatt> hmm you can specify it to load radeong_dri.so in xorg.conf or just the path to radeon_dri.so? I didn't know that was possible but it would greatly simplify it if you could specify the name and not have to rename things
[20:55] <Dr_Jakob> You can't now, but it wouldn't be hard to make the driver look obey a "DRIDriverName" option.
[20:57] <Sarvatt> ah ok I get it now, it'd use radeong_dri if I went and used radeong_drv also
[20:59] <Dr_Jakob> Hmm dunno, it might be hardcoded to "radeon" inside the driver or the name of the driver.
[21:06] <BUGabundo> http://www.phoronix.com/vr.php?view=ODE3MA  what's this I read about an X mem leak??
[21:07] <Sarvatt> BUGabundo: fixed already and didn't affect you on nvidia, it sure was good for ad revenue I'm sure though
[21:08] <BUGabundo> I bet
[21:09] <Sarvatt> oh hoh, looks like I might be able to abuse --with-dri-searchpath to have it look in the gallium directory first, then split the gallium drivers out to another package mangling the names that isn't installed by default
[21:11] <virtuald> there's a newer xorg-server in main that in the x testing ppa
[21:12] <virtuald> than*
[21:16] <Sarvatt> virtuald: do you mean x-updates? because the one from there was uploaded to main, its the same thing
[21:23] <Sarvatt> this --with-dri-searchpath hack just might work :)
[21:42] <Sarvatt> so i'm thinking build everything at once in the config-dri rules target that has --with-dri-searchpath=/usr/lib/dri-gallium:/usr/lib/dri, only install mesa classic dri (and nouveau/svga) in /usr/lib/dri, copy the gallium dri drivers to /usr/lib/dri-gallium/ with the expected names, and have a seperate libgl1-mesa-dri-gallium (or whatever) package that's optionally installed with the /usr/lib/dri-gallium stuff
[21:43] <Sarvatt> guess it doesn't matter where nouveau goes, it just works fine in /usr/lib/dri
[21:44] <Dr_Jakob> sounds good
[21:44] <Dr_Jakob> Could I request that the vmwgfx_dri.so ends up in the correct place?
[21:45] <Dr_Jakob> That is /usr/lib/dri
[21:45] <Sarvatt> ah yeah need to work out how to handle that right since it'll have the _drv.so too right?
[21:46] <Dr_Jakob> just stuff that into /usr/lib/xorg/modules/drivers/
[21:46] <Dr_Jakob> vmware_drv.so will then check if your enviroment is sane and load it.
[21:48] <Dr_Jakob> if not it will fallback to vmwlegacy_drv.so  (renamed vmware_drv.so, the new vmware_drv.so is just a driver picker liker ati_drv.so).
[21:49] <Sarvatt> yeah whenever I get that together it'd probably be better off in a seperate package installing both anyway
[21:51] <Dr_Jakob> well the driver picker is quite paraniod about the enviroment (must be able to load vmwgfx_drv.so, must be able to open the drm device) otherwise it falls back to the old driver.
[22:03] <Sarvatt> yeah i'll make sure it's all in /usr/lib/dri and /usr/lib/xorg/modules/drivers when i do it, nice that you have vmware picking the right one instead of having to patch xf86AutoConfig.c to add vmwgfx :)
[22:15] <Sarvatt> jcristau: is there any way to give other people access to personal branches on git.debian.org? like if tormod created a mesa packaging branch on there and I wanted to commit to it
[22:23] <bdmurray> isn't bug 568605 a dup of bug 564181?
[22:30] <bryceh> bdmurray, maybe
[22:31] <bryceh> bdmurray, with X freezes I've learned from experience not to dupe them together too aggressively
[22:32] <bryceh> it's better to forward each one upstream and let the experts tell us that they're dupes rather than guess wrongly and lose a bug in the cracks
[22:33] <bryceh> also even if they are the same bug sometimes having several users investigating them in parallel can make it easier to find the solution since there's more eyes and hands 
[22:33] <bryceh> once a solution is found, often then it is pretty straightforward to identify dupes via ppa testing
[22:34] <bryceh> also I hate the "X freezes" me-too bugs of death ;-)
[23:05] <jcristau> Sarvatt: use acls?