[00:00] night tjaalton [00:20] bryce: who is "we"? [00:20] pwnguin: ubuntu-x team [00:22] if anyone is interested in taking charge of caring for -nouveau bugs, we can change that [00:23] im already subscribed to them, but im not sure what it'd take to "care for" them [00:23] 'care for' == triage and forward upstream as appropriate [00:24] triage normally means designate an importance [00:25] yep [00:25] if the x team isn't touching the package for jaunty I'm not sure why an imporatnce should be set [00:26] man. can you believe that was my second try at importance? [00:27] heh [00:27] anyways, if there's going to be a time where nouveau DOES garner X Team attention, it might be helpful to have a bug corpus [00:28] well, in bug tracker context, triage generally is taken to mean "make sure the report has sufficient information included" as well [00:28] but this really depends on nouveau upstream being ready to work on such stuff [00:29] perhaps, but presumably many of these bugs will be fixed upstream between now and whenever we switch it to supported, so having a bunch of old, likely-fixed bugs will detract from issues reported against the version uploaded [00:29] correct; last I checked they still were not accepting bug reports [00:30] partly the reason to close bugs for now is to set expectations [00:31] I don't want users feeling they can file -nouveau bugs against LP and trust us to take care of them, when we won't. Better to close them and get the users to go upstream with them. [00:31] we've got a somewhat similar problem with -radeonhd [00:33] guess I should close those out as well [00:33] (actually they may be xserver issues...) [00:35] nouveau seems to have a bug tracker [00:35] mainly for 2d [00:51] tjaalton, i thought it was decided at uds to switch gdm to vt1 already? [00:51] or am i just imagining things... [05:55] [ANNOUNCE] xorg-server 1.5.99.902 [06:49] superm1: it wasn't that widely discussed, and it doesn't need changes in any X packages other than maybe xdm, so maybe the desktop team should make the decision, not us [06:49] hmm, so the xserver did do something wrong when the xrandr sluggishness occurred [06:50] randr: Avoid re-querying the configuration on everything but [06:50] GetScreenResources. [07:04] yeah saw that [07:04] tjaalton, we should definitely pull that in for the xserver [07:05] also, I forgot to pull the client limit patch today [07:09] they need more work [07:10] since the ones were for 1024 clients, but we should probably settle for 512 [07:10] and they were for the server and proto [07:10] IIRC [07:12] I'll push server rc2 and mesa 7.3 shortly [07:25] ok [07:28] hmm the maxclients is defined only in the server nowadays [07:28] so no need to touch coreproto [07:28] since XPoll.h is gone [07:30] hmm not quite [07:39] bryce: I was wrong, the patches are ok as-is, just s/1024/512/ [07:40] sweet [07:41] ok I'm heading to bed, and then up early for a 6am flight to berlin, so I probably won't be online 'til monday [07:41] cya tjaalton [07:41] ok, bye [12:52] tjaalton, perhaps it's worthwhile to put a call for feedback to ubuntu-devel for getting more people to test it then and look for side effects? I mean it's going to happen eventually anyway (when KMS hits), so the sooner you know about the side effects of say the other drivers (NV and AMD), the more time you'll have to get those things reported and fixed at least [12:53] maybe a few line description of how to change your server to run on VT1 [12:54] superm1: it shouldn't matter what driver is used, but maybe it should be discussed openly right from the start :) [12:56] and KMS doesn't dictate which VT to use, but it'll reduce flicker to run X on VT1 === ogra_ is now known as ogra [16:45] tjaalton, superm1: I sent this file with the new drivers to pitti (so that he can upload them ASAP). In the meantime, if you want to play with the new drivers: http://albertomilone.com/ubuntu/newlrm/pitti/jaunty/driver_jaunty.txt