Stein Magnus Jodal

March and April contributions

2016-04-30T00:00:00CEST

The following is a short summary of my open source work in March and April, almost like in previous months, except that I haven’t spent as much time as previously on Open Source the last two months.

Debian

Attended one day of the Debian Bug Squashing Party in Oslo.
Uploaded mopidy 2.0.2-2: Fixed RC bug #819174.
Uploaded mopidy-dleyna 1.0.5-2: Added missing dependency.

Mopidy

Bugfixes for the upcoming Mopidy 2.0.1 (which should have been released a long time ago): merged PR #1455, created PR #1493.
Started on, but didn’t finish, fixing the Travis CI setup for Mopidy-GMusic.
Upgraded the Mopidy project server from Ubuntu 14.04 LTS to 16.04 LTS. Rebuilt the discuss.mopidy.com Discourse/Docker instance.
Accepted Lars Kruse as the new maintainer of Mopidy-Beets. Thanks!
The extensions still in need of a new maintainer are:
If you’re a user of any of these and want to contribute, please step up. Instructions can be found in the README of any of these projects.

February contributions

2016-03-01T00:00:00CET

The following is a short summary of my open source work in February, just like in previous months.

Debian

Uploaded mopidy-dirble 1.3.0-1: New upstream release. Moved to pkg-mopidy team.
Uploaded mopidy-tunein 0.3.0-1: New upstream release. Moved to pkg-mopidy team.
Uploaded python-tunigo 1.0.0-1: New package. ITP. Maintained in the Debian Python Modules Team (DPMT).
Uploaded mopidy 2.0.0-1: New upstream release. Fixed RC bug #785910.
Uploaded mopidy-soundcloud 2.0.2-2: Fixed RC bug #799089.

Mopidy

Released Mopidy-Spotify 2.3.1: Works around search being broken in libspotify by using the Spotify Web API for the search functionality, and nothing else.
Wrapped up and released Mopidy 2.0 release. This was a quite large release that ports to GStreamer 1.x and adds support for gapless playback. It was uploaded to Debian in time to be part of Ubuntu 16.04 LTS.
Released Mopidy-Spotify 3.0.0: A couple of small compatibility fixes to work with Mopidy 2.x and GStreamer 1.x.
Updates to packages not in Debian, only at apt.mopidy.com:
- Uploaded mopidy-spotify-tunigo 1.0.0-0mopidy1. Far down the chain, it depends on libspotify, which is not in Debian.
- Uploaded mopidy-spotify 2.0.0-0mopidy1.
Updated homebrew-mopidy with lots of new releases:
- Mopidy 2.0.0
- Mopidy-Dirble 1.3.0
- Mopidy-SoundCloud 2.0.2
- Mopidy-Spotify 2.3.0, 2.3.1 and 3.0.0
- python-backports-abc 0.4
- python-backports-ssl-match-hostname 3.5.0.1
- python-certifi 2015.11.20.1
- python-cffi 1.5.0 and 1.5.2
- python-requests 2.9.1
- python-singledispatch 3.4.0.3
- python-six 1.10.0
- python-tornado 4.3
Rebased my feature/py3-compat branch on top of Mopidy 2.0.
Planned breaking changes for Mopidy 3.0: unbundling of Mopidy.js, removal of deprecated core APIs, model APIs, audio APIs and removal of the http/static_dir config.
Planned breaking changes to modernize Mopidy.js: change default calling convention to by-position-or-by-name, replace When.js with ES6 Promise, replace Bane.js with EventEmitter, and replace Buster.js with Karma+Mocha.

Comics

Started working on the upgrade to Django 1.8. Most deps are upgraded. The major remaining pieces is to upgrade django-registration from 0.8 to 2.0 and to replace the years-old vendored copy of django-invitation (singular) with django-invitations (plural).

A guide to poor API management

2016-02-18T00:00:00CET

This is the story of libspotify, as experienced by a Spotify customer and libspotify developer for six years.

