=== bryceh_ is now known as bryceh
=== bryceh is now known as bryce
[04:06] <fei> Hello,e'rbody
[04:06] <fei> I'm a kubuntu user from China
[04:07] <fei> anyone here?
[04:17] <fei> hi,dantti
[07:55] <RAOF> tjaalton: I don't think the nvidia/fglrx blacklists won't actually affect nouveau/ati.  They end up explicitly loading the kernel driver, which should bypass the blacklist, right?
[07:56] <RAOF> tjaalton: That said, doing that will likely race and will not necessarily do anything but make X explode as nouveau initialises before KMS is fully up, bails, and then VESA stomps all over KMS state.
[07:56] <tjaalton> RAOF: then why do they install the blacklist if it doesn't work ?-)
[07:56] <RAOF> tjaalton: Because it prevents *autoloading* by pciid.
[07:57] <RAOF> So without the blacklist there's a race between nvidia and nouveau kernel modules, and whichever loads first locks the other one out.
[07:57] <tjaalton> ok, so nouveau would load anyway if nvidia wouldn't autoload?
[07:58] <RAOF> Now that we no longer install an xorg.conf, I think the answer is “yes”.
[07:58] <tjaalton> ookay
[07:58] <RAOF> This sounds like a job for The Experimental Method™!
[07:58] <tjaalton> :)
[07:59] <RAOF> Although I don't think I've got a system fast enough to break with the kernel/DDX kms race.
[08:01] <RAOF> But first, to the running around!
[08:01] <tjaalton> i need to get my head around the race thingy, last week was the first time I heard about it
=== yofel_ is now known as yofel
[08:08] <RAOF> Which race?  The kms/DDX race?
[08:08] <tjaalton> that
[08:08] <tjaalton> you mean the xserver might start before kms is up?
[08:12] <RAOF> Yes, absolutely.
[08:12] <tjaalton> ugh..
[08:12] <RAOF> I'm *sure* I've seen you comment on bugs where this has happened :)
[08:12] <tjaalton> ok, bad memory then :)
[08:12] <RAOF> Particularly - if the module is blacklisted, then it'll only start to get loaded once X has loaded the DDX.
[08:12] <tjaalton> i do have an ssd system, though the cpu isn't on par with the disk
[08:15] <tjaalton> now that part i don't get, that how it'll still load the module if it's blacklisted
[08:15] <tjaalton> but I guess it's easy to test
[08:15] <tjaalton> if no nvidia, X will try nouveau, and then it would forcibly load nouveau.ko?
[08:16] <tjaalton> hmm right
[08:16] <tjaalton> modprobe.d blacklisting doesn't prevent 'modprobe foo' from working
[08:19] <tjaalton> maybe I'll delete the comment from the blueprint then
[08:20] <tjaalton> done
[08:21] <tjaalton> would be great to have a diagram of all the various ways to break the system, then it would be easier to plan the failsafe stuff so that it's more robust
=== ara_ is now known as ara
[10:21] <RAOF> tjaalton: :)
[13:51] <bryce> or some sort of artificial way of reproducing those conditions so we can write a test suite
[16:48] <cnd> bryce, tjaalton: do you know what the timeline is for an upload to natty-proposed for xorg-server?
[16:48] <cnd> I just got another email about the coordinate transformation bug that's waiting to be pushed
[16:49] <bryce> cnd, if you have a branch set up with the change I could upload it right now
[16:49] <cnd> bryce, it's up
[16:49] <cnd> ubuntu-natty
[16:49] <cnd> in the git repo
[16:50] <tjaalton> yeah fine by me to upload it now
[16:50] <cnd> cool
[16:56] <bryce> uploaded
[16:57] <cnd> bryce, ta
[17:04] <tjaalton> bryce: bad release :)
[17:06] <bryce> sigh
[17:12] <bryce> reuploaded
[17:12] <bryce> stupid git won't let me push the branch change
[17:14] <tjaalton> what does it say?
[17:15] <bryce> $ git push origin ubuntu-natty
[17:15] <bryce> To ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git
[17:15] <bryce>  ! [rejected]        ubuntu-natty -> ubuntu-natty (non-fast-forward)
[17:15] <bryce> error: failed to push some refs to 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git'
[17:15] <bryce> To prevent you from losing history, non-fast-forward updates were rejected
[17:15] <ubot4> bryce: Error: I am only a bot, please don't think I'm intelligent :)
[17:15] <bryce> Merge the remote changes (e.g. 'git pull') before pushing again.  See the
[17:15] <bryce> 'Note about fast-forwards' section of 'git push --help' for details.
[17:16] <tjaalton> have you done rebases on your local tree?
[17:16] <bryce> no, just git commit --amend
[17:18] <tjaalton> http://stackoverflow.com/questions/253055/how-do-i-push-amended-commit-to-the-remote-git-repo
[17:18] <tjaalton> it rewrites the history, so you need to force it
[17:19] <tjaalton> and don't amend in the future :)
[17:19] <tjaalton> if you've already pushed
[17:19] <tjaalton> maybe this is why things have failed in the past?
[17:23] <bryce> it's probably the source of the problem I had yesterday.  Didn't realize --amend was actually useless post-push
[17:23] <tjaalton> in this case forcing the update would only break my local three, but that's probably ok :)
[17:23] <bryce> no, I didn't want to do that, I just started over as a regular commit
[17:23] <tjaalton> and force that?
[17:24] <bryce> no force needed
[17:24] <tjaalton> ah, there it is
[17:25] <tjaalton> yeah looks good now
[17:25] <bryce> evidently I should hold off on pushing ;-)
[17:26] <tjaalton> on the contrary, more practice :)
[17:26] <bryce> how many years have I been using git?  it's still such a time sink for me
[17:26] <bryce> 1 minute to upload something, 30 min to fight git to let me commit it
[17:27] <tjaalton> do a change, dch, debcommit -a, git push origin
[17:27] <tjaalton> that's it, and don't use .patch but .diff for patches :)
[17:27] <tjaalton> so git status will complain loudly
[17:27] <tjaalton> about files not added to the branch
[17:28] <bryce> don't you have to do 'git push origin ubuntu'?
[17:28] <tjaalton> well yeah if you just want to push that branch, it'll just complain if the other branches are not uptodate
[17:28] <bryce> I dislike the idea of using .diff instead of .patch.
[17:28] <tjaalton> why?
[17:29] <tjaalton> they are in debian/patches, so the path tells they are patches
[17:30] <bryce> 'patch' is descriptive of what the file is, 'diff' just indicates how it was produced
[17:31] <bryce> seems like it would be better to just make git stop rejecting .patch files
[17:31] <tjaalton> besides, libxi git doesn't have the latest patch
[17:32] <tjaalton> bryce: that change would have to be made to every .gitignore where we have an ubuntu branch, not that practical
[17:34] <bryce> tjaalton, we typically add patches to only a handful, and could be done on a case-by-case basis as needed.  not that big of a deal
[17:36] <tjaalton> mmh, i don't like case-by-case decisions, it's either-or :)
[17:37] <bryce> actually looks like we can just add debian/patches/.gitignore with "!*.patch"
[17:37] <tjaalton> it's still ugly, for the sake of a postfix
[17:41] <bryce> aha, figured it out
[17:41] <bryce> can be set globally
[17:55] <tjaalton> that's good then
[18:26] <bryce> hmm, can be set globally but project level .gitignore always takes precedence :-/
[18:47] <tjaalton> bryce: ah..
[22:05] <tjaalton> i'll upload current xorg-server git to oneiric, need to get the patch there too