Am Wed, 24 Mar 2021 15:15:17 +0100
schrieb prx <p...@ybad.name>:

> * Stuart Henderson <s...@spacehopper.org> le [22-03-2021 09:49:53
> +0000]:
> > On 2021/03/21 23:27, Florian Viehweger wrote:
> > > Hi ports,
> > > 
> > > I've attached an updated tarball addressing hopefully all the
> > > mentioned issues.
> > > 
> > > Thank you for your input.
> > 
> > In the README you have "${SYSCONFDIR}/inetd.conf", this should just
> > be /etc not ${SYSCONFDIR} because inetd is a system daemon not a
> > ports one. Also some whitespace issues in the relayd config (4
> > spaces then a tab, I think maybe your editor is set to ts=4? the
> > indent is wrong when viewed in a normal terminal). That's in this
> > bit:
> > 
> >     relay "gemini" {
> >             listen on hostname.example port 1965 tls
> >             protocol "gemini"
> >             forward to 127.0.0.1 port 11965
> >     }
> > 
> > Please also add a "uses pledge()" marker near WANTLIB.
> > 
> > > > inetd, really, in 2021?!
> > > 
> > > What is wrong with inetd in this use case?
> > 
> > Executing a new process is relatively resource intensive, most
> > network daemons handling short-lived requests moved away from this
> > model in the 80's-90's. Even the original UM gopher daemon served
> > directly (inetd support wasn't even present in the earlier
> > releases, I would speculate that maybe it was added later so people
> > could run it under the radar without appearing in a typical ps
> > listing ;-)
> > 
> > Also explained in the old NCSA httpd docs (which eventually morphed
> > into Apache but this long pre-dates that change), though I suppose
> > the bit about parsing config isn't relevant for vger:
> > http://cfpm.org/docs/setup/httpd/WhyNotInetd.html
> > 
> > It's not a blocking thing for adding a port but still it's a bit of
> > a surprise since being lightweight seems to be a key point of
> > gemini.
> > 
> 
> Hi,
> just tested the port.
> 
> make
> {fetch,checksum,extract,patch,build,test,fake,port-lib-depends-check}
> works fine.
> 
> However, "make package" and "make install" fail with : 
> 
> ```
> ===>  Building package for vger-1.06
> Create /usr/ports/packages/amd64/all/vger-1.06.tgz
> Creating package vger-1.06
> Error: newgroup _vger: not registered in
> /usr/ports/infrastructure/db/user.list Error: newuser _vger: not
> registered in /usr/ports/infrastructure/db/user.list pkg_create:
> can't continue ```
> 
> Find attached a diff as suggested by @solene to add "_vger" in
> infrastructure/db/user.list.
> 
> Also, find attached an updated tarball according to previous comments.
> 
> Regards.
> 
> prx

Thank you for looking at it. You probably had not seen the diff for
user.list, which I had sent inline.

In the meantime I have sent an updated version with the diff for
user.list as an attachment. This updated version hopefully addresses all
the mentioned issues.

I've run Vger locally without issues on amd64.

-- 
greetings,

Florian Viehweger

Reply via email to