I'm a crap maintainer, as well as being bloody lazy.

I'm relieved I've finally been found out, I can desist with this charade. I mean, it must be true, someone said it on the Internet.

I spent today hacking on bzr-builddeb for the first time in a while. The first order of business was to review and merge all of the proposed merges in launchpad. Thanks especially to Jelmer Vernooij for all his work.

After that I tackled a long-standing annoyance in bzr-builddeb. This limitation made it difficult to pass extra options to the underlying build command. For instance, when building a merge you must use the -v option to debuild. Previously this meant that you would have to run something like:

$ bzr builddeb -S --builder "debuild -S -v0.1-1"

Using the tradition of -- to end option parsing this now becomes:

$ bzr builddeb -- -S -v0.1-1

which is much better.

The -- isn't exactly obvious, but it does mean that I don't have to implement support for every option of dpkg-buildpackage.

It may be possible to add support in bzr to make this work without the --, I haven't looked yet, and the current implementation doesn't prevent us from doing that.

One other thing I did was to make the build command default to debuild, rather than dpkg-buildpackage -rfakeroot -uc -us, so that we get all the debuild goodness. The obvious change here will be that it tries to sign the package when you build. You can define your builder to be debuild -uc -us to avoid this.

One last break was to remove support for source-builder from the configuration. It now assumes that adding -S to the build command will make it build a source package.

Comments on any of this are welcome.

Hannah is very interested in radio, and is planning to set up her own Internet radio site. I wanted to try out icecast to see whether it would be suitable. I have jotted down a few notes about how to set it up here as I couldn't see any others.

Firstly get the server and the streaming client:

aptitude install icecast2 ices2

Then edit /etc/default/icecast2 to enable the daemon, and /etc/icecast2/icecast.xml to set the passwords.

Then

/etc/init.d/icecast2 start

Then

cp /usr/share/doc/ices2/examples/ices-playlist.xml .

and set the password in ices2-playlist.xml to be the stream password you set above.

Then create playlist.txt with the names of some .ogg files, one per line.

Then run as root

ices2 ices-playlist.xml

and test using

mplayer http://localhost:8000/example1.ogg

Hopefully this should be enough to get a stream going, and then you can configure it how you want.

I returned today and I had received the email I had been waiting for.

To: James Westby <jw+debian@jameswestby.net>
From: Debian Installer <installer@ftp-master.debian.org>
Date: Fri, 18 Aug 2006 07:00:09 -0700
Subject: seccure_0.2-1_i386.changes ACCEPTED


Accepted:
seccure_0.2-1.diff.gz
  to pool/main/s/seccure/seccure_0.2-1.diff.gz
seccure_0.2-1.dsc
  to pool/main/s/seccure/seccure_0.2-1.dsc
seccure_0.2-1_i386.deb
  to pool/main/s/seccure/seccure_0.2-1_i386.deb
seccure_0.2.orig.tar.gz
  to pool/main/s/seccure/seccure_0.2.orig.tar.gz


Override entries for your package:
seccure_0.2-1.dsc - optional utils
seccure_0.2-1_i386.deb - optional utils

Announcing to debian-devel-changes@lists.debian.org
Closing bugs: 378987


Thank you for your contribution to Debian.

Thanks to those that helped me to get this in, and especially the author for a cool bit of software. He has just released a new version, so I will package that and upload it soon.

We hadn't really realised but some gnutls related packages are Priority: Important, and as such are due to be frozen soon for etch. There has been some upstream activity in the area recently, with several releases. Luckily the timing was really good, and the uploads made it in such that they should progress to etch quickly, without causing any trouble for the release team.

Also there has been some action from a couple of the maintainers holding up the gnutls11 and libtasn1-2 removal. This just leaves two packages, one of which the maintainer has tagged pending, and nutmeg has just upgraded the bugs to serious to try and prod the maintainers. It is possible then that removal can be requested before the release team calls the freeze that is supposed to include these packages.

gnutls13 builds a gnutls-dev package, which will make this easier in the future... until there is an API change and we have to switch back to gnutlsXX-dev and get all packages to migrate again. It is hard to know which is the better approach, but at least this way it only requires rebuilds while things stay calm.

