[07:13] <tjaalton> RAOF: so, the mesa packaging doesn't include swrastg_dri.so, maybe just replace swrast_dri.so with it?
[07:14] <RAOF> tjaalton: I was thinking of shipping it in -dri-experimental.
[07:14] <tjaalton> ah
[07:14] <RAOF> Apparently llvmpipe is great as long as you're doing POT textures, and may fall over horribly outside that…
[07:14] <tjaalton> but how would it get used? the fallback is swrast_dri
[07:15] <RAOF> I'd rename it to swrast_dri instead of swrastg, and ship it in dri-alternates/
[07:15] <RAOF> Then you get to set LIBGL_DRIVERS_PATH if you want to play with llvmpipe.
[07:15] <RAOF> But it's pretty easy.
[07:15] <tjaalton> ok
[07:17] <RAOF> I don't think we need to spend too much time making it easier to test an alternative software rasteriser unless we plan to use it as a fallback for Unity.
[07:17] <tjaalton> sure
[07:18] <tjaalton> i mean 'right'
[07:20] <tjaalton> gnome doesn't start even with stock oneiric on this machine
[07:25] <tjaalton> hmm no, unity/compiz is running, but it just gives a purple screen
[07:26] <RAOF> A nice purple? :)
[07:26] <tjaalton> yes, single colour and not some mess :)
[07:26] <tjaalton> actually nicer looking that what the desktop becomes on the intel machine
[07:26] <tjaalton> just that I can't do anything here
[07:30] <tjaalton> classic session works, and can start compiz there
[07:31] <tjaalton> though it says that tfp is missing
[07:46] <tjaalton> maybe I should try a snapshot instead
[07:53] <tjaalton> maybe just commit 2b64886c would do
[07:53] <tjaalton> *pulling
[09:22] <RAOF> Mmm.  Loadavg 8.4.  I *may* be building too many things right now.
[09:22] <tjaalton> just 2.19 here
[09:23] <seb128> hey there!
[09:23] <RAOF> Oop, 10.5
[09:23] <seb128> did anyone read my question about glew yesterday?
[09:23] <tjaalton> seb128: re glew; nothing new has happened aiui
[09:23] <seb128> is there any plan to get 1.6? is #ubuntu-x taking care of that package or is unmaintained?
[09:24] <seb128> (desktop is not working on it)
[09:24] <tjaalton> and we don't generally track it, it's not maintained by pkg-xorg in debian
[09:24] <RAOF> If you'd like us to take it we could; it's not unreasonable to lump it in the graphics stack.
[09:26] <seb128> hey RAOF, that would be nice indeed
[09:26] <tjaalton> the changelog is strange
[09:26] <tjaalton> taken from 1.5.2 it seems
[09:27] <tjaalton> debian has 1.5.8
[09:28] <seb128> we downgraded in natty because the update broken unity on some intel cards and it was late in the cycle to figure who was at fault
[09:28] <seb128> but would be nice to update to 1.6 now early in oneiric and fix the issue where it is if there is still one
[09:29] <tjaalton> could it be tested with 1.5.8 in debian first?
[09:30] <seb128> in debian?
[09:30] <tjaalton> from debian
[09:30] <seb128> or do you mean "can some people try installing the debian version on oneiric and see if it breaks"?
[09:30] <tjaalton> right
[09:30] <seb128> we can do that
[09:30] <tjaalton> we could sync it
[09:30] <seb128> the issue is I guess dx is not going to work on it until they have a good reason to
[09:30] <seb128> well there was a .pc fix
[09:31] <seb128> though upstream apparently argued that it's wrong so maybe nux needs an update
[09:31] <seb128> but ok, I will get some desktop people to check with the current debian version then we can try syncing
[09:31] <tjaalton> good
[09:36] <RAOF> tjaalton: Are you planning on merging xserver 1.10.2 from Debian?
[09:39] <tjaalton> RAOF: I could do that, yes
[09:40] <RAOF> I wasn't fishing for that :).  But if you were, it would be nice to coordinate with an upload of a multiarch'd mesa.
[09:41] <tjaalton> they need to be done in sync?
[09:41] <RAOF> AIGLX ties them together; the multiarch mesa installs the dri drivers into a different place, so needs a rebuild of X to pick that up.
[09:41] <tjaalton> ah, of course
[09:42] <tjaalton> post-a1 i believe?
[09:42] <RAOF> That would be the case, now, yes.
[09:42] <tjaalton> sigh, network manager broken
[09:43] <tjaalton> this is going to be an amazing a1 release :)
[09:44] <RAOF> Mine works :)
[09:45] <tjaalton> wired seems to work, wireless no
[09:45] <tjaalton> and the desktop still looks rather funky
[09:46] <RAOF> Heh.  It seems that loadavg 15 is the threshold beyond which the music will start to occasionally skip.
[09:46] <tjaalton> heavy i/o does that
[09:48] <tjaalton> meh, tfp still missing after building with that single commit
[09:55] <RAOF> And the laptop hits loadavg 30.  Time to set this mesa build off and let it digest the tasks I've given it.
[09:56] <tjaalton> so you've multiarch'ed mesa?
[09:57] <RAOF> Well, merged vorlon's multiarch branch, yes.
[09:57] <tjaalton> ah right, there was a branch already
[12:03] <tjaalton> ok, XI2.1 patch applies without fuzzies
[12:06] <tjaalton> RAOF: patch 201_report-real-dpi.patch has been commented out for some time? or all the time, couldn't find a reference in the changelog
[12:09] <tjaalton> ok got it from git log
[14:37] <ach1m> hi, I am using xorg-edgers ppa in Natty, glxgears does exit with a segmentation fault, I mean it doesn't really start at all.  Should I fill a bug-report somewhere?
[15:57] <YoBoY> hi
[15:59] <YoBoY> another freeze :]
[16:00] <YoBoY> tjaalton: you told me yesterday there is a ppa with a test kernel, where I can find it ? I can't work anymore with so many freezes ¬_¬
[16:05] <tjaalton> YoBoY: bug 740126
[16:05] <ubot4`> Launchpad bug 740126 in unity (Ubuntu Natty) (and 6 other projects) "Disabling an output can cause vblank events to be missed (affects: 78) (dups: 10) (heat: 392)" [High,Triaged] https://launchpad.net/bugs/740126
[16:05] <tjaalton> comment #46 has a link to a ppa
[16:05] <tjaalton> just wget the deb you need
[16:06] <YoBoY> crap ... why the search on "ppa" don't work xD
[16:06] <tjaalton> the comments are numbered..
[16:07] <tjaalton> and it's not a ppa to be precise
[16:07] <tjaalton> http://kernel.ubuntu.com/~sarvatt/lp740126/
[16:08] <YoBoY> ha ok, it's not really an "ubuntu ppa" like one we can add to the sources.list, misunderstanding ... my bad
[16:10] <YoBoY> thanks I'll try
[19:41] <Sarvatt> argh, libxcb-util0-dev | libxcb-aux0-dev  build depends would have been a lot friendlier for x-x-v-intel :P