Mer/Build
(changed scratch3) |
|||
Line 43: | Line 43: | ||
This specifies where all the cached binary packages are held to create a chroot build environment. Around 300Mb. | This specifies where all the cached binary packages are held to create a chroot build environment. Around 300Mb. | ||
- | packagecachedir = / | + | packagecachedir = /home/lbt/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. | This specifies the default location where a complete chroot build will be installed. This will be a minimal OS install - allow 400Mb minimum. | ||
- | build-root = / | + | build-root = /home/lbt/maemo/Mer/obs/build-%(repo)s-%(arch)s |
The next section is credentials for access control to the builder. | The next section is credentials for access control to the builder. | ||
Line 58: | Line 58: | ||
You'll need space to have a copy of various Mer source packages - around 650Mb | You'll need space to have a copy of various Mer source packages - around 650Mb | ||
- | cd / | + | cd /home/lbt/maemo/Mer/obs |
Now: | Now: | ||
Line 80: | Line 80: | ||
If you like you can work inside qemu chroot: | If you like you can work inside qemu chroot: | ||
- | chroot / | + | chroot /home/lbt/maemo/Mer/obs/build-standard-armv5el su abuild |
cd /usr/src/packages/BUILD | cd /usr/src/packages/BUILD | ||
Revision as of 17:13, 12 April 2009
Contents |
Buiding Mer.
This page documents how to use OBS, the Open Build Service, with Mer.
https://build.opensuse.org
Installing OBS tools locally
You'll need an | account with Novell
Assuming a debian or ubuntu development box locally:
Add osc repo to apt.
deb http://download.opensuse.org/repositories/openSUSE:/Tools/xUbuntu_8.10/ /
or
deb http://download.opensuse.org/repositories/openSUSE:/Tools/Debian_5.0/ /
to
/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 Apr 2009)
(may have to ask on #mer to install the right build - it's version 02009.03.08.6740S as of 12 Apr 2009)
run
osc
and enter novell.com username/passwd when prompted (note these are stored in cleartext in the config file...FYI)
Go and login to https://build.opensuse.org
Make sure you click the "let me build packages" button.
There is a link to 'Home Project' on the left I think. Follow this and enter a description.
Local osc Setup
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/lbt/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.
build-root = /home/lbt/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 /home/lbt/maemo/Mer/obs
Now:
osc ls home:lbt:Mer:0.11
will list all the packages
osc co home:lbt:Mer:0.11
will 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
To work on a package go to the right location and get the source:
cd <osc project dir> osc up osc build --clean standard armv5el <project.dsc>
This 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/lbt/maemo/Mer/obs/build-standard-armv5el su abuild cd /usr/src/packages/BUILD
at this point: ./configure make
etc... all work using the binfmt_misc redirection.
To create a new package
Run
osc meta pkg -e home:lbt:Mer:0.11 <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>
so
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
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.
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.
1. 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.
2. Variation on the first but with OpenSUSE Build Service located on maemo.org
3. 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
4. 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)