Approved

Approved

In D38863#884950, @fuz wrote:

Packages exist for other architectures and this bump changes the versions of dependencies used in them, hence I believe a PORTREVISION bump is appropriate.

Approved. Thanks for adding the UPDATING entry.

Approved.

I think this looks fine. What @diizzy notes comes down to personal preference I guess. Approved, with or without changes to the do-install target.

Approved

Approved

Approved

Approved

Approved

Approved.

Approved

I left a comment in the PR, i think we should add an UPDATING entry. Other than that I think this looks good.

Approved

Approved. I realize that this is one more of those not documented but usually we do it this way things. When we use blanket approval it's often noted as such. i.e. portmgr (blanket, build fix), otherwise it looks like portmgr actively approved this commit, which I *think* the did not?

Approved

Approved

This is kind of redundant information, i would leave it out

• make makesum
• new plist entries

Approved

Approved

Approved

Approved

Approved

In D38683#880657, @diizzy wrote:

Consider asking maintainer for a new patch as 1.3.5 is out
https://github.com/open62541/open62541/releases

In D38681#880651, @fuz wrote:

If you approve, please set the appropriate flag. I've seen various other maintainers write something to the effect of “first time maintainer” or “already maintainer of other ports” when committing new ports by third party contributors.

Yeah, forgot the tag. Ok, apparently I never noticed.

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.

In D38687#880643, @fuz wrote:

The maintainer has disclaimed maintainership (D38635). I had generated this batch of patches from a branch right before I had committed the previous batch, so that change is not in there yet.

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

Was this discussed with the maintainer? I'm 50:50 whether this is infrastructure works that we as committers are expected to correct, or if this should be run by the maintainer. For sysutils/rundeck2 it's clear as it has been unmaintained upstream for a long time.

Approved.

Approved. This looks like something that might be MFH'ed?

Approved. You can put something like (maintainer, via private mail). That's how it's done from time to time.

Approved.

Approved. I was going to comment on the commit message, that it should describe why something is done and not what is done, but I see it was also submitted by the maintainer.

"Submitter is first time maintainer." I've never seen this mentioned. I don't think it's necessary to mention this, but it doesn't hurt of course. Personally I would leave it out.

Looks good. Approved

Approved

In D38629#879848, @eduardo wrote:

Approved.

In D38635#879630, @fuz wrote:

Is it ok if I add the deprecation to the next batch or do you want me to revise this one?

In D38635#879603, @diizzy wrote:

As mentioned in PR deprecate 2.x and set EXPIRATION_DATE appropriately. Please don't just dump old unmaintained versions in ports.

In D38636#879592, @eduardo wrote:

Isn't Security: tag a vid or cve?
27c822a0-addc-11ed-a9ee-dca632b19f10
or
CVE-2021-44832 ?

Approved

Approved

Approved

Approved

Approved

I see you add a Reported by: tag on all maintainer submitted patches. That is relatively uncommon. I see that fernape seems to do this. Usually ever since switching to git we just set the author on the commit. Reported by: is usually for when someone just reported something but did not provide a patch.

In D38628#879480, @fuz wrote:

I have submitted the patch as I received it from the maintainer. I can change it to DISTVERSION for the commit if you want.

Approved

Approved

Approved

Approved. The PR states that it should be MFH'ed. I don't see this in the commit message template, but if you want to that's approved too, as a simple build fix.