Maemo on Debian
 Moebian: Maemo5 and MeeGo on Debian
The purpose of this project is to port the proprietary Nokia components of Maemo 5 to a Debian base system running on the Nokia N900 and future devices. It should be possible run both Maemo5 and standard Debian software on this platform natively and in the same environment. In the future, the project will package and integrate the MeeGo components and know-how to enable the installation of MeeGo applications.
 Why not MeeGo?
MeeGo is supposed to be a merger of Maemo 5 and Moblin and therefore the future of Maemo. While Maemo 5 is similar to Debian and reuses most of its tools and policies, it is still significantly different from Debian so that porting Debian packages is not always trivial. Installation of native Debian packages is in most cases impossible.
For many users, the similarity to Debian and the relative openness of Maemo 5 has been precisely the reason they have bought the Nokia N900. So far Nokia has not committed to porting Harmattan, the successor of Maemo 5, which is supposed to be MeeGo compatible, or the official MeeGo to the N900. Now, a few months after its public release, owners of the sophisticated, but expensive N900 have the impression that they are left with an abandoned OS and have little hope to be able to upgrade to its successors.
This projects aims to give N900 users immediate access to the Debian software pool and the prospect to be able to install MeeGo applications in the future. It also intends to try and convince Nokia to open-source as many applications and drivers for the N900 as possible in order to integrate them better into this project.
The commercial initiative of Intel and Nokia, called MeeGo, is supposed to be open-source and open for the community. However, important decisions have been made behind closed doors and are unlikely to change. One of those decisions is to switch from a base system that is similar to Debian, to an independent base that uses the RPM package manager and that is not required to be compatible with any of the major Linux distributions. MeeGo users and developers could therefore only use and rely on designated MeeGo applications and libraries, if they do not port third-party software to it themselves. MeeGo apparently only targets mainstream mobile applications, while this project aims to satisfy the needs of both mainstream and experts. This project is therefore not a fork or competitor to MeeGo but rather a project with a broader scope than MeeGo. The MeeGo software stack is just one part of this project.
 Advantages for users and developers
The integration of Debian, Maemo 5 and MeeGo in this project has the following advantages:
Users will have the freedom to install
- all Maemo 5 applications (incl. the non-free Nokia binaries), and improved free Nokia packages (which is not possible for standard Maemo5 firmware)
- future mobile-optimized MeeGo applications (RPM packages), and
- all packages from the huge Debian software pool, which is constantly maintained and updated (incl. security fixes) by the Debian community.
- novel mobile, Debian compatible applications written for this project
Only few packages will require modification to run on this platform (excluding complete GUI adapations). The main contribution of this project is to perform and maintain such modifications, and if possible, to send them upstream.
Developers of third-party apps could simply integrate all software packages (for example, libraries) that are available in the huge Debian pool, without the need to port and to maintain them themselves. If they are familiar with the mature Debian development tools and policies, there is no need to learn something new. They could also build and test the apps natively on their Debian desktop.
 The .deb vs. .rpm debate
Main article: DebForMeeGo
There are only subtle differences between the two package formats .deb and .rpm and their respective package managers. Many MeeGo supporters make a category error by confusing the underlying package format with the higher goal. The purpose of this project is not necessarily to have .deb packages and dpkg as a front end, but to be able to integrate existing Debian and Maemo work and know-how. Since both of them are based on dpkg, choosing the same format is required for retaining compatibility. To emphasize this point: if Maemo and Debian were using .rpm, this project would use it, too.
Also many people not familiar with packaging erroneously believe that packages could be simply converted using tools like alien. However, this only works for very simple packages with minimal dependencies. For packages with library dependencies and specific file system layout expectations this is not possible and requires manual packaging.
 Differences to Easy Debian
The Easy Debian project proves that it's possible to run a full Debian distribution within a chroot on the N900. However, the Debian applications run rather independently from Maemo5 and there are problems with hardware access (keyboard, sound etc.). This project tries to integrate Debian packages directly with Maemo5 so that both can access the hardware natively and share the same up to date libraries. Disc access would also be much faster than through a disc image.
 Implementation plan
Currently, project is in it's very early stage.
Here are several steps that we are going to do:
 Determine a place for the installation of the Debian base system on a N900
Ideally, we'd like to be able to boot and use Maemo5 and the new experimental system in parallel on the device in order to compare differences, and get access to more beta-testers which would not risk breaking their device. By default, N900 has a fast 256MB NAND flash and a slower 32G eMMC flash (/dev/mmcblk0 device), that is split into a 768k swap partition, a 2 Gb /home partition, and a 27GB vfat /home/MyDocs partition.
However, the rootfs is too small to store all packages, user data and addon-software. Maemo5 tries to solves this problem with problematic "optification", which is not compatible with standard Linux distributions. We should try to solve this problem in a more elegant way which is FHS compatible. The simplest solution is to keep the rootfs (or the largest part of it) not on NAND but on eMMC.
There are several possible solutions where to store the Debian base system and its rootfs:
- installation in a /home. pros: simple installation, no need for partitioning (unless repartitioned for larger /home), fast, cons: only one installation possible, limited to 2GB (unless repartitioned)
- installation in a chroot on /home. pros: simple installation, no need for partitioning (unless repartitioned for larger /home), fast, multiple chroots. cons: not useable as independent boot device? limited to 2GB (unless repartitioned)
- installation in a new partition or on SD card: pros: independent and isolated, could be USB exported, fast, less space constraints. cons: requires partitioning and setting up a file system, fixed size, only one simultaneous installation possible
- installation in a disk image. pros: isolated, prepared image could be downloaded, size up to 27GB in MyDocs could be USB exported, multiple chroots. cons: quite slow
 Repartitioning the flash