Step 1: Support your API for years

Since April 2009, libspotify has been a mostly nice–although proprietary–C library for integrating with the Spotify music streaming service, providing both music metadata and full playback capabilities. Language wrappers have been written for a plenitude of programming languages (including my own pyspotify). libspotify is integrated into numerous open source projects (including my own Mopidy), networked AV receivers, and rumour has it: even cars.

In addition to being closed source, there was another catch: in order to use it, you need the Spotify premium subscription. Speaking from my own experience supporting a project integrating with Spotify for the last six years: lots of end users upgraded to premium in order to use the projects built on top of libspotify.

Step 2: Stop accepting bug reports and stop releasing updates

In May 2012, Spotify released libspotify 12.1.51 for all supported architectures, which now even included Android.

After months of endless requests from the quickly growing hoards of Raspberry Pi users, Spotify released libspotify 12.1.103 for hardfloat armv6 on January 22 2013. The release included minor API additions, like the addition of explicit lyrics and means for accepting Spotify’s Terms of Service.

The additions in 12.1.103 never reached the other supported architectures and 12.1.51 remains the last release for those. There was no clear communication about this being the end of libspotify, releases have just ceased. libspotify has not been mentioned in a single developer blog post or developer email newsletter since.

That’s now more than three years ago.

Step 3: Create new APIs

Over the next couple of years Spotify released a new Web API and iOS and Android SDKs. Through their developer blog, they communicated quite a bit both about these and about the deprecation of the apps inside the Spotify desktop client.

Here are some pieces from their developer blog to illustrate:

2014-02-03: Deprecation of Spotify Apps API 0.x
2014-03-06: First Spotify iOS SDK beta release
2014-03-24: No longer accepting new Spotify Apps
2014-06-17: First Spotify Web API release
2014-06-25: First Spotify Android SDK beta release

The Web API grew steadily, as documented by the Web APIs changelog. Over time, its feature list improved, supporting anonymous endpoints for generic music metadata as well as OAuth protected endpoints for managing your own music collection and playlists. The only major part missing that prevented developers replacing libspotify was music playback, as the Web API only provides 30 second previews.

From what I recall of 2014 IRC discussions with Spotify employees, they had built a new much smaller library for streaming music. The iOS and Android SDKs were simply platform specific wrappers around this new playback library and the new Web API. My impression is that, after a number of beta releases, the iOS and Android SDKs seamlessly replaced libspotify on those platforms. The plan was apparently to release the new playback library for desktop too, so that it, in combination with the Web API, could replace libspotify there as well.

That was all back in 2014.

Step 4: Deprecate old APIs

At some point, Spotify deprecated their old web API, the Metadata API. There was no blog post about it and it was not mentioned in any Spotify Developer News email I’ve received in recent years. I guess they only published this fact as a note on the Metadata API web page; it is therefore hard to track down exactly when it was deprecated and how the deprecation was communicated. Anyway, it was deprecated, and the natural upgrade path was to the new Web API. Spotify even has a migration guide mapping the concepts of the Metadata API to the new Web API. All good.

In May 2015, after 28 months without a single release or any news, libspotify is officially deprecated. The communication channel of choice? A note on the libspotify web page. No post on the developer blog. No Spotify Developer News email. To be able to use libspotify, all developers have registered and requested a personal application key. To my knowledge, none of these registered library users were notified directly.

Step 5: Shut down an old API

On January 20 2016 Spotify end-of-lifed their Metadata API. I don’t know if this date was communicated on the Metadata API web page well in advance of this shutdown. There’s no blog post on the topic. There’s no news email. There’s no tweet from @SpotifyPlatform or @SpotifyStatus. I can’t find anything except users commenting on various Spotify documentation pages that the text is outdated because the API is no longer merely deprecated, but entirely shut down.

Hopefully they did publish the shutdown date ahead of time. It had a full replacement API and a migration guide. Fair and square. Nothing much to complain about here. It’s time to get porting your code to the Web API!

