Version Numbers

Last week I mentioned how I had uploaded a new version of Symbol::Approx::Sub. Because there were pretty major changes to the inner workings of the module (although the interface still looked the same) I decided that I would move it from version 2.07 to version 3. At the same time, I decided that I would switch to a semantic versioning scheme.

Later in the week, I released minor updates to a few more of my modules. And I decided to apply semantic versioning to those as well. But as I was only making minor packaging fixes to these modules, I didn’t increment the major version number. For example, Array::Compare went from 12.2 to 12.2.1.

It turns out that was a mistake.

Well, I don’t really think it was a mistake. I think it was the right thing to do. But it appears that my opinion is at odds with what some parts of the Perl toolchain think.

Last night I got this bug report. It seems that by switching to three-part semantic versions, the version number can (in some quite common circumstances) appear to decrease.

To my mind, a version number is a dot-separated sequence of numbers. So 12.2 is smaller than 12.2.1. Any sane version number comparison will separate the two strings on dots and compare the individual components. Any missing components (12.2 is, for example, one component shorter than 12.2.1) should be assumed to be zero.

But that’s not what the Perl toolchain does. Observe:

When the version number with two components (2.12) is split into components, the second component is bizarrely treated as a three-digit number so it becomes 12o instead of 12 and when it is compared with the second component of the three-component version, 120 is obviously larger than 12 and any tool which relies on this behaviour to work out which version of a module is the most recent will get the wrong answer.

This leads to other “interesting” effects. In my head, versions 1.1, 1.01 and 1.001 are all the same version. The leading zeroes mean nothing. But under this scheme, they are very different version numbers.

I know that versioning isn’t as easy as it should be and I know that some people use bizarre versioning systems. And I’m pretty sure that no matter how bizarre a versioning system is, you’ll almost certainly find an example of it on CPAN. So I suppose that this behaviour was a “least worse” scenario that was chosen to make the most sense given CPAN’s wide range of versioning schemes.

Personally, I see it as a bug in But I’m not going to report it as such as I’m sure the Perl toolchain gang know what they’re doing and have very good reasons for adopting this seemingly broken behaviour.

I just need to remember to be more careful when switching my modules to semantic versioning. Using a minor or patch level version change when switching to semantic versioning is likely to lead to confusion and bug reports. Only a major level change (as I did with Symbol::Approx::Sub) is guaranteed to work.

And, I suppose, I’ll need to release Array::Compare 3.0.0 to CPAN pretty soon.

Updating Ogg::Vorbis::Header

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:

When it should have looked like this:

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 🙂

Taming QMail

I run my own email server. It uses QMail. I realise there are at least two problems there – all of the cool kids have been using Gmail for their email since approximately forever, and who the hell uses QMail anyway?

Like most of these situations, it’s that way for historical reasons. And, of course, I’d love to change the current situation but it works well enough most of the time that the occasional pain it gives me isn’t worth the pain of changing the set-up.

So there I am. One of about three people in the world who are still running an email server using QMail. And that occasionally gives me problems.

One problem is the management of the mailing queues. The tools that QMail gives you for checking the contents of the queues and deleting any unnecessary messages are rather primitive. It seems that everyone uses third-party tools. A couple of years ago, I had a WordPress installation that was compromised and was used to send thousands of email messages to random people. The outgoing queue was full of spam and the incoming queue was full of bounce messages. I stopped QMail and started looking for a way to cleanly delete all the bad messages while retaining the tiny number of legitimate ones.

I discovered a program called qmHandle which did exactly what I wanted. It enabled me to remove messages from both queues that matched various criteria and before very long at all, I was back in business (having also cleaned up the WordPress installation and tightening its security).

The qmHandle program was written in Perl. And I always had it in the back of my mind that at some point I’d revisit the program and give something back by fixing it or improving it in some way. A few months ago I found time to do that.

I started by looking at the code. And realised that it had pretty much been written to be as hard to maintain as possible. Ok, that’s probably not true, but it certainly wasn’t written to be particularly easy to understand. What the original author, Michele Beltrame, created was really useful, but it seemed to me that he had made it far harder for himself than he needed to.

So I had found my project. I wanted to hack on qmHandle. But before  I could do that, I needed to rewrite it so that it was easier to work on. That became something that I’d hack on in quite moments over a few weeks. The new version is on Github. I started by importing the original version, so it’s interesting to read the commit history to trace the changes that I made. I think there were three main areas where I improved things.

  1. Splitting most of the logic out into a module. I say “most”, but it’s actually all. The command-line program is now a pleasingly simple:
  2. Improving (by which I mainly mean simplifying) the logic and the syntax. I moved a few variable declarations around (so their scope was smaller) and renamed some so their meaning was more obvious. Oh, and I added a couple of useful CPAN modules – Term::ANSIColor and Getopt::Std.
  3. Using Moose. Switching to an OO approach was a big win in general and Moose made this far easier than it would otherwise have been. At some point in the future, I might consider moving from Moose to Moo, for performance reasons.

