Rich Megginson (richmegginson) wrote,
Rich Megginson
richmegginson

Notes on using new Fedora fedpkg/git workflow

Fedora is switching from CVS to git for packages, and has a new tool fedpkg which replaces make.  I've been using git for over a year now on 389 and other projects, so I thought I would try using git to release the latest 389 updates.

I had already done a local mock build to make sure the builds worked.

To release 389-ds-base 1.2.6.rc6 and 389-admin 1.1.11.rc2, this is what I did:
yum install --enablerepo=epel-testing fedora-packager
the one in epel stable is not that good - the one in testing is much better
fedpkg clone 389-ds-base
cd 389-ds-base
fedpkg new-sources /path/to/389-ds-base-1.2.6.rc6.tar.bz2 # updates 'sources' and '.gitignore' and does a git add
edit 389-ds-base.spec *.sh # update for new version, bump Release, add changelog
git commit -a
fedpkg verrel # checks changelog consistency
git tag $(fedpkg verrel) # creates a named tag like the old make tag
git push --dry-run -v # to see what will happen
git push # push the changes
git push --tags # push the tag
fedpkg build --nowait
That takes care of master/rawhide.  There is a similar workflow for the other branches (currently f14, f13, f12, el6, el5, el4) - for each branch XXX
fedpkg switch-branch XXX
git merge master # this may cause merge conflicts - edit/git add/git commit to resolve
edit the files - remove the conflict markers - may have to manually update release numbers, changelog comments because different branches may have been updated independently e.g. to rebuild for a new build dependency - changelog comment editing may be tricky - have to preserve the old comments and order while adding the new comment for the new version, which may have a different Release number
edit 389-ds-base.spec ... # edit all of the files that are marked as having conflicts
git add 389-ds-base.spec ... # add the files to the commit to tell git merge we have fixed them
git commit # will resolve the merge conflicts
git log # optional - check the merge commits
fedpkg verrel # checks changelog consistency
git tag $(fedpkg verrel) # creates a named tag like the old make tag
git push --dry-run -v origin XXX:refs/heads/XXX/master # to see what will happen
git push origin XXX:refs/heads/XXX/master # push the changes
git push --tags # push the tag
fedpkg build --nowait
NOTES:
* not sure why git merge creates so many conflicts and cannot automatically merge - seems like it should be able to do that - perhaps subsequent merges will remember the common ancestor better and just "do the right thing"
* not sure why I have to specify git push origin XXX:refs/heads/XXX/master - in other projects, if I do
git checkout BRANCH
and BRANCH is set up to do remote tracking, doing
git push
will just automatically push all branches that are tracked remotely - perhaps subsequent pushes will work
Tags: git fedora
Subscribe

  • Post a new comment

    Error

    default userpic

    Your reply will be screened

    When you submit the form an invisible reCAPTCHA check will be performed.
    You must follow the Privacy Policy and Google Terms of use.
  • 2 comments