[07:39] <ripps> Does anybody have any clue how well the integrated intel graphics on an core i5 2400 is compared to an nvidia gt 240?
[07:48] <tjaalton> what do you mean?
[07:49] <tjaalton> it's perfectly fine for a "normal" linux desktop
[10:41] <tseliot> Sarvatt, tjaalton: didn't we use to strip the OS ABI tag from Mesa's libGL?
[10:47] <tseliot> this patch: http://sarvatt.com/downloads/patches/100_no_abi_tag.patch
[10:47] <jcristau> wasn't this made unnecessary by your alternatives stuff?
[10:58] <tseliot> yes but I'm now reconsidering this as the alternatives system kind of breaks dlopen()
[10:58] <tseliot> I think we can get both things to work
[11:00] <jcristau> dlopen("libGL.so.1") should still work...
[11:00] <tseliot> i.e. libGL.so.1 will be a slave link in /usr/lib and point to either the lib in /usr/lib/mesa/ or the one in  /usr/lib/$driver
[11:01] <tseliot> right now we don't have any libGL.so.1 in /usr/lib
[11:01] <jcristau> i know.
[11:01] <tseliot> only libGL.so is there
[11:01] <tseliot> I think someone reported a bug about it
[11:02] <jcristau> so dlopen("/usr/lib/libGL.so.1") won't work.  dlopen("libGL.so.1"), otoh...
[11:03] <tseliot> ah, I guess the bug report was about apps which specified the full path
[11:09] <tseliot> yes, that was the case. Thanks jcristau
[11:14] <jcristau> (the linux libGL ABI spec says it should be in /usr/lib/libGL.so.1 so in theory it should work.  i don't know what apps rely on that part of the spec though)
[11:23] <tseliot> right
=== highvolt1ge is now known as highvoltage
[16:09] <Amaranth> hrm, I see a mesa update in oneiric, scary
[16:43] <Sarvatt> very :)
[16:47] <tjaalton> oh right, now that llvm is in main
[16:59] <Amaranth> oh, it's not anything mesa 7.11, i'm probably ok
[16:59] <Amaranth> last time I checked 7.11 stuff still breaks my gles
[17:00] <Prf_Jakob> Amaranth: bug filed?
[17:00] <Amaranth> I believe one was filed
[17:00] <Amaranth> It was something in the build system disabling GLES for intel when using the shared glapi stuff
[17:01] <Prf_Jakob> Hmm ok
[17:01] <Amaranth> I spoke to RAOF about it at UDS and he said a bug was filed and he was going to look at it, I believe I found the bug that same day
[17:01] <Amaranth> Trying to find it again now
[17:05] <Amaranth> hrm, now I can't find the bug or the gles code in mesa to find the problem again
[17:06] <Prf_Jakob> Things have changed in that area I think.
[17:07] <Amaranth> iirc -DFEATURE_ES2 was getting lost when building with --enable-shared-glapi, but only for intel
[17:07] <Amaranth> I'll have to see if xorg-edgers has a recent looking mesa snapshot to see if the problem is still happening
[19:31] <Amaranth> Prf_Jakob: Looks like that bug was fixed, I'm on a mesa snapshot from the 16th and have gles2
=== yofel_ is now known as yofel
[23:04] <Sarvatt> https://launchpad.net/ubuntu/oneiric/+localpackagediffs allowing ia32-libs diff computation and doing it on the fly every time? incoming DoS
[23:05] <Sarvatt> xserver-xorg-video-ati has taken about 5 minutes to compute so far :(
[23:15] <bryceh> Sarvatt, I assume it caches the result after doing it once
[23:16] <bryceh> Sarvatt, out of curiousity what are you looking at in -ati?
[23:17] <Sarvatt> bryceh: what happened was i clicked calculate diff for ia32-libs which will take a year and probably be 1GB+, switched pages to cancel and tried to get a diff on -ati. turned out i'll have to wait until ia32-libs is done :)
[23:17] <bryceh> ah
[23:18] <bryceh> hm, I've several natty -intel bugs marked now as "fixed" due to ickle's dropping of uxa 3d pipeline
[23:21] <Sarvatt> dont think its worth picking up that commit to SRU?
[23:21] <bryceh> well I'm thinking about it
[23:22] <Sarvatt> people using xterm will complain no doubt :)
[23:22] <bryceh> Sarvatt, what do you think?  I've got it packaged and am going to slam it in a ppa at least
[23:22] <bryceh> Sarvatt, why's that, does this optimization path solve a problem for them?