Re: ports/119546

2013-05-11 Thread b.f.
On 5/11/13, Andrea Venturoli m...@netfence.it wrote:
 On 05/10/13 15:50, b.f. wrote:

...

 Here's what I did:
 # find /usr/ports -type f -exec grep -l OPENSS_PORT {} ;

 This showed very few ports really requiring openssl from ports, none of
 which I had currently installed.


Then the simplest and safest solution for you is just to remove
security/openssl, if you don't think that you'll need it.

 So I moved its libraries to /usr/local/lib/compat/pkg/ and pkg_deleted
 (-f) it. Newer compilations would pick up base, then.


You may also need to move the security/openssl headers out of
${LOCALBASE}/include/openssl, to prevent ports from mistakenly using
them.

...

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: ports/119546

2013-05-10 Thread b.f.
Andrea wrote:

...

 I had a look at /usr/ports/net/openldap23-server/Makefile and only found:
  USE_OPENSSL=yes

 AFAICT this does not give any preference wrt to base vs port openssl; if
 I'm correct this means the port is choosen if installed, but, otherwise,
 openssl from base is used.

 Wouldn't it be better to use base only? Put a knot to give the user a
 choice?

 Would I screw too many things if I tried adding:
  WITH_OPENSSL_BASE=yes

Yes, because then the additions to the check-depends target in
ports/Mk/bsd.openssl.mk would cause unsandboxed builds of the port on
a live system to fail when security/openssl is installed.  Adding
WITH_OPENSSL_BASE to port Makefiles should be avoided for this reason.

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: ports/119546

2013-05-10 Thread b.f.
On 5/10/13, Andrea Venturoli m...@netfence.it wrote:
 On 05/10/13 14:32, b.f. wrote:

 Would I screw too many things if I tried adding:
 WITH_OPENSSL_BASE=yes

 Yes, because then the additions to the check-depends target in
 ports/Mk/bsd.openssl.mk would cause unsandboxed builds of the port on
 a live system to fail when security/openssl is installed.  Adding
 WITH_OPENSSL_BASE to port Makefiles should be avoided for this reason.

 Thanks for the answer, but I don't quite get this. Do you have any
 pointer for docs I can study?

I don't think so, other than the ports Makefiles.  With regard to
bsd.openssl.mk, I was referring to:

59 .if defined(WITH_OPENSSL_BASE)

,,,

 73 .if exists(${LOCALBASE}/lib/libcrypto.so)
 74 check-depends::
 75 @${ECHO_CMD} Dependency error: this port wants the
OpenSSL library from the FreeBSD
 76 @${ECHO_CMD} base system. You can't build against it,
while a newer
 77 @${ECHO_CMD} version is installed by a port.
 78 @${ECHO_CMD} Please deinstall the port or undefine
WITH_OPENSSL_BASE.
 79 @${FALSE}
 80 .endif


 What's the purpose/usefulness of WITH_OPENSSL_BASE, then?


I'm afraid that it is not very useful, for the many people that use
security/openssl. We had hoped that it would work as originally
intended, but we found that many ports sloppily change the library
search paths for linking, so if security/openssl is installed, many
ports link to the libraries of the openssl port rather than the base
system openssl, even if WITH_OPENSSL_BASE is set.  So the restrictive
checks in bsd.openssl.mk were added to prevent these kinds of
problems, even if they aren't needed in every specific case.



 Is there another simple solution?

You can try to work around the problem by not using USE_OPENSSL, but
instead adding the openssl dependencies, link line and rpath
additions, etc. in the port Makefile. A number of ports used to do
this, for various reasons.  However, this should only be done when
necessary, to prevent the proliferation of ad hoc methods of using
openssl in the ports tree, which makes maintenance more difficult.

A real solution (probably as good a solution as we can arrive at
without investing a lot more time in patching many different ports, or
fundamentally changing the way that we handle linking) would be to
change the openssl port and bsd.openssl,mk to install the
security/openssl libraries in a location other than ${LOCALBASE}/lib
(as in the parallel case of the compiler support libraries used by the
lang/gcc* ports that conflict with some base system libraries), so
that it would be more difficult to accidentally link to them, and so
the -L and -rpath directives in bsd.openssl.mk would have fewer
unintended side effects.  Then some of the restrictive checks in
bsd.openssl.mk could be relaxed.

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: WANTED: Tool to verify installed package/port consistancy

2013-05-09 Thread b.f.
Ronald wrote:

