Updating alpine

[Herby G]

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 ​ <contextnerror at outlook.com>
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 <herby.gillot at gmail.com> wrote:
>
> Attempt with `patch.pre_args -p0`
>
> On Wed, Oct 4, 2023 at 10:38 PM contextnerror ​ <contextnerror at outlook.com>
> 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 <jmr at macports.org> 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
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.macports.org/pipermail/macports-dev/attachments/20231005/355c8e95/attachment.htm>