security/certmgr: fix build on riscv64

[fuz]

Summary

security/certmgr: fix build on riscv64

 - bump golang.org/x/sys dependency to 0.5.0 to add
   missing riscv64-freebsd bits
 - remove lots of useless GH_TUPLE entries (these are
   already vendored in the upstream repository).
 - move REINPLACE_CMD to pre-configure to simplify
   make makepatch

Tested by:	dmgk
Approved by:	... (mentor)
Sponsored by:	Berliner Linux User Group e.V.

Test Plan

Tested with Poudriere on riscv64 FreeBSD 13.1 (no log file available).
Tested with Poudriere on i386 amd64 FreeBSD 12.4 13.1.
Arm64 test results pending. For logs see
http://fuz.su/~fuz/freebsd/batch3

[fuz]

ARM64 builds have concluded meanwhile.

[flo]

Are the bundled libraries always used? I.e. the ones that the port depended on were unused? Otherwise we should keep the dependencies.

https://docs.freebsd.org/en/books/porters-handbook/book/#bundled-libs

[fuz]

@flo This is a Go port, which always links its dependencies statically. As per Porter's Handbook, Go dependencies are never packaged on their own, simply because it cannot be done in a reasonable way. This project in particular *vendors* its dependencies, meaning copies of them are part of the upstream repository. A part of go.mk is the target gomod-vendor which automatically generates a set of GH_TUPLE entries to do this vendoring locally, permitting a build without network access at build time. This target did not detect that upstream had already vendored the dependencies, leading to useless duplicate code fetches. With more knowledge of how this works, I can now safely remove these extraneous distfiles, keeping only the one we override with a different version. They were never used anyway as the presence of the directories they were supposed to be unpacked to in the main distfile led them to be unpacked into the wrong places.

[flo]

In D38684#880648, @fuz wrote:

@flo This is a Go port, which always links its dependencies statically. As per Porter's Handbook, Go dependencies are never packaged on their own, simply because it cannot be done in a reasonable way. This project in particular *vendors* its dependencies, meaning copies of them are part of the upstream repository. A part of go.mk is the target gomod-vendor which automatically generates a set of GH_TUPLE entries to do this vendoring locally, permitting a build without network access at build time. This target did not detect that upstream had already vendored the dependencies, leading to useless duplicate code fetches. With more knowledge of how this works, I can now safely remove these extraneous distfiles, keeping only the one we override with a different version. They were never used anyway as the presence of the directories they were supposed to be unpacked to in the main distfile led them to be unpacked into the wrong places.

I wanted to preface my question with a remark that I don't know anything related to go ports..., except that the programs are always statically linked. Thanks for the detailed explanation. So my suspicion was true, that those deps were never used.

Approved.