Bug 244710 - www/gitea 1.11.2 shows wrong version number
Summary: www/gitea 1.11.2 shows wrong version number
Status: Closed FIXED
Alias: None
Product: Ports & Packages
Classification: Unclassified
Component: Individual Port(s) (show other bugs)
Version: Latest
Hardware: Any Any
: --- Affects Only Me
Assignee: Adam Weinberger
URL:
Keywords:
Depends on: 244898
Blocks:
  Show dependency treegraph
 
Reported: 2020-03-10 09:01 UTC by Stefan Bethke
Modified: 2020-04-13 16:15 UTC (History)
1 user (show)

See Also:


Attachments
Fix version string (988 bytes, patch)
2020-03-10 16:26 UTC, Adam Weinberger
no flags Details | Diff

Note You need to log in before you can comment on or make changes to this bug.
Description Stefan Bethke 2020-03-10 09:01:54 UTC
On behalf of a user on -ports:

Yesterday, I updated gitea on my FreeBSD server. I updated using pkg.
While `pkg info gitea` claims that the installed version is 1.11.2, the
command `gitea -v` claims that I'm running 1.9.0-dev. At the same time,
my instance does have the new features that have been released in 1.11.2.
Comment 1 Stefan Bethke 2020-03-10 09:02:55 UTC
The version number reported by the gitea binary is wrong. I'll check the build to see why the VERSION file is not picked up properly.
Comment 2 Adam Weinberger freebsd_committer freebsd_triage 2020-03-10 16:26:40 UTC
Created attachment 212311 [details]
Fix version string

Ok, the problem here is that we're passing LDFLAGS in MAKE_ARGS, which winds up clobbering the LDFLAGS that WRKSRC/Makefile sets (which includes the version string). Passing the LDFLAGS in MAKE_ENV fixes that.

Doing so, however, exposes another problem whereby the '-fstack-protector-string' from Mk/bsd.ssp.mk breaks the build. I have no idea whether golang supports stack protection, but disabling it (as appears in the patch) makes the build work.

If you're aware of golang supporting stack protection, then we need to do something else (possibly allowing the ssp LDFLAGS to be overridden as the SSP_CFLAGS are).
Comment 3 Adam Weinberger freebsd_committer freebsd_triage 2020-03-17 00:11:43 UTC
Hi, do you have input here on what approach you'd like to take?
Comment 4 Stefan Bethke 2020-03-18 21:17:35 UTC
Should be fixed by bug 244898. Thanks adamw!
Comment 5 Kubilay Kocak freebsd_committer freebsd_triage 2020-03-19 01:37:52 UTC
^Triage: Re-open until dependent bug(s) are closed
Comment 6 Kubilay Kocak freebsd_committer freebsd_triage 2020-03-19 01:39:24 UTC
Ideally this bug fix can land prior to the version update in bug 244898, so that the bugfix can be merged to the quarterly branch, unless the version update is also a bugfix only release, in which case all of bug 244898  can be committed to head and merged to quarterly
Comment 7 Stefan Bethke 2020-03-19 09:04:28 UTC
(In reply to Kubilay Kocak from comment #6)

Release 1.11.3 (in bug 244898) is a pure bug fix release.
Comment 8 Adam Weinberger freebsd_committer freebsd_triage 2020-04-12 16:21:57 UTC
I'm a little confused. Does something in this PR need to be fixed? Or can we close it?
Comment 9 Stefan Bethke 2020-04-13 12:42:24 UTC
(In reply to Adam Weinberger from comment #8)

No, with the current version of the port, everything is fine. I think this can be closed.
Comment 10 Adam Weinberger freebsd_committer freebsd_triage 2020-04-13 16:15:51 UTC
Thanks, Stefan.