But frankly, I don’t really care about this Metadata API because I don’t use the Metadata API, do I?

Step 6: Break your API without warning

February 3 2016, Mopidy users start reporting “General transient error” when searching Spotify. This is a libspotify error message known as “SP_ERROR_OTHER_TRANSIENT” with error code 16. This error usually means that there is some unspecified issue with the Spotify service. We’ve actually seen it before and like its name suggests, it is indeed transient and soon goes away.

According to a series of tweets between my fellow Mopidy developer Nick Steel and @SpotifyCares it appears that the libspotify search functionality was backed by the Metadata API’s search functionality. Who knew? I’m not aware of any relation between these APIs ever being mentioned publicly. No libspotify user could possibly have known that the Metadata API shutdown would affect them.

Let’s summarize: libspotify hasn’t had any releases for three years and it was officially deprecated in May last year. But, there have been no warnings about any shutdown. The libspotify project is likely no longer staffed at all. Did someone just forget that libspotify depended on the Metadata API they were shutting down?

Many newer networked AV receivers use the Spotify Connect libraries that are exclusive to Spotify’s commercial partners. But some receivers probably still use libspotify. If so, did Spotify just break hardware sold with Spotify support as a major feature? Something that people are paying a monthly fee to use?

It seems they did!

In the Spotify Community forums there are numerous reports of broken devices and software that all have two things in common: the date the problem started occurring, and that search is the only feature that is broken.

Denon receivers, including models: CEOL N8
Logitech Squeezebox media players
Marantz receivers, including models: M-CR510, M-CR610, NR1504, NR1603, SR5007, SR6008
Onkyo receivers, including CR-N755, TX-NR509, TX-NR609, TX-8050
Roku media players

Surely, Spotify will quickly explain themselves and fix this?

Step 7: Stay quiet

Since the API shutdown, Spotify has been very quiet. No posts on the developer blog. No email newsletter. No tweets from @SpotifyPlatform since December 1 last year.

Some users at The Spotify Community forum are quoting responses from Spotify. Most responses seem to link to the Metadata API migration docs and state that application developers must migrate. In other cases the responses point the finger at the commercial partner which only adds to the confusion.

Some of these devices may use the Metadata API directly, and in those cases the application maintainers are probably to blame. However, I’m quite certain that the libspotify search issue is responsible for a fair share of these complaints. libspotify, in contrast to the Metadata API, has never been officially shut down. The responsibility for any breakage caused by libspotify is Spotify’s alone.

What I want from Spotify

Apologize to your paying customers and supporters.
Get substantially better at communicating deprecations and shutdowns. We want all news, not just good news.
Give us a new supported C library for audio playback. Now! Not later this year. I’ve heard that promise for three consecutive years now.

We can live with pre-release software quality initially. Getting the library out sooner rather than later shows us that there is a road ahead for all the projects that stream music from Spotify. Let us get started making new language wrappers.
Release Spotify Connect specifications and libraries.

We want to make music players that can be controlled by the Spotify mobile app.

We want to make music controllers that can play music on all the Spotify Connect software and hardware players we’ve invested in.

You’ve created this technology, now let us use it.

Thanks to Nick Steel for reviewing this blog post.

January contributions

2016-02-01T00:00:00CET

The following is a short summary of my open source work in January, just like I did back in November and December.

Debian

Uploaded mopidy 1.1.2-1: New upstream release. Moved to pkg-mopidy team.
Uploaded mopidy-dleyna 1.0.5-1: New upstream release. Moved to pkg-mopidy team.
Uploaded mopidy-soundcloud 2.0.2-1: New upstream release. Moved to pkg-mopidy team.
Uploaded mopidy-somafm 1.0.1-1: New package in pkg-mopidy.
Uploaded mopidy-internetarchive 2.0.0-1: New package in pkg-mopidy.

Mopidy

