git-svn-id: svn://anonscm.debian.org/ddp/manuals/trunk/developers-reference@2567
313b444b-1b9f-4f58-a734-
7bb04f332e8d
* Andreas Barth
- uploads to more than one dist are not possible.
- updated upload queues. Closes: #235213
* Andreas Barth
- uploads to more than one dist are not possible.
- updated upload queues. Closes: #235213
- - updated URL of vanilla rules files. Closes: #237557
+ - updated URL of vanilla rules files. Closes: #237557, #252048
- please speak with stable RM before uploading to stable. Closes: #261464
- information on wnpp usage synced with wnpp. Closes: #255298
- please speak with stable RM before uploading to stable. Closes: #261464
- information on wnpp usage synced with wnpp. Closes: #255298
+ - spelling, grammer fixes.
+ Closes: #202444, #202499, #203202, #203378, #221902, #226208
+ - add hint about partitial key id. Closes: #243968
+ - spohr is restriced, and also ftp-master. Closes: #255814
* Matt Zimmerman
- Security uploads get urgency=high
- Be even more explicit about not uploading security updates
* Matt Zimmerman
- Security uploads get urgency=high
- Be even more explicit about not uploading security updates
- -- Andreas Barth <aba@not.so.argh.org> Sun, 5 Sep 2004 12:48:32 -0600
+ -- Andreas Barth <aba@not.so.argh.org> Sun, 5 Sep 2004 14:02:11 -0600
developers-reference (3.3.4) unstable; urgency=low
developers-reference (3.3.4) unstable; urgency=low
<!-- include version information so we don't have to hard code it
within the document -->
<!ENTITY % versiondata SYSTEM "version.ent"> %versiondata;
<!-- 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 % commondata SYSTEM "common.ent" > %commondata;
<!-- CVS revision of this document -->
- <!ENTITY cvs-rev "$Revision: 1.229 $">
+ <!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 -->
<!-- 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
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">.
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>
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>
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
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
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
<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.
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.
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
<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.
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>
<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>
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
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>
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
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.
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
<p>
The <file>unchecked</file> directory has a special <file>DELAYED</file>
subdirectory. It is itself subdivided in nine directories
residents consult a lawyer before doing uploads to non-US.
residents consult a lawyer before doing uploads to non-US.
+ <sect1 id="delayed-incoming">Delayed uploads
<p>
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<p>
Delayed uploads are done for the moment via the delayed queue at
gluck. The upload-directory is
<heading>Separating your patches into multiple files</heading>
<p>
Big, complex packages may have many bugs that you need to deal with.
<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
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>
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
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
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
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.
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.
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>
<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
<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