Date: Wed, 03 Aug 2022 13:55:03 +0000 From: bugzilla-noreply@freebsd.org To: ports-bugs@FreeBSD.org Subject: [Bug 265462] security/crowdsec: update to 1.4.1 Message-ID: <bug-265462-7788-J7sw9WOnyJ@https.bugs.freebsd.org/bugzilla/> In-Reply-To: <bug-265462-7788@https.bugs.freebsd.org/bugzilla/> References: <bug-265462-7788@https.bugs.freebsd.org/bugzilla/>
next in thread | previous in thread | raw e-mail | index | archive | help
https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=3D265462 --- Comment #5 from marco@crowdsec.net --- Hi, thanks for suggestion! Long story short: I have tested, I agree and also GH_TAGNAME=3D ${DISTVERSIONFULL}-freebsd do you need a new patch? Now the long story. I need the freebsd release tags because I include vendored dependencies, wh= ich are not used in the other builds. But if I reference only the commit hash in GH_TAGNAME then I would have nothing, anywhere, that references the tag nam= e. I could remove the 1.3.4-freebsd and its packages would still accidentally bu= ild while taking the code from the 1.4.1-freebsd history... I don't like that. On the other hand the (misnamed) BUILD_TAG variable is used by the "cscli" command to display the version number. The makefile calls "git rev-parse HE= AD" under Linux but I can't do that while building from a zip file. If I set it to the tag name it would render as "v1.4.1-v1.4.1-freebsd". Ideally, I should be able to avoid a separate release tag by retrieving the dependencies before the build step, but I have not been able to replicate t= he functionality provided by go:modules, or configure it for my case. --=20 You are receiving this mail because: You are the assignee for the bug.=
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?bug-265462-7788-J7sw9WOnyJ>