Getting spotify into Fedora – part 2

Getting spotify into fedora hasn’t been easy. Not for technical reasons, but legal.  Clearing spotify’s legal conditions, Fedora’s legal concerns and also the packaging rules as defined by the FPC has taken more than half a year. Actually, the FPC process made part of my previous post obsolete.  But at last we see some light in the tunnel, with the packages going to rpmfusion instead of Fedora.

As of now (exactly right now!) the lpf-spotify-client package has been published for F-19 on rpmfusion. This package basically automates the process to download, build and install a rpm based on the Spotify debian package.. Enjoy

Also, this means that the lpf (Local Package Factory) framework becomes live. We have currently lpf-skype and lpf-flash-plugin under way.  I also have lpf-msttcore-fonts in my plans. When all this flies, there will actually be a way to handle a lot of the things in all those Fedora post-installation guides out there in a more organized manner.  Which might be a Good Thing.

Getting Spotify and Skype into Fedora.

Fedora is really about free software, which can be used, inspected and modified according to our needs. Still, there are  commercial, closed source applications which offers a great value without being free. They are typically only distributed as binary code.

So, let’s download the binary application, build an rpm and make it available to fedora users!  For some apps this works fine,  you most often find them on rpmfusion.

However, some applications are not only closed-source but also non-redistributable. This means that rpmfusion can’t host such a package. Instead, each user must download and install the software. Examples include skype and spotify.

One could of course package some kind of ‘skype-installer’ which makes this. However, this would mean several installers and commands to handle them which might become messy. So, instead I wrote some silly shellscripts which I called lpf, which should be read Local Package Factory. The basic idea with lpf is to provide a common framework for these applications.

Using lpf,, there is now a package lpf-spotify-client. After installing this, one just have to click on the lpf-spotify-client icon  or use ‘lpf update’ in the terminal. This will download spotify, build an rpm and install it.  It’s meant to be as simple as possible, but it will always need a user actually pushing the button.

One advantage is the packaging. The lpf-spotify-client actually contains and uses spotify-client.spec, an already tested spec. There’s nothing lpf-specific  in it. OTOH, the lpf-spotify-client.spec is just some boilerplate code which should be simple to use in other applications.

One problem I’ve seen so far is the process. When I submit lpf-spotify-client for review, what the reviewer checks is lpf-spotify-scient.spec. However, this is just boilerplate code and not much to check. The central spotify-client.spec gets no attention, although the quality of this spec is what the user really is affected by. Obviously, we need to fix the review process if there will be more of these.

Now, the lpf command can actually do much more. It supports the complete package life-cycle: install,  update, remove. The upstream is at https://github.com/leamas/lpf. Here is a more in-depth presentation of the package.

The lpf-spotify-client package is now in f20 updates-testing and  rawhide if you want to give it a try. lpf-skype needs a reviewer, but looks good to me. We’ll see if this idea for a framework handling non-distributable files is the way to go until those software vendors sees the light and at least make their clients re-distributable.

Fedora: writing the update message… three times.

OK, trying to make a blog which actually shows up in planet.fedora. We’ll see…

Tired of writing the same update message when doing the git upstream commit, when editing the specfile changelog and when submitting the bodhi update request? Some pieces which might help:

  • If you are making an upstream git commit first, I have a script gitspec
    available at http://github.com/leamas/pkg-scripts. This can create a new specfile changelog and/or bump the release based on the upstream git commit.
  • When you have the proper changelog, it would be real nice if fedpkg used the changelog as the default update messages. I have submitted patches for this, and a patched fedpkg is available at http://leamas.fedorapeople.org/fedpkg (which is a valid yum repo).
  • Don’t forget fedpkg clog. Using this you will generate a file clog reflecting the spec changelog which you can inspect, edit and finally use as the git commit message with -F clog.