...

 It occurs to me that *something*, i.e. some tool(s) within the FreeBSD
 panoply, *must* already be reading and/or otherwise making use of those
 MD5 checksums within the +CONTENTS files.  Otherwise, why would they even
 be there?  So my question really comes down to this: What pre-existing
 software tools are available that can and do check the MD5 checksums, as
 given the the +CONTENTS file(s), of various files associated with some
 given installed port or package?

...

Yes, of course, this is a basic package management feature:
pkg_info(1) with the -g flag.
(The analogous part of the newer pkgng is described in pkg-check(8)
from ports-mgmt/pkg.)

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: Ocaml ports needs love

2013-02-27 Thread b.f.
I received a lot of complaint about ocaml being in a bad shape: lang/ocaml 
being
outdated, lots of ocaml ports not being carefully maintained and updated.

I personnally know nothing about ocaml so I'm not able to actually be helpful 
to
improve the situation, I would love to see people taking the task of cleaning 
up
the situation, bringing up ocaml ports to newer version.

Probably creating a ocaml@ team would be a good idea?

Have these people been talking to the maintainers, or those
responsible for outstanding PRs?  Because I've only had two inquiries
in the past several months.  There were a few delays as maintainership
passed from stas to new volunteers, the pre-release freeze was
drawn-out, some upstream bugs were fixed, and while other changes
(like tcl/tk) were made. But I expect that the new ocaml will be done
soon (right after an update of lablgtk2) , and Michael Grunewald has
been active. An ocaml alias and mailing list might help at least for
the unmaintained ports, and as a place for discussions.

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: 7+ days of dogfood

2013-02-13 Thread b.f.
On 2/13/13, Anton Shterenlikht me...@bristol.ac.uk wrote:
   From s...@troutmask.apl.washington.edu Wed Feb 13 03:40:53 2013

   On Wed, Feb 13, 2013 at 02:15:08AM +, b.f. wrote:
On 2/13/13, Steve Kargl s...@troutmask.apl.washington.edu wrote:
 On Wed, Feb 13, 2013 at 12:18:29AM +, b.f. wrote:
 # cat /etc/make.conf|grep FFLAGS
 FFLAGS = -O2 -pipe -march=native -mtune=native

 Please do _not_ assign flags unconditionally in make.conf.

 FFLAGS is for compiling Fortran.  I'm one of the people who
 has spent years working/patching gfortran.  I think I might
 have a better understanding of what options to use with
 gfortran than most people.

   
I know you have, but you are giving advice that is liable to be abused
by those who are less experienced.  The flags you are adding are not
the problem -- it's the way that you are adding them -- specifically,
the assignment in the first line of your snippet, if it's applied
unconditionally.  You should either be appending all of them, or
assigning them conditionally, so that they are sure to be assigned
only once, or -- preferably -- using another makefile that can't be
re-read multiple times during a build (ports/Mk/bsd.port.mk
automatically includes several makefiles that can be used for this
purpose, if you are building a port). You have been lucky not to trip
over this: every couple of months for the last several years I have
had to debug errors reported by users that arise from this problem. It
is more common with CFLAGS and CXXFLAGS but it can happen with FFLAGS,
too.

   Try 'find /usr/ports -name Makefile -maxdepth 3 | xargs grep FFLAGS'
   Then go read about the options chosen by the various port maintainers.
   I specifically set FFLAGS to avoid the questionable options set in
   the ports.  If -malign-double appears in a port, it should probably
   be marked as broken.  If a port uses -fdefault-real-8, it should 
 probably
   be marked as broken.  If a port uses -ffast-math, it may have issues 
 that
   are extremely difficult to debug.

 (I removed freebsd-current@ and added cc to ports@)

 Oi vey. I see, it is complicated.
 So on the one hand some options are
 risky or just wrong and must not be used.
 On the other there is a large number of ports,
 which might not even build if this is implemented,
 and convincing upstream that they are wrong
 is never easy.

 Is there a middle ground?
 What about appending the suggested options
 to FFLAGS in ports/MK/bsd.port.mk?
 Or will it make debugging ports with questionable
 options even harder?

