 |
+
+ Reject FAQ for Debian's NEW-Queue | + + |
+
 |
+
+
NEW checking is about three things. In order of + priority:
+ +Not all QA issues will be noticed; we don't test + packages, but we do look through them and note problems that jump out at + us. Sometimes that'll result in a bug, sometimes it will result in an + email, sometimes it will result in a REJECT, depending on how serious the + issue seems.
+ +Of course this does not take away the developers + responsibility to do their own QA before upload. Its the maintainer who + is responsible for everything that happens with a bad package, not the + ftpteam!
+ +All items are things that really should never + happen anyway, but exist in some packages nonetheless. Visit this list + from time to time, as we may change points or add new ones.
+ +Note: This is a purely informational list, there may be + more reasons. If there is a third column it states the date when the + entry was added to this list.
+ +If you want to make it easy for us, then please state + why you've added a NEW binary package or renamed source. A simple + New upstream or Fixed bug isn't great.
+ +| Serious violations (direct rejects + even if we only find one point) | +||
|---|---|---|
| OpenSSL | + +You have a GPL program linking with OpenSSL. This is only ok if + upstream gave a license exception for this otherwise the two licenses + are incompatible. Visit the OpenSSL FAQ + or/and another + infotext for more information. | + ++ |
| CDBS | + +
+ You have a cdbs package and for whatever reason turned on the
+ play with my debian/control in a bad way option. See
+ #311724 for a long text
+ on that matter. + Small overview: The DEB_AUTO_UPDATE_DEBIAN_CONTROL option + turned on modifies Build-Depends, which doesn't affect the build + that's running. But it affects all following builds, which can be + NMU, buildd builds and worst case: security builds. You DO + NOT want to have such a build getting a different result + (except for the small changes intended with the build) just because + there is now another thing in the build-depends. + Two solutions for this: + +
|
+
+ + |
| PHP License | + +You have a PHP add-on package (any php script/"app"/thing, not
+ PHP itself) and its licensed only under the standard PHP license.
+ That license, up to the 3.x which is actually out, is not really
+ usable for anything else than PHP itself.
+ I've
+ mailed our -legal list about that and got only one response,
+ which basically supported my view on this. Basically this license
+ talks only about PHP, the PHP Group and includes Zend Engine,
+ so its not applicable to anything else. And even worse, older
+ versions include the nice ad-clause. + One good solution here is to suggest a license change to your + upstream, as they clearly wanted a free one. LGPL or BSD seems to be + what they want. |
+
+ + |
| License | + +Be sure that you correctly document the license of the package. + We often find packages having a GPL COPYING file in the source, but + if one goes and looks at every file there are a few here and there + having different licenses in them, sometimes as bad as You aren't + allowed to do anything with this file, and if you do we will send our + lawyers to you. Of course it's hard to check a tarball with + thousands of files (think about X, KDE, Kernel or similar big + packages), but most of the tarballs aren't that big. Also not-nice is + a package, itself being GPL, having documentation licensed with a + non-free license, like the CC licenses. Makes the original tarball + non-free, this is one of the cases where you need to repackage it + (look in the archive for examples, mostly having .dfsg. in their + tarballs name). | + ++ |
| Transition | + +You break a transition. Like, in the past we had the + C++ one, but there might be any number of transitions running. + + + + + + + + + + + | + ++ |
| Experimental Library | + +Also not good is to build against a version of a library only in + experimental, but uploading to unstable. We may not detect all of + that, but if it happens the package will be rejected. | + ++ |
| Hijack | + +You try to hijack a package of an active maintainer ( or team). + Don't do that. | + ++ |
| Package split | + +You split a package too much or in a broken way. Well, broken or + too much is a wide definition, so this is a case-by-case thing, but + you should really think about a split before you do it. For example + it doesn't make any sense to split a 50k arch:all package from a 250k + arch:any one. Or splitting a package for only one file, depending on + the main package. Yes, big dependency chains can be a reason. Or big + documentation splitted into one -doc package. The point there is + big. | + ++ |
| FTBFSIASW | + +Your package fails to build from source in a sane way. A
+ good example is behind #300683,
+ but I can think of more creative ways to do it. Basically you need be able
+ to build all .debs with only one call to debian/rules. Not two, not three.
+ Not an extra script. + This only includes .debs that should get uploaded. Stuff that's only + built by users for their local system doesn't matter. |
+
+ + |
| debian/control breakage #2 | + +Your package builds binary packages not listed in
+ debian/control.
+ While this is technically possible it is not allowed, all
+ binaries need to be listed in your control file *prior* to the
+ build (ie. that information needs to be included in the uploaded
+ source). This mostly happens to kernel-module packages. + + Now, if you follow Policy you have + + Section 5.2 (Source package control files -- debian/control) + which says + +
+ The debian/control file contains the most vital (and
+ version-independent) information about the source package and
+ about the binary packages it creates. + The source package control file is generated by + dpkg-source when it builds the source archive, from other files + in the source package, + + + + which basically means that everything must be defined at the + beginning of the build.+ + Following the Binary reference we find + + Section 5.6.19 (Binary) where the important part reads + + + + When it appears in the .dsc file it is the list of binary + packages which a source package can produce. It does not + necessarily produce all of these binary packages for every + architecture. The source control file doesn't contain details of + which architectures are appropriate for which of the binary + packages. + + + + Putting all of that together you can simplify it with + debian/control has to contain a list of binaries to be built + before the build-process starts, do not modify that in + the running build-process. + ++ + Of course that makes life hard(er) for packages like kernel + modules. But not that much. There is nothing to say against a + target in debian/rules that generates the control file + for you, IFF this is only run manually. And if you run in + troubles with debhelper's -a you may want to read man debhelper(7) for + the -s switch. + |
+
+ Feb 2006 | +
| Copyright | + +Your debian/copyright file must have at least the minimum needed + stuff. A good overview of what you need is behind + this mail. | + ++ |
| License II | +If the upstream tarball does not include a copy of the license, + debian/copyright must document when and how the license information was + obtained (i.e. include "Downloaded by John Doe on 2008-12-24 from + http://example.net/license" or reproduce email correspondence including + some header) in addition to the reproducing the license itself. + In the past there were uploads where one couldn't + find the license statement in the tarball or on the website from + upstream, which is bad. + | +Revised Dec 2008 | +
| License III | +You need to list all + copyright information with all licenses in the copyright file itself. That one has + to be the single point of information. Only files you find in /usr/share/common-licenses + have a special exception here, everthing else needs to be fully included! | +Revised Dec 2008 | +
| Non-Main | + +If you want your package in main it must not + (Build-)Depend: or Recommend: a package which isn't in main too. + That's what we have contrib for. | + ++ |
| Package Content | + +You most probably want to have some content in your package. From + time to time we find packages which don't have any. An example is a + rename of a lib* package, but to miss updating the place where the + files are installed. | + ++ |
| Policy Violation | + +It should really not violate policy, for example violating FHS. + Like installing libFOO.so in /usr/share, creating random new + /pathentries or any other obvious policy violation. | + ++ |
| Contents of orig.tar.gz | + +If you rebuild the orig.tar.gz (in the few cases this is needed, + most of the times it is NOT) - be sure to not include .so/.a/other + compiled files. You should also exclude + .cvs/.svn/.whatever_your_version_control_system_has directories you + added. | + ++ |
| Lintian | + +Lintian errors and warnings, without a good reason to ignore them + can get you a reject. Sometimes there are valid reasons, but then you + should either file a bug against lintian if it's generally wrong or + include an override in your package, giving a reason in the changelog + for it. | + ++ |
| rpath | + +Watch out if you include a rpath in your binaries. Most of the + time this is not what you want but it is easy to fix. See + this Wiki for + more. | + ++ |
| Package name | + +Use the right package names. A lib should start with lib, a perl + module with lib and end with -perl, etc. | + ++ |
| Common license | + +Do not include a license that is in /usr/share/common-licenses + into your debian/copyright. That's a waste of space. | + ++ |
| Renaming source for DFSG-removals | + +Do not rename the source if you delete files that are not DFSG free. + Instead add a .dfsg. somewhere to the version part to mark it. Renaming the source + just confuses tools like the PTS who are source-package based, and also confuses + users who cant simply fetch sources anymore without looking what source package + it is first. + | + +June 2006 | +
| Wrong license pointer | + +Be careful at what file in /usr/share/common-licenses you + point. (L)GPL is only correct if the licensing allows you + to chose "or any later" version. If it does not and you have a + licensing that does not give you that option you have to use the + versioned file (L)GPL-2 or -3. | +Januar 2008 | +
| Symbol file wrong | + +Your symbol file contains errors, as reported from lintian + with the two tags + symbols-file-contains-current-version-with-debian-revision + and symbols-file-contains-debian-revision. + | +Januar 2008 | +
| Source missing | +Your packages contains files that need source + but do not have it. These include PDF and PS files in the documentation. | +December 2008 | +
| Minor issues, sometimes also named + "Good packaging behavior". Not a single one is enough to get you a + REJECT, but if you collect multiple ones the probability rises: | +||
|---|---|---|
| Description | + +Have a good description for your package. Both short and long. + You should know what your package does but your users don't. So write + something that they know what they get before they install it. + A simple XY, it does stuff is nothing that should get + uploaded. | + +August 2005 | +
| Repackage orig.tar.gz | + +Do not repackage your orig.tar.gz unless you have to. If you need + to remove files due to license issues - OK. But for example to have + the directory in the tarball named pkgname-ver you DO NOT repackage. + dpkg-source completely doesn't care about that. | + +August 2005 | +
| Native/Non-Native | + +Be sure to look for native/non-native build. Its easy to build a + package native because you had a spelling error in the upstream + tarballs name. Simple solution: Whenever you have a -X in your + version number (ie a debian-revision) look if you have a .diff.gz + before you upload. | + +August 2005 | +
| Multiple versions | + +Do not add the third version of a lib/program. Get RID of them + instead. Always try to not have more than two version of a + library/program in, and that also only if its needed due to a hard + transition to the newer one. | + +August 2005 | +
| debian/rules | + +Have a clear debian/rules file. A bad example are the dh-make + templates. As the name says: they are templates. Edit them, test your + package and then delete the whole bunch of commands that are + commented out, make it hard to read and do not help. If you later + need anything: Type dh_[TAB][TAB] to see whats available. | + +August 2005 | +
| .ex files | + +Remove the .ex files from debian/. They are examples not meant to + stay around. | + +August 2005 | +
| Standards-Version | + +Standards-Version should be the latest available one, not any + ancient that may happen to get in with a template you use. | + +August 2005 | +
| Manpages | + +Write manpages. Yes. Really. Write them. Well. It's basically: If + your program/tool has a --help and --version commandline option you + can simply run + help2man and have a working + start. Such easy ones are near to a reject. Yes, there are things in + the archive where its hard to write manpages. | + +August 2005 | +
| Useless Settings | + +Having a "INSTALL_PROGRAM += -s" setting if nostrip option is set + while using dh_strip later. Useless, read man dh_strip please. There + may be other things like this, this is just a prominent example. If + they are there - remove them please. | + +August 2005 | +
Last modified: Sat Dec 13 15:58:41 UTC 2008
+
+
+