Am 01.06.25 um 12:58 schrieb Stuart Henderson:
> On 2025/06/01 12:53, Christoph Liebender wrote:
>> Am 20.05.25 um 19:27 schrieb Christoph Liebender:
>>> Am 19.05.25 um 19:48 schrieb Omar Polo:
>>>> Usually we try to keep these kind of changes local to the ports tree
>>>> because upstream may not care and then it could break easily.  However,
>>>> in golang this is a bit weird to do.  So, you already have Unveil in
>>>> golang.org/x/sys, which is a "indirect" dependency of anubis, but
>>>> relying on it could break if future release stops depending on it.  On
>>>> the other hand, i don't think we have a way to add a dependency to an
>>>> existing go project for the build.
>>>
>>> www/anubis builds from a vendored tarball anyway so manually adding a go
>>> module would probably complicate the Makefile even more. Getting
>>> go.port.mk to build with this vendored tarball was already complicated
>>> enough, imho.
>>>
>>>> second thing, the usage pattern of unveil is thought to be along the
>>>> lines of
>>>>
>>>>      if (unveil(path, perm) == -1)
>>>>          err(1, "unveil");
>>>>
>>>> and your unveil binding is lacking the error checking.  I think you
>>>> should bubble up the errors returned by unveil(2) and call log.Fatal if
>>>> they fail, as upstream already does for other failing points.
>>>
>>> Yes, it makes sense to be pedantic about unveil calls failing. After
>>> all, it indicates misconfiguration to the user early on when starting
>>> the daemon. I've attached an updated diff.
>>>
>>> - Christoph
>>
>> Ping! Anyone else interested in reviewing/testing this patch? I consider
>> stepping up as MAINTAINER for anubis after this patch is applied.
> 
> would be happier if you took maintainer already if adding patches like
> this.
> 

Alright, sign me up then.