[00:08] <bryce> jbarnes, yeah was looking at that earlier, sounded like people were pretty geared up about it at XDC
[00:08] <bryce> jbarnes, I'm still waiting to see what the actual dates will be
[00:09] <jbarnes> yeah
[00:11] <bryce> jbarnes, currently it seems X releases are timed for maximal angst on our end.  Too late to make it by our freeze dates, but early enough prior to our release that we look bad by not including the latest stuff in our release.  
[00:12] <bryce> in my ideal world, we'd see X releases reliably out by the end of January and the end of July
[00:12] <jbarnes> yeah
[00:12] <bryce> er, s/July/August/
[00:12] <jbarnes> I was telling rickspencer3 I just want to see them come out reliably in the first place
[00:13] <jbarnes> the stable releases have been ok (1.6.x) but the major releases have been all over the place
[00:13] <bryce> yep
[00:13] <rickspencer3> exactly
[00:13] <rickspencer3> once there is a cadence, it can be adjusted
[00:13] <jbarnes> right
[00:14] <jbarnes> reliably wrong is better than unreliably wrong :)
[00:14] <rickspencer3> as much as I'd love to see it, I don't the world is necessarily going to revolve around Ubuntu release dates ;)
[00:14] <bryce> I know I can hardly complain, since fedora puts a lot of resources to help with releases so it meets their schedule and we don't, but I'd hope that wasn't the only consideration for when release dates are set
[00:14] <jbarnes> I haven't heard much discussion of distro release dates in the schedule discussion for X
[00:15] <jbarnes> another way to handle it would be like xf86-video-intel
[00:15] <jbarnes> just release frequently enough that any distro can pick up something that's not too stale
[00:15] <jbarnes> (of course having *stable* releases is a prerequisite too)
[00:16] <bryce> yeah that'd be about perfect
[00:16] <bryce> then we could pick and choose
[00:17] <bryce> but yeah at least things are going in the right direction
[00:18] <bryce> jbarnes, since LL is going to be LTS we'll probably be off a bit schedule-wise anyway since we'll be locking things down much earlier than usual.  So we'll probably miss the 1.8 cycle entirely this go around
[06:31] <tjaalton> bryce: it'd make sense to have the same version as squeeze, so it might be wise to coordinate things with them
[06:32] <tjaalton> I know that squeeze will be frozen in December, but there should be a 1.8beta by then
[08:24] <bryce> tjaalton, mind acking bug 446080?
[08:30] <tjaalton> bryce: sure
[08:32] <tjaalton> done
[08:34] <bryce> thanks.  ok I'm done for... bed
[08:34] <tjaalton> night :)
[14:18] <tjaalton> huh, I wonder why libdrm 2.4.14 fails to build because dh_install complains about missing files (usr/include/drm/radeon_* "not installed to anywhere), while 2.4.13 builds just fine
[14:20] <tjaalton> could it be due to the new standards-version?
[14:21] <tjaalton> nope
[14:21] <tjaalton> including those in libdrm-dev.install makes it build, so I'll just add them there
[14:22] <jcristau> is it in git?
[14:22] <tjaalton> the failing one is
[14:23] <jcristau> origin/ubuntu has 2.4.12
[14:23] <tjaalton> ah, I've not pushed it yet
[14:23] <jcristau> ah ok
[14:23] <tjaalton> thought you meant if the environment had something to do with it
[14:24] <jcristau> what's in your debian/libdrm-dev.install?
[14:25] <tjaalton> it's the same as in git now
[14:25] <tjaalton> if I add radeon*, it builds
[14:26] <jcristau> i'd have thought usr/include/* would catch that
[14:26] <tjaalton> 2.4.13-1u1 had the same files, but it didn't complain
[14:27] <tjaalton> maybe I'll just add them then
[14:27] <jcristau> and it used --fail-missing?
[14:27] <tjaalton> yes
[14:27] <jcristau> weird
[14:28] <tjaalton> hmm right
[14:29] <tjaalton> we've changed that wildcard before, because there were conflicts with linux-libc-dev
[14:29] <tjaalton> so it's not includ/* anymore
[14:29] <tjaalton> +e
[14:30] <jcristau> in the debian branch, we rm the conflicting files in debian/rules
[14:30] <tjaalton> ah
[14:30] <tjaalton> so I could change it back
[14:34] <tjaalton> heh, actually it was like that in .13-1u1
[14:34] <tjaalton> no wonder it didn't show up in the debdiff
[14:36] <tjaalton> pushed what I have now
[14:36] <tjaalton> only the changelog entry missing, then it's good to go
[14:37] <jcristau> cool
[14:41] <tjaalton> uploaded -1u0.1 to my ppa for sanity checking
[14:42] <tjaalton> bryce: ^^ libdrm is ready, but I didn't upload it to karmic yet. I'll be mostly away the next hours, but will check here when I can, and upload it once it's ack'ed (by you, I guess)
[15:50] <brobostigon> good afternoon all.
[15:52] <brobostigon> bryce: hello, popey pointed me in your direction, and asked me to ask you politly to have a look at bug 441284, could you please have a quick look at it for me, please. 
[16:45] <rickspencer3eee> bryce, are you online yet? has mesa 7.6 melted the world?
[17:19] <tseliot> rickspencer3eee: not yet, I guess :-P
[17:25] <bryce> rickspencer3eee, no bug reports
[17:26] <brobostigon> bryce: could you have a quick look at https://launchpad.net/bugs/441284, please. 
[17:28] <brobostigon> bryce: shall i add a screenshot aswell?
[17:29] <bryce> brobostigon, yes
[17:29] <brobostigon> bryce: ok, i will try as best quality as i can.
[17:30] <bryce> brobostigon, since I'm pretty tied up with release stuff, I am not planning on looking at -siliconmotion bugs before release.  However, if you take the bug upstream, and they provide a patch that fixes it, I can consider including it
[17:30] <bryce> time is short though... we only got effectively a week
[17:30] <brobostigon> bryce: ok, i will do that.
[17:34] <brobostigon> bryce: thank you for your help.
[17:43] <mac_v> bryce: mesa7.6 causes crashes for me :( > Bug 436546
[17:43] <tjaalton> bryce: looks like bug 446425 is related to mesa
[17:44] <tjaalton> mac_v: that's older than the upload last night
[17:44] <mac_v> tjaalton: still crashes :/
[17:44] <mac_v> nothing has changed
[17:44] <tjaalton> but it's not a regression due to the upload, there's a difference :)
[17:45] <mac_v> oh ;)
[17:46] <tjaalton> bryce: should I upload the libdrm merge to main? built fine on my ppa
[17:46] <bryce> hrm, lp is not letting me edit descriptions
[17:47] <bryce> tjaalton, go for it
[17:47] <tjaalton> bryce: great thanks
[17:47] <bryce> btw I uploaded -intel about 30 min ago
[17:47] <tjaalton> 2.9.0?
[17:49] <bryce> yes
[17:49] <tjaalton> ok, more reason to upload libdrm then :)
[17:50] <tjaalton> aiui it build-depends on 2.4.14
[17:51] <bryce>  libdrm-dev (>= 2.4.11),
[17:51] <bryce> should be ok; but might be worth rebuilding after libdrm goes in anyway
[17:51] <tjaalton> ah
[17:51] <tjaalton> ok
[17:53] <tjaalton> uploaded
[17:57] <tjaalton> gone again -> :)
[18:00] <brobostigon> bryce: ok, i have added a screenshot to my bug, you mean take it upstream as in to xorgs own bug tracker?
[18:09] <jbarnes> why does my rhythmbox icon have a black rectangle around it
[18:09] <jbarnes> in the notification area
[18:09] <jbarnes> it used to have little sound waves coming out while playing
[18:10] <rickspencer3> ok, if jbarnes is discussing icons this close to release, this give me lots of confidence in the xorg stack for karmic
[18:10] <rickspencer3> ;)
[18:11] <rickspencer3> jbarnes, atm, my doesn't have a rectangle, it has little blue waves
[18:11]  * rickspencer3 is glad to be talking about icons rather than xorg crashers :)
[18:14] <jbarnes> rickspencer3: heh
[18:14] <jbarnes> this is actually on jaunty
[18:14] <rickspencer3> oh?
[18:14] <jbarnes> at some point I just started getting a black rectangle
[18:14] <jbarnes> looks funky
[18:14] <rickspencer3> ok, Jaunty is dead to me :)
[18:14] <rickspencer3> that is weird
[18:15] <rickspencer3> jbarnes, for reals, xorg seems quite improved in Karmic compared to Jaunty, thanks for your ongoing engagement in that
[18:15] <jbarnes> http://www.virtuousgeek.org/Screenshot.png
[18:15] <jbarnes> rickspencer3: yeah we've stabilized things a lot
[18:35] <Duke`> okay, latest libdrm in xorg-edgers PPA totally breaks my Xorg :( it seems the intel driver go in an infinite loop, because it never go further than "(II) intel(0): Attempting memory allocation with tiled buffers."
[18:35] <Duke`> I had to revert to the previous versions (from october 4th, Sarvatt's packages)
[19:18] <bryce> rickspencer3, http://www.phoronix.com/scan.php?page=article&item=ubuntu_karmic_mesa&num=1
[19:19] <rickspencer3> bryce, what's the top line report?
[19:19] <bryce> rickspencer3, lookin' good
[19:19] <rickspencer3> great
[19:19] <rickspencer3> and did I see -intel went out?
[19:22] <bryce> yes, just sent it this morning after pitti thumbs-upped it
[19:23] <rickspencer3> sweet
[19:24] <rickspencer3> was there one more major change coming
[19:24] <rickspencer3> ?
[19:24] <bryce> rickspencer3, I've also done a scouring through Xorg for any regressions for mesa.  I did find one bug report that might be caused by it, on an old radeon R250 chip when running Kubuntu.  Bug 446425.  I've forwarded it upstream.  
[19:25] <bryce> rickspencer3, it is a minor corruption issue, but worth getting fixed at some point
[19:26] <bryce> rickspencer3, yes the one remaining bit is xorg-server; I'm going to work on that package today.  I wanted to catch up on mesa stuff before starting on that.
[19:27] <bryce> rickspencer3, btw that 100% X CPU bug has turned out to actually be not an X bug
[19:27] <rickspencer3> right
[19:27] <bryce> rickspencer3, it seems some crypto service was stealing vt7 and breaking X.  pitti is following up on it
[19:39] <rickspencer3> bryce, should it be assigned to pitti?
[19:48] <Amaranth> I've got someone who may have a regression caused by mesa
[19:49]  * rickspencer3 cries
[19:49] <rickspencer3> :)
[19:49] <rickspencer3> Amaranth, is there a bug #?
[19:49] <Amaranth> Getting them to file one now
[19:49] <Amaranth> Until about an hour ago everything worked great but now X crashes when they open firefox...
[19:49] <Amaranth> Radeon X300
[19:50] <rickspencer3> ug
[19:50] <rickspencer3> that sounds quite ugly
[19:51] <Amaranth> Considering they just quit IRC when I asked to try with compiz turned off I'm thinking that didn't fix it
[19:51] <Amaranth> Is mesa used for cairo? :)
[19:52] <rickspencer3> :(
[20:05] <jcristau> Amaranth: no
[20:05] <Amaranth> jcristau: I know, was joking
[20:06] <Amaranth> They never came back either
[20:13] <bryce> the mesa 7.6 changelog indicates a good bit of change for R300 class hardware, so indeed it could have resulted in a bug on X300.  I'd like to see that bug report if it comes in.
[20:16] <bryce> hmm, another kubuntu/kwin bug - 446578
[20:16] <rickspencer3eee> bryce: did you see Amaranth's?
[20:17] <Amaranth> ?
[20:17] <rickspencer3eee> Amaranth: I was offline for a few minutes
[20:17] <rickspencer3eee> you mentioned a user with a radeon card that might be experiencing a regression
[20:17] <bryce> rickspencer3eee, I saw his comment but don't know if a bug got filed on it yet
 the mesa 7.6 changelog indicates a good bit of change for R300 class hardware, so indeed it could have resulted in a bug on X300.  I'd like to see that bug report if it comes in.
[20:18] <Amaranth> I don't think one did
[20:18] <Amaranth> The user never came back
[20:18] <rickspencer3eee> ?oh
[20:19] <bryce> if he does, point him my way
[20:19] <bryce> rickspencer3eee, 446578 is the first report that I think is going to score as "serious" for us
[20:21] <bryce> rickspencer3eee, note that both the regressions reported so far are against kwin/kubuntu
[20:21] <rickspencer3eee> yup
[20:21] <rickspencer3eee> and radeon?
[20:21] <bryce> right
[20:23] <Amaranth> bryce: That reminds me, fun bug
[20:24] <Amaranth> bryce: It seems that even thought glxinfo -l says GL_MAX_TEXTURE_SIZE is 2048 for ati users it is 1024
[20:24] <Amaranth> Unless you use KMS
[20:25]  * Amaranth tries to find the bug
[20:26] <Amaranth> bryce: bug 444139
[20:28] <bryce> Amaranth, ah yes iirc there was a similar issue on intel a while back
[20:29] <bryce> Amaranth, that's probably a driver issue.  However I don't know if I want to fiddle those settings this late
[20:29] <bryce> Amaranth, possibly there's already a patch upstream - it'd be in the xf86-video-ati git tree if it exists
[20:29] <Amaranth> There is no way for us to properly detect this either
[20:31] <Amaranth> nothing jumps out at me
[20:31] <bryce> yeah me either
[20:32] <bryce> I'll forward the bug upstream
[20:40] <bryce> rickspencer3eee, btw I've alerted -ati upstream that they may be getting some priority radeon bug reports from us due to mesa 7.6
 bryce: sounds good
[20:40] <rickspencer3eee> bryce: do you think they are addressable in this tight time frame?
[20:41] <bryce> rickspencer3eee, quite possibly
[20:41] <rickspencer3eee> I don't want to get wrapped up in an endless chasing of tails, but ...
[20:41] <rickspencer3eee> I also don't want to give up too early
[20:41] <bryce> rickspencer3eee, they may already have patches for the bugs since we're trailing a bit behind their git head
[20:41] <rickspencer3eee> bryce: right
[20:41] <rickspencer3eee> the point I tried to make in the rollback criteria is that we should fear *undiagnosable* issues
[20:42] <bryce> yeah I let them know we have a small window of opportunity, and the qa team will be making their determination for go/no-go
[20:42] <bryce> ahh
[20:42] <rickspencer3eee> yeah, so maybe this isn't hard to diagnose
[20:42] <rickspencer3eee> in which case, we shouldn't turn off progress
[20:43] <rickspencer3eee> also, it seems a bit isolated ... only one scenario seems to be causing issues atm
[20:43] <bryce> mostly I want to ensure upstream recognizes them as priorities.  Sometimes -ati ignores upstreamed bug reports if they're not pertinent, but they're good if I flag them as priorities to us
[20:43] <rickspencer3eee> yeah
[20:46] <rickspencer3eee> bryce: seems that -intel is having no issues as of yet?
[20:46] <bryce> none reported so far
[20:46] <bryce> and a number of positive reports
[20:46] <rickspencer3eee> great
[20:47]  * rickspencer3eee crosses finders wrt radeon bug
[20:51]  * Amaranth still gets no backlight control with intel 2.9 :/
[20:52] <Amaranth> That part relies on kernel changes, doesn't it?
[20:52] <bryce> yes
[20:53] <Amaranth> apt-get source linux-image-generic-2.6.30-12 here I come
[20:53] <Amaranth> err, except the real version with the real naming scheme :P
[20:54] <bryce> Amaranth, yeah with -intel so much of the code now lives in the kernel that the ddx driver updates are not nearly as significant as they used to be
[20:55] <Amaranth> I'm using xorg-edgers but I can't boot with nomodeset anymore, btw
[20:55] <bryce> mm, perhaps upstream has begun the excising of UMS
[20:56] <jcristau> "begun"
[20:56] <jcristau> http://cgit.freedesktop.org/xorg/driver/xf86-video-intel/commit/?id=b9b159c49854d8d9d2207946bb583537bb0d48d6
[20:56] <Amaranth> I get this awesome strobe light effect as X apparently tries to start about 30 times a second :P
[20:56] <Amaranth> Can't even login on tty1
[20:56] <jcristau> 56 files changed, 120 insertions, 17939 deletions
[20:57] <bryce> jcristau, jesus
[20:57] <jcristau> (and that's not even all of it)
[20:57] <bryce> so yeah
[20:57] <Amaranth> So at this point the intel driver only works on linux?
[20:57] <bryce> Amaranth, guessing -intel git will be a bit rocky for a bit
[20:57] <jcristau> Amaranth: yes
[20:58] <jcristau> but it was already unusable for a few releases now without gem
[20:58] <Amaranth> so now I _really_ need to see if I get backlight support with a kernel change
[20:58] <Amaranth> Where would I find the patches/git for that?
[20:59] <bryce> the kernel team has a crack of the day repo with upstream snapshots of the kernel
[21:03] <bryce> heya tormod
[21:03] <tormod> hi bryce
[21:03] <tormod> seems we had a mid-air collision in an interesting bug report
[21:03] <ScottK> At least reboots are fast with a new kernel seems like every day.
[21:05] <bryce> tormod, yep
[21:06] <tormod> bryce, are you gonna push the new mesa to git
[21:06] <bryce> tormod, no, go ahead if you'd like
[21:06] <Amaranth> time to try out 2.6.32-rc3
[21:07] <bryce> embarrassingly, I don't know how to do the fdo/debian/ubuntu new release merge trickery
[21:07] <tormod> bryce, I don't think I can, I am only member of collab-maint
[21:10] <jcristau> tormod: that's fixable.
[21:11] <tormod> jcristau, what's my next excuse gonna be then? :)
[21:14] <Amaranth> no luck, still no backlight property
[21:15] <Amaranth> time for ppa-purge, I guess
[21:16] <tormod> Amaranth, using radeonhd?
[21:16] <Amaranth> intel
[21:17] <Amaranth> MacBook4,1
[21:22] <tormod> jcristau, I have dreamt of having xorg-edgers branches on g.d.o, would that be possible?
[21:23] <jcristau> probably
[21:25] <tormod> in the best case, you could pick from them into experimental :)
[21:25] <Amaranth> there, much better, nomodeset ftw :)
[21:26] <ScottK> bryce: I confirmed Bug #432521 is still a problem after today's updates.  Do you have an opinion about the proposed patch in the bug?
[21:26] <bryce> Amaranth, does https://bugs.edge.launchpad.net/ubuntu/+bug/417770 sound relevant for you?
[21:27] <jcristau> ScottK: does TerminateServer=true in the kdm config work around the issue?
[21:27] <Amaranth> bryce: yep, that's the one
[21:28] <ScottK> jcristau: I didn't retry that after today's updates, but it did before.
[21:28] <ScottK> I don't know what the side effects of that are.
[21:28] <Amaranth> bryce: oh, wait, maybe not
[21:29] <Amaranth> FATAL: Error inserting mbp_nvidia_bl (/lib/modules/2.6.32-020632rc3-generic/kernel/drivers/video/backlight/mbp_nvidia_bl.ko): No such device
[21:29] <Amaranth> Nope, not going to help me :/
[21:30] <bryce> ScottK, I'd want to see the patch accepted upstream before we pull it into karmic.  The way that patch is written, it adds new behavior for all Intel video cards, so regression risk is a touch high for this stage in the release
[21:32] <ScottK> bryce: OK.  This is a significant issue for Kubuntu, so I'd appreciate it if you could discuss it with upstream then.
[21:33] <jcristau> ScottK: i'd say TerminateServer is the best workaround.  it makes it behave as gdm, and shouldn't have any downsides
[21:33] <jcristau> assuming it still works
[21:35] <ScottK> jcristau: The problem is we don't have a good way to enforce that on upgrades.
[21:37] <ScottK> If we can avoid having a release note that requires everyone to manually edit config files as root, I'd really prefer it.
[21:38] <bryce> ScottK, at the moment I'm focusing on regressions for these recent uploads.  It would be great if you have a kubuntu guy that would address that patch with upstream.
[21:38] <jcristau> the default can't be changed inside kdm, it's necessarily in the config file?
[21:38] <jcristau> sadness.
[21:39] <ScottK> Well if I was going to patch KDM, I'd have the same problem with wanting upstream buy in.  KDM code is notoriously fiddly.
[21:39] <ScottK> bryce: This is a regression.
[21:45] <bryce> ScottK, other regressions are more of a priority for me at the moment
[21:45] <ScottK> OK
[21:47] <bryce> (all of which are affecting kubuntu/kwin users... it would be great if the kubuntu team had an xorg specialist that could work with us on these kinds of kde-specific xorg bugs, since I no longer really test kubuntu stuff myself anymore)
[21:50] <ScottK> It'd be great if we had a number of resources we don't in the Kubuntu team.
[22:11] <bryce> heh, there got to be so many comments on bug 359392 that launchpad times out before it can display them
[22:22] <tormod> now we will be DOS'ing lp by clicking on that link to see what it is about :)
[22:31] <bryce> tormod, that's that old X freeze bug from jaunty
[22:31] <bryce> I was curious what's going on with it these days but guess I'll never know
[22:33] <tormod> bryce, maybe you can look it up at staging.lp.net
[22:33] <tormod> bryce, or use launchpadlib :)
[22:34] <bryce> I was just idly curious since I would like to recycle the ppas I set up for it to use for these kwin bugs.  But I just made a new ppa instead.
[22:35] <tormod> will you try reverting suokko's commit in question?
[22:35] <bryce> (https://edge.launchpad.net/~bryceharrington/+archive/black)
[22:35] <bryce> tormod, exactly
[22:38] <tormod> bryce, trick: run debian/rules patch and unpatch before uploading ;)
[22:40] <tormod> bryce, I was actually thinking of fdo 24131, another of suokko's commits. a pity he's not on #radeon now
[22:47] <bryce> aw rats
[22:47] <bryce> is there a lp bug corresponding to fdo 24131?
[22:48] <tormod> yes, you were just commenting on it earlier
[22:49] <tormod> there KMS works fine
[22:51] <ScottK> bryce: Do you have a list of the kwin bugs you're looking at?
[22:59] <tormod> what is kwin doing that compiz etc is not?
[23:01] <ScottK> Working with KDE
[23:02] <tormod> ScottK, I mean, opengl-wise
[23:02] <ScottK> No idea.
[23:02] <ScottK> I know it approaches some things differently, but not the details.
[23:03] <ScottK> I recall we had a patch in Intrepid that helped Compiz be faster and did very bad things to Kwin.
[23:03]  * ScottK is not a video expert at all.
[23:09] <bryce> tormod, ok fixed the patch in the ppa.  I forgot to actually invert it
[23:10] <tormod> :) I wondered about that when I saw the patch header
[23:35] <Amaranth> ScottK: That would be the no backfill patch, iirc
[23:35] <Amaranth> It made GNOME faster and KDE full of garbage
[23:35] <ScottK> Amaranth: Yeah.  That's the one.
[23:35] <Amaranth> Too bad without it fglrx users get a terrible experience
[23:36] <Amaranth> maybe with Qt 4.6 we can put it back in? :)
[23:36] <ScottK> Well sort it out with upstream then, don't just use distro specific hacks that break other things.
[23:36] <ScottK> No idea.
[23:36] <ScottK> I think it should get sorted out upstream.
[23:36] <Amaranth> The hack comes from ajax
[23:36] <Amaranth> There is no proper upstream fix possible
[23:36] <ScottK> Not saying it's a bad hack, just that it is.
[23:37] <ScottK> Then we shouldn't rely on it.
[23:37] <Amaranth> Well once Qt joins the modern world and uses _NET_WM_SYNC_REQUEST it doesn't hurt anymore ;)
[23:42] <bryce> ScottK, bugs 410711 and 446578 are the recent regressions I'm focusing on
[23:45] <ScottK> Thanks.
[23:45] <Amaranth> bryce: that second one looks similar to the X300 user I was talking to earlier
[23:45] <Amaranth> But compiz instead of kwin
[23:52] <bryce> hmm whoops.  I mispasted
[23:52] <bryce> ScottK, the two bugs are 446578 and 446425
[23:53] <ScottK> Thanks
[23:58] <ScottK> bryce: Thanks.  I agree those are more important.