Like promised, this post doesn’t start with rivendell
The first objective was testing the module source packages provided with Rivendell. Between etch and intrepid, these modules can be built on several kernel versions (from 2.6.18 to 2.6.27) and waiting errors on the rivendell user mailing-list doesn”t seem a good solution
My CPU is burning for several hours. I’m trying to make the rivendell package cleaner and I’m going to go crazy with the debian packaging tools :-/ The 50th rivendell build is now running .. and I’ve experienced 2 or 3 dozen of various problems with dpkg-source, pbuilder, debarchiver and cie. Debian packaging is a very pretty environment but it’s sometimes a obscur science
There are some notes from my day troubles:
debuild, the wrapper of wrapper: it’s a wrapper for dpkg-buildpkg .. which wraps several dpkg tools
use cdebootsrap with pbuilder (instead of the debootstrap), either you can’t build an etch or sid base
if your package doesn’t end with -0 or -1, the orig.tar.gzwon’t be specified into the changes file, use the -sa option of dpkg-source
if your debarchiver moves your incoming files into a REJECT directory, set the --debug-level to 4 to know more. In my case, the changes file was invalid and designated the wrong tar.gz. Note that logcheck considerates “debug” as a keyword for .. security event .. so fix the logcheck rules to avoid a mail spamming.
My pending problems are:
how run pbuilder without running a whole dpkg-buildpackage ? Because pbuilder uses the files created by dpkg-buildpackage .. and when you need to check the Build-Depends of your package .. it takes the night
how inject my gpg key passphrase to debuild ? via a customized gpg command, or something like ?
something dpkg-buildpackage fails after the initial dpkg-source -b for an unknown reason ..