 |
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