PR #1381: Made lookup() ignore tracks without URI.
Updated docs for Raspberry Pi installation to match Raspbian jessie.
Rewrote docs for running Mopidy as a service, more focused on systemd than Debian specifics to also cater for Arch users.
PR #1397: Added missing MPD volume command.
Merged a bunch of contributed fixes and released Mopidy 1.1.2.
Updated all extensions hosted under the Mopidy GitHub organization with either the name of the primary maintainer or a call for a new maintainer. The extensions in need of a new maintainer are:
If you’re a user of any of these and want to contribute, please step up. Instructions can be found in the README of any of these projects.
The feature/gst1 branch is complete as far as I know. There are no known regressions from Mopidy 1.1.2. PR #1419 is hopefully the last iteration of the pull request and GStreamer 1.x support will land in Mopidy 1.2.
Wrapping up the 1.2 release is now the focus. We might want to include this in Debian/Ubuntu before the Ubuntu 16.04 import freeze February 18, depending on feedback over the next week or two.

Comics

Added one new crawler.
Released comics 2.4.2.
Merged one new crawler and a crawler update.

December contributions

2016-01-01T00:00:00CET

The following is a short summary of my open source work in December, following up on my first report in November.

Debian

Uploaded mopidy-dirble 1.2.0-1: New upstream release.
Created the pkg-mopidy Alioth team to set myself up for sharing the maintenance of Mopidy packages. As I upload new releases, I’ll gather the git repositories of Debian packages related to Mopidy here. My intention is for the team to follow the DPMT policy closely.
Sponsored: python-ase 3.9.1.4567-2, which adds Python 3 support.

Mopidy

The feature/gst1 branch: Finished porting Mopidy from GStreamer 0.10 to PyGI and GStreamer 1.x. Merge of the branch is currently blocked on a single test failure (test_gapless) and issues with transitioning from one track to another with Mopidy-Spotify, which is the only backend using an appsrc for playback.

The goal is for this branch to be part of Mopidy 1.2, which I hope to have in Debian/Ubuntu before the Ubuntu 16.04 import freeze February 18.
The feature/py3-compat branch: I’ve worked quite a bit on this private branch, frequently rebased on top of feature/gst1. Currently Mopidy starts without any crashes on Python 3 and the test suite is down to 262 failed and 1841 passed tests.

My current thinking, is that this will become part of a Mopidy 2.0 release, which will support both Python 2.7 and 3.4+. As soon as most of Mopidy’s extension ecosystem supports Python 2+3, a new Mopidy major release (3.0?) will drop Python 2 support.
Merged a bunch of pull requests, both targeting the 1.1.2 bug fix release and the 1.2 feature release.

November contributions

2015-11-30T00:00:00CET

The following is a short summary of my open source work in November. My hope is that keeping better track of what I’m doing will help me reflect on how I spend my time, and help me to focus my efforts better.

Debian

Completed the NM process and became a Debian Developer in the end of October.
Joined the Debian Python Modules Team (DPMT).
Fixed RC bug #803662 and uploaded sphinxcontrib-spelling 2.1.2-1.
Uploaded python-uritools 1.0.1-2: Moved to DPMT. Now runs tests when building.
Uploaded python-ws4py 0.3.4-2: Moved to DPMT. Migrated to git-dpm and pybuild. Now runs tests when building.
Uploaded python-pykka 1.2.1-2: Moved to DPMT. Migrated to git-dpm and pybuild. Now runs tests when building.
Tested the upcoming Debian packaging of the Let’s Encrypt client software on Ubuntu 15.10, and reported a missing dependency. (Successfully created and deployed five free TLS certificates in a few minutes.)
Uploaded mopidy-dleyna 1.0.4-1: New upstream release.
Uploaded mopidy-podcast 1.1.2-1: New upstream release. Now runs tests when building.
Uploaded mopidy-soundcloud 2.0.1-1: New upstream release.

Mopidy

