and make XFREE86_VERSION map to it. XFREE86_VERSION is now deprecated.
- Make xorg the default X_WINDOW_SYSTEM on -current.
- Add several new X_*_PORT variables which point to various pieces of X11 based
on the setting of X_WINDOW_SYSTEM, and make ports use them.
- Add information to CHANGES about how to handle the transition.
PR: ports/68763
Approved by: portmgr (marcus)
Approved by: re (scottl)
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
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.
to unbreak gtk-doc as well as removes a ton of gross hacks to support
the old location. Also, import some CVS patches from SK to fix some
potential crashes when installing bad catalogs.
While I tested this with a full SK database rebuild, problems may still
occur. Please let me know if you encounter any issues with OMF files
after this commit.
Instead, make configure check for a file installed by docbook-sk, and
move the catalog creation to a pre-install target.
Prompted by: Andrew J Caines <A.J.Caines@halplant.com>
Tested by: myself
Andrew J Caines <A.J.Caines@halplant.com>
SGML catalogs in favor of its own XML format catalogs as well as prevent
scrollkeeper from making HTTP connections to obtain DTDs for OMF
validation.
PR: 39504 46179
Tested by: Stephen Hilton <nospam@hiltonbsd.com>
Mezz bsdforums.org <reigncracks@hotmail.com>
symlinks when attempting to locate a temp file. Note, this is not the
author's patch, but one of my own. I think this should fix it, but I'm
not sure if I'm missing something. The patch is based on the description
from securityfocus.com.
See http://online.securityfocus.com/bid/5602/info/ for more details.
Reported by: Daniel Harris <dh@askdh.com>
problematic for some users. Instead, fix it so that only ${LOCALBASE}
will be followed if it is a symlink.
PR: 42096
Tested by: John-David Childs <jdc@nterprise.net>
When we uninstall scrollkeeper, revert back to the original catalog files
so the dependecny chain has a better chance of being preserved. Bump
PORTREVISION.
PR: 41300
apps to bsd.gnomeng.mk. The goal is to make GNOME1 framework more modular,
which will allow to use GNOME1 apps with GNOME2 desktop as well as considerably
reduce langht of dependency chains for GNOME1 ports (for example after this
commit AbiWord's dependency chain was reduced by 7 ports from 57 to only
50, while Gnumeric's - from 60 to 53 and so on).
The most of the GNOME1 apps are still not converted, so that lot of work is
still ahead.
Please report any unusual problems to gnome@FreeBSD.org.
Discussed with: marcus
Reviewed by: marcus
Also, fix it so scrollkeeper 0.2 will produce a correct XML
database. Bump PORTEPOCH.
scrollkeeper 0.3.x will be looked at further to see if there is a good way
to make it work with both GNOME 1.4 and GNOME 2.0.
PR: 38581
With this new version, GNOME 2.0 documentation works, and scrollkeeper
updates for GNOME 1.x applications work as well. I have tested builds
of most of the GNOME 1.x applications, and none of them fail.
Reviewed by: sobomax