By all means, adjust our conservative default flags if you want to
improve the performance of some ports or other software -- only be
sure to test the results.  Dr. Kargl has given you some good
candidates.  But I'd advise you to add to the flags once at the start
of a build, and to deal with flag changes in a port or other piece of
software that you think are unnecessary and problematic by patching
the software itself. (If the software uses gmake or adds problematic
flags and then uses them before it invokes make(1) again you won't be
able to deal with them in make.conf, anyway.)  It's probably best to
use a makefile that was intended for this purpose, like
${PORTSDIR}/Mk/bsd.local.mk.  (Or, If you still prefer make.conf, you
could make the flag alterations there, but conditionally -- you could
test .CURDIR, for example, to prevent your changes from being
reapplied if you have descended into a work directory.  But using
another makefile would probably be better.)

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 to move 9.1 ports to HEAD?

2013-02-08 Thread b.f.
On 2/8/13, Anton Shterenlikht me...@bristol.ac.uk wrote:
   From bf1...@googlemail.com Fri Feb  8 17:33:09 2013

  I don't think it's true.
  While still on 9.1 ports, the latest
  entry in UPDATING was (well I lost it now)
  about NOV-2012. I believe the revision was
  also substantially lower.

  AS soon as I switched to head,
  the latest entry in UPDATING is from
  6-FEB-2013 and the revision is 311942.

  Or maybe I misunderstood you?
   
You do.  :-)
The local _subversion repository_ (I know I'm using incorrent
terminology) has a revision number: r##.  Which is the same
across different versions of FreeBSD.
The individual ports _maintained within that repository_ have
their individual ports numbers (e.g. libreoffice-3.6.5) ... which
also does not vary with the FreeBSD release.  One can have
libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two separate
ports and both work (or should) on 8.3, 9.1, and -CURRENT.  If a
port has a minimum (or maximum) release of the OS it supports, there
a mechanism for figuring that out and DTRT.
   
Or did I misunderstand you?

   Yes, it is now branched, and he was probably using the equivalent of:

   http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/

   rather than

   http://svnweb.FreeBSD.org/ports/head/

   By the way, Anton, you may wish to use https:// rather than svn:// --
   slightly less efficient, but more secure.

 yes, got it, cool!

 root@zzz:/root # svn info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: https://svn0.us-east.freebsd.org/ports/head
 Repository Root: https://svn0.us-east.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 311950
 Node Kind: directory
 Schedule: normal
 Last Changed Author: eadler
 Last Changed Rev: 311950
 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013)

 root@zzz:/root #

 Does svn://svn.freebsd.org/base/head
 support https too?


Apparently, yes.

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 to move 9.1 ports to HEAD?

2013-02-08 Thread b.f.
On 2/8/13, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Fri, Feb 8, 2013 at 10:45 PM, Kimmo Paasiala kpaas...@gmail.com wrote:
 On Fri, Feb 8, 2013 at 10:17 PM, Anton Shterenlikht me...@bristol.ac.uk
 wrote:
 From bf1...@googlemail.com Fri Feb  8 17:33:09 2013

I don't think it's true.
While still on 9.1 ports, the latest
entry in UPDATING was (well I lost it now)
about NOV-2012. I believe the revision was
also substantially lower.
  
AS soon as I switched to head,
the latest entry in UPDATING is from
6-FEB-2013 and the revision is 311942.
  
Or maybe I misunderstood you?
 
  You do.  :-)
  The local _subversion repository_ (I know I'm using
 incorrent
  terminology) has a revision number: r##.  Which is the
 same
  across different versions of FreeBSD.
  The individual ports _maintained within that
 repository_ have
  their individual ports numbers (e.g. libreoffice-3.6.5) ...
 which
  also does not vary with the FreeBSD release.  One can have
  libreoffice-3.6.5 and libreoffice 3.5.4 - but those are two
 separate
  ports and both work (or should) on 8.3, 9.1, and -CURRENT.  If
 a
  port has a minimum (or maximum) release of the OS it supports,
 there
  a mechanism for figuring that out and DTRT.
 
  Or did I misunderstand you?

 Yes, it is now branched, and he was probably using the equivalent
 of:

 http://svnweb.FreeBSD.org/ports/branches/RELENG_9_1_0/

 rather than

 http://svnweb.FreeBSD.org/ports/head/

 By the way, Anton, you may wish to use https:// rather than
 svn:// --
 slightly less efficient, but more secure.

 yes, got it, cool!

 root@zzz:/root # svn info /usr/ports/
 Path: /usr/ports
 Working Copy Root Path: /usr/ports
 URL: https://svn0.us-east.freebsd.org/ports/head
 Repository Root: https://svn0.us-east.freebsd.org/ports
 Repository UUID: 35697150-7ecd-e111-bb59-0022644237b5
 Revision: 311950
 Node Kind: directory
 Schedule: normal
 Last Changed Author: eadler
 Last Changed Rev: 311950
 Last Changed Date: 2013-02-08 19:18:40 + (Fri, 08 Feb 2013)

 root@zzz:/root #

 Does svn://svn.freebsd.org/base/head
 support https too?

 Thanks

 Anton



 Just to repeat what others have tried to tell you. The ports tree is
 NOT branched. The branches/RELENG_9_1_0 thing is a tag in subversion
 terminology, a read only-snapshot of head from the time the release
 was made that will never be updated.

 -Kimmo

 Actually I'm talking slightly rubbish here, the tags are in the tags/*
 part of the repository, for example
 http://svn.freebsd.org/ports/tags/RELEASE_9_1_0. The
 branches/RELENG_9_1_0 thing is a proper branch but since there's no
 announcement of what it should used for I would guess it's someone's
 test branch.

