X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=pkgs.dbk;h=160fa5b11a08fdd1a80ebd4e05bad81eb3e3c6f4;hb=18f7e0f173799b3dc24248340e88c5feedc282a6;hp=2fb760965e038b2cdeb3ef18b0821d700c78ea96;hpb=430f868ef5cabbf6539d3051966de888d14277be;p=developers-reference.git diff --git a/pkgs.dbk b/pkgs.dbk index 2fb7609..160fa5b 100644 --- a/pkgs.dbk +++ b/pkgs.dbk @@ -48,6 +48,12 @@ new package in order for the bug report to be automatically closed once the new package is installed in the archive (see ). +If you think your package needs some explanations for the administrators of the +NEW package queue, include them in your changelog, send to ftpmaster@debian.org +a reply to the email you receive as a maintainer after your upload, or reply to +the rejection email in case you are already re-uploading. + + When closing security bugs include CVE numbers as well as the Closes: #nnnnn. This is useful for the security team to track vulnerabilities. If an upload is made to fix the bug before the advisory ID is known, it is encouraged to modify @@ -401,29 +407,28 @@ the Debian package .
Delayed uploads + -Delayed uploads are done for the moment via the delayed queue at gluck -. The upload-directory is -gluck:~tfheen/DELAYED/[012345678]-day. 0-day is uploaded -multiple times per day to &ftp-master-host;. - - -With a fairly recent dput, this section +It is sometimes useful to upload a package immediately, but to want this +package to arrive in the archive only a few days later. For example, +when preparing a Non-maintainer Upload, +you might want to give the maintainer a few days to react. - -[tfheen_delayed] -method = scp -fqdn = gluck.debian.org -incoming = ~tfheen - + -in ~/.dput.cf should work fine for uploading to the -DELAYED queue. +An upload to the delayed directory keeps the package in + +the deferred uploads queue". +When the specified waiting time is over, the package is moved into +the regular incoming directory for processing. +This is done through automatic uploading to +&ftp-master-host; in upload-directory +DELAYED/[012345678]-day. 0-day is uploaded +multiple times per day to &ftp-master-host;. -Note: Since this upload queue goes to -&ftp-master-host;, the prescription found in applies here as well. +With dput, you can use the --delayed DELAY +parameter to put the package into one of the queues.
@@ -828,15 +833,13 @@ outstanding security problems, helping maintainers with security problems or fixing them themselves, sending security advisories, and maintaining security.debian.org. - - 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. DO NOT UPLOAD any packages for stable; - the security team will do that. Useful information includes, for example: +role="strong">DO NOT UPLOAD any packages for stable +without contacting the team. Useful information includes, for example: @@ -871,6 +874,29 @@ linkend="bug-security-advisories"/> ) +As the maintainer of the package, you have the responsibility to +maintain it, even in the stable release. You are in the best position +to evaluate patches and test updated packages, so please see the sections +below on how to prepare packages for the Security Team to handle. + +
+The Security Tracker + +The security team maintains a central database, the +Debian Security Tracker. +This contains all public information that is known about security issues: +which packages and versions are affected or fixed, and thus whether stable, +testing and/or unstable are vulnerable. Information that is still confidential +is not added to the tracker. + + +You can search it for a specific issue, but also on package name. Look +for your package to see which issues are still open. If you can, please provide +more information about those issues, or help to address them in your package. +Instructions are on the tracker web pages. + +
+
Confidentiality @@ -940,6 +966,10 @@ There are two reasons for releasing information even though secrecy is requested: the problem has been known for a while, or the problem or exploit has become public. + +The Security Team has a PGP-key to enable encrypted communication about +sensitive issues. See the Security Team FAQ for details. +
@@ -1076,7 +1106,8 @@ Be sure to verify the following items: -Target the right distribution in your debian/changelog. +Target the right distribution +in your debian/changelog. For stable this is stable-security and for testing this is testing-security, and for the previous stable release, this is oldstable-security. Do not target @@ -1086,67 +1117,58 @@ stable release, this is oldstable-security. Do not target -The upload should have urgency=high. +The upload should have urgency=high. 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 identifier, so that it can be cross-referenced. -Include the same information in the changelog for unstable, -so that it is clear -that the same bug was fixed, as this is very helpful when verifying that the -bug is fixed in the next stable release. If a CVE identifier has not yet been -assigned, the security team will request one so that it can be included in the -package and in the advisory. - - - - -Make sure the version number is proper. It must be greater than the current -package, but less than package versions in later distributions. If in doubt, -test it with dpkg --compare-versions. Be careful not to -re-use a version number that you have already used for a previous upload. For -testing, there must be a higher version in -unstable. If there is none yet (for example, if -testing and unstable have the same -version) you must upload a new version to unstable first. +determine whether a particular bug was fixed. Add closes: +statements for any Debian bugs filed. +Always include an external reference, preferably a CVE +identifier, so that it can be cross-referenced. However, if a CVE +identifier has not yet been assigned, do not wait for it but continue the +process. The identifier can be cross-referenced later. -Do not make source-only uploads if your package has any binary-all packages (do -not use the -S option to -dpkg-buildpackage). The buildd -infrastructure will not build those. This point applies to normal package -uploads as well. +Make sure the version number is proper. +It must be greater than the current package, but less than package versions in +later distributions. If in doubt, test it with dpkg +--compare-versions. Be careful not to re-use a version number that +you have already used for a previous upload, or one that conflicts with a +binNMU. The convention is to append ++codename1, e.g. +1:2.4.3-4+etch1, of course increasing 1 for any subsequent +uploads. Unless the upstream source has been uploaded to security.debian.org - before (by a previous security update), build the upload with full -upstream source (dpkg-buildpackage -sa). If there has been -a previous upload to security.debian.org with the same -upstream version, you may upload without upstream source ( -dpkg-buildpackage -sd). + before (by a previous security update), build the upload with full upstream source (dpkg-buildpackage +-sa). If there has been a previous upload to +security.debian.org with the same upstream version, you may +upload without upstream source ( dpkg-buildpackage -sd). -Be sure to use the exact same *.orig.tar.gz as used in the +Be sure to use the exact same +*.orig.tar.gz as used in the normal archive, otherwise it is not possible to move the security fix into the main archives later. -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 ) or -setup a chroot (see and ). +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 + ) or setup a chroot (see + and ). @@ -1179,7 +1201,7 @@ archives. For security uploads, the place to upload to is Once an upload to the security queue has been accepted, the package will -automatically be rebuilt for all architectures and stored for verification by +automatically be built for all architectures and stored for verification by the security team. @@ -1768,6 +1790,16 @@ also enable Debian to recompile entire distributions quickly. The buildds admins of each arch can be contacted at the mail address arch@buildd.debian.org. + + +Since the Release team also has access to wanna-build, +it has become common practice to ask them to perform actions such as +the recompilation of packages (binNMUs, see ) +or the retry of failed builds (give-backs). +The format to use when requesting such actions is described at +. + +
@@ -1967,18 +1999,33 @@ upload. The first line of this entry must explicitely mention that this upload -The version must be the version of the last maintainer upload, plus +The way to version NMUs differs for native and non-native packages. + + +If the package is a native package (without a debian revision in the version number), +the version must be the version of the last maintainer upload, plus +nmuX, where -X is a counter starting at 1. If +X is a counter starting at 1. +If the last upload was also an NMU, the counter should be increased. For example, -if the current version is 1.5-1, then an NMU would get -version 1.5-1+nmu1. If the current version is -1.5+nmu3 (a native package which has already been NMUed), the -NMU would get version 1.5+nmu4. If a new upstream version +if the current version is 1.5, then an NMU would get +version 1.5+nmu1. + + +If the package is a not a native package, you should add a minor version number +to the debian revision part of the version number (the portion after the last +hyphen). This extra number must start at 1. For example, +if the current version is 1.5-2, then an NMU would get +version 1.5-2.1. If a new upstream version is packaged in the NMU, the debian revision is set to 0, for -example 1.6-0+nmu1. +example 1.6-0.1. + + +In both cases, if the last upload was also an NMU, the counter should +be increased. For example, if the current version is +1.5+nmu3 (a native package which has already been +NMUed), the NMU would get version 1.5+nmu4. . - A special versioning scheme is needed to avoid disrupting the maintainer's work, since using an integer for the Debian revision will potentially