[01:44] <Sarvatt> hmm, shadow branch of xf86-video-intel seems to have more problems than just KMS+fbdev. glx and changing resolutions dont work on 945
[03:18] <RAOF> Bah!  Plymouth killing X seems to have returned!
[06:11] <RAOF> Hm.  How was clutter ever working?
[06:16] <RAOF> Hey, is there someone here running stock Maverick mesa on an intel chip?  I'd like the (pastebinned) output of glxinfo.
[06:37] <tjaalton> RAOF: I am, you'll get it in 30min after I get to work first
[07:25] <tjaalton> RAOF: http://pastebin.com/9e3m7EcL
[08:20] <vish> RAOF: 7.9 dint work either... and seems mutter is also failing/crashing X with the latest xorg not related to the mesa update , also with stock update
[08:20] <vish> rather stock maverick xorg
[08:20] <RAOF> vish: Hm, odd.
[08:21] <RAOF> vish: Because mine is working just fine* (modulo stupid clutter bugs)
[08:21] <vish> RAOF: yeah totally odd, previously when i started testing , mutter would work fine , now with the maverick stock mutter just crashes X
[08:22] <RAOF> Got a backtrace?
[08:22] <vish> i if i just do a mutter --replace , i get back to the gdm
[08:22] <vish> yeah , i just downloaded the latest daily , gonna do it now :)
[08:30] <RAOF> Note you'll probably want to attach gdb to X
[08:32] <vish> k.. 
[10:44] <vish> \
[10:45] <ion> /
[10:45] <jcristau> |
[10:46] <ion> ┌────┘
[10:48] <vish> oopsie! :D
[11:47] <vish_> RAOF: got the backtrace for the mutter crashing x: http://paste.ubuntu.com/485793/
[11:48] <vish_> it happens consistently, all i  need to do it start mutter --replace and once mutter starts, try to focus on a different window
[11:48] <RAOF> Hm.
[11:48] <vish_> and bam! X crashes
[11:48] <RAOF> What version of xserver-xorg-video-ati?
[11:49]  * RAOF 's “don't crash X” patches seem to have some unhandled edges.
[11:49] <vish_> -ati is 1:6.13.1-1ubuntu4
[11:50] <RAOF> Bah.
[11:51] <vish_> i'll file a separate bug with that backtrace
[11:51] <RAOF> Thanks.
[11:53] <RAOF> You're probably hitting an edge case fixed in 6a2c8587
[11:58] <vish_> hehe, yeah, i seem to gather a lot of X bugs ;p the benefitss of using ati \o/
[11:59] <vish_> btw, bug 626743
[11:59] <ubot4> Launchpad bug 626743 in xserver-xorg-video-ati (Ubuntu) "[RV515] Running Mutter causes X to crash (affects: 1) (heat: 6)" [Undecided,New] https://launchpad.net/bugs/626743
[11:59] <vish_> RAOF: ^ thats the bug ,attached the gdb too.. Thanks for looking into tis :)
[11:59] <vish_> this*
[12:55] <asac> Sarvatt: can you please use the maverick packaging with egl etc. to update mesa in xorg-edgers?
[12:55] <asac> thanks!!!
[12:55] <asac> we need this to figure if we need to do upstream fixes/code
[12:56] <RAOF> asac: There's a 7.9 snapshot in sarvatt's PPA.
[12:56] <RAOF> https://edge.launchpad.net/~sarvatt/+archive/mesa
[12:57] <RAOF> If I can chase down the couple of regressions it's mostly what I'll be aiming for a FFe for.
[12:57] <asac> RAOF: hmm. so the versioning in xorg-edgers is bogus? it has 7.9+
[12:58] <asac> e.g. i cannot use the ppa where i copied it to ;)
[12:58] <RAOF> Yeah, bogus versioning.
[12:58] <RAOF> 7.9 hasn't been released yet.
[12:58] <asac> sigh
[12:58] <asac> so my ppa is unusable now
[12:58] <asac> please update the mesa in xorg-edgers with all the packaging ;)
[12:58] <RAOF> You could delete the 7.9+… version from the PPA and wait a couple of hours before copying the 7.9
[12:59] <asac> if thats too hard let me know and i can create one new
[12:59] <asac> RAOF: that doesnt work
[12:59] <asac> unless ppa learned that now
[12:59] <RAOF> It doesn't?
[12:59] <asac> no
[12:59] <asac> deleting doesnt remove it from history
[12:59] <asac> so you can never upload something lower ;)
[13:01] <RAOF> I'll throw something into ppa:raof/mesa-egl
[13:02] <asac> RAOF: cool!!
[13:04] <RAOF> Oh, do you want it for maverick or lucid?
=== asac_ is now known as asac
[13:14] <RAOF> asac: should be in ppa:raof/mesa-egl now.
[13:14] <RAOF> And with that, it's good night from me!
[13:35] <Sarvatt> asac: thats why i havent updated mesa in edgers in almost a week, working out the packaging of all this new stuff and i've been more worried about the one that might go into maverick :) edgers is significantly different, uses llvm and enables lots of other things for testing like vmware
[13:36] <Sarvatt> sorry about the versioning problem, I bumped it to a + by mistake when I was working out some automated scripts and its too big a deal convincing people to downgrade and not get stuck at the + version :)
[13:46] <Sarvatt> things changed so much in mesa 7.9, i had to fork the packaging well before any of the egl stuff was introduced and was waiting until the final decisions were made for pulling 7.9 into maverick to rework it. sorry you used edgers on arm, if I had known I would have warned you about all of that :(
[14:04]  * Sarvatt tries to figure out how to get piglit to ignore nv50_screen_get_param:192 - Unknown PIPE_CAP messages
[14:08] <Sarvatt> oh that was surprisingly easy
[14:28] <mvo> does anyone mind if I upload https://bugs.edge.launchpad.net/ubuntu/+source/xorg-server/+bug/614993/+attachment/1529476/+files/xorg-server_1.9.0-0ubuntu2.debdiff ? context is bug #614993
[14:28] <ubot4> mvo: Bug 614993 on http://launchpad.net/bugs/614993 is private
[14:28] <ubot4> Launchpad bug 614993 in xorg-server (Ubuntu) (and 1 other project) "10.04 -> 10.10 upgrade fails: pkgProblemResolver::Resolve generated breaks: Holding Back xserver-xorg-video-nouveau rather than change xorg-video-abi-8.0 (affects: 13) (dups: 8) (heat: 103)" [Critical,In progress]
[14:38] <Sarvatt> mvo: oh hmm, thats supposed to be in Breaks: already, debian had the same problem
[14:38] <Sarvatt> looks like its only there in unstable not experimental
[14:39] <Sarvatt> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=commit;h=9c8080d06c457932d3bfec021c69ac000aa60120
[14:40] <mvo> Sarvatt: aha, great. I change it to a breaks and upload then ? 
[14:41] <Sarvatt> sounds good!
[14:42] <mvo> uploaded, thanks for the pointer
[14:42] <Sarvatt> thanks mvo, i'll push it to git when ya do
[14:43] <mvo> I adjusted it a bit, we don't need most of the diff from debian as we e.g. do not have -vga anymore and our -v4l seems to work with -video-8, but its universe now. anyway, the upload should fix the upgrade for us :)
[14:46] <Sarvatt> yeah v4l is the important one, it was dropped from xserver-xorg-video-all so it probably doesn't try to upgrade it right away and holds back the new abi. apt ordering is such a headache :)
[14:47] <vish> Sarvatt: can a single package be downgraded? like only xserver-xorg-video-ati  instead of the whole xserver?
[14:47] <Sarvatt> whatcha mean?
[14:48] <vish> not sure if the new mesa 7.9 from your ppa works , since latest xserver-xorg-video-ati cause problem
[14:48] <Sarvatt> like you have edgers updated and want to downgrade ati  to the one in the archive?
[14:48] <mvo> Sarvatt: apt ordering> yeah!
[14:48] <vish> s
[14:49] <vish> Sarvatt: actually Bug 626743 , probably prevents me from testing your ppa and mesa 7.9 , so i was wondering if i could downgrade  xserver-xorg-video-ati alone and test your ppa again..
[14:49] <ubot4> Launchpad bug 626743 in xserver-xorg-video-ati (Ubuntu) "[RV515] Running Mutter causes X to crash (affects: 1) (heat: 6)" [Undecided,Confirmed] https://launchpad.net/bugs/626743
[14:49] <Sarvatt> vish: yeah nothing special there, ya probably have the old deb in /var/cache/apt/archives/ even
[14:49] <Sarvatt> by my ppa do you mean the one with just mesa 7.9 in it?
[14:49] <vish> yeah..
[14:50] <vish> cool, just making sure if doing that would actually work.. before i bork something else ;)
[14:50] <Sarvatt> yep it'll work
[15:14] <Sarvatt> bryceh: this graph has gone nuts :) http://www2.bryceharrington.org:8080/X/Reports/ubuntu-x-swat/totals-maverick-workqueue.svg
[15:21] <Sarvatt> wow, nouveau is in good shape - http://sarvatt.com/downloads/piglit/nouveau/
[15:40] <bjsnider> according to someone over in the gnome-shell channel, the .52 blob fixes the performance issues with gnome-shell and nvidia
[15:40] <bjsnider> that's a very small sample size, just one person, but that's something nvidia left out of the changelog
[15:42] <Sarvatt> were they using gnome-shell via xephyr? because that would be in the changelog
[15:43] <bjsnider> what does it say about that?
[15:43] <Sarvatt>    - Fixed a bug that caused extremely slow rendering of OpenGL
[15:43] <Sarvatt>      applications on X screens other than screen 0 when using a compositing
[15:43] <Sarvatt>      manager.
[15:43] <bjsnider> i doubt they're using screens other than 0
[15:43] <bjsnider> it's possible that guy is though
[16:01] <bjsnider> Sarvatt, have you got that packaged for lucid yet?
[16:02] <Sarvatt> yep, looks like I forgot to patch that latest upload to lucid yesterday but i fixed it up about an hour ago, dont think it's built yet
[16:09] <Sarvatt> amd64 is, i386 is in the middle of building now
[16:12] <bjsnider> i don't think you need the 185 transitional packages since if they're using lucid they already had those packages in the main repo
[16:18] <Sarvatt> crazy people - https://bugs.edge.launchpad.net/ubuntu/+source/nvidia-graphics-drivers/+bug/626557
[16:18] <ubot4> Launchpad bug 626557 in nvidia-graphics-drivers (Ubuntu) "package nvidia-current 195.36.24-0ubuntu1~10.04 failed to install/upgrade: trying to overwrite '/etc/OpenCL/vendors/nvidia.icd', which is also in package nvidia-glx-256 0:256.52-0ubuntu1~karmic~nvidiavdpauppa1 (affects: 1) (heat: 6)" [Undecided,New]
[16:19] <Sarvatt> oh read that backwards, thought they were installing the karmic package on lucid :)
[16:20] <bjsnider> that bug is because nvidia-current doesn't conflict with nvidia-glx-256
[16:21] <bjsnider> they just need to ppa-purge. basically it's a support request
[16:36] <tseliot> err... what's nvidia-glx-256 and where does it come from???
[16:47] <Sarvatt> tseliot: in the middle of filing a FFe for nvidia-graphics-drivers 256.52, unless you already had one lined up?
=== yofel_ is now known as yofel
[16:48] <tseliot> Sarvatt: I don't think we'll need a FFE for that. If it's just bug fixes, it should be fine
[16:49] <tseliot> either I'd like to discuss this with Nvidia first though (on Friday)
[16:50] <Sarvatt> oh ok
[16:50] <Sarvatt> glad I asked first :)
[16:52] <tseliot> :-)
[16:54] <Sarvatt> well I got one all written up and a clean package if we do end up needing it
[17:00] <tseliot> Sarvatt: good, thanks for your work.
[17:02] <vish> RAOF: in case you miss the bugmail, i downgraded and tried various versions, the problem was actually xserver-xorg-video-ati (1:6.13.1-1ubuntu3)  and CLUTTER_VBLANK=none helps mutter but not unity..
[17:02]  * vish lets RAOF sleep ;)
[17:15] <Sarvatt> ok mesa is going gallium only for r300 in the next update in edgers, think i'll replace swrast_dri.so with the llvmpipe enabled swrastg_dri.so as well. the rest will be shipped in /usr/lib/dri/gallium in dri-experimental so people can at least test manually adjusting paths
[17:58]  * Sarvatt wonders if conflicts/replaces libgl1-mesa-dri-gallium is enough for libgl1-mesa-dri-experimental in edgers
[18:03] <Sarvatt> ricotz: heads up that ia32-libs will be all kinds of screwed up now, I'm sorry about that :(
[18:04] <Sarvatt> here is the new file layout - http://sarvatt.com/downloads/filelist_mesa_edgers.txt
[18:24] <Sarvatt> I put a big notice detailing the changes on the main xorg-edgers/ppa page
[18:30] <Sarvatt> RAOF: are you sure about nouveau-vieux being in dri-experimental? considering nvidia isn't planning on updating -96 to support xserver 1.9 it seems pretty important to have it easily available
[18:31] <ricotz> Sarvatt, thanks for the heads up
[18:32] <ricotz> Sarvatt, so is gallium disabled for nouveau even if the experimental package is installed?
[18:33] <Sarvatt> nope, if you install libgl1-mesa-dri-experimental it's there
[18:33] <Sarvatt> i was just fudging it and installing it in libgl1-mesa-dri before
[18:33] <ricotz> ok, to the ordered search paths are still set?
[18:33] <ricotz> to7so
[18:33] <ricotz> ok
[18:34] <Sarvatt> yeah everythings in /usr/lib/dri now except the few things that conflict with classic mesa naming (r600, i915, swrast gallium)
[18:34] <Sarvatt> and those are all in /usr/lib/dri/gallium, no more --with-dri-searchpath crap
[18:35] <Sarvatt> i dont fancy setting up diversions and replaces: will completely bust downgrades
[18:35] <ricotz> alright, i will look at it
[18:37] <Sarvatt> if libgl1-mesa-dri-experimental has replaces: libgl1-mesa-dri to overwrite the -dri ones and you remove libgl1-mesa-dri-experimental later it'll just delete all those drivers and not reinstall the -dri ones :(
[18:51] <jcristau> Sarvatt: yeah so you need Breaks+Replaces
[18:51] <jcristau> oh wait.
[18:52] <jcristau> you want to provide the same files in both?  then you probably need conflicts.
[18:54] <Sarvatt> i want to transition people using libgl1-mesa-dri-gallium over to libgl1-mesa-dri-experimental
[18:55] <Sarvatt> think i saw a specific section about that situation in the policy manual, going to go over it again
[20:45] <Sarvatt> argh, forgot mesa needs that latest libdrm commit now
[20:55] <Sarvatt> intel bugs are getting out of control, someone just submitted 11 identical crash reports in a row that didn't auto dupe :)
[20:58] <Sarvatt> oh he's still not done
[22:29] <Sarvatt> RAOF: what was it in mesa that needed dpkg-dev (>= 1.15.6) again?
[22:29] <Sarvatt> oh yeah, symbol patterns in dpkg-gensymbols.. ugh
[22:40] <Sarvatt> and double fun, gettext in lucid is too old to just do a dpkg backport :)