Editing Building packages with sbdmock

Warning: You are not logged in. Your IP address will be recorded in this page's edit history.
The edit can be undone. Please check the comparison below to verify that this is what you want to do, and then save the changes below to finish undoing the edit.
Latest revision Your text
Line 1: Line 1:
-
''sbdmock'' builds binary "deb" packages from source, it is part of Maemo's automatic build chain.
+
'''''Note: this page is work in progress documenting my experiments with sbdmock'''''  --[[User:gcobb|gcobb]] 18:17, 12 July 2009 (UTC)
-
''sbdmock'' is a tool which provides a clean scratchbox environment, allowing you to test that your package can build in that environment before submitting it to the autobuilder. It can either be used manually, or it can be used as part of an automatic script (for example, I use for my nightly builds of GPE, OpenSync and Xsisusb).
+
Before submitting packages to the autobuilder, it is important to test that it will build.  The first step of that is to use ''dpkg-buildpackage'' in the scratchbox environment to create the packages (or a tool like [[MUD]] can be used, which automatically calls ''dpkg-buildpackage'').
 +
 
 +
However, just because a package builds in your normal scratchbox development environment is no guarantee that it will build in the autobuilder.  The main reason is that the autobuilder starts with no packages installed and only installs the packages defined in your package control file (using the ''BuildDepends:'' line).
 +
 
 +
''sbdmock'' is a tool which provides a clean scratchbox environment, allowing you to test that your package can build in that environment before submitting it to the autobuilder. It can either be used manually, or it can be used as part of an automatic script (for example, I intend to use it as part of my nightly builds of GPE).
 +
 
 +
