[med-svn] r6376 - trunk/community/website/docs
Charles Plessy
plessy at alioth.debian.org
Wed Mar 23 23:01:14 UTC 2011
Author: plessy
Date: 2011-03-23 23:01:13 +0000 (Wed, 23 Mar 2011)
New Revision: 6376
Modified:
trunk/community/website/docs/policy.xml
Log:
Spellchecked.
Modified: trunk/community/website/docs/policy.xml
===================================================================
--- trunk/community/website/docs/policy.xml 2011-03-23 22:37:13 UTC (rev 6375)
+++ trunk/community/website/docs/policy.xml 2011-03-23 23:01:13 UTC (rev 6376)
@@ -113,17 +113,17 @@
the Subversion tags take a disproportionated size, when the maintainer is
much more comfortable with Git than Subversion, when some special features of
Git or git-buildpackage are desired, or more simply when the maintainer wants
- to thake the opportunity to familiarise with Git.
+ to take the opportunity to familiarise with Git.
</para>
<warning id="umask">
<para>
- For most direct operaitons on the repositories in Alioth, an <command>umask</command> of <literal>002</literal> is necessary to avoid problems of missing write permission to the other team members.
+ For most direct operations on the repositories in Alioth, an <command>umask</command> of <literal>002</literal> is necessary to avoid problems of missing write permission to the other team members.
</para>
</warning>
<sect2 id="source">
<title>Give me the source!</title>
<para>
- To check sources out from our repostitories, please do:
+ To check sources out from our repositories, please do:
<itemizedlist>
<listitem>
<para>
@@ -305,7 +305,7 @@
</para>
<para>
Debian releases are tagged with names like
- <literal>debian/debianversion</literal> and upstream relases are
+ <literal>debian/debianversion</literal> and upstream releases are
tagged with names like <literal>upstream/upstreamversion</literal>.
</para>
</sect3>
@@ -313,7 +313,7 @@
<title>Social Git</title>
<para>
For some projects, like the ones hosted on <ulink
- url="http://www.github.com">Github</ulink> or <ulink
+ url="http://www.github.com">GitHub</ulink> or <ulink
url="http://www.gitorious.com">Gitorious</ulink>, it may be easier to
forward changes made in the Debian package if this one is itself
hosted on the same platform, as a clone. In that case, the layouts
@@ -430,7 +430,7 @@
</para>
<para>
To make <command>git-buildpackage</command> builds the package with a
- chroot, you can add the folowwing to the configuration file <filename>~/.gbp.conf</filename> or <filename>debian/gbp.conf</filename>:<programlisting>
+ chroot, you can add the following to the configuration file <filename>~/.gbp.conf</filename> or <filename>debian/gbp.conf</filename>:<programlisting>
[DEFAULT]
builder = ~/bin/git-pbuilder
cleaner = fakeroot debian/rules clean
@@ -459,7 +459,7 @@
<para>There is no easy way to prepare a Git repository from our Subversion repository that would
look like the package was always managed in Git, because we use svn-buildpackage with the
mergeWithUpstream property set, which excludes the upstream sources. Nevertheless, the
- following receipe will genearate a Git repostitory that contains all the history of
+ following recipe will generate a Git repository that contains all the history of
the debian directory, plus a collection of selected upstream source releases.
</para>
<itemizedlist>
@@ -480,7 +480,7 @@
<sect2 id="updating-git-package">
<title>Updating a source package managed with Git</title>
<para>Most source packages maintained as Git repositories in Debian Med are using the <command>git-buildpackage</command> helper toolkit. In doubt, try this one first.</para>
- <para><command>git-buildpackage</command>'s command <command>git-import-orig</command> allows very easy update of the <emphasis>upstream</emphasis> branch when the original sources are distributed as a compressed archive. Its option <command>--pristine-tar</command> is useful for stablizing the MD5 sum of the “<filename>orig.tar.gz</filename>” produced when building a source package from the repository alone (not doing so results in archive rejection of package updates). With recent versions of git-buildpackage, it is often unnecessary to rename the freshly downloaded original upstream archive.</para>
+ <para><command>git-buildpackage</command>'s command <command>git-import-orig</command> allows very easy update of the <emphasis>upstream</emphasis> branch when the original sources are distributed as a compressed archive. Its option <command>--pristine-tar</command> is useful for stabilizing the MD5 sum of the “<filename>orig.tar.gz</filename>” produced when building a source package from the repository alone (not doing so results in archive rejection of package updates). With recent versions of git-buildpackage, it is often unnecessary to rename the freshly downloaded original upstream archive.</para>
</sect2>
</sect1>
<sect1 id="packaging">
@@ -540,7 +540,7 @@
<listitem>
<formalpara>
<title>Uploaders</title>
- <para>Please add yourelf 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 <ulink url="http://www.debian.org/doc/developers-reference/pkgs#nmu-team-upload">team upload</ulink>.
+ <para>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 <ulink url="http://www.debian.org/doc/developers-reference/pkgs#nmu-team-upload">team upload</ulink>.
</para>
</formalpara>
</listitem>
@@ -588,7 +588,7 @@
</sect2>
<sect2 id="debian-readme-source">
<title><filename>debian/README.source</filename></title>
- <para>This file is recommended by the Policy (<ulink url="http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource">§ 4.14</ulink>) 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 achive, when we repack the sources,…</para>
+ <para>This file is recommended by the Policy (<ulink url="http://www.debian.org/doc/debian-policy/ch-source.html#s-readmesource">§ 4.14</ulink>) 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,…</para>
</sect2>
<sect2 id="debhelper">
@@ -598,7 +598,7 @@
touch packages only because it has an older Debhelper version.</para>
<para>
It is strongly recommended to use the short <emphasis>dh</emphasis> notation in <filename>debian/rules</filename> files which makes code factorisation very
- simple and easy to understand the packaging for other members of the team. Even complex packaging becomes quite transparant this way.
+ simple and easy to understand the packaging for other members of the team. Even complex packaging becomes quite transparent this way.
</para>
</sect2>
@@ -636,7 +636,7 @@
linkend="create-git-repository-on-alioth"><command>setup-repository</command></link>
script available there. There, they must give write access to the
<literal>debian-med</literal> Alioth group and all the Debian
- Developers, with approporiate Unix permissions (including SGID bit on
+ Developers, with appropriate Unix permissions (including SGID bit on
directories) and ACLs. See <filename class="directory">/git/debian-med</filename>
itself as an example. <command>setup-repository</command> does this
automatically.
@@ -671,7 +671,7 @@
<title>The Debian Med Blend tasks</title>
<para>
Once you injected a new package please make sure that it is mentioned
- in the apropriate <link linkend="tasks">tasks</link> file in the SVN
+ in the appropriate <link linkend="tasks">tasks</link> file in the SVN
source of the <package>debian-med</package> 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
More information about the debian-med-commit
mailing list