Mer/Build

(→Getting Mer and Packages)
(Undo revision 50502 by 94.23.1.28 (Talk) due to vandalism)
 
(52 intermediate revisions not shown)
Line 1: Line 1:
-
This page documents how to use the [http://build.opensuse.org openSUSE Build Service] with Mer.
+
{{Mer}}
-
== Installing OBS tools locally ==
+
This section documents how to use the [http://build.opensuse.org openSUSE Build Service] with Mer. More on the openSUSE Buildservice [http://en.opensuse.org/Build_Service here].
-
You'll need an [https://secure-www.novell.com/selfreg/jsp/createOpenSuseAccount.jsp?target=http://www.opensuse.org account with Novell]
+
A simple way to think of OBS is as a version control system for source tarballs and .dsc files and whenever you commit a tarball the build farm compiles it for you.
-
Assuming a Debian or Ubuntu development box locally:
+
Over and above this OBS provides a local tool called osc that lets you do clean builds not only for your own OS and architecture but also for other distros and even other architectures (armel).
-
To get the OBS tools repository add one of the following lines:
+
==Getting Started==
-
deb http://download.opensuse.org/repositories/openSUSE:/Tools/xUbuntu_8.10/ /
+
-
or
+
-
deb http://download.opensuse.org/repositories/openSUSE:/Tools/Debian_5.0/ /
+
-
to a new file called:
+
Approaching OBS can look overwhelming... but it is perfectly possible to get an existing package built for Mer just using a web browser.
-
/etc/apt/sources.list.d/obs.list
+
-
Then
+
The first thing to do is to [[/Install OBS|install OBS]]. This will provide access to the tools and source used to build Mer.
-
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)
+
Then you should become familiar with building an application using OBS but outside the Mer repository. This is explained in detail in [[/Application Building|Application Building]] which takes you through an example application.
-
(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)
+
==Mer Internals==
-
run
+
When you are comfortable building your own applications for Mer then you can look at the [[Mer/Packages|Mer Packages]] and start helping to improve Mer itself.
-
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 [https://build.opensuse.org login].
+
There are [[/Processes|processes]] used to manage the Mer packages which may include [[/UsingGitorious|Using Gitorious]].
-
Make sure you click the "let me build packages" button.
+
The OBS [[/Cross Build|cross build]] page describes how the OBS has been accelerated.
-
There is a link to 'Home Project' on the left, follow this and enter a description.
+
== OBS Build Farm ==
-
=== Local osc setup ===
+
http://wiki.maemo.org/Mer/Documentation/Build/Common_Problems
-
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.
+
== QEMU armel image ==
-
You can now check some settings in your ~/.oscrc :
+
An Ubuntu armel image for QEMU is available from here:<br>
 +
http://gitorious.org/mer-toggles/qemu-armel-image (login: qemu/qemu)
 +
<br>
 +
Based on these instructions:<br>
 +
https://wiki.ubuntu.com/ARM/RootfsFromScratch<br>
-
This is the OBS builder we're using... maybe we'll use a maemo.org instance one day?
+
This is NOT a Mer development image like Mer VMDK is.
-
apiurl = https://api.opensuse.org
+
-
This specifies where all the cached binary packages are held to create a chroot build environment. Around 300MB.
+
== Mer Source ==
-
packagecachedir = /home/(yourusername)/maemo/Mer/obs/.pkg-cache/
+
Currently you cannot <code>apt-get source</code> for Mer.
-
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
+
Our approach requires you to get a Novell account and is similar to the one in HHGTTG:
-
build-root = /home/(yourusername)/maemo/Mer/obs/build-%(repo)s-%(arch)s
+
-
The next section is credentials for access control to the builder.
+
<blockquote>
-
<nowiki>[https://api.opensuse.org]</nowiki>
+
"`...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.'<br>
-
user = <username>
+
`But the plans were on display...'<br>
-
pass = <password>
+
`On display? I eventually had to go down to the cellar to find them.'<br>
 +
`That's the display department.'<br>
 +
`With a torch.'<br>
 +
`Ah, well the lights had probably gone.'<br>
 +
`So had the stairs.'<br>
 +
`But look you found the notice didn't you?'<br>
 +
`Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".'"
 +
</blockquote>
 +
<br>
 +
But slightly simpler...
-
== Getting Mer and Packages ==
+
Nb... the fix is trivial and simply requires you to modify the GPL licensed OBS system to publish debian style source distros ... patches accepted.
-
 
+
-
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 <code>osc ls home:lbt:Mer:0.11</code> will list all the packages.
+
-
 
+
-
If you want the ''entire'' Mer project then you can run <code>osc co home:lbt:Mer:0.11</code> to checkout the entire project as tar.gz and .dsc files, or to get just one package <code>osc co home:lbt:Mer:0.11/''<package>''</code>
+
-
 
+
-
== 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/lbt/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>
+
-
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 ==
+
-
 
+
-
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 [http://git.kernel.org/gitweb.cgi?p=linux/kernel/git/torvalds/linux-2.6.git;a=blob;f=Documentation/binfmt_misc.txt;hb=HEAD | 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)
+
-
 
+
-
[[Category:Mer|Build]]
+

Latest revision as of 12:03, 9 February 2013

Image:Mer infobox icon.png
 Mer is back : Please visit http://www.merproject.org to learn more about this news.


This section documents how to use the openSUSE Build Service with Mer. More on the openSUSE Buildservice here.

A simple way to think of OBS is as a version control system for source tarballs and .dsc files and whenever you commit a tarball the build farm compiles it for you.

Over and above this OBS provides a local tool called osc that lets you do clean builds not only for your own OS and architecture but also for other distros and even other architectures (armel).

Contents

[edit] Getting Started

Approaching OBS can look overwhelming... but it is perfectly possible to get an existing package built for Mer just using a web browser.

The first thing to do is to install OBS. This will provide access to the tools and source used to build Mer.

Then you should become familiar with building an application using OBS but outside the Mer repository. This is explained in detail in Application Building which takes you through an example application.


[edit] Mer Internals

When you are comfortable building your own applications for Mer then you can look at the Mer Packages and start helping to improve Mer itself.

There are processes used to manage the Mer packages which may include Using Gitorious.

The OBS cross build page describes how the OBS has been accelerated.

[edit] OBS Build Farm

http://wiki.maemo.org/Mer/Documentation/Build/Common_Problems


[edit] QEMU armel image

An Ubuntu armel image for QEMU is available from here:
http://gitorious.org/mer-toggles/qemu-armel-image (login: qemu/qemu)
Based on these instructions:
https://wiki.ubuntu.com/ARM/RootfsFromScratch

This is NOT a Mer development image like Mer VMDK is.

[edit] Mer Source

Currently you cannot apt-get source for Mer.

Our approach requires you to get a Novell account and is similar to the one in HHGTTG:

"`...You hadn't exactly gone out of your way to call attention to them had you? I mean like actually telling anyone or anything.'
`But the plans were on display...'
`On display? I eventually had to go down to the cellar to find them.'
`That's the display department.'
`With a torch.'
`Ah, well the lights had probably gone.'
`So had the stairs.'
`But look you found the notice didn't you?'
`Yes,' said Arthur, `yes I did. It was on display in the bottom of a locked filing cabinet stuck in a disused lavatory with a sign on the door saying "Beware of The Leopard".'"


But slightly simpler...

Nb... the fix is trivial and simply requires you to modify the GPL licensed OBS system to publish debian style source distros ... patches accepted.

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