This page is kept for historic reasons and as a log file of the MOTU/School session, for more general Packaging information, please check out PackagingGuide/Basic.
Packages on revu, that F(ail) T(o) B(uild) F(rom) S(ource)
<sistpoty> I guess one of the first basic mistakes is to upload packages that simply FTBFS <sistpoty> this is quite trivial to fix by test-building them in pbuilder <sistpoty> everyone got a feisty pbuilder at hand? or should I give some hints there <sistpoty> as a side note: it's quite helpful to testbuild packages prior to uploading them to revu. Once you become motus, you'll also make sure to have the packages testbuilt before uploading to the archive ;)
Templates not adjusted
<sistpoty> ok, then some things that more often show up is stuff like "unstable" in the distribution field or plain debian version numbers <sistpoty> I guess this is pretty much related to dh_make templates... <sistpoty> that just aren't adjusted to the real package. <sistpoty> while dh_make creates some basic templates, you should really look at each template and see if it's a) necessary b) what things to put in there so that it makes sense
Version number
<sistpoty> and so is for the package version. to distinguish ubuntu-modified (or created) packages from debian ones <sistpoty> you should use a version suffix of -XubuntuY <sistpoty> more precise, a foo with upstream version 1.2 would be 1.2-1 for a plain debian package <sistpoty> and thus 1.2-0ubuntu1 for ubuntu <sistpoty> the -0 is to make sure, if a debian package is created from the same upstream version, it will get a newer version number <sistpoty> (/me points to merges)
debian/copyright
<sistpoty> ok, let's get to a tougher point, that's often wrong: debian/copyright <sistpoty> ajmitch: want to tell s.th. about debian/copyright? <ajmitch> um <ajmitch> being detailed is essential :) * sistpoty is just looking for the links on the debian mailing list that were quite good about it <ajmitch> since you need to have all the copyright holders listed in there, and there can be difference licenses in different source files <sistpoty> ok, a really good read on this topic is <sistpoty> http://lists.debian.org/debian-legal/2003/12/msg00194.html <sistpoty> and <sistpoty> http://lists.debian.org/debian-devel-announce/2003/12/msg00007.html <sistpoty> also, you need to make sure, that the files fall in fact under a license... if s.th. like "All rights reserved." is in a file, you're almost out, unless explicit permission under a license are granted <sistpoty> you should also take a special look at data files. especially games tend to have some really non-free stuff included, but this is often the hardest part to spot (...) * ajmitch notes that it can be a problem where there are binary files shipped in a source tarball <ajmitch> like silly mono apps that bundle .dlls they need to run :) <sistpoty> ah, yep... back for debian/copyright ;) <sistpoty> if it's GPL, you'll need to stuff full sources in the package. You may additionally put binaries that can be built from the sources put in the package as well, but not the other way round
File locations
<sistpoty> some other things that come to my mind are files installed in wrong places, though this is more rare then the topics we had till now <sistpoty> if you've built a binary package, please take a look at a) what files are in the package b) where these get installed <Adri2000> dpkg -c *deb is your friend ;) <sistpoty> yes <sistpoty> but back to file locations: if you're unsure, where a file should go, the FHS (iirc found in package debian-policy) should give some insights
lintian
<sistpoty> ok, then finally a good hint: you can use lintian to find some basic mistakes... just run it on the .dsc file of your source package <sistpoty> but it is even of more use, if you run it on the resulting binary packages <sistpoty> lintian -i -v will also give you a little bit more verbose hints