=== cjwatson_ [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-x
[12:13] <bryce> keescook: I've read through timo's xorg patch, and I didn't see anything to complain about, although this is still newish to me so some of the changes I don't have a good feel for
=== cjwatson [n=cjwatson@82-69-40-219.dsl.in-addr.zen.co.uk]  has joined #ubuntu-x
[12:18] <keescook> cool.  tepsipakki: hey, you're core-dev now aren't you?  upload whenever you're ready, I guess.  :)
[12:18] <bryce> keescook, I notice in the nv driver that debian made a change outside the debian directory (adding some codes for GeForce 8500 and 8600 cards), but there's no record of the change in the changelog
[12:19] <bryce> is there anything special I need to be doing here?
[12:20] <keescook> If they're new changes relative to the prior ubuntu build, I'd mention it in the changelog.  If those changes have been there for a while, I don't think it's worth mentioning (it was accidentally skipped some time ago..)
[12:20] <bryce> MoM flagged a conflict with it, but I'm not sure why since the debian change seems to simply add 3 lines
=== keescook goes to check
[12:22] <keescook> I think due to the #if/#endif, it make the area unpatchable
[12:23] <bryce> really? weird
[12:23] <keescook> I'm just guessing  :P
[12:24] <keescook> what I _really_ don't get is why it blew up on src/g80_ddc.c
[12:25] <bryce> it did?  I didn't see that file mentioned in the REPORT
[12:25] <keescook> http://merges.ubuntu.com/x/xserver-xorg-video-nv/REPORT
[12:26] <keescook>   C* src/g80_ddc.c
[12:26] <keescook>   C* src/g80_display.h
[12:26] <bryce> ahh, I was looking at DaD; it must be behind
[12:26] <keescook> oh, ignore DaD.  Now that MoM is working, just forget DaD ever happened.  :)
[12:26] <bryce> ah ok
[12:27] <bryce> wow, haven't seen C* before
[12:28] <keescook> that means it's an unresolvable full-file conflict.
[12:28] <keescook> but, like I said, I'm not clear on why...
[12:33] <bryce> yeah, those seem like pretty minor differences
[12:41] <bryce> I'm a little mystified where those came from though; both MoM and DaD were listing the same debian version, yet DaD didn't have this conflict
[12:42] <bryce> oh I see, Dad was using 1.2.0 as the base, whereas MoM used 1.2.2.1
[12:44] <keescook> wild, this merge is pretty confused in general.. the debdiff is showing all kinds of weirdness
[12:51] <bryce> greaat
[12:55] <keescook> I'm digging through it, and hopefully I should have a clean example for you in a moment...
[12:57] <bryce> ok cool
[01:06] <keescook> ah, the reason for the C* is because upstream took both patches, which made it hard to sort out which was "right" debian or ubuntu.  :)
[01:09] <keescook> bryce: okay, I've got nv merged.  do you want to work on your copy and compare notes, or do you want me to upload this and show you my resulting debdiff?
[01:10] <bryce> upload and show me your debdiff
[01:11] <bryce> meanwhile I've been looking at xutils-dev, which looks clean - MoM found no merge issues, so do I just run merge-genchanges, etc. from there?
[01:11] <bryce> or is this where I run requestsync ?
[01:12] <keescook> if it's a clean merge, MoM should have generated a .patch file that shows the differences
[01:12] <bryce> yup, just changelog entry and control file
[01:12] <bryce> (I'm not entirely sure why it didn't just automatically merge it)
[01:12] <keescook> if the only diff is the maintainers field, then you can do a requestsync
[01:13] <keescook> because even a clean merge needs humans to describe the remaining delta between debian and ubuntu, and sometimes a clean merge won't actually build.
[01:13] <keescook> (for example, when patches in debian/patches were taken upstream)
[01:13] <bryce> no, it also adds Conflicts: and Replaces: lines
[01:13] <keescook> in that case, I'd see if jcristau is interested in adding that, and then wait for it to appear in Debian do a requestsync from there.
[01:14] <keescook> in a perfect world, no merging will be needed because Debian and Ubuntu will always be on the same page.  :)
[01:14] <bryce> ah ok cool
[01:15] <keescook> bryce: http://people.ubuntu.com/~kees/xserver-xorg-video-nv_2.0.2-1ubuntu1.dsc.debdiff
[01:32] <bryce> jcristau: would you like me to email you this patch for xutils-dev?  Or should I post it to bugs.debian.org?
[01:34] <jcristau> either post it to the bts or email debian-x@l.d.o
[01:36] <bryce> ok, cool
[01:54] <bryce> kees, thanks for the debdiff, looks good, so basically you just created a new 102_ patch?
[01:54] <bryce> keescook, what did you do about 102-dont-call-nvsync-in-entervt.patch?
[02:04] <keescook> bryce: yeah, for the changes that were outside of the debian/ and due to seemingly previous ubuntu changes, I revert the change in the upstream, and created a patch to handle it in debian/patches
[02:04] <keescook> the 102-dont-call was taken upstream, and all its changes are already visible in the source tree
[02:04] <keescook> 100 and 101 are not, though.
[02:06] <bryce> ah, ok, I was curious why you numbered it 102_ rather than 103_?  Do we always just number from the last patch present?
[02:20] <keescook> the convention for the xorg stuff seems to be numbering starting at 100 and going up.  I tend to try and fill gaps where it makes sense.  Since this is the first upload for gutsy and the prior 102 was taken upstream, it seemed sensible to make the new patch 102 again.
=== bryce nods
[07:00] <tepsipakki> all the drivers which need replaces/conflicts have that change done to git.d.o
[07:01] <tepsipakki> they just need to be released to be able to sync them
[07:01] <tepsipakki> and -nv and rest; we should only have changes in debian/patches, nothing else
[07:02] <tepsipakki> of nv; 101 can be dropped
[07:02] <tepsipakki> it's been implemented upstream
[07:05] <tepsipakki> the debian changes outside debian/ are git pulls, and should be left as is, imho
[07:57] <tepsipakki> ..but looking at the diff that's the case ;)
[08:51] <bryce> heya tepsipakki!  :-)
[08:51] <tepsipakki> hey bryce