Last night, I uploaded a new version of Ogg::Vorbis::Header – a CPAN module that hasn’t been updated since 2003 and which I strongly suspect no-one at all uses any more. You might be interested to hear what I did or why I did it.

About a year ago, I wrote about the dashboard I had written for my CPAN modules. It’s a simple page that pulls together information about all of my modules and, among other things, shows me how they are doing on Travis CI and Coveralls.

One of the aims of the dashboard was to encourage me to do more work ensuring that my CPAN modules were working well and had good test coverage. The idea was that if I’m constantly looking at a page which shows how rubbish the test coverage for a module is, then I’ll be more motivated to fix it. Of course, that only works if I’m constantly looking at the dashboard and, to be honest, over the year since I built it I really haven’t taken much notice of it.

But recently, I was reminded of its existence as I updated it to remove some modules that I’ve handed over to other people and to add a couple of new modules I had released. And, in doing that, I took a closer look at it and my attention was drawn to AudioFile::Info::Ogg::Vorbis::Header. This is the only one of my modules which doesn’t even build on Travis. Clearly, more investigation was needed. But, before we get into that, it’s probably worth making a brief digression to explain what the module does.

Some of you will be too young to remember this, but there was a time back in the early middle ages of internet history (so, perhaps, fifteen years ago) when not everyone listened to music as MP3s. Back then, one of the biggest sources of digital music for many people was ripping their existing CDs (ask your parents – they might still have a CD or two they can show you). And when ripping music from CDs we had a choice of formats. Most people (even then) were using MP3, but some of us took the ideologically superior option of ripping to Ogg Vorbis. The main reason was that MP3 format was patented, but Ogg Vorbis was completely free.

All of this meant that in the first five or six years of the 21st century, I ended up with hundreds (maybe thousands) of Ogg Vorbis files on my hard disk. This immediately gave me problems as it dramatically limited the devices that I could play my music on. For example, it probably explains why I’ve never owned an iPod.

But I also… er… acquired a number of MP3s over the same time. And, being a geek, at times I wanted to write programs that gathered information about all of my music, no matter what format it was stored in. There were modules on CPAN for dealing with MP3s and there were modules on CPAN for dealing with Ogg Vorbis files. But (as is so often the way with these things) all of these modules worked in completely different ways.

And that’s I wrote the AudioFile::Info set of modules. They acted as a wrapper around the various modules for dealing with the different audio formats and gave them all the same interface. It meant that I could write programs that got information from any of my audio files and I didn’t need to care what format they were in. Think of them a bit like a DBI for audio file formats.

Of course, no-one else ever had any use for them. And soon afterwards MP3 became the de-facto standard for digital audio and Ogg Vorbis was relegated to the same (virtual) drawer as Betamax. I’d say that no-one uses it any more – but I suspect there are actually about eight users left and they would all write comments telling me that I was wrong.

None of the AudioFile::Info modules have been updated for a very long time, because no-one uses them any more and no-one cares about them. I’d remove them from CPAN, but that goes against my pack-rat nature.

All of which leaves me annoyed by the failure of AudioFile::Info::Ogg::Vorbis::Header to build on Travis. So a couple of weeks ago, I investigated further. And, to my delight, I found that it wasn’t my fault. Actually, it was the underlying module (Ogg::Vorbis::Header) that had the problem. That module no longer built successfully on modern Perls. And that failure prevented my module from building on top of it.

The problem is described in this RT ticket. Basically, there was some very funky syntax in a test. Syntax that became a fatal error through some parser fixes in Perl 5.22. The test looked like this:

ok(@{$ogg->comment("artist")}->[0] == "Dan"); 1 ok ( @ { $ogg -> comment ( "artist" ) } -> [ 0 ] == "Dan" ) ;

When it should have looked like this:

ok(($ogg->comment("artist"))[0] eq "Dan"); 1 ok ( ( $ogg -> comment ( "artist" ) ) [ 0 ] eq "Dan" ) ;

In the RT ticket, H. Merijn Brand gives a good explanation of how the test ever passed – but try working it out for yourself before looking.

So, anyway, I knew what the problem was and I knew how to fix it. My next step was to pass this information on to the author of the module. I emailed him a couple of weeks ago, offering to make the fixes myself if he was too busy (or too uninterested) to do it himself. I got no reply, so at the end of last week I emailed the CPAN Powers That Be explaining the situation and asking for co-maintenance rights on the module so that I could fix the problem. They granted my request – which is why the new version was released yesterday. I can already see that the tests for this version look a lot healthier than the ones for the previous version.

Healthier, but still not as healthy as I’d like them. Within an hour or so of my release hitting CPAN, this issue was raised. The Makefile.PL uses Inline::MakeMaker and I can’t work out how to make that work, given that the “use” statement is executed long before any of the configuration code that tells the build tools what modules are required. If you have any suggestions, please let me know (or send me a pull request). I’m a bit out of my depth when it comes to Inline-based modules.

There are a few other things that I might fix. It’s an old-style distribution where there are no /lib or /t directories. It’s all in the top-level directory. I’m very tempted to move all that stuff around.

But really, I should get back to ensuring that my module builds successfully now.

Update: On Sunday, I released another version of Ogg::Vorbis::Header which fixed the packaging problems. But it still hasn’t solved my Travis-CI woes and there are still a disappointing number of failures on CPAN testers (actually they are “unknown” results rather than real failures – because there are still cases where the module won’t even build).

The problem is the underlying C libraries. Ogg::Vorbis::Header relies on the libogg and libvorbis libraries. And a large number of people aren’t going to have those libraries installed (the Travis-CI environment certainly doesn’t). Trying to build the module on a system that doesn’t have those libraries is doomed to failure.

The solution is, I suspect, to build Alien modules for these two libraries. But that’s something that I know very little about. I doubt I’ll have the time to learn a whole new area of CPAN packaging until after YAPC Europe at the earliest. Of course, if some kind person who knows more about this area than me was to offer to help (or even to produce the Alien modules for me) then that would make me very happy 🙂

Also published on Medium.