[00:49] <bryce> erf
[00:49] <bryce> $ git push
[00:49] <bryce> Password: 
[00:49] <bryce> To ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git
[00:49] <bryce>  ! [rejected]        debian-unstable -> debian-unstable (non-fast forward)
[00:49] <bryce> error: failed to push some refs to 'ssh://bryce-guest@alioth.debian.org/git/pkg-xorg/xserver/xorg-server.git'
[00:50] <bryce> ubottu: don't worry I'd never think that
[03:36] <pwnguin> heh
[05:51] <tjaalton> bryce: git push origin ubuntu doesn't work?
[05:54] <tjaalton> sigh
[05:54] <tjaalton> I wonder how many lrm bugs are due to people booting the old kernel
[05:54] <tjaalton> bug 226993 surely was
[07:40] <bryce> tjaalton: hmm $ git push origin ubuntu
[07:40] <bryce> Password: 
[07:40] <bryce> Everything up-to-date
[07:44] <tjaalton> you are on the ubuntu branch?
[07:44] <bryce> well it looks like it...  there are ubuntu changes in the debian/changelog file
[07:45] <tjaalton> git status
[07:45] <bryce> $ git status
[07:45] <bryce> # On branch ubuntu
[07:45] <bryce> nothing to commit (working directory clean)
[07:46] <tjaalton> hmh
[07:48] <bryce> anyway, I think it's ok
[07:48] <tjaalton> you have changes to push?
[07:49] <bryce> no, I was just doublechecking that my last commit (a few weeks ago) actually made it
[07:49] <tjaalton> ah
[07:49] <tjaalton> git.debian.org shows it
[07:49] <tjaalton> http://git.debian.org/?p=pkg-xorg/xserver/xorg-server.git;a=shortlog;h=refs/heads/ubuntu
[14:22] <munckfish> bryce: I'm just about to test the patch you pointed me to, but one of the existing patches (166_fix_lpl_monitors.diff) is failing to apply in the git ubuntu branch
[14:22] <munckfish> Is it ok for you?
[14:23] <munckfish> it affects hw/xfree86/modes/xf86EdidModes.c so I don't think it's clashing with the closedir() fix we added last
[14:25] <munckfish> hah, it's way too early in his timezone for him to be around yet! :D
[14:30] <jcristau> yeah, that patch doesn't apply
[14:31] <munckfish> jcristau: hi, yes it's just a different comment
[14:31] <munckfish> an extra line of commnt
[14:44] <munckfish> nope I'm wrong there's more to it than that :(
[14:45] <jcristau> yes, upstream commit 08afc70513e5496cc5cd8b76c8658c4292119e4b
[14:46] <munckfish> by upstream you mean debian, or x?
[14:46] <jcristau> x
[14:46] <munckfish> ok
[14:47] <munckfish> jcristau: what should I really be working against here? I followed the X/GitUsage tut, but should I be working on debian-unstable branch? should I have pulled from debian-unstable into my ubuntu branch?
[14:49] <jcristau> i don't know. what are you trying to do?
[14:49] <munckfish> I'm trying to test out your non_pci_autoconfig.diff for ubuntu hardy xorg
[14:49] <jcristau> if you're just trying to test the ubuntu package, you're doing the right thing, but you got unlucky because of that broken patch
[14:50] <munckfish> LP 217647
[14:51] <munckfish> jcristau: ok. I'll cont as is. I presume best course of action is to pull that upstream change into a patch under debian/patches
[14:51] <jcristau> munckfish: remove patch 166 from debian/patches/series and you should be able to build the package
[14:51] <munckfish> but if I do that, I may as well ...
[14:51] <munckfish> yeah
[14:51] <munckfish> good point
[14:51] <munckfish> thx
[14:51] <jcristau> np
[14:51] <munckfish> :)
[14:54] <munckfish> BTW do you happen to know if it's possible to cross-compile as I build the xorg-server package?
[14:56] <jcristau> no idea
[15:08] <munckfish> is it common practice to cherry pick patches and then integrate them a little later?
[15:08] <jcristau> integrate how?
[15:08] <munckfish> well 
[15:09] <munckfish> if they don't apply successfully, but they've been committed
[15:09] <munckfish> then at some point
[15:09] <munckfish> someone has to go thru and fix them so they do
[15:09] <munckfish> so that a release can be made
[15:09] <munckfish> that's what I mean
[15:09] <jcristau> well. i usually try not to do that :)
[15:09] <munckfish> ok
[15:10] <munckfish> so, in my case this non_pci .... patch, 
[15:10] <munckfish> it's against a newer version of the codebase from upstream
[15:11] <munckfish> even with the patches cherrypicked back into debian and ubuntu
[15:11] <munckfish> it doesn't apply
[15:11] <munckfish> (matchDriverFromFiles appears to be from a later refactoring)
[15:11] <jcristau> ah, right.
[15:12] <munckfish> should I be looking to modify the patch so it works against our code
[15:12] <munckfish> or
[15:12] <munckfish> should I look to pull down more patches from above
[15:12] <munckfish> or should I ... do something else :)
[15:12] <jcristau> let me have a look
[15:12] <munckfish> ok
[15:13] <munckfish> thx, I'll try to speed you on your way ...
[15:13] <munckfish> patch http://launchpadlibrarian.net/13978744/non_pci_autoconfig.patch
[15:15] <munckfish> I hope to get up to speed with how things work round here then I will cause minimum fuss
[15:15] <jcristau> doesn't seem applicable
[15:15] <munckfish> Bit too different? right
[15:17] <munckfish> so, now I will consider creating my own patch against our customised code, maybe with same intent as this upstream one
[15:17] <munckfish> thx for looking
[15:17] <jcristau> the bug that patch fixes doesn't exist in the version in hardy
[15:17] <munckfish> yes
[15:17] <jcristau> as far as i can tell
[15:18] <munckfish> ok
[15:19] <munckfish> actually there's two issues here really
[15:19] <munckfish> first is
[15:19] <munckfish> the crash I reported in that bug
[15:19] <munckfish> originally I think that was cause NOT havig PCI info was an untested path through this code
[15:19] <munckfish> PS3 doesn't appear to have PCI info
[15:20] <munckfish> so it brought out this crash
[15:20] <munckfish> 2nd issue is
[15:20] <munckfish> once the crash is resolved X then goes on to choose the vesa driver instead of fbdev
[15:20] <munckfish> which is wrong
[15:21] <jcristau> yeah. do you have a log for that?
[15:21] <munckfish> I presumed that non_pci patch may do something to help
[15:21] <jcristau> nah. it doesn't.
[15:21] <jcristau> it fixes another crash :)
[15:22] <munckfish> LP 217647 has logs for both with an xorg and without. Both times it chooses the wrong driver
[15:22] <munckfish> I think Bryce suggested it as an alternative for the closedir patch
[15:24] <munckfish> So ... I tell you what I'm going to just dig into this and understand the code a bit better. I'm sure I can come up with a fix, it'll be simple I'm sure.
[15:26] <jcristau> yeah, the code in chooseVideoDriver() is supposed to fall back to fbdev on ppc, but that part is probably not much tested
[15:26] <jcristau> so if you can step through what's going on in there, you should be able to come up with a fix
[15:27] <munckfish> I seem to remember seeing some codes further up the stack using preprocessor defines to decide on a default fallback
[15:27] <munckfish> it must be doing the wrong thing somehow
[15:27] <munckfish> thx!