[00:51] <Sarvatt> looks like pm-utils needs an update for nvidia, no wonder suspend wasnt working
[00:51] <Sarvatt> using_nvidia() {  [[ -d /sys/module/nvidia ]]; }
[00:51] <Sarvatt> (should be nvidia-current or whatever?)
[00:51] <Sarvatt> in /usr/lib/pm-utils/sleep.d/98-video-quirk-db-handler
[00:53] <kklimonda> Sarvatt, can you build new lbm for -13 kernel? I have no idea how to do it the right way :)
[00:53] <Sarvatt> have_nvidia_g80() looks like it will take affect if nouveau is in use on a g80 and add --quirk-vbe-post that shouldnt be there too
[00:54] <RAOF> kklimonda: It's surprisingly easy.  You just add a new changelog entry as 2.6.32-13.something.
[00:54] <BUGabundo> Sarvatt: and nouveau ? I can't get my LCD back after suspend to ram
[00:54] <BUGabundo> haven't tested hibernation yet
[00:55] <kklimonda> RAOF, oh? I got scared by all those control.stubs :)
[00:55] <Sarvatt> yeah looks like pm-utils needs some adapting for all this new stuff, not surprised
[00:55] <kklimonda> probably should just run debuild -S and see how it works
[00:55] <BUGabundo> cool
[00:55] <BUGabundo> ping me back once those are done, and ill test again
[00:55] <Sarvatt> the ddx depends on -12 too, needs more than just lbm bumped
[01:00] <Sarvatt> sheesh theres a *ton* of vendor specific quirks in pm-utils that kind of dont take into account if kms and such is used from what i see
[01:02]  * BUGabundo hands an eraser to Sarvatt
[01:03] <Sarvatt> anyone know what the older nvidia kernel modules are renamed to?
[01:03] <Sarvatt> besides nvidia-current
[01:08] <Sarvatt> looks like its nvidia-173 and nvidia-96
[01:09] <bryceh> yeah
[01:10] <Sarvatt> using_nvidia() {  [[ -d /sys/module/nvidia-current || /sys/module/nvidia || /sys/module/nvidia-173 || /sys/module/nvidia-96 ]]; } works
[01:10] <Sarvatt> err
[01:10] <Sarvatt> [[ -d /sys/module/nvidia-current || -d /sys/module/nvidia || -d /sys/module/nvidia-173 || -d /sys/module/nvidia-96 ]]
[01:15] <Sarvatt> elif have_nvidia_g80; then
[01:16] <Sarvatt> if i want to extend that to have_nvidia_g80 and !=have_kms what would it be?
[01:16] <Sarvatt> pushing changes here - https://code.edge.launchpad.net/~sarvatt/ubuntu/lucid/pm-utils/bugfixes
[01:17] <bryceh> gonna do a merge proposal on that?
[01:19] <Sarvatt> or should i extend_nvidia_g80() to return 0 if have_kms or else do what it does now
[01:20] <Sarvatt> yeah, want to test it first though
[01:21] <bryceh> how proper of you ;-)
[01:22] <Sarvatt> oh the have_nvidia_g80 check is after the have_kms check and wouldnt get called i think
[01:39] <superm1> Sarvatt, if that's all it was for fixing suspend on all nv hardware, owe ya a beer :)
[01:41] <superm1> could you maybe just do an 'if ls /sys/module/nvidia* >/dev/null 2>&1' or similar though?
[01:42] <superm1> that would hopefully cover beta versions and what not too
[01:42] <Sarvatt> ah yeah good point
[01:42] <Sarvatt> corrupted screen on resume, bah
[01:44] <Sarvatt> http://pastebin.com/f3feec8de http://pastebin.com/f1cc31346
[01:49] <Sarvatt> hmm that one was funky
[01:50] <Sarvatt> came back to a black screen, switched vt's to 7 and got the unlock message, then it looks like gdm restarted and asked me to log in again
[01:50]  * Sarvatt tries without plymouth
[01:51] <Sarvatt> wonder how i get more verbose info out of pm-suspend
[02:02] <Sarvatt> there we go, PM_DEBUG env variable
[02:11] <Sarvatt> yeah that pm-utils change doesnt do anything, its still /sys/module/nvidia/ even though its aliased to nvidia-current
[02:11] <Sarvatt> darn
[02:38] <bryceh> Sarvatt, I've sponsored your plymouth patch for nouveau
[02:38] <bryceh> I don't know whether they maintain the packaging in bzr, but if so you may need to push it in there
[03:14] <Sarvatt> thanks bryceh! looks like udev went in too, doesn't look like pm-utils needs an update after all after looking into it more.. 
[03:15] <Sarvatt> anyone have a nvidia box thats able to suspend/resume with the blob? even if it's on karmic. i'd like to see your /var/log/pm-suspend.log after running sudo PM_DEBUG=true pm-suspend if so :)
[03:16] <Sarvatt> i got it resuming, but it just sits at a black screen until I vt switch a few times to get back and it looks like a really common problem
[03:20] <kklimonda> heh - I was going to say that hibernation works with nouveau just fine (had to add resume=/dev/sda2 by hand to command line arguments) and then X crashed after I've pressed enter..
[03:28] <Sarvatt> might want to try removing quiet splash and try again, i've heard people getting the crash hitting enter from plymouth
[03:32] <kklimonda> Sarvatt, it was with quiet splash removed :)
[03:39] <bryceh> Sarvatt, yeah pitti helped with udev yesterday
[03:39] <bryceh> Sarvatt, I've let apw know to put out l-b-m now
[03:43] <Sarvatt> i just crashed after hitting enter right after booting - http://pastebin.com/f49b04d77
[03:53] <Sarvatt> hmm https://bugs.edge.launchpad.net/ubuntu/+source/libxext/+bug/519576
[03:53] <ubottu> Ubuntu bug 519576 in libxext "Race condition in libXext" [Undecided,New]
[03:54] <Sarvatt> fixed in our libxext 1.1.1 but could be backported
[03:57] <Sarvatt> well they turned off shm support in chrome now to work around it
[04:00] <johanbr> Sarvatt, well I can suspend/resume, but I have to switch vt's a few times too
[04:00] <johanbr> still interested in a log?
[04:00] <Sarvatt> nah its the same as here if thats the case, wondering what happens in a working suspend thats different
[04:01] <Sarvatt> thank you though
[04:01] <johanbr> you're welcome
[04:16] <Sarvatt> tjaalton: https://bugs.edge.launchpad.net/ubuntu/+source/x11proto-dri2/+bug/520796
[04:16] <ubottu> Ubuntu bug 520796 in x11proto-dri2 "Sync x11proto-dri2 2.2-1 (main) from Debian unstable (main)" [Undecided,New]
[09:13] <BUGabundo_remote> good morning
[09:13] <BUGabundo_remote> please advice: http://paste.ubuntu.com/374554/p://past!
[09:13] <BUGabundo_remote> please advice: http://paste.ubuntu.com/374554/
[09:14]  * BUGabundo_remote has week paste fu so early
[09:14]  * BUGabundo_remote and English skills too, it seems
[09:19] <RAOF> I think someone's updated the DDX to depend on the -13 l-b-m, but the -13 l-b-m has not been built yet.
[09:20] <RAOF> Read: now isn't the time to upgrade.
[09:21] <BUGabundo_remote> ok
[09:21] <BUGabundo_remote> no full upgrade for me then
[09:21] <BUGabundo_remote> I did a safe upgrade
[09:21] <BUGabundo_remote> and it did remove linux-backports-modules-nouveau-2.6.32-12-generic
=== Sinnerman is now known as Cobalt
=== Sinnerman is now known as Cobalt
=== Sinnerman is now known as Cobalt
=== Sinnerman is now known as Cobalt
[15:03] <bjsnider> tseliot, with the 195 driver, did you have to create any symlinks for the new files included in that driver?
[15:06] <tseliot> bjsnider: honestly I don't remember, let me check
[15:08] <tseliot> bjsnider: yes, links for libOpenCL and libnvidia-compiler
[15:09] <bjsnider> because you're worried about the linker not being able to find them?
[15:10] <bjsnider> i was really hoping you'd say no, but i couldn't be that ucky
[15:10] <tseliot> bjsnider: no, the linker should find them when you're using nvidia as they are in /usr/lib/nvidia-current/
[15:10] <bjsnider> well, i have to modify the old build scripts
[15:10] <tseliot> aah, now I see why you were asking
[15:10] <bjsnider> why create symlinks then?
[15:11] <bjsnider> i don't understand the purpose of it
[15:11] <tseliot> yes, if you want to make a backport you will have to modify it
[15:11] <tseliot> the purpose of what?
[15:11] <bjsnider> i can see in the old scripts that you're deliberately creating symlinks for some of the shared libs. why is that necessary?
[15:12] <tseliot> do you mean, when I create .so and .so.1?
[15:13] <bjsnider> well, i don't have the scripts in front of me right now, but i guess so
[15:16] <tseliot> bjsnider: maybe have a look at this page? http://www.linux.org/docs/ldp/howto/Program-Library-HOWTO/shared-libraries.html
[15:18] <bjsnider> i don't understand why, if .so and .so.1 are necessary, nvidia didn't include them.
[15:20] <bjsnider> tseliot, i was just going to put the opencl libs in the nvidia-glx-xxx package. is that how you would do it?
[15:21] <tseliot> bjsnider: the nvidia installer would create those links, see the manifest file (it's a hidden file in their installer)
[15:21] <tseliot> bjsnider: yes, that would be fine
[15:22] <bjsnider> did you also install that file to the /etc directory?
[15:25] <tseliot> bjsnider: nvidia.icd? Yes, it does't hurt to install it
[15:25] <bjsnider> of course debian upstream creates a whole separate opencl package at this point
[15:45] <tseliot> superm1: it looks like in new releases of fglrx the modaliases file is empty. I guess they removed the ids from the driver which is why I think we'll have to generate a kernel module and extract the ids with modinfo from there
[16:20] <superm1> tseliot, are you sure of this?  are you looking at generic releases, or releases intended for an OEM?
[16:21] <superm1> i'm wondering if perhaps they are stripping it out in the releases intended for OEM (because these are tied to SSID instead)
[16:21] <tseliot> superm1: is 8.70 an OEM release?
[16:21] <superm1> tseliot, it depends where it came from
[16:21] <tseliot> it could be then
[16:22] <superm1> this is just a theory i'm suspecting though, I don't know for sure
[16:22] <tseliot> I'll check a new release from AMD's website when I'm back home
[16:22] <tseliot> just to be sure
[16:22] <superm1> that or check the latest beta that they've posted it
[16:24] <tseliot> yes, that too
[16:38] <pgraner> bryceh: you about?
[16:42] <apw> bryceh, we have any feel for whether any ati cards are working with KMS, are the issues leaning towards 'turn off for these cards' or 'turn off'
[16:42] <apw> upstream saying 2.6.33 will have a longer support life seems to fly in the face of stable teams plans
[16:43] <jcristau> i guess rhel will ship with the .33 radeon stuff backported
[16:44] <apw> that is one hell of a heap of backport
[16:44] <apw> and if you pull back radeon you are pulling back drm, and then you need i915 etc to match
[16:44] <apw> how much of 2.6.32 are you left with
[17:20] <tjaalton> apw: is that a problem? it's just one subsystem (a big one at that, in terms of LOC), and becoming more and more important due to kms..
[17:37] <apw> tjaalton, replaceing the whole of drm ... thats a biggie surley, all the testing is rendered meaningless
[17:37] <apw> and we don't get long term support goodness from stable as its not .32 anymore
[18:01] <Sarvatt> how about just having a linux-backports-graphics people can opt-in to with KMS enabled ati and all the rest of drm, and making ati default to modeset=0 ala karmic in 2.6.32-x? could we extend the installer to install the backports by default for certain pci id ranges if it was on the cd?
[18:03] <Sarvatt> or make it show up in jockey for people to pick
[18:05] <tjaalton> apw: .32.x probably won't get much drm updates, probably only intel
[18:05] <tjaalton> duh, damn evening messing my language :)
[18:05] <Sarvatt> intel is expecting people to backport 2.6.33 features (overlay support) to use 2.10 too :( 
[18:05] <tjaalton> +up
=== Sinnerman is now known as Cobalt
=== Sinnerman is now known as Cobalt
[18:18] <Sarvatt> we could just add a postinst to -radeon checking the pci id and disabling KMS for r100 (and maybe some others like RS480)
[18:22] <Sarvatt> that would be something safe to update post-release as we find new ones with problems and need to be disabled.. I still think modeset=0 should be the default for radeon if we arent backporting though and instead have whitelisted cards
[18:23] <Sarvatt> apw: I dont know if you've seen but 2.6.33's radeon needs extra firmware not in linus' tree or linux-firmware for ati hd2xxx and newer cards also, just something else to look out for if its backported
[18:39] <bryceh> pgraner, apw, yeah the kms+2.6.32 combo is proving to be pretty bug ridden.  We need to either turn it off, or backport 2.6.33 there.
[18:40] <bryceh> pgraner, apw, I know there's lots of strong desire to have kms across the board, which means 2.6.33, but if that's not feasible to do then yeah kms probably should be shut off.  Otherwise we're going to be breaking a lot of systems
[18:40] <pgraner> bryceh: noted, apw can speak better to the backport work
[18:41] <pgraner> bryceh: I have some funky nouveau stuff to show you some time
[18:41] <bryceh> ok
[18:42] <pgraner> bryceh: very strange things on my card, I get X on my left monitor, on my right monitor I get a console vt
[18:42] <pgraner> bryceh: and I can switch between them using ctl-alt-F1 for text & ctl-alt-F7 for X
[18:42] <bryceh> pgraner, we're in a similar boat with nouveau btw.  In order to get fixes from upstream we must be pulling from the 2.6.33 drm tree.
[18:42] <bryceh> wow, that's a bug I've not heard of before
[18:43] <pgraner> bryceh: I'll make a video and send it to ya
[18:43] <pgraner> bryceh: its a: nVidia Corporation G92 [GeForce 9800 GX2]
[18:45] <bryceh> hmm, weird well file a bug via ubuntu-bug xserver-xorg-video-nouveau and post the video and any other useful info there
[18:45] <pgraner> bryceh: wilco
[18:46] <bjsnider> gx2, so there are dual gpus
[19:06] <bjsnider> pgraner, there's a nouveau channel that has all of the devs in it including skeggs
[19:07] <bjsnider> i wonder if the dual gpus might be an issue
[19:38] <Sarvatt> not sure if i got disconnected or not but - <Sarvatt> oh wow, we *really* need to update libdrm it looks like, that fix fixed more than just 915-945 with intel 2.10+, people were hitting the crashes on vt switching and lid close as well 
[19:38] <Sarvatt> https://bugs.launchpad.net/bugs/505271
[19:38] <ubottu> Ubuntu bug 505271 in linux "[gm45] "*ERROR* Execbuf while wedged" when closing laptop lid with compiz running" [Unknown,Confirmed]
[19:42] <Sarvatt> had a chance of crashing on anything triggering an interrupt without the fix it looks like
[19:45] <Sarvatt> asking for a new libdrm release, been 2 months and theres other major changes like radeon KMS enabled by default as well as the fixes
[19:48] <Sarvatt> we should probably just do a git snapshot if theres no release soon, other fixes in there like the <=915 fence starvation fix and we already have a 9 patch series of backports for nouveau thats outdated and needs updates already
[19:50] <Sarvatt> what are we going to do about intel 2.10 though, we either need the overlay stuff from 2.6.33 backported to 2.6.32 like intel wants, ifdef out the overlay code in 2.10 and dont use it (blocking off people from using it even if they use a newer kernel with support) or install i915_drm.h in libdrm-dev and have libdrm-dev replace linux-libc-dev
[19:52] <Sarvatt> just reverting this would be enough if we use the second option it looks like http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=bd81734465912d79d6320a6fb021ce43d258b906
[19:53] <Sarvatt> would be so much nicer if the drm headers weren't installed in linux-libc-dev since they want people using the libdrm-dev headers now because everything has runtime feature detection
[20:01] <tjaalton> yes that's where upstream is going
[20:03] <jcristau> they just went the other way a few months ago..
[20:06] <bryceh> Sarvatt, airlied seemed to suggest they were thinking of putting out a new libdrm soonish
[20:07] <bryceh> Sarvatt, meanwhile we can consider updating to a newer git snapshot, I've added to my todo list for next week to look at it; if you get some time to test on it that'd be great
[20:08] <bryceh> Sarvatt, regarding 2.10, I'm sort of mixed about it.  With the exec buffer bug fixed, we now have the main blocker we identified removed, so we ought to move ahead on it.  However, I'm concerned about losing UMS permanently, and sounds like we would be wanting to backport a bunch more stuff
[20:19] <Sarvatt> same here, doesn't look like theres much in the way of fixes outside of fixes for the performance enhancements they added post 2.9.1 in 2.10 :D
[20:23] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=c87585229b36790f883b9b8954ed061e00624df6 might  be worth pulling back into 2.9 branch
[20:25] <Sarvatt> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=10946118dd3a63f1375a1bfde0b2f0542a93c1c2 ?
[20:25] <jcristau> tell cworth that?
[20:26] <Sarvatt> yeah i'm looking at things that might be worth it then planning on asking
[20:26] <jcristau> cool
[20:26] <jcristau> thanks :)
[20:35] <bryceh> Sarvatt, Geir mentioned on the list that we need 2.6.33 for Clarkdale support
[20:36] <jcristau> eh? i thought that was in .32..
[20:36] <Sarvatt> it *should* work fine on 2.6.32.x, alot of fixes for that went into 2.6.32-13
[20:36] <Sarvatt> we just had an old 2.6.32.6 before that was missing a bunch of fixes
[20:37] <bryceh> ah
[21:03] <Sarvatt> http://sarvatt.com/downloads/patches/103_increase_idgng_stride.patch 
[21:04] <Sarvatt> jbarnes: does "Disable bo reuse on shadow framebuffer" fix a bug that would exist on 2.9 branch?
[21:05] <jbarnes> Sarvatt: yeah wouldn't hurt
[21:06] <geser> anyone familiar with the mesa packaging still around?
[21:07] <Sarvatt> we might end up shipping 2.9 branch with lucid because of the the dropped UMS support and the fact we're stuck with an old kernel, just looking at things that might be relevant
[21:07] <Sarvatt> whats up geser?
[21:09] <geser> libgl1-mesa-swx11 doesn't have it's own ld.so.conf snippet which makes that libGl.so.1 from that package doesn't get found
[21:10] <geser> and as it is a valid alternative for libgl1-mesa-glx it makes all packages using libGL.so.1 not find it
[21:12] <geser> my guess is that libgl1-mesa-swx11 should also have a ld.so.conf snippet like libgl1-mesa-glx
[21:12] <Sarvatt> eww
[21:13] <randomaction> I can confirm that replacing "libgl1-mesa-swx11-dev | libgl-dev" with "libgl1-mesa-dev" in build-deps fixes this FTBFS: http://people.ubuntuwire.org/~lucas/ubuntu-nbs/32/rss-glx_0.9.0-2ubuntu3_llucid32.buildlog
[21:15] <Sarvatt> hmm shouldn't libgl1-mesa-swx11 conflict with libgl1-mesa-glx?
[21:16] <geser> it does (indirectly about conflicting with libgl1 which libgl1-mesa-glx provides)
[21:17] <geser> but when libgl1-mesa-glx get removed also the ld.so.conf snippet gets removed which allows libGL.so.1 in /usr/lib/mesa to get found
[21:17] <Sarvatt> if we had libGL.so.1 in /usr/lib we wouldn't need an alternative installed with mesa would we? asking because I know how we can move libGL back to /usr/lib
[21:18] <jcristau> i think you'd need an alternative that said "don't use fglrx or nvidia"
[21:19] <geser> libGL.so.1 was in /usr/lib but got moved to /usr/lib/mesa (don't know the details)
[21:20] <geser> I guess I've to wait for tseliot
[21:20] <Sarvatt> geser: yeah, just trying to work out how we could get around moving libGL at all which is causing all these problems
[21:21] <geser> as far as I know it got moved to fix other problems
[21:21] <Sarvatt> why would we need an alternative that said dont use fglrx or nvidia though? there would be no alternative at all for it unless nvidia or fglrx was specifically installed
[21:22] <Sarvatt> it got moved because ldconfig wouldn't let libGL.so.1 from another directory have a higher priority over the one in /usr/lib because of the abi tag in the lib
[21:23] <geser> as I told, I don't know the details why it moved just that it caused much trouble
[21:26] <Sarvatt> http://sarvatt.com/downloads/patches/100_no_abi_tag.patch would fix that (on x86 or amd64 at least)
[21:27] <jcristau> Sarvatt: i thought the plan was to be able to install them all, and choose which one to use dynamically
[21:27] <Sarvatt> that tag doesnt get added on other arches anyway it looks like
[21:28] <Sarvatt> hmm good point
[21:30] <Sarvatt> well the only people that would want to use mesa instead of nvidia or fglrx would be people with nvidia or fglrx installed, maybe those packages could install the mesa alternatives too at lower priority? dunno
[21:41] <Sarvatt> i just dont like not being able to install packages from nvidia.com directly anymore since the alternatives were added to mesa :D and we keep having problems pop up with the mesa libGL being moved
[21:42] <Sarvatt> i guess adding a         echo "/usr/lib/mesa" \
[21:42] <Sarvatt>         > $(CURDIR)/debian/libgl1-mesa-swx11/usr/lib/mesa/ld.so.conf
[21:42] <Sarvatt> to the rules should work?
[21:43] <Sarvatt> and adding the prerm and postinst to libgl1-mesa-swx11
[21:43] <jcristau> i guess
[21:43] <geser> the same that was done to -glx to setup the alternatives needs to be repeated for -swx11 too
[21:44] <tjaalton> better to fix the loading order and move the libs back to where they belong?
[21:55] <bjsnider> has somebody got nvidia-current installed here?
[21:55] <Sarvatt> yep
[21:56] <bjsnider> can you check for the existence of this link: /usr/lib/libvdpau_nvidia.so
[21:59] <bdmurray> bryceh: do you have process for bugs with patches like bug 402260?
[21:59] <ubottu> Launchpad bug 402260 in xorg-server "segfault when running Xdmx" [Undecided,Confirmed] https://launchpad.net/bugs/402260
[22:00] <bryceh> bdmurray, yes
[22:01] <bryceh> bdmurray, generally the steps I follow are first to look at each patch and see whether it is a patch from upstream, or one that the user created, or one that they just picked randomly from elsewhere in the internet
[22:01] <bryceh> in the latter two cases I *usually* ask that they get the patch accepted upstream first, or at least run it by them.
[22:02] <bryceh> Sometimes I will go ahead and post it upstream for them, if I'm in a good mood.
[22:02] <BUGabundo> evening o/
[22:02] <bryceh> (or if it looks important)
[22:02] <bdmurray> I'm trying to figure out how x packages will fit in the ubuntu-reviews team workflow...
[22:02] <bryceh> bdmurray, for ones which are pulls from upstream, the next step is to see if it applies to our tree.  Often the upstream patches are against upstream git trees and so don't apply.
[22:02] <jcristau> xdmx is fixed in 1.7 afaik
[22:03] <jcristau> ah the guy nominated it for karmic
[22:03] <Sarvatt> bjsnider: lrwxrwxrwx 1 root root   36 2010-02-11 20:24 /usr/lib/libvdpau_nvidia.so -> /etc/alternatives/libvdpau_nvidia.so
[22:04] <bryceh> bdmurray, if they don't apply, then it is a choice between a) wait until we update (in which case I just put "[Needs 1.2.3]" in the subject, b) backport the patch myself, or c) leave it for someone else to look at
[22:04] <bjsnider> Sarvatt, and does the so.1 link also exist?
[22:05] <bryceh> bdmurray, along with all the above, it is also important to see if people have actually tested the patch.  Often I see people will post patches that they *think* fix the issue because upstream told them so, but they're afraid of patching/building the X component themselves, so are sort of hoping someone else will do that bit for them.
[22:06] <bryceh> sometimes I do this; this is why I have so many ppas ;-)
[22:06] <bryceh> these days I find I haven't so much time to do this for people though
[22:06] <bryceh> bdmurray, anyway take from the above what you may
[22:06] <Sarvatt> should I commit this to the ubuntu branch of mesa git? http://sarvatt.com/downloads/patches/0001-Add-100_no_abi_tag.patch.patch
[22:07] <Sarvatt> bjsnider: http://pastebin.com/f51587796
[22:08] <bryceh> bdmurray, does that answer your question or is it TMI?
[22:08] <bryceh> hi rickspencer3
[22:09] <rickspencer3> hiya bryceh
[22:09] <rickspencer3> apport?
[22:09] <bryceh> rickspencer3, btw I'm confused about when we have that call with alice? 
[22:09] <bryceh> apport?
[22:09] <rickspencer3> did she send an invite?
[22:09] <rickspencer3> she said she would schedule it
[22:09] <bryceh> rickspencer3, yes but it was for yesterday
[22:09] <rickspencer3> lol
[22:09] <bdmurray> bryceh: it was a bit too much TMI.  The reviews team is more of a sorting / assigning team.  We'd assign bugs with patches to the main reviews team or universe or upload the patch our selves.  But since you have a fairly detailed process what should we do with them?
[22:09] <rickspencer3> well, I can only assume that was a Friday afternoon mistake for her
[22:10] <bryceh> rickspencer3, try again tuesday?
[22:10] <rickspencer3> bryceh, sure
[22:10] <bryceh> bdmurray, maybe you should explain what you do for non-x patches, and we can see if there is a good overlap
[22:11] <bjsnider> Sarvatt, i don't understand why a .so.1 version isn't also there, but thanks
[22:11] <bryceh> rickspencer3, maybe right after the team meeting so it's not too late london time for her?
[22:11] <rickspencer3> bryceh, sure
[22:11] <rickspencer3> I don't actually see an invite from her
[22:11] <rickspencer3> could you just bounce it back and ask her to try again?
[22:16] <bryceh> sure
[22:20] <bryceh> rickspencer3, is it cool if we use your conference line for this?
[22:20] <rickspencer3> sure
[22:20] <Sarvatt> tjaalton: how does this look for libgl1-mesa-swx11 alternatives? http://sarvatt.com/downloads/patches/0001-Install-alternatives-for-libgl1-mesa-swx11-as-well.patch
[22:21] <bryceh> rickspencer3, ok email sent, you're cc'd.  9:30am Tuesday, your conf call line
[22:22] <rickspencer3> okee dokee
[22:22] <bryceh> Sarvatt, sorry, in the middle of reviewing your patch, one sec
[22:23] <tjaalton> Sarvatt: tbh I haven't given much thought on our current mesa, and I've been up too long to think straight ;)
[22:23] <bryceh> Sarvatt, one question, would it not be sufficient to simply undefine GLX_USE_TLS via configure or something?
[22:24] <jcristau> it would work too, but it would be a completely different fix
[22:24] <Sarvatt> nah alot of other changes are done for GLX_USE_TLS in there, undefining it would stop using TLS at all
[22:26] <Sarvatt> could just stop passing --enable-glx-tls to disable it completely
[22:30] <Sarvatt> which would fix https://launchpad.net/bugs/259219 but thats way over my head
[22:30] <ubottu> Ubuntu bug 259219 in mesa "Broken TLS support in libGL.so" [Undecided,Confirmed]
[22:31] <tjaalton> tls should improve performance
[22:36] <Sarvatt> debian/ubuntu seem to be the only people enabling it, fedora gentoo and mandriva when I looked
[22:36] <Sarvatt> *dont
[22:36] <tjaalton> because of selinux?
[22:37] <tjaalton> fedora at least
[22:37] <Sarvatt> nevermind gentoo does, i'm blind - $(use_enable nptl glx-tls) \