X-Git-Url: http://www.chiark.greenend.org.uk/ucgi/~ianmdlvl/git?a=blobdiff_plain;f=developers-reference.sgml;h=0756207a555a8ac381af2e21c7860d40194b766b;hb=11738bc20dfa85b02e0df9d5a64fd3dcbe97a010;hp=5f55eacaa86f95efea21b3004b66d0a3a71dc99d;hpb=e324851ea50c64b435bc7a0a0357017d1735c76b;p=developers-reference.git diff --git a/developers-reference.sgml b/developers-reference.sgml index 5f55eac..0756207 100644 --- a/developers-reference.sgml +++ b/developers-reference.sgml @@ -6,7 +6,7 @@ %commondata; - + @@ -1125,7 +1125,7 @@ why you can not remove an upload once it has been accepted. Delayed incoming

-Note: This description here is currently disabled, because +Note: This description here is currently not working, because ftp-master is restricted. Please see for the currently working way.

@@ -2642,6 +2642,12 @@ The way to invoke dpkg-buildpackage is as set porter-email to your email address. This will do a binary-only build of only the architecture-dependent portions of the package, using the `binary-arch' target in debian/rules. +

+If you are working on a Debian machine for your porting efforts and you +need to sign your upload locally for the acceptance in the archive, you +can run debsign on your .changes file to have +it signed conveniently, or use the remote signing mode of dpkg-sig. + Recompilation or binary-only NMU @@ -2652,7 +2658,14 @@ library, bad compiler, ...). Then you may just need to recompile it in an updated environment. However, you have to bump the version number in this case, so that the old bad package can be replaced in the Debian archive (katie refuses to install new packages if they don't have a -version number greater than the currently available one). Despite the +version number greater than the currently available one). +

+You have to make sure that your binary-only NMU doesn't render the package +uninstallable. This could happen when a source package generates +arch-dependend and arch-independend packages that depend on each other via +$(Source-Version). +

+Despite the required modification of the changelog, these are called binary-only NMUs — there is no need in this case to trigger all other architectures to consider themselves out of date or requiring recompilation. @@ -2669,6 +2682,10 @@ if the latest version you are recompiling against was version ``2.9-3'', your NMU should carry a version of ``2.9-3.0.1''. If the latest version was ``3.4-2.1'', your NMU should have a version number of ``3.4-2.1.1''. +

+Similar to initial porter uploads, the correct way of invoking +dpkg-buildpackage is dpkg-buildpackage -B to only +build the architecture-dependent parts of the package. @@ -2680,17 +2697,11 @@ the wait cycle for a porter's source NMU is smaller than for a non-porter, since porters have to cope with a large quantity of packages. Again, the situation varies depending on the distribution they are -uploading to. - - +uploading to. It also varies whether the architecture is a candidate +for inclusion into the next stable release; the release managers +decide and announce which architectures are candidates.

-However, if you are a porter doing an NMU for `unstable', the above +If you are a porter doing an NMU for `unstable', the above guidelines for porting should be followed, with two variations. Firstly, the acceptable waiting period — the time between when the bug is submitted to the BTS and when it is OK to do an NMU — is seven @@ -2698,6 +2709,8 @@ days for porters working on the unstable distribution. This period can be shortened if the problem is critical and imposes hardship on the porting effort, at the discretion of the porter group. (Remember, none of this is Policy, just mutually agreed upon guidelines.) +For uploads to stable or testing, please coordinate with the appropriate +release team first.

