[00:00] <ubotu> New bug: #172456 in xorg (main) "intel driver does not honor CW command" [Undecided,New] https://launchpad.net/bugs/172456
[00:21] <ubotu> New bug: #172435 in xorg (main) "[hardy] login hangs after upgrade to xorg 1.4" [Undecided,Confirmed] https://launchpad.net/bugs/172435
[09:45] <ubotu> New bug: #82925 in xorg (main) "AutoRepeat doesn't work on Thinkpad Back/Forward keys." [Undecided,New] https://launchpad.net/bugs/82925
[15:35] <ubotu> New bug: #172591 in xorg (main) "intel driver does not honor clone screen output" [Undecided,New] https://launchpad.net/bugs/172591
[16:45] <ubotu> New bug: #172601 in xserver-xorg-driver-ati (main) "Dual-head fails with ati driver, appears related to 'crtc'" [Undecided,New] https://launchpad.net/bugs/172601
[17:41] <ubotu> New bug: #172610 in xserver-xorg-video-intel (main) "gnome-panel position is above the standard one" [Undecided,New] https://launchpad.net/bugs/172610
[18:09] <bryce> my cat this morning:  http://bryceharrington.org/Photos/Cats/
[18:12] <tjaalton> mm, that looks comfy ;)
[20:21] <ubotu> New bug: #172638 in mesa (main) "Segmentation fault in Mesa dri / SDL _ConvertX86p32_8RGB332" [Undecided,New] https://launchpad.net/bugs/172638
[20:32] <bryce> huh, all the X tasks for alpha-1 are done.  https://launchpad.net/ubuntu/+milestone/hardy-alpha-1  We're awesome
[20:34] <bryce> oh whoops, there's a couple blueprints for driver issues.  hmm
[20:46] <tjaalton> users can propose those at will..
[20:49] <tjaalton> too bad that specs can't be marked invalid by devs
[20:59] <bryce> do you think those are invalid?  I think at best they're bug reports...
[21:46] <tjaalton> invalid as specs. there are almost 1800 specs listed, and majority of those should just be bug reports
[21:50] <bryce> true
[22:00] <tjaalton> ooh, they got removed :)
[22:00] <bryce> yup
[22:01] <bryce> I got friends ;-)
[22:01] <bryce> the specs are still there, just not listed for hardy
[22:02] <tjaalton> yeah
[22:03] <tjaalton> someone should have the guts to clean up the specs
[22:03] <bryce> agreed
[22:03] <bryce> I've been accumulating a list of obsolete/invalid X specs on wiki (X/Blueprints), in hopes one day to find someone who can/will go through and close them
[22:04] <tjaalton> I guess the reason why it has come to this is that the guidelines used to mention that "feature requests should be specs"
[22:04] <bryce> I asked mdz a while ago, but he didn't want to do it
[22:04]  * bryce nods
[22:05] <tjaalton> it needs special powers..
[22:10] <bryce> to be honest I think by not regularly weeding blueprints, it makes the whole system less useful
[22:11] <bryce> I wish it were categorized more, like bugs are, so there'd be an X-blueprints area that we could maintain
[22:13] <tjaalton> right
[22:14] <tjaalton> it's hopeless trying to find something useful, although the search works somewhat
[22:28] <tjaalton> sigh, why did I start going through nv bugs in upstream
[22:29] <bryce> heh
[22:30] <bryce> eh, so much for offering to help with the xorg website
[22:31] <tormod> hi
[22:32] <bryce> heya tormod :-)
[22:32] <tormod> bryce: xorg website?
[22:32] <bryce> daniels asked for help on wiki.x.org
[22:32] <tormod> on the xorg ML?
[22:32] <bryce> yeah
[22:33] <tormod> I asked them for permissions to remove spam some time ago , heard nothing
[22:33] <bryce> weird, because it seems the complaint was that the spam load was too high
[22:33] <tormod> kind of sucks to file bugs for every change you want to do on the front page also
[22:33] <bryce> yep
[22:34] <tormod> the xorg problem is that they don't want to receive help :)
[22:34] <bryce> seems that way
[22:34] <bryce> upstreams are weird
[22:35] <tormod> their issues with their server hardware is another farce
[22:35] <tormod> they've got money, servers, people who would like to help...
[22:36] <bryce> I like how they completely shut everything down for days when they have security issues
[22:36] <tormod> but things are just blocked on... nothing?
[22:37]  * bryce shrugs
[22:38] <bryce> I figure it's just that daniels takes on too many tasks himself, and isn't comfortable sharing responsibiltiies or something
[22:38] <bryce> like you say, step 1 is you have to want to receive help
[22:39] <bryce> (step 2 is actually letting people help you) ;-)
[22:41] <tormod> I read the thread - yeah it ended up in "which wiki engine is better" discussion. They don't seem to get that "community" thing...
[22:45] <bryce> tormod, tjaalton, do either of you have code/processes for packaging x.org snapshots?
[22:45] <tormod> bryce: funny you ask, was working on it all night :)
[22:45] <bryce> kewl
[22:45] <tjaalton> bryce: nope
[22:46] <tormod> I've been trying to automate xorg git + debian git -> source deb
[22:46] <bryce> some of the ume guys are wanting snapshot packages of xserver git head so they can use the new xephyr stuff
[22:46] <bryce> cool, can I assist?
[22:46] <tormod> works nice for radonhd, but for some reason not for ati
[22:46] <tormod> I wanted to make builds for ati+atombios...
[22:47] <bryce> yeah this sounds like it could be quite useful for bleeding edge folks without packaging expertise
[22:47] <bryce> how could I help?
[22:48] <tormod> Take a look at the script attached to XorgOnTheEdge
[22:48] <bryce> ok
[22:48] <tormod> It potentially work with xorg-server as well.
[22:49] <tormod> but I am not fluent enough in git to get much further ATM.
[22:49] <tormod> Since they are removing xsfbs I have to incorporate make-orig-tar also.
[22:50] <bryce> hmm, I'm not spotting the link...?
[22:50] <tormod> wiki Attachments
[22:51] <bryce> oh whoa, I didn't know there was such a thing.  cool thanks
[23:03] <tormod> bryce, the radeonhd packages on XorgOnTheEdge are built with the script, the extra manual steps (mostly adjustments for Gutsy) are documented in debian/README.ubuntu-dev