devel/libgtop: Update for ino64

[kib]

Summary

This change adopts the port to ino64 commit, which is explained in
https://lists.freebsd.org/pipermail/freebsd-current/2017-April/065687.html
The src change is nearly ready to commit, and is undergoing a final round
of pre-commit testing. This will likely happen in the next few days,
unless some issue found.

In general, patches for ino64 support will be conditional on FreeBSD
version. It is likely that __FreeBSD_version / kern.osreldate 1200031
will be the value used for the ino64 change, and the port patch may have
a conditional test using that value. Of course, if the final value in
the src commit is different the ports patches will be updated before
commit.

A number of ports require updates after this change is committed to src.
I seek approval of the change to the port in this review, either directly
from the maintainer or portmgr blanket approval of the set of ino64 port
updates. In either case I will commit the ports change shortly after the
src tree commit.

I am also happy if you, as maintainer of the port, wish to handle this
yourself. Please add a comment here with your preference for this port.

[emaste]

The ino64 src change is in review D10439

[kwm]

TLDR:

I would prefer the patch for libgtop I added to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218320 to be committed instead. But this whole efford is a lot of work and I can always svn mv the patch later, and replace it with the one with __FreeBSD_version checks. I need to do maintainance on the port anyway, so it not that big of a deal to fix up the patch later.

I would like to thank you for providing the patch!

[kib]

In D10795#223701, @kwm wrote:

I would prefer the patch for libgtop I added to https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=218320 to be committed instead. But this whole efford is a lot of work and I can always svn mv the patch later, and replace it with the one with __FreeBSD_version checks. I need to do maintainance on the port anyway, so it not that big of a deal to fix up the patch later.

I would like to thank you for providing the patch!

I am more than happy to offload this port to you and have you commit your patch.

Reasons why I did it this way is because OSVERSION check to edit is only one, and patch for port is much easier to regenerate when it is done this way. Also, after stable/11 is dropped from support, the patch should be applied unconditionally, most likely in upstream.

Also, does upstream accept such kind of patches with check for __FreeBSD_version ? I thought that the common preference is to do configure checks.

[kwm]

Ok, I will update it later with my patch when I get to doing my maintaince.

Upstream is happy with FreeBSD_version checks, and they happely take our patches. And usual configure checks are prefered. It just that there are already a lot of FreeBSD_version check spread over the code, so a few more don't really matter.

[kib]

In D10795#223708, @kwm wrote:

Ok, I will update it later with my patch when I get to doing my maintaince.

Sorry, it is not clear to me what should I do. Should I commit the patch from this review, and then you re-apply your preferred patch ? Or just delegate the port to you and presume that you will fix it shortly after ino64 src commit ?

[kwm]

Ah sorry, just commit the patch you proposed to libgtop as it is in this review.

I will add my patch with the __FreeBSD_version checks later after everything is committed.

[antoine]

The .include <bsd.port.mk> has to be replaced by .include <bsd.port.post.mk>

[antoine]

ah it is already.