The Maemo Record

Extras, Extras-testing and Extras-devel explained

The Maemo repositories

PACKAGErepositories
SECTIONthe software
IN THE LINEcore: the platform itself
ANSWERSmaemo repositories
ARCHIVED LINKS1 old article address points here
A package-style metadata block listing the Maemo repositories: label on the left, value on the right.

Maemo repositories were the apt catalogues a Maemo device installed software from, and on Maemo 5 three of them mattered: Extras-devel for raw developer uploads, Extras-testing for packages under community review, and Extras for the tested software an ordinary owner was meant to use.

The Application manager on the device called them catalogues, the underlying apt configuration called them repositories, and the two words meant the same thing. Everything a Maemo user installed that Nokia had not preinstalled came through one of them, which is why the catalogues, and not any storefront, are the right place to start when working out what the platform could do. The wider picture is in What you could actually install.

What Maemo means, and what a catalogue was

Maemo means nothing in English, and Nokia never published an expansion or an acronym for it. A folk reading circulated among users splitting the name into the Finnish words maa and emo, but that reading has no official backing and the platform documentation simply treats Maemo as a name. What the name referred to is precise enough: the Debian-based Linux operating system Nokia shipped on its internet tablets from 2005 and on the N900 from November 2009, built on the Linux kernel, GTK and the Hildon user interface layer.

A catalogue, in that system, was one line of apt configuration presented as a form. It carried a web address, a distribution codename, and a list of components. Maemo 5 used the codename fremantle and the components free and non-free; Maemo 4 used diablo, and Maemo 4.0 used chinook. Get the codename wrong and the catalogue was valid but empty, which is the single most common reason a correctly typed address appeared to do nothing.

The three catalogues, and what each one was for

The three catalogues were tiers of confidence, not three separate collections. The same package moved through all of them, gaining scrutiny at each step, and a package that failed stayed where it was.

Catalogue What it held Who it was for Risk
Extras Packages promoted out of testing Any owner of the device Low, and safe to leave enabled
Extras-testing Candidates awaiting community votes Volunteers willing to test and report Moderate, occasional broken builds
Extras-devel Every autobuilt upload, unreviewed Developers, and only briefly for users High, capable of breaking the system

Applications reached these catalogues on their own terms and on their own schedule, which is how the platform ended up with software Nokia would never have written: mapping and routing clients of the kind described in Maps and navigation, emulators, terminal tools, and games that a signed-application regime would have kept out.

How a package was promoted from Extras-devel to Extras

Promotion from Extras-devel to Extras ran as a sequence, and a developer could not skip a step.

  1. Upload the source package to the maemo.org autobuilder, which produced the ARM binaries and placed them in Extras-devel.
  2. Request promotion to Extras-testing once the package installed cleanly and did not conflict with system packages.
  3. Collect votes from testers, who installed the candidate deliberately and reported whether it worked.
  4. Wait out the quarantine period that maemo.org’s quality assurance policy imposed on every candidate.
  5. Promote to Extras, which happened automatically once the vote balance and the waiting period were both satisfied.

The exact vote threshold and the length of the quarantine period were set by maemo.org’s QA policy and were revised more than once over the life of the platform, so no single pair of numbers describes the whole period honestly.

Nothing in that pipeline resembled the review Nokia applied to its own storefront, where an application was signed, listed and sold under Nokia’s account system. The two channels coexisted for the whole life of Maemo 5, and their relationship is set out in The Ovi Store.

How to activate the Extras catalogues in the Application manager

To activate a catalogue in the Application manager, you added it by hand from the application’s own menu, filling in three fields. The steps below are what the 2010 how-to guides described, and they are recorded here as history: this site distributes no packages, no repackaged applications and no firmware.

  1. Open the Application manager on the device.
  2. Choose Application catalogues from the menu.
  3. Select New to create an empty catalogue entry.
  4. Enter a name, the web address on repository.maemo.org, the distribution codename, and the components.
  5. Save the entry and let the Application manager refresh its package lists.
  6. Disable the entry again from the same screen once the package you wanted is installed, if the catalogue you enabled was Extras-devel.

All three fremantle catalogues lived under repository.maemo.org, took fremantle as the distribution, and took free and non-free as the components; only the path differed between extras, extras-testing and extras-devel. Enabling a catalogue changed nothing on its own. It only widened what the Application manager offered, and what an update would pull.

Why leaving Extras-devel enabled was dangerous

Leaving Extras-devel enabled was dangerous because it was an autobuilder output, not a curated collection. Nothing in it had been reviewed, some of it replaced system components such as the desktop, the theme engine or the kernel modules, and packages in it could depend on other packages that were themselves broken. A user who enabled it and then ran a general update was not installing one experimental application, but offering every experimental package on the device a chance to upgrade a working system component. Rebuilding from that point meant reflashing, and reflashing is outside what this reference covers.

Maemo repositories against MeeGo repositories

Maemo repositories and MeeGo repositories were incompatible at the packaging layer, which is the clearest practical difference between the two projects. Maemo was Debian-derived and used .deb packages with apt; MeeGo, announced by Nokia and Intel at Mobile World Congress in February 2010 as the merger of Maemo with Intel’s Moblin and hosted by the Linux Foundation, took Moblin’s RPM packaging and its build system. A Maemo package could not be installed on MeeGo without being rebuilt.

MeeGo as a joint project ended in September 2011, and the Nokia N9 that shipped that year ran MeeGo 1.2 Harmattan, which was Maemo 6 lineage with Debian packaging rather than the RPM MeeGo core. The Mer project forked the MeeGo core and Jolla built Sailfish OS on it, and Sailfish OS is still shipping. That is the line most people are following when they arrive at this subject from a Jolla device.

Maemo Leste and its own repositories

Maemo Leste keeps the repository model going on current hardware, and it is the reason the question is not purely historical. Leste is a community operating system built on Devuan, the systemd-free Debian derivative, reimplementing the Maemo user interface on top of it, with development carried out in the open on GitHub. It publishes its own apt repositories, so installing software on Leste works the way it worked on the N900: add the catalogue, install the package.

Leste targets a mix of old and new devices, among them the Nokia N900, the Motorola Droid 4, the PinePhone and the PineTab. Installing it means writing an image to the device, and this site neither hosts nor links those images; the project distributes them itself and documents the procedure per device. What Leste is, and how far it has got, is covered in Maemo Leste, the continuation.

Where to go next