sysutils/tmux: Update to 3.6

[yasu]

Summary

While here,

• Pet portclippy.
• Tidy up Makefile with portfmt.

ChangeLog: https://github.com/tmux/tmux/blob/3.6/CHANGES

Test Plan

Build succeeds with poudriere and 14.3-RELEASE amd64 jail.

[yasu]

Replase files/patch-server-fn.c with the patch from upstream.

[yasu]

Change reviewer to new maintainer.

[vsasjason_gmail.com]

sysutils/tmux/files/patch-server-fn.c

2–25

There's no need to copy the patch itself. Please see section 5.4.8 of Porter's Handbook [0] for reference.

[yasu]

@vsasjason_gmail.com I know it but there is reason I don't use. When the source of patch is GitHub, content of the file sometimes changes with unknown reason and it causes checksum error. So I intentionally include patch file in ports tree.

[vsasjason_gmail.com]

In D53924#1233441, @yasu wrote:

@vsasjason_gmail.com I know it but there is reason I don't use. When the source of patch is GitHub, content of the file sometimes changes with unknown reason and it causes checksum error. So I intentionally include patch file in ports tree.

Are you sure it's the case for GitHub? I know it happens kinda often on BitBucket since they include git version in footer, but GitHub doesn't do that. I believe patch will never change unless repository history would be rewritten which would change commit hash (and then link to commit will change). But I'd say it would be even better to fail from our side then, to catch the fact of history rewrite.

[yasu]

Are you sure it's the case for GitHub? I know it happens kinda often on BitBucket since they include git version in footer, but GitHub doesn't do that. I believe patch will never change unless repository history would be rewritten which would change commit hash (and then link to commit will change). But I'd say it would be even better to fail from our side then, to catch the fact of history rewrite.

I don't agree with you. Why is it better for us to be bothered by the reason that is out of our control?