therning.org/ magnus

I have to say I was a little worried when I saw the installation notice during a recent upgrade of debfoster. It had been deprecated, abandoned by its developers, and instead I was being encouraged to use aptitude. So, I was being forced to give up my favourite package tool for a tool that I’ve started a few times but always found too confusing to invest time in learning.

My first step was the transition from debfoster to aptitude. I tried out the debfoster2aptitude script that was added to the last upgrade of debfoster but quickly realised that it was asking questions on a level that was way too low. I decided to do it manually instead. First I minimised my list of packages in debfoster and saved a copy of it:

# debfoster
# debfoster -qmn
# debfoster -a > ~/debfoster_keepers

Then I turned to aptitude. First I marked all packages as automatically installed (auto) from the command line:

# aptitude markauto '~i'

Then I marked each of the packages in /root/debfoster_keepers as not auto. I did this using the UI, which was both boring and time consuming. It should be easy to wip up a shell script for it, but I felt I needed to get used to aptitude‘s UI a bit. After this I went on to see what the damage would be–I hit ‘g’ to add/remove packages. As expected there were a few packages in there that I had to tell aptitude to keep installed for me. No big deal.

One interesting thing about aptitude is that it doesn’t just keep depends of packages, it keeps recommends as well. To see if I could further trim the list of non-auto packages I started looking at the ways to filter the view of packages. I didn’t quite succeed on my own, but after a few emails to the Debian User List I had a nice filter expression:

~i!~M(~R~i|~Rrecommends:~i)

It will show any installed packages that aren’t auto which are dependencies or recommendations of other packages. In short, packages that aren’t marked auto but could (should?) be. Be aware though that circular depends/recommends prevents all packages in that list to be marked auto.

Another cool thing is the “Audit recommendations” view in aptitude. It’s a great way of finding related packages and improving the functionality of the system. If you want to also see the suggests of installed packages you can change the filter in that view to:

!~v!~i(~RBrecommends:~i|~RBsuggests:~i)

By now I’m not too sad that debfoster is being removed, aptitude actually doesn’t suck

[Edited 01-09-2006 17:11 BST] Fixed a few spelling errors.

Well, this is the first entry in my st00pid category. I make quite a few mistakes when using Linux, mistakes that take time and effort to fix. From now on I’ll swallow my pride and write down, in a public place like this, about what st00pid things I do. Most importantly I’ll also write down what I did to get my Linux system back to the state it was before my brain temporarily popped out for a coffee.

I like keeping my Debian systems minimal. When running Sid there ends up being quite a few upgrades to download and when dependencies change your system ends up having “orphaned” packages, i.e. packages that were pulled in to satisfy a dependency but by now the dependent package has since moved on (or been deleted). This is of course a worrying thought, packages are installed that don’t actually need to be present on the system. My stomach’s turning. Some people use aptitude to handle this, personally I’ve never really like aptitude and I use debfoster.

Yesterday, after a sizable upgrade of my system at work I ran debfoster to prune orphaned packages. This was in fact the first time I ran it after setting up the system which resulted in quite a few questions regarding whether to keep specific packages or not. This is about the time when my brain popped out for a coffee. When asked if I wanted to keep lvm2 or not there was no brain to consult and I answered no. Had the brain been around it would have reminded me that I opted to use logical volumes on that particular machine (for two reasons, 1) I had never done it before and it’s damn cool, and 2) it makes the system a bit more flexible and future proof).

After a reboot I was sitting there with a system that was fairly useless since the root partition couldn’t be mounted. A quick calculation of just how long it’d take me to re-install later, I popped in the only live CD I had available at work–Ubuntu 5.04, Hoary Hedgehog. Using that I found a page on the Knoppix Wiki on how to use LVM2 with Knoppix. Now armed with something that looked like a workable plan I did the following in a terminal

$ sudo su -
# modprobe dm-mod
# vgscan
# vgchange -a y
# cd /mnt; mkdir debsys

Then I went ahead and mounted the root partition on /mnt/debsys. I also mounted the other partitions I have on my installed system, /var, etc. Then to get into it and fix it I

# chroot /debsys
# apt-get install lvm2 lvm-common

Except lvm2 refused to install, it complained about the kernel being too old. Not surprising since Hoary is getting really old by now. to get around that I downloaded the source for lvm2, modified debian/preinst so that the kernel version check was skipped, re-built the package, and installed it. Worked like a charm.

The document on secure APT contains an excellent explanation of what secure APT actually is. One section is empty though–the one about setting up your own secure APT repo.

I have some circumstantial evidence that my local APT repo is secure. apt-get update complained about packages being “unsecure” when I installed from it. Then I signed my Release file, and instead I was told that the key was missing. Then I used apt-key to add my GPG key and the complaint went away.

