Emacs mode for machine-readable copyright files !

Quite a fair amount of time has flown since my decision to implement an emacs mode for the proposed machine-readable format for debian/copyright files. A have to admit that I had left that sleeping for quite a long while. But I took my courage, and rewrote nearly everything I had done so far. I'm quite happy with the results, to be truthful. The debian-mr-copyright-mode features:

• syntax highlighting
• a coverage mode show all files in the package, including the ones not covered by the copyright file
• the coverage mode shows which glob matches a given file
• it provides links to visit files and go to the declaration leading to a given label

The aim of this mode is to provide a quick check for uncovered files in a package, and also means to verify if the license of a file is not misrepresented.

The code can be downloaded from the git repository, accessible using

git clone git://git.debian.org/git/users/fourmond/debian-mr-copyright-mode.git

No debian package is available for the time being, although that could definitely change after lenny is out. I hope this emacs mode will help the new format to be widely adopted.

Switching to mpd

I was until recently using xmms2 as a music daemon. I was finding it neat, providing a good command-line (thus scriptable) control over how the music was playing, and I was using xmms2 info to automatically write signature files for my mails. However, I got annoyed by one quite painful thing: on my computer, it can take up to 40% of the processor to play a MP3 file (AMD64 x2 4200+ @2.2GHz)! That is mad. One of the consequences was that the music was jaggy whenever aptitude was upgrading packages... Annoying.

So, I've switched to mpd. It provides a decent command-line client, with possibly a bit less features than xmms2, but it takes only a few percent of the processor's usage... Thanks !

Process substitution is cool !

I've finally found some time to work on ctioga again ! My main problem there is that I keep adding new features without ever bothering to document them... One of my main concerns is therefore to find out about the list of command-line switches that are not documented in the manual page. I've just written a neat shell one-liner that precisely does that:

diff <(man -a -l $HOME/SciYAG/ctioga/doc/ctioga.1 | \
  egrep -o -- '--[a-z0-9-]+' | sort | uniq) \
  <(ctioga --help | egrep -o -- '--[][a-z0-9-]+' | \
  sort | uniq) | colordiff | less -R

(of course, I broke it into lines for clarity). It is based on process substitution, a shell trick that lets you use the output/input of a shell command exactly as a file on command line. Neat ! The trouble is, replacing the colordiff... part by | egrep '^>' | wc tells me there are 65 undocumented features... Lots of work in perspective, and I'm not sure I'll do it all before the 1.9 release...

Doxygen and Ruby...

I've been using Doxygen for a while now, and, no surprises, I find it fantastic ! The only thing that is really missing there is a decent support for Ruby... Allright, Ruby already has a documentation system, rdoc, but using only one for everything has its charms, and Doxygen is doubtlessly much more evolved than rdoc. Maybe when I have time, I'll have a look at writing it. (but that won't be before a long time...).

Update: I finally had some time to write and publish this patch. It is available on github

Another bzr2git example

Today, I tried to switch one of my personal repositories for debian-related scripts from bzr to git, just like I've done for pmount. The trick was that this time, I wanted to only move a part of the repository, not the full repository. I had only been working before with CVS and SVN who have the idea of modules, which is not the case for bzr or git. So I made the mistake of using a single bzr for several projects, which I realize now is not a very good idea...

In any case, I managed to drop some parts and here is how I did it; the trick was precisely to use SVN as an intermediate storage medium, using the following configurations files. First, bzr2svn.conf

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = bzr:source
target = svn:target
start-revision = INITIAL
state-file = tailor.state

[bzr:source]
repository = /home/vincent/debian-devel/bzr/scripts

[svn:target]
repository = file:///tmp/testtai
module = biniou

and svn2git.conf:

[DEFAULT]
verbose = True
patch-name-format = ""

[project]
source = svn:source
target = git:target
start-revision = INITIAL
root-directory = /home/vincent/tmp/debian-mr-copyright-mode
state-file = tailor.state

[svn:source]
repository = file:///tmp/testtai
module = biniou/debian-mr-copyright-mode

[git:target]
git-command=/usr/bin/git

Then, all that is left to do is to run tailor on the resulting configuration files:

~ tailor -D -c bzr2svn.conf
~ tailor -D -c svn2git.conf

Sanitizing bad UTF-8

I've hit a problem recently where statsvn does not manage to generate statistics on one of my repositories. After investigation, it turned out that there are some raw latin1 sequences in the XML log file (from a conversion from latin to UTF-8 long time ago), and that makes logfile parsing fail. To sanitize this, I use the following filter:

iconv -c -f UTF-8 -t UTF-8

This way, obnoxious sequences are dropped and processing can go on. (or, at least, could go on if it was not failing just a little later with a Null pointer exception...).

pmount switching to git

I've been neglecting pmount for such a long time I feel ashamed about it. Thanks to tailor and a neat post, I've just switched it to a git repository at git://git.debian.org/git/pmount/pmount.git to get more work done (I don't like bzr too much in the end, don't flame me, it's just a matter of personal taste...). I hope that I'll be able to reduce the amazing number of bugs that have accumulated there...