About box 2.0

October 7th, 2009

You want to revitalize a dying, inactive free software project. How do you proceed?

  1. You write code, contribute, get involved in the community, get in touch with the previous developer(s) to try and join the team or take over the project. Failing that, you fork the project, because this is how free software works after all. Then, once you’ve got something to show, you start talking about it;
  2. You set up a new forum, brag about it on the old one, arrange with the previous lead developer to make sure you can use the name and logo, then open a twitter account so users can follow the new forum’s setup process minute by minute.

There’s this saying about opensource/free software that says the logo and about box are the very first (and only) things that work in new/young projects (and sometimes that’s also true for more “mature” projects, as we all come to know).

Choice 2 above is the About Box 2.0. Unfortunately, that’s the way a handful of people choose to revitalize mt-daapd/Firefly Media Server. Of course, not one among them can code or has actually got a clue about the current codebase.

FAIL of epic proportions. Facepalm.

pommed v1.28: new machine

September 13th, 2009

pommed v1.28 is a minor update adding support for the MacBookPro5,3.

Why oh why…

September 10th, 2009

… did FAI switch to that stinking pile of shit known as live-initramfs?

Things that were possible before aren’t possible anymore due to the extreme brokenness of live-initramfs. Nothing that can’t be fixed by some heavy-handed patching here and there, but what a waste of time.

Not happy. Hammer time.

pommed v1.27: new machines

August 1st, 2009

pommed v1.27 is out as a maintenance release adding support for 3 of the newer machines:

  • MacBook5,2 (White MacBook)
  • MacBookPro5,2 (17″ MacBook Pro, June 2009)
  • MacBookPro5,5 (13″ MacBook Pro, June 2009)

Some machines are still missing, as I haven’t got any report about them yet.

Looks like the keyboard backlight behaviour and keys handling will have to be modified slightly for the new machines, but it’s really touchy to get right. I’ll need to try it out on the actual hardware.

How to not use lintian overrides

July 9th, 2009

Look what just got added to all the packages maintained by the Debian Forensics team:

--- md5deep-3.4.orig/debian/source.lintian-overrides
+++ md5deep-3.4/debian/source.lintian-overrides
@@ -0,0 +1,3 @@
+# Avoid warnings if non-uploaders to uploads.
+md5deep source: changelog-should-mention-nmu
+md5deep source: source-nmu-has-incorrect-version-number

You’re doing it wrong.

Digi AccelePort drivers updated to 1.3-15; now for Lenny

June 30th, 2009

This is yet another “beta” release from Digi from a few months ago.

I had to patch the driver to build with a 2.6.26 kernel, as neither versions of the code would build against that version. Lenny ships with 2.6.26, so that would have meant no dgap drivers on Lenny. I’ve tested the patched driver and haven’t noticed anything obvious while doing so.

The drivers are now built for Lenny; if you need them on Etch, a simple rebuild from source will do. Previous versions are still available in the pool, under the old/ directory.

APT source line, now changed:

deb http://debian.technologeek.org/ lenny non-free

Feedback at the usual address.

Releasing a rewrite of mt-daapd/Firefly Media Server

June 12th, 2009

About a year ago, I bought a SoundBridge, having grown tired of running a media player on one machine or another to listen to music. The SoundBridge really fits my needs perfectly.

The server-side counterpart, mt-daapd (Firefly Media Server), on the other hand… not so much. Feature-wise, it works and does what it’s supposed to do, so the issues aren’t there.

The first issue was with the crappy, below-average packaging of mt-daapd in Debian. I’ve fixed that since I think, at least now it’s in a state where I’m not looking away from the screen while typing apt-get install mt-daapd.

The second issue came after looking at the code, while writing patches for Debian. Eek. It’s horrible in about every aspect you can think of. No coding standard, outdated comments, cruft everywhere, either #ifdef’d out or not, useless code left lying around inside functions, obvious memory leaks, and way more levels of indirection than is actually needed, let alone sane. Also, someone is clearly in deep and urgent need of taking “Pointers in C 101″. My eyes still hurt.