Of course, if the build in sbdmock fails you will need to debug it.  sbdmock can be used for that as well.
The sbdmock home page is: http://bifh.org/wiki/sbdmock
The sbdmock home page is: http://bifh.org/wiki/sbdmock
Line 7: Line 13:
The sbdmock git source tree can be accessed at: http://github.com/kad/sbdmock/tree/master
The sbdmock git source tree can be accessed at: http://github.com/kad/sbdmock/tree/master
-
== Why use sbdmock? ==
+
= Getting sbdmock =
-
Before submitting a package to the autobuilder, it is important to test that it will buildThe first step of that is to use ''dpkg-buildpackage'' in the scratchbox environment to create the packages (or a tool like [http://mud-builder.garage.maemo.org/ mud-builder] can be used, which automatically calls ''dpkg-buildpackage'').
+
This is the procedure I used, using Debian squeezePackages for sbdmock may be available for your platform, however I wanted to use the latest development version and, as I expected to make changes to it, I did not want to install it into system directories.
-
However, just because a package builds in your normal scratchbox development environment is no guarantee that it will build in the autobuilder. The most common problem is that the autobuilder starts with no packages installed and only installs the packages defined in your package control file (using the ''Build-Depends:'' line).
+
1. Install Debian packages for ''git-core'', ''python-pip'', ''python-setuptools'' and ''python-virtualenv'' using:
-
''sbdmock'' allows you to test your build in a clean scratchbox target, just like the autobuilder uses.  Of course, if the build in sbdmock fails you will need to debug it.  sbdmock can be used for that as well.
+
'''sudo aptitude install git-core python-pip python-setuptools python-virtualenv'''
-
== Getting sbdmock ==
+
2. Create the python virtual environment:
-
This is the procedure I used, using Debian squeeze. Packages for sbdmock may be available for your platform, however I wanted to use the latest development version and, as I expected to make changes to it, I did not want to install it into system directories.
+
  '''virtualenv sbdmock'''
-
<ol>
+
3. Install minideblib, which is a prerequisite for using sbdmock:
-
<li>
+
-
Install Debian packages for ''git-core'', ''python-pip'', ''python-setuptools'' and ''python-virtualenv'' using:<pre>sudo aptitude install git-core python-pip python-setuptools python-virtualenv</pre>
+
-
</li>
+
-
<li>
+
-
Create the Python virtual environment:<pre>virtualenv sbdmock</pre>
+
-
</li>
+
-
<li>
+
-
Install minideblib, which is a prerequisite for using sbdmock:<pre>pip install -E sbdmock minideblib</pre>
+
-
</li>
+
-
<li>
+
-
Install sbdmock from the git repository:<pre>pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock</pre>
+
-
</li>
+
-
<li>
+
-
Copy the config files to your sbdmock config directory:
+
-
<pre>
+
-
mkdir ~/.sbdmock/
+
-
cp sbdmock/src/sbdmock/etc/*.cfg ~/.sbdmock/
+
-
</pre>
+
-
</li>
+
-
<li>
+
-
Test the sbdmock installation:<pre>sbdmock/bin/sbdmock --help</pre>
+
-
</li>
+
-
</ol>
+
-
Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:
+
'''pip install -E sbdmock minideblib'''
-
<ol>
+
4. Install sbdmock from the git repository:
-
<li>
+
 
-
Install ''git-core'', ''python-setuptools'' and ''dpkg-dev'':<pre>sudo aptitude install git-core python-setuptools dpkg-dev</pre>
+
'''pip install -E sbdmock -e git://github.com/kad/sbdmock.git#egg=sbdmock'''
-
</li>
+
 
-
<li>
+
5. Copy the config files to your sbdmock config directory:
-
Download latest minideblib tarball from http://pypi.python.org/pypi/minideblib
+
 
-
</li>
+
'''mkdir ~/.sbdmock/'''
-
<li>
+
'''cp sbdmock/src/sbdmock/etc/*.cfg ~/.sbdmock/'''
-
Unpack it and build the .deb package:
+
 
-
<pre>
+
6. Test the sbdmock installation:
-
tar -xvzf minideblib-*.tar.gz
+
 
-
cd minideblib-*/
+
'''sbdmock/bin/sbdmock --help'''
-
dpkg-buildpackage -us -uc -rfakeroot
+
-
</pre>
+
-
</li>
+
-
<li>
+
-
Download sbdmock sources:<pre>git clone git://github.com/kad/sbdmock.git sbdmock</pre>
+
-
</li>
+
-
<li>
+
-
Build sbdmock .deb package:<pre>dpkg-buildpackage -us -uc -rfakeroot -i.git -I.git</pre>
+
-
</li>
+
-
<li>
+
-
Install the built .deb packages:<pre>dpkg -i python-minideblib*.deb sbdmock*.deb</pre>
+
-
</li>
+
-
<li>
+
-
Copy the config files to your sbdmock config directory:
+
-
<pre>
+
-
mkdir ~/.sbdmock/
+
-
cp /usr/share/doc/sbdmock/examples/*.cfg ~/.sbdmock/
+
-
</pre>
+
-
</li>
+
-
<li>
+
-
Test the sbdmock installation:<pre>sbdmock --help</pre>
+
-
</li>
+
-
</ol>
+
-
== sbdmock documentation ==
+
= sbdmock documentation =
There is no documentation.  ''sbdmock --help'' gives:
There is no documentation.  ''sbdmock --help'' gives:
Line 115: Line 75:
</pre>
</pre>
-
== sbdmock configuration ==
+
= sbdmock configuration =
The most important part of the configuration is to put the rootstraps where sbdmock can find them.   
The most important part of the configuration is to put the rootstraps where sbdmock can find them.   
-
The rootstrap file names are specified in the configuration files (for example the standard chinook configuration file specifies ''maemo-sdk-rootstrap_4.0_armel.tgz'' as the rootstrap file name). Be aware that the rootstrap file names are relative to your scratchbox home directory. So, you have three options:
+
The rootstrap file names are specified in the configuration files (for example the standard chinook configuration file specifies ''maemo-sdk-rootstrap_4.0_armel.tgz'' as the rootstrap file name). Be aware that the rootstrap file names are relative to your scratchbox home directory. So, you have three options:
-
# Put the rootstrap files in your scratchbox home directory.  This is easiest and means no changes to the configuration files. However, depending on how you installed the SDK, they are almost certainly not in that directory at the moment.
+
1) Put the rootstrap files in your scratchbox home directory.  This is easiest and means no changes to the configuration files. However, depending on how you installed the SDK, they are almost certainly not in that directory at the moment.
-
# Put a softlink in the scratchbox home directory by logging in to Scratchbox and using something like:<pre>ln -s /some/directory/maemo-sdk-rootstrap_4.0_armel.tgz</pre>Note that this directory has to be accessible from within the Scratchbox environment, of course.
+
 
-
# Edit the configuration file to change the location.  The configuration file is in the <code>~/.sbdmock</code> directory and the line to change is the one which defines ''<nowiki>config_opts['rootstrap']</nowiki>''.  Again, the file has to be accessible from within the scratchbox environment.
+
2) Put a softlink in the scratchbox home directory by logging in to scratchbox'' and using something like:
 +
 
 +
'''ln -s /some/directory/maemo-sdk-rootstrap_4.0_armel.tgz'''
 +
 
 +
Note that this directory has be be accessible from within the scratchbox environment, of course.
 +
 
 +
3) Edit the configuration file to change the location.  The configuration file is in the ''~/.sbdmock'' directory and the line to change is the one which defines ''<nowiki>config_opts['rootstrap']</nowiki>''.  Again, the file has to be accessible from within the scratchbox environment.
Currently the following config files are shipped with sbdmock, although others may be added soon:
Currently the following config files are shipped with sbdmock, although others may be added soon:
-
{| class="wikitable"
+
{| class="wikitable" border="1"
! Configuration name !! SDK version !! Architecture !! Repository !! Rootstrap
! Configuration name !! SDK version !! Architecture !! Repository !! Rootstrap
|-
|-
Line 147: Line 113:
|}
|}
-
'''Note:''' the ''extras'' configurations are not used by the autobuilder: all building is done in extras-devel.
+
= Test build =
-
 
+
-
== Test build ==
+
To test the package defined in ''something.dsc'' will build using the chinook autobuilder use the following command:
To test the package defined in ''something.dsc'' will build using the chinook autobuilder use the following command:
-
  sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel -u ''something.dsc''
+
  '''sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel -u ''something.dsc'''''
This command must be issued from '''outside''' the scratchbox environment.
This command must be issued from '''outside''' the scratchbox environment.
Line 159: Line 123:
''sbdmock'' displays a message at the end of the build saying where the results (including logs) can be found.  That filespec is designed to be used from outside the scratchbox environment.  From inside the scratchbox environment the results are in ''<nowiki>~/maemo-chinook-armel-extras-devel/results</nowiki>''.
''sbdmock'' displays a message at the end of the build saying where the results (including logs) can be found.  That filespec is designed to be used from outside the scratchbox environment.  From inside the scratchbox environment the results are in ''<nowiki>~/maemo-chinook-armel-extras-devel/results</nowiki>''.
-
Once the ''-armel-extras-devel'' build is working, it is worth testing ''-i386-extras-devel'', which the autobuilder will build automatically unless your package defines that it is only for armel. Note that the autobuilder never uses the ''-extras'' configurations.
+
Once the ''-armel-extras-devel'' build is working, it is worth testing the other configurations: ''-i386-extras-devel'' (which the autobuilder will build automatically unless your package defines that it is only for armel), ''-armel-extras'' (so that you know the build will work if/when the package is promoted to extras) and ''-i386-extras''.
-
== Debugging build problems ==
+
= Debugging build problems =
The test builds described above use the ''sbdmock -u'' option.  This option causes sbdmock to create a completely new scratchbox target, with a unique name, run the build and delete the target again.  This is ideal for automatic builds and test builds but it is not useful when you want to debug a failing build.  In that case, you would like the scratchbox target to remain around so that you can select it and do debugging to see why your build failed, and fix it.
The test builds described above use the ''sbdmock -u'' option.  This option causes sbdmock to create a completely new scratchbox target, with a unique name, run the build and delete the target again.  This is ideal for automatic builds and test builds but it is not useful when you want to debug a failing build.  In that case, you would like the scratchbox target to remain around so that you can select it and do debugging to see why your build failed, and fix it.
Line 169: Line 133:
For example:
For example:
-
  sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel --sbtarget TEST_40_ARMEL ''something.dsc''
+
  '''sbdmock/bin/sbdmock -r maemo-chinook-armel-extras-devel --sbtarget TEST_40_ARMEL ''something.dsc'''''
'''Note:''' currently sbdmock does not actually recreate the target completely, so it is important that you specify a target which has the correct compiler, devkit and CPU transparency settings for the configuration you are using.  In other words, use a target which was set up for the correct version of the SDK and the correct architecture.
'''Note:''' currently sbdmock does not actually recreate the target completely, so it is important that you specify a target which has the correct compiler, devkit and CPU transparency settings for the configuration you are using.  In other words, use a target which was set up for the correct version of the SDK and the correct architecture.
If the build fails you can go into scratchbox, select the target (if necessary) and debug the problem.  You can then use ''dpkg-buildpackage'' to recreate the package files and re-try the build in ''sbdmock''.
If the build fails you can go into scratchbox, select the target (if necessary) and debug the problem.  You can then use ''dpkg-buildpackage'' to recreate the package files and re-try the build in ''sbdmock''.
-
 
-
== Example ==
 
-
 
-
'''Todo:''' create a worked example showing how to debug and fix a missing build dependency.
 
-
 
-
'''''Note: this page is work in progress documenting my experiments with sbdmock'''''  -- [[User:gcobb|gcobb]] 22:04, 16 July 2009 (UTC)
 
-
 
[[Category:Development]]
[[Category:Development]]

Learn more about Contributing to the wiki.


Please note that all contributions to maemo.org wiki may be edited, altered, or removed by other contributors. If you do not want your writing to be edited mercilessly, then do not submit it here.
You are also promising us that you wrote this yourself, or copied it from a public domain or similar free resource (see maemo.org wiki:Copyrights for details). Do not submit copyrighted work without permission!


Cancel | Editing help (opens in new window)