I use dput and mini-dinstall to manage my local repo. At some point I’m planning on synchronising it to another computer so that it’s available to others as well, but due to bandwidth problem I haven’t started doing this yet.

My ~/.dput.conf looks like this:

[DEFAULT]
allow_unsigned_uploads = 0

[local]
fqdn = localhost
method = local
incoming = /usr/local/apt/mini-dinstall/incoming
post_upload_command = mini-dinstall --batch

As you can see my local repo lives in /usr/local/apt. Then the ~/.mini-dinstall.conf looks like this:

[DEFAULT]
architectures = all, i386
archivedir = /usr/local/apt
use_dnotify = 0
verify_sigs = 1
extra_keyrings = ~/ms_home/secret/gnupg/pubring.gpg
mail_on_success = 0
archive_style = flat
poll_time = 40
mail_log_level = NONE
generate_release = 1
release_description = Magnus' Funky Packages
release_signscript = ~/bin/release_sign

Most of this should be obvious to anyone who’s read the manpage. The only interesting bit is the release_signscript at the end. Based on information in the manpage I wrote this little shell script:

#! /bin/sh

gpg --detach-sign --armor --output Release.gpg $1

Pretty straight forward really!

Since I’ve re-joined the mothership (I recently moved back to Debian (Sid) after about a year using Ubuntu and a couple of months using ArchLinux) I thought it’d be a good time to do that one thing that’s been on my todo-list for years now–grok Debian package building.

I’ve built a few packages over the years but I’ve never really understood the magic of debian/rules. For my first package I used debhelper, then I discovered CDBS. Both of these systems (especially CDBS) are great, but I never really understood what was going on. I came across a tutorial on building a Debian package without debhelper a while ago and ever since I’ve been planning to reading it. It turns out Miriam Ruiz has made an excellent job in explaining how to package. This post reflects my current understanding of Debian packaging.

The basics

Only for files are really needed

1. debian/control contains source and package information such as dependencies and a description of the package. It’s handy to use that package names defined in this file as install directories for the actual packages when building, e.g. build the package foo in debian/foo/.
2. debian/copyright contains information about upstream.
3. debian/changelog contains the changelog for the package (not upstream). The format must be strictly followed, the easiest way of doing that is to use dch. dch --create will create the file with the first entry.
4. debian/rules is at the heart of packaging.

All of them are well described in Miriam’s document, but I have some thoughts on the last one.

The rules

This file is a makefile with three required targets:

• clean – Cleans up the build area, both for the source and the stuff generated in debian/.
• build – Build the software
• binary-arch – Create packages for architecture specific parts, e.g. binary executables and libraries.
• binary-indep – Create packages for architecture independent parts, e.g. documentation.
• binary – This is often an empty target that depends on the two previous ones.

*-stamp targets are used to make sure things happen in the right order. Everything else is convenience, really.

Where to put things

The upstream source is installed, by convention in debian/<package name> (or debian/tmp). Package control files go in debian/<package name>/DEBIAN. The very last step of packaging is to create the package itself by calling dpkg --build (or dpkg-deb -b).

Debhelper

Miriam has made a conscious choice to leave Debhelper out of her document. I think this is wise. However, I think any packager would benefit from getting familiar with the d_* commands. They aren’t very easy to use, and though their manpages are well written they don’t contain any expamples. Luckily there’s a load of examples in Debian’s source repos. Debhelper’s dh_make is also an excellent way of learning-by-example.

For the first time in years I don’t have a Ubuntu system installed at home. Over the last few weeks I’ve been playing with ArchLinux and it’s been good so far. I especially enjoy the frequent updates to the software. Ubuntu with its two releases per year has been leaving me less and less satisfied lately. Don’t get me wrong, it’s great at work where I need a system I can rely on. For home, however, I want a totally different system. I want it bleeding edge on top, with a less bloody edge at the bottom. Arch Linux gives me exactly that!

I just tried installing Dapper FT2. I suppose in attempt to see if tracking Ubuntu unstable would be an interesting hobby. The install CD’s expert mode didn’t work at all! I ended up in a cul-de-sac since it apparently doesn’t like non-networked system (yes, I’m still on a dialup!). The non-expert mode worked better, but the system didn’t boot once installed. The kernel didn’t manage to find the proper modules to deal with my SATA drive. A few hours later I had downloaded the kernel sources and had a few failed kernel compiles (some USB-related driver kept resulting in compilation errors). Once the I had a kernel that booted I decided to look at what I had installed. Oh my DOYC, a default Ubuntu system is amazingly bloated. I installed debfoster and started cleaning up. 50% of the packages went out the door… Then I stopped to think about what I was doing. Ubuntu clearly isn’t a system for me anymore. If I need a Debian-based system on my computer I’ll just go for the real thing (Sid of course) instead. My Ubuntu Dapper FT2 CD went in the bin.