Solved Methodically upgrade a port

TL;DR - What is the most methodical way patch a patch that no longer cleanly applies to the upstream source?

I'm looking into upgrading net/kamailio (currently the port pins to v5.0.1 of the upstream, I want to uprev this to 5.1.2 from the upstream).

Following the procedure describe this thread in conjunction with the porter's handbook, I'm running into patch reject issues:

Code:
===>  Applying FreeBSD patches for kamailio-5.1.2_1
1 out of 3 hunks failed--saving rejects to src/Makefile.rej
=> FreeBSD patch patch-src_Makefile failed to apply cleanly.

I guess you could take the latest version of the upstream and beat it back into shape and generate patches from that.

But that would potentially throw away the work done previously on the port. This might cause unnecessary rework and could introduce subtle bugs.

Is there known workflow to refresh a patch that has gone stale?
 
I get that the patch needs to be re-written, but is there an existing method to essentially follow the slow porting section of the handbook, whilst trying to leverage (and re-assess the reason for) existing patches?

When to-be-patched upstream tree is fetched, the old patches are applied and some of them fail. So then you have a broken tree which you can then fix. The workflow issue I see is that the handbook suggests to manually copy each to-be-patched file so that you can produce per-file diffs when you are finished. But when you run make patch to see how far you get with the old patches, some files will be modified before you get a chance to copy the pristine files (unless you read the patch file and make a copy of each pristine file that has a patch against it).

If the pristine upstream were managed by git or svn, then this wouldn't matter, since both tools could produce a diff between the working copy and the last revision or commit.

But AFAICT the upstream tree is HTTP downloaded and unpacked. So you need to copy before writing.

So I'm left thinking that I should:
  • make extract to get the pristine upstream
  • Eyeball each existing patch file and copy the corresponding file in the upstream for later diffing
  • make extract to see what happens
  • Resolve each conflict
  • Fix anything else that might be breaking the port
  • Nuke all existing patch files
  • make makepatch to re-generate the necessary refreshed patches
I just wonder how maintainers generally do this, to avoid manual and/or error prone refreshes.

Am I missing something or have I completely missed the point?
 
I would first find out what patches are not being applied and proceed to delete them one by one. Since I use svn for ports I can revert anytime.

Then starting building ( make stage) and fixing what is failing. If one of those deleted patches were supposed to fix a specific problem, I revert that and open on a separated terminal. Fix the original file as explained in the Porter's Handbook, run make makepatch and start again, building etc. until everything is fine. Of course using make clean after each of these "phases".

There is not much of shortcut for that, and can be tedious when there are many necessaries patches.
 
If you have a repo with the necessary patches applied (if not apply the existing patches to the repo one by one via patch -V none -E -i /path/to/patchfile and see what doesn't apply anymore and fix it on the go; do a commit for every applied patch; if upstream doesn't have a repo you can trivially create one with git init and adding the tarball contents into it) you can simply use that to generate a patch file and recreate the individual patches
  • Nuke all existing patches in files/
  • make clean
  • Generate a diff from the repo:
    git -C /path/to/repo diff --no-prefix ... > files/patch-foobar
  • make patch
  • rm files/patch-foobar (this is necessary if you want individual patch files. Without removing it first makepatch will recreate files/patch-foobar again)
  • make makepatch
 
Many thanks for the clear explanation - I was able to follow these steps easily - very much appreciated.

I cloned the upstream git repo and checked out the tag for the new port version.

I applied the each existing patches as you suggested patch -V none -E -i /path/to/patchfile.

After fixing the port and re-baselining with make makepatch, I successfully ran this with poudriere testport.

Now that I've got an upgraded port, I might find out how to submit this as a pull request.

But that is probably not the subject of this thread, so I guess we can mark this as resolved (I probably don't have the kudos to do this yet).
 
Back
Top