Released Mopidy-Spotify 2.2.0: Fixes related to duplicate “Starred” playlists and albums from year 0.
Moved Mopidy’s Travis CI testing from Ubuntu 12.04 to Ubuntu 14.04, to prepare for GStreamer 1.x, and eventually testing with Python 3.4. PR #1341
Worked on porting Mopidy from GStreamer 0.10 to PyGI and GStreamer 1.x. PR #1339
Briefly looked at what remains to get Mopidy running on both Python 2.7 and 3.4+ when we’ve landed the port to GStreamer 1.x. Doesn’t look too bad, except that ConfigParser doesn’t want to work with bytes in Python 3, so there’s no easy way to read a config file referring to a path on a non-UTF-8 file system.

Comics

Fixed two old crawlers. Added two new crawlers.
Needs to upgrade to Django 1.8 before the Django 1.7 security support ends this December.

Building ARM Debian packages with pbuilder

2015-03-08T00:00:00CET

The goal of this post is to help myself reproduce this pbuilder setup in the future. If you find it useful too, then that’s great.

Building ARM packages on older ARM devices like the Raspberry Pi 1 is slow, so I want to use a single amd64 machine to build Debian packages for all my target platforms:

amd64,
i386,
armel/ARMv4+ (e.g. Debian on Raspberry Pi 1),
armhf/ARMv6+ (Raspbian), and
armhf/ARMv7+ (e.g. Debian/Ubuntu on Raspberry Pi 2, Odroid C1, etc.).

Preferably, I want to build the packages for the current Debian stable, which at the time of writing is wheezy, so that they’ll work for as many users as possible.

Instead of managing a bunch of virtual machines by hand, we can use pbuilder. pbuilder creates chroots with debootstrap, keeps them updated with changes to the base system, and keeps the chroots clean of dependencies installed when you build packages within them.

There is an introduction to pbuilder and lots of information on various ways of using it in the Ubuntu wiki.

I’m doing the following on an amd64 system running Ubuntu 14.10.

I start out with a ~/.pbuilderrc to help simplify the later commands:

#!/bin/sh

set -e

if [ "$OS" == "debian" ]; then
    MIRRORSITE="http://ftp.no.debian.org/debian/"
    COMPONENTS="main contrib non-free"
    DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}"
        "--keyring=/usr/share/keyrings/debian-archive-keyring.gpg")
    : ${DIST:="wheezy"}
    : ${ARCH:="amd64"}
    if [ "$DIST" == "wheezy" ]; then
        #EXTRAPACKAGES="$EXTRAPACKAGES debian-backports-keyring"
        OTHERMIRROR="$OTHERMIRROR | deb $MIRRORSITE wheezy-backports $COMPONENTS"
    fi
elif [ "$OS" == "raspbian" ]; then
    MIRRORSITE="http://ftp.acc.umu.se/mirror/raspbian/raspbian/"
    COMPONENTS="main contrib non-free"
    DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}"
        "--keyring=/usr/share/keyrings/raspbian-archive-keyring.gpg")
    : ${DIST:="wheezy"}
    : ${ARCH:="armhf"}
elif [ "$OS" == "ubuntu" ]; then
    MIRRORSITE="http://no.archive.ubuntu.com/ubuntu/"
    COMPONENTS="main restricted universe multiverse"
    DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}"
        "--keyring=/usr/share/keyrings/ubuntu-archive-keyring.gpg")
else
    echo "Unknown OS: $OS"
    exit 1
fi

if [ "$DIST" == "" ]; then
    echo "DIST is not set"
    exit 1
fi

if [ "$ARCH" == "" ]; then
    echo "ARCH is not set"
    exit 1
fi

NAME="$OS-$DIST-$ARCH"

if [ "$ARCH" == "armel" ] && [ "$(dpkg --print-architecture)" != "armel" ]; then
    DEBOOTSTRAP="qemu-debootstrap"
