 |
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 it will 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 uploading. It's the maintainer who is responsible for everything that happens with a bad package, not the FTP Team!
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. The third column 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 a source package. A simple New upstream or Fixed bug isn't great.
| Serious violations (direct rejects even if we only find one point) | ||
|---|---|---|
| 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 NMUs, 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 | There is now a Debian position on software licensed uner the PHP License. It includes specific additional requirements for debian/copyright. | Revised August 2016 |
| 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 some 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. 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 split 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. In Debian Policy we 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 harder 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. There is currently one exception: automatic debug packages are not listed in debian/control file, but are accepted. |
Revised Apr 2016 |
| 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 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, everything 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. | |
| Non-Main II | Tests, including autopkgtests, are part of our build process. Packages in Main can only require packages in Main to run their tests (both build time and autopkgtest). Downloading unpackaged programs, depending on contrib/non-free packages, etc. are not acceptable for Main. We are just adding this now as it turns out this wasn't nearly as obvious to some of you as it was to the FTP Team. | Added Mar 2020 |
| 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 library package without 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, which are source-package based, and also confuses users, who can't 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. | January 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. | January 2008 |
| Source missing | Your package contains files that need source but do not have it. These include PDF and PS files in the documentation, or auto-generated files. | December 2008 |
| Generated files | Your package contains generated files (such as compressed .js libraries) without corresponding original form. They're not considered as the preferred form of modification, so you will either have to provide corresponding original form, or remove them from your tarball, eventually depending on an already available packages to provide missing features. | October 2011 |
| Package uses waf as build system | That's a special case of source code missing. Normally packages using waf as build system contain a Python script with a compressed tarball embedded as a binary blob, where it is not obvious how to get the actual source. As that's not considered to be the preferred form of modification, it fails the DFSG. See #645190 and https://wiki.debian.org/UnpackWaf for details. |
January 2012 |
| Source package missing source | Source packages are part of the distribution. As such source must be present for all files in the source package itself, this includes convenience copies of other projects. | |
| 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 tarball's 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 it's 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 what's 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 it's 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: Mon Oct 19 13:03:23 UTC 2020