Using git for team packages
- Creating new repositories
- Creating a new package
- Checking out an existing package
- Ensure up-to-date
- New upstream release
- Cherry picking upstream commits
- Sponsoring, mentoring, reviewing
- Pull requests
- Converting git-dpm to gbp pq
- Packages no longer maintained by DPMT
- More information and resources
Using git for team packages
On 2018-02-24, the DPMT and PAPT transition to Git for version controlling all of our packages has been complete. See below for details, workflow, policies, etc. Write access to the subversion repos has been TURNED OFF! You can still access them in read-only mode. We welcome back all Python (modules and app) developers who have moved their packages away from the team because of our previous use of subversion!
There are many advantages to team-based package development. The DPMT and PAPT have very excellent, knowledgeable, and experienced Python and Debian developers and our goal is to bring the very best Python experience to Debian users and developers. We're here to help each other and provide consensus (if not 100% agreement) on best practices. Collaboration has many benefits, and one of the things that aids effective collaboration is common tools and workflows surrounding packaging, while still providing individual maintainers the freedom to adapt those practices to their preferences, and the peculiarities of the packages.
One of the perks of being in a team is that all of our packages are managed in a similar way, using similar tools and workflows. This is great because any team member can immediately get the source of a package to do an update or a bug fix, and they don't have to first try to figure out how the package is version controlled. Plus, we can have nice wiki documentation which help new team members how to do things, and almost anyone on IRC can immediately give you advice. We use a common set of vcs procedures to ensure consistency among all of our packages. Both the DPMT and PAPT teams use the same version control system, layout, and workflows. -- The DPMT team migrated to Git on 2015-10-09, while the PAPT migrated on 2018-02-24.
It is a team requirement that all packages be managed using the same version control system.
Most of our git-based workflow is provided by gbp (formerly git-buildpackage). On top of gbp there's the patch management regime. Most Debian developers are familiar with quilt for including Debian-specific patches to upstream pristine tarballs. While it's still possible to use quilt directly of course, there is a better way to integrate the best of the git world with quilt. Of the two predominant git-based patch regimes, the Debian Python team has chosen gbp pq.
Git Branch Names
As a team we are strongly recommending you use DEP-14 style branch names, specifically:
debian/master - The Debianized upstream source directory. IOW, this contains upstream source and a debian/ packaging directory. It is a source-full, patches-unapplied checkout.
pristine-tar - Contains the standard pristine-tar deltas.
upstream - The un-Debianized upstream source. This is what you get when you unpack the upstream tarball. This could also be upstream/<version> if required.
If you use other branch names, please have a good reason (not just personal preference, remember - take one for the team!), and you MUST document the differences in debian/README.source. The default branch names will help the repo interoperate better with other tools.
gbp pq creates a patch branch when you want to directly edit upstream source files for export to quilt patches, however this is for local use only and should not be pushed to remote servers.
Git Tag Names
There seems to be several tag styles in common use. However, we recommend using '/' as a separator, yielding tags like debian/0.2.0-1.
Recommended/required configuration settings
Both git itself and git-bp provide ways to configure defaults. Settings that are personal to you should live only in $HOME/.gitconfig or $HOME/.gbp.conf. Settings which affect how the team interoperates should live in <repo>/debian/gbp.conf so that anyone who checks out the branch will see the same settings.
Here are some common scenarios and use cases. There may be other ways to accomplish these tasks so if you find a more efficient way of doing something, please update these pages and discuss with the team via the debian-python mailing list. Feel free to add more use cases here too! Your experience is valuable.
Creating new repositories
To set up a new repository visit https://salsa.debian.org/python-team/modules/ and follow the 'new project' link. Enter the source package name as the project name and leave the visibility set to public.
Use these Vcs-* fields in the header of your debian/control file:
Vcs-Git: https://salsa.debian.org/python-team/modules/<srcpkgname>.git Vcs-Browser: https://salsa.debian.org/python-team/modules/<srcpkgname>
Replace <srcpkgname> with your source package name.
Creating a new package
First, initialize the project on salsa.debian.org to set up the bare repo that you will push your branch.
$ uscan # Download your package's upstream original tarball $ tar -xvf srcpkgname_1.0.orig.tar.gz $ cd srcpkgname_1.0 $ git init $ git checkout -b upstream $ git add . $ git commit -m "import srcpkgname_1.0.orig.tar.gz" $ pristine-tar commit ../srcpkgname_1.0.orig.tar.gz upstream $ git checkout -b debian/master
You'll now be left on the debian/master branch, i.e. the packaging branch. You'll also have upstream (raw tarball contents) and pristine-tar branch.
Fill in the rest of your debian/ directory, then do this:
$ git add debian/* $ debcommit # assuming you have a d/changelog entry, otherwise git commit
Checking out an existing package
Packages can be checked out individually, or managed as a group, with mr. It is configured to not checkout all the team packages by default, but easily manage the ones that are checkout out, collectively.
$ sudo apt install mr $ git clone email@example.com:python-team/tools/python-modules $ cd python-modules $ echo $PWD/.mrconfig >> ~/.mrtrust $ ./checkout PACKAGENAME # For each package you care about
if your username differs between your local machine and Salsa, then you can add this snippet to ~/.ssh/config:
Host salsa.debian.org User SALSA_USERNAME
To update the .mr-config file, run
$ git pull $ ./make-mrconfig
And if there are any, commit and push changes.
To update all your checked out packages, run
To check out packages individually, you might be able to just
$ debcheckout -a <srcpkgname>
but while the Vcs-* fields have been updated in the repository, new uploads with those fields still need to be done. In the meantime, you can:
$ gbp clone firstname.lastname@example.org:python-team/modules/<srcpkgname>.git
gbp clone is preferable to git clone because gbp clone ensures that you'll have all the remote tracking branches set up properly. You can still use git clone but you'll have to check out the pristine-tar and upstream branches yourself.
You might also want to add this handy little convenience to your ~/.gitconfig file:
[url "email@example.com:python-team/modules/"] insteadof = dpmt:
which allows you to do this:
$ gbp clone dpmt:srcpkgname.git
make sure you cd into the source directory.
Before doing anything on an existing repository, always always always ensure you have pulled in any changes:
$ gbp pull --redo-pq
If you always remember to do this, you reduce the risk of causing accidental git conflicts.
Note that the --redo-pq option will discard any local changes to your local patch queue, and replace with the patches from debian/patches.
Now you can build your package using whatever tools you like, including debuild, dpkg-buildpackage, and git-buildpackage.
Push your repo to salsa.debian.org:
$ git push --set-upstream firstname.lastname@example.org:python-team/modules/<srcpkgname>.git : --tags
At this point, I like to cd to a different directory and do a gbp clone email@example.com:python-team/modules/<srcpkgname>.git and then continue working from the <srcpkgname> directory. To prove that all the branches got pushed correctly, in this fresh clone, checkout the debian/master, pristine-tar, and upstream branches.
Once you've built and uploaded your package, you should tag the release.
$ gbp buildpackage --git-tag-only $ git push --tags
Alternately, if you want to sign your tags:
$ gbp buildpackage --git-tag-only --git-sign-tags $ git push --tags
New upstream release
You should import the patch queue first. For this to work correctly, debian/gbp.conf should already have the correct value debian-branch, otherwise gbp import-orig will merge to the wrong branch.
Using a debian/watch file (recommended):
$ gbp pq import $ gbp checkout debian/master $ gbp import-orig --pristine-tar --uscan
Note "gbp pq import" will switch to the wrong branch, and if not fixed then import-orig can do the wrong thing.
Using a tarball file:
$ gbp pq import $ gbp import-orig --pristine-tar /path/to/new-upstream.tar.gz -u 0.2
where 0.2 is the new upstream version number.
If the upstream tarball is already in the form packagename_version.orig.tar.gz (E.g. package_0.2.orig.tar.gz), then the -u option is not required.
Don't forget to update debian/changelog!
Rebase the patches:
$ gbp pq rebase $ gbp pq export
You will need to push the debian/master branch and also the upstream and pristine-tar branches.
$ git push origin : --tags
Patching (i.e. adding quilt patches) is easy. You import the patches to a git patch queue, edit the patch queue, then export back again.
In general, to patch your package do this:
$ gbp pq import Edit patches $ gbp pq export $ vim debian/changelog $ git add debian/changelog $ git add debian/patches/* $ git commit
Cherry picking upstream commits
Sometimes you need to cherry pick upstream commits, e.g. to fix a bug in the Debian version when upstream hasn't yet released a new version. A convenient way to do that, if upstream is developed in git, is to add a remote and cherry pick from that. For example:
$ git remote add upstream_repo git://example.com/foo.git $ git fetch upstream_repo $ gbp pq import $ git cherry-pick any_upstream_commit $ gbp pq export $ vim debian/changelog $ git add debian/changelog $ git add debian/patches/* $ git commit
Sponsoring, mentoring, reviewing
Converting git-dpm to gbp pq
Previously DPMT used git-dpm at the workflow. This section documents how to convert from git-dpm to gbp pq.
- Ensure all branches up to date.
- Unapply all patches
Delete debian/.git-dpm config file.
Set debian-branch value to debian/master in debian/gbp.conf
Commit to debian/master branch (use git branch -m master debian/master to rename the branch).
Update .git/config branch debian/master to refer to merge = refs/heads/debian/master.
- Refresh the patches.
On Salsa, set the default branch to the new debian/master branch.
Sample debian/gbp.conf file:
Sample steps to do the above (upstream branch will not be automatically checkout out locally):
gbp pull git read-tree --reset -u upstream git reset -- debian git checkout debian git rm debian/.git-dpm cat <<EOF > debian/gbp.conf [DEFAULT] debian-branch=debian/master EOF git add debian/gbp.conf git commit -m "Convert from git-dpm to patches unapplied format" git branch -m master debian/master git push origin -u debian/master
To refresh the patches:
gbp pq import gbp pq export dch -m "Refresh patches after git-dpm to gbp pq conversion" git add debian/patches/ git add debian/changelog debcommit
To make the new branch the default and delete the old branch:
- expand "General settings"
- select the new default branch
- expand "Protected branches"
- fix those settings
- delete the old master branch
Packages no longer maintained by DPMT
Packages repositories can be archived on Salsa by owners of the Python team namespace. If you want an obsolete repositories to be archived you will need to contact one of the owners and ask them to do it.
Q: What if I don't want to use gbp pq? A: Please be nice to your fellow teammates, and reconsider! We want team members to easily know what workflow to use, by common convention. In rare cases, if some deviation from the team default is required, you MUST have a good rationale, and both the reason and workflow MUST be documented in the README.source file.
Q: Source-full or source-less branches? A: Source-full branches please! There are lots of good reasons for this, including the ability to easily diff between upstream versions, say to double check that nothing untoward or undocumented has been added in a new upstream version. E.g. git checkout upstream and git diff upstream/0.11.3 would for example give you an overview of what's new in upstream's 0.11.4.
We require team maintained packages to contain the full upstream source, and we don't believe it will be an overwhelming performance or disk-space burden to do so. It is much easier to hack on packages, including generating the quilt patches, when a checkout of the repo gives you the full source. Source-less branches defeat much of the benefit of managing packages in git.
A:We will still require all team packages to be available on salsa.debian.org. Please do not host your team maintained packaging branches anywhere else; e.g. ?GitHub is not appropriate for the packaging branches because it is not free software. GitLab does have a free software Community Edition and someday it might be interesting to run one of those for DPMT or Debian-at-large, but for now please do not submit merge requests on gitlab.com.