[med-svn] [Git][med-team/community/policy][master] Commiting html target as well to enable publishing
Andreas Tille
gitlab at salsa.debian.org
Tue May 15 13:21:36 BST 2018
Andreas Tille pushed to branch master at Debian Med / community / policy
Commits:
23556a50 by Andreas Tille at 2018-05-15T14:20:56+02:00
Commiting html target as well to enable publishing
- - - - -
1 changed file:
- + policy.html
Changes:
=====================================
policy.html
=====================================
--- /dev/null
+++ b/policy.html
@@ -0,0 +1,436 @@
+<?xml version="1.0" encoding="UTF-8"?>
+<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd"><html xmlns="http://www.w3.org/1999/xhtml"><head><meta http-equiv="Content-Type" content="text/html; charset=UTF-8" /><title>Debian Med Group Policy</title><meta name="generator" content="DocBook XSL Stylesheets V1.79.1" /></head><body><div class="article"><div class="titlepage"><div><div><h2 class="title"><a id="idm1"></a>Debian Med Group Policy</h2></div><div><div class="authorgroup"><div class="author"><h3 class="author"><span class="firstname">Andreas</span> <span class="surname">Tille</span></h3><span class="contrib">First review </span> <code class="email"><<a class="email" href="mailto:tille at debian.org">tille at debian.org</a>></code></div><div class="author"><h3 class="author"><span class="firstname">David</span> <span class="surname">Paleino</span></h3><span class="contrib">Initial writing </span> <code class="email"><<a class="email" href="mailto:d.paleino at gmail.com">d.paleino at gmail.com</a>></code></div><div class="author"><h3 class="author"><span class="firstname">Charles</span> <span class="surname">Plessy</span></h3><span class="contrib">Contributions in 2008 and 2011</span> <code class="email"><<a class="email" href="mailto:plessy at debian.org">plessy at debian.org</a>></code></div></div></div><div><p class="releaseinfo">
+ $ policy.xml rev. @REV@ - @DATE@ (@AUTHOR@) $
+ </p></div><div><p class="releaseinfo">
+ Source: https://salsa.debian.org/med-team/community/policy
+ </p></div></div><hr /></div><div class="toc"><p><strong>Table of Contents</strong></p><dl class="toc"><dt><span class="sect1"><a href="#introduction">Introduction</a></span></dt><dt><span class="sect1"><a href="#contribute">How to Contribute</a></span></dt><dd><dl><dt><span class="sect2"><a href="#membership">Membership</a></span></dt><dt><span class="sect2"><a href="#readings">Essential readings</a></span></dt><dt><span class="sect2"><a href="#meta">Contributing to this Policy</a></span></dt></dl></dd><dt><span class="sect1"><a href="#repositories">Repositories</a></span></dt><dd><dl><dt><span class="sect2"><a href="#source">Give me the source!</a></span></dt><dt><span class="sect2"><a href="#git-repository-structures">Common Git repository structures</a></span></dt><dt><span class="sect2"><a href="#git-tips">Git tips</a></span></dt><dt><span class="sect2"><a href="#updating-git-package">Updating a source package managed with Git</a></span></dt></dl></dd><dt><span class="sect1"><a href="#packaging">Packaging</a></span></dt><dd><dl><dt><span class="sect2"><a href="#packagingguidelines">Newcomer guidelines for building proper Debian packages</a></span></dt><dt><span class="sect2"><a href="#itp">Announcing intent to package</a></span></dt><dt><span class="sect2"><a href="#backports">Backports</a></span></dt><dt><span class="sect2"><a href="#ppa">PPA for Ubuntu</a></span></dt><dt><span class="sect2"><a href="#sidonubuntu">Debian unstable chroot on Ubuntu</a></span></dt><dt><span class="sect2"><a href="#derivatives">Derivatives working together with Debian Med</a></span></dt><dt><span class="sect2"><a href="#r-packages">R packages</a></span></dt></dl></dd><dt><span class="sect1"><a href="#tasks">Tasks</a></span></dt><dt><span class="sect1"><a href="#policy">Policy</a></span></dt><dd><dl><dt><span class="sect2"><a href="#debian-control"><code class="filename">debian/control</code></a></span></dt><dt><span class="sect2"><a href="#debian-copyright"><code class="filename">debian/copyright</code></a></span></dt><dt><span class="sect2"><a href="#debian-changelog"><code class="filename">debian/changelog</code></a></span></dt><dt><span class="sect2"><a href="#debian-upstream"><code class="filename">debian/upstream</code></a></span></dt><dt><span class="sect2"><a href="#debian-gbp.conf"><code class="filename">debian/gbp.conf</code></a></span></dt><dt><span class="sect2"><a href="#debian-readme-source"><code class="filename">debian/README.source</code></a></span></dt><dt><span class="sect2"><a href="#debian-readme-test"><code class="filename">debian/README.test</code></a></span></dt><dt><span class="sect2"><a href="#debian-source-format"><code class="filename">debian/source/format</code></a></span></dt><dt><span class="sect2"><a href="#debian-source-option"><code class="filename">debian/source/options</code></a></span></dt><dt><span class="sect2"><a href="#debhelper">Debhelper</a></span></dt><dt><span class="sect2"><a href="#vcs">Version control systems</a></span></dt><dt><span class="sect2"><a href="#new-package">New package</a></span></dt><dt><span class="sect2"><a href="#new-packages-in-tasks">The Debian Med Blend tasks</a></span></dt><dt><span class="sect2"><a href="#building-and-tagging">Building and tagging the packages</a></span></dt><dt><span class="sect2"><a href="#patches">Handling patches</a></span></dt></dl></dd><dt><span class="sect1"><a href="#faq">FAQ</a></span></dt><dd><dl><dt><span class="sect2"><a href="#autobuilder">What to do if a large package does not build on a specific autobuilder architecture?</a></span></dt></dl></dd></dl></div><div class="mediaobject" align="center"><img src="/img/debian-med.jpg" align="middle" /></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="introduction"></a>Introduction</h2></div></div></div><p>Debian Med is a <span class="quote">“<span class="quote"><a class="ulink" href="https://blends.debian.org/blends" target="_top">Debian Pure Blend</a></span>”</span>
+ with the aim to develop Debian into an operating system that is particularly
+ well tailored for the requirements for medical practice and research.</p><p>The Debian Med project presents packages that are associated
+ with medicine, pre-clinical research, and life sciences. Its developments
+ are mostly focused on three areas for the moment: medical practice,
+ imaging and bioinformatics.</p><p>Over the previous years, several initiatives have spawned that
+ address the scientific disciplines like chemistry or bioinformatics.
+ Debian Med is not a competition to these efforts but a platform to
+ present the packages to the community as a Debian Pure Blend.</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="contribute"></a>How to Contribute</h2></div></div></div><p>From the developer to the user, there is a long chain of tasks
+ in which we always welcome participation. First we must keep ourselves
+ informed about the software landscape in biology and medicine. Software
+ to be packaged is chosen according to criteria such as users' need and
+ the consistency of the distribution.</p><p>Once in Debian, the software is monitored for its quality and bugs
+ are fixed, if possible in collaboration with the upstream maintainer(s).
+ All this work would not be very useful if it remains confidential.</p><p>We also dedicate some time to advertise it to the world via
+ <a class="ulink" href="https://www.debian.org" target="_top">www.debian.org</a>
+ and to ease the integration of new members.</p><p>Please contact us on <a class="ulink" href="mailto:debian-med at lists.debian.org" target="_top">debian-med at lists.debian.org</a>
+ if you want to help to make medical and biological software available
+ to Debian users. Read the <a class="link" href="#membership" title="Membership">Membership</a> section if you're
+ interested in joining us.</p><p>If you speak a language other than English, you can contribute
+ rightaway with translations of package descriptions at
+ <a class="ulink" href="https://ddtp.debian.net" target="_top">ddtp.debian.net</a>.</p><p>When working on these, you will find immediate targets for improvements
+ of the original English versions, too. For these, though, you need access
+ to Debian Med's source code repository. Very welcome are tutorials that
+ guide Debian users towards the use of packages to their immediate benefit.
+ You may also consider to write respective articles for Magazines, be they
+ online or in print.</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="membership"></a>Membership</h3></div></div></div><p>To request membership to this group, please go on our
+ <a class="ulink" href="https://salsa.debian.org/med-team/" target="_top">page on Salsa</a>,
+ or directly follow this <a class="ulink" href="https://salsa.debian.org/groups/med-team/-/group_members/request_access" target="_top">link</a>.
+ Remember that you must have an account on Salsa.debian.org before requesting
+ membership (see <a class="ulink" href="https://salsa.debian.org/users/sign_in" target="_top">here</a>
+ to request an account on Salsa.debian.org).</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="readings"></a>Essential readings</h3></div></div></div><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>The <a class="ulink" href="https://www.debian.org/doc/debian-policy/" target="_top">Debian Policy</a>: packages must conform to it.</p></li><li class="listitem"><p>The <a class="ulink" href="https://www.debian.org/doc/developers-reference/" target="_top">Developers Reference</a>: details best packaging practices.</p></li><li class="listitem"><p>The <a class="ulink" href="https://www.debian.org/doc/maint-guide/" target="_top">New Maintainer's Guide</a>: puts a bit of the two above in practice.</p></li><li class="listitem"><p>The <a class="ulink" href="https://debian-med.alioth.debian.org/docs/policy.html" target="_top">Debian Med Policy</a> (this document): explains how the work is organised in our team.</p></li></ul></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="meta"></a>Contributing to this Policy</h3></div></div></div><p>
+ This policy is itself maintained in Git and all team members have write access
+ to its repository.
+ </p><pre class="programlisting">
+ <span class="command"><strong>git clone git at salsa.debian.org:med-team/community/policy.git</strong></span>
+ Make changes to policy.xml commit and push.
+ Publish using the following command:
+ <span class="command"><strong>make publish</strong></span>
+ </pre><p>
+ </p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="repositories"></a>Repositories</h2></div></div></div><p>We use Git repositories, hosted
+ by Debian. You can have a look at each repository through
+ <a class="ulink" href="https://salsa.debian.org/groups/med-team/" target="_top">Salsa's web interfaces</a>.</p><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="source"></a>Give me the source!</h3></div></div></div><p>
+ To check the sources of a package (referred as
+ <span class="emphasis"><em><package></em></span> below) in our repositories, use the
+ <span class="command"><strong>debcheckout</strong></span> command, from the
+ <a class="ulink" href="https://packages.debian.org/devscripts" target="_top">devscripts</a>
+ package.
+ </p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p>
+ If you are a member of Debian Med or a Debian developer, with
+ account name <span class="emphasis"><em><username></em></span>, you have
+ write permission.
+ </p><p>
+ If the package is already in the archive:</p><pre class="programlisting">
+<span class="command"><strong>debcheckout</strong></span> <code class="option">--user</code> <em class="replaceable"><code><username></code></em> <code class="option">--git-track <em class="replaceable"><code>'*'</code></em></code> <em class="replaceable"><code><package></code></em></pre><p>
+ </p><p>
+ For draft packages that are only on Salsa:</p><pre class="programlisting">
+<span class="command"><strong>gbp</strong></span> <code class="option">clone</code> <em class="replaceable"><code><username></code></em> <em class="replaceable"><code>git at salsa.debian.org:med-team/<package>.git</code></em></pre><p>
+ </p><p>
+ For packages managed with Git, the option <code class="option">--git-track</code>
+ ensures that the clone has all the branches tracked. This is
+ needed when using the <a class="link" href="#git-buildpackage" title="gbp buildpackage">gbp buildpackage</a>
+ helper. Alternatively to <span class="command"><strong>debcheckout</strong></span>, the command
+ <span class="command"><strong>gbp clone</strong></span> will also track the relevant branches:</p><pre class="programlisting">
+<span class="command"><strong>gbp clone</strong></span> <em class="replaceable"><code>git at salsa.debian.org:med-team/<package>.git</code></em></pre><p>
+ </p></li><li class="listitem"><p>
+ For read-only access with <span class="command"><strong>debcheckout</strong></span>, remove
+ the <code class="option">--user</code> option. With <span class="command"><strong>gbp clone</strong></span>,
+ use an anonymous URL like the following:</p><pre class="programlisting">
+<span class="command"><strong>gbp clone</strong></span> <em class="replaceable"><code>https://salsa.debian.org/med-team/<package>.git</code></em></pre><p>
+ </p></li></ul></div><p>
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="git-repository-structures"></a>Common Git repository structures</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-buildpackage"></a><span class="command"><strong>gbp buildpackage</strong></span></h4></div></div></div><p>
+ Most of our packages using Git and stored on Salsa are managed following
+ the standard layout of the <span class="command"><strong>gbp buildpackage</strong></span> helper. The
+ <code class="literal">master</code> branch contains the full source package.
+ The <code class="literal">upstream</code> branch contains the upstream source,
+ after repacking when necessary (non-free files, large convenience code
+ copies, …). The <code class="literal">pristine-tar</code> contains the data
+ necessary to recreate an original tarball from the repository with a
+ reproducible checksum.
+ </p><p>
+ Debian releases are tagged with names like
+ <code class="literal">debian/debianversion</code> and upstream releases are
+ tagged with names like <code class="literal">upstream/upstreamversion</code>.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-without-tarball"></a>Social Git</h4></div></div></div><p>
+ For some projects, like the ones hosted on <a class="ulink" href="https://www.github.com" target="_top">GitHub</a> or <a class="ulink" href="https://www.gitlab.com" target="_top">GitLab</a>, it may be easier to
+ forward changes made in the Debian package if this one is itself
+ mirrored on the same platform, as a clone. In that case, the layouts
+ may vary from package to packages, and the branch that contains the
+ Debian work will probably not be the master one. If it is not the
+ <a class="link" href="#git-change-default-branch" title="To change the default branch.">default branch</a>, It must
+ be indicated in the <a class="link" href="#vcs-url" title="Vcs-Git: and Vcs-Browser:">VCS URL</a> with the
+ <code class="option">-b</code> option.
+ </p><p>
+ Even when you are not using <span class="command"><strong>gbp buildpackage</strong></span>,
+ please include a <a class="link" href="#debian-gbp.conf" title="debian/gbp.conf"><code class="filename">debian/gbp.conf</code></a>,
+ to document the layout of the repository.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-branches"></a>Other branches</h4></div></div></div><p>
+ Changes uploaded to other distributions than <code class="literal">unstable</code> can be stored in other branches, named for instance <code class="literal">experimental</code>, <code class="literal">stable</code>, etc.
+ </p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="git-tips"></a>Git tips</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-options-devscripts"></a>Set the <span class="package">devscripts</span> variables
+ <code class="varname">DEBEMAIL</code> and <code class="varname">DEBFULLNAME</code></h4></div></div></div><p><span class="command"><strong>debcheckout</strong></span> will then set
+ <span class="command"><strong>git</strong></span>'s options <code class="varname">user.email</code> and
+ <code class="varname">user.name</code> accordingly.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="debcheckout-sets-git-options"></a>Configure Git to commit using your packager name and address.</h4></div></div></div><p>The <code class="option">--global</code> option is to say Git these are the default parameters for every Git repository you commit to,
+ without it the settings will be per-repository only:</p><p>
+</p><pre class="programlisting">
+<span class="command"><strong>git config</strong></span> <code class="option">[<span class="optional">--global</span>]</code> <code class="option">user.name "$DEBFULLNAME"</code>
+<span class="command"><strong>git config</strong></span> <code class="option">[<span class="optional">--global</span>]</code> <code class="option">user.email "$DEBEMAIL"</code></pre><p>
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="new-repository-with-gbp"></a>To create a new local git repository</h4></div></div></div><p>Before you create a new git repository you probably want to check whether your target project just exists.
+ In the Gitlab interface of <a class="ulink" href="https://salsa.debian.org/med-team/" target="_top">Salsa</a> you can seek
+ for software packaged by the Debian Med team.
+ </p><p>When the upstream sources are distributed as compressed <span class="command"><strong>tar</strong></span> archives (<code class="literal">tar.gz</code>, …):</p><pre class="programlisting">
+<span class="command"><strong>mkdir</strong></span> <code class="filename">package</code>
+<span class="command"><strong>cd</strong></span> <code class="filename">package</code>
+<span class="command"><strong>git init</strong></span>
+<span class="command"><strong>gbp import-orig</strong></span> <code class="option">--pristine-tar</code> <code class="filename">/path/to/package_version.orig.tar.gz</code>
+<span class="command"><strong>git clone https://salsa.debian.org/med-team/community/package_template.git /tmp/package_template</strong></span>
+<span class="command"><strong>mv /tmp/package_template/debian . ; rm -rf /tmp/package_template</strong></span></pre><p>
+ </p>
+ The above steps will create a repository with the appropriate layout for <span class="command"><strong>gbp buildpackage</strong></span>, with three branches:
+ <code class="literal">master</code> (where the Debian development will happen),
+ <code class="literal">pristine-tar</code> used by the <code class="literal">pristine-tar</code> tool during the package build process to recreate the original tarball,
+ and <code class="literal">upstream</code>, which will contain the upstream source.
+ </div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="debcheckout-git-track"></a>To clone and follow every branch of a git repository.</h4></div></div></div><p>When the package is already in the Debian archive, you can use the
+ <span class="command"><strong>debcheckout</strong></span> command with its
+ <span class="command"><strong><code class="option">--git-track='*'</code></strong></span> option.
+ </p><p>To update the <code class="literal">upstream</code>, <code class="literal">master</code> and <code class="literal">pristine-tar</code> branches at once, use the <span class="command"><strong>gbp pull</strong></span>.</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-track-new-branches"></a>To track extra upstream branches, simply check them out.</h4></div></div></div><p>With recent versions of git, the remote branch will be automatically tracked when running <span class="command"><strong>git</strong></span> checkout. For example, when a <code class="literal">pristine-tar</code> branch is available upstream and not yet tracked locally, the command <span class="command"><strong>git checkout</strong></span> <code class="option"><em class="replaceable"><code>pristine-tar</code></em></code> will implicitly run the command <span class="command"><strong>git branch</strong></span> <code class="option">-t <em class="replaceable"><code>pristine-tar</code></em> <em class="replaceable"><code>origin/pristine-tar</code></em></code>.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-missing-pristine-tar"></a>To create a pristine-tar branch when it is missing.</h4></div></div></div><p>
+ See the <a class="ulink" href="https://honk.sigxcpu.org/projects/git-buildpackage/manual-html/gbp.import.html" target="_top">documentation of git-buildpackage</a>
+ for details. Use a similar command for any other missing branch.
+ </p><pre class="programlisting">
+<span class="command"><strong>git checkout</strong></span> <code class="option">--orphan</code> <em class="replaceable"><code>upstream</code></em>
+<span class="command"><strong>git rm</strong></span> <code class="option">-rf</code> <em class="replaceable"><code>.</code></em>
+<span class="command"><strong>git commit</strong></span> <code class="option">--allow-empty</code> <code class="option">-m</code> <em class="replaceable"><code>'Initial upstream branch.'</code></em>
+<span class="command"><strong>git checkout</strong></span> <code class="option">-f</code> <em class="replaceable"><code>master</code></em>
+</pre><p>
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="create-git-repository-on-salsa"></a>Creating a new repository on Salsa</h4></div></div></div><p>Before pushing to salsa.debian.org for the first time, an empty repository needs to be created there in the Gitlab interface.
+ </p><p>
+ Each package is kept in its own Git repository.
+ Now, on your local machine add the salsa repository as a remote:</p><pre class="programlisting">
+<span class="command"><strong>git remote add</strong></span> <code class="literal">origin</code> <code class="filename">git at salsa.debian.org:med-team/<pkg>.git</code>
+</pre><p>
+</p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-change-default-branch"></a>To change the default branch.</h4></div></div></div><p>
+ If the Debian work is not on the <code class="literal">master</code> branch, change
+ the default branch by editing the <code class="filename">HEAD</code> file in the
+ bare repository on Salsa, and replace <code class="literal">master</code> by the
+ name of the new default branch. For a branch called <code class="literal">debian/unstable</code>
+ the contents of the file will <code class="literal">refs/heads/debian/unstable</code>.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="push-package-to-salsa"></a>To push the package.</h4></div></div></div><p>(make sure you've added the salsa remote!), do the
+ following: <code class="code"><span class="command"><strong>git push</strong></span> <code class="option">origin
+ master</code></code>. For the first push, it's necessary to specify
+ <code class="option">origin master</code>. The next time you will push, a
+ <span class="command"><strong>git push</strong></span> will suffice.
+ Or use the <code class="literal">--set-upstream</code> option, helps future use of git pull.</p><pre class="programlisting">
+<span class="command"><strong>git</strong></span> push --set-upstream
+</pre><p>
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-push-all-tags"></a>To push all your work</h4></div></div></div><p>Be sure to also do a run <span class="command"><strong>git push</strong></span> with
+ <code class="option">--all</code>, and one with <code class="option">--tags</code> if you
+ created new tags.
+</p><pre class="programlisting">
+<span class="command"><strong>git</strong></span> push --all --set-upstream
+<span class="command"><strong>git</strong></span> push --tags
+</pre><p>
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-tag-release"></a>To tag a release</h4></div></div></div><p><code class="code"><span class="command"><strong>git tag</strong></span> <code class="option">debian/x.y-z</code></code>.
+ You can also easily retroactively make tags:
+ <code class="code"><span class="command"><strong>git tag</strong></span> <code class="option">debian/x.y-z</code> <code class="option"><commit hash></code></code>.
+ Remember to <code class="code"><span class="command"><strong>git push --tags</strong></span></code>.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-debian-version-from-commit"></a>If upstream manages his sources with Git.</h4></div></div></div><p>
+ The following makefile script can help producing a version number when
+ no Git tag is available:</p><pre class="programlisting">
+SOURCEPKG=$(shell dpkg-parsechangelog | sed -n 's/^Source: \(.*\)/\1/p')
+UPSTREAM=$(shell dpkg-parsechangelog | sed -n 's/^Version: \(.*\)-[^-]*/\1/p')
+SHA1=$(lastword $(subst ~g, ,$(UPSTREAM)))
+ORIG=${SOURCEPKG}_${UPSTREAM}.orig.tar.gz
+
+describe-current-version:
+ git describe --tags upstream | sed 's,^release-,,;s,-,+,;s,-,~,;'
+
+get-orig-source:
+ git archive --format=tar $(SHA1) | gzip -9 > ../$(ORIG)</pre><p>
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="git-pbuilder"></a>To make <span class="command"><strong>gbp buildpackage</strong></span> build the package with <span class="command"><strong>pdebuild</strong></span>.</h4></div></div></div><p>
+ Add the following to the configuration file
+ <code class="filename">~/.gbp.conf</code> or
+ <code class="filename">debian/gbp.conf</code>:</p><pre class="programlisting">
+[DEFAULT]
+builder = ~/bin/git-pbuilder
+
+pristine-tar = True
+</pre><p>
+ With this configuration file you're specifying that
+ <span class="command"><strong>gbp buildpackage</strong></span> will use
+ <code class="filename">~/bin/git-pbuilder</code> as the builder script.
+ This is an example script you can use:</p><pre class="programlisting">
+#!/bin/sh
+set -e
+
+pdebuild --pbuilder cowbuilder --debbuildopts "-i\.git -I.git $*"
+rm ../*_source.changes</pre><p>
+ This will build the package inside the default cowbuilder chroot,
+ while passing any more parameters directly do
+ <span class="command"><strong>dpkg-buildpackage</strong></span>.
+ </p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="updating-git-package"></a>Updating a source package managed with Git</h3></div></div></div><p>Most source packages maintained as Git repositories in Debian Med are using the <span class="command"><strong>gbp buildpackage</strong></span> helper toolkit. In doubt, try this one first.</p><p><span class="command"><strong>gbp buildpackage</strong></span>'s command <span class="command"><strong>gbp import-orig</strong></span> makes it easy to update of the <span class="emphasis"><em>upstream</em></span> branch using upstream releases distributed as a compressed archive, and to merge these changes in the <span class="emphasis"><em>master</em></span> branch. Its option <span class="command"><strong>--pristine-tar</strong></span> is useful for stabilizing the MD5 sum of the “<code class="filename">orig.tar.gz</code>” produced when building a source package from the repository alone (not doing so results in archive rejection of package updates). With recent versions of <span class="command"><strong>gbp buildpackage</strong></span>, it is often unnecessary to rename the freshly downloaded original upstream archive.</p><p>If you do not use <span class="command"><strong>gbp buildpackage</strong></span>, please use <span class="command"><strong>pristine-tar</strong></span> anyway to register the compressed archives that you upload to Debian as original upstream sources (the <code class="literal">orig.tar.{gz|bz2|xz}</code> file), with a command such as the following, where <code class="literal">tarball</code> is a path to the archive file and <code class="literal">tag</code> is the upstream release tag for that archive (as a fallback, if you created the tarball from a given branch, use the name of the branch).</p><pre class="programlisting">
+<code class="code"><span class="command"><strong>pristine-tar commit</strong></span> <code class="option">tarball</code> <code class="option">tag</code></code>
+</pre><p>Commit messages are sent to our commit mailing list with the <a class="ulink" href="https://github.com/mhagger/git-multimail/" target="_top">git-multimail</a>
+ tool. To avoid sending too many messages, consider setting the option
+ <code class="option">multimailhook.maxCommitEmails</code> to a low value, for instance
+ 20; the default is 500…</p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="packaging"></a>Packaging</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="packagingguidelines"></a>Newcomer guidelines for building proper Debian packages</h3></div></div></div><p>Some newcomers tend to go the create DEBIAN dir, move files around and `dpkg-deb -b` way to create
+ Debian packages. Short answer: Forget about this. The only way to the official Debian mirror leads
+ via proper source packages. The right way to build Debian packages is described in
+ <a class="ulink" href="https://www.debian.org/doc/manuals/maint-guide/" target="_top">Debian New Maintainers' Guide</a>.
+ </p><p>See also the <a class="ulink" href="https://salsa.debian.org/med-team/community/package_template" target="_top">package
+ template</a> on Salsa.
+ </p><p>There is also the option of joining the <a class="ulink" href="https://wiki.debian.org/DebianMed/MoM" target="_top">Mentoring
+ if the Month</a> as student to get a personal training how to start working inside the Debian Med team.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="itp"></a>Announcing intent to package</h3></div></div></div><p>If you intent to work on a Debian package you should follow
+ the <a class="ulink" href="https://www.debian.org/devel/wnpp/#l1" target="_top">normal Debian rules</a> and file a <acronym class="acronym">WNPP</acronym> bug report.</p><p>It is a good idea to keep the Debian Med mailing list
+ <a class="ulink" href="mailto:debian-med at lists.debian.org" target="_top">debian-med at lists.debian.org</a>
+ <a class="ulink" href="https://www.debian.org/Bugs/Reporting#xcc" target="_top"> in CC</a> and to set it
+ as the owner of the ITP to keep your co-workers informed. This will ensure that we notice
+ if for some reason the package has not been uploaded.</p><p>In addition, please add the package to the <span class="quote">“<span class="quote">task</span>”</span> file where it fits
+ the best, and document your ITP number using the <span class="command"><strong>WNPP</strong></span> field name.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="backports"></a>Backports</h3></div></div></div><p>
+ Debian offers <a class="ulink" href="https://backports.debian.org" target="_top">backports</a> to provide
+ up-to-date software for users of the official stable releases. Backports of Debian Med packages
+ should be kept as branches in our <a class="link" href="#git-repository-structures" title="Common Git repository structures">Git</a> repositories.
+ The branch should be named using the release code names. As an example, the backports branch for Debian 9 ("stretch")
+ should be named <code class="literal">debian/stretch-backports</code>, in accordance with
+ <a class="ulink" href="http://dep.debian.net/deps/dep14/" target="_top">DEP-14</a>.
+ If you are developing on Stable, make sure to get the <code class="literal">devscripts</code> package from stretch-backports for <code class="literal">dch --bpo</code> to set the version properly.
+ </p><p>
+ In Git, preparing a backport can be as simple as:
+ </p><pre class="programlisting">
+ <span class="command"><strong>git checkout debian/VESIONTAG</strong></span>
+ <span class="command"><strong>git checkout -b debian/stretch-backports</strong></span>
+ <span class="command"><strong>dch --bpo</strong></span>
+ </pre><p>
+ And then building the package using a Stable chroot after making any necessary adjustments to the packaging. See the
+ <a class="ulink" href="https://wiki.debian.org/BuildingFormalBackports" target="_top">wiki on backports</a> and
+ the <a class="ulink" href="https://backports.debian.org" target="_top">main backports website</a> for more detailed instructions.
+ </p><p>
+ When preparing subsequent versions of a backport, the changelog should
+ include all the changes since the previous backported version. You will want to make sure you set up
+ your cloned repository to use <code class="literal">dpkg-mergechangelogs</code> (from the <code class="literal">dpkg-dev</code>
+ package) to avoid getting unnecessary merge conflicts. See its manpage section "Integration with Git" for
+ how to set that up.
+ </p><pre class="programlisting">
+ <span class="command"><strong>git checkout debian/stretch-backports</strong></span>
+ <span class="command"><strong>git merge debian/TO_BE_BACKPORTED_VERSION</strong></span>
+ <span class="command"><strong>dch --bpo</strong></span>
+ </pre><p>
+ Now, you can try building against a Stable chroot.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="ppa"></a>PPA for Ubuntu</h3></div></div></div><p>
+ Debian Med operates a <a class="ulink" href="https://launchpad.net/~debian-med/+archive/ppa" target="_top">Personal Package Archive</a> (PPA) on Launchpad, where packages are backported for Ubuntu. There is currently no team policy on what to build.
+ </p><p>
+ Because the space in the PPA is currently limited (4.0 GiB), we keep in the PPA only packages for <a class="ulink" href="https://wiki.ubuntu.com/Releases" target="_top">still maintained</a> LTS Ubuntu version. Packages targeting an older Ubuntu will be removed.
+ </p><p>
+ Please keep in mind issues like the possibility to upgrade to the next Ubuntu stable release. Packages that are backports can be made <a class="ulink" href="https://www.debian.org/doc/debian-policy/#version" target="_top">inferior in version by using a tilde</a>. If the package contains additional development, a version number without the tilde will make it higher, but not as high as the next Debian revision. For example: <code class="code">2.12.0-1~natty1</code> (backport in PPA) < <code class="code">2.12.0-1</code> (from Debian in Ubuntu) < <code class="code">2.12.0-1natty1</code> (in PPA, containing additions) < <code class="code">2.12.0-2</code> (from Debian in Ubuntu).
+ Please follow the Ubuntu's <a class="ulink" href="https://help.launchpad.net/Packaging/PPA/BuildingASourcePackage#versioning" target="_top">recommendations</a> for versioning packages in PPA.
+ </p><p>
+ Packages sent to this PPA may be kept as branches in our repositories.
+ </p><p><a id="lintian-profile-ubuntu"></a>
+ Lintian checks are adapted to Ubuntu by setting the environment as follows: <code class="code">LINTIAN_PROFILE=ubuntu</code>.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="sidonubuntu"></a>Debian unstable chroot on Ubuntu</h3></div></div></div><p>
+ cowbuilder-dist sid create
+ cowbuilder-dist sid login
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="derivatives"></a>Derivatives working together with Debian Med</h3></div></div></div><p>
+ Debian Med is proud that derivatives (like for instance <a class="ulink" href="http://environmentalomics.org/bio-linux/" target="_top">Bio-Linux</a>) are profiting from our work inside Debian and we try to establish strong connections to these derivatives. With Bio-Linux the connection is as strong that a common workflow was created where Bio-Linux developers are injecting their packaging straight into the Debian Med version control system. To make sure that there will be no conflicts with the Debian revisions some attention should be payed to the revision numbering. If the derivative is creating a new package (either from scratch or an upgraded version) it should get the version <code class="code"><upstreamversion>-0<derivativename><derivativerevision></code> (which is the versioning scheme usually used by Ubuntu).
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="r-packages"></a>R packages</h3></div></div></div><p>
+ Debian R packages should be maintained within the <a class="ulink" href="https://wiki.debian.org/Teams/r-pkg-team" target="_top">Debian R Packages Team</a>.
+ </p><p>
+ <a class="ulink" href="https://packages.debian.org/r-base-core" target="_top">GNU R</a> sometimes introduces backward incompatibilities, so the current practice is to make packages depend on versions equal or higher to the one against which they were built. When using <code class="code">r-base-dev</code>, this can be acheived by adding the substitution variable <code class="code">${R:Depends}</code> in the <span class="emphasis"><em>Depends</em></span> field of the binary package.
+ </p></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="tasks"></a>Tasks</h2></div></div></div><p>The Debian Med <a class="ulink" href="https://blends.debian.org/blends" target="_top">Debian Pure Blend</a> is organised by <a class="ulink" href="https://blends.debian.org/med/tasks" target="_top">tasks</a>, that group packages around broad themes such as <a class="ulink" href="https://blends.debian.org/med/tasks/imaging" target="_top">medical imaging</a> for instance. The tasks list programs that are already packaged in Debian as well as packages in preparation.</p><p>The tasks files are not hosted in the Debian Med repositories, but in the Debian Blends repository. Nevertheless, all members of the Debian Med project on Salsa have write access to the Blends Git repository. You can easily check out its sources with the command <span class="command"><strong>debcheckout -a debian-med</strong></span>.</p><p>The syntax of the tasks files is very similar to Debian control files, and described in the <a class="ulink" href="https://blends.debian.org/blends/ch08.html#edittasksfiles" target="_top">Debian Blends website</a>.</p></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="policy"></a>Policy</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-control"></a><code class="filename">debian/control</code></h3></div></div></div><div class="orderedlist"><ol class="orderedlist" type="1"><li class="listitem"><p><strong>Section. </strong>Should be <span class="quote">“<span class="quote">science</span>”</span> for the source package.</p></li><li class="listitem"><p><strong>Priority. </strong>Should be <span class="quote">“<span class="quote">optional</span>”</span> unless forbidden by the Debian policy (<a class="ulink" href="https://www.debian.org/doc/debian-policy/#priorities" target="_top">see §2.5</a>). Packages of priority <span class="quote">“<span class="quote">extra</span>”</span> are excluded from some QA tests.</p></li><li class="listitem"><p><strong>Maintainer. </strong>Maintainer should be <code class="code">Debian Med Packaging Team <code class="email"><<a class="email" href="mailto:debian-med-packaging at lists.alioth.debian.org">debian-med-packaging at lists.alioth.debian.org</a>></code></code>. Please subscribe to this list if you list yourself in the <code class="code">Uploaders:</code> field of one of Debian Med's packages. You can refer to the <a class="ulink" href="https://qa.debian.org/developer.php?login=debian-med-packaging@lists.alioth.debian.org" target="_top">QA page</a> corresponding to this email to gather information about the packages.</p></li><li class="listitem"><p><strong>Uploaders. </strong>Please add yourself as an uploader when you have a significant interest in a package. Being Uploader means that you are expected to answer to the bug reports. For more occasional works, you can do a <a class="ulink" href="https://www.debian.org/doc/manuals/developers-reference/pkgs.html#nmu-team-upload" target="_top">team upload</a>.
+ </p></li><li class="listitem"><p><strong>Standards-Version. </strong>Please always use the latest unless there are concerns for backporting. If no changes are needed, please indicate this fact in the changelog, and increment the value of the field.</p></li><li class="listitem"><p><strong>Homepage. </strong>should be documented whenever possible</p></li><li class="listitem"><p><a id="vcs-url"></a><strong>Vcs-Git: and Vcs-Browser: </strong>Please use the following templates, and refer to the Debian Policy
+ <a class="ulink" href="https://www.debian.org/doc/debian-policy/#version-control-system-vcs-fields" target="_top">§ 5.6.26</a>
+ for details:</p><pre class="programlisting">
+Vcs-Browser: https://salsa.debian.org/med-team/<package>
+Vcs-Git: https://salsa.debian.org/med-team/<package>.git</pre><p>
+ </p></li><li class="listitem"><p><a id="testsuite"></a><strong>Testsuite: autopkgtest. </strong>
+ Field and value to declare that a testsuite compatible with
+ <a class="ulink" href="http://dep.debian.net/deps/dep8/" target="_top">autopkgtest</a>
+ is available. Such testsuite can be executed via the <span class="command"><strong>adt-run</strong></span>
+ command from the <span class="package">autopkgtest</span> package or the
+ <span class="command"><strong>sadt</strong></span> command from the <span class="package">devscripts</span>
+ package. Note that since <span class="command"><strong>dpkg</strong></span> version 1.17.6,
+ the <span class="emphasis"><em>XS-</em></span> prefix is not necessary anymore for
+ this field.
+ </p></li></ol></div><p>
+ It is a very good idea to use <span class="command"><strong>Config::Model</strong></span> to unify the formatting of <code class="filename">debian/control</code>.
+ To do so make sure you have installed
+ </p><p><span class="command"><strong>apt-get</strong></span><code class="option"> install cme libconfig-model-dpkg-perl</code></p><p>
+ and than you can simply call
+ </p><p><span class="command"><strong>cme</strong></span><code class="option"> fix dpkg-control</code></p><p>
+ to get a properly formated, sanity checked <code class="filename">debian/control</code> file. Please note that sometimes you need to
+ call this more than once. In case you want to use the cme GUI you also need to
+ </p><p><span class="command"><strong>apt-get</strong></span><code class="option"> install libconfig-model-tkui-perl</code></p><p>
+ which enables you to do something like
+ </p><p><span class="command"><strong>cme</strong></span><code class="option"> edit dpkg</code></p><p>
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-copyright"></a><code class="filename">debian/copyright</code></h3></div></div></div><p>
+ We use the <a class="ulink" href="https://www.debian.org/doc/packaging-manuals/copyright-format/1.0/" target="_top">machine-readable format</a> for the <code class="filename">debian/copyright</code> file. The <code class="computeroutput">Source</code> field does not need to contain the full URL to the particular version that is being packaged, since this can be determined by the <span class="command"><strong>uscan</strong></span> program with the <code class="filename">debian/watch</code> file (but note that some packagers use it as a bookmark to record when was the last copyright check). Please list yourself in the <code class="computeroutput">Files: debian/*</code> section if you think that your contributions are not trivial and therefore subjected to copyright. Please chose a license that is compatible with the program you package. You can also use <span class="quote">“<span class="quote">same as if it were in the public domain</span>”</span> or <span class="quote">“<span class="quote">same as the packaged program itself</span>”</span>.
+ </p>
+ You can create a <code class="filename">debian/copyright</code> file from scratch using
+ <p><span class="command"><strong>cme</strong></span><code class="option"> update dpkg-copyright</code></p><p>
+ Alternatively you can create some reasonable skeleton for a <code class="filename">debian/copyright</code> file you can try the following:</p><pre class="programlisting">
+<span class="command"><strong>sudo apt-get install</strong></span> <em class="replaceable"><code>devscripts</code></em> <em class="replaceable"><code>cdbs</code></em>
+<span class="command"><strong>licensecheck</strong></span> <code class="option">--copyright</code> <code class="option">-r <em class="replaceable"><code>`find -type f`</code></em></code> | <span class="command"><strong>/usr/lib/cdbs/licensecheck2dep5</strong></span> > <code class="filename">debian/copyright</code></pre><p>
+ </p><p>
+ To verify the correct syntax of the <code class="filename">debian/copyright</code> file you can use:</p><pre class="programlisting">
+<span class="command"><strong>cme </strong></span> <code class="option">check|fix|edit dpkg-copyright</code></pre><p>
+ from package <code class="filename">libconfig-model-dpkg-perl</code> (see above).
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-changelog"></a><code class="filename">debian/changelog</code></h3></div></div></div><p>Packages hosted in our Git repository, that have been modified but not uploaded must use <code class="literal">UNRELEASED</code> as a distribution name. This can be done automatically by declaring <code class="literal"><code class="varname">DEBCHANGE_RELEASE_HEURISTIC</code>=<em class="replaceable"><code>changelog</code></em></code> in <code class="filename">~/.devscripts</code> and using <span class="command"><strong>dch</strong></span>.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-upstream"></a><code class="filename">debian/upstream</code></h3></div></div></div><p>
+ We use the <a class="ulink" href="https://wiki.debian.org/UpstreamMetadata#Fields" target="_top">bibliographic information</a>
+ which should be stored in the file <code class="filename">debian/upstream</code>. The purpose of specifying this
+ is to enhance the contact to upstream which thus gets an extra reward of their work if their citations
+ show up on pages inside the Debian domain and if users more popularly are asked to cite upstream when
+ working with the program in question.
+ </p><p>
+ A new development are registries of research software (e.g. SciCrunch's RRID,
+ bio.tools, OMICtools). The metadata allows for references to publications
+ and entries in these registries alike.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-gbp.conf"></a><code class="filename">debian/gbp.conf</code></h3></div></div></div><p>
+ Include this file to document the layout of the repository. Packages managed
+ with <span class="command"><strong>gbp buildpackage</strong></span> may omit default values.</p><pre class="programlisting">
+[DEFAULT]
+# The default name for the upstream branch is "upstream".
+# Change it if the name is different (for instance, "master").
+upstream-branch = upstream
+# The default name for the Debian branch is "master".
+# Change it if the name is different (for instance, "debian/unstable").
+debian-branch = master
+# gbp import-orig uses the following names for the upstream tags.
+# Change the value if you are not using gbp import-orig
+upstream-tag = upstream/%(version)s
+# Always use pristine-tar.
+pristine-tar = True</pre><p>
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-readme-source"></a><code class="filename">debian/README.source</code></h3></div></div></div><p>This file is recommended by the Policy (<a class="ulink" href="https://www.debian.org/doc/debian-policy/#source-package-handling-debian-readme-source" target="_top">§ 4.14</a>) from version 3.8.0 for documenting source package handling. Please follow the recommendation. For instance, this file is needed when we use a patch system, when the upstream sources are in another format than gzipped tar archive, when we repack the sources,…</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-readme-test"></a><code class="filename">debian/README.test</code></h3></div></div></div><p>This file was (<a class="ulink" href="https://lists.debian.org/debian-devel-announce/2011/01/msg00006.html" target="_top">recommended by the Security team</a>) for describing to others than the regular maintainer how the package's functionality can properly be tested.</p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-source-format"></a><code class="filename">debian/source/format</code></h3></div></div></div><p>
+ This file sould contain <span class="quote">“<span class="quote"><code class="literal">3.0 (quilt)</code></span>”</span> in
+ order to use this source format. Other formats should be avoided unless
+ they bring a specific advantage.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debian-source-option"></a><code class="filename">debian/source/options</code></h3></div></div></div><p>
+ For packages not using <a class="link" href="#quilt" title="Using quilt">quilt</a> patches, for
+ example when committing changes directly to the Debian branch, this file
+ should contain <span class="quote">“<span class="quote"><code class="literal">single-debian-patch</code></span>”</span> in
+ order to emulate the <code class="literal">1.0</code> format. This is better than
+ using the <code class="literal">1.0</code> format directly because the <code class="literal">3.0
+ (quilt)</code> format brings other advantages, in particular the
+ conservation of file permissions in the <code class="filename">debian</code>
+ directory.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="debhelper"></a>Debhelper</h3></div></div></div><p>Debhelper uses compatibility levels to control the behaviour of its commands. We currently recommend to use the level <span class="emphasis"><em>10</em></span> which
+ is available in current <span class="emphasis"><em>Stable</em></span> and backported to <span class="emphasis"><em>Oldstable</em></span>. However, there is no urgent need to
+ touch packages only because it has an older Debhelper version.</p><p>
+ It is strongly recommended to use the short <span class="emphasis"><em>dh</em></span> notation in <code class="filename">debian/rules</code> files which makes code factorisation very
+ simple and easy to understand the packaging for other members of the team. Even complex packaging becomes quite transparent this way.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="vcs"></a>Version control systems</h3></div></div></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="vcs-git"></a>Source package stored in a Git repository on Salsa</h4></div></div></div><p>
+ Git repositories should be stored on <a class="ulink" href="https://salsa.debian.org/med-team/" target="_top">Salsa</a>.
+ </p></div><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="vcs-tags"></a>Tags</h4></div></div></div><p>
+ Tags indicate the revision corresponding to uploaded packages.
+ For a released package
+ <code class="literal">debian/</code> is added before the package version number.
+ </p></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-package"></a>New package</h3></div></div></div><p>
+ Try to inject a new package only after successfully building it with
+ <span class="command"><strong>dpkg-buildpackage</strong></span> (or any wrapper around it). Use a
+ file like <code class="filename">debian/DRAFT</code> to mention when the package
+ is a draft.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="new-packages-in-tasks"></a>The Debian Med Blend tasks</h3></div></div></div><p>
+ Once you injected a new package please make sure that it is mentioned
+ in the appropriate <a class="link" href="#tasks" title="Tasks">tasks</a> file in the Git
+ source of the <span class="package">debian-med</span> Blend package. Some team
+ members watch the changes in the Debian Med packaging pool but it helps
+ if the maintainer of a new package verifies that everything is in the
+ right place.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="building-and-tagging"></a>Building and tagging the packages</h3></div></div></div><p>
+ We prefer that uploaded packages are built in a chroot, to provide
+ similar build environment to the whole team. After upload, please <a class="link" href="#vcs-tags" title="Tags">tag</a>
+ the <a class="link" href="#git-tag-release" title="To tag a release">Git</a> repository.
+ </p></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="patches"></a>Handling patches</h3></div></div></div><p>
+ Often happens that the upstream code doesn't fit well into the
+ Debian distribution: be this wrong paths, missing features, anything
+ that implies editing the source files. When you directly edit
+ upstream's source files, your changes will be put into a .diff.gz file
+ if you use the <code class="literal">1.0</code> source format and in a monolithic
+ patch if you use the <code class="literal">3.0 (quilt)</code> format. To better
+ organise the patches and group the by function, please use a patch
+ handling system which keeps patches under the <code class="filename">debian/patches</code> directory.
+ </p><p>
+ The <code class="literal">3.0 (quilt)</code> Dpkg source format provides its own
+ patch system. You can use it with the <span class="command"><strong>quilt</strong></span> command.
+ </p><div class="sect3"><div class="titlepage"><div><div><h4 class="title"><a id="quilt"></a>Using <span class="command"><strong>quilt</strong></span></h4></div></div></div><p>Using quilt is rather easy.</p><p>First, make sure you have correctly setup quilt: open
+ <code class="filename">.quiltrc</code> in your home directory (create
+ it if you don't have one), and make sure it looks like this:</p><div class="blockquote"><blockquote class="blockquote"><pre class="programlisting">QUILT_DIFF_ARGS="--no-timestamps --no-index"
+QUILT_REFRESH_ARGS="--no-timestamps --no-index"
+QUILT_PATCHES="debian/patches"</pre></blockquote></div><p>
+ After this, you're ready to start working with quilt. See also the
+ instructions in the <a class="ulink" href="https://www.debian.org/doc/manuals/maint-guide/modify.en.html#quiltrc" target="_top">New
+ Maintainer's Guide</a>.
+ </p><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a id="quilt-create"></a>Creating a patch</h5></div></div></div><p>To create a patch, use the <span class="command"><strong>new</strong></span> command.
+ Run:</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt new</strong></span> <code class="filename"><patch_name>.patch</code>
+ </code></strong></p></blockquote></div><p>This will create (if it doesn't exist yet) a
+ <code class="filename">debian/patches/series</code> file, which
+ contains all the patches to be applied by quilt. Moreover,
+ the new patch is also the topmost (the currently
+ applied).</p><p>Now start editing files, with:</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt edit</strong></span> <code class="filename"><file></code>
+ </code></strong></p></blockquote></div><p>and repeat the process for each file the patch is
+ involved with. At the end, run</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt refresh</strong></span>
+ </code></strong></p></blockquote></div><p>This will compare the noted state of the edited files
+ with the current state, and will produce a patch in
+ <code class="filename">debian/patches</code>. Remember: the patch
+ is currently applied (you can check this with
+ <span class="command"><strong>quilt applied</strong></span>).</p><p>Make sure to write the patch header and use the
+ <a class="ulink" href="http://dep.debian.net/deps/dep3/" target="_top">DEP3 format</a>:</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt header -e --dep3</strong></span>
+ </code></strong></p></blockquote></div></div><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a id="quilt-apply"></a>Applying and unapplying patches</h5></div></div></div><p>Just two easy commands to do the job:</p><div class="itemizedlist"><ul class="itemizedlist" style="list-style-type: disc; "><li class="listitem"><p><span class="command"><strong>quilt pop</strong></span> will unapply the topmost patch.</p></li><li class="listitem"><p><span class="command"><strong>quilt push</strong></span> will apply the next patch in debian/patches/series.</p></li></ul></div><p>You can just add a "-a" flag to the commands above, to
+ respectively apply/unapply all patches in the series.</p><div class="tip" style="margin-left: 0.5in; margin-right: 0.5in;"><h3 class="title">Tip</h3><p>You can check which patches are applied/unapplied
+ with, respectively, <span class="command"><strong>quilt applied</strong></span> and
+ <span class="command"><strong>quilt unapplied</strong></span>.</p></div></div><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a id="quilt-edit"></a>Editing patches</h5></div></div></div><p>To edit a patch, first make it the topmost:</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt push</strong></span> <code class="filename"><patch_name></code>
+ </code></strong></p></blockquote></div><p>If the patch is already applied, but is not the topmost,
+ run <span class="command"><strong>quilt pop</strong></span> until it becomes the currently
+ applied one.</p><p>You can now run <span class="command"><strong>quilt edit</strong></span> on the files
+ you want to change, and, when you're done, <span class="command"><strong>quilt
+ refresh</strong></span>.</p></div><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a id="quilt-rename"></a>Renaming patches</h5></div></div></div><p>Sometimes it's useful to rename a patch. Without
+ any hassle, do:</p><div class="blockquote"><blockquote class="blockquote"><p><strong class="userinput"><code>
+ <span class="command"><strong>quilt rename -P</strong></span> <code class="filename"><old_name>.patch</code>
+ <code class="filename"><new_name>.patch</code>
+ </code></strong></p></blockquote></div></div><div class="sect4"><div class="titlepage"><div><div><h5 class="title"><a id="quilt-other"></a>Other commands</h5></div></div></div><p>Please see <span class="command"><strong>man 1 quilt</strong></span> to have a
+ comprehensive list of commands.</p></div></div></div></div><div class="sect1"><div class="titlepage"><div><div><h2 class="title" style="clear: both"><a id="faq"></a>FAQ</h2></div></div></div><div class="sect2"><div class="titlepage"><div><div><h3 class="title"><a id="autobuilder"></a>What to do if a large package does not build on a specific autobuilder architecture?</h3></div></div></div><p>Some of our target packages are large regarding memory consumption or requiring more computing power to build on not so powerful architectures.
+ Since the Debian autobuilder infrastructure consists of differently equiped hosts which are picked at random it might help to ask at
+ </p><div class="blockquote"><blockquote class="blockquote"><span class="command"><strong><arch>@buildd.debian.org</strong></span></blockquote></div><p>
+ to blacklist the weaker candidates.
+ </p></div></div></div></body></html>
\ No newline at end of file
View it on GitLab: https://salsa.debian.org/med-team/community/policy/commit/23556a50805f894fcb6f1047915ea144a5646c31
---
View it on GitLab: https://salsa.debian.org/med-team/community/policy/commit/23556a50805f894fcb6f1047915ea144a5646c31
You're receiving this email because of your account on salsa.debian.org.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://alioth-lists.debian.net/pipermail/debian-med-commit/attachments/20180515/dde5afbf/attachment-0001.html>
More information about the debian-med-commit
mailing list