Hi As you may have noticed, the beloved target of many flamewars, the NEW queue [1] has been reduced to an average of less than 10 packages. Packages are processed within days, sometimes even within hours. In order to slow it right back down again, so you dont get used to it too much, I decided to become insane and do even more. I plan to add some very rough quality checks - nothing should surprise you, but all of these problems were already seen in the queue. Not everything that makes a package RC-buggy is listed, but will also count as a reason for a reject - iff we notice it. 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! NEW checking is about three things. In order of priority: trying to keep the archive legal, trying to keep the package namespace sane, and trying to reduce the number of bugs in Debian. 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. To avoid flames from surprised maintainers, I have decided to post a little list of things we look for, so you can fix your packages before uploading. All items are things that *really* should never happen anyway, but exist in some packages nonetheless. You can find this list at http://ftp-master.debian.org/REJECT-FAQ.html in the future and that one will also be updated if we need to. This is purely an informational list and is from the top of my head. There may be more reasons. I mark reasons added with this mail with a star, so you can quickly see what's new. Most of the added points are just quality issues. While I'm at it: 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): - 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 http://www.openssl.org/support/faq.html#LEGAL2 or/and http://www.gnome.org/~markmc/openssl-and-the-gpl.html for more information. - 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 is in Footnote [2]. - You have a PHP addon 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[3], is not really usable for anything else than PHP itself. I've mailed[4] 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. - 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 bas 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). - You "break" a transition. Well, right at the moment its the nice C++ ABI thing, but in the future it may be something else. For this C++ one it's basically - if you link against libstdc++5 you are out, *EXCEPT* if you declare a special Build-Depends on the right compiler to get this which most people havent done and its nearly always not part of the build environment. Also having dependencies on non-transitioned C++-libraries gets you rejected. I think most important libs are done, but until recently a nice candidate was libqt[whatever]c102. Watch out c102 names in your Depends lines if you want to be sure. - 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. :) - You try to hijack a package of an active maintainer (or team). Don't do that. - 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* :) - 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 to be able to build all[5] .debs with only one call to debian/rules. Not two, not three. Not an extra script. - Your debian/copyright file must have at least the minimum needed stuff. A good overview of what you need is in the thread starting at http://lists.debian.org/debian-legal/2003/12/msg00188.html - Your upstream tarball needs to include a copy of the license, or debian/copyright needs to explain where it can be found. (eg. the upstream website). In the past there were uploads where one couldnt find the license statement in the tarball or on the website from upstream, which is bad. - Do not include a license that is in /usr/share/common-licenses into your debian/copyright. That's a waste of space. - If the license is not in /usr/share/common-licenses it must be copied verbatim into debian/copyright, a pointer to the package or a website is not enough. - If you want your package in main it must *not* (Build-)Depend: or Recommend: a package which isn't in main too. Thats what we have contrib for. - 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. - 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. - 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 errors and warnings, without a good reason to ignore them can get your package 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. - Watch out if you include a rpath in your binaries. Most of the time this is not what you want but it's easy to fix. See http://wiki.debian.net/index.cgi?RpathIssue for more details. - Use the right package names. A lib should start with lib, a perl module with lib and end with -perl, etc. Minor issues, sometimes also named "Good packaging behaviour". Not a single one is enough to get you a REJECT, but if you collect multiple ones the probability rises: * Have a good description for your package. Both short and long. You should know what you packager does but your users don't. So write something that they will understand *before* they install it. A simple "XY, it does stuff" is not something that should get uploaded. * 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 completly doesn't care for that. * 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. * 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 the hard transition to a newer one. * 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. * 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. * Remove the .ex files from debian/. They are examples and not meant to stay around. * Standards-Version should be the latest available one, not any ancient that may happen to get in with a template you use. * Having a "INSTALL_PROGRAM += -s" setting if nostrip option is set while using dh_strip later. Useless, read man dh_strip please. :) [1] http://ftp-master.debian.org/new.html [2] The "DEB_AUTO_UPDATE_DEBIAN_CONTROL" option turned on modifies Build-Depends, which doesnt affect the build thats 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: a.) Think about it and set the Build- Depends yourself. Thats *easy* and you can check them in pbuilder. b.) Do this only in a special target in debian/rules that is NEVER called automagically. So you can check what it did before you start the real build. [3] But many people still use older ones, like 2.xx. [4] http://lists.debian.org/debian-legal/2005/08/msg00128.html [5] This only includes .debs that should get uploaded. Stuff that's only built by users for their local system doesn't matter. -- bye Joerg I think there's a world market for about five computers. -- attr. Thomas J. Watson (Chairman of the Board, IBM), 1943
Attachment:
pgp7euYqyf3aC.pgp
Description: PGP signature