[00:01] <maxb> It's weird how some people say ftbs and some say ftbfs
[00:02]  * maxb is in the ftbfs camp
[00:29] <Sarvatt> that was fast, x11proto-dri2 synced :)
[00:33]  * bryce grins
[00:33] <bryce> actually, slangasek said it was already autosync'd?
[00:35] <Sarvatt> it wasnt when i looked at aptitude show x11proto-dri2-dev this morning! odd
[00:35] <Sarvatt> -vv rather
[00:36] <Sarvatt> theres xserver 1.6.2 rc2
[00:36] <RAOF> Do we want to pull in the couple of libdrm-nouveau patches needed to libdrm to pull in a new nouveau snapshot into Karmic?  I can pull them into libdrm git on alioth if so.
[00:39] <bryce> RAOF, sure as long as it doesn't conflict with -ati's
[00:41] <bryce> Sarvatt, yeah dunno, was it only in debian experimental before?  (which wouldn't get autosync'd... however I didn't mention that in my sync request)
[00:41] <RAOF> bryce: What part would conflict with -ati's?  ATI doesn't yet ship a libdrm-radeon (at least in any libdrm release) as far as I can see?
[00:42] <RAOF> I guess the ttm & drm modules from nouveau-kernel-source *would* conflict with ATi's stuff in 2.6.31, but that'll only be pulled in by x-x-v-nouveau.
[08:37] <jcristau> Sarvatt: dri2 1.1 ought to be compatible with 1.0
[08:37] <jcristau> it's not, but that's a bug.
[11:02] <tjaalton> jcristau: does it concern mesa too? I mean, would something break if mesa was built against it?
[11:07] <jcristau> tjaalton: the issue seems to be in the server/driver interface, so no
[11:14] <tjaalton> ah, great
[15:58] <tjaalton> mesa and xorg uploaded
[16:19] <tjaalton> huh, seems I didn't fix the mesa build properly
[16:19] <tjaalton> since lpia failed already
[16:20] <tjaalton> Sarvatt: did you apply the exact same patch from jcristau, or modified?
[16:21] <tjaalton> anyway, need to do some shopping and then head back home.. I'll sort this out once there
[16:22] <jcristau> heh, missing ;
[17:44] <tormod> dpkg: error processing /var/cache/apt/archives/xserver-xorg_1%3a7.4+3ubuntu1_i386.deb (--unpack):
[17:44] <tormod>  trying to overwrite `/usr/lib/hal/debian-setup-keyboard', which is also in package hal
[17:45] <tormod> sorry that was fixed 15 minutes ago I see
[17:48] <tjaalton> yep :)
[17:48] <tjaalton> and looks like the mesa build went fine too
[17:49] <bryce> tjaalton, thanks for the mesa and xorg uploads!
[17:50] <tormod> finally mesa 7.5 in karmic \o/
[17:51] <tormod> well failed to build all over the place though
[17:52] <tormod> tjaalton: jcristau	heh, missing ;
[17:53] <tjaalton> tormod: yes, uploading a new one right now
[18:05] <Sarvatt> tjaalton: i modified it because of the missing ; and linked a fixed up one last night but it looks like you already worked it out, sorry about that
[18:05] <tjaalton> Sarvatt: yeah, it's good now
[18:06] <A|i> since upgrading to 9.04, my ubuntu freezez randomly
[18:06]  * Sarvatt cheers at all the uploads today
[18:06] <A|i> when it freezes, nothing works, i have to force the machine to restart
[18:09] <tormod> is it normal that I have xlibmesa-gl-dev installed? can't see what depends on it
[18:09] <tormod> A|i, what card do you have?
[18:10] <A|i> tormod, radeon 9600
[18:10] <A|i> yes, it's unsupported in jaunty
[18:10] <tormod> A|i, unsupported, why? is it agp?
[18:11] <A|i> tor, i mean the  amd/ati driver cannot be used as jaunty uses the new xorg
[18:11] <A|i> this is really frustrating
[18:11] <tormod> A|i, you don't need fglrx
[18:12] <A|i> tormod, i'm using the free driver (which sucks)
[18:12] <A|i> it's very slow
[18:12] <tjaalton> tormod: nope, I don't have it here and I have a lot of headers installed
[18:13] <A|i> tormod, the worst part is that, when it freezes, i lose data on my ntfs drives
[18:13] <tormod> tjaalton, thanks. this was a recent, clean install of karmic but I have been through xorg-edgers packages etc
[18:14] <tormod> A|i, it can be a bit slower than fglrx but should be useable. and definitely not lock up. is it AGP?
[18:14] <A|i> tormod, yes
[18:15] <Sarvatt> thats installed by a metapackage tormod, are you sure you didnt come from hardy or something? :D
[18:15] <A|i> tormod, any idea how to avoid the freezing? googling shows many people have this problem in jaunty, but no solution
[18:15] <tormod> Sarvatt, as I said, clean karmic install - from your kms cd :D
[18:16] <Sarvatt> apt-get build-dep anything?
[18:16] <tormod> A|i, link to bug report?
[18:17] <tormod> Sarvatt, good idea. I guess those do not show up in apt-cache (r)depends
[18:17] <A|i> tormod, here is one: http://ubuntuforums.org/showthread.php?t=1141320
[18:17] <tormod> A|i, that is not a bug report
[18:17] <A|i> tormod, but it's very difficult to trace this problem
[18:17] <A|i> i know, i don't know if anyone has submitted one
[18:18] <tormod> A|i, I know, but you can't expect developers to search the forums for bugs to fix
[18:19] <A|i> tormod, https://bugs.launchpad.net/ubuntu/+source/linux/+bug/364828
[18:19] <tormod> A|i, there is not much harm in filing a new bug and attaching info
[18:20] <tormod> A|i, that bug was closed because it was fixed.
[18:20] <A|i> it wasnt
[18:21] <tormod> A|i, the reporter could not reproduce it any longer -> closed. anyway it was nvidia cards
[18:22] <tormod> A|i, those bugs are highly specific to each driver and often a family of cards
[18:22] <A|i> tormod, yes, but re-constructing this bug is impossible
[18:23] <A|i> i dont really have much to report
[18:23] <A|i> it doesn't get logged too
[18:23] <tormod> A|i, I know but please file a bug using "ubuntu-bug xserver-xorg-video-ati"
[18:23] <tormod> this will attach relevant information
[18:24] <tormod> A|i, let me ask for the 3rd time: is it an AGP card?
[18:24] <A|i> tormod, yes, i answered yes, how can i verify this? is there a command?
[18:24] <tjaalton> probably needs an AGP quirk?
[18:25] <tormod> the log that will be attached to your bug report will confirm this
[18:25] <tormod> yes very probably an AGPMode issue
[18:26] <tormod> A|i, sorry I missed your "yes" in all the talk
[18:26] <A|i> what should agpmode be set to?
[18:26] <tormod> A|i, trial and error, your choices are 1,2,4 or 4,8 depending on your card
[18:27] <tormod> A|i, please see https://wiki.ubuntu.com/X/Quirks#ATI%20AGP%20Mode%20Quirk
[18:27] <tormod> A|i, if you follow up (on launchpad) with this info we can easily fix it
[18:29] <A|i> tormod, i think my agp goes up to 16x, and in bios i set it to 8x, does ubuntu overwrite this again?
[18:30] <tormod> I don't think AGP x16 exists...
[18:31] <A|i> tormod, it is similar to this bug: https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-ati/+bug/349229
[18:31] <A|i> but they dont talk about agp?
[18:33] <A|i> tormod, how can i find out my current agp mode?
[18:33] <tormod> A|i, well they should if the reporter has an agp card :) but anyway file your own bug. different cards - different bugs and quirks
[18:35] <tormod> A|i, grep "agp..Mode" /var/log/Xorg.0.log
[18:35] <A|i> (II) RADEON(0): [agp] Mode 0x1f000a0a [AGP 0x1106/0x0282; Card 0x1002/0x4152 0x174b/0x7c19]
[18:36] <A|i> tormod, the above is not 1,2,4,8?
[18:38] <tormod> A|i, it's bit encrypted: the last "a" in the Mode says this is an 4/8 card.
[18:39] <A|i> tormod, but does it say if it is currently on 4 or 8?
[18:39] <tormod> and the mode is 4 IIRC. try setting 8
[18:39] <A|i> ok, thanks
[18:39] <tormod> well try both and you'll see
[18:40] <A|i> ok,.. i'm going to restart x and wait for it to (not) to happen!
[18:41]  * tormod looks for his agp mode parsing script
[18:57]  * hyperair is annoyed that the key repeat settings seem to not get set correctly for newly plugged in keyboards
[19:05] <tormod> for radeon hangs new in Jaunty there is also http://bugs.freedesktop.org/show_bug.cgi?id=21849
[19:06] <tormod> (since the 2.6.30-rc1 stuff in question was backported to the Jaunty kernel)
[19:06] <bryce> how things going tormod?
[19:06] <tormod> bryce, fine thanks, but too much nice weather for any serious hacking
[19:06] <bryce> tormod, is it time for us to update -ati?  I think we've done updates to all the other drivers so far, I haven't checked where -ati is at tho
[19:07] <bryce> hehe, quite true
[19:07] <tormod> it is always time to update -ati :) at least the 6.12 branch is a no-brainer
[19:09] <tormod> there has been many card-specific fixed, PCI ids and such
[19:09] <tormod> now is a good time to snapshot master, before they put kms in there
[19:10] <bryce> tormod, ok we can pull in a new snapshot; is the current one in xorg-edgers good, or is there a different commit id that is more stable?
[19:10] <tormod> I haven't heard about any regressions
[19:12] <tormod> I would pull up to bb04... just before the kms preparation
[19:12] <tormod> which I have in my PPA I think
[19:13] <bryce> bug tracker seems reasonably quiescent
[19:13] <Sarvatt> 	Check if the composite op is supported in R200CheckComposite. isnt in the one on edgers
[19:14] <tormod> yeah that's bb04
[19:14] <Sarvatt> the got commited like 10 minutes after i uploaded the package lol
[19:15] <bryce> mm, that change is listing as e1a582fd in my tree; maybe I'm on a branch
[19:15] <bryce> # On branch 6.12-branch
[19:15] <bryce> aha
[19:16] <tormod> the 6.12-branch is for SRU and old ladies, I think master is pretty safe at this point
[19:17] <bryce> hehe
[19:18] <bryce> ok sonny
[19:18] <Sarvatt> maybe we should clean up .gitignore and lastcommit files in auto-xorg-git? noticed some stuff hanging around in orig.tar.gz while making debdiffs
[19:19] <bryce> good idea
[19:19] <Sarvatt> could the lastcommit, delete it before creating the orig then make it again after if we need it to hang around?
[19:19] <Sarvatt> could delete rather
[19:19] <Sarvatt> wow, i cant speak today!
[19:20] <tormod> I'd say leave it in, but do not add it to the orig.tar.gz
[19:20] <Sarvatt> oh that too, could add --exclude=.gitignore --excluse=.lastcommit right?
[19:20] <tormod> yes
[19:21] <bryce> so... you guys have a preference, should I pull tormod's package from his ppa, or pull sarvatt's and apply bb04 as a patch?
[19:22] <tormod> mine is using experimental, sarvatt's is from debian-unstable
[19:22] <tormod> I am not sure if there is a difference
[19:22] <Sarvatt> unstable was newer when i looked
[19:22] <Sarvatt> http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=summary
[19:23] <bryce> ok, sounds like sarvatts+patch is the way to go
[19:24] <tormod> might be some pci id changes in debian/
[19:24] <tormod> or you use auto-xorg-git to roll your own :)
[19:24] <bryce> in debian/patches ?
[19:24] <Sarvatt> i dont know, you probably want to remove the hooks for ati anyhow so i would use another
[19:25] <tormod> I just checked http://git.debian.org/?p=pkg-xorg/driver/xserver-xorg-video-ati.git;a=history;f=debian;hb=refs/heads/debian-unstable
[19:25] <tormod> there is a pci id difference from experimental
[19:26] <Sarvatt> yeah unstable doesnt install them
[19:27] <tormod> yes, maybe you don't want that git commit ID patch we add through the hooks
[19:27] <bryce> hmm
[19:27] <tormod> doesn't hurt though
[19:27] <bryce> btw, I nuked the karmic fglrx and nvidia packages from edgers; they're in karmic already.  I saw we were up to 99% full on the ppa
[19:28] <tormod> I've asked for more space, maybe you can kick your colleagues :)
[19:28] <bryce> I'd like to keep the jaunty versions a bit longer since I'd asked folks to test those, but we can drop them later since they're in x-updates
[19:29] <tormod> yes, I won't miss the blobs in xorg-edgers
[19:29] <bryce> tormod, ok is there a bug# or person I can reference?
[19:29] <tormod> bryce, I asked on soyuz answers.lp.net
[19:30] <bryce> yeah in the future I think I should post them to x-updates myself rather than going through xorg-edgers to avoid clashing with other libs in edgers
[19:30] <Sarvatt> we could move hardy and intrepid to another PPA via binary copies and clean it up :D
[19:30] <tormod> well there is not much for intrepid and some people are using it for hardy (LTS and all that)
[19:31] <tormod> would be nice if they fix launchpad to filter releases by default, or as a ppa setting
[19:31] <Sarvatt> desktop support ended though (excuse excuse!) :D
[19:32] <Sarvatt> bryce actually gave me a link that lets you filter it, you can do it manually screwing with the url lol
[19:32] <bryce> tormod, ah I notice you requested on the original space request, but it seems to have scrolled off the list so maybe they've not noticed; I'll file a new request
[19:32] <tormod> oh is that true? isn't it until 9.10 or something?
[19:32] <tormod> bryce: it's there if you filter on Open
[19:33] <tormod> I hope the soyuz people filter on open, another thing that could have been default :)
[19:34] <Sarvatt> https://edge.launchpad.net/~xorg-edgers/+archive/ppa?field.series_filter=jaunty
[19:34] <tormod> isn't LTS supported on the desktop until next LTS?
[19:34] <tormod> maybe we can add those links in the header of the page?
[19:36] <Sarvatt> trying to find where i read it, i think it was like 18 months desktop and the rest is just security updates so that would put it at 9.10 then
[19:36] <tormod> oh for lock-ups in jaunty there is also https://bugs.edge.launchpad.net/bugs/355155
[19:38] <bryce> tormod, LTS's are supported for longer than just the next LTS
[19:38] <bryce> aiui, dapper is just now going away
[19:38]  * tormod actually runs hardy on some lab computers
[19:39] <Sarvatt> clocksource tsc unstable is just a harmless error message with how it checks it on bootup though...
[19:39] <bryce> https://answers.edge.launchpad.net/soyuz/+question/75728
[19:40] <tormod> Sarvatt, the bug has importance=high ?
[19:40] <Sarvatt> i havent looked at that bug yet but i'm just going to go out on a limb and guess they have vbox or  kvm modules loaded
[19:41] <Sarvatt> i get clocksource tsc unstabled on every pc that is able to change its frequency dynamically
[19:42] <tormod> Leann triaged it to High so there must be something to it
[19:53] <Sarvatt> oh tormod, I'm sorry, i was thinking of 6.06 desktop support. sheesh :)
[19:56] <tormod> omg the 355155 bug mentioned has become a metoo black hole
[19:56] <Sarvatt> because of the title!!!
[19:56] <Sarvatt> everyone with multiple cpus or cpus that can change frequency get that in dmesg!
[19:57] <Sarvatt> its not a bug, it just means it cant use TSC as the clock source which is intentional, it falls back to acpi_pm
[19:58] <Sarvatt> sudo cat /sys/devices/system/clocksource/clocksource0/available_clocksource
[19:58] <Sarvatt> sudo cat /sys/devices/system/clocksource/clocksource0/current_clocksource
[20:01] <bryce> 231 comments, not bad
[20:02] <tormod> tjaalton, seems like the new xorg (?) broke X via gdm. startx works
[20:02]  * bryce adds comment, "This bug affects me too!  But I have different hardware.  When will it be fixed???"
[20:03] <tormod> Warning:  Could not generate /etc/X11/xorg.conf.failsafe for vesa driver
[20:03] <tormod> bryce, go back to windows :)
[20:04] <tormod> and my keyboard layout is lost
[20:06]  * Sarvatt makes a note to not reboot anytime soon :D
[20:09] <Sarvatt> oh man, right as I said that i noticed my battery had .5% power left
[20:10] <Sarvatt> g-p-m wont stay open longer than 30 minutes or so lately for me so i've been checking it manually
[20:13]  * Sarvatt makes a new bug saying Cannot allocate resource for EISA slot 1 error in dmesg causes lockups in Jaunty
[20:19] <tormod> did anyone else try restarting X after the last updates, or find out something_
[20:19] <Sarvatt> how did you even install all of the updates?
[20:19] <Sarvatt> or did you not notice the error?
[20:20] <Sarvatt> oh now its published, sweet
[20:24] <tormod> from the general silence I suppose everybody is staring at their text consoles :)
[20:24] <Sarvatt> i'll try now
[20:25] <rick_h_> tormod: well I stopped gdm on boot
[20:25] <rick_h_> and setup an .xinitrc
[20:25] <rick_h_> and so have things 'working'
[20:25] <rick_h_> but I was a moron and updated when I shouldn't have so taking my licks
[20:26] <rick_h_> although booting my WM this way is causing issues with my fun .Xresources/.Xmodmap stuff
[20:28] <tormod> rick_h_, you can just run startx instead of making an .xinitrc right?
[20:28] <rick_h_> tormod: yea, but to get awesomeWM started as my default WM I exec awesome in my .xinitrc to get the right WM
[20:29] <jbarnes> bryce: you'll want cec9fc6f6cffce186606f39982d0d78ff7c63bbf from the 2d driver
[20:30] <jbarnes> should fix the dpi differences people have been seeing, along with the display properties applet in the kms case
[20:30] <tormod> if awesomeWM has a desktop file you can choose it in a gconf setting somewhere
[20:31] <rick_h_> yea, I have it setup as a default in gdm and it works ok there. 
[20:31] <tormod> rick_h_, I see
[20:31] <rick_h_> but since gdm is blowing up on me and locking up my X and all this way is working
[20:31] <rick_h_> and once I get my blown up screen from GDM, ctrl-alt-1-6 won't give me a terminal either
[20:32] <tormod> rick_h_, intel?
[20:32] <rick_h_> yea
[20:32] <rick_h_> T61
[20:32] <tormod> the joy of kms I suppose
[20:33] <rick_h_> well I knew better. I am heading out of town and figured I'd do updates before I left
[20:33] <rick_h_> then boom :)
[20:34] <tjaalton> tormod: how could that be?
[20:34] <tormod> tjaalton, did you not experience it?
[20:35] <tjaalton> I should probably try :)
[20:35] <tormod> dog food :)
[20:35] <tjaalton> testing ftw
[20:36] <tormod> I guess gdm fails to start x then failsafeX fails because it tries to run dexconf (which it should not any longer, right?)
[20:37] <tjaalton> which kernel?
[20:37] <tormod> 2.6.30-10-generic
[20:37] <tjaalton> .31 fails here, intel claims no modes
[20:37] <tjaalton> ok
[20:37] <tormod> 2.6.30-10.12-generic to be precise
[20:38] <tjaalton> I'm still running -8, because of the dpms hanger
[20:38] <tjaalton> anyway, upgrading now..
[20:41] <jbarnes> Sarvatt: just fixed the bug where in KMS mode outputs didn't have the EDID blob
[20:41] <Sarvatt> yes, very broken and I couldnt figure out why. its forcing failsafe mode no matter what for some reason
[20:41] <jbarnes> which makes the display applet easier to use and will probably fix the dpi differences between kms and ums
[20:41] <Sarvatt> actually had to boot up windows here so i can look through the changes to try to figure it out
[20:41] <Sarvatt> oh nice!
[20:42] <Sarvatt> it might be a bit until i can update edgers, in windows atm because of problems in karmic :D
[20:42] <jbarnes> ouch
[20:42] <bryce> jbarnes, thanks
[20:43] <tormod> this looks messed up:
[20:43] <tormod> gdm[14980]: DEBUG: Loading locale string: Welcome (null) 
[20:44] <tormod> gdm[14980]: DEBUG: Key file does not have key 'Welcome'
[20:44] <tormod> or maybe not
[20:45] <bryce> heh, guess xorg should have been staged on xorg-edgers first
[20:45] <tjaalton> I'll debug it goddammit :)
[20:45] <tormod> heh this is messed up:
[20:45] <tormod> DEBUG: gdm_server_spawn: '/usr/X11R6/bin/X 
[20:45] <tormod> X11R6 ?
[20:45] <bryce> well, the good news is half the desktop team was just complaining a few hours ago that are using xorg-edgers too much and not putting stuff in ubuntu quickly enough for people to test ;-)
[20:46] <tjaalton> tormod: good catch
[20:46] <tjaalton> so gdm needs fixing.. seb128? :)
[20:46] <seb128> tjaalton, what is broken?
[20:46] <tormod> been too long without any X breakage, about time we get some fun
[20:46] <Sarvatt> are we not creating the symlink to X in the postinst now?
[20:47] <tjaalton> seb128: gdm.conf still references /usr/X11R6/bin/X which is finally gone
[20:47] <tjaalton> seb128: it should use /usr/bin/X instead
[20:47] <seb128> tjaalton, and you uploaded that?
[20:47] <seb128> tjaalton, without testing?
[20:47] <tjaalton> seb128: why yes :/
[20:47] <seb128> bah
[20:48] <seb128> great
[20:48] <tjaalton> the package has a Breaks for it, but the debian version
[20:49] <tjaalton> I could fix that
[20:49] <seb128> well that will be as quick to fix gdm now
[20:49] <tjaalton> ok..
[20:49] <seb128> but that means anybody upgrading between now and some publisher run later will have broken xorg
[20:49] <tjaalton> right
[20:49] <seb128> we should not give upload rights for base components to people not testing before upgrading
[20:49] <tormod> they can still use "startx"
[20:49] <seb128> sorry for the rant looking at fixing gdm now
[20:50] <tjaalton> np, deserve it
[20:50] <tjaalton> too much vac :P
[20:52] <tjaalton> well, say I didn't use gnome or gdm, this bug would have gone unnoticed anyway ;)
[20:53] <tjaalton> I'll let the forums know
[20:54] <Sarvatt> ahh yeah * Don't ship the /usr/X11R6/bin symlink in x11-common.  Break gdm <<
[20:54] <Sarvatt>     2.20.7-5.
[20:57] <seb128> tjaalton, gdm change uploaded, you might still want to update the break to gdm <= 2.20.10-0ubuntu3 in the next upload
[20:59] <tjaalton> seb128: yeah, will do
[21:00] <tjaalton> seb128: thanks for the quick update, and sorry for the trouble at this hour!
[21:00] <seb128> no problem, happens to everybody
[21:07] <tjaalton> uploaded
[21:25] <tjaalton> Sarvatt: fixed livecd-rootfs to not touch xorg.conf anymore
[21:25] <tjaalton> pushed to bzr
[21:25] <Sarvatt> phew, editing the links to use /usr/bin/X instead in gdm.conf did fix it for me, there were multiple places it was calling it in there so it threw me off since i only edited the first :D
[21:28] <bryce> hey sarvatt, I've a handy script you might find useful... I'll post to ubuntu-x@
[21:36] <Sarvatt> gotta love etckeeper :) http://sarvatt.com/downloads/0001-saving-uncommitted-changes-in-etc-prior-to-apt-run.patch.txt
[21:36] <Sarvatt> oo, what about bryce?
[21:37] <bryce> changelog merges
[21:38] <Sarvatt> oh nice!
[21:43] <Sarvatt> holy heck g-p-m output is rediculious
[21:45] <Sarvatt> 200k of output into .xsession-errors in 5 minutes :D
[21:53] <bryce> -ati snapshot uploaded to karmic
[21:53] <bryce> Sarvatt, I also stuck it in xorg-edgers, although that probably wasn't necessary
[21:54] <bryce> Sarvatt, tormod: xorg-edgers can move on to focus on -ati+KMS work now :-)
[21:54] <Sarvatt> jbarnes: very nice! just looked over the changes, new one is uploading right now
[21:54] <tormod> bryce, can you ping apw about a newer kernel again? :)
[21:55] <bryce> sure
[21:55] <Sarvatt> yeah we need a linux-libc-dev that has all the radeon KMS stuff that doesnt get built if its not enabled in staging as far as i can see
[21:56] <bryce> ah, Sarvatt, could you write up what's needed in an email to ubuntu-x@?  Then I'll forward that along
[21:57] <bryce> I need to get re-caughtup on kms stuff, I've been focused just on bug stuff exclusively this last week
[22:12] <bryce> ok, time to go do DEQ/DMV stuff...  bbiab
[22:40] <tjaalton> jcristau: the fdi file change probably makes sense for debian too
[23:06] <tormod> bryce, I would link to bug_1734 on your blog, but it requires a login.
[23:33] <apw> bryce, i keep forgetting, how is radeon kms in stock karmic userspace
[23:37] <tormod> apw?
[23:37] <Sarvatt> not working, they are *just* getting it up at least with kms and no libdrm-radeon1 as of a few hours ago in -ati 
[23:39] <Sarvatt> funny, it requires libdrm-radeon1 to build kms support, but says "It won't build against libdrm radeon yet either"
[23:41] <Sarvatt> oh nevermind, the check in configure.ac is just there to check further if it should build dri2 support if DRM_MODE is yes and that part isnt working
[23:44] <Sarvatt> yeah that mesa rules change for sure fixed things, 16 builds with no failures now.. that was annoying me for a month having to babysit the retry button every day :D