Secondly, porters doing source NMUs should make sure that the bug they submit to the BTS should be of severity `serious' or greater. This @@ -2785,86 +2798,50 @@ distributions quickly. Non-Maintainer Uploads (NMUs)

Under certain circumstances it is necessary for someone other than the -official package maintainer to make a release of a package. This is +official package maintainer to make a release of a package. This is called a non-maintainer upload, or NMU.

-Debian porters, who compile packages for different architectures, -occasionally do binary-only NMUs as part of their porting activity -(see ). Another reason why NMUs are done is when a -Debian developer needs to fix another developer's packages in order to -address serious security problems or crippling bugs, especially during -the freeze, or when the package maintainer is unable to release a fix +This sections handles only source NMUs, i.e. NMUs which upload a new +version of the package. For binary-only NMUs by porters or QA members, +please see . +For buildd uploads (which are strictly speaking also NMUs), please see . +

+The main reason why NMUs are done is when a +developer needs to fix another developer's packages in order to +address serious problems or crippling bugs +or when the package maintainer is unable to release a fix in a timely fashion. -

-This chapter contains information providing guidelines for when and -how NMUs should be done. A fundamental distinction is made between -source and binary-only NMUs, which is explained in the next section. - - Terminology

-There are two new terms used throughout this section: ``binary-only NMU'' -and ``source NMU''. These terms are used with specific technical -meaning throughout this document. Both binary-only and source NMUs are -similar, since they involve an upload of a package by a developer who -is not the official maintainer of that package. That is why it's a -non-maintainer upload. -

-A source NMU is an upload of a package by a developer who is not the -official maintainer, for the purposes of fixing a bug in the package. -Source NMUs always involves changes to the source (even if it is just -a change to debian/changelog). This can be either a -change to the upstream source, or a change to the Debian bits of the -source. Note, however, that source NMUs may also include -architecture-dependent packages, as well as an updated Debian diff. -

-A binary-only NMU is a recompilation and upload of a binary package -for a given architecture. As such, it is usually part of a porting -effort. A binary-only NMU is a non-maintainer uploaded binary version -of a package, with no source changes required. There are many cases -where porters must fix problems in the source in order to get them to -compile for their target architecture; that would be considered a -source NMU rather than a binary-only NMU. As you can see, we don't -distinguish in terminology between porter NMUs and non-porter NMUs. -

-Both classes of NMUs, source and binary-only, can be lumped by the -term ``NMU''. However, this often leads to confusion, since most -people think ``source NMU'' when they think ``NMU''. So it's best to -be careful. In this chapter, if we use the unqualified term ``NMU'', -we refer to any type of non-maintainer upload NMUs, whether source and -binary, or binary-only. - - - Who can do an NMU +First and foremost, it is critical that NMU patches to source should +be as non-disruptive as possible. Do not do housekeeping tasks, do +not change the name of modules or files, do not move directories; in +general, do not fix things which are not broken. Keep the patch as +small as possible. If things bother you aesthetically, talk to the +Debian maintainer, talk to the upstream maintainer, or submit a bug. +However, aesthetic changes must not be made in a non-maintainer +upload.

-Only official, registered Debian maintainers can do binary or source -NMUs. An official maintainer is someone who has their key in the -Debian key ring. Non-developers, however, are encouraged to download -the source package and start hacking on it to fix problems; however, -rather than doing an NMU, they should just submit worthwhile patches -to the Bug Tracking System. Maintainers almost always appreciate -quality patches and bug reports. +And please remember the Hippocratic Oath: "Above all, do no harm." +It is better if a package has an grave bug open, than if a not working +patch was applied, and the bug is only hidden now but not resolved. - When to do a source NMU -

-Guidelines for when to do a source NMU depend on the target -distribution, i.e., stable, unstable, or experimental. Porters have -slightly different rules than non-porters, due to their unique -circumstances (see ). + How to do a NMU

-When a security bug is detected, the security team may do an NMU. -Please refer to for more information. +NMUs which fix important, serious or higher severity bugs are encouraged +and accepted. +You should endeavor to reach the current maintainer of the package; they +might be just about to upload a fix for the problem, or have a better +solution present.

-During the release cycle (see ), NMUs which fix -serious or higher severity bugs are encouraged and accepted. Even -during this window, however, you should endeavor to reach the current -maintainer of the package; they might be just about to upload a fix -for the problem. As with any source NMU, the guidelines found in need to be followed. Special exceptions are made -for . +NMUs should be made to assist a package's maintainer in resolving bugs. +Maintainers should be thankfull for that help, and NMUers should respect +the decisions of maintainers, and try to personally help the maintainer by +their work.

-Uploading bug fixes to unstable by non-maintainers should only be done -by following this protocol: +A NMU should follow all conventions, written down in this section. +For an upload to testing or unstable, this order of steps is recommended:

@@ -2900,27 +2877,30 @@ before uploading the fixes, and shortening the DELAYED period. It is important to notice that even in these so-called "bug squashing party" times, the NMU'er has to file bugs and contact the developer first, and act later. - - How to do a source NMU +Please see for details.

-The following applies to porters insofar as they are playing the dual -role of being both package bug-fixers and package porters. If a -porter has to change the Debian source archive, their upload is -automatically a source NMU and is subject to its rules. If a porter is -simply uploading a recompiled binary package, the rules are different; -see . +For the testing distribution, the rules may be changed by the release +managers. Please take additional care, and acknowledge that the usual way +for a package to enter testing is through unstable.

-First and foremost, it is critical that NMU patches to source should -be as non-disruptive as possible. Do not do housekeeping tasks, do -not change the name of modules or files, do not move directories; in -general, do not fix things which are not broken. Keep the patch as -small as possible. If things bother you aesthetically, talk to the -Debian maintainer, talk to the upstream maintainer, or submit a bug. -However, aesthetic changes must not be made in a non-maintainer -upload. +For the stable distribution, please take extra care. Of course, the release +managers may also change the rules here. Please verify before upload that +all your changes are ok for inclusion into the next stable release by the +release manager. +

+When a security bug is detected, the security team may do an NMU, using +their own rules. Please refer to for more +information. +

+For the differences for Porters NMUs, please see +. +

+Of course, it is always possible to agree on special rules with a maintainer +(like the maintainer asking "please upload this fix directly for me, and no +diff required"). - Source NMU version numbering + NMU version numbering

Whenever you have made a change to a package, no matter how trivial, the version number needs to change. This enables our packing system @@ -2948,9 +2928,13 @@ make a release based on a new upstream version then the person making the release should start with the debian-revision value `0.1'. The usual maintainer of a package should start their debian-revision numbering at `1'. +