For a few weeks now, I’ve been using the revised version on my email server and it seems to be working pretty much the same as the original version. So it’s time to set it loose on the wider world. This afternoon, I released it to CPAN. I’ve said above that the number of people using QMail to handle their email is tiny. But if you’re in that group and you want a more powerful way to manage your mail queues, then the new version of qmHandle might well be useful to you.

There are a few things that I know I need to do.

  1. More tests. The main point of moving most of the code into a module was to make it easier to test. Now it’s time to prove that. The current test suite is tiny. I need to improve that.
  2. Configuration. Currently, the configuration is all hard-coded. And different systems might well need different configuration (for example, the queues might be stored in a different directory). There needs to be a simple way to configure that.
  3. Bug fixes and improvements. This was, after all, why I started doing this. I don’t know what those might be, but I’m sure there are ways to improve the program.

I hope at least someone finds this useful.

Reviving WWW::Shorten

Last July I wrote a post threatening to cull some of my unused CPAN modules. Some people made sensible comments and I never got round to removing the modules (and I’m no longer planning to) but I marked the modules in question as “HANDOFF” and waited for the rush of volunteers.

As predicted in my previous post, I wasn’t overwhelmed by the interest, but this week I got an email from Chase Whitener offering to take over maintenance of my WWW::Shorten modules. I think the WWW::Shorten modules are a great idea, but (as I said in my previous post) the link-shortening industry moves very quickly and you would need to far more dedicated than I am in order to keep up with it. All too often I’d start getting failures for a module and, on investigation, discover that another link-shortening service had closed down.

So I was happy to hand over my modules to Chase. And in the week or so since he’s taken them over he’s been more proactive than I’ve been in the last five years.

  • He’s set up a p5-shorten organisation on Github to control the repos for all of the modules (all of my repos are now forks from those repos).
  • He has started cleaning up all of the individual modules so that they are all a lot more similar than they have previously been.
  • He has improved the documentation.
  • He has started to release new versions of some of the modules to CPAN.

All stuff that I’ve been promising myself that I’d get round to doing – for about the last five years. So I’m really grateful that the project seems to have been given the shot in the arm that I never had the time to give it. Thanks to Chase for taking it on.

Looking at CPAN while writing this post, I see that there are two pages of modules in the WWW::Shorten namespace – and only about 20% of them are modules that I wrote or inherited from SPOON. It’s great to see so many modules based on my work. However, I have no idea how many of them still work (services close down, HTML changes – breaking web scrapers). It would be great if the authors could all work together to share best practice on keeping up with this fast-moving industry. Perhaps the p5-shorten Github organisation would be a good place to do that.

Anyway, that’s seven fewer distributions that I own on CPAN. And that makes me happy. Many thanks to Chase for taking them on.

Now. Who wants Guardian::OpenPlatform::API, Net::Backpack or the AudioFile::Info modules?

Build RPMs of CPAN Modules

If you’ve been reading my blog for a while, you probably already know that I have an interest in building RPMs of CPAN modules. I run a small RPM repository where I make available all of the RPMs that I have built for myself. These will either be modules that aren’t available in other RPM repositories or modules where I wanted a newer version than the currently available one.

I’m happy to take requests for my repo, but I don’t often get any. That’s probably because most people very sensibly use the cpanminus/local::lib approach or something along those lines.

But earlier this week, I was sitting on IRC and Ilmari asked if I had a particular module available. When I said that I didn’t, he asked if I had a guide for building an RPM. I didn’t (well there are slides from YAPC 2008 – but they’re a bit dated) but I could see that it was a good suggestion. So here it is. Oh, and I built the missing RPM for him.

Setting Up

In order to build RPMs you’ll need a few things set up. This is stuff you’ll only need to do once. Firstly, you’ll need two new packages installed – cpanspec (which parses a CPAN distribution and produces a spec file) and rpm-build (which takes a spec file and a distribution and turns them into an RPM). They will be available in the standard repos for your distribution (assuming your distribution is something RPM-based like Fedora or Centos) so installing them is as simple as:

If you’re using Fedora 22 or later, “yum” has been replaced with “dnf”.

Next, you’ll need a directory structure in which to build your RPMs. I always have an “rpm” directory in my home directory, but it can be anywhere and called anything you like. Within that directory you will need subdirectories called BUILD, BUILDROOT, RPMS, SOURCES, SPECS and SRPMS. We’ll see what most of those are for a little later.

