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]> 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]> wrote: > > Attempt with `patch.pre_args -p0` > > On Wed, Oct 4, 2023 at 10:38 PM contextnerror <[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]> 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 > > >
