Anonymous avatar Anonymous committed 3602576

Additional docs

Comments (0)

Files changed (5)

doc/package_maintenance.rst

+================================
+PACKAGE MAINTENANCE GUILDELINES 
+================================
+This guide explains how package maintenance is done for packages contributed to the `VectorLinux Buildbot 
+<http://vlcore.vectorlinux.com/buildbot>`_ system.  The following guidelines apply to all package maintenance performed to every 
+package in the database.
+
+General Guidelines
+==================
+* All package revisions **MUST** increase the ``BUILD`` value on the updated package.  This will help ``slapt-get`` detect the 
+available update on all end-user's machines.
+* All version bumps (increases) **MUST** reset the ``BUILD`` value back to 1
+* All SlackBuilds must be tested by the contributor before they are submitted.
+
+How to maintain a package
+-------------------------
+When performing maintenance on a package, always follow these guidelines to make sure your contributions are in line with the 
+rest of the development efforts.
+
+* Update your working copy of the slackbuilds repository.  If you do not have one, check out a new one.  The repository can be 
+accessed at `http://bitbucket.org/vlcore/vabs <http://vlcore.vectorlinux.com/buildbot>`_.  The build SlackBuilds can be found in 
+the var/vabs directory of that repo.
+* Navigate to the var/vabs directory in your local copy: ``cd vabs/var/vabs``
+* Locate the application(s) you want to maintain or update, and open the SlackBuild with your favorite text editor.
+* Make your changes to the build script and save it (with the same name).  Changes should include any changes in package version, 
+build number, URL to source tarball **direct download**, or other necessary build procedure changes.
+* Run the script to test it's basic functionality.
+* When you have verified that the script runs and does not return an error, then you commit your changes, and push them to the 
+online git repository.
+
+Typical maintenance example
+----------------------------
+A typical package maintenance procedure would be necessary when a new version of an application is released from upstream.  At 
+that time, the packager would need to do the following.
+
+* Find the SlackBuild in the repository that builds the application that was just released.
+* Edit the SlackBuild to update its ``VERSION`` value
+* Reset the ``BUILD`` value  back to 1 (with every version bump, the release should be reset back to 1)
+* Make sure the ``LINK`` value can download the new version of the source tarball.
+* Commit and push changes.
+
+FAQ
+===
+Q:  
+    If I have to test the SlackBuild myself, why can't I just upload package instead of the SlackBuild?
+
+A:  
+    Contributing a SlackBuild results in multiple packages for different architectures created from your SlackBuild.  Uploading a 
+package only contributes to **your** current arquitecture.
+
+ 
+
+

doc/repository_maintenance.rst

+==================================
+REPOSITORY MAINTENANCE GUILDELINES 
+==================================
+This guide explains how the maintenance of the official VectorLinux repositories is done when working with  packages contributed 
+to the `VectorLinux Buildbot <http://vlcore.vectorlinux.com/buildbot>`_ system.
+
+At the present time, there are no tools to automatically move the packages to the official repositories.  When a packager 
+contributes a package or package update, the buildbot will build as instructed, and place the resulting packages in 
+http://vlcore.vectorlinux/pkg/untested
+
+The repository maintainer will have to move the packages like they usually do now, with the exception that the repo maintainer 
+should test each package before moving it to the repositories to make sure the package works as expected.
+
+What you need to know:
+----------------------
+* The bot collects packages in http://vlcore.vectorlinux.com/pkg/untested
+* Source code for the packages can can be found at http://vlcore.vectorlinux.com/src/
+* You **MUST** delete the packages from the untested repository once the package has been moved to the official repositories.
+* You must trigger the scripts to update the metadata on the untested repository as well as the official repositories when you 
+perform maintenance.
+

doc/vlbuildbot.fixed.rst

