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: net/dante forbidden because: Building on 10+ triggers a nasty bug with unix domain sockets build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=dante portname: net/ntp-rc forbidden because: CVE-2013-5211 / VU build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=ntp-rc ___ 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 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 7.x/8.x/9.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/cowbell broken because: No more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell portname: audio/raproxy broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: audio/wmauda broken because: Does not work with audacious 3.5 or later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wmauda portname: audio/x11amp broken because: hangs at start with gtk and linker errors build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=x11amp portname: cad/cider broken because: Will not build with bmake and USES=fmake will not solve the issue build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider portname: databases/gtksql broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=gtksql portname: databases/tora broken because: Does not compile with clang (include ) build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=tora portname: devel/fsmgenerator broken because: Fails to link build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fsmgenerator portname: emulators/linux_base-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_base-gentoo-stage3 portname: emulators/linux_dist-gentoo-stage3 broken because: Fails to package build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=emulators&portname=linux_dist-gentoo-stage3 portname: ftp/rexx-curl broken because: Fails to install/package with new rexx-regina build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ftp&portname=rexx-curl portname: games/djgame2 broken because: Online servers gone, game is not playable build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/djgame2-3.2.0_4.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=djgame2 portname: games/wmfortune broken because: No public disfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=wmfortune portname: graphics/gnash broken because: unable to link in libboost_system build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=gnash portname: graphics/xfpovray broken because: Fails to link build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=graphics&portname=xfpovray portname: science/mpb broken because:
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/cowbell description:Elegant music organizer maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell portname: audio/cuberok description:Music player and collection manager based on Qt4 maintainer: v...@freebsd.org deprecated because: Upstream development has stalled expiration date:2014-11-15 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cuberok portname: biology/boinc-simap description:Similarity Matrix of Proteins project for BOINC maintainer: po...@freebsd.org deprecated because: Project shutting down, see http://boincsimap.org/boincsimap/forum_thread.php?id=88 expiration date:2015-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=boinc-simap portname: databases/db48 description:The Berkeley DB package, revision 4.8 maintainer: mand...@freebsd.org deprecated because: Please migrate to db5 or db6 expiration date:2014-11-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=db48 portname: databases/memcachedb description:Distributed storage system designed for persistence maintainer: k...@stereochro.me deprecated because: Depends on deprecated Berkeley DB version, needs porting to DB_SITE expiration date:2014-11-30 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=memcachedb portname: devel/creduce description:Produces small test cases maintainer: po...@freebsd.org deprecated because: Unmaintained and depends on ancient LLVM 3.2 expiration date:2014-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=creduce portname: devel/fsmgenerator description:Finite State Machine generating software maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fsmgenerator portname: devel/ocaml-equeue description:The Equeue library for OCaml maintainer: michip...@gmail.com deprecated because: Superseded by www/ocaml-net expiration date:2015-08-20 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=ocaml-equeue portname: devel/rubygem-dep_selector description:Find a valid assignment of package versions maintainer: r...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=rubygem-dep_selector portname: dns/bind10 description:Development version of ISC BIND 10 DNS Suite maintainer: m...@freebsd.org status: IGNORE deprecated because: Is not developed any more, use dns/bundy expiration date:2015-12-31 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=bind10 portname: dns/maradns1 description:DNS server with focus on security and simplicity maintainer: m...@freebsd.org deprecated because: MaraDNS 1 end-of-life: June 21, 2015, use dns/maradns expiration date:2015-06-21 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=dns&portname=maradns1 portname: editors/emacs23 description:GNU editing macros maintainer: ash...@freebsd.org deprecated because: Unmaintained upstream, use editors/emacs expiration date:2014-11-19 build errors: http:/
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 7.x/8.x/9.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: does not build build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=aureal-kmod portname: audio/cowbell broken because: No more public distfiles build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell portname: audio/firefly broken because: Does not fetch build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=firefly portname: audio/qmidinet broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=qmidinet portname: audio/raproxy broken because: Unfetchable build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=raproxy portname: audio/wmauda broken because: Does not work with audacious 3.5 or later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=wmauda portname: audio/x11amp broken because: hangs at start with gtk and linker errors build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=x11amp portname: audio/xmms-openspc broken because: does not build on FreeBSD 10.x and later build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=xmms-openspc portname: cad/cider broken because: Will not build with bmake and USES=fmake will not solve the issue build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=cad&portname=cider portname: comms/wsjt broken because: Fails to configure build errors: http://beefy2.isc.freebsd.org/bulk/93amd64-RELENG_9_3/latest/logs/errors/wsjt-9.1.r2511_3.log http://beefy1.isc.freebsd.org/bulk/84i386-default/latest/logs/errors/wsjt-9.1.r2511_6.log http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/wsjt-9.1.r2511_5.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=comms&portname=wsjt portname: databases/freetds-devel broken because: Fails to build build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/freetds-devel-0.92.812,1.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=freetds-devel portname: databases/gtksql broken because: Fails to configure build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=gtksql portname: databases/mariadb-client broken because: Does not build under FreeBSD 10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mariadb-client portname: databases/mariadb-server broken because: Does not build under FreeBSD 10 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=databases&portname=mariadb-server portname: databases/py-fdb bro
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: net/dante forbidden because: Building on 10+ triggers a nasty bug with unix domain sockets build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=net&portname=dante ___ 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 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/cowbell description:Elegant music organizer maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=audio&portname=cowbell portname: biology/boinc-simap description:Similarity Matrix of Proteins project for BOINC maintainer: po...@freebsd.org deprecated because: Project shutting down, see http://boincsimap.org/boincsimap/forum_thread.php?id=88 expiration date:2015-01-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=biology&portname=boinc-simap portname: devel/creduce description:Produces small test cases maintainer: po...@freebsd.org deprecated because: Unmaintained and depends on ancient LLVM 3.2 expiration date:2014-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=creduce portname: devel/fsmgenerator description:Finite State Machine generating software maintainer: po...@freebsd.org status: BROKEN deprecated because: Broken for more than 6 months expiration date:2014-11-26 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=devel&portname=fsmgenerator portname: games/djgame2 description:bluedj contains many popular online games maintainer: po...@freebsd.org status: BROKEN deprecated because: Online servers gone, game is not playable expiration date:2014-12-01 build errors: http://beefy2.isc.freebsd.org/bulk/101amd64-RELENG_10_1/latest/logs/errors/djgame2-3.2.0_4.log overview: http://portsmon.FreeBSD.org/portoverview.py?category=games&portname=djgame2 portname: lang/clay description:Language designed for generic programming maintainer: po...@freebsd.org deprecated because: No development since July 2013, depends on obsolete clang-3.2 expiration date:2014-12-01 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=lang&portname=clay portname: math/elmer-umfpack description:UMFPACK library used by ELMER FEM package maintainer: po...@freebsd.org deprecated because: Obsoleted by cad/elmerfem expiration date:2014-11-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=math&portname=elmer-umfpack portname: ports-mgmt/pib description:GUI Ports Collection management tool maintainer: po...@freebsd.org deprecated because: Does not work with tcl/tk 8.4+, does not support pkgng expiration date:2014-12-06 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=ports-mgmt&portname=pib portname: science/elmer-eio description:ELMER FEM Package Data base Interface maintainer: po...@freebsd.org deprecated because: Obsoleted by cad/elmerfem expiration date:2014-11-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=science&portname=elmer-eio portname: science/elmer-matc description:MatC language library used by ELMER FEM package maintainer: po...@freebsd.org deprecated because: Obsoleted by cad/elmerfem expiration date:2014-11-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=science&portname=elmer-matc portname: science/elmer-meshgen2d description:Mesh Generation Utility for use with the ELMER FEM package maintainer: po...@freebsd.org deprecated because: Obsoleted by cad/elmerfem expiration date:2014-11-07 build errors: none. overview: http://portsmon.FreeBSD.org/portoverview.py?category=science&portname=elmer-meshgen2d portname: science/elmergrid description:Mesh Manipulation Utility for use with the ELMER FEM package maintainer: po...@freebs
Re: Reducing the size of the ports tree (brainstorm v2)
On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin wrote: > Hi all, > > tijl@ spotted an interesting point, distinfo and pkg-descr files files > convenient are taking a lot of space for "free", we can reduce the size of the > while ports tree by a factor 2 by simply merging them into one of the other > files (Makefile and/or pkg-plist) from my testing it really devides > significantly the size of the tree. > > Problem is how to merge them if we want to. > > What we do not want to loose: > - Easyness of parsing distinfo > - Easyness to get informations about the description > > so far I have not been able to figure out a user friendly way > > Ideas I got so far only concerns pkg-descr: > Adding an entry in the Makefile for the WWW: > WWW= bla > or an entry in the plist: @www http... > > for the description the Makefile is not suitable as multi line entry in > Makefiles are painful > Maybe a new keyword: > @descr < mydesc > in > multiline > EOD > > which could easily be added to the plist parser in pkg. But I'm do not find > that > very friendly in particular for make(1) to extract the data. > > Concerning the distinfo I have no idea. > > so this mail is a call of ideas :), if nothing nice ideas is found we will > just > do nothing here :) > > regards, > Bapt At first I liked the idea, since I was wondering on my own if pkg-descr and distinfo couldnt be simply part of the Makefile. In vast majority of cases that would look good and wouldnt introduce too much content into existing Makefiles. There are ports like www/nginx or www/tengine that have enourmous distinfo files with number of entries that would ruin readability of their Makefiles, but so far I havent seen too many of these so I suppose they'd be the liveable drawbacks of new approach. However, after reading this discussion and some more tinkering about the idea I changed my mind - if the goal of current pkg&ports activities is to make the pkg the default way of installing packages and 'deprecate' ports when that happens, then the amount of work and the risk of breaking things by doing this ports improvement outweights its benefits. At this point I'd much rather like us to concentrate on making pkg a perfect replacement (I am mostly thinking about being able to package base for stripped down FreeBSD builds and pkg 'flavours' that would allow me install packages with custom options, like ports) and hold off making any changes to ports until we can safely state that 'pkg is the way to go for 99% of FreeBSD users and ports are for that 1% of package builders, nerds, tinkerers' etc., unless we simply cant move forward without some change. And just to be sure, I am not against improving ports, but rather about making better choice of where to put our limited resources - I am supper happy to get back to this discussion once we can replace ports with pkg :) Kind regards, Bartek Rutkowski ___ 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 you maintain which are out of date
Dear port maintainer, The portscout new distfile checker has detected that one or more of your ports appears to be out of date. Please take the opportunity to check each of the ports listed below, and if possible and appropriate, submit/commit an update. If any ports have already been updated, you can safely ignore the entry. You will not be e-mailed again for any of the port/version combinations below. Full details can be found at the following URL: http://portscout.freebsd.org/po...@freebsd.org.html Port| Current version | New version +-+ deskutils/mirall| 1.6.3 | 1.7.0 +-+ devel/gecode| 4.3.0 | 4.3.2 +-+ If any of the above results are invalid, please check the following page for details on how to improve portscout's detection and selection of distfiles on a per-port basis: http://portscout.freebsd.org/info/portscout-portconfig.txt 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: What is xmmintrin.h, and why aren't ports finding it?
On 07 Nov 2014, at 04:36, Chris H wrote: > > Greetings, > Working on a recent 11-CURRENT install > (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) > svn info /usr/ports Revision: 372176 > > Given the above, and the fact that I have installed lang/gcc-48. > Is there any reason that any port wanting to include xmmintrin.h > fails to find it? Even though dmesg && messages reflects the fact > that gcc48 is included within my $PATH? What you have in your PATH does not matter. The xmmintrin.h header contains SSE intrinsics, and should automatically be found by your gcc 4.8 port. Normally it is located in: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include/xmmintrin.h or if you have a slightly different gcc version, just run: find /usr/local/lib/gcc48 -name xmmintrin.h to find it. If you run: gcc48 -v -x c -c /dev/null -o /dev/null it should show you the paths it searches for include files (look for the "#include <...> search starts here:" line). For example, on my system this shows: #include <...> search starts here: /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include /usr/local/include /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include-fixed /usr/include End of search list. The directory where you found xmmintrin.h should be listed in the search directories. -Dimitry ___ 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"
new dependency for emacs-nox11
Emacs 24.4 update in ports pulls in a new dependency: desktop-file-utils. This in turn pulls in a big swath of additional packages including python, perl, pcre, glib. I cannot figure out what this utility is supposed to do, as all it refers to is "make a desktop". I don't have a desktop on freebsd nor do I run gnome. I do not understand the need for emacs to have a run-dependeny on this, especially the non-x11 version. I have zero desktop systems here (they're all servers) and nothing has X11 on it, and have no need for python and most cases perl. Is there a way that the port could be tweaked so that the desktop utilities are not installed when there is no desktop (ie, the nox11 variant)? My goal is to have a minimal footprint of software on my servers so I do not have to security audit all this extra software. Thanks for any info on why this is now included by default. ___ 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: new dependency for emacs-nox11
Vick Khera writes: > Emacs 24.4 update in ports pulls in a new dependency: desktop-file-utils. > This in turn pulls in a big swath of additional packages including python, > perl, pcre, glib. I don't think so. desktop-file-utils doesn't seem to pull in anything that isn't already required for emacs (glib being the big one, and libintl the only other, according to "pkg info"). What makes you say otherwise? > Is there a way that the port could be tweaked so that the desktop utilities > are not installed when there is no desktop (ie, the nox11 variant)? My goal > is to have a minimal footprint of software on my servers so I do not have > to security audit all this extra software. Yes, leaving that out seems fine. However, the footprint seems to be just a couple of command-line programs totalling 150KB, plus manuals and an elisp file for an editing mode. I don't currently have an X-library-free build environment, so unfortunately I can't make a definitive check on that statement. ___ 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: new dependency for emacs-nox11
On Fri, 07 Nov 2014 10:27:39 -0500 Lowell Gilbert wrote: > Vick Khera writes: > > > Emacs 24.4 update in ports pulls in a new dependency: > > desktop-file-utils. This in turn pulls in a big swath of additional > > packages including python, perl, pcre, glib. > > I don't think so. desktop-file-utils doesn't seem to pull in anything > that isn't already required for emacs (glib being the big one, and > libintl the only other, according to "pkg info"). Out of idle curiosity I removed the desktop-file-utils dependency and did a make all-depends-list in the nox slave port - glib wasn't there. ___ 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: new dependency for emacs-nox11
RW writes: > On Fri, 07 Nov 2014 10:27:39 -0500 > Lowell Gilbert wrote: > >> Vick Khera writes: >> >> > Emacs 24.4 update in ports pulls in a new dependency: >> > desktop-file-utils. This in turn pulls in a big swath of additional >> > packages including python, perl, pcre, glib. >> >> I don't think so. desktop-file-utils doesn't seem to pull in anything >> that isn't already required for emacs (glib being the big one, and >> libintl the only other, according to "pkg info"). > > Out of idle curiosity I removed the desktop-file-utils dependency and > did a make all-depends-list in the nox slave port - glib wasn't there. I stand corrected. The makefile isn't even confusing on that; I have no idea what I was thinking. ___ 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: new dependency for emacs-nox11
On 11/07/2014 09:25, Vick Khera wrote: > Emacs 24.4 update in ports pulls in a new dependency: desktop-file-utils. > This in turn pulls in a big swath of additional packages including python, > perl, pcre, glib. I cannot figure out what this utility is supposed to do, > as all it refers to is "make a desktop". I don't have a desktop on freebsd > nor do I run gnome. > > I do not understand the need for emacs to have a run-dependeny on this, > especially the non-x11 version. I have zero desktop systems here (they're > all servers) and nothing has X11 on it, and have no need for python and > most cases perl. > > Is there a way that the port could be tweaked so that the desktop utilities > are not installed when there is no desktop (ie, the nox11 variant)? My goal > is to have a minimal footprint of software on my servers so I do not have > to security audit all this extra software. > > Thanks for any info on why this is now included by default. The emacs port was fixed early this morning for this. Try updating? ___ 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: new dependency for emacs-nox11
On Fri, Nov 7, 2014 at 10:27 AM, Lowell Gilbert < freebsd-ports-lo...@be-well.ilk.org> wrote: > Vick Khera writes: > > > Emacs 24.4 update in ports pulls in a new dependency: desktop-file-utils. > > This in turn pulls in a big swath of additional packages including > python, > > perl, pcre, glib. > > I don't think so. desktop-file-utils doesn't seem to pull in anything > that isn't already required for emacs (glib being the big one, and > libintl the only other, according to "pkg info"). What makes you say > otherwise? > On one of my servers, I run "pkg install emacs-nox11" from my repo, which is build using poudriere with these options Options: ACL: off ALSA : off DBUS : off FILENOTIFY : off GNUTLS : off LTO: off OSS: off SOUND : off SOURCES: on XML: on The pkg install says it will pull in the following: New packages to be INSTALLED: emacs-nox11: 24.4,3 desktop-file-utils: 0.22_3 pcre: 8.35_1 glib: 2.36.3_4 python27: 2.7.8_6 libffi: 3.0.13_3 Compare old emacs 24.3 to 24.4 requirements: % pkg info -dr emacs-nox11 emacs-nox11-24.3_14,3 Depends on : libxml2-2.9.2_2 indexinfo-0.2 # pkg info -dr emacs-nox11 emacs-nox11-24.4,3 Depends on : libxml2-2.9.2_2 indexinfo-0.2 desktop-file-utils-0.22_3 Chasing down the chain we see that desktop-file-utils is what pulled in pcre and glib, and that glib pulled in python (which pulls in libffi). I already had perl, gettext, and libiconv from other dependencies installed. > > > Is there a way that the port could be tweaked so that the desktop > utilities > > are not installed when there is no desktop (ie, the nox11 variant)? My > goal > > is to have a minimal footprint of software on my servers so I do not have > > to security audit all this extra software. > > Yes, leaving that out seems fine. However, the footprint seems to be > just a couple of command-line programs totalling 150KB, plus manuals and > an elisp file for an editing mode. I don't currently have an > X-library-free build environment, so unfortunately I can't make a > definitive check on that statement. > Any non-zero footprint has the potential to open up security holes. The size is not really the issue. I'm also personally unclear why glib needs perl and python as a run-time dependency, but that's only from a cursory look at it. ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski wrote > On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin wrote: > > Hi all, > > > > tijl@ spotted an interesting point, distinfo and pkg-descr files files > > convenient are taking a lot of space for "free", we can reduce the size of > > the while ports tree by a factor 2 by simply merging them into one of the > > other files (Makefile and/or pkg-plist) from my testing it really devides > > significantly the size of the tree. > > > > Problem is how to merge them if we want to. > > > > What we do not want to loose: > > - Easyness of parsing distinfo > > - Easyness to get informations about the description > > > > so far I have not been able to figure out a user friendly way > > > > Ideas I got so far only concerns pkg-descr: > > Adding an entry in the Makefile for the WWW: > > WWW= bla > > or an entry in the plist: @www http... > > > > for the description the Makefile is not suitable as multi line entry in > > Makefiles are painful > > Maybe a new keyword: > > @descr < > mydesc > > in > > multiline > > EOD > > > > which could easily be added to the plist parser in pkg. But I'm do not find > > that very friendly in particular for make(1) to extract the data. > > > > Concerning the distinfo I have no idea. > > > > so this mail is a call of ideas :), if nothing nice ideas is found we will > > just do nothing here :) > > > > regards, > > Bapt > > At first I liked the idea, since I was wondering on my own if > pkg-descr and distinfo couldnt be simply part of the Makefile. In vast > majority of cases that would look good and wouldnt introduce too much > content into existing Makefiles. There are ports like www/nginx or > www/tengine that have enourmous distinfo files with number of entries > that would ruin readability of their Makefiles, but so far I havent > seen too many of these so I suppose they'd be the liveable drawbacks > of new approach. > > However, after reading this discussion and some more tinkering about > the idea I changed my mind - if the goal of current pkg&ports > activities is to make the pkg the default way of installing packages > and 'deprecate' ports when that happens, Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the intended result of the introduction of pkg(8). That would be a _horrible_ decision. For more reasons than I can list in a mailing list reply. Honestly. If this is true, has any real thought gone into the potential consequences resulting from this? We're not just talking about the affects on "geeks", and "hobbyists" here. We're talking about Shops, and Businesses that create specific products, for specific needs, and chose *BSD for what at least _was_ the freedom, and amount of _choices_ it offered. Making it, by comparison, more _flexible_ than it's alternatives. You'll effectively eliminate that market, traveling in the direction you appear to be going. If what I understand you to be saying is true. It appears FreeBSD is simply looking to parrot Linux, and relinquish "The power to serve". In exchange for competing for a strictly Desktop market. If true. This will mark a very dark year in history, for FreeBSD. Sincerely, Disappointed. > then the amount of work and > the risk of breaking things by doing this ports improvement outweights > its benefits. At this point I'd much rather like us to concentrate on > making pkg a perfect replacement (I am mostly thinking about being > able to package base for stripped down FreeBSD builds and pkg > 'flavours' that would allow me install packages with custom options, > like ports) and hold off making any changes to ports until we can > safely state that 'pkg is the way to go for 99% of FreeBSD users and > ports are for that 1% of package builders, nerds, tinkerers' etc., > unless we simply cant move forward without some change. And just to be > sure, I am not against improving ports, but rather about making better > choice of where to put our limited resources - I am supper happy to > get back to this discussion once we can replace ports with pkg :) > > Kind regards, > Bartek Rutkowski > ___ > 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: What is xmmintrin.h, and why aren't ports finding it?
On Fri, 7 Nov 2014 13:10:51 +0100 Dimitry Andric wrote > On 07 Nov 2014, at 04:36, Chris H wrote: > > > > Greetings, > > Working on a recent 11-CURRENT install > > (11-CURRENT #1 amd64 r274134 Nov 5 12:56:14 PST 2014) > > svn info /usr/ports Revision: 372176 > > > > Given the above, and the fact that I have installed lang/gcc-48. > > Is there any reason that any port wanting to include xmmintrin.h > > fails to find it? Even though dmesg && messages reflects the fact > > that gcc48 is included within my $PATH? > > What you have in your PATH does not matter. The xmmintrin.h header > contains SSE intrinsics, and should automatically be found by your gcc > 4.8 port. Normally it is located in: > > /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include/xmmintrin.h > > or if you have a slightly different gcc version, just run: > > find /usr/local/lib/gcc48 -name xmmintrin.h > > to find it. If you run: > > gcc48 -v -x c -c /dev/null -o /dev/null > > it should show you the paths it searches for include files (look for the > "#include <...> search starts here:" line). For example, on my system > this shows: > > #include <...> search starts here: > /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include > /usr/local/include > /usr/local/lib/gcc48/gcc/i386-portbld-freebsd11.0/4.8.4/include-fixed > /usr/include > End of search list. > > The directory where you found xmmintrin.h should be listed in the search > directories. > Thank you _very_ much for the reply, Dimitry. Indeed, following your example above. Indicates that xmmintrin.h _is_ in the search path. I think it must be a matter of _which_ CC USE_GCC is defaulting to. I'll have to examine things in that range, a little closer. Thank you again, for the informative reply, Dimitry. --Chris > -Dimitry > > ___ > 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: Reducing the size of the ports tree (brainstorm v2)
On Fri, Nov 7, 2014 at 6:47 PM, Chris H wrote: > On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski wrote > >> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin wrote: >> > Hi all, >> > >> > tijl@ spotted an interesting point, distinfo and pkg-descr files files >> > convenient are taking a lot of space for "free", we can reduce the size of >> > the while ports tree by a factor 2 by simply merging them into one of the >> > other files (Makefile and/or pkg-plist) from my testing it really devides >> > significantly the size of the tree. >> > >> > Problem is how to merge them if we want to. >> > >> > What we do not want to loose: >> > - Easyness of parsing distinfo >> > - Easyness to get informations about the description >> > >> > so far I have not been able to figure out a user friendly way >> > >> > Ideas I got so far only concerns pkg-descr: >> > Adding an entry in the Makefile for the WWW: >> > WWW= bla >> > or an entry in the plist: @www http... >> > >> > for the description the Makefile is not suitable as multi line entry in >> > Makefiles are painful >> > Maybe a new keyword: >> > @descr <> > mydesc >> > in >> > multiline >> > EOD >> > >> > which could easily be added to the plist parser in pkg. But I'm do not find >> > that very friendly in particular for make(1) to extract the data. >> > >> > Concerning the distinfo I have no idea. >> > >> > so this mail is a call of ideas :), if nothing nice ideas is found we will >> > just do nothing here :) >> > >> > regards, >> > Bapt >> >> At first I liked the idea, since I was wondering on my own if >> pkg-descr and distinfo couldnt be simply part of the Makefile. In vast >> majority of cases that would look good and wouldnt introduce too much >> content into existing Makefiles. There are ports like www/nginx or >> www/tengine that have enourmous distinfo files with number of entries >> that would ruin readability of their Makefiles, but so far I havent >> seen too many of these so I suppose they'd be the liveable drawbacks >> of new approach. >> >> However, after reading this discussion and some more tinkering about >> the idea I changed my mind - if the goal of current pkg&ports >> activities is to make the pkg the default way of installing packages >> and 'deprecate' ports when that happens, > Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the > intended result of the introduction of pkg(8). That would be a > _horrible_ decision. For more reasons than I can list in a mailing > list reply. Honestly. If this is true, has any real thought gone into > the potential consequences resulting from this? We're not just talking > about the affects on "geeks", and "hobbyists" here. We're talking about > Shops, and Businesses that create specific products, for specific needs, > and chose *BSD for what at least _was_ the freedom, and amount of > _choices_ it offered. Making it, by comparison, more _flexible_ than > it's alternatives. You'll effectively eliminate that market, traveling > in the direction you appear to be going. > If what I understand you to be saying is true. It appears FreeBSD is > simply looking to parrot Linux, and relinquish "The power to serve". > In exchange for competing for a strictly Desktop market. If true. > This will mark a very dark year in history, for FreeBSD. > > Sincerely, > Disappointed. I think we've a little misunderstanding here. At no point I've said nor heard that ports are about to be eliminated. I did hovewer heard that the goal is to deprecate them, as in, encourage users to move to pkg entirely, once pkg is a viable ports replacement, and to make that a default way to install/maintain software on FreeBSD. At the end, it would be very hard to 'eliminate' ports, since we still have to generate the packages with something, dont we? ;) Even said that, I could be completely wrong here, misunderstood someone else and so on, and by no means this discussion is a statement of what is going on to happen with ports/pkg oficially, so, to quote D. Adams: DON'T PANIC. :) Kind regards, Bartek Rutkowski > >> then the amount of work and >> the risk of breaking things by doing this ports improvement outweights >> its benefits. At this point I'd much rather like us to concentrate on >> making pkg a perfect replacement (I am mostly thinking about being >> able to package base for stripped down FreeBSD builds and pkg >> 'flavours' that would allow me install packages with custom options, >> like ports) and hold off making any changes to ports until we can >> safely state that 'pkg is the way to go for 99% of FreeBSD users and >> ports are for that 1% of package builders, nerds, tinkerers' etc., >> unless we simply cant move forward without some change. And just to be >> sure, I am not against improving ports, but rather about making better >> choice of where to put our limited resources - I am supper happy to >> get back to this discussion once we can replace ports with pkg :) >> >> Kind regards, >> Bartek Rutkowski >> ___
Re: Reducing the size of the ports tree (brainstorm v2)
On Fri, 7 Nov 2014 19:32:25 +0100 Bartek Rutkowski wrote > On Fri, Nov 7, 2014 at 6:47 PM, Chris H wrote: > > On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski > > wrote > > >> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin > >> wrote: > Hi all, > >> > > >> > tijl@ spotted an interesting point, distinfo and pkg-descr files files > >> > convenient are taking a lot of space for "free", we can reduce the size > >> > of the while ports tree by a factor 2 by simply merging them into one of > >> > the other files (Makefile and/or pkg-plist) from my testing it really > >> > devides significantly the size of the tree. > >> > > >> > Problem is how to merge them if we want to. > >> > > >> > What we do not want to loose: > >> > - Easyness of parsing distinfo > >> > - Easyness to get informations about the description > >> > > >> > so far I have not been able to figure out a user friendly way > >> > > >> > Ideas I got so far only concerns pkg-descr: > >> > Adding an entry in the Makefile for the WWW: > >> > WWW= bla > >> > or an entry in the plist: @www http... > >> > > >> > for the description the Makefile is not suitable as multi line entry in > >> > Makefiles are painful > >> > Maybe a new keyword: > >> > @descr < >> > mydesc > >> > in > >> > multiline > >> > EOD > >> > > >> > which could easily be added to the plist parser in pkg. But I'm do not > >> > find that very friendly in particular for make(1) to extract the data. > >> > > >> > Concerning the distinfo I have no idea. > >> > > >> > so this mail is a call of ideas :), if nothing nice ideas is found we > >> > will just do nothing here :) > >> > > >> > regards, > >> > Bapt > >> > >> At first I liked the idea, since I was wondering on my own if > >> pkg-descr and distinfo couldnt be simply part of the Makefile. In vast > >> majority of cases that would look good and wouldnt introduce too much > >> content into existing Makefiles. There are ports like www/nginx or > >> www/tengine that have enourmous distinfo files with number of entries > >> that would ruin readability of their Makefiles, but so far I havent > >> seen too many of these so I suppose they'd be the liveable drawbacks > >> of new approach. > >> > >> However, after reading this discussion and some more tinkering about > >> the idea I changed my mind - if the goal of current pkg&ports > >> activities is to make the pkg the default way of installing packages > >> and 'deprecate' ports when that happens, > > Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the > > intended result of the introduction of pkg(8). That would be a > > _horrible_ decision. For more reasons than I can list in a mailing > > list reply. Honestly. If this is true, has any real thought gone into > > the potential consequences resulting from this? We're not just talking > > about the affects on "geeks", and "hobbyists" here. We're talking about > > Shops, and Businesses that create specific products, for specific needs, > > and chose *BSD for what at least _was_ the freedom, and amount of > > _choices_ it offered. Making it, by comparison, more _flexible_ than > > it's alternatives. You'll effectively eliminate that market, traveling > > in the direction you appear to be going. > > If what I understand you to be saying is true. It appears FreeBSD is > > simply looking to parrot Linux, and relinquish "The power to serve". > > In exchange for competing for a strictly Desktop market. If true. > > This will mark a very dark year in history, for FreeBSD. > > > > Sincerely, > > Disappointed. > Thank you for the reply, and clarification, Bartek. > I think we've a little misunderstanding here. At no point I've said > nor heard that ports are about to be eliminated. I did hovewer heard > that the goal is to deprecate them, as in, encourage users to move to > pkg entirely, once pkg is a viable ports replacement, and to make that > a default way to install/maintain software on FreeBSD. At the end, it > would be very hard to 'eliminate' ports, since we still have to > generate the packages with something, dont we? ;) One wouldn't think so. But I've been surprised before. :) > Even said that, I > could be completely wrong here, misunderstood someone else and so on, > and by no means this discussion is a statement of what is going on to > happen with ports/pkg oficially, so, to quote D. Adams: DON'T PANIC. > :) Well. So could I. Hopefully I am. :) Thanks again, for the thoughtful reply, Bartek. --Chris > > Kind regards, > Bartek Rutkowski > > > > >> then the amount of work and > >> the risk of breaking things by doing this ports improvement outweights > >> its benefits. At this point I'd much rather like us to concentrate on > >> making pkg a perfect replacement (I am mostly thinking about being > >> able to package base for stripped down FreeBSD builds and pkg > >> 'flavours' that would allow me install packages with custom options, > >> like ports) and hold off making any changes to ports until we can > >> sa
Re: Reducing the size of the ports tree (brainstorm v2)
On 11/07/14 10:32, Bartek Rutkowski wrote: > On Fri, Nov 7, 2014 at 6:47 PM, Chris H wrote: >> On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski wrote >> >>> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin >>> wrote: Hi all, tijl@ spotted an interesting point, distinfo and pkg-descr files files convenient are taking a lot of space for "free", we can reduce the size of the while ports tree by a factor 2 by simply merging them into one of the other files (Makefile and/or pkg-plist) from my testing it really devides significantly the size of the tree. Problem is how to merge them if we want to. What we do not want to loose: - Easyness of parsing distinfo - Easyness to get informations about the description so far I have not been able to figure out a user friendly way Ideas I got so far only concerns pkg-descr: Adding an entry in the Makefile for the WWW: WWW= bla or an entry in the plist: @www http... for the description the Makefile is not suitable as multi line entry in Makefiles are painful Maybe a new keyword: @descr <>>> mydesc in multiline EOD which could easily be added to the plist parser in pkg. But I'm do not find that very friendly in particular for make(1) to extract the data. Concerning the distinfo I have no idea. so this mail is a call of ideas :), if nothing nice ideas is found we will just do nothing here :) regards, Bapt >>> At first I liked the idea, since I was wondering on my own if >>> pkg-descr and distinfo couldnt be simply part of the Makefile. In vast >>> majority of cases that would look good and wouldnt introduce too much >>> content into existing Makefiles. There are ports like www/nginx or >>> www/tengine that have enourmous distinfo files with number of entries >>> that would ruin readability of their Makefiles, but so far I havent >>> seen too many of these so I suppose they'd be the liveable drawbacks >>> of new approach. >>> >>> However, after reading this discussion and some more tinkering about >>> the idea I changed my mind - if the goal of current pkg&ports >>> activities is to make the pkg the default way of installing packages >>> and 'deprecate' ports when that happens, >> Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the >> intended result of the introduction of pkg(8). That would be a >> _horrible_ decision. For more reasons than I can list in a mailing >> list reply. Honestly. If this is true, has any real thought gone into >> the potential consequences resulting from this? We're not just talking >> about the affects on "geeks", and "hobbyists" here. We're talking about >> Shops, and Businesses that create specific products, for specific needs, >> and chose *BSD for what at least _was_ the freedom, and amount of >> _choices_ it offered. Making it, by comparison, more _flexible_ than >> it's alternatives. You'll effectively eliminate that market, traveling >> in the direction you appear to be going. >> If what I understand you to be saying is true. It appears FreeBSD is >> simply looking to parrot Linux, and relinquish "The power to serve". >> In exchange for competing for a strictly Desktop market. If true. >> This will mark a very dark year in history, for FreeBSD. >> >> Sincerely, >> Disappointed. > I think we've a little misunderstanding here. At no point I've said > nor heard that ports are about to be eliminated. I did hovewer heard > that the goal is to deprecate them, as in, encourage users to move to > pkg entirely "Please explain [ not directed to THIS post, but to the THREAD maybe... ] the narrowing-of-choice encouragement reasons" I am trying triply to politely address the issues and apologize in advance for any perceived disrespect to the points I am directly replying to... > , once pkg is a viable ports replacement, Once upon a time /var/db/pkg and upstream .tbz served as a "pkg".. that is, a tracking of ports, and a prebuilt subset of ports. Nowhere did I ever imagine that a replacment for /var/db/pkg would encourage the non use, replacement, deprecation, discouragement, ... Again, with apologies. > and to make that > a default way to install/maintain software on FreeBSD. If that existed before portmaster, portupgrade were written, how would they have come into existence? How about "a convenient and reliable" ?? More below... > At the end, it > would be very hard to 'eliminate' ports, since we still have to > generate the packages with something, dont we? Spot on. Not only that... I always thought ports were FreeBSD's strong point. Maintainers, ... innovations... new scripts... new categories... > ;) Even said that, I > could be completely wrong here, misunderstood someone else and so on, > and by no means this discussion is a statement of what is going on to > happen with ports/pkg oficially, so, to quote D. Adams:
mail-notification only allows Gmail mailboxes?
I've built mail/mail-notification with these options: root@kg-core1# make showconfig ===> The following configuration options are available for mail-notification-5.4_15: EVOLUTION=off: Evolution support GMAIL=on: Gmail support IMAP=on: IMAP support MAILDIR=on: Maildir support MBOX=on: mbox support MH=on: MH support MOZILLA=on: Mozilla products support POP3=on: POP3 support SASL=on: SASL authentication support SSL=on: SSL protocol support SYLPHEED=on: Sylpheed support ===> Use 'make config' to modify these settings this is on FreeBSD 9.3-stable: tingo@kg-core1$ uname -a FreeBSD kg-core1.kg4.no 9.3-STABLE FreeBSD 9.3-STABLE #0 r273918: Fri Oct 31 22:52:44 CET 2014 r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 the problem is that when I start mail-notification I get these error messages in a dialog box: Errors have occurred while loading the mailboxes configuration On line 3: unknown mailbox type "imap". On line 4: unknown mailbox type "pop3". On line 5: unknown mailbox type "imap". On line 7: unknown mailbox type "imap". and when I open the propertyies dialog and try to add another mailbox, I can only choose "Autodetect" and "Gmail". Any idea what's wrong? -- Regards, Torfinn Ingolfsen ___ 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: Reducing the size of the ports tree (brainstorm v2)
On Fri, Nov 7, 2014 at 9:15 PM, Jeffrey Bouquet via freebsd-ports wrote: > > On 11/07/14 10:32, Bartek Rutkowski wrote: >> On Fri, Nov 7, 2014 at 6:47 PM, Chris H wrote: >>> On Fri, 7 Nov 2014 09:08:28 + Bartek Rutkowski wrote >>> On Fri, Oct 31, 2014 at 6:56 PM, Baptiste Daroussin wrote: > Hi all, > > tijl@ spotted an interesting point, distinfo and pkg-descr files files > convenient are taking a lot of space for "free", we can reduce the size of > the while ports tree by a factor 2 by simply merging them into one of the > other files (Makefile and/or pkg-plist) from my testing it really devides > significantly the size of the tree. > > Problem is how to merge them if we want to. > > What we do not want to loose: > - Easyness of parsing distinfo > - Easyness to get informations about the description > > so far I have not been able to figure out a user friendly way > > Ideas I got so far only concerns pkg-descr: > Adding an entry in the Makefile for the WWW: > WWW= bla > or an entry in the plist: @www http... > > for the description the Makefile is not suitable as multi line entry in > Makefiles are painful > Maybe a new keyword: > @descr < mydesc > in > multiline > EOD > > which could easily be added to the plist parser in pkg. But I'm do not > find > that very friendly in particular for make(1) to extract the data. > > Concerning the distinfo I have no idea. > > so this mail is a call of ideas :), if nothing nice ideas is found we will > just do nothing here :) > > regards, > Bapt At first I liked the idea, since I was wondering on my own if pkg-descr and distinfo couldnt be simply part of the Makefile. In vast majority of cases that would look good and wouldnt introduce too much content into existing Makefiles. There are ports like www/nginx or www/tengine that have enourmous distinfo files with number of entries that would ruin readability of their Makefiles, but so far I havent seen too many of these so I suppose they'd be the liveable drawbacks of new approach. However, after reading this discussion and some more tinkering about the idea I changed my mind - if the goal of current pkg&ports activities is to make the pkg the default way of installing packages and 'deprecate' ports when that happens, >>> Aak! Seriously?! Eliminate ports? I _sincerely_ hope that isn't the >>> intended result of the introduction of pkg(8). That would be a >>> _horrible_ decision. For more reasons than I can list in a mailing >>> list reply. Honestly. If this is true, has any real thought gone into >>> the potential consequences resulting from this? We're not just talking >>> about the affects on "geeks", and "hobbyists" here. We're talking about >>> Shops, and Businesses that create specific products, for specific needs, >>> and chose *BSD for what at least _was_ the freedom, and amount of >>> _choices_ it offered. Making it, by comparison, more _flexible_ than >>> it's alternatives. You'll effectively eliminate that market, traveling >>> in the direction you appear to be going. >>> If what I understand you to be saying is true. It appears FreeBSD is >>> simply looking to parrot Linux, and relinquish "The power to serve". >>> In exchange for competing for a strictly Desktop market. If true. >>> This will mark a very dark year in history, for FreeBSD. >>> >>> Sincerely, >>> Disappointed. >> I think we've a little misunderstanding here. At no point I've said >> nor heard that ports are about to be eliminated. I did hovewer heard >> that the goal is to deprecate them, as in, encourage users to move to >> pkg entirely > "Please explain [ not directed to THIS post, but to the > THREAD maybe... ] the narrowing-of-choice encouragement reasons" > > I am trying triply to politely address the issues and apologize in > advance for any perceived disrespect to the points I am directly > replying to... >> , once pkg is a viable ports replacement, > Once upon a time /var/db/pkg and upstream .tbz served as a "pkg".. > that is, a tracking of ports, and a prebuilt subset of ports. Nowhere did I > ever imagine that a replacment for /var/db/pkg would encourage the non > use, replacement, deprecation, discouragement, ... > > Again, with apologies. > >> and to make that >> a default way to install/maintain software on FreeBSD. > If that existed before portmaster, portupgrade were written, how would they > have come into existence? > > How about "a convenient and reliable" ?? More below... >> At the end, it >> would be very hard to 'eliminate' ports, since we still have to >> generate the packages with something, dont we? > Spot on. > Not only that... I always thought ports were FreeBSD's > strong point. Maintainers, ... innovations... new scripts... new > categories... > >> ;) Even said
CURRENT Revision: 274250 breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2
Out of the blue the build of port x11/nvidia-driver fails - portmaster is that sloppy that it can not check BEFORE it kills the existent driver and fails to install after the deletion! The src tree is at Revision: 274250 and with Revision r274177 the build works. The failure is: ===> Registering installation for nvidia-driver-343.22 pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so To use these drivers, make sure that you have loaded the NVidia kernel module, by doing [...] Please can someone fix this? I have three boxes now without graphics due to this. Regards, Oliver pgpxpHCLzxOSI.pgp Description: OpenPGP digital signature
CURRENT breaks build of x11/nvidia-driver: pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2
Out of the blue the build of port x11/nvidia-driver fails - portmaster is that sloppy that it can not check BEFORE it kills the existent driver and fails to install after the deletion! The src tree is at Revision: 274250 and with Revision r274177 the build works. The failure is: ===> Registering installation for nvidia-driver-343.22 pkg-static: nvidia-driver-343.22 conflicts with libEGL-10.3.2 (installs files into the same place). Problematic file: /usr/local/lib/libEGL.so To use these drivers, make sure that you have loaded the NVidia kernel module, by doing [...] Please can someone fix this? I have three boxes now without graphics due to this. Regards, Oliver pgpPLUfwLQ9uk.pgp Description: OpenPGP digital signature
py27-pillow-2.6.0 fails if tkinter option is on
root@kg-core1# make showconfig ===> The following configuration options are available for py27-pillow-2.6.0: FREETYPE=on: TrueType font rendering support JPEG=on: JPEG image format support LCMS=on: Little Color Management System PNG=on: PNG image format support TIFF=on: TIFF image format support TKINTER=on: Tkinter (Tcl/Tk) BitmapImage & PhotoImage support WEBP=on: WebP image format support ===> Use 'make config' to modify these settings on tingo@kg-core1$ uname -a FreeBSD kg-core1.kg4.no 9.3-STABLE FreeBSD 9.3-STABLE #0 r273918: Fri Oct 31 22:52:44 CET 2014 r...@kg-core1.kg4.no:/usr/obj/usr/src/sys/GENERIC amd64 root@kg-core1# make ===> License PIL accepted by the user ===> Found saved configuration for py27-pillow-2.6.0 ===> py27-pillow-2.6.0 depends on file: /usr/local/sbin/pkg - found ===> Fetching all distfiles required by py27-pillow-2.6.0 for building ===> Extracting for py27-pillow-2.6.0 => SHA256 Checksum OK for Pillow-2.6.0.tar.gz. ===> Patching for py27-pillow-2.6.0 ===> py27-pillow-2.6.0 depends on package: py27-setuptools27>0 - found ===> py27-pillow-2.6.0 depends on file: /usr/local/bin/python2.7 - found ===> py27-pillow-2.6.0 depends on executable: wish8.6 - found ===> py27-pillow-2.6.0 depends on shared library: libfreetype.so - found (/usr/local/lib/libfreetype.so.6.11.2) ===> py27-pillow-2.6.0 depends on shared library: libjpeg.so - found (/usr/local/lib/libjpeg.so.11) ===> py27-pillow-2.6.0 depends on shared library: liblcms2.so - found (/usr/local/lib/liblcms2.so.2.0.6) ===> py27-pillow-2.6.0 depends on shared library: libtiff.so - found (/usr/local/lib/libtiff.so.4) ===> py27-pillow-2.6.0 depends on shared library: libwebp.so - found (/usr/local/lib/libwebp.so.5.0.1) ===> Configuring for py27-pillow-2.6.0 running config ===> Staging for py27-pillow-2.6.0 ===> py27-pillow-2.6.0 depends on package: py27-setuptools27>0 - found ===> py27-pillow-2.6.0 depends on file: /usr/local/bin/python2.7 - found ===> Generating temporary packing list running build running build_py creating build creating build/lib.freebsd-9.3-STABLE-amd64-2.7 creating build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/BdfFontFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/BmpImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/BufrStubImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ContainerIO.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/CurImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/DcxImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/EpsImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ExifTags.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/FitsStubImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/FliImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/FontFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/FpxImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GbrImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GdImageFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GifImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GimpGradientFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GimpPaletteFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/GribStubImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/Hdf5StubImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/IcnsImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/IcoImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImImagePlugin.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/Image.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageChops.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageCms.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageColor.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageDraw.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageDraw2.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageEnhance.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageFile.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageFileIO.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageFilter.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageFont.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageGrab.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageMath.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageMode.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageMorph.py -> build/lib.freebsd-9.3-STABLE-amd64-2.7/PIL copying PIL/ImageOps.py -> build/lib.freebsd-9.3-ST
Re: FreeBSD Port: devel/tortoisehg - is not compatible with Mercurial version 3.2
arrowdodger wrote, On 09/25/2014 07:48: On Thu, Sep 25, 2014 at 12:54 AM, Miroslav Lachman <000.f...@quip.cz> wrote: arrowdodger wrote, On 09/21/2014 11:34: On Fri, Sep 19, 2014 at 2:10 PM, Miroslav Lachman <000.f...@quip.cz> wrote: Hi, I tried to install TortoiseHG on FreeBSD 10 (PC-BSD), but it doesn't work, because it is not compatible with Mercurial 3.1.1 (version in ports tree). [...] Can you please update TortoiseHG to more current version? The website http://tortoisehg.bitbucket.org/ has: | * 2014-09-04: TortoiseHg 3.1.1 (with Mercurial 3.1.1) released * 2014-08-03: TortoiseHg 3.1 (with Mercurial 3.1+2) released Miroslav Lachman Oh, right. I've got taken away by $WORK. Will update the port ASAP. Thank you, I really appreciate your work. Miroslav Lachman Here's a PR [1] with a port patch, if you dont want to wait for the commit. [1]: https://bugs.freebsd.org/bugzilla/show_bug.cgi?id=193812 Hi, I am sorry to disturbing you again, but ports tree now has Mercurial 3.2 and it is not comaptible with TortoiseHG 3.1.1. So it cannot be used on newly installed machines and/or with packages. Can you please update TortoiseHG port again? Miroslav Lachman ___ 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"
How exactly does the base toolchain determine WHICH language to build with?
Greetings, Sorry for the long title. I've been [needlessly] struggling with getting ports within the ports tree to build, on a fresh 11-CURRENT install from 2014-11-05. With custom KERNEL and WORLD built, and installed. Here's my situation, which has worked well since ~8.2; make.conf(5) WITHOUT_CLANG=true FAVORITE_COMPILER=gcc src.conf(5) WITHOUT_CLANG=true I'll neither argue, nor defend rational for w/o clang. To boring and out of scope for this thread. That said; I realize that lang/clang(33/34/35) is the default toolchain for 10+, and that's just fine by me. So I shouldn't be terribly surprised when install kernel/world, followed by make delete-old removes the clang built, or provided by the base install from the (initial) install procedure. But what _does_ surprise me, is that the install of lang/gcc-48 does _not_ become the compiler of choice with the above $ENV, after [seemingly] deleting clang. I understand that it may not be advisable to eliminate the default [base] toolchain. But leaving only remnants of clang, causes quite a bit of what I would consider POLA. Given that clang's bin files are [still] located in /usr/bin, while additional compilers are located in /usr/local/bin. All past installs -- even an older 11, did not exhibit this problem. What's changed? What's the rational, and how to best setup an effective build $ENV under the current circumstances? Or is this simply an [unintended] anomaly? Currently, the only way I can envision overcoming this, is by way of make.conf(5). Using the CC, CXX, and CPP directives. Which IMHO is not ideal. Thank you for all your time, and consideration, and sorry for the somewhat longish post. --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"
FreeBSD Port: ruby21-2.1.3_1,1
Hello, I just installed ruby21-2.1.3_1,1 with the DEBUG option *unset*, and when ruby21 is invoked, it prints out: WARNING: number of probes fixed does not match the number of defined probes (9 != 50, respectively) WARNING: some probes might not fire or your program might crash I haven't used dtrace yet and don't know much about it, but I discovered that if I re-installed the port with DEBUG turned on (*set*), then the warning messages aren't printed. I'm guessing that the probes.d file in the ruby source arranges to install some probes at runtime in some routines that don't get compiled into ruby if DEBUG is off. Is it appropriate to just tell you about this? Should I file a bug report someplace else? Thank you for your work on the ruby ports! Regards, Carol -- Carol Deihl - ca...@westryn.net Shrier and Deihl, Westryn Internet Services Internet Software Development and Hosting Remote Unix Admin, Security http://www.westryn.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: mail-notification only allows Gmail mailboxes?
On 8 November 2014 09:18, Torfinn Ingolfsen wrote: > I've built mail/mail-notification with these options: > root@kg-core1# make showconfig > ===> The following configuration options are available for > mail-notification-5.4_15: > EVOLUTION=off: Evolution support > GMAIL=on: Gmail support > IMAP=on: IMAP support > MAILDIR=on: Maildir support > MBOX=on: mbox support > MH=on: MH support > MOZILLA=on: Mozilla products support > POP3=on: POP3 support > SASL=on: SASL authentication support > SSL=on: SSL protocol support > SYLPHEED=on: Sylpheed support > ===> Use 'make config' to modify these settings I'm not seeing your errors - but my options differs from yours in that I have MOZILLA=off. I'm also running 10/STABLE Cheers. -- Jonathan Chen ___ 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 exactly does the base toolchain determine WHICH language to build with?
On Fri, Nov 7, 2014 at 6:23 PM, Chris H wrote:
> Greetings,
> Sorry for the long title. I've been [needlessly] struggling
> with getting ports within the ports tree to build, on a
> fresh 11-CURRENT install from 2014-11-05. With custom
> KERNEL and WORLD built, and installed.
> Here's my situation, which has worked well since ~8.2;
> make.conf(5)
> WITHOUT_CLANG=true
> FAVORITE_COMPILER=gcc
> src.conf(5)
> WITHOUT_CLANG=true
>
> I'll neither argue, nor defend rational for w/o clang. To
> boring and out of scope for this thread. That said; I
> realize that lang/clang(33/34/35) is the default toolchain
> for 10+, and that's just fine by me. So I shouldn't be
lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
version of clang that is included in the FreeBSD source (/usr/src).
> terribly surprised when install kernel/world, followed by
> make delete-old removes the clang built, or provided by
> the base install from the (initial) install procedure. But
> what _does_ surprise me, is that the install of lang/gcc-48
> does _not_ become the compiler of choice with the above
> $ENV, after [seemingly] deleting clang. I understand that
FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
If you want ports to build with lang/gcc-48, then you would need to
check that the ports you are trying to compile have either
USES=compiler or USES_GCC defined in their Makefile. Otherwise the
ports will use the compiler that is provided by the FreeBSD source
(gcc 2.4.x or clang).
When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
source will be built using gcc 2.4.x from the FreeBSD source.
/usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
will then use this version to build if there is no USES_GCC or
USES=compiler in the ports Makefile.
--
DISCLAIMER:
No electrons were maimed while sending this message. Only slightly bruised.
___
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 exactly does the base toolchain determine WHICH language to build with?
On Fri, 7 Nov 2014 22:39:27 -0600 Scot Hetzel wrote
> On Fri, Nov 7, 2014 at 6:23 PM, Chris H wrote:
> > Greetings,
> > Sorry for the long title. I've been [needlessly] struggling
> > with getting ports within the ports tree to build, on a
> > fresh 11-CURRENT install from 2014-11-05. With custom
> > KERNEL and WORLD built, and installed.
> > Here's my situation, which has worked well since ~8.2;
> > make.conf(5)
> > WITHOUT_CLANG=true
> > FAVORITE_COMPILER=gcc
> > src.conf(5)
> > WITHOUT_CLANG=true
> >
> > I'll neither argue, nor defend rational for w/o clang. To
> > boring and out of scope for this thread. That said; I
> > realize that lang/clang(33/34/35) is the default toolchain
> > for 10+, and that's just fine by me. So I shouldn't be
>
> lang/clang(33/34/35) is not the default toolchain in 10+. 10+ uses a
> version of clang that is included in the FreeBSD source (/usr/src).
>
> > terribly surprised when install kernel/world, followed by
> > make delete-old removes the clang built, or provided by
> > the base install from the (initial) install procedure. But
> > what _does_ surprise me, is that the install of lang/gcc-48
> > does _not_ become the compiler of choice with the above
> > $ENV, after [seemingly] deleting clang. I understand that
>
> FAVORITE_COMPILER is used by Mk/Uses/compiler.mk.
>
> If you want ports to build with lang/gcc-48, then you would need to
> check that the ports you are trying to compile have either
> USES=compiler or USES_GCC defined in their Makefile. Otherwise the
> ports will use the compiler that is provided by the FreeBSD source
> (gcc 2.4.x or clang).
>
> When WITHOUT_CLANG is defined in make.conf/src.conf. The FreeBSD
> source will be built using gcc 2.4.x from the FreeBSD source.
> /usr/bin/{cc,c++} will then be linked to the gcc versions. The ports
> will then use this version to build if there is no USES_GCC or
> USES=compiler in the ports Makefile.
Perfect, and thank you very much, Scott, for the clarification.
For what ever reason. Mine (CC,cc++,...) are linked to what's left
of clang. I guess I'll need to try and dig deeper, and see if I can
discover, why, and what happened.
Just for the record. Re-reading my comment above, I realize that
my statement regarding clang, might be interpreted as my having
negative feelings about clang/llvm. For clarity, that is not the
case. This install is targeted at development. As such, I want
more granular control of what I build, and test with. So I'll
actually be installing every version of lang/clang, and testing
accordingly.
Thank you again, Scott, for taking the time to respond.
--Chris
>
> --
> DISCLAIMER:
>
> No electrons were maimed while sending this message. Only slightly bruised.
> ___
> 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"
