Hello @ports Damien, Stuart and Theo. I'm attaching Forgejo 13.0.1 port, which was released two days ago.
This works Ok on OpenBSD 7.8 -current amd64. I fixed the following issue: >>> ld: error: undefined symbol: code.gitea.io/sdk/gitea.(*Client).getParsedResponse The root cause of the build issue in Forgejo 13.x.x lies in a "hack"introduced since version 11.0.0 to resolve a visibility limitation within the
Gitea SDK. The function essential for low-level request execution and API response parsing (getParsedResponse) is defined as non-exported (private) within the SDK package. To allow the migration code to access this function, Forgejo developers created the workaround gitea_sdk_hack.go, which utilized the //go:linkname directive. This directive is a bypass tool that attempts to force linkage toprivate symbols. This practice is insecure and broke the building process. It
failed catastrophically under OpenBSD, preventing binary generation. I strongly advise against modifying the SDK to make the getParsedResponse function public for the following security reasons: PoLP Violation: Exposing this low-level primitive for request execution compromises security encapsulation. The responsibility for authentication (tokens, headers) must reside within the SDK's Client object, not in the consuming module. Increased Attack Surface: Making this function public would introduce a new vector for attack that could be exploited by external code. It would weaken control over authenticated request execution, increasing the risk of API manipulation. To eliminate the //go:linkname "hack", I implemented the doRawAPIRequest function within the migrations package.The Forgejo 13.0.1 binary compiles successfully for now, but it requires extensive testing.
Purple Rain On 10/18/25 10:44 AM, Stuart Henderson wrote:
On 2025/10/18 05:27, Theo Buehler wrote:On Fri, Oct 17, 2025 at 08:23:26PM +0000, Purple Rain wrote:Hello ports@ and Damien Here is a updated port www/forgejo 7.0.16 This works OK on SecBSD and OpenBSD-7.8-current amd64.Is there a reason to stick with 7, which is EOL since July 2025? I would have expected a port to target 13, or at least 11.Looking at https://forgejo.org/docs/latest/admin/release-schedule/ I wonder if LTS (currently 11) might align better with our schedule. The patches to default config seem excessive and easily result in conflicts for updates. For starters most of the overridden paths seem to have sane defaults relative to AppWorkPath so perhaps set that via --work-path in daemon_flags and use the default paths or relative paths? (if you can avoid needing SUBST_CMD for patched files, that will also simplify updating patches). That also avoids missed patches if an update addds a new configurable path. I'd tend to avoid patching the .ini for personal preferences and restrict it to just changes needed for the port, unless really important. Again to reduce conflicts for updates.
forgejo.tgz
Description: application/compressed-tar
