tox has a new upstream so I decided to take the opportunity to A/B git-dpm and gbp-pq on a more complicated, but probably common task, simply stated:: upgrade to the new upstream, refresh the patches, handling any conflicts, and regenerate a source package for testing.
TL;DR: You can make things work with both workflows, but both are very picky about the order in which you do things. Documentation needs to be better too. I've formed my opinion on a way forward, which I'll describe in a follow up message. == git-dpm == Since tox is still maintained under svn, I wanted to jump start maintenance under git-dpm. For this experiment, I don't care about detailed history. There's no `git-dpm import-dscs --debsnap` so I wrote my own: $ git clone git://git.debian.org/users/barry/import-dscs.git will give you import-dscs.py which will effectively use snapshots to get all the uploaded versions and call `git-dpm import-dsc --ptc` in a loop (with tagging). Then it calls `git-dpm prepare` and the repo should be ready to go. Of course, my script could be doing stupid things. WARNING: import-dscs.py requires an unreleased bug fix to python3-apt, so you'll need to grab the python-apt git repo, build, and install the latest head, otherwise the snapshots will not be applied in the correct order. http://tinyurl.com/mjoms6h (You'll also need packages like pristine-tar, git-dpm, git-buildpackage, and devscripts.) In any case, now I do the following: $ git init toxdpm $ cd toxdpm $ .../import-dscs.py tox Right, so now its time to switch to the new upstream. git-dpm doesn't have a --uscan option, so: $ uscan $ git-dpm import-new-upstream --rebase ../tox_1.7.2.orig.tar.gz There will be merge conflicts, so you need to resolve those manually, calling `git add <file>` and `git rebase --continue` after each resolution. You may not know exactly how to resolve each conflict, but I don't think the details matter. Once everything's resolved: $ git-dpm update-patches leaves you on the master branch. Now *before* you try to build the source package, you must add a new d/changelog entry, otherwise git-buildpackage will build the old version, and the quilt stack won't apply cleanly. So: $ dch -v1.7.2-1 $ git-buildpackage --git-ignore-new --git-export=WC -S -us -uc (or commit and just `git-buildpackage -S -us -uc`) That gets you a source package, but the binary package FTBFS because one additional test cannot be run during the build process (there's a DEP-8 test for full coverage). Now though, you *must* commit or stash the d/changelog change. Here's where things get a little frustrating. What I need to do is patch a file to add a line that skips a test. I'd like to append that to the 0003- patch but it's not the top of the quilt stack (there's an 0004- patch). But this doesn't seem possible, and `git-dpm apply-patch` doesn't seem to do this. Besides, it's very inconvenient to name the full d/p/*.patch file you want to apply. What I really want is the equivalent of `quilt push`. The best it seems you can do is: $ git-dpm checkout-patched <hack, git commit> $ git-dpm update-patches The file is patched, but now I have an d/p/0005- file instead of a modified 0003- patch file. Sigh. git-buildpackage && sbuild && adt-run and everything passes. We're done. == gbp pq == gbp-pq seems *much* more finicky about how to get a new upstream with updated patches. If you do not do things in exactly the right order, your new upstream merge will be totally broken. Or, at least they were for me. I had a ton of trial-and-error before I got this incantation correct. git-buildpackage has the bootstrapping step built-in: $ gbp import-dscs --debsnap tox $ gbp pq import $ gbp pq export This renames the d/patches files, and you *must* do this before you try to update to a new upstream your you'll be screwed. If you do it out of order, `gbp pq import` and `gbp pq rebase` will either do nothing, do the wrong thing (e.g. delete d/patches with no renames), or fail (you'll get patch application conflict errors with no way left to resolve them). $ git add debian/patches/ $ git stat On branch master Changes to be committed: (use "git reset HEAD <file>..." to unstage) renamed: debian/patches/intersphinx_mapping.patch -> debian/patches/0001-intersphinx_mapping.patch renamed: debian/patches/hack-requires.patch -> debian/patches/0002-hack-requires.patch renamed: debian/patches/build-time-tests.patch -> debian/patches/0003-build-time-tests.patch renamed: debian/patches/de-google-ify.patch -> debian/patches/0004-de-google-ify.patch modified: debian/patches/series $ git commit -a -m"patch import/export" Now get the new upstream. $ gbp import-orig --uscan $ dch -v1.7.2-1 "New upstream release." $ git commit -a -m"New upstream release." Now we should be able to rebase the patches onto 1.7.2: $ gbp pq rebase (I largely resolve the merge conflicts in the same way as with git-dpm.) $ gbp pq export $ git commit -a -m"Rebase patches onto 1.7.2" As with git-dpm, I'll get FTBFS. One important thing to remember is that at this point, neither `gbp pq import` nor `gbp pq rebase` is appropriate. Instead use: $ gbp pq switch to get you into the patch-queue/master branch. After you fix the tests, you'll need to: $ git commit -a -m"Skip another test at build time." $ gbp pq export $ git add debian/patches $ git commit -m"Skip another test at build time." (Yes, two commits.) I suffer the same frustration as with git-dpm about adding this patch as an 0005- patch instead of being able to extend the 0003- patch. Cheers, -Barry
signature.asc
Description: PGP signature
