Executable programs like OpenOffice or Firefox start out as code. That code is translated into a language the computer can understand. The process of translating code written by humans into code a computer understands is called compiling. After the code is compiled we make sure it works as well if not better than the original. We, in the GoOSe Linux Project, have set out to compile all of the code necessary for a complete enterprise grade operating system in an automated fashion, document the process and stay as transparent and open as possible.
Technical Background
We are downloading srpms that contain the source for a program (hence the preceding "s" in srpm) hashing the source, then compiling the srpm into an rpm. We are using skein to grab the srpms prepare them and pass them on to koji. Koji will take an srpm and compile it.
Collecting the source and compiling it takes time and effort. Automating the process is ideal.
After compliation verification is necessary. We make sure that all binaries have not degraded in quality.
Technical Details
Skein will download an srpm from a given repository and place it into its own repository in our project. Then it will create a hash of the source, store it in a "sources" file along with the tarred source in a web directory called a lookaside cache.
Koji is then told to look at the lookaside cache, grab the source, hash the source, compare it against the hash in the lookaside cache, then try to compile it for the specified architectures. Koji runs from a main computer that can then manage a collection of build computers. These build comptuers are of as many desired architectures. Currently we are only building for x86 and x86_64 architectures, we could potentially build for ppc, arm, sparc, etc.
What we are currently doing is building the build environment so we can build packages we compile. Once the build environment is built we can build whatever packages we want.
We can poll the upstream for new/changed srpms which will then start the process over again. Automating the process will allow us to stay current and free resources for fixing issues and other non-automatable processes.
Once all the necessary packages have been compiled quality assurance can commence. We compare our binaries against those of our upstream to verify they are as good as if not better than theirs. Quality Assurance is one way you can help