"Mer" is an experimental project, where an attempt of "reconstructing" the Maemo platform is done, based on the proposal on Maemo_Reconstructed. Mer means ocean in French, "more" in Danish, etc.. New blueprint for discussion can be found at Mer_Blueprint_New.



Iteration 1 (done)

Idea: Build as much of Maemo trunk we can, adapt to Ubuntu, chaos coding, microdocument through Jaiku, and make it work and run. Name was M-R PoC.

Results: 123MB flash for minimal Ubuntu base system, Xorg omapfb driver, tslib Hildon on top. Possible to do things like:

A choice was made to restart and do things by the book. We originally based on Mojo Handhelds Ubuntu port to ARM.

Iteration 2: Mer Alpha

Mer: Provide a experimental system for Maemo community use, as a playground to try out new technologies and ideas on. Give community a voice in system architecture and continued development of the Maemo platform post Fremantle. Give the community ability to give documented, researched input to the development process of Maemo. Mer should be cross-platform, both for i386, armel, and not rely on running on specific devices.

Upstream distribution: Ubuntu 'Jaunty' for ARM and i386. Experiment with VFP/optimized versions (use of hwcap) for libraries that would benefit from it. Maemo trunk.

Development process: Use of Launchpad. Everything must be done in bzr branches and published in the m-r project on Launchpad. Use of builders, which only accepts bzr branches and source packages and are primary uploaders to repository. Packages must compile in both i386 and armel ideally.

Microdocumentation is still done in Jaiku.

Repository: as primary repository. Mirrors should be added.

Phase 1: Infrastructure setup

  • Set up project (done).
  • Set up APT repository (done)
  • Set up i386 and armel builders (qemu and or beagleboard), which relies on clean buildd chroots (done)

Builder works by first attempting to generate a source package from a bzr branch (after getting build dependancies) in a buildd chroot, to make sure the packages are sane. Then it builds i386 and lets this do the binary i386 and binary indep packages. Then it lets the armel builder(s) do their job on compiling the package. This way we have an early warning if a package does not compile at all instead of wasting hours on waiting for armel builder to fail.

Phase 2: Establishing base system

  • Create bzr branches for Maemo trunk packages and push them to launchpad.
  • Compile these for i386, armel (first glib, then gtk, then .. ending with a full hildon desktop, python-desktop), and builder will upload to repository.
  • Establish which dependancies applications targetting the Maemo platform, use, that are not OSS or dbus wrappers. What are the portability problems of the Maemo platform.
  • Establish system architecture and abstractions (DSME, MCE, HAL, OHM, etc), must take into consideration the cross-platform nature of Mer.
  • Establish where Mer begins and where it ends in terms of what does the generic platform include, and which is platform-specific / vendor-specific.
  • Establish what constitutes stable packages for inclusion into beta/testing
  • Establish what our relation to Maemo is, - Maemo council as governing body?
  • Establish how Maemo packages conflict with desktop elements of upstream. (libgnomevfs, maemo GTK), and how these can work together.
  • Establish how close we are to being like Maemo, by trying to build packages from Extras (mer-extras?)
  • Work on image builders for the following targets:
    • N8x0 tar.gz (compat with N8x0 bootmenu-svn initfs), fully open source
    • N8x0 tar.gz (compat with N8x0 bootmenu-svn initfs), with value adders such as wifi/bluetooth firmware drivers, hald-addon-bme, gps driver, adobe flash, .. other apps, to show the ability of differentation
    • N8x0 jffs2 rootfs (for QEMU-N8x0 emulation)
    • BeagleBoard jffs2 rootfs
    • i386 tar.gz (targeting Intel D945GCLF2 board)
    • 770 tar.gz (compact with bootmenu-svn initfs), installable on RS-MMC.

