Mer

"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..

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:


 * Hildon Desktop with Quicknote
 * Hildon Desktop with GQView

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: http://trac.tspre.org/mer/jaunty as primary repository. Mirrors should be added.

Phase 1: Infrastructure setup

 * Set up launchpad.net 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 gmail.com if you want an invite)
 * Join the #reconstructedPOC channel on Jaiku, and microdocument your Mer related activities.
 * Ideally, if possible, hang out on #maemo on IRC, irc.freenode.net
 * 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 (powerlaunch.garage.maemo.org) 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

 * A jaunty-i386 chroot, grab debootstrap from http://archive.ubuntu.com/ubuntu/pool/main/d/debootstrap/debootstrap_1.0.10ubuntu1_all.deb and install it and do the following, where /TARGET is a place where you have space for a jaunty base.

Package: * Pin: origin trac.tspre.org Pin-Priority: 801
 * 1) debootstrap --verbose --components=main,universe,multiverse jaunty /TARGET http://archive.ubuntu.com/ubuntu
 * 2) chroot /TARGET rm /usr/sbin/invoke-rc.d
 * 3) chroot /TARGET rm /sbin/start-stop-daemon
 * 4) chroot /TARGET ln -s /bin/true /usr/sbin/invoke-rc.d
 * 5) chroot /TARGET ln -s /bin/true /sbin/start-stop-daemon
 * 6) chroot /TARGET mount -t proc proc /proc
 * 7) chroot /TARGET mount -t devpts devpts /dev/pts
 * 8) cat > /TARGET/etc/apt/preferences

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

Guidelines for branching a Maemo package
For packages on https://stage.maemo.org/viewcvs.cgi/projects/?root=maemo


 * 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 https://stage.maemo.org/svn/maemo and set it to:

projects/connectivity/*/tags/* projects/connectivity/*/trunk projects/connectivity/*/branches/* projects/email/*/tags/* projects/email/*/trunk projects/email/*/branches/* projects/haf/trunk/* projects/haf/tags/*/* projects/haf/branches/*/*

To branch a Maemo package, example, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/

$ bzr branch https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo0/ epeg $ cd epeg $ cat debian/control # What is the source package called? SOURCE from now on. $ bzr push lp:~LAUNCHPADUSERNAME/m-r/SOURCE

So, a new version comes out of epeg, https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/

$ cd epeg $ bzr merge https://stage.maemo.org/svn/maemo/projects/haf/tags/epeg/0.9.0.005maemo1/ $ bzr commit -m "merged upstream changes from 0.9.0.005maemo1" $ bzr push # upload changes to launchpad

For packages on http://repository.maemo.org/pool/diablo/


 * 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 "
 * 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 autogen.sh is mentioned in debian/rules. If it isn't, add NOCONFIGURE=1 ./autogen.sh before the ./configure call.
 * In both cases, verify the source package has autoconf, libtool and automake as build dependancies
 * If there are A | B statements in Build-Depends, please choose one and remove the |. Our source package builder cannot handle it yet (XXX)
 * 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 ""
 * 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 SVN

 * 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.)
 * You need access to merbuilder, ask Stskeeps on Jaiku/IRC for this.
 * On http://jaiku.com/channel/merbuilder, write "build  "
 * Monitor progress at http://merbuilder.jaiku.com
 * An LP player notes that it has picked up a package for building at a certain builder
 * A toast means it baked properly on this architecture. And is uploaded to repository.
 * A heart means it built properly on all architectures and source package. And is uploaded to the repository
 * A bomb means it failed to build on an architecture.
 * A shopping wagon means it has noticed your build request and queued it.

Tainted branches on BZR
The following branches on launchpad, under ~carsten-munk/m-r are tainted - as in, it is not possible to sanely bzr merge with new updates from the Maemo SVN repository, due to late discovery of bzr svn-branching-scheme. If a new version come out or you want to alter the package, please branch off the tags in the repository and upload a branch of your own. The resulting packages are fine, but the uploaded branches are not feasible for distributed work.


 * glib
 * gtk+
 * hildon-1
 * mce-dummy
 * libosso
 * osso-gnome-vfs2
 * sapwood
 * gnome-vfs-filechooser-backend
 * gtkhtml
 * epeg
 * libhildonhelp
 * libhildonmime
 * haf-marketing-release
 * osso-uri-l10n
 * osso-gwconnect
 * hildon-fm-i10n
 * hildon-thumbnail
 * hildon-fm
 * osso-gnomevfs-extra
 * osso-gwobex
 * osso-af-settings

System Init ramdisk / Initfs / etc.
Reference from proposal: http://wiki.maemo.org/Maemo_Reconstructed#Boot_process

Mer devices will normally after booting kernel, to have a proper "device" feel, have a start up phase and a failsafe, to prevent reboot loops, load device drivers for mounting the actual rootfs, rescue operations, etc.

The initfs can take multiple forms, - a jffs2, a cpio initrd (http://suse.mirrors.tds.net/pub/projects/loadlin/loadlin-1.6/initrd.txt), and so on.

The purpose of the initfs is to bring the device and the system to such a state that the actual Mer system can run.

Device State Management Entity
Description based loosely on Nokia's DSME, abstracted away from hardware specifics. Actual implementation may be based on the open source release of DSME when it comes out.

Purpose:
 * Handle pre-HAL/D-BUS/OHM functionality. It is booted up in initfs, as it is the most basic service Mer provides to provide the device feel.
 * Provide a simple communication interface through a unix socket (stream) in initfs.
 * Provide a module interface for loadable shared objects, which can register hooks in communication interface, hook into event loop/timers, etc. Modules should ideally document their interface. Vendors should strive towards generic interfaces, and differ on the implementation/act instead.

Mandatory functionality (in modules possibly):
 * Early system logger, storing reboot/wd reasons
 * Timeout for system startup, if system does not start up, show a message, reboot?
 * Preventing reboot loops
 * Handling "why was the system booted" (bootreason), and providing this information to the OS.
 * Way to make DSME exit gracefully, in case of non-Mer systems replacing DSME
 * Aiding HW/Mer-(self) test (why does my system not boot)

Potential uses:
 * Hardware watchdog
 * Software watchdog?
 * Process watchdog (does this belong in upstart?)
 * Pre-HAL hardware access (icon+text display?)