[website/master] Fix some typos in the REJECT-FAQS
Signed-off-by: Luca Falavigna <dktrkranz@debian.org>
---
REJECT-FAQ.html | 80 ++++++++++++++++++++++++++++---------------------------
1 file changed, 41 insertions(+), 39 deletions(-)
diff --git a/REJECT-FAQ.html b/REJECT-FAQ.html
index 2a6722a..87ffb5e 100644
--- a/REJECT-FAQ.html
+++ b/REJECT-FAQ.html
@@ -48,11 +48,11 @@
priority:</p>
<ul>
- <li>trying to keep the archive legal,</li>
+ <li>trying to keep the archive legal</li>
- <li>trying to keep the package namespace sane,</li>
+ <li>trying to keep the package namespace sane</li>
- <li>trying to reduce the number of bugs in Debian.</li>
+ <li>trying to reduce the number of bugs in Debian</li>
</ul>
<p class="text">Not all QA issues will be noticed; we don't test
@@ -61,18 +61,18 @@
email, sometimes it will result in a REJECT, depending on how serious the
issue seems.</p>
- <p class="text">Of course this does not take away the developers
- responsibility to do their own QA before upload. It's the maintainer who
- is responsible for everything that happens with a bad package, not the
- FTP Team!</p>
+ <p class="text">Of course this does not take away the developers'
+ responsibility to do their own QA before the upload. It's the maintainer
+ who is responsible for everything that happens with a bad package, not
+ the FTP Team!</p>
<p class="text">All items are things that <b>really</b> should never
happen anyway, but exist in some packages nonetheless. Visit this list
from time to time, as we may change points or add new ones.</p>
<p class="text">Note: This is a purely informational list, there may be
- more reasons. If there is a third column it states the date when the
- entry was added to this list.</p>
+ more reasons. The third column it states the date when the entry was
+ added to this list.</p>
<p class="text">If you want to make it easy for us, then please state
<b>why</b> you've added a NEW binary package or renamed a source package.
@@ -88,7 +88,7 @@
<td>OpenSSL</td>
<td>You have a GPL program linking with OpenSSL. This is only ok if
- upstream gave a license exception for this otherwise the two licenses
+ upstream gave a license exception for this, otherwise the two licenses
are incompatible. Visit <a href=
"http://www.openssl.org/support/faq.html#LEGAL2";>the OpenSSL FAQ</a>
or/and <a href=
@@ -109,7 +109,7 @@
Small overview: The <i>DEB_AUTO_UPDATE_DEBIAN_CONTROL</i> option
turned on modifies Build-Depends, which doesn't affect the build
that's running. But it affects all following builds, which can be
- NMU, buildd builds and worst case: security builds. You <b>DO
+ NMUs, buildd builds and worst case: security builds. You <b>DO
NOT</b> want to have such a build getting a different result
(except for the small changes intended with the build) just because
there is now another thing in the build-depends.<br />
@@ -120,7 +120,7 @@
<b>easy</b> and you can check them in pbuilder.</li>
<li>Do this only in a special target in debian/rules that is
- NEVER called automagically. So you can check what it did before
+ NEVER called automagically, so you can check what it does before
you start the real build.</li>
</ol>
</td>
@@ -138,7 +138,7 @@
<a href="http://lists.debian.org/debian-legal/2005/08/msg00128.html";>I've
mailed</a> our -legal list about that and got only one response,
which basically supported my view on this. Basically this license
- talks only about PHP, the PHP Group and <i>includes Zend Engine</i>,
+ talks only about PHP, the PHP Group, and <i>includes Zend Engine</i>,
so its not applicable to anything else. And even worse, older
versions include the nice ad-clause.<br />
One good solution here is to suggest a license change to your
@@ -153,17 +153,17 @@
<td>Be sure that you correctly document the license of the package.
We often find packages having a GPL COPYING file in the source, but
- if one goes and looks at every file there are a few here and there
+ if one goes and looks at every file, there are a few here and there
having different licenses in them, sometimes as bad as <i>You aren't
allowed to do anything with this file, and if you do we will send our
lawyers to you</i>. Of course it's hard to check a tarball with
thousands of files (think about X, KDE, Kernel or similar big
packages), but most of the tarballs aren't that big. Also not-nice is
a package, itself being GPL, having documentation licensed with a
- non-free license, like some CC licenses, makes the original tarball
+ non-free license, like some CC licenses: makes the original tarball
non-free. This is one of the cases where you need to repackage it
- (look in the archive for examples, mostly having .dfsg. in their
- tarballs name).</td>
+ (look in the archive for examples, mostly having "dfsg" in their
+ tarballs' name).</td>
<td> </td>
</tr>
@@ -241,12 +241,12 @@
<td>Your package builds binary packages not listed in
debian/control.
- While this is technically possible it is not allowed, all
- binaries need to be listed in your control file *prior* to the
+ While this is technically possible, it is not allowed: all
+ binaries need to be listed in your control file prior to the
build (ie. that information needs to be included in the uploaded
source). This mostly happens to kernel-module packages.<br />
- Now, if you follow Policy you have
+ In Debian Policy we have
<a href="http://www.debian.org/doc/debian-policy/ch-controlfields.html#s-sourcecontrolfiles";>
Section 5.2 (Source package control files -- debian/control)</a>
which says
@@ -291,14 +291,14 @@
</cite>
</p>
- Putting all of that together you can simplify it with
+ Putting all of that together, you can simplify it with
<em>debian/control has to contain a list of binaries to be built
<b>before</b> the build-process starts, do not modify that in
the running build-process.</em>
<hr/>
- Of course that makes life hard(er) for packages like kernel
+ Of course that makes life harder for packages like kernel
modules. But not that much. There is nothing to say against a
target in <i>debian/rules</i> that generates the control file
for you, <b>IFF</b> this is only run manually. And if you run in
@@ -324,7 +324,7 @@
debian/copyright must document when and how the license information was
obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from
http://example.net/license"; or reproduce email correspondence including
- some header) in addition to the reproducing the license itself.
+ some header) in addition to reproducing the license itself.
In the past there were uploads where one couldn't
find the license statement in the tarball or on the website from
upstream, which is bad.
@@ -355,7 +355,7 @@
<td>You most probably want to have some content in your package. From
time to time we find packages which don't have any. An example is a
- rename of a lib* package, but to miss updating the place where the
+ rename of a library package without updating the place where the
files are installed.</td>
<td> </td>
@@ -366,7 +366,7 @@
<td>It should really not violate policy, for example violating FHS.
Like installing libFOO.so in /usr/share, creating random new
- /pathentries or any other obvious policy violation.</td>
+ /pathentries, or any other obvious policy violation.</td>
<td> </td>
</tr>
@@ -386,9 +386,9 @@
<tr>
<td>Lintian</td>
- <td>Lintian errors and warnings, without a good reason to ignore them
+ <td>Lintian errors and warnings, without a good reason to ignore them,
can get you a reject. Sometimes there are valid reasons, but then you
- should either file a bug against lintian if it's generally wrong or
+ should either file a bug against lintian if it's generally wrong, or
include an override in your package, giving a reason in the changelog
for it.</td>
@@ -428,9 +428,9 @@
<td>Renaming source for DFSG-removals</td>
<td>Do not rename the source if you delete files that are not DFSG free.
- Instead add a .dfsg. somewhere to the version part to mark it. Renaming the source
- just confuses tools like the PTS who are source-package based, and also confuses
- users who cant simply fetch sources anymore without looking what source package
+ Instead add a "dfsg" somewhere to the version part to mark it. Renaming the source
+ just confuses tools like the PTS, which are source-package based, and also confuses
+ users, who can't simply fetch sources anymore without looking what source package
it is first.
</td>
@@ -461,7 +461,9 @@
<tr>
<td>Source missing</td>
<td>Your package contains files that need source
- but do not have it. These include PDF and PS files in the documentation.</td>
+ but do not have it. These include PDF and PS files in the documentation,
+ or auto-generated files.
+ </td>
<td>December 2008</td>
</tr>
<tr>
@@ -469,7 +471,7 @@
<td>Your package contains generated files (such as compressed .js libraries)
without corresponding original form. They're not considered as the
preferred form of modification, so you will either have to provide
- corresponding original form or remove them from your tarball, eventually
+ corresponding original form, or remove them from your tarball, eventually
depending on an already available packages to provide missing features.</td>
<td>October 2011</td>
</tr>
@@ -477,10 +479,10 @@
<td>Package uses <tt>waf</tt> as build system</td>
<td>That's a special case of <q>source code missing</q>. Normaly
packages using waf as build system contain a Python script
- with an compressed tarball embedded as a binary blob, where
+ with a compressed tarball embedded as a binary blob, where
it is not obvious how to get the actual source. As that's not
- considered to be the prefered form of modification that's considerer to
- fail the DFSG. See <a href="http://bugs.debian.org/645190";>#645190</a> and
+ considered to be the prefered form of modification, it fails
+ the DFSG. See <a href="http://bugs.debian.org/645190";>#645190</a> and
<a href="http://wiki.debian.org/UnpackWaf";>http://wiki.debian.org/UnpackWaf</a>
for details.</td>
<td>January 2012</td>
@@ -523,7 +525,7 @@
<td>Be sure to look for native/non-native build. Its easy to build a
package native because you had a spelling error in the upstream
- tarballs name. Simple solution: Whenever you have a -X in your
+ tarball's name. Simple solution: Whenever you have a -X in your
version number (ie a debian-revision) look if you have a .diff.gz
before you upload.</td>
@@ -535,7 +537,7 @@
<td>Do not add the third version of a lib/program. Get RID of them
instead. Always try to not have more than two version of a
- library/program in, and that also only if its needed due to a hard
+ library/program in, and that also only if it's needed due to a hard
transition to the newer one.</td>
<td>August 2005</td>
@@ -548,7 +550,7 @@
templates. As the name says: they are templates. Edit them, test your
package and then delete the whole bunch of commands that are
commented out, make it hard to read and do not help. If you later
- need anything: Type dh_[TAB][TAB] to see whats available.</td>
+ need anything: Type dh_[TAB][TAB] to see what's available.</td>
<td>August 2005</td>
</tr>
@@ -579,7 +581,7 @@
can simply run
<a href="http://packages.debian.org/help2man";>help2man</a> and have a working
start. Such easy ones are near to a reject. Yes, there are things in
- the archive where its hard to write manpages.</td>
+ the archive where it's hard to write manpages.</td>
<td>August 2005</td>
</tr>
--
1.7.10.4
Reply to: