Join GitHub today
GitHub is home to over 20 million developers working together to host and review code, manage projects, and build software together.
Fetching latest commit…
Cannot retrieve the latest commit at this time.
|Failed to load latest commit information.|
I learned this method from Bdale Garbee Note: These are mostly my (sconklin) personal notes. If they are helpful to you that's nice, but they aren't really intended to be high quality documentation. -- The tarball from upstream for d-rats contains a non-free (or questionable) executable. That needs to be stripped form the tarball bdale: I do all of my packaging in git, so I think about this in terms of git branch management. Before I used git for packaging, I did a lot of this "manually". So let me explain how I'd handle an upstream with non-free content in git and see if that makes sense to you? sconklin: yes, please. bdale: ok, so I'll use 'tar' as an example, because it's suitably complicated to cover all the interesting cases bdale: I have a branch structure that includes upstream, pristine-tar, dfsg-orig, dfsg-debian, doc-orig, and doc-debian branches to start bdale: when there's a new upstream release, I download the tarball, and import it into the upstream branch with commands like: bdale: git checkout upstream bdale: git-import-orig --no-merge --pristine-tar --upstream-version 1.23 ~/Desktop/tar-1.23.tar.gz bdale: this gets us the upstream 1.23 sources into the upstream branch, doesn't try to automatically merge them down anywhere, and puts the tarball into the pristine-tar branch .. bdale: then I want to merge this into the dfsg-orig branch, clean it of non-DFSG compliant stuff, and commit it... so I do something like: git checkout dfsg-orig git pull . upstream # See NOTE just below ./cleanup-script.sh git commit -a NOTE: In the case of d-rats, the cleanup script removed the directory libexec and the file in it, so this directory no longer exists on the dfsg-orig branch. Git ignores empty directories (and apparently those which do not exist), so when you do the pull that directory won't be created, and you don't need to run the cleanup script or commit. BUT - make sure nothing new has been added to that directory upstream. If it has, you'll have to get it. bdale: the cleanup-script.sh exists only in that branch, and basically removes the doc/ subtree followed by unpacking a shar containing a skeletal Makefile.in and README to keep the build system happy without further patching and explain to the naive what's going on bdale: so, now we move to the dfsg-debian branch, populate the debian/ directory, create a debian/gbp.conf that tells git-buildpackage to use dfsg-orig as the 'upstream' branch and dfsg-debian as the 'master' branch for packaging, and go for it.. since we don't have an orig.tar.gz matching our cleaned upstream, we create one like: git checkout dfsg-debian git pull . dfsg-orig - fix up merge conflicts - update debian/changelog git commit -a git-buildpackage --git-ignore-new --git-no-pristine-tar -S pristine-tar commit ../build-area/tar/tar_1.23.orig.tar.gz rm -r ../build-area/tar/* sudo cowbuilder --create # optional if needed the first time sudo cowbuilder --update git-buildpackage git tag debian/1.23-1 Now for Ubuntu: (Note: Ubuntu branches are temporary until debian is in place) git checkout dfsg-ubuntu git pull . dfsg-debian (fixup changelog) Note: Versioning for Ubuntu must be like this: 0.3.3~b5-lucid07 git-buildpackage --git-no-pristine-tar -S -sa And repeat for the dfsg-ubuntu-maverick branch bdale: sconklin: so you can see, I'm making use of git, git-buildpackage, and pristine-tar .. and the results are just stunningly productive once you get the mental firmware in place to just "do it" bdale: and by doing *all* of my package builds in cowbuilder, I never ever get caught with bad build-depends content on an upload... though the price I pay is waiting for the "populate a minimal chroot" to happen on every build. it's completely rational to use more efficient build cycles and just do this for things you're going to upload, but I'm OCD about it. bdale: for Debian packaging, using git.debian.org via the Alioth collab-maint thing can be a good choice bdale: I have enough other git stuff going that I tend to just use git.gag.com and let others cope, putting appropriate tags in the debian/control file to show where my packaging repo is, etc bdale: my only other suggestion, which I'm bad at following myself, is to put a debian/README.source or whatever it's called in place that does things like document the branching structure you're using and a canonical set of steps like those I pasted above. sconklin: easy, I can paste a chat log in as a start . . . ;-)