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