Only declare non-default options in gbp.conf.
compact commands (strip vertical space)
|Deletions are marked like this.||Additions are marked like this.|
|Line 124:||Line 124:|
|Line 126:||Line 125:|
|Line 128:||Line 126:|
|Line 130:||Line 127:|
|Line 132:||Line 128:|
|Line 140:||Line 135:|
|Line 142:||Line 136:|
|Line 144:||Line 137:|
|Line 150:||Line 142:|
|Line 152:||Line 143:|
|Line 154:||Line 144:|
|Line 160:||Line 149:|
|Line 162:||Line 150:|
|Line 168:||Line 155:|
|Line 170:||Line 156:|
|Line 176:||Line 161:|
|Line 178:||Line 162:|
|Line 193:||Line 176:|
|Line 195:||Line 177:|
|Line 201:||Line 182:|
|Line 203:||Line 183:|
|Line 210:||Line 189:|
|Line 212:||Line 190:|
|Line 226:||Line 203:|
|(uncomment compression line if upstream tarball(s) are not gzip-compressed)|
|Line 229:||Line 207:|
# Enable the following lines if the upstream tarball compression type is bzip2.
|sign-tags = True|
1. Develop Packaging
2. Packages maintained by the Debian Multimedia Team
Here you can find a list of packages maintained by the Debian Multimedia Team:
New packages should set the Maintainer field to Debian Multimedia Maintainers <email@example.com>. Existing packages should move to using that address on a best-effort basis.
All source packages shoud use the pkg-multimedia git area in alioth.
3. How to help with packaging
The Debian Multimedia Maintainers need help to create new Debian packages and maintain the existing ones. If you want to contribute to this effort, but you are new to the Debian packaging systems, here follows some information to get you started. Also see DebianMultimedia/Sponsoring for Best Practices with regard to obtaining sponsorship for your uploads if you are not a DD or DM.
3.1. Packaging guidelines
Packages should use git, as mentioned above. Desirable is being able to use git-buildpackage.
Upstream sources should be kept in the upstream branch and the the debian packaging in the master branch.
quilt should be used for patch management, and the master branch should only differ from the upstream branch in files inside the debian/ directory. This means no direct changes to the source in the master branch.
Patches should have a DEP-3 compliant header, and should be submitted upstream (if relevant) before uploading to Debian.
The maintainer field should be set to Debian Multimedia Maintainers <firstname.lastname@example.org>
The git repository should be hosted in alioth, under the pkg-multimedia project. It should forward commit messages to email@example.com and firstname.lastname@example.org
- You can use the setup-repository script in /git/pkg-multimedia to create the bare repository with commit messages enabled. The repository should be named as the source package name for the message forwarding to work (eg, the repository for source package liblo is named liblo.git).
- The control file should use the Vcs-Git and Vcs-Browser tags.
3.2. Workflow guidelines
One change per commit. This is very important, it eases review, cherry picking, bisecting (and thus debugging) and backporting.
Do not commit debian/changelog along with the changes. This practice makes cherry picking and backporting changes unnecessarily hard. The changelog is generated with git-dch(1) at the time of upload.
The commit message should have a short (<78 characters) summary of the change followed by a newline. After that, you can elaborate on the change. The summary is treated specially by various tools like git-dch(1), or the commitdiff mailer.
- After each upload to the Debian FTP servers, the first commit should be creating a new changelog entry, to ease testing of unreleased packages.
- Tags should be created (and signed) by the uploading DD, in the case of the debian tags in the master branch, and by the person importing the upstream sources in the case of upstream tags.
git-buildpackage online documentation (offline: /usr/share/doc/git-buildpackage/manual-html)
3.4. Proposing new packages for pkg-multimedia
If you are confident with your package, propose it for review on the pkg-multimedia-maintainers mailing list. Link to your package preferably in a way that can be easily used with ?dget. The debian mentors site is a good place.
- Members of the team will then review your package and give you hints how to improve it. If the package is "good enough" (at the reviewer's discretion), he will setup a repository on git.debian.org and integrate your package while preserving attribution.
3.5. Working on existing packages with git for newbies
As a very basic introduction, first read PackagingWithGit.
We generally follow the workflow and defaults of git-buildpackage
locate the packaging branch on http://git.debian.org. All pkg-multimedia branches have pkg-multimedia in their url. Click on the leftmost link in that line. That will bring you to the summary of the project.
- Note the metadata just above the shortlog, it contains 2 URLs, one of
them starting with git://
then git-clone(1) to get a copy of the repository. E.g.
$ git clone git://git.debian.org/pkg-multimedia/jack-audio-connection-kit.git
- Do changes to that branch, build the package, test your changes, and commit early and often!
- If someone else has committed while you are working on the branch, you need to integrate his changes. For this you have 2 options:
if your local changes are rather minor and clean, rebase when using git-pull(1):
$ git pull --rebase origin
- if you rather don't want to break your history because you think that your changes are rather large and are likely to interfere with the other changes, better merge them with:
$ git pull origin
In case you want to cleanup your local commits before pushing, use git-rebase(1):
$ git rebase -i origin/master
- You will be presented a textfile where you can specify what of your local commits you want to modify, drop or squish (merge with the previous one). You can also improve your commit message here. Make sure that you don't rewrite already published commits.
In order to get comments on your (preferably cleaned up) commits, use git-format-patch(1) to generate patches of your commits and email them to the mailing list. Any committer can do this while preserving attribution.
- None of the steps above require membership in the pkg-multimedia alioth group. All of that can be done totally anonymously!
4. Common tasks for team members
4.1. Uploading proposed package to the team git repository
- First create a repository on git.debian.org:
$ ssh git.debian.org /git/pkg-multimedia/setup-repository <project>
- Then import the sources locally, register the remote archive and push your commits (i.e. upload changes) with the following commands:
$ cd /path/to/sources/ $ git-import-dsc --pristine-tar <project>_0.0.1-1.dsc $ cd <project> $ git remote add alioth ssh://email@example.com/git/pkg-multimedia/<project>.git $ git push alioth master upstream pristine-tar --tags
4.2. Uploading new upstream version to existing repository
- Updating a git branch
$ git checkout master $ git pull
- update local branches without switching to them
$ git remote update $ git fetch alioth upstream:upstream pristine-tar:pristine-tar
- merging a new upstream version
$ git-import-orig --pristine-tar /path/to/<package>_0.0.1.orig.tar.bz
resolve merge conflicts, review your changes e.g. with gitk
$ git commit
- pushing new revisions
$ git push alioth master upstream pristine-tar --tags --dry-run
- if happy, remove the --dry-run parameter
Assumptions in all cases
- in the source tree
- the remote 'alioth' is setup properly
4.3. Removing/Adding debian tags to repository
- Removing debian tag
$ git tag -d debian/0.0.1-1
- Adding debian tag
$ git tag [-a|-s] "debian/0.0.1-1" -m "Debian release 0.0.1-1"
-s (or -u <key>) for GPG-signed tag
- -a for unsigned tag
$ git push alioth master
- Replacing a previously set tag:
$ git tag -f [-a|-s] "debian/1.2.3-1" -m "Debian release 1.2.3-1"
4.4. Common configuration options
These parameters should be placed in the debian/gbp.conf file. (uncomment compression line if upstream tarball(s) are not gzip-compressed)
[DEFAULT] pristine-tar = True sign-tags = True #compression = bzip2
If you adopt the dpkg source format 3.0 (quilt) you should consider appending the following line to the .gitignore file:
Work in progress : We're checking all the WNPP bugs and updating infos on this page.