| 1829 |
<section id="nmu"> |
<section id="nmu"> |
| 1830 |
<title>Non-Maintainer Uploads (NMUs)</title> |
<title>Non-Maintainer Uploads (NMUs)</title> |
| 1831 |
<para> |
<para> |
| 1832 |
Under certain circumstances it is necessary for someone other than the official |
Every package has one or more maintainers. Normally, these are the people who |
| 1833 |
package maintainer to make a release of a package. This is called a |
work on and upload new versions of the package. In some situations, it is |
| 1834 |
non-maintainer upload, or NMU. |
useful that other developers can upload a new version as well, for example if |
| 1835 |
</para> |
they want to fix a bug in a package they don't maintain, when the maintainer |
| 1836 |
<para> |
needs help to respond to issues. Such uploads are called |
| 1837 |
This section handles only source NMUs, i.e. NMUs which upload a new version of |
<emphasis>Non-Maintainer Uploads (NMU)</emphasis>. |
|
the package. For binary-only NMUs by porters or QA members, please see <xref |
|
|
linkend="binary-only-nmu"/> . If a buildd builds and uploads a package, that |
|
|
too is strictly speaking a binary NMU. See <xref linkend="wanna-build"/> for |
|
|
some more information. |
|
|
</para> |
|
|
<para> |
|
|
The main reason why NMUs are done is when a developer needs to fix another |
|
|
developer's package in order to address serious problems or crippling bugs or |
|
|
when the package maintainer is unable to release a fix in a timely fashion. |
|
|
</para> |
|
|
<para> |
|
|
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 |
|
|
<emphasis>not</emphasis> be made in a non-maintainer upload. |
|
| 1838 |
</para> |
</para> |
| 1839 |
|
|
| 1840 |
|
<section id="nmu-guidelines"> |
| 1841 |
|
<title>When and how to do an NMU</title> |
| 1842 |
|
|
| 1843 |
<para> |
<para> |
| 1844 |
And please remember the Hippocratic Oath: Above all, do no harm. It is better |
Before doing an NMU, consider the following questions: |
|
to leave a package with an open grave bug than applying a non-functional patch, |
|
|
or one that hides the bug instead of resolving it. |
|
| 1845 |
</para> |
</para> |
| 1846 |
<section id="nmu-guidelines"> |
<itemizedlist> |
| 1847 |
<title>How to do a NMU</title> |
<listitem> |
| 1848 |
<para> |
<para> |
| 1849 |
NMUs which fix important, serious or higher severity bugs are encouraged and |
Does your NMU really fix bugs? Fixing cosmetic issues or changing the |
| 1850 |
accepted. You should endeavor to reach the current maintainer of the package; |
packaging style in NMUs is discouraged. |
|
they might be just about to upload a fix for the problem, or have a better |
|
|
solution. |
|
| 1851 |
</para> |
</para> |
| 1852 |
|
</listitem> |
| 1853 |
|
<listitem> |
| 1854 |
<para> |
<para> |
| 1855 |
NMUs should be made to assist a package's maintainer in resolving bugs. |
Did you give enough time to the maintainer? When was the bug reported to the |
| 1856 |
Maintainers should be thankful for that help, and NMUers should respect the |
BTS? Being busy for a week or two isn't unusual. Is the bug so severe that it |
| 1857 |
decisions of maintainers, and try to personally help the maintainer by their |
needs to be fixed right now, or can it wait a few more days? |
|
work. |
|
| 1858 |
</para> |
</para> |
| 1859 |
|
</listitem> |
| 1860 |
|
<listitem> |
| 1861 |
<para> |
<para> |
| 1862 |
A NMU should follow all conventions, written down in this section. For an |
How confident are you about your changes? Please remember the Hippocratic Oath: |
| 1863 |
upload to <literal>testing</literal> or <literal>unstable</literal>, this |
"Above all, do no harm." It is better to leave a package with an open grave bug |
| 1864 |
order of steps is recommended: |
than applying a non-functional patch, or one that hides the bug instead of |
| 1865 |
|
resolving it. If you are not 100% sure of what you did, it might be a good idea |
| 1866 |
|
to seek advice from others. Remember that if you break something in your NMU, |
| 1867 |
|
many people will be very unhappy about it. |
| 1868 |
</para> |
</para> |
| 1869 |
<itemizedlist> |
</listitem> |
| 1870 |
<listitem> |
<listitem> |
| 1871 |
<para> |
<para> |
| 1872 |
Make sure that the package's bugs that the NMU is meant to address are all |
Have you clearly expressed your intention to NMU, at least in the BTS? |
| 1873 |
filed in the Debian Bug Tracking System (BTS). If they are not, submit them |
It is also a good idea to try to contact the |
| 1874 |
immediately. |
maintainer by other means (private email, IRC). |
| 1875 |
</para> |
</para> |
| 1876 |
</listitem> |
</listitem> |
| 1877 |
<listitem> |
<listitem> |
| 1878 |
<para> |
<para> |
| 1879 |
Wait a few days for the response from the maintainer. If you don't get any |
If the maintainer is usually active and responsive, have you tried to contact |
| 1880 |
response, you may want to help them by sending the patch that fixes the bug. |
him? In general it should be considered preferable that a maintainer takes care |
| 1881 |
Don't forget to tag the bug with the patch keyword. |
of an issue himself and that he is given the chance to review and correct your |
| 1882 |
|
patch, because he can be expected to be more aware of potential issues which an |
| 1883 |
|
NMUer might miss. It is often a better use of everyone's time if the maintainer |
| 1884 |
|
is given an opportunity to upload a fix on their own. |
| 1885 |
</para> |
</para> |
| 1886 |
</listitem> |
</listitem> |
| 1887 |
|
</itemizedlist> |
| 1888 |
|
<para> |
| 1889 |
|
When doing an NMU, you must first make sure that your intention to NMU is |
| 1890 |
|
clear. Then, you must send a patch with the differences between the |
| 1891 |
|
current package and your proposed NMU to the BTS. The |
| 1892 |
|
<literal>nmudiff</literal> script in the <literal>devscripts</literal> package |
| 1893 |
|
might be helpful. |
| 1894 |
|
</para> |
| 1895 |
|
<para> |
| 1896 |
|
While preparing the patch, you should better be aware of any package-specific |
| 1897 |
|
practices that the maintainer might be using. Taking them into account reduces |
| 1898 |
|
the burden of getting your changes integrated back in the normal package |
| 1899 |
|
workflow and thus increases the possibilities that that will happen. A good |
| 1900 |
|
place where to look for for possible package-specific practices is |
| 1901 |
|
<ulink url="&url-debian-policy;ch-source.html#s-readmesource"><literal>debian/README.source</literal></ulink>. |
| 1902 |
|
</para> |
| 1903 |
|
<para> |
| 1904 |
|
Unless you have an excellent reason not to do so, you must then give some time |
| 1905 |
|
to the maintainer to react (for example, by uploading to the |
| 1906 |
|
<literal>DELAYED</literal> queue). Here are some recommended values to use for delays: |
| 1907 |
|
</para> |
| 1908 |
|
<itemizedlist> |
| 1909 |
<listitem> |
<listitem> |
| 1910 |
<para> |
<para> |
| 1911 |
Wait a few more days. If you still haven't got an answer from the maintainer, |
Upload fixing only release-critical bugs older than 7 days: 2 days |
|
send them a mail announcing your intent to NMU the package. Prepare an NMU as |
|
|
described in this section, and test it carefully on your machine (cf. <xref |
|
|
linkend="sanitycheck"/> ). Double check that your patch doesn't have any |
|
|
unexpected side effects. Make sure your patch is as small and as |
|
|
non-disruptive as it can be. |
|
| 1912 |
</para> |
</para> |
| 1913 |
</listitem> |
</listitem> |
| 1914 |
<listitem> |
<listitem> |
| 1915 |
<para> |
<para> |
| 1916 |
Upload your package to incoming in <filename>DELAYED/7-day</filename> (cf. |
Upload fixing only release-critical and important bugs: 5 days |
|
<xref linkend="delayed-incoming"/> ), send the final patch to the maintainer |
|
|
via the BTS, and explain to them that they have 7 days to react if they want to |
|
|
cancel the NMU. |
|
| 1917 |
</para> |
</para> |
| 1918 |
</listitem> |
</listitem> |
| 1919 |
<listitem> |
<listitem> |
| 1920 |
<para> |
<para> |
| 1921 |
Follow what happens, you're responsible for any bug that you introduced with |
Other NMUs: 10 days |
|
your NMU. You should probably use <xref linkend="pkg-tracking-system"/> (PTS) |
|
|
to stay informed of the state of the package after your NMU. |
|
| 1922 |
</para> |
</para> |
| 1923 |
</listitem> |
</listitem> |
| 1924 |
</itemizedlist> |
</itemizedlist> |
| 1925 |
|
|
| 1926 |
<para> |
<para> |
| 1927 |
At times, the release manager or an organized group of developers can announce |
Those delays are only examples. In some cases, such as uploads fixing security |
| 1928 |
a certain period of time in which the NMU rules are relaxed. This usually |
issues, or fixes for trivial bugs that blocking a transition, it is desirable |
| 1929 |
involves shortening the period during which one is to wait before uploading the |
that the fixed package reaches <literal>unstable</literal> sooner. |
|
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. Please see <xref |
|
|
linkend="qa-bsp"/> for details. |
|
| 1930 |
</para> |
</para> |
| 1931 |
|
|
| 1932 |
<para> |
<para> |
| 1933 |
For the <literal>testing</literal> distribution, the rules may be changed by |
Sometimes, release managers decide to allow NMUs with shorter delays for a |
| 1934 |
the release managers. Please take additional care, and acknowledge that the |
subset of bugs (e.g release-critical bugs older than 7 days). Also, some |
| 1935 |
usual way for a package to enter <literal>testing</literal> is through |
maintainers list themselves in the <ulink url="&url-low-threshold-nmu;">Low |
| 1936 |
<literal>unstable</literal>. |
Threshold NMU list</ulink>, and accept that NMUs are uploaded without delay. But |
| 1937 |
|
even in those cases, it's still a good idea to give the maintainer a few days |
| 1938 |
|
to react before you upload, especially if the patch wasn't available in the BTS |
| 1939 |
|
before, or if you know that the maintainer is generally active. |
| 1940 |
</para> |
</para> |
| 1941 |
|
|
| 1942 |
<para> |
<para> |
| 1943 |
For the stable distribution, please take extra care. Of course, the release |
After you upload an NMU, you are responsible for the possible problems that you |
| 1944 |
managers may also change the rules here. Please verify before you upload that |
might have introduced. You must keep an eye on the package (subscribing to the |
| 1945 |
all your changes are OK for inclusion into the next stable release by the |
package on the PTS is a good way to achieve this). |
|
release manager. |
|
| 1946 |
</para> |
</para> |
| 1947 |
|
|
| 1948 |
<para> |
<para> |
| 1949 |
When a security bug is detected, the security team may do an NMU, using their |
This is not a license to perform NMUs thoughtlessly. If you NMU when it is |
| 1950 |
own rules. Please refer to <xref linkend="bug-security"/> for more |
clear that the maintainers are active and would have acknowledged a patch in a |
| 1951 |
information. |
timely manner, or if you ignore the recommendations of this document, your |
| 1952 |
|
upload might be a cause of conflict with the maintainer. |
| 1953 |
|
You should always be prepared to |
| 1954 |
|
defend the wisdom of any NMU you perform on its own merits. |
| 1955 |
</para> |
</para> |
| 1956 |
|
</section> |
| 1957 |
|
|
| 1958 |
|
<section id="nmu-changelog"> |
| 1959 |
|
<title>NMUs and debian/changelog</title> |
| 1960 |
<para> |
<para> |
| 1961 |
For the differences for Porters NMUs, please see <xref |
Just like any other (source) upload, NMUs must add an entry to |
| 1962 |
linkend="source-nmu-when-porter"/> . |
<literal>debian/changelog</literal>, telling what has changed with this |
| 1963 |
|
upload. The first line of this entry must explicitely mention that this upload is an NMU, e.g.: |
| 1964 |
</para> |
</para> |
| 1965 |
|
<screen> |
| 1966 |
|
* Non-maintainer upload. |
| 1967 |
|
</screen> |
| 1968 |
|
|
| 1969 |
<para> |
<para> |
| 1970 |
Of course, it is always possible to agree on special rules with a maintainer |
The version must be the version of the last maintainer upload, plus |
| 1971 |
(like the maintainer asking please upload this fix directly for me, and no diff |
<literal>+nmu<replaceable>X</replaceable></literal>, where |
| 1972 |
required). |
<replaceable>X</replaceable> is a counter starting at <literal>1</literal>. If |
| 1973 |
|
the last upload was also an NMU, the counter should be increased. For example, |
| 1974 |
|
if the current version is <literal>1.5-1</literal>, then an NMU would get |
| 1975 |
|
version <literal>1.5-1+nmu1</literal>. If the current version is |
| 1976 |
|
<literal>1.5+nmu3</literal> (a native package which has already been NMUed), the |
| 1977 |
|
NMU would get version <literal>1.5+nmu4</literal>. If a new upstream version |
| 1978 |
|
is packaged in the NMU, the debian revision is set to <literal>0</literal>, for |
| 1979 |
|
example <literal>1.6-0+nmu1</literal>. |
| 1980 |
</para> |
</para> |
|
</section> |
|
| 1981 |
|
|
|
<section id="nmu-version"> |
|
|
<title>NMU version numbering</title> |
|
| 1982 |
<para> |
<para> |
| 1983 |
Whenever you have made a change to a package, no matter how trivial, the |
A special versioning scheme is needed to avoid disrupting the maintainer's |
| 1984 |
version number needs to change. This enables our packing system to function. |
work, since using an integer for the Debian revision will potentially |
| 1985 |
|
conflict with a maintainer upload already in preparation at the time of an |
| 1986 |
|
NMU, or even one sitting in the ftp NEW queue. |
| 1987 |
|
It also has the |
| 1988 |
|
benefit of making it visually clear that a package in the archive was not made |
| 1989 |
|
by the official maintainer. |
| 1990 |
</para> |
</para> |
| 1991 |
|
|
| 1992 |
<para> |
<para> |
| 1993 |
If you are doing a non-maintainer upload (NMU), you should add a new minor |
If you upload a package to testing or stable, you sometimes need to "fork" the |
| 1994 |
version number to the <replaceable>debian-revision</replaceable> part of the |
version number tree. This is the case for security uploads, for example. For |
| 1995 |
version number (the portion after the last hyphen). This extra minor number |
this, a version of the form |
| 1996 |
will start at `1'. For example, consider the package `foo', which is at |
<literal>+deb<replaceable>XY</replaceable>u<replaceable>Z</replaceable></literal> |
| 1997 |
version 1.1-3. In the archive, the source package control file would be |
should be used, where <replaceable>X</replaceable> and |
| 1998 |
<filename>foo_1.1-3.dsc</filename>. The upstream version is `1.1' and the |
<replaceable>Y</replaceable> are the major and minor release numbers, and |
| 1999 |
Debian revision is `3'. The next NMU would add a new minor number `.1' to the |
<replaceable>Z</replaceable> is a counter starting at <literal>1</literal>. |
| 2000 |
Debian revision; the new source control file would be |
When the release number is not yet known (often the case for |
| 2001 |
<filename>foo_1.1-3.1.dsc</filename>. |
<literal>testing</literal>, at the beginning of release cycles), the lower |
| 2002 |
|
release number higher than the last stable release number must be used. For |
| 2003 |
|
example, while Etch (Debian 4.0) is stable, a security NMU to stable for a |
| 2004 |
|
package at version <literal>1.5-3</literal> would have version |
| 2005 |
|
<literal>1.5-3+deb40u1</literal>, whereas a security NMU to Lenny would get |
| 2006 |
|
version <literal>1.5-3+deb50u1</literal>. After the release of Lenny, security |
| 2007 |
|
uploads to the <literal>testing</literal> distribution will be versioned |
| 2008 |
|
<literal>+deb51uZ</literal>, until it is known whether that release will be |
| 2009 |
|
Debian 5.1 or Debian 6.0 (if that becomes the case, uploads will be versioned |
| 2010 |
|
as <literal>+deb60uZ</literal>. |
| 2011 |
</para> |
</para> |
| 2012 |
|
</section> |
| 2013 |
|
|
| 2014 |
|
<section id="nmu-delayed"> |
| 2015 |
|
<title>Using the <literal>DELAYED/</literal> queue</title> |
| 2016 |
|
|
| 2017 |
<para> |
<para> |
| 2018 |
The Debian revision minor number is needed to avoid stealing one of the package |
Having to wait for a response after you request permission to NMU is |
| 2019 |
maintainer's version numbers, which might disrupt their work. It also has the |
inefficient, because it costs the NMUer a context switch to come back to the |
| 2020 |
benefit of making it visually clear that a package in the archive was not made |
issue. |
| 2021 |
by the official maintainer. |
The <literal>DELAYED</literal> queue (see <xref linkend="delayed-incoming"/>) |
| 2022 |
|
allows the developer doing the NMU to perform all the necessary tasks at the |
| 2023 |
|
same time. For instance, instead of telling the maintainer that you will |
| 2024 |
|
upload the updated |
| 2025 |
|
package in 7 days, you should upload the package to |
| 2026 |
|
<literal>DELAYED/7</literal> and tell the maintainer that he has 7 days to |
| 2027 |
|
react. During this time, the maintainer can ask you to delay the upload some |
| 2028 |
|
more, or cancel your upload. |
| 2029 |
</para> |
</para> |
| 2030 |
|
|
| 2031 |
<para> |
<para> |
| 2032 |
If there is no <replaceable>debian-revision</replaceable> component in the |
The <literal>DELAYED</literal> queue should not be used to put additional |
| 2033 |
version number then one should be created, starting at `0.1' (but in case of a |
pressure on the maintainer. In particular, it's important that you are |
| 2034 |
debian native package still upload it as native package). If it is absolutely |
available to cancel or delay the upload before the delay expires since the |
| 2035 |
necessary for someone other than the usual maintainer to make a release based |
maintainer cannot cancel the upload himself. |
|
on a new upstream version then the person making the release should start with |
|
|
the <replaceable>debian-revision</replaceable> value `0.1'. The usual |
|
|
maintainer of a package should start their |
|
|
<replaceable>debian-revision</replaceable> numbering at `1'. |
|
| 2036 |
</para> |
</para> |
| 2037 |
|
|
| 2038 |
<para> |
<para> |
| 2039 |
If you upload a package to <literal>testing</literal> or <literal>stable |
If you make an NMU to <literal>DELAYED</literal> and the maintainer updates |
| 2040 |
</literal>, sometimes, you need to fork the version number tree. For this, |
his package before the delay expires, your upload will be rejected because a |
| 2041 |
version numbers like 1.1-3sarge0.1 could be used. |
newer version is already available in the archive. |
| 2042 |
|
Ideally, the maintainer will take care to include your proposed changes (or |
| 2043 |
|
at least a solution for the problems they address) in that upload. |
| 2044 |
</para> |
</para> |
| 2045 |
|
|
| 2046 |
</section> |
</section> |
| 2047 |
|
|
| 2048 |
<section id="nmu-changelog"> |
<section id="nmu-maintainer"> |
| 2049 |
<title>Source NMUs must have a new changelog entry</title> |
<title>NMUs from the maintainer's point of view</title> |
| 2050 |
|
|
| 2051 |
<para> |
<para> |
| 2052 |
Anyone who is doing a source NMU must create a changelog entry, describing |
When someone NMUs your package, this means they want to help you to keep it in |
| 2053 |
which bugs are fixed by the NMU, and generally why the NMU was required and |
good shape. This gives users fixed packages faster. You |
| 2054 |
what it fixed. The changelog entry will have the email address of the person |
can consider asking the NMUer to become a co-maintainer of the package. |
| 2055 |
who uploaded it in the log entry and the NMU version number in it. |
Receiving an NMU on a package is not a bad |
| 2056 |
|
thing; it just means that the package is interesting enough for other people to |
| 2057 |
|
work on it. |
| 2058 |
</para> |
</para> |
| 2059 |
|
|
| 2060 |
<para> |
<para> |
| 2061 |
By convention, source NMU changelog entries start with the line |
To acknowledge an NMU, include its changes and changelog entry in your next |
| 2062 |
|
maintainer upload. If you do not acknowledge the NMU by including the |
| 2063 |
|
NMU changelog entry in your changelog, the bugs will remain closed in the |
| 2064 |
|
BTS but will be listed as affecting your maintainer version of the package. |
| 2065 |
</para> |
</para> |
| 2066 |
<screen> |
|
|
* Non-maintainer upload |
|
|
</screen> |
|
| 2067 |
</section> |
</section> |
| 2068 |
|
|
| 2069 |
<section id="nmu-patch"> |
<section id="nmu-binnmu"> |
| 2070 |
<title>Source NMUs and the Bug Tracking System</title> |
<title>Source NMUs vs Binary-only NMUs (binNMUs)</title> |
| 2071 |
|
|
| 2072 |
<para> |
<para> |
| 2073 |
Maintainers other than the official package maintainer should make as few |
The full name of an NMU is <emphasis>source NMU</emphasis>. There is also |
| 2074 |
changes to the package as possible, and they should always send a patch as a |
another type, namely the <emphasis>binary-only NMU</emphasis>, or |
| 2075 |
unified context diff (<literal>diff -u</literal>) detailing their changes to |
<emphasis>binNMU</emphasis>. A binNMU is also a package upload by someone |
| 2076 |
the Bug Tracking System. |
other than the package's maintainer. However, it is a binary-only upload. |
|
</para> |
|
|
<para> |
|
|
What if you are simply recompiling the package? If you just need to recompile |
|
|
it for a single architecture, then you may do a binary-only NMU as described in |
|
|
<xref linkend="binary-only-nmu"/> which doesn't require any patch to be sent. |
|
|
If you want the package to be recompiled for all architectures, then you do a |
|
|
source NMU as usual and you will have to send a patch. |
|
|
</para> |
|
|
<para> |
|
|
Bugs fixed by source NMUs used to be tagged fixed instead of closed, but since |
|
|
version tracking is in place, such bugs are now also closed with the NMU |
|
|
version. |
|
|
</para> |
|
|
<para> |
|
|
Also, after doing an NMU, you have to send the information to the existing bugs |
|
|
that are fixed by your NMU, including the unified diff. Historically, it was |
|
|
custom to 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. If the maintainer |
|
|
decides not to apply the NMU's patch but to release a new version, the |
|
|
maintainer needs to ensure that the new upstream version really fixes each |
|
|
problem that was fixed in the non-maintainer release. |
|
|
</para> |
|
|
<para> |
|
|
In addition, the normal maintainer should <emphasis>always</emphasis> retain |
|
|
the entry in the changelog file documenting the non-maintainer upload -- and of |
|
|
course, also keep the changes. If you revert some of the changes, please |
|
|
reopen the relevant bug reports. |
|
| 2077 |
</para> |
</para> |
|
</section> |
|
| 2078 |
|
|
|
<section id="nmu-build"> |
|
|
<title>Building source NMUs</title> |
|
| 2079 |
<para> |
<para> |
| 2080 |
Source NMU packages are built normally. Pick a distribution using the same |
When a library (or other dependency) is updated, the packages using it may need |
| 2081 |
rules as found in <xref linkend="distribution"/> , follow the other |
to be rebuilt. Since no changes to the source are needed, the same source |
| 2082 |
instructions in <xref linkend="upload"/> . |
package is used. |
| 2083 |
</para> |
</para> |
| 2084 |
|
|
| 2085 |
<para> |
<para> |
| 2086 |
Make sure you do <emphasis>not</emphasis> change the value of the maintainer in |
BinNMUs are usually triggered on the buildds by wanna-build. |
| 2087 |
the <filename>debian/control</filename> file. Your name as given in the NMU |
An entry is added to debian/changelog, |
| 2088 |
entry of the <filename>debian/changelog</filename> file will be used for |
explaining why the upload was needed and increasing the version number as |
| 2089 |
signing the changes file. |
described in <xref linkend="binary-only-nmu"/>. |
| 2090 |
|
This entry should not be included in the next upload. |
| 2091 |
</para> |
</para> |
|
</section> |
|
| 2092 |
|
|
|
<section id="ack-nmu"> |
|
|
<title>Acknowledging an NMU</title> |
|
| 2093 |
<para> |
<para> |
| 2094 |
If one of your packages has been NMU'ed, you have to incorporate the changes in |
Buildds upload packages for their architecture to the archive as binary-only |
| 2095 |
your copy of the sources. This is easy, you just have to apply the patch that |
uploads. Strictly speaking, these are binNMUs. However, they are not normally |
| 2096 |
has been sent to you. Once this is done, you have to close the bugs that have |
called NMU, and they don't add an entry to debian/changelog. |
|
been tagged fixed by the NMU. The easiest way is to use the |
|
|
<literal>-v</literal> option of <command>dpkg-buildpackage</command>, as this |
|
|
allows you to include just all changes since your last maintainer upload. |
|
|
Alternatively, you can close them manually by sending the required mails to the |
|
|
BTS or by adding the required <literal>closes: #nnnn</literal> in the changelog |
|
|
entry of your next upload. |
|
|
</para> |
|
|
<para> |
|
|
In any case, you should not be upset by the NMU. An NMU is not a personal |
|
|
attack against the maintainer. It is a proof that someone cares enough about |
|
|
the package that they were willing to help you in your work, so you should be |
|
|
thankful. You may also want to ask them if they would be interested in helping |
|
|
you on a more frequent basis as co-maintainer or backup maintainer (see <xref |
|
|
linkend="collaborative-maint"/> ). |
|
| 2097 |
</para> |
</para> |
| 2098 |
|
|
| 2099 |
</section> |
</section> |
| 2100 |
|
|
| 2101 |
<section id="nmu-vs-qa"> |
<section id="nmu-qa-upload"> |
| 2102 |
<title>NMU vs QA uploads</title> |
<title>NMUs vs QA uploads</title> |
| 2103 |
|
|
| 2104 |
<para> |
<para> |
| 2105 |
Unless you know the maintainer is still active, it is wise to check the package |
NMUs are uploads of packages by somebody else than their assigned maintainer. |
| 2106 |
to see if it has been orphaned. The current list of orphaned packages which |
There is |
| 2107 |
haven't had their maintainer set correctly is available at <ulink |
another type of upload where the uploaded package is not yours: QA uploads. QA |
| 2108 |
url="&url-debian-qa-orphaned;"></ulink>. If you perform an NMU on an |
uploads are uploads of orphaned packages. |
|
improperly orphaned package, please set the maintainer to <literal>Debian QA Group |
|
|
<packages@qa.debian.org></literal>. |
|
| 2109 |
</para> |
</para> |
|
</section> |
|
| 2110 |
|
|
|
<section id="nmu-who"> |
|
|
<title>Who can do an NMU</title> |
|
| 2111 |
<para> |
<para> |
| 2112 |
Only official, registered Debian Developers can do binary or source NMUs. A |
QA uploads are very much like normal maintainer uploads: they may fix anything, |
| 2113 |
Debian Developer is someone who has their key in the Debian key ring. |
even minor issues; the version numbering is normal, and there is no need to use |
| 2114 |
Non-developers, however, are encouraged to download the source package and |
a delayed upload. The difference is that you are not listed as the Maintainer |
| 2115 |
start hacking on it to fix problems; however, rather than doing an NMU, they |
or Uploader for the package. Also, the changelog entry of a QA upload has a |
| 2116 |
should just submit worthwhile patches to the Bug Tracking System. Maintainers |
special first line: |
|
almost always appreciate quality patches and bug reports. |
|
| 2117 |
</para> |
</para> |
|
</section> |
|
| 2118 |
|
|
| 2119 |
<section id="nmu-terms"> |
<screen> |
| 2120 |
<title>Terminology</title> |
* QA upload. |
| 2121 |
|
</screen> |
| 2122 |
|
|
| 2123 |
<para> |
<para> |
| 2124 |
There are two new terms used throughout this section: ``binary-only NMU'' and |
If you want to do an NMU, and it seems that the maintainer is not active, it is |
| 2125 |
``source NMU''. These terms are used with specific technical meaning |
wise to check if the package is orphaned |
| 2126 |
throughout this document. Both binary-only and source NMUs are similar, since |
(this information is displayed on the package's Package Tracking System page). |
| 2127 |
they involve an upload of a package by a developer who is not the official |
When doing the first QA upload to an |
| 2128 |
maintainer of that package. That is why it's a |
orphaned package, the maintainer should be set to <literal>Debian QA Group |
| 2129 |
<literal>non-maintainer</literal> upload. |
<packages@qa.debian.org></literal>. Orphaned packages which did |
| 2130 |
</para> |
not yet have a QA upload still have their old maintainer set. There is a list |
| 2131 |
<para> |
of them at <ulink url="&url-orphaned-not-qa;"/>. |
|
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 |
|
|
<filename>debian/changelog</filename>). 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. |
|
|
</para> |
|
|
<para> |
|
|
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. |
|
|
</para> |
|
|
<para> |
|
|
Both classes of NMUs, source and binary-only, can be lumped under 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: always use |
|
|
``binary NMU'' or ``binNMU'' for binary-only NMUs. |
|
| 2132 |
</para> |
</para> |
| 2133 |
|
|
| 2134 |
|
<para> |
| 2135 |
|
Instead of doing a QA upload, you can also consider adopting the package by |
| 2136 |
|
making yourself the maintainer. You don't need permission from anybody to |
| 2137 |
|
adopt an orphaned package, you can just set yourself as maintainer and upload |
| 2138 |
|
the new version (see <xref linkend="adopting"/>). |
| 2139 |
|
</para> |
| 2140 |
|
|
| 2141 |
</section> |
</section> |
| 2142 |
|
|
| 2143 |
</section> |
</section> |
Parent Directory
| 
Revision Log
| 
Patch