Most users of this project have a Debian background and would probably like to reserve more space for packages or POSIX compatible data storage than for a large partition with an outdated filesystem (vfat). The obvious solution is to repartition the flash. There are several typical scenarios:
- Swap /home and MyDocs partition to get a 2GB vfat MyDocs and a 27GB ext3 /home. No partition size need to be changed and the change could be done online.
- get rid of the MyDocs partition, setup a single 31GB ext3 partition, and replace MyDocs with loopback file(s) that could also be USB exported and have arbitrary size and filesystem. However, the loopback files may be significantly slower. ext3 partitions can be grown online.
- setup an arbitrary /home and MyDocs division of the space. This may require partitioning before any eMMC is mounted (/home cannot be unmounted) and may be much more dangerous. But it may be the least intrusive and visible solution for applications.
Solutions 1 and 2 require modifications to ke-recv, which hardcodes /dev/mmcblk0p1, upstart scripts (rcS-late) and possibly the USB export scripts to enable USB mass storage support. For the camera application the DCIM directory has to be created with proper permissions.
We should design and document a clean procedure, how to make /home/MyDocs partition smaller, and get a new free partition for Debian. This should be done such that all current content of /home/MyDocs is preserved, and device keeps booting and working normally. Once such a procedure is designed and debugged, it will be documented here.
 Determine minimal subset of Nokia's firmware to work with
It will be easier to work with smaller system. I think that complete Nokia's firmware is a bit large to start with. Better to find a smallest subset that is enough for communication functions (UI/phone/messaging) and work with that.
This subset is likely a set of Nokia's original .deb packages (from some particular firmware release), plus maybe some files that are not in any package [don't know if there are such].
It should be possible to unpack the debs in the subset into our free partition (perhaps in the way similar to debootstrap: first unpack, then run postinst scripts and hooks), add not-in-deb files if any (hook can do that), and then boot device into that.
Having device that dual-boots into original system and this minimal subset is a big milestone.
 Integrate minimal nokia system with Debian infrastructure
Next step is to understand the relation between our minimal system and the rest of the debian. There will likely be different sort of incompatibilities between minimal Nokia system and normal Debian: files provided by both Nokia and Debian packages, namespace collisions, incompatible packaging practices, and all other sort of problems. These should be determined and faced somehow, step-by-step.
At some point we should get system that is still functional as a phone, and that can install packages from Debian repositories.
 To be continued ...
Then we should integrate rest of Nokia apps, as well as Maemo and/or Meego apps, and also do numerous enhancements that definitly will be needed and possible.
All tasks within one phase can be done independently. Later phases require all tasks in previous phases to be done. You can assign ourselves by adding your nickname or email.
 Phase 0
- DONE: decide on the name for the project, register a domain, setup a homepage, and make it public. Some ideas for the name: Moebian, Debian Mobile, Debian/MeeGo, Maebian
 Phase 1
- DONE: set up mailing lists with public archive, http://garage.maemo.org/mailman/listinfo/moebian-devel
- DONE: set up bug/issue/task tracker and wiki, VCS, https://garage.maemo.org/projects/moebian/
- DONE: set up a repository for updated, but N900 specific free packages or rebuild Debian, Maemo and MeeGo packages, temporary location: http://maemory.com/moebian/
- DONE: write scripts to setup Maemo5 chroots or partitions which can be booted (bootmenu) or chrooted to. titan has written a script to symlink all necessary system in the rootfs from a chroot. The advantage over copying the rootfs are the higher speed of NAND,the automatic update by firmware upgrades and less disc usage.
- fix hanging startup-pin-query when booting from flash
- identify more shared directories in /usr where packages install their files. create them before symlinking
 Milestone 1
successfully dual-boot or chroot into the Maemo5 copy
 Phase 2
- identify non-free packages names in the firmware and repack the binaries with dpkg-repack
- set up or get access to a build system (OBS?)
- create a Maemo package in extras-devel which automatically setups a chroot or partition (incl. repartitioning)
- build a dependency graph for the non-free packages so that we know which packages could be broken by what library upgrade. Use debtree?
- modify dpkg-repack so that dependencies can be modified
- try to replace essential libraries (libc, libgcc, Gtk) and software step by step and check which packages would break
- for packages which break, keep the original dependency at another place and fix the rpaths with chrpath. Alternatively, create a sub-chroot which contains the minimal dependencies to run the application. Also ask Nokia to open-source the code, or rebuild the binary in a more compatible way.
- install essential Debian packages and disable all services that would run in the background or unnecessarily slow down the system (PAM) in order to save battery.
 Milestone 2
run the core Nokia binaries (phone,calendar etc) on a base system with essential libraries replaced by their Debian versions
 Phase 3
- adapt more Debian packages to mobile usage
- make sure Maemo5 applications can be installed or port more essential Maemo5 packages to the new base (e.g., pymaemo).
 Phase ?
- integrate MeeGo components, send fixes to MeeGo
 Related projects
- Debian Wiki
- MeeGo: Debian Packaging
- Mer dual-booting Mer
- Easy Debian thread
- Debian rebuild for Maemo5
- Debian for Eee PC
- Ubuntu ARM port and with new UI
- Debian for Linux phones
- Ubuntu Netbook Remix
- Debian on FreeRunner
- Ubuntu Mobile
 Proprietary Maemo components
- Why close packages?
- Openness report
- Free Maemo
- Licensing change requests and thread for license change requests
 Build systems and toolchains
 Packaging, tools
- This page was last modified on 5 September 2011, at 19:35.
- This page has been accessed 14,024 times.