On 2015/01/13 20:39, Bruno Flueckiger wrote: > On 05.01.2015 22:14, Stuart Henderson wrote: > >On 2015/01/05 20:55, Bruno Flueckiger wrote: > >>1. The port is a daemon. And a daemon needs a rc.d script. So I've > >>created one according to > >>http://www.openbsd.org/faq/ports/specialtopics.html#RcScripts > >>I place it in pkg/udpxy.rc and run make plist. This gives me a > >>complain: > >> > >>make-plist: Bogus element outside of every prefix: /etc/rc.d/udpxy > > > >Others addressed the "make plist" issue - but also relating to this, > >it seems this software has some funny behaviour where it automatically > >daemonizes when run by root, but not by a normal user. This is awkward, > >as in general we would like daemons to run as their own userid where > >possible (especially those handling network data), I'm not sure how best > >to handle it in this case - maybe patch, maybe use rc_bg ... > > > >As for setting up the userid to run as, you can take a look at examples > >like telephony/asterisk/pkg/PLIST-main where you'll see an @newuser > >entry in the plist, this adds the new user at pkg_add time. There's a > >file, ports/infrastructure/db/user.list, where you can identify the > >next available uid value. > > > >>Is this the best/right way to do it? > > > >I can live with either method, but in this case (where it seems unlikely > >there will be many changes from upstream in later versions), I think > >do-install is probably simpler. > > > > I've added do-install: to the Makefile and the @rcscript entry in PLIST. > The funny behaviour of the software mentioned by Stuart is another > point. On my test machine I can run it under an unprivileged user > account using rc_bg. So I feel ready to post the port to this list. > > pkg/DESCR: > > udpxy is a UDP-to-HTTP multicast traffic relay daemon: it forwards UDP > traffic from a given multicast subscription to the requesting HTTP > client. > > The port is tested to build and install on i386 and amd64. And I can > confirm that the software works as expected on i386. > > Any feedback is welcome. > > Cheers, > Bruno >
Please drop pkg/SECURITY - we don't use this any more I see no benefit in patching strncpy with an explicit NUL termination to strlcpy, only difficulties in updating if upstream change things in this area. The EPROTO patch segment is needed but I would drop all the others. The "MAKE_FLAGS = GZIP=..." line isn't needed as the install target in upstream's Makefile isn't used COMMENT normally starts with lowercase