Well anyway, I’ve been contemplating either fixing it or rewriting it because I can’t stand such crappy code. Also, mt-daapd has been unmaintained upstream for something like 2 years, given that the upstream developer just pretty much disappeared.

So, with way more time on my hands than I’d like these days, I’ve finally jumped in, pulled the whole SVN into a git repository and started cleaning things up then rewriting it piece by piece. Good way to keep myself busy, producing something useful while doing so and playing with a couple new things.

This rewrite is called forked-daapd, for lack of a better name at the moment, it’s GPLv2+, and the code is available in a git repository at

git://git.debian.org/~jblache/forked-daapd.git

It’s not a feature-for-feature rewrite. I’ve tossed out a few things.

It’s Linux-only for a start, and then I’ve thrown out the web interface, the XML-RPC interface that goes with it,  the iTunes XML playlist support (only useful on Mac OS X) and the smart playlists. Maybe a couple other minor things I can’t think of right now.

It’s Linux-only because it uses signalfd and inotify. It’s built on libevent and pthreads, but doesn’t abuse threads either like mt-daapd does (spawning one thread per HTTP request … seriously). Parsers for the RSP and DAAP queries are built with ANTLR v3. Media handling is mostly done by ffmpeg, though ffmpeg suckiness in parsing metadata in some formats had to be compensated by dedicated metadata parsers. It’s a shame ffmpeg can’t handle raw FLAC streams with VORBIS comments, that is, bog-standard .flac files, while it goes to great length to support proprietary formats (though I should note it fails miserably on WMA too).

So, new things I played with: signalfd, libevent, threads, ANTLR, ffmpeg. Threads aren’t really a first, but I did some new things. inotify isn’t a first either, but it’s the first time I use it to watch events other than IN_CREATE or IN_MODIFY; that leads to quite some unhappiness towards the inotify API, which has some real shortcomings. I’m still shaking my head in disbelief.

It will happily support multiple concurrent clients, even when decoding media files to WAV, without abusing the machine it’s running on. I thought of adding more threading, especially in the decoding case, but I doubt this will be needed by anyone. Unless you’re streaming to hundreds of clients at the same time, which doesn’t look like a plausible usage scenario to me.

I don’t know where I’m going with this project. Right now it works for me and covers my needs. I’ve tested both the RSP and DAAP protocols with my SoundBridge, and DAAP with iTunes. I’m not an iTunes user so I may have skipped on the complicated things with iTunes, although I looked hard.

If there’s enough interest in this project, it can become a full-blown project on Alioth (it can even have a name that doesn’t suck!).

No patch is better than useless patch

April 12th, 2009

Joerg,

The patch you submitted has 0 chance of getting applied, and you know it. It’s nothing more than a bad joke.

The best solution for this issue is most probably to provide a xserver-xorg-nohal package that is a duplicate of xserver-xorg minus the HAL dependency.

HAL-haters heads up: #515214

April 10th, 2009

Don’t like HAL? X.org now forces it upon you via xserver-xorg.

#515214, currently wishlist/wontfix.

d-i SCM FAIL

April 9th, 2009

From the Bits from the Debian Installer team mail to d-d-a:

It has been decided that, in order to not slow down the development processes, D-I SVN should be branched when the work on preparing a release starts. Even if SVN doesn’t make the process very easy, changing the VCS we use is currently not an option we prefer.

SVN, branching, d-i. There’s no word to describe how painful it is to work on d-i using SVN. d-i is big, SVN is slow in about everything it does. Now add branches to the mix.

That mail left me very disappointed; first because I thought switching to git was sort-of planned for after the release of Lenny, and now it’s off the table, second because some things in this mail are just wrong.

Oh well. No d-i for me, I guess, then.