+If you upload a package to testing or stable, sometimes, you need to +"fork" the version number tree. For this, version numbers like +1.1-3sarge0.1 could be used. - + Source NMUs must have a new changelog entry

A non-maintainer doing a source NMU must create a changelog entry, @@ -2965,7 +2949,7 @@ By convention, source NMU changelog entries start with the line - Source NMUs and the Bug Tracking System + Source NMUs and the Bug Tracking System

Maintainers other than the official package maintainer should make as few changes to the package as possible, and they should always send a @@ -2982,7 +2966,7 @@ send a patch. If the source NMU (non-maintainer upload) fixes some existing bugs, these bugs should be tagged fixed in the Bug Tracking System rather than closed. By convention, only the official package -maintainer or the original bug submitter are allowed to close bugs. +maintainer or the original bug submitter close bugs. Fortunately, Debian's archive system recognizes NMUs and thus marks the bugs fixed in the NMU appropriately if the person doing the NMU has listed all bugs in the changelog with the Closes: @@ -2993,9 +2977,11 @@ bug was fixed in an NMU; however the bug is left open until the changes in the NMU are incorporated officially into the package by the official package maintainer.

-Also, after doing an NMU, you have to open a new bug and include a -patch showing all the changes you have made. Alternatively you can send -that information to the existing bugs that are fixed by your NMU. +Also, after doing an NMU, you have to send +that information to the existing bugs that are fixed by your NMU, +including the unified diff. +Alternatively you can open a new bug and include a +patch showing all the changes you have made. The normal maintainer will either apply the patch or employ an alternate method of fixing the problem. Sometimes bugs are fixed independently upstream, which is another good reason to back out an NMU's patch. @@ -3007,7 +2993,7 @@ In addition, the normal maintainer should always retain the entry in the changelog file documenting the non-maintainer upload. - Building source NMUs + Building source NMUs

Source NMU packages are built normally. Pick a distribution using the same rules as found in , follow the other @@ -3036,6 +3022,57 @@ ask them if they would be interested in helping you on a more frequent basis as co-maintainer or backup maintainer (see ). + NMU vs QA uploads +

+Unless you know the maintainer is still active, it is wise to check the +package to see if it has been orphaned. The current list of orphaned +packages which haven't had their maintainer set correctly is available at +. If you perform an NMU on an +improperly orphaned package, please set the maintainer to ``Debian QA Group +<packages@qa.debian.org>''. + + Who can do an NMU +

