Building packages with sbdmock - Revision history

imported_>amigadave: wikify slightly

2011-02-04T13:05:25Z

wikify slightly

imported_>lizardo at 17:00, 23 December 2009

2009-12-23T17:00:28Z

← Older revision		Revision as of 17:00, 23 December 2009
Line 43:		Line 43:

	'''sbdmock/bin/sbdmock --help'''		'''sbdmock/bin/sbdmock --help'''

	~~== Alternative method ==~~

	Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:		Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:

imported_>lizardo: /* Alternative method */

2009-12-23T16:59:24Z

Alternative method

← Older revision		Revision as of 16:59, 23 December 2009
Line 44:		Line 44:
	'''sbdmock/bin/sbdmock --help'''		'''sbdmock/bin/sbdmock --help'''

	= Alternative method =		== Alternative method ==

	Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:		Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:

imported_>lizardo: /* Alternative method */

2009-12-23T16:30:29Z

Alternative method

← Older revision		Revision as of 16:30, 23 December 2009
Line 48:		Line 48:
	Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:		Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:

	1. Install ''git-core'', ''python-setuptools'' and ''dpkg-dev'':		<ol>
	sudo aptitude install git-core python-setuptools dpkg-dev		<li>Install ''git-core'', ''python-setuptools'' and ''dpkg-dev'':</li>
	2. Download latest minideblib tarball from http://pypi.python.org/pypi/minideblib		'''sudo aptitude install git-core python-setuptools dpkg-dev
	3. Unpack it and build the .deb package:		<li>Download latest minideblib tarball from http://pypi.python.org/pypi/minideblib</li>
	tar -xvzf minideblib-*.tar.gz		<li>Unpack it and build the .deb package:</li>
	cd minideblib-*/		'''tar -xvzf minideblib-*.tar.gz
	dpkg-buildpackage -us -uc -rfakeroot		'''cd minideblib-*/
	4. Download sbdmock sources:		'''dpkg-buildpackage -us -uc -rfakeroot
	git clone git://github.com/kad/sbdmock.git sbdmock		<li>Download sbdmock sources:</li>
	5. Build sbdmock .deb package:		'''git clone git://github.com/kad/sbdmock.git sbdmock
	dpkg-buildpackage -us -uc -rfakeroot -i.git -I.git		<li>Build sbdmock .deb package:</li>
	6. Install the built .deb packages:		'''dpkg-buildpackage -us -uc -rfakeroot -i.git -I.git
	dpkg -i python-minideblib.deb sbdmock.deb		<li>Install the built .deb packages:</li>
	7. Copy the config files to your sbdmock config directory:		'''dpkg -i python-minideblib.deb sbdmock.deb
	mkdir ~/.sbdmock/		<li>Copy the config files to your sbdmock config directory:</li>
	cp /usr/share/doc/sbdmock/examples/*.cfg ~/.sbdmock/		'''mkdir ~/.sbdmock/
	8. Test the sbdmock installation:		'''cp /usr/share/doc/sbdmock/examples/*.cfg ~/.sbdmock/
	sbdmock --help		<li>Test the sbdmock installation:</li>
			'''sbdmock --help
			</ol>

	= sbdmock documentation =		= sbdmock documentation =

imported_>lizardo: /* Getting sbdmock */

2009-12-23T16:26:42Z

Getting sbdmock

