Re: OPTIONSng: Overide options in /var/db/ports/*/options ?

[Gyrd Thane Lange]

On Sun, 17 Mar 2013 19:49:27 +0100
Baptiste Daroussin  wrote:

> On Sun, Mar 17, 2013 at 07:27:56PM +0100, Marco Steinbach wrote:
> > Chris Rees wrote on 17.03.2013 17:15:
> > > On 17 Mar 2013 15:45, "Marco Steinbach"
> > >  wrote:
> > >> Matthew Seaman wrote on 17.03.2013 14:49:
> > >>
> > >>> On 17/03/2013 12:16, Marco Steinbach wrote:
> >  Hi,
> > 
> >  is there a way to overide options stored
> >  in /var/db/ports/*/options, basically getting back the
> >  pre-OPTIONSng behaviour of being able to overide port options
> >  in /etc/make.conf ?
> > 
> >  Before OPTIONSng was introduced, I was able to specify options
> >  in /etc/make.conf (WITHOUT_X11, WITHOUT_CUPS, WITH_MAILHEAD,
> >  WITH_SSL, WITH_MYSQL, WITH_DOVECOT, ...), which then overode
> >  any occurency of that option in any port (or just specific
> >  ones, by e.g. checking .CURDIR), regardless of the setting the
> >  ports option file contained.
> > >>>
> > >>> Find the uniquename of the port[*] (by 'make -V UNIQUENAME')
> > >>> then in /etc/make.conf
> > >>>
> > >>> uniquename_SET= FOO BAR BAZ
> > >>> uniquename_UNSET= BLURFL
> > >>>
> > >>> will override the default settings in that port's Makefile for
> > >>> the FOO, BAR, BAZ and BLURFL options.
> > >>>
> > >>> Note: this won't override any settings you make from an options
> > >>> dialog. Might be a good idea to 'make rmconfig' if you only
> > >>> want to rely on /etc/make.conf
> > >>
> > >> [...]
> > >>
> > >> Exactly my point.  Currently, with OPTIONSng there seems to be
> > >> no way to
> > > overide anything in /var/db/ports/*/options.
> > >> I find it irritating, that I no longer can be sure about options
> > >> in
> > > /etc/make.conf.  I have to check/reconfigure to make sure.
> > >> As much as I like OPTIONSng (especially in combination with
> > > dialog4ports), this is one thing I'd very much like OPTIONSng to
> > > relearn: Enforce options regardless of what's in a ports options
> > > file.
> > > 
> > > No, that's a bad idea.  It's more confusing to have options not
> > > being set that are checked in the OPTIONS dialog.
> > > 
> > > Setting those in make.conf sets defaults, and allows them to be
> > > overridden in individual ports.
> > 
> > Let's say I never want CUPS, X11, EXAMPLES and DOCS, regardless of
> > what I willingly or accidentially configured in an OPTIONS dialog
> > (or is defaulted to in a ports Makefile), either because I didn't
> > understand the dependancy of a choice, I fat-fingered something or
> > someone helps me configuring something, and wants to make sure I
> > get it right:
> > 
> > OPTIONS_UNSET_FORCE= CUPS X11 EXAMPLES DOCS
> > 
> > Same goes for the complementary case of having options set
> > forcibly, either system-wide or per port:
> > 
> > particularport_SET_FORCE= EXAMPLES DOCS
> > 
> > I'd set these in /etc/make.conf, and be done for good.
> > 
> > I have a local patch for that kind of behaviour, but wanted to
> > check for possible alternatives besides the beaten path, before
> > bothering bapt@.
> > 
> 
> The thing is half of people wants the /var/db/*/options to be the
> last word, the other half want the behaviour you are exposing, so
> getting a final word that will satisfy everyone is hard.
> 
> I personnally really dislike /var/db/port/*/options and the dialog :).
> 
> The new option framework has been design to:
> 1/ respect the same behaviour has it used to be
> before: /var/db/port/*/options has the final word.
> 
> 2/ provide the ability to users to be able to tune the whole system
> in a consistent way.
> 
> 3/ provide a way to totally disable the dialog thing (NO_DIALOG) so
> that you can't save a option file by mistake.
> 
> What we can probably do in the end is provide a new macro to totally
> in all cases ignore /var/db/port/*/options.
> 
> Would that satisfy your needs?

I cannot speak for the OP, but it would not solve it for me. I mostly
use the */options dialogue for setting secondary settings, but my
important settings are specified in make.conf. I don't
want to loose either.

