current: # pkg install zrepl # zrepl version client: zrepl version= go=go1.17.3 GOOS=freebsd GOARCH=amd64 Compiler=gc expected: # zrepl version client: zrepl version=0.4.0 go=go1.17.3 GOOS=freebsd GOARCH=amd64 Compiler=gc The reason is that the port is using `go build` directly, instead of using `gmake`. I tried like this: USES= gmake go:modules,no_targets USE_RC_SUBR= zrepl MAKE_ENV= ZREPL_VERSION=${DISTVERSION} but it gets a bit complex as it would probably require modifications to the Makefile (but, as we're not using it, should USES=gmake removed from the port?). I finally managed like this (but is a bit more hackish and breaks WITH_DEBUG as it overrides "-ldflags=-s" as would be otherwise done in /usr/ports/Mk/Uses/go.mk) but it's simple enough and works in the general case: GO_BUILDFLAGS+= -ldflags="-X github.com/zrepl/zrepl/version.zreplVersion=${DISTVERSION}"
Thank you for the report. Good catch. It looks like we only need the `gmake` dependency when building the documentation through sphinx, as such, is easily addressed by only including it in `MANPAGES_USES` rather than the global `USES` which applies for all the port OPTIONS. Regarding version output, appending to `GO_BUILDFLAGS` is the most elegant solution, and usually we don't see the use of `WITH_DEBUG/DEBUG` (or generally including symbol tables/debug information) explicitly (or by default) in many Go-specific packages so have little qualms going this route, goes without saying anyone who wishes to enable this kind of behavior can do it manually. I'll address these issues shortly.
A commit in branch main references this bug: URL: https://cgit.FreeBSD.org/ports/commit/?id=cc6aef99d65a5cae3a48e007fa3036368938a153 commit cc6aef99d65a5cae3a48e007fa3036368938a153 Author: Lewis Cook <lcook@FreeBSD.org> AuthorDate: 2021-12-22 15:56:48 +0000 Commit: Lewis Cook <lcook@FreeBSD.org> CommitDate: 2021-12-22 16:00:35 +0000 sysutils/zrepl: Include build version in command output While here, only include gmake as a dependency when building the documentation. PR: 260608 Reported by: Lapo Luchini <lapo@lapo.it> sysutils/zrepl/Makefile | 9 ++++++--- 1 file changed, 6 insertions(+), 3 deletions(-)
Appears to work as expected now: pts/0 zrepl% ./work/bin/zrepl version client: zrepl version=0.4.0 go=go1.17.5 GOOS=freebsd GOARCH=amd64 Compiler=gc Let me know if there is anything else. Cheers.
Nicely done, thanks! …my fault though, I didn't notice that version included by `gmake` would include a leading "v", so this should be needed for strict compatibility with manually compiled releases: GO_BUILDFLAGS+= -ldflags="-X github.com/zrepl/zrepl/version.zreplVersion=v${DISTVERSION}" (either that or ${DISTVERSIONPREFIX}…)
(In reply to Lapo Luchini from comment #4) No worries, ${DISTVERSIONFULL} also includes the prefix, committed: https://cgit.freebsd.org/ports/commit/?id=7bd7616e5043d364afda746fe4ed0d7087e7d92f :)
Seems to happen again with latest versions. % pkg info zrepl | head -n 3 zrepl-0.5.0.8 Name : zrepl Version : 0.5.0.8 % zrepl version client: zrepl version= go=go1.18.1 GOOS=freebsd GOARCH=amd64 Compiler=gc
Created attachment 238423 [details] Patch to fix version number display This patch will fix this issue for the tagged and untagged GH builds
Created attachment 238424 [details] Test build log for the purposed patch Added a test build log for the purposed patch.
(In reply to Lapo Luchini from comment #6) This was due to some over-optimization that was introduced in commit mentioned in comment #5 that affects builds from untagged GH zrepl releases. The attached patch will fix this issue for the tagged and untagged builds. So zrepl that was built with the attached patch properly displays it's version as: zrepl version=v0.5.0-8-g19b2deb go=go1.19.3 GOOS=freebsd GOARCH=amd64 Compiler=gc
I will take a look at it.
I checked this with last update in https://cgit.freebsd.org/ports/commit/?id=b74ef047bb99df838aedb6efdf0966667e4f2981 and it seems fixed. Closing, if this happens again feel free to open a new PR!
(In reply to Dries Michiels from comment #11) This will happen again if someone would commit a zrepl build from the untagged GH release. The version number will be compiled in fine until we build zrepl from the tagged releases - as in commit that you've mentioned. But as soon as we'll try to build zrepl from the untagged GH release, we'll face this problem again. The patch that was proposed in this bug-report will compile in a proper zrepl version for the both tagged and untagged GH releases. So this bug wasn't really "overcome by events" it was just hidden by them. ;-)