CVS usage
SME Server core and contribs code is stored in CVS, this is a system to maintain version history and change management for program code.
On top of that a build system (plague) is layered to build packages in the RPM format used by yum.
The following is a cheat sheet that was started by User:Cactus here User:Cactus:CVS:Cheat_Sheet but was locked so I copied the contents here to allow it to be updated where needed.
Repositories
There are two repositories hosting code for SME Server:
- SME Server - holding the source code for the SME Server core
- SME Contribs - holdint the source code for contribs (add-ons) for SME Server
Both repositories are organized by the package name under which they appear in the software installer in the server-manager (or yum).
SME Server repository
The SME Server repository holds the SME Server core source code. Everybody can have a look at the content of the repository, but not every one is to allowed to make changes to the code. More on helping development can be found [].
Browsing the source code
There is a nice web based interface through which you can browse the development of SME Server core packages and you can find it here.
SME Contribs repository
The SME Contribs repository holds the SME Server contribs source code. Everybody can have a look at the content of the repository, but not every one is to allowed to make changes to the code. The code in this repository is not linked to SME Server as such, most of it is written by experienced SME Server users, some of it by the core development team. If you want to develop a package that can be an addition to SME Server you can apply for an account for this repository and develop your contrib.
Browsing the source code
There is a nice web based interface through which you can browse the development of SME Server contribs and you can find it here.
Workflow
The basic workflow is to first setup your development environment this is described in Package Modification. After that you need to get a copy of the source of a package by checking out the source. Than you can make your modifications by making a copy with a suffix (patchname) and make your modification to the original. You can refer to this page Rpm_build_example_using_cvs/mock to see many examples of mock/cvs usage After that we first need to test what we did, therefore we need to make a local build
make local
and install and test the created package:
sudo -u root yum localinstall /path/to/packagename
If everything is successfully tested we need to create a tag in the CVS system:
make tag
And instruct the build system to build the package:
make build
Development stages/actions
Check out
To get a local copy of a package we need to retrieve the source from the repository, this is called a check out. To check out a package from the SME Contribs repository take a look at Package_Modification. To be able to work on your code in the SME Server CVS repository you need an account on SourceForge. If you do not have an account at CVS, retrieving is performed as an anonymous user and changes cannot be saved.
Registered Users
- To retrieve a package or a full tree as a registered user, cd into a work directory and issue following commands:
- for smeserver
cvs -z3 -d:ext:smeserver.cvs.sourceforge.net:/cvsroot/smeserver co -P packagename [individual package] cvs -z3 -d:ext:smeserver.cvs.sourceforge.net:/cvsroot/smeserver co -P rpms [full tree]
- for smecontribs
cvs -z3 -d:ext:smeserver.cvs.sourceforge.net:/cvsroot/smecontribs co -P packagename [individual package] cvs -z3 -d:ext:smeserver.cvs.sourceforge.net:/cvsroot/smecontribs co -P rpms [full tree]
Anonymous users
- To retrieve a package or a full tree as an anonymous user, cd into a work directory and issue following commands:
- for smeserver
cvs -z3 -d:pserver:anonymous@smeserver.cvs.sourceforge.net:/cvsroot/smeserver checkout -P packagename [individual package] cvs -z3 -d:pserver:anonymous@smeserver.cvs.sourceforge.net:/cvsroot/smeserver co -P rpms [full tree]
- for smecontribs
cvs -z3 -d:pserver:anonymous@smeserver.cvs.sourceforge.net:/cvsroot/smecontribs checkout -P packagename [individual package] cvs -z3 -d:pserver:anonymous@smeserver.cvs.sourceforge.net:/cvsroot/smecontribs co -P rpms [full tree]
Retrieving the latest version
If you already once checked out the source of a certain package you can update your local copy with the following command:
cvs update -dPA
if you wish to find the last known exact version as that of CVS. you must delete the whole folder or file in question and after running the command 'cvs checkout'
cvs checkout smeserver-vacation
or that
cvs checkout smeserver-vacation/contribs8
or you can also
cvs checkout smeserver-vacation/contribs8/smeserver-vacation-1.0-locale-2013-07-15.patch
Check in or committing
To upload your source code into the repository (check in) you need to have a user account on the SourceForge system that is hosting the SME Server core and SME Server contribs repositories. Check in is quite simple
cvs commit -m 'message'
Adding/removing files
Since files under source control are not aware of the local file system we need to add and remove them with special commands:
To remove a file from source control:
cvs remove <file>
To add a file to source control:
cvs add <file>
Prepare a working copy
To prepare a working copy you can use
make prep
This command will download the latest source archive, extract it and apply all patches listed in the spec file.
Erasing your changes
To erase changes not committed to the repository you can issue
make clean
This command will remove all SRPMS and clear out the source directory in which you made modifications. It will give you a clear start as if you just checked out the latest version of the package from the repository.
Tagging
A tag is a mark in the source tree to document a certain stage of the development, usually a release version. To check the current tag number we can issue the following command:
cvs status -v *.spec
The output could look something like this:
File: e-smith-apache.spec Status: Up-to-date
Working revision: 1.3
Repository revision: 1.3 /cvsroot/smeserver/rpms/e-smith-apache/sme7/e-smith-apache.spec,v
Sticky Tag: (none)
Sticky Date: (none)
Sticky Options: -ko
Existing Tags:
e-smith-apache-1_2_0-15_el4_sme (revision: 1.2)
e-smith-apache-1_2_0-13_el4_sme (revision: 1.1)
From this output you can see that the working revision of the (e-smith-apache) code is at version 1.3 and that the latest tag in the repository is 1.2, so we need to make a new tag for this release, we can use this command to do so:
make tag
Building
To instruct the build system to build the package we tagged you issue
make build
Examples of CVS usage
Move contribs from SME(n-1) to SME(n)
here is an example for SME7 to SME8:
Do a clean checkout of smeserver-mycontrib (This is very important, must be a completely clean tree)
rm -rf ~/smecontribs/rpms/smeserver-mycontrib cd ~/smecontribs/rpms cvs co smeserver-mycontrib cd smeserver-mycontrib
then you can copy (DO NOT MODIFY ANYTHING before commiting!!!):
cp -a contribs7 contribs8 rm -rf contribs8/CVS cvs add contribs8 find contribs8 -mindepth 1 -name CVS -prune -o -print | xargs cvs add cvs commit -m 'Initial import'
finally you can make your first build
cd contribs8 make local make tag make build
Creating a new branch, eg SME 9
Package Build Steps
check out package
cp -a sme8 sme9 rm -rf sme9/CVS cd sme9 make prep
mv {sourcedir} {newsourcedir}
- example e-smith-base-5.2.0 to e-smith-base-5.4.0
rm -f *.patch
- apply any fixes from spec to tree, only for SME Server packages
- move lib/perl5/site_perl to share/perl5/vendor_perl
tar Jcvf {newsource}.tar.xz {newsourcedir}
vi *.spec
- remove patches and fixes applied directly to tree
- bump version and reset release to 1
- add changelog saying rolling for sme9
make mockbuild
- if this works then we can proceed
rpm -qpl {package-version}_sme/{rpmname}.rpm
- check that files look similar to the sme8 package
These following steps need developer access
They are here for reference, and transparency. They will need to be run on SME Server's build server. You do not need to do this part. (If you have CVS access but not access to the build servers please don't run any of these commands)
cd .. cvs add sme9 cd sme9
date +%s
- get date for import
vi import.log*
- fix name/version/release and date
cvs add .cvsignore *.spec Makefile import.log sources
- be sure to add any other needed packages
make new-sources FILES=*xz
make commit tag build
Patching an upstream package
initscripts is an example of a package where we have to patch the upstream package. Note that this is not the best approach, new method to be documented by Ian soon.
Original author Ian Wells
Here it is a 3-step process, Analysis, Integration, buildsys update. The majority of the work is in steps 1 & 2 where there needs to be an analysis of what has changed, and then an integration stage where you need to check that the patches still work, update CVS with new and modified files etc. Finally the new source needs updating into the buildsys before the official build will work.
initscripts-8.45.44-3.el5.centos.src.rpm
Steps to update initscripts
Step 1: Analysis, by anyone
Check the contents of the SRPMs
$ rpm -qlp initscripts-8.45.44-3.el5.centos.src.rpm 0001-Fix-comments-in-sysctl.conf.ppc-862597.patch 0002-create-tmp-.X11-unix-in-rc.sysinit.patch initscripts-8.45.44.tar.bz2 initscripts-centos-branding.patch initscripts.spec
$ rpm -qlp initscripts-8.45.42-2.1.el5.sme.src.rpm 0002-create-tmp-.X11-unix-in-rc.sysinit.patch initscripts-8.45.38-smepatches.patch initscripts-8.45.42-kpartx.patch initscripts-8.45.42.tar.bz2 initscripts-centos-branding.patch initscripts.spec
Check what is different (do a directory compare)
- Identical
initscripts-centos-branding.patch (content is identical, although files are not)
- Modified
initscripts.spec 0002-create-tmp-.X11-unix-in-rc.sysinit.patch (patch is identical but line numbers changed)
- New
initscripts-8.45.44.tar.bz2 (New source will need to be added to buildsys) 0001-Fix-comments-in-sysctl.conf.ppc-862597.patch (will be added to CVS)
- Obsolete
initscripts-8.45.42-kpartx.patch (can be removed from CVS) initscripts-8.45.42.tar.bz2
- Not in upstream SRPM as this is an SME Server patch to be applied each time
initscripts-8.45.38-smepatches.patch
So we need the new initscripts-8.45.44.tar.bz2 & 0001-Fix-comments-in-sysctl.conf.ppc-862597.patch, and the updated 0002-create-tmp-.X11-unix-in-rc.sysinit.patch
Step 2: Integration : local mock build, can be done by a developer
- Remove the obsolete files
- Update the spec file.
Version Release Patches Check the description, don't copy the 'Centos' wording to the SME package Copy the latest upstream Changelog Add/modify the changelog regarding SME patches
- Copy the new patch & source to the local directory
- Check that the patches apply cleanly (You don't want to see lines like Hunk #1 succeeded at 890 (offset 1 line).)
make prep
- Try to build it
make mockbuild
- Once it builds cleanly on local mock, commit the changes to CVS. Note that you cannot submit the build yet as it will fail due to the new source.
make commit
Step 3: Buildsys access and permissions needed
Then add new sources to buildsys ON BUILDSYS
If the above step has already been done then can update to latest in CVS, and retrieve the source tarball.
- get date for import
$ date +%s 1382918459
- fix name/version/release and date in the import.log (I don't have a good explanation for this)
vi import.log*
- import the new source/tarball
make new-sources FILES=*bz2
- Finally commit changes to CVS and build it.
make commit tag build