Re: Port of udpxy
Bruno Flueckiger inform...@gmx.net writes:
On 16.01.2015 01:29, Jérémie Courrèges-Anglas wrote:
I would zap it too. But feel free to discuss this with upstream and
work with them to use the safer strl idiom. :)
Even though this API is safer people have done mistakes in ports in the
past.
Please also use http://www.udpxy.com/index-en.html as homepage.
Thanks for your feedback, Jérémie. I've changed the homepage in
Makefile, removed the patches strncpy() - strlcpy() and kept the patch
strcpy() - strlcpy().
*shrug*. No objection about the latter since it looks correct.
Attached is the updated port. Any feedback is welcome!
Improved version:
* respect CFLAGS
* use a dedicated group instead of the default daemon
* don't hardcode /var/log in udpxy.rc but use ${LOCALSTATEDIR}
* while here use the same default port as FreeBSD, else there is no
point setting default daemon_flags
* ensure that we have a writable directory for the logfile in
${LOCALSTATEDIR}/log. @mode annotations for paranoia, they can go
away if people think they're useless
I don't have a way to test this in the field. I think this version is
ready to go in, depending on the feedback and tests.
What do you folks think?
udpxy.tgz
Description: Binary data
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Port of udpxy
j...@wxcvbn.org (Jérémie Courrèges-Anglas) writes:
Bruno Flueckiger inform...@gmx.net writes:
On 16.01.2015 01:29, Jérémie Courrèges-Anglas wrote:
I would zap it too. But feel free to discuss this with upstream and
work with them to use the safer strl idiom. :)
Even though this API is safer people have done mistakes in ports in the
past.
Please also use http://www.udpxy.com/index-en.html as homepage.
Thanks for your feedback, Jérémie. I've changed the homepage in
Makefile, removed the patches strncpy() - strlcpy() and kept the patch
strcpy() - strlcpy().
*shrug*. No objection about the latter since it looks correct.
Attached is the updated port. Any feedback is welcome!
Improved version:
* respect CFLAGS
* use a dedicated group instead of the default daemon
* don't hardcode /var/log in udpxy.rc but use ${LOCALSTATEDIR}
ajacoutot@ pointed out that since /var/log belongs to base, there is no
reason to use the ${LOCALSTATEDIR} abstraction. Updated tarball.
* while here use the same default port as FreeBSD, else there is no
point setting default daemon_flags
* ensure that we have a writable directory for the logfile in
${LOCALSTATEDIR}/log. @mode annotations for paranoia, they can go
away if people think they're useless
I don't have a way to test this in the field. I think this version is
ready to go in, depending on the feedback and tests.
What do you folks think?
udpxy.tgz
Description: Binary data
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Port of udpxy
On 16.01.2015 01:29, Jérémie Courrèges-Anglas wrote: I would zap it too. But feel free to discuss this with upstream and work with them to use the safer strl idiom. :) Even though this API is safer people have done mistakes in ports in the past. Please also use http://www.udpxy.com/index-en.html as homepage. Thanks for your feedback, Jérémie. I've changed the homepage in Makefile, removed the patches strncpy() - strlcpy() and kept the patch strcpy() - strlcpy(). Attached is the updated port. Any feedback is welcome! Cheers, Bruno udpxy.tar.gz Description: application/gzip
Re: Port of udpxy
On 13.01.2015 23:23, Stuart Henderson wrote:
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
Stuart, thank you for the feedback. I rework the port according to it.
After removing all the patches for strncpy() When I run make build now I
get a compiler warning about strcpy() in ctx.c.
Should I keep this patch in the port?
$OpenBSD$
--- ctx.c.orig Thu Jan 15 18:41:32 2015
+++ ctx.c Thu Jan 15 18:42:01 2015
@@ -201,7 +201,7 @@ add_client( struct server_ctx* ctx,
client-mcast_port = mport;
if (ctx-rq.tail[0])
-(void) strcpy( client-tail, ctx-rq.tail );
+(void) strlcpy( client-tail, ctx-rq.tail, sizeof(client-tail) );
rc = get_src_info( client, sockfd );
if( 0 != rc ) {
Cheers,
Bruno
Re: Port of udpxy
Bruno Flueckiger inform...@gmx.net writes:
On 13.01.2015 23:23, Stuart Henderson wrote:
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
Stuart, thank you for the feedback. I rework the port according to it.
After removing all the patches for strncpy() When I run make build now
I get a compiler warning about strcpy() in ctx.c.
Should I keep this patch in the port?
I would zap it too. But feel free to discuss this with upstream and
work with them to use the safer strl idiom. :)
Even though this API is safer people have done mistakes in ports in the
past.
Please also use http://www.udpxy.com/index-en.html as homepage.
$OpenBSD$
--- ctx.c.orig Thu Jan 15 18:41:32 2015
+++ ctx.c Thu Jan 15 18:42:01 2015
@@ -201,7 +201,7 @@ add_client( struct server_ctx* ctx,
client-mcast_port = mport;
if (ctx-rq.tail[0])
-(void) strcpy( client-tail, ctx-rq.tail );
+(void) strlcpy( client-tail, ctx-rq.tail, sizeof(client-tail) );
rc = get_src_info( client, sockfd );
if( 0 != rc ) {
--
jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
Re: Port of udpxy
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 udpxy.tar.gz Description: application/gzip
Re: Port of udpxy
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
Re: Port of udpxy
On 04.01.2015 23:09, Landry Breuil wrote: With what provider did you tested it, was it rtp only or also rtsp ? i might be interested in that, if it allows one to simplify the mess that is streaming multiple channels at the same time to different clients... Also, a port would be welcome :) Landry I've tested it with IPTV from Swisscom (http://www.swisscom.ch). AFAIK they don't make use of RTSP. The streams are delivered by RTP. Every stream from Swisscom has a different multicast IP, so I guess there is no need for RTSP on their side. I start the work on the port. Might take some time to complete because I first have to read the porting guide in depth ;) Bruno
Re: Port of udpxy
On 2015/01/05 15:52, Bruno Flueckiger wrote:
On 04.01.2015 23:09, Landry Breuil wrote:
With what provider did you tested it, was it rtp only or also rtsp ? i
might be interested in that, if it allows one to simplify the mess that
is streaming multiple channels at the same time to different clients...
Also, a port would be welcome :)
Landry
I've tested it with IPTV from Swisscom (http://www.swisscom.ch). AFAIK
they don't make use of RTSP. The streams are delivered by RTP. Every
stream from Swisscom has a different multicast IP, so I guess there is no
need for RTSP on their side.
I start the work on the port. Might take some time to complete because I
first have to read the porting guide in depth ;)
Bruno
Here's a bit to get you started because they use weird naming:
V= 1.0.23-9
DISTNAME= udpxy.$V
EXTRACT_SUFX= -prod.tar.gz
PKGNAME=udpxy-${V:S/-/./}
WRKDIST=${WRKDIR}/udpxy-$V
You'll need to use gmake, and I suggest writing your own do-install
rather than patching upstream's install target to work (in this case
it's a simple target and unlikely to change much in future) - look
for other examples using do-install in the ports tree to crib from.
Re: Port of udpxy
On Mon, Jan 05, 2015 at 03:01:15PM +, Stuart Henderson wrote:
On 2015/01/05 15:52, Bruno Flueckiger wrote:
On 04.01.2015 23:09, Landry Breuil wrote:
With what provider did you tested it, was it rtp only or also rtsp ? i
might be interested in that, if it allows one to simplify the mess that
is streaming multiple channels at the same time to different clients...
Also, a port would be welcome :)
Landry
I've tested it with IPTV from Swisscom (http://www.swisscom.ch). AFAIK
they don't make use of RTSP. The streams are delivered by RTP. Every
stream from Swisscom has a different multicast IP, so I guess there is no
need for RTSP on their side.
I start the work on the port. Might take some time to complete because I
first have to read the porting guide in depth ;)
Bruno
Here's a bit to get you started because they use weird naming:
V= 1.0.23-9
DISTNAME= udpxy.$V
EXTRACT_SUFX= -prod.tar.gz
PKGNAME=udpxy-${V:S/-/./}
WRKDIST=${WRKDIR}/udpxy-$V
You'll need to use gmake, and I suggest writing your own do-install
rather than patching upstream's install target to work (in this case
it's a simple target and unlikely to change much in future) - look
for other examples using do-install in the ports tree to crib from.
There's no need for patching nor do-install.
Just use:
USE_GMAKE= Yes
MAKE_FLAGS= GZIP=/usr/bin/gzip
FAKE_FLAGS= INSTALLROOT=${WRKINST}/${PREFIX} \
MANPAGE_DIR=${WRKINST}/${PREFIX}/man/man1
--
Antoine
Re: Port of udpxy
On 05.01.2015 19:33, Ingo Schwarze wrote: Hi, Antoine Jacoutot wrote on Mon, Jan 05, 2015 at 04:50:38PM +0100: On Mon, Jan 05, 2015 at 03:40:56PM +, Stuart Henderson wrote: On 2015/01/05 16:30, Antoine Jacoutot wrote: Why? We support gzipped manpages just fine. Consistency if nothing else.. That's only because we started supporting gzip'ed manpages not so long ago. Both man(1) and apropos(1) have been supporting them for years, long before both were switched to the mandoc implementation. And that no one bothered removing the patches. But for new ports, I see no reason to patch out for something we support. espie@ does, here is what he told me on June 13, 2014: :: Don't do it. :: :: gzip manuals in packages are a bad idea. :: They store a timestamp within the file proper. :: :: This completely precludes the optimization I'm working on :: wrt pkg_add and updates. Yours, Ingo Thanks for the valuable input. I've made good progress and I'm not almost at the point to send the port to the list. But there are two questions right now: 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 I optimistically ignore it and continue with make package. But the script doesn't get included in the package. What step(s) am I missing to get script included into the package? 2. I've prepared a patch for the Makefile of the software to prevent gzipping of the man pages: $OpenBSD$ --- Makefile.origMon Jan 5 19:33:29 2015 +++ MakefileMon Jan 5 19:34:21 2015 @@ -182,11 +182,13 @@ install: $(EXEC) @cp $(EXEC) $(INSTALLROOT)/bin @ls -l $(INSTALLROOT)/bin/$(EXEC) @mkdir -p -m 755 $(MANPAGE_DIR) -@$(GZIP) -c $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1).gz +#@$(GZIP) -c $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1).gz +@cp $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1) ifneq (yes, $(NO_UDPXREC)) @cp $(UDPXREC) $(INSTALLROOT)/bin/$(UDPXREC) @ls -l $(INSTALLROOT)/bin/$(UDPXREC) -@$(GZIP) -c $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1).gz +#@$(GZIP) -c $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1).gz +@cp $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1) endif @echo Installation of udpxy is complete Is this the best/right way to do it? Cheers, Bruno
Re: Port of udpxy
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
Yeah, that's one of several known issues with update-plist.
You must not trust its output.
I optimistically ignore it and continue with make package. But the
script doesn't get included in the package. What step(s) am I missing to
get script included into the package?
You need to append the following at the end of the PLIST:
@rcscript ${RCDIR}/udpxy
Beware that running make plist again will remove it...
2. I've prepared a patch for the Makefile of the software to prevent
gzipping of the man pages:
$OpenBSD$
--- Makefile.origMon Jan 5 19:33:29 2015
+++ MakefileMon Jan 5 19:34:21 2015
@@ -182,11 +182,13 @@ install: $(EXEC)
@cp $(EXEC) $(INSTALLROOT)/bin
@ls -l $(INSTALLROOT)/bin/$(EXEC)
@mkdir -p -m 755 $(MANPAGE_DIR)
-@$(GZIP) -c $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1).gz
+#@$(GZIP) -c $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1).gz
+@cp $(UDPXY_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXY_MAN1)
ifneq (yes, $(NO_UDPXREC))
@cp $(UDPXREC) $(INSTALLROOT)/bin/$(UDPXREC)
@ls -l $(INSTALLROOT)/bin/$(UDPXREC)
-@$(GZIP) -c $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1).gz
+#@$(GZIP) -c $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1).gz
+@cp $(UDPXREC_MANPAGE_EN) $(MANPAGE_DIR)/$(UDPXREC_MAN1)
endif
@echo Installation of udpxy is complete
Is this the best/right way to do it?
I think Stuart suggested going with a local do-install target directly within
the port Makefile.
Something like:
do-install:
${INSTALL_PROGRAM} ${WRKBUILD}/.../udpxy ${PREFIX}/bin/udpxy
${INSTALL_MAN} ${WRKBUILD}/.../udpxy.1 ${PREFIX}/man/man1/udpxy.1
etc etc
--
Antoine
Re: Port of udpxy
On Mon, Jan 05, 2015 at 08:55:24PM +0100, Bruno Flueckiger wrote:
On 05.01.2015 19:33, Ingo Schwarze wrote:
Hi,
Antoine Jacoutot wrote on Mon, Jan 05, 2015 at 04:50:38PM +0100:
On Mon, Jan 05, 2015 at 03:40:56PM +, Stuart Henderson wrote:
On 2015/01/05 16:30, Antoine Jacoutot wrote:
Why? We support gzipped manpages just fine.
Consistency if nothing else..
That's only because we started supporting gzip'ed manpages
not so long ago.
Both man(1) and apropos(1) have been supporting them for years,
long before both were switched to the mandoc implementation.
And that no one bothered removing the patches. But for new ports,
I see no reason to patch out for something we support.
espie@ does, here is what he told me on June 13, 2014:
:: Don't do it.
::
:: gzip manuals in packages are a bad idea.
:: They store a timestamp within the file proper.
::
:: This completely precludes the optimization I'm working on
:: wrt pkg_add and updates.
Yours,
Ingo
Thanks for the valuable input. I've made good progress and I'm not
almost at the point to send the port to the list. But there are two
questions right now:
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
I optimistically ignore it and continue with make package. But the
script doesn't get included in the package. What step(s) am I missing to
get script included into the package?
you need a special entry in PLIST like @rcscript ${RCDIR}/udpxy for the
script to be included in the package.
Landry
Re: Port of udpxy
Hi, Antoine Jacoutot wrote on Mon, Jan 05, 2015 at 04:50:38PM +0100: On Mon, Jan 05, 2015 at 03:40:56PM +, Stuart Henderson wrote: On 2015/01/05 16:30, Antoine Jacoutot wrote: Why? We support gzipped manpages just fine. Consistency if nothing else.. That's only because we started supporting gzip'ed manpages not so long ago. Both man(1) and apropos(1) have been supporting them for years, long before both were switched to the mandoc implementation. And that no one bothered removing the patches. But for new ports, I see no reason to patch out for something we support. espie@ does, here is what he told me on June 13, 2014: :: Don't do it. :: :: gzip manuals in packages are a bad idea. :: They store a timestamp within the file proper. :: :: This completely precludes the optimization I'm working on :: wrt pkg_add and updates. Yours, Ingo
Re: Port of udpxy
On Mon, Jan 05, 2015 at 03:40:56PM +, Stuart Henderson wrote: On 2015/01/05 16:30, Antoine Jacoutot wrote: Why? We support gzipped manpages just fine. Consistency if nothing else.. That's only because we started supporting gzip'ed manpages not so long ago. And that no one bothered removing the patches. But for new ports, I see no reason to patch out for something we support. $ pkglocate /man/man | grep gz$ | wc -l 1 $ pkglocate /man/man | grep -v gz$ | wc -l 41040 -- Antoine
Re: Port of udpxy
On 2015/01/05 16:09, Antoine Jacoutot wrote:
On Mon, Jan 05, 2015 at 03:01:15PM +, Stuart Henderson wrote:
On 2015/01/05 15:52, Bruno Flueckiger wrote:
On 04.01.2015 23:09, Landry Breuil wrote:
With what provider did you tested it, was it rtp only or also rtsp ? i
might be interested in that, if it allows one to simplify the mess that
is streaming multiple channels at the same time to different clients...
Also, a port would be welcome :)
Landry
I've tested it with IPTV from Swisscom (http://www.swisscom.ch). AFAIK
they don't make use of RTSP. The streams are delivered by RTP. Every
stream from Swisscom has a different multicast IP, so I guess there is no
need for RTSP on their side.
I start the work on the port. Might take some time to complete because I
first have to read the porting guide in depth ;)
Bruno
Here's a bit to get you started because they use weird naming:
V= 1.0.23-9
DISTNAME= udpxy.$V
EXTRACT_SUFX= -prod.tar.gz
PKGNAME=udpxy-${V:S/-/./}
WRKDIST=${WRKDIR}/udpxy-$V
You'll need to use gmake, and I suggest writing your own do-install
rather than patching upstream's install target to work (in this case
it's a simple target and unlikely to change much in future) - look
for other examples using do-install in the ports tree to crib from.
There's no need for patching nor do-install.
Just use:
USE_GMAKE=Yes
MAKE_FLAGS= GZIP=/usr/bin/gzip
FAKE_FLAGS= INSTALLROOT=${WRKINST}/${PREFIX} \
MANPAGE_DIR=${WRKINST}/${PREFIX}/man/man1
We don't want gzipped manpages though, and using ${INSTALL_PROGRAM}
will take care of stripping properly..
Re: Port of udpxy
On 2015/01/05 16:30, Antoine Jacoutot wrote: Why? We support gzipped manpages just fine. Consistency if nothing else.. $ pkglocate /man/man | grep gz$ | wc -l 1 $ pkglocate /man/man | grep -v gz$ | wc -l 41040
Re: Port of udpxy
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.
Port of udpxy
Hi all, An article in c't has brought my attention to udpxy (http://www.udpxy.com/index-en.html). I've successfully compiled it on OpenBSD. Now it runs on my home router and allows me to watch IPTV streams of my provider using VLC on clients in my home network. Is anybody working already on a port for it? If this is not the case I would like to try to create my first port for OpenBSD. Cheers, Bruno
Re: Port of udpxy
On Sun, Jan 04, 2015 at 04:11:13PM +0100, Bruno Flueckiger wrote: Hi all, An article in c't has brought my attention to udpxy (http://www.udpxy.com/index-en.html). I've successfully compiled it on OpenBSD. Now it runs on my home router and allows me to watch IPTV streams of my provider using VLC on clients in my home network. With what provider did you tested it, was it rtp only or also rtsp ? i might be interested in that, if it allows one to simplify the mess that is streaming multiple channels at the same time to different clients... Also, a port would be welcome :) Landry