Yes, it's a branch -- or a copy, I suppose, in subversion terms.  I
believe it was used to generate the package set for the 9.1 release.
There probably won't be any future changes to it, but people can use
it, as Anton apparently did.

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: Removal of Portmanager

2013-01-16 Thread b.f.
Mark wrote:
On Wed, Jan 16, 2013 at 01:51:39AM +, RW wrote:
  Reports are sent to ports@ every 2 weeks.

 And I wonder how many people read carefully through all 478 entries.

And your suggestion is ... ?


Try ports/ports-mgmt/portupdate-scan.

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: Removal of Portmanager

2013-01-16 Thread b.f.
On Wed, Jan 16, 2013 at 08:48:37AM +, b.f. wrote:
 Mark wrote:
 On Wed, Jan 16, 2013 at 01:51:39AM +, RW wrote:
   Reports are sent to ports@ every 2 weeks.
  And I wonder how many people read carefully through all 478 entries.
 And your suggestion is ... ?
 Try ports/ports-mgmt/portupdate-scan.

portupdate-scan displays pertinent entries from /usr/ports/UPDATING.
How does that help you digest long lists posted on a mailing list?


Obviously, it can't:  I misunderstood the original complaint.  If
portupdate-scan is parsing MOVED and UPDATING, it can help notify
users of port removals before they update their packages, but not
before the ports are removed.  If users have an up-to-date ports tree
in PORTSDIR, they can use something simple like:

pkg_info -qoa | xargs -I @ grep -le EXPIRATION_DATE $PORTSDIR/@/Makefile

to find which of their installed packages are likely to be removed,
with obvious variations to list all DEPRECATED ports, etc.  If they
don't have a ports tree, they can use:

http://portsmon.freebsd.org/portsconcordanceforexpiring.py

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: print/acroreadwrapper and gcc 4.6.3 ISSUE

2013-01-05 Thread b.f.
 Building for acroreadwrapper-0.0.20110920
 Warning: Object directory not changed from original
 /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110920
 @ - /usr/src/sys
 machine - /usr/src/sys/i386/include
 x86 - /usr/src/sys/x86/include
 gcc46 -O2 -pipe -march=pentium4 -mtune=pentium4
 -Wl,-rpath=/usr/local/lib/gcc46 -fno-strict-aliasing -march=pentium4
 -mtune=pentium4 -Werror -D_KERNEL -DKLD_MODULE -nostdinc   -I. -I@
 -I@/contrib/altq -finline-limit=8000 --param inline-unit-growth=100
 --param large-function-growth=1000 -fno-common
 -mno-align-long-strings -mpreferred-stack-boundary=2 -mno-sse -mno-mmx
 -msoft-float -ffreestanding -fstack-protector -std=iso9899:1999
 -fstack-protector -Wall -Wredundant-decls -Wnested-externs
 -Wstrict-prototypes  -Wmissing-prototypes -Wpointer-arith -Winline
 -Wcast-qual  -Wundef -Wno-pointer-sign -fformat-extensions
 -Wmissing-include-dirs -fdiagnostics-show-option -c linux_adobe.c
 cc1: error: unrecognized command line option '-mno-align-long-strings'
 cc1: error: unrecognized command line option '-fformat-extensions'
 *** Error code 1

 Stop in /usr/ports/print/acroreadwrapper/work/linux_adobe_kmod-20110920.
 *** Error code 1

 Stop in /usr/ports/print/acroreadwrapper.

 But gcc 4.2+ works fine. It seems that all the *kmod* ports/parts have
 4.2 'origin' and can't be properly compiled with higher versions of
 gcc or clang.


