=== bryce_ [n=bryce@71.237.200.28]  has joined #ubuntu-x
=== mvo [n=egon@p54A6769C.dip.t-dialin.net]  has joined #ubuntu-x
[08:55] <bryce_> tepsipakki: btw, one thing I'm hoping to work towards with our xorg packaging, is to improve testing
[08:55] <tepsipakki> yes, you mentioned that briefly..
[08:55] <tepsipakki> what do you mean by that?
[08:56] <bryce_> before I started with ubuntu/xorg, I used to maintain a large automated testsuite for nfsv4, and I'm hoping to reuse some of those approaches for xorg
[08:56] <tepsipakki> testing the code itself?
[08:56] <bryce_> well, I haven't 100% determined what would serve us best yet
[08:56] <bryce_> possibly
[08:56] <bryce_> there's a lot of different ways to test things
[08:57] <bryce_> the key is to test for things we can actually do stuff about
[08:57] <bryce_> so like, just running xorg performance tests probably wouldn't gain us much
[08:57] <bryce_> (although it might not be a bad thing to do)
[08:57] <bryce_> the particular thing I've been looking at is just plain old "startup" tests
[08:58] <bryce_> e.g., given a new (proposed) xorg package, install it on a test machine, and try starting xorg on that machine
[08:58] <tepsipakki> that would need a lot of hardware :)
[08:58] <bryce_> yup
[08:58] <tepsipakki> but sounds good
[08:58] <bryce_> which is why I've been accumulating hardware ;-)
[08:59] <tepsipakki> heh
[08:59] <bryce_> I've got 4 working test systems, plus 3 more on the way
[08:59] <bryce_> (I call test systems 'sut's - Systems Under Test)
[09:00] <bryce_> anyway, I bring this up because if you know of or can think of other tests that would be worth running, let me know
[09:00] <bryce_> oh, aside from just having a lot of hardware, it can also be useful to run the same test with different parameters
[09:01] <bryce_> e.g. on an intel system, testing against -i810 and -intel, or with an ati or nvidia system, testing against both open and binary drivers
[09:01] <tepsipakki> can't think of anything, but I'll keep that in mind
[09:02] <bryce_> another thing to think about, is when you manually test something, to try to think, "how could I achieve this same test, but in a completely automated way"
[09:02] <bryce_> as we go, anything we can script, we can turn into a cheap test for using in the future
[09:03] <tepsipakki> manual testing don't scale well :) (but OTOH it doesn't need to be run _that_ often)
[09:03] <bryce_> yup
[09:04] <bryce_> where automated testing can prove useful is when we're doing a release and want to have as many extra checks as possible
[09:04] <bryce_> obviously, those checks don't need to be automated, 
[09:04] <bryce_> but it can eliminate a lot of questions if it's scripted to the extent that it could be 100% automated
[09:05] <tepsipakki> of course, scripting helps, it's just tricky to write good scripts for that purpose :)
[09:06] <bryce_> yup
[09:07] <tepsipakki> I'm wondering if I should create a git branch for our xorg in git.d.o and push the changes one by one..
[09:08] <bryce_> I think that would be really, really, really useful and a very good idea
[09:08] <bryce_> I can set up my test system to auto-pull from git when there are changes, and automatically run tests against that
[09:08] <tepsipakki> the metapackage has most of the changes, rest of the components just use patches so they are pretty trivial to keep for now
[09:09] <bryce_> I used to run this automated test system for carl worth for doing cairo testing, using exactly that approach
[09:09] <tepsipakki> jcristau: you awake yet?-)
[09:09] <tepsipakki> cool
[09:09] <bryce_> so I was thinking resurrecting that would be handy, so we'd have something at the application level to test
[09:10] <bryce_> but a lot of what you and I care about is going to be more at the integration/packaging layer
[09:10] <tepsipakki> upgrades are also nice to test beforehand
[09:10] <bryce_> another thing I've thought about is hooking this in with vmware, so on a given hardware I can test against feisty as well as gutsy
[09:11] <bryce_> exactly
[09:11] <bryce_> I've used this test framework (aka crucible) with xen, but not with vmware
[09:12] <tepsipakki> ah, build tests
[09:12] <bryce_> yeah
[09:12] <tepsipakki> it's silly to upload and then notice that the build fails for whatever reason :)
[09:12] <bryce_> also, I don't know if we care, but I've done some testing work with cross compilers
[09:13] <bryce_> honestly, I don't think anyone is going to care if we get errors/warnings on arm, solaris, etc. ;-) but that's something else we could test if we wished
[09:14] <tepsipakki> I believe debian will test those :)
[09:14] <bryce_> yup
[09:15] <tepsipakki> AIUI they are going to keep experimental as close to upstream git master as possible to make testing easier
[09:17] <bryce_> the thing I've learned with testing is that the key is in reviewing and following up on test results
[09:17] <bryce_> you can automate all the tests in the world and generate terabytes of results, but if no one follows up on the results, it's all worthless
[09:17] <tepsipakki> right
[09:18] <bryce_> so the trick is to try to only run tests that actually matter, that you actually care about
[09:18] <bryce_> so that's where I can really use your help and advice
[09:19] <bryce_> just because we *can* run a test, the real question is if we care
[09:22] <bryce_> anyway, it'll probably be a few weeks before I have anything worthwhile to look at.  But when I do, please be critical - if it looks un-useful to you, say so :-)
[09:22] <tepsipakki> ok, I will :)
[09:23] <tepsipakki> testing itself is a gray area for me, but I know how costly it is to leave testing for the end users
[09:24] <bryce_> cool, well this'll be a good thing to learn.  It's actually a pretty simple thing, it just seems strange and mysterious from the outside
[09:25] <bryce_> testing mostly is just useful for catching goofs
[09:26] <bryce_> but we all make goofs from time to time ;-)
[09:26] <tepsipakki> yep :)
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
[11:10] <jcristau> tepsipakki: now i am
[11:10] <jcristau> (my sleep pattern is kinda fucked up, these days)
[11:12] <tepsipakki> hehe
[11:13] <tepsipakki> I was wondering if it makes sense to create a new branch for xorg and to apply the ubuntu changes there one by one
[11:13] <jcristau> i'm fine with that
[11:14] <tepsipakki> ok, I've just started with it
[11:14] <tepsipakki> I guess it's easier to pull changes then
[11:15] <ubotu> New bug: #20584 in xserver-xorg-video-trident (main) "xv output garbled [not regr] " [Medium,Needs info]  https://launchpad.net/bugs/20584
=== cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-x
[12:08] <ubotu> New bug: #118208 in libxinerama (main) "Context Menu display cutoff" [Undecided,Unconfirmed]  https://launchpad.net/bugs/118208
[12:25] <ubotu> New bug: #53878 in xorg-server (main) "Screen is distorted for a few seconds at X startup shutdown" [Medium,Needs info]  https://launchpad.net/bugs/53878
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
=== mvo [n=egon@p54A67049.dip.t-dialin.net]  has joined #ubuntu-x
=== seb128 [n=seb128@ubuntu/member/seb128]  has joined #ubuntu-x
=== mvo [n=egon@p54A65B4C.dip.t-dialin.net]  has joined #ubuntu-x
=== brycerr [n=bryce@71.237.200.28]  has joined #ubuntu-x
[07:22] <ubotu> New bug: #96213 in xorg (main) "won't install on Dell 640m with 1400x900 screen" [Undecided,Needs info]  https://launchpad.net/bugs/96213
[08:01] <ubotu> New bug: #42607 in xserver-xorg-video-via (main) "Ubuntu Dapper on VIA EPIA-MS with LVDS; no video after installation" [Medium,Needs info]  https://launchpad.net/bugs/42607
[09:10] <ubotu> New bug: #45418 in xkbutils (main) "Restart of X gdm and freezing" [Medium,Confirmed]  https://launchpad.net/bugs/45418
=== mvo [n=egon@p54A667F8.dip.t-dialin.net]  has joined #ubuntu-x
[09:36] <ubotu> New bug: #41404 in xserver-xorg-video-via (main) "OpenGL stuff freezes on AMD64" [Medium,Needs info]  https://launchpad.net/bugs/41404
=== mvo_ [n=egon@p54A67E71.dip.t-dialin.net]  has joined #ubuntu-x
[09:50] <ubotu> New bug: #46352 in xresprobe (main) "Panel resolution not detected" [Medium,Needs info]  https://launchpad.net/bugs/46352
[10:00] <ubotu> New bug: #32152 in linux-restricted-modules-2.6.15 (restricted) "Wireless networking suddenly broken" [Medium,Needs info]  https://launchpad.net/bugs/32152
=== mvo_ [n=egon@p54A673E6.dip.t-dialin.net]  has joined #ubuntu-x
[10:51] <ubotu> New bug: #68319 in xorg (main) "Right button and middle click on mouse are swapped" [Undecided,Unconfirmed]  https://launchpad.net/bugs/68319
[11:11] <ubotu> New bug: #49115 in xresprobe (main) "Max resolution not detected properly for IBM G78" [Undecided,Rejected]  https://launchpad.net/bugs/49115
[11:33] <ubotu> New bug: #36525 in linux-restricted-modules-2.6.15 (restricted) "bcm43xx Driver only works @ 11Mb/s" [Low,Confirmed]  https://launchpad.net/bugs/36525
[11:44] <brycerr> tepsipakki, I posted a patch to bug 42553 for conditionalizing wacom in dexconf, with explanation of why we aren't doing it based on mjg59's comments
[11:44] <ubotu> Launchpad bug 42553 in xorg "wacom input devices enabled by default, why?" [Medium,Confirmed]  https://launchpad.net/bugs/42553
[11:54] <tepsipakki> brycerr: yeah, uploading with that change would be a regression for some wacom users, so probably not worth it
[11:54] <tepsipakki> we'll see how the input-hotplug progresses..
[12:00] <ubotu> New bug: #103497 in linux-restricted-modules-2.6.20 (restricted) "IPW2200 proccess 100% cpu ussage with no configured  network in the area" [Undecided,Needs info]  https://launchpad.net/bugs/103497
[12:05] <ubotu> New bug: #72705 in linux-restricted-modules-2.6.17 (restricted) "kernel panic, system freeze on shutdown, vmware hangs..." [Medium,Confirmed]  https://launchpad.net/bugs/72705