I would rather have a mechanism where the port dialogue is brought up
automatically if there is a conflict between the settings in make.conf
and those stored in */options. The dialogue should then present the
stored settings, with the make.conf settings applied latest.

This way my settings in make.conf will no longer be silently ignored.

Best regards,
Gyrd ^_^

> 
> regards,
> Bapt
___
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"

virtualbox-ose-kmod breaks VLAN tagging

[Gyrd Thane Lange]

Hi,

I anyone working on this?:

ports/174975: Latest emulators/virtualbox-ose-kmod 4.2.6 commit (309876)
breaks VLAN tagging


The PR is from January, but I'm experiencing the same problem:

virtualbox-ose-4.2.12
virtualbox-ose-kmod-4.2.12

FreeBSD 10.0-CURRENT #5 r249051: Wed Apr  3 18:13:01 CEST 2013  amd64

Best regards,
Gyrd ^_^
___
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: OPTIONSng: Overide options in /var/db/ports/*/options ?

[Gyrd Thane Lange]

Hi all, its been a while but I have prepared a patch.

On 17.03.2013 21:27, Gyrd Thane Lange wrote:

[Snipped away most of the discussion about whether
/var/db/ports/*/options or make.conf should have the final word, and
mechanisms for forcing one or the other.]

> I would rather have a mechanism where the port dialogue is brought up
> automatically if there is a conflict between the settings in make.conf
> and those stored in */options. The dialogue should then present the
> stored settings, with the make.conf settings applied latest.

(Forget about raising the dialogue and resolving conflicts
automatically. I found a better way.)

> This way my settings in make.conf will no longer be silently ignored.

