Mer/Documentation/Getting your package included - Revision history

amigadave: minor fix

2010-09-22T10:46:35Z

minor fix

← Older revision		Revision as of 10:46, 22 September 2010
Line 4:		Line 4:
	* Ideally test <code>dpkg-buildpackage -S -us -uc</code>, <code>dpkg-buildpackage -b -us -uc</code>, and <code>dpkg-buildpackage -B</code> (some packages may not build any arch-dep packages, so that's OK. Microdocument it on Jaiku.)		* Ideally test <code>dpkg-buildpackage -S -us -uc</code>, <code>dpkg-buildpackage -b -us -uc</code>, and <code>dpkg-buildpackage -B</code> (some packages may not build any arch-dep packages, so that's OK. Microdocument it on Jaiku.)
	* <code>bzr export ''source package name'' lp:~''yourusername''/m-r/''source package name''</code> (gives you a checked out version, without metadata)		* <code>bzr export ''source package name'' lp:~''yourusername''/m-r/''source package name''</code> (gives you a checked out version, without metadata)
-	* <code>cd ''<source package name>''</code>	+	* <code>cd ''source package name''</code>
	* <code>dpkg-buildpackage -S -us -uc</code>, to generate a source package		* <code>dpkg-buildpackage -S -us -uc</code>, to generate a source package
	* Upload the resulting source package (<code>.changes</code>, <code>.tar.gz</code>, possibly <code>*.diff.gz</code>) to your <code>~/incoming</code> on trac.tspre.org.		* Upload the resulting source package (<code>.changes</code>, <code>.tar.gz</code>, possibly <code>*.diff.gz</code>) to your <code>~/incoming</code> on trac.tspre.org.

amigadave: {{Mer}}

2010-09-22T10:45:55Z

← Older revision		Revision as of 10:45, 22 September 2010
Line 1:		Line 1:
		+	{{Mer}}
		+
	* Make sure it compiles after getting your build dependancies, <code>dpkg-buildpackage</code>.		* Make sure it compiles after getting your build dependancies, <code>dpkg-buildpackage</code>.
	* Ideally test <code>dpkg-buildpackage -S -us -uc</code>, <code>dpkg-buildpackage -b -us -uc</code>, and <code>dpkg-buildpackage -B</code> (some packages may not build any arch-dep packages, so that's OK. Microdocument it on Jaiku.)		* Ideally test <code>dpkg-buildpackage -S -us -uc</code>, <code>dpkg-buildpackage -b -us -uc</code>, and <code>dpkg-buildpackage -B</code> (some packages may not build any arch-dep packages, so that's OK. Microdocument it on Jaiku.)
-	* <code>bzr export ''<source package name>'' lp:~''yourusername''/m-r/''<source package name>''</code> (gives you a checked out version, without metadata)	+	* <code>bzr export ''source package name'' lp:~''yourusername''/m-r/''source package name''</code> (gives you a checked out version, without metadata)
	* <code>cd ''<source package name>''</code>		* <code>cd ''<source package name>''</code>
	* <code>dpkg-buildpackage -S -us -uc</code>, to generate a source package		* <code>dpkg-buildpackage -S -us -uc</code>, to generate a source package
Line 12:		Line 14:
	* Builder is at http://trac.tspre.org:8000		* Builder is at http://trac.tspre.org:8000
	* Follow instructions, and submit job.		* Follow instructions, and submit job.
-
-
-	~~[[Category:Mer]]~~

generalantilles: Cleanup, markup

2009-04-18T09:29:17Z

Cleanup, markup

