On Feb 11, 2016, at 09:09 AM, Ross Gammon wrote: >I was working last night on fixing the RC bug for tweepy, but got myself >in a muddle with git-dpm. Yep, git-dpm will do this some times. :/ >Tweepy is currently 3.4.0 & 3.5.0 is a new available release. I cloned, >fixed the bug (just disabling the unit test), confirmed it was fixed and >then looked at packaging 3.5.0 as a team upload. But git-dpm seemed to >be unaware of 3.4.0 (claiming that 3.1.0 was the right tarball), that >there were non-debian changes in the debian branch and wouldn't let me >import 3.5.0. So I gave up on 3.5.0, and started trying to work out what >was wrong with 3.4.0 in git-dpm. Occasionally I find it necessary to blow away a clone and start over, but even then, git-dpm sometimes does mysterious things. (This is one of several reasons I'm beginning to sour on it, though it works just fine in the majority of cases.) One thing I've found is that import-new-upstream will sometimes not record the pristine-tar, even if you use --ptc. It seems like this can happen if you also --rebase and are required to resolve some conflicts. After finally git-dpm u-p'ing the pristine-tar will not have been recorded. Though you have to remember to do it, it's easy enough to pristine-tar commit the new orig.tar.gz after the fact. The main thing is that when you update to a new upstream, be sure to git-dpm status (and/or prepare) to be sure everything's okay before you start to work on further changes on top of the new upstream. Another gotcha is that if you `git clone` the repo, you won't actually have a pristine-tar or upstream tracking branch, and this will break git-dpm. Much better to use `gbp clone` which does the clone and then assures you have the local tracking branches. If you do git clone, just be sure to checkout the pristine-tar branch before you start working on things (and upstream too, though this matters less in practice). (Aside: I'm not sure I'd say that disabling a unit test counts as a "fix" ;) I don't know if any of the above is relevant for your case. I've seen git-dpm do weird things like take a single commit in the patches branch and turn it into a quilt patch where the diff is present *twice*. I think this was for a simple fix in pyparsing (trying to change distutils.setup() into setuptools.setup() in the setup.py), and though I tried a ton of different things, I was never able to get git-dpm to generate a correct quilt patch file. >At this point, I somehow merged pristine-tar into master :-( You'll be way better off restarting from a fresh clone than trying to fix your busted one. That way leads to madness. ;) Cheers, -Barry
Attachment:
pgpVzFCBkevVp.pgp
Description: OpenPGP digital signature