[04:58] <RAOF> WIN!  I can now corrupt the function parameters on IA32 rather just calling off into random memory!
[07:33] <tjaalton> RAOF_: fixing the TLS bug?
=== RAOF_ is now known as RAOF
[09:35] <RAOF> tjaalton: Yup.  I may be slightly insane, because I think I'm beginning to understand mesa dispatch.
[09:41] <tjaalton> <g>
[09:41] <RAOF> Although I'm *not* sure why I appear to be corrupting all the arguments on IA32.
[09:43] <RAOF> On x86-64 it was because I wasn't saving enough registers, but (a) registers aren't *used* in passing arguments in IA32 and (b) I'm only clobbering %eax, which is safe to clobber, and (c) I'm not even really doing that.
[09:46] <RAOF> Because, obviously, on IA32 mesa calculates the base address of the dispatch table at init time and writes that directly into the function definitions.
[09:46] <tjaalton> glad I don't do assembler. at all :P
[09:46] <tjaalton> some mips years ago
[09:47] <RAOF> There's some sparc assembler here too.  That'll be broken also, but sucks to be on sparc.
[09:51] <mvo> RAOF: ohhh, progress on the mesa issue? that is excellent! that will make my software-center users happy :)
[09:51] <RAOF> Yeah, sorry about that.
[09:52] <mvo> well, not really your fault, the joy of natty. I'm happy that you dived so deep into it for the fix
[09:52] <mvo> sounds very painful to debug it
[09:54] <RAOF> I get to learn all sorts of arcana about IA32 assembly, the System V ABI, the TLS ABI…
[09:54] <RAOF> And that x86-64 assembler is much nicer.
[09:55] <RAOF> And now, as I stare at gdb disassembly, I realise that it's time to learn more about relocations and the PLT…
[09:57] <mvo> geeh, good luck
[10:01] <jcristau> sparc asm isn't nearly as horrific as x86
[10:12] <RAOF> More difficult for me to test, though.
=== seb128_ is now known as seb128
[15:39] <tseliot> RAOF: did you rebuild the X packages in the ubuntu-x-swat PPA bumping the video ABI number?
[15:41] <lag> cnd: Good day
[15:41] <lag> cnd: Did you receive my email with the non-empty device.* files?
[15:41] <cnd> lag, yep, but it's a bit low in the queue :(
[15:41] <cnd> I'm trying to get through a backlog
[15:41] <cnd> and I have to get a root canal in a few hours too
[15:41] <cnd> so...
[15:42] <cnd> hopefully tomorrow?
[15:43] <lag> Sure
[15:43] <lag> Good luck with the root canal - rather you than me
[15:59] <cnd> bryceh_, tjaalton: would one of you be able to upload an update to python-libavg? (bug 733247)
[15:59] <ubot4`> Launchpad bug 733247 in libavg (Ubuntu) "Please upgrade to libavg v1.5.4 (affects: 1) (heat: 10)" [Undecided,Confirmed] https://launchpad.net/bugs/733247
[16:00] <cnd> I can prepare a source package if you need
[16:00] <jcristau> i thought libavg was broken by mesa tls fun anyway?
[16:01] <cnd> jcristau, I gave them a hacky patch :)
[16:01] <cnd> it literally loads libstdc++ using python before doing any opengl stuff
[16:01] <jcristau> ewww :)
=== yofel_ is now known as yofel
[17:10] <tjaalton> cnd: hey, I'm not at my ws atm, so can't sponsor it until maybe 2.5h from now
[17:20] <cnd> tjaalton, I won't be around then
[17:20] <cnd> maybe tomorrow
[17:31] <tjaalton> cnd: put the package somewhere and I'll download it then
[17:33] <cnd> tjaalton, ok, I'll get to that in a bit
[17:33] <cnd> I have to leave now
[17:49] <tjaalton> cnd: ok
[19:38] <sweeze> with latest xserver-xorg-video-ati from xorg-edgers, ForceGallium=true in xorg.conf no longer works.  I've temporarily copied /usr/lib/dri/r600g_dri.so over r600_dri.so, but what's the "right" way to get the gallium driver from the packages to be used?
[19:39] <sweeze> (braid w/ s3tc libtxc_dxtn.so hack seems to work w/ gallium, but not classic drivers)
[19:46] <Sarvatt> sweeze: it's always used by default, /usr/lib/dri/r600_dri.so is the gallium one. if you have an r600g_dri.so its hanging around from an old build
[19:53] <sweeze> Sarvatt: hmm... looks like not true in libgl1-mesa-dri package in ppa?  
[19:53] <sweeze> `strings /usr/lib/dri/r600_dri.so |grep -i gallium` is empty
[19:53] <sweeze> but on r600g_dri, gallium strings show up
[21:44] <Prf_Jakob> Is there a ppa to get a kernel capable of KMS on radeon cayman cards?
[21:45] <Sarvatt> hmm good question.. lets see
[21:46] <Sarvatt> http://kernel.ubuntu.com/~kernel-ppa/mainline/drm-next/
[21:47] <Prf_Jakob> ah cool
=== unitylogger is now known as gnomeshellogger
[21:47] <Prf_Jakob> Whats the magic ppa name for that repo?
[21:47] <bryceh_> it's not actually a true PPA
[21:48] <Sarvatt> linux-firmware 1.48+ from natty has the firmware if you aren't on natty
[21:48] <Sarvatt> yeah have to install it manually
[21:48] <Prf_Jakob> ah
[21:48] <Prf_Jakob> Yeah maverick
[21:49] <Sarvatt> https://launchpad.net/ubuntu/+source/linux-firmware/1.48/+buildjob/2297992
[21:49] <Sarvatt> can grab the firmware deb there
[21:50] <Prf_Jakob> Thanks!
[21:52] <Sarvatt> there's no accel or anything yet though
[21:53] <Prf_Jakob> I just want a native resolution on my 30" :-/
[22:03] <Prf_Jakob> Hmm I guess I need some xf86-video-ati bits to go with that as well.
[22:13] <Prf_Jakob> Hmm that kernel just made my screen go black and the network didn't work :-/
[22:14] <Sarvatt> sudo apt-get build-dep xserver-xorg-video-ati && dget -u -x https://launchpad.net/~xorg-edgers/+archive/ppa/+files/xserver-xorg-video-ati_6.14.99%2Bgit20110307.6319a33c-0ubuntu0sarvatt~maverick.dsc && cd xserver-xorg-video-ati-6.14.99+git20110307.6319a33c && fakeroot debian/rules binary
[22:14] <Prf_Jakob> Sarvatt: awesome!
[22:22] <RAOF> bryceh_, tjaalton, Sarvatt: What do you think of uploading a temporary fix for the mesa tls annoyance?  I've got it for platforms without asm optimisations and for x86-64 asm.  IA32 is still kicking my arse, and I don't care about sparc.
[22:23] <RAOF> We could upload a mesa with assembly disabled on i386, which would work.
[22:23] <bryceh_> RAOF, sure
[22:24] <bryceh_> RAOF, in fact we should probably start pushing buttons on the xserver update, what do you think?
[22:24] <RAOF> Probably, yeah.
[22:24] <tjaalton> RAOF: i guess nothing would break?-)
[22:25] <RAOF> Although you might know better; I've been diving through things man was not meant to know.
[22:25] <Sarvatt> think we're going to end up just disabling tls completely at this rate?
=== gnomeshellogger is now known as TheHarald
[22:26] <RAOF> Sarvatt: Why?  It works for x86-64 ;)
[22:26] <RAOF> And that's an ABI change that'll freak out the server, IIUC.
[22:27] <bryceh_> RAOF, I've been distracting myself with some toolsmithing work lately, but I think what I should do is test booting the ppa on a few machines, then put out the usual announcement, and maybe tues/weds we can do the uploads
[22:28] <RAOF> bryceh_: Sounds reasonable.
[22:29] <RAOF> I'll need others to help with the uploads, as usual; the DMB didn't get a quorum last night :(
[22:30] <tjaalton> meh
[22:30] <bryceh_> RAOF, not a problem
[22:53] <jcristau> RAOF: i think the enable-glx-tls server is happy to load drivers built with --disable-glx-tls
[22:53] <jcristau> RAOF: it's the other way around that doesn't work
[22:53] <RAOF> Ah, ok.
[22:54] <jcristau> (because tls enabled drivers require symbols only found in tls enabled loaders)
[22:54] <RAOF> Right.
[23:06] <tjaalton> ideas how this is possible http://launchpadlibrarian.net/66332175/DpkgTerminalLog.txt
[23:06] <tjaalton> from bug 734676
[23:07] <ubot4`> Launchpad bug 734676 in xorg-server (Ubuntu) "package xserver-xorg-core 2:1.9.99.902-2ubuntu2 failed to install/upgrade: installing xserver-xorg-core would break existing software (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/734676
[23:07] <tjaalton> only thing I can think of is a very stale mirror
[23:18] <bryceh_> tjaalton,   xserver-xorg-video-tseng provides xserver-xorg-video-8 and is present and installed.
[23:19] <bryceh_> tjaalton, perhaps uninstall -tseng and try again?
[23:19] <tjaalton> bryceh_: yeah, but the archive should have the new one
[23:19] <bryceh_> tjaalton, PPAs involved?
[23:19] <tjaalton> I guess there's no other reason than a stale mirror then
[23:19] <tjaalton> no idea, not mine
[23:20] <bryceh_> I wonder if having -fglrx installed would produce that error message (although obviously not in this case since it's -intel)
[23:21] <tjaalton> i guess it's proven that fglrx/nvidia has been removed on upgrade :)
[23:22] <bryceh_> heh, ok true
[23:22] <tjaalton> i'll close this on
[23:22] <tjaalton> e