Release notes are available at
http://www.x.org/X11R6.8.2/doc/RELNOTES.html
Thanks to kris and krion for running several cluster test builds,
maintainers of GNOME for prompt responses, portmgr for postponing ports
freeze for this update, testers on FreeBSD-X11@ list and others that I
might have mised here.
Also included:
- fix for ATI Mobility on Dell Inspiron 7500 (obtained from Marc Aurele La
France; obtained and tested by julian)
- fix for kbd driver on Sparc64 (tested by Aaron Dudek, Michael G. Jung and
Matthias Muthmann), which still appears to have problems with some
keyboards - so
- fix for kbd driver on PC98 (reported and tested by NAKAJI Hiroyuki; PR
ports/77217)
- fix for i810 on HP D530 (obtained from Egbert Eich; obtained and tested
by Anders Nor Berle; PR ports/74757)
His idea was:
What do you guys think of changing the +='s in bsd.sites.mk to
?='s? The deal is this: say I have a specific AfterStep dist
site that I want to use, and I don't want the default listed
sites to be attempted at all.
As it stands now, there are two current solutions that I see:
* edit bsd.sites.mk after every cvsup
* put like 100 entries for that site in MASTER_SITE_AFTERSTEP
in /etc/make.conf and turn on RANDOMIZE_MASTER_SITES
His solution was:
Change the bsd.sites.mk to MASTER_SITE_AFTERSTEP?=, and then I
can define MASTER_SITE_AFTERSTEP to be whatever I want it to
be.
The final solution is:
Add an .if !defined(IGNORE_MASTER_SITE_xxx) / .endif around all
MASTER_SITE definitions:
+.if !defined(IGNORE_MASTER_SITE_XORG)
MASTER_SITE_XORG+= \
ftp://ftp.x.org/pub/%SUBDIR%/ \
ftp://ftp.gwdg.de/pub/x11/x.org/pub/%SUBDIR%/ \
[...]
+.endif
This way, if you want to ignore the default MASTER_SITE_xxx and use
a certain mastersite for this collection, you set this in your
/etc/make.conf:
IGNORE_MASTER_SITE_xxx=yes
MASTER_SITE_xxx=http://z.x.y/
While if you prefer a certain mastersite for this collection, you
set this in your /etc/make.conf:
MASTER_SITE_xxx=http://z.x.y/
NOTE: these are only added if the related variables are defined by the port.
This should ease the configuration of launcher shell scripts used for Java
application ports, when they are using javavmwrapper to invoke a JVM. From now,
a simple launcher that suits most of the Java application ports can be writen
using the following scheme:
#!/bin/sh
JAVA_VERSION="%%JAVA_VERSION%%" \
"%%LOCALBASE%%/bin/java" -jar "%%JAVAJARDIR%%/myport.jar" "$@"
As mentioned above, this is of course only correct provided that the port
defines JAVA_VERSION.
Approved by: glewis (co-maintainer)
- Sync up Motif selection algorithm with xemacs21-mule port.
- Remove GTK support for now, it was commented out and it does not work well.
- General Makefile cleanup
- Unbreak on sparc64
PR: ports/77291
Submitted by: Pawel Worach <pawel.worach(at)telia.com>
* Document DISABLE_VULNERABILITIES variable. [2]
* Add WWW: line for 'search' target. [3]
* Speedup check-vulnerable invokation, if portaudit is installed. [4]
* Run install-info for all .info files. [5]
* Run add-plist-docs more strictly and prevent some situations with
leftover files in the future. [6]
* Introduce two new variables: MASTER_PORT and SLAVE_PORT.
The results from these variables is only used as information for
users. [7]
* Honour OPTIONS if PACKAGE_BUILDING or BATCH are defined. [8]
* Move all USE_GCC entries to new file - bsd.gcc.mk. 'test-gcc'
target allows users to check gcc version if USE_GCC is used. Give
maintainers opportunity to add '+' character to USE_GCC version
for using specified and higher versions. [9]
* Install startup scripts with the help of USE_RC_SUBR variable. [10]
* Add three new targets: config-recursive, rmconfig-recursive and
config-conditional. You can set or delete OPTIONS for all
dependencies before every build. config-conditional target is
used to skip configuring ports which have already been
configured. [11]
* Fix using of WANT_PGSQL_VER variable if postgresql is already
installed. [12]
PR: ports/75768 [1], ports/75728 [2], ports/76187 [3],
ports/76191 [4], ports/76182 [5], ports/75379 [6],
ports/75286 [7], ports/75727 [8], ports/76489 [9],
ports/73691 ports/69217 [10], ports/76254 [11],
ports/76988 [12]
Submitted by: dinoex [1], edwin [2] [5] [6] [8] [9] [10],
Marcus Grando <marcus@corp.grupos.com.br> [3],
tobez and Valentin Nechayev <netch@netch.kiev.ua> [4],
linimon [7], Florent Thoumie <flz@xbsd.org> [10],
Chris Dillon <cdillon@wolves.k12.mo.us> [11],
girgen [12]
dropped and the lang/ruby16_r and lang/ruby18_r ports have been
removed, since no one seems to appreciate the partially working
solution.
Good news is that the pthread support of lang/ruby18 is now enabled by
default for newer systems, which means the ruby interpreter is linked
with libpthread. This will allow threaded extension libraries to run
and work properly on those systems.
The --march=cputype flag is disabled because it gets ruby to
malfunction and fail to build. I don't know if the problem is in
libpthread or in gcc.
(It really makes me wonder if they had actually tested before asking
me to do this somewhat risky change ;-)
Use more correct OSVERSION threshold to distinguish between
base system perl and perl from ports - the right value is 500036 [1].
Also, simplify OSVERSION-related logic in lang/perl5 and lang/perl5.8.
Now it goes as follows:
- for lang/perl5.8, if there is perl in the base system, install
use.perl script, use a helpful pkg-message, and do not automatically
update symlinks;
- for lang/perl5.8, if there is no perl in the base system, do not
install use.perl script, and update symlinks automatically;
- for lang/perl5, always install use.perl;
- for lang/perl5, never update symlinks automatically;
- for lang/perl5, vary produced pkg-message depending on the presence of
the base system perl.
Bump PORTREVISION for both lang/perl5 and lang/perl5.8.
[1] Approved by: portmgr
All ports depending on postgresql shall use the USE_PGSQL=yes knob
defined in Mk/bsd.ports.mk. Bumping portrevisions where needed.
PR: 75344
Approved by: portmgr@ (kris), ade & sean (mentors)
dependency on many python versions. This fixes a problem that Zope
product ports depend on both of Python 2.3 and 2.4 if they use not
only Zope itself but also 3rd party Python modules.
Submitted by: Filippo Natali <filippo.natali@widestore.net>
