=== maco_ is now known as maco [01:40] https://wiki.ubuntu.com/X/Troubleshooting/IntelPerformance [06:01] heya cwillu [06:01] poke poek [06:01] cwillu: with -intel bug triaging, the name of the game for us is getting bugs upstreamed to Intel [06:02] we fix _some_ bugs in Ubuntu but the vast bulk are fixed upstream, and we cherrypick the patches into Ubuntu [06:03] of course, hardly anyone reports bugs to us in a form that we can upstream, so it usually takes some work on our part to massage them into shape, getting the requisite info, etc. [06:04] cwillu: the page to bookmark is http://intellinuxgraphics.org/how_to_report_bug.html [06:05] got it [06:06] I've been developing some automated scripts that help in gathering or requesting the info, but some reporters really need human help [06:06] * cwillu is composing notes in the background, please keep the info dump going :) [06:06] ah ok :-) [06:07] what else... [06:07] you may want to join the ubuntu-x@ mailing list as well; quite low traffic but I try to announce stuff there and we sometimes have useful discussions [06:08] https://lists.ubuntu.com/mailman/listinfo/Ubuntu-x [06:08] if I start adding tags to bugs in a private namespace, are they likely to remain there, at least for a week or so? [06:08] we also have a team set up in launchpad - https://edge.launchpad.net/~ubuntu-x-swat [06:09] private namespace? [06:09] (cwillu-foo, cwillu-bar) [06:09] ahh, yeah feel free to add tags [06:09] mainly so I don't trip on other stuff by accident [06:10] I was planning on opening umbrella bugs per-chipset, linked to newly opened bugs for each unique symptom that I can see. [06:10] btw, if you join the ubuntu-x-swat list, one important caveat is that it subscribes you to the bug mail - roughly 100 mails per day [06:11] so if you do that make sure you have procmail or something to filter those out. I'd be happy to share my procmail rules if you use it [06:11] I think a good portion of the deluge comes from people posting to the first bug they find with a similar symptom, so "intel video hangs" gets all the traffic even if it's an 810 bug [06:11] being a member of the team enables you to set states Triaged and Wontfix, set priorities, etc. [06:11] bryce, I'm addicted to gmail :p [06:11] hehe [06:12] indeed, you're absolutely right. "driver performance regression" would be another good subjectline if you wanted to cause a me-too storm ;-) [06:12] I try to always update bug titles when I see ones that just describe a generic symptom [06:13] it helps head off confirmation hell [06:14] regarding tagging of chipsets, one thing I've been doing is prepending bug titles with chipset names, [i845], etc. [06:14] yep, that was my inspiration actually :) [06:14] I think people used to use tags for the same purpose, but an advantage to the subject lines is that it helps mitigate me-too'ing [06:15] Umbrella bug per chipset, and then nice fresh bugs with the chipset in the title, a list of similar but different bugs in the summary, exhortations to verify the chipset and simple instructions to do so [06:15] as well, even mroe importantly, it's the format upstream likes to have when we upstream the bugs [06:15] basically, a couple hundred words of boilerplate, to make it easy on the lazy bug reporters [06:15] sounds interesting [06:15] is that counterproductive re: upstreaming those bugs? (I'm imaging that the boiler plate can be stripped easily enough) [06:16] dunno, I'd need to see it in action. Willing to give anything a shot that helps us get more organized [06:16] I guess if I get a start on this over the weekend, I probably won't be tripping over too much concurrent activity on launchpad [06:17] I'll avoid marking any of the old bugs as duplicates until it's clear if it's a win or not [06:18] (are duplicated bugs hidden from searching-by-tag by default as well?) [06:18] yes [06:23] this would also be one of those days I regret not having my wiki up and running [06:23] my schemes -> http://pastebin.com/f5600578c [06:27] nice [06:28] is there any need to drill down to the particular revision, or is the general chipset enough? [06:29] when you go through bugs you'll note the format I've been trying to use, basically separating standard sections via [lspci], [testcase], etc. [06:29] yep [06:30] god I hope they get that ext4 mess sorted out quick [06:30] especially when upstreaming bugs I like to have the top of the bug report be a very brief [problem] statement, no more than 1-3 sentences, so people can quickly skim it [06:31] okay [06:31] Time for bed now, I should be getting started in ~10 hours or so [06:31] Thanks for the info :) [06:31] regarding the particular revision... in the subjectline I tend to keep it just to the family, but in the [lspci] section it is good to be more specific [06:32] okay [06:32] sure, cya later :-) [06:33] don't know if you want to mention anything on the mailing list, I probably won't be bothering to subscribe to it until I'm thoroughly sick of sifting through launchpad sometime tomorrow :p [06:36] ok, I'll wait 'til you make introductions [07:00] bryce_: looks like the glxinfo crashers all had nvidia in NonfreeKernelModules, so -> nvidia-glx-180 :) [07:01] aha [07:01] moving them right now [07:01] tjaalton: odd, I was just looking at nvidia bug replies [07:01] also, there are a couple of intel regressions, suggesting that the most recent version doesn't work for everyone [07:01] filed against xorg [07:01] looks like a handful of people followed through on my request to test + close -180 bugs. Was hoping to see more, but at least it's something [07:02] * bryce_ looks [07:02] these were filed against mesa [07:04] which bug #'s? [07:05] none of the new bugs in xorg look due to today's updates... [07:05] 354735 [07:08] ok that was the only one I guess [07:09] ok [07:09] nx6110 sounds familiar... [07:11] hmm, well if he truly has narrowed it to 2:2.6.3-0ubuntu4 or ubuntu3, the only change in those that looks reasonably questionable is 118_drop_legacy3d.patch [07:12] ./debian/changelog: * 25_quirks_nx6110.patch: [07:13] hmm bug 354889 looks related [07:13] Launchpad bug 354889 in xorg "[jaunty] i845 xorg crashes upon playing video" [Undecided,New] https://launchpad.net/bugs/354889 [07:16] found a dupe for steve's bug [07:24] how related? [07:25] same error message [07:25] I've run across a bunch of "crash on playing video" bugs. We need to report those upstream [07:25] http://dl.getdropbox.com/u/256410/IMG_0479.JPG [07:26] duped them already [07:26] hehe [07:26] man, that bit of code to put the error into the dialog has turned out way more useful than I'd anticipated :-) [07:27] heh [07:30] bryce: that was a truly inspired idea. [07:30] grep ftw [07:31] * Alexia_Death hates having to do that manually when something fails [07:32] Now, if crash log would not get overwritten if you log in again for random crashes... [07:32] Alexia_Death: it should not get overwritten [07:32] Alexia_Death: I made sure the failsafe log gets written to Xorg.failsafe.log instead [07:32] failsafe yes [07:32] Alexia_Death: also the Xorg.0.log.old should still contain the prior crash [07:33] but say my X crashes but theres no need or failsafe [07:33] X can start normally [07:33] right [07:33] greeter loads just fine and I log in [07:33] crash should still be in the Xorg.0.log.old [07:33] After I log in the crash log is gone. [07:34] no. its gone. [07:34] are you sure? [07:34] the greeter log is in the .old [07:34] it's been there for me... [07:34] hm [07:35] I havent needed it in the past few months but before that when tablet still crashed X I needed to keep a console session to coppy the log before it was lost [07:36] its a sort of thing you only need when things go wrong with X configured right... [07:36] Alexia_Death: ok, well 274870 covers this situation [07:37] ? [07:37] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=503251 - forwarded to debian, but no response so far afaik [07:37] Debian bug 503251 in xorg-server "xorg-server: Xorg should keep more rotated logs" [Wishlist,Open] [07:37] Alexia_Death: the wacom hotplug patches are now upstream :) [07:38] in 0.8.3-2 [07:38] (and I'm open to alternate ideas || patches) [07:38] and builtin serial devices should work OOTB [07:38] tjaalton: Indeed:D [07:38] bryce: yes, that covers it:) [07:39] tjaalton: how was that done? [07:40] My daemon has serial devices description file. I use an usb Serial tablet [07:40] laterz [07:40] Alexia_Death: with a hal callout program that feeds the parameters to the xserver/driver [07:41] tjaalton: sounds sensible:) [07:41] "usb serial tablet" [07:41] how's that possible :) [07:42] usb->serail adapter+ serial tablet:) [07:42] ah [07:50] how the hll is lp karma counted these days? yesterday or the day before mine was around 16k and now it's over 50k.. [07:51] Hm. We may need to pull in a patch to update libdrm-nouveau. Let's see... [07:52] tjaalton: I heard there was some inflation in translation karma [07:52] i wonder if there's a "my sister runs ubuntu" team.. [07:52] bryce_: haven't done those ;) [07:52] oh, soyuz [07:52] 35k from there [07:55] tjaalton: btw, cwillu suggested some of these random unexplained lockups might be due to the ext4 fallout [07:56] (bug #330824) [07:56] Launchpad bug 330824 in linux "Soft lockups (freezes) when deleting files from ext4 partitions on 2.6.28" [Medium,In progress] https://launchpad.net/bugs/330824 [07:56] oh? [07:56] Ow. Everyone's favourite not-quite-stable filesystem! [07:58] I'll switch to btrfs once karmic opens ;) [07:59] who cares if it can't handle full disks [07:59] disks are cheap [08:00] I wonder if there's any way we can easily determine what filesystem they have installed? [08:04] installed or mounted? cat /proc/mounts will tell you what fs types are mounted [08:04] the problem is (reliably) determining where $HOME is [08:05] under / or /home or linked somewhere [08:05] I'll add /proc/mounts to our apport [08:06] ooh, mount -t ext4 will tell you if any of the fielsystems are ext4. [08:09] hrm, what does stat -f /path say on an ext4 system? [08:10] * sbeattie wiped all his test ext4 partitions after getting bit by data loss. [08:11] try: [08:11] script = subprocess.Popen(['mount', '-t', 'ext4'], stdout=subprocess.PIPE) [08:11] matches = script.communicate()[0] [08:11] if (matches): [08:11] report['ext4'] = matches [08:11] except OSError: [08:11] pass [08:11] look good? [08:11] sbeattie: Type: ext2/ext3 [08:11] ah, bummer. time to file a bug on stat [08:12] yeah [08:13] jcristau: should the rgb.txt-file be revived? there seem to be a number of client apps that still want it [08:14] some of them proprietary [08:17] committed [08:31] I ought to write an automatic script to reply to bugs with "randomly" in the subject ;-) [08:35] Hm. I think we should pull in the recent changes to libdrm/nouveau. Does anyone have any particular comments or questions about this? [08:37] RAOF, yes what are the recent changes? Are they feature additions or bug fixes? How well tested are the changes? Are there specific bugs in launchpad that they are likely to resolve? [08:41] So, it's difficult to say whether the changes are bugfix or new features. There are things which certainly are bugfixes. Fixing a memory leak, cleaning up typos. [08:42] given that we're a week away from release, how comfortable are you with that uncertainty? [08:43] (fwiw, I am struggling with -intel fixes that are *definitely* bug fixes, yet apparently cause regressions... aargh!) [08:43] * wgrant makes it 2.5 weeks, not 1. [08:45] I'm not entirely sure; this depends on precisely what xserver-xorg-video-nouveau is doing in Jaunty. If it's predominantly for testing, then I'd be uncomfortable with not shipping the changes; their lack definitely generates an error in the driver, but I'm not sure whether anything actually _hits_ that path. [08:45] wgrant: well, post April 9th we shouldn't be making any changes [08:45] bryce_: That's true. [08:46] * bryce_ s/release/end of development/ [08:47] wtf is up with wiki.ubuntu.com tonight? [08:47] It's not very up. [08:47] indeed [08:47] Well, actually, I am sure that something hits that path; mesa. DRI is definitely broken because we don't have the changes in libdrm-nouveau, but that's really neither here nor there. I'm not sure whether anything _else_ hits it. [08:48] RAOF: personally I consider it predominantly for testing, and will back you up 100% on that. [08:49] RAOF: but ultimately it's up to you -- if the changes cause regressions you'll want to have a plan on if, and how to deal with them. [08:51] Worst case we can simply disable the patch. That'll take things back to their current, apparently working fine, state. [08:51] * bryce_ nods [08:51] make sure to solicit testing feedback in that case [08:52] disabling patches pre-release is not too difficult, but post release can require a lot of annoying paperwork [08:52] Right. [08:54] fwiw, I'm really happy with -nouveau's state in jaunty, it is exceeding where I'd expected of it to be development-wise [08:55] similarly with -ati. I think our open source story on both nvidia and ati hardware is notable [08:55] It's very nice that 2D is quite drama-free. [08:55] Intel, however, is not meeting what I had anticipated in jaunty. [08:56] but still there's time [08:56] Intel has been somewhat of a problem child this release, hasn't it. [08:56] Although that might also be due to lack of testing; we've only had... 6 bugs reported against the nouveau stack in total? [08:56] could be [08:56] certainly no shortage of bug reports against nvidia -180 [08:57] RAOF: I'd put a "we're not accepting bug reports against -nouveau" statement in the bug tracker for -nouvea at the start of jaunty [08:57] that may be cutting down on bug reports a bit. I should probably pull that out (assuming you're interested in bug reports) [08:58] I'm moderately interested, but the bugs will be less and less interesting the older Jaunty's snapshot gets. [08:59] I know that Jaunty's nouveau package has so far resulted in at least one bug being filed upstream and fixed, though. So that's good :) [09:00] ok [09:00] my plan has been to pull that out once karmic opens, which is just a few weeks, so unless you're anxious for bug reports I'll stick to that plan [09:00] I think that's a fine plan. [09:01] ok kewl. let me know if there's any specialized info beyond the norm you'd like included in nouveau bug reports [09:01] most people don't read directions, but for those who do, we can tell them what to include [09:02] Xorg.0.log, as always. Also, and slightly more difficultly, dmesg with the drm module loaded with 'debug=1'. [09:02] interesting; how do you load the drm module with debug=1 ? [09:03] "modprobe drm debug=1" [09:03] But you obviously have to do that outside of X, and preferably you want to do that before nouveau.ko has been loaded at all. [09:03] right, hm [09:04] So I tend to start in recovery mode, drop to a root terminal, modprobe, then continue the boot sequence. [09:04] usually by the time they've gotten to the directions, they've already got their bug. I'll need to think on where best to put that direction. [09:05] That's obviously only useful if you can easily reproduce the bug; running with debug=1 results in everything being a bit slower, and dmesg being big :) [09:05] are there disadvantages to running with debug=1 ? [09:05] oh okay [09:05] maybe we need a 'how to debug nouveau' wiki page with this on it [09:07] That's a fine idea. [09:07] * bryce_ switching machines... [09:11] mm [09:11] ^%$ broken wiki [09:12] ok, well, some day we should make a troubleshooting page for nouveau. ;-) [09:12] Once the wiki is up! [09:29] OK. libdrm is pushed to git. I'll craft a call for testing. [09:48] bryce: a random stock reply for such bugs?-) [09:53] tjaalton: couldn't hurt [10:48] heya albert23 [10:49] hi bryce [10:51] albert23: what's new [10:55] +? [10:56] bryce: not much yet. Weekend has started and going to do some performance testing on Kubuntu [10:56] That's a bit slow on 965 [10:56] yes [10:56] everything is slow on all intel chipsets [10:57] (my fault I think) [10:57] tjaalton: yes, possibly (re: rgb.txt) [11:01] bryce: actually, Gnome is doing fine on the 965 [11:02] and the 945 is fine without gem as well [11:03] So I guess it's the whole gem newness that's hurting at the moment [11:03] albert23: try open a fullscreen firefox window on each side of the cube in gnome and then spin the cube [11:03] I think it [11:03] s about how big the bitmaps are or something [11:04] * bryce waves to jcristau [11:05] if I spin the cube with no programs active, it's really fast even in EXA but if I create lots of firefox windows then in becomes very slow.. so maybe kubuntu just uses the intel driver differently and thus runs straight into the perf problems [11:08] mnemo: indeed, 3 times firefox makes the spin slow [11:08] but Kubuntu already seems to be slower with just moving windows around [11:08] * bryce <-- passing out [11:08] night everyone. [11:09] good night [11:12] night [13:42] hi, was it needed to change the order of the entries in the xorg.conf [13:51] oooo, uxa is fast again on the latest kernel on 945 [13:53] bug 349314 [13:53] Launchpad bug 349314 in linux "[i915] allocate MCHBAR space & enable if necessary" [Low,Fix released] https://launchpad.net/bugs/349314 [13:54] Fixes tiling issues and slowdown on i915 chipsets [13:58] got the impression that was supposed to help exa though [14:01] albert23, was that supposed to be fixing uxa or exa? Uxa has good performance again, exa still has noticeably slower rendering on larger windows [14:03] cwillu: the change is in i915_gem_tiling, and gem is used by both exa and uxa [14:03] ineffective on exa then [14:05] cwillu: with exa, do you still see tiling error messages in X log? [14:05] yes [14:05] http://pastebin.com/f4b9a0722 is uxa [14:05] http://pastebin.com/f779fadfc is exa [14:06] Failed to set tiling on front/back/depth buffer under exa [14:07] There's also a warning: (WW) intel(0): DRI2 requires EXA [14:07] bah, UXA [14:07] uxa also fails on the front buffer [14:07] yes [14:08] uxa is fast for any size of window though [14:08] like, night and day difference [14:08] good, so far it was only fast fro small windows for me [14:08] cwillu: rejected by kernel usually means that the drm from kernel is wrong, 11.40 is patched [14:08] Kano, I'm running 11.40 [14:10] well maybe the fix was only for another chipset [14:10] Jesse mentions he only tested on i915... [14:52] * albert23 has no luck with the new kernel. GLBlur full-screen and sauerbraten are still slow (amd64) [14:57] I've never had blur be fast on a 945 [14:58] It's fast for me with gem disabled [15:00] wow, turning it on and off again just put performance through the floor, I'm getting .2 fps now [15:00] how can I make an LP bug be open against both python2.6 and mesa? if I select "also affects project" I only see upstream mesa project [15:00] even with blur redisabled [15:00] its for this bug --> https://bugs.launchpad.net/ubuntu/+source/python2.6/+bug/355137 [15:00] Launchpad bug 355137 in python2.6 "[G45] xserver and/or python2.6 crashed with SIGSEGV" [Undecided,New] [15:00] mnemo, also affects distribution [15:00] aah ok [15:21] bryce, the boilerplate for "we need xorg.0.log and lspci" should probably include a note to remark the bug as confirmed or new [15:34] ooo, ubuntu wiki is back up [20:35] cwillu: in fact what I've been doing lately, is tag bugs "needs-lspci-vvnn" when asking for those files. I'm working on a script that automatically reviews bugs with those tags, that have had the files subsequently provided by the original reporter, and then it moves the bug to Confirmed automatically [20:36] cwillu: using a script to do it ensures some level of consistency, and simplifies things for the reporter a bit, since they can then just reply via email or whatever [20:37] oh btw, I've got a processing script that runs against all bugs in New, and asks the user to attach stuff, etc. [20:37] so take care not to put bugs into New state unless they do need to be re-processed by the script. [20:38] I've seen situations where the reporter kept putting the bug back to New, and getting a new automated response, repeat etc. [20:40] yep, I've been marking them back to confirmed [20:40] the first script re: needs-lspci-vvnn, is that running now? [20:41] I've removed that tag from about 5-6 bugs that had the relevant details attached [20:41] cool [20:41] I run the scripts manually usually on Mondays [20:41] you remember anything about 865's dri being disabled offhand? [20:42] I like to keep them supervised since I've been known to make coding goofs ;-) [20:42] heh [20:42] yes, in fact it is intentionally disabled [20:42] is there a particular api for scripting lauchpad, or are you just making normal http requests? [20:42] yes, the api is provided by 'launchpadlib' [20:42] is there any hope for it being enabled? [20:43] thanks, I'll look into that [20:43] https://help.launchpad.net/API/launchpadlib [20:43] yes, the original problem was that with DRI enabled, 865 would freeze during boot [20:43] 845 et al? [20:44] we tried a number of different things to get it working but no dice, so ended up disabiling it [20:44] no, I disabled it only on 865 [20:44] hmm, xorg claims 845 and 865 have it disables [20:44] s/disables/disabled/ [20:45] https://bugs.launchpad.net/ubuntu/+source/xserver-xorg-video-intel/+bug/355258 [20:45] Launchpad bug 355258 in xserver-xorg-video-intel "[i865] Jaunty: DRI disabled with i865" [Undecided,Confirmed] [20:45] oh right [20:46] hmm, I think we don't need to disable it on 845; I could take that bit out of the patch [20:46] this is bug 304871 btw [20:46] Launchpad bug 304871 in xserver-xorg-video-intel "[i845G] Fatal server error: Couldn't bind memory for BO front buffer (Jaunty)" [High,Fix released] https://launchpad.net/bugs/304871 [20:48] yes, I pulled one guy away from that report back to his on report on 865 on the same issue, marked it as fix released, and got him to file a new bug for the dri issue [20:49] 343690 I believe [20:50] good [20:50] http://pastebin.com/ff2e4278 is where I'm at [20:51] Internally flagging each bug as either a hang/crash, display corruption/anomaly, or performace [20:51] nice [20:51] I'm just working down the list of incomplete bugs from the bug day page [20:52] once I've finished that pass, I'll make umbrella bugs for each class, link them all up, etc [20:52] yeah I've thought we could fix titles to include keywords (like I did with "(UXA bug)") to make them easier to group [20:52] excellent [20:52] I've just been doing [i865] [UXA], etc [20:52] plus tags, but ya [20:53] wonder how easy it would be to have seperate 'packages' per chipset to report against [20:53] I mean, I know they're all in theory -intel, but... [20:54] btw, there's some triaging graphs here - http://people.ubuntu.com/~bryce/Plots/ [20:54] click on X, then -intel on the left [20:55] * cwillu looks at the dip in incomplete bugs at 12:00->20:00, and shouts "hey, that was me!" :) [20:58] is there a magic syntax to write bug numbers in launchpad description so that they get linked up automatically? If there is, I haven't tripped over it yet [20:59] :-) [20:59] "linked up"? do you mean duped? [20:59] no, just referenced [21:00] ah, yes if you say "bug NNNNN" it'll autolink them [21:00] "bug #NNNN" may work too [21:01] I knew that. Except for the last 4 hours [21:01] anyways :p [21:01] I don't think creating separate packages for each chipset would be very feasible, but I've thought it would be nice to create a launchpadlib report that allows ordering and/or filtering by chipset (or tags in general) [21:01] hehe [21:26] If I can get a few machines with 845/855/865 chipsets, would some sort of remote access test farm be useful? [21:35] cwillu: I think the most useful resource would be a a server that everyone can PXE boot from into various configs for super easy bisection [21:35] it would be like grub booting over network where you can choose like 2.6.28kernel+intel2.6.3+mesa7.4 etc [21:36] using such a tool we could easily and conveniently bisect issues [21:36] and find the patches we need to cherry pick [21:36] kexec would make short work of that [21:36] if one has to compile mesa,kernel,libdrm and intel ddx it's soo much work to bisect issues (also many people, like me, is not that good at fixing issues when stuff doesnt compile) [21:37] ive not really been able to test upstream versions at all until I found xorg-edgers [21:37] but know I've been able to file several good upstream bugs using xorg-edgers + mainline kernel [21:38] and easy bisection is probably the _one_ thing I can imagine that could help us quickly backport cherry picks [21:38] the idea is basically xorg-edgers but with history and bootable directly from network [21:39] that would rock imo, heh [21:39] but probably hard to build [21:39] * cwillu ponders [21:39] I'd need a power supply that I can power-cycle over the network [21:39] and maybe a webcam :p [21:40] yeah [21:40] also... then it would also be easy for us to ask bug reporters to "hey, go boot this blah blah versions and see when it broke plx" [21:40] i mean if its really easy we can get help from more people [21:40] but beyond that, it doesn't look completely infeasible [21:40] biggest problem would be how to handle access to it [21:40] I don't need to be providing an open proxy :p [21:41] I'm intruiged : [21:41] not intruiged enough to jump on it right now, but that's probably something useful that I can poke at post jaunty release [21:42] yeah === mnemo is now known as mne|afk [21:42] * cwillu idly wonders how you spell intruiged anyway [21:42] intrigued [21:42] that's it [21:49] hehe [21:50] a test farm is a good idea. With X testing, there's a bit of a limitation in that a lot of bugs require you to sit in front of a real physical screen [21:51] also, for bugs where X locks up, if you're using the machine remotely, how do you restart it? You'd need some sort of IPC or something [21:51] but... if we had a good plan, I'd totally be on board with it. [21:51] hmm, people on the bibblelabs forums claim that our nvidia packages are broken because they link libGL.so.1 against the nvidia library, when it should be the mesa version.. [21:52] resulting that bibble5 doesn't start [21:52] "works on fedora" [21:53] mne|afk: in fact I've been working on a bisection page thingee (for just -intel and -ati, not mesa, xserver, etc. yet) [21:53] I've just had so much regular bug work to do, my progress has been slow. But it's probably about a man-week from being usable [21:55] cwillu: fwiw, before I started working at Canonical, in my previous job I set up exactly such a remote, automated test harness, for doing NFS testing, called 'Crucible' [21:56] http://markmail.org/message/yii6s3okfiyqlx57 [21:58] biggest sticking point is how do you monitor the video: I mean, one could just get a good big kvm with a monitor and a webcam, but that's pricy [21:58] yep [21:58] otherwise you're stuck with only really being able to test crashers [21:59] I was actually fortunate in snapping up a kvm when my previoous company went belly up and auctioned everythign off :-) [21:59] intels aren't discrete, so you can't just plop a bunch of them into one machine and select them via pci address or whatever [21:59] (thinking out loud) [21:59] right [21:59] even with discrete cards, there's often only one slot on the mboard to stick them [22:00] and having >1 vidcard in a system can sometimes cause other kinds of problems... (something I've been testing actually...) [22:00] well, that can be addressed with a good choice of machine to use in the first place [22:00] although that still doesn't help with the 'capturing the output' problem [22:00] * bryce nods [22:00] I miss my multiseats :) [22:03] afk for a bit === mne|afk is now known as mnemo [22:05] "With X testing, there's a bit of a limitation" [22:06] thats the reason why I was thinking about PXE network booting [22:06] so you get different versions of stuff but you can still only test _your_ hardware [22:07] "With X testing, there's a bit of a limitation in that a lot of bugs require you to sit in front of a real physical screen" [22:07] even [22:11] hmm, now still is pretty aburd actually... http://portableubuntu.sourceforge.net/index.php?section=screenshots [22:11] ubuntu for Windows ? [22:44] mnemo: ahh, gotcha, thought you meant pxe booting within a testing environment [22:45] er, _remote_ testing environment I mean [23:10] lp is quite responsive today.. [23:12] * bryce waves [23:12] filing a FFe for wacom-tools [23:12] howdy [23:16] tjaalton: Which LP are you using, and how can I get at it? :) [23:16] RAOF: edge, trying to be sarcastic ;) [23:20] Oh. Dissappointing! I'd quite like to actually access my bugs, damnit! [23:21] edge is functional, if slow, which is more than can be said for release right now :-) [23:30] maxb? [23:33] main lp.net is completely down [23:35] ah [23:36]