fi
if [ "$ARCH" == "armhf" ] && [ "$(dpkg --print-architecture)" != "armhf" ]; then
    DEBOOTSTRAP="qemu-debootstrap"
fi

DEBOOTSTRAPOPTS=("${DEBOOTSTRAPOPTS[@]}" "--arch=$ARCH")
BASETGZ="/var/cache/pbuilder/$NAME-base.tgz"
DISTRIBUTION="$DIST"
BUILDRESULT="/var/cache/pbuilder/$NAME/result/"
APTCACHE="/var/cache/pbuilder/$NAME/aptcache/"
BUILDPLACE="/var/cache/pbuilder/build"
HOOKDIR="/var/cache/pbuilder/hook.d/"

The .pbuilderrc file cares about three environment variables:

OS: Either debian, raspbian, or ubuntu
DIST: For example wheezy, jessie, or trusty
ARCH: For example amd64, i386, armel, or armhf

Based on these three variables, the .pbuilderrc script selects the proper APT mirror, distribution components, and keyring to verify the downloaded packages. If the architecture is armel or armhf, and we’re not currently on that architecture, it uses qemu-debootstrap to bootstrap the chroot and copies a static qemu emulator for ARM into the chroot.

For more details on the qemu part, see the Ports page in the Ubuntu wiki.

Before running pbuilder, we have to install pbuilder and qemu-debootstrap:

sudo apt install pbuilder qemu-user-static

And we also need the keyrings. Ubuntu includes packages with the Ubuntu and Debian keyrings:

sudo apt install ubuntu-keyring debian-archive-keyring

While we have to download the Raspbian keyring package and install it by hand:

wget http://archive.raspbian.org/raspbian/pool/main/r/raspbian-archive-keyring/raspbian-archive-keyring_20120528.2_all.deb
sudo dpkg -i raspbian-archive-keyring_20120528.2_all.deb

You should now have all keyrings referenced from the .pbuilderrc:

$ ls /usr/share/keyrings
...
/usr/share/keyrings/debian-archive-keyring.gpg
/usr/share/keyrings/raspbian-archive-keyring.gpg
/usr/share/keyrings/ubuntu-archive-keyring.gpg
...
$

Then we can bootstrap the five chroots. This takes a bit of time as it downloads all packages needed to bootstrap a fully functional OS. Five times.

sudo OS=debian DIST=wheezy ARCH=amd64 pbuilder --create
sudo OS=debian DIST=wheezy ARCH=i386 pbuilder --create
sudo OS=debian DIST=wheezy ARCH=armel pbuilder --create
sudo OS=raspbian DIST=wheezy ARCH=armhf pbuilder --create
sudo OS=debian DIST=wheezy ARCH=armhf pbuilder --create

This will create tarballs with the pristine chroots:

$ ls /var/cache/pbuilder
...
/var/cache/pbuilder/debian-wheezy-amd64-base.tgz
/var/cache/pbuilder/debian-wheezy-armel-base.tgz
/var/cache/pbuilder/debian-wheezy-armhf-base.tgz
/var/cache/pbuilder/debian-wheezy-i386-base.tgz
/var/cache/pbuilder/raspbian-wheezy-armhf-base.tgz
...

Now we’re ready to build packages. Basically, you just get the source of a Debian package, change into its directory, and run:

OS=raspbian DIST=wheezy ARCH=armhf pdebuild

If the pdebuild command completes successfully, you’ll find the resulting Debian source and binary packages for armhf in e.g. /var/cache/pbuilder/raspbian-wheezy-armhf/result. All without using the rather slow Raspberry Pi 1 I used to build packages with.

Appendix: Depending on packages from an unofficial APT repo

Since I build packages for Mopidy, to be hosted at apt.mopidy.com, they often depend on other packages hosted there, and not just packages from the official repos. Thus I need to add an extra APT repository to the chroots. As I already have five chroots, I don’t want to change each chroot manually with pbuilder --login --save-after-login.

