/srv/irclogs.ubuntu.com/2009/09/30/#ubuntu-x.txt

brycehm, ok rick says no further X updates except cherrypicking00:12
tormodI could not find any desktop meeting in #ubuntu-meeting logs?00:17
albert23tormod: http://irclogs.ubuntu.com/2009/09/29/%23ubuntu-desktop.html starting at 17:4200:18
tormodalbert23, thanks00:19
brycetormod, they're usually held on #ubuntu-desktop00:19
tormodwhat is the x-testers PPA 00:23
tormodhm 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:24
tormodI wonder if tseliot knows about xorg-edgers and x-updates PPA?00:25
bryceI don't think there is an x-testers ppa..00:26
brycehe should know about xorg-edgers.  dunno if he knows he should be pushing stuff to it00:27
brycehrm, I kind of wish we were a bit more caught up with all this stuff... guess its my bad for being offline the past month00:27
tormodIt 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 leave00:29
tormod<tseliot>and this is why I think they should live in a PPA at first00:32
tormod<pitti>tseliot: are these in the x-testers PPA? I'd love to try them and see whether they fix suspend/resume00:32
bryceah, yeah he must mean xorg-edgers00:32
tormod<tseliot>pitti: not yet, sorry, I think I'll work on it (I've been busy with oem stuff)00:32
tormodI feel we are a bit disconnected here00:33
tormod(my remark, not a quote that last one)00:34
bryceI sense I'm going to have a lot of patch porting work in my near future00:35
tormodfor commit in $(git log); do cherry-pick $commit; done :)00:35
tormodI think I will leave the bug triaging and debugging to the Desktop team :)00:37
seb128weird comment00:48
bryceI 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 alone00:57
bryceI suspect he may be right, although I've not really investigated00:57
brycebut 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 instead00:58
seb128well, we did pull a new version to fix issues previous cycle01:00
seb128and we got jaunty without compiz on some intel card to workaround the issues we didn't manage to track01:00
seb128so we are rather careful about updates this time01:01
bryceseb128, actually no, in Jaunty we opted *not* to pull new versions to fix the issues01:04
seb128ok01:04
bryceseb128, 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 cherrypicking01:04
seb128in any case non trivial updates are always risky01:04
seb128I though the locking issues on intel did start after some update01:04
seb128but it has been a while ;-)01:05
seb128in any case I'm not the one who decided01:05
bryceit was ironic all the fixes we needed for Jaunty were released (mostly in kernel code)01:05
brycewe just didn't have time to cherrypick everything we needed01:05
bryceseb128, 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
seb128anyway let's not discuss jaunty now01:06
seb128dunno if you read the meeting log01:06
seb128but there was no strong argument in favor of doing the non trivial update01:07
seb128and people felt it's late in the cycle to try that many changes01:07
seb128but whoever has good argument can probably argue with pitti and rick01:07
bryceseb128, I did look at the meeting log; it didn't appear that anyone had any tangible concerns, just generic worry01:09
bryce"fix all the bugs, and btw please don't change anything while you do it."  ;-)01:10
seb128bryce, no, it was rather "do we have a good reason to throw that many changes in now"01:11
seb128bryce, and "do we feel we can test that properly and act if things break before karmic"01:11
seb128and there was no real reply to the first question01:11
bryceseb128, 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:15
bryceseb128, anyway it'll be embarrassing to release without this stuff in, but really it's my fault for having taken time off01:16
seb128you can't say it's your fault, it's rather the team fault to not have taken on your tasks while you were on leave01:17
seb128but argue with rick or pitti if you think we should really do the update01:17
seb128the rational was that after beta is late for that number of change01:17
seb128and that cherrypicking might be less risky01:18
seb128we are sort of sitting between a rock and an hard place now01:18
seb128anyway I'm not really the guy to talk with about those01:20
seb128I was just relying the meeting conversation01:20
seb128it's probably a good idea to talk to pitti tomorrow01:20
tjaaltonbryce: the intel "2009Q3" release consists of all these new releases, so yes, I'm in favour of updating to the current stable stack06:17
tjaaltonand I've been slacking with wacom.. should've uploaded it last week06:17
tjaaltonbut, stuff..06:17
bryceyeah, me too06:17
brycebut however I think we're now too late to update X components any further06:19
bryceit appears the desktop team semi-firmly decided not to allow updates06:19
tjaaltonhrm06:20
tjaaltonooh, "xf86-input-wacom now available"06:21
tjaaltonbut surelyn not for karmic :)06:22
tjaalton-n06:22
brycehey btw at XDC they got a consensus around merging the DDX drivers back into the xserver codebase06:22
tjaaltonhaha :)06:22
bryceso if you were worried things were going to get boring for us X packagers, none to worry!06:22
tjaaltonyeah the notes suggested so06:23
tjaaltonwell, it should make things somewhat simpler too, I hope06:23
tjaaltonat least the amount upstream regressions should go down06:23
bryceof course so much has moved into the kernel now06:24
tjaaltonyep06:24
brycebtw, how'd your rowing team do?06:25
tjaaltonhehe06:25
tjaaltonthere were ~115 teams, and we finished as 103rd or so :)06:25
bryce!!06:25
brycewell, hey you finished, that's way better than most of us could do!06:26
tjaaltonbut it took 30min less than the last time (6h15min)06:26
pwnguinthats a long row06:26
tjaaltonyep, 58km06:26
tjaaltonhttp://www.sulkavanvene.fi/kuvat/sulkavansoutu1.jpg06:27
brycewow06:27
tjaaltonso the hardest thing was to stay in sync06:28
brycebet it takes a lot of practice06:28
tjaaltonand holding a steady pace06:28
pwnguinbet it takes a lot more willpower06:28
tjaaltonyeah, once in every second year doesn't quite cut it :)06:28
tjaaltonafter we finished no-one was willing to go next year, but when got to the sauna & barbeque -phase opinions had changed ;)06:29
pwnguinif you're tired im guessing the guy behind you might not be and still wants to win06:29
tjaaltonwe took short breaks a pair at a time (there were seven pairs and the cap'n)06:32
tjaaltonhttp://www.vastavalo.fi/albums/userpics/11563/DSCN0116p.jpg06:33
tjaaltonthat's a better picture06:33
tjaaltonbut yeah, a sore butt and hands full of blisters cannot be avoided ;)06:34
bryceah no gloves?06:36
tjaaltonand tape, but still06:36
bryceah heh looks like there was no guy behind timo!06:36
tjaaltonhaha06:37
tjaaltonthat's not from our team, just some pic I found06:37
tjaalton(they were mostly ladies anyway.. sometimes I felt the same about our team though=06:37
brycethe boats do sort of resemble viking longboats06:43
tjaaltonyeah06:43
tjaaltonwe call them "church boats"06:43
tjaaltonbecause families used to go to the church etc with similar boats06:44
brycecan they go in the open oceans or just fjords?06:44
pwnguinanything can go in the oceans, its a matter of what comes back06:45
tjaaltonheh06:45
brycelol\06:45
pwnguini doubt you could row your way back against an ocean current06:46
tjaaltonin lakes only (we don't have fjords :). there were some annoying spectators going round us on muscleboats, and the waves weren't nice to handle06:46
tjaaltonbecause some rows would not reach the water so the pace broke06:47
brycetjaalton, 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 xserver06:55
tjaaltonbryce: 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
tjaaltonrc3 is in experimental06:58
brycewell, 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.706:59
tjaaltonalso it seems like rhel6 will ship it06:59
tjaaltonbut, maybe wait a month and think about it when lucid opens?-)07:00
brycecouldn't hurt07:00
tjaaltonhas there been any talk about 1.8 release schedule?07:03
bryceyes there was07:03
tjaaltonfd.o is still down, so no notes available07:04
brycethe discussion was to go to more of a routine, regular release schedule, tied to the GNOME development cycle07:04
tjaaltonnice07:04
tjaaltonbut07:04
bryceso every 6 months, shortly prior to GNOME's releases07:04
tjaaltonit's usually too late for our cycle?07:04
bryceyes, that's something I'm a little concerned about07:04
brycebut I don't know that we have a whole lot of pull ;-)07:05
tjaaltonunless the release management is improved like whot suggested07:05
bryceright that also got a lot of talk07:05
tjaaltonmeaning less regressions07:05
tjaaltonless chance of..07:05
brycethere was rough consensus around changing things like whot's suggestions, and go with a stricter control over main in a more Linus-like fashion07:06
pwnguinprobably, you want to give them some practice at this regular release thing before trusting them on it ;)07:06
brycewhere in this case Keith (or Peter) would be the Linus07:06
brycepwnguin, indeed07:06
pwnguinwhen did gnome start doing regular releases? 2003?07:07
brycedunno07:07
tjaaltonwhen 2.0 was released, I guess07:07
pwnguinso way earlier07:07
pwnguinbefore ubuntu, lets say07:07
tjaaltonactually no, 2.0 was june 2002, 2.2 was feb 200307:08
tjaaltonso after that07:08
brycethis 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 tomorrow07:09
tjaaltonoh, congrats!07:09
brycehttp://outflux.net/~bryce/arr_baby.jpg07:10
tjaaltonmaybe I shouldn't be telling this, but our baby has been a good sleeper so far ;)07:10
tjaaltonyarr!07:10
Ngbryce: 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:56
Ngbut 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 :)08:57
jcristauNg: i'm not sure why redhat should have to care about ubuntu tbh.09:39
Ngjcristau: that depends how honest they are about being upstream :)09:39
Ngif you're genuinely an upstream you care about your users09:39
Ngif you're not then that's fine :)09:39
tjaaltonwe'll see what happens with rhel610:04
mnemobryce: I attached dmesg, xorglog to bug 438657 (so maybe you'd want to change it from INCOMPLETE and remove  needs-lspci-vvnn  needs-xorglog18:31
mnemo) https://bugs.launchpad.net/ubuntu/+source/mesa/+bug/43865718:31
ubottuLaunchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed] https://launchpad.net/bugs/43865718:31
ubottuLaunchpad bug 438657 in mesa "[G45] Blender: crash in brw_prepare_vertices after "Render this window"" [Unknown,Confirmed]18:31
virtualdive 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]=0x0000194E22:10
virtuald[drm] ib[25]=0x82B5021522:10
virtualdalways [drm] ib[24]=0x0000194E22:11
virtualdand always No reloc for ib[25]=0x653822:12
virtualdthe other [drm] ib[25] changes but not every time22:13
bryyycevirtuald, 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:01
virtualdok23:02

Generated by irclog2html.py 2.7 by Marius Gedminas - find it at mg.pov.lt!