← Older revision		Revision as of 09:29, 18 April 2009
Line 1:		Line 1:
-	~~== Getting~~ your package ~~included in~~ the ~~Repository ==~~	+	* Make sure it compiles after getting your build dependancies, <code>dpkg-buildpackage</code>.
		+	* Ideally test <code>dpkg-buildpackage -S -us -uc</code>, <code>dpkg-buildpackage -b -us -uc</code>, and <code>dpkg-buildpackage -B</code> (some packages may not build any arch-dep packages, so that's OK. Microdocument it on Jaiku.)
		+	* <code>bzr export ''<source package name>'' lp:~''yourusername''/m-r/''<source package name>''</code> (gives you a checked out version, without metadata)
		+	* <code>cd ''<source package name>''</code>
		+	* <code>dpkg-buildpackage -S -us -uc</code>, to generate a source package
		+	* Upload the resulting source package (<code>.changes</code>, <code>.tar.gz</code>, possibly <code>*.diff.gz</code>) to your <code>~/incoming</code> on trac.tspre.org.
		+	* <code>ssh ''yourlogin''@trac.tspre.org /import-new-packages</code>

-	* Make sure it compiles after getting your build dependancies, dpkg-buildpackage.	+	(This will add the source package to repository, and complain otherwise.)
-	* Ideally test both dpkg-buildpackage -S -us -uc, dpkg-buildpackage -b -us -uc, dpkg-buildpackage -B (some packages may not build any arch-dep packages, so that's ok. Microdocument it on Jaiku.)	+
-	* bzr export <source package name> lp:~yourusername/m-r/<source package name> (gives you a checked out version, without metadata)	+
-	* cd <source package name>	+
-	* dpkg-buildpackage -S -us -uc, to generate a source package	+
-	* Upload the resulting source package (.changes, .tar.gz, possibly *.diff.gz) to your ~/incoming on trac.tspre.org.	+
-	* ssh yourlogin@trac.tspre.org /import-new-packages	+
-		+
-	(This will add the source package to repository, and complain otherwise)	+

	* You need access to merbuilder & repository upload for the following, ask Stskeeps on Jaiku/IRC for this.		* You need access to merbuilder & repository upload for the following, ask Stskeeps on Jaiku/IRC for this.
	* Builder is at http://trac.tspre.org:8000		* Builder is at http://trac.tspre.org:8000
	* Follow instructions, and submit job.		* Follow instructions, and submit job.
-	[[Category:Mer~~\|Getting your package included~~]]	+
		+
		+	[[Category:Mer]]

jukey at 15:45, 15 April 2009

2009-04-15T15:45:20Z

← Older revision		Revision as of 15:45, 15 April 2009
Line 14:		Line 14:
	* Builder is at http://trac.tspre.org:8000		* Builder is at http://trac.tspre.org:8000
	* Follow instructions, and submit job.		* Follow instructions, and submit job.
		+	[[Category:Mer\|Getting your package included]]

stskeeps at 08:45, 10 April 2009

2009-04-10T08:45:41Z

← Older revision		Revision as of 08:45, 10 April 2009
Line 11:		Line 11:
	(This will add the source package to repository, and complain otherwise)		(This will add the source package to repository, and complain otherwise)

-	* You need access to merbuilder & repository upload for the following, ask Stskeeps on Jaiku/IRC for this. ~~Or refer on Jaiku to the source package and some may pick it up~~	+	* You need access to merbuilder & repository upload for the following, ask Stskeeps on Jaiku/IRC for this.
-	* ~~On http://jaiku.com/channel/merbuilder , write "build <SOURCE PACKAGE NAME>=<package version>"~~	+	* Builder is at http://trac.tspre.org:8000
-	* You can also save the builder some resources if it's an arch-indep package and do "build-x86 <SOURCE PACKAGE NAME>=<package version>"	+	* Follow instructions, and submit job.
-	* You can make a specific rebuild using build-armel-sb (build in scratchbox),	+
-	* Monitor progress at ~~same page (RSS:~~ http://~~jaiku~~.~~com/channel/merbuilder/feed/rss )~~	+
-	* An LP player notes that it has picked up a package for building at a certain builder	+
-	* A toast means it baked properly on this architecture. And is uploaded to repository.	+
-	* ~~A heart means it built properly on all architectures. And is uploaded to the repository~~	+
-	* A bomb means it failed to build on an architecture.	+
-	* A shopping wagon means it has noticed your build request and ~~queued it.~~	+
-	* A straightjacket means that it failed to build on Scratchbox and needed to be built natively. Note this in [[Mer/Documentation/Straightjacket _Packages\|Straightjacket packages]] when this happens. means there's a bug in SDK.)	+

stskeeps at 00:40, 22 January 2009

2009-01-22T00:40:25Z

← Older revision		Revision as of 00:40, 22 January 2009
Line 21:		Line 21:
	* A bomb means it failed to build on an architecture.		* A bomb means it failed to build on an architecture.
	* A shopping wagon means it has noticed your build request and queued it.		* A shopping wagon means it has noticed your build request and queued it.
-	* A straightjacket means that it failed to build on Scratchbox and needed to be built natively. Note this in "Straightjacket packages" when this happens. means there's a bug in SDK.)	+	* A straightjacket means that it failed to build on Scratchbox and needed to be built natively. Note this in [[Mer/Documentation/Straightjacket _Packages\|Straightjacket packages]] when this happens. means there's a bug in SDK.)

stskeeps: New page: == Getting your package included in the Repository == * Make sure it compiles after getting your build dependancies, dpkg-buildpackage. * Ideally test both dpkg-buildpackage -S -us -uc, ...

2009-01-22T00:39:33Z

New page: == Getting your package included in the Repository == * Make sure it compiles after getting your build dependancies, dpkg-buildpackage. * Ideally test both dpkg-buildpackage -S -us -uc, ...

New page

== Getting your package included in the Repository ==

* Make sure it compiles after getting your build dependancies, dpkg-buildpackage.
* Ideally test both dpkg-buildpackage -S -us -uc, dpkg-buildpackage -b -us -uc, dpkg-buildpackage -B (some packages may not build any arch-dep packages, so that's ok. Microdocument it on Jaiku.)
* bzr export <source package name> lp:~yourusername/m-r/<source package name> (gives you a checked out version, without metadata)
* cd <source package name>
* dpkg-buildpackage -S -us -uc, to generate a source package
* Upload the resulting source package (*.changes, *.tar.gz, possibly *.diff.gz) to your ~/incoming on trac.tspre.org.
* ssh yourlogin@trac.tspre.org /import-new-packages

(This will add the source package to repository, and complain otherwise)

* You need access to merbuilder & repository upload for the following, ask Stskeeps on Jaiku/IRC for this. Or refer on Jaiku to the source package and some may pick it up
* On http://jaiku.com/channel/merbuilder , write "build <SOURCE PACKAGE NAME>=<package version>"
* You can also save the builder some resources if it's an arch-indep package and do "build-x86 <SOURCE PACKAGE NAME>=<package version>"
* You can make a specific rebuild using build-armel-sb (build in scratchbox),
* Monitor progress at same page (RSS: http://jaiku.com/channel/merbuilder/feed/rss )
* An LP player notes that it has picked up a package for building at a certain builder
* A toast means it baked properly on this architecture. And is uploaded to repository.
* A heart means it built properly on all architectures. And is uploaded to the repository
* A bomb means it failed to build on an architecture.
* A shopping wagon means it has noticed your build request and queued it.
* A straightjacket means that it failed to build on Scratchbox and needed to be built natively. Note this in "Straightjacket packages" when this happens. means there's a bug in SDK.)