Syncing the Minix pkgsrc Repository with Upstream

Minix uses pkgsrc as it's primary package manager, and pkgsrc is generally distributed in source form via a version control system. Most people on non-Minix systems use CVS to checkout the latest copy from the NetBSD project. Since all of the Minix specific changes and patches haven't made their way into the NetBSD version of pkgsrc yet, we maintain our version of the pkgsrc tree in own repository on git.minix3.org. On a semi-regular basis we update our pkgsrc tree by merging in the changes from the NetBSD (upstream) version. Upstream uses CVS and we use git. Luckily, the folks at DragonFlyBSD maintain a git mirror of NetBSD's pkgsrc repository (here). To update our repository, we just merge the changes from DragonFlyBSD's mirror.

The master branch of Minix's pkgsrc.git repository contains a pristine copy of the pkgsrc repository. The minix-master branch contains a copy of the master branch with the minix specific changes applied. We are going to be fetching the master branch from DragonFlyBSD's pkgsrcv2.git repository and merging it into the master branch of Minix's pkgsrc.git repository. From there we will merge the master branch of Minix's pkgsrc.git into the minix-master branch of Minix's pkgsrc.git and deal with any merge conflicts.

Get a copy of Minix's pkgsrc.git

git clone gitosis@git.minix3.org:pkgsrc
cd pkgsrc
git checkout master

Add the DragonFlyBSD repository and get the changes from upstream.

git remote add upstream-pkgsrc git://git.dragonflybsd.org/pkgsrcv2.git
git fetch upstream-pkgsrc

Merge the changes into master. Note, Minix's master branch mirrors DragonFlyBSD's master branch. If you get any merge conflicts at this stage, you're doing something wrong.

git merge upstream-pkgsrc/master
git push
git pull

Merge the changes from Minix's master branch into the minix-master branch.

git checkout minix-master
git pull
git merge master

git will tell you if automerge failed. You can use git status to see the conflicts. You should fix the conflict(s), then git add the changed files

git add -v path/to/fixed/files
git status

When git status shows that you have no more work to do and a bulk build succeeds, then you can do a commit.

git commit

When you have completed the merge and done sufficient testing, you can push the changes.

git push

• Check the pkgsrc upstreaming page to see if any patches or package changes have been upstreamed since the last sync.

• Once you do the git merge master step, do git status to see the conflicts. A good conflict resolution strategy is to go through the list, beginning by merging changes in mk/, then moving on to toolchain packages, libraries, and finally applications.

• If you are a contributor with read-only access to minix3.org, you can follow the above steps in your private repository to get the upstream (DragonFlyBSD's pkgsrcv2.git) reference as the master branch, since as explained above it will merge with fast-forwarding. However, you must wait for the MINIX3 developers to perform the merge into the minix-master branch.

Symptom:

# git status
...
# Untracked files:
#   (use "git add <file>..." to include in what will be committed)
#
#	patch-lib_libucsi_dvb_rnt__rar__over__dvb__stream__descripto
...

Cause: Minix FS has a NAME_MAX of 60. Filenames longer than 60 characters are truncated.

Solution:

# mv patch-lib_libucsi_dvb_rnt__rar__over__dvb__stream__descripto patch-too-long-ab
# git rm patch-lib_libucsi_dvb_rnt__rar__over__dvb__stream__descripto*
rm 'multimedia/dvb-apps/patches/patch-lib_libucsi_dvb_rnt__rar__over__dvb__stream__descriptor.h'
# git add patch-too-long-ab

Don't forget to do 'bmake mdi' and 'git add distinfo' in the package's directory.

Symptom:

# bmake patch
...
=> Applying pkgsrc patches for gcc44-4.4.7
2 out of 5 hunks failed--saving rejects to gcc/config.gcc.rej
Patch /usr/pkgsrc/lang/gcc44/patches/patch-ac failed
...

Cause: If upstream did a version bump, some patches might not apply to the new version.

Solution 1: Look at the patch and the file it's trying to patch. If the patch was applied upstream, you can remove it.

# less patches/patch-ac
# less /usr/tmp/work/lang/gcc44/work/gcc44-4.4.7/gcc/config.gcc
# git rm patches/patch-ac
# bmake mdi
# git add distinfo

Solution 2: if it looks like it is simply a matter of the line numbers changing due to code being added/removed, you can set PATCH_FUZZ_FACTOR to cause patch to try harder. If it succeeds, you will need to remake the patch.

# PATCH_FUZZ_FACTOR=-F2 bmake patch
...
# cd /usr/tmp/work/lang/gcc44/work/gcc44-4.4.7 && diff -bu gcc/config.gcc.orig gcc/config.gcc > /usr/pkgsrc/lang/gcc44/patches/patch-ac
# cd /usr/pkgsrc/lang/gcc44/
# bmake mdi
# git add distinfo patches/patch-ac

Solution 3: If all else fails, manually edit the file and generate a new patch.

# bmake extract
...
# pkgvi /usr/tmp/work/lang/gcc44/work/gcc44-4.4.7/gcc/config.gcc
# cd /usr/tmp/work/lang/gcc44/work/gcc44-4.4.7
# diff -bu gcc/config.gcc.orig gcc/config.gcc > /usr/pkgsrc/lang/gcc44/patches/patch-ac
# cd /usr/pkgsrc/lang/gcc44/
# bmake mdi
# git add distinfo patches/patch-ac