The final thing you’ll need is a file called “.rpmmacros” in your home directory. At a minimum, it should contain this:

The packager and vendor settings are just to stop you having to type in that information every time you build an RPM. The _topdir setting points to the “rpm” directory that you created a couple of paragraphs up.

I would highly recommend adding the following line as well:

This turns off the default behavior for adding “Requires” data to the RPM. The standard behaviour is to parse the module’s source code looking for every “use” statement. By turning that off, you instead trust the information in the META.yml to be correct. If you’re interesting in hearing more detail about why I think the default behaviour is broken, then ask me in a pub sometime.

Ok. Now we’re all set. We can build our first RPM.

Building an RPM

Building an RPM is simple. You use “cpanspec” to make the spec file and then “rpmbuild” to build the RPM. You can use “cpanspec” in a few different modes. If you have the module tarball, then you can pass that to “cpanspec”.

That will unwrap the tarball, parse the code and create the spec file.

But if you’re building an RPM for a CPAN module, you don’t need to download the tarball first, “cpanspec” will do that for you if you give it a distribution name.

That will connect to CPAN, find the latest version of the distribution, download the right tarball and then do all the unwrapping, parsing and spec creation.

But there’s another, even cleverer way to use “cpanspec” and that’s the one that I use. If you only know the module’s name and you’re not sure which distribution it’s in, then you can just pass the name of the module.

This is the mode that I always use it in.

No matter how you invoke “cpanspec”, you will end up with the distribution tarball and the spec file – which will be called “perl-Some-Module.spec”. You need to copy these files into the correct directories under your rpm building directory. The tarball goes into SOURCES and the spec goes into SPECS. It’s also probably easiest if you change directory into your rpm building directory.

You can now build the RPM with this command:

You’ll see a lot of output as “rpmbuild” goes through the whole CPAN module testing and building process. But hopefully eventually you’ll see some output saying that the build has succeeded and that an RPM has been written under your RPMS directory (in either the “noarch” or “x86_64” subdirectory). You can install that RPM with any of the following commands:

And that should be that. Of course there are a few things that can go wrong. And that’s what the next section is about.

Fixing Problems

There are a number of things that can go wrong when building RPMs. Here are some of the most common, along with suggested fixes.

Missing prerequisites

This is also known as “dependency hell”. The module you are building is likely to require other modules. And you will need to have those installed before “rpmbuild” will let you build the RPM (and, note, they’ll need to be installed as RPMS – the RPM database doesn’t know about modules you have installed with “cpan” or “cpanminus”).

If you have missing prerequisites, the first step is to try to install them using “yum” (or “dnf”). Sometimes you will get lucky, other times the prerequisites won’t exist in the repos that you’re using and you will have to build them yourself. This is the point at which building an RPM for a single module suddenly spirals into three hours of painstaking work as you struggle to keep track of how far down the rabbit-hole you have gone.

I keep thinking that I should build a tool which parses the prerequisites, works out which ones already exist and automatically tries to build the ones that are missing. It would need to work recursively of course. I haven’t summoned the courage yet.

Extra files

Sometimes at the end of an RPM build, you’ll get an error saying that files were found which weren’t listed in the spec file. This usually means that the distribution contains programs that “cpanspec” didn’t find and therefore didn’t add to the spec file. This is a simple fix. Open the spec file in an editor and look for the section labelled ‘%files’. Usually, it will look something like this:

This is a list of the files which will be added to the RPM. See the _mandir entry? That’s the man page for the module that is generated from the module’s Pod (section 3 is where library documentation goes). We just need to add two lines to the bottom of this section:

This says “add any files you find in the binaries directories (and also any man pages you find for those programs)”.

If you add these lines and re-run the “rpmbuild” command, the build should now succeed.

Missing header files

If you’re building an XS module that is a wrapped around a C library then you will also need the C header files for that library in order to compile the XS files. If you get errors about missing definitions, then this is probably the problem. In RedHat-land a C library called “mycoolthing” will live in an RPM called “libmycoolthing” and the headers will be in an RPM library called “libmycoolthing-devel”. You will need both of those installed.

Your users, however, will only need the C library (libmycoolthing) installed. It’s well worth telling the RPM system that this external library is required by adding the following line to the spec file:

That way, when people install your module using “yum” or “dnf”, it will pull in the correct C library too. “cpanspec” will automatically generate “Requires” lines for other Perl RPMs, but it can’t do it for libraries that aren’t declared in the META.yml file.


So that’s it. A basic guide to building RPMs from CPAN distributions. There’s a lot more detail that I could cover, but this should be enough to work for 80-90% of the modules that you will want to build.

If you have any questions, then please leave a comment below.