FreeBSD unmaintained ports which are currently marked forbidden
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: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x ___ 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 ports which are currently marked forbidden
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=databases&portname=gnats portname: misc/compat3x forbidden because: FreeBSD-SA-03:05.xdr, FreeBSD-SA-03:08.realpath - not fixed / no lib available build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x ___ 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 ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/bmp-musepack description:Musepack decoder for beep-media-player maintainer: po...@freebsd.org deprecated because: does not build with audio/musepack expiration date:2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=bmp-musepack portname: audio/libmpcdec description:High quality audio compression format maintainer: multime...@freebsd.org deprecated because: superseded by audio/musepack expiration date:2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=libmpcdec portname: audio/py-musepack description:Python module that provides the Musepack decoding interface maintainer: po...@freebsd.org deprecated because: does not build with audio/musepack expiration date:2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=py-musepack portname: chinese/chinput3 description:Chinese GB2312,BIG5 code input server maintainer: po...@freebsd.org status: BROKEN deprecated because: Development has ceased. expiration date:2010-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: devel/p5-P4 description:P4 - Perl friendly OO interface to the Perforce SCM System maintainer: to...@freebsd.org deprecated because: Depends of p5-P4-Client, which is DEPRECATED. expiration date:2010-10-14 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-P4 portname: devel/p5-P4-Client description:P4::Client - Perl extension for the Perforce API maintainer: to...@freebsd.org status: BROKEN deprecated because: has been broken for 11 months expiration date:2010-01-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=p5-P4-Client portname: emulators/win4bsd description:Win4BSD Virtual Machine for Windows under BSD maintainer: po...@freebsd.org status: BROKEN deprecated because: Development has ceased and distfile is no longer available expiration date:2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: french/mozilla-flp description:seamonkey French Language Pack (FLP) maintainer: po...@freebsd.org deprecated because: www/seamonkey port is deprecated. Consider using the www/firefox-i18n. expiration date:2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=mozilla-flp portname: french/xtel description:An emulator for the french Minitel maintainer: po...@freebsd.org deprecated because: Minitel services will be discontinued at the end of 2010. expiration date:2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=xtel portname: ftp/kwebget description:A KDE frontend to wget maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=kwebget portname: japanese/samba3 description:Japanese Samba maintainer: kuriy...@freebsd.org deprecated because: Unsupported by the upstream. Please, consider to upgrade. expiration date:2010-09-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=japanese&portname=samba3 portname: misc/compat3x description:A convenience package to i
FreeBSD unmaintained ports which are currently scheduled for deletion
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically schedule removal of ports that have been judged to have outlived their usefulness. Often, this is due to a better alternative having become available and/or the cessation of development on the existing port. In some cases, ports are marked for removal because they fail to build and install correctly from their sources, or otherwise fail in operation. The ports, and the reason and date that they have been scheduled for removal, are listed below. If no one has stepped forward before that time to propose a way to fix the problems (such as via a PR), the ports will be deleted. portname: audio/bmp-musepack description:Musepack decoder for beep-media-player maintainer: po...@freebsd.org deprecated because: does not build with audio/musepack expiration date:2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=bmp-musepack portname: audio/py-musepack description:Python module that provides the Musepack decoding interface maintainer: po...@freebsd.org deprecated because: does not build with audio/musepack expiration date:2010-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=py-musepack portname: chinese/chinput3 description:Chinese GB2312,BIG5 code input server maintainer: po...@freebsd.org status: BROKEN deprecated because: Development has ceased. expiration date:2010-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: emulators/win4bsd description:Win4BSD Virtual Machine for Windows under BSD maintainer: po...@freebsd.org status: BROKEN deprecated because: Development has ceased and distfile is no longer available expiration date:2010-12-31 build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname: french/mozilla-flp description:seamonkey French Language Pack (FLP) maintainer: po...@freebsd.org deprecated because: www/seamonkey port is deprecated. Consider using the www/firefox-i18n. expiration date:2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=mozilla-flp portname: french/xtel description:An emulator for the french Minitel maintainer: po...@freebsd.org deprecated because: Minitel services will be discontinued at the end of 2010. expiration date:2010-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=french&portname=xtel portname: ftp/kwebget description:A KDE frontend to wget maintainer: po...@freebsd.org deprecated because: Development has ceased. expiration date:2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=kwebget portname: misc/compat3x description:A convenience package to install the compat3x libraries maintainer: po...@freebsd.org status: FORBIDDEN deprecated because: Only FreeBSD 6.4+ are supported in ports expiration date:2010-10-08 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=misc&portname=compat3x portname: multimedia/clive-utils description:Passwords, RSS parsing, and link extraction for clive maintainer: po...@freebsd.org status: IGNORE deprecated because: development has ceased; use multimedia/umph instead expiration date:2010-11-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=multimedia&portname=clive-utils portname: net-mgmt/net-snmp4 description:An extendable SNMP implementation maintainer: po...@freebsd.org status: BROKEN deprecated because: Use net-mgmt/net-snmp port instead expiration date:2009-07-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net-mgmt&portname=net-snmp4 portname: net-p2p/btpeer description:Client functionality of bittorrent protocol, network only environment maintainer: po...@freebsd.org deprecated because: Does not build with net/Sockets and is unmaintained. expiration date:2010-10-14 build errors: none. overview: http://portsmon.FreeBSD
FreeBSD ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/aureal-kmod broken because: doesn't build on RELENG_8 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=aureal-kmod portname: audio/baudline broken because: no longer available (website now have 1.08) build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/linux-baudline-1.07.log.bz2 (_Jul_27_00:43:34_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=baudline portname: audio/ecawave broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=ecawave portname: audio/emu10kx broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=emu10kx portname: audio/festvox-aec broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=festvox-aec portname: audio/gmpc-mserver broken because: fails to build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gmpc-mserver portname: audio/gtkguitune broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gtkguitune portname: audio/gxmms2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gxmms2 portname: benchmarks/polygraph broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph-3.0.6_1.log (_Mar_21_01:42:24_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph portname: benchmarks/polygraph31 broken because: does not build build errors: http://pointyhat.FreeBSD.org/errorlogs/amd64-errorlogs/e.9.20100319084642/polygraph31-3.1.5_1.log (_Mar_21_01:42:25_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=benchmarks&portname=polygraph31 portname: biology/tinker broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=tinker portname: cad/tclspice broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=tclspice portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: comms/hcfmdm broken because: Does not compile at 7.x or higher build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=hcfmdm portname: comms/hso-kmod broken because: does not build with USB2, please try comms/uhso-kmod instead build errors: none. overview: http://portsmon.Fr
FreeBSD unmaintained ports which are currently marked broken
As part of an ongoing effort to reduce the number of problems in the FreeBSD ports system, we periodically notify users of ports that are marked as "broken" in their Makefiles. In many cases these ports are failing to compile on some subset of the FreeBSD build environments. The most common problem is that recent versions of -CURRENT include gcc4.2, which is much stricter than older versions. The next most common problem is that compiles succeed on the i386 architecture (e.g. the common Intel PC), but fail on one or more of the other architectures due to assumptions about things such as size of various types, byte-alignment issues, and so forth. In occasional cases we see that the same port may have different errors in different build environments. The script that runs on the build cluster uses heuristics to try to 'guess' the error type to help you isolate problems, but it is only a rough guide. One more note: on occasion, there are transient build errors seen on the build farm. Unfortunately, there is not yet any way for this algorithm to tell the difference (humans are much, much better at this kind of thing.) The errors are listed below. In the case where the same problem exists on more than one build environment, the URL points to the latest errorlog for that type. (By 'build environment' here we mean 'combination of 6.x/7.x/-current with target architecture'.) (Note: the dates are included to help you to gauge whether or not the error still applies to the latest version. The program that generates this report is not yet able to determine this automatically.) portname: audio/festvox-aec broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=festvox-aec portname: audio/gtkguitune broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gtkguitune portname: audio/gxmms2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=gxmms2 portname: biology/tinker broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=tinker portname: chinese/chinput3 broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=chinese&portname=chinput3 portname: databases/p5-sqlrelay broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=p5-sqlrelay portname: deskutils/gnotime broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=deskutils&portname=gnotime portname: devel/ace+tao broken because: Does not compile on FreeBSD >= 7.0 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ace%2Btao portname: devel/fampp broken because: FAM system mismatch: gamin is installed, while desired FAM system is fam build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fampp portname: devel/gcvs broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=gcvs portname: devel/linux-js broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linux-js portname: devel/linuxthreads broken because: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=linuxthreads portname: devel/ngpt broken because: does not compile build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ngpt portname: dns/fourcdns broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=fourcdns portname: emulators/cpmtools2 broken because: does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=cpmtools2 portname: emulators/win4bsd broken because: does not fetch build errors: http://pointyhat.freebsd.org/errorlogs/i386-errorlogs/e.7.20100914233422/win4bsd-1.1_4.log.bz2 (_Jul_27_00:44:09_UTC_2010) overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=win4bsd portname:
Re: OPTIONS
On 10/06/2010 13:55, David O'Brien wrote:
> On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote:
>> On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote:
>>> On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote:
> 2010/10/3 Matthew Seaman :
>> In fact, you might just as well write a small HTML form, display it
>> using lynx or w3c or some other text mode browser[*], and then have the
>> form action feed into a CGI program that outputs a small Makefile with
>> appropriate variable definitions in it.
I like this statement -- as it shows just how complex this will get when
taken to its natural conclusion.
>>>
>>> This is also how ridiculous things can get:
>>>
>>> curl 7.21.1 now offers me:
>>> � �[X] WERROR � � � Treat compilation warnings as errors
>>>
>>> � �Can the port maintainer really not decide if that should just be
>>> � �turned off or turned on for FreeBSD?!?
>>
>> I wonder why -Werror even ever considered to be turned "on" at all.
>
> \AOL{me too}
>
> I mean building with "-Werror" sounds like goodness -- of course I
> want it.
>
> But why is the maintainer offering me a choice?
> What is the likelihood of the port not building with -Werror?
> Does he know of versions of FreeBSD where the port will not build
> with -Werror? Hum.. maybe I don't want -Werror. But then why didn't
> the the maintainer just decide we would all not build with -Werror?
>
> Given we are just building and installing Curl, what do we expect
> users to do choose WERROR and get a build break with -Werror?
> They aren't developing the next version of Curl. Can they submit a
> FreeBSD PR and expect the maintainer will quickly add a patch to the
> port to fix the warning(s)? Or will the response be
> "Well, don't do that."? In which case just turning off -Werror for
> all seems a better thing to do.
>
IMHO If I may, The OPTIONS framework is a UI(User Interface) to useful
options that a 'User' would be interested in turning on. This would be
things that a user, not a 'developer' could use or would find helpful.
With the above said, if it was the developers intent to add options in
order to make debugging the port easier for them, then I feel that is
the wrong approach as these are options that are more appropriately
handled by CFLAGS CXXFLAGS LDFLAGS and such since they are developer
centric and mean very little to the majority of the community.
Now with both of the above stated, it may be useful if specific
developer options were wrapped in a statement that would check to see if
a MAINTAINER_MODE has been defined allowing those options to be
dynamically added to the list of existing option.
Personally I feel that because of the loose guidelines that we already
have in the Porters Handbook that when frameworks like this present
problems as the options framework has already shown, that a better
defined standard should be developed & agreed upon so that every
developer and user knows exactly what to expect out of every port and
what is expected to be presented to the user. A ports tree of this size
and not having a clear and set-forth standard as to what can be expected
is fairly hazardous IMO. If I had missed an area 'one area' where this
is already defined then please excuse me and reference me a clear link.
Regards,
--
jhell,v
___
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"
security/openssh-portable maintainer
Hi, I see this port has no maintainer now and is now out of date. I have attempted myself to update the port but have hit a number of problems. 1 - some of the contrib patches dont exist for the new version of the app. I assume support would need to be dropped t least emporarily on an update. 2 - one of the freebsd patches in the files dir fails to patch, the rest are reported as syccessful however when checking the files in the work dir they are not patched. 3 - the hpn patch on the dev website is gzipped, the ports system seems to assume a patch must be uncompressed when downloading? 4 - the hpn patch initially on the old version is just in the files dir however I couldnt find a way to use -p1 with it, so I set it to download as a dist patch but because of problem #3 I used my own webspace to download a uncompressed patch. What I am asking is, can someone please take over this port, my skill set is not high enough to do it at least without some help. Failing that can someone help me with the freebed patches in the files dir to patch ok on openssh 5.6p1. Chris ___ 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: irc/weechat*: cmake/Find(Python|Ruby|etc).cmake don't respect version from bsd.(python|ruby|etc).mk
Anonymous writes: > $ export PYTHON_DEFAULT_VERSION=python2.7 > $ make install deinstall WITH_PYTHON= > ... > ===> Deinstalling weechat-0.3.3_1 > pkg_delete: file '/usr/local/lib/weechat/plugins/python.so' doesn't exist > > And excerpt from CMakeCache.txt Oops, read as And excerpt from CMakeCache.txt when several version of python installed while retaining python2.7 as the default > //Path to a program. > PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python > > //Path to a file. > PYTHON_INCLUDE_PATH:PATH=/usr/local/include/python2.5 > > //Path to a library. > PYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython2.6.so > > //Dependencies for the target > > python_LIB_DEPENDS:STATIC=general;/usr/local/lib/libpython2.6.so;general;weechat_scripts; As for the case when only python2.7 is installed the contents are //Path to a program. PYTHON_EXECUTABLE:FILEPATH=PYTHON_EXECUTABLE-NOTFOUND ___ 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"
irc/weechat*: cmake/Find(Python|Ruby|etc).cmake don't respect version from bsd.(python|ruby|etc).mk
The port blindly assumes the first version of python|ruby|etc it finds
as the one user wants weechat plugin built against. Example for python
$ export PYTHON_DEFAULT_VERSION=python2.7
$ make install deinstall WITH_PYTHON=
...
===> Deinstalling weechat-0.3.3_1
pkg_delete: file '/usr/local/lib/weechat/plugins/python.so' doesn't exist
And excerpt from CMakeCache.txt
//Path to a program.
PYTHON_EXECUTABLE:FILEPATH=/usr/local/bin/python
//Path to a file.
PYTHON_INCLUDE_PATH:PATH=/usr/local/include/python2.5
//Path to a library.
PYTHON_LIBRARY:FILEPATH=/usr/local/lib/libpython2.6.so
//Dependencies for the target
python_LIB_DEPENDS:STATIC=general;/usr/local/lib/libpython2.6.so;general;weechat_scripts;
I guess FindPython.cmake doesn't respect LOCALBASE, too.
%%
Index: irc/weechat/Makefile
===
RCS file: /a/.cvsup/ports/irc/weechat/Makefile,v
retrieving revision 1.49
diff -u -p -r1.49 Makefile
--- irc/weechat/Makefile30 Sep 2010 04:14:36 - 1.49
+++ irc/weechat/Makefile7 Oct 2010 02:44:32 -
@@ -64,6 +64,8 @@ PLIST_SUB+= ASPELL="@comment "
.if defined(WITH_PYTHON)
USE_PYTHON=yes
+CMAKE_ARGS+= -DPYTHON_VERSION=${PYTHON_VERSION} \
+ -DPYTHON_CMD=${PYTHON_CMD}
PLIST_SUB+=PYTHON=""
.else
CMAKE_ARGS+= -DDISABLE_PYTHON=yes
Index: irc/weechat/files/patch-cmake-FindPython.cmake
===
RCS file: irc/weechat/files/patch-cmake-FindPython.cmake
diff -N irc/weechat/files/patch-cmake-FindPython.cmake
--- /dev/null 1 Jan 1970 00:00:00 -
+++ irc/weechat/files/patch-cmake-FindPython.cmake 7 Oct 2010 01:59:44
-
@@ -0,0 +1,21 @@
+--- cmake/FindPython.cmake~2010-09-28 13:09:52.0 +0400
cmake/FindPython.cmake 2010-10-07 05:37:43.709648725 +0400
+@@ -34,8 +34,7 @@ IF(PYTHON_FOUND)
+ ENDIF(PYTHON_FOUND)
+
+ FIND_PROGRAM(PYTHON_EXECUTABLE
+- NAMES python python2.6 python2.5 python2.4 python2.3 python2.2
+- PATHS /usr/bin /usr/local/bin /usr/pkg/bin
++ NAMES ${PYTHON_CMD}
+ )
+
+ IF(PYTHON_EXECUTABLE)
+@@ -65,7 +64,7 @@ IF(PYTHON_EXECUTABLE)
+ )
+
+ FIND_LIBRARY(PYTHON_LIBRARY
+-NAMES python python2.6 python2.5 python2.4 python2.3 python2.2
++NAMES ${PYTHON_VERSION}
+ PATHS ${PYTHON_POSSIBLE_LIB_PATH}
+ )
+
%%
___
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: ntop-3.3.10_7
Any plans on adding ntop 4.1 to the FreeBSD ports collection? Thanks, Paul Hohberg System Administrator Fullerton School District 1401 W. Valencia Drive Fullerton, CA 92833 714-447-7483 ___ 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"
several question about ports
Hello I have several question about create Makefile Есть пару вопросов по поводу создания Makefile I'm not understand in what sequence processed USE_* flags in Makefile Не понятно в какой последовательности обрабатываются USE_* флаги в майк файле Is it possible the following: Возможно ли выполнить на pre-fetch USE_AUTOTOOLS USE_JAVA USE_APACHE pre-fetch сборку зависимостей USE_AUTOTOOLS USE_JAVA USE_APACHE after that execute script, pre-configure who maked firebird-2.1 from sorce, then make PHP via USE flag? затем выполнить скрипт, pre-configure который соберет firebird-2.1, а затем собрать PHP через USE флаг. ___ 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: several question about ports
Hello, I have several questions concerning creating Makefile I don't understand in what sequence USE_* flags in Makefile are processed Is it possible to do: In pre-fetch stage USE_AUTOTOOLS USE_JAVA USE_APACHE after that execute script, pre-configure which will make firebird-2.1 from sorce, then make PHP via USE flag? ___ 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: OPTIONS
On Wed, Oct 06, 2010 at 12:01:48PM +0300, Andrew W. Nosenko wrote:
> On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote:
> > On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote:
> >> > 2010/10/3 Matthew Seaman :
> >> > > In fact, you might just as well write a small HTML form, display it
> >> > > using lynx or w3c or some other text mode browser[*], and then have the
> >> > > form action feed into a CGI program that outputs a small Makefile with
> >> > > appropriate variable definitions in it.
> >>
> >> I like this statement -- as it shows just how complex this will get when
> >> taken to its natural conclusion.
> >
> > This is also how ridiculous things can get:
> >
> > curl 7.21.1 now offers me:
> > ? ?[X] WERROR ? ? ? Treat compilation warnings as errors
> >
> > ? ?Can the port maintainer really not decide if that should just be
> > ? ?turned off or turned on for FreeBSD?!?
>
> I wonder why -Werror even ever considered to be turned "on" at all.
\AOL{me too}
I mean building with "-Werror" sounds like goodness -- of course I
want it.
But why is the maintainer offering me a choice?
What is the likelihood of the port not building with -Werror?
Does he know of versions of FreeBSD where the port will not build
with -Werror? Hum.. maybe I don't want -Werror. But then why didn't
the the maintainer just decide we would all not build with -Werror?
Given we are just building and installing Curl, what do we expect
users to do choose WERROR and get a build break with -Werror?
They aren't developing the next version of Curl. Can they submit a
FreeBSD PR and expect the maintainer will quickly add a patch to the
port to fix the warning(s)? Or will the response be
"Well, don't do that."? In which case just turning off -Werror for
all seems a better thing to do.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: OPTIONS (was: editors/vim installs to /)
On Wed, Oct 06, 2010 at 02:12:18PM +0200, David DEMELIER wrote:
> 2010/10/5 David O'Brien :
> > On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote:
> >> 2010/10/2 David O'Brien :
> >> > 2. With the way OPTIONS handling is done, there isn't a way for me
> >> > to query if I built with the defaults or not.
> >> > Thus leading to every port I manually install looking like it was
> >> > customized just because /var/db/ports/${PORTNAME} exists. ??Thus
> >> > implying I can no longer install the pre-build package.
> >>
> >> make rmconfig ?
> >
> > I think you've missed my point.
> >
> > That does not tell me if I, in the past, made a decision that did not
> > like the maintainer's defaults, or if I just wanted to extract the
> > sources so I could read the license or figure out what the OPTIONS knobs
> > were about, etc..
>
> I understood, you prefere a file like make.conf or ports.conf to see
> which options/knob is defined, isn't it ?
That is true - but doesn't isn't really what's behind #2 above.
In this case, I really want to now which packages are OK to upgrade using
'portupgrade -PP' (or portmaster) -- to quickly do upgrades using the
pre-built packages Portmgr spends a lot of time making available to us.
I use a script that looks for a non-zero byte /var/db/ports/$PKG/options
or any $PKG knobs in /etc/make.conf. If either is found, then
'portupgrade -PP', else just 'portupgrade'.
This is where things like 'make extract' cause a problem - since one
cannot even extract without going thru OPTIONS dialog.
--
-- David (obr...@freebsd.org)
Q: Because it reverses the logical flow of conversation.
A: Why is top-posting (putting a reply at the top of the message) frowned upon?
Let's not play "Jeopardy-style quoting"
___
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: Volunteering for maintaining ICC port
>The maintainer used to be netchild at FreeBSD.org. He wrote this not long ago: http://lists.freebsd.org/pipermail/freebsd-current/2010-August/019208.html b. ___ 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: How long does a repocopy take?
Max Brazhnikov wrote: > On Mon, 4 Oct 2010 18:57:35 + (UTC), Helmut Schneider wrote: > > sorry for my impatience but I asked for a repocopy about one week > > ago and now I'm wondering how long normally a repocopy takes. > > Submit patch vs existing port ask for repocopy. Commiter will request > repocopy from portmgr@ Did so. Thanks, Helmut ___ 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"
teamspeak_client/teamspeak_server ports
hi, I just wanted to notify you that there are TeamSpeak 3 binaries available for FreeBSD x86 and AMD64 now. Got them up and running without problems, maybe you find some time and update the ports... just let me know if I can help (but I don't have experience with ports). daemon -u teamspeak ./ts3server_minimal_runscript.sh works for me, when permissions are set to teamspeak user for the whole directory Best regards Andreas ___ 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: Volunteering for maintaining ICC port
Ah, perfect - That's the page I was looking for. Thanks, now begins the feasibility study. :-) -Original Message- From: owner-freebsd-po...@freebsd.org [mailto:owner-freebsd-po...@freebsd.org] On Behalf Of Denny Lin Sent: October-06-10 12:25 PM To: Chris Forgeron Cc: 'freebsd-ports@freebsd.org' Subject: Re: Volunteering for maintaining ICC port On Wed, Oct 06, 2010 at 11:45:03AM -0300, Chris Forgeron wrote: > What I'm looking for is the previous port maintainer's email address. I ran > across it someplace, but can't find it now. He mentioned having some contacts > at Intel, as well as info on the basic process and tips for the next person > who may want to maintain. The maintainer used to be netch...@freebsd.org. Info can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/icc/Makefile#rev1.94 -- Denny Lin ___ 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-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: Volunteering for maintaining ICC port
On Wed, Oct 06, 2010 at 11:45:03AM -0300, Chris Forgeron wrote: > What I'm looking for is the previous port maintainer's email address. I ran > across it someplace, but can't find it now. He mentioned having some contacts > at Intel, as well as info on the basic process and tips for the next person > who may want to maintain. The maintainer used to be netch...@freebsd.org. Info can be found here: http://www.freebsd.org/cgi/cvsweb.cgi/ports/lang/icc/Makefile#rev1.94 -- Denny Lin ___ 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"
Volunteering for maintaining ICC port
I'd like to step up and offer to modernize and maintain the ICC port for FreeBSD. I may be crazy, specially as 9 is going towards Clang/LLVM. With that move, there may be a lot of very talented people modifying the build/make environment to work in a way that is even further removed from ICC's working. Time will tell if this is viable or not. What I'm looking for is the previous port maintainer's email address. I ran across it someplace, but can't find it now. He mentioned having some contacts at Intel, as well as info on the basic process and tips for the next person who may want to maintain. I'm very interested in HPC, and I believe step one on this long road for FreeBSD is an option to use a more optimized complier for Intel platforms (which is all we use anyway). Thanks. ___ 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: OPTIONS (was: editors/vim installs to /)
David DEMELIER writes: > I will try to do it, I think a replacement of ports.conf with a > make syntax would be better. I will try to do something in the > end of week. For informational purposes only: if you are not aware of it, portupgrade has "pkgtools.conf". Robert Huff ___ 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: OPTIONS
David O'Brien wrote:
> On Sun, Sep 19, 2010 at 10:24:59AM +0200, David DEMELIER wrote:
> > What is "sufficiently clean" ? I wonder what is not clean in the
> > options framework, so please tell me then we still can clean it?
>
> When the Ports Collection was invented, ports maintainers were to
> choose a reasonable set of configuration for the FreeBSD community
> and have the port build that way.
>
> Today we have ports that seem to expose every single option to GNU
> configure and giving the user a puzzling choice of too many things.
> Often the explanations are nothing more than restating the option
> name and the user is left wondering what is X? What does Y mean?
> How do I know if I really want Z or not? Why is threading so often
> an OPTION and not just the default? Why do I have to go read the
> packages README and INSTALLING to figure out the caveats of say
> enabling threading? Or what the other list of things are and their
> caveats?
If you mean that some of the defaults are inconsistent, and could be
changed; and that succinct comments could be added in some places to
save time for the user, then I agree with you. But if you think that
comments could obviate the need for learning about the software; or
that the solution is to do away with OPTIONS altogether, and hard-code
everything, I don't. You are a very experienced programmer, and you
can appreciate that there is a lot of software out there that works in
a lot of different ways. Also, there are a lot of users with different
needs. To take your example, it may be that threading may be disabled
for one port, and enabled for another, because of some inconsequential
decision by a port maintainer. But it may also be because that port
doesn't implement threading properly for some FreeBSD platforms. Or
because enabling it brings benefits for some users, but disadvantages
for others. We may be able to clean up some things, but we can't make
the situation simpler than it is.
> 1. One should not have to deal with the OPTIONS dialog just to
> 'make extract' if one wants to check the license or otherwise
> investigate a port before deciding to install it.
That may be annoying, but some OPTIONS affect what is fetched and
extracted, and how, so there isn't an easy way around this. If you
just wanted to examine the default distfiles, you could set BATCH.
The new license framework may help in the other case, after more
LICENSE entries are added to ports.
> 2. With the way OPTIONS handling is done, there isn't a way for me
> to query if I built with the defaults or not.
> Thus leading to every port I manually install looking like it was
> customized just because /var/db/ports/${PORTNAME} exists. Thus
> implying I can no longer install the pre-build package.
This is partly an administrative issue, and I don't think that it can
be dealt with entirely within Ports. Even if we changed the
OPTIONSFILE handling to: (a) add a PORTS_DBDIR cookie, or an
OPTIONSFILE entry, to indicate if an OPTIONSFILE corresponded to the
default OPTIONS ; and (b) include all knobs that may affect the port
build, and not just those now in OPTIONS -- both of which would add
some complexity, and another potential source of error -- the
information in PORTS_DBDIR may not correspond to the packages that are
actually installed. Are you suggesting that all knobs used to build a
package should be recorded in the package, and hence in PKG_DBDIR?
That might be useful, although not easy to implement for knobs that
weren't in OPTIONS. However, it seems to me that this kind of thing
is best handled by updating tools, like pkg-mgmt/portupgrade[-devel],
which has the per-port USE_PKGS[_ONLY] settings in pkgtool.conf.
> 3. OPTIONS are limited to only checkbox YES/NO settings.
> Why can I not set PREFIX thru the OPTIONS framework and have it come
> from /var/db/ports/${PORTNAME}/options on the 2nd and later builds?
> Even the boolean NOPORTDOCS isn't available thru OPTIONS.
> Thus it is an inconsistent way to configure a port.
>
> 4. When I build misc/mc-light and have "WITHOUT_NLS=yes" in
> /etc/make.conf, why does the OPTIONS dialog offer me
> "[X] NLS Enable gettext support" instead of defaulting the
> dialog to unchecked?
You can set those knobs via the command line, or via Makefile.{inc,
${ARCH}*, ${OPSYS}, local}, or via make.conf, where you can limit the
scope based on the .CURDIR, etc. Although we do have a problem, as
you note in (4), with knobs that are OPTIONS, but are defined
somewhere other than OPTIONSFILE. I hadn't seen:
http://docs.freebsd.org/cgi/mid.cgi?4C476F69.1060200
until swell.k pointed it out (thanks). I think that it does some good
things, but it does have some problems:
--I don't think the priority is right: the "environment" settings
ought to override the PORTS_DBDIR entries. This is because they will
do so anyway in some circumstances (because of recursion, or the use
of make -e/-E, or because you can't .undef some "environment"
variables), but also
Re: OPTIONS (was: editors/vim installs to /)
2010/10/5 David O'Brien :
> On Sun, Oct 03, 2010 at 10:22:46AM +0200, David DEMELIER wrote:
>> 2010/10/2 David O'Brien :
>> > 2. With the way OPTIONS handling is done, there isn't a way for me
>> > to query if I built with the defaults or not.
>> > Thus leading to every port I manually install looking like it was
>> > customized just because /var/db/ports/${PORTNAME} exists. Thus
>> > implying I can no longer install the pre-build package.
>>
>> make rmconfig ?
>
> I think you've missed my point.
>
> That does not tell me if I, in the past, made a decision that did not
> like the maintainer's defaults, or if I just wanted to extract the
> sources so I could read the license or figure out what the OPTIONS knobs
> were about, etc..
>
I understood, you prefere a file like make.conf or ports.conf to see
which options/knob is defined, isn't it ?
>> The best thing to do is switch totally to a way to configure a port
>> and remove the other one.
>
> Only if folks agree on what the best way to configure a port is.
> I spoke with some co-workers last week, and OPTIONS weren't very
> popular with them. They also stated some of the the issues I listed.
>
>
>> I think we should try to upgrade the options
>> framework with what I said at 4. and 3. It's possible but we need some
>> work.
>
> Even without forcing all ports to go in one direction for configuration,
> this would be a Good Thing to do. Hopefully someone with interest will
> submit some patches.
>
I will try to do it, I think a replacement of ports.conf with a make
syntax would be better. I will try to do something in the end of week.
> --
> -- David (obr...@freebsd.org)
> Q: Because it reverses the logical flow of conversation.
> A: Why is top-posting (putting a reply at the top of the message) frowned
> upon?
> Let's not play "Jeopardy-style quoting"
> ___
> 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"
>
Kind regards,
--
Demelier David
___
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: OPTIONS
On Wed, Oct 6, 2010 at 11:40, David O'Brien wrote: > On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: >> > 2010/10/3 Matthew Seaman : >> > > In fact, you might just as well write a small HTML form, display it >> > > using lynx or w3c or some other text mode browser[*], and then have the >> > > form action feed into a CGI program that outputs a small Makefile with >> > > appropriate variable definitions in it. >> >> I like this statement -- as it shows just how complex this will get when >> taken to its natural conclusion. > > This is also how ridiculous things can get: > > curl 7.21.1 now offers me: > [X] WERROR Treat compilation warnings as errors > > Can the port maintainer really not decide if that should just be > turned off or turned on for FreeBSD?!? I wonder why -Werror even ever considered to be turned "on" at all. > > Do *I* really need to think about this one? > > But of course it doesn't offer me turning on NOPORTDOCS or > NOPORTEXAMPLES, which would be useful. > [I don't think any ports do...] > > > cscope 15.7a offers me: > [ ] XCSCOPE Install (X)Emacs package > > Do we really need to be bothered with OPTIONS to avoid installing an > 87K .el file?!? Yes. I'm, as everyday cscope and emacs user, would be very frustrated if xcscope.el would be installed by ports overriding my patched version and forcing me to patch it again and again. Why xcscope.el didn't splinted out into separate port/package -- it's another question... -- Andrew W. Nosenko ___ 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: OPTIONS
On Tue, Oct 05, 2010 at 11:34:52AM -0700, David O'Brien (@FreeBSD) wrote: > > 2010/10/3 Matthew Seaman : > > > In fact, you might just as well write a small HTML form, display it > > > using lynx or w3c or some other text mode browser[*], and then have the > > > form action feed into a CGI program that outputs a small Makefile with > > > appropriate variable definitions in it. > > I like this statement -- as it shows just how complex this will get when > taken to its natural conclusion. This is also how ridiculous things can get: curl 7.21.1 now offers me: [X] WERROR Treat compilation warnings as errors Can the port maintainer really not decide if that should just be turned off or turned on for FreeBSD?!? Do *I* really need to think about this one? But of course it doesn't offer me turning on NOPORTDOCS or NOPORTEXAMPLES, which would be useful. [I don't think any ports do...] cscope 15.7a offers me: [ ] XCSCOPE Install (X)Emacs package Do we really need to be bothered with OPTIONS to avoid installing an 87K .el file?!? -- -- David (obr...@freebsd.org) Q: Because it reverses the logical flow of conversation. A: Why is top-posting (putting a reply at the top of the message) frowned upon? Let's not play "Jeopardy-style quoting" ___ 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"
