<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.222 $">
+ <!ENTITY cvs-rev "$Revision: 1.229 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
(<file>disks-i386</file>, <file>disks-m68k</file>, etc.).
- <sect1>Sections
+ <sect1 id="archive-sections">Sections
<p>
The <em>main</em> section of the Debian archive is what makes up the
<strong>official &debian-formal; distribution</strong>. The
`testing-security', but read <ref id="bug-security"> for more information on
those.
<p>
-It is technically possible to upload a package into several distributions
-at the same time but it usually doesn't make sense to use that feature
-because the dependencies of the package may vary with the distribution.
-In particular, it never makes sense to combine the <em>experimental</em>
-distribution with anything else (see <ref id="experimental">).
+It is not possible to upload a package into several distributions
+at the same time.
<sect1 id="upload-stable">
<heading>Special case: uploads to the <em>stable</em> distribution</heading>
verbose, if necessary) in your changelog entries for uploads to
<em>stable</em>, because otherwise the package won't be considered for
inclusion.
+ <p>
+It's best practice to speak with the stable release manager <em>before</em>
+uploading to <em>stable</em>/<em>stable-proposed-updates</em>, so that the
+uploaded package fits the needs of the next point release.
<sect1 id="upload-t-p-u">
<heading>Special case: uploads to <em>testing-proposed-updates</em></heading>
<sect1 id="upload-ftp-master">Uploading to <tt>ftp-master</tt>
<p>
-To upload a package, you need a personal account on
-<ftpsite>&ftp-master-host;</ftpsite>, which you should have as an
-official maintainer. If you use <prgn>scp</prgn> or <prgn>rsync</prgn>
-to transfer the files, place them into &us-upload-dir;;
-if you use anonymous FTP to upload, place them into
-&upload-queue;.
- <p>
-If you want to use the feature described in <ref id="delayed-incoming">,
-you'll have to upload to <tt>ftp-master</tt>. It is the only upload
-point that supports delayed incoming.
+To upload a package, you should upload the files (including the signed
+changes and dsc-file) with anonymous ftp to
+<ftpsite>&ftp-master-host;</ftpsite> in the directory &upload-queue;.
+To get the files processed there, they need to be signed with a key in the
+debian keyring.
<p>
Please note that you should transfer
the changes file last. Otherwise, your upload may be rejected because the
archive maintenance software will parse the changes file and see that not
-all files have been uploaded. If you don't want to bother with transferring
-the changes file last, you can simply copy your files to a temporary
-directory on <tt>ftp-master</tt> and then move them to
-&us-upload-dir;.
- <p>
+all files have been uploaded.
+ <p>
<em>Note:</em> Do not upload to <tt>ftp-master</tt> cryptographic
packages which belong to <em>contrib</em> or <em>non-free</em>. Uploads of
such software should go to <tt>non-us</tt> (see <ref
<tt>ftp-master</tt>; depending on the case they may still be uploaded to
<file>non-US/non-free</file> (it's in non-free because of distribution issues
and not because of the license of the software). If you can't upload it to
-<tt>ftp-master</tt>, then neither can you upload it to the overseas upload
-queues on <tt>chiark</tt> or <tt>erlangen</tt>. If you are not sure
+<tt>ftp-master</tt>, then neither can you upload it to backup
+queues that finally also end up on <tt>ftp-master</tt>. If you are not sure
whether U.S. patent controls or cryptographic controls apply to your
package, post a message to &email-debian-devel; and ask.
<p>
You may also find the Debian packages <ref id="dupload"> or
<ref id="dput"> useful
-when uploading packages. These handy programs help automate the
+when uploading packages. These handy programs help automate the
process of uploading packages into Debian.
<p>
-After uploading your package, you can check how the archive
-maintenance software will process it by running <prgn>dinstall</prgn>
-on your changes file:
-<example>dinstall -n foo.changes</example>
- <p>
-Note that <prgn>dput</prgn> can do this for you automatically.
+For removing packages, please see the README file in that ftp directory,
+and the Debian package <ref id="dcut">.
<sect1 id="upload-non-us">Uploading to <tt>non-US</tt>
<p>
-As discussed above, export controlled software should not be uploaded
-to <tt>ftp-master</tt>. Instead, upload the package to
-<ftpsite>non-us.debian.org</ftpsite>, placing the files in
-&non-us-upload-dir; (again, both <ref id="dupload"> and <ref
-id="dput"> can do this for you if invoked properly). By default,
-you can use the same account/password that works on
-<tt>ftp-master</tt>. If you use anonymous FTP to upload, place the
-files into &upload-queue;.
+<em>Note:</em> non-us is currently not processed any more.
<p>
-You can check your upload the same way it's done on <tt>ftp-master</tt>,
-with:
-<example>dinstall -n foo.changes</example>
+As discussed above, export controlled software should not be uploaded
+to <tt>ftp-master</tt>. Instead, upload the package with anonymous FTP
+to <ftpsite>non-us.debian.org</ftpsite>, placing the files in
+&upload-queue; (again, both <ref id="dupload"> and <ref
+id="dput"> can do this for you if invoked properly).
<p>
Note that U.S. residents or citizens are subject to restrictions on
export of cryptographic software. As of this writing, U.S. citizens
residents consult a lawyer before doing uploads to non-US.
- <sect1>Uploads via <tt>chiark</tt>
- <p>
-If you have a slow network connection to <tt>ftp-master</tt>, there are
-alternatives. One is to upload files to <file>Incoming</file> via a
-upload queue in Europe on <tt>chiark</tt>. For details connect to
-<url id="&url-chiark-readme;">.
- <p>
-<em>Note:</em> Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-<tt>chiark</tt>. Since this upload queue goes to <tt>ftp-master</tt>, the
-prescription found in <ref id="upload-ftp-master"> applies here as well.
- <p>
-The program <prgn>dupload</prgn> comes with support for uploading to
-<tt>chiark</tt>; please refer to the documentation that comes with the
-program for details.
-
-
- <sect1>Uploads via <tt>erlangen</tt>
+ <sect1>Delayed uploads
<p>
-Another upload queue is available in Germany: just upload the files
-via anonymous FTP to <url id="&url-upload-erlangen;">.
+Delayed uploads are done for the moment via the delayed queue at
+gluck. The upload-directory is
+<ftpsite>gluck:~tfheen/DELAYED/[012345678]-day</ftpsite>.
+0-day is uploaded approximately one hour before dinstall runs.
<p>
-The upload must be a complete Debian upload, as you would put it into
-<tt>ftp-master</tt>'s <file>Incoming</file>, i.e., a <file>.changes</file> files
-along with the other files mentioned in the <file>.changes</file>. The
-queue daemon also checks that the <file>.changes</file> is correctly
-signed with GnuPG or OpenPGP by a Debian developer, so that no bogus files can find
-their way to <tt>ftp-master</tt> via this queue. Please also make sure that
-the <tt>Maintainer</tt> field in the <file>.changes</file> contains
-<em>your</em> e-mail address. The address found there is used for all
-replies, just as on <tt>ftp-master</tt>.
- <p>
-There's no need to move your files into a second directory after the
-upload, as on <tt>chiark</tt>. And, in any case, you should get a
-mail reply from the queue daemon explaining what happened to your
-upload. Hopefully it should have been moved to <tt>ftp-master</tt>, but in
-case of errors you're notified, too.
+With a fairly recent dput, this section
+<example>
+[tfheen_delayed]
+method = scp
+fqdn = gluck.debian.org
+incoming = ~tfheen
+</example>
+in ~/.dput.cf should work fine for uploading to the DELAYED queue.
<p>
-<em>Note:</em> Do not upload packages containing software that is
-export-controlled by the United States government to the queue on
-<tt>erlangen</tt>. Since this upload queue goes to <tt>ftp-master</tt>, the
+<em>Note:</em>
+Since this upload queue goes to <tt>ftp-master</tt>, the
prescription found in <ref id="upload-ftp-master"> applies here as well.
- <p>
-The program <prgn>dupload</prgn> comes with support for uploading to
-<tt>erlangen</tt>; please refer to the documentation that comes with
-the program for details.
+ <sect1>Security uploads
+ <p>
+Do NOT upload a package to the security upload queue (oldstable-security,
+stable-security, etc.) without prior authorization from the security
+team. If the package does not exactly meet the team's requirements, it
+will cause many problems and delays in dealing with the unwanted upload.
+For details, please see section <ref id="bug-security">.
<sect1>Other upload queues
<p>
-Another upload queue is available which is based in the US, and is a
-good backup when there are problems reaching <tt>ftp-master</tt>. You can
-upload files, just as in <tt>erlangen</tt>, to <url
-id="&url-upload-samosa;">.
+The scp queues on ftp-master, non-us and security are mostly unuseable
+due to the login restrictions on those hosts.
<p>
-An upload queue is available in Japan: just upload the files via
-anonymous FTP to <url id="&url-upload-jp;">.
-
+The anonymous queues on ftp.uni-erlangen.de and ftp.uk.debian.org are
+currently down. Work is underway to resurrect those.
+ <p>
+The queues on master.debian.org, samosa.debian.org, master.debian.or.jp
+and ftp.chiark.greenend.org.uk are down permanently and will not be
+resurrected. The queue in Japan will be replaced with a new queue on
+hp.debian.or.jp some day.
+ <p>
+For the time being, the anonymous ftp queue on auric.debian.org (the
+former ftp-master) works, but it is deprecated and will be removed at
+some point in the future.
<sect1 id="upload-notification">
<heading>Notification that a new package has been installed</heading>
Note also that if you upload via queues, the queue daemon software will
also send you a notification by email.
- <sect id="override-file">Determining section and priority of a package
+ <sect id="override-file">Specifying the package section, subsection and priority
<p>
The <file>debian/control</file> file's <tt>Section</tt> and
<tt>Priority</tt> fields do not actually specify where the file will
name="dpkg-scanpackages" section="8"> and
<url id="&url-bts-devel;#maintincorrect">.
<p>
-Note also that the term "section" is used for the separation of packages
-according to their licensing, e.g. <em>main</em>, <em>contrib</em> and
-<em>non-free</em>. This is described in another section, <ref id="archive">.
+Note that the <tt>Section</tt> field describes both the section as
+well as the subsection, which are described in <ref
+id="archive-sections">. If the section is "main", it should be
+omitted. The list of allowable subsections can be found in <url
+id="&url-debian-policy;ch-archive.html#s-subsections">.
<sect id="bug-handling">Handling bugs
When you become aware of a security-related bug in a Debian package,
whether or not you are the maintainer, collect pertinent information
about the problem, and promptly contact the security team at
-&email-security-team; as soon as possible. Useful information
-includes, for example:
+&email-security-team; as soon as possible. <strong>DO NOT UPLOAD</strong> any
+packages for stable; the security team will do that.
+
+Useful information includes, for example:
<list compact>
<item>What versions of the package are known to be affected by the
package. Test other, normal actions as well, as sometimes a security
fix can break seemingly unrelated features in subtle ways.
<p>
+Do <strong>NOT</strong> include any changes in your package which are
+not directly related to fixing the vulnerability. These will only
+need to be reverted, and this wastes time. If there are other bugs in
+your package that you would like to fix, make an upload to
+proposed-updates in the usual way, after the security advisory is
+issued. The security update mechanism is not a means for introducing
+changes to your package which would otherwise be rejected from the
+stable release, so please do not attempt to do this.
+<p>
Review and test your changes as much as possible. Check the
differences from the previous version repeatedly
(<prgn>interdiff</prgn> from the <package>patchutils</package> package
and <prgn>debdiff</prgn> from <package>devscripts</package> are useful
tools for this, see <ref id="debdiff">).
<p>
-When packaging the fix, keep the following points in mind:
+Be sure to verify the following items:
<list>
- <item>Make sure you target the right distribution in your
+ <item>Target the right distribution in your
<file>debian/changelog</file>. For stable this is <tt>stable-security</tt> and for
testing this is <tt>testing-security</tt>, and for the previous
stable release, this is <tt>oldstable-security</tt>. Do not target
<var>distribution</var>-proposed-updates or <tt>stable</tt>!
+ <item>The upload should have urgency=high.
+
<item>Make descriptive, meaningful changelog entries. Others will
rely on them to determine whether a particular bug was fixed.
Always include an external reference, preferably a CVE
not build those. This point applies to normal package uploads as
well.
- <item>If the upstream source has been uploaded to
+ <item>Unless the upstream source has been uploaded to
security.debian.org before (by a previous security update), build
- the upload without the upstream source (<tt>dpkg-buildpackage
- -sd</tt>). Otherwise, build with full source
- (<tt>dpkg-buildpackage -sa</tt>).
+ the upload with full upstream source (<tt>dpkg-buildpackage
+ -sa</tt>). If there has been a previous upload to
+ security.debian.org with the same upstream version, you may upload
+ without upstream source (<tt>dpkg-buildpackage -sd</tt>).
<item>Be sure to use the exact same <file>*.orig.tar.gz</file> as used in the
normal archive, otherwise it is not possible to move the security
fix into the main archives later.
- <item>Be sure to build the package on a clean
+ <item>Build the package on a clean
system which only has packages installed from the distribution you
are building for. If you do not have such a system yourself, you
can use a debian.org machine (see <ref id="server-machines">)
against the pseudo package <package>wnpp</package>. The bug report should be
titled <tt>O: <var>package</var> -- <var>short description</var></tt>
indicating that the package is now orphaned. The severity of the bug
-should be set to <em>normal</em>. If you feel it's necessary, send a copy
+should be set to <em>normal</em>; if the package has a priority of standard
+or higher, it should be set to important.
+If you feel it's necessary, send a copy
to &email-debian-devel; by putting the address in the X-Debbugs-CC: header
of the message (no, don't use CC:, because that way the message's subject
won't indicate the bug number).
<p>
-If the package is especially crucial to Debian, you should instead submit
+If you just intend to give the package away, but you can keep maintainership
+for the moment, then you should instead submit
a bug against <package>wnpp</package> and title it <tt>RFA: <var>package</var> --
-<var>short description</var></tt> and set its severity to
-<em>important</em>. <tt>RFA</tt> stands for <em>Request For Adoption</em>.
-Definitely copy the message to debian-devel in this case, as described
-above.
+<var>short description</var></tt>.
+<tt>RFA</tt> stands for <em>Request For Adoption</em>.
<p>
-Read instructions on the <url id="&url-wnpp;" name="WNPP web pages">
-for more information.
+More information is on the <url id="&url-wnpp;" name="WNPP web pages">.
<sect1 id="adopting">Adopting a package
<p>
possibility of running <prgn>dinstall</prgn> in dry-run mode after the
upload.
</sect1>
+ <sect1 id="dcut">
+ <heading><package>dcut</package></heading>
+ <p>
+The <package>dcut</package> script (part of the package <ref id="dput">)
+helps in removing files from the ftp upload directory.
+ </sect1>
</sect>
<sect id="tools-maint-automate">
~ianmdlvl / developers-reference.git / blobdiff