The solution is to add a hook script to be executed every time the chroot is being set up, before the Debian packaging begins, which adds apt.mopidy.com as an APT repo and runs apt-get update.

Create the directory /var/cache/pbuilder/hook.d and make a file /var/cache/pbuilder/hook.d/D10add-apt.mopidy.com:

#!/bin/sh

cat << EOF | apt-key add -
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.10 (GNU/Linux)

mQINBEzXBRYBEADGWsXEGa+WcoVMv6SevKPJQsFNbp/CbK6J8xJ0wVdf5LdfWF46
rNFMUa6DPwVOjp7wdY6mwTnW7OkpHLakP9DzaUXLGZ/9Bku7O+Aw+NDLC2W4IbdJ
... key data removed for brevity ...
0ax2VWX0487MYQcU8e2fEPOi3QkPc7zMr7wWDeB2JNBf2y/FnJxcbTLS6CEWr8mf
nXSGfezg+nzdC8eags3zCmQ5dlIKFLi7QautytYDA32vl09JcLl7mA8cxST8LyGw
rNNPwkCckaxcrWfSUso6saWj5j8y+OVn
=kcoa
-----END PGP PUBLIC KEY BLOCK-----
EOF

echo "deb http://apt.mopidy.com/ stable main contrib non-free" >> /etc/apt/sources.list
apt-get update

Remember to make the hook script executable, or else it will have no effect:

sudo chmod a+x /var/cache/pbuilder/hook.d/D10add-apt.mopidy.com

And that should be it. The hook script will now be executed before any package build and all packages from the APT repo will be available to pdebuild.

Debian packaging of Mopidy

2014-10-28T00:00:00CET

My first upload to Debian as a Debian Maintainer, Mopidy 0.19.4-3, landed in Debian testing today, well in time for the upcoming freeze.

The new version adjusts the LSB facilities the sysvinit script depends on, to make sure that DNS lookups, DBus (used by Mopidy-MPRIS), and Avahi (used for Zeroconf service publishing) are available before Mopidy starts.

Most importantly, maybe, the new package adds a systemd service file. The sysvinit init script included a custom action called “run”, which is used to run Mopidy subcommands with the same user and configuration as the system service use. To replace this with something that can also be used on a system running systemd, a new executable called mopidyctl has been added. The new executable does exactly the same: it runs Mopidy with the same user and configuration as the init system use to start Mopidy as a system service.

In short, sudo service mopidy run config now becomes sudo mopidyctl config, both on systems running sysvinit and systems running systemd.

Mopidy packaged in Debian and Ubuntu

2013-12-28T00:00:00CET

Looking back to my last post from September, my goal was to have the music server Mopidy packaged in Debian by the end of the year and in Ubuntu in time for the 14.04 LTS release in April. As of yesterday, Mopidy 0.17.0 is a part of Debian unstable and Ubuntu trusty, just a few days after Mopidy’s fourth anniversary on December 23.

Next up will be to get some Mopidy extensions into Debian and Ubuntu, starting with Mopidy-Scrobbler, Mopidy-MPRIS, Mopidy-Soundcloud, and Mopidy-Beets.

Until then, Debian packages of some Mopidy extensions are available from apt.mopidy.com.

Pykka packaged in Debian and Ubuntu

2013-09-03T00:00:00CEST

The Python actor library Pykka is now packaged as python-pykka and python3-pykka in Debian unstable and Ubuntu saucy, soon to be Ubuntu 13.10. In a few more days, the packages will be probably be available in Debian testing as well.

After a decade of using Debian and later Ubuntu, this is only my second package in Debian and Ubuntu, and the first of my own projects being packaged. With time, I’m planning on packaging and getting the rest of the Mopidy ecosystem into Debian and Ubuntu. My current goal is to have the majority in by the end of the year, as to get into Ubuntu in time for the 14.04 LTS release.

Until then, Debian packages related to Mopidy are available from apt.mopidy.com.