LGTM, gimme couple hours and I will commit it.

@samm Can you move forward with this patch? The maintainer has timeout already.

So please, proceed to merge these two reviews and incorporate the submitter suggestions.

In D22045#483993, @samm wrote:

In D22045#483373, @araujo wrote:

@samm Could you double check with @daniel.engberg.lists_pyret.net the changes that he is proposing and perhaps after that we can close the D21969 review?

A single place makes more sense, however @daniel.engberg.lists_pyret.net opened the review first, so technically he will receive the credits for the patch submission. I just want a single review for this port update.

Best Regards,

Hi, i am perfectly fine to give him credits and merge the patches. Main problem is that there is no feedback from the maintainer. What should we do to get this done?

In D21969#483377, @daniel.engberg.lists_pyret.net wrote:

Sure, but I think it's a discouraging way to handle submissions in terms of chronological order.

@samm Could you double check with @daniel.engberg.lists_pyret.net the changes that he is proposing and perhaps after that we can close the D21969 review?

In D21969#483371, @daniel.engberg.lists_pyret.net wrote:

At least fix the issues reported in that case?

Can we abandon this review in favor of the another one?

LGTM, I will commit soon!!!

Lgtm!

You should bump PORTREVISION to force package rebuild.

In D22051#481744, @dmgk wrote:

The PHB seems to say otherwise:

PORTREVISION must be increased each time a change is made to the port that changes the generated package in any way.

Changing MAINTAINER does change package metadata (and the generated package as a consequence) and according to the above, needs a PORTREVISION bump. But looking at the svn logs, nobody deems this change "important enough" to warrant a rebuild :)

For record only, accepting it from Fukushima, Japan!

Why bump PORTREVISION?

You don't need the gratuitous PORTREVISION bump here!

Forgot to commit? Is there anything left to be reviewed?

In D22022#481030, @samm wrote:

Thank you for feedback!

In D22022#481027, @araujo wrote:

Do you use poudriere?
https://www.freebsd.org/doc/handbook/ports-poudriere.html

Yes, i am using it already

You must always test the changes using it, also when you open a review, you should fullfil the test area saying at least something like:

poudriere (11.2-, 12.0-RELEASE, 13.0-CURRENT@r348350 amd64 + i386) -> OK
portlint and portclippy -> OK
Runtime tests -> OK

Ok, was not aware of this, will do from the next submission. Only problem is that host for the poudriere is now running on 11.3, so 12+ tests will fail.

And will think how to automate all the process...

Probably will setup bhyve vm on 12+ to do the tests or will upgrade this host.

Do you use poudriere?
https://www.freebsd.org/doc/handbook/ports-poudriere.html

You have two "right" options, choose wisely :)

Two separate commits makes it easier to write the history log and in case you need one day to make a revert, it will be more easier to identify the reason. But it is not mandatory, but it is what I have been doing since 2007.

Sorry, I should have accepted it!!! But please wait for krion to approve it.

Thanks for that! You did right already!

I came here from D21838 to say: looks good too!!! :)

Lgtm, thank you!

Lgtm

In D21955#479672, @dmgk wrote:

Hook to the build.

In D21955#479658, @dmgk wrote:

In D21955#479644, @araujo wrote:

You need to connect the new port on security/Makefile, seems it is missing from this diff.

But I was asked to use addport for this by @tz - https://reviews.freebsd.org/D21780?id=62505#inline-136019
So what should I use? :)

You need to connect the new port on security/Makefile, seems it is missing from this diff.

It is a bit of nit picky from my side, but I don't see a reason for those changes, actually before was better, the files were in alphabetic order.
Did I miss something?

In D21929#479091, @romain wrote:

This solves my problem as far as I am concerned. Maybe it's worth thinking about this tuning globally since we have more than 50 ports depending on devel/git and I am pretty sure most of these ports would be functional with devel/git-lite. By defaulting to devel/git-lite, you make it impossible to use both one of there 50+ ports and sysutils/iocage, which might be a problem? I am not sure about what is the best solution, so I will stick to a LGTM for now :-)

In D21854#479049, @dmgk wrote:

In D21854#479045, @araujo wrote:

Hey @dmgk, please proceed with the commit. You have my blessing.

Thanks, I asked for an exp-run (https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=240986) and will commit as soon as it passes.

Hey @dmgk, please proceed with the commit. You have my blessing.

In D21854#477434, @dmgk wrote:

In D21854#477383, @araujo wrote:

LGTM!

Do I need to get portmgr approval for this or it's OK to commit along with https://reviews.freebsd.org/D21730?

LGTM!

In D21744#477011, @dmgk wrote:

In D21744#476965, @adamw wrote:

That's fair. However, this review is a sweeping change of all go ports to meet a specific, consistent standard, suggesting that the plurality of ports were doing things in a suboptimal way. IMO the PHB should demonstrate what the ports should and should not be doing.

Makes sense. Perhaps it would be useful to have a list of "best practices" for creating Go ports. I'll extend the "Building Go Applications" section and post a doc review.

In D21819#476317, @dmgk wrote:

Looks like svn ate "Changes:" line in the commit message, sorry about that. Is it some kind a reserved keyword? Should I use "Changelog" or similar for itemized changes list?

On this Port secteam isn't needed because your are the maintainer. The another case we will check who approves first maintainer or secteam. If none of them approves in couple days, we need to escalate to portmng.

ports secteam any of you could approve? @dmgk add ports_secteam group in the review too.

Ok, please open reviews for both of go and go-devel, we should commit the vuxml and both ports together, not mandatory, but nice to do.

Will we update go and go-devel ports? Do you need to sync anything with @jlaffaye?

Is it worth do an exp-run on this one too?

LGTM, same thing as the other reviews, wait for the exp-run and also for the portmgr approval.

LGTM, same thing, wait for the exp-run and portmgr approval.

It looks good to me, but you need to wait for the exp-run and also portmgr approval.
Thanks to work on this.

This is cool, I didn't know it would be possible set version via ldflags.

In D21730#475087, @dmgk wrote:

In D21730#474823, @tobik wrote:

IIUC this potentially changes all Go binaries, so all USES=go ports that do not set ldflags themselves probably need a PORTREVISION bump afterwards to relink them?

A quick search

for f in $(find /usr/ports -name Makefile | xargs grep -l 'USES=.*\bgo\b'); do grep -q '\bldflags\b' $f || echo $f; done | wc -l

shows that it would require bumping PORTREVISION of 198 ports. Recompiling will make binaries about 25% smaller on average but there are no other functional changes. I can prepare a separate review if we're OK with this.

In D21721#474028, @dmgk wrote:

In D21721#473929, @araujo wrote:

As you are working on this already for a while, how about ports that you are not a maintainer? Maybe an exp-run following with a portmgr@ approval would be interesting to clean up the rest of the ports.

That was my plan actually, I was just not sure what would be the best way to get something like that reviewed/committed. The complete diff is about 250KB, I was thinking about maybe breaking it to 3-4 parts for easier review. Would that make sense or it would be better to post it in a single review?

In D21721#473887, @dmgk wrote:

In D21721#473870, @tz wrote:

Since i am very unfamiliar with the go ports, i have problems to understand this diff.
In devel/awless only do-build and do-install is removed, but i do not see any usage of GO_TARGET. Same for some other ports.

r505321 converted all ports to USES=go which already provides do-build and do-install targets. During that conversion, ports that were defining their own build/install targets were left alone to be cleaned up later. This commit does this cleanup for the ports that I maintain.

You should do two commits for this review, first commit security/botan2 and then commit the BUMP for the other ports that depends of security/botan2.