[09:02] <hyperair> bah. mplayer hangs with DRI failure now?!
[09:06] <hyperair> oh wait. no, this is a pulseaudio issue
[09:06] <hyperair> stupid flash
[10:58] <hyperair> Sarvatt: do you get crashes when the scale plugin of compiz is activated?
[11:04] <hyperair> Sarvatt: http://pastebin.com/f4d192c93 <-- looks like an upgrade in mesa caused it
[11:24] <hyperair> Sarvatt: the 0602 mesa git doesn't cause the crash.
[14:01] <Milan-BV> I'd like to debug KMS on 2.6.30rc kernels, with an Intel i915 card - is this the place for it, or do you prefer me to go to the kernel channel?
[14:09] <apw> a tricky one, as the x side belongs here and the kernel side on #u-k, but i'd recommend starting here
[14:10] <Milan-BV> OK
[14:11] <Milan-BV> actually, my system won't finish to boot when I enable KMs and updat emy initramfs
[14:11] <apw> what card do you have
[14:11] <Milan-BV> the screen gets blank in the middle of the boot
[14:11] <Milan-BV> Intel i915 GM
[14:11] <apw> do you have the updated x-server components you need for kms?
[14:11] <Milan-BV> 2.7.1
[14:12] <jcristau> you probably want something newer than 2.7.1
[14:12] <apw> and mesa etc?
[14:12] <apw> there is a specific ppa for kms support iirc
[14:12] <Milan-BV> I guess, I'm using the ubuntu-x-swat PPA
[14:12] <Milan-BV> do you think 2.7.99 is required?
[14:12] <Milan-BV> I've tested it too, but there are terrible mem leaks, so that's not very practical for now
[14:13] <jcristau> terrible mem leaks shouldn't prevent booting
[14:13] <Milan-BV> but since I have problems before X starts, I think the problem comes from elsewhere
[14:13] <jcristau> when does the monitor turn blank?
[14:13] <Milan-BV> no, they don't, but this means I must go back to 2.7.1 after testing to really work on my box
[14:13] <Milan-BV> in the middle of the boot
[14:14] <apw> is the machine up after it turns black?  does ctrl-alt-f1 get you a console?  can you login over ssh?
[14:14] <jcristau> that's not terribly specific :)
[14:14] <Milan-BV> and then my fan starts, just like the GPU/CPU was working too hard
[14:14] <Milan-BV> no, complete freeze
[14:14] <Milan-BV> I've not tried SSH, though
[14:14] <Milan-BV> I'd like to know what logs you need before doing so
[14:15] <apw> can you try booting with quiet and splash removed and see what the last thing said was
[14:15] <apw> if you can login then dmesg would be interesting, and a ps listing
[14:15] <Milan-BV> yeah, that's an idea
[14:15] <Milan-BV> actually, I had tried that in another situation:
[14:16] <Milan-BV> if I only change the conf file in /etc/modprobe.d, I'm able to boot with older 2.6.30 rc's
[14:16] <Milan-BV> the screen goes blank, but when GDM starts everything is fine
[14:16] <apw> so thats normal behaviour yes, sl
[14:16] <Milan-BV> and then I noticed the screen went blank when the manual modules were loaded - includin gi915 I guess
[14:16] <apw> splash, black, gdm
[14:16] <Milan-BV> yeah - logical
[14:17] <Milan-BV> OK I can just reboot and tell you what logs I get
[14:17] <apw> as you get hte hard hang and fans, i'd guess kernel hang, and i'd say the first thing to try is removing splash/quiet
[14:18] <Milan-BV> would you need GPU batch buffers too?
[14:18]  * apw is a simple kernel guy ....
[14:19] <jcristau> Milan-BV: start with dmesg for now :)
[14:19] <Milan-BV> OK, I start with dmesg - anyway that avoid the need to SSH, which is a pain (Windows laptops...)
[14:19] <Milan-BV> see you soon...
[14:39] <Milan-BV> so I'm back
[14:39] <Milan-BV> with good new: you were right
[14:39] <Milan-BV> I had not tested the combination 2.6.30rc7 and latest 2.7.99
[14:39] <Milan-BV> that works now
[14:39] <jcristau> cool
[14:40] <Milan-BV> the problem was with one of the many versions of kernels and drivers I've tested
[14:40] <Milan-BV> now I just need Intel guys to fix my leak ;-)
[14:40] <Milan-BV> one question though: it seems that the boot splash is not using a high resolution
[14:41] <Milan-BV> when I stop the computer, it's much nicer and bigger
[14:41] <Milan-BV> (maybe that's not a concern if many changes will be going on before Karmic, though)
[15:17]  * apw waves to brye
[15:17]  * apw waves to bryce
[15:29] <bryce> heya apw
[15:30] <apw> bryce, is the xedgers pile going to support kms ati should we have it?
[15:30] <apw> and do you have something that can test with an ati kms enabled kernel?
[15:30] <bryce> yep, that's the plan
[15:30] <apw> plan as in it will, or as in it should?
[15:30] <bryce> sure, I've got a test box with pci nvidia and ati cards
[15:31] <bryce> should
[15:31] <apw> ok i've put up a dirty roll-forward kernel in a PPA if you are intrested in testing it
[15:31] <bryce> yes, definitely
[15:31] <apw> its a simple roll forward of gliss' patch pile so i have no idea if it even boots
[15:32] <bryce> ok, I need to update my box but can probably test it later today or tomorrow
[15:32] <apw> https://edge.launchpad.net/~apw/+archive/daily
[15:32] <apw> is a badly documented kernel the kms1 one ... it has the radeon patch stack on it.  any feedback you can get is perfect
[15:34] <bryce> cool, yeah I just need to update -intel for that bug you found yesterday, then will hammer on ati
[15:37] <bryce> hmm, this has an RV680 in it currently; wonder if that's too new?
[15:44] <Sarvatt> you'd need different drm, drivers and mesa than edgers and the ati kms specific branches arent mergeable yet last i looked so it'd probably have to be another PPA
[15:45] <Sarvatt> as far as I could see, it was all so confusing because theres so many different branches of everything out there for it specific to certain cards
[15:47]  * Sarvatt groans at the pain in the butt the XI2 merge is turning out to be
[15:53] <Sarvatt> does your kernel generate a new linux-libc-dev apw?
[15:54] <Sarvatt> ah sorry i can look myself
[15:55] <apw> Sarvatt, likely yes
[15:56] <apw> is that good or bad i wonder <- Sarvatt 
[15:57] <jcristau> apw: probably good, as the drm headers will be needed for libdrm-radeon
[15:57] <jcristau> for the new ioctls and stuff
[15:57] <apw> ahh thats handy
[15:57] <Sarvatt> doesnt look like it does, just wondering because you'd have to add Replaces: linux-libc-dev and override the header deletion from the libdrm package built for it
[15:58] <tseliot> tjaalton, wgrant: are we going to get a new release of synaptics for karmic?
[15:58] <tseliot> i.e. newer than the current version
[15:58] <apw> why would i need to replace it, as the new one would be a direct replacement
[16:02] <Sarvatt> i'm blind and i thought i didnt see the new linux-libc-dev in the dsc, sorry apw
[16:03] <apw> :)
[16:04] <Sarvatt> tseliot: been alot of complaints about the lastest synaptics in karmic with the default tap disabled, thats for sure
[16:05] <tseliot> Sarvatt: that's because I haven't ported my patches to the new driver in Karmic ;)
[16:06] <Sarvatt> they all still apply fine except 108 and 109, i think wgrant fixed up 109 to apply on the lastest though on his PPA but not sure how relevant it is anymore
[16:07] <Sarvatt> (the alps one)
[16:08] <tseliot> one of my patches re-enabled tapping
[16:09] <tseliot> hmm... I see only 2 patches in the karmic package
[16:11] <tseliot> neither of which is mine
[16:14] <jcristau> that's probably bug 378391
[16:17] <bryce> apw: fix for bug 383129 is uploaded
[16:25]  * hyperair waves at Sarvatt 
[16:47] <tjaalton> tseliot: I believe so, why?
[16:51] <Sarvatt> ahhh what a headache, my x11proto-input-dev.install needed changes, only took me 3 hours and a crapload of builds to figure it out lol
[16:57] <Ng> interestingness, the occasional, logless X crashes on resume I was having in jaunty with all versions of the intel driver appear to be entirely reproducible in karmic
[16:58] <Ng> which is a shame because I like suspending, but on the plus side, I now have a couple of logs of the backtrace
[17:00] <Ng> I'll get it all in a bug on LP just as soon as I go find a keyboard so I can log into the machine that has my jaunty stuff backed up onto it, including the ssh key I need to get into that machine ;)
[17:05] <Ng> oh wow, locking the screen and pressing a key crashes X too
[17:05] <Sarvatt> Ng what driver are you using? 
[17:05] <tseliot> tjaalton: so as not to have to rewrite my patches more than once ;)
[17:05] <Ng> Sarvatt: karmic's intel
[17:06] <bryce> Ng: if the latter crash is bug 383129, I just uploaded a fix for it
[17:06] <Sarvatt> the git200602 has problems where it'd crash X with just about anything fullscreen
[17:06]  * Sarvatt cheers
[17:06]  * Ng has a peek
[17:06] <tjaalton> tseliot: push them upstream if the defaults are wron
[17:06] <tjaalton> +g
[17:06] <tjaalton> gotta go ->
[17:07] <Ng> bryce: certainly sounds similar, I'll wait until that hits the archive to test it
[17:08] <Ng> I'm really glad I decided to do a karmic re-install on my week off, I already found a bunch of bugs :)
[17:09] <Ng> bryce: I'd expect it might actually fix both things, since resuming will involve doing fullscreeny things like locking
[17:09] <Sarvatt> you could test now by disabling compiz and seeing if it works :D
[17:11] <Ng> Sarvatt: testing from a gdm screen it doesn't crash :)
[17:11] <Ng> it's also damn fast :o
[17:12] <Ng> can we get rid of the stupid fading thing for screen locking? that seems to take the longest ;)
[17:12] <Sarvatt> thats a compiz plugin isnt it?
[17:13] <Ng> quite possibly, but I'm not sure
[17:13] <hyperair> i think gnome-screensaver does the fading.
[17:13] <hyperair> at the very least, i don't have any compiz plugin that fades stuff so slowly
[17:13] <Ng> Sarvatt: oh, it continues to not crash when testing suspend/resume from gdm, but the mouse pointer does disappear until I switch vt and back
[17:13] <hyperair> by the way, Sarvatt, did you get my message about the mesa crash?
[17:14] <Sarvatt> login/logout plugin in compiz maybe?
[17:14] <hyperair> is there such a thing?
[17:15] <hyperair> oh there is
[17:15] <hyperair> it's not enabled for me
[17:15] <Sarvatt> no i didnt, been busy all morning trying to get xserver 1.7 working with the XI2 merge before the firefox buildbot of doom runs in an hour and makes it so you cant retry builds for 4 hours :D
[17:16] <hyperair> hahahahaha
[17:16] <hyperair> xD
[17:16] <hyperair> good luck =p
[17:16] <hyperair> by the way, does XI2 mean i get one pointer for my mouse and one pointer for my touchpad? O_o
[17:17]  * hyperair is about to go git bisecting
[17:18] <hyperair> then i'll be able to isolate the commit
[17:19] <Sarvatt> in a bit when i get this working i'll upload a mesa without the 2 patches
[17:20] <hyperair> i dont' think it's the two patches.
[17:20] <hyperair> the two patches were enabled in yesterday's build, right?
[17:20] <hyperair> i mean 0602's
[17:20] <hyperair> 0603 has issues.
[17:20] <hyperair> 0602 doesn't
[17:20] <Sarvatt> can you install the dbg packages for the backtrace? wasnt any info in the one you pastebinned
[17:20] <hyperair> and oh hell, i accidentally purged my /tmp instead of ./tmp folder
[17:21] <hyperair> right
[17:21] <Sarvatt> scale plugin is working fine here
[17:21] <hyperair> is it?
[17:21] <hyperair> hmm
[17:21] <Sarvatt> 945 though and im not using edgers
[17:22] <hyperair> ah.
[17:22] <hyperair> the edgers' mesa had issues =\
[17:22] <hyperair> has
[17:23] <Sarvatt> i'm using the same mesa but its built against a newer dri2proto
[18:05]  * hyperair groans. how long does mesa take to compile?!
[18:05] <jbarnes_LHR> hyperair: it's fast if you disable everything and only enable the driver you want
[18:05] <hyperair> it's been 40 minutes already!
[18:05] <hyperair> hmm
[18:05] <hyperair> disable everything huh
[18:05] <jbarnes_LHR> --disable-gallium --disable-glut --with-dri-drivers=i965 (or whatever)
[18:05] <hyperair> O_o
[18:06] <hyperair> hmm
[18:06] <hyperair> i should do that huh
[18:09] <hyperair> hmm
[18:09]  * hyperair pkoes around the debian/rules
[18:09] <hyperair> it looks scary
[18:09] <hyperair> positively scary
[18:09] <Sarvatt> anyone happen to know what could be causing that build error? http://tinyurl.com/qow2tr
[18:09] <Sarvatt> sorry, guess i should ask in MOTU
[18:10] <Sarvatt> hyperair, one sec i'll give you a rules to build a minimal version
[18:10] <hyperair> thanks
[18:10] <hyperair> but wait
[18:10] <hyperair> i think if i override DRI_DRIVERS i can get a minimal version, right?
[18:12] <Ng> bryce: looks like that upload fixed both the things I was seeing \o/
[18:13] <bryce> Sarvatt: you need newer x11proto-input
[18:13] <bryce> Ng: excellent
[18:14] <Sarvatt> Unpacking x11proto-input-dev (from .../x11proto-input-dev_1.9.99.10+git20090604.56da1968-0ubuntu0sarvatt2_all.deb) ...
[18:14] <Sarvatt> my x11proto-input must be messed up
[18:14] <bryce> oh wait, I'm wrong
[18:14] <bryce> this is the error:
[18:14] <bryce> ../configure: line 11256: syntax error near unexpected token `XI,'
[18:15] <bryce> is the comma out of place?
[18:15] <bryce> anyway, it's unhappy with something in this line:
[18:15] <bryce> ../configure: line 11256: `PKG_CHECK_MODULES(XI, xproto >= 7.0.13 x11 >= 1.1.99.1 xextproto >= 7.0.3 xext >= 1.0.99.1 inputproto >= 1.9.99.10)'
[18:15] <hyperair> wait a sec
[18:15] <hyperair> if that line is there, then PKG_CHECK_MODULES was not expanded
[18:15] <hyperair> the macro wasn't expanded.
[18:15] <hyperair> are you missing pkg-config or something?
[18:16] <Sarvatt> yeah i dont know why the comma is screwing up but it doesnt screw it up from libxi with the same line in the script 2 days ago
[18:16]  * hyperair still thinks that the macro wasn't expanded.
[18:17]  * hyperair pokes Sarvatt 
[18:17] <hyperair> PKG_CHECK_MODULES should not appear in the configure script at all.
[18:19] <Sarvatt> it all builds fine locally so i'm guessing its a build depends problem but the same exact build depends were working 2 days ago in thjaeger's PPA
[18:20] <hyperair> Sarvatt: add pkg-config to the build-dep. it should fix the issue.
[18:20] <Sarvatt> it's in it already
[18:20] <hyperair> are you sure?
[18:21] <hyperair> the build log doesn't seem to show pkg-config being installed
[18:21] <Sarvatt> hmmm
[18:22] <Sarvatt> ahhhh hell
[18:22] <Sarvatt> teach me to do that at 6 am
[18:22] <Sarvatt>  x11proto-input-dev (>= 1.9.99.10)
[18:22] <Sarvatt>  pkg-config,
[18:22] <Sarvatt> no comma
[18:22] <bryce> aha
[18:22] <Sarvatt> thanks guys :)
[18:22] <hyperair> hehehe
[18:25] <hyperair> meh maybe i should have done -j2
[18:31] <Sarvatt> now i wonder if i should be rebuilding input drivers from master or merging in whot's seperate XI2 input driver repos into them..
[18:33] <hyperair> note to self: lower cpu frequency before pulling something like make -j2 off.
[19:05] <bryce> Sarvatt: I can sympathize!
[19:06] <bryce> er, nevermind
[19:18] <Sarvatt> sure would be nice to move this whole PPA over to edgers where other people could help (hint hint tormod)
[19:18] <Sarvatt> go figure he isnt in here :D
[19:34] <Sarvatt> sorry we're using 7.5.0 and 7.6.0 for mesa by the way, thats how it comes out with the scripts and i dont know how to go back and fix it now without getting people stick on the package versions they have now since 7.6~git would be lower
[19:53] <Sarvatt> ah looks like the animated cursor patch needs to go now too
[20:40] <Sarvatt> yeesh, in over my head now - http://launchpadlibrarian.net/27504178/buildlog_ubuntu-karmic-i386.xorg-server_2%3A1.6.99.1%2Bgit20090604.993daf06-0ubuntu0sarvatt3_FAILEDTOBUILD.txt.gz
[20:42] <bryce> ew
[20:44] <bryce> apw, hmm, testing your -ati kernel bits now.  Kernel boots up okay and gdm displays the login screen, but I get an unusual gconf error message when trying to log in.
[20:44] <bryce> "There is a problem with the configuration server."  Haven't seen that one before.
[20:44] <apw> bryce, would we say kms is on?
[20:44] <bryce> but this is after doing a full dist-upgrade to latest bits, so could be some other thing
[20:44] <apw> gnome-settings-manager has been changed, and if i am right is taking near 30s to start
[20:45] <bryce> apw: doesn't look like it... do I need to set a modprobe.d flag like with intel?
[20:45] <apw> as my cpu stays in perf for some time
[20:45] <apw> hrm
[20:45] <Sarvatt> do you see a drmfb loading in the dmesg?
[20:45] <bryce> Sarvatt: nope, but I see an error message
[20:45] <apw> the help on the option i enabled claiimed to enable by default
[20:45] <apw> but then its prolly lying
[20:45] <bryce> [drm:radeon_driver_load_kms] *ERROR* Failed to initialize radeon, disabling IOCTL
[20:46] <bryce> fwiw, this is on a RV630.  Probably I need a >=R5xx card
[20:46] <bryce> mm
[20:46] <apw> MODULE_PARM_DESC(modeset, "Disable/Enable modesetting");
[20:46] <apw> module_param_named(modeset, radeon_modeset, int, 0400);
[20:47] <apw> though i enabled CONFIG_DRM_RADEON_KMS which is meant to default it on
[20:47] <Sarvatt> There is no support for r6xx/r7xx (so your card is not supported) hw yet.
[20:48] <Sarvatt> thats what jglisse says about that error to someone on his livejournal http://jglisse.livejournal.com/1822.html?thread=7198
[20:48] <apw> bottom
[20:53] <rawler> anyone else with problems using KMS on their Mac Mini?
[20:53] <rawler> just found http://lists.freedesktop.org/archives/intel-gfx/2009-February/001249.html about the problem.. seems like there's a semi-hack-patch for a quick workaround..
[20:53] <bryce> ok, I also have an x1550 which purports to be an R520, let's try that next...
[20:54] <rawler> doesn't seem to be in the Karmic kernels yet, though.. any pointers on getting it there?
[20:56] <Sarvatt> it is and its completely different now
[20:58] <Sarvatt> http://kernel.ubuntu.com/git?p=ubuntu/ubuntu-karmic.git;a=history;f=drivers/gpu/drm/i915/intel_lvds.c;h=53731f0ffcb52b4d3444cdfe659f38b5fec479a0;hb=HEAD
[20:59] <rawler> oki.. must be something else b0rking, then.. :)
[20:59] <bryce> ...yay \o/ kms on -ati
[20:59] <rawler> maybe that dmesg is shouting "i915 0000:00:02.0: DVI-D-1: no EDID data"
[21:00] <bryce> logs in ok too now
[21:01] <bryce> fb0: radeondrmfb frame buffer device
[21:01] <bryce> apw: success
[21:02] <apw> bryce rocking ... thanks
[21:02] <bryce> I'll take a quick shot running my xsmoke test on it...
[21:03] <apw> bryce, excellent
[21:06] <Sarvatt> rawler: maybe search bugs.freedesktop.org for mac mini (or mac EDID kms) too see if you can get any hints about it
[21:08] <bryce> um, this is weird
[21:09] <bryce> not even sure how to describe it...  the console got shifted over to the right and wraps from right to left
[21:09] <hyperair> yay second step of bisect done.
[21:10]  * bryce tries running individual tests manually...
[21:15] <bryce> apw: hmm, no DRI or DRI2 loaded for some reason (so no compiz)
[21:18] <bryce> wait, I think I know the cause of this...
[21:19] <hyperair> O_o
[21:22] <bryce> nope, I'm wrong.  Something is not right in DRM land here
[21:22] <apw> bryce, hrm ... 
[21:23] <rawler> Sarvatt: yep.. I have been..
[21:23] <bryce> (EE) RADEON(0): [dri] RADEONDRIGetVersion failed because of a version mismatch.
[21:23] <bryce> [dri] Disabling DRI.
[21:23] <bryce> (II) AIGLX: Screen 0 is not DRI2 capable
[21:23] <bryce> version mismatch... sounds fixable
[21:23] <rawler> Sarvatt: I found https://bugzilla.redhat.com/show_bug.cgi?id=501042, which fits my problem (I get those same messages in dmesg, and are using DVI-over-HDMI)
[21:24] <rawler> Sarvatt: so, I tried connecting it to my raw-dvi-monitor, which finally gave me some sort of picture, but it was severly distored, and the system didn't really boot..
[21:25] <bryce> ok, on to next test... video playback
[21:27] <Sarvatt> did you use arlied or jglisse's kms apw?
[21:27] <Sarvatt> guessing jglisse's since it didnt work on his rv630
[21:27] <apw> jglisse 
[21:28] <apw> as airlied's handn't been updated when i cehcked
[21:29] <apw> bryce, there are two new commits in glisse's tre
[21:29] <Sarvatt> when i get some free time i can put together the other bits you need, modesetting-gem of libdrm, radeon-gem-cs3 of xf86-video-ati
[21:30] <bryce> okayyy no xv
[21:31] <bryce> xrandr seems to work though :-)
[21:32] <bryce> chvt works, but it's not as quick as I've seen on intel
[21:38] <bryce> heya tormod
[21:39] <Sarvatt> drm built
[21:39] <bryce> tormod: we've got kms on -ati :-)
[21:39] <tormod> hi bryce, I think I heard rumour about it
[21:39] <tormod> in a ppa? which libdrm branch/patch?
[21:39] <bryce> suspend/resume sort of worked.  I got a zebra stripe corruption on the screen but vtswitching cleared it
[21:40] <bryce> tormod: <apw> https://edge.launchpad.net/~apw/+archive/daily
[21:41] <Sarvatt> i'm putting the other packages you need here (the karmic ones as they come along), feel free to copy it over :)
[21:41] <Sarvatt> https://edge.launchpad.net/~sarvatt/+archive/ati
[21:41] <bryce> tormod: I didn't do any -ati or libdrm changes, this is just with the X bits currently in karmic
[21:41] <bryce> tormod: however X came up without DRI or Xv so it's a bit unuseful, but otherwise works
[21:41] <tormod> nice, oh really no funky branches needed?
[21:41] <Sarvatt> only problem is modesetting-gem is 2.4.4 and I think radeon-rewrite needs 2.4.5
[21:42] <Sarvatt> yeah funky branches needed
[21:42] <bryce> tormod: well, probably for DRI and Xv and fast vtswitching and so on we'll need more funkiness, but good start so far
[21:42] <tormod> Sarvatt: I saw a patch floating around against current libdrm
[21:43] <tormod> apw: bad changelog :) which branches of which repo did you merge in?
[21:44] <bryce> Sarvatt: kewl thanks for doing the ppa
[21:44] <tormod> Sarvatt: http://neo-technical.wikispaces.com/kms-glisse links to a patch
[21:44] <Sarvatt> ./auto-xorg-git -d origin/debian-unstable -u git://people.freedesktop.org/~glisse/xf86-video-ati -b radeon-gem-cs3 -e 1 -H hooks-karmic ati    for ddx
[21:44] <Sarvatt> oh nice
[21:44] <bryce> mm, time for lunch first.  bbiab
[21:44] <tormod> Sarvatt: let's make a "radeon-kms" ppa in xorg-edgers
[21:45] <Sarvatt> sure, copy stuff over :D
[21:45] <tormod> will you try that patch or should I take a look?
[21:45] <Sarvatt> i just loaded the page
[21:46] <Sarvatt> ahh thats gonna take a bunch more work, all you :)
[21:51] <Sarvatt> oh hmm, didnt notice mesa failed to build on edgers, same package built fine on testing
[21:52] <tormod> Sarvatt: I'm on it
[21:52] <Sarvatt> getting lots of these errors the past few days and they go away after doing a rebuild 
[21:52] <Sarvatt> /usr/bin/install: cannot create regular file `/build/buildd/mesa-7.6.0~git20090604.81a0ef3f/debian/tmp/usr/lib/pkgconfig/gl.pc': File exists
[21:52] <tormod> (libdrm I mean)
[21:53] <Sarvatt> lol here's why
[21:54] <Sarvatt> WARNING: The following essential packages will be removed.
[21:54] <Sarvatt> This should NOT be done unless you know exactly what you are doing!
[21:54] <Sarvatt>   mktemp
[21:54] <Sarvatt> problem in karmic right now
[21:54] <Sarvatt> why drm failed on the ati ppa i mean
[22:00] <Sarvatt> well I put a drm and ddx that will work up on mine, they wont build because of the problem in karmic right now but copying after its fixed should be ok
[22:02] <Sarvatt> could actually copy the radeon-rewrite from jaunty too in that PPA too, only one trivial commit since then
[22:03]  * Sarvatt can't speak properly today aparently.
[22:04] <tormod> thanks I will copy in your radeon-rewrite/jaunty to radeon-kms/karmic once I see my libdrm builds
[22:09] <tormod> so everything in karmic using mktemp will fail to build?
[22:11] <tormod> seem like it yeah
[22:11] <Sarvatt> yeah
[22:11] <Sarvatt> probably will be borked for awhile too
[22:11] <Sarvatt> http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=531846
[22:13] <Sarvatt> want me to build anything in karmic for ya tormod?
[22:13] <tormod> on your local machine?
[22:13] <Sarvatt> yeah
[22:14] <Sarvatt> can try out your drm
[22:16] <tormod> thanks
[22:16] <tormod> I guess someone will fix this pretty soon though, no?
[22:17] <tormod> just wonder if apw's kernel has some changes header files that will be used when building libdrm?
[22:18] <Sarvatt> ah wait, yeah would need his linux-libc-dev
[22:20] <tormod> Sarvatt: I will install his kernel and build libdrm here
[22:22] <Sarvatt> giving up on xi2 xserver 1.7 for today, got a nasty dbus problem building it that i have no idea how to fix that I'm hoping other people have :D
[22:24] <tormod> hmm I don't even have a real karmic installation
[22:27] <tormod> oh and my libdrm package is broken anyway :)
[22:45] <bryce> hmm, probably should merge debian's -ati for karmic next I guess
[22:46] <tormod> are there Ubuntu changes?
[22:47] <bryce> some patches
[22:47] <bryce> nothing major
[22:47] <tormod> is it based on 6.12 branch?
[22:48] <bryce> yes the 6.12 branch
[22:49] <bryce>   * Pull upstream commits from 6.12-branch up to 248b435a.
[22:55] <hyperair> Sarvatt: found it. 7f8000db8bd45bb95bda4a4f8535c49b8ef74254
[23:04] <bryce> craptacular, LP is down again
[23:05] <Sarvatt> oh, http://cgit.freedesktop.org/mesa/mesa/commit/?id=7f8000db8bd45bb95bda4a4f8535c49b8ef74254 makes your scale plugin crash?
[23:08] <hyperair> yes
[23:08] <hyperair> not just scale
[23:08] <hyperair> rotate
[23:08] <hyperair> er
[23:08] <hyperair> ring window switcher i mean
[23:08] <tormod> bryce: scheduled downtime again? or broken?
[23:09] <bryce> scheduled iirc
[23:09] <bryce> think it's supposed to be short.  *reload* *reload*
[23:11] <tormod> do they have to schedule it to hacking prime time :)
[23:20] <bryce> gahh still down
 tsimpson: yeah, we ran into some difficulties
[23:22] <bryce>  services are coming back up now
[23:26] <bryce> aha back
[23:41] <tormod> bryce: what went wrong with the xorg fglrx apport hook?
[23:42] <bryce> tormod: I'm not sure exactly, but the shelling out call was failing
[23:42] <bryce> in some cases it printed an error in the bug report, in other cases the bug report could not be filed
[23:43] <tormod> from the traceback it seems to fail in "report" and not in command_output
[23:44] <tormod> anyway., "redundant" means there is something else flagging fglrx?
[23:46] <bryce> yep
[23:47] <bryce> see for example https://bugs.edge.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/383486
[23:48] <bryce>     # Detect proprietary drivers                                                                                                  
[23:48] <bryce>     if 'fglrx' in report['ProcModules']:
[23:48] <bryce>         report['fglrx'] = recent_syslog(re.compile('fglrx'))
[23:48] <bryce>     else:
[23:48] <bryce>         report['fglrx'] = 'Not loaded'
[23:48] <bryce> I think maybe mdz did that
[23:48] <tormod> hah grep returns 1 when not found, that's all
[23:49] <tormod> in a shell script script (or makefile) you would use grep ... || true
[23:50] <tormod> I think "fglrx: Not loaded" should be silenced away
[23:54] <tormod> g'night
[23:54] <bryce> night
[23:54] <bryce> tormod: building new -ati now; will upload once I've tested it.
[23:55] <tormod> will anything build in karmic ATM?