Rather than forcing either of make.conf or /var/db/ports/*/options to
thrumph the other I have instead settled on a conflict reporting
mechanism that will prevent the port system from silently ignoring my
wishes and allow me to manually resolve the conflicts before building.

The gist of the attached patch is:

1) Go through the options in make.conf and command line (in priority
order) and build two lists:
  - a list of all options that MUST be set
  - a list of all options that MUST NOT be set

2) Compare with current options and build lists where options do not
match users MUST [NOT] preferences.

3) Act on any conflict
Currently I've only implemented a simple way of setting IGNORE with a
list of conflicting options when the following make variable is set.

OPTIONS_CONFLICT_ACTION=fail

If the variable is not set then no action will be taken (making this
feature non-obtrusive to users unless they activate it.) In the future
we may implement other actions: perhaps to automatically bring up the
configuration dialogue.

Note about (1). I see that _[UN]SET_FORCE options have been implemented
after I prepared this patch. This may easily be added to the patch if
required. I have not needed it yet.

This patch is complementary to all the other preference logic, since it
doesn't actually change any options but only report on them.

Best regards,
Gyrd ^_^

Index: Mk/bsd.options.mk
===
--- Mk/bsd.options.mk   (revision 317733)
+++ Mk/bsd.options.mk   (working copy)
@@ -315,6 +315,88 @@
 .undef _SORTED_OPTIONS
 .endif
 
+### 2013-04-19, GTL, check for conflicts
+# Build list of users express preference
+# Maintain two lists:
+#   a) A positive list of all options that MUST be set
+#   b) A negative list of all options that MUST NOT be set
+# Priority: (first listed is least important)
+#   1) Global
+#   2) Uniquename
+#   3) with_/without_ (from make.conf)
+#   4) command line
+
+# Global options...
+_OPTIONS_MUST_SET= ${OPTIONS_SET}
+_OPTIONS_MUST_UNSET=   ${OPTIONS_UNSET}
+
+# Port specific options...
+.for opt in ${${UNIQUENAME}_SET}
+_OPTIONS_MUST_SET+=${opt}
+_OPTIONS_MUST_UNSET:=  ${_OPTIONS_MUST_UNSET:N${opt}}
+.endfor
+.for opt in ${${UNIQUENAME}_UNSET}
+_OPTIONS_MUST_SET:=${_OPTIONS_MUST_SET:N${opt}}
+_OPTIONS_MUST_UNSET+=  ${opt}
+.endfor
+
+# WITH and WITHOUT found in make.conf or reloaded from old optionsfile
+# Actually, we only want to heed settings from make.conf (not the optionsfile),
+# but I don't know how to tell them apart.
+#.for opt in ${ALL_OPTIONS}
+#.  if defined(WITH_${opt})
+#_OPTIONS_MUST_SET+=   ${opt}
+#_OPTIONS_MUST_UNSET:= ${_OPTIONS_MUST_UNSET:N${opt}}
+#.  endif
+#.  if defined(WITHOUT_${opt})
+#_OPTIONS_MUST_SET:=   ${_OPTIONS_MUST_SET:N${opt}}
+#_OPTIONS_MUST_UNSET+= ${opt}
+#.  endif
+#.endfor
+
+# Command line...
+.for opt in ${WITH}
+_OPTIONS_MUST_SET+=${opt}
+_OPTIONS_MUST_UNSET:=  ${_OPTIONS_MUST_UNSET:N${opt}}
+.endfor
+.for opt in ${WITHOUT}
+_OPTIONS_MUST_SET:=${_OPTIONS_MUST_SET:N${opt}}
+_OPTIONS_MUST_UNSET+=  ${opt}
+.endfor
+
+# Prettify...
+_OPTIONS_MUST_SET:=${_OPTIONS_MUST_SET:O:u}
+_OPTIONS_MUST_UNSET:=  ${_OPTIONS_MUST_UNSET:O:u}
+
+# report where current options does match users preferences
+.for opt in ${ALL_OPTIONS}
+.  if empty(PORT_OPTIONS:M${opt})
+.if ${_OPTIONS_MUST_SET:M${opt}}
+_OPTIONS_CONFLICT_SET+=${opt}
+.endif
+.  else
+.if ${_OPTIONS_MUST_UNSET:M${opt}}
+_OPTIONS_CONFLICT_UNSET+=  ${opt}
+.endif
+.  endif
+.endfor
+.undef opt
+.if !empty(OPTIONS_CONFLICT_ACTION:Mfail)
+.  if defined(_OPTIONS_CONFLICT_SET)
+.if defined(_OPTIONS_CONFLICT_UNSET)
+eol_marker=.
+.endif
+# Complain about options that should have been set
+IGNORE+=   Option ${_OPTIONS_CONFLICT_SET} unexpectedly unset${eol_marker}
+.  endif
+.  if defined(_OPTIONS_CONFLICT_UNSET)
+# Complain about options that should not have been set
+IGNORE+=   Option ${_OPTIONS_CONFLICT_UNSET} unexpectedly set
+.  endif
+.endif
+### End of conflicts check
+
+
 ### to be removed once old OPTIONS disappear
 .for opt in ${ALL_OPTIONS}
 .if empty(PORT_OPTIONS:M${opt})
___
freebsd-ports

Re: how to install ruby18

[Gyrd Thane Lange]

On Sat, 04 Jan 2014 15:41:31 +0100
Mathieu Arnold  wrote:

> +--On 4 janvier 2014 15:21:07 +0100 Marco Beishuizen 
> wrote:
> | Hi,
> | 
> | Since portupgrade doesn't work with the default ruby19 ("invalid
> | byte sequence" errors) I want to reinstall ruby18 instead. But
> | ruby18 has been removed from the ports, so how can I install
> | ruby18 again?
> 
> That error may come from a non us-ascii character in portupgrade's
> configuration files.

Hi!

I had a similar problem some time ago. Some intermediate combination of
pkg-tools/ruby/portupgrade installed bad metadata. The following
helped me identity the ports with bad files:

find /var/db/pkg -type f -exec iconv -t US-ASCII {} > /dev/null \;

Reinstalling the indicated ports solved it for me. I'm currently using
pkg-tools, ruby19 and portupgrade with no problems on FreeBSD 8.3.

Best regards,
Gyrd ^_^
___
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: multimedia/transcode won't build

[Gyrd Thane Lange]

On Fri, 08 Aug 2008 15:18:40 +0100
Craig Butler <[EMAIL PROTECTED]> wrote:

> On Fri, 2008-08-08 at 15:58 +0200, Martin Tournoij wrote:
> > On Fri, Aug 08, 2008 at 03:44:32PM +0200, Leslie Jensen wrote:
> > > Hello
> > > 
> > > I have the above problem.
> > > 
> > > I have tried make deinstall and then reinstall, same error.
> > > 
> > > Any hints?
> > > 
> > > Thanks
> > > /Leslie
> > > 
> > > 
> > > -
> > > In file included from import_nuv.c:19:
> > > ../../libtc/tc_lzo.h:13:23: error: lzo/lzo1x.h: No such file or
> > > directory ../../libtc/tc_lzo.h:14:25: error: lzo/lzoutil.h: No
> > > such file or directory import_nuv.c: In function
> > > 'nuv_decode_video': import_nuv.c:473: warning: pointer targets in
> > > assignment differ in signedness
> > > import_nuv.c:480: error: 'lzo_uint' undeclared (first use in this
> > > function) import_nuv.c:480: error: (Each undeclared identifier is
> > > reported only once import_nuv.c:480: error: for each function it
> > > appears in.) import_nuv.c:480: error: expected ';' before 'len'
> > > import_nuv.c:486: warning: implicit declaration of function 
> > > 'lzo1x_decompress'
> > > import_nuv.c:487: error: 'len' undeclared (first use in this
> > > function) import_nuv.c:487: error: 'LZO_E_OK' undeclared (first
> > > use in this function) import_nuv.c:509: warning: pointer targets
> > > in passing argument 2 of 'RTjpeg_deco
> > > mpressYUV420' differ in signedness
> > > import_nuv.c: In function 'import_nuv_decode':
> > > import_nuv.c:624: warning: pointer targets in assignment differ
> > > in signedness
> > > gmake[3]: *** [import_nuv_la-import_nuv.lo] Error 1
> > > gmake[3]: Leaving directory 
> > > `/usr/ports/multimedia/transcode/work/transcode-1.0.
> > > 6/import/nuv'
> > > gmake[2]: *** [all-recursive] Error 1
> > > gmake[2]: Leaving directory 
> > > `/usr/ports/multimedia/transcode/work/transcode-1.0.
> > > 6/import'
> > > gmake[1]: *** [all-recursive] Error 1
> > > gmake[1]: Leaving directory 
> > > `/usr/ports/multimedia/transcode/work/transcode-1.0.
> > > 6'
> > > gmake: *** [all] Error 2
> > > *** Error code 2
> > > 
> > > Stop in /usr/ports/multimedia/transcode.
> > > *** Error code 1
> > > 
> > > Stop in /usr/ports/multimedia/transcode.
> > > -
> > 
> > I had the same problem today, it's probably a bug in the port ...
> > Haven't had the time to look into it.
> > 
> 
> have you got /usr/ports/archivers/lzo installed ?
> 
> it looks like the port is trying to pull in an include files from
> it...

The port appears to looking for the lzo headers in the wrong place.

archivers/lzo places include files in /usr/local/include while
archivers/lzo2 places include files in /usr/local/include/lzo

a) To make the port work with lzo version 1, you can drop a small patch
file (also attached) into /usr/ports/multimedia/transcode/files/:

[patch-libtc_tc_lzo.h]
--- libtc/tc_lzo.h.orig 2008-08-10 22:24:53.0 +0200
+++ libtc/tc_lzo.h  2008-08-10 22:25:37.0 +0200
@@ -10,8 +10,8 @@
 #ifndef TC_LZO_H
 #define TC_LZO_H
 
-#include 
-#include 
+#include 
+#include 
 
 #ifdef HAVE_CONFIG_H
 #include "config.h"

b) You can uninstall archivers/lzo and install archivers/lzo2 instead
(haven' tried this but I'll expect it to work.)

Regards
Gyrd ^_^
___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: multimedia/transcode won't build

[Gyrd Thane Lange]

Leslie Jensen skrev:




The port appears to looking for the lzo headers in the wrong place.

archivers/lzo places include files in /usr/local/include while
archivers/lzo2 places include files in /usr/local/include/lzo

a) To make the port work with lzo version 1, you can drop a small patch
file (also attached) into /usr/ports/multimedia/transcode/files/:

[patch-libtc_tc_lzo.h]
--- libtc/tc_lzo.h.orig2008-08-10 22:24:53.0 +0200
+++ libtc/tc_lzo.h2008-08-10 22:25:37.0 +0200
@@ -10,8 +10,8 @@
 #ifndef TC_LZO_H
 #define TC_LZO_H
 
-#include 

-#include 
+#include 
+#include 
 
 #ifdef HAVE_CONFIG_H

 #include "config.h"

b) You can uninstall archivers/lzo and install archivers/lzo2 instead
(haven' tried this but I'll expect it to work.)

Regards
Gyrd ^_^



Thank you! I'll try the solution you mention.  Just a thought, shouldn't
lzo be a dependency if the port won't build without it? I my self do not 
have lzo installed at all at the moment and will install it just to make 
this new version of transcode work.


If you haven't got any lzo installed from before I guess your simplest 
option is to follow strategy (b) above.


I'm not an expert on this port, I just encountered a similar problem 
when upgrading all of my ports using "portupgrade -fa". I already had 
lzo installed and conjured up a quick fix (a).


 
Two weeks ago the port was updated with a commit comment of "Switch from 
using lzo to lzo2 to fix build". This was probably to work around the 
change in the lzo header files location. It may not have been necessary, 
as it compiled just fine for me with lzo1 and the patch. (Haven't tried 
running it yet though.)


I also see that if you specify the WITH_LZO it pulls in archivers/lzo2 
as a dependency. My guess is that something in the source recently 
changed and requires the use of lzo even when the WITH_LZO is not specified.


And here is a question for the freebsd-ports@ masters. If a port only 
requires basic lzo functionality, is there an easy way to just work with 
whatever version (lzo1 or lzo2) the user already has installed on the 
system? Thus possibly avoiding the user ending up with both versions on 
his system.


Gyrd ^_^


Thanks
/Leslie



___
freebsd-ports@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-ports
To unsubscribe, send any mail to "[EMAIL PROTECTED]"

Re: Strange pkg_deinstall behaviour with pkgng

[Gyrd Thane Lange]

On Tue, 29 Jul 2014 20:41:18 +0200
Baptiste Daroussin  wrote:

> On Tue, Jul 29, 2014 at 05:46:40PM +0200, Andrea Venturoli wrote:
> > On 07/28/14 20:28, Andrea Venturoli wrote:
> > > Hello.
> > >
> > > I was forced to switch to pkgng on a 9.2 box and I'm now noticing
> > > a strange behaviour.
> > >
> > > Before, "pkg_deinstall -R foo" would deinstall foo and all ports
> > > on which foo depended, except those who were needed by other
> > > ports.
> > >
> > > Now, "pkg_deinstall -R foo" will deinstall foo, all ports on
> > > which foo depends and all ports depending on the ports on which
> > > foo depends.
> > >
> > > E.g.
> > > Port A depends on B
> > > Port B depends on C
> > > Port D depends on C
> > >
> > > With the old behaviour, "pkg_deinstall -R A" would deinstall A
> > > and B (but not C).
> > > Now it will deinstall A, B, C and D.
> > 
> > After some investigation, this broke after the upgrade to pkg 1.3,
> > in which *by default* "pkg delete" seems to be the same as "pkg
> > delete -R".
> > 
> >  From what I can tell, there is no flags to "pkg delete" which
> > makes it act as it used to and as portupgrade expects, so I cannot
> > easily fix it.
> > 
> pkg delete -f is not recursive

This is true, but is very hard to guess based on the pkg-delete(8) man
page. My first reading of the options led me to believe that -f was
an alias for -y and that it would forcefully and recursively delete
without asking. This could certainly be better worded in the man page.
-f should explicitly state that it is non-recursive (now that -R is
implicit and there is no other option to turn it off) and that a
confirmation is still required, either interactively or through the -y
option. It was with trepidation that I first used the -f option.

Also, since the -R option now does nothing, it should either be removed
or complemented with an -r option (for non-recursive)

BTW, pkg info use -d for showing dependencies instead of -R (used by
pkg_info), so the options are different from pkg_tools. Also the
options are not consistently named across the pkg commands. 

General gripe about pkg(8): The command structure and options are very
similar to the previous pkg_tools but with enough changes in options
and behaviour that it trips up an unwary user. I feel this is a POLA
violation. It is almost like it is baiting the user into making a
mistake. Is is similar enough to the old tools that the user think it is
sufficient to just replace the hyphen with a space (as in pkg-delete and
pkg delete) but sometimes with subtle changes in options or behaviour,
most of them with no clear rationale for the change.

I suppose that the superficial likeness was to make it more familiar
for existing users of pkg_tools, but since it is not 100% compatible
(would be better if it was) it would perhaps have been better to make a
clean break to remove preconceptions about operations.

Thanks for reading.

Best regards,
Gyrd ^_^

> 
> regards,
> Bapt
___
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: Can someone have a look at PR 185060 (audio/sonata) ?

[Gyrd Thane Lange]

On 04. feb. 2014 09:47, Matthieu Volat wrote:> Hi everybody,
>
> I know everybody is overloaded, but if somebody could have a look at
> http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185060
>
> It would be nice, audio/sonata is pretty useless on freebsd now, and 
> have been for more than a month…


I second this. It is required when controlling recent versions of 
musicpd, and I have been using the patch with great results for weeks 
already.


> And it's getting irritating in these periods of rebuild to ever have 
> to manually patch things… :(


I'm using svn to keep the ports tree up-to-date. That way I only had to 
apply the patch once to audio/sonata/files/*, and it is not clobbered on 
updates. :-)


Gyrd ^_^

>
> -- Matthieu Volat
>

___
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: Can someone have a look at PR 185060 (audio/sonata) ?

[Gyrd Thane Lange]

On 04. feb. 2014 14:11, Mathieu Arnold wrote:

+--On 4 février 2014 09:47:58 +0100 Matthieu Volat 
wrote:
| Hi everybody,
|
| I know everybody is overloaded, but if somebody could have a look at
| http://www.freebsd.org/cgi/query-pr.cgi?pr=ports/185060
|
| It would be nice, audio/sonata is pretty useless on freebsd now, and have
| been for more than a month… And it's getting irritating in these
| periods of rebuild to ever have to manually patch things… :(

Fix committed, thanks :-)


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: Unable to use ports on 8.3 or earlier since r352986

[Gyrd Thane Lange]

Den 09. mai 2014 14:01, skrev Steven Hartland:

Since the following commit ports is now broken on 8.3 and earlier.
http://svnweb.freebsd.org/ports?view=revision&revision=352986

Now while 8.3 is now officially EOL as of 9 days ago such a
breakage so soon after the EOL seems very bad.

Can we consider reverting this and only applying after a
decent amount of time to give people the chance to update
without preventing them from getting port security updates etc?


As a work-around it may be possible to install the devel/bmake port and 
use it for port management. (Disclaimer: have not tried it, but it 
should be possible in theory.)


Best regards,
Gyrd ^_^


Regards
Steve


___
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"