Building packages is a task that every system administrator will end up doing. Most of the time this is not a very interesting task but someone has to do it, right? Normally you will end up modifying and tweaking based on your own needs an existing package that was built by the maintainers of the Linux distribution that you are using. In time you might even become familiar with the packaging system you are using (rpm, deb, etc.) and you will be able to write a spec file and start from scratch and build a new package if you need to. Still, this process is complicated and requires a lot of work.

Luckily, Jordan Sissel has built a tool called FPM (Effing Package Management), exactly for this: to ease the pain of building new packages; packages that you will use for your own infrastructure and you want them customized based on your own needs; and you don’t care about upstream rules and standards and other limitations when building such packages. This can be very useful for people deploying their own applications as rpms (or debs) and can simplify a lot of the process of building those packages.

FPM can be easily installed on your build system using rubygems:
gem install fpm

Once installed you can use fpm to build packages (targets):

• deb
• rpm
• solaris

from any of the following sources:

• directory (of compiled source of some application)
• gem
• python eggs
• rpm
• node npm packages

Read the rest of this entry »

The Bcfg2 version available in debian etch is quite old (v0.8.6), while the one in lenny is newer v0.9.5.7, it still isn’t the latest stable version 0.9.6 that was released in November last year. Since this version fixes many bugs it is the version that is recommended to use in production at this time (unfortunately it breaks the reporting system, that will not be fixed until the release 1.0 planed for the next months). This post will show how we can rebuild a debian package for the latest stable bcfg2 release so we can easily deploy it on several machines.

Bcfg2 is a debian friendly project, meaning they provide inside the source package all what is needed to build a debian package very easy. We will use for this a debian etch system, but this should work on any debian based system. Read the rest of this entry »

This is a quick post to show how you can rebuild a debian package and skip some steps, like “make test” for example in the upstream package, by passing some build options. More and more debian packages are now supporting the nodocs, nocheck/notest build options. You might want this if you are repeatedly building the package and want to skip some parts and make it faster, or maybe some step is failing while running the tests and that is something acceptable and known. In this case you can build the package as usual and export DEB_BUILD_OPTIONS=nocheck.

For example rebuilding the mysql package takes quite a long time, and to skip the package run tests we will do something like:
dpkg-source -x mysql-dfsg-5.0_5.0.67-1.dsc
cd mysql-dfsg-5.0-5.0.67/
DEB_BUILD_OPTIONS=nocheck debuild -us -uc

Note: not all packages implement this option and you might want to look in the rules file and see if this is defined or not.

I have just noticed that the old looking packages.debian.org website has a new look with some minor visual changes, but with many functional ones. Personally, I like it very much and find it much more functional than before.

Read the rest of this entry »

snapshot.debian.net/archive is one of the unofficial debian projects that can be very useful if you are looking for old debian packages that have been removed from the official repositories. This post is a short presentation of debian snapshot project and how it can help you find the debian packages you can’t seem to find anywhere else.

Debian contains a huge collection of software packages and in order to keep up with this huge size a debian repository is designed to keep only ONE version of a package. This means that newer versions will remove the old ones from the repository, to keep it clean and as slim as possible. Normally this is not a problem as debian (at least for stable and testing) is known to be quite stable in the package updates and things in general don’t break. Still it can happen that a software package is removed, its functionality changed in a newer version or you just want to install the same packages on more machines.

By default each debian system will keep a local cache of all the packages it downloads and installs. This can be found under /var/cache/apt/archives and if the package you are looking for is there you should just go ahead and use it as it is the fastest way to get it. Still if you regularly clean your cache (apt-get clean) then you will no longer find the packages there either.

Read the rest of this entry »