Deprecate gnome1 for real, it is EOLed for very long upstream now, it is
cluttering the infrastructure and ports tree.
It cost a lot in maintainance and improvement of the ports tree.
Approved by: gnome@ (implicit)

Bump portrevision due to upgrade of devel/gettext.
The affected ports are the ones with gettext as a run-dependency
according to ports/INDEX-7 (5007 of them) and the ones with USE_GETTEXT
in Makefile (29 of them).
PR: ports/124340
Submitted by: edwin@
Approved by: portmgr (pav)

Mass-conversion to the USE_AUTOTOOLS New World Order. The code present
in bsd.autotools.mk essentially makes this a no-op given that all the
old variables set a USE_AUTOTOOLS_COMPAT variable, which is parsed in
exactly the same way as USE_AUTOTOOLS itself.
Moreover, USE_AUTOTOOLS has already been extensively tested by the GNOME
team -- all GNOME 2.12.x ports use it.
Preliminary documentation can be found at:
http://people.FreeBSD.org/~ade/autotools.txt
which is in the process of being SGMLized before introduction into the
Porters Handbook.
Light blue touch-paper. Run.

Apply a big libtool patch to allow porters to use the libtool installed by
the libtoolX ports instead of the one included with each port. Ports that
set USE_LIBTOOL_VER=X will now use the ports version of libtool instead of
the included version. To restore previous behavior, use the new macro,
USE_INC_LIBTOOL_VER. Both macros accept the same argument: a libtool version.
For example, to use the ports version of libtool-1.5, add the following to
your Makefile:
USE_LIBTOOL_VER= 15
To use the included version of libtool with extra hacks provided by
libtool-1.5, add the following to your Makefile:
USE_INC_LIBTOOL_VER= 15
With this change, ports that had to add additional libtool hacks to prevent
.la files from being installed or to fix certain threading issues can now
delete those hacks (after appropriate testing, of course).
PR: 63944
Based on work by:eik and marcus
Approved by: ade (autotools maintainer)
Tested by: kris on pointyhat
Bound to be hidden problems: You bet

Whoa there, boy, that's a mighty big commit y'all have there...
Begin autotools sanitization sequence by requiring ports to explicitly
specify which version of {libtool,autoconf,automake} they need, erasing
the concept of a "system default".
For ports-in-waiting:
USE_LIBTOOL=YES -> USE_LIBTOOL_VER=13
USE_AUTOCONF=YES -> USE_AUTOCONF_VER=213
USE_AUTOMAKE=YES -> USE_AUTOMAKE_VER=14
Ports attempting to use the old style system after June 1st 2004 will be
sorely disappointed.

GNOME has just changed the layout of their FTP site. This resulted in
making all the distfiles unfetachable. Update all GNOME ports that fetch
from MASTER_SITE_GNOME to fetch from the correct location.

gettext upgrade uber-patch (stage 3)
- switch devel/gettext (0.11.1) on, installing full package
- flip devel/gettext-old (0.10.35) to installing only static binaries
with a "-old" suffix -- gettext-old will have its deorbit burn
sequence initiated just after 4.6-RELEASE
- fix up ports for the new world order
Reviewed by: portmgr

Use ${ECHO_CMD} instead of ${ECHO} where you mean the echo command; the ECHO
macro is set to "echo" by default, but it is set to "true" if make(1) is
invoked with the -s option while ECHO_CMD is always set to the echo command.

Huh, finally implement writev(2) wrapper that actually works. Boys, never ever
try to use writev(2) in a non-blocking mode, especially on sockets. Not only
this makes handling of EAGAIN rather weird, but in the case of sockets makes
your code subject of a ENOBUFS, which is absolutely unclear how to handle
properly. *sigh*

Reimplement fix for an imcompatibility between ORBit and FreeBSD properly.
Instead of replacing writev(2) with loop based on write(2), test system limit
on the number of vectors writev(2) accepts and split call to writev(2) to
several calls in such a way that number of vectors in each call doesn't exceed
this limit (aka UIO_MAXIOV). Bump PORTREVISION.

Fix a rather weird incompatibility between ORBit and FreeBSD. It appears that
FreeBSD's writev(2) implementation is rather unreliable when large number of
vectors is submitted - it returns EINVAL despite the fact that all arguments
are pretty valid. This caused serious problems with GNOME's oaf and prevented
Nautilus from working properly. The problem disappeared when I've replaced
writev(2) call with appropriate loop based around ordinary write(2). Perhaps
this should be investigated and the real source of the problem fixed instead,
but I do not have a time for this right now. For those who interested I'm
ready to provide a step-by step instruction on how to reproduce the bug.

Address a potential security issue by forcibly telling ORBit not to listen on
any network (IPv4 or IPv6) sockets, if and only if the user hasn't already
installed a ${PREFIX}/etc/orbitrc file (the default, and most likely case)