← Older revision		Revision as of 16:26, 23 December 2009
Line 43:		Line 43:

	'''sbdmock/bin/sbdmock --help'''		'''sbdmock/bin/sbdmock --help'''

			= Alternative method =

			Alternatively, if you are on a Debian based system, you might prefer to build and install Debian packages instead:

			1. Install ''git-core'', ''python-setuptools'' and ''dpkg-dev'':
			sudo aptitude install git-core python-setuptools dpkg-dev
			2. Download latest minideblib tarball from http://pypi.python.org/pypi/minideblib
			3. Unpack it and build the .deb package:
			tar -xvzf minideblib-*.tar.gz
			cd minideblib-*/
			dpkg-buildpackage -us -uc -rfakeroot
			4. Download sbdmock sources:
			git clone git://github.com/kad/sbdmock.git sbdmock
			5. Build sbdmock .deb package:
			dpkg-buildpackage -us -uc -rfakeroot -i.git -I.git
			6. Install the built .deb packages:
			dpkg -i python-minideblib.deb sbdmock.deb
			7. Copy the config files to your sbdmock config directory:
			mkdir ~/.sbdmock/
			cp /usr/share/doc/sbdmock/examples/*.cfg ~/.sbdmock/
			8. Test the sbdmock installation:
			sbdmock --help

	= sbdmock documentation =		= sbdmock documentation =

imported_>gcobb: Tidy introduction further

2009-07-16T22:04:59Z

Tidy introduction further

← Older revision		Revision as of 22:04, 16 July 2009
Line 1:		Line 1:
	~~'''''Note: this page is work in progress documenting my experiments with sbdmock''''' [[User:gcobb\|gcobb]] 21:59, 15 July 2009 (UTC)~~

	''sbdmock'' builds binary "deb" packages from source, it is part of Maemo's automatic build chain.		''sbdmock'' builds binary "deb" packages from source, it is part of Maemo's automatic build chain.

	''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).		''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 [~~http://~~mud-builder.garage.maemo~~.org/ ~~mud-builder] can be used, which automatically calls ''dpkg-buildpackage'').~~		The sbdmock home page is: http://bifh.org/wiki/sbdmock

	~~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 ''Build-Depends~~:~~'' line)~~.		The sbdmock git source tree can be accessed at: http://github.com/kad/sbdmock/tree/master

	~~Of course, if the build in~~ sbdmock ~~fails you will need to debug it. sbdmock can be used for that as well.~~		= Why use sbdmock? =

	The ~~sbdmock home page~~ is: http://~~bifh~~.org/~~wiki/sbdmock~~		Before submitting a package 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 [http://mud-builder.garage.maemo.org/ mud-builder] 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 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).

	~~The~~ sbdmock ~~git source tree~~ can be ~~accessed at: http://github~~.~~com/kad/sbdmock/tree/master~~		''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.

	= Getting sbdmock =		= Getting sbdmock =
Line 142:		Line 142:

	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]]

imported_>jeremiah: Added a introductory line, rearranged a couple paragraphs for clarity.

2009-07-16T08:25:33Z

Added a introductory line, rearranged a couple paragraphs for clarity.

← Older revision		Revision as of 08:25, 16 July 2009
Line 1:		Line 1:
	'''''Note: this page is work in progress documenting my experiments with sbdmock''''' [[User:gcobb\|gcobb]] 21:59, 15 July 2009 (UTC)		'''''Note: this page is work in progress documenting my experiments with sbdmock''''' [[User:gcobb\|gcobb]] 21:59, 15 July 2009 (UTC)

			''sbdmock'' builds binary "deb" packages from source, it is part of Maemo's automatic build chain.

			''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).

	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 [http://mud-builder.garage.maemo.org/ mud-builder] can be used, which automatically calls ''dpkg-buildpackage'').		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 [http://mud-builder.garage.maemo.org/ mud-builder] 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 ''Build-Depends:'' line).		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 ''Build-Depends:'' 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.		Of course, if the build in sbdmock fails you will need to debug it. sbdmock can be used for that as well.

imported_>gcobb: /* Test build */

2009-07-15T22:01:12Z

Test build

← Older revision		Revision as of 22:01, 15 July 2009
Line 125:		Line 125:
	''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 ~~builds using~~ the ''-extras'' configurations.		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.

	= Debugging build problems =		= Debugging build problems =

imported_>gcobb: Explain that -extras configs are not used

2009-07-15T21:59:34Z

Explain that -extras configs are not used

← Older revision		Revision as of 21:59, 15 July 2009
Line 1:		Line 1:
	'''''Note: this page is work in progress documenting my experiments with sbdmock''''' --[[User:gcobb\|gcobb]] 18:17, 12 July 2009 (UTC)		'''''Note: this page is work in progress documenting my experiments with sbdmock''''' [[User:gcobb\|gcobb]] 21:59, 15 July 2009 (UTC)

	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 [http://mud-builder.garage.maemo.org/ mud-builder] can be used, which automatically calls ''dpkg-buildpackage'').		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 [http://mud-builder.garage.maemo.org/ mud-builder] can be used, which automatically calls ''dpkg-buildpackage'').
Line 112:		Line 112:
	\| maemo-sdk-rootstrap_4.0_i386.tgz		\| maemo-sdk-rootstrap_4.0_i386.tgz
	\|}		\|}

			'''Note:''' the ''extras'' configurations are not used by the autobuilder: all building is done in extras-devel.

	= Test build =		= Test build =
Line 123:		Line 125:
	''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 ~~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''.		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 builds using the ''-extras'' configurations.

	= Debugging build problems =		= Debugging build problems =

imported_>gcobb: Minor fixes

2009-07-12T18:26:20Z

Minor fixes

← Older revision		Revision as of 18:26, 12 July 2009
Line 1:		Line 1:
	'''''Note: this page is work in progress documenting my experiments with sbdmock''''' --[[User:gcobb\|gcobb]] 18:17, 12 July 2009 (UTC)		'''''Note: this page is work in progress documenting my experiments with sbdmock''''' --[[User:gcobb\|gcobb]] 18:17, 12 July 2009 (UTC)

	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'').		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 [http://mud-builder.garage.maemo.org/ mud-builder] 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).		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 ''Build-Depends:'' 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).		''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).