[00:45] <bryce> superm1, there is a script which automatically moves bugs from 'xorg' to other packages.  It just makes guesses and sometimes is wrong.  If you set the importance, or assign the bug, or set status to triaged, the script will ignore the bug.
[00:46] <bryce> superm1, perhaps I should make the script check for 'failsafe' in the title too.  /me todo's
[00:46] <superm1> bryce, ah i figured it was something like that.  i dont like to triage or assign other teams bugs even if i have permissions too as then i dont know that the right eyes get to see them
[00:46] <superm1> and i dont trust that my opinion of what the priority should be is what the team would agree on
[00:55] <bryce> understood, just be aware that bugs filed against xorg are volatile since that's our incoming queue for all X issues
[00:55] <bryce> superm1, I've updated the script to leave bugs with titles including (failsafe|please|depend|apport) alone
[00:56] <superm1> cool okay
[04:35] <bryce> tjaalton, I notice we have 104_nvidia_autodetect.patch and 105_fglrx_autodetect.patch present in xorg-server but disabled in series, and no mention of them in changelog.  Do you recall what the status of these is?
[05:08] <superm1> bryce, if i am to recall correctly, there is a problem with them when an xorg.conf is present
[05:09] <bryce> ah
[05:09] <bryce> ok, sounds like something we could look at as part of that blueprint
[05:09] <superm1> but sorting out those issues should definitely be something to mention in that blueprint
[05:10] <superm1> could you by chance assemble a karmic PPA that we can have with them enabled for a quick test so we can evaluate definitively what's missing?
[05:10] <superm1>  /broke
[05:12] <bryce> sure
[05:13] <bryce> btw, presently I'm trying to draft up a test plan for the proprietary drivers...  https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers
[05:13] <bryce> just started about 30 min ago; please toss out ideas for stuff/configurations/corner-cases worth testing
[05:14] <superm1> well i should probably throw out the idea that i had at you too then
[05:14] <superm1> what would you think about offering proprietary drivers via a ubiquity plugin that ran jockey?
[05:15] <superm1> just the ones that are on the media
[05:15] <superm1> so if you install from a DVD, you'll be able to install them all, but otherwise it would just be wireless
[05:15] <bryce> on the media?  do you mean on the dvd?
[05:16] <superm1> the idea comes more out of the horrible experience you have with the 10v where you dont have wireless after a fresh karmic install
[05:16] <superm1> but if you are installing from live media that contains fglrx or nvidia, those can be offered too
[05:16] <bryce> hmm
[05:16] <superm1> i haven't talked it over with evan and colin yet
[05:16] <bryce> I think that'd be a great idea
[05:16] <bryce> although I don't know all the ramifications and impact it'd have on ubiquity
[05:17] <bryce> yeah
[05:17] <bryce> well I'd have no concerns against it, I think it or something equivalent would be a good idea
[05:17] <superm1> hopefully it doesnt need to actually be part of ubiquity if mterry did all his ubiquity code for plugins right, it would be part of jockey
[05:17] <bryce> right
[05:18] <superm1> at some point during the week i'll bring it up with them, i'll see what session fits best
[05:19] <bryce> ok
[05:19] <superm1> i think that upgrade and fallback testing are both great things that are definitely undertested
[05:21]  * bryce nods
[05:22] <bryce> yeah that is the main motivation here; I figure the main root cause of the nvidia problem was that it was not tested fully enough
[05:23] <superm1> well i have a differing view.
[05:23] <bryce> I'd tested both drivers heavily at the point that I uploaded them, but they were fine at that point; they really needed re-testing after the upstart stuff
[05:23] <superm1> upstart was introduced very late in the cycle, and brought with it unforseen consequences that weren't fully hammered out for a long long time
[05:25] <bryce> sounds like our views are not so different actually ;-)
[05:25] <superm1> yeah :)
[05:25] <bryce> anyway, I want something that I can point testers to for any time we change something like that drastically
[05:26] <bryce> next time it could be a late kernel change, or some build system thing
[05:26] <superm1> Yeah
[05:26] <bryce> what I hope to do is hand this to our QA team and get them to own it
[05:27] <bryce> I figure they'll be able to do the testing much more reliably and rigorously than I could alone
[05:39] <bryce> https://wiki.ubuntu.com/X/Testing/ProprietaryDrivers updated
[05:39]  * bryce --> dinner
[20:57] <tobi_> bryce_: I'm not able to find out, which patch would fix my problem. But it looks like there aren't that much fixes from intel 2.9.0 to 2.9.1. why don't you do a complete packport?
[21:01] <bryce_> tobi_, because the Ubuntu release managers do not allow complete version backports, just specific patch backports
[21:01] <bryce_> IOW, it would be rejected if I tried to put it through.
[21:01] <bryce_> (trust me, I've tried many times before)
[21:15] <tormod> tobi_, there are really few commits: one i830 fix, one uxa fix, one dvi revert fix.
[21:16] <tobi_> tormod: but I have no clue how to find out which patch is the on to fix my problem
[21:17] <tormod> tobi_, what is your problem?
 the version in 9.10 broke tho only winform mono app I use :(
[21:19] <tobi_> I have an mono winform application, and in that the text is white on white
[21:20] <tormod> and you know or suspect 2.9.1 to fit it?
[21:20] <tormod> *fix
[21:20] <tobi_> that was what I was told on #mono
	supertobi, , intel?
	yes
	driver bug.
	use intel 2.9.1
[21:24] <tobi_> the answer was so fast, that it sound like a well nown problem there
[21:24] <tobi_> apropos, you can test it with this app:
[21:24] <tobi_> http://code.google.com/p/rasterbator-ng/
[21:26] <bryce_> tormod, could only be the uxa fix,  yeah?
[21:28] <bryce_> it is a fix to http://bugs.freedesktop.org/show_bug.cgi?id=24459
[21:28] <bryce_> tobi_, ^ is that your bug?
[21:33] <tobi_> not sure
[21:34] <tobi_> I think that's could be the bug
[21:36] <albert23> https://bugzilla.novell.com/show_bug.cgi?id=549882
[21:37] <albert23> they confirm 2.9.1 works
[21:39] <tobi_> yes, that is at least my problem
[21:59] <bibinou> hi
[22:00] <bibinou> i'm no X wizard and I have a problem triaging a bug 
[22:00] <bibinou> https://bugs.launchpad.net/ubuntu/+bug/409640
[22:00] <bibinou> it seems to affect the "Xv Driver"
[23:04] <tormod> bryce_, sorry got busy. did tobi try xorg-edgers?
[23:06] <bryce_> tormod, sorry I got distracted as well
[23:06] <tormod> np :) I found his initial discussion on #intel-gfx
[23:07] <tormod> would have talked him into patching it himself but he ran away
[23:07] <bryce_> I'm heading out on vacation for the week soon (and will be heading to UDS after that) so probably won't be of much help
[23:07] <tormod> well have a nice time!
[23:07] <tormod> so no xorg updates in lucid then?
[23:07] <bryce_> as nice as a new baby will allow!
[23:08] <bryce_> yeah... was hoping to have done some work on it this week, but still dealing with -nvidia fallout
[23:08] <tormod> did you look at my mesa git history rewrite?
[23:08] <tormod> yeah proprietary drivers suck
[23:09] <bryce_> not yet, it's in the queue
[23:09] <bryce_> I'm unfortunately backed up with a bunch of requests to look at things...
[23:10] <bryce_> wife is not letting me work late to stay caught up any more ;-)
[23:11] <bryce_> looking at it now
[23:11] <tormod> well just hope we can get back to use git for next mesa version
[23:11] <tormod> I am just wondering if I should sync the non-debian/ stuff to the tarball
[23:12] <tormod> *from the tarball
[23:13] <bryce_> what's the non-debian stuff?
[23:14] <tormod> things outside the debian/ directory
[23:14] <bryce_> heh, I know that, I mean, what were the changes outside debian/?  Not spotting them
[23:15] <tormod> well that's the thing, I ignored them in the git history because they make so much noise
[23:15] <tormod> the alternative would be to have them in separate commits
[23:16] <bryce_> oh were those configure change stuff?
[23:16] <bryce_> any autoconf type stuff can be dropped.  As long as the package still builds that should be sufficient
[23:17] <tormod> no, these are non-used changes for instance in the windows dirs
[23:17] <bryce_> hmm, not sure I understand why those changes would be there though... did our source tarball differ from debians?
[23:18] <tormod> It certainly did sometimes, when we shipped 0ubuntu1 for instance
[23:18] <bryce_> right
[23:18] <tormod> and debians tarball != debian git
[23:19] <bryce_> ah so there are non-debian/ changes present in debian's git tree?
[23:20] <tormod> yes lots. additionally, the Debian tarball is not made from git it looks like
[23:21] <bryce_> urf
[23:22] <tormod> the ubuntu 7.6.0 tarball is the same as debian 7.6 tarball. however there are diffs between the bzr tree (autoextracted from package) and the git tree (outside debian tree)
[23:23] <tormod> bryce_, http://ubuntu.pastebin.com/d6ad766c2
[23:24] <bryce_> ok yeah I'm not sure what to do about those either
[23:24] <bryce_> glew.c?
[23:24] <tormod> yes these are things that doesn't really matter, it's just to get it MrClean
[23:24] <bryce_> the depend files are probably innocuous
[23:24] <bryce_> dunno what the glew stuff is, maybe jcristau can elaborate
[23:25]  * bryce_ --> lunch
[23:25]  * tormod --> bed