* Allows us to build packages for multiple architectures virtually
parallel to each other. This means that the x86_64 version of every
package in our repositories will be available at the same time the
- x86 package is ready, w
hitout the need for anyone to do any extra work.
+ x86 package is ready, witout the need for anyone to do any extra work.
* Makes package maintenance easier.
* Would allow us to release security fixes in a timely manner.
* Makes the job of the repo maintainer easier.
-* Enforces consist
ancy during the development of the distro by forcing
+* Enforces consistncy during the development of the distro by forcing
developers and contributors to re-use the existing tools and
resources as much as possible.
* Allows us to see which packages are failing and why so we can
1. Generate the build script with sbbuilder. (See Buildscript Guidelines below).
2. Get or write a slack-desc file for the application you are building. You
- can usally find them online. If they dont exist, you need to create one.
+ can usally find them online. If they dont exist, you need to create one.
3. Execute the script to make sure it builds on your box. Mainly, this will
make sure the LINK and build procedures are correct on the SlackBuild.
Make any corrections to the SlackBuild as necessary.
4. Submit your SlackBuild, slack-desc and any other supporting files
(patches, icons, .desktop files, etc) to the git repository at
maintainer) submitted for inclusion on the buildbot system
**MUST** meet the following requirements:
-* Must be genrated by sbbuilder
-* Must include a value in the ``LINK:`` variable
+* Must be generated by sbbuilder.
+* Must include a value in the ``LINK`` array.
* Must list any and all dependencies required *to build the package*
- in a
variable named ``MAKEDEPENDS``. This is an array separated by
+ in a named ``MAKEDEPENDS``. This is an array separated by
a single space character. See 'Handling Dependencies' below.
-* Must be tested by the contribut
er to make sure it is free of syntax
+* Must be tested by the contributr to make sure it is free of syntax
errors and to make sure it downloads its source package correctly.
* Must be accompanied by a slack-desc and any other files the
SlackBuild needs to run successfully. This includes any patches,
The buildbot is equipped with a small tool to resolve any dependencies
needed to build your package. But you must list them in the
var iable of your SlackBuild. To solve these, the bot
+``MAKEDEPENDS`` ar of your SlackBuild. To solve these, the bot
will first look in the official VectorLinux repositories. If a
dependency is not in the repositories, it will look in the source
s:// bitbucket.org/VLCore/vabs) to see if we have
+repository (http:///vabs) to see if we have
build scripts that will produce the package needed. If a dependency
is not found at either location, your build will fail immediately.
-**NOTE:** The ``MAKEDEPENDS``
var iable should only list dependencies
+**NOTE:** The ``MAKEDEPENDS`` ar should only list dependencies
needed **to build** your package, not to run it. Requiredbuilder will
list all the dependencies needed to run the application you just
-**How to list your dependencies**
+**How to list your dependencies**
Consider the following scenario.
* Run the SlackBuild again.
-Repeat those steps for every dependency you need to list for your
+Repeat those steps for every dependency you need to list for your
SlackBuild. If you need to depend on a package that is currently not
in the official repositories, you will have to submit buildscripts for
1. A contributor (packager) submits a buildscript to the git repository.
2. The buildbot master will detect the change on the git commit logs and
- instruc the build slaves to build the new package.
+ instruc the build slaves to build the new package.
3. The build slave receives notification from the master that a new package
needs to be built, and runs the script submitted by the contributor.
4. The build slave notifies the master of the build results. If the build
was successful, the binary package and source code are uploaded to
5. Once the package makes it to vlcore.vectorlinux.com, it is picked up by
- other tools for processing and su
mbission to the official vector linux
+ other tools for processing and subission to the official ectorinux
linux buildbot is a special configuration of the buildbot
+The Vectorinux buildbot is a special configuration of the buildbot
tool found at http://buildbot.net
It consists of at least 2 parts. One master, and at least one slave.
* Monitor the git source repository for changes.
* Assign tasks for each build slave as necessary.
* Collect results data and build logs from the build slaves.
-* Exposes build results and logs via a web ui
-* Provides the IRC bot as another way to force builds and notify the
+* Expose build results and logs via a web ui.
+* Provide an IRC bot as another way to force builds and notify the
dev channel of events taking place.
* (currently disabled) Provide email notification of triggered
* Receive instructions from the build master.
* Carry out the actual build process when instructed by the master.
* Relay build results and log files back to the master.
-* Upload the resulting binary pac
akage and source tree to the pool
+* Upload the resulting binary package and source tree to the pool