minidlna not working with minissdpd
Hello everyone! I'm in trouble with minidlna, installed from pkgs in OpenBSD 5.7 I have installed miniupnpd, minidlna, and minissdpd from packages, added minissdpd_flags=-i em1 in my /etc/rc.conf.local, next i uncommented minissdpdsocket=/var/run/minissdpd.sock in files /etc/miniupnpd.conf and /etc/minidlna.conf and started all daemons in next order: minissdpd - miniupnpd - minidlna and it seems that miniupnpd works and minidlna not :( In other words, it is starting and i can open http://192.168.0.1:8200 but it does not appear on dlna clients Otherwise, if I disable all minissdpd, miniupnpd and start minidlna alone, it works well! If I try to start only minissdpd and minidlna it doesn't work. Here is some log when starting minidlna: [2015/07/12 23:51:16] minidlna.c:1026: warn: Starting MiniDLNA version 1.1.4. [2015/07/12 23:51:16] minissdp.c:114: error: bind(udp): Address already in use [2015/07/12 23:51:16] minidlna.c:1065: warn: HTTP listening on port 8200 [2015/07/12 23:51:16] minissdp.c:80: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor [2015/07/12 23:51:16] minissdp.c:180: warn: Failed to add multicast membership for address 192.168.0.1 Maybe I'm doing something wrong? Or is it a bug?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2015/07/13 02:56:20 ports/sysutils/facter/files Update of /cvs/ports/sysutils/facter/files In directory cvs.openbsd.org:/tmp/cvs-serv3481/files Log Message: Directory /cvs/ports/sysutils/facter/files added to the repository
Re: Vulnerable packages in ports tree 13/07
On 13 July 2015 at 04:10, Gleydson Soares gsoa...@gmail.com wrote: On Sun, Jul 12, 2015 at 11:27 PM, Sevan / Venture37 ventur...@gmail.com wrote: graphics/libwmf - CVE-2015-0848, CVE-2015-4696, CVE-2015-4695, CVE-2015-4588 No. These were already fixed [1]. [1] http://marc.info/?l=openbsd-ports-cvsm=143530877618567w=2 Hi, Appologies, http://openports.se/graphics/libwmf indicated that the package hadn't been updated for some time. Looks like the site stopped updating. Sevan / Venture37
Re: minidlna not working with minissdpd
On h, júl 13, 2015 at 11:14:19 +0300, kasak wrote: Hello everyone! I'm in trouble with minidlna, installed from pkgs in OpenBSD 5.7 I have installed miniupnpd, minidlna, and minissdpd from packages, added minissdpd_flags=-i em1 in my /etc/rc.conf.local, next i uncommented minissdpdsocket=/var/run/minissdpd.sock in files /etc/miniupnpd.conf and /etc/minidlna.conf and started all daemons in next order: minissdpd - miniupnpd - minidlna and it seems that miniupnpd works and minidlna not :( In other words, it is starting and i can open http://192.168.0.1:8200 but it does not appear on dlna clients Otherwise, if I disable all minissdpd, miniupnpd and start minidlna alone, it works well! If I try to start only minissdpd and minidlna it doesn't work. I have the same exact issue with the mini* trio. My setup is a bit more complicated, it involves three network interfaces and a bridge. What is interesting however, is that it seems this is somehow related to the bridge or one of the NIC's drivers, because with bge(4) minissdpd+minidlna works, but with fxp(4)+bridge(4) minissdpd+minidlna does not. The discoveries (multicast) are received from upnp clients, and the advertisements get sent out from minissdpd (run it with debug mode enabled, and you'll see), but somehow they get lost between the software and the hardware. Shame on me, because I didn't debug it further and reported it, but this is an older OBSD 5.5, with an old hardware, and I thought I upgrade both first, and try it out with different NICs and a -current OBSD. However, seeing that someone else already feels the same pain, I thought I'll just chime in... Here is some log when starting minidlna: [2015/07/12 23:51:16] minidlna.c:1026: warn: Starting MiniDLNA version 1.1.4. [2015/07/12 23:51:16] minissdp.c:114: error: bind(udp): Address already in use [2015/07/12 23:51:16] minidlna.c:1065: warn: HTTP listening on port 8200 [2015/07/12 23:51:16] minissdp.c:80: error: setsockopt(udp, IP_ADD_MEMBERSHIP): Bad file descriptor [2015/07/12 23:51:16] minissdp.c:180: warn: Failed to add multicast membership for address 192.168.0.1 Maybe I'm doing something wrong? Or is it a bug? The first error (minissdpd.c:114: error: ...) is actually from minidlna, and if minissdpd is already running, it just confirms that minissdpd already binds to the required address, and minidlna should fall back to the socket that is configured in minidlna.conf to communicate with minissdpd. Running minissdpd with the -d option, and minidlna with -d and -v tells you more information during client discoveries and replies; maybe it will be useful to post those to the list also (at least for just the archives), and I'll try to do the same sometime. Daniel -- LÉVAI Dániel PGP key ID = 0x83B63A8F Key fingerprint = DBEC C66B A47A DFA2 792D 650C C69B BE4C 83B6 3A8F
Re: Vulnerable packages in ports tree 13/07
On 2015/07/13 13:25, Sevan / Venture37 wrote: On 13 July 2015 at 04:10, Gleydson Soares gsoa...@gmail.com wrote: On Sun, Jul 12, 2015 at 11:27 PM, Sevan / Venture37 ventur...@gmail.com wrote: graphics/libwmf - CVE-2015-0848, CVE-2015-4696, CVE-2015-4695, CVE-2015-4588 No. These were already fixed [1]. [1] http://marc.info/?l=openbsd-ports-cvsm=143530877618567w=2 Hi, Appologies, http://openports.se/graphics/libwmf indicated that the package hadn't been updated for some time. Looks like the site stopped updating. Weird, they are showing some updates but not that one...
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2015/07/13 21:21:15 Modified files: security/libnettle: Makefile distinfo security/libnettle/patches: patch-Makefile_in patch-configure security/libnettle/pkg: PLIST Added files: security/libnettle/patches: patch-ecc-point-mul-g_c patch-ecc-random_c patch-getopt_c Removed files: security/libnettle/patches: patch-pkcs1-decrypt_c Log message: Major upgrade to libnettle-3.1.1.
make fake error: option --single-version-externally-managed not recognized
Hi ports@ While trying to update py-serial I'm getting the following error with make fake: error: option --single-version-externally-managed not recognized *** Error 1 in . (/usr/ports/lang/python/python.port.mk:178 'do-install': @cd /usr/ports/pobj/py-serial-2.7/pyserial-2.7 /usr/bin/env -i ...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2848 '/usr/ports/pobj/py-serial-2.7/fake-amd64/.fake_done') *** Error 1 in /usr/ports/devel/py-serial (/usr/ports/infrastructure/mk/bsd.port.mk:2485 'fake') If I comment out --single-version-externally-managed from python.port.mk I can do make fake and make install with no problems. I am missing something obvious? Cheers Fred
Re: duplicity backup to hubic - bunch of new deps
On Sat, Jul 11, 2015 at 4:12 PM, viq vic...@gmail.com wrote: On Fri, Jul 10, 2015 at 7:09 PM, Giovanni Bechis giova...@paclan.it wrote: On 07/09/15 22:20, viq wrote: On Thu, Jul 9, 2015 at 1:14 PM, viq vic...@gmail.com wrote: I pushed a version with equivalent changes to openbsd-wip, if you want to try from there. And here's a patch against CVS. attached a patch that applies on current, py-pyrax do not exist yet; I do not like adding all those deps to duplicity, maybe it would be better to add a README file in which we instruct users that py-pyrax should be installed to be able to play with Hubic. Yeah, that works for me. Maybe even mention other backends there as well, though I think it's at least partially covered in the man page. Anyone? I guess at this moment stage 1, ie let's get updated duplicity into the tree. But I'd appreciate some comments regarding state 2, adding pyrax and deps. -- viq
Re: devel/arm-none-eabi/newlib is broken
On Sun, Jul 12, 2015 at 10:06 PM Nigel Taylor njtay...@asterisk.demon.co.uk
wrote:
On 07/13/15 00:54, Dave Vandervies wrote:
Somebody claiming to be Stuart Henderson wrote:
For some common things (in particular
programs from coreutils) we have scaffolding to prevent autoconf from
picking them up, but the arm-none-eabi ports are too complex for the
normal things to work.
...And, after following up on the suggestions from this thread and
digging around in /usr/ports/infrastructure, I think I've figured out
one of the reasons why and come up with a better quick fix.
Newlib (and binutils and gcc, though they don't have this particular
symptom) does a lot of recursive configuring during the build, and
doesn't do a very good job of passing things the top-level configure
was asked to do down to the sub-configures.
Adding ${CONFIGURE_ENV} to ${MAKE_ENV} so that it affects the environment
that the sub-configures are actually running in persuades them to pick
up the overrides that tell them not to use gmkdir.
Index: Makefile
===
RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 28 May 2015 23:28:26 - 1.1.1.1
+++ Makefile 12 Jul 2015 23:42:48 -
@@ -7,6 +7,13 @@ VERSION= 2.2.0.1
PKGNAME= ${CONFIG}-newlib-${VERSION}
#REVISION= 0
+# The build stage for newlib invokes configure (repeatedly), so make
+# sure the sub-configures run in a suitable environment.
+# Without this, if coreutils is present at configure time, the
+# sub-configures will pick up gmkdir as their preferred concurrency-safe
+# 'mkdir -p'.
+MAKE_ENV+= ${CONFIGURE_ENV}
+
HOMEPAGE=http://sourceware.org/newlib/
MASTER_SITES=ftp://sourceware.org/pub/newlib/
Builds for me, with coreutils uninstalled mid build.
This seems reasonable to me. Does anyone have any objections?
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs
Module name:ports
Changes by: jas...@cvs.openbsd.org 2015/07/13 13:03:19
Modified files:
sysutils/facter: Makefile
sysutils/facter/patches: patch-lib_CMakeLists_txt
patch-lib_src_facts_bsd_filesystem_resolver_cc
Log message:
implement filesystem facts ('mountpoints')
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: jas...@cvs.openbsd.org 2015/07/13 13:28:51 Modified files: sysutils/facter: Makefile sysutils/facter/patches: patch-lib_src_facts_bsd_filesystem_resolver_cc Log message: - previous pushed upstream - list 'noatime' option if a mount has it set
Re: devel/arm-none-eabi/newlib is broken
Somebody claiming to be Antoine Jacoutot wrote:
I think this is less of a hammer:
I went with the bigger hammer to make sure all of the configure overrides
would get through and not just the one that was observed causing problems
when it got lost. But I don't have strong feelings about which side of
that tradeoff is the correct one to take.
Index: Makefile
===
RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile 28 May 2015 23:28:26 - 1.1.1.1
+++ Makefile 13 Jul 2015 16:33:26 -
@@ -25,6 +25,13 @@ USE_GROFF= No
CONFIGURE_ARGS+=--enable-interwork \
--enable-multilib
+# The build stage for newlib invokes configure (repeatedly), so make
+# sure the sub-configures run in a suitable environment.
+# Without this, if coreutils is present at configure time, the
+# sub-configures will pick up gmkdir as their preferred concurrency-safe
+# 'mkdir -p'
+MAKE_ENV += MKDIR_P='mkdir -p'
+
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/newlib
${INSTALL_DATA} ${WRKDIST}/COPYING.NEWLIB \
--
Dave Vandervies
dj3va...@terse.ca / dj3va...@uwaterloo.ca
Plan your future! Make God laugh!
Re: duplicity backup to hubic - bunch of new deps
On 07/13/15 15:50, viq wrote: On Sat, Jul 11, 2015 at 4:12 PM, viq vic...@gmail.com wrote: On Fri, Jul 10, 2015 at 7:09 PM, Giovanni Bechis giova...@paclan.it wrote: On 07/09/15 22:20, viq wrote: On Thu, Jul 9, 2015 at 1:14 PM, viq vic...@gmail.com wrote: I pushed a version with equivalent changes to openbsd-wip, if you want to try from there. And here's a patch against CVS. attached a patch that applies on current, py-pyrax do not exist yet; I do not like adding all those deps to duplicity, maybe it would be better to add a README file in which we instruct users that py-pyrax should be installed to be able to play with Hubic. Yeah, that works for me. Maybe even mention other backends there as well, though I think it's at least partially covered in the man page. Anyone? I guess at this moment stage 1, ie let's get updated duplicity into the tree. But I'd appreciate some comments regarding state 2, adding pyrax and deps. step 1: please test that x11/deja-dup still works correctly Cheers Giovanni
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: z...@cvs.openbsd.org2015/07/13 10:33:03 Modified files: graphics/digikam-kde4: Makefile Log message: Add another missing dependency, that was hiding behind the RUN_DEPENDS curtains. Noticedreminded by nigel@, who was as much kind as possible.
Re: devel/arm-none-eabi/newlib is broken
Index: Makefile
===
RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -r1.1.1.1 Makefile
--- Makefile 28 May 2015 23:28:26 - 1.1.1.1
+++ Makefile 12 Jul 2015 23:42:48 -
@@ -7,6 +7,13 @@ VERSION= 2.2.0.1
PKGNAME= ${CONFIG}-newlib-${VERSION}
#REVISION= 0
+# The build stage for newlib invokes configure (repeatedly), so make
+# sure the sub-configures run in a suitable environment.
+# Without this, if coreutils is present at configure time, the
+# sub-configures will pick up gmkdir as their preferred concurrency-safe
+# 'mkdir -p'.
+MAKE_ENV+= ${CONFIGURE_ENV}
+
HOMEPAGE=http://sourceware.org/newlib/
MASTER_SITES=ftp://sourceware.org/pub/newlib/
Builds for me, with coreutils uninstalled mid build.
This seems reasonable to me. Does anyone have any objections?
I think this is less of a hammer:
Index: Makefile
===
RCS file: /cvs/ports/devel/arm-none-eabi/newlib/Makefile,v
retrieving revision 1.1.1.1
diff -u -p -u -p -r1.1.1.1 Makefile
--- Makefile28 May 2015 23:28:26 - 1.1.1.1
+++ Makefile13 Jul 2015 16:33:26 -
@@ -25,6 +25,13 @@ USE_GROFF= No
CONFIGURE_ARGS+=--enable-interwork \
--enable-multilib
+# The build stage for newlib invokes configure (repeatedly), so make
+# sure the sub-configures run in a suitable environment.
+# Without this, if coreutils is present at configure time, the
+# sub-configures will pick up gmkdir as their preferred concurrency-safe
+# 'mkdir -p'
+MAKE_ENV +=MKDIR_P='mkdir -p'
+
post-install:
${INSTALL_DATA_DIR} ${PREFIX}/share/doc/newlib
${INSTALL_DATA} ${WRKDIST}/COPYING.NEWLIB \
--
Antoine
seamonkey fix
Resubmitting this patch, last sent on May 29th. I've been using
seamonkey on -current/amd64 daily since that time, everything seems to
work fine.
The fix for Mozilla bug 1107063[1], commited upstream, has actually been
reverted in ports (the local patch was reversed, not removed). The
following diff allows seamonkey to start again.
[1] https://bugzilla.mozilla.org/show_bug.cgi?id=1107063
Index: Makefile
===
RCS file: /cvs/ports/www/seamonkey/Makefile,v
retrieving revision 1.173
diff -u -p -r1.173 Makefile
--- Makefile28 May 2015 10:17:25 -1.173
+++ Makefile29 May 2015 21:41:05 -
@@ -11,8 +11,8 @@ MOZILLA_CODENAME =suite
MULTI_PACKAGES =-main -lightning
PKGNAME-main =${PKGNAME}
PKGNAME-lightning =lightning-seamonkey-3.8
-REVISION-main =2
-REVISION-lightning =3
+REVISION-main =3
+REVISION-lightning =4
EPOCH-lightning =0
HOMEPAGE = http://www.seamonkey-project.org/
Index: patches/patch-ldap_sdks_c-sdk_configure_in
===
RCS file: patches/patch-ldap_sdks_c-sdk_configure_in
diff -N patches/patch-ldap_sdks_c-sdk_configure_in
--- patches/patch-ldap_sdks_c-sdk_configure_in16 Mar 2015 20:00:29
-1.8
+++ /dev/null1 Jan 1970 00:00:00 -
@@ -1,13 +0,0 @@
-$OpenBSD: patch-ldap_sdks_c-sdk_configure_in,v 1.8 2015/03/16 20:00:29
landry Exp $
-https://bugzilla.mozilla.org/show_bug.cgi?id=1107063
ldap/sdks/c-sdk/configure.in.origMon Mar 9 06:35:46 2015
-+++ ldap/sdks/c-sdk/configure.inMon Mar 9 19:59:02 2015
-@@ -1823,7 +1823,7 @@ mips-sony-newsos*)
- fi
- DSO_CFLAGS=-fPIC
- USE_NSPR_THREADS=1
--DSO_LDOPTS='-shared -fPIC -Wl,-soname,$(notdir $@)'
-+DSO_LDOPTS='-shared -fPIC'
- ;;
-
- *-openvms*)
Re: make fake error: option --single-version-externally-managed not recognized
On 2015/07/13 14:40, Fred wrote: Hi ports@ While trying to update py-serial I'm getting the following error with make fake: error: option --single-version-externally-managed not recognized *** Error 1 in . (/usr/ports/lang/python/python.port.mk:178 'do-install': @cd /usr/ports/pobj/py-serial-2.7/pyserial-2.7 /usr/bin/env -i ...) *** Error 1 in . (/usr/ports/infrastructure/mk/bsd.port.mk:2848 '/usr/ports/pobj/py-serial-2.7/fake-amd64/.fake_done') *** Error 1 in /usr/ports/devel/py-serial (/usr/ports/infrastructure/mk/bsd.port.mk:2485 'fake') If I comment out --single-version-externally-managed from python.port.mk I can do make fake and make install with no problems. I am missing something obvious? Cheers Fred It is probably no longer a MODPY_SETUPUTILS ports.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: st...@cvs.openbsd.org 2015/07/13 13:48:13 Added files: x11/vlc/patches: patch-bin_Makefile_am Log message: Force LD_PRELOAD=/usr/local/lib/libgobject-2.0.so when running vlc-cache-gen, working around an intermittent crash during build. ok brad@ aja@ robert@ Some of the plugins are linked (indirectly) to gobject. During the generation of the plugin cache, these plugins are loaded and unloaded again. In some circumstances this causes gobject to be unloaded at the wrong time and vlc-cache-gen crashes. (debian bug 752544)
Bulk build error: ruby-capybara-webkit,ruby22 (amd64)
The www/ruby-capybara-webkit,ruby22 port failed to build during the latest amd64 bulk build run. Specifically, it didn't create the bin/webkit_server file and consequently failed to package. Log attached. -- Christian naddy Weisgerber na...@mips.inka.de ruby-capybara-webkit,ruby22.log.gz Description: application/gzip
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2015/07/13 01:02:36 Modified files: mail/evolution : Makefile distinfo Log message: Update to evolution-3.16.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2015/07/13 01:02:14 Modified files: databases/evolution-data-server: Makefile distinfo Log message: Update to evolution-data-server-3.16.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2015/07/13 01:02:54 Modified files: mail/evolution-ews: Makefile distinfo Log message: Update to evolution-ews-3.16.4.
CVS: cvs.openbsd.org: ports
CVSROOT:/cvs Module name:ports Changes by: ajacou...@cvs.openbsd.org 2015/07/13 01:07:48 Modified files: security/gnutls: Makefile distinfo Log message: Bug-fix update to gnutls-3.3.16.
