Task:Maemo OBS

Contents

[edit] Goals

This project enables the following:

  • Provide a single, community OBS that includes Harmattan, Fremantle and Diablo as targets to faciliate the development of applications that work on all platforms.
  • To collaborate with Mer/Nemo to share the costs of maintaining and operating the community OBS.

[edit] Weekly meetings

We are currently having weekly meetings on Mondays, 15:00 UTC. We will be using the maemo-developers mailing list for communications.

Meeting minutes can be found here.

[edit] Issues

[edit] Build dependencies

Maemo SDK ships what is called a rootstrap with many packages preinstalled. Developers usually do not explicitly mention those packages in their build dependencies because they're already preinstalled.

OBS doesn't accept rootstraps. Each builder process starts with an empty virtual machine, and from there a fixed set of packages is installed onto it.

Therefore, the packages that do not explicitly list the in-rootstrap packages in their build-dependencies fail to build.

[edit] Solutions to consider

  1. Manually go through all build failures and add the missing build-dependencies to the packages. Hard to contact all the package maintainers.
  2. Manually go through all build failures and add the missing build-dependencies to the fixed list of packages that are preinstalled when the VM starts. Each package on this list adds to the build time of all packages...
  3. Investigate the use of an actual rootstrap (maybe with SB2 it is possible?)

[edit] Scratchboxisms

A scratchboxism happens when a developer assumes something that is only true when running under Scratchbox(1). It might be a special environment variable, special directory, the behavior of certain commands, the fact that is actually x86, or the use of a custom Scratchbox devkit.

Many packages have scratchboxisms. The exact number is yet to be determined. Hopefully, not large.

[edit] Solutions to consider

  1. SB2 might help here.
  2. Manually fix the packages. The hard way. Most build problems are trivial, but even then this might require quite some time.
  3. ... Emulate those Scratchboxisms in some other way?

[edit] Current progress

[edit] April 23 2012

X-Fade agreed to import the Fremantle 1.3 SDK packages to OBS, as well as the current Fremantle extras-testing. This should give us updated estimates on how large the "problems" are

Additionally, we agreed that we should look for more information on the use of Scratchbox2 on OBS.

[edit] May 22 2012

[1]

The imported Fremantle 1.3 SDK packages are not yet built. Some issues have already been found (such as the presence of x86 binaries in some official SDK armel packages). Even with all qt-based packages failing because of the previous issue, the number of failing packages did not grow to unmanageable proportions.


Additionally, we have extra documentation regarding the use of SB2: [2].

The idea of the build process using SB2 is 1) the builder creates a new virtual machine, 2) installs the base Fremantle X86 packages to it, 3) installs Scratchbox2 and the arm crosscompiler, 4) boots the VM, 5) installs some more packages, 6) configures the SB2 target and installs base packages to it, 6 ) enters SB2 and starts building.

Therefore, the first detected requirement is that we need to provide the following Fremantle X86 debian packages:

  1. Scratchbox2
  2. CodeSourcery 2009q3

javispedro will be playing with this.

[edit] May 29 2012

xfade: I've imported qt4-dev with armel binaries into the PR1.3 repo. This fixed building Qt apps for Fremantle

Currently trying to build qemu dynamically linked for PR1.3, starting out with the qemu-kvm version that was uploaded to extras-devel. This failed building a few times on OBS because the vm ran out of memory. Trying again :)