[00:12] hm, ok rick says no further X updates except cherrypicking [00:17] I could not find any desktop meeting in #ubuntu-meeting logs? [00:18] tormod: http://irclogs.ubuntu.com/2009/09/29/%23ubuntu-desktop.html starting at 17:42 [00:19] albert23, thanks [00:19] tormod, they're usually held on #ubuntu-desktop [00:23] what is the x-testers PPA [00:24] hm I would have been interested in hanging around at that meeting. I though the Desktop team were fixing gnome bugs, not deciding the X stuff :) [00:25] I wonder if tseliot knows about xorg-edgers and x-updates PPA? [00:26] I don't think there is an x-testers ppa.. [00:27] he should know about xorg-edgers. dunno if he knows he should be pushing stuff to it [00:27] hrm, I kind of wish we were a bit more caught up with all this stuff... guess its my bad for being offline the past month [00:29] It seems like none of the people in that meeting is on the ubuntu-x ML for instance, that is a structural problem and not your fault for having a leave [00:32] and this is why I think they should live in a PPA at first [00:32] tseliot: are these in the x-testers PPA? I'd love to try them and see whether they fix suspend/resume [00:32] ah, yeah he must mean xorg-edgers [00:32] pitti: not yet, sorry, I think I'll work on it (I've been busy with oem stuff) [00:33] I feel we are a bit disconnected here [00:34] (my remark, not a quote that last one) [00:35] I sense I'm going to have a lot of patch porting work in my near future [00:35] for commit in $(git log); do cherry-pick $commit; done :) [00:37] I think I will leave the bug triaging and debugging to the Desktop team :) [00:48] weird comment [00:57] I think he just means the amount of work required to backport and test all the patches needed is well beyond what the X team can do alone [00:57] I suspect he may be right, although I've not really investigated [00:58] but yeah, I had been anticipating that we'd pull all these fixes as updates, so I could spend the last couple weeks working on xserver crashers instead [01:00] well, we did pull a new version to fix issues previous cycle [01:00] and we got jaunty without compiz on some intel card to workaround the issues we didn't manage to track [01:01] so we are rather careful about updates this time [01:04] seb128, actually no, in Jaunty we opted *not* to pull new versions to fix the issues [01:04] ok [01:04] seb128, perhaps you don't recall, but we opted to stay with the -intel 2.5 instead of 2.6 which was released, and instead I spent much time doing cherrypicking [01:04] in any case non trivial updates are always risky [01:04] I though the locking issues on intel did start after some update [01:05] but it has been a while ;-) [01:05] in any case I'm not the one who decided [01:05] it was ironic all the fixes we needed for Jaunty were released (mostly in kernel code) [01:05] we just didn't have time to cherrypick everything we needed [01:06] seb128, the locking issues first started being reported at UDS berlin, very early on. Just most people didn't notice them right away because they hadn't upgraded yet. [01:06] anyway let's not discuss jaunty now [01:06] dunno if you read the meeting log [01:07] but there was no strong argument in favor of doing the non trivial update [01:07] and people felt it's late in the cycle to try that many changes [01:07] but whoever has good argument can probably argue with pitti and rick [01:09] seb128, I did look at the meeting log; it didn't appear that anyone had any tangible concerns, just generic worry [01:10] "fix all the bugs, and btw please don't change anything while you do it." ;-) [01:11] bryce, no, it was rather "do we have a good reason to throw that many changes in now" [01:11] bryce, and "do we feel we can test that properly and act if things break before karmic" [01:11] and there was no real reply to the first question [01:15] seb128, the replies I see are, a) "Fixes bunch of regressions on 8xx", b) "fixes backlight breakage", c) "FFe's have been filed and approved" [01:16] seb128, anyway it'll be embarrassing to release without this stuff in, but really it's my fault for having taken time off [01:17] you can't say it's your fault, it's rather the team fault to not have taken on your tasks while you were on leave [01:17] but argue with rick or pitti if you think we should really do the update [01:17] the rational was that after beta is late for that number of change [01:18] and that cherrypicking might be less risky [01:18] we are sort of sitting between a rock and an hard place now [01:20] anyway I'm not really the guy to talk with about those [01:20] I was just relying the meeting conversation [01:20] it's probably a good idea to talk to pitti tomorrow [06:17] bryce: the intel "2009Q3" release consists of all these new releases, so yes, I'm in favour of updating to the current stable stack [06:17] and I've been slacking with wacom.. should've uploaded it last week [06:17] but, stuff.. [06:17] yeah, me too [06:19] but however I think we're now too late to update X components any further [06:19] it appears the desktop team semi-firmly decided not to allow updates [06:20] hrm [06:21] ooh, "xf86-input-wacom now available" [06:22] but surelyn not for karmic :) [06:22] -n [06:22] hey btw at XDC they got a consensus around merging the DDX drivers back into the xserver codebase [06:22] haha :) [06:22] so if you were worried things were going to get boring for us X packagers, none to worry! [06:23] yeah the notes suggested so [06:23] well, it should make things somewhat simpler too, I hope [06:23] at least the amount upstream regressions should go down [06:24] of course so much has moved into the kernel now [06:24] yep [06:25] btw, how'd your rowing team do? [06:25] hehe [06:25] there were ~115 teams, and we finished as 103rd or so :) [06:25] !! [06:26] well, hey you finished, that's way better than most of us could do! [06:26] but it took 30min less than the last time (6h15min) [06:26] thats a long row [06:26] yep, 58km [06:27] http://www.sulkavanvene.fi/kuvat/sulkavansoutu1.jpg [06:27] wow [06:28] so the hardest thing was to stay in sync [06:28] bet it takes a lot of practice [06:28] and holding a steady pace [06:28] bet it takes a lot more willpower [06:28] yeah, once in every second year doesn't quite cut it :) [06:29] after we finished no-one was willing to go next year, but when got to the sauna & barbeque -phase opinions had changed ;) [06:29] if you're tired im guessing the guy behind you might not be and still wants to win [06:32] we took short breaks a pair at a time (there were seven pairs and the cap'n) [06:33] http://www.vastavalo.fi/albums/userpics/11563/DSCN0116p.jpg [06:33] that's a better picture [06:34] but yeah, a sore butt and hands full of blisters cannot be avoided ;) [06:36] ah no gloves? [06:36] and tape, but still [06:36] ah heh looks like there was no guy behind timo! [06:37] haha [06:37] that's not from our team, just some pic I found [06:37] (they were mostly ladies anyway.. sometimes I felt the same about our team though= [06:43] the boats do sort of resemble viking longboats [06:43] yeah [06:43] we call them "church boats" [06:44] because families used to go to the church etc with similar boats [06:44] can they go in the open oceans or just fjords? [06:45] anything can go in the oceans, its a matter of what comes back [06:45] heh [06:45] lol\ [06:46] i doubt you could row your way back against an ocean current [06:46] in lakes only (we don't have fjords :). there were some annoying spectators going round us on muscleboats, and the waves weren't nice to handle [06:47] because some rows would not reach the water so the pace broke [06:55] tjaalton, since lucid is going to be an LTS, and since the 1.7 release sounds like it was pretty shaky, and the 1.8 plans outlined at XDC sound a tad ambitious, I'm wondering that it may be wisest for us to stick with a 1.6.x xserver [06:58] bryce: hmm, I think debian squeeze will aim for 1.7, so wouldn't it make sense to follow them and benefit from it? [06:58] rc3 is in experimental [06:59] well, it could be. I've been on the fence on it. My gut says not having MPX in the LTS would be shortsighted. However so far XDC has not been filling me with confidence about 1.7 [06:59] also it seems like rhel6 will ship it [07:00] but, maybe wait a month and think about it when lucid opens?-) [07:00] couldn't hurt [07:03] has there been any talk about 1.8 release schedule? [07:03] yes there was [07:04] fd.o is still down, so no notes available [07:04] the discussion was to go to more of a routine, regular release schedule, tied to the GNOME development cycle [07:04] nice [07:04] but [07:04] so every 6 months, shortly prior to GNOME's releases [07:04] it's usually too late for our cycle? [07:04] yes, that's something I'm a little concerned about [07:05] but I don't know that we have a whole lot of pull ;-) [07:05] unless the release management is improved like whot suggested [07:05] right that also got a lot of talk [07:05] meaning less regressions [07:05] less chance of.. [07:06] there was rough consensus around changing things like whot's suggestions, and go with a stricter control over main in a more Linus-like fashion [07:06] probably, you want to give them some practice at this regular release thing before trusting them on it ;) [07:06] where in this case Keith (or Peter) would be the Linus [07:06] pwnguin, indeed [07:07] when did gnome start doing regular releases? 2003? [07:07] dunno [07:07] when 2.0 was released, I guess [07:07] so way earlier [07:07] before ubuntu, lets say [07:08] actually no, 2.0 was june 2002, 2.2 was feb 2003 [07:08] so after that [07:09] this was all stuff discussed on XDC day 1; I didn't actually go in today... baby kept us up too much last night and I needed to spell my wife for the day. but I'll be going back tomorrow [07:09] oh, congrats! [07:10] http://outflux.net/~bryce/arr_baby.jpg [07:10] maybe I shouldn't be telling this, but our baby has been a good sleeper so far ;) [07:10] yarr! [08:56] bryce: we might not have a lot of developer pull, but they might want to remember that if they care about desktops they really need to care about ubuntu ;) [08:57] but even if they release slightly before gnome that means we get an x server release about 2 months before each development cycle starts, so we have over 6 months to stabilise it :) [09:39] Ng: i'm not sure why redhat should have to care about ubuntu tbh. [09:39] jcristau: that depends how honest they are about being upstream :) [09:39] if you're genuinely an upstream you care about your users [09:39] if you're not then that's fine :) [10:04] we'll see what happens with rhel6 [18:31] bryce: I attached dmesg, xorglog to bug 438657 (so maybe you'd want to change it from INCOMPLETE and remove needs-lspci-vvnn needs-xorglog [18:31] ) https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/438657 [18:31] Launchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed] https://launchpad.net/bugs/438657 [18:31] Launchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed] [22:10] ive got a 70 MB syslog with lots of messages like [drm:radeon_cs_ioctl] *ERROR* Invalid command stream ! [drm:r100_cs_packet_parse_vline] *ERROR* unknown crtc reloc [drm:r300_packet0_check] *ERROR* No reloc for ib[25]=0x6538 [drm] ib[24]=0x0000194E [22:10] [drm] ib[25]=0x82B50215 [22:11] always [drm] ib[24]=0x0000194E [22:12] and always No reloc for ib[25]=0x6538 [22:13] the other [drm] ib[25] changes but not every time [23:01] virtuald, those are kernel messages. they can be safely ignored but if they bug you, direct your complaints to #ubuntu-kernel. Not really anything we can do about those from Xorg-space. [23:02] ok