mplayer options patch
mplayer fails on ia64 portscluster:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile2010-12-03 03:38:31.0 +
+++ Makefile.new2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
+OPTIONS+= RTCPU Allow runtime CPU detection off
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
Fri, Jan 07, 2011 at 09:58:17AM +, Anton Shterenlikht wrote:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile 2010-12-03 03:38:31.0 +
+++ Makefile.new 2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+=RTCPU Allow runtime CPU detection on
+OPTIONS+=RTCPU Allow runtime CPU detection off
OPTIONS+=OCFLAGS Use optimized compiler flags on
OPTIONS+=IPV6 Include inet6 network support on
OPTIONS+=X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
Please, try the following snippet:
{{{
.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
OPTIONS+= RTCPU Allow runtime CPU detection on
.else
OPTIONS+= RTCPU Allow runtime CPU detection off
.endif
}}}
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpFg3IMvCRy7.pgp
Description: PGP signature
Re: mplayer options patch
On Fri, Jan 07, 2011 at 01:15:21PM +0300, Eygene Ryabinkin wrote:
Fri, Jan 07, 2011 at 09:58:17AM +, Anton Shterenlikht wrote:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile2010-12-03 03:38:31.0 +
+++ Makefile.new2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
+OPTIONS+= RTCPU Allow runtime CPU detection off
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
Please, try the following snippet:
{{{
.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
OPTIONS+= RTCPU Allow runtime CPU detection on
.else
OPTIONS+= RTCPU Allow runtime CPU detection off
.endif
}}}
good idea. Here's the full patch:
--- Makefile2010-12-02 09:18:00.0 +
+++ Makefile.new2011-01-07 11:16:56.0 +
@@ -13,7 +13,6 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
@@ -75,6 +74,12 @@
BROKEN=Does not compile on sparc64
.endif
+.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
+OPTIONS+= RTCPU Allow runtime CPU detection on
+.else
+OPTIONS+= RTCPU Allow runtime CPU detection off
+.endif
+
CONFIGURE_ARGS+= --disable-ssse3 \
--disable-directfb \
--disable-faac \
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
Eygene Ryabinkin r...@freebsd.org writes:
Fri, Jan 07, 2011 at 09:58:17AM +, Anton Shterenlikht wrote:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile 2010-12-03 03:38:31.0 +
+++ Makefile.new 2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS=DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
+OPTIONS+= RTCPU Allow runtime CPU detection off
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
Please, try the following snippet:
{{{
.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
OPTIONS+= RTCPU Allow runtime CPU detection on
.else
OPTIONS+= RTCPU Allow runtime CPU detection off
.endif
}}}
ARCH is not defined before bsd.port.options.mk. Try to set it
.if !defined(ARCH)
ARCH ?= ${MACHINE} # uname -p == hw.machine
.endif
or there'd be an error
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 || ${ARCH} ==
amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
On Fri, Jan 07, 2011 at 02:41:21PM +0300, Anonymous wrote:
Eygene Ryabinkin r...@freebsd.org writes:
Fri, Jan 07, 2011 at 09:58:17AM +, Anton Shterenlikht wrote:
Error: Runtime CPU detection only works for x86, x86-64 and PPC!
Here's a patch:
--- Makefile 2010-12-03 03:38:31.0 +
+++ Makefile.new 2011-01-07 09:38:50.0 +
@@ -13,7 +13,7 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
+OPTIONS+= RTCPU Allow runtime CPU detection off
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
It would be better to make it conditional on ARCH, but
I don't know how to do it.
Please, try the following snippet:
{{{
.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
OPTIONS+= RTCPU Allow runtime CPU detection on
.else
OPTIONS+= RTCPU Allow runtime CPU detection off
.endif
}}}
ARCH is not defined before bsd.port.options.mk. Try to set it
.if !defined(ARCH)
ARCH ?= ${MACHINE} # uname -p == hw.machine
.endif
or there'd be an error
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 || ${ARCH} ==
amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
I put Eygene's snippet after .include bsd.port.pre.mk,
see my previous post. It seems to work.
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently marked broken
On Fri, Jan 07, 2011 at 08:29:10AM +0100, lini...@freebsd.org wrote: portname: math/dislin broken because: size mismatch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=mathportname=dislin Is this a security concern? I've never used this port before, but it looks intersting. By doing rm distinfo* make makesum I can install this port. Is this not a good idea? However, it seems the binaries provided (to get the sources one has to buy a licence) are only for i386: from ftp://ftp.gwdg.de/pub/grafik/dislin/unix/README.UNX -- | File Computer/Oper.-SystemCompiler | -- || | dislin-10.0.fbsd.tar.gz IBM-PC / FreeBSD 8.x gcc, f2c, f77, | | Perl, Python | || || | dislin-10.0.fbsd-5.4.tar.gz IBM-PC / FreeBSD 5.x gcc, f2c, f77, | | Perl, Python | || || | dislin-10.0.fbsd-6.0.tar.gz IBM-PC / FreeBSD 6.x gcc, f2c, f77, | | Perl, Python | || || | dislin-10.0.fbsd-7.0.tar.gz IBM-PC / FreeBSD 7.x gcc, f2c, f77, | | Perl, Python | || Should there be an ONLY_FOR_ARCHS defined for this port then? -- Anton Shterenlikht Room 2.6, Queen's Building Mech Eng Dept Bristol University University Walk, Bristol BS8 1TR, UK Tel: +44 (0)117 331 5944 Fax: +44 (0)117 929 4423 ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
Anton Shterenlikht me...@bristol.ac.uk writes:
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 || ${ARCH}
== amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
I put Eygene's snippet after .include bsd.port.pre.mk,
see my previous post. It seems to work.
bsd.port.pre.mk starts after OPTIONS were already parsed.
Try to check
$ make rmconfig
$ make -V WITH_RTCPU ARCH=sparc64
true
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
On Fri, Jan 07, 2011 at 03:00:39PM +0300, Anonymous wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 || ${ARCH}
== amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
I put Eygene's snippet after .include bsd.port.pre.mk,
see my previous post. It seems to work.
bsd.port.pre.mk starts after OPTIONS were already parsed.
Try to check
$ make rmconfig
$ make -V WITH_RTCPU ARCH=sparc64
true
# make rmconfig
=== Removing user-configured options for mplayer-1.0.r20101106
rmdir: /var/db/ports/mplayer: Directory not empty
*** Error code 1 (ignored)
# make -V WITH_RTCPU ARCH=sparc64
# make -V WITH_RTCPU ARCH=ia64
#
those are empty lines of output.
On my ia64 I get in the dialog:
*skip*
| |[ ] LIBLZOEnable external liblzo library
| |
| |[ ] JOYSTICK Enable joystick support
| |
| |[ ] V4L Enable Video4Linux TV support
| |
| |[ ] RTCPU Allow runtime CPU detection
| |
+-++-+
| [ OK ] Cancel
|
++
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
Anton Shterenlikht me...@bristol.ac.uk writes:
On Fri, Jan 07, 2011 at 03:00:39PM +0300, Anonymous wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 ||
${ARCH} == amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
I put Eygene's snippet after .include bsd.port.pre.mk,
see my previous post. It seems to work.
bsd.port.pre.mk starts after OPTIONS were already parsed.
Try to check
$ make rmconfig
$ make -V WITH_RTCPU ARCH=sparc64
true
# make rmconfig
=== Removing user-configured options for mplayer-1.0.r20101106
rmdir: /var/db/ports/mplayer: Directory not empty
*** Error code 1 (ignored)
# make -V WITH_RTCPU ARCH=sparc64
# make -V WITH_RTCPU ARCH=ia64
#
My bad, I forgot to remove RTCPU when added the ifdef.
$ make -V WITH_RTCPU ARCH=sparc64
$ make -V WITHOUT_RTCPU ARCH=sparc64
$ make -V CONFIGURE_ARGS ARCH=sparc64 | fgrep run
... --enable-runtime-cpudetection ... ${_LATE_CONFIGURE_ARGS}
It's not only for sparc64, there is no WITH/WITHOUT_RTPCU for i386.
But the configure option still works
.if !defined(WITHOUT_RTCPU)
CONFIGURE_ARGS+=--enable-runtime-cpudetection
.endif
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
On Fri, Jan 07, 2011 at 03:28:44PM +0300, Anonymous wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
On Fri, Jan 07, 2011 at 03:00:39PM +0300, Anonymous wrote:
Anton Shterenlikht me...@bristol.ac.uk writes:
$ make config
Makefile, line 16: Malformed conditional (${ARCH} == i386 ||
${ARCH} == amd64 || ${ARCH} == powerpc)
Makefile, line 18: if-less else
Makefile, line 20: if-less endif
make: fatal errors encountered -- cannot continue
I put Eygene's snippet after .include bsd.port.pre.mk,
see my previous post. It seems to work.
bsd.port.pre.mk starts after OPTIONS were already parsed.
Try to check
$ make rmconfig
$ make -V WITH_RTCPU ARCH=sparc64
true
# make rmconfig
=== Removing user-configured options for mplayer-1.0.r20101106
rmdir: /var/db/ports/mplayer: Directory not empty
*** Error code 1 (ignored)
# make -V WITH_RTCPU ARCH=sparc64
# make -V WITH_RTCPU ARCH=ia64
#
My bad, I forgot to remove RTCPU when added the ifdef.
$ make -V WITH_RTCPU ARCH=sparc64
$ make -V WITHOUT_RTCPU ARCH=sparc64
$ make -V CONFIGURE_ARGS ARCH=sparc64 | fgrep run
... --enable-runtime-cpudetection ... ${_LATE_CONFIGURE_ARGS}
It's not only for sparc64, there is no WITH/WITHOUT_RTPCU for i386.
But the configure option still works
.if !defined(WITHOUT_RTCPU)
CONFIGURE_ARGS+=--enable-runtime-cpudetection
.endif
I don't think I need to change any other options from
the current default to make it build and run on my ia64.
So if this patch seems reasonable, can somebody submit it?
many thanks
anton
--- Makefile2010-12-02 09:18:00.0 +
+++ Makefile.new2011-01-07 11:16:56.0 +
@@ -13,7 +13,6 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+= RTCPU Allow runtime CPU detection on
OPTIONS+= OCFLAGS Use optimized compiler flags on
OPTIONS+= IPV6 Include inet6 network support on
OPTIONS+= X11 Enable X11 support for mplayer's video output on
@@ -75,6 +74,12 @@
BROKEN=Does not compile on sparc64
.endif
+.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
+OPTIONS+= RTCPU Allow runtime CPU detection on
+.else
+OPTIONS+= RTCPU Allow runtime CPU detection off
+.endif
+
CONFIGURE_ARGS+= --disable-ssse3 \
--disable-directfb \
--disable-faac \
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
clamav makefile patch
clamav fails configure on ia64 portscluster because
LLVM is included in default options:
from
http://pointyhat.freebsd.org/errorlogs/ia64-errorlogs/e.8.20101230091827/clamav-0.96.5_1.log
configure: error: Failed to configure LLVM, and LLVM was explicitly requested
With this patch it builds fine on my ia64 box.
--- Makefile2010-12-16 17:43:46.0 +
+++ Makefile.new2011-01-07 13:52:26.0 +
@@ -140,7 +140,7 @@
CONFIGURE_ARGS+=--without-iconv
.endif
-.if defined(WITH_LLVM) ${ARCH} != sparc64
+.if defined(WITH_LLVM) ${ARCH} != sparc64 ${ARCH} != ia64
CONFIGURE_ARGS+=--enable-llvm
USE_GMAKE= yes
. if defined(WITH_TESTS)
However, LLVM probably doesn't build on PPC either, so
it might be better to use something like
.if defined(WITH_LLVM) ${ARCH} == i386 | ${ARCH} == amd64
--
Anton Shterenlikht
Room 2.6, Queen's Building
Mech Eng Dept
Bristol University
University Walk, Bristol BS8 1TR, UK
Tel: +44 (0)117 331 5944
Fax: +44 (0)117 929 4423
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: mplayer options patch
Fri, Jan 07, 2011 at 01:32:39PM +, Anton Shterenlikht wrote:
I don't think I need to change any other options from
the current default to make it build and run on my ia64.
So if this patch seems reasonable, can somebody submit it?
many thanks
anton
--- Makefile 2010-12-02 09:18:00.0 +
+++ Makefile.new 2011-01-07 11:16:56.0 +
@@ -13,7 +13,6 @@
.include ${.CURDIR}/Makefile.shared
OPTIONS= DEBUG Include debug symbols in mplayer's binaries off
-OPTIONS+=RTCPU Allow runtime CPU detection on
OPTIONS+=OCFLAGS Use optimized compiler flags on
OPTIONS+=IPV6 Include inet6 network support on
OPTIONS+=X11 Enable X11 support for mplayer's video output on
@@ -75,6 +74,12 @@
BROKEN= Does not compile on sparc64
.endif
+.if ${ARCH} == i386 || ${ARCH} == amd64 || ${ARCH} == powerpc
+OPTIONS+= RTCPU Allow runtime CPU detection on
+.else
+OPTIONS+= RTCPU Allow runtime CPU detection off
+.endif
Having thinked about it for a while, I wonder if we need to have
RTCPU knob on non-{i386,amd64,powerpc}? From the one hand, the
knob isn't functional, so it is redundant, because mplayer will
refuse to build. On the other hand, once mplayer will gain the
ability to make run-time CPU detection on other platforms, this
knob will be usable again and it will be good to add it to the
relevant architectures.
I think that this should be left to the maintainers decision.
Please, submit a PR that describes the problem and contains
the patch. If submitting PR is something you hadn't done before,
please, take a look at
http://www.freebsd.org/doc/en_US.ISO8859-1/articles/problem-reports/article.html
You can add me to the X-GNATS-Notify header -- I'll take the PR
and once/if Thomas will approve it, I'll commit the modifications.
--
Eygene Ryabinkin,,,^..^,,,
[ Life's unfair - but root password helps! | codelabs.ru ]
[ 82FE 06BC D497 C0DE 49EC 4FF0 16AF 9EAE 8152 ECFB | freebsd.org ]
pgpRMftPbUoMb.pgp
Description: PGP signature
Re: FreeBSD ports which are currently marked forbidden
On 2011-01-07 08:29, lini...@freebsd.org wrote: As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users about ports that are marked as forbidden in their Makefiles. Often, these ports are so marked due to security concerns, such as known exploits. An overview of each port, including errors seen on the build farm, is included below. portname: databases/gnats forbidden because: Security issues build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databasesportname=gnats I wonder about the old gants port. Do we use parts of this port somewhere (OS/freefall...)? The port is now marked since nearly 7 years as forbidden/broken, was scheduled to expire (2004-08-20) which was removed 5 years ago with the following comment. - Remove expiration date, this port is not going away yet ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
ldconfig -r does not show devel/sfml libraries
Hello, I'm writing a patch for emulators/visualboyadvance-m because it needs libsfml as LIB_DEPENDS and not only BUILD_DEPENDS. The problem is that ldconfig -r does not show the libsfml libraries so I can't actually add a correct LIB_DEPEND line see : mark...@melon ...ators/visualboyadvance-m $ ldconfig -r | grep libsfml mark...@melon ...ators/visualboyadvance-m $ mark...@melon ...ators/visualboyadvance-m $ ls /usr/local/lib/libsfml-* /usr/local/lib/libsfml-audio.so /usr/local/lib/libsfml-graphics.so.1.6 /usr/local/lib/libsfml-system.so /usr/local/lib/libsfml-window.so.1.6 /usr/local/lib/libsfml-audio.so.1.6/usr/local/lib/libsfml-network.so /usr/local/lib/libsfml-system.so.1.6 /usr/local/lib/libsfml-graphics.so /usr/local/lib/libsfml-network.so.1.6 /usr/local/lib/libsfml-window.so the weird thing is that ldconfig -m is ran after the devel/sfml install. What can I do to fix? Kind regards, -- David Demelier ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ldconfig -r does not show devel/sfml libraries
On Jan 7, 2011, at 10:40 AM, David Demelier wrote: [ ... ] the weird thing is that ldconfig -m is ran after the devel/sfml install. What can I do to fix? If you cat /var/run/ld-elf.so.hints, does /usr/local/lib appear in the list of paths? (Yeah, this is a mildly binary file, but...) Does running ldconfig -R do anything helpful? Regards, -- -Chuck ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 2011-01-07 01:49, Doug Barton wrote:
On 01/05/2011 01:14, Douglas Thrift wrote:
Hello,
Since ISC dhcpd 4.1 now supports DHCPv6, but a single instance of the
daemon can't do both IPv4 DHCP and DHCPv6, it would be nice if the rc.d
script from the port could be configured to start the daemon twice. Has
anyone thought about this at all or implemented anything?
I really dislike this trend that we're seeing of individual rc.d scripts
supporting running multiple versions of the same daemon, but I haven't yet
found
the time to write it up for TPH. The canonical way to do this is for the rc.d
script to have multiple copies of itself, and then do something like:
name=${0##*/}
For this example you could have the port install rc.d/dhcpd by default (or
whatever the name is, not suggesting a change), and an option to also install
dhcpd_v6 (perhaps as a symlink). This would make it easy to clean up as the
additional copy of the script should also be in the plist.
The other reason I haven't squawked more about this is that for services that
would like to be able to run an arbitrary number of the same daemon the
servicename_N_{flags|pidfile|etc} method works, and eliminates the problem of
leaving behind multiple numbers of the script after port deinstall. But for
something like this where we're discussing a fixed (and small) number of
copies
it's better to have this done the right way.
hth,
Doug
Maybe something like the apache22 rc script will work.
Apache22 can start more than one instance and it is easy to control
all or only a single instance with the apache rc script.
And the best, it works without links
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: ldconfig -r does not show devel/sfml libraries
David Demelier demelier.da...@gmail.com writes:
Hello,
I'm writing a patch for emulators/visualboyadvance-m because it needs
libsfml as LIB_DEPENDS and not only BUILD_DEPENDS.
The problem is that ldconfig -r does not show the libsfml libraries so
Let's look at other lines in `ldconfig -r' output, e.g.
$ ldconfig -r | fgrep cairomm
185:-lcairomm-1.0.1 = /usr/local/lib/libcairomm-1.0.so.1
So, appling same logic to
LIB_DEPENDS = sfml-system.1.6:${PORTSDIR}/devel/sfml
it'd check libsfml-system.1.so.6 and not libsfml-system.so.1.6.
$ mv libsfml-system.so.1.6 libsfml-system.1.so.6
$ ldconfig -m /usr/local/lib
$ ldconfig -r | fgrep sfml
268:-lsfml-system.1.6 = /usr/pkg/lib/libsfml-system.1.so.6
$ make lib-depends
=== visualboyadvance-m-1.8.0r966 depends on shared library: png.6 - found
=== visualboyadvance-m-1.8.0r966 depends on shared library:
sfml-system.1.6 - found
...
Try workaround in below diff, it uses -lsfml-system.1, though.
Index: devel/sfml/pkg-plist
===
RCS file: /a/.cvsup/ports/devel/sfml/pkg-plist,v
retrieving revision 1.2
diff -u -p -r1.2 pkg-plist
--- devel/sfml/pkg-plist 1 Sep 2010 18:05:18 - 1.2
+++ devel/sfml/pkg-plist 7 Jan 2011 19:54:39 -
@@ -72,15 +72,15 @@ include/SFML/Window/WindowListener.hpp
include/SFML/Window/WindowSettings.hpp
include/SFML/Window/WindowStyle.hpp
lib/libsfml-audio.so
-lib/libsfml-audio.so.1.6
+lib/libsfml-audio.so.1
lib/libsfml-graphics.so
-lib/libsfml-graphics.so.1.6
+lib/libsfml-graphics.so.1
lib/libsfml-network.so
-lib/libsfml-network.so.1.6
+lib/libsfml-network.so.1
lib/libsfml-system.so
-lib/libsfml-system.so.1.6
+lib/libsfml-system.so.1
lib/libsfml-window.so
-lib/libsfml-window.so.1.6
+lib/libsfml-window.so.1
@dirrm include/SFML/Window
@dirrm include/SFML/System/Win32
@dirrm include/SFML/System/Unix
Index: devel/sfml/files/patch-src-SFML-Makefile
===
RCS file: /a/.cvsup/ports/devel/sfml/files/patch-src-SFML-Makefile,v
retrieving revision 1.2
diff -u -p -r1.2 patch-src-SFML-Makefile
--- devel/sfml/files/patch-src-SFML-Makefile 1 Sep 2010 18:05:18 - 1.2
+++ devel/sfml/files/patch-src-SFML-Makefile 7 Jan 2011 19:53:49 -
@@ -24,7 +24,8 @@
+export CXXFLAGS += -W -Wall -pedantic -I../../../include -I../../ $(DEBUGFLAGS) $(BUILDFLAGS) -I${LOCALBASE}/include -I${LOCALBASE}/include/freetype2
+export LDFLAGS= -L${LOCALBASE}/lib $(LINKFLAGS)
export LIBPATH= ../../../lib
- export VERSION= 1.6
+-export VERSION= 1.6
++export VERSION= 1
export CP = cp
@@ -27,9 +27,9 @@
export LNFLAGS= -s -f
Index: emulators/visualboyadvance-m/Makefile
===
RCS file: /a/.cvsup/ports/emulators/visualboyadvance-m/Makefile,v
retrieving revision 1.3
diff -u -p -r1.3 Makefile
--- emulators/visualboyadvance-m/Makefile 13 Dec 2010 09:34:22 - 1.3
+++ emulators/visualboyadvance-m/Makefile 7 Jan 2011 19:55:14 -
@@ -14,8 +14,8 @@ MASTER_SITES= http://update.cooltrainer.
MAINTAINER= r...@cooltrainer.org
COMMENT= Game Boy Advance emulator with GTK frontend
-BUILD_DEPENDS= ${LOCALBASE}/lib/libsfml-system.so:${PORTSDIR}/devel/sfml
LIB_DEPENDS= png.6:${PORTSDIR}/graphics/png \
+ sfml-system.1:${PORTSDIR}/devel/sfml \
cairomm-1.0.1:${PORTSDIR}/graphics/cairomm
OPTIONS= GVBAM Build gvbam (GTK2 frontend) on \
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Perhatian Mendesak, Perlu Anda Asisten.
Hai, Nama saya Maria Susanto 39yrs saya berasal dari Indonesia, dan menikah dengan Mr Marc Joeseph. dan saya memiliki dua anak dari pernikahan kami dan kami tinggal di Britania Raya (London), akan tetapi suatu musibah datang kepada keluarga saya dan saya kehilangan suami saya tercinta yang sangat saya sayangi dalam mengalami musibah kecelakaan yang sangat fatal yang mengakibatkan suami saya meninggal dunia dan meninggalkan saya dan juga ke 2 anak saya untuk selamanya. Setelah mengalami musibah ini permasalahan nya adalah saya ingin memperjuangkan hak asasi saya selayak nya saya seorang istri yang harus saya perjuangkan dan saya pun mempunyai keluarga di Indonesia akan tetapi semua keluarga saya tidak mengetahui bahwa saya sudah menikah dengan suami saya (almarhum). karena saya sudah hamil dan keluarga saya menolak saya tidak mengakui saya ketika mereka tahu bahwa saya hamil dari dia suami saya ( almarhum), karena itulah sebabnya saya tidak ingin menghubungi mereka / keluarga saya untuk masalah ini, dan sekarang saudara suami adik saya, dan keluarga yang lain dengan suami saya mereka mencoba untuk mengklaim segala sesuatu yang seharusnya milik saya dari suami saya. Dari itu saya menulis surat ini kepada Anda untuk meminta kerjasama / membantu dan menolong saya untuk dapat saya memperjuang hak asasi saya dan suami saya dan karena itu pula saya sangat berharap besar dapat menemukan seseorang untuk membantu/menolong saya yang dapat bisa dipercaya akan membantu/menolong saya untuk menerima jumlah uang dan sebuah proparty yang sekarang berada di sebuah perusahaan keamanan di sini (UK). karena jika keluarga suami saya mengetahui tentang hal ini mereka akan mengklaim semua segala sesuatu nya dan tinggalkan saya handless. Ini adalah Legal dan saya sudah membuat perjanjian dengan perusahaan jasa keamanan untuk kesepakatan yang akan membuat dana relokasi ke alamat anda dengan diplomasi sopan, sebagai bagasi diplomatik untuk menghindari serangan dan gangguan apa pun. Saya akan senang jika Anda dapat berdiri dan menerima dana ini di negara kita sendiri di Indonesia atas nama keluarga saya dan anak saya sangat bersyukur sekali jika menemukan seseorang menolong saya, setelah itu saya akan mengatur untuk saya kembali ke Indonesia setelah semua urusan keluarga dengan suami saya selesai. Apapun cara yang Anda lakukan untuk membantu/menolong saya sangat saya hargai dengan sangat hormat. Semoga Tuhan memberkati Anda selalu dalam lindungan nya. Jika Anda tertarik dan dapat memberikan usul/saran yang saya alami ini, Anda tidak perlu ragu dan sungkan kapan saja anda dapat menghubungi saya , dan saya menawarkan anda beberapa% dari total semua. Saya selalu menunggu jawaban positif Anda mendesak. Silakan Anda menghubungi saya langsung ke mail pribadi saya: m-susan...@hotmail.com Salam, Maria Susanto ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
stunnel transparent proxy
Folks, Would it be possible to devise an ipfw 'fwd' rule to pass along a socket connection with IP_BINDANY set via stunnel that forwards it to another process? The problem I'm having is the vnc service on the other side cannot reply back to the IP address because the routing does not redirect back through stunnel. I am testing configurations using apache (port 80 and 443) for convenience. Request : ext ip - stunnel - vnc svc Response : vnc svc X-ext ip instead of : vnc svc - stunnel - ext ip With stunnel's transparent set option traffic looks like : 19:31:34.162337 IP 192.168.103.69.52671 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7437993 ecr 0], length 0 19:31:37.153079 IP 192.168.103.69.52671 127.0.0.1.80: Flags [S], snip.. 19:31:40.351804 IP 192.168.103.69.52671 127.0.0.1.80: Flags [S], snip .. 19:31:43.550543 IP 192.168.103.69.52671 127.0.0.1.80: Flags [S], seq 2050938762, win 65535, options [mss 16344,sackOK,eol], length 0 Without transparent, traffic flows fine, and looks like : 19:32:55.883404 IP 127.0.0.1.30326 127.0.0.1.80: Flags [S], seq 2147354729, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 7446169 ecr 0], length 0 19:32:55.883575 IP 127.0.0.1.80 127.0.0.1.30326: Flags [S.], seq 2770470513, ack 2147354730, win 65535, options [mss 16344,nop,wscale 3,sackOK,TS val 1229815108 ecr 7446169], length 0 19:32:55.883589 IP 127.0.0.1.30326 127.0.0.1.80: Flags [.], ack 1, win 8960, options [nop,nop,TS val 7446169 ecr 1229815108], length 0 ... I did try and devise pf rules to redirect or rdr and nat, but neither worked. I am only vaguely familiar with ipfw, and from some of my research led me to believe it may be possible. Thanks P.S. I did post the same question earlier on freebsd-pf list as well. http://lists.freebsd.org/pipermail/freebsd-pf/2011-January/005914.html ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 01/07/2011 11:57, Olli Hauer wrote: Maybe something like the apache22 rc script will work. Apache22 can start more than one instance and it is easy to control all or only a single instance with the apache rc script. And the best, it works without links With respect to those involved, the apache scripts are a good example of what I don't want more examples of. Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Fri, Jan 07, 2011 at 12:04:20PM -0800, Doug Barton wrote: On 01/07/2011 11:57, Olli Hauer wrote: Maybe something like the apache22 rc script will work. Apache22 can start more than one instance and it is easy to control all or only a single instance with the apache rc script. And the best, it works without links With respect to those involved, the apache scripts are a good example of what I don't want more examples of. I agree. It's extra complexity that can be solved with a simple solution like the one Doug proposed. -- WXS ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 01/06/2011 21:16, Freddie Cash wrote:
The OpenVPN port does a pretty good job of this. Default rc.d script
is just openvpn. But you can create manual symlinks to it using
openvpn_somename, and it checks rc.conf for openvpn_somename_enable.
Having to manually create the symlink is kind of needed in the openvpn
setup and can lead to left-over files on port removal, but wouldn't be
needed for dhcpd.
Might want to look through the openvpn rc script for ideas.
Yeah, I'm actually kind of embarrassed that I didn't mention that
explicitly, since I was working with openvpn the other day. :) The
script can be simplified with the attached patch. The eval's are a
necessary evil without some other mechanism for setting the defaults.
The patch also removes the default empty variable assignments which are
never necessary or desirable.
hth,
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
Index: openvpn.sh.in
===
RCS file: /home/pcvs/ports/security/openvpn/files/openvpn.sh.in,v
retrieving revision 1.14
diff -u -r1.14 openvpn.sh.in
--- openvpn.sh.in 4 Aug 2010 19:53:56 - 1.14
+++ openvpn.sh.in 7 Jan 2011 20:25:58 -
@@ -31,7 +31,7 @@
# -
#
# This script supports running multiple instances of openvpn.
-# To run additional instance link this script to something like
+# To run additional instances link this script to something like
# % ln -s openvpn openvpn_foo
# and define additional openvpn_foo_* variables in one of
# /etc/rc.conf, /etc/rc.conf.local or /etc/rc.conf.d/openvpn_foo
@@ -63,25 +63,13 @@
. /etc/rc.subr
-case $0 in
-/etc/rc*)
- # during boot (shutdown) $0 is /etc/rc (/etc/rc.shutdown),
- # so get the name of the script from $_file
- name=$(basename $_file .sh)
- ;;
-*)
- name=$(basename $0 .sh)
- ;;
-esac
+name=${0%%*/}
rcvar=$(set_rcvar)
openvpn_precmd()
{
for i in $interfaces ; do
- # FreeBSD = 5.4 does not know kldstat's -m option
- # FreeBSD = 6.0 does not add debug.* sysctl information
- # in the default build - we check both to keep things simple
if ! sysctl debug.if_${i}_debug /dev/null 21 \
! kldstat -m if_${i} /dev/null 21 ; then
if ! kldload if_${i} ; then
@@ -123,8 +111,6 @@
load_rc_config ${name}
eval : \${${name}_enable:=\NO\}
-eval : \${${name}_flags:=\\}
-eval : \${${name}_if:=\\}
eval : \${${name}_configfile:=\%%PREFIX%%/etc/openvpn/${name}.conf\}
eval : \${${name}_dir:=\%%PREFIX%%/etc/openvpn\}
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 01/07/2011 02:04 PM, Doug Barton wrote: On 01/07/2011 11:57, Olli Hauer wrote: Maybe something like the apache22 rc script will work. Apache22 can start more than one instance and it is easy to control all or only a single instance with the apache rc script. And the best, it works without links With respect to those involved, the apache scripts are a good example of what I don't want more examples of. Hi Doug, I think (imho) the apache style scripts are better than the one in openvpn for example. The main reason for this is that they are more along the lines of how other platforms have implemented this feature. Ubuntu/debian uses an init.d script with the same semantics as the apache script except its definition of a profile is a file with a .conf extension in /etc/openvpn/. Maybe we need a more generic way of doing this rather than each port providing their own implementation? Tom This is my slightly biased opinion as I am the author of one such script in the tree. -- TJU13-ARIN ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
Sorry for replying to my own message and top posing. I wanted to note that this is relation to general /profile/ type rc scripts and really has no relation to how the dhcpd one should be changed. On 01/07/2011 02:46 PM, Tom Judge wrote: On 01/07/2011 02:04 PM, Doug Barton wrote: On 01/07/2011 11:57, Olli Hauer wrote: Maybe something like the apache22 rc script will work. Apache22 can start more than one instance and it is easy to control all or only a single instance with the apache rc script. And the best, it works without links With respect to those involved, the apache scripts are a good example of what I don't want more examples of. Hi Doug, I think (imho) the apache style scripts are better than the one in openvpn for example. The main reason for this is that they are more along the lines of how other platforms have implemented this feature. Ubuntu/debian uses an init.d script with the same semantics as the apache script except its definition of a profile is a file with a .conf extension in /etc/openvpn/. Maybe we need a more generic way of doing this rather than each port providing their own implementation? Tom This is my slightly biased opinion as I am the author of one such script in the tree. -- TJU13-ARIN ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently marked forbidden
On Fri, Jan 07, 2011 at 04:18:49PM +0100, Olli Hauer wrote: I wonder about the old gants port. Do we use parts of this port somewhere (OS/freefall...)? freefall, yep. It's our main GNATS installation. mcl ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 01/07/2011 12:46, Tom Judge wrote: Hi Doug, I think (imho) the apache style scripts are better than the one in openvpn for example. The main reason for this is that they are more along the lines of how other platforms have implemented this feature. That's not a reason either to, or not to do something in FreeBSD. The rc.d system is substantially different that sysV style init.d, and has more capabilities in some ways. Maybe we need a more generic way of doing this rather than each port providing their own implementation? I agree, and I thought I made that point in my initial post. :) Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On Fri, Jan 07, 2011 at 02:46:29PM -0600, Tom Judge wrote: On 01/07/2011 02:04 PM, Doug Barton wrote: On 01/07/2011 11:57, Olli Hauer wrote: ... Maybe we need a more generic way of doing this rather than each port providing their own implementation? I like that idea. I was for a while running two openvpn instances, it was a right pita modifying one. *t_j* i.e. '/etc/rc.d/openvpn restart link1' will restart the process for +/etc/openvpn/link1.conf *t_j* it was discussed in #bsdports briefly *agreed* that would be nice. Tom This is my slightly biased opinion as I am the author of one such script in the tree. - Diane -- - d...@freebsd.org d...@db.net http://www.db.net/~db ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD ports which are currently marked forbidden
On 2011-01-07 22:16, Mark Linimon wrote: On Fri, Jan 07, 2011 at 04:18:49PM +0100, Olli Hauer wrote: I wonder about the old gants port. Do we use parts of this port somewhere (OS/freefall...)? freefall, yep. It's our main GNATS installation. mcl Ups, I thought freefall runs the gnats4 port. ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 1/6/2011 7:03 PM, Wesley Shields wrote:
On Thu, Jan 06, 2011 at 10:01:23PM -0500, Wesley Shields wrote:
On Thu, Jan 06, 2011 at 04:49:36PM -0800, Doug Barton wrote:
On 01/05/2011 01:14, Douglas Thrift wrote:
Hello,
Since ISC dhcpd 4.1 now supports DHCPv6, but a single instance of the
daemon can't do both IPv4 DHCP and DHCPv6, it would be nice if the rc.d
script from the port could be configured to start the daemon twice. Has
anyone thought about this at all or implemented anything?
I really dislike this trend that we're seeing of individual rc.d scripts
supporting running multiple versions of the same daemon, but I haven't
yet found the time to write it up for TPH. The canonical way to do this
is for the rc.d script to have multiple copies of itself, and then do
something like:
name=${0##*/}
For this example you could have the port install rc.d/dhcpd by default
(or whatever the name is, not suggesting a change), and an option to
also install dhcpd_v6 (perhaps as a symlink). This would make it easy to
clean up as the additional copy of the script should also be in the plist.
I'm not a big fan of the same script running multiple versions of the
same daemon either. I do think the symlink and code above is a good
solution though.
The other reason I haven't squawked more about this is that for services
that would like to be able to run an arbitrary number of the same daemon
the servicename_N_{flags|pidfile|etc} method works, and eliminates the
problem of leaving behind multiple numbers of the script after port
deinstall. But for something like this where we're discussing a fixed
(and small) number of copies it's better to have this done the right way.
I didn't know servicename_N_foo existed. I still like the symlink
approach. I can certainly add that to the port in the future.
Forgot to mention... Could you please submit a PR for this so that it
does not end up lost?
-- WXS
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
I've submitted a PR: http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/153781
--
Douglas William Thrift
douglas...@gmail.com
http://douglasthrift.net/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Re: FreeBSD Port: isc-dhcp41-server-4.1.2,1; Concurrent IPv4 DHCP and DHCPv6
On 01/07/2011 12:32, Doug Barton wrote:
On 01/06/2011 21:16, Freddie Cash wrote:
The OpenVPN port does a pretty good job of this. Default rc.d script
is just openvpn. But you can create manual symlinks to it using
openvpn_somename, and it checks rc.conf for openvpn_somename_enable.
Having to manually create the symlink is kind of needed in the openvpn
setup and can lead to left-over files on port removal, but wouldn't be
needed for dhcpd.
Might want to look through the openvpn rc script for ideas.
Yeah, I'm actually kind of embarrassed that I didn't mention that
explicitly, since I was working with openvpn the other day. :) The
script can be simplified with the attached patch. The eval's are a
necessary evil without some other mechanism for setting the defaults.
The patch also removes the default empty variable assignments which are
never necessary or desirable.
Blah, name=${0%%*/} should be ${0##*/} in the patch, I was moving too
quickly, sorry.
Doug
--
Nothin' ever doesn't change, but nothin' changes much.
-- OK Go
Breadth of IT experience, and depth of knowledge in the DNS.
Yours for the right price. :) http://SupersetSolutions.com/
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
FreeBSD Port: ja-nkf-2.1.1,1-- japanese man corrupt
(I will write this mail both in English and Japanese.) I'm a FreeBSD user. I appreciate those who are in The FreeBSD Project. I met Mr. Norikatsu Shigemura at AsiaBSDcon2009, CBUG 22th and 23th meeting. When I was using nkf , I recoginzed that man in Japanese is corrupt. I use FreeBSD/i386 8.1-RELEASE-p2, both in Package (japanese/ja-nkf-2.1.0,1) and most recent Ports (japanese/ja-nkf-2.1.1,1), I found man in Japanese corrupt. While cat1 is unreadable with pager jless , man1 readable with jless. I tried both in ja_JP.UTF-8 and ja_JP.eucJP locale. Please fix the problem. Sicerely yours, Hiroshi Saeki h-sa...@wmail.plala.or.jp 初めてメール差し上げます。 小生は、FreeBSDの一ユーザーです。佐伯と申します。 The FreeBSD Projectの皆様には、感謝の気持ちで一杯です。 重村様のご尊顔は、AsiaBSDCon2009と第22回、第23回のCBUG Meetingで 拝したことがございます。 さて、小生は、 FreeBSD/i386 8.1-RELEASE-p2環境を使っております。 アカウントに依って、LANG、LC_ALLはja_JP.UTF-8にしたり ja_JP.eucJPにしたりしております。 nkfの日本語manが文字化けして読めないので、ご通知申し上げます。 unicode環境でも、euc環境でも読めません。 Packageのjapanese/ja-nkf-2.1.0,1でも、2011年 1月 8日現在、最新の Portsのjapanese/ja-nkf-2.1.1,1でも、日本語manが読めません。 jlessで直接ファイルの中を覘いて見ると、 cat1の方は、日本語が全く読めず、man1の方は、日本語の文字は読めますが、 % jman -a nkf で表示させると読めません。 日本語manが読めるように修正して頂ければ幸いです。 宜しくお願い申し上げます。 佐伯 浩 h-sa...@wmail.plala.or.jp ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
Package building for -current (Was: Re: HEADS UP: Merge of binutils 2.17)
I'm happy to have a discussion about this topic either publicly, or privately, your choice. Since your message went to -current@, that's where my reply is headed. I've also cc'ed ports@ since the topic is relevant there too. Meanwhile, I've snipped some of what you wrote to focus on the issues that I think are most relevant. I value and respect both your opinion and your experience in these issues, but I have some rather profound disagreements with your conclusions. On 01/07/2011 21:48, Ade Lovett wrote: On Jan 07, 2011, at 17:37 , Doug Barton wrote: On 01/07/2011 13:54, Ade Lovett wrote: Most likely it's low priority given all the other exp-runs that affect 7.x/8.x, tweaking things for an 6.x-EOL-tagged tree, and a bunch of other infrastructure stuff. Not to mention the impending 7- and 8- RELEASEs. Before I start on this, I would like a few things noted for the record: 1. I have set Reply-To to developers@ (this should be a major hint) 2. I am not a current member of portmgr@ 3. I requested, and served, for a very short time, on the first portmgr That may very well be the case, but if so then it's incumbent on portmgr to communicate that. If you check the audit trail you will find that they did not. Horsecrap. You are taking an individual PR history without reference to the whole host of things that were also going on at the same time. Like it or not, when it comes to ports, -STABLE wins over -CURRENT every single time. I disagree rather profoundly on this point. We have a tolerance/expectation of our leadership just plain not communicating with us that has gone way past unhealthy. It takes 30 seconds to respond to a PR and say We can't get to this before the pending releases, here is a suggested course of action. That's a perfectly reasonable thing for a person to expect in response to a request. In addition to not responding just being plain rude, it fosters the attitude of Why should I bother communicating with portmgr, they never respond anyway. Not to mention the fact that occasionally the fact that portmgr doesn't like to communicate can sometimes create actual problems, such as when they removed the MD5 checksum stuff without warning, and therefore broke all the ports management and other tools that depended on them. I was glad of the action to finish the change, but the action came after months of no communication about it at all. IMO this is a total red herring, and has been for several years now. I run -current every day on my real-work system, and barring the occasional hiccup it's been buildable nearly every time I've tried. Apologies for not being able to drive my email client appropriately. The issue at hand is one of running -CURRENT. There is a distinct, and fundamental difference between running -CURRENT on a single system, as opposed to a cluster of systems that are tightly interlinked. Believe it or not, I understand that. I also get that sometimes running package building on -current stresses it in ways that cause it to break. That's a good thing. :) My point is that YEARS of ignoring the problem is not acceptable, and needs to change. For a long time portmgr griped about not having enough systems for the build cluster. Now they have plenty of hardware available, but the problem is that the system is too pointy-hat centric. Apparently significant progress has been made in that area, but none of it seems to have trickled down to actually getting more packages built for more platforms better and faster. I do, honestly, get that this is a hard problem. But if portmgr needs help, it needs to ask for it. It asked for and received more hardware, so clearly the foundation and the FreeBSD community at large is ready to step up to help. I think it's pretty obvious at this point that the gating factor is person-hours, so portmgr needs to be a lot more aggressive in developing new volunteers, asking for help with specific tasks, etc. etc. The fact that they are dealing with hard problems is no longer an acceptable excuse for years of failure to solve them. Sadly, the only thing I can say to your 4-step procedure, and with utmost politeness, is that your src-centric views are completely missing the point. 4. start building ports is in fact a 20- or 30-step process to ensure no cross-contamination. Once again, I get that bit too. Since we do, in fact, already have a package building cluster I was handwaving it because I was trying to address your red herring about we can't find a version of -current we like so we can't even try. The essential points that I'm trying to communicate are: 1. Most of the time HEAD works pretty well nowadays 2. Very few ports care that deeply about the guts of the system they are running on I look forward to your input and total solutions on how to make this better. I do. See above. I would love it if the foundation wanted to fund me to spend the amount of time it would take to
Re: boost libs error
On 01/01/2011 13:40, Alexander Churanov wrote: 2011/1/1 Doug Bartondo...@freebsd.org: I'm getting the following with qbittorrent-23 which depends on libtorrent-rasterbar-15 after the latest boost lib update: qbittorrent terminate called after throwing an instance of 'std::runtime_error' what(): locale::facet::_S_create_c_locale name not valid Abort trap: 6 (core dumped) Doug, please, check whether you have are observing the issue ports/153561. Alexander Churanov, maintainer of devel/boost-* I didn't see your reply to the PR, so I wasn't aware that you had approved the patches until I double-checked tonight. But the update is done now, thanks! Doug -- Nothin' ever doesn't change, but nothin' changes much. -- OK Go Breadth of IT experience, and depth of knowledge in the DNS. Yours for the right price. :) http://SupersetSolutions.com/ ___ freebsd-ports@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-ports To unsubscribe, send any mail to freebsd-ports-unsubscr...@freebsd.org