They use base system makefiles to build the kernel modules, which use
various kernel flags, including some FreeBSD-specific ones, for
consistency.  You can override CWARNFLAGS from kern.mk, but you should
be careful when mixing toolchains for kernel modules.

You are going to find a lot of ports that fail to build with
non-default toolchains.  If you can suggest small, reasonable changes
that make it possible to do so, then submit PRs.

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: Shared library version bump policy suggestion to track these bumps formally

2013-01-04 Thread b.f.
Lev wrote:

   Now, when some port after update installs new version of shared
 library, used by other ports, here are two variants:

  (a) To bump versions of all dependant ports (PORTREVISION=${PORTREVISION} + 
 1)

  (b) Don't touch other ports, but add copy'n'pasted item into
   UPDATING with instructions for users of portmaster, portupgrade
   and binary pkg-ng packages.

Question is: which way is better? Why sometimes first way is selected
  and sometimes second one? Is here any policy to select between them
  in different cases?

You're always supposed to do (a), for those default packages that must
be rebuilt because of the change -- whether because of a shared
library version change, or something else.

(b) is only as a reminder for those users that have non-default
packages that may need to be rebuilt, or as a stopgap in an emergency
-- it is not supposed to replace (a).  It is usually used when someone
failed to notice that a large number of ports link to a shared
library, but that shared library is not in the LIB_DEPENDS of those
ports, because it is in the LIB_DEPENDS of a port that those port
depends upon (if you want to reopen the debate about whether this
non-redundant dependency accounting is the right thing to do, that may
be worthwhile), and needs to alert users while the problematic ports
are being fixed.  It is often a sign that an exp-run should have been
requested, but wasn't.


Personally, I don't like both ways.

First one is error-prone for maintainer: dependency could be
   optional and turned off by default, for example.

Then a PORTREVISION bump isn't necessary, but an UPDATING note may be advisable.


Second one is error-prone for users. And, to be honest, I don't
   like when formal task is performed by hands. All these records in
   UPDATING is copy'n'pasted with replacement of port name, receipt of
   upgrading is always the same (yes, I know, that there are more
   difficult scenarios in UPDATING too, I don't speak about them now).
   Why this receipt should be performed by user, not by tool!?


There are some ways to refine the updating process -- like, for
example, lstewart@'s:

https://lauren.room52.net/hg/scripts/raw-file/tip/libdepend/libdepend.sh

There is certainly room for improvement in the standard tools here.
But some ports may need to be rebuilt for reasons other than shared
library changes, which may be difficult to detect automatically in
every case.

I suggest to have new variable in port's Makefile: BORDER_VERSIONS
   or something like this. Let it will be list of port's versions, when
   shared libs are updated and all dependent ports should be rebuild
   too.

Then, portmaster/portupgrade could add forced updates to queue
   automatically (like with portmaster -r port / portupgrade -fr
   port) if port cross (inclusive) one of versions from this list.

Something like this:

 BORDER_VERSIONS=0.48 0.65 1.0_1

   And if port is updated to version 0.48 or higher from
 version STRICTLY LESS than 0.48 (and same for 0.65 and 1.0_1), all
 ports, which uses this library, will be rebuild too.

This has some advantages, but how would it be used efficiently by the
package-building clusters, in the absence of PORTREVISION bumps?  And
for end users, is BORDER_VERSIONS better, in most cases, than
improving the package-updating tools to perform automatic checks
during partial updates, as in lstewart@'s script? -- how would
BORDER_VERSIONS overcome the existing problems in dependency
accounting that I mentioned above, without forcing unnecessary
rebuilds?

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: Status of ports update submitted 2 months ago

2013-01-04 Thread b.f.
Michael wrote:
Dear FreeBSD community,

2 months ago I submitted four port updates related to the
ocaml/language. The PRs used to be listed by portsmon but I recently
noticed they disappeared. [1]

How can I help to let these changes go into our ports tree?


The four PRs are

2012/11/04ports/173362devel/ocaml-calendar Update to 2.03.2
2012/11/04ports/173364*lang/ocaml Update to 4.00.1
2012/11/07ports/173438*lang/tuareg-mode.el
2012/11/07ports/173453*graphics/ocaml-images Update to 4.0.1

I didn't see these -- I'll try to resolve at least 173364 and 173453.
I think portsmon has some problems with PR links since the disruption
of services following the security breach, but the PRs should still be
in the database.  The ports tree was partially frozen for a while
before the release of 9.1, and some of these couldn't have been
handled during that period.

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