Mer/Build

Revision as of 13:34, 26 April 2009

This page documents how to use the openSUSE Build Service with Mer.

1 Installing OBS tools locally
- 1.1 Local osc setup
2 Getting Mer and Packages
3 Building a package locally
4 To create a new package
- 4.1 Standalone Project
5 Co-existing with Scratchbox
- 5.1 Linking
6 OBS Project structure and promotion

Installing OBS tools locally

Assuming a Debian or Ubuntu development box locally:

To get the OBS tools repository add one of the following lines:

deb http://download.opensuse.org/repositories/openSUSE:/Tools/xUbuntu_8.10/ /

deb http://download.opensuse.org/repositories/openSUSE:/Tools/Debian_5.0/ /

to a new file called:

/etc/apt/sources.list.d/obs.list

Then

apt-get update
apt-get install osc build qemu

(may have to use aptitude to install the right qemu - it's version 0.9.2svn6094-1 as of 12 April 2009)

(may have to ask on #mer to install the right build - it's version 02009.03.08.6740S as of 12 April 2009 http://download.opensuse.org/repositories/openSUSE:/Tools:/Devel/Debian_Lenny/all/ )

(Note, 64 bit systems will need to download manually using wget from http://download.opensuse.org/repositories/openSUSE:/Tools/Debian_5.0/amd64/ as the openSUSE repo may have some packaging issues)

run

osc

and enter novell.com username/passwd when prompted (note these are stored in cleartext in the config file). Note this isn't supposed to do anything (it prints out the osc help) but it stores your name/pw for future use.

Go and login.

Make sure you click the "let me build packages" button.

There is a link to 'Home Project' on the left, follow this and enter a description.

Local osc setup

Create a local build path.

mkdir -p ~/maemo/Mer/obs

All references below with (yourusername) should of course be replaced with the login name on your local machine.

You can now check some settings in your ~/.oscrc :

This is the OBS builder we're using... maybe we'll use a maemo.org instance one day?

apiurl = https://api.opensuse.org

This specifies where all the cached binary packages are held to create a chroot build environment. Around 300MB.

packagecachedir = /home/(yourusername)/maemo/Mer/obs/.pkg-cache/

This specifies the default location where a complete chroot build will be installed. This will be a minimal OS install - allow 400MB minimum. Replace (yourusername) with your current login name

build-root = /home/(yourusername)/maemo/Mer/obs/build-%(repo)s-%(arch)s

The next section is credentials for access control to the builder.

[https://api.opensuse.org]
user = <username>
pass = <password>

Getting Mer and Packages

Create and cd to a directory to act as the root for the OBS/Mer repository. You'll need space to have a copy of various Mer source packages - around 650MB

cd ~/maemo/Mer/obs

Note that you need to use "home:lbt:Mer" in the osc commands (until Mer is made a main project).

Now osc ls home:lbt:Mer:0.11 will list all the packages.

If you want the entire Mer project then you can run osc co home:lbt:Mer:0.11 to checkout the entire project as tar.gz and .dsc files, or to get just one package osc co home:lbt:Mer:0.11/<package>

Building a package locally

(Note: if you have Scratchbox then you may need to see the section below on temporarily disabling it)

To work on a package go to the right location and get the source.

osc co home:lbt:Mer:0.11/maemopad
cd home:lbt:Mer:0.11/maemopad         # ie <osc project dir>
osc up
osc build --clean standard armv5el   maemopad*.dsc         # ie <project.dsc>

This will download all the (arm) debs to create a local chroot - it'll take a while the first time but will use a cache after that.

Eventually it will prompt you for the root passwd in order to chroot etc. After that the builder will su to the "abuild" user (uid:gid 399:399) and build the code.

If you like you can work inside qemu chroot:

chroot /home/(yourusername)/maemo/Mer/obs/build-standard-armv5el su abuild                # this is the dir you set in .oscrc as the build-root.
cd /usr/src/packages/BUILD

at this point:

./configure
make

etc... all work using the binfmt_misc redirection.

To create a new package

These osc commands are done in your own area - use your username after "home:"

Run

osc meta pkg -e home:<username> <package>

This pops up an editor where you can edit the name/description and then save. This will tell the OBS server about the package.

To get a local (empty) copy run

osc up

This makes a package directory so now you can:

cp package.tar.gz package.dsc homt:lbt/package
cd package

Then add them to version control

osc addremove

and upload them

osc commit

To watch what is going on:

osc buildlog <target>

osc buildlog Debian_5.0 i586

This does something like a "tail -f" of the Xen builder.

Standalone Project

On the web, create the (sub)project maemopad.

In the repository section add a repository and from advanced select the Mer project: home:lbt:Mer:011

Now we need to pick build targets:

 https://build.opensuse.org/project/add_target_simple?project=home:lbt

And pick one or two ( I picked Debian Lenny and Ubuntu 8.10) This creates a standalone project and builds against another project

Goto your obs base (eg /scratch3/maemo/Mer/obs) and checkout the project:

 osc co home:lbt:maemopad

Now create the package metadata:

 osc meta pkg -e home:lbt:maemopad maemopad

and get a local copy (empty still):

 cd home:lbt:maemopad/
 osc up

the 'osc up' created a directory so go into it and get the source:

  cd maemopad/
 wget http://repository.maemo.org/pool/maemo4.1.2/free/m/maemopad/maemopad_2.4.dsc
 wget http://repository.maemo.org/pool/maemo4.1.2/free/m/maemopad/maemopad_2.4.tar.gz

Use the cheap'n'cheerful 'register all file adds and removes with vc'-command:

 osc addremove

and then commit the source which uploads it to the OBS

 osc commit -m "added source"

This will trigger a rebuild and you can access the logs.

Co-existing with Scratchbox

If you use the OBS local build facility and the scratchbox-1 local builder then you need to know how to teach the two emulators how to co-exist.

Both OBS and Scratchbox use | binfmt_misc to cause the kernel to invoke (in our case) qemu when it comes across an armel binary.

To disable qemu and enable sbox

 echo 0 > /proc/sys/fs/binfmt_misc/arm
 echo 0 > /proc/sys/fs/binfmt_misc/armeb
 echo 1 > /proc/sys/fs/binfmt_misc/sbox-arm
 echo 1 > /proc/sys/fs/binfmt_misc/sbox-armeb

To disable sbox and enable arm

 echo 1 > /proc/sys/fs/binfmt_misc/arm
 echo 1 > /proc/sys/fs/binfmt_misc/armeb
 echo 0 > /proc/sys/fs/binfmt_misc/sbox-arm
 echo 0 > /proc/sys/fs/binfmt_misc/sbox-armeb

Don't do this whilst a build is in progress!

Linking

To link to a source create a _link file containing:

 <link project="linked project name" package="linked package name">

optionally:

 <patches>
   <apply name="name of the first patch" />
 </patches>

Sadly these patches apply to the files in the source; so this means you need to apply the diff to the maemo-ised diff file.

OBS Project structure and promotion

The Mer projects on OBS look like this:

Maemo:Mer:Stable
Maemo:Mer:Stable:HW:Beagle
Maemo:Mer:Stable:HW:N8x0

This means all devices will have the main 'Stable' repository and an appropriate HW repository.

The development area is expanded slightly:

Maemo:Mer:Devel:Apps
Maemo:Mer:Devel:Base
Maemo:Mer:Devel:MaemoCommon
Maemo:Mer:Devel:MaemoCommon:L10n
Maemo:Mer:Devel:UI
Maemo:Mer:Devel:HW:Beagle:Devel
Maemo:Mer:Devel:HW:N8x0:Devel

Packages in each of these Devel subproject areas can be hacked on and then, when they're kinda working they are consolidated into the :Devel area (which is used as a build target for the :Devel:* subprojects)

Maemo:Mer:Devel
Maemo:Mer:Devel:HW:N8x0
Maemo:Mer:Devel:HW:Beagle

Packages are placed in :Testing with the intention of including them in the next release subject to QA and bug fixes

 Maemo:Mer:Testing
 Maemo:Mer:Testing:HW:Beagle
 Maemo:Mer:Testing:HW:N8x0

Once :Testing is ready a release of all packages to a numbered version is made:

 Maemo:Mer:0.13
 Maemo:Mer:0.13:HW:Beagle
 Maemo:Mer:0.13:HW:N8x0

Note that the :HW promotion process is slightly different:

Maemo:Mer:Devel:HW:N8x0:Devel -> Maemo:Mer:Devel:HW:N8x0 -> Maemo:Mer:Testing:HW:N8x0 -> Maemo:Mer:Stable:HW:N8x0

Maemo:Mer:Devel:Apps

Mer Applications and Applets

Packaged applications included in Mer

advanced-backlight
advanced-power
advanced-power-monitor
blueman
extras-repository
finefm
galculator
homeip
maemopadplus
midori
mirage
mplayer
osso-xterm
vte
personal-launch
wpeditor

Maemo:Mer:Devel:Base

Mer system base

Packages which deals with the underlying functionality of Mer that isn't directly presented to the user, such as booting, networking, logging, rescue, generic X support

apt
alsa-plugins
circular-syslogd
core-pattern
evkey
base64
hal
network-manager
cnetworkmanager
pulseaudio
sudo
tslib
upstart
utelnetd
waitdbus
xserver-xorg-input-evdev
xresponse-visualize
xkeyboard-config
xf86-input-tslib

Maemo:Mer:Devel:MaemoCommon

Maemo and Hildon Packages

These packages should ideally be unmodified from the upstream Maemo and hildon projects

alarmd
clinkc
certman
clipboard-manager
dbus-glib
epeg
alarmd
gail
gconf2
glib2.0
gnome-vfs-filechooser-backend
gstreamer0.10-ffmpeg-osso
gtk+2.0
gtkhtml
hildon-application-manager
hildon-control-panel
hildon-input-method
hildon-input-method-framework
icd2-osso-ic-dev
hildon-thumbnail
hildon-theme-tools
hildon-theme-cacher
hildon-games-wrapper
libconbtui
libconic
libdb1
libhildon
libhildonfm
libhildonhelp
libhildonmime
libosso
maemo-launcher
maemopad
mce-dev
osso-af-settings
osso-af-utils
osso-gnome-vfs2
osso-gnomevfs2-extra
osso-gwconnect
osso-gwobex
osso-systemui-dbus-dev
osso-uri-l10n-public
sapwood
screenshot-tool
tablet-browser-interface

Maemo:Mer:Devel:MaemoCommon:L10n

L10n shared with Maemo

Packages with translation strings which we share with Maemo

marketing-release-public
gtk20-l10n
hildon-application-manager-l10n-public
hildon-common-strings-l10n-public
hildon-control-panel-l10n-public
hildon-fm-l10n-public
hildon-libs-l10n-public
ke-recv-l10n-public
maemo-af-desktop-l10n-public
osso-applet-tasknavigator-l10n-public

Maemo:Mer:Devel:UI

Mer User interface & Behaviour

Packages which deals with presenting the Hildon Desktop and the Mer UI, and generic functionality across platforms

zenity
powerlaunch
ubuntulooks
first-boot-wizard
hildon-desktop
hildon-desktop-env
hildon-desktop-layout-alpha
hildon-home-weather
hildon-initscripts
hildon-icons
hildon-theme-layout-mer
hildon-theme-liberty-mer
hildon-theme-selector
hildon-cpa-dummy
liberty-sounds-ui
marquee-plugins
matchbox-window-manager
libmatchbox1
network-manager-applet
hildon-input-method-plugins-example
hildon-plugins-settings
pygtk
python-conic
python-hildon
python-hildondesktop
python-osso
load-applet

Maemo:Mer:Devel:HW:Beagle:Devel

Development area for Beagle specific code

Maemo:Mer:Devel:HW:N8x0:Devel

Development area for N8x0 specific code

dsme-tools
kernel-diablo
kernel-diablo-modules-fbcon
cx3110x-module
cx3110x-module-src
cx3110x-umac-module
n810-slideout-kbd-xmodmap
mer-omapfb-splash
mer-rescue-menu
nit-bootmenu-compat
nit-kernel-compat
nokia-n8x0-firmware
nokia-tablets-pointercal
omap-fb-console
omap-fb-tools
x11proto-xsp
libxsp
usbnet-emergency-telnetd

Retrieved from "http://wiki.maemo.org/Mer/Build"

Category: Mer

@@ Line 185: / Line 185: @@
 Sadly these patches apply to the files in the source; so this means you need to apply the diff to the maemo-ised diff file.
-== Scenarios ==
-In the following, Mer environment is defined as the sum of packages with Ubuntu packages, with Mer repository overlaid on top, not what is built in a 'Mer' project.
-. A lone developer sits down and decides to create a project. He assigns a package name to this and his name as maintainer. He builds it locally for Mer and tries it out as he develops it through dpkg-buildpackage'ing (or osc build?) locally and testing his package. He finishes his release, and dpkg-buildpackage -S -us -uc, generating a .dsc and tar.gz. He would like to build his package for the Mer environment, the X86 and ARMEL targets. He doesn't want to maintain a local toolchain beyond his x86 VMDK, so he submits the build job to the OpenSUSE Build Service (which he has registered with). He can then observe the build progress and he can subsequently download resulting .deb(s) and .changes file to upload to the Mer (Extras) repository.
-. Variation on the first but with OpenSUSE Build Service located on maemo.org
-. A company developer sits down and creates a project. He takes this source from a company source code repository, assigns a package name and setting his name as maintainer. He builds it locally for Mer and tries it out as he develops it through dpkg-buildpackage'ing (or osc build?) locally and testing his package. He generates a release (generating a .dsc and tar.gz) and he would like to target Mer environment, and Ubuntu, the X86 and ARMEL targets. He would like to build locally on his VMDK, as the source code should never leave the company premises. He can then watch the build progress and subsequently gets the resulting .deb(s) and .changes, to be able to upload. He should not need a login at all to build locally
-. Same as 3, but is okay to need a login, it is assumed there is a OBS Server appliance with build workers in the company.
-== Naming and Deltas ==
-Mer is derived from Ubuntu with the intial releases being based on Jaunty.
-This means that in general you get Ubuntu packages.
-In OBS terms, Mer builds against Ubuntu Jaunty (ie build-dependencies are met from Jaunty)
-However, Maemo provides some excellent libraries, UIs and applications that Mer will use.
-So Mer is "linked to" the OBS Maemo project (which just contains an upload of the Maemo source)
-mer=orig+delta(deb)+delta(maemo)+delta(mer)      mer!=orig+delta(deb+maemo+mer)
 == OBS Project structure and promotion ==

Personal tools

Navigation

Views