From Fedora Project Wiki
(Imported from MoinMoin)
m (1 revision(s))
(No difference)

Latest revision as of 16:33, 24 May 2008

Fedora Package Collection CVS FAQ

This FAQ is still work in progress.

How do I update an existing package in CVS? (recommended way)

export CVS_RSH=ssh

Check out a local working copy of the CVS module you plan to edit, e.g. (for a description of the directory layout, see the Anatomy page:

cvs co libtar

In the directory libtar on your local disk you may find individual branches of the package, each in its own sub-directory (devel, FC-5, FC-6, ...) depending on what base OS release the package has been made for. The "devel" directory is where package development during the Fedora Development period takes places.

Enter the correct branch directory. If you update to a new upstream version you have to upload the tarball to an external lookaside cache. Operations on the lookaside cache require a client-side certificate, grab it and see instructions for installing it at To upload a new source tarball and replace an older one, run

make new-sources FILES="yournewtarball.tar.gz"

or for multiple files:

make new-sources FILES="yournewtarball.tar.gz yourbigdatafile.tar.gz"

This also updates your local copy of the .cvsignore and sources files. You will need to do this for each branch that you will be building the new version for. The new tarball will be uploaded only once and the rest will be md5sum checked and not uploaded, only the .cvsignore and sources files will be updated.

If you just want to add another tarball (e.g. a big gzipped patch or a documentation tarball), use:

make upload FILES="somefile.tar.gz"

Contrary to "make new-sources", this does not purge old files from the ".cvsignore" and "sources" files.

If you just have a small patch, initscript, or otherwise plain text file, you can commit those directly to CVS. This can be done with the cvs add command, e.g.:

cvs add packagename-fix-the-foobar.patch

After that you can start to modifiy the spec file of your package. Test if it compiles with a commands like

make i386

in the branch directory. If everything works fine you are ready to commit the changes to the cvs server. Before you do that you should run

cvs diff -u

and check if everything that has changed is correct. If it is you can commit all your modified files:

cvs commit

As a test whether the full commit was fine, check out a fresh working copy into a different directory. It should succeed in fetching the binaries from lookaside cache and also pass simple build tests such as make i386 or make srpm at least.

If everything is fine you can request the build with

make tag build


export CVS_RSH=ssh
cvs co foo
cd foo/devel
make new-sources FILES="foo-0.0.2.tar.bz2"
gedit foo.spec
make i386
cvs diff -u
cvs commit -m "Update to 0.0.2"
make tag build

Import of complete src.rpm packages

The common directory in CVS, which is replicated in every module directory, contains a script. This script can commit entire src.rpm contents in one step. It uploads new tarballs into lookaside cache, updates a working copy of the last version found in CVS, and commits all changes. In case you prepare your update packages in an ordinary rpmbuild tree, you can use the script to import a finished update src.rpm in one step. Examples:

./ ~/rpm/SRPMS/foo-1.0-2.src.rpm
./ -b FC-3 -m "import Joe's update" ~/bar-2.1-1.src.rpm

See " --help" for the options it understands. It can also update modules in branch directories other than the default "devel".

Be careful, since can also create non-existing cvs modules in "devel" branch on-the-fly. According to current policies, the creation of new modules needs approval.

Also be aware that if you a single src.rpm to multiple branches, you run into problems with cvs tags which cannot be the same for different branches. You will need to avoid tag collision yourself and e.g. add the %{dist} macro to your spec file after import and then run "make tag" manually for every branch you imported to.

Example for this method

Idea.png Warning! This way may look much easier, but it not recommended because you can't check the changes that you have made against the version in cvs before you commit them. People accidentally overwrote other packages with this method. Please make yourself familar with above description please.

export CVS_RSH=ssh
cvs co foo
cd foo/devel
make srpm
cd foo/common
./ -b <branch_name> -m "foo updated to 0.0.2" ~/rpmbuild/SRPM/<package_name>-<version>-<release>.src.rpm
cd ../<branch_name>
cvs up
make build

How to add new packages?

Please refer to the NewPackageProcess and the 'Import of complete src.rpm packages' section above.

How to import new packages on older branches?

Currently, the script can only create new modules in CVS in the "devel" directory. Due to this it is currently not possible to import completely new packages (i.e. packages which have not been stored in CVS before) with on branches other than "devel", simply because the other branch directories don't exist and won't be created by the script. But there is a way around it, which requires manual intervention. To request the creation of a new branch directory other than "devel" (e.g. FC-5), first import your package with in order to create the new module in CVS in the "devel" directory. Then edit CVSAdminProcedure and add your package name together with the branches you want.

How do I remove a branch I no longer want or need?

Simply use the cvs remove command. Do not list this on the CVSAdminProcedure page; that page is only for CVS administrative actions.

How do I make changes to an older branch?

Here is the scenario: you've build your package successfully on the FC-5 branch, but there is a problem keeping your package from building on FC-4.

Solution: make your changes in the branch and then add a digit to the very right of the release tag. There is no need to change the release in the other branches. This allows upgrades to work smoothly if the user upgrades to a newer release of Fedora.

Name:    foo
Version: 1.0
Release: 1%{?dist}

Name:    foo
Version: 1.0
Release: 1%{?dist}.1

Then tag and build as usual.


How to request builds?

Please refer to BuildRequests .

I have an account but I am unable to connect to CVS via ssh

Please write to accounts at and include all details. There has not been any IP address ACL anymore for months now, so your problem is likely a client configuration issue, private/public key mismatch, or some network problem.

I ran make tag without checking in my files, how do I revert so I can check them in?

If you are aware of the consequences of what you're doing, run:

TAG_OPTS=-F make tag

If you still run into problems, simply increase the Release version in your spec file, commit the changes, and run make tag normally.


  • For a list of Makefile targets, see Makefile or run
make help
  • Set the WORKDIR environment variable to point to a directory, in which the various "make" commands will run rpmbuild and store built rpms. Then make extensive use of e.g. "make i386" and "make srpm" to test your package prior to a CVS commit.

  • After cvs commit of a new package version or release, run make tag in your working copy to add a symbolic tag to this particular version of your package. With these cvs tags you can check out a specific version of your package easily any time. For instance:
cvs co -r fedora-rpmdevtools-1_0-2 fedora-rpmdevtools

The automated build system for Fedora Package Collection requires such tags in order to be able to fulfill build requests.

  • Use make clog to extract the last spec changelog entry and store it in a local "clog" file. Include this file as the cvs commit log message. This can be done with the following commands:
make clog
cvs commit -F clog

  • If you get this error:
ERROR: could not check remote file status
make: *** [upload]  Error 255

this usually means that your client certificate (~/.fedora.cert) has expired, so you need to head over to the account system and retrieve a new one.