The other day I decided I wanted to try out one of the more modern revision control systems. I decided on bzr as it seemed to have some features that I liked the look of. I still intend to try out darcs one day though, as it looks very interesting.

Just as I started looking at it and thinking about using it for some of my packaging work, I discovered that there was no -buildpackage for bzr. But lo, madduck filed an ITP for it. However he said that it didn't actually exist yet.

I decided I would try and help to write something, even though I have hardly ever touched Python before. It was quite easy to hack something together by looking in examples. I ended up with a plugin that worked for me to build simple packages from a bzr repository, including supporting the layout where just the debian/ dir is versioned (the mergeWithUpstream of svn-buildpackage). You can find my work here, (in a bzr branch of course). The plugin is actually called builddeb, as it seems Fedora are keen on something similar, and so we didn't want to hog the namespace. The Debian package will probably include a wrapper script named bzr-buildpackage though.

There is plenty that can be added on, for instance config files are needed, and madduck would like to include hook script capability within the branches, but this is going to take some careful thought.

I have quite enjoyed working in Python, it allows you to do things "properly" if you want, but also can be very terse. I've not grasped all of the features yet though.

The upstream author, B. Poettering, has been fantastic, very responsive and helpful. He even asked what features I would be interested in for the software.

He wrote it for backups, and so it is quite simple, without the keyrings etc. of gpg. It might be quite useful, and the length of the keys makes it easy to pass them around. I have put my key in my .signature for a bit of advertising. ECC is planned to be included in a future version of gpg, so seccure will stay small.

I also asked the debian-audit team if they would take a look at the package. Ulf Harnhammar and Brian M. Carlson had a look, and said that it was very well done.

I think there is a dictionary attack on the password, and so the secret key, so you better pick a good one. My public key is

(3+)k7|M*edCX/.A:n*N!>|&7U.L#9E)Tu)T0>AM

I currently have an open RFS for the package, but I need to update it, as there is a new upstream release, including an implementation of DH key exchange.

So I decided that I could do better and started writing the next generation of the tool. This version aims to have different modes of operation, and allow the system admin the choice of how certificates should be handled. As an added bonus it makes it easier for package maintainers to create and use SSL certificates.

You can see an overview of the design, and the current status of the work here. There is also the source code of the project in a bzr branch. I would welcome any comments that anyone has on the design of the project, as I am sure I haven't thought of every situation yet.

I then started work on the package, fixing all of the easy bugs while I got used to coding in Ruby. I put my patches in to the BTS, mainly so that I could tag the bug +patch, and it would be displayed differently, so that I could see which bugs still need working on. I kept the package locally in svn, and by the end had a package that fixed around 25 open bugs in the BTS.. My plan was to seek a QA upload of the package, as I didn't want to become the maintainer.

Unfortuantely the package that I had didn't tackle the RC bug. This is because the index files that apt-listbugs uses to get the status of bugs appeared to be wrong or out of date. These files live on a non-Debian server, so the DDs who had looked at the bug could not instantly see what was going on. There were proposals to move the files to a Debian machine, but this had not happened. Without access to the generation of these index files it was impossible to debug where the problem was coming from.

Then another person stepped up to adopt apt-listbugs. This was good as it seemed that he was in contact with a DD that could work out where the problem was, and was apparently rewriting the scripts to be more reliable. I was hopeful that the problem would be fixed soon.

However one problem was that the prospective maintainer said that he did not want to use my packages as a base for his work, he would pull my patches out of the BTS. In a way this is fine, and it is his choice, but at the same time it is annoying as some of my work might go to waste. Not only did I make the patches that ended up in the BTS, I did several more things that didn't have an associated bug report.

The other problem appears to be that there has been no further activity in the BTS for apt-listbugs since the O became ITA. I'm not sure how the prospective maintainer works, but I would have thought he would triage the new bugs, and send some thoughts or questions to old bugs as he is working on them. There has also been no activity on the RC bug, giving the process for interested parties, or those that are looking to squash RC bugs in preparation for etch. I understand that the DD doing this part is probably very busy though.

There is no way in which apt-listbugs can enter a stable release in its current state, as it is worse that useless, continually giving false positives. Hopefully all of this can be sorted out soon.