Great, thanks for taking care of that. On Oct 5, 2023, at 10:42 AM, Herby G <[email protected]<mailto:[email protected]>> wrote:
Apologies, that was a careless response. You are correct, it is indeed `p1`. I took a look: https://github.com/macports/macports-ports/pull/20721 The issue is that the final hunk of the patch is invalid. It needed to be edited to match the actual line present in `pith/pine.hlp`. On Thu, Oct 5, 2023 at 3:47 AM contextnerror <[email protected]<mailto:[email protected]>> wrote: That fails even earlier, and on all of the files instead of just pine. On Oct 4, 2023, at 10:22 PM, Herby G <[email protected]<mailto:[email protected]>> wrote: Attempt with `patch.pre_args -p0` On Wed, Oct 4, 2023 at 10:38 PM contextnerror <[email protected]<mailto:[email protected]>> wrote: Thanks for that advice. I tried to use the patch from https://repo.or.cz/alpine.git/patch/701aebc00aff0585ce6c96653714e4ba94834c9c This was with patch.pre_args -p1 applied as well. It’s failing at pith/pine.hlp: "Hunk #1 FAILED at 147.” Do I even need this file? I’m not sure how it’s related. > On Oct 4, 2023, at 6:49 AM, Joshua Root > <[email protected]<mailto:[email protected]>> wrote: > > On 4/10/2023 15:05, contextnerror wrote: >> I was hoping to update the portfile for alpine. >> Currently the 2.26 release will not build due to a passfile bug, but this >> was fixed in a newer commit. (https://repo.or.cz/alpine.git) >> I had a few questions about how to implement this: >> - Should I add the changes as patchfiles, or just change the master site to >> the git repo? >> - Would the version still be 2.26 or something else? >> - Should I also add any of the other new fixes from git? > > Fetching from a VCS should be avoided if possible, since we can't mirror the > source in that case, and fetching is more likely to fail on restrictive > networks. So probably patchfiles. > > Usually we would not change the version when adding bug fix patches. If the > version in the published ports tree were already 2.26 and you added a patch > that changes the installed files in any way, you would of course increase the > port's revision. > > Normally you don't want to pull in all the changes that exist in an upstream > repo, simply because if they were considered ready to use there would be a > new release containing them. Some projects have very slow release cycles > though, so if that's the case here, try to get some sense of the risk vs > benefit for each change before deciding to incorporate it. > > - Josh