-===================================================
- PACKAGING GUIDELINES FOR THE VECTORLINUX BUILDBOT
-===================================================
-
-Introduction:
-=============
-The packaging procedures for use with the VectorLinux Buildbot are a
-bit different, although the principles are still the same and some of
-the steps on the procedure remain unchanged.  In the past, one would
-normally generate a build script (SlackBuild in most cases), then one
-would get the source code for the application as well as a fitting
-slack-desc file.  When it was built, one would upload a complete
-source directory containing a tarball, description, and build script
-as well as the binary package itself (.txz as of VectorLinux 7.0).
-
-With the buildbot system, things change a little bit.  You still need
-to generate a script (See Buildscript Guidelines below), and you still
-need a description file.  However, the only thing you upload is the
-build script and any supporting files it needs (slack-desc, patches,
-etc).  See the guide for submitting a package below.
-
-
-Why use a buildbot?
-===================
-* 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, whitout 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 consistancy during the development of the distro by forcing
-  developers and contributors to re-use the existing tools and
-  resources as much as possible.
-  sure we re-use existing tools and resources as much as possible.
-* Allows us to see which packages are failing and why so we can
-  address the changes and get them fixed.
-
-
-Submitting a new package:
-=========================
-The following steps should be taken to submit a new package to the
-database.
-
- 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.
- 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  
-    https://bitbucket.org/VLCore/vabs
-
-
-SlackBuild Guidelines:
-======================
-**ALL** SlackBuilds (with very few exceptions approved by a buildbot
-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 list any and all dependencies required *to build the package*
-  in a variable named ``MAKEDEPENDS``.  This is an array separated by
-  a single space character.  See 'Handling Dependencies' below.
-* Must be tested by the contributer 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,
-  icons, .desktop files, etc.
-
-All of these apply to every single submission.  There will be special
-cases where an exception to the rules needs to be made.  In such
-cases, communication between the package maintainer and the buildbot
-maintainer will determine how it will be implemented.
-
-
-Handling Dependencies:
-======================
-The buildbot is equipped with a small tool to resolve any dependencies
-needed to build your package.  But you must list them in the
-``MAKEDEPENDS`` variable 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
-repository (https://bitbucket.org/VLCore/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`` variable 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
-packaged.
-
-**How to list your dependencies**
-
-Consider the following scenario.
-
-You are building package 'foo'.  But when you run the SlackBuild
-locally (for testing before submission), you find that the configure
-step needs 'libbar'.  You would do the following.
-
-* Edit your SlackBuild to add 'libbar' to your ``MAKEDEPENDS``.
-* Install libbar on your local system so you can continue to test the
-  SlackBuild.
-* Run the SlackBuild again.
-
-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
-your dependency too.
-
-
-THE LIFE OF A PACKAGE:
-----------------------
-The following explains how a package is created and how it ends up in
-the repositories.
-
-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.
-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
-   http://vlcore.vectorlinux.com/pkg/ 
-5. Once the package makes it to vlcore.vectorlinux.com, it is picked up by 
-   other tools for processing and sumbission to the official vectorlinux 
-   repositories.
-
-HOW THE BOT WORKS:
-------------------
-The Vectorlinux 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.
-
-The Master:
-===========
-The buildbot master is responsible for the following tasks:
-
-*  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
-   dev channel of events taking place.
-*  (currently disabled) Provide email notification of triggered
-   events.
-
-The Slave:
-==========
-The buildbot slave(s) are responsible for the following tasks:
-
-* 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 pacakage and source tree to the pool
-  location.
-

doc/vlbuildbot.original.rst

-===================================================
- PACKAGING GUIDELINES FOR THE VECTORLINUX BUILDBOT
-===================================================
-
-Introduction:
-=============
-The packaging procedures for use with the VectorLinux Buildbot are a
-bit different, although the principles are still the same and some of
-the steps on the procedure remain unchanged.  In the past, one would
-normally generate a build script (SlackBuild in most cases), then one
-would get the source code for the application as well as a fitting
-slack-desc file.  When it was built, one would upload a complete
-source directory containing a tarball, description, and build script
-as well as the binary package itself (.txz as of VectorLinux 7.0).
-
-With the buildbot system, things change a little bit.  You still need
-to generate a script (See Buildscript Guidelines below), and you still
-need a description file.  However, the only thing you upload is the
-build script and any supporting files it needs (slack-desc, patches,
-etc).  See the guide for submitting a package below.
-
-
-Why use a buildbot?:
-====================
-* 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, whitout 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 consistancy during the development of the distro by forcing
-  developers and contributors to re-use the existing tools and
-  resources as much as possible.
-  sure we re-use existing tools and resources as much as possible.
-* Allows us to see which packages are failing and why so we can
-  address the changes and get them fixed.
-
-
-Submitting a new package:
-=========================
-The following steps should be taken to submit a new package to the
-database.
-
-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 usually 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
-https://bitbucket.org/VLCore/vabs
-
-
-SlackBuild Guidelines:
-======================
-**ALL** SlackBuilds (with very few exceptions approved by a buildbot
-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 list any and all dependencies required *to build the package*
-  in a variable named ``MAKEDEPENDS``.  This is an array separated by
-  a single space character.  See 'Handling Dependencies' below.
-* Must be tested by the contributer 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,
-  icons, .desktop files, etc.
-
-All of these apply to every single submission.  There will be special
-cases where an exception to the rules needs to be made.  In such
-cases, communication between the package maintainer and the buildbot
-maintainer will determine how it will be implemented.
-
-
-Handling Dependencies:
-======================
-The buildbot is equipped with a small tool to resolve any dependencies
-needed to build your package.  But you must list them in the
-``MAKEDEPENDS`` variable 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
-repository (https://bitbucket.org/VLCore/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`` variable 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
-packaged.
-
-** How to list your dependencies **
-Consider the following scenario.
-
-You are building package 'foo'.  But when you run the SlackBuild
-locally (for testing before submission), you find that the configure
-step needs 'libbar'.  You would do the following.
-
-* Edit your SlackBuild to add 'libbar' to your ``MAKEDEPENDS``.
-* Install libbar on your local system so you can continue to test the
-  SlackBuild.
-* Run the SlackBuild again.
-
-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
-your dependency too.
-
-
-THE LIFE OF A PACKAGE:
-----------------------
-The following explains how a package is created and how it ends up in
-the repositories.
-
-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.
-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 http://vlcore.vectorlinux.com/pkg/ \
-5. Once the package makes it to vlcore.vectorlinux.com, it is picked
-up by other tools for processing and sumbission to the official
-vectorlinux repositories.
-
-HOW THE BOT WORKS:
-------------------
-The Vectorlinux 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.
-
-The Master:
-===========
-The buildbot master is responsible for the following tasks:
-
-*  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
-   dev channel of events taking place.
-*  (currently disabled) Provide email notification of triggered
-   events.
-
-The Slave:
-==========
-The buildbot slave(s) are responsible for the following tasks:
-
-* 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 pacakage and source tree to the pool
-  location.

doc/vlbuildbot.rst

+===================================================
+ PACKAGING GUIDELINES FOR THE VECTORLINUX BUILDBOT
+===================================================
+
+Introduction:
+=============
+The packaging procedures for use with the VectorLinux Buildbot are a
+bit different, although the principles are still the same and some of
+the steps on the procedure remain unchanged.  In the past, one would
+normally generate a build script (SlackBuild in most cases), then one
+would get the source code for the application as well as a fitting
+slack-desc file.  When it was built, one would upload a complete
+source directory containing a tarball, description, and build script
+as well as the binary package itself (.txz as of VectorLinux 7.0).
+
+With the buildbot system, things change a little bit.  You still need
+to generate a script (See Buildscript Guidelines below), and you still
+need a description file.  However, the only thing you upload is the
+build script and any supporting files it needs (slack-desc, patches,
+etc).  See the guide for submitting a package below.
+
+
+Why use a buildbot?
+===================
+* 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, whitout 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 consistancy during the development of the distro by forcing
+  developers and contributors to re-use the existing tools and
+  resources as much as possible.
+  sure we re-use existing tools and resources as much as possible.
+* Allows us to see which packages are failing and why so we can
+  address the changes and get them fixed.
+
+
+Submitting a new package:
+=========================
+The following steps should be taken to submit a new package to the
+database.
+
+ 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.
+ 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  
+    https://bitbucket.org/VLCore/vabs
+
+
+SlackBuild Guidelines:
+======================
+**ALL** SlackBuilds (with very few exceptions approved by a buildbot
+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 list any and all dependencies required *to build the package*
+  in a variable named ``MAKEDEPENDS``.  This is an array separated by
+  a single space character.  See 'Handling Dependencies' below.
+* Must be tested by the contributer 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,
+  icons, .desktop files, etc.
+
+All of these apply to every single submission.  There will be special
+cases where an exception to the rules needs to be made.  In such
+cases, communication between the package maintainer and the buildbot
+maintainer will determine how it will be implemented.
+
+
+Handling Dependencies:
+======================
+The buildbot is equipped with a small tool to resolve any dependencies
+needed to build your package.  But you must list them in the
+``MAKEDEPENDS`` variable 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
+repository (https://bitbucket.org/VLCore/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`` variable 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
+packaged.
+
+**How to list your dependencies**
+
+Consider the following scenario.
+
+You are building package 'foo'.  But when you run the SlackBuild
+locally (for testing before submission), you find that the configure
+step needs 'libbar'.  You would do the following.
+
+* Edit your SlackBuild to add 'libbar' to your ``MAKEDEPENDS``.
+* Install libbar on your local system so you can continue to test the
+  SlackBuild.
+* Run the SlackBuild again.
+
+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
+your dependency too.
+
+
+THE LIFE OF A PACKAGE:
+----------------------
+The following explains how a package is created and how it ends up in
+the repositories.
+
+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.
+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
+   http://vlcore.vectorlinux.com/pkg/ 
+5. Once the package makes it to vlcore.vectorlinux.com, it is picked up by 
+   other tools for processing and sumbission to the official vectorlinux 
+   repositories.
+
+HOW THE BOT WORKS:
+------------------
+The Vectorlinux 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.
+
+The Master:
+===========
+The buildbot master is responsible for the following tasks:
+
+*  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
+   dev channel of events taking place.
+*  (currently disabled) Provide email notification of triggered
+   events.
+
+The Slave:
+==========
+The buildbot slave(s) are responsible for the following tasks:
+
+* 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 pacakage and source tree to the pool
+  location.
+
Tip: Filter by directory path e.g. /media app.js to search for public/media/app.js.
Tip: Use camelCasing e.g. ProjME to search for ProjectModifiedEvent.java.
Tip: Filter by extension type e.g. /repo .js to search for all .js files in the /repo directory.
Tip: Separate your search with spaces e.g. /ssh pom.xml to search for src/ssh/pom.xml.
Tip: Use ↑ and ↓ arrow keys to navigate and return to view the file.
Tip: You can also navigate files with Ctrl+j (next) and Ctrl+k (previous) and view the file with Ctrl+o.
Tip: You can also navigate files with Alt+j (next) and Alt+k (previous) and view the file with Alt+o.