+Only official, registered Debian maintainers can do binary or source +NMUs. An official maintainer is someone who has their key in the +Debian key ring. Non-developers, however, are encouraged to download +the source package and start hacking on it to fix problems; however, +rather than doing an NMU, they should just submit worthwhile patches +to the Bug Tracking System. Maintainers almost always appreciate +quality patches and bug reports. + + Terminology +

+There are two new terms used throughout this section: ``binary-only NMU'' +and ``source NMU''. These terms are used with specific technical +meaning throughout this document. Both binary-only and source NMUs are +similar, since they involve an upload of a package by a developer who +is not the official maintainer of that package. That is why it's a +non-maintainer upload. +

+A source NMU is an upload of a package by a developer who is not the +official maintainer, for the purposes of fixing a bug in the package. +Source NMUs always involves changes to the source (even if it is just +a change to debian/changelog). This can be either a +change to the upstream source, or a change to the Debian bits of the +source. Note, however, that source NMUs may also include +architecture-dependent packages, as well as an updated Debian diff. +

+A binary-only NMU is a recompilation and upload of a binary package +for a given architecture. As such, it is usually part of a porting +effort. A binary-only NMU is a non-maintainer uploaded binary version +of a package, with no source changes required. There are many cases +where porters must fix problems in the source in order to get them to +compile for their target architecture; that would be considered a +source NMU rather than a binary-only NMU. As you can see, we don't +distinguish in terminology between porter NMUs and non-porter NMUs. +

+Both classes of NMUs, source and binary-only, can be lumped by the +term ``NMU''. However, this often leads to confusion, since most +people think ``source NMU'' when they think ``NMU''. So it's best to +be careful. Best use always ``binary NMU'' or ``binNMU'' for binary-only +NMUs. + Collaborative maintenance @@ -3100,6 +3137,7 @@ This way, `testing' should always be close to being a release candidate. Please see below for details. Updates from unstable +

The scripts that update the testing distribution are run each day after the installation of the updated packages. They generate the Packages files for the testing distribution, but @@ -3165,12 +3203,12 @@ has in testing.

Consider this example:

- - foo | alpha | arm + +foo | alpha | arm ---------+-------+---- testing | 1 | - unstable | 1 | 2 - +

The package is out of date on alpha in unstable, and will not go to testing. And removing foo from testing would not help at all, the package @@ -3178,12 +3216,12 @@ is still out of date on alpha, and will not propagate to testing.

However, if ftp-master removes a package in unstable (here on arm):

- + foo | alpha | arm | hurd-i386 ---------+-------+-----+---------- testing | 1 | 1 | - unstable | 2 | - | 1 - +

In this case, the package is up to date on all release architectures in unstable (and the extra hurd-i386 doesn't matter, as it's not a release @@ -3212,18 +3250,18 @@ depends on the new version of package b, and vice versa.

An example of this is:

- + | testing | unstable --+-----------------+------------ a | 1; depends: b=1 | 2; depends: b=2 b | 1; depends: a=1 | 2; depends: a=2 - +

Package a is not considered for update, and package b also not.

-Currently, this requires some manual hinting from the release masters. -Please, send mail to debian-release@lists.debian.org if that happens to -one of your packages. +Currently, this requires some manual hinting from the release team. +Please, contact them by sending mail to &email-debian-release; if that +happens to one of your packages. @@ -3236,7 +3274,8 @@ even if it is still RC-buggy. The second exception is if the version of the package in testing is out of sync on the different arches: Then any arch might just upgrade to the version of the source package; however, this can happen only if the package was previously forced -through, or the arch is in fuckedarches. +through, the arch is in fuckedarches or there was no binary package of that +arch present in unstable at all during the testing migration.

In summary this means: The only influence that a package being in testing has on a new version of the same package is that the new version might @@ -3304,7 +3343,7 @@ through testing-proposed-updates of the package version 1.2.

- What are release-critical bugs, and how do they get counted? + What are release-critical bugs, and how do they get counted?

All bugs of some higher severities are by default considered release-critical; currently, these are critical, grave and serious bugs.