Thu, 24 Aug 2006
Setting up Icecast2 on Debian
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.
Posted at: 01:43 | category: /debian | Comments (1)
Wed, 23 Aug 2006
Subject: seccure_0.2-1_i386.changes ACCEPTED
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.
Posted at: 00:18 | category: /debian | Comments (0)
Mon, 14 Aug 2006
GnuTLS freeze for etch
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.
Posted at: 00:02 | category: /debian | Comments (0)
Sat, 12 Aug 2006
bzr-builddeb started
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.
Posted at: 17:08 | category: /debian | Comments (0)
Tue, 08 Aug 2006
seccure in Debian?
An RFP was filed for seccure, a small program allowing ECC based public-key crypto. I snapped it up and produced a package. The packaging was simple, but I enjoyed playing with the software while I was doing it.
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
using the secp256r1/nistp256 curve.(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.
Posted at: 02:15 | category: /debian | Comments (0)
Sun, 06 Aug 2006
ssl-cert2 Proposal
After a discussion on the debian-devel mailing list about having a system for unifying the way packages create SSL certificates, a couple of things became apparent. Firstly that the idea was a good one, and secondly that the existing tool that tries to do this (ssl-cert) is not good enough.
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.
Posted at: 12:29 | category: /debian | Comments (0)
apt-listbugs RC bug problems
Recently apt-listbugs was orphaned, and it was in a bad shape, including an RC bug that makes it virtually useless at the moment, not showing some bugs, and showing ones that were closed long ago.
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.
Posted at: 10:29 | category: /debian | Comments (0)