<!-- include version information so we don't have to hard code it
within the document -->
<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
- <!-- common, language independant entities -->
+ <!-- common, language independent entities -->
<!ENTITY % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.225 $">
+ <!ENTITY cvs-rev "$Revision: 1.230 $">
<!-- if you are translating this document, please notate the CVS
revision of the original developer's reference in cvs-en-rev -->
packages (<ref id="tools">).
<p>
It should be clear that this reference does not discuss the technical
-details of the Debian package nor how to generate Debian packages.
+details of Debian packages nor how to generate them.
Nor does this reference detail the standards to which Debian software
must comply. All of such information can be found in the <url
id="&url-debian-policy;" name="Debian Policy Manual">.
nothing as critical as that, but it's still appropriate to let the others
know that you're unavailable.
<p>
-In order to inform the other developers, there's two things that you should do.
+In order to inform the other developers, there are two things that you should do.
First send a mail to &email-debian-private; with "[VAC] " prepended to the
subject of your message<footnote>This is so that the message can be easily
filtered by people who don't want to read vacation notices.</footnote>
While it's not your job to fix non-Debian specific bugs, you may freely
do so if you're able. When you make such fixes, be sure to pass them on
to the upstream maintainers as well. Debian users and developers will
-sometimes submit patches to fix upstream bugs -- you should evaluate
+sometimes submit patches to fix upstream bugs — you should evaluate
and forward these patches upstream.
<p>
If you need to modify the upstream sources in order to build a policy
<p>
Generally you should deal with bug reports on your packages as described in
<ref id="bug-handling">. However, there's a special category of bugs that
-you need to take care of -- the so-called release-critical bugs (RC bugs).
+you need to take care of — the so-called release-critical bugs (RC bugs).
All bug reports that have severity <em>critical</em>, <em>grave</em> or
<em>serious</em> are considered to have an impact on whether the package can
be released in the next stable release of Debian.
suggestions for the web site, etc.),
generally you'll report a bug against a ``pseudo-package''. See <ref
id="submit-bug"> for information on how to submit bugs.
+ <p>
+Some of the core servers are restricted, but the information from there
+is mirror to another server.
<sect1 id="servers-bugs">The bugs server
<p>
<tt>&bugs-host;</tt> is the canonical location for the Bug Tracking
-System (BTS). If you plan on doing some statistical analysis or
+System (BTS).
+ <p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
+If you plan on doing some statistical analysis or
processing of Debian bugs, this would be the place to do it. Please
describe your plans on &email-debian-devel; before implementing
anything, however, to reduce unnecessary duplication of effort or
wasted processing time.
- <p>
-All Debian developers have accounts on <tt>&bugs-host;</tt>.
<sect1 id="servers-ftp-master">The ftp-master server
<p>
archive (excluding the non-US packages). Generally, package uploads
go to this server; see <ref id="upload">.
<p>
+It is restricted; a mirror is available on <tt>merkel</tt>.
+ <p>
Problems with the Debian FTP archive generally need to be reported as
bugs against the <package>ftp.debian.org</package> pseudo-package or
an email to &email-ftpmaster;, but also see the procedures in
to make sure everything in this distribution is working properly, it is
sometimes literally unstable.
<p>
-<qref id="testing">"testing"</qref> is generated automatically by taking
+The <qref id="testing">"testing"</qref> distribution is generated
+automatically by taking
packages from unstable if they satisfy certain criteria. Those
criteria should ensure a good quality for packages within testing.
The update to testing is launched each day after the
all the other directories are only writable by the ftpmasters, that is
why you can not remove an upload once it has been accepted.
- <sect1 id="delayed-incoming">Delayed incoming
+ <sect1 id="delayed-incoming-broken">Delayed incoming
+ <p>
+<em>Note:</em> This description here is currently disabled, because
+ftp-master is restricted. Please see <ref id="delayed-incoming"> for
+the currently working way.
<p>
The <file>unchecked</file> directory has a special <file>DELAYED</file>
subdirectory. It is itself subdivided in nine directories
`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 id="delayed-incoming">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>
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
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>
<heading>Separating your patches into multiple files</heading>
<p>
Big, complex packages may have many bugs that you need to deal with.
-If you correct a number of bug directly in the source, if you're not
+If you correct a number of bugs directly in the source, and you're not
careful, it can get hard to differentiate the various patches that you
applied. It can get quite messy when you have to update the package
to a new upstream version which integrates some of the fixes (but not
non-Debian mailing lists or news groups.
</list>
<p>
-One big problem are packages which were sponsored -- the maintainer is not
+One big problem are packages which were sponsored — the maintainer is not
an official Debian developer. The echelon information is not available for
sponsored people, for example, so you need to find and contact the Debian
developer who has actually uploaded the package. Given that they signed the
People on this alias will use the information you provided in order to
decide how to proceed. For example, they might orphan one or all of the
packages of the maintainer. If a packages has been NMUed, they might prefer
-to contact the NMUer before orphaning the package -- perhaps the person who
+to contact the NMUer before orphaning the package — perhaps the person who
has done the NMU is interested in the package.
<p>
One last word: please remember to be polite. We are all volunteers and
cannot dedicate all of our time to Debian. Also, you are not aware of the
circumstances of the person who is involved. Perhaps they might be
-seriously ill or might even had died -- you do not know who may be on the
-receiving side -- imagine how a relative will feel if they read the e-mail
+seriously ill or might even had died — you do not know who may be on the
+receiving side — imagine how a relative will feel if they read the e-mail
of the deceased and find a very impolite, angry and accusing message!)
<p>
On the other hand, although we are volunteers, we do have a responsibility.
-So you can stress the importance of the greater good -- if a maintainer does
+So you can stress the importance of the greater good — if a maintainer does
not have the time or interest anymore, they should "let go" and give the
package to someone with more time.
<p>
Once the package meets Debian standards, build and sign it with
<example>dpkg-buildpackage -k<var>KEY-ID</var></example>
-before uploading it to the incoming directory.
+before uploading it to the incoming directory. Of course, you can also
+use any part of your <var>KEY-ID</var>, as long as it's uniq in your
+secret keyring.
<p>
The Maintainer field of the <file>control</file> file and the
<file>changelog</file> should list the person who did the packaging, i.e., the
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