Package maintenance guide

The following paragraphs are provisional content during the (doc) migration from dist-cvs to dist-git is happening.

Git config needs
A config problem has been discovered which may make fedpkg push or fedpkg commit -p or even git push not understand your intentions. As a short term work around, you can run: git config --global --add push.default tracking. This option tells git that when it gets a push request with no other arguments, see if it's tracking a remote branch. If it is, push to that remote branch. This seems like it will usually be safe no matter what git repository you are using.

Commands

Here is a basic table of equivalent commands:

OLD CVS	NEW GIT	Notes
cvs checkout libfoo	fedpkg clone libfoo	Note that branches are not separated out by directory with this command. To switch to a different branch with this layout, run: fedpkg switch-branch f13
cvs checkout libfoo (ALTERNATE)	fedpkg clone -B libfoo	This command creates the same branch/directory layout that was used with cvs.
cvs update	git pull	fedpkg will get a pull soon.
cvs commit .	fedpkg commit -p
cvs commit . (ALTERNATE)	fedpkg commit && fedpkg push	The -p option to commit invokes a push, but you can separate these actions just like with git
cvs commit -m 'breaking things' .	fedpkg commit -m 'breaking things' -p
make clog	fedpkg clog	Create the "clog" file from the %changelog of the specfile.
cvs commit -F clog .	fedpkg commit -F clog -p	Use the contents of file "clog" as the commit message.
make tag	N/A	Explicitly tagging source states for package builds is no longer necessary.
make build	fedpkg build
BUILD_FLAGS="--nowait" make build	fedpkg build --nowait	If you don't want to wait for the build to complete before freeing up the shell.
make prep	fedpkg prep
make chain-build CHAIN='foo bar : baz'	fedpkg chain-build foo bar : baz	Just like before, the current directory package is always added to the end of the CHAIN list.
make scratch-build	fedpkg scratch-build
make local	fedpkg local
make x86_64	fedpkg local --arch x86_64
make upload FILES='apollo starbuck'	fedpkg upload apollo starbuck	Remember, this adds new source files without replacing others.
make new-sources FILES='red_fish blue_fish'	fedpkg new-sources red_fish blue_fish	This replaces any existing source files.
make help	fedpkg -h
./cvs-import.sh libfoo-1.2-3.src.rpm	mkdir libfoo cd libfoo fedpkg import libfoo-1.2-3.src.rpm (Review Changes) fedpkg commit -p

Merging

Merging is one of the things that we can now do directly in the VCS that we had to do with an external diff program in CVS. Getting used to how it works may take a little adjustment though.

First, the way we imported from cvs means that we have to do a little work to make the older release branches "mergable" (F-14, since it branched after the conversion to git, doesn't need this).

fedpkg clone bzrtools
cd bzrtools
git merge origin/f13/master
# If no conflicts proceed to the next step.
# Otherwise, resolve the conflicts, git add & git commit, and then move on
git merge origin/f12/master
git merge origin/el6/master
git merge origin/el5/master

Potentially better alternative to the above (without conflicts, and without actually changing the master content):

fedpkg clone menu-cache
cd menu-cache
git merge -m "Initial pseudo merge for dist-git setup" -s ours $(git branch -r | grep -E '/(el|f|fc)[0-9]+/master')

Now when you make changes on one branch and want to move them to a different branch, you can use git to merge those changes.

fedpkg clone bzrtools
# Make some changes in the master branch
fedpkg new-sources bzrtools-2.2.tar.gz
vim bzrtools.spec
git commit
fedpkg switch-branch f14
git merge master

Resolving conflicts

Resolving conflicts is only slightly different than in cvs. When you git merge and a conflict occurs you still edit the files that have conflicts. Remove the conflict markers in the files and merge the changes manually. Then you need to commit your changes. Do that with git add CONFLICTEDFILES ; git commit

Branch names

Old CVS	new remote git	fedpkg local branch names	Notes
devel	origin/master	master	This is the default when you do fedpkg co
F-14	origin/f14/master	f14
F-13	origin/f13/master	f13
F-12	origin/f12/master	f12
EL-6	origin/el6/master	el6
EL-5	origin/el5/master	el5

local branch names
If you use git commands to branch and checkout directly, you can define whatever local branch names you want. If you use fedpkg switch-branch, it will default to creating the names listed in the table above. So you can do fedpkg clone firefox ; fedpkg switch-branch f14 and then you'll have a new local branch named f14

Display current branch in your shell prompt
It is often helpful to know what branch you are working on at a glance. You can add this information to your bash prompt with the information here.

Errors

Access denied

During the next few days and weeks, occasional tweaking to the servers might cause short periods (seconds or minutes) when the git server refuses you access. Just try again.

ssh fingerprint

The recommend option is to include "VerifyHostKeyDNS yes" in your ~/.ssh/config file. This will result in using DNS to check that the key is correct.

But you can also manually check against the list of keys at https://admin.fedoraproject.org . The strings there are what ends up in your ~/.ssh/known_hosts file. So you can accept the fingerprint when prompted and then check that the correct string for pkgs.fedoraproject.org ended up in your ~/.ssh/known_hosts file.

Search