Phase 3a: User interface

  • Theming (Plankton is one theme, but what other exists that are redistributable)
  • Icon sets (open license, redistributable)
  • Control panels
  • Translations?
  • Systemui (normally seen when charging, or when pressing power button, or when you're locking your screen). Powerlaunch will be used for this.
  • Experimental interactions? TV screen and wiimote?
  • Tech demos: Mer on Beagleboard, netbook, ASUS Eee Top (touch?), N8x0, 770, Pandora, Zaurus, x86+TV screen

Phase 3b: Experimental system use

  • Rescue menu & bootmenu
  • Clone-to-SD
  • Unionfs use
  • USB networking, Bluetooth PAN
  • NTP synchronization
  • .. others


Contributing to Mer

The purpose of Mer is to support future OS development done in the tablet community and to aid in helping Maemo to be more in alignment with standard distributions and serve as an experimental community platform..

If you'd like to start contributing to Mer in any way:

  • Get a Jaiku account (mail carsten.munk at if you want an invite)
  • Join the #reconstructedPOC channel on Jaiku, and microdocument your Mer related activities.
  • Get a account.
  • Ideally, if possible, hang out on #maemo on IRC,
  • Participate in getting the blueprints for Mer made as described in Roadmap.

We are currently in need of:

  • Maemo package porters (help getting the Maemo released source compiling and working in Mer.)
  • People interested in system architecture (initfs, MCE, DSME, etc.)
  • People with other devices than N8x0s that runs Linux that could benefit from Mer. (>= ARMv5t, x86 preferred
  • Someone who can investigate the use of HWCAP, how can some libraries be compiled for ARMv7 and distributed alongside non-ARMv7 libs? What libraries benefit?
  • People with community feel - working out the formalities, procedures for example, how can vendors work with a Mer style distribution?, how does one gain upload rights. Mer Extras or not? Mer PPA?
  • Powerlaunch ( scripters - possibly our systemui
  • People interested in integrating non-hildon apps into hildon - and integrating Mer/Maemo UI parts into other DE's
  • Theme and icon designers (open themes, icons)
  • Launchpad maintainers
  • Repository mirrors
  • .. someone who can make a proper logo.

.. and more to come. But, please remember. Mer is not:

  • A Maemo competitor - Mer is meant as a proof of concept to research in what directions may be feasible and which may not be, to serve as properly researched and documented community input to the Maemo platform. To be able to show what the Maemo platform is capable of.
  • An Nokia/Maemo-backed effort, - 100% done by tablet enthusiasts
  • Something that is installable here and now
  • Ready for use

Mer Developer Tools

# debootstrap --verbose --components=main,universe,multiverse jaunty /TARGET
# export LC_ALL=C
# chroot /TARGET rm /usr/sbin/invoke-rc.d
# chroot /TARGET rm /sbin/start-stop-daemon
# chroot /TARGET ln -s /bin/true /usr/sbin/invoke-rc.d
# chroot /TARGET ln -s /bin/true /sbin/start-stop-daemon
# chroot /TARGET mount -t proc proc /proc
# chroot /TARGET mount -t devpts devpts /dev/pts
# cat > /TARGET/etc/apt/preferences
Package: *
Pin: origin
Pin-Priority: 801

Package: *
Pin: release a=jaunty
Pin-Priority: 800
^D (control-D)
# cat > /TARGET/etc/apt/sources.list
deb jaunty main universe multiverse
deb-src jaunty main universe multiverse
deb alpha main contrib non-free
deb-src alpha main contrib non-free
# chroot /TARGET apt-get update
# chroot /TARGET apt-get dist-upgrade
# chroot /TARGET apt-get install --force-yes -y bzr devscripts subversion build-essential dpkg-dev bzr-svn debhelper
# chroot /TARGET dpkg-reconfigure dash # Make /bin/sh not be dash. 
# chroot /TARGET # you now have a Mer developer environment for i386.

Guidelines for branching a Maemo package

For packages on

  • Rule: When we are branching Maemo packages, we branch the tags (released packages). We have to respect the author's choice to release when they think the package is stable enough for release and we should not follow trunk unless it is absolutely needed (and justified in changelog)
  • There might be certain exceptions in repository pre this rule was made, but this should stable out eventually
  • Get bzr, bzr-svn, and run: bzr svn-branching-scheme --set and set it to:

To branch a Maemo package, example,

$ bzr branch epeg
$ cd epeg
$ cat debian/control # What is the source package called? SOURCE from now on.

So, a new version comes out of epeg,

$ cd epeg
$ bzr merge
$ bzr commit -m "merged upstream changes from"
$ bzr push # upload changes to launchpad

For packages on

  • Retrieve the tar.gz, .diff.gz (if applies), .dsc, and dpkg-source -x *.dsc, source package hereby named SOURCE
  • cd into the unpacked directory
  • bzr init
  • bzr add
  • bzr commit -m "initial commit of <VERSION OF PACKAGE>"
  • bzr push lp:~LAUNCHPADUSERNAME/m-r/SOURCE # upload to launchpad

Porting a Maemo package to Mer

  • Follow the branching guidelines above
  • Verify ./configure exists in source package.
  • If not, verify an is mentioned in debian/rules. If it isn't, add NOCONFIGURE=1 ./ before the ./configure call.
  • In both cases, verify the source package has autoconf, libtool and automake as build dependancies
  • If you change anything in the package, make sure to edit it in debian/changelog, use "merX" as suffix on versions. where X is the version of your changes. Make sure to document what you did in bzr commit -m "<Message>"
  • When you pull new upstream version, make sure versions are aligned in the changelog (merX on the newest version)
  • Verify it builds using dpkg-buildpackage.

Getting your package included in the Repository

  • Make sure it compiles after getting your build dependancies, dpkg-buildpackage.
  • Ideally test both dpkg-buildpackage -S -us -uc, dpkg-buildpackage -b -us -uc, dpkg-buildpackage -B (some packages may not build any arch-dep packages, so that's ok. Microdocument it on Jaiku.)
  • bzr export

    Invalid language.

    You need to specify a language like this: <source lang="html4strict">...</source>

    Supported languages for syntax highlighting:

    abap, actionscript, actionscript3, ada, apache, applescript, apt_sources, asm, asp, autoit, avisynth, bash, basic4gl, bf, bibtex, blitzbasic, bnf, boo, c, c_mac, caddcl, cadlisp, cfdg, cfm, cil, cmake, cobol, cpp, cpp-qt, csharp, css, d, dcs, delphi, diff, div, dos, dot, eiffel, email, erlang, fo, fortran, freebasic, genero, gettext, glsl, gml, gnuplot, groovy, haskell, hq9plus, html4strict, idl, ini, inno, intercal, io, java, java5, javascript, kixtart, klonec, klonecpp, latex, lisp, locobasic, lolcode, lotusformulas, lotusscript, lscript, lsl2, lua, m68k, make, matlab, mirc, modula3, mpasm, mxml, mysql, nsis, oberon2, objc, ocaml, ocaml-brief, oobas, oracle11, oracle8, pascal, per, perl, php, php-brief, pic16, pixelbender, plsql, povray, powershell, progress, prolog, properties, providex, python, qbasic, rails, rebol, reg, robots, ruby, sas, scala, scheme, scilab, sdlbasic, smalltalk, smarty, sql, tcl, teraterm, text, thinbasic, tsql, typoscript, vb, vbnet, verilog, vhdl, vim, visualfoxpro, visualprolog, whitespace, whois, winbatch, xml, xorg_conf, xpp, z80

Retrieved from ""